From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 12:56:01 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1855B5D; Sun, 6 Jan 2013 12:56:01 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 41F65ED6; Sun, 6 Jan 2013 12:56:00 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TrplZ-003yco-LZ>; Sun, 06 Jan 2013 13:55:53 +0100 Received: from e178035121.adsl.alicedsl.de ([85.178.35.121] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TrplZ-002HnI-I6>; Sun, 06 Jan 2013 13:55:53 +0100 Message-ID: <50E97457.7050809@zedat.fu-berlin.de> Date: Sun, 06 Jan 2013 13:55:51 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ports FreeBSD , Current FreeBSD Subject: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7BDA07D9443323A1686D5320" X-Originating-IP: 85.178.35.121 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 12:56:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7BDA07D9443323A1686D5320 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable While working with an OpenCL port that is depending on LLVM 3.2, I feel very uncomfortable haveng to have devel/llvm-devel installed while the official release of LLVM is 3.2. The port devel/llvm is still the older 3.1. Is this going to be changed? I guess it must be synchronized with FreeBSD 9.X's LLVM/CLANG, isn't it (I'm on FreeBSD 10.0). Well, this brings up again another piece of question. While FreeBSD's base system already has LLVM/CLANG, it is missing some important LLVM pieces, like llvm-config and others. Having a crippled LLVM aboard AND the need having installed a port is a kind of none-sense. Why should I install port devel/llvm to have a working LLVM backend? The last time I brought up this issue, it was mentioned that the long compile time is one of the reasons. Can this be fixed by having an additional knob like "WITH_LLVM_EXTRAS"? Personally I feel much better having the complete LLVM in the base than having the very same (or with bad luck, a slightly different in the ports) LLVM from the ports. Since it depends on the preferences of search paths, software used to choose the port's version prior over the base system - that caused trouble for me in the past. Oliver --------------enig7BDA07D9443323A1686D5320 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ6XRYAAoJEOgBcD7A/5N8HZkH/iRZcV79lIq5F+NzP8mBu/OZ nie0emch5LFl+BzGq4cA6ZyAQ8dOve69IVAzUAGa2YZTvtg/QjOVFS2+0T7N67yb 1Vp7x0KPGYeBsSsMq4W4G7dyTJUsHKdQp1LIf2B0CidFH8K0m1CTMj70V9qXscwZ uec6uavKruytEtBi3nMuQ9lgeMBsgRkl+nCIjbqyJ9bNlTeN0eT9QzMqEMj+2h5D DP8ZVdh/fVCAP87Sz0BYTu8Kd0gGBu9CuL+J7Qx/rF3TPpsQX/dzZCeFN0okrhbf yEs0wkkaPRypf5oBj4uMVyEtl04xlhLqrV0M+80WsKOcfRE5JY3951mbOGdw7nM= =HzaF -----END PGP SIGNATURE----- --------------enig7BDA07D9443323A1686D5320-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 14:22:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 00C45B9E; Sun, 6 Jan 2013 14:22:24 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep28.mx.upcmail.net (fep28.mx.upcmail.net [62.179.121.48]) by mx1.freebsd.org (Postfix) with ESMTP id EAC491B9; Sun, 6 Jan 2013 14:22:23 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep20-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130106141709.ZQNX11920.viefep20-int.chello.at@edge03.upcmail.net>; Sun, 6 Jan 2013 15:17:09 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id keH91k00t2xdvHc03eH9Dc; Sun, 06 Jan 2013 15:17:09 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 110A66D449; Sun, 6 Jan 2013 15:17:08 +0100 (CET) Date: Sun, 6 Jan 2013 15:17:08 +0100 From: Stefan Farfeleder To: Dimitry Andric Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130106141708.GA1418@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130104154940.GD1430@mole.fafoe.narf.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 14:22:25 -0000 On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: > Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile =================================================================== --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME= libgcc_s.so.1 SHLIBDIR?= /lib +CC= gcc + .include # # libgcc is linked in last and thus cannot depend on ssp symbols coming From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 14:24:24 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 923A2DA1; Sun, 6 Jan 2013 14:24:24 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3F01DF; Sun, 6 Jan 2013 14:24:24 +0000 (UTC) Received: from [192.168.1.44] (unknown [176.222.238.90]) by csmtp3.one.com (Postfix) with ESMTPA id A04F124067A3; Sun, 6 Jan 2013 14:16:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! From: Erik Cederstrand In-Reply-To: <50E97457.7050809@zedat.fu-berlin.de> Date: Sun, 6 Jan 2013 15:16:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0900DD62-3A21-4D77-8B5B-7976ACB3921B@cederstrand.dk> References: <50E97457.7050809@zedat.fu-berlin.de> To: O. Hartmann X-Mailer: Apple Mail (2.1499) Cc: Current FreeBSD , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 14:24:24 -0000 Den 06/01/2013 kl. 13.55 skrev O. Hartmann = : > While FreeBSD's > base system already has LLVM/CLANG, it is missing some important LLVM > pieces, like llvm-config and others. llvm-config is a build dependency that spits out some lib paths that you = can just hard-code for FreeBSD. So what in "others" does your port need? I think the real problem is that LLVM and the related tools are build in = one go, so you can't easily build llvm-config and others for the base = version of LLVM. llvm-config needs shared libraries that are not = installed in base because they supposedly require a prohibitive amount = of build time. The LLVM port could be split up instead. There could be a = devel/llvm-libs port that installed the shared libs for the base LLVM, = and then a devel/llvm-config, devel/scan-build or devel/mclinker port = that depends on the former port. This might require that a larger part = of the LLVM source tree is imported into src/contrib, though. Erik From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 14:52:39 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C43FD327; Sun, 6 Jan 2013 14:52:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6FAA62A9; Sun, 6 Jan 2013 14:52:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b477:ff2d:fc59:6c40] (unknown [IPv6:2001:7b8:3a7:0:b477:ff2d:fc59:6c40]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 907B55C37; Sun, 6 Jan 2013 15:52:37 +0100 (CET) Message-ID: <50E98FB2.5040304@FreeBSD.org> Date: Sun, 06 Jan 2013 15:52:34 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! References: <50E97457.7050809@zedat.fu-berlin.de> In-Reply-To: <50E97457.7050809@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Current FreeBSD , Brooks Davis , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 14:52:39 -0000 On 2013-01-06 13:55, O. Hartmann wrote: > While working with an OpenCL port that is depending on LLVM 3.2, I feel > very uncomfortable haveng to have devel/llvm-devel installed while the > official release of LLVM is 3.2. Please prod the port maintainer (Brooks) to update the llvm port instead. I have CC'd him on this mail. > The port devel/llvm is still the older > 3.1. Is this going to be changed? Obviously, but this is at the discretion of the port maintainer. If Brooks needs more time, then you will have be a little patient. Also please remember that ports just came out of feature freeze. If Brooks has no time, I can update the port too, but since I am not a ports committer, I will still need his review and approval. > I guess it must be synchronized with > FreeBSD 9.X's LLVM/CLANG, isn't it (I'm on FreeBSD 10.0). No, there is no need to be synchronized at all. That is the whole point of a port. With a port, you are free to update the port independently of the base system, or even have multiple versions installed at the same time. > Well, this brings up again another piece of question. While FreeBSD's > base system already has LLVM/CLANG, it is missing some important LLVM > pieces, like llvm-config and others. That is on purpose. The base system only supplies the compiler, with a minimum of dependencies, for now. If we start supplying other LLVM components, such as shared libraries, we will be stuck with their APIs, and will need to maintain those for the lifetimes of the branches in which they occur. > Having a crippled LLVM aboard AND the need having installed a port is a > kind of none-sense. Why should I install port devel/llvm to have a > working LLVM backend? Because then you would have a stock LLVM, with all the bells and whistles that you have configured. The version of llvm/clang in base has a few FreeBSD-specific modifications, and some additional upstream changes that are not in the release version. It is impossible to appease everybody with the version of llvm/clang integrated into the base system. Its function, for now, is simply to be able to bootstrap the system, and function as a system compiler. (Read that as: it is *not* necessarily the compiler for ports, ports can obviously make their own decisions about using other compilers, prepackaged ones, if necessary.) > The last time I brought up this issue, it was mentioned that the long > compile time is one of the reasons. Can this be fixed by having an > additional knob like "WITH_LLVM_EXTRAS"? No, the compile time is not the reason. The reason is having yet another API to be maintained in base. At the moment, clang is just one monolithic executable, without any dependencies. This is an advantage. The only option added (on request from some users) is WITH_CLANG_EXTRAS, which builds a number of tools like llc, opt, and so on. But these really belong in the port too. > Personally I feel much better having the complete LLVM in the base than > having the very same (or with bad luck, a slightly different in the > ports) LLVM from the ports. Since it depends on the preferences of > search paths, software used to choose the port's version prior over the > base system - that caused trouble for me in the past. In my opinion, the ports system should set up things so that it always finds components under $PREFIX first, not those in the base system. At least, in most cases. So if a port is dependent on devel/llvm32, it should ensure the include and library paths are set up so it will find the correct llvm headers and libraries. From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 14:57:35 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF22D578; Sun, 6 Jan 2013 14:57:35 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id B1B922E8; Sun, 6 Jan 2013 14:57:35 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b477:ff2d:fc59:6c40] (unknown [IPv6:2001:7b8:3a7:0:b477:ff2d:fc59:6c40]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F00815C37; Sun, 6 Jan 2013 15:57:33 +0100 (CET) Message-ID: <50E990DD.5040605@FreeBSD.org> Date: Sun, 06 Jan 2013 15:57:33 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Erik Cederstrand Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! References: <50E97457.7050809@zedat.fu-berlin.de> <0900DD62-3A21-4D77-8B5B-7976ACB3921B@cederstrand.dk> In-Reply-To: <0900DD62-3A21-4D77-8B5B-7976ACB3921B@cederstrand.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current FreeBSD , "O. Hartmann" , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 14:57:36 -0000 On 2013-01-06 15:16, Erik Cederstrand wrote: ... > I think the real problem is that LLVM and the related tools are build in one go, so you can't easily build llvm-config and others for the base version of LLVM. Well, it would be easy enough to build llvm-config, but what should its output be? We do not install llvm/clang headers or libraries into the system, so llvm-config would not give any meaningful -I or -L flags. :) > llvm-config needs shared libraries that are not installed in base because they supposedly require a prohibitive amount of build time. Again, build time is not the problem. The libraries are already built, but in static form; making them dynamic would not be that difficult, but installing them would add another maintenance and compatibility burden. > The LLVM port could be split up instead. There could be a devel/llvm-libs port that installed the shared libs for the base LLVM, and then a devel/llvm-config, devel/scan-build or devel/mclinker port that depends on the former port. Yes, this seems to be the proper approach. But, as far as I understand, the ports system cannot yet do one work tree build, and package that up in different packages, such as -libs, -devel, and so on. > This might require that a larger part of the LLVM source tree is imported into src/contrib, though. I am not sure what you mean by this. Why would the ports require something in the base system, other than a compiler? From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 15:00:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A83FE85A; Sun, 6 Jan 2013 15:00:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD63314; Sun, 6 Jan 2013 15:00:07 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b477:ff2d:fc59:6c40] (unknown [IPv6:2001:7b8:3a7:0:b477:ff2d:fc59:6c40]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F34495C37; Sun, 6 Jan 2013 15:59:59 +0100 (CET) Message-ID: <50E9916F.3040500@FreeBSD.org> Date: Sun, 06 Jan 2013 15:59:59 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: clang 3.2 RC2 miscompiles libgcc? References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> In-Reply-To: <20130106141708.GA1418@mole.fafoe.narf.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 15:00:07 -0000 On 2013-01-06 15:17, Stefan Farfeleder wrote: > On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: >> Here's a minimal test case that reproduces the bug: > [...] > > Until someone fixes this bug, could we apply something like this as a > work-around? > > Stefan > > Index: gnu/lib/libgcc/Makefile > =================================================================== > --- gnu/lib/libgcc/Makefile (revision 245055) > +++ gnu/lib/libgcc/Makefile (working copy) > @@ -6,6 +6,8 @@ > SHLIB_NAME= libgcc_s.so.1 > SHLIBDIR?= /lib > > +CC= gcc > + > .include I think this is a bit overkill approach. We still don't know what the exact cause of the problem is, and this just papers over it. Also, ince the bug is only reproducible by compiling the testcase with g++, could you not compile your crashing programs with clang instead, for now? :-) From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 15:23:15 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D22BB22F; Sun, 6 Jan 2013 15:23:15 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF7B400; Sun, 6 Jan 2013 15:23:15 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r06FNDr7049581; Sun, 6 Jan 2013 16:23:13 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r06FND5j049580; Sun, 6 Jan 2013 16:23:13 +0100 (CET) (envelope-from marius) Date: Sun, 6 Jan 2013 16:23:13 +0100 From: Marius Strobl To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20130106152313.GD26039@alchemy.franken.de> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50DB4EFE.2020600@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Davide Italiano , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 15:23:15 -0000 On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote: > On 26.12.2012 01:21, Marius Strobl wrote: > > On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote: > >> Experiments with dummynet shown ineffective support for very short > >> tick-based callouts. New version fixes that, allowing to get as many > >> tick-based callout events as hz value permits, while still be able to > >> aggregate events and generating minimum of interrupts. > >> > >> Also this version modifies system load average calculation to fix some > >> cases existing in HEAD and 9 branches, that could be fixed with new > >> direct callout functionality. > >> > >> http://people.freebsd.org/~mav/calloutng_12_17.patch > >> > >> With several important changes made last time I am going to delay commit > >> to HEAD for another week to do more testing. Comments and new test cases > >> are welcome. Thanks for staying tuned and commenting. > > > > FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a > > try on sparc64 and it at least survives a buildworld there. However, > > with the patched kernels, buildworld times seem to increase slightly but > > reproducible by 1-2% (I only did four runs but typically buildworld > > times are rather stable and don't vary more than a minute for the > > same kernel and source here). Is this an expected trade-off (system > > time as such doesn't seem to increase)? > > I don't think build process uses significant number of callouts to > affect results directly. I think this additional time could be result of > the deeper next event look up, done by the new code, that is practically > useless for sparc64, which effectively has no cpu_idle() routine. It > wouldn't affect system time and wouldn't show up in any statistics > (except PMC or something alike) because it is executed inside timer > hardware interrupt handler. If my guess is right, that is a part that > probably still could be optimized. I'll look on it. Thanks. > > > Is there anything specific to test? > > Since the most of code is MI, for sparc64 I would mostly look on related > MD parts (eventtimers and timecounters) to make sure they are working > reliably in more stressful conditions. I still have some worries about > possible deadlock on hardware where IPIs are used to fetch present time > from other CPU. Well, I've just learnt two things the hard way: a) We really need the mutex in that path. b) Assuming that the initial synchronization of the counters is good enough and they won't drift considerably accross the CPUs so we can always use the local one makes things go south pretty soon after boot. At least with your calloutng_12_26.patch applied. I'm not really sure what to do about that. Earlier you already said that sched_bind(9) also isn't an option in case if td_critnest > 1. To be honest, I don't really unerstand why using a spin lock in the timecounter path makes sparc64 the only problematic architecture for your changes. The x86 i8254_get_timecount() also uses a spin lock so it should be in the same boat. The affected machines are equipped with a x86-style south bridge which exposes a powermanagment unit (intended to be used as a SMBus bridge only in these machines) on the PCI bus. Actually, this device also includes an ACPI power management timer. However, I've just spent a day trying to get that one working without success - it just doesn't increment. Probably its clock input isn't connected as it's not intended to be used in these machines. That south bridge also includes 8254 compatible timers on the ISA/ LPC side, but are hidden from the OFW device tree. I can hack these devices into existence and give it a try, but even if that works this likely would use the same code as the x86 i8254_get_timecount() so I don't see what would be gained with that. The last thing in order to avoid using the tick counter as timecounter in the MP case I can think of is that the Broadcom MACs in the affected machines also provide a counter driven by a 1 MHz clock. If that's good enough for a timecounter I can hook these up (in case these work ...) and hack bge(4) to not detach in that case (given that we can't detach timecounters ...). > > Here is small tool we are using for test correctness and performance of > different user-level APIs: http://people.freebsd.org/~mav/testsleep.c > I've run Ian's set of tests on a v215 with and without your calloutng_12_26.patch and on a v210 (these uses the IPI approach) with the latter also applied. I'm not really sure what to make out of the numbers. v215 w/o v215 w/ v210 w/ ---------- ---------------- ---------------- ---------------- select 1 1999.61 1 23.87 1 29.97 poll 1 1999.70 1 1069.61 1 1075.24 usleep 1 1999.86 1 23.43 1 28.99 nanosleep 1 999.92 1 23.28 1 28.66 kqueue 1 1000.12 1 1071.13 1 1076.35 kqueueto 1 999.56 1 26.33 1 31.34 syscall 1 1.89 1 1.92 1 2.88 select 300 1999.72 300 326.08 300 332.24 poll 300 1999.12 300 1069.78 300 1075.82 usleep 300 1999.91 300 325.63 300 330.94 nanosleep 300 999.82 300 23.25 300 26.76 kqueue 300 1000.14 300 1071.06 300 1075.96 kqueueto 300 999.53 300 26.32 300 31.42 syscall 300 1.90 300 1.93 300 2.89 select 3000 3998.18 3000 3176.51 3000 3193.86 poll 3000 3999.29 3000 3182.21 3000 3193.12 usleep 3000 3998.46 3000 3191.60 3000 3192.50 nanosleep 3000 1999.79 3000 23.21 3000 27.02 kqueue 3000 3000.12 3000 3189.13 3000 3191.96 kqueueto 3000 1999.99 3000 26.28 3000 31.91 syscall 3000 1.91 3000 1.91 3000 2.90 select 30000 30990.85 30000 31489.18 30000 31548.77 poll 30000 30995.25 30000 31518.80 30000 31487.92 usleep 30000 30992.00 30000 31510.42 30000 31475.50 nanosleep 30000 1999.46 30000 38.67 30000 41.95 kqueue 30000 30006.49 30000 30991.86 30000 30996.77 kqueueto 30000 1999.09 30000 41.67 30000 46.36 syscall 30000 1.91 30000 1.91 30000 2.88 select 300000 300990.65 300000 301864.98 300000 301787.01 poll 300000 300998.09 300000 301831.36 300000 301741.62 usleep 300000 300990.80 300000 301824.67 300000 301770.10 nanosleep 300000 1999.15 300000 325.74 300000 331.01 kqueue 300000 300000.87 300000 301031.11 300000 300992.28 kqueueto 300000 1999.39 300000 328.77 300000 333.45 syscall 300000 1.91 300000 1.91 300000 2.88 Marius From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 15:29:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 29F3E597; Sun, 6 Jan 2013 15:29:25 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id F21A465D; Sun, 6 Jan 2013 15:29:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from wanderer.tachypleus.net (dhcp107-17-54-205.hil-sfofhhh.sfo.wayport.net [107.17.54.205]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MG700FJMN0OT800@smtpauth3.wiscmail.wisc.edu>; Sun, 06 Jan 2013 09:29:18 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.6.151818, SenderIP=107.17.54.205 X-Spam-Report: AuthenticatedSender=yes, SenderIP=107.17.54.205 X-Wisc-Sender: whitehorn@wisc.edu Message-id: <50E99848.6090209@freebsd.org> Date: Sun, 06 Jan 2013 10:29:12 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: Dimitry Andric Subject: Re: clang 3.2 RC2 miscompiles libgcc? References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> In-reply-to: <50E9916F.3040500@FreeBSD.org> Cc: Stefan Farfeleder , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 15:29:25 -0000 On 01/06/13 09:59, Dimitry Andric wrote: > On 2013-01-06 15:17, Stefan Farfeleder wrote: >> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: >>> Here's a minimal test case that reproduces the bug: >> [...] >> >> Until someone fixes this bug, could we apply something like this as a >> work-around? >> >> Stefan >> >> Index: gnu/lib/libgcc/Makefile >> =================================================================== >> --- gnu/lib/libgcc/Makefile (revision 245055) >> +++ gnu/lib/libgcc/Makefile (working copy) >> @@ -6,6 +6,8 @@ >> SHLIB_NAME= libgcc_s.so.1 >> SHLIBDIR?= /lib >> >> +CC= gcc >> + >> .include > > I think this is a bit overkill approach. We still don't know what the > exact cause of the problem is, and this just papers over it. > > Also, ince the bug is only reproducible by compiling the testcase with > g++, could you not compile your crashing programs with clang instead, > for now? :-) > I would very much support this patch. Whatever is going wrong is a critical problem -- although his testcase requires g++, I have lots of code that also crashes when built with clang. The fact that *any* code built with *any* compiler crashes when used with clang-built libgcc is an error. This is quite serious and breaks a *lot* of C++ code. If it can't be fixed now, papering it over is required. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 15:45:35 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E21E195B; Sun, 6 Jan 2013 15:45:34 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 744DD6DB; Sun, 6 Jan 2013 15:45:34 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TrsPl-0004gm-2F>; Sun, 06 Jan 2013 16:45:33 +0100 Received: from e178035121.adsl.alicedsl.de ([85.178.35.121] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TrsPk-002Qpa-TY>; Sun, 06 Jan 2013 16:45:33 +0100 Message-ID: <50E99C1B.5080803@zedat.fu-berlin.de> Date: Sun, 06 Jan 2013 16:45:31 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! References: <50E97457.7050809@zedat.fu-berlin.de> <50E98FB2.5040304@FreeBSD.org> In-Reply-To: <50E98FB2.5040304@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAC9162AFC61F486A17E18011" X-Originating-IP: 85.178.35.121 Cc: Current FreeBSD , Brooks Davis , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 15:45:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAC9162AFC61F486A17E18011 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 01/06/13 15:52, schrieb Dimitry Andric: > On 2013-01-06 13:55, O. Hartmann wrote: >> While working with an OpenCL port that is depending on LLVM 3.2, I fee= l >> very uncomfortable haveng to have devel/llvm-devel installed while the= >> official release of LLVM is 3.2. >=20 > Please prod the port maintainer (Brooks) to update the llvm port > instead. I have CC'd him on this mail. >=20 >=20 >> The port devel/llvm is still the older >> 3.1. Is this going to be changed? >=20 > Obviously, but this is at the discretion of the port maintainer. If > Brooks needs more time, then you will have be a little patient. Also > please remember that ports just came out of feature freeze. >=20 > If Brooks has no time, I can update the port too, but since I am not a > ports committer, I will still need his review and approval. >=20 >=20 >> I guess it must be synchronized with >> FreeBSD 9.X's LLVM/CLANG, isn't it (I'm on FreeBSD 10.0). >=20 > No, there is no need to be synchronized at all. That is the whole poin= t > of a port. With a port, you are free to update the port independently > of the base system, or even have multiple versions installed at the sam= e > time. In my case, I had some confusions with some LLVM related software (POCL, portable openCL library). >=20 >=20 >> Well, this brings up again another piece of question. While FreeBSD's >> base system already has LLVM/CLANG, it is missing some important LLVM >> pieces, like llvm-config and others. >=20 > That is on purpose. The base system only supplies the compiler, with a= > minimum of dependencies, for now. If we start supplying other LLVM > components, such as shared libraries, we will be stuck with their APIs,= > and will need to maintain those for the lifetimes of the branches in > which they occur. It is hard for my little brain to accept those things ... A personal tragedy, I guess. I like it the way to have everything "at hand" in the base someone need, but as a non-maintainer, I often forget about the point of maintaining. >=20 >=20 >> Having a crippled LLVM aboard AND the need having installed a port is = a >> kind of none-sense. Why should I install port devel/llvm to have a >> working LLVM backend? >=20 > Because then you would have a stock LLVM, with all the bells and > whistles that you have configured. The version of llvm/clang in base > has a few FreeBSD-specific modifications, and some additional upstream > changes that are not in the release version. Well, then the question is whether it is a big deal to build the other portions with a special knob enabling them. The maintainer also has to split the LLVM system anyway, apply the patches and so on. In my imagination, then some IFDEFS/IFs are applied to get rid of what is not needed. >=20 > It is impossible to appease everybody with the version of llvm/clang > integrated into the base system. >=20 > Its function, for now, is simply to be able to bootstrap the system, an= d > function as a system compiler. (Read that as: it is *not* necessarily > the compiler for ports, ports can obviously make their own decisions > about using other compilers, prepackaged ones, if necessary.) >=20 >=20 >> The last time I brought up this issue, it was mentioned that the long >> compile time is one of the reasons. Can this be fixed by having an >> additional knob like "WITH_LLVM_EXTRAS"? >=20 > No, the compile time is not the reason. The reason is having yet > another API to be maintained in base. At the moment, clang is just one= > monolithic executable, without any dependencies. This is an advantage.= I agree. >=20 > The only option added (on request from some users) is WITH_CLANG_EXTRAS= , > which builds a number of tools like llc, opt, and so on. But these > really belong in the port too. >=20 >=20 >> Personally I feel much better having the complete LLVM in the base tha= n >> having the very same (or with bad luck, a slightly different in the >> ports) LLVM from the ports. Since it depends on the preferences of >> search paths, software used to choose the port's version prior over th= e >> base system - that caused trouble for me in the past. >=20 > In my opinion, the ports system should set up things so that it always > finds components under $PREFIX first, not those in the base system. At= > least, in most cases. So if a port is dependent on devel/llvm32, it > should ensure the include and library paths are set up so it will find > the correct llvm headers and libraries. The confusing part (at least for me) starts there, where a port rquires a compiler, like clang not providing the absolute path to the binary. i had in the past trouble with that where port lang/clang was installed and having used FreeBSD's aboard/base clang compiler in 10.0-CUR. It caused some problems. Well, what you say at the end is, that a port also should then rely on a port compiler from the ports? That would be the logical clean slate solution. I might be wrong here. I'm still hoping, from the point of an user with scietific purposes, that one day FreeBSD will make use of heterogenous execution facilities, like OpenCL introduces: having CPU AND GPU as possible calculation facilities. For that, LLVM seems the proper weapon of choice. Like Apple, having this in the base system would also provide this from the point of view of the base system. But this is possibly too early to think about, since FreeBSD is still not any traget of GPGPU support. Hopefully, this will change in the near future. Maybe too much noise ... oh --------------enigAC9162AFC61F486A17E18011 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ6ZwcAAoJEOgBcD7A/5N8DiAH/RYcZ7BvX1BAQe7gbWN/lExP stciJ2V4LfIjrwDkC29OHQP/DggO1bfmZ1RmWdY06N/4eiaN1KsVsukt2zbbrwua 2+UA6isJe1anD3O9P0yWZNvjNSRaGK6FolzZ0ovPI0Q3A5YUjHih6WMJ+VJfTHAG ZBx6cUdXSj5lGVUOrgTqdIJtlgvn25GZv3K/77OsZ9tDKW0HH6vXvLyb3zPAu4if 286g+jYfFoAF5rq+qcmC80kfrU/lxE55X6XEcN6W7ixEXxZa6ohjowEDaR4YD+UN MeptkAH/bCmqSbrDmQ/iUHhk/LmgxoyXeUsoX+MNLgBI04laLXgNBUKroz1vC/w= =uOYb -----END PGP SIGNATURE----- --------------enigAC9162AFC61F486A17E18011-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 15:52:46 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD6A5BDC; Sun, 6 Jan 2013 15:52:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0E171D; Sun, 6 Jan 2013 15:52:46 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TrsWj-0005UJ-Ep>; Sun, 06 Jan 2013 16:52:45 +0100 Received: from e178035121.adsl.alicedsl.de ([85.178.35.121] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TrsWj-002RCm-Av>; Sun, 06 Jan 2013 16:52:45 +0100 Message-ID: <50E99DCC.1010504@zedat.fu-berlin.de> Date: Sun, 06 Jan 2013 16:52:44 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! References: <50E97457.7050809@zedat.fu-berlin.de> <0900DD62-3A21-4D77-8B5B-7976ACB3921B@cederstrand.dk> <50E990DD.5040605@FreeBSD.org> In-Reply-To: <50E990DD.5040605@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D96E0525AAB0B5F06460232" X-Originating-IP: 85.178.35.121 Cc: Current FreeBSD , Ports FreeBSD , Erik Cederstrand X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 15:52:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D96E0525AAB0B5F06460232 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 01/06/13 15:57, schrieb Dimitry Andric: > On 2013-01-06 15:16, Erik Cederstrand wrote: > ... >> I think the real problem is that LLVM and the related tools are build >> in one go, so you can't easily build llvm-config and others for the >> base version of LLVM. >=20 > Well, it would be easy enough to build llvm-config, but what should its= > output be? We do not install llvm/clang headers or libraries into the > system, so llvm-config would not give any meaningful -I or -L flags. :)= The problem at this point is that I personally do not exactly understand the real dependency of the software i try to build as a port (POCL, now RC2 at sourceforge). The build system requires llvm-config and I guess the LLVM backend for the LLVM IR for the target (at the moment, only the CPU). >=20 >=20 >> llvm-config needs shared libraries that are not installed in base >> because they supposedly require a prohibitive amount of build time. >=20 > Again, build time is not the problem. The libraries are already built,= > but in static form; making them dynamic would not be that difficult, bu= t > installing them would add another maintenance and compatibility burden.= >=20 >=20 >> The LLVM port could be split up instead. There could be a >> devel/llvm-libs port that installed the shared libs for the base LLVM,= >> and then a devel/llvm-config, devel/scan-build or devel/mclinker port >> that depends on the former port. >=20 > Yes, this seems to be the proper approach. But, as far as I understand= , > the ports system cannot yet do one work tree build, and package that up= > in different packages, such as -libs, -devel, and so on. Why splitting up? My problem is NOT the compile time, the burden on an oldish Intel Core2Duo E8400 is not that much and I'm, personally, have installed the port devel/llvm-devel. So I guess now I reeled in everything I need and want to have (without exactly knowing what to need)= =2E My question was to have the whole thing in the base. But you made clear this is more an disadvantage than advantage. >=20 >=20 >> This might require that a larger part of the LLVM source tree is >> imported into src/contrib, though. >=20 > I am not sure what you mean by this. Why would the ports require > something in the base system, other than a compiler? --------------enig5D96E0525AAB0B5F06460232 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ6Z3NAAoJEOgBcD7A/5N84lEIAOWOrXxytKaW6R9RI2E5zpsW J/LewxjY/9DzQzHnvTgvy/UqPw8rhlNGHsbpHthP2CCBF/St+iKZ+3MOyTEpPmuO h6KsOuol1eWH/KiiNt/4CiQmsITYSOCL+tTLj2TntK5Gap1yNVBcXRPaJsNeYYGt bt0+5NACdFpKoLStQD63WMkL2W0Ljx5fGQdjmjTfJ+NQP14bjLd9X164qIxsCVaD H/zdl2MXZdwEZItQ7dGTWi02kLz3XIS6OTR3la7UqajeI64fFDUrQTWY/21SmQf7 08OtIKj4qowvbazbXEGUVVnI9bd3VH9q0b5Au2LMt/vLE9NVSpO6i3P/wPSrKL0= =WBUV -----END PGP SIGNATURE----- --------------enig5D96E0525AAB0B5F06460232-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:00:12 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD98BDE4; Sun, 6 Jan 2013 16:00:12 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8E92A75B; Sun, 6 Jan 2013 16:00:12 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Trsdv-0006BF-6f>; Sun, 06 Jan 2013 17:00:11 +0100 Received: from e178035121.adsl.alicedsl.de ([85.178.35.121] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Trsdv-002Rat-33>; Sun, 06 Jan 2013 17:00:11 +0100 Message-ID: <50E99F89.6010802@zedat.fu-berlin.de> Date: Sun, 06 Jan 2013 17:00:09 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! References: <50E97457.7050809@zedat.fu-berlin.de> <50E98FB2.5040304@FreeBSD.org> In-Reply-To: <50E98FB2.5040304@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig489B11C016A90294F75B7530" X-Originating-IP: 85.178.35.121 Cc: Current FreeBSD , Brooks Davis , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 16:00:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig489B11C016A90294F75B7530 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Am 01/06/13 15:52, schrieb Dimitry Andric: > On 2013-01-06 13:55, O. Hartmann wrote: >> While working with an OpenCL port that is depending on LLVM 3.2, I fee= l >> very uncomfortable haveng to have devel/llvm-devel installed while the= >> official release of LLVM is 3.2. >=20 > Please prod the port maintainer (Brooks) to update the llvm port > instead. I have CC'd him on this mail. >=20 >=20 >> The port devel/llvm is still the older >> 3.1. Is this going to be changed? >=20 > Obviously, but this is at the discretion of the port maintainer. If > Brooks needs more time, then you will have be a little patient. Also > please remember that ports just came out of feature freeze. >=20 I also filed a PR ( http://www.freebsd.org/cgi/query-pr.cgi?pr=3D175059). It seems, that the port devel/llvm-devel also misses some pieces of the most recent LLVM 3.2, as it is needed to compile POCL properly, but I leave this with the experts to change. I try to follow a logical path: devel/llvm represents the recent release, while devel/llvm-devel should be the development branch, 3.3 by now. I do not know whether we need LLVM 3.1 any more, since apart from the POCL device driver backend via LLVM for OpenCL target I know about nothing in the FreeBSD realm by now using LLVM. I might be wrong ... So, I see forward to hear from the decissions made ;-) Oliver --------------enig489B11C016A90294F75B7530 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ6Z+JAAoJEOgBcD7A/5N82SAH/RoV1FoknW033dLIznEBFlqF c0sPC3sGPnAxjwmMQeneZu5DzlSGIFKv6Ta2sfMxAfhChqFcB6qPICjfDioAusoG 0RKdLyn9ChVOVEe4JjFXgCaUUDmWzrb5FVeipJKnBybrdy9P8QHnhePbvHjV0Rcx dIp+BUYsBHYMg69Usaf3ZwjBlUsqqPbE26LBZE7M9/3PjbiXCH0tS4z4grOT0y3W 5Mtz1Du8dPLadmbCiLvFM1Ox3SNM5bSmJEarBjS+GUB4gLLEf+r06cNxn/KnNEmd 1QvHC6ssHsqXUa07U6mTkWcNgOhVAtV3rBNJQ4BZXPKucXg1nSqRH3Ca4M4J4iI= =MrVA -----END PGP SIGNATURE----- --------------enig489B11C016A90294F75B7530-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:03:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6884DF9C; Sun, 6 Jan 2013 16:03:36 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep16.mx.upcmail.net (fep16.mx.upcmail.net [62.179.121.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3985B784; Sun, 6 Jan 2013 16:03:34 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep16-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130106160333.MHHL29828.viefep16-int.chello.at@edge04.upcmail.net>; Sun, 6 Jan 2013 17:03:33 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id kg3Y1k01M2xdvHc04g3Y4V; Sun, 06 Jan 2013 17:03:33 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 9F0456D449; Sun, 6 Jan 2013 17:03:32 +0100 (CET) Date: Sun, 6 Jan 2013 17:03:32 +0100 From: Stefan Farfeleder To: Dimitry Andric Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130106160331.GB1418@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E9916F.3040500@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 16:03:36 -0000 On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: > On 2013-01-06 15:17, Stefan Farfeleder wrote: > > On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: > >> Here's a minimal test case that reproduces the bug: > > [...] > > > > Until someone fixes this bug, could we apply something like this as a > > work-around? > > > > Stefan > > > > Index: gnu/lib/libgcc/Makefile > > =================================================================== > > --- gnu/lib/libgcc/Makefile (revision 245055) > > +++ gnu/lib/libgcc/Makefile (working copy) > > @@ -6,6 +6,8 @@ > > SHLIB_NAME= libgcc_s.so.1 > > SHLIBDIR?= /lib > > > > +CC= gcc > > + > > .include > > I think this is a bit overkill approach. We still don't know what the > exact cause of the problem is, and this just papers over it. It seems unwise to install a known-to-be-broken libgcc by default, even though the exact cause is not known yet. > Also, ince the bug is only reproducible by compiling the testcase with > g++, could you not compile your crashing programs with clang instead, > for now? :-) The bug also affects ports software, e.g., I also experienced strange rtorrent segfaults that are now gone. Stefan From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:29:44 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 43CCD598; Sun, 6 Jan 2013 16:29:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 92CCA821; Sun, 6 Jan 2013 16:29:42 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 80B4273027; Sun, 6 Jan 2013 17:20:49 +0100 (CET) Date: Sun, 6 Jan 2013 17:20:49 +0100 From: Luigi Rizzo To: Marius Strobl Subject: Re: [RFC/RFT] calloutng Message-ID: <20130106162049.GA3640@onelab2.iet.unipi.it> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130106152313.GD26039@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Alexander Motin , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 16:29:44 -0000 On Sun, Jan 06, 2013 at 04:23:13PM +0100, Marius Strobl wrote: > On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote: > > On 26.12.2012 01:21, Marius Strobl wrote: > > > On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote: > > >> Experiments with dummynet shown ineffective support for very short > > >> tick-based callouts. New version fixes that, allowing to get as many > > >> tick-based callout events as hz value permits, while still be able to > > >> aggregate events and generating minimum of interrupts. > > >> > > >> Also this version modifies system load average calculation to fix some > > >> cases existing in HEAD and 9 branches, that could be fixed with new > > >> direct callout functionality. > > >> > > >> http://people.freebsd.org/~mav/calloutng_12_17.patch > > >> > > >> With several important changes made last time I am going to delay commit > > >> to HEAD for another week to do more testing. Comments and new test cases > > >> are welcome. Thanks for staying tuned and commenting. > > > > > > FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a > > > try on sparc64 and it at least survives a buildworld there. However, > > > with the patched kernels, buildworld times seem to increase slightly but > > > reproducible by 1-2% (I only did four runs but typically buildworld > > > times are rather stable and don't vary more than a minute for the > > > same kernel and source here). Is this an expected trade-off (system > > > time as such doesn't seem to increase)? > > > > I don't think build process uses significant number of callouts to > > affect results directly. I think this additional time could be result of > > the deeper next event look up, done by the new code, that is practically > > useless for sparc64, which effectively has no cpu_idle() routine. It > > wouldn't affect system time and wouldn't show up in any statistics > > (except PMC or something alike) because it is executed inside timer > > hardware interrupt handler. If my guess is right, that is a part that > > probably still could be optimized. I'll look on it. Thanks. > > > > > Is there anything specific to test? > > > > Since the most of code is MI, for sparc64 I would mostly look on related > > MD parts (eventtimers and timecounters) to make sure they are working > > reliably in more stressful conditions. I still have some worries about > > possible deadlock on hardware where IPIs are used to fetch present time > > from other CPU. > > Well, I've just learnt two things the hard way: > a) We really need the mutex in that path. > b) Assuming that the initial synchronization of the counters is good > enough and they won't drift considerably accross the CPUs so we can > always use the local one makes things go south pretty soon after > boot. At least with your calloutng_12_26.patch applied. > > I'm not really sure what to do about that. Earlier you already said > that sched_bind(9) also isn't an option in case if td_critnest > 1. > To be honest, I don't really unerstand why using a spin lock in the > timecounter path makes sparc64 the only problematic architecture > for your changes. The x86 i8254_get_timecount() also uses a spin lock > so it should be in the same boat. > > The affected machines are equipped with a x86-style south bridge > which exposes a powermanagment unit (intended to be used as a SMBus > bridge only in these machines) on the PCI bus. Actually, this device > also includes an ACPI power management timer. However, I've just > spent a day trying to get that one working without success - it > just doesn't increment. Probably its clock input isn't connected as > it's not intended to be used in these machines. > That south bridge also includes 8254 compatible timers on the ISA/ > LPC side, but are hidden from the OFW device tree. I can hack these > devices into existence and give it a try, but even if that works this > likely would use the same code as the x86 i8254_get_timecount() so I > don't see what would be gained with that. > > The last thing in order to avoid using the tick counter as timecounter > in the MP case I can think of is that the Broadcom MACs in the affected > machines also provide a counter driven by a 1 MHz clock. If that's good > enough for a timecounter I can hook these up (in case these work ...) > and hack bge(4) to not detach in that case (given that we can't detach > timecounters ...). > > > > > Here is small tool we are using for test correctness and performance of > > different user-level APIs: http://people.freebsd.org/~mav/testsleep.c > > > > I've run Ian's set of tests on a v215 with and without your > calloutng_12_26.patch and on a v210 (these uses the IPI approach) > with the latter also applied. > I'm not really sure what to make out of the numbers. > > v215 w/o v215 w/ v210 w/ > ---------- ---------------- ---------------- ---------------- > select 1 1999.61 1 23.87 1 29.97 > poll 1 1999.70 1 1069.61 1 1075.24 > usleep 1 1999.86 1 23.43 1 28.99 > nanosleep 1 999.92 1 23.28 1 28.66 > kqueue 1 1000.12 1 1071.13 1 1076.35 > kqueueto 1 999.56 1 26.33 1 31.34 > syscall 1 1.89 1 1.92 1 2.88 > select 300 1999.72 300 326.08 300 332.24 > poll 300 1999.12 300 1069.78 300 1075.82 > usleep 300 1999.91 300 325.63 300 330.94 > nanosleep 300 999.82 300 23.25 300 26.76 > kqueue 300 1000.14 300 1071.06 300 1075.96 > kqueueto 300 999.53 300 26.32 300 31.42 > syscall 300 1.90 300 1.93 300 2.89 > select 3000 3998.18 3000 3176.51 3000 3193.86 > poll 3000 3999.29 3000 3182.21 3000 3193.12 > usleep 3000 3998.46 3000 3191.60 3000 3192.50 > nanosleep 3000 1999.79 3000 23.21 3000 27.02 > kqueue 3000 3000.12 3000 3189.13 3000 3191.96 > kqueueto 3000 1999.99 3000 26.28 3000 31.91 > syscall 3000 1.91 3000 1.91 3000 2.90 > select 30000 30990.85 30000 31489.18 30000 31548.77 > poll 30000 30995.25 30000 31518.80 30000 31487.92 > usleep 30000 30992.00 30000 31510.42 30000 31475.50 > nanosleep 30000 1999.46 30000 38.67 30000 41.95 > kqueue 30000 30006.49 30000 30991.86 30000 30996.77 > kqueueto 30000 1999.09 30000 41.67 30000 46.36 > syscall 30000 1.91 30000 1.91 30000 2.88 > select 300000 300990.65 300000 301864.98 300000 301787.01 > poll 300000 300998.09 300000 301831.36 300000 301741.62 > usleep 300000 300990.80 300000 301824.67 300000 301770.10 > nanosleep 300000 1999.15 300000 325.74 300000 331.01 > kqueue 300000 300000.87 300000 301031.11 300000 300992.28 > kqueueto 300000 1999.39 300000 328.77 300000 333.45 > syscall 300000 1.91 300000 1.91 300000 2.88 the nanosleep and kqueueto tests are probably passing the wrong argument to the syscall (meant to be microseconds, but nanosleep takes nanosecond so it should probably be multiplied by 1000). I think that for the time being it would be useful to run at least one set of tests with kern.timecounter.alloweddeviation=0 so we can tell how close we get to the required timeouts cheers luigi > Marius > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:39:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1DAB6BF2 for ; Sun, 6 Jan 2013 16:39:45 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id E926389C for ; Sun, 6 Jan 2013 16:39:44 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MG700800QA2CB00@smtpauth2.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sun, 06 Jan 2013 10:39:38 -0600 (CST) Received: from wanderer.tachypleus.net (dhcp107-17-54-205.hil-sfofhhh.sfo.wayport.net [107.17.54.205]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MG70057NQA0R710@smtpauth2.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sun, 06 Jan 2013 10:39:37 -0600 (CST) Date: Sun, 06 Jan 2013 11:39:35 -0500 From: Nathan Whitehorn Subject: Re: clang 3.2 RC2 miscompiles libgcc? In-reply-to: <50E99848.6090209@freebsd.org> Sender: whitehorn@wisc.edu To: freebsd-current@freebsd.org Message-id: <50E9A8C7.40600@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=107.17.54.205 X-Spam-PmxInfo: Server=avs-16, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.6.163017, SenderIP=107.17.54.205 References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <50E99848.6090209@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 16:39:45 -0000 On 01/06/13 10:29, Nathan Whitehorn wrote: > On 01/06/13 09:59, Dimitry Andric wrote: >> On 2013-01-06 15:17, Stefan Farfeleder wrote: >>> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: >>>> Here's a minimal test case that reproduces the bug: >>> [...] >>> >>> Until someone fixes this bug, could we apply something like this as a >>> work-around? >>> >>> Stefan >>> >>> Index: gnu/lib/libgcc/Makefile >>> =================================================================== >>> --- gnu/lib/libgcc/Makefile (revision 245055) >>> +++ gnu/lib/libgcc/Makefile (working copy) >>> @@ -6,6 +6,8 @@ >>> SHLIB_NAME= libgcc_s.so.1 >>> SHLIBDIR?= /lib >>> >>> +CC= gcc >>> + >>> .include >> >> I think this is a bit overkill approach. We still don't know what the >> exact cause of the problem is, and this just papers over it. >> >> Also, ince the bug is only reproducible by compiling the testcase with >> g++, could you not compile your crashing programs with clang instead, >> for now? :-) >> > > I would very much support this patch. Whatever is going wrong is a > critical problem -- although his testcase requires g++, I have lots of > code that also crashes when built with clang. The fact that *any* code > built with *any* compiler crashes when used with clang-built libgcc is > an error. This is quite serious and breaks a *lot* of C++ code. If it > can't be fixed now, papering it over is required. > -Nathan For whatever it's worth, I verified that this is the same bug I was seeing earlier: only unwind-dw2.c is being miscompiled. The preprocessed versions of this file are identical with both gcc and clang and the problem occurs at all optimization levels with it is built with clang. I tried replacing as many of the __builtin functions as a could with thunks to the gcc versions, with no positive result. The ones I could not replace are __builtin_return_address, __builtin_dwarf_cfa, and __builtin_eh_return. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:46:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9A452D3B; Sun, 6 Jan 2013 16:46:38 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4A21D8D0; Sun, 6 Jan 2013 16:46:37 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r06GkTQf033234 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 6 Jan 2013 16:46:30 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: clang 3.2 RC2 miscompiles libgcc? Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20130106141708.GA1418@mole.fafoe.narf.at> Date: Sun, 6 Jan 2013 16:46:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> To: Stefan Farfeleder X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@FreeBSD.org, Dimitry Andric , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 16:46:38 -0000 On 6 Jan 2013, at 14:17, Stefan Farfeleder wrote: > On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: >> Here's a minimal test case that reproduces the bug: > [...] >=20 > Until someone fixes this bug, could we apply something like this as a > work-around? >=20 > Stefan >=20 > Index: gnu/lib/libgcc/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- gnu/lib/libgcc/Makefile (revision 245055) > +++ gnu/lib/libgcc/Makefile (working copy) > @@ -6,6 +6,8 @@ > SHLIB_NAME=3D libgcc_s.so.1 > SHLIBDIR?=3D /lib >=20 > +CC=3D gcc > + > .include > # > # libgcc is linked in last and thus cannot depend on ssp symbols = coming This will break the build entirely for those of us who build without = gcc, and as we are planning on removing gcc entirely by the 10.0 = timeframe we should be encouraging people to do this, not discouraging = it. Does compiling at a lower optimisation level (-O1? -O0) work as a = temporary fix? David From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:48:55 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED3F7E5A; Sun, 6 Jan 2013 16:48:55 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id C4BD98EA; Sun, 6 Jan 2013 16:48:55 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MG700800QPJYW00@smtpauth2.wiscmail.wisc.edu>; Sun, 06 Jan 2013 10:48:55 -0600 (CST) Received: from wanderer.tachypleus.net (dhcp107-17-54-205.hil-sfofhhh.sfo.wayport.net [107.17.54.205]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MG7005HGQPHR710@smtpauth2.wiscmail.wisc.edu>; Sun, 06 Jan 2013 10:48:54 -0600 (CST) Date: Sun, 06 Jan 2013 11:48:52 -0500 From: Nathan Whitehorn Subject: Re: clang 3.2 RC2 miscompiles libgcc? In-reply-to: Sender: whitehorn@wisc.edu To: David Chisnall Message-id: <50E9AAF4.209@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=107.17.54.205 X-Spam-PmxInfo: Server=avs-15, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.6.163615, SenderIP=107.17.54.205 References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 Cc: Stefan Farfeleder , Dimitry Andric , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 16:48:56 -0000 On 01/06/13 11:46, David Chisnall wrote: > On 6 Jan 2013, at 14:17, Stefan Farfeleder wrote: > >> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: >>> Here's a minimal test case that reproduces the bug: >> [...] >> >> Until someone fixes this bug, could we apply something like this as a >> work-around? >> >> Stefan >> >> Index: gnu/lib/libgcc/Makefile >> =================================================================== >> --- gnu/lib/libgcc/Makefile (revision 245055) >> +++ gnu/lib/libgcc/Makefile (working copy) >> @@ -6,6 +6,8 @@ >> SHLIB_NAME= libgcc_s.so.1 >> SHLIBDIR?= /lib >> >> +CC= gcc >> + >> .include >> # >> # libgcc is linked in last and thus cannot depend on ssp symbols coming > > This will break the build entirely for those of us who build without gcc, and as we are planning on removing gcc entirely by the 10.0 timeframe we should be encouraging people to do this, not discouraging it. > > Does compiling at a lower optimisation level (-O1? -O0) work as a temporary fix? > No. It's completely broken at all optimization levels. There do not appear to be any flags that change the behavior. Building unwind-dw2.c either with gcc or with the previous import of clang in our tree does fix it, however. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:49:41 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B829BF66; Sun, 6 Jan 2013 16:49:41 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 85F7C8F9; Sun, 6 Jan 2013 16:49:40 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r06GnbRW033249 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 6 Jan 2013 16:49:39 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <50E97457.7050809@zedat.fu-berlin.de> Date: Sun, 6 Jan 2013 16:49:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <34476030-BDBF-46C4-8E7D-60FDC53B076A@FreeBSD.org> References: <50E97457.7050809@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1278) Cc: Current FreeBSD , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 16:49:41 -0000 On 6 Jan 2013, at 12:55, O. Hartmann wrote: > Having a crippled LLVM aboard AND the need having installed a port is = a > kind of none-sense. Why should I install port devel/llvm to have a > working LLVM backend? The issue is the same as the issue for anything in the FreeBSD base = system, which is: what level of compatibility do we want to provide? In general, we aim to provide a backwards-compatible ABI across an = entire major release. This means that anything that runs on 9.0 should = work on 9.1 and so on. It should also work on 10.x with the relevant = compat packages installed. In contrast, LLVM changes the ABI (and API!) significantly between point = releases. We therefore don't want to encourage anything outside of the = base system to link against these libraries, because doing so would = prevent us from importing a new LLVM release every six months - we'd = either need to ship 4 copies of LLVM by an x.3 release, or stick with = the one that we shipped in x.0. There is no problem with other base-system tools linking against the = base system LLVM libraries, but in this case llvm-config does not need = to be installed (and neither do the LLVM headers), because such tools = will be built as part of the base system itself. David= From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:51:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E162254; Sun, 6 Jan 2013 16:51:14 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 308F191E; Sun, 6 Jan 2013 16:51:13 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r06GpBe9033259 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 6 Jan 2013 16:51:12 GMT (envelope-from theraven@freebsd.org) Subject: Re: clang 3.2 RC2 miscompiles libgcc? Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <50E9AAF4.209@freebsd.org> Date: Sun, 6 Jan 2013 16:51:11 +0000 Content-Transfer-Encoding: 7bit Message-Id: <78AC11F6-7AAE-449D-9ED1-DB5B207152DA@freebsd.org> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9AAF4.209@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1278) Cc: Stefan Farfeleder , Dimitry Andric , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 16:51:14 -0000 On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote: > No. It's completely broken at all optimization levels. There do not > appear to be any flags that change the behavior. Building unwind-dw2.c > either with gcc or with the previous import of clang in our tree does > fix it, however. Do you have an LLVM PR# for this that I can follow? David From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 17:25:30 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AE64B81D; Sun, 6 Jan 2013 17:25:30 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 42E84A8A; Sun, 6 Jan 2013 17:25:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TrtyS-000H2R-CF>; Sun, 06 Jan 2013 18:25:28 +0100 Received: from e178035121.adsl.alicedsl.de ([85.178.35.121] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TrtyS-002WL2-8Q>; Sun, 06 Jan 2013 18:25:28 +0100 Message-ID: <50E9B385.9060104@zedat.fu-berlin.de> Date: Sun, 06 Jan 2013 18:25:25 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Chisnall Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! References: <50E97457.7050809@zedat.fu-berlin.de> <34476030-BDBF-46C4-8E7D-60FDC53B076A@FreeBSD.org> In-Reply-To: <34476030-BDBF-46C4-8E7D-60FDC53B076A@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA526349AD859E1AE0F9E4874" X-Originating-IP: 85.178.35.121 Cc: Current FreeBSD , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 17:25:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA526349AD859E1AE0F9E4874 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 01/06/13 17:49, schrieb David Chisnall: > On 6 Jan 2013, at 12:55, O. Hartmann wrote: >=20 >> Having a crippled LLVM aboard AND the need having installed a port is = a >> kind of none-sense. Why should I install port devel/llvm to have a >> working LLVM backend? >=20 > The issue is the same as the issue for anything in the FreeBSD base sys= tem, which is: what level of compatibility do we want to provide? >=20 > In general, we aim to provide a backwards-compatible ABI across an enti= re major release. This means that anything that runs on 9.0 should work = on 9.1 and so on. It should also work on 10.x with the relevant compat p= ackages installed. >=20 > In contrast, LLVM changes the ABI (and API!) significantly between poin= t releases. We therefore don't want to encourage anything outside of the= base system to link against these libraries, because doing so would prev= ent us from importing a new LLVM release every six months - we'd either n= eed to ship 4 copies of LLVM by an x.3 release, or stick with the one tha= t we shipped in x.0. Indeed, this is a serious point and the developer of LLVM has to be blamed for that. >=20 > There is no problem with other base-system tools linking against the ba= se system LLVM libraries, but in this case llvm-config does not need to b= e installed (and neither do the LLVM headers), because such tools will be= built as part of the base system itself. llvm-config is simply as an example. It shows up the first when the build of POCL fails, so I have chossen it to be checked for as the relevant dependency - it was a hunch for the port Makefile I intend to provide. Since I was more focused on having POCL running for my OpenCL moveon on FreeBSD, I wasn't very careful about choosing what to check against. I will change this before I will send the port to be reviewed and revised. >=20 > David > _______________________________________________ --------------enigA526349AD859E1AE0F9E4874 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ6bOHAAoJEOgBcD7A/5N8FzsIAIsW0yvH86ww2TbR39HGfkQJ L8RijWC2MJLSDfd2iZQy3pKm/ejMLRMyyYBsIx1uD6wEuPOVHmAtRaFTqpGJ+mlN dtodo58uG3Iw+/g0sLbx7HMi8Kc+Lv2xMHSRnsZJvib4vvH7ofN0fNUfeedVczut 000lkM2z8mOcq4LDWORJPRmlVBqJAWGDUgKe76aMDnYpZrU2Gwv+GKj0EwX+U2VU sulyYx8PL0Sk4Sa5VwiJTtrNsKEx3nwhAzN95Q2SQwVV6EDLx5T8b9lWSvn9CB/u n7gO+aa+T5qK4gQEaVqDCSzsiSLHdB70J/UOJ464szKNyhLtLtIM396KLGExmvc= =Rk8T -----END PGP SIGNATURE----- --------------enigA526349AD859E1AE0F9E4874-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 20:21:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF9BEC86; Sun, 6 Jan 2013 20:21:42 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by mx1.freebsd.org (Postfix) with ESMTP id 8729016C6; Sun, 6 Jan 2013 20:21:42 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c13so22487109ieb.3 for ; Sun, 06 Jan 2013 12:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C6P3aHcR4kW3G5URdgBvPp7Fb+He3uzz9OwIzHsC98c=; b=q6kcgv17riIpXPlT2F9xm7zJLsEAVQgkmQlhLXNj1bC9pAG+bGA9NsI8gcEwcJtP+Y DV3+qfoaIFdm/gUjAQ2+g/VpRIcZB/nJr8RH8B7PWdKzsHaPi3UFm/t+thkuRMm4nT4N 3HvskRh8J4/S0dmdjwY3Px36rhiyXLS9t+bhiGPaaHfzygP6WNZMIhK2x6dUZC1/8OYO auTX1TbFhdxDz+P53EA363rZNbZk4xVgwW0WwaYxo8fdesSNzkG0P3ggCEtRWzcQ8IRN WFMD2zEvUoFvaU99+tEwczRGdc/4q/QsZROKJrsYOJ+eJhl8Rz8IHrTf9nHU78Zo28rB AjTw== MIME-Version: 1.0 X-Received: by 10.50.202.97 with SMTP id kh1mr4177070igc.15.1357503696535; Sun, 06 Jan 2013 12:21:36 -0800 (PST) Received: by 10.64.65.132 with HTTP; Sun, 6 Jan 2013 12:21:36 -0800 (PST) Received: by 10.64.65.132 with HTTP; Sun, 6 Jan 2013 12:21:36 -0800 (PST) In-Reply-To: References: <50E97457.7050809@zedat.fu-berlin.de> <0900DD62-3A21-4D77-8B5B-7976ACB3921B@cederstrand.dk> <50E990DD.5040605@FreeBSD.org> Date: Sun, 6 Jan 2013 20:21:36 +0000 Message-ID: Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! From: Chris Rees To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Current FreeBSD , "O. Hartmann" , Erik Cederstrand , FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 20:21:42 -0000 On 6 Jan 2013 14:57, "Dimitry Andric" wrote: > > On 2013-01-06 15:16, Erik Cederstrand wrote: > ... > >> I think the real problem is that LLVM and the related tools are build in one go, so you can't easily build llvm-config and others for the base version of LLVM. > > > Well, it would be easy enough to build llvm-config, but what should its > output be? We do not install llvm/clang headers or libraries into the > system, so llvm-config would not give any meaningful -I or -L flags. :) > > > >> llvm-config needs shared libraries that are not installed in base because they supposedly require a prohibitive amount of build time. > > > Again, build time is not the problem. The libraries are already built, > but in static form; making them dynamic would not be that difficult, but > installing them would add another maintenance and compatibility burden. > > > >> The LLVM port could be split up instead. There could be a devel/llvm-libs port that installed the shared libs for the base LLVM, and then a devel/llvm-config, devel/scan-build or devel/mclinker port that depends on the former port. > > > Yes, this seems to be the proper approach. But, as far as I understand, > the ports system cannot yet do one work tree build, and package that up > in different packages, such as -libs, -devel, and so on. No, but it can be done if the parts are compiled separately, =E0 la postgresql-* ports. Is this definitely impossible? It's crudely but effectively done with pgsql by only running make in certain directories... Chris From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 20:38:15 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5CFD2FD4; Sun, 6 Jan 2013 20:38:15 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2311D1735; Sun, 6 Jan 2013 20:38:14 +0000 (UTC) Received: from [192.168.1.44] (unknown [176.222.238.90]) by csmtp3.one.com (Postfix) with ESMTPA id C84DA24068F5; Sun, 6 Jan 2013 20:38:12 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! From: Erik Cederstrand In-Reply-To: <50E9B385.9060104@zedat.fu-berlin.de> Date: Sun, 6 Jan 2013 21:38:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> References: <50E97457.7050809@zedat.fu-berlin.de> <34476030-BDBF-46C4-8E7D-60FDC53B076A@FreeBSD.org> <50E9B385.9060104@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1499) Cc: Current FreeBSD , David Chisnall , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 20:38:15 -0000 Den 06/01/2013 kl. 18.25 skrev "O. Hartmann" = : >> In contrast, LLVM changes the ABI (and API!) significantly between = point releases. We therefore don't want to encourage anything outside = of the base system to link against these libraries, because doing so = would prevent us from importing a new LLVM release every six months - = we'd either need to ship 4 copies of LLVM by an x.3 release, or stick = with the one that we shipped in x.0. >=20 > Indeed, this is a serious point and the developer of LLVM has to be > blamed for that. You can't seriously blame LLVM for making progress. If ports rely on a = specific version of LLVM, it would be far better to create devel/llvm31, = devel/llvm32 etc. Erik= From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 22:37:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B154D3A5; Sun, 6 Jan 2013 22:37:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 72D3E1B66; Sun, 6 Jan 2013 22:37:49 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b477:ff2d:fc59:6c40] (unknown [IPv6:2001:7b8:3a7:0:b477:ff2d:fc59:6c40]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5E5275C37; Sun, 6 Jan 2013 23:37:47 +0100 (CET) Message-ID: <50E9FCB9.2000805@FreeBSD.org> Date: Sun, 06 Jan 2013 23:37:45 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Erik Cederstrand Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! References: <50E97457.7050809@zedat.fu-berlin.de> <34476030-BDBF-46C4-8E7D-60FDC53B076A@FreeBSD.org> <50E9B385.9060104@zedat.fu-berlin.de> <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> In-Reply-To: <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Chisnall , Current FreeBSD , "O. Hartmann" , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 22:37:49 -0000 On 2013-01-06 21:38, Erik Cederstrand wrote: > Den 06/01/2013 kl. 18.25 skrev "O. Hartmann" : >>> In contrast, LLVM changes the ABI (and API!) significantly between point releases. We therefore don't want to encourage anything outside of the base system to link against these libraries, because doing so would prevent us from importing a new LLVM release every six months - we'd either need to ship 4 copies of LLVM by an x.3 release, or stick with the one that we shipped in x.0. >> Indeed, this is a serious point and the developer of LLVM has to be >> blamed for that. > You can't seriously blame LLVM for making progress. If ports rely on a specific version of LLVM, it would be far better to create devel/llvm31, devel/llvm32 etc. Yes, I think that is probably the most effective approach. It should also be possible to install multiple versions simultaneously. From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 23:07:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 584AB823 for ; Sun, 6 Jan 2013 23:07:53 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 242F81C43 for ; Sun, 6 Jan 2013 23:07:52 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TrzJn-00016h-SM for freebsd-current@freebsd.org; Sun, 06 Jan 2013 15:07:51 -0800 Date: Sun, 6 Jan 2013 15:07:51 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1357513671871-5775300.post@n5.nabble.com> In-Reply-To: <50E9FCB9.2000805@FreeBSD.org> References: <50E97457.7050809@zedat.fu-berlin.de> <34476030-BDBF-46C4-8E7D-60FDC53B076A@FreeBSD.org> <50E9B385.9060104@zedat.fu-berlin.de> <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> <50E9FCB9.2000805@FreeBSD.org> Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 23:07:53 -0000 While it is only remotely related, it looks like MFC of 3.2 for STABLE should be around the corner? -- View this message in context: http://freebsd.1045724.n5.nabble.com/LLVM-3-2-official-stable-port-is-still-LLVM-3-1-Basesystem-missing-important-LLVM-pieces-tp5775141p5775300.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 07:37:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 883EC721 for ; Mon, 7 Jan 2013 07:37:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2BEC5F7A for ; Mon, 7 Jan 2013 07:37:31 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:406f:4ff9:6789:6380] (unknown [IPv6:2001:7b8:3a7:0:406f:4ff9:6789:6380]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 214235C37; Mon, 7 Jan 2013 08:37:30 +0100 (CET) Message-ID: <50EA7B38.9010604@FreeBSD.org> Date: Mon, 07 Jan 2013 08:37:28 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Jakub Lach Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! References: <50E97457.7050809@zedat.fu-berlin.de> <34476030-BDBF-46C4-8E7D-60FDC53B076A@FreeBSD.org> <50E9B385.9060104@zedat.fu-berlin.de> <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> <50E9FCB9.2000805@FreeBSD.org> <1357513671871-5775300.post@n5.nabble.com> In-Reply-To: <1357513671871-5775300.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 07:37:32 -0000 On 2013-01-07 00:07, Jakub Lach wrote: > While it is only remotely related, it looks like MFC of 3.2 for STABLE > should be around the corner? I'm postponing the MFC of 3.2, until we find the exact cause of the libgcc problem (1). -Dimitry 1) http://lists.freebsd.org/pipermail/freebsd-current/2012-December/038766.html From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 08:10:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 21AFABD6; Mon, 7 Jan 2013 08:10:44 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id D596CE3; Mon, 7 Jan 2013 08:10:42 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep15-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130107081034.NJYV2598.viefep15-int.chello.at@edge04.upcmail.net>; Mon, 7 Jan 2013 09:10:34 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id kwAa1k00f2xdvHc04wAaPG; Mon, 07 Jan 2013 09:10:34 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 5569C6D47C; Mon, 7 Jan 2013 09:10:34 +0100 (CET) Date: Mon, 7 Jan 2013 09:10:34 +0100 From: Stefan Farfeleder To: David Chisnall Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130107081033.GA1446@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9AAF4.209@freebsd.org> <78AC11F6-7AAE-449D-9ED1-DB5B207152DA@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78AC11F6-7AAE-449D-9ED1-DB5B207152DA@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Dimitry Andric , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 08:10:44 -0000 On Sun, Jan 06, 2013 at 04:51:11PM +0000, David Chisnall wrote: > On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote: > > > No. It's completely broken at all optimization levels. There do not > > appear to be any flags that change the behavior. Building unwind-dw2.c > > either with gcc or with the previous import of clang in our tree does > > fix it, however. > > Do you have an LLVM PR# for this that I can follow? There's http://llvm.org/bugs/show_bug.cgi?id=8541 which I think should be reopened. Stefan From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 08:29:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5287BE55 for ; Mon, 7 Jan 2013 08:29:36 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from mx.lissyara.su (mx.lissyara.su [91.227.18.11]) by mx1.freebsd.org (Postfix) with ESMTP id E9E9F167 for ; Mon, 7 Jan 2013 08:29:35 +0000 (UTC) Received: from [79.164.58.122] (port=56393 helo=dc7700p.lissyara.su) by mx.lissyara.su with esmtpa (Exim 4.80 (FreeBSD)) (envelope-from ) id 1Ts85H-0005MZ-KJ for current@freebsd.org; Mon, 07 Jan 2013 12:29:27 +0400 Message-ID: <50EA8766.3020500@lissyara.su> Date: Mon, 07 Jan 2013 12:29:26 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: current@freebsd.org Subject: Re: fsck problem References: <201301062315.r06NFgH4065878@chez.mckusick.com> In-Reply-To: <201301062315.r06NFgH4065878@chez.mckusick.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: mx.lissyara.su X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 08:29:36 -0000 07.01.2013 03:15, Kirk McKusick ïèøåò: >> Date: Wed, 02 Jan 2013 00:46:53 +0400 >> From: Alex Keda >> To: current@freebsd.org >> Subject: fsck problem >> >> so, whats reason for use SUJ? > > SUJ is used to speed up the fsck process. If you have had hard disk > errors then it is not able to recover and you need to run fsck in the > old full-fsck way. > > It is not necessary to disable the journal. If fsck runs and fails > it marks the journal as failed so when you rerun fsck it will > run in the old full-fsck mode. Note that running `fsck -y' is not > recommended as that says make this filesystem clean no matter what. > So while you will end up with a clean filesystem, it may be empty > if you had a bad block in the root directory. Instead you should > run fsck and read and think about the questions rather than just > blindly answering them all yes. it's HDD not have bad blocks - it's hardware RAID10 I run fsck -y more than 3 time, before disable journal. it's can't fix error, with enabled journal and, I see it's error not first time. From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 09:39:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 070CE2B0; Mon, 7 Jan 2013 09:39:39 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id CC3E46AB; Mon, 7 Jan 2013 09:39:38 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r079dHSr037219 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 7 Jan 2013 09:39:35 GMT (envelope-from theraven@freebsd.org) Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> Date: Mon, 7 Jan 2013 09:39:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <410ACCF2-D1E6-45D9-AF93-B5625682644A@freebsd.org> References: <50E97457.7050809@zedat.fu-berlin.de> <34476030-BDBF-46C4-8E7D-60FDC53B076A@FreeBSD.org> <50E9B385.9060104@zedat.fu-berlin.de> <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> To: Erik Cederstrand X-Mailer: Apple Mail (2.1278) Cc: Current FreeBSD , "O. Hartmann" , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:39:39 -0000 On 6 Jan 2013, at 20:38, Erik Cederstrand wrote: > You can't seriously blame LLVM for making progress. If ports rely on a = specific version of LLVM, it would be far better to create devel/llvm31, = devel/llvm32 etc. Well, I can (and, even with my LLVM committer hat on, do) blame LLVM for = not having a sensible deprecation strategy. Breaking the ABI is = unavoidable in a C++ project (unless you invent an entire metalanguage = on top of C++, as Qt does) but breaking the API is a huge pain, when it = would be no more effort in most cases to stick on a deprecation = attribute telling people what they should be using instead. Having llvm31, llvm32, and so on ports is likely to be unavoidable, as = lots of external projects end up depending on older versions of LLVM. = It would be worth splitting out clang from these. A few = refactoring-type tools depend on old versions of clang, but most = commonly people will be using latest clang with latest LLVM, plus = something else with old LLVM. =20 David= From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 10:20:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B6C5193 for ; Mon, 7 Jan 2013 10:20:24 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF3AB21 for ; Mon, 7 Jan 2013 10:20:23 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id t57so9510607wey.39 for ; Mon, 07 Jan 2013 02:20:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=bfzGJYe/LVh3VXW29O3nSw7dU0qQ0QufQ1lzRS6nQB0=; b=embaGmjxxBRa1hexol0UcoW3X2Caoj1KcHe3c+PELCllQ0/TgRQSOQUTzmTV/83GBF IkF0PHG1GUy1/VtQyFIcrVly9CcgYBCejp0vLfI/GWYkjABQf6gLjM4uQsnGbORtqsOO 1lnFT+GRQ2dWbfjd63aDpA3OSOeEJrE9RWf0Mn51h24vwxfmKaCDVrvmQJ7Chzf1E0P+ BUBq1YstAnqWzOUfVh0ToM/sGDsP6XX0bd0lLaq1jyHEbtGn7A9T3WzW+WKE350nzNg1 06CfAr1KoCgFDwgbk3ChMWk8YIuUZQLDaDmZR78EEgpQmNGoTqWOce6IgsDEYNqRbgnB N6Lw== X-Received: by 10.194.88.164 with SMTP id bh4mr79704477wjb.37.1357554016373; Mon, 07 Jan 2013 02:20:16 -0800 (PST) Received: from [192.168.1.123] (tui75-3-88-168-239-38.fbx.proxad.net. [88.168.239.38]) by mx.google.com with ESMTPS id p2sm12752956wic.7.2013.01.07.02.20.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Jan 2013 02:20:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance From: Fleuriot Damien In-Reply-To: Date: Mon, 7 Jan 2013 11:20:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <74D89D84-CC53-49A9-8D69-AF255A8323E0@my.gd> References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> To: Daniel Kalchev X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQl6Ju8cWbKfJOQ0K0UTHeh+c1ndAO6lB5D+augkdbsQJUb4jSI9bkLkvMRZs3MjjqBiSPLe Cc: Current FreeBSD , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 10:20:24 -0000 On Jan 7, 2013, at 11:14 AM, Daniel Kalchev wrote: >=20 > On Jan 4, 2013, at 4:06 PM, Fleuriot Damien wrote: >=20 >>=20 >> And network cards: >> # Up a bit our intel cards parameters >> hw.em.txd=3D4096 >> hw.em.rxd=3D4096 >> hw.em.tx_int_delay=3D512 >> hw.em.rx_int_delay=3D512 >> hw.em.tx_abs_int_delay=3D1024 >> hw.em.rx_abs_int_delay=3D1024 >>=20 >=20 > I am curious why we need to manually set up these values. Especially = the txd/rxd -- here are few controllers supported by the em driver that = can't handle 4096 descriptors and the choice could really be made at = driver attach time.. That could also permit different em interfaces in = the system (using different chips) to have different settings. >=20 > My belief is the auto tuning should set things up for maximum = performance, given the hardware and if someone really needs smaller = queues they could just use the tunables.=20 >=20 > Are there drawbacks? >=20 > Daniel Well perhaps the code to handle auto tuning isn't present in the driver = itself. I'm not a huge fan of the idea, I believe it would be rather taxing to = implement all the exceptions and that some could easily be overlooked. I believe it's better to have a more user-friendly documentation and let = users tune the hardware to suit their needs. From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 10:38:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16943658 for ; Mon, 7 Jan 2013 10:38:07 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 73263C1A for ; Mon, 7 Jan 2013 10:38:05 +0000 (UTC) Received: from [192.92.129.185] ([192.92.129.185]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id r07AFIR7072459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Jan 2013 12:15:19 +0200 (EET) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance From: Daniel Kalchev In-Reply-To: <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> Date: Mon, 7 Jan 2013 12:14:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> To: Fleuriot Damien X-Mailer: Apple Mail (2.1499) Cc: Current FreeBSD , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 10:38:07 -0000 On Jan 4, 2013, at 4:06 PM, Fleuriot Damien wrote: >=20 > And network cards: > # Up a bit our intel cards parameters > hw.em.txd=3D4096 > hw.em.rxd=3D4096 > hw.em.tx_int_delay=3D512 > hw.em.rx_int_delay=3D512 > hw.em.tx_abs_int_delay=3D1024 > hw.em.rx_abs_int_delay=3D1024 >=20 I am curious why we need to manually set up these values. Especially the = txd/rxd -- here are few controllers supported by the em driver that = can't handle 4096 descriptors and the choice could really be made at = driver attach time.. That could also permit different em interfaces in = the system (using different chips) to have different settings. My belief is the auto tuning should set things up for maximum = performance, given the hardware and if someone really needs smaller = queues they could just use the tunables.=20 Are there drawbacks? Daniel= From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 12:49:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 26793FF0 for ; Mon, 7 Jan 2013 12:49:51 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by mx1.freebsd.org (Postfix) with ESMTP id DA8C17F1 for ; Mon, 7 Jan 2013 12:49:50 +0000 (UTC) Received: by mail-vb0-f46.google.com with SMTP id b13so19021702vby.5 for ; Mon, 07 Jan 2013 04:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=QcaZlOiLTZEzwf55lmh0tbNtUh9x0rF8Ku/G/WZiokM=; b=c5dOn5mY7dL+nM9sAvpRxASpGzdpjTceW3jSTXyowjRIJMCmQznU5YXT9xkOyuLNFc HM/y637p9jE9/OyJrPfYL49t/ctICCRE0nPHCwLWPLgMT8DfFTk4tTikDQHn4RiQmMr7 qFRqowkvBRCLJsIjWglgx+GRv2mZisXoJlVUqDo6PXDYuyI97txHH+I3ALpTng4BcO2T Ly5Oofoy7fZKTr0rKXyYaeb8rwomSqD23Dx/RWfVpCH7nIrF8n951zfGjGlYqS/UJaSv iDAr5qDFQn1XvldHKcOH8/984bKXgj75tS0aqgCYBcTeTc2xSxQ4uA1lhTkNrsqdWH5K bZFA== Received: by 10.220.238.148 with SMTP id ks20mr82806591vcb.5.1357562984648; Mon, 07 Jan 2013 04:49:44 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.164.100 with HTTP; Mon, 7 Jan 2013 04:49:24 -0800 (PST) In-Reply-To: <74D89D84-CC53-49A9-8D69-AF255A8323E0@my.gd> References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> <74D89D84-CC53-49A9-8D69-AF255A8323E0@my.gd> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Mon, 7 Jan 2013 13:49:24 +0100 X-Google-Sender-Auth: QHTteTv3tfHBeNjpB90CGMmW5Rw Message-ID: Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance To: Fleuriot Damien Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Current FreeBSD , "O. Hartmann" , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 12:49:51 -0000 On Mon, Jan 7, 2013 at 11:20 AM, Fleuriot Damien wrote: > > > Well perhaps the code to handle auto tuning isn't present in the driver i= tself. > > I'm not a huge fan of the idea, I believe it would be rather taxing to im= plement all the exceptions and that some could easily be overlooked. > > I believe it's better to have a more user-friendly documentation and let = users tune the hardware to suit their needs. > And why not to provide a "simple" shell script that: 1. Collect the detected hardware device list 2. Collect the sysctl value 3. Popose all tunning tips regarding the detected hardware (including RAM/number of CPU/etc=85) and the sysctl value This will kept default conservative value and guide the user to tune by itself its system. Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 13:21:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 97403A4E for ; Mon, 7 Jan 2013 13:21:20 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2739B0 for ; Mon, 7 Jan 2013 13:21:19 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u3so10215118wey.30 for ; Mon, 07 Jan 2013 05:21:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=N9/iXRMD4HrU4kdfBZXVs/HvnRDyXQDnbWP8Hjzc2qs=; b=jbwguZL1b0i4siVSWDmBBzO6G4DDj0hqaak6RZjyGHUR3TUHssp3+Buy7RdauW8OMF M0q6S+B4Sf1BCJV+rGQGAZ7z/C7V67zBW6pVizn/2/3fDIAS88IZfU4ov/+zdQLwQzlX iOq66/1+hYXaAMpMd/FxILaHDVaFWYXA+dTvT7GsRVgvYPoA2K9zWv3SpZl4xw9ocWFh vx8fM6RLg5NfgKdvlN5TY+Nq2lgiSpWxRDwPabGVQlw2ldyeHbXw/zYOQ5tjCWrZGErU En4MRQCT7AhD9TnroiBVwx0iYhqCzP8fihj7k38HC21Gvs4dTeIB0WyvfmYQgAoS0yiy z86w== X-Received: by 10.180.106.34 with SMTP id gr2mr9197907wib.18.1357564872933; Mon, 07 Jan 2013 05:21:12 -0800 (PST) Received: from [192.168.1.123] (tui75-3-88-168-239-38.fbx.proxad.net. [88.168.239.38]) by mx.google.com with ESMTPS id fv2sm12154167wib.4.2013.01.07.05.21.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jan 2013 05:21:12 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance From: Fleuriot Damien In-Reply-To: Date: Mon, 7 Jan 2013 14:21:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3E4CC481-6222-4AD5-8F39-C7532D6D67AF@my.gd> References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> <74D89D84-CC53-49A9-8D69-AF255A8323E0@my.gd> To: =?windows-1252?Q?Olivier_Cochard-Labb=E9?= X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlPp8rDR02FsNliyyV8nFCAvyWcWYSoISBya3qMwtVQpXrpEJjhYGzouTR4PBOsTkncj+O9 Cc: Current FreeBSD , "O. Hartmann" , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 13:21:20 -0000 On Jan 7, 2013, at 1:49 PM, Olivier Cochard-Labb=E9 = wrote: > On Mon, Jan 7, 2013 at 11:20 AM, Fleuriot Damien wrote: >>=20 >>=20 >> Well perhaps the code to handle auto tuning isn't present in the = driver itself. >>=20 >> I'm not a huge fan of the idea, I believe it would be rather taxing = to implement all the exceptions and that some could easily be = overlooked. >>=20 >> I believe it's better to have a more user-friendly documentation and = let users tune the hardware to suit their needs. >>=20 >=20 > And why not to provide a "simple" shell script that: > 1. Collect the detected hardware device list > 2. Collect the sysctl value > 3. Popose all tunning tips regarding the detected hardware (including > RAM/number of CPU/etc=85) and the sysctl value >=20 > This will kept default conservative value and guide the user to tune > by itself its system. >=20 > Regards, >=20 > Olivier Tuning isn't simply dependent on your hardware, it also *heavily* = depends on what you want to do with your server. A large database, a fast httpd serving tiny 2kbytes files, or a samba = server have little in common and require different optimizations. While I understand the motivation behind your idea, I still don't think = it would be terrific. However, who am I to stop you ? Kindly feel free to conceptualize such a script and ask for testers here = on the mailing list, I for one would be delighted to help.= From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 13:25:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5E5A0B90 for ; Mon, 7 Jan 2013 13:25:21 +0000 (UTC) (envelope-from ianf@cloudseed.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id DF8309EB for ; Mon, 7 Jan 2013 13:25:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id C909A2B42D97 for ; Mon, 7 Jan 2013 15:25:10 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivtqazs2HneG for ; Mon, 7 Jan 2013 15:25:10 +0200 (SAST) Received: from clue.co.za (unknown [197.87.27.111]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 3313B2B42D30 for ; Mon, 7 Jan 2013 15:25:10 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TsChN-00014U-8I for current@freebsd.org; Mon, 07 Jan 2013 15:25:05 +0200 To: current@freebsd.org Subject: route add ... -iface fails From: "Ian FREISLICH" X-Attribution: BOFH Date: Mon, 07 Jan 2013 15:25:05 +0200 Message-Id: X-Mailman-Approved-At: Mon, 07 Jan 2013 13:36:59 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 13:25:21 -0000 Hi This used to work on tunX, but no more. tun0: flags=8051 metric 0 mtu 1492 options=80000 inet 41.135.82.18 --> 41.135.70.1 netmask 0xffffffff Opened by PID 2387 [router] ~ # route add 41.154.2.53 -iface tun0 route: bad address: tun0 It also doesn't work on ngX PPP interfaces. ng2: flags=88d1 metric 0 mtu 1490 inet 41.135.82.120 --> 41.135.70.1 netmask 0xffffffff [router] ~ # route add 41.154.2.53 -iface ng2 route: bad address: ng2 [router] ~ # route add 41.154.2.53 -interface ng2 route: bad address: ng2 I have several PPP conections on several ADSL lines with the same provider that doesn't do multi link PPP, so I need to be able to set the destination interface. Ian -- Meditating Guru Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 23:21:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B21248A6; Mon, 7 Jan 2013 23:21:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 388D2C25; Mon, 7 Jan 2013 23:21:21 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:406f:4ff9:6789:6380] (unknown [IPv6:2001:7b8:3a7:0:406f:4ff9:6789:6380]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3C7025C37; Tue, 8 Jan 2013 00:21:18 +0100 (CET) Message-ID: <50EB5868.2050509@FreeBSD.org> Date: Tue, 08 Jan 2013 00:21:12 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: clang 3.2 RC2 miscompiles libgcc? References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <20130106160331.GB1418@mole.fafoe.narf.at> In-Reply-To: <20130106160331.GB1418@mole.fafoe.narf.at> Content-Type: multipart/mixed; boundary="------------080402030204060302080304" Cc: freebsd-current@freebsd.org, David Chisnall , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 23:21:21 -0000 This is a multi-part message in MIME format. --------------080402030204060302080304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-01-06 17:03, Stefan Farfeleder wrote: > On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: ... > The bug also affects ports software, e.g., I also experienced strange > rtorrent segfaults that are now gone. Can you please try the attached patch, which is a very horrid, atrocious hack, and will only work for amd64. Then rebuild libgcc with clang, and please try if this fixes at least some of the crashes... This is at least the direction I'm looking at. It seems that in some cases with __builtin_eh_return(), llvm does not see that registers can be clobbered, and it doesn't save and restore them. After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. Here is a side-by-side overview of the output; sorry for going over any 72-char margin, but this is for illustration. You can see that gcc saves most registers on the stack, and restores them just before the eh return. Clang does not, at least by default: GCC OUTPUT CLANG OUTPUT ================================================= ========================================================= _Unwind_Resume: _Unwind_Resume: # @_Unwind_Resume pushq %rbp pushq %rbp movq %rsp, %rbp movq %rsp, %rbp pushq %r15 pushq %rdx pushq %r14 pushq %rax pushq %r13 subq $528, %rsp # imm = 0x210 pushq %r12 movq %rdi, -24(%rbp) pushq %rbx movq %rbp, %rdi pushq %rdx addq $16, %rdi pushq %rax movq 8(%rbp), %rdx subq $536, %rsp leaq -264(%rbp), %rcx movq %rdi, -584(%rbp) movq %rdi, -536(%rbp) # 8-byte Spill movq 8(%rbp), %rax movq %rcx, %rdi movq %rax, %rdx movq -536(%rbp), %rsi # 8-byte Reload leaq 16(%rbp), %rsi callq uw_init_context_1@PLT leaq -336(%rbp), %rdi movabsq $240, %rdx call uw_init_context_1@PLT leaq -264(%rbp), %rcx leaq -576(%rbp), %rdi leaq -504(%rbp), %rsi leaq -336(%rbp), %rsi movq %rsi, %rdi movl $240, %edx movq %rcx, %rsi call memcpy@PLT callq memcpy@PLT movq -584(%rbp), %rax movq -24(%rbp), %rcx movq 16(%rax), %rax cmpq $0, 16(%rcx) testq %rax, %rax jne .LBB0_2 jne .L59 leaq -504(%rbp), %rsi leaq -576(%rbp), %rsi movq -24(%rbp), %rdi movq -584(%rbp), %rdi callq _Unwind_RaiseException_Phase2@PLT call _Unwind_RaiseException_Phase2@PLT movl %eax, -508(%rbp) movl %eax, -84(%rbp) jmp .LBB0_3 jmp .L61 .LBB0_2: # %if.else .L59: leaq -504(%rbp), %rsi leaq -576(%rbp), %rsi movq -24(%rbp), %rdi movq -584(%rbp), %rdi callq _Unwind_ForcedUnwind_Phase2@PLT call _Unwind_ForcedUnwind_Phase2@PLT movl %eax, -508(%rbp) movl %eax, -84(%rbp) .LBB0_3: # %if.end .L61: cmpl $7, -508(%rbp) cmpl $7, -84(%rbp) je .LBB0_5 je .L62 callq abort@PLT call abort@PLT .LBB0_5: # %cond.false .L62: jmp .LBB0_6 leaq -576(%rbp), %rsi .LBB0_6: # %cond.end leaq -336(%rbp), %rdi leaq -264(%rbp), %rdi call uw_install_context_1@PLT leaq -504(%rbp), %rsi movq %rax, -80(%rbp) callq uw_install_context_1@PLT movq -424(%rbp), %rax movq %rax, -520(%rbp) movq %rax, -72(%rbp) movq -352(%rbp), %rsi movq -80(%rbp), %rcx movq %rsi, -528(%rbp) movq -72(%rbp), %rax movq -520(%rbp), %rsi movq %rax, 8(%rbp,%rcx) movq -528(%rbp), %rdi movq -56(%rbp), %rax movq %rbp, %rax movq -48(%rbp), %rdx movq %rdi, 8(%rax,%rsi) movq -40(%rbp), %rbx leaq 8(%rax,%rsi), %rcx movq -32(%rbp), %r12 addq $528, %rsp # imm = 0x210 movq -24(%rbp), %r13 popq %rax movq -16(%rbp), %r14 popq %rdx movq -8(%rbp), %r15 popq %rbp leaq 8(%rbp,%rcx), %rcx movq %rcx, %rsp movq 0(%rbp), %rbp ret # eh_return, addr: %rcx movq %rcx, %rsp ret --------------080402030204060302080304 Content-Type: text/x-diff; name="unwind-clobber-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="unwind-clobber-1.diff" Index: contrib/gcc/unwind-dw2.c =================================================================== --- contrib/gcc/unwind-dw2.c (revision 244663) +++ contrib/gcc/unwind-dw2.c (working copy) @@ -1448,6 +1448,7 @@ uw_init_context_1 (struct _Unwind_Context *context { \ long offset = uw_install_context_1 ((CURRENT), (TARGET)); \ void *handler = __builtin_frob_return_addr ((TARGET)->ra); \ + __asm __volatile(" " : : : "r15", "r14", "r13", "r12", "rbx", "rdx", "rax"); \ __builtin_eh_return (offset, handler); \ } \ while (0) --------------080402030204060302080304-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 22:47:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90C6D54C for ; Mon, 7 Jan 2013 22:47:22 +0000 (UTC) (envelope-from kach@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1.freebsd.org (Postfix) with ESMTP id E2649AB3 for ; Mon, 7 Jan 2013 22:47:13 +0000 (UTC) Received: from mailout-eu.gmx.com ([10.1.101.214]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lr5bx-1TMqXe35yF-00eh8s for ; Mon, 07 Jan 2013 23:47:01 +0100 Received: (qmail invoked by alias); 07 Jan 2013 22:47:00 -0000 Received: from 188.4.146.168.dsl.dyn.forthnet.gr (EHLO [10.6.42.20]) [188.4.146.168] by mail.gmx.com (mp-eu014) with SMTP; 07 Jan 2013 23:47:00 +0100 X-Authenticated: #43597853 X-Provags-ID: V01U2FsdGVkX19BEXgAk25B7dVvmXFQtm6TC79waANKexdz/9JGKT G0wqROKl32scam From: Chrysostomos Kanoulis Subject: esxi - high system cpu load Date: Tue, 8 Jan 2013 00:46:58 +0200 Message-Id: To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Mon, 07 Jan 2013 23:21:23 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 22:47:22 -0000 Hello, The following output is from a virtual machine on ESXi 4.1.=20 I am experiencing high system cpu loads whenever i try to compile = anything,=20 making it difficult to even update the system. = --------------------------------------------------------------------------= ------------------------- root@lab:~ # uname -a FreeBSD lab.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sun Dec 30 = 10:45:18 UTC 2012 = root@snap.freebsd.org:/usr/obj/i386.i386/usr/src/sys/GENERIC i386 = --------------------------------------------------------------------------= ------------------------- root@lab:~ # top last pid: 45416; load averages: 1.10, 1.08, 1.08 = = up 1+23:24:19 22:06:25 36 processes: 2 running, 34 sleeping CPU: 12.2% user, 0.0% nice, 87.8% system, 0.0% interrupt, 0.0% idle Mem: 273M Active, 62M Inact, 109M Wired, 11M Cache, 59M Buf, 27M Free Swap: 819M Total, 8996K Used, 810M Free, 1% Inuse = --------------------------------------------------------------------------= ------------------------- root@lab:~ # vmstat 1 procs memory page disks faults = cpu r b w avm fre flt re pi po fr sr da0 cd0 in sy cs = us sy id 1 0 0 398M 37M 325 0 0 0 334 2 0 0 3 69 149 = 0 4 96 1 0 0 398M 37M 5195 0 2 0 5318 0 2 0 7 1335 163 = 47 53 0 1 1 0 373M 37M 5374 0 0 0 5337 0 0 0 7 1395 157 = 45 55 0 1 0 0 394M 39M 10096 0 0 0 10724 0 0 0 7 965 198 = 4 96 0 1 0 0 408M 30M 7602 0 1 0 5347 0 1 0 4 1630 150 = 32 68 0 1 0 0 354M 54M 6540 0 0 0 12687 0 0 0 5 1206 162 = 26 74 0 1 0 0 409M 26M 10452 0 2 0 3373 0 3 0 9 1592 208 = 10 90 0 1 0 0 398M 34M 4184 0 1 0 6316 0 2 0 5 929 153 = 52 48 0 1 0 0 369M 41M 3637 0 0 0 5337 0 0 0 5 1371 152 = 54 46 0 2 0 0 362M 42M 10285 0 0 0 10710 0 0 0 6 959 185 = 5 95 0 Any suggestions ?= From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 23:54:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 201401F4 for ; Mon, 7 Jan 2013 23:54:25 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 03785DCC for ; Mon, 7 Jan 2013 23:54:24 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id F34551FB3E; Mon, 7 Jan 2013 15:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1357602864; bh=MskYA/hUdiiMtBBUatfafKOCNrdvgS8BwqaNn65TIyI=; h=Date:From:Reply-To:To:Subject; b=nfyZ8CHtRyxrZAAJMCSbFONMVAcePEZqrHnx4B7LYTcwb7kG8eypPVb5OJkXs1/8A 6qu2lq4Q50ld7it4FzuFkkTYOO8Bo927+CiZxmVcg/veppVrzAe8D/2OVf54OBXmD3 2SJdSjW5Pdk5cejztUUcAauV2xItsmGaHPpOescM= Message-ID: <50EB602F.9050300@delphij.net> Date: Mon, 07 Jan 2013 15:54:23 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: sysctl -a causes kernel trap 12 X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 23:54:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I've recently (by mid-December I think) noticed that sysctl -a can sometimes cause kernel trap 12. Tried enabling INVARIANTS and the problem mysteriously disappeared. After some experiments on this, it seems that this can be triggered by sysctl -a but the system have an 1 in 10 chance to survive. When INVARIANTS is enabled however, I can not trigger the panic. "sysctl hw" triggers the panic sometimes, but not always. Do anybody have clue on this? The system hangs hard when it panics so kernel debugger won't work. When it panics, the fault instruction pointer is always 0x20:0xffffffff808d61c9, which is sys/kern/subr_turnstile.c:297: > /* Resort td on the list if needed. */ if > (!turnstile_adjust_thread(ts, td)) { mtx_unlock_spin(&ts->ts_lock); > // 297 // return; } This sounds like a race condition but I haven't yet able to track it down... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQ62AvAAoJEG80Jeu8UPuzW0IH/0D0PxoTIr6qdHFhzG1It1r2 HRnkCaVKzllc6a0obdHzthBLe7dd3bMARuVLR/NiD611mhrFGY2P4W9x+bp9KwMH gTp18fWsHamkj5jEO8zpLjVWF62WwaFKuCEvg1zKLS+Fo3K7vSr5i5O6SeUhueeR iUNldC5m5E6Nwkbn9OW8jHzadhHmmIbUAfoWs8K7FCFQpLYXg5e8Q8gW5RsJvPmT v92vwAC2L3MOBiSGKfRkKngBihHlDnkX0xRhWuI+PIh5yr8kijgA4DDroOhJv3RF ga0NKanjZFk9k1+gFVua3gmMmCopvkIs7XHsjJbKBcMcvEtTXQxkrJwVmgX+q80= =Wubv -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 00:08:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C1D41871 for ; Tue, 8 Jan 2013 00:08:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B829CE56 for ; Tue, 8 Jan 2013 00:03:11 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id r0802X6x010279; Tue, 8 Jan 2013 02:02:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua r0802X6x010279 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id r0802XA3010278; Tue, 8 Jan 2013 02:02:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Jan 2013 02:02:33 +0200 From: Konstantin Belousov To: d@delphij.net Subject: Re: sysctl -a causes kernel trap 12 Message-ID: <20130108000233.GZ82219@kib.kiev.ua> References: <50EB602F.9050300@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1PhPE3kzXS7rBT0C" Content-Disposition: inline In-Reply-To: <50EB602F.9050300@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:08:48 -0000 --1PhPE3kzXS7rBT0C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi, >=20 > I've recently (by mid-December I think) noticed that sysctl -a can > sometimes cause kernel trap 12. Tried enabling INVARIANTS and the > problem mysteriously disappeared. After some experiments on this, it > seems that this can be triggered by sysctl -a but the system have an 1 > in 10 chance to survive. When INVARIANTS is enabled however, I can > not trigger the panic. "sysctl hw" triggers the panic sometimes, but > not always. >=20 > Do anybody have clue on this? The system hangs hard when it panics so > kernel debugger won't work. When it panics, the fault instruction > pointer is always 0x20:0xffffffff808d61c9, which is > sys/kern/subr_turnstile.c:297: >=20 > > /* Resort td on the list if needed. */ if > > (!turnstile_adjust_thread(ts, td)) { mtx_unlock_spin(&ts->ts_lock); > > // 297 // return; } >=20 > This sounds like a race condition but I haven't yet able to track it > down... Could you try to isolate the sub-leaf under hw which causes the panic ? Just shot in the dark, do you have Intel GPU gemified driver loaded ? --1PhPE3kzXS7rBT0C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ62IYAAoJEJDCuSvBvK1B+d4P/0DrwSyV2MYDKfxbl4OT/f6r Mcrof8S/Bgpa7YMJiMVWDzIkyIBsViA+ukQpl7iiieVBS5YQOtdy63JXUbegFVpB AK+CLIjQ9wLYINe2GOnhclP2mjV80R3QxY61Vj1WR3zoL7Nhml6WDl8FDiizSAq8 ZiLn/3mBIhzphqybs++h2ZeMY0CyY8FFi0m6X9mkNdcfbmuiqywWCYQYU1L3+H5L /jpnVtZK/T7S6UTz+zIf3foYGoOnxIYFYWGD6ceMKXyYN4MRIG9ybvuJ4Lgwgjin MmiIOAcN13ERbu7aLXxOgGa9uGA/FcZA2zx+1N/HtRnSshI1NcfEn8Nz+/Yb1Nad 5TXb+UOYXtQI51C20Ns76hOLDuvY6nmdLAP2M7NPNUzJ6J+kV6kz4mXJ53sqtEEH +dr8QwwVdXKLf4uNi8G9hssGxO/TyGNvQMR4WrK07MjSb4AT5dAlY5MogR7V2yVq CswGfqPCAAEbVBhcB0oeZ9odp88md7KrS6jyaRzWUYtfw29tqqK+AnBd283TUMlg Qn44coabfD+Soznd5j3ryyTOtnbuRvsSs7X0t0YSlej5h1JR9BS1W0hX5J8ilXIA XbNXhXUJLpz4Us2LGwPd92P3KDJTYxj/Z9tXLCl9od5QFkLpOzSfvmcxrcwarz9t Li9xHx3pfpgXiKo8jjHw =OGXM -----END PGP SIGNATURE----- --1PhPE3kzXS7rBT0C-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 00:09:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 25ECAA2C for ; Tue, 8 Jan 2013 00:09:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 13967EBC for ; Tue, 8 Jan 2013 00:09:15 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 651041FC51; Mon, 7 Jan 2013 16:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1357603754; bh=nh4+Px4mXSgxDfRR+p2Xnl2BCqnOSl31YnVuXGuV0DM=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=1Vs46tfyhqieSrcrjuABnNQezPHXV+spVTrRXKrGTyLfV4ePKDuJm7l7G+tZdEp+O cmOCEBVwTB5hjpdCqXMz9M8t/fI4cl/WiKdSPkSclqyvWrdJP5N9tnwvdLmy9TefLb N7zFrWrDA3lE9LF9tC+B1QKnnlEGmHNtdYmUvl4o= Message-ID: <50EB63A9.50903@delphij.net> Date: Mon, 07 Jan 2013 16:09:13 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: sysctl -a causes kernel trap 12 References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> In-Reply-To: <20130108000233.GZ82219@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, d@delphij.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:09:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/07/13 16:02, Konstantin Belousov wrote: > On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Hi, >> >> I've recently (by mid-December I think) noticed that sysctl -a >> can sometimes cause kernel trap 12. Tried enabling INVARIANTS >> and the problem mysteriously disappeared. After some experiments >> on this, it seems that this can be triggered by sysctl -a but the >> system have an 1 in 10 chance to survive. When INVARIANTS is >> enabled however, I can not trigger the panic. "sysctl hw" >> triggers the panic sometimes, but not always. >> >> Do anybody have clue on this? The system hangs hard when it >> panics so kernel debugger won't work. When it panics, the fault >> instruction pointer is always 0x20:0xffffffff808d61c9, which is >> sys/kern/subr_turnstile.c:297: >> >>> /* Resort td on the list if needed. */ if >>> (!turnstile_adjust_thread(ts, td)) { >>> mtx_unlock_spin(&ts->ts_lock); // 297 // return; } >> >> This sounds like a race condition but I haven't yet able to track >> it down... > > Could you try to isolate the sub-leaf under hw which causes the > panic ? Just shot in the dark, do you have Intel GPU gemified > driver loaded ? It seems that it was not hw itself that causes the problem (I thought about isolating to sub-leaf and at one point believed it was hw.acpi.battery but doing so repeatedly doesn't panic the system, with or without INVARIANTS; doing 'sysctl hw' sometimes causes panic but not always). The laptop is running nVidia but it's using i7-3610QM which does have Intel GPU, but I have not loaded drm2.ko and the panic is reproducible in single user mode. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQ62OpAAoJEG80Jeu8UPuzsYgH/iw8ispGuIqYkDAcfH1rh2AR MvSF3kf6OsPUAm3hRpa+VGcwssqgPTnyTgB2AGDPQ4FPurep/9sVD7rEmjy+4jFY 6bpUvirTcfSVnuEXWKq+ySaq7K+zR9SvorNMOnufS91oY+hzwwnZd3iykjhLAAth MNjmhAoSsT+MHvMBNweIoWA7FH9MxE7yfOi89foM/ZTcbibt9vY+gTpAPAlrfsab xG1w8aQhgX6/91QZGh8E1nVDo8vqO9Fqte+tkaZbEh3eJQFx8uRktvAps6T052T/ la/1zzGoqxfZZRbc0/bK7CnhyM4N5xPM1Q+eB2Q9F6F/S+XQPPhASnJNJXh0XAw= =tCfp -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 00:21:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2209C42 for ; Tue, 8 Jan 2013 00:21:06 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by mx1.freebsd.org (Postfix) with ESMTP id B3843F28 for ; Tue, 8 Jan 2013 00:21:06 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id vb8so17989086obc.20 for ; Mon, 07 Jan 2013 16:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iWTvawaH6/3G+Dr1QTiqG7WbyF4MphqskQvT9biMmrI=; b=Ld8wqbOis3ASPae79VELqj4XfhsnA/eF4aT0ybgC95hoUjbKYj4vqHAvbPGETCJLEc SpRM6mTN4endy0XOUATtCgZ9rw6xXC9LzPE4AoaGUELpwD3uFLjGfHbZGwsRU/MtaZHf wNjG8IfSWhU6PCy6mqMqoDiojX8vC9MCtzcEUaa+Bpz3R67Cl9kaSXN2rZri8QL4RrsD 6vumDOAKWwHC99bZf4uyZeF9381+t7WBLbydkPstujfuqz8PxaevUAT+58IniRWvjr89 kYgAHGKarAgcRYSJ2NGaUT9qQdxfWac+9OJpaZqNxtBfIpGMPx69kdxAesVkt/+M/3em pPRA== MIME-Version: 1.0 Received: by 10.60.171.175 with SMTP id av15mr34089243oec.75.1357604460782; Mon, 07 Jan 2013 16:21:00 -0800 (PST) Received: by 10.76.128.68 with HTTP; Mon, 7 Jan 2013 16:21:00 -0800 (PST) In-Reply-To: <50EB63A9.50903@delphij.net> References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> Date: Mon, 7 Jan 2013 19:21:00 -0500 Message-ID: Subject: Re: sysctl -a causes kernel trap 12 From: Ryan Stone To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:21:06 -0000 Have you tried dropping into the debugger by setting debug.debugger_on_panic=1 instead of trying to generate a core? You might have some success generating at least a backtrace. Also it would be worth setting kern.stop_scheduler_on_panic=0 to see if that lets you generate a core. From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 00:23:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2D4FDB4 for ; Tue, 8 Jan 2013 00:23:08 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by mx1.freebsd.org (Postfix) with ESMTP id 738DEF55 for ; Tue, 8 Jan 2013 00:23:08 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id k14so18616360oag.28 for ; Mon, 07 Jan 2013 16:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PcQWge02qfaT+toNfe1w2Ss4VqGVCXNdJPfjAceGahE=; b=sgisNitoBrNRHFFcvdRuzh8tYOxzv7WyOAgsLJdwwBGWVclbLqwF2MvC28XBdTjyXx EsGGp/eb9GQBRwXQvLlLH9OZqvuuTT28bUMt5PwTb68H9fFyUilJW3VFwElYJ2LOxXaC vmxydpPYKRIutSn0knvgHF1Tblg8rr4JXkL13txFX2noTaGqI6OvyfVy72zhRcbe0E26 huN76pMM9F1m7agnDSSQvamo55b+MVpnLZVDnMz9P/fHfqXqW0uHLuDzOHfhcOHI3QcW dy1gdIe+0LYaGBODEDmTyqPspjPHPns+bbQHJjPUUfXv22fFo09/J5+YtlZKOietWatX TguA== MIME-Version: 1.0 Received: by 10.60.171.175 with SMTP id av15mr34091285oec.75.1357604587477; Mon, 07 Jan 2013 16:23:07 -0800 (PST) Received: by 10.76.128.68 with HTTP; Mon, 7 Jan 2013 16:23:07 -0800 (PST) In-Reply-To: References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> Date: Mon, 7 Jan 2013 19:23:07 -0500 Message-ID: Subject: Re: sysctl -a causes kernel trap 12 From: Ryan Stone To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:23:08 -0000 On Mon, Jan 7, 2013 at 7:21 PM, Ryan Stone wrote: > Have you tried dropping into the debugger by setting > debug.debugger_on_panic=1 instead of trying to generate a core? You might > have some success generating at least a backtrace. > Sigh, reading comprehension fail on my part. Try generating a core, I guess. Another think that you could do would be to annotate the sysctl code path to print the name of the sysctl that it is about to run to the console. From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 00:34:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D518F30; Tue, 8 Jan 2013 00:34:46 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by mx1.freebsd.org (Postfix) with ESMTP id D13F5F97; Tue, 8 Jan 2013 00:34:45 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id e13so7897795eaa.5 for ; Mon, 07 Jan 2013 16:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=yOE7WRqOmfWKp3qTa3kYGlmu2zD1nitAYWVJYV6J/Ok=; b=xN48RtUHgwn7Mk6v99dwgtvo6ntQxfBHFcjD9x/D1+KeqZRzTxJwNVbHt0bGBaAsIi uAqjFtPJicFbUaa7p/c1HC65HAiTrXgB9UUuGL1d0sxvZtDDTIz0GOjp9zaDQ3/zjrYd H5MMtE9e+3/etauX2fvJp43DPxItVDpQBUnQLj6mNkAXjwa05SLLrhak1MldqKGs2/NQ MdnnYFSNqagVKO4sUWtIdlzxvDpNjQuYm6tJOynjdPpdSFgeAMEw8+ZB1qBlOf9o/R7y BfJ24cqeKsxe+6vegxnVDyuGs/l/2blA3xsf1F2oMZGUzP2BxdeF/+jQOCSjvk+R90Rd WcOw== MIME-Version: 1.0 Received: by 10.14.215.194 with SMTP id e42mr169650017eep.32.1357605279109; Mon, 07 Jan 2013 16:34:39 -0800 (PST) Received: by 10.14.221.132 with HTTP; Mon, 7 Jan 2013 16:34:38 -0800 (PST) Date: Mon, 7 Jan 2013 16:34:38 -0800 Message-ID: Subject: Fixing clang warnings in hwpmc From: hiren panchasara To: Fabien Thomas , Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:34:46 -0000 http://www.strugglingcoder.info/patches/hwpmc_clang_warnings.txt A trivial patch to fix a couple of clang warnings. Thanks, Hiren From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 01:33:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94D90978 for ; Tue, 8 Jan 2013 01:33:36 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 351F018C for ; Tue, 8 Jan 2013 01:33:35 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so10116597wgb.17 for ; Mon, 07 Jan 2013 17:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Gv/gBUhlLspdDSE/x3jGEbZ24OqbZ20niJuIcFcj8OM=; b=CefmH38NG9B/PIsMD6ogiFJ530/s7iZ2/bou7orpccB1UXbouueS8PlJh4aNRdKWGI ajEiCa3AW4nDUTwftEDBk8PTUHlceJZZAL5JqTOUGTWkrJEeoZHLiUsCqhpM6C4GdoDm Yv37sueUKuOvHIHhIIwmdhBEpUxF0e+GpdqzN8Rpl6GtAUjUSmEllzR2S/gqMwazJpYO OWuIidlsLF/7iP3AU888lWjruZYo8YRzN5vie0iXRoxCcDuqtSzeDxnRGR1tW3ux6+MQ 1N7Xpo7pc7t6grbWPqPI75vZcM5VpYo1dl7nTvAjOja5dHgeVQbv7nCBVWnCQPApJrkC 5rew== MIME-Version: 1.0 X-Received: by 10.180.100.163 with SMTP id ez3mr12040134wib.24.1357608809320; Mon, 07 Jan 2013 17:33:29 -0800 (PST) Received: by 10.216.100.194 with HTTP; Mon, 7 Jan 2013 17:33:29 -0800 (PST) In-Reply-To: <50EB63A9.50903@delphij.net> References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> Date: Mon, 7 Jan 2013 19:33:29 -0600 Message-ID: Subject: Re: sysctl -a causes kernel trap 12 From: Brandon Gooch To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 01:33:36 -0000 On Mon, Jan 7, 2013 at 6:09 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 01/07/13 16:02, Konstantin Belousov wrote: > > On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >> > >> Hi, > >> > >> I've recently (by mid-December I think) noticed that sysctl -a > >> can sometimes cause kernel trap 12. Tried enabling INVARIANTS > >> and the problem mysteriously disappeared. After some experiments > >> on this, it seems that this can be triggered by sysctl -a but the > >> system have an 1 in 10 chance to survive. When INVARIANTS is > >> enabled however, I can not trigger the panic. "sysctl hw" > >> triggers the panic sometimes, but not always. > >> > >> Do anybody have clue on this? The system hangs hard when it > >> panics so kernel debugger won't work. When it panics, the fault > >> instruction pointer is always 0x20:0xffffffff808d61c9, which is > >> sys/kern/subr_turnstile.c:297: > >> > >>> /* Resort td on the list if needed. */ if > >>> (!turnstile_adjust_thread(ts, td)) { > >>> mtx_unlock_spin(&ts->ts_lock); // 297 // return; } > >> > >> This sounds like a race condition but I haven't yet able to track > >> it down... > > > > Could you try to isolate the sub-leaf under hw which causes the > > panic ? Just shot in the dark, do you have Intel GPU gemified > > driver loaded ? > > It seems that it was not hw itself that causes the problem (I thought > about isolating to sub-leaf and at one point believed it was > hw.acpi.battery but doing so repeatedly doesn't panic the system, with > or without INVARIANTS; doing 'sysctl hw' sometimes causes panic but > not always). > > The laptop is running nVidia but it's using i7-3610QM which does have > Intel GPU, but I have not loaded drm2.ko and the panic is reproducible > in single user mode. > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > Xin, did you compile the NVIDIA driver port with clang? I was having this issue until I set an exception for the NVIDIA driver port to be built with GCC. Actually, I just remembered (and checked), and what I'm actually doing is setting CFLAGS for the NVIDIA driver port to -O0, and building with clang. Clang optimizes out important bits, I didn't investigate deeply enough to determine what was actually going awry... -Brandon From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 02:12:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C777F2F1 for ; Tue, 8 Jan 2013 02:12:45 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0DF2B9 for ; Tue, 8 Jan 2013 02:12:44 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id e51so9409787eek.20 for ; Mon, 07 Jan 2013 18:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dogwood.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UfDLHr66lMzppz99Ea7/gcXHXomx79Z4KHFc3HNXtno=; b=iqLaXnuZJmLHIqTh06c7ZnwHMRt5SH4P9w1JebuLZl3mstj/0kWLKhzzEOwFwuHSxu kq4kLzPORvXDI466uN20naKoGgr0h8NSXXZh3k4G/AcEwylV3tavRpYgssbJPPhKaImx vUST/xSq15/YSRa+zp81YEcovO1efmsI+OV64= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=UfDLHr66lMzppz99Ea7/gcXHXomx79Z4KHFc3HNXtno=; b=M4OvjX25Cet4cHDT8VAhCaFHLUaOfAkfZ+zUrgC9QO2ck/mL9o4S9cfsQJEdXNjvQq r0ZmeL5kYMAgIVzT/C0zjHdmiIwf8fXCXgUh+SeOmqu/Qf5D9Bja67E+ekwpuTTBSHod Zr9jV1Z/PjzC2wcyySvZudeI63LFdslt/mvtAwDSI2uj/40YvSY2vPW4SI0aNF69NCml Zov9JloXNHxb4aIQFQ+2HdbqeW8MHo9BmOYp1CbCPk0DtWtioE0HxPul2HIbwlM02R4t d131VLmZJQyMFUfQ85hU8stSBUtWgIIwv9L0KGHs3TV+sVPeqTkDOG111Amp9iKuR82q pmBQ== MIME-Version: 1.0 Received: by 10.14.225.194 with SMTP id z42mr170465590eep.22.1357610669105; Mon, 07 Jan 2013 18:04:29 -0800 (PST) Received: by 10.14.135.72 with HTTP; Mon, 7 Jan 2013 18:04:29 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Jan 2013 16:04:29 -1000 Message-ID: Subject: Re: esxi - high system cpu load From: David Cornejo To: Chrysostomos Kanoulis X-Gm-Message-State: ALoCoQm8baPJ5LoRE1jdPw66sdIAJbfxKf2gc7hYyrWffeWnr2VTZ/K4CiU8IcZSuU6Cbw8gz20i Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 02:12:45 -0000 On Mon, Jan 7, 2013 at 12:46 PM, Chrysostomos Kanoulis wrote: > Hello, > > The following output is from a virtual machine on ESXi 4.1. > I am experiencing high system cpu loads whenever i try to compile anything, > making it difficult to even update the system. > > > --------------------------------------------------------------------------------------------------- > root@lab:~ # uname -a > FreeBSD lab.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sun Dec 30 > 10:45:18 UTC 2012 root@snap.freebsd.org:/usr/obj/i386.i386/usr/src/sys/GENERIC > i386 > > --------------------------------------------------------------------------------------------------- > root@lab:~ # top > last pid: 45416; load averages: 1.10, 1.08, 1.08 > > up 1+23:24:19 22:06:25 > 36 processes: 2 running, 34 sleeping > CPU: 12.2% user, 0.0% nice, 87.8% system, 0.0% interrupt, 0.0% idle > Mem: 273M Active, 62M Inact, 109M Wired, 11M Cache, 59M Buf, 27M Free > Swap: 819M Total, 8996K Used, 810M Free, 1% Inuse > > --------------------------------------------------------------------------------------------------- > root@lab:~ # vmstat 1 > procs memory page disks faults > cpu > r b w avm fre flt re pi po fr sr da0 cd0 in sy cs > us sy id > 1 0 0 398M 37M 325 0 0 0 334 2 0 0 3 69 149 > 0 4 96 > 1 0 0 398M 37M 5195 0 2 0 5318 0 2 0 7 1335 163 > 47 53 0 > 1 1 0 373M 37M 5374 0 0 0 5337 0 0 0 7 1395 157 > 45 55 0 > 1 0 0 394M 39M 10096 0 0 0 10724 0 0 0 7 965 198 > 4 96 0 > 1 0 0 408M 30M 7602 0 1 0 5347 0 1 0 4 1630 150 > 32 68 0 > 1 0 0 354M 54M 6540 0 0 0 12687 0 0 0 5 1206 162 > 26 74 0 > 1 0 0 409M 26M 10452 0 2 0 3373 0 3 0 9 1592 208 > 10 90 0 > 1 0 0 398M 34M 4184 0 1 0 6316 0 2 0 5 929 153 > 52 48 0 > 1 0 0 369M 41M 3637 0 0 0 5337 0 0 0 5 1371 152 > 54 46 0 > 2 0 0 362M 42M 10285 0 0 0 10710 0 0 0 6 959 185 > 5 95 0 > > Any suggestions ? > A load of 1.10 isn't very high, maybe some output while you're compiling might help? It looks like you've got approximately 512M of RAM - I can think of a lot of code that would really stress that these days, but you don't say what you're compiling. You included the top and vmstat output which would indicate that you're already thinking this way. Also, ESXi 4.1 is pretty old - I know latest FreeBSD really has problems on old VMWare workstation, so there might be a problem there too. From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 02:30:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C5BF95FC for ; Tue, 8 Jan 2013 02:30:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 92FA837E for ; Tue, 8 Jan 2013 02:30:54 +0000 (UTC) Received: from Xins-MacBook-Pro-2.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id D6C5F1F51A; Mon, 7 Jan 2013 18:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1357612253; bh=bNZ3DD5K1Odc3N2MlmylKVCEbP3gMxofcR5UXPKmBCQ=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=o+hPT9zZylIecuZNU08j6dyTvqjn7HDXeMLI+DL3eoGyqyW1RduKJtiowjc2rMMrd VtsVFVTJAo34LUzpnCN7uGlxBO5Pi0MnVCBgWurKBeeuaksJHENayx4xWNl96uX8Fw SHSEHriBVPputzzKL06MCq1zSShcG3NctnrRss3s= Message-ID: <50EB84DC.2010805@delphij.net> Date: Mon, 07 Jan 2013 18:30:52 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: sysctl -a causes kernel trap 12 References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 02:30:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 1/7/13 4:21 PM, Ryan Stone wrote: > Have you tried dropping into the debugger by setting > debug.debugger_on_panic=1 instead of trying to generate a core? > You might have some success generating at least a backtrace. My setting was debugger on panic but that's a good point, will try unattended tomorrow to find out (I don't have high expectation here though). > Also it would be worth setting kern.stop_scheduler_on_panic=0 to > see if that lets you generate a core. Hmm... I don't know how will this help but will try. Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQ64TcAAoJEG80Jeu8UPuzhLoH/RVSZKhc4TkhWM3GF9FgiZY0 s5TH738pyh0+fe+FsGItr4uw83MvLLkjVZTlvstwXjEZhrXH6ehnXibcAQnNKACo 0mJKUOQq5xbWVVDSkLeJwthavrAXEBwUPVTVjx6ZhRLJmikkQNbtOkvOypvJ5Jjh i/1/HSFgFrI3x71OpPJOdKMru18VvN5K74A8v34HlaYMgEpnPGmuTJ6hPvkgC8a+ 1w0vGBInmLQWQZ4UEGUhPyoVly2zp81zFpCUfIzf6jd+FPMOcN+gj2JPSYLVUHS2 Rv7ReaT5U6gWvTxTm+lc2zkaUnSkXb8oAwQafWWD/NopnUZHvlQsIdZgSjGhG1k= =Nf0J -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 02:40:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A534979 for ; Tue, 8 Jan 2013 02:40:18 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 6BE3C3FA for ; Tue, 8 Jan 2013 02:40:18 +0000 (UTC) Received: from Xins-MacBook-Pro-2.local (unknown [IPv6:2001:470:83bf:0:fde3:6b6f:53d:dc1a]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 6BCE91F5D9; Mon, 7 Jan 2013 18:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1357612817; bh=GdBFJtCevdxzSVxo92EWXExrQdY7nJCVhh15cx9+9cA=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=AUa021DjAaxXvoteaWFGtYN1wZMZi8yE7YgQ/dX0FbBjVGomrr/3olwfTh+/3udk2 k5Qkygze6CiRrMB9qGOdlfGvUYW3hQoqr0lBZKP3zIv0cmOuySMlED1ouxdK9sYoTJ tYO67tBM1RquYJ/TZIagoV3pmD8IuhIYy8nG4rbg= Message-ID: <50EB870D.3020306@delphij.net> Date: Mon, 07 Jan 2013 18:40:13 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Brandon Gooch Subject: Re: sysctl -a causes kernel trap 12 References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-current@freebsd.org, d@delphij.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 02:40:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 1/7/13 5:33 PM, Brandon Gooch wrote: > On Mon, Jan 7, 2013 at 6:09 PM, Xin Li > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > On 01/07/13 16:02, Konstantin Belousov wrote: >> On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> Hi, >>> >>> I've recently (by mid-December I think) noticed that sysctl -a >>> can sometimes cause kernel trap 12. Tried enabling INVARIANTS >>> and the problem mysteriously disappeared. After some >>> experiments on this, it seems that this can be triggered by >>> sysctl -a but the system have an 1 in 10 chance to survive. >>> When INVARIANTS is enabled however, I can not trigger the >>> panic. "sysctl hw" triggers the panic sometimes, but not >>> always. >>> >>> Do anybody have clue on this? The system hangs hard when it >>> panics so kernel debugger won't work. When it panics, the >>> fault instruction pointer is always 0x20:0xffffffff808d61c9, >>> which is sys/kern/subr_turnstile.c:297: >>> >>>> /* Resort td on the list if needed. */ if >>>> (!turnstile_adjust_thread(ts, td)) { >>>> mtx_unlock_spin(&ts->ts_lock); // 297 // return; } >>> >>> This sounds like a race condition but I haven't yet able to >>> track it down... >> >> Could you try to isolate the sub-leaf under hw which causes the >> panic ? Just shot in the dark, do you have Intel GPU gemified >> driver loaded ? > > It seems that it was not hw itself that causes the problem (I > thought about isolating to sub-leaf and at one point believed it > was hw.acpi.battery but doing so repeatedly doesn't panic the > system, with or without INVARIANTS; doing 'sysctl hw' sometimes > causes panic but not always). > > The laptop is running nVidia but it's using i7-3610QM which does > have Intel GPU, but I have not loaded drm2.ko and the panic is > reproducible in single user mode. > > Cheers, - -- Xin LI > https://www.delphij.net/ FreeBSD - > The Power to Serve! Live free or die > > > Xin, did you compile the NVIDIA driver port with clang? I was > having this issue until I set an exception for the NVIDIA driver > port to be built with GCC. > > Actually, I just remembered (and checked), and what I'm actually > doing is setting CFLAGS for the NVIDIA driver port to -O0, and > building with clang. Clang optimizes out important bits, I didn't > investigate deeply enough to determine what was actually going > awry... Yes my nVidia driver is compiled with clang. I'll try gcc tomorrow, thanks for the pointer. (Note that the panic was a NULL pointer deference and it's a race condition so I doubt if it's compiler related but will try). Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQ64cNAAoJEG80Jeu8UPuzkLwIAKgjgbcBaow64mWzrJ0XtczM 6Xi4mC0Oq5kdomx0y+Vgks/qTvq28Ff/JqyxN8osD959Vwaq0vbQumFiDtbWCr0h /MD0w5m7Asdbf8KzJE80il90Vv1/nJrOVdwj3qoNIqtKIomi12CHDKL5zFs2Ja2i rscN22SBh8+3vV1rBSE6NGzJ7jPSs/B0o73YuIdwj6bUYMiBqHWWGGTfFStNhc4U 1JX6WWsDdiWxNvGPH5lE3HelSgya+WCltD+B6/8mYaByBQbXD+JBOA9AvX97h2kk muQROSMOz6OVdGmtM6U/19Bsiv/8kUtItJF2k19Y/eTQEohH/2xBhq+37EG8cqg= =b9UF -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 07:50:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 708BCD0F; Tue, 8 Jan 2013 07:50:58 +0000 (UTC) (envelope-from mr.kodiak@gmail.com) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by mx1.freebsd.org (Postfix) with ESMTP id 2883DFDC; Tue, 8 Jan 2013 07:50:57 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c12so131424ieb.37 for ; Mon, 07 Jan 2013 23:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=BpQmNpmGwE2GHkNFC3ymKfCTVbncF75wO93grqGTuPE=; b=njoNP4F6gmWxcdWKAz6W924xYVxltuValiMU49U9jHG9jMPuJx/aIecwSrzfys/Xs9 Iav8G5mNU+i2ez4K4ac+tnpHYNL2H2XUKiew8y6JeY5FYjcbrZn5XalNKEENMFLqSC8h KV5QQhDDhgoiV85pGMqdZOfIe65cBxPSxytrci3Gi7Og1pzPNwnjqfiyU3A9TrIT7fRq wB0xk2+kUKsgenPLuDvQh2buSkvit1410Wamsg0NfyqcaT6OY55r8lPeG+Vdlax0OzMS +tJThlvDzWsatzEYzfKwy6UpO0ulwpBkVN+iuu89lJiOWnwl4MD5Ml6xux2VoS7+Tu+G B/Xg== X-Received: by 10.50.207.70 with SMTP id lu6mr8262385igc.50.1357631457424; Mon, 07 Jan 2013 23:50:57 -0800 (PST) MIME-Version: 1.0 Sender: mr.kodiak@gmail.com Received: by 10.64.142.198 with HTTP; Mon, 7 Jan 2013 23:50:27 -0800 (PST) In-Reply-To: References: From: Bryan Venteicher Date: Tue, 8 Jan 2013 01:50:27 -0600 X-Google-Sender-Auth: qRaySTD3Ov1BpPZvvI8HJn_FpAM Message-ID: Subject: Re: VirtIO in GENERIC To: Bryan Venteicher Content-Type: text/plain; charset=ISO-8859-1 Cc: Jim Harris , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 07:50:58 -0000 On Mon, Dec 17, 2012 at 1:17 AM, Bryan Venteicher wrote: > On Sun, Dec 16, 2012 at 11:06 PM, Jim Harris wrote: >> >> >> On Sun, Dec 16, 2012 at 6:53 PM, Andrew Thompson >> wrote: >>> >>> On 17 December 2012 13:17, Bryan Venteicher wrote: >>> >>> > There's been lots of requests to have VirtIO in GENERIC for i386 and >>> > amd64. Anybody have any issues or concerns with this or the patch at >>> > [1]. This also removes the kludge that was introduced in r239009. >>> > >>> > I've compiled LINT for i386 and amd64 so hopefully there won't be any >>> > surprise breakages. >>> > >>> > [1] http://people.freebsd.org/~bryanv/patches/virtio.generic.patch >>> >>> >>> It would be great to have the drivers enabled. You do not need the >>> sys/conf/files changes, the common and arch files are combined. >>> >> >> Removing the virtio files from sys/conf/files ensures these drivers can only >> be specified in x86 kernel configuration files. r239009 added these lines >> to sys/conf/files, but Bryan's patch does it more correctly. >> >> The only question I have is the GENERIC changes where "device virtio" is >> added - it says it is required, but should this instead say it's required >> for any of the other drivers in this section? >> > > Yes, that wording could be improved; will update the patch in the morning. > Hmm .. on second thought, I think 'required' is sufficiently clear on its own that it applies only to this section. Other nearby sections (USB, sound) use the word also. For the time being, I still intend to add VirtIO only to i386 and amd64 GENERIC. ARM and PPC64 can join the club later once I have a chance to test/debug them on QEMU. I'd like to commit this this weekend if nobody raises any objections. >> -Jim >> From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 08:08:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C633015F; Tue, 8 Jan 2013 08:08:21 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 98337D5; Tue, 8 Jan 2013 08:08:20 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0888Chf042159 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 8 Jan 2013 08:08:13 GMT (envelope-from theraven@freebsd.org) Subject: Re: clang 3.2 RC2 miscompiles libgcc? Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <50EB5868.2050509@FreeBSD.org> Date: Tue, 8 Jan 2013 08:08:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1D415F08-5FFC-41B5-9A0D-E03757800E0C@freebsd.org> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <20130106160331.GB1418@mole.fafoe.narf.at> <50EB5868.2050509@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1278) Cc: Stefan Farfeleder , Nathan Whitehorn , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 08:08:21 -0000 On 7 Jan 2013, at 23:21, Dimitry Andric wrote: > This is at least the direction I'm looking at. It seems that in some > cases with __builtin_eh_return(), llvm does not see that registers can > be clobbered, and it doesn't save and restore them. Do you mean that some registers were clobbered by a prior call? = __builtin_eh_return() doesn't return, so whether it clobbers anything or = not isn't something that should matter. The preceding call is = __builtin_frob_return_addr, which seems to be a no-op, so it shouldn't = clobber any registers either... David= From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 08:58:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 343CBE70; Tue, 8 Jan 2013 08:58:36 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id 1EBE531F; Tue, 8 Jan 2013 08:58:34 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep15-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130108085827.CADM2598.viefep15-int.chello.at@edge02.upcmail.net>; Tue, 8 Jan 2013 09:58:27 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge02.upcmail.net with edge id lM021k0042xdvHc01M02px; Tue, 08 Jan 2013 10:00:02 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 312526D449; Tue, 8 Jan 2013 09:58:27 +0100 (CET) Date: Tue, 8 Jan 2013 09:58:27 +0100 From: Stefan Farfeleder To: Dimitry Andric Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130108085826.GA1422@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <20130106160331.GB1418@mole.fafoe.narf.at> <50EB5868.2050509@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50EB5868.2050509@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, David Chisnall , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 08:58:36 -0000 On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: > On 2013-01-06 17:03, Stefan Farfeleder wrote: > > On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: > ... > > The bug also affects ports software, e.g., I also experienced strange > > rtorrent segfaults that are now gone. > > Can you please try the attached patch, which is a very horrid, atrocious > hack, and will only work for amd64. Then rebuild libgcc with clang, and > please try if this fixes at least some of the crashes... > > This is at least the direction I'm looking at. It seems that in some > cases with __builtin_eh_return(), llvm does not see that registers can > be clobbered, and it doesn't save and restore them. > > After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume > which when compiled by clang caused the crashes, but when compiled by > gcc ran OK. Hi Dimitry, your patch seems to work just fine. No crashes whatsoever so far. Thank you. Stefan From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 09:22:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C6FD5956; Tue, 8 Jan 2013 09:22:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 752F1631; Tue, 8 Jan 2013 09:22:21 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b8a6:2fee:dcd9:6bd9] (unknown [IPv6:2001:7b8:3a7:0:b8a6:2fee:dcd9:6bd9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D2A9E5C37; Tue, 8 Jan 2013 10:22:18 +0100 (CET) Message-ID: <50EBE549.9070808@FreeBSD.org> Date: Tue, 08 Jan 2013 10:22:17 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: David Chisnall Subject: Re: clang 3.2 RC2 miscompiles libgcc? References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <20130106160331.GB1418@mole.fafoe.narf.at> <50EB5868.2050509@FreeBSD.org> <1D415F08-5FFC-41B5-9A0D-E03757800E0C@freebsd.org> In-Reply-To: <1D415F08-5FFC-41B5-9A0D-E03757800E0C@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan Farfeleder , Nathan Whitehorn , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 09:22:21 -0000 On 2013-01-08 09:08, David Chisnall wrote: > On 7 Jan 2013, at 23:21, Dimitry Andric wrote: >> This is at least the direction I'm looking at. It seems that in some >> cases with __builtin_eh_return(), llvm does not see that registers can >> be clobbered, and it doesn't save and restore them. > Do you mean that some registers were clobbered by a prior call? __builtin_eh_return() doesn't return, so whether it clobbers anything or not isn't something that should matter. The preceding call is __builtin_frob_return_addr, which seems to be a no-op, so it shouldn't clobber any registers either... No, I mean that gcc seems to take great care in saving and restoring almost all important registers in a function, if that function contains a call to __builtin_eh_return. If you look at expand_eh_return() in contrib/gcc/except.c, you can see that it sets the special variable 'current_function_calls_eh_return'. This influences the code generation all over the place, and specifically the saving of registers in contrib/gcc/config/i386/i386.c: ====================================================================== /* Return 1 if we need to save REGNO. */ static int ix86_save_reg (unsigned int regno, int maybe_eh_return) { if (pic_offset_table_rtx && regno == REAL_PIC_OFFSET_TABLE_REGNUM && (regs_ever_live[REAL_PIC_OFFSET_TABLE_REGNUM] || current_function_profile || current_function_calls_eh_return || current_function_uses_const_pool)) { if (ix86_select_alt_pic_regnum () != INVALID_REGNUM) return 0; return 1; } if (current_function_calls_eh_return && maybe_eh_return) { unsigned i; for (i = 0; ; i++) { unsigned test = EH_RETURN_DATA_REGNO (i); if (test == INVALID_REGNUM) break; if (test == regno) return 1; } } [...] /* Emit code to save registers in the prologue. */ static void ix86_emit_save_regs (void) { unsigned int regno; rtx insn; for (regno = FIRST_PSEUDO_REGISTER; regno-- > 0; ) if (ix86_save_reg (regno, true)) { insn = emit_insn (gen_push (gen_rtx_REG (Pmode, regno))); RTX_FRAME_RELATED_P (insn) = 1; } } ====================================================================== On i386, most registers are touched anyway in _Unwind_Resume, so clang will already save and restore them. But on amd64, there are more registers than local variables, so clang only seems to save a few; not enough, in any case. This is why I added the asm statement which clobbers all those registers, forcing clang to save and restore them. This fixes most of the crashes I was able to reproduce. I think I still have another unrelated issue in libgcc with clang, but this only occurs when compiling the testcases with gcc 4.7, and very high optimization. From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 10:47:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72ACA63A; Tue, 8 Jan 2013 10:47:04 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by mx1.freebsd.org (Postfix) with ESMTP id 7A15890E; Tue, 8 Jan 2013 10:47:03 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id jk13so141215bkc.4 for ; Tue, 08 Jan 2013 02:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=w3tRLkMQks8wQZDzW9pxUxxx+ggw2dsVaHaLhGz/AgM=; b=WuY+fskh+9PPS2YT5CM6vT2574rf8OK6QBOi39+CGTnhHpMnB7iDJoSTnBp9dw10c3 4bpoTu6LXeKVkdnrOektPG/iAWHzanlmNpA8J5CW6iJC8iMAGV94sYGXKDlThAZoIUuf m/kfx1ueByP7mCY7NkIl3hzCS+inwNQNlxpiNeTkiNNMoxBIo1YN+1KebqnB6eBKzoIh bfC/LC+qRQkIynJ+G7rMEhC6jgCV/6Yq3Ym7y3EndIlsFVNobr7ycgvSHXyTD/fOlrjj tfVaWlEU2gzjIuwTv4BAqTKo2OL179T6lmc8jZaA0cJzxnGHxh2NDMdd1h5lW6lDt7vO Jtnw== X-Received: by 10.204.154.202 with SMTP id p10mr31709514bkw.29.1357642022301; Tue, 08 Jan 2013 02:47:02 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id z5sm44885552bkv.11.2013.01.08.02.46.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2013 02:47:01 -0800 (PST) Sender: Alexander Motin Message-ID: <50EBF921.2000304@FreeBSD.org> Date: Tue, 08 Jan 2013 12:46:57 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Strobl Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> In-Reply-To: <20130106152313.GD26039@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Davide Italiano , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 10:47:04 -0000 On 06.01.2013 17:23, Marius Strobl wrote: > On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote: >> On 26.12.2012 01:21, Marius Strobl wrote: >>> On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote: >>>> Experiments with dummynet shown ineffective support for very short >>>> tick-based callouts. New version fixes that, allowing to get as many >>>> tick-based callout events as hz value permits, while still be able to >>>> aggregate events and generating minimum of interrupts. >>>> >>>> Also this version modifies system load average calculation to fix some >>>> cases existing in HEAD and 9 branches, that could be fixed with new >>>> direct callout functionality. >>>> >>>> http://people.freebsd.org/~mav/calloutng_12_17.patch >>>> >>>> With several important changes made last time I am going to delay commit >>>> to HEAD for another week to do more testing. Comments and new test cases >>>> are welcome. Thanks for staying tuned and commenting. >>> >>> FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a >>> try on sparc64 and it at least survives a buildworld there. However, >>> with the patched kernels, buildworld times seem to increase slightly but >>> reproducible by 1-2% (I only did four runs but typically buildworld >>> times are rather stable and don't vary more than a minute for the >>> same kernel and source here). Is this an expected trade-off (system >>> time as such doesn't seem to increase)? >> >> I don't think build process uses significant number of callouts to >> affect results directly. I think this additional time could be result of >> the deeper next event look up, done by the new code, that is practically >> useless for sparc64, which effectively has no cpu_idle() routine. It >> wouldn't affect system time and wouldn't show up in any statistics >> (except PMC or something alike) because it is executed inside timer >> hardware interrupt handler. If my guess is right, that is a part that >> probably still could be optimized. I'll look on it. Thanks. >> >>> Is there anything specific to test? >> >> Since the most of code is MI, for sparc64 I would mostly look on related >> MD parts (eventtimers and timecounters) to make sure they are working >> reliably in more stressful conditions. I still have some worries about >> possible deadlock on hardware where IPIs are used to fetch present time >> from other CPU. > > Well, I've just learnt two things the hard way: > a) We really need the mutex in that path. > b) Assuming that the initial synchronization of the counters is good > enough and they won't drift considerably accross the CPUs so we can > always use the local one makes things go south pretty soon after > boot. At least with your calloutng_12_26.patch applied. Do you think it means they are not really synchronized for some reason? > I'm not really sure what to do about that. Earlier you already said > that sched_bind(9) also isn't an option in case if td_critnest > 1. > To be honest, I don't really unerstand why using a spin lock in the > timecounter path makes sparc64 the only problematic architecture > for your changes. The x86 i8254_get_timecount() also uses a spin lock > so it should be in the same boat. The problem is not in using spinlock, but in waiting for other CPU while spinlock is held. Other CPU may also hold spinlock and wait for something, causing deadlock. i8254 code uses spinlock just to atomically access hardware registers, so it causes no problems. > The affected machines are equipped with a x86-style south bridge > which exposes a powermanagment unit (intended to be used as a SMBus > bridge only in these machines) on the PCI bus. Actually, this device > also includes an ACPI power management timer. However, I've just > spent a day trying to get that one working without success - it > just doesn't increment. Probably its clock input isn't connected as > it's not intended to be used in these machines. > That south bridge also includes 8254 compatible timers on the ISA/ > LPC side, but are hidden from the OFW device tree. I can hack these > devices into existence and give it a try, but even if that works this > likely would use the same code as the x86 i8254_get_timecount() so I > don't see what would be gained with that. > > The last thing in order to avoid using the tick counter as timecounter > in the MP case I can think of is that the Broadcom MACs in the affected > machines also provide a counter driven by a 1 MHz clock. If that's good > enough for a timecounter I can hook these up (in case these work ...) > and hack bge(4) to not detach in that case (given that we can't detach > timecounters ...). i8254 on x86 is also just a bit above 1MHz. >> Here is small tool we are using for test correctness and performance of >> different user-level APIs: http://people.freebsd.org/~mav/testsleep.c >> > > I've run Ian's set of tests on a v215 with and without your > calloutng_12_26.patch and on a v210 (these uses the IPI approach) > with the latter also applied. > I'm not really sure what to make out of the numbers. > > v215 w/o v215 w/ v210 w/ > ---------- ---------------- ---------------- ---------------- > select 1 1999.61 1 23.87 1 29.97 > poll 1 1999.70 1 1069.61 1 1075.24 > usleep 1 1999.86 1 23.43 1 28.99 > nanosleep 1 999.92 1 23.28 1 28.66 > kqueue 1 1000.12 1 1071.13 1 1076.35 > kqueueto 1 999.56 1 26.33 1 31.34 > syscall 1 1.89 1 1.92 1 2.88 Numbers are not bad, respecting the fact that to protect from lost interrupts eventtimer code on sparc64 now sets minimal programming interval to 15us. It was made to reduce race window between the timer read-modify-write and some long NMIs. May be with rereading counter after programming comparator (same as done for HPET, reading which is probably much more expensive) this value could be reduced. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 10:55:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6DE595C; Tue, 8 Jan 2013 10:55:38 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id ED5BF96E; Tue, 8 Jan 2013 10:55:37 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id fn15so200606wgb.8 for ; Tue, 08 Jan 2013 02:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M3EwzbqQ3rMCyMxQ2hP3jyAajEx/QVYxap8URdgdNiI=; b=FNjSSGycSAwaLILf2sONvCXHDsl8cgTXyRHhFRfKkPYctSkJAWklUhdXu73F6xm27b 3LsQttQDfXjMqYQsKxZEl8UL/CPRELw6L7AVeSh5xK20AR7deguov+BOpM2bxCLfNd9B 8xgwfMMUjWd30GU8NHcK6yiG04baAa8S9/PXwOHl0OqMAK3k5tCOO2u0a3nn8+k8JCT+ AoBbsDAjY3WRZM2HukNs0af/jxvRdXOJfcY5q0reUi1ZsRF2Rb4mI3qKWFr8fFDx1pQv vDq6UWziR8VcHfs58F2oKHXtKxZH/n9f4RCFAIkl8lhFJ0fXqOMeK4CcTZ34Ere/KJ9q McGA== X-Received: by 10.180.33.44 with SMTP id o12mr14204490wii.28.1357642530948; Tue, 08 Jan 2013 02:55:30 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id p3sm16024526wic.8.2013.01.08.02.55.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jan 2013 02:55:29 -0800 (PST) Sender: Alexander Motin Message-ID: <50EBFB1F.2080708@FreeBSD.org> Date: Tue, 08 Jan 2013 12:55:27 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <20130106162049.GA3640@onelab2.iet.unipi.it> In-Reply-To: <20130106162049.GA3640@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-arch@FreeBSD.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 10:55:38 -0000 On 06.01.2013 18:20, Luigi Rizzo wrote: > On Sun, Jan 06, 2013 at 04:23:13PM +0100, Marius Strobl wrote: >> On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote: >>> Here is small tool we are using for test correctness and performance of >>> different user-level APIs: http://people.freebsd.org/~mav/testsleep.c >>> >> >> I've run Ian's set of tests on a v215 with and without your >> calloutng_12_26.patch and on a v210 (these uses the IPI approach) >> with the latter also applied. >> I'm not really sure what to make out of the numbers. >> >> v215 w/o v215 w/ v210 w/ >> ---------- ---------------- ---------------- ---------------- >> select 1 1999.61 1 23.87 1 29.97 >> poll 1 1999.70 1 1069.61 1 1075.24 >> usleep 1 1999.86 1 23.43 1 28.99 >> nanosleep 1 999.92 1 23.28 1 28.66 >> kqueue 1 1000.12 1 1071.13 1 1076.35 >> kqueueto 1 999.56 1 26.33 1 31.34 >> syscall 1 1.89 1 1.92 1 2.88 >> select 300 1999.72 300 326.08 300 332.24 >> poll 300 1999.12 300 1069.78 300 1075.82 >> usleep 300 1999.91 300 325.63 300 330.94 >> nanosleep 300 999.82 300 23.25 300 26.76 >> kqueue 300 1000.14 300 1071.06 300 1075.96 >> kqueueto 300 999.53 300 26.32 300 31.42 >> syscall 300 1.90 300 1.93 300 2.89 >> select 3000 3998.18 3000 3176.51 3000 3193.86 >> poll 3000 3999.29 3000 3182.21 3000 3193.12 >> usleep 3000 3998.46 3000 3191.60 3000 3192.50 >> nanosleep 3000 1999.79 3000 23.21 3000 27.02 >> kqueue 3000 3000.12 3000 3189.13 3000 3191.96 >> kqueueto 3000 1999.99 3000 26.28 3000 31.91 >> syscall 3000 1.91 3000 1.91 3000 2.90 >> select 30000 30990.85 30000 31489.18 30000 31548.77 >> poll 30000 30995.25 30000 31518.80 30000 31487.92 >> usleep 30000 30992.00 30000 31510.42 30000 31475.50 >> nanosleep 30000 1999.46 30000 38.67 30000 41.95 >> kqueue 30000 30006.49 30000 30991.86 30000 30996.77 >> kqueueto 30000 1999.09 30000 41.67 30000 46.36 >> syscall 30000 1.91 30000 1.91 30000 2.88 >> select 300000 300990.65 300000 301864.98 300000 301787.01 >> poll 300000 300998.09 300000 301831.36 300000 301741.62 >> usleep 300000 300990.80 300000 301824.67 300000 301770.10 >> nanosleep 300000 1999.15 300000 325.74 300000 331.01 >> kqueue 300000 300000.87 300000 301031.11 300000 300992.28 >> kqueueto 300000 1999.39 300000 328.77 300000 333.45 >> syscall 300000 1.91 300000 1.91 300000 2.88 > > the nanosleep and kqueueto tests are probably passing the wrong > argument to the syscall (meant to be microseconds, but nanosleep > takes nanosecond so it should probably be multiplied by 1000). Yes, you are right. I've used it in such way to see what will happen if I request sub-microsecond interval. In this test these rows are definitely incorrect. > I think that for the time being it would be useful to run at least > one set of tests with kern.timecounter.alloweddeviation=0 so we can > tell how close we get to the required timeouts May be just to be sure, because it should not significantly affect results of the 1us tests, as 5% of 1us is much less then numbers we see there. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 11:16:57 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04BDAE2F; Tue, 8 Jan 2013 11:16:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id AE5FBA34; Tue, 8 Jan 2013 11:16:56 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 23E747300A; Tue, 8 Jan 2013 12:16:03 +0100 (CET) Date: Tue, 8 Jan 2013 12:16:03 +0100 From: Luigi Rizzo To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20130108111603.GA30469@onelab2.iet.unipi.it> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <20130106162049.GA3640@onelab2.iet.unipi.it> <50EBFB1F.2080708@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50EBFB1F.2080708@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , freebsd-arch@FreeBSD.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 11:16:57 -0000 On Tue, Jan 08, 2013 at 12:55:27PM +0200, Alexander Motin wrote: > On 06.01.2013 18:20, Luigi Rizzo wrote: ... > > I think that for the time being it would be useful to run at least > > one set of tests with kern.timecounter.alloweddeviation=0 so we can > > tell how close we get to the required timeouts > > May be just to be sure, because it should not significantly affect > results of the 1us tests, as 5% of 1us is much less then numbers we see > there. to clarify - i don't mind if we are 50-100us (absolute error) off the requested timeout for short intervals, but i want to be sure that this error can be achieved also for large requests. cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 11:46:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE6FC352 for ; Tue, 8 Jan 2013 11:46:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 97959B13 for ; Tue, 8 Jan 2013 11:46:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAKAG7FCDaFvO/2dsb2JhbABEhjm3M3OCHgEBAQMBAQEBIAQnIAsFFhgCAg0WAwIpAQkVEQ4HBAEcBIdwBgynEYJAjTaBIos1FgGDFIETA4hhinyCLoEcjy2DEoFTNQ X-IronPort-AV: E=Sophos;i="4.84,430,1355115600"; d="scan'208";a="10876586" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 08 Jan 2013 06:46:14 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2F7B3B4033; Tue, 8 Jan 2013 06:46:14 -0500 (EST) Date: Tue, 8 Jan 2013 06:46:14 -0500 (EST) From: Rick Macklem To: d@delphij.net Message-ID: <1267967012.1762322.1357645574104.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <50EB870D.3020306@delphij.net> Subject: Re: sysctl -a causes kernel trap 12 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: Konstantin Belousov , Brandon Gooch , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 11:46:15 -0000 d wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 1/7/13 5:33 PM, Brandon Gooch wrote: > > On Mon, Jan 7, 2013 at 6:09 PM, Xin Li > > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > > > On 01/07/13 16:02, Konstantin Belousov wrote: > >> On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >>> > >>> Hi, > >>> > >>> I've recently (by mid-December I think) noticed that sysctl -a > >>> can sometimes cause kernel trap 12. Tried enabling INVARIANTS > >>> and the problem mysteriously disappeared. After some > >>> experiments on this, it seems that this can be triggered by > >>> sysctl -a but the system have an 1 in 10 chance to survive. > >>> When INVARIANTS is enabled however, I can not trigger the > >>> panic. "sysctl hw" triggers the panic sometimes, but not > >>> always. > >>> > >>> Do anybody have clue on this? The system hangs hard when it > >>> panics so kernel debugger won't work. When it panics, the > >>> fault instruction pointer is always 0x20:0xffffffff808d61c9, > >>> which is sys/kern/subr_turnstile.c:297: > >>> > >>>> /* Resort td on the list if needed. */ if > >>>> (!turnstile_adjust_thread(ts, td)) { > >>>> mtx_unlock_spin(&ts->ts_lock); // 297 // return; } > >>> > >>> This sounds like a race condition but I haven't yet able to > >>> track it down... > >> > >> Could you try to isolate the sub-leaf under hw which causes the > >> panic ? Just shot in the dark, do you have Intel GPU gemified > >> driver loaded ? > > > > It seems that it was not hw itself that causes the problem (I > > thought about isolating to sub-leaf and at one point believed it > > was hw.acpi.battery but doing so repeatedly doesn't panic the > > system, with or without INVARIANTS; doing 'sysctl hw' sometimes > > causes panic but not always). > > > > The laptop is running nVidia but it's using i7-3610QM which does > > have Intel GPU, but I have not loaded drm2.ko and the panic is > > reproducible in single user mode. > > > > Cheers, - -- Xin LI > > https://www.delphij.net/ FreeBSD - > > The Power to Serve! Live free or die > > > > > > Xin, did you compile the NVIDIA driver port with clang? I was > > having this issue until I set an exception for the NVIDIA driver > > port to be built with GCC. > > > > Actually, I just remembered (and checked), and what I'm actually > > doing is setting CFLAGS for the NVIDIA driver port to -O0, and > > building with clang. Clang optimizes out important bits, I didn't > > investigate deeply enough to determine what was actually going > > awry... > > Yes my nVidia driver is compiled with clang. I'll try gcc tomorrow, > thanks for the pointer. > > (Note that the panic was a NULL pointer deference and it's a race > condition so I doubt if it's compiler related but will try). > I saw this crash once, on an i386 (No X windows setup) with just the GENERIC kernel config + "options DEBIG_VFS_LOCKS" built with gcc, so I don't think it would be caused by the NVIDIA driver. Just one more data point, rick > Cheers, > > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBCAAGBQJQ64cNAAoJEG80Jeu8UPuzkLwIAKgjgbcBaow64mWzrJ0XtczM > 6Xi4mC0Oq5kdomx0y+Vgks/qTvq28Ff/JqyxN8osD959Vwaq0vbQumFiDtbWCr0h > /MD0w5m7Asdbf8KzJE80il90Vv1/nJrOVdwj3qoNIqtKIomi12CHDKL5zFs2Ja2i > rscN22SBh8+3vV1rBSE6NGzJ7jPSs/B0o73YuIdwj6bUYMiBqHWWGGTfFStNhc4U > 1JX6WWsDdiWxNvGPH5lE3HelSgya+WCltD+B6/8mYaByBQbXD+JBOA9AvX97h2kk > muQROSMOz6OVdGmtM6U/19Bsiv/8kUtItJF2k19Y/eTQEohH/2xBhq+37EG8cqg= > =b9UF > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 14:42:27 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CC96BB00 for ; Tue, 8 Jan 2013 14:42:27 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id 597AD638 for ; Tue, 8 Jan 2013 14:42:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id A48452B42DA0 for ; Tue, 8 Jan 2013 16:42:17 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmfNHTy2MkhR for ; Tue, 8 Jan 2013 16:42:16 +0200 (SAST) Received: from clue.co.za (unknown [197.87.27.111]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 75ECA2B42D9C for ; Tue, 8 Jan 2013 16:42:16 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TsaNb-0001AZ-BR for current@freebsd.org; Tue, 08 Jan 2013 16:42:15 +0200 To: current@freebsd.org From: Ian FREISLICH Subject: -iface option to route(8) is broken X-Attribution: BOFH Date: Tue, 08 Jan 2013 16:42:15 +0200 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 14:42:27 -0000 Hi Adding routes using the -iface option to route(8) doesn't work any more. This was useful to select a specific interface for a route when the remote gateway has the same IP address. Are there plans to restore this functionality? tun0: flags=8051 metric 0 mtu 1492 options=80000 inet 41.135.82.18 --> 41.135.70.1 netmask 0xffffffff Opened by PID 2387 [router] ~ # route add 41.154.2.53 -iface tun0 route: bad address: tun0 It also doesn't work on ngX PPP interfaces. ng1: flags=88d1 metric 0 mtu 1490 inet 197.87.27.111 --> 41.135.70.1 netmask 0xffffffff ng2: flags=88d1 metric 0 mtu 1490 inet 41.135.82.120 --> 41.135.70.1 netmask 0xffffffff [router] ~ # route add 41.154.2.53 -iface ng2 route: bad address: ng2 [router] ~ # route add 41.154.2.53 -interface ng2 route: bad address: ng2 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 15:17:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8C3697C0; Tue, 8 Jan 2013 15:17:46 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward1h.mail.yandex.net (forward1h.mail.yandex.net [IPv6:2a02:6b8:0:f05::10]) by mx1.freebsd.org (Postfix) with ESMTP id 2C939828; Tue, 8 Jan 2013 15:17:46 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward1h.mail.yandex.net (Yandex) with ESMTP id 303CE9E12E7; Tue, 8 Jan 2013 19:17:43 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 8E2E81B40165; Tue, 8 Jan 2013 19:17:42 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id HgO4ginm-HgOeYaJg; Tue, 8 Jan 2013 19:17:42 +0400 Message-ID: <50EC3894.7000801@passap.ru> Date: Tue, 08 Jan 2013 19:17:40 +0400 From: =?UTF-8?B?0JHQvtGA0LjRgSDQodCw0LzQvtGA0L7QtNC+0LI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang 3.2 RC2 miscompiles libgcc? References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <20130106160331.GB1418@mole.fafoe.narf.at> <50EB5868.2050509@FreeBSD.org> In-Reply-To: <50EB5868.2050509@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Stefan Farfeleder , David Chisnall , Nathan Whitehorn , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:17:46 -0000 08.01.2013 03:21, Dimitry Andric пишет: > Can you please try the attached patch, which is a very horrid, atrocious > hack, and will only work for amd64. Then rebuild libgcc with clang, and > please try if this fixes at least some of the crashes... The patch fixed building editors/libreoffice. Without this patch the port segfaulted while doing cppunittest. The system: ----- % uname -a FreeBSD BB051.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r245047: Sat Jan 5 03:19:00 SAMT 2013 bsam@BB051.wart.ru:/usr/obj/usr/src/sys/BB64X amd64 % clang --version FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd10.0 Thread model: posix ----- Thanks! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 15:36:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CB2D5ED7 for ; Tue, 8 Jan 2013 15:36:05 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA7C90C for ; Tue, 8 Jan 2013 15:36:05 +0000 (UTC) Received: from [87.79.192.104] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TsbDa-0000PN-4s for freebsd-current@freebsd.org; Tue, 08 Jan 2013 16:35:58 +0100 Date: Tue, 8 Jan 2013 16:35:38 +0100 From: Fabian Keil To: FreeBSD Current Subject: standards/173421: [patch] strptime() accepts formats that should be rejected Message-ID: <20130108163538.5c392243@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/RSK1S1QWP6PoDhXC0uxkBRT"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:36:05 -0000 --Sig_/RSK1S1QWP6PoDhXC0uxkBRT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Anyone interested in a PR for a strptime() bug coming with a test case and a potential fix? > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D173421 >=20 > >Category: standards > >Responsible: freebsd-standards > >Synopsis: [patch] strptime() accepts formats that should be reject= ed > >Arrival-Date: Tue Nov 06 14:30:00 UTC 2012 Looks like freebsd-standards@ is not the most active mailing list. Fabian --Sig_/RSK1S1QWP6PoDhXC0uxkBRT Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDsPN4ACgkQBYqIVf93VJ0bNACgshMCgG+fmZpOLNjhM2rRx8eU 0S0An3cwT25qnvWqn7OT9siCMoqmSNZT =VtVK -----END PGP SIGNATURE----- --Sig_/RSK1S1QWP6PoDhXC0uxkBRT-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 17:04:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD7C81F1 for ; Tue, 8 Jan 2013 17:04:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A6313DA0 for ; Tue, 8 Jan 2013 17:04:42 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-148-105.hsd1.ca.comcast.net [50.143.148.105]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r08H4eIo074482 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Jan 2013 09:04:41 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50EC51A3.6020909@freebsd.org> Date: Tue, 08 Jan 2013 09:04:35 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ian FREISLICH Subject: Re: -iface option to route(8) is broken References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:04:42 -0000 On 1/8/13 6:42 AM, Ian FREISLICH wrote: > Hi > > Adding routes using the -iface option to route(8) doesn't work any > more. This was useful to select a specific interface for a route > when the remote gateway has the same IP address. Are there plans > to restore this functionality? I agree.. thus was a crucial piece of functionality.. who broke it? > > tun0: flags=8051 metric 0 mtu 1492 > options=80000 > inet 41.135.82.18 --> 41.135.70.1 netmask 0xffffffff > Opened by PID 2387 > > [router] ~ # route add 41.154.2.53 -iface tun0 > route: bad address: tun0 > > It also doesn't work on ngX PPP interfaces. > > ng1: flags=88d1 metric 0 mtu 1490 > inet 197.87.27.111 --> 41.135.70.1 netmask 0xffffffff > ng2: flags=88d1 metric 0 mtu 1490 > inet 41.135.82.120 --> 41.135.70.1 netmask 0xffffffff > > [router] ~ # route add 41.154.2.53 -iface ng2 > route: bad address: ng2 > [router] ~ # route add 41.154.2.53 -interface ng2 > route: bad address: ng2 > > Ian > From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 17:29:06 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8AD6C27; Tue, 8 Jan 2013 17:29:06 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 102D9EBF; Tue, 8 Jan 2013 17:29:05 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r08HSh71012388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 02:28:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id r08HSenl097552; Wed, 9 Jan 2013 02:28:41 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 09 Jan 2013 02:28:21 +0900 (JST) Message-Id: <20130109.022821.161123847814107230.hrs@allbsd.org> To: julian@FreeBSD.org Subject: Re: -iface option to route(8) is broken From: Hiroki Sato In-Reply-To: <50EC51A3.6020909@freebsd.org> References: <50EC51A3.6020909@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jan__9_02_28_21_2013_596)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Wed, 09 Jan 2013 02:28:53 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: ianf@clue.co.za, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:29:06 -0000 ----Security_Multipart(Wed_Jan__9_02_28_21_2013_596)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Elischer wrote in <50EC51A3.6020909@freebsd.org>: ju> On 1/8/13 6:42 AM, Ian FREISLICH wrote: ju> > Hi ju> > ju> > Adding routes using the -iface option to route(8) doesn't work any ju> > more. This was useful to select a specific interface for a route ju> > when the remote gateway has the same IP address. Are there plans ju> > to restore this functionality? ju> ju> I agree.. thus was a crucial piece of functionality.. ju> ju> who broke it? Oh, sorry, it seems I accidentally broke it in the previous commit. It should be fixed now. Please let me know if it still does not work. -- Hiroki ----Security_Multipart(Wed_Jan__9_02_28_21_2013_596)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlDsVzUACgkQTyzT2CeTzy1+CwCgsAM8PGTegjv+qXbMUe9b6d9V vgIAnA2162UR3UqiFGh4uCfrsKSIXH8y =9Xk/ -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jan__9_02_28_21_2013_596)---- From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 17:51:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA88E670; Tue, 8 Jan 2013 17:51:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id C3D4BFD9; Tue, 8 Jan 2013 17:51:04 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-148-105.hsd1.ca.comcast.net [50.143.148.105]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r08Hp2Zh074651 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Jan 2013 09:51:03 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50EC5C81.3020600@freebsd.org> Date: Tue, 08 Jan 2013 09:50:57 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hiroki Sato Subject: Re: -iface option to route(8) is broken References: <50EC51A3.6020909@freebsd.org> <20130109.022821.161123847814107230.hrs@allbsd.org> In-Reply-To: <20130109.022821.161123847814107230.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ianf@clue.co.za, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:51:05 -0000 On 1/8/13 9:28 AM, Hiroki Sato wrote: > Julian Elischer wrote > in <50EC51A3.6020909@freebsd.org>: > > ju> On 1/8/13 6:42 AM, Ian FREISLICH wrote: > ju> > Hi > ju> > > ju> > Adding routes using the -iface option to route(8) doesn't work any > ju> > more. This was useful to select a specific interface for a route > ju> > when the remote gateway has the same IP address. Are there plans > ju> > to restore this functionality? > ju> > ju> I agree.. thus was a crucial piece of functionality.. > ju> > ju> who broke it? > > Oh, sorry, it seems I accidentally broke it in the previous commit. > It should be fixed now. Please let me know if it still does not > work. thankyou > > -- Hiroki From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 08:56:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CCDF1985; Wed, 9 Jan 2013 08:56:07 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 766E7AA2; Wed, 9 Jan 2013 08:56:06 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TsrS8-002KcJ-05>; Wed, 09 Jan 2013 09:56:04 +0100 Received: from munin.geoinf.fu-berlin.de ([130.133.86.110]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TsrS7-0022j4-Ug>; Wed, 09 Jan 2013 09:56:03 +0100 Message-ID: <50ED30B9.7040101@zedat.fu-berlin.de> Date: Wed, 09 Jan 2013 09:56:25 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: gljennjohn@googlemail.com Subject: Re: loopback interface broken on current References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> <201301030355.r033t4aI001542@pozo.com> <90299.1357212618@pf2.ed.niigata-u.ac.jp> <20130104094532.4a921e47@ernst.jennejohn.org> In-Reply-To: <20130104094532.4a921e47@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.110 Cc: freebsd-current@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 08:56:08 -0000 On 01/04/13 09:45, Gary Jennejohn wrote: > On Thu, 03 Jan 2013 20:30:18 +0900 > KAHO Toshikazu wrote: > >> Hello, >> >>> There is still ====>ifa_del_loopback_route: deletion failed: 3 >>> that wasn't there before,but the 127.0.0.1 seems to be configured now: >> >> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf? >> If you have it, try to remove it. >> >> I think something broken, but people using automatic configuration >> don't notice the breakage. >> > > Something is definitely broken because I don't have network_interfaces > in /etc/rc.conf but my lo0 does not have even ipv6 addresses assigned. > Same here. The OS: FreeBSD 10.0-CURRENT/amd64 r245218. Since I have three boxes running approximately the same configurations (I share my configs between lab and home), but different hardware, I'm confused. The symptoms in my case are: Booting the box is all right until it comes to the start of nfsuserd. Prior to that, ntp adjusts the clock properly with an external time server - so this implies network connectivity. Start of nfsuserd is stuck forever. Interrupting the start of nfsuserd restarts several other services, but winbindd and slapd (OpenLDAP) get stuck again. In case I also interrupt them, there are other services which will not start. Trying to login as root on the console fails - I never get a password tag after having issued the root login name. Since this machine is bound to a local and remote OpenLDAP backend, I'm used to have an emergency local user which usually works - but this time, neither root nor this user can login! Bringing up the box in SINGLEUSER allows me to login. Investigating the network interfaces with ifconfig reveals, that the loopback did not get assigned to any inet 127.0.0.1 address. Sometimes there is only inet6 linklocal address, some nd6 options, but sometimes even IPv6 assignments do not show up. In a desperate move I tried to recompile a kernel. In /etc/src.conf, I recompile also the kernel module for the most recent virtual-box kernel module. While the kernel and module (*.ko) get installed properly, the recompilation of the VirtualBox port gets stuck when the system unfolds the source tarball. Hitting Ctrl-T say "sbwait" for the process. Other processes seem to have trouble getting a proper ownership or UID for a file - this is my naiv interpretation what I see at the surface. The funny thing is, that after several reboots, the box gets up as normal. I revealed this issue approx. two weeks ago when out of the sudden the amd automounter stopped working and the NFSv4 network drives didn't attach properly and made the whole box being stuck. Sorry for the more superficial description of the problem ... Has the problem been identified? Is there a solution? Since it affects only my very modern hardware (i7-3930, 32GB RAM, ASUS P9X79 WS mainboard), while a very same setup on older hardware (our local server is Intel Q6600 with 8GB RAM and and oldish Intel P45-chipset based mainboard), both systems do have Intel NICs, I'm a bit confused. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 08:59:22 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 93072ACA for ; Wed, 9 Jan 2013 08:59:22 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2F202ADD for ; Wed, 9 Jan 2013 08:59:21 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id r098x7oU075214; Wed, 9 Jan 2013 12:59:08 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id r098x7sM075213; Wed, 9 Jan 2013 12:59:07 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 9 Jan 2013 12:59:07 +0400 From: Gleb Smirnoff To: "Hartmann, O." Subject: Re: loopback interface broken on current Message-ID: <20130109085907.GJ66284@glebius.int.ru> References: <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> <201301030355.r033t4aI001542@pozo.com> <90299.1357212618@pf2.ed.niigata-u.ac.jp> <20130104094532.4a921e47@ernst.jennejohn.org> <50ED30B9.7040101@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <50ED30B9.7040101@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 08:59:22 -0000 On Wed, Jan 09, 2013 at 09:56:25AM +0100, Hartmann, O. wrote: H> Same here. H> The OS: FreeBSD 10.0-CURRENT/amd64 r245218. Since I have three boxes H> running approximately the same configurations (I share my configs H> between lab and home), but different hardware, I'm confused. H> H> The symptoms in my case are: H> H> Booting the box is all right until it comes to the start of nfsuserd. H> Prior to that, ntp adjusts the clock properly with an external time H> server - so this implies network connectivity. Start of nfsuserd is H> stuck forever. H> Interrupting the start of nfsuserd restarts several other services, but H> winbindd and slapd (OpenLDAP) get stuck again. In case I also interrupt H> them, there are other services which will not start. H> H> Trying to login as root on the console fails - I never get a password H> tag after having issued the root login name. Since this machine is bound H> to a local and remote OpenLDAP backend, I'm used to have an emergency H> local user which usually works - but this time, neither root nor this H> user can login! H> H> Bringing up the box in SINGLEUSER allows me to login. Investigating the H> network interfaces with ifconfig reveals, that the loopback did not get H> assigned to any inet 127.0.0.1 address. Sometimes there is only inet6 H> linklocal address, some nd6 options, but sometimes even IPv6 assignments H> do not show up. H> H> In a desperate move I tried to recompile a kernel. In /etc/src.conf, I H> recompile also the kernel module for the most recent virtual-box kernel H> module. While the kernel and module (*.ko) get installed properly, the H> recompilation of the VirtualBox port gets stuck when the system unfolds H> the source tarball. Hitting Ctrl-T say "sbwait" for the process. Other H> processes seem to have trouble getting a proper ownership or UID for a H> file - this is my naiv interpretation what I see at the surface. H> H> The funny thing is, that after several reboots, the box gets up as normal. H> H> I revealed this issue approx. two weeks ago when out of the sudden the H> amd automounter stopped working and the NFSv4 network drives didn't H> attach properly and made the whole box being stuck. H> H> Sorry for the more superficial description of the problem ... H> H> Has the problem been identified? Is there a solution? Since it affects H> only my very modern hardware (i7-3930, 32GB RAM, ASUS P9X79 WS H> mainboard), while a very same setup on older hardware (our local server H> is Intel Q6600 with 8GB RAM and and oldish Intel P45-chipset based H> mainboard), both systems do have Intel NICs, I'm a bit confused. This looks unrelated to the problem discussed, because r245218 is later than r244989 which backed out my change. Can you do a binary search to identify which revision broke things? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 10:55:47 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED8F9C4F for ; Wed, 9 Jan 2013 10:55:47 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 920DE3F9 for ; Wed, 9 Jan 2013 10:55:47 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id r09AdmWU002545 for ; Wed, 9 Jan 2013 19:39:48 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili14) with ESMTP id r09Adm529282 for ; Wed, 9 Jan 2013 19:39:48 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi16) id r09Admn7001273 for freebsd-current@FreeBSD.org; Wed, 9 Jan 2013 19:39:48 +0900 Received: from localhost by lomi16.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id r09Admx1001239 for ; Wed, 9 Jan 2013 19:39:48 +0900 Date: Wed, 09 Jan 2013 19:39:45 +0900 (JST) Message-Id: <20130109.193945.561808600309975779.okuno.kohji@jp.panasonic.com> To: freebsd-current@FreeBSD.org Subject: arm: cpu_switch() has bug? From: Kohji Okuno Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 10:55:48 -0000 Hi, I have doubt if cpu_switch() of arm has a bug. In swtch.S:L.334, if newtd->td_pcb (this is in stack pointer for kernel) has an address accessed first for the old(current) thread, data_abort_fault may occur. When data_abort_fault occurs, data_abort_handler() tries to solve this address from kernel_map. In this time, curthread and curpcb are already updated in swtch.S:L.223-231. As this result, data_abort_handler() will occur data_abort_fault in trap.c:L.301, again. When I check, in other CPUs, after updating the root pointer of MMU, curthread and curpcb are updated. Would you please check this? Thanks, Kohji Okuno <> 215 ENTRY(cpu_switch) 216 stmfd sp!, {r4-r7, lr} 217 mov r6, r2 /* Save the mutex */ 218 219 .Lswitch_resume: 220 /* rem: r0 = old lwp */ 221 /* rem: interrupts are disabled */ 222 223 /* Process is now on a processor. */ 224 /* We have a new curthread now so make a note it */ 225 GET_CURTHREAD_PTR(r7) 226 str r1, [r7] 227 228 /* Hook in a new pcb */ 229 GET_PCPU(r7) 230 ldr r2, [r1, #TD_PCB] 231 str r2, [r7, #PC_CURPCB] 232 233 /* rem: r1 = new process */ 234 /* rem: interrupts are enabled */ ==== SNIP ==== 298 /* rem: r2 = old PCB */ 299 /* rem: r9 = new PCB */ 300 /* rem: interrupts are enabled */ 301 302 #ifdef ARM_VFP_SUPPORT 303 /* 304 * vfp_store will clear pcpu->pc_vfpcthread, save 305 * registers and state, and modify the control as needed. 306 * a future exception will bounce the backup settings in the fp unit. 307 * XXX vfp_store can't change r4 308 */ 309 GET_PCPU(r7) 310 ldr r8, [r7, #(PC_VFPCTHREAD)] 311 cmp r4, r8 /* old thread used vfp? */ 312 bne 1f /* no, don't save */ 313 cmp r1, r4 /* same thread ? */ 314 beq 1f /* yes, skip vfp store */ 315 #ifdef SMP 316 ldr r8, [r7, #(PC_CPU)] /* last used on this cpu? */ 317 ldr r3, [r2, #(PCB_VFPCPU)] 318 cmp r8, r3 /* last cpu to use these registers? */ 319 bne 1f /* no. these values are stale */ 320 #endif 321 add r0, r2, #(PCB_VFPSTATE) 322 bl _C_LABEL(vfp_store) 323 1: 324 #endif /* ARM_VFP_SUPPORT */ 325 326 /* r1 now free! */ 327 328 /* Third phase : restore saved context */ 329 330 /* rem: r2 = old PCB */ 331 /* rem: r9 = new PCB */ 332 /* rem: interrupts are enabled */ 333 334 ldr r5, [r9, #(PCB_DACR)] /* r5 = new DACR */ 335 mov r2, #DOMAIN_CLIENT 336 cmp r5, r2, lsl #(PMAP_DOMAIN_KERNEL * 2) /* Sw to kernel thread? */ 337 beq .Lcs_context_switched /* Yup. Don't flush cache */ 338 mrc p15, 0, r0, c3, c0, 0 /* r0 = old DACR */ <> 224 void 225 data_abort_handler(trapframe_t *tf) 226 { 227 struct vm_map *map; 228 struct pcb *pcb; 229 struct thread *td; 230 u_int user, far, fsr; 231 vm_prot_t ftype; 232 void *onfault; 233 vm_offset_t va; 234 int error = 0; 235 struct ksig ksig; 236 struct proc *p; 237 238 239 /* Grab FAR/FSR before enabling interrupts */ 240 far = cpu_faultaddress(); 241 fsr = cpu_faultstatus(); 242 #if 0 243 printf("data abort: %p (from %p %p)\n", (void*)far, (void*)tf->tf_pc, 244 (void*)tf->tf_svc_lr); 245 #endif 246 247 /* Update vmmeter statistics */ 248 #if 0 249 vmexp.traps++; 250 #endif 251 252 td = curthread; 253 p = td->td_proc; 254 255 PCPU_INC(cnt.v_trap); 256 /* Data abort came from user mode? */ 257 user = TRAP_USERMODE(tf); 258 259 if (user) { 260 td->td_pticks = 0; 261 td->td_frame = tf; 262 if (td->td_ucred != td->td_proc->p_ucred) 263 cred_update_thread(td); 264 265 } 266 /* Grab the current pcb */ 267 pcb = td->td_pcb; ==== SNIP ==== 299 300 /* fusubailout is used by [fs]uswintr to avoid page faulting */ 301 if (__predict_false(pcb->pcb_onfault == fusubailout)) { 302 tf->tf_r0 = EFAULT; 303 tf->tf_pc = (register_t)(intptr_t) pcb->pcb_onfault; 304 return; 305 } From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 18:52:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7379EC57 for ; Wed, 9 Jan 2013 18:52:49 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [IPv6:2a01:4f8:162:1142::2]) by mx1.freebsd.org (Postfix) with ESMTP id 16F626D9 for ; Wed, 9 Jan 2013 18:52:49 +0000 (UTC) Received: from cpos1.nexxtmobile.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id B49253FA4 for ; Wed, 9 Jan 2013 19:52:47 +0100 (CET) X-Virus-Scanned: amavisd-new at nexxtmobile.de Received: from mail.solomo.de ([127.0.0.1]) by cpos1.nexxtmobile.de (cpos1.nexxtmobile.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3pZLY5gfGfMp for ; Wed, 9 Jan 2013 19:52:45 +0100 (CET) Received: from nibbler-osx-wlan.fritz.box (unknown [85.22.126.46]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 92AD73F9B for ; Wed, 9 Jan 2013 19:52:45 +0100 (CET) Message-ID: <50EDBC7B.5070408@smeets.im> Date: Wed, 09 Jan 2013 19:52:43 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0a1 MIME-Version: 1.0 To: "current@freebsd.org" Subject: panic: vputx: missed vn_close X-Enigmail-Version: 1.5a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AURNUGKMHGFSDRPGFRWA" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 18:52:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AURNUGKMHGFSDRPGFRWA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I got this while building packages with poudriere. I'm running r245188. Let me know if you need anything else from the dump. Florian VNASSERT failed 0xfffffe04fda5bba0: tag zfs, type VREG usecount 1, writecount 1, refcount 1 mountedhere 0 flags (VI_ACTIVE) VI_LOCKed v_object 0xfffffe062f6479f8 ref 0 pages 0 lock type zfs: EXCL by thread 0xfffffe00bd683480 (pid 34602, umount, tid 100578) panic: vputx: missed vn_close cpuid =3D 3 Uptime: 9h25m23s Dumping 13255 out of 32647 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% [...] (kgdb) where #0 doadump (textdump=3D1) at pcpu.h:229 #1 0xffffffff804c4ab7 in kern_reboot (howto=3D260) at /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:446 #2 0xffffffff804c4fc6 in vpanic (fmt=3D, ap=3D) at /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:753 #3 0xffffffff804c4e56 in kassert_panic (fmt=3D) at /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:641 #4 0xffffffff8055714d in vputx (vp=3D0xfffffe04fda5bba0, func=3D2) at /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2243 #5 0xffffffff80d6b42f in null_reclaim (ap=3D) at /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/nu= ll_vnops.c:743 #6 0xffffffff8070aee8 in VOP_RECLAIM_APV (vop=3D, a=3D) at vnode_if.c:1959 #7 0xffffffff8055844c in vgonel (vp=3D0xfffffe04fda5b7c0) at vnode_if.h:= 830 #8 0xffffffff80557a7f in vflush (mp=3D0xfffffe0533ce3cc0, rootrefs=3D1, flags=3D2, td=3D0xfffffe00bd683480) at /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2625 #9 0xffffffff80d6aa4e in nullfs_unmount (mp=3D0xfffffe0533ce3cc0, mntflags=3D) at /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/nu= ll_vfsops.c:250 #10 0xffffffff805502cf in dounmount (mp=3D0xfffffe0533ce3cc0, flags=3D134742016, td=3D) at /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1314 #11 0xffffffff8054ff8b in sys_unmount (td=3D0xfffffe00bd683480, uap=3D0xffffff90d2c87a40) at /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1211 #12 0xffffffff806b4845 in amd64_syscall (td=3D0xfffffe00bd683480, traced=3D0) at subr_syscall.c:134 #13 0xffffffff8069d04b in Xfast_syscall () at exception.S:387 #14 0x0000000800882ffa in ?? () Previous frame inner to this frame (corrupt stack?) ------enig2AURNUGKMHGFSDRPGFRWA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlDtvHsACgkQapo8P8lCvwkkpQCgyoPY9/FsyGxkp2Q1L2r2yfMo kJMAoLCLL3iLiG7j8z/3V5+XU8t/HFyw =GMWw -----END PGP SIGNATURE----- ------enig2AURNUGKMHGFSDRPGFRWA-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 20:53:35 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C097A76; Wed, 9 Jan 2013 20:53:35 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7FD38D0F; Wed, 9 Jan 2013 20:53:35 +0000 (UTC) Received: from girgBook.local (c-2754e155.1525-1-64736c12.cust.bredbandsbolaget.se [85.225.84.39]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by melon.pingpong.net (Postfix) with ESMTPSA id CA71512FEF; Wed, 9 Jan 2013 21:46:46 +0100 (CET) Message-ID: <50EDD736.8000102@FreeBSD.org> Date: Wed, 09 Jan 2013 21:46:46 +0100 From: Palle Girgensohn User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: Andriy Gapon Subject: Re: gptzfsboot error using HP Smart Array P410i Controller References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> <4F4FECA4.10504@FreeBSD.org> <50A37C2D.9010607@FreeBSD.org> In-Reply-To: <50A37C2D.9010607@FreeBSD.org> X-Enigmail-Version: 1.2.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Julian Akehurst , Bjorn Larsson , freebsd-current@FreeBSD.org, Christoph Hoffmann , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:53:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, this work like a charm. Super! Booted with no problems. Well done! Palle Andriy Gapon skrev: > Guys, > > if you still have the hardware and use FreeBSD, could you please try > r243025? > > http://svnweb.freebsd.org/base?view=revision&revision=243025 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQ7dc2AAoJEIhV+7FrxBJDttEIAMUsq/pmv9ZNPGQ7lk2vFVtk sP3TyqSj08q7aLJvURbCcOc20vUZp/TlirSrN8tL1h4O9HnPUdTQNIxlAN5ylrsi QkpDgK2kSM/ybOjWaFe0Olz3s/+47XJKfOEJsN8qLsmChnO7RUnjmJxz1HWCqWMf eNg7UnNOKZq0SyiZLDG8zF44Q0iU09voCFSAN/kXQl0YtxGbqt+HuI68w9cThRSr +jZmGYrnxHQxdqBagAoUU3mMLh9oGRhRLbfd5noXzJ3JWc+ljpjMt/3/YwZj5IcF BUydnCy9uiUepyAQSKFsJ97WsgeWwYxFOEWuWn/6ar3Shsoy5+9E/4d57AD9J5c= =AkUA -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 20:56:19 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D6B326C; Wed, 9 Jan 2013 20:56:19 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1C791D56; Wed, 9 Jan 2013 20:56:19 +0000 (UTC) Received: from girgBook.local (c-2754e155.1525-1-64736c12.cust.bredbandsbolaget.se [85.225.84.39]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by melon.pingpong.net (Postfix) with ESMTPSA id 0B0FE120A2; Wed, 9 Jan 2013 21:56:17 +0100 (CET) Message-ID: <50EDD96F.5070002@FreeBSD.org> Date: Wed, 09 Jan 2013 21:56:15 +0100 From: Palle Girgensohn User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: Andriy Gapon Subject: Re: gptzfsboot error using HP Smart Array P410i Controller References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> <4F4FECA4.10504@FreeBSD.org> <50A37C2D.9010607@FreeBSD.org> In-Reply-To: <50A37C2D.9010607@FreeBSD.org> X-Enigmail-Version: 1.2.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bjorn Larsson , freebsd-current@FreeBSD.org, Christoph Hoffmann , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:56:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This was for an HP DL380 G5, by the way. I'll try it on a G6 later as well, I reckon the outcome will be similar. Palle Andriy Gapon skrev: > Guys, > > if you still have the hardware and use FreeBSD, could you please try > r243025? > > http://svnweb.freebsd.org/base?view=revision&revision=243025 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQ7dlvAAoJEIhV+7FrxBJDyRIH/0ieSUwN9Ev8hsYIniCRtFMH 79QqQI0XmnASgNh+TXxQABOGUQ1SFUqi2sDsOv+lyPGGS5RIWIzy9GGr91+LlwJu bLexZqXCIzWjZwpJsIba2wF41Iwc7EDGy6cA28n+O3pfqfazewgvPWWIpcEJ/Rng sUTQOozZUhblNmvlcsdVpRw1i9QYhivy1d3Yj10AzDfioKXdvRT1d5//BmJ1aEh+ I9+JpG7c8geMLQ+z/mER8tbTg7/Sm+7qwAjM8bFg1lBdDKYryHC8d/nO4XFSE2IO DCrJRmoe8bormQWZVh4gP16phVm7cFWFXBn3JsRqJYYDrDMnm+LT4AXL/1v5BKY= =CBpm -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 20:59:08 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DA1C23E2; Wed, 9 Jan 2013 20:59:08 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id 89720D8B; Wed, 9 Jan 2013 20:59:08 +0000 (UTC) Received: from girgBook.local (c-2754e155.1525-1-64736c12.cust.bredbandsbolaget.se [85.225.84.39]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by melon.pingpong.net (Postfix) with ESMTPSA id 90BEE12113; Wed, 9 Jan 2013 21:59:06 +0100 (CET) Message-ID: <50EDDA1A.7040305@FreeBSD.org> Date: Wed, 09 Jan 2013 21:59:06 +0100 From: Palle Girgensohn User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: Andriy Gapon Subject: Re: gptzfsboot error using HP Smart Array P410i Controller References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> <4F4FECA4.10504@FreeBSD.org> <50A37C2D.9010607@FreeBSD.org> In-Reply-To: <50A37C2D.9010607@FreeBSD.org> X-Enigmail-Version: 1.2.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bjorn Larsson , freebsd-current@FreeBSD.org, Christoph Hoffmann , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:59:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, jumped the gun here... it booted first time, now it is back at the same fail prompt... gptzfsboot: error 1 lba 32 gptzfsboot: error 1 lba 1 gptzfsboot: No ZFS pools located, can't boot Andriy Gapon skrev: > Guys, > > if you still have the hardware and use FreeBSD, could you please try > r243025? > > http://svnweb.freebsd.org/base?view=revision&revision=243025 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQ7doaAAoJEIhV+7FrxBJDRd0IAIaufFeA6TkvVv8ytwtoKyac M1d/181hq92PXjGKkqPsP7HB2z3c7Op9zMURh6yia0fUrP68ryw6YVrT22cksNAU W8WXvhXb80cGw9JKT6lerkqFezex8SInnxjKEiEs93ZRRS98nN2aasu+G5DUCaLK Fag/QUVJsTfriVpSy8RywKj3AVo2CN6qAoiT/wg+jg7Oqf/QkY9/0cxcrQtrjUJ6 2DTkHs6G3IfHUDmZGpfvlkBwJmbgc90dCC1F/BWsH2MTICcHxEZS8oVliaIgkCWp wSazAX0x0aYONnYVzIkeJvh/a1ahuVlAatlnuw0IcwPfc/h6wfYZgFIan40DUnY= =13n2 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 22:57:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7C42E113; Wed, 9 Jan 2013 22:57:11 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2452728A; Wed, 9 Jan 2013 22:57:10 +0000 (UTC) Received: from girgBook.local (c-2754e155.1525-1-64736c12.cust.bredbandsbolaget.se [85.225.84.39]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by melon.pingpong.net (Postfix) with ESMTPSA id 3A57B12979; Wed, 9 Jan 2013 23:57:08 +0100 (CET) Message-ID: <50EDF5C2.8020609@FreeBSD.org> Date: Wed, 09 Jan 2013 23:57:06 +0100 From: Palle Girgensohn User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: Christoph Hoffmann Subject: Re: gptzfsboot error using HP Smart Array P410i Controller References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> <4F4FECA4.10504@FreeBSD.org> In-Reply-To: <4F4FECA4.10504@FreeBSD.org> X-Enigmail-Version: 1.2.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christoph Hoffmann , Andriy Gapon , Bjorn Larsson , freebsd-current@freebsd.org, Daniel Kalchev , Julian Akehurst X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 22:57:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Palle Girgensohn skrev: > Hi! > > This is still happening with FreeBSD 9.0-RELEASE, as I have just > discovered. The hack works like a charm, but seems kind of odd... :) > > Any progress in getting a "real" fix into the repository? Any risks > with the hack - is it likely to believe that it will suddenly or > sporadically fail? > > Cheers, Palle > > Christoph Hoffmann skrev: >> Hello Daniel, >> >> Last time I checked up on the issue was on the 23rd of September, >> it was not fixed then. I was able to to boot from drive 0x80 after >> adding: >> >> *** zfsboot.c.orig Fri Sep 23 18:03:26 2011 --- zfsboot.c Fri Sep >> 23 18:47:44 2011 *************** *** 459,464 **** --- 459,465 ---- >> heap_end = (char *) PTOV(bios_basemem); } >> >> + printf("Hello! I am a hack.\n"); dsk = malloc(sizeof(struct >> dsk)); dsk->drive = *(uint8_t *)PTOV(ARGS); dsk->type = dsk->drive >> & DRV_HARD ? TYPE_AD : TYPE_FD; >> >> I am inclined to think that this is related to the way how we >> compile this code, especially when run on the following particular >> processor: >> >> 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is >> enabled Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz QPI Speed: 5.8 >> GT/s. >> >> >> Regards, >> >> Christoph >> >> >> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote: >> >>> Has this issue been resolved somehow? Sane method to build >>> gptzfsboot that will run on HP's P410i? Hi, This is still happening with 9.2-RELEASE on a HP DL 380 G5: gptzfsboot: error 1 lba 32 gptzfsboot: error 1 lba 1 gptzfsboot: No ZFS pools located, can't boot Andriy suggested the latest sys/boot/i386/common/edd.h@243024 from head, but unfortunately it makes no difference. The printf hack above still works fine though. Palle -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQ7fXCAAoJEIhV+7FrxBJDKKsIALihEN7Ohc2w/d1bCHM0JkPg JdLSQzKa96YBH29vhWbhLpxAd/x/Vkis0H5Kv96e2M9Bg6aiWGXZuChlyzEu8ZBQ +q6hqXYcAQJEYzP2n9jWOCcYelYVmmtyLgKLtbx5GQeYkCdS98Icad9cOKWPZYDN D2aMslLdCVS99RJrvMvtNj3X5roafRfQAXDoTXng/c1VpV1YoXmhHcLPVP2jGP8v F29Vl5K/24d+CHA3HkUqi7WJ4xyodJSPOpjXtSyLs0mMEMPTY9E9kcp+OFj1JXh4 fnEK3wFIT1g7lpYQK9SF3bHJxu6o9sb67jKYynkMhP6jsCpLMkLMRWuseA22d+0= =3gJo -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 23:40:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 37D08576; Wed, 9 Jan 2013 23:40:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7F230384; Wed, 9 Jan 2013 23:40:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r09Ne8li016220; Thu, 10 Jan 2013 01:40:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r09Ne8li016220 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r09Ne7qp016151; Thu, 10 Jan 2013 01:40:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 10 Jan 2013 01:40:07 +0200 From: Konstantin Belousov To: Florian Smeets Subject: Re: panic: vputx: missed vn_close Message-ID: <20130109234007.GJ2561@kib.kiev.ua> References: <50EDBC7B.5070408@smeets.im> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ublo+h3cBgJ33ahC" Content-Disposition: inline In-Reply-To: <50EDBC7B.5070408@smeets.im> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: pho@freebsd.org, "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 23:40:18 -0000 --Ublo+h3cBgJ33ahC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 09, 2013 at 07:52:43PM +0100, Florian Smeets wrote: > Hi, >=20 > I got this while building packages with poudriere. I'm running r245188. >=20 > Let me know if you need anything else from the dump. >=20 > Florian >=20 > VNASSERT failed > 0xfffffe04fda5bba0: tag zfs, type VREG > usecount 1, writecount 1, refcount 1 mountedhere 0 > flags (VI_ACTIVE) > VI_LOCKed v_object 0xfffffe062f6479f8 ref 0 pages 0 > lock type zfs: EXCL by thread 0xfffffe00bd683480 (pid 34602, umount, > tid 100578) > panic: vputx: missed vn_close > cpuid =3D 3 > Uptime: 9h25m23s > Dumping 13255 out of 32647 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >=20 > [...] >=20 > (kgdb) where > #0 doadump (textdump=3D1) at pcpu.h:229 > #1 0xffffffff804c4ab7 in kern_reboot (howto=3D260) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:446 > #2 0xffffffff804c4fc6 in vpanic (fmt=3D, ap=3D optimized out>) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:753 > #3 0xffffffff804c4e56 in kassert_panic (fmt=3D) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:641 > #4 0xffffffff8055714d in vputx (vp=3D0xfffffe04fda5bba0, func=3D2) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2243 > #5 0xffffffff80d6b42f in null_reclaim (ap=3D) at > /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/nu= ll_vnops.c:743 > #6 0xffffffff8070aee8 in VOP_RECLAIM_APV (vop=3D, > a=3D) at vnode_if.c:1959 > #7 0xffffffff8055844c in vgonel (vp=3D0xfffffe04fda5b7c0) at vnode_if.h:= 830 > #8 0xffffffff80557a7f in vflush (mp=3D0xfffffe0533ce3cc0, rootrefs=3D1, > flags=3D2, td=3D0xfffffe00bd683480) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2625 > #9 0xffffffff80d6aa4e in nullfs_unmount (mp=3D0xfffffe0533ce3cc0, > mntflags=3D) > at > /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/nu= ll_vfsops.c:250 > #10 0xffffffff805502cf in dounmount (mp=3D0xfffffe0533ce3cc0, > flags=3D134742016, td=3D) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1314 > #11 0xffffffff8054ff8b in sys_unmount (td=3D0xfffffe00bd683480, > uap=3D0xffffff90d2c87a40) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1211 > #12 0xffffffff806b4845 in amd64_syscall (td=3D0xfffffe00bd683480, > traced=3D0) at subr_syscall.c:134 > #13 0xffffffff8069d04b in Xfast_syscall () at exception.S:387 > #14 0x0000000800882ffa in ?? () > Previous frame inner to this frame (corrupt stack?) >=20 I was able to reproduce it locally. I think that you need to have a file opened for write on the nullfs mount, and then do forced unmount of the mount, while file is still open. The patch below fixed it for me. diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c index cc35d81..3be7366 100644 --- a/sys/fs/nullfs/null_vnops.c +++ b/sys/fs/nullfs/null_vnops.c @@ -740,6 +740,13 @@ null_reclaim(struct vop_reclaim_args *ap) vp->v_object =3D NULL; vp->v_vnlock =3D &vp->v_lock; VI_UNLOCK(vp); + + /* + * If we were opened for write, we borrowed one write + * reference to the lower vnode. Undo the reference now. + */ + if (vp->v_writecount > 0) + VOP_ADD_WRITECOUNT(lowervp, -1); vput(lowervp); free(xp, M_NULLFSNODE); =20 --Ublo+h3cBgJ33ahC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7f/WAAoJEJDCuSvBvK1BFgAP/23/mb2Zgdn1dJwgwGSY6e2E UN2Gsw4mclgJgciSBzWwD/RbNKAu0NrlUTc76TMPqbfM4tp7QCKL7keH+m1u48e3 h2kQhmkazWskWy9rtNp796LOB3dESEkipLy4cQctkNDFlx/QjoDNP8CcZagpctjZ wGrQVLsoOwOuLF45XmoG31XULer93pZaQFQke71af3gW6yGSkOpQzzQMtlwxIHXJ boPHQCQBnKGBbc9d0kRX8uFjW3dwxONkaN179bMSFlIw2NBs0c11WvtWLUiQQFBU +PSC+Sh/tSusDj9oBz4jD5Kftx0z3WJVWOUcx2ZPzlAAPHaJAkr99ggEnpea94XD RUEL45oG+y0V8TzITpWaM4ybwzXl8B9DQYCa5U8PIzl1OlqhDecjFgyKQY0y9k22 r1eCw65LHjebt7dk9jAcGK7AP/DTDYsSIU1xqw+NyM8kzOGaxNWjSEIE5vl3EOon XLuVDo8eak5gqkfoTMdTxgQ2clcMUGBuDar0Pfnz2EIXMTjCM3sz2xKXGFfonauP zOU88l5g5mQ84GWjcwaYtvuWl5ukhMNlnyVWN1QOWNfZBmJUaz1SHkoRnEclP9sY /p7CfQLwT965UkbN859aB6OuV6TvRgZjQJWNScymZcjySUd22rVUo/qz2oY5B+39 iruVs8zGvZ99xS+YK2Ow =xe7n -----END PGP SIGNATURE----- --Ublo+h3cBgJ33ahC-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 10 09:09:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0076311 for ; Thu, 10 Jan 2013 09:09:15 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 5ECF7EDE for ; Thu, 10 Jan 2013 09:09:14 +0000 (UTC) Received: (qmail 86217 invoked from network); 10 Jan 2013 09:02:32 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay01.pair.com with SMTP; 10 Jan 2013 09:02:32 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r0A92VXe001810; Thu, 10 Jan 2013 10:02:31 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r0A92VJi001809; Thu, 10 Jan 2013 10:02:31 +0100 (CET) (envelope-from pho) Date: Thu, 10 Jan 2013 10:02:31 +0100 From: Peter Holm To: Konstantin Belousov Subject: Re: panic: vputx: missed vn_close Message-ID: <20130110090231.GA1746@x2.osted.lan> References: <50EDBC7B.5070408@smeets.im> <20130109234007.GJ2561@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130109234007.GJ2561@kib.kiev.ua> User-Agent: Mutt/1.4.2.3i Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 09:09:15 -0000 On Thu, Jan 10, 2013 at 01:40:07AM +0200, Konstantin Belousov wrote: > On Wed, Jan 09, 2013 at 07:52:43PM +0100, Florian Smeets wrote: > > Hi, > > > > I got this while building packages with poudriere. I'm running r245188. > > > > Let me know if you need anything else from the dump. > > > > Florian > > > > VNASSERT failed > > 0xfffffe04fda5bba0: tag zfs, type VREG > > usecount 1, writecount 1, refcount 1 mountedhere 0 > > flags (VI_ACTIVE) > > VI_LOCKed v_object 0xfffffe062f6479f8 ref 0 pages 0 > > lock type zfs: EXCL by thread 0xfffffe00bd683480 (pid 34602, umount, > > tid 100578) > > panic: vputx: missed vn_close > > cpuid = 3 > > Uptime: 9h25m23s > > Dumping 13255 out of 32647 > > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > > > [...] > > > > (kgdb) where > > #0 doadump (textdump=1) at pcpu.h:229 > > #1 0xffffffff804c4ab7 in kern_reboot (howto=260) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:446 > > #2 0xffffffff804c4fc6 in vpanic (fmt=, ap= > optimized out>) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:753 > > #3 0xffffffff804c4e56 in kassert_panic (fmt=) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:641 > > #4 0xffffffff8055714d in vputx (vp=0xfffffe04fda5bba0, func=2) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2243 > > #5 0xffffffff80d6b42f in null_reclaim (ap=) at > > /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:743 > > #6 0xffffffff8070aee8 in VOP_RECLAIM_APV (vop=, > > a=) at vnode_if.c:1959 > > #7 0xffffffff8055844c in vgonel (vp=0xfffffe04fda5b7c0) at vnode_if.h:830 > > #8 0xffffffff80557a7f in vflush (mp=0xfffffe0533ce3cc0, rootrefs=1, > > flags=2, td=0xfffffe00bd683480) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2625 > > #9 0xffffffff80d6aa4e in nullfs_unmount (mp=0xfffffe0533ce3cc0, > > mntflags=) > > at > > /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c:250 > > #10 0xffffffff805502cf in dounmount (mp=0xfffffe0533ce3cc0, > > flags=134742016, td=) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1314 > > #11 0xffffffff8054ff8b in sys_unmount (td=0xfffffe00bd683480, > > uap=0xffffff90d2c87a40) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1211 > > #12 0xffffffff806b4845 in amd64_syscall (td=0xfffffe00bd683480, > > traced=0) at subr_syscall.c:134 > > #13 0xffffffff8069d04b in Xfast_syscall () at exception.S:387 > > #14 0x0000000800882ffa in ?? () > > Previous frame inner to this frame (corrupt stack?) > > > > I was able to reproduce it locally. I think that you need to have a file > opened for write on the nullfs mount, and then do forced unmount of > the mount, while file is still open. > > The patch below fixed it for me. > > diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c > index cc35d81..3be7366 100644 > --- a/sys/fs/nullfs/null_vnops.c I've verified the scenario and are now testing with your patch. - Peter From owner-freebsd-current@FreeBSD.ORG Thu Jan 10 15:48:35 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DB7C77BD; Thu, 10 Jan 2013 15:48:35 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8372063E; Thu, 10 Jan 2013 15:48:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TtKMl-000Sdl-5B>; Thu, 10 Jan 2013 16:48:27 +0100 Received: from e178006081.adsl.alicedsl.de ([85.178.6.81] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TtKMl-0042CT-0d>; Thu, 10 Jan 2013 16:48:27 +0100 Message-ID: <50EEE2C2.8050404@zedat.fu-berlin.de> Date: Thu, 10 Jan 2013 16:48:18 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: loopback interface broken on current References: <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> <201301030355.r033t4aI001542@pozo.com> <90299.1357212618@pf2.ed.niigata-u.ac.jp> <20130104094532.4a921e47@ernst.jennejohn.org> <50ED30B9.7040101@zedat.fu-berlin.de> <20130109085907.GJ66284@glebius.int.ru> In-Reply-To: <20130109085907.GJ66284@glebius.int.ru> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27CE62C2833F3C0E9520B7A6" X-Originating-IP: 85.178.6.81 Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 15:48:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27CE62C2833F3C0E9520B7A6 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Am 01/09/13 09:59, schrieb Gleb Smirnoff: > On Wed, Jan 09, 2013 at 09:56:25AM +0100, Hartmann, O. wrote: > H> Same here. > H> The OS: FreeBSD 10.0-CURRENT/amd64 r245218. Since I have three boxes= > H> running approximately the same configurations (I share my configs > H> between lab and home), but different hardware, I'm confused. > H>=20 > H> The symptoms in my case are: > H>=20 > H> Booting the box is all right until it comes to the start of nfsuserd= =2E > H> Prior to that, ntp adjusts the clock properly with an external time > H> server - so this implies network connectivity. Start of nfsuserd is= > H> stuck forever. > H> Interrupting the start of nfsuserd restarts several other services, = but > H> winbindd and slapd (OpenLDAP) get stuck again. In case I also interr= upt > H> them, there are other services which will not start. > H>=20 > H> Trying to login as root on the console fails - I never get a passwor= d > H> tag after having issued the root login name. Since this machine is b= ound > H> to a local and remote OpenLDAP backend, I'm used to have an emergenc= y > H> local user which usually works - but this time, neither root nor thi= s > H> user can login! > H>=20 > H> Bringing up the box in SINGLEUSER allows me to login. Investigating = the > H> network interfaces with ifconfig reveals, that the loopback did not = get > H> assigned to any inet 127.0.0.1 address. Sometimes there is only inet= 6 > H> linklocal address, some nd6 options, but sometimes even IPv6 assignm= ents > H> do not show up. > H>=20 > H> In a desperate move I tried to recompile a kernel. In /etc/src.conf,= I > H> recompile also the kernel module for the most recent virtual-box ker= nel > H> module. While the kernel and module (*.ko) get installed properly, t= he > H> recompilation of the VirtualBox port gets stuck when the system unfo= lds > H> the source tarball. Hitting Ctrl-T say "sbwait" for the process. Oth= er > H> processes seem to have trouble getting a proper ownership or UID for= a > H> file - this is my naiv interpretation what I see at the surface. > H>=20 > H> The funny thing is, that after several reboots, the box gets up as n= ormal. > H>=20 > H> I revealed this issue approx. two weeks ago when out of the sudden t= he > H> amd automounter stopped working and the NFSv4 network drives didn't > H> attach properly and made the whole box being stuck. > H>=20 > H> Sorry for the more superficial description of the problem ... > H>=20 > H> Has the problem been identified? Is there a solution? Since it affec= ts > H> only my very modern hardware (i7-3930, 32GB RAM, ASUS P9X79 WS > H> mainboard), while a very same setup on older hardware (our local ser= ver > H> is Intel Q6600 with 8GB RAM and and oldish Intel P45-chipset based > H> mainboard), both systems do have Intel NICs, I'm a bit confused. >=20 > This looks unrelated to the problem discussed, because r245218 is > later than r244989 which backed out my change. >=20 > Can you do a binary search to identify which revision broke things? >=20 Sorry for the delay. Today I realized that the problems occured and described are due to the fact that I use jumbo frames (mtu 9100 or mtu 6150) on the em0-device (em0@pci0:0:25:0: class=3D0x020000 card=3D0x844e1043 chip=3D0x1503= 8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82579V Gigabit Network Connection' class =3D network subclass =3D ethernet ). Using the default of mtu 1500 does not make the problem occur. My time constraints disallow to do further or deeper investigations - at least until the end of next week, I'm sorry. The problems arose around Christmas, it might be even earlier, since I didn't access the machine since 10th December. I have other boxes with Intel NICs - different chiptypes. They do not show this problem. Oliver --------------enig27CE62C2833F3C0E9520B7A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ7uLKAAoJEOgBcD7A/5N8+B0H/AyeT0dNahSyuCbp5OiEWTyH LfKccvosiplls/sIeqeV5Wp6GlF/2PqDHO7mhXM/c/i07dXZpGdUttYxZbfEmYV9 /8DcVhNEYpYCyzyo1a0xIrMv4niyl+sZhdyla0hGbr0jaPOlu9KLTsDQH0E0EvmB UfAlhuAeZA8VcCoc4H/q31DVU83OIy2sey9KvCThEObvN7M8deNSf3qlkvuVMNUZ kF9fNy4cKujPh7GeAebyvAid9n27vQH6L9y1PSC+aPmp0TUXU3vULY66uLIv5SUW KWzYyF7JzdDGy09TJjvtrgV6hhHvdkuYeGm4QvZvFTc7HEPAUDfwtI0NkthKBGc= =xAVw -----END PGP SIGNATURE----- --------------enig27CE62C2833F3C0E9520B7A6-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 10 21:12:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 582866F4; Thu, 10 Jan 2013 21:12:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 34FC5947; Thu, 10 Jan 2013 21:12:40 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3C138B944; Thu, 10 Jan 2013 16:12:39 -0500 (EST) From: John Baldwin To: Palle Girgensohn Subject: Re: gptzfsboot error using HP Smart Array P410i Controller Date: Thu, 10 Jan 2013 12:15:48 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <4F4FECA4.10504@FreeBSD.org> <50EDF5C2.8020609@FreeBSD.org> In-Reply-To: <50EDF5C2.8020609@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301101215.48510.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 10 Jan 2013 16:12:39 -0500 (EST) Cc: Christoph Hoffmann , freebsd-current@freebsd.org, Andriy Gapon , Bjorn Larsson , Julian Akehurst , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:12:40 -0000 On Wednesday, January 09, 2013 05:57:06 PM Palle Girgensohn wrote: > Palle Girgensohn skrev: > > Hi! > > > > This is still happening with FreeBSD 9.0-RELEASE, as I have just > > discovered. The hack works like a charm, but seems kind of odd... :) > > > > Any progress in getting a "real" fix into the repository? Any risks > > with the hack - is it likely to believe that it will suddenly or > > sporadically fail? > > > > Cheers, Palle > > > > Christoph Hoffmann skrev: > >> Hello Daniel, > >> > >> Last time I checked up on the issue was on the 23rd of September, > >> it was not fixed then. I was able to to boot from drive 0x80 after > >> adding: > >> > >> *** zfsboot.c.orig Fri Sep 23 18:03:26 2011 --- zfsboot.c Fri Sep > >> 23 18:47:44 2011 *************** *** 459,464 **** --- 459,465 ---- > >> heap_end = (char *) PTOV(bios_basemem); } > >> > >> + printf("Hello! I am a hack.\n"); dsk = malloc(sizeof(struct > >> dsk)); dsk->drive = *(uint8_t *)PTOV(ARGS); dsk->type = dsk->drive > >> & DRV_HARD ? TYPE_AD : TYPE_FD; > >> > >> I am inclined to think that this is related to the way how we > >> compile this code, especially when run on the following particular > >> processor: > >> > >> 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is > >> enabled Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz QPI Speed: 5.8 > >> GT/s. > >> > >> > >> Regards, > >> > >> Christoph > >> > >> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote: > >>> Has this issue been resolved somehow? Sane method to build > >>> gptzfsboot that will run on HP's P410i? > > Hi, > > This is still happening with 9.2-RELEASE on a HP DL 380 G5: Presumably 9.1? > gptzfsboot: error 1 lba 32 > gptzfsboot: error 1 lba 1 > gptzfsboot: No ZFS pools located, can't boot > > Andriy suggested the latest sys/boot/i386/common/edd.h@243024 from head, > but unfortunately it makes no difference. > > The printf hack above still works fine though. Do you have avg's most recent commit to edd.h to pack various structures? I'm not sure that made it into 9.1. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 10 21:55:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 34F953AB; Thu, 10 Jan 2013 21:55:09 +0000 (UTC) (envelope-from girgen@pingpong.net) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id DB39FB3A; Thu, 10 Jan 2013 21:55:08 +0000 (UTC) Received: from [10.0.1.7] (c-2754e155.1525-1-64736c12.cust.bredbandsbolaget.se [85.225.84.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by melon.pingpong.net (Postfix) with ESMTPSA id C8A2812ECF; Thu, 10 Jan 2013 22:55:00 +0100 (CET) References: <4F4FECA4.10504@FreeBSD.org> <50EDF5C2.8020609@FreeBSD.org> <201301101215.48510.jhb@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <201301101215.48510.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3037D71C-49A7-488C-AC8B-FBC2A1DA8F0C@pingpong.net> X-Mailer: iPhone Mail (10A523) From: Palle Girgensohn Subject: Re: gptzfsboot error using HP Smart Array P410i Controller Date: Thu, 10 Jan 2013 22:54:58 +0100 To: John Baldwin Cc: Christoph Hoffmann , Andriy Gapon , Bjorn Larsson , "freebsd-current@freebsd.org" , Daniel Kalchev , Palle Girgensohn , Julian Akehurst X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:55:09 -0000 10 jan 2013 kl. 18:15 skrev John Baldwin : > On Wednesday, January 09, 2013 05:57:06 PM Palle Girgensohn wrote: >> Palle Girgensohn skrev: >>> Hi! >>>=20 >>> This is still happening with FreeBSD 9.0-RELEASE, as I have just >>> discovered. The hack works like a charm, but seems kind of odd... :) >>>=20 >>> Any progress in getting a "real" fix into the repository? Any risks >>> with the hack - is it likely to believe that it will suddenly or >>> sporadically fail? >>>=20 >>> Cheers, Palle >>>=20 >>> Christoph Hoffmann skrev: >>>> Hello Daniel, >>>>=20 >>>> Last time I checked up on the issue was on the 23rd of September, >>>> it was not fixed then. I was able to to boot from drive 0x80 after >>>> adding: >>>>=20 >>>> *** zfsboot.c.orig Fri Sep 23 18:03:26 2011 --- zfsboot.c Fri Sep= >>>> 23 18:47:44 2011 *************** *** 459,464 **** --- 459,465 ---- >>>> heap_end =3D (char *) PTOV(bios_basemem); } >>>>=20 >>>> + printf("Hello! I am a hack.\n"); dsk =3D malloc(sizeof(struct >>>> dsk)); dsk->drive =3D *(uint8_t *)PTOV(ARGS); dsk->type =3D dsk->drive >>>> & DRV_HARD ? TYPE_AD : TYPE_FD; >>>>=20 >>>> I am inclined to think that this is related to the way how we >>>> compile this code, especially when run on the following particular >>>> processor: >>>>=20 >>>> 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is >>>> enabled Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz QPI Speed: 5.8 >>>> GT/s. >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Christoph >>>>=20 >>>> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote: >>>>> Has this issue been resolved somehow? Sane method to build >>>>> gptzfsboot that will run on HP's P410i? >>=20 >> Hi, >>=20 >> This is still happening with 9.2-RELEASE on a HP DL 380 G5: >=20 > Presumably 9.1? >=20 >> gptzfsboot: error 1 lba 32 >> gptzfsboot: error 1 lba 1 >> gptzfsboot: No ZFS pools located, can't boot >>=20 >> Andriy suggested the latest sys/boot/i386/common/edd.h@243024 from head, >> but unfortunately it makes no difference. >>=20 >> The printf hack above still works fine though. >=20 > Do you have avg's most recent commit to edd.h to pack various structures? = I'm=20 > not sure that made it into 9.1. >=20 9.1, of course, sorry! :-) Yes, I've built a fresh gptzfsboot using 9.1 + edd.h from head (with _packe= d keywords added).=20= From owner-freebsd-current@FreeBSD.ORG Thu Jan 10 22:25:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D80E8866 for ; Thu, 10 Jan 2013 22:25:49 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id BE3EBD38 for ; Thu, 10 Jan 2013 22:25:49 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 6727A22D53; Thu, 10 Jan 2013 14:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1357856749; bh=XFGbKEHyI09ssK2zQXQOvXX09OaLPAtZab+TZ4mxN9A=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=B1hbr4humEWPLMNO6CgEc3NqORsa4zhaLNBve919a3yRKWeqUVf9yer8Llu/9eHXS rBwuVBtrKLfrUiJKIPcKMrXyPXTZOMDN1YL31jP7yBJ797DFS4dd/2qhvUGZXoFe+E XvpCYrsDMlH0qNqLE5q/oHY20C/SsfAlxkr8eyhg= Message-ID: <50EF3FEC.60605@delphij.net> Date: Thu, 10 Jan 2013 14:25:48 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: d@delphij.net Subject: Re: sysctl -a causes kernel trap 12 References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> <50EB870D.3020306@delphij.net> In-Reply-To: <50EB870D.3020306@delphij.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brandon Gooch , Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 22:25:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 To all: this became more and more hard to replicate lately. I've tried these options and the most important progress is that it's possible to get a crashdump when debug.debugger_on_panic=0 and I managed to get a backtrace which indicates the panic occur when trying to do mtx_lock(&Giant) -> __mtx_lock_sleep -> turnstile_wait -> propagate_priority, but after I've added some instruments to the surrounding code and enabled INVARIANT and/or WITNESS, it mysteriously went away. Reverting my instruments code and update to latest svn makes the issue disappear for one day. I've hit it again today but unfortunately didn't get a successful dump and after reboot I can't reproduce it again :( Still trying... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQ7z/sAAoJEG80Jeu8UPuzJbMIAL2xM6xWATXp2swY1E25WaCj UoDAJtVkGvI5pOQmt7UBvDJfqr74/1c1ugGodFVAtRluKihxQ6amXcmF62eqPu0g ARj7R+g/5qQ+QDDOVFcqnvuz1A1KwoDD5jkfAyq+oWECQ5a4ROk/59EhlriK9CQd I4NRzuJLgOf3t4xNk7nAEYSnx+zL07vpGmSNIHdWkLieGNIoa1X5W9HtfpOGgRpm c5ELbWTpxGTtAFmFxc7h2hygu38/hlj6KPJHRK6HGcR1t/EMc2Rauzn7Bl3R3C/W TjDrxknPjZUUA70oI2V2Vo8tGZaJCzpq8dDWb8fx5rbKxLM+svmShHYftow78rM= =ooDY -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jan 10 23:39:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A3ECB19F; Thu, 10 Jan 2013 23:39:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 66E5A90; Thu, 10 Jan 2013 23:39:48 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:3cf0:ddba:2f37:eb56] (unknown [IPv6:2001:7b8:3a7:0:3cf0:ddba:2f37:eb56]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 294A05C37; Fri, 11 Jan 2013 00:39:46 +0100 (CET) Message-ID: <50EF5140.60407@FreeBSD.org> Date: Fri, 11 Jan 2013 00:39:44 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: clang 3.2 RC2 miscompiles libgcc? References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <20130106160331.GB1418@mole.fafoe.narf.at> <50EB5868.2050509@FreeBSD.org> <20130108085826.GA1422@mole.fafoe.narf.at> In-Reply-To: <20130108085826.GA1422@mole.fafoe.narf.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, David Chisnall , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 23:39:48 -0000 On 2013-01-08 09:58, Stefan Farfeleder wrote: > On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... >> After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume >> which when compiled by clang caused the crashes, but when compiled by >> gcc ran OK. > your patch seems to work just fine. No crashes whatsoever so far. Thank > you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 01:22:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 523E6429; Fri, 11 Jan 2013 01:22:04 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 156FF6E2; Fri, 11 Jan 2013 01:22:03 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r0B1LvjW079346; Thu, 10 Jan 2013 20:22:02 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50EF6935.3070000@m5p.com> Date: Thu, 10 Jan 2013 20:21:57 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org Subject: Circular port dependency Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Thu, 10 Jan 2013 20:22:02 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 01:22:04 -0000 I grabbed the ports tree as of 308518, the RELEASE_9_1_0 tag. devel/libtool won't build, because it requires autom4te during the configure phase. So I put "BUILD_DEPENDS= autom4te:devel/autoconf" in the Makefile. But autoconf depends on gmake, which depends on gettext, which depends on libiconv, which depends on libtool. What to do? I'm running on a CURRENT build on my Raspberry Pi. -- George Mitchell From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 02:13:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 50235A98 for ; Fri, 11 Jan 2013 02:13:42 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 40630832 for ; Fri, 11 Jan 2013 02:13:42 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 701AC225F2; Thu, 10 Jan 2013 18:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1357870421; bh=FCqVFZDMvJpxulXS4/iv5xnB8cftan2LvbClTrqKR0o=; h=Date:From:Reply-To:To:Subject; b=RKjqmTRbkvbMSK2uww/6ar/gXP3DFZ5p4+1TI4vwVe6B95pro+yViUHmO4x6s6oCH WR/BpV/HT6jAf1SYzDsA7eYH/Oue+a7ai2Jt7ddkN3CCojeHIWMBIOBmzQOA6e7MJh B27DfKIWk55TvKAUG09wl83GkA326zrEDKx4AuOM= Message-ID: <50EF7554.70607@delphij.net> Date: Thu, 10 Jan 2013 18:13:40 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: current@freebsd.org Subject: setlocale() for base system utilities X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 02:13:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I just noticed that many base system utilities, like rm, cat, etc. does not do setlocale() at beginning. Is this intentional or just nobody have yet to done it? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQ73VUAAoJEG80Jeu8UPuzWR4H/Ap79HVGQso6/HPmiud2JC5q dzeY20K1P2rlQAjDhday1HWJg3bW4ZCzvIX09AVi+lQB8fRAcRzLIFjXt611ovqC tBOhTgtwJvFEYGBs5batWCrEOtbTnbM2YZlOyJegSdjqhIoXiWrj5BCpbr5OaGw7 GK9yJhiYX60vHQwL0kRP4Xwn9Yc1+UPyyzPXj0HpgTutJhFFwcXCymK2ZpWmyxT4 6SdwEcIEsBH2iluunS9yDGKCexk8v8BT/uPUOGOQ6vK9y4L/3egJ3RKrQj4Q3Mu+ Yksn+jIT5eXdijmmbnYZKR0QW/7+eyJbZ4w4ZNasYhEYGskCfj2ce32sbYa7ilw= =p9Ch -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 02:55:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 23AA04D0 for ; Fri, 11 Jan 2013 02:55:45 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by mx1.freebsd.org (Postfix) with ESMTP id ACF3A9A1 for ; Fri, 11 Jan 2013 02:55:44 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id gi11so988473lbb.33 for ; Thu, 10 Jan 2013 18:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M/yaCRw2Uap6pQSrBqJNDd52/7Z+eYzPeoIEr+OAT/o=; b=wJ+1OdIo0GsbYaduiwPoX0a36GVQX/zyn/Stc9m4m3EA68EXuQ/Xgt4t1vM3L+QBsY XkZ/fveH90WdXJN8gUkc3t8EjnHoqw9y1FGjb8WZc3b/YW8jRCIiQ43+bYBaIAh98WsW 9IaUPAPpatStK50AuZBsW+e1pFY0eMTrwznV7NdhVjN1BcFdXonT03YcynuY6VyXvCKv AAAaMRNfpyQQHAN97V2DcTJGNEH8mBdND7JLB1+dFm4fwiBzf+JDReu8SBiKLuBR0M7N xeukHIEtetKQHSJXDqaKvyrXZYt6BVO3m6zDP4Wlt8acjyCtGY6j1bRBtS44HCBk8X/x pYNQ== MIME-Version: 1.0 Received: by 10.112.46.70 with SMTP id t6mr30851197lbm.107.1357872943412; Thu, 10 Jan 2013 18:55:43 -0800 (PST) Received: by 10.112.75.131 with HTTP; Thu, 10 Jan 2013 18:55:43 -0800 (PST) In-Reply-To: <50EF7554.70607@delphij.net> References: <50EF7554.70607@delphij.net> Date: Thu, 10 Jan 2013 20:55:43 -0600 Message-ID: Subject: Re: setlocale() for base system utilities From: Zhihao Yuan To: Xin LI Content-Type: text/plain; charset=UTF-8 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 02:55:45 -0000 On Thu, Jan 10, 2013 at 8:13 PM, Xin Li wrote: > I just noticed that many base system utilities, like rm, cat, etc. > does not do setlocale() at beginning. Is this intentional or just > nobody have yet to done it? Enabling locale in the non-wide-char-awared utilities only makes difference for 8-bit locales, like ISO8859-*, but not multibyte ones. From a user's point of view, this is an inconsistency. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 03:24:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B82519E5 for ; Fri, 11 Jan 2013 03:24:13 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECAFB52 for ; Fri, 11 Jan 2013 03:24:13 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j15so1173573qaq.20 for ; Thu, 10 Jan 2013 19:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=To8f/8xB2+plKOOZG6EYNSKWyi4eOCV4iUaFunoAqGc=; b=ZOTSCK224VdLAikdbarTRb//yeZIFqNqr+R/FEyApflvzJ3tVB4QTw+a8elt77sMCv AmlY7eqUvnPxBpPo0igo4ST2pPPwYQ7QnKDroPCXq9jg6VOhGGemqvOmt5RCF7vz/Npl JTkGYmps/nGTLtigQXF9aNOvaUJ/UxBbXQ5PHDsRvcD2BK4FGiD3OFn3aUqs3ByQ441U 7kzDsSTZFdPo2BUNPxnQPfuC8Jqo+KVTu/jrH580+PX8EtjMZFH6T2pSu8AorGVngkM3 yxeVeB7TU2e6zZzzFFBDn2822cKWqLze8Lbs1igPucMSB9CHdgRG4j881c90miRWalYB UEAg== MIME-Version: 1.0 Received: by 10.49.12.138 with SMTP id y10mr68420553qeb.64.1357874647156; Thu, 10 Jan 2013 19:24:07 -0800 (PST) Received: by 10.49.12.162 with HTTP; Thu, 10 Jan 2013 19:24:07 -0800 (PST) In-Reply-To: References: <50EF7554.70607@delphij.net> Date: Thu, 10 Jan 2013 19:24:07 -0800 Message-ID: Subject: Re: setlocale() for base system utilities From: Xin LI To: Zhihao Yuan Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Xin LI , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 03:24:13 -0000 On Thursday, January 10, 2013, Zhihao Yuan wrote: > On Thu, Jan 10, 2013 at 8:13 PM, Xin Li > > wrote: > > I just noticed that many base system utilities, like rm, cat, etc. > > does not do setlocale() at beginning. Is this intentional or just > > nobody have yet to done it? > > Enabling locale in the non-wide-char-awared utilities only makes > difference for 8-bit locales, like ISO8859-*, but not multibyte > ones. From a user's point of view, this is an inconsistency. > It's inconsistency that some utilities use localized messages while some do, too. So I don't buy that argument. -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 03:39:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5B8D9B86 for ; Fri, 11 Jan 2013 03:39:13 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id DB397C1F for ; Fri, 11 Jan 2013 03:39:12 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id fp12so1355694lab.27 for ; Thu, 10 Jan 2013 19:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BT4zU96hc0lEIzWoDX8o2xEu/8trr5MRUO6kem3jwag=; b=gUSqqeonZj6iDsE51IdPpr311F5mSfj625pv3JcD2GWuw+g1xK33YgUMchzy6jbVjN mZHeVHXwO471/EFTO/cUw1Ux16maIhZ1gVOK2V1kO+y2H+rZy1jO2jDrOq6uwpYS4+CO 593f2JMJMqyN/7QZRC1nppsxQjl3hVjCMv1Tt3vCBFtRx+H2QThhOn2TLKo/r4E7KTff EGcR9qmbFDNxjx8Y02UqQK0qjkjWBplJAWwA32J5ce1dx8gZD+GL6OAYBhivFo4djuXl E9945I98D20lqZYHyu33buhXvJzsOW26PKU0yfRuiN2SST0eW7+McqbTeLe8ZJiX9ON4 ByKw== MIME-Version: 1.0 Received: by 10.112.51.175 with SMTP id l15mr29477743lbo.5.1357875551297; Thu, 10 Jan 2013 19:39:11 -0800 (PST) Received: by 10.112.75.131 with HTTP; Thu, 10 Jan 2013 19:39:11 -0800 (PST) In-Reply-To: References: <50EF7554.70607@delphij.net> Date: Thu, 10 Jan 2013 21:39:11 -0600 Message-ID: Subject: Re: setlocale() for base system utilities From: Zhihao Yuan To: Xin LI Content-Type: text/plain; charset=UTF-8 Cc: Xin LI , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 03:39:13 -0000 On Thu, Jan 10, 2013 at 9:24 PM, Xin LI wrote: > It's inconsistency that some utilities use localized messages while some do, > too. So I don't buy that argument. If one utility support catalogs, then localized messages can be fully supported by providing catalogs for all the locales. But if enabling locale for a narrow-char-only utility, only 8-bit encodings locales are supported, not all. The inconsistency happens within the utility. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 07:10:37 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC8D3E37 for ; Fri, 11 Jan 2013 07:10:37 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 60A4C3E9 for ; Fri, 11 Jan 2013 07:10:37 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1TtYl9-002h7d-MG>; Fri, 11 Jan 2013 08:10:35 +0100 Received: from e178010030.adsl.alicedsl.de ([85.178.10.30] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1TtYl9-000bD3-J0>; Fri, 11 Jan 2013 08:10:35 +0100 Message-ID: <50EFBAEA.3070200@zedat.fu-berlin.de> Date: Fri, 11 Jan 2013 08:10:34 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Current FreeBSD Subject: Expanding ZFS RAIDZ on the fly? X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0D88BF2AEDFDF0ED017214CC" X-Originating-IP: 85.178.10.30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:10:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0D88BF2AEDFDF0ED017214CC Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable My question may sound naiv, sorry. I have already set up a RAIDZ (on FreeBSD 10.0-CUR), comprised with three 3 TB disks. I'd like to expand the array with an additional disk - on the fly. oh --------------enig0D88BF2AEDFDF0ED017214CC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ77rrAAoJEOgBcD7A/5N8NkoH/jnVOwc9xhl5OfFTBTblDegU wtBa2VsdamS8Kcm+IOS/p5bMoW5xbNiPOb8aup+V7DUH9vbdv6qaKtInMlXV4q2c 9Vupr6yddpbDJKog4d9Fn1fu+Et/LLX0PXKLa3klsclM2ogKX//CJBChWIgC755A csMhRUTfLNSvKMXsA6d6SUI+32WjtxechTqdDDpliTJN8tUSi55BfIO3H1/RtszP 281D2FDdlnVT4zMFa0fWC/s40SmJKq1LWFg9Q3DlO+TjWOIukVrp8LY+aasWlAar mr+L+r4IQ3Se5D9oYiZg71JT6lbM2FK+JXM60dgjWgTZANVhGCyxzCLn/qLHE8Y= =UET7 -----END PGP SIGNATURE----- --------------enig0D88BF2AEDFDF0ED017214CC-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 07:57:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB4124F3; Fri, 11 Jan 2013 07:57:38 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep16.mx.upcmail.net (fep16.mx.upcmail.net [62.179.121.36]) by mx1.freebsd.org (Postfix) with ESMTP id CFEF981B; Fri, 11 Jan 2013 07:57:37 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep16-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130111075730.RWWR29828.viefep16-int.chello.at@edge04.upcmail.net>; Fri, 11 Jan 2013 08:57:30 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id mXxW1k00N2xdvHc04XxWAV; Fri, 11 Jan 2013 08:57:30 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id F2AC16D47C; Fri, 11 Jan 2013 08:57:29 +0100 (CET) Date: Fri, 11 Jan 2013 08:57:29 +0100 From: Stefan Farfeleder To: Dimitry Andric Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130111075729.GA1450@mole.fafoe.narf.at> References: <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <20130106160331.GB1418@mole.fafoe.narf.at> <50EB5868.2050509@FreeBSD.org> <20130108085826.GA1422@mole.fafoe.narf.at> <50EF5140.60407@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50EF5140.60407@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, David Chisnall , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:57:39 -0000 On Fri, Jan 11, 2013 at 12:39:44AM +0100, Dimitry Andric wrote: > On 2013-01-08 09:58, Stefan Farfeleder wrote: > > On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: > ... > >> After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume > >> which when compiled by clang caused the crashes, but when compiled by > >> gcc ran OK. > > your patch seems to work just fine. No crashes whatsoever so far. Thank > > you. > > I have committed a slighly cleaned-up version of this hack in r245272, > so until this is fixed by upstream, everybody will at least have a > correctly functioning libgcc on amd64. > > Since this issue can potentially also occur on stable/9, I will MFC the > fix too, after a few days timeout. Thanks! From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 08:19:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 70C72A75; Fri, 11 Jan 2013 08:19:14 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 16F0E905; Fri, 11 Jan 2013 08:19:13 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TtZpY-002sbB-Aj>; Fri, 11 Jan 2013 09:19:12 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TtZpY-000fDs-8F>; Fri, 11 Jan 2013 09:19:12 +0100 Message-ID: <50EFCAFD.6040001@zedat.fu-berlin.de> Date: Fri, 11 Jan 2013 09:19:09 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang 3.2 RC2 miscompiles libgcc? References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <20130106160331.GB1418@mole.fafoe.narf.at> <50EB5868.2050509@FreeBSD.org> <20130108085826.GA1422@mole.fafoe.narf.at> <50EF5140.60407@FreeBSD.org> In-Reply-To: <50EF5140.60407@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A840280DC7FC6DB8ED96573" X-Originating-IP: 130.133.86.198 Cc: Stefan Farfeleder , David Chisnall , Nathan Whitehorn , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:19:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A840280DC7FC6DB8ED96573 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/11/13 00:39, Dimitry Andric wrote: > On 2013-01-08 09:58, Stefan Farfeleder wrote: >> On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: > ... >>> After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Res= ume >>> which when compiled by clang caused the crashes, but when compiled by= >>> gcc ran OK. >> your patch seems to work just fine. No crashes whatsoever so far. Than= k >> you. >=20 > I have committed a slighly cleaned-up version of this hack in r245272, > so until this is fixed by upstream, everybody will at least have a > correctly functioning libgcc on amd64. >=20 > Since this issue can potentially also occur on stable/9, I will MFC the= > fix too, after a few days timeout. > _______________________________________________ Very appreciated and thanks. oh --------------enig4A840280DC7FC6DB8ED96573 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ78sAAAoJEOgBcD7A/5N8X+kH/2G+edpL7pVB7DLF9y963gAY hSTKlTFTPr5G+NUuAw3zxiyxgZm6XE+eSoNfUF+XyJQcCEf/M9krMQGS+hmLOKln FGDEeVYdW4R84CpmE58RdX6RE91SgmXdb0T/HXXpsLlo8Rlr3bhYwfXwfCUQRwtW qbcpwo06Pgl/nR3ABF3VuD4SzG6epsCOl0OrofnSVkNIMPVNSY9OmwvZLrcWaVoV rgUD0PAaAGGBu37SdU6//skACNzKBjb1udts+qUk1rCu6HBAgdGHG90zU3/8UOfk fsdcd5HjGIla31fq4Tvp7kIDDHHTVpZfM26LzMrpJyT918OVMLM798VihDQM9k4= =Rk7q -----END PGP SIGNATURE----- --------------enig4A840280DC7FC6DB8ED96573-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 09:55:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21CE0BA4; Fri, 11 Jan 2013 09:55:29 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by mx1.freebsd.org (Postfix) with ESMTP id 76B6B2F; Fri, 11 Jan 2013 09:55:28 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id gk1so1176848lbb.28 for ; Fri, 11 Jan 2013 01:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MvPfX9oVju184e0kGjUBJUwQ0hsYbLxSDzVvBZ9NwLw=; b=Z3KPxwaYSwOf9EieAJk24Vv7Xktx8nZY+rLR37sIuEdYSJoJZAvJlZFm2S9xMiciKS QI/ZMQXbGd6nImMhX2eu0HMarW0e8i0lyv3iniKiINdfblpLyUal9D1HnqDHTBMMl5hX 1/TNSpar+Zw2TGL1S8zF2TTN7U4yNQEJANtzjILSg1kcboYw7WDxzFRWTYQJARiK6diW h7ZzWxuFKtZfTexT9EJsWyGK9Iflhm5EatXugSPEwc8LZwYubl6SRXjjJi6oD6FHUXnQ okIbtTGkgVN+6BoX+YYhXGQOJpGmYH9kRPuRaemsXefU02AXkAZiGLsXPjUGXZCXqkw3 jfkw== X-Received: by 10.112.26.169 with SMTP id m9mr23780597lbg.116.1357898127201; Fri, 11 Jan 2013 01:55:27 -0800 (PST) Received: from [192.168.1.130] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id v7sm1880040lbj.13.2013.01.11.01.55.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jan 2013 01:55:26 -0800 (PST) Message-ID: <50EFE18C.3050408@gmail.com> Date: Fri, 11 Jan 2013 11:55:24 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: George Mitchell Subject: Re: Circular port dependency References: <50EF6935.3070000@m5p.com> In-Reply-To: <50EF6935.3070000@m5p.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-ports@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 09:55:29 -0000 11.01.2013 03:21, George Mitchell: > I grabbed the ports tree as of 308518, the RELEASE_9_1_0 tag. The current and supported version of ports is HEAD. > devel/libtool won't build, because it requires autom4te during the Can you provide some logs showing how it can't be built? > configure phase. So I put "BUILD_DEPENDS= autom4te:devel/autoconf" > in the Makefile. But autoconf depends on gmake, which depends on > gettext, which depends on libiconv, which depends on libtool. > What to do? -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 10:39:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC107C66 for ; Fri, 11 Jan 2013 10:39:16 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx1.freebsd.org (Postfix) with ESMTP id 62DBB266 for ; Fri, 11 Jan 2013 10:39:16 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id l6so1273091vcl.23 for ; Fri, 11 Jan 2013 02:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SyCcGXqoP4Y8m+krcHz7jbTaHAradWovBvS6Z15xFYk=; b=ZoeXeR8jgipoWT3NNnshw153qFpG1fh3gZeFcBzYUZrVCv0f6b/Nk+fDYKA+otWrbt yY0iSkpV5QIaGPIrWHqKSf9FfXYGV1f5V7XTcwOAVLhXx2fv4IQ3nm0fC2XnTXOd0ZyW fw62Qs125uKEuPNXDXZ2JVe13igZ52ov6WCr9eodZPNYlKU5lwH8XoC8wLF+kJl7TFvo n+Zm1Q0xpXiIGOoKazgdxh/tdTGxrGldWVXF5YjaWrd8JazPxadLZSTgNgyxJlVQyQ/z fFCUtogcRLJ7Za250Z5RUb61y2/sU8ed5ZpJ3EAyjedOR4mgzOghWN1u+d2LeKu1yZmc GK9A== MIME-Version: 1.0 Received: by 10.58.4.231 with SMTP id n7mr14783943ven.26.1357900750401; Fri, 11 Jan 2013 02:39:10 -0800 (PST) Received: by 10.59.13.73 with HTTP; Fri, 11 Jan 2013 02:39:10 -0800 (PST) In-Reply-To: <50EFBAEA.3070200@zedat.fu-berlin.de> References: <50EFBAEA.3070200@zedat.fu-berlin.de> Date: Fri, 11 Jan 2013 10:39:10 +0000 Message-ID: Subject: Re: Expanding ZFS RAIDZ on the fly? From: Tom Evans To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:39:16 -0000 On Fri, Jan 11, 2013 at 7:10 AM, O. Hartmann wrote: > My question may sound naiv, sorry. > > I have already set up a RAIDZ (on FreeBSD 10.0-CUR), comprised with > three 3 TB disks. I'd like to expand the array with an additional disk - > on the fly. > > oh > It's not possible to expand by just 1 disk. Expanding with another 3 disks is possible though, or "backup, destroy, create, restore". Expanding or reducing the number of disks in a raidz is the mythical block pointer rewrite functionality, google will tell more. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 14:06:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0D8489F7 for ; Fri, 11 Jan 2013 14:06:06 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id ABEE9CF6 for ; Fri, 11 Jan 2013 14:06:05 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id r0BE5vxe085104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jan 2013 15:06:02 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id r0BE5v6F085103 for freebsd-current@freebsd.org; Fri, 11 Jan 2013 15:05:57 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Fri, 11 Jan 2013 15:05:57 +0100 From: Paul Schenkeveld To: freebsd-current@freebsd.org Subject: Re: Expanding ZFS RAIDZ on the fly? Message-ID: <20130111140557.GA63102@psconsult.nl> References: <50EFBAEA.3070200@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 14:06:06 -0000 On Fri, Jan 11, 2013 at 10:39:10AM +0000, Tom Evans wrote: > On Fri, Jan 11, 2013 at 7:10 AM, O. Hartmann > wrote: > > My question may sound naiv, sorry. > > > > I have already set up a RAIDZ (on FreeBSD 10.0-CUR), comprised with > > three 3 TB disks. I'd like to expand the array with an additional disk - > > on the fly. > > > > oh > > > > It's not possible to expand by just 1 disk. Expanding with another 3 > disks is possible though, or "backup, destroy, create, restore". > > Expanding or reducing the number of disks in a raidz is the mythical > block pointer rewrite functionality, google will tell more. Another growth path is replacing each of the existing disks by larger ones and resilvering the data with 'zpool replace ...'. Having a spare drive bay is really a help so if you wanted to add just a 4th drive because you've only one bay left you should consider leaving that one unoccupied so you can easily grow to bigger disks now or in the future. HTH Paul Schenkeveld From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 14:19:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 24366E98 for ; Fri, 11 Jan 2013 14:19:05 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 8EAFEDA2 for ; Fri, 11 Jan 2013 14:19:04 +0000 (UTC) Received: (qmail 11106 invoked from network); 11 Jan 2013 14:19:17 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 11 Jan 2013 14:19:17 -0000 Received: (qmail 11097 invoked by uid 599); 11 Jan 2013 14:19:16 -0000 Received: from unknown (HELO PDC002.icritical.int) (212.57.254.146) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Fri, 11 Jan 2013 14:19:16 +0000 Message-ID: <50F01F52.10006@icritical.com> Date: Fri, 11 Jan 2013 14:18:58 +0000 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120906 Thunderbird/15.0 MIME-Version: 1.0 To: Subject: Re: installworld failure due to cross-device links References: <50E42264.4010609@freebsd.org> <50E4357B.7020400@freebsd.org> In-Reply-To: <50E4357B.7020400@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-TLS-Incoming: YES X-Virus-Scanned: by iCritical at mail1.icritical.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 14:19:05 -0000 On 01/02/13 13:26, Nathan Whitehorn wrote: > Thanks for the patch! I've committed it (slightly modified) as r244958. > I haven't taken any action on the chgrp/chown issue, though. Similarly, 'make distribution' fails when /root is a separate filesystem: cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.profile /tmproot/root/.profile; rm -f /tmproot/.profile; ln /tmproot/root/.profile /tmproot/.profile ln: /tmproot/.profile: Cross-device link *** [distribution] Error code 1 Is there any real advantage of hard links over symlinks nowadays? -- Sorry for the following... The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 15:53:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E0829B7 for ; Fri, 11 Jan 2013 15:53:44 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 31049240 for ; Fri, 11 Jan 2013 15:53:42 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r0BFrgDC088183 for ; Fri, 11 Jan 2013 09:53:42 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r0BFrgn7088182 for current@freebsd.org; Fri, 11 Jan 2013 09:53:42 -0600 (CST) (envelope-from brooks) Date: Fri, 11 Jan 2013 09:53:42 -0600 From: Brooks Davis To: current@freebsd.org Subject: fixed breaking in libc ABI Message-ID: <20130111155342.GA80509@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:53:44 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On December 18th I made a commit that accidentally broke the libc ABI, the commit below fixes it. If you updated current in the interim and rebuilt ports due to complaints about strunvis or strunvisx you will need to do so again after your next update. Sorry for the breakage. -- Brooks ----- Forwarded message from Brooks Davis ----- =46rom: Brooks Davis Date: Fri, 11 Jan 2013 15:50:01 +0000 (UTC) To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: svn commit: r245305 - head/lib/libc/gen Author: brooks Date: Fri Jan 11 15:50:01 2013 New Revision: 245305 URL: http://svnweb.freebsd.org/changeset/base/245305 Log: In r244401 I accidently moved strunvis and strunvisx from version 1.0 to 1.3 breaking the libc ABI. Revert that change (breaking the ABI again for users who updated after December 18th). Modified: head/lib/libc/gen/Symbol.map Modified: head/lib/libc/gen/Symbol.map =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/lib/libc/gen/Symbol.map Fri Jan 11 15:05:55 2013 (r245304) +++ head/lib/libc/gen/Symbol.map Fri Jan 11 15:50:01 2013 (r245305) @@ -298,6 +298,8 @@ FBSD_1.0 { ualarm; ulimit; uname; + strunvis; + strunvisx; usleep; utime; valloc; @@ -391,8 +393,6 @@ FBSD_1.3 { snvis; strnunvis; strnunvisx; - strunvis; - strunvisx; strnvis; strnvisx; strsnvis; ----- End forwarded message ----- --17pEHd4RhPHOinZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQ8DWGXY6L6fI4GtQRAg+HAKCsMTynt/PuFAw0NO9U0Dbegm7k+ACeJ93n rYvXM68pbZULfG/HIqosZbU= =ZIuK -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 16:05:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 31637D49 for ; Fri, 11 Jan 2013 16:05:19 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 02B8F2C8 for ; Fri, 11 Jan 2013 16:05:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=YLFNdnpP9HmB/Rsie5+p+K66UuBnPjqXsO8IsG7C59c=; b=ABr9R6MiamolHUDiVVP4jXJMMYuX2FstORdOm9BN3FINzvx1MSNLS6k9JM/PEpBRJQFsIerg+hFK4uh2QN65GkyMZWgwz90ARKgfZOGunjoyY9XMDGdIHrd7a+cNOKWD6eM77hfeC0i6lA/G9Sme5rkGCW7FcSW7tj2U2mPusQM=; Received: from localhost.lerctr.org ([127.0.0.1]:10420 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tth6b-0001A8-NM for freebsd-current@freebsd.org; Fri, 11 Jan 2013 10:05:18 -0600 Received: from [32.97.110.60] by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 11 Jan 2013 10:05:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 11 Jan 2013 10:05:17 -0600 From: Larry Rosenman To: Subject: Re: clang 3.2 RC2 miscompiles =?UTF-8?Q?libgcc=3F?= In-Reply-To: <50EFCAFD.6040001@zedat.fu-berlin.de> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9916F.3040500@FreeBSD.org> <20130106160331.GB1418@mole.fafoe.narf.at> <50EB5868.2050509@FreeBSD.org> <20130108085826.GA1422@mole.fafoe.narf.at> <50EF5140.60407@FreeBSD.org> <50EFCAFD.6040001@zedat.fu-berlin.de> Message-ID: <30f3d421021e82dbc8d9fa8635771fff@webmail.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.4 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:05:19 -0000 On 2013-01-11 02:19, O. Hartmann wrote: > On 01/11/13 00:39, Dimitry Andric wrote: >> On 2013-01-08 09:58, Stefan Farfeleder wrote: >>> On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: >> ... >>>> After a lot of splitting up of unwind-dw2.c, I arrived at >>>> _Unwind_Resume >>>> which when compiled by clang caused the crashes, but when compiled >>>> by >>>> gcc ran OK. >>> your patch seems to work just fine. No crashes whatsoever so far. >>> Thank >>> you. >> >> I have committed a slighly cleaned-up version of this hack in >> r245272, >> so until this is fixed by upstream, everybody will at least have a >> correctly functioning libgcc on amd64. >> >> Since this issue can potentially also occur on stable/9, I will MFC >> the >> fix too, after a few days timeout. >> _______________________________________________ > > > Very appreciated and thanks. > > oh For the record, I rebuilt my world/kernel after this commit, and rebuilt VirtualBox, and it now works correctly. Thanks Dimitry! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 19:13:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D8174B7 for ; Fri, 11 Jan 2013 19:13:55 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 61D45BDE for ; Fri, 11 Jan 2013 19:13:55 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id r0BJDnr6055573 for ; Fri, 11 Jan 2013 11:13:49 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id r0BJDnDd055572 for freebsd-current@freebsd.org; Fri, 11 Jan 2013 11:13:49 -0800 (PST) (envelope-from sgk) Date: Fri, 11 Jan 2013 11:13:49 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Parallel buildworld broken by clang Message-ID: <20130111191349.GA55533@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 19:13:55 -0000 It seems that a parallel buildworld is broken by clang. % cd /usr/src % svn update % svn info=20 Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 245280 % make -j 5 buildworld =2E.. =3D=3D=3D> lib/clang/include (installincludes) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/lib/clang= /include/../../../contrib/llvm/tools/clang/lib/Headers/__wmmintrin_aes.h /u= sr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/__wm= mintrin_pclmul.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/cla= ng/lib/Headers/altivec.h /usr/src/lib/clang/include/../../../contrib/llvm/t= ools/clang/lib/Headers/ammintrin.h /usr/src/lib/clang/include/../../../cont= rib/llvm/tools/clang/lib/Headers/avx2intrin.h /usr/src/lib/clang/include/..= /../../contrib/llvm/tools/clang/lib/Headers/avxintrin.h /usr/src/lib/clang/= include/../../../contrib/llvm/tools/clang/lib/Headers/bmi2intrin.h /usr/src= /lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/bmiintrin.= h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/= cpuid.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/He= aders/emmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/cl= ang/lib/Headers/f16cintrin.h /usr/src/lib/clang/include/../../../contrib/ll= vm/tools/clang/lib/Headers/fma4intrin.h /usr/src/lib/clang/include/../../..= /contrib/llvm/tools/clang/lib/Headers/fmaintrin.h /usr/src/lib/clang/includ= e/../../../contrib/llvm/tools/clang/lib/Headers/immintrin.h /usr/src/lib/cl= ang/include/../../../contrib/llvm/tools/clang/lib/Headers/lzcntintrin.h /us= r/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/mm3dn= ow.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Heade= rs/mm_malloc.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang= /lib/Headers/mmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/to= ols/clang/lib/Headers/module.map /usr/src/lib/clang/include/../../../contri= b/llvm/tools/clang/lib/Headers/nmmintrin.h /usr/src/lib/clang/include/../..= /../contrib/llvm/tools/clang/lib/Headers/pmmintrin.h /usr/src/lib/clang/inc= lude/../../../contrib/llvm/tools/clang/lib/Headers/popcntintrin.h /usr/src/= lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/rtmintrin.h= /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/s= mmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib= /Headers/tmmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools= /clang/lib/Headers/wmmintrin.h /usr/src/lib/clang/include/../../../contrib/= llvm/tools/clang/lib/Headers/x86intrin.h /usr/src/lib/clang/include/../../.= =2E/contrib/llvm/tools/clang/lib/Headers/xmmintrin.h /usr/src/lib/clang/inc= lude/../../../contrib/llvm/tools/clang/lib/Headers/xopintrin.h /usr/obj/usr= /src/tmp/usr/include/clang/3.2 1 error *** [_includes] Error code 2 1 error *** [buildworld] Error code 2 1 error hpc:root:exit:[212]=20 --=20 Steve From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 19:41:36 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5886ABA1 for ; Fri, 11 Jan 2013 19:41:36 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 041BED51 for ; Fri, 11 Jan 2013 19:41:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1TtkTp-000vIW-5F>; Fri, 11 Jan 2013 20:41:29 +0100 Received: from e178038055.adsl.alicedsl.de ([85.178.38.55] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1TtkTp-001PyA-1B>; Fri, 11 Jan 2013 20:41:29 +0100 Message-ID: <50F06AE7.5000404@zedat.fu-berlin.de> Date: Fri, 11 Jan 2013 20:41:27 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: "freebs >> Current FreeBSD" Subject: r245310: /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3 X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig80E2AA3491AA04C716131220" X-Originating-IP: 85.178.38.55 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 19:41:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig80E2AA3491AA04C716131220 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable When building the system, I receive very quickly the following error when /usr/src/lib/libcxxrt is compiled: c++ -fpic -DPIC -O2 -pipe -O3 -march=3Dnative -I/usr/src/lib/libcxxrt/../../contrib/libcxxrt -Qunused-arguments -fstack-protector -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -stdlib=3Dlibc++ -std=3Dc++11 -c /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc -o memory.So /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3 /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3 return ATOMIC_SWAP(&new_handl, handler); return ATOMIC_SWAP(&new_handl, handler); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:14:47: note: expanded from macro 'ATOMIC_SWAP' __atomic_exchange(addr, val, __ATOMIC_ACQ_REL) ~~~~~~~~~~~~~~~~~ ^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:69:10: error: too few arguments to function call, expected 3, have 2 return ATOMIC_LOAD(&new_handl); ^~~~~~~~~~~~~~~~~~~~~~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~~~~~~~~~~~~~ ^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:14:47: note: expanded from macro 'ATOMIC_SWAP' __atomic_exchange(addr, val, __ATOMIC_ACQ_REL) ~~~~~~~~~~~~~~~~~ ^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:69:10: error: too few arguments to function call, expected 3, have 2 return ATOMIC_LOAD(&new_handl); ^~~~~~~~~~~~~~~~~~~~~~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~~~~~~~~~~~~~ ^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. 1 warning and 2 errors generated. *** [memory.So] Error code 1 *** [memory.o] Error code 1 2 errors *** [lib/libcxxrt__L] Error code 2 1 error *** [libraries] Error code 2 1 error *** [_libraries] Error code 2 1 error *** [buildworld] Error code 2 1 error --------------enig80E2AA3491AA04C716131220 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ8GroAAoJEOgBcD7A/5N8+7YIALN8K/fz6lYEGrWZ9iGaw5W/ E0yWETxoGPtGHXSKqpyPNiLEMkdmc3tq0lZ/Bytnnhj2/AzLCt+zDlP8j3/Uh4E/ h+fbA0pyKrMNSwApfuuUd9EH8bX1UJai8uTYH22TTKmUZCUFTeKjI7yJEdSG8vZJ k7/iuTb+PWz6qEFKf0p++CDGQzuu5xcl43pPgoJdXJK1wRL2+YeBsmv+ko4dc4Wm jEf+j3HBcI/FZA7VvJFzzXQoBdlUMKUxLFIUbbig19LAnI2HfFx0qiuK+hO4+Yo+ lnALL5gnFpzmZacuJErCkrUfyRWnsUs1R12QGjRJJkoSo+Orj9R8NBC7rfkzPVk= =ub2Q -----END PGP SIGNATURE----- --------------enig80E2AA3491AA04C716131220-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:09:57 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 309171AB; Fri, 11 Jan 2013 20:09:57 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id D77E5E3F; Fri, 11 Jan 2013 20:09:56 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 3809623F763; Fri, 11 Jan 2013 15:09:54 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.1 onyx.glenbarber.us 3809623F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Fri, 11 Jan 2013 15:09:52 -0500 From: Glen Barber To: freebsd-current@FreeBSD.org Subject: [panic] Unknown caching mode 8198 in sys/amd64/amd64/pmap.c Message-ID: <20130111200952.GA1359@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:09:57 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm running a relatively recent -CURRENT: root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # uname -a FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #50 r244773: Mon Dec 31 16:07:53 EST 2012 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 I ran into this panic twice over the past 24 hours. Both times, Chromium was the program I was actively using, with a few ssh sessions in the background. Below follows kgdb session and hopefully useful information. Any advice on how to further debug this would be appreciated. Glen Script started on Fri Jan 11 14:58:16 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # kgdb kernel.debug /var/crash/vm= core.6 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: Unknown caching mode 8198 cpuid =3D 3 KDB: stack backtrace: #0 0xffffffff80605a76 at kdb_backtrace+0x66 #1 0xffffffff805cbbbb at panic+0x13b #2 0xffffffff80879748 at pmap_cache_bits+0x58 #3 0xffffffff80880fb4 at pmap_enter+0xa4 #4 0xffffffff8084ed25 at vm_fault_hold+0x1a15 #5 0xffffffff8084f8d3 at vm_fault+0x73 #6 0xffffffff8088593a at trap_pfault+0x13a #7 0xffffffff80886184 at trap+0x4f4 #8 0xffffffff8086f853 at calltrap+0x8 Uptime: 1d14h30m4s Dumping 4646 out of 7951 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..9= 1% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdir/bo= ot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bo= otdir/boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /bootd= ir/boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /bootdir/= boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /bootd= ir/boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /boo= tdir/boot/kernel/acpi_video.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/kernel/sem.ko...Reading symbols from /bootdir/bo= ot/kernel/sem.ko.symbols...done. done. Loaded symbols for /boot/kernel/sem.ko Reading symbols from /boot/kernel/acpi_asus.ko...Reading symbols from /boot= dir/boot/kernel/acpi_asus.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_asus.ko Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /bootdir/= boot/kernel/aesni.ko.symbols...done. done. Loaded symbols for /boot/kernel/aesni.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /bootdir/boo= t/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from /bootdi= r/boot/kernel/i915kms.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915kms.ko Reading symbols from /boot/kernel/iicbb.ko...Reading symbols from /bootdir/= boot/kernel/iicbb.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicbb.ko Reading symbols from /boot/kernel/iicbus.ko...Reading symbols from /bootdir= /boot/kernel/iicbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicbus.ko Reading symbols from /boot/kernel/iic.ko...Reading symbols from /bootdir/bo= ot/kernel/iic.ko.symbols...done. done. Loaded symbols for /boot/kernel/iic.ko Reading symbols from /boot/kernel/agp.ko...Reading symbols from /bootdir/bo= ot/kernel/agp.ko.symbols...done. done. Loaded symbols for /boot/kernel/agp.ko Reading symbols from /boot/kernel/drm2.ko...Reading symbols from /bootdir/b= oot/kernel/drm2.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm2.ko Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done. Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko #0 doadump (textdump=3D) at pcpu.h:229 229 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) bt #0 doadump (textdump=3D) at pcpu.h:229 #1 0xffffffff805cb724 in kern_reboot (howto=3D260) at /usr/src/sys/kern/ke= rn_shutdown.c:446 #2 0xffffffff805cbba5 in panic (fmt=3D) at /usr/src/s= ys/kern/kern_shutdown.c:753 #3 0xffffffff80879748 in pmap_cache_bits (mode=3D, is= _pde=3D) at /usr/src/sys/amd64/amd64/pmap.c:863 #4 0xffffffff80880fb4 in pmap_enter (pmap=3D0xfffffe01bfa66440, va=3D34636= 066816, access=3D,=20 m=3D0xfffffe023dfc1b70, prot=3D, wired=3D) at /usr/src/sys/amd64/amd64/pmap.c:3456 #5 0xffffffff8084ed25 in vm_fault_hold (map=3D0xfffffe01bfa66310, vaddr=3D= 34636066816, fault_type=3D1 '\001',=20 fault_flags=3D, m_hold=3D0x0) at /usr/src/sys/vm/v= m_fault.c:914 #6 0xffffffff8084f8d3 in vm_fault (map=3D0xfffffe01bfa66310, vaddr=3D34636= 066816,=20 fault_type=3D, fault_flags=3D0) at /usr/src/sys/vm= /vm_fault.c:224 #7 0xffffffff8088593a in trap_pfault (frame=3D0xffffff8239b37ac0, usermode= =3D1) at /usr/src/sys/amd64/amd64/trap.c:756 #8 0xffffffff80886184 in trap (frame=3D0xffffff8239b37ac0) at /usr/src/sys= /amd64/amd64/trap.c:363 #9 0xffffffff8086f853 in calltrap () at /usr/src/sys/amd64/amd64/exception= =2ES:228 #10 0x000000080b0f2200 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 3 #3 0xffffffff80879748 in pmap_cache_bits (mode=3D, is= _pde=3D) at /usr/src/sys/amd64/amd64/pmap.c:863 863 panic("Unknown caching mode %d\n", mode); (kgdb) list *0xffffffff80879748 0xffffffff80879748 is at /usr/src/sys/amd64/amd64/pmap.c:863. 858 pmap_cache_bits(int mode, boolean_t is_pde) 859 { 860 int cache_bits, pat_flag, pat_idx; 861 =20 862 if (mode < 0 || mode >=3D PAT_INDEX_SIZE || pat_index[mode]= < 0) 863 panic("Unknown caching mode %d\n", mode); 864 =20 865 /* The PAT bit is different for PTE's and PDE's. */ 866 pat_flag =3D is_pde ? PG_PDE_PAT : PG_PTE_PAT; 867 =20 (kgdb) frame 4 #4 0xffffffff80880fb4 in pmap_enter (pmap=3D0xfffffe01bfa66440, va=3D34636= 066816, access=3D,=20 m=3D0xfffffe023dfc1b70, prot=3D, wired=3D) at /usr/src/sys/amd64/amd64/pmap.c:3456 3456 newpte |=3D pmap_cache_bits(m->md.pat_mode, 0); (kgdb) p *m $1 =3D {pageq =3D {tqe_next =3D 0x0, tqe_prev =3D 0xffffffff80d2f1b8}, list= q =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0xfffffe023dfc1b08}, left =3D 0xfffffe023dfc1af8, right = =3D 0x0, object =3D 0xfffffe00219a93a0,=20 pindex =3D 2905, phys_addr =3D 8809881600, md =3D {pv_list =3D {tqh_first= =3D 0x0, tqh_last =3D 0xfffffe023dfc1bb8},=20 pat_mode =3D 8198}, queue =3D 255 '=FF', segind =3D 10 '\n', hold_count= =3D 0, order =3D 13 '\r', pool =3D 0 '\0',=20 cow =3D 0, wire_count =3D 0, aflags =3D 0 '\0', oflags =3D 1 '\001', flag= s =3D 0, act_count =3D 0 '\0', busy =3D 0 '\0',=20 valid =3D 255 '=FF', dirty =3D 0 '\0'} (kgdb) list *0xffffffff80880fb4 0xffffffff80880fb4 is in pmap_enter (/usr/src/sys/amd64/amd64/pmap.c:3461). 3456 newpte |=3D pmap_cache_bits(m->md.pat_mode, 0); 3457 =20 3458 mpte =3D NULL; 3459 =20 3460 lock =3D NULL; 3461 rw_rlock(&pvh_global_lock); 3462 PMAP_LOCK(pmap); 3463 =20 3464 /* 3465 * In the case that a page table page is not (kgdb) root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # ^D Script done on Fri Jan 11 14:58:54 2013 --jRHKVT23PllUwdXP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQ8HGPAAoJEFJPDDeguUaj0y4H/1lmJNgBQ5mqJ5XF2pmVP8li zNd0l0scELRr4zvbwWM6nOP6X2w4gJXZ9C8AB8HjUtUVarPGNV1IxFFLeJtlg1qi ZNCtPNZxRVoIZAWfBMI7bDYXgYnqwBV9URtRnI8MEuhf1D1P2gNzswZ0fviBFeIW sJP+CGCu25w63omvm0GCt2rbzunevv4+b2cnFYSXIc8RUgExLzEFPPc6Bre6Fcp3 Sw/ofH+CZFvJppupktv0H03+/D5pi74kkggdlAea3HTSTJAgO6xiKR14LgFRI5FD XNXMFq7o+Xbmh6yvfAnPN/YukgNzr2kktUrFWFrnVqzam6F6u1/x/rXkxJuVVDc= =2XV7 -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:30:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C2B8741 for ; Fri, 11 Jan 2013 20:30:57 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0D06EF18 for ; Fri, 11 Jan 2013 20:30:56 +0000 (UTC) Received: by mail-da0-f45.google.com with SMTP id w4so927764dam.32 for ; Fri, 11 Jan 2013 12:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pD/8Vn2BZ/t8+wpf4OaaldDr/ZUAYHoLkeKXIthL47w=; b=e1NYPTFxLmLWKIjkvzGxFntj8zWFued/ExXXaDF6VefqXtyFVJDTI1x78KMZpUDEIj aTsMoJXCXCcxkBCRe84hsS0W3TFNbiGogbFXwg1u8WYbVw5m5O9H2wUGF2PGplq76V/Z 8n3Z9o1FndGGwK1d+uN4oBEs2TH6h0bWCMmq8x7Nfch63bBiZqS4Ci7Bmjz8o6+J/8PO evP7CEVRq9SZjrnuaNmIz1CdUYW1mY8uPbJwQOov3cyPP+CKL4J91CsefRU875orvaQ8 U+Aes3OYald8l3MdhZGz62toekpEirtjZBEwoO++QFIudT49V4h4LgOMk+MxKxx5fzXN L/jw== MIME-Version: 1.0 Received: by 10.68.223.230 with SMTP id qx6mr235032619pbc.159.1357936256517; Fri, 11 Jan 2013 12:30:56 -0800 (PST) Received: by 10.67.2.65 with HTTP; Fri, 11 Jan 2013 12:30:56 -0800 (PST) In-Reply-To: <50F01F52.10006@icritical.com> References: <50E42264.4010609@freebsd.org> <50E4357B.7020400@freebsd.org> <50F01F52.10006@icritical.com> Date: Fri, 11 Jan 2013 12:30:56 -0800 Message-ID: Subject: Re: installworld failure due to cross-device links From: Kevin Oberman To: Matt Burke Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:30:57 -0000 On Fri, Jan 11, 2013 at 6:18 AM, Matt Burke wrote: > On 01/02/13 13:26, Nathan Whitehorn wrote: >> Thanks for the patch! I've committed it (slightly modified) as r244958. >> I haven't taken any action on the chgrp/chown issue, though. > > Similarly, 'make distribution' fails when /root is a separate filesystem: > > cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.profile > /tmproot/root/.profile; rm -f /tmproot/.profile; ln > /tmproot/root/.profile /tmproot/.profile > ln: /tmproot/.profile: Cross-device link > *** [distribution] Error code 1 > > Is there any real advantage of hard links over symlinks nowadays? Yes. In fact, hard links are essential for some purposes. Key advantage of hard links is that you can create and use them as long as needed and then just delete them. Any remaining hard links are unaffected. When the last hard link is deleted, so is the file. Symlinks, on the other hand are simply pointer to a real file and if the file is deleted, the symlink remains, but is broken. Of course, symlinks can cross file systems when hard links can't. Both are likely to remain useful and neither is appropriate for all applications. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:42:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DA20193F; Fri, 11 Jan 2013 20:42:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B85AFF72; Fri, 11 Jan 2013 20:42:03 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 10165B968; Fri, 11 Jan 2013 15:42:03 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: FILE's _file can only hold a short Date: Fri, 11 Jan 2013 10:44:32 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301111044.32719.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Jan 2013 15:42:03 -0500 (EST) Cc: mdf@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:42:03 -0000 On Wednesday, October 31, 2012 02:12:55 PM mdf@freebsd.org wrote: > I seem to recall a thread earlier on this limitation, but looking at > actual libc/stdio sources, the 4 year old check for open(2)'s fd being > less than SHRT_MAX is still there. I thought I saw a patch to change > this to an int, but it's not in the tree. Was this in a PR or a > mailing list thread or am I just imagining things? > > We've run into this limitation at work, where some processes have > around 32k open file descriptors and then try to use the libc FILE > interface. Since we control ABI we can just change this to int, but I > had been hoping there was a FreeBSD revision we could pull instead of > having another diff. I had been working on a port-exp run. The problem I have run into is that perl actually reaches inside of FILE directly to clear out _file so it can control when the fd is actually closed (really gross). I have extended my stuff so that old Perl binaries should still work, but wanted to figure out how to prevent future Perl binaries from growing the same dependency. Also, I haven't had a chance to do a follow-up to find what else out in ports-land tries to use _file directly from FILE. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:42:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A1F49941; Fri, 11 Jan 2013 20:42:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7E6ABF73; Fri, 11 Jan 2013 20:42:04 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CDED0B98A; Fri, 11 Jan 2013 15:42:03 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: sysutils/lsof Author Question (for CLANG).... Date: Fri, 11 Jan 2013 11:10:39 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <5d4c4abe37bd6fffd0c206c1b7b68ce1@webmail.lerctr.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301111110.39677.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Jan 2013 15:42:03 -0500 (EST) Cc: Greg 'groggy' Lehey , Eitan Adler , Benjamin Kaduk , Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:42:04 -0000 On Wednesday, November 07, 2012 06:15:21 PM Eitan Adler wrote: > On 7 November 2012 17:35, Larry Rosenman wrote: > > On 2012-11-07 15:39, Greg 'groggy' Lehey wrote: > >> On Wednesday, 7 November 2012 at 10:32:23 -0500, Benjamin Kaduk wrote: > >>> Once again, attempting to use kernel internals outside of the > >>> supported interfaces is just asking for trouble; I do not understand > >>> why this message is not sinking in over the course of your previous > >>> mails to these lists, so I will not try to belabor it further. > >> > >> IIRC lsof is a special case that always needs to be built with > >> intimate knowledge of the kernel. > > > > This is VERY true. Since some of the information lsof uses has > > no API/ABI/KPI/KBI to get, it grovels around in the kernel. > > Can you tell us what interfaces you need? Perhaps we can either point > you to ones that may work better or seek provide (stable) kernel > features? The sysctls used by procstat -f and -v are close, (better than kern.files for example). However, lsof also reads other things we don't export such as the file descriptor locking state (flock(), etc.) and that requires direct access to KVM still. If you want to fix it, try to port lsof to use sysctls and see what you run into. The code isn't that hard to work with. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:42:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 600E9943; Fri, 11 Jan 2013 20:42:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF24F74; Fri, 11 Jan 2013 20:42:05 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 84E7DB993; Fri, 11 Jan 2013 15:42:04 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm Date: Fri, 11 Jan 2013 11:16:06 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201211082303.qA8N3RlN031977@freebsd-current.sentex.ca> <509D858C.6060005@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301111116.06531.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Jan 2013 15:42:04 -0500 (EST) Cc: Adrian Chadd , Chuck Burns X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:42:05 -0000 On Friday, November 09, 2012 05:47:43 PM Adrian Chadd wrote: > On 9 November 2012 14:37, Chuck Burns wrote: > > Adrian. diskspace and cpu cycles are things I can spare, drop me a line > > outside of the ML and we can discuss particulars. "It's just a personal > > box.. on a residential internet service, I have an amd64 box with 600G > > free on my pool.. 8G ram.. and I have a smaller i386 box... 100G or so > > free, 512M ram.. just drop me a line.. > > Hi, > > Those I do have - I have access to all of the ref* boxes in the > cluster. I'm just typically hacking on this stuff on the train or at a > cafe, and I don't have a workflow setup for pushing out potential > diffs to build machines that have all the grunt/disk space for each > little change that I do. > > I'm sorry about breaking things from time to time, but besides a small > handful of "what was I thinking?!" things, the build breaks are just > that - build breaks. They're easily fixed. This is why I use p4 branches. I hack on my laptop and then commit it to p4 and use 'p4 sync' as a glorified rsync on development hosts. I can then do a full 'make tinderbox' before committing to HEAD after extracting the patches from p4 and applying them to an SVN checkout. SVN branches should let you do something similar as well (or just about any soure code control system you choose to use). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:42:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 123AA945 for ; Fri, 11 Jan 2013 20:42:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E4331F75 for ; Fri, 11 Jan 2013 20:42:05 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 482A0B9B2; Fri, 11 Jan 2013 15:42:05 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: No ATA disks on 9.1-RC3 Date: Fri, 11 Jan 2013 11:33:24 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <50A9ECB3.8010209@lissyara.su> In-Reply-To: <50A9ECB3.8010209@lissyara.su> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301111133.24133.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Jan 2013 15:42:05 -0500 (EST) Cc: Alex Keda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:42:06 -0000 On Monday, November 19, 2012 03:24:19 AM Alex Keda wrote: > I try update my laptop - Compaq 6715s from 9.0 to 9.1-rc3 > it cannot boot, because no HDD found > dmesg from 9.0/9.1 and pciconf in attached files Can you get a verbose dmesg from 9.0? Also, if at all possible, it would be very helpful to get the full verbose dmesg from both 9.0 and 9.1 (the 9.1 one is truncated at the top). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:42:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2596946; Fri, 11 Jan 2013 20:42:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8FEB4F76; Fri, 11 Jan 2013 20:42:06 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EE9CFB9B3; Fri, 11 Jan 2013 15:42:05 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: syscall cost freebsd vs linux ? Date: Fri, 11 Jan 2013 11:35:49 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20121119193202.GA79496@onelab2.iet.unipi.it> <50B460AA.10300@FreeBSD.org> In-Reply-To: <50B460AA.10300@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301111135.49997.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Jan 2013 15:42:06 -0500 (EST) Cc: Andrey Zonov , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:42:06 -0000 On Tuesday, November 27, 2012 01:41:46 AM Andrey Zonov wrote: > On 11/19/12 11:32 PM, Luigi Rizzo wrote: > > today i was comparing the performance of some netmap-related code > > on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that > > our system calls are significantly slower. > > On comparable hardware (i7-2600k vs E5-1650) the syscall > > getppid() takes about 95ns on FreeBSD and 38ns on linux. > > > > (i make sure not to use gettimeofday(), which in linux is through vdso, > > and getpid(), which is cached by glibc). > > > > Any idea on why there is this difference and whether/how > > we can reduce it ? > > This is the cost of blocking mutexes. Linux uses RCU instead [1]. > > Here are the numbers on current: > > $ time ./getppid 100000000 > > real 0m22.926s > user 0m2.252s > sys 0m20.669s > > After locking removing (patch below): > > $ time ./getppid 100000000 > > real 0m15.224s > user 0m2.355s > sys 0m12.868s > > Unfortunately, RCU can be used only in GPL code, but we can use "passive > serialization" for simple deref. And even more, it's already > implemented in NetBSD. Of course, that is specific to getppid(). Micro-optimizing getppid() is probably not all that useful, and I suspect Luigi is more concerned about syscall overhead as it impacts other system calls. Perhaps compare getppid() on Linux with getpid() on FreeBSD. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:42:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E250948 for ; Fri, 11 Jan 2013 20:42:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B167F77 for ; Fri, 11 Jan 2013 20:42:07 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 99E83B9B9; Fri, 11 Jan 2013 15:42:06 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Spurious witness warning when destroying spin mtx Date: Fri, 11 Jan 2013 11:44:09 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301111144.10060.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Jan 2013 15:42:06 -0500 (EST) Cc: Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:42:07 -0000 On Friday, November 23, 2012 10:08:28 PM Ryan Stone wrote: > Today I saw a spurious witness warning for "acquiring duplicate lock of > same type". The root cause is that when running mtx_destroy on a spinlock > that is held by the current thread, mtx_destroy calls spinlock_exit() > before calling WITNESS_UNLOCK, which opens up a window in which the CPU can > be interrupted and attempt to acquire another spinlock of the same type as > the one being destroyed. This patch should fix it: > > diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c > index 2f13863..96f43f8 100644 > --- a/sys/kern/kern_mutex.c > +++ b/sys/kern/kern_mutex.c > @@ -918,16 +918,16 @@ _mtx_destroy(volatile uintptr_t *c) > else { > MPASS((m->mtx_lock & (MTX_RECURSED|MTX_CONTESTED)) == 0); > > + lock_profile_release_lock(&m->lock_object); > + /* Tell witness this isn't locked to make it happy. */ > + WITNESS_UNLOCK(&m->lock_object, LOP_EXCLUSIVE, __FILE__, > + __LINE__); > + > /* Perform the non-mtx related part of mtx_unlock_spin(). > */ if (LOCK_CLASS(&m->lock_object) == &lock_class_mtx_spin) > spinlock_exit(); > else > curthread->td_locks--; > - > - lock_profile_release_lock(&m->lock_object); > - /* Tell witness this isn't locked to make it happy. */ > - WITNESS_UNLOCK(&m->lock_object, LOP_EXCLUSIVE, __FILE__, > - __LINE__); > } > > m->mtx_lock = MTX_DESTROYED Ah, I would tweak this slightly perhaps to match mtx_unlock() and mtx_unlock_spin(): if (LOCK_CLASS() == &lock_class_mtx_sleep) curthread->td_locks--; /* lock profile and witness stuff */ if (LOCK_CLASS() == &lock_class_mtx_spin) spinlock_exit(); You are correct that it is broken for the spin case. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:42:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06F1D949 for ; Fri, 11 Jan 2013 20:42:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D7837F78 for ; Fri, 11 Jan 2013 20:42:07 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 31BBDB9BE; Fri, 11 Jan 2013 15:42:07 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: panic: page fault Date: Fri, 11 Jan 2013 15:26:57 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120814122909.4a3213ee@nonamehost> <201208141404.07743.jhb@freebsd.org> <20121221124726.7e678e11@nonamehost> In-Reply-To: <20121221124726.7e678e11@nonamehost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201301111526.57416.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Jan 2013 15:42:07 -0500 (EST) Cc: Ivan Klymenko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:42:08 -0000 On Friday, December 21, 2012 05:47:26 AM Ivan Klymenko wrote: > =D0=92 Tue, 14 Aug 2012 14:04:07 -0400 >=20 > John Baldwin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Tuesday, August 14, 2012 05:29:09 AM Ivan Klymenko wrote: > > > http://privatepaste.com/147286442b > >=20 > > It is easier to reply if the messages are inline (for future > > reference). The panic and relevant bit of backtrace are below. > > Sadly, trying to cut and paste this destroyed the formatting, so I've > > tried to fix it by hand. :( > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x18 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff80933e07 > > stack pointer =3D 0x28:0xffffff823025b660 > > frame pointer =3D 0x28:0xffffff823025b6c0 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > >=20 > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > >=20 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 12 (irq256: bce0) > > trap number =3D 12 > > panic: page fault > >=20 > > #6 0xffffffff80bb5e53 in calltrap () > >=20 > > at /usr/src/sys/amd64/amd64/exception.S:228 > >=20 > > #7 0xffffffff80933e07 in m_copym (m=3D0x0, off0=3D1500, len=3D1480, wa= it=3D1) > >=20 > > at /usr/src/sys/kern/uipc_mbuf.c:542 > >=20 > > #8 0xffffffff809f8b76 in ip_fragment (ip=3D0xfffffe004b2f3980, > > m_frag=3D0xffffff823025b7c8, mtu=3DVariable "mtu" is not available. ) > >=20 > > at /usr/src/sys/netinet/ip_output.c:822 > >=20 > > #9 0xffffffff809f948a in ip_output (m=3D0xfffffe004b2f3900, > > opt=3DVariable "opt" is not available. ) > >=20 > > at /usr/src/sys/netinet/ip_output.c:654 > >=20 > > #10 0xffffffff809f59fa in ip_forward (m=3D0xfffffe004b2f3900, > > srcrt=3DVariable "srcrt" is not available. ) > >=20 > > at /usr/src/sys/netinet/ip_input.c:1494 > >=20 > > #11 0xffffffff809f6dc6 in ip_input (m=3D0xfffffe004b2f3900) > >=20 > > at /usr/src/sys/netinet/ip_input.c:702 >=20 > I apologize for not having answered - no more required files... > At that time it was not possible to fulfill your request ... > Now I have gained a number of similar panic's and i ready to provide > the results. >=20 > > Can you run kgdb again and do 'frame 8' followed by 'p *m_frag', 'p > > m0', and 'p *m0'? >=20 > kgdb.log in attach Looks like this attachment was lost unfortunately. Can you reply with the output inline (and include the output from the other kgdb commands below)? > > Can you also grab my gdb scripts at www.freebsd.org/~jhb/gdb/ and run > > 'cd /path/to/scripts', 'source gdb6', 'mbuf m0' as well? >=20 > What kind of shell should I use for this? Ah, those are meant to be run while you are in kgdb. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 20:30:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD4AA740 for ; Fri, 11 Jan 2013 20:30:54 +0000 (UTC) (envelope-from xenophon@irtnog.org) Received: from mx1.irtnog.org (rrcs-24-123-13-61.central.biz.rr.com [24.123.13.61]) by mx1.freebsd.org (Postfix) with ESMTP id 8C50FF17 for ; Fri, 11 Jan 2013 20:30:53 +0000 (UTC) Received: from cinep001bsdgw.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id D13011A820 for ; Fri, 11 Jan 2013 15:30:52 -0500 (EST) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by cinep001bsdgw.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCpNu2Iswnk3 for ; Fri, 11 Jan 2013 15:30:45 -0500 (EST) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP for ; Fri, 11 Jan 2013 15:30:45 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Expanding ZFS RAIDZ on the fly? Date: Fri, 11 Jan 2013 15:30:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <20130111140557.GA63102@psconsult.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expanding ZFS RAIDZ on the fly? thread-index: Ac3wBNTIjujhLPfqRrOQAYmWX2WZ/wANRyAw References: <50EFBAEA.3070200@zedat.fu-berlin.de> <20130111140557.GA63102@psconsult.nl> From: "Matthew X. Economou" To: X-Mailman-Approved-At: Fri, 11 Jan 2013 20:57:32 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:30:54 -0000 Speaking of ZFS restriping, is anyone (Oracle/FreeBSD/etc.) actively working on block pointer rewrite functionality for ZFS? --=20 I FIGHT FOR THE USERS From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 21:16:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ACEACEE2; Fri, 11 Jan 2013 21:16:10 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by mx1.freebsd.org (Postfix) with ESMTP id 6ED6D1E5; Fri, 11 Jan 2013 21:16:10 +0000 (UTC) Received: by mail-da0-f41.google.com with SMTP id e20so945683dak.0 for ; Fri, 11 Jan 2013 13:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rEuVDI2zABzNtyExBrXusCHr/OC8f50IbU3mrXQsgbE=; b=fj60gIK9m4SosiXYgqqmaa+SbpbEJiZwJdcXCxgnSynwyY6TgiS7GHIQoyOtaRFBeO Od38DmzZrEAJhpiFhbl3xI7vl53vuvJ5BbZd3MFcmfMA2BHVizyBZcA9XftL4n1XCXds eZscX87TbWjB21RgpnUDSfLtILtQeJ9pXLRQs26kEGTHk/U10pgyS9wQt3/PlXaNFGv2 VbFIqvVbJ+iPdSgn/aznDWGvCUZUoAfKF2uE2yeK70xz9TcCvfstT6aqNVO1ryP3r9Tu BHmb97xQv+YLDIyWdTWN+PAlpnxnzhp6y69YEj5eekai1X0LLH48xkUU/WwQGSmLVDBv /QaA== MIME-Version: 1.0 Received: by 10.66.76.8 with SMTP id g8mr210472173paw.40.1357938964398; Fri, 11 Jan 2013 13:16:04 -0800 (PST) Received: by 10.67.2.65 with HTTP; Fri, 11 Jan 2013 13:16:04 -0800 (PST) In-Reply-To: <201301111044.32719.jhb@freebsd.org> References: <201301111044.32719.jhb@freebsd.org> Date: Fri, 11 Jan 2013 13:16:04 -0800 Message-ID: Subject: Re: FILE's _file can only hold a short From: Kevin Oberman To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: mdf@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:16:10 -0000 On Fri, Jan 11, 2013 at 7:44 AM, John Baldwin wrote: > On Wednesday, October 31, 2012 02:12:55 PM mdf@freebsd.org wrote: >> I seem to recall a thread earlier on this limitation, but looking at >> actual libc/stdio sources, the 4 year old check for open(2)'s fd being >> less than SHRT_MAX is still there. I thought I saw a patch to change >> this to an int, but it's not in the tree. Was this in a PR or a >> mailing list thread or am I just imagining things? >> >> We've run into this limitation at work, where some processes have >> around 32k open file descriptors and then try to use the libc FILE >> interface. Since we control ABI we can just change this to int, but I >> had been hoping there was a FreeBSD revision we could pull instead of >> having another diff. > > I had been working on a port-exp run. The problem I have run into is > that perl actually reaches inside of FILE directly to clear out _file > so it can control when the fd is actually closed (really gross). I > have extended my stuff so that old Perl binaries should still work, but > wanted to figure out how to prevent future Perl binaries from growing > the same dependency. Also, I haven't had a chance to do a follow-up > to find what else out in ports-land tries to use _file directly from > FILE. John, I posted a problem I am having with a perl script that opens multiple filehandles with output to a pipe (open $fh,"command|";). The script has worked fine for over a decade, but an upgrade of FreeBSD from 7.2 to 8.3 caused the program to fail to transfer the entire output (between 14 and 30KB of data in lines of between 1 and 80 bytes. (Output of show bgp summary on a Juniper.) The sub-process just hangs until my watchdog sends a sigterm after 15 seconds. When I read the filehadle, I get only a truncated output from these processes. Others complete normally with full output. the failures tend to be ones with larger outputs, but not always. I have worked around this, but I would love to know why it broke in 8.3 after working since at least v5 and probably 4.3. Since this is a common technique or running multiple commands in parallel in perl, it would be nice if I could at least understand what is going on. This looks a bit like what this thread is discussing, but I am far from certain. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 22:38:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9640316D; Fri, 11 Jan 2013 22:38:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 475A270A; Fri, 11 Jan 2013 22:38:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0BMQSLc021305; Fri, 11 Jan 2013 17:26:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0BMQSj5021301; Fri, 11 Jan 2013 22:26:28 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 11 Jan 2013 22:26:28 GMT Message-Id: <201301112226.r0BMQSj5021301@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 22:38:22 -0000 TB --- 2013-01-11 20:50:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-11 20:50:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-11 20:50:16 - starting HEAD tinderbox run for i386/i386 TB --- 2013-01-11 20:50:16 - cleaning the object tree TB --- 2013-01-11 20:50:16 - /usr/local/bin/svn stat /src TB --- 2013-01-11 20:50:20 - At svn revision 245310 TB --- 2013-01-11 20:50:21 - building world TB --- 2013-01-11 20:50:21 - CROSS_BUILD_TESTING=YES TB --- 2013-01-11 20:50:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-11 20:50:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-11 20:50:21 - SRCCONF=/dev/null TB --- 2013-01-11 20:50:21 - TARGET=i386 TB --- 2013-01-11 20:50:21 - TARGET_ARCH=i386 TB --- 2013-01-11 20:50:21 - TZ=UTC TB --- 2013-01-11 20:50:21 - __MAKE_CONF=/dev/null TB --- 2013-01-11 20:50:21 - cd /src TB --- 2013-01-11 20:50:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 11 20:50:26 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ^~~~~~~~~~~~~~~~~~~~~~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~~~~~~~~~~~~~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-11 22:26:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-11 22:26:28 - ERROR: failed to build world TB --- 2013-01-11 22:26:28 - 4746.52 user 719.55 system 5771.76 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 22:38:23 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EA4716F; Fri, 11 Jan 2013 22:38:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C732F70C; Fri, 11 Jan 2013 22:38:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0BMQWeq021384; Fri, 11 Jan 2013 17:26:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0BMQWH4021383; Fri, 11 Jan 2013 22:26:32 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 11 Jan 2013 22:26:32 GMT Message-Id: <201301112226.r0BMQWH4021383@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 22:38:23 -0000 TB --- 2013-01-11 20:50:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-11 20:50:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-11 20:50:16 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-01-11 20:50:16 - cleaning the object tree TB --- 2013-01-11 20:50:16 - /usr/local/bin/svn stat /src TB --- 2013-01-11 20:50:20 - At svn revision 245310 TB --- 2013-01-11 20:50:21 - building world TB --- 2013-01-11 20:50:21 - CROSS_BUILD_TESTING=YES TB --- 2013-01-11 20:50:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-11 20:50:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-11 20:50:21 - SRCCONF=/dev/null TB --- 2013-01-11 20:50:21 - TARGET=amd64 TB --- 2013-01-11 20:50:21 - TARGET_ARCH=amd64 TB --- 2013-01-11 20:50:21 - TZ=UTC TB --- 2013-01-11 20:50:21 - __MAKE_CONF=/dev/null TB --- 2013-01-11 20:50:21 - cd /src TB --- 2013-01-11 20:50:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 11 20:50:26 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ^~~~~~~~~~~~~~~~~~~~~~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~~~~~~~~~~~~~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-11 22:26:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-11 22:26:32 - ERROR: failed to build world TB --- 2013-01-11 22:26:32 - 4753.98 user 716.46 system 5775.46 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 22:59:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DE7EC912; Fri, 11 Jan 2013 22:59:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f51.google.com (mail-da0-f51.google.com [209.85.210.51]) by mx1.freebsd.org (Postfix) with ESMTP id B5C8E830; Fri, 11 Jan 2013 22:59:13 +0000 (UTC) Received: by mail-da0-f51.google.com with SMTP id i30so968567dad.24 for ; Fri, 11 Jan 2013 14:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=RLFje69LNKVOaA/6/wrSBk9UPIdyQFjQ8d82PG3VhAA=; b=v//SpyCQUxrYEKNYaBEk3qA1XEVI/s93rI1ZAJAp1my0G6KGButVYrB++/PlHzXyr9 y9NGBSbpS5y9NnTBrhmKe6dSy4Ply4Tf1YNkGBg3Ze0VRJ1LpDVIjQasCviBTeTUj0uP 2VL6HMT3/QaI+onZ8LCPXaxAsjeAhG1z/aeF9XY7Dxyhc78Op7ozhdmDYn/djG+RtCFV LQDNl6Faf6qQtE0wh15xtVuq9ltsXgIRDEuaS0hffm38IywqRhifNClSdwql6uLKzUAl kK4/eMuU/x468+RNzfLHXJdPYN65C2ciINr/74SyK3thmz1bDXB7kc6mVeQCqcSgUa7J 2AYA== X-Received: by 10.68.220.161 with SMTP id px1mr81650421pbc.167.1357945147865; Fri, 11 Jan 2013 14:59:07 -0800 (PST) Received: from [10.76.220.84] (mobile-166-137-216-147.mycingular.net. [166.137.216.147]) by mx.google.com with ESMTPS id vo6sm3506838pbc.8.2013.01.11.14.59.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jan 2013 14:59:07 -0800 (PST) References: <50F06AE7.5000404@zedat.fu-berlin.de> Mime-Version: 1.0 (1.0) In-Reply-To: <50F06AE7.5000404@zedat.fu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: r245310: /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3 Date: Fri, 11 Jan 2013 14:59:04 -0800 To: "O. Hartmann" Cc: "freebs >> Current FreeBSD" , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 22:59:13 -0000 Dimitry cced. Sent from my iPhone On Jan 11, 2013, at 11:41 AM, "O. Hartmann" wr= ote: > When building the system, I receive very quickly the following error > when /usr/src/lib/libcxxrt is compiled: >=20 >=20 > c++ -fpic -DPIC -O2 -pipe -O3 -march=3Dnative > -I/usr/src/lib/libcxxrt/../../contrib/libcxxrt -Qunused-arguments > -fstack-protector -Wno-empty-body -Wno-string-plus-int > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum > -Wno-parentheses -stdlib=3Dlibc++ -std=3Dc++11 -c > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc -o memory.So > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too > few arguments to function call, expected 4, have 3 > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too > few arguments to function call, expected 4, have 3 > return ATOMIC_SWAP(&new_handl, handler); > return ATOMIC_SWAP(&new_handl, handler); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:14:47: note: > expanded from macro 'ATOMIC_SWAP' > __atomic_exchange(addr, val, __ATOMIC_ACQ_REL) > ~~~~~~~~~~~~~~~~~ ^ > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:69:10: error: too > few arguments to function call, expected 3, have 2 > return ATOMIC_LOAD(&new_handl); > ^~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:25:38: note: > expanded from macro 'ATOMIC_LOAD' > __atomic_load(addr, __ATOMIC_ACQUIRE) > ~~~~~~~~~~~~~ ^ > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:149:6: warning: > function previously declared with an implicit exception specification > redeclared with an explicit exception specification > [-Wimplicit-exception-spec-mismatch] > void operator delete[](void * ptr) throw() > ^ > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:14:47: note: > expanded from macro 'ATOMIC_SWAP' > __atomic_exchange(addr, val, __ATOMIC_ACQ_REL) > ~~~~~~~~~~~~~~~~~ ^ > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:69:10: error: too > few arguments to function call, expected 3, have 2 > return ATOMIC_LOAD(&new_handl); > ^~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:25:38: note: > expanded from macro 'ATOMIC_LOAD' > __atomic_load(addr, __ATOMIC_ACQUIRE) > ~~~~~~~~~~~~~ ^ > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:149:6: warning: > function previously declared with an implicit exception specification > redeclared with an explicit exception specification > [-Wimplicit-exception-spec-mismatch] > void operator delete[](void * ptr) throw() > ^ > 1 warning and 2 errors generated. > 1 warning and 2 errors generated. > *** [memory.So] Error code 1 > *** [memory.o] Error code 1 > 2 errors > *** [lib/libcxxrt__L] Error code 2 > 1 error > *** [libraries] Error code 2 > 1 error > *** [_libraries] Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error >=20 From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 23:34:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E80A6256 for ; Fri, 11 Jan 2013 23:34:30 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id A654095C for ; Fri, 11 Jan 2013 23:34:30 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tto7J-000Jx1-2s; Fri, 11 Jan 2013 18:34:29 -0500 Date: Fri, 11 Jan 2013 18:34:28 -0500 From: Gary Palmer To: "Matthew X. Economou" Subject: Re: Expanding ZFS RAIDZ on the fly? Message-ID: <20130111233428.GA54865@in-addr.com> References: <50EFBAEA.3070200@zedat.fu-berlin.de> <20130111140557.GA63102@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 23:34:31 -0000 On Fri, Jan 11, 2013 at 03:30:44PM -0500, Matthew X. Economou wrote: > Speaking of ZFS restriping, is anyone (Oracle/FreeBSD/etc.) actively > working on block pointer rewrite functionality for ZFS? If Oracle does it, I wouldn't expect to see it released in source code form for the rest of us to use. Regarding non-Oracle entities developing the code http://www.mail-archive.com/discuss@lists.illumos.org.hold.archive.listbox.com/msg00002.html BPR doesn't look likely, unfortunately. Regards, Gary From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 23:44:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 29BF19B5; Fri, 11 Jan 2013 23:44:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D2E7B9D5; Fri, 11 Jan 2013 23:44:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0BNioFi074982; Fri, 11 Jan 2013 18:44:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0BNioH5074966; Fri, 11 Jan 2013 23:44:50 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 11 Jan 2013 23:44:50 GMT Message-Id: <201301112344.r0BNioH5074966@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 23:44:52 -0000 TB --- 2013-01-11 22:02:00 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-11 22:02:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-11 22:02:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-01-11 22:02:00 - cleaning the object tree TB --- 2013-01-11 22:02:00 - /usr/local/bin/svn stat /src TB --- 2013-01-11 22:02:03 - At svn revision 245310 TB --- 2013-01-11 22:02:04 - building world TB --- 2013-01-11 22:02:04 - CROSS_BUILD_TESTING=YES TB --- 2013-01-11 22:02:04 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-11 22:02:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-11 22:02:04 - SRCCONF=/dev/null TB --- 2013-01-11 22:02:04 - TARGET=pc98 TB --- 2013-01-11 22:02:04 - TARGET_ARCH=i386 TB --- 2013-01-11 22:02:04 - TZ=UTC TB --- 2013-01-11 22:02:04 - __MAKE_CONF=/dev/null TB --- 2013-01-11 22:02:04 - cd /src TB --- 2013-01-11 22:02:04 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 11 22:02:09 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ^~~~~~~~~~~~~~~~~~~~~~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~~~~~~~~~~~~~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-11 23:44:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-11 23:44:50 - ERROR: failed to build world TB --- 2013-01-11 23:44:50 - 5019.84 user 796.99 system 6169.86 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 00:41:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2BC25E1; Sat, 12 Jan 2013 00:41:38 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB92C01; Sat, 12 Jan 2013 00:41:38 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r0C0fVwV093201; Fri, 11 Jan 2013 19:41:37 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50F0B13B.1050708@m5p.com> Date: Fri, 11 Jan 2013 19:41:31 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: Gleb Kurtsou Subject: Re: Circular port dependency References: <50EF6935.3070000@m5p.com> <20130111082226.GA2969@reks> In-Reply-To: <20130111082226.GA2969@reks> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Fri, 11 Jan 2013 19:41:37 -0500 (EST) Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 00:41:38 -0000 On 01/11/13 03:22, Gleb Kurtsou wrote: > On (10/01/2013 20:21), George Mitchell wrote: >> I grabbed the ports tree as of 308518, the RELEASE_9_1_0 tag. >> devel/libtool won't build, because it requires autom4te during the >> configure phase. So I put "BUILD_DEPENDS= autom4te:devel/autoconf" >> in the Makefile. But autoconf depends on gmake, which depends on >> gettext, which depends on libiconv, which depends on libtool. >> What to do? > > Build devel/gmake defining WITHOUT_NLS: > # cd /usr/ports/devel/gmake && make -DWITHOUT_NLS all install > > Why would anybody want NLS support in make in a first place? > >> >> I'm running on a CURRENT build on my Raspberry Pi. >> -- George Mitchell >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" It turns out the circular dependency is the side effect of the FreeBSD 10 autotools fix. Upon discovering that acinclude.m4 has been modified, the port decides it needs to run autom4te. I worked around the problem with "make -DWITHOUT_FBSD10_FIX", with no apparent ill effects. Perhaps the devel/libtool Makefile should always define WITHOUT_FBSD10_FIX. -- George Mitchell From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 03:44:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9CCF9F00; Sat, 12 Jan 2013 03:44:33 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) by mx1.freebsd.org (Postfix) with ESMTP id 449D11A9; Sat, 12 Jan 2013 03:44:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Ugy3Srr2gn5Pk081xCrhhQQSaSvFrNxAMgCPPFkbKYw=; b=QoH9vi2ocHePkqqPhDILlRZJ3VMcBo157iWMhyJjzLcItcWx2ckBB6Rvq3Ih8LK5+bVi9PCp6kVzkdnUToYg6XzOKNWFvncsDTvE0bGh+f6x99FR25CI/wwyktJktpPHdjRE/hnNQh0znv23aAD68PlAuFjpqVT9nX91gry2r+o=; Received: from [178.137.138.140] (helo=nonamehost) by fsm2.ukr.net with esmtpsa ID 1TtmO1-00095y-BF ; Fri, 11 Jan 2013 23:43:37 +0200 Date: Fri, 11 Jan 2013 23:43:35 +0200 From: Ivan Klymenko To: John Baldwin Subject: Re: panic: page fault Message-ID: <20130111234335.3bc62d2b@nonamehost> In-Reply-To: <201301111526.57416.jhb@freebsd.org> References: <20120814122909.4a3213ee@nonamehost> <201208141404.07743.jhb@freebsd.org> <20121221124726.7e678e11@nonamehost> <201301111526.57416.jhb@freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/QvrSkd_9U6t7dWNNEYJSCCL" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 03:44:33 -0000 --MP_/QvrSkd_9U6t7dWNNEYJSCCL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =D0=92 Fri, 11 Jan 2013 15:26:57 -0500 John Baldwin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Friday, December 21, 2012 05:47:26 AM Ivan Klymenko wrote: > > =D0=92 Tue, 14 Aug 2012 14:04:07 -0400 > >=20 > > John Baldwin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > On Tuesday, August 14, 2012 05:29:09 AM Ivan Klymenko wrote: > > > > http://privatepaste.com/147286442b > > >=20 > > > It is easier to reply if the messages are inline (for future > > > reference). The panic and relevant bit of backtrace are below. > > > Sadly, trying to cut and paste this destroyed the formatting, so > > > I've tried to fix it by hand. :( > > >=20 > > > Fatal trap 12: page fault while in kernel mode > > > cpuid =3D 0; apic id =3D 00 > > > fault virtual address =3D 0x18 > > > fault code =3D supervisor read data, page not present > > > instruction pointer =3D 0x20:0xffffffff80933e07 > > > stack pointer =3D 0x28:0xffffff823025b660 > > > frame pointer =3D 0x28:0xffffff823025b6c0 > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > >=20 > > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > >=20 > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > current process =3D 12 (irq256: bce0) > > > trap number =3D 12 > > > panic: page fault > > >=20 > > > #6 0xffffffff80bb5e53 in calltrap () > > >=20 > > > at /usr/src/sys/amd64/amd64/exception.S:228 > > >=20 > > > #7 0xffffffff80933e07 in m_copym (m=3D0x0, off0=3D1500, len=3D1480, > > > wait=3D1) > > >=20 > > > at /usr/src/sys/kern/uipc_mbuf.c:542 > > >=20 > > > #8 0xffffffff809f8b76 in ip_fragment (ip=3D0xfffffe004b2f3980, > > > m_frag=3D0xffffff823025b7c8, mtu=3DVariable "mtu" is not available. ) > > >=20 > > > at /usr/src/sys/netinet/ip_output.c:822 > > >=20 > > > #9 0xffffffff809f948a in ip_output (m=3D0xfffffe004b2f3900, > > > opt=3DVariable "opt" is not available. ) > > >=20 > > > at /usr/src/sys/netinet/ip_output.c:654 > > >=20 > > > #10 0xffffffff809f59fa in ip_forward (m=3D0xfffffe004b2f3900, > > > srcrt=3DVariable "srcrt" is not available. ) > > >=20 > > > at /usr/src/sys/netinet/ip_input.c:1494 > > >=20 > > > #11 0xffffffff809f6dc6 in ip_input (m=3D0xfffffe004b2f3900) > > >=20 > > > at /usr/src/sys/netinet/ip_input.c:702 > >=20 > > I apologize for not having answered - no more required files... > > At that time it was not possible to fulfill your request ... > > Now I have gained a number of similar panic's and i ready to provide > > the results. > >=20 > > > Can you run kgdb again and do 'frame 8' followed by 'p *m_frag', > > > 'p m0', and 'p *m0'? > >=20 > > kgdb.log in attach >=20 > Looks like this attachment was lost unfortunately. Can you reply with > the output inline (and include the output from the other kgdb commands > below)? I sent a letter with an attached log of privately. kgdb.log again in attach >=20 > > > Can you also grab my gdb scripts at www.freebsd.org/~jhb/gdb/ and > > > run 'cd /path/to/scripts', 'source gdb6', 'mbuf m0' as well? > >=20 > > What kind of shell should I use for this? >=20 > Ah, those are meant to be run while you are in kgdb. >=20 (kgdb) source gdb6 Warning: /sys/amd64/compile/GENERIC: No such file or directory. (kgdb) mbuf m0 0xfffffe00255aa200: 60 bytes packet: 576 bytes received via bce0 0xfffffe0011a53c00: 516 bytes ext 0xfffffe0011a92000 0xfffffe0011bf1500: 0 bytes ext 0xfffffe0011c00800 (kgdb)=20 --MP_/QvrSkd_9U6t7dWNNEYJSCCL Content-Type: application/octet-stream; name=core.txt.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=core.txt.0 Z3cwMS5uZXZvc29mdC5sb2NhbCBkdW1wZWQgY29yZSAtIHNlZSAvdmFyL2NyYXNoL3ZtY29yZS4w CgpXZWQgRGVjIDE5IDE4OjM0OjU0IE1TSyAyMDEyCgpGcmVlQlNEIG5vbmFtZWhvc3QubG9jYWwg OS4xLVJFTEVBU0UgRnJlZUJTRCA5LjEtUkVMRUFTRSAjMCByMjQzODI1OiBUdWUgRGVjICA0IDA5 OjIzOjEwIFVUQyAyMDEyICAgICByb290QGZhcnJlbGwuY3NlLmJ1ZmZhbG8uZWR1Oi91c3Ivb2Jq L3Vzci9zcmMvc3lzL0dFTkVSSUMgIGFtZDY0CgpwYW5pYzogcGFnZSBmYXVsdAoKR05VIGdkYiA2 LjEuMSBbRnJlZUJTRF0KQ29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJ bmMuCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJs aWMgTGljZW5zZSwgYW5kIHlvdSBhcmUKd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5kL29yIGRpc3Ry aWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4KVHlwZSAic2hvdyBj b3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuClRoZXJlIGlzIGFic29sdXRlbHkgbm8gd2Fy cmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxzLgpUaGlzIEdE QiB3YXMgY29uZmlndXJlZCBhcyAiYW1kNjQtbWFyY2VsLWZyZWVic2QiLi4uCgpVbnJlYWQgcG9y dGlvbiBvZiB0aGUga2VybmVsIG1lc3NhZ2UgYnVmZmVyOgoKCkZhdGFsIHRyYXAgMTI6IHBhZ2Ug ZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKY3B1aWQgPSAzOyBhcGljIGlkID0gMDMKZmF1bHQg dmlydHVhbCBhZGRyZXNzCT0gMHgxOApmYXVsdCBjb2RlCQk9IHN1cGVydmlzb3IgcmVhZCBkYXRh LCBwYWdlIG5vdCBwcmVzZW50Cmluc3RydWN0aW9uIHBvaW50ZXIJPSAweDIwOjB4ZmZmZmZmZmY4 MDk0YmM0NwpzdGFjayBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZmODExODJjZDY1MApm cmFtZSBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZmODExODJjZDZiMApjb2RlIHNlZ21l bnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYgoJCQk9IERQTCAwLCBwcmVz IDEsIGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAxCnByb2Nlc3NvciBlZmxhZ3MJPSBpbnRlcnJ1cHQg ZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0gMApjdXJyZW50IHByb2Nlc3MJCT0gMTIgKGlycTI1Njog YmNlMCkKdHJhcCBudW1iZXIJCT0gMTIKcGFuaWM6IHBhZ2UgZmF1bHQKY3B1aWQgPSAzCktEQjog c3RhY2sgYmFja3RyYWNlOgojMCAweGZmZmZmZmZmODA5MjA4YTYgYXQga2RiX2JhY2t0cmFjZSsw eDY2CiMxIDB4ZmZmZmZmZmY4MDhlYThiZSBhdCBwYW5pYysweDFjZQojMiAweGZmZmZmZmZmODBi ZDgyNDAgYXQgdHJhcF9mYXRhbCsweDI5MAojMyAweGZmZmZmZmZmODBiZDg1N2QgYXQgdHJhcF9w ZmF1bHQrMHgxZWQKIzQgMHhmZmZmZmZmZjgwYmQ4YjllIGF0IHRyYXArMHgzY2UKIzUgMHhmZmZm ZmZmZjgwYmMzMTVmIGF0IGNhbGx0cmFwKzB4OAojNiAweGZmZmZmZmZmODBhMDY0ZDggYXQgaXBf ZnJhZ21lbnQrMHgxZTgKIzcgMHhmZmZmZmZmZjgwYTA2ZTE0IGF0IGlwX291dHB1dCsweDZmNAoj OCAweGZmZmZmZmZmODBhMDMyNDMgYXQgaXBfZm9yd2FyZCsweDMwMwojOSAweGZmZmZmZmZmODBh MDQ4ZGIgYXQgaXBfaW5wdXQrMHg1YWIKIzEwIDB4ZmZmZmZmZmY4MDlhZGFmYiBhdCBuZXRpc3Jf ZGlzcGF0Y2hfc3JjKzB4MjBiCiMxMSAweGZmZmZmZmZmODA5YTM1Y2QgYXQgZXRoZXJfZGVtdXgr MHgxNGQKIzEyIDB4ZmZmZmZmZmY4MDlhMzhhNCBhdCBldGhlcl9uaF9pbnB1dCsweDFmNAojMTMg MHhmZmZmZmZmZjgwOWFkYWZiIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgyMGIKIzE0IDB4ZmZm ZmZmZmY4MDQzOGZkNyBhdCBiY2VfaW50cisweDQ4NwojMTUgMHhmZmZmZmZmZjgwOGJlOGQ0IGF0 IGludHJfZXZlbnRfZXhlY3V0ZV9oYW5kbGVycysweDEwNAojMTYgMHhmZmZmZmZmZjgwOGMwMDc2 IGF0IGl0aHJlYWRfbG9vcCsweGE2CiMxNyAweGZmZmZmZmZmODA4YmI5ZWYgYXQgZm9ya19leGl0 KzB4MTFmClVwdGltZTogNTNtMThzCkR1bXBpbmcgMzM2IG91dCBvZiA0MDc0IE1COi4uNSUuLjE1 JS4uMjQlLi4zNCUuLjQzJS4uNTMlLi42MiUuLjcyJS4uODElLi45MSUKClJlYWRpbmcgc3ltYm9s cyBmcm9tIC9ib290L2tlcm5lbC9pcGZ3LmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qv a2VybmVsL2lwZncua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAv Ym9vdC9rZXJuZWwvaXBmdy5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvcGYu a28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvcGYua28uc3ltYm9scy4uLmRv bmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvcGYua28KUmVhZGluZyBz eW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2lmX2NhcnAua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJv bSAvYm9vdC9rZXJuZWwvaWZfY2FycC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5 bWJvbHMgZm9yIC9ib290L2tlcm5lbC9pZl9jYXJwLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9i b290L2tlcm5lbC9haW8ua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvYWlv LmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVs L2Fpby5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvYWNjZl9kYXRhLmtvLi4u UmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2FjY2ZfZGF0YS5rby5zeW1ib2xzLi4u ZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9hY2NmX2RhdGEua28K UmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2FjY2ZfZG5zLmtvLi4uUmVhZGluZyBz eW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2FjY2ZfZG5zLmtvLnN5bWJvbHMuLi5kb25lLgpkb25l LgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2FjY2ZfZG5zLmtvClJlYWRpbmcgc3lt Ym9scyBmcm9tIC9ib290L2tlcm5lbC9hY2NmX2h0dHAua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJv bSAvYm9vdC9rZXJuZWwvYWNjZl9odHRwLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQg c3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2FjY2ZfaHR0cC5rbwpSZWFkaW5nIHN5bWJvbHMgZnJv bSAvYm9vdC9rZXJuZWwvZHVtbXluZXQua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9r ZXJuZWwvZHVtbXluZXQua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZv ciAvYm9vdC9rZXJuZWwvZHVtbXluZXQua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2Vy bmVsL2NwdWN0bC5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9jcHVjdGwu a28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwv Y3B1Y3RsLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9pcGwua28uLi5SZWFk aW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvaXBsLmtvLnN5bWJvbHMuLi5kb25lLgpkb25l LgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2lwbC5rbwpSZWFkaW5nIHN5bWJvbHMg ZnJvbSAvYm9vdC9rZXJuZWwvbmdfc29ja2V0LmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jv b3Qva2VybmVsL25nX3NvY2tldC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJv bHMgZm9yIC9ib290L2tlcm5lbC9uZ19zb2NrZXQua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jv b3Qva2VybmVsL25ldGdyYXBoLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVs L25ldGdyYXBoLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jv b3Qva2VybmVsL25ldGdyYXBoLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9u Z19tcHBjLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL25nX21wcGMua28u c3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvbmdf bXBwYy5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvcmM0LmtvLi4uUmVhZGlu ZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL3JjNC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4K TG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9yYzQua28KIzAgIGRvYWR1bXAgKHRleHRk dW1wPVZhcmlhYmxlICJ0ZXh0ZHVtcCIgaXMgbm90IGF2YWlsYWJsZS4KKSBhdCBwY3B1Lmg6MjI0 CjIyNAlwY3B1Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuCglpbiBwY3B1LmgKKGtnZGIp ICMwICBkb2FkdW1wICh0ZXh0ZHVtcD1WYXJpYWJsZSAidGV4dGR1bXAiIGlzIG5vdCBhdmFpbGFi bGUuCikgYXQgcGNwdS5oOjIyNAojMSAgMHhmZmZmZmZmZjgwOGVhM2ExIGluIGtlcm5fcmVib290 IChob3d0bz0yNjApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NDQ4 CiMyICAweGZmZmZmZmZmODA4ZWE4OTcgaW4gcGFuaWMgKGZtdD0weDEgPEFkZHJlc3MgMHgxIG91 dCBvZiBib3VuZHM+KQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjYz NgojMyAgMHhmZmZmZmZmZjgwYmQ4MjQwIGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4YywgZXZhPVZh cmlhYmxlICJldmEiIGlzIG5vdCBhdmFpbGFibGUuCikKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2 NC9hbWQ2NC90cmFwLmM6ODU3CiM0ICAweGZmZmZmZmZmODBiZDg1N2QgaW4gdHJhcF9wZmF1bHQg KGZyYW1lPTB4ZmZmZmZmODExODJjZDVhMCwgdXNlcm1vZGU9MCkKICAgIGF0IC91c3Ivc3JjL3N5 cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NzczCiM1ICAweGZmZmZmZmZmODBiZDhiOWUgaW4gdHJhcCAo ZnJhbWU9MHhmZmZmZmY4MTE4MmNkNWEwKQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0 L3RyYXAuYzo0NTYKIzYgIDB4ZmZmZmZmZmY4MGJjMzE1ZiBpbiBjYWxsdHJhcCAoKQogICAgYXQg L3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlvbi5TOjIyOAojNyAgMHhmZmZmZmZmZjgw OTRiYzQ3IGluIG1fY29weW0gKG09MHgwLCBvZmYwPTE1MDAsIGxlbj0xNDgwLCB3YWl0PTEpCiAg ICBhdCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX21idWYuYzo1NDIKIzggIDB4ZmZmZmZmZmY4MGEw NjRkOCBpbiBpcF9mcmFnbWVudCAoaXA9MHhmZmZmZmUwMDI1NWFhMjgwLCAKICAgIG1fZnJhZz0w eGZmZmZmZjgxMTgyY2Q3YjgsIG10dT1WYXJpYWJsZSAibXR1IiBpcyBub3QgYXZhaWxhYmxlLgop IGF0IC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lwX291dHB1dC5jOjgyMgojOSAgMHhmZmZmZmZmZjgw YTA2ZTE0IGluIGlwX291dHB1dCAobT0weGZmZmZmZTAwMjU1YWEyMDAsIG9wdD1WYXJpYWJsZSAi b3B0IiBpcyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9pcF9v dXRwdXQuYzo2NTMKIzEwIDB4ZmZmZmZmZmY4MGEwMzI0MyBpbiBpcF9mb3J3YXJkIChtPTB4ZmZm ZmZlMDAyNTVhYTIwMCwgc3JjcnQ9VmFyaWFibGUgInNyY3J0IiBpcyBub3QgYXZhaWxhYmxlLgop CiAgICBhdCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9pcF9pbnB1dC5jOjE0OTQKIzExIDB4ZmZmZmZm ZmY4MGEwNDhkYiBpbiBpcF9pbnB1dCAobT0weGZmZmZmZTAwMjU1YWEyMDApCiAgICBhdCAvdXNy L3NyYy9zeXMvbmV0aW5ldC9pcF9pbnB1dC5jOjcwMgojMTIgMHhmZmZmZmZmZjgwOWFkYWZiIGlu IG5ldGlzcl9kaXNwYXRjaF9zcmMgKHByb3RvPTEsIHNvdXJjZT1WYXJpYWJsZSAic291cmNlIiBp cyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMvbmV0L25ldGlzci5jOjEwMTMK IzEzIDB4ZmZmZmZmZmY4MDlhMzVjZCBpbiBldGhlcl9kZW11eCAoaWZwPTB4ZmZmZmZlMDAwMjky MTgwMCwgCiAgICBtPTB4ZmZmZmZlMDAyNTVhYTIwMCkgYXQgL3Vzci9zcmMvc3lzL25ldC9pZl9l dGhlcnN1YnIuYzo5NDAKIzE0IDB4ZmZmZmZmZmY4MDlhMzhhNCBpbiBldGhlcl9uaF9pbnB1dCAo bT1WYXJpYWJsZSAibSIgaXMgbm90IGF2YWlsYWJsZS4KKQogICAgYXQgL3Vzci9zcmMvc3lzL25l dC9pZl9ldGhlcnN1YnIuYzo3NTkKIzE1IDB4ZmZmZmZmZmY4MDlhZGFmYiBpbiBuZXRpc3JfZGlz cGF0Y2hfc3JjIChwcm90bz05LCBzb3VyY2U9VmFyaWFibGUgInNvdXJjZSIgaXMgbm90IGF2YWls YWJsZS4KKQogICAgYXQgL3Vzci9zcmMvc3lzL25ldC9uZXRpc3IuYzoxMDEzCiMxNiAweGZmZmZm ZmZmODA0MzhmZDcgaW4gYmNlX2ludHIgKHhzYz1WYXJpYWJsZSAieHNjIiBpcyBub3QgYXZhaWxh YmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMvZGV2L2JjZS9pZl9iY2UuYzo2OTAzCiMxNyAweGZm ZmZmZmZmODA4YmU4ZDQgaW4gaW50cl9ldmVudF9leGVjdXRlX2hhbmRsZXJzIChwPVZhcmlhYmxl ICJwIiBpcyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2lu dHIuYzoxMjYyCiMxOCAweGZmZmZmZmZmODA4YzAwNzYgaW4gaXRocmVhZF9sb29wIChhcmc9MHhm ZmZmZmUwMDAyZDUyNjYwKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6MTI3 NQojMTkgMHhmZmZmZmZmZjgwOGJiOWVmIGluIGZvcmtfZXhpdCAoCiAgICBjYWxsb3V0PTB4ZmZm ZmZmZmY4MDhiZmZkMCA8aXRocmVhZF9sb29wPiwgYXJnPTB4ZmZmZmZlMDAwMmQ1MjY2MCwgCiAg ICBmcmFtZT0weGZmZmZmZjgxMTgyY2RjNDApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9y ay5jOjk5MgojMjAgMHhmZmZmZmZmZjgwYmMzNjhlIGluIGZvcmtfdHJhbXBvbGluZSAoKQogICAg YXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlvbi5TOjYwMgojMjEgMHgwMDAwMDAw MDAwMDAwMDAwIGluID8/ICgpCiMyMiAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzIzIDB4 MDAwMDAwMDAwMDAwMDAwMSBpbiA/PyAoKQojMjQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgp CiMyNSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzI2IDB4MDAwMDAwMDAwMDAwMDAwMCBp biA/PyAoKQojMjcgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMyOCAweDAwMDAwMDAwMDAw MDAwMDAgaW4gPz8gKCkKIzI5IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzAgMHgwMDAw MDAwMDAwMDAwMDAwIGluID8/ICgpCiMzMSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzMy IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ ICgpCiMzNCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzM1IDB4MDAwMDAwMDAwMDAwMDAw MCBpbiA/PyAoKQojMzYgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMzNyAweDAwMDAwMDAw MDAwMDAwMDAgaW4gPz8gKCkKIzM4IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzkgMHgw MDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiM0MCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkK IzQxIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojNDIgMHgwMDAwMDAwMDAwMDAwMDAwIGlu ID8/ICgpCiM0MyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzQ0IDB4MDAwMDAwMDAwMDAw MDAwMCBpbiA/PyAoKQojNDUgMHgwMDAwMDAwMDAwMDAwMDAzIGluID8/ICgpCiM0NiAweGZmZmZm ZmZmODEyNDI4ODAgaW4gdGRxX2NwdSAoKQojNDcgMHhmZmZmZmUwMDAyOTM0OGUwIGluID8/ICgp CiM0OCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzQ5IDB4ZmZmZmZmODExODJjZGIzMCBp biA/PyAoKQojNTAgMHhmZmZmZmY4MTE4MmNkYWQ4IGluID8/ICgpCiM1MSAweGZmZmZmZTAwMDI5 MTk0NzAgaW4gPz8gKCkKIzUyIDB4ZmZmZmZmZmY4MDkxMzUyZSBpbiBzY2hlZF9zd2l0Y2ggKHRk PTB4MCwgbmV3dGQ9MHhmZmZmZmUwMDAyZDUyNjYwLCAKICAgIGZsYWdzPVZhcmlhYmxlICJmbGFn cyIgaXMgbm90IGF2YWlsYWJsZS4KKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzox OTIxClByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQoo a2dkYikgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KcHMgLWF4bAoKICBVSUQgIFBJRCBQUElEIENQVSBQUkkg TkkgICBWU1ogUlNTIE1XQ0hBTiAgIFNUQVQgVFQgICAgICBUSU1FIENPTU1BTkQKICAgIDAgICAg MCAgICAwICAgMCAtOTIgIDAgICAgIDAgICAwIC0gICAgICAgIERMcyAgPz8gICAwOjE5LjYwIFtr ZXJuZWxdCiAgICAwICAgIDEgICAgMCAgIDAgIDI0ICAwICA2Mjc2ICAgMCB3YWl0ICAgICBETHMg ID8/ICAgMDowMC4wMSBbaW5pdF0KICAgIDAgICAgMiAgICAwICAgMCAtMTYgIDAgICAgIDAgICAw IGFpZnRoZCAgIERMICAgPz8gICAwOjAwLjAwIFthYWMwYWlmXQogICAgMCAgICAzICAgIDAgICAw IC0xNiAgMCAgICAgMCAgIDAgY3RsX3dvcmsgREwgICA/PyAgIDA6MDAuMDAgW2N0bF90aHJkXQog ICAgMCAgICA0ICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAgcGZ0bSAgICAgREwgICA/PyAgIDA6 MDAuMDMgW3BmcHVyZ2VdCiAgICAwICAgIDUgICAgMCAgIDAgLTE2ICAwICAgICAwICAgMCB3YWl0 aW5nXyBETCAgID8/ICAgMDowMC4wMCBbc2N0cF9pdGVyYXRvcl0KICAgIDAgICAgNiAgICAwICAg MCAtMTYgIDAgICAgIDAgICAwIGNjYl9zY2FuIERMICAgPz8gICAwOjAwLjAwIFt4cHRfdGhyZF0K ICAgIDAgICAgNyAgICAwICAgMCAtMTYgIDAgICAgIDAgICAwIHBzbGVlcCAgIERMICAgPz8gICAw OjAwLjAxIFtwYWdlZGFlbW9uXQogICAgMCAgICA4ICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAg cHNsZWVwICAgREwgICA/PyAgIDA6MDAuMDAgW3ZtZGFlbW9uXQogICAgMCAgICA5ICAgIDAgICAw IDE1NSAgMCAgICAgMCAgIDAgcGd6ZXJvICAgREwgICA/PyAgIDA6MDAuMDAgW3BhZ2V6ZXJvXQog ICAgMCAgIDEwICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAgYXVkaXRfd28gREwgICA/PyAgIDA6 MDAuMDAgW2F1ZGl0XQogICAgMCAgIDExICAgIDAgICAwIDE1NSAgMCAgICAgMCAgIDAgLSAgICAg ICAgUkwgICA/PyAgOTY6MzUuNTkgW2lkbGVdCiAgICAwICAgMTIgICAgMCAgIDAgLTg0ICAwICAg ICAwICAgMCAtICAgICAgICBXTCAgID8/ICAgMjo0NC42MSBbaW50cl0KICAgIDAgICAxMyAgICAw ICAgMCAgLTggIDAgICAgIDAgICAwIC0gICAgICAgIERMICAgPz8gICAwOjAwLjA4IFtnZW9tXQog ICAgMCAgIDE0ICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAgLSAgICAgICAgREwgICA/PyAgIDA6 MTAuMDIgW3lhcnJvd10KICAgIDAgICAxNSAgICAwICAgMCAtNjggIDAgICAgIDAgICAwIC0gICAg ICAgIERMICAgPz8gICAwOjAwLjEwIFt1c2JdCiAgICAwICAgMTYgICAgMCAgIDAgLTE2ICAwICAg ICAwICAgMCBwc2xlZXAgICBETCAgID8/ICAgMDowMC4wMiBbYnVmZGFlbW9uXQogICAgMCAgIDE3 ICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAgdmxydXd0ICAgREwgICA/PyAgIDA6MDAuMDMgW3Zu bHJ1XQogICAgMCAgIDE4ICAgIDAgICAwICAxNiAgMCAgICAgMCAgIDAgc3luY2VyICAgREwgICA/ PyAgIDA6MDAuMDYgW3N5bmNlcl0KICAgIDAgICAxOSAgICAwICAgMCAtMTYgIDAgICAgIDAgICAw IHNkZmx1c2ggIERMICAgPz8gICAwOjAwLjA1IFtzb2Z0ZGVwZmx1c2hdCiAgICAwICAxNjAgICAg MSAgIDAgIDUyICAwICA5OTIwICAgMCBwYXVzZSAgICBEcyAgID8/ICAgMDowMC4wMCBbYWRqa2Vy bnR6XQogICAgMCAxNTgxICAgIDEgICAwICAyMCAgMCAxMjA1MiAgIDAgc2VsZWN0ICAgRHMgICA/ PyAgIDA6MDAuMDIgW3N5c2xvZ2RdCiAgIDUzIDE2NjcgICAgMSAgIDAgIDUyICAwIDQ3Mzg0ICAg MCBrcXJlYWQgICBEcyAgID8/ICAgMDowMC4wNSBbbmFtZWRdCiAgICAwIDE3MzQgICAgMSAgIDAg IDUyICAwIDQxNTQ0ICAgMCBzZWxlY3QgICBEcyAgID8/ICAgMDowMC4wMyBbbXBkNV0KICAgIDAg MTc0MCAgICAwICAgMCAtMTYgIDAgICAgIDAgICAwIHNsZWVwICAgIERMICAgPz8gICAwOjAwLjAw IFtuZ19xdWV1ZV0KICAgIDAgMTc0MSAgICAxICAgMCAgMjAgIDAgNDU1MjAgICAwIHNlbGVjdCAg IERzICAgPz8gICAwOjAwLjEwIFtzbm1wdHJhcGRdCiAgICAwIDE3NDUgICAgMSAgIDAgIDIwICAw IDQzNDM2ICAgMCBzZWxlY3QgICBEICAgID8/ICAgMDowMi42MiBbc25tcGRdCiAgICAwIDE3NzQg ICAgMSAgIDAgIDUyICAwIDE3NDUyICAgMCBrcXJlYWQgICBEcyAgID8/ICAgMDowMC4wMCBbbnNj ZF0KICAgIDAgMTc3NyAgICAxICAgMCAgMjAgIDAgMjIxOTYgICAwIHNlbGVjdCAgIERzICAgPz8g ICAwOjAwLjIxIFtudHBkXQogICAgMCAxNzgwICAgIDEgICAwICAyMCAgMCAxMjA1MiAgIDAgc2Vs ZWN0ICAgRHMgICA/PyAgIDA6MDAuNDkgW3Bvd2VyZF0KICAgIDAgMTgwNCAgICAxICAgMCAgMjAg IDAgMjI3MjggICAwIHNlbGVjdCAgIERzICAgPz8gICAwOjAwLjAzIFtvcGVudnBuXQogICAgMCAx ODE2ICAgIDEgICAwICA1MiAgMCAzMTU1MiAgIDAgcGF1c2UgICAgRHMgICA/PyAgIDA6MDAuMDAg W25naW54XQo2NTUzNCAxODE3IDE4MTYgICAwICAyMCAgMCAzMTU1MiAgIDAga3FyZWFkICAgRCAg ICA/PyAgIDA6MDAuMDIgW25naW54XQo2NTUzNCAxODE4IDE4MTYgICAwICAyMCAgMCAzMTU1MiAg IDAga3FyZWFkICAgRCAgICA/PyAgIDA6MDAuMjEgW25naW54XQo2NTUzNCAxODI0ICAgIDEgICAw ICAyMCAgMCAxNDMxMiAgIDAgc2VsZWN0ICAgRHMgICA/PyAgIDA6MDUuMTggW2RhcmtzdGF0XQo2 NTUzNCAxODI1IDE4MjQgICAwICA1MiAgMCAxNDMxMiAgIDAgc2J3YWl0ICAgRHMgICA/PyAgIDA6 MDAuMDAgW2RhcmtzdGF0XQogICAgMCAxODI4ICAgIDEgICAwICAyMCAgMCA1NDMyOCAgIDAgdXdh aXQgICAgRHMgICA/PyAgIDA6MDAuMDEgW2JhY3VsYS1mZF0KICAgIDAgMTgzOSAgICAxICAgMCAg MjAgIDAgMjAyNTIgICAwIHNlbGVjdCAgIERzICAgPz8gICAwOjAwLjA4IFtzZW5kbWFpbF0KICAg MjUgMTg0MiAgICAxICAgMCAgMjAgIDAgMjAyNTIgICAwIHBhdXNlICAgIERzICAgPz8gICAwOjAw LjAwIFtzZW5kbWFpbF0KICAgIDAgMTg0NiAgICAxICAgMCAgMjAgIDAgMTQxMjggICAwIG5hbnNs cCAgIERzICAgPz8gICAwOjAwLjAyIFtjcm9uXQogICAgMCAxODk5ICAgIDEgICAwICA1MiAgMCAx NjIxMiAgIDAgc2VsZWN0ICAgRHMgICA/PyAgIDA6MDAuMDAgW2luZXRkXQogICAgMCAxOTE2ICAg IDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5 XQogICAgMCAxOTE3ICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAg IDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTE4ICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5 aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTE5ICAgIDEgICAwICA1MiAg MCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTIw ICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dl dHR5XQogICAgMCAxOTIxICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/ PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTIyICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAg dHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTIzICAgIDEgICAwICA1 MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAy MDExICAgIDEgICAwICAyMCAgMCA0Njc0NCAgIDAgc2VsZWN0ICAgRHMgICA/PyAgIDA6MDAuMDEg W3NzaGRdCiAgICAwIDIxMTMgICAgMSAgIDAgIDIwICAwIDEwMzc2ICAgMCBzZWxlY3QgICBEcyAg ID8/ICAgMDowMC4wMCBbZGV2ZF0KICAgIDAgMjE1NiAyMDExICAgMCAgMjAgIDAgNjc4ODQgICAw IHNlbGVjdCAgIERzICAgPz8gICAwOjAwLjAwIFtzc2hkXQogICAgMCAyMTU4IDIxNTYgICAwICAy MCAgMCAxNzUzMiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDEgW2NzaF0KCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQp2bXN0YXQgLXMKCiAyNTc5Mjg0MiBjcHUgY29udGV4dCBzd2l0Y2hlcwogMTAwNDU1 MjEgZGV2aWNlIGludGVycnVwdHMKICAzMjUwMjMwIHNvZnR3YXJlIGludGVycnVwdHMKICAgMTk4 OTUxIHRyYXBzCiAgIDU4MTM4MCBzeXN0ZW0gY2FsbHMKICAgICAgIDIwIGtlcm5lbCB0aHJlYWRz IGNyZWF0ZWQKICAgICAyMDk0ICBmb3JrKCkgY2FsbHMKICAgICAgIDUwIHZmb3JrKCkgY2FsbHMK ICAgICAgICAwIHJmb3JrKCkgY2FsbHMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZWlucwogICAg ICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdlZCBpbgogICAgICAgIDAgc3dhcCBwYWdlciBwYWdl b3V0cwogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdlZCBvdXQKICAgICAgODkyIHZub2Rl IHBhZ2VyIHBhZ2VpbnMKICAgICA3NjQxIHZub2RlIHBhZ2VyIHBhZ2VzIHBhZ2VkIGluCiAgICAg ICAgMCB2bm9kZSBwYWdlciBwYWdlb3V0cwogICAgICAgIDAgdm5vZGUgcGFnZXIgcGFnZXMgcGFn ZWQgb3V0CiAgICAgICAgMCBwYWdlIGRhZW1vbiB3YWtldXBzCiAgICAgICAgMCBwYWdlcyBleGFt aW5lZCBieSB0aGUgcGFnZSBkYWVtb24KICAgICAgNTM2IHBhZ2VzIHJlYWN0aXZhdGVkCiAgICA2 NTI1MiBjb3B5LW9uLXdyaXRlIGZhdWx0cwogICAgICAzOTYgY29weS1vbi13cml0ZSBvcHRpbWl6 ZWQgZmF1bHRzCiAgICA2ODM1NiB6ZXJvIGZpbGwgcGFnZXMgemVyb2VkCiAgICAgICAgMCB6ZXJv IGZpbGwgcGFnZXMgcHJlemVyb2VkCiAgICAgICAgMyBpbnRyYW5zaXQgYmxvY2tpbmcgcGFnZSBm YXVsdHMKICAgMjAyMTY2IHRvdGFsIFZNIGZhdWx0cyB0YWtlbgogICAgICAgIDAgcGFnZXMgYWZm ZWN0ZWQgYnkga2VybmVsIHRocmVhZCBjcmVhdGlvbgogIDEwNjE1MjIgcGFnZXMgYWZmZWN0ZWQg YnkgIGZvcmsoKQogICAgMjI3NTcgcGFnZXMgYWZmZWN0ZWQgYnkgdmZvcmsoKQogICAgICAgIDAg cGFnZXMgYWZmZWN0ZWQgYnkgcmZvcmsoKQogICAgICAgIDAgcGFnZXMgY2FjaGVkCiAgIDIwMDk3 NyBwYWdlcyBmcmVlZAogICAgICAgIDAgcGFnZXMgZnJlZWQgYnkgZGFlbW9uCiAgICAgICAgMCBw YWdlcyBmcmVlZCBieSBleGl0aW5nIHByb2Nlc3NlcwogICAgMTAwNDEgcGFnZXMgYWN0aXZlCiAg ICAgNjY0NCBwYWdlcyBpbmFjdGl2ZQogICAgICAgMTUgcGFnZXMgaW4gVk0gY2FjaGUKICAgIDQy MjI2IHBhZ2VzIHdpcmVkIGRvd24KICAgOTQ1NTg5IHBhZ2VzIGZyZWUKICAgICA0MDk2IGJ5dGVz IHBlciBwYWdlCiAgICA3ODU0NCB0b3RhbCBuYW1lIGxvb2t1cHMKICAgICAgICAgIGNhY2hlIGhp dHMgKDg4JSBwb3MgKyA1JSBuZWcpIHN5c3RlbSAwJSBwZXItZGlyZWN0b3J5CiAgICAgICAgICBk ZWxldGlvbnMgMCUsIGZhbHNlaGl0cyAwJSwgdG9vbG9uZyAwJQoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnZt c3RhdCAtbQoKICAgICAgICAgVHlwZSBJblVzZSBNZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6 ZShzKQpDQU0gZGV2IHF1ZXVlICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAxMjgKICBt ZF9zaWlfZGF0YSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxMSAgNTEyCiAgICAgIENBTSBY UFQgICAgMzEgICAgMTRLICAgICAgIC0gICAgICAgNzQgIDMyLDY0LDEyOCwxMDI0LDIwNDgKICAg ICAgIGlzYWRldiAgICAgOSAgICAgMksgICAgICAgLSAgICAgICAgOSAgMTI4CiAgICAgICBhYWNi dWYgICAyNDEgICAgNzJLICAgICAgIC0gICAgICAyNDEgIDY0LDEyOAogICAgIGFjcGlpbnRyICAg ICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NAogICAgICAgICBjZGV2ICAgICA4ICAgICAy SyAgICAgICAtICAgICAgICA4ICAyNTYKICAgICAgIGFjcGljYSAgMTM3NCAgIDE0N0sgICAgICAg LSAgICAzNzI2NiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICBz aWdpbyAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgNjQKICAgICBmaWxlZGVzYyAgICA2 MSAgICA1NksgICAgICAgLSAgICAgMjE5MiAgMTYsMzIsNjQsMTI4LDUxMiwxMDI0LDIwNDgsNDA5 NgogICAgICAgICBrZW52ICAgIDczICAgIDExSyAgICAgICAtICAgICAgIDc5ICAxNiwzMiw2NCwx MjgKICAgICAgIGtxdWV1ZSAgICAgOCAgICAxNUsgICAgICAgLSAgICAgICA1OSAgMjU2LDUxMiwy MDQ4CiAgICBwcm9jLWFyZ3MgICAgMzMgICAgIDNLICAgICAgIC0gICAgIDE1NDUgIDE2LDMyLDY0 LDEyOCwyNTYKICAgICAgICBoaG9vayAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4 CiAgICAgYWNwaXRhc2sgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIwNDgKICAgICAg aXRocmVhZCAgICA3NSAgICAxM0sgICAgICAgLSAgICAgICA3NSAgMzIsMTI4LDI1NgogICAgQ0FN IHF1ZXVlICAgIDExICAgICAxSyAgICAgICAtICAgICAgIDM5ICAxNiwzMgogICAgICAgS1RSQUNF ICAgMTAwICAgIDEzSyAgICAgICAtICAgICAgMTAwICAxMjgKICAgICAgIGxpbmtlciAgIDI4NyAg IDEyMksgICAgICAgLSAgICAgIDMzMSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQw OTYKICAgICAgICBsb2NrZiAgICAyOSAgICAgM0sgICAgICAgLSAgICAgICA3MyAgNjQsMTI4CiAg IGxvZ2luY2xhc3MgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgMjEgIDY0CiAgICAgICBpcDZu ZHAgICAgMTYgICAgIDJLICAgICAgIC0gICAgICAgMTkgIDY0LDEyOAogICAgICAgICB0ZW1wIDEx ODQ2ICA0MDE5SyAgICAgICAtICAgMTkyMDk5ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIw NDgsNDA5NgogICAgICAgZGV2YnVmIDI0MTAzIDY3NTY5SyAgICAgICAtICAgIDI0NDkxICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgbW9kdWxlICAgNDk2ICAgIDYy SyAgICAgICAtICAgICAgNDk2ICAxMjgKICAgICBtdHhfcG9vbCAgICAgMiAgICAxNksgICAgICAg LSAgICAgICAgMiAgCiAgICAgICBVU0JkZXYgICAgMjUgICAgIDRLICAgICAgIC0gICAgICAgMjUg IDY0LDEyOCw1MTIKICAgICAgICAgIFVTQiAgICAzOCAgIDEwOEsgICAgICAgLSAgICAgICAzOSAg MTYsMzIsNjQsMTI4LDI1NiwyMDQ4CiAgICAgcG1jaG9va3MgICAgIDEgICAgIDFLICAgICAgIC0g ICAgICAgIDEgIDEyOAogICAgICBzdWJwcm9jICAgMTQyICAgMjU3SyAgICAgICAtICAgICAyMjU1 ICA1MTIsNDA5NgogICAgICAgICBwcm9jICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAK ICAgICAgc2Vzc2lvbiAgICAzMSAgICAgNEsgICAgICAgLSAgICAgICA1OCAgMTI4CiAgICAgICAg IHBncnAgICAgMzEgICAgIDRLICAgICAgIC0gICAgICAgOTEgIDEyOAogICAgICAgICBjcmVkICAg IDQ2ICAgICA4SyAgICAgICAtICAgICA5MzEyICA2NCwyNTYKICAgICAgdWlkaW5mbyAgICAgNSAg ICAgM0sgICAgICAgLSAgICAgICAyNiAgMTI4LDIwNDgKICAgICAgIHBsaW1pdCAgICAxNSAgICAg NEsgICAgICAgLSAgICAgIDM5NyAgMjU2CiAgICAgIGF0YV9wY2kgICAgIDEgICAgIDFLICAgICAg IC0gICAgICAgIDEgIDY0CiAgICAgIHNjc2lfY2QgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAg MTAgIDE2CiAgICBzeXNjdGx0bXAgICAgIDAgICAgIDBLICAgICAgIC0gICAgICA0MTUgIDE2LDMy LDY0LDEyOCw0MDk2CiAgICBzeXNjdGxvaWQgIDQxNzEgICAyMTFLICAgICAgIC0gICAgIDQyNzUg IDE2LDMyLDY0LDEyOAogICAgICAgc3lzY3RsICAgICAwICAgICAwSyAgICAgICAtICAgICAyMjUx ICAxNiwzMiw2NAogICAgICB0aWRoYXNoICAgICAxICAgIDE2SyAgICAgICAtICAgICAgICAxICAK ICAgICAgY2FsbG91dCAgICAgMyAgMTUzNksgICAgICAgLSAgICAgICAgMyAgCiAgICAgICAgIHVt dHggICAzOTAgICAgNDlLICAgICAgIC0gICAgICAzOTAgIDEyOAogICAgIHAxMDAzLjFiICAgICAx ICAgICAxSyAgICAgICAtICAgICAgICAxICAxNgogICAgICAgICBTV0FQICAgICAyICAgNTQ5SyAg ICAgICAtICAgICAgICAyICA2NAogICAgICAgYnVzLXNjICAgIDkzICAgNjMxSyAgICAgICAtICAg ICA0NjU3ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgICAgYnVz ICAxMjQ0ICAgMTA0SyAgICAgICAtICAgICA3MjQ4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0 CiAgICAgIGRldnN0YXQgICAgIDYgICAgMTNLICAgICAgIC0gICAgICAgIDYgIDMyLDQwOTYKIGV2 ZW50aGFuZGxlciAgICA5NCAgICAgOEsgICAgICAgLSAgICAgICA5NCAgNjQsMTI4CiAgICAgIGFj cGlzZW0gICAgMTYgICAgIDJLICAgICAgIC0gICAgICAgMTYgIDEyOAogICAgICAgICBrb2JqICAg MzI5ICAxMzE2SyAgICAgICAtICAgICAgNDg3ICA0MDk2CiAgICAgIENBTSBTSU0gICAgIDMgICAg IDFLICAgICAgIC0gICAgICAgIDMgIDI1NgogICAgICBQZXItY3B1ICAgICAxICAgICAxSyAgICAg ICAtICAgICAgICAxICAzMgogICBDQU0gcGVyaXBoICAgICA0ICAgICAxSyAgICAgICAtICAgICAg IDE4ICAxNiwzMiw2NCwxMjgsMjU2CiAgICAgICAgIHJtYW4gICAyMDggICAgMjJLICAgICAgIC0g ICAgICA1NjYgIDE2LDMyLDEyOAogICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAgICAtICAg ICAgNjk4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICBlbnRyb3B5 ICAxMDI0ICAgIDY0SyAgICAgICAtICAgICAxMDI0ICA2NAogICAgICAgY3RsbWVtICA1MDYyIDEw MTEzSyAgICAgICAtICAgICA1MDYyICAxMjgsMjA0OAogICAgICAgIHN0YWNrICAgICAwICAgICAw SyAgICAgICAtICAgICAgICAyICAyNTYKICAgIHRhc2txdWV1ZSAgICAxOSAgICAgMksgICAgICAg LSAgICAgICAxOSAgMTYsMzIsMTI4CiAgICAgICBVbml0bm8gICAgMTUgICAgIDFLICAgICAgIC0g ICAgICA1MzMgIDMyLDY0CiAgICAgICAgICBpb3YgICAgIDAgICAgIDBLICAgICAgIC0gICAgIDEy NTAgIDE2LDY0LDEyOCwyNTYsNTEyCiAgICAgICBzZWxlY3QgICAgMzIgICAgIDRLICAgICAgIC0g ICAgICAgMzIgIDEyOAogICAgIGlvY3Rsb3BzICAgICAwICAgICAwSyAgICAgICAtICAgIDI3MTk4 ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgICAgICBtc2cgICAgIDQgICAgMzBLICAg ICAgIC0gICAgICAgIDQgIDIwNDgsNDA5NgogICAgICAgICAgc2VtICAgICA0ICAgMTA2SyAgICAg ICAtICAgICAgICA0ICAyMDQ4LDQwOTYKICAgICAgICAgIHNobSAgICAgMSAgICAyMEsgICAgICAg LSAgICAgICAgMSAgCiAgICAgICAgICB0dHkgICAgMjAgICAgMjBLICAgICAgIC0gICAgICAgMjYg IDEwMjQsMjA0OAogICAgICAgICAgcHRzICAgICAxICAgICAxSyAgICAgICAtICAgICAgICA1ICAy NTYKICAgICAgICAgYWNjZiAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgNjQKICAgICBt YnVmX3RhZyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgMzA5MSAgMzIKICAgICAgICBzaG1mZCAg ICAgMSAgICAgOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgICAgICBwY2IgICAgMzYgICAxNThL ICAgICAgIC0gICAgICAxMzggIDE2LDMyLDY0LDEyOCwxMDI0LDIwNDgsNDA5NgogICAgICAgc29u YW1lICAgICA2ICAgICAxSyAgICAgICAtICAgICAxNjU4ICAxNiwzMiwxMjgKICAgICB2ZnNjYWNo ZSAgICAgMSAgMjA0OEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgdmZzX2hhc2ggICAgIDEgIDEw MjRLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgREVWRlMxICAgMTAwICAgIDUwSyAgICAgICAt ICAgICAgMTExICA1MTIKICAgICAgIHZub2RlcyAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAg NCAgNjQsMjU2CiAgICAgICBERVZGUzMgICAyMzMgICAgNTlLICAgICAgIC0gICAgICAyNTQgIDI1 NgogICAgICAgIG1vdW50ICAgIDI5ICAgICAySyAgICAgICAtICAgICAgMTMyICAxNiwzMiw2NCwx MjgsMjU2CiAgdm5vZGVtYXJrZXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAzMTYgIDUxMgog ICAgICAgICAgQlBGICAgIDE3ICAxMDI3SyAgICAgICAtICAgICAgIDIxICAxNiwxMjgsNTEyCiAg ZXRoZXJfbXVsdGkgICAgNzMgICAgIDRLICAgICAgIC0gICAgICAgODQgIDE2LDMyLDY0CiAgICAg ICBpZmFkZHIgICAxMzQgICAgMzRLICAgICAgIC0gICAgICAxMzQgIDMyLDY0LDEyOCwyNTYsNTEy LDIwNDgsNDA5NgogICAgICAgIGlmbmV0ICAgIDEzICAgIDI1SyAgICAgICAtICAgICAgIDEzICAx MjgsMjA0OAogICAgICAgREVWRlMyICAgIDk4ICAgICAySyAgICAgICAtICAgICAgIDk4ICAxNgog ICAgICAgIGNsb25lICAgICA3ICAgIDI4SyAgICAgICAtICAgICAgICA3ICA0MDk2CiAgICAgICBh cnBjb20gICAgIDYgICAgIDFLICAgICAgIC0gICAgICAgIDYgIDE2CiAgICAgIGxsdGFibGUgICAg NzUgICAgMjVLICAgICAgIC0gICAgICAgODAgIDI1Niw1MTIKICAgICAgICAgIHR1biAgICAgMSAg ICAgMUsgICAgICAgLSAgICAgICAgMSAgMjU2CiAgICAgICAgIHZsYW4gICAgIDUgICAgIDFLICAg ICAgIC0gICAgICAgIDUgIDY0LDEyOAogICBERVZGU19SVUxFICAgIDU1ICAgIDI2SyAgICAgICAt ICAgICAgIDU1ICA2NCw1MTIKICAgICAgICBERVZGUyAgICAzNCAgICAgMUsgICAgICAgLSAgICAg ICAzNyAgMTYsMTI4CiAgICAgICBERVZGU1AgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDIg IDY0CiAgICAgcm91dGV0YmwgICAgNjEgICAgIDhLICAgICAgIC0gICAgMTUxOTQgIDMyLDY0LDEy OCwyNTYsNTEyCiAgICAgICAgIGlnbXAgICAgMTIgICAgIDNLICAgICAgIC0gICAgICAgMTIgIDI1 NgogICAgIGluX211bHRpICAgICA1ICAgICAySyAgICAgICAtICAgICAgICA1ICAyNTYKICAgIHNj dHBfaXRlciAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgNyAgMjU2CiAgICAgc2N0cF9pZm4g ICAgIDUgICAgIDFLICAgICAgIC0gICAgICAgIDUgIDEyOAogICAgIHNjdHBfaWZhICAgICA5ICAg ICAySyAgICAgICAtICAgICAgICA5ICAxMjgKICAgICBzY3RwX3ZyZiAgICAgMSAgICAgMUsgICAg ICAgLSAgICAgICAgMSAgNjQKICAgIHNjdHBfYV9pdCAgICAgMCAgICAgMEsgICAgICAgLSAgICAg ICAgNyAgMTYKICAgIGhvc3RjYWNoZSAgICAgMSAgICAyOEsgICAgICAgLSAgICAgICAgMSAgCiAg ICAgc3luY2FjaGUgICAgIDEgICAgOTZLICAgICAgIC0gICAgICAgIDEgIAogICAgaW42X211bHRp ICAgIDM2ICAgICA1SyAgICAgICAtICAgICAgIDM2ICAzMiwyNTYKICAgICAgICAgIG1sZCAgICAx MiAgICAgMksgICAgICAgLSAgICAgICAxMiAgMTI4CiAgICAgICAgICBycGMgICAgIDIgICAgIDFL ICAgICAgIC0gICAgICAgIDIgIDI1NgphdWRpdF9ldmNsYXNzICAgMTc5ICAgICA2SyAgICAgICAt ICAgICAgMjE4ICAzMgogICAgICBqYmxvY2tzICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAy ICAxMjgsMjU2CiAgICAgc2F2ZWRpbm8gICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMzggIDI1 NgogICAgICAgIHNiZGVwICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDM4ICA2NAogICAgICBq c2VnZGVwICAgICAwICAgICAwSyAgICAgICAtICAgICAgNDYxICA2NAogICAgICAgICBqc2VnICAg ICAwICAgICAwSyAgICAgICAtICAgICAgIDU2ICAxMjgKICAgIGpmcmVlZnJhZyAgICAgMCAgICAg MEsgICAgICAgLSAgICAgICAgNSAgMTI4CiAgICAgIGpuZXdibGsgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAxNTYgIDEyOAogICAgICBqcmVtcmVmICAgICAwICAgICAwSyAgICAgICAtICAgICAg MTQwICAxMjgKICAgICAgamFkZHJlZiAgICAgMCAgICAgMEsgICAgICAgLSAgICAgIDE2MCAgMTI4 CiAgICAgZnJlZXdvcmsgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAxMjEgIDY0LDEyOAogICAg bmV3ZGlyYmxrICAgICAwICAgICAwSyAgICAgICAtICAgICAgICA3ICA2NAogICAgICAgZGlycmVt ICAgICAwICAgICAwSyAgICAgICAtICAgICAgMTM2ICAxMjgKICAgICAgICBta2RpciAgICAgMCAg ICAgMEsgICAgICAgLSAgICAgICAxNCAgMTI4CiAgICAgICBkaXJhZGQgICAgIDAgICAgIDBLICAg ICAgIC0gICAgICAxNDYgIDEyOAogICAgIGZyZWVmaWxlICAgICAwICAgICAwSyAgICAgICAtICAg ICAgIDkxICA2NAogICAgIGZyZWVibGtzICAgICAwICAgICAwSyAgICAgICAtICAgICAgMTE3ICAx MjgKICAgICBmcmVlZnJhZyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgNSAgMTI4CiAgICAg ICBuZXdibGsgICAgIDEgICAxMjhLICAgICAgIC0gICAgICAxNTcgIDI1NgogICAgYm1zYWZlbWFw ICAgICAxICAgICA4SyAgICAgICAtICAgICAgMTMxICAyNTYKICAgICBpbm9kZWRlcCAgICAgMiAg MTAyNUsgICAgICAgLSAgICAgIDI1MiAgNTEyCiAgICAgIHBhZ2VkZXAgICAgIDEgICAxMjhLICAg ICAgIC0gICAgICAgMzYgIDI1NgogIHVmc19kaXJoYXNoICAgIDM5ICAgICA4SyAgICAgICAtICAg ICAgIDM5ICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgdWZzX21vdW50ICAgICAzICAgIDM3SyAg ICAgICAtICAgICAgICA0ICA1MTIsNDA5NgogICAgdm1fcGdkYXRhICAgICAyICAgMTI5SyAgICAg ICAtICAgICAgICAyICAxMjgKICAgICAgbWVtZGVzYyAgICAgMSAgICAgNEsgICAgICAgLSAgICAg ICAgMSAgNDA5NgogICAgIGF0a2JkZGV2ICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICA2 NAogICAgcGZzX25vZGVzICAgIDIxICAgICA2SyAgICAgICAtICAgICAgIDIxICAyNTYKICAgICAg IGN0bGJsayAgIDIwMCAgMTYwMEsgICAgICAgLSAgICAgIDIwMCAgCiAgICAgICAgIEdFT00gICAg NTEgICAgMTFLICAgICAgIC0gICAgICA0NzkgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0 OAogICAgICByYW1kaXNrICAgICAxICA0MDk2SyAgICAgICAtICAgICAgICAxICAKICAgICAgYWNw aWRldiAgICAyOCAgICAgMksgICAgICAgLSAgICAgICAyOCAgNjQKICAgICAgY3RscG9vbCAgIDUz MiAgIDE0MksgICAgICAgLSAgICAgIDUzMiAgMzIsNTEyCiAgICAgICBrYmRtdXggICAgIDcgICAg MThLICAgICAgIC0gICAgICAgIDcgIDE2LDUxMiwxMDI0LDIwNDgKICAgICAgIGFwbWRldiAgICAg MSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4CiAgIG1hZHRfdGFibGUgICAgIDAgICAgIDBL ICAgICAgIC0gICAgICAgIDEgIDQwOTYKICAgICAgIGZlZWRlciAgICAgNyAgICAgMUsgICAgICAg LSAgICAgICAgNyAgMzIKICAgICBwY2lfbGluayAgICAxMyAgICAgMksgICAgICAgLSAgICAgICAx MyAgMTYsMTI4CiAgICByYWlkX2RhdGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNzIgIDMy LDEyOCwyNTYKICAgICAgaW9fYXBpYyAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0 OAogICAgICAgICAgTUNBICAgICA2ICAgICAxSyAgICAgICAtICAgICAgICA2ICAxMjgKICAgICAg ICAgIG1zaSAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4CiAgICAgbmV4dXNkZXYg ICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDE2Cm1kX252aWRpYV9kYXRhICAgICAwICAg ICAwSyAgICAgICAtICAgICAgIDExICA1MTIKICBJcEZ3L0lwQWNjdCAgICAgOSAgICAgM0sgICAg ICAgLSAgICAgICAxMyAgMTYsMzIsNjQsMTI4LDEwMjQKICAgICBpcGZ3X3RibCAgICAxNCAgICAg NEsgICAgICAgLSAgICAgICAxNCAgMjU2CiAgICAgICAgIENBUlAgICAgIDQgICAgIDJLICAgICAg IC0gICAgICAgIDQgIDY0LDI1NiwxMDI0CiAgICAgZHVtbXluZXQgICAgIDMgICAgIDNLICAgICAg IC0gICAgICAgIDMgIDUxMiwxMDI0CiAgICAgICBjcHVjdGwgICAgIDEgICAgIDFLICAgICAgIC0g ICAgICAgIDEgIDMyCiBuZXRncmFwaF9tc2cgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDUg IDY0LDEyOCwyNTYKbmV0Z3JhcGhfbm9kZSAgICAgNSAgICAgMUsgICAgICAgLSAgICAgICAgNyAg MTI4LDI1NgpuZXRncmFwaF9ob29rICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAyICAxMjgK bmV0Z3JhcGhfc29jayAgICAgNiAgICAgMUsgICAgICAgLSAgICAgICAgOSAgMzIsMTI4Cm5ldGdy YXBoX3BhdGggICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDQgIDE2Cm5ldGdyYXBoX21wcGMg ICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDEgIDEwMjQKCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0 YXQgLXoKCklURU0gICAgICAgICAgICAgICAgICAgU0laRSAgTElNSVQgICAgIFVTRUQgICAgIEZS RUUgICAgICBSRVEgRkFJTCBTTEVFUAoKVU1BIEtlZ3M6ICAgICAgICAgICAgICAgMjA4LCAgICAg IDAsICAgICAxMTIsICAgICAgIDcsICAgICAxMTIsICAgMCwgICAwClVNQSBab25lczogICAgICAg ICAgICAgIDg5NiwgICAgICAwLCAgICAgMTEyLCAgICAgICAwLCAgICAgMTEyLCAgIDAsICAgMApV TUEgU2xhYnM6ICAgICAgICAgICAgICA1NjgsICAgICAgMCwgICAgMzk5NSwgICAgICAgMiwgICAg NTc4NCwgICAwLCAgIDAKVU1BIFJDbnRTbGFiczogICAgICAgICAgNTY4LCAgICAgIDAsICAgIDI1 MDAsICAgICAgIDYsICAgIDI1MDAsICAgMCwgICAwClVNQSBIYXNoOiAgICAgICAgICAgICAgIDI1 NiwgICAgICAwLCAgICAgICAzLCAgICAgIDEyLCAgICAgICAzLCAgIDAsICAgMAoxNiBCdWNrZXQ6 ICAgICAgICAgICAgICAxNTIsICAgICAgMCwgICAgIDExOCwgICAgICAgNywgICAgIDExOCwgICAw LCAgIDAKMzIgQnVja2V0OiAgICAgICAgICAgICAgMjgwLCAgICAgIDAsICAgICAxMDEsICAgICAg MTEsICAgICAxMDEsICAgMSwgICAwCjY0IEJ1Y2tldDogICAgICAgICAgICAgIDUzNiwgICAgICAw LCAgICAgIDgyLCAgICAgICAyLCAgICAgIDgyLCAgNTcsICAgMAoxMjggQnVja2V0OiAgICAgICAg ICAgIDEwNDgsICAgICAgMCwgICAgIDE2NywgICAgICAgMSwgICAgIDE2NywgNjI3LCAgIDAKVk0g T0JKRUNUOiAgICAgICAgICAgICAgMjMyLCAgICAgIDAsICAgIDE1MzQsICAgICAzODYsICAgMjg3 MDEsICAgMCwgICAwCk1BUDogICAgICAgICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgICAgICA3 LCAgICAgIDI1LCAgICAgICA3LCAgIDAsICAgMApLTUFQIEVOVFJZOiAgICAgICAgICAgICAxMjAs IDE1MDI1NywgICAgICA0NywgICAgIDQ4MCwgICAxNTkxNCwgICAwLCAgIDAKTUFQIEVOVFJZOiAg ICAgICAgICAgICAgMTIwLCAgICAgIDAsICAgIDEwMzIsICAgICA3MDQsICAgODEwNzcsICAgMCwg ICAwCmZha2VwZzogICAgICAgICAgICAgICAgIDEyMCwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMAptdF96b25lOiAgICAgICAgICAgICAgIDQxMTIsICAgICAgMCwg ICAgIDM0MiwgICAgICAgMSwgICAgIDM0MiwgICAwLCAgIDAKMTY6ICAgICAgICAgICAgICAgICAg ICAgIDE2LCAgICAgIDAsICAgIDIwNTksICAgICA0NjEsICAgMzE5ODEsICAgMCwgICAwCjMyOiAg ICAgICAgICAgICAgICAgICAgICAzMiwgICAgICAwLCAgICAyNDg5LCAgICAgNjQyLCAgIDIwODEw LCAgIDAsICAgMAo2NDogICAgICAgICAgICAgICAgICAgICAgNjQsICAgICAgMCwgICAxNzM4Nywg ICAgIDgxMywgICA3NzY2NywgICAwLCAgIDAKMTI4OiAgICAgICAgICAgICAgICAgICAgMTI4LCAg ICAgIDAsICAgIDY1MjcsICAgICA0MDQsICAgODE0MDgsICAgMCwgICAwCjI1NjogICAgICAgICAg ICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgNjY3LCAgICAgMTI4LCAgIDIyMjcwLCAgIDAsICAg MAo1MTI6ICAgICAgICAgICAgICAgICAgICA1MTIsICAgICAgMCwgICAgNzY0MCwgICAgMTMzNCwg ICA0Mzg1OCwgICAwLCAgIDAKMTAyNDogICAgICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAg ICAgNDMsICAgICAxOTMsICAgMTE3NTIsICAgMCwgICAwCjIwNDg6ICAgICAgICAgICAgICAgICAg MjA0OCwgICAgICAwLCAgICA1MTA3LCAgICAgNDAzLCAgIDQxMTYxLCAgIDAsICAgMAo0MDk2OiAg ICAgICAgICAgICAgICAgIDQwOTYsICAgICAgMCwgICAgIDQyMSwgICAgICA4NSwgICAgODcyNSwg ICAwLCAgIDAKRmlsZXM6ICAgICAgICAgICAgICAgICAgIDgwLCAgICAgIDAsICAgICAxNDQsICAg ICAyMTYsICAgMjM5MzksICAgMCwgICAwClRVUk5TVElMRTogICAgICAgICAgICAgIDEzNiwgICAg ICAwLCAgICAgMTk2LCAgICAgIDY0LCAgICAgMTk2LCAgIDAsICAgMAp1bXR4IHBpOiAgICAgICAg ICAgICAgICAgOTYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAK TUFDIGxhYmVsczogICAgICAgICAgICAgIDQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwClBST0M6ICAgICAgICAgICAgICAgICAgMTE4NCwgICAgICAwLCAgICAg IDUyLCAgICAgIDM1LCAgICAyMTY0LCAgIDAsICAgMApUSFJFQUQ6ICAgICAgICAgICAgICAgIDEx MjgsICAgICAgMCwgICAgIDE1MCwgICAgICA0NSwgICAgIDE1MSwgICAwLCAgIDAKU0xFRVBRVUVV RTogICAgICAgICAgICAgIDgwLCAgICAgIDAsICAgICAxOTYsICAgICAgMzYsICAgICAxOTYsICAg MCwgICAwClZNU1BBQ0U6ICAgICAgICAgICAgICAgIDM5MiwgICAgICAwLCAgICAgIDMzLCAgICAg IDg3LCAgICAyMTQ2LCAgIDAsICAgMApjcHVzZXQ6ICAgICAgICAgICAgICAgICAgNzIsICAgICAg MCwgICAgICA3MCwgICAgICA4MCwgICAgICA3MCwgICAwLCAgIDAKYXVkaXRfcmVjb3JkOiAgICAg ICAgICAgOTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCm1i dWZfcGFja2V0OiAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICA0MDgyLCAgICAgNzkzLCAyNjE3 NTk1LCAgIDAsICAgMAptYnVmOiAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgMTAy NSwgICAgIDkwNiwgOTMxNTkzMywgICAwLCAgIDAKbWJ1Zl9jbHVzdGVyOiAgICAgICAgICAyMDQ4 LCAgNjU1MzYsICAgIDQ4NjQsICAgICAgIDYsICAgIDQ4NjQsICAgMCwgICAwCm1idWZfanVtYm9f cGFnZTogICAgICAgNDA5NiwgIDEyODAwLCAgICAgICAwLCAgICAgIDY1LCAgICAgMTcwLCAgIDAs ICAgMAptYnVmX2p1bWJvXzlrOiAgICAgICAgIDkyMTYsICAxOTIwMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKbWJ1Zl9qdW1ib18xNms6ICAgICAgIDE2Mzg0LCAgMTI4MDAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCm1idWZfZXh0X3JlZmNudDogICAg ICAgICAgNCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApnX2Jp bzogICAgICAgICAgICAgICAgICAyMzIsICAgICAgMCwgICAgICAgMCwgICAgIDI3MiwgICAgOTc0 NiwgICAwLCAgIDAKdHR5aW5xOiAgICAgICAgICAgICAgICAgMTYwLCAgICAgIDAsICAgICAxODAs ICAgICAyNTIsICAgICA1NTUsICAgMCwgICAwCnR0eW91dHE6ICAgICAgICAgICAgICAgIDI1Niwg ICAgICAwLCAgICAgIDk1LCAgICAgMTMwLCAgICAgMjkxLCAgIDAsICAgMAphdGFfcmVxdWVzdDog ICAgICAgICAgICAzMjgsICAgICAgMCwgICAgICAgMCwgICAgICAzNiwgICAgICAzMiwgICAwLCAg IDAKYXRhX2NvbXBvc2l0ZTogICAgICAgICAgMzM2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwClZOT0RFOiAgICAgICAgICAgICAgICAgIDQ4MCwgICAgICAwLCAg ICAzNjIwLCAgICAgIDM2LCAgICAzNzIyLCAgIDAsICAgMApWTk9ERVBPTEw6ICAgICAgICAgICAg ICAxMTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKTkFNRUk6 ICAgICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAgICAgIDAsICAgICAgNDgsICAgMzMwNjIs ICAgMCwgICAwClMgVkZTIENhY2hlOiAgICAgICAgICAgIDEwOCwgICAgICAwLCAgICAzNjc1LCAg ICAgIDg3LCAgICA0ODI1LCAgIDAsICAgMApTVFMgVkZTIENhY2hlOiAgICAgICAgICAxNDgsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKTCBWRlMgQ2FjaGU6ICAg ICAgICAgICAgMzI4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw CkxUUyBWRlMgQ2FjaGU6ICAgICAgICAgIDM2OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMApESVJIQVNIOiAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAg ICA2NywgICAgICAyOSwgICAgICA2NywgICAwLCAgIDAKTkNMTk9ERTogICAgICAgICAgICAgICAg NTY4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBpcGU6ICAg ICAgICAgICAgICAgICAgIDcyOCwgICAgICAwLCAgICAgICA5LCAgICAgIDU2LCAgICAxNDI5LCAg IDAsICAgMApNb3VudHBvaW50czogICAgICAgICAgICA3OTIsICAgICAgMCwgICAgICAgMywgICAg ICAxMiwgICAgICAgMywgICAwLCAgIDAKQUlPOiAgICAgICAgICAgICAgICAgICAgMjA4LCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCkFJT1A6ICAgICAgICAgICAg ICAgICAgICAzMiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApB SU9DQjogICAgICAgICAgICAgICAgICA0ODAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDAKQUlPTDogICAgICAgICAgICAgICAgICAgMTI4LCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCkFJT0xJTzogICAgICAgICAgICAgICAgIDI3 MiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAprc2lnaW5mbzog ICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAgICA3NiwgICAgIDk4MCwgICAgIDI3NiwgICAw LCAgIDAKaXRpbWVyOiAgICAgICAgICAgICAgICAgMzQ0LCAgICAgIDAsICAgICAgIDEsICAgICAg MzIsICAgICAgIDIsICAgMCwgICAwCnBmc3JjdHJwbDogICAgICAgICAgICAgIDE1MiwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZnJ1bGVwbDogICAgICAgICAg ICAgICA5MzYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZz dGF0ZXBsOiAgICAgICAgICAgICAgMjg4LCAgMTAwMTAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCnBmc3RhdGVrZXlwbDogICAgICAgICAgIDI4OCwgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZnN0YXRlaXRlbXBsOiAgICAgICAgICAyODgs ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZhbHRxcGw6ICAg ICAgICAgICAgICAgMjQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCnBmcG9vbGFkZHJwbDogICAgICAgICAgICA4OCwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMApwZnJrdGFibGU6ICAgICAgICAgICAgIDEyOTYsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZya2VudHJ5OiAgICAgICAgICAg ICAgMTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmcmtj b3VudGVyczogICAgICAgICAgICA2NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMApwZmZyZW50OiAgICAgICAgICAgICAgICAgMzIsICAgNTA1MCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZmcmFnOiAgICAgICAgICAgICAgICAgIDgwLCAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmZnJjYWNoZTogICAg ICAgICAgICAgICA4MCwgIDEwMDM1LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MApwZmZyY2VudDogICAgICAgICAgICAgICAgMjQsICA1MDAyMiwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKcGZzdGF0ZXNjcnViOiAgICAgICAgICAgIDQwLCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmaWFkZHJwbDogICAgICAgICAgICAg IDEyMCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZm9zcGZl bjogICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKcGZvc2ZwOiAgICAgICAgICAgICAgICAgIDQwLCAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwCktOT1RFOiAgICAgICAgICAgICAgICAgIDEyOCwgICAg ICAwLCAgICAgIDIxLCAgICAgMTI0LCAgICA2NTYzLCAgIDAsICAgMApzb2NrZXQ6ICAgICAgICAg ICAgICAgICA2ODAsIDIwNDgwNCwgICAgICA1NywgICAgICA3NSwgICAxMzc3NiwgICAwLCAgIDAK aXBxOiAgICAgICAgICAgICAgICAgICAgIDU2LCAgIDIwNzksICAgICAgIDEsICAgICAxMjUsICAg ICAgIDIsICAgMCwgICAwCnVkcF9pbnBjYjogICAgICAgICAgICAgIDM5MiwgMjA0ODAwLCAgICAg IDE1LCAgICAgIDg1LCAgIDEzMzA0LCAgIDAsICAgMAp1ZHBjYjogICAgICAgICAgICAgICAgICAg MTYsIDIwNDk2MCwgICAgICAxNSwgICAgIDY1NywgICAxMzMwNCwgICAwLCAgIDAKdGNwX2lucGNi OiAgICAgICAgICAgICAgMzkyLCAyMDQ4MDAsICAgICAgMTUsICAgICAgNTUsICAgICAgNzIsICAg MCwgICAwCnRjcGNiOiAgICAgICAgICAgICAgICAgIDk3NiwgMjA0ODAwLCAgICAgIDE1LCAgICAg IDMzLCAgICAgIDcyLCAgIDAsICAgMAp0Y3B0dzogICAgICAgICAgICAgICAgICAgNzIsICA0MTAw MCwgICAgICAgMCwgICAgIDEwMCwgICAgICAzNCwgICAwLCAgIDAKc3luY2FjaGU6ICAgICAgICAg ICAgICAgMTUyLCAgMTUzNzUsICAgICAgIDAsICAgICAgNzUsICAgICAgMzgsICAgMCwgICAwCmhv c3RjYWNoZTogICAgICAgICAgICAgIDEzNiwgIDE1MzcyLCAgICAgICAxLCAgICAgIDU1LCAgICAg ICAxLCAgIDAsICAgMAp0Y3ByZWFzczogICAgICAgICAgICAgICAgNDAsICAgNDExNiwgICAgICAg MCwgICAgIDE2OCwgICAgICAgOCwgICAwLCAgIDAKc2Fja2hvbGU6ICAgICAgICAgICAgICAgIDMy LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfZXA6ICAg ICAgICAgICAgICAgMTM3NiwgIDI1NjAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMApzY3RwX2Fzb2M6ICAgICAgICAgICAgIDIyODgsICA0MDAwMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKc2N0cF9sYWRkcjogICAgICAgICAgICAgIDQ4LCAgODAwNjQs ICAgICAgIDAsICAgICAzNjAsICAgICAgIDgsICAgMCwgICAwCnNjdHBfcmFkZHI6ICAgICAgICAg ICAgIDcwNCwgIDgwMDAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3Rw X2NodW5rOiAgICAgICAgICAgICAxMzYsIDQwMDAwOCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKc2N0cF9yZWFkcTogICAgICAgICAgICAgMTA0LCA0MDAwMzIsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfc3RyZWFtX21zZ19vdXQ6ICAgIDExMiwg NDAwMDI2LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3RwX2FzY29uZjog ICAgICAgICAgICAgNDAsIDQwMDAwOCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKc2N0cF9hc2NvbmZfYWNrOiAgICAgICAgIDQ4LCA0MDAwMzIsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnJpcGNiOiAgICAgICAgICAgICAgICAgIDM5MiwgMjA0ODAwLCAg ICAgICAwLCAgICAgIDQwLCAgICAgIDE5LCAgIDAsICAgMAp1bnBjYjogICAgICAgICAgICAgICAg ICAyNDAsIDIwNDgwMCwgICAgICAyMCwgICAgICA2MCwgICAgIDM1NSwgICAwLCAgIDAKcnRlbnRy eTogICAgICAgICAgICAgICAgMjAwLCAgICAgIDAsICAgICAgMzQsICAgICAgNjEsICAgICAgNDAs ICAgMCwgICAwCklQRlcgZHluYW1pYyBydWxlOiAgICAgIDEyMCwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzZWxmZDogICAgICAgICAgICAgICAgICAgNTYsICAg ICAgMCwgICAgICA4NSwgICAgIDU0NSwgIDEwMjQ5OCwgICAwLCAgIDAKU1dBUE1FVEE6ICAgICAg ICAgICAgICAgMjg4LCAxMTY1MTksICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw CkZGUyBpbm9kZTogICAgICAgICAgICAgIDE2OCwgICAgICAwLCAgICAzNTIyLCAgICAgMTMwLCAg ICAzNjE1LCAgIDAsICAgMApGRlMxIGRpbm9kZTogICAgICAgICAgICAxMjgsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKRkZTMiBkaW5vZGU6ICAgICAgICAgICAg MjU2LCAgICAgIDAsICAgIDM1MjIsICAgICAxNTMsICAgIDM2MTUsICAgMCwgICAwCk5ldEdyYXBo IGl0ZW1zOiAgICAgICAgICA3MiwgICA0MTE4LCAgICAgICAwLCAgICAgIDU4LCAgICAgICA3LCAg IDAsICAgMApOZXRHcmFwaCBkYXRhIGl0ZW1zOiAgICAgNzIsICAgIDUyMiwgICAgICAgMCwgICAg ICA1OCwgICAgICAgNCwgICAwLCAgIDAKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1pCgppbnRl cnJ1cHQgICAgICAgICAgICAgICAgICAgICAgICAgIHRvdGFsICAgICAgIHJhdGUKaXJxMTQ6IGF0 YTAgICAgICAgICAgICAgICAgICAgICAgICAgICA0MyAgICAgICAgICAxCmlycTE3OiBhYWMwICAg ICAgICAgICAgICAgICAgICAgICAgIDI5MjUgICAgICAgICA5NAppcnEyMDogaHBldDAgICAgICAg ICAgICAgICAgICAgICAzNzExNjY3ICAgICAxMTk3MzEKaXJxMjI6IHVoY2kxICAgICAgICAgICAg ICAgICAgICAgICAgICAyMiAgICAgICAgICAwCmlycTIzOiB1aGNpMCB1aGNpMisgICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgMAppcnEyNTY6IGJjZTAgICAgICAgICAgICAgICAgICAgICAz MTU3ODMzICAgICAxMDE4NjUKaXJxMjU3OiBiY2UxICAgICAgICAgICAgICAgICAgICAgMzE3MzAy OSAgICAgMTAyMzU1ClRvdGFsICAgICAgICAgICAgICAgICAgICAgICAgICAgMTAwNDU1MjEgICAg IDMyNDA0OQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnBzdGF0IC1UCgoxNDQvMjA0ODAwIGZpbGVzCjBNLzQw OTVNIHN3YXAgc3BhY2UKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtcwoKRGV2aWNlICAgICAgICAg IDUxMi1ibG9ja3MgICAgIFVzZWQgICAgQXZhaWwgQ2FwYWNpdHkKL2Rldi9hYWNkMHAzICAgICAg IDgzODgzNTIgICAgICAgIDAgIDgzODgzNTIgICAgIDAlCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KaW9zdGF0 Cgppb3N0YXQ6IGt2bV9yZWFkKF90a19uaW4pOiBpbnZhbGlkIGFkZHJlc3MgKDB4MCkKaW9zdGF0 OiBkaXNhYmxpbmcgVFRZIHN0YXRpc3RpY3MKICAgICAgICAgICBhYWNkMCAgICAgICAgICAgICAg Y2QwICAgICAgICAgICAgcGFzczAgICAgICAgICAgICAgY3B1CiAgS0IvdCB0cHMgIE1CL3MgICBL Qi90IHRwcyAgTUIvcyAgIEtCL3QgdHBzICBNQi9zICB1cyBuaSBzeSBpbiBpZAogMzEuMTYgIDk4 ICAyLjk3ICAgMC4wMCAgIDEgIDAuMDAgICAwLjAwICAgMCAgMC4wMCAgIDAgIDAgIDAgIDMgOTYK Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQppcGNzIC1hCgpNZXNzYWdlIFF1ZXVlczoKVCAgICAgICAgICAgSUQg ICAgICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVSICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9V UCAgICAgICAgICAgICAgICAgQ0JZVEVTICAgICAgICAgICAgICAgICBRTlVNICAgICAgICAgICAg ICAgUUJZVEVTICAgICAgICBMU1BJRCAgICAgICAgTFJQSUQgU1RJTUUgICAgUlRJTUUgICAgQ1RJ TUUgICAKClNoYXJlZCBNZW1vcnk6ClQgICAgICAgICAgIElEICAgICAgICAgIEtFWSBNT0RFICAg ICAgICBPV05FUiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JPVVAgICAgICAgICBOQVRUQ0ggICAg ICAgIFNFR1NaICAgICAgICAgQ1BJRCAgICAgICAgIExQSUQgQVRJTUUgICAgRFRJTUUgICAgQ1RJ TUUgICAKClNlbWFwaG9yZXM6ClQgICAgICAgICAgIElEICAgICAgICAgIEtFWSBNT0RFICAgICAg ICBPV05FUiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JPVVAgICAgICAgICAgTlNFTVMgT1RJTUUg ICAgQ1RJTUUgICAKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KaXBjcyAtVAoKbXNnaW5mbzoKCW1zZ21heDog ICAgICAgIDE2Mzg0CShtYXggY2hhcmFjdGVycyBpbiBhIG1lc3NhZ2UpCgltc2dtbmk6ICAgICAg ICAgICA0MAkoIyBvZiBtZXNzYWdlIHF1ZXVlcykKCW1zZ21uYjogICAgICAgICAyMDQ4CShtYXgg Y2hhcmFjdGVycyBpbiBhIG1lc3NhZ2UgcXVldWUpCgltc2d0cWw6ICAgICAgICAgICA0MAkobWF4 ICMgb2YgbWVzc2FnZXMgaW4gc3lzdGVtKQoJbXNnc3N6OiAgICAgICAgICAgIDgJKHNpemUgb2Yg YSBtZXNzYWdlIHNlZ21lbnQpCgltc2dzZWc6ICAgICAgICAgMjA0OAkoIyBvZiBtZXNzYWdlIHNl Z21lbnRzIGluIHN5c3RlbSkKCnNobWluZm86CglzaG1tYXg6ICAgIDUzNjg3MDkxMgkobWF4IHNo YXJlZCBtZW1vcnkgc2VnbWVudCBzaXplKQoJc2htbWluOiAgICAgICAgICAgIDEJKG1pbiBzaGFy ZWQgbWVtb3J5IHNlZ21lbnQgc2l6ZSkKCXNobW1uaTogICAgICAgICAgMTkyCShtYXggbnVtYmVy IG9mIHNoYXJlZCBtZW1vcnkgaWRlbnRpZmllcnMpCglzaG1zZWc6ICAgICAgICAgIDEyOAkobWF4 IHNoYXJlZCBtZW1vcnkgc2VnbWVudHMgcGVyIHByb2Nlc3MpCglzaG1hbGw6ICAgICAgIDEzMTA3 MgkobWF4IGFtb3VudCBvZiBzaGFyZWQgbWVtb3J5IGluIHBhZ2VzKQoKc2VtaW5mbzoKCXNlbW1u aTogICAgICAgICAgIDUwCSgjIG9mIHNlbWFwaG9yZSBpZGVudGlmaWVycykKCXNlbW1uczogICAg ICAgICAgMzQwCSgjIG9mIHNlbWFwaG9yZXMgaW4gc3lzdGVtKQoJc2VtbW51OiAgICAgICAgICAx NTAJKCMgb2YgdW5kbyBzdHJ1Y3R1cmVzIGluIHN5c3RlbSkKCXNlbW1zbDogICAgICAgICAgMzQw CShtYXggIyBvZiBzZW1hcGhvcmVzIHBlciBpZCkKCXNlbW9wbTogICAgICAgICAgMTAwCShtYXgg IyBvZiBvcGVyYXRpb25zIHBlciBzZW1vcCBjYWxsKQoJc2VtdW1lOiAgICAgICAgICAgNTAJKG1h eCAjIG9mIHVuZG8gZW50cmllcyBwZXIgcHJvY2VzcykKCXNlbXVzejogICAgICAgICAgNjMyCShz aXplIGluIGJ5dGVzIG9mIHVuZG8gc3RydWN0dXJlKQoJc2Vtdm14OiAgICAgICAgMzI3NjcJKHNl bWFwaG9yZSBtYXhpbXVtIHZhbHVlKQoJc2VtYWVtOiAgICAgICAgMTYzODQJKGFkanVzdCBvbiBl eGl0IG1heCB2YWx1ZSkKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmZzc3RhdAoKQ2xpZW50IEluZm86ClJw YyBDb3VudHM6CiAgR2V0YXR0ciAgIFNldGF0dHIgICAgTG9va3VwICBSZWFkbGluayAgICAgIFJl YWQgICAgIFdyaXRlICAgIENyZWF0ZSAgICBSZW1vdmUKICAgICAgICAwICAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAog ICBSZW5hbWUgICAgICBMaW5rICAgU3ltbGluayAgICAgTWtkaXIgICAgIFJtZGlyICAgUmVhZGRp ciAgUmRpclBsdXMgICAgQWNjZXNzCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKICAgIE1rbm9kICAg IEZzc3RhdCAgICBGc2luZm8gIFBhdGhDb25mICAgIENvbW1pdAogICAgICAgIDAgICAgICAgICAw ICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwClJwYyBJbmZvOgogVGltZWRPdXQgICBJbnZh bGlkIFggUmVwbGllcyAgIFJldHJpZXMgIFJlcXVlc3RzCiAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAKQ2FjaGUgSW5mbzoKQXR0ciBIaXRzICAgIE1pc3Nl cyBMa3VwIEhpdHMgICAgTWlzc2VzIEJpb1IgSGl0cyAgICBNaXNzZXMgQmlvVyBIaXRzICAgIE1p c3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwCkJpb1JMSGl0cyAgICBNaXNzZXMgQmlvRCBIaXRz ICAgIE1pc3NlcyBEaXJFIEhpdHMgICAgTWlzc2VzIEFjY3MgSGl0cyAgICBNaXNzZXMKICAgICAg ICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMAoKU2VydmVyIEluZm86CiAgR2V0YXR0ciAgIFNldGF0dHIgICAgTG9v a3VwICBSZWFkbGluayAgICAgIFJlYWQgICAgIFdyaXRlICAgIENyZWF0ZSAgICBSZW1vdmUKICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAg ICAgICAgICAwICAgICAgICAgMAogICBSZW5hbWUgICAgICBMaW5rICAgU3ltbGluayAgICAgTWtk aXIgICAgIFJtZGlyICAgUmVhZGRpciAgUmRpclBsdXMgICAgQWNjZXNzCiAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAKICAgIE1rbm9kICAgIEZzc3RhdCAgICBGc2luZm8gIFBhdGhDb25mICAgIENvbW1p dAogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwClNlcnZl ciBSZXQtRmFpbGVkCiAgICAgICAgICAgICAgICAwClNlcnZlciBGYXVsdHMKICAgICAgICAgICAg MApTZXJ2ZXIgQ2FjaGUgU3RhdHM6CiAgIElucHJvZyAgICAgIElkZW0gIE5vbi1pZGVtICAgIE1p c3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKU2VydmVyIFdyaXRl IEdhdGhlcmluZzoKIFdyaXRlT3BzICBXcml0ZVJQQyAgIE9wc2F2ZWQKICAgICAgICAwICAgICAg ICAgMCAgICAgICAgIDAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1zCgp0Y3A6CgkyNjkwIHBh Y2tldHMgc2VudAoJCTI0NzMgZGF0YSBwYWNrZXRzICg5MDcyODMgYnl0ZXMpCgkJMCBkYXRhIHBh Y2tldHMgKDAgYnl0ZXMpIHJldHJhbnNtaXR0ZWQKCQkwIGRhdGEgcGFja2V0cyB1bm5lY2Vzc2Fy aWx5IHJldHJhbnNtaXR0ZWQKCQkwIHJlc2VuZHMgaW5pdGlhdGVkIGJ5IE1UVSBkaXNjb3ZlcnkK CQkxNzkgYWNrLW9ubHkgcGFja2V0cyAoNzIgZGVsYXllZCkKCQkwIFVSRyBvbmx5IHBhY2tldHMK CQkwIHdpbmRvdyBwcm9iZSBwYWNrZXRzCgkJMCB3aW5kb3cgdXBkYXRlIHBhY2tldHMKCQkzOCBj b250cm9sIHBhY2tldHMKCTExOTQ5IHBhY2tldHMgcmVjZWl2ZWQKCQkyNzQ0IGFja3MgKGZvciA5 MDczNTggYnl0ZXMpCgkJMzAgZHVwbGljYXRlIGFja3MKCQkwIGFja3MgZm9yIHVuc2VudCBkYXRh CgkJMTI0NSBwYWNrZXRzICg2NDkwOCBieXRlcykgcmVjZWl2ZWQgaW4tc2VxdWVuY2UKCQkxIGNv bXBsZXRlbHkgZHVwbGljYXRlIHBhY2tldCAoMCBieXRlcykKCQkwIG9sZCBkdXBsaWNhdGUgcGFj a2V0cwoJCTAgcGFja2V0cyB3aXRoIHNvbWUgZHVwLiBkYXRhICgwIGJ5dGVzIGR1cGVkKQoJCTgg b3V0LW9mLW9yZGVyIHBhY2tldHMgKDMyIGJ5dGVzKQoJCTAgcGFja2V0cyAoMCBieXRlcykgb2Yg ZGF0YSBhZnRlciB3aW5kb3cKCQkwIHdpbmRvdyBwcm9iZXMKCQkwIHdpbmRvdyB1cGRhdGUgcGFj a2V0cwoJCTAgcGFja2V0cyByZWNlaXZlZCBhZnRlciBjbG9zZQoJCTAgZGlzY2FyZGVkIGZvciBi YWQgY2hlY2tzdW1zCgkJMCBkaXNjYXJkZWQgZm9yIGJhZCBoZWFkZXIgb2Zmc2V0IGZpZWxkcwoJ CTAgZGlzY2FyZGVkIGJlY2F1c2UgcGFja2V0IHRvbyBzaG9ydAoJCTAgZGlzY2FyZGVkIGR1ZSB0 byBtZW1vcnkgcHJvYmxlbXMKCTEgY29ubmVjdGlvbiByZXF1ZXN0CgkzOCBjb25uZWN0aW9uIGFj Y2VwdHMKCTAgYmFkIGNvbm5lY3Rpb24gYXR0ZW1wdHMKCTAgbGlzdGVuIHF1ZXVlIG92ZXJmbG93 cwoJMCBpZ25vcmVkIFJTVHMgaW4gdGhlIHdpbmRvd3MKCTM4IGNvbm5lY3Rpb25zIGVzdGFibGlz aGVkIChpbmNsdWRpbmcgYWNjZXB0cykKCTU3IGNvbm5lY3Rpb25zIGNsb3NlZCAoaW5jbHVkaW5n IDEgZHJvcCkKCQkyIGNvbm5lY3Rpb25zIHVwZGF0ZWQgY2FjaGVkIFJUVCBvbiBjbG9zZQoJCTIg Y29ubmVjdGlvbnMgdXBkYXRlZCBjYWNoZWQgUlRUIHZhcmlhbmNlIG9uIGNsb3NlCgkJMCBjb25u ZWN0aW9ucyB1cGRhdGVkIGNhY2hlZCBzc3RocmVzaCBvbiBjbG9zZQoJMSBlbWJyeW9uaWMgY29u bmVjdGlvbiBkcm9wcGVkCgkyNzE1IHNlZ21lbnRzIHVwZGF0ZWQgcnR0IChvZiAyMzA1IGF0dGVt cHRzKQoJOCByZXRyYW5zbWl0IHRpbWVvdXRzCgkJMCBjb25uZWN0aW9ucyBkcm9wcGVkIGJ5IHJl eG1pdCB0aW1lb3V0CgkwIHBlcnNpc3QgdGltZW91dHMKCQkwIGNvbm5lY3Rpb25zIGRyb3BwZWQg YnkgcGVyc2lzdCB0aW1lb3V0CgkwIENvbm5lY3Rpb25zIChmaW5fd2FpdF8yKSBkcm9wcGVkIGJl Y2F1c2Ugb2YgdGltZW91dAoJMSBrZWVwYWxpdmUgdGltZW91dAoJCTAga2VlcGFsaXZlIHByb2Jl cyBzZW50CgkJMSBjb25uZWN0aW9uIGRyb3BwZWQgYnkga2VlcGFsaXZlCgkyMDM0IGNvcnJlY3Qg QUNLIGhlYWRlciBwcmVkaWN0aW9ucwoJODM0IGNvcnJlY3QgZGF0YSBwYWNrZXQgaGVhZGVyIHBy ZWRpY3Rpb25zCgkzOCBzeW5jYWNoZSBlbnRyaWVzIGFkZGVkCgkJMCByZXRyYW5zbWl0dGVkCgkJ MCBkdXBzeW4KCQkwIGRyb3BwZWQKCQkzOCBjb21wbGV0ZWQKCQkwIGJ1Y2tldCBvdmVyZmxvdwoJ CTAgY2FjaGUgb3ZlcmZsb3cKCQkwIHJlc2V0CgkJMCBzdGFsZQoJCTAgYWJvcnRlZAoJCTAgYmFk YWNrCgkJMCB1bnJlYWNoCgkJMCB6b25lIGZhaWx1cmVzCgkzOCBjb29raWVzIHNlbnQKCTAgY29v a2llcyByZWNlaXZlZAoJMSBob3N0Y2FjaGUgZW50cmllIGFkZGVkCgkJMCBidWNrZXQgb3ZlcmZs b3cKCTAgU0FDSyByZWNvdmVyeSBlcGlzb2RlcwoJMCBzZWdtZW50IHJleG1pdHMgaW4gU0FDSyBy ZWNvdmVyeSBlcGlzb2RlcwoJMCBieXRlIHJleG1pdHMgaW4gU0FDSyByZWNvdmVyeSBlcGlzb2Rl cwoJMCBTQUNLIG9wdGlvbnMgKFNBQ0sgYmxvY2tzKSByZWNlaXZlZAoJMCBTQUNLIG9wdGlvbnMg KFNBQ0sgYmxvY2tzKSBzZW50CgkwIFNBQ0sgc2NvcmVib2FyZCBvdmVyZmxvdwoJMCBwYWNrZXRz IHdpdGggRUNOIENFIGJpdCBzZXQKCTAgcGFja2V0cyB3aXRoIEVDTiBFQ1QoMCkgYml0IHNldAoJ MCBwYWNrZXRzIHdpdGggRUNOIEVDVCgxKSBiaXQgc2V0CgkwIHN1Y2Nlc3NmdWwgRUNOIGhhbmRz aGFrZXMKCTAgdGltZXMgRUNOIHJlZHVjZWQgdGhlIGNvbmdlc3Rpb24gd2luZG93CnVkcDoKCTM0 ODE5IGRhdGFncmFtcyByZWNlaXZlZAoJMCB3aXRoIGluY29tcGxldGUgaGVhZGVyCgkwIHdpdGgg YmFkIGRhdGEgbGVuZ3RoIGZpZWxkCgkwIHdpdGggYmFkIGNoZWNrc3VtCgk4MCB3aXRoIG5vIGNo ZWNrc3VtCgkxNTU4NSBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTE5MDU1IGJyb2FkY2FzdC9t dWx0aWNhc3QgZGF0YWdyYW1zIHVuZGVsaXZlcmVkCgkwIGRyb3BwZWQgZHVlIHRvIGZ1bGwgc29j a2V0IGJ1ZmZlcnMKCTAgbm90IGZvciBoYXNoZWQgcGNiCgkxNzkgZGVsaXZlcmVkCgkxOTIgZGF0 YWdyYW1zIG91dHB1dAoJMCB0aW1lcyBtdWx0aWNhc3Qgc291cmNlIGZpbHRlciBtYXRjaGVkCmlw OgoJNDY0OTYzNSB0b3RhbCBwYWNrZXRzIHJlY2VpdmVkCgkwIGJhZCBoZWFkZXIgY2hlY2tzdW1z CgkwIHdpdGggc2l6ZSBzbWFsbGVyIHRoYW4gbWluaW11bQoJMCB3aXRoIGRhdGEgc2l6ZSA8IGRh dGEgbGVuZ3RoCgkwIHdpdGggaXAgbGVuZ3RoID4gbWF4IGlwIHBhY2tldCBzaXplCgkwIHdpdGgg aGVhZGVyIGxlbmd0aCA8IGRhdGEgc2l6ZQoJMCB3aXRoIGRhdGEgbGVuZ3RoIDwgaGVhZGVyIGxl bmd0aAoJMCB3aXRoIGJhZCBvcHRpb25zCgkwIHdpdGggaW5jb3JyZWN0IHZlcnNpb24gbnVtYmVy CgkyIGZyYWdtZW50cyByZWNlaXZlZAoJMCBmcmFnbWVudHMgZHJvcHBlZCAoZHVwIG9yIG91dCBv ZiBzcGFjZSkKCTEgZnJhZ21lbnQgZHJvcHBlZCBhZnRlciB0aW1lb3V0CgkwIHBhY2tldHMgcmVh c3NlbWJsZWQgb2sKCTQ2NzcxIHBhY2tldHMgZm9yIHRoaXMgaG9zdAoJOTcyIHBhY2tldHMgZm9y IHVua25vd24vdW5zdXBwb3J0ZWQgcHJvdG9jb2wKCTQ1OTQ1MTggcGFja2V0cyBmb3J3YXJkZWQg KDAgcGFja2V0cyBmYXN0IGZvcndhcmRlZCkKCTczOTYgcGFja2V0cyBub3QgZm9yd2FyZGFibGUK CTAgcGFja2V0cyByZWNlaXZlZCBmb3IgdW5rbm93biBtdWx0aWNhc3QgZ3JvdXAKCTMxMSByZWRp cmVjdHMgc2VudAoJMzIzNSBwYWNrZXRzIHNlbnQgZnJvbSB0aGlzIGhvc3QKCTAgcGFja2V0cyBz ZW50IHdpdGggZmFicmljYXRlZCBpcCBoZWFkZXIKCTAgb3V0cHV0IHBhY2tldHMgZHJvcHBlZCBk dWUgdG8gbm8gYnVmcywgZXRjLgoJMiBvdXRwdXQgcGFja2V0cyBkaXNjYXJkZWQgZHVlIHRvIG5v IHJvdXRlCgkwIG91dHB1dCBkYXRhZ3JhbXMgZnJhZ21lbnRlZAoJMCBmcmFnbWVudHMgY3JlYXRl ZAoJMCBkYXRhZ3JhbXMgdGhhdCBjYW4ndCBiZSBmcmFnbWVudGVkCgkwIHR1bm5lbGluZyBwYWNr ZXRzIHRoYXQgY2FuJ3QgZmluZCBnaWYKCTAgZGF0YWdyYW1zIHdpdGggYmFkIGFkZHJlc3MgaW4g aGVhZGVyCmljbXA6CgkyNyBjYWxscyB0byBpY21wX2Vycm9yCgkwIGVycm9ycyBub3QgZ2VuZXJh dGVkIGluIHJlc3BvbnNlIHRvIGFuIGljbXAgbWVzc2FnZQoJT3V0cHV0IGhpc3RvZ3JhbToKCQll Y2hvIHJlcGx5OiAxCgkJZGVzdGluYXRpb24gdW5yZWFjaGFibGU6IDMKCQlyb3V0aW5nIHJlZGly ZWN0OiAzMTEKCQl0aW1lIGV4Y2VlZGVkOiAyNAoJMCBtZXNzYWdlcyB3aXRoIGJhZCBjb2RlIGZp ZWxkcwoJMCBtZXNzYWdlcyBsZXNzIHRoYW4gdGhlIG1pbmltdW0gbGVuZ3RoCgkwIG1lc3NhZ2Vz IHdpdGggYmFkIGNoZWNrc3VtCgkwIG1lc3NhZ2VzIHdpdGggYmFkIGxlbmd0aAoJMCBtdWx0aWNh c3QgZWNobyByZXF1ZXN0cyBpZ25vcmVkCgkwIG11bHRpY2FzdCB0aW1lc3RhbXAgcmVxdWVzdHMg aWdub3JlZAoJSW5wdXQgaGlzdG9ncmFtOgoJCWRlc3RpbmF0aW9uIHVucmVhY2hhYmxlOiAzOTQK CQllY2hvOiAxCgkxIG1lc3NhZ2UgcmVzcG9uc2UgZ2VuZXJhdGVkCgkwIGludmFsaWQgcmV0dXJu IGFkZHJlc3NlcwoJMCBubyByZXR1cm4gcm91dGVzCmlnbXA6Cgk1NzggbWVzc2FnZXMgcmVjZWl2 ZWQKCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCB0b28gZmV3IGJ5dGVzCgkwIG1lc3NhZ2VzIHJl Y2VpdmVkIHdpdGggd3JvbmcgVFRMCgkwIG1lc3NhZ2VzIHJlY2VpdmVkIHdpdGggYmFkIGNoZWNr c3VtCgk1MCBWMS9WMiBtZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQKCTAgVjMgbWVtYmVyc2hp cCBxdWVyaWVzIHJlY2VpdmVkCgkwIG1lbWJlcnNoaXAgcXVlcmllcyByZWNlaXZlZCB3aXRoIGlu dmFsaWQgZmllbGQocykKCTUwIGdlbmVyYWwgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cCBxdWVy aWVzIHJlY2VpdmVkCgkwIGdyb3VwLXNvdXJjZSBxdWVyaWVzIHJlY2VpdmVkCgkwIGdyb3VwLXNv dXJjZSBxdWVyaWVzIGRyb3BwZWQKCTUwNSBtZW1iZXJzaGlwIHJlcG9ydHMgcmVjZWl2ZWQKCTAg bWVtYmVyc2hpcCByZXBvcnRzIHJlY2VpdmVkIHdpdGggaW52YWxpZCBmaWVsZChzKQoJMzkgbWVt YmVyc2hpcCByZXBvcnRzIHJlY2VpdmVkIGZvciBncm91cHMgdG8gd2hpY2ggd2UgYmVsb25nCgkw IFYzIHJlcG9ydHMgcmVjZWl2ZWQgd2l0aG91dCBSb3V0ZXIgQWxlcnQKCTEzIG1lbWJlcnNoaXAg cmVwb3J0cyBzZW50CmFycDoKCTM3IEFSUCByZXF1ZXN0cyBzZW50CgkxNzY3IEFSUCByZXBsaWVz IHNlbnQKCTIzNzYwIEFSUCByZXF1ZXN0cyByZWNlaXZlZAoJMzQgQVJQIHJlcGxpZXMgcmVjZWl2 ZWQKCTQ2MDE4IEFSUCBwYWNrZXRzIHJlY2VpdmVkCgkyIHRvdGFsIHBhY2tldHMgZHJvcHBlZCBk dWUgdG8gbm8gQVJQIGVudHJ5Cgk0IEFSUCBlbnRyeXMgdGltZWQgb3V0CgkwIER1cGxpY2F0ZSBJ UHMgc2VlbgppcDY6CgkwIHRvdGFsIHBhY2tldHMgcmVjZWl2ZWQKCTAgd2l0aCBzaXplIHNtYWxs ZXIgdGhhbiBtaW5pbXVtCgkwIHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5ndGgKCTAgd2l0aCBi YWQgb3B0aW9ucwoJMCB3aXRoIGluY29ycmVjdCB2ZXJzaW9uIG51bWJlcgoJMCBmcmFnbWVudHMg cmVjZWl2ZWQKCTAgZnJhZ21lbnRzIGRyb3BwZWQgKGR1cCBvciBvdXQgb2Ygc3BhY2UpCgkwIGZy YWdtZW50cyBkcm9wcGVkIGFmdGVyIHRpbWVvdXQKCTAgZnJhZ21lbnRzIHRoYXQgZXhjZWVkZWQg bGltaXQKCTAgcGFja2V0cyByZWFzc2VtYmxlZCBvawoJMCBwYWNrZXRzIGZvciB0aGlzIGhvc3QK CTAgcGFja2V0cyBmb3J3YXJkZWQKCTAgcGFja2V0cyBub3QgZm9yd2FyZGFibGUKCTAgcmVkaXJl Y3RzIHNlbnQKCTEzIHBhY2tldHMgc2VudCBmcm9tIHRoaXMgaG9zdAoJMCBwYWNrZXRzIHNlbnQg d2l0aCBmYWJyaWNhdGVkIGlwIGhlYWRlcgoJMCBvdXRwdXQgcGFja2V0cyBkcm9wcGVkIGR1ZSB0 byBubyBidWZzLCBldGMuCgk2IG91dHB1dCBwYWNrZXRzIGRpc2NhcmRlZCBkdWUgdG8gbm8gcm91 dGUKCTAgb3V0cHV0IGRhdGFncmFtcyBmcmFnbWVudGVkCgkwIGZyYWdtZW50cyBjcmVhdGVkCgkw IGRhdGFncmFtcyB0aGF0IGNhbid0IGJlIGZyYWdtZW50ZWQKCTAgcGFja2V0cyB0aGF0IHZpb2xh dGVkIHNjb3BlIHJ1bGVzCgkwIG11bHRpY2FzdCBwYWNrZXRzIHdoaWNoIHdlIGRvbid0IGpvaW4K CU1idWYgc3RhdGlzdGljczoKCQkyNDc2IG9uZSBtYnVmCgkJdHdvIG9yIG1vcmUgbWJ1ZjoKCQkJ YmNlMD0gNDQxMQoJCTAgb25lIGV4dCBtYnVmCgkJMCB0d28gb3IgbW9yZSBleHQgbWJ1ZgoJMCBw YWNrZXRzIHdob3NlIGhlYWRlcnMgYXJlIG5vdCBjb250aWd1b3VzCgkwIHR1bm5lbGluZyBwYWNr ZXRzIHRoYXQgY2FuJ3QgZmluZCBnaWYKCTAgcGFja2V0cyBkaXNjYXJkZWQgYmVjYXVzZSBvZiB0 b28gbWFueSBoZWFkZXJzCgkwIGZhaWx1cmVzIG9mIHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbgoJ U291cmNlIGFkZHJlc3NlcyBzZWxlY3Rpb24gcnVsZSBhcHBsaWVkOgppY21wNjoKCTAgY2FsbHMg dG8gaWNtcDZfZXJyb3IKCTAgZXJyb3JzIG5vdCBnZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gYW4g aWNtcDYgbWVzc2FnZQoJMCBlcnJvcnMgbm90IGdlbmVyYXRlZCBiZWNhdXNlIG9mIHJhdGUgbGlt aXRhdGlvbgoJT3V0cHV0IGhpc3RvZ3JhbToKCQluZWlnaGJvciBzb2xpY2l0YXRpb246IDMKCQlN TER2MiBsaXN0ZW5lciByZXBvcnQ6IDQKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY29kZSBmaWVsZHMK CTAgbWVzc2FnZXMgPCBtaW5pbXVtIGxlbmd0aAoJMCBiYWQgY2hlY2tzdW1zCgkwIG1lc3NhZ2Vz IHdpdGggYmFkIGxlbmd0aAoJSGlzdG9ncmFtIG9mIGVycm9yIG1lc3NhZ2VzIHRvIGJlIGdlbmVy YXRlZDoKCQkwIG5vIHJvdXRlCgkJMCBhZG1pbmlzdHJhdGl2ZWx5IHByb2hpYml0ZWQKCQkwIGJl eW9uZCBzY29wZQoJCTAgYWRkcmVzcyB1bnJlYWNoYWJsZQoJCTAgcG9ydCB1bnJlYWNoYWJsZQoJ CTAgcGFja2V0IHRvbyBiaWcKCQkwIHRpbWUgZXhjZWVkIHRyYW5zaXQKCQkwIHRpbWUgZXhjZWVk IHJlYXNzZW1ibHkKCQkwIGVycm9uZW91cyBoZWFkZXIgZmllbGQKCQkwIHVucmVjb2duaXplZCBu ZXh0IGhlYWRlcgoJCTAgdW5yZWNvZ25pemVkIG9wdGlvbgoJCTAgcmVkaXJlY3QKCQkwIHVua25v d24KCTAgbWVzc2FnZSByZXNwb25zZXMgZ2VuZXJhdGVkCgkwIG1lc3NhZ2VzIHdpdGggdG9vIG1h bnkgTkQgb3B0aW9ucwoJMCBtZXNzYWdlcyB3aXRoIGJhZCBORCBvcHRpb25zCgkwIGJhZCBuZWln aGJvciBzb2xpY2l0YXRpb24gbWVzc2FnZXMKCTAgYmFkIG5laWdoYm9yIGFkdmVydGlzZW1lbnQg bWVzc2FnZXMKCTAgYmFkIHJvdXRlciBzb2xpY2l0YXRpb24gbWVzc2FnZXMKCTAgYmFkIHJvdXRl ciBhZHZlcnRpc2VtZW50IG1lc3NhZ2VzCgkwIGJhZCByZWRpcmVjdCBtZXNzYWdlcwoJMCBwYXRo IE1UVSBjaGFuZ2VzCnJpcDY6CgkwIG1lc3NhZ2VzIHJlY2VpdmVkCgkwIGNoZWNrc3VtIGNhbGN1 bGF0aW9ucyBvbiBpbmJvdW5kCgkwIG1lc3NhZ2VzIHdpdGggYmFkIGNoZWNrc3VtCgkwIG1lc3Nh Z2VzIGRyb3BwZWQgZHVlIHRvIG5vIHNvY2tldAoJMCBtdWx0aWNhc3QgbWVzc2FnZXMgZHJvcHBl ZCBkdWUgdG8gbm8gc29ja2V0CgkwIG1lc3NhZ2VzIGRyb3BwZWQgZHVlIHRvIGZ1bGwgc29ja2V0 IGJ1ZmZlcnMKCTAgZGVsaXZlcmVkCgkwIGRhdGFncmFtcyBvdXRwdXQKCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQpuZXRzdGF0IC1tCgo1MTA3LzE2OTkvNjgwNiBtYnVmcyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUv dG90YWwpCjQwNzEvNzk5LzQ4NzAvNjU1MzYgbWJ1ZiBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQv Y2FjaGUvdG90YWwvbWF4KQo0MDgyLzc5MyBtYnVmK2NsdXN0ZXJzIG91dCBvZiBwYWNrZXQgc2Vj b25kYXJ5IHpvbmUgaW4gdXNlIChjdXJyZW50L2NhY2hlKQowLzY1LzY1LzEyODAwIDRrIChwYWdl IHNpemUpIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjAv MC8wLzE5MjAwIDlrIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9t YXgpCjAvMC8wLzEyODAwIDE2ayBqdW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUv dG90YWwvbWF4KQo5NDE4Sy8yMjgySy8xMTcwMUsgYnl0ZXMgYWxsb2NhdGVkIHRvIG5ldHdvcmsg KGN1cnJlbnQvY2FjaGUvdG90YWwpCjAvMC8wIHJlcXVlc3RzIGZvciBtYnVmcyBkZW5pZWQgKG1i dWZzL2NsdXN0ZXJzL21idWYrY2x1c3RlcnMpCjAvMC8wIHJlcXVlc3RzIGZvciBqdW1ibyBjbHVz dGVycyBkZW5pZWQgKDRrLzlrLzE2aykKMCByZXF1ZXN0cyBmb3Igc2ZidWZzIGRlbmllZAowIHJl cXVlc3RzIGZvciBzZmJ1ZnMgZGVsYXllZAowIHJlcXVlc3RzIGZvciBJL08gaW5pdGlhdGVkIGJ5 IHNlbmRmaWxlCjAgY2FsbHMgdG8gcHJvdG9jb2wgZHJhaW4gcm91dGluZXMKCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQpuZXRzdGF0IC1pZAoKTmFtZSAgICBNdHUgTmV0d29yayAgICAgICBBZGRyZXNzICAgICAg ICAgICAgICBJcGt0cyBJZXJycyBJZHJvcCAgICBPcGt0cyBPZXJycyAgQ29sbCBEcm9wCmJjZTAg ICAxNTAwIDxMaW5rIzE+ICAgICAgWFg6WFg6WFg6WFg6WFg6WFggIDE5OTMyNTkgICAgIDAgICAg IDAgIDI2NjQzNDUgICAgIDAgICAgIDAgICAgMCAKYmNlMCAgIDE1MDAgWFhYWDo6WFhYOlhYWCBY WFhYOjpYWFg6WFhYWDpYWCAgICAgICAgMCAgICAgLSAgICAgLSAgICAgICAgMCAgICAgLSAgICAg LSAgICAtIApiY2UwICAgMTUwMCBYWFguWFhYLlhYWC5YWFggICAgWFhYLlhYWC5YWFguWFhYICAg ICAgICAgICAxMTAwOCAgICAgLSAgICAgLSAgICAgNjE3OCAgICAgLSAgICAgLSAgICAtIApiY2Ux ICAgMTUwMCA8TGluayMyPiAgICAgIFhYOlhYOlhYOlhYOlhYOlhYICAyNzE0NDYyICAgICAwICAg ICAwICAxOTM4MTMxICAgICAwICAgICAwICAgIDAgCmJjZTEgICAxNTAwIFhYWFg6OlhYWDpYWFgg WFhYWDo6WFhYOlhYWFg6WFggICAgICAgIDAgICAgIC0gICAgIC0gICAgICAgIDEgICAgIC0gICAg IC0gICAgLSAKdXNidXMgICAgIDAgPExpbmsjMz4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMCAgICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIAp1c2J1cyAgICAgMCA8 TGluayM0PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAwICAgICAg ICAwICAgICAwICAgICAwICAgIDAgCnVzYnVzICAgICAwIDxMaW5rIzU+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAK dXNidXMgICAgIDAgPExpbmsjNj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAg MCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIAppcGZ3MCA2NTUzNiA8TGluayM3PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAwICAgICAgICAwICAgICAw ICAgICAwICAgIDAgCmxvMCAgIDE2Mzg0IDxMaW5rIzg+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAKbG8wICAgMTYz ODQgbG9jYWxob3N0ICAgICA6OjEgICAgICAgICAgICAgICAgICAgICAgMCAgICAgLSAgICAgLSAg ICAgICAgMCAgICAgLSAgICAgLSAgICAtIApsbzAgICAxNjM4NCBmZTgwOjoxJWxvMCAgIGZlODA6 OjEgICAgICAgICAgICAgICAgICAwICAgICAtICAgICAtICAgICAgICAwICAgICAtICAgICAtICAg IC0gCmxvMCAgIDE2Mzg0IHlvdXItbmV0ICAgICAgbG9jYWxob3N0ICAgICAgICAgICAgICAgIDAg ICAgIC0gICAgIC0gICAgICAgIDAgICAgIC0gICAgIC0gICAgLSAKdmxhbjEgIDE1MDAgPExpbmsj OT4gICAgICBYWDpYWDpYWDpYWDpYWDpYWCAgMjY3OTczNSAgICAgMCAgICAgMCAgMTkzODEzMSAg ICAgMCAgICAgMCAgICAwIAp2bGFuMSAgMTUwMCBYWFguWFhYLlhYWC5YWFggWVlZWVlZWVlZWVlZ WVlZWS4gICAgMjQyMDAgICAgIC0gICAgIC0gICAgICAyNTMgICAgIC0gICAgIC0gICAgLSAKdmxh bjIgIDE1MDAgPExpbmsjMTA+ICAgICAwMDowMDowMDowMDowMDowMCAgICAgICAgMCAgICAgMCAg ICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIApjYXJwMCAgMTUwMCA8TGluayMxMT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAxICAgICAwICAgICAwICAgICAzMDYwICAgICAwICAg ICAwICAgIDAgCmNhcnAwICAxNTAwIFhYWC5YWFguWFhYLlhYWCAgICBsb2dzICAgICAgICAgICAg ICAgICAgIDI5NyAgICAgLSAgICAgLSAgICAgICAgMCAgICAgLSAgICAgLSAgICAtIAp0dW4wICAg MTUwMCA8TGluayMxMj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAw ICAgICAgMjcyICAgICAwICAgICAwICAgIDAgCnR1bjAgICAxNTAwIFhYWFg6OlhYWDpYWFggWFhY WDo6WFhYOlhYWFg6WFggICAgICAgIDAgICAgIC0gICAgIC0gICAgICAgIDIgICAgIC0gICAgIC0g ICAgLSAKdHVuMCAgIDE1MDAgWC5YLlguWC8zMiAgIFguWC5YLlggICAgICAgICAgICAgICAgIDAg ICAgIC0gICAgIC0gICAgICAgIDAgICAgIC0gICAgIC0gICAgLSAKCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpu ZXRzdGF0IC1hbnIKClJvdXRpbmcgdGFibGVzCgpJbnRlcm5ldDoKRGVzdGluYXRpb24gICAgICAg IEdhdGV3YXkgICAgICAgICAgICBGbGFncyAgICBSZWZzICAgICAgVXNlICBOZXRpZiBFeHBpcmUK ZGVmYXVsdCAgICAgICAgICAgIHh4eC54eHgueHh4LjQ5ICAgICBVR1MgICAgICAgICAxICAxOTM4 MDM2IHZsYW4xMQoxMC41LjAuMC8yNCAgICAgICAgMTAuNS4wLjIgICAgICAgICAgIFVHUyAgICAg ICAgIDAgICAgICAyNjcgICB0dW4wCjEwLjUuMC4xICAgICAgICAgICBsaW5rIzEyICAgICAgICAg ICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKMTAuNS4wLjIgICAgICAgICAgIGxpbmsj MTIgICAgICAgICAgICBVSCAgICAgICAgICAwICAgICAgICAwICAgdHVuMAoxMjcuMC4wLjEgICAg ICAgICAgbGluayM4ICAgICAgICAgICAgIFVIICAgICAgICAgIDAgICAgICAgIDAgICAgbG8wCnh4 eC54eHguMC4wLzE2ICAgICAgbGluayMxICAgICAgICAgICAgIFUgICAgICAgICAgIDAgIDI2NTkx NzAgICBiY2UwCnh4eC54eHguMS4yICAgICAgICAgbGluayMxICAgICAgICAgICAgIFVIUyAgICAg ICAgIDAgICAgICAgIDAgICAgbG8wCnh4eC54eHguMS4zICAgICAgICAgbGluayMxMSAgICAgICAg ICAgIFVIICAgICAgICAgIDAgICAgICAgIDAgIGNhcnAwCjE5Mi4xNjguMTcuMC8yNCAgICB4eHgu eHh4LjEuMTAgICAgICAgIFVHUyAgICAgICAgIDAgICAgICAgIDAgICBiY2UwCjE5Mi4xNjguMTgu MC8yNCAgICB4eHgueHh4LjEuMjAgICAgICAgIFVHUyAgICAgICAgIDAgICAgICAgIDAgICBiY2Uw Cnh4eC54eHgueHh4LjQ4LzI5ICBsaW5rIzkgICAgICAgICAgICAgVSAgICAgICAgICAgMCAgICAg ICA4OSB2bGFuMTEKeHh4Lnh4eC54eHguNTIgICAgIGxpbmsjOSAgICAgICAgICAgICBVSFMgICAg ICAgICAwICAgICAgICAwICAgIGxvMAp4eHgueHh4Lnh4eC41NCAgICAgeHh4Lnh4eC4xLjExMCAg ICAgICBVR0hTICAgICAgICAwICAgICAgMzExICAgYmNlMAoKSW50ZXJuZXQ2OgpEZXN0aW5hdGlv biAgICAgICAgICAgICAgICAgICAgICAgR2F0ZXdheSAgICAgICAgICAgICAgICAgICAgICAgRmxh Z3MgICAgICBOZXRpZiBFeHBpcmUKOjovOTYgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDo6 MSAgICAgICAgICAgICAgICAgICAgICAgICAgIFVHUlMgICAgICAgIGxvMAo6OjEgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgbGluayM4ICAgICAgICAgICAgICAgICAgICAgICAgVUggICAg ICAgICAgbG8wCjo6ZmZmZjowLjAuMC4wLzk2ICAgICAgICAgICAgICAgICA6OjEgICAgICAgICAg ICAgICAgICAgICAgICAgICBVR1JTICAgICAgICBsbzAKZmU4MDo6LzEwICAgICAgICAgICAgICAg ICAgICAgICAgIDo6MSAgICAgICAgICAgICAgICAgICAgICAgICAgIFVHUlMgICAgICAgIGxvMApm ZTgwOjolYmNlMC82NCAgICAgICAgICAgICAgICAgICAgbGluayMxICAgICAgICAgICAgICAgICAg ICAgICAgVSAgICAgICAgICBiY2UwCnh4eHg6Onh4eDp4eHh4Onh4eHg6ZWMyYSViY2UwICAgICBs aW5rIzEgICAgICAgICAgICAgICAgICAgICAgICBVSFMgICAgICAgICBsbzAKZmU4MDo6JWJjZTEv NjQgICAgICAgICAgICAgICAgICAgIGxpbmsjMiAgICAgICAgICAgICAgICAgICAgICAgIFUgICAg ICAgICAgYmNlMQp4eHh4Ojp4eHg6eHh4eDp4eHh4OmVjMmMlYmNlMSAgICAgbGluayMyICAgICAg ICAgICAgICAgICAgICAgICAgVUhTICAgICAgICAgbG8wCmZlODA6OiVsbzAvNjQgICAgICAgICAg ICAgICAgICAgICBsaW5rIzggICAgICAgICAgICAgICAgICAgICAgICBVICAgICAgICAgICBsbzAK ZmU4MDo6MSVsbzAgICAgICAgICAgICAgICAgICAgICAgIGxpbmsjOCAgICAgICAgICAgICAgICAg ICAgICAgIFVIUyAgICAgICAgIGxvMApmZTgwOjolMTIvNjQgICAgICAgICAgICAgICAgICAgICAg bGluayMxMiAgICAgICAgICAgICAgICAgICAgICAgVSAgICAgICAgICB0dW4wCnh4eHg6Onh4eDp4 eHh4Onh4eHg6ZWMyYSUxMiAgICAgICBsaW5rIzEyICAgICAgICAgICAgICAgICAgICAgICBVSFMg ICAgICAgICBsbzAKZmYwMTo6JWJjZTAvMzIgICAgICAgICAgICAgICAgICAgIHh4eHg6Onh4eDp4 eHh4Onh4eHg6ZWMyYSViY2UwIFUgICAgICAgICAgYmNlMApmZjAxOjolYmNlMS8zMiAgICAgICAg ICAgICAgICAgICAgeHh4eDo6eHh4Onh4eHg6eHh4eDplYzJjJWJjZTEgVSAgICAgICAgICBiY2Ux CmZmMDE6OiVsbzAvMzIgICAgICAgICAgICAgICAgICAgICA6OjEgICAgICAgICAgICAgICAgICAg ICAgICAgICBVICAgICAgICAgICBsbzAKZmYwMTo6JTEyLzMyICAgICAgICAgICAgICAgICAgICAg IHh4eHg6Onh4eDp4eHh4Onh4eHg6ZWMyYSUxMiAgIFUgICAgICAgICAgdHVuMApmZjAyOjovMTYg ICAgICAgICAgICAgICAgICAgICAgICAgOjoxICAgICAgICAgICAgICAgICAgICAgICAgICAgVUdS UyAgICAgICAgbG8wCmZmMDI6OiViY2UwLzMyICAgICAgICAgICAgICAgICAgICB4eHh4Ojp4eHg6 eHh4eDp4eHh4OmVjMmElYmNlMCBVICAgICAgICAgIGJjZTAKZmYwMjo6JWJjZTEvMzIgICAgICAg ICAgICAgICAgICAgIHh4eHg6Onh4eDp4eHh4Onh4eHg6ZWMyYyViY2UxIFUgICAgICAgICAgYmNl MQpmZjAyOjolbG8wLzMyICAgICAgICAgICAgICAgICAgICAgOjoxICAgICAgICAgICAgICAgICAg ICAgICAgICAgVSAgICAgICAgICAgbG8wCmZmMDI6OiUxMi8zMiAgICAgICAgICAgICAgICAgICAg ICB4eHh4Ojp4eHg6eHh4eDp4eHh4OmVjMmElMTIgICBVICAgICAgICAgIHR1bjAKCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpuZXRzdGF0IC1hbkEKCkFjdGl2ZSBJbnRlcm5ldCBjb25uZWN0aW9ucyAoaW5jbHVk aW5nIHNlcnZlcnMpClRjcGNiICAgICAgICAgICAgUHJvdG8gUmVjdi1RIFNlbmQtUSBMb2NhbCBB ZGRyZXNzICAgICAgRm9yZWlnbiBBZGRyZXNzICAgIChzdGF0ZSkKZmZmZmZlMDAyNTA2NzNkMCB0 Y3A0ICAgICAgIDAgICAgICAwIHh4eC54eHguMS4yLjIyMjIyICAgeHh4Lnh4eC4zLjIwLjQ3MzAw ICBFU1RBQkxJU0hFRApmZmZmZmUwMDI1M2RhN2EwIHRjcDQgICAgICAgMCAgICAgIDAgKi4yMjIy MiAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZlMDAyNTNkYWI3MCB0 Y3A2ICAgICAgIDAgICAgICAwICouMjIyMjIgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAg TElTVEVOCmZmZmZmZTAwMjUxY2U3YTAgdGNwNCAgICAgICAwICAgICAgMCAqLjM3ICAgICAgICAg ICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmUwMDI1M2RiM2QwIHRjcDQgICAg ICAgMCAgICAgIDAgMTI3LjAuMC4xLjI1ICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4K ZmZmZmZlMDAyNTIzNGI3MCB0Y3A0ICAgICAgIDAgICAgICAwICouOTEwMiAgICAgICAgICAgICAq LiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZTAwMjUyMzUwMDAgdGNwNCAgICAgICAwICAg ICAgMCB4eHgueHh4LjEuMi42NjcgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZl MDAyNTA2NzAwMCB0Y3A0ICAgICAgIDAgICAgICAwICouNDQzICAgICAgICAgICAgICAqLiogICAg ICAgICAgICAgICAgTElTVEVOCmZmZmZmZTAwMjUwNjZiNzAgdGNwNCAgICAgICAwICAgICAgMCAq LjgwICAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmUwMDI1MjM1 M2QwIHRjcDQgICAgICAgMCAgICAgIDAgKi4xOTkgICAgICAgICAgICAgICouKiAgICAgICAgICAg ICAgICBMSVNURU4KZmZmZmZlMDAyNTFjZTAwMCB0Y3A0ICAgICAgIDAgICAgICAwICouMTcyMyAg ICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZTAwMjUxY2UzZDAgdGNw NCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuNTAwNSAgICAgKi4qICAgICAgICAgICAgICAgIExJ U1RFTgpmZmZmZmUwMDI1MDY2N2EwIHRjcDYgICAgICAgMCAgICAgIDAgOjoxLjk1MyAgICAgICAg ICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZlMDAyNTA2NjAwMCB0Y3A0ICAgICAg IDAgICAgICAwIDEyNy4wLjAuMS45NTMgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZm ZmZmZTAwMjUwNjYzZDAgdGNwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuNTMgICAgICAgKi4q ICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmUwMDExNDE1MzEwIHVkcDQgICAgICAgMCAgICAg IDAgMTAuNS4wLjEuMTIzICAgICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZlMDAxMTQyNTkz MCB1ZHA0ICAgICAgIDAgICAgICAwIHh4eC54eHgueHh4LjUyLjUwMCAqLiogICAgICAgICAgICAg ICAgCmZmZmZmZTAwMTE0MjUwMDAgdWRwNCAgICAgICAwICAgICAgMCB4eHgueHh4LjEuMy4xMjMg ICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZlMDAxMTQyNTMxMCB1ZHA0ICAgICAgIDAgICAg ICAwIHh4eC54eHgueHh4LjUyLjEyMyAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMTE0MTVj NDAgdWRwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuMTIzICAgICAgKi4qICAgICAgICAgICAg ICAgIApmZmZmZmUwMDExNDE1N2E4IHVkcDYgICAgICAgMCAgICAgIDAgZmU4MDo4OjoxLjEyMyAg ICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZlMDAxMTQxNTE4OCB1ZHA2ICAgICAgIDAgICAg ICAwIDo6MS4xMjMgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMTE0MTU0 OTggdWRwNiAgICAgICAwICAgICAgMCB4eHh4Ong6Onh4eDp4eHhmLjEgKi4qICAgICAgICAgICAg ICAgIApmZmZmZmUwMDExNDE1NjIwIHVkcDQgICAgICAgMCAgICAgIDAgeHh4Lnh4eC4xLjIuMTIz ICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMTE0MTU5MzAgdWRwNiAgICAgICAwICAg ICAgMCB4eHh4Ong6Onh4eDp4eHhmLjEgKi4qICAgICAgICAgICAgICAgIApmZmZmZmUwMDExNDE1 YWI4IHVkcDYgICAgICAgMCAgICAgIDAgKi4xMjMgICAgICAgICAgICAgICouKiAgICAgICAgICAg ICAgICAKZmZmZmZlMDAxMTQxNWRjOCB1ZHA0ICAgICAgIDAgICAgICAwICouMTIzICAgICAgICAg ICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMTE0NTk0OTggdWRwNCAgICAgICAwICAg ICAgMCAqLjE2MSAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmUwMDExNDI1 NjIwIHVkcDQgICAgICAgMCAgICAgIDAgeHh4Lnh4eC4xLjIuMTYyICAgICAqLiogICAgICAgICAg ICAgICAgCmZmZmZmZTAwMTE0MjUxODggdWRwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuNTMg ICAgICAgKi4qICAgICAgICAgICAgICAgIApBY3RpdmUgVU5JWCBkb21haW4gc29ja2V0cwpBZGRy ZXNzICBUeXBlICAgUmVjdi1RIFNlbmQtUSAgICBJbm9kZSAgICAgQ29ubiAgICAgUmVmcyAgTmV4 dHJlZiBBZGRyCmZmZmZmZTAwMTFmMmQzYzAgc3RyZWFtICAgICAgMCAgICAgIDAgZmZmZmZlMDAy NWNjODFlMCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9kZXZkLnBpcGUKZmZm ZmZlMDAxMTlhM2E1MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDExOWEz YjQwICAgICAgICAwICAgICAgICAwCmZmZmZmZTAwMTE5YTNiNDAgc3RyZWFtICAgICAgMCAgICAg IDAgICAgICAgIDAgZmZmZmZlMDAxMTlhM2E1MCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDEx ZjE0YzMwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMTFmMTRkMjAgICAg ICAgIDAgICAgICAgIDAKZmZmZmZlMDAxMWYxNGQyMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAg ICAgMCBmZmZmZmUwMDExZjE0YzMwICAgICAgICAwICAgICAgICAwCmZmZmZmZTAwMTFmMTRlMTAg c3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAxMWYyZDAwMCAgICAgICAgMCAg ICAgICAgMApmZmZmZmUwMDExZjJkMDAwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZm ZmZmZTAwMTFmMTRlMTAgICAgICAgIDAgICAgICAgIDAKZmZmZmZlMDAxMWYxNDAwMCBzdHJlYW0g ICAgICAwICAgICAgMCBmZmZmZmUwMDExNDMzNzgwICAgICAgICAwICAgICAgICAwICAgICAgICAw IC92YXIvcnVuL25zY2QKZmZmZmZlMDAxMTQyN2QyMCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAg ICAgMCBmZmZmZmUwMDExZjEyOTYwICAgICAgICAwIGZmZmZmZTAwMTE0MjdlMTAKZmZmZmZlMDAx MWYxNGI0MCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDExZjEyODcwICAg ICAgICAwICAgICAgICAwCmZmZmZmZTAwMTE0MjdlMTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAg ICAgIDAgZmZmZmZlMDAxMWYxMjk2MCAgICAgICAgMCBmZmZmZmUwMDExZjJkMWUwCmZmZmZmZTAw MTFmMmQxZTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAxMWYxMjk2MCAg ICAgICAgMCBmZmZmZmUwMDExZjJkMmQwCmZmZmZmZTAwMTFmMmQyZDAgZGdyYW0gICAgICAgMCAg ICAgIDAgICAgICAgIDAgZmZmZmZlMDAxMWYxMjk2MCAgICAgICAgMCBmZmZmZmUwMDExZjEyNWEw CmZmZmZmZTAwMTFmMTI1YTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAx MWYxMjk2MCAgICAgICAgMCBmZmZmZmUwMDExZjE0MGYwCmZmZmZmZTAwMTFmMTQwZjAgZGdyYW0g ICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAxMWYxMjk2MCAgICAgICAgMCBmZmZmZmUw MDExZjE0MWUwCmZmZmZmZTAwMTFmMTQxZTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAg ZmZmZmZlMDAxMWYxMjk2MCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDExZjEyNzgwIGRncmFt ICAgICAgIDAgICAgICAwIGZmZmZmZTAwMTFmMmYzYzAgICAgICAgIDAgICAgICAgIDAgICAgICAg IDAgL3Zhci9uYW1lZC92YXIvcnVuL2xvZwpmZmZmZmUwMDExZjEyODcwIGRncmFtICAgICAgIDAg ICAgICAwIGZmZmZmZTAwMTFmMmY3ODAgICAgICAgIDAgZmZmZmZlMDAxMWYxNGI0MCAgICAgICAg MCAvdmFyL3J1bi9sb2cKZmZmZmZlMDAxMWYxMjk2MCBkZ3JhbSAgICAgICAwICAgICAgMCBmZmZm ZmUwMDExZjJmOTYwICAgICAgICAwIGZmZmZmZTAwMTE0MjdkMjAgICAgICAgIDAgL3Zhci9ydW4v bG9ncHJpdgpmZmZmZmUwMDExZjEyYTUwIGRncmFtICAgICAgIDAgICAgICAwIGZmZmZmZTAwMTFm MmZiNDAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vbG9nCgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KbmV0c3RhdCAtYUwKCkN1cnJlbnQgbGlzdGVuIHF1ZXVlIHNpemVzIChxbGVuL2luY3Fs ZW4vbWF4cWxlbikKUHJvdG8gTGlzdGVuICAgICAgICAgTG9jYWwgQWRkcmVzcyAgICAgICAgIAp0 Y3A0ICAwLzAvMTI4ICAgICAgICAqLjIyMjIyICAgICAgICAgICAgICAgIAp0Y3A2ICAwLzAvMTI4 ICAgICAgICAqLjIyMjIyICAgICAgICAgICAgICAgIAp0Y3A0ICAwLzAvNjQgICAgICAgICAqLnRp bWUgICAgICAgICAgICAgICAgIAp0Y3A0ICAwLzAvMTAgICAgICAgICBsb2NhbGhvc3Quc210cCAg ICAgICAgIAp0Y3A0ICAwLzAvNTAgICAgICAgICAqLmJhY3VsYS1mZCAgICAgICAgICAgIAp0Y3A0 ICAwLzAvNDA5NiAgICAgICB4eHgueHh4LjEuMi5kaXNjbG9zZSAgICAKdGNwNCAgMC8wLzQwOTYg ICAgICAgKi5odHRwcyAgICAgICAgICAgICAgICAKdGNwNCAgMC8wLzQwOTYgICAgICAgKi5odHRw ICAgICAgICAgICAgICAgICAKdGNwNCAgMC8wLzEyOCAgICAgICAgKi5zbXV4ICAgICAgICAgICAg ICAgICAKdGNwNCAgMC8wLzIgICAgICAgICAgKi5wcHRwICAgICAgICAgICAgICAgICAKdGNwNCAg MC8wLzIgICAgICAgICAgbG9jYWxob3N0LjUwMDUgICAgICAgICAKdGNwNiAgMC8wLzEyOCAgICAg ICAgbG9jYWxob3N0LnJuZGMgICAgICAgICAKdGNwNCAgMC8wLzEyOCAgICAgICAgbG9jYWxob3N0 LnJuZGMgICAgICAgICAKdGNwNCAgMC8wLzMgICAgICAgICAgbG9jYWxob3N0LmRvbWFpbiAgICAg ICAKdW5peCAgMC8wLzQgICAgICAgICAgL3Zhci9ydW4vZGV2ZC5waXBlCnVuaXggIDAvMC80MDk2 ICAgICAgIC92YXIvcnVuL25zY2QKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpmc3RhdAoKVVNFUiAgICAgQ01E ICAgICAgICAgIFBJRCAgIEZEIE1PVU5UICAgICAgSU5VTSBNT0RFICAgICAgICAgU1p8RFYgUi9X CnJvb3QgICAgIGNzaCAgICAgICAgIDIxNTggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIt eCAgICAxMDI0ICByCnJvb3QgICAgIGNzaCAgICAgICAgIDIxNTggICB3ZCAvICAgICAgICA5NTk4 NjE3NiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgY3NoICAgICAgICAgMjE1OCB0ZXh0 IC8gICAgICAgIDcxMDI2NjA1IC1yLXhyLXhyLXggIDM4MjI0OCAgcgpyb290ICAgICBjc2ggICAg ICAgICAyMTU4IGN0dHkgL2RldiAgICAgICAgMTEyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290 ICAgICBjc2ggICAgICAgICAyMTU4ICAgMTUgL2RldiAgICAgICAgMTEyIGNydy0tdy0tLS0gICBw dHMvMCBydwpyb290ICAgICBjc2ggICAgICAgICAyMTU4ICAgMTYgL2RldiAgICAgICAgMTEyIGNy dy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2ggICAgICAgICAyMTU4ICAgMTcgL2RldiAg ICAgICAgMTEyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2ggICAgICAgICAyMTU4 ICAgMTggL2RldiAgICAgICAgMTEyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2gg ICAgICAgICAyMTU4ICAgMTkgL2RldiAgICAgICAgMTEyIGNydy0tdy0tLS0gICBwdHMvMCBydwpy b290ICAgICBzc2hkICAgICAgICAyMTU2IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXgg ICAgMTAyNCAgcgpyb290ICAgICBzc2hkICAgICAgICAyMTU2ICAgd2QgLyAgICAgICAgICAgICAy IGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBzc2hkICAgICAgICAyMTU2IHRleHQgLyAg ICAgICAgNTQzNDQzMzcgLXIteHIteHIteCAgMjY5NTQ0ICByCnJvb3QgICAgIHNzaGQgICAgICAg IDIxNTYgICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAg IHNzaGQgICAgICAgIDIxNTYgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxs IHJ3CnJvb3QgICAgIHNzaGQgICAgICAgIDIxNTYgICAgMiAvZGV2ICAgICAgICAgMjIgY3J3LXJ3 LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHNzaGQgICAgICAgIDIxNTYgICAgMyogaW50ZXJuZXQg c3RyZWFtIHRjcCBmZmZmZmUwMDI1MDY3M2QwCnJvb3QgICAgIHNzaGQgICAgICAgIDIxNTYgICAg NCogcGlwZSBmZmZmZmUwMDA3ZGM4ODg4IDwtPiBmZmZmZmUwMDA3ZGM4OWUwICAgICAgMCBydwpy b290ICAgICBzc2hkICAgICAgICAyMTU2ICAgIDUqIHBpcGUgZmZmZmZlMDAwN2RjODllMCA8LT4g ZmZmZmZlMDAwN2RjODg4OCAgICAgIDAgcncKcm9vdCAgICAgc3NoZCAgICAgICAgMjE1NiAgICA2 KiBwc2V1ZG8tdGVybWluYWwgbWFzdGVyICAgICAgcHRzLzAgcncKcm9vdCAgICAgc3NoZCAgICAg ICAgMjE1NiAgICA4KiBwc2V1ZG8tdGVybWluYWwgbWFzdGVyICAgICAgcHRzLzAgcncKcm9vdCAg ICAgc3NoZCAgICAgICAgMjE1NiAgICA5KiBwc2V1ZG8tdGVybWluYWwgbWFzdGVyICAgICAgcHRz LzAgcncKcm9vdCAgICAgZGV2ZCAgICAgICAgMjExMyByb290IC8gICAgICAgICAgICAgMiBkcnd4 ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMjExMyAgIHdkIC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMjExMyB0 ZXh0IC8gICAgICAgIDg0NjcwMTg4IC1yLXhyLXhyLXggIDQ1NDE4NCAgcgpyb290ICAgICBkZXZk ICAgICAgICAyMTEzICAgIDAgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpy b290ICAgICBkZXZkICAgICAgICAyMTEzICAgIDEgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0g ICAgbnVsbCBydwpyb290ICAgICBkZXZkICAgICAgICAyMTEzICAgIDIgL2RldiAgICAgICAgIDIy IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBkZXZkICAgICAgICAyMTEzICAgIDMgL2Rl diAgICAgICAgICA0IGNydy0tLS0tLS0gIGRldmN0bCAgcgpyb290ICAgICBkZXZkICAgICAgICAy MTEzICAgIDQqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDExZjJkM2MwCnJvb3QgICAgIGRldmQgICAg ICAgIDIxMTMgICAgNSAvICAgICAgICAyMzQ0NDM4NyAtcnctLS0tLS0tICAgICAgIDQgIHcKcm9v dCAgICAgc3NoZCAgICAgICAgMjAxMSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg IDEwMjQgIHIKcm9vdCAgICAgc3NoZCAgICAgICAgMjAxMSAgIHdkIC8gICAgICAgICAgICAgMiBk cnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgc3NoZCAgICAgICAgMjAxMSB0ZXh0IC8gICAg ICAgIDU0MzQ0MzM3IC1yLXhyLXhyLXggIDI2OTU0NCAgcgpyb290ICAgICBzc2hkICAgICAgICAy MDExICAgIDAgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBz c2hkICAgICAgICAyMDExICAgIDEgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBy dwpyb290ICAgICBzc2hkICAgICAgICAyMDExICAgIDIgL2RldiAgICAgICAgIDIyIGNydy1ydy1y dy0gICAgbnVsbCBydwpyb290ICAgICBzc2hkICAgICAgICAyMDExICAgIDMqIGludGVybmV0NiBz dHJlYW0gdGNwIGZmZmZmZTAwMjUzZGFiNzAKcm9vdCAgICAgc3NoZCAgICAgICAgMjAxMSAgICA0 KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZmZTAwMjUzZGE3YTAKcm9vdCAgICAgZ2V0dHkgICAg ICAgMTkyMyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAg ICAgZ2V0dHkgICAgICAgMTkyMyAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEw MjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMyB0ZXh0IC8gICAgICAgIDU0MzQ0MDYxIC1y LXhyLXhyLXggICAyODAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTIzIGN0dHkgL2RldiAg ICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2NyBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIz ICAgIDAgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2NyBydwpyb290ICAgICBnZXR0 eSAgICAgICAxOTIzICAgIDEgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2NyBydwpy b290ICAgICBnZXR0eSAgICAgICAxOTIzICAgIDIgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0g ICB0dHl2NyBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIyIHJvb3QgLyAgICAgICAgICAgICAy IGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTIyICAgd2QgLyAg ICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAx OTIyIHRleHQgLyAgICAgICAgNTQzNDQwNjEgLXIteHIteHIteCAgIDI4MDI0ICByCnJvb3QgICAg IGdldHR5ICAgICAgIDE5MjIgY3R0eSAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXY2 IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MjIgICAgMCAvZGV2ICAgICAgICAgNDkgY3J3LS0t LS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MjIgICAgMSAvZGV2ICAgICAg ICAgNDkgY3J3LS0tLS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MjIgICAg MiAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAg ICAgIDE5MjEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3Qg ICAgIGdldHR5ICAgICAgIDE5MjEgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAx MDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDE5MjEgdGV4dCAvICAgICAgICA1NDM0NDA2MSAt ci14ci14ci14ICAgMjgwMjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMSBjdHR5IC9kZXYg ICAgICAgICA0OCBjcnctLS0tLS0tICAgdHR5djUgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTky MSAgICAwIC9kZXYgICAgICAgICA0OCBjcnctLS0tLS0tICAgdHR5djUgcncKcm9vdCAgICAgZ2V0 dHkgICAgICAgMTkyMSAgICAxIC9kZXYgICAgICAgICA0OCBjcnctLS0tLS0tICAgdHR5djUgcncK cm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMSAgICAyIC9kZXYgICAgICAgICA0OCBjcnctLS0tLS0t ICAgdHR5djUgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMCByb290IC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMCAgIHdkIC8g ICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAg MTkyMCB0ZXh0IC8gICAgICAgIDU0MzQ0MDYxIC1yLXhyLXhyLXggICAyODAyNCAgcgpyb290ICAg ICBnZXR0eSAgICAgICAxOTIwIGN0dHkgL2RldiAgICAgICAgIDQ3IGNydy0tLS0tLS0gICB0dHl2 NCBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIwICAgIDAgL2RldiAgICAgICAgIDQ3IGNydy0t LS0tLS0gICB0dHl2NCBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIwICAgIDEgL2RldiAgICAg ICAgIDQ3IGNydy0tLS0tLS0gICB0dHl2NCBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIwICAg IDIgL2RldiAgICAgICAgIDQ3IGNydy0tLS0tLS0gICB0dHl2NCBydwpyb290ICAgICBnZXR0eSAg ICAgICAxOTE5IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290 ICAgICBnZXR0eSAgICAgICAxOTE5ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAg MTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTE5IHRleHQgLyAgICAgICAgNTQzNDQwNjEg LXIteHIteHIteCAgIDI4MDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTkgY3R0eSAvZGV2 ICAgICAgICAgNDYgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5 MTkgICAgMCAvZGV2ICAgICAgICAgNDYgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJvb3QgICAgIGdl dHR5ICAgICAgIDE5MTkgICAgMSAvZGV2ICAgICAgICAgNDYgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3 CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTkgICAgMiAvZGV2ICAgICAgICAgNDYgY3J3LS0tLS0t LSAgIHR0eXYzIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTggcm9vdCAvICAgICAgICAgICAg IDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTggICB3ZCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAg IDE5MTggdGV4dCAvICAgICAgICA1NDM0NDA2MSAtci14ci14ci14ICAgMjgwMjQgIHIKcm9vdCAg ICAgZ2V0dHkgICAgICAgMTkxOCBjdHR5IC9kZXYgICAgICAgICA0NSBjcnctLS0tLS0tICAgdHR5 djIgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkxOCAgICAwIC9kZXYgICAgICAgICA0NSBjcnct LS0tLS0tICAgdHR5djIgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkxOCAgICAxIC9kZXYgICAg ICAgICA0NSBjcnctLS0tLS0tICAgdHR5djIgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkxOCAg ICAyIC9kZXYgICAgICAgICA0NSBjcnctLS0tLS0tICAgdHR5djIgcncKcm9vdCAgICAgZ2V0dHkg ICAgICAgMTkxNyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9v dCAgICAgZ2V0dHkgICAgICAgMTkxNyAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg IDEwMjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkxNyB0ZXh0IC8gICAgICAgIDU0MzQ0MDYx IC1yLXhyLXhyLXggICAyODAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTE3IGN0dHkgL2Rl diAgICAgICAgIDQ0IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBnZXR0eSAgICAgICAx OTE3ICAgIDAgL2RldiAgICAgICAgIDQ0IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBn ZXR0eSAgICAgICAxOTE3ICAgIDEgL2RldiAgICAgICAgIDQ0IGNydy0tLS0tLS0gICB0dHl2MSBy dwpyb290ICAgICBnZXR0eSAgICAgICAxOTE3ICAgIDIgL2RldiAgICAgICAgIDQ0IGNydy0tLS0t LS0gICB0dHl2MSBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTE2IHJvb3QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTE2ICAgd2Qg LyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAg ICAxOTE2IHRleHQgLyAgICAgICAgNTQzNDQwNjEgLXIteHIteHIteCAgIDI4MDI0ICByCnJvb3Qg ICAgIGdldHR5ICAgICAgIDE5MTYgY3R0eSAvZGV2ICAgICAgICAgNDMgY3J3LS0tLS0tLSAgIHR0 eXYwIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTYgICAgMCAvZGV2ICAgICAgICAgNDMgY3J3 LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTYgICAgMSAvZGV2ICAg ICAgICAgNDMgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTYg ICAgMiAvZGV2ICAgICAgICAgNDMgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGluZXRk ICAgICAgIDE4OTkgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJv b3QgICAgIGluZXRkICAgICAgIDE4OTkgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAxMDI0ICByCnJvb3QgICAgIGluZXRkICAgICAgIDE4OTkgdGV4dCAvICAgICAgICA1NDM0NDIw NiAtci14ci14ci14ICAgNDk3NzYgIHIKcm9vdCAgICAgaW5ldGQgICAgICAgMTg5OSAgICAwIC9k ZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgaW5ldGQgICAgICAg MTg5OSAgICAxIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAg aW5ldGQgICAgICAgMTg5OSAgICAyIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwg cncKcm9vdCAgICAgaW5ldGQgICAgICAgMTg5OSAgICAzIC8gICAgICAgIDIzNDQ0Mzk5IC1ydy0t LS0tLS0gICAgICAgNCAgdwpyb290ICAgICBpbmV0ZCAgICAgICAxODk5ICAgIDQqIHBpcGUgZmZm ZmZlMDAwN2RiNjJkOCA8LT4gZmZmZmZlMDAwN2RiNjQzMCAgICAgIDAgcncKcm9vdCAgICAgaW5l dGQgICAgICAgMTg5OSAgICA1KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZmZTAwMjUxY2U3YTAK cm9vdCAgICAgaW5ldGQgICAgICAgMTg5OSAgICA2KiBwaXBlIGZmZmZmZTAwMDdkYjY0MzAgPC0+ IGZmZmZmZTAwMDdkYjYyZDggICAgICAwIHJ3CnJvb3QgICAgIGNyb24gICAgICAgIDE4NDYgcm9v dCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGNyb24gICAg ICAgIDE4NDYgICB3ZCAvICAgICAgICAyMzQzNDc1OSBkcnd4ci14LS0tICAgICA1MTIgIHIKcm9v dCAgICAgY3JvbiAgICAgICAgMTg0NiB0ZXh0IC8gICAgICAgIDU0MzQ0MTUxIC1yLXhyLXhyLXgg ICA0MTQ0OCAgcgpyb290ICAgICBjcm9uICAgICAgICAxODQ2ICAgIDAgL2RldiAgICAgICAgIDIy IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9uICAgICAgICAxODQ2ICAgIDEgL2Rl diAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9uICAgICAgICAx ODQ2ICAgIDIgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBj cm9uICAgICAgICAxODQ2ICAgIDMgLyAgICAgICAgMjM0NDQzOTggLXJ3LS0tLS0tLSAgICAgICA0 ICB3CnJvb3QgICAgIGNyb24gICAgICAgIDE4NDYgICAgNSogbG9jYWwgZGdyYW0gZmZmZmZlMDAx MTQyN2QyMCA8LT4gZmZmZmZlMDAxMWYxMjk2MApzbW1zcCAgICBzZW5kbWFpbCAgICAxODQyIHJv b3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpzbW1zcCAgICBzZW5kbWFp bCAgICAxODQyICAgd2QgLyAgICAgICAgMjM0MzQ3ODIgZHJ3eHJ3eC0tLSAgICAgNTEyICByCnNt bXNwICAgIHNlbmRtYWlsICAgIDE4NDIgdGV4dCAvICAgICAgICA1NDM0NDA5NiAtci14ci1zci14 ICA3MTkyNTYgIHIKc21tc3AgICAgc2VuZG1haWwgICAgMTg0MiAgICAwIC9kZXYgICAgICAgICAy MiBjcnctcnctcnctICAgIG51bGwgIHIKc21tc3AgICAgc2VuZG1haWwgICAgMTg0MiAgICAxIC9k ZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHcKc21tc3AgICAgc2VuZG1haWwgICAg MTg0MiAgICAyIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHcKc21tc3AgICAg c2VuZG1haWwgICAgMTg0MiAgICAzKiBsb2NhbCBkZ3JhbSBmZmZmZmUwMDExZjE0YjQwIDwtPiBm ZmZmZmUwMDExZjEyODcwCnNtbXNwICAgIHNlbmRtYWlsICAgIDE4NDIgICAgNCAvICAgICAgICAy MzQ0NDM1MyAtcnctLS0tLS0tICAgICAgNTAgIHcKcm9vdCAgICAgc2VuZG1haWwgICAgMTgzOSBy b290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgc2VuZG1h aWwgICAgMTgzOSAgIHdkIC8gICAgICAgIDIzNDM0Nzc5IGRyd3hyLXhyLXggICAgIDUxMiAgcgpy b290ICAgICBzZW5kbWFpbCAgICAxODM5IHRleHQgLyAgICAgICAgNTQzNDQwOTYgLXIteHItc3It eCAgNzE5MjU2ICByCnJvb3QgICAgIHNlbmRtYWlsICAgIDE4MzkgICAgMCAvZGV2ICAgICAgICAg MjIgY3J3LXJ3LXJ3LSAgICBudWxsICByCnJvb3QgICAgIHNlbmRtYWlsICAgIDE4MzkgICAgMSAv ZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsICB3CnJvb3QgICAgIHNlbmRtYWlsICAg IDE4MzkgICAgMiAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsICB3CnJvb3QgICAg IHNlbmRtYWlsICAgIDE4MzkgICAgMyogaW50ZXJuZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1M2Ri M2QwCnJvb3QgICAgIHNlbmRtYWlsICAgIDE4MzkgICAgNCogbG9jYWwgZGdyYW0gZmZmZmZlMDAx MTQyN2UxMCA8LT4gZmZmZmZlMDAxMWYxMjk2MApyb290ICAgICBzZW5kbWFpbCAgICAxODM5ICAg IDUgLyAgICAgICAgMjM0MzQ4NTQgLXJ3LS0tLS0tLSAgICAgIDc5ICB3CnJvb3QgICAgIGJhY3Vs YS1mZCAgIDE4Mjggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJv b3QgICAgIGJhY3VsYS1mZCAgIDE4MjggICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAxMDI0ICByCnJvb3QgICAgIGJhY3VsYS1mZCAgIDE4MjggdGV4dCAvICAgICAgICA1NDQxMzYz NyAtcnd4ci14ci14ICAyMDA4MDIgIHIKcm9vdCAgICAgYmFjdWxhLWZkICAgMTgyOCAgICAwIC9k ZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHIKcm9vdCAgICAgYmFjdWxhLWZkICAg MTgyOCAgICAxIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHIKcm9vdCAgICAg YmFjdWxhLWZkICAgMTgyOCAgICAyIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwg IHIKcm9vdCAgICAgYmFjdWxhLWZkICAgMTgyOCAgICAzKiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZm ZmZmZTAwMjUyMzRiNzAKbm9ib2R5ICAgZGFya3N0YXQgICAgMTgyNSByb290IC8gICAgICAgICAg ICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKbm9ib2R5ICAgZGFya3N0YXQgICAgMTgyNSAgIHdk IC8gICAgICAgIDIzNTE1MDE2IGRyd3hyLXhyLXggICAgIDUxMiAgcgpub2JvZHkgICBkYXJrc3Rh dCAgICAxODI1IHRleHQgLyAgICAgICAgNTQ0MTQxNTUgLXIteHIteHIteCAgMTE5MDc1ICByCm5v Ym9keSAgIGRhcmtzdGF0ICAgIDE4MjUgICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAg ICBudWxsIHJ3Cm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4MjUgICAgMSAvZGV2ICAgICAgICAgMjIg Y3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4MjUgICAgMiAvZGV2 ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4 MjUgICAgMyogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMTE5YTNiNDAgPC0+IGZmZmZmZTAwMTE5YTNh NTAKbm9ib2R5ICAgZGFya3N0YXQgICAgMTgyNCByb290IC8gICAgICAgIDIzNTE1MDE2IGRyd3hy LXhyLXggICAgIDUxMiAgcgpub2JvZHkgICBkYXJrc3RhdCAgICAxODI0ICAgd2QgLyAgICAgICAg MjM1MTUwMTYgZHJ3eHIteHIteCAgICAgNTEyICByCm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4MjQg amFpbCAvICAgICAgICAyMzUxNTAxNiBkcnd4ci14ci14ICAgICA1MTIgIHIKbm9ib2R5ICAgZGFy a3N0YXQgICAgMTgyNCB0ZXh0IC8gICAgICAgIDU0NDE0MTU1IC1yLXhyLXhyLXggIDExOTA3NSAg cgpub2JvZHkgICBkYXJrc3RhdCAgICAxODI0ICAgIDAgL2RldiAgICAgICAgIDIyIGNydy1ydy1y dy0gICAgbnVsbCBydwpub2JvZHkgICBkYXJrc3RhdCAgICAxODI0ICAgIDEgL2RldiAgICAgICAg IDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpub2JvZHkgICBkYXJrc3RhdCAgICAxODI0ICAgIDIg L2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpub2JvZHkgICBkYXJrc3RhdCAg ICAxODI0ICAgIDMgL2RldiAgICAgICAgIDExIGNydy0tLS0tLS0gICAgIGJwZiBydwpub2JvZHkg ICBkYXJrc3RhdCAgICAxODI0ICAgIDcqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDExOWEzYTUwIDwt PiBmZmZmZmUwMDExOWEzYjQwCm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4MjQgICAgOCogaW50ZXJu ZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1MjM1MDAwCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTgg cm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCm5vYm9keSAgIG5naW54 ICAgICAgIDE4MTggICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCm5v Ym9keSAgIG5naW54ICAgICAgIDE4MTggdGV4dCAvICAgICAgICA1NDQyNzI0NyAtci14ci14ci14 ICA2NzEwNDAgIHIKbm9ib2R5ICAgbmdpbnggICAgICAgMTgxOCAgICAwIC9kZXYgICAgICAgICAy MiBjcnctcnctcnctICAgIG51bGwgcncKbm9ib2R5ICAgbmdpbnggICAgICAgMTgxOCAgICAxIC9k ZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKbm9ib2R5ICAgbmdpbnggICAgICAg MTgxOCAgICAyIC8gICAgICAgIDIzNDM0OTMwIC1ydy1yLS1yLS0gICAgICAgMCAgdwpub2JvZHkg ICBuZ2lueCAgICAgICAxODE4ICAgIDMqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDExZjJkMDAwIDwt PiBmZmZmZmUwMDExZjE0ZTEwCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTggICAgNCAvICAgICAg ICAyMzQzNDkzMCAtcnctci0tci0tICAgICAgIDAgIHcKbm9ib2R5ICAgbmdpbnggICAgICAgMTgx OCAgICA1IC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHcKbm9ib2R5ICAgbmdp bnggICAgICAgMTgxOCAgICA2KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZmZTAwMjUwNjZiNzAK bm9ib2R5ICAgbmdpbnggICAgICAgMTgxOCAgICA3KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZm ZTAwMjUwNjcwMDAKbm9ib2R5ICAgbmdpbnggICAgICAgMTgxOCAgIDEwKiBsb2NhbCBzdHJlYW0g ZmZmZmZlMDAxMWYxNGMzMCA8LT4gZmZmZmZlMDAxMWYxNGQyMApub2JvZHkgICBuZ2lueCAgICAg ICAxODE3IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpub2JvZHkg ICBuZ2lueCAgICAgICAxODE3ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAy NCAgcgpub2JvZHkgICBuZ2lueCAgICAgICAxODE3IHRleHQgLyAgICAgICAgNTQ0MjcyNDcgLXIt eHIteHIteCAgNjcxMDQwICByCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTcgICAgMCAvZGV2ICAg ICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm5vYm9keSAgIG5naW54ICAgICAgIDE4MTcg ICAgMSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm5vYm9keSAgIG5naW54 ICAgICAgIDE4MTcgICAgMiAvICAgICAgICAyMzQzNDkzMCAtcnctci0tci0tICAgICAgIDAgIHcK bm9ib2R5ICAgbmdpbnggICAgICAgMTgxNyAgICAzKiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAxMWYx NGQyMCA8LT4gZmZmZmZlMDAxMWYxNGMzMApub2JvZHkgICBuZ2lueCAgICAgICAxODE3ICAgIDQg LyAgICAgICAgMjM0MzQ5MzAgLXJ3LXItLXItLSAgICAgICAwICB3Cm5vYm9keSAgIG5naW54ICAg ICAgIDE4MTcgICAgNSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsICB3Cm5vYm9k eSAgIG5naW54ICAgICAgIDE4MTcgICAgNiogaW50ZXJuZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1 MDY2YjcwCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTcgICAgNyogaW50ZXJuZXQgc3RyZWFtIHRj cCBmZmZmZmUwMDI1MDY3MDAwCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTcgICAgOCogbG9jYWwg c3RyZWFtIGZmZmZmZTAwMTFmMTRlMTAgPC0+IGZmZmZmZTAwMTFmMmQwMDAKcm9vdCAgICAgbmdp bnggICAgICAgMTgxNiByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIK cm9vdCAgICAgbmdpbnggICAgICAgMTgxNiAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgIDEwMjQgIHIKcm9vdCAgICAgbmdpbnggICAgICAgMTgxNiB0ZXh0IC8gICAgICAgIDU0NDI3 MjQ3IC1yLXhyLXhyLXggIDY3MTA0MCAgcgpyb290ICAgICBuZ2lueCAgICAgICAxODE2ICAgIDAg L2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBuZ2lueCAgICAg ICAxODE2ICAgIDEgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAg ICBuZ2lueCAgICAgICAxODE2ICAgIDIgLyAgICAgICAgMjM0MzQ5MzAgLXJ3LXItLXItLSAgICAg ICAwICB3CnJvb3QgICAgIG5naW54ICAgICAgIDE4MTYgICAgMyogbG9jYWwgc3RyZWFtIGZmZmZm ZTAwMTFmMmQwMDAgPC0+IGZmZmZmZTAwMTFmMTRlMTAKcm9vdCAgICAgbmdpbnggICAgICAgMTgx NiAgICA0IC8gICAgICAgIDIzNDM0OTMwIC1ydy1yLS1yLS0gICAgICAgMCAgdwpyb290ICAgICBu Z2lueCAgICAgICAxODE2ICAgIDUgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCAg dwpyb290ICAgICBuZ2lueCAgICAgICAxODE2ICAgIDYqIGludGVybmV0IHN0cmVhbSB0Y3AgZmZm ZmZlMDAyNTA2NmI3MApyb290ICAgICBuZ2lueCAgICAgICAxODE2ICAgIDcqIGludGVybmV0IHN0 cmVhbSB0Y3AgZmZmZmZlMDAyNTA2NzAwMApyb290ICAgICBuZ2lueCAgICAgICAxODE2ICAgIDgq IGxvY2FsIHN0cmVhbSBmZmZmZmUwMDExZjE0ZTEwIDwtPiBmZmZmZmUwMDExZjJkMDAwCnJvb3Qg ICAgIG5naW54ICAgICAgIDE4MTYgICAgOSogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMTFmMTRkMjAg PC0+IGZmZmZmZTAwMTFmMTRjMzAKcm9vdCAgICAgbmdpbnggICAgICAgMTgxNiAgIDEwKiBsb2Nh bCBzdHJlYW0gZmZmZmZlMDAxMWYxNGMzMCA8LT4gZmZmZmZlMDAxMWYxNGQyMApyb290ICAgICBv cGVudnBuICAgICAxODA0IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAg cgpyb290ICAgICBvcGVudnBuICAgICAxODA0ICAgd2QgLyAgICAgICAgNTQ1NzQyOTQgZHJ3eHJ3 eHJ3eCAgICAgNTEyICByCnJvb3QgICAgIG9wZW52cG4gICAgIDE4MDQgdGV4dCAvICAgICAgICA1 NDQyNjk1NiAtci14ci14ci14ICA1MTU4MDggIHIKcm9vdCAgICAgb3BlbnZwbiAgICAgMTgwNCAg ICAwIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgb3BlbnZw biAgICAgMTgwNCAgICAxIC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0Kcm9vdCAgICAgb3Bl bnZwbiAgICAgMTgwNCAgICAyIC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0Kcm9vdCAgICAg b3BlbnZwbiAgICAgMTgwNCAgICAzKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAxMTQyNTkz MApyb290ICAgICBvcGVudnBuICAgICAxODA0ICAgIDQqIGxvY2FsIGRncmFtIGZmZmZmZTAwMTFm MmQxZTAgPC0+IGZmZmZmZTAwMTFmMTI5NjAKcm9vdCAgICAgb3BlbnZwbiAgICAgMTgwNCAgICA1 IC9kZXYgICAgICAgIDExMSBjcnctLS0tLS0tICAgIHR1bjAgcncKcm9vdCAgICAgcG93ZXJkICAg ICAgMTc4MCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAg ICAgcG93ZXJkICAgICAgMTc4MCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEw MjQgIHIKcm9vdCAgICAgcG93ZXJkICAgICAgMTc4MCB0ZXh0IC8gICAgICAgIDU0MzQ0MjkwIC1y LXhyLXhyLXggICAxNTYxNiAgcgpyb290ICAgICBwb3dlcmQgICAgICAxNzgwICAgIDAgL2RldiAg ICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBwb3dlcmQgICAgICAxNzgw ICAgIDEgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBwb3dl cmQgICAgICAxNzgwICAgIDIgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpy b290ICAgICBwb3dlcmQgICAgICAxNzgwICAgIDMgLyAgICAgICAgMjM0MzQ4MjUgLXJ3LS0tLS0t LSAgICAgICA0ICB3CnJvb3QgICAgIG50cGQgICAgICAgIDE3Nzcgcm9vdCAvICAgICAgICAgICAg IDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIG50cGQgICAgICAgIDE3NzcgICB3ZCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIG50cGQgICAgICAg IDE3NzcgdGV4dCAvICAgICAgICA1NDM0NDI3MSAtci14ci14ci14ICAzOTI0NzIgIHIKcm9vdCAg ICAgbnRwZCAgICAgICAgMTc3NyAgICAwIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51 bGwgcncKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgICAxIC9kZXYgICAgICAgICAyMiBjcnct cnctcnctICAgIG51bGwgcncKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgICAyIC9kZXYgICAg ICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAg ICAzKiBsb2NhbCBkZ3JhbSBmZmZmZmUwMDExZjJkMmQwIDwtPiBmZmZmZmUwMDExZjEyOTYwCnJv b3QgICAgIG50cGQgICAgICAgIDE3NzcgICAyMCogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZTAw MTE0MTVkYzgKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgIDIxKiBpbnRlcm5ldDYgZGdyYW0g dWRwIGZmZmZmZTAwMTE0MTVhYjgKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgIDIyKiBpbnRl cm5ldDYgZGdyYW0gdWRwIGZmZmZmZTAwMTE0MTU5MzAKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3 NyAgIDIzKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAxMTQxNTYyMApyb290ICAgICBudHBk ICAgICAgICAxNzc3ICAgMjQqIGludGVybmV0NiBkZ3JhbSB1ZHAgZmZmZmZlMDAxMTQxNTQ5OApy b290ICAgICBudHBkICAgICAgICAxNzc3ICAgMjUqIGludGVybmV0NiBkZ3JhbSB1ZHAgZmZmZmZl MDAxMTQxNTE4OApyb290ICAgICBudHBkICAgICAgICAxNzc3ICAgMjYqIGludGVybmV0NiBkZ3Jh bSB1ZHAgZmZmZmZlMDAxMTQxNTdhOApyb290ICAgICBudHBkICAgICAgICAxNzc3ICAgMjcqIGlu dGVybmV0IGRncmFtIHVkcCBmZmZmZmUwMDExNDE1YzQwCnJvb3QgICAgIG50cGQgICAgICAgIDE3 NzcgICAyOCogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZTAwMTE0MjUzMTAKcm9vdCAgICAgbnRw ZCAgICAgICAgMTc3NyAgIDI5KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAxMTQyNTAwMApy b290ICAgICBudHBkICAgICAgICAxNzc3ICAgMzAqIHJvdXRlIHJhdyAwIGZmZmZmZTAwMjUyMzgy YTgKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgIDMxKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZm ZmZlMDAxMTQxNTMxMApyb290ICAgICBuc2NkICAgICAgICAxNzc0IHJvb3QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBuc2NkICAgICAgICAxNzc0ICAgd2Qg LyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBuc2NkICAgICAg ICAxNzc0IHRleHQgLyAgICAgICAgNTQzNDQyNjggLXIteHIteHIteCAgIDc1NzI4ICByCnJvb3Qg ICAgIG5zY2QgICAgICAgIDE3NzQgICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBu dWxsIHJ3CnJvb3QgICAgIG5zY2QgICAgICAgIDE3NzQgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3 LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG5zY2QgICAgICAgIDE3NzQgICAgMiAvZGV2ICAg ICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG5zY2QgICAgICAgIDE3NzQg ICAgMyAvICAgICAgICAyMzQzNDgwMyAtcnctci0tci0tICAgICAgIDQgIHcKcm9vdCAgICAgbnNj ZCAgICAgICAgMTc3NCAgICA0KiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAxMWYxNDAwMApyb290ICAg ICBzbm1wZCAgICAgICAxNzQ1IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAy NCAgcgpyb290ICAgICBzbm1wZCAgICAgICAxNzQ1ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hy LXhyLXggICAgMTAyNCAgcgpyb290ICAgICBzbm1wZCAgICAgICAxNzQ1IHRleHQgLyAgICAgICAg NTQ0MTM5OTEgLXJ3eHIteHIteCAgIDI5MTIwICByCnJvb3QgICAgIHNubXBkICAgICAgIDE3NDUg ICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHNubXBk ICAgICAgIDE3NDUgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJv b3QgICAgIHNubXBkICAgICAgIDE3NDUgICAgMiAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAg ICBudWxsIHJ3CnJvb3QgICAgIHNubXBkICAgICAgIDE3NDUgICAgMyAvICAgICAgICAyMzQzNDk0 MSAtcnctci0tci0tICAgIDYwMzQgIHcKcm9vdCAgICAgc25tcGQgICAgICAgMTc0NSAgICA0IC9k ZXYgICAgICAgICAxNiBjcnctci0tLS0tICAgICBtZW0gIHIKcm9vdCAgICAgc25tcGQgICAgICAg MTc0NSAgICA1IC9kZXYgICAgICAgICAxNyBjcnctci0tLS0tICAgIGttZW0gIHIKcm9vdCAgICAg c25tcGQgICAgICAgMTc0NSAgICA2KiBwaXBlIGZmZmZmZTAwMDdkYzgyZDggPC0+IGZmZmZmZTAw MDdkYzg0MzAgICAgICAwIHJ3CnJvb3QgICAgIHNubXBkICAgICAgIDE3NDUgICAgNyogcGlwZSBm ZmZmZmUwMDA3ZGM4NDMwIDwtPiBmZmZmZmUwMDA3ZGM4MmQ4ICAgICAgMCBydwpyb290ICAgICBz bm1wZCAgICAgICAxNzQ1ICAgIDggLyAgICAgICAgMjM0MzQ4MjIgLXJ3LXItLS0tLSAgICAxNDQ4 ICByCnJvb3QgICAgIHNubXBkICAgICAgIDE3NDUgICAgOSogaW50ZXJuZXQgZGdyYW0gdWRwIGZm ZmZmZTAwMTE0NTk0OTgKcm9vdCAgICAgc25tcGQgICAgICAgMTc0NSAgIDEwKiBpbnRlcm5ldCBz dHJlYW0gdGNwIGZmZmZmZTAwMjUyMzUzZDAKcm9vdCAgICAgc25tcHRyYXBkICAgMTc0MSByb290 IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgc25tcHRyYXBk ICAgMTc0MSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAg ICAgc25tcHRyYXBkICAgMTc0MSB0ZXh0IC8gICAgICAgIDU0NDEzOTkzIC1yd3hyLXhyLXggICAy ODkwNCAgcgpyb290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgIDAgL2RldiAgICAgICAgIDIyIGNy dy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgIDEgL2RldiAg ICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzbm1wdHJhcGQgICAxNzQx ICAgIDIgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzbm1w dHJhcGQgICAxNzQxICAgIDMgL2RldiAgICAgICAgIDE2IGNydy1yLS0tLS0gICAgIG1lbSAgcgpy b290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgIDQgL2RldiAgICAgICAgIDE3IGNydy1yLS0tLS0g ICAga21lbSAgcgpyb290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgIDUqIHBpcGUgZmZmZmZlMDAw N2Q5NjViMCA8LT4gZmZmZmZlMDAwN2Q5NjcwOCAgICAgIDAgcncKcm9vdCAgICAgc25tcHRyYXBk ICAgMTc0MSAgICA2KiBwaXBlIGZmZmZmZTAwMDdkOTY3MDggPC0+IGZmZmZmZTAwMDdkOTY1YjAg ICAgICAwIHJ3CnJvb3QgICAgIHNubXB0cmFwZCAgIDE3NDEgICAgNyogcGlwZSBmZmZmZmUwMDA3 ZDIxYjYwIDwtPiBmZmZmZmUwMDA3ZDIxY2I4ICAgICAgMCBydwpyb290ICAgICBzbm1wdHJhcGQg ICAxNzQxICAgIDgqIHBpcGUgZmZmZmZlMDAwN2QyMWNiOCA8LT4gZmZmZmZlMDAwN2QyMWI2MCAg ICAgIDAgcncKcm9vdCAgICAgc25tcHRyYXBkICAgMTc0MSAgICA5KiBpbnRlcm5ldCBkZ3JhbSB1 ZHAgZmZmZmZlMDAxMTQyNTYyMApyb290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgMTAqIGxvY2Fs IGRncmFtIGZmZmZmZTAwMTFmMTI1YTAgPC0+IGZmZmZmZTAwMTFmMTI5NjAKcm9vdCAgICAgbmdf cXVldWUgICAgMTc0MCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIK cm9vdCAgICAgbmdfcXVldWUgICAgMTc0MCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgIDEwMjQgIHIKcm9vdCAgICAgbXBkNSAgICAgICAgMTczNCByb290IC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgbXBkNSAgICAgICAgMTczNCAgIHdkIC8g ICAgICAgIDU0NTc1MjA5IGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBtcGQ1ICAgICAg ICAxNzM0IHRleHQgLyAgICAgICAgNTQ0MjY5NTggLXIteHIteHIteCAgNjQ5NzQ0ICByCnJvb3Qg ICAgIG1wZDUgICAgICAgIDE3MzQgICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBu dWxsIHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3 LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAgMiAvZGV2ICAg ICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQg ICAgMyogbG9jYWwgZGdyYW0gZmZmZmZlMDAxMWYxNDBmMCA8LT4gZmZmZmZlMDAxMWYxMjk2MApy b290ICAgICBtcGQ1ICAgICAgICAxNzM0ICAgIDQgLyAgICAgICAgMjM0MzQ4MDAgLXJ3LXItLXIt LSAgICAgICA1IHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAgNSogbmV0Z3JhcGggZGdy YW0gMiBmZmZmZmUwMDExNDRhNTUwCnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAgNiogbmV0 Z3JhcGggZGdyYW0gMSBmZmZmZmUwMDExNDRhYWEwCnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQg ICAgNyogcGlwZSBmZmZmZmUwMDA3ZDk2MmQ4IDwtPiBmZmZmZmUwMDA3ZDk2NDMwICAgICAgMCBy dwpyb290ICAgICBtcGQ1ICAgICAgICAxNzM0ICAgIDgqIHBpcGUgZmZmZmZlMDAwN2Q5NjQzMCA8 LT4gZmZmZmZlMDAwN2Q5NjJkOCAgICAgIDAgcncKcm9vdCAgICAgbXBkNSAgICAgICAgMTczNCAg ICA5KiBuZXRncmFwaCBkZ3JhbSAyIGZmZmZmZTAwMTE0MjQ3ZjgKcm9vdCAgICAgbXBkNSAgICAg ICAgMTczNCAgIDEwKiBuZXRncmFwaCBkZ3JhbSAxIGZmZmZmZTAwMTE0NGFkNDgKcm9vdCAgICAg bXBkNSAgICAgICAgMTczNCAgIDExKiBuZXRncmFwaCBkZ3JhbSAyIGZmZmZmZTAwMTE0NTg1NTAK cm9vdCAgICAgbXBkNSAgICAgICAgMTczNCAgIDEyKiBuZXRncmFwaCBkZ3JhbSAxIGZmZmZmZTAw MTE0NTg3ZjgKcm9vdCAgICAgbXBkNSAgICAgICAgMTczNCAgIDEzKiBwaXBlIGZmZmZmZTAwMDdk ODdiNjAgPC0+IGZmZmZmZTAwMDdkODdjYjggICAgICAwIHJ3CnJvb3QgICAgIG1wZDUgICAgICAg IDE3MzQgICAxNCogcGlwZSBmZmZmZmUwMDA3ZDg3Y2I4IDwtPiBmZmZmZmUwMDA3ZDg3YjYwICAg ICAgMCBydwpyb290ICAgICBtcGQ1ICAgICAgICAxNzM0ICAgMTYqIGludGVybmV0IHN0cmVhbSB0 Y3AgZmZmZmZlMDAyNTFjZTNkMApyb290ICAgICBtcGQ1ICAgICAgICAxNzM0ICAgMTgqIHBpcGUg ZmZmZmZlMDAwN2Q4Nzg4OCA8LT4gZmZmZmZlMDAwN2Q4NzllMCAgICAgIDAgcncKcm9vdCAgICAg bXBkNSAgICAgICAgMTczNCAgIDE5KiBwaXBlIGZmZmZmZTAwMDdkODc5ZTAgPC0+IGZmZmZmZTAw MDdkODc4ODggICAgICAwIHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAyMCogaW50ZXJu ZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1MWNlMDAwCmJpbmQgICAgIG5hbWVkICAgICAgIDE2Njcg cm9vdCAvICAgICAgICAyMzQzNDc2NyBkcnd4ci14ci14ICAgICA1MTIgIHIKYmluZCAgICAgbmFt ZWQgICAgICAgMTY2NyAgIHdkIC8gICAgICAgIDIzNDM0Nzk5IGRyd3hyLXhyLXggICAgIDUxMiAg cgpiaW5kICAgICBuYW1lZCAgICAgICAxNjY3IGphaWwgLyAgICAgICAgMjM0MzQ3NjcgZHJ3eHIt eHIteCAgICAgNTEyICByCmJpbmQgICAgIG5hbWVkICAgICAgIDE2NjcgdGV4dCAvICAgICAgICA1 NDM0NDIzMCAtci14ci14ci14ICAyMjMxNjk2ICByCmJpbmQgICAgIG5hbWVkICAgICAgIDE2Njcg ICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CmJpbmQgICAgIG5hbWVk ICAgICAgIDE2NjcgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CmJp bmQgICAgIG5hbWVkICAgICAgIDE2NjcgICAgMiAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAg ICBudWxsIHJ3CmJpbmQgICAgIG5hbWVkICAgICAgIDE2NjcgICAgMyogbG9jYWwgZGdyYW0gZmZm ZmZlMDAxMWYxNDFlMCA8LT4gZmZmZmZlMDAxMWYxMjk2MApiaW5kICAgICBuYW1lZCAgICAgICAx NjY3ICAgIDQgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpiaW5kICAgICBu YW1lZCAgICAgICAxNjY3ICAgIDYqIHBpcGUgZmZmZmZlMDAwN2QyMDg4OCA8LT4gZmZmZmZlMDAw N2QyMDllMCAgICAgIDAgcncKYmluZCAgICAgbmFtZWQgICAgICAgMTY2NyAgICA4KiBwaXBlIGZm ZmZmZTAwMDdkMjA5ZTAgPC0+IGZmZmZmZTAwMDdkMjA4ODggICAgICAwIHJ3CmJpbmQgICAgIG5h bWVkICAgICAgIDE2NjcgICAxMCAvdmFyL25hbWVkL2RldiAgICAgMjYgY3J3LXJ3LXJ3LSAgcmFu ZG9tICByCmJpbmQgICAgIG5hbWVkICAgICAgIDE2NjcgICAyMCogaW50ZXJuZXQgc3RyZWFtIHRj cCBmZmZmZmUwMDI1MDY2M2QwCmJpbmQgICAgIG5hbWVkICAgICAgIDE2NjcgICAyMSogaW50ZXJu ZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1MDY2MDAwCmJpbmQgICAgIG5hbWVkICAgICAgIDE2Njcg ICAyMiogaW50ZXJuZXQ2IHN0cmVhbSB0Y3AgZmZmZmZlMDAyNTA2NjdhMApiaW5kICAgICBuYW1l ZCAgICAgICAxNjY3ICA1MTIqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmUwMDExNDI1MTg4CnJv b3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAxMDI0ICByCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgICB3ZCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgdGV4dCAvICAg ICAgICA1NDM0NDMzOSAtci14ci14ci14ICAgNDA2ODAgIHIKcm9vdCAgICAgc3lzbG9nZCAgICAg MTU4MSAgICAwIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAg c3lzbG9nZCAgICAgMTU4MSAgICAxIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwg cncKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgICAyIC9kZXYgICAgICAgICAyMiBjcnctcnct cnctICAgIG51bGwgcncKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgICAzIC8gICAgICAgIDIz NDQ0MzkxIC1ydy0tLS0tLS0gICAgICAgNCAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNTgxICAg IDQqIGxvY2FsIGRncmFtIGZmZmZmZTAwMTFmMTJhNTAKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4 MSAgICA1KiBsb2NhbCBkZ3JhbSBmZmZmZmUwMDExZjEyOTYwCnJvb3QgICAgIHN5c2xvZ2QgICAg IDE1ODEgICAgNiogbG9jYWwgZGdyYW0gZmZmZmZlMDAxMWYxMjg3MApyb290ICAgICBzeXNsb2dk ICAgICAxNTgxICAgIDcqIGxvY2FsIGRncmFtIGZmZmZmZTAwMTFmMTI3ODAKcm9vdCAgICAgc3lz bG9nZCAgICAgMTU4MSAgICA4IC9kZXYgICAgICAgICAgOSBjcnctLS0tLS0tICAgIGtsb2cgIHIK cm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgIDEwIC9kZXYgICAgICAgICAgNSBjcnctLS0tLS0t ICBjb25zb2xlICB3CnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgICAxMSAvICAgICAgICAyMzQz NDg0NiAtcnctci0tci0tICAgICAzMjAgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgIDEy IC8gICAgICAgIDIzNDM0ODMzIC1ydy0tLS0tLS0gICAgICA1OSAgdwpyb290ICAgICBzeXNsb2dk ICAgICAxNTgxICAgMTMgLyAgICAgICAgMjM0MzQ4MjYgLXJ3LS0tLS0tLSAgIDMzODIzICB3CnJv b3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgICAxNCAvICAgICAgICAyMzQzNDg4OCAtcnctci0tLS0t ICAgIDM0MzYgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgIDE1IC8gICAgICAgIDIzNDM0 ODI5IC1ydy1yLS1yLS0gICAgICA1OSAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNTgxICAgMTYg LyAgICAgICAgMjM0MzQ4MzQgLXJ3LS0tLS0tLSAgICAgIDU5ICB3CnJvb3QgICAgIHN5c2xvZ2Qg ICAgIDE1ODEgICAxNyAvICAgICAgICAyMzQzNDgzNiAtcnctLS0tLS0tICAgNzYxMDAgIHcKcm9v dCAgICAgc3lzbG9nZCAgICAgMTU4MSAgIDE4IC8gICAgICAgIDIzNDM0ODI4IC1ydy0tLS0tLS0g ICAgICA1OSAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNTgxICAgMTkgLyAgICAgICAgMjM0MzQ4 MzIgLXJ3LXItLS0tLSAgICAgIDU5ICB3CnJvb3QgICAgIGFkamtlcm50eiAgICAxNjAgcm9vdCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGFkamtlcm50eiAg ICAxNjAgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAg IGFkamtlcm50eiAgICAxNjAgdGV4dCAvICAgICAgICA4NDY3MDE3NyAtci14ci14ci14ICAgIDky NDggIHIKcm9vdCAgICAgYWRqa2VybnR6ICAgIDE2MCAgICAwIC9kZXYgICAgICAgICAyMiBjcnct cnctcnctICAgIG51bGwgcncKcm9vdCAgICAgYWRqa2VybnR6ICAgIDE2MCAgICAxIC9kZXYgICAg ICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgYWRqa2VybnR6ICAgIDE2MCAg ICAyIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgaW5pdCAg ICAgICAgICAgMSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9v dCAgICAgaW5pdCAgICAgICAgICAgMSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg IDEwMjQgIHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSB0ZXh0IC8gICAgICAgIDg0NjcwMjE0 IC1yLXhyLXhyLXggIDc5MTM4NCAgcgpyb290ICAgICBrZXJuZWwgICAgICAgICAwIHJvb3QgLyAg ICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBrZXJuZWwgICAgICAg ICAwICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgoKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCmRtZXNnCgpDb3B5cmlnaHQgKGMpIDE5OTItMjAxMiBUaGUgRnJlZUJTRCBQcm9qZWN0 LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEs IDE5OTIsIDE5OTMsIDE5OTQKCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlm b3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRl bWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNEIDkuMS1SRUxFQVNFICMwIHIy NDM4MjU6IFR1ZSBEZWMgIDQgMDk6MjM6MTAgVVRDIDIwMTIKICAgIHJvb3RAZmFycmVsbC5jc2Uu YnVmZmFsby5lZHU6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQyBhbWQ2NApDUFU6IEludGVs KFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNTQwNSAgQCAyLjAwR0h6ICgxOTk1LjA0LU1IeiBL OC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHgxMDY3NiAgRmFt aWx5ID0gNiAgTW9kZWwgPSAxNyAgU3RlcHBpbmcgPSA2CiAgRmVhdHVyZXM9MHhiZmViZmJmZjxG UFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxD TU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxU TSxQQkU+CiAgRmVhdHVyZXMyPTB4Y2UzM2Q8U1NFMyxEVEVTNjQsTU9OLERTX0NQTCxWTVgsVE0y LFNTU0UzLENYMTYseFRQUixQRENNLERDQSxTU0U0LjE+CiAgQU1EIEZlYXR1cmVzPTB4MjAwMDA4 MDA8U1lTQ0FMTCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBp bnZhcmlhbnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBtZW1vcnkgID0gNDI5NDk2NzI5 NiAoNDA5NiBNQikKYXZhaWwgbWVtb3J5ID0gNDA4NDYyOTUwNCAoMzg5NSBNQikKRXZlbnQgdGlt ZXIgIkxBUElDIiBxdWFsaXR5IDQwMApBQ1BJIEFQSUMgVGFibGU6IDxJQk0gICAgU0VSREVGTlQ+ CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwpGcmVl QlNEL1NNUDogMSBwYWNrYWdlKHMpIHggNCBjb3JlKHMpCiBjcHUwIChCU1ApOiBBUElDIElEOiAg MAogY3B1MSAoQVApOiBBUElDIElEOiAgMQogY3B1MiAoQVApOiBBUElDIElEOiAgMgogY3B1MyAo QVApOiBBUElDIElEOiAgMwppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhl cmJvYXJkCmtiZDEgYXQga2JkbXV4MAphY3BpMDogPElCTSBTRVJERUZOVD4gb24gbW90aGVyYm9h cmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAK Y3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTM6 IDxBQ1BJIENQVT4gb24gYWNwaTAKYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAweDQwLTB4NDMg aXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5 IDEwMAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzMgaXJxIDggb24g YWNwaTAKRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMApocGV0 MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAz ZmYgb24gYWNwaTAKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFs aXR5IDk1MApFdmVudCB0aW1lciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkg NDUwCkV2ZW50IHRpbWVyICJIUEVUMSIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQw CkV2ZW50IHRpbWVyICJIUEVUMiIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwClRp bWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgOTAwCmFj cGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NTg4LTB4NThi IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCnBjaWIwOiBM ZW5ndGggbWlzbWF0Y2ggZm9yIDMgcmFuZ2U6IGMwMDAwMDAwIHZzIGZmZmZmZmZmYzAwMDAwMDAK cGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKcGNpMTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBj aWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBwY2kxNgpwY2kxNzog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMC4wIG9uIHBjaTE3CnBjaTE5OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2liNDog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMTcKcGNpMTg6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDAuMyBvbiBwY2kxNgpwY2kyMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKcGNpYjY6IDxQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDMuMCBvbiBwY2kwCnBjaTM1OiA8UENJIGJ1cz4gb24gcGNp YjYKcGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNC4wIG9uIHBjaTAKcGNp NzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcKcGNpYjg6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDUuMCBvbiBwY2kwCnBjaTM0OiA8UENJIGJ1cz4gb24gcGNpYjgKcGNpYjk6IDxBQ1BJIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNi4wIG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjkKcGNpYjEwOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjAgb24gcGNpMwpw Y2k0OiA8UENJIGJ1cz4gb24gcGNpYjEwCmJjZTA6IDxCcm9hZGNvbSBOZXRYdHJlbWUgSUkgQkNN NTcwOCAxMDAwQmFzZS1UIChCMik+IG1lbSAweGM4MDAwMDAwLTB4YzlmZmZmZmYgaXJxIDE4IGF0 IGRldmljZSAwLjAgb24gcGNpNAptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmNlMApicmdwaHkwOiA8 QkNNNTcwOEMgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czAKYnJn cGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEw MDBiYXNlVCwgMTAwMGJhc2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1t YXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpiY2UwOiBFdGhlcm5ldCBhZGRyZXNzOiB4eDp4eDp4eDp4 eDp4eDoyYQpiY2UwOiBBU0lDICgweDU3MDgxMDIwKTsgUmV2IChCMik7IEJ1cyAoUENJLVgsIDY0 LWJpdCwgMTMzTUh6KTsgQi9DICg0LjAuMyk7IEJ1ZnMgKFJYOjI7VFg6MjtQRzo4KTsgRmxhZ3Mg KFNQTFR8TVNJfE1GVyk7IE1GVyAoaXBtcyAxLjYuMCkKQ29hbCAoUlg6Niw2LDE4LDE4OyBUWDoy MCwyMCw4MCw4MCkKcGNpYjExOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDcuMCBv biBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxMQphYWMwOiA8SUJNIFNlcnZlUkFJ RC04az4gcG9ydCAweDQwMDAtMHg0MGZmIG1lbSAweGNjZTAwMDAwLTB4Y2NmZmZmZmYsMHhjYWZl MDAwMC0weGNhZmZmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKYWFjMDogRW5hYmxp bmcgNjQtYml0IGFkZHJlc3Mgc3VwcG9ydAphYWMwOiBFbmFibGUgUmF3IEkvTwphYWMwOiBFbmFi bGUgNjQtYml0IGFycmF5CmFhYzA6IE5ldyBjb21tLiBpbnRlcmZhY2UgZW5hYmxlZAphYWMwOiBT ZXJ2ZVJBSUQgOGstbCAgLCBhYWMgZHJpdmVyIDIuMS45LTEKcGNpMDogPGJhc2UgcGVyaXBoZXJh bD4gYXQgZGV2aWNlIDguMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMTI6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMTIKcGNpYjEzOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjAgb24g cGNpNQpwY2k2OiA8UENJIGJ1cz4gb24gcGNpYjEzCmJjZTE6IDxCcm9hZGNvbSBOZXRYdHJlbWUg SUkgQkNNNTcwOCAxMDAwQmFzZS1UIChCMik+IG1lbSAweGNlMDAwMDAwLTB4Y2ZmZmZmZmYgaXJx IDE2IGF0IGRldmljZSAwLjAgb24gcGNpNgptaWlidXMxOiA8TUlJIGJ1cz4gb24gYmNlMQpicmdw aHkxOiA8QkNNNTcwOEMgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1 czEKYnJncGh5MTogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1G RFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VU LUZEWC1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpiY2UxOiBFdGhlcm5ldCBhZGRyZXNzOiB4eDp4 eDp4eDp4eDp4eDoyYwpiY2UxOiBBU0lDICgweDU3MDgxMDIwKTsgUmV2IChCMik7IEJ1cyAoUENJ LVgsIDY0LWJpdCwgMTMzTUh6KTsgQi9DICg0LjAuMyk7IEJ1ZnMgKFJYOjI7VFg6MjtQRzo4KTsg RmxhZ3MgKFNQTFR8TVNJfE1GVyk7IE1GVyAoaXBtcyAxLjYuMCkKQ29hbCAoUlg6Niw2LDE4LDE4 OyBUWDoyMCwyMCw4MCw4MCkKdWhjaTA6IDxJbnRlbCA2MzFYRVNCLzYzMlhFU0IvMzEwMCBVU0Ig Y29udHJvbGxlciBVU0ItMT4gcG9ydCAweDIyMDAtMHgyMjFmIGlycSAyMyBhdCBkZXZpY2UgMjku MCBvbiBwY2kwCnVzYnVzMCBvbiB1aGNpMAp1aGNpMTogPEludGVsIDYzMVhFU0IvNjMyWEVTQi8z MTAwIFVTQiBjb250cm9sbGVyIFVTQi0yPiBwb3J0IDB4MjYwMC0weDI2MWYgaXJxIDIyIGF0IGRl dmljZSAyOS4xIG9uIHBjaTAKdXNidXMxIG9uIHVoY2kxCnVoY2kyOiA8SW50ZWwgNjMxWEVTQi82 MzJYRVNCLzMxMDAgVVNCIGNvbnRyb2xsZXIgVVNCLTM+IHBvcnQgMHgyYTAwLTB4MmExZiBpcnEg MjMgYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1c2J1czIgb24gdWhjaTIKZWhjaTA6IDxJbnRlbCA2 M1hYRVNCIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjkwMDAwMDAtMHhmOTAwMDNmZiBpcnEg MjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAp1c2J1czM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMz IG9uIGVoY2kwCnBjaWIxNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9u IHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjE0CnZnYXBjaTA6IDxWR0EtY29tcGF0 aWJsZSBkaXNwbGF5PiBwb3J0IDB4MzAwMC0weDMwZmYgbWVtIDB4ZDAwMDAwMDAtMHhkN2ZmZmZm ZiwweGRmZmYwMDAwLTB4ZGZmZmZmZmYgaXJxIDIyIGF0IGRldmljZSAxLjAgb24gcGNpMQppc2Fi MDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVz PiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgNjNYWEVTQjIgVURNQTEwMCBjb250cm9sbGVyPiBw b3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4NDgwLTB4NDhmIGF0IGRl dmljZSAzMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYXRh cGNpMApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIg YXR0YWNoZWQpCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjYWZm ZiwweGNiMDAwLTB4Y2ZmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3Mg MHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+ CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAw MC0weGJmZmZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4g YXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24g YXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBwYzA6IGNhbm5v dCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmN0bDogQ0FNIFRhcmdldCBMYXllciBsb2FkZWQKcDR0 Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKcDR0Y2MxOiA8Q1BV IEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKcDR0Y2MyOiA8Q1BVIEZyZXF1ZW5j eSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTIKcDR0Y2MzOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFs IENvbnRyb2w+IG9uIGNwdTMKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpJUCBG aWx0ZXI6IHY0LjEuMjggaW5pdGlhbGl6ZWQuICBEZWZhdWx0ID0gcGFzcyBhbGwsIExvZ2dpbmcg PSBlbmFibGVkCmlwZncyICgraXB2NikgaW5pdGlhbGl6ZWQsIGRpdmVydCBsb2FkYWJsZSwgbmF0 IGxvYWRhYmxlLCBydWxlLWJhc2VkIGZvcndhcmRpbmcgZGlzYWJsZWQsIGRlZmF1bHQgdG8gYWNj ZXB0LCBsb2dnaW5nIGRpc2FibGVkCkRVTU1ZTkVUIDAgd2l0aCBJUHY2IGluaXRpYWxpemVkICgx MDA0MDkpCmxvYWRfZG5fc2NoZWQgZG5fc2NoZWQgRklGTyBsb2FkZWQKbG9hZF9kbl9zY2hlZCBk bl9zY2hlZCBRRlEgbG9hZGVkCmxvYWRfZG5fc2NoZWQgZG5fc2NoZWQgUlIgbG9hZGVkCmxvYWRf ZG5fc2NoZWQgZG5fc2NoZWQgV0YyUSsgbG9hZGVkCmxvYWRfZG5fc2NoZWQgZG5fc2NoZWQgUFJJ TyBsb2FkZWQKYWFjZDAgb24gYWFjMAphYWNkMDogOTUzNjg5TUIgKDE5NTMxNTUwNzIgc2VjdG9y cykKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czE6IDEyTWJwcyBGdWxs IFNwZWVkIFVTQiB2MS4wCnVzYnVzMjogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMz OiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdWdlbjAuMTogPEludGVsPiBhdCB1c2J1czAK dWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNidXMxCnVodWIxOiA8SW50ZWwg VUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz MQp1Z2VuMi4xOiA8SW50ZWw+IGF0IHVzYnVzMgp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPElu dGVsPiBhdCB1c2J1czMKdWh1YjM6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVo dWIzOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApjZDAgYXQgYXRhMCBi dXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8TUFUU0hJVEEgVUpEQTc4MCBEVkQvQ0RS VyBDQTIxPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgCmNkMDogMzMuMzAwTUIvcyB0 cmFuc2ZlcnMgKFVETUEyLCBBVEFQSSAxMmJ5dGVzLCBQSU8gNjU1MzRieXRlcykKY2QwOiBBdHRl bXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHBy ZXNlbnQgLSB0cmF5IGNsb3NlZApTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKU01QOiBBUCBDUFUg IzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpUaW1lY291bnRlciAiVFNDLWxv dyIgZnJlcXVlbmN5IDE1NTg2MjM4IEh6IHF1YWxpdHkgMTAwMApUcnlpbmcgdG8gbW91bnQgcm9v dCBmcm9tIHVmczovZGV2L2FhY2QwcDIgW3J3XS4uLgpXQVJOSU5HOiAvIHdhcyBub3QgcHJvcGVy bHkgZGlzbW91bnRlZApXQVJOSU5HOiAvOiBtb3VudCBwZW5kaW5nIGVycm9yOiBibG9ja3MgMCBm aWxlcyA4ClNldHRpbmcgaG9zdHV1aWQ6IDZmZTNkODRmLTgxOTItMzFjNi04MmExLWFmOTRiNGU1 MDc5ZC4KU2V0dGluZyBob3N0aWQ6IDB4M2JlZTkxMTAuCkVudHJvcHkgaGFydmVzdGluZzogaW50 ZXJydXB0cyBldGhlcm5ldCBwb2ludF90b19wb2ludCBraWNrc3RhcnQuClN0YXJ0aW5nIGZpbGUg c3lzdGVtIGNoZWNrczoKdWdlbjEuMjogPHZlbmRvciAweDA5ZGE+IGF0IHVzYnVzMQp1a2JkMDog PHZlbmRvciAweDA5ZGEgVVNCIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzIuNTAsIGFk ZHIgMj4gb24gdXNidXMxCioqIFNVK0ogUmVjb3ZlcmluZyAvZGV2L2FhY2QwcDIKKiogUmVhZGlu ZyAzMzU1NDQzMiBieXRlIGpvdXJuYWwgZnJvbSBpbm9kZSA0LgprYmQyIGF0IHVrYmQwCnVoaWQw OiA8dmVuZG9yIDB4MDlkYSBVU0IgS2V5Ym9hcmQsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMi41MCwg YWRkciAyPiBvbiB1c2J1czEKKiogQnVpbGRpbmcgcmVjb3ZlcnkgdGFibGUuCioqIFJlc29sdmlu ZyB1bnJlZmVyZW5jZWQgaW5vZGUgbGlzdC4KKiogUHJvY2Vzc2luZyBqb3VybmFsIGVudHJpZXMu CioqIDEyNiBqb3VybmFsIHJlY29yZHMgaW4gODcwNCBieXRlcyBmb3IgNDYuMzIlIHV0aWxpemF0 aW9uCioqIEZyZWVkIDEzIGlub2RlcyAoOSBkaXJzKSAwIGJsb2NrcywgYW5kIDQgZnJhZ3MuCgoq KioqKiBGSUxFIFNZU1RFTSBNQVJLRUQgQ0xFQU4gKioqKioKTW91bnRpbmcgbG9jYWwgZmlsZSBz eXN0ZW1zOi4KU2V0dGluZyBob3N0bmFtZTogbm9uYW1laG9zdC5sb2NhbC4KQWRkaXRpb25hbCBU Q1AvSVAgb3B0aW9uczogZHJvcCBTWU4rRklOIHBhY2tldHM9WUVTLgpJbnN0YWxsaW5nIE5BVCBy dWxlcy4KMCBlbnRyaWVzIGZsdXNoZWQgZnJvbSBOQVQgdGFibGUKMCBlbnRyaWVzIGZsdXNoZWQg ZnJvbSBOQVQgbGlzdApTdGFydGluZyBOZXR3b3JrOiBsbzAgYmNlMCBiY2UxIGlwZncwIHZsYW4x MSB2bGFuMjIgY2FycDAuCmxvMDogZmxhZ3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJ Q0FTVD4gbWV0cmljIDAgbXR1IDE2Mzg0CglvcHRpb25zPTYwMDAwMzxSWENTVU0sVFhDU1VNLFJY Q1NVTV9JUFY2LFRYQ1NVTV9JUFY2PgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjggCglpbmV0NiBm ZTgwOjoxJWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDggCglpbmV0IDEyNy4wLjAuMSBuZXRt YXNrIDB4ZmYwMDAwMDAgCgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FM PgpiY2UwOiBmbGFncz04OTQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFBST01JU0MsU0lNUExFWCxN VUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPWMwMWJiPFJYQ1NVTSxUWENTVU0s VkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsSlVNQk9fTVRVLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9I V1RTTyxMSU5LU1RBVEU+CglldGhlciB4eDp4eDp4eDp4eDp4eDoyYQoJaW5ldDYgeHh4eDo6eHh4 Onh4eHg6eHh4eDplYzJhJWJjZTAgcHJlZml4bGVuIDY0IHRlbnRhdGl2ZSBzY29wZWlkIDB4MSAK CWluZXQgeHh4Lnh4eC4xLjIgbmV0bWFzayAweGZmZmYwMDAwIGJyb2FkY2FzdCB4eHgueHh4LjI1 NS4yNTUKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NB TD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0IChub25lKQoJc3RhdHVzOiBubyBjYXJyaWVy CmJjZTE6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+ IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPWMwMWJiPFJYQ1NVTSxUWENTVU0sVkxBTl9NVFUs VkxBTl9IV1RBR0dJTkcsSlVNQk9fTVRVLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9IV1RTTyxMSU5L U1RBVEU+CglldGhlciB4eDp4eDp4eDp4eDp4eDoyYwoJaW5ldDYgeHh4eDo6eHh4Onh4eHg6eHh4 eDplYzJjJWJjZTEgcHJlZml4bGVuIDY0IHRlbnRhdGl2ZSBzY29wZWlkIDB4MiAKCW5kNiBvcHRp b25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhl cm5ldCBhdXRvc2VsZWN0IChub25lKQoJc3RhdHVzOiBubyBjYXJyaWVyCmlwZncwOiBmbGFncz04 ODAxPFVQLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgNjU1MzYKCW5kNiBvcHRpb25z PTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KdmxhbjExOiBmbGFncz04 ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUg MTUwMAoJb3B0aW9ucz0xMDM8UlhDU1VNLFRYQ1NVTSxUU080PgoJZXRoZXIgeHg6eHg6eHg6eHg6 eHg6MmMKCWluZXQgeHh4Lnh4eC54eHguNTIgbmV0bWFzayAweGZmZmZmZmY4IGJyb2FkY2FzdCB4 eHgueHh4Lnh4eC41NQoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9f TElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKG5vbmUpCglzdGF0dXM6IG5v IGNhcnJpZXIKCXZsYW46IDExIHBhcmVudCBpbnRlcmZhY2U6IGJjZTEKdmxhbjIyOiBmbGFncz04 MDAyPEJST0FEQ0FTVCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglldGhlciAwMDowMDow MDowMDowMDowMAoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElO S0xPQ0FMPgoJdmxhbjogMCBwYXJlbnQgaW50ZXJmYWNlOiA8bm9uZT4KY2FycDA6IGZsYWdzPTg8 TE9PUEJBQ0s+IG1ldHJpYyAwIG10dSAxNTAwCglpbmV0IHh4eC54eHguMS4zIG5ldG1hc2sgMHhm ZmZmMDAwMCAKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktM T0NBTD4KCWNhcnA6IElOSVQgdmhpZCAxIGFkdmJhc2UgMSBhZHZza2V3IDEwClN0YXJ0aW5nIGRl dmQuClN0YXJ0aW5nIE5ldHdvcms6IHVzYnVzMC4KU3RhcnRpbmcgTmV0d29yazogdXNidXMxLgpT dGFydGluZyBOZXR3b3JrOiB1c2J1czIuClN0YXJ0aW5nIE5ldHdvcms6IHVzYnVzMy4KU3RhcnRp bmcgTmV0d29yazogdmxhbjIyLgp2bGFuMjI6IGZsYWdzPTgwMDI8QlJPQURDQVNULE1VTFRJQ0FT VD4gbWV0cmljIDAgbXR1IDE1MDAKCWV0aGVyIDAwOjAwOjAwOjAwOjAwOjAwCgluZDYgb3B0aW9u cz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+Cgl2bGFuOiAwIHBhcmVu dCBpbnRlcmZhY2U6IDxub25lPgpTdGFydGluZyBOZXR3b3JrOiBjYXJwMC4KY2FycDA6IGZsYWdz PTg8TE9PUEJBQ0s+IG1ldHJpYyAwIG10dSAxNTAwCglpbmV0IHh4eC54eHguMS4zIG5ldG1hc2sg MHhmZmZmMDAwMCAKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJ TktMT0NBTD4KCWNhcnA6IElOSVQgdmhpZCAxIGFkdmJhc2UgMSBhZHZza2V3IDEwCmFkZCBuZXQg ZGVmYXVsdDogZ2F0ZXdheSB4eHgueHh4Lnh4eC40OQphZGQgbmV0IDE5Mi4xNjguMTcuMDogZ2F0 ZXdheSB4eHgueHh4LjEuMTAKYWRkIGhvc3QgeHh4Lnh4eC54eHguNTQ6IGdhdGV3YXkgeHh4Lnh4 eC4xLjExMAphZGQgbmV0IDE5Mi4xNjguMTguMDogZ2F0ZXdheSB4eHgueHh4LjEuMjAKcm91dGU6 IHdyaXRpbmcgdG8gcm91dGluZyBzb2NrZXQ6IEZpbGUgZXhpc3RzCmFkZCBuZXQgZGVmYXVsdDog Z2F0ZXdheSB4eHgueHh4Lnh4eC40OTogcm91dGUgYWxyZWFkeSBpbiB0YWJsZQpyb3V0ZTogd3Jp dGluZyB0byByb3V0aW5nIHNvY2tldDogRmlsZSBleGlzdHMKYWRkIG5ldCAxOTIuMTY4LjE3LjA6 IGdhdGV3YXkgeHh4Lnh4eC4xLjEwOiByb3V0ZSBhbHJlYWR5IGluIHRhYmxlCnJvdXRlOiB3cml0 aW5nIHRvIHJvdXRpbmcgc29ja2V0OiBGaWxlIGV4aXN0cwphZGQgaG9zdCB4eHgueHh4Lnh4eC41 NDogZ2F0ZXdheSB4eHgueHh4LjEuMTEwOiByb3V0ZSBhbHJlYWR5IGluIHRhYmxlCnJvdXRlOiB3 cml0aW5nIHRvIHJvdXRpbmcgc29ja2V0OiBGaWxlIGV4aXN0cwphZGQgbmV0IDE5Mi4xNjguMTgu MDogZ2F0ZXdheSB4eHgueHh4LjEuMjA6IHJvdXRlIGFscmVhZHkgaW4gdGFibGUKQWRkaXRpb25h bCBpbmV0IHJvdXRpbmcgb3B0aW9uczogaWdub3JlIElDTVAgcmVkaXJlY3Q9WUVTIGxvZyBJQ01Q IHJlZGlyZWN0PVlFUyBnYXRld2F5PVlFUy4KYWRkIG5ldCA6OmZmZmY6MC4wLjAuMDogZ2F0ZXdh eSA6OjEKYWRkIG5ldCA6OjAuMC4wLjA6IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmU4MDo6OiBnYXRl d2F5IDo6MQphZGQgbmV0IGZmMDI6OjogZ2F0ZXdheSA6OjEKRmlyZXdhbGwgcnVsZXMgbG9hZGVk LgpFTEYgbGRjb25maWcgcGF0aDogL2xpYiAvdXNyL2xpYiAvdXNyL2xpYi9jb21wYXQgL3Vzci9s b2NhbC9saWIKMzItYml0IGNvbXBhdGliaWxpdHkgbGRjb25maWcgcGF0aDogL3Vzci9saWIzMgpD cmVhdGluZyBhbmQvb3IgdHJpbW1pbmcgbG9nIGZpbGVzLgpTdGFydGluZyBzeXNsb2dkLgpTdGFy dGluZyBuYW1lZC4KU2V0dGluZyBkYXRlIHZpYSBudHAuCmNhcnAwOiBJTklUIC0+IEJBQ0tVUApi Y2UwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKY2FycDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0 byBET1dOCmJjZTA6IEdpZ2FiaXQgbGluayB1cCEKYmNlMTogbGluayBzdGF0ZSBjaGFuZ2VkIHRv IFVQCnZsYW4xMTogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmJjZTE6IEdpZ2FiaXQgbGluayB1 cCEKY2FycDA6IEJBQ0tVUCAtPiBNQVNURVIgKHByZWVtcHRpbmcgYSBzbG93ZXIgbWFzdGVyKQpj YXJwMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCjE5IERlYyAxNzozOToxMyBudHBkYXRlWzE2 NzBdOiBubyBzZXJ2ZXIgc3VpdGFibGUgZm9yIHN5bmNocm9uaXphdGlvbiBmb3VuZApDbGVhcmlu ZyAvdG1wLgpTdGFydGluZyBtcGQ1LgpTdGFydGluZyBzbm1wdHJhcGQuCldBUk5JTkc6IGF0dGVt cHQgdG8gZG9tYWluX2FkZChuZXRncmFwaCkgYWZ0ZXIgZG9tYWluZmluYWxpemUoKQpTdGFydGlu ZyBzbm1wZC4KVXBkYXRpbmcgbW90ZDouClN0YXJ0aW5nIG5zY2QuClN0YXJ0aW5nIG50cGQuClN0 YXJ0aW5nIHBvd2VyZC4KU3RhcnRpbmcgcnN5bmNkLgpTdGFydGluZyBvcGVudnBuLgp0dW4wOiBs aW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKYWRkIG5ldCAxMC41LjAuMDogZ2F0ZXdheSAxMC41LjAu MgpQZXJmb3JtaW5nIHNhbml0eSBjaGVjayBvbiBuZ2lueCBjb25maWd1cmF0aW9uOgpuZ2lueDog dGhlIGNvbmZpZ3VyYXRpb24gZmlsZSAvdXNyL2xvY2FsL2V0Yy9uZ2lueC9uZ2lueC5jb25mIHN5 bnRheCBpcyBvawpuZ2lueDogY29uZmlndXJhdGlvbiBmaWxlIC91c3IvbG9jYWwvZXRjL25naW54 L25naW54LmNvbmYgdGVzdCBpcyBzdWNjZXNzZnVsClN0YXJ0aW5nIG5naW54LgpTdGFydGluZyBk YXJrc3RhdC4KIDE4MjQ6IHdhcm5pbmc6IGNhbid0IGltcG9ydCBmcm9tICJkYXJrc3RhdC5kYiI6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKU3RhcnRpbmcgYmFjdWxhX2ZkLgpDb25maWd1cmlu ZyBzeXNjb25zOiBibGFua3RpbWUuClN0YXJ0aW5nIHNzaGQuClN0YXJ0aW5nIGNyb24uCi9ldGMv cmMuZC9zeXNjdGw6IFdBUk5JTkc6IHN5c2N0bCA8PDw8PDw8IGRvZXMgbm90IGV4aXN0LgovZXRj L3JjLmQvc3lzY3RsOiBXQVJOSU5HOiBzeXNjdGwgPT09PT09IGRvZXMgbm90IGV4aXN0LgovZXRj L3JjLmQvc3lzY3RsOiBXQVJOSU5HOiBzeXNjdGwgPj4+Pj4+PiBkb2VzIG5vdCBleGlzdC4KU3Rh cnRpbmcgaW5ldGQuCgpXZWQgRGVjIDE5IDE3OjM5OjE1IE1TSyAyMDEyCmFycF9wcm94eTogaWdu b3JpbmcgcmVxdWVzdCBmcm9tIDAuMC4wLjAgdmlhIGJjZTAsIGV4cGVjdGluZyB2bGFuMTEKYXJw X3Byb3h5OiBpZ25vcmluZyByZXF1ZXN0IGZyb20gMC4wLjAuMCB2aWEgYmNlMCwgZXhwZWN0aW5n IHZsYW4xMQphcnBfcHJveHk6IGlnbm9yaW5nIHJlcXVlc3QgZnJvbSAwLjAuMC4wIHZpYSBiY2Uw LCBleHBlY3RpbmcgdmxhbjExCmFycF9wcm94eTogaWdub3JpbmcgcmVxdWVzdCBmcm9tIDAuMC4w LjAgdmlhIGJjZTAsIGV4cGVjdGluZyB2bGFuMTEKCgpGYXRhbCB0cmFwIDEyOiBwYWdlIGZhdWx0 IHdoaWxlIGluIGtlcm5lbCBtb2RlCmNwdWlkID0gMzsgYXBpYyBpZCA9IDAzCmZhdWx0IHZpcnR1 YWwgYWRkcmVzcwk9IDB4MTgKZmF1bHQgY29kZQkJPSBzdXBlcnZpc29yIHJlYWQgZGF0YSwgcGFn ZSBub3QgcHJlc2VudAppbnN0cnVjdGlvbiBwb2ludGVyCT0gMHgyMDoweGZmZmZmZmZmODA5NGJj NDcKc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgxMTgyY2Q2NTAKZnJhbWUg cG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgxMTgyY2Q2YjAKY29kZSBzZWdtZW50CQk9 IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0eXBlIDB4MWIKCQkJPSBEUEwgMCwgcHJlcyAxLCBs b25nIDEsIGRlZjMyIDAsIGdyYW4gMQpwcm9jZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0IGVuYWJs ZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVudCBwcm9jZXNzCQk9IDEyIChpcnEyNTY6IGJjZTAp CnRyYXAgbnVtYmVyCQk9IDEyCnBhbmljOiBwYWdlIGZhdWx0CmNwdWlkID0gMwpLREI6IHN0YWNr IGJhY2t0cmFjZToKIzAgMHhmZmZmZmZmZjgwOTIwOGE2IGF0IGtkYl9iYWNrdHJhY2UrMHg2Ngoj MSAweGZmZmZmZmZmODA4ZWE4YmUgYXQgcGFuaWMrMHgxY2UKIzIgMHhmZmZmZmZmZjgwYmQ4MjQw IGF0IHRyYXBfZmF0YWwrMHgyOTAKIzMgMHhmZmZmZmZmZjgwYmQ4NTdkIGF0IHRyYXBfcGZhdWx0 KzB4MWVkCiM0IDB4ZmZmZmZmZmY4MGJkOGI5ZSBhdCB0cmFwKzB4M2NlCiM1IDB4ZmZmZmZmZmY4 MGJjMzE1ZiBhdCBjYWxsdHJhcCsweDgKIzYgMHhmZmZmZmZmZjgwYTA2NGQ4IGF0IGlwX2ZyYWdt ZW50KzB4MWU4CiM3IDB4ZmZmZmZmZmY4MGEwNmUxNCBhdCBpcF9vdXRwdXQrMHg2ZjQKIzggMHhm ZmZmZmZmZjgwYTAzMjQzIGF0IGlwX2ZvcndhcmQrMHgzMDMKIzkgMHhmZmZmZmZmZjgwYTA0OGRi IGF0IGlwX2lucHV0KzB4NWFiCiMxMCAweGZmZmZmZmZmODA5YWRhZmIgYXQgbmV0aXNyX2Rpc3Bh dGNoX3NyYysweDIwYgojMTEgMHhmZmZmZmZmZjgwOWEzNWNkIGF0IGV0aGVyX2RlbXV4KzB4MTRk CiMxMiAweGZmZmZmZmZmODA5YTM4YTQgYXQgZXRoZXJfbmhfaW5wdXQrMHgxZjQKIzEzIDB4ZmZm ZmZmZmY4MDlhZGFmYiBhdCBuZXRpc3JfZGlzcGF0Y2hfc3JjKzB4MjBiCiMxNCAweGZmZmZmZmZm ODA0MzhmZDcgYXQgYmNlX2ludHIrMHg0ODcKIzE1IDB4ZmZmZmZmZmY4MDhiZThkNCBhdCBpbnRy X2V2ZW50X2V4ZWN1dGVfaGFuZGxlcnMrMHgxMDQKIzE2IDB4ZmZmZmZmZmY4MDhjMDA3NiBhdCBp dGhyZWFkX2xvb3ArMHhhNgojMTcgMHhmZmZmZmZmZjgwOGJiOWVmIGF0IGZvcmtfZXhpdCsweDEx ZgpVcHRpbWU6IDUzbTE4cwpEdW1waW5nIDMzNiBvdXQgb2YgNDA3NCBNQjouLjUlLi4xNSUuLjI0 JS4uMzQlLi40MyUuLjUzJS4uNjIlLi43MiUuLjgxJS4uOTElCgotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Ka2Vy bmVsIGNvbmZpZwoKb3B0aW9ucwlDT05GSUdfQVVUT0dFTkVSQVRFRAppZGVudAlHRU5FUklDCm1h Y2hpbmUJYW1kNjQKY3B1CUhBTU1FUgptYWtlb3B0aW9ucwlERUJVRz0tZwpvcHRpb25zCVVTQl9E RUJVRwpvcHRpb25zCUFIX1NVUFBPUlRfQVI1NDE2Cm9wdGlvbnMJSUVFRTgwMjExX1NVUFBPUlRf TUVTSApvcHRpb25zCUlFRUU4MDIxMV9BTVBEVV9BR0UKb3B0aW9ucwlJRUVFODAyMTFfREVCVUcK b3B0aW9ucwlTQ19QSVhFTF9NT0RFCm9wdGlvbnMJVkVTQQpvcHRpb25zCUFIRF9SRUdfUFJFVFRZ X1BSSU5UCm9wdGlvbnMJQUhDX1JFR19QUkVUVFlfUFJJTlQKb3B0aW9ucwlBVEFfU1RBVElDX0lE Cm9wdGlvbnMJQVRBX0NBTQpvcHRpb25zCVNNUApvcHRpb25zCUtEQl9UUkFDRQpvcHRpb25zCUtE QgpvcHRpb25zCUlOQ0xVREVfQ09ORklHX0ZJTEUKb3B0aW9ucwlNQUMKb3B0aW9ucwlBVURJVApv cHRpb25zCUhXUE1DX0hPT0tTCm9wdGlvbnMJS0JEX0lOU1RBTExfQ0RFVgpvcHRpb25zCVBSSU5U Rl9CVUZSX1NJWkU9MTI4Cm9wdGlvbnMJX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HCm9wdGlv bnMJU1lTVlNFTQpvcHRpb25zCVNZU1ZNU0cKb3B0aW9ucwlTWVNWU0hNCm9wdGlvbnMJU1RBQ0sK b3B0aW9ucwlLVFJBQ0UKb3B0aW9ucwlTQ1NJX0RFTEFZPTUwMDAKb3B0aW9ucwlDT01QQVRfRlJF RUJTRDcKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDYKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDUKb3B0 aW9ucwlDT01QQVRfRlJFRUJTRDQKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDMyCm9wdGlvbnMJR0VP TV9MQUJFTApvcHRpb25zCUdFT01fUkFJRApvcHRpb25zCUdFT01fUEFSVF9HUFQKb3B0aW9ucwlQ U0VVRE9GUwpvcHRpb25zCVBST0NGUwpvcHRpb25zCUNEOTY2MApvcHRpb25zCU1TRE9TRlMKb3B0 aW9ucwlORlNfUk9PVApvcHRpb25zCU5GU0xPQ0tECm9wdGlvbnMJTkZTRApvcHRpb25zCU5GU0NM Cm9wdGlvbnMJTURfUk9PVApvcHRpb25zCVVGU19HSk9VUk5BTApvcHRpb25zCVVGU19ESVJIQVNI Cm9wdGlvbnMJVUZTX0FDTApvcHRpb25zCVNPRlRVUERBVEVTCm9wdGlvbnMJRkZTCm9wdGlvbnMJ U0NUUApvcHRpb25zCUlORVQ2Cm9wdGlvbnMJSU5FVApvcHRpb25zCVBSRUVNUFRJT04Kb3B0aW9u cwlTQ0hFRF9VTEUKb3B0aW9ucwlORVdfUENJQgpvcHRpb25zCUdFT01fUEFSVF9NQlIKb3B0aW9u cwlHRU9NX1BBUlRfRUJSX0NPTVBBVApvcHRpb25zCUdFT01fUEFSVF9FQlIKb3B0aW9ucwlHRU9N X1BBUlRfQlNECmRldmljZQlpc2EKZGV2aWNlCW1lbQpkZXZpY2UJaW8KZGV2aWNlCXVhcnRfbnM4 MjUwCmRldmljZQljcHVmcmVxCmRldmljZQlhY3BpCmRldmljZQlwY2kKZGV2aWNlCWZkYwpkZXZp Y2UJYWhjaQpkZXZpY2UJYXRhCmRldmljZQltdnMKZGV2aWNlCXNpaXMKZGV2aWNlCWFoYwpkZXZp Y2UJYWhkCmRldmljZQllc3AKZGV2aWNlCWhwdGlvcApkZXZpY2UJaXNwCmRldmljZQltcHQKZGV2 aWNlCW1wcwpkZXZpY2UJc3ltCmRldmljZQl0cm0KZGV2aWNlCWFkdgpkZXZpY2UJYWR3CmRldmlj ZQlhaWMKZGV2aWNlCWJ0CmRldmljZQlpc2NpCmRldmljZQlzY2J1cwpkZXZpY2UJY2gKZGV2aWNl CWRhCmRldmljZQlzYQpkZXZpY2UJY2QKZGV2aWNlCXBhc3MKZGV2aWNlCXNlcwpkZXZpY2UJY3Rs CmRldmljZQlhbXIKZGV2aWNlCWFyY21zcgpkZXZpY2UJY2lzcwpkZXZpY2UJZHB0CmRldmljZQlo cHRtdgpkZXZpY2UJaHB0cnIKZGV2aWNlCWlpcgpkZXZpY2UJaXBzCmRldmljZQltbHkKZGV2aWNl CXR3YQpkZXZpY2UJdHdzCmRldmljZQlhYWMKZGV2aWNlCWFhY3AKZGV2aWNlCWlkYQpkZXZpY2UJ bWZpCmRldmljZQltbHgKZGV2aWNlCXR3ZQpkZXZpY2UJYXRrYmRjCmRldmljZQlhdGtiZApkZXZp Y2UJcHNtCmRldmljZQlrYmRtdXgKZGV2aWNlCXZnYQpkZXZpY2UJc3BsYXNoCmRldmljZQlzYwpk ZXZpY2UJYWdwCmRldmljZQljYmIKZGV2aWNlCXBjY2FyZApkZXZpY2UJY2FyZGJ1cwpkZXZpY2UJ dWFydApkZXZpY2UJcHBjCmRldmljZQlwcGJ1cwpkZXZpY2UJbHB0CmRldmljZQlwbGlwCmRldmlj ZQlwcGkKZGV2aWNlCXB1YwpkZXZpY2UJYnhlCmRldmljZQlkZQpkZXZpY2UJZW0KZGV2aWNlCWln YgpkZXZpY2UJaXhnYmUKZGV2aWNlCWxlCmRldmljZQl0aQpkZXZpY2UJdHhwCmRldmljZQl2eApk ZXZpY2UJbWlpYnVzCmRldmljZQlhZQpkZXZpY2UJYWdlCmRldmljZQlhbGMKZGV2aWNlCWFsZQpk ZXZpY2UJYmNlCmRldmljZQliZmUKZGV2aWNlCWJnZQpkZXZpY2UJY2FzCmRldmljZQlkYwpkZXZp Y2UJZXQKZGV2aWNlCWZ4cApkZXZpY2UJZ2VtCmRldmljZQlobWUKZGV2aWNlCWptZQpkZXZpY2UJ bGdlCmRldmljZQltc2sKZGV2aWNlCW5mZQpkZXZpY2UJbmdlCmRldmljZQlwY24KZGV2aWNlCXJl CmRldmljZQlybApkZXZpY2UJc2YKZGV2aWNlCXNnZQpkZXZpY2UJc2lzCmRldmljZQlzawpkZXZp Y2UJc3RlCmRldmljZQlzdGdlCmRldmljZQl0bApkZXZpY2UJdHgKZGV2aWNlCXZnZQpkZXZpY2UJ dnIKZGV2aWNlCXdiCmRldmljZQl4bApkZXZpY2UJY3MKZGV2aWNlCWVkCmRldmljZQlleApkZXZp Y2UJZXAKZGV2aWNlCWZlCmRldmljZQlzbgpkZXZpY2UJeGUKZGV2aWNlCXdsYW4KZGV2aWNlCXds YW5fd2VwCmRldmljZQl3bGFuX2NjbXAKZGV2aWNlCXdsYW5fdGtpcApkZXZpY2UJd2xhbl9hbXJy CmRldmljZQlhbgpkZXZpY2UJYXRoCmRldmljZQlhdGhfcGNpCmRldmljZQlhdGhfaGFsCmRldmlj ZQlhdGhfcmF0ZV9zYW1wbGUKZGV2aWNlCWlwdwpkZXZpY2UJaXdpCmRldmljZQlpd24KZGV2aWNl CW1hbG8KZGV2aWNlCW13bApkZXZpY2UJcmFsCmRldmljZQl3aQpkZXZpY2UJd3BpCmRldmljZQls b29wCmRldmljZQlyYW5kb20KZGV2aWNlCWV0aGVyCmRldmljZQl2bGFuCmRldmljZQl0dW4KZGV2 aWNlCXB0eQpkZXZpY2UJbWQKZGV2aWNlCWdpZgpkZXZpY2UJZmFpdGgKZGV2aWNlCWZpcm13YXJl CmRldmljZQlicGYKZGV2aWNlCXVoY2kKZGV2aWNlCW9oY2kKZGV2aWNlCWVoY2kKZGV2aWNlCXho Y2kKZGV2aWNlCXVzYgpkZXZpY2UJdWhpZApkZXZpY2UJdWtiZApkZXZpY2UJdWxwdApkZXZpY2UJ dW1hc3MKZGV2aWNlCXVtcwpkZXZpY2UJdXJpbwpkZXZpY2UJdTNnCmRldmljZQl1YXJrCmRldmlj ZQl1YnNhCmRldmljZQl1ZnRkaQpkZXZpY2UJdWlwYXEKZGV2aWNlCXVwbGNvbQpkZXZpY2UJdXNs Y29tCmRldmljZQl1dmlzb3IKZGV2aWNlCXV2c2NvbQpkZXZpY2UJYXVlCmRldmljZQlheGUKZGV2 aWNlCWNkY2UKZGV2aWNlCWN1ZQpkZXZpY2UJa3VlCmRldmljZQlydWUKZGV2aWNlCXVkYXYKZGV2 aWNlCXJ1bQpkZXZpY2UJcnVuCmRldmljZQl1YXRoCmRldmljZQl1cGd0CmRldmljZQl1cmFsCmRl dmljZQl1cnR3CmRldmljZQl6eWQKZGV2aWNlCWZpcmV3aXJlCmRldmljZQlmd2UKZGV2aWNlCWZ3 aXAKZGV2aWNlCWRjb25zCmRldmljZQlkY29uc19jcm9tCmRldmljZQlzb3VuZApkZXZpY2UJc25k X2NtaQpkZXZpY2UJc25kX2NzYQpkZXZpY2UJc25kX2VtdTEwa3gKZGV2aWNlCXNuZF9lczEzN3gK ZGV2aWNlCXNuZF9oZGEKZGV2aWNlCXNuZF9pY2gKZGV2aWNlCXNuZF91YXVkaW8KZGV2aWNlCXNu ZF92aWE4MjMzCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZGRiIGNhcHR1cmUgYnVmZmVyCgpkZGI6IGRkYl9j YXB0dXJlOiBrdm1fbmxpc3QK --MP_/QvrSkd_9U6t7dWNNEYJSCCL-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 05:38:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 158E8C1A; Sat, 12 Jan 2013 05:38:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9FAAC682; Sat, 12 Jan 2013 05:38:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0C5cuMX035326; Sat, 12 Jan 2013 00:38:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0C5cuOj035322; Sat, 12 Jan 2013 05:38:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Jan 2013 05:38:56 GMT Message-Id: <201301120538.r0C5cuOj035322@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 05:38:58 -0000 TB --- 2013-01-12 04:00:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-12 04:00:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-12 04:00:16 - starting HEAD tinderbox run for i386/i386 TB --- 2013-01-12 04:00:16 - cleaning the object tree TB --- 2013-01-12 04:02:39 - /usr/local/bin/svn stat /src TB --- 2013-01-12 04:02:42 - At svn revision 245321 TB --- 2013-01-12 04:02:43 - building world TB --- 2013-01-12 04:02:43 - CROSS_BUILD_TESTING=YES TB --- 2013-01-12 04:02:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-12 04:02:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-12 04:02:43 - SRCCONF=/dev/null TB --- 2013-01-12 04:02:43 - TARGET=i386 TB --- 2013-01-12 04:02:43 - TARGET_ARCH=i386 TB --- 2013-01-12 04:02:43 - TZ=UTC TB --- 2013-01-12 04:02:43 - __MAKE_CONF=/dev/null TB --- 2013-01-12 04:02:43 - cd /src TB --- 2013-01-12 04:02:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jan 12 04:02:48 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ^~~~~~~~~~~~~~~~~~~~~~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~~~~~~~~~~~~~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-12 05:38:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-12 05:38:56 - ERROR: failed to build world TB --- 2013-01-12 05:38:56 - 4751.02 user 720.77 system 5919.77 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 05:39:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 12A47D37; Sat, 12 Jan 2013 05:39:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B2B8668A; Sat, 12 Jan 2013 05:39:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0C5dCOp036381; Sat, 12 Jan 2013 00:39:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0C5dCG2036376; Sat, 12 Jan 2013 05:39:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Jan 2013 05:39:12 GMT Message-Id: <201301120539.r0C5dCG2036376@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 05:39:14 -0000 TB --- 2013-01-12 04:00:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-12 04:00:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-12 04:00:16 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-01-12 04:00:16 - cleaning the object tree TB --- 2013-01-12 04:02:39 - /usr/local/bin/svn stat /src TB --- 2013-01-12 04:02:42 - At svn revision 245321 TB --- 2013-01-12 04:02:43 - building world TB --- 2013-01-12 04:02:43 - CROSS_BUILD_TESTING=YES TB --- 2013-01-12 04:02:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-12 04:02:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-12 04:02:43 - SRCCONF=/dev/null TB --- 2013-01-12 04:02:43 - TARGET=amd64 TB --- 2013-01-12 04:02:43 - TARGET_ARCH=amd64 TB --- 2013-01-12 04:02:43 - TZ=UTC TB --- 2013-01-12 04:02:43 - __MAKE_CONF=/dev/null TB --- 2013-01-12 04:02:43 - cd /src TB --- 2013-01-12 04:02:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jan 12 04:02:47 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ^~~~~~~~~~~~~~~~~~~~~~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~~~~~~~~~~~~~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-12 05:39:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-12 05:39:12 - ERROR: failed to build world TB --- 2013-01-12 05:39:12 - 4757.20 user 718.62 system 5936.28 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 06:55:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D286E54A; Sat, 12 Jan 2013 06:55:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 790B3828; Sat, 12 Jan 2013 06:55:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0C6tuvP083174; Sat, 12 Jan 2013 01:55:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0C6tu3I083170; Sat, 12 Jan 2013 06:55:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 12 Jan 2013 06:55:56 GMT Message-Id: <201301120655.r0C6tu3I083170@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 06:55:57 -0000 TB --- 2013-01-12 05:11:55 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-12 05:11:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-12 05:11:55 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-01-12 05:11:55 - cleaning the object tree TB --- 2013-01-12 05:12:31 - /usr/local/bin/svn stat /src TB --- 2013-01-12 05:12:34 - At svn revision 245321 TB --- 2013-01-12 05:12:35 - building world TB --- 2013-01-12 05:12:35 - CROSS_BUILD_TESTING=YES TB --- 2013-01-12 05:12:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-12 05:12:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-12 05:12:35 - SRCCONF=/dev/null TB --- 2013-01-12 05:12:35 - TARGET=pc98 TB --- 2013-01-12 05:12:35 - TARGET_ARCH=i386 TB --- 2013-01-12 05:12:35 - TZ=UTC TB --- 2013-01-12 05:12:35 - __MAKE_CONF=/dev/null TB --- 2013-01-12 05:12:35 - cd /src TB --- 2013-01-12 05:12:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jan 12 05:12:39 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ^~~~~~~~~~~~~~~~~~~~~~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~~~~~~~~~~~~~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-12 06:55:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-12 06:55:56 - ERROR: failed to build world TB --- 2013-01-12 06:55:56 - 5019.60 user 801.84 system 6240.99 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 12:49:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1202089A for ; Sat, 12 Jan 2013 12:49:16 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [IPv6:2a02:6b8:0:f05::5]) by mx1.freebsd.org (Postfix) with ESMTP id B654974D for ; Sat, 12 Jan 2013 12:49:15 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 1D5E4D01635 for ; Sat, 12 Jan 2013 16:49:14 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id EC88E13402D0 for ; Sat, 12 Jan 2013 16:49:13 +0400 (MSK) Received: from 93.91.2.63.tel.ru (93.91.2.63.tel.ru [93.91.2.63]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id nD0CvlB0-nD003A01; Sat, 12 Jan 2013 16:49:13 +0400 Message-ID: <50F15BC9.6030100@passap.ru> Date: Sat, 12 Jan 2013 16:49:13 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: The line "World build completed on..." disappeared from the build log Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 12:49:16 -0000 Hi All, not so far (a week or two?) the line with starting date and time of the world build has disappeared. That seems to be unintentional because the corresponding "stop" line is there. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 12:55:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 31F23A3F for ; Sat, 12 Jan 2013 12:55:22 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward4h.mail.yandex.net (forward4h.mail.yandex.net [IPv6:2a02:6b8:0:f05::4]) by mx1.freebsd.org (Postfix) with ESMTP id D37CF7A3 for ; Sat, 12 Jan 2013 12:55:21 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward4h.mail.yandex.net (Yandex) with ESMTP id EF2231B21986 for ; Sat, 12 Jan 2013 16:55:19 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id BE36D2C02A7 for ; Sat, 12 Jan 2013 16:55:19 +0400 (MSK) Received: from 93.91.2.63.tel.ru (93.91.2.63.tel.ru [93.91.2.63]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id tJHKTBmF-tJHu94UF; Sat, 12 Jan 2013 16:55:19 +0400 Message-ID: <50F15D37.90403@passap.ru> Date: Sat, 12 Jan 2013 16:55:19 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: the line moved down (was: The line "World build completed on..." disappeared from the build log) References: <50F15BC9.6030100@passap.ru> In-Reply-To: <50F15BC9.6030100@passap.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 12:55:22 -0000 12.01.2013 16:49, Boris Samorodov пишет: > Hi All, > > not so far (a week or two?) the line with starting date > and time of the world build has disappeared. That seems > to be unintentional because the corresponding "stop" line > is there. Hm, sorry, the line happen to be the first one and now it appears a little bit later. Was this move intentional? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 18:29:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0DDBFAAC; Sat, 12 Jan 2013 18:29:45 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by mx1.freebsd.org (Postfix) with ESMTP id A7D5733E; Sat, 12 Jan 2013 18:29:44 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id fb10so1562847pad.16 for ; Sat, 12 Jan 2013 10:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer; bh=Luv0bP3hT64WPZzpSiq1/GfkEhPKHRzwuDqqxKe/EqM=; b=IbG2cfj2REB44rZZFxI7T2+kQ/8vgq+BWkBV9BzZCd1EaezvgJmkbasN0orTdVbSLn o3dcK4psqN9vUg1U5O3wSMXGxqWWVCxoHLUl63XhszmJZLuigWAUrqKAwDY3pmWIyd3X DxC4g3PXeA1R5blpRlmZb8th4ZQ7cBRaBLzFT7KEf/g+WDq/QqOhU1sCW/g7qqp7sEgC He/7c8DTg5KMcxH5Ap1Kshehn7F33dRbMk9reXYNDOWiO9AJ/Eh++eyEtvaDlfTb0t58 ZURSIKqb3HUm+vROZJFtd5QCFLpZmSDTThPr5Nj6zGMOi2VyojQXlGWrGgHIAyz9AbZq a49A== X-Received: by 10.66.83.6 with SMTP id m6mr217734345pay.52.1358015383959; Sat, 12 Jan 2013 10:29:43 -0800 (PST) Received: from [192.168.1.128] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id vo6sm4978200pbc.8.2013.01.12.10.29.42 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 12 Jan 2013 10:29:42 -0800 (PST) Subject: Re: Fixing clang warnings in hwpmc From: Sean Bruno To: hiren panchasara In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xsrGALxN+j750vre9u6g" Date: Sat, 12 Jan 2013 10:29:40 -0800 Message-ID: <1358015380.81432.0.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-current , Fabien Thomas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 18:29:45 -0000 --=-xsrGALxN+j750vre9u6g Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2013-01-07 at 16:34 -0800, hiren panchasara wrote:=20 > http://www.strugglingcoder.info/patches/hwpmc_clang_warnings.txt >=20 > A trivial patch to fix a couple of clang warnings. >=20 > Thanks, > Hiren Ack. compiles good. Commit in progress. Sean=20 --=-xsrGALxN+j750vre9u6g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJQ8auUAAoJEBkJRdwI6BaHdbcIAIiO9WMOco2vHMDpwH4yzY3D zdw6GXf3Te/VA4GaWyFg2W/KsYyuQzRU8YncdHI8ViiVa7ZuvFptUXle4DRmUDp8 SanpPwmG59Tksrew/rXGu8g8taz2+qWq6x2vxUkaEqlesqiYUczzW7NADMSGLPoX VjunYinuYkQE7YDIYjXBwLHtnKE+inddrSM0y4eGxT1HSc+l2nVLeDfN8nsQVRfq OEb3ylMydrpYZ26Sm21fzykwL0mHWvOxjUSE3SwmtkkMVau2wktzABtsUYHPqlPA Ojov33Mwy3ws3CCgm9c7N7COffLN9nNpiFLE55Al405f9t+g72sSL7CitqP1YOA= =f3Kv -----END PGP SIGNATURE----- --=-xsrGALxN+j750vre9u6g-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 12 21:11:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B5428CF3 for ; Sat, 12 Jan 2013 21:11:23 +0000 (UTC) (envelope-from xenophon+freebsd@irtnog.org) Received: from mx1.irtnog.org (rrcs-24-123-13-61.central.biz.rr.com [24.123.13.61]) by mx1.freebsd.org (Postfix) with ESMTP id 619B398F for ; Sat, 12 Jan 2013 21:11:22 +0000 (UTC) Received: from cinep001bsdgw.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id 02EBA1ADCC for ; Sat, 12 Jan 2013 16:11:21 -0500 (EST) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by cinep001bsdgw.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxWMD7csdPqu for ; Sat, 12 Jan 2013 16:11:19 -0500 (EST) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP for ; Sat, 12 Jan 2013 16:11:19 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Expanding ZFS RAIDZ on the fly? Date: Sat, 12 Jan 2013 16:11:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <20130111233428.GA54865@in-addr.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expanding ZFS RAIDZ on the fly? thread-index: Ac3wVEE7zwhwNePjSYK1XbPSVQQkXwAtIGpA References: <50EFBAEA.3070200@zedat.fu-berlin.de> <20130111140557.GA63102@psconsult.nl> <20130111233428.GA54865@in-addr.com> From: "xenophon\\+freebsd" To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 21:11:23 -0000 > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Gary Palmer > Sent: Friday, January 11, 2013 6:34 PM >=20 > BPR doesn't look likely, unfortunately. I wonder how other SANs implement restriping. The HP P4000/P4500 can restripe logical units, and it even maintains data redundancy in the process. --=20 I FIGHT FOR THE USERS