From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 00:29:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E8A61065670 for ; Sun, 22 Nov 2009 00:29:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 717918FC0A for ; Sun, 22 Nov 2009 00:29:27 +0000 (UTC) Received: from OMTA20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id 80M71d0091smiN4A60VUPG; Sun, 22 Nov 2009 00:29:28 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA20.emeryville.ca.mail.comcast.net with comcast id 80VT1d0073S48mS8g0VTxu; Sun, 22 Nov 2009 00:29:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 57EC81E3035; Sat, 21 Nov 2009 16:29:26 -0800 (PST) Date: Sat, 21 Nov 2009 16:29:26 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091122002926.GA19628@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <790a9fff0911211159k14920410g7a76cf6a292f0bae@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <790a9fff0911211159k14920410g7a76cf6a292f0bae@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 00:29:29 -0000 On Sat, Nov 21, 2009 at 01:59:11PM -0600, Scot Hetzel wrote: > On Sat, Nov 21, 2009 at 1:36 PM, Jeremy Chadwick > wrote: > > > > On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: > >> Randy Bush wrote: > >> > imiho, zfs can not be called production ready if it crashes if you > >> > do not stand on your left leg, put your right hand in the air, and > >> > burn some eye of newt. > >> > >> This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > >> been marked as production ready. > >> As far as i know, on FreeBSD 8.0 ZFS is called production ready. > >> > >> If you boot your system it probably tell you it is still experimental. > >> > >> Try running FreeBSD 7-Stable to get the latest ZFS version which on > >> FreeBSD is 13 > >> On 7.2 it is still at 6 (if I remember it right). > > > > RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. > > > > RELENG_8 is still using ZFS v13. I meant to type ZFS v13 for RELENG_8. Fingers focused on 8 for some reason... Heh. :-) I'm not going to go on a rant talking about the recurring scenario that keeps happening on the mailing lists -- you know, where Person X says "well, use these loader.conf variables and it's stable", yet Person Y comes back with evidence that it's NOT stable. Everyone's workloads are different, but the panic is the same every time: kmem exhaustion. i386 with KVA_PAGES or amd64 -- happens on both. It's highly dependent upon workload and what the filesystem consists of (many files vs. fewer files but larger in size, etc.) > > RELENG_7 and RELENG_8 both, more or less, behave the same way with > > regards to ZFS.  Both panic on kmem exhaustion.  No one has answered my > > question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > > > Under RELENG_8/i386, you still need to tune ZFS as mentioned in the > ZFS Tuning Guide: > > http://wiki.freebsd.org/ZFSTuningGuide > > With RELENG_8/amd64 no tuning is necessary, if the system has at least 2G RAM. Nope. http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 00:44:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 732F9106566C for ; Sun, 22 Nov 2009 00:44:05 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 551F18FC12 for ; Sun, 22 Nov 2009 00:44:05 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NC0Ye-000BF4-PR; Sun, 22 Nov 2009 00:44:04 +0000 Received: from host-40-47.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 3588D2C2C0BF; Sun, 22 Nov 2009 09:44:04 +0900 (JST) Date: Sun, 22 Nov 2009 09:44:03 +0900 Message-ID: From: Randy Bush To: Jeremy Chadwick In-Reply-To: <20091122002926.GA19628@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <790a9fff0911211159k14920410g7a76cf6a292f0bae@mail.gmail.com> <20091122002926.GA19628@icarus.home.lan> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 00:44:05 -0000 > Everyone's workloads are different, but the panic is the same every > time: kmem exhaustion. i386 with KVA_PAGES or amd64 -- happens on both. > It's highly dependent upon workload and what the filesystem consists of > (many files vs. fewer files but larger in size, etc.) these are measurable. at least until it crashes. the suggested memsz script could, instead of giving what to a naive admin are some cute but unhepful numbers, suggest values for loader.conf.local. randy From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 01:02:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73109106566B for ; Sun, 22 Nov 2009 01:02:39 +0000 (UTC) (envelope-from marco@tols.org) Received: from tols.org (goofy.tols.org [83.163.60.200]) by mx1.freebsd.org (Postfix) with ESMTP id E73848FC17 for ; Sun, 22 Nov 2009 01:02:38 +0000 (UTC) Received: from donald.home.tols.org (localhost [127.0.0.1]) by donald.home.tols.org (8.14.3/8.14.3) with ESMTP id nAM0OUid001800 for ; Sun, 22 Nov 2009 00:24:30 GMT (envelope-from marco@donald.home.tols.org) Received: (from marco@localhost) by donald.home.tols.org (8.14.3/8.14.3/Submit) id nAM0OUiw001799 for freebsd-stable@freebsd.org; Sun, 22 Nov 2009 01:24:30 +0100 (CET) (envelope-from marco) Date: Sun, 22 Nov 2009 01:24:30 +0100 From: Marco van Tol To: freebsd-stable@freebsd.org Message-ID: <20091122002430.GB934@donald.home.tols.org> Mail-Followup-To: freebsd-stable@freebsd.org References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 01:02:39 -0000 On Sat, Nov 21, 2009 at 06:16:04PM +0900, Randy Bush wrote: > >> imiho, zfs can not be called production ready if it crashes if you > >> do not stand on your left leg, put your right hand in the air, and > >> burn some eye of newt. > > ROFL! > > As with any open-source project, I suppose it will be ready > > when it is ready. At least it hasn't been made the default. > > yep. i demand a full refund! :) > > my concern is the innocent admin putting something critical on zfs in > 8.0 when it is called stable and production. this isn't linux. Well, to be honest, running something critical on a release candidate is interesting enough as it is right? :-) Just my $0.02 Marco van Tol -- The first step to better times is to imagine them. - www.chinese-fortune-cookie.com From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 01:11:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85AA6106568D for ; Sun, 22 Nov 2009 01:11:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 6813E8FC0A for ; Sun, 22 Nov 2009 01:11:50 +0000 (UTC) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id 80M81d0050QkzPwAD1BrST; Sun, 22 Nov 2009 01:11:51 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id 81Bq1d00D3S48mS8N1BrZ5; Sun, 22 Nov 2009 01:11:51 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CEC1C1E3035; Sat, 21 Nov 2009 17:11:49 -0800 (PST) Date: Sat, 21 Nov 2009 17:11:49 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091122011149.GA19922@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <790a9fff0911211159k14920410g7a76cf6a292f0bae@mail.gmail.com> <20091122002926.GA19628@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20091122002926.GA19628@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 01:11:51 -0000 On Sat, Nov 21, 2009 at 04:29:26PM -0800, Jeremy Chadwick wrote: > On Sat, Nov 21, 2009 at 01:59:11PM -0600, Scot Hetzel wrote: > > > RELENG_7 and RELENG_8 both, more or less, behave the same way with > > > regards to ZFS.  Both panic on kmem exhaustion.  No one has answered my > > > question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > > > > > Under RELENG_8/i386, you still need to tune ZFS as mentioned in the > > ZFS Tuning Guide: > > > > http://wiki.freebsd.org/ZFSTuningGuide > > > > With RELENG_8/amd64 no tuning is necessary, if the system has at least 2G RAM. > > Nope. > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html I'll expand briefly on this because my post mentioned RELENG_7, and the "state" of ZFS in RELENG_7 vs. RELENG_8 vs. HEAD is hard to follow because some of the commits to (what once was) HEAD are actually in RELENG_8 given when HEAD was tagged as RELENG_8. There's a particular situation (with patch for RELENG_8) that has been "making the rounds": http://lists.freebsd.org/pipermail/freebsd-fs/2009-October/006907.html http://lists.freebsd.org/pipermail/freebsd-fs/2009-October/006969.html The discussion is with regards to slow performance as a result of ARC degrading, except numerous posters (including the OP) mention that their box also can "just hang". But this patch seems different than the one which got committed to HEAD (what is CURRENT today); revision 1.25 -- Commit message: Prevent paging pressure from draining arc too much - always drain arc if above arc_c_max - never drain arc if arc is below arc_c_max http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c.diff?r1=1.24;r2=1.25;f=h This commit is not in RELENG_8 nor RELENG_7 (I've confirmed by looking at sources), and of course the patch is "?!?" given the nature of the thread. I've looked at SVN commits to HEAD and Kip has been very, very busy (even today). :-) .....but then there's this commit, which happened ~5 months ago, and made it into HEAD at the time (thus is in RELENG_8; also verified by looking at source): Commit message: Manually export rev 192360 from kmacy http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c.diff?r1=1.19;r2=1.20;f=h ...Which I don't understand technically, but appears to have a direct effect on ARC limiting. So, this is getting very hard to track/follow. Circling back to kmem exhaustion: has there been any official statement on what's actually causing it? Is it ARC overuse (and if so how's that even possible)? Is it ZIL? Is it a combination of things? Is it bugs in the ZFS port (e.g. Solaris VM vs. FreeBSD VM)? Is it all of these things? And ultimately -- how do we work around it? With regards to loader.conf tuning, because this comes up often too: There still has been no official or even semi-official (e.g. Wiki) explanation as far as what should be tuned, and HOW things should be tuned. What are the proper variables to tune this? Tuning on RELENG_7 vs. RELENG_8 also probably differs at this point in time -- or does it? The following loader.conf variables are under scrutiny: vm.kmem_size vm.kmem_size_max vfs.zfs.arc_min vfs.zfs.arc_max vfs.zfs.prefetch_disable vfs.zfs.zil_disable The number of conflicting details on the mailing lists (freebsd-stable, freebsd-current, and freebsd-fs) make it very hard to discern at this point how one is supposed to tune loader.conf to gain stability. For example, I've seen pjd@ mention that one should NOT be touching vm.kmem_size_max, but rather vm.kmem_size -- which I don't understand (and I mean that as in "help me understand", not "I'm questioning the logic"), especially since src/UPDATING states "you probably don't need to adjust either of these". This is why we need people who are familiar with both the ZFS code and the VM to help provide details so that documentation can be updated (I'm referring to the Wiki). If we could get something official from people who are "in the know", that would be awesome. Or maybe this is the wrong list to be discussing it at all, and freebsd-fs is? I don't know any more... It's almost like we need some kind of "ZFS on FreeBSD" newsletter that's sent out weekly documenting all of what's getting changed and what it solves and how it impacts users. Things are totally chaotic right now. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 01:44:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7EDD106568B; Sun, 22 Nov 2009 01:44:28 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 564268FC08; Sun, 22 Nov 2009 01:44:28 +0000 (UTC) Received: by bwz5 with SMTP id 5so4553692bwz.3 for ; Sat, 21 Nov 2009 17:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=z3ad/daHPL91+LmPKmLzGMgWM0cTD+37NJwSdP8L96s=; b=nZHFkVUt3ce6jCQdM/h4O4dpUNc+o4h0y2YjX6uhhXxsbKNviMGHYSeWkDxKyx/5dq Jt5rdQfaW+bJO+LPTWfVwChLjXl5WUb6szNR022/XfQp7jU4tpl677wtwndyMD1YcK6W NmBIpdUq4+V0HRR2h4gNMEsAAPNOE+3jAP36c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=cEJPdNpBhf/axEnLGmlwV1H+uvlpzVMd1IeJCupxzBJsclkMP5tMPxqoy1eESSf8Qk d+LnntzS82Rw01UZZHSEX+A/KHUjf+73784o063/S5NgP6yHGpmsUxrmcTqAXOdnW/si 4v5pUd9NxSdkg6jG767MyP4UOSX5EvcuXRw1k= MIME-Version: 1.0 Received: by 10.204.157.16 with SMTP id z16mr3025806bkw.103.1258854267160; Sat, 21 Nov 2009 17:44:27 -0800 (PST) Date: Sun, 22 Nov 2009 01:44:27 +0000 Message-ID: <6101e8c40911211744y3ec455a2l441361171d9a004b@mail.gmail.com> From: Oliver Pinter To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: MFC of r198284 to 7-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 01:44:29 -0000 commit 4a6ea694eaad85c9ff99668ba7427c00cea3e990 Author: kib Date: Tue Oct 20 13:34:41 2009 +0000 MFC r197934: Map PIE binaries at non-zero base address. MFC r198202: Honour non-zero mapbase for PIE binaries. Inform interpreter-less PIE binary about its relocbase. Approved by: re (kensmith) git-svn-id: svn://svn.freebsd.org/base/stable/8@198284 ccf9f872-aa2e-dd11-9fc8-001c23d0 From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 02:44:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F4A2106566B for ; Sun, 22 Nov 2009 02:44:13 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com (web.hostmailing.com [200.110.145.34]) by mx1.freebsd.org (Postfix) with ESMTP id 61A9D8FC12 for ; Sun, 22 Nov 2009 02:44:12 +0000 (UTC) Received: from web.hostmailing.com ([200.110.145.34] helo=www.hostmailing.com) by web.hostmailing.com with esmtpa (Exim 4.63) (envelope-from ) id 1NC2Ko-0004Xb-HG for freebsd-stable@freebsd.org; Sat, 21 Nov 2009 23:37:54 -0300 Date: Sat, 21 Nov 2009 23:37:54 -0300 To: freebsd-stable@freebsd.org From: Exemys Message-ID: <145b6ddbb47618a8ff694dd543543ede@www.hostmailing.com> X-Priority: 3 X-Mailer: wh4535 [version 4.1] X-Fid: eGZpZC1mcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZy0yMzI3NC03MzE4LTY4NjM= MIME-Version: 1.0 Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Pulse Meter with Cellular communication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: exemys@exemys.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 02:44:13 -0000 This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 03:46:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96DC5106566C; Sun, 22 Nov 2009 03:46:25 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (server70.appriver.com [69.20.119.203]) by mx1.freebsd.org (Postfix) with ESMTP id 00B358FC0A; Sun, 22 Nov 2009 03:46:24 +0000 (UTC) X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note: TCH-CT/SI:0-5/SG:5 11/21/2009 10:46:18 PM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.733847 p=-0.903069 Source Normal X-Signature-Violations: 0-0-0-28178-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 107744208; Sat, 21 Nov 2009 22:46:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 21 Nov 2009 19:40:27 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC USB problem -- how to recover a damaged USB stick Thread-Index: AcpoP3z6JZv+wKUaR6W88hemmQS/OQC4iGNc References: <200911181213.34112.hselasky@c2i.net> From: "Guojun Jin" To: "Hans Petter Selasky" , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: questions@freebsd.org, freebsd-stable@freebsd.org Subject: 8.0-RC USB problem -- how to recover a damaged USB stick X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 03:46:25 -0000 It seems this is more serious problem in 8.0, and I hope it could be = resolved before a formal release. I can help to diagnose this if people = need more information (this is destructive). I have picked a USB stick (DataTraveler 2GB), that has two partitions s0 = for DOS and s1 for FreeBSD. Both USB hard drive and the USB stick have worked under FreeBSD 6.2, = 6.3, 6.4 and 7.2 for a few years without any problem. Plugged USB stick in 8.0-RC and mounted it on /mnt; then untar a file, tarred one day ago from FreeBSD 6.3 machine onto stick,to = a IDE drive then tar it back to the USB stick. During tar writting from IDE to USB stick, did "ls /mnt", and "tar" = paused and "ls" hangs. A couple of minutes later, ls comes back, but tar still pauses. Hit ^C on tar process around 14:30, it took another minutes to stop the = process. Tried tar again, and system disallowed to write on the USB stick. "ls" shows all file = still there (probably cached inods). Went out for a few hours, and came back found /var/log/message are = flooded with following message: -rw-r--r-- 1 root wheel 167181 Nov 21 19:02 messages -rw-r--r-- 1 root wheel 7390 Nov 21 18:00 messages.0.bz2 -rw-r--r-- 1 root wheel 7509 Nov 21 17:00 messages.1.bz2 -rw-r--r-- 1 root wheel 9365 Nov 21 16:00 messages.2.bz2 -rw-r--r-- 1 root wheel 20598 Nov 21 15:00 messages.3.bz2 Nov 21 18:00:00 wolf newsyslog[2635]: logfile turned over due to = size>384K Nov 21 18:00:27 wolf kernel: = g_vfs_done():da0s2[WRITE(offset=3D625688576, length=3D1 31072)]error =3D 5 Nov 21 18:00:27 wolf kernel: = g_vfs_done():da0s2[WRITE(offset=3D625819648, length=3D1 31072)]error =3D 5 ..... Nov 21 18:19:03 wolf kernel: = g_vfs_done():da0s2[WRITE(offset=3D524451840, length=3D1 6384)]error =3D 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=3D5586944, = length=3D204 8)]error =3D 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=3D65536, = length=3D2048) ]error =3D 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=3D114688, = length=3D1638 4)]error =3D 5 Nov 21 18:20:05 wolf kernel: = g_vfs_done():da0s2[WRITE(offset=3D349700096, length=3D1 and has to reboot the system, and reboot was not able to umount = everything (boot up message): Nov 21 18:24:03 wolf kernel: da0: = Removable Dir ect Access SCSI-2 device Nov 21 18:24:03 wolf kernel: da0: 40.000MB/s transfers Nov 21 18:24:03 wolf kernel: da0: 1947MB (3987456 512 byte sectors: 255H = 63S/T 2 48C) Nov 21 18:24:03 wolf kernel: WARNING: / was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /data was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /home was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /tmp was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /usr was not properly dismounted ... # mount /dev/da0s2 /mnt mount: /dev/da0s2 : Operation not permitted The USB stick cannot be mount under any FreeBSD OS now, and everything = on the drive has lost. Does anyone know if it is possible to revocer such damaged USB stick? -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wed 11/18/2009 3:13 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; freebsd-stable@freebsd.org; questions@freebsd.org Subject: Re: 8.0-RC3 USB lock up on mounting two partitions from one USB = drive =20 Hi, I'm not sure if this is an USB issue or not. If you get READ/WRITE = errors and=20 the drive simply dies then it might be the case. Else it is a system = issue. There are quirks for mass storage which you can add to=20 sys/dev/usb/storage/umass.c . --HPS On Wednesday 18 November 2009 08:33:07 Guojun Jin wrote: > Did newfs on those partition and made things worsen -- restore = completely > fails: (I had experienced another similar problem on an IDE, which = works > well for 6.4 and 7.2, but 8.0.) This dirve works fine under FreeBSD = 6.4. > > Is something new in 8.0 making disk partition schema changed? > > g_vfs_done():da0s3d[READ(offset=3D98304, length=3D16384)]error =3D 6 > g_vfs_done():da0s3d[WRITE(offset=3D192806912, length=3D16384)]error = =3D 6 > fopen: Device not configured > cannot create save file ./restoresymtable for symbol table > abort? [yn] (da0:umass-sim0:0:0:0): Synchronize cache failed, status = =3D=3D > 0xa, scs i status =3D=3D 0x0 > (da0:umass-sim0:0:0:0): removing device entry > ugen1.2: at usbus1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) > Device da0s3d went missing before all of the data could be written to = it; > expect data loss. > > 99 23:19 sysinstall > 100 23:20 newfs /dev/da0s3d > 101 23:20 newfs /dev/da0s3e > 102 23:21 mount /dev/da0s3d /mnt > 103 23:21 cd /mnt > 104 23:21 dump -0f - /home | restore -rf - > 105 23:27 history 15 > > > > -----Original Message----- > From: Guojun Jin > Sent: Tue 11/17/2009 11:05 PM > To: freebsd-stable@freebsd.org > Cc: questions@freebsd.org; freebsd-usb@freebsd.org > Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB = drive > > When mounting two partitions from a USB dirve, it can cause the drive > access lock up for a long time. Details: > > Terminal 1 -- > term1# mount /dev/da0s3d /mnt > term1# cd /mnt ; rm -fr * > > when rm starts, go to terminal 2 and do: > > term2# mount /dev/da0s3e /dist ### this will hanging for a long time = and > USB hard drive activity light is off. After more than 1-2 minutes, = mount > returns, and the drive activity light is blinking, thus removing is = going > on. > > term2# ls /dist ### this will cause dUSB dirve hanging again -- no > avtivity. Similarly, ls will finish in a couple of miniutes or longer, = the > rm command continues; but for a while, the drive activity will stop = again. > > Reboot machine, repeat the above steps, and result will be the same. = Reboot > machine again, and just mount one partition, then doing "rm -rf *" = without > involve the second partition, rm will finish quickly. > > Has anyone obseved this behave on 8.0-RC? > > -Jin From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 04:45:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28742106566B; Sun, 22 Nov 2009 04:45:34 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (server70b.appriver.com [74.205.4.150]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE738FC14; Sun, 22 Nov 2009 04:45:33 +0000 (UTC) X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note: TCH-CT/SI:0-30/SG:5 11/21/2009 11:45:18 PM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.734345 p=-0.903537 Source Normal X-Signature-Violations: 0-0-0-32767-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 107744544; Sat, 21 Nov 2009 23:45:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 21 Nov 2009 20:38:13 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC USB/FS problem Thread-Index: AcpoP3z6JZv+wKUaR6W88hemmQS/OQC4iGNcAAKBqPo= References: <200911181213.34112.hselasky@c2i.net> From: "Guojun Jin" To: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 04:45:34 -0000 Tried on the USB hard drive: Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. Was happy because successfully did dump/restore on s3d, and thought it = just partition format issue; but system crashed during dump/restore on s3e, and partition lost the = file system type. wolf# mount /dev/da0s3e /mnt WARNING: /mnt was not properly dismounted /mnt: mount pending error: blocks 35968 files 0 wolf# fsck da0s3e fsck: Could not determine filesystem type wolf# bsdlabel da0s3 # /dev/da0s3: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 175735035 0 unused 0 0 # "raw" part, = don't edi t d: 18874368 0 4.2BSD 0 0 0 e: 156860667 18874368 4.2BSD 0 0 0 Therefore, tried directly use fsck_ufs on both USB hard drive and USB = stick to get file system clean up. All data got back now. The machine has run with FreeBSD 6.1 all the way to 7.2 without such = problem. How can we determine what could go wrong in 8.0? FS or USB. By the way, IDE to IDE dump/restore seems not having such problem at = this point, although one of IDE drive experienced partition recognizing problem, which went = away after deleting slices and recreating slices. -----Original Message----- From: Guojun Jin Sent: Sat 11/21/2009 7:40 PM To: Hans Petter Selasky; freebsd-usb@freebsd.org Cc: freebsd-stable@freebsd.org; questions@freebsd.org Subject: 8.0-RC USB problem -- how to recover a damaged USB stick =20 It seems this is more serious problem in 8.0, and I hope it could be = resolved before a formal release. I can help to diagnose this if people = need more information (this is destructive). I have picked a USB stick (DataTraveler 2GB), that has two partitions s0 = for DOS and s1 for FreeBSD. Both USB hard drive and the USB stick have worked under FreeBSD 6.2, = 6.3, 6.4 and 7.2 for a few years without any problem. Plugged USB stick in 8.0-RC and mounted it on /mnt; then untar a file, tarred one day ago from FreeBSD 6.3 machine onto stick,to = a IDE drive then tar it back to the USB stick. During tar writting from IDE to USB stick, did "ls /mnt", and "tar" = paused and "ls" hangs. A couple of minutes later, ls comes back, but tar still pauses. Hit ^C on tar process around 14:30, it took another minutes to stop the = process. Tried tar again, and system disallowed to write on the USB stick. "ls" shows all file = still there (probably cached inods). Went out for a few hours, and came back found /var/log/message are = flooded with following message: -rw-r--r-- 1 root wheel 167181 Nov 21 19:02 messages -rw-r--r-- 1 root wheel 7390 Nov 21 18:00 messages.0.bz2 -rw-r--r-- 1 root wheel 7509 Nov 21 17:00 messages.1.bz2 -rw-r--r-- 1 root wheel 9365 Nov 21 16:00 messages.2.bz2 -rw-r--r-- 1 root wheel 20598 Nov 21 15:00 messages.3.bz2 Nov 21 18:00:00 wolf newsyslog[2635]: logfile turned over due to = size>384K Nov 21 18:00:27 wolf kernel: = g_vfs_done():da0s2[WRITE(offset=3D625688576, length=3D1 31072)]error =3D 5 Nov 21 18:00:27 wolf kernel: = g_vfs_done():da0s2[WRITE(offset=3D625819648, length=3D1 31072)]error =3D 5 ..... Nov 21 18:19:03 wolf kernel: = g_vfs_done():da0s2[WRITE(offset=3D524451840, length=3D1 6384)]error =3D 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=3D5586944, = length=3D204 8)]error =3D 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=3D65536, = length=3D2048) ]error =3D 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=3D114688, = length=3D1638 4)]error =3D 5 Nov 21 18:20:05 wolf kernel: = g_vfs_done():da0s2[WRITE(offset=3D349700096, length=3D1 and has to reboot the system, and reboot was not able to umount = everything (boot up message): Nov 21 18:24:03 wolf kernel: da0: = Removable Dir ect Access SCSI-2 device Nov 21 18:24:03 wolf kernel: da0: 40.000MB/s transfers Nov 21 18:24:03 wolf kernel: da0: 1947MB (3987456 512 byte sectors: 255H = 63S/T 2 48C) Nov 21 18:24:03 wolf kernel: WARNING: / was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /data was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /home was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /tmp was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /usr was not properly dismounted ... # mount /dev/da0s2 /mnt mount: /dev/da0s2 : Operation not permitted The USB stick cannot be mount under any FreeBSD OS now, and everything = on the drive has lost. Does anyone know if it is possible to revocer such damaged USB stick? -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wed 11/18/2009 3:13 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; freebsd-stable@freebsd.org; questions@freebsd.org Subject: Re: 8.0-RC3 USB lock up on mounting two partitions from one USB = drive =20 Hi, I'm not sure if this is an USB issue or not. If you get READ/WRITE = errors and=20 the drive simply dies then it might be the case. Else it is a system = issue. There are quirks for mass storage which you can add to=20 sys/dev/usb/storage/umass.c . --HPS On Wednesday 18 November 2009 08:33:07 Guojun Jin wrote: > Did newfs on those partition and made things worsen -- restore = completely > fails: (I had experienced another similar problem on an IDE, which = works > well for 6.4 and 7.2, but 8.0.) This dirve works fine under FreeBSD = 6.4. > > Is something new in 8.0 making disk partition schema changed? > > g_vfs_done():da0s3d[READ(offset=3D98304, length=3D16384)]error =3D 6 > g_vfs_done():da0s3d[WRITE(offset=3D192806912, length=3D16384)]error = =3D 6 > fopen: Device not configured > cannot create save file ./restoresymtable for symbol table > abort? [yn] (da0:umass-sim0:0:0:0): Synchronize cache failed, status = =3D=3D > 0xa, scs i status =3D=3D 0x0 > (da0:umass-sim0:0:0:0): removing device entry > ugen1.2: at usbus1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) > Device da0s3d went missing before all of the data could be written to = it; > expect data loss. > > 99 23:19 sysinstall > 100 23:20 newfs /dev/da0s3d > 101 23:20 newfs /dev/da0s3e > 102 23:21 mount /dev/da0s3d /mnt > 103 23:21 cd /mnt > 104 23:21 dump -0f - /home | restore -rf - > 105 23:27 history 15 > > > > -----Original Message----- > From: Guojun Jin > Sent: Tue 11/17/2009 11:05 PM > To: freebsd-stable@freebsd.org > Cc: questions@freebsd.org; freebsd-usb@freebsd.org > Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB = drive > > When mounting two partitions from a USB dirve, it can cause the drive > access lock up for a long time. Details: > > Terminal 1 -- > term1# mount /dev/da0s3d /mnt > term1# cd /mnt ; rm -fr * > > when rm starts, go to terminal 2 and do: > > term2# mount /dev/da0s3e /dist ### this will hanging for a long time = and > USB hard drive activity light is off. After more than 1-2 minutes, = mount > returns, and the drive activity light is blinking, thus removing is = going > on. > > term2# ls /dist ### this will cause dUSB dirve hanging again -- no > avtivity. Similarly, ls will finish in a couple of miniutes or longer, = the > rm command continues; but for a while, the drive activity will stop = again. > > Reboot machine, repeat the above steps, and result will be the same. = Reboot > machine again, and just mount one partition, then doing "rm -rf *" = without > involve the second partition, rm will finish quickly. > > Has anyone obseved this behave on 8.0-RC? > > -Jin From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 05:20:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EDD1106566B for ; Sun, 22 Nov 2009 05:20:33 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id EFA1A8FC18 for ; Sun, 22 Nov 2009 05:20:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 6C86A93872; Sun, 22 Nov 2009 00:20:31 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3zItcCLkccG; Sun, 22 Nov 2009 00:20:31 -0500 (EST) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 1074893861; Sun, 22 Nov 2009 00:20:31 -0500 (EST) Received: by localhost (Postfix, from userid 21281) id 0C4FF275; Sun, 22 Nov 2009 00:20:31 -0500 (EST) Date: Sun, 22 Nov 2009 00:20:31 -0500 From: Adam McDougall To: Jeremy Chadwick Message-ID: <20091122052030.GL1213@egr.msu.edu> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091121193643.GA14122@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 05:20:33 -0000 On Sat, Nov 21, 2009 at 11:36:43AM -0800, Jeremy Chadwick wrote: On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: > Randy Bush wrote: > > imiho, zfs can not be called production ready if it crashes if you > > do not stand on your left leg, put your right hand in the air, and > > burn some eye of newt. > > This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > been marked as production ready. > As far as i know, on FreeBSD 8.0 ZFS is called production ready. > > If you boot your system it probably tell you it is still experimental. > > Try running FreeBSD 7-Stable to get the latest ZFS version which on > FreeBSD is 13 > On 7.2 it is still at 6 (if I remember it right). RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. RELENG_7 and RELENG_8 both, more or less, behave the same way with regards to ZFS. Both panic on kmem exhaustion. No one has answered my question as far as what's needed to stabilise ZFS on either 7.x or 8.x. I have a stable public ftp/http/rsync/cvsupd mirror that runs ZFS v13. It has been stable since mid may. I have not had a kmem panic on any of my ZFS systems for a long time, its a matter of making sure there is enough kmem at boot (not depending on kmem_size_max) and that it is big enough that fragmentation does not cause a premature allocation failure due to lack of large-enough contiguous chunk. This requires the platform to support a kmem size that is "big enough"... i386 can barely muster 1.6G and sometimes that might not be enough. I'm pretty sure all of my currently existing ZFS systems are amd64 where the kmem can now be huge. On the busy fileserver with 20 gigs of ram running FreeBSD 8.0-RC2 #21: Tue Oct 27 21:45:41 EDT 2009, I currently have: vfs.zfs.arc_max=16384M vfs.zfs.arc_min=4096M vm.kmem_size=18G The arc settings here are to try to encourage it to favor the arc cache instead of whatever else Inactive memory in 'top' contains. On other systems that are hit less hard, I simply set: vm.kmem_size="20G" I even do this on systems with much less ram, it doesn't seem to matter except it works, this is on an amd64 with only 8G. Most of my ZFS systems are 7.2-stable, some are 8.0-something. Anything with v13 is much better than v6, but 8.0 has additional fixes that have not been backported to 7 yet. I don't consider the additional fixes in 8 required for my uses yet, although I'm planning on moving forward eventually. I would consider 2G kmem a realistic minimum on a system that will see some serious disk IO (regardless of how much ram the system actually contains, as long as the kmem size can be set that big and the system not blow chunks). Hope this personal experience helps. The people who need to answer the question are those who are familiar with the code. Specifically: Kip Macy, Pawel Jakub Dawidek, and anyone else who knows the internals. Everyone else in the user community is simply guessing + going crazy trying to figure out a solution. As much as I appreciate all the work that has been done to bring ZFS to FreeBSD -- and I do mean that! -- we need answers at this point. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 07:31:35 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89889106566B for ; Sun, 22 Nov 2009 07:31:35 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 399548FC0A for ; Sun, 22 Nov 2009 07:31:34 +0000 (UTC) Received: (qmail 21531 invoked by uid 0); 22 Nov 2009 07:04:54 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Nov 2009 07:04:54 -0000 Date: Sun, 22 Nov 2009 02:04:53 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: panic in 7.2 (ffs_alloc.c?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 07:31:35 -0000 Howdy, I'm not expert at getting info out of a dump, but I'll do my best to provide some information. This is a Dell PE2970 w/PERC6/i RAID running FreeBSD 7.2/amd64. Brand new box, has been doing very light work for about two weeks. Last night I started a very long mstone run on a jailed mail server and found that quite a way into this burn-in, the box paniced. I was going to put it in service Monday (after punishing it all weekend). Looking for some input on what the root cause is and whether going to a -stable snapshot might be worthwhile. I can tell you there was a good deal of disk activity at the time in the jail - mstone was simulating 100 POP and SMTP clients hitting the machine at once. This is qmail+courier. So messages are coming in, hitting the queue, hitting a user's maildir, getting read and deleted via the POP "client" over and over again. I do see lots of "ffs_*" stuff in the backtrace, which is a little scary. Here's my stab at a kgdb session (also @ pastie for easier reading: http://pastie.org/709671): [root@bigmail /usr/obj/usr/src/sys/BWAY7-64]# kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x12d4b9f5c fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff8050382e stack pointer = 0x10:0xffffffff281a75b0 frame pointer = 0x10:0xffffff000455f800 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 = 6324 (vdelivermail) trap number = 12 panic: page fault cpuid = 0 Uptime: 12d0h32m3s Physical memory: 6130 MB Dumping 725 MB: 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); #3 0xffffffff8034cba2 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff80574823 in trap_fatal (frame=0xffffff00046c8000, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0xffffffff80574bf5 in trap_pfault (frame=0xffffffff281a7500, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673 #6 0xffffffff80575534 in trap (frame=0xffffffff281a7500) at /usr/src/sys/amd64/amd64/trap.c:444 #7 0xffffffff8055969e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #8 0xffffffff8050382e in ffs_realloccg (ip=0xffffff00267f75c0, lbprev=0, bprev=6288224785898156086, bpref=593305256, osize=0, nsize=2048, flags=33619968, cred=0xffffff00927fe800, bpp=0xffffffff281a7800) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1349 #9 0xffffffff80506e8e in ffs_balloc_ufs2 (vp=0xffffff0027a64dc8, startoffset=Variable "startoffset" is not available. ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:692 #10 0xffffffff805223e5 in ffs_write (ap=0xffffffff281a7a10) at /usr/src/sys/ufs/ffs/ffs_vnops.c:724 #11 0xffffffff805a0645 in VOP_WRITE_APV (vop=0xffffffff80793d20, a=0xffffffff281a7a10) at vnode_if.c:691 #12 0xffffffff803dd731 in vn_write (fp=0xffffff001027cd00, uio=0xffffffff281a7b00, active_cred=Variable "active_cred" is not available. ) at vnode_if.h:373 #13 0xffffffff80388768 in dofilewrite (td=0xffffff00046c8000, fd=5, fp=0xffffff001027cd00, auio=dwarf2_read_address: Corrupted DWARF expression. ) at file.h:257 #14 0xffffffff80388a6e in kern_writev (td=0xffffff00046c8000, fd=5, auio=0xffffffff281a7b00) at /usr/src/sys/kern/sys_generic.c:402 #15 0xffffffff80388aec in write (td=0x800, uap=0x12d4b9f50) at /usr/src/sys/kern/sys_generic.c:318 #16 0xffffffff80596a66 in ia32_syscall (frame=0xffffffff281a7c80) at /usr/src/sys/amd64/ia32/ia32_syscall.c:182 #17 0xffffffff80559ad0 in Xint0x80_syscall () at ia32_exception.S:65 #18 0x0000000028167928 in ?? () Previous frame inner to this frame (corrupt stack?) Full dmesg, verbose boot and kernel config at pastie as well. Actually no verbose boot... I rebooted the box after setting verbose boot with "nextboot" and it didn't come back. Hrmph. No remote console, so I don't know what's up, perhaps waiting on some manual fsck action. Thanks, Charles From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 09:00:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20C931065672 for ; Sun, 22 Nov 2009 09:00:01 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4BC8FC0A for ; Sun, 22 Nov 2009 09:00:00 +0000 (UTC) Received: from [192.168.4.14] (unknown [192.168.4.14]) (Authenticated sender: svein) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 7D5D526; Sun, 22 Nov 2009 09:59:59 +0100 (CET) Message-ID: <4B08FD93.4070409@stillbilde.net> Date: Sun, 22 Nov 2009 10:00:03 +0100 From: "Svein Skogen (listmail account)" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam McDougall References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <20091122052030.GL1213@egr.msu.edu> In-Reply-To: <20091122052030.GL1213@egr.msu.edu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 09:00:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam McDougall wrote: > On Sat, Nov 21, 2009 at 11:36:43AM -0800, Jeremy Chadwick wrote: > > > On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: > > Randy Bush wrote: > > > imiho, zfs can not be called production ready if it crashes if you > > > do not stand on your left leg, put your right hand in the air, and > > > burn some eye of newt. > > > > This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > > been marked as production ready. > > As far as i know, on FreeBSD 8.0 ZFS is called production ready. > > > > If you boot your system it probably tell you it is still experimental. > > > > Try running FreeBSD 7-Stable to get the latest ZFS version which on > > FreeBSD is 13 > > On 7.2 it is still at 6 (if I remember it right). > > RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. > > RELENG_7 and RELENG_8 both, more or less, behave the same way with > regards to ZFS. Both panic on kmem exhaustion. No one has answered my > question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > > I have a stable public ftp/http/rsync/cvsupd mirror that runs ZFS v13. > It has been stable since mid may. I have not had a kmem panic on any > of my ZFS systems for a long time, its a matter of making sure there is > enough kmem at boot (not depending on kmem_size_max) and that it is big enough > that fragmentation does not cause a premature allocation failure due to lack > of large-enough contiguous chunk. This requires the platform to support a > kmem size that is "big enough"... i386 can barely muster 1.6G and sometimes > that might not be enough. I'm pretty sure all of my currently existing ZFS > systems are amd64 where the kmem can now be huge. On the busy fileserver with > 20 gigs of ram running FreeBSD 8.0-RC2 #21: Tue Oct 27 21:45:41 EDT 2009, > I currently have: > vfs.zfs.arc_max=16384M > vfs.zfs.arc_min=4096M > vm.kmem_size=18G > The arc settings here are to try to encourage it to favor the arc cache > instead of whatever else Inactive memory in 'top' contains. Very interesting. For my iscsi backend (running istgt from ports), I had to change the arc_max below 128M to stop iSCSI initiators generating timeouts when the cache flushed. (This is on a system with a megaraid 8308ELP handling the disk back end, with the disks in two RAID5 arrays of four disks each, zpooled as one big pool). When I had more than 128M arc_max, zfs on regular times ate all available resources to flush to disk, leaving the istgt waiting, and iSCSI initiators timed out and had to reconnect. The iSCSI initiators are the built-in software initator in VMWare ESX 4i. //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg Østli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksI/ZMACgkQODUnwSLUlKRr6gCfeq5dybIfp5RLOzjL04guLV25 +qgAn04SjnGG3lBRExQaMjxyKcd9Jcct =ubYi -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 09:31:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA7BF106566C; Sun, 22 Nov 2009 09:31:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id D03968FC0A; Sun, 22 Nov 2009 09:31:43 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=iMyEeliNSOsA:10 a=RERtC8nhXGhYvIZhK0yWrQ==:17 a=VHrStUV67yV2xKv06s0A:9 a=jNZRmPzEl3JUsrUVeXkbrUMrroUA:4 Received: from [90.149.203.35] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1330222682; Sun, 22 Nov 2009 10:31:41 +0100 From: Hans Petter Selasky To: "Guojun Jin" Date: Sun, 22 Nov 2009 10:33:15 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200911181213.34112.hselasky@c2i.net> In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911221033.17251.hselasky@c2i.net> Cc: questions@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.0-RC USB problem -- how to recover a damaged USB stick X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 09:31:44 -0000 On Sunday 22 November 2009 04:40:27 Guojun Jin wrote: > Does anyone know if it is possible to revocer such damaged USB stick? Hi, There are several recovery tools in /usr/ports for this kind of task. For example photorec . --HPS From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 09:45:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 809381065670; Sun, 22 Nov 2009 09:45:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 78A148FC0C; Sun, 22 Nov 2009 09:45:46 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=RERtC8nhXGhYvIZhK0yWrQ==:17 a=YQtf8eRKws4ADrAROVgA:9 a=_rwKxgonmejjDw73-l6V-51-0GQA:4 Received: from [90.149.203.35] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1322095374; Sun, 22 Nov 2009 10:45:44 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sun, 22 Nov 2009 10:47:18 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911221047.20362.hselasky@c2i.net> Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, Guojun Jin Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 09:45:47 -0000 On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: > Tried on the USB hard drive: > > Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. > Was happy because successfully did dump/restore on s3d, and thought it just > partition format issue; but system crashed during dump/restore on s3e, and > partition lost the file system type. > > wolf# mount /dev/da0s3e /mnt > WARNING: /mnt was not properly dismounted > /mnt: mount pending error: blocks 35968 files 0 > wolf# fsck da0s3e > fsck: Could not determine filesystem type > wolf# bsdlabel da0s3 > # /dev/da0s3: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 175735035 0 unused 0 0 # "raw" part, > don't edi t > d: 18874368 0 4.2BSD 0 0 0 > e: 156860667 18874368 4.2BSD 0 0 0 > > Therefore, tried directly use fsck_ufs on both USB hard drive and USB stick > to get file system clean up. All data got back now. > > The machine has run with FreeBSD 6.1 all the way to 7.2 without such > problem. How can we determine what could go wrong in 8.0? FS or USB. Hi, Error 5 means IO error, so probably the transport layer, USB or lower, is to blame. Some things to check: 1) Make sure the connection for your memory stick is Ok. 2) Make sure there is enough power for your memory stick. Regarding memory sticks: Other operating systems do a port bus reset when the device has a problem. On FreeBSD we just try a software reset via the control endpoint. I guess that it is a device problem you are seeing. The USB stack in FreeBSD is faster than the old one, and maybe the faster queueing of mass storage requests trigger some hidden bugs in your device. When the problem happens try: sysctl hw.usb.umass.debug=-1 --HPS From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 15:13:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 230A81065676 for ; Sun, 22 Nov 2009 15:13:00 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.80]) by mx1.freebsd.org (Postfix) with ESMTP id BCDC88FC0A for ; Sun, 22 Nov 2009 15:12:59 +0000 (UTC) Received: from mail53.abv.bg (mail53.ni.bg [192.168.151.29]) by smtp-out.abv.bg (Postfix) with ESMTP id 7FF2B87AC0; Sun, 22 Nov 2009 17:13:36 +0200 (EET) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=UEHM38gGNj6iF5DSri1mD/9oi07ol/0IBVfEgjq8Ca/9bVgbXhPiza4lpSgWPOVFd m/ipJKJSxPcemc3XzqFDpo6hl20rph+kYAKZ5R4eUTT25L+3rU5r8tuwOOtmYk9lTmp D7BFb6bQETXm24rFdSBkhgl/Qm8Bgpx/Sl0NZpU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1258902816; bh=kevwHKkMwMKX6n9nvOWOuPfHwoPWw5MtrE25TEjrwGQ=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:DKIM; b=gtOC+FGOce5UxW9Sf1gwLf56w44B1E/7X+diLnbO4KpW6Jl7QvQEw/NfZARo+PXvY RAok49DUqNHGRvIFilx+Vqgu4Uix1dx38q7xk8a8hmCj21W6Z3I9PB2jJOO/TgwHL5 dGkYyQudzaKv5T7Z312xM8qYndSfqe8iTSE+1aeo= Received: from mail53.abv.bg (localhost.localdomain [127.0.0.1]) by mail53.abv.bg (Postfix) with ESMTP id C0F9B241BEA; Sun, 22 Nov 2009 17:13:14 +0200 (EET) Date: Sun, 22 Nov 2009 17:13:14 +0200 (EET) From: Mario Pavlov To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, freebsd-acpi@freebsd.org Message-ID: <24772986.196751.1258902794788.JavaMail.apache@mail53.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Mailer: AbvMail 1.0 X-Originating-IP: 78.128.21.208 Cc: Subject: BIOS resource allocation and FreeBSD ACPI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 15:13:00 -0000 Hi, I see this problem over and over again... some time ago I created this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/135070 and I just saw it has been duplicated: http://www.freebsd.org/cgi/query-pr.cgi?pr=140751 maybe the later one should be closed as a duplicate... anyway I think I saw this problem reported for more than 10 different laptops in the lists and the forums...maybe it's time someone to fix this issue ... I'm willing to donate money if someone can take and fix this (yes, I'm serious, I think it's worth it) regards, mgp ----------------------------------------------------------------- ВОжте вПЎещОте МПвОМО Пт Vesti.bg! http://www.vesti.bg From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 16:51:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F17F106566C for ; Sun, 22 Nov 2009 16:51:27 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 5AFFE8FC14 for ; Sun, 22 Nov 2009 16:51:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 562E97A5B8; Sun, 22 Nov 2009 11:51:26 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kxQT47RITAS; Sun, 22 Nov 2009 11:51:26 -0500 (EST) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 162B97A5B5; Sun, 22 Nov 2009 11:51:25 -0500 (EST) Received: by localhost (Postfix, from userid 21281) id ED094286; Sun, 22 Nov 2009 11:51:25 -0500 (EST) Date: Sun, 22 Nov 2009 11:51:25 -0500 From: Adam McDougall To: "Svein Skogen (listmail account)" Message-ID: <20091122165125.GN1213@egr.msu.edu> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <20091122052030.GL1213@egr.msu.edu> <4B08FD93.4070409@stillbilde.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B08FD93.4070409@stillbilde.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 16:51:27 -0000 On Sun, Nov 22, 2009 at 10:00:03AM +0100, Svein Skogen (listmail account) wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam McDougall wrote: > On Sat, Nov 21, 2009 at 11:36:43AM -0800, Jeremy Chadwick wrote: > > > On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: > > Randy Bush wrote: > > > imiho, zfs can not be called production ready if it crashes if you > > > do not stand on your left leg, put your right hand in the air, and > > > burn some eye of newt. > > > > This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > > been marked as production ready. > > As far as i know, on FreeBSD 8.0 ZFS is called production ready. > > > > If you boot your system it probably tell you it is still experimental. > > > > Try running FreeBSD 7-Stable to get the latest ZFS version which on > > FreeBSD is 13 > > On 7.2 it is still at 6 (if I remember it right). > > RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. > > RELENG_7 and RELENG_8 both, more or less, behave the same way with > regards to ZFS. Both panic on kmem exhaustion. No one has answered my > question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > > I have a stable public ftp/http/rsync/cvsupd mirror that runs ZFS v13. > It has been stable since mid may. I have not had a kmem panic on any > of my ZFS systems for a long time, its a matter of making sure there is > enough kmem at boot (not depending on kmem_size_max) and that it is big enough > that fragmentation does not cause a premature allocation failure due to lack > of large-enough contiguous chunk. This requires the platform to support a > kmem size that is "big enough"... i386 can barely muster 1.6G and sometimes > that might not be enough. I'm pretty sure all of my currently existing ZFS > systems are amd64 where the kmem can now be huge. On the busy fileserver with > 20 gigs of ram running FreeBSD 8.0-RC2 #21: Tue Oct 27 21:45:41 EDT 2009, > I currently have: > vfs.zfs.arc_max=16384M > vfs.zfs.arc_min=4096M > vm.kmem_size=18G > The arc settings here are to try to encourage it to favor the arc cache > instead of whatever else Inactive memory in 'top' contains. Very interesting. For my iscsi backend (running istgt from ports), I had to change the arc_max below 128M to stop iSCSI initiators generating timeouts when the cache flushed. (This is on a system with a megaraid 8308ELP handling the disk back end, with the disks in two RAID5 arrays of four disks each, zpooled as one big pool). When I had more than 128M arc_max, zfs on regular times ate all available resources to flush to disk, leaving the istgt waiting, and iSCSI initiators timed out and had to reconnect. The iSCSI initiators are the built-in software initator in VMWare ESX 4i. //Svein I could understand that happening. I've seen situations in the past where my kmem was smaller than I wanted it to be, and within a few days the overall ZFS disk IO would become incredibly slow because it was trying to flush out the ARC way too often because of external intense memory pressure on the ARC. Assuming you have a large amount of ram, I wonder if setting kmem_size, arc_min and arc_max sufficiently large and using modern code would help as long as you made sure other processes on the machine don't squeeze down Wired memory in top too much. In such a situation, I would expect it to operate fine while the ARC has enough kmem to expand as much as it wants to, and it might either hit a wall later or perhaps given enough ARC the reclamation might be tolerable. Or, if 128M ARC is good enough for you, leave it :) From owner-freebsd-stable@FreeBSD.ORG Sun Nov 22 22:10:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E35E1065704; Sun, 22 Nov 2009 22:10:11 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id D9E2E8FC1B; Sun, 22 Nov 2009 22:10:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0617541C48B; Sun, 22 Nov 2009 23:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id kqELO7ol2cYG; Sun, 22 Nov 2009 23:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 5816141C751; Sun, 22 Nov 2009 23:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1F1D94448EC; Sun, 22 Nov 2009 22:05:48 +0000 (UTC) Date: Sun, 22 Nov 2009 22:05:48 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-stable@freebsd.org Message-ID: <20091122215953.L37440@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-security@freebsd.org Subject: HEADS UP: removal of PECOFF support in RELENG_[67] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 22:10:11 -0000 Hi, I'd like to give you a heads up that I intend to also remove PECOFF support from the stable/7 and stable/6 branches. PECOFF support is non-working and unmaintained in those FreeBSD releases and has lately still seen public security problems. PECOFF support is already gone in the upcoming 8.0 RELEASE or the 9-CURRENT development branch. Should no valid complaints come up saying that someone needs (and actively uses *cough* PECOFF support on FreeBSD it'll be removed earliest Novemeber 29th 2009 00:00 UTC (in about one week). /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 00:51:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EC94106566B; Mon, 23 Nov 2009 00:51:54 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 33ADA8FC15; Mon, 23 Nov 2009 00:51:53 +0000 (UTC) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id nAN0Usnk033383; Sun, 22 Nov 2009 19:30:54 -0500 (EST) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <4B09D7BE.20602@aldan.algebra.com> Date: Sun, 22 Nov 2009 19:30:54 -0500 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.22 (X11/20090711) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, openoffice@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: openoffice stuck in _umtx_op X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 00:51:54 -0000 Hello! I'm trying to start OOo, and it hangs at start-up -- after popping up its banner page. ktrace shows the following, slowly repeating, sequence of events: [...] 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fffffbfeef0) 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out 32726 soffice.bin CALL gettimeofday(0x7fffffbfef70,0) 32726 soffice.bin RET gettimeofday 0 32726 soffice.bin CALL clock_gettime(0,0x7fffffbfef00) 32726 soffice.bin RET clock_gettime 0 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fffffbfeef0) 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out 32726 soffice.bin CALL gettimeofday(0x7fffffbfef70,0) 32726 soffice.bin RET gettimeofday 0 32726 soffice.bin CALL clock_gettime(0,0x7fffffbfef00) 32726 soffice.bin RET clock_gettime 0 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fffffbfeef0) [...] what's happening? `ipcs -a' does not show anything extraordinary and there is nothing in syslog either... The machine is running 7.2-STABLE/amd64 (as of Oct 25). Any ideas? Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 02:09:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BC95106566C for ; Mon, 23 Nov 2009 02:09:03 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 084378FC0A for ; Mon, 23 Nov 2009 02:09:02 +0000 (UTC) Received: by ewy26 with SMTP id 26so1555218ewy.3 for ; Sun, 22 Nov 2009 18:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/3UIcme08+4jo3w/KGznM6wa6lIg58j/vCF8QRRdVpA=; b=Zbmw3BwSRGS+0Iqj6bSzf4ffeOg9RZd8/vP45U+FUzjwJh9hMoM/UWxlf42C/G6fMS kaWUDNhjcrFE7qEYuhYeKyMfcGddeQvBTE8bCbORfvLwG0rK7O20uA2RW7+5BsQhXVLB h3J+vTe0Na1sLW6AU/0iZtfryvIYGy/i03SW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lA7ycZQeTjTwbCUc7npOSCNIEAfYFCqBb8NzMK0hJKBu6bnPu2J+TZ0GYs1CqkVb0G o9pgQpoNG2gckAgSo93LyCpJWSyQkFzsqIIMClNvUWvwYAPDV5wezEufS5dtW32krcXg noZ9TkEhf5G9uPFRYBsW1EVQ1FlQEVWncJl9M= MIME-Version: 1.0 Received: by 10.216.87.67 with SMTP id x45mr1341188wee.18.1258942141938; Sun, 22 Nov 2009 18:09:01 -0800 (PST) In-Reply-To: <20091114024438.GA93630@icarus.home.lan> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> <20091114024438.GA93630@icarus.home.lan> Date: Sun, 22 Nov 2009 21:09:01 -0500 Message-ID: <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> From: Zaphod Beeblebrox To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.x hang-on-boot on Dell 1950 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 02:09:03 -0000 On Fri, Nov 13, 2009 at 9:44 PM, Jeremy Chadwick wrote: > > > This 1950 may predate that a bit, but I'm not sure how to nail it down > > exactly, other than by it's hardware components. Anyways, 7.0 does the > same > > thing --- still wedged. > > I haven't seen anyone recommend this as a test method yet -- disabling > fdc prior to the kernel booting via the loader prompt: > > - Press 6 at the menu, > - At the loader prompt, type: > > set hint.fdc.0.disabled="1" > boot -v (or without -v; your choice) > > You shouldn't need to set hint.fd.0.disabled="1", since fd0 would > normally bind to fdc0; disable the latter and you disable the lesser. > > The intention here is to rule out the device attachment failures from > fdc as the source of the deadlock. > Entertainingly, it does not. Aparently that hint doesn't stop the code from trying to attach fdc0 when acpi says so. I suppose I need to know the console command to disable acpi and fdc. but it still wedges at "device_attach: fdc0 attach returned 6" with the above. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 04:12:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 099F91065670; Mon, 23 Nov 2009 04:12:00 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (server70.appriver.com [69.20.119.203]) by mx1.freebsd.org (Postfix) with ESMTP id 82B7A8FC08; Mon, 23 Nov 2009 04:11:59 +0000 (UTC) X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note: TCH-CT/SI:0-30/SG:5 11/22/2009 11:12:00 PM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.675531 p=-0.900427 Source Normal X-Signature-Violations: 0-0-0-19685-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 107759545; Sun, 22 Nov 2009 23:12:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Nov 2009 19:59:10 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC USB/FS problem Thread-Index: AcprWqhOc0di4XCLQnutgxkzKDrTkwAg+g77 References: <200911221047.20362.hselasky@c2i.net> From: "Guojun Jin" To: "Hans Petter Selasky" , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bugs@freebsd.org, freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 04:12:00 -0000 >From more intensive diagnose, it looks like more related USB layer. repeated a few time on following process and ithe crash happened at = different USB access phase at each time. dd if=3D/dev/zero of=3D/dev/da0 count=3D1000 bs=3D4k sysinstall partition=20 slice 1 (da0s1) 18GB ID=3D12 slice 2 (da0s2) 10-15GB Id=3D165 slice 3 (da0s3) rest ID=3D165 W ---> OK label da0s3d 9GB /mnt da0s3e rest /dist W ---> da0s3e ---- device is not configured. w# ll /dev/da0* # after sysinstall did partition + W at 1st time crw-r----- 1 root operator 0, 97 Nov 22 11:23 /dev/da0 crw-r----- 1 root operator 0, 98 Nov 22 11:23 /dev/da0s1 crw-r----- 1 root operator 0, 99 Nov 22 11:23 /dev/da0s2 crw-r----- 1 root operator 0, 100 Nov 22 11:23 /dev/da0s3 # ll /dev/da0* # after sysinstall start at 2nd time crw-r----- 1 root operator 0, 97 Nov 22 11:27 /dev/da0 System crashed The crash log is available at = http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 (All logs are based on hw.usb.umass.debug=3D-1) After system reboot, and repeated above processes, the da0s3e was = mounted on /dist, but da0s3d cannot. It tunred out that newfs fail inside labeling process in sysinstall. = Manually did newfs on da0s3d, and it cannot be mounted on /mnt, but access to it caused crash. The crash log is available at = http:/www.daemonfun.com/archives/pub/USB/newfs Tried entire process again, this time, both partitons are formatted = (newfs) inside labaling process (sysinstall) but crahsed system during dump/restore on da0s3e (/dist). The crash log is available at = http:/www.daemonfun.com/archives/pub/USB/usb-log.crash2.bz2, which is = huge one. It contains two parts, one dump/restore IDE to da0s3d (passed), and the = rest is dump/restore to da0s3e (crashed). I am going to reinstall the system with the new ISO from Nov 21 = 8.0-RELEASE to see if anything will improve. -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Sun 11/22/2009 1:47 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem =20 On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: > Tried on the USB hard drive: > > Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. > Was happy because successfully did dump/restore on s3d, and thought it = just > partition format issue; but system crashed during dump/restore on s3e, = and > partition lost the file system type. > > wolf# mount /dev/da0s3e /mnt > WARNING: /mnt was not properly dismounted > /mnt: mount pending error: blocks 35968 files 0 > wolf# fsck da0s3e > fsck: Could not determine filesystem type > wolf# bsdlabel da0s3 > # /dev/da0s3: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 175735035 0 unused 0 0 # "raw" part, > don't edi t > d: 18874368 0 4.2BSD 0 0 0 > e: 156860667 18874368 4.2BSD 0 0 0 > > Therefore, tried directly use fsck_ufs on both USB hard drive and USB = stick > to get file system clean up. All data got back now. > > The machine has run with FreeBSD 6.1 all the way to 7.2 without such > problem. How can we determine what could go wrong in 8.0? FS or USB. Hi, Error 5 means IO error, so probably the transport layer, USB or lower, = is to=20 blame. Some things to check: 1) Make sure the connection for your memory stick is Ok. 2) Make sure there is enough power for your memory stick. Regarding memory sticks: Other operating systems do a port bus reset when the device has a = problem. On=20 FreeBSD we just try a software reset via the control endpoint. I guess = that it=20 is a device problem you are seeing. The USB stack in FreeBSD is faster = than=20 the old one, and maybe the faster queueing of mass storage requests = trigger=20 some hidden bugs in your device. When the problem happens try: sysctl hw.usb.umass.debug=3D-1 --HPS From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 04:16:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C79106566C for ; Mon, 23 Nov 2009 04:16:12 +0000 (UTC) (envelope-from seklecki@noc.cfi.pgh.pa.us) Received: from collaborativefusion.com (mx01.pub.collaborativefusion.com [206.210.89.201]) by mx1.freebsd.org (Postfix) with ESMTP id A7A738FC18 for ; Mon, 23 Nov 2009 04:16:11 +0000 (UTC) Received: from Internal Mail-Server by mx01 (envelope-from seklecki@noc.cfi.pgh.pa.us) with SMTP; 22 Nov 2009 22:48:48 -0500 From: Brian Seklecki To: Zaphod Beeblebrox In-Reply-To: <5f67a8c40911121356j608b41dct6ad7c1109b5d0438@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <6201873e0911121327x8b5a16k86c5018582785396@mail.gmail.com> <5f67a8c40911121355m5f115c93j7d1908336591fe31@mail.gmail.com> <5f67a8c40911121356j608b41dct6ad7c1109b5d0438@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Organization: Collaborative Fusion, Inc. Date: Sun, 22 Nov 2009 22:49:25 -0500 Message-Id: <1258948165.27241.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 (2.28.0-2.fc12) Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: FreeBSD 7.x hang-on-boot on Dell 1950 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 04:16:12 -0000 On Thu, 2009-11-12 at 16:56 -0500, Zaphod Beeblebrox wrote: > > I've now verified that 8.0-RC3 does the same thing, BTW. > > Anyways... no. There is no floppy option in the BIOS. It's not in Dell BIOS absolutely sucks. You get what you pay for. We have 25+ 9th gen systems. Revision 1, with the older HT Xeons, are all lemons. The only thing that runs stable on them in ESXi R3 of the 1950 with the PERC6 and DRAC5 works fine on 6.3/amd64, 7.2, etc. ~BAS > any of the sub-menus (which is how Dell's BIOS is organized). I'm > also not-so-sure that the floppy is where it's stopping because the > non-ACPI boot doesn't From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 04:47:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69174106566B for ; Mon, 23 Nov 2009 04:47:56 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id E999A8FC13 for ; Mon, 23 Nov 2009 04:47:55 +0000 (UTC) Received: by ewy26 with SMTP id 26so1624884ewy.3 for ; Sun, 22 Nov 2009 20:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5alUeX9PrHUgYLQnt8Eg0SPr4oOUi+QOS2YzYx31Aa8=; b=H7ZZhx+Cuoo6q4wPqzIZPX1k2v4o5tRoPV1u5YMKUUqKERZps9FCjXdt5dSnjpasZC q/ktzwkaiz45KeGOWdPwXpICiiJdI1l6skrY7xkgMEOn96V4hdGfFg9+F2MZkmTvl3xk 1B1tn8q3Ktf4JdPzvbUVKAoieQ670pZwBrm/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dAaeO2YEo4xeYd9w41v2v4WW093Zz1npgUj6PMaH26StALIdEGt75h43VobWCHWKYc Ne36DEBeXKmfaD9VayrAZH/3fj1sDZWrbUBo3aVNhGQ2yyC6NRUK67qr1/mtR3ZcM4F7 gwnt58NOQx5dqMYpA4imGoTn0EngcnDnjsB6o= MIME-Version: 1.0 Received: by 10.216.86.135 with SMTP id w7mr1367199wee.176.1258951674948; Sun, 22 Nov 2009 20:47:54 -0800 (PST) In-Reply-To: <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> <20091114024438.GA93630@icarus.home.lan> <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> Date: Sun, 22 Nov 2009 23:47:54 -0500 Message-ID: <5f67a8c40911222047m78ac7378i8a2016449d0d2996@mail.gmail.com> From: Zaphod Beeblebrox To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.x hang-on-boot on Dell 1950 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 04:47:56 -0000 On Sun, Nov 22, 2009 at 9:09 PM, Zaphod Beeblebrox wrote: > > > On Fri, Nov 13, 2009 at 9:44 PM, Jeremy Chadwick > wrote: > >> >> > This 1950 may predate that a bit, but I'm not sure how to nail it down >> > exactly, other than by it's hardware components. Anyways, 7.0 does the >> same >> > thing --- still wedged. >> >> I haven't seen anyone recommend this as a test method yet -- disabling >> fdc prior to the kernel booting via the loader prompt: >> >> - Press 6 at the menu, >> - At the loader prompt, type: >> >> set hint.fdc.0.disabled="1" >> boot -v (or without -v; your choice) >> >> You shouldn't need to set hint.fd.0.disabled="1", since fd0 would >> normally bind to fdc0; disable the latter and you disable the lesser. >> >> The intention here is to rule out the device attachment failures from >> fdc as the source of the deadlock. >> > > Entertainingly, it does not. Aparently that hint doesn't stop the code > from trying to attach fdc0 when acpi says so. I suppose I need to know the > console command to disable acpi and fdc. > > but it still wedges at "device_attach: fdc0 attach returned 6" with the > above. > > OK. With both floppy and acpi disabled, it dies calling "start_init" several times, the last being /stand/sysinstal (which should work). I don't see it "starting" the other CPUs. It hangs hard... no keyboard working (ie: no caps lock). From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 08:41:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AEF9106566C for ; Mon, 23 Nov 2009 08:41:46 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop2.sarenet.es (proxypop2.sarenet.es [194.30.0.95]) by mx1.freebsd.org (Postfix) with ESMTP id 065D78FC15 for ; Mon, 23 Nov 2009 08:41:45 +0000 (UTC) Received: from [172.16.1.204] (izaro.sarenet.es [192.148.167.11]) by proxypop2.sarenet.es (Postfix) with ESMTP id 1A45173946; Mon, 23 Nov 2009 09:41:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: Date: Mon, 23 Nov 2009 09:41:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75706651-E9D4-4C40-B39C-6B8B0023DFF7@sarenet.es> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> To: Randy Bush X-Mailer: Apple Mail (2.1077) Cc: Johan Hendriks , freebsd-stable@freebsd.org Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:41:46 -0000 On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: >=20 >> Try running FreeBSD 7-Stable to get the latest ZFS version which on >> FreeBSD is 13 >=20 > that is what i am running. RELENG_7 I've been following ZFS on FreeBSD long ago, and it really seems to be = stable on 8.0/amd64. Even Sun Microsystems say that ZFS is better used on a 64 bit system, = they don't recommend it on the 32 bit version of Solaris. That said, there's still an outstanding bug, I managed to deadlock it = but the condition is easy to avoid. Borja. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 09:01:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50087106566B for ; Mon, 23 Nov 2009 09:01:25 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id ED0A58FC13 for ; Mon, 23 Nov 2009 09:01:23 +0000 (UTC) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA13.westchester.pa.mail.comcast.net with comcast id 8Z1P1d0020Fqzac5DZ1PZE; Mon, 23 Nov 2009 09:01:23 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 8Z1N1d0083S48mS3UZ1NGE; Mon, 23 Nov 2009 09:01:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E8A8B1E3035; Mon, 23 Nov 2009 01:01:21 -0800 (PST) Date: Mon, 23 Nov 2009 01:01:21 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091123090121.GA59823@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <75706651-E9D4-4C40-B39C-6B8B0023DFF7@sarenet.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75706651-E9D4-4C40-B39C-6B8B0023DFF7@sarenet.es> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 09:01:25 -0000 On Mon, Nov 23, 2009 at 09:41:43AM +0100, Borja Marcos wrote: > On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: > > > >> Try running FreeBSD 7-Stable to get the latest ZFS version which on > >> FreeBSD is 13 > > > > that is what i am running. RELENG_7 > > I've been following ZFS on FreeBSD long ago, and it really seems to be stable on 8.0/amd64. > Even Sun Microsystems say that ZFS is better used on a 64 bit system, they don't recommend it > on the 32 bit version of Solaris. > > That said, there's still an outstanding bug, I managed to deadlock it but the condition is easy to avoid. Please provide details of this deadlock (PR, kernel output, scenario details, etc.), and details of how to avoid it. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 09:47:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85364106566B for ; Mon, 23 Nov 2009 09:47:20 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD388FC15 for ; Mon, 23 Nov 2009 09:47:19 +0000 (UTC) Received: from [172.16.1.204] (izaro.sarenet.es [192.148.167.11]) by proxypop1.sarenet.es (Postfix) with ESMTP id 746C9639A; Mon, 23 Nov 2009 10:47:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20091123090121.GA59823@icarus.home.lan> Date: Mon, 23 Nov 2009 10:47:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <75706651-E9D4-4C40-B39C-6B8B0023DFF7@sarenet.es> <20091123090121.GA59823@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 09:47:20 -0000 On Nov 23, 2009, at 10:01 AM, Jeremy Chadwick wrote: > On Mon, Nov 23, 2009 at 09:41:43AM +0100, Borja Marcos wrote: >> On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: >>>=20 >>>> Try running FreeBSD 7-Stable to get the latest ZFS version which on >>>> FreeBSD is 13 >>>=20 >>> that is what i am running. RELENG_7 >>=20 >> I've been following ZFS on FreeBSD long ago, and it really seems to = be stable on 8.0/amd64. >> Even Sun Microsystems say that ZFS is better used on a 64 bit system, = they don't recommend it >> on the 32 bit version of Solaris. >>=20 >> That said, there's still an outstanding bug, I managed to deadlock it = but the condition is easy to avoid. >=20 > Please provide details of this deadlock (PR, kernel output, scenario > details, etc.), and details of how to avoid it. Of course, it's been discussed on freebsd-fs, that's why I didn's = cross-post. I'm making a heavy usage of zfs send/receive to keep a replica of a = dataset. ZFS can deadlock if you are doing a zfs send and zfs receive = (I'm using incremental snapshots) and at the same time you have reading = activity on the destination dataset. Imagine this: Machine 1 is the origin, machine 2 is the destination: machine 1: zfs send -i pool/dataset@first pool/dataset@second | ssh = machine2 zfs receive -d pool And while this is running, I have some activity going on with = pool/dataset. Easy to replicate if pool/dataset contains /usr/obj and = you are doing a make buildworld on the first machine, doing frequent = replicas (30 second intervals) while on the second machine you keep a = job reading it, I did the tests with a tar process copying the /usr/obj = tree to another location. However, if you can ensure that the destination dataset is not read = while the zfs receive is working, there is no problem at all, zfs send = -i/zfs receives work like a charm, even at 30 second intervals. Borja. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 11:25:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2253106566B for ; Mon, 23 Nov 2009 11:25:25 +0000 (UTC) (envelope-from freebsd-stable=freebsd.org+1258957525+15088_399+200911@md1n.mailserve.net) Received: from mdreg1.mailserve.net (mdreg1.mailserve.net [64.151.77.216]) by mx1.freebsd.org (Postfix) with ESMTP id A852D8FC13 for ; Mon, 23 Nov 2009 11:25:25 +0000 (UTC) Received: from mdreg2.mailserve.net (mdreg2.mailserve.net [64.151.77.217]) by mdreg1.mailserve.net (Postfix) with ESMTP id 8027031E036 for ; Mon, 23 Nov 2009 16:24:43 +0530 (IST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by mdreg2.mailserve.net (Postfix) with ESMTP id 6B517398043 for ; Mon, 23 Nov 2009 16:24:43 +0530 (IST) From: "Rupesh Agrawal " To: freebsd-stable@freebsd.org X-Mailer: MailDirect v2.03 for [Verve Communications Pvt Ltd] http://maildirect.co.in/: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_1778b47fda4b1d169cead83eb0f23453" Message-Id: <20091123105443.6B517398043@mdreg2.mailserve.net> Date: Mon, 23 Nov 2009 16:24:43 +0530 (IST) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Christmas Administrators - Recruitment Support Services X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "rupesh.agrawal@verveos2i.com" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 11:25:25 -0000 --b1_1778b47fda4b1d169cead83eb0f23453 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: quoted-printable =C2=A0 Most of our recruitment clients recognise Christmas time as being the = ideal opportunity to undertake an annual clean up of their databases to = have their back offices ship shape for the New Year. =C2=A0 =C2=A345.00 per day =C2=A0 This is the cost of a FULL-TIME administrator This is the cost of a FULL-TIME administrator working 8 hrs per day This is the cost of a FULL-TIME administrator working 8 hrs per day with = only you as a client =C2=A0 =C2=A0 Verveoffshore Recruitment Process Outsourcing =C2=A0 We offer flexible solutions to fit around your business =C2=A0 =C2=A0 =C2=A0 Kind Regards, =C2=A0 Rupesh Agrawal | Manager - Client Services =C2=A0 VerveOS2i=C2=A0=C2=A0 |=C2=A0 India=C2=A0 |=C2=A0 Phone:+91 = 20-41056789=C2=A0Ext. 6712 |=C2=A0 E-mail: rupesh.agrawal@verveos2i.com = |=C2=A0 Website: www.verveos2i.com =C2=A0 CONFIDENTIALITY & DISCLAIMER: This E-mail from VerveOS2i =C2=A0is = confidential. It may also be legally privileged. If you are not the = intended receiver, you may not copy, reproduce, forward, disclose, = disseminate or use any part of it. If you have received this message by = slip, delete it and all copies from your system and notify the sender = immediately by return E-mail. We do not guarantee the security of Internet = communications and are not liable for any errors or omissions.=20 =C2=A0 We are a responsible email marketing team and comply with necessary = regulations. Most often we buy email lists from opt-in repositories and = carry our necessary checks. If this email has come to you by error or if = you need us to remove your ID from our emailing list, please reply to this = email with "REMOVE" on the subject line. --b1_1778b47fda4b1d169cead83eb0f23453-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 15:09:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45544106566B; Mon, 23 Nov 2009 15:09:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id CA4658FC0C; Mon, 23 Nov 2009 15:09:00 +0000 (UTC) Received: from ydesk.samsco.home (ydesk.samsco.home [192.168.254.15]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id nANF8uS3014285; Mon, 23 Nov 2009 08:08:56 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: Date: Mon, 23 Nov 2009 08:08:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6B4DCB23-179D-4163-923F-24FC66303086@samsco.org> References: <200910150853.49850.jhb@freebsd.org> To: pluknet X-Mailer: Apple Mail (2.1076) X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi , freebsd-stable@freebsd.org, John Baldwin Subject: Re: mfi(4) endless loop kernel output on attach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 15:09:01 -0000 Did you ever get a resolution for this? The 6.x bugs definitely need to be fixed. The reported timeouts on 7.x might be due to the adapter taking a log time to do the command. Scott On Oct 22, 2009, at 8:30 AM, pluknet wrote: > 2009/10/15 John Baldwin : >> On Thursday 15 October 2009 5:51:19 am pluknet wrote: >>> Hi. >>> >>> This is 7.2-R. Seen on IBM x3650M2. >>> >>> During the boot I get those endless looping kernel messages while on >>> mfi(4) attach phase. >>> It's getting more odd since 7.2 booted and worked fine on exactly >>> this >>> server model >>> months ago (on different box though).. Any hints? >> >> We just had some boxes die like this (but spewing a different loop >> of messages >> on boot related to continuously scheduling patrol reads and >> consistency >> checks that finished immediately) at work. We fixed them by >> swapping out the >> controller. We might try stick them in a different box and >> reflashing them >> using mfiutil(8) to see if it's some sort of corrupted state that >> flashing >> the adapter fixes. >> >> In your case it looks lik the firmware keeps crashing and restarting. >> > > Some more thoughts.. > > There was a problem I got with 'MegaCli -AdpBbuCmd -BbuLearn -aall' > command. > On 6.2-R process slept on mfiwait wchan: > > db> bt 14734 > Tracing pid 14734 tid 100135 td 0xc93f8190 > sched_switch(c93f8190,0,1) at sched_switch+0x143 > mi_switch(1,0,c93f8190,f9a32acc,c06a43a4,...) at mi_switch+0x1ba > sleepq_switch(c8c6b0d0) at sleepq_switch+0x87 > sleepq_wait(c8c6b0d0,0,c93f8190,c8c6b0d0,c8c25800,...) at sleepq_wait > +0x5c > msleep(c8c6b0d0,c8c25954,4c,c090acbc,0) at msleep+0x269 > mfi_wait_command(c8c25800,c8c6b0d0,0,0,cc382460,...) at > mfi_wait_command+0xa8 > mfi_ioctl(c8c31300,c1144d01,cc870a00,1,c93f8190,...) at mfi_ioctl > +0x485 > devfs_ioctl_f(c90a2750,c1144d01,cc870a00,c9048000,c93f8190) at > devfs_ioctl_f+0xaf > ioctl(c93f8190,f9a32d04) at ioctl+0x445 > syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = > 0xbfbfe88c, ebp = 0xbfbfe8b8 --- > > Then: > mfi0: COMMAND 0xc8c6b0d0 TIMEOUT AFTER 51 SECONDS > mfi0: COMMAND 0xc8c61d50 TIMEOUT AFTER 49 SECONDS > mfi0: COMMAND 0xc8c61850 TIMEOUT AFTER 49 SECONDS > > > On 6.4-R MegaCli throws a page fault due to NULL deref > in mfi_data_cb():cm->cm_sg (see below). > > There was past 6.4 backport mentioning > "fix some bugs in the API for the management ioctl." > With this patch I have no longer panic and/or locks. > > Thanks to LSI now on 7.2-R (and on patched 6.4-R) it returns an error: > # ./MegaCli -AdpBbuCmd -BbuLearn -aall > > Adapter 0: BBU Learn Failed > > Exit Code: 0x32 > > > db> bt > Tracing pid 43059 tid 101363 td 0xcf46e680 > mfi_data_cb(c9cfae00,c9cc3e00,1,0) at mfi_data_cb+0x5e > bus_dmamap_load(c9cd7c80,0,caf86270,0,c0597240,c9cfae00,0) at > bus_dmamap_load+0x4a1 > mfi_mapcmd(c9cc3800,c9cfae00) at mfi_mapcmd+0x31 > mfi_startio(c9cc3800) at mfi_startio+0x9b > mfi_wait_command(c9cc3800,c9cfae00,0,0,caf86270,...) at > mfi_wait_command+0x89 > mfi_ioctl(c9cf7200,c1144d01,d3fb6200,1,cf46e680,...) at mfi_ioctl > +0x52a > devfs_ioctl_f(d1a551b0,c1144d01,d3fb6200,cbf52c80,cf46e680) at > devfs_ioctl_f+0xaf > ioctl(cf46e680,fbd91d04) at ioctl+0x445 > syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = > 0xbfbfe88c, ebp = 0xbfbfe8b8 > > #9 0xc08cbb1a in calltrap () at /usr/src/sys/i386/i386/exception.s: > 139 > #10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00, > nsegs=1, > ---Type to continue, or q to quit--- > error=0) at /usr/src/sys/dev/mfi/mfi.c:1488 > #11 0xc08c7afd in bus_dmamap_load (dmat=0xc8a6f100, map=0xac89e000, > buf=0xc8a5ac60, buflen=0, callback=0xc0597240 , > callback_arg=0xc8a744b0, flags=0) > at /usr/src/sys/i386/i386/busdma_machdep.c:733 > #12 0xc059721d in mfi_mapcmd (sc=0xc8a49800, cm=0xc8a49e00) > at /usr/src/sys/dev/mfi/mfi.c:1452 > #13 0xc0597177 in mfi_startio (sc=0xc8a49800) > at /usr/src/sys/dev/mfi/mfi.c:1436 > #14 0xc0595f09 in mfi_wait_command (sc=0xc8a49800, cm=0xc8a744b0) > at /usr/src/sys/dev/mfi/mfi.c:822 > #15 0xc059840a in mfi_ioctl (dev=0xac89e000, cmd=0, arg=0xc8de8800 > "", flag=1, > td=0xc8a5ac60) at /usr/src/sys/dev/mfi/mfi.c:2061 > #16 0xc06598b7 in devfs_ioctl_f (fp=0xc902dc18, com=3239333121, > data=0xc8de8800, cred=0xc9052980, td=0xc8e2dd00) > at /usr/src/sys/fs/devfs/devfs_vnops.c:480 > #17 0xc06d3a11 in ioctl (td=0xc8e2dd00, uap=0xeb37bd04) at file.h:265 > > (kgdb) f 10 > #10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00, > nsegs=1, > error=0) at /usr/src/sys/dev/mfi/mfi.c:1488 > 1488 sgl->sg32[i].addr = segs[i].ds_addr; > (kgdb) list > 1483 return; > 1484 } > 1485 > 1486 if ((sc->mfi_flags & MFI_FLAGS_SG64) == 0) { > 1487 for (i = 0; i < nsegs; i++) { > 1488 sgl->sg32[i].addr = segs[i].ds_addr; > 1489 sgl->sg32[i].len = segs[i].ds_len; > 1490 } > 1491 } else { > 1492 for (i = 0; i < nsegs; i++) { > (kgdb) p i > $1 = 0 > (kgdb) p *segs > $3 = {ds_addr = 2457600, ds_len = 65536} > (kgdb) p sgl > $4 = (union mfi_sgl *) 0x0 > (kgdb) p *cm > $6 = {cm_link = {tqe_next = 0x0, tqe_prev = 0xc8a49814}, > cm_timestamp = 0, > cm_sc = 0xc8a49800, cm_frame = 0xe8fee680, cm_frame_busaddr = > 3748513408, > cm_sense = 0xe904c780, cm_sense_busaddr = 3749103488, cm_dmamap = > 0x0, > cm_sg = 0x0, cm_data = 0xc8a5ac60, cm_len = 0, cm_total_frame_size > = 0, > cm_extra_frames = 0, cm_flags = 6, cm_aen_abort = 0, cm_complete = 0, > cm_private = 0x0, cm_index = 15, cm_error = 0} > > > -- > wbr, > pluknet > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 15:27:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A3DD1065694; Mon, 23 Nov 2009 15:27:00 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f220.google.com (mail-bw0-f220.google.com [209.85.218.220]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3718FC08; Mon, 23 Nov 2009 15:26:59 +0000 (UTC) Received: by bwz20 with SMTP id 20so4040872bwz.14 for ; Mon, 23 Nov 2009 07:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NnmkRq+Ypjb37eZ29UXAixdSssytkqc4ScuPXwhryq8=; b=eY35PnH8EglwaEGjodi9f+kCY7sAqVcbTLG97vT70Iy0qlgcmA62bjjMB6kzQDH72T WJqZn/BHzEfRO3UThPwLS806cIwBsdnYx05cY5FdcN8+Q5ecQgD/z/mifOsMi/GC3GOc os11IAURsX90GaQgCoprVr1FLALHCaWf9N6C0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G+Cs3CvXAFFDoANSyY4epG+Sqg/rw47ELHGM5k2H5+smY3F+s8PnprX0aG/SnH2iUt Giauo8Tz/8mNbh66LfKIpMmxatBiEWGka+vCRLpRLVVc/v9ixfcc/I8bQSbX7cOlrell e0gbwg0kQY38GOZxePMFQ4s7BymC85QCPz2O4= MIME-Version: 1.0 Received: by 10.204.7.88 with SMTP id c24mr4887647bkc.17.1258990018421; Mon, 23 Nov 2009 07:26:58 -0800 (PST) In-Reply-To: <6B4DCB23-179D-4163-923F-24FC66303086@samsco.org> References: <200910150853.49850.jhb@freebsd.org> <6B4DCB23-179D-4163-923F-24FC66303086@samsco.org> Date: Mon, 23 Nov 2009 18:26:57 +0300 Message-ID: From: pluknet To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi , freebsd-stable@freebsd.org, John Baldwin Subject: Re: mfi(4) endless loop kernel output on attach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 15:27:00 -0000 2009/11/23 Scott Long : > Did you ever get a resolution for this? =A0The 6.x bugs definitely need t= o be > fixed. =A0The reported timeouts on 7.x might be due to the adapter taking= a > log time to do the command. > > Scott An "endless loop kernel output" on boot always solved with clearing logs with MegaCli -AdpEventLog -GetEventLogInfo -aAll. As for BBULearn issue, I just tested it again on one of my boxes: # ./MegaCli -AdpBbuCmd -BbuLearn -aall Adapter 0: BBU Learn Succeeded. Exit Code: 0x00 So it seems to work. I see no problems. mfi0: 3748 (312279437s/0x0008/info) - Battery relearn started mfi0: 3749 (312279437s/0x0008/WARN) - BBU disabled; changing WB virtual disks to WT mfi0: 3750 (312279437s/0x0001/info) - Policy change on VD 00/0 to [ID=3D00,dcp=3D6d,ccp=3D6c,ap=3D0,dc=3D0,dbgi=3D0] from [ID=3D00,dcp=3D6d,ccp=3D6d,ap=3D0,dc=3D0,dbgi=3D0] mfi0: 3751 (312279442s/0x0008/info) - Battery is discharging mfi0: 3752 (312279442s/0x0008/info) - Battery relearn in progress > > On Oct 22, 2009, at 8:30 AM, pluknet wrote: > >> 2009/10/15 John Baldwin : >>> >>> On Thursday 15 October 2009 5:51:19 am pluknet wrote: >>>> >>>> Hi. >>>> >>>> This is 7.2-R. Seen on IBM x3650M2. >>>> >>>> During the boot I get those endless looping kernel messages while on >>>> mfi(4) attach phase. >>>> It's getting more odd since 7.2 booted and worked fine on exactly this >>>> server model >>>> months ago (on different box though).. Any hints? >>> >>> We just had some boxes die like this (but spewing a different loop of >>> messages >>> on boot related to continuously scheduling patrol reads and consistency >>> checks that finished immediately) at work. =A0We fixed them by swapping= out >>> the >>> controller. =A0We might try stick them in a different box and reflashin= g >>> them >>> using mfiutil(8) to see if it's some sort of corrupted state that >>> flashing >>> the adapter fixes. >>> >>> In your case it looks lik the firmware keeps crashing and restarting. >>> >> >> Some more thoughts.. >> >> There was a problem I got with 'MegaCli -AdpBbuCmd -BbuLearn -aall' >> command. >> On 6.2-R process slept on mfiwait wchan: >> >> db> bt 14734 >> Tracing pid 14734 tid 100135 td 0xc93f8190 >> sched_switch(c93f8190,0,1) at sched_switch+0x143 >> mi_switch(1,0,c93f8190,f9a32acc,c06a43a4,...) at mi_switch+0x1ba >> sleepq_switch(c8c6b0d0) at sleepq_switch+0x87 >> sleepq_wait(c8c6b0d0,0,c93f8190,c8c6b0d0,c8c25800,...) at sleepq_wait+0x= 5c >> msleep(c8c6b0d0,c8c25954,4c,c090acbc,0) at msleep+0x269 >> mfi_wait_command(c8c25800,c8c6b0d0,0,0,cc382460,...) at >> mfi_wait_command+0xa8 >> mfi_ioctl(c8c31300,c1144d01,cc870a00,1,c93f8190,...) at mfi_ioctl+0x485 >> devfs_ioctl_f(c90a2750,c1144d01,cc870a00,c9048000,c93f8190) at >> devfs_ioctl_f+0xaf >> ioctl(c93f8190,f9a32d04) at ioctl+0x445 >> syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x8177207, esp =3D >> 0xbfbfe88c, ebp =3D 0xbfbfe8b8 --- >> >> Then: >> mfi0: COMMAND 0xc8c6b0d0 TIMEOUT AFTER 51 SECONDS >> mfi0: COMMAND 0xc8c61d50 TIMEOUT AFTER 49 SECONDS >> mfi0: COMMAND 0xc8c61850 TIMEOUT AFTER 49 SECONDS >> >> >> On 6.4-R MegaCli throws a page fault due to NULL deref >> in mfi_data_cb():cm->cm_sg (see below). >> >> There was past 6.4 backport mentioning >> "fix some bugs in the API for the management ioctl." >> With this patch I have no longer panic and/or locks. >> >> Thanks to LSI now on 7.2-R (and on patched 6.4-R) it returns an error: >> # ./MegaCli -AdpBbuCmd -BbuLearn -aall >> >> Adapter 0: BBU Learn Failed >> >> Exit Code: 0x32 >> >> >> db> bt >> Tracing pid 43059 tid 101363 td 0xcf46e680 >> mfi_data_cb(c9cfae00,c9cc3e00,1,0) at mfi_data_cb+0x5e >> bus_dmamap_load(c9cd7c80,0,caf86270,0,c0597240,c9cfae00,0) at >> bus_dmamap_load+0x4a1 >> mfi_mapcmd(c9cc3800,c9cfae00) at mfi_mapcmd+0x31 >> mfi_startio(c9cc3800) at mfi_startio+0x9b >> mfi_wait_command(c9cc3800,c9cfae00,0,0,caf86270,...) at >> mfi_wait_command+0x89 >> mfi_ioctl(c9cf7200,c1144d01,d3fb6200,1,cf46e680,...) at mfi_ioctl+0x52a >> devfs_ioctl_f(d1a551b0,c1144d01,d3fb6200,cbf52c80,cf46e680) at >> devfs_ioctl_f+0xaf >> ioctl(cf46e680,fbd91d04) at ioctl+0x445 >> syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x8177207, esp =3D >> 0xbfbfe88c, ebp =3D 0xbfbfe8b8 >> >> #9 =A00xc08cbb1a in calltrap () at /usr/src/sys/i386/i386/exception.s:13= 9 >> #10 0xc059729e in mfi_data_cb (arg=3D0xc8a744b0, segs=3D0xc8a49e00, nseg= s=3D1, >> ---Type to continue, or q to quit--- >> =A0 error=3D0) at /usr/src/sys/dev/mfi/mfi.c:1488 >> #11 0xc08c7afd in bus_dmamap_load (dmat=3D0xc8a6f100, map=3D0xac89e000, >> =A0 buf=3D0xc8a5ac60, buflen=3D0, callback=3D0xc0597240 , >> =A0 callback_arg=3D0xc8a744b0, flags=3D0) >> =A0 at /usr/src/sys/i386/i386/busdma_machdep.c:733 >> #12 0xc059721d in mfi_mapcmd (sc=3D0xc8a49800, cm=3D0xc8a49e00) >> =A0 at /usr/src/sys/dev/mfi/mfi.c:1452 >> #13 0xc0597177 in mfi_startio (sc=3D0xc8a49800) >> =A0 at /usr/src/sys/dev/mfi/mfi.c:1436 >> #14 0xc0595f09 in mfi_wait_command (sc=3D0xc8a49800, cm=3D0xc8a744b0) >> =A0 at /usr/src/sys/dev/mfi/mfi.c:822 >> #15 0xc059840a in mfi_ioctl (dev=3D0xac89e000, cmd=3D0, arg=3D0xc8de8800= "", >> flag=3D1, >> =A0 td=3D0xc8a5ac60) at /usr/src/sys/dev/mfi/mfi.c:2061 >> #16 0xc06598b7 in devfs_ioctl_f (fp=3D0xc902dc18, com=3D3239333121, >> =A0 data=3D0xc8de8800, cred=3D0xc9052980, td=3D0xc8e2dd00) >> =A0 at /usr/src/sys/fs/devfs/devfs_vnops.c:480 >> #17 0xc06d3a11 in ioctl (td=3D0xc8e2dd00, uap=3D0xeb37bd04) at file.h:26= 5 >> >> (kgdb) f 10 >> #10 0xc059729e in mfi_data_cb (arg=3D0xc8a744b0, segs=3D0xc8a49e00, nseg= s=3D1, >> =A0 error=3D0) at /usr/src/sys/dev/mfi/mfi.c:1488 >> 1488 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sgl->sg32[i]= .addr =3D segs[i].ds_addr; >> (kgdb) list >> 1483 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; >> 1484 =A0 =A0 =A0 =A0 =A0 =A0} >> 1485 >> 1486 =A0 =A0 =A0 =A0 =A0 =A0if ((sc->mfi_flags & MFI_FLAGS_SG64) =3D=3D = 0) { >> 1487 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < nsegs; i++= ) { >> 1488 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sgl->sg32[i]= .addr =3D segs[i].ds_addr; >> 1489 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sgl->sg32[i]= .len =3D segs[i].ds_len; >> 1490 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> 1491 =A0 =A0 =A0 =A0 =A0 =A0} else { >> 1492 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < nsegs; i++= ) { >> (kgdb) p i >> $1 =3D 0 >> (kgdb) p *segs >> $3 =3D {ds_addr =3D 2457600, ds_len =3D 65536} >> (kgdb) p sgl >> $4 =3D (union mfi_sgl *) 0x0 >> (kgdb) p *cm >> $6 =3D {cm_link =3D {tqe_next =3D 0x0, tqe_prev =3D 0xc8a49814}, cm_time= stamp =3D 0, >> =A0cm_sc =3D 0xc8a49800, cm_frame =3D 0xe8fee680, cm_frame_busaddr =3D 3= 748513408, >> =A0cm_sense =3D 0xe904c780, cm_sense_busaddr =3D 3749103488, cm_dmamap = =3D 0x0, >> =A0cm_sg =3D 0x0, cm_data =3D 0xc8a5ac60, cm_len =3D 0, cm_total_frame_s= ize =3D 0, >> =A0cm_extra_frames =3D 0, cm_flags =3D 6, cm_aen_abort =3D 0, cm_complet= e =3D 0, >> =A0cm_private =3D 0x0, cm_index =3D 15, cm_error =3D 0} >> >> >> -- >> wbr, >> pluknet >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 16:11:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D94A106566B for ; Mon, 23 Nov 2009 16:11:00 +0000 (UTC) (envelope-from matt@madhaus.cns.utoronto.ca) Received: from madhaus.cns.utoronto.ca (madhaus.cns.utoronto.ca [128.100.103.10]) by mx1.freebsd.org (Postfix) with SMTP id B46398FC13 for ; Mon, 23 Nov 2009 16:10:57 +0000 (UTC) Received: (qmail 30218 invoked from network); 23 Nov 2009 16:10:56 -0000 Received: from sparchaus.cns.utoronto.ca (HELO ?128.100.103.14?) (128.100.103.14) by madhaus.cns.utoronto.ca with SMTP; 23 Nov 2009 16:10:56 -0000 Message-ID: <4B0AB408.1010500@madhaus.cns.utoronto.ca> Date: Mon, 23 Nov 2009 11:10:48 -0500 From: Matt Wilks Organization: University of Toronto, CNS User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: freebsd-stable@freebsd.org References: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> <4B06E274.3090207@madhaus.cns.utoronto.ca> <20091120194613.GA81572@icarus.home.lan> In-Reply-To: <20091120194613.GA81572@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: NSIS compile failed on FreeBSD 7.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 16:11:00 -0000 > If that's indeed the case, then the port Makefile needs to be modified > to reject building on any architectures other than i386. This should > suffice: > > ONLY_FOR_ARCHS= i386 > > If you could file a PR on this matter, the FreeBSD Project folks would > likely appreciate it. :-) There isn't actually a FreeBSD port for this project. I was compiling source obtained from the NSIS sourceforge page. -- Matt Wilks Colossians 2:6-7 University of Toronto Information Security, I+TS (416) 978-3328 matt@madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 21:28:23 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E07F4106566B for ; Mon, 23 Nov 2009 21:28:23 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 90F148FC08 for ; Mon, 23 Nov 2009 21:28:23 +0000 (UTC) Received: (qmail 31273 invoked by uid 0); 23 Nov 2009 21:28:22 -0000 Received: from unknown (HELO office-dhcp-20.bway.net) (spork@216.220.107.20) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Nov 2009 21:28:22 -0000 Date: Mon, 23 Nov 2009 16:28:21 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: stable@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: panic in 7.2 (ffs_alloc.c?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:28:24 -0000 Just a follow-up... The machine was waiting for a manual fsck - this crash seemed to scramble things up pretty good, it hit the jail partition hard and seemed to touch others that were quiet at the time. I'm re-running mstone with an even heavier load to see if I can reproduce this again. Full verbose dmesg: http://pastie.org/711839 Should I bother with a PR or anything on this? Doesn't look like a hardware issue to me. It seems like there could be a nasty bug waiting in the UFS2 code somewhere, does anyone want to persue this at all? I have the dump available for anyone that wants it. Thanks, Charles On Sun, 22 Nov 2009, Charles Sprickman wrote: > Howdy, > > I'm not expert at getting info out of a dump, but I'll do my best to provide > some information. > > This is a Dell PE2970 w/PERC6/i RAID running FreeBSD 7.2/amd64. Brand new > box, has been doing very light work for about two weeks. Last night I > started a very long mstone run on a jailed mail server and found that quite a > way into this burn-in, the box paniced. I was going to put it in service > Monday (after punishing it all weekend). Looking for some input on what the > root cause is and whether going to a -stable snapshot might be worthwhile. > > I can tell you there was a good deal of disk activity at the time in the jail > - mstone was simulating 100 POP and SMTP clients hitting the machine at once. > This is qmail+courier. So messages are coming in, hitting the queue, hitting > a user's maildir, getting read and deleted via the POP "client" over and over > again. I do see lots of "ffs_*" stuff in the backtrace, which is a little > scary. > > Here's my stab at a kgdb session (also @ pastie for easier reading: > http://pastie.org/709671): > > [root@bigmail /usr/obj/usr/src/sys/BWAY7-64]# kgdb kernel.debug > /var/crash/vmcore.0 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x12d4b9f5c > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff8050382e > stack pointer = 0x10:0xffffffff281a75b0 > frame pointer = 0x10:0xffffff000455f800 > 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 = 6324 (vdelivermail) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 12d0h32m3s > Physical memory: 6130 MB > Dumping 725 MB: 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 > 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 > 166 150 134 118 102 86 70 54 38 22 6 > > Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from > /boot/kernel/nullfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/nullfs.ko > Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from > /boot/kernel/fdescfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/fdescfs.ko > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > #3 0xffffffff8034cba2 in panic (fmt=0x104
) > at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff80574823 in trap_fatal (frame=0xffffff00046c8000, eva=Variable > "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:757 > #5 0xffffffff80574bf5 in trap_pfault (frame=0xffffffff281a7500, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:673 > #6 0xffffffff80575534 in trap (frame=0xffffffff281a7500) > at /usr/src/sys/amd64/amd64/trap.c:444 > #7 0xffffffff8055969e in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:209 > #8 0xffffffff8050382e in ffs_realloccg (ip=0xffffff00267f75c0, lbprev=0, > bprev=6288224785898156086, bpref=593305256, osize=0, nsize=2048, > flags=33619968, cred=0xffffff00927fe800, bpp=0xffffffff281a7800) > at /usr/src/sys/ufs/ffs/ffs_alloc.c:1349 > #9 0xffffffff80506e8e in ffs_balloc_ufs2 (vp=0xffffff0027a64dc8, > startoffset=Variable "startoffset" is not available. > ) > at /usr/src/sys/ufs/ffs/ffs_balloc.c:692 > #10 0xffffffff805223e5 in ffs_write (ap=0xffffffff281a7a10) > at /usr/src/sys/ufs/ffs/ffs_vnops.c:724 > #11 0xffffffff805a0645 in VOP_WRITE_APV (vop=0xffffffff80793d20, > a=0xffffffff281a7a10) at vnode_if.c:691 > #12 0xffffffff803dd731 in vn_write (fp=0xffffff001027cd00, > uio=0xffffffff281a7b00, active_cred=Variable "active_cred" is not > available. > ) at vnode_if.h:373 > #13 0xffffffff80388768 in dofilewrite (td=0xffffff00046c8000, fd=5, > fp=0xffffff001027cd00, auio=dwarf2_read_address: Corrupted DWARF > expression. > ) at file.h:257 > #14 0xffffffff80388a6e in kern_writev (td=0xffffff00046c8000, fd=5, > auio=0xffffffff281a7b00) at /usr/src/sys/kern/sys_generic.c:402 > #15 0xffffffff80388aec in write (td=0x800, uap=0x12d4b9f50) > at /usr/src/sys/kern/sys_generic.c:318 > #16 0xffffffff80596a66 in ia32_syscall (frame=0xffffffff281a7c80) > at /usr/src/sys/amd64/ia32/ia32_syscall.c:182 > #17 0xffffffff80559ad0 in Xint0x80_syscall () at ia32_exception.S:65 > #18 0x0000000028167928 in ?? () > Previous frame inner to this frame (corrupt stack?) > > Full dmesg, verbose boot and kernel config at pastie as well. Actually no > verbose boot... I rebooted the box after setting verbose boot with > "nextboot" and it didn't come back. Hrmph. No remote console, so I don't > know what's up, perhaps waiting on some manual fsck action. > > Thanks, > > Charles > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Nov 23 21:37:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCC27106566B for ; Mon, 23 Nov 2009 21:37:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 717078FC1D for ; Mon, 23 Nov 2009 21:37:31 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABmPCkuDaFvJ/2dsb2JhbADWbYQ8BIFw X-IronPort-AV: E=Sophos;i="4.47,273,1257138000"; d="scan'208";a="55031404" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 23 Nov 2009 16:37:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id E50CBFB80B3; Mon, 23 Nov 2009 16:37:29 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUkUQ-beUsCR; Mon, 23 Nov 2009 16:37:28 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id A506FFB80BD; Mon, 23 Nov 2009 16:37:27 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id nANLjc207133; Mon, 23 Nov 2009 16:45:38 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 23 Nov 2009 16:45:38 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Olaf Seibert In-Reply-To: <20091027164159.GU841@twoquid.cs.ru.nl> Message-ID: References: <20091027164159.GU841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:37:31 -0000 On Tue, 27 Oct 2009, Olaf Seibert wrote: > I see an annoying behaviour with NFS over TCP. It happens both with nfs > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > some Linux or perhaps Solaris, I'm not entirely sure. > [good stuff snipped...] > > Though technically the connection is closed in one direction > only, the intention of the server seems clear, and it would be better to > be careful and make a new connection right away. > I believe that r199293 committed to stable/8 should fix this. It did not make it into FreeBSD8.0, so users of FreeBSD8.0 will need to switch to using "udp" or apply the patch themselves, if slow reconnects after a non-FreeBSD NFS server are causing them grief. rick From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 01:53:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17F461065676; Tue, 24 Nov 2009 01:53:32 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id A60458FC1A; Tue, 24 Nov 2009 01:53:31 +0000 (UTC) Received: by qyk4 with SMTP id 4so1754883qyk.7 for ; Mon, 23 Nov 2009 17:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=OBmIR9xqjMBLPkB0HioLO3xaJSaD6jocRieA4jVEf70=; b=A07oGykEkBggi9QlhLBXjMeBAALaCs/EgV3aZ5i1tXuN6aiSC44hmNepY9YnhfQwlk ZRqXJ1pf1Y2g3E/379U6NoATu96vxauZhBIXCWKPo7FDypoheuUS7TaIU/rfaXybQiex n0BT8VDQ6bamq4ceED8Y5xoTQ7c/J4SQTcD7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=e++g9NQtwIH0chllfqaJoI33ADQh7AQx/eAwnbCdKeYdbQnCs6HtKFplZqdfUjfDpa WaHy5LUVE2VIWvs0NFZ39PUVqe4m/AI0SPd8mpal2V9vivlcKNGnCFqqSqmpmjm2TfOz qUAUg2iGCLyo7QVtkCoGecgrWcNDSvOWD211o= Received: by 10.224.45.23 with SMTP id c23mr2882543qaf.13.1259027611108; Mon, 23 Nov 2009 17:53:31 -0800 (PST) Received: from ?10.0.3.231? (pool-173-70-28-149.nwrknj.fios.verizon.net [173.70.28.149]) by mx.google.com with ESMTPS id 4sm12375584qwe.25.2009.11.23.17.53.29 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 17:53:29 -0800 (PST) From: "Alexandre \"Sunny\" Kovalenko" To: Alexander Motin In-Reply-To: <1258688373.1678.4.camel@RabbitsDen> References: <4B03322A.2080608@FreeBSD.org> <1258688373.1678.4.camel@RabbitsDen> Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Nov 2009 20:53:24 -0500 Message-Id: <1259027604.1654.2.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: FreeBSD Stable Subject: Re: HEADS UP: major CAM ATA MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:53:32 -0000 On Thu, 2009-11-19 at 22:43 -0500, Alexandre "Sunny" Kovalenko wrote: > On Wed, 2009-11-18 at 01:30 +0200, Alexander Motin wrote: > > Feedbacks are welcome as always. > > > Works here (ThinkPad X60): > > ahci0: port > 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf > mem 0xee444400-0xee4447ff irq 16 at device 31.2 on pci0 > ahci0: [ITHREAD] > ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > > RabbitsDen# camcontrol tags ada0 > (pass0:ahcich0:0:0:0): device openings: 32 > RabbitsDen# Might be of interest for some other people out there: with this driver, I can suspend/resume my ThinkPad X60 with UP kernel -- the original ATA driver was going into the timeout loop upon resume. -- Alexandre Kovalenko (ОлексаМЎр КПвалеМкП) From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 03:14:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAC00106566C for ; Tue, 24 Nov 2009 03:14:22 +0000 (UTC) (envelope-from s-qfAT43Emqpeh5D_J-NAS1ePv471C3ccpFxGaKR1zv6y1lQbCOim4C_@bounce.linkedin.com) Received: from maila-ad.linkedin.com (maila-ad.linkedin.com [70.42.142.148]) by mx1.freebsd.org (Postfix) with ESMTP id A57138FC16 for ; Tue, 24 Nov 2009 03:14:22 +0000 (UTC) DomainKey-Signature: s=prod; d=linkedin.com; c=nofws; q=dns; h=Sender:Date:From:To:Message-ID:Subject:MIME-Version: Content-Type:X-LinkedIn-fbl; b=g/HKlb6/Qs88CIROM6pubOYvjew3OkmQ+wd5Nu3Ue8jTg0z5IVAujv3/ n59D8kJFx4yYEWS5TMgGXU3pDjPm1VoB+mXX6BvWhssEcFGV647MAQmBq 66pucnfpFgWizEC; Sender: messages-noreply@bounce.linkedin.com Date: Mon, 23 Nov 2009 18:46:39 -0800 (PST) From: Don Wilde To: Valeriy Rotaev Message-ID: <1509792466.7126047.1259030799504.JavaMail.app@ech3-cdn12.prod> MIME-Version: 1.0 X-LinkedIn-fbl: qfAT43Emqpeh5D_J-NAS1ePv471C3ccpFxGaKR1zv6y1lQbCOim4C_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Don Wilde wants to connect on LinkedIn X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 03:14:22 -0000 LinkedIn ------------ Don Wilde requested to add you as a connection on LinkedIn: ------------------------------------------ Dear Valeriy, I'm merging my GMail with Liked-In so I can easily learn more about what's new in your lives. Please accept my humble invitation and feel free to personally reconnect and strengthen the connection! :D - Don Wilde Accept invitation from Don Wilde http://www.linkedin.com/e/2bA_QBNshSoW6_Mg2FRMfzNsaTwKa_DOn-2pAopq/blk/I39742775_4/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYQnPkTdP8QdPAPiiZWd44MblxWiOYPdz8Md3sPe3wLrCBxbOYWrSlI/EML_comm_afe/ View invitation from Don Wilde http://www.linkedin.com/e/2bA_QBNshSoW6_Mg2FRMfzNsaTwKa_DOn-2pAopq/blk/I39742775_4/d5YRdPsOd3sVcQALqnpPbOYWrSlI/svi/ ------------------------------------------ DID YOU KNOW you can be the first to know when a trusted member of your network changes jobs? With Network Updates on your LinkedIn home page, you'll be notified as members of your network change their current position. Be the first to know and reach out! http://www.linkedin.com/ ------ (c) 2009, LinkedIn Corporation From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 06:24:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99C3B1065670 for ; Tue, 24 Nov 2009 06:24:41 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 754988FC19 for ; Tue, 24 Nov 2009 06:24:41 +0000 (UTC) Received: by pxi12 with SMTP id 12so4620181pxi.3 for ; Mon, 23 Nov 2009 22:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=+0sa16Ign4QP0VwQejcBMSWg2Ojuc2p33yVaKdhwW30=; b=ZwKh+KGjqwrKHHO8Wz9onyi7xyx9FsmP77ZFiorp5KWA+Eoeb5QZcAOvHH34YIfEwk M1v8hKiYciCBbQbPEKjIjQHy97uObqo4KIva0r+VRtymkxZVvFSKuGLfSCLUhkVeyk23 i6d87uqPNBsGXPyFHwH8QCgh9SYlcB5/8xlKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=CXBBP2/n01zTJxkhuIDI++HRclltWVDZEyx1ULxlGITtGh/pT1qyyATBHIvopypxJq VoI1YVvm1YqIqJtzz4cJG/HLIHIM9Iy1FM5HMI7/TCTsAp/ZAm7dKQRjsihyfVKshyIr YGu8jWoxlRhi62YyCi4gDT10IN0G2QqnFEys8= MIME-Version: 1.0 Received: by 10.143.24.37 with SMTP id b37mr661855wfj.183.1259042415093; Mon, 23 Nov 2009 22:00:15 -0800 (PST) From: dikshie Date: Tue, 24 Nov 2009 14:59:55 +0900 Message-ID: <910e60e80911232159t2c52d081nce0d7ecfde713362@mail.gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: tcpdump/libpcap core dump on amd64. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 06:24:41 -0000 Hi, I have experience core dump signal 11 using tcpdump in amd64 arch. 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #14: Tue Nov 24 03:28:14 JST 2009 tcpdump -nvi em2 -> no core dump tcpdump -nvi em2 -c 100 -> core dump i try in i386 and the result: no coredump here's the core file: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `tcpdump'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpcap.so.7...done. Loaded symbols for /lib/libpcap.so.7 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800b244e7 in free () from /lib/libc.so.7 (gdb) bt #0 0x0000000800b244e7 in free () from /lib/libc.so.7 #1 0x00000008006f6a75 in pcap_cleanup_live_common (p=0x800e04400) at /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:1158 #2 0x00000008006f7768 in pcap_cleanup_bpf (p=0x800e04400) at /usr/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c:1218 #3 0x00000008006f65ee in pcap_close (p=0x800e04400) at /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:1232 #4 0x0000000000452b04 in main (argc=Variable "argc" is not available. ) at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1230 thanks! -- -dikshie- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 08:16:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71449106566C; Tue, 24 Nov 2009 08:16:17 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (server70.appriver.com [69.20.119.203]) by mx1.freebsd.org (Postfix) with ESMTP id EAA258FC08; Tue, 24 Nov 2009 08:16:16 +0000 (UTC) X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note: TCH-CT/SI:0-85/SG:5 11/24/2009 3:15:37 AM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.736882 p=-0.901176 Source Normal X-Signature-Violations: 0-0-0-26217-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 107870192; Tue, 24 Nov 2009 03:16:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Nov 2009 00:12:45 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC USB/FS problem Thread-Index: AcprWqhOc0di4XCLQnutgxkzKDrTkwAg+g77AD9+WyA= References: <200911221047.20362.hselasky@c2i.net> From: "Guojun Jin" To: "Guojun Jin" , "Hans Petter Selasky" , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bugs@freebsd.org, freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:16:17 -0000 Freshly installed 8.0-RELEASE on two differnt machines, and USB stick = work well so far, but the USB hard drive still has crash on this SMP (4-core AMD phenom 9600) during the = dump/restore. I will try it on the single CPU machine tomorrow. Re-tested dump/restore with FreeBSD 6.3/6.4 on this SMP machine and they = are working well. Also the another strange thing ocurred during the mount a partition on = /tmp, which ended with two /tmp, and the last one mounted is on the top (the first should be hidden): : df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 756750 165484 530726 24% / devfs 1 1 0 100% /dev /dev/ad0s2e 43194318 27833648 11905126 70% /data /dev/ad0s2d 9135182 5870390 2533978 70% /home /dev/ad0s1e 507630 34882 432138 7% /tmp /dev/ad0s1f 13246730 1424522 10762470 12% /usr /dev/ad0s1d 5077038 12700 4658176 0% /var /dev/da0s2 661176 487660 120622 80% /mnt /dev/da1s3d 9135182 4 8404364 0% /dist /dev/da1s3e 74938948 4 68943830 0% /tmp : df /tmp Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da1s3e 74938948 4 68943830 0% /tmp -----Original Message----- From: Guojun Jin Sent: Sun 11/22/2009 7:59 PM To: Hans Petter Selasky; freebsd-usb@freebsd.org Cc: bugs@freebsd.org; freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem =20 >From more intensive diagnose, it looks like more related USB layer. repeated a few time on following process and ithe crash happened at = different USB access phase at each time. dd if=3D/dev/zero of=3D/dev/da0 count=3D1000 bs=3D4k sysinstall partition=20 slice 1 (da0s1) 18GB ID=3D12 slice 2 (da0s2) 10-15GB Id=3D165 slice 3 (da0s3) rest ID=3D165 W ---> OK label da0s3d 9GB /mnt da0s3e rest /dist W ---> da0s3e ---- device is not configured. w# ll /dev/da0* # after sysinstall did partition + W at 1st time crw-r----- 1 root operator 0, 97 Nov 22 11:23 /dev/da0 crw-r----- 1 root operator 0, 98 Nov 22 11:23 /dev/da0s1 crw-r----- 1 root operator 0, 99 Nov 22 11:23 /dev/da0s2 crw-r----- 1 root operator 0, 100 Nov 22 11:23 /dev/da0s3 # ll /dev/da0* # after sysinstall start at 2nd time crw-r----- 1 root operator 0, 97 Nov 22 11:27 /dev/da0 System crashed The crash log is available at = http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 (All logs are based on hw.usb.umass.debug=3D-1) After system reboot, and repeated above processes, the da0s3e was = mounted on /dist, but da0s3d cannot. It tunred out that newfs fail inside labeling process in sysinstall. = Manually did newfs on da0s3d, and it cannot be mounted on /mnt, but access to it caused crash. The crash log is available at = http:/www.daemonfun.com/archives/pub/USB/newfs Tried entire process again, this time, both partitons are formatted = (newfs) inside labaling process (sysinstall) but crahsed system during dump/restore on da0s3e (/dist). The crash log is available at = http:/www.daemonfun.com/archives/pub/USB/usb-log.crash2.bz2, which is = huge one. It contains two parts, one dump/restore IDE to da0s3d (passed), and the = rest is dump/restore to da0s3e (crashed). I am going to reinstall the system with the new ISO from Nov 21 = 8.0-RELEASE to see if anything will improve. -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Sun 11/22/2009 1:47 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem =20 On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: > Tried on the USB hard drive: > > Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. > Was happy because successfully did dump/restore on s3d, and thought it = just > partition format issue; but system crashed during dump/restore on s3e, = and > partition lost the file system type. > > wolf# mount /dev/da0s3e /mnt > WARNING: /mnt was not properly dismounted > /mnt: mount pending error: blocks 35968 files 0 > wolf# fsck da0s3e > fsck: Could not determine filesystem type > wolf# bsdlabel da0s3 > # /dev/da0s3: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 175735035 0 unused 0 0 # "raw" part, > don't edi t > d: 18874368 0 4.2BSD 0 0 0 > e: 156860667 18874368 4.2BSD 0 0 0 > > Therefore, tried directly use fsck_ufs on both USB hard drive and USB = stick > to get file system clean up. All data got back now. > > The machine has run with FreeBSD 6.1 all the way to 7.2 without such > problem. How can we determine what could go wrong in 8.0? FS or USB. Hi, Error 5 means IO error, so probably the transport layer, USB or lower, = is to=20 blame. Some things to check: 1) Make sure the connection for your memory stick is Ok. 2) Make sure there is enough power for your memory stick. Regarding memory sticks: Other operating systems do a port bus reset when the device has a = problem. On=20 FreeBSD we just try a software reset via the control endpoint. I guess = that it=20 is a device problem you are seeing. The USB stack in FreeBSD is faster = than=20 the old one, and maybe the faster queueing of mass storage requests = trigger=20 some hidden bugs in your device. When the problem happens try: sysctl hw.usb.umass.debug=3D-1 --HPS From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 08:31:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36205106566B; Tue, 24 Nov 2009 08:31:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 63BE38FC0A; Tue, 24 Nov 2009 08:31:42 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=rPscrj6gAAAA:8 a=VSprzn2SJXCWY732YVwA:9 a=efImWuUJO7OosnRcqHoqtDoppKMA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1334636849; Tue, 24 Nov 2009 09:31:41 +0100 From: Hans Petter Selasky To: "Guojun Jin" Date: Tue, 24 Nov 2009 09:33:18 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911240933.19329.hselasky@c2i.net> Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:31:44 -0000 On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: > http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 I'm not able to fetch this file. Could you extract the panic backtrace? --HPS From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 12:24:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CB59106566B for ; Tue, 24 Nov 2009 12:24:35 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.229]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8148FC13 for ; Tue, 24 Nov 2009 12:24:34 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp02.cdmon.com (Postfix) with ESMTP id 3CF6545E75 for ; Tue, 24 Nov 2009 13:24:33 +0100 (CET) Message-ID: <4B0BD02D.6010406@minibofh.org> Date: Tue, 24 Nov 2009 13:23:09 +0100 From: Jordi Espasa Clofent User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: gjournal + gmirror X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:24:35 -0000 Hi all, I've configured a new disk with two journaled partitions (/var and /usr). All works fine until this point. Next I add a new disk and I set up a gmirror as I've done always without problems. But when I reboot the system, I always get a nasty 'mountroot' message. I've cheched the gmirror creation process (module in /boot/loader.conf, the modified fstab... all) and all is correct. I suspect some gjournal+gmirror especial issues maybe.... ¿Any clue? FreeBSD 7.2 AMD64 -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 14:53:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74FA71065672 for ; Tue, 24 Nov 2009 14:53:41 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 05CEF8FC19 for ; Tue, 24 Nov 2009 14:53:40 +0000 (UTC) Received: by bwz5 with SMTP id 5so6462219bwz.3 for ; Tue, 24 Nov 2009 06:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:organization:from :date:message-id:user-agent:mime-version:content-type; bh=QAcFdS+EcWB/O5rE7qWePa8lGdJmp062iLToeis7Rcs=; b=Y/MDkYPftk9iB1eqTm2Lw4dbam0++A2A7nLvh/BF1sk40vR7bjwV+jebX8HB+xqe2a xA/CYfoA43KNCx6mpMl0RgJPPLlFq8/x1qlA7Q0+0hvk0IZKr26dNKqaPgbE8HuXakqW Z+Euu47rtzfLbSd6vYGk0TQ3QN66B0e6QCAPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:organization:from:date:message-id:user-agent :mime-version:content-type; b=u69v7sSm5slz8d7YKXvQ02baBtu7HMZuZJsX0vWwmK2cxGSUDCHbZ0dtwb0kxDuGB4 gIXK0BXqepEgeM91OJmAqXsDWISgI2om4wOAgIRRo5byfLEBwGdbkujgBgPTqsX02O9E 3qf0XsNak8TwRnEkvU/4RnC1FUTkIR7gt791c= Received: by 10.204.154.209 with SMTP id p17mr5926027bkw.104.1259074419180; Tue, 24 Nov 2009 06:53:39 -0800 (PST) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 14sm1421096bwz.9.2009.11.24.06.53.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 06:53:37 -0800 (PST) To: FreeBSD Stable Organization: TOA Ukraine From: Mikolaj Golub Date: Tue, 24 Nov 2009 16:53:35 +0200 Message-ID: <86aayc7z4g.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:53:41 -0000 Hi, I have problems with compiling our application under 8.0. It fails due to these definitions in pthread.h that look like a typo or incorrectly applied patch: 170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \ 171 { \ 172 struct _pthread_cleanup_info __cleanup_info__; \ 173 __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ 174 &__cleanup_info__); \ 175 { 176 177 #define pthread_cleanup_pop(execute) \ 178 } \ 179 __pthread_cleanup_pop_imp(execute); \ 180 } This patch fixes the problem for me: --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 @@ -172,10 +172,10 @@ struct _pthread_cleanup_info __cleanup_info__; \ __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ &__cleanup_info__); \ - { + } #define pthread_cleanup_pop(execute) \ - } \ + { \ __pthread_cleanup_pop_imp(execute); \ } -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 15:14:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 801E3106566C for ; Tue, 24 Nov 2009 15:14:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 11EAB8FC1A for ; Tue, 24 Nov 2009 15:14:00 +0000 (UTC) Received: by bwz5 with SMTP id 5so6484152bwz.3 for ; Tue, 24 Nov 2009 07:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L9MwjzbSvMypy+CGEbxFvYRxgYURiWs1q25OFeJU23E=; b=lTtgwsllzCOpJ4L/Ng8FQJyU6/zer+QksYvxBEDa2wxXl9rEHfve0EmgQEVXzsq1h/ kqOlxTl5EqhFTSALiDunIrrf8gLLCee/QQ1eCqco5DKk3kVHmZDXencd8Rlk6p3loki/ ksU9ykiWQgVHG6Y5pJOAsz4O6MQbid9VmvzFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bkQCUwgY2fS2K+/rLbaxtDxPJGwzzLEmFl1sRvEqgBopJali8xTzv6/1eTmCZvYguP 53cnzBA+AZwkAmU3PAlXM7hjOjHs+w3dJs63oCGiGmCY62fGjlJFDQB10PWktHubhvTQ g0mwHclYCgxqaYQ5z8SKJdMoQ4GEurCb8oaKI= MIME-Version: 1.0 Received: by 10.204.10.7 with SMTP id n7mr2485676bkn.68.1259075639877; Tue, 24 Nov 2009 07:13:59 -0800 (PST) In-Reply-To: <86aayc7z4g.fsf@zhuzha.ua1> References: <86aayc7z4g.fsf@zhuzha.ua1> Date: Tue, 24 Nov 2009 18:13:59 +0300 Message-ID: From: pluknet To: Mikolaj Golub Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Cc: FreeBSD Stable Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:14:01 -0000 MjAwOS8xMS8yNCBNaWtvbGFqIEdvbHViIDx0by5teS50cm9jaW55QGdtYWlsLmNvbT46Cj4gSGks Cj4KPiBJIGhhdmUgcHJvYmxlbXMgd2l0aCBjb21waWxpbmcgb3VyIGFwcGxpY2F0aW9uIHVuZGVy IDguMC4KPgo+IEl0IGZhaWxzIGR1ZSB0byB0aGVzZSBkZWZpbml0aW9ucyBpbiBwdGhyZWFkLmgg dGhhdCBsb29rIGxpa2UgYSB0eXBvIG9yCj4gaW5jb3JyZWN0bHkgYXBwbGllZCBwYXRjaDoKPgo+ IKAgoDE3MCAjZGVmaW5lIKAgoCCgIKAgcHRocmVhZF9jbGVhbnVwX3B1c2goY2xlYW51cF9yb3V0 aW5lLCBjbGVhbnVwX2FyZykgoCCgIKAgoCCgIKAgoFwKPiCgIKAxNzEgoCCgIKAgoCCgIKAgoCCg IHsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBcCj4goCCgMTcyIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHN0cnVjdCBfcHRocmVh ZF9jbGVhbnVwX2luZm8gX19jbGVhbnVwX2luZm9fXzsgoCCgIKAgoCCgXAo+IKAgoDE3MyCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCBfX3B0aHJlYWRfY2xlYW51cF9wdXNoX2ltcChjbGVhbnVwX3Jv dXRpbmUsIGNsZWFudXBfYXJnLFwKPiCgIKAxNzQgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCAmX19jbGVhbnVwX2luZm9fXyk7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBcCj4g oCCgMTc1IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHsKPiCgIKAxNzYKPiCgIKAxNzcgI2RlZmlu ZSCgIKAgoCCgIHB0aHJlYWRfY2xlYW51cF9wb3AoZXhlY3V0ZSkgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKBcCj4goCCgMTc4IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIH0goCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgXAo+IKAg oDE3OSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBfX3B0aHJlYWRfY2xlYW51cF9wb3BfaW1wKGV4 ZWN1dGUpOyCgIKAgoCCgIKAgoCCgIKAgoCCgIFwKPiCgIKAxODAgoCCgIKAgoCCgIKAgoCCgIH0K PgoKSGkuCgpObywgdGhpcyBpcyBtYWRlIGludGVudGlvbmFsbHkuClAuUy4gSSBkb24ndCB1bmRl cnN0YW5kIHRoZSByZWFzb24gaW4gdGhlIHNlY29uZCBicmFja2V0cyBwYWlyIHRob3VnaAoobGlu ZXMgMTc1LDE3OCksCiBtYXliZSB0aGVzZSBhcmUgYmVjYXVzZSBvZiBjb21tZW50IHRvIHYxLjQz Li4KCi0tIAp3YnIsCnBsdWtuZXQK From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 15:18:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05F5A1065693 for ; Tue, 24 Nov 2009 15:18:34 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA3E8FC19 for ; Tue, 24 Nov 2009 15:18:33 +0000 (UTC) Received: by bwz5 with SMTP id 5so6488938bwz.3 for ; Tue, 24 Nov 2009 07:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=ap+5IHbO//52lh0SmRF9Rgj85h9cJYG/FYI5Vuk46bQ=; b=VrN/YPOxwHYIMMdZbI6akeEBW4nojKD77CyVXvRd4jKim7tGYWgJkdoOGyXNFRBhbn TlN1xWFwwZcUj0uWSBd13Um4wi5xztFQObz4P0EWEJmSkVm0oom5w32FU9VrvP9Lmltr 8jKl3NIXFoGSECW0d3+d/tf9NjzyDqulvbvHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:references:organization:from:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=XyPXpD8UxJ9z1op1VuKvatQXOLTk/D84n9gVfQv9eW3Upz2L2PW2/3X1qv/bW0IgjV DX452K2ZfN3Mb7GhPbTJO0RxYnxIv+O1U45rhcMGwub9rWKxDR/nAZ2y6gXje/hFHAMM UMpM+NQ9hEoW9lQwA3cnm5f379XclNMSSjxzM= Received: by 10.204.20.142 with SMTP id f14mr343371bkb.64.1259075912035; Tue, 24 Nov 2009 07:18:32 -0800 (PST) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 13sm1434861bwz.2.2009.11.24.07.18.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 07:18:31 -0800 (PST) To: FreeBSD Stable References: <86aayc7z4g.fsf@zhuzha.ua1> Organization: TOA Ukraine From: Mikolaj Golub Date: Tue, 24 Nov 2009 17:18:29 +0200 In-Reply-To: <86aayc7z4g.fsf@zhuzha.ua1> (Mikolaj Golub's message of "Tue\, 24 Nov 2009 16\:53\:35 +0200") Message-ID: <8663907xyy.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:18:34 -0000 On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote: > Hi, > > I have problems with compiling our application under 8.0. > > It fails due to these definitions in pthread.h that look like a typo or > incorrectly applied patch: > > 170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \ > 171 { \ > 172 struct _pthread_cleanup_info __cleanup_info__; \ > 173 __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ > 174 &__cleanup_info__); \ > 175 { > 176 > 177 #define pthread_cleanup_pop(execute) \ > 178 } \ > 179 __pthread_cleanup_pop_imp(execute); \ > 180 } > > > This patch fixes the problem for me: I was hurry when said that the patch fixed the problem. The application compiled but later it crashed in pthread_cleanup_pop: (gdb) bt #0 0xbf4f9ee0 in ?? () #1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3 #2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3 #3 0x287d123c in pthread_exit () from /lib/libthr.so.3 #4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3 #5 0x00000000 in ?? () So, I don't know what these macros actually were supposed to be. They were introduced in r179662: Revision 1.43: download - view: text, markup, annotated - select for diffs Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu Branches: MAIN Diff to: previous 1.42: preferred, colored Changes since revision 1.42: +21 -2 lines SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros, use stack space to keep cleanup information, this eliminates overhead of calling malloc() and free() in thread library. Discussed on: thread@ > --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 > +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 > @@ -172,10 +172,10 @@ > struct _pthread_cleanup_info __cleanup_info__; \ > __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ > &__cleanup_info__); \ > - { > + } > > #define pthread_cleanup_pop(execute) \ > - } \ > + { \ > __pthread_cleanup_pop_imp(execute); \ > } -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 15:32:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B6601065676 for ; Tue, 24 Nov 2009 15:32:59 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8898FC08 for ; Tue, 24 Nov 2009 15:32:58 +0000 (UTC) Received: by ewy21 with SMTP id 21so628581ewy.13 for ; Tue, 24 Nov 2009 07:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6DQL5RjitfTuaxBPn2sfTpEj70/eM06sURNyk7kqQqo=; b=wXFv6oYIuWtna6w7IdSdevlNB/6zzlBYK+lAP/VLrAXYkVuh0RAFof/w7HMUNxXrS+ PxvIQm4fRnrOtV40M9k+HrHtb38FCCmRRAdiIKvLwGwKe/QSE+UL3h1BvCHuLJZ6D0Lc 7L1Y1Yr5od6lE0emSwhjHcieUtFDrMtudV7eY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lW4W5V3PHQUQpVlnE8bbwaUBnOTvKmAfGIgj7Hd3gc/rHrSSuE2rqfOaxBRglgEubk Nquq2Je4yuLZz28EEoIPf1yb6xQrPZF2YOPr5Z+8bPo4Sq1rZ/ah4qRmBvQCtu9kcv4I z+YG63WNkQIy4g4uWeyq0COQMDjGBOvQ3LBH4= MIME-Version: 1.0 Received: by 10.213.0.195 with SMTP id 3mr5275377ebc.87.1259076777232; Tue, 24 Nov 2009 07:32:57 -0800 (PST) In-Reply-To: <8663907xyy.fsf@zhuzha.ua1> References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> Date: Tue, 24 Nov 2009 15:32:57 +0000 Message-ID: <2e027be00911240732u1ac60d31ucbbb65545636e6b@mail.gmail.com> From: Tom Evans To: Mikolaj Golub Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:32:59 -0000 On Tue, Nov 24, 2009 at 3:18 PM, Mikolaj Golub wrote: > > So, I don't know what these macros actually were supposed to be. They were > introduced in r179662: > > Revision 1.43: download - view: text, markup, annotated - select for diffs > Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu > Branches: MAIN > Diff to: previous 1.42: preferred, colored > Changes since revision 1.42: +21 -2 lines > > SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu > > Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros, > use stack space to keep cleanup information, this eliminates overhead of > calling malloc() and free() in thread library. > > Discussed on: thread@ > http://lists.freebsd.org/pipermail/freebsd-threads/2008-May/004299.html Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 15:34:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B326C106566B for ; Tue, 24 Nov 2009 15:34:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2ACD38FC12 for ; Tue, 24 Nov 2009 15:34:26 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id nAOFYMff097023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 17:34:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id nAOFYMtd089187; Tue, 24 Nov 2009 17:34:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id nAOFYMRA089186; Tue, 24 Nov 2009 17:34:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Nov 2009 17:34:22 +0200 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20091124153422.GT2331@deviant.kiev.zoral.com.ua> References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i616tqyc3hrkKsk2" Content-Disposition: inline In-Reply-To: <8663907xyy.fsf@zhuzha.ua1> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Stable Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:34:27 -0000 --i616tqyc3hrkKsk2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote: > On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote: >=20 > > Hi, > > > > I have problems with compiling our application under 8.0. > > > > It fails due to these definitions in pthread.h that look like a typo or > > incorrectly applied patch: > > > > 170 #define pthread_cleanup_push(cleanup_routine, cleanup_a= rg) \ > > 171 { = \ > > 172 struct _pthread_cleanup_info __cleanup_= info__; \ > > 173 __pthread_cleanup_push_imp(cleanup_rout= ine, cleanup_arg,\ > > 174 &__cleanup_info__); = \ > > 175 { > > 176=20 > > 177 #define pthread_cleanup_pop(execute) = \ > > 178 } = \ > > 179 __pthread_cleanup_pop_imp(execute); = \ > > 180 } > > > > > > This patch fixes the problem for me: >=20 > I was hurry when said that the patch fixed the problem. The application > compiled but later it crashed in pthread_cleanup_pop: >=20 > (gdb) bt > #0 0xbf4f9ee0 in ?? () > #1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3 > #2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3 > #3 0x287d123c in pthread_exit () from /lib/libthr.so.3 > #4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3 > #5 0x00000000 in ?? () >=20 > So, I don't know what these macros actually were supposed to be. They were > introduced in r179662: >=20 > Revision 1.43: download - view: text, markup, annotated - select for diffs > Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu > Branches: MAIN > Diff to: previous 1.42: preferred, colored > Changes since revision 1.42: +21 -2 lines >=20 > SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu >=20 > Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros, > use stack space to keep cleanup information, this eliminates overhead of > calling malloc() and free() in thread library. >=20 > Discussed on: thread@ >=20 > > --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 > > +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 > > @@ -172,10 +172,10 @@ > > struct _pthread_cleanup_info __cleanup_info__; = \ > > __pthread_cleanup_push_imp(cleanup_routine, cle= anup_arg,\ > > &__cleanup_info__); = \ > > - { > > + } =20 > > =20 > > #define pthread_cleanup_pop(execute) = \ > > - } = \ > > + { = \ > > __pthread_cleanup_pop_imp(execute); = \ > > } pthread_cleanup_push/pop are supposed to be used from the common lexical scope. Citation from SUSv4: These functions may be implemented as macros. The application shall ensure that they appear as statements, and in pairs within the same lexical scope (that is, the pthread_cleanup_push() macro may be thought to expand to a token list whose first token is '{' with pthread_cleanup_pop() expanding to a token list whose last token is the corresponding '}' ). Your change is wrong. Basically, the code should do pthread_cleanup_push(some_func, arh); something ... pthread_cleanup_pop(1); (1 denotes that some_func should be called). --i616tqyc3hrkKsk2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksL/P4ACgkQC3+MBN1Mb4h4UwCgxIIHVqHBqU9wPIQKiOWf9g2z r94AoOiN4CE6Eig6AlJ1IuHFo9Hk7Pvf =FjUi -----END PGP SIGNATURE----- --i616tqyc3hrkKsk2-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 15:35:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92B39106568F; Tue, 24 Nov 2009 15:35:28 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1C42B8FC28; Tue, 24 Nov 2009 15:35:27 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga-m.mahoroba.org [IPv6:2001:2f0:104:801c:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nAOFZCmb045295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 00:35:20 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 25 Nov 2009 00:35:05 +0900 Message-ID: From: Hajimu UMEMOTO To: Mikolaj Golub In-Reply-To: <8663907xyy.fsf@zhuzha.ua1> References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-RELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Wed, 25 Nov 2009 00:35:21 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: FreeBSD Stable Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:35:28 -0000 Hi, >>>>> On Tue, 24 Nov 2009 17:18:29 +0200 >>>>> Mikolaj Golub said: to.my.trociny> I was hurry when said that the patch fixed the problem. The application to.my.trociny> compiled but later it crashed in pthread_cleanup_pop: to.my.trociny> (gdb) bt to.my.trociny> #0 0xbf4f9ee0 in ?? () to.my.trociny> #1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3 to.my.trociny> #2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3 to.my.trociny> #3 0x287d123c in pthread_exit () from /lib/libthr.so.3 to.my.trociny> #4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3 to.my.trociny> #5 0x00000000 in ?? () to.my.trociny> So, I don't know what these macros actually were supposed to be. They were to.my.trociny> introduced in r179662: Your modification to pthread.h is wrong. You need to write your code something like following: pthread_cleanup_push(); . . . do something . . . pthread_cleanup_pop(); This is not FreeBSD alone. pthread_cleanup_push() and pthread_cleanup_pop() are macro on Linux as well. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 15:47:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD021065695 for ; Tue, 24 Nov 2009 15:47:47 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id ED0F78FC20 for ; Tue, 24 Nov 2009 15:47:46 +0000 (UTC) Received: by bwz5 with SMTP id 5so6520691bwz.3 for ; Tue, 24 Nov 2009 07:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=YBuNJXGraUfaw1TMHhGoUNjVqli5F/rDlZMAfXrqNdA=; b=aWRNI1piKE4lUBb36viaxZ9O2EktPPbVrghnnrSDrgyjFP5bnSsTfaEdHTYZGY1+Ad BZWrH/zHbIlXTlxEuXFugPhnGhx8U/yrP+LnXqqig1t7sARzmc+My1df+r9J9mAn3Uap dxfvqJuhHa92ounzR0XLCy6RJ6yYpPvck/LHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=by5KBg3w7LMG2eTH+Fgc2w3h/qoJuLX4PUvv/74jBMiuSu61Z1r604rG/X3ti0gXJn fWX7O29GBiX2d37xF0XJVgVFtto5Ki6EU3YbWuQAzmbuBTsNCLjB+NWlkqD2Qqf08HqA ed9XZB5dEh7iy82+Y5TIbUAlw1iG5HrWXfUqI= Received: by 10.204.156.217 with SMTP id y25mr990263bkw.76.1259077665636; Tue, 24 Nov 2009 07:47:45 -0800 (PST) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 15sm1434571bwz.4.2009.11.24.07.47.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 07:47:44 -0800 (PST) To: Kostik Belousov References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> Organization: TOA Ukraine From: Mikolaj Golub Date: Tue, 24 Nov 2009 17:47:42 +0200 In-Reply-To: <20091124153422.GT2331@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Tue\, 24 Nov 2009 17\:34\:22 +0200") Message-ID: <861vjn9b6p.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Stable Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:47:47 -0000 On Tue, 24 Nov 2009 17:34:22 +0200 Kostik Belousov wrote: > pthread_cleanup_push/pop are supposed to be used from the common > lexical scope. Citation from SUSv4: > > These functions may be implemented as macros. The application shall > ensure that they appear as statements, and in pairs within the same > lexical scope (that is, the pthread_cleanup_push() macro may be > thought to expand to a token list whose first token is '{' with > pthread_cleanup_pop() expanding to a token list whose last token is the > corresponding '}' ). > > Your change is wrong. > > Basically, the code should do > pthread_cleanup_push(some_func, arh); > something ... > pthread_cleanup_pop(1); > (1 denotes that some_func should be called). I see. Thank you. So it really looks like a bug in our application as pthread_cleanup_pop(1) is missed. I will tell our developers :-) -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 17:09:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A1C2106566B; Tue, 24 Nov 2009 17:09:03 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (gwlb1.appriver.com [69.20.60.122]) by mx1.freebsd.org (Postfix) with ESMTP id CD4AD8FC0C; Tue, 24 Nov 2009 17:09:01 +0000 (UTC) X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note: TCH-CT/SI:0-415/SG:5 11/24/2009 12:08:03 PM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.745707 p=-0.900648 Source Normal X-Signature-Violations: 0-0-0-4797-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 107930775; Tue, 24 Nov 2009 12:09:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Nov 2009 08:58:47 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC USB/FS problem Thread-Index: Acps4DRh91jZwvKvTYah2bfhsI4ySQARy8PJ References: <200911240933.19329.hselasky@c2i.net> From: "Guojun Jin" To: "Hans Petter Selasky" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: RE: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:09:03 -0000 Sorry for the typo -- it is public not pub in the middle. The others = should be all public. http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Tue 11/24/2009 12:33 AM To: Guojun Jin Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; = freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem =20 On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: > http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 I'm not able to fetch this file. Could you extract the panic backtrace? --HPS From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 17:11:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35F06106568D; Tue, 24 Nov 2009 17:11:54 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2FC8FC13; Tue, 24 Nov 2009 17:11:52 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=rPscrj6gAAAA:8 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=mK_DLrGy7CXV3tfyuFgA:9 a=wx7D4YLKRSFbyesQ_58A:7 a=Vtk2n1sZcEM6qDpyLC9ZRYUwTHAA:4 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1331367170; Tue, 24 Nov 2009 18:11:51 +0100 From: Hans Petter Selasky To: "Guojun Jin" Date: Tue, 24 Nov 2009 18:13:21 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200911240933.19329.hselasky@c2i.net> In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911241813.23616.hselasky@c2i.net> Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:11:54 -0000 On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: > Sorry for the typo -- it is public not pub in the middle. The others should > be all public. > > http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No address record --HPS > -----Original Message----- > From: Hans Petter Selasky [mailto:hselasky@c2i.net] > Sent: Tue 11/24/2009 12:33 AM > To: Guojun Jin > Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org > Subject: Re: 8.0-RC USB/FS problem > > On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: > > http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 > > I'm not able to fetch this file. Could you extract the panic backtrace? > > --HPS From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 17:40:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29EFC106568F for ; Tue, 24 Nov 2009 17:40:17 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id CB42B8FC1F for ; Tue, 24 Nov 2009 17:40:16 +0000 (UTC) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA07.westchester.pa.mail.comcast.net with comcast id 924x1d0011HzFnQ575gGUz; Tue, 24 Nov 2009 17:40:16 +0000 Received: from [192.168.2.164] ([206.210.89.202]) by OMTA14.westchester.pa.mail.comcast.net with comcast id 95g31d0034Mx3R23a5g5lE; Tue, 24 Nov 2009 17:40:14 +0000 Message-ID: <4B0C1A72.3000301@comcast.net> Date: Tue, 24 Nov 2009 12:40:02 -0500 From: Steve Polyack User-Agent: Thunderbird 2.0.0.23 (X11/20090902) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org, freebsd-stable , freebsd-geom@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Panic possibly related to glabel/geom and siis(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:40:17 -0000 I have a system running 8.0-PRERELEASE with multiple drives and SATA port multipliers (siis controllers and PMPs). All of the attached drives are labeled via glabel(8) and then included into a ZFS pool. During some testing to determine how the system would react to a dead drive (simulated by physically removing a drive during operation), I was able to produce a panic. Now, I know that the SATA PMP and siis(4) code to handle and recover from device errors is incomplete, but I believe the crash may be particular to using glabel'd drives. Basically, after removing a drive while the zpool is in use and issues 'camcontrol reset' and 'rescan' on the appropriate bus, the physical device associated with the drive disappears. In this case: (pass5:siisch7:0:15:0): lost device (pass5:siisch7:0:15:0): removing device entry (ada2:siisch7:0:0:0): lost device and /dev/ada2 disappears. However, the associated glabel /dev/label/bigdisk07 remains. Since my ZFS pool is created based on the drive glabels, I believe this is why ZFS never notices the drives disappear either. Do glabels typically go away after a physical device is lost? Should this not be the case? After some runtime with the physical device missing, a kernel panic is produced: ada2:siisch7:0:0:0): Synchronize cache failed (ada2:siisch7:0:0:0): removing device entry Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 14 fault virtual address = 0x48 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8035f375 stack pointer = 0x28:0xffffff800006db60 frame pointer = 0x28:0xffffff800006db70 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 = 2 (g_event) [thread pid 2 tid 100014 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db> bt Tracing pid 2 tid 100014 td 0xffffff00014d4ab0 _mtx_lock_flags() at _mtx_lock_flags+0x15 vdev_geom_release() at vdev_geom_release+0x33 vdev_geom_orphan() at vdev_geom_orphan+0x15c g_run_events() at g_run_events+0x104 g_event_procbody() at g_event_procbody+0x55 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800006dd30, rbp = 0 --- I'm open to try patches and other suggestions. Thanks. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 17:47:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31FDE1065782 for ; Tue, 24 Nov 2009 17:47:16 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 18A818FC15 for ; Tue, 24 Nov 2009 17:47:15 +0000 (UTC) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 954P1d00a0vp7WLA95nGEP; Tue, 24 Nov 2009 17:47:16 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id 95nF1d0093S48mS8R5nFjj; Tue, 24 Nov 2009 17:47:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 64A391E3035; Tue, 24 Nov 2009 09:47:14 -0800 (PST) Date: Tue, 24 Nov 2009 09:47:14 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091124174714.GA2240@icarus.home.lan> References: <200911240933.19329.hselasky@c2i.net> <200911241813.23616.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911241813.23616.hselasky@c2i.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:47:16 -0000 On Tue, Nov 24, 2009 at 06:13:21PM +0100, Hans Petter Selasky wrote: > On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: > > Sorry for the typo -- it is public not pub in the middle. The others should > > be all public. > > > > http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > > > %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No > address record > > --HPS > > > -----Original Message----- > > From: Hans Petter Selasky [mailto:hselasky@c2i.net] > > Sent: Tue 11/24/2009 12:33 AM > > To: Guojun Jin > > Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org > > Subject: Re: 8.0-RC USB/FS problem > > > > On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: > > > http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 > > > > I'm not able to fetch this file. Could you extract the panic backtrace? > > > > --HPS The above issue is unrelated to the USB/FS problem. It looks like fetch(1) has a parser bug. Note the text portion between the URI and URL is colon-slash not colon-slash-slash like it should be. Reproduction: $ host www.daemonfun.com www.daemonfun.com is an alias for daemonfun.com. daemonfun.com has address 76.202.192.211 daemonfun.com mail is handled by 10 mh1.daemonfun.com. daemonfun.com mail is handled by 20 mh2.daemonfun.com. $ fetch http:/www.daemonfun.com/ fetch: http:/www.daemonfun.com/: No address record I haven't examined the code, but my guess is fetch is trying to do a lookup on the FQDN "http:/www.daemonfun.com/". Who wants to file a PR? :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 18:16:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54E5C106568B for ; Tue, 24 Nov 2009 18:16:58 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 18A778FC14 for ; Tue, 24 Nov 2009 18:16:57 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id nAOIGtB3040474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Nov 2009 12:16:55 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id nAOIGtEZ061757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Nov 2009 12:16:55 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id nAOIGsT9061756; Tue, 24 Nov 2009 12:16:54 -0600 (CST) (envelope-from dan) Date: Tue, 24 Nov 2009 12:16:54 -0600 From: Dan Nelson To: Jeremy Chadwick Message-ID: <20091124181654.GI89004@dan.emsphone.com> References: <200911240933.19329.hselasky@c2i.net> <200911241813.23616.hselasky@c2i.net> <20091124174714.GA2240@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091124174714.GA2240@icarus.home.lan> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Tue, 24 Nov 2009 12:16:55 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:16:58 -0000 In the last episode (Nov 24), Jeremy Chadwick said: > On Tue, Nov 24, 2009 at 06:13:21PM +0100, Hans Petter Selasky wrote: > > On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: > > > Sorry for the typo -- it is public not pub in the middle. The others should > > > be all public. > > > > > > http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > > > > > > %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No address record > > The above issue is unrelated to the USB/FS problem. It looks like > fetch(1) has a parser bug. Note the text portion between the URI and URL > is colon-slash not colon-slash-slash like it should be. That's a typo in the URL, not a bug in fetch :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 18:50:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 114D710656C0 for ; Tue, 24 Nov 2009 18:50:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id EA8E88FC13 for ; Tue, 24 Nov 2009 18:50:17 +0000 (UTC) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id 96121d00C17UAYkA16pXH2; Tue, 24 Nov 2009 18:49:31 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id 96qH1d00B3S48mS8Z6qH2L; Tue, 24 Nov 2009 18:50:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5C3671E3035; Tue, 24 Nov 2009 10:50:16 -0800 (PST) Date: Tue, 24 Nov 2009 10:50:16 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091124185016.GA3433@icarus.home.lan> References: <200911240933.19329.hselasky@c2i.net> <200911241813.23616.hselasky@c2i.net> <20091124174714.GA2240@icarus.home.lan> <20091124181654.GI89004@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091124181654.GI89004@dan.emsphone.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:50:18 -0000 On Tue, Nov 24, 2009 at 12:16:54PM -0600, Dan Nelson wrote: > In the last episode (Nov 24), Jeremy Chadwick said: > > On Tue, Nov 24, 2009 at 06:13:21PM +0100, Hans Petter Selasky wrote: > > > On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: > > > > Sorry for the typo -- it is public not pub in the middle. The others should > > > > be all public. > > > > > > > > http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > > > > > > > > > %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > > fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No address record > > > > The above issue is unrelated to the USB/FS problem. It looks like > > fetch(1) has a parser bug. Note the text portion between the URI and URL > > is colon-slash not colon-slash-slash like it should be. > > That's a typo in the URL, not a bug in fetch :) It's a bug in libfetch, specifically the fetchParseURL(3) function. Relevant code from src/usr.bin/fetch/fetch.c: 312 static int 313 fetch(char *URL, const char *path) 314 { 315 struct url *url; ... 342 /* parse URL */ 343 if ((url = fetchParseURL(URL)) == NULL) { 344 warnx("%s: parse error", URL); 345 goto failure; 346 } The man page for fetchParseURL(3) claims: fetchParseURL() takes a URL in the form of a null-terminated string and splits it into its components function according to the Common Internet Scheme Syntax detailed in RFC1738. A regular expression which produces this syntax is: :(//((:)?@)?(:)?)?/()? If the URL does not seem to begin with a scheme name, the following syn- tax is assumed: (((:)?@)?(:)?)?/()? ..... fetchParseURL() returns a pointer to a struct url containing the individ- ual components of the URL. If it is unable to allocate memory, or the URL is syntactically incorrect, fetchParseURL() returns a NULL pointer. If we add some debugging code *before* the "scheme assumption" portion of fetch.c (which actually looks at the hostname portion and if it starts with "ftp" assumes the scheme is FTP, "http" = HTTP, etc.): 348 printf("fetchParseURL() successful. struct details:\n"); 349 printf("url->scheme = %s\n", url->scheme); 350 printf("url->user = %s\n", url->user); 351 printf("url->pwd = %s\n", url->pwd); 352 printf("url->host = %s\n", url->host); 353 printf("url->port = %d\n", url->port); 354 printf("url->doc = %s\n", url->doc); ...we end up with this: $ ./fetch http:/www.daemonfun.com/ fetchParseURL() successful. struct details: url->scheme = http url->user = url->pwd = url->host = url->port = 0 url->doc = /www.daemonfun.com/ fetch: http:/www.daemonfun.com/: No address record Here we can see the libfetch code properly works out the scheme (URI) on its own (which means the "assumption part" of the man page should not play a role here) -- but incorrectly parses the remaining portion of the URL. In this situation, fetchParseURL(3) should return NULL. The code in fetch.c continues on to call fetchXGet(3) with the above struct data (some of it gets modified, but that's besides the point), and the result is fetchXGet(3) returning NULL (indicating the fetch failed in some way), which gets us here: 463 f = fetchXGet(url, &us, flags); ... 468 if (f == NULL) { 469 warnx("%s: %s", URL, fetchLastErrString); 470 if (i_flag && strcmp(url->scheme, SCHEME_HTTP) == 0 471 && fetchLastErrCode == FETCH_OK 472 && strcmp(fetchLastErrString, "Not Modified") == 0) { 473 /* HTTP Not Modified Response, return OK. */ 474 r = 0; 475 goto done; 476 } else 477 goto failure; 478 } We modify some code to add some debugging to validate that warnx() is what's returning the error message: 469 warnx("fetchXGet() returned NULL: %s: %s", URL, fetchLastErrString); ...and we end up with: fetch: fetchXGet() returned NULL: http:/www.daemonfun.com/: No address record I guess I'll be the one to file the PR. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 21:14:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 532B6106566C for ; Tue, 24 Nov 2009 21:14:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by mx1.freebsd.org (Postfix) with ESMTP id 3CEE28FC0A for ; Tue, 24 Nov 2009 21:14:40 +0000 (UTC) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 5F6DEE6063; Tue, 24 Nov 2009 21:14:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nAOLEZIN049990; Wed, 25 Nov 2009 08:14:36 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200911242114.nAOLEZIN049990@drugs.dv.isc.org> To: Mikolaj Golub From: Mark Andrews References: <86aayc7z4g.fsf@zhuzha.ua1> In-reply-to: Your message of "Tue, 24 Nov 2009 16:53:35 +0200." <86aayc7z4g.fsf@zhuzha.ua1> Date: Wed, 25 Nov 2009 08:14:35 +1100 Sender: marka@isc.org Cc: FreeBSD Stable Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:14:40 -0000 Report it using "send-pr". That way the problem will make its way into the bug tracking system. In message <86aayc7z4g.fsf@zhuzha.ua1>, Mikolaj Golub writes: > Hi, > > I have problems with compiling our application under 8.0. > > It fails due to these definitions in pthread.h that look like a typo or > incorrectly applied patch: > > 170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg) > \ > 171 { > \ > 172 struct _pthread_cleanup_info __cleanup_info__; > \ > 173 __pthread_cleanup_push_imp(cleanup_routine, clean > up_arg,\ > 174 &__cleanup_info__); > \ > 175 { > 176 > 177 #define pthread_cleanup_pop(execute) > \ > 178 } > \ > 179 __pthread_cleanup_pop_imp(execute); > \ > 180 } > > > This patch fixes the problem for me: > > --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 > +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 > @@ -172,10 +172,10 @@ > struct _pthread_cleanup_info __cleanup_info__; \ > __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ > &__cleanup_info__); \ > - { > + } > > #define pthread_cleanup_pop(execute) > \ > - } \ > + { \ > __pthread_cleanup_pop_imp(execute); \ > } > > -- > Mikolaj Golub > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 21:29:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 209D3106566B for ; Tue, 24 Nov 2009 21:29:35 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id CEF668FC12 for ; Tue, 24 Nov 2009 21:29:34 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id nAOLTX1A015588; Tue, 24 Nov 2009 16:29:33 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Tue, 24 Nov 2009 16:29:33 -0500 (EST) Date: Tue, 24 Nov 2009 16:29:33 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Mark Andrews In-Reply-To: <200911242114.nAOLEZIN049990@drugs.dv.isc.org> Message-ID: References: <86aayc7z4g.fsf@zhuzha.ua1> <200911242114.nAOLEZIN049990@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable , Mikolaj Golub Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:29:35 -0000 On Wed, 25 Nov 2009, Mark Andrews wrote: > > Report it using "send-pr". That way the problem will make its way into the > bug tracking system. > > In message <86aayc7z4g.fsf@zhuzha.ua1>, Mikolaj Golub writes: >> Hi, >> >> I have problems with compiling our application under 8.0. >> >> It fails due to these definitions in pthread.h that look like a typo or >> incorrectly applied patch: Did someone already reply to this? I think the problem is in your application. You cannot have push and pop at different nesting levels. The start brace in the push is ended by the end brace in pop on purpose. It is to enforce nesting levels. >> >> 170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg) >> \ >> 171 { >> \ >> 172 struct _pthread_cleanup_info __cleanup_info__; >> \ >> 173 __pthread_cleanup_push_imp(cleanup_routine, clean >> up_arg,\ >> 174 &__cleanup_info__); >> \ >> 175 { >> 176 >> 177 #define pthread_cleanup_pop(execute) >> \ >> 178 } >> \ >> 179 __pthread_cleanup_pop_imp(execute); >> \ >> 180 } -- DE From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 21:41:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18147106568B for ; Tue, 24 Nov 2009 21:41:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by mx1.freebsd.org (Postfix) with ESMTP id F1DCB8FC19 for ; Tue, 24 Nov 2009 21:41:13 +0000 (UTC) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 5C1F7E601C; Tue, 24 Nov 2009 21:41:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nAOLfAQa050429; Wed, 25 Nov 2009 08:41:10 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200911242141.nAOLfAQa050429@drugs.dv.isc.org> To: Kostik Belousov From: Mark Andrews References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> In-reply-to: Your message of "Tue, 24 Nov 2009 17:34:22 +0200." <20091124153422.GT2331@deviant.kiev.zoral.com.ua> Date: Wed, 25 Nov 2009 08:41:10 +1100 Sender: marka@isc.org Cc: FreeBSD Stable , Mikolaj Golub Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:41:14 -0000 In message <20091124153422.GT2331@deviant.kiev.zoral.com.ua>, Kostik Belousov write s: > > --i616tqyc3hrkKsk2 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote: > > On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote: > >=20 > > > Hi, > > > > > > I have problems with compiling our application under 8.0. > > > > > > It fails due to these definitions in pthread.h that look like a typo or > > > incorrectly applied patch: > > > > > > 170 #define pthread_cleanup_push(cleanup_routine, cleanup_a= > rg) \ > > > 171 { = > \ > > > 172 struct _pthread_cleanup_info __cleanup_= > info__; \ > > > 173 __pthread_cleanup_push_imp(cleanup_rout= > ine, cleanup_arg,\ > > > 174 &__cleanup_info__); = > \ > > > 175 { > > > 176=20 > > > 177 #define pthread_cleanup_pop(execute) = > \ > > > 178 } = > \ > > > 179 __pthread_cleanup_pop_imp(execute); = > \ > > > 180 } > > > > > > > > > This patch fixes the problem for me: > >=20 > > I was hurry when said that the patch fixed the problem. The application > > compiled but later it crashed in pthread_cleanup_pop: > >=20 > > (gdb) bt > > #0 0xbf4f9ee0 in ?? () > > #1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3 > > #2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3 > > #3 0x287d123c in pthread_exit () from /lib/libthr.so.3 > > #4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3 > > #5 0x00000000 in ?? () > >=20 > > So, I don't know what these macros actually were supposed to be. They were > > introduced in r179662: > >=20 > > Revision 1.43: download - view: text, markup, annotated - select for diffs > > Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu > > Branches: MAIN > > Diff to: previous 1.42: preferred, colored > > Changes since revision 1.42: +21 -2 lines > >=20 > > SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu > >=20 > > Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros, > > use stack space to keep cleanup information, this eliminates overhead of > > calling malloc() and free() in thread library. > >=20 > > Discussed on: thread@ > >=20 > > > --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 > > > +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 > > > @@ -172,10 +172,10 @@ > > > struct _pthread_cleanup_info __cleanup_info__; = > \ > > > __pthread_cleanup_push_imp(cleanup_routine, cle= > anup_arg,\ > > > &__cleanup_info__); = > \ > > > - { > > > + } =20 > > > =20 > > > #define pthread_cleanup_pop(execute) = > \ > > > - } = > \ > > > + { = > \ > > > __pthread_cleanup_pop_imp(execute); = > \ > > > } > > pthread_cleanup_push/pop are supposed to be used from the common > lexical scope. Citation from SUSv4: > > These functions may be implemented as macros. The application shall > ensure that they appear as statements, and in pairs within the same > lexical scope (that is, the pthread_cleanup_push() macro may be > thought to expand to a token list whose first token is '{' with > pthread_cleanup_pop() expanding to a token list whose last token is the > corresponding '}' ). > > Your change is wrong. > > Basically, the code should do > pthread_cleanup_push(some_func, arh); > something ... > pthread_cleanup_pop(1); > (1 denotes that some_func should be called). The problem is that that expands to C code that can only be used with newer C compilers. This expansion should be usable with all C compilers. #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \ { \ struct _pthread_cleanup_info __cleanup_info__; \ __pthread_cleanup_push_imp(cleanup_routine, cleanup _arg,\ &__cleanup_info__) #define pthread_cleanup_pop(execute) \ __pthread_cleanup_pop_imp(execute); \ } ((void)0) > > --i616tqyc3hrkKsk2 > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (FreeBSD) > > iEYEARECAAYFAksL/P4ACgkQC3+MBN1Mb4h4UwCgxIIHVqHBqU9wPIQKiOWf9g2z > r94AoOiN4CE6Eig6AlJ1IuHFo9Hk7Pvf > =FjUi > -----END PGP SIGNATURE----- > > --i616tqyc3hrkKsk2-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 21:53:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6509D1065670 for ; Tue, 24 Nov 2009 21:53:28 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id DF6C88FC0A for ; Tue, 24 Nov 2009 21:53:27 +0000 (UTC) Received: by bwz5 with SMTP id 5so6869471bwz.3 for ; Tue, 24 Nov 2009 13:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=av+cEImrfvDtKTHY+IMUINxQgrFSEyvX65uvM0jhBQQ=; b=ksl4LPaZe8u64QLfPknm0DaTZX2bnTiSpTlTH7IAzQuvo2JiSTkDpf/dvoZ59zx1rt L+wEnQ5XlKtG4adNR5motX3AXRPEKtwKuscxo9Qk9T8Mbov3WXZANXL1BuvWPkLyWDyv Ghdw751/o7idpUadzaaZr8NMmiiBT9WCvBddk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=iYHHaXVx3bXltj/2k7dmX7S9X2mGb4SsqYumEqEp8pftZcUlf9h2YgNfy2JfGuy5po aRUi5nrbWLVLnMMFgLtVUzLxOPBO0Z2oTxKYg5niNxT9f+0uppvT/+LyR9DHZbqdpbaH aYZyXWqALJgFwptY3rdksWa4L6yIy8ov6qLTs= MIME-Version: 1.0 Received: by 10.204.26.147 with SMTP id e19mr6667754bkc.149.1259099606392; Tue, 24 Nov 2009 13:53:26 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Nov 2009 00:53:26 +0300 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [geom] page fault in g_mbr_config() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:53:28 -0000 2009/7/24 pluknet : > 2009/7/24 pluknet : >> Hi. >> >> I got a panic while performing a repetitive =A0'fdisk -BI aacd0', >> where aacd0 is a disk on aac0: . >> This means that the command was issued after filesystems >> were already created on aacd (after the first fdisk -BI aacd0 >> iteration), and are in umount'ed state. >> >> This is on 7.2-R, amd64. Config is a GENERIC plus ddb, carp, ipfw, quota= . >> >> Fatal trap 12: page fault while in kernel mode >> cpuid =3D 5; apic id =3D 05 >> fault virtual address =A0 =3D 0x20 >> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read data, page not= present >> instruction pointer =A0 =A0 =3D 0x8:0xffffffff804cc554 >> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x10:0xfffffffe80079b80 >> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x10:0xfffffffe80079bd0 >> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x= 1b >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1= , def32 0, gran 1 >> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D = 0 >> current process =A0 =A0 =A0 =A0 =3D 2 (g_event) >> [thread pid 2 tid 100013 ] >> Stopped at =A0 =A0 =A0g_mbr_config+0x64: =A0 =A0 =A0movq =A0 =A00x20(%ra= x),%r15 >> db> bt >> Tracing pid 2 tid 100013 td 0xffffff000144da50 >> g_mbr_config() at g_mbr_config+0x64 >> g_run_events() at g_run_events+0x1b8 >> g_event_procbody() at g_event_procbody+0x57 >> fork_exit() at fork_exit+0x11f >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip =3D 0, rsp =3D 0xfffffffe80079d30, rbp =3D 0 --- > > And, of course... > > db> show proc 818 > Process 818 (fdisk) at 0xffffff0004ed1000: > =A0state: NORMAL > =A0uid: 0 =A0gids: 0, 0, 5 > =A0parent: pid 814 at 0xffffff00045c0478 > =A0ABI: FreeBSD ELF64 > =A0arguments: fdisk > =A0threads: 1 > 100169 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 D =A0 =A0 =A0 g_waitfo 0xfffff= f0004ec9100 fdisk > db> bt 818 > Tracing pid 818 tid 100169 td 0xffffff0004fbf6e0 > sched_switch() at sched_switch+0x1fe > mi_switch() at mi_switch+0x18e > sleepq_timedwait() at sleepq_timedwait+0x31 > _sleep() at _sleep+0x354 > g_waitfor_event() at g_waitfor_event+0x9a > g_ctl_ioctl() at g_ctl_ioctl+0x2df > giant_ioctl() at giant_ioctl+0x7d > devfs_ioctl_f() at devfs_ioctl_f+0x77 > kern_ioctl() at kern_ioctl+0xa2 > ioctl() at ioctl+0xf9 > syscall() at syscall+0x256 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x8008200ec, rsp =3D > 0x7fffffffe1d8, rbp =3D 0x4 --- > This makes me tied to GEOM_* -> GEOM_PART_* scheme (which is in 8+ in DEFAULTS now). After this replacement in DEFAULTS I see no more panics in 'fdisk -BI aacd0= '. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 22:11:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 855611065670 for ; Tue, 24 Nov 2009 22:11:58 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4E08FC1B for ; Tue, 24 Nov 2009 22:11:57 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so1771441eye.9 for ; Tue, 24 Nov 2009 14:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cml/A3r1sa5kH7/9rxF/VdbIin8bOTvmvT9bHE47gPI=; b=nZ7c22shqwjk7GdJi9r9BbQHB5ca7FdKE/jse5Q6JSSqKYvMTWZrN/hHJ5uJXzP323 KYaU2jAGywyx2MJJ99/aV8gAeFkVGCBDkKAs5FtglSFA2kowuGtjHbvQwx2WBGNel/1a NFxV5pxv8PFEWKcqSzD9Hhi+pUkwtw75vEHiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V7aq7KIEJkK/iEu78gkdt6YPVWug9ncL6aGB3C9Ry/VjLaVdhftoCFshHwC8KWtOYc E1uxusueo9q+3ZBFSEmvYKoVxw5PB7Sx4Nis7T/B4NUR6BRl/qGH55oY3tA1x3nN559q f2NTaXrQTQCkBEL7dgbMuBO7JZtzH0trHvscU= MIME-Version: 1.0 Received: by 10.216.88.85 with SMTP id z63mr344580wee.129.1259100716873; Tue, 24 Nov 2009 14:11:56 -0800 (PST) In-Reply-To: <5f67a8c40911222047m78ac7378i8a2016449d0d2996@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> <20091114024438.GA93630@icarus.home.lan> <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> <5f67a8c40911222047m78ac7378i8a2016449d0d2996@mail.gmail.com> Date: Tue, 24 Nov 2009 17:11:56 -0500 Message-ID: <5f67a8c40911241411l95e06ebya99270ac4eff17e3@mail.gmail.com> From: Zaphod Beeblebrox To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.x hang-on-boot on Dell 1950 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:11:58 -0000 On Sun, Nov 22, 2009 at 11:47 PM, Zaphod Beeblebrox wrote: > > > On Sun, Nov 22, 2009 at 9:09 PM, Zaphod Beeblebrox wrote: > >> >> >> On Fri, Nov 13, 2009 at 9:44 PM, Jeremy Chadwick < >> freebsd@jdc.parodius.com> wrote: >> >>> >>> > This 1950 may predate that a bit, but I'm not sure how to nail it down >>> > exactly, other than by it's hardware components. Anyways, 7.0 does the >>> same >>> > thing --- still wedged. >>> >>> I haven't seen anyone recommend this as a test method yet -- disabling >>> fdc prior to the kernel booting via the loader prompt: >>> >>> - Press 6 at the menu, >>> - At the loader prompt, type: >>> >>> set hint.fdc.0.disabled="1" >>> boot -v (or without -v; your choice) >>> >>> You shouldn't need to set hint.fd.0.disabled="1", since fd0 would >>> normally bind to fdc0; disable the latter and you disable the lesser. >>> >>> The intention here is to rule out the device attachment failures from >>> fdc as the source of the deadlock. >>> >> >> Entertainingly, it does not. Aparently that hint doesn't stop the code >> from trying to attach fdc0 when acpi says so. I suppose I need to know the >> console command to disable acpi and fdc. >> >> but it still wedges at "device_attach: fdc0 attach returned 6" with the >> above. >> >> > OK. With both floppy and acpi disabled, it dies calling "start_init" > several times, the last being /stand/sysinstal (which should work). I don't > see it "starting" the other CPUs. It hangs hard... no keyboard working (ie: > no caps lock). > > OK... I finally figured out what makes this Dell boot. The system as I got it has 2 dual core (Xeon) processors. If I remove one processor (so now it has one dual-core processor), Then the system boots !?! ... so there's something wrong with how FreeBSD is going multiprocessor (works with RedHat, it would appear) From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 22:20:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA814106566B for ; Tue, 24 Nov 2009 22:20:27 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 37FCA8FC1D for ; Tue, 24 Nov 2009 22:20:26 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id nAOMKPXx007425; Tue, 24 Nov 2009 17:20:25 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Tue, 24 Nov 2009 17:20:25 -0500 (EST) Date: Tue, 24 Nov 2009 17:20:25 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Mark Andrews In-Reply-To: <200911242141.nAOLfAQa050429@drugs.dv.isc.org> Message-ID: References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> <200911242141.nAOLfAQa050429@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , FreeBSD Stable , Mikolaj Golub Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:20:27 -0000 On Wed, 25 Nov 2009, Mark Andrews wrote: > > In message <20091124153422.GT2331@deviant.kiev.zoral.com.ua>, Kostik Belousov write > s: >> >> --i616tqyc3hrkKsk2 >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote: >> >> pthread_cleanup_push/pop are supposed to be used from the common >> lexical scope. Citation from SUSv4: >> >> These functions may be implemented as macros. The application shall >> ensure that they appear as statements, and in pairs within the same >> lexical scope (that is, the pthread_cleanup_push() macro may be >> thought to expand to a token list whose first token is '{' with >> pthread_cleanup_pop() expanding to a token list whose last token is the >> corresponding '}' ). >> >> Your change is wrong. >> >> Basically, the code should do >> pthread_cleanup_push(some_func, arh); >> something ... >> pthread_cleanup_pop(1); >> (1 denotes that some_func should be called). > > The problem is that that expands to C code that can only be used > with newer C compilers. This expansion should be usable with all > C compilers. > > #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \ > { \ > struct _pthread_cleanup_info __cleanup_info__; \ > __pthread_cleanup_push_imp(cleanup_routine, cleanup _arg,\ > &__cleanup_info__) > > #define pthread_cleanup_pop(execute) \ > __pthread_cleanup_pop_imp(execute); \ > } ((void)0) Hmm, agreed. But note that Solaris 10 does it this way: #define pthread_cleanup_push(routine, args) { \ _cleanup_t _cleanup_info; \ __pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \ (caddr_t)_getfp(), &_cleanup_info); #define pthread_cleanup_pop(ex) \ __pthread_cleanup_pop(ex, &_cleanup_info); \ } -- DE From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 22:30:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13622106568F; Tue, 24 Nov 2009 22:30:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by mx1.freebsd.org (Postfix) with ESMTP id EC1FB8FC12; Tue, 24 Nov 2009 22:30:24 +0000 (UTC) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 42713E6065; Tue, 24 Nov 2009 22:30:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id nAOMUKmh052215; Wed, 25 Nov 2009 09:30:20 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200911242230.nAOMUKmh052215@drugs.dv.isc.org> To: Daniel Eischen From: Mark Andrews References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> <200911242141.nAOLfAQa050429@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 24 Nov 2009 17:20:25 CDT." Date: Wed, 25 Nov 2009 09:30:20 +1100 Sender: marka@isc.org Cc: Kostik Belousov , FreeBSD Stable , Mikolaj Golub Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 22:30:25 -0000 In message , Daniel Eischen wri tes: > On Wed, 25 Nov 2009, Mark Andrews wrote: > > > > > In message <20091124153422.GT2331@deviant.kiev.zoral.com.ua>, Kostik Belous > ov write > > s: > >> > >> --i616tqyc3hrkKsk2 > >> Content-Type: text/plain; charset=us-ascii > >> Content-Disposition: inline > >> Content-Transfer-Encoding: quoted-printable > >> > >> On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote: > >> > >> pthread_cleanup_push/pop are supposed to be used from the common > >> lexical scope. Citation from SUSv4: > >> > >> These functions may be implemented as macros. The application shall > >> ensure that they appear as statements, and in pairs within the same > >> lexical scope (that is, the pthread_cleanup_push() macro may be > >> thought to expand to a token list whose first token is '{' with > >> pthread_cleanup_pop() expanding to a token list whose last token is the > >> corresponding '}' ). > >> > >> Your change is wrong. > >> > >> Basically, the code should do > >> pthread_cleanup_push(some_func, arh); > >> something ... > >> pthread_cleanup_pop(1); > >> (1 denotes that some_func should be called). > > > > The problem is that that expands to C code that can only be used > > with newer C compilers. This expansion should be usable with all > > C compilers. > > > > #define pthread_cleanup_push(cleanup_routine, cleanup_arg) > \ > > { \ > > struct _pthread_cleanup_info __cleanup_info__; \ > > __pthread_cleanup_push_imp(cleanup_routine, cleanup > _arg,\ > > &__cleanup_info__) > > > > #define pthread_cleanup_pop(execute) > \ > > __pthread_cleanup_pop_imp(execute); \ > > } ((void)0) > > Hmm, agreed. But note that Solaris 10 does it this way: > > #define pthread_cleanup_push(routine, args) { \ > _cleanup_t _cleanup_info; \ > __pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \ > (caddr_t)_getfp(), &_cleanup_info); > > #define pthread_cleanup_pop(ex) \ > __pthread_cleanup_pop(ex, &_cleanup_info); \ > } Writing portable macros that don't generate compiler warnings is fun. :-) Tricks like "do { } while (0)" and "{ } ((void)0)" absorb the pesky semi-colon. > -- > DE -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-stable@FreeBSD.ORG Tue Nov 24 23:09:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFD90106568D; Tue, 24 Nov 2009 23:09:40 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (server70.appriver.com [69.20.119.203]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADE98FC19; Tue, 24 Nov 2009 23:09:40 +0000 (UTC) X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note: TCH-CT/SI:0-26/SG:2 11/24/2009 6:09:27 PM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.758919 p=-0.912603 Source White X-Signature-Violations: 0-0-0-14325-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 107975677; Tue, 24 Nov 2009 18:09:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Nov 2009 15:08:59 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC USB/FS problem Thread-Index: AcprWqhOc0di4XCLQnutgxkzKDrTkwAg+g77AD9+WyAAHqRYgA== References: <200911221047.20362.hselasky@c2i.net> From: "Guojun Jin" To: "Hans Petter Selasky" , Cc: bugs@freebsd.org, freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:09:41 -0000 Interesting now by some incident :-) The single CPU machine (Intel P4) with 8.0 works fine on the USB drives and the USB stick. So, installed 8.0 on another AMD Turion64 HP Pavilion dv5210us Laptop, it comes the same problem -- accessing the USB hard drive causes system panic and reboot: Took the previously dump/restored USB drive and mount it on this Laptop, tried to remove the data before dump/restore, it crashed the system after=20 hit ^C and unplugged USB hard drive when the LED on USB hard drive becomes solid red and spiting out numbers of lines Operation not permitted=20 (the user is root, so this means accessing hard drive is not possible): rm: bin/... : Operation not permitted ...... A second try causes the system locks up After ^C. So, try to re-partitioning the USB hard drive on AMD laptop and dump/restore, partitioning passed, but dump/restore crashed. Since hw.usb.umass.debug=3D-1 does not tell a USB problem beside the RESET, What other debug shall we turn on to analyze this problem. -----Original Message----- From: Guojun Jin=20 Sent: Tuesday, November 24, 2009 12:13 AM To: Guojun Jin; Hans Petter Selasky; freebsd-usb@freebsd.org Cc: bugs@freebsd.org; freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem Freshly installed 8.0-RELEASE on two differnt machines, and USB stick work well so far, but the USB hard drive still has crash on this SMP (4-core AMD phenom 9600) during the dump/restore. I will try it on the single CPU machine tomorrow. Re-tested dump/restore with FreeBSD 6.3/6.4 on this SMP machine and they are working well. Also the another strange thing ocurred during the mount a partition on /tmp, which ended with two /tmp, and the last one mounted is on the top (the first should be hidden): : df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 756750 165484 530726 24% / devfs 1 1 0 100% /dev /dev/ad0s2e 43194318 27833648 11905126 70% /data /dev/ad0s2d 9135182 5870390 2533978 70% /home /dev/ad0s1e 507630 34882 432138 7% /tmp /dev/ad0s1f 13246730 1424522 10762470 12% /usr /dev/ad0s1d 5077038 12700 4658176 0% /var /dev/da0s2 661176 487660 120622 80% /mnt /dev/da1s3d 9135182 4 8404364 0% /dist /dev/da1s3e 74938948 4 68943830 0% /tmp : df /tmp Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da1s3e 74938948 4 68943830 0% /tmp -----Original Message----- From: Guojun Jin Sent: Sun 11/22/2009 7:59 PM To: Hans Petter Selasky; freebsd-usb@freebsd.org Cc: bugs@freebsd.org; freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem =20 >From more intensive diagnose, it looks like more related USB layer. repeated a few time on following process and ithe crash happened at different USB access phase at each time. dd if=3D/dev/zero of=3D/dev/da0 count=3D1000 bs=3D4k sysinstall partition=20 slice 1 (da0s1) 18GB ID=3D12 slice 2 (da0s2) 10-15GB Id=3D165 slice 3 (da0s3) rest ID=3D165 W ---> OK label da0s3d 9GB /mnt da0s3e rest /dist W ---> da0s3e ---- device is not configured. w# ll /dev/da0* # after sysinstall did partition + W at 1st time crw-r----- 1 root operator 0, 97 Nov 22 11:23 /dev/da0 crw-r----- 1 root operator 0, 98 Nov 22 11:23 /dev/da0s1 crw-r----- 1 root operator 0, 99 Nov 22 11:23 /dev/da0s2 crw-r----- 1 root operator 0, 100 Nov 22 11:23 /dev/da0s3 # ll /dev/da0* # after sysinstall start at 2nd time crw-r----- 1 root operator 0, 97 Nov 22 11:27 /dev/da0 System crashed The crash log is available at http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 (All logs are based on hw.usb.umass.debug=3D-1) After system reboot, and repeated above processes, the da0s3e was mounted on /dist, but da0s3d cannot. It tunred out that newfs fail inside labeling process in sysinstall. Manually did newfs on da0s3d, and it cannot be mounted on /mnt, but access to it caused crash. The crash log is available at http:/www.daemonfun.com/archives/pub/USB/newfs Tried entire process again, this time, both partitons are formatted (newfs) inside labaling process (sysinstall) but crahsed system during dump/restore on da0s3e (/dist). The crash log is available at http:/www.daemonfun.com/archives/pub/USB/usb-log.crash2.bz2, which is huge one. It contains two parts, one dump/restore IDE to da0s3d (passed), and the rest is dump/restore to da0s3e (crashed). I am going to reinstall the system with the new ISO from Nov 21 8.0-RELEASE to see if anything will improve. -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Sun 11/22/2009 1:47 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem =20 On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: > Tried on the USB hard drive: > > Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. > Was happy because successfully did dump/restore on s3d, and thought it just > partition format issue; but system crashed during dump/restore on s3e, and > partition lost the file system type. > > wolf# mount /dev/da0s3e /mnt > WARNING: /mnt was not properly dismounted > /mnt: mount pending error: blocks 35968 files 0 > wolf# fsck da0s3e > fsck: Could not determine filesystem type > wolf# bsdlabel da0s3 > # /dev/da0s3: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 175735035 0 unused 0 0 # "raw" part, > don't edi t > d: 18874368 0 4.2BSD 0 0 0 > e: 156860667 18874368 4.2BSD 0 0 0 > > Therefore, tried directly use fsck_ufs on both USB hard drive and USB stick > to get file system clean up. All data got back now. > > The machine has run with FreeBSD 6.1 all the way to 7.2 without such > problem. How can we determine what could go wrong in 8.0? FS or USB. Hi, Error 5 means IO error, so probably the transport layer, USB or lower, is to=20 blame. Some things to check: 1) Make sure the connection for your memory stick is Ok. 2) Make sure there is enough power for your memory stick. Regarding memory sticks: Other operating systems do a port bus reset when the device has a problem. On=20 FreeBSD we just try a software reset via the control endpoint. I guess that it=20 is a device problem you are seeing. The USB stack in FreeBSD is faster than=20 the old one, and maybe the faster queueing of mass storage requests trigger=20 some hidden bugs in your device. When the problem happens try: sysctl hw.usb.umass.debug=3D-1 --HPS From owner-freebsd-stable@FreeBSD.ORG Wed Nov 25 00:14:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D71106566C for ; Wed, 25 Nov 2009 00:14:22 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF938FC12 for ; Wed, 25 Nov 2009 00:14:21 +0000 (UTC) Received: by ewy21 with SMTP id 21so1183805ewy.13 for ; Tue, 24 Nov 2009 16:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=EeSwjB3RMje40OGet8irt0+RM1nnyPfa2Oi+ti4r7qk=; b=wnPhNweyTvHXsq8DxSH5MoSqrLtqgsgiu87u0IXkvoaD/oKvr+agKR26igJK96TMIy uJPfNfhuR3qqI6tN8dmhO2AL9HYjtrPgStYjNjM72ussix1XnTdEb8swkWwCJS/ZjfHc wgjJcVYFe4f3CZRCjGVZuEYw83G/4C6H5YSSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=HDp86Jp9GHb4mwOBECmwefpBF0rUWsPuiVw4VEFAHClJpgeVCCnE55daXkqKu65nlF 2Z4Tk/8ZGj4BIqk4WrodbnrWlaGHuPVgov/bPYJ/s2rxaGhP+DqXTkuiAUrqlEpZ1KyR hD7pqRmomavZ7oD/12Iuvy/hIhEsqfPy1hOjA= MIME-Version: 1.0 Received: by 10.216.86.16 with SMTP id v16mr2311391wee.162.1259106133128; Tue, 24 Nov 2009 15:42:13 -0800 (PST) Date: Tue, 24 Nov 2009 17:42:13 -0600 Message-ID: From: Don Wilde To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: sackcloth and ashes time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dwilde1@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:14:22 -0000 Dear FreeBSD friends; I recently added my gmail contacts to Linked-In, Inviting only those who were already on Linked-In, and discovered -- thanks to Bruce Cran -- that it came to STABLE. Looking in Linked-In at his profile, Mr Rotaev's public e-mail address address is clearly noted as being freebsd-stable@freebsd.org. I have requested that Linked-In customer service address the matter, as I cannot contact him without causing more of the same spam in your mailboxes. He does not appear to be an active Linked-In user. Thank you all in advance for your understanding! :D -- -- Don Wilde " Convince by Example " http://www.EngineeringJobFuture.com From owner-freebsd-stable@FreeBSD.ORG Wed Nov 25 01:56:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A78D11065694; Wed, 25 Nov 2009 01:56:37 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 920248FC1D; Wed, 25 Nov 2009 01:56:37 +0000 (UTC) Received: from apple.my.domain (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAP1uYOo064827; Wed, 25 Nov 2009 01:56:35 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4B0C8ED2.7030101@freebsd.org> Date: Wed, 25 Nov 2009 09:56:34 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Daniel Eischen References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> <200911242141.nAOLfAQa050429@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , FreeBSD Stable , Mikolaj Golub Subject: Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 01:56:37 -0000 Daniel Eischen wrote: > Hmm, agreed. But note that Solaris 10 does it this way: > > #define pthread_cleanup_push(routine, args) { \ > _cleanup_t _cleanup_info; \ > __pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \ > (caddr_t)_getfp(), &_cleanup_info); > > #define pthread_cleanup_pop(ex) \ > __pthread_cleanup_pop(ex, &_cleanup_info); \ > } > Hmm, I considered using this style, but if there is a C++ object within the lexical scope, its destructor will execute after pthread_cleanup_pop(), this may not be correct, so I used extra pair of '{}'. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 25 08:35:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39F1D10656C3; Wed, 25 Nov 2009 08:35:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 602628FC1C; Wed, 25 Nov 2009 08:35:32 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=LyfRj6cwWzvHMnOFOJMA:9 a=T-Vo3nG-Aqvxpwz43i1AfT4DWmwA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1350553548; Wed, 25 Nov 2009 09:35:31 +0100 From: Hans Petter Selasky To: "Guojun Jin" Date: Wed, 25 Nov 2009 09:37:06 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911250937.08267.hselasky@c2i.net> Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 08:35:34 -0000 On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote: > What other debug shall we turn on to analyze this problem. Are you able to extract the panic message? Try enabling dump on the swap partition. --HPS From owner-freebsd-stable@FreeBSD.ORG Wed Nov 25 11:34:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC695106566B for ; Wed, 25 Nov 2009 11:34:27 +0000 (UTC) (envelope-from rpalov@e-card.bg) Received: from e-card.bg (mail.e-card.bg [193.47.74.3]) by mx1.freebsd.org (Postfix) with SMTP id F29118FC18 for ; Wed, 25 Nov 2009 11:34:26 +0000 (UTC) Received: (qmail 34685 invoked by uid 89); 25 Nov 2009 11:07:29 -0000 Received: from unknown (HELO webbie.e-card.bg) (193.47.74.66) by mail.e-card.bg with SMTP; 25 Nov 2009 11:07:25 -0000 Message-ID: <4B0D0FEC.60409@e-card.bg> Date: Wed, 25 Nov 2009 13:07:24 +0200 From: =?windows-1252?Q?=3F=3F=3F=3F=3F_=3F=3F=3F=3F=3F?= Organization: E-CARD LTD. User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Zaphod Beeblebrox References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> <20091114024438.GA93630@icarus.home.lan> <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> <5f67a8c40911222047m78ac7378i8a2016449d0d2996@mail.gmail.com> <5f67a8c40911241411l95e06ebya99270ac4eff17e3@mail.gmail.com> In-Reply-To: <5f67a8c40911241411l95e06ebya99270ac4eff17e3@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on FaiLurE.e-card.bg X-Spam-Level: X-Spam-Status: No, score=-5.9 required=8.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: FreeBSD 7.x hang-on-boot on Dell 1950 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rpalov@e-card.bg List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 11:34:27 -0000 Hi all, I have dell 1950 / Single Xeon , 8G RAM , SAS Host without RAID / im my hands. Yesterday we have install FreeBSD7.2 AMD. After INITIAL install all works fine and next step was cvsup & base & kernel rebuild. This steps are also fine BUT after first reboot from SINGLE mode to MULTIUSER mode the system has the same strange behavior, like described in this thread: Very slow passed boot init on fdc0 and it has very very slow and strange responce in text consloe switching. So the server was inusable. Next step was to shutdown the server from power button and just boot-up again and it .. was fine: fdc0 is reported like this: "fdc0: does not respond" for less a second and normal booting processed is goin on. The server is working well and stable now. Zaphod Beeblebrox wrote: > On Sun, Nov 22, 2009 at 11:47 PM, Zaphod Beeblebrox wrote: > >> >> On Sun, Nov 22, 2009 at 9:09 PM, Zaphod Beeblebrox wrote: >> >>> >>> On Fri, Nov 13, 2009 at 9:44 PM, Jeremy Chadwick < >>> freebsd@jdc.parodius.com> wrote: >>> >>>>> This 1950 may predate that a bit, but I'm not sure how to nail it down >>>>> exactly, other than by it's hardware components. Anyways, 7.0 does the >>>> same >>>>> thing --- still wedged. >>>> I haven't seen anyone recommend this as a test method yet -- disabling >>>> fdc prior to the kernel booting via the loader prompt: >>>> >>>> - Press 6 at the menu, >>>> - At the loader prompt, type: >>>> >>>> set hint.fdc.0.disabled="1" >>>> boot -v (or without -v; your choice) >>>> >>>> You shouldn't need to set hint.fd.0.disabled="1", since fd0 would >>>> normally bind to fdc0; disable the latter and you disable the lesser. >>>> >>>> The intention here is to rule out the device attachment failures from >>>> fdc as the source of the deadlock. >>>> >>> Entertainingly, it does not. Aparently that hint doesn't stop the code >>> from trying to attach fdc0 when acpi says so. I suppose I need to know the >>> console command to disable acpi and fdc. >>> >>> but it still wedges at "device_attach: fdc0 attach returned 6" with the >>> above. >>> >>> >> OK. With both floppy and acpi disabled, it dies calling "start_init" >> several times, the last being /stand/sysinstal (which should work). I don't >> see it "starting" the other CPUs. It hangs hard... no keyboard working (ie: >> no caps lock). >> >> OK... I finally figured out what makes this Dell boot. The system as I got > it has 2 dual core (Xeon) processors. > > If I remove one processor (so now it has one dual-core processor), Then the > system boots !?! > > ... so there's something wrong with how FreeBSD is going multiprocessor > (works with RedHat, it would appear) > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Nov 25 12:00:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29E35106566C for ; Wed, 25 Nov 2009 12:00:11 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D07828FC0C for ; Wed, 25 Nov 2009 12:00:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NDGXY-0004qe-03 for freebsd-stable@freebsd.org; Wed, 25 Nov 2009 13:00:08 +0100 Received: from 85.173.92.192 ([85.173.92.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Nov 2009 13:00:07 +0100 Received: from dsh by 85.173.92.192 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Nov 2009 13:00:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Denis Shaposhnikov Date: Wed, 25 Nov 2009 14:55:23 +0300 Lines: 11 Message-ID: <20091125145523.6420d4a5@wizard.volgograd.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 85.173.92.192 X-Newsreader: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd7.2) Sender: news Subject: how to disable APM using camcontrol cmd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:00:11 -0000 Hello, I'm trying to replace sysutils/ataidle which doesn't work with new acpi(4). May be somebody could tell me args for camcontrol cmd ada0 -a cmd XX XX XX XX XX XX XX XX to disable APM and acoustic management (AAM) for my HDD? Thanks! From owner-freebsd-stable@FreeBSD.ORG Wed Nov 25 16:05:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0A11065679 for ; Wed, 25 Nov 2009 16:05:16 +0000 (UTC) (envelope-from npapke@acm.org) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1C08C8FC21 for ; Wed, 25 Nov 2009 16:05:15 +0000 (UTC) Received: from pd7ml1no-ssvc.prod.shaw.ca ([10.0.153.161]) by pd6mo1no-svcs.prod.shaw.ca with ESMTP; 25 Nov 2009 09:05:15 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=VF9RaR9bft6c8SsOr3WyFg==:17 a=rPscrj6gAAAA:8 a=N54-gffFAAAA:8 a=lvbMJxvVAAAA:8 a=uvToM1aP1EmNSNev-SMA:9 a=-89utvjrQBzkPOXryeWBhGD7bdcA:4 a=Bie_pJhHtn0A:10 a=nAPXUAfsBmEA:10 a=q7hC28v8Ol7pyxDI:21 a=ph2BSlT_2KPWd8_F:21 Received: from unknown (HELO proven.lan) ([24.85.241.34]) by pd7ml1no-dmz.prod.shaw.ca with ESMTP; 25 Nov 2009 09:05:15 -0700 Received: from proven.lan (localhost [127.0.0.1]) by proven.lan (8.14.3/8.14.3) with ESMTP id nAPG5EJ5046919 for ; Wed, 25 Nov 2009 08:05:14 -0800 (PST) (envelope-from npapke@acm.org) Received: (from npapke@localhost) by proven.lan (8.14.3/8.14.3/Submit) id nAPG5E9d046918 for freebsd-stable@freebsd.org; Wed, 25 Nov 2009 08:05:14 -0800 (PST) (envelope-from npapke@acm.org) X-Authentication-Warning: proven.lan: npapke set sender to npapke@acm.org using -f From: Norbert Papke To: freebsd-stable@freebsd.org Date: Wed, 25 Nov 2009 08:05:14 -0800 User-Agent: KMail/1.12.1 (FreeBSD/8.0-PRERELEASE; KDE/4.3.1; amd64; ; ) References: <200911241813.23616.hselasky@c2i.net> <20091124174714.GA2240@icarus.home.lan> In-Reply-To: <20091124174714.GA2240@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200911250805.14558.npapke@acm.org> Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:05:16 -0000 On November 24, 2009, Jeremy Chadwick wrote: > $ host www.daemonfun.com > www.daemonfun.com is an alias for daemonfun.com. > daemonfun.com has address 76.202.192.211 > daemonfun.com mail is handled by 10 mh1.daemonfun.com. > daemonfun.com mail is handled by 20 mh2.daemonfun.com. > > $ fetch http:/www.daemonfun.com/ > fetch: http:/www.daemonfun.com/: No address record > > I haven't examined the code, but my guess is fetch is trying to do a > lookup on the FQDN "http:/www.daemonfun.com/". Who wants to file a PR? As Dan Nelson mentioned, it's just a typo in the url. Try $ fetch http://www.daemonfun.com/ Note the "://" rather than ":/". Cheers. -- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From owner-freebsd-stable@FreeBSD.ORG Wed Nov 25 16:09:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAD9F106566B for ; Wed, 25 Nov 2009 16:09:10 +0000 (UTC) (envelope-from bsdlist@cogeco.ca) Received: from fipsb04.cogeco.net (smtp1.cogeco.ca [216.221.81.28]) by mx1.freebsd.org (Postfix) with ESMTP id 950E18FC12 for ; Wed, 25 Nov 2009 16:09:10 +0000 (UTC) X-SBRS: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncBANreDEsYlmz4/2dsb2JhbAAIxzgHjkiEMgSBcQ X-IronPort-AV: E=Sophos;i="4.47,286,1257138000"; d="scan'208";a="17210901" Received: from d24-150-108-248.home.cgocable.net (HELO [192.168.1.126]) ([24.150.108.248]) by fipsb04.cogeco.net with ESMTP; 25 Nov 2009 10:40:26 -0500 Message-ID: <4B0D501C.1070702@cogeco.ca> Date: Wed, 25 Nov 2009 10:41:16 -0500 From: Paul MacKenzie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Problem with running 6.X libraries on 7.2 with Apache X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:09:10 -0000 Hello, I have am having a problem which I am fairly sure I have traced to running 6.X based code on 7.2 with apache such as Wusage and Scomtherm. All runs fine on the server without these running and when I start the program the system spirals downwards only on http from what I can tell. It seems to be connected to PHP within apache in part. If I allow the system to run programs needing this code it causes problems with Apache taking 100% of the cpu. When I stop the program from accessing the old libraries the issue does not come back. FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #0: Wed Jul 1 09:36:28 EDT 2009 amd64 Apache setup: apache-2.2.13 TOP when the system has the problem visible: last pid: 1824; load averages: 207.55, 91.64, 38.50 up 7+11:03:23 08:55:20 755 processes: 236 running, 516 sleeping, 3 lock CPU: 11.2% user, 0.0% nice, 86.7% system, 2.0% interrupt, 0.1% idle Mem: 5617M Active, 8371M Inact, 1179M Wired, 244M Cache, 399M Buf, 433M Free Swap: 8192M Total, 648K Used, 8191M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1730 www 1 61 0 197M 41004K RUN 2 0:06 4.59% httpd 1475 www 1 -4 0 195M 39220K ufs 7 0:06 4.49% httpd 1732 www 1 -4 0 193M 38124K RUN 0 0:06 4.39% httpd 1651 www 1 -4 0 221M 59520K RUN 0 0:07 4.20% httpd 1653 www 1 -4 0 220M 59244K RUN 0 0:07 3.96% httpd 1609 www 1 -4 0 227M 64656K RUN 6 0:07 3.96% httpd 1431 www 1 -4 0 220M 59804K RUN 6 0:13 3.86% httpd 1568 www 1 -4 0 195M 39288K RUN 6 0:09 3.86% httpd 1572 www 1 -4 0 222M 61052K RUN 0 0:09 3.86% httpd 1585 www 1 -4 0 227M 64844K RUN 5 0:07 3.86% httpd 1681 www 1 64 0 220M 59368K RUN 3 0:07 3.86% httpd 1738 www 1 64 0 197M 40772K RUN 7 0:05 3.86% httpd 1648 www 1 67 0 210M 50628K RUN 6 0:08 3.76% httpd 1600 www 1 60 0 221M 59632K RUN 7 0:08 3.76% httpd 1622 www 1 -4 0 220M 59216K RUN 5 0:08 3.76% httpd 1619 www 1 -4 0 220M 58768K RUN 2 0:07 3.76% httpd I wondered if anyone else has had a similar problem or might be able to suggest a way to fix this? I am going to try an upgrade to the latest 7.2 shortly. Thanks, Paul From owner-freebsd-stable@FreeBSD.ORG Wed Nov 25 16:15:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62EAE1065697 for ; Wed, 25 Nov 2009 16:15:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 14DC98FC23 for ; Wed, 25 Nov 2009 16:15:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIfnDEuDaFvI/2dsb2JhbADWNoQyBA X-IronPort-AV: E=Sophos;i="4.47,286,1257138000"; d="scan'208";a="56807813" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 25 Nov 2009 11:15:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id EA7F394007B; Wed, 25 Nov 2009 11:15:42 -0500 (EST) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knFQOLgkJgxE; Wed, 25 Nov 2009 11:15:38 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 2725B9400E6; Wed, 25 Nov 2009 11:15:38 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id nAPGNqG06621; Wed, 25 Nov 2009 11:23:53 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 25 Nov 2009 11:23:52 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: =?utf-8?B?R2Vycml0IEvDvGhu?= In-Reply-To: <20091120132945.e2031bfb.gerrit@pmp.uni-hannover.de> Message-ID: References: <20091120132945.e2031bfb.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-959030623-1259166232=:4663" Cc: freebsd-stable@freebsd.org Subject: Re: zfs/nfs mkstemp() failure & subsequent hangs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:15:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-959030623-1259166232=:4663 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 20 Nov 2009, Gerrit K=C3=BChn wrote: > Hi all, > > I have a 8.0-PRERELEASE zfs/nfs server here that complains about i/o > errors when using rsync on a nfs client: > > rsync: mkstemp > "/usr/portage/metadata/cache/app-mobilephone/.ksms-0.1.2.4.BynVFw" failed= : > Input/output error (5) > > > I found this to be quite similar to kern/135412. However, this one > is said to be fixed and only applicable to 7-stable anyway. > Furthermore, after this happened, I tried to access files on the server > from the zfs filesystem concerned and found that I cannot access the fs > anymore. ls hangs in state zfs, so do mountd and zfs unmount. > > Questions: > Should I open a new PR for this? Gerrit reports that the fix recently committed to FreeBSD-current as r199616 (and will be MFC'd to stable/8 in about 2 weeks unless problems with it are reported) has fixed this problem. Thanks to Gerrit for reporting it and testing the fix, rick ---559023410-959030623-1259166232=:4663-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 25 17:42:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 357111065670; Wed, 25 Nov 2009 17:42:35 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (gwlb1.appriver.com [69.20.60.122]) by mx1.freebsd.org (Postfix) with ESMTP id B1B5F8FC1A; Wed, 25 Nov 2009 17:42:34 +0000 (UTC) X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note: TCH-CT/SI:0-175/SG:5 11/25/2009 12:41:38 PM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.777555 p=-0.911205 Source White X-Signature-Violations: 0-0-0-4980-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 108025808; Wed, 25 Nov 2009 12:42:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Nov 2009 09:35:44 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC USB/FS problem Thread-Index: AcptrLXhvnlwlhtHT/OlRRc5JWrzIgASQHSw References: <200911250937.08267.hselasky@c2i.net> From: "Guojun Jin" To: "Hans Petter Selasky" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: RE: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:42:35 -0000 I will do, I also borrowed two other machiens -- one AMD two core laptop, and one = P4 desktop -- for further testing. I will enable kernel coredump for all of them and will make cores = available by end of today. -Jin -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wed 11/25/2009 12:37 AM To: Guojun Jin Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; = freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem =20 On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote: > What other debug shall we turn on to analyze this problem. Are you able to extract the panic message? Try enabling dump on the swap = partition. --HPS From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 02:47:10 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8ECD106566B for ; Thu, 26 Nov 2009 02:47:10 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 380868FC1C for ; Thu, 26 Nov 2009 02:47:09 +0000 (UTC) Received: by qyk6 with SMTP id 6so157498qyk.3 for ; Wed, 25 Nov 2009 18:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:subject:date :mime-version:from:message-id:user-agent; bh=ejRBkWf5LZjP6XT7IvyiTCXKwWJMp5Bik3k5OtkcfdI=; b=vNb64DqRi542/mfTIdA32gVhZW7ZOZwzrw14bXmHkKYFhhohb8SG/qSuU/+HjZSRXR gc1EkuZyxlthKp5wyssG4pOKcZ3iEAeBaqER0NS6oyI40Z0SI02QBOXdiMHk2uWiXzsd zr1jMbb6p/oYpxJxjUuY2QTzugaYXCoVsz5RY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:subject:date:mime-version:from:message-id :user-agent; b=UuT+NOljfLDTLxhtPSsGTbMXHNKKP2LjO/p6v7w9YARbBBJK01ELeNlkY4vnRwlmfS hmEWyOofJcTV++kvvOo6IX+/MlZD7oOkcMrM6+SYNia3YwsIdEqfgclu7P+7Wx+QAJxD 1TgPMxuOTqFrbWjpbqLbIt9Voa+7lLxuW/auQ= Received: by 10.224.102.207 with SMTP id h15mr4420627qao.139.1259203629471; Wed, 25 Nov 2009 18:47:09 -0800 (PST) Received: from localhost (c-71-230-240-241.hsd1.pa.comcast.net [71.230.240.241]) by mx.google.com with ESMTPS id 21sm235629qyk.0.2009.11.25.18.47.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 18:47:07 -0800 (PST) Content-Type: multipart/mixed; boundary=----------qUGtupsUqelWsTC0XzBUch To: stable@freebsd.org Date: Wed, 25 Nov 2009 21:48:44 -0500 MIME-Version: 1.0 From: "Glen Barber" Message-ID: User-Agent: Opera Mail/10.10 (FreeBSD) Cc: Subject: [panic] 8.0-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 02:47:10 -0000 ------------qUGtupsUqelWsTC0XzBUch Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, This evening I experienced another panic on a Toshiba laptop on which I've been having excessive hang-up issues. This time, I was able to get a crash report (attached, with fstat output excluded because of the length). Any thoughts? -- Glen Barber ------------qUGtupsUqelWsTC0XzBUch Content-Disposition: attachment; filename=core.txt.5 Content-Type: application/octet-stream; name=core.txt.5 Content-Transfer-Encoding: Base64 cGVnYXN1cyBkdW1wZWQgY29yZSAtIHNlZSAvdmFyL2NyYXNoL3ZtY29yZS41CgpX ZWQgTm92IDI1IDIxOjMxOjI2IEVTVCAyMDA5CgpGcmVlQlNEIHBlZ2FzdXMgOC4w LVBSRVJFTEVBU0UgRnJlZUJTRCA4LjAtUFJFUkVMRUFTRSAjMTYgcjE5OTM0ME06 IE1vbiBOb3YgMTYgMjE6MDA6MzAgRVNUIDIwMDkgICAgIGdiYXJiZXJAcGVnYXN1 czovdXNyL29iai91c3Ivc3JjL3N5cy9QRUdBU1VTICBpMzg2CgpwYW5pYzogcGFn ZSBmYXVsdAoKR05VIGdkYiA2LjEuMSBbRnJlZUJTRF0KQ29weXJpZ2h0IDIwMDQg RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCkdEQiBpcyBmcmVlIHNvZnR3 YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwg YW5kIHlvdSBhcmUKd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5kL29yIGRpc3RyaWJ1 dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4KVHlwZSAi c2hvdyBjb3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuClRoZXJlIGlzIGFi c29sdXRlbHkgbm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFu dHkiIGZvciBkZXRhaWxzLgpUaGlzIEdEQiB3YXMgY29uZmlndXJlZCBhcyAiaTM4 Ni1tYXJjZWwtZnJlZWJzZCIuLi4KClVucmVhZCBwb3J0aW9uIG9mIHRoZSBrZXJu ZWwgbWVzc2FnZSBidWZmZXI6CgoKRmF0YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3 aGlsZSBpbiBrZXJuZWwgbW9kZQpjcHVpZCA9IDA7IGFwaWMgaWQgPSAwMApmYXVs dCB2aXJ0dWFsIGFkZHJlc3MJPSAweDdmZmZmZmZmCmZhdWx0IGNvZGUJCT0gc3Vw ZXJ2aXNvciB3cml0ZSwgcGFnZSBub3QgcHJlc2VudAppbnN0cnVjdGlvbiBwb2lu dGVyCT0gMHgyMDoweGMwODU3Y2NkCnN0YWNrIHBvaW50ZXIJICAgICAgICA9IDB4 Mjg6MHhlOWFlYjdkYwpmcmFtZSBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZTlh ZWI4MDQKY29kZSBzZWdtZW50CQk9IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0 eXBlIDB4MWIKCQkJPSBEUEwgMCwgcHJlcyAxLCBkZWYzMiAxLCBncmFuIDEKcHJv Y2Vzc29yIGVmbGFncwk9IGludGVycnVwdCBlbmFibGVkLCByZXN1bWUsIElPUEwg PSAwCmN1cnJlbnQgcHJvY2VzcwkJPSAxNTE1IChpbml0aWFsIHRocmVhZCkKdHJh cCBudW1iZXIJCT0gMTIKcGFuaWM6IHBhZ2UgZmF1bHQKY3B1aWQgPSAwClVwdGlt ZTogNDJtN3MKUGh5c2ljYWwgbWVtb3J5OiAyOTIzIE1CCkR1bXBpbmcgMjM2IE1C OiAyMjEgMjA1IDE4OSAxNzMgMTU3IDE0MSAxMjUgMTA5IDkzIDc3IDYxIDQ1IDI5 IDEzCgpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbGludXgua28u Li5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbGludXgua28uc3lt Ym9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJu ZWwvbGludXgua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL3Nu ZF9oZGEua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvc25k X2hkYS5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9y IC9ib290L2tlcm5lbC9zbmRfaGRhLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9i b290L2tlcm5lbC9zb3VuZC5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290 L2tlcm5lbC9zb3VuZC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5 bWJvbHMgZm9yIC9ib290L2tlcm5lbC9zb3VuZC5rbwpSZWFkaW5nIHN5bWJvbHMg ZnJvbSAvYm9vdC9rZXJuZWwvY29yZXRlbXAua28uLi5SZWFkaW5nIHN5bWJvbHMg ZnJvbSAvYm9vdC9rZXJuZWwvY29yZXRlbXAua28uc3ltYm9scy4uLmRvbmUuCmRv bmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvY29yZXRlbXAua28K UmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2lmX2l3bi5rby4uLlJl YWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9pZl9pd24ua28uc3ltYm9s cy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwv aWZfaXduLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9saW5w cm9jZnMua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbGlu cHJvY2ZzLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBm b3IgL2Jvb3Qva2VybmVsL2xpbnByb2Nmcy5rbwpSZWFkaW5nIHN5bWJvbHMgZnJv bSAvYm9vdC9rZXJuZWwvcGYua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9v dC9rZXJuZWwvcGYua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1i b2xzIGZvciAvYm9vdC9rZXJuZWwvcGYua28KUmVhZGluZyBzeW1ib2xzIGZyb20g L2Jvb3Qva2VybmVsL2l3bjUwMDBmdy5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9t IC9ib290L2tlcm5lbC9pd241MDAwZncua28uc3ltYm9scy4uLmRvbmUuCmRvbmUu CkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvaXduNTAwMGZ3LmtvClJl YWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9pOTE1LmtvLi4uUmVhZGlu ZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2k5MTUua28uc3ltYm9scy4uLmRv bmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvaTkxNS5r bwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvZHJtLmtvLi4uUmVh ZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2RybS5rby5zeW1ib2xzLi4u ZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9kcm0u a28KIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjI0NgoyNDYJcGNwdS5oOiBObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5LgoJaW4gcGNwdS5oCihrZ2RiKSAjMCAgZG9h ZHVtcCAoKSBhdCBwY3B1Lmg6MjQ2CiMxICAweGMwODllZTg3IGluIGJvb3QgKGhv d3RvPTI2MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjQx NgojMiAgMHhjMDg5ZjE3OSBpbiBwYW5pYyAoZm10PVZhcmlhYmxlICJmbXQiIGlz IG5vdCBhdmFpbGFibGUuCikgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0 ZG93bi5jOjU3OQojMyAgMHhjMGJkOWM4YyBpbiB0cmFwX2ZhdGFsIChmcmFtZT0w eGU5YWViNzljLCBldmE9MjE0NzQ4MzY0NykKICAgIGF0IC91c3Ivc3JjL3N5cy9p Mzg2L2kzODYvdHJhcC5jOjkzOAojNCAgMHhjMGJkOWY5MCBpbiB0cmFwX3BmYXVs dCAoZnJhbWU9MHhlOWFlYjc5YywgdXNlcm1vZGU9MCwgZXZhPTIxNDc0ODM2NDcp CiAgICBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzo4NTEKIzUgIDB4 YzBiZGFiNDUgaW4gdHJhcCAoZnJhbWU9MHhlOWFlYjc5YykgYXQgL3Vzci9zcmMv c3lzL2kzODYvaTM4Ni90cmFwLmM6NTMzCiM2ICAweGMwYmJjZTBiIGluIGNhbGx0 cmFwICgpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvZXhjZXB0aW9uLnM6MTY1 CiM3ICAweGMwODU3Y2NkIGluIGNsb25lX2NyZWF0ZSAoY2RwPTB4YzBlMTM3MjQs IGNzdz0weGMwZDlkZGUwLCAKICAgIHVwPTB4ZTlhZWI4MjgsIGRwPTB4ZTlhZWI4 YjgsIGV4dHJhPTApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2NvbmYu YzoxMDIzCiM4ICAweGMwYmIzZDQyIGluIGFwbV9jbG9uZSAoYXJnPTB4MCwgY3Jl ZD0weGM2ZWFlNDAwLCBuYW1lPTB4ZTlhZWI4ZjggImFwbSIsIAogICAgbmFtZWxl bj0zLCBkZXY9MHhlOWFlYjhiOCkgYXQgL3Vzci9zcmMvc3lzL2kzODYvYWNwaWNh L2FjcGlfbWFjaGRlcC5jOjIzOQojOSAgMHhjMDgyMWEzNSBpbiBkZXZmc19sb29r dXAgKGFwPTB4ZTlhZWI5ODApCiAgICBhdCAvdXNyL3NyYy9zeXMvZnMvZGV2ZnMv ZGV2ZnNfdm5vcHMuYzo4MTEKIzEwIDB4YzBiZTg1NjQgaW4gVk9QX0xPT0tVUF9B UFYgKHZvcD0weGMwZDYwNzgwLCBhPTB4ZTlhZWI5ODApCiAgICBhdCB2bm9kZV9p Zi5jOjEyMwojMTEgMHhjMDkxZjJiZSBpbiBsb29rdXAgKG5kcD0weGU5YWViYmEw KSBhdCB2bm9kZV9pZi5oOjU0CiMxMiAweGMwOTIwNTRmIGluIG5hbWVpIChuZHA9 MHhlOWFlYmJhMCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2xvb2t1cC5jOjI2 NAojMTMgMHhjMDkzOGI5MyBpbiB2bl9vcGVuX2NyZWQgKG5kcD0weGU5YWViYmEw LCBmbGFncD0weGU5YWViYzU4LCBjbW9kZT0wLCAKICAgIHZuX29wZW5fZmxhZ3M9 VmFyaWFibGUgInZuX29wZW5fZmxhZ3MiIGlzIG5vdCBhdmFpbGFibGUuCikgYXQg L3Vzci9zcmMvc3lzL2tlcm4vdmZzX3Zub3BzLmM6MTg4CiMxNCAweGMwOTM4ZTli IGluIHZuX29wZW4gKG5kcD0weGU5YWViYmEwLCBmbGFncD0weGU5YWViYzU4LCBj bW9kZT0wLCAKICAgIGZwPTB4Yzc1Yjg1NzgpIGF0IC91c3Ivc3JjL3N5cy9rZXJu L3Zmc192bm9wcy5jOjk0CiMxNSAweGMwOTM2ZTRmIGluIGtlcm5fb3BlbmF0ICh0 ZD0weGM3ZTVhOTAwLCBmZD0tMTAwLCAKICAgIHBhdGg9MHg4MDcwYTQwIDxBZGRy ZXNzIDB4ODA3MGE0MCBvdXQgb2YgYm91bmRzPiwgcGF0aHNlZz1VSU9fVVNFUlNQ QUNFLCAKICAgIGZsYWdzPTEsIG1vZGU9MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4v dmZzX3N5c2NhbGxzLmM6MTA4NAojMTYgMHhjMDkzNzM1NSBpbiBrZXJuX29wZW4g KHRkPTB4YzdlNWE5MDAsIAogICAgcGF0aD0weDgwNzBhNDAgPEFkZHJlc3MgMHg4 MDcwYTQwIG91dCBvZiBib3VuZHM+LCBwYXRoc2VnPVVJT19VU0VSU1BBQ0UsIAog ICAgZmxhZ3M9MCwgbW9kZT0wKSBhdCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3lz Y2FsbHMuYzoxMDM4CiMxNyAweGMwOTM3MzkwIGluIG9wZW4gKHRkPTB4YzdlNWE5 MDAsIHVhcD0weGU5YWViY2Y4KQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4vdmZz X3N5c2NhbGxzLmM6MTAxNAojMTggMHhjMGJkYTM5NSBpbiBzeXNjYWxsIChmcmFt ZT0weGU5YWViZDM4KQogICAgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90cmFw LmM6MTA3OAojMTkgMHhjMGJiY2VhMCBpbiBYaW50MHg4MF9zeXNjYWxsICgpCiAg ICBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjI2MQojMjAg MHgwMDAwMDAzMyBpbiA/PyAoKQpQcmV2aW91cyBmcmFtZSBpbm5lciB0byB0aGlz IGZyYW1lIChjb3JydXB0IHN0YWNrPykKKGtnZGIpIAoKLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCnBzIC1heGwKCiAgVUlEICAgUElEICBQUElEIENQVSBQUkkgTkkg ICBWU1ogICBSU1MgTVdDSEFOIFNUQVQgIFRUICAgICAgIFRJTUUgQ09NTUFORAog ICAgMCAgICAgMCAgICAgMCAgIDAgLTY4ICAwICAgICAwICAgICAwIC0gICAgICBE THMgICA/PyAgNDM5MTAzOToyMC4wMCBba2VybmVsXQogICAgMCAgICAgMSAgICAg MCAgIDAgIDQ0ICAwICAyOTEyICAgICAwIHdhaXQgICBETHMgICA/PyAgNzMzNzc6 MDAuMDAgW2luaXRdCiAgICAwICAgICAyICAgICAwICAgMCAgLTggIDAgICAgIDAg ICAgIDAgLSAgICAgIERMICAgID8/ICAyMTY2ODM6MzAuMDAgW2dfZXZlbnRdCiAg ICAwICAgICAzICAgICAwICAgMCAgLTggIDAgICAgIDAgICAgIDAgLSAgICAgIFJM ICAgID8/ICAxMDEwMjAzOjUwLjAwIFtnX3VwXQogICAgMCAgICAgNCAgICAgMCAg IDAgIC04ICAwICAgICAwICAgICAwIC0gICAgICBSTCAgICA/PyAgOTQ0OTE1OjMw LjAwIFtnX2Rvd25dCiAgICAwICAgICA1ICAgICAwICAgMCAtMTYgIDAgICAgIDAg ICAgIDAgY2NiX3NjIERMICAgID8/ICAgIDA6MDAuMDAgW3hwdF90aHJkXQogICAg MCAgICAgNiAgICAgMCAgIDAgLTE2ICAwICAgICAwICAgICAwIHdhaXRpbiBETCAg ICA/PyAgNTU3OjAwLjAwIFtzY3RwX2l0ZXJhCiAgICAwICAgICA3ICAgICAwICAg MCAtMTYgIDAgICAgIDAgICAgIDAgLSAgICAgIFJMICAgID8/ICAyNzIzOjEwLjAw IFtwYWdlZGFlbW9uCiAgICAwICAgICA4ICAgICAwICAgMCAtMTYgIDAgICAgIDAg ICAgIDAgcHNsZWVwIERMICAgID8/ICAgNjY6MjAuMDAgW3ZtZGFlbW9uXQogICAg MCAgICAgOSAgICAgMCAgIDAgIDc2ICAwICAgICAwICAgICAwIHBnemVybyBETCAg ICA/PyAgIDYzOjAwLjAwIFtwYWdlemVyb10KICAgIDAgICAgMTAgICAgIDAgICAw IC0xNiAgMCAgICAgMCAgICAgMCBhdWRpdF8gREwgICAgPz8gICAgMDowMC4wMCBb YXVkaXRdCiAgICAwICAgIDExICAgICAwICAgMCAxNzEgIDAgICAgIDAgICAgIDAg LSAgICAgIFJMICAgID8/ICAyMTEzMDIwMDo1Mi4wMCBbaWRsZV0KICAgIDAgICAg MTIgICAgIDAgICAwIC02MCAgMCAgICAgMCAgICAgMCAtICAgICAgV0wgICAgPz8g IDU4OTIyMTM6NTAuMDAgW2ludHJdCiAgICAwICAgIDEzICAgICAwICAgMCAtMTYg IDAgICAgIDAgICAgIDAgLSAgICAgIFJMICAgID8/ICAxMzA5MTc6MzAuMDAgW3lh cnJvd10KICAgIDAgICAgMTQgICAgIDAgICAwIC02NCAgMCAgICAgMCAgICAgMCAt ICAgICAgREwgICAgPz8gIDYzMTYzMTozMC4wMCBbdXNiXQogICAgMCAgICAxNSAg ICAgMCAgIDAgLTE2ICAwICAgICAwICAgICAwIHR6cG9sbCBETCAgICA/PyAgNjc5 OTA6MDAuMDAgW2FjcGlfdGhlcm0KICAgIDAgICAgMTYgICAgIDAgICAwIC0xNiAg MCAgICAgMCAgICAgMCBjb29saW4gREwgICAgPz8gICAgMDowMC4wMCBbYWNwaV9j b29saQogICAgMCAgICAxNyAgICAgMCAgIDAgIDQ0ICAwICAgICAwICAgICAwIHBz bGVlcCBETCAgICA/PyAgMTIwMTo0MC4wMCBbYnVmZGFlbW9uXQogICAgMCAgICAx OCAgICAgMCAgIDAgLTE2ICAwICAgICAwICAgICAwIC0gICAgICBSTCAgICA/PyAg MTIwMjowMC4wMCBbdm5scnVdCiAgICAwICAgIDE5ICAgICAwICAgMCAgNDQgIDAg ICAgIDAgICAgIDAgLSAgICAgIFJMICAgID8/ICA2NDU1OjIwLjAwIFtzeW5jZXJd CiAgICAwICAgIDIwICAgICAwICAgMCAgNDQgIDAgICAgIDAgICAgIDAgc2RmbHVz IERMICAgID8/ICA2MjI2OjIwLjAwIFtzb2Z0ZGVwZmx1CiAgICAwICAgIDIxICAg ICAwICAgMCAtMTYgIDAgICAgIDAgICAgIDAgZmxvd2NsIERMICAgID8/ICAzODk6 MDAuMDAgW2Zsb3djbGVhbmUKICAgIDAgICAgOTIgICAgIDAgICAwICAtOCAgMCAg ICAgMCAgICAgMCBtZHdhaXQgREwgICAgPz8gIDQ0OTcyNTozMC4wMCBbbWQxMDFd CiAgICAwICAgMzgwICAgICAxICAgMCAgNDQgIDAgIDUxNDAgICAgIDAgc2VsZWN0 IERzICAgID8/ICA3MDM5MzoyMC4wMCBbd3BhX3N1cHBsaQogICAgMCAgIDQzNCAg ICAgMCAgIDAgIDU1ICAwICAgICAwICAgICAwIHBmdG0gICBETCAgICA/PyAgODM1 OjIwLjAwIFtwZnB1cmdlXQogICAgMCAgIDUyNiAgICAgMSAgIDAgIDQ0ICAwICAx ODg4ICAgICAwIHNlbGVjdCBEcyAgICA/PyAgODA0MzozMC4wMCBbZGV2ZF0KICAg IDAgICA2NTcgICAgIDEgICAwICAgMSAgMCAgMzM0NCAgICAgMCAtICAgICAgUnMg ICAgPz8gIDI1MTMyODoxMC4wMCBbc3lzbG9nZF0KICAgNzAgICA4ODEgICAgIDEg ICAwICA0NCAgMCA0NzY5MiAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDUyNTAyODY6 NDAuMDAgW3Bvc3RncmVzXQogICAgMCAgIDkwMiAgICAgMSAgIDAgIDc2ICAwICAz Mjg0ICAgICAwIHNlbGVjdCBEcyAgICA/PyAgMTk3NzE6MzAuMDAgW2RoY2xpZW50 XQogICA2NSAgIDkxOCAgICAgMSAgIDAgIDQ0ICAwICAzMjg0ICAgICAwIHNlbGVj dCBEcyAgICA/PyAgODk5OTowMC4wMCBbZGhjbGllbnRdCiAgIDcwICAgOTIxICAg ODgxICAgMCAgNDQgIDAgNDc2OTIgICAgIDAgLSAgICAgIFJzICAgID8/ICAzNjAw NDowMC4wMCBbcG9zdGdyZXNdCiAgIDcwICAgOTIyICAgODgxICAgMCAgNDQgIDAg NDc2OTIgICAgIDAgLSAgICAgIFJzICAgID8/ICAxNjUwNDozMC4wMCBbcG9zdGdy ZXNdCiAgIDcwICAgOTIzICAgODgxICAgMCAgNDQgIDAgNDc2OTIgICAgIDAgLSAg ICAgIFJzICAgID8/ICAyMTcwNTo0MC4wMCBbcG9zdGdyZXNdCiAgIDcwICAgOTI0 ICAgODgxICAgMCAgNDQgIDAgMTE2NzYgICAgIDAgLSAgICAgIFJzICAgID8/ICAy MDMxNDozMC4wMCBbcG9zdGdyZXNdCiAgICAwICAgOTM4ICAgICAxICAgMCAgNDQg IDAgIDM0NDQgICAgIDAgc2VsZWN0IERzICAgID8/ICA0NDEzOjEwLjAwIFttb3Vz ZWRdCiAgICAwICAgOTY3ICAgICAxICAgMCAgNzYgIDAgIDY2NzYgICAgIDAgc2Vs ZWN0IERzICAgID8/ICAyMTY1MTowMC4wMCBbc3NoZF0KICAgIDAgICA5ODYgICAg IDEgICAwICA0NCAgMCAgOTk2NCAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDM1MjIz NzE6MTAuMDAgW2h0dHBkXQogICAgMCAgMTAyOCAgICAgMSAgIDAgIDQ0ICAwICAz MzcyICAgICAwIG5hbnNscCBEcyAgICA/PyAgNDY3MzM6MTAuMDAgW2Nyb25dCiAg IDgwICAxMTAzICAgOTg2ICAgMCAgNjEgIDAgIDk5NjQgICAgIDAgYWNjZXB0IEQg ICAgID8/ICAzMDkzNDo1MC4wMCBbaHR0cGRdCiAgIDgwICAxMTA0ICAgOTg2ICAg MCAgNjIgIDAgIDk5NjQgICAgIDAgYWNjZXB0IEQgICAgID8/ICAyMzAzOTowMC4w MCBbaHR0cGRdCiAgIDgwICAxMTA1ICAgOTg2ICAgMCAgNjEgIDAgIDk5NjQgICAg IDAgYWNjZXB0IEQgICAgID8/ICAyMjM1NDo1MC4wMCBbaHR0cGRdCiAgIDgwICAx MTA2ICAgOTg2ICAgMCAgNjIgIDAgIDk5NjQgICAgIDAgYWNjZXB0IEQgICAgID8/ ICAyMDMyMDowMC4wMCBbaHR0cGRdCiAgIDgwICAxMTA3ICAgOTg2ICAgMCAgNjIg IDAgIDk5NjQgICAgIDAgYWNjZXB0IEQgICAgID8/ICAyMTEwMjozMC4wMCBbaHR0 cGRdCiAgICAwICAxMjE2ICAgICAxICAgMCAgNDQgIDAgIDMzNDQgICAgIDAgc2Vs ZWN0IERzICAgID8/ICAxMDM4ODI6MjAuMDAgW3N5c2xvZ2RdCiAgICAwICAxMzI3 ICAgICAxICAgMCAgNDQgIDAgIDYwNzIgICAgIDAgLSAgICAgIFJzICAgID8/ICAz NTU2MjoyMC4wMCBbc2VuZG1haWxdCiAgIDI1ICAxMzMxICAgICAxICAgMCAgNDQg IDAgIDYwNzIgICAgIDAgcGF1c2UgIERzICAgID8/ICAyODY0MjowMC4wMCBbc2Vu ZG1haWxdCiAgICAwICAxMzM3ICAgICAxICAgMCAgNDQgIDAgIDMzNzIgICAgIDAg bmFuc2xwIERzICAgID8/ICA0MTQwMToyMC4wMCBbY3Jvbl0KICAgIDAgIDE0MTEg ICAgIDEgICAwICA3NiAgMCAgMzM0NCAgICAgMCB0dHlpbiAgRHMrICAgPz8gIDQ1 NDg2OjAwLjAwIFtnZXR0eV0KICAgIDAgIDE0MTIgICAgIDEgICAwICA3NiAgMCAg MzM0NCAgICAgMCB0dHlpbiAgRHMrICAgPz8gIDQxMDQyOjIwLjAwIFtnZXR0eV0K ICAgIDAgIDE0MTMgICAgIDEgICAwICA3NiAgMCAgMzM0NCAgICAgMCB0dHlpbiAg RHMrICAgPz8gIDQ1MDkxOjEwLjAwIFtnZXR0eV0KICAgIDAgIDE0MTQgICAgIDEg ICAwICA3NiAgMCAgMzM0NCAgICAgMCB0dHlpbiAgRHMrICAgPz8gIDM5ODU0OjIw LjAwIFtnZXR0eV0KICAgIDAgIDE0MTUgICAgIDEgICAwICA3NiAgMCAgMzM0NCAg ICAgMCB0dHlpbiAgRHMrICAgPz8gIDQwNjUzOjUwLjAwIFtnZXR0eV0KICAgIDAg IDE0MTYgICAgIDEgICAwICA3NiAgMCAgMzM0NCAgICAgMCB0dHlpbiAgRHMrICAg Pz8gIDQxMzQ4OjUwLjAwIFtnZXR0eV0KICAgIDAgIDE0MTcgICAgIDEgICAwICA3 NiAgMCAgMzM0NCAgICAgMCB0dHlpbiAgRHMrICAgPz8gIDQyNjcxOjAwLjAwIFtn ZXR0eV0KICAgIDAgIDE0MTggICAgIDEgICAwICA3NiAgMCAgMzM0NCAgICAgMCB0 dHlpbiAgRHMrICAgPz8gIDQxMjI3OjAwLjAwIFtnZXR0eV0KICAgIDAgIDE0MTkg ICAgIDEgICAwICA0NCAgMCAgNDg4OCAgICAgMCBzZWxlY3QgRCAgICAgPz8gICAg MDowMC4wMCBba2RtLWJpbl0KICAgIDAgIDE0MjIgIDE0MTkgICAwICA0NCAgMCAz ODY1NDQgICAgIDAgc2VsZWN0IEQgICAgID8/ICAgIDA6MDAuMDAgW1hvcmddCiAg ICAwICAxNDI1ICAxNDE5ICAgMCAgNDUgIDAgIDgwODQgICAgIDAgd2FpdCAgIEQg ICAgID8/ICAgIDA6MDAuMDAgW2tkbS1iaW5dCiAxMDAxICAxNDMzICAxNDI1ICAg MCAtODQgIDAgICAgIDAgICAgIDAgLSAgICAgIFpXICAgID8/ICAgIDA6MDAuMDAg PGRlZnVuY3Q+CiAxMDAxICAxNDM0ICAgICAxICAgMCAgNDQgIDAgIDYzNjQgICAg IDAgc2VsZWN0IERzICAgID8/ICAxOTI1NDoxMC4wMCBbc3NoLWFnZW50XQogMTAw MSAgMTQzNSAgMTQyNSAgIDAgIDc2ICAwICAzNjI0ICAgICAwIHdhaXQgICBEcyAg ICA/PyAgMzIxODQ3OjUwLjAwIFtzaF0KIDEwMDEgIDE0NzMgICAgIDEgICAwICA0 NCAgMCAgNTI4NCAgICAgMCBzZWxlY3QgRCAgICAgPz8gIDUyODMyMDU6MjAuMDAg W2dhbV9zZXJ2ZXIKIDEwMDEgIDE0ODcgICAgIDEgICAwICA0NSAgMCAyNjU0MCAg ICAgMCBzZWxlY3QgRHMgICAgPz8gIDE1NDYwMTY6NDAuMDAgW2tkZWluaXRdCiAx MDAxICAxNDkwICAgICAxICAgMCAgNDQgIDAgMjYxMTYgICAgIDAgc2VsZWN0IEQg ICAgID8/ICA3NzI1MTY6MjAuMDAgW2tkZWluaXRdCiAxMDAxICAxNDkyICAxNDg3 ICAgMCAgNDQgIDAgMjcyMjQgICAgIDAgc2VsZWN0IEQgICAgID8/ICA5MDY2Njg6 MzAuMDAgW2tkZWluaXRdCiAxMDAxICAxNDk0ICAgICAxICAgMCAgNDQgIDAgMjk4 NTIgICAgIDAgc2VsZWN0IEQgICAgID8/ICA4OTE1NjAzOjEwLjAwIFtrZGVpbml0 XQogMTAwMSAgMTQ5OSAgMTQzNSAgIDAgIDQ0ICAwICAzNDkyICAgICAwIC0gICAg ICBSICAgICA/PyAgMjEzODM3OjMwLjAwIFtrd3JhcHBlcl0KIDEwMDEgIDE1MDEg ICAgIDEgICAwICA0NCAgMCAyNzQzMiAgICAgMCBzZWxlY3QgRCAgICAgPz8gIDE0 MTE5ODQ6NDAuMDAgW2tkZWluaXRdCiAxMDAxICAxNTAyICAxNDg3ICAgMCAgNDQg IDAgMjkzMDQgICAgIDAgc2VsZWN0IEQgICAgID8/ICAxNTY1NDY0ODo1MC4wMCBb a2RlaW5pdF0KIDEwMDEgIDE1MDQgICAgIDEgICAwICA0NCAgMCAyOTQ4OCAgICAg MCBzZWxlY3QgRCAgICAgPz8gIDE1ODE2NjYxOjQwLjAwIFtrZGVpbml0XQogMTAw MSAgMTUwNiAgICAgMSAgIDAgIDQ0ICAwIDMyNDc2ICAgICAwIHNlbGVjdCBEICAg ICA/PyAgMjc3MTg0MzY6NTAuMDAgW2tkZWluaXRdCiAxMDAxICAxNTEwICAxNDg3 ICAgMCAgNjAgIDAgMTMxMjAgICAgIDAgLSAgICAgIFIgICAgID8/ICAxNzA0OTEz NToxMC4wMCBbYXJ0c2RdCiAxMDAxICAxNTEyICAgICAxICAgMCAgNDQgIDAgMjc0 NzIgICAgIDAgc2VsZWN0IEQgICAgID8/ICAxMTMwNzU2OjIwLjAwIFtrZGVpbml0 XQogMTAwMSAgMTUxNCAgICAgMSAgIDAgIDQ0ICAwIDI4NjY4ICAgICAwIHNlbGVj dCBEICAgICA/PyAgMzQwMTYyMjo0MC4wMCBba2RlaW5pdF0KIDEwMDEgIDE1MTUg IDE0ODcgICAwICA0NCAgMCAgNTkwOCAgICAgMCAtICAgICAgUiAgICAgPz8gIDE4 MzIyODQxOjEwLjAwIFtjb25reV0KIDEwMDEgMzMzMTQgICAgIDEgICAwICA0NCAg MCAzMDQwOCAgICAgMCBzZWxlY3QgRCAgICAgPz8gIDE0MjM6MDAuMDAgW2thdGFw dWx0XQogMTAwMSAzMzMxOSAgMTQ4NyAgIDAgIDQ0ICAwIDExOTA3MiAgICAgMCB1 Y29uZCAgRCAgICAgPz8gIDUxODU4OTo0MC4wMCBbb3BlcmFdCgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1zCgogIDc2NTkzODggY3B1IGNvbnRleHQg c3dpdGNoZXMKICAgNzg3NjQwIGRldmljZSBpbnRlcnJ1cHRzCiAgIDUxODQ5MSBz b2Z0d2FyZSBpbnRlcnJ1cHRzCiAgMjkzMjc1NCB0cmFwcwogMTg2ODA2NTggc3lz dGVtIGNhbGxzCiAgICAgICAyMyBrZXJuZWwgdGhyZWFkcyBjcmVhdGVkCiAgICAz MjM2MSAgZm9yaygpIGNhbGxzCiAgICAgMTcwNyB2Zm9yaygpIGNhbGxzCiAgICAg ICAgMCByZm9yaygpIGNhbGxzCiAgICAgICAgMCBzd2FwIHBhZ2VyIHBhZ2VpbnMK ICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZXMgcGFnZWQgaW4KICAgICAgICAwIHN3 YXAgcGFnZXIgcGFnZW91dHMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZXMgcGFn ZWQgb3V0CiAgICAgMjI0OCB2bm9kZSBwYWdlciBwYWdlaW5zCiAgICAxNzc1NSB2 bm9kZSBwYWdlciBwYWdlcyBwYWdlZCBpbgogICAgICAgIDAgdm5vZGUgcGFnZXIg cGFnZW91dHMKICAgICAgICAwIHZub2RlIHBhZ2VyIHBhZ2VzIHBhZ2VkIG91dAog ICAgICAgIDAgcGFnZSBkYWVtb24gd2FrZXVwcwogICAgICAgIDAgcGFnZXMgZXhh bWluZWQgYnkgdGhlIHBhZ2UgZGFlbW9uCiAgICAgMTI3MiBwYWdlcyByZWFjdGl2 YXRlZAogICA3NjI3MTMgY29weS1vbi13cml0ZSBmYXVsdHMKICAgICAzMDk1IGNv cHktb24td3JpdGUgb3B0aW1pemVkIGZhdWx0cwogIDEwOTcxNjMgemVybyBmaWxs IHBhZ2VzIHplcm9lZAogICAgNTUxMDMgemVybyBmaWxsIHBhZ2VzIHByZXplcm9l ZAogICAgICAyNDIgaW50cmFuc2l0IGJsb2NraW5nIHBhZ2UgZmF1bHRzCiAgMjQz Mjc1MSB0b3RhbCBWTSBmYXVsdHMgdGFrZW4KICAgICAgICAwIHBhZ2VzIGFmZmVj dGVkIGJ5IGtlcm5lbCB0aHJlYWQgY3JlYXRpb24KICA2MDg4NjIyIHBhZ2VzIGFm ZmVjdGVkIGJ5ICBmb3JrKCkKICAgMjg3NzY0IHBhZ2VzIGFmZmVjdGVkIGJ5IHZm b3JrKCkKICAgICAgICAwIHBhZ2VzIGFmZmVjdGVkIGJ5IHJmb3JrKCkKICAgICAx NjgxIHBhZ2VzIGNhY2hlZAogIDIyNjQ3NDcgcGFnZXMgZnJlZWQKICAgICAgICAw IHBhZ2VzIGZyZWVkIGJ5IGRhZW1vbgogIDE2MDQyMjEgcGFnZXMgZnJlZWQgYnkg ZXhpdGluZyBwcm9jZXNzZXMKICAgIDI5NDg4IHBhZ2VzIGFjdGl2ZQogICAgOTIx MjcgcGFnZXMgaW5hY3RpdmUKICAgICAgMjg2IHBhZ2VzIGluIFZNIGNhY2hlCiAg ICA0MTkwOSBwYWdlcyB3aXJlZCBkb3duCiAgIDU3MTEzMyBwYWdlcyBmcmVlCiAg ICAgNDA5NiBieXRlcyBwZXIgcGFnZQogIDI2OTE5MDEgdG90YWwgbmFtZSBsb29r dXBzCiAgICAgICAgICBjYWNoZSBoaXRzICg4OCUgcG9zICsgNiUgbmVnKSBzeXN0 ZW0gMCUgcGVyLWRpcmVjdG9yeQogICAgICAgICAgZGVsZXRpb25zIDElLCBmYWxz ZWhpdHMgMCUsIHRvb2xvbmcgMCUKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2 bXN0YXQgLW0KCiAgICAgICAgIFR5cGUgSW5Vc2UgTWVtVXNlIEhpZ2hVc2UgUmVx dWVzdHMgIFNpemUocykKICBwZnNfdm5jYWNoZSAgICAgNyAgICAgMUsgICAgICAg LSAgICAgICAgOSAgMzIKICAgICBwY2lfbGluayAgICAxNiAgICAgMksgICAgICAg LSAgICAgICAxNiAgMzIsMTI4CiAgICAgICAgIEdFT00gICAgOTcgICAgMjVLICAg ICAgIC0gICAgICA2NTIgIDE2LDMyLDY0LDEyOCw1MTIsMTAyNCwyMDQ4CiAgICAg ICBpc2FkZXYgICAgMTAgICAgIDFLICAgICAgIC0gICAgICAgMTAgIDY0CiAgICBh Y3BpX3BlcmYgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDEyOAogICAg ICAgICBjZGV2ICAgIDExICAgICAySyAgICAgICAtICAgICAgIDExICAxMjgKICAg ICAgYWNwaXB3ciAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMzIKICAg ICAgICBzaWdpbyAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMzIKICAg ICBmaWxlZGVzYyAgIDEwMiAgICA2N0sgICAgICAgLSAgICAzNDEzNiAgMTYsMzIs NjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAga2R0cmFjZSAgIDI3 MCAgICA1NEsgICAgICAgLSAgICAzNDM2NyAgNjQsMjU2CiAgICAgICAgIGtlbnYg ICAgODUgICAgIDdLICAgICAgIC0gICAgICAgOTIgIDE2LDMyLDY0LDEyOCw0MDk2 CiAgICAgICBrcXVldWUgICAgMTIgICAgMTRLICAgICAgIC0gICAgICAxOTQgIDEy OCwxMDI0LDIwNDgsNDA5NgogICAgICAga2JkbXV4ICAgICA2ICAgIDEwSyAgICAg ICAtICAgICAgICA2ICAxNiwyNTYsMTAyNCwyMDQ4LDQwOTYKICAgIHByb2MtYXJn cyAgICA0OCAgICAgM0sgICAgICAgLSAgICAyMTE1MyAgMTYsMzIsNjQsMTI4LDI1 NgogICAgICBpdGhyZWFkICAgIDgyICAgICA3SyAgICAgICAtICAgICAgIDgyICAx Niw2NCwxMjgKICAgICAgIHByaXNvbiAgICAgMyAgICAgM0sgICAgICAgLSAgICAg ICAgMyAgMTYsMjU2LDIwNDgKICAgICAgbWRfZGlzayAgICAgMSAgICAgMksgICAg ICAgLSAgICAgICAgMSAgMjA0OAogICAgICAgS1RSQUNFICAgMTAwICAgIDEzSyAg ICAgICAtICAgICAgMTAwICAxMjgKICAgICAgIGxpbmtlciAgIDE3MCAgIDc3M0sg ICAgICAgLSAgICAgIDMwOCAgMTYsMzIsMjU2LDEwMjQsNDA5NgogICAgICAgIGxv Y2tmICAgIDYyICAgICA0SyAgICAgICAtICAgIDEzMzQ2ICAzMiw2NAogICAgICAg aXA2bmRwICAgICA1ICAgICAxSyAgICAgICAtICAgICAgICA1ICA2NCwxMjgKICAg ICAgICAgdGVtcCAgICAzOCAgIDI0M0sgICAgICAgLSAgICA1NjU3OCAgMTYsMzIs NjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgIGRldmJ1ZiAgNDk3 NyAgNTk0MEsgICAgICAgLSAgICAgNTEyNiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIs MTAyNCwyMDQ4LDQwOTYKICAgICAgIG1vZHVsZSAgIDQ3NSAgICAzMEsgICAgICAg LSAgICAgIDQ3NSAgNjQsMTI4CiAgICAgbXR4X3Bvb2wgICAgIDIgICAgIDhLICAg ICAgIC0gICAgICAgIDIgIDQwOTYKICAgICAgICAgIGFncCAgICAgMiAgICAgMUsg ICAgICAgLSAgICAgICAgMiAgMTYsNjQKICAgICAgICAgIG9zZCAgICAgMyAgICAg MUsgICAgICAgLSAgICAgICAgMyAgMTYsMzIKICAgICAgc3VicHJvYyAgIDIxMCAg IDM0MksgICAgICAgLSAgICAzNDIyNSAgMjU2LDQwOTYKICAgICAgICAgcHJvYyAg ICAgMiAgICAgOEsgICAgICAgLSAgICAgICAgMiAgNDA5NgogICAgICBzZXNzaW9u ICAgIDMyICAgICAySyAgICAgICAtICAgICAgMTEwICA2NAogICAgICAgICBwZ3Jw ICAgIDMzICAgICAzSyAgICAgICAtICAgICAgMTU1ICA2NAogICAgICAgICBjcmVk ICAgIDY0ICAgICA2SyAgICAgICAtICAgNTU1OTM0ICA2NCwxMjgKICAgICAgdWlk aW5mbyAgICAgNyAgICAgMksgICAgICAgLSAgICAgICAzOCAgNjQsMTAyNAogICAg ICAgcGxpbWl0ICAgIDE3ICAgICA1SyAgICAgICAtICAgICAgNjI1ICAyNTYKICAg ICAgIGFjcGljYSAgMzkwNCAgIDE5NEsgICAgICAgLSAgIDIwMzk5MyAgMTYsMzIs NjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4CiAgICBzeXNjdGx0bXAgICAgIDAgICAg IDBLICAgICAgIC0gICAgIDE3ODMgIDE2LDMyLDY0LDEyOAogICAgc3lzY3Rsb2lk ICAzOTExICAgMTIxSyAgICAgICAtICAgICA0MDE1ICAxNiwzMiw2NCwxMjgKICAg ICAgIHN5c2N0bCAgICAgMCAgICAgMEsgICAgICAgLSAgICAyMDA3NiAgMTYsMzIs NjQKICAgICAgY2FsbG91dCAgICAgMSAgIDI1NksgICAgICAgLSAgICAgICAgMSAg CiAgICAgICAgIHVtdHggICAyMjQgICAgMTRLICAgICAgIC0gICAgICAyMjQgIDY0 CiAgICAgcDEwMDMuMWIgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDE2 CiAgICAgICAgIFNXQVAgICAgIDIgICA1NDlLICAgICAgIC0gICAgICAgIDIgIDY0 CiAgICAgYWNwaXRhc2sgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDEw MjQKICAgICAgIGJ1cy1zYyAgICA4NCAgIDMwNEsgICAgICAgLSAgICAgNDQ5NiAg MTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAgIGJ1 cyAgMTI2OCAgICA1OEsgICAgICAgLSAgICAxMzgyOSAgMTYsMzIsNjQsMTI4LDUx MiwxMDI0CiAgICAgIGRldnN0YXQgICAgIDYgICAgMTNLICAgICAgIC0gICAgICAg IDYgIDE2LDQwOTYKIGV2ZW50aGFuZGxlciAgICA5MyAgICAgNUsgICAgICAgLSAg ICAgICA5MyAgMzIsNjQsMTI4CiAgICAgIENBTSBTSU0gICAgIDEgICAgIDFLICAg ICAgIC0gICAgICAgIDEgIDEyOAogICAgICAgICBrb2JqICAgMzM3ICAgNjc0SyAg ICAgICAtICAgICAgNDI3ICAyMDQ4CiAgICAgIFBlci1jcHUgICAgIDEgICAgIDFL ICAgICAgIC0gICAgICAgIDEgIDE2CiAgICAgICAgIHJtYW4gICAxNzMgICAgMTFL ICAgICAgIC0gICAgICA3MDEgIDE2LDMyLDY0CiAgICAgIGFjcGlzZW0gICAgMzYg ICAgIDVLICAgICAgIC0gICAgICAgMzYgIDY0LDEyOAogICAgICAgICBzYnVmICAg ICAwICAgICAwSyAgICAgICAtICAgICAgNDE0ICAxNiwzMiw2NCwxMjgsMjU2LDUx MiwxMDI0LDIwNDgsNDA5NgogICAgICBDQU0gWFBUICAgIDExICAgICAySyAgICAg ICAtICAgICAgIDMwICAxNiwzMiw2NCwxMDI0CiAgIENBTSBwZXJpcGggICAgIDIg ICAgIDFLICAgICAgIC0gICAgICAgMTEgIDE2LDMyLDY0LDEyOAogICAgICAgIHN0 YWNrICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAyICAxMjgKICAgIHRhc2tx dWV1ZSAgICAxMyAgICAgMUsgICAgICAgLSAgICAgICAxMyAgMTYsNjQKICAgICAg IFVuaXRubyAgICAxMiAgICAgMUsgICAgICAgLSAgICAgMzE1MCAgMTYsNjQKICAg ICAgICAgIGlvdiAgICAgMCAgICAgMEsgICAgICAgLSAgIDU2Njk4NiAgMTYsNjQs MTI4LDI1NgogICAgICAgc2VsZWN0ICAgIDc1ICAgICA1SyAgICAgICAtICAgICAg IDc1ICA2NAogICAgIGlvY3Rsb3BzICAgICAwICAgICAwSyAgICAgICAtICAzNjY0 NjUxICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAg ICAgbXNnICAgICA0ICAgIDI1SyAgICAgICAtICAgICAgICA0ICAxMDI0LDQwOTYK ICAgICAgICAgIHNlbSAgICAgNCAgICA2NEsgICAgICAgLSAgICAgICAgNCAgCiAg ICAgICAgICBzaG0gICAgIDggICAgMTlLICAgICAgIC0gICAgICAgNTIgIDEwMjQK ICAgICAgICAgIHR0eSAgICAyMSAgICAxMUsgICAgICAgLSAgICAgICAyNiAgNTEy LDEwMjQKICAgICAgICAgIHB0cyAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAg NSAgMTI4CiAgICAgbWJ1Zl90YWcgICAgNDYgICAgIDNLICAgICAgIC0gICAgNzc4 NzYgIDMyLDY0CiAgICAgICAgIGtzZW0gICAgIDEgICAgIDRLICAgICAgIC0gICAg ICAgIDEgIDQwOTYKICAgICAgICBzaG1mZCAgICAgMSAgICAgNEsgICAgICAgLSAg ICAgICAgMSAgNDA5NgogICAgICAgICAgcGNiICAgIDI3ICAgIDc5SyAgICAgICAt ICAgICAgMjg4ICAxNiw2NCw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgIHNvbmFt ZSAgICA1MiAgICAgNksgICAgICAgLSAgICAgMTk1NCAgMTYsMzIsNjQsMTI4CiAg ICAgICAgICBhY2wgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAyMDcgIDQwOTYK ICAgICAgIGJpb2J1ZiAgIDE1NyAgIDMxNEsgICAgICAgLSAgICAgMjE3NSAgMjA0 OAogICAgIHZmc2NhY2hlICAgICAxICAgNTEySyAgICAgICAtICAgICAgICAxICAK ICAgY2xfc2F2ZWJ1ZiAgICAgMCAgICAgMEsgICAgICAgLSAgICAgMjA1MSAgMzIs NjQKICAgICB2ZnNfaGFzaCAgICAgMSAgIDI1NksgICAgICAgLSAgICAgICAgMSAg CiAgICAgICB2bm9kZXMgICAgIDQgICAgIDFLICAgICAgIC0gICAgICAgIDQgIDMy LDEyOAogIHZub2RlbWFya2VyICAgICAwICAgICAwSyAgICAgICAtICAgICAxMzEy ICA1MTIKICAgICAgICBtb3VudCAgIDE1MCAgICAgNksgICAgICAgLSAgICAgIDIy MiAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0CiAgICAgICAgICBCUEYgICAgMTMgICAg NzRLICAgICAgIC0gICAgICAgMTQgIDE2LDY0LDEyOCwyNTYsNDA5NgogIGV0aGVy X211bHRpICAgIDM4ICAgICAySyAgICAgICAtICAgICAgIDU2ICAxNiwzMiw2NAog ICAgICAgaWZhZGRyICAgMTg4ICAgIDE4SyAgICAgICAtICAgICAgMTg5ICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwyMDQ4CiAgICAgICAgaWZuZXQgICAgIDUgICAgIDVL ICAgICAgIC0gICAgICAgIDUgIDY0LDEwMjQKICAgICAgICBjbG9uZSAgICAgNSAg ICAyMEsgICAgICAgLSAgICAgICAgNSAgNDA5NgogICAgICAgYXJwY29tICAgICAy ICAgICAxSyAgICAgICAtICAgICAgICAyICAxNgogICAgICBsbHRhYmxlICAgIDE1 ICAgICA0SyAgICAgICAtICAgICAgIDE1ICAxMjgsMjU2CiAgYXRhX2dlbmVyaWMg ICAgIDIgICAgIDJLICAgICAgIC0gICAgICAgIDIgIDEwMjQKICAgIGFkX2RyaXZl ciAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMzIKICAgIGFyX2RyaXZl ciAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgNiAgNTEyLDIwNDgKICAgYWNk X2RyaXZlciAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0OAogICAg IHJvdXRldGJsICAgIDYxICAgMjYxSyAgICAgICAtICAgICAxMTU1ICAxNiwzMiw2 NCwxMjgsMjU2LDUxMgogICAgIDgwMjExdmFwICAgICAxICAgICA0SyAgICAgICAt ICAgICAgICAxICA0MDk2CiAgODAyMTFjcnlwdG8gICAgIDIgICAgIDFLICAgICAg IC0gICAgICAgIDIgIDUxMgogICAgIDgwMjExY29tICAgICAxICAgICA4SyAgICAg ICAtICAgICAgICAxICAKICA4MDIxMW5vZGVpZSAgICAxMCAgICAgMksgICAgICAg LSAgICAgICAxMiAgMzIsNjQsMTI4LDI1NgogICAgODAyMTFub2RlICAgICAxICAg ICA4SyAgICAgICAtICAgICAgICAyICAKICAgIDgwMjExc2NhbiAgICAxMCAgICAg NksgICAgICAgLSAgICAgICAxMCAgMjU2LDIwNDgKICAgICAgICAgaWdtcCAgICAg NCAgICAgMUsgICAgICAgLSAgICAgICAgNCAgMTI4CiAgICAgIGVudHJvcHkgIDEw MjQgICAgNjRLICAgICAgIC0gICAgIDEwMjQgIDY0CiAgaXBfbW9wdGlvbnMgICAg IDggICAgIDFLICAgICAgIC0gICAgICAgIDggIDMyLDEyOAogICAgIGluX211bHRp ICAgICA1ICAgICAxSyAgICAgICAtICAgICAgICA2ICAxMjgKICAgaW5fbWZpbHRl ciAgICAgNCAgICAgMksgICAgICAgLSAgICAgICAgNCAgNTEyCiAgICBzY3RwX2l0 ZXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDQgIDEyOAogICAgIHNjdHBf aWZuICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAxMjgKICAgICBzY3Rw X2lmYSAgICAgNSAgICAgMUsgICAgICAgLSAgICAgICAgNSAgMTI4CiAgICAgc2N0 cF92cmYgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICBzY3Rw X2FfaXQgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDQgIDE2CiAgICBob3N0 Y2FjaGUgICAgIDEgICAgMTZLICAgICAgIC0gICAgICAgIDEgIAogICAgIHN5bmNh Y2hlICAgICAxICAgIDcySyAgICAgICAtICAgICAgICAxICAKICAgICAgYWNwaWRl diAgICA5MyAgICAgM0sgICAgICAgLSAgICAgICA5MyAgMzIKICAgIGluNl9tdWx0 aSAgICAxMiAgICAgMksgICAgICAgLSAgICAgICAxMiAgMTYsMjU2CiAgICAgICAg ICBtbGQgICAgIDQgICAgIDFLICAgICAgIC0gICAgICAgIDQgIDEyOAogICAgICBO RlMgRkhBICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAxMDI0CiAgICAg ICAgICBycGMgICAgIDIgICAgIDVLICAgICAgIC0gICAgICAgIDIgIDEyOCw0MDk2 CmF1ZGl0X2V2Y2xhc3MgICAxNzIgICAgIDNLICAgICAgIC0gICAgICAyMTEgIDE2 CiAgICAgc2F2ZWRpbm8gICAgIDAgICAgIDBLICAgICAgIC0gICAgIDI5OTggIDI1 NgogICAgbmV3ZGlyYmxrICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDk3ICAz MgogICAgICAgZGlycmVtICAgICAxICAgICAxSyAgICAgICAtICAgIDE5NTg2ICAz MgogICAgICAgIG1rZGlyICAgICAwICAgICAwSyAgICAgICAtICAgICA0MzUwICAz MgogICAgICAgZGlyYWRkICAgICAxICAgICAxSyAgICAgICAtICAgIDE4ODgyICA2 NAogICAgIGZyZWVmaWxlICAgIDE0ICAgICAxSyAgICAgICAtICAgIDE3ODQ0ICAz MgogICAgIGZyZWVibGtzICAgIDE0ICAgICA0SyAgICAgICAtICAgIDE3ODc4ICAy NTYKICAgICBmcmVlZnJhZyAgICAgMSAgICAgMUsgICAgICAgLSAgICAxMzMwOSAg MzIKICAgYWxsb2NpbmRpciAgICAgMSAgICAgMUsgICAgICAgLSAgICAxNjU1NCAg NjQKICAgICBpbmRpcmRlcCAgICAgMiAgICAgMUsgICAgICAgLSAgICAgOTAwOCAg MzIKICBhbGxvY2RpcmVjdCAgICAgMSAgICAgMUsgICAgICAgLSAgICA1NjIzNSAg MTI4CiAgICBibXNhZmVtYXAgICAgIDEgICAgIDFLICAgICAgIC0gICAgIDYwODIg IDY0CiAgICAgICBuZXdibGsgICAgIDEgICAgIDFLICAgICAgIC0gICAgNzI3OTAg IDY0LDI1NgogICAgIGlub2RlZGVwICAgIDE3ICAgMjU4SyAgICAgICAtICAgIDMy MTk4ICAxMjgKICAgICAgcGFnZWRlcCAgICAgMiAgICA2NUsgICAgICAgLSAgICAg NTQ5NSAgNjQKICB1ZnNfZGlyaGFzaCAgIDMwOSAgICA3MksgICAgICAgLSAgICAg IDM2MyAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsNDA5NgogICAgdWZzX21vdW50ICAg IDE4ICAgIDY2SyAgICAgICAtICAgICAgIDE4ICAyNTYsMjA0OCw0MDk2CiAgICAg IFVNQUhhc2ggICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDQgIDI1Niw1MTIs MTAyNCwyMDQ4CiAgICB2bV9wZ2RhdGEgICAgIDIgICAgNjVLICAgICAgIC0gICAg ICAgIDIgIDY0CiAgICAgYXRrYmRkZXYgICAgIDIgICAgIDFLICAgICAgIC0gICAg ICAgIDIgIDMyCiAgICAgICBVU0JkZXYgICAgMzYgICAgMTBLICAgICAgIC0gICAg ICAgMzYgIDMyLDEyOCwxMDI0CiAgICAgICAgICBVU0IgICAgNjQgICAgMTZLICAg ICAgIC0gICAgICAgNjYgIDE2LDMyLDY0LDEyOCw1MTIsMTAyNCw0MDk2CkNBTSBk ZXYgcXVldWUgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAg ICBhcG1kZXYgICAgIDEgICAgIDFLICAgICAgIC0gICAgIDE0NzggIDY0CiAgICBD QU0gcXVldWUgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDcgIDE2CiAgICAg ICBERVZGUzEgICAxMTQgICAgMjlLICAgICAgIC0gICAgIDMwOTAgIDI1NgogICAg ICAgREVWRlMzICAgMjYxICAgIDMzSyAgICAgICAtICAgICAxNzU1ICAxMjgKICAg ICAgIERFVkZTMiAgIDExMCAgICAgMksgICAgICAgLSAgICAgIDExMiAgMTYKICAg ICAgaW9fYXBpYyAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTAyNAog ICBERVZGU19SVUxFICAgIDM3ICAgICA5SyAgICAgICAtICAgICAgIDM3ICAzMiwy NTYKICAgICAgbWVtZGVzYyAgICAgMSAgICAgNEsgICAgICAgLSAgICAgICAgNiAg MzIsNDA5NgogICAgICAgICAgbXNpICAgICA0ICAgICAxSyAgICAgICAtICAgICAg ICA0ICA2NAogICAgIG5leHVzZGV2ICAgICA0ICAgICAxSyAgICAgICAtICAgICAg ICA0ICAxNgogICAgICAgIERFVkZTICAgIDM5ICAgICAxSyAgICAgICAtICAgICAg IDQwICAxNiw2NAogICAgICAgREVWRlNQICAgICAzICAgICAxSyAgICAgICAtICAg ICAgICAzICAzMgogICAgcGZzX25vZGVzICAgIDcwICAgICA5SyAgICAgICAtICAg ICAgIDcwICAxMjgKICAgICAgICBtaXhlciAgICAgMSAgICAgNEsgICAgICAgLSAg ICAgICAgMSAgNDA5NgogICAgICAgIGxpbnV4ICAgIDEyICAgICAxSyAgICAgICAt ICAgICAgIDE2ICAxNiwzMiw2NAogICAgICAgZmVlZGVyICAgIDE0ICAgICAxSyAg ICAgICAtICAgICAgIDU5ICAxNiw2NAogICAgICAgICBoZGFjICAgIDEwICAgIDU0 SyAgICAgICAtICAgICAgIDEwICA2NCwxMjgsNTEyLDEwMjQsNDA5Ngpkcm1fY3R4 Yml0bWFwICAgICAxICAgICA0SyAgICAgICAtICAgICAgICAxICA0MDk2CiBkcm1f YWdwbGlzdHMgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiBkcm1f YnVmbGlzdHMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDMyCiAgICBk cm1fZmlsZXMgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAg ZHJtX21hcHMgICAgIDggICAgIDlLICAgICAgIC0gICAgICAgIDggIDY0CiAgIGRy bV9kcml2ZXIgICAgIDUgICAgIDVLICAgICAgIC0gICAgICAgIDUgIDE2LDMyLDY0 LDI1Niw0MDk2CiAgICBkcm1fc2FyZWEgICAgIDEgICAgIDFLICAgICAgIC0gICAg ICAgIDEgIDE2CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC16CgpJ VEVNICAgICAgICAgICAgICAgICAgICAgU0laRSAgICAgTElNSVQgICAgICBVU0VE ICAgICAgRlJFRSAgUkVRVUVTVFMgIEZBSUxVUkVTCgpVTUEgS2VnczogICAgICAg ICAgICAgICAgIDEyOCwgICAgICAgIDAsICAgICAgMTA0LCAgICAgICAxNiwgICAg ICAxMDQsICAgICAgICAwClVNQSBab25lczogICAgICAgICAgICAgICAgODg4LCAg ICAgICAgMCwgICAgICAxMDQsICAgICAgICAwLCAgICAgIDEwNCwgICAgICAgIDAK VU1BIFNsYWJzOiAgICAgICAgICAgICAgICAyODQsICAgICAgICAwLCAgICAgMTg2 MywgICAgICAgMTMsICAgICA3NTY5LCAgICAgICAgMApVTUEgUkNudFNsYWJzOiAg ICAgICAgICAgIDU0NCwgICAgICAgIDAsICAgICAgNTE4LCAgICAgICAgMCwgICAg ICA1MTgsICAgICAgICAwClVNQSBIYXNoOiAgICAgICAgICAgICAgICAgMTI4LCAg ICAgICAgMCwgICAgICAgIDMsICAgICAgIDI3LCAgICAgICAgNCwgICAgICAgIDAK MTYgQnVja2V0OiAgICAgICAgICAgICAgICAgNzYsICAgICAgICAwLCAgICAgICA2 MywgICAgICAgMzcsICAgICAgIDg0LCAgICAgICAgMAozMiBCdWNrZXQ6ICAgICAg ICAgICAgICAgIDE0MCwgICAgICAgIDAsICAgICAgIDgxLCAgICAgICAgMywgICAg ICAxMDcsICAgICAgICAwCjY0IEJ1Y2tldDogICAgICAgICAgICAgICAgMjY4LCAg ICAgICAgMCwgICAgICAgNzQsICAgICAgIDEwLCAgICAgIDEyMCwgICAgICAgNzUK MTI4IEJ1Y2tldDogICAgICAgICAgICAgICA1MjQsICAgICAgICAwLCAgICAgIDQ2 NiwgICAgICAgIDMsICAgICAxNTU2LCAgICAgIDE1MQpWTSBPQkpFQ1Q6ICAgICAg ICAgICAgICAgIDEzNiwgICAgICAgIDAsICAgIDE4NjMyLCAgICAgIDI3NiwgICA1 MDY1NDYsICAgICAgICAwCk1BUDogICAgICAgICAgICAgICAgICAgICAgMTQwLCAg ICAgICAgMCwgICAgICAgIDcsICAgICAgIDIxLCAgICAgICAgNywgICAgICAgIDAK S01BUCBFTlRSWTogICAgICAgICAgICAgICAgNzIsICAgIDU3NTA1LCAgICAgICA0 MSwgICAgICAyMjQsICAgIDI1MDk5LCAgICAgICAgMApNQVAgRU5UUlk6ICAgICAg ICAgICAgICAgICA3MiwgICAgICAgIDAsICAgICAzMjc5LCAgICAgIDY0MywgICA5 MjMwODgsICAgICAgICAwCkRQIGZha2VwZzogICAgICAgICAgICAgICAgIDcyLCAg ICAgICAgMCwgICAgNjU1NjYsICAgICAgIDQ4LCAgICA2NTYxNCwgICAgICAgIDAK U0cgZmFrZXBnOiAgICAgICAgICAgICAgICAgNzIsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAptdF96b25lOiAgICAgICAg ICAgICAgICAgMjA1NiwgICAgICAgIDAsICAgICAgMjg5LCAgICAgIDExMCwgICAg ICAyODksICAgICAgICAwCjE2OiAgICAgICAgICAgICAgICAgICAgICAgIDE2LCAg ICAgICAgMCwgICAgIDM2MjgsICAgICAgNDMyLCAgMzUwMTU3MSwgICAgICAgIDAK MzI6ICAgICAgICAgICAgICAgICAgICAgICAgMzIsICAgICAgICAwLCAgICAgNDA2 OCwgICAgIDgyNDksICAgNDYzNzYwLCAgICAgICAgMAo2NDogICAgICAgICAgICAg ICAgICAgICAgICA2NCwgICAgICAgIDAsICAgICA2MTk5LCAgICAgODI1NiwgIDEx MjQ3MTksICAgICAgICAwCjEyODogICAgICAgICAgICAgICAgICAgICAgMTI4LCAg ICAgICAgMCwgICAgIDM2OTEsICAgICA3Njc5LCAgIDM5MTQyMCwgICAgICAgIDAK MjU2OiAgICAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAgICAgMTI2 NywgICAgIDUyMTMsICAgIDY3OTIxLCAgICAgICAgMAo1MTI6ICAgICAgICAgICAg ICAgICAgICAgIDUxMiwgICAgICAgIDAsICAgICAgMTczLCAgICAgICA1OSwgICAg MzEzMTMsICAgICAgICAwCjEwMjQ6ICAgICAgICAgICAgICAgICAgICAxMDI0LCAg ICAgICAgMCwgICAgICAgNjYsICAgICAgMTc4LCAgICAgMzI1MiwgICAgICAgIDAK MjA0ODogICAgICAgICAgICAgICAgICAgIDIwNDgsICAgICAgICAwLCAgICAgIDU1 MSwgICAgIDE0MTUsICAgICAyOTE0LCAgICAgICAgMAo0MDk2OiAgICAgICAgICAg ICAgICAgICAgNDA5NiwgICAgICAgIDAsICAgICAgMTQ1LCAgICAgICA4MCwgICAg MzkwOTEsICAgICAgICAwCkZpbGVzOiAgICAgICAgICAgICAgICAgICAgIDU2LCAg ICAgICAgMCwgICAgIDE1MTEsICAgICAgMzY1LCAgIDE4MDUyMSwgICAgICAgIDAK VFVSTlNUSUxFOiAgICAgICAgICAgICAgICAgNzIsICAgICAgICAwLCAgICAgIDIy NSwgICAgICAgNzUsICAgICAgMjI1LCAgICAgICAgMAp1bXR4IHBpOiAgICAgICAg ICAgICAgICAgICA1MiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCk1BQyBsYWJlbHM6ICAgICAgICAgICAgICAgIDIwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK UFJPQzogICAgICAgICAgICAgICAgICAgICA2ODAsICAgICAgICAwLCAgICAgICA3 NiwgICAgICAgNTYsICAgIDM0MDkxLCAgICAgICAgMApUSFJFQUQ6ICAgICAgICAg ICAgICAgICAgIDU3MiwgICAgICAgIDAsICAgICAgMTkyLCAgICAgICAzMiwgICAg ICAyNzQsICAgICAgICAwClNMRUVQUVVFVUU6ICAgICAgICAgICAgICAgIDMyLCAg ICAgICAgMCwgICAgICAyMjUsICAgICAgMTI5LCAgICAgIDIyNSwgICAgICAgIDAK Vk1TUEFDRTogICAgICAgICAgICAgICAgICAyMzIsICAgICAgICAwLCAgICAgICA1 MywgICAgICAxMDAsICAgIDM0MDcwLCAgICAgICAgMApjcHVzZXQ6ICAgICAgICAg ICAgICAgICAgICA0MCwgICAgICAgIDAsICAgICAgICAzLCAgICAgIDI3MywgICAg ICAgIDQsICAgICAgICAwCmF1ZGl0X3JlY29yZDogICAgICAgICAgICAgODE2LCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK bWJ1Zl9wYWNrZXQ6ICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAgICAgIDMw MSwgICAgICAzNDIsICAgIDU5Njg1LCAgICAgICAgMAptYnVmOiAgICAgICAgICAg ICAgICAgICAgIDI1NiwgICAgICAgIDAsICAgICAgIDc3LCAgICAgIDQzOCwgICA2 NzU5NjMsICAgICAgICAwCm1idWZfY2x1c3RlcjogICAgICAgICAgICAyMDQ4LCAg ICAyNTYwMCwgICAgICA2NDAsICAgICAgIDI0LCAgICAgIDY3OCwgICAgICAgIDAK bWJ1Zl9qdW1ib19wYWdlOiAgICAgICAgIDQwOTYsICAgIDEyODAwLCAgICAgICA3 MywgICAgICAxMTMsICAgMTkzODU5LCAgICAgICAgMAptYnVmX2p1bWJvXzlrOiAg ICAgICAgICAgOTIxNiwgICAgMTkyMDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCm1idWZfanVtYm9fMTZrOiAgICAgICAgIDE2Mzg0LCAg ICAxMjgwMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK bWJ1Zl9leHRfcmVmY250OiAgICAgICAgICAgIDQsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApnX2JpbzogICAgICAgICAg ICAgICAgICAgIDE0MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgMzIyMCwgIDE0 NzEwOTgsICAgICAgICAwCnR0eW91dHE6ICAgICAgICAgICAgICAgICAgMjU2LCAg ICAgICAgMCwgICAgICAgODAsICAgICAgIDI1LCAgICAgIDQ1NiwgICAgICAgIDAK dHR5aW5xOiAgICAgICAgICAgICAgICAgICAxNTIsICAgICAgICAwLCAgICAgIDE2 NSwgICAgICAgOTUsICAgICAgODg1LCAgICAgICAgMAphdGFfcmVxdWVzdDogICAg ICAgICAgICAgIDIwMCwgICAgICAgIDAsICAgICAgICAxLCAgICAgIDg1NCwgICAz NzE0MDksICAgICAgICAwCmF0YV9jb21wb3NpdGU6ICAgICAgICAgICAgMTgwLCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK Vk5PREU6ICAgICAgICAgICAgICAgICAgICAyNjgsICAgICAgICAwLCAgICAzMjYx MSwgICAgICAyNjEsICAgIDUxOTQzLCAgICAgICAgMApWTk9ERVBPTEw6ICAgICAg ICAgICAgICAgICA2MCwgICAgICAgIDAsICAgICAxMTI0LCAgICAgICA3MywgICAg IDExMjYsICAgICAgICAwClMgVkZTIENhY2hlOiAgICAgICAgICAgICAgIDcyLCAg ICAgICAgMCwgICAgMjU0ODcsICAgICAgMjE4LCAgICA4NjcyMiwgICAgICAgIDAK TCBWRlMgQ2FjaGU6ICAgICAgICAgICAgICAyOTIsICAgICAgICAwLCAgICAgMTQ2 NSwgICAgICA4NzUsICAgICA4Mjk0LCAgICAgICAgMApOQU1FSTogICAgICAgICAg ICAgICAgICAgMTAyNCwgICAgICAgIDAsICAgICAgICAxLCAgICAgICA0NywgICA3 NDkzOTQsICAgICAgICAwCkRJUkhBU0g6ICAgICAgICAgICAgICAgICAxMDI0LCAg ICAgICAgMCwgICAgIDE1OTQsICAgICAgIDk0LCAgICAgMTgzNCwgICAgICAgIDAK TkZTTU9VTlQ6ICAgICAgICAgICAgICAgICA1MjAsICAgICAgICAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApORlNOT0RFOiAgICAgICAg ICAgICAgICAgIDQ2NCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnBpcGU6ICAgICAgICAgICAgICAgICAgICAgMzkyLCAg ICAgICAgMCwgICAgICAgMzUsICAgICAgIDU1LCAgICAxNzI4NCwgICAgICAgIDAK a3NpZ2luZm86ICAgICAgICAgICAgICAgICAgODAsICAgICAgICAwLCAgICAgIDEx OSwgICAgICA5MzcsICAgICAgMTE5LCAgICAgICAgMAppdGltZXI6ICAgICAgICAg ICAgICAgICAgIDIyMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCktOT1RFOiAgICAgICAgICAgICAgICAgICAgIDcyLCAg ICAgICAgMCwgICAgIDExOTksICAgICAgMTc5LCAgICAgNDg3NCwgICAgICAgIDAK c29ja2V0OiAgICAgICAgICAgICAgICAgICA0MTIsICAgIDI1NjA1LCAgICAgIDEy MSwgICAgICAgNjgsICAgICAxMTY1LCAgICAgICAgMAppcHE6ICAgICAgICAgICAg ICAgICAgICAgICAzMiwgICAgICA5MDQsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnVkcF9pbnBjYjogICAgICAgICAgICAgICAgMjIwLCAg ICAyNTYxNCwgICAgICAgIDksICAgICAgIDYzLCAgICAgIDI4MSwgICAgICAgIDAK dWRwY2I6ICAgICAgICAgICAgICAgICAgICAgIDgsICAgIDI1NzgxLCAgICAgICAg OSwgICAgICAzOTcsICAgICAgMjgxLCAgICAgICAgMAp0Y3BfaW5wY2I6ICAgICAg ICAgICAgICAgIDIyMCwgICAgMjU2MTQsICAgICAgIDExLCAgICAgICA5NywgICAg ICAyNDIsICAgICAgICAwCnRjcGNiOiAgICAgICAgICAgICAgICAgICAgNjMyLCAg ICAyNTYwMiwgICAgICAgMTEsICAgICAgIDQ5LCAgICAgIDI0MiwgICAgICAgIDAK dGNwdHc6ICAgICAgICAgICAgICAgICAgICAgNTIsICAgICA1MTg0LCAgICAgICAg MCwgICAgICAyMTYsICAgICAgIDM2LCAgICAgICAgMApzeW5jYWNoZTogICAgICAg ICAgICAgICAgIDExMiwgICAgMTUzNjUsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCmhvc3RjYWNoZTogICAgICAgICAgICAgICAgIDc2LCAg ICAxNTQwMCwgICAgICAgMjcsICAgICAgMTIzLCAgICAgICAyNywgICAgICAgIDAK dGNwcmVhc3M6ICAgICAgICAgICAgICAgICAgMjAsICAgICAxNjkwLCAgICAgICAg MCwgICAgICAzMzgsICAgICAyMzM4LCAgICAgICAgMApzYWNraG9sZTogICAgICAg ICAgICAgICAgICAyMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgIDE2OSwgICAg ICAgMTMsICAgICAgICAwCnNjdHBfZXA6ICAgICAgICAgICAgICAgICAgODQ4LCAg ICAyNTYwMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK c2N0cF9hc29jOiAgICAgICAgICAgICAgIDE0NjAsICAgIDQwMDAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApzY3RwX2xhZGRyOiAgICAg ICAgICAgICAgICAyNCwgICAgODAwNDAsICAgICAgICAwLCAgICAgIDI5MCwgICAg ICAgIDQsICAgICAgICAwCnNjdHBfcmFkZHI6ICAgICAgICAgICAgICAgNDIwLCAg ICA4MDAwMSwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK c2N0cF9jaHVuazogICAgICAgICAgICAgICAgOTYsICAgNDAwMDAwLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApzY3RwX3JlYWRxOiAgICAg ICAgICAgICAgICA3NiwgICA0MDAwMDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnNjdHBfc3RyZWFtX21zZ19vdXQ6ICAgICAgIDY0LCAg IDQwMDAyMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK c2N0cF9hc2NvbmY6ICAgICAgICAgICAgICAgMjQsICAgNDAwMDU1LCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApzY3RwX2FzY29uZl9hY2s6 ICAgICAgICAgICAyNCwgICA0MDAwNTUsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnJpcGNiOiAgICAgICAgICAgICAgICAgICAgMjIwLCAg ICAyNTYxNCwgICAgICAgIDEsICAgICAgIDM1LCAgICAgICAgMSwgICAgICAgIDAK dW5wY2I6ICAgICAgICAgICAgICAgICAgICAxNzIsICAgIDI1NjIyLCAgICAgICA5 OCwgICAgICAgNDAsICAgICAgNjM2LCAgICAgICAgMApydGVudHJ5OiAgICAgICAg ICAgICAgICAgIDEwOCwgICAgICAgIDAsICAgICAgIDExLCAgICAgICA5NywgICAg ICAgMTIsICAgICAgICAwCnNlbGZkOiAgICAgICAgICAgICAgICAgICAgIDI4LCAg ICAgICAgMCwgICAgICAyMDgsICAgICAgNDI3LCAgNTkxMjU0NiwgICAgICAgIDAK aXA0ZmxvdzogICAgICAgICAgICAgICAgICAgNDAsICAgICA0MTQwLCAgICAgICAg NiwgICAgICAyNzAsICAgICAgMjUzLCAgICAgICAgMAppcDZmbG93OiAgICAgICAg ICAgICAgICAgICA2NCwgICAgIDQxMTgsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwClNXQVBNRVRBOiAgICAgICAgICAgICAgICAgMjc2LCAg IDEyMTU3NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK TW91bnRwb2ludHM6ICAgICAgICAgICAgICA2NDQsICAgICAgICAwLCAgICAgICAx MCwgICAgICAgIDgsICAgICAgIDEwLCAgICAgICAgMApGRlMgaW5vZGU6ICAgICAg ICAgICAgICAgIDExNiwgICAgICAgIDAsICAgIDMyNTIwLCAgICAgIDMxNSwgICAg NTAzNjYsICAgICAgICAwCkZGUzEgZGlub2RlOiAgICAgICAgICAgICAgMTI4LCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK RkZTMiBkaW5vZGU6ICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAgICAzMjUy MCwgICAgICAzMDAsICAgIDUwMzY2LCAgICAgICAgMApwZnNyY3RycGw6ICAgICAg ICAgICAgICAgIDEyNCwgICAgMTAwMTMsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnBmcnVsZXBsOiAgICAgICAgICAgICAgICAgODI4LCAg ICAgICAgMCwgICAgICAgMTMsICAgICAgICA3LCAgICAgICAxMywgICAgICAgIDAK cGZzdGF0ZXBsOiAgICAgICAgICAgICAgICAyODQsICAgIDEwMDEwLCAgICAgICAg NSwgICAgICAxMjEsICAgICAgMjY1LCAgICAgICAgMApwZmFsdHFwbDogICAgICAg ICAgICAgICAgIDIyNCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnBmcG9vbGFkZHJwbDogICAgICAgICAgICAgIDY4LCAg ICAgICAgMCwgICAgICAgIDksICAgICAgMTAzLCAgICAgICAgOSwgICAgICAgIDAK cGZya3RhYmxlOiAgICAgICAgICAgICAgIDEyNDAsICAgICAxMDAyLCAgICAgICAg MiwgICAgICAgIDcsICAgICAgICA2LCAgICAgICAgMApwZnJrZW50cnk6ICAgICAg ICAgICAgICAgIDE1NiwgICAxMDAwMDAsICAgICAgICAxLCAgICAgICA3NCwgICAg ICAgIDMsICAgICAgICAwCnBmcmtlbnRyeTI6ICAgICAgICAgICAgICAgMTU2LCAg ICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK cGZmcmVudDogICAgICAgICAgICAgICAgICAgMTYsICAgICA1MDc1LCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZmZyYWc6ICAgICAgICAg ICAgICAgICAgICA0OCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnBmZnJjYWNoZTogICAgICAgICAgICAgICAgIDQ4LCAg ICAxMDA2MiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAK cGZmcmNlbnQ6ICAgICAgICAgICAgICAgICAgMTIsICAgIDUwMTQxLCAgICAgICAg MCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZnN0YXRlc2NydWI6ICAg ICAgICAgICAgICAyOCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAg ICAgIDAsICAgICAgICAwCnBmaWFkZHJwbDogICAgICAgICAgICAgICAgMTAwLCAg ICAgICAgMCwgICAgICAgIDksICAgICAgIDY5LCAgICAgICAgOSwgICAgICAgIDAK cGZvc3BmZW46ICAgICAgICAgICAgICAgICAxMDgsICAgICAgICAwLCAgICAgIDY5 NiwgICAgICAgMjQsICAgICAgNjk2LCAgICAgICAgMApwZm9zZnA6ICAgICAgICAg ICAgICAgICAgICAyOCwgICAgICAgIDAsICAgICAgNDA3LCAgICAgIDIyOCwgICAg ICA0MDcsICAgICAgICAwCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnZtc3Rh dCAtaQoKaW50ZXJydXB0ICAgICAgICAgICAgICAgICAgICAgICAgICB0b3RhbCAg ICAgICByYXRlCmlycTE6IGF0a2JkMCAgICAgICAgICAgICAgICAgICAgICAgIDE4 NjIgICAgICAgICA1OAppcnE5OiBhY3BpMCAgICAgICAgICAgICAgICAgICAgICAg ICA5ODcyICAgICAgICAzMDgKaXJxMTI6IHBzbTAgICAgICAgICAgICAgICAgICAg ICAgIDI2NjAxMCAgICAgICA4MzEyCmlycTE2OiB1aGNpMCB1aGNpNCAgICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgMAppcnExOTogZWhjaTAgdWhjaSsgICAg ICAgICAgICAgICAgMzY3ODk0ICAgICAgMTE0OTYKY3B1MDogdGltZXIgICAgICAg ICAgICAgICAgICAgICAgNTA1MTkzMCAgICAgMTU3ODcyCmlycTI1NjogaGRhYzAg ICAgICAgICAgICAgICAgICAgICAgIDU3ODAgICAgICAgIDE4MAppcnEyNTg6IGl3 bjAgICAgICAgICAgICAgICAgICAgICAgMTA0MDEwICAgICAgIDMyNTAKY3B1MTog dGltZXIgICAgICAgICAgICAgICAgICAgICAgNTA1MDgyMyAgICAgMTU3ODM4Cmly cTI1OTogdmdhcGNpMCAgICAgICAgICAgICAgICAgICAgMzIyMDEgICAgICAgMTAw NgpUb3RhbCAgICAgICAgICAgICAgICAgICAgICAgICAgIDEwODkwMzgzICAgICAz NDAzMjQKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtVAoKMTUxMS8x MjMyOCBmaWxlcwowTS80MDk1TSBzd2FwIHNwYWNlCgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KcHN0YXQgLXMKCkRldmljZSAgICAgICAgICA1MTItYmxvY2tzICAg ICBVc2VkICAgIEF2YWlsIENhcGFjaXR5Ci9kZXYvYWQ2czFiICAgICAgICA4Mzg4 MzUyICAgICAgICAwICA4Mzg4MzUyICAgICAwJQoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCmlvc3RhdAoKaW9zdGF0OiBrdm1fcmVhZChfdGtfbmluKTogaW52YWxp ZCBhZGRyZXNzICgweDApCmlvc3RhdDogZGlzYWJsaW5nIFRUWSBzdGF0aXN0aWNz Cmlvc3RhdDoga3ZtX2dldGNwdGltZTogaW52YWxpZCBhZGRyZXNzICgweDApCmlv c3RhdDogZGlzYWJsaW5nIENQVSB0aW1lIHN0YXRpc3RpY3MKICAgICAgICAgICAg IGFkNiAgICAgICAgICAgIG1kMTAxIAogIEtCL3QgdHBzICBNQi9zICAgS0IvdCB0 cHMgIE1CL3MgCiAxNS43OSAxMTQwNSAxNzUuODQgIDEzLjM2ICAyMSAgMC4yNyAK Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQppcGNzIC1hCgpNZXNzYWdlIFF1ZXVl czoKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVS ICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgICAgICAgICAgQ0JZ VEVTICAgICAgICAgICAgICAgICBRTlVNICAgICAgICAgICAgICAgUUJZVEVTICAg ICAgICBMU1BJRCAgICAgICAgTFJQSUQgU1RJTUUgICAgUlRJTUUgICAgQ1RJTUUg ICAKClNoYXJlZCBNZW1vcnk6ClQgICAgICAgICAgIElEICAgICAgICAgIEtFWSBN T0RFICAgICAgICBPV05FUiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JPVVAgICAg ICAgICBOQVRUQ0ggICAgICAgIFNFR1NaICAgICAgICAgQ1BJRCAgICAgICAgIExQ SUQgQVRJTUUgICAgRFRJTUUgICAgQ1RJTUUgICAKbSAgICAgICAgNjU1MzYgICAg ICA1NDMyMDAxIC0tcnctLS0tLS0tIHBnc3FsICAgIHBnc3FsICAgIHBnc3FsICAg IHBnc3FsICAgICAgICAgICAgICAgNCAgICAgMzY4ODAzODQgICAgICAgICAgODgx ICAgICAgICAgIDg4MSAyMDo0ODowNSAyMToyOToxMSAyMDo0ODowNQoKU2VtYXBo b3JlczoKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUgICAgICAgIE9X TkVSICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgICBOU0VNUyBP VElNRSAgICBDVElNRSAgIApzICAgICAgICA2NTUzNiAgICAgIDU0MzIwMDEgLS1y dy0tLS0tLS0gcGdzcWwgICAgcGdzcWwgICAgcGdzcWwgICAgcGdzcWwgICAgICAg ICAgICAgIDE3IDIwOjQ4OjA1IDIwOjQ4OjA1CnMgICAgICAgIDY1NTM3ICAgICAg NTQzMjAwMiAtLXJ3LS0tLS0tLSBwZ3NxbCAgICBwZ3NxbCAgICBwZ3NxbCAgICBw Z3NxbCAgICAgICAgICAgICAgMTcgMjA6NDg6MDUgMjA6NDg6MDUKcyAgICAgICAg NjU1MzggICAgICA1NDMyMDAzIC0tcnctLS0tLS0tIHBnc3FsICAgIHBnc3FsICAg IHBnc3FsICAgIHBnc3FsICAgICAgICAgICAgICAxNyAyMDo0ODowNSAyMDo0ODow NQpzICAgICAgICA2NTUzOSAgICAgIDU0MzIwMDQgLS1ydy0tLS0tLS0gcGdzcWwg ICAgcGdzcWwgICAgcGdzcWwgICAgcGdzcWwgICAgICAgICAgICAgIDE3IDIwOjQ4 OjA1IDIwOjQ4OjA1CnMgICAgICAgIDY1NTQwICAgICAgNTQzMjAwNSAtLXJ3LS0t LS0tLSBwZ3NxbCAgICBwZ3NxbCAgICBwZ3NxbCAgICBwZ3NxbCAgICAgICAgICAg ICAgMTcgMjA6NDg6MDUgMjA6NDg6MDUKcyAgICAgICAgNjU1NDEgICAgICA1NDMy MDA2IC0tcnctLS0tLS0tIHBnc3FsICAgIHBnc3FsICAgIHBnc3FsICAgIHBnc3Fs ICAgICAgICAgICAgICAxNyAyMDo0ODowNSAyMDo0ODowNQpzICAgICAgICA2NTU0 MiAgICAgIDU0MzIwMDcgLS1ydy0tLS0tLS0gcGdzcWwgICAgcGdzcWwgICAgcGdz cWwgICAgcGdzcWwgICAgICAgICAgICAgIDE3IDIwOjQ4OjA1IDIwOjQ4OjA1CgoK LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmlwY3MgLVQKCm1zZ2luZm86Cgltc2dt YXg6ICAgICAgICAxNjM4NAkobWF4IGNoYXJhY3RlcnMgaW4gYSBtZXNzYWdlKQoJ bXNnbW5pOiAgICAgICAgICAgNDAJKCMgb2YgbWVzc2FnZSBxdWV1ZXMpCgltc2dt bmI6ICAgICAgICAgMjA0OAkobWF4IGNoYXJhY3RlcnMgaW4gYSBtZXNzYWdlIHF1 ZXVlKQoJbXNndHFsOiAgICAgICAgICAgNDAJKG1heCAjIG9mIG1lc3NhZ2VzIGlu IHN5c3RlbSkKCW1zZ3NzejogICAgICAgICAgICA4CShzaXplIG9mIGEgbWVzc2Fn ZSBzZWdtZW50KQoJbXNnc2VnOiAgICAgICAgIDIwNDgJKCMgb2YgbWVzc2FnZSBz ZWdtZW50cyBpbiBzeXN0ZW0pCgpzaG1pbmZvOgoJc2htbWF4OiAgICAyNjg0MzU0 NTYJKG1heCBzaGFyZWQgbWVtb3J5IHNlZ21lbnQgc2l6ZSkKCXNobW1pbjogICAg ICAgICAgICAxCShtaW4gc2hhcmVkIG1lbW9yeSBzZWdtZW50IHNpemUpCglzaG1t bmk6ICAgICAgICAgIDE5MgkobWF4IG51bWJlciBvZiBzaGFyZWQgbWVtb3J5IGlk ZW50aWZpZXJzKQoJc2htc2VnOiAgICAgICAgICAxMjgJKG1heCBzaGFyZWQgbWVt b3J5IHNlZ21lbnRzIHBlciBwcm9jZXNzKQoJc2htYWxsOiAgICAgICAgNjU1MzYJ KG1heCBhbW91bnQgb2Ygc2hhcmVkIG1lbW9yeSBpbiBwYWdlcykKCnNlbWluZm86 CglzZW1tYXA6ICAgICAgICAgICAzMAkoIyBvZiBlbnRyaWVzIGluIHNlbWFwaG9y ZSBtYXApCglzZW1tbmk6ICAgICAgICAgIDI1NgkoIyBvZiBzZW1hcGhvcmUgaWRl bnRpZmllcnMpCglzZW1tbnM6ICAgICAgICAgIDUxMgkoIyBvZiBzZW1hcGhvcmVz IGluIHN5c3RlbSkKCXNlbW1udTogICAgICAgICAgMjU2CSgjIG9mIHVuZG8gc3Ry dWN0dXJlcyBpbiBzeXN0ZW0pCglzZW1tc2w6ICAgICAgICAgICA2MAkobWF4ICMg b2Ygc2VtYXBob3JlcyBwZXIgaWQpCglzZW1vcG06ICAgICAgICAgIDEwMAkobWF4 ICMgb2Ygb3BlcmF0aW9ucyBwZXIgc2Vtb3AgY2FsbCkKCXNlbXVtZTogICAgICAg ICAgIDEwCShtYXggIyBvZiB1bmRvIGVudHJpZXMgcGVyIHByb2Nlc3MpCglzZW11 c3o6ICAgICAgICAgIDEzNgkoc2l6ZSBpbiBieXRlcyBvZiB1bmRvIHN0cnVjdHVy ZSkKCXNlbXZteDogICAgICAgIDMyNzY3CShzZW1hcGhvcmUgbWF4aW11bSB2YWx1 ZSkKCXNlbWFlbTogICAgICAgIDE2Mzg0CShhZGp1c3Qgb24gZXhpdCBtYXggdmFs dWUpCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5mc3N0YXQKCkNsaWVudCBJ bmZvOgpScGMgQ291bnRzOgogIEdldGF0dHIgICBTZXRhdHRyICAgIExvb2t1cCAg UmVhZGxpbmsgICAgICBSZWFkICAgICBXcml0ZSAgICBDcmVhdGUgICAgUmVtb3Zl CiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAg IDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKICAgUmVuYW1lICAgICAg TGluayAgIFN5bWxpbmsgICAgIE1rZGlyICAgICBSbWRpciAgIFJlYWRkaXIgIFJk aXJQbHVzICAgIEFjY2VzcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAw CiAgICBNa25vZCAgICBGc3N0YXQgICAgRnNpbmZvICBQYXRoQ29uZiAgICBDb21t aXQKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMApScGMgSW5mbzoKIFRpbWVkT3V0ICAgSW52YWxpZCBYIFJlcGxpZXMgICBS ZXRyaWVzICBSZXF1ZXN0cwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwCkNhY2hlIEluZm86CkF0dHIgSGl0cyAgICBNaXNz ZXMgTGt1cCBIaXRzICAgIE1pc3NlcyBCaW9SIEhpdHMgICAgTWlzc2VzIEJpb1cg SGl0cyAgICBNaXNzZXMKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMApC aW9STEhpdHMgICAgTWlzc2VzIEJpb0QgSGl0cyAgICBNaXNzZXMgRGlyRSBIaXRz ICAgIE1pc3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAg IDAgICAgICAgICAwICAgICAgICAgMAoKU2VydmVyIEluZm86CiAgR2V0YXR0ciAg IFNldGF0dHIgICAgTG9va3VwICBSZWFkbGluayAgICAgIFJlYWQgICAgIFdyaXRl ICAgIENyZWF0ZSAgICBSZW1vdmUKICAgICAgICAwICAgICAgICAgMCAgICAgICAg IDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMAogICBSZW5hbWUgICAgICBMaW5rICAgU3ltbGluayAgICAgTWtkaXIgICAg IFJtZGlyICAgUmVhZGRpciAgUmRpclBsdXMgICAgQWNjZXNzCiAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAw ICAgICAgICAgMCAgICAgICAgIDAKICAgIE1rbm9kICAgIEZzc3RhdCAgICBGc2lu Zm8gIFBhdGhDb25mICAgIENvbW1pdAogICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMCAgICAgICAgIDAgICAgICAgICAwClNlcnZlciBSZXQtRmFpbGVkCiAgICAg ICAgICAgICAgICAwClNlcnZlciBGYXVsdHMKICAgICAgICAgICAgMApTZXJ2ZXIg Q2FjaGUgU3RhdHM6CiAgIElucHJvZyAgICAgIElkZW0gIE5vbi1pZGVtICAgIE1p c3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKU2Vy dmVyIFdyaXRlIEdhdGhlcmluZzoKIFdyaXRlT3BzICBXcml0ZVJQQyAgIE9wc2F2 ZWQKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQpuZXRzdGF0IC1zCgp0Y3A6CgkzMjQzOSBwYWNrZXRzIHNlbnQK CQkyMjA5IGRhdGEgcGFja2V0cyAoMTU0OTQ3MCBieXRlcykKCQk2MyBkYXRhIHBh Y2tldHMgKDY0MjUxIGJ5dGVzKSByZXRyYW5zbWl0dGVkCgkJMCBkYXRhIHBhY2tl dHMgdW5uZWNlc3NhcmlseSByZXRyYW5zbWl0dGVkCgkJMCByZXNlbmRzIGluaXRp YXRlZCBieSBNVFUgZGlzY292ZXJ5CgkJMTgwMzkgYWNrLW9ubHkgcGFja2V0cyAo MzMxIGRlbGF5ZWQpCgkJMCBVUkcgb25seSBwYWNrZXRzCgkJMCB3aW5kb3cgcHJv YmUgcGFja2V0cwoJCTExNzk1IHdpbmRvdyB1cGRhdGUgcGFja2V0cwoJCTMzMyBj b250cm9sIHBhY2tldHMKCTQ0MDM2IHBhY2tldHMgcmVjZWl2ZWQKCQkyMTQzIGFj a3MgKGZvciAxNTM0NDg1IGJ5dGVzKQoJCTEyNiBkdXBsaWNhdGUgYWNrcwoJCTAg YWNrcyBmb3IgdW5zZW50IGRhdGEKCQkzOTY5MSBwYWNrZXRzICg1Mjg1NDAyMCBi eXRlcykgcmVjZWl2ZWQgaW4tc2VxdWVuY2UKCQk2NyBjb21wbGV0ZWx5IGR1cGxp Y2F0ZSBwYWNrZXRzICgxNTgxNiBieXRlcykKCQkwIG9sZCBkdXBsaWNhdGUgcGFj a2V0cwoJCTAgcGFja2V0cyB3aXRoIHNvbWUgZHVwLiBkYXRhICgwIGJ5dGVzIGR1 cGVkKQoJCTIzMzggb3V0LW9mLW9yZGVyIHBhY2tldHMgKDE3NDY5MTcgYnl0ZXMp CgkJMCBwYWNrZXRzICgwIGJ5dGVzKSBvZiBkYXRhIGFmdGVyIHdpbmRvdwoJCTAg d2luZG93IHByb2JlcwoJCTEyOSB3aW5kb3cgdXBkYXRlIHBhY2tldHMKCQkxNSBw YWNrZXRzIHJlY2VpdmVkIGFmdGVyIGNsb3NlCgkJMCBkaXNjYXJkZWQgZm9yIGJh ZCBjaGVja3N1bXMKCQkwIGRpc2NhcmRlZCBmb3IgYmFkIGhlYWRlciBvZmZzZXQg ZmllbGRzCgkJMCBkaXNjYXJkZWQgYmVjYXVzZSBwYWNrZXQgdG9vIHNob3J0CgkJ MjAgZGlzY2FyZGVkIGR1ZSB0byBtZW1vcnkgcHJvYmxlbXMKCTE2OSBjb25uZWN0 aW9uIHJlcXVlc3RzCgkwIGNvbm5lY3Rpb24gYWNjZXB0cwoJMCBiYWQgY29ubmVj dGlvbiBhdHRlbXB0cwoJMCBsaXN0ZW4gcXVldWUgb3ZlcmZsb3dzCgkwIGlnbm9y ZWQgUlNUcyBpbiB0aGUgd2luZG93cwoJMTY4IGNvbm5lY3Rpb25zIGVzdGFibGlz aGVkIChpbmNsdWRpbmcgYWNjZXB0cykKCTIzMSBjb25uZWN0aW9ucyBjbG9zZWQg KGluY2x1ZGluZyAxMiBkcm9wcykKCQk3NyBjb25uZWN0aW9ucyB1cGRhdGVkIGNh Y2hlZCBSVFQgb24gY2xvc2UKCQk3OCBjb25uZWN0aW9ucyB1cGRhdGVkIGNhY2hl ZCBSVFQgdmFyaWFuY2Ugb24gY2xvc2UKCQkyIGNvbm5lY3Rpb25zIHVwZGF0ZWQg Y2FjaGVkIHNzdGhyZXNoIG9uIGNsb3NlCgkxIGVtYnJ5b25pYyBjb25uZWN0aW9u IGRyb3BwZWQKCTIxNDEgc2VnbWVudHMgdXBkYXRlZCBydHQgKG9mIDE4NzAgYXR0 ZW1wdHMpCgkxMjggcmV0cmFuc21pdCB0aW1lb3V0cwoJCTkgY29ubmVjdGlvbnMg ZHJvcHBlZCBieSByZXhtaXQgdGltZW91dAoJMCBwZXJzaXN0IHRpbWVvdXRzCgkJ MCBjb25uZWN0aW9ucyBkcm9wcGVkIGJ5IHBlcnNpc3QgdGltZW91dAoJMCBDb25u ZWN0aW9ucyAoZmluX3dhaXRfMikgZHJvcHBlZCBiZWNhdXNlIG9mIHRpbWVvdXQK CTEga2VlcGFsaXZlIHRpbWVvdXQKCQkwIGtlZXBhbGl2ZSBwcm9iZXMgc2VudAoJ CTEgY29ubmVjdGlvbiBkcm9wcGVkIGJ5IGtlZXBhbGl2ZQoJNjAgY29ycmVjdCBB Q0sgaGVhZGVyIHByZWRpY3Rpb25zCgkzOTEzMiBjb3JyZWN0IGRhdGEgcGFja2V0 IGhlYWRlciBwcmVkaWN0aW9ucwoJMCBzeW5jYWNoZSBlbnRyaWVzIGFkZGVkCgkJ MCByZXRyYW5zbWl0dGVkCgkJMCBkdXBzeW4KCQkwIGRyb3BwZWQKCQkwIGNvbXBs ZXRlZAoJCTAgYnVja2V0IG92ZXJmbG93CgkJMCBjYWNoZSBvdmVyZmxvdwoJCTAg cmVzZXQKCQkwIHN0YWxlCgkJMCBhYm9ydGVkCgkJMCBiYWRhY2sKCQkwIHVucmVh Y2gKCQkwIHpvbmUgZmFpbHVyZXMKCTAgY29va2llcyBzZW50CgkwIGNvb2tpZXMg cmVjZWl2ZWQKCTAgU0FDSyByZWNvdmVyeSBlcGlzb2RlcwoJMCBzZWdtZW50IHJl eG1pdHMgaW4gU0FDSyByZWNvdmVyeSBlcGlzb2RlcwoJMCBieXRlIHJleG1pdHMg aW4gU0FDSyByZWNvdmVyeSBlcGlzb2RlcwoJMjQgU0FDSyBvcHRpb25zIChTQUNL IGJsb2NrcykgcmVjZWl2ZWQKCTE0MzkgU0FDSyBvcHRpb25zIChTQUNLIGJsb2Nr cykgc2VudAoJMCBTQUNLIHNjb3JlYm9hcmQgb3ZlcmZsb3cKCTAgcGFja2V0cyB3 aXRoIEVDTiBDRSBiaXQgc2V0CgkwIHBhY2tldHMgd2l0aCBFQ04gRUNUKDApIGJp dCBzZXQKCTAgcGFja2V0cyB3aXRoIEVDTiBFQ1QoMSkgYml0IHNldAoJMCBzdWNj ZXNzZnVsIEVDTiBoYW5kc2hha2VzCgkwIHRpbWVzIEVDTiByZWR1Y2VkIHRoZSBj b25nZXN0aW9uIHdpbmRvdwp1ZHA6CgkzMjIgZGF0YWdyYW1zIHJlY2VpdmVkCgkw IHdpdGggaW5jb21wbGV0ZSBoZWFkZXIKCTAgd2l0aCBiYWQgZGF0YSBsZW5ndGgg ZmllbGQKCTAgd2l0aCBiYWQgY2hlY2tzdW0KCTAgd2l0aCBubyBjaGVja3N1bQoJ NiBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTAgYnJvYWRjYXN0L211bHRpY2Fz dCBkYXRhZ3JhbXMgdW5kZWxpdmVyZWQKCTAgZHJvcHBlZCBkdWUgdG8gZnVsbCBz b2NrZXQgYnVmZmVycwoJMCBub3QgZm9yIGhhc2hlZCBwY2IKCTMxNiBkZWxpdmVy ZWQKCTQwMyBkYXRhZ3JhbXMgb3V0cHV0CgkwIHRpbWVzIG11bHRpY2FzdCBzb3Vy Y2UgZmlsdGVyIG1hdGNoZWQKaXA6Cgk0NDYxMyB0b3RhbCBwYWNrZXRzIHJlY2Vp dmVkCgkwIGJhZCBoZWFkZXIgY2hlY2tzdW1zCgkwIHdpdGggc2l6ZSBzbWFsbGVy IHRoYW4gbWluaW11bQoJMCB3aXRoIGRhdGEgc2l6ZSA8IGRhdGEgbGVuZ3RoCgkw IHdpdGggaXAgbGVuZ3RoID4gbWF4IGlwIHBhY2tldCBzaXplCgkwIHdpdGggaGVh ZGVyIGxlbmd0aCA8IGRhdGEgc2l6ZQoJMCB3aXRoIGRhdGEgbGVuZ3RoIDwgaGVh ZGVyIGxlbmd0aAoJMCB3aXRoIGJhZCBvcHRpb25zCgk2NCB3aXRoIGluY29ycmVj dCB2ZXJzaW9uIG51bWJlcgoJMCBmcmFnbWVudHMgcmVjZWl2ZWQKCTAgZnJhZ21l bnRzIGRyb3BwZWQgKGR1cCBvciBvdXQgb2Ygc3BhY2UpCgkwIGZyYWdtZW50cyBk cm9wcGVkIGFmdGVyIHRpbWVvdXQKCTAgcGFja2V0cyByZWFzc2VtYmxlZCBvawoJ NDQxMzcgcGFja2V0cyBmb3IgdGhpcyBob3N0Cgk2IHBhY2tldHMgZm9yIHVua25v d24vdW5zdXBwb3J0ZWQgcHJvdG9jb2wKCTAgcGFja2V0cyBmb3J3YXJkZWQgKDAg cGFja2V0cyBmYXN0IGZvcndhcmRlZCkKCTAgcGFja2V0cyBub3QgZm9yd2FyZGFi bGUKCTAgcGFja2V0cyByZWNlaXZlZCBmb3IgdW5rbm93biBtdWx0aWNhc3QgZ3Jv dXAKCTAgcmVkaXJlY3RzIHNlbnQKCTMyNjczIHBhY2tldHMgc2VudCBmcm9tIHRo aXMgaG9zdAoJMCBwYWNrZXRzIHNlbnQgd2l0aCBmYWJyaWNhdGVkIGlwIGhlYWRl cgoJMCBvdXRwdXQgcGFja2V0cyBkcm9wcGVkIGR1ZSB0byBubyBidWZzLCBldGMu CgkwIG91dHB1dCBwYWNrZXRzIGRpc2NhcmRlZCBkdWUgdG8gbm8gcm91dGUKCTAg b3V0cHV0IGRhdGFncmFtcyBmcmFnbWVudGVkCgkwIGZyYWdtZW50cyBjcmVhdGVk CgkwIGRhdGFncmFtcyB0aGF0IGNhbid0IGJlIGZyYWdtZW50ZWQKCTAgdHVubmVs aW5nIHBhY2tldHMgdGhhdCBjYW4ndCBmaW5kIGdpZgoJMCBkYXRhZ3JhbXMgd2l0 aCBiYWQgYWRkcmVzcyBpbiBoZWFkZXIKaWNtcDoKCTYgY2FsbHMgdG8gaWNtcF9l cnJvcgoJMCBlcnJvcnMgbm90IGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBhbiBp Y21wIG1lc3NhZ2UKCU91dHB1dCBoaXN0b2dyYW06CgkJZGVzdGluYXRpb24gdW5y ZWFjaGFibGU6IDYKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY29kZSBmaWVsZHMKCTAg bWVzc2FnZXMgbGVzcyB0aGFuIHRoZSBtaW5pbXVtIGxlbmd0aAoJMCBtZXNzYWdl cyB3aXRoIGJhZCBjaGVja3N1bQoJMCBtZXNzYWdlcyB3aXRoIGJhZCBsZW5ndGgK CTAgbXVsdGljYXN0IGVjaG8gcmVxdWVzdHMgaWdub3JlZAoJMCBtdWx0aWNhc3Qg dGltZXN0YW1wIHJlcXVlc3RzIGlnbm9yZWQKCUlucHV0IGhpc3RvZ3JhbToKCQlk ZXN0aW5hdGlvbiB1bnJlYWNoYWJsZTogNgoJMCBtZXNzYWdlIHJlc3BvbnNlcyBn ZW5lcmF0ZWQKCTAgaW52YWxpZCByZXR1cm4gYWRkcmVzc2VzCgkwIG5vIHJldHVy biByb3V0ZXMKaWdtcDoKCTAgbWVzc2FnZXMgcmVjZWl2ZWQKCTAgbWVzc2FnZXMg cmVjZWl2ZWQgd2l0aCB0b28gZmV3IGJ5dGVzCgkwIG1lc3NhZ2VzIHJlY2VpdmVk IHdpdGggd3JvbmcgVFRMCgkwIG1lc3NhZ2VzIHJlY2VpdmVkIHdpdGggYmFkIGNo ZWNrc3VtCgkwIFYxL1YyIG1lbWJlcnNoaXAgcXVlcmllcyByZWNlaXZlZAoJMCBW MyBtZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQKCTAgbWVtYmVyc2hpcCBxdWVy aWVzIHJlY2VpdmVkIHdpdGggaW52YWxpZCBmaWVsZChzKQoJMCBnZW5lcmFsIHF1 ZXJpZXMgcmVjZWl2ZWQKCTAgZ3JvdXAgcXVlcmllcyByZWNlaXZlZAoJMCBncm91 cC1zb3VyY2UgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cC1zb3VyY2UgcXVlcmll cyBkcm9wcGVkCgkwIG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZlZAoJMCBtZW1i ZXJzaGlwIHJlcG9ydHMgcmVjZWl2ZWQgd2l0aCBpbnZhbGlkIGZpZWxkKHMpCgkw IG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZlZCBmb3IgZ3JvdXBzIHRvIHdoaWNo IHdlIGJlbG9uZwoJMCBWMyByZXBvcnRzIHJlY2VpdmVkIHdpdGhvdXQgUm91dGVy IEFsZXJ0CgkwIG1lbWJlcnNoaXAgcmVwb3J0cyBzZW50CmlwNjoKCTIyMSB0b3Rh bCBwYWNrZXRzIHJlY2VpdmVkCgkwIHdpdGggc2l6ZSBzbWFsbGVyIHRoYW4gbWlu aW11bQoJMCB3aXRoIGRhdGEgc2l6ZSA8IGRhdGEgbGVuZ3RoCgkwIHdpdGggYmFk IG9wdGlvbnMKCTAgd2l0aCBpbmNvcnJlY3QgdmVyc2lvbiBudW1iZXIKCTAgZnJh Z21lbnRzIHJlY2VpdmVkCgkwIGZyYWdtZW50cyBkcm9wcGVkIChkdXAgb3Igb3V0 IG9mIHNwYWNlKQoJMCBmcmFnbWVudHMgZHJvcHBlZCBhZnRlciB0aW1lb3V0Cgkw IGZyYWdtZW50cyB0aGF0IGV4Y2VlZGVkIGxpbWl0CgkwIHBhY2tldHMgcmVhc3Nl bWJsZWQgb2sKCTIyMSBwYWNrZXRzIGZvciB0aGlzIGhvc3QKCTAgcGFja2V0cyBm b3J3YXJkZWQKCTAgcGFja2V0cyBub3QgZm9yd2FyZGFibGUKCTAgcmVkaXJlY3Rz IHNlbnQKCTIyMSBwYWNrZXRzIHNlbnQgZnJvbSB0aGlzIGhvc3QKCTAgcGFja2V0 cyBzZW50IHdpdGggZmFicmljYXRlZCBpcCBoZWFkZXIKCTAgb3V0cHV0IHBhY2tl dHMgZHJvcHBlZCBkdWUgdG8gbm8gYnVmcywgZXRjLgoJMCBvdXRwdXQgcGFja2V0 cyBkaXNjYXJkZWQgZHVlIHRvIG5vIHJvdXRlCgkwIG91dHB1dCBkYXRhZ3JhbXMg ZnJhZ21lbnRlZAoJMCBmcmFnbWVudHMgY3JlYXRlZAoJMCBkYXRhZ3JhbXMgdGhh dCBjYW4ndCBiZSBmcmFnbWVudGVkCgkwIHBhY2tldHMgdGhhdCB2aW9sYXRlZCBz Y29wZSBydWxlcwoJMCBtdWx0aWNhc3QgcGFja2V0cyB3aGljaCB3ZSBkb24ndCBq b2luCglJbnB1dCBoaXN0b2dyYW06CgkJVURQOiAyMjEKCU1idWYgc3RhdGlzdGlj czoKCQkxMzYgb25lIG1idWYKCQk4NSBvbmUgZXh0IG1idWYKCQkwIHR3byBvciBt b3JlIGV4dCBtYnVmCgkwIHBhY2tldHMgd2hvc2UgaGVhZGVycyBhcmUgbm90IGNv bnRpbnVvdXMKCTAgdHVubmVsaW5nIHBhY2tldHMgdGhhdCBjYW4ndCBmaW5kIGdp ZgoJMCBwYWNrZXRzIGRpc2NhcmRlZCBiZWNhdXNlIG9mIHRvbyBtYW55IGhlYWRl cnMKCTAgZmFpbHVyZXMgb2Ygc291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uCglTb3Vy Y2UgYWRkcmVzc2VzIHNlbGVjdGlvbiBydWxlIGFwcGxpZWQ6CmljbXA2OgoJMCBj YWxscyB0byBpY21wNl9lcnJvcgoJMCBlcnJvcnMgbm90IGdlbmVyYXRlZCBpbiBy ZXNwb25zZSB0byBhbiBpY21wNiBtZXNzYWdlCgkwIGVycm9ycyBub3QgZ2VuZXJh dGVkIGJlY2F1c2Ugb2YgcmF0ZSBsaW1pdGF0aW9uCgkwIG1lc3NhZ2VzIHdpdGgg YmFkIGNvZGUgZmllbGRzCgkwIG1lc3NhZ2VzIDwgbWluaW11bSBsZW5ndGgKCTAg YmFkIGNoZWNrc3VtcwoJMCBtZXNzYWdlcyB3aXRoIGJhZCBsZW5ndGgKCUhpc3Rv Z3JhbSBvZiBlcnJvciBtZXNzYWdlcyB0byBiZSBnZW5lcmF0ZWQ6CgkJMCBubyBy b3V0ZQoJCTAgYWRtaW5pc3RyYXRpdmVseSBwcm9oaWJpdGVkCgkJMCBiZXlvbmQg c2NvcGUKCQkwIGFkZHJlc3MgdW5yZWFjaGFibGUKCQkwIHBvcnQgdW5yZWFjaGFi bGUKCQkwIHBhY2tldCB0b28gYmlnCgkJMCB0aW1lIGV4Y2VlZCB0cmFuc2l0CgkJ MCB0aW1lIGV4Y2VlZCByZWFzc2VtYmx5CgkJMCBlcnJvbmVvdXMgaGVhZGVyIGZp ZWxkCgkJMCB1bnJlY29nbml6ZWQgbmV4dCBoZWFkZXIKCQkwIHVucmVjb2duaXpl ZCBvcHRpb24KCQkwIHJlZGlyZWN0CgkJMCB1bmtub3duCgkwIG1lc3NhZ2UgcmVz cG9uc2VzIGdlbmVyYXRlZAoJMCBtZXNzYWdlcyB3aXRoIHRvbyBtYW55IE5EIG9w dGlvbnMKCTAgbWVzc2FnZXMgd2l0aCBiYWQgTkQgb3B0aW9ucwoJMCBiYWQgbmVp Z2hib3Igc29saWNpdGF0aW9uIG1lc3NhZ2VzCgkwIGJhZCBuZWlnaGJvciBhZHZl cnRpc2VtZW50IG1lc3NhZ2VzCgkwIGJhZCByb3V0ZXIgc29saWNpdGF0aW9uIG1l c3NhZ2VzCgkwIGJhZCByb3V0ZXIgYWR2ZXJ0aXNlbWVudCBtZXNzYWdlcwoJMCBi YWQgcmVkaXJlY3QgbWVzc2FnZXMKCTAgcGF0aCBNVFUgY2hhbmdlcwpyaXA2OgoJ MCBtZXNzYWdlcyByZWNlaXZlZAoJMCBjaGVja3N1bSBjYWxjdWxhdGlvbnMgb24g aW5ib3VuZAoJMCBtZXNzYWdlcyB3aXRoIGJhZCBjaGVja3N1bQoJMCBtZXNzYWdl cyBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTAgbXVsdGljYXN0IG1lc3NhZ2Vz IGRyb3BwZWQgZHVlIHRvIG5vIHNvY2tldAoJMCBtZXNzYWdlcyBkcm9wcGVkIGR1 ZSB0byBmdWxsIHNvY2tldCBidWZmZXJzCgkwIGRlbGl2ZXJlZAoJMCBkYXRhZ3Jh bXMgb3V0cHV0CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtbQoK Mzc4Lzc4MC8xMTU4IG1idWZzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbCkK Mjk4LzM2Ni82NjQvMjU2MDAgbWJ1ZiBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQv Y2FjaGUvdG90YWwvbWF4KQozMDEvMzQyIG1idWYrY2x1c3RlcnMgb3V0IG9mIHBh Y2tldCBzZWNvbmRhcnkgem9uZSBpbiB1c2UgKGN1cnJlbnQvY2FjaGUpCjczLzEx My8xODYvMTI4MDAgNGsgKHBhZ2Ugc2l6ZSkganVtYm8gY2x1c3RlcnMgaW4gdXNl IChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAvMTkyMDAgOWsganVtYm8g Y2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAv MTI4MDAgMTZrIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90 b3RhbC9tYXgpCjk4NUsvMTM3OUsvMjM2NEsgYnl0ZXMgYWxsb2NhdGVkIHRvIG5l dHdvcmsgKGN1cnJlbnQvY2FjaGUvdG90YWwpCjAvMC8wIHJlcXVlc3RzIGZvciBt YnVmcyBkZW5pZWQgKG1idWZzL2NsdXN0ZXJzL21idWYrY2x1c3RlcnMpCjAvMC8w IHJlcXVlc3RzIGZvciBqdW1ibyBjbHVzdGVycyBkZW5pZWQgKDRrLzlrLzE2aykK MCByZXF1ZXN0cyBmb3Igc2ZidWZzIGRlbmllZAowIHJlcXVlc3RzIGZvciBzZmJ1 ZnMgZGVsYXllZAowIHJlcXVlc3RzIGZvciBJL08gaW5pdGlhdGVkIGJ5IHNlbmRm aWxlCjAgY2FsbHMgdG8gcHJvdG9jb2wgZHJhaW4gcm91dGluZXMKCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1pZAoKTmFtZSAgICBNdHUgTmV0d29y ayAgICAgICBBZGRyZXNzICAgICAgICAgICAgICBJcGt0cyBJZXJycyAgICBPcGt0 cyBPZXJycyAgQ29sbCBEcm9wCnJlMCAgICAxNTAwIDxMaW5rIzE+ICAgICAgMDA6 MWU6MzM6Y2I6MjY6OGUgICAgICAgNDUgICAgIDAgICAgICAgIDAgICAgIDAgICAg IDAgICAgMCAKcmUwICAgIDE1MDAgMTkyLjE2OC4yNDAuMSAxOTIuMTY4LjI0MC4x MDEgICAgICAgICAxMiAgICAgLSAgICAgICA0NSAgICAgLSAgICAgLSAgICAtIApp d24wICAgMjI5MCA8TGluayMyPiAgICAgIDAwOjFlOjY1OjM5OjU5OjM4ICAgICAg ICAwICAgICAwICAgICAgICAwICAgICAwICAgICAwICAgIDAgCmxvMCAgIDE2Mzg0 IDxMaW5rIzM+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyMzMgICAgIDAg ICAgICAyMzMgICAgIDAgICAgIDAgICAgMCAKbG8wICAgMTYzODQgZmU4MDozOjox ICAgICBmZTgwOjM6OjEgICAgICAgICAgICAgICAgMCAgICAgLSAgICAgICAgMCAg ICAgLSAgICAgLSAgICAtIApsbzAgICAxNjM4NCBsb2NhbGhvc3QgICAgIDo6MSAg ICAgICAgICAgICAgICAgICAgICAwICAgICAtICAgICAgMjIxICAgICAtICAgICAt ICAgIC0gCmxvMCAgIDE2Mzg0IHlvdXItbmV0ICAgICAgbG9jYWxob3N0ICAgICAg ICAgICAgICAgIDAgICAgIC0gICAgICAgMTIgICAgIC0gICAgIC0gICAgLSAKd2xh bjAgIDE1MDAgPExpbmsjND4gICAgICAwMDoxZTo2NTozOTo1OTozOCAgICA0NDU2 NCAgICAgMCAgICAzMjYyMCAgICAgMCAgICAgMCAgICAwIAp3bGFuMCAgMTUwMCAx OTIuMTY4LjEuMCAgIDE5Mi4xNjguMS4xMyAgICAgICAgIDQ0MTMxICAgICAtICAg IDMyNjEyICAgICAtICAgICAtICAgIC0gCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KbmV0c3RhdCAtYW5yCgpSb3V0aW5nIHRhYmxlcwoKSW50ZXJuZXQ6CkRlc3Rp bmF0aW9uICAgICAgICBHYXRld2F5ICAgICAgICAgICAgRmxhZ3MgICAgUmVmcyAg ICAgIFVzZSAgTmV0aWYgRXhwaXJlCmRlZmF1bHQgICAgICAgICAgICAxOTIuMTY4 LjEuMSAgICAgICAgVUdTICAgICAgICAgNiAgICAzMjUxNyAgd2xhbjAKMTI3LjAu MC4xICAgICAgICAgIGxpbmsjMyAgICAgICAgICAgICBVSCAgICAgICAgICAwICAg ICAgICAwICAgIGxvMAoxOTIuMTY4LjEuMC8yNCAgICAgbGluayM0ICAgICAgICAg ICAgIFUgICAgICAgICAgIDAgICAgICAgNTAgIHdsYW4wCjE5Mi4xNjguMS4xMyAg ICAgICBsaW5rIzQgICAgICAgICAgICAgVUhTICAgICAgICAgMCAgICAgICAgMCAg ICBsbzAKMTkyLjE2OC4yNDAuMTAxICAgIGxpbmsjMSAgICAgICAgICAgICBVSFMg ICAgICAgICAwICAgICAgIDEyICAgIGxvMCA9PgoxOTIuMTY4LjI0MC4xMDEvMzIg bGluayMxICAgICAgICAgICAgIFUgICAgICAgICAgIDAgICAgICAgIDAgICAgcmUw CgpJbnRlcm5ldDY6CkRlc3RpbmF0aW9uICAgICAgICAgICAgICAgICAgICAgICBH YXRld2F5ICAgICAgICAgICAgICAgICAgICAgICBGbGFncyAgICAgIE5ldGlmIEV4 cGlyZQo6OjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOjoxICAgICAg ICAgICAgICAgICAgICAgICAgICAgVUggICAgICAgICAgbG8wCmZlODA6OiVsbzAv NjQgICAgICAgICAgICAgICAgICAgICBsaW5rIzMgICAgICAgICAgICAgICAgICAg ICAgICBVICAgICAgICAgICBsbzAKZmU4MDo6MSVsbzAgICAgICAgICAgICAgICAg ICAgICAgIGxpbmsjMyAgICAgICAgICAgICAgICAgICAgICAgIFVIUyAgICAgICAg IGxvMApmZjAxOjM6Oi8zMiAgICAgICAgICAgICAgICAgICAgICAgZmU4MDo6MSVs bzAgICAgICAgICAgICAgICAgICAgVSAgICAgICAgICAgbG8wCmZmMDI6OiVsbzAv MzIgICAgICAgICAgICAgICAgICAgICBmZTgwOjoxJWxvMCAgICAgICAgICAgICAg ICAgICBVICAgICAgICAgICBsbzAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpu ZXRzdGF0IC1hbkEKCkFjdGl2ZSBJbnRlcm5ldCBjb25uZWN0aW9ucyAoaW5jbHVk aW5nIHNlcnZlcnMpClRjcGNiICAgIFByb3RvIFJlY3YtUSBTZW5kLVEgIExvY2Fs IEFkZHJlc3MgICAgICBGb3JlaWduIEFkZHJlc3MgICAoc3RhdGUpCmM5MzkwMjc4 IHRjcDQgICAgICAgMCAgICAgIDAgMTkyLjE2OC4xLjEzLjE4NzQwIDc0LjEyNS45 MS4xMDkuOTkzICBFU1RBQkxJU0hFRApjODMwNzAwMCB0Y3A0ICAgMTI3NjIgICAg ICAwIDE5Mi4xNjguMS4xMy42MjE4OSA3NC4xMjUuOTEuMTA5Ljk5MyAgRVNUQUJM SVNIRUQKYzkzOGMwMDAgdGNwNCAgICAgICAwICAgICAgMCAqLjg4NDAgICAgICAg ICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpjNzU4MzAwMCB0Y3A0ICAg ICAgIDAgICAgICAwIDE5Mi4xNjguMS4xMy40NDUzMyAyMTMuMjM2LjIwOC4zMy4x NjYgRVNUQUJMSVNIRUQKYzc1ODNjNTggdGNwNCAgICAgICAwICAgICAgMCAxOTIu MTY4LjI0MC4xMDEuMjUgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpjNzM0NTAw MCB0Y3A0ICAgICAgIDAgICAgICAwICouKiAgICAgICAgICAgICAgICAqLiogICAg ICAgICAgICAgICAgQ0xPU0VECmM3MzQ1Mjc4IHRjcDQ2ICAgICAgMCAgICAgIDAg Ki44MCAgICAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KYzcz NDU5ZTAgdGNwNCAgICAgICAwICAgICAgMCAqLjIyICAgICAgICAgICAgICAgKi4q ICAgICAgICAgICAgICAgIExJU1RFTgpjNzRlODRmMCB0Y3A2ICAgICAgIDAgICAg ICAwICouMjIgICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVO CmM3MzQ1YzU4IHRjcDQgICAgICAgMCAgICAgIDAgMTI3LjAuMC4xLjU0MzIgICAg ICouKiAgICAgICAgICAgICAgICBMSVNURU4KYzczNDYwMDAgdGNwNiAgICAgICAw ICAgICAgMCA6OjEuNTQzMiAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJ U1RFTgpjNzAyMTQ0YyB1ZHA0ICAgICAgIDAgICAgICAwIDE5Mi4xNjguMS4xMy42 NDA4MCAqLiogICAgICAgICAgICAgICAgCmM3MDIwYjJjIHVkcDQgICAgICAgMCAg ICAgIDAgMjM5LjI1NS4yNTUuMjUwLjE5ICouKiAgICAgICAgICAgICAgICAKYzcw MjE2ZTAgdWRwNCAgICAgICAwICAgICAgMCAxOTIuMTY4LjI0MC4xMDEuMzkgKi4q ICAgICAgICAgICAgICAgIApjNzAzMzFiOCB1ZHA0ICAgICAgIDAgICAgICAwIDIz OS4yNTUuMjU1LjI1MC4xOSAqLiogICAgICAgICAgICAgICAgCmM3MDIwMzcwIHVk cDQgICAgICAgMCAgICAgIDAgMTkyLjE2OC4yNDAuMTAxLjUxICouKiAgICAgICAg ICAgICAgICAKYzcwMjFjZTQgdWRwNiAgICAgICAwICAgICAgMCA6OjEuMTE3OTkg ICAgICAgICAgOjoxLjExNzk5ICAgICAgICAgIApjNzAyMDZlMCB1ZHA0ICAgICAg IDAgICAgICAwICouNTE0ICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAg CmM3MDIwODk4IHVkcDYgICAgICAgMCAgICAgIDAgKi41MTQgICAgICAgICAgICAg ICouKiAgICAgICAgICAgICAgICAKYzcwMjBhNTAgdWRwNCAgICAgICAwICAgICAg MCAqLiogICAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIApBY3RpdmUg VU5JWCBkb21haW4gc29ja2V0cwpBZGRyZXNzICBUeXBlICAgUmVjdi1RIFNlbmQt USAgICBJbm9kZSAgICAgQ29ubiAgICAgUmVmcyAgTmV4dHJlZiBBZGRyCmM3ZTZj NzY0IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGM3ZGZhYjZjICAgICAg ICAwICAgICAgICAwIC90bXAvLklDRS11bml4LzE1MDEKYzdkZmFiNmMgc3RyZWFt ICAgICAgMCAgICAgIDAgICAgICAgIDAgYzdlNmM3NjQgICAgICAgIDAgICAgICAg IDAKYzdkZmFlMWMgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzdlNmMx NTggICAgICAgIDAgICAgICAgIDAgL3RtcC8uWDExLXVuaXgvWDAKYzdlNmMxNTgg c3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzdkZmFlMWMgICAgICAgIDAg ICAgICAgIDAKYzdlNmMyMDQgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAg YzdkZmFkNzAgICAgICAgIDAgICAgICAgIDAgL3RtcC8uSUNFLXVuaXgvZGNvcDE0 OTAtMTI1OTIwMDEyMgpjN2RmYWQ3MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAg ICAgMCBjN2U2YzIwNCAgICAgICAgMCAgICAgICAgMApjN2RmYWNjNCBzdHJlYW0g ICAgICAwICAgICAgMCAgICAgICAgMCBjN2RmYWVjOCAgICAgICAgMCAgICAgICAg MCAvdG1wLy5JQ0UtdW5peC8xNTAxCmM3ZGZhZWM4IHN0cmVhbSAgICAgIDAgICAg ICAwICAgICAgICAwIGM3ZGZhY2M0ICAgICAgICAwICAgICAgICAwCmM3ZTZjNTYw IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGM3ZGZhNmI4ICAgICAgICAw ICAgICAgICAwIC90bXAvLlgxMS11bml4L1gwCmM3ZGZhNmI4IHN0cmVhbSAgICAg IDAgICAgICAwICAgICAgICAwIGM3ZTZjNTYwICAgICAgICAwICAgICAgICAwCmM3 ZTZjMzVjIHN0cmVhbSAgICAgIDAgICAgICAwIGM3ZTczOTZjICAgICAgICAwICAg ICAgICAwICAgICAgICAwIC90bXAva3NvY2tldC1nYmFyYmVyL2xvY2FsaG9zdC0w NWU2LTRiMGRkZTdlCmM3YzgxMGFjIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAg ICAwIGM3YzgxMjA0ICAgICAgICAwICAgICAgICAwIC90bXAvLlgxMS11bml4L1gw CmM3YzgxMjA0IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGM3YzgxMGFj ICAgICAgICAwICAgICAgICAwCmM3MDIzOGJjIHN0cmVhbSAgICAgIDAgICAgICAw ICAgICAgICAwIGM3MDIzMDAwICAgICAgICAwICAgICAgICAwIC90bXAvLklDRS11 bml4LzE1MDEKYzcwMjMwMDAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAg YzcwMjM4YmMgICAgICAgIDAgICAgICAgIDAKYzdjODE0MDggc3RyZWFtICAgICAg MCAgICAgIDAgICAgICAgIDAgYzdjODE0YjQgICAgICAgIDAgICAgICAgIDAgL3Rt cC8uWDExLXVuaXgvWDAKYzdjODE0YjQgc3RyZWFtICAgICAgMCAgICAgIDAgICAg ICAgIDAgYzdjODE0MDggICAgICAgIDAgICAgICAgIDAKYzdjODE2Yjggc3RyZWFt ICAgICAgMCAgICAgIDAgICAgICAgIDAgYzdjODE3NjQgICAgICAgIDAgICAgICAg IDAgL3RtcC8uSUNFLXVuaXgvZGNvcDE0OTAtMTI1OTIwMDEyMgpjN2M4MTc2NCBz dHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBjN2M4MTZiOCAgICAgICAgMCAg ICAgICAgMApjN2M4MTgxMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBj N2M4MThiYyAgICAgICAgMCAgICAgICAgMCAvdG1wLy5JQ0UtdW5peC8xNTAxCmM3 YzgxOGJjIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGM3YzgxODEwICAg ICAgICAwICAgICAgICAwCmM3YzgxOTY4IHN0cmVhbSAgICAgIDAgICAgICAwICAg ICAgICAwIGM3YzgxYTE0ICAgICAgICAwICAgICAgICAwIC90bXAvLlgxMS11bml4 L1gwCmM3YzgxYTE0IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGM3Yzgx OTY4ICAgICAgICAwICAgICAgICAwCmM3YzgxYWMwIHN0cmVhbSAgICAgIDAgICAg ICAwICAgICAgICAwIGM3YzgxYjZjICAgICAgICAwICAgICAgICAwIC90bXAvLklD RS11bml4L2Rjb3AxNDkwLTEyNTkyMDAxMjIKYzdjODFiNmMgc3RyZWFtICAgICAg MCAgICAgIDAgICAgICAgIDAgYzdjODFhYzAgICAgICAgIDAgICAgICAgIDAKYzdj ODEzNWMgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzcwMjQ3NjQgICAg ICAgIDAgICAgICAgIDAgL3RtcC8uWDExLXVuaXgvWDAKYzcwMjQ3NjQgc3RyZWFt ICAgICAgMCAgICAgIDAgICAgICAgIDAgYzdjODEzNWMgICAgICAgIDAgICAgICAg IDAKYzcwZWJkNzAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzcwMjNl YzggICAgICAgIDAgICAgICAgIDAgL3RtcC8uSUNFLXVuaXgvZGNvcDE0OTAtMTI1 OTIwMDEyMgpjNzAyM2VjOCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBj NzBlYmQ3MCAgICAgICAgMCAgICAgICAgMApjNzAyNDAwMCBzdHJlYW0gICAgICAw ICAgICAgMCAgICAgICAgMCBjNzAyM2NjNCAgICAgICAgMCAgICAgICAgMCAvdG1w L2ZhbS1nYmFyYmVyL2ZhbS0KYzcwMjNjYzQgc3RyZWFtICAgICAgMCAgICAgIDAg ICAgICAgIDAgYzcwMjQwMDAgICAgICAgIDAgICAgICAgIDAKYzdjODFjMTggc3Ry ZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzdjODFjYzQgICAgICAgIDAgICAg ICAgIDAgL3RtcC8uSUNFLXVuaXgvMTUwMQpjN2M4MWNjNCBzdHJlYW0gICAgICAw ICAgICAgMCAgICAgICAgMCBjN2M4MWMxOCAgICAgICAgMCAgICAgICAgMApjN2M4 MWQ3MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBjN2M4MWUxYyAgICAg ICAgMCAgICAgICAgMCAvdG1wLy5YMTEtdW5peC9YMApjN2M4MWUxYyBzdHJlYW0g ICAgICAwICAgICAgMCAgICAgICAgMCBjN2M4MWQ3MCAgICAgICAgMCAgICAgICAg MApjN2RmYTIwNCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBjN2RmYTJi MCAgICAgICAgMCAgICAgICAgMCAvdG1wLy5JQ0UtdW5peC9kY29wMTQ5MC0xMjU5 MjAwMTIyCmM3ZGZhMmIwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGM3 ZGZhMjA0ICAgICAgICAwICAgICAgICAwCmM3MDI0ZDcwIHN0cmVhbSAgICAgIDAg ICAgICAwICAgICAgICAwIGM3MDI0ZWM4ICAgICAgICAwICAgICAgICAwIC90bXAv LklDRS11bml4LzE1MDEKYzcwMjRlYzggc3RyZWFtICAgICAgMCAgICAgIDAgICAg ICAgIDAgYzcwMjRkNzAgICAgICAgIDAgICAgICAgIDAKYzcwZWIwMDAgc3RyZWFt ICAgICAgMCAgICAgIDAgICAgICAgIDAgYzcwMjNhYzAgICAgICAgIDAgICAgICAg IDAgL3RtcC8uWDExLXVuaXgvWDAKYzcwMjNhYzAgc3RyZWFtICAgICAgMCAgICAg IDAgICAgICAgIDAgYzcwZWIwMDAgICAgICAgIDAgICAgICAgIDAKYzdkZmE2MGMg c3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzcwZWI0MDggICAgICAgIDAg ICAgICAgIDAgL3RtcC8uSUNFLXVuaXgvZGNvcDE0OTAtMTI1OTIwMDEyMgpjNzBl YjQwOCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBjN2RmYTYwYyAgICAg ICAgMCAgICAgICAgMApjNzAyMzRiNCBzdHJlYW0gICAgICAwICAgICAgMCAgICAg ICAgMCBjNzBlYjIwNCAgICAgICAgMCAgICAgICAgMCAvdG1wLy5JQ0UtdW5peC8x NTAxCmM3MGViMjA0IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGM3MDIz NGI0ICAgICAgICAwICAgICAgICAwCmM3MGViODEwIHN0cmVhbSAgICAgIDAgICAg ICAwICAgICAgICAwIGM3MDIzODEwICAgICAgICAwICAgICAgICAwIC90bXAvLklD RS11bml4L2Rjb3AxNDkwLTEyNTkyMDAxMjIKYzcwMjM4MTAgc3RyZWFtICAgICAg MCAgICAgIDAgICAgICAgIDAgYzcwZWI4MTAgICAgICAgIDAgICAgICAgIDAKYzcw MjNhMTQgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzcwMjNiNmMgICAg ICAgIDAgICAgICAgIDAgL3RtcC8uSUNFLXVuaXgvMTUwMQpjNzAyM2I2YyBzdHJl YW0gICAgICAwICAgICAgMCAgICAgICAgMCBjNzAyM2ExNCAgICAgICAgMCAgICAg ICAgMApjNzAyMzk2OCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBjNzBl YjE1OCAgICAgICAgMCAgICAgICAgMCAvdG1wLy5YMTEtdW5peC9YMApjNzBlYjE1 OCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBjNzAyMzk2OCAgICAgICAg MCAgICAgICAgMApjNzBlYjYwYyBzdHJlYW0gICAgICAwICAgICAgMCBjN2RkOGQ5 YyAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAvdG1wLy5JQ0UtdW5peC8xNTAx CmM3MGViNTYwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGM3MGViNGI0 ICAgICAgICAwICAgICAgICAwIC90bXAvLklDRS11bml4L2Rjb3AxNDkwLTEyNTky MDAxMjIKYzcwZWI0YjQgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzcw ZWI1NjAgICAgICAgIDAgICAgICAgIDAKYzcwMjM2MGMgc3RyZWFtICAgICAgMCAg ICAgIDAgICAgICAgIDAgYzcwZWI4YmMgICAgICAgIDAgICAgICAgIDAgL3RtcC8u WDExLXVuaXgvWDAKYzcwZWI4YmMgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAg IDAgYzcwMjM2MGMgICAgICAgIDAgICAgICAgIDAKYzcwZWIyYjAgc3RyZWFtICAg ICAgMCAgICAgIDAgICAgICAgIDAgYzcwZWIzNWMgICAgICAgIDAgICAgICAgIDAg L3RtcC9rc29ja2V0LWdiYXJiZXIva2RlaW5pdF9fMApjNzBlYjM1YyBzdHJlYW0g ICAgICAwICAgICAgMCAgICAgICAgMCBjNzBlYjJiMCAgICAgICAgMCAgICAgICAg MApjN2M4MTE1OCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBjN2M4MTAw MCAgICAgICAgMCAgICAgICAgMCAvdG1wL2ZhbS1nYmFyYmVyL2ZhbS0KYzdjODEw MDAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzdjODExNTggICAgICAg IDAgICAgICAgIDAKYzcwZWI2Yjggc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAg IDAgYzcwZWI3NjQgICAgICAgIDAgICAgICAgIDAgL3RtcC8uWDExLXVuaXgvWDAK YzcwZWI3NjQgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzcwZWI2Yjgg ICAgICAgIDAgICAgICAgIDAKYzcwZWJlMWMgc3RyZWFtICAgICAgMCAgICAgIDAg ICAgICAgIDAgYzcwZWJjYzQgICAgICAgIDAgICAgICAgIDAgL3RtcC8uSUNFLXVu aXgvZGNvcDE0OTAtMTI1OTIwMDEyMgpjNzBlYmNjNCBzdHJlYW0gICAgICAwICAg ICAgMCAgICAgICAgMCBjNzBlYmUxYyAgICAgICAgMCAgICAgICAgMApjNzAyNGUx YyBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBjNzAyM2MxOCAgICAgICAg MCAgICAgICAgMCAvdG1wLy5YMTEtdW5peC9YMApjNzAyM2MxOCBzdHJlYW0gICAg ICAwICAgICAgMCAgICAgICAgMCBjNzAyNGUxYyAgICAgICAgMCAgICAgICAgMApj NzAyNDk2OCBzdHJlYW0gICAgICAwICAgICAgMCBjN2I5NGQ5YyAgICAgICAgMCAg ICAgICAgMCAgICAgICAgMCAvdG1wL2tzb2NrZXQtZ2JhcmJlci9rbGF1bmNoZXJW eXhUMzguc2xhdmUtc29ja2V0CmM3MDI0Y2M0IHN0cmVhbSAgICAgIDAgICAgICAw ICAgICAgICAwIGM3MGViMGFjICAgICAgICAwICAgICAgICAwIC90bXAvLklDRS11 bml4L2Rjb3AxNDkwLTEyNTkyMDAxMjIKYzcwZWIwYWMgc3RyZWFtICAgICAgMCAg ICAgIDAgICAgICAgIDAgYzcwMjRjYzQgICAgICAgIDAgICAgICAgIDAKYzcwZWI5 Njggc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgYzcwZWJhMTQgICAgICAg IDAgICAgICAgIDAKYzcwZWJhMTQgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAg IDAgYzcwZWI5NjggICAgICAgIDAgICAgICAgIDAKYzcwZWJhYzAgc3RyZWFtICAg ICAgMCAgICAgIDAgYzc1NWQwMDAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAg L3RtcC8uSUNFLXVuaXgvZGNvcDE0OTAtMTI1OTIwMDEyMgpjNzAyNDYwYyBzdHJl YW0gICAgICAwICAgICAgMCBjNzVjNWE3OCAgICAgICAgMCAgICAgICAgMCAgICAg ICAgMCAvdG1wL2tzb2NrZXQtZ2JhcmJlci9rZGVpbml0LTowCmM3MDI0ODEwIHN0 cmVhbSAgICAgIDAgICAgICAwIGM3MjBmNzU0ICAgICAgICAwICAgICAgICAwICAg ICAgICAwIC90bXAva3NvY2tldC1nYmFyYmVyL2tkZWluaXRfXzAKYzcwMjQ0YjQg c3RyZWFtICAgICAgMCAgICAgIDAgYzdjNmRiODQgICAgICAgIDAgICAgICAgIDAg ICAgICAgIDAgL3RtcC9mYW0tZ2JhcmJlci9mYW0tCmM3MDIzNzY0IHN0cmVhbSAg ICAgIDAgICAgICAwIGM3Yjk0Yjg0ICAgICAgICAwICAgICAgICAwICAgICAgICAw IC90bXAvc3NoLVlkNEcyc2p3djcvYWdlbnQuMTQzMwpjNzAyNDU2MCBzdHJlYW0g ICAgICAwICAgICAgMCAgICAgICAgMCBjNzAyNDQwOCAgICAgICAgMCAgICAgICAg MCAvdG1wLy5YMTEtdW5peC9YMApjNzAyNDQwOCBzdHJlYW0gICAgIDY0ICAgICAg MCAgICAgICAgMCBjNzAyNDU2MCAgICAgICAgMCAgICAgICAgMApjNzAyMzBhYyBz dHJlYW0gICAgICAwICAgICAgMCBjN2I2OTk2YyAgICAgICAgMCAgICAgICAgMCAg ICAgICAgMCAvdmFyL3J1bi94ZG1jdGwvZG1jdGwtOjAvc29ja2V0CmM3MDIzMTU4 IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGM3MDIzMjA0ICAgICAgICAw ICAgICAgICAwCmM3MDIzMjA0IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAw IGM3MDIzMTU4ICAgICAgICAwICAgICAgICAwCmM3MDIzMmIwIHN0cmVhbSAgICAg IDAgICAgICAwIGM3NWM1ODYwICAgICAgICAwICAgICAgICAwICAgICAgICAwIC90 bXAvLlgxMS11bml4L1gwCmM3MDI0MzVjIHN0cmVhbSAgICAgIDAgICAgICAwIGM3 NWJiYTc4ICAgICAgICAwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL3hkbWN0 bC9kbWN0bC9zb2NrZXQKYzcwMjQwYWMgc3RyZWFtICAgICAgMCAgICAgIDAgICAg ICAgIDAgYzcwMjQxNTggICAgICAgIDAgICAgICAgIDAKYzcwMjQxNTggc3RyZWFt ICAgICAgMCAgICAgIDAgICAgICAgIDAgYzcwMjQwYWMgICAgICAgIDAgICAgICAg IDAKYzcwMjM2Yjggc3RyZWFtICAgICAgMCAgICAgIDAgYzczM2JkOWMgICAgICAg IDAgICAgICAgIDAgICAgICAgIDAgL3RtcC8ucy5QR1NRTC41NDMyCmM3MDIzZDcw IHN0cmVhbSAgICAgIDAgICAgICAwIGM3MDJlYzkwICAgICAgICAwICAgICAgICAw ICAgICAgICAwIC92YXIvcnVuL2RldmQucGlwZQpjNzAyNDIwNCBkZ3JhbSAgICAg ICAwICAgICAgMCAgICAgICAgMCBjNzAyMzQwOCAgICAgICAgMCAgICAgICAgMApj NzAyNDJiMCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAgICAgMCBjNzAyMzM1YyAg ICAgICAgMCAgICAgICAgMApjNzAyMzM1YyBkZ3JhbSAgICAgICAwICAgICAgMCBj NzU2NWQ5YyAgICAgICAgMCBjNzAyNDJiMCAgICAgICAgMCAvdmFyL3J1bi9sb2dw cml2CmM3MDIzNDA4IGRncmFtICAgICAgIDAgICAgICAwIGM3NTdhMDAwICAgICAg ICAwIGM3MDI0MjA0ICAgICAgICAwIC92YXIvcnVuL2xvZwpjNzAyMzU2MCBkZ3Jh bSAgICAgICAwICAgICAgMCAgICAgICAgMCBjNzAyNGMxOCAgICAgICAgMCBjNzAy NDZiOApjNzAyNDZiOCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAgICAgMCBjNzAy NGMxOCAgICAgICAgMCAgICAgICAgMApjNzAyNGExNCBkZ3JhbSAgICAgICAwICAg ICAgMCAgICAgICAgMCBjNzAyNGI2YyAgICAgICAgMCBjNzAyNGFjMApjNzAyNGFj MCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAgICAgMCBjNzAyNGI2YyAgICAgICAg MCAgICAgICAgMApjNzAyNGI2YyBkZ3JhbSAgICAgICAwICAgICAgMCBjNzIwNGQ5 YyAgICAgICAgMCBjNzAyNGExNCAgICAgICAgMCAvdmFyL3J1bi9sb2dwcml2CmM3 MDI0YzE4IGRncmFtICAgICAgIDAgICAgICAwIGM3MjA1MDAwICAgICAgICAwIGM3 MDIzNTYwICAgICAgICAwIC92YXIvcnVuL2xvZwpjNzAyM2UxYyBkZ3JhbSAgICAg ICAwICAgICAgMCBjNzAyZDQzMCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAv dmFyL3J1bi93cGFfc3VwcGxpY2FudC93bGFuMAoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCm5ldHN0YXQgLWFMCgpDdXJyZW50IGxpc3RlbiBxdWV1ZSBzaXplcyAo cWxlbi9pbmNxbGVuL21heHFsZW4pClByb3RvIExpc3RlbiAgICAgICAgIExvY2Fs IEFkZHJlc3MgICAgICAgICAKdGNwNCAgMC8wLzEwICAgICAgICAgKi44ODQwICAg ICAgICAgICAgICAgICAKdGNwNCAgMC8wLzEwICAgICAgICAgMTkyLjE2OC4yNDAu MTAxLnNtdHAgICAKdGNwNDYgMC8wLzEyOCAgICAgICAgKi5odHRwICAgICAgICAg ICAgICAgICAKdGNwNCAgMC8wLzEyOCAgICAgICAgKi5zc2ggICAgICAgICAgICAg ICAgICAKdGNwNiAgMC8wLzEyOCAgICAgICAgKi5zc2ggICAgICAgICAgICAgICAg ICAKdGNwNCAgMC8wLzEyOCAgICAgICAgbG9jYWxob3N0LnBvc3RncmVzcWwgICAK dGNwNiAgMC8wLzEyOCAgICAgICAgbG9jYWxob3N0LnBvc3RncmVzcWwgICAKdW5p eCAgMC8wLzE2ICAgICAgICAgL3RtcC9rc29ja2V0LWdiYXJiZXIvbG9jYWxob3N0 LTA1ZTYtNGIwZGRlN2UKdW5peCAgMC8wLzEyOCAgICAgICAgL3RtcC8uSUNFLXVu aXgvMTUwMQp1bml4ICAwLzAvMTI4ICAgICAgICAvdG1wL2tzb2NrZXQtZ2JhcmJl ci9rbGF1bmNoZXJWeXhUMzguc2xhdmUtc29ja2V0CnVuaXggIDAvMC8xMjggICAg ICAgIC90bXAvLklDRS11bml4L2Rjb3AxNDkwLTEyNTkyMDAxMjIKdW5peCAgMC8w LzEyOCAgICAgICAgL3RtcC9rc29ja2V0LWdiYXJiZXIva2RlaW5pdC06MAp1bml4 ICAwLzAvMTI4ICAgICAgICAvdG1wL2tzb2NrZXQtZ2JhcmJlci9rZGVpbml0X18w CnVuaXggIDAvMC8zMCAgICAgICAgIC90bXAvZmFtLWdiYXJiZXIvZmFtLQp1bml4 ICAwLzAvMTI4ICAgICAgICAvdG1wL3NzaC1ZZDRHMnNqd3Y3L2FnZW50LjE0MzMK dW5peCAgMC8wLzUgICAgICAgICAgL3Zhci9ydW4veGRtY3RsL2RtY3RsLTowL3Nv Y2tldAp1bml4ICAwLzAvMTI4ICAgICAgICAvdG1wLy5YMTEtdW5peC9YMAp1bml4 ICAwLzAvNSAgICAgICAgICAvdmFyL3J1bi94ZG1jdGwvZG1jdGwvc29ja2V0CnVu aXggIDAvMC8xMjggICAgICAgIC90bXAvLnMuUEdTUUwuNTQzMgp1bml4ICAwLzAv NCAgICAgICAgICAvdmFyL3J1bi9kZXZkLnBpcGUKCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpkbWVzZwoKQ29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVC U0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2 LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50 cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJl c2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhl IEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtUFJFUkVMRUFTRSAjMTYg cjE5OTM0ME06IE1vbiBOb3YgMTYgMjE6MDA6MzAgRVNUIDIwMDkKICAgIGdiYXJi ZXJAcGVnYXN1czovdXNyL29iai91c3Ivc3JjL3N5cy9QRUdBU1VTIGkzODYKVGlt ZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAK Q1BVOiBJbnRlbChSKSBDb3JlKFRNKTIgRHVvIENQVSAgICAgVDY0MDAgIEAgMi4w MEdIeiAoMTk5NS4wMS1NSHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2Vu dWluZUludGVsIiAgSWQgPSAweDEwNjdhICBTdGVwcGluZyA9IDEwCiAgRmVhdHVy ZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4 LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERU UyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVy ZXMyPTB4NDA4ZTM5ZDxTU0UzLERURVM2NCxNT04sRFNfQ1BMLEVTVCxUTTIsU1NT RTMsQ1gxNix4VFBSLFBEQ00sU1NFNC4xLFhTQVZFPgogIEFNRCBGZWF0dXJlcz0w eDIwMTAwMDAwPE5YLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAgVFND OiBQLXN0YXRlIGludmFyaWFudApyZWFsIG1lbW9yeSAgPSAzMjIxMjI1NDcyICgz MDcyIE1CKQphdmFpbCBtZW1vcnkgPSAzMDA2MDk1MzYwICgyODY2IE1CKQpBQ1BJ IEFQSUMgVGFibGU6IDxUT1NJTlYgVE9TSU5WMDA+CkZyZWVCU0QvU01QOiBNdWx0 aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwpGcmVlQlNEL1NNUDog MSBwYWNrYWdlKHMpIHggMiBjb3JlKHMpCiBjcHUwIChCU1ApOiBBUElDIElEOiAg MAogY3B1MSAoQVApOiBBUElDIElEOiAgMQppb2FwaWMwOiBDaGFuZ2luZyBBUElD IElEIHRvIDQKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3Ro ZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYWNwaTA6IDxUT1NJTlYgVE9TSU5WMDA+ IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1 dHRvbiAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAz NTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1l ciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMAphY3Bp X2VjMDogPEVtYmVkZGVkIENvbnRyb2xsZXI6IEdQRSAweDE2PiBwb3J0IDB4NjIs MHg2NiBvbiBhY3BpMAphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQg VGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1l Y291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTAw CmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9saWQw OiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRjaD4gb24gYWNwaTAKYWNwaV9hY2Fk MDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9s IE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kg YnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIwCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5 PiBwb3J0IDB4NTExMC0weDUxMTcgbWVtIDB4ZDAwMDAwMDAtMHhkMDNmZmZmZiww eGMwMDAwMDAwLTB4Y2ZmZmZmZmYgaXJxIDE2IGF0IGRldmljZSAyLjAgb24gcGNp MAphZ3AwOiA8SW50ZWwgR000NSBTVkdBIGNvbnRyb2xsZXI+IG9uIHZnYXBjaTAK YWdwMDogZGV0ZWN0ZWQgMTMxMDY4ayBzdG9sZW4gbWVtb3J5CmFncDA6IGFwZXJ0 dXJlIHNpemUgaXMgMjU2TQp2Z2FwY2kxOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxh eT4gbWVtIDB4ZDM1MDAwMDAtMHhkMzVmZmZmZiBhdCBkZXZpY2UgMi4xIG9uIHBj aTAKdWhjaTA6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBw b3J0IDB4NTBlMC0weDUwZmYgaXJxIDE2IGF0IGRldmljZSAyNi4wIG9uIHBjaTAK dWhjaTA6IFtJVEhSRUFEXQp1aGNpMDogTGVnU3VwID0gMHgzZjAwCnVzYnVzMDog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVo Y2kxOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAw eDUwYzAtMHg1MGRmIGlycSAyMSBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCnVoY2kx OiBbSVRIUkVBRF0KdWhjaTE6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czE6IDxJbnRl bCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQplaGNpMDog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhk NjcwNGMwMC0weGQ2NzA0ZmZmIGlycSAxOSBhdCBkZXZpY2UgMjYuNyBvbiBwY2kw CmVoY2kwOiBbSVRIUkVBRF0KdXNidXMyOiB3YWl0aW5nIGZvciBCSU9TIHRvIGdp dmUgdXAgY29udHJvbAp1c2J1czI6IHRpbWVkIG91dCB3YWl0aW5nIGZvciBCSU9T CnVzYnVzMjogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czI6IDxJbnRlbCA4MjgwMUkg KElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKaGRhYzA6IDxJbnRl bCA4MjgwMUkgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXI+IG1lbSAw eGQ2NzAwMDAwLTB4ZDY3MDNmZmYgaXJxIDIyIGF0IGRldmljZSAyNy4wIG9uIHBj aTAKaGRhYzA6IEhEQSBEcml2ZXIgUmV2aXNpb246IDIwMDkwNjI0XzAxMzYKaGRh YzA6IFtJVEhSRUFEXQpwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAx NyBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIxCnJlMDogPFJlYWxUZWsgODEwMUUvODEwMkUvODEwMkVMIFBDSWUgMTAv MTAwYmFzZVRYPiBwb3J0IDB4MzAwMC0weDMwZmYgbWVtIDB4ZDA0MTAwMDAtMHhk MDQxMGZmZiwweGQwNDAwMDAwLTB4ZDA0MGZmZmYgaXJxIDE2IGF0IGRldmljZSAw LjAgb24gcGNpMgpyZTA6IFVzaW5nIDEgTVNJIG1lc3NhZ2VzCnJlMDogQ2hpcCBy ZXYuIDB4MjQ4MDAwMDAKcmUwOiBNQUMgcmV2LiAweDAwNDAwMDAwCm1paWJ1czA6 IDxNSUkgYnVzPiBvbiByZTAKcmxwaHkwOiA8UlRMODIwMUwgMTAvMTAwIG1lZGlh IGludGVyZmFjZT4gUEhZIDEgb24gbWlpYnVzMApybHBoeTA6ICAxMGJhc2VULCAx MGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvCnJlMDog RXRoZXJuZXQgYWRkcmVzczogMDA6MWU6MzM6Y2I6MjY6OGUKcmUwOiBbRklMVEVS XQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2Ug MjguMSBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCml3bjA6 IDxJbnRlbChSKSBQUk8vV2lyZWxlc3MgNTEwMD4gbWVtIDB4ZDQ2MDAwMDAtMHhk NDYwMWZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kzCml3bjA6IE1JTU8g MVQyUiwgTW9XLCBhZGRyZXNzIDAwOjFlOjY1OjM5OjU5OjM4Cml3bjA6IFtJVEhS RUFEXQppd24wOiAxMWEgcmF0ZXM6IDZNYnBzIDlNYnBzIDEyTWJwcyAxOE1icHMg MjRNYnBzIDM2TWJwcyA0OE1icHMgNTRNYnBzCml3bjA6IDExYiByYXRlczogMU1i cHMgMk1icHMgNS41TWJwcyAxMU1icHMKaXduMDogMTFnIHJhdGVzOiAxTWJwcyAy TWJwcyA1LjVNYnBzIDExTWJwcyA2TWJwcyA5TWJwcyAxMk1icHMgMThNYnBzIDI0 TWJwcyAzNk1icHMgNDhNYnBzIDU0TWJwcwppd24wOiAxMW5hIE1DUzogMTVNYnBz IDMwTWJwcyA0NU1icHMgNjBNYnBzIDkwTWJwcyAxMjBNYnBzIDEzNU1icHMgMTUw TWJwcyAzME1icHMgNjBNYnBzIDkwTWJwcyAxMjBNYnBzIDE4ME1icHMgMjQwTWJw cyAyNzBNYnBzIDMwME1icHMKaXduMDogMTFuZyBNQ1M6IDE1TWJwcyAzME1icHMg NDVNYnBzIDYwTWJwcyA5ME1icHMgMTIwTWJwcyAxMzVNYnBzIDE1ME1icHMgMzBN YnBzIDYwTWJwcyA5ME1icHMgMTIwTWJwcyAxODBNYnBzIDI0ME1icHMgMjcwTWJw cyAzMDBNYnBzCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0 IGRldmljZSAyOC40IG9uIHBjaTAKcGNpNzogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjMKdWhjaTI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBw b3J0IDB4NTBhMC0weDUwYmYgaXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBjaTAK dWhjaTI6IFtJVEhSRUFEXQp1aGNpMjogTGVnU3VwID0gMHgyZjAwCnVzYnVzMzog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kyCnVo Y2kzOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAw eDUwODAtMHg1MDlmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2kz OiBbSVRIUkVBRF0KdWhjaTM6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czQ6IDxJbnRl bCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMwp1aGNpNDog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1MDYw LTB4NTA3ZiBpcnEgMTYgYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpNDogW0lU SFJFQURdCnVoY2k0OiBMZWdTdXAgPSAweDJmMDAKdXNidXM1OiA8SW50ZWwgODI4 MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTQKdWhjaTU6IDxJbnRl bCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4NTA0MC0weDUw NWYgaXJxIDE4IGF0IGRldmljZSAyOS4zIG9uIHBjaTAKdWhjaTU6IFtJVEhSRUFE XQp1aGNpNTogTGVnU3VwID0gMHgyZjAwCnVzYnVzNjogPEludGVsIDgyODAxSSAo SUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k1CmVoY2kxOiA8SW50ZWwgODI4 MDFJIChJQ0g5KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGQ2NzA0ODAwLTB4 ZDY3MDRiZmYgaXJxIDIzIGF0IGRldmljZSAyOS43IG9uIHBjaTAKZWhjaTE6IFtJ VEhSRUFEXQp1c2J1czc6IHdhaXRpbmcgZm9yIEJJT1MgdG8gZ2l2ZSB1cCBjb250 cm9sCnVzYnVzNzogdGltZWQgb3V0IHdhaXRpbmcgZm9yIEJJT1MKdXNidXM3OiBF SENJIHZlcnNpb24gMS4wCnVzYnVzNzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNC IDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMQpwY2liNDogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKQUNQSSBXYXJuaW5nOiBcXF9T Ql8uUENJMC5QMzJfLl9QUlQ6IFJldHVybiBQYWNrYWdlIGhhcyBubyBlbGVtZW50 cyAoZW1wdHkpIDIwMDkwNTIxIG5zcHJlZGVmLTU0NQpwY2k0OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liNAppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2Ug MzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8 SW50ZWwgQUhDSSBjb250cm9sbGVyPiBwb3J0IDB4NTEwOC0weDUxMGYsMHg1MTFj LTB4NTExZiwweDUxMDAtMHg1MTA3LDB4NTExOC0weDUxMWIsMHg1MDIwLTB4NTAz ZiBtZW0gMHhkNjcwNDAwMC0weGQ2NzA0N2ZmIGlycSAxOSBhdCBkZXZpY2UgMzEu MiBvbiBwY2kwCmF0YXBjaTA6IFtJVEhSRUFEXQphdGFwY2kwOiBBSENJIHYxLjIw IGNvbnRyb2xsZXIgd2l0aCA0IDNHYnBzIHBvcnRzLCBQTSBzdXBwb3J0ZWQKYXRh MjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhMjogW0lUSFJFQURdCmF0 YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YTM6IFtJVEhSRUFEXQph dGE0OiA8QVRBIGNoYW5uZWwgND4gb24gYXRhcGNpMAphdGE0OiBbSVRIUkVBRF0K YXRhNTogPEFUQSBjaGFubmVsIDU+IG9uIGF0YXBjaTAKYXRhNTogW0lUSFJFQURd CnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRy aXZlciBhdHRhY2hlZCkKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkw CmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3NyBvbiBh Y3BpMAphdHJ0YzA6IFdhcm5pbmc6IENvdWxkbid0IG1hcCBJL08uCmF0a2JkYzA6 IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGly cSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGti ZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQw OiBbSVRIUkVBRF0KcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMw CnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IFtJVEhSRUFEXQpwc20wOiBtb2Rl bCBTeW5hcHRpY3MgVG91Y2hwYWQsIGRldmljZSBJRCAwCmNwdTA6IDxBQ1BJIENQ VT4gb24gYWNwaTAKY29yZXRlbXAwOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNv cnM+IG9uIGNwdTAKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kg Q29udHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwg Q29udHJvbD4gb24gY3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNvcmV0 ZW1wMTogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUxCmVzdDE6 IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEK cDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEK cG10aW1lcjAgb24gaXNhMApvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVt IDB4ZDAwMDAtMHhkMGZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTAKc2MwOiA8U3lz dGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJ U0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZm ZiBvbiBpc2EwCmF0YTAgYXQgcG9ydCAweDFmMC0weDFmNywweDNmNiBpcnEgMTQg b24gaXNhMAphdGEwOiBbSVRIUkVBRF0KYXRhMSBhdCBwb3J0IDB4MTcwLTB4MTc3 LDB4Mzc2IGlycSAxNSBvbiBpc2EwCmF0YTE6IFtJVEhSRUFEXQpwcGMwOiBwYXJh bGxlbCBwb3J0IG5vdCBmb3VuZC4KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4w MDAgbXNlYwp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVz MTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMyOiA0ODBNYnBzIEhp Z2ggU3BlZWQgVVNCIHYyLjAKdXNidXMzOiAxMk1icHMgRnVsbCBTcGVlZCBVU0Ig djEuMAp1c2J1czQ6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNTog MTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM2OiAxMk1icHMgRnVsbCBT cGVlZCBVU0IgdjEuMAp1c2J1czc6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIu MAphZDY6IDMwNTI0NU1CIDxXREMgV0QzMjAwQkVWVC0yNlpDVDAgMTIuMDFBMTI+ IGF0IGF0YTMtbWFzdGVyIFNBVEEzMDAKdWdlbjAuMTogPEludGVsPiBhdCB1c2J1 czAKdWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQg dXNidXMxCnVodWIxOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2VuMi4xOiA8SW50ZWw+ IGF0IHVzYnVzMgp1aHViMjogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkv MCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPElu dGVsPiBhdCB1c2J1czMKdWh1YjM6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzCnVnZW40LjE6 IDxJbnRlbD4gYXQgdXNidXM0CnVodWI0OiA8SW50ZWwgVUhDSSByb290IEhVQiwg Y2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNAp1Z2Vu NS4xOiA8SW50ZWw+IGF0IHVzYnVzNQp1aHViNTogPEludGVsIFVIQ0kgcm9vdCBI VUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czUK dWdlbjYuMTogPEludGVsPiBhdCB1c2J1czYKdWh1YjY6IDxJbnRlbCBVSENJIHJv b3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXM2CnVnZW43LjE6IDxJbnRlbD4gYXQgdXNidXM3CnVodWI3OiA8SW50ZWwgRUhD SSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYnVzNwp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJl ZAp1aHViNDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK dWh1YjU6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVo dWI2OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAphY2Qw OiBEVkRSIDxNQVRTSElUQURWRC1SQU0gVUo4ODBFUy8xLjgwPiBhdCBhdGE1LW1h c3RlciBTQVRBMTUwCmhkYWMwOiBIREEgQ29kZWMgIzA6IFJlYWx0ZWsgQUxDMjcy CmhkYWMwOiBIREEgQ29kZWMgIzE6IEx1Y2VudC9BZ2VyZSBTeXN0ZW1zIChVbmtu b3duKQpwY20wOiA8SERBIFJlYWx0ZWsgQUxDMjcyIFBDTSAjMCBBbmFsb2c+IGF0 IGNhZCAwIG5pZCAxIG9uIGhkYWMwClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpH RU9NOiBhZDZzMTogZ2VvbWV0cnkgZG9lcyBub3QgbWF0Y2ggbGFiZWwgKDI1NWgs NjNzICE9IDE2aCw2M3MpLgpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcg dXNidXMyCnVodWIyOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcgdXNidXMyCnVnZW4y LjI6IDxTdVlpbj4gYXQgdXNidXMyCnVodWI3OiA4IHBvcnRzIHdpdGggOCByZW1v dmFibGUsIHNlbGYgcG93ZXJlZApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVm czovZGV2L2FkNnMxYQpFbnRyb3B5IGhhcnZlc3Rpbmc6CiBpbnRlcnJ1cHRzCiBl dGhlcm5ldAogcG9pbnRfdG9fcG9pbnQKIGtpY2tzdGFydAouCi9kZXYvYWQ2czFh OiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWQ2czFh OiBjbGVhbiwgMTg2Njk0MSBmcmVlICgxMDUzIGZyYWdzLCAyMzMyMzYgYmxvY2tz LCAwLjElIGZyYWdtZW50YXRpb24pCi9kZXYvYWQ2czFlOiBGSUxFIFNZU1RFTSBD TEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWQ2czFlOiBjbGVhbiwgMjQ5MDkz IGZyZWUgKDI5IGZyYWdzLCAzMTEzMyBibG9ja3MsIDAuMCUgZnJhZ21lbnRhdGlv bikKL2Rldi9hZDZzMWY6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVD S1MKL2Rldi9hZDZzMWY6IGNsZWFuLCA2MTM3MTAwNyBmcmVlICgxNTM3ODMgZnJh Z3MsIDc2NTIxNTMgYmxvY2tzLCAwLjIlIGZyYWdtZW50YXRpb24pCi9kZXYvYWQ2 czFkOiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWQ2 czFkOiBjbGVhbiwgMTU4MTAwOSBmcmVlICg3MDMzIGZyYWdzLCAxOTY3NDcgYmxv Y2tzLCAwLjQlIGZyYWdtZW50YXRpb24pCi9kZXYvYWQ2czJhOiBGSUxFIFNZU1RF TSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvYWQ2czJhOiBjbGVhbiwgNTU5 MDQxMTYgZnJlZSAoMjEyIGZyYWdzLCA2OTg3OTg4IGJsb2NrcywgMC4wJSBmcmFn bWVudGF0aW9uKQp3bGFuMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MWU6NjU6Mzk6 NTk6MzgKU3RhcnRpbmcgd3BhX3N1cHBsaWNhbnQuClN0YXJ0aW5nIE5ldHdvcms6 IGxvMCByZTAuCk5vIEFMVFEgc3VwcG9ydCBpbiBrZXJuZWwKQUxUUSByZWxhdGVk IGZ1bmN0aW9ucyBkaXNhYmxlZApObyBBTFRRIHN1cHBvcnQgaW4ga2VybmVsCkFM VFEgcmVsYXRlZCBmdW5jdGlvbnMgZGlzYWJsZWQKTm8gQUxUUSBzdXBwb3J0IGlu IGtlcm5lbApBTFRRIHJlbGF0ZWQgZnVuY3Rpb25zIGRpc2FibGVkCnBmIGVuYWJs ZWQKQWRkaXRpb25hbCByb3V0aW5nIG9wdGlvbnM6CiBJUCBnYXRld2F5PVlFUwou CkFkZGl0aW9uYWwgQUJJIHN1cHBvcnQ6CiBsaW51eAouCndsYW4wOiBsaW5rIHN0 YXRlIGNoYW5nZWQgdG8gVVAKaXduMDogbmVlZCBtdWx0aWNhc3QgdXBkYXRlIGNh bGxiYWNrCml3bjA6IG5lZWQgbXVsdGljYXN0IHVwZGF0ZSBjYWxsYmFjawppd24w OiBuZWVkIG11bHRpY2FzdCB1cGRhdGUgY2FsbGJhY2sKTm92IDI1IDIwOjQ4OjA1 IHBlZ2FzdXMgcG9zdGdyZXNbOTIwXTogWzEtMV0gRkFUQUw6ICB0aGUgZGF0YWJh c2Ugc3lzdGVtIGlzIHN0YXJ0aW5nIHVwClBlcmZvcm1pbmcgc2FuaXR5IGNoZWNr IG9uIGFwYWNoZTIyIGNvbmZpZ3VyYXRpb246ClN5bnRheCBPSwpDb25maWd1cmlu ZyBzeXNjb25zOgogYWxsc2NyZWVuc19rYmQKIGJsYW5rdGltZQouCi1iZCBpcyBu b3Qgc3VwcG9ydGVkIGJ5IHNTTVRQCnNlbmRtYWlsOiBNYWlsIHF1ZXVlIGlzIGVt cHR5CkNvbmZpZ3VyaW5nIGphaWxzOgouClN0YXJ0aW5nIGphaWxzOgogd3d3Ci4K CldlZCBOb3YgMjUgMjA6NDg6MTAgRVNUIDIwMDkKZHJtMDogPE1vYmlsZSBJbnRl bFxNLUJcTS0uIEdNNDUgRXhwcmVzcyBDaGlwc2V0PiBvbiB2Z2FwY2kwCmluZm86 IFtkcm1dIE1TSSBlbmFibGVkIDEgbWVzc2FnZShzKQp2Z2FwY2kwOiBjaGlsZCBk cm0wIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2J1c21hc3RlcgppbmZvOiBbZHJtXSBB R1AgYXQgMHhjMDAwMDAwMCAyNTZNQgppbmZvOiBbZHJtXSBJbml0aWFsaXplZCBp OTE1IDEuNi4wIDIwMDgwNzMwCmRybTA6IFtJVEhSRUFEXQpOb3YgMjUgMjA6NTA6 MDggcGVnYXN1cyBzdTogZ2JhcmJlciB0byByb290IG9uIC9kZXYvcHRzLzEKaXdu MDogbmVlZCBtdWx0aWNhc3QgdXBkYXRlIGNhbGxiYWNrCgoKRmF0YWwgdHJhcCAx MjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQpjcHVpZCA9IDA7IGFw aWMgaWQgPSAwMApmYXVsdCB2aXJ0dWFsIGFkZHJlc3MJPSAweDdmZmZmZmZmCmZh dWx0IGNvZGUJCT0gc3VwZXJ2aXNvciB3cml0ZSwgcGFnZSBub3QgcHJlc2VudApp bnN0cnVjdGlvbiBwb2ludGVyCT0gMHgyMDoweGMwODU3Y2NkCnN0YWNrIHBvaW50 ZXIJICAgICAgICA9IDB4Mjg6MHhlOWFlYjdkYwpmcmFtZSBwb2ludGVyCSAgICAg ICAgPSAweDI4OjB4ZTlhZWI4MDQKY29kZSBzZWdtZW50CQk9IGJhc2UgMHgwLCBs aW1pdCAweGZmZmZmLCB0eXBlIDB4MWIKCQkJPSBEUEwgMCwgcHJlcyAxLCBkZWYz MiAxLCBncmFuIDEKcHJvY2Vzc29yIGVmbGFncwk9IGludGVycnVwdCBlbmFibGVk LCByZXN1bWUsIElPUEwgPSAwCmN1cnJlbnQgcHJvY2VzcwkJPSAxNTE1IChpbml0 aWFsIHRocmVhZCkKdHJhcCBudW1iZXIJCT0gMTIKcGFuaWM6IHBhZ2UgZmF1bHQK Y3B1aWQgPSAwClVwdGltZTogNDJtN3MKUGh5c2ljYWwgbWVtb3J5OiAyOTIzIE1C CkR1bXBpbmcgMjM2IE1COiAyMjEgMjA1IDE4OSAxNzMgMTU3IDE0MSAxMjUgMTA5 IDkzIDc3IDYxIDQ1IDI5IDEzCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Ka2Vy bmVsIGNvbmZpZwoKY29uZmlnOiBGaWxlIC9ib290L2tlcm5lbC9rZXJuZWwgZG9l c24ndCBjb250YWluIGNvbmZpZ3VyYXRpb24gZmlsZS4gRWl0aGVyIHVuc3VwcG9y dGVkLCBvciBub3QgY29tcGlsZWQgd2l0aCBJTkNMVURFX0NPTkZJR19GSUxFCgot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZGRiIGNhcHR1cmUgYnVmZmVyCgpkZGI6 IGRkYl9jYXB0dXJlOiBrdm1fbmxpc3QK ------------qUGtupsUqelWsTC0XzBUch-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 06:18:11 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08F40106566C for ; Thu, 26 Nov 2009 06:18:11 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id E68C08FC0A for ; Thu, 26 Nov 2009 06:18:10 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NDXg9-000KEx-W2 for stable@freebsd.org; Thu, 26 Nov 2009 06:18:10 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 5F52B2C46585 for ; Thu, 26 Nov 2009 15:18:09 +0900 (JST) Date: Thu, 26 Nov 2009 15:18:09 +0900 Message-ID: From: Randy Bush To: stable User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: 5.5-STABLE to 88.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 06:18:11 -0000 can one go from 5.5 to 8.0 using the normal hammer, or is it multi-stage, and i should just blow it away and go from install? randy From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 07:35:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E14106568F; Thu, 26 Nov 2009 07:35:05 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (server70b.appriver.com [74.205.4.150]) by mx1.freebsd.org (Postfix) with ESMTP id 461D38FC28; Thu, 26 Nov 2009 07:35:04 +0000 (UTC) Received: by server70.appriver.com (CommuniGate Pro PIPE 5.3c2) with PIPE id 108069255; Thu, 26 Nov 2009 02:35:03 -0500 Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 108069252; Thu, 26 Nov 2009 02:34:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA6E6A.61D5C50E" Date: Wed, 25 Nov 2009 23:30:52 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC USB/FS problem Thread-Index: AcptrLXhvnlwlhtHT/OlRRc5JWrzIgAu9bGS References: <200911250937.08267.hselasky@c2i.net> From: "Guojun Jin" To: "Hans Petter Selasky" X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: VCH-CT/SI:0-824/SG:1 11/26/2009 2:34:26 AM X-Virus-Scan: V-X0M0 X-Note: ICH-CT/SI:0-458/SG:1 11/26/2009 2:34:26 AM X-Note: TCH-CT/SI:0-128/SG:8 11/26/2009 2:34:26 AM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.792533 p=-0.913163 Source White X-Signature-Violations: 0-0-0-17447-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: RE: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 07:35:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6E6A.61D5C50E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Most crash had the same back trace. This is also true when USB access = hangs, then unplug the drive. More interesting is the third AMD laptop (dual core) had similar = problem, but it is less crashing but hanging. The core information is available at the same place (bt file is also = attached): http://www.daemonfun.com/archives/public/USB -rw-r--r-- 1 jin wheel 4668 Nov 25 23:17 bt -rw------- 1 4294967294 wheel 80074 Nov 25 22:59 core.txt.0 -rw-r--r-- 1 4294967294 wheel 72108588 Nov 25 23:09 coredump-0.tbz core.txt.0 is from savecore, and bt is I did back trace so it has = slightly more information than core.txt. The tbz file contains the kernel.symbol and all files from savecore. I will continute to dig this and I will set more coredump if new crash = happens at different place. Please let me know anything I can help debug futher before Dec 3rd. I = will on travel for a while and I do not want to hold release for another two weeks. So let's resolve the = problem before I am on travel if possible. -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wed 11/25/2009 12:37 AM To: Guojun Jin Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; = freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem =20 On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote: > What other debug shall we turn on to analyze this problem. Are you able to extract the panic message? Try enabling dump on the swap = partition. --HPS ------_=_NextPart_001_01CA6E6A.61D5C50E Content-Type: application/octet-stream; name="bt" Content-Transfer-Encoding: base64 Content-Description: bt Content-Disposition: attachment; filename="bt" ICBEVU1QOiAxMy4yNiUgZG9uZSwgZmluaXNoZWQgaW4gMDozMiBhdCBXZWQgTm92IDI1IDIyOjI4 OjIzIDIwMDkKICBEVU1QOiBzaG9ydCByZWFkIGVycm9yIGZyb20gL2Rldi9kYTBzMmQ6IFtibG9j ayA1NDU5OTg2MF06IGNvdW50PTEwMjQsIGdvdD0wCiAgRFVNUDogc2hvcnQgcmVhZCBlcnJvciBm cm9tIC9kZXYvZGEwczJkOiBbYmxvY2sgNzg0NjQ3MDRdOiBjb3VudD03MTY4LCBnb3Q9MAogIERV TVA6IDIwLjU1JSBkb25lLCBmaW5pc2hlZCBpbiAwOjM4IGF0IFdlZCBOb3YgMjUgMjI6Mzk6MjIg MjAwOQogIERVTVA6IDI1Ljk1JSBkb25lLCBmaW5pc2hlZCBpbiAwOjQzIGF0IFdlZCBOb3YgMjUg MjI6NDg6NDYgMjAwOQogIERVTVA6IDI2LjAwJSBkb25lLCBmaW5pc2hlZCBpbiAwOjU3IGF0IFdl ZCBOb3YgMjUgMjM6MDg6MDcgMjAwOQogIERVTVA6IHNob3J0IHJlYWQgZXJyb3IgZnJvbSAvZGV2 L2RhMHMyZDogW2Jsb2NrIDI2MzA3NzUzNl06IGNvdW50PTMwNzIsIGdvdD0wCiAgRFVNUDogMjYu MDMlIGRvbmUsIGZpbmlzaGVkIGluIDE6MTEgYXQgV2VkIE5vdiAyNSAyMzoyNzoxOSAyMDA5CiAg RFVNUDogMjYuMDYlIGRvbmUsIGZpbmlzaGVkIGluIDE6MjUgYXQgV2VkIE5vdiAyNSAyMzo0Njoz NCAyMDA5CiAgRFVNUDogMjYuMTAlIGRvbmUsIGZpbmlzaGVkIGluIDE6MzkgYXQgVGh1IE5vdiAy NiAwMDowNTo0NiAyMDA5CgoxNSAvdmFyL2NyYXNoOiB2aSBjb3JlLnR4dC4wIAoxNiAvdmFyL2Ny YXNoOiBrZ2RiIC9ib290L2tlcm5lbC9rZXJuZWwuc3ltYm9scyB2bWNvcmUuMCAKR05VIGdkYiA2 LjEuMSBbRnJlZUJTRF0KQ29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJ bmMuCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJs aWMgTGljZW5zZSwgYW5kIHlvdSBhcmUKd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5kL29yIGRpc3Ry aWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4KVHlwZSAic2hvdyBj b3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuClRoZXJlIGlzIGFic29sdXRlbHkgbm8gd2Fy cmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxzLgpUaGlzIEdE QiB3YXMgY29uZmlndXJlZCBhcyAiaTM4Ni1tYXJjZWwtZnJlZWJzZCIuLi4KClVucmVhZCBwb3J0 aW9uIG9mIHRoZSBrZXJuZWwgbWVzc2FnZSBidWZmZXI6CnVnZW4yLjI6IDxETUk+IGF0IHVzYnVz MiAoZGlzY29ubmVjdGVkKQp1bWFzczA6IGF0IHVodWIyLCBwb3J0IDQsIGFkZHIgMiAoZGlzY29u bmVjdGVkKQooZGEwOnVtYXNzLXNpbTA6MDowOjApOiBsb3N0IGRldmljZQooZGEwOnVtYXNzLXNp bTA6MDowOjApOiBJbnZhbGlkYXRpbmcgcGFjawpnX3Zmc19kb25lKCk6ZGEwczNkW1dSSVRFKG9m ZnNldD0yMzIyOTcyNjcyLCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYKL21udDogZ290IGVycm9y IDYgd2hpbGUgYWNjZXNzaW5nIGZpbGVzeXN0ZW0KcGFuaWM6IHNvZnRkZXBfZGVhbGxvY2F0ZV9k ZXBlbmRlbmNpZXM6IHVucmVjb3ZlcmVkIEkvTyBlcnJvcgpjcHVpZCA9IDAKVXB0aW1lOiAxNW01 N3MKKGRhMDp1bWFzcy1zaW0wOjA6MDowKTogU3luY2hyb25pemUgY2FjaGUgZmFpbGVkLCBzdGF0 dXMgPT0gMHhhLCBzY3NpIHN0YXR1cyA9PSAweDAKUGh5c2ljYWwgbWVtb3J5OiAzNzAgTUIKRHVt cGluZyAxMzMgTUI6IDExOCAxMDIgODYgNzAgNTQgMzggMjIgNgoKUmVhZGluZyBzeW1ib2xzIGZy b20gL2Jvb3Qva2VybmVsL2lmX3JsLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2Vy bmVsL2lmX3JsLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jv b3Qva2VybmVsL2lmX3JsLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9zbmRf YXRpaXhwLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL3NuZF9hdGlpeHAu a28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwv c25kX2F0aWl4cC5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvc291bmQua28u Li5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvc291bmQua28uc3ltYm9scy4uLmRv bmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvc291bmQua28KUmVhZGlu ZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL3JhZGVvbi5rby4uLlJlYWRpbmcgc3ltYm9scyBm cm9tIC9ib290L2tlcm5lbC9yYWRlb24ua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBz eW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvcmFkZW9uLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9i b290L2tlcm5lbC9kcm0ua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvZHJt LmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVs L2RybS5rbwojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MjQ2CjI0NiAgICAgcGNwdS5oOiBObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5LgogICAgICAgIGluIHBjcHUuaAooa2dkYikgdXAKIzEgIDB4 YzA3Njg4NTcgaW4gYm9vdCAoaG93dG89MjYwKSBhdCAuLi8uLi8uLi9rZXJuL2tlcm5fc2h1dGRv d24uYzo0MTYKNDE2ICAgICAgICAgICAgICAgICAgICAgZG9hZHVtcCgpOwooa2dkYikgdXAKIzIg IDB4YzA3NjhiNDkgaW4gcGFuaWMgKGZtdD1WYXJpYWJsZSAiZm10IiBpcyBub3QgYXZhaWxhYmxl LgopIGF0IC4uLy4uLy4uL2tlcm4va2Vybl9zaHV0ZG93bi5jOjU3OQo1NzkgICAgICAgICAgICAg Ym9vdChib290b3B0KTsKKGtnZGIpIHVwCiMzICAweGMwOTkwMDVkIGluIHNvZnRkZXBfZGVhbGxv Y2F0ZV9kZXBlbmRlbmNpZXMgKGJwPVZhcmlhYmxlICJicCIgaXMgbm90IGF2YWlsYWJsZS4KKQog ICAgYXQgLi4vLi4vLi4vdWZzL2Zmcy9mZnNfc29mdGRlcC5jOjYzNjcKNjM2NyAgICAgICAgICAg IHBhbmljKCJzb2Z0ZGVwX2RlYWxsb2NhdGVfZGVwZW5kZW5jaWVzOiB1bnJlY292ZXJlZCBJL08g ZXJyb3IiKTsKKGtnZGIpIGwKNjM2MiAgICB7CjYzNjMKNjM2NCAgICAgICAgICAgIGlmICgoYnAt PmJfaW9mbGFncyAmIEJJT19FUlJPUikgPT0gMCkKNjM2NSAgICAgICAgICAgICAgICAgICAgcGFu aWMoInNvZnRkZXBfZGVhbGxvY2F0ZV9kZXBlbmRlbmNpZXM6IGRhbmdsaW5nIGRlcHMiKTsKNjM2 NiAgICAgICAgICAgIHNvZnRkZXBfZXJyb3IoYnAtPmJfdnAtPnZfbW91bnQtPm1udF9zdGF0LmZf bW50b25uYW1lLCBicC0+Yl9lcnJvcik7CjYzNjcgICAgICAgICAgICBwYW5pYygic29mdGRlcF9k ZWFsbG9jYXRlX2RlcGVuZGVuY2llczogdW5yZWNvdmVyZWQgSS9PIGVycm9yIik7CjYzNjggICAg fQo2MzY5CjYzNzAgICAgLyoKNjM3MSAgICAgKiBGdW5jdGlvbiB0byBoYW5kbGUgYXN5bmNocm9u b3VzIHdyaXRlIGVycm9ycyBpbiB0aGUgZmlsZXN5c3RlbS4KKGtnZGIpIHAveCBicC0+Yl9pb2Zs YWdzClZhcmlhYmxlICJicCIgaXMgbm90IGF2YWlsYWJsZS4KKGtnZGIpIGwgNjM2MAo2MzU1ICAg ICAqIENhbGxlZCB3aGVuZXZlciBhIGJ1ZmZlciB0aGF0IGlzIGJlaW5nIGludmFsaWRhdGVkIG9y IHJlYWxsb2NhdGVkCjYzNTYgICAgICogY29udGFpbnMgZGVwZW5kZW5jaWVzLiBUaGlzIHNob3Vs ZCBvbmx5IGhhcHBlbiBpZiBhbiBJL08gZXJyb3IgaGFzCjYzNTcgICAgICogb2NjdXJyZWQuIFRo ZSByb3V0aW5lIGlzIGNhbGxlZCB3aXRoIHRoZSBidWZmZXIgbG9ja2VkLgo2MzU4ICAgICAqLyAK NjM1OSAgICBzdGF0aWMgdm9pZAo2MzYwICAgIHNvZnRkZXBfZGVhbGxvY2F0ZV9kZXBlbmRlbmNp ZXMoYnApCjYzNjEgICAgICAgICAgICBzdHJ1Y3QgYnVmICpicDsKNjM2MiAgICB7CjYzNjMKNjM2 NCAgICAgICAgICAgIGlmICgoYnAtPmJfaW9mbGFncyAmIEJJT19FUlJPUikgPT0gMCkKKGtnZGIp IHVwCiM0ICAweGMwN2Q4ZDUwIGluIGJyZWxzZSAoYnA9MHhjYTFmOTZjMCkgYXQgYnVmLmg6NDE4 CjQxOCAgICAgYnVmLmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuCiAgICAgICAgaW4gYnVm LmgKKGtnZGIpIHVwCiM1ICAweGMwN2RiNmM2IGluIGJ1ZmRvbmVfZmluaXNoIChicD0weGNhMWY5 NmMwKQogICAgYXQgLi4vLi4vLi4va2Vybi92ZnNfYmlvLmM6MzQwMQozNDAxICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGJyZWxzZShicCk7CihrZ2RiKSBwIGJwCiQxID0gKHN0cnVjdCBidWYg KikgMHhjYTFmOTZjMAooa2dkYikgcC94IGJwLT5iX2lvZmxhZ3MKJDIgPSAweDEKKGtnZGIpIHVw CiM2ICAweGMwN2RiNzNkIGluIGJ1ZmRvbmUgKGJwPTB4Y2ExZjk2YzApIGF0IC4uLy4uLy4uL2tl cm4vdmZzX2Jpby5jOjMyNjEKMzI2MSAgICAgICAgICAgIGJ1ZmRvbmVfZmluaXNoKGJwKTsKKGtn ZGIpCg== ------_=_NextPart_001_01CA6E6A.61D5C50E-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 08:22:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B7F8106568B for ; Thu, 26 Nov 2009 08:22:18 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from golanth.tzim.net (unknown [IPv6:2001:41d0:1:d91f:21c:c0ff:fe4b:cf32]) by mx1.freebsd.org (Postfix) with ESMTP id D07878FC1B for ; Thu, 26 Nov 2009 08:22:17 +0000 (UTC) Received: from 12rf.tzim.net ([82.232.60.244] helo=[192.168.0.198]) by golanth.tzim.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NDZcG-00024X-Sv for freebsd-stable@freebsd.org; Thu, 26 Nov 2009 09:22:16 +0100 Message-ID: <4B0E3ABA.3030606@tzim.net> Date: Thu, 26 Nov 2009 09:22:18 +0100 From: Arnaud Houdelette User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: tzim@tzim.net X-Authenticator: plain Subject: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:22:18 -0000 I just upgraded from 7.2 to 8.0. Under 7.2 the pool was like : NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6p1 ONLINE 0 0 0 ad10p1 ONLINE 0 0 0 ad8p1 ONLINE 0 0 0 ad4p1 ONLINE 0 0 0 I'd like to use gpt labels or gptids reimporting the pool. # ls /dev/gpt disk1 disk2 disk3 disk4 # ls /dev/gptid 0902db4e-d462-11de-96bd-001d923bc7a0 9fb111f8-d426-11de-99bc-001d923bc7a0 1be29091-d9dc-11de-9f4a-001d923bc7a0 ffb4e96a-d497-11de-96bd-001d923bc7a0 I did # zpool import -d /dev/gpt tank and I got tank ONLINE raidz1 ONLINE ada1p1 ONLINE ada3p1 ONLINE ada2p1 ONLINE gpt/disk4 ONLINE Now, how to force zpool import to only use gpt labels (or uuids) ? Or at least get back to coherent situation ( zpool export tank / zpool import gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid gives nothing ) ? Thanks in advance. Arnaud From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 08:40:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFC26106568D for ; Thu, 26 Nov 2009 08:40:17 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id B8F368FC1C for ; Thu, 26 Nov 2009 08:40:17 +0000 (UTC) Received: by iwn36 with SMTP id 36so323239iwn.3 for ; Thu, 26 Nov 2009 00:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hd/FDKfAl6mpNLhy9EQmDlxcF4DUpZ6U2rZr8QIzjdU=; b=B9yqgToZ9KewEn1J713IRURb928n+tddb9r609g29rXP6qEHmxXj+euR/2ITWj2PGf ZFHDgNTEBhqdwJoLHAebtVG7NFKPkYvFqhKW9O83RcKiLF3muC7bfUQ8BfUkA/iU8WKZ j8HQDU7CkU3RyfJrwb0WIyviGPk8kZKgaxFtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XR5eClL7ahOUnlegsMJ97nYYkrNK+FeMgdCzQQ+vGpnnmc/fWBF+cUkn0J8XWGHFSQ pORFMNuc7ISN3vN6+VRyoog5c1iLH7ZFN1tJYCdaUKgI3b7XBbYug/Cd3nQd1sWOdN9w ThRXJjbGngIcg0JJf1Fscw8vBosBCuzJZXr5c= MIME-Version: 1.0 Received: by 10.231.29.149 with SMTP id q21mr2344438ibc.35.1259224817198; Thu, 26 Nov 2009 00:40:17 -0800 (PST) In-Reply-To: <4B0E3ABA.3030606@tzim.net> References: <4B0E3ABA.3030606@tzim.net> Date: Thu, 26 Nov 2009 02:40:17 -0600 Message-ID: <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> From: Scot Hetzel To: Arnaud Houdelette Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:40:18 -0000 On 11/26/09, Arnaud Houdelette wrote: > I just upgraded from 7.2 to 8.0. > Under 7.2 the pool was like : > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad6p1 ONLINE 0 0 0 > ad10p1 ONLINE 0 0 0 > ad8p1 ONLINE 0 0 0 > ad4p1 ONLINE 0 0 0 > > I'd like to use gpt labels or gptids reimporting the pool. > # ls /dev/gpt > disk1 disk2 disk3 disk4 > # ls /dev/gptid > 0902db4e-d462-11de-96bd-001d923bc7a0 > 9fb111f8-d426-11de-99bc-001d923bc7a0 > 1be29091-d9dc-11de-9f4a-001d923bc7a0 > ffb4e96a-d497-11de-96bd-001d923bc7a0 > > I did # zpool import -d /dev/gpt tank > and I got > tank ONLINE > raidz1 ONLINE > ada1p1 ONLINE > ada3p1 ONLINE > ada2p1 ONLINE > gpt/disk4 ONLINE > > Now, how to force zpool import to only use gpt labels (or uuids) ? Or at > least get back to coherent situation ( zpool export tank / zpool import > gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid > gives nothing ) ? > Use 'zpool replace' to change the zfs pool to use the gpt names: zpool replace tank ada1p1 gpt/disk1 zpool replace tank ada2p1 gpt/disk2 zpool replace tank ada3p1 gpt/disk3 NOTE: make sure you use the correct gpt names for each partition, as the above assumes that ada1p1 is labeled as disk1. Scot From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 08:50:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A0C81065695 for ; Thu, 26 Nov 2009 08:50:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id D80EE8FC0A for ; Thu, 26 Nov 2009 08:50:36 +0000 (UTC) Received: from OMTA18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA12.westchester.pa.mail.comcast.net with comcast id 9knt1d0051wpRvQ5Ckqdg9; Thu, 26 Nov 2009 08:50:37 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA18.westchester.pa.mail.comcast.net with comcast id 9kxD1d0043S48mS3ekxEkw; Thu, 26 Nov 2009 08:57:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EFF1D1E3035; Thu, 26 Nov 2009 00:50:34 -0800 (PST) Date: Thu, 26 Nov 2009 00:50:34 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091126085034.GA51998@icarus.home.lan> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:50:37 -0000 On Thu, Nov 26, 2009 at 02:40:17AM -0600, Scot Hetzel wrote: > On 11/26/09, Arnaud Houdelette wrote: > > I just upgraded from 7.2 to 8.0. > > Under 7.2 the pool was like : > > NAME STATE READ WRITE CKSUM > > tank ONLINE 0 0 0 > > raidz1 ONLINE 0 0 0 > > ad6p1 ONLINE 0 0 0 > > ad10p1 ONLINE 0 0 0 > > ad8p1 ONLINE 0 0 0 > > ad4p1 ONLINE 0 0 0 > > > > I'd like to use gpt labels or gptids reimporting the pool. > > # ls /dev/gpt > > disk1 disk2 disk3 disk4 > > # ls /dev/gptid > > 0902db4e-d462-11de-96bd-001d923bc7a0 > > 9fb111f8-d426-11de-99bc-001d923bc7a0 > > 1be29091-d9dc-11de-9f4a-001d923bc7a0 > > ffb4e96a-d497-11de-96bd-001d923bc7a0 > > > > I did # zpool import -d /dev/gpt tank > > and I got > > tank ONLINE > > raidz1 ONLINE > > ada1p1 ONLINE > > ada3p1 ONLINE > > ada2p1 ONLINE > > gpt/disk4 ONLINE > > > > Now, how to force zpool import to only use gpt labels (or uuids) ? Or at > > least get back to coherent situation ( zpool export tank / zpool import > > gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid > > gives nothing ) ? > > > > Use 'zpool replace' to change the zfs pool to use the gpt names: > > zpool replace tank ada1p1 gpt/disk1 > zpool replace tank ada2p1 gpt/disk2 > zpool replace tank ada3p1 gpt/disk3 > > NOTE: make sure you use the correct gpt names for each partition, as > the above assumes that ada1p1 is labeled as disk1. I'm a bit curious about something, so maybe someone can help me understand: Why are people bothering with GPT labels (or in some cases, glabels) when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what circumstance would the device name change dynamically in this situation? I've never witnessed this happening with AHCI, at least on Intel systems, and I've hot-swapped hard disks many times over. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 09:09:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36932106566B for ; Thu, 26 Nov 2009 09:09:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id B7D918FC1C for ; Thu, 26 Nov 2009 09:09:22 +0000 (UTC) Received: by bwz5 with SMTP id 5so379084bwz.3 for ; Thu, 26 Nov 2009 01:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=p8VUOziElJ2xaY2bo8V2WcYiv6nCQLJwf57LGlh9qWo=; b=WkmzwB+yE0fS7hXiz97aJ2ka3LqMxSOh7TyrWqhxdMGVUmN6J8HGLOGVrZJfsoPv7r +liYpZMf3PYO2uu1Eogt4rki43mbwfo6Q+3R+fFnR8Miz4iX3azdjzdcWYmaRXCYSB+j u31HkiOj/4XWWB+/1l9DeiZEGnd2VOGSY+f8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZaJAqtVxoIzqMP62s2o+thjKD1LtFKoY9Y3TSPydQTCsawJP3bFAWTqbLHGoEb7B2Z SMtPWnuHEwN8ruAGtzh1pg+OrwW2LarucWJzynw55tioV64lyIB9gU9LElK4tuFo0EXN YdGOWYM6GAcyGQuuYL2dpYIYGZpCTfphV/P9g= Received: by 10.204.10.6 with SMTP id n6mr8431801bkn.27.1259226561349; Thu, 26 Nov 2009 01:09:21 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm145897fxm.10.2009.11.26.01.09.19 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 01:09:20 -0800 (PST) Sender: Alexander Motin Message-ID: <4B0E45B1.90907@FreeBSD.org> Date: Thu, 26 Nov 2009 11:09:05 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Denis Shaposhnikov References: <1259162588.00187044.1259151005@10.7.7.3> In-Reply-To: <1259162588.00187044.1259151005@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: how to disable APM using camcontrol cmd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 09:09:23 -0000 Denis Shaposhnikov wrote: > I'm trying to replace sysutils/ataidle which doesn't work with new > acpi(4). May be somebody could tell me args for > > camcontrol cmd ada0 -a cmd XX XX XX XX XX XX XX XX > > to disable APM and acoustic management (AAM) for my HDD? To set APM level: camcontrol cmd ada0 -a "EF 05 00 00 00 00 00 00 00 00 xx 00" To disable it: camcontrol cmd ada0 -a "EF 85 00 00 00 00 00 00 00 00 00 00 To set AAM level: camcontrol cmd ada0 -a "EF 42 00 00 00 00 00 00 00 00 xx 00" To disable it: camcontrol cmd ada0 -a "EF C2 00 00 00 00 00 00 00 00 00 00 You can check result with: camcontrol identify ada0 -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 09:18:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA313106566C for ; Thu, 26 Nov 2009 09:18:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.tele2.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6921B8FC0A for ; Thu, 26 Nov 2009 09:18:58 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=AZ1ajIJw4K75eKegOlwA:9 a=Xa-G-XI08IdcHqc1iairc3C-kDUA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1169561369; Thu, 26 Nov 2009 09:18:52 +0100 From: Hans Petter Selasky To: "Guojun Jin" Date: Thu, 26 Nov 2009 09:20:31 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200911250937.08267.hselasky@c2i.net> In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911260920.32342.hselasky@c2i.net> Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 09:18:58 -0000 On Thursday 26 November 2009 08:30:52 Guojun Jin wrote: > Most crash had the same back trace. This is also true when USB access > hangs, then unplug the drive. I think from the backtrace that this is not an USB issue. It is a file-system issue. --HPS From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 09:45:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31A011065670 for ; Thu, 26 Nov 2009 09:45:39 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id B2F958FC12 for ; Thu, 26 Nov 2009 09:45:38 +0000 (UTC) Received: by ewy26 with SMTP id 26so594898ewy.3 for ; Thu, 26 Nov 2009 01:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=FnTqvj3i+VlsgTlKpd3C3gJZz45CZxoBZewhwKNATPY=; b=QPxJuPlhC4MSyphLwZYSDpPKwUMlSNlxjU4Hdx2tcM+NxeYbKGkMkm90VQoW7elgwf qk+VxHJ/bfN3iMF3ykY4YoRF+UHFAMWKXkwYL5nbjlF9+w+R4UjVzuCGkvkDgPK+/YYs f2uGnvkJ7OuKBIa+frx9YTN7PuNW8KwGeBNYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ELii0CcgjsixywM7dlWNijkQLwMkNWzWIAz75p3MhdxEHi0fXtNrZjxgfkcBkPJ25o E6pxnNO1irf57GwjvUgPuaH/fYdf+20rqn3NdlaBXt0EHmC/9W8/2g6DUcu9+ZZ82wNl pl2A+kYP4vVjTu89YD+9kB1MVAvkVHlkXE1lY= MIME-Version: 1.0 Received: by 10.213.110.17 with SMTP id l17mr9105776ebp.91.1259228737777; Thu, 26 Nov 2009 01:45:37 -0800 (PST) In-Reply-To: <20091126085034.GA51998@icarus.home.lan> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> Date: Thu, 26 Nov 2009 09:45:37 +0000 Message-ID: <2e027be00911260145q4192728cuaea1d5e6da01a1e@mail.gmail.com> From: Tom Evans To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 09:45:39 -0000 On Thu, Nov 26, 2009 at 8:50 AM, Jeremy Chadwick wrote: > I'm a bit curious about something, so maybe someone can help me > understand: > > Why are people bothering with GPT labels (or in some cases, glabels) > when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what > circumstance would the device name change dynamically in this situation? > > I've never witnessed this happening with AHCI, at least on Intel > systems, and I've hot-swapped hard disks many times over. > > My home server has 6 x ICH10 SATA ports using ahci(4), and 2 x SiL 3128 SATA ports using siis(4). When I first set it up, I created a raidz pool using MBR/BSD slices/partitions on the drives on the ahci controllers, (ie zpool create tank raidz ada[0-5]s1d). I then shutdown, connected a couple of drives to the siis controller, and booted up again. This caused the pool to fail to be imported, as the drives on siis came up as ada0 and ada1. I then wiped out the pool, and restarted the install, but this time using GPT partitioning and labelling each partition that I use. Now I can connect my drives on any interface, any order and it works correctly, always. I also get a nice label for each drive that I can scribble on the drive cage, and I can tell exactly what physical device is referred to by a label. The only cost to this was having to remember to label the drives - well worth it imo. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 10:11:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DE12106566B for ; Thu, 26 Nov 2009 10:11:29 +0000 (UTC) (envelope-from dsh@wizard.volgograd.ru) Received: from dsh.falconknight.com (dsh.falconknight.com [66.160.163.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2F59F8FC1C for ; Thu, 26 Nov 2009 10:11:28 +0000 (UTC) Received: from localhost (dsh [66.160.163.23]) by dsh.falconknight.com (Postfix) with ESMTP id 594B1B63528; Thu, 26 Nov 2009 01:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= wizard.volgograd.ru; h=content-transfer-encoding:content-type :mime-version:x-mailer:references:in-reply-to:message-id:subject :from:date:received:received:x-virus-scanned; s=foo; t= 1259229150; x=1261043550; bh=SUH5sC/8EknYdUX7kh4tRYeR7j205EiZYAS ce9s5GwQ=; b=fz5L2ud7AnZBfwDZny0vKmQbfwWqtnZqffpiXBIsI5G2Mkm0dU+ y9WehgtEhhrdSN50y5fJdn08t1clGrRxRWxKABQTZ0WGDhHj5mMEyFtbnkGWDPnF vTk5sGsufx0wsI5s3LO7Er23yWMhM5E7PJ6dVk9raSa4634lF5NkwSiU= X-Virus-Scanned: amavisd-new at wizard.volgograd.ru Received: from dsh.falconknight.com ([66.160.163.23]) by localhost (dsh.falconknight.com [66.160.163.23]) (amavisd-new, port 10026) with LMTP id C5SlnR2Cc737; Thu, 26 Nov 2009 01:52:30 -0800 (PST) Received: from localhost (unknown [85.173.92.192]) by dsh.falconknight.com (Postfix) with ESMTPSA id 0414AB6350B; Thu, 26 Nov 2009 01:52:28 -0800 (PST) Date: Thu, 26 Nov 2009 12:52:25 +0300 From: Denis Shaposhnikov To: Alexander Motin Message-ID: <20091126125225.500f9dd7@wizard.volgograd.ru> In-Reply-To: <4B0E45B1.90907@FreeBSD.org> References: <1259162588.00187044.1259151005@10.7.7.3> <4B0E45B1.90907@FreeBSD.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: how to disable APM using camcontrol cmd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 10:11:29 -0000 Hello, On Thu, 26 Nov 2009 11:09:05 +0200 Alexander Motin wrote: > To set APM level: > camcontrol cmd ada0 -a "EF 05 00 00 00 00 00 00 00 00 xx 00" > To disable it: > camcontrol cmd ada0 -a "EF 85 00 00 00 00 00 00 00 00 00 00 Yes, it works! Thank you very much! From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 10:29:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A791A1065778 for ; Thu, 26 Nov 2009 10:29:18 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 6F85F8FC12 for ; Thu, 26 Nov 2009 10:29:18 +0000 (UTC) Received: by iwn36 with SMTP id 36so359159iwn.3 for ; Thu, 26 Nov 2009 02:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MT0val/IshjR+hhTv1ONkj6Oe+NNH1l17TgvKcliQ54=; b=Exo6n78dxj7ry9Dm7aMfM2JKwsLpLHt/4+2YMdTbjI6TV5d+cb0zvv0ZA0haqKwMwE zVuZhMMFC9EmT1mGFeZ34pJLV5msRARgmrgtY7NP8ndQaz9eLlV/0XZtpCugmgDG+71/ O9j9xjRboiryfLrPuuZAknAcIXfEkZLjJ2bvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=E/hiLE6kRK33Q0lTVW6vtZVHYKmmjrAIrJlQNAXZ7I8DqzavfyYItg+AnNlokrGCAa mEGlJWG8VFY7MZUD9dG+uLv8Lm8HUlvo6ot0B414oa04ss4LDVpf9Mar2eHPBzsOevy8 0tuiDwh1T71ruVLd7AarQU7Zn87ABDTi/QsTE= MIME-Version: 1.0 Received: by 10.231.120.136 with SMTP id d8mr2090610ibr.14.1259231357818; Thu, 26 Nov 2009 02:29:17 -0800 (PST) In-Reply-To: <20091126085034.GA51998@icarus.home.lan> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> Date: Thu, 26 Nov 2009 04:29:17 -0600 Message-ID: <790a9fff0911260229u40d9f499w28a7ce46e1f92467@mail.gmail.com> From: Scot Hetzel To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 10:29:18 -0000 On 11/26/09, Jeremy Chadwick wrote: > I'm a bit curious about something, so maybe someone can help me > understand: > > Why are people bothering with GPT labels (or in some cases, glabels) > when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what > circumstance would the device name change dynamically in this situation? > There was a thread about this problem where the drives had changed their device names due to a change in the kernel drive (Current list from July): http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009377.html Through out this thread there were various suggests on how he could recover the system, and prevent the problem from occurring in the future. One of the suggestions was that use of zpool replace to change from device names to using glabel labels. http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html > I've never witnessed this happening with AHCI, at least on Intel > systems, and I've hot-swapped hard disks many times over. > Using glabels, gpt labels, or gptid solves the problem of not needing to remember which device name the drive originally had. For instance, on a zfs zraid pool with 3 disks (ad1 ad2 ad3) you could disconnect the pool from one computer and connect it to another system and it wouldn't matter which order you reconnected the drives (1 2 3 or 3 1 2) as the pool would still be recognized when it is imported on the new system. Also if the new system already has drives ad1 and ad2, it wouldn't matter. Scot From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 11:09:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7BD91065676 for ; Thu, 26 Nov 2009 11:09:26 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from golanth.tzim.net (unknown [IPv6:2001:41d0:1:d91f:21c:c0ff:fe4b:cf32]) by mx1.freebsd.org (Postfix) with ESMTP id 64F378FC1E for ; Thu, 26 Nov 2009 11:09:26 +0000 (UTC) Received: from 12rf.tzim.net ([82.232.60.244] helo=[192.168.0.10]) by golanth.tzim.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NDcE1-00039H-Go; Thu, 26 Nov 2009 12:09:25 +0100 Message-ID: <4B0E61E2.7070509@tzim.net> Date: Thu, 26 Nov 2009 12:09:22 +0100 From: Arnaud Houdelette User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Scot Hetzel References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <4B0E43B1.6050802@tzim.net> <790a9fff0911260200kf07d6d2nf7cf9eb9d2c07bcf@mail.gmail.com> In-Reply-To: <790a9fff0911260200kf07d6d2nf7cf9eb9d2c07bcf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: tzim@tzim.net X-Authenticator: plain Cc: freebsd-stable@freebsd.org Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 11:09:27 -0000 Scot Hetzel wrote: > On 11/26/09, Arnaud Houdelette wrote: > >> Scot Hetzel wrote: >> >> >>> On 11/26/09, Arnaud Houdelette wrote: >>> >>> >>> >>>> I just upgraded from 7.2 to 8.0. >>>> Under 7.2 the pool was like : >>>> NAME STATE READ WRITE CKSUM >>>> tank ONLINE 0 0 0 >>>> raidz1 ONLINE 0 0 0 >>>> ad6p1 ONLINE 0 0 0 >>>> ad10p1 ONLINE 0 0 0 >>>> ad8p1 ONLINE 0 0 0 >>>> ad4p1 ONLINE 0 0 0 >>>> >>>> I'd like to use gpt labels or gptids reimporting the pool. >>>> # ls /dev/gpt >>>> disk1 disk2 disk3 disk4 >>>> # ls /dev/gptid >>>> 0902db4e-d462-11de-96bd-001d923bc7a0 >>>> 9fb111f8-d426-11de-99bc-001d923bc7a0 >>>> 1be29091-d9dc-11de-9f4a-001d923bc7a0 >>>> ffb4e96a-d497-11de-96bd-001d923bc7a0 >>>> >>>> I did # zpool import -d /dev/gpt tank >>>> and I got >>>> tank ONLINE >>>> raidz1 ONLINE >>>> ada1p1 ONLINE >>>> ada3p1 ONLINE >>>> ada2p1 ONLINE >>>> gpt/disk4 ONLINE >>>> >>>> Now, how to force zpool import to only use gpt labels (or uuids) ? Or >>>> >> at >> >>>> least get back to coherent situation ( zpool export tank / zpool import >>>> gives the same now. and zpool import -d /dev, as zpool import -d >>>> >> /dev/gptid >> >>>> gives nothing ) ? >>>> >>>> >>>> >>>> >>> Use 'zpool replace' to change the zfs pool to use the gpt names: >>> >>> zpool replace tank ada1p1 gpt/disk1 >>> zpool replace tank ada2p1 gpt/disk2 >>> zpool replace tank ada3p1 gpt/disk3 >>> >>> NOTE: make sure you use the correct gpt names for each partition, as >>> the above assumes that ada1p1 is labeled as disk1. >>> >>> Scot >>> >>> >>> >> Mmmh, zpool replace will resilver the drive, won't it ? >> > > Yes, it will resilver the drive, but it shouldn't take as long as it > will recognize that it is the same drive. Just wait for the resilver > process to finish before changing the next drive. > > >> Moreover, I can't use replace as when adaXp1 is used, the corresponding >> /dev/gpt entry disapears. Unless you mean that I can use replace before >> import ? >> >> > > There was a discussion about this back in July: > > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html > > In that discussion, they had used glabel to label each drive, and then > use zpool replace on the active pool to change it to use the label. > > Just make sure that you use the gpt name that you assigned to ada1p1, > when replacing it. > > Scot > That does not work or there's something I'm doing wrong. # uname -a FreeBSD carenath.tzim.net 8.0-RELEASE FreeBSD 8.0-RELEASE #26: Wed Nov 25 23:43:22 CET 2009 tzim@carenath.tzim.net:/usr/obj/usr/src/sys/CARENATH amd64 As I said, the label is not present in /dev/gpt while used with adaXp1 ( here ada1p1 has label HD753LJ-1) : # ls /dev/gpt HD753LJ-4 zfs-boot # zpool replace tank ada1p1 gpt/HD753LJ-1 cannot open 'gpt/HD753LJ-1': no such GEOM provider If I offline the drive first, I get another error : # zpool offline tank ada1p1 # zpool replace tank ada1p1 gpt/HD753LJ-1 invalid vdev specification use '-f' to override the following errors: /dev/gpt/HD753LJ-1 is part of active pool 'tank' # zpool replace -f tank ada1p1 gpt/HD753LJ-1 invalid vdev specification the following errors must be manually repaired: /dev/gpt/HD753LJ-1 is part of active pool 'tank' I know there is the solution of cleaning the disk and resilvering, but if I could avoid this ? Arnaud From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 11:10:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39234106568B for ; Thu, 26 Nov 2009 11:10:11 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA9E8FC17 for ; Thu, 26 Nov 2009 11:10:10 +0000 (UTC) Received: by pzk15 with SMTP id 15so467015pzk.3 for ; Thu, 26 Nov 2009 03:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vPTtc3maL3iOZhqm7oMV+84Wwtj7E4uxNdlOgv0eIG4=; b=Qiz3sySKOFqdc9OHfQen1BR0sbg9O9i3mjDg0IYLKOoPx+iMcODCCJZidAqu/0/LKS PZkWgG+RXBQUvk+h0xcUQt2t2Vb42+q9MO3cW9bmbqhl7HqbCScBx0/BJuxVB5m7wm5F +VyPWvxowHYTb1Ms+7bYz4hkUhvlZiO00lFIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ee+pTGnVT+vGyl9abFk0k+47Zf8akJ26L389xweuJiHWok5gLQCuB/HwLQhcbf3Tqk NbSzmZbkBVYLZsfDlYcjT852ByjSCQ5nG2XBdtTKTj4J6ZfSOlQ/5L02hliBWLavOi5T +wZAdFyPFK8jPfB+5CBPrwhhKb+VZ1DHjD1SQ= MIME-Version: 1.0 Received: by 10.142.248.38 with SMTP id v38mr942415wfh.280.1259233810499; Thu, 26 Nov 2009 03:10:10 -0800 (PST) In-Reply-To: <790a9fff0911260229u40d9f499w28a7ce46e1f92467@mail.gmail.com> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> <790a9fff0911260229u40d9f499w28a7ce46e1f92467@mail.gmail.com> Date: Thu, 26 Nov 2009 18:10:10 +0700 Message-ID: From: Edho P Arief To: Scot Hetzel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 11:10:11 -0000 On Thu, Nov 26, 2009 at 5:29 PM, Scot Hetzel wrote: > On 11/26/09, Jeremy Chadwick wrote: >> I'm a bit curious about something, so maybe someone can help me >> =C2=A0understand: >> >> =C2=A0Why are people bothering with GPT labels (or in some cases, glabel= s) >> =C2=A0when AHCI (whether it be ataahci.ko or ahci.ko) is in use? =C2=A0U= nder what >> =C2=A0circumstance would the device name change dynamically in this situ= ation? >> > > There was a thread about this problem where the drives had changed > their device names due to a change in the kernel drive =C2=A0(Current lis= t > from July): > > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009377.html > > Through out this thread there were various suggests on how he could > recover the system, and prevent the problem from occurring in the > future. > > One of the suggestions was that use of zpool replace to change from > device names to using glabel labels. > > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html > >> =C2=A0I've never witnessed this happening with AHCI, at least on Intel >> =C2=A0systems, and I've hot-swapped hard disks many times over. >> > > Using glabels, gpt labels, or gptid solves the problem of not needing > to remember which device name the drive originally had. =C2=A0For instanc= e, > on a zfs zraid pool with 3 disks (ad1 ad2 ad3) you could disconnect > the pool from one computer and connect it to another system and it > wouldn't matter which order you reconnected the drives (1 2 3 or 3 =C2=A0= 1 > 2) as the pool would still be recognized when it is imported on the > new system. =C2=A0Also if the new system already has drives ad1 and ad2, = it > wouldn't matter. > > Scot for some reasons it sounds to me like 'avoiding problem' since device name shouldn't matter in zfs (or so I read) --=20 O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 11:42:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EF2F106568F for ; Thu, 26 Nov 2009 11:42:50 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 3C8AF8FC1A for ; Thu, 26 Nov 2009 11:42:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 24EF93B04E for ; Thu, 26 Nov 2009 12:42:48 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81Z0QDtrGEIz for ; Thu, 26 Nov 2009 12:42:47 +0100 (CET) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 586AB39CE1 for ; Thu, 26 Nov 2009 12:42:47 +0100 (CET) Date: Thu, 26 Nov 2009 12:42:17 +0100 From: Ollivier Robert To: freebsd-stable@freebsd.org Message-ID: <20091126114217.GA64047@roberto-al.eurocontrol.fr> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <4B0E43B1.6050802@tzim.net> <790a9fff0911260200kf07d6d2nf7cf9eb9d2c07bcf@mail.gmail.com> <4B0E61E2.7070509@tzim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <4B0E61E2.7070509@tzim.net> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 11:42:50 -0000 According to Arnaud Houdelette: >As I said, the label is not present in /dev/gpt while used with >adaXp1 ( here ada1p1 has label HD753LJ-1) : ># ls /dev/gpt >HD753LJ-4 zfs-boot ># zpool replace tank ada1p1 gpt/HD753LJ-1 >cannot open 'gpt/HD753LJ-1': no such GEOM provider >I know there is the solution of cleaning the disk and resilvering, >but if I could avoid this ? Do you load glabel in loader.conf? I think that in order to be able to use GPT labels in GEOM (and thus ZFS), you set them with gpart, glabel will "load" them in the kernel and you then can use them for zfs. I recently moved from ata to ahci and wanted to use labels for the swap partitions. So I added a label to my swap partitions with gpart, they got recognized by geom thru glabel and I was able to use /dev/gpt/swapN instead of the usual /dev/adNp2 that were there before. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 11:53:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25DF41065670 for ; Thu, 26 Nov 2009 11:53:15 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D31A88FC08 for ; Thu, 26 Nov 2009 11:53:14 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NDcuO-0007Wu-7z for freebsd-stable@freebsd.org; Thu, 26 Nov 2009 12:53:12 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 12:53:12 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 12:53:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 26 Nov 2009 12:52:53 +0100 Lines: 12 Message-ID: References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> <790a9fff0911260229u40d9f499w28a7ce46e1f92467@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: Sender: news Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 11:53:15 -0000 Edho P Arief wrote: > for some reasons it sounds to me like 'avoiding problem' since device > name shouldn't matter in zfs (or so I read) Theoretically, you should be right, but the details are still fuzzy. At the very least, the sequence "zpool export" - shuffle drives around - "zpool import" should work without problems, though ZFS might pick up different drive names if multiple labels are present; for example if using partitions, some of the drives in the pool could be imported as "adXp1" and others as "gptid/xxxx..." so a manual intervention might be needed to keep things consistent. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 12:00:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7606106568B for ; Thu, 26 Nov 2009 12:00:07 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 87BD18FC13 for ; Thu, 26 Nov 2009 12:00:07 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NDd14-000281-A8 for freebsd-stable@freebsd.org; Thu, 26 Nov 2009 13:00:06 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 13:00:06 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 13:00:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 26 Nov 2009 12:56:50 +0100 Lines: 17 Message-ID: References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: <20091126085034.GA51998@icarus.home.lan> Sender: news Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 12:00:07 -0000 Jeremy Chadwick wrote: > Why are people bothering with GPT labels (or in some cases, glabels) > when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what > circumstance would the device name change dynamically in this situation? > > I've never witnessed this happening with AHCI, at least on Intel > systems, and I've hot-swapped hard disks many times over. It isn't specific to AHCI, but this is where most people encountered it first. The issue in question is "how to make ZFS survive drive renaming" for any cause - driver change, controller change, drive shuffling, etc. In general, ZFS will taste individual drives on "zpool import" so will try to do the right thing, but it might pick up different labels for different drives, etc. Using glabel tricks simply makes the naming a bit more consistent. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 13:29:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65CB1106566B; Thu, 26 Nov 2009 13:29:52 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id C50028FC14; Thu, 26 Nov 2009 13:29:51 +0000 (UTC) Received: by fxm10 with SMTP id 10so629683fxm.14 for ; Thu, 26 Nov 2009 05:29:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=K4wCeOiLeppQjKM03+++rdbLHWjTfNaSUsVW21mTYuM=; b=dfTJQdf8wz+uwJZEKjBrGYiC4KKLkT/mjDkY1nQElOU5FeXOqVSjr9AlMdu51OCQXV bQz39aLovavAxpAYFLhr8c4xZ6GleWEs4msI34jXhtJWEiTgBgvNymnxZbgcaidjV9R7 /WLHR3Dw15fMNM+ISkyYeycHHvPUG74c5E+9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=IhZoWrKq16xBUNJEjOFNJfJBZvEqOZ3xHC9I1xGkgnXyD56shQb20DkDd1XQSk00Uu N+I3fgiFiIGtpdMo6vmK8Exn5L6WJZo+jy3/EUo1tOzmxWbTfUj5y6RYgugaF6QR/oR4 n9Bag/HuR02toIQVi8wAAQ9itftXWzgwqVIfA= Received: by 10.102.249.18 with SMTP id w18mr876451muh.51.1259240865393; Thu, 26 Nov 2009 05:07:45 -0800 (PST) Received: from ndenev.cmotd.com ([195.34.111.178]) by mx.google.com with ESMTPS id 12sm1684965muq.8.2009.11.26.05.07.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 05:07:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: Date: Thu, 26 Nov 2009 15:07:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27DF657E-A14A-4B6F-ABE5-877B018FEE42@gmail.com> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> To: Ivan Voras X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 13:29:52 -0000 On Nov 26, 2009, at 1:56 PM, Ivan Voras wrote: > Jeremy Chadwick wrote: >=20 >> Why are people bothering with GPT labels (or in some cases, glabels) >> when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under = what >> circumstance would the device name change dynamically in this = situation? >> I've never witnessed this happening with AHCI, at least on Intel >> systems, and I've hot-swapped hard disks many times over. >=20 > It isn't specific to AHCI, but this is where most people encountered = it first. The issue in question is "how to make ZFS survive drive = renaming" for any cause - driver change, controller change, drive = shuffling, etc. >=20 > In general, ZFS will taste individual drives on "zpool import" so will = try to do the right thing, but it might pick up different labels for = different drives, etc. Using glabel tricks simply makes the naming a bit = more consistent. >=20 >=20 What about "zpool import -d /dev/gpt/" ? Though last time I tried this it refused to work for some reason.=20 Regards, Niki Denev From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 13:45:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8AC106566C for ; Thu, 26 Nov 2009 13:45:16 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from golanth.tzim.net (unknown [IPv6:2001:41d0:1:d91f:21c:c0ff:fe4b:cf32]) by mx1.freebsd.org (Postfix) with ESMTP id C98F28FC17 for ; Thu, 26 Nov 2009 13:45:15 +0000 (UTC) Received: from 12rf.tzim.net ([82.232.60.244] helo=[192.168.0.14]) by golanth.tzim.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NDeeo-0004EE-LY for freebsd-stable@freebsd.org; Thu, 26 Nov 2009 14:45:14 +0100 Message-ID: <4B0E866D.9040400@tzim.net> Date: Thu, 26 Nov 2009 14:45:17 +0100 From: Arnaud Houdelette User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: tzim@tzim.net X-Authenticator: plain Subject: atacontrol spindown equivalent for ahci/ada X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 13:45:16 -0000 Is there a equivalent command (camcontrol something ... ?) to atacontrol spindown when using ahci(4) ? I'd like to continue using this feature to reduce power consumption during night hours. Arnaud From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 13:48:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBDB9106568F for ; Thu, 26 Nov 2009 13:48:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5EDB68FC27 for ; Thu, 26 Nov 2009 13:48:47 +0000 (UTC) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 9pW41d0050EZKEL53pon09; Thu, 26 Nov 2009 13:48:47 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 9pom1d0073S48mS3MponcD; Thu, 26 Nov 2009 13:48:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 94F811E3035; Thu, 26 Nov 2009 05:48:45 -0800 (PST) Date: Thu, 26 Nov 2009 05:48:45 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091126134845.GA57738@icarus.home.lan> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Can't use gpt labels re-importing pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 13:48:48 -0000 On Thu, Nov 26, 2009 at 12:56:50PM +0100, Ivan Voras wrote: > Jeremy Chadwick wrote: > > >Why are people bothering with GPT labels (or in some cases, glabels) > >when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what > >circumstance would the device name change dynamically in this situation? > > > >I've never witnessed this happening with AHCI, at least on Intel > >systems, and I've hot-swapped hard disks many times over. > > It isn't specific to AHCI, but this is where most people encountered > it first. The issue in question is "how to make ZFS survive drive > renaming" for any cause - driver change, controller change, drive > shuffling, etc. > > In general, ZFS will taste individual drives on "zpool import" so > will try to do the right thing, but it might pick up different > labels for different drives, etc. Using glabel tricks simply makes > the naming a bit more consistent. What I'm having trouble understanding is where the "more consistent" concept comes from. I guess it ultimately depends on one's system configuration. For example: Tom Evans' situation greatly benefits from use of labels, since his configuration consists of 1) multiple SATA controllers, and 2) moving drives around between different controllers. This isn't going to happen in most production server environments, where the there is a static number of disks and (usually) a single controller. This is the "situation" I was referring to; "environment" or "configuration" would have been a more accurate choice of word. On 4-disk Supermicro systems (Intel ICHx + AHCI based, with hot-swap drive bays, with FreeBSD 7.x/8.x and ataahci), depending on what ICHx ports the drives are plugged into, your drive bays/disks are going to be static/consistent. SATA port #0 = ad4, SATA port #1 = ad6, and so on. These won't change unless you do something like, say, disable a SATA port or disable AHCI mode in the BIOS. Regardless, I'm almost certain I've made the mistake on a 4-disk system of doing (physical) system cleaning, which involves dusting out all of the bays and so on -- and ended up inserting a drive/carrier/disk into a bay which it wasn't part of prior to the shutdown. "zpool import" took care of things for me. If someone wants me to validate my own memory (the more I work Grave shift the more I find my memory failing me...), I'd be more than happy to spend a weekend messing around moving disks + reporting back what the behaviour is on RELENG_8. I have a "spare" 5-disk (6 ports) system which can be used for this purpose (Supermicro X7SBA + 5 disks). I spend most of my time messing around with disks at my night job as is... :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 14:07:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30EA6106566B for ; Thu, 26 Nov 2009 14:07:34 +0000 (UTC) (envelope-from michal@ionic.co.uk) Received: from mail1.sharescope.co.uk (pm1.ionic.co.uk [85.159.80.19]) by mx1.freebsd.org (Postfix) with ESMTP id E83008FC26 for ; Thu, 26 Nov 2009 14:07:33 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail1.sharescope.co.uk (Postfix) with ESMTP id E7C1FFC0E7; Thu, 26 Nov 2009 13:50:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at sharescope.co.uk Received: from mail1.sharescope.co.uk ([127.0.0.1]) by localhost (mail1.sharescope.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQiH8Iafk9Xw; Thu, 26 Nov 2009 13:50:50 +0000 (GMT) Received: from [192.168.2.37] (office.ionic.co.uk [85.159.85.2]) (Authenticated sender: chris@sharescope.co.uk) by mail1.sharescope.co.uk (Postfix) with ESMTPSA id EB97CFC0E2; Thu, 26 Nov 2009 13:50:49 +0000 (GMT) Message-ID: <4B0E87B9.2040903@ionic.co.uk> Date: Thu, 26 Nov 2009 13:50:49 +0000 From: Michal User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Arnaud Houdelette , freebsd-stable@freebsd.org References: <4B0E866D.9040400@tzim.net> In-Reply-To: <4B0E866D.9040400@tzim.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: atacontrol spindown equivalent for ahci/ada X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 14:07:34 -0000 Arnaud Houdelette wrote: > Is there a equivalent command (camcontrol something ... ?) to atacontrol > spindown when using ahci(4) ? > I'd like to continue using this feature to reduce power consumption > during night hours. > > Arnaud > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" someone even wrote a script. Search the OpenBSD archives From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 14:56:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C9B106566C for ; Thu, 26 Nov 2009 14:56:55 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2E50D8FC16 for ; Thu, 26 Nov 2009 14:56:55 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NDfm9-00039M-T4 for freebsd-stable@freebsd.org; Thu, 26 Nov 2009 15:56:53 +0100 Received: from 85.173.92.192 ([85.173.92.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 15:56:53 +0100 Received: from dsh by 85.173.92.192 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Nov 2009 15:56:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Denis Shaposhnikov Date: Thu, 26 Nov 2009 17:56:24 +0300 Lines: 10 Message-ID: <20091126175624.20c7d5c9@wizard.volgograd.ru> References: <4B0E866D.9040400@tzim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 85.173.92.192 In-Reply-To: <4B0E866D.9040400@tzim.net> X-Newsreader: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd7.2) Sender: news Subject: Re: atacontrol spindown equivalent for ahci/ada X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 14:56:55 -0000 Hello, On Thu, 26 Nov 2009 14:45:17 +0100 Arnaud Houdelette wrote: > Is there a equivalent command (camcontrol something ... ?) to > atacontrol spindown when using ahci(4) ? "camcontrol standby" works for me. It stops my HDD. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 18:10:43 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACA89106566B for ; Thu, 26 Nov 2009 18:10:43 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B3FA8FC22 for ; Thu, 26 Nov 2009 18:10:42 +0000 (UTC) Received: (from brett@localhost) by lariat.net (8.9.3/8.9.3) id KAA14021 for stable@freebsd.org; Thu, 26 Nov 2009 10:43:13 -0700 (MST) Date: Thu, 26 Nov 2009 10:43:13 -0700 (MST) From: Brett Glass Message-Id: <200911261743.KAA14021@lariat.net> To: stable@freebsd.org Cc: Subject: 8.0 kernel fails to build if some USB drivers are trimmed out; error in /sys/conf/files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:10:43 -0000 Happy Thanksgiving to everyone in the US (and elsewhere as well)! I encountered a strange bug when I was "trimming" the GENERIC FreeBSD RELEASE-8.0 kernel to omit drivers for hardware that would not be used on one target platform. I removed all of the USB Ethernet drivers except for "udav" (Davicom USB Ethernet) and tried to rebuild the kernel. The build stopped at the point where the kernel was linked, reporting undefined references in the file /sys/usb/net/if_udav.c to "uether_pause", "uether_ifdetach", "uether_getmii", and other routines with similar names. I discovered that these functions are defined in the file usb_ethernet.c, which is in the same directory as if_udav.c. A look at the file /usr/src/sys/i386/compile/KERNELNAME/Makefile showed that "usb_ethernet.o" was missing from the list of object files in the variable "OBJS". Because the Makefile wasn't properly triggering the compilation of usb_ethernet.c or including usb_ethernet.o in the list of files to be linked, the build was aborting at link time due to the unresolved references. After a bit of research (I am admittedly unfamiliar with all of the details of the kernel build system), it appears to me that this problem is the result of the use of parentheses on line 1623 of the file /sys/conf/files. This is the only place in any of the kernel dependency metadata where parentheses are used around a list of driver names, and removing them seems to solve the problem. More experimentation seems to indicate that the GENERIC kernel builds by sheer luck, due to an odd quirk in the "config" utility. The utility happens to do the right thing when at least one of the drivers in the middle of the parenthesized list (that is, not the first or last) is included in the kernel, as is true in GENERIC. This masks the bug. But the "config" utility produces an incorrect list of dependencies when none of the drivers in the middle of the parenthesized list is included in the kernel. I'll leave it to the committers to decide whether it is better to make the "config" utility handle parentheses correctly, or simply to make sure that no parentheses are used in the kernel dependency metadata. I've submitted this bug as PR 140904. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 18:44:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B565106566B for ; Thu, 26 Nov 2009 18:44:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 8122A8FC19 for ; Thu, 26 Nov 2009 18:44:10 +0000 (UTC) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id 9uMl1d00316AWCUA7ukBxn; Thu, 26 Nov 2009 18:44:11 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id 9ukA1d0023S48mS8SukAdP; Thu, 26 Nov 2009 18:44:10 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 206731E3035; Thu, 26 Nov 2009 10:44:09 -0800 (PST) Date: Thu, 26 Nov 2009 10:44:09 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091126184409.GA65045@icarus.home.lan> References: <200911261743.KAA14021@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911261743.KAA14021@lariat.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0 kernel fails to build if some USB drivers are trimmed out; error in /sys/conf/files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:44:10 -0000 On Thu, Nov 26, 2009 at 10:43:13AM -0700, Brett Glass wrote: > I encountered a strange bug when I was "trimming" the GENERIC FreeBSD > RELEASE-8.0 kernel to omit drivers for hardware that would not be used on one > target platform. I removed all of the USB Ethernet drivers except for "udav" > (Davicom USB Ethernet) and tried to rebuild the kernel. The build stopped at > the point where the kernel was linked, reporting undefined references in the > file /sys/usb/net/if_udav.c to "uether_pause", "uether_ifdetach", > "uether_getmii", and other routines with similar names. I discovered that > these functions are defined in the file usb_ethernet.c, which is in the same > directory as if_udav.c. Missing symbols are almost always the sign of a missing "device" directive inside of the kernel configuration file. In this case, they're part of sys/dev/usb/net/usb_ethernet.[ch], which should be being built. You absolutely need to include the following devices in addition to "device udav": device ether device miibus I assume you did leave "device usb" and related pieces (meaning lines around that area) intact. Keeping it simple: can we see your kernel configuration file in its entirety? It isn't included in the PR, nor in this Email. > More experimentation seems to indicate that the GENERIC kernel builds by sheer > luck, due to an odd quirk in the "config" utility. I haven't used "config" since the early 3.x days. I'm certain "make buildkernel" and friends relies on it, but configuring a kernel + building a kernel is a lot simpler now. Read /usr/src/Makefile, starting with the line "For individuals wanting to upgrade their sources". The steps there are accurate. I don't think parenthesis are the core of the problem, given that there are many other devices in /sys/conf/files which utilise said method. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 19:05:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF324106566B for ; Thu, 26 Nov 2009 19:05:56 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id B59678FC08 for ; Thu, 26 Nov 2009 19:05:55 +0000 (UTC) Received: by iwn36 with SMTP id 36so571390iwn.3 for ; Thu, 26 Nov 2009 11:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SDgvwJCfRbaMkGxMSJIkvlE30HQNiMPwBMVoHh1jn1Q=; b=hfORhlwYbc9nklCcAMFveKPBMArxvamI/fsZzxcaBH7Qtr7KKXomY9aWDtXhne59bx EuiM55FfIf7LPGK/byGeb1y46BIFomDNNFGTCddNH0fvdEDIHZ+WDFH/Px/vHOLV3CLe ngrFLY6O8z81GzbjQs3oSt4lU4fbncCukM+80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JxLPEyi9/4b17wp9tz0QHPgBMUoMuDzsA5fqG5L8UpJLPw5xjfTAlqZUqxgoJlMM+t emgMNu9YZGRVLExNGTNP8ejACvWkG6nVNCtJT5Kzz7LIWG5ow8UqV/BpSUUbQZISXlrz UTYMk90JnjIaVLYZvWCBox1b6QvxZ2QCkq1pM= MIME-Version: 1.0 Received: by 10.231.121.69 with SMTP id g5mr159895ibr.44.1259262355164; Thu, 26 Nov 2009 11:05:55 -0800 (PST) In-Reply-To: <20091126184409.GA65045@icarus.home.lan> References: <200911261743.KAA14021@lariat.net> <20091126184409.GA65045@icarus.home.lan> Date: Thu, 26 Nov 2009 13:05:55 -0600 Message-ID: <790a9fff0911261105n46e6b4e4g8c73e4a67af293c6@mail.gmail.com> From: Scot Hetzel To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 kernel fails to build if some USB drivers are trimmed out; error in /sys/conf/files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:05:57 -0000 On 11/26/09, Jeremy Chadwick wrote: > I don't think parenthesis are the core of the problem, given that there > are many other devices in /sys/conf/files which utilise said method. > There are only 2 places in the /sys/conf/files which use this method, and both of them are for usb drivers: # USB ethernet drivers # dev/usb/net/if_aue.c optional aue dev/usb/net/if_axe.c optional axe dev/usb/net/if_cdce.c optional cdce dev/usb/net/if_cue.c optional cue dev/usb/net/if_kue.c optional kue dev/usb/net/if_rue.c optional rue dev/usb/net/if_udav.c optional udav dev/usb/net/usb_ethernet.c \ optional (aue | axe | cdce | cue | kue | rue | udav) : # USB serial and parallel port drivers # dev/usb/serial/u3g.c optional u3g dev/usb/serial/uark.c optional uark dev/usb/serial/ubsa.c optional ubsa dev/usb/serial/ubser.c optional ubser dev/usb/serial/uchcom.c optional uchcom dev/usb/serial/ucycom.c optional ucycom dev/usb/serial/ufoma.c optional ufoma dev/usb/serial/uftdi.c optional uftdi dev/usb/serial/ugensa.c optional ugensa dev/usb/serial/uipaq.c optional uipaq dev/usb/serial/ulpt.c optional ulpt dev/usb/serial/umct.c optional umct dev/usb/serial/umodem.c optional umodem dev/usb/serial/umoscom.c optional umoscom dev/usb/serial/uplcom.c optional uplcom dev/usb/serial/uslcom.c optional uslcom dev/usb/serial/uvisor.c optional uvisor dev/usb/serial/uvscom.c optional uvscom dev/usb/serial/usb_serial.c optional ucom | \ (u3g | uark | ubsa | ubser | uchcom | ucycom | ufoma | uftdi | ugensa | uipaq | ulpt | umct | umodem | umoscom | uplcom | uslcom | uvisor | uvscom) It would be interesting if this also breaks for compiling 'USB serial and parallel port drivers' into the kernel. Scot From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 19:32:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3B251065676 for ; Thu, 26 Nov 2009 19:32:16 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED8C8FC1C for ; Thu, 26 Nov 2009 19:32:16 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id nAQJWCVn006614; Thu, 26 Nov 2009 20:32:13 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Nov 2009 20:32:11 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA57277@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 5.5-STABLE to 88.0-RELEASE Thread-Index: AcpuYPpdZmNxQr5DQiGs8SK0kipR+AAbXuWA References: From: "Johan Hendriks" To: "Randy Bush" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: RE: 5.5-STABLE to 88.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:32:16 -0000 >can one go from 5.5 to 8.0 using the normal hammer, or is it >multi-stage, and i should just blow it away and go from install? >randy It is do able, but you need to rebuild all ports. And to go from 5.5 to 8 it is adviced to go trough all major version, like 6 and 7 and then go to 8. So my take is, backup all your data, and config files and do a reinstall. This way you make sure there are no un needed libs and old stuff laying around which can clobber your system. Regards, Johan Hendriks =20 From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 19:33:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 921FC1065693; Thu, 26 Nov 2009 19:33:55 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (server70.appriver.com [69.20.119.203]) by mx1.freebsd.org (Postfix) with ESMTP id 215798FC08; Thu, 26 Nov 2009 19:33:54 +0000 (UTC) X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note: TCH-CT/SI:0-240/SG:5 11/26/2009 2:33:19 PM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.797229 p=-0.910044 Source White X-Signature-Violations: 0-0-0-4693-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 108087470; Thu, 26 Nov 2009 14:33:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Nov 2009 11:25:50 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC USB/FS problem Thread-Index: AcpucLHwJ6bfJmWlQYaRaAUxK7k9NgAXZE+h References: <200911250937.08267.hselasky@c2i.net> <200911260920.32342.hselasky@c2i.net> From: "Guojun Jin" To: "Hans Petter Selasky" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: RE: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:33:55 -0000 Shall I fill a defect? or someone on this mailing list can take care of = this problem before release. -Jin -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Thu 11/26/2009 12:20 AM To: Guojun Jin Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; = freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem =20 On Thursday 26 November 2009 08:30:52 Guojun Jin wrote: > Most crash had the same back trace. This is also true when USB access > hangs, then unplug the drive. I think from the backtrace that this is not an USB issue. It is a = file-system=20 issue. --HPS From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 19:49:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A86EF106566B for ; Thu, 26 Nov 2009 19:49:27 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6708FC0C for ; Thu, 26 Nov 2009 19:49:27 +0000 (UTC) Received: from c83-253-248-99.bredband.comhem.se ([83.253.248.99]:47203 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1NDkL6-0003RG-6L; Thu, 26 Nov 2009 20:49:18 +0100 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 896C41D5E2F; Thu, 26 Nov 2009 20:49:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Thomas Backman In-Reply-To: Date: Thu, 26 Nov 2009 20:48:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86DD8C42-A49C-49F1-9EBE-1DFF8B8CAD73@exscape.org> References: <200911250937.08267.hselasky@c2i.net> <200911260920.32342.hselasky@c2i.net> To: Guojun Jin X-Mailer: Apple Mail (2.1077) X-Originating-IP: 83.253.248.99 X-Scan-Result: No virus found in message 1NDkL6-0003RG-6L. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1NDkL6-0003RG-6L 1a7e732dd16442cc988ee70a89109156 Cc: bugs@freebsd.org, freebsd-stable , freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: 8.0-RC USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:49:27 -0000 On Nov 26, 2009, at 8:25 PM, Guojun Jin wrote: > Shall I fill a defect? or someone on this mailing list can take care = of this problem before release. >=20 > -Jin 8.0 is halfway out already, you can download -RELEASE ISOs or upgrade = using freebsd-update. The main announcement just hasn't been made yet. Regards, Thomas= From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 19:56:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B7DE1065693; Thu, 26 Nov 2009 19:56:58 +0000 (UTC) (envelope-from gjin@ubicom.com) Received: from server70.appriver.com (gwlb1.appriver.com [69.20.60.122]) by mx1.freebsd.org (Postfix) with ESMTP id CC6248FC14; Thu, 26 Nov 2009 19:56:57 +0000 (UTC) X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Policy: GLOBAL - ubicom.com X-Primary: gjin@ubicom.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note: TCH-CT/SI:0-185/SG:5 11/26/2009 2:56:19 PM X-GBUdb-Analysis: 0, 216.112.109.98, Ugly c=0.797274 p=-0.910083 Source White X-Signature-Violations: 0-0-0-5884-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.112.109.98 X-Note-Reverse-DNS: 216.112.109.98.ptr.us.xo.net X-Note-WHTLIST: gjin@ubicom.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 115 116 117 118 122 123 221 X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [216.112.109.98] (HELO stork.scenix.com) by server70.appriver.com (CommuniGate Pro SMTP 5.3c2) with ESMTP id 108087851; Thu, 26 Nov 2009 14:56:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Nov 2009 11:48:18 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-R USB/FS problem Thread-Index: Acpu0RWtLDXlAiaQSguKNjWVz3+4BAAAFDVW References: <200911250937.08267.hselasky@c2i.net> <200911260920.32342.hselasky@c2i.net> <86DD8C42-A49C-49F1-9EBE-1DFF8B8CAD73@exscape.org> From: "Guojun Jin" To: "Thomas Backman" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bugs@freebsd.org, freebsd-stable , freebsd-usb@freebsd.org, Hans Petter Selasky Subject: RE: 8.0-R USB/FS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:56:58 -0000 Be clear, the recent (last 5 days) tests are based on -RELEASE made on = 21st, not RC any more, so I changed title now. Since this problem occurs on multiple machines (not just single one), = with different USB drives, so I would like this to be fixed before the formal release if possible. -----Original Message----- From: Thomas Backman [mailto:serenity@exscape.org] Sent: Thu 11/26/2009 11:48 AM To: Guojun Jin Cc: Hans Petter Selasky; bugs@freebsd.org; freebsd-stable; = freebsd-usb@freebsd.org Subject: Re: 8.0-RC USB/FS problem =20 On Nov 26, 2009, at 8:25 PM, Guojun Jin wrote: > Shall I fill a defect? or someone on this mailing list can take care = of this problem before release. >=20 > -Jin 8.0 is halfway out already, you can download -RELEASE ISOs or upgrade = using freebsd-update. The main announcement just hasn't been made yet. Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 20:11:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A82D31065670 for ; Thu, 26 Nov 2009 20:11:18 +0000 (UTC) (envelope-from listreader@lazlarlyricon.com) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id 61E038FC1B for ; Thu, 26 Nov 2009 20:11:18 +0000 (UTC) Received: from ipb1.telenor.se (195.54.127.164) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC013C0606 for freebsd-stable@freebsd.org; Thu, 26 Nov 2009 20:51:07 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsVkAHpqDktV44PPPGdsb2JhbACBTJd4glsBAQEBN7g8hDEEhWo X-IronPort-AV: E=Sophos;i="4.47,295,1257116400"; d="scan'208";a="8055376" Received: from c-cf83e355.09-42-6e6b7010.cust.bredbandsbolaget.se (HELO lazlar.kicks-ass.net) ([85.227.131.207]) by ipb1.telenor.se with ESMTP; 26 Nov 2009 20:51:06 +0100 Message-ID: <4B0EDC29.5000109@lazlarlyricon.com> Date: Thu, 26 Nov 2009 20:51:05 +0100 From: Rolf Nielsen User-Agent: Thunderbird 2.0.0.23 (X11/20091117) MIME-Version: 1.0 To: Johan Hendriks References: <57200BF94E69E54880C9BB1AF714BBCBA57277@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA57277@w2003s01.double-l.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randy Bush , freebsd-stable@freebsd.org Subject: Re: 5.5-STABLE to 88.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 20:11:18 -0000 Johan Hendriks wrote: >> can one go from 5.5 to 8.0 using the normal hammer, or is it >> multi-stage, and i should just blow it away and go from install? > >> randy > > It is do able, but you need to rebuild all ports. > And to go from 5.5 to 8 it is adviced to go trough all major version, > like 6 and 7 and then go to 8. > > So my take is, backup all your data, and config files and do a > reinstall. > This way you make sure there are no un needed libs and old stuff laying > around which can clobber your system. > > Regards, > Johan Hendriks > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > I believe you'll have to wait quite some time for 88.0. ;) A lot of config files have changed since 5.5. Some have been added and some have been removed and others been changed in various ways. I'd suggest either removing all ports, then going through the 5.5 -> 6.0 -> 7.0 -> 8.0 and be sure to run the mergemaster, make delete-old, make delete-old-libs at each stage and finally install the ports you need or back up your data (not the config files), do a fresh install of 8.0 and configure from scratch, restore the data, install the ports you need. I may be paranoid suggesting this, and others may disagree with me, however I've had problems caused by config files changing after upgrading. Good Luck, Rolf Nielsen From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 20:43:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DA3F1065676 for ; Thu, 26 Nov 2009 20:43:27 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 0E19A8FC0A for ; Thu, 26 Nov 2009 20:43:27 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NDlBU-000Mcf-2n; Thu, 26 Nov 2009 20:43:24 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 6CA152C498B6; Fri, 27 Nov 2009 05:43:23 +0900 (JST) Date: Fri, 27 Nov 2009 05:43:23 +0900 Message-ID: From: Randy Bush To: Rolf Nielsen In-Reply-To: <4B0EDC29.5000109@lazlarlyricon.com> References: <57200BF94E69E54880C9BB1AF714BBCBA57277@w2003s01.double-l.local> <4B0EDC29.5000109@lazlarlyricon.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Johan Hendriks , freebsd-stable@freebsd.org Subject: Re: 5.5-STABLE to 88.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 20:43:27 -0000 > I'd suggest either removing all ports, then going through the 5.5 -> > 6.0 -> 7.0 -> 8.0 and be sure to run the mergemaster, make delete-old, > make delete-old-libs at each stage and finally install the ports you > need or back up your data (not the config files) no thanks. too much of a mess, and very little on the system that i really need. it's just that it is remote. but i'll visit and install perhaps the section labeled "To upgrade in-place from 5.x-stable to current" should be edited or removed from /usr/src/UPDATING. :) thanks all randy From owner-freebsd-stable@FreeBSD.ORG Thu Nov 26 22:56:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F77106566B for ; Thu, 26 Nov 2009 22:56:01 +0000 (UTC) (envelope-from marco@tols.org) Received: from tols.org (goofy.tols.org [83.163.60.200]) by mx1.freebsd.org (Postfix) with ESMTP id 746028FC1A for ; Thu, 26 Nov 2009 22:56:00 +0000 (UTC) Received: from donald.home.tols.org (localhost [127.0.0.1]) by donald.home.tols.org (8.14.3/8.14.3) with ESMTP id nAQMtxPR078290 for ; Thu, 26 Nov 2009 22:55:59 GMT (envelope-from marco@donald.home.tols.org) Received: (from marco@localhost) by donald.home.tols.org (8.14.3/8.14.3/Submit) id nAQMtx7s078289 for freebsd-stable@freebsd.org; Thu, 26 Nov 2009 23:55:59 +0100 (CET) (envelope-from marco) Date: Thu, 26 Nov 2009 23:55:59 +0100 From: Marco van Tol To: freebsd-stable@freebsd.org Message-ID: <20091126225559.GA943@donald.home.tols.org> Mail-Followup-To: freebsd-stable@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCBA57277@w2003s01.double-l.local> <4B0EDC29.5000109@lazlarlyricon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: 5.5-STABLE to 88.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 22:56:02 -0000 On Fri, Nov 27, 2009 at 05:43:23AM +0900, Randy Bush wrote: [... suggestions and advise upgrading 5.5 to 88^H ...] > perhaps the section labeled "To upgrade in-place from 5.x-stable to > current" should be edited or removed from /usr/src/UPDATING. :) That's something I found curious as well. ;-) My vote would be to update it to "the previous version" or 7.x, whichever is most accurate and/or fits best. If 5.x is accurate, forgive me for sending this email. -- If you continually give, you will continually have. - www.chinese-fortune-cookie.com From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 01:08:55 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57795106566B for ; Fri, 27 Nov 2009 01:08:55 +0000 (UTC) (envelope-from jguojun@sbcglobal.net) Received: from web82207.mail.mud.yahoo.com (web82207.mail.mud.yahoo.com [209.191.86.102]) by mx1.freebsd.org (Postfix) with SMTP id 23C2B8FC0A for ; Fri, 27 Nov 2009 01:08:54 +0000 (UTC) Received: (qmail 52252 invoked by uid 60001); 27 Nov 2009 01:08:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1259284134; bh=6lFUGoGhB+fcyhs2+19dxnApaA11+ts97M7pKDQBk4A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hCKseKODsUjCfV9v2SuA0x18e6ZaCTIJf19oPEsF9YsjJqKGWBUbekT5BCWB+QRB4CACYwjEByorl+RkmR5xROiG88XGRCAzJ7ZR5fGgpirmfiUlMsxZGWU80Ez7/shRAISnPWbPDlbiwK1uQP1osscftvtYSQ41yhw7ls2y75U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=cgvayEKjh6pO6i7XeGK6tVso9FZnmtdu62Mb0WHwZG59TjZbyBuNrgQdGpsqzhlQtteejlqOWZkX/nU4LT1+PMTiop3TImoV+LkJxXsTqCE+xvV7rFU6d8KPOYXs27UbP2p8u4ry+JO3pemXrBpmT/YzdDavHRIv8IiqHv4vrh0=; Message-ID: <390534.50689.qm@web82207.mail.mud.yahoo.com> X-YMail-OSG: a9J_QQoVM1n9d82zsK0YeYguKE1e_hx2p6BCo6Qr1NUnbHovZkU4dtHQCaCPmBcOj9hNpXUkDpOlSs9dMTVKX2krs.Zd36jPx9EWV82n32LLF_d3cX4K7q_fCx2iZcxV.zRsZkLMDqMBfVkfa0gBOemDreXeAwMDAy0djkqApyNL4eamskDFwoel05TwZ0QOcseFEQnbmfSbRH1JFBiFdrVb4Hds_OHVe91a6RjxMqhNpLiDdCmi_8oVUcJaOTEOLiCJtUpUSImaiYGhg1FMVmxuT0ak5dOZoO7.f8TxdZWrh.k3LiauZuoGLwEeTPlMbS.Vhh30lJ1QcR.H1N3KKwPv Received: from [76.202.192.211] by web82207.mail.mud.yahoo.com via HTTP; Thu, 26 Nov 2009 17:08:54 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.8.100.260964 Date: Thu, 26 Nov 2009 17:08:54 -0800 (PST) From: Jin Guojun To: freebsd-hardware@freebsd.org, freebsd-stable , Steve Polyack In-Reply-To: <4B0C1A72.3000301@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: Panic possibly related to glabel/geom and siis(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 01:08:55 -0000 This is similar to what I have fight on last two weeks (was 8.0-RC USB/FS). My back trace from the panic is some different from yours, but the behave is the same. When access USB drives from 8.0-RC and 8.0-R will cause drives dead, vanish or reset, thus causing panic. >From both cases, it looks like a hotplug/automount related problem. --- On Tue, 11/24/09, Steve Polyack wrote: > From: Steve Polyack > Subject: Panic possibly related to glabel/geom and siis(4) > To: freebsd-hardware@freebsd.org, "freebsd-stable" , freebsd-geom@FreeBSD.org > Date: Tuesday, November 24, 2009, 5:40 PM > I have a system running > 8.0-PRERELEASE with multiple drives and SATA port > multipliers (siis controllers and PMPs). All of the > attached drives are labeled via glabel(8) and then included > into a ZFS pool. During some testing to determine how > the system would react to a dead drive (simulated by > physically removing a drive during operation), I was > able to produce a panic. > > Now, I know that the SATA PMP and siis(4) code to handle > and recover from device errors is incomplete, but I believe > the crash may be particular to using glabel'd drives. > Basically, after removing a drive while the zpool is in use > and issues 'camcontrol reset' and 'rescan' on the > appropriate bus, the physical device associated with the > drive disappears. In this case: > (pass5:siisch7:0:15:0): lost device > (pass5:siisch7:0:15:0): removing device entry > (ada2:siisch7:0:0:0): lost device > > and /dev/ada2 disappears. However, the associated > glabel /dev/label/bigdisk07 remains. Since my ZFS pool > is created based on the drive glabels, I believe this is why > ZFS never notices the drives disappear either. > > Do glabels typically go away after a physical device is > lost? Should this not be the case? > > > After some runtime with the physical device missing, a > kernel panic is produced: > > ada2:siisch7:0:0:0): Synchronize cache failed > (ada2:siisch7:0:0:0): removing device entry > > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 14 > fault virtual address = 0x48 > fault code > = supervisor write data, page not present > instruction pointer = > 0x20:0xffffffff8035f375 > stack pointer > = 0x28:0xffffff800006db60 > frame pointer > = 0x28:0xffffff800006db70 > 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 = 2 > (g_event) > [thread pid 2 tid 100014 ] > Stopped at > _mtx_lock_flags+0x15: lock > cmpxchgq %rsi,0x18(%rdi) > db> bt > Tracing pid 2 tid 100014 td 0xffffff00014d4ab0 > _mtx_lock_flags() at _mtx_lock_flags+0x15 > vdev_geom_release() at vdev_geom_release+0x33 > vdev_geom_orphan() at vdev_geom_orphan+0x15c > g_run_events() at g_run_events+0x104 > g_event_procbody() at g_event_procbody+0x55 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff800006dd30, rbp = 0 --- > > > I'm open to try patches and other suggestions. > Thanks. > _______________________________________________ > freebsd-hardware@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 01:24:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B20106566B; Fri, 27 Nov 2009 01:24:43 +0000 (UTC) (envelope-from kensmith@cse.buffalo.edu) Received: from localmailC.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.204]) by mx1.freebsd.org (Postfix) with ESMTP id DBAD68FC1B; Fri, 27 Nov 2009 01:24:42 +0000 (UTC) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 94D015627; Thu, 26 Nov 2009 20:06:25 -0500 (EST) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id 212545614; Thu, 26 Nov 2009 20:06:25 -0500 (EST) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id 1B6A355F2; Thu, 26 Nov 2009 20:06:25 -0500 (EST) Received: from [192.168.1.101] (cpe-74-77-179-53.buffalo.res.rr.com [74.77.179.53]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id A278C5B003A; Thu, 26 Nov 2009 20:06:24 -0500 (EST) From: Ken Smith To: freebsd-current@freebsd.org, freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Z5db9p2oJAthtKYUZSA6" Date: Thu, 26 Nov 2009 20:06:23 -0500 Message-Id: <1259283983.92302.23.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 27% Cc: Subject: 8.0-RELEASE completed... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 01:24:43 -0000 --=-Z5db9p2oJAthtKYUZSA6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just a quick note in case there are people here who aren't subscribed to the freebsd-announce@ mailing list. We have completed the 8.0-RELEASE cycle. Details about the release are available from the main web site, in particular the announcement itself is available here: http://www.freebsd.org/releases/8.0R/announce.html Thanks for all the help with testing during the release process, as well as your continued support of FreeBSD. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-Z5db9p2oJAthtKYUZSA6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAksPJg8ACgkQ/G14VSmup/YH5ACfQ+23gMjww1eqen+G4311ltUo QTUAnjqKfB4Q3qUyYOJji5v2lbwFNZVO =fybo -----END PGP SIGNATURE----- --=-Z5db9p2oJAthtKYUZSA6-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 03:06:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E6881065670; Fri, 27 Nov 2009 03:06:16 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail4.es.net [IPv6:2001:400:6000:6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 00A468FC14; Fri, 27 Nov 2009 03:06:15 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id nAR362Ma001648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Nov 2009 19:06:06 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CAB2C1CC0E; Thu, 26 Nov 2009 19:06:01 -0800 (PST) To: Ken Smith In-reply-to: Your message of "Thu, 26 Nov 2009 20:06:23 EST." <1259283983.92302.23.camel@neo.cse.buffalo.edu> Date: Thu, 26 Nov 2009 19:06:01 -0800 From: "Kevin Oberman" Message-Id: <20091127030601.CAB2C1CC0E@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-26_07:2009-11-16, 2009-11-26, 2009-11-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0911260287 Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: 8.0-RELEASE completed... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 03:06:16 -0000 > From: Ken Smith > Date: Thu, 26 Nov 2009 20:06:23 -0500 > Sender: owner-freebsd-stable@freebsd.org > > > Just a quick note in case there are people here who aren't subscribed to > the freebsd-announce@ mailing list. > > We have completed the 8.0-RELEASE cycle. Details about the release are > available from the main web site, in particular the announcement itself > is available here: > > http://www.freebsd.org/releases/8.0R/announce.html > > Thanks for all the help with testing during the release process, as well > as your continued support of FreeBSD. And congratulations and thanks to the entire FreeBSD release engineering team and the contributors. It's a .0 release, but my experience with it through the release cycle has been excellent. I especially appreciate the new USB stack which has fixed all sorts of annoying issues (and a couple that were a lot more than annoying) in the old stack. Great job! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 06:24:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15ED810657A0; Fri, 27 Nov 2009 06:24:01 +0000 (UTC) (envelope-from kline@thought.org) Received: from aristotle.thought.org (ns1.thought.org [209.180.213.210]) by mx1.freebsd.org (Postfix) with ESMTP id 6B66E8FC1D; Fri, 27 Nov 2009 06:24:00 +0000 (UTC) Received: from thought.org (tao.thought.org [10.47.0.250]) (authenticated bits=0) by aristotle.thought.org (8.14.2/8.14.2) with ESMTP id nAR5vYCi046064; Thu, 26 Nov 2009 21:57:34 -0800 (PST) (envelope-from kline@thought.org) Received: by thought.org (nbSMTP-1.00) for uid 1002 kline@thought.org; Thu, 26 Nov 2009 21:57:58 -0800 (PST) Date: Thu, 26 Nov 2009 21:57:58 -0800 From: Gary Kline To: Kevin Oberman Message-ID: <20091127055757.GA75657@thought.org> References: <1259283983.92302.23.camel@neo.cse.buffalo.edu> <20091127030601.CAB2C1CC0E@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091127030601.CAB2C1CC0E@ptavv.es.net> User-Agent: Mutt/1.4.2.3i X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: With 23 years of service to the Unix community. X-Spam-Status: No, score=-4.4 required=3.6 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on aristotle.thought.org Cc: Ken Smith , freebsd-stable , freebsd-current@freebsd.org Subject: Re: 8.0-RELEASE completed... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 06:24:01 -0000 Some questions that I hope are not too far OT:: On Thu, Nov 26, 2009 at 07:06:01PM -0800, Kevin Oberman wrote: > > From: Ken Smith > > Date: Thu, 26 Nov 2009 20:06:23 -0500 > > Sender: owner-freebsd-stable@freebsd.org > > > > > > Just a quick note in case there are people here who aren't subscribed to > > the freebsd-announce@ mailing list. > > > > We have completed the 8.0-RELEASE cycle. Details about the release are > > available from the main web site, in particular the announcement itself > > is available here: > > > > http://www.freebsd.org/releases/8.0R/announce.html > > > > Thanks for all the help with testing during the release process, as well > > as your continued support of FreeBSD. > > And congratulations and thanks to the entire FreeBSD release engineering > team and the contributors. It's a .0 release, but my experience with it > through the release cycle has been excellent. I especially appreciate the > new USB stack which has fixed all sorts of annoying issues (and a couple > that were a lot more than annoying) in the old stack. > /* I echo Kevin's congrats, of course; it ain't getting any *easier*, certainly. */ Altho I am still some time from having my migration from the 1998 Kayak -> 2009 Dell done and working, will it be possible to upgrade my 32bit 7.2-R, p4 to a 64bit 8.0? Even tho i am documenting __everything__, it isn't something I would care to do more than necessary. In going from 32bits to 64, does the filesystem change? My hunch is that it does, but thought I would get that clear as a first step. My Intell duo-core is very fast; would moving to the 64-bit system be a net gain or loss [in performance]. Eventuaaly, I *will* have 64-bit micros, killers or otherwise, :-) ... thanks in advance. > Great job! > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 7.31a release of Jottings: http://jottings.thought.org/index.php From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 07:48:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B96741065679 for ; Fri, 27 Nov 2009 07:48:52 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50B548FC1F for ; Fri, 27 Nov 2009 07:48:51 +0000 (UTC) Received: from maxwell.mencon.com.au (c122-107-224-152.eburwd5.vic.optusnet.com.au [122.107.224.152]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nAR7mdgk017594; Fri, 27 Nov 2009 18:48:40 +1100 Received: from [203.2.73.73] (chief.mencon.com.au [203.2.73.73]) by maxwell.mencon.com.au (Postfix) with ESMTP id F2CB25CFF; Fri, 27 Nov 2009 18:48:38 +1100 (EST) Message-ID: <4B0F845D.3000108@menhennitt.com.au> Date: Fri, 27 Nov 2009 18:48:45 +1100 From: Graham Menhennitt User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Mikhail T." References: <4B09D7BE.20602@aldan.algebra.com> In-Reply-To: <4B09D7BE.20602@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: openoffice stuck in _umtx_op X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 07:48:52 -0000 Mikhail T. wrote: > I'm trying to start OOo, and it hangs at start-up -- after popping up > its banner page. > > ktrace shows the following, slowly repeating, sequence of events: > > [...] > 32726 soffice.bin CALL > _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fffffbfeef0) > 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out > 32726 soffice.bin CALL gettimeofday(0x7fffffbfef70,0) > 32726 soffice.bin RET gettimeofday 0 > 32726 soffice.bin CALL clock_gettime(0,0x7fffffbfef00) > 32726 soffice.bin RET clock_gettime 0 > 32726 soffice.bin CALL > _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fffffbfeef0) > 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out > 32726 soffice.bin CALL gettimeofday(0x7fffffbfef70,0) > 32726 soffice.bin RET gettimeofday 0 > 32726 soffice.bin CALL clock_gettime(0,0x7fffffbfef00) > 32726 soffice.bin RET clock_gettime 0 > 32726 soffice.bin CALL > _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fffffbfeef0) > [...] > > what's happening? `ipcs -a' does not show anything extraordinary and > there is nothing in syslog either... > > The machine is running 7.2-STABLE/amd64 (as of Oct 25). Any ideas? Thanks! > Mikhail, I don't use OOo on FreeBSD, so I can't help you directly. However, I see similar behaviour on Kubuntu Linux. If I double click on some files that are associated with OOo, I see the splash screen and it hangs forever. If I start OOo from the command line without any parameters, it works correctly - I then open the file from the menu. Maybe that's a workaround for you for now. I haven't seen any bugs on the OOo site that seem to match this. I'll try to get a reproducable case and report it. Graham From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 08:12:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C96391065694 for ; Fri, 27 Nov 2009 08:12:21 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF258FC24 for ; Fri, 27 Nov 2009 08:12:21 +0000 (UTC) Received: (qmail 49019 invoked by uid 0); 27 Nov 2009 07:45:40 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Nov 2009 07:45:40 -0000 Date: Fri, 27 Nov 2009 02:45:39 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: 7.2 serial console/getty problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 08:12:21 -0000 Howdy, I'm having some issues getting a working serial console on a 7.2-amd64 system (Dell PE 2970). Everything is running at 9600bps to keep things simple (BIOS, loader, getty). Normal DB-9 null cable to another host. /etc/ttys has getty on ttyd0 with the "std.9600" gettytab entry and vt100 terminal type. The following works fine: -Console redirection via Dell's BIOS (I can enter setup, navigate BIOS, enter RAID config, etc.) -Boot loader (can enter boot params, select boot options, etc.) -Boot messages (displays fine) However once the machine boots and getty has control, things get a bit odd. I've tested this with various hosts using minicom and conserver (conserver.com). No problems with my other hosts running older versions of FreeBSD with the same settings (9600, 8N1, hw flow control). If I just hit "enter", I get a response like this: noooo~:oommv64(jkoomimnnwwou})(|t}}t9- It does not vary - always the same string. However, if I hit CTRL-D, then I get a normal prompt: FreeBSD/amd64 (bigmail.bway.net) (ttyd0) login: If at the "login:" prompt I just hit "enter" again without typing a username, I get the same garbled output. CTRL-D again gives me a proper prompt. Once I'm logged-in, there seem to be no issues. "vi", "top" and other things that rely on the terminal being sane work fine. Any ideas? Thanks, Charles ___ Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet - www.bway.net spork@bway.net - 212.655.9344 From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 08:33:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC7A4106566B for ; Fri, 27 Nov 2009 08:33:07 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr16.xs4all.nl (smtp-vbr16.xs4all.nl [194.109.24.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2628FC0A for ; Fri, 27 Nov 2009 08:33:07 +0000 (UTC) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr16.xs4all.nl (8.13.8/8.13.8) with ESMTP id nAR8X4a9055040; Fri, 27 Nov 2009 09:33:04 +0100 (CET) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 86D25BAC2; Fri, 27 Nov 2009 09:33:04 +0100 (CET) Date: Fri, 27 Nov 2009 09:33:04 +0100 From: Roland Smith To: Gary Kline Message-ID: <20091127083304.GA8618@slackbox.xs4all.nl> References: <1259283983.92302.23.camel@neo.cse.buffalo.edu> <20091127030601.CAB2C1CC0E@ptavv.es.net> <20091127055757.GA75657@thought.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20091127055757.GA75657@thought.org> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: 8.0-RELEASE completed... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 08:33:08 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 26, 2009 at 09:57:58PM -0800, Gary Kline wrote: >=20 > Altho I am still some time from having my migration from the > 1998 Kayak -> 2009 Dell done and working, will it be possible > to upgrade my 32bit 7.2-R, p4 to a 64bit 8.0?=20 It is possible, but not easy. Upgrading from 7.x to 8.0 on the same architecture is not that hard IMHO. Upgrading from i386 to amd64 on the same release is doable but tricky; you need a spare root partition to install the amd64 binaries. Combining these two sounds like a big can of worms to me. My advice would be _not_ to do it. It would be far easier to just install 8.0 on the new machine and migrate y= our data and configuration files. You are going to have to build your ports from scratch anyway, because you're switching to another architecture and another major release. As far as I know, the on-disk filesystem format hasn't changed. (unless your old machine is still running UFS1. The default now is UFS2) There are a couple of differences between 7.x and 8.0; * The USB stack has been rewritten. I've had to change the following in /etc/devfs.rules: replace "add path 'usb*' mode 0660 group usb" with "add path 'usb/*' mode 0660 group usb"=20 * The name of the tty devices has changed in /etc/ttys; ttydN -> ttyuN (impacts /etc/ttys) * There have been a lot of changes in the kernel configuration. If you want= a custom kernel, start anew from the 8.0 GENERIC kernel so you don't miss anything.=20 * A lot of changes as well in /etc/src.conf (the file that defines which pa= rts of the system are built from source) * Network cards show up in dmesg and ifconfig, but not as devices in /dev (= but that could be a configuration error on my part.) All my configuration files are kept in a directory that is under revision control by git(1), so I could show you exactly what changes I've made. > would get that clear as a first step. My Intell duo-core is > very fast; would moving to the 64-bit system be a net gain or > loss [in performance]. =20 There is no clear gain or loss answer to that one. It depends on the worklo= ad you are running. On the plus size, amd64 has a lot more general registers available in the CPU than i386. On the other hand, the binaries are bigger.=20 Since you're switching to another CPU, things like cache size will have a major inpact. WRT single versus multi cores, my impression has been that the individual cores in a multi-core intel CPU are somewhat slower that the core of a similarly clocked single-core CPU. (based on some informal testing I've done with povray). If your workloads are capable of running on multiple cor= es (e.g. make jobs, different programs running concurrently) there will be a significant speed increase. You only _need_ amd64 if you are running out of address space on the i386 architecture. Having said that, I've been running amd64 on my desktop since 5.3-RELEASE more or less because I can, and it has worked fine ever since. = Be aware though that there are a few (most binary) ports that do not work on amd64. You can see that in the port Makefiles by looking for things like NOT_FOR_ARCHS and ONLY_FOR_ARCHS. HTH, Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksPjsAACgkQEnfvsMMhpyU9FgCffxYTR3f1N8BJ1gMQd/7e9A3F BEQAniXU53GOIKUMLlX75yOh+kJs9Qq4 =wOcc -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 09:45:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA79B106566C for ; Fri, 27 Nov 2009 09:45:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id C26FB8FC08 for ; Fri, 27 Nov 2009 09:45:36 +0000 (UTC) Received: from OMTA24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id A9l51d0011zF43QAE9ldoW; Fri, 27 Nov 2009 09:45:37 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA24.emeryville.ca.mail.comcast.net with comcast id A9ll1d0033S48mS8k9lllZ; Fri, 27 Nov 2009 09:45:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0A2E81E3035; Fri, 27 Nov 2009 01:45:35 -0800 (PST) Date: Fri, 27 Nov 2009 01:45:35 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091127094534.GA40406@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 7.2 serial console/getty problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 09:45:37 -0000 On Fri, Nov 27, 2009 at 02:45:39AM -0500, Charles Sprickman wrote: > Howdy, > > I'm having some issues getting a working serial console on a > 7.2-amd64 system (Dell PE 2970). Everything is running at 9600bps > to keep things simple (BIOS, loader, getty). Normal DB-9 null cable > to another host. /etc/ttys has getty on ttyd0 with the "std.9600" > gettytab entry and vt100 terminal type. > > The following works fine: > > -Console redirection via Dell's BIOS (I can enter setup, navigate > BIOS, enter RAID config, etc.) > -Boot loader (can enter boot params, select boot options, etc.) > -Boot messages (displays fine) > > However once the machine boots and getty has control, things get a > bit odd. > > I've tested this with various hosts using minicom and conserver > (conserver.com). No problems with my other hosts running older > versions of FreeBSD with the same settings (9600, 8N1, hw flow > control). > > If I just hit "enter", I get a response like this: > > noooo~:oommv64(jkoomimnnwwou})(|t}}t9- > > It does not vary - always the same string. > > However, if I hit CTRL-D, then I get a normal prompt: > > FreeBSD/amd64 (bigmail.bway.net) (ttyd0) > > login: > > If at the "login:" prompt I just hit "enter" again without typing a > username, I get the same garbled output. > > CTRL-D again gives me a proper prompt. > > Once I'm logged-in, there seem to be no issues. "vi", "top" and > other things that rely on the terminal being sane work fine. > > Any ideas? The only idea I have is one which pertains to flow control, or lack there-of. Prior to logging in, flow control isn't used. Marcel Moolenaar told me about this when I complained that occasionally on serial console, prior to logging in, that characters could be lost, even when using hardware flow control (CTS/RTS). I initially thought the problem was induced by uart(4) (which I was trying out when I noticed the problem), but it happens on sio(4) as well. Example of what I'm referring to on a (RELENG_7 box; /etc/ttys uses std.115200; serial adapters are absolute 100% correct and wired for hardware CTS/RTS), where all I'm doing is hitting Enter: FreeBSD/amd64 (horus.sc1.parodius.com) (ttyd0) login: FreeBSD/amd64 (horus.sc1.parodius.com) (ttyd0) login: ) login: (horus.sc1.parodius.com) (ttyd0) login: FreeBSD/amd64 (horus.sc1.parodius.com) (ttyd0) login: ) login: (horus.sc1.parodius.com) (ttyd0) login: Note that the way the text messes up is consistent. Again, this only happens prior to logging in. And yes, if I press EOF[*], I get a proper OS string and prompt. Maybe somehow this is what you're experiencing but manifesting itself differently (visually)? I could be totally off base but it's the only thing I can think of. I haven't tried RELENG_8 on a box with serial console, so I can't say whether or not the new tty code in RELENG_8 somehow addresses this; Ed Schouten would have to comment on that. [*] -- Be aware that as of this writing, 8.0-RELEASE (and presently RELENG_8) does have a problem with printing the EOF character (^D) once logged in. Example: log in, run cat, hit ^D, and you'll actually see Caret-D printed (vs. on previous FreeBSD releases, where ^D wouldn't be shown). This is a bug in 8.x which Ed has since fixed, but the code hasn't been MFC'd yet (but will be soon): http://koitsu.wordpress.com/2009/10/12/testing-out-freebsd-8-0-rc1/ http://koitsu.wordpress.com/2009/11/02/testing-out-freebsd-8-0-rc2/ -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 13:08:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D308106568F; Fri, 27 Nov 2009 13:08:27 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 44D158FC1A; Fri, 27 Nov 2009 13:08:27 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NE0Yk-00009a-AO; Fri, 27 Nov 2009 13:08:26 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id C5B672C4DDB6; Fri, 27 Nov 2009 22:08:25 +0900 (JST) Date: Fri, 27 Nov 2009 22:08:25 +0900 Message-ID: From: Randy Bush To: "Kevin Oberman" In-Reply-To: <20091127030601.CAB2C1CC0E@ptavv.es.net> References: <1259283983.92302.23.camel@neo.cse.buffalo.edu> <20091127030601.CAB2C1CC0E@ptavv.es.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: 8.0-RELEASE completed... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 13:08:27 -0000 yep. have upgraded to 8.0-RELEASE on a number of servers and it is very boring. this is a feature. thanks all. randy From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 15:18:46 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 483C0106566C for ; Fri, 27 Nov 2009 15:18:46 +0000 (UTC) (envelope-from pz-freebsd-stable@ziemba.us) Received: from ziemba.us (208-106-105-148.dsl.static.sonic.net [208.106.105.148]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE138FC14 for ; Fri, 27 Nov 2009 15:18:46 +0000 (UTC) Received: from hairball.ziemba.us (localhost.ziemba.us [127.0.0.1]) by hairball.ziemba.us (8.14.3/8.14.3) with ESMTP id nARExDpW078832 for ; Fri, 27 Nov 2009 06:59:13 -0800 (PST) (envelope-from pz-freebsd-stable@ziemba.us) Received: (from mailnull@localhost) by hairball.ziemba.us (8.14.3/8.14.3/Submit) id nARExCDR078831 for freebsd-stable@FreeBSD.org; Fri, 27 Nov 2009 06:59:12 -0800 (PST) (envelope-from pz-freebsd-stable@ziemba.us) X-Authentication-Warning: hairball.ziemba.us: mailnull set sender to pz-freebsd-stable@ziemba.us using -f Received: (from news@localhost) by hairball.ziemba.us (8.14.3/8.14.3/Submit) id nARExCIY078769 for treehouse-mail-freebsd-stable@hairball.treehouse.napa.ca.us; Fri, 27 Nov 2009 06:59:12 -0800 (PST) (envelope-from news) From: "G. Paul Ziemba" To: freebsd-stable@FreeBSD.org Date: Fri, 27 Nov 2009 14:59:12 +0000 (UTC) Message-id: Errors-to: "G. Paul Ziemba" Cc: Subject: 8.0: buildworld fails "/usr/src/lib/libc/stdlib/Makefile.inc" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paul+usenet@w6yx.stanford.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:18:46 -0000 I just csupped with tag=RELENG_8 but can't complete "make buildworld". I'm starting from 7.1-PRERELEASE (roughly Nov 18, 2008) Any suggestions would be appreciated! -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 7.1-PRERELEASE i386 700112" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 /usr/obj/usr/src/make.i386/make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp par-cleandir ===> share/info (cleandir) ===> lib (cleandir) ===> lib/csu/i386-elf (cleandir) rm -f crt1.o crti.o crtn.o gcrt1.o rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libc (cleandir) "/usr/src/lib/libc/stdlib/Makefile.inc", line 19: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 -- G. Paul Ziemba FreeBSD unix: 6:56AM up 1 day, 12:08, 4 users, load averages: 0.04, 0.02, 0.03 From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 15:39:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC7121065692; Fri, 27 Nov 2009 15:39:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C6DCC8FC30; Fri, 27 Nov 2009 15:39:19 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 48E0C46B06; Fri, 27 Nov 2009 10:39:19 -0500 (EST) Date: Fri, 27 Nov 2009 15:39:19 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ken Smith In-Reply-To: <1259283983.92302.23.camel@neo.cse.buffalo.edu> Message-ID: References: <1259283983.92302.23.camel@neo.cse.buffalo.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-current@freebsd.org, freebsd-stable Subject: The press release (was: Re: 8.0-RELEASE completed...) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:39:20 -0000 On Thu, 26 Nov 2009, Ken Smith wrote: > Just a quick note in case there are people here who aren't subscribed to the > freebsd-announce@ mailing list. > > We have completed the 8.0-RELEASE cycle. Details about the release are > available from the main web site, in particular the announcement itself is > available here: > > http://www.freebsd.org/releases/8.0R/announce.html > > Thanks for all the help with testing during the release process, as well as > your continued support of FreeBSD. For those wanting to do advocacy work for the release, in addition to the release announcement and highly detail release notes, there's also a press release: http://www.freebsd.org/releases/8.0R/pressrelease.html It is a bit more verbose and salesy than the announcement, but a lot shorter than the release notes. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 15:58:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85BF71065676 for ; Fri, 27 Nov 2009 15:58:43 +0000 (UTC) (envelope-from marco@goofy.tols.org) Received: from goofy.tols.org (goofy.tols.org [83.163.60.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9D08FC18 for ; Fri, 27 Nov 2009 15:58:42 +0000 (UTC) Received: from goofy.tols.org (localhost [127.0.0.1]) by goofy.tols.org (8.14.3/8.14.3) with ESMTP id nARFQQGj045062; Fri, 27 Nov 2009 15:26:26 GMT (envelope-from marco@goofy.tols.org) Received: (from marco@localhost) by goofy.tols.org (8.14.3/8.14.3/Submit) id nARFQQuZ045061; Fri, 27 Nov 2009 15:26:26 GMT (envelope-from marco) Date: Fri, 27 Nov 2009 15:26:26 +0000 From: Marco van Tol To: paul+usenet@w6yx.stanford.edu Message-ID: <20091127152626.GA44562@goofy.tols.org> Mail-Followup-To: paul+usenet@w6yx.stanford.edu, freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 8.0: buildworld fails "/usr/src/lib/libc/stdlib/Makefile.inc" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:58:43 -0000 On Fri, Nov 27, 2009 at 02:59:12PM +0000, G. Paul Ziemba wrote: > I just csupped with tag=RELENG_8 but can't complete "make buildworld". > I'm starting from 7.1-PRERELEASE (roughly Nov 18, 2008) > > Any suggestions would be appreciated! Just thinking oud loud, but I have seen this kind of thing happen as well when I didn't "make clean ; rm -rf /usr/obj" before cvsup'ing to the next major release. I build a world and kernel today of RELENG_8 today without problems. Marco -- Success is having to worry about every damn thing in the world, except money. - Johnny Cash From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 16:05:01 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F3B6106566C for ; Fri, 27 Nov 2009 16:05:01 +0000 (UTC) (envelope-from pz-freebsd-stable@ziemba.us) Received: from ziemba.us (208-106-105-148.dsl.static.sonic.net [208.106.105.148]) by mx1.freebsd.org (Postfix) with ESMTP id 65B808FC3B for ; Fri, 27 Nov 2009 16:05:01 +0000 (UTC) Received: from hairball.ziemba.us (localhost.ziemba.us [127.0.0.1]) by hairball.ziemba.us (8.14.3/8.14.3) with ESMTP id nARG51uH035349 for ; Fri, 27 Nov 2009 08:05:01 -0800 (PST) (envelope-from pz-freebsd-stable@ziemba.us) Received: (from mailnull@localhost) by hairball.ziemba.us (8.14.3/8.14.3/Submit) id nARG51w1035348 for freebsd-stable@FreeBSD.org; Fri, 27 Nov 2009 08:05:01 -0800 (PST) (envelope-from pz-freebsd-stable@ziemba.us) X-Authentication-Warning: hairball.ziemba.us: mailnull set sender to pz-freebsd-stable@ziemba.us using -f Received: (from news@localhost) by hairball.ziemba.us (8.14.3/8.14.3/Submit) id nARG5028035284 for treehouse-mail-freebsd-stable@hairball.treehouse.napa.ca.us; Fri, 27 Nov 2009 08:05:00 -0800 (PST) (envelope-from news) From: "G. Paul Ziemba" To: freebsd-stable@FreeBSD.org Date: Fri, 27 Nov 2009 16:05:00 +0000 (UTC) Message-id: References: <20091127152626.GA44562@goofy.tols.org> Errors-to: "G. Paul Ziemba" Cc: Subject: Re: 8.0: buildworld fails "/usr/src/lib/libc/stdlib/Makefile.inc" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paul+usenet@w6yx.stanford.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:05:01 -0000 marco@tols.org (Marco van Tol) writes: >On Fri, Nov 27, 2009 at 02:59:12PM +0000, G. Paul Ziemba wrote: >> I just csupped with tag=RELENG_8 but can't complete "make buildworld". >> I'm starting from 7.1-PRERELEASE (roughly Nov 18, 2008) >> >> Any suggestions would be appreciated! >Just thinking oud loud, but I have seen this kind of thing happen as well >when I didn't "make clean ; rm -rf /usr/obj" before cvsup'ing to the next >major release. Ah! That fixed it. Thanks! -- G. Paul Ziemba FreeBSD unix: 8:01AM up 1 day, 13:13, 4 users, load averages: 1.12, 0.95, 0.57 From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 16:13:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 700F3106566B; Fri, 27 Nov 2009 16:13:44 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC5A8FC15; Fri, 27 Nov 2009 16:13:44 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NE3S3-0008SZ-O3; Fri, 27 Nov 2009 17:13:43 +0100 Date: Fri, 27 Nov 2009 17:13:43 +0100 From: Kurt Jaeger To: freebsd-current@freebsd.org, freebsd-stable Message-ID: <20091127161343.GG2103@home.opsec.eu> References: <1259283983.92302.23.camel@neo.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1259283983.92302.23.camel@neo.cse.buffalo.edu> Cc: Subject: route(8) and show/sticky/... Re: 8.0-RELEASE completed... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:13:44 -0000 Hi! > Just a quick note in case there are people here who aren't subscribed to > the freebsd-announce@ mailing list. > > We have completed the 8.0-RELEASE cycle. Details about the release are > available from the main web site, in particular the announcement itself > is available here: > > http://www.freebsd.org/releases/8.0R/announce.html Thanks! One question: http://www.freebsd.org/releases/8.0R/relnotes-detailed.html says: ---------- The route(8) utility now supports show, weights, and sticky commands. For more details, see the route(8) manual page. ---------- I do not have those things in my man page or route(8) command ? -- pi@opsec.eu +49 171 3101372 11 years to go ! From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 16:21:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BA681065670 for ; Fri, 27 Nov 2009 16:21:38 +0000 (UTC) (envelope-from oliver@FreeBSD.org) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id EAF288FC0C for ; Fri, 27 Nov 2009 16:21:37 +0000 (UTC) Received: (qmail 28607 invoked by uid 89); 27 Nov 2009 16:21:35 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 27 Nov 2009 16:21:35 -0000 Date: Fri, 27 Nov 2009 17:21:35 +0100 From: Oliver Lehmann To: freebsd-stable@freebsd.org Message-Id: <20091127172135.1f241984.oliver@FreeBSD.org> In-Reply-To: <1259283983.92302.23.camel@neo.cse.buffalo.edu> References: <1259283983.92302.23.camel@neo.cse.buffalo.edu> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: 8.0-RELEASE completed... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:21:38 -0000 Hi Ken, Ken Smith wrote: > http://www.freebsd.org/releases/8.0R/announce.html Just a small typo on that page - not a big deal: >>>> The press release contains more information on this relese. ^^^^ <<<< -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 16:48:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CA36106566C for ; Fri, 27 Nov 2009 16:48:18 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 115FF8FC0C for ; Fri, 27 Nov 2009 16:48:16 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id nARGmHTt004136 for ; Fri, 27 Nov 2009 10:48:17 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Nov 27 10:48:17 2009 Message-ID: <4B100262.6000900@denninger.net> Date: Fri, 27 Nov 2009 10:46:26 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------000007000601080802040509" X-Antivirus: avast! (VPS 091127-1, 11/27/2009), Outbound message X-Antivirus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:48:18 -0000 This is a multi-part message in MIME format. --------------000007000601080802040509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is pretty serious folks - as noted below I have tried several options including limiting FIFO depth with the flags with no result. The PUC-based ports are basically useless under 8.x as a consequence. I can reproduce this lockup within 15-30 minutes every time. >Submitter-Id: current-users >Originator: Karl Denninger >Organization: Karls Sushi and Packet Smashers >Confidential: no >Synopsis: Serial I/O is terminally screwed under 8.x. >Severity: serious >Priority: high >Category: i386 >Class: sw-bug >Release: FreeBSD 8.0-STABLE i386 >Environment: System: FreeBSD FS.denninger.net 8.0-STABLE FreeBSD 8.0-STABLE #3: Fri Nov 27 08 :32:51 CST 2009 karl@FS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP i386 puc0: port 0x4060-0x407f,0x4040-0x405f m em 0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3 puc0: [FILTER] uart2: <16550 or compatible> on puc0 uart2: [FILTER] uart3: <16550 or compatible> on puc0 uart3: [FILTER] uart4: <16550 or compatible> on puc0 uart4: [FILTER] uart5: <16550 or compatible> on puc0 uart5: [FILTER] puc0@pci0:3:0:0: class=0x070006 card=0x00001415 chip=0x950a1415 rev=0x00 hdr=0x00 bar [10] = type I/O Port, range 32, base 0x4060, size 32, enabled bar [14] = type Memory, range 32, base 0x94503000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0x4040, size 32, enabled bar [1c] = type Memory, range 32, base 0x94502000, size 4096, enabled cap 01[40] = powerspec 1 supports D0 D2 D3 current D0 # # SMP -- Generic kernel configuration file for FreeBSD/i386 SMP # Use this for multi-processor machines # # $FreeBSD: src/sys/i386/conf/SMP,v 1.5.6.1 2005/09/18 03:37:58 scottl Exp $ include GENERIC ident KSD-SMP # To make an SMP kernel, the next line is needed #options SMP # Symmetric MultiProcessor Kernel # # We also need the firewall, divert, and PPS_SYNC (for the GPS) options # options IPFIREWALL options IPDIVERT options PPS_SYNC # # Rate-shaping requirements # options DUMMYNET options HZ=1000 #options SYSVSHM # # Local stuff # device rp # Comtrol Rocketport Board device sound # Generic sound card drivers #device ubsa # USB Serial Adapters #device ucom #device uftdi #device uplcom device umct device puc >Description: Serial I/O fails with a lockup after a variable amount of time. Modem-controlled ports are succeptible, especially those that require tight adherence to that capability. There is no reset possible without rebooting the machine. Attempts to "probe" the port by stopping the running process(es) and re-initializing them fail. This IDENTICAL board in the IDENTICAL machine was functioning properly under 7.x over the space of about a year under extremely heavy use. As soon as 8.x-RC2 was loaded, and subsequently with the released version (as seen above) it failed and has remained dead. The custom kernel with "PPS_SYNC" is present as one of the ports (on the motherboard) is used for a GPS clock under ntpd. This port is operating fine - it is relatively low-traffic, of course, containing only timecode. Another port used to talk to an APC UPS (again, low traffic) is also ok. All ports in use for Hylafax, however, lock up as described above. Attempting to limit FIFO depth with 0x100 or 0x200 flags on the ports has no effect. >How-To-Repeat: Put a "puc" style board in the machine, set up hylafax, send a few dozen faxes. The driver will wedge. >Fix: --------------000007000601080802040509-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 18:56:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C32C106566B for ; Fri, 27 Nov 2009 18:56:09 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id BF4C68FC19 for ; Fri, 27 Nov 2009 18:56:08 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id nARIu8Ku002435 for ; Fri, 27 Nov 2009 12:56:09 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Nov 27 12:56:09 2009 Message-ID: <4B102059.6040003@denninger.net> Date: Fri, 27 Nov 2009 12:54:17 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B100262.6000900@denninger.net> In-Reply-To: <4B100262.6000900@denninger.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------050006070207060403040001" X-Antivirus: avast! (VPS 091127-1, 11/27/2009), Outbound message X-Antivirus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 18:56:09 -0000 This is a multi-part message in MIME format. --------------050006070207060403040001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Karl Denninger wrote: > This is pretty serious folks - as noted below I have tried several > options including limiting FIFO depth with the flags with no result. > The PUC-based ports are basically useless under 8.x as a consequence. I > can reproduce this lockup within 15-30 minutes every time. > > >> Submitter-Id: current-users >> Originator: Karl Denninger >> Organization: Karls Sushi and Packet Smashers >> Confidential: no >> Synopsis: Serial I/O is terminally screwed under 8.x. >> Severity: serious >> Priority: high >> Category: i386 >> Class: sw-bug >> Release: FreeBSD 8.0-STABLE i386 >> Environment: >> > System: FreeBSD FS.denninger.net 8.0-STABLE FreeBSD 8.0-STABLE #3: Fri > Nov 27 08 > :32:51 CST 2009 karl@FS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP i386 > > puc0: port > 0x4060-0x407f,0x4040-0x405f m > em 0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3 > puc0: [FILTER] > uart2: <16550 or compatible> on puc0 > uart2: [FILTER] > uart3: <16550 or compatible> on puc0 > uart3: [FILTER] > uart4: <16550 or compatible> on puc0 > uart4: [FILTER] > uart5: <16550 or compatible> on puc0 > uart5: [FILTER] > > puc0@pci0:3:0:0: class=0x070006 card=0x00001415 chip=0x950a1415 > rev=0x00 > hdr=0x00 > bar [10] = type I/O Port, range 32, base 0x4060, size 32, enabled > bar [14] = type Memory, range 32, base 0x94503000, size 4096, enabled > bar [18] = type I/O Port, range 32, base 0x4040, size 32, enabled > bar [1c] = type Memory, range 32, base 0x94502000, size 4096, enabled > cap 01[40] = powerspec 1 supports D0 D2 D3 current D0 > > > # > # SMP -- Generic kernel configuration file for FreeBSD/i386 SMP > # Use this for multi-processor machines > # > # $FreeBSD: src/sys/i386/conf/SMP,v 1.5.6.1 2005/09/18 03:37:58 scottl Exp $ > > include GENERIC > > ident KSD-SMP > > # To make an SMP kernel, the next line is needed > #options SMP # Symmetric MultiProcessor Kernel > # > # We also need the firewall, divert, and PPS_SYNC (for the GPS) options > # > options IPFIREWALL > options IPDIVERT > options PPS_SYNC > > # > # Rate-shaping requirements > # > options DUMMYNET > options HZ=1000 > > #options SYSVSHM > > # > # Local stuff > # > device rp # Comtrol Rocketport Board > device sound # Generic sound card drivers > > #device ubsa # USB Serial Adapters > #device ucom > #device uftdi > #device uplcom > > device umct > device puc > > > >> Description: >> > Serial I/O fails with a lockup after a variable amount of time. > Modem-controlled ports are succeptible, especially those that > require tight adherence to that capability. > > There is no reset possible without rebooting the machine. Attempts > to "probe" the port by stopping the running process(es) and > re-initializing them fail. > > This IDENTICAL board in the IDENTICAL machine was functioning > properly under 7.x over the space of about a year under extremely > heavy use. As soon as 8.x-RC2 was loaded, and subsequently with the > released version (as seen above) it failed and has remained dead. > > The custom kernel with "PPS_SYNC" is present as one > of the ports (on the motherboard) is used for a GPS clock under > ntpd. > This port is operating fine - it is relatively low-traffic, of > course, containing only timecode. Another port used to talk to an > APC UPS (again, low traffic) is also ok. > > All ports in use for Hylafax, however, lock up as described above. > > Attempting to limit FIFO depth with 0x100 or 0x200 flags on the > ports has no effect. > > >> How-To-Repeat: >> > Put a "puc" style board in the machine, set up hylafax, send a few > dozen faxes. The driver will wedge. > > >> Fix: >> > > lines)> > For what its worth, USB-based serial adapters also fail in the same way, but faster (they have NEVER been reliable in this regard, and this hasn't improved) -- Karl --------------050006070207060403040001-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 19:03:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D18FF1065670 for ; Fri, 27 Nov 2009 19:03:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id B8A828FC22 for ; Fri, 27 Nov 2009 19:03:20 +0000 (UTC) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id AJhp1d0080QkzPwA9K3Mar; Fri, 27 Nov 2009 19:03:21 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id AK3L1d0043S48mS8NK3LYE; Fri, 27 Nov 2009 19:03:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7465A1E301B; Fri, 27 Nov 2009 11:03:19 -0800 (PST) Date: Fri, 27 Nov 2009 11:03:19 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091127190319.GA12437@icarus.home.lan> References: <4B100262.6000900@denninger.net> <4B102059.6040003@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B102059.6040003@denninger.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 19:03:20 -0000 On Fri, Nov 27, 2009 at 12:54:17PM -0600, Karl Denninger wrote: > For what its worth, USB-based serial adapters also fail in the same way, > but faster (they have NEVER been reliable in this regard, and this > hasn't improved) There must be a regression of some kind, given that some FreeBSD developers have stated in the past that FTDI-based USB serial adapters work great: http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041615.html Original thread: http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041610.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 19:46:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47B51106568B for ; Fri, 27 Nov 2009 19:46:57 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 00E568FC0C for ; Fri, 27 Nov 2009 19:46:56 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id nARJkv1f004227 for ; Fri, 27 Nov 2009 13:46:57 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Nov 27 13:46:57 2009 Message-ID: <4B102C41.6040205@denninger.net> Date: Fri, 27 Nov 2009 13:45:05 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jeremy Chadwick References: <4B100262.6000900@denninger.net> <4B102059.6040003@denninger.net> <20091127190319.GA12437@icarus.home.lan> In-Reply-To: <20091127190319.GA12437@icarus.home.lan> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------050507040909060309060806" X-Antivirus: avast! (VPS 091127-1, 11/27/2009), Outbound message X-Antivirus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 19:46:57 -0000 This is a multi-part message in MIME format. --------------050507040909060309060806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeremy Chadwick wrote: > On Fri, Nov 27, 2009 at 12:54:17PM -0600, Karl Denninger wrote: > >> For what its worth, USB-based serial adapters also fail in the same way, >> but faster (they have NEVER been reliable in this regard, and this >> hasn't improved) >> > > There must be a regression of some kind, given that some FreeBSD > developers have stated in the past that FTDI-based USB serial adapters > work great: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041615.html > > Original thread: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041610.html > I don't know where "works great" has come from. Certainly not my experience in "heavy" use. For non-modem-control heavy use, it works ok. I use an 8-port fanout on 7.x to drive process control and it's stable. However, for heavy modem use (e.g. Hylafax) it has NEVER been stable - although in 8.x it won't even manage to send ONE 10-page fax most of the time, where under 7.x it would randomly fail in that use. Then again the puc() driver based serial I/O was completely stable under 7.x and now, with the "new architecture" it will get one or two jobs through it before it blows up. -- Karl --------------050507040909060309060806-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 20:22:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3099B106566C; Fri, 27 Nov 2009 20:22:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id E332D8FC0C; Fri, 27 Nov 2009 20:22:02 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id CB2086D41B; Fri, 27 Nov 2009 20:22:01 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7FA20844F1; Fri, 27 Nov 2009 21:22:01 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Roland Smith References: <1259283983.92302.23.camel@neo.cse.buffalo.edu> <20091127030601.CAB2C1CC0E@ptavv.es.net> <20091127055757.GA75657@thought.org> <20091127083304.GA8618@slackbox.xs4all.nl> Date: Fri, 27 Nov 2009 21:22:01 +0100 In-Reply-To: <20091127083304.GA8618@slackbox.xs4all.nl> (Roland Smith's message of "Fri, 27 Nov 2009 09:33:04 +0100") Message-ID: <86hbsflnva.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Gary Kline , freebsd-stable , freebsd-current@freebsd.org Subject: Re: 8.0-RELEASE completed... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 20:22:03 -0000 Roland Smith writes: > It is possible, but not easy. Upgrading from 7.x to 8.0 on the same > architecture is not that hard IMHO. Upgrading from i386 to amd64 on the s= ame > release is doable but tricky; you need a spare root partition to install = the > amd64 binaries. Not at all, just make a backup of /etc, extract the amd64 dist on top of your existing system, then restore whichever parts of /etc got clobbered. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 20:51:28 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19EBC106566B for ; Fri, 27 Nov 2009 20:51:28 +0000 (UTC) (envelope-from troy@twisted.net) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mx1.freebsd.org (Postfix) with ESMTP id DAC358FC15 for ; Fri, 27 Nov 2009 20:51:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 4DDBEFEE3EE for ; Fri, 27 Nov 2009 14:33:46 -0600 (CST) X-Virus-Scanned: amavisd-new at example.com Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVdrZ-R5ZUVk for ; Fri, 27 Nov 2009 14:33:38 -0600 (CST) Received: by oz.twisted.net (Postfix, from userid 1001) id 9B20DFEE438; Fri, 27 Nov 2009 14:33:38 -0600 (CST) Date: Fri, 27 Nov 2009 14:33:38 -0600 From: Troy To: freebsd-stable@FreeBSD.org Message-ID: <20091127203338.GA70392@twisted.net> Mail-Followup-To: freebsd-stable@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: 8.0 installworld fails in /usr/src/lib/csu/i386-elf cc: not found X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: troy@twisted.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 20:51:28 -0000 I was just upgrading from 7.2 to 8.0 using RELENG_8 and everything went well until I did the installworld. Below is the error. -Troy -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info (install) ===> lib (install) ===> lib/csu/i386-elf (install) cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c crt1.c cc: not found *** Error code 127 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Exit 1 From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 21:06:57 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 156AB106566B for ; Fri, 27 Nov 2009 21:06:57 +0000 (UTC) (envelope-from troy@twisted.net) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mx1.freebsd.org (Postfix) with ESMTP id D1E7C8FC0A for ; Fri, 27 Nov 2009 21:06:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 5508CFEE3EE for ; Fri, 27 Nov 2009 15:07:13 -0600 (CST) X-Virus-Scanned: amavisd-new at example.com Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFO1F7GIDUzo for ; Fri, 27 Nov 2009 15:07:05 -0600 (CST) Received: by oz.twisted.net (Postfix, from userid 1001) id C8861FEE43A; Fri, 27 Nov 2009 15:07:05 -0600 (CST) Date: Fri, 27 Nov 2009 15:07:05 -0600 From: Troy To: freebsd-stable@FreeBSD.org Message-ID: <20091127210705.GA72043@twisted.net> Mail-Followup-To: freebsd-stable@FreeBSD.org References: <20091127203338.GA70392@twisted.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091127203338.GA70392@twisted.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: 8.0 installworld fails in /usr/src/lib/csu/i386-elf cc: not found X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: troy@twisted.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 21:06:57 -0000 cc is installed and I can execute it. I don't have any unique cc variables being set in make.conf either. -Troy On Fri, Nov 27, 2009 at 02:33:38PM -0600, Troy wrote: > I was just upgrading from 7.2 to 8.0 using RELENG_8 and everything went > well until I did the installworld. Below is the error. > > -Troy > > > > > -------------------------------------------------------------- > >>> Installing everything > -------------------------------------------------------------- > cd /usr/src; make -f Makefile.inc1 install > ===> share/info (install) > ===> lib (install) > ===> lib/csu/i386-elf (install) > cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common > -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align > -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wno-pointer-sign -c crt1.c > cc: not found > *** Error code 127 > > Stop in /usr/src/lib/csu/i386-elf. > *** Error code 1 > > Stop in /usr/src/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > Exit 1 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 21:32:58 2009 Return-Path: Delivered-To: stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 854FB106568D; Fri, 27 Nov 2009 21:32:58 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFB88FC12; Fri, 27 Nov 2009 21:32:58 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.167.197]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id nARLHVST062941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 13:17:32 -0800 (PST) (envelope-from sobomax@sippysoft.com) Message-ID: <4B1041EB.9020109@sippysoft.com> Date: Fri, 27 Nov 2009 13:17:31 -0800 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , stable@FreeBSD.ORG Subject: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 21:32:58 -0000 Hi, I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Here is my limits: Resource limits (current): cputime infinity secs filesize infinity kB datasize 2097152 kB stacksize 65536 kB coredumpsize infinity kB memoryuse infinity kB memorylocked infinity kB maxprocesses 5547 openfiles 20000 sbsize infinity bytes vmemoryuse infinity kB Running ktrace I see: 9154 java CALL mmap(0,0x44000000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,0xffffffff,0,0) 9154 java RET mmap -1 errno 12 Cannot allocate memory 9154 java CALL write(0x1,0xbf9fe378,0x2b) 9154 java GIO fd 1 wrote 43 bytes "Error occurred during initialization of VM I made a small program that uses malloc(3) to allocate the same amount of memory, and that works nicely, ktrace reveals why: 10108 a.out CALL mmap(0,0x44000000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0) 10108 a.out RET mmap -1 errno 12 Cannot allocate memory 10108 a.out CALL break(0x4c100000) 10108 a.out RET break 0 So the question is: why does mmap() fails while essentially the same sbrk() request succeeds? This is really bad since, while native FreeBSD programs can work around this by using malloc(3), Linux programs and software that knows nothing about intricate details of the FreeBSD VM (i.e. Java) will fail miserably. I tried increasing vm.max_proc_mmap to 2147483647 from default 49344, but it did not do any good. mmap() still fails with the request of this size. I have seen several threads on the issue over the years, but still no resolution. It seems that only plausible solution is to limit heap size in java, which may not work for all cases. Funny thing is that the first sentence of the sbrk(2) manual page says: The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. Yet, "legacy interfaces" seems to do much better job than "modern virtual memory management interfaces"! -Maxim From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 21:42:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 294F1106566C for ; Fri, 27 Nov 2009 21:42:59 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id C77338FC12 for ; Fri, 27 Nov 2009 21:42:58 +0000 (UTC) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA11.westchester.pa.mail.comcast.net with comcast id AMXY1d00J16LCl05BMiySb; Fri, 27 Nov 2009 21:42:58 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA06.westchester.pa.mail.comcast.net with comcast id AMix1d00M3S48mS3SMiy8Z; Fri, 27 Nov 2009 21:42:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 91EFE1E301B; Fri, 27 Nov 2009 13:42:56 -0800 (PST) Date: Fri, 27 Nov 2009 13:42:56 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20091127214256.GB15526@icarus.home.lan> References: <20091127203338.GA70392@twisted.net> <20091127210705.GA72043@twisted.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091127210705.GA72043@twisted.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0 installworld fails in /usr/src/lib/csu/i386-elf cc: not found X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 21:42:59 -0000 On Fri, Nov 27, 2009 at 03:07:05PM -0600, Troy wrote: > cc is installed and I can execute it. I don't have any unique cc > variables being set in make.conf either. Shot in the dark: are you using the -j argument during "make installworld" (not buildworld)? If so, don't do that. Otherwise, try moving make.conf aside and see if things improve. One thing at a time... :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 27 21:55:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C5CE106568D; Fri, 27 Nov 2009 21:55:37 +0000 (UTC) (envelope-from kline@thought.org) Received: from aristotle.thought.org (aristotle.thought.org [209.180.213.210]) by mx1.freebsd.org (Postfix) with ESMTP id 05E2D8FC08; Fri, 27 Nov 2009 21:55:36 +0000 (UTC) Received: from thought.org (tao.thought.org [10.47.0.250]) (authenticated bits=0) by aristotle.thought.org (8.14.2/8.14.2) with ESMTP id nARLt47e053820; Fri, 27 Nov 2009 13:55:05 -0800 (PST) (envelope-from kline@thought.org) Received: by thought.org (nbSMTP-1.00) for uid 1002 kline@thought.org; Fri, 27 Nov 2009 13:55:30 -0800 (PST) Date: Fri, 27 Nov 2009 13:55:29 -0800 From: Gary Kline To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20091127215529.GA78724@thought.org> References: <1259283983.92302.23.camel@neo.cse.buffalo.edu> <20091127030601.CAB2C1CC0E@ptavv.es.net> <20091127055757.GA75657@thought.org> <20091127083304.GA8618@slackbox.xs4all.nl> <86hbsflnva.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86hbsflnva.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: With 23 years of service to the Unix community. X-Spam-Status: No, score=-4.4 required=3.6 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on aristotle.thought.org Cc: Roland Smith , freebsd-current@freebsd.org, freebsd-stable Subject: Re: 8.0-RELEASE completed... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 21:55:37 -0000 On Fri, Nov 27, 2009 at 09:22:01PM +0100, Dag-Erling Sm?rgrav wrote: > Roland Smith writes: > > It is possible, but not easy. Upgrading from 7.x to 8.0 on the same > > architecture is not that hard IMHO. Upgrading from i386 to amd64 on the same > > release is doable but tricky; you need a spare root partition to install the > > amd64 binaries. > > Not at all, just make a backup of /etc, extract the amd64 dist on top of > your existing system, then restore whichever parts of /etc got clobbered. > > DES > -- > Dag-Erling Smørgrav - des@des.no Thanks, gentlemen. Mostly, my post was just a pondering; wondering if it might be better to re-do stuff now, But then my new server still isn't finished and probably won't be until next week. So best to stick with what I'm familar with. gary -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 7.31a release of Jottings: http://jottings.thought.org/index.php From owner-freebsd-stable@FreeBSD.ORG Sat Nov 28 02:47:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBEB01065672 for ; Sat, 28 Nov 2009 02:47:05 +0000 (UTC) (envelope-from fbsdq@peterk.org) Received: from poshta.pknet.net (poshta.pknet.net [216.241.167.213]) by mx1.freebsd.org (Postfix) with SMTP id 831188FC16 for ; Sat, 28 Nov 2009 02:47:05 +0000 (UTC) Received: (qmail 53958 invoked from network); 28 Nov 2009 02:20:23 -0000 Received: from poshta.pknet.net (HELO pop.pknet.net) (216.241.167.213) by poshta.pknet.net with SMTP; 28 Nov 2009 02:20:23 -0000 Received: from 216.241.167.212 (SquirrelMail authenticated user fbsdq@peterk.org) by webmail.pknet.net with HTTP; Fri, 27 Nov 2009 19:20:23 -0700 (MST) Message-ID: <352272328d0a303111e957807e1cb165.squirrel@webmail.pknet.net> Date: Fri, 27 Nov 2009 19:20:23 -0700 (MST) From: "Peter" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: stable/8/UPDATING - no mention of 8.0 release X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 02:47:05 -0000 iH, Been updating my src via svn and following stable/8. Looking at the UPDATING file, it does not mention '8.0-RELEASE' Did it just not make it in there yet? http://svn.freebsd.org/viewvc/base/stable/8/UPDATING?view=markup vs. http://svn.freebsd.org/viewvc/base/release/8.0.0/UPDATING?view=markup It just confused me for awhile after I did a 'svn up' and did not see the release notes... [for the 7.X series, both stable/ and release/ mention the release in UPDATING] ]Peter[ From owner-freebsd-stable@FreeBSD.ORG Sat Nov 28 03:09:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4C55106566C for ; Sat, 28 Nov 2009 03:09:49 +0000 (UTC) (envelope-from troy@twisted.net) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mx1.freebsd.org (Postfix) with ESMTP id 7EBC48FC0C for ; Sat, 28 Nov 2009 03:09:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 888D5FEE445 for ; Fri, 27 Nov 2009 21:10:07 -0600 (CST) X-Virus-Scanned: amavisd-new at example.com Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGBMm-8tMd5c for ; Fri, 27 Nov 2009 21:10:00 -0600 (CST) Received: from [172.16.0.5] (sindrome.twisted.net [172.16.0.5]) by oz.twisted.net (Postfix) with ESMTP id EEB64FEE3EE for ; Fri, 27 Nov 2009 21:09:59 -0600 (CST) Message-ID: <4B109474.6050405@twisted.net> Date: Fri, 27 Nov 2009 21:09:40 -0600 From: Troy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20091127203338.GA70392@twisted.net> <20091127210705.GA72043@twisted.net> <20091127214256.GB15526@icarus.home.lan> In-Reply-To: <20091127214256.GB15526@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 8.0 installworld fails in /usr/src/lib/csu/i386-elf cc: not found X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: troy@twisted.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 03:09:49 -0000 Tried to move make.conf aside and it did not help. I am not using -j in the installworld command. Any other thoughts? I'm in a bind with my upgrade without being able to do 'make installworld' On 11/27/2009 3:42 PM, Jeremy Chadwick wrote: > On Fri, Nov 27, 2009 at 03:07:05PM -0600, Troy wrote: > >> cc is installed and I can execute it. I don't have any unique cc >> variables being set in make.conf either. >> > Shot in the dark: are you using the -j argument during "make > installworld" (not buildworld)? If so, don't do that. > > Otherwise, try moving make.conf aside and see if things improve. One > thing at a time... :-) > > From owner-freebsd-stable@FreeBSD.ORG Sat Nov 28 07:24:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 889A71065672 for ; Sat, 28 Nov 2009 07:24:40 +0000 (UTC) (envelope-from t_uemura@macome.co.jp) Received: from smtp12.dti.ne.jp (smtp12.dti.ne.jp [202.216.231.187]) by mx1.freebsd.org (Postfix) with ESMTP id AEE288FC0C for ; Sat, 28 Nov 2009 07:24:39 +0000 (UTC) Received: from towerrecords.dyndns.org (221x254x158x92.ap221.ftth.ucom.ne.jp [221.254.158.92]) by smtp12.dti.ne.jp (3.11s) with ESMTP AUTH id nAS7BV1T002764 for ; Sat, 28 Nov 2009 16:11:31 +0900 (JST) Received: by towerrecords.dyndns.org (Postfix, from userid 58) id 588454104; Sat, 28 Nov 2009 16:11:31 +0900 (JST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on towerrecords.dyndns.org Received: from [127.0.0.1] (towerrecords.shiba.local [10.141.30.1]) by towerrecords.dyndns.org (Postfix) with ESMTP id 25B1340B2 for ; Sat, 28 Nov 2009 16:11:27 +0900 (JST) From: UEMURA Tetsuya To: freebsd-stable@freebsd.org Sender: t_uemura@macome.co.jp MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_4B10C96F00000000DA8D_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] Message-Id: <20091128071127.25B1340B2@towerrecords.dyndns.org> Date: Sat, 28 Nov 2009 16:11:27 +0900 (JST) Subject: uftdi on ehci problem. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 07:24:40 -0000 --------_4B10C96F00000000DA8D_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi list. I have several sensor boards connected to PC via UART, actually an FTDI FT4232H quad port USB 2.0 to UART bridge in-between. With sensor board A: baud: 115200 bps, actual transfer: 320 Bps, there is no problem whether or not ehci high speed mode is enabled. With sensor board B: baud: 115200 bps, actual transfer: 6400 Bps, there is still no problem when high speed mode is disabled. However when high speed mode is enabled, a program waits read() to complete for a long time or even forever. Tried using a USB 2.0 hub and no luck. With hw.usb.debug and hw.usb.ehci.debug tunables both set to 1 and I got many USB_ERR_STALLED errors. The machine runs yesterday's 8.0-STABLE amd64. Is there a way to fix/diagnose the problem? Thanks. -- UEMURA Tetsuya --------_4B10C96F00000000DA8D_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtU1RBQkxFICMwOiBTYXQgTm92IDI4IDEyOjQy OjUyIEpTVCAyMDA5CiAgICByb290QGR4NzUwMC5UZXNsYS5sb2NhbDovdXNyL29iai91c3Ivc3Jj L3N5cy9EWDc1MDAgYW1kNjQKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBI eiBxdWFsaXR5IDAKQ1BVOiBQZW50aXVtKFIpIER1YWwtQ29yZSAgQ1BVICAgICAgRTUyMDAgIEAg Mi41MEdIeiAoMjUwMC4xMC1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50 ZWwiICBJZCA9IDB4MTA2N2EgIFN0ZXBwaW5nID0gMTAKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQ VSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENN T1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRN LFBCRT4KICBGZWF0dXJlczI9MHg0MDBlMzlkPFNTRTMsRFRFUzY0LE1PTixEU19DUEwsRVNULFRN MixTU1NFMyxDWDE2LHhUUFIsUERDTSxYU0FWRT4KICBBTUQgRmVhdHVyZXM9MHgyMDEwMDgwMDxT WVNDQUxMLE5YLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAgVFNDOiBQLXN0YXRlIGlu dmFyaWFudApyZWFsIG1lbW9yeSAgPSAxMDczNzQxODI0ICgxMDI0IE1CKQphdmFpbCBtZW1vcnkg PSA5OTIwNzU3NzYgKDk0NiBNQikKQUNQSSBBUElDIFRhYmxlOiA8SFBRT0VNIFNMSUMtQlBDPgpG cmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMKRnJlZUJT RC9TTVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShzKQogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAK IGNwdTEgKEFQKTogQVBJQyBJRDogIDEKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBv biBtb3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYWNwaTA6IDxIUFFPRU0gU0xJQy1CUEM+IG9u IG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQp CmFjcGkwOiByZXNlcnZhdGlvbiBvZiBmZmMwMDAwMCwgMzAwMDAwICgzKSBmYWlsZWQKYWNwaTA6 IHJlc2VydmF0aW9uIG9mIGZlZTAwMDAwLCAxMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0 aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwg M2RkMDAwMDAgKDMpIGZhaWxlZApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3 OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1 NDVNSHo+IHBvcnQgMHg4MDgtMHg4MGIgb24gYWNwaTAKYWNwaV9ocGV0MDogPEhpZ2ggUHJlY2lz aW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTAKVGlt ZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDkwMApwY2liMDog PEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIwCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBw b3J0IDB4YzAwMC0weGMwMDcgbWVtIDB4ZmU0MDAwMDAtMHhmZTdmZmZmZiwweGUwMDAwMDAwLTB4 ZWZmZmZmZmYgaXJxIDE2IGF0IGRldmljZSAyLjAgb24gcGNpMAp2Z2FwY2kxOiA8VkdBLWNvbXBh dGlibGUgZGlzcGxheT4gbWVtIDB4ZmVhMDAwMDAtMHhmZWFmZmZmZiBhdCBkZXZpY2UgMi4xIG9u IHBjaTAKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uIDYuOS4xND4g cG9ydCAweGMwODAtMHhjMDlmIG1lbSAweGZlYmMwMDAwLTB4ZmViZGZmZmYsMHhmZWJmZDAwMC0w eGZlYmZkZmZmIGlycSAyMCBhdCBkZXZpY2UgMjUuMCBvbiBwY2kwCmVtMDogVXNpbmcgTVNJIGlu dGVycnVwdAplbTA6IFtGSUxURVJdCmVtMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjM6N2Q6Yzc6 ODg6NGYKdWhjaTA6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGM0MDAt MHhjNDFmIGlycSAxNiBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVoY2kwOiBbSVRIUkVBRF0KdWhj aTA6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czA6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxl cj4gb24gdWhjaTAKdWhjaTE6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAw eGM0ODAtMHhjNDlmIGlycSAyMSBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCnVoY2kxOiBbSVRIUkVB RF0KdWhjaTE6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czE6IDxVSENJIChnZW5lcmljKSBVU0IgY29u dHJvbGxlcj4gb24gdWhjaTEKdWhjaTI6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g cG9ydCAweGM4MDAtMHhjODFmIGlycSAyMCBhdCBkZXZpY2UgMjYuMiBvbiBwY2kwCnVoY2kyOiBb SVRIUkVBRF0KdWhjaTI6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czI6IDxVSENJIChnZW5lcmljKSBV U0IgY29udHJvbGxlcj4gb24gdWhjaTIKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNl IDI2LjcgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBp cnEgMTcgYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MQpwY2liMjogPFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kyCnBj aTM6IDxQQ0kgYnVzPiBvbiBwY2liMgpwdWMwOiA8TW94YSBUZWNobm9sb2dpZXMsIENQLTE2OEVM L1BDSWU+IHBvcnQgMHhlYzAwLTB4ZWMxZiwweGU4ODAtMHhlOGJmLDB4ZTgwMC0weGU4MGYgaXJx IDE2IGF0IGRldmljZSAwLjAgb24gcGNpMwpwdWMwOiBbRklMVEVSXQp1YXJ0MjogPDE2OTUwIG9y IGNvbXBhdGlibGU+IG9uIHB1YzAKdWFydDI6IFtGSUxURVJdCnVhcnQzOiA8MTY5NTAgb3IgY29t cGF0aWJsZT4gb24gcHVjMAp1YXJ0MzogW0ZJTFRFUl0KdWFydDQ6IDwxNjk1MCBvciBjb21wYXRp YmxlPiBvbiBwdWMwCnVhcnQ0OiBbRklMVEVSXQp1YXJ0NTogPDE2OTUwIG9yIGNvbXBhdGlibGU+ IG9uIHB1YzAKdWFydDU6IFtGSUxURVJdCnVhcnQ2OiA8MTY5NTAgb3IgY29tcGF0aWJsZT4gb24g cHVjMAp1YXJ0NjogW0ZJTFRFUl0KdWFydDc6IDwxNjk1MCBvciBjb21wYXRpYmxlPiBvbiBwdWMw CnVhcnQ3OiBbRklMVEVSXQp1YXJ0ODogPDE2OTUwIG9yIGNvbXBhdGlibGU+IG9uIHB1YzAKdWFy dDg6IFtGSUxURVJdCnVhcnQ5OiA8MTY5NTAgb3IgY29tcGF0aWJsZT4gb24gcHVjMAp1YXJ0OTog W0ZJTFRFUl0KdWhjaTM6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGM4 ODAtMHhjODlmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVoY2kzOiBbSVRIUkVBRF0K dWhjaTM6IExlZ1N1cCA9IDB4M2YwMAp1c2J1czM6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJv bGxlcj4gb24gdWhjaTMKdWhjaTQ6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9y dCAweGNjMDAtMHhjYzFmIGlycSAyMCBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2k0OiBbSVRI UkVBRF0KdWhjaTQ6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czQ6IDxVSENJIChnZW5lcmljKSBVU0Ig Y29udHJvbGxlcj4gb24gdWhjaTQKdWhjaTU6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxl cj4gcG9ydCAweGQwMDAtMHhkMDFmIGlycSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2k1 OiBbSVRIUkVBRF0KdWhjaTU6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czU6IDxVSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTUKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2 aWNlIDI5LjcgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCmlz YWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBi dXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0gxMCBTQVRBMzAwIGNvbnRyb2xsZXI+IHBv cnQgMHhkODgwLTB4ZDg4NywweGQ4MDAtMHhkODAzLDB4ZDQ4MC0weGQ0ODcsMHhkNDAwLTB4ZDQw MywweGQwODAtMHhkMDlmIG1lbSAweGZlYmZmMDAwLTB4ZmViZmY3ZmYgaXJxIDE5IGF0IGRldmlj ZSAzMS4yIG9uIHBjaTAKYXRhcGNpMDogW0lUSFJFQURdCmF0YXBjaTA6IEFIQ0kgY2FsbGVkIGZy b20gdmVuZG9yIHNwZWNpZmljIGRyaXZlcgphdGFwY2kwOiBBSENJIHYxLjIwIGNvbnRyb2xsZXIg d2l0aCA2IDNHYnBzIHBvcnRzLCBQTSBub3Qgc3VwcG9ydGVkCmF0YTI6IDxBVEEgY2hhbm5lbCAw PiBvbiBhdGFwY2kwCmF0YTI6IFtJVEhSRUFEXQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRh cGNpMAphdGEzOiBbSVRIUkVBRF0KYXRhNDogPEFUQSBjaGFubmVsIDI+IG9uIGF0YXBjaTAKYXRh NDogW0lUSFJFQURdCmF0YTU6IDxBVEEgY2hhbm5lbCAzPiBvbiBhdGFwY2kwCmF0YTU6IFtJVEhS RUFEXQphdGE2OiA8QVRBIGNoYW5uZWwgND4gb24gYXRhcGNpMAphdGE2OiBbSVRIUkVBRF0KYXRh NzogPEFUQSBjaGFubmVsIDU+IG9uIGF0YXBjaTAKYXRhNzogW0lUSFJFQURdCnBjaTA6IDxzZXJp YWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKYWNwaV9i dXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9j az4gcG9ydCAweDcwLTB4NzEgaXJxIDggb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3Bp MAplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwCnA0 dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwCmNwdTE6IDxBQ1BJ IENQVT4gb24gYWNwaTAKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJv bD4gb24gY3B1MQpwNHRjYzE6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1 MQpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8 MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+ IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKYXRrYmRj MDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNh MAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAph dGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdClRpbWVjb3VudGVycyB0aWNr IGV2ZXJ5IDEuMDAwIG1zZWMKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1 czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMjogMTJNYnBzIEZ1bGwgU3BlZWQg VVNCIHYxLjAKdXNidXMzOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czQ6IDEyTWJw cyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAK YWQwOiA3NjMxOU1CIDxTZWFnYXRlIFNUMzgwODE1QVMgMy5DSEg+IGF0IGF0YTItbWFzdGVyIFNB VEEzMDAKYWNkMDogRFZEUk9NIDxocCBEVkQgRCBESDE2RDVTL1ZIRDc+IGF0IGF0YTYtbWFzdGVy IFNBVEExNTAKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNi dWdlbnUwcy4xMTogPEludGVsPiBhdCB1c2J1czAKdWh1YjA6IAo8SW50ZWwgVUhDSSByb290IEhV QiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1aHViMTogPElu dGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2J1czAKdWdlbjIuMTogPEludGVsPiBhdCB1c2J1czJ1Z2VuMy4xOiA8SW50ZWw+IGF0IHVzYnVz MwoKdWh1YjI6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXMyCnVodWIzOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMwp1Z2VuNC4xOiA8SW50ZWw+IGF0IHVz YnVzNHVnZW41LjE6IDxJbnRlbD4gYXQgdXNidXM1Cgp1aHViNDogPEludGVsIFVIQ0kgcm9vdCBI VUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czQKdWh1YjU6IDxJ bnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXM1CkdFT006IGFkMHMxOiBnZW9tZXRyeSBkb2VzIG5vdCBtYXRjaCBsYWJlbCAoMjU1aCw2 M3MgIT0gMTZoLDYzcykuCkdFT006IGxhYmVsL2FkMHMxOiBnZW9tZXRyeSBkb2VzIG5vdCBtYXRj aCBsYWJlbCAoMjU1aCw2M3MgIT0gMTZoLDYzcykuCkdFT01fSk9VUk5BTDogSm91cm5hbCAxNTk2 OTA0OTM3OiBsYWJlbC9hZDBzMWEgY29udGFpbnMgZGF0YS4KR0VPTV9KT1VSTkFMOiBKb3VybmFs IDE1OTY5MDQ5Mzc6IGxhYmVsL2FkMHMxYSBjb250YWlucyBqb3VybmFsLgpHRU9NX0pPVVJOQUw6 IEpvdXJuYWwgbGFiZWwvYWQwczFhIGNsZWFuLgpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1 czUgdXNidXM0IHVzYnVzMyB1c2J1czIgdXNidXMxIHVzYnVzMAp1aHViMDogMiBwb3J0cyB3aXRo IDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjQ6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI1OiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuNC4yOiA8dmVuZG9yIDB4MDU1Nz4gYXQg dXNidXM0CnVodWI2OiA8dmVuZG9yIDB4MDU1NyBwcm9kdWN0IDB4NzAwMCwgY2xhc3MgOS8wLCBy ZXYgMS4xMC8xLjAwLCBhZGRyIDI+IG9uIHVzYnVzNApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1 c2J1czQKdWh1YjY6IDQgcG9ydHMgd2l0aCA0IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3Qg bW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNAp1Z2VuNC4zOiA8Q0hFU0VOPiBhdCB1c2J1czQKdWti ZDA6IDxDSEVTRU4gVVNCIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzEuMTAsIGFkZHIg Mz4gb24gdXNidXM0CmtiZDIgYXQgdWtiZDAKdWhpZDA6IDxDSEVTRU4gVVNCIEtleWJvYXJkLCBj bGFzcyAwLzAsIHJldiAxLjEwLzEuMTAsIGFkZHIgMz4gb24gdXNidXM0ClJvb3QgbW91bnQgd2Fp dGluZyBmb3I6IHVzYnVzNAp1Z2VuNC40OiA8dmVuZG9yIDB4MDQyND4gYXQgdXNidXM0CnVodWI3 OiA8dmVuZG9yIDB4MDQyNCBwcm9kdWN0IDB4MjUxNCwgY2xhc3MgOS8wLCByZXYgMi4wMC84MC5h MCwgYWRkciA0PiBvbiB1c2J1czQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM0CnVodWI3 OiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuNC41OiA8RlREST4g YXQgdXNidXM0CnVmdGRpMDogPFF1YWQgUlMyMzItSFM+IG9uIHVzYnVzNAp1ZnRkaTE6IDxRdWFk IFJTMjMyLUhTPiBvbiB1c2J1czQKdWZ0ZGkyOiA8UXVhZCBSUzIzMi1IUz4gb24gdXNidXM0CnVm dGRpMzogPFF1YWQgUlMyMzItSFM+IG9uIHVzYnVzNApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1 c2J1czQKdWdlbjQuNjogPEZUREk+IGF0IHVzYnVzNAp1ZnRkaTQ6IDxRdWFkIFJTMjMyLUhTPiBv biB1c2J1czQKdWZ0ZGk1OiA8UXVhZCBSUzIzMi1IUz4gb24gdXNidXM0CnVmdGRpNjogPFF1YWQg UlMyMzItSFM+IG9uIHVzYnVzNAp1ZnRkaTc6IDxRdWFkIFJTMjMyLUhTPiBvbiB1c2J1czQKUm9v dCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM0CnVnZW40Ljc6IDxGVERJPiBhdCB1c2J1czQKdWZ0 ZGk4OiA8UXVhZCBSUzIzMi1IUz4gb24gdXNidXM0CnVmdGRpOTogPFF1YWQgUlMyMzItSFM+IG9u IHVzYnVzNAp1ZnRkaTEwOiA8UXVhZCBSUzIzMi1IUz4gb24gdXNidXM0CnVmdGRpMTE6IDxRdWFk IFJTMjMyLUhTPiBvbiB1c2J1czQKdWdlbjQuODogPEZUREk+IGF0IHVzYnVzNAp1ZnRkaTEyOiA8 UXVhZCBSUzIzMi1IUz4gb24gdXNidXM0CnVmdGRpMTM6IDxRdWFkIFJTMjMyLUhTPiBvbiB1c2J1 czQKdWZ0ZGkxNDogPFF1YWQgUlMyMzItSFM+IG9uIHVzYnVzNAp1ZnRkaTE1OiA8UXVhZCBSUzIz Mi1IUz4gb24gdXNidXM0ClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvbGFiZWwv YWQwczFhLmpvdXJuYWwKZWhjaTA6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+ IG1lbSAweGZlYmZlYzAwLTB4ZmViZmVmZmYgaXJxIDE4IGF0IGRldmljZSAyNi43IG9uIHBjaTAK ZWhjaTA6IFtJVEhSRUFEXQp1c2J1czY6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXM2OiA8RUhDSSAo Z2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMAp1c2J1czY6IDQ4ME1icHMgSGln aCBTcGVlZCBVU0IgdjIuMAplaGNpMTogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxl cj4gbWVtIDB4ZmViZmY4MDAtMHhmZWJmZmJmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNp MAplaGNpMTogW0lUSFJFQURdCnVzYnVzNzogRUhDSSB2ZXJzaW9uIDEuMAp1Z2VuNi4xOiA8SW50 ZWw+IGF0IHVzYnVzNgp1aHViODogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2 IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czYKdXNidXM3OiA8RUhDSSAoZ2VuZXJpYykgVVNC IDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMQp1c2J1czc6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0Ig djIuMAp1Z2VuNy4xOiA8SW50ZWw+IGF0IHVzYnVzNwp1aHViOTogPEludGVsIEVIQ0kgcm9vdCBI VUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czcKdWdlbjQuMjog PHZlbmRvciAweDA1NTc+IGF0IHVzYnVzNCAoZGlzY29ubmVjdGVkKQp1aHViNjogYXQgdWh1YjQs IHBvcnQgMSwgYWRkciAyIChkaXNjb25uZWN0ZWQpCnVnZW40LjM6IDxDSEVTRU4+IGF0IHVzYnVz NCAoZGlzY29ubmVjdGVkKQp1a2JkMDogYXQgdWh1YjYsIHBvcnQgMSwgYWRkciAzIChkaXNjb25u ZWN0ZWQpCnVoaWQwOiBhdCB1aHViNiwgcG9ydCAxLCBhZGRyIDMgKGRpc2Nvbm5lY3RlZCkKdWdl bjQuNDogPHZlbmRvciAweDA0MjQ+IGF0IHVzYnVzNCAoZGlzY29ubmVjdGVkKQp1aHViNzogYXQg dWh1YjQsIHBvcnQgMiwgYWRkciA0IChkaXNjb25uZWN0ZWQpCnVnZW40LjU6IDxGVERJPiBhdCB1 c2J1czQgKGRpc2Nvbm5lY3RlZCkKdWZ0ZGkwOiBhdCB1aHViNywgcG9ydCAxLCBhZGRyIDUgKGRp c2Nvbm5lY3RlZCkKdWZ0ZGkxOiBhdCB1aHViNywgcG9ydCAxLCBhZGRyIDUgKGRpc2Nvbm5lY3Rl ZCkKdWZ0ZGkyOiBhdCB1aHViNywgcG9ydCAxLCBhZGRyIDUgKGRpc2Nvbm5lY3RlZCkKdWZ0ZGkz OiBhdCB1aHViNywgcG9ydCAxLCBhZGRyIDUgKGRpc2Nvbm5lY3RlZCkKdWdlbjQuNjogPEZUREk+ IGF0IHVzYnVzNCAoZGlzY29ubmVjdGVkKQp1ZnRkaTQ6IGF0IHVodWI3LCBwb3J0IDIsIGFkZHIg NiAoZGlzY29ubmVjdGVkKQp1ZnRkaTU6IGF0IHVodWI3LCBwb3J0IDIsIGFkZHIgNiAoZGlzY29u bmVjdGVkKQp1ZnRkaTY6IGF0IHVodWI3LCBwb3J0IDIsIGFkZHIgNiAoZGlzY29ubmVjdGVkKQp1 ZnRkaTc6IGF0IHVodWI3LCBwb3J0IDIsIGFkZHIgNiAoZGlzY29ubmVjdGVkKQp1Z2VuNC43OiA8 RlREST4gYXQgdXNidXM0IChkaXNjb25uZWN0ZWQpCnVmdGRpODogYXQgdWh1YjcsIHBvcnQgMywg YWRkciA3IChkaXNjb25uZWN0ZWQpCnVmdGRpOTogYXQgdWh1YjcsIHBvcnQgMywgYWRkciA3IChk aXNjb25uZWN0ZWQpCnVmdGRpMTA6IGF0IHVodWI3LCBwb3J0IDMsIGFkZHIgNyAoZGlzY29ubmVj dGVkKQp1ZnRkaTExOiBhdCB1aHViNywgcG9ydCAzLCBhZGRyIDcgKGRpc2Nvbm5lY3RlZCkKdWdl bjQuODogPEZUREk+IGF0IHVzYnVzNCAoZGlzY29ubmVjdGVkKQp1ZnRkaTEyOiBhdCB1aHViNywg cG9ydCA0LCBhZGRyIDggKGRpc2Nvbm5lY3RlZCkKdWZ0ZGkxMzogYXQgdWh1YjcsIHBvcnQgNCwg YWRkciA4IChkaXNjb25uZWN0ZWQpCnVmdGRpMTQ6IGF0IHVodWI3LCBwb3J0IDQsIGFkZHIgOCAo ZGlzY29ubmVjdGVkKQp1ZnRkaTE1OiBhdCB1aHViNywgcG9ydCA0LCBhZGRyIDggKGRpc2Nvbm5l Y3RlZCkKdWh1Yjg6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI5 OiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuNy4yOiA8dmVuZG9y IDB4MDQyND4gYXQgdXNidXM3CnVodWI2OiA8dmVuZG9yIDB4MDQyNCBwcm9kdWN0IDB4MjUxNCwg Y2xhc3MgOS8wLCByZXYgMi4wMC84MC5hMCwgYWRkciAyPiBvbiB1c2J1czcKdWh1YjY6IDQgcG9y dHMgd2l0aCA0IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW40LjI6IDx2ZW5kb3IgMHgwNTU3 PiBhdCB1c2J1czQKdWh1Yjc6IDx2ZW5kb3IgMHgwNTU3IHByb2R1Y3QgMHg3MDAwLCBjbGFzcyA5 LzAsIHJldiAxLjEwLzEuMDAsIGFkZHIgMj4gb24gdXNidXM0CnVnZW43LjM6IDxGVERJPiBhdCB1 c2J1czcKdWZ0ZGkwOiA8UXVhZCBSUzIzMi1IUz4gb24gdXNidXM3CnVmdGRpMTogPFF1YWQgUlMy MzItSFM+IG9uIHVzYnVzNwp1ZnRkaTI6IDxRdWFkIFJTMjMyLUhTPiBvbiB1c2J1czcKdWZ0ZGkz OiA8UXVhZCBSUzIzMi1IUz4gb24gdXNidXM3CnVodWI3OiA0IHBvcnRzIHdpdGggNCByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZAp1Z2VuNy40OiA8RlREST4gYXQgdXNidXM3CnVmdGRpNDogPFF1YWQg UlMyMzItSFM+IG9uIHVzYnVzNwp1ZnRkaTU6IDxRdWFkIFJTMjMyLUhTPiBvbiB1c2J1czcKdWZ0 ZGk2OiA8UXVhZCBSUzIzMi1IUz4gb24gdXNidXM3CnVmdGRpNzogPFF1YWQgUlMyMzItSFM+IG9u IHVzYnVzNwp1Z2VuNC4zOiA8Q0hFU0VOPiBhdCB1c2J1czQKdWtiZDA6IDxDSEVTRU4gVVNCIEtl eWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzEuMTAsIGFkZHIgMz4gb24gdXNidXM0CmtiZDIg YXQgdWtiZDAKdWhpZDA6IDxDSEVTRU4gVVNCIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEw LzEuMTAsIGFkZHIgMz4gb24gdXNidXM0CnVnZW43LjU6IDxGVERJPiBhdCB1c2J1czcKdWZ0ZGk4 OiA8UXVhZCBSUzIzMi1IUz4gb24gdXNidXM3CnVmdGRpOTogPFF1YWQgUlMyMzItSFM+IG9uIHVz YnVzNwp1ZnRkaTEwOiA8UXVhZCBSUzIzMi1IUz4gb24gdXNidXM3CnVmdGRpMTE6IDxRdWFkIFJT MjMyLUhTPiBvbiB1c2J1czcKdWdlbjcuNjogPEZUREk+IGF0IHVzYnVzNwp1ZnRkaTEyOiA8UXVh ZCBSUzIzMi1IUz4gb24gdXNidXM3CnVmdGRpMTM6IDxRdWFkIFJTMjMyLUhTPiBvbiB1c2J1czcK dWZ0ZGkxNDogPFF1YWQgUlMyMzItSFM+IG9uIHVzYnVzNwp1ZnRkaTE1OiA8UXVhZCBSUzIzMi1I Uz4gb24gdXNidXM3Cg== --------_4B10C96F00000000DA8D_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="usb-log.txt" Content-Disposition: attachment; filename="usb-log.txt" Content-Transfer-Encoding: base64 Tm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5 NTogc3Q9MApOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJt aXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0ZGQxNDgsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIw ZThkOCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDog dXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0weGZm ZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNz PTB4MDAKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRw b2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2Vy bmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBr ZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MjkgZHg3NTAw IGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01Q TEVUSU9OCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBw ZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAwNGRkMTQ4IGVuZHBvaW50PTB4ZmZmZmZmMDAw MWIwZThkOCBzdHM9MCBhbGVuPTgsIHNsZW49OCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3 OjI5IGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MQpOb3Yg MjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBz dD0wCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDox Mzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDE0OCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4 LCBuZnJhbWVzPTEsIGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNi X2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0weGZmZmZm ZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4 MDAKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2lu dD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVs OiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJu ZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtl cm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVU SU9OCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJf c3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAwNGRkMTQ4IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIw ZThkOCBzdHM9MCBhbGVuPTgsIHNsZW49OCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjI5 IGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MQpOb3YgMjgg MTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6dXMxYjNkXzlkOW86 XyByeGVmcWV1cmU9c3RfY2FsMGx4YmZhZmNma2ZmOmYwMDA5MWU1YzozIDJzYXQ4PSwwIGVuZHBv aW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6 MjkgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZm ZjgwMDA0ZGQxNDgsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9 d3JpdGUKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6 IGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRw b2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBf cXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjI5 IGR4NzUwMCBrZXJuZWw6IHVzdWJzYl9kZHVfbXRwX2VuZHJwYW9pbm50czpmIGVlcm5fZHBzb3Vp Ym5tdD1pdDoxMDR4ZjE4ZjpmIGZvZnBmZTBuMDAxYjBlOGQ4Ck5vdiAyOCAxNDo0NzoyOSBkeDc1 MDAga2VybmVsOiBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25l eHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6 IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAy OCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiBlaGNpX3NldF9od19wdW9zd2JlZHJfOnBpcDNlOF81 ZTluOnRlIHI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IApOb3Yg MjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5v diAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiBlaGNpX3NldF9od19wb3dlcjozODcxOiBBc3lu YyBpcyBhY3RpdmUKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IGVoY2lfc2V0X2h3X3Bv d2VyOjM4NzY6IFBlcmlvZGljIGlzIGFjdGl2ZQpOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5l bDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9O Ck5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50 ZXIKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9z dWI6MjU4MjogeGZlcj0weGZmZmZmZjgwMDA0ZGQxNDggZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBl OGQ4IHN0cz0wIGFsZW49OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6Mjkg ZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBzdD0xCk5vdiAyOCAx NDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4 ZmZmZmZmODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4LCBuZnJhbWVzPTEs IGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9p bnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQg aXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0 OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAw MDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5z ZmVyX3N1Ym1pdDoxNDE4OiBvcGVuCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2Jk X3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVz YmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MApOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtl cm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0ZGQxNDgs IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUKTm92IDI4 IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZm ZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2NfbmV4dD0wIHRvZ2ds ZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2Vy bmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHhmZXI6IApO b3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVy Ck5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N0YXJ0X2NiOjIy ODU6IHN0YXJ0Ck5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2Rv bmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjI5IGR4 NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZm ZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHN0cz0wIGFsZW49OCwgc2xl bj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiZF9w aXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2Jk X3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVz YmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3Yg MjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1V U0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1 c2JkX2NhbGxiYXVjc2tiX2R3X3JjYWFwbHBsZWJyYV9jc2t1X2J3OnJhcDJwNWU4cl8yczp1IGJ4 OmZlcjI9NTgyOiB4MGZ4ZWZyZj1mZmZmMDAwMDF4ZWZjZjNmMmZhOGYgZmU4bjBkMHAwbzRpZG50 ZD0xNDggZW4wZHhwZm9maW5mdGY9ZmYwMDIxMDJ4MWY2ZjlmMGYwZiBmczB0MHM9MDFiMGU4ZDgg MHMgdGFzbD1lbjA9IGEybCxlIHNubD1lbjg9LDYgNHMsbCBlYW5mPXJtOD0sMSAsYSBmbmZycm1t PT0xMSwgbmZybT0xCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVy X3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYw MDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2Vy bmVsOiB1c2JkX2RvX3JlcXVlc3RfY2FsbGJhY2s6OTU6IHN0PTEKTm92IDI4IDE0OjQ3OjI5IGR4 NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5 MDAKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0 MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0xIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjgg MTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZm MDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlw ZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5lbDogdXNiZF9w aXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2Jk X2RvX3JlcXVlc3RfY3Vhc2xibGRiX2F0Y2tyYTpuc2Y5ZTVyOl9kIG9zbnRlPTowMjIxNTogZXJy PVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6 IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGRkMTQ4LCBlbmRw b2ludD0weGZmZmZmZjAwMDFiMGU4ZDgsIG5mcmFtZXM9MSwgZGlyPXdyaXRlCk5vdiAyOCAxNDo0 NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9 MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBzdHM9MCBhbGVu PTIsIHNsZW49NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVs OiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4Ck5vdiAyOCAx NDo0NzoyOSBkeDc1MDAga2VybmVsOiBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0 PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjI5IGR4 NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDgg eGZlcjogCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1dXNzYmJkZF9fdHByaWFwbmVz X2ZlZW5ydF9lc3J1OmJtaTF0NTo4NjoxIDNlOW45dDplIHJ4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJh OCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAy OCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92 IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MjkgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0w eGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRy ZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjI5IGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAg a2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjI5IGR4NzUw MCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MjkgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9D T01QTEVUSU9OCk5vdiAyOCAxNDo0NzoyOSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2Rv bmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjI5IGR4 NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6dTJzNWI4ZDI6XyBjeGFmbGVs cmI9YWNrX3dyMGF4cGZwZWZyZl9mc2Z1ZmIwOjAwMWUyYzUzODIyYTo4IHggZmVlcm49ZHBvaW4w dHg9ZmZmZmZmMDh4MGYwZjBmNGZkZmRmMTA0MDgyIDFlMjFuNjlkMHAwbyBpbnQ9c3RzPTB4MGYg ZmFmbGZlZm5mPTAwMDIxLGIgMHNlbDhkZThuID1zdDZzND0sIGEwZiByYW1sPWVuPTEsOCBuLGYg cm1zPWxlMW49OCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6 IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBlbmRw b2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0OjQ3 OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MQpOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4 ZmZmZmZmMDAyMTIxNjkwMApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogZWRlc2M9MHhm ZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTEgYkVuZHBvaW50QWRkcmVz cz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5k cG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtl cm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAg a2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09N UExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXVzc2JiZGRfX2Rjb2FfbHJs ZWJxYXVjZWtzX3R3X3JjYWFwbHBsZWJyYV9jc2t1OmI6OTUyOjUgOHMydDo9IDB4ZmVyPTB4ZmZm ZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTAgYWxlbj0yLCBz bGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNi ZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0ZGQxNDgsIGVuZHBvaW50 PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUKTm92IDI4IDE0OjQ3OjMw IGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYw MDAxZWMzMmE4LCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJl YWQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRw b2ludD0weGZmZmZmZjAwMDFiMGU4ZDgKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IGVk ZXNjPTB4ZmZmZmZmMDAwMWIwZWRlNCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2lu dEFkZHJlc3M9MHgwMApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVl dWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4 NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5 MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVu ZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVt cF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6 MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0 NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjgg MTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAy OCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVT Ql9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVz YmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTh1 MnM6YiBkeF9mY2VyYT1sbGJhYzBreF9md2ZyZmFmcGZwZmU4cjBfMHMwdTRiZDpkMTQ4MiA1ZW44 ZDJwOm8gaXhuZnRlPXI9MHgwZnhmZmZmZmZmZmYwZjBmMDAxMGIwMDFlZThkYzgzIDJzYXQ4cyA9 ZW5kMCBwYW9saWVubj10PTgsIHNsMGV4bmY9OGYsZiBmYWZmcm1mPTAwMjEyMTEsNiA5bjBmMHIg bT1zMXRzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAg ZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBzdD0xCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4 ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEs IGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiAKTm92IDI4IDE0OjQ3OjMw IGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEy MTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTEg YkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2Jf ZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4 IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9 MHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTog eGZlcj0weGZmZmZmZjgwMDA0ZGQxNDgsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZy YW1lcz0xLCBkaXI9d3JpdGUKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3YgMjgg MTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZm ZmZmMDAwMWIwZThkOCBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xl X25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5v diAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkdV9zY2JhbGRsX2JhY2tfcHdpcnBhZXBf cGVlbnJ0X2VzcnU6YjoxNTI4NTY4OjI6ICBleG5mdGVlcnI9MHhmZmZmZmYwMDAxZWMzMmE4IGVu ZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBzdHM9MCBhbGVuPTIsIHNsZW49NjQsIGFmcm09MSwg bmZybT0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0 ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzAg ZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAw MDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjl1MHMwYixkIF9uZnJ0YXJtYWVuc3M9 ZmUxcixfIGRkb2lucmU9OnJlYTJkMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2Vy bmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNj PTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2ludEFk ZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6 IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYmRfY3Vhc2xsYmJkYV9jcGtpX3B3ZXJfYWVwbnB0ZWVycl86c3ViMTo1ODYy OjUgOGUybjp0IHhmZXJlPXIweGZmZmZmZjgwMDA0ZGQxNDggZW5kcG9pbnQ9MHhmZmZmZmYwMDAx YjBlOGQ4IHN0cz0wIGFsZW49OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6 MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0 NzozMCBkeDc1MDAga2VybmVsOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRf ZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MXVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9 VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDog Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3Vi OjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkw MCBzdHM9MCBhbGVuPTIsIHNsZW49NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMCBk eDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAw MWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFk Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9p bnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9 MCB0b2dnbGVfbmV4dD0xIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4 ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2 OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0 NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2RvX3JlcXVlc3Rf Y2FsbGJhY2s6OTU6IHN0PTB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9S TUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNm ZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGRkMTQ4LCBlbmRwb2ludD0weGZmZmZm ZjAwMDFiMGU4ZDgsIG5mcmFtZXM9MSwgZGlyPXdyaXRlCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAg a2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAx ZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBzdHM9MCBhbGVuPTIsIHNsZW49NjQs IGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9l bmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4Ck5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25l eHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6 IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAy OCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1dXNiZHNfcGlicGVfZGVudGVfcjp0MTU4cjZhOiBl bm50ZXJzZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9 MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMCBk eDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMw IGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBf ZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0weGZmZmZmZjAwMDFi MmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4ODUKTm92 IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZm ZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2Jk X3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVz YmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDog dXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5v diAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJy PVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6 IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6dTI1czgyOmIgeGZlZHI9X2NhMHhmbGZmZmxmZjhi MDAwNGFkZDFjNDhrIGVuX2Rwb3dpbnRyPWEweHBmZmZmcGZmZTAwMDFyYjBlXzhkOHMgc3RzdT0w YiBhbDplbj0yOCwgNXNsZThuPTgyLCBhZnJtPToxLCAgbmZ4cm09ZjFlcj0weGZmZmZmZjAwMDFl YzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0wIGFsZW49Miwgc2xlbj02NCwg YWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVx dWVzdF9jYWxsYmFjazo5NTogc3Q9MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNi ZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50 PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAg ZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9l bmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZmZmZmMDAwMWIy ZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0xIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZm ZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRf cGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNi ZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1 c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92 IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4 MjogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0 cz0wIGFsZW49Miwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMz MmE4LCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92 IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0w eGZmZmZmZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRv Z2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAg a2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6 IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVu dGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODog c3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToy MjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAw IGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAw MWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTAgYWxlbj0yLCBzbGVuPTY0 LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFu c2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZm ZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAw IGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBl ZGVzYz0weGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MSBiRW5kcG9p bnRBZGRyZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAy MTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9l bnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBl X3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3Ry YW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZl cj0weGZmZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0wIGFs ZW49Miwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZm ZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9u ZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5v diAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBl cnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJh OCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJt PTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0Nzoz MCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZm MDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1y ZWFkCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBp c29jX25leHQ9MCB0b2dnbGVfbmV4dD0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiBi RW5kcG9pbnRBZGRyZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZm ZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5v diAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBl cnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJh OCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJt PTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9z dWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAy MTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0w eGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRy ZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAg a2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydGVoY2lfc2V0X2h3X3Bvd2VyOjM4 NTk6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogZWhjaV9zZXRfaHdfcG93ZXI6Mzg1 OTogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2RvX3JlcXVlc3RfZmxhZ3M6 MzI3OiBIYW5kbGUgUmVxdWVzdCBmdW5jdGlvbiBpcyBzZXQKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IGVoY2lfc2V0X2h3X3Bvd2VyOjM4NzE6IEFzeW5jIGlzIGFjdGl2ZQpOb3YgMjgg MTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2ZsYWdzOjMyNzogSGFuZGxl IFJlcXVlc3QgZnVuY3Rpb24gaXMgc2V0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiBl aGNpX3NldF9od19wb3dlcjozODc2OiBQZXJpb2RpYyBpcyBhY3RpdmUKTm92IDI4IDE0OjQ3OjMw IGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9mbGFnczozMjc6IEhhbmRsZSBSZXF1ZXN0 IGZ1bmN0aW9uIGlzIHNldApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGxhc3QgbWVzc2FnZSByZXBl YXRlZCA3IHRpbWVzCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVy X2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMw IGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19y ZXF1ZXN0X2ZsYWdzOjMyNzogSGFuZGxlIFJlcXVlc3QgZnVuY3Rpb24gaXMgc2V0dXNiZF9jYWxs YmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0w eGZmZmZmZjAwMjEyMTY5MDAgc3RzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2ZsYWdzOjMyNzog SGFuZGxlIFJlcXVlc3QgZnVuY3Rpb24gaXMgc2V0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2Vy bmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwg ZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVz Yl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZm ZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTEgYkVuZHBvaW50QWRkcmVzcz0w eDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9p bnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2Vy bmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBr ZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MHVzYmRfdHJhbnNmZXJfZG9u ZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0 ZDExNDgsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMTliMTBkOCwgbmZyYW1lcz0yLCBkaXI9cmVhZApO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1Yjoy NTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAg c3RzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMTliMTBk OApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogZWRlc2M9MHhmZmZmZmYwMDAxOWIxNWU0 IGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYw MDAxOWIxMGQ4IHhmZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90dXNi cmFuc2RfcGZlcmlwZV9fc3ViZW50bWl0ZXI6OjExNTM5OTg2OiBlbnQ6IGVyeGZlcj0weGZmZmZm ZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9 cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6 IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiAKTm92IDI4IDE0OjQ3OjMwIGR4 NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5 MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVu ZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVt cF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6 MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0 NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VS Ul9OT1JNQUxfQ09NUExFVElPTnVzYmRfZG9fcmVxdWVzdF9mbGFnczozMjc6IEhhbmRsZSBSZXF1 ZXN0IGZ1bmN0aW9uIGlzIHNldApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90 cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2RvX3JlcXVlc3RfZmxhZ3M6MzI3OiBIYW5kbGUg UmVxdWVzdCBmdW5jdGlvbiBpcyBzZXQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1Yjoy NTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMXVzYjY5 MDBkXyBzdGRvX3M9cmVxdTAgYWVzdGxlbl9mbD0yLGFncyBzbDozZW49Mjc6NjQsIEhhIGFmbmRs ZXJtPSBSZTEsIHF1ZXNuZnJ0IGZtPTF1bmN0aW9uIGlzIHNldApOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFl YzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2ZsYWdzOjMyNzog SGFuZGxlIFJlcXVlc3QgZnVuY3Rpb24gaXMgc2V0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2Vy bmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwCk5vdiAy OCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2RvX3JlcXVlc3RfZmxhZ3M6MzI3OiBIYW5k bGUgUmVxdWVzdCBmdW5jdGlvbiBpcyBzZXQgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2Nf bmV4dD0wIHRvZ2dsZV9uZXh0PTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRf ZG9fcmVxdWVzdF9mbGFnczozMjc6IEhhbmRsZSBSZXF1ZXN0IGZ1bmN0aW9uIGlzIHNldCBiRW5k cG9pbnRBZGRyZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9f cmVxdWVzdF9mbGFnczozMjc6IEhhbmRsZSBSZXF1ZXN0IGZ1bmN0aW9uIGlzIHNldApOb3YgMjgg MTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBzdD0w Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9 MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDog dXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0Y2IxNDgsIGVuZHBv aW50PTB4ZmZmZmZmMDAwMWQ0NzBkOCwgbmZyYW1lcz0yLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6 MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAw MWQ0NzBkOApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1 ODY6IGVudGVyIGVkZXNjPTB4ZmZmZmZmMDAwMWQ0NzVlNCBpc29jX25leHQ9MCB0b2dnbGVfbmV4 dD0wCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODog c3RhcnQgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAwNGQxMTQ4 IGVuZHBvaW50PTB4ZmZmZmZmMDAwMTliMTBkOCBzdHM9MCBhbGVuPTEyLCBzbGVuPTEyLCBhZnJt PTIsIG5mcm09MgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0 X2NhbGxiYWNrOjk1OiBzdD0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVt cF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxZDQ3MGQ4IHhmZXI6IApOb3YgMjggMTQ6NDc6 MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05P Uk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiAKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdXViOnNiZF9wMjVp cDgyOmVfIHhlbmZldGVyPXI6MTA1OHhmNmY6ZiBmZmVmbjB0MGUwcjFlYzMyYTggZW5kcG9pbnQ9 MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0wIGFsZW49Miwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFy dApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5 OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwg bmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9k b19yZXF1ZXN0X2ZsYWdzOjMyNzogSGFuZGxlIFJlcXVlc3QgZnVuY3Rpb24gaXMgc2V0Ck5vdiAy OCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhm ZmZmZmYwMDIxMjE2OTAwCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2RvX3Jl cXVlc3RfZmxhZ3M6MzI3OiBIYW5kbGUgUmVxdWVzdCBmdW5jdGlvbiBpcyBzZXQgZWRlc2M9MHhm ZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAKTm92IDI4IDE0OjQ3OjMw IGR4NzUwMCBrZXJuZWw6IGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4 ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2 OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0 NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2Rv bmU6MjIxdXM1OiBiZF9lcnJ0cmE9VVNuc2ZCX0Vlcl9SUl9OZG9uT1JNZTpBTF9DMjIxT01QNTog TEVUZXJySU9OPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193 cmFwcHVzYmRfY2FsbGJhY3Vza193YmRfcmFwZG9fcnBlcmVxdV9zdWVzdGI6X2NhbDI1OGxiYTI6 IGNrOnhmZXI5PTU6IDBzdD14ZmYwZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIx MjE2OTAwIHN0cz0wIGFsZW49Miwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3 OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZm ZmY4MDAwNGRkMTQ4LCBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDgsIG5mcmFtZXM9MSwgZGly PXdyaXRlCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1p dDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2 OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1 c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4Ck5vdiAyOCAxNDo0 NzozMCBkeDc1MDAga2VybmVsOiBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAg dG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZl cjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5k cG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25l eHQ9MCB0b2dnbGVfbmV4dD0xIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzAg ZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkw MCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjox NTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0 OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfZW50 ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9z dGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZGVyX19k b3N1Yl9yZToycXVlczU4MnRfYzogeGFsbGJmZXJhY2s9OjkwNTogeGZmc3Q9ZmZmMGY4MDAwNGNi MTQ4IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWQ0NzBkOCBzdHM9MCBhbGVuPTEyLCBzbGVuPTEyLCBh ZnJtPTIsIG5mcm09MgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zl cl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0ZDExNDgsIGVuZHBvaW50PTB4ZmZmZmZm MDAwMTliMTBkOCwgbmZyYW1lcz0yLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtl cm5lbDogdXNiZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBzdD0xCk5vdiAyOCAxNDo0NzozMCBk eDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxOWIx MGQ4Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2RvX3JlcXVlc3RfY2FsbGJh Y2s6OTU6IHN0PTAgZWRlc2M9MHhmZmZmZmYwMDAxOWIxNWU0IGlzb2NfbmV4dD0wIHRvZ2dsZV9u ZXh0PTAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0 OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGNiMTQ4LCBlbmRwb2ludD0weGZmZmZmZjAwMDFkNDcw ZDgsIG5mcmFtZXM9MiwgZGlyPXJlYWQgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0 NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYw MDAxZDQ3MGQ4IGVkZXNjPTB4ZmZmZmZmMDAwMWQ0NzVlNCBpc29jX25leHQ9MCB0b2dnbGVfbmV4 dD0wCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9p bnQ9MHhmZmZmZmYwMDAxOWIxMGQ4IHhmZXI6ICBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4 IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZm ZjAwMDFkNDcwZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3Bp cGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRf cGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNi ZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1 c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92 IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVy cj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1 OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtl cm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1Yjp1c2IyNWRfdDgyOnJhbnMgeGZmZXJlcj1f ZG9uZToweGYyMjFmZmY1OiBmZjAwZXJyPTAxZVVTYzMyQl9FUmE4IFJfTmVuZE9STUFwb2luTF9D dD1PTVBMMHhmZmZmZmZFVElPMDAyMU4yMTY5MDAgc3RzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJt PTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193 cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDE0OCBlbmRwb2ludD0weGZmZmZm ZjAwMDFiMGU4ZDggc3RzPTAgYWxlbj04LCBzbGVuPTgsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4 ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEs IGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2RvX3JlcXVlc3Rf Y2FsbGJhY2s6OTU6IHN0PTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1w X2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAKTm92IDI4IDE0OjQ3OjMwIGR4 NzUwMCBrZXJuZWw6IGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVf bmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92 IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbHVic2FiY2Rfa3BfaXdwZXJfYWVw bnB0ZWVycl86c3UxYjU6ODYyOiA1ZThuMnQ6ZSByeGZlcj0weGZmZmZmZjgwMDA0ZDExNDggZW5k cG9pbnQ9MHhmZmZmZmYwMDAxOWIxMGQ4IHN0cz0wIGFsZW49MTIsIHNsZW49MTIsIGFmcm09Miwg bmZybT0yCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0 ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzAg ZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXVxc2J1ZGVfc3RjX2FjbGFsbGxiYmFhY2Nra193OnI5 YTVwOnAgZXNydF89czF1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRjYjE0OCBlbmRwb2ludD0w eGZmZmZmZjAwMDFkNDcwZDggc3RzPTAgYWxlbj0xMiwgc2xlbj0xMiwgYWZybT0yLCBuZnJtPTIK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBl cnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBzdD0xCk5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYw MDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBzdHM9MCBhbGVuPTIsIHNsZW49 NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2Rv X3JlcXVlc3RfY2FsbGJhY2s6OTU6IHN0PTAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6 IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBlbmRw b2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0OjQ3 OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZm ZmY4MDAwNGQxMTQ4LCBlbmRwb2ludD0weGZmZmZmZjAwMDE5YjEwZDgsIG5mcmFtZXM9MiwgZGly PXJlYWQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6 IGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0xIGJFbmRw b2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBf cXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMw IGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMDE5 YjEwZDggZWRlc2M9MHhmZmZmZmYwMDAxOWIxNWU0IGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAg YkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2Jf ZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxOWIxMGQ4IHhmZXI6IApOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4 IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5v diAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJy PVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6 IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1Yjoy NTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAg c3RzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFl YzMyYTgsIGVuZHBvaW50PXVzYmRfZG9fcmUweGZxdWVzdF9jYWZsZmxmYmFjazpmZjAwOTU6IHN0 PTAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtl cm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0ZGQxNDgs IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUKTm92IDI4 IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZm ZmZmZjAwMjEyMTY5MDAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IGVkZXNjPTB4ZmZm ZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9 MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBv aW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggZWRlc2M9 MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRk cmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTog ZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHhmZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAw IGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4 NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAg ZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0Nzoz MCBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXVyX3N1Yjoyc2JkNTgyOiB4ZmVy PV9kb18wcnhmZmVxdWZmZmY4MDAwNGRlc3QxMTQ4IGVuZHBfY29pbmF0bD1sYmEweGZmZmZmZjAw MGNrOjE5YjEwZDggOXM1dHM6PTAgYWxlbiBzdD0xMiwgc2xlbj0wPTEyLCBhZnJtPTIsIG5mcm09 MgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5 OTogeGZlcj0weGZmZmZmZjgwMDA0Y2IxNDgsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWQ0NzBkOCwg bmZyYW1lcz0yLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9k b19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBzdD0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxZDQ3MGQ4Ck5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9F UlJfTk9STUFMX0NPTVBMRVRJT04gZWRlc2M9MHhmZmZmZmYwMDAxZDQ3NWU0IGlzb2NfbmV4dD0w IHRvZ2dsZV9uZXh0PTAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNm ZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTiBiRW5kcG9pbnRBZGRy ZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3Jh cHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYw MDIxMjE2OTAwIHN0cz0wIGFsZW49Miwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhm ZmZmZmYwMDAxZWMzMmE4LCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwg ZGlyPXJlYWQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBl bmRwb2ludD0weGZmZmZmZjAwMDFkNDcwZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAg a2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVk ZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0xCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIgYkVuZHBv aW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVf c3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3YgMjgg MTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZm MDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlw ZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9w aXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2Jk X2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAwNGRkMTQ4IGVuZHBv aW50PTB4ZmZmZmZmdXNiMDAwMWIwZWQ4X2R0OCBzdHM9MHJhbiBhbGVuPTgsIHNzZmVybGVuPV84 ZCwgb25lYWZybT0xLCBuOjJmcm09MTIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04K Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5 NTogc3Q9MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFw cGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRjYjE0OCBlbmRwb2ludD0weGZmZmZmZjAw MDFkNDcwZDggc3RzPTAgYWxlbj0xMiwgc2xlbj0xMiwgYWZybT0yLCBuZnJtPTIKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MApO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1 OiBzdD0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1p dDoxMzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRkMTE0OCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxOWIx MGQ4LCBuZnJhbWVzPTIsIGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiAK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2lu dD0weGZmZmZmZjAwMDE5YjEwZDggZWRlc2M9MHhmZmZmZmYwMDAxOWIxNWU0IGlzb2NfbmV4dD0w IHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxOWIxMGQ4IHhm ZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6 IGVudGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0 ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9j YWxsYmFjazo5NTogc3Q9MApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFu c2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0ZGQxNDgsIGVuZHBvaW50PTB4ZmZm ZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDgg ZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBv aW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9x dWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHhmZXI6IApOb3YgMjggMTQ6NDc6MzAg ZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVf ZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3YgMjgg MTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAy OCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6 IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2Vy bmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6dXNiMmRfZDIxbzU6XyByZWVxdXJyZT1zdFVfY2FsU0Jf bEViUmFSY2s6X05PUk05QTVMXzogQ09Nc1B0TD1FMFRJT04KTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGNi MTQ4LCBlbmRwb2ludD0weGZmZmZmZjAwMDFkNDcwZDgsIG5mcmFtZXM9MiwgZGlyPXJlYWQKTm92 IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9 VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDog dXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWQ0NzBkOApOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVy PTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTAgYWxl bj0yLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MSBlZGVzYz0weGZmZmZmZjAwMDFkNDc1ZTQgaXNv Y19uZXh0PTAgdG9nZ2xlX25leHQ9MApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNi ZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50 PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZCBiRW5kcG9pbnRBZGRyZXNz PTB4MDAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2Nf bmV4dD0wIHRvZ2dsZV9uZXh0PTAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9k dW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMDFkNDcwZDggeGZlcjogIGJFbmRwb2ludEFk ZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVy OjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1 ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBk eDc1MDAga2VybmVsOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9l bnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBl X3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2Nh bGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmZ1c2JkX3RyODAwMDRkMTE0OGFu c2Zlcl9kbyBlbmRwb2ludG49ZToyMjE1OiAweGZmZmZlcnI9VVNCX0VmZjAwMDE5YjEwUlJfTk9S TUFMX2Q4IHN0cz0wQ09NUExFVElPTiBhbGVuPTEyLCBzbGVuPTEyLCBhZnJtPTIsIG5mcm09MgpO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtl cm5lbDogdXNic2JkX2NhbGxiYWRfZG9fcmVxdWVzY2tfd3JhcHBlcl90X2NhbGxiYWNrc3ViOjI1 ODo5NTogc3Q9MTI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAy MTIxNjkwMCBzdHM9MCBhbGVuPTIsIHNsZW49NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0 NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9 MHhmZmZmZmY4MDAwNGRkMTQ4IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBzdHM9MCBhbGVu PTgsIHNsZW49OCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6 IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBlbmRw b2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0OjQ3 OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MQpOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4 ZmZmZmZmMDAyMTIxNjkwMApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogZWRlc2M9MHhm ZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTEgYkVuZHBvaW50QWRkcmVz cz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5k cG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtl cm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVydXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6 IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2Vy bmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBr ZXJuZWw6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2Zs YWdzOjMyNzogSGFuZGxlIFJlcXVlc3QgZnVuY3Rpb24gaXMgc2V0dXNiZF90cmFuc2Zlcl9kb25l OjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2F1c2JkbF9s YmFjYWxsY2JrYV9jd3JrX2F3cnBhcHBlcl9wZXJzdV9iczp1YjoyNTI4NTI4OiB4MjogeGZlcj0w eGZmZmZmZmZlcj0wMDAxZWMzMmEwOHhmZmZmZiBlbmRwb2lmbjgwMDA0Y3Q9YjAxeDQ4IGVuZmZm ZmZmMGQwMnBvaW50MTIxNjkwMD0gczB4ZnRzPTAgYWZsZmZmZjAwZW49MiwwIDFzZDQ3MGRsZW49 ODYgNHN0cz0sIGFmcjBtPSAxYWxlbiwgbmZyPW09MTIsIHMxbGVuPTEyLCBhZnJtPTIsIG5mcm09 MgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5 OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwg bmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9k b19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBzdD0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiBlZGVzYz0weGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0 PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMwIGR4 NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAg eGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpdXBzYmVfZWRuX3Rk ZW9fcjpyZTFxNXU4ZXM2OnQgX2VmbG5hZ3Rlc3I6MzI3OiBIYW5kbGUgUmVxdWVzdCBmdW5jdGlv biBpcyBzZXQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoy NDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0Nzoz MCBkeDc1MDAga2VybmVsOiB1c2JkX2RvX3JlcXVlc3RfZmxhZ3M6MzI3OiBIYW5kbGUgUmVxdWVz dCBmdW5jdGlvbiBpcyBzZXR1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9S TUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVy PTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTAgYWxl bj0yLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVu ZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2Jf ZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZmZmZm MDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0xIGJFbmRwb2ludEFkZHJlc3M9MHg4 NQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAg a2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6 IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVu dGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODog c3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9D T01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dy YXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZm MDAyMTIxNjkwMCBzdHM9MCBhbGVuPTIsIHNsZW49NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4 ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEs IGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2lu dDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBp c29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAy MTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9l bnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBl X3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3Ry YW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZl cj0weGZmZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0wIGFs ZW49Miwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZm ZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9u ZXh0PTEgYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5v diAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBl cnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJh OCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJt PTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9z dWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAy MTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0w eGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRy ZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAg a2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9D T01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dy YXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZm MDAyMTIxNjkwMCBzdHM9MCBhbGVuPTIsIHNsZW49NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4 ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEs IGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2lu dDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBp c29jX25leHQ9MCB0b2dnbGVfbmV4dD0xIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAy MTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9l bnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBl X3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3Ry YW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZl cj0weGZmZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0wIGFs ZW49Miwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZm ZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9u ZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5v diAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBl cnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJh OCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJt PTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9z dWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAy MTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0w eGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MSBiRW5kcG9pbnRBZGRy ZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAg a2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFl YzMxNDgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjk0MCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2lu dD0weGZmZmZmZjAwMjEyMTY5NDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQ3IGlzb2NfbmV4dD0w IHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDA2Ck5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTQwIHhm ZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6 MTQxODogb3BlbgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVy OjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVy X3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYw MDAxYjBlOGQ4LCBuZnJhbWVzPTEsIGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtl cm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVz Yz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRB ZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVl OiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4 NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxf Q09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193 cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZm ZjAwMjEyMTY5MDAgc3RzPTAgYWxlbj0yLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3YgMjgg MTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0w eGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0x LCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9p bnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0weGZmZmZmZjAwMDFiMmRlNDAg aXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4ODUKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAw MjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVf ZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlw ZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90 cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhm ZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBzdHM9MCBh bGVuPTIsIHNsZW49NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2Vy bmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwg ZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZm ZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVf bmV4dD0xIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92 IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0 Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTog ZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjAwMDFlYzMy YTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0wIGFsZW49Miwgc2xlbj02NCwgYWZy bT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJf c3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBlbmRwb2ludD0weGZmZmZmZjAw MjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgZWRlc2M9 MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRk cmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTog ZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAw IGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4 NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3RhcnRfY2I6MjI4NTogc3RhcnQKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VS Ul9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90 cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAx NDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkdXNiZF9jYWxsYmFja19fd2NyYWFwbHBsZWJhcmNf a3NfdXdicjphcDJwNWU4cjJfOnMgeHVmYmU6cj0yNTgyOjAgeHhmZmVyPWZmZmZmODAweDBmMGY0 ZmRmZGY2ZjcwMDAgMGUxbmVkcGNvM2kybmF0OD0gZW5kcDBveGlmbmZ0Zj1mZmYwMDAweDFmYmYw ZmVmOGZkZjgwIDBzMnQxczI9MTYwOTAgMGEgbHNlbj10OHMsPSBzMGwgZWFubD1lbjg9LDIgLGEg ZnNscmVtbj09MTYsNCAsbiBmYXJmbXI9bTE9MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4 NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zl cl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZm MDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtl cm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVz Yz0weGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MSBiRW5kcG9pbnRB ZGRyZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVl OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NP TVBMRVRJT04KTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjox NTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0 OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNr X3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMTQ4IGVuZHBvaW50PTB4ZmZm ZmZmMDAyMTIxNjk0MCBzdHM9MCBhbGVuPTEsIHNsZW49MSwgYWZybT0xLCBuZnJtPTEKTm92IDI4 IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNC X0VSUl9TVEFMTEVECk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNr X3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZm ZmZmMDAyMTIxNjkwMCBzdHM9MjIgYWxlbj0wLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZl cj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1l cz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5k cG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0weGZmZmZmZjAwMDFiMmRl NDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MSBiRW5kcG9pbnRBZGRyZXNzPTB4ODUKTm92IDI4 IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZm ZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3Bp cGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRf dHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGRkNjcwLCBlbmRwb2ludD0w eGZmZmZmZjAwMDFiMGU4ZDgsIG5mcmFtZXM9MSwgZGlyPXdyaXRlCk5vdiAyOCAxNDo0NzozMCBk eDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBl OGQ4IGVkZXNjPTB4ZmZmZmZmMDAwMWIwZWRlNCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJF bmRwb2ludEFkZHJlc3M9MHgwMApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1 bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCB4ZmVyOiAKTm92IDI4IDE0OjQ3 OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdGFydF9jYjoyMjg1OiBzdGFydApO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVy cj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAwNGRkNjcw IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBzdHM9MCBhbGVuPTgsIHNsZW49OCwgYWZybT0x LCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoy NDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9k b25lOjIyMTU6IGVycj1VU0JfRVJSX1NUQUxMRUQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjAwMDFlYzMy YTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0yMiBhbGVuPTAsIHNsZW49NjQsIGFm cm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVy X3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYw MDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2Vy bmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNj PTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2ludEFk ZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6 IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUw MCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0 ZGQ2NzAsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUK Tm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2lu dD0weGZmZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2NfbmV4dD0w IHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMCBkeDc1 MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHhm ZXI6IApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6 IGVudGVyCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N0YXJ0 X2NiOjIyODU6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5z ZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3 OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0w eGZmZmZmZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHN0cz0wIGFsZW49 OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDog dXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfU1RBTExFRApOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVy PTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTIyIGFs ZW49MCwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0 OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZm ZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9u ZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVs OiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3Yg MjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5v diAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4 ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4LCBuZnJh bWVzPTEsIGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBf ZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0weGZmZmZmZjAwMDFi MGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92 IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZm ZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2Jk X3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVz YmRfdHJhbnNmZXJfc3RhcnRfY2I6MjI4NTogc3RhcnQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBr ZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExF VElPTgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVy X3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCBlbmRwb2ludD0weGZmZmZmZjAwMDFi MGU4ZDggc3RzPTAgYWxlbj04LCBzbGVuPTgsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0Nzoz MCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3 OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9T VEFMTEVECk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBw ZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAy MTIxNjkwMCBzdHM9MjIgYWxlbj0wLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6 NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZm ZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBk aXI9cmVhZApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6 IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0weGZmZmZmZjAwMDFiMmRlNDAgaXNv Y19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4ODUKTm92IDI4IDE0OjQ3 OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMjEy MTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfZW50 ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNm ZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGRkNjcwLCBlbmRwb2ludD0weGZmZmZm ZjAwMDFiMGU4ZDgsIG5mcmFtZXM9MSwgZGlyPXdyaXRlCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAg a2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IGVk ZXNjPTB4ZmZmZmZmMDAwMWIwZWRlNCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2lu dEFkZHJlc3M9MHgwMApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVl dWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4 NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAg ZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdGFydF9jYjoyMjg1OiBzdGFydApOb3YgMjgg MTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0Jf RVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2Jk X2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAwNGRkNjcwIGVuZHBv aW50PTB4ZmZmZmZmMDAwMWIwZThkOCBzdHM9MCBhbGVuPTgsIHNsZW49OCwgYWZybT0xLCBuZnJt PTEKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBz dGFydApOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIy MTU6IGVycj1VU0JfRVJSX1NUQUxMRUQKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVz YmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTggZW5k cG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0yMiBhbGVuPTAsIHNsZW49NjQsIGFmcm09MSwg bmZybT0xCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1p dDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2 OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2VybmVsOiB1 c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZm ZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9 MHg4NQpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBv aW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMwIGR4NzUwMCBrZXJu ZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtl cm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0ZGQ2NzAs IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUKTm92IDI4 IDE0OjQ3OjMwIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZm ZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2NfbmV4dD0wIHRvZ2ds ZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMCBkeDc1MDAga2Vy bmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHhmZXI6IApO b3YgMjggMTQ6NDc6MzAgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVy Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N0YXJ0X2NiOjIy ODU6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2Rv bmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMxIGR4 NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZm ZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHN0cz0wIGFsZW49OCwgc2xl bj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9w aXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2Jk X3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfU1RBTExFRApOb3YgMjggMTQ6NDc6MzEg ZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZm ZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTIyIGFsZW49MCwg c2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVz YmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBlbmRwb2lu dD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0OjQ3OjMx IGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEy MTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAg YkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2Jf ZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6 NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAx NDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4 ZmZmZmZmODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4LCBuZnJhbWVzPTEs IGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9p bnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQg aXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0 OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAw MDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVf ZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJh bnNmZXJfc3RhcnRfY2I6MjI4NTogc3RhcnQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6 IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpO b3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1Yjoy NTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDgg c3RzPTAgYWxlbj04LCBzbGVuPTgsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMSBkeDc1 MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMxIGR4 NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9TVEFMTEVE Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3Vi OjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkw MCBzdHM9MjIgYWxlbj0wLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzEg ZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAw MDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVh ZApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBv aW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0weGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0 PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMxIGR4 NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAg eGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4 NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3Vi bWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGRkNjcwLCBlbmRwb2ludD0weGZmZmZmZjAwMDFi MGU4ZDgsIG5mcmFtZXM9MSwgZGlyPXdyaXRlCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVs OiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IGVkZXNjPTB4 ZmZmZmZmMDAwMWIwZWRlNCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2ludEFkZHJl c3M9MHgwMApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVu ZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBr ZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzEgZHg3NTAw IGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdGFydF9jYjoyMjg1OiBzdGFydApOb3YgMjggMTQ6NDc6 MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05P Uk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxi YWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAwNGRkNjcwIGVuZHBvaW50PTB4 ZmZmZmZmMDAwMWIwZThkOCBzdHM9MCBhbGVuPTgsIHNsZW49OCwgYWZybT0xLCBuZnJtPTEKTm92 IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApO b3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVy cj1VU0JfRVJSX1NUQUxMRUQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2Fs bGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9 MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0yMiBhbGVuPTAsIHNsZW49NjQsIGFmcm09MSwgbmZybT0x Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5 OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBu ZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVt cF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZmZmZmMDAw MWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpO b3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4 ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVz YmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDog dXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0ZGQ2NzAsIGVuZHBv aW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUKTm92IDI4IDE0OjQ3 OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAw MDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0 PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1 c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHhmZXI6IApOb3YgMjgg MTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAy OCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N0YXJ0X2NiOjIyODU6IHN0 YXJ0Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIx NTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBr ZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjgwMDA0 ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHN0cz0wIGFsZW49OCwgc2xlbj04LCBh ZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0 YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5z ZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfU1RBTExFRApOb3YgMjggMTQ6NDc6MzEgZHg3NTAw IGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAw MWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTIyIGFsZW49MCwgc2xlbj02 NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJh bnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBlbmRwb2ludD0weGZm ZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0OjQ3OjMxIGR4NzUw MCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAg ZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBv aW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9x dWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6MzEg ZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0Nzoz MSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZm ODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4LCBuZnJhbWVzPTEsIGRpcj13 cml0ZQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVu ZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19u ZXh0PTAgdG9nZ2xlX25leHQ9MApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogYkVuZHBv aW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiAKTm92IDI4IDE0 OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAw MDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVf ZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IApOb3YgMjgg MTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdGFydF9jYjoyMjg1OiBzdGFy dApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6 IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2Vy bmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAwNGRk NjcwIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBzdHM9MCBhbGVuPTgsIHNsZW49OCwgYWZy bT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFy dDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zl cl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX1NUQUxMRUQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBr ZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjAwMDFl YzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0yMiBhbGVuPTAsIHNsZW49NjQs IGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5z ZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhmZmZm ZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAg a2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIGVk ZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2lu dEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVl dWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMxIGR4 NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzEg ZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgw MDA0ZGQ2NzAsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3Jp dGUKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRw b2ludD0weGZmZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2NfbmV4 dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMSBk eDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4 IHhmZXI6IApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1 ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1 Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzE0OCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIx MjE2OTQwLCBuZnJhbWVzPTEsIGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjk0MCBlZGVzYz0w eGZmZmZmZjAwMDFiMmRlNDcgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MSBiRW5kcG9pbnRBZGRy ZXNzPTB4MDYKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5NDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAg a2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUw MCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzEgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9D T01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dy YXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMTQ4IGVuZHBvaW50PTB4ZmZmZmZm MDAyMTIxNjk0MCBzdHM9MCBhbGVuPTEsIHNsZW49MSwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0 OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3RhcnRfY2I6MjI4NTogc3RhcnQK Tm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBl cnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5l bDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3 MCBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggc3RzPTAgYWxlbj04LCBzbGVuPTgsIGFmcm09 MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6 MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJf ZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9TVEFMTEVECk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2Vy bmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMz MmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBzdHM9MjIgYWxlbj0wLCBzbGVuPTY0LCBh ZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zl cl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZm MDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtl cm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVz Yz0weGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRB ZGRyZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVl OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1 MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4 NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAw NGRkNjcwLCBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDgsIG5mcmFtZXM9MSwgZGlyPXdyaXRl Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9p bnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IGVkZXNjPTB4ZmZmZmZmMDAwMWIwZWRlNCBpc29jX25leHQ9 MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9MHgwMApOb3YgMjggMTQ6NDc6MzEgZHg3 NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCB4 ZmVyOiAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2 OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdGFy dF9jYjoyMjg1OiBzdGFydApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFu c2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0 NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9 MHhmZmZmZmY4MDAwNGRkNjcwIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBzdHM9MCBhbGVu PTgsIHNsZW49OCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6 IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5l bDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX1NUQUxMRUQKTm92IDI4IDE0 OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZl cj0weGZmZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0yMiBh bGVuPTAsIHNsZW49NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2Vy bmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwg ZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAx NDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZm ZmYwMDIxMjE2OTAwIGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVf bmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92 IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpO b3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTog eGZlcj0weGZmZmZmZjgwMDA0ZGQ2NzAsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZy YW1lcz0xLCBkaXI9d3JpdGUKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1w X2VuZHBvaW50OiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAx YjBlZGU0IGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5v diAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhm ZmZmZmYwMDAxYjBlOGQ4IHhmZXI6IApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNi ZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1 c2JkX3RyYW5zZmVyX3N0YXJ0X2NiOjIyODU6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAg a2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBM RVRJT04KTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBl cl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAx YjBlOGQ4IHN0cz0wIGFsZW49OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6 MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0 NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJf U1RBTExFRApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFw cGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAw MjEyMTY5MDAgc3RzPTIyIGFsZW49MCwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0 OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhm ZmZmZmYwMDAxZWMzMmE4LCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwg ZGlyPXJlYWQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50 OiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlz b2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0 NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIx MjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2Vu dGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5z ZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZm ZmYwMDAxYjBlOGQ4LCBuZnJhbWVzPTEsIGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAw IGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBl ZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9p bnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1 ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMSBk eDc1MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMx IGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3RhcnRfY2I6MjI4NTogc3RhcnQKTm92IDI4 IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNC X0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNi ZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCBlbmRw b2ludD0weGZmZmZmZjAwMDFiMGU4ZDggc3RzPTAgYWxlbj04LCBzbGVuPTgsIGFmcm09MSwgbmZy bT0xCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODog c3RhcnQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToy MjE1OiBlcnI9VVNCX0VSUl9TVEFMTEVECk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1 c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVu ZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBzdHM9MjIgYWxlbj0wLCBzbGVuPTY0LCBhZnJtPTEs IG5mcm09MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJt aXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIx NjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDog dXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0weGZm ZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNz PTB4ODUKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRw b2ludD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2Vy bmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBr ZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGRkNjcw LCBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDgsIG5mcmFtZXM9MSwgZGlyPXdyaXRlCk5vdiAy OCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhm ZmZmZmYwMDAxYjBlOGQ4IGVkZXNjPTB4ZmZmZmZmMDAwMWIwZWRlNCBpc29jX25leHQ9MCB0b2dn bGVfbmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9MHgwMApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtl cm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCB4ZmVyOiAK Tm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRl cgpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdGFydF9jYjoy Mjg1OiBzdGFydApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9k b25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMSBk eDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZm ZmY4MDAwNGRkNjcwIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBzdHM9MCBhbGVuPTgsIHNs ZW49OCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRf cGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNi ZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX1NUQUxMRUQKTm92IDI4IDE0OjQ3OjMx IGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZm ZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0yMiBhbGVuPTAs IHNsZW49NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1 c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9p bnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAxNDo0Nzoz MSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIx MjE2OTAwIGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0w IGJFbmRwb2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNi X2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0 OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjgg MTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0w eGZmZmZmZjgwMDA0ZGQ2NzAsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0x LCBkaXI9d3JpdGUKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBv aW50OiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0 IGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAx NDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYw MDAxYjBlOGQ4IHhmZXI6IApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBl X2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3Ry YW5zZmVyX3N0YXJ0X2NiOjIyODU6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVs OiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04K Tm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6 MjU4MjogeGZlcj0weGZmZmZmZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4 IHN0cz0wIGFsZW49OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzEgZHg3 NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMSBk eDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfU1RBTExF RApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1 YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5 MDAgc3RzPTIyIGFsZW49MCwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMx IGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYw MDAxZWMzMmE4LCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJl YWQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRw b2ludD0weGZmZmZmZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4 dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMSBk eDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAw IHhmZXI6IApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1 ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1 Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAx YjBlOGQ4LCBuZnJhbWVzPTEsIGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0w eGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRy ZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBl bmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAg a2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUw MCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3RhcnRfY2I6MjI4NTogc3RhcnQKTm92IDI4IDE0OjQ3 OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9O T1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxs YmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCBlbmRwb2ludD0w eGZmZmZmZjAwMDFiMGU4ZDggc3RzPTAgYWxlbj04LCBzbGVuPTgsIGFmcm09MSwgbmZybT0xCk5v diAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQK Tm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBl cnI9VVNCX0VSUl9TVEFMTEVECk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX2Nh bGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50 PTB4ZmZmZmZmMDAyMTIxNjkwMCBzdHM9MjIgYWxlbj0wLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09 MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5 OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwg bmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1 bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBlZGVzYz0weGZmZmZmZjAw MDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4ODUK Tm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0w eGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1 c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6 IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGRkNjcwLCBlbmRw b2ludD0weGZmZmZmZjAwMDFiMGU4ZDgsIG5mcmFtZXM9MSwgZGlyPXdyaXRlCk5vdiAyOCAxNDo0 NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYw MDAxYjBlOGQ4IGVkZXNjPTB4ZmZmZmZmMDAwMWIwZWRlNCBpc29jX25leHQ9MCB0b2dnbGVfbmV4 dD0wIGJFbmRwb2ludEFkZHJlc3M9MHgwMApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDog dXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCB4ZmVyOiAKTm92IDI4 IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3Yg MjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdGFydF9jYjoyMjg1OiBz dGFydApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIy MTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAg a2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAw NGRkNjcwIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBzdHM9MCBhbGVuPTgsIHNsZW49OCwg YWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9z dGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFu c2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX1NUQUxMRUQKTm92IDI4IDE0OjQ3OjMxIGR4NzUw MCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjAw MDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0yMiBhbGVuPTAsIHNsZW49 NjQsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3Ry YW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCwgZW5kcG9pbnQ9MHhm ZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5vdiAyOCAxNDo0NzozMSBkeDc1 MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAw IGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRw b2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBf cXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMx IGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6 MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZm ZjgwMDA0ZGQ2NzAsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9 d3JpdGUKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBl bmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2Nf bmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0Nzoz MSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBl OGQ4IHhmZXI6IApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVy OjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVy X3N0YXJ0X2NiOjIyODU6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2Jk X3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4 IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4Mjog eGZlcj0weGZmZmZmZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHN0cz0w IGFsZW49OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtl cm5lbDogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0 ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzEg ZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX1NUQUxM RUQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzEgZHg3NTAw IGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAw MWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3RzPTIyIGFsZW49MCwgc2xlbj02 NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IApOb3YgMjgg MTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0w eGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0x LCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0Nzoz MSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIx MjE2OTAwCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiBlZGVzYz0weGZmZmZmZjAwMDFi MmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtl cm5lbDogYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVs OiAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2lu dD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVs OiAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBl bnRlcgpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMSBkeDc1 MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRk ZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4LCBuZnJhbWVzPTEsIGRpcj13cml0ZQpO b3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50 PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAg dG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMxIGR4NzUw MCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZl cjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4Njog ZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3RhcnRf Y2I6MjI4NTogc3RhcnQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNm ZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6 MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4 ZmZmZmZmODAwMDRkZDY3MCBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggc3RzPTAgYWxlbj04 LCBzbGVuPTgsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1 c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6 IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9TVEFMTEVECk5vdiAyOCAxNDo0 NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9 MHhmZmZmZmYwMDAxZWMzMmE4IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCBzdHM9MjIgYWxl bj0wLCBzbGVuPTY0LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5l bDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVu ZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6 NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZm MDAyMTIxNjkwMCBlZGVzYz0weGZmZmZmZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25l eHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4ODUKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6 IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAy OCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92 IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhm ZXI9MHhmZmZmZmY4MDAwNGRkNjcwLCBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDgsIG5mcmFt ZXM9MSwgZGlyPXdyaXRlCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9l bmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IGVkZXNjPTB4ZmZmZmZmMDAwMWIw ZWRlNCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9MHgwMApOb3Yg MjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZm ZmZmMDAwMWIwZThkOCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRf cGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNi ZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBzdD0wCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2Vy bmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDE0OCwg ZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4LCBuZnJhbWVzPTEsIGRpcj13cml0ZQpOb3YgMjgg MTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZm ZmZmMDAwMWIwZThkOCBlZGVzYz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xl X25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJu ZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5v diAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIK Tm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3RhcnRfY2I6MjI4 NTogc3RhcnQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9u ZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzEgZHg3 NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZm ODAwMDRkZDY3MCBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggc3RzPTAgYWxlbj04LCBzbGVu PTgsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3Bp cGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRf cGlwZV9zdGFydDoyNDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNi ZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAy OCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVT Ql9FUlJfU1RBTExFRApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFj dXNiZGtfd19jYXJhcHBsbGJlcl9hY2tzdWI6X3dyYTJwcGU1ODJyX3M6IHh1YjpmZXI9MjU4Mjow IHhmeGZmZmVyPWZmZjAwMDEweGZlYzMyZmZmZmY4MGE4IDAwNGRlbmRkMTQ4cG9pIGVubnQ9ZHBv aW50PTB4ZmZmZmZmMHhmMDAyMWZmZjIxNmZmMDA5MDAgMDFic3RzMGU4PWQ4IHMyMiB0cz1hbGUw IG49MGFsZSwgc249bGVuPTgsIDY0c2xlLCBhbj04ZnJtLCBhPTEsZnJtIG5mPTEscm09IG5mMXJt PTEKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEz OTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMzMmE4LCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAs IG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRf ZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMApOb3YgMjgg MTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4 dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMSBk eDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAw IHhmZXI6IApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1 ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1 Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAx YjBlOGQ4LCBuZnJhbWVzPTEsIGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0w eGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRy ZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBl bmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAg a2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUw MCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MApOb3YgMjggMTQ6NDc6 MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZm ZjgwMDA0ZGQxNDgsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9 d3JpdGUKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBl bmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2Nf bmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0Nzoz MSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBl OGQ4IHhmZXI6IApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVy OjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVy X3N0YXJ0X2NiOjIyODU6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2Jk X3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4 IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4Mjog eGZlcj0weGZmZmZmZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHN0cz0w IGFsZW49OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtl cm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMSBkeDc1MDAg a2VybmVsOiAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoy NDQ4OiBzdGFydApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9k b25lOjIyMTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMSBk eDc1MDAga2VybmVsOiAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNm ZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9TVEFMTEVECk5vdiAyOCAxNDo0NzozMSBkeDc1MDAg a2VybmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1OHUyOiBzYmR4ZmVyX2NhPWxsYjBh Y2tfeGZmd3JhZmZmZnBwZTAwMHJfc3UxZWMzYjoyYTgyNSBlbjgyOmRwb2kgeGZudD1lcj0weGZm MHhmZmZmZmZmZmYwMDJmODAxMjEwMDQ2OTBkZDEwIHM0OCB0cz1lbmQyMnBvaSBhbG50PWVuPTAs IHMweGZsZW5mZmY9NmZmMDQsIDAwMWFmcm1iMGU4PTFkOCAsIG5mc3RzPXJtPTAgMWFsZW49OCwg c2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNi ZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjAwMDFlYzMyYTgsIGVuZHBvaW50 PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9cmVhZApOb3YgMjggMTQ6NDc6MzEg ZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1OiBzdD0xCk5vdiAyOCAx NDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZm ZmYwMDIxMjE2OTAwCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiBlZGVzYz0weGZmZmZm ZjAwMDFiMmRlNDAgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4 ODUKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2lu dD0weGZmZmZmZjAwMjEyMTY5MDAgeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVs OiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJu ZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmY4MDAwNGRkNjcwLCBl bmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDgsIG5mcmFtZXM9MSwgZGlyPXdyaXRlCk5vdiAyOCAx NDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZm ZmYwMDAxYjBlOGQ4IGVkZXNjPTB4ZmZmZmZmMDAwMWIwZWRlNCBpc29jX25leHQ9MCB0b2dnbGVf bmV4dD0wIGJFbmRwb2ludEFkZHJlc3M9MHgwMApOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCB4ZmVyOiAKTm92 IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpO b3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDogdXNiZF9kb19yZXF1ZXN0X2NhbGxiYWNrOjk1 OiBzdD0wCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1p dDoxMzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDE0OCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBl OGQ4LCBuZnJhbWVzPTEsIGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzEgZHg3NTAwIGtlcm5lbDog dXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0weGZm ZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNz PTB4MDAKTm92IDI4IDE0OjQ3OjMxIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRw b2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMSBkeDc1MDAga2Vy bmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBr ZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3RhcnRfY2I6MjI4NTogc3RhcnQKTm92IDI4IDE0OjQ3OjMy IGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JN QUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFj a193cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCBlbmRwb2ludD0weGZm ZmZmZjAwMDFiMGU4ZDggc3RzPTAgYWxlbj04LCBzbGVuPTgsIGFmcm09MSwgbmZybT0xCk5vdiAy OCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQKTm92 IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBzdGFydApO b3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVy cj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVs OiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfU1RBTExFRApOb3YgMjggMTQ6 NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYnVhY3Nia2Rfd19jYWxsYmFja3JfYXdycHBh cGVycGVfcnNfdXNiOnViOjI1ODIyNTo4MiA6eCBmeGVmcmVyPT0wMHh4ZmZmZmZmZmZmZmZmODAw MDAwNGQwMWRlMWM0ODMgMmVhbjhkIHBlb25pZG5wdD1vaW50PTB4ZmYwZmZmeGYwZjBmMDFmYmYw ZmVmODBkMDgyMSAyczF0NnM5PTAwMCAgc2F0bHNlbj09OCwyIDJzIGxhZWxuPWU4bj0sIDBhZixy IG1zPWxlbjE9LCA2bmY0cixtID1hMWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMyIGR4NzUw MCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MQpOb3YgMjggMTQ6NDc6 MzIgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZm ZjAwMDFlYzMyYTgsIGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCwgbmZyYW1lcz0xLCBkaXI9 cmVhZApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMiBkeDc1 MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAw IGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRw b2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBf cXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMy IGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6 MzIgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZm ZjgwMDA0ZGQ2NzAsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9 d3JpdGUKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBl bmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2Nf bmV4dD0wIHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0Nzoz MiBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBl OGQ4IHhmZXI6IApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVy OjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVy X3N0YXJ0X2NiOjIyODU6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2Jk X3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4 IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4Mjog eGZlcj0weGZmZmZmZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHN0cz0w IGFsZW49OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtl cm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMiBkeDc1MDAg a2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfU1RBTExFRApOb3Yg MjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193cmFwcGVyX3N1YjoyNTgy OiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAgc3Rz PTIyIGFsZW49MCwgc2xlbj02NCwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMyIGR4NzUw MCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYwMDAxZWMz MmE4LCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJlYWQKTm92 IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2ludD0w eGZmZmZmZjAwMjEyMTY5MDAgZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRv Z2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMiBkeDc1MDAg a2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6 IApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVu dGVyCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDox Mzk5OiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4 LCBuZnJhbWVzPTEsIGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNi X2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVzYz0weGZmZmZm ZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4 MDAKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2lu dD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVs OiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJu ZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFjazo5NTogc3Q9MApOb3YgMjggMTQ6NDc6MzIgZHg3 NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXQ6MTM5OTogeGZlcj0weGZmZmZmZjgwMDA0 ZGQxNDgsIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUK Tm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBlbmRwb2lu dD0weGZmZmZmZjAwMDFiMGU4ZDggZWRlc2M9MHhmZmZmZmYwMDAxYjBlZGU0IGlzb2NfbmV4dD0w IHRvZ2dsZV9uZXh0PTAgYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMiBkeDc1 MDAga2VybmVsOiB1c2JfZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHhm ZXI6IApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6 IGVudGVyCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N0YXJ0 X2NiOjIyODU6IHN0YXJ0Ck5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5z ZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9STUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3 OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0w eGZmZmZmZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4IHN0cz0wIGFsZW49 OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDog Ck5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3Rh cnQKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9zdGFydDoyNDQ4OiBz dGFydApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIy MTU6IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAg a2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfU1RBTExFRApOb3Yg MjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9jdWFsbHNiZGJhY2tfY2FsX3dybGJhYXBw ZWNrX3dyX3NyYXB1YjpwZXJfMjVzdWI4Mjo6IHhmMjVlcj04MjogeGZlMHhmcj1mZmZmZjAwMDFl YzMyYTgwIGVueGZmZmRwb2ZmZmludD04MDAwNGRkMHgxNDhmZmZmIGVuZGZmMHBvaTAyMW50PTIx NjkwMCBzMHhmdHM9ZmZmMjJmZjAgYWwwMDFiZW49MGU4MCxkOCAgc2xlc3Rzbj09MDY0LCBhbGUg YWZybj1tPTgsIDEsIHNsZW5mcm49OG09MSwgYWZybT0xLCBuZnJtPTEKTm92IDI4IDE0OjQ3OjMy IGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfc3VibWl0OjEzOTk6IHhmZXI9MHhmZmZmZmYw MDAxZWMzMmE4LCBlbmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAsIG5mcmFtZXM9MSwgZGlyPXJl YWQKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxsYmFj azo5NTogc3Q9MQpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBfZW5kcG9p bnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtl cm5lbDogZWRlc2M9MHhmZmZmZmYwMDAxYjJkZTQwIGlzb2NfbmV4dD0wIHRvZ2dsZV9uZXh0PTAg YkVuZHBvaW50QWRkcmVzcz0weDg1Ck5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2Jf ZHVtcF9xdWV1ZTogZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHhmZXI6IApOb3YgMjggMTQ6 NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAx NDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4 ZmZmZmZmODAwMDRkZDY3MCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4LCBuZnJhbWVzPTEs IGRpcj13cml0ZQpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0Nzoz MiBkeDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9pbnQ9MHhmZmZmZmYwMDAx YjBlOGQ4Ck5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiBlZGVzYz0weGZmZmZmZjAwMDFi MGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRBZGRyZXNzPTB4MDAKTm92 IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5l bDogdXNiX2R1bXBfcXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCB4ZmVyOiAKTm92 IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5l bDogdXNiZF9waXBlX2VudGVyOjE1ODY6IGVudGVyCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2Vy bmVsOiAKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfZG9fcmVxdWVzdF9jYWxs YmFjazo5NTogc3Q9MApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0 NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZm ZmZmODAwMDRkZDE0OCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDAxYjBlOGQ4LCBuZnJhbWVzPTEsIGRp cj13cml0ZQpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMiBk eDc1MDAga2VybmVsOiB1c2JfZHVtcF9lbmRwb2ludDogZW5kcG9hbnQ9MHhmZmZmZmYwMDAxYjBl OGQ4Ck5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiBlZGVzYz0weGZmZmZmZjAwMDFiMGVk ZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5l bDogYkVuZHBvaW50QWRkcmVzcz0weDAwCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiAK Tm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVlOiBlbmRwb2ludD0w eGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiAK Tm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRl cgpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAg a2VybmVsOiB1c2JkX3RyYW5zZmVyX3N0YXJ0X2NiOjIyODU6IHN0YXJ0Ck5vdiAyOCAxNDo0Nzoz MiBkeDc1MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX2RvbmU6MjIxNTogZXJyPVVTQl9FUlJfTk9S TUFMX0NPTVBMRVRJT04KTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJh Y2tfd3JhcHBlcl9zdWI6MjU4MjogeGZlcj0weGZmZmZmZjgwMDA0ZGQ2NzAgZW5kcG9pbnQ9MHhm ZmZmZmYwMDAxYjBlOGQ4IHN0cz0wIGFsZW49OCwgc2xlbj04LCBhZnJtPTEsIG5mcm09MQpOb3Yg MjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9waXBlX3N0YXJ0OjI0NDg6IHN0YXJ0Ck5v diAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX3BpcGVfc3RhcnQ6MjQ0ODogc3RhcnQK Tm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBl cnI9VVNCX0VSUl9OT1JNQUxfQ09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5l bDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6IGVycj1VU0JfRVJSX1NUQUxMRUQKTm92IDI4IDE0 OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYmRfY2FsbGJhY2tfd3JhcHBlcl9zdWI6MjU4MjogeGZl cj0weGZmZmZmZjAwMDFlYzMyYTggZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwIHN0cz0yMiBh bGVuPTAsIHNsZW49NjQsIGFmcm09MSwgbmZybT0xdXNiZF9jYWxsYmFja193cmFwcGVyX3N1Yjoy NTgyOiB4ZmVyPTB4ZmZmZmZmODAwMDRkZDE0OCBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDgg c3RzPTAgYWxlbj04LCBzbGVuPTgsIGFmcm09MSwgbmZybT0xCk5vdiAyOCAxNDo0NzozMiBkeDc1 MDAga2VybmVsOiB1c2JkX3RyYW5zZmVyX3N1Ym1pdDoxMzk5OiB4ZmVyPTB4ZmZmZmZmMDAwMWVj MzJhOCwgZW5kcG9pbnQ9MHhmZmZmZmYwMDIxMjE2OTAwLCBuZnJhbWVzPTEsIGRpcj1yZWFkCk5v diAyOCAxNDo0NzozMiBkeDc1MDAga2VybmVsOiB1c2JkX2RvX3JlcXVlc3RfY2FsbGJhY2s6OTU6 IHN0PTEKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX2VuZHBvaW50OiBl bmRwb2ludD0weGZmZmZmZjAwMjEyMTY5MDAKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6 IGVkZXNjPTB4ZmZmZmZmMDAwMWIyZGU0MCBpc29jX25leHQ9MCB0b2dnbGVfbmV4dD0wIGJFbmRw b2ludEFkZHJlc3M9MHg4NQpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiX2R1bXBf cXVldWU6IGVuZHBvaW50PTB4ZmZmZmZmMDAyMTIxNjkwMCB4ZmVyOiAKTm92IDI4IDE0OjQ3OjMy IGR4NzUwMCBrZXJuZWw6IHVzYmRfcGlwZV9lbnRlcjoxNTg2OiBlbnRlcgpOb3YgMjggMTQ6NDc6 MzIgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdWJtaXR1c2I6ZF90MXJhbjM5c2Y5ZTpy IF94c2Z0ZXJvPXA6MDE2eGY5MWY6ZiBmY2Zsb2ZzOGUwMDA0ZGQ2NzAsIGVuZHBvaW50PTB4ZmZm ZmZmMDAwMWIwZThkOCwgbmZyYW1lcz0xLCBkaXI9d3JpdGUKTm92IDI4IDE0OjQ3OjMyIGR4NzUw MCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9DQU5DRUxMRUQK Tm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtl cm5lbDogdXNiX2R1bXBfZW5kcG9pbnQ6IGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBlZGVz Yz0weGZmZmZmZjAwMDFiMGVkZTQgaXNvY19uZXh0PTAgdG9nZ2xlX25leHQ9MCBiRW5kcG9pbnRB ZGRyZXNzPTB4MDAKTm92IDI4IDE0OjQ3OjMyIGR4NzUwMCBrZXJuZWw6IHVzYl9kdW1wX3F1ZXVl OiBlbmRwb2ludD0weGZmZmZmZjAwMDFiMGU4ZDggeGZlcjogCk5vdiAyOCAxNDo0NzozMiBkeDc1 MDAga2VybmVsOiB1c2JkX3BpcGVfZW50ZXI6MTU4NjogZW50ZXIKTm92IDI4IDE0OjQ3OjMyIGR4 NzUwMCBrZXJuZWw6IHVzYmRfdHJhbnNmZXJfZG9uZToyMjE1OiBlcnI9VVNCX0VSUl9OT1JNQUxf Q09NUExFVElPTgpOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF9jYWxsYmFja193 cmFwcGVyX3N1YjoyNTgyOiB4ZmVyPTB4ZmZmZmZmMDAwMWVjMzJhOCBlbmRwb2ludD0weGZmZmZm ZjAwMjEyMTY5MDAgc3RzPTUgYWxlbj0wLCBzbGVuPTY0LCBhZnJtPTAsIG5mcm09MQpOb3YgMjgg MTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9zdGFydF9jYjoyMjg1OiBzdGFy dApOb3YgMjggMTQ6NDc6MzIgZHg3NTAwIGtlcm5lbDogdXNiZF90cmFuc2Zlcl9kb25lOjIyMTU6 IGVycj1VU0JfRVJSX05PUk1BTF9DT01QTEVUSU9OCk5vdiAyOCAxNDo0NzozMiBkeDc1MDAga2Vy bmVsOiB1c2JkX2NhbGxiYWNrX3dyYXBwZXJfc3ViOjI1ODI6IHhmZXI9MHhmZmZmZmY4MDAwNGRk NjcwIGVuZHBvaW50PTB4ZmZmZmZmMDAwMWIwZThkOCBzdHM9MCBhbGVuPTgsIHNsZW49OCwgYWZy bT0xLCBuZnJtPTEK --------_4B10C96F00000000DA8D_MULTIPART_MIXED_-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 28 13:09:09 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3904D106566B; Sat, 28 Nov 2009 13:09:09 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay001.isp.belgacom.be (mailrelay001.isp.belgacom.be [195.238.6.51]) by mx1.freebsd.org (Postfix) with ESMTP id 803B78FC13; Sat, 28 Nov 2009 13:09:08 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAGapEEtR8EdJ/2dsb2JhbACBTdB8hDEE Received: from 73.71-240-81.adsl-dyn.isp.belgacom.be (HELO kalimero.atlascopco.be) ([81.240.71.73]) by relay.skynet.be with ESMTP; 28 Nov 2009 13:39:39 +0100 Received: from kalimero.atlascopco.be (kalimero.atlascopco.be [127.0.0.1]) by kalimero.atlascopco.be (8.14.3/8.14.3) with ESMTP id nASCcruV002359; Sat, 28 Nov 2009 13:39:08 +0100 (CET) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: Maxim Sobolev Date: Sat, 28 Nov 2009 13:38:50 +0100 User-Agent: KMail/1.9.10 References: <4B1041EB.9020109@sippysoft.com> In-Reply-To: <4B1041EB.9020109@sippysoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911281338.53430.tijl@coosemans.org> Cc: FreeBSD Hackers , stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 13:09:09 -0000 On Friday 27 November 2009 22:17:31 Maxim Sobolev wrote: > I am trying to figure out why java fails to start with 1024MB of heap > on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are > set to 2GB. Here is my limits: > > Resource limits (current): > cputime infinity secs > filesize infinity kB > datasize 2097152 kB > stacksize 65536 kB > coredumpsize infinity kB > memoryuse infinity kB > memorylocked infinity kB > maxprocesses 5547 > openfiles 20000 > sbsize infinity bytes > vmemoryuse infinity kB > > Running ktrace I see: > > 9154 java CALL mmap(0,0x44000000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,0xffffffff,0,0) > 9154 java RET mmap -1 errno 12 Cannot allocate memory > 9154 java CALL write(0x1,0xbf9fe378,0x2b) > 9154 java GIO fd 1 wrote 43 bytes > "Error occurred during initialization of VM On i386 a process has only 3GiB of address space. If you reserve 2GiB for datasize (sbrk), there's less than 1GiB available for mmap. Unless you have a program that still uses sbrk and needs 2GiB you should make maxdsiz much smaller. Since FreeBSD 7 malloc can use mmap besides sbrk so you can set maxdsiz to a really small value if you want to. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 28 13:57:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F9BE1065670 for ; Sat, 28 Nov 2009 13:57:59 +0000 (UTC) (envelope-from mcfusaro@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 249978FC08 for ; Sat, 28 Nov 2009 13:57:58 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so678159eye.9 for ; Sat, 28 Nov 2009 05:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VTdMP5KoINvI+Nb50YnXBda1+SqOQC86REisV6e7SF4=; b=VySkSr5/ZyP0AkFY7e4563ZRxBe3awR5JrGXt3MJC3rHxBRnMVOBLU5sCT9jTJBRdD oQGJ5CU5OqfrmuuNSS6aXp5XuZJ+Pr7T0fHZKmSzaNdSw6s1rrD1k6j4QXA8JgnaipOB W1lXbkyei4XAp7Miz5JvYFj4Il47iYPo4HcSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PhOS+8As+eFcUspb6f+efoBl97ABMF+R+OLYgnBfcCIQ5uK9zEWBs1iqUw0bDzAxIs LFpeLSEE/o2sts/eSd0nO23iePr8YC2HVVNNjMYTVYfFCJZeY92IrXrb9NyEznAynYs7 l2UUdavvFYhp+y66Y1yWHQmH0yhluC5KVuCQ8= MIME-Version: 1.0 Received: by 10.216.89.200 with SMTP id c50mr708170wef.137.1259415034758; Sat, 28 Nov 2009 05:30:34 -0800 (PST) In-Reply-To: <4B109474.6050405@twisted.net> References: <20091127203338.GA70392@twisted.net> <20091127210705.GA72043@twisted.net> <20091127214256.GB15526@icarus.home.lan> <4B109474.6050405@twisted.net> Date: Sat, 28 Nov 2009 14:30:34 +0100 Message-ID: <60f6f5610911280530y2cb7350vd13e4919c9bde46b@mail.gmail.com> From: Massimo Fusaro To: troy@twisted.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 installworld fails in /usr/src/lib/csu/i386-elf cc: not found X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 13:57:59 -0000 2009/11/28 Troy : > Tried to move make.conf aside and it did not help. I am not using -j in t= he > installworld command. =A0Any other thoughts? I'm in a bind with my upgrad= e > without being able to do 'make installworld' > > > > On 11/27/2009 3:42 PM, Jeremy Chadwick wrote: >> >> On Fri, Nov 27, 2009 at 03:07:05PM -0600, Troy wrote: >> >>> >>> cc is installed and I can execute it. =A0I don't have any unique cc >>> variables being set in make.conf either. >>> >> >> Shot in the dark: are you using the -j argument during "make >> installworld" (not buildworld)? =A0If so, don't do that. >> >> Otherwise, try moving make.conf aside and see if things improve. =A0One >> thing at a time... =A0:-) >> >> > The cc that installworld is trying to execute is not the one in /usr/bin but that generated by buildworld, so something went wrong with that phase. Remove /usr/obj/* and then restart buildworld, without -j --=20 -Max From owner-freebsd-stable@FreeBSD.ORG Sat Nov 28 15:41:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4C02106566C for ; Sat, 28 Nov 2009 15:41:08 +0000 (UTC) (envelope-from gausus@gausus.net) Received: from dagobah.intersec.pl (dagobah.intersec.pl [91.192.226.10]) by mx1.freebsd.org (Postfix) with ESMTP id 623DB8FC19 for ; Sat, 28 Nov 2009 15:41:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dagobah.intersec.pl (Postfix) with ESMTP id 95D3D254002 for ; Sat, 28 Nov 2009 16:41:06 +0100 (CET) X-Virus-Scanned: amavisd-new at intersec.pl Received: from dagobah.intersec.pl ([127.0.0.1]) by localhost (dagobah.intersec.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qhUj7CnWD-w for ; Sat, 28 Nov 2009 16:41:01 +0100 (CET) Received: from loken.local (69-dzi-33.acn.waw.pl [85.222.122.69]) by dagobah.intersec.pl (Postfix) with ESMTP id D279C254001 for ; Sat, 28 Nov 2009 16:41:01 +0100 (CET) Message-ID: <4B11448D.9050304@gausus.net> Date: Sat, 28 Nov 2009 16:41:01 +0100 From: Maciej Jan Broniarz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: problem with freebsd-update on 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 15:41:08 -0000 Hello, I am trying to upgrade my servers to 8.0-STABLE. All my three machines run 8.0-PRELEASE. On two of them freebsd-update upgrade went well, still on the third one I ran into problems: # freebsd-update upgrade -r 8.0-RELEASE Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 8.0-PRERELEASE from update5.FreeBSD.org... failed. Fetching metadata signature for 8.0-PRERELEASE from update4.FreeBSD.org... failed. Fetching metadata signature for 8.0-PRERELEASE from update2.FreeBSD.org... failed. What might be the issue? Network is configured correctly and I have network conectivity. I am able to for eg. run a cvsup update or install a package via pkg_add -r. Still, freebsd-update doesnt work. Thanks for any help, Regards, mjb From owner-freebsd-stable@FreeBSD.ORG Sat Nov 28 21:43:31 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1CEA1065679; Sat, 28 Nov 2009 21:43:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6478FC19; Sat, 28 Nov 2009 21:43:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id nASLhUtV072662; Sat, 28 Nov 2009 16:43:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id nASLhUtD072661; Sat, 28 Nov 2009 21:43:30 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Nov 2009 21:43:30 GMT Message-Id: <200911282143.nASLhUtD072661@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 21:43:31 -0000 TB --- 2009-11-28 20:35:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-28 20:35:54 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2009-11-28 20:35:54 - cleaning the object tree TB --- 2009-11-28 20:36:08 - cvsupping the source tree TB --- 2009-11-28 20:36:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2009-11-28 20:37:27 - building world TB --- 2009-11-28 20:37:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-28 20:37:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-28 20:37:27 - TARGET=powerpc TB --- 2009-11-28 20:37:27 - TARGET_ARCH=powerpc TB --- 2009-11-28 20:37:27 - TZ=UTC TB --- 2009-11-28 20:37:27 - __MAKE_CONF=/dev/null TB --- 2009-11-28 20:37:27 - cd /src TB --- 2009-11-28 20:37:27 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 28 20:37:27 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 28 21:33:16 UTC 2009 TB --- 2009-11-28 21:33:16 - generating LINT kernel config TB --- 2009-11-28 21:33:16 - cd /src/sys/powerpc/conf TB --- 2009-11-28 21:33:16 - /usr/bin/make -B LINT TB --- 2009-11-28 21:33:16 - building LINT kernel TB --- 2009-11-28 21:33:16 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-28 21:33:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-28 21:33:16 - TARGET=powerpc TB --- 2009-11-28 21:33:16 - TARGET_ARCH=powerpc TB --- 2009-11-28 21:33:16 - TZ=UTC TB --- 2009-11-28 21:33:16 - __MAKE_CONF=/dev/null TB --- 2009-11-28 21:33:16 - cd /src TB --- 2009-11-28 21:33:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 28 21:33:16 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/copyinout.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/interrupt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/mmu_oea.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/mmu_oea64.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/mp_cpudep.c cc1: warnings being treated as errors /src/sys/powerpc/aim/mp_cpudep.c:210: warning: function declaration isn't a prototype *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-28 21:43:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-28 21:43:30 - ERROR: failed to build lint kernel TB --- 2009-11-28 21:43:30 - 3235.62 user 595.20 system 4056.18 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full