From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 8 00:39:25 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 172CC4BF; Sun, 8 Mar 2015 00:39:25 +0000 (UTC) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 836FBBE8; Sun, 8 Mar 2015 00:39:24 +0000 (UTC) X-AuditID: 12074423-f79066d0000058b8-52-54fb9907d6b3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C8.59.22712.7099BF45; Sat, 7 Mar 2015 19:34:15 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t280YEf8006968; Sat, 7 Mar 2015 19:34:15 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t280YC2M007264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Mar 2015 19:34:14 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t280YCON025506; Sat, 7 Mar 2015 19:34:12 -0500 (EST) Date: Sat, 7 Mar 2015 19:34:12 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org Subject: Call for FreeBSD 2015Q1 (January-March) Status Reports Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrMs+83eIwebjmha7rp1mt5jz5gOT xfbN/xgdmD1mfJrPEsAYxWWTkpqTWZZapG+XwJWxbeNX1oKzXBWzm6eyNjA+4+hi5OSQEDCR OLb1JiOELSZx4d56ti5GLg4hgcVMEs0TzjBBOBsYJR71bGeEcA4ySXz7O48FpEVIoF5iy481 zCA2i4CWxOU7p5lAbDYBNYnHe5tZIcYqSmw+NQmohoNDREBeYsF5e5AwM5D5/8plsHJhAXuJ prM32UFsXgEHiVVvv4NdJCqgI7F6/xQWiLigxMmZT1ggerUklk/fxjKBUWAWktQsJKkFjEyr GGVTcqt0cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJTSjcxggKS3UV5B+Ofg0qHGAU4GJV4eCfM +BUixJpYVlyZe4hRkoNJSZS3I+x3iBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3u/eQDnelMTK qtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQnehulAjYJFqempFWmZOSUIaSYO TpDhPEDDL4PU8BYXJOYWZ6ZD5E8xKkqJ824FSQiAJDJK8+B6YQnjFaM40CvCvAwzgKp4gMkG rvsV0GAmoMFaYj9ABpckIqSkGhg1EmcsydK0SzosZGpYvVh+05Gr31mf3U2fqVyqbloumVPE oDvRZIFYzc7cExZT93+8dCL/gf/6/kcHX7P/jPjF6jA1Y5MB0+duH42fBml2Jku9Mgz4vj3f u2a5kEHmvUtr9aZbsWm6nfknz+C4M1jVs63gqFPwjEmvtv3ZU2rcsCDj8m6JWa5KLMUZiYZa zEXFiQBKeswQ8wIAAA== Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 00:39:25 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is April 7, 2015, for work done in January through March. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly at freebsd.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2015Q1 reports! Thanks, Ben (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-07-2014-09.html [5] http://www.freebsd.org/news/status/report-2014-10-2014-12.html From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 8 13:03:35 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 100B8BAE for ; Sun, 8 Mar 2015 13:03:35 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83805C59 for ; Sun, 8 Mar 2015 13:03:34 +0000 (UTC) Received: by labgd6 with SMTP id gd6so18900764lab.3 for ; Sun, 08 Mar 2015 06:03:32 -0700 (PDT) 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=FHD4FpZKyJfL4T85mstRW2zpT9l4cGHGIKlN357Qj88=; b=InPHh7gwlLqT0O/uAsx9hiWnT3xrsMgLRLDZLONCXdAULEP4vGwga2ZF+vgcv7jhV6 kOeCviy7xwTnPUTa8cex7/0sTMZ41eYv2W5n4umTKA+1JgtT7ZwIJP2tIAEOUFTRveqH bF1YGkiszNhv9mRektuQtMeYtN4378a+nWqzY35IRJ9f7eH8wtgHtzRZxB5X9orbM1jo FGTc293Xd6tyyTPtHeYlnX7xu2oP8Fr/rN5Ogg3BVKbC7aD7vnjNz9kCo3HfGeQexhgZ 6QFn0YHPj2Vnqx6BG1BfPQqaJHrJWsic/Omxx/0AxFUANu6rGDo+UvwJDFyQ8q/kIH7N AK+g== MIME-Version: 1.0 X-Received: by 10.112.212.106 with SMTP id nj10mr2600049lbc.36.1425819812284; Sun, 08 Mar 2015 06:03:32 -0700 (PDT) Received: by 10.112.9.235 with HTTP; Sun, 8 Mar 2015 06:03:32 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Mar 2015 18:33:32 +0530 Message-ID: Subject: Re: GSoC 2015 Task: Unifying ping and ping6 From: Rushil Paul To: Ed Schouten Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 13:03:35 -0000 Hi, I'm not sure about what my part would be in getting noping relicensed to BSD/MIT. I'm still going with unifying ping/ping6 and traceroute/traceroute6 as of now. Also, I did not find the source for traceroute in /usr/src/usr.sbin/traceroute/. This dir just contained a Makefile and findsaddr-udp.c. The other relevant files were in /usr/src/contrib/traceroute/. However this was not the case with traceroute6. traceroute6.c is in /usr/src/usr.sbin/traceroute6/ (where it should be) except for the file as.h (which it includes) which is in /usr/src/contrib/traceroute/ Why isn't all of traceroute in one place? On Sat, Mar 7, 2015 at 12:58 AM, Ed Schouten wrote: > Hi Rushil, > > 2015-03-04 20:40 GMT+01:00 Rushil Paul : > > And what exactly should my proposal include? How much code can be shared > > between ping and ping6, how to test the program afterwards etc.? Some > > inputs from experts will be very helpful :-) > > A good friend of mine is the author of noping/oping/liboping: > > http://noping.cc/ > > It's a pretty sweet tool. It supports a tonne of options and has nice > displaying/graphing. It also has support for multiple address > families, can ping multiple addresses per hostname, etc. > > The tool is LGPL/GPLv2 licensed, but the last time I talked to the > author, he said he was willing to go through the hoops to get it > relicensed to BSD/MIT if a party like us would be interested in using > it. Maybe it's worth considering going that route? > > Best regards, > -- > Ed Schouten > -- Regards, Rushil From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 13:11:26 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7383FE65 for ; Mon, 9 Mar 2015 13:11:26 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ED447797 for ; Mon, 9 Mar 2015 13:11:25 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t29DBEtP074485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 9 Mar 2015 14:11:16 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t29DB9HF039951 for ; Mon, 9 Mar 2015 14:11:09 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t29DB2sC039134 for ; Mon, 9 Mar 2015 14:11:04 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Mon, 9 Mar 2015 14:11:02 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: UFS endian conversion Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Mon, 09 Mar 2015 14:11:16 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 13:11:26 -0000 is it possible without backup/restore? any tool? or do i miss something in fsck_ffs manual? From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 15:36:23 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D965952 for ; Mon, 9 Mar 2015 15:36:23 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 37FC3A16 for ; Mon, 9 Mar 2015 15:36:23 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id D9B7B5A9F27; Mon, 9 Mar 2015 15:36:22 +0000 (UTC) Date: Mon, 9 Mar 2015 15:36:22 +0000 From: Brooks Davis To: Jonathon McDaniels Subject: Re: GSoC idea - porting and patching of userland for lld, the LLVM linker Message-ID: <20150309153622.GB72806@spindle.one-eyed-alien.net> References: <54F9EFD7.7030803@mymail.vcu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline In-Reply-To: <54F9EFD7.7030803@mymail.vcu.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:36:23 -0000 --gatW/ieO32f1wygP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 06, 2015 at 01:20:07PM -0500, Jonathon McDaniels wrote: > Hey guys, >=20 > After giving it some thought, I was thinking of porting ( as in, make it= =20 > a port of ) and patching the userland so a make buildworld can go=20 > through on x86/AMD64 on lld, the LLVM linker, and if time permits,=20 > patching the kernel to make use of it.. As the binutils included in base= =20 > is over 7 years old, and is unlikely to be updated due to the GPLv3, it= =20 > would make sense to assist with removing dependence of the FreeBSD=20 > platforms now using LLVM/Clang for compiling. >=20 > Before I go contact the mentors that would be within the scope of this=20 > project, I wanted to make sure of the following: >=20 > * That this would be a good use of GSoC > * That it is narrow enough in scope to be feasible, but broad enough > that it would prove a beneficial project. >=20 > Considering the environment we have now, I think it would allow me to=20 > further my knowledge of C beyond what I already know ( currently working= =20 > on learning about dynamic linking of libraries, and I already know about= =20 > data structures, stacks, pointers etc. and plan to be much farther along= =20 > by the time of the start of the project and deliverables. ). >=20 > And since lld is compatible with the BSD license terms, and is=20 > interoperable with LLVM, it seems a viable and good project to undertake. >=20 > Thoughts from you guys? Not to be too discouraging, I want lld in the base soon, but I'm not convinced there's a good GSoC project here. Creating a port of lld is probably a week's work even starting with no knowledge of the ports system. There may be some FreeBSD specific changes to lld required, but they should be small. Resolving compatibility issues with FreeBSD and ports might be a good project, but being able to work on that depends on the completion of linker script support. I think that's an unacceptably large external dependency for a GSoC project given that there's no public timeline for that work. -- Brooks --gatW/ieO32f1wygP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlT9vfYACgkQXY6L6fI4GtRswwCcCauyHT7VOyE01OgB3RiAKuwt EqwAnRgf8zq8lpawSxB9qThJfc0EtzX7 =yuUm -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 16:12:18 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28963913 for ; Mon, 9 Mar 2015 16:12:18 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2380EA3 for ; Mon, 9 Mar 2015 16:12:17 +0000 (UTC) Received: by obbnt9 with SMTP id nt9so10011279obb.9 for ; Mon, 09 Mar 2015 09:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=A3IbtV1wnaTYRkVNK/rZihzO8Dclnaw9RjTaIjFdZV0=; b=t9afwNbT2MfDQEagpcs1xfGE9oAufVZLpxtfs2+wejtmTmof+Tnlj7umltiHZQYF6S /sm5xXaLxI2KuBIZd2sbtsU7zyQS3WzUELslemiy237YgIigjDc1NOqOPGfZiVYn4Z+7 dtyScImiGDiex9R8PwZb3ibT1Ced98uSvoR6txyVHtT1SCRZQm8VV4kuq1tT7/jAWcAL 6VxAJn5xLe8ZXpP8qbFhRkN6plr2SF+bAaKB9HIjWC0OxLfnOSifzh8Uon1O5XfoIvvr iYrUTqrLEMt1fl0gqf+y87dE6p+uKtKEk3typA/kLL0j+6BOPbN1zfu+TebHpLb9yy3t PW8A== MIME-Version: 1.0 X-Received: by 10.202.66.136 with SMTP id p130mr21182083oia.110.1425917537049; Mon, 09 Mar 2015 09:12:17 -0700 (PDT) Received: by 10.182.55.100 with HTTP; Mon, 9 Mar 2015 09:12:16 -0700 (PDT) Date: Mon, 9 Mar 2015 10:12:16 -0600 Message-ID: Subject: Booting FreeBSD under UEFI x86-64 hardware From: JCA <1.41421@gmail.com> To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:12:18 -0000 I have just started looking into what is involved in booting FreeBSD on UEFI-based x86-64 hardware. I was wondering if anybody in this group could provide some pointers where to start. I am interested in the FreeBSD boot code under UEFI in general, with a particular emphasis on how the FreeBSD loader exploits the secure boot capabilities supported by recent UEFI versions. I'd be most grateful if anybody can point me in the right direction on this. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 16:20:05 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EB0F169 for ; Mon, 9 Mar 2015 16:20:05 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AC55FAA for ; Mon, 9 Mar 2015 16:20:05 +0000 (UTC) Received: from coleburn.avinity.tv (unknown [77.243.161.229]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B51C75C48; Mon, 9 Mar 2015 17:19:58 +0100 (CET) Subject: Re: Booting FreeBSD under UEFI x86-64 hardware Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4A32D0FD-CAD5-4770-9092-FB8C6C002D9E"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Dimitry Andric In-Reply-To: Date: Mon, 9 Mar 2015 17:19:54 +0100 Message-Id: <7C95EDD1-F2A3-4120-BF04-49E0A6DC83FF@FreeBSD.org> References: To: JCA <1.41421@gmail.com> X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:20:05 -0000 --Apple-Mail=_4A32D0FD-CAD5-4770-9092-FB8C6C002D9E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 09 Mar 2015, at 17:12, JCA <1.41421@gmail.com> wrote: > > I have just started looking into what is involved in booting FreeBSD > on UEFI-based x86-64 hardware. I was wondering if anybody in this > group could provide some pointers where to start. I am interested in > the FreeBSD boot code under UEFI in general, with a particular > emphasis on how the FreeBSD loader exploits the secure boot > capabilities supported by recent UEFI versions. I'd be most grateful > if anybody can point me in the right direction on this. Start here: https://wiki.freebsd.org/UEFI Executive summary: it works, but with some caveats (e.g. no ZFS). -Dimitry --Apple-Mail=_4A32D0FD-CAD5-4770-9092-FB8C6C002D9E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlT9yC0ACgkQsF6jCi4glqPfRACeMfNyMrnwH2LauaPwVc+LkeTt ZTsAoPivdxKRWLq+kbPxt1LGppPSl6dO =ZTnp -----END PGP SIGNATURE----- --Apple-Mail=_4A32D0FD-CAD5-4770-9092-FB8C6C002D9E-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 17:24:20 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0962CB3C for ; Mon, 9 Mar 2015 17:24:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D47E7A8D for ; Mon, 9 Mar 2015 17:24:19 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 715C7B93C; Mon, 9 Mar 2015 13:24:18 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: GSoC 2015 Task: Unifying ping and ping6 Date: Mon, 09 Mar 2015 12:24:53 -0400 Message-ID: <1523576.ksVdKF2UQl@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Mar 2015 13:24:18 -0400 (EDT) Cc: Ed Schouten , Rushil Paul X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:24:20 -0000 On Sunday, March 08, 2015 06:33:32 PM Rushil Paul wrote: > Hi, > I'm not sure about what my part would be in getting noping relicensed to > BSD/MIT. > I'm still going with unifying ping/ping6 and traceroute/traceroute6 as of > now. > > Also, I did not find the source for traceroute in > /usr/src/usr.sbin/traceroute/. This dir just contained a Makefile and > findsaddr-udp.c. The other relevant files were in > /usr/src/contrib/traceroute/. > However this was not the case with traceroute6. traceroute6.c is in > /usr/src/usr.sbin/traceroute6/ (where it should be) except for the file > as.h (which it includes) which is in /usr/src/contrib/traceroute/ > > Why isn't all of traceroute in one place? That is because traceroute is from an external ("contributed") source. Specifically, traceroute comes from a package provided by Lawrence Berkeley National Laboratory. https://svnweb.freebsd.org/base/head/contrib/traceroute/README?revision=100785&view=markup -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 17:24:20 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53CC4B3D; Mon, 9 Mar 2015 17:24:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BE2AA8F; Mon, 9 Mar 2015 17:24:20 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1BA2FB945; Mon, 9 Mar 2015 13:24:19 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: GSoC 2015: FreeBSD Port of Network manager Date: Mon, 09 Mar 2015 12:16:47 -0400 Message-ID: <12575122.FXQfMv0qnV@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54FA08C7.6090304@freebsd.org> References: <54FA08C7.6090304@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Mar 2015 13:24:19 -0400 (EDT) Cc: 'Gavin Atkinson' , Allan Jude , Kris Moore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:24:20 -0000 On Friday, March 06, 2015 03:06:31 PM Allan Jude wrote: > On 2015-03-06 15:00, Gokul Krishna wrote: > > Hi > > I am currently studying 2nd year of masters in embedded systems at KTH > > Royal institute of technology , sweden. > > I have around 2 and half years of experience in embedded linux and device > > drivers projects. > > I have reasonably good working and debugging knowledge of Char/Block/ > > Network drivers in Linux and their implementation. Also Im familiar about > > working knowledge of Realtek 8139 network device driver in Linux. > > So I am interested to work in this project "FreeBSD porting of Network > > manager". > > Kindly explain me about the expected deliverables, i need to contribute > > for this project , So I will start working for project plan with list of > > Milestone task and design decisions for mid term deliverables and final > > deliverables. > > Kindly reply me. > > thanks and regards > > gokul > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > There is a network manager in PCBSD that works on FreeBSD, already in > the ports tree. You might want to make sure there is some advantage to > network manager before doing the work. > > the PCBSD Network Manager is part of: sysutils/pcbsd-utils-qt4 > > http://www.freshports.org/sysutils/pcbsd-utils-qt4 Note that if this tool is sufficient, we really shouldn't have this idea on the GSoC ideas list. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 18:09:14 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DCD494E for ; Mon, 9 Mar 2015 18:09:14 +0000 (UTC) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15CC5FA6 for ; Mon, 9 Mar 2015 18:09:13 +0000 (UTC) Received: by qgdz107 with SMTP id z107so30512383qgd.3 for ; Mon, 09 Mar 2015 11:09:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hMLCEu4DwGHrc6ZgGzKP2PYILBEwG6eaY2MYHTfOgyU=; b=YwsnU4PH3gQkgzqzTXsBI98fhxRM5Fq6zdn+Et2Wbp2pUzfn7lUaM3PpVsPT57g9wR cNg/U2SzGrx2xUn5LKClwSW7Z/hr+8vAXBA09w1rJJ73Aj+yYK7mrkNdu1C6ZI9wJo6J X6KThtzpZ8SsKhAq7i+joYoxVlsGKWIHwe6KCvaHQnttNcr1Qm9jr/8pkNsrG9K7B57a PySNZXTX7+8xntBaSommcOwSO5kut/u7qbWNM3a8XlAHwxHubOCVUAqnsOhZW4Ns4aK4 jprdqVauaqJkfQSe0SHT0IzjbnVjoCsutDZfpiMkS/r+hN6jsFfCIomsGqbDzuUvJQ8Q 4lyg== X-Gm-Message-State: ALoCoQnCr3tHRzC/sDyp9lNiQEjhH8BkM4yiOmYDj2RTcQHhK0Xc+IRnq9KWyzGefy6SeD6AXlkk X-Received: by 10.140.31.246 with SMTP id f109mr35464171qgf.23.1425924547427; Mon, 09 Mar 2015 11:09:07 -0700 (PDT) Received: from blackrose.teamblackfox.local (pool-173-53-56-48.rcmdva.fios.verizon.net. [173.53.56.48]) by mx.google.com with ESMTPSA id d186sm12017281qhc.3.2015.03.09.11.09.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 11:09:06 -0700 (PDT) Message-ID: <54FDE1C1.90304@mymail.vcu.edu> Date: Mon, 09 Mar 2015 14:09:05 -0400 From: Jonathon McDaniels User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brooks Davis Subject: Re: GSoC idea - porting and patching of userland for lld, the LLVM linker References: <54F9EFD7.7030803@mymail.vcu.edu> <20150309153622.GB72806@spindle.one-eyed-alien.net> In-Reply-To: <20150309153622.GB72806@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:09:14 -0000 Good points Brooks, Instead of lld I'm actually considering doing the idea of making a new linker from scratch to work with FreeBSD on all architectures, but that's dependent on my study and comprehension of all of the things GNU ld does, and furthermore that I get enough experience to take on such a daunting task. Luckily this week is spring break for me, so I'll have time to brain storm and look more into this. The good thing is that any changes I make I can test on almost all major architectures supported by FreeBSD, excluding SPARC, PC-98 and a few others since I own a large variety of hardware. If you've any advice or other ideas that would involve leveraging us off of binutils, I'm all ears. As it stands though I'm not interested or experienced enough to do either gdb or gas, since assembler isn't my primary interest. On 03/09/2015 11:36, Brooks Davis wrote: > On Fri, Mar 06, 2015 at 01:20:07PM -0500, Jonathon McDaniels wrote: >> Hey guys, >> >> After giving it some thought, I was thinking of porting ( as in, make it >> a port of ) and patching the userland so a make buildworld can go >> through on x86/AMD64 on lld, the LLVM linker, and if time permits, >> patching the kernel to make use of it.. As the binutils included in base >> is over 7 years old, and is unlikely to be updated due to the GPLv3, it >> would make sense to assist with removing dependence of the FreeBSD >> platforms now using LLVM/Clang for compiling. >> >> Before I go contact the mentors that would be within the scope of this >> project, I wanted to make sure of the following: >> >> * That this would be a good use of GSoC >> * That it is narrow enough in scope to be feasible, but broad enough >> that it would prove a beneficial project. >> >> Considering the environment we have now, I think it would allow me to >> further my knowledge of C beyond what I already know ( currently working >> on learning about dynamic linking of libraries, and I already know about >> data structures, stacks, pointers etc. and plan to be much farther along >> by the time of the start of the project and deliverables. ). >> >> And since lld is compatible with the BSD license terms, and is >> interoperable with LLVM, it seems a viable and good project to undertake. >> >> Thoughts from you guys? > Not to be too discouraging, I want lld in the base soon, but I'm not > convinced there's a good GSoC project here. Creating a port of lld is > probably a week's work even starting with no knowledge of the ports > system. There may be some FreeBSD specific changes to lld required, > but they should be small. > > Resolving compatibility issues with FreeBSD and ports might be a good > project, but being able to work on that depends on the completion of > linker script support. I think that's an unacceptably large external > dependency for a GSoC project given that there's no public timeline for > that work. > > -- Brooks From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 19:01:20 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9035478F; Mon, 9 Mar 2015 19:01:20 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 6B38A94A; Mon, 9 Mar 2015 19:01:20 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 414305A9F27; Mon, 9 Mar 2015 19:01:19 +0000 (UTC) Date: Mon, 9 Mar 2015 19:01:19 +0000 From: Brooks Davis To: Wojciech Puchar Subject: Re: UFS endian conversion Message-ID: <20150309190119.GC72806@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y5rl02BVI9TCfPar" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, sson@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:01:20 -0000 --Y5rl02BVI9TCfPar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 09, 2015 at 02:11:02PM +0100, Wojciech Puchar wrote: > is it possible without backup/restore? >=20 > any tool? >=20 > or do i miss something in fsck_ffs manual? You would need to backup on the source endian and restore on the destination. Stacey Son (cc'd) has some patches to allow access to UFS file systems of non-native endian that need someone to help polishing them up. -- Brooks --Y5rl02BVI9TCfPar Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlT97f4ACgkQXY6L6fI4GtRqpgCg2n3ZB4QiIZYxTVneBudgolsF 3yYAoJp3rjGEFKvasTvoeZP3dc7yqgBh =7DHB -----END PGP SIGNATURE----- --Y5rl02BVI9TCfPar-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 20:18:39 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E390BF00 for ; Mon, 9 Mar 2015 20:18:39 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1FB65FE for ; Mon, 9 Mar 2015 20:18:39 +0000 (UTC) Received: by paceu11 with SMTP id eu11so61270672pac.4 for ; Mon, 09 Mar 2015 13:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=95pk4zS4AVIbb7snO78kWj/YkZZWBXZqA4OzfQwLYII=; b=i39dgvrdb52dnq0oiiyBLvm643zFMT21EGUzHwblreEGm7STJdLq4EYFDBq2WZ0caq whlyoQsVTYHwHrrFvFT5njO8DPxq6084WkYkx5eB6z7U6Q4kZktJ7GnFxgjOcZBIRfxy 2ZDvIQNRuSfeF1mAjXfgOHqfzvVKUL6QyZvLzhMHuipmJ+P2POGYoS1huhK3Uj6BpCdA FGi0DHdoUxJDxrEIvjDLkl9phe339GyMIZVUNROFsqVlyzAbMc1mpsNpXKwHWtdDiA6E bE+7A1HNoLXl74BW4hWrijHFNas67xkE4Uv7JVIRj92DqhvZeQIV75hwKlOnO3u9Ufp5 YCwQ== X-Received: by 10.70.0.207 with SMTP id 15mr6677276pdg.56.1425932318880; Mon, 09 Mar 2015 13:18:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.179.203 with HTTP; Mon, 9 Mar 2015 13:18:07 -0700 (PDT) From: Yue Chen Date: Mon, 9 Mar 2015 16:18:07 -0400 Message-ID: Subject: [Rebuild Kernel] Part of the kernel functions are not recompiled when rebuilding the kernel To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:18:40 -0000 Hi all, When I used my customized LLVM (insert some instructions after each basic block) to rebuild the 10.1-RELEASE kernel, I found that about 10% of the kernel functions (in a continuous address range, in "objdump -S kernel", about 79%-88%) are not recompiled with my LLVM (does not have the feature of my customized LLVM). For example, these functions: calc_rebuild_progress ID_TO_VDEV ldm_spinup_vdev hpt27xx_ldm_suspend ldm_start_rebuild hptnr_ldm_acquire_lock __ldm_finish_cmd I believe the rebuilding process would do a CLEAN first. Maybe something is wrong with my building process? I followed the instructions here: https://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html Or these functions are in kernel modules that are statically linked? Best regards and thanks, Yue From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 9 21:03:50 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AC4D67C for ; Mon, 9 Mar 2015 21:03:50 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0055.outbound.protection.outlook.com [207.46.100.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C8EBD8C for ; Mon, 9 Mar 2015 21:03:49 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) with Microsoft SMTP Server (TLS) id 15.1.106.15; Mon, 9 Mar 2015 21:03:47 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0106.007; Mon, 9 Mar 2015 21:03:47 +0000 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: detecting hyperthreading Thread-Topic: detecting hyperthreading Thread-Index: AQHQWqyImRFHWPGSCkqtx00nVjUfFQ== Date: Mon, 9 Mar 2015 21:03:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [64.80.217.3] authentication-results: freebsd.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0944; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(164054003)(450100001)(2900100001)(122556002)(19580395003)(221733001)(77156002)(92566002)(15975445007)(50986999)(40100003)(66066001)(83506001)(102836002)(36756003)(86362001)(229853001)(62966003)(2656002)(107886001)(46102003)(2351001)(54356999)(106116001)(87936001)(110136001)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0944; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002009); SRVR:DM2PR0801MB0944; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0944; x-forefront-prvs: 05102978A2 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2015 21:03:47.1221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0944 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:03:50 -0000 Hi folks, There used to be a sysctl, "machdep.hyperthreading_allowed", which indicated whether or not the kernel was using hyperthreaded cores. It looks like it was removed sometime between 8 and 9, for perfectly good reasons (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D222853)= . That said, is there currently a way to tell at runtime from userland if hyperthreading is enabled or not? Thanks, Ravi From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 01:17:00 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4813A230; Tue, 10 Mar 2015 01:17:00 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BD77F96; Tue, 10 Mar 2015 01:17:00 +0000 (UTC) Received: from [10.17.4.36] (p31209-ipngn8001marunouchi.tokyo.ocn.ne.jp [153.214.94.209]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NKZ00KKD27KZP00@st11p02mm-asmtp001.mac.com>; Tue, 10 Mar 2015 01:16:36 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-09_05:2015-03-09,2015-03-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503100013 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: GSoC idea - porting and patching of userland for lld, the LLVM linker From: Rui Paulo In-reply-to: <54FDE1C1.90304@mymail.vcu.edu> Date: Tue, 10 Mar 2015 10:16:32 +0900 Content-transfer-encoding: quoted-printable Message-id: <14A66663-722D-4B03-9E32-4CF02396664C@me.com> References: <54F9EFD7.7030803@mymail.vcu.edu> <20150309153622.GB72806@spindle.one-eyed-alien.net> <54FDE1C1.90304@mymail.vcu.edu> To: Jonathon McDaniels X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-hackers@freebsd.org, Brooks Davis X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 01:17:00 -0000 On 10 Mar 2015, at 03:09, Jonathon McDaniels = wrote: >=20 > Instead of lld I'm actually considering doing the idea of making a new = linker from scratch to work with FreeBSD on all architectures[...] That's a monumental task and I think it could never be completed during = the GSoC time frame. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 01:19:55 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A780E426 for ; Tue, 10 Mar 2015 01:19:55 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AC02FBF for ; Tue, 10 Mar 2015 01:19:55 +0000 (UTC) Received: from [10.17.4.36] (p31209-ipngn8001marunouchi.tokyo.ocn.ne.jp [153.214.94.209]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NKZ00FAR2CAZQ50@st11p02mm-asmtp002.mac.com> for freebsd-hackers@freebsd.org; Tue, 10 Mar 2015 01:19:25 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-09_05:2015-03-09,2015-03-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503100014 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: detecting hyperthreading From: Rui Paulo In-reply-to: Date: Tue, 10 Mar 2015 10:19:21 +0900 Content-transfer-encoding: quoted-printable Message-id: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> References: To: "Pokala, Ravi" X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 01:19:55 -0000 On 10 Mar 2015, at 06:03, Pokala, Ravi wrote: >=20 > Hi folks, >=20 > There used to be a sysctl, "machdep.hyperthreading_allowed", which > indicated whether or not the kernel was using hyperthreaded cores. It > looks like it was removed sometime between 8 and 9, for perfectly good > reasons = (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D222853). >=20 > That said, is there currently a way to tell at runtime from userland = if > hyperthreading is enabled or not? I think that sysctl didn't fully control hyperthreading: you can disable = it on the BIOS and FreeBSD never exported that information. If you used = that tunable, it would simply disable the Pentium 4 Hyperthreading. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 02:57:38 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38F7623E for ; Tue, 10 Mar 2015 02:57:38 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0083.outbound.protection.outlook.com [157.56.111.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD935DAA for ; Tue, 10 Mar 2015 02:57:36 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0942.namprd08.prod.outlook.com (25.160.131.25) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 01:24:35 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0106.007; Tue, 10 Mar 2015 01:24:35 +0000 From: "Pokala, Ravi" To: Rui Paulo Subject: Re: detecting hyperthreading Thread-Topic: detecting hyperthreading Thread-Index: AQHQWqyImRFHWPGSCkqtx00nVjUfFZ0U6yCA//+MIIA= Date: Tue, 10 Mar 2015 01:24:35 +0000 Message-ID: References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> In-Reply-To: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [64.80.217.3] authentication-results: me.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0942; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377424004)(51444003)(13464003)(2656002)(106116001)(36756003)(92566002)(46102003)(62966003)(76176999)(77156002)(99286002)(66066001)(102836002)(50986999)(86362001)(83506001)(19580395003)(2950100001)(122556002)(19580405001)(87936001)(221733001)(110136001)(54356999)(2900100001)(40100003)(7059030)(111123002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0942; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002009); SRVR:DM2PR0801MB0942; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0942; x-forefront-prvs: 051158ECBB Content-Type: text/plain; charset="us-ascii" Content-ID: <0D69E1BB803CCE4EBA5CE1E39241C3DD@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 01:24:35.2127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0942 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 02:57:38 -0000 -----Original Message----- From: Rui Paulo Date: 2015-03-09, Monday at 18:19 To: Ravi Pokala Cc: "freebsd-hackers@freebsd.org" Subject: Re: detecting hyperthreading >I think that sysctl didn't fully control hyperthreading: you can disable >it on the BIOS and FreeBSD never exported that information. If you used >that tunable, it would simply disable the Pentium 4 Hyperthreading. I never tried to *change* it at runtime; I just used it's *existence* as an indicator that HT was enabled. (Aside - why did it not exist at all when HT was disabled, as opposed to always existing and just having zero/non-zero values?) -Ravi >-- >Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 07:52:58 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53CCD170 for ; Tue, 10 Mar 2015 07:52:58 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 113C7E4B for ; Tue, 10 Mar 2015 07:52:57 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 52E631FE022; Tue, 10 Mar 2015 08:52:55 +0100 (CET) Message-ID: <54FEA306.4060704@selasky.org> Date: Tue, 10 Mar 2015 08:53:42 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yue Chen , "freebsd-hackers@freebsd.org" Subject: Re: [Rebuild Kernel] Part of the kernel functions are not recompiled when rebuilding the kernel References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 07:52:58 -0000 On 03/09/15 21:18, Yue Chen wrote: > Hi all, > > When I used my customized LLVM (insert some instructions after each basic > block) to rebuild the 10.1-RELEASE kernel, I found that about 10% of the > kernel functions (in a continuous address range, in "objdump -S kernel", > about 79%-88%) are not recompiled with my LLVM (does not have the feature > of my customized LLVM). For example, these functions: > > calc_rebuild_progress > ID_TO_VDEV > ldm_spinup_vdev > hpt27xx_ldm_suspend > ldm_start_rebuild > hptnr_ldm_acquire_lock > __ldm_finish_cmd > > I believe the rebuilding process would do a CLEAN first. Maybe something is > wrong with my building process? I followed the instructions here: > https://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html > > Or these functions are in kernel modules that are statically linked? > > Best regards and thanks, > Yue Hi, Is your source tree is clean from object files? --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 15:56:22 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADC4CD2A for ; Tue, 10 Mar 2015 15:56:22 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0081.outbound.protection.outlook.com [207.46.100.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B22D227 for ; Tue, 10 Mar 2015 15:56:21 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0943.namprd08.prod.outlook.com (25.160.131.26) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 15:56:13 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0106.007; Tue, 10 Mar 2015 15:56:13 +0000 From: "Pokala, Ravi" To: "lokadamus@gmx.de" , Rui Paulo Subject: Re: detecting hyperthreading Thread-Topic: detecting hyperthreading Thread-Index: AQHQWqyImRFHWPGSCkqtx00nVjUfFZ0U6yCA//+MIICAAWfagP//i6mA Date: Tue, 10 Mar 2015 15:56:12 +0000 Message-ID: References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> In-Reply-To: <54FF1343.1020705@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [24.6.178.251] authentication-results: gmx.de; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0943; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377424004)(51704005)(164054003)(13464003)(40100003)(19580405001)(19580395003)(2950100001)(92566002)(76176999)(46102003)(50986999)(99286002)(54356999)(83506001)(122556002)(102836002)(36756003)(62966003)(221733001)(77156002)(2501003)(2656002)(93886004)(87936001)(86362001)(2900100001)(106116001)(66066001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0943; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR0801MB0943; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0943; x-forefront-prvs: 051158ECBB Content-Type: text/plain; charset="us-ascii" Content-ID: <5156B82CBDF092489A8C7E5B4996D663@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 15:56:12.5101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0943 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 15:56:22 -0000 -----Original Message----- From: "lokadamus@gmx.de" Date: 2015-03-10, Tuesday at 08:52 To: Ravi Pokala , Rui Paulo Cc: "freebsd-hackers@freebsd.org" Subject: Re: detecting hyperthreading >Have you look at dmesg? >My system is a P4 with HTT. >dmesg |more [...] >CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.00-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf29 Family =3D 0xf Model =3D 0x2 >Stepping =3D 9 > >Features=3D0xbfebfbffCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=3D0x4400 Of course. :-) But there are two problems: (1) That just tells me HTT is supported by the CPU, not that if kernel is using it. (2) It's difficult to parse. Of the two, (1) is the bigger concern for my use-case. Thanks, Ravi From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 15:58:06 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02197E52 for ; Tue, 10 Mar 2015 15:58:06 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F578263 for ; Tue, 10 Mar 2015 15:58:05 +0000 (UTC) Received: from [192.168.0.143] ([95.91.226.153]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0McUnM-1YDpZd0156-00HhcU; Tue, 10 Mar 2015 16:52:37 +0100 Message-ID: <54FF1343.1020705@gmx.de> Date: Tue, 10 Mar 2015 16:52:35 +0100 From: "lokadamus@gmx.de" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Pokala, Ravi" , Rui Paulo Subject: Re: detecting hyperthreading References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YN9ynNoPdAe7EVkk8Frvki7RowOAJCL+kTwo/4veiJk6ysfto82 o2Gbe8x21vsJmeLzT9G4UFG3syGYfmHc9yRPSobWLam9mKYO3bcxuxO6gG8k/Gns/D/qQF/ kKVXvHiUcr2LIWBe8SQsI2NLF0nkPAP5/Mw5aNXxoCHOKY9wfG9xbqtavDea7vMQl3knL6I DbSy0bViK2DpFS0Hcejlw== X-UI-Out-Filterresults: notjunk:1; Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 15:58:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/10/15 02:24, Pokala, Ravi wrote: > -----Original Message----- From: Rui Paulo Date: > 2015-03-09, Monday at 18:19 To: Ravi Pokala > Cc: "freebsd-hackers@freebsd.org" > Subject: Re: detecting hyperthreading > >> I think that sysctl didn't fully control hyperthreading: you can >> disable it on the BIOS and FreeBSD never exported that >> information. If you used that tunable, it would simply disable >> the Pentium 4 Hyperthreading. > > I never tried to *change* it at runtime; I just used it's > *existence* as an indicator that HT was enabled. (Aside - why did > it not exist at all when HT was disabled, as opposed to always > existing and just having zero/non-zero values?) > > -Ravi > >> -- Rui Paulo > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To > unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > Have you look at dmesg? My system is a P4 with HTT. dmesg |more Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 18:57:59 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = 0xf Model = 0x2 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 4294967296 (4096 MB) avail memory = 3396710400 (3239 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <7536MS A7536200> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard ... and so on ... Greeting From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 16:02:09 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BE9518C for ; Tue, 10 Mar 2015 16:02:09 +0000 (UTC) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31D04358 for ; Tue, 10 Mar 2015 16:02:09 +0000 (UTC) Received: by yks20 with SMTP id 20so1172879yks.4 for ; Tue, 10 Mar 2015 09:02:08 -0700 (PDT) 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=9m5WL0DMafaOtVHZUxPn99rpjut/2mbQH0RiHqANHE0=; b=IBzDnQSWWZVz9vvunUh6GlsvVhQPZWoXdN+hYYvJbqM9bv899q7pcruLviABmUaIUb QInZSmoG7xZiLkLFQvBjBSB+x7hOhlmeUKSAgd3KpTyTRIOeu3kZ4DjiGf9qkTDVPUdP 4hgzSE+14XtiaXO2wtuT3OeI0KxjLaG98BTRDVv62ZstqW/U4ohH9wdztTPWFYLXGhEu k7YYxkYIfdtLBtOqCsv5WrDj3rX4dQoejeQFqPcsUGmiwuqWw3zpAI/MQ9PYe3ShA2Lk tf3Adi/gBxWI4nJ2pRlxNacStjABAPFVePbfis5jDc3K7Ins9rBx8HulTtreH3G+DYXM Jytg== MIME-Version: 1.0 X-Received: by 10.170.220.197 with SMTP id m188mr36861684ykf.58.1426003328339; Tue, 10 Mar 2015 09:02:08 -0700 (PDT) Received: by 10.170.79.87 with HTTP; Tue, 10 Mar 2015 09:02:08 -0700 (PDT) In-Reply-To: References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> Date: Tue, 10 Mar 2015 09:02:08 -0700 Message-ID: Subject: Re: detecting hyperthreading From: Freddie Cash To: "Pokala, Ravi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , "lokadamus@gmx.de" , Rui Paulo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:02:09 -0000 On Tue, Mar 10, 2015 at 8:56 AM, Pokala, Ravi wrote: > -----Original Message----- > From: "lokadamus@gmx.de" > Date: 2015-03-10, Tuesday at 08:52 > To: Ravi Pokala , Rui Paulo > Cc: "freebsd-hackers@freebsd.org" > Subject: Re: detecting hyperthreading > > >Have you look at dmesg? > >My system is a P4 with HTT. > >dmesg |more > [...] > >CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.00-MHz 686-class CPU) > > Origin =3D "GenuineIntel" Id =3D 0xf29 Family =3D 0xf Model =3D 0x2 > >Stepping =3D 9 > > > >Features=3D0xbfebfbff >CA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=3D0x4400 > > Of course. :-) > > But there are two problems: > > (1) That just tells me HTT is supported by the CPU, not that if kernel is > using it. > (2) It's difficult to parse. > > Of the two, (1) is the bigger concern for my use-case. > =E2=80=8B6 lines or so below the Features line shows the kernel loading "cp= u0 (BSP)", and then "cpu1 (AP/HT)". Compare that to a system without HTT, where any extra cpus only show "(AP)"= . It's not perfect, but one could grep through /var/run/dmesg.boot looking for "cpu" lines and checking for "(AP)" or "(AP/HT)".=E2=80=8B --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 16:07:21 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB60344C for ; Tue, 10 Mar 2015 16:07:21 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48F6B3A7 for ; Tue, 10 Mar 2015 16:07:21 +0000 (UTC) Received: by wibbs8 with SMTP id bs8so31542706wib.0 for ; Tue, 10 Mar 2015 09:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ip/B4kUG/+xTOr2qQsLtaYNTgYTlxVG+XlYFb5MEmvQ=; b=bgp5MuXIxC49w+iuBRbhIpGK7Xswp0KFwvEIFZVTMvpzkmCgSBVki8BO5+iSHXjG1y n/klRprg4OUkl4KUUlMRXoj63iE/Y52RjBpepvwLIHNQU63QlDZQDs2Fe9Y/+xGTGm8a 2/BTXKKCiGOKDfsBuGuGP4lvwOdT+dcmiF1ZHw7+6DNzxDLvrNJkkgECKYxO5pBsMNs3 P2bfxMn174kx4dRawovMa7seG8iIk1l9UFeuZw2UcdD/yR9jFWYyFZYioNXuV+wAXhig bUJH/ishaMxRRAMQsOQWjkfmAr+kmlA9iSb6H3WnhKStdhLsn6wlKgBs+lcMXKCIC8ou b4Zw== MIME-Version: 1.0 X-Received: by 10.180.78.136 with SMTP id b8mr72939318wix.6.1426003639746; Tue, 10 Mar 2015 09:07:19 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.17.129 with HTTP; Tue, 10 Mar 2015 09:07:19 -0700 (PDT) In-Reply-To: References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> Date: Tue, 10 Mar 2015 10:07:19 -0600 X-Google-Sender-Auth: 0nHKXgNie-nY0mupEasLlTG-CSw Message-ID: Subject: Re: detecting hyperthreading From: Alan Somers To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "lokadamus@gmx.de" , "Pokala, Ravi" , Rui Paulo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:07:21 -0000 On Tue, Mar 10, 2015 at 10:02 AM, Freddie Cash wrote: > On Tue, Mar 10, 2015 at 8:56 AM, Pokala, Ravi wrote: > >> -----Original Message----- >> From: "lokadamus@gmx.de" >> Date: 2015-03-10, Tuesday at 08:52 >> To: Ravi Pokala , Rui Paulo >> Cc: "freebsd-hackers@freebsd.org" >> Subject: Re: detecting hyperthreading >> >> >Have you look at dmesg? >> >My system is a P4 with HTT. >> >dmesg |more >> [...] >> >CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.00-MHz 686-class CPU) >> > Origin = "GenuineIntel" Id = 0xf29 Family = 0xf Model = 0x2 >> >Stepping = 9 >> > >> >Features=0xbfebfbff> >CA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >> > Features2=0x4400 >> >> Of course. :-) >> >> But there are two problems: >> >> (1) That just tells me HTT is supported by the CPU, not that if kernel is >> using it. >> (2) It's difficult to parse. >> >> Of the two, (1) is the bigger concern for my use-case. >> > > 6 lines or so below the Features line shows the kernel loading "cpu0 > (BSP)", and then "cpu1 (AP/HT)". > > Compare that to a system without HTT, where any extra cpus only show "(AP)". > > It's not perfect, but one could grep through /var/run/dmesg.boot looking > for "cpu" lines and checking for "(AP)" or "(AP/HT)". > > -- > Freddie Cash > fjwcash@gmail.com I always look at "sysctl kern.sched.topology_spec" to tell if hyperthreading is enabled. It's overkill, but it works. Here's some Ruby code that can parse it: require 'rexml/document' # Parses the output of "sysctl kern.sched.topology_spec and returns a triple # of [number of sockets, cores/socket, threads/core] def _parse_topo(topology) cpu_xpath = "groups/group/children/group/cpu" xmldoc = REXML::Document.new(topology) _punt_topo(topology) unless xmldoc.get_elements("groups/group").count == 1 sockets = xmldoc.get_elements("groups/group/children/group").count all_cores_per_socket = Set.new([]) all_threads_per_core = Set.new([]) xmldoc.get_elements("groups/group/children/group").each do |group2| cores = 0 children = group2.get_elements("children/group") if children.empty? # No hyperthreading cpu_entities = group2.get_elements("cpu") _punt_topo(topology) unless cpu_entities.count == 1 core_count = cpu_entities.first.attribute("count").value cores += core_count.to_i else children.each do |group3| if group3.get_elements("flags/flag[@name='SMT']").empty? && \ group3.get_elements("flags/flag[@name='HTT']").empty? && \ group3.get_elements("flags/flag[@name='THREAD']").empty? else # This cpu group represents a single hyperthreaded core cores += 1 cpu_entities = group3.get_elements("cpu") _punt_topo(topology) unless cpu_entities.count == 1 core_count = cpu_entities.first.attribute("count").value all_threads_per_core.add(core_count.to_i) end end end all_cores_per_socket.add cores end if all_cores_per_socket.size > 1 cores_per_socket = "mixed" else cores_per_socket = all_cores_per_socket.first.to_i end if all_threads_per_core.size > 1 threads_per_core = "mixed" elsif all_threads_per_core.size == 0 # No SMT sections means no hyperthreading threads_per_core = 1 else threads_per_core = all_threads_per_core.first.to_i end [sockets, cores_per_socket, threads_per_core] end # Helper method for _parse_topo def _punt_topo(topo) STDERR.puts topology raise IOError.new "Output of kern.sched.topology is not understood" end -Alan From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 16:09:57 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B4A4687 for ; Tue, 10 Mar 2015 16:09:57 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F02533E8 for ; Tue, 10 Mar 2015 16:09:56 +0000 (UTC) Received: from [192.168.0.143] ([95.91.226.153]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M6vSj-1XYyiP3oPN-00wiKp; Tue, 10 Mar 2015 17:09:41 +0100 Message-ID: <54FF1743.8080205@gmx.de> Date: Tue, 10 Mar 2015 17:09:39 +0100 From: "lokadamus@gmx.de" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Pokala, Ravi" , Rui Paulo Subject: Re: detecting hyperthreading References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3XBLcHwUihTIK9W6bL+BCu0OU1Yrl6b8+HpHtnc41e1v59Y1Pou uUyGMCl8DKYCTSVu4W5XwsEmqnXop3rFvvQSrz3BQ8xDoGUNoYW4JVQN2KoR+hvxIYtRD0w MRq9CbjpoG2X07+oxmQoqAZgoB6b6whGpxCuJgwHAMrKFOQffScme2Cs+Z2RS+YcLh4NPXn 6vN/OeUjc86qZbnv3wkfw== X-UI-Out-Filterresults: notjunk:1; Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:09:57 -0000 On 03/10/15 16:56, Pokala, Ravi wrote: > -----Original Message----- From: "lokadamus@gmx.de" > Date: 2015-03-10, Tuesday at 08:52 To: Ravi > Pokala , Rui Paulo Cc: > "freebsd-hackers@freebsd.org" > Subject: Re: detecting hyperthreading > >> Have you look at dmesg? My system is a P4 with HTT. dmesg |more > [...] >> CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.00-MHz 686-class >> CPU) Origin = "GenuineIntel" Id = 0xf29 Family = 0xf Model = >> 0x2 Stepping = 9 >> >> Features=0xbfebfbff> >> CA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >> Features2=0x4400 > > Of course. :-) > > But there are two problems: > > (1) That just tells me HTT is supported by the CPU, not that if > kernel is using it. (2) It's difficult to parse. > > Of the two, (1) is the bigger concern for my use-case. > > Thanks, > > Ravi > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To > unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > Well, i don't know, how a new system is showing the following sequence: dmesg | grep FreeBSD/SMP | grep HTT Answer: FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads Value $? is zero, but i will not reboot my system to look how it will change, when HTT is disabled. I make a portupgrade and this will need some hour. ;) Greeting From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 10 22:07:29 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0314C54A for ; Tue, 10 Mar 2015 22:07:29 +0000 (UTC) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B29DE8F0 for ; Tue, 10 Mar 2015 22:07:28 +0000 (UTC) X-ASG-Debug-ID: 1426025230-08ca043650089a0002-P5m3U7 Received: from [192.168.18.10] (221x253x176x170.ap221.ftth.ucom.ne.jp [221.253.176.170]) by barracuda.ixsystems.com with ESMTP id CEZ0x8OkqcVrRnD6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Mar 2015 15:07:11 -0700 (PDT) X-Barracuda-Envelope-From: kris@pcbsd.org X-Barracuda-AUTH-User: kris@pcbsd.org X-Barracuda-Apparent-Source-IP: 221.253.176.170 Message-ID: <54FF6B0D.5050708@pcbsd.org> Date: Tue, 10 Mar 2015 18:07:09 -0400 From: Kris Moore User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Baldwin , freebsd-hackers@freebsd.org Subject: Re: GSoC 2015: FreeBSD Port of Network manager References: <54FA08C7.6090304@freebsd.org> <12575122.FXQfMv0qnV@ralph.baldwin.cx> X-ASG-Orig-Subj: Re: GSoC 2015: FreeBSD Port of Network manager In-Reply-To: <12575122.FXQfMv0qnV@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 221x253x176x170.ap221.ftth.ucom.ne.jp[221.253.176.170] X-Barracuda-Start-Time: 1426025231 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.16486 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Mailman-Approved-At: Tue, 10 Mar 2015 22:47:15 +0000 Cc: 'Gavin Atkinson' , Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 22:07:29 -0000 On 03/09/2015 12:16, John Baldwin wrote: > On Friday, March 06, 2015 03:06:31 PM Allan Jude wrote: >> On 2015-03-06 15:00, Gokul Krishna wrote: >>> Hi >>> I am currently studying 2nd year of masters in embedded systems at KTH >>> Royal institute of technology , sweden. >>> I have around 2 and half years of experience in embedded linux and device >>> drivers projects. >>> I have reasonably good working and debugging knowledge of Char/Block/ >>> Network drivers in Linux and their implementation. Also Im familiar about >>> working knowledge of Realtek 8139 network device driver in Linux. >>> So I am interested to work in this project "FreeBSD porting of Network >>> manager". >>> Kindly explain me about the expected deliverables, i need to contribute >>> for this project , So I will start working for project plan with list of >>> Milestone task and design decisions for mid term deliverables and final >>> deliverables. >>> Kindly reply me. >>> thanks and regards >>> gokul >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> There is a network manager in PCBSD that works on FreeBSD, already in >> the ports tree. You might want to make sure there is some advantage to >> network manager before doing the work. >> >> the PCBSD Network Manager is part of: sysutils/pcbsd-utils-qt4 >> >> http://www.freshports.org/sysutils/pcbsd-utils-qt4 > Note that if this tool is sufficient, we really shouldn't have this idea on > the GSoC ideas list. > Yea, we've had the tool in ports for a while now. Also, the -qt4 version was replaced with -qt5, just a FYI: http://www.freshports.org/sysutils/pcbsd-utils-qt5 The included network manager supports setting up IPv4/IPv6 on devices, wifi-scanning / setup, lagg support, and a handy-tray app to make connecting super-easy. We had looked at porting over NetworkManager years ago, but it was so Linux-centric it made more sense for us to develop something for FreeBSD specifically. -- Kris Moore PC-BSD Software iXsystems From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 00:44:54 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47E8671A for ; Wed, 11 Mar 2015 00:44:54 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0065.outbound.protection.outlook.com [65.55.169.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D988BD81 for ; Wed, 11 Mar 2015 00:44:53 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) with Microsoft SMTP Server (TLS) id 15.1.106.15; Wed, 11 Mar 2015 00:44:44 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0106.007; Wed, 11 Mar 2015 00:44:44 +0000 From: "Pokala, Ravi" To: Freddie Cash Subject: Re: detecting hyperthreading Thread-Topic: detecting hyperthreading Thread-Index: AQHQWqyImRFHWPGSCkqtx00nVjUfFZ0U6yCA//+MIICAAWfagP//i6mAgAB3AgCAAByoAA== Date: Wed, 11 Mar 2015 00:44:44 +0000 Message-ID: References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [24.6.178.251] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0944; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(13464003)(51704005)(377424004)(2656002)(99286002)(62966003)(87936001)(54356999)(46102003)(110136001)(106116001)(92566002)(221733001)(77156002)(2950100001)(19580395003)(122556002)(93886004)(1411001)(2900100001)(76176999)(83506001)(36756003)(66066001)(50986999)(40100003)(86362001)(102836002)(19580405001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0944; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002009); SRVR:DM2PR0801MB0944; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0944; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="utf-8" Content-ID: <7C455144811EB34B9E56ED3F3BA1CA95@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 00:44:44.5311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0944 Cc: "freebsd-hackers@freebsd.org" , "lokadamus@gmx.de" , Rui Paulo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:44:54 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEZyZWRkaWUgQ2FzaCA8Zmp3Y2FzaEBn bWFpbC5jb20+DQpEYXRlOiAyMDE1LTAzLTEwLCBUdWVzZGF5IGF0IDA5OjAyDQpUbzogUmF2aSBQ b2thbGEgPHJwb2thbGFAcGFuYXNhcy5jb20+DQpDYzogImxva2FkYW11c0BnbXguZGUiIDxsb2th ZGFtdXNAZ214LmRlPiwgUnVpIFBhdWxvIDxycGF1bG9AbWUuY29tPiwNCiJmcmVlYnNkLWhhY2tl cnNAZnJlZWJzZC5vcmciIDxmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmc+DQpTdWJqZWN0OiBS ZTogZGV0ZWN0aW5nIGh5cGVydGhyZWFkaW5nDQoNCj7igIs2IGxpbmVzIG9yIHNvIGJlbG93IHRo ZSBGZWF0dXJlcyBsaW5lIHNob3dzIHRoZSBrZXJuZWwgbG9hZGluZyAiY3B1MA0KPihCU1ApIiwg YW5kIHRoZW4gImNwdTEgKEFQL0hUKSIuDQo+DQo+Q29tcGFyZSB0aGF0IHRvIGEgc3lzdGVtIHdp dGhvdXQgSFRULCB3aGVyZSBhbnkgZXh0cmEgY3B1cyBvbmx5IHNob3cNCj4iKEFQKSIuDQo+DQo+ SXQncyBub3QgcGVyZmVjdCwgYnV0IG9uZSBjb3VsZCBncmVwIHRocm91Z2ggL3Zhci9ydW4vZG1l c2cuYm9vdCBsb29raW5nDQo+Zm9yICJjcHUiIGxpbmVzIGFuZCBjaGVja2luZyBmb3IgIihBUCki IG9yICIoQVAvSFQpIi7igIsNCg0KWWVhaC4gVGhlcmUncyB0b25zIG9mIGluZm8gdGhhdCBjb3Vs ZCBiZSBzY3JhcGVkIG91dCBvZiBkbWVzZy5ib290LCBidXQNCmFjdHVhbGx5IGRvaW5nIHRoYXQg LSBsZXQgYWxvbmUgZnJvbSBDIC0gaXMgYSBwYWluLiA6LVANCg0KLVJhdmkNCj4NCg0K From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 00:49:20 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 484C9837 for ; Wed, 11 Mar 2015 00:49:20 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19BC4DA9 for ; Wed, 11 Mar 2015 00:49:19 +0000 (UTC) Received: from [10.17.5.24] (p31209-ipngn8001marunouchi.tokyo.ocn.ne.jp [153.214.94.209]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NL000LFKVLB9910@st11p02mm-asmtp001.mac.com> for freebsd-hackers@freebsd.org; Wed, 11 Mar 2015 00:48:51 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-10_08:2015-03-10,2015-03-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503110008 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: detecting hyperthreading From: Rui Paulo In-reply-to: Date: Wed, 11 Mar 2015 09:48:47 +0900 Content-transfer-encoding: quoted-printable Message-id: <70D59C1C-8047-4A80-A172-D7CB3D8679AE@me.com> References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> To: "Pokala, Ravi" X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-hackers@freebsd.org" , "lokadamus@gmx.de" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:49:20 -0000 On 11 Mar 2015, at 09:44, Pokala, Ravi wrote: > Yeah. There's tons of info that could be scraped out of dmesg.boot, = but > actually doing that - let alone from C - is a pain. :-P At my $DAYJOB, I wrote some code to detect the number of CPU sockets via = topology_spec using expat (bsdxml library). It was probably less than = 50 lines of code. Detecting HTT/SMT shouldn't be hard. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 00:53:07 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71EC09AD for ; Wed, 11 Mar 2015 00:53:07 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0065.outbound.protection.outlook.com [157.56.111.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13DCAE74 for ; Wed, 11 Mar 2015 00:53:06 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0941.namprd08.prod.outlook.com (25.160.131.24) with Microsoft SMTP Server (TLS) id 15.1.106.15; Wed, 11 Mar 2015 00:52:58 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0106.007; Wed, 11 Mar 2015 00:52:58 +0000 From: "Pokala, Ravi" To: "lokadamus@gmx.de" , Rui Paulo Subject: Re: detecting hyperthreading Thread-Topic: detecting hyperthreading Thread-Index: AQHQWqyImRFHWPGSCkqtx00nVjUfFZ0U6yCA//+MIICAAWfagP//i6mAgAB5HICAABzcgA== Date: Wed, 11 Mar 2015 00:52:58 +0000 Message-ID: References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> <54FF1743.8080205@gmx.de> In-Reply-To: <54FF1743.8080205@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [24.6.178.251] authentication-results: gmx.de; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0941; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(51704005)(377424004)(13464003)(106116001)(66066001)(86362001)(87936001)(221733001)(122556002)(102836002)(40100003)(92566002)(93886004)(77156002)(83506001)(76176999)(36756003)(2501003)(54356999)(2900100001)(19580405001)(2950100001)(62966003)(2656002)(46102003)(19580395003)(99286002)(50986999)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0941; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR0801MB0941; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0941; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="us-ascii" Content-ID: <6F2234014D260C44A71F03F30E3075C1@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 00:52:58.6913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0941 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:53:07 -0000 -----Original Message----- From: "lokadamus@gmx.de" Date: 2015-03-10, Tuesday at 09:09 To: Ravi Pokala , Rui Paulo Cc: "freebsd-hackers@freebsd.org" Subject: Re: detecting hyperthreading >Well, i don't know, how a new system is showing the following sequence: >dmesg | grep FreeBSD/SMP | grep HTT >Answer: FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads > >Value $? is zero, but i will not reboot my system to look how it will >change, when HTT is disabled. > >I make a portupgrade and this will need some hour. ;) :-) I could probably use the machdep.hyperthreading_allowed *tunable* in loader.conf to get a system running w/ HT disabled and see what the kernel reports there, but all the suitable systems are shared, so I need to coordinate w/ others. -Ravi From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 01:05:17 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD1DCC3B; Wed, 11 Mar 2015 01:05:17 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0054.outbound.protection.outlook.com [157.56.110.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3073AF62; Wed, 11 Mar 2015 01:05:16 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0941.namprd08.prod.outlook.com (25.160.131.24) with Microsoft SMTP Server (TLS) id 15.1.106.15; Wed, 11 Mar 2015 00:50:33 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0106.007; Wed, 11 Mar 2015 00:50:33 +0000 From: "Pokala, Ravi" To: Alan Somers , Freddie Cash Subject: Re: detecting hyperthreading Thread-Topic: detecting hyperthreading Thread-Index: AQHQWqyImRFHWPGSCkqtx00nVjUfFZ0U6yCA//+MIICAAWfagP//i6mAgAB3AgCAAAFzgIAAHNWA Date: Wed, 11 Mar 2015 00:50:33 +0000 Message-ID: References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [24.6.178.251] authentication-results: freebsd.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0941; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377424004)(13464003)(106116001)(66066001)(86362001)(87936001)(221733001)(122556002)(102836002)(40100003)(92566002)(93886004)(77156002)(83506001)(76176999)(36756003)(54356999)(2900100001)(19580405001)(2950100001)(62966003)(2656002)(46102003)(19580395003)(99286002)(50986999)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0941; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR0801MB0941; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0941; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 00:50:33.5026 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0941 Cc: "freebsd-hackers@freebsd.org" , "lokadamus@gmx.de" , Rui Paulo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 01:05:17 -0000 -----Original Message----- From: Alan Somers Date: 2015-03-10, Tuesday at 09:07 To: Freddie Cash Cc: Ravi Pokala , "freebsd-hackers@freebsd.org" , "lokadamus@gmx.de" , Rui Paulo Subject: Re: detecting hyperthreading >I always look at "sysctl kern.sched.topology_spec" to tell if >hyperthreading is enabled. It's overkill, but it works. Yeah, David pointed me at that yesterday. It should be easy enough to take the same source data and create something that just returns the numbers. (i.e. kern.sched.active_{sockets,cores,threads}). -Ravi From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 01:13:06 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E442F7C for ; Wed, 11 Mar 2015 01:13:06 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0064.outbound.protection.outlook.com [65.55.169.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2504E3 for ; Wed, 11 Mar 2015 01:13:05 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0943.namprd08.prod.outlook.com (25.160.131.26) with Microsoft SMTP Server (TLS) id 15.1.106.15; Wed, 11 Mar 2015 01:12:57 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0106.007; Wed, 11 Mar 2015 01:12:57 +0000 From: "Pokala, Ravi" To: Rui Paulo Subject: Re: detecting hyperthreading Thread-Topic: detecting hyperthreading Thread-Index: AQHQWqyImRFHWPGSCkqtx00nVjUfFZ0U6yCA//+MIICAAWfagP//i6mAgAB3AgCAAByoAIAAdn2A//+RZAA= Date: Wed, 11 Mar 2015 01:12:57 +0000 Message-ID: References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> <70D59C1C-8047-4A80-A172-D7CB3D8679AE@me.com> In-Reply-To: <70D59C1C-8047-4A80-A172-D7CB3D8679AE@me.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [24.6.178.251] authentication-results: me.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0943; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(13464003)(164054003)(51704005)(377424004)(24454002)(86362001)(87936001)(221733001)(93886004)(2656002)(77156002)(66066001)(2900100001)(106116001)(40100003)(2950100001)(92566002)(19580405001)(19580395003)(36756003)(110136001)(102836002)(62966003)(76176999)(46102003)(50986999)(83506001)(99286002)(122556002)(54356999)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0943; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR0801MB0943; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0943; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="us-ascii" Content-ID: <18EFD6B88EBE31469A6F812A51981FC7@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 01:12:57.4821 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0943 Cc: "freebsd-hackers@freebsd.org" , "lokadamus@gmx.de" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 01:13:06 -0000 -----Original Message----- From: Rui Paulo Date: 2015-03-10, Tuesday at 17:48 To: Ravi Pokala Cc: Freddie Cash , "lokadamus@gmx.de" , "freebsd-hackers@freebsd.org" Subject: Re: detecting hyperthreading >On 11 Mar 2015, at 09:44, Pokala, Ravi wrote: >> Yeah. There's tons of info that could be scraped out of dmesg.boot, but >>actually doing that - let alone from C - is a pain. :-P > >At my $DAYJOB, I wrote some code to detect the number of CPU sockets via >topology_spec using expat (bsdxml library). It was probably less than 50 >lines of code. Detecting HTT/SMT shouldn't be hard. That's a fair point. We currently don't have an XML parser linked to the chunk of code I'm working in, but adding that wouldn't be too terrible if it came to that. Thanks, Ravi From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 03:32:33 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED854802 for ; Wed, 11 Mar 2015 03:32:33 +0000 (UTC) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B33E8301 for ; Wed, 11 Mar 2015 03:32:33 +0000 (UTC) Received: by obcuy5 with SMTP id uy5so6215441obc.11 for ; Tue, 10 Mar 2015 20:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=TM1i3BPEvEzq5qpEMnJcI5gh1HZx2RtQZYdx3WLhUT4=; b=D+SiWPdnTaYcxva27ocJMLyxSUOFjjuNFeZFJk00dpoczD/5jJ0Xj0IfCjt6/FMcuJ XML49EayLyU+4CcIQdrDHl88DdsXbMx2DuyyN58LocDllwbb0n4WD+j1PnyMNhPZvrAv w27h55O67f6wU+VevqiyPPLsLEz8Mm74dj8CaBi6c66wgpqAZmn1mJoNSwqKLH47Gctm slgUSCEbVkPGVlFlIgO0z6QIzlK1WwVdKtrS34fGr8KPEZv892AzxmEg6RADXXjVuxBN 7g2T2QrDip5jrP88rmAzNzc3JA0hYFcksp7bmZLZRhvd4e9vHY9ocDo1rJnooFrLFLSa RBUg== X-Received: by 10.60.97.35 with SMTP id dx3mr28408206oeb.6.1426044753066; Tue, 10 Mar 2015 20:32:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.116.133 with HTTP; Tue, 10 Mar 2015 20:31:52 -0700 (PDT) From: Matt Tagg Date: Tue, 10 Mar 2015 20:31:52 -0700 Message-ID: Subject: find with -delete option on absolute paths To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 03:32:34 -0000 Hey BSD folks I believe this was discussed previously (2013), though I could not find a resolution. To recap, suppose we try deleting files on an absolute path: matt@mtbook:/% find /tmp/foo/* -delete find: -delete: /tmp/foo/bar.txt: relative path potentially not safe As you can see it gives an error and quits. However if we instead try this: matt@mtbook:/% gfind /tmp/foo/* -delete GNU Find throws no error and works as expected ('bar.txt is deleted') So as an end user, I find this rather confusing. How can I get the same behavior with BSD Find out of the box? Thanks - m From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 04:43:23 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ED25FA0 for ; Wed, 11 Mar 2015 04:43:23 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03564B96 for ; Wed, 11 Mar 2015 04:43:22 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2B4iv9u040654; Tue, 10 Mar 2015 21:44:57 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: freebsd-hackers@freebsd.org, Matt Tagg In-Reply-To: References: From: "Chris H" Subject: Re: find with -delete option on absolute paths Date: Tue, 10 Mar 2015 21:44:57 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <244af0804267e6eaf7ddd43ffc7dd6e8@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 04:43:23 -0000 On Tue, 10 Mar 2015 20:31:52 -0700 Matt Tagg wrote > Hey BSD folks > > I believe this was discussed previously (2013), though I could not > find a resolution. > > To recap, suppose we try deleting files on an absolute path: > > matt@mtbook:/% find /tmp/foo/* -delete > find: -delete: /tmp/foo/bar.txt: relative path potentially not safe > > As you can see it gives an error and quits. However if we instead try this: > > matt@mtbook:/% gfind /tmp/foo/* -delete > > GNU Find throws no error and works as expected ('bar.txt is deleted') > > So as an end user, I find this rather confusing. How can I get the > same behavior with BSD Find out of the box? I don't know. But for tasks like you describe, I generally cobble up (bourne)shell scripts, and keep them handy in my ~/bin/ folder. Heck, you could easily create aliases to accomplish frequently used one-liners, and let us not overlook your shells history. But regarding your specific line above; maybe you mean: # find -name /tmp/foo/* -delete, or #find /tmp/foo/ -name * -delete or for directories # find /tmp/ -type d -name foo -delete which wouldn't probably work, but is basically the syntax your looking for. The key here, is -name. If you get into the habit of using it, you'll forget you need to add it, before you know it. But for me; I'm still keen on cobbling up one-liners for this sort of thing. :) All the best. --Chris > > Thanks > - m > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 04:52:50 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 688B7344 for ; Wed, 11 Mar 2015 04:52:50 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2653EC77 for ; Wed, 11 Mar 2015 04:52:50 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2B4sQPo041348; Tue, 10 Mar 2015 21:54:26 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: freebsd-hackers@freebsd.org, Matt Tagg In-Reply-To: <244af0804267e6eaf7ddd43ffc7dd6e8@ultimatedns.net> References: , <244af0804267e6eaf7ddd43ffc7dd6e8@ultimatedns.net> From: "Chris H" Subject: Re: find with -delete option on absolute paths Date: Tue, 10 Mar 2015 21:54:26 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <8170e39ad9c9cbecbc80406d3569dbea@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 04:52:50 -0000 On Tue, 10 Mar 2015 21:44:57 -0700 "Chris H" wrote > On Tue, 10 Mar 2015 20:31:52 -0700 Matt Tagg wrote > > > Hey BSD folks > > > > I believe this was discussed previously (2013), though I could not > > find a resolution. > > > > To recap, suppose we try deleting files on an absolute path: > > > > matt@mtbook:/% find /tmp/foo/* -delete > > find: -delete: /tmp/foo/bar.txt: relative path potentially not safe > > > > As you can see it gives an error and quits. However if we instead try this: > > > > matt@mtbook:/% gfind /tmp/foo/* -delete > > > > GNU Find throws no error and works as expected ('bar.txt is deleted') > > > > So as an end user, I find this rather confusing. How can I get the > > same behavior with BSD Find out of the box? Apologies. I was a bit distracted when I responded. I should have waited. What you are probably looking for is something like: find /tmp/foo/ -type f -delete Sorry. --Chris ---8<----- > --Chris > > > > Thanks > > - m > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 07:14:57 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 640B993D for ; Wed, 11 Mar 2015 07:14:57 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DDAE4C27 for ; Wed, 11 Mar 2015 07:14:56 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t2B7Ekxp063500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Mar 2015 08:14:46 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t2B7EfAj000876; Wed, 11 Mar 2015 08:14:41 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t2B7EY09000873; Wed, 11 Mar 2015 08:14:36 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 11 Mar 2015 08:14:34 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: "Pokala, Ravi" Subject: Re: detecting hyperthreading In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 11 Mar 2015 08:14:47 +0100 (CET) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 07:14:57 -0000 dmesg look at "HTT" CPU capability On Mon, 9 Mar 2015, Pokala, Ravi wrote: > Hi folks, > > There used to be a sysctl, "machdep.hyperthreading_allowed", which > indicated whether or not the kernel was using hyperthreaded cores. It > looks like it was removed sometime between 8 and 9, for perfectly good > reasons (https://svnweb.freebsd.org/base?view=revision&revision=222853). > > That said, is there currently a way to tell at runtime from userland if > hyperthreading is enabled or not? > > Thanks, > > Ravi > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 08:56:03 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10CA0DB1; Wed, 11 Mar 2015 08:56:03 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E4A98DC; Wed, 11 Mar 2015 08:56:02 +0000 (UTC) Received: by wevk48 with SMTP id k48so7541437wev.5; Wed, 11 Mar 2015 01:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=OQejqQqLTS1CwY4Foo0mudpcKR+8/ZNzpDo9aJnL/rI=; b=JWIAlOwUQLkGMJXau0Pa4b8JqdnucgYSYOwl7ZIeFvwb7U8ZImkynOFAe6RAALOh3F hIb/xFnmV3VBiB/xGbIjsTJ24TqyuluTOqoyUlPCFXxxzwOrKOoFvFBGnVpIWjExcBoy wAplIqxxhFEeRiSXLCq750ED4IOAdD+CN5PyE/JsN93OdSBaGO6Avn1ItKnLxCkpvbyf Dv+jbUn6UDHKbPwt+UpIsqXhxEK8GnDID8CHfIec3htzD+02irtbOdY0k3/S7MyFpmd1 4qhcEL3kVF/9y8tbgnmmFCfZJ6OjGlGqboEon0cFurgcZFxKQJptdLW6tuy468E+PV/d IxSg== X-Received: by 10.181.8.75 with SMTP id di11mr120788107wid.26.1426064160989; Wed, 11 Mar 2015 01:56:00 -0700 (PDT) Received: from ernst.home (p578E137B.dip0.t-ipconnect.de. [87.142.19.123]) by mx.google.com with ESMTPSA id gd6sm5536035wib.17.2015.03.11.01.55.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 01:56:00 -0700 (PDT) Date: Wed, 11 Mar 2015 09:55:56 +0100 From: Gary Jennejohn To: Alan Somers Subject: Re: detecting hyperthreading Message-ID: <20150311095556.1ed29f5d@ernst.home> In-Reply-To: References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , "lokadamus@gmx.de" , "Pokala, Ravi" , Rui Paulo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 08:56:03 -0000 On Tue, 10 Mar 2015 10:07:19 -0600 Alan Somers wrote: > On Tue, Mar 10, 2015 at 10:02 AM, Freddie Cash wrote: > > On Tue, Mar 10, 2015 at 8:56 AM, Pokala, Ravi wrote: > > > >> -----Original Message----- > >> From: "lokadamus@gmx.de" > >> Date: 2015-03-10, Tuesday at 08:52 > >> To: Ravi Pokala , Rui Paulo > >> Cc: "freebsd-hackers@freebsd.org" > >> Subject: Re: detecting hyperthreading > >> > >> >Have you look at dmesg? > >> >My system is a P4 with HTT. > >> >dmesg |more > >> [...] > >> >CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.00-MHz 686-class CPU) > >> > Origin = "GenuineIntel" Id = 0xf29 Family = 0xf Model = 0x2 > >> >Stepping = 9 > >> > > >> >Features=0xbfebfbff >> >CA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > >> > Features2=0x4400 > >> > >> Of course. :-) > >> > >> But there are two problems: > >> > >> (1) That just tells me HTT is supported by the CPU, not that if kernel is > >> using it. > >> (2) It's difficult to parse. > >> > >> Of the two, (1) is the bigger concern for my use-case. > >> > > > > 6 lines or so below the Features line shows the kernel loading "cpu0 > > (BSP)", and then "cpu1 (AP/HT)". > > > > Compare that to a system without HTT, where any extra cpus only show "(AP)". > > > > It's not perfect, but one could grep through /var/run/dmesg.boot looking > > for "cpu" lines and checking for "(AP)" or "(AP/HT)". > > > > -- > > Freddie Cash > > fjwcash@gmail.com > > I always look at "sysctl kern.sched.topology_spec" to tell if > hyperthreading is enabled. It's overkill, but it works. > [snip Ruby] Is this ULE-specific? This OID isn't present on my box using the BSD scheduler. Something to be aware of. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 13:10:57 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A31E7305 for ; Wed, 11 Mar 2015 13:10:57 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 61F499A1 for ; Wed, 11 Mar 2015 13:10:55 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygC3ZzzOPgBVcbeFAw--.48208S2; Wed, 11 Mar 2015 21:10:48 +0800 (CST) From: Tiwei Bie To: mjguzik@gmail.com Subject: [PATCH] Finish the task 'Convert mountlist_mtx to rwlock' Date: Wed, 11 Mar 2015 21:10:34 +0800 Message-Id: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.3.1 X-CM-TRANSID: LkAmygC3ZzzOPgBVcbeFAw--.48208S2 X-Coremail-Antispam: 1UD129KBjvAXoWfXF1UAFykuw4rGF4xAFWrKrg_yoW8Zw48Xo W3Xa4rGay0gFn5try8ArsagFsxGa4qga9rJw4kGFWqyF95JrykCrykAw13XF4fXrW0kFya vry7WF48Xw4kJw1kn29KB7ZKAUJUUUUr529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUY47k0a2IF6w4kM7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0 x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj4 1l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0 I7IYx2IY6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAaw2AFwI0_Jrv_JF1le2I262IYc4CY6c8Ij28IcVAa Y2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4 A2jsIE14v26r4UJVWxJr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkI ecxEwVAFwVW5GwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c 02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_ JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7 CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa 7IU5RBT5UUUUU== X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUFAVQhl-bDMwAFsh Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 13:10:57 -0000 Hi, Mateusz! I have finished the task: Convert mountlist_mtx to rwlock [1]. sys/rwlock.h and cddl/compat/opensolaris/sys/rwlock.h have defined the same symbols, such as rw_init(), rw_destroy(). So they could not be included in the same file. And the latter has been indirectly included in cddl/compat/opensolaris/kern/opensolaris_vfs.c and cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c which needs to use mountlist_lock. So I implemented the following functions to access mountlist_lock in these files: void zfs_mountlist_wlock(void); void zfs_mountlist_wunlock(void); void zfs_mountlist_rlock(void); void zfs_mountlist_runlock(void); Following is my patch: --- .../compat/opensolaris/kern/opensolaris_mount.c | 66 ++++++++++++++++++++++ sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c | 4 +- sys/cddl/compat/opensolaris/sys/mount.h | 5 ++ .../opensolaris/uts/common/fs/zfs/zfs_ioctl.c | 4 +- .../opensolaris/uts/common/fs/zfs/zfs_vfsops.c | 4 +- sys/compat/linprocfs/linprocfs.c | 4 +- sys/geom/journal/g_journal.c | 9 +-- sys/kern/vfs_mount.c | 21 +++---- sys/kern/vfs_mountroot.c | 13 +++-- sys/kern/vfs_subr.c | 34 +++++------ sys/kern/vfs_syscalls.c | 18 +++--- sys/modules/zfs/Makefile | 1 + sys/sys/mount.h | 5 +- 13 files changed, 132 insertions(+), 56 deletions(-) create mode 100644 sys/cddl/compat/opensolaris/kern/opensolaris_mount.c diff --git a/sys/cddl/compat/opensolaris/kern/opensolaris_mount.c b/sys/cddl/compat/opensolaris/kern/opensolaris_mount.c new file mode 100644 index 0000000..1a844d8 --- /dev/null +++ b/sys/cddl/compat/opensolaris/kern/opensolaris_mount.c @@ -0,0 +1,66 @@ +/*- + * Copyright (c) . + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +void +zfs_mountlist_wlock(void) +{ + + /* + * This is not ideal because FILE/LINE used by assertions will not + * be too helpful, but it must be an hard function for + * compatibility reasons. + */ + rw_wlock(&mountlist_lock); +} + +void +zfs_mountlist_wunlock(void) +{ + + rw_wunlock(&mountlist_lock); +} + +void +zfs_mountlist_rlock(void) +{ + + rw_rlock(&mountlist_lock); +} + +void +zfs_mountlist_runlock(void) +{ + + rw_runlock(&mountlist_lock); +} diff --git a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c index a2532f8..045aa80 100644 --- a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c +++ b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c @@ -222,9 +222,9 @@ mount_snapshot(kthread_t *td, vnode_t **vpp, const char *fstype, char *fspath, vp->v_mountedhere = mp; /* Put the new filesystem on the mount list. */ - mtx_lock(&mountlist_mtx); + zfs_mountlist_wlock(); TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); - mtx_unlock(&mountlist_mtx); + zfs_mountlist_wunlock(); vfs_event_signal(NULL, VQ_MOUNT, 0); if (VFS_ROOT(mp, LK_EXCLUSIVE, &mvp)) panic("mount: lost mount"); diff --git a/sys/cddl/compat/opensolaris/sys/mount.h b/sys/cddl/compat/opensolaris/sys/mount.h index e012597..8ad4598 100644 --- a/sys/cddl/compat/opensolaris/sys/mount.h +++ b/sys/cddl/compat/opensolaris/sys/mount.h @@ -38,4 +38,9 @@ typedef struct fid fid_t; +void zfs_mountlist_wlock(void); +void zfs_mountlist_wunlock(void); +void zfs_mountlist_rlock(void); +void zfs_mountlist_runlock(void); + #endif /* !_OPENSOLARIS_SYS_MOUNT_H_ */ diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c index a829b06..4d86892 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c @@ -3015,14 +3015,14 @@ zfs_get_vfs(const char *resource) { vfs_t *vfsp; - mtx_lock(&mountlist_mtx); + zfs_mountlist_rlock(); TAILQ_FOREACH(vfsp, &mountlist, mnt_list) { if (strcmp(refstr_value(vfsp->vfs_resource), resource) == 0) { VFS_HOLD(vfsp); break; } } - mtx_unlock(&mountlist_mtx); + zfs_mountlist_runlock(); return (vfsp); } diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c index 415db9e..9b29323 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c @@ -2537,7 +2537,7 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) oldlen = strlen(oldname); - mtx_lock(&mountlist_mtx); + zfs_mountlist_rlock(); TAILQ_FOREACH(mp, &mountlist, mnt_list) { fromname = mp->mnt_stat.f_mntfromname; if (strcmp(fromname, oldname) == 0) { @@ -2554,6 +2554,6 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) continue; } } - mtx_unlock(&mountlist_mtx); + zfs_mountlist_runlock(); } #endif diff --git a/sys/compat/linprocfs/linprocfs.c b/sys/compat/linprocfs/linprocfs.c index 8607646..b39f194 100644 --- a/sys/compat/linprocfs/linprocfs.c +++ b/sys/compat/linprocfs/linprocfs.c @@ -344,7 +344,7 @@ linprocfs_domtab(PFS_FILL_ARGS) } lep_len = strlen(lep); - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); error = 0; TAILQ_FOREACH(mp, &mountlist, mnt_list) { /* determine device name */ @@ -387,7 +387,7 @@ linprocfs_domtab(PFS_FILL_ARGS) /* a real Linux mtab will also show NFS options */ sbuf_printf(sb, " 0 0\n"); } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); free(flep, M_TEMP); return (error); } diff --git a/sys/geom/journal/g_journal.c b/sys/geom/journal/g_journal.c index 9cc324c..bdef5d1 100644 --- a/sys/geom/journal/g_journal.c +++ b/sys/geom/journal/g_journal.c @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -2888,7 +2889,7 @@ g_journal_do_switch(struct g_class *classp) g_topology_unlock(); PICKUP_GIANT(); - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); TAILQ_FOREACH(mp, &mountlist, mnt_list) { if (mp->mnt_gjprovider == NULL) continue; @@ -2899,7 +2900,7 @@ g_journal_do_switch(struct g_class *classp) continue; if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) continue; - /* mtx_unlock(&mountlist_mtx) was done inside vfs_busy() */ + /* rw_runlock(&mountlist_lock) was done inside vfs_busy() */ DROP_GIANT(); g_topology_lock(); @@ -2977,10 +2978,10 @@ g_journal_do_switch(struct g_class *classp) vfs_write_resume(mp, 0); next: - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); vfs_unbusy(mp); } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); sc = NULL; for (;;) { diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c index 09fa7ed..da4b452 100644 --- a/sys/kern/vfs_mount.c +++ b/sys/kern/vfs_mount.c @@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -85,8 +86,8 @@ static uma_zone_t mount_zone; struct mntlist mountlist = TAILQ_HEAD_INITIALIZER(mountlist); /* For any iteration/modification of mountlist */ -struct mtx mountlist_mtx; -MTX_SYSINIT(mountlist, &mountlist_mtx, "mountlist", MTX_DEF); +struct rwlock mountlist_lock; +RW_SYSINIT(mountlist, &mountlist_lock, "mountlist"); /* * Global opts, taken by all filesystems @@ -852,9 +853,9 @@ vfs_domount_first( VI_UNLOCK(vp); vp->v_mountedhere = mp; /* Place the new filesystem at the end of the mount list. */ - mtx_lock(&mountlist_mtx); + rw_wlock(&mountlist_lock); TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); - mtx_unlock(&mountlist_mtx); + rw_wunlock(&mountlist_lock); vfs_event_signal(NULL, VQ_MOUNT, 0); if (VFS_ROOT(mp, LK_EXCLUSIVE, &newdp)) panic("mount: lost mount"); @@ -1161,13 +1162,13 @@ sys_unmount(td, uap) return (EINVAL); } - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); TAILQ_FOREACH_REVERSE(mp, &mountlist, mntlist, mnt_list) { if (mp->mnt_stat.f_fsid.val[0] == id0 && mp->mnt_stat.f_fsid.val[1] == id1) break; } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); } else { /* * Try to find global path for path argument. @@ -1181,12 +1182,12 @@ sys_unmount(td, uap) if (error == 0 || error == ENODEV) vput(nd.ni_vp); } - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); TAILQ_FOREACH_REVERSE(mp, &mountlist, mntlist, mnt_list) { if (strcmp(mp->mnt_stat.f_mntonname, pathbuf) == 0) break; } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); } free(pathbuf, M_TEMP); if (mp == NULL) { @@ -1353,9 +1354,9 @@ dounmount(mp, flags, td) VOP_UNLOCK(coveredvp, 0); return (error); } - mtx_lock(&mountlist_mtx); + rw_wlock(&mountlist_lock); TAILQ_REMOVE(&mountlist, mp, mnt_list); - mtx_unlock(&mountlist_mtx); + rw_wunlock(&mountlist_lock); EVENTHANDLER_INVOKE(vfs_unmounted, mp, td); if (coveredvp != NULL) { coveredvp->v_mountedhere = NULL; diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c index a050099..2ba1f36 100644 --- a/sys/kern/vfs_mountroot.c +++ b/sys/kern/vfs_mountroot.c @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -231,9 +232,9 @@ vfs_mountroot_devfs(struct thread *td, struct mount **mpp) TAILQ_INIT(opts); mp->mnt_opt = opts; - mtx_lock(&mountlist_mtx); + rw_wlock(&mountlist_lock); TAILQ_INSERT_HEAD(&mountlist, mp, mnt_list); - mtx_unlock(&mountlist_mtx); + rw_wunlock(&mountlist_lock); *mpp = mp; set_rootvnode(); @@ -257,7 +258,7 @@ vfs_mountroot_shuffle(struct thread *td, struct mount *mpdevfs) mpnroot = TAILQ_NEXT(mpdevfs, mnt_list); /* Shuffle the mountlist. */ - mtx_lock(&mountlist_mtx); + rw_wlock(&mountlist_lock); mporoot = TAILQ_FIRST(&mountlist); TAILQ_REMOVE(&mountlist, mpdevfs, mnt_list); if (mporoot != mpdevfs) { @@ -265,7 +266,7 @@ vfs_mountroot_shuffle(struct thread *td, struct mount *mpdevfs) TAILQ_INSERT_HEAD(&mountlist, mpnroot, mnt_list); } TAILQ_INSERT_TAIL(&mountlist, mpdevfs, mnt_list); - mtx_unlock(&mountlist_mtx); + rw_wunlock(&mountlist_lock); cache_purgevfs(mporoot); if (mporoot != mpdevfs) @@ -968,14 +969,14 @@ vfs_mountroot(void) * timestamps we encounter. */ timebase = 0; - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); mp = TAILQ_FIRST(&mountlist); while (mp != NULL) { if (mp->mnt_time > timebase) timebase = mp->mnt_time; mp = TAILQ_NEXT(mp, mnt_list); } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); inittodr(timebase); /* Keep prison0's root in sync with the global rootvnode. */ diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index fda80c9..de9ee7f 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -375,7 +375,7 @@ SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_FIRST, vntblinit, NULL); /* * Mark a mount point as busy. Used to synchronize access and to delay - * unmounting. Eventually, mountlist_mtx is not released on failure. + * unmounting. Eventually, mountlist_lock is not released on failure. * * vfs_busy() is a custom lock, it can block the caller. * vfs_busy() only sleeps if the unmount is active on the mount point. @@ -439,15 +439,15 @@ vfs_busy(struct mount *mp, int flags) return (ENOENT); } if (flags & MBF_MNTLSTLOCK) - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); mp->mnt_kern_flag |= MNTK_MWAIT; msleep(mp, MNT_MTX(mp), PVFS | PDROP, "vfs_busy", 0); if (flags & MBF_MNTLSTLOCK) - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); MNT_ILOCK(mp); } if (flags & MBF_MNTLSTLOCK) - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); mp->mnt_lockref++; MNT_IUNLOCK(mp); return (0); @@ -483,16 +483,16 @@ vfs_getvfs(fsid_t *fsid) struct mount *mp; CTR2(KTR_VFS, "%s: fsid %p", __func__, fsid); - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); TAILQ_FOREACH(mp, &mountlist, mnt_list) { if (mp->mnt_stat.f_fsid.val[0] == fsid->val[0] && mp->mnt_stat.f_fsid.val[1] == fsid->val[1]) { vfs_ref(mp); - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); return (mp); } } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); CTR2(KTR_VFS, "%s: lookup failed for %p id", __func__, fsid); return ((struct mount *) 0); } @@ -501,7 +501,7 @@ vfs_getvfs(fsid_t *fsid) * Lookup a mount point by filesystem identifier, busying it before * returning. * - * To avoid congestion on mountlist_mtx, implement simple direct-mapped + * To avoid congestion on mountlist_lock, implement simple direct-mapped * cache for popular filesystem identifiers. The cache is lockess, using * the fact that struct mount's are never freed. In worst case we may * get pointer to unmounted or even different filesystem, so we have to @@ -536,14 +536,14 @@ vfs_busyfs(fsid_t *fsid) vfs_unbusy(mp); slow: - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); TAILQ_FOREACH(mp, &mountlist, mnt_list) { if (mp->mnt_stat.f_fsid.val[0] == fsid->val[0] && mp->mnt_stat.f_fsid.val[1] == fsid->val[1]) { error = vfs_busy(mp, MBF_MNTLSTLOCK); if (error) { cache[hash] = NULL; - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); return (NULL); } cache[hash] = mp; @@ -551,7 +551,7 @@ slow: } } CTR2(KTR_VFS, "%s: lookup failed for %p id", __func__, fsid); - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); return ((struct mount *) 0); } @@ -909,18 +909,18 @@ vnlru_proc(void) } mtx_unlock(&vnode_free_list_mtx); done = 0; - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) { nmp = TAILQ_NEXT(mp, mnt_list); continue; } done += vlrureclaim(mp); - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); nmp = TAILQ_NEXT(mp, mnt_list); vfs_unbusy(mp); } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); if (done == 0) { #if 0 /* These messages are temporary debugging aids */ @@ -3413,7 +3413,7 @@ sysctl_vnode(SYSCTL_HANDLER_ARGS) return (error); xvn = malloc(len, M_TEMP, M_ZERO | M_WAITOK); n = 0; - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); TAILQ_FOREACH(mp, &mountlist, mnt_list) { if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) continue; @@ -3465,12 +3465,12 @@ sysctl_vnode(SYSCTL_HANDLER_ARGS) ++n; } MNT_IUNLOCK(mp); - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); vfs_unbusy(mp); if (n == len) break; } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); error = SYSCTL_OUT(req, xvn, n * sizeof *xvn); free(xvn, M_TEMP); diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 14be379..08f4bae 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -131,7 +131,7 @@ sys_sync(td, uap) struct mount *mp, *nmp; int save; - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) { nmp = TAILQ_NEXT(mp, mnt_list); @@ -145,11 +145,11 @@ sys_sync(td, uap) curthread_pflags_restore(save); vn_finished_write(mp); } - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); nmp = TAILQ_NEXT(mp, mnt_list); vfs_unbusy(mp); } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); return (0); } @@ -460,18 +460,18 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, sfsp = *buf; else /* if (bufseg == UIO_SYSSPACE) */ { count = 0; - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); TAILQ_FOREACH(mp, &mountlist, mnt_list) { count++; } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); if (maxcount > count) maxcount = count; sfsp = *buf = malloc(maxcount * sizeof(struct statfs), M_TEMP, M_WAITOK); } count = 0; - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { if (prison_canseemount(td->td_ucred, mp) != 0) { nmp = TAILQ_NEXT(mp, mnt_list); @@ -504,7 +504,7 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, if (((flags & (MNT_LAZY|MNT_NOWAIT)) == 0 || (flags & MNT_WAIT)) && (error = VFS_STATFS(mp, sp))) { - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); nmp = TAILQ_NEXT(mp, mnt_list); vfs_unbusy(mp); continue; @@ -527,11 +527,11 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, sfsp++; } count++; - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); nmp = TAILQ_NEXT(mp, mnt_list); vfs_unbusy(mp); } - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); if (sfsp && count > maxcount) td->td_retval[0] = maxcount; else diff --git a/sys/modules/zfs/Makefile b/sys/modules/zfs/Makefile index 29f4ae0..52f083d 100644 --- a/sys/modules/zfs/Makefile +++ b/sys/modules/zfs/Makefile @@ -25,6 +25,7 @@ SRCS+= opensolaris_dtrace.c SRCS+= opensolaris_kobj.c SRCS+= opensolaris_kstat.c SRCS+= opensolaris_lookup.c +SRCS+= opensolaris_mount.c SRCS+= opensolaris_policy.c SRCS+= opensolaris_string.c SRCS+= opensolaris_sysevent.c diff --git a/sys/sys/mount.h b/sys/sys/mount.h index 6fb2d08..376d613 100644 --- a/sys/sys/mount.h +++ b/sys/sys/mount.h @@ -39,6 +39,7 @@ #include #include #include +#include #include #endif @@ -147,7 +148,7 @@ struct vfsopt { * put on a doubly linked list. * * Lock reference: - * m - mountlist_mtx + * m - mountlist_lock * i - interlock * v - vnode freelist mutex * @@ -890,7 +891,7 @@ int vfs_suser(struct mount *, struct thread *); void vfs_unbusy(struct mount *); void vfs_unmountall(void); extern TAILQ_HEAD(mntlist, mount) mountlist; /* mounted filesystem list */ -extern struct mtx mountlist_mtx; +extern struct rwlock mountlist_lock; extern struct nfs_public nfs_pub; extern struct sx vfsconf_sx; #define vfsconf_lock() sx_xlock(&vfsconf_sx) -- 2.1.2 [1] https://wiki.freebsd.org/JuniorJobs#Convert_mountlist_mtx_to_rwlock Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 13:45:57 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B453AD66; Wed, 11 Mar 2015 13:45:57 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29471DDA; Wed, 11 Mar 2015 13:45:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426081528; l=762; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From: Date; bh=yABuP3lrNXtL4ie4CDeyReEI8sfW4/iPPwZfGeXJzAI=; b=oiw9N1H2Efb9y6rgRNlX2+/EOoEBNg96/EB1LyoPE3U6LCkhhuIR5uEVyGXrHQs6aiK Cfl2Ft+HyQulqLALdADhZw1wBjh+tMdtLYmozn5BhpuSeiUGxuVn4rB2oZEL6hUDB+qPx +L4S6sBg64nfONF925gfeyU1ACad+nC1L1k= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgkO4q1xDEhkgOJDsXNs= X-RZG-CLASS-ID: mo00 Received: from fuckner.delnet ([85.183.0.195]) by smtp.strato.de (RZmta 37.3 AUTH) with ESMTPA id 003b59r2BDjSZ94; Wed, 11 Mar 2015 14:45:28 +0100 (CET) Message-ID: <550046F7.1050205@fuckner.net> Date: Wed, 11 Mar 2015 14:45:27 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org Subject: Server with 3TB Crashing at boot Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 13:45:57 -0000 Hi, I have a server with 4 Xeon E7-8857 v2 and 96x32TB, organized as 8 Memory Risers with 12DIMMs each. With 2 Risers I can boot the System with FreeBSD10.1-p6, when adding a third riser (above 1TB RAM) the system crashes on boot. http://dedi3.fuckner.net/~molli123/temp/3tb_ap1_phy2.png http://dedi3.fuckner.net/~molli123/temp/3tb_crash.avi Here is the dmesg/ verbose dmesg, but I believe the verbose one got truncated. Is there anything more I can do than booting verbose and to copy /var/run/dmesg.boot? http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_verbose.txt http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_10.1.txt Regards, Michael! PS: already posted to freebsd-amd64, but I was told these lists are better. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 15:19:44 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2D59732 for ; Wed, 11 Mar 2015 15:19:44 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3826BCAA for ; Wed, 11 Mar 2015 15:19:44 +0000 (UTC) Received: by wesw55 with SMTP id w55so10006521wes.3 for ; Wed, 11 Mar 2015 08:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=nJj0sbVvLXkenwXJRPoqw1EEhVHf13NgctWjnfXcBug=; b=p/fayqc8odWQbpb2VY2NrjOIjg9C2xUCGyTe8dZy8j3MwNkLWvefaJ85xpLxBTF3AK m0Q0VjlGRWzFXbolqxvAI7gn940Ci7JxN9+V5cuCWDSWD6LSkhzoGbOTPuRZxcIcAOec oTaZT9y8hyWEwFgytKMwj4PXbE0oCQq3uf8D88ke268bSuyjY0+7FHxe9UIotvrlVpIE zVg1aYcCBQKMIhlp1umCtlnKfvxnAAnc6dflIMGk4r5uXUA6t8Ja/x8Z4ym4w03fCduD UrYBGL0C5dnleEennXJ4cICLucGC9Jx9zb5U7SSnMDaOF4yY3kVvG20qE9cFFO4jcV8E C59A== X-Received: by 10.180.86.35 with SMTP id m3mr80667127wiz.83.1426087182653; Wed, 11 Mar 2015 08:19:42 -0700 (PDT) Received: from localhost ([217.14.212.217]) by mx.google.com with ESMTPSA id lu13sm6555563wic.10.2015.03.11.08.19.41 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 11 Mar 2015 08:19:42 -0700 (PDT) Date: Wed, 11 Mar 2015 16:19:36 +0100 From: To: hackers@freebsd.org Subject: Making release Message-ID: <20150311161936.0000658f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:19:44 -0000 So I've updated my 10.1 RELEASE i386 to patch p6 and decided to have *.txz = generic binaries by building my own release Not in chroot: After make of world and kernel, I decided to build release only for ftp # make ftp # make install DESTDIR=3D/tmp This step: Fills /tmp/ftp/*.txz and I expected layout as /tmp/ftp/i386/10.1-RELEAS= E-p6/*.txz, as on ftp://ftp.freebsd.org Arch and version actually are part of image media name. If not ALL is being built, install will error about not founding cd/dvd= image, which is next what it tries to install. Make target 'install' simply doesn't checks for what has actually been = built. Domagoj Smol=C4=8Di=C4=87 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 15:19:58 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99E3B813 for ; Wed, 11 Mar 2015 15:19:58 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22DDACAF for ; Wed, 11 Mar 2015 15:19:58 +0000 (UTC) Received: by wghk14 with SMTP id k14so9993716wgh.7 for ; Wed, 11 Mar 2015 08:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5erSJKJNHKZqFqp5+9AUmm0Tlg6N00nhwRGzPHoQwp8=; b=P2Ki2GojbdldePb2s5iF8N1lOzDb5io86rTrtqml1oghGL5GPjIroYDJaDiU3Ov2tz GlYCryRvhVA2MgXtgEQk8mR4SDiMXH1yVNvB5r+6Yi1tKNU3vnbtLR6tEKrUCtYvMqEW emncimOsvXAgj60k8YZGNVA3Jj9Tr7s7BhFTrew+gXv+bBQ8f13joT2H1kLV3+qOORJz IafOYY7JJNMv81OlP0kPxKMLdvmkZUAQa/Wv5qoLA0a6VETIBrBuQ1gFEO5V7QVAVzUf CKDN7DA7ow8crsfKSjlWN8fvTPbFhrV/oPE+U0UqEuHKzTvnt1PqWOz10xmbZ2zKHdkQ yS9Q== MIME-Version: 1.0 X-Received: by 10.194.86.194 with SMTP id r2mr80640766wjz.41.1426087196349; Wed, 11 Mar 2015 08:19:56 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.17.129 with HTTP; Wed, 11 Mar 2015 08:19:56 -0700 (PDT) In-Reply-To: <20150311095556.1ed29f5d@ernst.home> References: <9F2E1411-B517-4BC8-AF61-BB15EE35083C@me.com> <54FF1343.1020705@gmx.de> <20150311095556.1ed29f5d@ernst.home> Date: Wed, 11 Mar 2015 09:19:56 -0600 X-Google-Sender-Auth: MM_2iiozsyyxPw_pPNK6CVZyG2Q Message-ID: Subject: Re: detecting hyperthreading From: Alan Somers To: gljennjohn@gmail.com Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "lokadamus@gmx.de" , "Pokala, Ravi" , Rui Paulo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:19:58 -0000 On Wed, Mar 11, 2015 at 2:55 AM, Gary Jennejohn wrote: > On Tue, 10 Mar 2015 10:07:19 -0600 > Alan Somers wrote: > >> On Tue, Mar 10, 2015 at 10:02 AM, Freddie Cash wrote: >> > On Tue, Mar 10, 2015 at 8:56 AM, Pokala, Ravi wrote: >> > >> >> -----Original Message----- >> >> From: "lokadamus@gmx.de" >> >> Date: 2015-03-10, Tuesday at 08:52 >> >> To: Ravi Pokala , Rui Paulo >> >> Cc: "freebsd-hackers@freebsd.org" >> >> Subject: Re: detecting hyperthreading >> >> >> >> >Have you look at dmesg? >> >> >My system is a P4 with HTT. >> >> >dmesg |more >> >> [...] >> >> >CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.00-MHz 686-class CPU) >> >> > Origin = "GenuineIntel" Id = 0xf29 Family = 0xf Model = 0x2 >> >> >Stepping = 9 >> >> > >> >> >Features=0xbfebfbff> >> >CA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >> >> > Features2=0x4400 >> >> >> >> Of course. :-) >> >> >> >> But there are two problems: >> >> >> >> (1) That just tells me HTT is supported by the CPU, not that if kernel is >> >> using it. >> >> (2) It's difficult to parse. >> >> >> >> Of the two, (1) is the bigger concern for my use-case. >> >> >> > >> > 6 lines or so below the Features line shows the kernel loading "cpu0 >> > (BSP)", and then "cpu1 (AP/HT)". >> > >> > Compare that to a system without HTT, where any extra cpus only show "(AP)". >> > >> > It's not perfect, but one could grep through /var/run/dmesg.boot looking >> > for "cpu" lines and checking for "(AP)" or "(AP/HT)". >> > >> > -- >> > Freddie Cash >> > fjwcash@gmail.com >> >> I always look at "sysctl kern.sched.topology_spec" to tell if >> hyperthreading is enabled. It's overkill, but it works. >> > [snip Ruby] > > Is this ULE-specific? This OID isn't present on my box using the > BSD scheduler. Something to be aware of. > > -- > Gary Jennejohn I never noticed because I don't use the BSD scheduler. But now that you mention it, yes it is. The OID is defined in kern/sched_ule.c. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 15:26:04 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D73FC96; Wed, 11 Mar 2015 15:26:04 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D83FDDCC; Wed, 11 Mar 2015 15:26:03 +0000 (UTC) Received: by iecsl2 with SMTP id sl2so116200iec.1; Wed, 11 Mar 2015 08:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Vf51ZYMJuXZzVhBfNqlwBQ2DckKqdg0Uv83vBYlnHNU=; b=ztY+VjHERQsS3FrLqzjJcKKbiT4k4Rt9as10vTi4+TEHqWQg3SgmRhEuTqqQBsZRb5 KkmfPnilUgBYv1jwdjXl/rdRMelYpwhvev8FW5Jt0v/Lg7qCi7ezPhHnOawXwEiWvv0z lwel5Se+QKxadxQ9BhUMmyDJ3BDWi2+SIbu0+JqHSbbWDss8W6SRvIKZaSOhBXzXo/+l 32k13pECOTBEheg5wcNCvFkG5hF1HPxee1yT5fdm9nV9zAeWEbXiN1A4SZsPj4zd22h6 ZSVpVX0wX+i3MKkEh5bksHV6n5n/oW4LdRJmnZUHkkdCAkSxu4oUvz5TcTSb8T+PbCiy c2kQ== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr91370111igb.6.1426087563230; Wed, 11 Mar 2015 08:26:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 11 Mar 2015 08:26:03 -0700 (PDT) In-Reply-To: <550046F7.1050205@fuckner.net> References: <550046F7.1050205@fuckner.net> Date: Wed, 11 Mar 2015 08:26:03 -0700 X-Google-Sender-Auth: B8kNdPWRBiNOd_Jtqqq_FwTuLuI Message-ID: Subject: Re: Server with 3TB Crashing at boot From: Adrian Chadd To: Michael Fuckner Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:26:04 -0000 Hm, have you tried with just one TB of RAM? I haven't had access to systems with 3TB of RAM - I'm just about to get 1TB in a box. :) Hm, other hackers - what's the current size of the AMD64 direct map? -adrian On 11 March 2015 at 06:45, Michael Fuckner wrote: > Hi, > > I have a server with 4 Xeon E7-8857 v2 and 96x32TB, organized as 8 Memory > Risers with 12DIMMs each. With 2 Risers I can boot the System with > FreeBSD10.1-p6, when adding a third riser (above 1TB RAM) the system crashes > on boot. > > > http://dedi3.fuckner.net/~molli123/temp/3tb_ap1_phy2.png > http://dedi3.fuckner.net/~molli123/temp/3tb_crash.avi > > > Here is the dmesg/ verbose dmesg, but I believe the verbose one got > truncated. Is there anything more I can do than booting verbose and to copy > /var/run/dmesg.boot? > > http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_verbose.txt > http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_10.1.txt > > Regards, > Michael! > > PS: already posted to freebsd-amd64, but I was told these lists are better. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 15:39:10 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4321430F for ; Wed, 11 Mar 2015 15:39:10 +0000 (UTC) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04151F14 for ; Wed, 11 Mar 2015 15:39:09 +0000 (UTC) Received: by ykp9 with SMTP id 9so4366038ykp.8 for ; Wed, 11 Mar 2015 08:39:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ytf5ZxlxyjncP7cJXNgGTcOOf1PjzaShxD9KJvPJqwA=; b=h/rzVjS/egmXZmon+hP8VgEPQ3rQ4Uw6MYJM5nRRhdPAx6940pec2gz3pEbQSam4FR YJduBRw6NtfxFNKOMcJlQNdYygEhmuhZdD5OuXZFlOt9+gMCm5oF5t4rbYp9t0MJNouG JIxBVf7CkWE17F8BjqA34nBCz7ZAFIjtg3YpvPwy22ct43bjLtZqe4bRDFCn3fB5/p5a zZAJf7mhRa7f7BO1q7GB3/d9URORpOu1oZqVj/7PrslRlLJq1OBtlC2Vh9HxuAJmbRf7 +FFMC/yJfztaC5qrjOouyGQ1U2BKITOeGdX42bvZWSfLobU3LTBNpIQtOLlYanymUNyb pIEg== X-Gm-Message-State: ALoCoQl/V6ZAH0JeB0H++POruM8Nmu5T0LnyccSOZHx2d/rrSIUkbhOj6USkzdPDSdPclwqlBxNo MIME-Version: 1.0 X-Received: by 10.236.209.137 with SMTP id s9mr37749605yho.45.1426088348728; Wed, 11 Mar 2015 08:39:08 -0700 (PDT) Received: by 10.170.104.86 with HTTP; Wed, 11 Mar 2015 08:39:08 -0700 (PDT) In-Reply-To: References: <550046F7.1050205@fuckner.net> Date: Wed, 11 Mar 2015 16:39:08 +0100 Message-ID: Subject: Re: Server with 3TB Crashing at boot From: Oliver Pinter To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Michael Fuckner , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:39:10 -0000 On Wed, Mar 11, 2015 at 4:26 PM, Adrian Chadd wrote: > Hm, have you tried with just one TB of RAM? I haven't had access to > systems with 3TB of RAM - I'm just about to get 1TB in a box. :) > > Hm, other hackers - what's the current size of the AMD64 direct map? 4TB - https://github.com/freebsd/freebsd/blob/master/sys/amd64/include/vmparam.h#L157 > > > > -adrian > > > On 11 March 2015 at 06:45, Michael Fuckner wrote: >> Hi, >> >> I have a server with 4 Xeon E7-8857 v2 and 96x32TB, organized as 8 Memory >> Risers with 12DIMMs each. With 2 Risers I can boot the System with >> FreeBSD10.1-p6, when adding a third riser (above 1TB RAM) the system crashes >> on boot. >> >> >> http://dedi3.fuckner.net/~molli123/temp/3tb_ap1_phy2.png >> http://dedi3.fuckner.net/~molli123/temp/3tb_crash.avi >> >> >> Here is the dmesg/ verbose dmesg, but I believe the verbose one got >> truncated. Is there anything more I can do than booting verbose and to copy >> /var/run/dmesg.boot? >> >> http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_verbose.txt >> http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_10.1.txt >> >> Regards, >> Michael! >> >> PS: already posted to freebsd-amd64, but I was told these lists are better. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 17:08:21 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC53AFB4 for ; Wed, 11 Mar 2015 17:08:21 +0000 (UTC) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47E50C7C for ; Wed, 11 Mar 2015 17:08:21 +0000 (UTC) Received: from [10.11.0.122] (a83-163-239-115.adsl.xs4all.nl [83.163.239.115]) (authenticated bits=0) by weser.webweaving.org (8.14.9/8.14.9) with ESMTP id t2BGclBd075454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2015 17:38:48 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host a83-163-239-115.adsl.xs4all.nl [83.163.239.115] claimed to be [10.11.0.122] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Subject: Re: Server with 3TB Crashing at boot From: Dirk-Willem van Gulik In-Reply-To: Date: Wed, 11 Mar 2015 17:38:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <664C3D0B-932E-4350-94BC-FFC5F7CD4A2B@webweaving.org> References: <550046F7.1050205@fuckner.net> To: Adrian Chadd X-Mailer: Apple Mail (2.2087) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Wed, 11 Mar 2015 17:38:49 +0100 (CET) Cc: "freebsd-hackers@freebsd.org" , Michael Fuckner , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 17:08:21 -0000 > On 11 Mar 2015, at 16:26, Adrian Chadd wrote: >=20 > Hm, have you tried with just one TB of RAM? I haven't had access to > systems with 3TB of RAM - I'm just about to get 1TB in a box. :) >=20 > Hm, other hackers - what's the current size of the AMD64 direct map? Since 10.0 - = https://svnweb.freebsd.org/base?view=3Drevision&revision=3D254466 has = made 2Tbyte work reliably for me. Dw. *: See also [amd64] The maximum amount of memory the FreeBSD kernel can = address has been increased from 1TB to 4TB in relnotes of = https://www.freebsd.org/releases/10.0R/relnotes.html= From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 17:34:53 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0E99796; Wed, 11 Mar 2015 17:34:53 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7752DF82; Wed, 11 Mar 2015 17:34:53 +0000 (UTC) Received: by wiwl15 with SMTP id l15so41015973wiw.4; Wed, 11 Mar 2015 10:34:52 -0700 (PDT) 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=+7qdx+Ua335ymtIEle9CudANe36LxrVLQ3b1FuY+sK4=; b=vIFyLIkjd5wc281C6znUhYZiDst+sRqSKqAQ+PK8RXjBnhcCro+7oDOWCqZl7361wJ IE8CP7XntNvE450N1JwUlZm/oHhoQsAgGN6EbwIXjmXA2aV61mnXgtdsj3hvtRnCYKge HgKMxwRTS3Fe262qvdXWZhzAg7iYAYJmnYuXfsGdRD7NRiihNl3b7jCtXkfQ2hoI+/FS CrX/yB9u1nRZ3Bt8fuBwMDUT1gosXlmHZ21rlOkDb8TAhjsLdCvLPNk7EVOMpKMDmrRD XsnH4KB1Cx2rUC8xMEQGjPLYsDK2h0E4i5/smigO6C34K6ZBf3ND2H28otFqAO013xvf BPfQ== MIME-Version: 1.0 X-Received: by 10.194.6.228 with SMTP id e4mr78631050wja.63.1426095291942; Wed, 11 Mar 2015 10:34:51 -0700 (PDT) Received: by 10.27.91.79 with HTTP; Wed, 11 Mar 2015 10:34:51 -0700 (PDT) In-Reply-To: <550046F7.1050205@fuckner.net> References: <550046F7.1050205@fuckner.net> Date: Wed, 11 Mar 2015 10:34:51 -0700 Message-ID: Subject: Re: Server with 3TB Crashing at boot From: Neel Natu To: Michael Fuckner Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 17:34:54 -0000 Hi Michael, On Wed, Mar 11, 2015 at 6:45 AM, Michael Fuckner wrote: > Hi, > > I have a server with 4 Xeon E7-8857 v2 and 96x32TB, organized as 8 Memory > Risers with 12DIMMs each. With 2 Risers I can boot the System with > FreeBSD10.1-p6, when adding a third riser (above 1TB RAM) the system crashes > on boot. > Can you try to boot the system with SMP disabled and more than 2 risers populated? LOADER> set kern.smp.disabled=1 best Neel > > http://dedi3.fuckner.net/~molli123/temp/3tb_ap1_phy2.png > http://dedi3.fuckner.net/~molli123/temp/3tb_crash.avi > > > Here is the dmesg/ verbose dmesg, but I believe the verbose one got > truncated. Is there anything more I can do than booting verbose and to copy > /var/run/dmesg.boot? > > http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_verbose.txt > http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_10.1.txt > > Regards, > Michael! > > PS: already posted to freebsd-amd64, but I was told these lists are better. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 19:08:13 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEB81128 for ; Wed, 11 Mar 2015 19:08:13 +0000 (UTC) Received: from mail.westryn.net (mail.westryn.net [199.48.135.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF98ACDA for ; Wed, 11 Mar 2015 19:08:13 +0000 (UTC) Received: from ice.westryn.net (225x169.ouraynet.com [204.16.225.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.westryn.net (Postfix) with ESMTPSA id 73C5F94323E for ; Wed, 11 Mar 2015 13:01:07 -0600 (MDT) From: Kim Shrier Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: file system change notifications Message-Id: Date: Wed, 11 Mar 2015 13:01:06 -0600 To: FreeBSD Hackers Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:08:13 -0000 I have a project where I need to notice changes to files in a large = directory tree. I noticed that there was a project in GSOC 2010 to implement such a = feature. https://wiki.freebsd.org/SOC2010IlyaPutsikau=20 It appears that it was never completed. Is it desirable to have this = project completed and added into FreeBSD. Or, is there another way to get file system change notifications? Kim From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 19:13:42 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE658553; Wed, 11 Mar 2015 19:13:42 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 92F17DC7; Wed, 11 Mar 2015 19:13:42 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2BJDctW016867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Mar 2015 12:13:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <550093DD.5040603@freebsd.org> Date: Wed, 11 Mar 2015 12:13:33 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Oliver Pinter , Adrian Chadd Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Michael Fuckner , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:13:43 -0000 On 3/11/15 8:39 AM, Oliver Pinter wrote: > On Wed, Mar 11, 2015 at 4:26 PM, Adrian Chadd wrote: >> Hm, have you tried with just one TB of RAM? I haven't had access to >> systems with 3TB of RAM - I'm just about to get 1TB in a box. :) >> >> Hm, other hackers - what's the current size of the AMD64 direct map? > 4TB - https://github.com/freebsd/freebsd/blob/master/sys/amd64/include/vmparam.h#L157 yeah but since direct-map is, well, directly mapped, you might have 3TB of ram but it might be spread over a larger range. there may be holes in it.. it would be worth knowing the apparent layout of the ram. > >> >> >> -adrian >> >> >> On 11 March 2015 at 06:45, Michael Fuckner wrote: >>> Hi, >>> >>> I have a server with 4 Xeon E7-8857 v2 and 96x32TB, organized as 8 Memory >>> Risers with 12DIMMs each. With 2 Risers I can boot the System with >>> FreeBSD10.1-p6, when adding a third riser (above 1TB RAM) the system crashes >>> on boot. >>> >>> >>> http://dedi3.fuckner.net/~molli123/temp/3tb_ap1_phy2.png >>> http://dedi3.fuckner.net/~molli123/temp/3tb_crash.avi >>> >>> >>> Here is the dmesg/ verbose dmesg, but I believe the verbose one got >>> truncated. Is there anything more I can do than booting verbose and to copy >>> /var/run/dmesg.boot? >>> >>> http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_verbose.txt >>> http://dedi3.fuckner.net/~molli123/temp/dmesg_q71l-4u_10.1.txt >>> >>> Regards, >>> Michael! >>> >>> PS: already posted to freebsd-amd64, but I was told these lists are better. >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 20:36:49 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36E5F51C for ; Wed, 11 Mar 2015 20:36:49 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EE4869E3 for ; Wed, 11 Mar 2015 20:36:48 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id E8E49B80F0; Wed, 11 Mar 2015 21:36:45 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id D491D28494; Wed, 11 Mar 2015 21:36:45 +0100 (CET) Date: Wed, 11 Mar 2015 21:36:45 +0100 From: Jilles Tjoelker To: Matt Tagg Subject: Re: find with -delete option on absolute paths Message-ID: <20150311203645.GA30268@stack.nl> References: 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) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 20:36:49 -0000 On Tue, Mar 10, 2015 at 08:31:52PM -0700, Matt Tagg wrote: > I believe this was discussed previously (2013), though I could not > find a resolution. > To recap, suppose we try deleting files on an absolute path: > matt@mtbook:/% find /tmp/foo/* -delete > find: -delete: /tmp/foo/bar.txt: relative path potentially not safe > As you can see it gives an error and quits. However if we instead try this: > matt@mtbook:/% gfind /tmp/foo/* -delete > GNU Find throws no error and works as expected ('bar.txt is deleted') > So as an end user, I find this rather confusing. How can I get the > same behavior with BSD Find out of the box? You can get the same behaviour by upgrading to FreeBSD 10 or newer. Before FreeBSD 10.0, find -delete did not allow deleting files given as arguments. This was because of an incorrect check and was fixed in SVN r253886. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 21:54:25 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFFEB5F2 for ; Wed, 11 Mar 2015 21:54:25 +0000 (UTC) Received: from mail.westryn.net (mail.westryn.net [199.48.135.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD624281 for ; Wed, 11 Mar 2015 21:54:25 +0000 (UTC) Received: from ice.westryn.net (225x169.ouraynet.com [204.16.225.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.westryn.net (Postfix) with ESMTPSA id 355E394323E; Wed, 11 Mar 2015 15:54:23 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: file system change notifications From: Kim Shrier In-Reply-To: Date: Wed, 11 Mar 2015 15:54:21 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: To: FreeBSD Hackers X-Mailer: Apple Mail (2.2070.6) Cc: int0dster@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 21:54:25 -0000 On Mar 11, 2015, at 1:14 PM, Ivan Krivonos wrote: > > Hi, > > Have not read this paper, but why just don`t kqueue() ? > Apparently, you have to have a file descriptor for every file you want to monitor, if I read things right. This is prohibitive with 100,000+ files. It also means that you cannot unmount a file system if you are monitoring any files in it, since the file system is considered busy. Kim From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 22:11:16 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 463FFD02 for ; Wed, 11 Mar 2015 22:11:16 +0000 (UTC) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0705C688 for ; Wed, 11 Mar 2015 22:11:15 +0000 (UTC) Received: by yhaf73 with SMTP id f73so6149732yha.12 for ; Wed, 11 Mar 2015 15:11:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QZ3Hqpq7gqtfDxvRkLoviM/H91mCVBGTf3SMqjtC3ok=; b=FeKMK6z93Ska9ohAOxw8YAp2Qu5grrD/mOFNI0yyU/1fbiNWGxqnIMBLz2zIhwuYmp GqoDsWyQbYX0Ej52JaAoXS+vf472U2iIl9nUdlRwIIfxAIA/jFYnEJoE8ARt0+P2LIBh 1wUvstds8J8gfdcouDTfbBLB12Bn2SmYhilBdH2omNHpig91a6UFCi+VaAnTaZPWGFNy pJ2JHOvxW70MCbbHo3JB+xJoKMACpRTvQfmGpglYKtz7woUuEwy/8GS6IqEFvJhwTLSM m0+qAg7hEd0FcSJ9zJSLfk1ieYFjnsuMectSbQWKzoPaO/Xgk3MGKswcVgXAo9IWk0+T usrA== X-Gm-Message-State: ALoCoQlvaMwe967WT0hN1P928VBeMpdEHTITptHtC8Zqtx0nIciTSv3W/T2+kVZElfapFRXM95yF MIME-Version: 1.0 X-Received: by 10.236.209.137 with SMTP id s9mr39338300yho.45.1426111874433; Wed, 11 Mar 2015 15:11:14 -0700 (PDT) Received: by 10.170.104.86 with HTTP; Wed, 11 Mar 2015 15:11:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Mar 2015 23:11:14 +0100 Message-ID: Subject: Re: file system change notifications From: Oliver Pinter To: Kim Shrier , Shawn Webb Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , int0dster@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 22:11:16 -0000 Take a look at dazuko kernel module. Probably you should forward port them, because they are obsoleted. On Wed, Mar 11, 2015 at 10:54 PM, Kim Shrier wrote: > On Mar 11, 2015, at 1:14 PM, Ivan Krivonos wrote: >> >> Hi, >> >> Have not read this paper, but why just don`t kqueue() ? >> > > Apparently, you have to have a file descriptor for every file you want to > monitor, if I read things right. This is prohibitive with 100,000+ files. > It also means that you cannot unmount a file system if you are monitoring > any files in it, since the file system is considered busy. > > Kim > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 22:47:05 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD7B384D for ; Wed, 11 Mar 2015 22:47:05 +0000 (UTC) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 50864A53 for ; Wed, 11 Mar 2015 22:47:04 +0000 (UTC) Received: from ppp118-210-187-121.lns20.adl6.internode.on.net (HELO midget.dons.net.au) ([118.210.187.121]) by ipmail06.adl6.internode.on.net with ESMTP; 12 Mar 2015 09:16:42 +1030 Received: from [10.0.2.26] ([10.0.2.26]) (authenticated bits=0) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPSA id t2BMkZvP030045 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 09:16:40 +1030 (CST) (envelope-from darius@dons.net.au) Subject: Re: file system change notifications Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: "O'Connor, Daniel" In-Reply-To: Date: Thu, 12 Mar 2015 09:16:34 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au> References: To: Kim Shrier X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -2.899 () ALL_TRUSTED,BAYES_00,URIBL_BLOCKED X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 22:47:05 -0000 > On 12 Mar 2015, at 05:31, Kim Shrier wrote: > I have a project where I need to notice changes to files in a large = directory tree. > I noticed that there was a project in GSOC 2010 to implement such a = feature. >=20 > https://wiki.freebsd.org/SOC2010IlyaPutsikau=20 >=20 > It appears that it was never completed. Is it desirable to have this = project > completed and added into FreeBSD. Or, is there another way to get = file > system change notifications? The 'standard' way is kqueue + masses of file descriptors. I am looking at using auditpipe(4) since you can register to be notified = for all file modifications and you get a path. I wrote some test code at = https://gist.github.com/DanielO/e36de242e79fed3fe4f7 Ideally we could add an inotify() syscall although I think that is still = suboptimal since you need to add a watch per directory so it can be = relatively expensive to setup. That said working out what to do in the = face of links and so on is tricky.. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 22:48:38 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72DEFA77 for ; Wed, 11 Mar 2015 22:48:38 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC89BA6D for ; Wed, 11 Mar 2015 22:48:37 +0000 (UTC) Received: by wghk14 with SMTP id k14so12550798wgh.3 for ; Wed, 11 Mar 2015 15:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=gpp5KutUGN5uEM3yXkmJDJNy9Wmxpt1WTEQzltkXNZA=; b=JTFjxmLH+EEp7/UvB64fVv7G6eB/NbjDPQh4eNaYtl4JbvPI6Tjfu38wyOL3WWE730 bZ6mNFiDQ5Dz2o6jDmy3LqHHuo3w3iUdi/lBpk5d0dXsTAq4DwMMUBT579/tNNx5RyYw tZRuu+2lTQoqefutCLO5X3xTtOEW60zQ8jWCxAIgCIQIUJ2umuLJH8pikohvCkJvwXYs 3f3bWnvOfKJI2dPDDCHDSyHelspIGX4tPA7jliFPQbZ/xUKq8hvd5A98ehr3+mmzQbbz wmF3kzu+hZ/L2/STQXL8tOINL//m0hl7IRncDvN5l5GJOM5QYzcj07TznTljlY15Bm5n SilQ== X-Received: by 10.180.87.66 with SMTP id v2mr4991103wiz.51.1426114116397; Wed, 11 Mar 2015 15:48:36 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id 17sm7315562wjt.45.2015.03.11.15.48.34 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 11 Mar 2015 15:48:35 -0700 (PDT) Date: Wed, 11 Mar 2015 23:48:31 +0100 From: Mateusz Guzik To: Oliver Pinter Subject: Re: file system change notifications Message-ID: <20150311224831.GB18699@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Oliver Pinter , Kim Shrier , Shawn Webb , FreeBSD Hackers , int0dster@gmail.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: int0dster@gmail.com, FreeBSD Hackers , Shawn Webb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 22:48:38 -0000 On Wed, Mar 11, 2015 at 11:11:14PM +0100, Oliver Pinter wrote: > Take a look at dazuko kernel module. Probably you should forward port > them, because they are obsoleted. > I checked the module out of curiosity. Their approach was to wrap various syscalls and work from there. This is used to be the common approach several years back it has a lot of shortcomings, complete lack of reliability being the biggest one. As for better implementation: current namecache does not guarantee name resolution (even if name was entered) and not all names end up in the cache in the first place. Lack of reliability comes from the fact that the cache does not pin vnodes in any way. The cache is also protected with one sx lock and requires users to get and drop refs during lookups. As such, I would say that the best course of action is implementing new cache instead of hacking current implementatin. Then something could be made on top of that. > On Wed, Mar 11, 2015 at 10:54 PM, Kim Shrier wrote: > > On Mar 11, 2015, at 1:14 PM, Ivan Krivonos wrote: > >> > >> Hi, > >> > >> Have not read this paper, but why just don`t kqueue() ? > >> > > > > Apparently, you have to have a file descriptor for every file you want to > > monitor, if I read things right. This is prohibitive with 100,000+ files. > > It also means that you cannot unmount a file system if you are monitoring > > any files in it, since the file system is considered busy. > > > > Kim > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 23:18:50 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 958AFBD for ; Wed, 11 Mar 2015 23:18:50 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 418ECD86 for ; Wed, 11 Mar 2015 23:18:50 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2BNIboU092815; Wed, 11 Mar 2015 15:18:41 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503112318.t2BNIboU092815@gw.catspoiler.org> Date: Wed, 11 Mar 2015 16:18:37 -0700 (PDT) From: Don Lewis Subject: Re: file system change notifications To: mjguzik@gmail.com In-Reply-To: <20150311224831.GB18699@dft-labs.eu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-hackers@FreeBSD.org, int0dster@gmail.com, oliver.pinter@hardenedbsd.org, shawn.webb@hardenedbsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 23:18:50 -0000 On 11 Mar, Mateusz Guzik wrote: > On Wed, Mar 11, 2015 at 11:11:14PM +0100, Oliver Pinter wrote: >> Take a look at dazuko kernel module. Probably you should forward port >> them, because they are obsoleted. >> > > I checked the module out of curiosity. Their approach was to wrap various > syscalls and work from there. This is used to be the common approach > several years back it has a lot of shortcomings, complete lack of > reliability being the biggest one. > > As for better implementation: current namecache does not guarantee name > resolution (even if name was entered) and not all names end up in the > cache in the first place. > > Lack of reliability comes from the fact that the cache does not pin > vnodes in any way. I seem to recall reading a long time ago that DragonFly pins directories in the cache, or something like that. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 23:44:03 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 896FA44D for ; Wed, 11 Mar 2015 23:44:03 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49A26FEC for ; Wed, 11 Mar 2015 23:44:02 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2BNhm2I017747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Mar 2015 16:43:49 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5500D32D.30703@freebsd.org> Date: Wed, 11 Mar 2015 16:43:41 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "O'Connor, Daniel" , Kim Shrier Subject: Re: file system change notifications References: <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au> In-Reply-To: <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 23:44:03 -0000 On 3/11/15 3:46 PM, O'Connor, Daniel wrote: >> On 12 Mar 2015, at 05:31, Kim Shrier wrote: >> I have a project where I need to notice changes to files in a large directory tree. >> I noticed that there was a project in GSOC 2010 to implement such a feature. >> >> https://wiki.freebsd.org/SOC2010IlyaPutsikau >> >> It appears that it was never completed. Is it desirable to have this project >> completed and added into FreeBSD. Or, is there another way to get file >> system change notifications? > The 'standard' way is kqueue + masses of file descriptors. > > I am looking at using auditpipe(4) since you can register to be notified for all file modifications and you get a path. > > I wrote some test code at https://gist.github.com/DanielO/e36de242e79fed3fe4f7 > > Ideally we could add an inotify() syscall although I think that is still suboptimal since you need to add a watch per directory so it can be relatively expensive to setup. That said working out what to do in the face of links and so on is tricky.. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > I think there are a few things that could lead to a relatively efficient way of doing this.. if you wanted to watch all the files in a subtree, you should be able to put an annotation in the vnode of base of that subtree, that would indicate that fact. Then you could modify lookup/namei so that any vnode returned from that lookup, that went past that notification would also get the annotation. Obviously if the lookup was relative then the anotation initial state would be inherrited from the start point (CWD?). you woudl have to be ready to remove annotations on the way down (..) but that seems doable. The annotations would refer to a specific kevent item and child processes inherritance rules would work as per normal. each vnode coudl end up being watched by many kevents so therw woudl have ot be some many to many mapping.. a cancelled kevent woudl need ot be able to remove all related anotations, and a touched file woudl need to be able to make several notifications. The "hole" would be that vnodes that already exist within the watched zone would not have the anotation, so you'd have to do root-wards searches to add them when the zone was added (or just live with that). If you search downwards towards root you have to add any annotation you find on any ancestor vnode. but all file activities have to start with an opened vnode somewhere. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 01:09:03 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FFF2444 for ; Thu, 12 Mar 2015 01:09:03 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD951AAB for ; Thu, 12 Mar 2015 01:08:59 +0000 (UTC) Received: by wggx13 with SMTP id x13so12950293wgg.12; Wed, 11 Mar 2015 18:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=iXd9h/B/dJjQeOObpxLvLkDMvScDv1ZxKi6A/zDNy5k=; b=ES69gJZ+MQL6O5DAZ2Yy2yHRX+aGHDUgILdHDCk3FW0TiXtEZy8NbqkNB0EUou5Slr eOGNxUpy7uQ6YDtoYrbTxdydXpdrUk0Hz5AJ4h1FiHwdRLfJpD/PkkhdHbZyAPbutgOj I7Fmz3piwvnl3c04CfGuPq2ghgQOxdyqE2JnewfHDrNDnZAZawiuPbc/7aUdUg5/5K7x 9UhKUc6VH20r2GObIkg6UyBdqp5dlVsuXcCFds1kglin/isKicB00GXNWeEtDwKIMzm7 GUgIcZ1CJlrbEtX/RypL5V4RQWdbqUm7SuSXXZTGfJuYWe7exlJEbY20R0H1isYX7baF gchg== X-Received: by 10.194.48.12 with SMTP id h12mr84588520wjn.74.1426122538253; Wed, 11 Mar 2015 18:08:58 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id hd10sm26369090wib.7.2015.03.11.18.08.56 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 11 Mar 2015 18:08:57 -0700 (PDT) Date: Thu, 12 Mar 2015 02:08:53 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'Convert mountlist_mtx to rwlock' Message-ID: <20150312010853.GC18699@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org, wca@freebsd.org References: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, wca@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 01:09:03 -0000 On Wed, Mar 11, 2015 at 09:10:34PM +0800, Tiwei Bie wrote: > Hi, Mateusz! > > I have finished the task: Convert mountlist_mtx to rwlock [1]. > > sys/rwlock.h and cddl/compat/opensolaris/sys/rwlock.h have defined > the same symbols, such as rw_init(), rw_destroy(). So they could not > be included in the same file. And the latter has been indirectly > included in cddl/compat/opensolaris/kern/opensolaris_vfs.c and > cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > which needs to use mountlist_lock. So I implemented the following > functions to access mountlist_lock in these files: > > void zfs_mountlist_wlock(void); > void zfs_mountlist_wunlock(void); > void zfs_mountlist_rlock(void); > void zfs_mountlist_runlock(void); > (cc-ed one of our zfs guys) Oops, completely forgot about header conflict. First off, if providing such functions, they should be prefixed with freebsd_ or something similar. Ideally we would somewhow fix namespace problems, but this may not be that easy. I think this is a nice opportunity to hide mountlist_lock behind some helpers. I left all usage samples below. We can fix mount_snapshot no problem by providing a dedicated function to insert into mountlist. I'm somewhat torn with zfs_get_vfs and zfsvfs_update_fromname. We could provide a helper function which takes a function pointer and calls it for each entry in the list. Somewhat crappy but should work fine. Comments? > diff --git a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c > index a2532f8..045aa80 100644 > --- a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c > +++ b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c > @@ -222,9 +222,9 @@ mount_snapshot(kthread_t *td, vnode_t **vpp, const char *fstype, char *fspath, > > vp->v_mountedhere = mp; > /* Put the new filesystem on the mount list. */ > - mtx_lock(&mountlist_mtx); > + zfs_mountlist_wlock(); > TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); > - mtx_unlock(&mountlist_mtx); > + zfs_mountlist_wunlock(); > vfs_event_signal(NULL, VQ_MOUNT, 0); > if (VFS_ROOT(mp, LK_EXCLUSIVE, &mvp)) > panic("mount: lost mount"); > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > index a829b06..4d86892 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > @@ -3015,14 +3015,14 @@ zfs_get_vfs(const char *resource) > { > vfs_t *vfsp; > > - mtx_lock(&mountlist_mtx); > + zfs_mountlist_rlock(); > TAILQ_FOREACH(vfsp, &mountlist, mnt_list) { > if (strcmp(refstr_value(vfsp->vfs_resource), resource) == 0) { > VFS_HOLD(vfsp); > break; > } > } > - mtx_unlock(&mountlist_mtx); > + zfs_mountlist_runlock(); > return (vfsp); > } > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > index 415db9e..9b29323 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > @@ -2537,7 +2537,7 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) > > oldlen = strlen(oldname); > > - mtx_lock(&mountlist_mtx); > + zfs_mountlist_rlock(); > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > fromname = mp->mnt_stat.f_mntfromname; > if (strcmp(fromname, oldname) == 0) { > @@ -2554,6 +2554,6 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) > continue; > } > } > - mtx_unlock(&mountlist_mtx); > + zfs_mountlist_runlock(); > } > #endif -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 02:25:17 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04A575A4 for ; Thu, 12 Mar 2015 02:25:17 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id E53E727D for ; Thu, 12 Mar 2015 02:25:14 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygBXORb++ABV_NuIAw--.47100S2; Thu, 12 Mar 2015 10:25:09 +0800 (CST) Date: Thu, 12 Mar 2015 10:24:59 +0800 From: Tiwei Bie To: Mateusz Guzik Subject: Re: [PATCH] Finish the task 'Convert mountlist_mtx to rwlock' Message-ID: <20150312022459.GA42663@freebsd> References: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> <20150312010853.GC18699@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150312010853.GC18699@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygBXORb++ABV_NuIAw--.47100S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAFWxZw1DZF43Aw18GrW7Jwb_yoW7JryDpF n0yF4jkF4kAr4DJr47t3Z5ua48Zr4v9r1UGw4kWry7Z398Xw1IqF48ta9xCay5urs29a93 Z3W8urn8CanayaUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUk0b7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr0_Cr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxkIecxEwVAFwVW8JwCF04k20xvY 0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUyrMaDUUUU X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUFAVQhl-bDMwAZs9 Cc: freebsd-hackers@freebsd.org, wca@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 02:25:17 -0000 On Thu, Mar 12, 2015 at 02:08:53AM +0100, Mateusz Guzik wrote: > On Wed, Mar 11, 2015 at 09:10:34PM +0800, Tiwei Bie wrote: > > Hi, Mateusz! > > > > I have finished the task: Convert mountlist_mtx to rwlock [1]. > > > > sys/rwlock.h and cddl/compat/opensolaris/sys/rwlock.h have defined > > the same symbols, such as rw_init(), rw_destroy(). So they could not > > be included in the same file. And the latter has been indirectly > > included in cddl/compat/opensolaris/kern/opensolaris_vfs.c and > > cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > > which needs to use mountlist_lock. So I implemented the following > > functions to access mountlist_lock in these files: > > > > void zfs_mountlist_wlock(void); > > void zfs_mountlist_wunlock(void); > > void zfs_mountlist_rlock(void); > > void zfs_mountlist_runlock(void); > > > > (cc-ed one of our zfs guys) > > Oops, completely forgot about header conflict. > > First off, if providing such functions, they should be prefixed with > freebsd_ or something similar. > When naming these functions, I read cddl/compat/opensolaris/kern/opensolaris_vm.c for reference. It also needs to use rwlock: void zfs_vmobject_wlock(vm_object_t object) { VM_OBJECT_WLOCK(object); } void zfs_vmobject_wunlock(vm_object_t object) { VM_OBJECT_WUNLOCK(object); } > Ideally we would somewhow fix namespace problems, but this may not be > that easy. > > I think this is a nice opportunity to hide mountlist_lock behind some > helpers. > > I left all usage samples below. > > We can fix mount_snapshot no problem by providing a dedicated function > to insert into mountlist. > > I'm somewhat torn with zfs_get_vfs and zfsvfs_update_fromname. We could > provide a helper function which takes a function pointer and calls it > for each entry in the list. Somewhat crappy but should work fine. > > Comments? > If we hide mountlist_lock behind some helpers, we will have to define new callback function and argument type (when the callback function needs more than one argument, I think these arguments have to be included in a structure to keep the prototype of the callback function simple, e.g. int (*func)(struct mount *mp, void *arg)), such as what we have to do with zfsvfs_update_fromname. It isn't very simple and elegant. So I prefer to provide some helpers to access mountlist_lock directly. > > diff --git a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c > > index a2532f8..045aa80 100644 > > --- a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c > > +++ b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c > > @@ -222,9 +222,9 @@ mount_snapshot(kthread_t *td, vnode_t **vpp, const char *fstype, char *fspath, > > > > vp->v_mountedhere = mp; > > /* Put the new filesystem on the mount list. */ > > - mtx_lock(&mountlist_mtx); > > + zfs_mountlist_wlock(); > > TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); > > - mtx_unlock(&mountlist_mtx); > > + zfs_mountlist_wunlock(); > > vfs_event_signal(NULL, VQ_MOUNT, 0); > > if (VFS_ROOT(mp, LK_EXCLUSIVE, &mvp)) > > panic("mount: lost mount"); > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > > index a829b06..4d86892 100644 > > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > > @@ -3015,14 +3015,14 @@ zfs_get_vfs(const char *resource) > > { > > vfs_t *vfsp; > > > > - mtx_lock(&mountlist_mtx); > > + zfs_mountlist_rlock(); > > TAILQ_FOREACH(vfsp, &mountlist, mnt_list) { > > if (strcmp(refstr_value(vfsp->vfs_resource), resource) == 0) { > > VFS_HOLD(vfsp); > > break; > > } > > } > > - mtx_unlock(&mountlist_mtx); > > + zfs_mountlist_runlock(); > > return (vfsp); > > } > > > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > > index 415db9e..9b29323 100644 > > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > > @@ -2537,7 +2537,7 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) > > > > oldlen = strlen(oldname); > > > > - mtx_lock(&mountlist_mtx); > > + zfs_mountlist_rlock(); > > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > > fromname = mp->mnt_stat.f_mntfromname; > > if (strcmp(fromname, oldname) == 0) { > > @@ -2554,6 +2554,6 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) > > continue; > > } > > } > > - mtx_unlock(&mountlist_mtx); > > + zfs_mountlist_runlock(); > > } > > #endif > > -- > Mateusz Guzik Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 04:06:03 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0B3982C for ; Thu, 12 Mar 2015 04:06:03 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84C93EDE for ; Thu, 12 Mar 2015 04:06:03 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so13797383iec.0; Wed, 11 Mar 2015 21:06:03 -0700 (PDT) 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=lZxNjJRxl4tjh6revJWFt2spzzVcB7JlxpnBd7QZ9IY=; b=HqGZb1lvvidh/w5Hph9DCHLPW5iz07Cr2GLpnhTixSja6/JECgdXB2ceivEca+NeyH gNJeHX91usLEbJQ0/8eFMoK8VsreIS8q5JAd2SXvyMCYSyQlezrx6nwEeBdOUO7eaG3P Mi6L0/7j4r3POK5fdYGvN03OlQm+HDpLlM3Qcp8sha3K1Baz4WSRjaQuUcmCvvJsE2MV DZTrNRfSdFxOVnboSLjTclDKKs0jylAl1sJQIpMT01qpEXyR+FbnwjzkVsmectefYSlB pSvlpIF07GRFlB1GFC0jq2hao9ZnvdrRyPUF+7vBkhzuMrKhkDdLr0w49mH8xKTzD3Ck 8gQQ== MIME-Version: 1.0 X-Received: by 10.43.16.196 with SMTP id pz4mr46324842icb.69.1426133162111; Wed, 11 Mar 2015 21:06:02 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Wed, 11 Mar 2015 21:06:02 -0700 (PDT) In-Reply-To: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> References: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> Date: Thu, 12 Mar 2015 00:06:02 -0400 Message-ID: Subject: Re: [PATCH] Finish the task 'Convert mountlist_mtx to rwlock' From: Ryan Stone To: Tiwei Bie Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , mjguzik@gmail.com, wca@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 04:06:03 -0000 On Wed, Mar 11, 2015 at 9:10 AM, Tiwei Bie wrote: > Hi, Mateusz! > > I have finished the task: Convert mountlist_mtx to rwlock [1]. My first comment is, are we sure that we actually want an rwlock here instead of an rmlock? An rmlock will offer much better performance in workloads that mostly only take read locks, and rmlocks do not suffer the priority inversion problems that rwlocks do. From the description on the wiki page, it sounds like an rmlock would be ideal here: > Interested person can upgrade this task to non-junior by coming up with a > solution exploiting rare need to modify the list. Example approaches include > designing a locking primitive with cheap shared locking (think: per-cpu) at > the expense of exclusive locking. The rmlock primitive does exactly this optimization. See the manpage for the API (it's mostly very similar to the rwlock API): https://www.freebsd.org/cgi/man.cgi?query=rmlock&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html > void zfs_mountlist_wlock(void); > void zfs_mountlist_wunlock(void); > void zfs_mountlist_rlock(void); > void zfs_mountlist_runlock(void); Why not: #define zfs_mountlist_wlock() _zfs_mountlist_wlock(__FILE__, __LINE__) void _zfs_mountlist_wlock(const char *file, int line); /* etc, etc */ (This may be moot if we switch to an rmlock though) From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 04:14:52 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C0FA95B for ; Thu, 12 Mar 2015 04:14:52 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DBECFA1 for ; Thu, 12 Mar 2015 04:14:51 +0000 (UTC) Received: by lbiz11 with SMTP id z11so13252149lbi.13; Wed, 11 Mar 2015 21:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uYesIyMHSg7oLZIgI4T3WhutmX4AXbdD9+Q5JxObirE=; b=r4+a2/bttsVj4EFEQpnC+u0Lhsnu/RuEWGL5VkAp2zPiNRfD7sti6M58HmxLMhocO6 A9j91C3aRYxbGP8VV3h2tBiviZ7LzFQKps5ThrC/KvrXZj3GifRBDvAg/EGbYtPR375+ BXRsB9GTz/+RIEgoBkCC1NV8YuGqI089nP/aNA7/Hp5q26TTSYq390vPA8RHUfWfx3/l ZN7YAJX2bw+p1KjmF0DlDuq1zYud6j6g7FMsrNUEXSfXnQA1gQsmrZUrmWAk6bu+fv1F 3n/3AiBQiAzucKQQ0cjzFqjR0/fxYdx84jpU//gzDE61S5VKttX+y8nTtrtAz7eYh17E kZEA== MIME-Version: 1.0 X-Received: by 10.152.204.42 with SMTP id kv10mr30653540lac.52.1426133689691; Wed, 11 Mar 2015 21:14:49 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.25.217.6 with HTTP; Wed, 11 Mar 2015 21:14:49 -0700 (PDT) In-Reply-To: References: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> Date: Wed, 11 Mar 2015 21:14:49 -0700 X-Google-Sender-Auth: R3uwdB8jvJMcbI61Fcvq-tRvpNc Message-ID: Subject: Re: [PATCH] Finish the task 'Convert mountlist_mtx to rwlock' From: Davide Italiano To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Tiwei Bie , Mateusz Guzik , wca@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 04:14:52 -0000 On Wed, Mar 11, 2015 at 9:06 PM, Ryan Stone wrote: > On Wed, Mar 11, 2015 at 9:10 AM, Tiwei Bie wrote: >> Hi, Mateusz! >> >> I have finished the task: Convert mountlist_mtx to rwlock [1]. > > My first comment is, are we sure that we actually want an rwlock here > instead of an rmlock? An rmlock will offer much better performance in > workloads that mostly only take read locks, and rmlocks do not suffer > the priority inversion problems that rwlocks do. From the description > on the wiki page, it sounds like an rmlock would be ideal here: > Snippet: [...] - mtx_unlock(&mountlist_mtx); + rw_runlock(&mountlist_lock); mp->mnt_kern_flag |= MNTK_MWAIT; msleep(mp, MNT_MTX(mp), PVFS | PDROP, "vfs_busy", 0); if (flags & MBF_MNTLSTLOCK) - mtx_lock(&mountlist_mtx); + rw_rlock(&mountlist_lock); [...] My understanding is that readers are not allowed to sleep while holding an rmlock() so a drop-in replacement don't work in this case. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 04:44:43 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F2B4185; Thu, 12 Mar 2015 04:44:43 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45F5064A; Thu, 12 Mar 2015 04:44:43 +0000 (UTC) Received: by pdjp10 with SMTP id p10so16902496pdj.10; Wed, 11 Mar 2015 21:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=mgmEVoAVOD3zyg3QoQklC88z9S6FwKHqGivKdiL1bQ4=; b=nxlAPFBc9aR2YT/artThLBXKZacgCVnv8qvFqqwjiCNtvpJUuC6gpfGqMgkY2zGq3T VfOQgDO6uVas0f5tI2udanSSh8ClTfc/zJQ7JFQxKVe5K8MF//AKcO0wKcaJM0wU1rUm eVgw5D8E4D89qf3UBUVIo9kNIH9yEOhps4haBteflq6hu4dQv4edvx9GpZmKFji/RpIa 7Dtv5nZAB2UFCFuE8JQNwpVndzoJcZ0b4/Um/ip+tPqbkT0NYZrHvErKBt5SFtirRvjU 0UXteG2vhxcYwM+AgzlQUelqY1ImMQYAxmHjUBT+cvt5wiHCdksTdDfhLz74IQa7+KgE uaMg== X-Received: by 10.66.118.129 with SMTP id km1mr85829800pab.112.1426135482727; Wed, 11 Mar 2015 21:44:42 -0700 (PDT) Received: from raichu (216-243-33-91.users.condointernet.net. [216.243.33.91]) by mx.google.com with ESMTPSA id jj1sm8609137pac.17.2015.03.11.21.44.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 21:44:41 -0700 (PDT) Sender: Mark Johnston Date: Wed, 11 Mar 2015 21:44:39 -0700 From: Mark Johnston To: Davide Italiano Subject: Re: [PATCH] Finish the task 'Convert mountlist_mtx to rwlock' Message-ID: <20150312044439.GB11120@raichu> References: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-hackers@freebsd.org" , Tiwei Bie , Mateusz Guzik , Ryan Stone , wca@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 04:44:43 -0000 On Wed, Mar 11, 2015 at 09:14:49PM -0700, Davide Italiano wrote: > On Wed, Mar 11, 2015 at 9:06 PM, Ryan Stone wrote: > > On Wed, Mar 11, 2015 at 9:10 AM, Tiwei Bie wrote: > >> Hi, Mateusz! > >> > >> I have finished the task: Convert mountlist_mtx to rwlock [1]. > > > > My first comment is, are we sure that we actually want an rwlock here > > instead of an rmlock? An rmlock will offer much better performance in > > workloads that mostly only take read locks, and rmlocks do not suffer > > the priority inversion problems that rwlocks do. From the description > > on the wiki page, it sounds like an rmlock would be ideal here: > > > > Snippet: > [...] > - mtx_unlock(&mountlist_mtx); > + rw_runlock(&mountlist_lock); > mp->mnt_kern_flag |= MNTK_MWAIT; > msleep(mp, MNT_MTX(mp), PVFS | PDROP, "vfs_busy", 0); > if (flags & MBF_MNTLSTLOCK) > - mtx_lock(&mountlist_mtx); > + rw_rlock(&mountlist_lock); > [...] > > My understanding is that readers are not allowed to sleep while > holding an rmlock() so a drop-in replacement don't work in this case. That's true of an rwlock as well though. And the mountlist lock is dropped around the msleep call in this snippet. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 06:12:49 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F2394AF for ; Thu, 12 Mar 2015 06:12:49 +0000 (UTC) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5D85152 for ; Thu, 12 Mar 2015 06:12:48 +0000 (UTC) Received: by oiax69 with SMTP id x69so11603347oia.5 for ; Wed, 11 Mar 2015 23:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FbTRo8pZNIvdgzQqIrCYtcTPIZ/I2SpvMefD/wvRflc=; b=Bl5xkGyYsTgAInbbL9h+KsNb/FD82VxQ6HT0ufyu/ZchCQEr6iOYR4VEAfLSDcDYRS wIRC+NIWN1lN1rf1fDqf1iu53zNb1+oNC+XK+op33y+KXquHwQEDsF5HUUNK1VkVpMX6 UuKkMulPDFZh+tD0Ed9hJZeUhO4LBYtJvc/NOg4A0i9X1DWdChK6hjW3D6EkQXQAdm/s h2aO+H9Zr/Rd9Zq5V+6bGdTJN+PvjOb4TWUZRwUbI1ROJ1lMM1yWJsbhfgAPPc5yZ0BD EXViCPu/6lM+Wr1DEVTOgChRforpPM7GWk3qm1e2C7bAcCSZPspD46p0nQqEsSZK2JsT ONlA== X-Received: by 10.60.120.36 with SMTP id kz4mr32884959oeb.47.1426140768155; Wed, 11 Mar 2015 23:12:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.116.133 with HTTP; Wed, 11 Mar 2015 23:12:07 -0700 (PDT) In-Reply-To: <20150311203645.GA30268@stack.nl> References: <20150311203645.GA30268@stack.nl> From: Matt Tagg Date: Wed, 11 Mar 2015 23:12:07 -0700 Message-ID: Subject: Re: find with -delete option on absolute paths To: Jilles Tjoelker Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 06:12:49 -0000 On Wed, Mar 11, 2015 at 1:36 PM, Jilles Tjoelker wrote: > You can get the same behaviour by upgrading to FreeBSD 10 or newer. > > Before FreeBSD 10.0, find -delete did not allow deleting files given as > arguments. This was because of an incorrect check and was fixed in > SVN r253886. Interesting, hope it makes it into Darwin 15 From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 06:16:12 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D0935AC for ; Thu, 12 Mar 2015 06:16:12 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtpout002.mac.com [17.172.220.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11FDC171 for ; Thu, 12 Mar 2015 06:16:11 +0000 (UTC) Received: from [192.168.11.209] (unknown [180.42.49.96]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NL30017A5EFEW30@st11p02mm-asmtp002.mac.com> for freebsd-hackers@freebsd.org; Thu, 12 Mar 2015 06:15:58 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-12_03:2015-03-11,2015-03-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503120068 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: find with -delete option on absolute paths From: Rui Paulo In-reply-to: Date: Thu, 12 Mar 2015 15:15:43 +0900 Content-transfer-encoding: 7bit Message-id: <7CB3B7AE-19E0-4E37-9BC0-FA4BBF46D7D7@me.com> References: <20150311203645.GA30268@stack.nl> To: Matt Tagg X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 06:16:12 -0000 On 12 Mar 2015, at 15:12, Matt Tagg wrote: > > On Wed, Mar 11, 2015 at 1:36 PM, Jilles Tjoelker wrote: >> You can get the same behaviour by upgrading to FreeBSD 10 or newer. >> >> Before FreeBSD 10.0, find -delete did not allow deleting files given as >> arguments. This was because of an incorrect check and was fixed in >> SVN r253886. > > Interesting, hope it makes it into Darwin 15 You probably should ask on an OS X mailing list. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 09:32:47 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BAAA591; Thu, 12 Mar 2015 09:32:47 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61253AA4; Thu, 12 Mar 2015 09:32:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426152764; l=2114; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date; bh=pmquw4YBb3mY2N2wHNWCis6juFgz/BejcUahZOUcQX0=; b=HS18olQrz6cYusvMGErBEqfZp3SJwasCk/HhX2u3Mv0anMfGKLd7RPMF+nfsQpY00Wl 2sHqgSwkUsX+LxCNlg1Urs79RyhE0htGo8ik9csBqwTwoywgM4q4LAQGB6BpJ2EGQVaQf ZHnwWHY0658kv7Sl71eEoyt7+2vPZ26xG3U= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgkO4q1xDEhkgOJDsXNs= X-RZG-CLASS-ID: mo00 Received: from fuckner.delnet ([85.183.0.195]) by smtp.strato.de (RZmta 37.3 AUTH) with ESMTPA id m077c7r2C9Whnmv; Thu, 12 Mar 2015 10:32:43 +0100 (CET) Message-ID: <55015D3B.6030605@fuckner.net> Date: Thu, 12 Mar 2015 10:32:43 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Julian Elischer , Oliver Pinter , Adrian Chadd Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> In-Reply-To: <550093DD.5040603@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 09:32:47 -0000 On 03/11/2015 08:13 PM, Julian Elischer wrote: > On 3/11/15 8:39 AM, Oliver Pinter wrote: >> On Wed, Mar 11, 2015 at 4:26 PM, Adrian Chadd wrote: >>> Hm, have you tried with just one TB of RAM? I haven't had access to >>> systems with 3TB of RAM - I'm just about to get 1TB in a box. :) >>> >>> Hm, other hackers - what's the current size of the AMD64 direct map? >> 4TB - >> https://github.com/freebsd/freebsd/blob/master/sys/amd64/include/vmparam.h#L157 >> > > yeah but since direct-map is, well, directly mapped, you might have 3TB > of ram but it might be spread over a larger range. > there may be holes in it.. it would be worth knowing the apparent > layout of the ram. is it this you are looking for (from OpenSUSE 13.2)? http://dedi3.fuckner.net/~molli123/temp/dmesg.smp.disabled.txt http://dedi3.fuckner.net/~molli123/temp/dmesg-s4l_opensuse13.2.txt [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x00000000000997ff] usable [ 0.000000] BIOS-e820: [mem 0x0000000000099800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000784affff] usable [ 0.000000] BIOS-e820: [mem 0x00000000784b0000-0x0000000078c63fff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000078c64000-0x0000000078ca6fff] ACPI data [ 0.000000] BIOS-e820: [mem 0x0000000078ca7000-0x000000007a268fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x000000007a269000-0x000000007bdc3fff] reserved [ 0.000000] BIOS-e820: [mem 0x000000007bdc4000-0x000000007bdc4fff] usable [ 0.000000] BIOS-e820: [mem 0x000000007bdc5000-0x000000007be4afff] reserved [ 0.000000] BIOS-e820: [mem 0x000000007be4b000-0x000000007bffffff] usable [ 0.000000] BIOS-e820: [mem 0x0000000080000000-0x000000008fffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000003007fffffff] usable From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 12:31:12 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8190CE3C for ; Thu, 12 Mar 2015 12:31:12 +0000 (UTC) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DA30FF6 for ; Thu, 12 Mar 2015 12:31:11 +0000 (UTC) Received: by wibbs8 with SMTP id bs8so47299082wib.0 for ; Thu, 12 Mar 2015 05:31:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=fGW4dqkvdNAy9xk+Xq9i9uMA5pelzebb5s863FEX59s=; b=Cyz6Fe7nCwa1j+tT/7MMnlYcz9+EapgclGuWON3nIklZxMTZNidZ747OsiNF1miCaI Tu39CLRCalAoFjZeOSmrUIsXgzwvDzmQjlknbpThP2KFJe8eouYXLSbaYZ4T+vg539or Wco6l4NRxRNgrnHNipyUis1xCHUTGkgJdfbT+Bgu8oopjwC8WYVyDHfB0wmSoCMhsjp0 Ln92SlrBB8rF+W5T7hGmtkYBGQIa9X1msXml4lJYfk9qLZL3amVGO701o0mOZzjssM6G oq8B2F8YjdK6iF6glzbxagFL9ffqqIi73/tozTBM3EAY/rZq4YN20s1f4QdBZaigkNGJ xt+Q== X-Gm-Message-State: ALoCoQlTwphW/wsHIG8FC0goQThK93ckTAKGHjZEqrTqFJB20Dt15o17McbUgGFNo8JytUSTkoII X-Received: by 10.195.12.97 with SMTP id ep1mr88358039wjd.134.1426161576613; Thu, 12 Mar 2015 04:59:36 -0700 (PDT) From: Sibananda Sahu MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBcvACn+dP0jp6dTgOxdZvRAGg3yg== Date: Thu, 12 Mar 2015 17:29:34 +0530 Message-ID: Subject: Kenrel panic in bus_dmamem_alloc() To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=047d7bfceb402c08e70511161e97 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 12:31:12 -0000 --047d7bfceb402c08e70511161e97 Content-Type: text/plain; charset=UTF-8 Hi, Recently I was working with the mrsas(4) driver and found that after several operations when I unload and reload the driver the kernel was entering into panic at the bus_dmamem_alloc() call. I have attached the core.txt file. Below is the Back trace info: Unread portion of the kernel message buffer: AVAGO MegaRAID SAS FreeBSD mrsas driver version: 06.708.09.00 mrsas0: port 0xfc00-0xfcff mem 0xdf2f0000-0xdf2fffff,0xdf300000-0xdf3fffff irq 32 at device 0.0 on pci5 mrsas0: Waiting for FW to come to ready state mrsas0: FW now in Ready state mrsas0: Using MSI-X with 4 number of vectors mrsas0: FW supports <96> MSIX vector,Online CPU 4 Current MSIX <4> mrsas0: Avago Debug: MAX sge 0x106 MAX chain frame size 0x1000 mrsas0: Allocating ver buf memory size 256 mrsas0: Allocating IO req memory 237824 mrsas0: Allocating chain frame memory 3796992 Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 32 instruction pointer = 0x20:0xffffffff80ae16f3 stack pointer = 0x28:0xfffffe01213d41d0 frame pointer = 0x28:0xfffffe01213d4240 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1406 (kldload) Error while mapping shared library sections: ./mrsas.ko: No such file or directory. Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/uftdi.ko.symbols...done. Loaded symbols for /boot/kernel/uftdi.ko.symbols Reading symbols from /boot/kernel/ucom.ko.symbols...done. Loaded symbols for /boot/kernel/ucom.ko.symbols Error while reading shared library symbols: ./mrsas.ko: No such file or directory. #0 doadump (textdump=0) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=0) at pcpu.h:219 #1 0xffffffff8033f5ae in db_dump (dummy=, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0xffffffff8033f08d in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:449 #3 0xffffffff8033ee04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xffffffff80341720 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff808b9bc3 in kdb_trap (type=9, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:656 #6 0xffffffff80c4b442 in trap_fatal (frame=0xfffffe01213d4120, eva=) at /usr/src/sys/amd64/amd64/trap.c:877 #7 0xffffffff80c4b0bf in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:224 #8 0xffffffff80c32d02 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #9 0xffffffff80ae16f3 in vm_reserv_alloc_contig (object=0xffffffff8166d9c8, pindex=, npages=, low=0, high=18446735281027570048, alignment=, boundary=) at /usr/src/sys/vm/vm_reserv.c:252 #10 0xffffffff80ada2ee in vm_page_alloc_contig (object=0xffffffff8166d9c8, pindex=1183744, req=546, npages=927, low=0, high=4294967295, memattr=) at /usr/src/sys/vm/vm_page.c:1741 #11 0xffffffff80acc153 in kmem_alloc_contig (vmem=0xffffffff8144bd80, size=3796992, flags=1, low=0, high=4294967295, alignment=4) at /usr/src/sys/vm/vm_kern.c:239 #12 0xffffffff80d454cd in bus_dmamem_alloc (dmat=0xfffff80099ba3480, vaddr=0xfffffe00019aa0b8, flags=, mapp=0xfffffe00019aa0b0) at /usr/src/sys/x86/x86/busdma_machdep.c:551 #13 0xffffffff81a2500b in ?? () #14 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) Can anybody suggest me what might have gone wrong so this disaster happened??? Thanks, Sibananda Sahu --047d7bfceb402c08e70511161e97 Content-Type: application/octet-stream; name="core.txt.3" Content-Disposition: attachment; filename="core.txt.3" Content-Transfer-Encoding: base64 X-Attachment-Id: bbbee0229ac5cb85_0.1 RnJlZUJTRDEwX1NUT0NLIGR1bXBlZCBjb3JlIC0gc2VlIC92YXIvY3Jhc2gvdm1jb3JlLjMKClRo dSBNYXIgMTIgMDA6Mjc6NDkgSVNUIDIwMTUKCkZyZWVCU0QgRnJlZUJTRDEwX1NUT0NLIDEwLjAt UkVMRUFTRSBGcmVlQlNEIDEwLjAtUkVMRUFTRSAjNDogVGh1IE1hciAgNSAwMToyMDozNSBJU1Qg MjAxNSAgICAgcm9vdEBGcmVlQlNEMTBfU1RPQ0s6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJ QyAgYW1kNjQKCnBhbmljOiAKCkdOVSBnZGIgNi4xLjEgW0ZyZWVCU0RdCkNvcHlyaWdodCAyMDA0 IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgpHREIgaXMgZnJlZSBzb2Z0d2FyZSwgY292 ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGFuZCB5b3UgYXJlCndlbGNv bWUgdG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRlciBjZXJ0 YWluIGNvbmRpdGlvbnMuClR5cGUgInNob3cgY29weWluZyIgdG8gc2VlIHRoZSBjb25kaXRpb25z LgpUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5IGZvciBHREIuICBUeXBlICJzaG93IHdh cnJhbnR5IiBmb3IgZGV0YWlscy4KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMgImFtZDY0LW1h cmNlbC1mcmVlYnNkIi4uLgoKVW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBtZXNzYWdlIGJ1 ZmZlcjoKQVZBR08gTWVnYVJBSUQgU0FTIEZyZWVCU0QgbXJzYXMgZHJpdmVyIHZlcnNpb246IDA2 LjcwOC4wOS4wMAptcnNhczA6IDxBVkFHTyBJbnZhZGVyIFNBUyBDb250cm9sbGVyPiBwb3J0IDB4 ZmMwMC0weGZjZmYgbWVtIDB4ZGYyZjAwMDAtMHhkZjJmZmZmZiwweGRmMzAwMDAwLTB4ZGYzZmZm ZmYgaXJxIDMyIGF0IGRldmljZSAwLjAgb24gcGNpNQptcnNhczA6IFdhaXRpbmcgZm9yIEZXIHRv IGNvbWUgdG8gcmVhZHkgc3RhdGUKbXJzYXMwOiBGVyBub3cgaW4gUmVhZHkgc3RhdGUKbXJzYXMw OiBVc2luZyBNU0ktWCB3aXRoIDQgbnVtYmVyIG9mIHZlY3RvcnMKbXJzYXMwOiBGVyBzdXBwb3J0 cyA8OTY+IE1TSVggdmVjdG9yLE9ubGluZSBDUFUgNCBDdXJyZW50IE1TSVggPDQ+Cm1yc2FzMDog QXZhZ28gRGVidWc6IE1BWCBzZ2UgMHgxMDYgTUFYIGNoYWluIGZyYW1lIHNpemUgMHgxMDAwIApt cnNhczA6IEFsbG9jYXRpbmcgdmVyIGJ1ZiBtZW1vcnkgc2l6ZSAyNTYKbXJzYXMwOiBBbGxvY2F0 aW5nIElPIHJlcSBtZW1vcnkgMjM3ODI0Cm1yc2FzMDogQWxsb2NhdGluZyBjaGFpbiBmcmFtZSBt ZW1vcnkgMzc5Njk5MgoKCkZhdGFsIHRyYXAgOTogZ2VuZXJhbCBwcm90ZWN0aW9uIGZhdWx0IHdo aWxlIGluIGtlcm5lbCBtb2RlCmNwdWlkID0gMjsgYXBpYyBpZCA9IDMyCmluc3RydWN0aW9uIHBv aW50ZXIJPSAweDIwOjB4ZmZmZmZmZmY4MGFlMTZmMwpzdGFjayBwb2ludGVyCSAgICAgICAgPSAw eDI4OjB4ZmZmZmZlMDEyMTNkNDFkMApmcmFtZSBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZm ZmZlMDEyMTNkNDI0MApjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5 cGUgMHgxYgoJCQk9IERQTCAwLCBwcmVzIDEsIGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAxCnByb2Nl c3NvciBlZmxhZ3MJPSBpbnRlcnJ1cHQgZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0gMApjdXJyZW50 IHByb2Nlc3MJCT0gMTQwNiAoa2xkbG9hZCkKCkVycm9yIHdoaWxlIG1hcHBpbmcgc2hhcmVkIGxp YnJhcnkgc2VjdGlvbnM6Ci4vbXJzYXMua286IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuClJl YWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC91bXMua28uc3ltYm9scy4uLmRvbmUuCkxv YWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvdW1zLmtvLnN5bWJvbHMKUmVhZGluZyBzeW1i b2xzIGZyb20gL2Jvb3Qva2VybmVsL3VmdGRpLmtvLnN5bWJvbHMuLi5kb25lLgpMb2FkZWQgc3lt Ym9scyBmb3IgL2Jvb3Qva2VybmVsL3VmdGRpLmtvLnN5bWJvbHMKUmVhZGluZyBzeW1ib2xzIGZy b20gL2Jvb3Qva2VybmVsL3Vjb20ua28uc3ltYm9scy4uLmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZv ciAvYm9vdC9rZXJuZWwvdWNvbS5rby5zeW1ib2xzCkVycm9yIHdoaWxlIHJlYWRpbmcgc2hhcmVk IGxpYnJhcnkgc3ltYm9sczoKLi9tcnNhcy5rbzogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeS4K IzAgIGRvYWR1bXAgKHRleHRkdW1wPTApIGF0IHBjcHUuaDoyMTkKMjE5CXBjcHUuaDogTm8gc3Vj aCBmaWxlIG9yIGRpcmVjdG9yeS4KCWluIHBjcHUuaAooa2dkYikgIzAgIGRvYWR1bXAgKHRleHRk dW1wPTApIGF0IHBjcHUuaDoyMTkKIzEgIDB4ZmZmZmZmZmY4MDMzZjVhZSBpbiBkYl9kdW1wIChk dW1teT08dmFsdWUgb3B0aW1pemVkIG91dD4sIGR1bW15Mj0wLCAKICAgIGR1bW15Mz0wLCBkdW1t eTQ9MHgwKSBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo1NDMKIzIgIDB4ZmZmZmZm ZmY4MDMzZjA4ZCBpbiBkYl9jb21tYW5kIChjbWRfdGFibGU9PHZhbHVlIG9wdGltaXplZCBvdXQ+ KQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6NDQ5CiMzICAweGZmZmZmZmZm ODAzM2VlMDQgaW4gZGJfY29tbWFuZF9sb29wICgpCiAgICBhdCAvdXNyL3NyYy9zeXMvZGRiL2Ri X2NvbW1hbmQuYzo1MDIKIzQgIDB4ZmZmZmZmZmY4MDM0MTcyMCBpbiBkYl90cmFwICh0eXBlPTx2 YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgY29kZT0wKQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9t YWluLmM6MjMxCiM1ICAweGZmZmZmZmZmODA4YjliYzMgaW4ga2RiX3RyYXAgKHR5cGU9OSwgY29k ZT0wLCB0Zj08dmFsdWUgb3B0aW1pemVkIG91dD4pCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9z dWJyX2tkYi5jOjY1NgojNiAgMHhmZmZmZmZmZjgwYzRiNDQyIGluIHRyYXBfZmF0YWwgKGZyYW1l PTB4ZmZmZmZlMDEyMTNkNDEyMCwgCiAgICBldmE9PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBhdCAv dXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjg3NwojNyAgMHhmZmZmZmZmZjgwYzRiMGJm IGluIHRyYXAgKGZyYW1lPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikKICAgIGF0IC91c3Ivc3JjL3N5 cy9hbWQ2NC9hbWQ2NC90cmFwLmM6MjI0CiM4ICAweGZmZmZmZmZmODBjMzJkMDIgaW4gY2FsbHRy YXAgKCkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9leGNlcHRpb24uUzoyMzIKIzkg IDB4ZmZmZmZmZmY4MGFlMTZmMyBpbiB2bV9yZXNlcnZfYWxsb2NfY29udGlnIChvYmplY3Q9MHhm ZmZmZmZmZjgxNjZkOWM4LCAKICAgIHBpbmRleD08dmFsdWUgb3B0aW1pemVkIG91dD4sIG5wYWdl cz08dmFsdWUgb3B0aW1pemVkIG91dD4sIGxvdz0wLCAKICAgIGhpZ2g9MTg0NDY3MzUyODEwMjc1 NzAwNDgsIGFsaWdubWVudD08dmFsdWUgb3B0aW1pemVkIG91dD4sIAogICAgYm91bmRhcnk9PHZh bHVlIG9wdGltaXplZCBvdXQ+KSBhdCAvdXNyL3NyYy9zeXMvdm0vdm1fcmVzZXJ2LmM6MjUyCiMx MCAweGZmZmZmZmZmODBhZGEyZWUgaW4gdm1fcGFnZV9hbGxvY19jb250aWcgKG9iamVjdD0weGZm ZmZmZmZmODE2NmQ5YzgsIAogICAgcGluZGV4PTExODM3NDQsIHJlcT01NDYsIG5wYWdlcz05Mjcs IGxvdz0wLCBoaWdoPTQyOTQ5NjcyOTUsIAogICAgbWVtYXR0cj08dmFsdWUgb3B0aW1pemVkIG91 dD4pIGF0IC91c3Ivc3JjL3N5cy92bS92bV9wYWdlLmM6MTc0MQojMTEgMHhmZmZmZmZmZjgwYWNj MTUzIGluIGttZW1fYWxsb2NfY29udGlnICh2bWVtPTB4ZmZmZmZmZmY4MTQ0YmQ4MCwgCiAgICBz aXplPTM3OTY5OTIsIGZsYWdzPTEsIGxvdz0wLCBoaWdoPTQyOTQ5NjcyOTUsIGFsaWdubWVudD00 KQogICAgYXQgL3Vzci9zcmMvc3lzL3ZtL3ZtX2tlcm4uYzoyMzkKIzEyIDB4ZmZmZmZmZmY4MGQ0 NTRjZCBpbiBidXNfZG1hbWVtX2FsbG9jIChkbWF0PTB4ZmZmZmY4MDA5OWJhMzQ4MCwgCiAgICB2 YWRkcj0weGZmZmZmZTAwMDE5YWEwYjgsIGZsYWdzPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgCiAg ICBtYXBwPTB4ZmZmZmZlMDAwMTlhYTBiMCkgYXQgL3Vzci9zcmMvc3lzL3g4Ni94ODYvYnVzZG1h X21hY2hkZXAuYzo1NTEKIzEzIDB4ZmZmZmZmZmY4MWEyNTAwYiBpbiA/PyAoKQojMTQgMHgwMDAw MDAwMDAwMDAwMDAwIGluID8/ICgpCkN1cnJlbnQgbGFuZ3VhZ2U6ICBhdXRvOyBjdXJyZW50bHkg bWluaW1hbAooa2dkYikgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KcHMgLWF4bAoKVUlEICBQSUQgUFBJRCBD UFUgIFBSSSBOSSAgIFZTWiBSU1MgTVdDSEFOICAgU1RBVCBUVCAgICAgVElNRSBDT01NQU5ECiAg MCAgICAwICAgIDAgICAwICAtNTIgIDAgICAgIDAgICAwIC0gICAgICAgIERMcyAgIC0gIDA6MDEu NjkgW2tlcm5lbF0KICAwICAgIDEgICAgMCAgIDAgICAyMyAgMCAgOTQyOCAgIDAgd2FpdCAgICAg RExzICAgLSAgMDowMC4zMCBbaW5pdF0KICAwICAgIDIgICAgMCAgIDAgIC0xNiAgMCAgICAgMCAg IDAgd2FpdGluZ18gREwgICAgLSAgMDowMC4wMCBbc2N0cF9pdGVyYXRvcl0KICAwICAgIDMgICAg MCAgIDAgIC0xNiAgMCAgICAgMCAgIDAgY2NiX3NjYW4gREwgICAgLSAgMDowMC4wMCBbeHB0X3Ro cmRdCiAgMCAgICA0ICAgIDAgICAwICAtMTYgIDAgICAgIDAgICAwIC0gICAgICAgIFJMICAgIC0g IDA6MDAuMDAgW3BhZ2VkYWVtb25dCiAgMCAgICA1ICAgIDAgICAwICAtMTYgIDAgICAgIDAgICAw IHBzbGVlcCAgIERMICAgIC0gIDA6MDAuMDAgW3ZtZGFlbW9uXQogIDAgICAgNiAgICAwICAgMCAg MTU1ICAwICAgICAwICAgMCBwZ3plcm8gICBETCAgICAtICAwOjAwLjAwIFtwYWdlemVyb10KICAw ICAgIDcgICAgMCAgIDAgIC0xNiAgMCAgICAgMCAgIDAgcHNsZWVwICAgREwgICAgLSAgMDowMC4w MCBbYnVmZGFlbW9uXQogIDAgICAgOCAgICAwICAgMCAgLTE2ICAwICAgICAwICAgMCB2bHJ1d3Qg ICBETCAgICAtICAwOjAwLjAwIFt2bmxydV0KICAwICAgIDkgICAgMCAgIDAgICAxNiAgMCAgICAg MCAgIDAgc3luY2VyICAgREwgICAgLSAgMDowMC4wMCBbc3luY2VyXQogIDAgICAxMCAgICAwICAg MCAgLTE2ICAwICAgICAwICAgMCBhdWRpdF93byBETCAgICAtICAwOjAwLjAwIFthdWRpdF0KICAw ICAgMTEgICAgMCAgIDAgIDE1NSAgMCAgICAgMCAgIDAgLSAgICAgICAgUkwgICAgLSAgMDo0MS40 NiBbaWRsZV0KICAwICAgMTIgICAgMCAgIDAgIC01MyAgMCAgICAgMCAgIDAgLSAgICAgICAgV0wg ICAgLSAgMDowMS4wMSBbaW50cl0KICAwICAgMTMgICAgMCAgIDAgICAtOCAgMCAgICAgMCAgIDAg LSAgICAgICAgREwgICAgLSAgMDowMC4yNSBbZ2VvbV0KICAwICAgMTQgICAgMCAgIDAgIC0xNiAg MCAgICAgMCAgIDAgLSAgICAgICAgREwgICAgLSAgMDowMC4wMCBbcmFuZF9oYXJ2ZXN0cV0KICAw ICAgMTUgICAgMCAgIDAgIC02OCAgMCAgICAgMCAgIDAgLSAgICAgICAgREwgICAgLSAgMDowMS4y MyBbdXNiXQogIDAgICAxNiAgICAwICAgMCAgIDIwICAwICAgICAwICAgMCBzZGZsdXNoICBETCAg ICAtICAwOjAwLjAwIFtzb2Z0ZGVwZmx1c2hdCiAgMCAgODE1ICAgIDEgICAwICAgNTIgIDAgMTQ1 NTYgICAwIHNlbGVjdCAgIERzICAgIC0gIDA6MDAuMDAgW2RoY2xpZW50XQogNjUgIDg1MSAgICAx ICAgMCAgIDUyICAwIDE0NTU2ICAgMCBzZWxlY3QgICBEcyAgICAtICAwOjAwLjAwIFtkaGNsaWVu dF0KICAwICA4NTggICAgMSAgIDAgICA1MiAgMCAxNjYyOCAgIDAgc2VsZWN0ICAgRHMgICAgLSAg MDowMC4wMCBbbW91c2VkXQogIDAgIDg3OSAgICAxICAgMCAgIDUyICAwIDE2NjI4ICAgMCBzZWxl Y3QgICBEcyAgICAtICAwOjAwLjAwIFttb3VzZWRdCiAgMCAgODk2ICAgIDEgICAwICAgMjAgIDAg MTM1ODQgICAwIC0gICAgICAgIFJzICAgIC0gIDA6MDAuMDAgW2RldmRdCiAgMCAxMDExICAgIDEg ICAwICAgMjAgIDAgMTQ0MjQgICAwIHNlbGVjdCAgIERzICAgIC0gIDA6MDAuMDEgW3N5c2xvZ2Rd CiAgMCAxMTMzICAgIDEgICAwICAgMjIgIDAgNjA4MTYgICAwIHNlbGVjdCAgIERzICAgIC0gIDA6 MDAuMDAgW3NzaGRdCiAgMCAxMTM2ICAgIDEgICAwICAgMjAgIDAgMjM5ODAgICAwIHNlbGVjdCAg IERzICAgIC0gIDA6MDAuMDEgW3NlbmRtYWlsXQogMjUgMTEzOSAgICAxICAgMCAgIDUyICAwIDIz OTgwICAgMCBwYXVzZSAgICBEcyAgICAtICAwOjAwLjAwIFtzZW5kbWFpbF0KICAwIDExNDMgICAg MSAgIDAgICAyMCAgMCAxNjUyMCAgIDAgbmFuc2xwICAgRHMgICAgLSAgMDowMC4wMCBbY3Jvbl0K ICAwIDExODIgICAgMSAgIDAgICAyMCAgMCA0NzY1NiAgIDAgd2FpdCAgICAgRHMgICAgLSAgMDow MC4wMCBbbG9naW5dCiAgMCAxMTgzICAgIDEgICAwICAgMjAgIDAgNDc2NTYgICAwIHdhaXQgICAg IERzICAgIC0gIDA6MDAuMDAgW2xvZ2luXQogIDAgMTE4NCAgICAxICAgMCAgIDIwICAwIDQ3NjU2 ICAgMCB3YWl0ICAgICBEcyAgICAtICAwOjAwLjAwIFtsb2dpbl0KICAwIDExODUgICAgMSAgIDAg ICAyMCAgMCA0NzY1NiAgIDAgd2FpdCAgICAgRHMgICAgLSAgMDowMC4wMCBbbG9naW5dCiAgMCAx MTg2ICAgIDEgICAwICAgNTIgIDAgMTQ0MjAgICAwIHR0eWluICAgIERzKyAgIC0gIDA6MDAuMDAg W2dldHR5XQogIDAgMTE4NyAgICAxICAgMCAgIDUyICAwIDE0NDIwICAgMCB0dHlpbiAgICBEcysg ICAtICAwOjAwLjAwIFtnZXR0eV0KICAwIDExODggICAgMSAgIDAgICA1MiAgMCAxNDQyMCAgIDAg dHR5aW4gICAgRHMrICAgLSAgMDowMC4wMCBbZ2V0dHldCiAgMCAxMTg5ICAgIDEgICAwICAgNTIg IDAgMTQ0MjAgICAwIHR0eWluICAgIERzKyAgIC0gIDA6MDAuMDAgW2dldHR5XQogIDAgMTE5MyAx MTMzICAgMCAgIDIwICAwIDg2MDg0ICAgMCBzZWxlY3QgICBEcyAgICAtICAwOjAwLjAwIFtzc2hk XQogIDAgMTE5NiAxMTkzICAgMCAgIDIzICAwIDIzNDkyICAgMCBwYXVzZSAgICBEcyAgICAtICAw OjAwLjAxIFtjc2hdCiAgMCAxMTk4IDExODIgICAwICAgMjAgIDAgMjM0OTIgICAwIHR0eWluICAg IEQrICAgIC0gIDA6MDAuMDEgW2NzaF0KICAwIDEzNTYgMTE4MyAgIDAgICAyMCAgMCAyMzQ5MiAg IDAgdHR5aW4gICAgRCsgICAgLSAgMDowMC4wMSBbY3NoXQogIDAgMTM1OCAxMTg0ICAgMCAgIDIw ICAwIDIzNDkyICAgMCB0dHlpbiAgICBEKyAgICAtICAwOjAwLjAwIFtjc2hdCiAgMCAxMzYxIDEz NTggICAwICAgMjAgIDAgMTY5ODggICAwIC0gICAgICAgIFQgICAgIC0gIDA6MDAuMDAgW3NoXQog IDAgMTM2OSAxMTg1ICAgMCAgIDIwICAwIDIzNDkyICAgMCBwYXVzZSAgICBEICAgICAtICAwOjAw LjAwIFtjc2hdCiAgMCAxMzcyIDEzNjkgICAwICAgMjEgIDAgMTY5ODggICAwIHdhaXQgICAgIEQr ICAgIC0gIDA6MDAuMDAgW3NoXQogIDAgMTM3MyAxMzcyICAgMCAgIDIxICAwIDEyMzIwICAgMCB0 dHlpbiAgICBEKyAgICAtICAwOjAwLjAwIFtjdV0KICAwIDEzNzQgMTM3MyAgIDAgICAyMCAgMCAx MjMyMCAgIDAgLSAgICAgICAgUisgICAgLSAgMDowMC4wMCBbY3VdCiAgMCAxNDAzIDEzNjEgICAw IC0xMDAgIDAgICAgIDAgICAwIC0gICAgICAgIFpXICAgIC0gIDA6MDAuMDAgPGRlZnVuY3Q+CiAg MCAxNDA2IDExOTYgICAwICAgNzUgIDAgIDgxNjggICAwIC0gICAgICAgIFIrICAgIC0gIDA6MDAu MDAgW2tsZGxvYWRdCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1zCgogIDc0MTkyNTUgY3B1IGNv bnRleHQgc3dpdGNoZXMKICAgOTM0NTUyIGRldmljZSBpbnRlcnJ1cHRzCiAgIDgxNzk2NSBzb2Z0 d2FyZSBpbnRlcnJ1cHRzCiAgMTEwNzMwMyB0cmFwcwogIDEyMDE2MzYgc3lzdGVtIGNhbGxzCiAg ICAgICAyMiBrZXJuZWwgdGhyZWFkcyBjcmVhdGVkCiAgICAgMTA2OSAgZm9yaygpIGNhbGxzCiAg ICAgIDMxNSB2Zm9yaygpIGNhbGxzCiAgICAgICAgMCByZm9yaygpIGNhbGxzCiAgICAgICAgMCBz d2FwIHBhZ2VyIHBhZ2VpbnMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZXMgcGFnZWQgaW4KICAg ICAgICAwIHN3YXAgcGFnZXIgcGFnZW91dHMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZXMgcGFn ZWQgb3V0CiAgICAgMTI2MiB2bm9kZSBwYWdlciBwYWdlaW5zCiAgICAxMTk3NCB2bm9kZSBwYWdl ciBwYWdlcyBwYWdlZCBpbgogICAgICAgIDAgdm5vZGUgcGFnZXIgcGFnZW91dHMKICAgICAgICAw IHZub2RlIHBhZ2VyIHBhZ2VzIHBhZ2VkIG91dAogICAgICAgIDAgcGFnZSBkYWVtb24gd2FrZXVw cwogICAgICAgIDAgcGFnZXMgZXhhbWluZWQgYnkgdGhlIHBhZ2UgZGFlbW9uCiAgICAgICAgMCBw YWdlcyByZWFjdGl2YXRlZAogICAgMzg3OTcgY29weS1vbi13cml0ZSBmYXVsdHMKICAgICAgMjIy IGNvcHktb24td3JpdGUgb3B0aW1pemVkIGZhdWx0cwogICAgOTE0NzEgemVybyBmaWxsIHBhZ2Vz IHplcm9lZAogICAgICAgIDAgemVybyBmaWxsIHBhZ2VzIHByZXplcm9lZAogICAgICAgIDUgaW50 cmFuc2l0IGJsb2NraW5nIHBhZ2UgZmF1bHRzCiAgIDE0NjQzOCB0b3RhbCBWTSBmYXVsdHMgdGFr ZW4KICAgICAxMTY5IHBhZ2UgZmF1bHRzIHJlcXVpcmluZyBJL08KICAgICAgICAwIHBhZ2VzIGFm ZmVjdGVkIGJ5IGtlcm5lbCB0aHJlYWQgY3JlYXRpb24KICAgIDM5NTc3IHBhZ2VzIGFmZmVjdGVk IGJ5ICBmb3JrKCkKICAgIDE0ODAwIHBhZ2VzIGFmZmVjdGVkIGJ5IHZmb3JrKCkKICAgICAgICAw IHBhZ2VzIGFmZmVjdGVkIGJ5IHJmb3JrKCkKICAgICAgICAwIHBhZ2VzIGNhY2hlZAogICAzMDI2 NTEgcGFnZXMgZnJlZWQKICAgICAgICAwIHBhZ2VzIGZyZWVkIGJ5IGRhZW1vbgogICAgICAgIDAg cGFnZXMgZnJlZWQgYnkgZXhpdGluZyBwcm9jZXNzZXMKICAgICA1ODQwIHBhZ2VzIGFjdGl2ZQog ICAgMTEwMTQgcGFnZXMgaW5hY3RpdmUKICAgICAgICAwIHBhZ2VzIGluIFZNIGNhY2hlCiAgICAy NzQ4NyBwYWdlcyB3aXJlZCBkb3duCiAgIDk2MzAwMCBwYWdlcyBmcmVlCiAgICAgNDA5NiBieXRl cyBwZXIgcGFnZQogICAxNTcyNzcgdG90YWwgbmFtZSBsb29rdXBzCiAgICAgICAgICBjYWNoZSBo aXRzICg3MSUgcG9zICsgMjYlIG5lZykgc3lzdGVtIDAlIHBlci1kaXJlY3RvcnkKICAgICAgICAg IGRlbGV0aW9ucyAwJSwgZmFsc2VoaXRzIDAlLCB0b29sb25nIDAlCgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K dm1zdGF0IC1tCgogICAgICAgICBUeXBlIEluVXNlIE1lbVVzZSBIaWdoVXNlIFJlcXVlc3RzICBT aXplKHMpCiAgICAgZmlsZWNhcHMgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDE2CiAg ICAgIGtkdHJhY2UgICAxNzcgICAgMzZLICAgICAgIC0gICAgIDE1NDggIDY0LDI1NgogICAgICAg ICBrZW52ICAgIDc4ICAgIDExSyAgICAgICAtICAgICAgIDg3ICAxNiwzMiw2NCwxMjgKICAgICAg IGtxdWV1ZSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAzMCAgMjU2LDIwNDgKICAgIHByb2Mt YXJncyAgICAzMCAgICAgMksgICAgICAgLSAgICAgIDc1OCAgMTYsMzIsNjQsMTI4LDI1NgogICAg IGFjcGl0YXNrICAgICAxICAgICA4SyAgICAgICAtICAgICAgICAxICAKICAgICAgICBoaG9vayAg ICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMjU2CiAgICAgIGl0aHJlYWQgICAxMjAgICAg MjFLICAgICAgIC0gICAgICAxNDQgIDMyLDEyOCwyNTYKICAgICAgYWNwaXNlbSAgICAyMCAgICAg M0sgICAgICAgLSAgICAgICAyMCAgMTI4CiAgICAgICBLVFJBQ0UgICAxMDAgICAgMTNLICAgICAg IC0gICAgICAxMDAgIDEyOAogICAgQ0FNIHF1ZXVlICAgIDE1ICAgICA0SyAgICAgICAtICAgIDcz MzEwICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICBhY3BpZGV2ICAg IDU0ICAgICA0SyAgICAgICAtICAgICAgIDU0ICA2NAogICAgICAgbGlua2VyICAgMjE0ICAgMTM2 SyAgICAgICAtICAgICAgMzg4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgpD QU0gZGV2IHF1ZXVlICAgICA1ICAgICAxSyAgICAgICAtICAgICAgIDExICAzMgogICAgICAgIGxv Y2tmICAgIDI2ICAgICAzSyAgICAgICAtICAgICAgIDg2ICA2NCwxMjgKICAgbG9naW5jbGFzcyAg ICAgMyAgICAgMUsgICAgICAgLSAgICAgICAxOSAgNjQKICAgICAgIGRldmJ1ZiAgNzM2NSAxNzk2 NUsgICAgICAgLSAgICAgOTI4MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYK ICAgICAgICAgdGVtcCAgICAzMSAgICAgMksgICAgICAgLSAgICAgMjAyNCAgMTYsMzIsNjQsMTI4 LDI1Niw1MTIsMTAyNCwyMDQ4CiAgICAgICBpcDZuZHAgICAgIDQgICAgIDFLICAgICAgIC0gICAg ICAgIDQgIDY0LDEyOAogICAgICAgbW9kdWxlICAgNDc1ICAgIDYwSyAgICAgICAtICAgICAgNDgx ICAxMjgKICAgICBtdHhfcG9vbCAgICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgCiAgICAg cG1jaG9va3MgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDEyOAogICAgICAgICBwZ3Jw ICAgIDI4ICAgICA0SyAgICAgICAtICAgICAgIDU3ICAxMjgKICAgICAgc2Vzc2lvbiAgICAyMSAg ICAgM0sgICAgICAgLSAgICAgICAyNiAgMTI4CiAgICAgICAgIHByb2MgICAgIDIgICAgMzJLICAg ICAgIC0gICAgICAgIDIgIAogICAgICBzdWJwcm9jICAgMTA4ICAgMjE5SyAgICAgICAtICAgICAx NDY4ICA1MTIsNDA5NgogICAgICAgICBjcmVkICAgIDY4ICAgIDExSyAgICAgICAtICAgICA2MTY4 ICA2NCwyNTYKICAgICAgIHBsaW1pdCAgICAxNyAgICAgNUsgICAgICAgLSAgICAgIDI1NiAgMjU2 CiAgICAgIHVpZGluZm8gICAgIDQgICAgIDVLICAgICAgIC0gICAgICAgIDkgIDEyOCw0MDk2CiAg ICAgICBrYmRtdXggICAgIDggICAgMThLICAgICAgIC0gICAgICAgIDggIDE2LDUxMiwxMDI0LDIw NDgKICAgICAgQ0FNIFNJTSAgICAgNSAgICAgMksgICAgICAgLSAgICAgICAxNyAgMjU2CiAgICAg IENBTSBYUFQgICAgMjcgICAgIDJLICAgICAgIC0gICAgMzA5NDMgIDE2LDMyLDY0LDEyOCwyNTYs MTAyNCwyMDQ4CiAgICAgICBERVZGUzMgICAxODEgICAgNDZLICAgICAgIC0gICAgICAyMDYgIDI1 NgogICAgICAgREVWRlMxICAgMTU0ICAgIDc3SyAgICAgICAtICAgICAgMjM5ICA1MTIKICAgICAg IHN5c2N0bCAgICAgMCAgICAgMEsgICAgICAgLSAgICAgIDI1NSAgMTYsMzIsNjQKICAgIHN5c2N0 bG9pZCAgNDQ4OSAgIDIyN0sgICAgICAgLSAgICAgNTc5MyAgMTYsMzIsNjQsMTI4CiAgICBzeXNj dGx0bXAgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAxODUgIDE2LDMyLDY0LDEyOCwyNTYKICAg ICAgdGlkaGFzaCAgICAgMSAgICAzMksgICAgICAgLSAgICAgICAgMSAgCiAgICAgIGNhbGxvdXQg ICAgIDUgIDIxODRLICAgICAgIC0gICAgICAgIDUgIAogICAgICAgICB1bXR4ICAgMjgyICAgIDM2 SyAgICAgICAtICAgICAgMjgyICAxMjgKICAgICBwMTAwMy4xYiAgICAgMSAgICAgMUsgICAgICAg LSAgICAgICAgMSAgMTYKICAgICAgICAgU1dBUCAgICAgMiAgIDU0OUsgICAgICAgLSAgICAgICAg MiAgNjQKICAgICAgICAgIGJ1cyAgMTI1NyAgIDExMEsgICAgICAgLSAgICAxMTA3OSAgMTYsMzIs NjQsMTI4LDI1NiwxMDI0CiAgICAgICBidXMtc2MgICAgOTYgIDE3MjBLICAgICAgIC0gICAgIDgw NjggIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgIGRldnN0YXQgICAg MTAgICAgMjFLICAgICAgIC0gICAgICAgMTAgIDMyLDQwOTYKIGV2ZW50aGFuZGxlciAgICA4MCAg ICAgN0sgICAgICAgLSAgICAgICA4MCAgNjQsMTI4CiAgICAgICAgREVWRlMgICAgMzAgICAgIDFL ICAgICAgIC0gICAgICAgMzEgIDE2LDMyLDEyOAogICAgICAgREVWRlNQICAgICA0ICAgICAxSyAg ICAgICAtICAgICAgICA0ICA2NAogICAgICAgICBrb2JqICAgMzIzICAxMjkySyAgICAgICAtICAg ICAxMTIyICA0MDk2CiAgICAgIFBlci1jcHUgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEg IDMyCiAgICAgICAgIHJtYW4gICAxODYgICAgMjFLICAgICAgIC0gICAgICA2MDIgIDE2LDMyLDEy OAogICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAgICAtICAgICAyNDA1ICAxNiwzMiw2NCwx MjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgdGFza3F1ZXVlICAgIDE1ICAgICAzSyAgICAg ICAtICAgICAgIDI3ICAxNiwzMiwyNTYKICAgICAgIFVuaXRubyAgICAyMyAgICAgMksgICAgICAg LSAgICAgMzE2NyAgMzIsNjQKICAgICAgICAgdm1lbSAgICAgMyAgICA3NEsgICAgICAgLSAgICAg ICAgNSAgMTAyNCwyMDQ4LDQwOTYKICAgICAgV2l0bmVzcyAgICAgMSAgIDEyOEsgICAgICAgLSAg ICAgICAgMSAgCiAgICAgaW9jdGxvcHMgICAgIDAgICAgIDBLICAgICAgIC0gICAgIDM4MjcgIDE2 LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQKICAgICAgIHNlbGVjdCAgICAxNSAgICAgMksgICAgICAg LSAgICAgICAxNSAgMTI4CiAgICAgICAgICBpb3YgICAgIDAgICAgIDBLICAgICAgIC0gICAgMjAw MzkgIDY0LDEyOCwyNTYsNTEyCiAgICAgICAgICBtc2cgICAgIDQgICAgMzBLICAgICAgIC0gICAg ICAgIDQgIDIwNDgsNDA5NgogICAgICAgICAgc2VtICAgICA0ICAgMTA2SyAgICAgICAtICAgICAg ICA0ICAyMDQ4LDQwOTYKICAgICAgICAgIHNobSAgICAgMSAgICAyMEsgICAgICAgLSAgICAgICAg MiAgMjA0OAogICAgICAgICAgdHR5ICAgIDIxICAgIDIxSyAgICAgICAtICAgICAgIDIxICAxMDI0 CiAgICAgICAgICBwdHMgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDI1NgogICAgIG1i dWZfdGFnICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDE4ICAzMgogICAgICAgIHNobWZkICAg ICAxICAgICA4SyAgICAgICAtICAgICAgICAxICAKICAgICAgIHNvbmFtZSAgICAgMyAgICAgMUsg ICAgICAgLSAgICAxNTk4MyAgMTYsMzIsMTI4CiAgICAgICAgICBwY2IgICAgMTYgICA2NjFLICAg ICAgIC0gICAgICAgNDIgIDE2LDMyLDEyOCwxMDI0LDIwNDgKICAgICAgICAgIGFjbCAgICAgMCAg ICAgMEsgICAgICAgLSAgICAgICAgMyAgNDA5NgogICAgIHZmc2NhY2hlICAgICAxICAyMDQ4SyAg ICAgICAtICAgICAgICAxICAKICAgY2xfc2F2ZWJ1ZiAgICAgMCAgICAgMEsgICAgICAgLSAgICAg ICAgOSAgNjQKICAgICB2ZnNfaGFzaCAgICAgMSAgMTAyNEsgICAgICAgLSAgICAgICAgMSAgCiAg ICAgICB2bm9kZXMgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDI1NgogICAgICAgIG1v dW50ICAgIDE2ICAgICAxSyAgICAgICAtICAgICAgMTE5ICAxNiwzMiw2NCwxMjgsMjU2CiAgdm5v ZGVtYXJrZXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNjEgIDUxMgogICAgICAgICAgQlBG ICAgIDExICAgIDE4SyAgICAgICAtICAgICAgIDExICAxMjgsNTEyLDQwOTYKICAgICAgICBpZm5l dCAgICAgNCAgICAgN0sgICAgICAgLSAgICAgICAgNCAgMTI4LDIwNDgKICAgICAgIGlmYWRkciAg ICA1MyAgICAxNEsgICAgICAgLSAgICAgICA1NCAgMzIsNjQsMTI4LDI1Niw1MTIsMjA0OCw0MDk2 CiAgZXRoZXJfbXVsdGkgICAgMTcgICAgIDFLICAgICAgIC0gICAgICAgMjQgIDE2LDMyLDY0CiAg ICAgICAgY2xvbmUgICAgIDcgICAgIDFLICAgICAgIC0gICAgICAgIDcgIDEyOAogICAgICAgYXJw Y29tICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAxNgogICAgICBsbHRhYmxlICAgIDEw ICAgICA0SyAgICAgICAtICAgICAgIDEwICAyNTYsNTEyCiAgICAgcm91dGV0YmwgICAgMzMgICAg IDZLICAgICAgIC0gICAgICAxMzUgIDMyLDY0LDEyOCwyNTYsNTEyCiAgICAgICAgIGlnbXAgICAg IDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDI1NgogICAgIGluX211bHRpICAgICAyICAgICAx SyAgICAgICAtICAgICAgICAzICAyNTYKICAgIHNjdHBfYV9pdCAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAgMyAgMTYKICAgICBzY3RwX3ZyZiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAg MSAgNjQKICAgICBzY3RwX2lmYSAgICAgNCAgICAgMUsgICAgICAgLSAgICAgICAgNCAgMTI4CiAg ICAgc2N0cF9pZm4gICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDEyOAogICAgc2N0cF9p dGVyICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAzICAyNTYKICAgIGhvc3RjYWNoZSAgICAg MSAgICAyOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgc3luY2FjaGUgICAgIDEgICAgNjRLICAg ICAgIC0gICAgICAgIDEgIAogICAgaW42X211bHRpICAgIDE1ICAgICAySyAgICAgICAtICAgICAg IDE1ICAzMiwyNTYKICAgICAgICAgIG1sZCAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAg MTI4CiAgICBwZnNfbm9kZXMgICAgMjEgICAgIDZLICAgICAgIC0gICAgICAgMjEgIDI1NgogICAg ICBORlMgRkhBICAgICAxICAgICAySyAgICAgICAtICAgICAgICAxICAyMDQ4CiAgICAgICAgICBy cGMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgphdWRpdF9ldmNsYXNzICAgMTg3 ICAgICA2SyAgICAgICAtICAgICAgMjI4ICAzMgogICAgICBwYWdlZGVwICAgICAxICAgMTI4SyAg ICAgICAtICAgICAgIDI2ICAyNTYKICAgICBpbm9kZWRlcCAgICAgMSAgMTAyNEsgICAgICAgLSAg ICAgIDE5OSAgNTEyCiAgICBibXNhZmVtYXAgICAgIDIgICAgIDlLICAgICAgIC0gICAgICAxMTQg IDI1NgogICAgICAgbmV3YmxrICAgICAxICAyMDQ4SyAgICAgICAtICAgICAgMjcyICAyNTYKICAg ICBmcmVlZnJhZyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICA2NiAgMTI4CiAgICAgZnJlZWJs a3MgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNjYgIDI1NgogICAgIGZyZWVmaWxlICAgICAw ICAgICAwSyAgICAgICAtICAgICAgIDkxICA2NAogICAgICAgZGlyYWRkICAgICAwICAgICAwSyAg ICAgICAtICAgICAgMTIwICAxMjgKICAgICAgICBta2RpciAgICAgMCAgICAgMEsgICAgICAgLSAg ICAgICAxMiAgMTI4CiAgICAgICBkaXJyZW0gICAgIDAgICAgIDBLICAgICAgIC0gICAgICAxMjYg IDEyOAogICAgbmV3ZGlyYmxrICAgICAwICAgICAwSyAgICAgICAtICAgICAgICA2ICA2NAogICAg IGZyZWV3b3JrICAgICAxICAgICAxSyAgICAgICAtICAgICAgMTExICAxNiwxMjgKICAgICAgamFk ZHJlZiAgICAgMCAgICAgMEsgICAgICAgLSAgICAgIDEzMiAgMTI4CiAgICAgIGpyZW1yZWYgICAg IDAgICAgIDBLICAgICAgIC0gICAgICAxMzggIDEyOAogICAgICBqbmV3YmxrICAgICAwICAgICAw SyAgICAgICAtICAgICAgMjcxICAxMjgKICAgIGpmcmVlZnJhZyAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICA2NiAgMTI4CiAgICAgICAgIGpzZWcgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAg NTAgIDEyOAogICAgICBqc2VnZGVwICAgICAzICAgICAxSyAgICAgICAtICAgICAgNjA3ICA2NAog ICAgICAgIHNiZGVwICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDE5ICA2NAogICAgIHNhdmVk aW5vICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDYzICAyNTYKICAgICAgamJsb2NrcyAgICAg MiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4LDI1NgogIHVmc19kaXJoYXNoICAgIDUxICAg IDEwSyAgICAgICAtICAgICAgIDUxICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgdWZzX3F1b3Rh ICAgICAxICAxMDI0SyAgICAgICAtICAgICAgICAxICAKICAgIHVmc19tb3VudCAgICAgMyAgICAy MUsgICAgICAgLSAgICAgICAgNCAgNTEyLDQwOTYKICAgIHZtX3BnZGF0YSAgICAgMiAgIDUxM0sg ICAgICAgLSAgICAgICAgMiAgMTI4CiAgICAgIFVNQUhhc2ggICAgIDEgICAgIDFLICAgICAgIC0g ICAgICAgIDEgIDUxMgogICAgICAgICBHRU9NICAgIDg4ICAgIDE1SyAgICAgICAtICAgICAzODEy ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgKICAgICAgIGZlZWRlciAgICAgNyAgICAg MUsgICAgICAgLSAgICAgICAgNyAgMzIKICAgICAgc2NzaV9jZCAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAxOCAgMTYKICAgICAgbWVtZGVzYyAgICAgMSAgICAgNEsgICAgICAgLSAgICAgICAg MSAgNDA5NgogICAgICBzY3NpX2RhICAgICAwICAgICAwSyAgICAgICAtICAgICAxMTM2ICAzMiw2 NAogICAgIGF0a2JkZGV2ICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICA2NAogICAgcmFp ZF9kYXRhICAgICAwICAgICAwSyAgICAgICAtICAgICAgNDkyICAzMiwxMjgsMjU2CiAgICAgIENB TSBERVYgICAgIDcgICAgMTRLICAgICAgIC0gICAgMTQ2NDYgIDIwNDgKICAgICBwY2lfbGluayAg ICAxNiAgICAgMksgICAgICAgLSAgICAgICAxNiAgNjQsMTI4CiAgICBhY3BpX3BlcmYgICAgIDQg ICAgIDFLICAgICAgIC0gICAgICAgIDQgIDI1NgogICAgICAgICBVQVJUICAgICA2ICAgICA1SyAg ICAgICAtICAgICAgICA2ICAxNiwxMDI0CiAgICAgIENBTSBDQ0IgICAgIDQgICAgIDhLICAgICAg IC0gICAgMTgyNDggIDIwNDgKbWRfbnZpZGlhX2RhdGEgICAgIDAgICAgIDBLICAgICAgIC0gICAg ICAgODIgIDUxMgogIGRkYl9jYXB0dXJlICAgICAxICAgIDQ4SyAgICAgICAtICAgICAgICAxICAK ICBtZF9zaWlfZGF0YSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICA4MiAgNTEyCiAgICAgYWNw aWludHIgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAgICBhY3BpY2EgIDEw NTIgICAxMDVLICAgICAgIC0gICAgNjQxNTkgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0 OAogICAgIENBTSBwYXRoICAgICA5ICAgICAxSyAgICAgICAtICAgIDQ0NjcwICAzMgogICAgICAg YXBtZGV2ICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAxMjgKICAgbWFkdF90YWJsZSAg ICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMSAgNDA5NgogICAgICAgaXNhZGV2ICAgICA3ICAg ICAxSyAgICAgICAtICAgICAgICA3ICAxMjgKICAgQ0FNIHBlcmlwaCAgICAgNiAgICAgMksgICAg ICAgLSAgICAxNDcwMyAgMTYsMzIsNjQsMTI4LDI1NgogICAgICAgICAgVVNCICAgIDkwICAgMTMz SyAgICAgICAtICAgICAgIDk4ICAxNiwzMiwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAg ICAgVVNCZGV2ICAgIDc4ICAgIDE2SyAgICAgICAtICAgICAgIDc4ICAzMiw2NCwxMjgsNTEyLDQw OTYKICAgICAgaW9fYXBpYyAgICAgMiAgICAgNEsgICAgICAgLSAgICAgICAgMiAgMjA0OAogICAg ICAgICAgTUNBICAgIDE0ICAgICAySyAgICAgICAtICAgICAgIDE0ICAzMiwxMjgKICAgICAgZW50 cm9weSAgMTAyNiAgICA2NUsgICAgICAgLSAgICAgMTAyOSAgMzIsNjQsNDA5NgogICAgICAgICBj ZGV2ICAgICA3ICAgICAySyAgICAgICAtICAgICAgICA3ICAyNTYKICAgICAgICAgIG1zaSAgICAg NiAgICAgMUsgICAgICAgLSAgICAgICAgNiAgMTI4CiAgICAgbmV4dXNkZXYgICAgIDQgICAgIDFL ICAgICAgIC0gICAgICAgIDQgIDE2CiAgICAgIGF0YV9wY2kgICAgIDIgICAgIDFLICAgICAgIC0g ICAgICAgIDIgIDY0CiAgICAgZmlsZWRlc2MgICAgNDYgICAgOTJLICAgICAgIC0gICAgIDE0MDcg IDIwNDgKICAgICAgICBzaWdpbyAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNjQKCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQp2bXN0YXQgLXoKCklURU0gICAgICAgICAgICAgICAgICAgU0laRSAgTElN SVQgICAgIFVTRUQgICAgIEZSRUUgICAgICBSRVEgRkFJTCBTTEVFUAoKVU1BIEtlZ3M6ICAgICAg ICAgICAgICAgMzg0LCAgICAgIDAsICAgICAgOTUsICAgICAgIDUsICAgICAgOTUsICAgMCwgICAw ClVNQSBab25lczogICAgICAgICAgICAgMTE1MiwgICAgICAwLCAgICAgIDk1LCAgICAgICAxLCAg ICAgIDk1LCAgIDAsICAgMApVTUEgU2xhYnM6ICAgICAgICAgICAgICAgODAsICAgICAgMCwgICAg MjI0NSwgICAgIDUwNSwgICAyMDE2OCwgICAwLCAgIDAKVU1BIFJDbnRTbGFiczogICAgICAgICAg IDg4LCAgICAgIDAsICAgIDEyNTQsICAgICAgIDYsICAgIDEyNTQsICAgMCwgICAwClVNQSBIYXNo OiAgICAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgICA4LCAgICAgICA3LCAgICAgICA5LCAg IDAsICAgMAo0IEJ1Y2tldDogICAgICAgICAgICAgICAgMzIsICAgICAgMCwgICAgICAxMiwgICAg IDQ4OCwgICAgIDk0MSwgICAwLCAgIDAKOCBCdWNrZXQ6ICAgICAgICAgICAgICAgIDY0LCAgICAg IDAsICAgICAgMTcsICAgICA1NDEsICAgIDk2NjUsICAgMCwgICAwCjE2IEJ1Y2tldDogICAgICAg ICAgICAgIDEyOCwgICAgICAwLCAgICAgIDU2LCAgICAgNDcxLCAgICAgMTYzLCAgMzgsICAgMAoz MiBCdWNrZXQ6ICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgICA0NiwgICAgIDI2OSwgICAg IDE5MiwgMTA1LCAgIDAKNjQgQnVja2V0OiAgICAgICAgICAgICAgNTEyLCAgICAgIDAsICAgICAg OTUsICAgICAxMTMsICAgIDMxNzQsIDEwNCwgICAwCjEyOCBCdWNrZXQ6ICAgICAgICAgICAgMTAy NCwgICAgICAwLCAgICAgMTM3LCAgICAgIDY3LCAgICAgOTk5LCAxNDcsICAgMAp2bWVtIGJ0YWc6 ICAgICAgICAgICAgICAgNTYsICAgICAgMCwgICAgNjg3NCwgICAgMTAwNywgICAyMDA1MCwgMTEx LCAgIDAKVk0gT0JKRUNUOiAgICAgICAgICAgICAgMjU2LCAgICAgIDAsICAgIDE1MTYsICAgICAx OTQsICAgMTY3NTksICAgMCwgICAwClJBRElYIE5PREU6ICAgICAgICAgICAgIDE0NCwgICAgICAw LCAgICAzMzUwLCAgICAxNDAyLCAgIDQ4MDk1LCAgNTEsICAgMApNQVA6ICAgICAgICAgICAgICAg ICAgICAyNDAsICAgICAgMCwgICAgICAgMywgICAgICA2MSwgICAgICAgMywgICAwLCAgIDAKS01B UCBFTlRSWTogICAgICAgICAgICAgMTI4LCAgICAgIDAsICAgICAgIDksICAgICA1MTgsICAgICAg MTUsICAgMCwgICAwCk1BUCBFTlRSWTogICAgICAgICAgICAgIDEyOCwgICAgICAwLCAgICAgOTM0 LCAgICAgNTg1LCAgIDM5MjA3LCAgIDAsICAgMApWTVNQQUNFOiAgICAgICAgICAgICAgICA0NDgs ICAgICAgMCwgICAgICAzMCwgICAgIDE1MCwgICAgMTM4NSwgICAwLCAgIDAKZmFrZXBnOiAgICAg ICAgICAgICAgICAgMTA0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCm10X3pvbmU6ICAgICAgICAgICAgICAgNDExMiwgICAgICAwLCAgICAgMzQ0LCAgICAgICAx LCAgICAgMzUwLCAgIDAsICAgMAoxNjogICAgICAgICAgICAgICAgICAgICAgMTYsICAgICAgMCwg ICAgMjA4NiwgICAgIDkyNiwgICA3MTcxMywgICAwLCAgIDAKMzI6ICAgICAgICAgICAgICAgICAg ICAgIDMyLCAgICAgIDAsICAgIDIzMDQsICAgIDE1NzEsICAgNTg1ODcsICAgMCwgICAwCjY0OiAg ICAgICAgICAgICAgICAgICAgICA2NCwgICAgICAwLCAgICA1NDAxLCAgICAgNDg5LCAgIDM2NDQ5 LCAgIDAsICAgMAoxMjg6ICAgICAgICAgICAgICAgICAgICAxMjgsICAgICAgMCwgICAgNDk4OCwg ICAgMTAyNiwgICA2ODkxNiwgICAwLCAgIDAKMjU2OiAgICAgICAgICAgICAgICAgICAgMjU2LCAg ICAgIDAsICAgICA3MjEsICAgIDE2MzQsICAgMzE2NDksICAgMCwgICAwCjUxMjogICAgICAgICAg ICAgICAgICAgIDUxMiwgICAgICAwLCAgICAgMzU5LCAgICAgMTYxLCAgICA3Njc4LCAgIDAsICAg MAoxMDI0OiAgICAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgICA0NiwgICAgIDE5MCwg ICAgOTczMCwgICAwLCAgIDAKMjA0ODogICAgICAgICAgICAgICAgICAyMDQ4LCAgICAgIDAsICAg ICAgOTMsICAgIDIwNTksICAgNjMwNTgsICAgMCwgICAwCjQwOTY6ICAgICAgICAgICAgICAgICAg NDA5NiwgICAgICAwLCAgICAgNDM2LCAgICAgICA2LCAgICA2MzMxLCAgIDAsICAgMApTTEVFUFFV RVVFOiAgICAgICAgICAgICAgODAsICAgICAgMCwgICAgIDE0MiwgICAgIDM4NSwgICAgIDE0Miwg ICAwLCAgIDAKdWludDY0IHBjcHU6ICAgICAgICAgICAgICA4LCAgICAgIDAsICAgIDEzODYsICAg ICAxNTAsICAgIDEzODYsICAgMCwgICAwCkZpbGVzOiAgICAgICAgICAgICAgICAgICA4MCwgICAg ICAwLCAgICAgIDc5LCAgICAgNDIxLCAgIDE4MDI2LCAgIDAsICAgMApUVVJOU1RJTEU6ICAgICAg ICAgICAgICAxMzYsICAgICAgMCwgICAgIDE0MiwgICAgIDE3OCwgICAgIDE0MiwgICAwLCAgIDAK cmxfZW50cnk6ICAgICAgICAgICAgICAgIDQwLCAgICAgIDAsICAgICAgNDQsICAgICA0NTYsICAg ICAgNDQsICAgMCwgICAwCnVtdHggcGk6ICAgICAgICAgICAgICAgICA5NiwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApNQUMgbGFiZWxzOiAgICAgICAgICAgICAg NDAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKUFJPQzogICAg ICAgICAgICAgICAgICAxMjA4LCAgICAgIDAsICAgICAgNDYsICAgICAgMTQsICAgIDE0MDYsICAg MCwgICAwClRIUkVBRDogICAgICAgICAgICAgICAgMTE2OCwgICAgICAwLCAgICAgMTI5LCAgICAg IDEyLCAgICAgMTQwLCAgIDAsICAgMApjcHVzZXQ6ICAgICAgICAgICAgICAgICAgNzIsICAgICAg MCwgICAgICA4NiwgICAgIDE4OSwgICAgICA5OCwgICAwLCAgIDAKYXVkaXRfcmVjb3JkOiAgICAg ICAgICAxMjQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCm1i dWZfcGFja2V0OiAgICAgICAgICAgIDI1NiwgMTYxMTkxNSwgICAgMjA0MCwgICAgIDQ2NSwgICAg MjUxNCwgICAxLCAgIDAKbWJ1ZjogICAgICAgICAgICAgICAgICAgMjU2LCAxNjExOTE1LCAgICAg NTExLCAgICAgNjE4LCAgICA2MDk3LCAgIDAsICAgMAptYnVmX2NsdXN0ZXI6ICAgICAgICAgIDIw NDgsIDI1MTg2MCwgICAgMjUwMSwgICAgICAgMSwgICAgMjUwMSwyNTAxLCAgIDAKbWJ1Zl9qdW1i b19wYWdlOiAgICAgICA0MDk2LCAxMjU5MjksICAgICAgIDAsICAgICAgIDMsICAgICAgIDcsICAg MywgICAwCm1idWZfanVtYm9fOWs6ICAgICAgICAgOTIxNiwgMTExOTM2LCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMAptYnVmX2p1bWJvXzE2azogICAgICAgMTYzODQsICA4Mzk1 MiwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKbWJ1Zl9leHRfcmVmY250OiAg ICAgICAgICA0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCmdf YmlvOiAgICAgICAgICAgICAgICAgIDI0OCwgICAgICAwLCAgICAgICAwLCAgICAgMzY4LCAyNjk3 NTgxLCAgIDAsICAgMAp0dHlpbnE6ICAgICAgICAgICAgICAgICAxNjAsICAgICAgMCwgICAgIDM2 MCwgICAgIDE0MCwgICAgIDk0NSwgICAwLCAgIDAKdHR5b3V0cTogICAgICAgICAgICAgICAgMjU2 LCAgICAgIDAsICAgICAxODgsICAgICAxMjcsICAgICA1MDAsICAgMCwgICAwCmF0YV9yZXF1ZXN0 OiAgICAgICAgICAgIDMzNiwgICAgICAwLCAgICAgICAxLCAgICAgMTUzLCAgICA5ODI0LCAgIDAs ICAgMAp2dG5ldF90eF9oZHI6ICAgICAgICAgICAgMjQsICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKRlBVX3NhdmVfYXJlYTogICAgICAgICAgNTEyLCAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwClZOT0RFOiAgICAgICAgICAgICAg ICAgIDQ3MiwgICAgICAwLCAgICAgODUxLCAgICAgIDUzLCAgICAgOTQ0LCAgIDAsICAgMApWTk9E RVBPTEw6ICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKQlVGIFRSSUU6ICAgICAgICAgICAgICAgMTQ0LCAgICAgIDAsICAgICAgODAs ICAgMjY1NjksICAgICA2MjcsICAgMCwgICAwClMgVkZTIENhY2hlOiAgICAgICAgICAgIDEwOCwg ICAgICAwLCAgICAgODQwLCAgICAgNDIwLCAgICAzMzE2LCAgIDAsICAgMApTVFMgVkZTIENhY2hl OiAgICAgICAgICAxNDgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKTCBWRlMgQ2FjaGU6ICAgICAgICAgICAgMzI4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCkxUUyBWRlMgQ2FjaGU6ICAgICAgICAgIDM2OCwgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApOQU1FSTogICAgICAgICAgICAgICAg IDEwMjQsICAgICAgMCwgICAgICAgMCwgICAgICA2OCwgICA2ODgzMCwgICAwLCAgIDAKTkNMTk9E RTogICAgICAgICAgICAgICAgNTI4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCkRJUkhBU0g6ICAgICAgICAgICAgICAgMTAyNCwgICAgICAwLCAgICAgIDcyLCAg ICAgIDMyLCAgICAgIDcyLCAgIDAsICAgMApwaXBlOiAgICAgICAgICAgICAgICAgICA3NDQsICAg ICAgMCwgICAgICAgNCwgICAgICA1MSwgICAgIDc5MiwgICAwLCAgIDAKcHJvY2Rlc2M6ICAgICAg ICAgICAgICAgMTI4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw Ck1vdW50cG9pbnRzOiAgICAgICAgICAgIDgxNiwgICAgICAwLCAgICAgICAyLCAgICAgIDEzLCAg ICAgICAyLCAgIDAsICAgMAprc2lnaW5mbzogICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAg ICA1MywgICAgIDk5NywgICAgICA4NSwgICAwLCAgIDAKaXRpbWVyOiAgICAgICAgICAgICAgICAg MzUyLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCktOT1RFOiAg ICAgICAgICAgICAgICAgIDEyOCwgICAgICAwLCAgICAgICAwLCAgICAgNTI3LCAgICAgIDMwLCAg IDAsICAgMApzb2NrZXQ6ICAgICAgICAgICAgICAgICA2OTYsIDEyOTkwNSwgICAgICAxOCwgICAg ICAzNywgICAgMjc3MSwgICAwLCAgIDAKaXBxOiAgICAgICAgICAgICAgICAgICAgIDU2LCAgIDc4 ODEsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnVkcF9pbnBjYjogICAgICAg ICAgICAgIDM5MiwgMTI5OTEwLCAgICAgICAyLCAgICAgMTE4LCAgICAgMjA0LCAgIDAsICAgMAp1 ZHBjYjogICAgICAgICAgICAgICAgICAgMTYsIDEzMDAxOCwgICAgICAgMiwgICAgIDUwMCwgICAg IDIwNCwgICAwLCAgIDAKdGNwX2lucGNiOiAgICAgICAgICAgICAgMzkyLCAxMjk5MTAsICAgICAg IDQsICAgICAxMTYsICAgICAgIDksICAgMCwgICAwCnRjcGNiOiAgICAgICAgICAgICAgICAgMTAy NCwgMTI5OTA4LCAgICAgICA0LCAgICAgIDQ4LCAgICAgICA5LCAgIDAsICAgMAp0Y3B0dzogICAg ICAgICAgICAgICAgICAgODgsICAyNjAxMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAw LCAgIDAKc3luY2FjaGU6ICAgICAgICAgICAgICAgMTYwLCAgMTUzNzUsICAgICAgIDAsICAgICAg NzUsICAgICAgIDEsICAgMCwgICAwCmhvc3RjYWNoZTogICAgICAgICAgICAgIDEzNiwgIDE1Mzcw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp0Y3ByZWFzczogICAgICAgICAg ICAgICAgNDAsICAxNTgwMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKc2Fj a2hvbGU6ICAgICAgICAgICAgICAgIDMyLCAgICAgIDAsICAgICAgIDAsICAgICAxMjUsICAgICAg MTUsICAgMCwgICAwCnNjdHBfZXA6ICAgICAgICAgICAgICAgMTQwOCwgMTI5OTA2LCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3RwX2Fzb2M6ICAgICAgICAgICAgIDIzNTIs ICA0MDAwMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKc2N0cF9sYWRkcjog ICAgICAgICAgICAgIDQ4LCAgODAwMTIsICAgICAgIDAsICAgICAzMzIsICAgICAgIDMsICAgMCwg ICAwCnNjdHBfcmFkZHI6ICAgICAgICAgICAgIDcyOCwgIDgwMDAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMApzY3RwX2NodW5rOiAgICAgICAgICAgICAxMzYsIDQwMDAyNiwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKc2N0cF9yZWFkcTogICAgICAgICAg ICAgMTA0LCA0MDAwMjYsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBf c3RyZWFtX21zZ19vdXQ6ICAgIDEwNCwgNDAwMDI2LCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMApzY3RwX2FzY29uZjogICAgICAgICAgICAgNDAsIDQwMDAwMCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKc2N0cF9hc2NvbmZfYWNrOiAgICAgICAgIDQ4LCA0 MDAwNjAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnJpcGNiOiAgICAgICAg ICAgICAgICAgIDM5MiwgMTI5OTEwLCAgICAgICAxLCAgICAgIDI5LCAgICAgICAxLCAgIDAsICAg MAp1bnBjYjogICAgICAgICAgICAgICAgICAyNDAsIDEyOTkyMCwgICAgICAxMCwgICAgIDI0Niwg ICAgMjU0OCwgICAwLCAgIDAKcnRlbnRyeTogICAgICAgICAgICAgICAgMjAwLCAgICAgIDAsICAg ICAgMTMsICAgICAyNDcsICAgICAgMTQsICAgMCwgICAwCnNlbGZkOiAgICAgICAgICAgICAgICAg ICA1NiwgICAgICAwLCAgICAgIDM0LCAgICAgNTM0LCAgIDE2NzAxLCAgIDAsICAgMApTV0FQTUVU QTogICAgICAgICAgICAgICAyODgsIDUwMzcyNCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKRkZTIGlub2RlOiAgICAgICAgICAgICAgMTY4LCAgICAgIDAsICAgICA4MDMsICAg ICAxODYsICAgICA4OTQsICAgMCwgICAwCkZGUzEgZGlub2RlOiAgICAgICAgICAgIDEyOCwgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApGRlMyIGRpbm9kZTogICAg ICAgICAgICAyNTYsICAgICAgMCwgICAgIDgwMywgICAgIDE4NywgICAgIDg5NCwgICAwLCAgIDAK CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1pCgppbnRlcnJ1cHQgICAgICAgICAgICAgICAgICAg ICAgICAgIHRvdGFsICAgICAgIHJhdGUKaXJxMTogYXRrYmQwICAgICAgICAgICAgICAgICAgICAg ICAgIDM5MiAgICAgICAgICA4CmlycTE5OiBlaGNpMCAgICAgICAgICAgICAgICAgICAgICAgIDE2 MzEgICAgICAgICAzNgppcnEyMDogaHBldDAgdWhjaTMrICAgICAgICAgICAgICAgIDI3ODI5ICAg ICAgICA2MTgKaXJxMjE6IHVoY2kyIHVoY2k0KyAgICAgICAgICAgICAgICAgICA2MiAgICAgICAg ICAxCmlycTIyOiBhdGFwY2kxICAgICAgICAgICAgICAgICAgICAgICAzNTcgICAgICAgICAgNwpp cnEyMzogYXRhcGNpMCAgICAgICAgICAgICAgICAgICAgICAzNjMyICAgICAgICAgODAKY3B1MDp0 aW1lciAgICAgICAgICAgICAgICAgICAgICAgIDEwMDAwNyAgICAgICAyMjIyCmlycTI1NjogYmNl MCAgICAgICAgICAgICAgICAgICAgICAgIDI5NDUgICAgICAgICA2NQpjcHUzOnRpbWVyICAgICAg ICAgICAgICAgICAgICAgICAgMjAwMTc0ICAgICAgIDQ0NDgKY3B1Mjp0aW1lciAgICAgICAgICAg ICAgICAgICAgICAgIDE4MDU2MiAgICAgICA0MDEyCmNwdTE6dGltZXIgICAgICAgICAgICAgICAg ICAgICAgICAxMDM0MDYgICAgICAgMjI5NwppcnEyNTg6ICAgICAgICAgICAgICAgICAgICAgICAg ICAgMjIyMTk2ICAgICAgIDQ5MzcKaXJxMjU5OiAgICAgICAgICAgICAgICAgICAgICAgICAgIDIy MTQ2OCAgICAgICA0OTIxCmlycTI2MDogICAgICAgICAgICAgICAgICAgICAgICAgICAyMjgxOTIg ICAgICAgNTA3MAppcnEyNjE6ICAgICAgICAgICAgICAgICAgICAgICAgICAgMjI1ODQ4ICAgICAg IDUwMTgKVG90YWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTUxODcwMSAgICAgIDMzNzQ4 CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KcHN0YXQgLVQKCiA3OS8xMjk5MDIgZmlsZXMKME0vMzg1MU0gc3dh cCBzcGFjZQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnBzdGF0IC1zCgpEZXZpY2UgICAgICAgICAgNTEyLWJs b2NrcyAgICAgVXNlZCAgICBBdmFpbCBDYXBhY2l0eQovZGV2L3VrYmQxICAgICAgICAgNzg4ODYx NiAgICAgICAgMCAgNzg4ODYxNiAgICAgMCUKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQppb3N0YXQKCmlvc3Rh dDoga3ZtX3JlYWQoX3RrX25pbik6IGludmFsaWQgYWRkcmVzcyAoMHgwKQppb3N0YXQ6IGRpc2Fi bGluZyBUVFkgc3RhdGlzdGljcwogICAgICAgICAgICBhZGEwICAgICAgICAgICAgICBjZDAgICAg ICAgICAgICBwYXNzMCAgICAgICAgICAgICBjcHUKICBLQi90IHRwcyAgTUIvcyAgIEtCL3QgdHBz ICBNQi9zICAgS0IvdCB0cHMgIE1CL3MgIHVzIG5pIHN5IGluIGlkCiAzMS44NCAgNzkgIDIuNDcg ICAwLjkzICAgMyAgMC4wMCAgIDAuMDAgICAwICAwLjAwICAgMCAgMCAxMiAgMiA4NQoKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCmlwY3MgLWEKCk1lc3NhZ2UgUXVldWVzOgpUICAgICAgICAgICBJRCAgICAgICAg ICBLRVkgTU9ERSAgICAgICAgT1dORVIgICAgR1JPVVAgICAgQ1JFQVRPUiAgQ0dST1VQICAgICAg ICAgICAgICAgICBDQllURVMgICAgICAgICAgICAgICAgIFFOVU0gICAgICAgICAgICAgICBRQllU RVMgICAgICAgIExTUElEICAgICAgICBMUlBJRCBTVElNRSAgICBSVElNRSAgICBDVElNRSAgIAoK U2hhcmVkIE1lbW9yeToKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUgICAgICAgIE9X TkVSICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgIE5BVFRDSCAgICAgICAgU0VH U1ogICAgICAgICBDUElEICAgICAgICAgTFBJRCBBVElNRSAgICBEVElNRSAgICBDVElNRSAgIAoK U2VtYXBob3JlczoKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVS ICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgICBOU0VNUyBPVElNRSAgICBDVElN RSAgIAoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQppcGNzIC1UCgptc2dpbmZvOgoJbXNnbWF4OiAgICAgICAg MTYzODQJKG1heCBjaGFyYWN0ZXJzIGluIGEgbWVzc2FnZSkKCW1zZ21uaTogICAgICAgICAgIDQw CSgjIG9mIG1lc3NhZ2UgcXVldWVzKQoJbXNnbW5iOiAgICAgICAgIDIwNDgJKG1heCBjaGFyYWN0 ZXJzIGluIGEgbWVzc2FnZSBxdWV1ZSkKCW1zZ3RxbDogICAgICAgICAgIDQwCShtYXggIyBvZiBt ZXNzYWdlcyBpbiBzeXN0ZW0pCgltc2dzc3o6ICAgICAgICAgICAgOAkoc2l6ZSBvZiBhIG1lc3Nh Z2Ugc2VnbWVudCkKCW1zZ3NlZzogICAgICAgICAyMDQ4CSgjIG9mIG1lc3NhZ2Ugc2VnbWVudHMg aW4gc3lzdGVtKQoKc2htaW5mbzoKCXNobW1heDogICAgNTM2ODcwOTEyCShtYXggc2hhcmVkIG1l bW9yeSBzZWdtZW50IHNpemUpCglzaG1taW46ICAgICAgICAgICAgMQkobWluIHNoYXJlZCBtZW1v cnkgc2VnbWVudCBzaXplKQoJc2htbW5pOiAgICAgICAgICAxOTIJKG1heCBudW1iZXIgb2Ygc2hh cmVkIG1lbW9yeSBpZGVudGlmaWVycykKCXNobXNlZzogICAgICAgICAgMTI4CShtYXggc2hhcmVk IG1lbW9yeSBzZWdtZW50cyBwZXIgcHJvY2VzcykKCXNobWFsbDogICAgICAgMTMxMDcyCShtYXgg YW1vdW50IG9mIHNoYXJlZCBtZW1vcnkgaW4gcGFnZXMpCgpzZW1pbmZvOgoJc2VtbW5pOiAgICAg ICAgICAgNTAJKCMgb2Ygc2VtYXBob3JlIGlkZW50aWZpZXJzKQoJc2VtbW5zOiAgICAgICAgICAz NDAJKCMgb2Ygc2VtYXBob3JlcyBpbiBzeXN0ZW0pCglzZW1tbnU6ICAgICAgICAgIDE1MAkoIyBv ZiB1bmRvIHN0cnVjdHVyZXMgaW4gc3lzdGVtKQoJc2VtbXNsOiAgICAgICAgICAzNDAJKG1heCAj IG9mIHNlbWFwaG9yZXMgcGVyIGlkKQoJc2Vtb3BtOiAgICAgICAgICAxMDAJKG1heCAjIG9mIG9w ZXJhdGlvbnMgcGVyIHNlbW9wIGNhbGwpCglzZW11bWU6ICAgICAgICAgICA1MAkobWF4ICMgb2Yg dW5kbyBlbnRyaWVzIHBlciBwcm9jZXNzKQoJc2VtdXN6OiAgICAgICAgICA2MzIJKHNpemUgaW4g Ynl0ZXMgb2YgdW5kbyBzdHJ1Y3R1cmUpCglzZW12bXg6ICAgICAgICAzMjc2Nwkoc2VtYXBob3Jl IG1heGltdW0gdmFsdWUpCglzZW1hZW06ICAgICAgICAxNjM4NAkoYWRqdXN0IG9uIGV4aXQgbWF4 IHZhbHVlKQoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZnNzdGF0CgpDbGllbnQgSW5mbzoKUnBjIENvdW50 czoKICBHZXRhdHRyICAgU2V0YXR0ciAgICBMb29rdXAgIFJlYWRsaW5rICAgICAgUmVhZCAgICAg V3JpdGUgICAgQ3JlYXRlICAgIFJlbW92ZQogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwCiAgIFJlbmFt ZSAgICAgIExpbmsgICBTeW1saW5rICAgICBNa2RpciAgICAgUm1kaXIgICBSZWFkZGlyICBSZGly UGx1cyAgICBBY2Nlc3MKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAogICAgTWtub2QgICAgRnNzdGF0 ICAgIEZzaW5mbyAgUGF0aENvbmYgICAgQ29tbWl0CiAgICAgICAgMCAgICAgICAgIDAgICAgICAg ICAwICAgICAgICAgMCAgICAgICAgIDAKUnBjIEluZm86CiBUaW1lZE91dCAgIEludmFsaWQgWCBS ZXBsaWVzICAgUmV0cmllcyAgUmVxdWVzdHMKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAg ICAgICAgICAwICAgICAgICAgMApDYWNoZSBJbmZvOgpBdHRyIEhpdHMgICAgTWlzc2VzIExrdXAg SGl0cyAgICBNaXNzZXMgQmlvUiBIaXRzICAgIE1pc3NlcyBCaW9XIEhpdHMgICAgTWlzc2VzCiAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAw ICAgICAgICAgMCAgICAgICAgIDAKQmlvUkxIaXRzICAgIE1pc3NlcyBCaW9EIEhpdHMgICAgTWlz c2VzIERpckUgSGl0cyAgICBNaXNzZXMgQWNjcyBIaXRzICAgIE1pc3NlcwogICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAg ICAgICAgICAwCgpTZXJ2ZXIgSW5mbzoKICBHZXRhdHRyICAgU2V0YXR0ciAgICBMb29rdXAgIFJl YWRsaW5rICAgICAgUmVhZCAgICAgV3JpdGUgICAgQ3JlYXRlICAgIFJlbW92ZQogICAgICAgIDAg ICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAg IDAgICAgICAgICAwCiAgIFJlbmFtZSAgICAgIExpbmsgICBTeW1saW5rICAgICBNa2RpciAgICAg Um1kaXIgICBSZWFkZGlyICBSZGlyUGx1cyAgICBBY2Nlc3MKICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAg MAogICAgTWtub2QgICAgRnNzdGF0ICAgIEZzaW5mbyAgUGF0aENvbmYgICAgQ29tbWl0CiAgICAg ICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKU2VydmVyIFJldC1G YWlsZWQKICAgICAgICAgICAgICAgIDAKU2VydmVyIEZhdWx0cwogICAgICAgICAgICAwClNlcnZl ciBDYWNoZSBTdGF0czoKICAgSW5wcm9nICAgICAgSWRlbSAgTm9uLWlkZW0gICAgTWlzc2VzCiAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMApTZXJ2ZXIgV3JpdGUgR2F0aGVy aW5nOgogV3JpdGVPcHMgIFdyaXRlUlBDICAgT3BzYXZlZAogICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5ldHN0YXQgLXMKCnRjcDoKCTkxNiBwYWNrZXRzIHNl bnQKCQk4OTYgZGF0YSBwYWNrZXRzICgxMjgzNzkgYnl0ZXMpCgkJMCBkYXRhIHBhY2tldHMgKDAg Ynl0ZXMpIHJldHJhbnNtaXR0ZWQKCQkwIGRhdGEgcGFja2V0cyB1bm5lY2Vzc2FyaWx5IHJldHJh bnNtaXR0ZWQKCQkwIHJlc2VuZHMgaW5pdGlhdGVkIGJ5IE1UVSBkaXNjb3ZlcnkKCQkyMCBhY2st b25seSBwYWNrZXRzICgxOSBkZWxheWVkKQoJCTAgVVJHIG9ubHkgcGFja2V0cwoJCTAgd2luZG93 IHByb2JlIHBhY2tldHMKCQkwIHdpbmRvdyB1cGRhdGUgcGFja2V0cwoJCTAgY29udHJvbCBwYWNr ZXRzCgkxMTI4IHBhY2tldHMgcmVjZWl2ZWQKCQk4MjYgYWNrcyAoZm9yIDEyODM4MCBieXRlcykK CQkxNCBkdXBsaWNhdGUgYWNrcwoJCTAgYWNrcyBmb3IgdW5zZW50IGRhdGEKCQk3NzAgcGFja2V0 cyAoNDA3MzcgYnl0ZXMpIHJlY2VpdmVkIGluLXNlcXVlbmNlCgkJMCBjb21wbGV0ZWx5IGR1cGxp Y2F0ZSBwYWNrZXRzICgwIGJ5dGVzKQoJCTAgb2xkIGR1cGxpY2F0ZSBwYWNrZXRzCgkJMCBwYWNr ZXRzIHdpdGggc29tZSBkdXAuIGRhdGEgKDAgYnl0ZXMgZHVwZWQpCgkJMCBvdXQtb2Ytb3JkZXIg cGFja2V0cyAoMCBieXRlcykKCQkwIHBhY2tldHMgKDAgYnl0ZXMpIG9mIGRhdGEgYWZ0ZXIgd2lu ZG93CgkJMCB3aW5kb3cgcHJvYmVzCgkJMCB3aW5kb3cgdXBkYXRlIHBhY2tldHMKCQkwIHBhY2tl dHMgcmVjZWl2ZWQgYWZ0ZXIgY2xvc2UKCQkwIGRpc2NhcmRlZCBmb3IgYmFkIGNoZWNrc3VtcwoJ CTAgZGlzY2FyZGVkIGZvciBiYWQgaGVhZGVyIG9mZnNldCBmaWVsZHMKCQkwIGRpc2NhcmRlZCBi ZWNhdXNlIHBhY2tldCB0b28gc2hvcnQKCQkwIGRpc2NhcmRlZCBkdWUgdG8gbWVtb3J5IHByb2Js ZW1zCgkwIGNvbm5lY3Rpb24gcmVxdWVzdHMKCTEgY29ubmVjdGlvbiBhY2NlcHQKCTAgYmFkIGNv bm5lY3Rpb24gYXR0ZW1wdHMKCTAgbGlzdGVuIHF1ZXVlIG92ZXJmbG93cwoJMCBpZ25vcmVkIFJT VHMgaW4gdGhlIHdpbmRvd3MKCTEgY29ubmVjdGlvbiBlc3RhYmxpc2hlZCAoaW5jbHVkaW5nIGFj Y2VwdHMpCgk1IGNvbm5lY3Rpb25zIGNsb3NlZCAoaW5jbHVkaW5nIDAgZHJvcHMpCgkJMCBjb25u ZWN0aW9ucyB1cGRhdGVkIGNhY2hlZCBSVFQgb24gY2xvc2UKCQkwIGNvbm5lY3Rpb25zIHVwZGF0 ZWQgY2FjaGVkIFJUVCB2YXJpYW5jZSBvbiBjbG9zZQoJCTAgY29ubmVjdGlvbnMgdXBkYXRlZCBj YWNoZWQgc3N0aHJlc2ggb24gY2xvc2UKCTAgZW1icnlvbmljIGNvbm5lY3Rpb25zIGRyb3BwZWQK CTgxMCBzZWdtZW50cyB1cGRhdGVkIHJ0dCAob2YgODEwIGF0dGVtcHRzKQoJMCByZXRyYW5zbWl0 IHRpbWVvdXRzCgkJMCBjb25uZWN0aW9ucyBkcm9wcGVkIGJ5IHJleG1pdCB0aW1lb3V0CgkwIHBl cnNpc3QgdGltZW91dHMKCQkwIGNvbm5lY3Rpb25zIGRyb3BwZWQgYnkgcGVyc2lzdCB0aW1lb3V0 CgkwIENvbm5lY3Rpb25zIChmaW5fd2FpdF8yKSBkcm9wcGVkIGJlY2F1c2Ugb2YgdGltZW91dAoJ MCBrZWVwYWxpdmUgdGltZW91dHMKCQkwIGtlZXBhbGl2ZSBwcm9iZXMgc2VudAoJCTAgY29ubmVj dGlvbnMgZHJvcHBlZCBieSBrZWVwYWxpdmUKCTE2MCBjb3JyZWN0IEFDSyBoZWFkZXIgcHJlZGlj dGlvbnMKCTI4NyBjb3JyZWN0IGRhdGEgcGFja2V0IGhlYWRlciBwcmVkaWN0aW9ucwoJMSBzeW5j YWNoZSBlbnRyeSBhZGRlZAoJCTAgcmV0cmFuc21pdHRlZAoJCTAgZHVwc3luCgkJMCBkcm9wcGVk CgkJMSBjb21wbGV0ZWQKCQkwIGJ1Y2tldCBvdmVyZmxvdwoJCTAgY2FjaGUgb3ZlcmZsb3cKCQkw IHJlc2V0CgkJMCBzdGFsZQoJCTAgYWJvcnRlZAoJCTAgYmFkYWNrCgkJMCB1bnJlYWNoCgkJMCB6 b25lIGZhaWx1cmVzCgkxIGNvb2tpZSBzZW50CgkwIGNvb2tpZXMgcmVjZWl2ZWQKCTAgaG9zdGNh Y2hlIGVudHJpZXMgYWRkZWQKCQkwIGJ1Y2tldCBvdmVyZmxvdwoJMCBTQUNLIHJlY292ZXJ5IGVw aXNvZGVzCgkwIHNlZ21lbnQgcmV4bWl0cyBpbiBTQUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkwIGJ5 dGUgcmV4bWl0cyBpbiBTQUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkxNSBTQUNLIG9wdGlvbnMgKFNB Q0sgYmxvY2tzKSByZWNlaXZlZAoJMCBTQUNLIG9wdGlvbnMgKFNBQ0sgYmxvY2tzKSBzZW50Cgkw IFNBQ0sgc2NvcmVib2FyZCBvdmVyZmxvdwoJMCBwYWNrZXRzIHdpdGggRUNOIENFIGJpdCBzZXQK CTAgcGFja2V0cyB3aXRoIEVDTiBFQ1QoMCkgYml0IHNldAoJMCBwYWNrZXRzIHdpdGggRUNOIEVD VCgxKSBiaXQgc2V0CgkwIHN1Y2Nlc3NmdWwgRUNOIGhhbmRzaGFrZXMKCTAgdGltZXMgRUNOIHJl ZHVjZWQgdGhlIGNvbmdlc3Rpb24gd2luZG93CnVkcDoKCTc2IGRhdGFncmFtcyByZWNlaXZlZAoJ MCB3aXRoIGluY29tcGxldGUgaGVhZGVyCgkwIHdpdGggYmFkIGRhdGEgbGVuZ3RoIGZpZWxkCgkw IHdpdGggYmFkIGNoZWNrc3VtCgkwIHdpdGggbm8gY2hlY2tzdW0KCTAgZHJvcHBlZCBkdWUgdG8g bm8gc29ja2V0Cgk2MSBicm9hZGNhc3QvbXVsdGljYXN0IGRhdGFncmFtcyB1bmRlbGl2ZXJlZAoJ MCBkcm9wcGVkIGR1ZSB0byBmdWxsIHNvY2tldCBidWZmZXJzCgkwIG5vdCBmb3IgaGFzaGVkIHBj YgoJMTUgZGVsaXZlcmVkCgkxNSBkYXRhZ3JhbXMgb3V0cHV0CgkwIHRpbWVzIG11bHRpY2FzdCBz b3VyY2UgZmlsdGVyIG1hdGNoZWQKaXA6CgkxMjk4IHRvdGFsIHBhY2tldHMgcmVjZWl2ZWQKCTAg YmFkIGhlYWRlciBjaGVja3N1bXMKCTAgd2l0aCBzaXplIHNtYWxsZXIgdGhhbiBtaW5pbXVtCgkw IHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5ndGgKCTAgd2l0aCBpcCBsZW5ndGggPiBtYXggaXAg cGFja2V0IHNpemUKCTAgd2l0aCBoZWFkZXIgbGVuZ3RoIDwgZGF0YSBzaXplCgkwIHdpdGggZGF0 YSBsZW5ndGggPCBoZWFkZXIgbGVuZ3RoCgkwIHdpdGggYmFkIG9wdGlvbnMKCTAgd2l0aCBpbmNv cnJlY3QgdmVyc2lvbiBudW1iZXIKCTAgZnJhZ21lbnRzIHJlY2VpdmVkCgkwIGZyYWdtZW50cyBk cm9wcGVkIChkdXAgb3Igb3V0IG9mIHNwYWNlKQoJMCBmcmFnbWVudHMgZHJvcHBlZCBhZnRlciB0 aW1lb3V0CgkwIHBhY2tldHMgcmVhc3NlbWJsZWQgb2sKCTEyMDQgcGFja2V0cyBmb3IgdGhpcyBo b3N0Cgk5MCBwYWNrZXRzIGZvciB1bmtub3duL3Vuc3VwcG9ydGVkIHByb3RvY29sCgkwIHBhY2tl dHMgZm9yd2FyZGVkICgwIHBhY2tldHMgZmFzdCBmb3J3YXJkZWQpCgk0IHBhY2tldHMgbm90IGZv cndhcmRhYmxlCgkwIHBhY2tldHMgcmVjZWl2ZWQgZm9yIHVua25vd24gbXVsdGljYXN0IGdyb3Vw CgkwIHJlZGlyZWN0cyBzZW50Cgk5MzEgcGFja2V0cyBzZW50IGZyb20gdGhpcyBob3N0CgkwIHBh Y2tldHMgc2VudCB3aXRoIGZhYnJpY2F0ZWQgaXAgaGVhZGVyCgkwIG91dHB1dCBwYWNrZXRzIGRy b3BwZWQgZHVlIHRvIG5vIGJ1ZnMsIGV0Yy4KCTAgb3V0cHV0IHBhY2tldHMgZGlzY2FyZGVkIGR1 ZSB0byBubyByb3V0ZQoJMCBvdXRwdXQgZGF0YWdyYW1zIGZyYWdtZW50ZWQKCTAgZnJhZ21lbnRz IGNyZWF0ZWQKCTAgZGF0YWdyYW1zIHRoYXQgY2FuJ3QgYmUgZnJhZ21lbnRlZAoJMCB0dW5uZWxp bmcgcGFja2V0cyB0aGF0IGNhbid0IGZpbmQgZ2lmCgkwIGRhdGFncmFtcyB3aXRoIGJhZCBhZGRy ZXNzIGluIGhlYWRlcgppY21wOgoJMCBjYWxscyB0byBpY21wX2Vycm9yCgkwIGVycm9ycyBub3Qg Z2VuZXJhdGVkIGluIHJlc3BvbnNlIHRvIGFuIGljbXAgbWVzc2FnZQoJMCBtZXNzYWdlcyB3aXRo IGJhZCBjb2RlIGZpZWxkcwoJMCBtZXNzYWdlcyBsZXNzIHRoYW4gdGhlIG1pbmltdW0gbGVuZ3Ro CgkwIG1lc3NhZ2VzIHdpdGggYmFkIGNoZWNrc3VtCgkwIG1lc3NhZ2VzIHdpdGggYmFkIGxlbmd0 aAoJMCBtdWx0aWNhc3QgZWNobyByZXF1ZXN0cyBpZ25vcmVkCgkwIG11bHRpY2FzdCB0aW1lc3Rh bXAgcmVxdWVzdHMgaWdub3JlZAoJMCBtZXNzYWdlIHJlc3BvbnNlcyBnZW5lcmF0ZWQKCTAgaW52 YWxpZCByZXR1cm4gYWRkcmVzc2VzCgkwIG5vIHJldHVybiByb3V0ZXMKaWdtcDoKCTcgbWVzc2Fn ZXMgcmVjZWl2ZWQKCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCB0b28gZmV3IGJ5dGVzCgkwIG1l c3NhZ2VzIHJlY2VpdmVkIHdpdGggd3JvbmcgVFRMCgkwIG1lc3NhZ2VzIHJlY2VpdmVkIHdpdGgg YmFkIGNoZWNrc3VtCgk3IFYxL1YyIG1lbWJlcnNoaXAgcXVlcmllcyByZWNlaXZlZAoJMCBWMyBt ZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQKCTAgbWVtYmVyc2hpcCBxdWVyaWVzIHJlY2VpdmVk IHdpdGggaW52YWxpZCBmaWVsZChzKQoJNyBnZW5lcmFsIHF1ZXJpZXMgcmVjZWl2ZWQKCTAgZ3Jv dXAgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cC1zb3VyY2UgcXVlcmllcyByZWNlaXZlZAoJMCBn cm91cC1zb3VyY2UgcXVlcmllcyBkcm9wcGVkCgkwIG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZl ZAoJMCBtZW1iZXJzaGlwIHJlcG9ydHMgcmVjZWl2ZWQgd2l0aCBpbnZhbGlkIGZpZWxkKHMpCgkw IG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZlZCBmb3IgZ3JvdXBzIHRvIHdoaWNoIHdlIGJlbG9u ZwoJMCBWMyByZXBvcnRzIHJlY2VpdmVkIHdpdGhvdXQgUm91dGVyIEFsZXJ0CgkwIG1lbWJlcnNo aXAgcmVwb3J0cyBzZW50CmFycDoKCTIgQVJQIHJlcXVlc3RzIHNlbnQKCTAgQVJQIHJlcGxpZXMg c2VudAoJOTAgQVJQIHJlcXVlc3RzIHJlY2VpdmVkCgk4MyBBUlAgcmVwbGllcyByZWNlaXZlZAoJ MTczIEFSUCBwYWNrZXRzIHJlY2VpdmVkCgkwIHRvdGFsIHBhY2tldHMgZHJvcHBlZCBkdWUgdG8g bm8gQVJQIGVudHJ5CgkwIEFSUCBlbnRyeXMgdGltZWQgb3V0CgkwIER1cGxpY2F0ZSBJUHMgc2Vl bgppcDY6CgkwIHRvdGFsIHBhY2tldHMgcmVjZWl2ZWQKCTAgd2l0aCBzaXplIHNtYWxsZXIgdGhh biBtaW5pbXVtCgkwIHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5ndGgKCTAgd2l0aCBiYWQgb3B0 aW9ucwoJMCB3aXRoIGluY29ycmVjdCB2ZXJzaW9uIG51bWJlcgoJMCBmcmFnbWVudHMgcmVjZWl2 ZWQKCTAgZnJhZ21lbnRzIGRyb3BwZWQgKGR1cCBvciBvdXQgb2Ygc3BhY2UpCgkwIGZyYWdtZW50 cyBkcm9wcGVkIGFmdGVyIHRpbWVvdXQKCTAgZnJhZ21lbnRzIHRoYXQgZXhjZWVkZWQgbGltaXQK CTAgcGFja2V0cyByZWFzc2VtYmxlZCBvawoJMCBwYWNrZXRzIGZvciB0aGlzIGhvc3QKCTAgcGFj a2V0cyBmb3J3YXJkZWQKCTAgcGFja2V0cyBub3QgZm9yd2FyZGFibGUKCTAgcmVkaXJlY3RzIHNl bnQKCTAgcGFja2V0cyBzZW50IGZyb20gdGhpcyBob3N0CgkwIHBhY2tldHMgc2VudCB3aXRoIGZh YnJpY2F0ZWQgaXAgaGVhZGVyCgkwIG91dHB1dCBwYWNrZXRzIGRyb3BwZWQgZHVlIHRvIG5vIGJ1 ZnMsIGV0Yy4KCTAgb3V0cHV0IHBhY2tldHMgZGlzY2FyZGVkIGR1ZSB0byBubyByb3V0ZQoJMCBv dXRwdXQgZGF0YWdyYW1zIGZyYWdtZW50ZWQKCTAgZnJhZ21lbnRzIGNyZWF0ZWQKCTAgZGF0YWdy YW1zIHRoYXQgY2FuJ3QgYmUgZnJhZ21lbnRlZAoJMCBwYWNrZXRzIHRoYXQgdmlvbGF0ZWQgc2Nv cGUgcnVsZXMKCTAgbXVsdGljYXN0IHBhY2tldHMgd2hpY2ggd2UgZG9uJ3Qgam9pbgoJTWJ1ZiBz dGF0aXN0aWNzOgoJCTQ0IG9uZSBtYnVmCgkJdHdvIG9yIG1vcmUgbWJ1ZjoKCQkJYmNlMD0gODgK CQkwIG9uZSBleHQgbWJ1ZgoJCTAgdHdvIG9yIG1vcmUgZXh0IG1idWYKCTAgcGFja2V0cyB3aG9z ZSBoZWFkZXJzIGFyZSBub3QgY29udGlndW91cwoJMCB0dW5uZWxpbmcgcGFja2V0cyB0aGF0IGNh bid0IGZpbmQgZ2lmCgkwIHBhY2tldHMgZGlzY2FyZGVkIGJlY2F1c2Ugb2YgdG9vIG1hbnkgaGVh ZGVycwoJMCBmYWlsdXJlcyBvZiBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24KCVNvdXJjZSBhZGRy ZXNzZXMgc2VsZWN0aW9uIHJ1bGUgYXBwbGllZDoKaWNtcDY6CgkwIGNhbGxzIHRvIGljbXA2X2Vy cm9yCgkwIGVycm9ycyBub3QgZ2VuZXJhdGVkIGluIHJlc3BvbnNlIHRvIGFuIGljbXA2IG1lc3Nh Z2UKCTAgZXJyb3JzIG5vdCBnZW5lcmF0ZWQgYmVjYXVzZSBvZiByYXRlIGxpbWl0YXRpb24KCTAg bWVzc2FnZXMgd2l0aCBiYWQgY29kZSBmaWVsZHMKCTAgbWVzc2FnZXMgPCBtaW5pbXVtIGxlbmd0 aAoJMCBiYWQgY2hlY2tzdW1zCgkwIG1lc3NhZ2VzIHdpdGggYmFkIGxlbmd0aAoJSGlzdG9ncmFt IG9mIGVycm9yIG1lc3NhZ2VzIHRvIGJlIGdlbmVyYXRlZDoKCQkwIG5vIHJvdXRlCgkJMCBhZG1p bmlzdHJhdGl2ZWx5IHByb2hpYml0ZWQKCQkwIGJleW9uZCBzY29wZQoJCTAgYWRkcmVzcyB1bnJl YWNoYWJsZQoJCTAgcG9ydCB1bnJlYWNoYWJsZQoJCTAgcGFja2V0IHRvbyBiaWcKCQkwIHRpbWUg ZXhjZWVkIHRyYW5zaXQKCQkwIHRpbWUgZXhjZWVkIHJlYXNzZW1ibHkKCQkwIGVycm9uZW91cyBo ZWFkZXIgZmllbGQKCQkwIHVucmVjb2duaXplZCBuZXh0IGhlYWRlcgoJCTAgdW5yZWNvZ25pemVk IG9wdGlvbgoJCTAgcmVkaXJlY3QKCQkwIHVua25vd24KCTAgbWVzc2FnZSByZXNwb25zZXMgZ2Vu ZXJhdGVkCgkwIG1lc3NhZ2VzIHdpdGggdG9vIG1hbnkgTkQgb3B0aW9ucwoJMCBtZXNzYWdlcyB3 aXRoIGJhZCBORCBvcHRpb25zCgkwIGJhZCBuZWlnaGJvciBzb2xpY2l0YXRpb24gbWVzc2FnZXMK CTAgYmFkIG5laWdoYm9yIGFkdmVydGlzZW1lbnQgbWVzc2FnZXMKCTAgYmFkIHJvdXRlciBzb2xp Y2l0YXRpb24gbWVzc2FnZXMKCTAgYmFkIHJvdXRlciBhZHZlcnRpc2VtZW50IG1lc3NhZ2VzCgkw IGJhZCByZWRpcmVjdCBtZXNzYWdlcwoJMCBwYXRoIE1UVSBjaGFuZ2VzCnJpcDY6CgkwIG1lc3Nh Z2VzIHJlY2VpdmVkCgkwIGNoZWNrc3VtIGNhbGN1bGF0aW9ucyBvbiBpbmJvdW5kCgkwIG1lc3Nh Z2VzIHdpdGggYmFkIGNoZWNrc3VtCgkwIG1lc3NhZ2VzIGRyb3BwZWQgZHVlIHRvIG5vIHNvY2tl dAoJMCBtdWx0aWNhc3QgbWVzc2FnZXMgZHJvcHBlZCBkdWUgdG8gbm8gc29ja2V0CgkwIG1lc3Nh Z2VzIGRyb3BwZWQgZHVlIHRvIGZ1bGwgc29ja2V0IGJ1ZmZlcnMKCTAgZGVsaXZlcmVkCgkwIGRh dGFncmFtcyBvdXRwdXQKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1tCgoyNTUxLzEwODMvMzYz NCBtYnVmcyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwpCjIwMzYvNDY2LzI1MDIvMjUxODYw IG1idWYgY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMjA0MC80NjUg bWJ1ZitjbHVzdGVycyBvdXQgb2YgcGFja2V0IHNlY29uZGFyeSB6b25lIGluIHVzZSAoY3VycmVu dC9jYWNoZSkKMC8zLzMvMTI1OTI5IDRrIChwYWdlIHNpemUpIGp1bWJvIGNsdXN0ZXJzIGluIHVz ZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjAvMC8wLzExMTkzNiA5ayBqdW1ibyBjbHVzdGVy cyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQowLzAvMC84Mzk1MiAxNmsganVtYm8g Y2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKNDcwOUsvMTIxNEsvNTky NEsgYnl0ZXMgYWxsb2NhdGVkIHRvIG5ldHdvcmsgKGN1cnJlbnQvY2FjaGUvdG90YWwpCjAvMjUw MS8xIHJlcXVlc3RzIGZvciBtYnVmcyBkZW5pZWQgKG1idWZzL2NsdXN0ZXJzL21idWYrY2x1c3Rl cnMpCjAvMC8wIHJlcXVlc3RzIGZvciBtYnVmcyBkZWxheWVkIChtYnVmcy9jbHVzdGVycy9tYnVm K2NsdXN0ZXJzKQowLzAvMCByZXF1ZXN0cyBmb3IganVtYm8gY2x1c3RlcnMgZGVsYXllZCAoNGsv OWsvMTZrKQozLzAvMCByZXF1ZXN0cyBmb3IganVtYm8gY2x1c3RlcnMgZGVuaWVkICg0ay85ay8x NmspCjAgcmVxdWVzdHMgZm9yIHNmYnVmcyBkZW5pZWQKMCByZXF1ZXN0cyBmb3Igc2ZidWZzIGRl bGF5ZWQKMCByZXF1ZXN0cyBmb3IgSS9PIGluaXRpYXRlZCBieSBzZW5kZmlsZQoKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCm5ldHN0YXQgLWlkVwoKTmFtZSAgICAgIE10dSBOZXR3b3JrICAgICAgIEFkZHJlc3Mg ICAgICAgICAgICAgIElwa3RzIEllcnJzIElkcm9wICAgIE9wa3RzIE9lcnJzICBDb2xsIERyb3AK YmNlMCAgICAgMTUwMCA8TGluayMxPiAgICAgIDc4OjJiOmNiOjVlOjQxOmFlICAgICAyMDUzICAg ICAwICAgICAwICAgICAgOTM0ICAgICAwICAgICAwICAgIDAgCmJjZTAgICAgIDE1MDAgMTM1LjI0 LjE5Mi4wICBmcmVlYnNkMTBfc3RvY2subCAgICAgMTE5MiAgICAgLSAgICAgLSAgICAgIDkzMSAg ICAgLSAgICAgLSAgICAtIApiY2UxKiAgICAxNTAwIDxMaW5rIzI+ICAgICAgNzg6MmI6Y2I6NWU6 NDE6YWYgICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAKbG8w ICAgICAxNjM4NCA8TGluayMzPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAw ICAgICAwICAgICAgICAwICAgICAwICAgICAwICAgIDAgCmxvMCAgICAgMTYzODQgbG9jYWxob3N0 ICAgICA6OjEgICAgICAgICAgICAgICAgICAgICAgMCAgICAgLSAgICAgLSAgICAgICAgMCAgICAg LSAgICAgLSAgICAtIApsbzAgICAgIDE2Mzg0IGZlODA6OjElbG8wICAgZmU4MDo6MSAgICAgICAg ICAgICAgICAgIDAgICAgIC0gICAgIC0gICAgICAgIDAgICAgIC0gICAgIC0gICAgLSAKbG8wICAg ICAxNjM4NCB5b3VyLW5ldCAgICAgIGxvY2FsaG9zdCAgICAgICAgICAgICAgICAwICAgICAtICAg ICAtICAgICAgICAwICAgICAtICAgICAtICAgIC0gCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAt YW5yCgpSb3V0aW5nIHRhYmxlcwoKSW50ZXJuZXQ6CkRlc3RpbmF0aW9uICAgICAgICBHYXRld2F5 ICAgICAgICAgICAgRmxhZ3MgICAgUmVmcyAgICAgIFVzZSAgTmV0aWYgRXhwaXJlCmRlZmF1bHQg ICAgICAgICAgICAxMzUuMjQuMTkyLjEgICAgICAgVUdTICAgICAgICAgMCAgICAgIDkzMSAgIGJj ZTAKMTI3LjAuMC4xICAgICAgICAgIGxpbmsjMyAgICAgICAgICAgICBVSCAgICAgICAgICAwICAg ICAgICAwICAgIGxvMAoxMzUuMjQuMTkyLjAvMjQgICAgbGluayMxICAgICAgICAgICAgIFUgICAg ICAgICAgIDAgICAgICAgIDAgICBiY2UwCjEzNS4yNC4xOTIuMTEyICAgICBsaW5rIzEgICAgICAg ICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKCkludGVybmV0NjoKRGVzdGluYXRp b24gICAgICAgICAgICAgICAgICAgICAgIEdhdGV3YXkgICAgICAgICAgICAgICAgICAgICAgIEZs YWdzICAgICAgTmV0aWYgRXhwaXJlCjo6Lzk2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6 OjEgICAgICAgICAgICAgICAgICAgICAgICAgICBVR1JTICAgICAgICBsbzAKOjoxICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGxpbmsjMyAgICAgICAgICAgICAgICAgICAgICAgIFVIICAg ICAgICAgIGxvMAo6OmZmZmY6MC4wLjAuMC85NiAgICAgICAgICAgICAgICAgOjoxICAgICAgICAg ICAgICAgICAgICAgICAgICAgVUdSUyAgICAgICAgbG8wCmZlODA6Oi8xMCAgICAgICAgICAgICAg ICAgICAgICAgICA6OjEgICAgICAgICAgICAgICAgICAgICAgICAgICBVR1JTICAgICAgICBsbzAK ZmU4MDo6JWxvMC82NCAgICAgICAgICAgICAgICAgICAgIGxpbmsjMyAgICAgICAgICAgICAgICAg ICAgICAgIFUgICAgICAgICAgIGxvMApmZTgwOjoxJWxvMCAgICAgICAgICAgICAgICAgICAgICAg bGluayMzICAgICAgICAgICAgICAgICAgICAgICAgVUhTICAgICAgICAgbG8wCmZmMDE6OiVsbzAv MzIgICAgICAgICAgICAgICAgICAgICA6OjEgICAgICAgICAgICAgICAgICAgICAgICAgICBVICAg ICAgICAgICBsbzAKZmYwMjo6LzE2ICAgICAgICAgICAgICAgICAgICAgICAgIDo6MSAgICAgICAg ICAgICAgICAgICAgICAgICAgIFVHUlMgICAgICAgIGxvMApmZjAyOjolbG8wLzMyICAgICAgICAg ICAgICAgICAgICAgOjoxICAgICAgICAgICAgICAgICAgICAgICAgICAgVSAgICAgICAgICAgbG8w CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtYW5BCgpBY3RpdmUgSW50ZXJuZXQgY29ubmVjdGlv bnMgKGluY2x1ZGluZyBzZXJ2ZXJzKQpUY3BjYiAgICAgICAgICAgIFByb3RvIFJlY3YtUSBTZW5k LVEgTG9jYWwgQWRkcmVzcyAgICAgIEZvcmVpZ24gQWRkcmVzcyAgICAoc3RhdGUpCmZmZmZmODAw OTk0Y2UwMDAgdGNwNCAgICAgICAwICAgICAgMCAxMzUuMjQuMTkyLjExMi4yMiAgMTM1LjM2LjEy Ny4xNjkuNTA2IEVTVEFCTElTSEVECmZmZmZmODAwOTk0ZGYwMDAgdGNwNCAgICAgICAwICAgICAg MCAxMjcuMC4wLjEuMjUgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZjgwMDk5 NGNlNDAwIHRjcDQgICAgICAgMCAgICAgIDAgKi4yMiAgICAgICAgICAgICAgICouKiAgICAgICAg ICAgICAgICBMSVNURU4KZmZmZmY4MDA5OTRjZTgwMCB0Y3A2ICAgICAgIDAgICAgICAwICouMjIg ICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmODAwOTkwZTU2MjAg dWRwNCAgICAgICAwICAgICAgMCAqLjUxNCAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAg IApmZmZmZjgwMDk5MGU1N2E4IHVkcDYgICAgICAgMCAgICAgIDAgKi41MTQgICAgICAgICAgICAg ICouKiAgICAgICAgICAgICAgICAKQWN0aXZlIFVOSVggZG9tYWluIHNvY2tldHMKQWRkcmVzcyAg VHlwZSAgIFJlY3YtUSBTZW5kLVEgICAgSW5vZGUgICAgIENvbm4gICAgIFJlZnMgIE5leHRyZWYg QWRkcgpmZmZmZjgwMDk5MGRmYjQwIHN0cmVhbSAgICAgIDAgICAgICAwIGZmZmZmODAwMTA5Nzgx ZDggICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vZGV2ZC5waXBlCmZmZmZmODAw OTkxMjAxZTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmY4MDA5OTBlOTY5MCAg ICAgICAgMCBmZmZmZjgwMDk5MTIwMmQwCmZmZmZmODAwOTkxMjAyZDAgZGdyYW0gICAgICAgMCAg ICAgIDAgICAgICAgIDAgZmZmZmY4MDA5OTBlOTY5MCAgICAgICAgMCBmZmZmZjgwMDk5MTZhZTEw CmZmZmZmODAwOTkxNmFlMTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmY4MDA5 OTBlOTY5MCAgICAgICAgMCBmZmZmZjgwMDk5MTIwNGIwCmZmZmZmODAwOTkxMjA0YjAgZGdyYW0g ICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmY4MDA5OTBlOTY5MCAgICAgICAgMCBmZmZmZjgw MDk5MTZiMDAwCmZmZmZmODAwOTkxNmIwMDAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAg ZmZmZmY4MDA5OTBlOTY5MCAgICAgICAgMCBmZmZmZjgwMDk5MTIwNWEwCmZmZmZmODAwOTkxNmIy ZDAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmY4MDA5OTBlOTc4MCAgICAgICAg MCAgICAgICAgMApmZmZmZjgwMDk5MTIwNWEwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAw IGZmZmZmODAwOTkwZTk2OTAgICAgICAgIDAgICAgICAgIDAKZmZmZmY4MDA5OTBlOTY5MCBkZ3Jh bSAgICAgICAwICAgICAgMCBmZmZmZjgwMDEwOTYwNzYwICAgICAgICAwIGZmZmZmODAwOTkxMjAx ZTAgICAgICAgIDAgL3Zhci9ydW4vbG9ncHJpdgpmZmZmZjgwMDk5MGU5NzgwIGRncmFtICAgICAg IDAgICAgICAwIGZmZmZmODAwMTA5NjA5MzggICAgICAgIDAgZmZmZmY4MDA5OTE2YjJkMCAgICAg ICAgMCAvdmFyL3J1bi9sb2cKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1hTAoKQ3VycmVudCBs aXN0ZW4gcXVldWUgc2l6ZXMgKHFsZW4vaW5jcWxlbi9tYXhxbGVuKQpQcm90byBMaXN0ZW4gICAg ICAgICBMb2NhbCBBZGRyZXNzICAgICAgICAgCnRjcDQgIDAvMC8xMCAgICAgICAgIGxvY2FsaG9z dC5zbXRwICAgICAgICAgCnRjcDQgIDAvMC8xMjggICAgICAgICouc3NoICAgICAgICAgICAgICAg ICAgCnRjcDYgIDAvMC8xMjggICAgICAgICouc3NoICAgICAgICAgICAgICAgICAgCnVuaXggIDAv MC80ICAgICAgICAgIC92YXIvcnVuL2RldmQucGlwZQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmZzdGF0Cgpm c3RhdDogY2FuJ3QgcmVhZCBmaWxlIDEgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0 IHJlYWQgZmlsZSAyIGF0IDB4NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUg MSBhdCAweDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0MDAw MDAwMDAxZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSA0IGF0IDB4NzgwMDAwZmZmZgpmc3Rh dDogY2FuJ3QgcmVhZCBmaWxlIDcgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJl YWQgZmlsZSA4IGF0IDB4NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMSBh dCAweDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0MDAwMDAw MDAxZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSA0IGF0IDB4NzgwMDAwZmZmZgpmc3RhdDog Y2FuJ3QgcmVhZCBmaWxlIDcgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQg ZmlsZSA4IGF0IDB4NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMSBhdCAw eDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0MDAwMDAwMDAx ZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSA0IGF0IDB4NzgwMDAwZmZmZgpmc3RhdDogY2Fu J3QgcmVhZCBmaWxlIDcgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmls ZSA4IGF0IDB4NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMTAgYXQgMHg3 ODAwMDBmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMSBhdCAweDIwMDAwN2ZmZmZmZmZmZgpm c3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0YXQ6IGNhbid0 IHJlYWQgZmlsZSA0IGF0IDB4NzgwMDAwZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDcgYXQg MHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSA4IGF0IDB4NDAwMDAwMDAw MWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMTAgYXQgMHg3ODAwMDBmZmZmCmZzdGF0OiBj YW4ndCByZWFkIGZpbGUgMSBhdCAweDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBm aWxlIDIgYXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSA0IGF0IDB4 NzgwMDAwZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDcgYXQgMHgyMDAwMDdmZmZmZmZmZmYK ZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSA4IGF0IDB4NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4n dCByZWFkIGZpbGUgMSBhdCAweDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxl IDIgYXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAxIGF0IDB4MjAw MDA3ZmZmZmZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMiBhdCAweDQwMDAwMDAwMDFmZmZm Zgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDEgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNh bid0IHJlYWQgZmlsZSAyIGF0IDB4NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZp bGUgMSBhdCAweDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0 MDAwMDAwMDAxZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAxIGF0IDB4MjAwMDA3ZmZmZmZm ZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMiBhdCAweDQwMDAwMDAwMDFmZmZmZgpmc3RhdDog Y2FuJ3QgcmVhZCBmaWxlIDEgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQg ZmlsZSAyIGF0IDB4NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMSBhdCAw eDIwMDAwN2ZmZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0MDAwMDAwMDAx ZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAxIGF0IDB4MjAwMDA3ZmZmZmZmZmZmCmZzdGF0 OiBjYW4ndCByZWFkIGZpbGUgMiBhdCAweDQwMDAwMDAwMDFmZmZmZgpmc3RhdDogY2FuJ3QgcmVh ZCBmaWxlIDEgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAyIGF0 IDB4NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMSBhdCAweDIwMDAwN2Zm ZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0 YXQ6IGNhbid0IHJlYWQgZmlsZSA0IGF0IDB4NzgwMDAwZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBm aWxlIDEgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAyIGF0IDB4 NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgNCBhdCAweDc4MDAwMGZmZmYK ZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAxIGF0IDB4MjAwMDA3ZmZmZmZmZmZmCmZzdGF0OiBjYW4n dCByZWFkIGZpbGUgMiBhdCAweDQwMDAwMDAwMDFmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxl IDQgYXQgMHg3ODAwMDBmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMSBhdCAweDIwMDAwN2Zm ZmZmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0 YXQ6IGNhbid0IHJlYWQgZmlsZSA0IGF0IDB4NzgwMDAwZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBm aWxlIDcgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSA4IGF0IDB4 NDAwMDAwMDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMTAgYXQgMHg3ODAwMDBmZmZm CmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMTMgYXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNh bid0IHJlYWQgZmlsZSAxNCBhdCAweDQwMDAwMDAwMDFmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBm aWxlIDE2IGF0IDB4NzgwMDAwZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDE5IGF0IDB4MjAw MDA3ZmZmZmZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMSBhdCAweDIwMDAwN2ZmZmZmZmZm Zgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0MDAwMDAwMDAxZmZmZmYKZnN0YXQ6IGNh bid0IHJlYWQgZmlsZSA0IGF0IDB4NzgwMDAwZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDEg YXQgMHgyMDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAyIGF0IDB4NDAwMDAw MDAwMWZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgNCBhdCAweDc4MDAwMGZmZmYKZnN0YXQ6 IGNhbid0IHJlYWQgZmlsZSAxIGF0IDB4MjAwMDA3ZmZmZmZmZmZmCmZzdGF0OiBjYW4ndCByZWFk IGZpbGUgMiBhdCAweDQwMDAwMDAwMDFmZmZmZgpmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDQgYXQg MHg3ODAwMDBmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgMSBhdCAweDIwMDAwMDAwMDAwMDAw MApmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDIgYXQgMHg0MDAwMDAwMDAwMDAwMDAKZnN0YXQ6IGNh bid0IHJlYWQgZmlsZSA3IGF0IDB4MjAwMDAwMDAwMDAwMDAyCmZzdGF0OiBjYW4ndCByZWFkIGZp bGUgOCBhdCAweDQwMDAwMDAwMDAwMDAwMApmc3RhdDogY2FuJ3QgcmVhZCBmaWxlIDEgYXQgMHgy MDAwMDdmZmZmZmZmZmYKZnN0YXQ6IGNhbid0IHJlYWQgZmlsZSAyIGF0IDB4NDAwMDAwMDAwMWZm ZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUgNCBhdCAweDc4MDAwMGZmZmYKZnN0YXQ6IGNhbid0 IHJlYWQgZmlsZSA3IGF0IDB4MjAwMDA3ZmZmZmZmZmZmCmZzdGF0OiBjYW4ndCByZWFkIGZpbGUg OCBhdCAweDQwMDAwMDAwMDFmZmZmZgpVU0VSICAgICBDTUQgICAgICAgICAgUElEICAgRkQgTU9V TlQgICAgICBJTlVNIE1PREUgICAgICAgICBTWnxEViBSL1cKcm9vdCAgICAga2xkbG9hZCAgICAg MTQwNiByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAg a2xkbG9hZCAgICAgMTQwNiAgIHdkIC8gICAgICAgIDI3NzcwMTEyIGRyd3hyLXhyLXggICAgIDUx MiAgcgpyb290ICAgICBrbGRsb2FkICAgICAxNDA2IHRleHQgLyAgICAgICAgNzIyMzg4IC1yLXhy LXhyLXggICAgODM4NCAgcgpyb290ICAgICBrbGRsb2FkICAgICAxNDA2IGN0dHkgL2RldiAgICAg ICAgMTQ5IGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBrbGRsb2FkICAgICAxNDA2ICAg IDAgL2RldiAgICAgICAgMTQ5IGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjdSAgICAg ICAgICAxMzc0IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290 ICAgICBjdSAgICAgICAgICAxMzc0ICAgd2QgLyAgICAgICAgNjAzNTI1MTIgZHJ3eHIteHIteCAg ICAgNTEyICByCnJvb3QgICAgIGN1ICAgICAgICAgIDEzNzQgdGV4dCAvICAgICAgICAyNjcyNTMx MyAtci14ci14ci14ICAgNjI3NTIgIHIKcm9vdCAgICAgY3UgICAgICAgICAgMTM3NCBjdHR5IC9k ZXYgICAgICAgICA1MCBjcnctLS0tLS0tICAgdHR5djMgcncKcm9vdCAgICAgY3UgICAgICAgICAg MTM3NCAgICAwIC9kZXYgICAgICAgICA1MCBjcnctLS0tLS0tICAgdHR5djMgcncKcm9vdCAgICAg Y3UgICAgICAgICAgMTM3NCAgICA2IC9kZXYgICAgICAgICA1MCBjcnctLS0tLS0tICAgdHR5djMg cncKcm9vdCAgICAgY3UgICAgICAgICAgMTM3MyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgY3UgICAgICAgICAgMTM3MyAgIHdkIC8gICAgICAgIDYw MzUyNTEyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBjdSAgICAgICAgICAxMzczIHRl eHQgLyAgICAgICAgMjY3MjUzMTMgLXIteHIteHIteCAgIDYyNzUyICByCnJvb3QgICAgIGN1ICAg ICAgICAgIDEzNzMgY3R0eSAvZGV2ICAgICAgICAgNTAgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJv b3QgICAgIGN1ICAgICAgICAgIDEzNzMgICAgMCAvZGV2ICAgICAgICAgNTAgY3J3LS0tLS0tLSAg IHR0eXYzIHJ3CnJvb3QgICAgIGN1ICAgICAgICAgIDEzNzMgICAgNiAvZGV2ICAgICAgICAgNTAg Y3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJvb3QgICAgIHNoICAgICAgICAgIDEzNzIgcm9vdCAvICAg ICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIHNoICAgICAgICAgIDEz NzIgICB3ZCAvICAgICAgICA2MDM1MjUxMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAg c2ggICAgICAgICAgMTM3MiB0ZXh0IC8gICAgICAgIDEwNTkzNzk1IC1yLXhyLXhyLXggIDE0MTY5 NiAgcgpyb290ICAgICBzaCAgICAgICAgICAxMzcyIGN0dHkgL2RldiAgICAgICAgIDUwIGNydy0t LS0tLS0gICB0dHl2MyBydwpyb290ICAgICBzaCAgICAgICAgICAxMzcyICAgIDAgL2RldiAgICAg ICAgIDUwIGNydy0tLS0tLS0gICB0dHl2MyBydwpyb290ICAgICBzaCAgICAgICAgICAxMzcyICAg IDYgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2MyBydwpyb290ICAgICBjc2ggICAg ICAgICAxMzY5IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290 ICAgICBjc2ggICAgICAgICAxMzY5ICAgd2QgLyAgICAgICAgNjAzNTI1MTIgZHJ3eHIteHIteCAg ICAgNTEyICByCnJvb3QgICAgIGNzaCAgICAgICAgIDEzNjkgdGV4dCAvICAgICAgICAxMDU5Mzc5 MyAtci14ci14ci14ICAzNzQxMjAgIHIKcm9vdCAgICAgY3NoICAgICAgICAgMTM2OSBjdHR5IC9k ZXYgICAgICAgICA1MCBjcnctLS0tLS0tICAgdHR5djMgcncKcm9vdCAgICAgc2ggICAgICAgICAg MTM2MSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAg c2ggICAgICAgICAgMTM2MSAgIHdkIC8gICAgICAgIDMzMDY1NDk0IGRyd3hyLXhyLXggICAgIDUx MiAgcgpyb290ICAgICBzaCAgICAgICAgICAxMzYxIHRleHQgLyAgICAgICAgMTA1OTM3OTUgLXIt eHIteHIteCAgMTQxNjk2ICByCnJvb3QgICAgIHNoICAgICAgICAgIDEzNjEgY3R0eSAvZGV2ICAg ICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXYyIHJ3CnJvb3QgICAgIHNoICAgICAgICAgIDEzNjEg ICAgMCAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXYyIHJ3CnJvb3QgICAgIHNoICAg ICAgICAgIDEzNjEgICAgNiAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXYyIHJ3CnJv b3QgICAgIGNzaCAgICAgICAgIDEzNTggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAxMDI0ICByCnJvb3QgICAgIGNzaCAgICAgICAgIDEzNTggICB3ZCAvICAgICAgICAzMzA2NTQ5 NCBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgY3NoICAgICAgICAgMTM1OCB0ZXh0IC8g ICAgICAgIDEwNTkzNzkzIC1yLXhyLXhyLXggIDM3NDEyMCAgcgpyb290ICAgICBjc2ggICAgICAg ICAxMzU4IGN0dHkgL2RldiAgICAgICAgIDQ5IGNydy0tLS0tLS0gICB0dHl2MiBydwpyb290ICAg ICBjc2ggICAgICAgICAxMzU2IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAy NCAgcgpyb290ICAgICBjc2ggICAgICAgICAxMzU2ICAgd2QgLyAgICAgICAgMzMwNjU0ODggZHJ3 eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIGNzaCAgICAgICAgIDEzNTYgdGV4dCAvICAgICAg ICAxMDU5Mzc5MyAtci14ci14ci14ICAzNzQxMjAgIHIKcm9vdCAgICAgY3NoICAgICAgICAgMTM1 NiBjdHR5IC9kZXYgICAgICAgICA0OCBjcnctLS0tLS0tICAgdHR5djEgcncKcm9vdCAgICAgY3No ICAgICAgICAgMTE5OCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIK cm9vdCAgICAgY3NoICAgICAgICAgMTE5OCAgIHdkIC8gICAgICAgIDYwMzUyNTEyIGRyd3hyLXhy LXggICAgIDUxMiAgcgpyb290ICAgICBjc2ggICAgICAgICAxMTk4IHRleHQgLyAgICAgICAgMTA1 OTM3OTMgLXIteHIteHIteCAgMzc0MTIwICByCnJvb3QgICAgIGNzaCAgICAgICAgIDExOTggY3R0 eSAvZGV2ICAgICAgICAgNDcgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGNzaCAgICAg ICAgIDExOTYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3Qg ICAgIGNzaCAgICAgICAgIDExOTYgICB3ZCAvICAgICAgICAyNzc3MDExMiBkcnd4ci14ci14ICAg ICA1MTIgIHIKcm9vdCAgICAgY3NoICAgICAgICAgMTE5NiB0ZXh0IC8gICAgICAgIDEwNTkzNzkz IC1yLXhyLXhyLXggIDM3NDEyMCAgcgpyb290ICAgICBjc2ggICAgICAgICAxMTk2IGN0dHkgL2Rl diAgICAgICAgMTQ5IGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBzc2hkICAgICAgICAx MTkzIHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBz c2hkICAgICAgICAxMTkzICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAg cgpyb290ICAgICBzc2hkICAgICAgICAxMTkzIHRleHQgLyAgICAgICAgMjY3Mjg0MDAgLXIteHIt eHIteCAgMjkyMDE2ICByCnJvb3QgICAgIHNzaGQgICAgICAgIDExOTMgICAgMCAvZGV2ICAgICAg ICAgIDkgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHNzaGQgICAgICAgIDExOTMgICAg NiAvZGV2ICAgICAgICAgIDkgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGdldHR5ICAg ICAgIDExODkgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3Qg ICAgIGdldHR5ICAgICAgIDExODkgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAx MDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDExODkgdGV4dCAvICAgICAgICAyNjcyODUxOCAt ci14ci14ci14ICAgMjc5NzYgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTE4OSBjdHR5IC9kZXYg ICAgICAgICA1NCBjcnctLS0tLS0tICAgdHR5djcgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTE4 OSAgICAwIC9kZXYgICAgICAgICA1NCBjcnctLS0tLS0tICAgdHR5djcgcncKcm9vdCAgICAgZ2V0 dHkgICAgICAgMTE4OCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIK cm9vdCAgICAgZ2V0dHkgICAgICAgMTE4OCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgIDEwMjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTE4OCB0ZXh0IC8gICAgICAgIDI2NzI4 NTE4IC1yLXhyLXhyLXggICAyNzk3NiAgcgpyb290ICAgICBnZXR0eSAgICAgICAxMTg4IGN0dHkg L2RldiAgICAgICAgIDUzIGNydy0tLS0tLS0gICB0dHl2NiBydwpyb290ICAgICBnZXR0eSAgICAg ICAxMTg4ICAgIDAgL2RldiAgICAgICAgIDUzIGNydy0tLS0tLS0gICB0dHl2NiBydwpyb290ICAg ICBnZXR0eSAgICAgICAxMTg3IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAy NCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxMTg3ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hy LXhyLXggICAgMTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxMTg3IHRleHQgLyAgICAgICAg MjY3Mjg1MTggLXIteHIteHIteCAgIDI3OTc2ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDExODcg Y3R0eSAvZGV2ICAgICAgICAgNTIgY3J3LS0tLS0tLSAgIHR0eXY1IHJ3CnJvb3QgICAgIGdldHR5 ICAgICAgIDExODcgICAgMCAvZGV2ICAgICAgICAgNTIgY3J3LS0tLS0tLSAgIHR0eXY1IHJ3CnJv b3QgICAgIGdldHR5ICAgICAgIDExODYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAxMDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDExODYgICB3ZCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDExODYgdGV4dCAvICAg ICAgICAyNjcyODUxOCAtci14ci14ci14ICAgMjc5NzYgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAg MTE4NiBjdHR5IC9kZXYgICAgICAgICA1MSBjcnctLS0tLS0tICAgdHR5djQgcncKcm9vdCAgICAg Z2V0dHkgICAgICAgMTE4NiAgICAwIC9kZXYgICAgICAgICA1MSBjcnctLS0tLS0tICAgdHR5djQg cncKcm9vdCAgICAgbG9naW4gICAgICAgMTE4NSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgbG9naW4gICAgICAgMTE4NSAgIHdkIC8gICAgICAgIDYw MzUyNTEyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBsb2dpbiAgICAgICAxMTg1IHRl eHQgLyAgICAgICAgMjY3MjUzNzkgLXItc3IteHIteCAgIDI0NzUyICByCnJvb3QgICAgIGxvZ2lu ICAgICAgIDExODUgY3R0eSAvZGV2ICAgICAgICAgNTAgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJv b3QgICAgIGxvZ2luICAgICAgIDExODUgICAgMCAvZGV2ICAgICAgICAgNTAgY3J3LS0tLS0tLSAg IHR0eXYzIHJ3CnJvb3QgICAgIGxvZ2luICAgICAgIDExODQgcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGxvZ2luICAgICAgIDExODQgICB3ZCAvICAg ICAgICA2MDM1MjUxMiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgbG9naW4gICAgICAg MTE4NCB0ZXh0IC8gICAgICAgIDI2NzI1Mzc5IC1yLXNyLXhyLXggICAyNDc1MiAgcgpyb290ICAg ICBsb2dpbiAgICAgICAxMTg0IGN0dHkgL2RldiAgICAgICAgIDQ5IGNydy0tLS0tLS0gICB0dHl2 MiBydwpyb290ICAgICBsb2dpbiAgICAgICAxMTg0ICAgIDAgL2RldiAgICAgICAgIDQ5IGNydy0t LS0tLS0gICB0dHl2MiBydwpyb290ICAgICBsb2dpbiAgICAgICAxMTgzIHJvb3QgLyAgICAgICAg ICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBsb2dpbiAgICAgICAxMTgzICAg d2QgLyAgICAgICAgNjAzNTI1MTIgZHJ3eHIteHIteCAgICAgNTEyICByCnJvb3QgICAgIGxvZ2lu ICAgICAgIDExODMgdGV4dCAvICAgICAgICAyNjcyNTM3OSAtci1zci14ci14ICAgMjQ3NTIgIHIK cm9vdCAgICAgbG9naW4gICAgICAgMTE4MyBjdHR5IC9kZXYgICAgICAgICA0OCBjcnctLS0tLS0t ICAgdHR5djEgcncKcm9vdCAgICAgbG9naW4gICAgICAgMTE4MyAgICAwIC9kZXYgICAgICAgICA0 OCBjcnctLS0tLS0tICAgdHR5djEgcncKcm9vdCAgICAgbG9naW4gICAgICAgMTE4MiByb290IC8g ICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgbG9naW4gICAgICAg MTE4MiAgIHdkIC8gICAgICAgIDYwMzUyNTEyIGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAg ICBsb2dpbiAgICAgICAxMTgyIHRleHQgLyAgICAgICAgMjY3MjUzNzkgLXItc3IteHIteCAgIDI0 NzUyICByCnJvb3QgICAgIGxvZ2luICAgICAgIDExODIgY3R0eSAvZGV2ICAgICAgICAgNDcgY3J3 LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGxvZ2luICAgICAgIDExODIgICAgMCAvZGV2ICAg ICAgICAgNDcgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGNyb24gICAgICAgIDExNDMg cm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGNyb24g ICAgICAgIDExNDMgICB3ZCAvICAgICAgICA2MDQzMjc4OSBkcnd4ci14LS0tICAgICA1MTIgIHIK cm9vdCAgICAgY3JvbiAgICAgICAgMTE0MyB0ZXh0IC8gICAgICAgIDI2NzI4NDcxIC1yLXhyLXhy LXggICA0MTAyNCAgcgpyb290ICAgICBjcm9uICAgICAgICAxMTQzICAgIDAgL2RldiAgICAgICAg ICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpzbW1zcCAgICBzZW5kbWFpbCAgICAxMTM5IHJvb3Qg LyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpzbW1zcCAgICBzZW5kbWFpbCAg ICAxMTM5ICAgd2QgLyAgICAgICAgNjA1MTMwMjcgZHJ3eHJ3eC0tLSAgICAgNTEyICByCnNtbXNw ICAgIHNlbmRtYWlsICAgIDExMzkgdGV4dCAvICAgICAgICAyNjgxMzk1NCAtci14ci1zci14ICA2 NzYwNjQgIHIKc21tc3AgICAgc2VuZG1haWwgICAgMTEzOSAgICAwIC9kZXYgICAgICAgICAgOSBj cnctcnctcnctICAgIG51bGwgIHIKcm9vdCAgICAgc2VuZG1haWwgICAgMTEzNiByb290IC8gICAg ICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgc2VuZG1haWwgICAgMTEz NiAgIHdkIC8gICAgICAgIDYwNTEzMDI2IGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBz ZW5kbWFpbCAgICAxMTM2IHRleHQgLyAgICAgICAgMjY4MTM5NTQgLXIteHItc3IteCAgNjc2MDY0 ICByCnJvb3QgICAgIHNlbmRtYWlsICAgIDExMzYgICAgMCAvZGV2ICAgICAgICAgIDkgY3J3LXJ3 LXJ3LSAgICBudWxsICByCnJvb3QgICAgIHNzaGQgICAgICAgIDExMzMgcm9vdCAvICAgICAgICAg ICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIHNzaGQgICAgICAgIDExMzMgICB3 ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIHNzaGQgICAg ICAgIDExMzMgdGV4dCAvICAgICAgICAyNjcyODQwMCAtci14ci14ci14ICAyOTIwMTYgIHIKcm9v dCAgICAgc3NoZCAgICAgICAgMTEzMyAgICAwIC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAg IG51bGwgcncKcm9vdCAgICAgc3lzbG9nZCAgICAgMTAxMSByb290IC8gICAgICAgICAgICAgMiBk cnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgc3lzbG9nZCAgICAgMTAxMSAgIHdkIC8gICAg ICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgc3lzbG9nZCAgICAgMTAx MSB0ZXh0IC8gICAgICAgIDI2NzI4NDcwIC1yLXhyLXhyLXggICAzOTY0OCAgcgpyb290ICAgICBz eXNsb2dkICAgICAxMDExICAgIDAgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBy dwpyb290ICAgICBzeXNsb2dkICAgICAxMDExICAgIDYgL2RldiAgICAgICAgICA5IGNydy1ydy1y dy0gICAgbnVsbCBydwpyb290ICAgICBzeXNsb2dkICAgICAxMDExICAgMTIgL2RldiAgICAgICAg ICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzeXNsb2dkICAgICAxMDExICAgMTgg LyAgICAgICAgNjA0MzI5NDAgLXJ3LS0tLS0tLSAgICAgICA0ICB3CnJvb3QgICAgIGRldmQgICAg ICAgICA4OTYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3Qg ICAgIGRldmQgICAgICAgICA4OTYgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAx MDI0ICByCnJvb3QgICAgIGRldmQgICAgICAgICA4OTYgdGV4dCAvICAgICAgICA3MjIzODkgLXIt eHIteHIteCAgMTA2MzA0OCAgcgpyb290ICAgICBkZXZkICAgICAgICAgODk2ICAgIDAgL2RldiAg ICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBkZXZkICAgICAgICAgODk2 ICAgIDYgL2RldiAgICAgICAgICA5IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBtb3Vz ZWQgICAgICAgODc5IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpy b290ICAgICBtb3VzZWQgICAgICAgODc5ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXgg ICAgMTAyNCAgcgpyb290ICAgICBtb3VzZWQgICAgICAgODc5IHRleHQgLyAgICAgICAgMjY3Mjgz OTQgLXIteHIteHIteCAgIDM3ODcyICByCnJvb3QgICAgIG1vdXNlZCAgICAgICA4NzkgICAgMCAv ZGV2ICAgICAgICAgIDkgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1vdXNlZCAgICAg ICA4NTggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAg IG1vdXNlZCAgICAgICA4NTggICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0 ICByCnJvb3QgICAgIG1vdXNlZCAgICAgICA4NTggdGV4dCAvICAgICAgICAyNjcyODM5NCAtci14 ci14ci14ICAgMzc4NzIgIHIKcm9vdCAgICAgbW91c2VkICAgICAgIDg1OCAgICAwIC9kZXYgICAg ICAgICAgOSBjcnctcnctcnctICAgIG51bGwgcncKX2RoY3AgICAgZGhjbGllbnQgICAgIDg1MSBy b290IC8gICAgICAgIDYwNDMyNzg1IGRyLXhyLXhyLXggICAgIDUxMiAgcgpfZGhjcCAgICBkaGNs aWVudCAgICAgODUxICAgd2QgLyAgICAgICAgNjA0MzI3ODUgZHIteHIteHIteCAgICAgNTEyICBy Cl9kaGNwICAgIGRoY2xpZW50ICAgICA4NTEgamFpbCAvICAgICAgICA2MDQzMjc4NSBkci14ci14 ci14ICAgICA1MTIgIHIKX2RoY3AgICAgZGhjbGllbnQgICAgIDg1MSB0ZXh0IC8gICAgICAgIDcy MjMzNiAtci14ci14ci14ICAgOTE5MDQgIHIKX2RoY3AgICAgZGhjbGllbnQgICAgIDg1MSAgICAw IC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51bGwgcncKX2RoY3AgICAgZGhjbGllbnQg ICAgIDg1MSAgICA2IC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAg ICAgZGhjbGllbnQgICAgIDgxNSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEw MjQgIHIKcm9vdCAgICAgZGhjbGllbnQgICAgIDgxNSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4 ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgZGhjbGllbnQgICAgIDgxNSB0ZXh0IC8gICAgICAg IDcyMjMzNiAtci14ci14ci14ICAgOTE5MDQgIHIKcm9vdCAgICAgZGhjbGllbnQgICAgIDgxNSAg ICAwIC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgZGhjbGll bnQgICAgIDgxNSAgICA2IC9kZXYgICAgICAgICAgOSBjcnctcnctcnctICAgIG51bGwgcncKcm9v dCAgICAgaW5pdCAgICAgICAgICAgMSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg IDEwMjQgIHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSAgIHdkIC8gICAgICAgICAgICAgMiBk cnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSB0ZXh0IC8gICAg ICAgIDcyMjMwNiAtci14ci14ci14ICA5MzkzMjAgIHIKcm9vdCAgICAga2VybmVsICAgICAgICAg MCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAga2Vy bmVsICAgICAgICAgMCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIK Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQpkbWVzZwoKQ29weXJpZ2h0IChjKSAxOTkyLTIwMTQgVGhlIEZyZWVC U0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAx OTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0 eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0 ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMC4wLVJF TEVBU0UgIzQ6IFRodSBNYXIgIDUgMDE6MjA6MzUgSVNUIDIwMTUKICAgIHJvb3RARnJlZUJTRDEw X1NUT0NLOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMgYW1kNjQKRnJlZUJTRCBjbGFuZyB2 ZXJzaW9uIDMuMyAodGFncy9SRUxFQVNFXzMzL2ZpbmFsIDE4MzUwMikgMjAxMzA2MTAKV0FSTklO RzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuCkNQ VTogSW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU1NjA2ICBAIDIuMTNHSHogKDIxMjgu MDUtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDIw NmMyICBGYW1pbHkgPSAweDYgIE1vZGVsID0gMHgyYyAgU3RlcHBpbmcgPSAyCiAgRmVhdHVyZXM9 MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1U UlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxT U0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4MjllZTNmZjxTU0UzLFBDTE1VTFFEUSxE VEVTNjQsTU9OLERTX0NQTCxWTVgsU01YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sUENJ RCxEQ0EsU1NFNC4xLFNTRTQuMixQT1BDTlQsQUVTTkk+CiAgQU1EIEZlYXR1cmVzPTB4MmMxMDA4 MDA8U1lTQ0FMTCxOWCxQYWdlMUdCLFJEVFNDUCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhG PgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBt ZW1vcnkgID0gNDI5NDk2NzI5NiAoNDA5NiBNQikKYXZhaWwgbWVtb3J5ID0gNDA5NzQ2MjI3MiAo MzkwNyBNQikKRXZlbnQgdGltZXIgIkxBUElDIiBxdWFsaXR5IDYwMApBQ1BJIEFQSUMgVGFibGU6 IDxERUxMICAgUEVfU0MzICA+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0 ZWN0ZWQ6IDQgQ1BVcwpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggNCBjb3JlKHMpCiBjcHUw IChCU1ApOiBBUElDIElEOiAzMgogY3B1MSAoQVApOiBBUElDIElEOiAzNAogY3B1MiAoQVApOiBB UElDIElEOiA1MAogY3B1MyAoQVApOiBBUElDIElEOiA1Mgppb2FwaWMxOiBDaGFuZ2luZyBBUElD IElEIHRvIDEKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApp b2FwaWMxIDxWZXJzaW9uIDIuMD4gaXJxcyAzMi01NSBvbiBtb3RoZXJib2FyZApyYW5kb206IDxT b2Z0d2FyZSwgWWFycm93PiBpbml0aWFsaXplZAprYmQxIGF0IGtiZG11eDAKYWNwaTA6IDxERUxM IFBFX1NDMz4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmNwdTA6 IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyOiA8QUNQ SSBDUFU+IG9uIGFjcGkwCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTAKYXRydGMwOiA8QVQgcmVh bHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDdmIGlycSA4IG9uIGFjcGkwCkV2ZW50IHRpbWVyICJS VEMiIGZyZXF1ZW5jeSAzMjc2OCBIeiBxdWFsaXR5IDAKYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9y dCAweDQwLTB4NWYgaXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kg MTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4 MiBIeiBxdWFsaXR5IDEwMApocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21l bSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTAKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1 ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDk1MApFdmVudCB0aW1lciAiSFBFVCIgZnJlcXVlbmN5 IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDUwCkV2ZW50IHRpbWVyICJIUEVUMSIgZnJlcXVlbmN5IDE0 MzE4MTgwIEh6IHF1YWxpdHkgNDQwCkV2ZW50IHRpbWVyICJIUEVUMiIgZnJlcXVlbmN5IDE0MzE4 MTgwIEh6IHF1YWxpdHkgNDQwCkV2ZW50IHRpbWVyICJIUEVUMyIgZnJlcXVlbmN5IDE0MzE4MTgw IEh6IHF1YWxpdHkgNDQwClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1 IEh6IHF1YWxpdHkgODUwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6 PiBwb3J0IDB4ODA4LTB4ODBiIG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+ IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAK cGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpMTog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKYmNlMDogPEJyb2FkY29tIE5ldFh0cmVtZSBJSSBCQ001 NzE2IDEwMDBCYXNlLVQgKEMwKT4gbWVtIDB4ZGEwMDAwMDAtMHhkYmZmZmZmZiBpcnEgMzYgYXQg ZGV2aWNlIDAuMCBvbiBwY2kxCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBiY2UwCmJyZ3BoeTA6IDxC Q001NzA5IDEwLzEwMC8xMDAwYmFzZVQgUEhZPiBQSFkgMSBvbiBtaWlidXMwCmJyZ3BoeTA6ICAx MGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQs IDEwMDBiYXNlVC1tYXN0ZXIsIDEwMDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBh dXRvLCBhdXRvLWZsb3cKYmNlMDogRXRoZXJuZXQgYWRkcmVzczogNzg6MmI6Y2I6NWU6NDE6YWUK YmNlMDogQVNJQyAoMHg1NzA5MjAwOCk7IFJldiAoQzApOyBCdXMgKFBDSWUgeDQsIDIuNUdicHMp OyBCL0MgKDUuMi4zKTsgQnVmcyAoUlg6MjtUWDoyO1BHOjgpOyBGbGFncyAoU1BMVHxNU0l8TUZX KTsgTUZXIChOQ1NJIDIuMC4xMSkKQ29hbCAoUlg6Niw2LDE4LDE4OyBUWDoyMCwyMCw4MCw4MCkK YmNlMTogPEJyb2FkY29tIE5ldFh0cmVtZSBJSSBCQ001NzE2IDEwMDBCYXNlLVQgKEMwKT4gbWVt IDB4ZGMwMDAwMDAtMHhkZGZmZmZmZiBpcnEgNDggYXQgZGV2aWNlIDAuMSBvbiBwY2kxCm1paWJ1 czE6IDxNSUkgYnVzPiBvbiBiY2UxCmJyZ3BoeTE6IDxCQ001NzA5IDEwLzEwMC8xMDAwYmFzZVQg UEhZPiBQSFkgMSBvbiBtaWlidXMxCmJyZ3BoeTE6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAw YmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIsIDEwMDBi YXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvLCBhdXRvLWZsb3cKYmNlMTogRXRo ZXJuZXQgYWRkcmVzczogNzg6MmI6Y2I6NWU6NDE6YWYKYmNlMTogQVNJQyAoMHg1NzA5MjAwOCk7 IFJldiAoQzApOyBCdXMgKFBDSWUgeDQsIDIuNUdicHMpOyBCL0MgKDUuMi4zKTsgQnVmcyAoUlg6 MjtUWDoyO1BHOjgpOyBGbGFncyAoU1BMVHxNU0l8TUZXKTsgTUZXIChOQ1NJIDIuMC4xMSkKQ29h bCAoUlg6Niw2LDE4LDE4OyBUWDoyMCwyMCw4MCw4MCkKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgMy4wIG9uIHBjaTAKcGNpNTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIK cGNpNTogPG1hc3Mgc3RvcmFnZSwgUkFJRD4gYXQgZGV2aWNlIDAuMCAobm8gZHJpdmVyIGF0dGFj aGVkKQpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA3LjAgb24gcGNpMApw Y2k2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSA5LjAgb24gcGNpMApwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApwY2li NTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTAKcGNpMjogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjUKcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNv bnRyb2xsZXI+IGF0IGRldmljZSAyMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNl IHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMjAuMSAobm8gZHJp dmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxl cj4gYXQgZGV2aWNlIDIwLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKdWhjaTA6IDxJbnRlbCA4Mjgw MUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUQ+IHBvcnQgMHhlYzQwLTB4ZWM1ZiBpcnEg MTcgYXQgZGV2aWNlIDI2LjAgb24gcGNpMAp1c2J1czAgb24gdWhjaTAKdWhjaTE6IDxJbnRlbCA4 MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUU+IHBvcnQgMHhlYzYwLTB4ZWM3ZiBp cnEgMTggYXQgZGV2aWNlIDI2LjEgb24gcGNpMAp1c2J1czEgb24gdWhjaTEKZWhjaTA6IDxJbnRl bCA4MjgwMUpJIChJQ0gxMCkgVVNCIDIuMCBjb250cm9sbGVyIFVTQi1CPiBtZW0gMHhkZjBmZTAw MC0weGRmMGZlM2ZmIGlycSAxOSBhdCBkZXZpY2UgMjYuNyBvbiBwY2kwCnVzYnVzMjogRUhDSSB2 ZXJzaW9uIDEuMAp1c2J1czIgb24gZWhjaTAKcGNpYjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CnVoY2ky OiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4ZWM4 MC0weGVjOWYgaXJxIDIxIGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdXNidXMzIG9uIHVoY2kyCnVo Y2kzOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1CPiBwb3J0IDB4 ZWNhMC0weGVjYmYgaXJxIDIwIGF0IGRldmljZSAyOS4xIG9uIHBjaTAKdXNidXM0IG9uIHVoY2kz CnVoY2k0OiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1DPiBwb3J0 IDB4ZWNjMC0weGVjZGYgaXJxIDIxIGF0IGRldmljZSAyOS4yIG9uIHBjaTAKdXNidXM1IG9uIHVo Y2k0CnVoY2k1OiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1GPiBw b3J0IDB4ZWNlMC0weGVjZmYgaXJxIDIwIGF0IGRldmljZSAyOS4zIG9uIHBjaTAKdXNidXM2IG9u IHVoY2k1CmVoY2kxOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiAyLjAgY29udHJvbGxlciBV U0ItQT4gbWVtIDB4ZGYwZmYwMDAtMHhkZjBmZjNmZiBpcnEgMjEgYXQgZGV2aWNlIDI5Ljcgb24g cGNpMAp1c2J1czc6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXM3IG9uIGVoY2kxCnBjaWI3OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2k3OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liNwp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gbWVtIDB4ZDk4 MDAwMDAtMHhkOWZmZmZmZiwweGRlN2ZjMDAwLTB4ZGU3ZmZmZmYsMHhkZTgwMDAwMC0weGRlZmZm ZmZmIGlycSAxOSBhdCBkZXZpY2UgMy4wIG9uIHBjaTcKdmdhcGNpMDogQm9vdCB2aWRlbyBkZXZp Y2UKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8 SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVsIElDSDEwIFNBVEEzMDAgY29udHJvbGxl cj4gcG9ydCAweGU4ZTAtMHhlOGU3LDB4ZThkMC0weGU4ZDMsMHhlOGU4LTB4ZThlZiwweGU4ZDQt MHhlOGQ3LDB4ZWMwMC0weGVjMGYsMHhlYzEwLTB4ZWMxZiBpcnEgMjMgYXQgZGV2aWNlIDMxLjIg b24gcGNpMAphdGEyOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhdGFwY2kwCmF0YTM6 IDxBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGF0YXBjaTAKYXRhcGNpMTogPEludGVsIElD SDEwIFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGU4ZjAtMHhlOGY3LDB4ZThkOC0weGU4ZGIs MHhlOGY4LTB4ZThmZiwweGU4ZGMtMHhlOGRmLDB4ZWMyMC0weGVjMmYsMHhlYzMwLTB4ZWMzZiBp cnEgMjIgYXQgZGV2aWNlIDMxLjUgb24gcGNpMAphdGE0OiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5u ZWwgMCBvbiBhdGFwY2kxCmF0YTU6IDxBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGF0YXBj aTEKdWFydDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZs YWdzIDB4MTAgb24gYWNwaTAKdWFydDA6IGNvbnNvbGUgKDk2MDAsbiw4LDEpCnVhcnQxOiA8MTY1 NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBhY3BpMApxcGkwOiA8 UVBJIHN5c3RlbSBidXM+IG9uIG1vdGhlcmJvYXJkCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0 IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4YzhmZmYsMHhlYzAwMC0weGVmZmZmIG9u IGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBW R0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0Eg VkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCmF0 a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0IG9u IGlzYTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGti ZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCBy YW5nZQplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUw CnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwCmVzdDE6IDxF bmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEKcDR0Y2MxOiA8Q1BV IEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKZXN0MjogPEVuaGFuY2VkIFNwZWVk U3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MgpwNHRjYzI6IDxDUFUgRnJlcXVlbmN5IFRo ZXJtYWwgQ29udHJvbD4gb24gY3B1Mgplc3QzOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5j eSBDb250cm9sPiBvbiBjcHUzCnA0dGNjMzogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9s PiBvbiBjcHUzClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKcmFuZG9tOiB1bmJs b2NraW5nIGRldmljZS4KbG9jayBvcmRlciByZXZlcnNhbDoKbG9jayBvcmRlciByZXZlcnNhbDoK bG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZmZmZmODE2NTVlZDggZW50cm9weSBoYXJ2 ZXN0IG11dGV4IChlbnRyb3B5IGhhcnZlc3QgbXV0ZXgpIEAgL3Vzci9zcmMvc3lzL2Rldi9yYW5k b20vcmFuZG9tX2hhcnZlc3RxLmM6MTk4CiAybmQgMHhmZmZmZjgwMDEwMDFlYzM4IHVhcnRfaHdt dHggKHVhcnRfaHdtdHgpIEAgL3Vzci9zcmMvc3lzL2Rldi91YXJ0L3VhcnRfY3B1Lmg6OTIKS0RC OiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3Nl bGZfd3JhcHBlcisweDJiL2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMjExMAprZGJfYmFja3RyYWNlKCkg YXQga2RiX2JhY2t0cmFjZSsweDM5L2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMjFjMAp3aXRuZXNzX2No ZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHhiOGEvZnJhbWUgMHhmZmZmZmUwMGY3 M2YyMjUwCl9fbXR4X2xvY2tfc3Bpbl9mbGFncygpIGF0IF9fbXR4X2xvY2tfc3Bpbl9mbGFncysw eDRjL2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMjJhMAp1YXJ0X2NucHV0YygpIGF0IHVhcnRfY25wdXRj KzB4M2IvZnJhbWUgMHhmZmZmZmUwMGY3M2YyMmMwCmNucHV0YygpIGF0IGNucHV0YysweDdmL2Zy YW1lIDB4ZmZmZmZlMDBmNzNmMjJmMApjbnB1dHMoKSBhdCBjbnB1dHMrMHg1OC9mcmFtZSAweGZm ZmZmZTAwZjczZjIzMTAKcHV0Y2hhcigpIGF0IHB1dGNoYXIrMHgxMzcvZnJhbWUgMHhmZmZmZmUw MGY3M2YyMzkwCmt2cHJpbnRmKCkgYXQga3ZwcmludGYrMHhkYS9mcmFtZSAweGZmZmZmZTAwZjcz ZjI0OTAKdnByaW50ZigpIGF0IHZwcmludGYrMHg4Ny9mcmFtZSAweGZmZmZmZTAwZjczZjI1NjAK cHJpbnRmKCkgYXQgcHJpbnRmKzB4NDMvZnJhbWUgMHhmZmZmZmUwMGY3M2YyNWMwCndpdG5lc3Nf Y2hlY2tvcmRlcigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDk3ZS9mcmFtZSAweGZmZmZmZTAw ZjczZjI2NTAKX19tdHhfbG9ja19zcGluX2ZsYWdzKCkgYXQgX19tdHhfbG9ja19zcGluX2ZsYWdz KzB4NGMvZnJhbWUgMHhmZmZmZmUwMGY3M2YyNmEwCnNjX3B1dHMoKSBhdCBzY19wdXRzKzB4YjAv ZnJhbWUgMHhmZmZmZmUwMGY3M2YyNmUwCnNjX2NucHV0YygpIGF0IHNjX2NucHV0YysweGU1L2Zy YW1lIDB4ZmZmZmZlMDBmNzNmMjcxMApjbnB1dGMoKSBhdCBjbnB1dGMrMHg3Zi9mcmFtZSAweGZm ZmZmZTAwZjczZjI3NDAKY25wdXRzKCkgYXQgY25wdXRzKzB4NTgvZnJhbWUgMHhmZmZmZmUwMGY3 M2YyNzYwCnB1dGNoYXIoKSBhdCBwdXRjaGFyKzB4MTM3L2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMjdl MAprdnByaW50ZigpIGF0IGt2cHJpbnRmKzB4ZGEvZnJhbWUgMHhmZmZmZmUwMGY3M2YyOGUwCnZw cmludGYoKSBhdCB2cHJpbnRmKzB4ODcvZnJhbWUgMHhmZmZmZmUwMGY3M2YyOWIwCnByaW50Zigp IGF0IHByaW50ZisweDQzL2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMmExMAp3aXRuZXNzX2NoZWNrb3Jk ZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg5N2UvZnJhbWUgMHhmZmZmZmUwMGY3M2YyYWEw Cl9fbXR4X2xvY2tfc3Bpbl9mbGFncygpIGF0IF9fbXR4X2xvY2tfc3Bpbl9mbGFncysweDRjL2Zy YW1lIDB4ZmZmZmZlMDBmNzNmMmFmMAptc2xlZXBfc3Bpbl9zYnQoKSBhdCBtc2xlZXBfc3Bpbl9z YnQrMHg1Yi9mcmFtZSAweGZmZmZmZTAwZjczZjJiNzAKcmFuZG9tX2t0aHJlYWQoKSBhdCByYW5k b21fa3RocmVhZCsweDc4L2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMmJiMApmb3JrX2V4aXQoKSBhdCBm b3JrX2V4aXQrMHg3MS9mcmFtZSAweGZmZmZmZTAwZjczZjJiZjAKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lKzB4ZS9mcmFtZSAweGZmZmZmZTAwZjczZjJiZjAKLS0tIHRyYXAg MCwgcmlwID0gMCwgcnNwID0gMHhmZmZmZmUwMGY3M2YyY2IwLCByYnAgPSAwIC0tLQogMXN0IDB4 ZmZmZmZmZmY4MTY1NWVkOCBlbnRyb3B5IGhhcnZlc3QgbXV0ZXggKGVudHJvcHkgaGFydmVzdCBt dXRleCkgQCAvdXNyL3NyYy9zeXMvZGV2L3JhbmRvbS9yYW5kb21faGFydmVzdHEuYzoxOTgKIDJu ZCAweGZmZmZmZmZmODEzZGE4Njggc2NybG9jayAoc2NybG9jaykgQCAvdXNyL3NyYy9zeXMvZGV2 L3N5c2NvbnMvc3lzY29ucy5jOjI2ODIKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3Nl bGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJiL2ZyYW1lIDB4ZmZmZmZl MDBmNzNmMjUxMAprZGJfYmFja3RyYWNlKCkgYXQga2RiX2JhY2t0cmFjZSsweDM5L2ZyYW1lIDB4 ZmZmZmZlMDBmNzNmMjVjMAp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3Jk ZXIrMHhiOGEvZnJhbWUgMHhmZmZmZmUwMGY3M2YyNjUwCl9fbXR4X2xvY2tfc3Bpbl9mbGFncygp IGF0IF9fbXR4X2xvY2tfc3Bpbl9mbGFncysweDRjL2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMjZhMApz Y19wdXRzKCkgYXQgc2NfcHV0cysweGIwL2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMjZlMApzY19jbnB1 dGMoKSBhdCBzY19jbnB1dGMrMHhlNS9mcmFtZSAweGZmZmZmZTAwZjczZjI3MTAKY25wdXRjKCkg YXQgY25wdXRjKzB4N2YvZnJhbWUgMHhmZmZmZmUwMGY3M2YyNzQwCmNucHV0cygpIGF0IGNucHV0 cysweDU4L2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMjc2MApwdXRjaGFyKCkgYXQgcHV0Y2hhcisweDEz Ny9mcmFtZSAweGZmZmZmZTAwZjczZjI3ZTAKa3ZwcmludGYoKSBhdCBrdnByaW50ZisweGRhL2Zy YW1lIDB4ZmZmZmZlMDBmNzNmMjhlMAp2cHJpbnRmKCkgYXQgdnByaW50ZisweDg3L2ZyYW1lIDB4 ZmZmZmZlMDBmNzNmMjliMApwcmludGYoKSBhdCBwcmludGYrMHg0My9mcmFtZSAweGZmZmZmZTAw ZjczZjJhMTAKd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4OTdl L2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMmFhMApfX210eF9sb2NrX3NwaW5fZmxhZ3MoKSBhdCBfX210 eF9sb2NrX3NwaW5fZmxhZ3MrMHg0Yy9mcmFtZSAweGZmZmZmZTAwZjczZjJhZjAKbXNsZWVwX3Nw aW5fc2J0KCkgYXQgbXNsZWVwX3NwaW5fc2J0KzB4NWIvZnJhbWUgMHhmZmZmZmUwMGY3M2YyYjcw CnJhbmRvbV9rdGhyZWFkKCkgYXQgcmFuZG9tX2t0aHJlYWQrMHg3OC9mcmFtZSAweGZmZmZmZTAw ZjczZjJiYjAKZm9ya19leGl0KCkgYXQgZm9ya19leGl0KzB4NzEvZnJhbWUgMHhmZmZmZmUwMGY3 M2YyYmYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweGUvZnJhbWUgMHhm ZmZmZmUwMGY3M2YyYmYwCi0tLSB0cmFwIDAsIHJpcCA9IDAsIHJzcCA9IDB4ZmZmZmZlMDBmNzNm MmNiMCwgcmJwID0gMCAtLS0KIDFzdCAweGZmZmZmZmZmODE2NTVlZDggZW50cm9weSBoYXJ2ZXN0 IG11dGV4IChlbnRyb3B5IGhhcnZlc3QgbXV0ZXgpIEAgL3Vzci9zcmMvc3lzL2Rldi9yYW5kb20v cmFuZG9tX2hhcnZlc3RxLmM6MTk4CiAybmQgMHhmZmZmZmZmZjgxNDQ5ODgwIHNsZWVwcSBjaGFp biAoc2xlZXBxIGNoYWluKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjI0 MApLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJh Y2Vfc2VsZl93cmFwcGVyKzB4MmIvZnJhbWUgMHhmZmZmZmUwMGY3M2YyOTYwCmtkYl9iYWNrdHJh Y2UoKSBhdCBrZGJfYmFja3RyYWNlKzB4MzkvZnJhbWUgMHhmZmZmZmUwMGY3M2YyYTEwCndpdG5l c3NfY2hlY2tvcmRlcigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweGI4YS9mcmFtZSAweGZmZmZm ZTAwZjczZjJhYTAKX19tdHhfbG9ja19zcGluX2ZsYWdzKCkgYXQgX19tdHhfbG9ja19zcGluX2Zs YWdzKzB4NGMvZnJhbWUgMHhmZmZmZmUwMGY3M2YyYWYwCm1zbGVlcF9zcGluX3NidCgpIGF0IG1z bGVlcF9zcGluX3NidCsweDViL2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMmI3MApyYW5kb21fa3RocmVh ZCgpIGF0IHJhbmRvbV9rdGhyZWFkKzB4NzgvZnJhbWUgMHhmZmZmZmUwMGY3M2YyYmIwCmZvcmtf ZXhpdCgpIGF0IGZvcmtfZXhpdCsweDcxL2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMmJmMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHhlL2ZyYW1lIDB4ZmZmZmZlMDBmNzNmMmJm MAotLS0gdHJhcCAwLCByaXAgPSAwLCByc3AgPSAweGZmZmZmZTAwZjczZjJjYjAsIHJicCA9IDAg LS0tCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMxOiAxMk1icHMgRnVs bCBTcGVlZCBVU0IgdjEuMAp1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVs IFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1 czAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVzYnVzMjogNDgw TWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVzYnVzMzogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYx LjAKdWdlbjIuMTogPEludGVsPiBhdCB1c2J1czIKdWh1YjI6IDxJbnRlbCBFSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVnZW4zLjE6IDxJ bnRlbD4gYXQgdXNidXMzCnVodWIzOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMwp1c2J1czQ6IDEyTWJwcyBGdWxsIFNwZWVk IFVTQiB2MS4wCnVzYnVzNTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdWdlbjQuMTogPElu dGVsPiBhdCB1c2J1czQKdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVnZW41LjE6IDxJbnRlbD4gYXQgdXNidXM1 CnVodWI1OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzNQp1c2J1czY6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVz NzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW42LjE6IDxJbnRlbD4gYXQgdXNidXM2 CnVodWI2OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzNgp1Z2VuNy4xOiA8SW50ZWw+IGF0IHVzYnVzNwp1aHViNzogPEludGVs IEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1 czcKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAy IHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRo IDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCnVodWI1OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZAp1aHViNjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjI6 IDQgcG9ydHMgd2l0aCA0IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmFkYTAgYXQgYXRhMiBidXMg MCBzY2J1czAgdGFyZ2V0IDEgbHVuIDAKYWRhMDogPFNUNTAwTk0wMDExIFBBMDk+IEFUQS04IFNB VEEgMi54IGRldmljZQphZGEwOiBTZXJpYWwgTnVtYmVyIFoxTTE4M0RXCmFkYTA6IDMwMC4wMDBN Qi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE1LCBQSU8gODE5MmJ5dGVzKQphZGEwOiA0NzY5 NDBNQiAoOTc2NzczMTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTA6 IFByZXZpb3VzbHkgd2FzIGtub3duIGFzIGFkNQp1Z2VuMi4yOiA8dmVuZG9yIDB4MDQyND4gYXQg dXNidXMyCmNkMCBhdCBhdGE0IGJ1cyAwIHNjYnVzMiB0YXJnZXQgMCBsdW4gMApjZDA6IDxQTERT IERWRC1ST00gREgtMTZENlMgQkQxMT4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlIApj ZDA6IDE1MC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAxLngsIFVETUE1LCBBVEFQSSAxMmJ5dGVz LCBQSU8gODE5MmJ5dGVzKQpjZDA6IGNkIHByZXNlbnQgWzEyMTMyNTMgeCAyMDQ4IGJ5dGUgcmVj b3Jkc10KdWh1Yjg6IDx2ZW5kb3IgMHgwNDI0IHByb2R1Y3QgMHgyNTE0LCBjbGFzcyA5LzAsIHJl diAyLjAwLzAuMDAsIGFkZHIgMj4gb24gdXNidXMyCnVodWI4OiBNVFQgZW5hYmxlZApOZXR2c2Mg aW5pdGlhbGl6aW5nLi4uIFNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMiBM YXVuY2hlZCEKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhClRpbWVjb3VudGVyICJUU0MiIGZyZXF1 ZW5jeSAyMTI4MDUwMTU2IEh6IHF1YWxpdHkgMTAwMApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBl bmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KdWh1Yjg6IDIgcG9ydHMgd2l0aCAy IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI3OiA4IHBvcnRzIHdpdGggOCByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAp1Z2VuMi4zOiA8dmVuZG9yIDB4NDEzYz4gYXQgdXNidXMyCnVodWI5OiA8 dmVuZG9yIDB4NDEzYyBVU0IgMi4wIEh1YiBNVFQsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwg YWRkciAzPiBvbiB1c2J1czIKdWh1Yjk6IE1UVCBlbmFibGVkCnVodWI5OiA0IHBvcnRzIHdpdGgg MyByZW1vdmFibGUsIGJ1cyBwb3dlcmVkCnVnZW4yLjQ6IDxEZWxsPiBhdCB1c2J1czIKdWtiZDA6 IDxEZWxsIFdpcmVkIE11bHRpbWVkaWEgS2V5Ym9hcmQ+IG9uIHVzYnVzMgprYmQyIGF0IHVrYmQw CnVnZW4zLjI6IDxBdm9jZW50PiBhdCB1c2J1czMKdWdlbjQuMjogPEZUREk+IGF0IHVzYnVzNAp1 a2JkMTogPEtleWJvYXJkPiBvbiB1c2J1czMKa2JkMyBhdCB1a2JkMQpUcnlpbmcgdG8gbW91bnQg cm9vdCBmcm9tIHVmczovZGV2L3Vmcy9hYXJvb3RmcyBbcnddLi4uCldBUk5JTkc6IC8gd2FzIG5v dCBwcm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6IC86IG1vdW50IHBlbmRpbmcgZXJyb3I6IGJs b2NrcyA4MTYgZmlsZXMgMQpTZXR0aW5nIGhvc3R1dWlkOiA0YzRjNDU0NC0wMDM5LTM4MTAtODA0 YS1iMWMwNGYzODUyMzEuClNldHRpbmcgaG9zdGlkOiAweDg2NGY5MjE2LgpFbnRyb3B5IGhhcnZl c3Rpbmc6IGludGVycnVwdHMgZXRoZXJuZXQgcG9pbnRfdG9fcG9pbnQgc3dpLgpTdGFydGluZyBm aWxlIHN5c3RlbSBjaGVja3M6CioqIFNVK0ogUmVjb3ZlcmluZyAvZGV2L3Vmcy9hYXJvb3Rmcwoq KiBSZWFkaW5nIDMzNTU0NDMyIGJ5dGUgam91cm5hbCBmcm9tIGlub2RlIDQuCioqIEJ1aWxkaW5n IHJlY292ZXJ5IHRhYmxlLgoqKiBSZXNvbHZpbmcgdW5yZWZlcmVuY2VkIGlub2RlIGxpc3QuCioq IFByb2Nlc3Npbmcgam91cm5hbCBlbnRyaWVzLgoqKiA5MCBqb3VybmFsIHJlY29yZHMgaW4gNTYz MiBieXRlcyBmb3IgNTEuMTQlIHV0aWxpemF0aW9uCioqIEZyZWVkIDEgaW5vZGVzICgwIGRpcnMp IDkgYmxvY2tzLCBhbmQgMTYgZnJhZ3MuCgoqKioqKiBGSUxFIFNZU1RFTSBNQVJLRUQgQ0xFQU4g KioqKioKTW91bnRpbmcgbG9jYWwgZmlsZSBzeXN0ZW1zOi4KV3JpdGluZyBlbnRyb3B5IGZpbGU6 LgpTZXR0aW5nIGhvc3RuYW1lOiBGcmVlQlNEMTBfU1RPQ0suClN0YXJ0aW5nIE5ldHdvcms6IGxv MCBiY2UwIGJjZTEuCmxvMDogZmxhZ3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FT VD4gbWV0cmljIDAgbXR1IDE2Mzg0CglvcHRpb25zPTYwMDAwMzxSWENTVU0sVFhDU1VNLFJYQ1NV TV9JUFY2LFRYQ1NVTV9JUFY2PgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjggCglpbmV0NiBmZTgw OjoxJWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDMgCglpbmV0IDEyNy4wLjAuMSBuZXRtYXNr IDB4ZmYwMDAwMDAgCgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FMPgpi Y2UwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBt ZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz1jMDFiYjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZM QU5fSFdUQUdHSU5HLEpVTUJPX01UVSxWTEFOX0hXQ1NVTSxUU080LFZMQU5fSFdUU08sTElOS1NU QVRFPgoJZXRoZXIgNzg6MmI6Y2I6NWU6NDE6YWUKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQs SUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0ICgx MDBiYXNlVFggPGZ1bGwtZHVwbGV4PikKCXN0YXR1czogYWN0aXZlCmJjZTE6IGZsYWdzPTg4MDI8 QlJPQURDQVNULFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz1j MDFiYjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLEpVTUJPX01UVSxWTEFO X0hXQ1NVTSxUU080LFZMQU5fSFdUU08sTElOS1NUQVRFPgoJZXRoZXIgNzg6MmI6Y2I6NWU6NDE6 YWYKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4K CW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0ClN0YXJ0aW5nIGRldmQuClN0YXJ0aW5nIE5ldHdv cms6IGJjZTEuCmJjZTE6IGZsYWdzPTg4MDI8QlJPQURDQVNULFNJTVBMRVgsTVVMVElDQVNUPiBt ZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz1jMDFiYjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZM QU5fSFdUQUdHSU5HLEpVTUJPX01UVSxWTEFOX0hXQ1NVTSxUU080LFZMQU5fSFdUU08sTElOS1NU QVRFPgoJZXRoZXIgNzg6MmI6Y2I6NWU6NDE6YWYKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQs SUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CnVt czA6IDxNb3VzZT4gb24gdXNidXMzCnVtczE6IDxEZWxsIFdpcmVkIE11bHRpbWVkaWEgS2V5Ym9h cmQ+IG9uIHVzYnVzMgp1bXMwOiAzIGJ1dHRvbnMgYW5kIFtaXSBjb29yZGluYXRlcyBJRD0wCnVt czE6IDMgYnV0dG9ucyBhbmQgW1hZWl0gY29vcmRpbmF0ZXMgSUQ9MQp1ZnRkaTA6IDxGVDIzMlIg VVNCIFVBUlQ+IG9uIHVzYnVzNApTdGFydGluZyBkaGNsaWVudC4KREhDUFJFUVVFU1Qgb24gYmNl MCB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NwpESENQQUNLIGZyb20gMTM1LjI0LjE5Mi4yCkJv Z3VzIEhvc3QgTmFtZSBvcHRpb24gMTI6IEZyZWVCU0QxMF9TVE9DSyAoRnJlZUJTRDEwX1NUT0NL KQpib3VuZCB0byAxMzUuMjQuMTkyLjExMiAtLSByZW5ld2FsIGluIDQzMjAwIHNlY29uZHMuClN0 YXJ0aW5nIHVtczAgbW91c2VkLgpTdGFydGluZyB1bXMxIG1vdXNlZC4KYWRkIG5ldCBmZTgwOjo6 IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmYwMjo6OiBnYXRld2F5IDo6MQphZGQgbmV0IDo6ZmZmZjow LjAuMC4wOiBnYXRld2F5IDo6MQphZGQgbmV0IDo6MC4wLjAuMDogZ2F0ZXdheSA6OjEKQ3JlYXRp bmcgYW5kL29yIHRyaW1taW5nIGxvZyBmaWxlcy4KU3RhcnRpbmcgc3lzbG9nZC4KTm8gY29yZSBk dW1wcyBmb3VuZC4KRUxGIGxkY29uZmlnIHBhdGg6IC9saWIgL3Vzci9saWIgL3Vzci9saWIvY29t cGF0IC91c3IvbG9jYWwvbGliCjMyLWJpdCBjb21wYXRpYmlsaXR5IGxkY29uZmlnIHBhdGg6IC91 c3IvbGliMzIKQ2xlYXJpbmcgL3RtcCAoWCByZWxhdGVkKS4KVXBkYXRpbmcgbW90ZDouCk1vdW50 aW5nIGxhdGUgZmlsZSBzeXN0ZW1zOi4KQ29uZmlndXJpbmcgc3lzY29uczogYmxhbmt0aW1lLgpQ ZXJmb3JtaW5nIHNhbml0eSBjaGVjayBvbiBzc2hkIGNvbmZpZ3VyYXRpb24uClN0YXJ0aW5nIHNz aGQuClN0YXJ0aW5nIHNlbmRtYWlsX3N1Ym1pdC4KU3RhcnRpbmcgc2VuZG1haWxfbXNwX3F1ZXVl LgpTdGFydGluZyBjcm9uLgpTdGFydGluZyBiYWNrZ3JvdW5kIGZpbGUgc3lzdGVtIGNoZWNrcyBp biA2MCBzZWNvbmRzLgoKVGh1IE1hciAxMiAwMDoxMDo1OSBJU1QgMjAxNQpNYXIgMTIgMDA6MTE6 MTMgRnJlZUJTRDEwX1NUT0NLIGxvZ2luOiAyIExPR0lOIEZBSUxVUkVTIE9OIHR0eXYwCk1hciAx MiAwMDoxMToxNSBGcmVlQlNEMTBfU1RPQ0sgbG9naW46IFJPT1QgTE9HSU4gKHJvb3QpIE9OIHR0 eXYwCkFWQUdPIE1lZ2FSQUlEIFNBUyBGcmVlQlNEIG1yc2FzIGRyaXZlciB2ZXJzaW9uOiAwNi43 MDguMDkuMDAKbXJzYXMwOiA8QVZBR08gSW52YWRlciBTQVMgQ29udHJvbGxlcj4gcG9ydCAweGZj MDAtMHhmY2ZmIG1lbSAweGRmMmYwMDAwLTB4ZGYyZmZmZmYsMHhkZjMwMDAwMC0weGRmM2ZmZmZm IGlycSAzMiBhdCBkZXZpY2UgMC4wIG9uIHBjaTUKbXJzYXMwOiBGVyBub3cgaW4gUmVhZHkgc3Rh dGUKbXJzYXMwOiBVc2luZyBNU0ktWCB3aXRoIDQgbnVtYmVyIG9mIHZlY3RvcnMKbXJzYXMwOiBG VyBzdXBwb3J0cyA8OTY+IE1TSVggdmVjdG9yLE9ubGluZSBDUFUgNCBDdXJyZW50IE1TSVggPDQ+ Cm1yc2FzMDogQXZhZ28gRGVidWc6IE1BWCBzZ2UgMHgxMDYgTUFYIGNoYWluIGZyYW1lIHNpemUg MHgxMDAwIAptcnNhczA6IEFsbG9jYXRpbmcgdmVyIGJ1ZiBtZW1vcnkgc2l6ZSAyNTYKbXJzYXMw OiBBbGxvY2F0aW5nIElPIHJlcSBtZW1vcnkgMjM3ODI0Cm1yc2FzMDogQWxsb2NhdGluZyBjaGFp biBmcmFtZSBtZW1vcnkgMzc5Njk5MgptcnNhczA6IEFsbG9jYXRpbmcgcnBseSBkZXNjIG1lbW9y eSA1OTM5MgptcnNhczA6IEFsbG9jYXRpbmcgc2Vuc2UgYnVmIG1lbW9yeSA4ODk5MgptcnNhczA6 IEFsbG9jYXRpbmcgRXZ0IGR0bCBidWYgbWVtb3J5IDI1NgptcnNhczA6IElzc3VpbmcgSU9DIElO SVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9t IEZXLgptcnNhczA6IEZXIHN1cHBvcnRzIFNFRCAKbXJzYXMwOiBGVyBzdXBwb3J0cyBKQk9EIE1h cCAKbXJzYXMwOiBKYm9kIG1hcCBpcyBzdXBwb3J0ZWQKbXJzYXMwOiBNU0kteCBpbnRlcnJ1cHRz IHNldHVwIHN1Y2Nlc3MKbXJzYXMwOiBtcnNhc19vY3JfdGhyZWFkCmRhMCBhdCBtcnNhczAgYnVz IDEgc2NidXM1IHRhcmdldCA0NyBsdW4gMApkYTA6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+ IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS02IGRldmljZSAKZGEwOiBTZXJpYWwgTnVtYmVyIDZY UDVLOTdHMDAwME0zNDRFSkFZCmRhMDogMTUwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogMjg2MTAy TUIgKDU4NTkzNzUwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDM2NDcyQykKZGExIGF0 IG1yc2FzMCBidXMgMSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAwCmRhMTogPFNFQUdBVEUgU1Q5MzAw NjA1U1MgMDAwND4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTYgZGV2aWNlIApkYTE6IFNlcmlh bCBOdW1iZXIgNlhQNUtBNEIwMDAwQjM0NDlYSk0KZGExOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMK ZGExOiAyODYxMDJNQiAoNTg1OTM3NTAwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMzY0 NzJDKQpkYTIgYXQgbXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNDkgbHVuIDAKZGEyOiA8U0VB R0FURSBTVDkzMDA2MDVTUyAwMDA0PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNiBkZXZpY2Ug CmRhMjogU2VyaWFsIE51bWJlciA2WFA1S0Q4MTAwMDBNMzQ0NzVRSApkYTI6IDE1MC4wMDBNQi9z IHRyYW5zZmVycwpkYTI6IDI4NjEwMk1CICg1ODU5Mzc1MDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1 SCA2M1MvVCAzNjQ3MkMpCmRhMyBhdCBtcnNhczAgYnVzIDEgc2NidXM1IHRhcmdldCA1MCBsdW4g MApkYTM6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NT SS02IGRldmljZSAKZGEzOiBTZXJpYWwgTnVtYmVyIDZYUDVLOTRGMDAwME0zNDRDUURCCmRhMzog MTUwLjAwME1CL3MgdHJhbnNmZXJzCmRhMzogMjg2MTAyTUIgKDU4NTkzNzUwMCA1MTIgYnl0ZSBz ZWN0b3JzOiAyNTVIIDYzUy9UIDM2NDcyQykKbXJzYXMwOiBFeGl0IGR1ZSB0byBTaHV0ZG93biBm cm9tIG1yc2FzX29jcl90aHJlYWQKbXJzYXMwOiBKYm9kIG1hcCBzeW5jIGZhaWxlZCwgc3RhdHVz PTIzCm1yc2FzMDogUHJlcGFyaW5nIHRvIHNodXQgZG93biBjb250cm9sbGVyLgpkYTAgYXQgbXJz YXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNDcgbHVuIDAKZGEwOiA8U0VBR0FURSBTVDkzMDA2MDVT UyAwMDA0PiBzL24gNlhQNUs5N0cwMDAwTTM0NEVKQVkgZGV0YWNoZWQKZGExIGF0IG1yc2FzMCBi dXMgMSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAwCmRhMTogPFNFQUdBVEUgU1Q5MzAwNjA1U1MgMDAw ND4gcy9uIDZYUDVLQTRCMDAwMEIzNDQ5WEpNIGRldGFjaGVkCmRhMiBhdCBtcnNhczAgYnVzIDEg c2NidXM1IHRhcmdldCA0OSBsdW4gMApkYTI6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IHMv biA2WFA1S0Q4MTAwMDBNMzQ0NzVRSCBkZXRhY2hlZApkYTMgYXQgbXJzYXMwIGJ1cyAxIHNjYnVz NSB0YXJnZXQgNTAgbHVuIDAKZGEzOiA8U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBzL24gNlhQ NUs5NEYwMDAwTTM0NENRREIgZGV0YWNoZWQKKGRhMDptcnNhczA6MTo0NzowKTogUGVyaXBoIGRl c3Ryb3llZAooZGExOm1yc2FzMDoxOjQ4OjApOiBQZXJpcGggZGVzdHJveWVkCihkYTM6bXJzYXMw OjE6NTA6MCk6IFBlcmlwaCBkZXN0cm95ZWQKKGRhMjptcnNhczA6MTo0OTowKTogUGVyaXBoIGRl c3Ryb3llZAptcnNhczA6IGRldGFjaGVkCnBjaTU6IDxtYXNzIHN0b3JhZ2UsIFJBSUQ+IGF0IGRl dmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKQVZBR08gTWVnYVJBSUQgU0FTIEZyZWVCU0Qg bXJzYXMgZHJpdmVyIHZlcnNpb246IDA2LjcwOC4wOS4wMAptcnNhczA6IDxBVkFHTyBJbnZhZGVy IFNBUyBDb250cm9sbGVyPiBwb3J0IDB4ZmMwMC0weGZjZmYgbWVtIDB4ZGYyZjAwMDAtMHhkZjJm ZmZmZiwweGRmMzAwMDAwLTB4ZGYzZmZmZmYgaXJxIDMyIGF0IGRldmljZSAwLjAgb24gcGNpNQpt cnNhczA6IFdhaXRpbmcgZm9yIEZXIHRvIGNvbWUgdG8gcmVhZHkgc3RhdGUKbXJzYXMwOiBGVyBu b3cgaW4gUmVhZHkgc3RhdGUKbXJzYXMwOiBVc2luZyBNU0ktWCB3aXRoIDQgbnVtYmVyIG9mIHZl Y3RvcnMKbXJzYXMwOiBGVyBzdXBwb3J0cyA8OTY+IE1TSVggdmVjdG9yLE9ubGluZSBDUFUgNCBD dXJyZW50IE1TSVggPDQ+Cm1yc2FzMDogQXZhZ28gRGVidWc6IE1BWCBzZ2UgMHgxMDYgTUFYIGNo YWluIGZyYW1lIHNpemUgMHgxMDAwIAptcnNhczA6IEFsbG9jYXRpbmcgdmVyIGJ1ZiBtZW1vcnkg c2l6ZSAyNTYKbXJzYXMwOiBBbGxvY2F0aW5nIElPIHJlcSBtZW1vcnkgMjM3ODI0Cm1yc2FzMDog QWxsb2NhdGluZyBjaGFpbiBmcmFtZSBtZW1vcnkgMzc5Njk5MgptcnNhczA6IEFsbG9jYXRpbmcg cnBseSBkZXNjIG1lbW9yeSA1OTM5MgptcnNhczA6IEFsbG9jYXRpbmcgc2Vuc2UgYnVmIG1lbW9y eSA4ODk5MgptcnNhczA6IEFsbG9jYXRpbmcgRXZ0IGR0bCBidWYgbWVtb3J5IDI1NgptcnNhczA6 IElzc3VpbmcgSU9DIElOSVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25z ZSByZWNlaXZlZCBmcm9tIEZXLgptcnNhczA6IEZXIHN1cHBvcnRzIFNFRCAKbXJzYXMwOiBGVyBz dXBwb3J0cyBKQk9EIE1hcCAKbXJzYXMwOiBKYm9kIG1hcCBpcyBzdXBwb3J0ZWQKbXJzYXMwOiBN U0kteCBpbnRlcnJ1cHRzIHNldHVwIHN1Y2Nlc3MKbXJzYXMwOiBtcnNhc19vY3JfdGhyZWFkCmRh MCBhdCBtcnNhczAgYnVzIDEgc2NidXM1IHRhcmdldCA0NyBsdW4gMApkYTA6IDxTRUFHQVRFIFNU OTMwMDYwNVNTIDAwMDQ+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS02IGRldmljZSAKZGEwOiBT ZXJpYWwgTnVtYmVyIDZYUDVLOTdHMDAwME0zNDRFSkFZCmRhMDogMTUwLjAwME1CL3MgdHJhbnNm ZXJzCmRhMDogMjg2MTAyTUIgKDU4NTkzNzUwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9U IDM2NDcyQykKZGExIGF0IG1yc2FzMCBidXMgMSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAwCmRhMTog PFNFQUdBVEUgU1Q5MzAwNjA1U1MgMDAwND4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTYgZGV2 aWNlIApkYTE6IFNlcmlhbCBOdW1iZXIgNlhQNUtBNEIwMDAwQjM0NDlYSk0KZGExOiAxNTAuMDAw TUIvcyB0cmFuc2ZlcnMKZGExOiAyODYxMDJNQiAoNTg1OTM3NTAwIDUxMiBieXRlIHNlY3RvcnM6 IDI1NUggNjNTL1QgMzY0NzJDKQpkYTIgYXQgbXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNDkg bHVuIDAKZGEyOiA8U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBGaXhlZCBEaXJlY3QgQWNjZXNz IFNDU0ktNiBkZXZpY2UgCmRhMjogU2VyaWFsIE51bWJlciA2WFA1S0Q4MTAwMDBNMzQ0NzVRSApk YTI6IDE1MC4wMDBNQi9zIHRyYW5zZmVycwpkYTI6IDI4NjEwMk1CICg1ODU5Mzc1MDAgNTEyIGJ5 dGUgc2VjdG9yczogMjU1SCA2M1MvVCAzNjQ3MkMpCmRhMyBhdCBtcnNhczAgYnVzIDEgc2NidXM1 IHRhcmdldCA1MCBsdW4gMApkYTM6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IEZpeGVkIERp cmVjdCBBY2Nlc3MgU0NTSS02IGRldmljZSAKZGEzOiBTZXJpYWwgTnVtYmVyIDZYUDVLOTRGMDAw ME0zNDRDUURCCmRhMzogMTUwLjAwME1CL3MgdHJhbnNmZXJzCmRhMzogMjg2MTAyTUIgKDU4NTkz NzUwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDM2NDcyQykKbXJzYXMwOiBFeGl0IGR1 ZSB0byBTaHV0ZG93biBmcm9tIG1yc2FzX29jcl90aHJlYWQKbXJzYXMwOiBKYm9kIG1hcCBzeW5j IGZhaWxlZCwgc3RhdHVzPTIzCm1yc2FzMDogUHJlcGFyaW5nIHRvIHNodXQgZG93biBjb250cm9s bGVyLgpkYTAgYXQgbXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNDcgbHVuIDAKZGEwOiA8U0VB R0FURSBTVDkzMDA2MDVTUyAwMDA0PiBzL24gNlhQNUs5N0cwMDAwTTM0NEVKQVkgZGV0YWNoZWQK ZGExIGF0IG1yc2FzMCBidXMgMSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAwCmRhMTogPFNFQUdBVEUg U1Q5MzAwNjA1U1MgMDAwND4gcy9uIDZYUDVLQTRCMDAwMEIzNDQ5WEpNIGRldGFjaGVkCmRhMiBh dCBtcnNhczAgYnVzIDEgc2NidXM1IHRhcmdldCA0OSBsdW4gMApkYTI6IDxTRUFHQVRFIFNUOTMw MDYwNVNTIDAwMDQ+IHMvbiA2WFA1S0Q4MTAwMDBNMzQ0NzVRSCBkZXRhY2hlZApkYTMgYXQgbXJz YXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNTAgbHVuIDAKZGEzOiA8U0VBR0FURSBTVDkzMDA2MDVT UyAwMDA0PiBzL24gNlhQNUs5NEYwMDAwTTM0NENRREIgZGV0YWNoZWQKKGRhMDptcnNhczA6MTo0 NzowKTogUGVyaXBoIGRlc3Ryb3llZAooZGEzOm1yc2FzMDoxOjUwOjApOiBQZXJpcGggZGVzdHJv eWVkCihkYTI6bXJzYXMwOjE6NDk6MCk6IFBlcmlwaCBkZXN0cm95ZWQKKGRhMTptcnNhczA6MTo0 ODowKTogUGVyaXBoIGRlc3Ryb3llZAptcnNhczA6IGRldGFjaGVkCnBjaTU6IDxtYXNzIHN0b3Jh Z2UsIFJBSUQ+IGF0IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKQVZBR08gTWVnYVJB SUQgU0FTIEZyZWVCU0QgbXJzYXMgZHJpdmVyIHZlcnNpb246IDA2LjcwOC4wOS4wMAptcnNhczA6 IDxBVkFHTyBJbnZhZGVyIFNBUyBDb250cm9sbGVyPiBwb3J0IDB4ZmMwMC0weGZjZmYgbWVtIDB4 ZGYyZjAwMDAtMHhkZjJmZmZmZiwweGRmMzAwMDAwLTB4ZGYzZmZmZmYgaXJxIDMyIGF0IGRldmlj ZSAwLjAgb24gcGNpNQptcnNhczA6IFdhaXRpbmcgZm9yIEZXIHRvIGNvbWUgdG8gcmVhZHkgc3Rh dGUKbXJzYXMwOiBGVyBub3cgaW4gUmVhZHkgc3RhdGUKbXJzYXMwOiBVc2luZyBNU0ktWCB3aXRo IDQgbnVtYmVyIG9mIHZlY3RvcnMKbXJzYXMwOiBGVyBzdXBwb3J0cyA8OTY+IE1TSVggdmVjdG9y LE9ubGluZSBDUFUgNCBDdXJyZW50IE1TSVggPDQ+Cm1yc2FzMDogQXZhZ28gRGVidWc6IE1BWCBz Z2UgMHgxMDYgTUFYIGNoYWluIGZyYW1lIHNpemUgMHgxMDAwIAptcnNhczA6IEFsbG9jYXRpbmcg dmVyIGJ1ZiBtZW1vcnkgc2l6ZSAyNTYKbXJzYXMwOiBBbGxvY2F0aW5nIElPIHJlcSBtZW1vcnkg MjM3ODI0Cm1yc2FzMDogQWxsb2NhdGluZyBjaGFpbiBmcmFtZSBtZW1vcnkgMzc5Njk5MgptcnNh czA6IEFsbG9jYXRpbmcgcnBseSBkZXNjIG1lbW9yeSA1OTM5MgptcnNhczA6IEFsbG9jYXRpbmcg c2Vuc2UgYnVmIG1lbW9yeSA4ODk5MgptcnNhczA6IEFsbG9jYXRpbmcgRXZ0IGR0bCBidWYgbWVt b3J5IDI1NgptcnNhczA6IElzc3VpbmcgSU9DIElOSVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJ T0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9tIEZXLgptcnNhczA6IEZXIHN1cHBvcnRzIFNF RCAKbXJzYXMwOiBGVyBzdXBwb3J0cyBKQk9EIE1hcCAKbXJzYXMwOiBKYm9kIG1hcCBpcyBzdXBw b3J0ZWQKbXJzYXMwOiBNU0kteCBpbnRlcnJ1cHRzIHNldHVwIHN1Y2Nlc3MKbXJzYXMwOiBtcnNh c19vY3JfdGhyZWFkCmRhMCBhdCBtcnNhczAgYnVzIDEgc2NidXM1IHRhcmdldCA0NyBsdW4gMApk YTA6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS02 IGRldmljZSAKZGEwOiBTZXJpYWwgTnVtYmVyIDZYUDVLOTdHMDAwME0zNDRFSkFZCmRhMDogMTUw LjAwME1CL3MgdHJhbnNmZXJzCmRhMDogMjg2MTAyTUIgKDU4NTkzNzUwMCA1MTIgYnl0ZSBzZWN0 b3JzOiAyNTVIIDYzUy9UIDM2NDcyQykKZGExIGF0IG1yc2FzMCBidXMgMSBzY2J1czUgdGFyZ2V0 IDQ4IGx1biAwCmRhMTogPFNFQUdBVEUgU1Q5MzAwNjA1U1MgMDAwND4gRml4ZWQgRGlyZWN0IEFj Y2VzcyBTQ1NJLTYgZGV2aWNlIApkYTE6IFNlcmlhbCBOdW1iZXIgNlhQNUtBNEIwMDAwQjM0NDlY Sk0KZGExOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOiAyODYxMDJNQiAoNTg1OTM3NTAwIDUx MiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMzY0NzJDKQpkYTIgYXQgbXJzYXMwIGJ1cyAxIHNj YnVzNSB0YXJnZXQgNDkgbHVuIDAKZGEyOiA8U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBGaXhl ZCBEaXJlY3QgQWNjZXNzIFNDU0ktNiBkZXZpY2UgCmRhMjogU2VyaWFsIE51bWJlciA2WFA1S0Q4 MTAwMDBNMzQ0NzVRSApkYTI6IDE1MC4wMDBNQi9zIHRyYW5zZmVycwpkYTI6IDI4NjEwMk1CICg1 ODU5Mzc1MDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAzNjQ3MkMpCmRhMyBhdCBtcnNh czAgYnVzIDEgc2NidXM1IHRhcmdldCA1MCBsdW4gMApkYTM6IDxTRUFHQVRFIFNUOTMwMDYwNVNT IDAwMDQ+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS02IGRldmljZSAKZGEzOiBTZXJpYWwgTnVt YmVyIDZYUDVLOTRGMDAwME0zNDRDUURCCmRhMzogMTUwLjAwME1CL3MgdHJhbnNmZXJzCmRhMzog Mjg2MTAyTUIgKDU4NTkzNzUwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDM2NDcyQykK bXJzYXMwOiBFeGl0IGR1ZSB0byBTaHV0ZG93biBmcm9tIG1yc2FzX29jcl90aHJlYWQKbXJzYXMw OiBKYm9kIG1hcCBzeW5jIGZhaWxlZCwgc3RhdHVzPTIzCm1yc2FzMDogUHJlcGFyaW5nIHRvIHNo dXQgZG93biBjb250cm9sbGVyLgpkYTAgYXQgbXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNDcg bHVuIDAKZGEwOiA8U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBzL24gNlhQNUs5N0cwMDAwTTM0 NEVKQVkgZGV0YWNoZWQKZGExIGF0IG1yc2FzMCBidXMgMSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAw CmRhMTogPFNFQUdBVEUgU1Q5MzAwNjA1U1MgMDAwND4gcy9uIDZYUDVLQTRCMDAwMEIzNDQ5WEpN IGRldGFjaGVkCmRhMiBhdCBtcnNhczAgYnVzIDEgc2NidXM1IHRhcmdldCA0OSBsdW4gMApkYTI6 IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IHMvbiA2WFA1S0Q4MTAwMDBNMzQ0NzVRSCBkZXRh Y2hlZApkYTMgYXQgbXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNTAgbHVuIDAKZGEzOiA8U0VB R0FURSBTVDkzMDA2MDVTUyAwMDA0PiBzL24gNlhQNUs5NEYwMDAwTTM0NENRREIgZGV0YWNoZWQK KGRhMzptcnNhczA6MTo1MDowKTogUGVyaXBoIGRlc3Ryb3llZAooZGEyOm1yc2FzMDoxOjQ5OjAp OiBQZXJpcGggZGVzdHJveWVkCihkYTE6bXJzYXMwOjE6NDg6MCk6IFBlcmlwaCBkZXN0cm95ZWQK KGRhMDptcnNhczA6MTo0NzowKTogUGVyaXBoIGRlc3Ryb3llZAptcnNhczA6IGRldGFjaGVkCnBj aTU6IDxtYXNzIHN0b3JhZ2UsIFJBSUQ+IGF0IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hl ZCkKQVZBR08gTWVnYVJBSUQgU0FTIEZyZWVCU0QgbXJzYXMgZHJpdmVyIHZlcnNpb246IDA2Ljcw OC4wOS4wMAptcnNhczA6IDxBVkFHTyBJbnZhZGVyIFNBUyBDb250cm9sbGVyPiBwb3J0IDB4ZmMw MC0weGZjZmYgbWVtIDB4ZGYyZjAwMDAtMHhkZjJmZmZmZiwweGRmMzAwMDAwLTB4ZGYzZmZmZmYg aXJxIDMyIGF0IGRldmljZSAwLjAgb24gcGNpNQptcnNhczA6IFdhaXRpbmcgZm9yIEZXIHRvIGNv bWUgdG8gcmVhZHkgc3RhdGUKbXJzYXMwOiBGVyBub3cgaW4gUmVhZHkgc3RhdGUKbXJzYXMwOiBV c2luZyBNU0ktWCB3aXRoIDQgbnVtYmVyIG9mIHZlY3RvcnMKbXJzYXMwOiBGVyBzdXBwb3J0cyA8 OTY+IE1TSVggdmVjdG9yLE9ubGluZSBDUFUgNCBDdXJyZW50IE1TSVggPDQ+Cm1yc2FzMDogQXZh Z28gRGVidWc6IE1BWCBzZ2UgMHgxMDYgTUFYIGNoYWluIGZyYW1lIHNpemUgMHgxMDAwIAptcnNh czA6IEFsbG9jYXRpbmcgdmVyIGJ1ZiBtZW1vcnkgc2l6ZSAyNTYKbXJzYXMwOiBBbGxvY2F0aW5n IElPIHJlcSBtZW1vcnkgMjM3ODI0Cm1yc2FzMDogQWxsb2NhdGluZyBjaGFpbiBmcmFtZSBtZW1v cnkgMzc5Njk5MgptcnNhczA6IEFsbG9jYXRpbmcgcnBseSBkZXNjIG1lbW9yeSA1OTM5MgptcnNh czA6IEFsbG9jYXRpbmcgc2Vuc2UgYnVmIG1lbW9yeSA4ODk5MgptcnNhczA6IEFsbG9jYXRpbmcg RXZ0IGR0bCBidWYgbWVtb3J5IDI1NgptcnNhczA6IElzc3VpbmcgSU9DIElOSVQgY29tbWFuZCB0 byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9tIEZXLgptcnNhczA6 IEZXIHN1cHBvcnRzIFNFRCAKbXJzYXMwOiBGVyBzdXBwb3J0cyBKQk9EIE1hcCAKbXJzYXMwOiBK Ym9kIG1hcCBpcyBzdXBwb3J0ZWQKbXJzYXMwOiBNU0kteCBpbnRlcnJ1cHRzIHNldHVwIHN1Y2Nl c3MKbXJzYXMwOiBtcnNhc19vY3JfdGhyZWFkCmRhMCBhdCBtcnNhczAgYnVzIDEgc2NidXM1IHRh cmdldCA0NyBsdW4gMApkYTA6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IEZpeGVkIERpcmVj dCBBY2Nlc3MgU0NTSS02IGRldmljZSAKZGEwOiBTZXJpYWwgTnVtYmVyIDZYUDVLOTdHMDAwME0z NDRFSkFZCmRhMDogMTUwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogMjg2MTAyTUIgKDU4NTkzNzUw MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDM2NDcyQykKZGExIGF0IG1yc2FzMCBidXMg MSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAwCmRhMTogPFNFQUdBVEUgU1Q5MzAwNjA1U1MgMDAwND4g Rml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTYgZGV2aWNlIApkYTE6IFNlcmlhbCBOdW1iZXIgNlhQ NUtBNEIwMDAwQjM0NDlYSk0KZGExOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOiAyODYxMDJN QiAoNTg1OTM3NTAwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMzY0NzJDKQpkYTIgYXQg bXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNTAgbHVuIDAKZGEyOiA8U0VBR0FURSBTVDkzMDA2 MDVTUyAwMDA0PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNiBkZXZpY2UgCmRhMjogU2VyaWFs IE51bWJlciA2WFA1Szk0RjAwMDBNMzQ0Q1FEQgpkYTI6IDE1MC4wMDBNQi9zIHRyYW5zZmVycwpk YTI6IDI4NjEwMk1CICg1ODU5Mzc1MDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAzNjQ3 MkMpCmRhMyBhdCBtcnNhczAgYnVzIDEgc2NidXM1IHRhcmdldCA0OSBsdW4gMApkYTM6IDxTRUFH QVRFIFNUOTMwMDYwNVNTIDAwMDQ+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS02IGRldmljZSAK ZGEzOiBTZXJpYWwgTnVtYmVyIDZYUDVLRDgxMDAwME0zNDQ3NVFICmRhMzogMTUwLjAwME1CL3Mg dHJhbnNmZXJzCmRhMzogMjg2MTAyTUIgKDU4NTkzNzUwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVI IDYzUy9UIDM2NDcyQykKbXJzYXMwOiBFeGl0IGR1ZSB0byBTaHV0ZG93biBmcm9tIG1yc2FzX29j cl90aHJlYWQKbXJzYXMwOiBKYm9kIG1hcCBzeW5jIGZhaWxlZCwgc3RhdHVzPTIzCm1yc2FzMDog UHJlcGFyaW5nIHRvIHNodXQgZG93biBjb250cm9sbGVyLgpkYTAgYXQgbXJzYXMwIGJ1cyAxIHNj YnVzNSB0YXJnZXQgNDcgbHVuIDAKZGEwOiA8U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBzL24g NlhQNUs5N0cwMDAwTTM0NEVKQVkgZGV0YWNoZWQKZGExIGF0IG1yc2FzMCBidXMgMSBzY2J1czUg dGFyZ2V0IDQ4IGx1biAwCmRhMTogPFNFQUdBVEUgU1Q5MzAwNjA1U1MgMDAwND4gcy9uIDZYUDVL QTRCMDAwMEIzNDQ5WEpNIGRldGFjaGVkCmRhMyBhdCBtcnNhczAgYnVzIDEgc2NidXM1IHRhcmdl dCA0OSBsdW4gMApkYTM6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IHMvbiA2WFA1S0Q4MTAw MDBNMzQ0NzVRSCBkZXRhY2hlZApkYTIgYXQgbXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNTAg bHVuIDAKZGEyOiA8U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBzL24gNlhQNUs5NEYwMDAwTTM0 NENRREIgZGV0YWNoZWQKKGRhMDptcnNhczA6MTo0NzowKTogUGVyaXBoIGRlc3Ryb3llZAooZGEz Om1yc2FzMDoxOjQ5OjApOiBQZXJpcGggZGVzdHJveWVkCihkYTI6bXJzYXMwOjE6NTA6MCk6IFBl cmlwaCBkZXN0cm95ZWQKKGRhMTptcnNhczA6MTo0ODowKTogUGVyaXBoIGRlc3Ryb3llZAptcnNh czA6IGRldGFjaGVkCnBjaTU6IDxtYXNzIHN0b3JhZ2UsIFJBSUQ+IGF0IGRldmljZSAwLjAgKG5v IGRyaXZlciBhdHRhY2hlZCkKQVZBR08gTWVnYVJBSUQgU0FTIEZyZWVCU0QgbXJzYXMgZHJpdmVy IHZlcnNpb246IDA2LjcwOC4wOS4wMAptcnNhczA6IDxBVkFHTyBJbnZhZGVyIFNBUyBDb250cm9s bGVyPiBwb3J0IDB4ZmMwMC0weGZjZmYgbWVtIDB4ZGYyZjAwMDAtMHhkZjJmZmZmZiwweGRmMzAw MDAwLTB4ZGYzZmZmZmYgaXJxIDMyIGF0IGRldmljZSAwLjAgb24gcGNpNQptcnNhczA6IFdhaXRp bmcgZm9yIEZXIHRvIGNvbWUgdG8gcmVhZHkgc3RhdGUKbXJzYXMwOiBGVyBub3cgaW4gUmVhZHkg c3RhdGUKbXJzYXMwOiBVc2luZyBNU0ktWCB3aXRoIDQgbnVtYmVyIG9mIHZlY3RvcnMKbXJzYXMw OiBGVyBzdXBwb3J0cyA8OTY+IE1TSVggdmVjdG9yLE9ubGluZSBDUFUgNCBDdXJyZW50IE1TSVgg PDQ+Cm1yc2FzMDogQXZhZ28gRGVidWc6IE1BWCBzZ2UgMHgxMDYgTUFYIGNoYWluIGZyYW1lIHNp emUgMHgxMDAwIAptcnNhczA6IEFsbG9jYXRpbmcgdmVyIGJ1ZiBtZW1vcnkgc2l6ZSAyNTYKbXJz YXMwOiBBbGxvY2F0aW5nIElPIHJlcSBtZW1vcnkgMjM3ODI0Cm1yc2FzMDogQWxsb2NhdGluZyBj aGFpbiBmcmFtZSBtZW1vcnkgMzc5Njk5MgptcnNhczA6IEFsbG9jYXRpbmcgcnBseSBkZXNjIG1l bW9yeSA1OTM5MgptcnNhczA6IEFsbG9jYXRpbmcgc2Vuc2UgYnVmIG1lbW9yeSA4ODk5MgptcnNh czA6IEFsbG9jYXRpbmcgRXZ0IGR0bCBidWYgbWVtb3J5IDI1NgptcnNhczA6IElzc3VpbmcgSU9D IElOSVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBm cm9tIEZXLgptcnNhczA6IEZXIHN1cHBvcnRzIFNFRCAKbXJzYXMwOiBGVyBzdXBwb3J0cyBKQk9E IE1hcCAKbXJzYXMwOiBKYm9kIG1hcCBpcyBzdXBwb3J0ZWQKbXJzYXMwOiBNU0kteCBpbnRlcnJ1 cHRzIHNldHVwIHN1Y2Nlc3MKbXJzYXMwOiBtcnNhc19vY3JfdGhyZWFkCmRhMCBhdCBtcnNhczAg YnVzIDEgc2NidXM1IHRhcmdldCA0NyBsdW4gMApkYTA6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAw MDQ+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS02IGRldmljZSAKZGEwOiBTZXJpYWwgTnVtYmVy IDZYUDVLOTdHMDAwME0zNDRFSkFZCmRhMDogMTUwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogMjg2 MTAyTUIgKDU4NTkzNzUwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDM2NDcyQykKZGEx IGF0IG1yc2FzMCBidXMgMSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAwCmRhMTogPFNFQUdBVEUgU1Q5 MzAwNjA1U1MgMDAwND4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTYgZGV2aWNlIApkYTE6IFNl cmlhbCBOdW1iZXIgNlhQNUtBNEIwMDAwQjM0NDlYSk0KZGExOiAxNTAuMDAwTUIvcyB0cmFuc2Zl cnMKZGExOiAyODYxMDJNQiAoNTg1OTM3NTAwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1Qg MzY0NzJDKQpkYTIgYXQgbXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNDkgbHVuIDAKZGEyOiA8 U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNiBkZXZp Y2UgCmRhMjogU2VyaWFsIE51bWJlciA2WFA1S0Q4MTAwMDBNMzQ0NzVRSApkYTI6IDE1MC4wMDBN Qi9zIHRyYW5zZmVycwpkYTI6IDI4NjEwMk1CICg1ODU5Mzc1MDAgNTEyIGJ5dGUgc2VjdG9yczog MjU1SCA2M1MvVCAzNjQ3MkMpCmRhMyBhdCBtcnNhczAgYnVzIDEgc2NidXM1IHRhcmdldCA1MCBs dW4gMApkYTM6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IEZpeGVkIERpcmVjdCBBY2Nlc3Mg U0NTSS02IGRldmljZSAKZGEzOiBTZXJpYWwgTnVtYmVyIDZYUDVLOTRGMDAwME0zNDRDUURCCmRh MzogMTUwLjAwME1CL3MgdHJhbnNmZXJzCmRhMzogMjg2MTAyTUIgKDU4NTkzNzUwMCA1MTIgYnl0 ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDM2NDcyQykKbXJzYXMwOiBFeGl0IGR1ZSB0byBTaHV0ZG93 biBmcm9tIG1yc2FzX29jcl90aHJlYWQKbXJzYXMwOiBKYm9kIG1hcCBzeW5jIGZhaWxlZCwgc3Rh dHVzPTIzCm1yc2FzMDogUHJlcGFyaW5nIHRvIHNodXQgZG93biBjb250cm9sbGVyLgpkYTAgYXQg bXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNDcgbHVuIDAKZGEwOiA8U0VBR0FURSBTVDkzMDA2 MDVTUyAwMDA0PiBzL24gNlhQNUs5N0cwMDAwTTM0NEVKQVkgZGV0YWNoZWQKZGExIGF0IG1yc2Fz MCBidXMgMSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAwCmRhMTogPFNFQUdBVEUgU1Q5MzAwNjA1U1Mg MDAwND4gcy9uIDZYUDVLQTRCMDAwMEIzNDQ5WEpNIGRldGFjaGVkCmRhMiBhdCBtcnNhczAgYnVz IDEgc2NidXM1IHRhcmdldCA0OSBsdW4gMApkYTI6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+ IHMvbiA2WFA1S0Q4MTAwMDBNMzQ0NzVRSCBkZXRhY2hlZApkYTMgYXQgbXJzYXMwIGJ1cyAxIHNj YnVzNSB0YXJnZXQgNTAgbHVuIDAKZGEzOiA8U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBzL24g NlhQNUs5NEYwMDAwTTM0NENRREIgZGV0YWNoZWQKKGRhMDptcnNhczA6MTo0NzowKTogUGVyaXBo IGRlc3Ryb3llZAooZGEzOm1yc2FzMDoxOjUwOjApOiBQZXJpcGggZGVzdHJveWVkCihkYTI6bXJz YXMwOjE6NDk6MCk6IFBlcmlwaCBkZXN0cm95ZWQKKGRhMTptcnNhczA6MTo0ODowKTogUGVyaXBo IGRlc3Ryb3llZAptcnNhczA6IGRldGFjaGVkCnBjaTU6IDxtYXNzIHN0b3JhZ2UsIFJBSUQ+IGF0 IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKQVZBR08gTWVnYVJBSUQgU0FTIEZyZWVC U0QgbXJzYXMgZHJpdmVyIHZlcnNpb246IDA2LjcwOC4wOS4wMAptcnNhczA6IDxBVkFHTyBJbnZh ZGVyIFNBUyBDb250cm9sbGVyPiBwb3J0IDB4ZmMwMC0weGZjZmYgbWVtIDB4ZGYyZjAwMDAtMHhk ZjJmZmZmZiwweGRmMzAwMDAwLTB4ZGYzZmZmZmYgaXJxIDMyIGF0IGRldmljZSAwLjAgb24gcGNp NQptcnNhczA6IFdhaXRpbmcgZm9yIEZXIHRvIGNvbWUgdG8gcmVhZHkgc3RhdGUKbXJzYXMwOiBG VyBub3cgaW4gUmVhZHkgc3RhdGUKbXJzYXMwOiBVc2luZyBNU0ktWCB3aXRoIDQgbnVtYmVyIG9m IHZlY3RvcnMKbXJzYXMwOiBGVyBzdXBwb3J0cyA8OTY+IE1TSVggdmVjdG9yLE9ubGluZSBDUFUg NCBDdXJyZW50IE1TSVggPDQ+Cm1yc2FzMDogQXZhZ28gRGVidWc6IE1BWCBzZ2UgMHgxMDYgTUFY IGNoYWluIGZyYW1lIHNpemUgMHgxMDAwIAptcnNhczA6IEFsbG9jYXRpbmcgdmVyIGJ1ZiBtZW1v cnkgc2l6ZSAyNTYKbXJzYXMwOiBBbGxvY2F0aW5nIElPIHJlcSBtZW1vcnkgMjM3ODI0Cm1yc2Fz MDogQWxsb2NhdGluZyBjaGFpbiBmcmFtZSBtZW1vcnkgMzc5Njk5MgptcnNhczA6IEFsbG9jYXRp bmcgcnBseSBkZXNjIG1lbW9yeSA1OTM5MgptcnNhczA6IEFsbG9jYXRpbmcgc2Vuc2UgYnVmIG1l bW9yeSA4ODk5MgptcnNhczA6IEFsbG9jYXRpbmcgRXZ0IGR0bCBidWYgbWVtb3J5IDI1NgptcnNh czA6IElzc3VpbmcgSU9DIElOSVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNw b25zZSByZWNlaXZlZCBmcm9tIEZXLgptcnNhczA6IEZXIHN1cHBvcnRzIFNFRCAKbXJzYXMwOiBG VyBzdXBwb3J0cyBKQk9EIE1hcCAKbXJzYXMwOiBKYm9kIG1hcCBpcyBzdXBwb3J0ZWQKbXJzYXMw OiBNU0kteCBpbnRlcnJ1cHRzIHNldHVwIHN1Y2Nlc3MKbXJzYXMwOiBtcnNhc19vY3JfdGhyZWFk CmRhMCBhdCBtcnNhczAgYnVzIDEgc2NidXM1IHRhcmdldCA0NyBsdW4gMApkYTA6IDxTRUFHQVRF IFNUOTMwMDYwNVNTIDAwMDQ+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS02IGRldmljZSAKZGEw OiBTZXJpYWwgTnVtYmVyIDZYUDVLOTdHMDAwME0zNDRFSkFZCmRhMDogMTUwLjAwME1CL3MgdHJh bnNmZXJzCmRhMDogMjg2MTAyTUIgKDU4NTkzNzUwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYz Uy9UIDM2NDcyQykKZGExIGF0IG1yc2FzMCBidXMgMSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAwCmRh MTogPFNFQUdBVEUgU1Q5MzAwNjA1U1MgMDAwND4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTYg ZGV2aWNlIApkYTE6IFNlcmlhbCBOdW1iZXIgNlhQNUtBNEIwMDAwQjM0NDlYSk0KZGExOiAxNTAu MDAwTUIvcyB0cmFuc2ZlcnMKZGExOiAyODYxMDJNQiAoNTg1OTM3NTAwIDUxMiBieXRlIHNlY3Rv cnM6IDI1NUggNjNTL1QgMzY0NzJDKQpkYTIgYXQgbXJzYXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQg NDkgbHVuIDAKZGEyOiA8U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBGaXhlZCBEaXJlY3QgQWNj ZXNzIFNDU0ktNiBkZXZpY2UgCmRhMjogU2VyaWFsIE51bWJlciA2WFA1S0Q4MTAwMDBNMzQ0NzVR SApkYTI6IDE1MC4wMDBNQi9zIHRyYW5zZmVycwpkYTI6IDI4NjEwMk1CICg1ODU5Mzc1MDAgNTEy IGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAzNjQ3MkMpCmRhMyBhdCBtcnNhczAgYnVzIDEgc2Ni dXM1IHRhcmdldCA1MCBsdW4gMApkYTM6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IEZpeGVk IERpcmVjdCBBY2Nlc3MgU0NTSS02IGRldmljZSAKZGEzOiBTZXJpYWwgTnVtYmVyIDZYUDVLOTRG MDAwME0zNDRDUURCCmRhMzogMTUwLjAwME1CL3MgdHJhbnNmZXJzCmRhMzogMjg2MTAyTUIgKDU4 NTkzNzUwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDM2NDcyQykKTWFyIDEyIDAwOjE4 OjA0IEZyZWVCU0QxMF9TVE9DSyBsb2dpbjogUk9PVCBMT0dJTiAocm9vdCkgT04gdHR5djEKTWFy IDEyIDAwOjE4OjA5IEZyZWVCU0QxMF9TVE9DSyBsb2dpbjogUk9PVCBMT0dJTiAocm9vdCkgT04g dHR5djIKbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUgdG8gRlcgZmF1bHQgZGV0ZWN0ZWQhCm1yc2Fz MDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdpbGwgcmVzZXQgYWRhcHRlci4KbXJzYXMwOiBy ZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jlc2V0X2N0cmwuCm1yc2FzMDogWyA1XXdhaXRp bmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9tIG1yc2FzX2lvY3RsCm1yc2FzMDogV2FpdGlu ZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0ZQptcnNhczA6IFsxMF13YWl0aW5nIGZvciBP Q1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNhczA6IFsxNV13YWl0aW5nIGZv ciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNhczA6IFsyMF13YWl0aW5n IGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNhczA6IEZXIG5vdyBp biBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9DIElOSVQgY29tbWFuZCB0byBGVy4KbXJz YXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9tIEZXLgptcnNhczA6IEpib2QgbWFw IGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nlc3NmdWwKbXJzYXMwOiBSZXNldCBFeGl0 IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUgdG8gRlcgZmF1bHQgZGV0ZWN0ZWQhCm1y c2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdpbGwgcmVzZXQgYWRhcHRlci4KbXJzYXMw OiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jlc2V0X2N0cmwuCm1yc2FzMDogWyA1XXdh aXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9tIG1yc2FzX2lvY3RsCm1yc2FzMDogV2Fp dGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0ZQptcnNhczA6IFsxMF13YWl0aW5nIGZv ciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNhczA6IFsxNV13YWl0aW5n IGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNhczA6IFsyMF13YWl0 aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNhczA6IEZXIG5v dyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9DIElOSVQgY29tbWFuZCB0byBGVy4K bXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9tIEZXLgptcnNhczA6IEpib2Qg bWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nlc3NmdWwKbXJzYXMwOiBSZXNldCBF eGl0IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUgdG8gRlcgZmF1bHQgZGV0ZWN0ZWQh Cm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdpbGwgcmVzZXQgYWRhcHRlci4KbXJz YXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jlc2V0X2N0cmwuCk1hciAxMiAwMDox OTozNCBGcmVlQlNEMTBfU1RPQ0sgbG9naW46IFJPT1QgTE9HSU4gKHJvb3QpIE9OIHR0eXYzCm1y c2FzMDogWyA1XXdhaXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9tIG1yc2FzX2lvY3Rs Cm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0ZQptcnNhczA6IFsx MF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNhczA6 IFsxNV13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNh czA6IFsyMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bApt cnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9DIElOSVQgY29t bWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9tIEZXLgpt cnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nlc3NmdWwKbXJz YXMwOiBSZXNldCBFeGl0IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUgdG8gRlcgZmF1 bHQgZGV0ZWN0ZWQhCm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdpbGwgcmVzZXQg YWRhcHRlci4KbXJzYXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jlc2V0X2N0cmwu Cm1yc2FzMDogWyA1XXdhaXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9tIG1yc2FzX2lv Y3RsCm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0ZQptcnNhczA6 IFsxMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNh czA6IFsxNV13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bApt cnNhczA6IFsyMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0 bAptcnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9DIElOSVQg Y29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9tIEZX LgptcnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nlc3NmdWwK bXJzYXMwOiBSZXNldCBFeGl0IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUgdG8gRlcg ZmF1bHQgZGV0ZWN0ZWQhCm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdpbGwgcmVz ZXQgYWRhcHRlci4KbXJzYXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jlc2V0X2N0 cmwuCm1yc2FzMDogWyA1XXdhaXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9tIG1yc2Fz X2lvY3RsCm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0ZQptcnNh czA6IFsxMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bApt cnNhczA6IFsxNV13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0 bAptcnNhczA6IFsyMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19p b2N0bAptcnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9DIElO SVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9t IEZXLgptcnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nlc3Nm dWwKbXJzYXMwOiBSZXNldCBFeGl0IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUgdG8g RlcgZmF1bHQgZGV0ZWN0ZWQhCm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdpbGwg cmVzZXQgYWRhcHRlci4KbXJzYXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jlc2V0 X2N0cmwuCm1yc2FzMDogWyA1XXdhaXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9tIG1y c2FzX2lvY3RsCm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0ZQpt cnNhczA6IFsxMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0 bAptcnNhczA6IFsxNV13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19p b2N0bAptcnNhczA6IFsyMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNh c19pb2N0bAptcnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9D IElOSVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBm cm9tIEZXLgptcnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nl c3NmdWwKbXJzYXMwOiBSZXNldCBFeGl0IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUg dG8gRlcgZmF1bHQgZGV0ZWN0ZWQhCm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdp bGwgcmVzZXQgYWRhcHRlci4KbXJzYXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jl c2V0X2N0cmwuCm1yc2FzMDogWyA1XXdhaXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9t IG1yc2FzX2lvY3RsCm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0 ZQptcnNhczA6IFsxMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19p b2N0bAptcnNhczA6IFsxNV13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNh c19pb2N0bAptcnNhczA6IFsyMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBt cnNhc19pb2N0bAptcnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3Vpbmcg SU9DIElOSVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZl ZCBmcm9tIEZXLgptcnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1 Y2Nlc3NmdWwKbXJzYXMwOiBSZXNldCBFeGl0IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRlZCBk dWUgdG8gRlcgZmF1bHQgZGV0ZWN0ZWQhCm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUs IHdpbGwgcmVzZXQgYWRhcHRlci4KbXJzYXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2Fz X3Jlc2V0X2N0cmwuCm1yc2FzMDogWyA1XXdhaXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBm cm9tIG1yc2FzX2lvY3RsCm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBz dGF0ZQptcnNhczA6IFsxMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNh c19pb2N0bAptcnNhczA6IFsxNV13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBt cnNhc19pb2N0bAptcnNhczA6IFsyMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJv bSBtcnNhc19pb2N0bAptcnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3Vp bmcgSU9DIElOSVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNl aXZlZCBmcm9tIEZXLgptcnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0 IHN1Y2Nlc3NmdWwKbXJzYXMwOiBSZXNldCBFeGl0IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRl ZCBkdWUgdG8gRlcgZmF1bHQgZGV0ZWN0ZWQhCm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3Rh dGUsIHdpbGwgcmVzZXQgYWRhcHRlci4KbXJzYXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1y c2FzX3Jlc2V0X2N0cmwuCm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBz dGF0ZQptcnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9DIElO SVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9t IEZXLgptcnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nlc3Nm dWwKbXJzYXMwOiBSZXNldCBFeGl0IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUgdG8g RlcgZmF1bHQgZGV0ZWN0ZWQhCm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdpbGwg cmVzZXQgYWRhcHRlci4KbXJzYXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jlc2V0 X2N0cmwuCm1yc2FzMDogWyA1XXdhaXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9tIG1y c2FzX2lvY3RsCm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0ZQpt cnNhczA6IFsxMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0 bAptcnNhczA6IFsxNV13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19p b2N0bAptcnNhczA6IFsyMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNh c19pb2N0bAptcnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9D IElOSVQgY29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBm cm9tIEZXLgptcnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nl c3NmdWwKbXJzYXMwOiBSZXNldCBFeGl0IHdpdGggMC4KKHhwdDA6bXJzYXMwOjE6LTE6LTEpOiBy ZXNjYW4gYWxyZWFkeSBxdWV1ZWQKbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUgdG8gRlcgZmF1bHQg ZGV0ZWN0ZWQhCm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdpbGwgcmVzZXQgYWRh cHRlci4KbXJzYXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jlc2V0X2N0cmwuCm1y c2FzMDogWyA1XXdhaXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9tIG1yc2FzX2lvY3Rs Cm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0ZQptcnNhczA6IFsx MF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNhczA6 IFsxNV13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNh czA6IFsyMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bApt cnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9DIElOSVQgY29t bWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9tIEZXLgpt cnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nlc3NmdWwKbXJz YXMwOiBSZXNldCBFeGl0IHdpdGggMC4KbXJzYXMwOiBPQ1Igc3RhcnRlZCBkdWUgdG8gRlcgZmF1 bHQgZGV0ZWN0ZWQhCm1yc2FzMDogRm91bmQgRlcgaW4gRkFVTFQgc3RhdGUsIHdpbGwgcmVzZXQg YWRhcHRlci4KbXJzYXMwOiByZXNldHRpbmcgYWRhcHRlciBmcm9tIG1yc2FzX3Jlc2V0X2N0cmwu Cm1yc2FzMDogWyA1XXdhaXRpbmcgZm9yIE9DUiB0byBiZSBmaW5pc2hlZCBmcm9tIG1yc2FzX2lv Y3RsCm1yc2FzMDogV2FpdGluZyBmb3IgRlcgdG8gY29tZSB0byByZWFkeSBzdGF0ZQptcnNhczA6 IFsxMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bAptcnNh czA6IFsxNV13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0bApt cnNhczA6IFsyMF13YWl0aW5nIGZvciBPQ1IgdG8gYmUgZmluaXNoZWQgZnJvbSBtcnNhc19pb2N0 bAptcnNhczA6IEZXIG5vdyBpbiBSZWFkeSBzdGF0ZQptcnNhczA6IElzc3VpbmcgSU9DIElOSVQg Y29tbWFuZCB0byBGVy4KbXJzYXMwOiBJT0MgSU5JVCByZXNwb25zZSByZWNlaXZlZCBmcm9tIEZX LgptcnNhczA6IEpib2QgbWFwIGlzIHN1cHBvcnRlZAptcnNhczA6IFJlc2V0IHN1Y2Nlc3NmdWwK bXJzYXMwOiBSZXNldCBFeGl0IHdpdGggMC4KbXJzYXMwOiBFeGl0IGR1ZSB0byBTaHV0ZG93biBm cm9tIG1yc2FzX29jcl90aHJlYWQKbXJzYXMwOiBKYm9kIG1hcCBzeW5jIGZhaWxlZCwgc3RhdHVz PTIzCm1yc2FzMDogUHJlcGFyaW5nIHRvIHNodXQgZG93biBjb250cm9sbGVyLgpkYTAgYXQgbXJz YXMwIGJ1cyAxIHNjYnVzNSB0YXJnZXQgNDcgbHVuIDAKZGEwOiA8U0VBR0FURSBTVDkzMDA2MDVT UyAwMDA0PiBzL24gNlhQNUs5N0cwMDAwTTM0NEVKQVkgZGV0YWNoZWQKZGExIGF0IG1yc2FzMCBi dXMgMSBzY2J1czUgdGFyZ2V0IDQ4IGx1biAwCmRhMTogPFNFQUdBVEUgU1Q5MzAwNjA1U1MgMDAw ND4gcy9uIDZYUDVLQTRCMDAwMEIzNDQ5WEpNIGRldGFjaGVkCmRhMiBhdCBtcnNhczAgYnVzIDEg c2NidXM1IHRhcmdldCA0OSBsdW4gMApkYTI6IDxTRUFHQVRFIFNUOTMwMDYwNVNTIDAwMDQ+IHMv biA2WFA1S0Q4MTAwMDBNMzQ0NzVRSCBkZXRhY2hlZApkYTMgYXQgbXJzYXMwIGJ1cyAxIHNjYnVz NSB0YXJnZXQgNTAgbHVuIDAKZGEzOiA8U0VBR0FURSBTVDkzMDA2MDVTUyAwMDA0PiBzL24gNlhQ NUs5NEYwMDAwTTM0NENRREIgZGV0YWNoZWQKKGRhMzptcnNhczA6MTo1MDowKTogUGVyaXBoIGRl c3Ryb3llZAooZGEyOm1yc2FzMDoxOjQ5OjApOiBQZXJpcGggZGVzdHJveWVkCihkYTE6bXJzYXMw OjE6NDg6MCk6IFBlcmlwaCBkZXN0cm95ZWQKKGRhMDptcnNhczA6MTo0NzowKTogUGVyaXBoIGRl c3Ryb3llZAptcnNhczA6IGRldGFjaGVkCnBjaTU6IDxtYXNzIHN0b3JhZ2UsIFJBSUQ+IGF0IGRl dmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKQVZBR08gTWVnYVJBSUQgU0FTIEZyZWVCU0Qg bXJzYXMgZHJpdmVyIHZlcnNpb246IDA2LjcwOC4wOS4wMAptcnNhczA6IDxBVkFHTyBJbnZhZGVy IFNBUyBDb250cm9sbGVyPiBwb3J0IDB4ZmMwMC0weGZjZmYgbWVtIDB4ZGYyZjAwMDAtMHhkZjJm ZmZmZiwweGRmMzAwMDAwLTB4ZGYzZmZmZmYgaXJxIDMyIGF0IGRldmljZSAwLjAgb24gcGNpNQpt cnNhczA6IFdhaXRpbmcgZm9yIEZXIHRvIGNvbWUgdG8gcmVhZHkgc3RhdGUKbXJzYXMwOiBGVyBu b3cgaW4gUmVhZHkgc3RhdGUKbXJzYXMwOiBVc2luZyBNU0ktWCB3aXRoIDQgbnVtYmVyIG9mIHZl Y3RvcnMKbXJzYXMwOiBGVyBzdXBwb3J0cyA8OTY+IE1TSVggdmVjdG9yLE9ubGluZSBDUFUgNCBD dXJyZW50IE1TSVggPDQ+Cm1yc2FzMDogQXZhZ28gRGVidWc6IE1BWCBzZ2UgMHgxMDYgTUFYIGNo YWluIGZyYW1lIHNpemUgMHgxMDAwIAptcnNhczA6IEFsbG9jYXRpbmcgdmVyIGJ1ZiBtZW1vcnkg c2l6ZSAyNTYKbXJzYXMwOiBBbGxvY2F0aW5nIElPIHJlcSBtZW1vcnkgMjM3ODI0Cm1yc2FzMDog QWxsb2NhdGluZyBjaGFpbiBmcmFtZSBtZW1vcnkgMzc5Njk5MgoKCkZhdGFsIHRyYXAgOTogZ2Vu ZXJhbCBwcm90ZWN0aW9uIGZhdWx0IHdoaWxlIGluIGtlcm5lbCBtb2RlCmNwdWlkID0gMjsgYXBp YyBpZCA9IDMyCmluc3RydWN0aW9uIHBvaW50ZXIJPSAweDIwOjB4ZmZmZmZmZmY4MGFlMTZmMwpz dGFjayBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZlMDEyMTNkNDFkMApmcmFtZSBwb2lu dGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZlMDEyMTNkNDI0MApjb2RlIHNlZ21lbnQJCT0gYmFz ZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYgoJCQk9IERQTCAwLCBwcmVzIDEsIGxvbmcg MSwgZGVmMzIgMCwgZ3JhbiAxCnByb2Nlc3NvciBlZmxhZ3MJPSBpbnRlcnJ1cHQgZW5hYmxlZCwg cmVzdW1lLCBJT1BMID0gMApjdXJyZW50IHByb2Nlc3MJCT0gMTQwNiAoa2xkbG9hZCkKCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQprZXJuZWwgY29uZmlnCgpvcHRpb25zCUNPTkZJR19BVVRPR0VORVJBVEVECmlk ZW50CUdFTkVSSUMKbWFjaGluZQlhbWQ2NApjcHUJSEFNTUVSCm1ha2VvcHRpb25zCVdJVEhfQ1RG PTEKbWFrZW9wdGlvbnMJREVCVUc9LWcKb3B0aW9ucwlYRU5IVk0Kb3B0aW9ucwlVU0JfREVCVUcK b3B0aW9ucwlBVEhfRU5BQkxFXzExTgpvcHRpb25zCUFIX0FSNTQxNl9JTlRFUlJVUFRfTUlUSUdB VElPTgpvcHRpb25zCUFIX1NVUFBPUlRfQVI1NDE2Cm9wdGlvbnMJSUVFRTgwMjExX1NVUFBPUlRf TUVTSApvcHRpb25zCUlFRUU4MDIxMV9BTVBEVV9BR0UKb3B0aW9ucwlJRUVFODAyMTFfREVCVUcK b3B0aW9ucwlTQ19QSVhFTF9NT0RFCm9wdGlvbnMJVkVTQQpvcHRpb25zCUFIRF9SRUdfUFJFVFRZ X1BSSU5UCm9wdGlvbnMJQUhDX1JFR19QUkVUVFlfUFJJTlQKb3B0aW9ucwlBVEFfU1RBVElDX0lE Cm9wdGlvbnMJV0lUTkVTUwpvcHRpb25zCUxPQ0tfUFJPRklMSU5HCm9wdGlvbnMJU01QCm9wdGlv bnMJS0RCX1RSQUNFCm9wdGlvbnMJS0RCCm9wdGlvbnMJRERCCm9wdGlvbnMJSU5DTFVERV9DT05G SUdfRklMRQpvcHRpb25zCUREQl9DVEYKb3B0aW9ucwlLRFRSQUNFX0hPT0tTCm9wdGlvbnMJS0RU UkFDRV9GUkFNRQpvcHRpb25zCU1BQwpvcHRpb25zCVBST0NERVNDCm9wdGlvbnMJQ0FQQUJJTElU SUVTCm9wdGlvbnMJQ0FQQUJJTElUWV9NT0RFCm9wdGlvbnMJQVVESVQKb3B0aW9ucwlIV1BNQ19I T09LUwpvcHRpb25zCUtCRF9JTlNUQUxMX0NERVYKb3B0aW9ucwlQUklOVEZfQlVGUl9TSVpFPTEy OApvcHRpb25zCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORwpvcHRpb25zCVNZU1ZTRU0Kb3B0 aW9ucwlTWVNWTVNHCm9wdGlvbnMJU1lTVlNITQpvcHRpb25zCVNUQUNLCm9wdGlvbnMJS1RSQUNF Cm9wdGlvbnMJU0NTSV9ERUxBWT01MDAwCm9wdGlvbnMJQ09NUEFUX0ZSRUVCU0Q3Cm9wdGlvbnMJ Q09NUEFUX0ZSRUVCU0Q2Cm9wdGlvbnMJQ09NUEFUX0ZSRUVCU0Q1Cm9wdGlvbnMJQ09NUEFUX0ZS RUVCU0Q0Cm9wdGlvbnMJQ09NUEFUX0ZSRUVCU0QzMgpvcHRpb25zCUdFT01fTEFCRUwKb3B0aW9u cwlHRU9NX1JBSUQKb3B0aW9ucwlHRU9NX1BBUlRfR1BUCm9wdGlvbnMJUFNFVURPRlMKb3B0aW9u cwlQUk9DRlMKb3B0aW9ucwlDRDk2NjAKb3B0aW9ucwlNU0RPU0ZTCm9wdGlvbnMJTkZTX1JPT1QK b3B0aW9ucwlORlNMT0NLRApvcHRpb25zCU5GU0QKb3B0aW9ucwlORlNDTApvcHRpb25zCU1EX1JP T1QKb3B0aW9ucwlRVU9UQQpvcHRpb25zCVVGU19HSk9VUk5BTApvcHRpb25zCVVGU19ESVJIQVNI Cm9wdGlvbnMJVUZTX0FDTApvcHRpb25zCVNPRlRVUERBVEVTCm9wdGlvbnMJRkZTCm9wdGlvbnMJ U0NUUApvcHRpb25zCVRDUF9PRkZMT0FECm9wdGlvbnMJSU5FVDYKb3B0aW9ucwlJTkVUCm9wdGlv bnMJUFJFRU1QVElPTgpvcHRpb25zCVNDSEVEX1VMRQpvcHRpb25zCU5FV19QQ0lCCm9wdGlvbnMJ R0VPTV9QQVJUX01CUgpvcHRpb25zCUdFT01fUEFSVF9FQlJfQ09NUEFUCm9wdGlvbnMJR0VPTV9Q QVJUX0VCUgpvcHRpb25zCUdFT01fUEFSVF9CU0QKZGV2aWNlCWlzYQpkZXZpY2UJbWVtCmRldmlj ZQlpbwpkZXZpY2UJdWFydF9uczgyNTAKZGV2aWNlCWNwdWZyZXEKZGV2aWNlCWFjcGkKZGV2aWNl CXBjaQpkZXZpY2UJZmRjCmRldmljZQlhaGNpCmRldmljZQlhdGEKZGV2aWNlCW12cwpkZXZpY2UJ c2lpcwpkZXZpY2UJYWhjCmRldmljZQlhaGQKZGV2aWNlCWVzcApkZXZpY2UJaHB0aW9wCmRldmlj ZQlpc3AKZGV2aWNlCW1wdApkZXZpY2UJbXBzCmRldmljZQlzeW0KZGV2aWNlCXRybQpkZXZpY2UJ YWR2CmRldmljZQlhZHcKZGV2aWNlCWFpYwpkZXZpY2UJYnQKZGV2aWNlCWlzY2kKZGV2aWNlCXNj YnVzCmRldmljZQljaApkZXZpY2UJZGEKZGV2aWNlCXNhCmRldmljZQljZApkZXZpY2UJcGFzcwpk ZXZpY2UJc2VzCmRldmljZQlhbXIKZGV2aWNlCWFyY21zcgpkZXZpY2UJY2lzcwpkZXZpY2UJZHB0 CmRldmljZQlocHRtdgpkZXZpY2UJaHB0bnIKZGV2aWNlCWhwdHJyCmRldmljZQlocHQyN3h4CmRl dmljZQlpaXIKZGV2aWNlCWlwcwpkZXZpY2UJbWx5CmRldmljZQl0d2EKZGV2aWNlCXR3cwpkZXZp Y2UJYWFjCmRldmljZQlhYWNwCmRldmljZQlhYWNyYWlkCmRldmljZQlpZGEKZGV2aWNlCW1seApk ZXZpY2UJdHdlCmRldmljZQlhdGtiZGMKZGV2aWNlCWF0a2JkCmRldmljZQlwc20KZGV2aWNlCWti ZG11eApkZXZpY2UJdmdhCmRldmljZQlzcGxhc2gKZGV2aWNlCXNjCmRldmljZQlhZ3AKZGV2aWNl CWNiYgpkZXZpY2UJcGNjYXJkCmRldmljZQljYXJkYnVzCmRldmljZQl1YXJ0CmRldmljZQlwcGMK ZGV2aWNlCXBwYnVzCmRldmljZQlscHQKZGV2aWNlCXBwaQpkZXZpY2UJcHVjCmRldmljZQlieGUK ZGV2aWNlCWRlCmRldmljZQllbQpkZXZpY2UJaWdiCmRldmljZQlpeGdiZQpkZXZpY2UJbGUKZGV2 aWNlCXRpCmRldmljZQl0eHAKZGV2aWNlCXZ4CmRldmljZQltaWlidXMKZGV2aWNlCWFlCmRldmlj ZQlhZ2UKZGV2aWNlCWFsYwpkZXZpY2UJYWxlCmRldmljZQliY2UKZGV2aWNlCWJmZQpkZXZpY2UJ YmdlCmRldmljZQljYXMKZGV2aWNlCWRjCmRldmljZQlldApkZXZpY2UJZnhwCmRldmljZQlnZW0K ZGV2aWNlCWhtZQpkZXZpY2UJam1lCmRldmljZQlsZ2UKZGV2aWNlCW1zawpkZXZpY2UJbmZlCmRl dmljZQluZ2UKZGV2aWNlCXBjbgpkZXZpY2UJcmUKZGV2aWNlCXJsCmRldmljZQlzZgpkZXZpY2UJ c2dlCmRldmljZQlzaXMKZGV2aWNlCXNrCmRldmljZQlzdGUKZGV2aWNlCXN0Z2UKZGV2aWNlCXRs CmRldmljZQl0eApkZXZpY2UJdmdlCmRldmljZQl2cgpkZXZpY2UJd2IKZGV2aWNlCXhsCmRldmlj ZQljcwpkZXZpY2UJZWQKZGV2aWNlCWV4CmRldmljZQllcApkZXZpY2UJZmUKZGV2aWNlCXNuCmRl dmljZQl4ZQpkZXZpY2UJd2xhbgpkZXZpY2UJd2xhbl93ZXAKZGV2aWNlCXdsYW5fY2NtcApkZXZp Y2UJd2xhbl90a2lwCmRldmljZQl3bGFuX2FtcnIKZGV2aWNlCWFuCmRldmljZQlhdGgKZGV2aWNl CWF0aF9wY2kKZGV2aWNlCWF0aF9oYWwKZGV2aWNlCWF0aF9yYXRlX3NhbXBsZQpkZXZpY2UJaXB3 CmRldmljZQlpd2kKZGV2aWNlCWl3bgpkZXZpY2UJbWFsbwpkZXZpY2UJbXdsCmRldmljZQlyYWwK ZGV2aWNlCXdpCmRldmljZQl3cGkKZGV2aWNlCWxvb3AKZGV2aWNlCXJhbmRvbQpkZXZpY2UJcGFk bG9ja19ybmcKZGV2aWNlCXJkcmFuZF9ybmcKZGV2aWNlCWV0aGVyCmRldmljZQl2bGFuCmRldmlj ZQl0dW4KZGV2aWNlCW1kCmRldmljZQlnaWYKZGV2aWNlCWZhaXRoCmRldmljZQlmaXJtd2FyZQpk ZXZpY2UJYnBmCmRldmljZQl1aGNpCmRldmljZQlvaGNpCmRldmljZQllaGNpCmRldmljZQl4aGNp CmRldmljZQl1c2IKZGV2aWNlCXVrYmQKZGV2aWNlCXVtYXNzCmRldmljZQlzb3VuZApkZXZpY2UJ c25kX2NtaQpkZXZpY2UJc25kX2NzYQpkZXZpY2UJc25kX2VtdTEwa3gKZGV2aWNlCXNuZF9lczEz N3gKZGV2aWNlCXNuZF9oZGEKZGV2aWNlCXNuZF9pY2gKZGV2aWNlCXNuZF92aWE4MjMzCmRldmlj ZQltbWMKZGV2aWNlCW1tY3NkCmRldmljZQlzZGhjaQpkZXZpY2UJdmlydGlvCmRldmljZQl2aXJ0 aW9fcGNpCmRldmljZQl2dG5ldApkZXZpY2UJdmlydGlvX2JsawpkZXZpY2UJdmlydGlvX3Njc2kK ZGV2aWNlCXZpcnRpb19iYWxsb29uCmRldmljZQloeXBlcnYKZGV2aWNlCXhlbnBjaQpkZXZpY2UJ dm14CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KZGRiIGNhcHR1cmUgYnVmZmVyCgoK --047d7bfceb402c08e70511161e97-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 13:26:24 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BECF1C23 for ; Thu, 12 Mar 2015 13:26:24 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD578ED for ; Thu, 12 Mar 2015 13:26:18 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygC3ZzztkwFVJCyMAw--.48429S2; Thu, 12 Mar 2015 21:26:10 +0800 (CST) Date: Thu, 12 Mar 2015 21:26:00 +0800 From: Tiwei Bie To: Ryan Stone Subject: Re: [PATCH] Finish the task 'Convert mountlist_mtx to rwlock' Message-ID: <20150312132338.GA57932@freebsd> References: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygC3ZzztkwFVJCyMAw--.48429S2 X-Coremail-Antispam: 1UD129KBjvAXoWfuF13CFyrJFy7GrWxtrW3GFg_yoW5KF18Co Waqa4rtw40gr1kGr4jyanaqFsxGa4DWF9xJr4kGFZFva4kW34UuryxCw13Xa1rXrWruF98 Zry7Wa1DWw4vy3yxn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUYb7k0a2IF6w4kM7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0 x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj4 1l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0 I7IYx2IY6xkF7I0E14v26r4UJVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xv F2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26F4j6r 4UJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc2xSY4AK67AK6ry8MxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07boc_fUUUUU= X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUGAVQhl-c1JwAAsE Cc: "freebsd-hackers@freebsd.org" , Mateusz Guzik , wca@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 13:26:24 -0000 On Thu, Mar 12, 2015 at 12:06:02AM -0400, Ryan Stone wrote: > On Wed, Mar 11, 2015 at 9:10 AM, Tiwei Bie wrote: > > Hi, Mateusz! > > > > I have finished the task: Convert mountlist_mtx to rwlock [1]. > > My first comment is, are we sure that we actually want an rwlock here > instead of an rmlock? An rmlock will offer much better performance in > workloads that mostly only take read locks, and rmlocks do not suffer > the priority inversion problems that rwlocks do. From the description > on the wiki page, it sounds like an rmlock would be ideal here: > > > Interested person can upgrade this task to non-junior by coming up with a > > solution exploiting rare need to modify the list. Example approaches include > > designing a locking primitive with cheap shared locking (think: per-cpu) at > > the expense of exclusive locking. > I think rmlock is okay. But one more argument needs to be added to vfs_busy(), that is 'struct rm_priotracker *tracker' which is used to track read owners of mountlist_lock in vfs_busy(). Following is my patch: --- share/man/man9/vfs_busy.9 | 7 ++- .../compat/opensolaris/kern/opensolaris_lookup.c | 2 +- sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c | 5 ++- .../opensolaris/uts/common/fs/zfs/zfs_ioctl.c | 6 ++- .../opensolaris/uts/common/fs/zfs/zfs_vfsops.c | 6 ++- sys/compat/linprocfs/linprocfs.c | 6 ++- sys/fs/fuse/fuse_vnops.c | 4 +- sys/fs/nfsclient/nfs_clstate.c | 2 +- sys/fs/nfsclient/nfs_clvfsops.c | 2 +- sys/fs/nfsclient/nfs_clvnops.c | 4 +- sys/fs/nfsserver/nfs_nfsdport.c | 4 +- sys/fs/nfsserver/nfs_nfsdserv.c | 2 +- sys/fs/pseudofs/pseudofs_vnops.c | 6 +-- sys/fs/smbfs/smbfs_vnops.c | 4 +- sys/fs/tmpfs/tmpfs_vnops.c | 2 +- sys/geom/journal/g_journal.c | 13 +++--- sys/kern/vfs_extattr.c | 2 +- sys/kern/vfs_lookup.c | 2 +- sys/kern/vfs_mount.c | 26 ++++++----- sys/kern/vfs_mountroot.c | 14 +++--- sys/kern/vfs_subr.c | 51 ++++++++++++---------- sys/kern/vfs_syscalls.c | 33 +++++++------- sys/kern/vfs_vnops.c | 4 +- sys/sys/mount.h | 8 ++-- sys/ufs/ffs/ffs_softdep.c | 8 ++-- sys/ufs/ffs/ffs_suspend.c | 2 +- sys/ufs/ufs/ufs_quota.c | 2 +- 27 files changed, 127 insertions(+), 100 deletions(-) diff --git a/share/man/man9/vfs_busy.9 b/share/man/man9/vfs_busy.9 index 8b9ba86..155e1e6 100644 --- a/share/man/man9/vfs_busy.9 +++ b/share/man/man9/vfs_busy.9 @@ -36,7 +36,7 @@ .In sys/param.h .In sys/mount.h .Ft int -.Fn vfs_busy "struct mount *mp" "int flags" +.Fn vfs_busy "struct mount *mp" "int flags" "struct rm_priotracker *tracker" .Sh DESCRIPTION The .Fn vfs_busy @@ -68,8 +68,11 @@ do not sleep if .Dv MNTK_UNMOUNT is set. .It Dv MBF_MNTLSTLOCK -drop the mountlist_mtx in the critical path. +drop the mountlist_lock in the critical path. .El +.It Fa tracker +The tracker used to track read owners of mountlist_lock +for priority propagation. .El .Sh RETURN VALUES A 0 value is returned on success. diff --git a/sys/cddl/compat/opensolaris/kern/opensolaris_lookup.c b/sys/cddl/compat/opensolaris/kern/opensolaris_lookup.c index 848007e..8e1c657b 100644 --- a/sys/cddl/compat/opensolaris/kern/opensolaris_lookup.c +++ b/sys/cddl/compat/opensolaris/kern/opensolaris_lookup.c @@ -88,7 +88,7 @@ traverse(vnode_t **cvpp, int lktype) vfsp = vn_mountedvfs(cvp); if (vfsp == NULL) break; - error = vfs_busy(vfsp, 0); + error = vfs_busy(vfsp, 0, NULL); /* * tvp is NULL for *cvpp vnode, which we can't unlock. * At least some callers expect the reference to be diff --git a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c index a2532f8..9476641 100644 --- a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c +++ b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c @@ -36,6 +36,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include MALLOC_DECLARE(M_MOUNT); @@ -222,9 +223,9 @@ mount_snapshot(kthread_t *td, vnode_t **vpp, const char *fstype, char *fspath, vp->v_mountedhere = mp; /* Put the new filesystem on the mount list. */ - mtx_lock(&mountlist_mtx); + rm_wlock(&mountlist_lock); TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); - mtx_unlock(&mountlist_mtx); + rm_wunlock(&mountlist_lock); vfs_event_signal(NULL, VQ_MOUNT, 0); if (VFS_ROOT(mp, LK_EXCLUSIVE, &mvp)) panic("mount: lost mount"); diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c index a829b06..a684516 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c @@ -142,6 +142,7 @@ #include #include #include +#include #include #include #include @@ -3014,15 +3015,16 @@ static vfs_t * zfs_get_vfs(const char *resource) { vfs_t *vfsp; + struct rm_priotracker tracker; - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); TAILQ_FOREACH(vfsp, &mountlist, mnt_list) { if (strcmp(refstr_value(vfsp->vfs_resource), resource) == 0) { VFS_HOLD(vfsp); break; } } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); return (vfsp); } diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c index 415db9e..55e11a1 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c @@ -62,6 +62,7 @@ #include #include #include +#include #include "zfs_comutil.h" struct mtx zfs_debug_mtx; @@ -2532,12 +2533,13 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) { char tmpbuf[MAXPATHLEN]; struct mount *mp; + struct rm_priotracker tracker; char *fromname; size_t oldlen; oldlen = strlen(oldname); - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); TAILQ_FOREACH(mp, &mountlist, mnt_list) { fromname = mp->mnt_stat.f_mntfromname; if (strcmp(fromname, oldname) == 0) { @@ -2554,6 +2556,6 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) continue; } } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); } #endif diff --git a/sys/compat/linprocfs/linprocfs.c b/sys/compat/linprocfs/linprocfs.c index 8607646..2d5a538 100644 --- a/sys/compat/linprocfs/linprocfs.c +++ b/sys/compat/linprocfs/linprocfs.c @@ -63,6 +63,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -327,6 +328,7 @@ linprocfs_domtab(PFS_FILL_ARGS) { struct nameidata nd; struct mount *mp; + struct rm_priotracker tracker; const char *lep; char *dlep, *flep, *mntto, *mntfrom, *fstype; size_t lep_len; @@ -344,7 +346,7 @@ linprocfs_domtab(PFS_FILL_ARGS) } lep_len = strlen(lep); - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); error = 0; TAILQ_FOREACH(mp, &mountlist, mnt_list) { /* determine device name */ @@ -387,7 +389,7 @@ linprocfs_domtab(PFS_FILL_ARGS) /* a real Linux mtab will also show NFS options */ sbuf_printf(sb, " 0 0\n"); } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); free(flep, M_TEMP); return (error); } diff --git a/sys/fs/fuse/fuse_vnops.c b/sys/fs/fuse/fuse_vnops.c index 12b9778..b9827df 100644 --- a/sys/fs/fuse/fuse_vnops.c +++ b/sys/fs/fuse/fuse_vnops.c @@ -902,11 +902,11 @@ calldaemon: */ mp = dvp->v_mount; ltype = VOP_ISLOCKED(dvp); - err = vfs_busy(mp, MBF_NOWAIT); + err = vfs_busy(mp, MBF_NOWAIT, NULL); if (err != 0) { vfs_ref(mp); VOP_UNLOCK(dvp, 0); - err = vfs_busy(mp, 0); + err = vfs_busy(mp, 0, NULL); vn_lock(dvp, ltype | LK_RETRY); vfs_rel(mp); if (err) diff --git a/sys/fs/nfsclient/nfs_clstate.c b/sys/fs/nfsclient/nfs_clstate.c index 2600b80..8737003 100644 --- a/sys/fs/nfsclient/nfs_clstate.c +++ b/sys/fs/nfsclient/nfs_clstate.c @@ -3621,7 +3621,7 @@ nfscl_getmnt(int minorvers, uint8_t *sessionid, u_int32_t cbident, mp = clp->nfsc_nmp->nm_mountp; vfs_ref(mp); NFSUNLOCKCLSTATE(); - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); vfs_rel(mp); if (error != 0) return (NULL); diff --git a/sys/fs/nfsclient/nfs_clvfsops.c b/sys/fs/nfsclient/nfs_clvfsops.c index 9758b4c..aa8f8bc 100644 --- a/sys/fs/nfsclient/nfs_clvfsops.c +++ b/sys/fs/nfsclient/nfs_clvfsops.c @@ -287,7 +287,7 @@ nfs_statfs(struct mount *mp, struct statfs *sbp) td = curthread; - error = vfs_busy(mp, MBF_NOWAIT); + error = vfs_busy(mp, MBF_NOWAIT, NULL); if (error) return (error); error = ncl_nget(mp, nmp->nm_fh, nmp->nm_fhsize, &np, LK_EXCLUSIVE); diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c index 513abf4..64a2eea 100644 --- a/sys/fs/nfsclient/nfs_clvnops.c +++ b/sys/fs/nfsclient/nfs_clvnops.c @@ -1228,11 +1228,11 @@ nfs_lookup(struct vop_lookup_args *ap) if (flags & ISDOTDOT) { ltype = NFSVOPISLOCKED(dvp); - error = vfs_busy(mp, MBF_NOWAIT); + error = vfs_busy(mp, MBF_NOWAIT, NULL); if (error != 0) { vfs_ref(mp); NFSVOPUNLOCK(dvp, 0); - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); NFSVOPLOCK(dvp, ltype | LK_RETRY); vfs_rel(mp); if (error == 0 && (dvp->v_iflag & VI_DOOMED)) { diff --git a/sys/fs/nfsserver/nfs_nfsdport.c b/sys/fs/nfsserver/nfs_nfsdport.c index 0ea48cd..c8a80c8 100644 --- a/sys/fs/nfsserver/nfs_nfsdport.c +++ b/sys/fs/nfsserver/nfs_nfsdport.c @@ -1985,7 +1985,7 @@ again: mp = vp->v_mount; vfs_ref(mp); NFSVOPUNLOCK(vp, 0); - nd->nd_repstat = vfs_busy(mp, 0); + nd->nd_repstat = vfs_busy(mp, 0, NULL); vfs_rel(mp); if (nd->nd_repstat != 0) { vrele(vp); @@ -2134,7 +2134,7 @@ again: nvp->v_type == VDIR && nvp->v_mountedhere != NULL) { new_mp = nvp->v_mountedhere; - r = vfs_busy(new_mp, 0); + r = vfs_busy(new_mp, 0, NULL); vput(nvp); nvp = NULL; if (r == 0) { diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c b/sys/fs/nfsserver/nfs_nfsdserv.c index e6e02d7..39f87c4 100644 --- a/sys/fs/nfsserver/nfs_nfsdserv.c +++ b/sys/fs/nfsserver/nfs_nfsdserv.c @@ -271,7 +271,7 @@ nfsrvd_getattr(struct nfsrv_descript *nd, int isdgram, at_root = 0; } if (nd->nd_repstat == 0) - nd->nd_repstat = vfs_busy(mp, 0); + nd->nd_repstat = vfs_busy(mp, 0, NULL); vfs_rel(mp); if (nd->nd_repstat == 0) { (void)nfsvno_fillattr(nd, mp, vp, &nva, diff --git a/sys/fs/pseudofs/pseudofs_vnops.c b/sys/fs/pseudofs/pseudofs_vnops.c index f00b4b2..a0852ce 100644 --- a/sys/fs/pseudofs/pseudofs_vnops.c +++ b/sys/fs/pseudofs/pseudofs_vnops.c @@ -392,7 +392,7 @@ pfs_vptocnp(struct vop_vptocnp_args *ap) pfs_unlock(pd); mp = vp->v_mount; - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); if (error) return (error); @@ -481,11 +481,11 @@ pfs_lookup(struct vop_cachedlookup_args *va) if (cnp->cn_flags & ISDOTDOT) { if (pd->pn_type == pfstype_root) PFS_RETURN (EIO); - error = vfs_busy(mp, MBF_NOWAIT); + error = vfs_busy(mp, MBF_NOWAIT, NULL); if (error != 0) { vfs_ref(mp); VOP_UNLOCK(vn, 0); - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); vn_lock(vn, LK_EXCLUSIVE | LK_RETRY); vfs_rel(mp); if (error != 0) diff --git a/sys/fs/smbfs/smbfs_vnops.c b/sys/fs/smbfs/smbfs_vnops.c index 8ea1198..e0736fd 100644 --- a/sys/fs/smbfs/smbfs_vnops.c +++ b/sys/fs/smbfs/smbfs_vnops.c @@ -1324,11 +1324,11 @@ smbfs_lookup(ap) } if (flags & ISDOTDOT) { mp = dvp->v_mount; - error = vfs_busy(mp, MBF_NOWAIT); + error = vfs_busy(mp, MBF_NOWAIT, NULL); if (error != 0) { vfs_ref(mp); VOP_UNLOCK(dvp, 0); - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY); vfs_rel(mp); if (error) { diff --git a/sys/fs/tmpfs/tmpfs_vnops.c b/sys/fs/tmpfs/tmpfs_vnops.c index 885f84c..a366170 100644 --- a/sys/fs/tmpfs/tmpfs_vnops.c +++ b/sys/fs/tmpfs/tmpfs_vnops.c @@ -789,7 +789,7 @@ tmpfs_rename(struct vop_rename_args *v) if (fdvp != tdvp && fdvp != tvp) { if (vn_lock(fdvp, LK_EXCLUSIVE | LK_NOWAIT) != 0) { mp = tdvp->v_mount; - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); if (error != 0) { mp = NULL; goto out; diff --git a/sys/geom/journal/g_journal.c b/sys/geom/journal/g_journal.c index 9cc324c..3c2066e 100644 --- a/sys/geom/journal/g_journal.c +++ b/sys/geom/journal/g_journal.c @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -2867,6 +2868,7 @@ g_journal_do_switch(struct g_class *classp) const struct g_journal_desc *desc; struct g_geom *gp; struct mount *mp; + struct rm_priotracker tracker; struct bintime bt; char *mountpoint; int error, save; @@ -2888,7 +2890,7 @@ g_journal_do_switch(struct g_class *classp) g_topology_unlock(); PICKUP_GIANT(); - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); TAILQ_FOREACH(mp, &mountlist, mnt_list) { if (mp->mnt_gjprovider == NULL) continue; @@ -2897,9 +2899,10 @@ g_journal_do_switch(struct g_class *classp) desc = g_journal_find_desc(mp->mnt_stat.f_fstypename); if (desc == NULL) continue; - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) continue; - /* mtx_unlock(&mountlist_mtx) was done inside vfs_busy() */ + /* rm_runlock(&mountlist_lock, &tracker) was done inside + * vfs_busy() */ DROP_GIANT(); g_topology_lock(); @@ -2977,10 +2980,10 @@ g_journal_do_switch(struct g_class *classp) vfs_write_resume(mp, 0); next: - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); vfs_unbusy(mp); } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); sc = NULL; for (;;) { diff --git a/sys/kern/vfs_extattr.c b/sys/kern/vfs_extattr.c index 24935ce..a82eddaf 100644 --- a/sys/kern/vfs_extattr.c +++ b/sys/kern/vfs_extattr.c @@ -104,7 +104,7 @@ sys_extattrctl(td, uap) if (error) goto out; mp = nd.ni_vp->v_mount; - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); if (error) { NDFREE(&nd, 0); mp = NULL; diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c index f2ffab2..610aa5f 100644 --- a/sys/kern/vfs_lookup.c +++ b/sys/kern/vfs_lookup.c @@ -779,7 +779,7 @@ unionlookup: */ while (dp->v_type == VDIR && (mp = dp->v_mountedhere) && (cnp->cn_flags & NOCROSSMOUNT) == 0) { - if (vfs_busy(mp, 0)) + if (vfs_busy(mp, 0, NULL)) continue; vput(dp); if (dp != ndp->ni_dvp) diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c index 09fa7ed..636a55f 100644 --- a/sys/kern/vfs_mount.c +++ b/sys/kern/vfs_mount.c @@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -85,8 +86,8 @@ static uma_zone_t mount_zone; struct mntlist mountlist = TAILQ_HEAD_INITIALIZER(mountlist); /* For any iteration/modification of mountlist */ -struct mtx mountlist_mtx; -MTX_SYSINIT(mountlist, &mountlist_mtx, "mountlist", MTX_DEF); +struct rmlock mountlist_lock; +RM_SYSINIT(mountlist, &mountlist_lock, "mountlist"); /* * Global opts, taken by all filesystems @@ -462,7 +463,7 @@ vfs_mount_alloc(struct vnode *vp, struct vfsconf *vfsp, const char *fspath, TAILQ_INIT(&mp->mnt_activevnodelist); mp->mnt_activevnodelistsize = 0; mp->mnt_ref = 0; - (void) vfs_busy(mp, MBF_NOWAIT); + (void) vfs_busy(mp, MBF_NOWAIT, NULL); atomic_add_acq_int(&vfsp->vfc_refcount, 1); mp->mnt_op = vfsp->vfc_vfsops; mp->mnt_vfc = vfsp; @@ -852,9 +853,9 @@ vfs_domount_first( VI_UNLOCK(vp); vp->v_mountedhere = mp; /* Place the new filesystem at the end of the mount list. */ - mtx_lock(&mountlist_mtx); + rm_wlock(&mountlist_lock); TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); - mtx_unlock(&mountlist_mtx); + rm_wunlock(&mountlist_lock); vfs_event_signal(NULL, VQ_MOUNT, 0); if (VFS_ROOT(mp, LK_EXCLUSIVE, &newdp)) panic("mount: lost mount"); @@ -918,7 +919,7 @@ vfs_domount_update( vput(vp); return (error); } - if (vfs_busy(mp, MBF_NOWAIT)) { + if (vfs_busy(mp, MBF_NOWAIT, NULL)) { vput(vp); return (EBUSY); } @@ -1137,6 +1138,7 @@ sys_unmount(td, uap) { struct nameidata nd; struct mount *mp; + struct rm_priotracker tracker; char *pathbuf; int error, id0, id1; @@ -1161,13 +1163,13 @@ sys_unmount(td, uap) return (EINVAL); } - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); TAILQ_FOREACH_REVERSE(mp, &mountlist, mntlist, mnt_list) { if (mp->mnt_stat.f_fsid.val[0] == id0 && mp->mnt_stat.f_fsid.val[1] == id1) break; } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); } else { /* * Try to find global path for path argument. @@ -1181,12 +1183,12 @@ sys_unmount(td, uap) if (error == 0 || error == ENODEV) vput(nd.ni_vp); } - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); TAILQ_FOREACH_REVERSE(mp, &mountlist, mntlist, mnt_list) { if (strcmp(mp->mnt_stat.f_mntonname, pathbuf) == 0) break; } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); } free(pathbuf, M_TEMP); if (mp == NULL) { @@ -1353,9 +1355,9 @@ dounmount(mp, flags, td) VOP_UNLOCK(coveredvp, 0); return (error); } - mtx_lock(&mountlist_mtx); + rm_wlock(&mountlist_lock); TAILQ_REMOVE(&mountlist, mp, mnt_list); - mtx_unlock(&mountlist_mtx); + rm_wunlock(&mountlist_lock); EVENTHANDLER_INVOKE(vfs_unmounted, mp, td); if (coveredvp != NULL) { coveredvp->v_mountedhere = NULL; diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c index a050099..ef3e9c9 100644 --- a/sys/kern/vfs_mountroot.c +++ b/sys/kern/vfs_mountroot.c @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -231,9 +232,9 @@ vfs_mountroot_devfs(struct thread *td, struct mount **mpp) TAILQ_INIT(opts); mp->mnt_opt = opts; - mtx_lock(&mountlist_mtx); + rm_wlock(&mountlist_lock); TAILQ_INSERT_HEAD(&mountlist, mp, mnt_list); - mtx_unlock(&mountlist_mtx); + rm_wunlock(&mountlist_lock); *mpp = mp; set_rootvnode(); @@ -257,7 +258,7 @@ vfs_mountroot_shuffle(struct thread *td, struct mount *mpdevfs) mpnroot = TAILQ_NEXT(mpdevfs, mnt_list); /* Shuffle the mountlist. */ - mtx_lock(&mountlist_mtx); + rm_wlock(&mountlist_lock); mporoot = TAILQ_FIRST(&mountlist); TAILQ_REMOVE(&mountlist, mpdevfs, mnt_list); if (mporoot != mpdevfs) { @@ -265,7 +266,7 @@ vfs_mountroot_shuffle(struct thread *td, struct mount *mpdevfs) TAILQ_INSERT_HEAD(&mountlist, mpnroot, mnt_list); } TAILQ_INSERT_TAIL(&mountlist, mpdevfs, mnt_list); - mtx_unlock(&mountlist_mtx); + rm_wunlock(&mountlist_lock); cache_purgevfs(mporoot); if (mporoot != mpdevfs) @@ -933,6 +934,7 @@ void vfs_mountroot(void) { struct mount *mp; + struct rm_priotracker tracker; struct sbuf *sb; struct thread *td; time_t timebase; @@ -968,14 +970,14 @@ vfs_mountroot(void) * timestamps we encounter. */ timebase = 0; - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); mp = TAILQ_FIRST(&mountlist); while (mp != NULL) { if (mp->mnt_time > timebase) timebase = mp->mnt_time; mp = TAILQ_NEXT(mp, mnt_list); } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); inittodr(timebase); /* Keep prison0's root in sync with the global rootvnode. */ diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index fda80c9..3733178 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -68,6 +68,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -375,7 +376,7 @@ SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_FIRST, vntblinit, NULL); /* * Mark a mount point as busy. Used to synchronize access and to delay - * unmounting. Eventually, mountlist_mtx is not released on failure. + * unmounting. Eventually, mountlist_lock is not released on failure. * * vfs_busy() is a custom lock, it can block the caller. * vfs_busy() only sleeps if the unmount is active on the mount point. @@ -410,7 +411,7 @@ SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_FIRST, vntblinit, NULL); * dounmount() locks B while F is drained. */ int -vfs_busy(struct mount *mp, int flags) +vfs_busy(struct mount *mp, int flags, struct rm_priotracker *tracker) { MPASS((flags & ~MBF_MASK) == 0); @@ -439,15 +440,15 @@ vfs_busy(struct mount *mp, int flags) return (ENOENT); } if (flags & MBF_MNTLSTLOCK) - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, tracker); mp->mnt_kern_flag |= MNTK_MWAIT; msleep(mp, MNT_MTX(mp), PVFS | PDROP, "vfs_busy", 0); if (flags & MBF_MNTLSTLOCK) - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, tracker); MNT_ILOCK(mp); } if (flags & MBF_MNTLSTLOCK) - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, tracker); mp->mnt_lockref++; MNT_IUNLOCK(mp); return (0); @@ -481,18 +482,19 @@ struct mount * vfs_getvfs(fsid_t *fsid) { struct mount *mp; + struct rm_priotracker tracker; CTR2(KTR_VFS, "%s: fsid %p", __func__, fsid); - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); TAILQ_FOREACH(mp, &mountlist, mnt_list) { if (mp->mnt_stat.f_fsid.val[0] == fsid->val[0] && mp->mnt_stat.f_fsid.val[1] == fsid->val[1]) { vfs_ref(mp); - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); return (mp); } } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); CTR2(KTR_VFS, "%s: lookup failed for %p id", __func__, fsid); return ((struct mount *) 0); } @@ -501,7 +503,7 @@ vfs_getvfs(fsid_t *fsid) * Lookup a mount point by filesystem identifier, busying it before * returning. * - * To avoid congestion on mountlist_mtx, implement simple direct-mapped + * To avoid congestion on mountlist_lock, implement simple direct-mapped * cache for popular filesystem identifiers. The cache is lockess, using * the fact that struct mount's are never freed. In worst case we may * get pointer to unmounted or even different filesystem, so we have to @@ -514,6 +516,7 @@ vfs_busyfs(fsid_t *fsid) typedef struct mount * volatile vmp_t; static vmp_t cache[FSID_CACHE_SIZE]; struct mount *mp; + struct rm_priotracker tracker; int error; uint32_t hash; @@ -525,7 +528,7 @@ vfs_busyfs(fsid_t *fsid) mp->mnt_stat.f_fsid.val[0] != fsid->val[0] || mp->mnt_stat.f_fsid.val[1] != fsid->val[1]) goto slow; - if (vfs_busy(mp, 0) != 0) { + if (vfs_busy(mp, 0, NULL) != 0) { cache[hash] = NULL; goto slow; } @@ -536,14 +539,14 @@ vfs_busyfs(fsid_t *fsid) vfs_unbusy(mp); slow: - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); TAILQ_FOREACH(mp, &mountlist, mnt_list) { if (mp->mnt_stat.f_fsid.val[0] == fsid->val[0] && mp->mnt_stat.f_fsid.val[1] == fsid->val[1]) { - error = vfs_busy(mp, MBF_MNTLSTLOCK); + error = vfs_busy(mp, MBF_MNTLSTLOCK, &tracker); if (error) { cache[hash] = NULL; - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); return (NULL); } cache[hash] = mp; @@ -551,7 +554,7 @@ slow: } } CTR2(KTR_VFS, "%s: lookup failed for %p id", __func__, fsid); - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); return ((struct mount *) 0); } @@ -891,6 +894,7 @@ vnlru_proc(void) struct mount *mp, *nmp; int done; struct proc *p = vnlruproc; + struct rm_priotracker tracker; EVENTHANDLER_REGISTER(shutdown_pre_sync, kproc_shutdown, p, SHUTDOWN_PRI_FIRST); @@ -909,18 +913,18 @@ vnlru_proc(void) } mtx_unlock(&vnode_free_list_mtx); done = 0; - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) { + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) { nmp = TAILQ_NEXT(mp, mnt_list); continue; } done += vlrureclaim(mp); - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); nmp = TAILQ_NEXT(mp, mnt_list); vfs_unbusy(mp); } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); if (done == 0) { #if 0 /* These messages are temporary debugging aids */ @@ -3397,6 +3401,7 @@ sysctl_vnode(SYSCTL_HANDLER_ARGS) struct xvnode *xvn; struct mount *mp; struct vnode *vp; + struct rm_priotracker tracker; int error, len, n; /* @@ -3413,9 +3418,9 @@ sysctl_vnode(SYSCTL_HANDLER_ARGS) return (error); xvn = malloc(len, M_TEMP, M_ZERO | M_WAITOK); n = 0; - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); TAILQ_FOREACH(mp, &mountlist, mnt_list) { - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) continue; MNT_ILOCK(mp); TAILQ_FOREACH(vp, &mp->mnt_nvnodelist, v_nmntvnodes) { @@ -3465,12 +3470,12 @@ sysctl_vnode(SYSCTL_HANDLER_ARGS) ++n; } MNT_IUNLOCK(mp); - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); vfs_unbusy(mp); if (n == len) break; } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); error = SYSCTL_OUT(req, xvn, n * sizeof *xvn); free(xvn, M_TEMP); @@ -3760,7 +3765,7 @@ sync_fsync(struct vop_fsync_args *ap) * Walk the list of vnodes pushing all that are dirty and * not already on the sync list. */ - if (vfs_busy(mp, MBF_NOWAIT) != 0) + if (vfs_busy(mp, MBF_NOWAIT, NULL) != 0) return (0); if (vn_start_write(NULL, &mp, V_NOWAIT) != 0) { vfs_unbusy(mp); diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 14be379..0d3ae31 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -60,6 +60,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -129,11 +130,12 @@ sys_sync(td, uap) struct sync_args *uap; { struct mount *mp, *nmp; + struct rm_priotracker tracker; int save; - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) { + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) { nmp = TAILQ_NEXT(mp, mnt_list); continue; } @@ -145,11 +147,11 @@ sys_sync(td, uap) curthread_pflags_restore(save); vn_finished_write(mp); } - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); nmp = TAILQ_NEXT(mp, mnt_list); vfs_unbusy(mp); } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); return (0); } @@ -190,7 +192,7 @@ sys_quotactl(td, uap) mp = nd.ni_vp->v_mount; vfs_ref(mp); vput(nd.ni_vp); - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); vfs_rel(mp); if (error != 0) return (error); @@ -297,7 +299,7 @@ kern_statfs(struct thread *td, char *path, enum uio_seg pathseg, vfs_ref(mp); NDFREE(&nd, NDF_ONLY_PNBUF); vput(nd.ni_vp); - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); vfs_rel(mp); if (error != 0) return (error); @@ -383,7 +385,7 @@ kern_fstatfs(struct thread *td, int fd, struct statfs *buf) error = EBADF; goto out; } - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); vfs_rel(mp); if (error != 0) return (error); @@ -449,6 +451,7 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, enum uio_seg bufseg, int flags) { struct mount *mp, *nmp; + struct rm_priotracker tracker; struct statfs *sfsp, *sp, sb; size_t count, maxcount; int error; @@ -460,18 +463,18 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, sfsp = *buf; else /* if (bufseg == UIO_SYSSPACE) */ { count = 0; - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); TAILQ_FOREACH(mp, &mountlist, mnt_list) { count++; } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); if (maxcount > count) maxcount = count; sfsp = *buf = malloc(maxcount * sizeof(struct statfs), M_TEMP, M_WAITOK); } count = 0; - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { if (prison_canseemount(td->td_ucred, mp) != 0) { nmp = TAILQ_NEXT(mp, mnt_list); @@ -483,7 +486,7 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, continue; } #endif - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) { + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) { nmp = TAILQ_NEXT(mp, mnt_list); continue; } @@ -504,7 +507,7 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, if (((flags & (MNT_LAZY|MNT_NOWAIT)) == 0 || (flags & MNT_WAIT)) && (error = VFS_STATFS(mp, sp))) { - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); nmp = TAILQ_NEXT(mp, mnt_list); vfs_unbusy(mp); continue; @@ -527,11 +530,11 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, sfsp++; } count++; - mtx_lock(&mountlist_mtx); + rm_rlock(&mountlist_lock, &tracker); nmp = TAILQ_NEXT(mp, mnt_list); vfs_unbusy(mp); } - mtx_unlock(&mountlist_mtx); + rm_runlock(&mountlist_lock, &tracker); if (sfsp && count > maxcount) td->td_retval[0] = maxcount; else @@ -741,7 +744,7 @@ sys_fchdir(td, uap) AUDIT_ARG_VNODE1(vp); error = change_dir(vp, td); while (!error && (mp = vp->v_mountedhere) != NULL) { - if (vfs_busy(mp, 0)) + if (vfs_busy(mp, 0, NULL)) continue; error = VFS_ROOT(mp, LK_SHARED, &tdp); vfs_unbusy(mp); diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index ed4ad4d..8d38305 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -2059,11 +2059,11 @@ vn_vget_ino_gen(struct vnode *vp, vn_get_ino_t alloc, void *alloc_arg, ltype = VOP_ISLOCKED(vp); KASSERT(ltype == LK_EXCLUSIVE || ltype == LK_SHARED, ("vn_vget_ino: vp not locked")); - error = vfs_busy(mp, MBF_NOWAIT); + error = vfs_busy(mp, MBF_NOWAIT, NULL); if (error != 0) { vfs_ref(mp); VOP_UNLOCK(vp, 0); - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); vn_lock(vp, ltype | LK_RETRY); vfs_rel(mp); if (error != 0) diff --git a/sys/sys/mount.h b/sys/sys/mount.h index 6fb2d08..6c47d7f 100644 --- a/sys/sys/mount.h +++ b/sys/sys/mount.h @@ -38,7 +38,9 @@ #ifdef _KERNEL #include #include +#include #include +#include #include #endif @@ -147,7 +149,7 @@ struct vfsopt { * put on a doubly linked list. * * Lock reference: - * m - mountlist_mtx + * m - mountlist_lock * i - interlock * v - vnode freelist mutex * @@ -864,7 +866,7 @@ int vfs_setopts(struct vfsoptlist *opts, const char *name, int vfs_setpublicfs /* set publicly exported fs */ (struct mount *, struct netexport *, struct export_args *); void vfs_msync(struct mount *, int); -int vfs_busy(struct mount *, int); +int vfs_busy(struct mount *, int, struct rm_priotracker *); int vfs_export /* process mount export info */ (struct mount *, struct export_args *); void vfs_allocate_syncvnode(struct mount *); @@ -890,7 +892,7 @@ int vfs_suser(struct mount *, struct thread *); void vfs_unbusy(struct mount *); void vfs_unmountall(void); extern TAILQ_HEAD(mntlist, mount) mountlist; /* mounted filesystem list */ -extern struct mtx mountlist_mtx; +extern struct rmlock mountlist_lock; extern struct nfs_public nfs_pub; extern struct sx vfsconf_sx; #define vfsconf_lock() sx_xlock(&vfsconf_sx) diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c index 700854e..8545df0 100644 --- a/sys/ufs/ffs/ffs_softdep.c +++ b/sys/ufs/ffs/ffs_softdep.c @@ -12274,11 +12274,11 @@ restart: FREE_LOCK(ump); if (ffs_vgetf(mp, parentino, LK_NOWAIT | LK_EXCLUSIVE, &pvp, FFSV_FORCEINSMQ)) { - error = vfs_busy(mp, MBF_NOWAIT); + error = vfs_busy(mp, MBF_NOWAIT, NULL); if (error != 0) { vfs_ref(mp); VOP_UNLOCK(vp, 0); - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); vfs_rel(mp); if (error != 0) @@ -13427,7 +13427,7 @@ clear_remove(mp) /* * Let unmount clear deps */ - error = vfs_busy(mp, MBF_NOWAIT); + error = vfs_busy(mp, MBF_NOWAIT, NULL); if (error != 0) goto finish_write; error = ffs_vgetf(mp, ino, LK_EXCLUSIVE, &vp, @@ -13503,7 +13503,7 @@ clear_inodedeps(mp) if (vn_start_write(NULL, &mp, V_NOWAIT) != 0) continue; FREE_LOCK(ump); - error = vfs_busy(mp, MBF_NOWAIT); /* Let unmount clear deps */ + error = vfs_busy(mp, MBF_NOWAIT, NULL); /* Let unmount clear deps */ if (error != 0) { vn_finished_write(mp); ACQUIRE_LOCK(ump); diff --git a/sys/ufs/ffs/ffs_suspend.c b/sys/ufs/ffs/ffs_suspend.c index b50fadc..6513a21 100644 --- a/sys/ufs/ffs/ffs_suspend.c +++ b/sys/ufs/ffs/ffs_suspend.c @@ -286,7 +286,7 @@ ffs_susp_ioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flags, error = ENOENT; break; } - error = vfs_busy(mp, 0); + error = vfs_busy(mp, 0, NULL); vfs_rel(mp); if (error != 0) break; diff --git a/sys/ufs/ufs/ufs_quota.c b/sys/ufs/ufs/ufs_quota.c index 4fbb8a1..3d17622 100644 --- a/sys/ufs/ufs/ufs_quota.c +++ b/sys/ufs/ufs/ufs_quota.c @@ -519,7 +519,7 @@ quotaon(struct thread *td, struct mount *mp, int type, void *fname) } NDFREE(&nd, NDF_ONLY_PNBUF); vp = nd.ni_vp; - error = vfs_busy(mp, MBF_NOWAIT); + error = vfs_busy(mp, MBF_NOWAIT, NULL); vfs_rel(mp); if (error == 0) { if (vp->v_type != VREG) { -- 2.1.2 > The rmlock primitive does exactly this optimization. See the manpage > for the API (it's mostly very similar to the rwlock API): > https://www.freebsd.org/cgi/man.cgi?query=rmlock&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html > > > > void zfs_mountlist_wlock(void); > > void zfs_mountlist_wunlock(void); > > void zfs_mountlist_rlock(void); > > void zfs_mountlist_runlock(void); > > Why not: > > #define zfs_mountlist_wlock() _zfs_mountlist_wlock(__FILE__, __LINE__) > void _zfs_mountlist_wlock(const char *file, int line); > > /* etc, etc */ > > (This may be moot if we switch to an rmlock though) Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 13:37:53 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4300DFDF for ; Thu, 12 Mar 2015 13:37:53 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B94BA19 for ; Thu, 12 Mar 2015 13:37:53 +0000 (UTC) Received: by ieclw3 with SMTP id lw3so39966954iec.2 for ; Thu, 12 Mar 2015 06:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=APUeguMX0pRs79TFA/8atDN1ytPV28GkO3+htrGF7HI=; b=sD2xp1TNLei+RZ32Rm1uKaBSZSBtcRt0skjiAY+4DUFsrSSID1mWfPrvLHhyJBEpa2 NeQ9fTxI2UXh4XzoXGtdOhYTcfHzpPM2YFOFCr3xFrlls3N9VvAMIBBh/x02nrvngAdh QjW5yAPy0T4oRzzB2TvDyGVvY9ulX9thHQEdhzbQbaDhylhzZu8j64BnkX5s2Ic3kCSt DT7dCvbyi9K8RairQx1mmvMHmTZz575NbMh+JFY/FboTITWf+cNyUGeM06AM7nCa/L9O m99/QVONwbnFtamJ0HnhRTe7q1xaaGWsL5+pC2UAQBrNFUTNzFpgGyzF9vUJqucgkx3J OMCg== X-Received: by 10.107.148.197 with SMTP id w188mr74785705iod.73.1426167459707; Thu, 12 Mar 2015 06:37:39 -0700 (PDT) Received: from [172.22.132.60] ([192.119.231.58]) by mx.google.com with ESMTPSA id y6sm76560igw.21.2015.03.12.06.37.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 06:37:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: file system change notifications From: Guy Helmer In-Reply-To: <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au> Date: Thu, 12 Mar 2015 08:37:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5786089D-414D-485C-B675-35B5A62C5950@gmail.com> References: <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au> To: "O'Connor, Daniel" X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 13:37:53 -0000 On Mar 11, 2015, at 5:46 PM, O'Connor, Daniel = wrote: >=20 >=20 >> On 12 Mar 2015, at 05:31, Kim Shrier wrote: >> I have a project where I need to notice changes to files in a large = directory tree. >> I noticed that there was a project in GSOC 2010 to implement such a = feature. >>=20 >> https://wiki.freebsd.org/SOC2010IlyaPutsikau=20 >>=20 >> It appears that it was never completed. Is it desirable to have this = project >> completed and added into FreeBSD. Or, is there another way to get = file >> system change notifications? >=20 > The 'standard' way is kqueue + masses of file descriptors. >=20 > I am looking at using auditpipe(4) since you can register to be = notified for all file modifications and you get a path. >=20 > I wrote some test code at = https://gist.github.com/DanielO/e36de242e79fed3fe4f7 >=20 > Ideally we could add an inotify() syscall although I think that is = still suboptimal since you need to add a watch per directory so it can = be relatively expensive to setup. That said working out what to do in = the face of links and so on is tricky.. How are Darwin (OS X) fsevents implemented? It=E2=80=99s a been a handy = interface for some of my work. Guy From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 14:14:38 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23962AD7 for ; Thu, 12 Mar 2015 14:14:38 +0000 (UTC) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4D20E86 for ; Thu, 12 Mar 2015 14:14:37 +0000 (UTC) Received: by iecsl2 with SMTP id sl2so41473589iec.1 for ; Thu, 12 Mar 2015 07:14:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SbTeJaD79UTwTOX2lD/t+enRWmuhMqWfXZNDy2HsmRc=; b=LENhgEkPP0gSjQy3Zlbu6YXXGBY0K59jOQ6rSMaYol8Cgyt41anYFt0enSMVCaX59A X5VutTvtyaV9NPu//VN24HLZZ5zOlFzlH0/zUntsBjRFdRyttPFbHlpYMFEnoZvHXnYw A1GIYtXIVebeJfL4hxmSQF3dC+BSSo7A2O0cZ2FsqJl9Uk8eymcJjqPwGwrSFf4/nItU nYsjSwn4152ZFVdF4mTDoVgjN4KuK0LU2gtCUo8eZG5CgMzxI1hLapmhXjyYEn7cqv8G rzb5QZCXMw5Yf7rJLtGrFxnA/9SemmOCY8uzsw+n065sfI9rbVpW2Mhw6A2YF0rU2qVr 1hwA== X-Gm-Message-State: ALoCoQntm/46vWrh+TIEPS4wAfrqqpoecOnN2pxkUogGQgdgphB5Nazf0qOXjHh7cuNsWte/dWib MIME-Version: 1.0 X-Received: by 10.50.20.228 with SMTP id q4mr53962791ige.1.1426169668795; Thu, 12 Mar 2015 07:14:28 -0700 (PDT) Received: by 10.36.46.7 with HTTP; Thu, 12 Mar 2015 07:14:28 -0700 (PDT) Date: Thu, 12 Mar 2015 10:14:28 -0400 Message-ID: Subject: GSOC Project Proposal: Unifying ping & ping6 From: Pankaj Moolrajani To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:14:38 -0000 Hi, I am intersted in unifying ping & ping6 this year for GSOC. I have experience in working with c++, networking, implementing trace route, ping and other protocols in python. I would like to work on ping6 & ping and also on traceroute & traceroute6 unification as suggested by Mark Martinec < Mark.Martinec@ijs.si>. Mark mentioned that a mentor is not yet decided for this unification, and hence to contact you for the same. Let me know the further process because I am new to GSOC. And, moreover if there is something I need to read before starting off this work, kindly lemme know know. About Me: I am a grad student at NYU studying Cyber Security and interested in working on open source projects for next few years. Also have experience as linux administrator, and development engineer. Thanks Pankaj From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 14:38:22 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 037965F2; Thu, 12 Mar 2015 14:38:22 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 833B7194; Thu, 12 Mar 2015 14:38:21 +0000 (UTC) Received: by wggz12 with SMTP id z12so16904679wgg.0; Thu, 12 Mar 2015 07:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=T/OEO+HYI0QKt2AfYVuj6B/9LA6jMprWL6f5N0gJRF4=; b=ufouSQX7HYPEZHjjfuP1KcnGvltw1cdN9Ob0EJ3MDZwt13i2Ufx8yi551IMCKZVwGj B52/yUa857ZFKL0qfbR9plusWYSGgZL+64d+oyRcWyo4trYPMhull5S/fe6BldCauGlc hGxCYnctUP+UvZavAXPSsr8qqkhM9l9fU0FCWKW0IE62lc5fsKtOkZVZEnPPjDGDhp/J IHTmRSnkeu/wJg2aP5tlAH7GXEpTPhc7lZ6MlA6ahtf8c06/zRWaqcVeLq3IicsXEvoR ++Gmqfec0j5JnQbpGCm2CsuGjt00topA1JF+MXTVS2T732o1eihezfdgZtPM6OHU9NO9 iJjw== X-Received: by 10.180.80.199 with SMTP id t7mr14409305wix.52.1426171099201; Thu, 12 Mar 2015 07:38:19 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id n1sm29674184wib.11.2015.03.12.07.38.17 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 12 Mar 2015 07:38:17 -0700 (PDT) Date: Thu, 12 Mar 2015 15:38:15 +0100 From: Mateusz Guzik To: Don Lewis Subject: Re: file system change notifications Message-ID: <20150312143814.GA9153@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Don Lewis , oliver.pinter@hardenedbsd.org, int0dster@gmail.com, freebsd-hackers@FreeBSD.org, shawn.webb@hardenedbsd.org References: <20150311224831.GB18699@dft-labs.eu> <201503112318.t2BNIboU092815@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201503112318.t2BNIboU092815@gw.catspoiler.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, int0dster@gmail.com, oliver.pinter@hardenedbsd.org, shawn.webb@hardenedbsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:38:22 -0000 On Wed, Mar 11, 2015 at 04:18:37PM -0700, Don Lewis wrote: > On 11 Mar, Mateusz Guzik wrote: > > On Wed, Mar 11, 2015 at 11:11:14PM +0100, Oliver Pinter wrote: > >> Take a look at dazuko kernel module. Probably you should forward port > >> them, because they are obsoleted. > >> > > > > I checked the module out of curiosity. Their approach was to wrap various > > syscalls and work from there. This is used to be the common approach > > several years back it has a lot of shortcomings, complete lack of > > reliability being the biggest one. > > > > As for better implementation: current namecache does not guarantee name > > resolution (even if name was entered) and not all names end up in the > > cache in the first place. > > > > Lack of reliability comes from the fact that the cache does not pin > > vnodes in any way. > > I seem to recall reading a long time ago that DragonFly pins directories > in the cache, or something like that. > Just refing is quite insufficient and may not work at all. Due to hardlinks files can have more than one name. So preferably we would stop tossing vnodes around and create an intermediate object which would keep name component and a pointer to an inode. And that's what we would keep in struct file. Then a namecache would just be a hash of such objects. That's quite a lot of work though and unfortunately is likely too complicated for gsoc. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 14:45:12 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40A4975D; Thu, 12 Mar 2015 14:45:12 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C51B12AA; Thu, 12 Mar 2015 14:45:11 +0000 (UTC) Received: by wevk48 with SMTP id k48so16849355wev.7; Thu, 12 Mar 2015 07:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=sljVJZgwb2Q1vWlTe0FKEf8uIPW/ZSSOC9xNsDgrTvI=; b=n4Q1F4+AdCGxJkWGbvv08ZdX9ZC4PKFtoK4XUMhcSTaHyGnw/Oa8T+zGHl4YtX8m11 7BkxtlGJ0A4XR/v9xfoYrSxoOG58TqbZ0noIpsDDJ/ZJWU4jxHgb7o9tZKk61WIb1Ern ewHtcu8oYbAd3fzNCTyKDPO2a8EXt8C8wONt2qE7ojyGPOQXapM1PCnrrlzCmxRgoytc DVB/3zxO+bwSCaxxJOddF8AWsxIWmNqVuya/SE1UJ4l5X0uE8vgNcFgUxJlk4oAxLSkz 0fISG5NaOkMz/voH8mdrOTCZMMH4eQ5dqu9+8ZergkNPewv8nc9Q3SaBEO0XVGx/AS0l swBQ== X-Received: by 10.180.107.71 with SMTP id ha7mr132800903wib.23.1426171510227; Thu, 12 Mar 2015 07:45:10 -0700 (PDT) Received: from localhost ([217.14.212.217]) by mx.google.com with ESMTPSA id w8sm10386013wja.4.2015.03.12.07.45.09 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 12 Mar 2015 07:45:09 -0700 (PDT) Date: Thu, 12 Mar 2015 15:45:03 +0100 From: To: "Ilya A. Arkhipov" , hackers@freebsd.org, "eadler@FreeBSD.org" , "bapt@FreeBSD.org" , "danfe@FreeBSD.org" Subject: Re: STDIN of dialog4ports Message-ID: <20150312154503.00003c47@gmail.com> In-Reply-To: <9928461426161287@web22o.yandex.ru> References: <20150312054510.000067f4@gmail.com> <9928461426161287@web22o.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:45:12 -0000 Thanks Ilya, Well, better you patch it as you already know the layout of dialog4ports's code, as you've been main dev and you know where to start patching. I believe it's a little change which would cost you only hour or few. ;) + you are way more experienced in C then I (I did it only for about 4 months) Just throw a patch and I'll gladly test it. (added hackers@) Domagoj Smol=C4=8Di=C4=87 On Thu, 12 Mar 2015 14:54:47 +0300 Ilya A. Arkhipov wrote: > Yes, now dialog4ports can't to get from STDIN any data. > But if you want you(or maybe I) can prepare patch for that ^_^ >=20 > 12.03.2015, 07:45, "rank1seeker@gmail.com" : > > Hi! > > > > I'm contacting you because you have developed dialog4ports and I'll > > try to be very short in my request. > > > > GOAL: File "/var/db/ports/$PORT/options" being created via 'make > > config' as it is when ENTER is pressed as soon as dialog was > > displayed. > > > > Before 9.0 my solution was: > > When in port's dir (DOESN'T have "/var/db/ports/$PORT/options" file > > set =3D> doesn't exists yet) -- > > # make config << MyEND > > o > > MyEND > > -- > > Additionally, I avoided dialog being displayed by sending it > > to /dev/null. Once "/var/db/ports/$PORT/options" is created, task > > is done =3D> NO build, install, etc ... > > > > Now as I understand, change to "raw" mode type of dialog4ports's > > STDIN, which differs from pipe's buffered mode, makes me unable to > > pipe ENTER (\n) to dialog > > > > Now I'm forced to use lang/expect which is overhead and very slow! > > > > Thanks in advance. > > > > Domagoj Smol=C4=8Di=C4=87 >=20 From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 15:09:36 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EAD6362 for ; Thu, 12 Mar 2015 15:09:36 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAB47797 for ; Thu, 12 Mar 2015 15:09:35 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E2452B941; Thu, 12 Mar 2015 11:09:32 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: [Rebuild Kernel] Part of the kernel functions are not recompiled when rebuilding the kernel Date: Thu, 12 Mar 2015 10:57 -0400 Message-ID: <2868982.gUMQ0OnoyR@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Mar 2015 11:09:33 -0400 (EDT) Cc: Yue Chen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 15:09:36 -0000 On Monday, March 09, 2015 04:18:07 PM Yue Chen wrote: > Hi all, > > When I used my customized LLVM (insert some instructions after each basic > block) to rebuild the 10.1-RELEASE kernel, I found that about 10% of the > kernel functions (in a continuous address range, in "objdump -S kernel", > about 79%-88%) are not recompiled with my LLVM (does not have the feature > of my customized LLVM). For example, these functions: > > calc_rebuild_progress > ID_TO_VDEV > ldm_spinup_vdev > hpt27xx_ldm_suspend > ldm_start_rebuild > hptnr_ldm_acquire_lock > __ldm_finish_cmd > > I believe the rebuilding process would do a CLEAN first. Maybe something is > wrong with my building process? I followed the instructions here: > https://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html > > Or these functions are in kernel modules that are statically linked? Some drivers ship with pre-compiled .o files provided by external vendors and not the source. Several hpt drivers are this way, so I suspect that is what you are running into. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 16:24:09 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC648CCB for ; Thu, 12 Mar 2015 16:24:09 +0000 (UTC) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B699B211 for ; Thu, 12 Mar 2015 16:24:09 +0000 (UTC) X-ASG-Debug-ID: 1426177447-08ca04364f1df6f0002-P5m3U7 Received: from [172.20.10.2] (74.sub-70-211-65.myvzw.com [70.211.65.74]) by barracuda.ixsystems.com with ESMTP id ievEGQzXATfdUdlr (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 09:24:08 -0700 (PDT) X-Barracuda-Envelope-From: jkh@mail.turbofuzz.com X-Barracuda-AUTH-User: jkh@ixsystems.com X-Barracuda-Apparent-Source-IP: 70.211.65.74 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\)) Subject: Re: file system change notifications From: Jordan Hubbard X-ASG-Orig-Subj: Re: file system change notifications In-Reply-To: <5786089D-414D-485C-B675-35B5A62C5950@gmail.com> Date: Thu, 12 Mar 2015 09:24:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85EE0305-5D79-4C66-A6F4-05219655DAD5@mail.turbofuzz.com> References: <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au> <5786089D-414D-485C-B675-35B5A62C5950@gmail.com> To: Guy Helmer X-Mailer: Apple Mail (2.2087) X-Barracuda-Connect: 74.sub-70-211-65.myvzw.com[70.211.65.74] X-Barracuda-Start-Time: 1426177448 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.16568 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: FreeBSD Hackers , "O'Connor, Daniel" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 16:24:09 -0000 > On Mar 12, 2015, at 6:37 AM, Guy Helmer wrote: >=20 > How are Darwin (OS X) fsevents implemented? It=E2=80=99s a been a = handy interface for some of my work. They have their own tap from the kernel and their own daemon (fseventsd) = to handle coalescing and a publish/subscribe model that will feed = multiple consumers without duplicating or losing events (I haven=E2=80=99t= looked deeply into the implementation, but presumably all the cache = management is there as well so that memory consumption can be kept = manageable. Maybe someone should keep a list of =E2=80=9COS X features we would = really like in FreeBSD=E2=80=9D (add purgeable memory and memory = pressure bands to that list while you=E2=80=99re at it) and parcel them = out as GSoC projects. :-) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 15:22:22 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17E18A9A for ; Thu, 12 Mar 2015 15:22:22 +0000 (UTC) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C26096A for ; Thu, 12 Mar 2015 15:22:21 +0000 (UTC) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id D4086FB8B8 for ; Thu, 12 Mar 2015 16:22:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id fVPgAZy4AAJX for ; Thu, 12 Mar 2015 16:22:17 +0100 (CET) X-Originating-IP: 213.21.93.252 Received: from [192.168.1.2] (213-21-93-252.customer.t3.se [213.21.93.252]) (Authenticated sender: public@beloved.name) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 3BE40FB887 for ; Thu, 12 Mar 2015 16:22:17 +0100 (CET) Message-ID: <5501AF66.808@beloved.name> Date: Thu, 12 Mar 2015 16:23:18 +0100 From: David Englund User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org Subject: FreeBSD package request for icecat References: <1426166013.2314.26.camel@thinkpad> In-Reply-To: <1426166013.2314.26.camel@thinkpad> X-Forwarded-Message-Id: <1426166013.2314.26.camel@thinkpad> X-Mailman-Approved-At: Thu, 12 Mar 2015 16:29:48 +0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 15:22:22 -0000 A few days ago IceCat 31.5.0 was released. Its the latest stable version and the first version with multiple OS support: GNU/Linux, Android, OS X, and Windows. However, currently there's no support for FreeBSD (or any other BSD variants for that matter). Would any BSD packager have interest in porting a working IceCat 31.5.0 version to FreeBSD? "GNUzilla is the GNU version of the Mozilla suite, and GNU IceCat is the GNU version of the Firefox browser. Its main advantage is an ethical one: it is entirely free software . While the Firefox source code from the Mozilla project is free software, they distribute and recommend non-free software as plug-ins and addons. Also their trademark license restricts distribution in several ways incompatible with freedom 0." - Please read http://gnuzilla.gnu.org for more information about IceCat. If you reply please send a CC to bug-gnuzilla@gnu.org mailing list. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 18:39:33 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9278DA2; Thu, 12 Mar 2015 18:39:33 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D67F766; Thu, 12 Mar 2015 18:39:33 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2CIdOql021847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 12 Mar 2015 11:39:25 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5501DD57.7030305@freebsd.org> Date: Thu, 12 Mar 2015 11:39:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michael Fuckner , Oliver Pinter , Adrian Chadd Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> In-Reply-To: <55015D3B.6030605@fuckner.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 18:39:33 -0000 On 3/12/15 2:32 AM, Michael Fuckner wrote: > On 03/11/2015 08:13 PM, Julian Elischer wrote: >> On 3/11/15 8:39 AM, Oliver Pinter wrote: >>> On Wed, Mar 11, 2015 at 4:26 PM, Adrian Chadd >>> wrote: >>>> Hm, have you tried with just one TB of RAM? I haven't had access to >>>> systems with 3TB of RAM - I'm just about to get 1TB in a box. :) >>>> >>>> Hm, other hackers - what's the current size of the AMD64 direct map? >>> 4TB - >>> https://github.com/freebsd/freebsd/blob/master/sys/amd64/include/vmparam.h#L157 >>> >>> >> >> yeah but since direct-map is, well, directly mapped, you might have >> 3TB >> of ram but it might be spread over a larger range. >> there may be holes in it.. it would be worth knowing the apparent >> layout of the ram. > is it this you are looking for (from OpenSUSE 13.2)? > > > http://dedi3.fuckner.net/~molli123/temp/dmesg.smp.disabled.txt > http://dedi3.fuckner.net/~molli123/temp/dmesg-s4l_opensuse13.2.txt > > > [ 0.000000] e820: BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: [mem > 0x0000000000000000-0x00000000000997ff] usable > [ 0.000000] BIOS-e820: [mem > 0x0000000000099800-0x000000000009ffff] reserved > [ 0.000000] BIOS-e820: [mem > 0x00000000000e0000-0x00000000000fffff] reserved > [ 0.000000] BIOS-e820: [mem > 0x0000000000100000-0x00000000784affff] usable > [ 0.000000] BIOS-e820: [mem > 0x00000000784b0000-0x0000000078c63fff] reserved > [ 0.000000] BIOS-e820: [mem > 0x0000000078c64000-0x0000000078ca6fff] ACPI data > [ 0.000000] BIOS-e820: [mem > 0x0000000078ca7000-0x000000007a268fff] ACPI NVS > [ 0.000000] BIOS-e820: [mem > 0x000000007a269000-0x000000007bdc3fff] reserved > [ 0.000000] BIOS-e820: [mem > 0x000000007bdc4000-0x000000007bdc4fff] usable > [ 0.000000] BIOS-e820: [mem > 0x000000007bdc5000-0x000000007be4afff] reserved > [ 0.000000] BIOS-e820: [mem > 0x000000007be4b000-0x000000007bffffff] usable > [ 0.000000] BIOS-e820: [mem > 0x0000000080000000-0x000000008fffffff] reserved > [ 0.000000] BIOS-e820: [mem > 0x00000000fed1c000-0x00000000fed1ffff] reserved > [ 0.000000] BIOS-e820: [mem > 0x00000000ff000000-0x00000000ffffffff] reserved > [ 0.000000] BIOS-e820: [mem > 0x0000000100000000-0x000003007fffffff] usable > ok, it looks like it is in one big chunk.. so that is not an issue. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 18:47:53 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3388518C for ; Thu, 12 Mar 2015 18:47:53 +0000 (UTC) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B580186F for ; Thu, 12 Mar 2015 18:47:51 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBE7D2.dip0.t-ipconnect.de [93.203.231.210]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t2CHx12n083661; Thu, 12 Mar 2015 18:59:01 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t2CHt8r1033784; Thu, 12 Mar 2015 18:55:09 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t2CHscnQ092956; Thu, 12 Mar 2015 18:54:57 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201503121754.t2CHscnQ092956@fire.js.berklix.net> To: Matt Tagg Subject: Re: find with -delete option on absolute paths From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 10 Mar 2015 20:31:52 -0700." Date: Thu, 12 Mar 2015 18:54:38 +0100 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 18:47:53 -0000 Matt Tagg wrote: > Hey BSD folks > > I believe this was discussed previously (2013), though I could not > find a resolution. > > To recap, suppose we try deleting files on an absolute path: > > matt@mtbook:/% find /tmp/foo/* -delete > find: -delete: /tmp/foo/bar.txt: relative path potentially not safe > > As you can see it gives an error and quits. However if we instead try this: > > matt@mtbook:/% gfind /tmp/foo/* -delete > > GNU Find throws no error and works as expected ('bar.txt is deleted') > > So as an end user, I find this rather confusing. How can I get the > same behavior with BSD Find out of the box? Off on a tangent: Last millenia (1987 :-) when I was using find & needed an rm to reduce near duplicate trees on DOS & Unix, I wrote my own C http://berklix.com/~jhs/src/bsd/jhs/bin/public/cmpd/ I've never since worried about getting syntax of test conditions wrong & deleting good stuff by mistake. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 18:55:57 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDF4F502 for ; Thu, 12 Mar 2015 18:55:57 +0000 (UTC) Received: from mail.westryn.net (mail.westryn.net [199.48.135.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86D3C94E for ; Thu, 12 Mar 2015 18:55:56 +0000 (UTC) Received: from ice.westryn.net (225x169.ouraynet.com [204.16.225.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.westryn.net (Postfix) with ESMTPSA id 890B994323E; Thu, 12 Mar 2015 12:55:54 -0600 (MDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: file system change notifications From: Kim Shrier In-Reply-To: <85EE0305-5D79-4C66-A6F4-05219655DAD5@mail.turbofuzz.com> Date: Thu, 12 Mar 2015 12:55:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <237A50A5-FAB7-4FC1-B8F1-0E40DCBF6137@dons.net.au> <5786089D-414D-485C-B675-35B5A62C5950@gmail.com> <85EE0305-5D79-4C66-A6F4-05219655DAD5@mail.turbofuzz.com> To: Jordan Hubbard X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Hackers , "O'Connor, Daniel" , Guy Helmer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 18:55:57 -0000 On Mar 12, 2015, at 10:24 AM, Jordan Hubbard = wrote: >=20 >=20 >> On Mar 12, 2015, at 6:37 AM, Guy Helmer wrote: >>=20 >> How are Darwin (OS X) fsevents implemented? It=E2=80=99s a been a = handy interface for some of my work. >=20 > They have their own tap from the kernel and their own daemon = (fseventsd) to handle coalescing and a publish/subscribe model that will = feed multiple consumers without duplicating or losing events (I = haven=E2=80=99t looked deeply into the implementation, but presumably = all the cache management is there as well so that memory consumption can = be kept manageable. >=20 > Maybe someone should keep a list of =E2=80=9COS X features we would = really like in FreeBSD=E2=80=9D (add purgeable memory and memory = pressure bands to that list while you=E2=80=99re at it) and parcel them = out as GSoC projects. :-) >=20 > - Jordan I was curious if the OS X code, which I believe adds some functionality = to VFS along with fseventd for actually handling the notifications, = would be a good model for FreeBSD. I need to study the OS X code some = more to make sure I understand it. Also, to clarify, I am not proposing this as a GSoC project. I was just = referring to a GSoC project that seemed to address this problem. If I = can figure out a good approach for adding this to FreeBSD, I would do it = myself. Kim From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 19:07:42 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 400A771E for ; Thu, 12 Mar 2015 19:07:42 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1473DA86 for ; Thu, 12 Mar 2015 19:07:41 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2CJ9Lpa046493; Thu, 12 Mar 2015 12:09:21 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: Matt Tagg , "Julian H. Stacey" In-Reply-To: <201503121754.t2CHscnQ092956@fire.js.berklix.net> References: <201503121754.t2CHscnQ092956@fire.js.berklix.net> From: "Chris H" Subject: Re: find with -delete option on absolute paths Date: Thu, 12 Mar 2015 12:09:21 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <3b90cd87b96ea11ed03d5125a897949e@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 19:07:42 -0000 On Thu, 12 Mar 2015 18:54:38 +0100 "Julian H. Stacey" wrote > Matt Tagg wrote: > > Hey BSD folks > > > > I believe this was discussed previously (2013), though I could not > > find a resolution. > > > > To recap, suppose we try deleting files on an absolute path: > > > > matt@mtbook:/% find /tmp/foo/* -delete > > find: -delete: /tmp/foo/bar.txt: relative path potentially not safe > > > > As you can see it gives an error and quits. However if we instead try this: > > > > matt@mtbook:/% gfind /tmp/foo/* -delete > > > > GNU Find throws no error and works as expected ('bar.txt is deleted') > > > > So as an end user, I find this rather confusing. How can I get the > > same behavior with BSD Find out of the box? > > Off on a tangent: > Last millenia (1987 :-) when I was using find & needed an rm to reduce > near duplicate trees on DOS & Unix, I wrote my own C > http://berklix.com/~jhs/src/bsd/jhs/bin/public/cmpd/ > I've never since worried about getting syntax of test conditions > wrong & deleting good stuff by mistake. Thanks for sharing that, Julian. :-) I don't see an entry for this in the ports tree. :-/ Thanks, again. --Chris > > Cheers, > Julian > -- > Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com > Indent previous with "> ". Reply Below as a play script. > Send plain text, Not quoted-printable, HTML, or base64. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 19:30:51 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94D55EF2; Thu, 12 Mar 2015 19:30:51 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58584DD1; Thu, 12 Mar 2015 19:30:51 +0000 (UTC) Received: by iegc3 with SMTP id c3so58351044ieg.3; Thu, 12 Mar 2015 12:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h5p1AZrjhyqOzqrGzWTQbxMq+F740IHRo2ImPl03XoU=; b=DpniJJVCUm6dLcYZrlGxxKVLrlRJafc+ciu7VuWV6DZAvMk36wRXKc81g33a3Ri4hA tuHQkch9EmuJFCgDSrYR2/QrMCXHWnVuCB2v5om5xc6dkBg7Q9M2q5a25eBcr6nK/dtd +Ns+xfMsSw0cxaCDDBixPmOgfuMssS3murmVcBOim1ZI/nWLLGVaONZjhQpXxkJRhXKE qfMg/kXa3AQUDT9Cuis/6YSsftcI/2aeHKJ2tEZeGyWfVvGuf/JvGsAdRi3xvclal4QK w9LJXO7Lj6347W8oHrDXuAwKY2TK/zJEmvo/0MT8xmiWtlNuIb2MscNYrOG4lDdNzv/a nsow== MIME-Version: 1.0 X-Received: by 10.50.66.170 with SMTP id g10mr103496657igt.49.1426188639908; Thu, 12 Mar 2015 12:30:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Thu, 12 Mar 2015 12:30:39 -0700 (PDT) In-Reply-To: <5501DD57.7030305@freebsd.org> References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> Date: Thu, 12 Mar 2015 12:30:39 -0700 X-Google-Sender-Auth: hQaVUxKXZKf65_2JqGAfvHhXMlo Message-ID: Subject: Re: Server with 3TB Crashing at boot From: Adrian Chadd To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Michael Fuckner , Oliver Pinter , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 19:30:51 -0000 Right. Try booting it with SMP disabled but with all the RAM. I think it's 'kern.smp.disabled=1' at the bootloader, then 'boot -v' -a From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 12 23:18:02 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF9A38A9 for ; Thu, 12 Mar 2015 23:18:02 +0000 (UTC) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E540A72 for ; Thu, 12 Mar 2015 23:18:01 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBE7D2.dip0.t-ipconnect.de [93.203.231.210]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t2CNLZx9087184; Fri, 13 Mar 2015 00:21:36 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t2CNHiQR035531; Fri, 13 Mar 2015 00:17:44 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t2CNHJtI056445; Fri, 13 Mar 2015 00:17:32 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201503122317.t2CNHJtI056445@fire.js.berklix.net> To: "Chris H" Subject: Re: find with -delete option on absolute paths From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 12 Mar 2015 12:09:21 -0700." <3b90cd87b96ea11ed03d5125a897949e@ultimatedns.net> Date: Fri, 13 Mar 2015 00:17:19 +0100 Cc: Matt Tagg , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 23:18:03 -0000 "Chris H" wrote: > On Thu, 12 Mar 2015 18:54:38 +0100 "Julian H. Stacey" wrote > > > Matt Tagg wrote: > > > Hey BSD folks > > > > > > I believe this was discussed previously (2013), though I could not > > > find a resolution. > > > > > > To recap, suppose we try deleting files on an absolute path: > > > > > > matt@mtbook:/% find /tmp/foo/* -delete > > > find: -delete: /tmp/foo/bar.txt: relative path potentially not safe > > > > > > As you can see it gives an error and quits. However if we instead try this: > > > > > > matt@mtbook:/% gfind /tmp/foo/* -delete > > > > > > GNU Find throws no error and works as expected ('bar.txt is deleted') > > > > > > So as an end user, I find this rather confusing. How can I get the > > > same behavior with BSD Find out of the box? > > > > Off on a tangent: > > Last millenia (1987 :-) when I was using find & needed an rm to reduce > > near duplicate trees on DOS & Unix, I wrote my own C > > http://berklix.com/~jhs/src/bsd/jhs/bin/public/cmpd/ > > I've never since worried about getting syntax of test conditions > > wrong & deleting good stuff by mistake. > Thanks for sharing that, Julian. :-) > I don't see an entry for this in the ports tree. :-/ > Thanks, again. > --Chris Hi Chris, Thanks :-) It's part of 8.5 meg of small tools & diffs in http://berklix.com/~jhs/src/ that I've occasionaly thought of rolling parts of for a port, but cd ~/public_html/src; make; make install works here, so I've never gone further, though ideally perhaps I should tidy & bundle some bits. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 00:52:47 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DBD1218 for ; Fri, 13 Mar 2015 00:52:47 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 3A3E394B for ; Fri, 13 Mar 2015 00:52:46 +0000 (UTC) Received: from [192.168.128.101] (ai126143092246.32.access-internet.ne.jp [126.143.92.246]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id D78409C531 for ; Fri, 13 Mar 2015 00:52:39 +0000 (UTC) Message-ID: <550234D8.1070006@freebsd.org> Date: Thu, 12 Mar 2015 20:52:40 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: STDIN of dialog4ports References: <20150312054510.000067f4@gmail.com> <9928461426161287@web22o.yandex.ru> <20150312154503.00003c47@gmail.com> In-Reply-To: <20150312154503.00003c47@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 00:52:47 -0000 On 03/12/2015 10:45, rank1seeker@gmail.com wrote: > Thanks Ilya, > > Well, better you patch it as you already know the layout of > dialog4ports's code, as you've been main dev and you know where to start > patching. I believe it's a little change which would cost you only hour > or few. ;) > + you are way more experienced in C then I (I did it only for about 4 > months) > > Just throw a patch and I'll gladly test it. (added hackers@) > > > Domagoj Smolčić > > > > On Thu, 12 Mar 2015 14:54:47 +0300 > Ilya A. Arkhipov wrote: > >> Yes, now dialog4ports can't to get from STDIN any data. >> But if you want you(or maybe I) can prepare patch for that ^_^ >> >> 12.03.2015, 07:45, "rank1seeker@gmail.com" : >>> Hi! >>> >>> I'm contacting you because you have developed dialog4ports and I'll >>> try to be very short in my request. >>> >>> GOAL: File "/var/db/ports/$PORT/options" being created via 'make >>> config' as it is when ENTER is pressed as soon as dialog was >>> displayed. >>> >>> Before 9.0 my solution was: >>> When in port's dir (DOESN'T have "/var/db/ports/$PORT/options" file >>> set => doesn't exists yet) -- >>> # make config << MyEND >>> o >>> MyEND >>> -- >>> Additionally, I avoided dialog being displayed by sending it >>> to /dev/null. Once "/var/db/ports/$PORT/options" is created, task >>> is done => NO build, install, etc ... >>> >>> Now as I understand, change to "raw" mode type of dialog4ports's >>> STDIN, which differs from pipe's buffered mode, makes me unable to >>> pipe ENTER (\n) to dialog >>> >>> Now I'm forced to use lang/expect which is overhead and very slow! >>> >>> Thanks in advance. >>> >>> Domagoj Smolčić >> > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > If you just want to accept the defaults, setting the environment variable BATCH=YES will skip displaying dialog4ports entirely -- Allan Jude From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 01:26:24 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84B51C66; Fri, 13 Mar 2015 01:26:24 +0000 (UTC) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by mx1.freebsd.org (Postfix) with ESMTP id E15F4D9C; Fri, 13 Mar 2015 01:26:23 +0000 (UTC) Received: from ppp118-210-187-121.lns20.adl6.internode.on.net (HELO midget.dons.net.au) ([118.210.187.121]) by ipmail07.adl2.internode.on.net with ESMTP; 13 Mar 2015 11:51:12 +1030 Received: from [10.0.2.26] ([10.0.2.26]) (authenticated bits=0) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPSA id t2D1KrJR067027 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2015 11:50:59 +1030 (CST) (envelope-from darius@dons.net.au) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: file system change notifications From: "O'Connor, Daniel" In-Reply-To: <20150312143814.GA9153@dft-labs.eu> Date: Fri, 13 Mar 2015 11:50:53 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <3C95016C-23D4-4827-A70D-803FD441255F@dons.net.au> References: <20150311224831.GB18699@dft-labs.eu> <201503112318.t2BNIboU092815@gw.catspoiler.org> <20150312143814.GA9153@dft-labs.eu> To: Mateusz Guzik X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -2.9 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 Cc: freebsd-hackers@FreeBSD.org, Don Lewis , int0dster@gmail.com, oliver.pinter@hardenedbsd.org, shawn.webb@hardenedbsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 01:26:24 -0000 > On 13 Mar 2015, at 01:08, Mateusz Guzik wrote: >> I seem to recall reading a long time ago that DragonFly pins = directories >> in the cache, or something like that. >>=20 >=20 > Just refing is quite insufficient and may not work at all. >=20 > Due to hardlinks files can have more than one name. >=20 > So preferably we would stop tossing vnodes around and create an > intermediate object which would keep name component and a pointer to = an > inode. And that's what we would keep in struct file. >=20 > Then a namecache would just be a hash of such objects. >=20 > That's quite a lot of work though and unfortunately is likely too > complicated for gsoc. I did some testing and neither Linux inotify or OS X FSEvents handle = hard links so I think it's somewhat out of scope. i.e. if you create /tmp/a and /tmp/b and have 2 separate processes = watching /tmp/a and /tmp/b then do.. 1) echo foo >/tmp/a/foo 2) ln /tmp/a/foo /tmp/b/foo 3) echo bar >/tmp/b/foo Step 1 shows a notification for /tmp/a/foo Step 2 shows a notification for /tmp/b/foo (and /tmp/a in OS X) Step 3 shows a notification for /tmp/b/foo (even though /tmp/a has = changed too) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 05:41:39 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EE5E524; Fri, 13 Mar 2015 05:41:39 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CF1F4CBC; Fri, 13 Mar 2015 05:41:38 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id t2D5fMRx021400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Mar 2015 16:41:28 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id t2D5fG1s019509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Mar 2015 16:41:16 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id t2D5fGxb019508; Fri, 13 Mar 2015 16:41:16 +1100 (AEDT) (envelope-from peter) Date: Fri, 13 Mar 2015 16:41:16 +1100 From: Peter Jeremy To: Adrian Chadd Subject: Re: Server with 3TB Crashing at boot Message-ID: <20150313054116.GB92183@server.rulingia.com> References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-hackers@freebsd.org" , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 05:41:39 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2015-Mar-12 12:30:39 -0700, Adrian Chadd wrote: >Right. Try booting it with SMP disabled but with all the RAM. Is this possible? Can one CPU see the RAM on another CPU if that CPU isn't enabled in the kernel? --=20 Peter Jeremy --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVAnh8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs06YkP/iOXjuzz4mEC/8lhrOYcBpHg lYJ1riUaBTM8gXhQoZQktJLzDk5nME9iZvoswGUybUkYgYCGcAUD+IXlnltsCmvh 8kSprGHlxyCHOpvB/UTK1h5HdCFgwHH4kI7Q3C8eVFaZSWvx8ISxxGFXYuANCJQ2 +ArfmNJAVPIIwQ/LStwPzZtXc0su2nZv6L/N6gYAUD09J77RQnwbB5IEIUz5he7q tkQzKAw2Y9NUQg6gzSf3NwpfjcX1Q39d50M4DUR3407kAO25xTqTWkphDsUyAkzg PS9ZtcoSbbpl91oINe9rjT5Eo8ycJUOLS0tfrmWukjtjTlVCIF8AFGU8qhANNh3k 8xec8Npn6r3VGKFQCmhD0RY+c8SpjKMrjg1vvav3jfiuGdnPowrhdq9dLuNZTDyt FYE2tyf1Ysua3EMRF7tg1hX1v01/AC33SWOHFV8muQdbxR6eoQ4n6UQCcigRDSYA rNBqpb6HOK+Wsf8iQh471ezPK3Bz8A1l8ikQfzCX8ZtSRpTvkQU6kkTPoNWebeKr 9qvlINFhatnfZo31blZQ/VbR7ACZLLJgCD0IG7OJWYnURAIy90eGYLwaFA3BKD5T JJAglNcB9hx0wbQIwVnHYd5Pnqh4l26HxiucmVpn6f9UDsHdlRuAZQB4OT6RSG/r JvGvwL0CKAA4pUR7b/33 =QpkY -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 07:36:35 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4351E52C; Fri, 13 Mar 2015 07:36:35 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E726799B; Fri, 13 Mar 2015 07:36:34 +0000 (UTC) Received: by qgef51 with SMTP id f51so24065118qge.0; Fri, 13 Mar 2015 00:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=h3xFJmvGWJy4mQBuJZXZmvk+2CBhmXDwNHa0/XnVue4=; b=HZ19Hokpdp3HC5t17A1+bjfZFVtMYmBrzliFTmG5FXN0cJcDJYD8csH6ziln9zwBfk VKO4NxYLTv1LZp8nAMbGwO0Gulf5HaTj9Offj8uVVr0ovnEkIZW04KbfdXV/Yyb/ZRp3 Fv8WrKQfzqTGlxXL77CTzsrodaYe1W09FdkJTPHpe9wynPzeCBIi+AZ/zQ+P15ovu7HS n7rfuks9JAxnla66g2hwY1hLG2BnJV/w/vHmt3AACvt+3Cps8VSdsgvrKlhFcx1Fr/ls FcWco+TPAbPsWBdUCM8pjhRnT+IuFauxc5+3XdiPP+AWrYaRG3ac9fcMJpM7O5oSzTdA ZirA== X-Received: by 10.140.37.7 with SMTP id q7mr56653937qgq.29.1426232194079; Fri, 13 Mar 2015 00:36:34 -0700 (PDT) Received: from [10.134.110.94] (mobile-107-107-56-178.mycingular.net. [107.107.56.178]) by mx.google.com with ESMTPSA id f77sm894015qka.9.2015.03.13.00.36.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Mar 2015 00:36:33 -0700 (PDT) References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <20150313054116.GB92183@server.rulingia.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20150313054116.GB92183@server.rulingia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <207BA405-A483-4EFB-9BC5-3AD4EDEA11DD@gmail.com> X-Mailer: iPhone Mail (12D508) From: Garrett Cooper Subject: Re: Server with 3TB Crashing at boot Date: Fri, 13 Mar 2015 03:36:29 -0400 To: Peter Jeremy Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 07:36:35 -0000 > On Mar 13, 2015, at 01:41, Peter Jeremy wrote: >=20 >> On 2015-Mar-12 12:30:39 -0700, Adrian Chadd wrote: >> Right. Try booting it with SMP disabled but with all the RAM. >=20 > Is this possible? Can one CPU see the RAM on another CPU if that CPU > isn't enabled in the kernel? I could be wrong, but I think Adrian's recommending that the number of varia= bles be reduced so the root cause cause could be better isolated. Thanks!= From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 07:52:21 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4586C79D; Fri, 13 Mar 2015 07:52:21 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6B70BA5; Fri, 13 Mar 2015 07:52:20 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2D7qE09049531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2015 09:52:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2D7qE09049531 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2D7qCQe049530; Fri, 13 Mar 2015 09:52:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 13 Mar 2015 09:52:12 +0200 From: Konstantin Belousov To: Peter Jeremy Subject: Re: Server with 3TB Crashing at boot Message-ID: <20150313075212.GU2379@kib.kiev.ua> References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <20150313054116.GB92183@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150313054116.GB92183@server.rulingia.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 07:52:21 -0000 On Fri, Mar 13, 2015 at 04:41:16PM +1100, Peter Jeremy wrote: > On 2015-Mar-12 12:30:39 -0700, Adrian Chadd wrote: > >Right. Try booting it with SMP disabled but with all the RAM. > > Is this possible? Can one CPU see the RAM on another CPU if that CPU > isn't enabled in the kernel? Yes, of course. The disabled state means that the core is not started to execute the stream of the architectural instructions opcodes. The memory controller, address decoder and inter-socket links, and pcie links are configured by the motherboard firmware during the POST. They are left alone by our kernel. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 13:41:11 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 576B9A7C; Fri, 13 Mar 2015 13:41:11 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD162A1E; Fri, 13 Mar 2015 13:41:10 +0000 (UTC) Received: by wiwl15 with SMTP id l15so12213958wiw.1; Fri, 13 Mar 2015 06:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=yo2QPeUejGf/MgYlGh/oUJGZMCTnfg4pGKbv7VYRYFk=; b=oBMSVyhD0Y5GCsTwkEuMknl8m9XTdCSw279m6CIWtoMGWaH5qRB1052Z8lSpFoub+g CEtiK+UtHxInnIMx9k0EjW5prgCp13F46pK+aW7ct0L77eihoa2eHFVMxeMCkgHTGdgg NXrnFe8PfAUtZsp9ad7JoEPpHHge7MB5to5GZ3GIrDZoVCnT1LPuR50QZI+SvL4g3aDK IUv9T0rNZiL2k8kh36qNXecE/uZT9joVpM3LZA8epk6VyEjl7I5bj4tqJf4UNz8YHFyE g5EoJ0/bwvycD5SDxKSGIfqhghgPMtrq4CSo6AAeMyHYaGc2r6zxrwYGsUn2hiWq4Hja 2S4g== X-Received: by 10.194.156.133 with SMTP id we5mr99388672wjb.37.1426254069371; Fri, 13 Mar 2015 06:41:09 -0700 (PDT) Received: from localhost ([217.14.212.217]) by mx.google.com with ESMTPSA id ew5sm2845217wic.14.2015.03.13.06.41.08 (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 06:41:08 -0700 (PDT) Date: Fri, 13 Mar 2015 14:41:05 +0100 From: To: freebsd-hackers@freebsd.org Subject: Re: STDIN of dialog4ports Message-ID: <20150313144105.000001f8@gmail.com> In-Reply-To: <550234D8.1070006@freebsd.org> References: <20150312054510.000067f4@gmail.com> <9928461426161287@web22o.yandex.ru> <20150312154503.00003c47@gmail.com> <550234D8.1070006@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 13:41:11 -0000 On Thu, 12 Mar 2015 20:52:40 -0400 Allan Jude wrote: > On 03/12/2015 10:45, rank1seeker@gmail.com wrote: > > Thanks Ilya, > >=20 > > Well, better you patch it as you already know the layout of > > dialog4ports's code, as you've been main dev and you know where to > > start patching. I believe it's a little change which would cost you > > only hour or few. ;) > > + you are way more experienced in C then I (I did it only for about > > 4 months) > >=20 > > Just throw a patch and I'll gladly test it. (added hackers@) > >=20 > >=20 > > Domagoj Smol=C4=8Di=C4=87 > >=20 > >=20 > >=20 > > On Thu, 12 Mar 2015 14:54:47 +0300 > > Ilya A. Arkhipov wrote: > >=20 > >> Yes, now dialog4ports can't to get from STDIN any data. > >> But if you want you(or maybe I) can prepare patch for that ^_^ > >> > >> 12.03.2015, 07:45, "rank1seeker@gmail.com" : > >>> Hi! > >>> > >>> I'm contacting you because you have developed dialog4ports and > >>> I'll try to be very short in my request. > >>> > >>> GOAL: File "/var/db/ports/$PORT/options" being created via 'make > >>> config' as it is when ENTER is pressed as soon as dialog was > >>> displayed. > >>> > >>> Before 9.0 my solution was: > >>> When in port's dir (DOESN'T have "/var/db/ports/$PORT/options" > >>> file set =3D> doesn't exists yet) -- > >>> # make config << MyEND > >>> o > >>> MyEND > >>> -- > >>> Additionally, I avoided dialog being displayed by sending it > >>> to /dev/null. Once "/var/db/ports/$PORT/options" is created, task > >>> is done =3D> NO build, install, etc ... > >>> > >>> Now as I understand, change to "raw" mode type of dialog4ports's > >>> STDIN, which differs from pipe's buffered mode, makes me unable to > >>> pipe ENTER (\n) to dialog > >>> > >>> Now I'm forced to use lang/expect which is overhead and very slow! > >>> > >>> Thanks in advance. > >>> > >>> Domagoj Smol=C4=8Di=C4=87 > >> > >=20 > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" > >=20 >=20 > If you just want to accept the defaults, setting the environment > variable BATCH=3DYES will skip displaying dialog4ports entirely No, BATCH=3DYES won't work for 'config' target as it'll display dialog anyw= ay. It'll work with 'install' target, BUT "/var/db/ports/$PORT/options" won't b= e created! From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 15:51:34 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB3BD315 for ; Fri, 13 Mar 2015 15:51:33 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B193BBE1 for ; Fri, 13 Mar 2015 15:51:33 +0000 (UTC) Received: by iegc3 with SMTP id c3so114251461ieg.3 for ; Fri, 13 Mar 2015 08:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/ug+5rgweGQs1TWcJbQ9Eaim/RJ2+tu/txnmlK2nVSs=; b=a+9o0gRnsqJ31V8imfuZ7kZifBipJ80vfmVsAmzhtPk3JS2jG6HdE8S3r7JvbEwenY 4PxuiU3vaYxyXyMlS26AT4gAE0ZLqtwyt64S7iRpkF9cpNBaZOdZB5p7kL76+vWe2ucd k/jnfVtNloCY2oBN2iMN8cwvaaaOEdgj+Z63doMXUua+nt4wZBCVfFZ4lYNxe0fyGdU+ nzZKX+FwsTSVsI2PJlHfKCZC7dV7jARGg7XkiN4Y8riQXyJzRikZisZvskKCf246cPMZ zy2HFCFtx7MHkQepViiS9hucEBRr4Ej5KQlDnyqNFY0pI7wcHpxm0/BCHEnnQHxyPgDp oOMg== MIME-Version: 1.0 X-Received: by 10.50.66.235 with SMTP id i11mr86307706igt.40.1426261888031; Fri, 13 Mar 2015 08:51:28 -0700 (PDT) Received: by 10.36.51.200 with HTTP; Fri, 13 Mar 2015 08:51:27 -0700 (PDT) Date: Fri, 13 Mar 2015 11:51:27 -0400 Message-ID: Subject: Memory foot print on BSD 9.1 From: suresh gumpula To: "freebsd-hackers@freebsd.org" X-Mailman-Approved-At: Fri, 13 Mar 2015 16:20:38 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 15:51:34 -0000 Hello VM experts, I am trying to figure out what has been changed from 8.1 to 9.1 which results more memory footprint on all processes. looking at one of the big processes we have on a idle machine, its about 35M resident size increase. Looking at map entries by procstat -v shows me that two libraries , one is our internal library(libmgwd) and other one is boost consume more now. There are no changes made with respect to process, just comparing after the upgrade to 9.1. Is there any knows things with respect VM has been changed and could result in more resident memory ? Can somebody please help on this to know what exactly causing this behaviour ? Details below. Thank you! 8.1 =E2=80=94 % sudo procstat -v `pgrep mgwd` PID START END PRT RES PRES REF SHD FL TP PATH 2213 0x800a46000 0x807b41000 r-x 18209 22827 2 1 CN vn /usr/lib/libmgwd.so.1 2213 0x807d40000 0x808a90000 rw- 3019 0 1 0 C- vn /usr/lib/libmgwd.so.1 2213 0x833406000 0x833407000 rw- 1 0 1 0 CN vn /usr/lib/libboost_atomic.so.1.56.0 2213 0x833600000 0x835600000 rw- 8134 0 1 0 C- df 2213 0x835600000 0x835800000 rw- 20 0 1 0 -- df 2213 0x7ffff6f99000 0x7ffff6fb9000 rw- 1 0 1 0 -- df 2213 0x7ffff719a000 0x7ffff71ba000 rw- 1 0 1 0 -- df 2213 0x7ffff739b000 0x7ffff73bb000 rw- 12 0 1 0 -- df 9.1 =E2=80=94=E2=80=94 % sudo procstat -v `pgrep mgwd` PID START END PRT RES PRES REF SHD FL TP PATH 2158 0x800a1c000 0x807c87000 r-x 23328 26760 2 1 CN-- vn /usr/lib/libmgwd.so.1 2158 0x807e87000 0x808bd4000 rw- 3283 0 1 0 C--- vn /usr/lib/libmgwd.so.1 2158 0x8336d7000 0x8336d8000 rw- 1 0 1 0 CN-- vn /usr/lib/libboost_atomic.so.1.56.0 2158 0x8336d8000 0x8342cf000 rw- 2105 0 1 0 C-S- df 2158 0x8342cf000 0x8342ea000 rw- 27 0 1 0 C--- df 2158 0x8342ea000 0x8342f3000 rw- 7 0 1 0 ---- df 2158 0x834400000 0x834600000 rw- 511 0 1 0 C--- df 2158 0x834600000 0x836400000 rw- 7375 0 1 0 C--- df 2158 0x836400000 0x836600000 rw- 228 0 1 0 ---- df BSD 8.1 =3D=3D=3D=3D=3D=3D last pid: 5116; load averages: 5.22, 4.29, 2.34 up 0+00:10:15 17:34:00 352 processes: 1 running, 350 sleeping, 1 zombie CPU: 0.2% user, 0.0% nice, 4.5% system, 1.7% interrupt, 93.5% idle Mem: 297M Active, 648M Inact, 139M Wired, 6948K Cache, 7520K Buf, 1862M Fre= e Swap: 1536M Total, 1536M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 2219 root 68 96 0 859M 226M ucond 1 0:24 0.00% mgwd BSD 9.1 =E2=80=94=E2=80=94=E2=80=94 last pid: 5344; load averages: 5.17, 4.47, 2.79 up 0+00:26:12 17:22:57 39 processes: 1 running, 37 sleeping, 1 zombie CPU: 0.2% user, 0.0% nice, 2.2% system, 0.6% interrupt, 97.0% idle Mem: 338M Active, 669M Inact, 147M Wired, 392K Cache, 7488K Buf, 1799M Free Swap: 1536M Total, 1536M Fre PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 2158 root 68 40 0 874M 262M uwait 1 0:23 0.00% mgwd =3D=3D=3D=3D=3D=3D=3D=3D % ldd /usr/lib/libmgwd.so.1 /usr/lib/libmgwd.so.1: % ldd /usr/lib/libboost_atomic.so.1.56.0 /usr/lib/libboost_atomic.so.1.56.0: librt.so.1 =3D> /usr/lib/librt.so.1 (0x801002000) libthr.so.3 =3D> /lib/libthr.so.3 (0x801207000) ;;image size comparison on different builds shows TEXT size of a libray went up by ~1.5M text data bss dec hex filename 118484184 13956880 5724944 138166008 83c3ef8 devN_150110_0500/mgmtgateway/bedrock/internal/x86_64/ulibso/libmgwd.so.1 119973051 13946008 5724944 139644003 852cc63 devN_150110_1035/mgmtgateway/bedrock/internal/x86_64/ulibso/libmgwd.so.1 BSD 9.1 =E2=80=94=E2=80=94 % size /sbin/mgwd text data bss dec hex filename 2106422 42388 371584 2520394 26754a /sbin/mgwd % size /usr/lib/libboost_atomic.so.1.56.0 text data bss dec hex filename 1309 264 2624 4197 1065 /usr/lib/libboost_atomic.so.1.56.0 BSd 8.1 =E2=80=94=E2=80=94=E2=80=94 % size /sbin/mgwd text data bss dec hex filename 2091457 42364 371520 2505341 263a7d /sbin/mgwd % size /usr/lib/libboost_atomic.so.1.56.0 text data bss dec hex filename 1309 264 2624 4197 1065 /usr/lib/libboost_atomic.so.1.56.0 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 17:50:31 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5ADEDCF; Fri, 13 Mar 2015 17:50:31 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFF2FB91; Fri, 13 Mar 2015 17:50:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426269004; l=803; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date; bh=TH3amsfH+Fk2BbZ4t+b3Zt2RXl6XFn6lspx6ELCe9Yo=; b=hxj8XCUO1jNda4wKYlapcv1RFGITYBIKJs0G00yuq7IXo8UyAT1taEqvo8HkoZcox/z qQGswpOszwiJme91SoPNiQeG51aOiVlmcbHeU+vQ4Jpfw9slQYNSjPxDCDwCQ2LwACACA mliPGHlGXpIGS1D3qCU7jyS34xtlcI09mAc= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgkO4q1xDEhkgOJDsXNs= X-RZG-CLASS-ID: mo00 Received: from fuckner.delnet ([85.183.0.195]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPA id 901c6er2DHo35di; Fri, 13 Mar 2015 18:50:03 +0100 (CET) Message-ID: <5503234A.4060103@fuckner.net> Date: Fri, 13 Mar 2015 18:50:02 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adrian Chadd , Julian Elischer Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Oliver Pinter , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 17:50:31 -0000 On 03/12/2015 08:30 PM, Adrian Chadd wrote: > Right. Try booting it with SMP disabled but with all the RAM. > > I think it's 'kern.smp.disabled=1' at the bootloader, then 'boot -v' my problem seems to be my /boot/loader.conf which is the correct option for verboose booting? when loading nvme/nvd/zfs it crashes. why is mpr1 detected after loading nvme? (I boot from mpr0) hw.memtest.tests=0 #kern.smp.disabled=1 console=comconsole boot_verbose="YES" verbose_loading="YES" zfs_load="NO" nvme_load="NO" nvd_load="NO" http://dedi3.fuckner.net/~molli123/temp/kldload-nvme_nvd_zfs.txt http://dedi3.fuckner.net/~molli123/temp/freebsd-10.1_smp-disabled_verbose.txt http://dedi3.fuckner.net/~molli123/temp/freebsd-10.1_smp-enabled_verbose.txt Any idea? Regards, Michael! From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 18:02:24 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DADC55A3; Fri, 13 Mar 2015 18:02:24 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D6D4D59; Fri, 13 Mar 2015 18:02:24 +0000 (UTC) Received: by iegc3 with SMTP id c3so120890154ieg.3; Fri, 13 Mar 2015 11:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GjpZjhb7bSri01aDPT7RYzHmhs+g4gY8/qzeJIuC3VQ=; b=xSCOjCoVdCrQ22YZlquxs4N1gCyYQg/NulU5glNzP66a29s4kBCcCpbAU++Y+KKKmg UoGvad7qyfUBK1dPrMmxEAf49YrVl9mN+E/5K4z5isgX94nW6aDTNTGoGmuDy37JefRJ lem8CYgUt9AKbjuFbNQn/xs7wIivRD/po1SpqQdHpzKweLPaYv/6mKq+sjkO+Bzjj9w/ s4VVqNa3vzeWjxfwKMJjyIejnKDTDeqA8QYG4HzvPCN6KHqHqBXOL+VThd0fLJGSBcKC kXM2i5DUHRc8vywe+qRtitBiwWUrSRgrTCT/B7DCwShREzHgQ4kNwdR8+bOBh27/zD4/ ulbg== MIME-Version: 1.0 X-Received: by 10.107.136.206 with SMTP id s75mr51439019ioi.8.1426269735349; Fri, 13 Mar 2015 11:02:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 13 Mar 2015 11:02:15 -0700 (PDT) In-Reply-To: <5503234A.4060103@fuckner.net> References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> Date: Fri, 13 Mar 2015 11:02:15 -0700 X-Google-Sender-Auth: CSkLeW2Vv8yRQqlo8W_OD8QKH1g Message-ID: Subject: Re: Server with 3TB Crashing at boot From: Adrian Chadd To: Michael Fuckner Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Oliver Pinter , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 18:02:25 -0000 On 13 March 2015 at 10:50, Michael Fuckner wrote: > On 03/12/2015 08:30 PM, Adrian Chadd wrote: >> >> Right. Try booting it with SMP disabled but with all the RAM. >> >> I think it's 'kern.smp.disabled=1' at the bootloader, then 'boot -v' > > > my problem seems to be my /boot/loader.conf > > which is the correct option for verboose booting? > when loading nvme/nvd/zfs it crashes. > why is mpr1 detected after loading nvme? (I boot from mpr0) > > > hw.memtest.tests=0 > #kern.smp.disabled=1 > console=comconsole > boot_verbose="YES" > verbose_loading="YES" > zfs_load="NO" > nvme_load="NO" > nvd_load="NO" > > http://dedi3.fuckner.net/~molli123/temp/kldload-nvme_nvd_zfs.txt > http://dedi3.fuckner.net/~molli123/temp/freebsd-10.1_smp-disabled_verbose.txt > http://dedi3.fuckner.net/~molli123/temp/freebsd-10.1_smp-enabled_verbose.txt > > > Any idea? Hi, boot_verbose=YES looks to be right. So hm, just to be clear - it boots fine if you don't load zfs/nvme/nvd? -adrian From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 18:27:50 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B5F2D84 for ; Fri, 13 Mar 2015 18:27:50 +0000 (UTC) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3649FE8 for ; Fri, 13 Mar 2015 18:27:48 +0000 (UTC) Received: by wesq59 with SMTP id q59so25079428wes.9 for ; Fri, 13 Mar 2015 11:27:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hKgQXTkb7DZrk167MK9Rt0GJdUq6gV3GodoGL1GYwNo=; b=OdL6+6HAsBeFntJ43QFCvXs6UteuZkc/1TZrY34hZEYZqhq/4TP4StNZV/yEetpfw/ iCwM7U/43t3+rTPFMllJv0L0849p8nsGYg71XaTJhva2IZh8Vo5+1EFpK9rx6QyBMtNi 4scnZM9g2z7FRnTW2KMn1jKgRInVeJpzuehgVfNrNdmCTiDw8VmZIBRSapHtY3Eu83F2 XyajBS9G8Ny3k2X4GwQEZV8DGdHEkiHSMNY1N0V/A7ZZSPZVljIJiv6odDAEaxV8z5EQ CtV9i0x33bK6Vpq+yvC39siVRHuRbxgpEjRwm1tH+81BJ8nhcaSBP06Mf5txVia2CUfu eWZw== X-Gm-Message-State: ALoCoQny/4gtI9LP5lppE3vN+9tWiRDLqq+8/hyswVvqn9kvcP1UHdv4SxIw+QxJFeJwNJkgoOSA X-Received: by 10.180.108.203 with SMTP id hm11mr64953515wib.49.1426271261345; Fri, 13 Mar 2015 11:27:41 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id ka1sm3907011wjc.2.2015.03.13.11.27.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 11:27:40 -0700 (PDT) Message-ID: <55032C1B.5030004@multiplay.co.uk> Date: Fri, 13 Mar 2015 18:27:39 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> In-Reply-To: <5503234A.4060103@fuckner.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 18:27:50 -0000 On 13/03/2015 17:50, Michael Fuckner wrote: > On 03/12/2015 08:30 PM, Adrian Chadd wrote: >> Right. Try booting it with SMP disabled but with all the RAM. >> >> I think it's 'kern.smp.disabled=1' at the bootloader, then 'boot -v' > > my problem seems to be my /boot/loader.conf > > which is the correct option for verboose booting? > when loading nvme/nvd/zfs it crashes. > why is mpr1 detected after loading nvme? (I boot from mpr0) > > > hw.memtest.tests=0 > #kern.smp.disabled=1 > console=comconsole > boot_verbose="YES" > verbose_loading="YES" > zfs_load="NO" > nvme_load="NO" > nvd_load="NO" > > http://dedi3.fuckner.net/~molli123/temp/kldload-nvme_nvd_zfs.txt > http://dedi3.fuckner.net/~molli123/temp/freebsd-10.1_smp-disabled_verbose.txt > > http://dedi3.fuckner.net/~molli123/temp/freebsd-10.1_smp-enabled_verbose.txt > > > > Any idea? Looks like that's panicing when allocating the zfs dbuf hash table, which by my calculation should be requesting 8GB for a 4TB physmem? Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 19:40:08 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1E681E7 for ; Fri, 13 Mar 2015 19:40:08 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA1C2AEB for ; Fri, 13 Mar 2015 19:40:08 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so118633252iec.0 for ; Fri, 13 Mar 2015 12:40:08 -0700 (PDT) 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=Ax79z1MHti3igZP0IaiffU0v61YUi21isLeLvVqR7jg=; b=ELSf5MsPCVHYXSqMZhyv5A/87C1WPR3KSZbJYOh5Mq61yUdKYR/kjKikLHe5KBk/yU TgHRKSWOeCvBySAlIhInqrwW1I8odOzBp7mrj20AzAx7InNUSMb33Myoh9EEQ8bQjzw2 9SsY6+5IHH56n+1MQ3xkPsjmqAOTX54K2zWumq1GMZheQIxopTkxN/jySsYNFLqQlGM4 95rBfK47z/gU5yeaE2eNhfrm0Z/X6C4CcC+Rqzf04Nax30oht0wUvO6RgI1GV4NpCz0T 5MS4L1v4Sc0V7gBozKK3vZODNZV8Osf/oT+HjVOhHSJKb9vKS2HBnaTPe+qnVfDijVmF 4DYw== MIME-Version: 1.0 X-Received: by 10.50.43.162 with SMTP id x2mr113493583igl.46.1426275602264; Fri, 13 Mar 2015 12:40:02 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Fri, 13 Mar 2015 12:40:02 -0700 (PDT) In-Reply-To: <55032C1B.5030004@multiplay.co.uk> References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> Date: Fri, 13 Mar 2015 15:40:02 -0400 Message-ID: Subject: Re: Server with 3TB Crashing at boot From: Ryan Stone To: Steven Hartland Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 19:40:09 -0000 On Fri, Mar 13, 2015 at 2:27 PM, Steven Hartland wrote: > Looks like that's panicing when allocating the zfs dbuf hash table, which > by my calculation should be requesting 8GB for a 4TB physmem? > Interesting observation. Michael, can you try booting with this patch applied? There is a bug in the kernel when we attempt to malloc() more than 4GB. https://people.freebsd.org/~rstone/patches/vm_64bit_malloc.diff From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 19:50:29 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46D4F49B; Fri, 13 Mar 2015 19:50:29 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53D82C88; Fri, 13 Mar 2015 19:50:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426276199; l=1800; s=domk; d=fuckner.net; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Cc:To: Reply-To:From:Date; bh=+QESKfdCq53CUeOeDqhDSu4iRopDU4kO6KlQyYNHn3k=; b=od9Q/jYyUja3Ylnvu4R1P0h3EGSv/Ate/q11Pzp/liBEHB6Bot1o+vmHS0penWrlcC8 MuuhdUXRGChNzmLO1e4bBwhVWt1b36GCIcGITSPrGjkxlHjBmoexHvwvq93igiP5UOQ+J le0GOC816lw+32hfOQRog/Q+HyMaHqcoUQQ= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTEGbkn8hussqFHiy/c+oYVPeezIVIZYA== X-RZG-CLASS-ID: mo00 Received: from ptangptang.store (com4.strato.de [81.169.145.237]) by smtp-ox.front (RZmta 37.4 AUTH) with ESMTPSA id n0379ar2DJni8rE (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate); Fri, 13 Mar 2015 20:49:44 +0100 (CET) Date: Fri, 13 Mar 2015 20:49:44 +0100 (CET) From: Michael Fuckner Reply-To: Michael Fuckner To: Adrian Chadd Message-ID: <101866634.392324.1426276184167.JavaMail.open-xchange@ptangptang.store> In-Reply-To: References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> Subject: Re: Server with 3TB Crashing at boot MIME-Version: 1.0 X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.0-Rev36 X-Originating-Client: com.openexchange.ox.gui.dhtml Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Oliver Pinter , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 19:50:29 -0000 > Adrian Chadd hat am 13. M=C3=A4rz 2015 um 19:02 gesc= hrieben: =20 Hi! > boot_verbose=3DYES looks to be right. root@s4l:~ # grep verbose /boot/defaults/loader.conf verbose_loading=3D"NO" # Set to YES for verbose loader output OK, this confused me :-( > So hm, just to be clear - it boots fine if you don't load zfs/nvme/nvd? yes, probably zfs, but why does loading nvme also come up with other device= s like mpr? From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 19:54:18 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CA7F65C for ; Fri, 13 Mar 2015 19:54:18 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08F34D5E for ; Fri, 13 Mar 2015 19:54:17 +0000 (UTC) Received: by wivr20 with SMTP id r20so8948668wiv.5 for ; Fri, 13 Mar 2015 12:54:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=bj46Cadu9fslOYOzqJDmN4VBpa8XDkM8azjzoQQYOLg=; b=PdCqUgpsoQTA1vPNPCrCghTppynlfSkeWTfs6re772G59VXT5RUMAKmdLWMIp5u+Jh zQpGZyl24YQTeImBwuV9Pn7Y11lIfRRbW+KkCOcBhTbOUSemnW3K12n7BK0WxnzwgoPC 9np1x7z6lignKMnvyGNBoxqcMk3gens9AL0NBTgHdotqH6dhLfuZRwj2EMDCDoLMg0WO zdmvqbY/TJnm9KExE32WaWjdfJp89TMiGRQ3RpyowKQYcwRGDMirNlcRSqqeYppNZQHS F2/yKkH8Xl9LJbxT8JoWMPLcGAM1JcYJvsPjRvUZlRjzKuzs0QHrItofiGi9gggm0zyH TpgQ== X-Gm-Message-State: ALoCoQlkSMj52ZZgmvIeIhHCTgFr5k0ifSUhSK6rg16YhHyKbdCSeT6DU7W9J7nwoTNJoyM+whLA X-Received: by 10.180.8.98 with SMTP id q2mr39594875wia.80.1426276450394; Fri, 13 Mar 2015 12:54:10 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id l4sm4144664wiw.6.2015.03.13.12.54.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 12:54:08 -0700 (PDT) Message-ID: <5503405E.6050805@multiplay.co.uk> Date: Fri, 13 Mar 2015 19:54:06 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ryan Stone Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 19:54:18 -0000 On 13/03/2015 19:40, Ryan Stone wrote: > On Fri, Mar 13, 2015 at 2:27 PM, Steven Hartland > > wrote: > > Looks like that's panicing when allocating the zfs dbuf hash > table, which by my calculation should be requesting 8GB for a 4TB > physmem? > > > Interesting observation. Michael, can you try booting with this patch > applied? There is a bug in the kernel when we attempt to malloc() > more than 4GB. > > https://people.freebsd.org/~rstone/patches/vm_64bit_malloc.diff > > Nice catch Ryan, don't you just love integer overflows ;-) Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 20:00:03 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53FC57C2 for ; Fri, 13 Mar 2015 20:00:03 +0000 (UTC) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0150FDA2 for ; Fri, 13 Mar 2015 20:00:02 +0000 (UTC) Received: by wibbs8 with SMTP id bs8so8716083wib.4 for ; Fri, 13 Mar 2015 12:59:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zZFAHSk/msL17pbMMS9ZHO7+RyC+PAk6o5SpTPyuFOo=; b=NtimzJwRd1oOLzfqLEpEou2dd34Fo3jIrmoN3yRnicTHdyII4+PzQSPTZmpS4GQJpg BmVwQaAGjX0Gc5fDH5JZ9dPhMO2/0y8eUbeVSeQOfb9oGTutF6X/9sGsBE2VKAmDWyzW s/MniSv+pwOdGTouqAQ9iXDIs3YIzy0yxbId7zzDdlO+YHC98hM9I4eZGGSKjEwXzo4n ZRmnfoUM36SgX2o9Ly2JA0QuAWXFR1IX5IVJClt2bJ4fj9hhtoRBq0nluD7ZsXntSwT9 ruYSTEa3eWRwCePk0/8GxVwLdqy+M7z5PVO5Y3hxvFGYWw+Z33IbXVUxbZDRh8nczWoJ 0hWw== X-Gm-Message-State: ALoCoQkhpuPEXQW6r/x2tCw/NItmIKmz2W8Vu4zQgyg/K8y8XCUCINSS42Q43fn+Ky9ZlmWwoy9b X-Received: by 10.180.74.112 with SMTP id s16mr13762690wiv.73.1426276404187; Fri, 13 Mar 2015 12:53:24 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id dq1sm4105977wib.20.2015.03.13.12.53.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 12:53:23 -0700 (PDT) Message-ID: <55034031.9000905@multiplay.co.uk> Date: Fri, 13 Mar 2015 19:53:21 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <101866634.392324.1426276184167.JavaMail.open-xchange@ptangptang.store> In-Reply-To: <101866634.392324.1426276184167.JavaMail.open-xchange@ptangptang.store> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 20:00:03 -0000 On 13/03/2015 19:49, Michael Fuckner wrote: >> Adrian Chadd hat am 13. März 2015 um 19:02 geschrieben: > > Hi! > >> boot_verbose=YES looks to be right. > root@s4l:~ # grep verbose /boot/defaults/loader.conf > verbose_loading="NO" # Set to YES for verbose loader output > > OK, this confused me :-( > >> So hm, just to be clear - it boots fine if you don't load zfs/nvme/nvd? > yes, probably zfs, but why does loading nvme also come up with other devices > like mpr? I'm guessing because there is zfs volume on the flash drives which the nvme exposes? Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 20:07:11 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69EDAB43 for ; Fri, 13 Mar 2015 20:07:11 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD04EE84 for ; Fri, 13 Mar 2015 20:07:10 +0000 (UTC) Received: by wesp10 with SMTP id p10so25571675wes.11; Fri, 13 Mar 2015 13:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=uObI21A+//nEXlOCOGJRQFajcTd9hV+jpEd9Ogitq9o=; b=YvIr833210vB9ZF4p98D0pzUiImNkhfYuV9brso+0yIqfac4e/hfNr5iXGHfiGBtqA 01Vb8RRFCrOZgMMssWaEc7XhzkiONnaAhFy1N3Ai/EtZzLLFFzIGyALvCaLbtCdKE2RD ZF/Kbe+RrVYt7ui9gm8YAcqJQB/pwmy8zqiAWoLX+C8hAlS5XN1SUkka0Aus4uWT2hJk I/fz9znHOG+zAdxv7u+VY+AjV+8yALIeDzNefbgf6ytXkwBKtTisZzwiDxiseyTgGntm pD39b2Ntu8kBOE6slWxMabDlaIRI0r9ZLhILnmaZTUJrqWqM9xPnaqqZXiLcTEYUkWEy iBRw== X-Received: by 10.180.208.107 with SMTP id md11mr58253702wic.10.1426277229154; Fri, 13 Mar 2015 13:07:09 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id fm10sm4183793wib.7.2015.03.13.13.07.07 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 13:07:07 -0700 (PDT) Date: Fri, 13 Mar 2015 21:07:05 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'Convert mountlist_mtx to rwlock' Message-ID: <20150313200705.GA32157@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , Ryan Stone , "freebsd-hackers@freebsd.org" , wca@freebsd.org References: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> <20150312132338.GA57932@freebsd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150312132338.GA57932@freebsd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" , Ryan Stone , wca@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 20:07:11 -0000 On Thu, Mar 12, 2015 at 09:26:00PM +0800, Tiwei Bie wrote: > On Thu, Mar 12, 2015 at 12:06:02AM -0400, Ryan Stone wrote: > > On Wed, Mar 11, 2015 at 9:10 AM, Tiwei Bie wrote: > > > Hi, Mateusz! > > > > > > I have finished the task: Convert mountlist_mtx to rwlock [1]. > > > > My first comment is, are we sure that we actually want an rwlock here > > instead of an rmlock? An rmlock will offer much better performance in > > workloads that mostly only take read locks, and rmlocks do not suffer > > the priority inversion problems that rwlocks do. From the description > > on the wiki page, it sounds like an rmlock would be ideal here: > > > > > Interested person can upgrade this task to non-junior by coming up with a > > > solution exploiting rare need to modify the list. Example approaches include > > > designing a locking primitive with cheap shared locking (think: per-cpu) at > > > the expense of exclusive locking. > > > > I think rmlock is okay. But one more argument needs to be added > to vfs_busy(), that is 'struct rm_priotracker *tracker' which is > used to track read owners of mountlist_lock in vfs_busy(). So, this is not a simple s/rw_lock/rm_rlock and the like after all, sorry. :) I'll have to go over this and possibly gather some ACKs before committing. > > Following is my patch: > > --- > share/man/man9/vfs_busy.9 | 7 ++- > .../compat/opensolaris/kern/opensolaris_lookup.c | 2 +- > sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c | 5 ++- > .../opensolaris/uts/common/fs/zfs/zfs_ioctl.c | 6 ++- > .../opensolaris/uts/common/fs/zfs/zfs_vfsops.c | 6 ++- > sys/compat/linprocfs/linprocfs.c | 6 ++- > sys/fs/fuse/fuse_vnops.c | 4 +- > sys/fs/nfsclient/nfs_clstate.c | 2 +- > sys/fs/nfsclient/nfs_clvfsops.c | 2 +- > sys/fs/nfsclient/nfs_clvnops.c | 4 +- > sys/fs/nfsserver/nfs_nfsdport.c | 4 +- > sys/fs/nfsserver/nfs_nfsdserv.c | 2 +- > sys/fs/pseudofs/pseudofs_vnops.c | 6 +-- > sys/fs/smbfs/smbfs_vnops.c | 4 +- > sys/fs/tmpfs/tmpfs_vnops.c | 2 +- > sys/geom/journal/g_journal.c | 13 +++--- > sys/kern/vfs_extattr.c | 2 +- > sys/kern/vfs_lookup.c | 2 +- > sys/kern/vfs_mount.c | 26 ++++++----- > sys/kern/vfs_mountroot.c | 14 +++--- > sys/kern/vfs_subr.c | 51 ++++++++++++---------- > sys/kern/vfs_syscalls.c | 33 +++++++------- > sys/kern/vfs_vnops.c | 4 +- > sys/sys/mount.h | 8 ++-- > sys/ufs/ffs/ffs_softdep.c | 8 ++-- > sys/ufs/ffs/ffs_suspend.c | 2 +- > sys/ufs/ufs/ufs_quota.c | 2 +- > 27 files changed, 127 insertions(+), 100 deletions(-) > > diff --git a/share/man/man9/vfs_busy.9 b/share/man/man9/vfs_busy.9 > index 8b9ba86..155e1e6 100644 > --- a/share/man/man9/vfs_busy.9 > +++ b/share/man/man9/vfs_busy.9 > @@ -36,7 +36,7 @@ > .In sys/param.h > .In sys/mount.h > .Ft int > -.Fn vfs_busy "struct mount *mp" "int flags" > +.Fn vfs_busy "struct mount *mp" "int flags" "struct rm_priotracker *tracker" > .Sh DESCRIPTION > The > .Fn vfs_busy > @@ -68,8 +68,11 @@ do not sleep if > .Dv MNTK_UNMOUNT > is set. > .It Dv MBF_MNTLSTLOCK > -drop the mountlist_mtx in the critical path. > +drop the mountlist_lock in the critical path. > .El > +.It Fa tracker > +The tracker used to track read owners of mountlist_lock > +for priority propagation. > .El > .Sh RETURN VALUES > A 0 value is returned on success. > diff --git a/sys/cddl/compat/opensolaris/kern/opensolaris_lookup.c b/sys/cddl/compat/opensolaris/kern/opensolaris_lookup.c > index 848007e..8e1c657b 100644 > --- a/sys/cddl/compat/opensolaris/kern/opensolaris_lookup.c > +++ b/sys/cddl/compat/opensolaris/kern/opensolaris_lookup.c > @@ -88,7 +88,7 @@ traverse(vnode_t **cvpp, int lktype) > vfsp = vn_mountedvfs(cvp); > if (vfsp == NULL) > break; > - error = vfs_busy(vfsp, 0); > + error = vfs_busy(vfsp, 0, NULL); > /* > * tvp is NULL for *cvpp vnode, which we can't unlock. > * At least some callers expect the reference to be > diff --git a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c > index a2532f8..9476641 100644 > --- a/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c > +++ b/sys/cddl/compat/opensolaris/kern/opensolaris_vfs.c > @@ -36,6 +36,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > > MALLOC_DECLARE(M_MOUNT); > > @@ -222,9 +223,9 @@ mount_snapshot(kthread_t *td, vnode_t **vpp, const char *fstype, char *fspath, > > vp->v_mountedhere = mp; > /* Put the new filesystem on the mount list. */ > - mtx_lock(&mountlist_mtx); > + rm_wlock(&mountlist_lock); > TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); > - mtx_unlock(&mountlist_mtx); > + rm_wunlock(&mountlist_lock); > vfs_event_signal(NULL, VQ_MOUNT, 0); > if (VFS_ROOT(mp, LK_EXCLUSIVE, &mvp)) > panic("mount: lost mount"); > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > index a829b06..a684516 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > @@ -142,6 +142,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -3014,15 +3015,16 @@ static vfs_t * > zfs_get_vfs(const char *resource) > { > vfs_t *vfsp; > + struct rm_priotracker tracker; > > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > TAILQ_FOREACH(vfsp, &mountlist, mnt_list) { > if (strcmp(refstr_value(vfsp->vfs_resource), resource) == 0) { > VFS_HOLD(vfsp); > break; > } > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > return (vfsp); > } > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > index 415db9e..55e11a1 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c > @@ -62,6 +62,7 @@ > #include > #include > #include > +#include > #include "zfs_comutil.h" > > struct mtx zfs_debug_mtx; > @@ -2532,12 +2533,13 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) > { > char tmpbuf[MAXPATHLEN]; > struct mount *mp; > + struct rm_priotracker tracker; > char *fromname; > size_t oldlen; > > oldlen = strlen(oldname); > > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > fromname = mp->mnt_stat.f_mntfromname; > if (strcmp(fromname, oldname) == 0) { > @@ -2554,6 +2556,6 @@ zfsvfs_update_fromname(const char *oldname, const char *newname) > continue; > } > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > } > #endif > diff --git a/sys/compat/linprocfs/linprocfs.c b/sys/compat/linprocfs/linprocfs.c > index 8607646..2d5a538 100644 > --- a/sys/compat/linprocfs/linprocfs.c > +++ b/sys/compat/linprocfs/linprocfs.c > @@ -63,6 +63,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -327,6 +328,7 @@ linprocfs_domtab(PFS_FILL_ARGS) > { > struct nameidata nd; > struct mount *mp; > + struct rm_priotracker tracker; > const char *lep; > char *dlep, *flep, *mntto, *mntfrom, *fstype; > size_t lep_len; > @@ -344,7 +346,7 @@ linprocfs_domtab(PFS_FILL_ARGS) > } > lep_len = strlen(lep); > > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > error = 0; > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > /* determine device name */ > @@ -387,7 +389,7 @@ linprocfs_domtab(PFS_FILL_ARGS) > /* a real Linux mtab will also show NFS options */ > sbuf_printf(sb, " 0 0\n"); > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > free(flep, M_TEMP); > return (error); > } > diff --git a/sys/fs/fuse/fuse_vnops.c b/sys/fs/fuse/fuse_vnops.c > index 12b9778..b9827df 100644 > --- a/sys/fs/fuse/fuse_vnops.c > +++ b/sys/fs/fuse/fuse_vnops.c > @@ -902,11 +902,11 @@ calldaemon: > */ > mp = dvp->v_mount; > ltype = VOP_ISLOCKED(dvp); > - err = vfs_busy(mp, MBF_NOWAIT); > + err = vfs_busy(mp, MBF_NOWAIT, NULL); > if (err != 0) { > vfs_ref(mp); > VOP_UNLOCK(dvp, 0); > - err = vfs_busy(mp, 0); > + err = vfs_busy(mp, 0, NULL); > vn_lock(dvp, ltype | LK_RETRY); > vfs_rel(mp); > if (err) > diff --git a/sys/fs/nfsclient/nfs_clstate.c b/sys/fs/nfsclient/nfs_clstate.c > index 2600b80..8737003 100644 > --- a/sys/fs/nfsclient/nfs_clstate.c > +++ b/sys/fs/nfsclient/nfs_clstate.c > @@ -3621,7 +3621,7 @@ nfscl_getmnt(int minorvers, uint8_t *sessionid, u_int32_t cbident, > mp = clp->nfsc_nmp->nm_mountp; > vfs_ref(mp); > NFSUNLOCKCLSTATE(); > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > vfs_rel(mp); > if (error != 0) > return (NULL); > diff --git a/sys/fs/nfsclient/nfs_clvfsops.c b/sys/fs/nfsclient/nfs_clvfsops.c > index 9758b4c..aa8f8bc 100644 > --- a/sys/fs/nfsclient/nfs_clvfsops.c > +++ b/sys/fs/nfsclient/nfs_clvfsops.c > @@ -287,7 +287,7 @@ nfs_statfs(struct mount *mp, struct statfs *sbp) > > td = curthread; > > - error = vfs_busy(mp, MBF_NOWAIT); > + error = vfs_busy(mp, MBF_NOWAIT, NULL); > if (error) > return (error); > error = ncl_nget(mp, nmp->nm_fh, nmp->nm_fhsize, &np, LK_EXCLUSIVE); > diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c > index 513abf4..64a2eea 100644 > --- a/sys/fs/nfsclient/nfs_clvnops.c > +++ b/sys/fs/nfsclient/nfs_clvnops.c > @@ -1228,11 +1228,11 @@ nfs_lookup(struct vop_lookup_args *ap) > > if (flags & ISDOTDOT) { > ltype = NFSVOPISLOCKED(dvp); > - error = vfs_busy(mp, MBF_NOWAIT); > + error = vfs_busy(mp, MBF_NOWAIT, NULL); > if (error != 0) { > vfs_ref(mp); > NFSVOPUNLOCK(dvp, 0); > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > NFSVOPLOCK(dvp, ltype | LK_RETRY); > vfs_rel(mp); > if (error == 0 && (dvp->v_iflag & VI_DOOMED)) { > diff --git a/sys/fs/nfsserver/nfs_nfsdport.c b/sys/fs/nfsserver/nfs_nfsdport.c > index 0ea48cd..c8a80c8 100644 > --- a/sys/fs/nfsserver/nfs_nfsdport.c > +++ b/sys/fs/nfsserver/nfs_nfsdport.c > @@ -1985,7 +1985,7 @@ again: > mp = vp->v_mount; > vfs_ref(mp); > NFSVOPUNLOCK(vp, 0); > - nd->nd_repstat = vfs_busy(mp, 0); > + nd->nd_repstat = vfs_busy(mp, 0, NULL); > vfs_rel(mp); > if (nd->nd_repstat != 0) { > vrele(vp); > @@ -2134,7 +2134,7 @@ again: > nvp->v_type == VDIR && > nvp->v_mountedhere != NULL) { > new_mp = nvp->v_mountedhere; > - r = vfs_busy(new_mp, 0); > + r = vfs_busy(new_mp, 0, NULL); > vput(nvp); > nvp = NULL; > if (r == 0) { > diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c b/sys/fs/nfsserver/nfs_nfsdserv.c > index e6e02d7..39f87c4 100644 > --- a/sys/fs/nfsserver/nfs_nfsdserv.c > +++ b/sys/fs/nfsserver/nfs_nfsdserv.c > @@ -271,7 +271,7 @@ nfsrvd_getattr(struct nfsrv_descript *nd, int isdgram, > at_root = 0; > } > if (nd->nd_repstat == 0) > - nd->nd_repstat = vfs_busy(mp, 0); > + nd->nd_repstat = vfs_busy(mp, 0, NULL); > vfs_rel(mp); > if (nd->nd_repstat == 0) { > (void)nfsvno_fillattr(nd, mp, vp, &nva, > diff --git a/sys/fs/pseudofs/pseudofs_vnops.c b/sys/fs/pseudofs/pseudofs_vnops.c > index f00b4b2..a0852ce 100644 > --- a/sys/fs/pseudofs/pseudofs_vnops.c > +++ b/sys/fs/pseudofs/pseudofs_vnops.c > @@ -392,7 +392,7 @@ pfs_vptocnp(struct vop_vptocnp_args *ap) > pfs_unlock(pd); > > mp = vp->v_mount; > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > if (error) > return (error); > > @@ -481,11 +481,11 @@ pfs_lookup(struct vop_cachedlookup_args *va) > if (cnp->cn_flags & ISDOTDOT) { > if (pd->pn_type == pfstype_root) > PFS_RETURN (EIO); > - error = vfs_busy(mp, MBF_NOWAIT); > + error = vfs_busy(mp, MBF_NOWAIT, NULL); > if (error != 0) { > vfs_ref(mp); > VOP_UNLOCK(vn, 0); > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > vn_lock(vn, LK_EXCLUSIVE | LK_RETRY); > vfs_rel(mp); > if (error != 0) > diff --git a/sys/fs/smbfs/smbfs_vnops.c b/sys/fs/smbfs/smbfs_vnops.c > index 8ea1198..e0736fd 100644 > --- a/sys/fs/smbfs/smbfs_vnops.c > +++ b/sys/fs/smbfs/smbfs_vnops.c > @@ -1324,11 +1324,11 @@ smbfs_lookup(ap) > } > if (flags & ISDOTDOT) { > mp = dvp->v_mount; > - error = vfs_busy(mp, MBF_NOWAIT); > + error = vfs_busy(mp, MBF_NOWAIT, NULL); > if (error != 0) { > vfs_ref(mp); > VOP_UNLOCK(dvp, 0); > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY); > vfs_rel(mp); > if (error) { > diff --git a/sys/fs/tmpfs/tmpfs_vnops.c b/sys/fs/tmpfs/tmpfs_vnops.c > index 885f84c..a366170 100644 > --- a/sys/fs/tmpfs/tmpfs_vnops.c > +++ b/sys/fs/tmpfs/tmpfs_vnops.c > @@ -789,7 +789,7 @@ tmpfs_rename(struct vop_rename_args *v) > if (fdvp != tdvp && fdvp != tvp) { > if (vn_lock(fdvp, LK_EXCLUSIVE | LK_NOWAIT) != 0) { > mp = tdvp->v_mount; > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > if (error != 0) { > mp = NULL; > goto out; > diff --git a/sys/geom/journal/g_journal.c b/sys/geom/journal/g_journal.c > index 9cc324c..3c2066e 100644 > --- a/sys/geom/journal/g_journal.c > +++ b/sys/geom/journal/g_journal.c > @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -2867,6 +2868,7 @@ g_journal_do_switch(struct g_class *classp) > const struct g_journal_desc *desc; > struct g_geom *gp; > struct mount *mp; > + struct rm_priotracker tracker; > struct bintime bt; > char *mountpoint; > int error, save; > @@ -2888,7 +2890,7 @@ g_journal_do_switch(struct g_class *classp) > g_topology_unlock(); > PICKUP_GIANT(); > > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > if (mp->mnt_gjprovider == NULL) > continue; > @@ -2897,9 +2899,10 @@ g_journal_do_switch(struct g_class *classp) > desc = g_journal_find_desc(mp->mnt_stat.f_fstypename); > if (desc == NULL) > continue; > - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) > + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) > continue; > - /* mtx_unlock(&mountlist_mtx) was done inside vfs_busy() */ > + /* rm_runlock(&mountlist_lock, &tracker) was done inside > + * vfs_busy() */ > > DROP_GIANT(); > g_topology_lock(); > @@ -2977,10 +2980,10 @@ g_journal_do_switch(struct g_class *classp) > > vfs_write_resume(mp, 0); > next: > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > vfs_unbusy(mp); > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > > sc = NULL; > for (;;) { > diff --git a/sys/kern/vfs_extattr.c b/sys/kern/vfs_extattr.c > index 24935ce..a82eddaf 100644 > --- a/sys/kern/vfs_extattr.c > +++ b/sys/kern/vfs_extattr.c > @@ -104,7 +104,7 @@ sys_extattrctl(td, uap) > if (error) > goto out; > mp = nd.ni_vp->v_mount; > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > if (error) { > NDFREE(&nd, 0); > mp = NULL; > diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c > index f2ffab2..610aa5f 100644 > --- a/sys/kern/vfs_lookup.c > +++ b/sys/kern/vfs_lookup.c > @@ -779,7 +779,7 @@ unionlookup: > */ > while (dp->v_type == VDIR && (mp = dp->v_mountedhere) && > (cnp->cn_flags & NOCROSSMOUNT) == 0) { > - if (vfs_busy(mp, 0)) > + if (vfs_busy(mp, 0, NULL)) > continue; > vput(dp); > if (dp != ndp->ni_dvp) > diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c > index 09fa7ed..636a55f 100644 > --- a/sys/kern/vfs_mount.c > +++ b/sys/kern/vfs_mount.c > @@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -85,8 +86,8 @@ static uma_zone_t mount_zone; > struct mntlist mountlist = TAILQ_HEAD_INITIALIZER(mountlist); > > /* For any iteration/modification of mountlist */ > -struct mtx mountlist_mtx; > -MTX_SYSINIT(mountlist, &mountlist_mtx, "mountlist", MTX_DEF); > +struct rmlock mountlist_lock; > +RM_SYSINIT(mountlist, &mountlist_lock, "mountlist"); > > /* > * Global opts, taken by all filesystems > @@ -462,7 +463,7 @@ vfs_mount_alloc(struct vnode *vp, struct vfsconf *vfsp, const char *fspath, > TAILQ_INIT(&mp->mnt_activevnodelist); > mp->mnt_activevnodelistsize = 0; > mp->mnt_ref = 0; > - (void) vfs_busy(mp, MBF_NOWAIT); > + (void) vfs_busy(mp, MBF_NOWAIT, NULL); > atomic_add_acq_int(&vfsp->vfc_refcount, 1); > mp->mnt_op = vfsp->vfc_vfsops; > mp->mnt_vfc = vfsp; > @@ -852,9 +853,9 @@ vfs_domount_first( > VI_UNLOCK(vp); > vp->v_mountedhere = mp; > /* Place the new filesystem at the end of the mount list. */ > - mtx_lock(&mountlist_mtx); > + rm_wlock(&mountlist_lock); > TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); > - mtx_unlock(&mountlist_mtx); > + rm_wunlock(&mountlist_lock); > vfs_event_signal(NULL, VQ_MOUNT, 0); > if (VFS_ROOT(mp, LK_EXCLUSIVE, &newdp)) > panic("mount: lost mount"); > @@ -918,7 +919,7 @@ vfs_domount_update( > vput(vp); > return (error); > } > - if (vfs_busy(mp, MBF_NOWAIT)) { > + if (vfs_busy(mp, MBF_NOWAIT, NULL)) { > vput(vp); > return (EBUSY); > } > @@ -1137,6 +1138,7 @@ sys_unmount(td, uap) > { > struct nameidata nd; > struct mount *mp; > + struct rm_priotracker tracker; > char *pathbuf; > int error, id0, id1; > > @@ -1161,13 +1163,13 @@ sys_unmount(td, uap) > return (EINVAL); > } > > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > TAILQ_FOREACH_REVERSE(mp, &mountlist, mntlist, mnt_list) { > if (mp->mnt_stat.f_fsid.val[0] == id0 && > mp->mnt_stat.f_fsid.val[1] == id1) > break; > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > } else { > /* > * Try to find global path for path argument. > @@ -1181,12 +1183,12 @@ sys_unmount(td, uap) > if (error == 0 || error == ENODEV) > vput(nd.ni_vp); > } > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > TAILQ_FOREACH_REVERSE(mp, &mountlist, mntlist, mnt_list) { > if (strcmp(mp->mnt_stat.f_mntonname, pathbuf) == 0) > break; > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > } > free(pathbuf, M_TEMP); > if (mp == NULL) { > @@ -1353,9 +1355,9 @@ dounmount(mp, flags, td) > VOP_UNLOCK(coveredvp, 0); > return (error); > } > - mtx_lock(&mountlist_mtx); > + rm_wlock(&mountlist_lock); > TAILQ_REMOVE(&mountlist, mp, mnt_list); > - mtx_unlock(&mountlist_mtx); > + rm_wunlock(&mountlist_lock); > EVENTHANDLER_INVOKE(vfs_unmounted, mp, td); > if (coveredvp != NULL) { > coveredvp->v_mountedhere = NULL; > diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c > index a050099..ef3e9c9 100644 > --- a/sys/kern/vfs_mountroot.c > +++ b/sys/kern/vfs_mountroot.c > @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -231,9 +232,9 @@ vfs_mountroot_devfs(struct thread *td, struct mount **mpp) > TAILQ_INIT(opts); > mp->mnt_opt = opts; > > - mtx_lock(&mountlist_mtx); > + rm_wlock(&mountlist_lock); > TAILQ_INSERT_HEAD(&mountlist, mp, mnt_list); > - mtx_unlock(&mountlist_mtx); > + rm_wunlock(&mountlist_lock); > > *mpp = mp; > set_rootvnode(); > @@ -257,7 +258,7 @@ vfs_mountroot_shuffle(struct thread *td, struct mount *mpdevfs) > mpnroot = TAILQ_NEXT(mpdevfs, mnt_list); > > /* Shuffle the mountlist. */ > - mtx_lock(&mountlist_mtx); > + rm_wlock(&mountlist_lock); > mporoot = TAILQ_FIRST(&mountlist); > TAILQ_REMOVE(&mountlist, mpdevfs, mnt_list); > if (mporoot != mpdevfs) { > @@ -265,7 +266,7 @@ vfs_mountroot_shuffle(struct thread *td, struct mount *mpdevfs) > TAILQ_INSERT_HEAD(&mountlist, mpnroot, mnt_list); > } > TAILQ_INSERT_TAIL(&mountlist, mpdevfs, mnt_list); > - mtx_unlock(&mountlist_mtx); > + rm_wunlock(&mountlist_lock); > > cache_purgevfs(mporoot); > if (mporoot != mpdevfs) > @@ -933,6 +934,7 @@ void > vfs_mountroot(void) > { > struct mount *mp; > + struct rm_priotracker tracker; > struct sbuf *sb; > struct thread *td; > time_t timebase; > @@ -968,14 +970,14 @@ vfs_mountroot(void) > * timestamps we encounter. > */ > timebase = 0; > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > mp = TAILQ_FIRST(&mountlist); > while (mp != NULL) { > if (mp->mnt_time > timebase) > timebase = mp->mnt_time; > mp = TAILQ_NEXT(mp, mnt_list); > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > inittodr(timebase); > > /* Keep prison0's root in sync with the global rootvnode. */ > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > index fda80c9..3733178 100644 > --- a/sys/kern/vfs_subr.c > +++ b/sys/kern/vfs_subr.c > @@ -68,6 +68,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -375,7 +376,7 @@ SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_FIRST, vntblinit, NULL); > > /* > * Mark a mount point as busy. Used to synchronize access and to delay > - * unmounting. Eventually, mountlist_mtx is not released on failure. > + * unmounting. Eventually, mountlist_lock is not released on failure. > * > * vfs_busy() is a custom lock, it can block the caller. > * vfs_busy() only sleeps if the unmount is active on the mount point. > @@ -410,7 +411,7 @@ SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_FIRST, vntblinit, NULL); > * dounmount() locks B while F is drained. > */ > int > -vfs_busy(struct mount *mp, int flags) > +vfs_busy(struct mount *mp, int flags, struct rm_priotracker *tracker) > { > > MPASS((flags & ~MBF_MASK) == 0); > @@ -439,15 +440,15 @@ vfs_busy(struct mount *mp, int flags) > return (ENOENT); > } > if (flags & MBF_MNTLSTLOCK) > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, tracker); > mp->mnt_kern_flag |= MNTK_MWAIT; > msleep(mp, MNT_MTX(mp), PVFS | PDROP, "vfs_busy", 0); > if (flags & MBF_MNTLSTLOCK) > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, tracker); > MNT_ILOCK(mp); > } > if (flags & MBF_MNTLSTLOCK) > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, tracker); > mp->mnt_lockref++; > MNT_IUNLOCK(mp); > return (0); > @@ -481,18 +482,19 @@ struct mount * > vfs_getvfs(fsid_t *fsid) > { > struct mount *mp; > + struct rm_priotracker tracker; > > CTR2(KTR_VFS, "%s: fsid %p", __func__, fsid); > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > if (mp->mnt_stat.f_fsid.val[0] == fsid->val[0] && > mp->mnt_stat.f_fsid.val[1] == fsid->val[1]) { > vfs_ref(mp); > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > return (mp); > } > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > CTR2(KTR_VFS, "%s: lookup failed for %p id", __func__, fsid); > return ((struct mount *) 0); > } > @@ -501,7 +503,7 @@ vfs_getvfs(fsid_t *fsid) > * Lookup a mount point by filesystem identifier, busying it before > * returning. > * > - * To avoid congestion on mountlist_mtx, implement simple direct-mapped > + * To avoid congestion on mountlist_lock, implement simple direct-mapped > * cache for popular filesystem identifiers. The cache is lockess, using > * the fact that struct mount's are never freed. In worst case we may > * get pointer to unmounted or even different filesystem, so we have to > @@ -514,6 +516,7 @@ vfs_busyfs(fsid_t *fsid) > typedef struct mount * volatile vmp_t; > static vmp_t cache[FSID_CACHE_SIZE]; > struct mount *mp; > + struct rm_priotracker tracker; > int error; > uint32_t hash; > > @@ -525,7 +528,7 @@ vfs_busyfs(fsid_t *fsid) > mp->mnt_stat.f_fsid.val[0] != fsid->val[0] || > mp->mnt_stat.f_fsid.val[1] != fsid->val[1]) > goto slow; > - if (vfs_busy(mp, 0) != 0) { > + if (vfs_busy(mp, 0, NULL) != 0) { > cache[hash] = NULL; > goto slow; > } > @@ -536,14 +539,14 @@ vfs_busyfs(fsid_t *fsid) > vfs_unbusy(mp); > > slow: > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > if (mp->mnt_stat.f_fsid.val[0] == fsid->val[0] && > mp->mnt_stat.f_fsid.val[1] == fsid->val[1]) { > - error = vfs_busy(mp, MBF_MNTLSTLOCK); > + error = vfs_busy(mp, MBF_MNTLSTLOCK, &tracker); > if (error) { > cache[hash] = NULL; > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > return (NULL); > } > cache[hash] = mp; > @@ -551,7 +554,7 @@ slow: > } > } > CTR2(KTR_VFS, "%s: lookup failed for %p id", __func__, fsid); > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > return ((struct mount *) 0); > } > > @@ -891,6 +894,7 @@ vnlru_proc(void) > struct mount *mp, *nmp; > int done; > struct proc *p = vnlruproc; > + struct rm_priotracker tracker; > > EVENTHANDLER_REGISTER(shutdown_pre_sync, kproc_shutdown, p, > SHUTDOWN_PRI_FIRST); > @@ -909,18 +913,18 @@ vnlru_proc(void) > } > mtx_unlock(&vnode_free_list_mtx); > done = 0; > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { > - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) { > + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) { > nmp = TAILQ_NEXT(mp, mnt_list); > continue; > } > done += vlrureclaim(mp); > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > nmp = TAILQ_NEXT(mp, mnt_list); > vfs_unbusy(mp); > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > if (done == 0) { > #if 0 > /* These messages are temporary debugging aids */ > @@ -3397,6 +3401,7 @@ sysctl_vnode(SYSCTL_HANDLER_ARGS) > struct xvnode *xvn; > struct mount *mp; > struct vnode *vp; > + struct rm_priotracker tracker; > int error, len, n; > > /* > @@ -3413,9 +3418,9 @@ sysctl_vnode(SYSCTL_HANDLER_ARGS) > return (error); > xvn = malloc(len, M_TEMP, M_ZERO | M_WAITOK); > n = 0; > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) > + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) > continue; > MNT_ILOCK(mp); > TAILQ_FOREACH(vp, &mp->mnt_nvnodelist, v_nmntvnodes) { > @@ -3465,12 +3470,12 @@ sysctl_vnode(SYSCTL_HANDLER_ARGS) > ++n; > } > MNT_IUNLOCK(mp); > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > vfs_unbusy(mp); > if (n == len) > break; > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > > error = SYSCTL_OUT(req, xvn, n * sizeof *xvn); > free(xvn, M_TEMP); > @@ -3760,7 +3765,7 @@ sync_fsync(struct vop_fsync_args *ap) > * Walk the list of vnodes pushing all that are dirty and > * not already on the sync list. > */ > - if (vfs_busy(mp, MBF_NOWAIT) != 0) > + if (vfs_busy(mp, MBF_NOWAIT, NULL) != 0) > return (0); > if (vn_start_write(NULL, &mp, V_NOWAIT) != 0) { > vfs_unbusy(mp); > diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c > index 14be379..0d3ae31 100644 > --- a/sys/kern/vfs_syscalls.c > +++ b/sys/kern/vfs_syscalls.c > @@ -60,6 +60,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -129,11 +130,12 @@ sys_sync(td, uap) > struct sync_args *uap; > { > struct mount *mp, *nmp; > + struct rm_priotracker tracker; > int save; > > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { > - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) { > + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) { > nmp = TAILQ_NEXT(mp, mnt_list); > continue; > } > @@ -145,11 +147,11 @@ sys_sync(td, uap) > curthread_pflags_restore(save); > vn_finished_write(mp); > } > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > nmp = TAILQ_NEXT(mp, mnt_list); > vfs_unbusy(mp); > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > return (0); > } > > @@ -190,7 +192,7 @@ sys_quotactl(td, uap) > mp = nd.ni_vp->v_mount; > vfs_ref(mp); > vput(nd.ni_vp); > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > vfs_rel(mp); > if (error != 0) > return (error); > @@ -297,7 +299,7 @@ kern_statfs(struct thread *td, char *path, enum uio_seg pathseg, > vfs_ref(mp); > NDFREE(&nd, NDF_ONLY_PNBUF); > vput(nd.ni_vp); > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > vfs_rel(mp); > if (error != 0) > return (error); > @@ -383,7 +385,7 @@ kern_fstatfs(struct thread *td, int fd, struct statfs *buf) > error = EBADF; > goto out; > } > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > vfs_rel(mp); > if (error != 0) > return (error); > @@ -449,6 +451,7 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, > enum uio_seg bufseg, int flags) > { > struct mount *mp, *nmp; > + struct rm_priotracker tracker; > struct statfs *sfsp, *sp, sb; > size_t count, maxcount; > int error; > @@ -460,18 +463,18 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, > sfsp = *buf; > else /* if (bufseg == UIO_SYSSPACE) */ { > count = 0; > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > count++; > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > if (maxcount > count) > maxcount = count; > sfsp = *buf = malloc(maxcount * sizeof(struct statfs), M_TEMP, > M_WAITOK); > } > count = 0; > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { > if (prison_canseemount(td->td_ucred, mp) != 0) { > nmp = TAILQ_NEXT(mp, mnt_list); > @@ -483,7 +486,7 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, > continue; > } > #endif > - if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK)) { > + if (vfs_busy(mp, MBF_NOWAIT | MBF_MNTLSTLOCK, &tracker)) { > nmp = TAILQ_NEXT(mp, mnt_list); > continue; > } > @@ -504,7 +507,7 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, > if (((flags & (MNT_LAZY|MNT_NOWAIT)) == 0 || > (flags & MNT_WAIT)) && > (error = VFS_STATFS(mp, sp))) { > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > nmp = TAILQ_NEXT(mp, mnt_list); > vfs_unbusy(mp); > continue; > @@ -527,11 +530,11 @@ kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize, > sfsp++; > } > count++; > - mtx_lock(&mountlist_mtx); > + rm_rlock(&mountlist_lock, &tracker); > nmp = TAILQ_NEXT(mp, mnt_list); > vfs_unbusy(mp); > } > - mtx_unlock(&mountlist_mtx); > + rm_runlock(&mountlist_lock, &tracker); > if (sfsp && count > maxcount) > td->td_retval[0] = maxcount; > else > @@ -741,7 +744,7 @@ sys_fchdir(td, uap) > AUDIT_ARG_VNODE1(vp); > error = change_dir(vp, td); > while (!error && (mp = vp->v_mountedhere) != NULL) { > - if (vfs_busy(mp, 0)) > + if (vfs_busy(mp, 0, NULL)) > continue; > error = VFS_ROOT(mp, LK_SHARED, &tdp); > vfs_unbusy(mp); > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index ed4ad4d..8d38305 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -2059,11 +2059,11 @@ vn_vget_ino_gen(struct vnode *vp, vn_get_ino_t alloc, void *alloc_arg, > ltype = VOP_ISLOCKED(vp); > KASSERT(ltype == LK_EXCLUSIVE || ltype == LK_SHARED, > ("vn_vget_ino: vp not locked")); > - error = vfs_busy(mp, MBF_NOWAIT); > + error = vfs_busy(mp, MBF_NOWAIT, NULL); > if (error != 0) { > vfs_ref(mp); > VOP_UNLOCK(vp, 0); > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > vn_lock(vp, ltype | LK_RETRY); > vfs_rel(mp); > if (error != 0) > diff --git a/sys/sys/mount.h b/sys/sys/mount.h > index 6fb2d08..6c47d7f 100644 > --- a/sys/sys/mount.h > +++ b/sys/sys/mount.h > @@ -38,7 +38,9 @@ > #ifdef _KERNEL > #include > #include > +#include > #include > +#include > #include > #endif > > @@ -147,7 +149,7 @@ struct vfsopt { > * put on a doubly linked list. > * > * Lock reference: > - * m - mountlist_mtx > + * m - mountlist_lock > * i - interlock > * v - vnode freelist mutex > * > @@ -864,7 +866,7 @@ int vfs_setopts(struct vfsoptlist *opts, const char *name, > int vfs_setpublicfs /* set publicly exported fs */ > (struct mount *, struct netexport *, struct export_args *); > void vfs_msync(struct mount *, int); > -int vfs_busy(struct mount *, int); > +int vfs_busy(struct mount *, int, struct rm_priotracker *); > int vfs_export /* process mount export info */ > (struct mount *, struct export_args *); > void vfs_allocate_syncvnode(struct mount *); > @@ -890,7 +892,7 @@ int vfs_suser(struct mount *, struct thread *); > void vfs_unbusy(struct mount *); > void vfs_unmountall(void); > extern TAILQ_HEAD(mntlist, mount) mountlist; /* mounted filesystem list */ > -extern struct mtx mountlist_mtx; > +extern struct rmlock mountlist_lock; > extern struct nfs_public nfs_pub; > extern struct sx vfsconf_sx; > #define vfsconf_lock() sx_xlock(&vfsconf_sx) > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > index 700854e..8545df0 100644 > --- a/sys/ufs/ffs/ffs_softdep.c > +++ b/sys/ufs/ffs/ffs_softdep.c > @@ -12274,11 +12274,11 @@ restart: > FREE_LOCK(ump); > if (ffs_vgetf(mp, parentino, LK_NOWAIT | LK_EXCLUSIVE, &pvp, > FFSV_FORCEINSMQ)) { > - error = vfs_busy(mp, MBF_NOWAIT); > + error = vfs_busy(mp, MBF_NOWAIT, NULL); > if (error != 0) { > vfs_ref(mp); > VOP_UNLOCK(vp, 0); > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); > vfs_rel(mp); > if (error != 0) > @@ -13427,7 +13427,7 @@ clear_remove(mp) > /* > * Let unmount clear deps > */ > - error = vfs_busy(mp, MBF_NOWAIT); > + error = vfs_busy(mp, MBF_NOWAIT, NULL); > if (error != 0) > goto finish_write; > error = ffs_vgetf(mp, ino, LK_EXCLUSIVE, &vp, > @@ -13503,7 +13503,7 @@ clear_inodedeps(mp) > if (vn_start_write(NULL, &mp, V_NOWAIT) != 0) > continue; > FREE_LOCK(ump); > - error = vfs_busy(mp, MBF_NOWAIT); /* Let unmount clear deps */ > + error = vfs_busy(mp, MBF_NOWAIT, NULL); /* Let unmount clear deps */ > if (error != 0) { > vn_finished_write(mp); > ACQUIRE_LOCK(ump); > diff --git a/sys/ufs/ffs/ffs_suspend.c b/sys/ufs/ffs/ffs_suspend.c > index b50fadc..6513a21 100644 > --- a/sys/ufs/ffs/ffs_suspend.c > +++ b/sys/ufs/ffs/ffs_suspend.c > @@ -286,7 +286,7 @@ ffs_susp_ioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flags, > error = ENOENT; > break; > } > - error = vfs_busy(mp, 0); > + error = vfs_busy(mp, 0, NULL); > vfs_rel(mp); > if (error != 0) > break; > diff --git a/sys/ufs/ufs/ufs_quota.c b/sys/ufs/ufs/ufs_quota.c > index 4fbb8a1..3d17622 100644 > --- a/sys/ufs/ufs/ufs_quota.c > +++ b/sys/ufs/ufs/ufs_quota.c > @@ -519,7 +519,7 @@ quotaon(struct thread *td, struct mount *mp, int type, void *fname) > } > NDFREE(&nd, NDF_ONLY_PNBUF); > vp = nd.ni_vp; > - error = vfs_busy(mp, MBF_NOWAIT); > + error = vfs_busy(mp, MBF_NOWAIT, NULL); > vfs_rel(mp); > if (error == 0) { > if (vp->v_type != VREG) { > -- > 2.1.2 > > > The rmlock primitive does exactly this optimization. See the manpage > > for the API (it's mostly very similar to the rwlock API): > > https://www.freebsd.org/cgi/man.cgi?query=rmlock&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html > > > > > > > void zfs_mountlist_wlock(void); > > > void zfs_mountlist_wunlock(void); > > > void zfs_mountlist_rlock(void); > > > void zfs_mountlist_runlock(void); > > > > Why not: > > > > #define zfs_mountlist_wlock() _zfs_mountlist_wlock(__FILE__, __LINE__) > > void _zfs_mountlist_wlock(const char *file, int line); > > > > /* etc, etc */ > > > > (This may be moot if we switch to an rmlock though) > > Tiwei Bie > -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 20:26:19 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E30E62C; Fri, 13 Mar 2015 20:26:19 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49558108; Fri, 13 Mar 2015 20:26:19 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2DKS1ME005725; Fri, 13 Mar 2015 13:28:04 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: Adrian Chadd , Michael Fuckner In-Reply-To: <101866634.392324.1426276184167.JavaMail.open-xchange@ptangptang.store> References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> , <101866634.392324.1426276184167.JavaMail.open-xchange@ptangptang.store> From: "Chris H" Subject: Re: Server with 3TB Crashing at boot Date: Fri, 13 Mar 2015 13:28:05 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <72adbbf534c673c111c0b8cec018318b@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: "freebsd-hackers@freebsd.org" , Oliver Pinter , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 20:26:19 -0000 On Fri, 13 Mar 2015 20:49:44 +0100 (CET) Michael Fuckner wrote > > Adrian Chadd hat am 13. März 2015 um 19:02 > > geschrieben: > > Hi! > > > boot_verbose=YES looks to be right. > > root@s4l:~ # grep verbose /boot/defaults/loader.conf > verbose_loading="NO" # Set to YES for verbose loader output > > OK, this confused me :-( In case it's still not clear: The values your copy of loader.conf located as /boot/loader.conf overrides the values set in /boot/defaults/loader.conf --Chris > > > So hm, just to be clear - it boots fine if you don't load zfs/nvme/nvd? > yes, probably zfs, but why does loading nvme also come up with other devices > like mpr? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 20:38:39 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 995748F5; Fri, 13 Mar 2015 20:38:39 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9877211; Fri, 13 Mar 2015 20:38:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426279092; l=2485; s=domk; d=fuckner.net; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Cc:To: Reply-To:From:Date; bh=/JrWJ2QROOgHOW12w+sjfZ+ks3ZKV70Ai7MCTsf1a9A=; b=QSKN86SssjVk1F8Rv9Sx1BmNXqLzuRCrB3gkC7tKQP/Kv6nWGq6yI+Ezj4dp0aWqmyz WGV4PR9ySC1fCPpH1Sw1ViyT4Pu7/y2pEDaiDu5M4eqTDdv5lMDsEqw5D/BZ86RsxkPT8 s+gqdCf/2cqLBXUDQaZvPVce/4lMm4Jp6+M= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTEGbkn8hussqFHiy/c+oYVPeezIVIZYA== X-RZG-CLASS-ID: mo00 Received: from ptangptang.store (com4.strato.de [81.169.145.237]) by smtp-ox.front (RZmta 37.4 AUTH) with ESMTPSA id x02882r2DKc1Ajs (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate); Fri, 13 Mar 2015 21:38:01 +0100 (CET) Date: Fri, 13 Mar 2015 21:38:01 +0100 (CET) From: Michael Fuckner Reply-To: Michael Fuckner To: Chris H , Adrian Chadd Message-ID: <1037310890.395652.1426279081703.JavaMail.open-xchange@ptangptang.store> In-Reply-To: <72adbbf534c673c111c0b8cec018318b@ultimatedns.net> References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> , <101866634.392324.1426276184167.JavaMail.open-xchange@ptangptang.store> <72adbbf534c673c111c0b8cec018318b@ultimatedns.net> Subject: Re: Server with 3TB Crashing at boot MIME-Version: 1.0 X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.0-Rev36 X-Originating-Client: com.openexchange.ox.gui.dhtml Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Oliver Pinter , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 20:38:39 -0000 > Chris H hat am 13. M=C3=A4rz 2015 um 21:28 gesch= rieben: > > > On Fri, 13 Mar 2015 20:49:44 +0100 (CET) Michael Fuckner > wrote > > > > Adrian Chadd hat am 13. M=C3=A4rz 2015 um 19:02 > > > geschrieben: > > > > Hi! > > > > > boot_verbose=3DYES looks to be right. > > > > root@s4l:~ # grep verbose /boot/defaults/loader.conf > > verbose_loading=3D"NO" # Set to YES for verbose loader output > > > > OK, this confused me :-( > In case it's still not clear: > The values your copy of loader.conf located as /boot/loader.conf > overrides the values set in /boot/defaults/loader.conf >=20 that is clear to me, but I was confused by verbose_loading vs boot_verbose From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 20:42:08 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 976E4A67 for ; Fri, 13 Mar 2015 20:42:08 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 222982FE for ; Fri, 13 Mar 2015 20:42:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426279324; l=2202; s=domk; d=fuckner.net; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Cc:To: Reply-To:From:Date; bh=vs6uouku9cC80mBHC+Uaqbx2U6xBAy7BrMckhA+mS38=; b=w+Xwc1xg+ZMG44IjLmj4qSIdih7VyGNw+dkkdNJPvX3eSuvCj6Gsi1XmhKhEVUfeuNC 8XTr09E1Sx7mtJgg0alT7Hg/Np00v7xe0fSsiekxAIPGaVcR6LEvacUySo51Dsgqp8qod aw9H+tZ2D39J4IQkjB71l4qjYH30iPAmm0U= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTEGbkn8hussqFHiy/c+oYVPeezIVIZYA== X-RZG-CLASS-ID: mo00 Received: from ptangptang.store (com4.strato.de [81.169.145.237]) by smtp-ox.front (RZmta 37.4 AUTH) with ESMTPSA id J0345cr2DKg48QW (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate); Fri, 13 Mar 2015 21:42:04 +0100 (CET) Date: Fri, 13 Mar 2015 21:42:04 +0100 (CET) From: Michael Fuckner Reply-To: Michael Fuckner To: Steven Hartland , Ryan Stone Message-ID: <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> In-Reply-To: References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> Subject: Re: Server with 3TB Crashing at boot MIME-Version: 1.0 X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.0-Rev36 X-Originating-Client: com.openexchange.ox.gui.dhtml Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 20:42:08 -0000 > Ryan Stone hat am 13. M=C3=A4rz 2015 um 20:40 geschri= eben: > > > On Fri, Mar 13, 2015 at 2:27 PM, Steven Hartland > wrote: > > > Looks like that's panicing when allocating the zfs dbuf hash table, whi= ch > > by my calculation should be requesting 8GB for a 4TB physmem? > > > > Interesting observation. Michael, can you try booting with this patch > applied? There is a bug in the kernel when we attempt to malloc() more > than 4GB. > > https://people.freebsd.org/~rstone/patches/vm_64bit_malloc.diff Now I can kldload zfs without exploding kernel. I'll do some more tests tomorrow, but this looks fine! From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 21:17:57 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22E088E3 for ; Fri, 13 Mar 2015 21:17:57 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D10278AB for ; Fri, 13 Mar 2015 21:17:56 +0000 (UTC) Received: by ieclw3 with SMTP id lw3so127475053iec.2 for ; Fri, 13 Mar 2015 14:17:56 -0700 (PDT) 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=82pvanoN/cmbHgq07gbdsXOz9eFkTuZu5zRhXwiIQcg=; b=C8X6lZ0fzQ6QR5NTkd0olUYL6TwtTZogoETyxGhcWZEOoOjIktglRyEMMKgU1DENQ+ o286PPgc4rA/SPz8HEzQ3J7Eia4AiBxPNEmxUL2irzuJnEeVfhGgsoG8zp6RYcr7gIAo 9CuMNEy90KnGO+ZuChbF7156JvNaCbA0XDXT5PTGJUNxEQCdjPuhh/C/LvI4xmg2CVaE OvnVW+GH/xLxZnCcAKuDEz4SaXsLi6FIw1z/7Q0QP+nVArsMTW3CFj6hXpwGCoeD6OHW Luqr/L8zmI2I91GXq5v4V38dNXoPUQ5dO9KVgS92+IuIpZZld9JDIcBGe07KfdHxAj6P 7XXw== MIME-Version: 1.0 X-Received: by 10.107.168.5 with SMTP id r5mr86591388ioe.87.1426281476045; Fri, 13 Mar 2015 14:17:56 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Fri, 13 Mar 2015 14:17:55 -0700 (PDT) In-Reply-To: <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> Date: Fri, 13 Mar 2015 17:17:55 -0400 Message-ID: Subject: Re: Server with 3TB Crashing at boot From: Ryan Stone To: Michael Fuckner Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Steven Hartland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 21:17:57 -0000 On Fri, Mar 13, 2015 at 4:42 PM, Michael Fuckner wrote: > Now I can kldload zfs without exploding kernel. I'll do some more tests > tomorrow, but this looks fine! > Excellent news! I'd be interested to know whether this fixes the panics that you saw when zfs.ko was loaded by the bootloader. It's definitely possible, as the symptoms of this bug are likely to be random memory corruption after zfs initializes, but your crash happened pretty early on and I'm not sure whether zfs would have had a chance to do anything that early. Thanks for all of the work that you did to debug this. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 13 23:59:42 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F31CD957; Fri, 13 Mar 2015 23:59:41 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C391B35; Fri, 13 Mar 2015 23:59:41 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2E01QIo046620; Fri, 13 Mar 2015 17:01:27 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: Adrian Chadd , Michael Fuckner In-Reply-To: <1037310890.395652.1426279081703.JavaMail.open-xchange@ptangptang.store> References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> , <101866634.392324.1426276184167.JavaMail.open-xchange@ptangptang.store> <72adbbf534c673c111c0b8cec018318b@ultimatedns.net>, <1037310890.395652.1426279081703.JavaMail.open-xchange@ptangptang.store> From: "Chris H" Subject: Re: Server with 3TB Crashing at boot Date: Fri, 13 Mar 2015 17:01:27 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <6efe9f7b5f8e1de40c1f950c864631c7@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: "freebsd-hackers@freebsd.org" , Oliver Pinter , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 23:59:42 -0000 On Fri, 13 Mar 2015 21:38:01 +0100 (CET) Michael Fuckner wrote > > Chris H hat am 13. März 2015 um 21:28 > > geschrieben: > > > > > On Fri, 13 Mar 2015 20:49:44 +0100 (CET) Michael Fuckner > > wrote > > > > > > Adrian Chadd hat am 13. März 2015 um 19:02 > > > > geschrieben: > > > > > > Hi! > > > > > > > boot_verbose=YES looks to be right. > > > > > > root@s4l:~ # grep verbose /boot/defaults/loader.conf > > > verbose_loading="NO" # Set to YES for verbose loader output > > > > > > OK, this confused me :-( > > In case it's still not clear: > > The values your copy of loader.conf located as /boot/loader.conf > > overrides the values set in /boot/defaults/loader.conf > > > that is clear to me, but I was confused by verbose_loading vs boot_verbose LOL in all honesty, that one got me too, at first. :-/ It *is* confusing. --Chris > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --Chris -- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 01:03:46 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92A7441D for ; Sat, 14 Mar 2015 01:03:46 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 8C02E171 for ; Sat, 14 Mar 2015 01:03:45 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygB3JzzniANVUmOUAw--.47941S2; Sat, 14 Mar 2015 09:03:41 +0800 (CST) Date: Sat, 14 Mar 2015 09:03:29 +0800 From: Tiwei Bie To: Mateusz Guzik Subject: Re: [PATCH] Finish the task 'Convert mountlist_mtx to rwlock' Message-ID: <20150314010329.GA2559@freebsd> References: <1426079434-51568-1-git-send-email-btw@mail.ustc.edu.cn> <20150312132338.GA57932@freebsd> <20150313200705.GA32157@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150313200705.GA32157@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygB3JzzniANVUmOUAw--.47941S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ur1xKF43tryUGFyDury8Krg_yoW8Gw4DpF WftFy0kr4vv3y8Z347tw15XryFvw1kJF17Xw1rXr1kA3sYvw1Skr1UtF45KFW7WryIkrsF vFWj93saq3Z8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E FcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr 0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxkIecxEwVAFwVWkMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jO6p9UUUUU= X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUHAVQhl-enIQAPse Cc: "freebsd-hackers@freebsd.org" , Ryan Stone , wca@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 01:03:46 -0000 On Fri, Mar 13, 2015 at 09:07:05PM +0100, Mateusz Guzik wrote: > On Thu, Mar 12, 2015 at 09:26:00PM +0800, Tiwei Bie wrote: > > On Thu, Mar 12, 2015 at 12:06:02AM -0400, Ryan Stone wrote: > > > On Wed, Mar 11, 2015 at 9:10 AM, Tiwei Bie wrote: > > > > Hi, Mateusz! > > > > > > > > I have finished the task: Convert mountlist_mtx to rwlock [1]. > > > > > > My first comment is, are we sure that we actually want an rwlock here > > > instead of an rmlock? An rmlock will offer much better performance in > > > workloads that mostly only take read locks, and rmlocks do not suffer > > > the priority inversion problems that rwlocks do. From the description > > > on the wiki page, it sounds like an rmlock would be ideal here: > > > > > > > Interested person can upgrade this task to non-junior by coming up with a > > > > solution exploiting rare need to modify the list. Example approaches include > > > > designing a locking primitive with cheap shared locking (think: per-cpu) at > > > > the expense of exclusive locking. > > > > > > > I think rmlock is okay. But one more argument needs to be added > > to vfs_busy(), that is 'struct rm_priotracker *tracker' which is > > used to track read owners of mountlist_lock in vfs_busy(). > > So, this is not a simple s/rw_lock/rm_rlock and the like after all, sorry. :) > > I'll have to go over this and possibly gather some ACKs before > committing. > Never mind, just do whatever necessary and make the best choice! ^_^ Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 01:07:34 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2149750E for ; Sat, 14 Mar 2015 01:07:34 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF41A189 for ; Sat, 14 Mar 2015 01:07:33 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2E19LHd061043 for ; Fri, 13 Mar 2015 18:09:21 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD Hackers" From: "Chris H" Subject: What's the possibilities of recycling /usr/obj for other targets, etc? Date: Fri, 13 Mar 2015 18:09:21 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 01:07:34 -0000 Greetings all, I've been combing /usr/src, build, relese, and release engineering in the FBSD docs, for the last couple days. But still haven't *quite* unwound everything in src. What I'm attempting to do, is to recycle a recent build/install world/kernel I still have in /usr/obj. To create 1) a utility CD/DV 2) a [minimal] "release" CD/DVD I'm *sure* I'm just over-complicating things. But it's still unclear as to whether any of the already available targets/dists -- release, distribute, distributekernel, distributeworld. Will attempt to REbuild world && kernel, before proceeding. If I'm not mistaken -DNO_CLEAN (might?) help me coerce make to do my bidding. Or is only available to speed up the initial build, after a cd /usr/obj chflags -R noschg * rm -rf * Any help, pointers, suggestions, ... *greatly* appreciated. BTW I'm attempting this on a recent -CURRENT (11). Thanks! --Chris -- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 07:00:31 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C710E2D4 for ; Sat, 14 Mar 2015 07:00:31 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54A9092D for ; Sat, 14 Mar 2015 07:00:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426316402; l=1532; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date; bh=wR3BXmTnMKbKZrfGSmlvLUEoQvQvk8zEEbNhAyb4O80=; b=jsiNSdf1DXJG0oJo3SIVFuP6ou3vAZ5a9NtSDEBdhmZQniOntEDd1zxDJkkS7/5rC4U wpDqGIGWf4E1P+IV9+jDDuCu9/Tc8CiDAqBj/gvI4vI3gMkL/COmdENsKkHlYxYov7Han 53yU5XwElJDZ1TyY+pABWeRSDt7HRj8Y0gE= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgknstV9BEzWRmW1UTIElHLUn9j9lPdvoHGqfmhRNhCftOauO36Vasg== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2028:737:9301:9004:fb54:5075:1f81] (some-ipv6-address.wtnet.de [IPv6:2a02:2028:737:9301:9004:fb54:5075:1f81]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id t0229br2E6xmBqT (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate); Sat, 14 Mar 2015 07:59:48 +0100 (CET) Message-ID: <5503DC66.40409@fuckner.net> Date: Sat, 14 Mar 2015 07:59:50 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ryan Stone Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Steven Hartland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 07:00:31 -0000 On 3/13/2015 10:17 PM, Ryan Stone wrote: > On Fri, Mar 13, 2015 at 4:42 PM, Michael Fuckner > wrote: > >> Now I can kldload zfs without exploding kernel. I'll do some more tests >> tomorrow, but this looks fine! >> > > Excellent news! I'd be interested to know whether this fixes the panics > that you saw when zfs.ko was loaded by the bootloader. It's definitely > possible, as the symptoms of this bug are likely to be random memory > corruption after zfs initializes, but your crash happened pretty early on > and I'm not sure whether zfs would have had a chance to do anything that > early. > > Thanks for all of the work that you did to debug this. Currently there is another issue that prevents me from testing ZFS: only one HBA gets initialized. mpr0: 9300-8i with 8x Intel S3700 mpr1: 9300-4i4e with 4x Intel S3700 and an external JBOD with 24HDD. mpr0 initializes fine, mpr1 fails root@s4l:~ # dmesg |grep mpr mpr1: port 0xf000-0xf0ff mem 0xfb100000-0xfb10ffff irq 112 at device 0.0 on pci195 mpr1: IOCFacts : mpr1: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd mpr1: IOCCapabilities: 7a85c mpr1: Cannot allocate queues memory mpr1: mpr_iocfacts_allocate failed to alloc queues with error 12 mpr1: mpr_attach IOC Facts based allocation failed with error 12 device_attach: mpr1 attach returned 12 Any idea? Should I post to freebsd-scsi? Regards, Michael! From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 11:44:05 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DCB9106 for ; Sat, 14 Mar 2015 11:44:05 +0000 (UTC) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E5F27C7 for ; Sat, 14 Mar 2015 11:44:03 +0000 (UTC) Received: by wibg7 with SMTP id g7so5771467wib.1 for ; Sat, 14 Mar 2015 04:44:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=OiaYJj7g6UA3x0QA32/lKsLIIoTFZZqLGO4j2/0pcr0=; b=kKEcmIWKqASN8m/M6i/PXYQ1jz2qkyU+p0s0andYIzx9D3/JmMstLoX0/rw2SvJ30Q +p9GR3esgDFA2uae0btWe7urMOaDbQ8HWCVh2hDWTwso6DAyHe4m04rVxUUnLyf5/Fvo 8ZCoCoA0v4cY1tOIHdNURupkpEvNswkzxV4umOhO2lMk6eotMAg+BnNCeUq1HrEiFKKu t3p/5hD2zNiflyx5S27b6HuJ404fl4rx9trXJz6RwnNPyyzubwSa6nUkXOmdhLyIcvSt VfLHSo20Yx3JoDMTZg4tuABAZzUU7obp5RpLEcD69it0PEnOgS0P3OMPsapbNQ4dJwR7 pLog== X-Gm-Message-State: ALoCoQkwxeldEpV5AEQZg+zbrrmjtBwdKoQ1a/R5crgS/UrqweckUDnkozWJZ6GaPn7ioIs5qCU+ X-Received: by 10.180.106.197 with SMTP id gw5mr56477615wib.58.1426333441925; Sat, 14 Mar 2015 04:44:01 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id vq9sm6711077wjc.6.2015.03.14.04.44.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 04:44:00 -0700 (PDT) Message-ID: <55041EF5.9080200@multiplay.co.uk> Date: Sat, 14 Mar 2015 11:43:49 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michael Fuckner , Ryan Stone Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> In-Reply-To: <5503DC66.40409@fuckner.net> Content-Type: multipart/mixed; boundary="------------090702070101020508050506" Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 11:44:05 -0000 This is a multi-part message in MIME format. --------------090702070101020508050506 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 14/03/2015 06:59, Michael Fuckner wrote: > On 3/13/2015 10:17 PM, Ryan Stone wrote: >> On Fri, Mar 13, 2015 at 4:42 PM, Michael Fuckner >> wrote: >> >>> Now I can kldload zfs without exploding kernel. I'll do some more >>> tests >>> tomorrow, but this looks fine! >>> >> >> Excellent news! I'd be interested to know whether this fixes the panics >> that you saw when zfs.ko was loaded by the bootloader. It's definitely >> possible, as the symptoms of this bug are likely to be random memory >> corruption after zfs initializes, but your crash happened pretty >> early on >> and I'm not sure whether zfs would have had a chance to do anything that >> early. >> >> Thanks for all of the work that you did to debug this. > > > Currently there is another issue that prevents me from testing ZFS: > only one HBA gets initialized. > > mpr0: 9300-8i with 8x Intel S3700 > mpr1: 9300-4i4e with 4x Intel S3700 and an external JBOD with 24HDD. > > mpr0 initializes fine, mpr1 fails > > root@s4l:~ # dmesg |grep mpr > mpr1: port 0xf000-0xf0ff mem 0xfb100000-0xfb10ffff irq > 112 at device 0.0 on pci195 > mpr1: IOCFacts : > mpr1: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd > mpr1: IOCCapabilities: > 7a85c > mpr1: Cannot allocate queues memory > mpr1: mpr_iocfacts_allocate failed to alloc queues with error 12 > mpr1: mpr_attach IOC Facts based allocation failed with error 12 > device_attach: mpr1 attach returned 12 > > Any idea? Should I post to freebsd-scsi? Thats failing in bus_dmamem_alloc so as a guess I'd say there's no space below the 4GB boundary for the allocation of size qsize. The attached patch will print out the maxsize of the attempted allocation which may be interesting, although I wouldn't expect it to be anything strange as its pretty much device specific and not connected to total memory that I can see. Given that I suspect something else in the earlier part of the boot process has allocated a large chunk of memory making available space below 4GB scarce. A verbose boot up to this point may provide some indication as to this. Regards Steve --------------090702070101020508050506 Content-Type: text/x-patch; name="mpr.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mpr.patch" --- sys/dev/mpr/mpr.c.orig 2015-03-14 11:32:43.256662663 +0000 +++ sys/dev/mpr/mpr.c 2015-03-14 11:33:23.682658734 +0000 @@ -1125,7 +1125,7 @@ mpr_alloc_queues(struct mpr_softc *sc) } if (bus_dmamem_alloc(sc->queues_dmat, (void **)&queues, BUS_DMA_NOWAIT, &sc->queues_map)) { - device_printf(sc->mpr_dev, "Cannot allocate queues memory\n"); + device_printf(sc->mpr_dev, "Cannot allocate queues size %d memory\n", qsize); return (ENOMEM); } bzero(queues, qsize); --------------090702070101020508050506-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 11:57:39 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ADB63E6 for ; Sat, 14 Mar 2015 11:57:39 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84DDA8C9 for ; Sat, 14 Mar 2015 11:57:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2EBvXmJ080039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2015 13:57:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2EBvXmJ080039 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2EBvX03080038; Sat, 14 Mar 2015 13:57:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Mar 2015 13:57:33 +0200 From: Konstantin Belousov To: Steven Hartland Subject: Re: Server with 3TB Crashing at boot Message-ID: <20150314115733.GG2379@kib.kiev.ua> References: <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55041EF5.9080200@multiplay.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Michael Fuckner , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 11:57:39 -0000 On Sat, Mar 14, 2015 at 11:43:49AM +0000, Steven Hartland wrote: > Thats failing in bus_dmamem_alloc so as a guess I'd say there's no space > below the 4GB boundary for the allocation of size qsize. If this is indeed the case, laoder tunable hw.dmar.enable=1 could help. I assume that machine of this class does have VT-d hardware, you might need to enable it in BIOS. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 12:04:40 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B8C17CB for ; Sat, 14 Mar 2015 12:04:40 +0000 (UTC) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC42C9A2 for ; Sat, 14 Mar 2015 12:04:39 +0000 (UTC) Received: by wixw10 with SMTP id w10so6818955wix.0 for ; Sat, 14 Mar 2015 05:04:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9NHxDe2SxzkK9OgYlxdUeH3Cz1iQwiuinVBijD09sGI=; b=GMjB1AfdyGv/qdnXVxFMqdPsB0VH6M6hanMM0V2bBXKnZmudLo/cWEc5kJO7aQPYYg phn9hiIePp+wDKPki8kE+RZw0JDUnBICRd7r7prjA9Ug4XQJZ7PbVcaCOY7zcMw7NnMQ XzquG5Iz58wp1utdq4pl4hLKzIB7ttKty2ckuTbz4Re7wA1pKJxpdM+QyfYYhxGjDt/c kkJZAUI7T6HDjBgShUe3ZJB83WlUFjs/9VJkKU+sryL0Yj0qlrV+MarSOMdwAtFZxmFA 4HPdrv+jPJ75vl3qQqQLEJyuTIp653WRccFvS2ymihk9DHe25kz4kqFgkBnkt8JjX7A+ avdw== X-Gm-Message-State: ALoCoQkttDTtwHZMRQkR5zwhyrMQkQ/5m5GVr9D6KVTaXk76aDDFu+UTVbmHDUIKtMw9S5not5yA X-Received: by 10.194.80.40 with SMTP id o8mr103351808wjx.34.1426334677774; Sat, 14 Mar 2015 05:04:37 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id b4sm6757123wic.2.2015.03.14.05.04.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 05:04:36 -0700 (PDT) Message-ID: <550423CC.9080409@multiplay.co.uk> Date: Sat, 14 Mar 2015 12:04:28 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Server with 3TB Crashing at boot References: <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> <20150314115733.GG2379@kib.kiev.ua> In-Reply-To: <20150314115733.GG2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Michael Fuckner , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 12:04:40 -0000 On 14/03/2015 11:57, Konstantin Belousov wrote: > On Sat, Mar 14, 2015 at 11:43:49AM +0000, Steven Hartland wrote: >> Thats failing in bus_dmamem_alloc so as a guess I'd say there's no space >> below the 4GB boundary for the allocation of size qsize. > If this is indeed the case, laoder tunable hw.dmar.enable=1 could help. > I assume that machine of this class does have VT-d hardware, you might > need to enable it in BIOS. I don't see that sysctl on my 10.1 boxes, is that something only in stable / current? From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 12:11:02 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 218C3909 for ; Sat, 14 Mar 2015 12:11:02 +0000 (UTC) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3AF29CE for ; Sat, 14 Mar 2015 12:11:01 +0000 (UTC) Received: by wibg7 with SMTP id g7so6054668wib.1 for ; Sat, 14 Mar 2015 05:10:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=El+fg7OgxGVTylmZQi5pSPJTL+vj6HJz7SAGBdrgXz8=; b=JCGrAbXPdTzM+hKZEpURZ7ChuVGGMr0ACUkEGbI4eyGT/iQU6rrybIS8yKeRpHoRL9 S2e09Uqy41lTbHt6gpinB0hoX+feBwgcgP9Z9pb0ZCNXPK6k2zJoVLpbMw8cbIojeGZ2 2kZ4BgnreEyRSE51CI65GWy1RU3+J5JI/3k0k9zJKh2ebnGHyR+wfXjD+NkKviLmZB4D dhEJwb0JGpIJv+Yo/lsg4ciUIVgqXk8IKaoHSt/U/9ROydFSUHU9h6HaykztY+1ygRut eCe2fdpomEv2T8DddnoNzmmeYGLX0jZ0zfYLDTUCtENm91Bz1NfP8oe7sH4ZeNIpq3DH sCkw== X-Gm-Message-State: ALoCoQljA5zdRJvGyzFnfZfLXkcefIQZoyn36esgkIBvKJvM873QK46op+IefL6gfldzwMNNKazO X-Received: by 10.194.11.9 with SMTP id m9mr103782044wjb.82.1426335053637; Sat, 14 Mar 2015 05:10:53 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id kj8sm6774095wjc.29.2015.03.14.05.10.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 05:10:52 -0700 (PDT) Message-ID: <55042544.2080202@multiplay.co.uk> Date: Sat, 14 Mar 2015 12:10:44 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Server with 3TB Crashing at boot References: <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> <20150314115733.GG2379@kib.kiev.ua> <550423CC.9080409@multiplay.co.uk> In-Reply-To: <550423CC.9080409@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Michael Fuckner , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 12:11:02 -0000 On 14/03/2015 12:04, Steven Hartland wrote: > On 14/03/2015 11:57, Konstantin Belousov wrote: >> On Sat, Mar 14, 2015 at 11:43:49AM +0000, Steven Hartland wrote: >>> Thats failing in bus_dmamem_alloc so as a guess I'd say there's no >>> space >>> below the 4GB boundary for the allocation of size qsize. >> If this is indeed the case, laoder tunable hw.dmar.enable=1 could help. >> I assume that machine of this class does have VT-d hardware, you might >> need to enable it in BIOS. > I don't see that sysctl on my 10.1 boxes, is that something only in > stable / current? Ignore, looks like its "only" a tunable so not exposed via sysctl Roll on 11 so we don't have that problem any more. Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 12:19:00 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A83EB9C for ; Sat, 14 Mar 2015 12:19:00 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B807AA2 for ; Sat, 14 Mar 2015 12:18:59 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2ECIsBu084613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2015 14:18:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2ECIsBu084613 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2ECIsf0084612; Sat, 14 Mar 2015 14:18:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Mar 2015 14:18:54 +0200 From: Konstantin Belousov To: Steven Hartland Subject: Re: Server with 3TB Crashing at boot Message-ID: <20150314121854.GH2379@kib.kiev.ua> References: <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> <20150314115733.GG2379@kib.kiev.ua> <550423CC.9080409@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550423CC.9080409@multiplay.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Michael Fuckner , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 12:19:00 -0000 On Sat, Mar 14, 2015 at 12:04:28PM +0000, Steven Hartland wrote: > On 14/03/2015 11:57, Konstantin Belousov wrote: > > On Sat, Mar 14, 2015 at 11:43:49AM +0000, Steven Hartland wrote: > >> Thats failing in bus_dmamem_alloc so as a guess I'd say there's no space > >> below the 4GB boundary for the allocation of size qsize. > > If this is indeed the case, laoder tunable hw.dmar.enable=1 could help. > > I assume that machine of this class does have VT-d hardware, you might > > need to enable it in BIOS. > I don't see that sysctl on my 10.1 boxes, is that something only in > stable / current? This is tunable, it should work in 10.1, but stable/10 and head has some worthy fixes. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 13:23:30 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E26D498D for ; Sat, 14 Mar 2015 13:23:30 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BF3CFE for ; Sat, 14 Mar 2015 13:23:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426339385; l=3301; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date; bh=+Ol8Yu1HYdwAc//Bj3YOMzlgxsYz4sxAokSDkz1XlNU=; b=ZPQ3UuBsVZozdmBC3vP/pgT/ADQDJtHBIZ4J+a5EkURzw7Z+r0RJAoC97WWVx6h0bNg Vmzzi4pTSaY4JN337SSAZRFsbSNF1FSyMNfBQOgjMlQhyazjb84VuDsuD9jAt5b6UBC+j jhY3RYwAlkF3ak2MykTkN5KK6KgOSPpBALs= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgknstV9BEzWRmW1UTIElHLUn9j9pNI6Yw3ftahX9+/V6TY7Maqcasg== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2028:737:9301:59e9:4863:b903:5e51] (some-ipv6-address.wtnet.de [IPv6:2a02:2028:737:9301:59e9:4863:b903:5e51]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id R02cb4r2EDMqC8R (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate); Sat, 14 Mar 2015 14:22:52 +0100 (CET) Message-ID: <5504362C.9000904@fuckner.net> Date: Sat, 14 Mar 2015 14:22:52 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Steven Hartland , Ryan Stone Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> In-Reply-To: <55041EF5.9080200@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 13:23:31 -0000 On 3/14/2015 12:43 PM, Steven Hartland wrote: > > > On 14/03/2015 06:59, Michael Fuckner wrote: >> On 3/13/2015 10:17 PM, Ryan Stone wrote: >>> On Fri, Mar 13, 2015 at 4:42 PM, Michael Fuckner >>> wrote: >>> >>>> Now I can kldload zfs without exploding kernel. I'll do some more >>>> tests >>>> tomorrow, but this looks fine! >>>> >>> >>> Excellent news! I'd be interested to know whether this fixes the panics >>> that you saw when zfs.ko was loaded by the bootloader. It's definitely >>> possible, as the symptoms of this bug are likely to be random memory >>> corruption after zfs initializes, but your crash happened pretty >>> early on >>> and I'm not sure whether zfs would have had a chance to do anything that >>> early. >>> >>> Thanks for all of the work that you did to debug this. >> >> >> Currently there is another issue that prevents me from testing ZFS: >> only one HBA gets initialized. >> >> mpr0: 9300-8i with 8x Intel S3700 >> mpr1: 9300-4i4e with 4x Intel S3700 and an external JBOD with 24HDD. >> >> mpr0 initializes fine, mpr1 fails >> >> root@s4l:~ # dmesg |grep mpr >> mpr1: port 0xf000-0xf0ff mem 0xfb100000-0xfb10ffff irq >> 112 at device 0.0 on pci195 >> mpr1: IOCFacts : >> mpr1: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd >> mpr1: IOCCapabilities: >> 7a85c >> >> mpr1: Cannot allocate queues memory >> mpr1: mpr_iocfacts_allocate failed to alloc queues with error 12 >> mpr1: mpr_attach IOC Facts based allocation failed with error 12 >> device_attach: mpr1 attach returned 12 did your patch for queue size and sense size. I just saw: http://dedi3.fuckner.net/~molli123/temp/mpr2.cap (just the second half of the boot, but nothing changed but the two debug echos) root@s4l:~ # dmesg |grep mpr mpr0: port 0x2000-0x20ff mem 0xaba00000-0xaba0ffff irq 42 at device 0.0 on pci4 mpr0: IOCFacts : mpr0: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd mpr0: IOCCapabilities: 7a85c mpr0: attempting to allocate 1 MSI-X vectors (96 supported) mpr0: using IRQ 300 for MSI-X mpr1: port 0xf000-0xf0ff mem 0xfb100000-0xfb10ffff irq 112 at device 0.0 on pci195 mpr1: IOCFacts : mpr1: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd mpr1: IOCCapabilities: 7a85c mpr1: Cannot allocate sense size 258048 memory mpr1: mpr_iocfacts_allocate failed to alloc queues with error 12 mpr1: mpr_attach IOC Facts based allocation failed with error 12 device_attach: mpr1 attach returned 12 (probe0:mpr0:0:0:0): Down reving Protocol Version from 4 to 0? da0 at mpr0 bus 0 scbus0 target 0 lun 0 pass0 at mpr0 bus 0 scbus0 target 0 lun 0 In Bios I have VT-d enabled. In the VT-d Menu there are two other options: ATS (Non-Iscoh VT-D Engine ATS Support), default: enabled Coherency Support(Non Iscoh VT_D Engine Coherency Support), default: Disabled In the Processor Configuration tab there also was extended apic support (default is disabled) Should I give this option a try? Regards, Michael! From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 13:47:40 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 400C04D9 for ; Sat, 14 Mar 2015 13:47:40 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB2CB2FC for ; Sat, 14 Mar 2015 13:47:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2EDlXpY005381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2015 15:47:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2EDlXpY005381 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2EDlXYp005380; Sat, 14 Mar 2015 15:47:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Mar 2015 15:47:33 +0200 From: Konstantin Belousov To: Michael Fuckner Subject: Re: Server with 3TB Crashing at boot Message-ID: <20150314134733.GI2379@kib.kiev.ua> References: <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> <5504362C.9000904@fuckner.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5504362C.9000904@fuckner.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Ryan Stone , Steven Hartland , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 13:47:40 -0000 On Sat, Mar 14, 2015 at 02:22:52PM +0100, Michael Fuckner wrote: > On 3/14/2015 12:43 PM, Steven Hartland wrote: > > > > > > On 14/03/2015 06:59, Michael Fuckner wrote: > >> On 3/13/2015 10:17 PM, Ryan Stone wrote: > >>> On Fri, Mar 13, 2015 at 4:42 PM, Michael Fuckner > >>> wrote: > >>> > >>>> Now I can kldload zfs without exploding kernel. I'll do some more > >>>> tests > >>>> tomorrow, but this looks fine! > >>>> > >>> > >>> Excellent news! I'd be interested to know whether this fixes the panics > >>> that you saw when zfs.ko was loaded by the bootloader. It's definitely > >>> possible, as the symptoms of this bug are likely to be random memory > >>> corruption after zfs initializes, but your crash happened pretty > >>> early on > >>> and I'm not sure whether zfs would have had a chance to do anything that > >>> early. > >>> > >>> Thanks for all of the work that you did to debug this. > >> > >> > >> Currently there is another issue that prevents me from testing ZFS: > >> only one HBA gets initialized. > >> > >> mpr0: 9300-8i with 8x Intel S3700 > >> mpr1: 9300-4i4e with 4x Intel S3700 and an external JBOD with 24HDD. > >> > >> mpr0 initializes fine, mpr1 fails > >> > >> root@s4l:~ # dmesg |grep mpr > >> mpr1: port 0xf000-0xf0ff mem 0xfb100000-0xfb10ffff irq > >> 112 at device 0.0 on pci195 > >> mpr1: IOCFacts : > >> mpr1: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd > >> mpr1: IOCCapabilities: > >> 7a85c > >> > >> mpr1: Cannot allocate queues memory > >> mpr1: mpr_iocfacts_allocate failed to alloc queues with error 12 > >> mpr1: mpr_attach IOC Facts based allocation failed with error 12 > >> device_attach: mpr1 attach returned 12 > > did your patch for queue size and sense size. > > I just saw: > > http://dedi3.fuckner.net/~molli123/temp/mpr2.cap (just the second half > of the boot, but nothing changed but the two debug echos) > > > root@s4l:~ # dmesg |grep mpr > mpr0: port 0x2000-0x20ff mem 0xaba00000-0xaba0ffff irq 42 > at device 0.0 on pci4 > mpr0: IOCFacts : > mpr0: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd > mpr0: IOCCapabilities: > 7a85c > mpr0: attempting to allocate 1 MSI-X vectors (96 supported) > mpr0: using IRQ 300 for MSI-X > mpr1: port 0xf000-0xf0ff mem 0xfb100000-0xfb10ffff irq 112 > at device 0.0 on pci195 > mpr1: IOCFacts : > mpr1: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd > mpr1: IOCCapabilities: > 7a85c > mpr1: Cannot allocate sense size 258048 memory > mpr1: mpr_iocfacts_allocate failed to alloc queues with error 12 > mpr1: mpr_attach IOC Facts based allocation failed with error 12 > device_attach: mpr1 attach returned 12 > (probe0:mpr0:0:0:0): Down reving Protocol Version from 4 to 0? > da0 at mpr0 bus 0 scbus0 target 0 lun 0 > pass0 at mpr0 bus 0 scbus0 target 0 lun 0 > > In Bios I have VT-d enabled. In the VT-d Menu there are two other options: > ATS (Non-Iscoh VT-D Engine ATS Support), default: enabled ATS is not used by FreeBSD right now, and your device probably does not support it as well. > Coherency Support(Non Iscoh VT_D Engine Coherency Support), default: > Disabled There is a bug in 10.1 which incorrectly invalidates IOMMU pages cache. Enabling the coherency works around the bug. > > In the Processor Configuration tab there also was > extended apic support (default is disabled) On 10.1 this option should not result in any behaviour change. > > Should I give this option a try? Up to you. I am somewhat curious whether it boots with DMAR enabled and what happens if it does not. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 14:42:25 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA44927C for ; Sat, 14 Mar 2015 14:42:25 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74284A52 for ; Sat, 14 Mar 2015 14:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426344117; l=473; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date; bh=y2HUL/UEZsAEcQ4Z7h1sJEBC5uaiPcY8HPymQgsjsMg=; b=PXXGyjmJ5w4L+rNxU+q/WkJV+ol6bcR89ACIj+1iXJ/zYjf9KAp6lV71mHiP86WV4yj c2UtZQnllAiL0y4R4C0crqHw2HjqfXFS9RLGY6SkIkbGsN327r6Ug1Xr0Cvrwhwvt6O52 mHZ1toh7quNk1mxr/+DI+xtvWQp5fvD1bKM= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgknstV9BEzWRmW1UTIElHLUn9j9pNI6Yw3ftahX9+/V6TY7Maqcasg== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2028:737:9301:59e9:4863:b903:5e51] (some-ipv6-address.wtnet.de [IPv6:2a02:2028:737:9301:59e9:4863:b903:5e51]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id a02f3er2EEfuFIU (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate); Sat, 14 Mar 2015 15:41:56 +0100 (CET) Message-ID: <550448B3.7050100@fuckner.net> Date: Sat, 14 Mar 2015 15:41:55 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Server with 3TB Crashing at boot References: <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> <5504362C.9000904@fuckner.net> <20150314134733.GI2379@kib.kiev.ua> In-Reply-To: <20150314134733.GI2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Steven Hartland , Ryan Stone , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 14:42:26 -0000 >> >> In the Processor Configuration tab there also was >> extended apic support (default is disabled) > On 10.1 this option should not result in any behaviour change. > >> >> Should I give this option a try? > > Up to you. I am somewhat curious whether it boots with DMAR enabled and > what happens if it does not. > ____ looks good, doesn't it? http://dedi3.fuckner.net/~molli123/temp/dmar.log I'll reattach the disks on monday. Regards, Michael From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 14:56:14 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B54257E0 for ; Sat, 14 Mar 2015 14:56:14 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F656B87 for ; Sat, 14 Mar 2015 14:56:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2EEu7V8021355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2015 16:56:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2EEu7V8021355 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2EEu7pw021352; Sat, 14 Mar 2015 16:56:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Mar 2015 16:56:07 +0200 From: Konstantin Belousov To: Michael Fuckner Subject: Re: Server with 3TB Crashing at boot Message-ID: <20150314145607.GJ2379@kib.kiev.ua> References: <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> <5504362C.9000904@fuckner.net> <20150314134733.GI2379@kib.kiev.ua> <550448B3.7050100@fuckner.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550448B3.7050100@fuckner.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Steven Hartland , Ryan Stone , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 14:56:14 -0000 On Sat, Mar 14, 2015 at 03:41:55PM +0100, Michael Fuckner wrote: > >> > >> In the Processor Configuration tab there also was > >> extended apic support (default is disabled) > > On 10.1 this option should not result in any behaviour change. > > > >> > >> Should I give this option a try? > > > > Up to you. I am somewhat curious whether it boots with DMAR enabled and > > what happens if it does not. > > ____ > > looks good, doesn't it? > > http://dedi3.fuckner.net/~molli123/temp/dmar.log No, it does not. At least I suspect that your ix* interfaces are not functional. The issue is with DMAR code, not with the ixgbe driver, and it was probably fixed in stable/10. > > I'll reattach the disks on monday. Would be interesting. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 15:26:54 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEC27A3 for ; Sat, 14 Mar 2015 15:26:53 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 684A8E1C for ; Sat, 14 Mar 2015 15:26:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426346783; l=2043; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date; bh=QBzP64tV+B4BRAIvpKf32txQD9gIXlOizShaku3qkl4=; b=bggSrGNUji/DaU3KdfQUypDElwsjlewhJjADhGhOjgkb1bPWhfKLM9x315+HE/W4Sou aEX3OrFZTbdakrDHeUspG7cmln4n3/F/Iljccc3MSnOFbETaTu45fAnmkkIpP27BH2NJ6 m9YgL2O86rMbLkxQjikw9Egnk7e0T5UreMA= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgknstV9BEzWRmW1VToIlv9YXueY+HT3a7I1W9ok0Dp7Udev/SxV3tQ== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2028:614:c501:9146:9cdf:f7eb:31de] (some-ipv6-address.wtnet.de [IPv6:2a02:2028:614:c501:9146:9cdf:f7eb:31de]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id L037f9r2EFQ8FZP (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate); Sat, 14 Mar 2015 16:26:08 +0100 (CET) Message-ID: <5504530F.5040508@fuckner.net> Date: Sat, 14 Mar 2015 16:26:07 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Server with 3TB Crashing at boot References: <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> <5504362C.9000904@fuckner.net> <20150314134733.GI2379@kib.kiev.ua> <550448B3.7050100@fuckner.net> <20150314145607.GJ2379@kib.kiev.ua> In-Reply-To: <20150314145607.GJ2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Steven Hartland , Ryan Stone , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 15:26:54 -0000 On 3/14/2015 3:56 PM, Konstantin Belousov wrote: > On Sat, Mar 14, 2015 at 03:41:55PM +0100, Michael Fuckner wrote: >>>> >>>> In the Processor Configuration tab there also was >>>> extended apic support (default is disabled) >>> On 10.1 this option should not result in any behaviour change. >>> >>>> >>>> Should I give this option a try? >>> >>> Up to you. I am somewhat curious whether it boots with DMAR enabled and >>> what happens if it does not. >>> ____ >> >> looks good, doesn't it? >> >> http://dedi3.fuckner.net/~molli123/temp/dmar.log > No, it does not. At least I suspect that your ix* interfaces are not > functional. The issue is with DMAR code, not with the ixgbe driver, and > it was probably fixed in stable/10. why do you think it is not working? root@s4l:~ # ping dedi3.fuckner.net PING dedi3.fuckner.net (81.169.184.133): 56 data bytes 64 bytes from 81.169.184.133: icmp_seq=0 ttl=56 time=15.522 ms 64 bytes from 81.169.184.133: icmp_seq=1 ttl=56 time=11.266 ms [root@mf5 ~]# grep ix0 dmar.log ix0: Link is Down ix0: link state changed to DOWN ix0: port 0x4020-0x403f mem 0xaaa00000-0xaabfffff,0xaac04000-0xaac07fff irq 32 at device 0.0 on pci1 ix0: attempting to allocate 9 MSI-X vectors (64 supported) ix0: using IRQs 272-280 for MSI-X ix0: Using MSIX interrupts with 9 vectors ix0: dmar3 pci0:1:0:0 domain 2 mgaw 48 agaw 48 re-mapped ix0: bpf attached ix0: Ethernet address: c4:54:44:92:73:d2 ix0: PCI Express Bus: Speed 5.0GT/s Width x8 ix0: Link is up 1 Gbps Full Duplex ix0: ix0: link state changed to UP ix0: link state changed to DOWN Starting Network: lo0 ix0 ix1 ix2 ix3. ix0: flags=8843 metric 0 mtu 1500 nd6 options=29 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58A101C1 for ; Sat, 14 Mar 2015 15:29:43 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D795EE32 for ; Sat, 14 Mar 2015 15:29:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426346980; l=990; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date; bh=C4QeVJ7SVDOs1OWQRkK891IjEtD5D+UdxrmzjmeMaXg=; b=ZT3BoFpGce9DtWv4AQf2kLHepD2uihGQLTlZmgepBtRsDAN8J/ceBDs2/Ib2jFv4AEd YxZVXkys0mYFNXwJimUZ1Y18RmwNkmb4y+m6FXjrb2mYtCOLspCJWMOo2DSc7DEHlINUp z34Tij6w2E549MaGPTMGB4Eale6ftxhgh1w= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgknstV9BEzWRmW1VToIlv9YXueY+HT3a7I1W9ok0Dp7Udev/SxV3tQ== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2028:614:c501:9146:9cdf:f7eb:31de] (some-ipv6-address.wtnet.de [IPv6:2a02:2028:614:c501:9146:9cdf:f7eb:31de]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id z02bebr2EFTcF0K (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate); Sat, 14 Mar 2015 16:29:38 +0100 (CET) Message-ID: <550453E2.8020901@fuckner.net> Date: Sat, 14 Mar 2015 16:29:38 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Server with 3TB Crashing at boot References: <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> <5504362C.9000904@fuckner.net> <20150314134733.GI2379@kib.kiev.ua> <550448B3.7050100@fuckner.net> <20150314145607.GJ2379@kib.kiev.ua> <5504530F.5040508@fuckner.net> In-Reply-To: <5504530F.5040508@fuckner.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Ryan Stone , Steven Hartland , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 15:29:43 -0000 On 3/14/2015 4:26 PM, Michael Fuckner wrote: > On 3/14/2015 3:56 PM, Konstantin Belousov wrote: >> On Sat, Mar 14, 2015 at 03:41:55PM +0100, Michael Fuckner wrote: >>>>> >>>>> In the Processor Configuration tab there also was >>>>> extended apic support (default is disabled) >>>> On 10.1 this option should not result in any behaviour change. >>>> >>>>> >>>>> Should I give this option a try? >>>> >>>> Up to you. I am somewhat curious whether it boots with DMAR enabled >>>> and >>>> what happens if it does not. >>>> ____ >>> >>> looks good, doesn't it? >>> >>> http://dedi3.fuckner.net/~molli123/temp/dmar.log >> No, it does not. At least I suspect that your ix* interfaces are not >> functional. The issue is with DMAR code, not with the ixgbe driver, and >> it was probably fixed in stable/10. > > why do you think it is not working? > you were right- when doing pkg install subversion the machine rebootet- but logging was just turned off :( Michael! From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 15:39:47 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54520518 for ; Sat, 14 Mar 2015 15:39:47 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E9C01F07 for ; Sat, 14 Mar 2015 15:39:46 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2EFdf6D030579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2015 17:39:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2EFdf6D030579 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2EFdfWS030578; Sat, 14 Mar 2015 17:39:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Mar 2015 17:39:41 +0200 From: Konstantin Belousov To: Michael Fuckner Subject: Re: Server with 3TB Crashing at boot Message-ID: <20150314153941.GL2379@kib.kiev.ua> References: <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> <5504362C.9000904@fuckner.net> <20150314134733.GI2379@kib.kiev.ua> <550448B3.7050100@fuckner.net> <20150314145607.GJ2379@kib.kiev.ua> <5504530F.5040508@fuckner.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5504530F.5040508@fuckner.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Steven Hartland , Ryan Stone , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 15:39:47 -0000 On Sat, Mar 14, 2015 at 04:26:07PM +0100, Michael Fuckner wrote: > On 3/14/2015 3:56 PM, Konstantin Belousov wrote: > > On Sat, Mar 14, 2015 at 03:41:55PM +0100, Michael Fuckner wrote: > >>>> > >>>> In the Processor Configuration tab there also was > >>>> extended apic support (default is disabled) > >>> On 10.1 this option should not result in any behaviour change. > >>> > >>>> > >>>> Should I give this option a try? > >>> > >>> Up to you. I am somewhat curious whether it boots with DMAR enabled and > >>> what happens if it does not. > >>> ____ > >> > >> looks good, doesn't it? > >> > >> http://dedi3.fuckner.net/~molli123/temp/dmar.log > > No, it does not. At least I suspect that your ix* interfaces are not > > functional. The issue is with DMAR code, not with the ixgbe driver, and > > it was probably fixed in stable/10. > > why do you think it is not working? > > root@s4l:~ # ping dedi3.fuckner.net > PING dedi3.fuckner.net (81.169.184.133): 56 data bytes > 64 bytes from 81.169.184.133: icmp_seq=0 ttl=56 time=15.522 ms > 64 bytes from 81.169.184.133: icmp_seq=1 ttl=56 time=11.266 ms Ok. I looked at the lines DMAR1: :pci3:0:0 fault acc 0 adt 0x0 reason 0x5 addr 0 Due to the nature of the bug, the pci rid above could be unrelated. Anyway, good that ix* work, but it is not clear which device transfer faulted. > > > > [root@mf5 ~]# grep ix0 dmar.log > ix0: Link is Down > ix0: link state changed to DOWN > ix0: > port 0x4020-0x403f mem 0xaaa00000-0xaabfffff,0xaac04000-0xaac07fff irq > 32 at device 0.0 on pci1 > ix0: attempting to allocate 9 MSI-X vectors (64 supported) > ix0: using IRQs 272-280 for MSI-X > ix0: Using MSIX interrupts with 9 vectors > ix0: dmar3 pci0:1:0:0 domain 2 mgaw 48 agaw 48 re-mapped > ix0: bpf attached > ix0: Ethernet address: c4:54:44:92:73:d2 > ix0: PCI Express Bus: Speed 5.0GT/s Width x8 > ix0: Link is up 1 Gbps Full Duplex > ix0: ix0: link state changed to UP > ix0: link state changed to DOWN > Starting Network: lo0 ix0 ix1 ix2 ix3. > ix0: flags=8843 metric 0 mtu 1500 > nd6 options=29 Gbps Full Duplex > mediaix0: link state changed : Ethernet autosto UP > DHCPREQUEST on ix0 to 255.255.255.255 port 67 > > > I'll checkout STABLE to check now... Thank you. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 16:23:05 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94BECB59 for ; Sat, 14 Mar 2015 16:23:05 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78ECE391 for ; Sat, 14 Mar 2015 16:23:05 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t2EGMwxQ018529 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Mar 2015 09:22:58 -0700 Message-ID: <55046061.8010506@freebsd.org> Date: Sat, 14 Mar 2015 09:22:57 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Chris H , FreeBSD Hackers Subject: Re: What's the possibilities of recycling /usr/obj for other targets, etc? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVb2Kb+o4Ugk3M74bq3jRR8Pnbj6nLuAeHXKkgVB8I3tZM1SSK+qRXCJJb5NuMRVULnb8jUrK1H4F4yi3QAZ+9TNZYU9prbqYTY= X-Sonic-ID: C;rr1sYGbK5BGAgL5YxQPdhw== M;qD/NYGbK5BGAgL5YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 16:23:05 -0000 On 03/13/15 18:09, Chris H wrote: > Greetings all, > I've been combing /usr/src, build, relese, and > release engineering in the FBSD docs, for the last > couple days. But still haven't *quite* unwound everything > in src. What I'm attempting to do, is to recycle a recent > build/install world/kernel I still have in /usr/obj. > To create > 1) a utility CD/DV > 2) a [minimal] "release" CD/DVD > I'm *sure* I'm just over-complicating things. But > it's still unclear as to whether any of the already > available targets/dists -- release, distribute, > distributekernel, distributeworld. Will attempt to > REbuild world && kernel, before proceeding. If I'm > not mistaken -DNO_CLEAN (might?) help me coerce make to > do my bidding. Or is only available to speed up the > initial build, after a > cd /usr/obj > chflags -R noschg * > rm -rf * > > Any help, pointers, suggestions, ... *greatly* appreciated. > > BTW I'm attempting this on a recent -CURRENT (11). > > Thanks! make release by default will reuse the results of the previous buildworld/buildkernel in /usr/obj (see release(7)). So everything should just work for you there. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 21:41:02 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC26D78; Sat, 14 Mar 2015 21:41:02 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90E7060B; Sat, 14 Mar 2015 21:41:02 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2ELgrnH078816; Sat, 14 Mar 2015 14:42:53 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: FreeBSD Hackers , Nathan Whitehorn In-Reply-To: <55046061.8010506@freebsd.org> References: , <55046061.8010506@freebsd.org> From: "Chris H" Subject: Re: What's the possibilities of recycling /usr/obj for other targets, etc? Date: Sat, 14 Mar 2015 14:42:53 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <74f9a918b3757b19b51ded64306b9e69@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 21:41:02 -0000 On Sat, 14 Mar 2015 09:22:57 -0700 Nathan Whitehorn wrote > On 03/13/15 18:09, Chris H wrote: > > Greetings all, > > I've been combing /usr/src, build, relese, and > > release engineering in the FBSD docs, for the last > > couple days. But still haven't *quite* unwound everything > > in src. What I'm attempting to do, is to recycle a recent > > build/install world/kernel I still have in /usr/obj. > > To create > > 1) a utility CD/DV > > 2) a [minimal] "release" CD/DVD > > I'm *sure* I'm just over-complicating things. But > > it's still unclear as to whether any of the already > > available targets/dists -- release, distribute, > > distributekernel, distributeworld. Will attempt to > > REbuild world && kernel, before proceeding. If I'm > > not mistaken -DNO_CLEAN (might?) help me coerce make to > > do my bidding. Or is only available to speed up the > > initial build, after a > > cd /usr/obj > > chflags -R noschg * > > rm -rf * > > > > Any help, pointers, suggestions, ... *greatly* appreciated. > > > > BTW I'm attempting this on a recent -CURRENT (11). > > > > Thanks! > > make release by default will reuse the results of the previous > buildworld/buildkernel in /usr/obj (see release(7)). So everything > should just work for you there. > -Nathan Perfect! Exactly what I was hoping for. Thank you very much, Nathan, and apologies for the noise. --Chris --