From owner-freebsd-fs@FreeBSD.ORG Sun Oct 3 09:06:54 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83605106564A; Sun, 3 Oct 2010 09:06:54 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id D002C8FC13; Sun, 3 Oct 2010 09:06:53 +0000 (UTC) Received: by ewy22 with SMTP id 22so1928991ewy.13 for ; Sun, 03 Oct 2010 02:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=qwjUN0An4Evkd2f+1jnP3TJTlauzOlGN2iPgeiv1xx0=; b=medQKosfAVv36E1n21wnZ80RkvDKJgICGHX9GpSfKBhzn5rffigr6yCWnbP9e4M9Mh 3imskcaN9mFstPoj5yvpB8qf7bVpQbWLPhsaSWd5kV1CgSzGww4t01qu5hbMpgXptv0Z aLSJV6ZXiY5w8gtePqcMbs8hP93VTH26PUasU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=hb2XbBkr4Zh+uhz7TVCtTrCPTgXVP8tN9odT0K0/vkzEt9uI9M5BurpkkZrZTaLibP 7HaWMB98067YCqeiPBMYoXZqXw9CTY8MVCp3/61q8smZvvt/4vNmQY/lJb/924ScOGnD p3neNv1jBbitZNPKNEUH2XxLa7eqI6poU8mqU= Received: by 10.213.15.140 with SMTP id k12mr5322993eba.15.1286096812779; Sun, 03 Oct 2010 02:06:52 -0700 (PDT) Received: from localhost ([95.69.162.97]) by mx.google.com with ESMTPS id v8sm5049746eeh.8.2010.10.03.02.06.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 03 Oct 2010 02:06:51 -0700 (PDT) From: Mikolaj Golub To: freebsd-fs@freebsd.org References: <86hbh44wgl.fsf@kopusha.home.net> <86aamw4l42.fsf@kopusha.home.net> X-Comment-To: Mikolaj Golub Date: Sun, 03 Oct 2010 12:06:53 +0300 In-Reply-To: <86aamw4l42.fsf@kopusha.home.net> (Mikolaj Golub's message of "Sat, 02 Oct 2010 19:26:05 +0300") Message-ID: <86ocbbir0y.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: pjd@freebsd.org Subject: Re: hastd: assertion (res->hr_event != NULL) fails in secondary on split-brain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 09:06:54 -0000 --=-=-= On Sat, 02 Oct 2010 19:26:05 +0300 Mikolaj Golub wrote to Mikolaj Golub: MG> What do you think about the attached patch? Here is updated version of the patch :-) 1) I didn't notice previously that in the different parts kill() was called with different signals. So in the new version I have child_kill(res, sig) instead of child_kill(res); 2) Testing hastd I faced another issue (which is not related to my patch, and shows up also with unpatched hastd. It is easy to hang hastd running the following test: for i in `jot 1000`; do hastctl role primary storage hastctl role secondary storage done Other host should be configured as secondary and should have some fix for the problem described initially in this thread (avoid double close of res->hr_event) so secondary would not crash on assertion. hastd hangs when switching to secondary, killing primary worker and waiting for it: root 1631 0.0 0.5 11244 2364 ?? Is 12:18PM 0:00.37 /sbin/hastd -ddd root 1869 0.0 7.0 49004 35700 ?? I 12:37PM 0:01.42 hastd: storage (primary) (hastd) root 1937 0.0 0.3 10924 1764 ?? I 12:37PM 0:00.02 /sbin/hastctl role secondary storage lolek# gdb /usr/obj/usr/src/sbin/hastd/hastd 1631 [Switching to Thread 28404140 (LWP 100045)] 0x282ba689 in wait4 () from /lib/libc.so.7 (gdb) bt #0 0x282ba689 in wait4 () from /lib/libc.so.7 #1 0x282912a3 in waitpid () from /lib/libc.so.7 #2 0x280df272 in waitpid () from /lib/libthr.so.3 #3 0x0804c6d4 in control_set_role_common (cfg=0x28419600, nvout=0x2850e0d0, role=3 '\003', res=0x284eb500, name=0x284a3442 "storage", no=0) at /usr/src/sbin/hastd/control.c:115 #4 0x0804d001 in control_handle (cfg=0x28419600) at /usr/src/sbin/hastd/control.c:356 #5 0x08050555 in main_loop () at /usr/src/sbin/hastd/hastd.c:671 #6 0x08050a7f in main (argc=0, argv=0xbfbfed04) at /usr/src/sbin/hastd/hastd.c:784 (gdb) fr 3 #3 0x0804c6d4 in control_set_role_common (cfg=0x28419600, nvout=0x2850e0d0, role=3 '\003', res=0x284eb500, name=0x284a3442 "storage", no=0) at /usr/src/sbin/hastd/control.c:115 115 } else if (waitpid(res->hr_workerpid, NULL, 0) != (gdb) list 110 if (res->hr_workerpid != 0) { 111 if (kill(res->hr_workerpid, SIGTERM) < 0) { 112 pjdlog_errno(LOG_WARNING, 113 "Unable to kill worker process %u", 114 (unsigned int)res->hr_workerpid); 115 } else if (waitpid(res->hr_workerpid, NULL, 0) != 116 res->hr_workerpid) { 117 pjdlog_errno(LOG_WARNING, 118 "Error while waiting for worker process %u", 119 (unsigned int)res->hr_workerpid); It looks like the worker does not die because guard_thread() is sending CONNECT event to parent and waiting for a response. lolek# gdb /usr/obj/usr/src/sbin/hastd/hastd 1869 Thread 8 (Thread 28404140 (LWP 100075)): #0 0x28301ed7 in recvfrom () from /lib/libc.so.7 #1 0x28287f52 in recv () from /lib/libc.so.7 #2 0x0805f467 in proto_common_recv (fd=10, data=0xbfbfe967 "(", size=5) at /usr/src/sbin/hastd/proto_common.c:77 #3 0x0805f8bd in sp_recv (ctx=0x2850e110, data=0xbfbfe967 "(", size=5) at /usr/src/sbin/hastd/proto_socketpair.c:185 #4 0x0805ee91 in proto_recv (conn=0x2850e100, data=0xbfbfe967, size=5) at /usr/src/sbin/hastd/proto.c:207 #5 0x0804e4ae in hast_proto_recv_hdr (conn=0x2850e100, nvp=0xbfbfe9a4) at /usr/src/sbin/hastd/hast_proto.c:308 #6 0x0804dbbc in event_send (res=0x284eb500, event=1) at /usr/src/sbin/hastd/event.c:69 #7 0x0805a411 in init_remote (res=0x284eb500, inp=0xbfbfea34, outp=0xbfbfea30) at /usr/src/sbin/hastd/primary.c:661 #8 0x0805e48a in guard_one (res=0x284eb500, ncomp=1) at /usr/src/sbin/hastd/primary.c:1912 #9 0x0805e7e9 in guard_thread (arg=0x284eb500) at /usr/src/sbin/hastd/primary.c:1977 #10 0x0805ac5f in hastd_primary (res=0x284eb500) at /usr/src/sbin/hastd/primary.c:823 #11 0x0804c743 in control_set_role_common (cfg=0x28419600, nvout=0x2850e0d0, role=2 '\002', res=0x284eb500, name=0x284a3442 "storage", no=0) at /usr/src/sbin/hastd/control.c:129 #12 0x0804d001 in control_handle (cfg=0x28419600) at /usr/src/sbin/hastd/control.c:356 #13 0x08050555 in main_loop () at /usr/src/sbin/hastd/hastd.c:671 #14 0x08050a7f in main (argc=0, argv=0xbfbfed04) at /usr/src/sbin/hastd/hastd.c:784 After changing the code so parent closes hr_event and hr_ctrl after kill() but before wait() the hang has not been observed. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=hast.child_kill.patch Index: sbin/hastd/hastd.c =================================================================== --- sbin/hastd/hastd.c (revision 213377) +++ sbin/hastd/hastd.c (working copy) @@ -94,22 +94,6 @@ g_gate_load(void) } static void -child_exit_log(unsigned int pid, int status) -{ - - if (WIFEXITED(status) && WEXITSTATUS(status) == 0) { - pjdlog_debug(1, "Worker process exited gracefully (pid=%u).", - pid); - } else if (WIFSIGNALED(status)) { - pjdlog_error("Worker process killed (pid=%u, signal=%d).", - pid, WTERMSIG(status)); - } else { - pjdlog_error("Worker process exited ungracefully (pid=%u, exitcode=%d).", - pid, WIFEXITED(status) ? WEXITSTATUS(status) : -1); - } -} - -static void child_exit(void) { struct hast_resource *res; @@ -388,8 +372,6 @@ listen_accept(void) const unsigned char *token; char laddr[256], raddr[256]; size_t size; - pid_t pid; - int status; proto_local_address(cfg->hc_listenconn, laddr, sizeof(laddr)); pjdlog_debug(1, "Accepting connection to %s.", laddr); @@ -504,26 +486,7 @@ listen_accept(void) "Worker process exists (pid=%u), stopping it.", (unsigned int)res->hr_workerpid); /* Stop child process. */ - if (kill(res->hr_workerpid, SIGINT) < 0) { - pjdlog_errno(LOG_ERR, - "Unable to stop worker process (pid=%u)", - (unsigned int)res->hr_workerpid); - /* - * Other than logging the problem we - * ignore it - nothing smart to do. - */ - } - /* Wait for it to exit. */ - else if ((pid = waitpid(res->hr_workerpid, - &status, 0)) != res->hr_workerpid) { - /* We can only log the problem. */ - pjdlog_errno(LOG_ERR, - "Waiting for worker process (pid=%u) failed", - (unsigned int)res->hr_workerpid); - } else { - child_exit_log(res->hr_workerpid, status); - } - child_cleanup(res); + child_kill(res, SIGINT); } else if (res->hr_remotein != NULL) { char oaddr[256]; @@ -678,8 +641,8 @@ main_loop(void) if (event_recv(res) == 0) continue; /* The worker process exited? */ - proto_close(res->hr_event); - res->hr_event = NULL; + if (res->hr_workerpid != 0) + child_kill(res, SIGINT); } } } Index: sbin/hastd/control.c =================================================================== --- sbin/hastd/control.c (revision 213377) +++ sbin/hastd/control.c (working copy) @@ -63,6 +63,52 @@ child_cleanup(struct hast_resource *res) res->hr_workerpid = 0; } +void +child_exit_log(unsigned int pid, int status) +{ + + if (WIFEXITED(status) && WEXITSTATUS(status) == 0) { + pjdlog_debug(1, "Worker process exited gracefully (pid=%u).", + pid); + } else if (WIFSIGNALED(status)) { + pjdlog_error("Worker process killed (pid=%u, signal=%d).", + pid, WTERMSIG(status)); + } else { + pjdlog_error("Worker process exited ungracefully (pid=%u, exitcode=%d).", + pid, WIFEXITED(status) ? WEXITSTATUS(status) : -1); + } +} + +void +child_kill(struct hast_resource *res, int sig) +{ + pid_t pid; + int status; + + assert(res->hr_workerpid != 0); + + pid = res->hr_workerpid; + + if (kill(pid, sig) < 0) { + pjdlog_errno(LOG_ERR, + "Unable to stop worker process (pid=%u)", + (unsigned int)pid); + /* + * Other than logging the problem we + * ignore it - nothing smart to do. + */ + } + child_cleanup(res); + /* Wait for it to exit. */ + if (waitpid(pid, &status, 0) != pid) { + /* We can only log the problem. */ + pjdlog_errno(LOG_ERR, + "Waiting for worker process (pid=%u) failed", + (unsigned int)pid); + } + child_exit_log(pid, status); +} + static void control_set_role_common(struct hastd_config *cfg, struct nv *nvout, uint8_t role, struct hast_resource *res, const char *name, unsigned int no) @@ -107,22 +153,8 @@ control_set_role_common(struct hastd_config *cfg, * If previous role was primary or secondary we have to kill process * doing that work. */ - if (res->hr_workerpid != 0) { - if (kill(res->hr_workerpid, SIGTERM) < 0) { - pjdlog_errno(LOG_WARNING, - "Unable to kill worker process %u", - (unsigned int)res->hr_workerpid); - } else if (waitpid(res->hr_workerpid, NULL, 0) != - res->hr_workerpid) { - pjdlog_errno(LOG_WARNING, - "Error while waiting for worker process %u", - (unsigned int)res->hr_workerpid); - } else { - pjdlog_debug(1, "Worker process %u stopped.", - (unsigned int)res->hr_workerpid); - } - child_cleanup(res); - } + if (res->hr_workerpid != 0) + child_kill(res, SIGTERM); /* Start worker process if we are changing to primary. */ if (role == HAST_ROLE_PRIMARY) Index: sbin/hastd/control.h =================================================================== --- sbin/hastd/control.h (revision 213377) +++ sbin/hastd/control.h (working copy) @@ -39,6 +39,8 @@ struct hastd_config; struct hast_resource; void child_cleanup(struct hast_resource *res); +void child_exit_log(unsigned int pid, int status); +void child_kill(struct hast_resource *res, int sig); void control_set_role(struct hast_resource *res, uint8_t role); --=-=-=-- From owner-freebsd-fs@FreeBSD.ORG Sun Oct 3 12:45:48 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CAA3106566B; Sun, 3 Oct 2010 12:45:48 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 68F578FC12; Sun, 3 Oct 2010 12:45:46 +0000 (UTC) Received: by ewy22 with SMTP id 22so1950748ewy.13 for ; Sun, 03 Oct 2010 05:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:user-agent:mime-version:content-type; bh=uX7WXshUgzn4gC4fgJJDqNeDpIQfCon/riNvUZcgq7Y=; b=F6i/omlG4pYHg2YCGq8t9p8RU4kmsrF/9Sb7jCd8ypoG1w50jO6ezmuJcAnv0JOb7H 4l4zXivbw94jJCARjFGI1zX0tqFu5xma7XITWyyKqmaNduPIuI9QGG688wht28ZgjB3o lwAxOvkM0FKcXGda0gyQ/juv04YklSUdAYxSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:user-agent:mime-version :content-type; b=wDlRXpFAYf3kQrlqKUmkZWh2UgslzdTFNRYzKmnKM3hHqQRdlI7EGrP9VO9MlqKhqf /JEkJf0jIKXBHJSgIQXQYTzErkJuhMM1kWKqf5/shbcWL552InUkdoCJsD4yNi0Yw8Y7 EcWIYW5YYAaP932dBOLx08fwIUQj0gbURh0FM= Received: by 10.14.37.10 with SMTP id x10mr4981305eea.33.1286109945529; Sun, 03 Oct 2010 05:45:45 -0700 (PDT) Received: from localhost ([95.69.162.97]) by mx.google.com with ESMTPS id v59sm5320609eeh.22.2010.10.03.05.45.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 03 Oct 2010 05:45:44 -0700 (PDT) From: Mikolaj Golub To: freebsd-fs@freebsd.org Date: Sun, 03 Oct 2010 15:45:47 +0300 Message-ID: <86hbh3igw4.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Pawel Jakub Dawidek Subject: hastd: zombies after hooks X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 12:45:48 -0000 --=-=-= Hi, After recent changes hastd does not garbage collect finished hooks leaving zombies and messages in log like below: Oct 3 18:21:05 bolek hastd[5144]: Hook is running for 1330 seconds (pid=5223, cmd=[/usr/bin/true connect storage]). This is because wait3() in hook_check() is never called (we never call hook_check(true)). Below is a patch that works for me. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=hook_check.patch Index: sbin/hastd/hastd.c =================================================================== --- sbin/hastd/hastd.c (revision 213380) +++ sbin/hastd/hastd.c (working copy) @@ -659,7 +659,7 @@ main_loop(void) assert(maxfd + 1 <= (int)FD_SETSIZE); ret = select(maxfd + 1, &rfds, NULL, NULL, &seltimeout); if (ret == 0) - hook_check(false); + hook_check(); else if (ret == -1) { if (errno == EINTR) continue; Index: sbin/hastd/hooks.c =================================================================== --- sbin/hastd/hooks.c (revision 213380) +++ sbin/hastd/hooks.c (working copy) @@ -293,7 +293,7 @@ hook_check_one(pid_t pid, int status) } void -hook_check(bool sigchld) +hook_check(void) { struct hookproc *hp, *hp2; int status; @@ -303,12 +303,10 @@ void assert(hooks_initialized); /* - * If SIGCHLD was received, garbage collect finished processes. + * Garbage collect finished processes. */ - if (sigchld) { - while ((pid = wait3(&status, WNOHANG, NULL)) > 0) - hook_check_one(pid, status); - } + while ((pid = wait3(&status, WNOHANG, NULL)) > 0) + hook_check_one(pid, status); /* * Report about processes that are running for a long time. Index: sbin/hastd/hooks.h =================================================================== --- sbin/hastd/hooks.h (revision 213380) +++ sbin/hastd/hooks.h (working copy) @@ -41,7 +41,7 @@ void hook_init(void); void hook_fini(void); void hook_check_one(pid_t pid, int status); -void hook_check(bool sigchld); +void hook_check(void); void hook_exec(const char *path, ...); void hook_execv(const char *path, va_list ap); --=-=-=-- From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 03:56:12 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC38B106566B; Mon, 4 Oct 2010 03:56:12 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAEC8FC0C; Mon, 4 Oct 2010 03:56:12 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 23AC712543B; Mon, 4 Oct 2010 12:37:26 +0900 (JST) Date: Mon, 4 Oct 2010 12:37:25 +0900 From: Daichi GOTO To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-Id: <20101004123725.65d09b9e.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 03:56:12 -0000 It looks very strange. fcntl() always fails to delete lock file and command.l_pid is always -6464. This issue is disclosed in porting Google's Japanese input system called "mozc". details follow: http://code.google.com/p/mozc/issues/detail?id=40 % uname -a FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 root@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL amd64 % My home directory on NFS server. Does anyone have any ideas? -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 05:28:33 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F09B2106566B for ; Mon, 4 Oct 2010 05:28:33 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B567A8FC15 for ; Mon, 4 Oct 2010 05:28:33 +0000 (UTC) Received: by iwn10 with SMTP id 10so1905381iwn.13 for ; Sun, 03 Oct 2010 22:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qK+IPUx355CreqOQa3BHUD675ChlcyfksF757/I/VDQ=; b=KFVqGV8qZj64Y3h1LD58Oo1HdM3SwH1m+6nMugtfdeDBBFYl+K8/JKuf0L0Q3jOVcp 2yDkUlIBpi+d21dGNhcsOluk8uvzbgJSBWLvAxPQk3s4ORs4myOnnftYQxBdfakAoBKx qJk4JTEltt3aszdCAIK5fsbfT5MMAYnrwAu3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WSUw3EKPC2FoGJRBJG7FBSu/bPwSomrJ7/vHCVOr7ozPuI4laGhm1lFsetkrAyIhFN 9M4f72q8mOrpHS3/9Lymey3QP+5+iK4jYIaKd0jdeyf8DTU4e9Nx+0raNyO4USpzWteN 7iXO07KNUk1zETOxAOFb/dZrWk2Ytqy31SV8M= MIME-Version: 1.0 Received: by 10.231.182.201 with SMTP id cd9mr9591344ibb.21.1286168712174; Sun, 03 Oct 2010 22:05:12 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.190.68 with HTTP; Sun, 3 Oct 2010 22:05:12 -0700 (PDT) In-Reply-To: <20101004123725.65d09b9e.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> Date: Sun, 3 Oct 2010 22:05:12 -0700 X-Google-Sender-Auth: QQ0cDYuvaGg3Nc64JvVHKc8Ae0M Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 05:28:34 -0000 On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO wrote: > It looks very strange. fcntl() always fails to delete lock file > and command.l_pid is always -6464. This issue is disclosed in > porting Google's Japanese input system called "mozc". > > =A0details follow: > =A0 =A0http://code.google.com/p/mozc/issues/detail?id=3D40 > > % uname -a > FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: = Thu Sep 30 10:30:06 JST 2010 =A0 =A0 root@parancell.ongs.co.jp:/usr/obj/usr= /src/sys/PARANCELL =A0amd64 > % > > My home directory on NFS server. =A0Does anyone have any ideas? I see some bad assumptions in the code: const int result =3D ::fcntl(*fd, F_SETLK, &command); if (-1 =3D=3D result) { // failed ::close(*fd); LOG(WARNING) << "already locked"; return false; // another server is already running } If the developer actually coded to POSIX expectations, he/she would be checking for EACCES/EAGAIN; there are a myriad of other issues that might be occurring with the software, as per my copy of SUSv4 (see the ERRORS section of fcntl). I would print out the strerror for that case. Providing a backtrace of the application's execution and the architecture and what version of FreeBSD you're using would be helpful. Thanks, -Garrett PS Quickly looking over this code, it has portability issues assuming that all Unix based OSes (that aren't under some Mac OSX guard) are Linux, based on the number of /proc filesystem opens and reads I see in the code. From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 05:39:47 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AD231065670 for ; Mon, 4 Oct 2010 05:39:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1368FC18 for ; Mon, 4 Oct 2010 05:39:46 +0000 (UTC) Received: by iwn10 with SMTP id 10so1916162iwn.13 for ; Sun, 03 Oct 2010 22:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=T8sJlTX6m2VXUPw3MEsCAwwXYVgfNMFwyV/D1H71fiY=; b=pkz3ha9QjaB+Oc8SjQ4+3LrbVYJWsGeIRHeJuXstAF3NRXQEjr3YqlJHAHw7n8zSJm MWCsmw51Dt/QyiqBWv+o7z8d4A5l7QvRf9SzJocZt91pB8mAjDZnGg+rYhtSr28NR3Ej wZ/Ehy2UaZMba5jdnGK2yFnKA5WuBmsUe2W8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=t3Hd8ncsIL5DWFrW9M+X2EVvLdWqaWu1zuMZSM7l9lyXMU+EDDI1vq6ru7INmj/dx3 /s1CGbzqzaRglyNo+ia4dndkOafbSlvinOTtYkwka2KRLZ/D8BPbWPaRLnNoh0jgUFIm F4Jdm/mndwrP3UDDTa26GQ3+CXYZhPVZGBvdk= MIME-Version: 1.0 Received: by 10.231.36.8 with SMTP id r8mr4848856ibd.128.1286168911251; Sun, 03 Oct 2010 22:08:31 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.190.68 with HTTP; Sun, 3 Oct 2010 22:08:31 -0700 (PDT) In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> Date: Sun, 3 Oct 2010 22:08:31 -0700 X-Google-Sender-Auth: wFNpcEJfI6OajxaH5pYis1Yk-Ic Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 05:39:47 -0000 On Sun, Oct 3, 2010 at 10:05 PM, Garrett Cooper wrote= : > On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO wrote: >> It looks very strange. fcntl() always fails to delete lock file >> and command.l_pid is always -6464. This issue is disclosed in >> porting Google's Japanese input system called "mozc". >> >> =A0details follow: >> =A0 =A0http://code.google.com/p/mozc/issues/detail?id=3D40 >> >> % uname -a >> FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257:= Thu Sep 30 10:30:06 JST 2010 =A0 =A0 root@parancell.ongs.co.jp:/usr/obj/us= r/src/sys/PARANCELL =A0amd64 >> % >> >> My home directory on NFS server. =A0Does anyone have any ideas? > > > =A0 =A0I see some bad assumptions in the code: > > =A0 =A0const int result =3D ::fcntl(*fd, F_SETLK, &command); > =A0 =A0if (-1 =3D=3D result) { =A0// failed > =A0 =A0 =A0::close(*fd); > =A0 =A0 =A0LOG(WARNING) << "already locked"; > =A0 =A0 =A0return false; =A0 // another server is already running > =A0 =A0} > > =A0 =A0If the developer actually coded to POSIX expectations, he/she > would be checking for EACCES/EAGAIN; there are a myriad of other > issues that might be occurring with the software, as per my copy of > SUSv4 (see the ERRORS section of fcntl). I would print out the > strerror for that case. > =A0 =A0Providing a backtrace of the application's execution and the > architecture and what version of FreeBSD you're using would be > helpful. > Thanks, > -Garrett > > PS Quickly looking over this code, it has portability issues assuming > that all Unix based OSes (that aren't under some Mac OSX guard) are > Linux, based on the number of /proc filesystem opens and reads I see > in the code. Sorry... missed some of the details in spite of the trees (FreeBSD version in particular). Thanks, -Garrett From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 05:49:28 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9C551065670; Mon, 4 Oct 2010 05:49:28 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id B30468FC0A; Mon, 4 Oct 2010 05:49:28 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 9A87312543B; Mon, 4 Oct 2010 14:49:27 +0900 (JST) Date: Mon, 4 Oct 2010 14:49:27 +0900 From: Daichi GOTO To: freebsd-current@freebsd.org, gcooper@FreeBSD.org, freebsd-fs@freebsd.org Message-Id: <20101004144927.36822f07.daichi@ongs.co.jp> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 05:49:29 -0000 On Sun, 3 Oct 2010 22:05:12 -0700 Garrett Cooper wrote: > On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO wrote: > > It looks very strange. fcntl() always fails to delete lock file > > and command.l_pid is always -6464. This issue is disclosed in > > porting Google's Japanese input system called "mozc". > > > >  details follow: > >    http://code.google.com/p/mozc/issues/detail?id=40 > > > > % uname -a > > FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010     root@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL  amd64 > > % > > > > My home directory on NFS server.  Does anyone have any ideas? > > > I see some bad assumptions in the code: > > const int result = ::fcntl(*fd, F_SETLK, &command); > if (-1 == result) { // failed > ::close(*fd); > LOG(WARNING) << "already locked"; > return false; // another server is already running > } > > If the developer actually coded to POSIX expectations, he/she > would be checking for EACCES/EAGAIN; there are a myriad of other It was EAGAIN, when I checked. And -6464 is very strange.... It should be -1 when it fails with EGAIN according to FreeBSD fcntl(2) manual. Repeat is easy: # cd /usr/ports/japanese/mozc-server/ # rm files/patch-server_mozc_server.cc # make WITH_DEBUG_CODE=yes install clean % mozc_server ^C --> in this timing, lock files should be deleted, but not working. % mozc_server --> so server will not run and finish soon % % cat ~/.mozc/mozc_server.log > issues that might be occurring with the software, as per my copy of > SUSv4 (see the ERRORS section of fcntl). I would print out the > strerror for that case. > Providing a backtrace of the application's execution and the > architecture and what version of FreeBSD you're using would be > helpful. > Thanks, > -Garrett -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 11:06:56 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EBA71065704 for ; Mon, 4 Oct 2010 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6233D8FC0C for ; Mon, 4 Oct 2010 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o94B6u3f065821 for ; Mon, 4 Oct 2010 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o94B6tsH065819 for freebsd-fs@FreeBSD.org; Mon, 4 Oct 2010 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Oct 2010 11:06:55 GMT Message-Id: <201010041106.o94B6tsH065819@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/151082 fs [zfs] [patch] sappend-flaged files on ZFS not working o kern/150910 fs [nfs] wsize=16384 on udp nfs mount unusable o kern/150796 fs [panic] [suj] [ufs] [softupdates] Panic on portbuild o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149855 fs [gvinum] growfs causes fsck to report errors in Filesy o kern/149495 fs [zfs] chflags sappend on zfs not working right o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149022 fs [hang] File system operations hangs with suspfs state o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/147292 fs [nfs] [patch] readahead missing in nfs client options o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/146375 fs [nfs] [patch] Typos in macro variables names in sys/fs s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c o kern/144458 fs [nfs] [patch] nfsd fails as a kld p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o kern/143345 fs [ext2fs] [patch] extfs minor header cleanups to better o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142924 fs [ext2fs] [patch] Small cleanup for the inode struct in o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs o bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135667 fs [lor] LORs causing ufs filesystem corruption on XEN Do o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp f kern/115645 fs [ffs] [snapshots] [panic] lockmgr: thread 0xc4c00d80, o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o bin/94635 fs snapinfo(8)/libufs only works for disk-backed filesyst o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 208 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 14:19:47 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7298106564A; Mon, 4 Oct 2010 14:19:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 401AF8FC13; Mon, 4 Oct 2010 14:19:46 +0000 (UTC) Received: by gyg4 with SMTP id 4so2144997gyg.13 for ; Mon, 04 Oct 2010 07:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=McWN10CyqTvEM5AfOGhXqP/g3cxPlJcAQhTJVJtmMzo=; b=C8fWBgWaCUWQZ2E/NLPi0AvJx+fE2e14Il2PC9MKEHROBnPKrcFdP2yAoxPV7JGcFm FjkCxh6Wlk8vbXQXuBm/fc++XLvSMXxSdqvWFgvHUDQbBugJdaYHdH4c+AigpDbumj1E WTu2VU3sIQPW3bOCCsTcDODeu8DB++S+SmiRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=VYMIUbyFdhog8TzI64fDLOcnC0eapYYG9gGo13dyq1y5Ni6nqP4aNcEHaxRBDpaP+p ETjs9LlwAj6CATJOKwLAC98ZPZxivvbguY/tax9lfF48Z1S6WaRaMZhTHSojbCY8kGG3 S8VXPKVWclv1egeZVxar7+QdI0NH5gvGns4Uw= MIME-Version: 1.0 Received: by 10.90.65.7 with SMTP id n7mr4683905aga.51.1286201985988; Mon, 04 Oct 2010 07:19:45 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.91.78.6 with HTTP; Mon, 4 Oct 2010 07:19:45 -0700 (PDT) In-Reply-To: <20101004144927.36822f07.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> Date: Mon, 4 Oct 2010 07:19:45 -0700 X-Google-Sender-Auth: DAbRmEHIOoaV-WdRWpRUWfJigCA Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: multipart/mixed; boundary=0016e6509cc27bfbb10491cb3c91 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 14:19:48 -0000 --0016e6509cc27bfbb10491cb3c91 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Oct 3, 2010 at 10:49 PM, Daichi GOTO wrote: > On Sun, 3 Oct 2010 22:05:12 -0700 > Garrett Cooper wrote: >> On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO wrote: >> > It looks very strange. fcntl() always fails to delete lock file >> > and command.l_pid is always -6464. This issue is disclosed in >> > porting Google's Japanese input system called "mozc". >> > >> > =A0details follow: >> > =A0 =A0http://code.google.com/p/mozc/issues/detail?id=3D40 >> > >> > % uname -a >> > FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r21325= 7: Thu Sep 30 10:30:06 JST 2010 =A0 =A0 root@parancell.ongs.co.jp:/usr/obj/= usr/src/sys/PARANCELL =A0amd64 >> > % >> > >> > My home directory on NFS server. =A0Does anyone have any ideas? >> >> >> =A0 =A0 I see some bad assumptions in the code: >> >> =A0 =A0 const int result =3D ::fcntl(*fd, F_SETLK, &command); >> =A0 =A0 if (-1 =3D=3D result) { =A0// failed >> =A0 =A0 =A0 ::close(*fd); >> =A0 =A0 =A0 LOG(WARNING) << "already locked"; >> =A0 =A0 =A0 return false; =A0 // another server is already running >> =A0 =A0 } >> >> =A0 =A0 If the developer actually coded to POSIX expectations, he/she >> would be checking for EACCES/EAGAIN; there are a myriad of other > > It was EAGAIN, when I checked. =A0And -6464 is very strange.... > It should be -1 when it fails with EGAIN according to FreeBSD > fcntl(2) manual. > > Repeat is easy: > =A0# cd /usr/ports/japanese/mozc-server/ > =A0# rm files/patch-server_mozc_server.cc > =A0# make WITH_DEBUG_CODE=3Dyes install clean > > =A0% mozc_server > =A0^C =A0 =A0--> in this timing, lock files should be deleted, but not wo= rking. > =A0% mozc_server =A0--> so server will not run and finish soon > =A0% > > =A0% cat ~/.mozc/mozc_server.log > >> issues that might be occurring with the software, as per my copy of >> SUSv4 (see the ERRORS section of fcntl). I would print out the >> strerror for that case. >> =A0 =A0 Providing a backtrace of the application's execution and the >> architecture and what version of FreeBSD you're using would be >> helpful. I'm not even getting that far. Logs attached from both runs (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 I completely blasted past the part of your reply above where you said your home directory is served up via NFS. It might be a problem if you don't have lockd running (/etc/rc.d/lockd onestatus ? It isn't enabled by default, and definitely isn't on on my machine) or the mount isn't setup with lockd on the client side (nolockd will do this on the initial mount, according to the manpage). There might be `dragons' in the nfsd code that fail to do locking properly, but I think that Rick (rmacklem@) or someone else on the list might be better at answering whether or not things work from an NFS perspective. I'd definitely divulge which version of NFS you're using as well as what your NFS server and client are running if enabling lockd both client and server side doesn't solve your problems right away. Cheers, -Garrett --0016e6509cc27bfbb10491cb3c91 Content-Type: application/octet-stream; name=mozc-server-WITHOUT_DEBUG Content-Disposition: attachment; filename=mozc-server-WITHOUT_DEBUG Content-Transfer-Encoding: base64 X-Attachment-Id: f_gevf4lv40 W2djb29wZXJAYmF5b25ldHRhIC91c3IvcG9ydHMvamFwYW5lc2UvbW96Yy1zZXJ2ZXJdJCB0cnVz cyAtZmYgbW96Y19zZXJ2ZXIKOTU3OTg6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMmYwLDB4MiwweDdm ZmZmZmZmZTMwYywweDdmZmZmZmZmZTMwMCwweDAsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IG1tYXAo MHgwLDMyNzY4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9OLC0xLDB4 MCkgPSAzNDM4MjQzMDIwOCAoMHg4MDE1YTQwMDApCjk1Nzk4OiBpc3NldHVnaWQoMHg4MDE1YTUw MTUsMHg4MDE1OWY4ZTQsMHg3ZmZmZmZmZmU5OTgsMHg4MDE2YmIwNDAsMHg1NzMxLDB4MCkgPSAw ICgweDApCjk1Nzk4OiBvcGVuKCIvZXRjL2xpYm1hcC5jb25mIixPX1JET05MWSwwNjY2KQkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBvcGVuKCIvdmFyL3J1bi9sZC1l bGYuc28uaGludHMiLE9fUkRPTkxZLDA1NykgPSAyICgweDIpCjk1Nzk4OiByZWFkKDIsIkVobnRc XkFcMFwwXDBcTV5AXDBcMFwwXE1eWlwwXDAiLi4uLDEyOCkgPSAxMjggKDB4ODApCjk1Nzk4OiBs c2VlaygyLDB4ODAsU0VFS19TRVQpCQkJID0gMTI4ICgweDgwKQo5NTc5ODogcmVhZCgyLCIvbGli Oi91c3IvbGliOi91c3IvbGliL2NvbXBhdDovdSIuLi4sMTU0KSA9IDE1NCAoMHg5YSkKOTU3OTg6 IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCjk1Nzk4OiBhY2Nlc3MoIi9saWIvbGliY3VybC5zby42 IiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIv dXNyL2xpYi9saWJjdXJsLnNvLjYiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y eScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvY29tcGF0L2xpYmN1cmwuc28uNiIsMCkJIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xp Yi9saWJjdXJsLnNvLjYiLDApCSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi91c3IvbG9jYWwvbGli L2xpYmN1cmwuc28uNiIsT19SRE9OTFksMDEzMjU2Mzc0MCkgPSAyICgweDIpCjk1Nzk4OiBmc3Rh dCgyLHsgbW9kZT0tcnd4ci14ci14ICxpbm9kZT0yODI2Mzk3LHNpemU9MzU0MzczLGJsa3NpemU9 MTYzODQgfSkgPSAwICgweDApCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDE2YWQ3YzAsMHgxMDAwLDB4 MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQo5 NTc5ODogbW1hcCgweDAsMTM1OTg3MixQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQ X05PQ09SRSwtMSwweDApID0gMzQzODM1NzcwODggKDB4ODAxNmJjMDAwKQo5NTc5ODogbW1hcCgw eDgwMTZiYzAwMCwyODI2MjQsUFJPVF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklY RUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM4MzU3NzA4OCAoMHg4MDE2YmMwMDApCjk1Nzk4OiBt bWFwKDB4ODAxODAxMDAwLDI4NjcyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1B UF9GSVhFRCwyLDB4NDUwMDApID0gMzQzODQ5MDgyODggKDB4ODAxODAxMDAwKQo5NTc5ODogY2xv c2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IGFjY2VzcygiL2xpYi9saWJjcnlwdG8uc28uNiIs MCkJCSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi9saWIvbGliY3J5cHRvLnNvLjYiLE9fUkRPTkxZ LDAxMzI1NjM3NDApID0gMiAoMHgyKQo5NTc5ODogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAs aW5vZGU9NDAwNDQ4LHNpemU9MTY2OTA4OCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQo5NTc5 ODogcHJlYWQoMHgyLDB4ODAxNmFkN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4 MDgwODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6IG1tYXAoMHgwLDI3MDc0NTYs UFJPVF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzg0 OTM2OTYwICgweDgwMTgwODAwMCkKOTU3OTg6IG1tYXAoMHg4MDE4MDgwMDAsMTM1OTg3MixQUk9U X1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9 IDM0Mzg0OTM2OTYwICgweDgwMTgwODAwMCkKOTU3OTg6IG1tYXAoMHg4MDFhNTQwMDAsMjkwODE2 LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MTRjMDAwKSA9 IDM0Mzg3MzQ1NDA4ICgweDgwMWE1NDAwMCkKOTU3OTg6IG1wcm90ZWN0KDB4ODAxYTliMDAwLDgx OTIsUFJPVF9SRUFEfFBST1RfV1JJVEUpID0gMCAoMHgwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9 IDAgKDB4MCkKOTU3OTg6IGFjY2VzcygiL2xpYi9saWJ0aHIuc28uMyIsMCkJCSA9IDAgKDB4MCkK OTU3OTg6IG9wZW4oIi9saWIvbGlidGhyLnNvLjMiLE9fUkRPTkxZLDAxMzI1NjM3NDApID0gMiAo MHgyKQo5NTc5ODogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAsaW5vZGU9NDAwNDI2LHNpemU9 ODc5NTIsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IHByZWFkKDB4MiwweDgwMTZh ZDdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0 MDk2ICgweDEwMDApCjk1Nzk4OiBtbWFwKDB4MCwxMTQyNzg0LFBST1RfTk9ORSxNQVBfUFJJVkFU RXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4NzY0NDQxNiAoMHg4MDFhOWQwMDAp Cjk1Nzk4OiBtbWFwKDB4ODAxYTlkMDAwLDczNzI4LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BS SVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzODc2NDQ0MTYgKDB4ODAxYTlk MDAwKQo5NTc5ODogbW1hcCgweDgwMWJhZTAwMCwxNjM4NCxQUk9UX1JFQUR8UFJPVF9XUklURSxN QVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDExMDAwKSA9IDM0Mzg4NzYyNjI0ICgweDgwMWJhZTAw MCkKOTU3OTg6IG1wcm90ZWN0KDB4ODAxYmIyMDAwLDgxOTIsUFJPVF9SRUFEfFBST1RfV1JJVEUp ID0gMCAoMHgwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IGFjY2Vzcygi L2xpYi9saWJydC5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5 NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9saWJydC5zby4xIiwwKQkJID0gMCAoMHgwKQo5NTc5ODog b3BlbigiL3Vzci9saWIvbGlicnQuc28uMSIsT19SRE9OTFksMDEzMjU2Mzc0MCkgPSAyICgweDIp Cjk1Nzk4OiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT0yNTY3OTAzLHNpemU9MjE3 NDQsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IHByZWFkKDB4MiwweDgwMTZhZDdj MCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2 ICgweDEwMDApCjk1Nzk4OiBtbWFwKDB4MCwxMDY5MDU2LFBST1RfTk9ORSxNQVBfUFJJVkFURXxN QVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4ODc4NzIwMCAoMHg4MDFiYjQwMDApCjk1 Nzk4OiBtbWFwKDB4ODAxYmI0MDAwLDIwNDgwLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZB VEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzODg3ODcyMDAgKDB4ODAxYmI0MDAw KQo5NTc5ODogbW1hcCgweDgwMWNiODAwMCw0MDk2LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9Q UklWQVRFfE1BUF9GSVhFRCwyLDB4NDAwMCkgPSAzNDM4OTg1MjE2MCAoMHg4MDFjYjgwMDApCjk1 Nzk4OiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQo5NTc5ODogYWNjZXNzKCIvbGliL2xpYnNzbC5z by42IiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNz KCIvdXNyL2xpYi9saWJzc2wuc28uNiIsMCkJCSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi91c3Iv bGliL2xpYnNzbC5zby42IixPX1JET05MWSwwMTMyNTYzNzQwKSA9IDIgKDB4MikKOTU3OTg6IGZz dGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTI1NjcxOTIsc2l6ZT0zMzQxNTIsYmxrc2l6 ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IHByZWFkKDB4MiwweDgwMTZhZDdjMCwweDEwMDAs MHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgweDEwMDAp Cjk1Nzk4OiBtbWFwKDB4MCwxMzgwMzUyLFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBfQU5PTnxN QVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4OTg1NjI1NiAoMHg4MDFjYjkwMDApCjk1Nzk4OiBtbWFw KDB4ODAxY2I5MDAwLDI4NjcyMCxQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9G SVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0Mzg5ODU2MjU2ICgweDgwMWNiOTAwMCkKOTU3OTg6 IG1tYXAoMHg4MDFkZmYwMDAsNDUwNTYsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8 TUFQX0ZJWEVELDIsMHg0NjAwMCkgPSAzNDM5MTE5MTU1MiAoMHg4MDFkZmYwMDApCjk1Nzk4OiBj bG9zZSgyKQkJCQkJID0gMCAoMHgwKQo5NTc5ODogYWNjZXNzKCIvbGliL2xpYnouc28uNiIsMCkJ CSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi9saWIvbGliei5zby42IixPX1JET05MWSwwMTMyNTYz NzQwKSA9IDIgKDB4MikKOTU3OTg6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQw MDQzMCxzaXplPTg5NTI4LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1Nzk4OiBwcmVhZCgw eDIsMHg4MDE2YWQ3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4 MDgwODApID0gNDA5NiAoMHgxMDAwKQo5NTc5ODogbW1hcCgweDAsMTEzODY4OCxQUk9UX05PTkUs TUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTEyMzY2MDggKDB4 ODAxZTBhMDAwKQo5NTc5ODogbW1hcCgweDgwMWUwYTAwMCw4MTkyMCxQUk9UX1JFQUR8UFJPVF9F WEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0MzkxMjM2NjA4 ICgweDgwMWUwYTAwMCkKOTU3OTg6IG1tYXAoMHg4MDFmMWUwMDAsODE5MixQUk9UX1JFQUR8UFJP VF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDE0MDAwKSA9IDM0MzkyMzY3MTA0ICgw eDgwMWYxZTAwMCkKOTU3OTg6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCjk1Nzk4OiBhY2Nlc3Mo Ii9saWIvbGlicHJvdG9idWYuc28uNiIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9saWJwcm90b2J1Zi5zby42IiwwKQkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbGliL2NvbXBh dC9saWJwcm90b2J1Zi5zby42IiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScK OTU3OTg6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvbGlicHJvdG9idWYuc28uNiIsMCkgPSAwICgw eDApCjk1Nzk4OiBvcGVuKCIvdXNyL2xvY2FsL2xpYi9saWJwcm90b2J1Zi5zby42IixPX1JET05M WSwwMTMyNTYzNzQwKSA9IDIgKDB4MikKOTU3OTg6IGZzdGF0KDIseyBtb2RlPS1yd3hyLXhyLXgg LGlub2RlPTI4Mjc3ODQsc2l6ZT0xNDEzMjg1LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1 Nzk4OiBwcmVhZCgweDIsMHg4MDE2YWQ3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSww eDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQo5NTc5ODogbW1hcCgweDAsMjE4MzE2 OCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQz OTIzNzUyOTYgKDB4ODAxZjIwMDAwKQo5NTc5ODogbW1hcCgweDgwMWYyMDAwMCw5OTUzMjgsUFJP VF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkg PSAzNDM5MjM3NTI5NiAoMHg4MDFmMjAwMDApCjk1Nzk4OiBtbWFwKDB4ODAyMTEyMDAwLDE0MzM2 MCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweGYyMDAwKSA9 IDM0Mzk0NDE1MTA0ICgweDgwMjExMjAwMCkKOTU3OTg6IGNsb3NlKDIpCQkJCQkgPSAwICgweDAp Cjk1Nzk4OiBhY2Nlc3MoIi9saWIvbGlic3RkYysrLnNvLjYiLDApCQkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbGliL2xpYnN0ZGMrKy5zby42 IiwwKQkgPSAwICgweDApCjk1Nzk4OiBvcGVuKCIvdXNyL2xpYi9saWJzdGRjKysuc28uNiIsT19S RE9OTFksMDEzMjU2Mzc0MCkgPSAyICgweDIpCjk1Nzk4OiBmc3RhdCgyLHsgbW9kZT0tci0tci0t ci0tICxpbm9kZT0yNTY4MDEwLHNpemU9MTAxODU4NCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgw KQo5NTc5ODogcHJlYWQoMHgyLDB4ODAxNmFkN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAx MDEsMHg4MDgwODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6IG1tYXAoMHgwLDIx NDIyMDgsUFJPVF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9 IDM0Mzk0NTU4NDY0ICgweDgwMjEzNTAwMCkKOTU3OTg6IG1tYXAoMHg4MDIxMzUwMDAsODc2NTQ0 LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiww eDApID0gMzQzOTQ1NTg0NjQgKDB4ODAyMTM1MDAwKQo5NTc5ODogbW1hcCgweDgwMjMwYTAwMCwx NDMzNjAsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHhkNTAw MCkgPSAzNDM5NjQ3OTQ4OCAoMHg4MDIzMGEwMDApCjk1Nzk4OiBtcHJvdGVjdCgweDgwMjMyZDAw MCw3NzgyNCxQUk9UX1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCjk1Nzk4OiBjbG9zZSgyKQkJ CQkJID0gMCAoMHgwKQo5NTc5ODogYWNjZXNzKCIvbGliL2xpYm0uc28uNSIsMCkJCSA9IDAgKDB4 MCkKOTU3OTg6IG9wZW4oIi9saWIvbGlibS5zby41IixPX1JET05MWSwwMTMyNTYzNzQwKSA9IDIg KDB4MikKOTU3OTg6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQwMDM5MSxzaXpl PTEzNjc0NCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQo5NTc5ODogcHJlYWQoMHgyLDB4ODAx NmFkN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgwODA4MDgwODA4MDgwKSA9 IDQwOTYgKDB4MTAwMCkKOTU3OTg6IG1tYXAoMHgwLDExNzU1NTIsUFJPVF9OT05FLE1BUF9QUklW QVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzk2NzAwNjcyICgweDgwMjM0MDAw MCkKOTU3OTg6IG1tYXAoMHg4MDIzNDAwMDAsMTIyODgwLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQ X1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTY3MDA2NzIgKDB4ODAy MzQwMDAwKQo5NTc5ODogbW1hcCgweDgwMjQ1ZDAwMCw4MTkyLFBST1RfUkVBRHxQUk9UX1dSSVRF LE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MWQwMDApID0gMzQzOTc4NjgwMzIgKDB4ODAyNDVk MDAwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IGFjY2VzcygiL2xpYi9s aWJnY2Nfcy5zby4xIiwwKQkJID0gMCAoMHgwKQo5NTc5ODogb3BlbigiL2xpYi9saWJnY2Nfcy5z by4xIixPX1JET05MWSwwMTMyNTYzNzQwKSA9IDIgKDB4MikKOTU3OTg6IGZzdGF0KDIseyBtb2Rl PS1yLS1yLS1yLS0gLGlub2RlPTQwMDQ0NCxzaXplPTU2MTkyLGJsa3NpemU9MTYzODQgfSkgPSAw ICgweDApCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDE2YWQ3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEw MTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQo5NTc5ODogbW1hcCgw eDAsMTEwMTgyNCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSww eDApID0gMzQzOTc4NzYyMjQgKDB4ODAyNDVmMDAwKQo5NTc5ODogbW1hcCgweDgwMjQ1ZjAwMCw0 OTE1MixQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JF LDIsMHgwKSA9IDM0Mzk3ODc2MjI0ICgweDgwMjQ1ZjAwMCkKOTU3OTg6IG1tYXAoMHg4MDI1NmEw MDAsODE5MixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweGIw MDApID0gMzQzOTg5Njk4NTYgKDB4ODAyNTZhMDAwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9IDAg KDB4MCkKOTU3OTg6IGFjY2VzcygiL2xpYi9saWJjLnNvLjciLDApCQkgPSAwICgweDApCjk1Nzk4 OiBvcGVuKCIvbGliL2xpYmMuc28uNyIsT19SRE9OTFksMDEzMjU2Mzc0MCkgPSAyICgweDIpCjk1 Nzk4OiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT00MDAzODgsc2l6ZT0xMTgwMDA4 LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDE2YWQ3YzAs MHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAo MHgxMDAwKQo5NTc5ODogbW1hcCgweDAsMjMwNjA0OCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQ X0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTg5NzgwNDggKDB4ODAyNTZjMDAwKQo5NTc5 ODogbW1hcCgweDgwMjU2YzAwMCwxMDE1ODA4LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZB VEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTg5NzgwNDggKDB4ODAyNTZjMDAw KQo5NTc5ODogbW1hcCgweDgwMjc2NDAwMCwxMzEwNzIsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQ X1BSSVZBVEV8TUFQX0ZJWEVELDIsMHhmODAwMCkgPSAzNDQwMTA0MjQzMiAoMHg4MDI3NjQwMDAp Cjk1Nzk4OiBtcHJvdGVjdCgweDgwMjc4NDAwMCwxMTA1OTIsUFJPVF9SRUFEfFBST1RfV1JJVEUp ID0gMCAoMHgwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IHN5c2FyY2go MHg4MSwweDdmZmZmZmZmZTQwMCwweDgwMTVhOTYwOCwweDAsMHhmZmZmZmZmZmZlZTNiZWQwLDB4 ODA4MDgwODA4MDgwODA4MCkgPSAwICgweDApCjk1Nzk4OiBtbWFwKDB4MCw0NTA1NixQUk9UX1JF QUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwtMSwweDApID0gMzQzODI0NjI5NzYg KDB4ODAxNWFjMDAwKQo5NTc5ODogbXVubWFwKDB4ODAxNWIwMDAwLDI4NjcyKQkJID0gMCAoMHgw KQo5NTc5ODogbW1hcCgweDAsMTAyNDAwLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRF fE1BUF9BTk9OLC0xLDB4MCkgPSAzNDM4MjQ3OTM2MCAoMHg4MDE1YjAwMDApCjk1Nzk4OiBzaWdw cm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxT SUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lH VFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdX SU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJv Y21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IF9fc3lzY3RsKDB4 N2ZmZmZmZmZlMzkwLDB4MiwweDgwMjc4YTMyMCwweDdmZmZmZmZmZTM4OCwweDAsMHgwKSA9IDAg KDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8 U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJ R0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZU QUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgw eDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5 NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxM fFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxT SUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJ R1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3 OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQ RXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8 U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxT SUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2ln cHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IGdldHBpZCgp CQkJCQkgPSA5NTc5OCAoMHgxNzYzNikKOTU3OTg6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMzUwLDB4 MiwweDgwMWJiM2U3MCwweDdmZmZmZmZmZTM1OCwweDAsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IF9f c3lzY3RsKDB4N2ZmZmZmZmZlMjcwLDB4MiwweDdmZmZmZmZmZTI5MCwweDdmZmZmZmZmZTJmOCww eDgwMWFhZGZkOCwweGQpID0gMCAoMHgwKQo5NTc5ODogX19zeXNjdGwoMHg3ZmZmZmZmZmUyOTAs MHgzLDB4ODAxYmIyZDY4LDB4N2ZmZmZmZmZlMzU4LDB4MCwweDApID0gMCAoMHgwKQo5NTc5ODog X19zeXNjdGwoMHg3ZmZmZmZmZmRlMDAsMHgyLDB4N2ZmZmZmZmZkZTJjLDB4N2ZmZmZmZmZkZTIw LDB4MCwweDApID0gMCAoMHgwKQo5NTc5ODogX19zeXNjdGwoMHg3ZmZmZmZmZmRjZjAsMHgyLDB4 N2ZmZmZmZmZkZDEwLDB4N2ZmZmZmZmZkZDc4LDB4ODAyNjU3NTQwLDB4YykgPSAwICgweDApCjk1 Nzk4OiBfX3N5c2N0bCgweDdmZmZmZmZmZGQxMCwweDIsMHg4MDI3ODlkNzAsMHg3ZmZmZmZmZmRk YzAsMHgwLDB4MCkgPSAwICgweDApCjk1Nzk4OiByZWFkbGluaygiL2V0Yy9tYWxsb2MuY29uZiIs MHg3ZmZmZmZmZmRlMzAsMTAyNCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1 Nzk4OiBpc3NldHVnaWQoMHg4MDI2NTYxNGYsMHg3ZmZmZmZmZmRlMzAsMHhmZmZmZmZmZmZmZmZm ZmZmLDB4MCwweDIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IGJyZWFrKDB4MTgwMDAwMCkJCQkJID0g MCAoMHgwKQo5NTc5ODogX19zeXNjdGwoMHg3ZmZmZmZmZmRlNTAsMHgyLDB4N2ZmZmZmZmZkZTZj LDB4N2ZmZmZmZmZkZTYwLDB4MCwweDApID0gMCAoMHgwKQo5NTc5ODogbW1hcCgweDAsNDE5NDMw NCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwtMSwweDApID0gMzQ0 MDEyODQwOTYgKDB4ODAyNzlmMDAwKQo5NTc5ODogbW1hcCgweDgwMmI5ZjAwMCwzOTczMTIsUFJP VF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0FOT04sLTEsMHgwKSA9IDM0NDA1NDc4 NDAwICgweDgwMmI5ZjAwMCkKOTU3OTg6IG11bm1hcCgweDgwMjc5ZjAwMCwzOTczMTIpCQkgPSAw ICgweDApCjk1Nzk4OiB0aHJfc2VsZigweDgwMjgwNzFjMCwweDAsMHgwLDB4MCwweDE4OCwweDE2 MzFjZjApID0gMCAoMHgwKQo5NTc5ODogbW1hcCgweDdmZmZmZmJmZjAwMCw0MDk2LFBST1RfTk9O RSxNQVBfQU5PTiwtMSwweDApID0gMTQwNzM3NDg0MTU2OTI4ICgweDdmZmZmZmJmZjAwMCkKOTU3 OTg6IHRocl9zZXRfbmFtZSgweDE4N2YyLDB4ODAxYWFlMDIwLDB4MCwweDEwMDAsMHhmZmZmZmZm ZiwweDApID0gMCAoMHgwKQo5NTc5ODogcnRwcmlvX3RocmVhZCgweDAsMHgxODdmMiwweDdmZmZm ZmZmZTMwMCwweDEwMDAsMHhmZmZmZmZmZiwweDApID0gMCAoMHgwKQo5NTc5ODogc3lzYXJjaCgw eDgxLDB4N2ZmZmZmZmZlMzIwLDB4ODAxYmIyOTQwLDB4ODAxYmIyY2M4LDB4ZmZmZmZmZmYsMHgw KSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLFNJR0hVUHxTSUdJTlR8 U0lHUVVJVHxTSUdJTEx8U0lHQUJSVHxTSUdFTVR8U0lHRlBFfFNJR0tJTEx8U0lHQlVTfFNJR1NF R1Z8U0lHU1lTfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8 U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lH VlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAg KDB4MCkKOTU3OTg6IHNpZ2FjdGlvbigzMix7IDB4ODAxYWE4Mzc1IFNBX1JFU1RBUlR8U0FfU0lH SU5GTyBzc190IH0sMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNL LDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQ fFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJ R1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hD UFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lH VVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4 MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5U fFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxT SUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdY RlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4 MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0g MCAoMHgwKQo5NTc5ODogbWFkdmlzZSgweDgwMjgwZjAwMCwweDEwMDAsMHg1LDB4ZSwweDIwMDgs MHhiKSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4MGYwMDAsMHgxMDAwLDB4NSwweGUs MHgyMDA4LDB4N2ZmZmZmZmZkNzQwKSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4MjAw MDAsMHgxMDAwLDB4NSwweDFmLDB4MjAwOCwweDE2MzFjZjApID0gMCAoMHgwKQo5NTc5ODogbWFk dmlzZSgweDgwMjgyNjAwMCwweDEwMDAsMHg1LDB4MjUsMHg1MDA4LDB4N2ZmZmZmZmZkNTgwKSA9 IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4MjIwMDAsMHgxMDAwLDB4NSwweDIxLDB4NTAw OCwweDdmZmZmZmZmZDU4MCkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyODFlMDAwLDB4 MTAwMCwweDUsMHgxZCwweDIwMDgsMHg3ZmZmZmZmZmQ1ODApID0gMCAoMHgwKQo5NTc5ODogbWFk dmlzZSgweDgwMjgxOTAwMCwweDEwMDAsMHg1LDB4MTgsMHgxLDB4N2ZmZmZmZmZkNWEwKSA9IDAg KDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4MTgwMDAsMHgxMDAwLDB4NSwweDE3LDB4MTYzMWRl MCwweDdmZmZmZmZmZDVlMCkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyODIwMDAwLDB4 MTAwMCwweDUsMHgxZiwweGYwMDAsMHg3ZmZmZmZmZmQ2MDApID0gMCAoMHgwKQo5NTc5ODogbWFk dmlzZSgweDgwMjgxYTAwMCwweDEwMDAsMHg1LDB4MTksMHgxMDA4LDB4MTYzMWNmMCkgPSAwICgw eDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJ R0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdD T05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFM Uk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgw KQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3 OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxT SUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lH Q0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQ Uk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCjk1Nzk4 OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogc2ln cHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8 U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJ R1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lH V0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3By b2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFz ayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJN fFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxT SUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxT SUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2so U0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19C TE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVS TXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8 U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98 U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VU TUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJ R0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VS R3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xT SUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1Ix fFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4 MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyODQ0MDAwLDB4MTAwMCwweDUs MHg0MywweDEsMHg3ZmZmZmZmZmRhZDApID0gMCAoMHgwKQo5NTc5ODogbWFkdmlzZSgweDgwMjgz ZDAwMCwweDEwMDAsMHg1LDB4M2MsMHgxLDB4N2ZmZmZmZmZkYWQwKSA9IDAgKDB4MCkKOTU3OTg6 IG1hZHZpc2UoMHg4MDI4M2MwMDAsMHgxMDAwLDB4NSwweDNiLDB4MTYzMWRlMCwweDdmZmZmZmZm ZGJhMCkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyODI1MDAwLDB4MTAwMCwweDUsMHgy NCwweDE2MzFkZTAsMHg3ZmZmZmZmZmRiYTApID0gMCAoMHgwKQo5NTc5ODogbWFkdmlzZSgweDgw MjgyNDAwMCwweDEwMDAsMHg1LDB4MjMsMHgxLDB4N2ZmZmZmZmZkYjIwKSA9IDAgKDB4MCkKOTU3 OTg6IG1hZHZpc2UoMHg4MDI4MWMwMDAsMHgyMDAwLDB4NSwweDFiLDB4MSwweDdmZmZmZmZmZGIy MCkgPSAwICgweDApCjk1Nzk4OiBnZXRldWlkKCkJCQkJID0gMTAwMCAoMHgzZTgpCjk1Nzk4OiBn ZXR1aWQoKQkJCQkJID0gMTAwMCAoMHgzZTgpCjk1Nzk4OiBnZXRldWlkKCkJCQkJID0gMTAwMCAo MHgzZTgpCjk1Nzk4OiBzdGF0KCIvZXRjL25zc3dpdGNoLmNvbmYiLHsgbW9kZT0tcnctci0tci0t ICxpbm9kZT0xNDEzNTksc2l6ZT0yNTUsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6 IG9wZW4oIi9ldGMvbnNzd2l0Y2guY29uZiIsT19SRE9OTFksMDY2NikJID0gMiAoMHgyKQo5NTc5 ODogaW9jdGwoMixUSU9DR0VUQSwweGZmZmZkZjkwKQkJIEVSUiMyNSAnSW5hcHByb3ByaWF0ZSBp b2N0bCBmb3IgZGV2aWNlJwo5NTc5ODogZnN0YXQoMix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9 MTQxMzU5LHNpemU9MjU1LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1Nzk4OiByZWFkKDIs IiNcbiMgbnNzd2l0Y2guY29uZig1KSAtIG5hbWUgc2VyIi4uLiwxNjM4NCkgPSAyNTUgKDB4ZmYp Cjk1Nzk4OiByZWFkKDIsMHg4MDI4NTQwMDAsMTYzODQpCQkgPSAwICgweDApCjk1Nzk4OiBzaWdw cm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxT SUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lH VFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdX SU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogYWNjZXNz KCIvbGliL25zc19jb21wYXQuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvbnNzX2NvbXBhdC5zby4xIiwwKQkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbGliL2NvbXBh dC9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5 NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2tkZTQv bGliL25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnkn Cjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2NvbXBhdC9uc3NfY29tcGF0LnNvLjEiLDAp IEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xv Y2FsL2xpYi9nZWdsLTAuMS9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUg b3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9ncmFwaHZpei9uc3Nf Y29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODog YWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9xdDQvbnNzX2NvbXBhdC5zby4xIiwwKSBFUlIjMiAnTm8g c3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL2xpYi9uc3NfY29tcGF0LnNv LjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3Mo Ii91c3IvbGliL25zc19jb21wYXQuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5Jwo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4 MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lH S0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NP TlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxS TXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDAp Cjk1Nzk4OiBhY2Nlc3MoIi9saWIvbnNzX25pcy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9uc3NfbmlzLnNvLjEiLDAp CSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9s aWIvY29tcGF0L25zc19uaXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfbmlzLnNvLjEiLDApCSBFUlIj MiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9sb2NhbC9r ZGU0L2xpYi9uc3NfbmlzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX25pcy5zby4xIiwwKSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9sb2Nh bC9saWIvZ2VnbC0wLjEvbnNzX25pcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXovbnNzX25pcy5z by4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2Vzcygi L3Vzci9sb2NhbC9saWIvcXQ0L25zc19uaXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi9saWIvbnNzX25pcy5zby4xIiwwKQkJIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9uc3Nf bmlzLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IHNp Z3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9j bWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdB TFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJ TnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5D SHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogYWNjZXNzKCIv bGliL25zc19maWxlcy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJIEVSUiMyICdObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9jb21wYXQvbnNz X2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODog YWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwva2RlNC9saWIvbnNz X2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODog YWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9n ZWdsLTAuMS9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dyYXBodml6L25zc19maWxlcy5zby4x IiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vz ci9sb2NhbC9saWIvcXQ0L25zc19maWxlcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9y IGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJCSBFUlIj MiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvbnNz X2ZpbGVzLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6 IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdw cm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxT SUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lH VFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdX SU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogYWNjZXNz KCIvbGliL25zc19kbnMuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y eScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvbnNzX2Rucy5zby4xIiwwKQkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbGliL2NvbXBhdC9uc3Nf ZG5zLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFj Y2VzcygiL3Vzci9sb2NhbC9saWIvbnNzX2Rucy5zby4xIiwwKQkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwva2RlNC9saWIvbnNzX2Ru cy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2Vz cygiL3Vzci9sb2NhbC9saWIvY29tcGF0L25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dlZ2wtMC4x L25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4 OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dyYXBodml6L25zc19kbnMuc28uMSIsMCkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGli L3F0NC9uc3NfZG5zLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5 NTc5ODogYWNjZXNzKCIvbGliL25zc19kbnMuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxl IG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvbnNzX2Rucy5zby4xIiwwKQkg RVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdf U0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogaW9jdGwoMixUSU9DR0VUQSwweGZm ZmZkZmEwKQkJIEVSUiMyNSAnSW5hcHByb3ByaWF0ZSBpb2N0bCBmb3IgZGV2aWNlJwo5NTc5ODog Y2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4NTQwMDAsMHg0MDAw LDB4NSwweDUzLDB4NGMwMDgsMHg4MDI3OGJmYzApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21h c2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxS TXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58 U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8 U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNr KFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdf QkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RF Uk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9V fFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZP fFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NF VE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IGdldGV1aWQoKQkJCQkgPSAxMDAwICgw eDNlOCkKOTU3OTg6IG9wZW4oIi9ldGMvcHdkLmRiIixPX1JET05MWSwwMCkJCSA9IDIgKDB4MikK OTU3OTg6IGZjbnRsKDIsRl9TRVRGRCxGRF9DTE9FWEVDKQkJID0gMCAoMHgwKQo5NTc5ODogZnN0 YXQoMix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MTQxNTM3LHNpemU9NDA5NjAsYmxrc2l6ZT0x NjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IHJlYWQoMiwiXDBcXkZcXlVhXDBcMFwwXF5CXDBcMFxe RFxNLVJcMCIuLi4sMjYwKSA9IDI2MCAoMHgxMDQpCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDI4YTIw MDAsMHgxMDAwLDB4NjAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6IHByZWFkKDB4 MiwweDgwMjhhMzAwMCwweDEwMDAsMHg0MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQo5NTc5 ODogcHJlYWQoMHgyLDB4ODAyOGE0MDAwLDB4MTAwMCwweDUwMDAsMHgxLDB4MCkgPSA0MDk2ICgw eDEwMDApCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDI4YTUwMDAsMHgxMDAwLDB4NzAwMCwweDEsMHgw KSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6IHByZWFkKDB4MiwweDgwMjhhNjAwMCwweDEwMDAsMHg4 MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQo5NTc5ODogcHJlYWQoMHgyLDB4ODAyOGE3MDAw LDB4MTAwMCwweDEwMDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCjk1Nzk4OiBwcmVhZCgweDIs MHg4MDI4YTgwMDAsMHgxMDAwLDB4MjAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6 IHByZWFkKDB4MiwweDgwMjhhOTAwMCwweDEwMDAsMHgzMDAwLDB4MSwweDApID0gNDA5NiAoMHgx MDAwKQo5NTc5ODogbWFkdmlzZSgweDgwMjhhODAwMCwweDIwMDAsMHg1LDB4YTcsMHgxLDB4MCkg PSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyOGEyMDAwLDB4NDAwMCwweDUsMHhhMSwweDEs MHgwKSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4YTYwMDAsMHgyMDAwLDB4NSwweGE1 LDB4MSwweDdmZmZmZmZmZDQyMCkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyOGExMDAw LDB4MTAwMCwweDUsMHhhMCwweDEsMHg3ZmZmZmZmZmQ0MjApID0gMCAoMHgwKQo5NTc5ODogY2xv c2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4NTkwMDAsMHgyMDAwLDB4 NSwweDU4LDB4NGMwMDgsMHg3ZmZmZmZmZmQ0NjApID0gMCAoMHgwKQo5NTc5ODogbWtkaXIoIi91 c3IvaG9tZS9nY29vcGVyLy5tb3pjIiwwNzAwKQkgRVJSIzE3ICdGaWxlIGV4aXN0cycKOTU3OTg6 IHN0YXQoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjIix7IG1vZGU9ZHJ3eC0tLS0tLSAsaW5vZGU9 MzAzOTI1MSxzaXplPTUxMixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQo5NTc5ODogY2htb2Qo Ii91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5zZXJ2ZXIubG9jayIsMDYwMCkgPSAwICgweDApCjk1 Nzk4OiBvcGVuKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96Yy8uc2VydmVyLmxvY2siLE9fUkRXUnxP X0NSRUFUfE9fVFJVTkMsMDYwMCkgPSAyICgweDIpCjk1Nzk4OiBmY250bCgyLEZfU0VUTEssMHg3 ZmZmZmZmZmU4MDApCQkgPSAwICgweDApCjk1Nzk4OiBjaG1vZCgiL3Vzci9ob21lL2djb29wZXIv Lm1vemMvLnNlcnZlci5sb2NrIiwwNDAwKSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi9kZXYvdXJh bmRvbSIsT19SRE9OTFksMDY2NikJID0gMyAoMHgzKQo5NTc5ODogcmVhZCgzLCJcTS03SWJCZ2Bc TS0pNVxNLTdZW1xNLVFcTV5GXE0tYiIuLi4sMTAyMykgPSAxMDIzICgweDNmZikKOTU3OTg6IGNs b3NlKDMpCQkJCQkgPSAwICgweDApCjk1Nzk4OiBzdGF0KCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96 Yy8uc2Vzc2lvbi5pcGMiLHsgbW9kZT0tci0tLS0tLS0tICxpbm9kZT0zMDM5MjUzLHNpemU9NTYs Ymxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi91c3IvaG9tZS9nY29vcGVy Ly5tb3pjLy5zZXNzaW9uLmlwYyIsT19SRE9OTFksMDY2NikgPSAzICgweDMpCjk1Nzk4OiByZWFk KDMsIlxuIGVmZDIxZGZiNmZjMDJkOTJiMzc3NWMwYjkxOTE4Ii4uLiw4MTkyKSA9IDU2ICgweDM4 KQo5NTc5ODogcmVhZCgzLDB4ODAyOGIzMDM4LDgxMzYpCQkJID0gMCAoMHgwKQo5NTc5ODogc3Rh dCgiL3Vzci9ob21lL2djb29wZXIvLm1vemMvLnNlc3Npb24uaXBjIix7IG1vZGU9LXItLS0tLS0t LSAsaW5vZGU9MzAzOTI1MyxzaXplPTU2LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1Nzk4 OiBjbG9zZSgzKQkJCQkJID0gMCAoMHgwKQo5NTc5ODogbWtkaXIoIi90bXAiLDA3MDApCQkJIEVS UiMxNyAnRmlsZSBleGlzdHMnCjk1Nzk4OiBzb2NrZXQoUEZfTE9DQUwsU09DS19TVFJFQU0sMCkJ CSA9IDMgKDB4MykKOTU3OTg6IGZjbnRsKDMsRl9HRVRGRCwpCQkJID0gMCAoMHgwKQo5NTc5ODog ZmNudGwoMyxGX1NFVEZELEZEX0NMT0VYRUMpCQkgPSAwICgweDApCjk1Nzk4OiBzZXRzb2Nrb3B0 KDB4MywweGZmZmYsMHg0LDB4N2ZmZmZmZmZlODI4LDB4NCwweDQpID0gMCAoMHgwKQo5NTc5ODog YmluZCgzLHsgQUZfVU5JWCAiL3RtcC8ubW96Yy5lZmQyMWRmYjZmYzAyZDkyYjM3NzVjMGI5MTkx OGExOS5zZXNzaW9uIiB9LDEwNikgRVJSIzQ4ICdBZGRyZXNzIGFscmVhZHkgaW4gdXNlJwo5NTc5 ODogc3RhdCgiL3Vzci9zaGFyZS9ubHMvQy9saWJjLmNhdCIsMHg3ZmZmZmZmZmUyNTApIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogc3RhdCgiL3Vzci9zaGFyZS9ubHMv bGliYy9DIiwweDdmZmZmZmZmZTI1MCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnkn Cjk1Nzk4OiBzdGF0KCIvdXNyL2xvY2FsL3NoYXJlL25scy9DL2xpYmMuY2F0IiwweDdmZmZmZmZm ZTI1MCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBzdGF0KCIvdXNy L2xvY2FsL3NoYXJlL25scy9saWJjL0MiLDB4N2ZmZmZmZmZlMjUwKSBFUlIjMiAnTm8gc3VjaCBm aWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IG1hZHZpc2UoMHg4MDI4YjMwMDAsMHgyMDAwLDB4NSww eGIyLDB4MTAwOCwweDApID0gMCAoMHgwKQo5NTc5ODogbWFkdmlzZSgweDgwMjhiMTAwMCwweDEw MDAsMHg1LDB4YjAsMHgxMDA4LDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdf QkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RF Uk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9V fFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZP fFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NF VE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxT SUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdV Ukd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98 U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNS MXxTSUdVU1IyLDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSyww eDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxT SUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdT VE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BV fFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VT UjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDAp CQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxT SUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lH VFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZT WnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDAp ID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAg KDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8 U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJ R0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZU QUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgw eDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5 NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxM fFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxT SUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJ R1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3 OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQ RXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8 U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxT SUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2ln cHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2Nt YXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FM Uk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElO fFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNI fFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFz ayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lH X0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdU RVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRP VXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5G T3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19T RVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ss U0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lH VVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lP fFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VT UjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ss MHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8 U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lH U1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQ VXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdV U1IyLDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgw KQkJID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8 U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJ R1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hG U1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgw KSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAw ICgweDApCjk1Nzk4OiBwcm9jZXNzIGV4aXQsIHJ2YWwgPSAyNTUK --0016e6509cc27bfbb10491cb3c91 Content-Type: application/octet-stream; name=mozc-server-WITH_DEBUG Content-Disposition: attachment; filename=mozc-server-WITH_DEBUG Content-Transfer-Encoding: base64 X-Attachment-Id: f_gevf4tvs1 JCB0cnVzcyAtZmYgbW96Y19zZXJ2ZXIKICAyMjI6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMmYwLDB4 MiwweDdmZmZmZmZmZTMwYywweDdmZmZmZmZmZTMwMCwweDAsMHgwKSA9IDAgKDB4MCkKICAyMjI6 IG1tYXAoMHgwLDMyNzY4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9O LC0xLDB4MCkgPSAzNDM4MzI3ODA4MCAoMHg4MDE2NzMwMDApCiAgMjIyOiBpc3NldHVnaWQoMHg4 MDE2NzQwMTUsMHg4MDE2NmU4ZTQsMHg3ZmZmZmZmZmU5OTgsMHg4MDE3OGEwNDAsMHg1NzMxLDB4 MCkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvZXRjL2xpYm1hcC5jb25mIixPX1JET05MWSwwNjY2 KQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBvcGVuKCIvdmFyL3J1 bi9sZC1lbGYuc28uaGludHMiLE9fUkRPTkxZLDA1NykgPSAyICgweDIpCiAgMjIyOiByZWFkKDIs IkVobnRcXkFcMFwwXDBcTV5AXDBcMFwwXE1eWlwwXDAiLi4uLDEyOCkgPSAxMjggKDB4ODApCiAg MjIyOiBsc2VlaygyLDB4ODAsU0VFS19TRVQpCQkJID0gMTI4ICgweDgwKQogIDIyMjogcmVhZCgy LCIvbGliOi91c3IvbGliOi91c3IvbGliL2NvbXBhdDovdSIuLi4sMTU0KSA9IDE1NCAoMHg5YSkK ICAyMjI6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjIyOiBhY2Nlc3MoIi9saWIvbGliY3Vy bC5zby42IiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNj ZXNzKCIvdXNyL2xpYi9saWJjdXJsLnNvLjYiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIvY29tcGF0L2xpYmN1cmwuc28uNiIsMCkJ IEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xv Y2FsL2xpYi9saWJjdXJsLnNvLjYiLDApCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi91c3IvbG9j YWwvbGliL2xpYmN1cmwuc28uNiIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAyICgweDIpCiAgMjIy OiBmc3RhdCgyLHsgbW9kZT0tcnd4ci14ci14ICxpbm9kZT0yODI2Mzk3LHNpemU9MzU0MzczLGJs a3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgx MDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgx MDAwKQogIDIyMjogbW1hcCgweDAsMTM1OTg3MixQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FO T058TUFQX05PQ09SRSwtMSwweDApID0gMzQzODQ0MjQ5NjAgKDB4ODAxNzhiMDAwKQogIDIyMjog bW1hcCgweDgwMTc4YjAwMCwyODI2MjQsUFJPVF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxN QVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM4NDQyNDk2MCAoMHg4MDE3OGIwMDApCiAg MjIyOiBtbWFwKDB4ODAxOGQwMDAwLDI4NjcyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklW QVRFfE1BUF9GSVhFRCwyLDB4NDUwMDApID0gMzQzODU3NTYxNjAgKDB4ODAxOGQwMDAwKQogIDIy MjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IGFjY2VzcygiL2xpYi9saWJjcnlwdG8u c28uNiIsMCkJCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi9saWIvbGliY3J5cHRvLnNvLjYiLE9f UkRPTkxZLDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIyMjogZnN0YXQoMix7IG1vZGU9LXItLXIt LXItLSAsaW5vZGU9NDAwNDQ4LHNpemU9MTY2OTA4OCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgw KQogIDIyMjogcHJlYWQoMHgyLDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAx MDEsMHg4MDgwODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IG1tYXAoMHgwLDI3 MDc0NTYsUFJPVF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9 IDM0Mzg1Nzg0ODMyICgweDgwMThkNzAwMCkKICAyMjI6IG1tYXAoMHg4MDE4ZDcwMDAsMTM1OTg3 MixQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIs MHgwKSA9IDM0Mzg1Nzg0ODMyICgweDgwMThkNzAwMCkKICAyMjI6IG1tYXAoMHg4MDFiMjMwMDAs MjkwODE2LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MTRj MDAwKSA9IDM0Mzg4MTkzMjgwICgweDgwMWIyMzAwMCkKICAyMjI6IG1wcm90ZWN0KDB4ODAxYjZh MDAwLDgxOTIsUFJPVF9SRUFEfFBST1RfV1JJVEUpID0gMCAoMHgwKQogIDIyMjogY2xvc2UoMikJ CQkJCSA9IDAgKDB4MCkKICAyMjI6IGFjY2VzcygiL2xpYi9saWJ0aHIuc28uMyIsMCkJCSA9IDAg KDB4MCkKICAyMjI6IG9wZW4oIi9saWIvbGlidGhyLnNvLjMiLE9fUkRPTkxZLDAxMzU3NTM3NDAp ID0gMiAoMHgyKQogIDIyMjogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAsaW5vZGU9NDAwNDI2 LHNpemU9ODc5NTIsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHByZWFkKDB4Miww eDgwMTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4 MCkgPSA0MDk2ICgweDEwMDApCiAgMjIyOiBtbWFwKDB4MCwxMTQyNzg0LFBST1RfTk9ORSxNQVBf UFJJVkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4ODQ5MjI4OCAoMHg4MDFi NmMwMDApCiAgMjIyOiBtbWFwKDB4ODAxYjZjMDAwLDczNzI4LFBST1RfUkVBRHxQUk9UX0VYRUMs TUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzODg0OTIyODggKDB4 ODAxYjZjMDAwKQogIDIyMjogbW1hcCgweDgwMWM3ZDAwMCwxNjM4NCxQUk9UX1JFQUR8UFJPVF9X UklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDExMDAwKSA9IDM0Mzg5NjEwNDk2ICgweDgw MWM3ZDAwMCkKICAyMjI6IG1wcm90ZWN0KDB4ODAxYzgxMDAwLDgxOTIsUFJPVF9SRUFEfFBST1Rf V1JJVEUpID0gMCAoMHgwKQogIDIyMjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IGFj Y2VzcygiL2xpYi9saWJydC5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9saWJydC5zby4xIiwwKQkJID0gMCAoMHgwKQog IDIyMjogb3BlbigiL3Vzci9saWIvbGlicnQuc28uMSIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAy ICgweDIpCiAgMjIyOiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT0yNTY3OTAzLHNp emU9MjE3NDQsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHByZWFkKDB4MiwweDgw MTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkg PSA0MDk2ICgweDEwMDApCiAgMjIyOiBtbWFwKDB4MCwxMDY5MDU2LFBST1RfTk9ORSxNQVBfUFJJ VkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4OTYzNTA3MiAoMHg4MDFjODMw MDApCiAgMjIyOiBtbWFwKDB4ODAxYzgzMDAwLDIwNDgwLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQ X1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzODk2MzUwNzIgKDB4ODAx YzgzMDAwKQogIDIyMjogbW1hcCgweDgwMWQ4NzAwMCw0MDk2LFBST1RfUkVBRHxQUk9UX1dSSVRF LE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4NDAwMCkgPSAzNDM5MDcwMDAzMiAoMHg4MDFkODcw MDApCiAgMjIyOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIyMjogYWNjZXNzKCIvbGliL2xp YnNzbC5zby42IiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjog YWNjZXNzKCIvdXNyL2xpYi9saWJzc2wuc28uNiIsMCkJCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4o Ii91c3IvbGliL2xpYnNzbC5zby42IixPX1JET05MWSwwMTM1NzUzNzQwKSA9IDIgKDB4MikKICAy MjI6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTI1NjcxOTIsc2l6ZT0zMzQxNTIs Ymxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHByZWFkKDB4MiwweDgwMTc3YzdjMCww eDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgw eDEwMDApCiAgMjIyOiBtbWFwKDB4MCwxMzgwMzUyLFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBf QU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM5MDcwNDEyOCAoMHg4MDFkODgwMDApCiAgMjIy OiBtbWFwKDB4ODAxZDg4MDAwLDI4NjcyMCxQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRF fE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0MzkwNzA0MTI4ICgweDgwMWQ4ODAwMCkK ICAyMjI6IG1tYXAoMHg4MDFlY2UwMDAsNDUwNTYsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BS SVZBVEV8TUFQX0ZJWEVELDIsMHg0NjAwMCkgPSAzNDM5MjAzOTQyNCAoMHg4MDFlY2UwMDApCiAg MjIyOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIyMjogYWNjZXNzKCIvbGliL2xpYnouc28u NiIsMCkJCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi9saWIvbGliei5zby42IixPX1JET05MWSww MTM1NzUzNzQwKSA9IDIgKDB4MikKICAyMjI6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlu b2RlPTQwMDQzMCxzaXplPTg5NTI4LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiBw cmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4 MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIyMjogbW1hcCgweDAsMTEzODY4OCxQUk9U X05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTIwODQ0 ODAgKDB4ODAxZWQ5MDAwKQogIDIyMjogbW1hcCgweDgwMWVkOTAwMCw4MTkyMCxQUk9UX1JFQUR8 UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0Mzky MDg0NDgwICgweDgwMWVkOTAwMCkKICAyMjI6IG1tYXAoMHg4MDFmZWQwMDAsODE5MixQUk9UX1JF QUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDE0MDAwKSA9IDM0MzkzMjE0 OTc2ICgweDgwMWZlZDAwMCkKICAyMjI6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjIyOiBh Y2Nlc3MoIi9saWIvbGlicHJvdG9idWYuc28uNiIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9saWJwcm90b2J1Zi5zby42IiwwKQkg RVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbGli L2NvbXBhdC9saWJwcm90b2J1Zi5zby42IiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvbGlicHJvdG9idWYuc28uNiIsMCkg PSAwICgweDApCiAgMjIyOiBvcGVuKCIvdXNyL2xvY2FsL2xpYi9saWJwcm90b2J1Zi5zby42IixP X1JET05MWSwwMTM1NzUzNzQwKSA9IDIgKDB4MikKICAyMjI6IGZzdGF0KDIseyBtb2RlPS1yd3hy LXhyLXggLGlub2RlPTI4Mjc3ODQsc2l6ZT0xNDEzMjg1LGJsa3NpemU9MTYzODQgfSkgPSAwICgw eDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAx MDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIyMjogbW1hcCgweDAs MjE4MzE2OCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDAp ID0gMzQzOTMyMjMxNjggKDB4ODAxZmVmMDAwKQogIDIyMjogbW1hcCgweDgwMWZlZjAwMCw5OTUz MjgsUFJPVF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwy LDB4MCkgPSAzNDM5MzIyMzE2OCAoMHg4MDFmZWYwMDApCiAgMjIyOiBtbWFwKDB4ODAyMWUxMDAw LDE0MzM2MCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweGYy MDAwKSA9IDM0Mzk1MjYyOTc2ICgweDgwMjFlMTAwMCkKICAyMjI6IGNsb3NlKDIpCQkJCQkgPSAw ICgweDApCiAgMjIyOiBhY2Nlc3MoIi9saWIvbGlic3RkYysrLnNvLjYiLDApCQkgRVJSIzIgJ05v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbGliL2xpYnN0ZGMr Ky5zby42IiwwKQkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvdXNyL2xpYi9saWJzdGRjKysuc28u NiIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAyICgweDIpCiAgMjIyOiBmc3RhdCgyLHsgbW9kZT0t ci0tci0tci0tICxpbm9kZT0yNTY4MDEwLHNpemU9MTAxODU4NCxibGtzaXplPTE2Mzg0IH0pID0g MCAoMHgwKQogIDIyMjogcHJlYWQoMHgyLDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAx MDEwMTAxMDEsMHg4MDgwODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IG1tYXAo MHgwLDIxNDIyMDgsUFJPVF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEs MHgwKSA9IDM0Mzk1NDA2MzM2ICgweDgwMjIwNDAwMCkKICAyMjI6IG1tYXAoMHg4MDIyMDQwMDAs ODc2NTQ0LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NP UkUsMiwweDApID0gMzQzOTU0MDYzMzYgKDB4ODAyMjA0MDAwKQogIDIyMjogbW1hcCgweDgwMjNk OTAwMCwxNDMzNjAsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIs MHhkNTAwMCkgPSAzNDM5NzMyNzM2MCAoMHg4MDIzZDkwMDApCiAgMjIyOiBtcHJvdGVjdCgweDgw MjNmYzAwMCw3NzgyNCxQUk9UX1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCiAgMjIyOiBjbG9z ZSgyKQkJCQkJID0gMCAoMHgwKQogIDIyMjogYWNjZXNzKCIvbGliL2xpYm0uc28uNSIsMCkJCSA9 IDAgKDB4MCkKICAyMjI6IG9wZW4oIi9saWIvbGlibS5zby41IixPX1JET05MWSwwMTM1NzUzNzQw KSA9IDIgKDB4MikKICAyMjI6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQwMDM5 MSxzaXplPTEzNjc0NCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogcHJlYWQoMHgy LDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgwODA4MDgwODA4 MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IG1tYXAoMHgwLDExNzU1NTIsUFJPVF9OT05FLE1B UF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzk3NTQ4NTQ0ICgweDgw MjQwZjAwMCkKICAyMjI6IG1tYXAoMHg4MDI0MGYwMDAsMTIyODgwLFBST1RfUkVBRHxQUk9UX0VY RUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTc1NDg1NDQg KDB4ODAyNDBmMDAwKQogIDIyMjogbW1hcCgweDgwMjUyYzAwMCw4MTkyLFBST1RfUkVBRHxQUk9U X1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MWQwMDApID0gMzQzOTg3MTU5MDQgKDB4 ODAyNTJjMDAwKQogIDIyMjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IGFjY2Vzcygi L2xpYi9saWJnY2Nfcy5zby4xIiwwKQkJID0gMCAoMHgwKQogIDIyMjogb3BlbigiL2xpYi9saWJn Y2Nfcy5zby4xIixPX1JET05MWSwwMTM1NzUzNzQwKSA9IDIgKDB4MikKICAyMjI6IGZzdGF0KDIs eyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQwMDQ0NCxzaXplPTU2MTkyLGJsa3NpemU9MTYzODQg fSkgPSAwICgweDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEw MTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIyMjog bW1hcCgweDAsMTEwMTgyNCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09S RSwtMSwweDApID0gMzQzOTg3MjQwOTYgKDB4ODAyNTJlMDAwKQogIDIyMjogbW1hcCgweDgwMjUy ZTAwMCw0OTE1MixQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBf Tk9DT1JFLDIsMHgwKSA9IDM0Mzk4NzI0MDk2ICgweDgwMjUyZTAwMCkKICAyMjI6IG1tYXAoMHg4 MDI2MzkwMDAsODE5MixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQs MiwweGIwMDApID0gMzQzOTk4MTc3MjggKDB4ODAyNjM5MDAwKQogIDIyMjogY2xvc2UoMikJCQkJ CSA9IDAgKDB4MCkKICAyMjI6IGFjY2VzcygiL2xpYi9saWJjLnNvLjciLDApCQkgPSAwICgweDAp CiAgMjIyOiBvcGVuKCIvbGliL2xpYmMuc28uNyIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAyICgw eDIpCiAgMjIyOiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT00MDAzODgsc2l6ZT0x MTgwMDA4LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDE3 N2M3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0g NDA5NiAoMHgxMDAwKQogIDIyMjogbW1hcCgweDAsMjMwNjA0OCxQUk9UX05PTkUsTUFQX1BSSVZB VEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTk4MjU5MjAgKDB4ODAyNjNiMDAw KQogIDIyMjogbW1hcCgweDgwMjYzYjAwMCwxMDE1ODA4LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQ X1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTk4MjU5MjAgKDB4ODAy NjNiMDAwKQogIDIyMjogbW1hcCgweDgwMjgzMzAwMCwxMzEwNzIsUFJPVF9SRUFEfFBST1RfV1JJ VEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHhmODAwMCkgPSAzNDQwMTg5MDMwNCAoMHg4MDI4 MzMwMDApCiAgMjIyOiBtcHJvdGVjdCgweDgwMjg1MzAwMCwxMTA1OTIsUFJPVF9SRUFEfFBST1Rf V1JJVEUpID0gMCAoMHgwKQogIDIyMjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IHN5 c2FyY2goMHg4MSwweDdmZmZmZmZmZTQwMCwweDgwMTY3ODYwOCwweDAsMHhmZmZmZmZmZmZlZTNi ZWQwLDB4ODA4MDgwODA4MDgwODA4MCkgPSAwICgweDApCiAgMjIyOiBtbWFwKDB4MCw0NTA1NixQ Uk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwtMSwweDApID0gMzQzODMz MTA4NDggKDB4ODAxNjdiMDAwKQogIDIyMjogbXVubWFwKDB4ODAxNjdmMDAwLDI4NjcyKQkJID0g MCAoMHgwKQogIDIyMjogbW1hcCgweDAsMTAyNDAwLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9Q UklWQVRFfE1BUF9BTk9OLC0xLDB4MCkgPSAzNDM4MzMyNzIzMiAoMHg4MDE2N2YwMDApCiAgMjIy OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lH UElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NI TER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJP RnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjog c2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IF9fc3lz Y3RsKDB4N2ZmZmZmZmZlMzkwLDB4MiwweDgwMjg1OTMyMCwweDdmZmZmZmZmZTM4OCwweDAsMHgw KSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJ R1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdU U1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNa fFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkg PSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAo MHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxT SUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lH Q09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRB TFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4 MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAg MjIyOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8 U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJ R0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lH UFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIy Mjogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IGdl dHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiBfX3N5c2N0bCgweDdmZmZmZmZmZTM1MCww eDIsMHg4MDFjODJlNzAsMHg3ZmZmZmZmZmUzNTgsMHgwLDB4MCkgPSAwICgweDApCiAgMjIyOiBf X3N5c2N0bCgweDdmZmZmZmZmZTI3MCwweDIsMHg3ZmZmZmZmZmUyOTAsMHg3ZmZmZmZmZmUyZjgs MHg4MDFiN2NmZDgsMHhkKSA9IDAgKDB4MCkKICAyMjI6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMjkw LDB4MywweDgwMWM4MWQ2OCwweDdmZmZmZmZmZTM1OCwweDAsMHgwKSA9IDAgKDB4MCkKICAyMjI6 IF9fc3lzY3RsKDB4N2ZmZmZmZmZkZTAwLDB4MiwweDdmZmZmZmZmZGUyYywweDdmZmZmZmZmZGUy MCwweDAsMHgwKSA9IDAgKDB4MCkKICAyMjI6IF9fc3lzY3RsKDB4N2ZmZmZmZmZkY2YwLDB4Miww eDdmZmZmZmZmZGQxMCwweDdmZmZmZmZmZGQ3OCwweDgwMjcyNjU0MCwweGMpID0gMCAoMHgwKQog IDIyMjogX19zeXNjdGwoMHg3ZmZmZmZmZmRkMTAsMHgyLDB4ODAyODU4ZDcwLDB4N2ZmZmZmZmZk ZGMwLDB4MCwweDApID0gMCAoMHgwKQogIDIyMjogcmVhZGxpbmsoIi9ldGMvbWFsbG9jLmNvbmYi LDB4N2ZmZmZmZmZkZTMwLDEwMjQpIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwog IDIyMjogaXNzZXR1Z2lkKDB4ODAyNzI1MTRmLDB4N2ZmZmZmZmZkZTMwLDB4ZmZmZmZmZmZmZmZm ZmZmZiwweDAsMHgyLDB4MCkgPSAwICgweDApCiAgMjIyOiBicmVhaygweDE4MDAwMDApCQkJCSA9 IDAgKDB4MCkKICAyMjI6IF9fc3lzY3RsKDB4N2ZmZmZmZmZkZTUwLDB4MiwweDdmZmZmZmZmZGU2 YywweDdmZmZmZmZmZGU2MCwweDAsMHgwKSA9IDAgKDB4MCkKICAyMjI6IG1tYXAoMHgwLDQxOTQz MDQsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0FOT04sLTEsMHgwKSA9IDM0 NDAyMTMxOTY4ICgweDgwMjg2ZTAwMCkKICAyMjI6IG1tYXAoMHg4MDJjNmUwMDAsMzc0Mzc0NCxQ Uk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwtMSwweDApID0gMzQ0MDYz MjYyNzIgKDB4ODAyYzZlMDAwKQogIDIyMjogbXVubWFwKDB4ODAyODZlMDAwLDM3NDM3NDQpCQkg PSAwICgweDApCiAgMjIyOiB0aHJfc2VsZigweDgwMmMwNzFjMCwweDAsMHgwLDB4MCwweDE4OCww eDE3M2FkNDApID0gMCAoMHgwKQogIDIyMjogbW1hcCgweDdmZmZmZmJmZjAwMCw0MDk2LFBST1Rf Tk9ORSxNQVBfQU5PTiwtMSwweDApID0gMTQwNzM3NDg0MTU2OTI4ICgweDdmZmZmZmJmZjAwMCkK ICAyMjI6IHRocl9zZXRfbmFtZSgweDE4ODFjLDB4ODAxYjdkMDIwLDB4MCwweDEwMDAsMHhmZmZm ZmZmZiwweDApID0gMCAoMHgwKQogIDIyMjogcnRwcmlvX3RocmVhZCgweDAsMHgxODgxYywweDdm ZmZmZmZmZTMwMCwweDEwMDAsMHhmZmZmZmZmZiwweDApID0gMCAoMHgwKQogIDIyMjogc3lzYXJj aCgweDgxLDB4N2ZmZmZmZmZlMzIwLDB4ODAxYzgxOTQwLDB4ODAxYzgxY2M4LDB4ZmZmZmZmZmYs MHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLFNJR0hVUHxTSUdJ TlR8U0lHUVVJVHxTSUdJTEx8U0lHQUJSVHxTSUdFTVR8U0lHRlBFfFNJR0tJTEx8U0lHQlVTfFNJ R1NFR1Z8U0lHU1lTfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RT VFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8 U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9 IDAgKDB4MCkKICAyMjI6IHNpZ2FjdGlvbigzMix7IDB4ODAxYjc3Mzc1IFNBX1JFU1RBUlR8U0Ff U0lHSU5GTyBzc190IH0sMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRN QVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lH SFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJH fFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJ R1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8 U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgw LDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lH SU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RP UHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxT SUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1Iy LDB4MCkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJ ID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgwMmMwZjAwMCwweDEwMDAsMHg1LDB4ZSwweDIw MDgsMHhiKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjMGYwMDAsMHgxMDAwLDB4NSww eGUsMHgyMDA4LDB4N2ZmZmZmZmZkNzQwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJj MjAwMDAsMHgxMDAwLDB4NSwweDFmLDB4MjAwOCwweDE3M2FkNDApID0gMCAoMHgwKQogIDIyMjog bWFkdmlzZSgweDgwMmMyNjAwMCwweDEwMDAsMHg1LDB4MjUsMHg1MDA4LDB4N2ZmZmZmZmZkNTgw KSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjMjIwMDAsMHgxMDAwLDB4NSwweDIxLDB4 NTAwOCwweDdmZmZmZmZmZDU4MCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzFlMDAw LDB4MTAwMCwweDUsMHgxZCwweDIwMDgsMHg3ZmZmZmZmZmQ1ODApID0gMCAoMHgwKQogIDIyMjog bWFkdmlzZSgweDgwMmMxOTAwMCwweDEwMDAsMHg1LDB4MTgsMHgxLDB4N2ZmZmZmZmZkNWEwKSA9 IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjMTgwMDAsMHgxMDAwLDB4NSwweDE3LDB4MTcz YWUzMCwweDdmZmZmZmZmZDVlMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzIwMDAw LDB4MTAwMCwweDUsMHgxZiwweGYwMDAsMHg3ZmZmZmZmZmQ2MDApID0gMCAoMHgwKQogIDIyMjog bWFkdmlzZSgweDgwMmMxYTAwMCwweDEwMDAsMHg1LDB4MTksMHgxMDA4LDB4MTczYWQ0MCkgPSAw ICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlU fFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxT SUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdW VEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAo MHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkK ICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lM THxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8 U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxT SUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAg MjIyOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjog c2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJ UEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExE fFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8 U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNp Z3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9j bWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdB TFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJ TnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5D SHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21h c2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJ R19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lH VEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RU T1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lO Rk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdf U0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX0JMT0NL LFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJ R1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJ T3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdV U1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNL LDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzQ0MDAwLDB4MTAwMCww eDUsMHg0MywweDEsMHg3ZmZmZmZmZmRhYTApID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgw MmMzZDAwMCwweDEwMDAsMHg1LDB4M2MsMHgxLDB4N2ZmZmZmZmZkYWEwKSA9IDAgKDB4MCkKICAy MjI6IG1hZHZpc2UoMHg4MDJjM2MwMDAsMHgxMDAwLDB4NSwweDNiLDB4MTczYWUzMCwweDdmZmZm ZmZmZGI3MCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzI1MDAwLDB4MTAwMCwweDUs MHgyNCwweDE3M2FlMzAsMHg3ZmZmZmZmZmRiNzApID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgw eDgwMmMyNDAwMCwweDEwMDAsMHg1LDB4MjMsMHgxLDB4N2ZmZmZmZmZkYWYwKSA9IDAgKDB4MCkK ICAyMjI6IG1hZHZpc2UoMHg4MDJjMWMwMDAsMHgyMDAwLDB4NSwweDFiLDB4MSwweDdmZmZmZmZm ZGFmMCkgPSAwICgweDApCiAgMjIyOiBnZXRldWlkKCkJCQkJID0gMTAwMCAoMHgzZTgpCiAgMjIy OiBnZXR1aWQoKQkJCQkJID0gMTAwMCAoMHgzZTgpCiAgMjIyOiBnZXRldWlkKCkJCQkJID0gMTAw MCAoMHgzZTgpCiAgMjIyOiBzdGF0KCIvZXRjL25zc3dpdGNoLmNvbmYiLHsgbW9kZT0tcnctci0t ci0tICxpbm9kZT0xNDEzNTksc2l6ZT0yNTUsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAy MjI6IG9wZW4oIi9ldGMvbnNzd2l0Y2guY29uZiIsT19SRE9OTFksMDY2NikJID0gMiAoMHgyKQog IDIyMjogaW9jdGwoMixUSU9DR0VUQSwweGZmZmZkZDgwKQkJIEVSUiMyNSAnSW5hcHByb3ByaWF0 ZSBpb2N0bCBmb3IgZGV2aWNlJwogIDIyMjogZnN0YXQoMix7IG1vZGU9LXJ3LXItLXItLSAsaW5v ZGU9MTQxMzU5LHNpemU9MjU1LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiByZWFk KDIsIiNcbiMgbnNzd2l0Y2guY29uZig1KSAtIG5hbWUgc2VyIi4uLiwxNjM4NCkgPSAyNTUgKDB4 ZmYpCiAgMjIyOiByZWFkKDIsMHg4MDJjNTQwMDAsMTYzODQpCQkgPSAwICgweDApCiAgMjIyOiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQ RXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8 U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxT SUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogYWNj ZXNzKCIvbGliL25zc19jb21wYXQuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIvbnNzX2NvbXBhdC5zby4xIiwwKQkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbGliL2Nv bXBhdC9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2tk ZTQvbGliL25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2NvbXBhdC9uc3NfY29tcGF0LnNvLjEi LDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNy L2xvY2FsL2xpYi9nZWdsLTAuMS9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9ncmFwaHZpei9u c3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIy MjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9xdDQvbnNzX2NvbXBhdC5zby4xIiwwKSBFUlIjMiAn Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL2xpYi9uc3NfY29tcGF0 LnNvLjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nl c3MoIi91c3IvbGliL25zc19jb21wYXQuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5JwogIDIyMjogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAg KDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8 U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJ R0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZU QUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgw eDApCiAgMjIyOiBhY2Nlc3MoIi9saWIvbnNzX25pcy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9uc3NfbmlzLnNvLjEi LDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vz ci9saWIvY29tcGF0L25zc19uaXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfbmlzLnNvLjEiLDApCSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9sb2Nh bC9rZGU0L2xpYi9uc3NfbmlzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX25pcy5zby4xIiww KSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9s b2NhbC9saWIvZ2VnbC0wLjEvbnNzX25pcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9y IGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXovbnNzX25p cy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2Vz cygiL3Vzci9sb2NhbC9saWIvcXQ0L25zc19uaXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi9saWIvbnNzX25pcy5zby4xIiwwKQkJIEVS UiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9u c3NfbmlzLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6 IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdw cm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxT SUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lH VFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdX SU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogYWNjZXNz KCIvbGliL25zc19maWxlcy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9jb21wYXQv bnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIy MjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwva2RlNC9saWIv bnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIy MjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xp Yi9nZWdsLTAuMS9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dyYXBodml6L25zc19maWxlcy5z by4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2Vzcygi L3Vzci9sb2NhbC9saWIvcXQ0L25zc19maWxlcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxl IG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJCSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIv bnNzX2ZpbGVzLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAy MjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQ RXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8 U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxT SUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogYWNj ZXNzKCIvbGliL25zc19kbnMuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIvbnNzX2Rucy5zby4xIiwwKQkgRVJSIzIgJ05v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbGliL2NvbXBhdC9u c3NfZG5zLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6 IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvbnNzX2Rucy5zby4xIiwwKQkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwva2RlNC9saWIvbnNz X2Rucy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFj Y2VzcygiL3Vzci9sb2NhbC9saWIvY29tcGF0L25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dlZ2wt MC4xL25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAg MjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dyYXBodml6L25zc19kbnMuc28uMSIsMCkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwv bGliL3F0NC9uc3NfZG5zLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 JwogIDIyMjogYWNjZXNzKCIvbGliL25zc19kbnMuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBm aWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIvbnNzX2Rucy5zby4xIiww KQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBzaWdwcm9jbWFzayhT SUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjogaW9jdGwoMixUSU9DR0VUQSww eGZmZmZkZDkwKQkJIEVSUiMyNSAnSW5hcHByb3ByaWF0ZSBpb2N0bCBmb3IgZGV2aWNlJwogIDIy MjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjNTQwMDAsMHg0 MDAwLDB4NSwweDUzLDB4NGMwMDgsMHg4MDI4NWFmYzApID0gMCAoMHgwKQogIDIyMjogc2lncHJv Y21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lH QUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RU SU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lO Q0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2Nt YXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhT SUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJ R1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdU VE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJ TkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21hc2soU0lH X1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IGdldGV1aWQoKQkJCQkgPSAxMDAw ICgweDNlOCkKICAyMjI6IG9wZW4oIi9ldGMvcHdkLmRiIixPX1JET05MWSwwMCkJCSA9IDIgKDB4 MikKICAyMjI6IGZjbnRsKDIsRl9TRVRGRCxGRF9DTE9FWEVDKQkJID0gMCAoMHgwKQogIDIyMjog ZnN0YXQoMix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MTQxNTM3LHNpemU9NDA5NjAsYmxrc2l6 ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHJlYWQoMiwiXDBcXkZcXlVhXDBcMFwwXF5CXDBc MFxeRFxNLVJcMCIuLi4sMjYwKSA9IDI2MCAoMHgxMDQpCiAgMjIyOiBwcmVhZCgweDIsMHg4MDJj YTIwMDAsMHgxMDAwLDB4NjAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IHByZWFk KDB4MiwweDgwMmNhMzAwMCwweDEwMDAsMHg0MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQog IDIyMjogcHJlYWQoMHgyLDB4ODAyY2E0MDAwLDB4MTAwMCwweDUwMDAsMHgxLDB4MCkgPSA0MDk2 ICgweDEwMDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDJjYTUwMDAsMHgxMDAwLDB4NzAwMCwweDEs MHgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IHByZWFkKDB4MiwweDgwMmNhNjAwMCwweDEwMDAs MHg4MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQogIDIyMjogcHJlYWQoMHgyLDB4ODAyY2E3 MDAwLDB4MTAwMCwweDEwMDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCiAgMjIyOiBwcmVhZCgw eDIsMHg4MDJjYTgwMDAsMHgxMDAwLDB4MjAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKICAy MjI6IHByZWFkKDB4MiwweDgwMmNhOTAwMCwweDEwMDAsMHgzMDAwLDB4MSwweDApID0gNDA5NiAo MHgxMDAwKQogIDIyMjogbWFkdmlzZSgweDgwMmNhODAwMCwweDIwMDAsMHg1LDB4YTcsMHgxLDB4 MCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyY2EyMDAwLDB4NDAwMCwweDUsMHhhMSww eDEsMHgwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjYTYwMDAsMHgyMDAwLDB4NSww eGE1LDB4MSwweDdmZmZmZmZmZDIxMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyY2Ex MDAwLDB4MTAwMCwweDUsMHhhMCwweDEsMHg3ZmZmZmZmZmQyMTApID0gMCAoMHgwKQogIDIyMjog Y2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjNTkwMDAsMHgyMDAw LDB4NSwweDU4LDB4NGMwMDgsMHg3ZmZmZmZmZmQyNTApID0gMCAoMHgwKQogIDIyMjogbWtkaXIo Ii91c3IvaG9tZS9nY29vcGVyLy5tb3pjIiwwNzAwKQkgRVJSIzE3ICdGaWxlIGV4aXN0cycKICAy MjI6IHN0YXQoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjIix7IG1vZGU9ZHJ3eC0tLS0tLSAsaW5v ZGU9MzAzOTI1MSxzaXplPTUxMixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogb3Bl bigiL3Vzci9ob21lL2djb29wZXIvLm1vemMvbW96Y19zZXJ2ZXIubG9nIixPX1dST05MWXxPX0FQ UEVORHxPX0NSRUFULDA2NjYpID0gMiAoMHgyKQogIDIyMjogbHNlZWsoMiwweDAsU0VFS19FTkQp CQkJID0gMCAoMHgwKQogIDIyMjogY2htb2QoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjL21vemNf c2VydmVyLmxvZyIsMDYwMCkgPSAwICgweDApCiAgMjIyOiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2 MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IGFjY2VzcygiL2V0Yy9sb2NhbHRp bWUiLDQpCQkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvZXRjL2xvY2FsdGltZSIsT19SRE9OTFks MDEpCSA9IDMgKDB4MykKICAyMjI6IGZzdGF0KDMseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTE0 MTQwMyxzaXplPTI4MTksYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHJlYWQoMywi VFppZjJcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sNDE0NDgpID0gMjgxOSAoMHhiMDMp CiAgMjIyOiBjbG9zZSgzKQkJCQkJID0gMCAoMHgwKQogIDIyMjogaXNzZXR1Z2lkKDB4ODAyNzJj ZTU5LDB4N2ZmZmZmZmY5YzEwLDB4MCwweDdmZmZmZmZlZmEyNSwweDUwLDB4OCkgPSAwICgweDAp CiAgMjIyOiBvcGVuKCIvdXNyL3NoYXJlL3pvbmVpbmZvL3Bvc2l4cnVsZXMiLE9fUkRPTkxZLDA1 NikgPSAzICgweDMpCiAgMjIyOiBmc3RhdCgzLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT0yMTUw NTE0LHNpemU9MzUxOSxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogcmVhZCgzLCJU WmlmMlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiw0MTQ0OCkgPSAzNTE5ICgweGRiZikK ICAyMjI6IGNsb3NlKDMpCQkJCQkgPSAwICgweDApCiAgMjIyOiBnZXRwaWQoKQkJCQkJID0gMjIy ICgweGRlKQogIDIyMjogd3JpdGUoMiwiTG9nIGZpbGUgY3JlYXRlZCBhdDogMjAxMC0xMC0wNCAi Li4uLDU3KSA9IDU3ICgweDM5KQogIDIyMjogd3JpdGUoMiwiUHJvZ3JhbSBuYW1lOiBtb3pjX3Nl cnZlclxuIiwyNikgPSAyNiAoMHgxYSkKICAyMjI6IGNobW9kKCIvdXNyL2hvbWUvZ2Nvb3Blci8u bW96Yy8uc2VydmVyLmxvY2siLDA2MDApID0gMCAoMHgwKQogIDIyMjogb3BlbigiL3Vzci9ob21l L2djb29wZXIvLm1vemMvLnNlcnZlci5sb2NrIixPX1JEV1J8T19DUkVBVHxPX1RSVU5DLDA2MDAp ID0gMyAoMHgzKQogIDIyMjogZmNudGwoMyxGX1NFVExLLDB4N2ZmZmZmZmZlNWYwKQkJID0gMCAo MHgwKQogIDIyMjogY2htb2QoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5zZXJ2ZXIubG9jayIs MDQwMCkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvZGV2L3VyYW5kb20iLE9fUkRPTkxZLDA2NjYp CSA9IDQgKDB4NCkKICAyMjI6IHJlYWQoNCwiXE1eTXZcTS1aXE0tYlxNLTpcTS1cXF5WXE0te1xN XkoiLi4uLDEwMjMpID0gMTAyMyAoMHgzZmYpCiAgMjIyOiBjbG9zZSg0KQkJCQkJID0gMCAoMHgw KQogIDIyMjogc3RhdCgiL3Vzci9ob21lL2djb29wZXIvLm1vemMvLnNlc3Npb24uaXBjIix7IG1v ZGU9LXItLS0tLS0tLSAsaW5vZGU9MzAzOTI1MyxzaXplPTU2LGJsa3NpemU9MTYzODQgfSkgPSAw ICgweDApCiAgMjIyOiBvcGVuKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96Yy8uc2Vzc2lvbi5pcGMi LE9fUkRPTkxZLDA2NjYpID0gNCAoMHg0KQogIDIyMjogcmVhZCg0LCJcbiBlZmQyMWRmYjZmYzAy ZDkyYjM3NzVjMGI5MTkxOCIuLi4sODE5MikgPSA1NiAoMHgzOCkKICAyMjI6IHJlYWQoNCwweDgw MmNlNDAzOCw4MTM2KQkJCSA9IDAgKDB4MCkKICAyMjI6IHN0YXQoIi91c3IvaG9tZS9nY29vcGVy Ly5tb3pjLy5zZXNzaW9uLmlwYyIseyBtb2RlPS1yLS0tLS0tLS0gLGlub2RlPTMwMzkyNTMsc2l6 ZT01NixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogY2xvc2UoNCkJCQkJCSA9IDAg KDB4MCkKICAyMjI6IG1rZGlyKCIvdG1wIiwwNzAwKQkJCSBFUlIjMTcgJ0ZpbGUgZXhpc3RzJwog IDIyMjogc29ja2V0KFBGX0xPQ0FMLFNPQ0tfU1RSRUFNLDApCQkgPSA0ICgweDQpCiAgMjIyOiBm Y250bCg0LEZfR0VURkQsKQkJCSA9IDAgKDB4MCkKICAyMjI6IGZjbnRsKDQsRl9TRVRGRCxGRF9D TE9FWEVDKQkJID0gMCAoMHgwKQogIDIyMjogc2V0c29ja29wdCgweDQsMHhmZmZmLDB4NCwweDdm ZmZmZmZmZTY3YywweDQsMHg0KSA9IDAgKDB4MCkKICAyMjI6IGJpbmQoNCx7IEFGX1VOSVggIi90 bXAvLm1vemMuZWZkMjFkZmI2ZmMwMmQ5MmIzNzc1YzBiOTE5MThhMTkuc2Vzc2lvbiIgfSwxMDYp ID0gMCAoMHgwKQogIDIyMjogY2htb2QoIi90bXAvLm1vemMuZWZkMjFkZmI2ZmMwMmQ5MmIzNzc1 YzBiOTE5MThhMTkuc2Vzc2lvbiIsMDYwMCkgPSAwICgweDApCiAgMjIyOiBsaXN0ZW4oMHg0LDB4 YSwweDZhLDB4MmUsMHhmZWZlZmVmZWZlZmVmZWZmLDB4NCkgPSAwICgweDApCiAgMjIyOiBnZXRw aWQoKQkJCQkJID0gMjIyICgweGRlKQogIDIyMjogY2htb2QoIi91c3IvaG9tZS9nY29vcGVyLy5t b3pjLy5zZXNzaW9uLmlwYyIsMDYwMCkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvdXNyL2hvbWUv Z2Nvb3Blci8ubW96Yy8uc2Vzc2lvbi5pcGMiLE9fUkRXUnxPX0NSRUFUfE9fVFJVTkMsMDYwMCkg PSA1ICgweDUpCiAgMjIyOiBmY250bCg1LEZfU0VUTEssMHg3ZmZmZmZmZmUzMjApCQkgPSAwICgw eDApCiAgMjIyOiB3cml0ZSg1LCJcbiBlZmQyMWRmYjZmYzAyZDkyYjM3NzVjMGI5MTkxOCIuLi4s NTUpID0gNTUgKDB4MzcpCiAgMjIyOiBjaG1vZCgiL3Vzci9ob21lL2djb29wZXIvLm1vemMvLnNl c3Npb24uaXBjIiwwNDAwKSA9IDAgKDB4MCkKICAyMjI6IHN0YXQoIi91c3IvaG9tZS9nY29vcGVy Ly5tb3pjLy5zZXNzaW9uLmlwYyIseyBtb2RlPS1yLS0tLS0tLS0gLGlub2RlPTMwMzkyNTMsc2l6 ZT01NSxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogb3BlbigiL3Vzci9ob21lL2dj b29wZXIvLm1vemMvY29uZmlnMS5kYiIsT19SRE9OTFksMDY2NikgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjIyOiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAw MDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IGdldHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIy OiB3cml0ZSgyLCIyMDEwLTEwLTA0IDA3OjA2OjU4IDIyMiAzNDQwNTkwNCIuLi4sMTA5KSA9IDEw OSAoMHg2ZCkKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0p ID0gMCAoMHgwKQogIDIyMjogZ2V0cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRl KDIsIjIwMTAtMTAtMDQgMDc6MDY6NTggMjIyIDM0NDA1OTA0Ii4uLiwxMzgpID0gMTM4ICgweDhh KQogIDIyMjogY2xvY2tfZ2V0dGltZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgw eDApCiAgMjIyOiBnZXRwaWQoKQkJCQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAx MC0xMC0wNCAwNzowNjo1OCAyMjIgMzQ0MDU5MDQiLi4uLDE0MikgPSAxNDIgKDB4OGUpCiAgMjIy OiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAy MjI6IGdldHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiB3cml0ZSgyLCIyMDEwLTEwLTA0 IDA3OjA2OjU4IDIyMiAzNDQwNTkwNCIuLi4sMTM1KSA9IDEzNSAoMHg4NykKICAyMjI6IGNsb2Nr X2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogZ2V0 cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIsIjIwMTAtMTAtMDQgMDc6MDY6 NTggMjIyIDM0NDA1OTA0Ii4uLiwxMzkpID0gMTM5ICgweDhiKQogIDIyMjogY2xvY2tfZ2V0dGlt ZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgweDApCiAgMjIyOiBnZXRwaWQoKQkJ CQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAxMC0xMC0wNCAwNzowNjo1OCAyMjIg MzQ0MDU5MDQiLi4uLDEzNCkgPSAxMzQgKDB4ODYpCiAgMjIyOiBjbG9ja19nZXR0aW1lKDEzLHsx Mjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IGdldHBpZCgpCQkJCQkgPSAy MjIgKDB4ZGUpCiAgMjIyOiB3cml0ZSgyLCIyMDEwLTEwLTA0IDA3OjA2OjU4IDIyMiAzNDQwNTkw NCIuLi4sMTM4KSA9IDEzOCAoMHg4YSkKICAyMjI6IG1hZHZpc2UoMHg4MDJjZTQwMDAsMHg0MDAw LDB4NSwweGUzLDB4MTczYWUzMCwweDdmZmZmZmZmZDViMCkgPSAwICgweDApCiAgMjIyOiBjbG9j a19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IG9w ZW4oIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjL2JvdW5kYXJ5LmRiIixPX1JEV1IsMDApID0gNiAo MHg2KQogIDIyMjogZnN0YXQoNix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MzAzOTI1NCxzaXpl PTgwMDEyLGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiBtbWFwKDB4MCw4MDAxMixQ Uk9UX1JFQUR8UFJPVF9XUklURSxNQVBfU0hBUkVELDYsMHgwKSA9IDM0MzgzNDI5NjMyICgweDgw MTY5ODAwMCkKICAyMjI6IGNsb3NlKDYpCQkJCQkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4 ODAyZDM3MDAwLDB4ODAwMCwweDUsMHgxMzYsMHgxLDB4N2ZmZmZmZmZkNWUwKSA9IDAgKDB4MCkK ICAyMjI6IG1hZHZpc2UoMHg4MDJjZTcwMDAsMHg0MDAwLDB4NSwweGU2LDB4MSwweDdmZmZmZmZm ZDVlMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyZDJmMDAwLDB4MTAwMCwweDUsMHgx MmUsMHhlMDA4LDB4N2ZmZmZmZmZkNmUwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJj ZTMwMDAsMHgxMDAwLDB4NSwweGUyLDB4ZTAwOCwweDdmZmZmZmZmZDZlMCkgPSAwICgweDApCiAg MjIyOiBtYWR2aXNlKDB4ODAyYzc1MDAwLDB4YTAwMCwweDUsMHg3NCwweGUwMDgsMHg3ZmZmZmZm ZmQ2ZTApID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgwMmM2NTAwMCwweDEwMDAwLDB4NSww eDY0LDB4MWUwMDgsMHg3ZmZmZmZmZmQ2ZTApID0gMCAoMHgwKQogIDIyMjogb3BlbigiL3Vzci9o b21lL2djb29wZXIvLm1vemMvc2VnbWVudC5kYiIsT19SRFdSLDAwKSA9IDYgKDB4NikKICAyMjI6 IGZzdGF0KDYseyBtb2RlPS1ydy1yLS1yLS0gLGlub2RlPTMwMzkyNTUsc2l6ZT0zMjAwMTIsYmxr c2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IG1tYXAoMHgwLDMyMDAxMixQUk9UX1JFQUR8 UFJPVF9XUklURSxNQVBfU0hBUkVELDYsMHgwKSA9IDM0MzgzNTExNTUyICgweDgwMTZhYzAwMCkK ICAyMjI6IGNsb3NlKDYpCQkJCQkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyZDM3MDAw LDB4ODAwMCwweDUsMHgxMzYsMHgxLDB4N2ZmZmZmZmZkNWUwKSA9IDAgKDB4MCkKICAyMjI6IG1h ZHZpc2UoMHg4MDJjZTcwMDAsMHg0MDAwLDB4NSwweGU2LDB4MSwweDdmZmZmZmZmZDVlMCkgPSAw ICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyZDJmMDAwLDB4MTAwMCwweDUsMHgxMmUsMHgxZTAw OCwweDdmZmZmZmZmZDZhMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzY1MDAwLDB4 MTAwMDAsMHg1LDB4NjQsMHgxZTAwOCwweDdmZmZmZmZmZDZhMCkgPSAwICgweDApCiAgMjIyOiBt YWR2aXNlKDB4ODAyY2UzMDAwLDB4MjAwMDAsMHg1LDB4ZTIsMHgxNzNhZTMwLDB4N2ZmZmZmZmZk NWQwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJkNDMwMDAsMHgyODAwMCwweDUsMHgx NDIsMHg4MDJjMDA5YTAsMHg3ZmZmZmZmZmQ2ZTApID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgw eDgwMmQwMzAwMCwweDQwMDAwLDB4NSwweDEwMiwweDE3M2FlMzAsMHg3ZmZmZmZmZmQ2ZDApID0g MCAoMHgwKQogIDIyMjogX3VtdHhfb3AoMHg3ZmZmZmZmZmUzZTgsMHgzLDB4MSwweDAsMHgwLDB4 MTczYWQ0MCkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJ R0lOVHxTSUdRVUlUfFNJR0FCUlR8U0lHRU1UfFNJR0tJTEx8U0lHU1lTfFNJR1BJUEV8U0lHQUxS TXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58 U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8 U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNr KFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdf QkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0FCUlR8U0lHRU1UfFNJR0tJTEx8U0lHU1lT fFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxT SUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJ R1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAy MjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBt bWFwKDB4N2ZmZmZmOWZlMDAwLDIxMDEyNDgsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1NUQUNL LC0xLDB4MCkgPSAxNDA3Mzc0ODIwNTU2ODAgKDB4N2ZmZmZmOWZlMDAwKQogIDIyMjogbXByb3Rl Y3QoMHg3ZmZmZmY5ZmUwMDAsNDA5NixQUk9UX05PTkUpCSA9IDAgKDB4MCkKICAyMjI6IHRocl9u ZXcoMHg3ZmZmZmZmZmU0MzAsMHg2OCwweDgwMWM4MTk0MCwweDE4ODFjLDB4ZmZmZmZmZmYsMHgw KSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5oaXN0b3J5 LmRiIixPX1JET05MWSwwMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIy OiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAy MjI6IGdldHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiB3cml0ZSgyLCIyMDEwLTEwLTA0 IDA3OjA2OjU4IDIyMiAzNDQwNTkwNiIuLi4sMTE3KSA9IDExNyAoMHg3NSkKICAyMjI6IGNsb2Nr X2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogZ2V0 cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIsIjIwMTAtMTAtMDQgMDc6MDY6 NTggMjIyIDM0NDA1OTA2Ii4uLiwxMTkpID0gMTE5ICgweDc3KQogIDIyMjogY2xvY2tfZ2V0dGlt ZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgweDApCiAgMjIyOiBnZXRwaWQoKQkJ CQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAxMC0xMC0wNCAwNzowNjo1OCAyMjIg MzQ0MDU5MDQiLi4uLDEzOSkgPSAxMzkgKDB4OGIpCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfQkxP Q0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0FCUlR8U0lHRU1UfFNJR0tJTEx8U0lHU1lTfFNJ R1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdD SExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BS T0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6 IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBtbWFw KDB4N2ZmZmZmN2ZkMDAwLDIxMDEyNDgsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1NUQUNLLC0x LDB4MCkgPSAxNDA3Mzc0Nzk5NTQ0MzIgKDB4N2ZmZmZmN2ZkMDAwKQogIDIyMjogbXByb3RlY3Qo MHg3ZmZmZmY3ZmQwMDAsNDA5NixQUk9UX05PTkUpCSA9IDAgKDB4MCkKICAyMjI6IHRocl9uZXco MHg3ZmZmZmZmZmUyZjAsMHg2OCwweDgwMWM4MTk0MCwweDE4ODFjLDB4ZmZmZmZmZmYsMHgwKSA9 IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FV SVR8U0lHQUJSVHxTSUdFTVR8U0lHS0lMTHxTSUdTWVN8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18 U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJ R0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJ R1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogX3VtdHhfb3AoMHg4MDFjODE0ODAs MHhkLDB4MCwweDAsMHgwLDB4MSkgPSA0NTQgKDB4MWM2KQotLSBVTktOT1dOIFNZU0NBTEwgMjk4 ODk2NjQgLS0KICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgw eDApCi0tIFVOS05PV04gU1lTQ0FMTCAtNjMwMDA4MCAtLQogIDIyMjogbW1hcCgweDdmZmZmZjVm YzAwMCwyMTAxMjQ4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9TVEFDSywtMSwweDApID0gMTQw NzM3NDc3ODUzMTg0ICgweDdmZmZmZjVmYzAwMCkKICAyMjI6IG1wcm90ZWN0KDB4N2ZmZmZmNWZj MDAwLDQwOTYsUFJPVF9OT05FKQkgPSAwICgweDApCiAgMjIyOiB0aHJfbmV3KDB4N2ZmZmZmZmZl MmIwLDB4NjgsMHg4MDFjODE5NDAsMHgxODgxYywweGZmZmZmZmZmLDB4MCkgPSAwICgweDApCiAg MjIyOiBtbWFwKDB4MCw0MTk0MzA0LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1B UF9BTk9OLC0xLDB4MCkgPSAzNDQxMDA3MDAxNiAoMHg4MDMwMDAwMDApCiAgMjIyOiBtbWFwKDB4 MCw4Mzg4NjA4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9OLC0xLDB4 MCkgPSAzNDQxNDI2NDMyMCAoMHg4MDM0MDAwMDApCiAgMjIyOiBtdW5tYXAoMHg4MDM4MDAwMDAs NDE5NDMwNCkJCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi91c3IvaG9tZS9nY29vcGVyLy5tb3pj L3VzZXJfZGljdGlvbmFyeS5kYiIsT19SRE9OTFksMDY2NikgRVJSIzIgJ05vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnknCiAgMjIyOiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAw MCB9KSA9IDAgKDB4MCkKICAyMjI6IGdldHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiB3 cml0ZSgyLCIyMDEwLTEwLTA0IDA3OjA2OjU4IDIyMiAzNDQwNTkwNyIuLi4sMTUxKSA9IDE1MSAo MHg5NykKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0g MCAoMHgwKQogIDIyMjogZ2V0cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIs IjIwMTAtMTAtMDQgMDc6MDY6NTggMjIyIDM0NDA1OTA3Ii4uLiwxNDIpID0gMTQyICgweDhlKQog IDIyMjogbWFkdmlzZSgweDgwMzAyNDAwMCwweDEwMDAsMHg1LDB4MjMsMHgxMDA4LDB4MmQpID0g MCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgwMzAyMzAwMCwweDEwMDAsMHg1LDB4MjIsMHgyMDA4 LDB4N2ZmZmZmN2ZjNDcwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDMwMjIwMDAsMHgx MDAwLDB4NSwweDIxLDB4MzAwOCwweDdmZmZmZjdmYzQ3MCkgPSAwICgweDApCiAgMjIyOiBtYWR2 aXNlKDB4ODAzMDIxMDAwLDB4MTAwMCwweDUsMHgyMCwweDQwMDgsMHg3ZmZmZmY3ZmM0NzApID0g MCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgwMzAyNjAwMCwweDEwMDAsMHg1LDB4MjUsMHgxLDB4 N2ZmZmZmN2ZjNDcwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDMwMjUwMDAsMHgxMDAw LDB4NSwweDI0LDB4N2ZmZmZmN2ZjNDYwLDB4N2ZmZmZmN2ZjNDYwKSA9IDAgKDB4MCkKICAyMjI6 IG1hZHZpc2UoMHg4MDMwMGYwMDAsMHgxMDAwLDB4NSwweGUsMHgxLDB4N2ZmZmZmN2ZjNDcwKSA9 IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDMwMGUwMDAsMHgxMDAwLDB4NSwweGQsMHgxMDAw OCwweDdmZmZmZjdmYzQzMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAzMDA3MDAwLDB4 MTAwMCwweDUsMHg2LDB4MTcwMDgsMHg3ZmZmZmY3ZmM0YzApID0gMCAoMHgwKQogIDIyMjogdGhy X2V4aXQoMHg4MDJjMDdjNDAsMHgyLDB4MCwweDE4YTBhLDB4N2ZmZmZmN2ZjNGMwLDB4N2ZmZmZm N2ZjNGMwKSA9IDQzMSAoMHgxYWYpCiAgMjIyOiBvcGVuKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96 Yy8ucmVnaXN0cnkuZGIiLE9fUkRPTkxZLDAwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeScKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0g MCAoMHgwKQogIDIyMjogZ2V0cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIs IjIwMTAtMTAtMDQgMDc6MDY6NTggMjIyIDM0NDA1OTA0Ii4uLiwxMTgpID0gMTE4ICgweDc2KQog IDIyMjogY2xvY2tfZ2V0dGltZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgweDAp CiAgMjIyOiBnZXRwaWQoKQkJCQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAxMC0x MC0wNCAwNzowNjo1OCAyMjIgMzQ0MDU5MDQiLi4uLDEyNykgPSAxMjcgKDB4N2YpCiAgMjIyOiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0FCUlR8U0lHRU1U fFNJR0tJTEx8U0lHU1lTfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJ R1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hG U1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgw KSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAw ICgweDApCiAgMjIyOiBtbWFwKDB4N2ZmZmZmM2ZiMDAwLDIxMDEyNDgsUFJPVF9SRUFEfFBST1Rf V1JJVEUsTUFQX1NUQUNLLC0xLDB4MCkgPSAxNDA3Mzc0NzU3NTE5MzYgKDB4N2ZmZmZmM2ZiMDAw KQogIDIyMjogbXByb3RlY3QoMHg3ZmZmZmYzZmIwMDAsNDA5NixQUk9UX05PTkUpCSA9IDAgKDB4 MCkKICAyMjI6IHRocl9uZXcoMHg3ZmZmZmZmZmU2NzAsMHg2OCwweDgwMWM4MTk0MCwweDE4ODFj LDB4ZmZmZmZmZmYsMHgwKSA9IDAgKDB4MCkKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYy MDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX0JMT0NL LFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdBQlJUfFNJR0VNVHxTSUdLSUxMfFNJR1NZU3xTSUdQ SVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hM RHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9G fFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjIyOiBz aWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjogbW1hcCgw eDdmZmZmZjFmYTAwMCwyMTAxMjQ4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9TVEFDSywtMSww eDApID0gMTQwNzM3NDczNjUwNjg4ICgweDdmZmZmZjFmYTAwMCkKICAyMjI6IG1tYXAoMHgwLDQx OTQzMDQsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0FOT04sLTEsMHgwKSA9 IDM0NDE4NDU4NjI0ICgweDgwMzgwMDAwMCkKICAyMjI6IG1wcm90ZWN0KDB4N2ZmZmZmMWZhMDAw LDQwOTYsUFJPVF9OT05FKQkgPSAwICgweDApCiAgMjIyOiB0aHJfbmV3KDB4N2ZmZmZmZmZlMzEw LDB4NjgsMHg4MDFjODE5NDAsMHgxODgxYywweGZmZmZmZmZmLDB4MCkgPSAwICgweDApCiAgMjIy OiBnZXRldWlkKCkJCQkJID0gMTAwMCAoMHgzZTgpCiAgMjIyOiBzdGF0KCIvZXRjL25zc3dpdGNo LmNvbmYiLHsgbW9kZT0tcnctci0tci0tICxpbm9kZT0xNDEzNTksc2l6ZT0yNTUsYmxrc2l6ZT0x NjM4NCB9KSA9IDAgKDB4MCkKLS0gVU5LTk9XTiBTWVNDQUxMIC0xMjYwMzg1NiAtLQogIDIyMjog Z2V0ZXVpZCgpCQkJCSA9IDEwMDAgKDB4M2U4KQogIDIyMjogb3BlbigiL2V0Yy9wd2QuZGIiLE9f UkRPTkxZLDAwKQkJID0gNiAoMHg2KQogIDIyMjogZmNudGwoNixGX1NFVEZELEZEX0NMT0VYRUMp CQkgPSAwICgweDApCiAgMjIyOiBmc3RhdCg2LHsgbW9kZT0tcnctci0tci0tICxpbm9kZT0xNDE1 Mzcsc2l6ZT00MDk2MCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogcmVhZCg2LCJc MFxeRlxeVWFcMFwwXDBcXkJcMFwwXF5EXE0tUlwwIi4uLiwyNjApID0gMjYwICgweDEwNCkKICAy MjI6IHByZWFkKDB4NiwweDgwMzU4YjAwMCwweDEwMDAsMHg2MDAwLDB4MSwweDApID0gNDA5NiAo MHgxMDAwKQogIDIyMjogcHJlYWQoMHg2LDB4ODAzNThjMDAwLDB4MTAwMCwweDQwMDAsMHgxLDB4 MCkgPSA0MDk2ICgweDEwMDApCiAgMjIyOiBwcmVhZCgweDYsMHg4MDM1OGQwMDAsMHgxMDAwLDB4 NTAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IHByZWFkKDB4NiwweDgwMzU4ZTAw MCwweDEwMDAsMHg3MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQogIDIyMjogcHJlYWQoMHg2 LDB4ODAzNThmMDAwLDB4MTAwMCwweDgwMDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCiAgMjIy OiBwcmVhZCgweDYsMHg4MDM1OTAwMDAsMHgxMDAwLDB4MTAwMCwweDEsMHgwKSA9IDQwOTYgKDB4 MTAwMCkKICAyMjI6IHByZWFkKDB4NiwweDgwMzU5MTAwMCwweDEwMDAsMHgyMDAwLDB4MSwweDAp ID0gNDA5NiAoMHgxMDAwKQogIDIyMjogcHJlYWQoMHg2LDB4ODAzNTkyMDAwLDB4MTAwMCwweDMw MDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCiAgMjIyOiBjbG9zZSg2KQkJCQkJID0gMCAoMHgw KQogIDIyMjogb3BlbigiL3RtcC9TRU1EYzkxYzAwOTI2OTk4IixPX1JEV1IsMDApCSBFUlIjMiAn Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYy MDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogZ2V0dGltZW9mZGF5KHsxMjg2MjAx MjE4Ljc4MzE1MSB9LDB4MCkJID0gMCAoMHgwKQogIDIyMjogY2xvY2tfZ2V0dGltZSgwLHsxMjg2 MjAxMjE4Ljc4MzE5MTI2NiB9KQkgPSAwICgweDApCiAgMjIyOiBzdGF0KCIvdXNyL3NoYXJlL25s cy9DL2xpYmMuY2F0IiwweDdmZmZmZmZmZTFmMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjIyOiBzdGF0KCIvdXNyL3NoYXJlL25scy9saWJjL0MiLDB4N2ZmZmZmZmZlMWYw KSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IHN0YXQoIi91c3IvbG9j YWwvc2hhcmUvbmxzL0MvbGliYy5jYXQiLDB4N2ZmZmZmZmZlMWYwKSBFUlIjMiAnTm8gc3VjaCBm aWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IHN0YXQoIi91c3IvbG9jYWwvc2hhcmUvbmxzL2xpYmMv QyIsMHg3ZmZmZmZmZmUxZjApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIy MjogY2xvY2tfZ2V0dGltZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgweDApCiAg MjIyOiBnZXRwaWQoKQkJCQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAxMC0xMC0w NCAwNzowNjo1OCAyMjIgMzQ0MDU5MDQiLi4uLDExNCkgPSAxMTQgKDB4NzIpCiAgMjIyOiBjbG9j a19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IGdl dHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiB3cml0ZSgyLCIyMDEwLTEwLTA0IDA3OjA2 OjU4IDIyMiAzNDQwNTkwNCIuLi4sMTA3KSA9IDEwNyAoMHg2YikKICAyMjI6IGNsb2NrX2dldHRp bWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogZ2V0cGlkKCkJ CQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIsIjIwMTAtMTAtMDQgMDc6MDY6NTggMjIy IDM0NDA1OTA0Ii4uLiwxMTEpID0gMTExICgweDZmKQogIDIyMjogc2lncHJvY21hc2soU0lHX0JM T0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdBQlJUfFNJR0VNVHxTSUdLSUxMfFNJR1NZU3xT SUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lH Q0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQ Uk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjIy OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjogbW1h cCgweDdmZmZmZWZmOTAwMCwyMTAxMjQ4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9TVEFDSywt MSwweDApID0gMTQwNzM3NDcxNTQ5NDQwICgweDdmZmZmZWZmOTAwMCkKICAyMjI6IG1wcm90ZWN0 KDB4N2ZmZmZlZmY5MDAwLDQwOTYsUFJPVF9OT05FKQkgPSAwICgweDApCiAgMjIyOiB0aHJfbmV3 KDB4N2ZmZmZmZmZlNmQwLDB4NjgsMHg4MDFjODE5NDAsMHgxODgxYywweGZmZmZmZmZmLDB4MCkg PSAwICgweDApCl5DXkMgIDIyMjogYWNjZXB0KDQsMHgwLDB4MCkJCQkgRVJSIzQgJ0ludGVycnVw dGVkIHN5c3RlbSBjYWxsJwogIDIyMjogU0lHTkFMIDE1IChTSUdURVJNKQogIDIyMjogcHJvY2Vz cyBleGl0LCBydmFsID0gMApbZ2Nvb3BlckBiYXlvbmV0dGEgL3Vzci9wb3J0cy9qYXBhbmVzZS9t b3pjLXNlcnZlcl0kIHRydXNzIC1mZiBtb3pjX3NlcnZlcgogIDIzMDogX19zeXNjdGwoMHg3ZmZm ZmZmZmUyZjAsMHgyLDB4N2ZmZmZmZmZlMzBjLDB4N2ZmZmZmZmZlMzAwLDB4MCwweDApID0gMCAo MHgwKQogIDIzMDogbW1hcCgweDAsMzI3NjgsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZB VEV8TUFQX0FOT04sLTEsMHgwKSA9IDM0MzgzMjc4MDgwICgweDgwMTY3MzAwMCkKICAyMzA6IGlz c2V0dWdpZCgweDgwMTY3NDAxNSwweDgwMTY2ZThlNCwweDdmZmZmZmZmZTk5OCwweDgwMTc4YTA0 MCwweDU3MzEsMHgwKSA9IDAgKDB4MCkKICAyMzA6IG9wZW4oIi9ldGMvbGlibWFwLmNvbmYiLE9f UkRPTkxZLDA2NjYpCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IG9w ZW4oIi92YXIvcnVuL2xkLWVsZi5zby5oaW50cyIsT19SRE9OTFksMDU3KSA9IDIgKDB4MikKICAy MzA6IHJlYWQoMiwiRWhudFxeQVwwXDBcMFxNXkBcMFwwXDBcTV5aXDBcMCIuLi4sMTI4KSA9IDEy OCAoMHg4MCkKICAyMzA6IGxzZWVrKDIsMHg4MCxTRUVLX1NFVCkJCQkgPSAxMjggKDB4ODApCiAg MjMwOiByZWFkKDIsIi9saWI6L3Vzci9saWI6L3Vzci9saWIvY29tcGF0Oi91Ii4uLiwxNTQpID0g MTU0ICgweDlhKQogIDIzMDogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMzA6IGFjY2Vzcygi L2xpYi9saWJjdXJsLnNvLjYiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnkn CiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL2xpYmN1cmwuc28uNiIsMCkJIEVSUiMyICdObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xpYi9jb21wYXQvbGliY3Vy bC5zby42IiwwKQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nl c3MoIi91c3IvbG9jYWwvbGliL2xpYmN1cmwuc28uNiIsMCkJID0gMCAoMHgwKQogIDIzMDogb3Bl bigiL3Vzci9sb2NhbC9saWIvbGliY3VybC5zby42IixPX1JET05MWSwwMTM1NzUzNzQwKSA9IDIg KDB4MikKICAyMzA6IGZzdGF0KDIseyBtb2RlPS1yd3hyLXhyLXggLGlub2RlPTI4MjYzOTcsc2l6 ZT0zNTQzNzMsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMzA6IHByZWFkKDB4MiwweDgw MTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkg PSA0MDk2ICgweDEwMDApCiAgMjMwOiBtbWFwKDB4MCwxMzU5ODcyLFBST1RfTk9ORSxNQVBfUFJJ VkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4NDQyNDk2MCAoMHg4MDE3OGIw MDApCiAgMjMwOiBtbWFwKDB4ODAxNzhiMDAwLDI4MjYyNCxQUk9UX1JFQUR8UFJPVF9FWEVDLE1B UF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0Mzg0NDI0OTYwICgweDgw MTc4YjAwMCkKICAyMzA6IG1tYXAoMHg4MDE4ZDAwMDAsMjg2NzIsUFJPVF9SRUFEfFBST1RfV1JJ VEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHg0NTAwMCkgPSAzNDM4NTc1NjE2MCAoMHg4MDE4 ZDAwMDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogYWNjZXNzKCIvbGli L2xpYmNyeXB0by5zby42IiwwKQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2xpYi9saWJjcnlw dG8uc28uNiIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAyICgweDIpCiAgMjMwOiBmc3RhdCgyLHsg bW9kZT0tci0tci0tci0tICxpbm9kZT00MDA0NDgsc2l6ZT0xNjY5MDg4LGJsa3NpemU9MTYzODQg fSkgPSAwICgweDApCiAgMjMwOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEw MTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIzMDog bW1hcCgweDAsMjcwNzQ1NixQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09S RSwtMSwweDApID0gMzQzODU3ODQ4MzIgKDB4ODAxOGQ3MDAwKQogIDIzMDogbW1hcCgweDgwMThk NzAwMCwxMzU5ODcyLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1B UF9OT0NPUkUsMiwweDApID0gMzQzODU3ODQ4MzIgKDB4ODAxOGQ3MDAwKQogIDIzMDogbW1hcCgw eDgwMWIyMzAwMCwyOTA4MTYsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJ WEVELDIsMHgxNGMwMDApID0gMzQzODgxOTMyODAgKDB4ODAxYjIzMDAwKQogIDIzMDogbXByb3Rl Y3QoMHg4MDFiNmEwMDAsODE5MixQUk9UX1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCiAgMjMw OiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogYWNjZXNzKCIvbGliL2xpYnRoci5zby4z IiwwKQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2xpYi9saWJ0aHIuc28uMyIsT19SRE9OTFks MDEzNTc1Mzc0MCkgPSAyICgweDIpCiAgMjMwOiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxp bm9kZT00MDA0MjYsc2l6ZT04Nzk1MixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDog cHJlYWQoMHgyLDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgw ODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMzA6IG1tYXAoMHgwLDExNDI3ODQsUFJP VF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzg4NDky Mjg4ICgweDgwMWI2YzAwMCkKICAyMzA6IG1tYXAoMHg4MDFiNmMwMDAsNzM3MjgsUFJPVF9SRUFE fFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM4 ODQ5MjI4OCAoMHg4MDFiNmMwMDApCiAgMjMwOiBtbWFwKDB4ODAxYzdkMDAwLDE2Mzg0LFBST1Rf UkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MTEwMDApID0gMzQzODk2 MTA0OTYgKDB4ODAxYzdkMDAwKQogIDIzMDogbXByb3RlY3QoMHg4MDFjODEwMDAsODE5MixQUk9U X1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgw KQogIDIzMDogYWNjZXNzKCIvbGliL2xpYnJ0LnNvLjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL2xpYnJ0LnNvLjEiLDApCQkg PSAwICgweDApCiAgMjMwOiBvcGVuKCIvdXNyL2xpYi9saWJydC5zby4xIixPX1JET05MWSwwMTM1 NzUzNzQwKSA9IDIgKDB4MikKICAyMzA6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2Rl PTI1Njc5MDMsc2l6ZT0yMTc0NCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDogcHJl YWQoMHgyLDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgwODA4 MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMzA6IG1tYXAoMHgwLDEwNjkwNTYsUFJPVF9O T05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzg5NjM1MDcy ICgweDgwMWM4MzAwMCkKICAyMzA6IG1tYXAoMHg4MDFjODMwMDAsMjA0ODAsUFJPVF9SRUFEfFBS T1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM4OTYz NTA3MiAoMHg4MDFjODMwMDApCiAgMjMwOiBtbWFwKDB4ODAxZDg3MDAwLDQwOTYsUFJPVF9SRUFE fFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHg0MDAwKSA9IDM0MzkwNzAwMDMy ICgweDgwMWQ4NzAwMCkKICAyMzA6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjMwOiBhY2Nl c3MoIi9saWIvbGlic3NsLnNvLjYiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL2xpYnNzbC5zby42IiwwKQkJID0gMCAoMHgwKQog IDIzMDogb3BlbigiL3Vzci9saWIvbGlic3NsLnNvLjYiLE9fUkRPTkxZLDAxMzU3NTM3NDApID0g MiAoMHgyKQogIDIzMDogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAsaW5vZGU9MjU2NzE5Mixz aXplPTMzNDE1MixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDogcHJlYWQoMHgyLDB4 ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgwODA4MDgwODA4MDgw KSA9IDQwOTYgKDB4MTAwMCkKICAyMzA6IG1tYXAoMHgwLDEzODAzNTIsUFJPVF9OT05FLE1BUF9Q UklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0MzkwNzA0MTI4ICgweDgwMWQ4 ODAwMCkKICAyMzA6IG1tYXAoMHg4MDFkODgwMDAsMjg2NzIwLFBST1RfUkVBRHxQUk9UX0VYRUMs TUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTA3MDQxMjggKDB4 ODAxZDg4MDAwKQogIDIzMDogbW1hcCgweDgwMWVjZTAwMCw0NTA1NixQUk9UX1JFQUR8UFJPVF9X UklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDQ2MDAwKSA9IDM0MzkyMDM5NDI0ICgweDgw MWVjZTAwMCkKICAyMzA6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjMwOiBhY2Nlc3MoIi9s aWIvbGliei5zby42IiwwKQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2xpYi9saWJ6LnNvLjYi LE9fUkRPTkxZLDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIzMDogZnN0YXQoMix7IG1vZGU9LXIt LXItLXItLSAsaW5vZGU9NDAwNDMwLHNpemU9ODk1MjgsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4 MCkKICAyMzA6IHByZWFkKDB4MiwweDgwMTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEw MTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgweDEwMDApCiAgMjMwOiBtbWFwKDB4MCwx MTM4Njg4LFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkg PSAzNDM5MjA4NDQ4MCAoMHg4MDFlZDkwMDApCiAgMjMwOiBtbWFwKDB4ODAxZWQ5MDAwLDgxOTIw LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiww eDApID0gMzQzOTIwODQ0ODAgKDB4ODAxZWQ5MDAwKQogIDIzMDogbW1hcCgweDgwMWZlZDAwMCw4 MTkyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MTQwMDAp ID0gMzQzOTMyMTQ5NzYgKDB4ODAxZmVkMDAwKQogIDIzMDogY2xvc2UoMikJCQkJCSA9IDAgKDB4 MCkKICAyMzA6IGFjY2VzcygiL2xpYi9saWJwcm90b2J1Zi5zby42IiwwKQkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL2xpYnByb3RvYnVm LnNvLjYiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2Vz cygiL3Vzci9saWIvY29tcGF0L2xpYnByb3RvYnVmLnNvLjYiLDApIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9saWJwcm90b2J1 Zi5zby42IiwwKSA9IDAgKDB4MCkKICAyMzA6IG9wZW4oIi91c3IvbG9jYWwvbGliL2xpYnByb3Rv YnVmLnNvLjYiLE9fUkRPTkxZLDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIzMDogZnN0YXQoMix7 IG1vZGU9LXJ3eHIteHIteCAsaW5vZGU9MjgyNzc4NCxzaXplPTE0MTMyODUsYmxrc2l6ZT0xNjM4 NCB9KSA9IDAgKDB4MCkKICAyMzA6IHByZWFkKDB4MiwweDgwMTc3YzdjMCwweDEwMDAsMHgwLDB4 MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgweDEwMDApCiAgMjMw OiBtbWFwKDB4MCwyMTgzMTY4LFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBfQU5PTnxNQVBfTk9D T1JFLC0xLDB4MCkgPSAzNDM5MzIyMzE2OCAoMHg4MDFmZWYwMDApCiAgMjMwOiBtbWFwKDB4ODAx ZmVmMDAwLDk5NTMyOCxQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxN QVBfTk9DT1JFLDIsMHgwKSA9IDM0MzkzMjIzMTY4ICgweDgwMWZlZjAwMCkKICAyMzA6IG1tYXAo MHg4MDIxZTEwMDAsMTQzMzYwLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9G SVhFRCwyLDB4ZjIwMDApID0gMzQzOTUyNjI5NzYgKDB4ODAyMWUxMDAwKQogIDIzMDogY2xvc2Uo MikJCQkJCSA9IDAgKDB4MCkKICAyMzA6IGFjY2VzcygiL2xpYi9saWJzdGRjKysuc28uNiIsMCkJ CSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9s aWIvbGlic3RkYysrLnNvLjYiLDApCSA9IDAgKDB4MCkKICAyMzA6IG9wZW4oIi91c3IvbGliL2xp YnN0ZGMrKy5zby42IixPX1JET05MWSwwMTM1NzUzNzQwKSA9IDIgKDB4MikKICAyMzA6IGZzdGF0 KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTI1NjgwMTAsc2l6ZT0xMDE4NTg0LGJsa3NpemU9 MTYzODQgfSkgPSAwICgweDApCiAgMjMwOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4 MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQog IDIzMDogbW1hcCgweDAsMjE0MjIwOCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQ X05PQ09SRSwtMSwweDApID0gMzQzOTU0MDYzMzYgKDB4ODAyMjA0MDAwKQogIDIzMDogbW1hcCgw eDgwMjIwNDAwMCw4NzY1NDQsUFJPVF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklY RUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM5NTQwNjMzNiAoMHg4MDIyMDQwMDApCiAgMjMwOiBt bWFwKDB4ODAyM2Q5MDAwLDE0MzM2MCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxN QVBfRklYRUQsMiwweGQ1MDAwKSA9IDM0Mzk3MzI3MzYwICgweDgwMjNkOTAwMCkKICAyMzA6IG1w cm90ZWN0KDB4ODAyM2ZjMDAwLDc3ODI0LFBST1RfUkVBRHxQUk9UX1dSSVRFKSA9IDAgKDB4MCkK ICAyMzA6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjMwOiBhY2Nlc3MoIi9saWIvbGlibS5z by41IiwwKQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2xpYi9saWJtLnNvLjUiLE9fUkRPTkxZ LDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIzMDogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAs aW5vZGU9NDAwMzkxLHNpemU9MTM2NzQ0LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjMw OiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgw ODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIzMDogbW1hcCgweDAsMTE3NTU1MixQ Uk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTc1 NDg1NDQgKDB4ODAyNDBmMDAwKQogIDIzMDogbW1hcCgweDgwMjQwZjAwMCwxMjI4ODAsUFJPVF9S RUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAz NDM5NzU0ODU0NCAoMHg4MDI0MGYwMDApCiAgMjMwOiBtbWFwKDB4ODAyNTJjMDAwLDgxOTIsUFJP VF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHgxZDAwMCkgPSAzNDM5 ODcxNTkwNCAoMHg4MDI1MmMwMDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIz MDogYWNjZXNzKCIvbGliL2xpYmdjY19zLnNvLjEiLDApCQkgPSAwICgweDApCiAgMjMwOiBvcGVu KCIvbGliL2xpYmdjY19zLnNvLjEiLE9fUkRPTkxZLDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIz MDogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAsaW5vZGU9NDAwNDQ0LHNpemU9NTYxOTIsYmxr c2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMzA6IHByZWFkKDB4MiwweDgwMTc3YzdjMCwweDEw MDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgweDEw MDApCiAgMjMwOiBtbWFwKDB4MCwxMTAxODI0LFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBfQU5P TnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM5ODcyNDA5NiAoMHg4MDI1MmUwMDApCiAgMjMwOiBt bWFwKDB4ODAyNTJlMDAwLDQ5MTUyLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQ X0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTg3MjQwOTYgKDB4ODAyNTJlMDAwKQogIDIz MDogbW1hcCgweDgwMjYzOTAwMCw4MTkyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRF fE1BUF9GSVhFRCwyLDB4YjAwMCkgPSAzNDM5OTgxNzcyOCAoMHg4MDI2MzkwMDApCiAgMjMwOiBj bG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogYWNjZXNzKCIvbGliL2xpYmMuc28uNyIsMCkJ CSA9IDAgKDB4MCkKICAyMzA6IG9wZW4oIi9saWIvbGliYy5zby43IixPX1JET05MWSwwMTM1NzUz NzQwKSA9IDIgKDB4MikKICAyMzA6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQw MDM4OCxzaXplPTExODAwMDgsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMzA6IHByZWFk KDB4MiwweDgwMTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4 MDgwODA4MCkgPSA0MDk2ICgweDEwMDApCiAgMjMwOiBtbWFwKDB4MCwyMzA2MDQ4LFBST1RfTk9O RSxNQVBfUFJJVkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM5OTgyNTkyMCAo MHg4MDI2M2IwMDApCiAgMjMwOiBtbWFwKDB4ODAyNjNiMDAwLDEwMTU4MDgsUFJPVF9SRUFEfFBS T1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM5OTgy NTkyMCAoMHg4MDI2M2IwMDApCiAgMjMwOiBtbWFwKDB4ODAyODMzMDAwLDEzMTA3MixQUk9UX1JF QUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweGY4MDAwKSA9IDM0NDAxODkw MzA0ICgweDgwMjgzMzAwMCkKICAyMzA6IG1wcm90ZWN0KDB4ODAyODUzMDAwLDExMDU5MixQUk9U X1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgw KQogIDIzMDogc3lzYXJjaCgweDgxLDB4N2ZmZmZmZmZlNDAwLDB4ODAxNjc4NjA4LDB4MCwweGZm ZmZmZmZmZmVlM2JlZDAsMHg4MDgwODA4MDgwODA4MDgwKSA9IDAgKDB4MCkKICAyMzA6IG1tYXAo MHgwLDQ1MDU2LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9OLC0xLDB4 MCkgPSAzNDM4MzMxMDg0OCAoMHg4MDE2N2IwMDApCiAgMjMwOiBtdW5tYXAoMHg4MDE2N2YwMDAs Mjg2NzIpCQkgPSAwICgweDApCiAgMjMwOiBtbWFwKDB4MCwxMDI0MDAsUFJPVF9SRUFEfFBST1Rf V1JJVEUsTUFQX1BSSVZBVEV8TUFQX0FOT04sLTEsMHgwKSA9IDM0MzgzMzI3MjMyICgweDgwMTY3 ZjAwMCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8 U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJ R0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZU QUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgw eDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQog IDIzMDogX19zeXNjdGwoMHg3ZmZmZmZmZmUzOTAsMHgyLDB4ODAyODU5MzIwLDB4N2ZmZmZmZmZl Mzg4LDB4MCwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hV UHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xT SUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdY Q1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJ R1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCww eDApCQkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lO VHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8 U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lH WEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiww eDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9 IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FV SVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQ fFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJ R1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAw ICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgw KQogIDIzMDogZ2V0cGlkKCkJCQkJCSA9IDIzMCAoMHhlNikKICAyMzA6IF9fc3lzY3RsKDB4N2Zm ZmZmZmZlMzUwLDB4MiwweDgwMWM4MmU3MCwweDdmZmZmZmZmZTM1OCwweDAsMHgwKSA9IDAgKDB4 MCkKICAyMzA6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMjcwLDB4MiwweDdmZmZmZmZmZTI5MCwweDdm ZmZmZmZmZTJmOCwweDgwMWI3Y2ZkOCwweGQpID0gMCAoMHgwKQogIDIzMDogX19zeXNjdGwoMHg3 ZmZmZmZmZmUyOTAsMHgzLDB4ODAxYzgxZDY4LDB4N2ZmZmZmZmZlMzU4LDB4MCwweDApID0gMCAo MHgwKQogIDIzMDogX19zeXNjdGwoMHg3ZmZmZmZmZmRlMDAsMHgyLDB4N2ZmZmZmZmZkZTJjLDB4 N2ZmZmZmZmZkZTIwLDB4MCwweDApID0gMCAoMHgwKQogIDIzMDogX19zeXNjdGwoMHg3ZmZmZmZm ZmRjZjAsMHgyLDB4N2ZmZmZmZmZkZDEwLDB4N2ZmZmZmZmZkZDc4LDB4ODAyNzI2NTQwLDB4Yykg PSAwICgweDApCiAgMjMwOiBfX3N5c2N0bCgweDdmZmZmZmZmZGQxMCwweDIsMHg4MDI4NThkNzAs MHg3ZmZmZmZmZmRkYzAsMHgwLDB4MCkgPSAwICgweDApCiAgMjMwOiByZWFkbGluaygiL2V0Yy9t YWxsb2MuY29uZiIsMHg3ZmZmZmZmZmRlMzAsMTAyNCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBk aXJlY3RvcnknCiAgMjMwOiBpc3NldHVnaWQoMHg4MDI3MjUxNGYsMHg3ZmZmZmZmZmRlMzAsMHhm ZmZmZmZmZmZmZmZmZmZmLDB4MCwweDIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IGJyZWFrKDB4MTgw MDAwMCkJCQkJID0gMCAoMHgwKQogIDIzMDogX19zeXNjdGwoMHg3ZmZmZmZmZmRlNTAsMHgyLDB4 N2ZmZmZmZmZkZTZjLDB4N2ZmZmZmZmZkZTYwLDB4MCwweDApID0gMCAoMHgwKQogIDIzMDogbW1h cCgweDAsNDE5NDMwNCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwt MSwweDApID0gMzQ0MDIxMzE5NjggKDB4ODAyODZlMDAwKQogIDIzMDogbW1hcCgweDgwMmM2ZTAw MCwzNzQzNzQ0LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9OLC0xLDB4 MCkgPSAzNDQwNjMyNjI3MiAoMHg4MDJjNmUwMDApCiAgMjMwOiBtdW5tYXAoMHg4MDI4NmUwMDAs Mzc0Mzc0NCkJCSA9IDAgKDB4MCkKICAyMzA6IHRocl9zZWxmKDB4ODAyYzA3MWMwLDB4MCwweDAs MHgwLDB4MTg4LDB4MTczYWQ0MCkgPSAwICgweDApCiAgMjMwOiBtbWFwKDB4N2ZmZmZmYmZmMDAw LDQwOTYsUFJPVF9OT05FLE1BUF9BTk9OLC0xLDB4MCkgPSAxNDA3Mzc0ODQxNTY5MjggKDB4N2Zm ZmZmYmZmMDAwKQogIDIzMDogdGhyX3NldF9uYW1lKDB4MTg4YzcsMHg4MDFiN2QwMjAsMHgwLDB4 MTAwMCwweGZmZmZmZmZmLDB4MCkgPSAwICgweDApCiAgMjMwOiBydHByaW9fdGhyZWFkKDB4MCww eDE4OGM3LDB4N2ZmZmZmZmZlMzAwLDB4MTAwMCwweGZmZmZmZmZmLDB4MCkgPSAwICgweDApCiAg MjMwOiBzeXNhcmNoKDB4ODEsMHg3ZmZmZmZmZmUzMjAsMHg4MDFjODE5NDAsMHg4MDFjODFjYzgs MHhmZmZmZmZmZiwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ss U0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0lMTHxTSUdBQlJUfFNJR0VNVHxTSUdGUEV8U0lHS0lM THxTSUdCVVN8U0lHU0VHVnxTSUdTWVN8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJ R1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hD UFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lH VVNSMiwweDApID0gMCAoMHgwKQogIDIzMDogc2lnYWN0aW9uKDMyLHsgMHg4MDFiNzczNzUgU0Ff UkVTVEFSVHxTQV9TSUdJTkZPIHNzX3QgfSwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21h c2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJ R19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lH VEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RU T1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lO Rk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdf U0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NL LFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJ R1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJ T3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdV U1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNL LDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyYzBmMDAwLDB4MTAwMCww eDUsMHhlLDB4MjAwOCwweGIpID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMwZjAwMCww eDEwMDAsMHg1LDB4ZSwweDIwMDgsMHg3ZmZmZmZmZmQ3NDApID0gMCAoMHgwKQogIDIzMDogbWFk dmlzZSgweDgwMmMyMDAwMCwweDEwMDAsMHg1LDB4MWYsMHgyMDA4LDB4MTczYWQ0MCkgPSAwICgw eDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyYzI2MDAwLDB4MTAwMCwweDUsMHgyNSwweDUwMDgsMHg3 ZmZmZmZmZmQ1ODApID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMyMjAwMCwweDEwMDAs MHg1LDB4MjEsMHg1MDA4LDB4N2ZmZmZmZmZkNTgwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2Uo MHg4MDJjMWUwMDAsMHgxMDAwLDB4NSwweDFkLDB4MjAwOCwweDdmZmZmZmZmZDU4MCkgPSAwICgw eDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyYzE5MDAwLDB4MTAwMCwweDUsMHgxOCwweDEsMHg3ZmZm ZmZmZmQ1YTApID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMxODAwMCwweDEwMDAsMHg1 LDB4MTcsMHgxNzNhZTMwLDB4N2ZmZmZmZmZkNWUwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2Uo MHg4MDJjMjAwMDAsMHgxMDAwLDB4NSwweDFmLDB4ZjAwMCwweDdmZmZmZmZmZDYwMCkgPSAwICgw eDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyYzFhMDAwLDB4MTAwMCwweDUsMHgxOSwweDEwMDgsMHgx NzNhZDQwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lH SU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RP UHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxT SUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1Iy LDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJ ID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lH UVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RT VFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8 U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9 IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgw eDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJ R0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdD T05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFM Uk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgw KQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAy MzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxT SUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lH Q0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQ Uk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMw OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2ln cHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8 U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJ R1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lH V0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3By b2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFz ayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJN fFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxT SUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxT SUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2so U0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2UoMHg4MDJjNDQw MDAsMHgxMDAwLDB4NSwweDQzLDB4MSwweDdmZmZmZmZmZGFhMCkgPSAwICgweDApCiAgMjMwOiBt YWR2aXNlKDB4ODAyYzNkMDAwLDB4MTAwMCwweDUsMHgzYywweDEsMHg3ZmZmZmZmZmRhYTApID0g MCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMzYzAwMCwweDEwMDAsMHg1LDB4M2IsMHgxNzNh ZTMwLDB4N2ZmZmZmZmZkYjcwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2UoMHg4MDJjMjUwMDAs MHgxMDAwLDB4NSwweDI0LDB4MTczYWUzMCwweDdmZmZmZmZmZGI3MCkgPSAwICgweDApCiAgMjMw OiBtYWR2aXNlKDB4ODAyYzI0MDAwLDB4MTAwMCwweDUsMHgyMywweDEsMHg3ZmZmZmZmZmRhZjAp ID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMxYzAwMCwweDIwMDAsMHg1LDB4MWIsMHgx LDB4N2ZmZmZmZmZkYWYwKSA9IDAgKDB4MCkKICAyMzA6IGdldGV1aWQoKQkJCQkgPSAxMDAwICgw eDNlOCkKICAyMzA6IGdldHVpZCgpCQkJCQkgPSAxMDAwICgweDNlOCkKICAyMzA6IGdldGV1aWQo KQkJCQkgPSAxMDAwICgweDNlOCkKICAyMzA6IHN0YXQoIi9ldGMvbnNzd2l0Y2guY29uZiIseyBt b2RlPS1ydy1yLS1yLS0gLGlub2RlPTE0MTM1OSxzaXplPTI1NSxibGtzaXplPTE2Mzg0IH0pID0g MCAoMHgwKQogIDIzMDogb3BlbigiL2V0Yy9uc3N3aXRjaC5jb25mIixPX1JET05MWSwwNjY2KQkg PSAyICgweDIpCiAgMjMwOiBpb2N0bCgyLFRJT0NHRVRBLDB4ZmZmZmRkODApCQkgRVJSIzI1ICdJ bmFwcHJvcHJpYXRlIGlvY3RsIGZvciBkZXZpY2UnCiAgMjMwOiBmc3RhdCgyLHsgbW9kZT0tcnct ci0tci0tICxpbm9kZT0xNDEzNTksc2l6ZT0yNTUsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkK ICAyMzA6IHJlYWQoMiwiI1xuIyBuc3N3aXRjaC5jb25mKDUpIC0gbmFtZSBzZXIiLi4uLDE2Mzg0 KSA9IDI1NSAoMHhmZikKICAyMzA6IHJlYWQoMiwweDgwMmM1NDAwMCwxNjM4NCkJCSA9IDAgKDB4 MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lH S0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NP TlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxS TXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDAp CiAgMjMwOiBhY2Nlc3MoIi9saWIvbnNzX2NvbXBhdC5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xpYi9uc3NfY29tcGF0LnNv LjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2Vzcygi L3Vzci9saWIvY29tcGF0L25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL25zc19jb21wYXQuc28u MSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91 c3IvbG9jYWwva2RlNC9saWIvbnNzX2NvbXBhdC5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxl IG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvY29tcGF0L25zc19j b21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBh Y2Nlc3MoIi91c3IvbG9jYWwvbGliL2dlZ2wtMC4xL25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGli L2dyYXBodml6L25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL3F0NC9uc3NfY29tcGF0LnNvLjEi LDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvbGli L25zc19jb21wYXQuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScK ICAyMzA6IGFjY2VzcygiL3Vzci9saWIvbnNzX2NvbXBhdC5zby4xIiwwKQkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAs MHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJ TlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9Q fFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJ R1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIs MHgwKSA9IDAgKDB4MCkKICAyMzA6IGFjY2VzcygiL2xpYi9uc3NfbmlzLnNvLjEiLDApCQkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL25z c19uaXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDog YWNjZXNzKCIvdXNyL2xpYi9jb21wYXQvbnNzX25pcy5zby4xIiwwKQkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL25zc19uaXMu c28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNz KCIvdXNyL2xvY2FsL2tkZTQvbGliL25zc19uaXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2NvbXBhdC9uc3Nf bmlzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNj ZXNzKCIvdXNyL2xvY2FsL2xpYi9nZWdsLTAuMS9uc3NfbmlzLnNvLjEiLDApIEVSUiMyICdObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9ncmFw aHZpei9uc3NfbmlzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwog IDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9xdDQvbnNzX25pcy5zby4xIiwwKSBFUlIjMiAn Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL2xpYi9uc3NfbmlzLnNv LjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3Mo Ii91c3IvbGliL25zc19uaXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkK ICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lM THxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8 U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxT SUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAg MjMwOiBhY2Nlc3MoIi9saWIvbnNzX2ZpbGVzLnNvLjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL25zc19maWxlcy5zby4xIiww KQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3Iv bGliL2NvbXBhdC9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL25zc19maWxlcy5zby4xIiwwKSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2Nh bC9rZGU0L2xpYi9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2NvbXBhdC9uc3NfZmlsZXMuc28u MSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91 c3IvbG9jYWwvbGliL2dlZ2wtMC4xL25zc19maWxlcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBm aWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXov bnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIz MDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9xdDQvbnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvbGliL25zc19maWxlcy5z by4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNz KCIvdXNyL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5JwogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4 MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lH S0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NP TlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxS TXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDAp CiAgMjMwOiBhY2Nlc3MoIi9saWIvbnNzX2Rucy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xpYi9uc3NfZG5zLnNvLjEiLDAp CSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9s aWIvY29tcGF0L25zc19kbnMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfZG5zLnNvLjEiLDApCSBFUlIj MiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2NhbC9r ZGU0L2xpYi9uc3NfZG5zLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 JwogIDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX2Rucy5zby4xIiwwKSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2Nh bC9saWIvZ2VnbC0wLjEvbnNzX2Rucy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXovbnNzX2Rucy5z by4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2Vzcygi L3Vzci9sb2NhbC9saWIvcXQ0L25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi9saWIvbnNzX2Rucy5zby4xIiwwKQkJIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xpYi9uc3Nf ZG5zLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IHNp Z3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBpb2N0bCgy LFRJT0NHRVRBLDB4ZmZmZmRkOTApCQkgRVJSIzI1ICdJbmFwcHJvcHJpYXRlIGlvY3RsIGZvciBk ZXZpY2UnCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgw MmM1NDAwMCwweDQwMDAsMHg1LDB4NTMsMHg0YzAwOCwweDgwMjg1YWZjMCkgPSAwICgweDApCiAg MjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8 U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJ R0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lH UFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIz MDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IHNp Z3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBF fFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxT SUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJ R1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdw cm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIzMDogZ2V0ZXVpZCgp CQkJCSA9IDEwMDAgKDB4M2U4KQogIDIzMDogb3BlbigiL2V0Yy9wd2QuZGIiLE9fUkRPTkxZLDAw KQkJID0gMiAoMHgyKQogIDIzMDogZmNudGwoMixGX1NFVEZELEZEX0NMT0VYRUMpCQkgPSAwICgw eDApCiAgMjMwOiBmc3RhdCgyLHsgbW9kZT0tcnctci0tci0tICxpbm9kZT0xNDE1Mzcsc2l6ZT00 MDk2MCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDogcmVhZCgyLCJcMFxeRlxeVWFc MFwwXDBcXkJcMFwwXF5EXE0tUlwwIi4uLiwyNjApID0gMjYwICgweDEwNCkKICAyMzA6IHByZWFk KDB4MiwweDgwMmNhMjAwMCwweDEwMDAsMHg2MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQog IDIzMDogcHJlYWQoMHgyLDB4ODAyY2EzMDAwLDB4MTAwMCwweDQwMDAsMHgxLDB4MCkgPSA0MDk2 ICgweDEwMDApCiAgMjMwOiBwcmVhZCgweDIsMHg4MDJjYTQwMDAsMHgxMDAwLDB4NTAwMCwweDEs MHgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMzA6IHByZWFkKDB4MiwweDgwMmNhNTAwMCwweDEwMDAs MHg3MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQogIDIzMDogcHJlYWQoMHgyLDB4ODAyY2E2 MDAwLDB4MTAwMCwweDgwMDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCiAgMjMwOiBwcmVhZCgw eDIsMHg4MDJjYTcwMDAsMHgxMDAwLDB4MTAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKICAy MzA6IHByZWFkKDB4MiwweDgwMmNhODAwMCwweDEwMDAsMHgyMDAwLDB4MSwweDApID0gNDA5NiAo MHgxMDAwKQogIDIzMDogcHJlYWQoMHgyLDB4ODAyY2E5MDAwLDB4MTAwMCwweDMwMDAsMHgxLDB4 MCkgPSA0MDk2ICgweDEwMDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyY2E4MDAwLDB4MjAwMCwweDUs MHhhNywweDEsMHgwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2UoMHg4MDJjYTIwMDAsMHg0MDAw LDB4NSwweGExLDB4MSwweDApID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmNhNjAwMCww eDIwMDAsMHg1LDB4YTUsMHgxLDB4N2ZmZmZmZmZkMjEwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZp c2UoMHg4MDJjYTEwMDAsMHgxMDAwLDB4NSwweGEwLDB4MSwweDdmZmZmZmZmZDIxMCkgPSAwICgw eDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmM1 OTAwMCwweDIwMDAsMHg1LDB4NTgsMHg0YzAwOCwweDdmZmZmZmZmZDI1MCkgPSAwICgweDApCiAg MjMwOiBta2RpcigiL3Vzci9ob21lL2djb29wZXIvLm1vemMiLDA3MDApCSBFUlIjMTcgJ0ZpbGUg ZXhpc3RzJwogIDIzMDogc3RhdCgiL3Vzci9ob21lL2djb29wZXIvLm1vemMiLHsgbW9kZT1kcnd4 LS0tLS0tICxpbm9kZT0zMDM5MjUxLHNpemU9NTEyLGJsa3NpemU9MTYzODQgfSkgPSAwICgweDAp CiAgMjMwOiBvcGVuKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96Yy9tb3pjX3NlcnZlci5sb2ciLE9f V1JPTkxZfE9fQVBQRU5EfE9fQ1JFQVQsMDY2NikgPSAyICgweDIpCiAgMjMwOiBsc2VlaygyLDB4 MCxTRUVLX0VORCkJCQkgPSAyMjYzICgweDhkNykKICAyMzA6IGNobW9kKCIvdXNyL2hvbWUvZ2Nv b3Blci8ubW96Yy9tb3pjX3NlcnZlci5sb2ciLDA2MDApID0gMCAoMHgwKQogIDIzMDogY2xvY2tf Z2V0dGltZSgxMyx7MTI4NjIwMTI0NS4wMDAwMDAwMDAgfSkgPSAwICgweDApCiAgMjMwOiBhY2Nl c3MoIi9ldGMvbG9jYWx0aW1lIiw0KQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2V0Yy9sb2Nh bHRpbWUiLE9fUkRPTkxZLDAxKQkgPSAzICgweDMpCiAgMjMwOiBmc3RhdCgzLHsgbW9kZT0tci0t ci0tci0tICxpbm9kZT0xNDE0MDMsc2l6ZT0yODE5LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDAp CiAgMjMwOiByZWFkKDMsIlRaaWYyXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDAiLi4uLDQxNDQ4 KSA9IDI4MTkgKDB4YjAzKQogIDIzMDogY2xvc2UoMykJCQkJCSA9IDAgKDB4MCkKICAyMzA6IGlz c2V0dWdpZCgweDgwMjcyY2U1OSwweDdmZmZmZmZmOWMxMCwweDAsMHg3ZmZmZmZmZWZhMjUsMHg1 MCwweDgpID0gMCAoMHgwKQogIDIzMDogb3BlbigiL3Vzci9zaGFyZS96b25laW5mby9wb3NpeHJ1 bGVzIixPX1JET05MWSwwNTYpID0gMyAoMHgzKQogIDIzMDogZnN0YXQoMyx7IG1vZGU9LXItLXIt LXItLSAsaW5vZGU9MjE1MDUxNCxzaXplPTM1MTksYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkK ICAyMzA6IHJlYWQoMywiVFppZjJcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sNDE0NDgp ID0gMzUxOSAoMHhkYmYpCiAgMjMwOiBjbG9zZSgzKQkJCQkJID0gMCAoMHgwKQogIDIzMDogZ2V0 cGlkKCkJCQkJCSA9IDIzMCAoMHhlNikKICAyMzA6IHdyaXRlKDIsIkxvZyBmaWxlIGNyZWF0ZWQg YXQ6IDIwMTAtMTAtMDQgIi4uLiw1NykgPSA1NyAoMHgzOSkKICAyMzA6IHdyaXRlKDIsIlByb2dy YW0gbmFtZTogbW96Y19zZXJ2ZXJcbiIsMjYpID0gMjYgKDB4MWEpCiAgMjMwOiBjaG1vZCgiL3Vz ci9ob21lL2djb29wZXIvLm1vemMvLnNlcnZlci5sb2NrIiwwNjAwKSA9IDAgKDB4MCkKICAyMzA6 IG9wZW4oIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5zZXJ2ZXIubG9jayIsT19SRFdSfE9fQ1JF QVR8T19UUlVOQywwNjAwKSA9IDMgKDB4MykKICAyMzA6IGZjbnRsKDMsRl9TRVRMSywweDdmZmZm ZmZmZTVmMCkJCSA9IDAgKDB4MCkKICAyMzA6IGNobW9kKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96 Yy8uc2VydmVyLmxvY2siLDA0MDApID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2Rldi91cmFuZG9t IixPX1JET05MWSwwNjY2KQkgPSA0ICgweDQpCiAgMjMwOiByZWFkKDQsIlxNLTxcTS1bcUNcXl5d dlxNLXJcTS1lX1xNXl5eIi4uLiwxMDIzKSA9IDEwMjMgKDB4M2ZmKQogIDIzMDogY2xvc2UoNCkJ CQkJCSA9IDAgKDB4MCkKICAyMzA6IHN0YXQoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5zZXNz aW9uLmlwYyIseyBtb2RlPS1yLS0tLS0tLS0gLGlub2RlPTMwMzkyNTMsc2l6ZT01NSxibGtzaXpl PTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDogb3BlbigiL3Vzci9ob21lL2djb29wZXIvLm1vemMv LnNlc3Npb24uaXBjIixPX1JET05MWSwwNjY2KSA9IDQgKDB4NCkKICAyMzA6IHJlYWQoNCwiXG4g ZWZkMjFkZmI2ZmMwMmQ5MmIzNzc1YzBiOTE5MTgiLi4uLDgxOTIpID0gNTUgKDB4MzcpCiAgMjMw OiByZWFkKDQsMHg4MDJjZTQwMzcsODEzNykJCQkgPSAwICgweDApCiAgMjMwOiBzdGF0KCIvdXNy L2hvbWUvZ2Nvb3Blci8ubW96Yy8uc2Vzc2lvbi5pcGMiLHsgbW9kZT0tci0tLS0tLS0tICxpbm9k ZT0zMDM5MjUzLHNpemU9NTUsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMzA6IGNsb3Nl KDQpCQkJCQkgPSAwICgweDApCiAgMjMwOiBta2RpcigiL3RtcCIsMDcwMCkJCQkgRVJSIzE3ICdG aWxlIGV4aXN0cycKICAyMzA6IHNvY2tldChQRl9MT0NBTCxTT0NLX1NUUkVBTSwwKQkJID0gNCAo MHg0KQogIDIzMDogZmNudGwoNCxGX0dFVEZELCkJCQkgPSAwICgweDApCiAgMjMwOiBmY250bCg0 LEZfU0VURkQsRkRfQ0xPRVhFQykJCSA9IDAgKDB4MCkKICAyMzA6IHNldHNvY2tvcHQoMHg0LDB4 ZmZmZiwweDQsMHg3ZmZmZmZmZmU2N2MsMHg0LDB4NCkgPSAwICgweDApCiAgMjMwOiBiaW5kKDQs eyBBRl9VTklYICIvdG1wLy5tb3pjLmVmZDIxZGZiNmZjMDJkOTJiMzc3NWMwYjkxOTE4YTE5LnNl c3Npb24iIH0sMTA2KSBFUlIjNDggJ0FkZHJlc3MgYWxyZWFkeSBpbiB1c2UnCiAgMjMwOiBzdGF0 KCIvdXNyL3NoYXJlL25scy9DL2xpYmMuY2F0IiwweDdmZmZmZmZmZTBhMCkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBzdGF0KCIvdXNyL3NoYXJlL25scy9saWJjL0Mi LDB4N2ZmZmZmZmZlMGEwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6 IHN0YXQoIi91c3IvbG9jYWwvc2hhcmUvbmxzL0MvbGliYy5jYXQiLDB4N2ZmZmZmZmZlMGEwKSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IHN0YXQoIi91c3IvbG9jYWwv c2hhcmUvbmxzL2xpYmMvQyIsMHg3ZmZmZmZmZmUwYTApIEVSUiMyICdObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5JwogIDIzMDogY2xvY2tfZ2V0dGltZSgxMyx7MTI4NjIwMTI0NS4wMDAwMDAwMDAg fSkgPSAwICgweDApCiAgMjMwOiBnZXRwaWQoKQkJCQkJID0gMjMwICgweGU2KQogIDIzMDogd3Jp dGUoMiwiMjAxMC0xMC0wNCAwNzowNzoyNSAyMzAgMzQ0MDU5MDQiLi4uLDEwNikgPSAxMDYgKDB4 NmEpCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmNl NDAwMCwweDIwMDAsMHg1LDB4ZTMsMHgxMDA4LDB4N2ZmZmZmZmZkYTQwKSA9IDAgKDB4MCkKICAy MzA6IG1hZHZpc2UoMHg4MDJjZTIwMDAsMHgxMDAwLDB4NSwweGUxLDB4MTAwOCwweDdmZmZmZmZm ZGE0MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lO VHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8 U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lH WEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiww eDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9 IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FV SVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQ fFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJ R1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAw ICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgw KQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdL SUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09O VHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJN fFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkK ICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMw OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lH UElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NI TER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJP RnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIzMDog c2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IHNpZ3By b2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJ R0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdU VElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJ TkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9j bWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2so U0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxT SUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lH VFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lH SU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJ R19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxP Q0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18 U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJ R0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJ R1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1B U0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdI VVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8 U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lH WENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxT SUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAs MHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJ TlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9Q fFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJ R1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIs MHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkg PSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdR VUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNU UHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxT SUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0g MCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4 MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lH S0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NP TlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxS TXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDAp CiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIz MDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJ R1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdD SExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BS T0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6 IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBwcm9j ZXNzIGV4aXQsIHJ2YWwgPSAyNTUK --0016e6509cc27bfbb10491cb3c91-- From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 19:11:03 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 440A9106566B for ; Mon, 4 Oct 2010 19:11:03 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 9757B8FC14 for ; Mon, 4 Oct 2010 19:10:51 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7397445E8E; Mon, 4 Oct 2010 21:10:50 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3DE1C45E6F; Mon, 4 Oct 2010 21:10:45 +0200 (CEST) Date: Mon, 4 Oct 2010 21:10:18 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20101004191018.GI7322@garage.freebsd.pl> References: <86hbh3igw4.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="va4/JQ6j8/8uipEp" Content-Disposition: inline In-Reply-To: <86hbh3igw4.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: hastd: zombies after hooks X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:11:03 -0000 --va4/JQ6j8/8uipEp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 03, 2010 at 03:45:47PM +0300, Mikolaj Golub wrote: > Hi, >=20 > After recent changes hastd does not garbage collect finished hooks leaving > zombies and messages in log like below: >=20 > Oct 3 18:21:05 bolek hastd[5144]: Hook is running for 1330 seconds (pid= =3D5223, cmd=3D[/usr/bin/true connect storage]). >=20 > This is because wait3() in hook_check() is never called (we never call > hook_check(true)). Below is a patch that works for me.=20 We don't call it, because it is not needed anymore. I believe there is a problem, but I think it must be somewhere else. In the main process there are two kinds of processes we fork: worker=20 processes and hook processes. When SIGCHLD is received we call=20 child_exit(), which first check if this is worker process (corresponding resource is configured). If this is not worker process then it must be hook process, so it calls hook_check_one(). I'll try to reproduce it and will get back to you. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --va4/JQ6j8/8uipEp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyqJpoACgkQForvXbEpPzTdEACdEvsCxDzuqa6jnK6LqwtgsR4v hb0AoKLtTYJwYzaB+zaUSoml/PkgDiSs =CwCp -----END PGP SIGNATURE----- --va4/JQ6j8/8uipEp-- From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 20:21:24 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AEC3106567A for ; Mon, 4 Oct 2010 20:21:24 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from firewall.mikej.com (loudsl01-253-111-133.iglou.com [64.253.111.133]) by mx1.freebsd.org (Postfix) with ESMTP id B69ED8FC17 for ; Mon, 4 Oct 2010 20:21:22 +0000 (UTC) Received: from firewall.mikej.com (localhost.mikej.com [127.0.0.1]) by firewall.mikej.com (8.13.3/8.13.3) with ESMTP id o94Jou8O017857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Oct 2010 15:50:56 -0400 (EDT) (envelope-from mikej@www.mikej.com) Authentication-Results: firewall.mikej.com; sender-id=none header.from=mikej@www.mikej.com; spf=none smtp.mfrom=mikej@www.mikej.com Received: (from www@localhost) by firewall.mikej.com (8.13.3/8.13.4/Submit) id o94Jou9T017856; Mon, 4 Oct 2010 15:50:56 -0400 (EDT) (envelope-from mikej@www.mikej.com) X-Authentication-Warning: firewall.mikej.com: www set sender to mikej@www.mikej.com using -f To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Mon, 04 Oct 2010 15:50:56 -0400 From: mikej Message-ID: <1fba977d953d205dc03e45446b827f6e@localhost> X-Sender: mikej@www.mikej.com User-Agent: RoundCube Webmail/0.4-beta Subject: ZFS v28 and proper checkout from CVS / Creating of new pools X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 20:21:24 -0000 After reading the patch announcement, and reading the patched applied against head of that day I did: *default host=cvsup5.freebsd.org *default base=/usr *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix *default compress delete date=2010.09.01.00.00.00 src-all The patches seemed to apply cleanly. Rebuilt world and kernel, installed, ran mergemaster and rebooted. Kernel shows ZFS FS version 5, storage pool28 and user land tools look to be updated. file shows zpool built for FreeBSD 9.0 and date/time stamps look good. My problem, I cannot create a zpool. I've tried creating against raw drives, against GPT partitions and always I get the error (root@charon) /home/staff/mikej/zfs# zpool create tank raidz2 da1 da2 da3 da4 da5 da6 da7 da8 spare da9 cannot create 'tank': invalid argument for this pool operation (root@charon) /home/staff/mikej/zfs# zpool ceate -n .... show no errors. If I run a 8.x kernel all works as expected. Did I botch the CVS checkout? Ideas? Thanks. Mike From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 20:59:27 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B66B81065674 for ; Mon, 4 Oct 2010 20:59:27 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 409C88FC1C for ; Mon, 4 Oct 2010 20:59:26 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DABD745DD8; Mon, 4 Oct 2010 22:59:25 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7B88545CDC; Mon, 4 Oct 2010 22:59:20 +0200 (CEST) Date: Mon, 4 Oct 2010 22:58:54 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20101004205854.GJ7322@garage.freebsd.pl> References: <86hbh44wgl.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUvfsPTz/SzOZDdw" Content-Disposition: inline In-Reply-To: <86hbh44wgl.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: hastd: assertion (res->hr_event != NULL) fails in secondary on split-brain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 20:59:27 -0000 --fUvfsPTz/SzOZDdw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 02, 2010 at 03:20:58PM +0300, Mikolaj Golub wrote: > Hi, >=20 > After recent changes in hastd (I think r213006: Fix descriptor leaks) if > split-brain occurs hastd will abort in child_cleanup() on assertion > (res->hr_event !=3D NULL). >=20 > Oct 2 17:24:17 lolek hastd[39334]: [storage] (init) Role changed to seco= ndary. > Oct 2 17:24:17 lolek hastd[39334]: Accepting connection to tcp4://0.0.0.= 0:8457. > Oct 2 17:24:17 lolek hastd[39334]: Connection from tcp4://172.20.68.12:1= 7367 to tcp4://172.20.68.11:8457. > Oct 2 17:24:17 lolek hastd[39334]: tcp4://172.20.68.12:17367: resource= =3Dstorage > Oct 2 17:24:17 lolek hastd[39334]: [storage] (secondary) Initial connect= ion from tcp4://172.20.68.12:17367. > Oct 2 17:24:17 lolek hastd[39334]: [storage] (secondary) Incoming connec= tion from tcp4://172.20.68.12:17367 configured. > Oct 2 17:24:17 lolek hastd[39334]: Accepting connection to tcp4://0.0.0.= 0:8457. > Oct 2 17:24:17 lolek hastd[39334]: Connection from tcp4://172.20.68.12:1= 3769 to tcp4://172.20.68.11:8457. > Oct 2 17:24:17 lolek hastd[39334]: tcp4://172.20.68.12:13769: resource= =3Dstorage > Oct 2 17:24:17 lolek hastd[39334]: [storage] (secondary) Outgoing connec= tion to tcp4://172.20.68.12:13769 configured. > Oct 2 17:24:17 lolek hastd[39339]: [storage] (secondary) Obtained info a= bout /dev/ad4. > Oct 2 17:24:17 lolek hastd[39339]: [storage] (secondary) Locked /dev/ad4. > Oct 2 17:24:17 lolek hastd[39339]: [storage] (secondary) Split-brain det= ected, exiting. > Oct 2 17:24:17 lolek hastd[39334]: Unable to receive event header: Socke= t is not connected. > Oct 2 17:24:28 lolek hastd[39334]: Accepting connection to tcp4://0.0.0.= 0:8457. > Oct 2 17:24:28 lolek hastd[39334]: Connection from tcp4://172.20.68.12:5= 9760 to tcp4://172.20.68.11:8457. > Oct 2 17:24:28 lolek hastd[39334]: tcp4://172.20.68.12:59760: resource= =3Dstorage > Oct 2 17:24:28 lolek hastd[39334]: [storage] (secondary) Initial connect= ion from tcp4://172.20.68.12:59760. > Oct 2 17:24:28 lolek hastd[39334]: [storage] (secondary) Worker process = exists (pid=3D39339), stopping it. > Oct 2 17:24:28 lolek hastd[39334]: [storage] (secondary) Worker process = exited ungracefully (pid=3D39339, exitcode=3D78). > Oct 2 17:24:28 lolek kernel: pid 39334 (hastd), uid 0: exited on signal = 6 (core dumped) >=20 > (gdb) bt > #0 0x28348d87 in kill () from /lib/libc.so.7 > #1 0x280e1017 in raise () from /lib/libthr.so.3 > #2 0x2834787a in abort () from /lib/libc.so.7 > #3 0x2832fc86 in __assert () from /lib/libc.so.7 > #4 0x0805f300 in proto_close (conn=3D0x0) at /usr/src/sbin/hastd/proto.c= :287 > #5 0x0804c445 in child_cleanup (res=3D0x284eb500) at /usr/src/sbin/hastd= /control.c:61 > #6 0x0804fc6d in listen_accept () at /usr/src/sbin/hastd/hastd.c:526 > #7 0x0805059a in main_loop () at /usr/src/sbin/hastd/hastd.c:673 > #8 0x08050a7f in main (argc=3D0, argv=3D0xbfbfed80) at /usr/src/sbin/has= td/hastd.c:784 > (gdb) fr 5 > #5 0x0804c445 in child_cleanup (res=3D0x284eb500) at /usr/src/sbin/hastd= /control.c:61 > 61 proto_close(res->hr_event); > (gdb) list > 56 child_cleanup(struct hast_resource *res) > 57 { > 58 > 59 proto_close(res->hr_ctrl); > 60 res->hr_ctrl =3D NULL; > 61 proto_close(res->hr_event); > 62 res->hr_event =3D NULL; > 63 res->hr_workerpid =3D 0; > 64 } > 65 >=20 > So we have double close of res->hr_event. The first time it is closed when > parent detects that worker exited in main_loop(), and the second time whe= n a > new connection from primary comes and the parent does cleanup after previ= ously > terminated child before starting new one. >=20 > The straightforward fix is to check res->hr_event before closing, like in= the > patch below. This is correct fix. We close event socketpair early to prevent spaming with debug logs as SIGCHLD is delivered a bit later. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --fUvfsPTz/SzOZDdw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyqQA0ACgkQForvXbEpPzSW8gCffC16IuebCBwq6wRvBRaoEejg jysAoJVHo8SIqIkEmPKrp/y2mu/CexkC =FmBS -----END PGP SIGNATURE----- --fUvfsPTz/SzOZDdw-- From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 21:37:20 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67C5C1065740 for ; Mon, 4 Oct 2010 21:37:20 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 948178FC16 for ; Mon, 4 Oct 2010 21:37:19 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 1FE8D45E11; Mon, 4 Oct 2010 23:37:18 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DFA4045D8D; Mon, 4 Oct 2010 23:37:12 +0200 (CEST) Date: Mon, 4 Oct 2010 23:36:47 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20101004213647.GK7322@garage.freebsd.pl> References: <86hbh44wgl.fsf@kopusha.home.net> <86aamw4l42.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rVkomL2febZOZtGQ" Content-Disposition: inline In-Reply-To: <86aamw4l42.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: hastd: assertion (res->hr_event != NULL) fails in secondary on split-brain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 21:37:20 -0000 --rVkomL2febZOZtGQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 02, 2010 at 07:26:05PM +0300, Mikolaj Golub wrote: > Running with this fix another issue is observed. On split-brain `hastctl > status' on secondary will return "[ERROR] Error 32 received from hastd" m= ost > of the times. And only for some runs an output will be returned. >=20 > lolek# hastctl status storage > [ERROR] Error 32 received from hastd. > lolek# hastctl status storage > [ERROR] Error 32 received from hastd. > lolek# hastctl status storage > storage: > role: secondary > provname: storage > localpath: /dev/ad4 > extentsize: 2097152 > keepdirty: 0 > remoteaddr: tcp4://bolek > replication: memsync > status: complete > dirty: 0 bytes > lolek# hastctl status storage > [ERROR] Error 32 received from hastd. >=20 > This is because hastd clears res->hr_workerpid only when a new connection= from > the primary comes. Whilst hastd checks res->hr_workerpid in control_statu= s() > and if it is not zero it tries to get info from the worker and returns er= ror > (broken pipe) if the worker is actually not running. >=20 > So it looks like it is better not just to close res->hr_ctrl in main_loop= () > but to do full child cleanup here -- straight away its exit is detected. >=20 > What do you think about the attached patch? I see three problems:) 1. In child_kill() you interpret status value always, even if it is invalid due to earlier errors. 2. While copying the code you changed style. Don't you like style(9)?:) 3. The patch doesn't fix the root cause of the problem. The real problem also for "hastd: zombies after hooks" you reported was that sigprocmask(2) doesn't mask ignored signals. In this case SIGCHLD is ignored by default, so it was never reported. We need to first install dummy signal handler for SIGCHLD. The fix I've here (and going to commit after a bit more testing) fixes zombie hookd you observed completely and makes the window for 'Error 32 received from hastd' problem much smaller. You can still see this message, because we can send request to child before we know it has terminated, but it is not as visible as it was before. Thanks for the report! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --rVkomL2febZOZtGQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyqSO4ACgkQForvXbEpPzRR9gCeP3QSHvMNiEwU62pCNiUdKYCA XXMAoKZujORkwbMOmuIGTHAIbWAA/94C =zAjI -----END PGP SIGNATURE----- --rVkomL2febZOZtGQ-- From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 00:38:29 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45DED10656A6; Tue, 5 Oct 2010 00:38:29 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id CB97A8FC0C; Tue, 5 Oct 2010 00:38:28 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 82BE112543B; Tue, 5 Oct 2010 09:38:26 +0900 (JST) Date: Tue, 5 Oct 2010 09:38:26 +0900 From: Daichi GOTO To: Garrett Cooper Message-Id: <20101005093826.17432b1e.daichi@ongs.co.jp> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 00:38:29 -0000 On Mon, 4 Oct 2010 07:19:45 -0700 Garrett Cooper wrote: > >> issues that might be occurring with the software, as per my copy of > >> SUSv4 (see the ERRORS section of fcntl). I would print out the > >> strerror for that case. > >>     Providing a backtrace of the application's execution and the > >> architecture and what version of FreeBSD you're using would be > >> helpful. > > I'm not even getting that far. Logs attached from both runs > (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). Yeah, it looks like the same situation. 1) mozc_server was killed lock file remains (even though it should be removed) 2) mozc_server try to boot 1. check lock file there 2. there is lock file, so cannot get lock file via fcntl 3. lock file means there is another mozc_server running, so mozc_server will stop boot and finish The cause of problem is that kernel does not remove lock file after mozc_server killed. Mozc developer explained me that fcntl will remove lock file after that process killed. But it looks like fnctl() does not remove lock file itself. According to FreeBSD fcntl(2) manual: All locks associated with a file for a given process are removed when the process terminates. No explanation lock file removing. Does FreeBSD fnctl(2) not remove lock file after process killed? Apparently from Mozc developer, Linux kernel removes lock files after process killed. > $ uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > Thu Aug 19 22:50:36 PDT 2010 > root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > I completely blasted past the part of your reply above where you > said your home directory is served up via NFS. It might be a problem > if you don't have lockd running (/etc/rc.d/lockd onestatus ? It isn't > enabled by default, and definitely isn't on on my machine) or the > mount isn't setup with lockd on the client side (nolockd will do this > on the initial mount, according to the manpage). There might be > `dragons' in the nfsd code that fail to do locking properly, but I > think that Rick (rmacklem@) or someone else on the list might be > better at answering whether or not things work from an NFS > perspective. server side: FreeBSD 7.3-PRERELEASE #0: Mon Mar 1 15:10:07 JST 2010 i386 rc.conf nfs_server_enable="YES" mountd_enable="YES" nfs_reserved_port_only="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" client side: FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 amd64 rc.conf: nfs_client_enable="YES" nfs_reserved_port_only="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" > I'd definitely divulge which version of NFS you're using as well > as what your NFS server and client are running if enabling lockd both > client and server side doesn't solve your problems right away. > Cheers, > -Garrett I have tested with ZFS because I was doubting NFS working well, but result was the same. (I didn't test with UFS.) Thanks truss output! From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 03:17:10 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1E78106566C; Tue, 5 Oct 2010 03:17:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A39EE8FC13; Tue, 5 Oct 2010 03:17:09 +0000 (UTC) Received: by iwn34 with SMTP id 34so931503iwn.13 for ; Mon, 04 Oct 2010 20:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=/ERprHhIg583y5L+Y5LSUftQcnUv5eY73L8qRpFQmfQ=; b=OARqQ+8jUxKLFD833qUjE/z83dn1yPJJj+CknxeBcxGofRO+OOU0DkJO2JqJOUkX/6 //v8YWK5p5owl8ZsM0vk4mK7r8+Ru/M3TNFrK45Ry2yhQ9XLqLB0rQfqkxNbK5je08J5 ZhkQr6bACepfz43jUUesB9Q0qdiEaaNWbyipc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SrmwKjK21j6lLVkwaA89mQ9jml+tsG6e1f5hUh3h6Qaw2VM7TQdE5hmzbcpgbBSCmo 63eIP8R+jACMJpdfzFqrgvtu8YN/2ffSq7toc42GU4Q1tXpoREtKUqMNCuX44Xcwk4A/ Hxma/C8Cdf9mM1Udy5ELmE1pM4iHRVqpBt55A= MIME-Version: 1.0 Received: by 10.231.160.17 with SMTP id l17mr11272294ibx.102.1286248628681; Mon, 04 Oct 2010 20:17:08 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Mon, 4 Oct 2010 20:17:08 -0700 (PDT) In-Reply-To: <20101005093826.17432b1e.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> Date: Mon, 4 Oct 2010 20:17:08 -0700 X-Google-Sender-Auth: 3KWLRms_3eyJB8TMeWGijBSD5NU Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: multipart/mixed; boundary=0050450157519afb400491d61878 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 03:17:10 -0000 --0050450157519afb400491d61878 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 4, 2010 at 5:38 PM, Daichi GOTO wrote: > On Mon, 4 Oct 2010 07:19:45 -0700 > Garrett Cooper wrote: >> >> issues that might be occurring with the software, as per my copy of >> >> SUSv4 (see the ERRORS section of fcntl). I would print out the >> >> strerror for that case. >> >> =A0 =A0 Providing a backtrace of the application's execution and the >> >> architecture and what version of FreeBSD you're using would be >> >> helpful. >> >> =A0 =A0 I'm not even getting that far. Logs attached from both runs >> (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). > > Yeah, it looks like the same situation. > > =A01) mozc_server was killed > =A0 =A0 =A0lock file remains =A0(even though it should be removed) > =A02) mozc_server try to boot > =A0 =A01. check lock file there > =A0 =A02. there is lock file, so cannot get lock file via fcntl > =A0 =A03. lock file means there is another mozc_server running, > =A0 =A0 =A0 so mozc_server will stop boot and finish Ok, weird. fstat on the file didn't yield anything nasty when I ran the app, and deleting the file in /tmp allowed the server to go a ways, then die, as opposed to die quickly, like what happened on the second try. > The cause of problem is that kernel does not remove lock file > after mozc_server killed. Mozc developer explained me that > fcntl will remove lock file after that process killed. But > it looks like fnctl() does not remove lock file itself. According > to FreeBSD fcntl(2) manual: > > =A0 =A0 All locks associated with a file for a given process are removed = when the > =A0 =A0 process terminates. > > No explanation lock file removing. Does FreeBSD fnctl(2) not remove lock = file > after process killed? =A0Apparently from Mozc developer, Linux kernel rem= oves > lock files after process killed. On Linux (RHEL 4.8): Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile --wxr-s--T 1 garrcoop eng 0 Oct 4 19:49 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Ok. This (EAGAIN) matches the Linux requirements specified in the manpage [1] I found, as well as the POSIX manpage [2]. The author is wrong about fcntl removing the file at exit though: $ ls -l /tmp/lockfile --wxr-s--T 1 garrcoop eng 0 Oct 4 19:49 /tmp/lockfile The file descriptor is closed though, so I can remove it at will: $ rm /tmp/lockfile $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory Following through the same process on FreeBSD... Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Well, lookie here! It locked as expected :). $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ rm /tmp/lockfile $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory So something else is going on with the application that needs to be resolved in that area. With that aside though, after modifying the test app a bit, I'm confused at the value of l_pid... Window 1: $ ./test_fcntl My pid: 5372 Window 2: $ ./test_fcntl My pid: 5373 test_fcntl: fcntl: Resource temporarily unavailable PID=3D1 has the lock Huh...? init has the file locked...? WTF?! So assuming Occam's Razor, I did a bit more reading and it turns out that l_pid is only populated when you call with F_GETLK: negative, l_start means end edge of the region. >>> The l_pid and l_s= ysid fields are only used with F_GETLK to return the process ID of the proc= ess holding a blocking lock and the system ID of the system that owns that process. Locks created by the local system will have a system ID of zero. <<< After a successful F_GETLK request, the value of l_whence i= s SEEK_SET. Thus, after fixing the test app I'm getting a sensical value: Window 1: $ ./test_fcntl My pid: 5394 Window 2: $ ./test_fcntl My pid: 5395 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=3D5394 has the lock Linux operates in the same manner: Window 1: $ ./test_fcntl My pid: 17861 Window 2: $ ./test_fcntl My pid: 17963 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=3D17861 has the lock Which I would expect because I'm not using anything exotic with fcntl(2) / open(2). I suspect mozc isn't properly initializing / calling fcntl(2), or the author used a non-POSIX extension that is implementation dependent and doesn't realize it (the Linux manpage has a pretty fat set of warnings about POSIX compatibility up at the top of the manpage). The developer might also want to use O_EXCL in the flags passed to open(2) as well, unless they want to lock specific sections in the file. Verified on UFS2 with SUJ. Test app attached. >> $ uname -a >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: >> Thu Aug 19 22:50:36 PDT 2010 >> root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =A0amd64 >> >> =A0 =A0 I completely blasted past the part of your reply above where you >> said your home directory is served up via NFS. It might be a problem >> if you don't have lockd running (/etc/rc.d/lockd onestatus ? It isn't >> enabled by default, and definitely isn't on on my machine) or the >> mount isn't setup with lockd on the client side (nolockd will do this >> on the initial mount, according to the manpage). There might be >> `dragons' in the nfsd code that fail to do locking properly, but I >> think that Rick (rmacklem@) or someone else on the list might be >> better at answering whether or not things work from an NFS >> perspective. > > server side: > =A0FreeBSD 7.3-PRERELEASE #0: Mon Mar =A01 15:10:07 JST 2010 i386 > =A0rc.conf > =A0 =A0nfs_server_enable=3D"YES" > =A0 =A0mountd_enable=3D"YES" > =A0 =A0nfs_reserved_port_only=3D"YES" > =A0 =A0rpc_lockd_enable=3D"YES" > =A0 =A0rpc_statd_enable=3D"YES" > > client side: > =A0FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 amd64 > =A0rc.conf: > =A0 =A0nfs_client_enable=3D"YES" > =A0 =A0nfs_reserved_port_only=3D"YES" > =A0 =A0rpc_lockd_enable=3D"YES" > =A0 =A0rpc_statd_enable=3D"YES" > >> =A0 =A0 I'd definitely divulge which version of NFS you're using as well >> as what your NFS server and client are running if enabling lockd both >> client and server side doesn't solve your problems right away. [...] > I have tested with ZFS because I was doubting NFS working well, > but result was the same. (I didn't test with UFS.) > > Thanks truss output! No problem :). Cheers, -Garrett [1] http://linux.die.net/man/2/fcntl [2] http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html --0050450157519afb400491d61878 Content-Type: application/octet-stream; name="test_fcntl.c" Content-Disposition: attachment; filename="test_fcntl.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gew700ol0 I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8ZXJyLmg+CiNpbmNsdWRlIDxlcnJuby5o PgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDx1bmlzdGQu aD4KCmludAptYWluKHZvaWQpCnsKCXN0cnVjdCBmbG9jayBmbG9jazsKCWludCBlcnJvciwgZmQ7 CgoJZmQgPSBvcGVuKCIvdG1wL2xvY2tmaWxlIiwgT19DUkVBVHxPX1dST05MWSk7CglpZiAoZmQg PT0gLTEpCgkJZXJyKDEsICJvcGVuIik7CgoJcHJpbnRmKCJNeSBwaWQ6ICVkXG4iLCBnZXRwaWQo KSk7CgoJZmxvY2subF90eXBlID0gRl9XUkxDSzsKCWZsb2NrLmxfc3RhcnQgPSAwOwoJZmxvY2su bF93aGVuY2UgPSBTRUVLX1NFVDsKCWZsb2NrLmxfbGVuID0gMDsKCglpZiAoZmNudGwoZmQsIEZf U0VUTEssICZmbG9jaykgPT0gLTEpIHsKCQllcnJvciA9IGVycm5vOwoJCXdhcm4oImZjbnRsWzFd Iik7CgkJaWYgKGVycm9yID09IEVBR0FJTikgewoJCQlpZiAoZmNudGwoZmQsIEZfR0VUTEssICZm bG9jaykgPT0gLTEpCgkJCQllcnIoMSwgImZjbnRsWzJdIik7CgkJCXByaW50ZigiUElEPSVkIGhh cyB0aGUgbG9ja1xuIiwgZmxvY2subF9waWQpOwoJCX0KCQlyZXR1cm4gKDEpOwoJfQoKCXdoaWxl ICgxKQoJCXNsZWVwKDEpOwoKCXJldHVybiAoMCk7Cgp9Cg== --0050450157519afb400491d61878-- From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 06:34:12 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63E13106564A; Tue, 5 Oct 2010 06:34:12 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 286B48FC15; Tue, 5 Oct 2010 06:34:12 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id E1F6A12543B; Tue, 5 Oct 2010 15:34:10 +0900 (JST) Date: Tue, 5 Oct 2010 15:34:10 +0900 From: Daichi GOTO To: Garrett Cooper Message-Id: <20101005153410.598e4484.daichi@ongs.co.jp> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 06:34:12 -0000 Thanks nice test tool :) And at last I got it excepting one mystery! On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper wrote: > Following through the same process on FreeBSD... > > Window 1: > $ ls -l /tmp/lockfile > ls: /tmp/lockfile: No such file or directory > $ ./test_fcntl > > Window 2: > > $ ls -l /tmp/lockfile > -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile > $ ./test_fcntl > test_fcntl: fcntl: Resource temporarily unavailable Just my mystery is as follow: Windows 1: % ./test_fcntl My pid: 43490 Windows 2: % ls -l /tmp/lockfile -r-sr-x--- 1 daichi wheel 0 10$B7n(B 5 15:02 /tmp/lockfile <--- is it weird, isn't it? % ./test_fcntl test_fcntl: open: Permission denied % Oops... What's wrong... /tmp is as follow: % mount | grep tmp /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) % dumpfs /tmp | grep journal flags soft-updates+journal % And working scene: Windows 2: % chmod u+w /tmp/lockfile % ls -l /tmp/lockfile -rwsr-x--- 1 daichi wheel 0 10$B7n(B 5 15:22 /tmp/lockfile % ./test_fcntl My pid: 43646 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=43490 has the lock % -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 06:56:12 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1F6106566C; Tue, 5 Oct 2010 06:56:12 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id A91358FC08; Tue, 5 Oct 2010 06:56:12 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 69B5812543B; Tue, 5 Oct 2010 15:39:26 +0900 (JST) Date: Tue, 5 Oct 2010 15:39:26 +0900 From: Daichi GOTO To: Garrett Cooper Message-Id: <20101005153926.88b4c1e1.daichi@freebsd.org> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> Organization: FreeBSD Project X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 06:56:13 -0000 Next step discussion engaged from this research I guess. Should we do change FreeBSD's fcntl(2) to return correct l_pid when called with F_SETLK? Or keep current behavior?? I want to hear other developers ideas and suggetions. On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper wrote: > test_fcntl: fcntl: Resource temporarily unavailable > PID=1 has the lock > > Huh...? init has the file locked...? WTF?! > So assuming Occam's Razor, I did a bit more reading and it turns > out that l_pid is only populated when you call with F_GETLK: > > negative, l_start means end edge of the region. >>> The l_pid and l_sysid > fields are only used with F_GETLK to return the process ID of the process > holding a blocking lock and the system ID of the system that owns that > process. Locks created by the local system will have a system ID of > zero. <<< After a successful F_GETLK request, the value of l_whence is > SEEK_SET. > > Thus, after fixing the test app I'm getting a sensical value: -- Daichi GOTO 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 07:05:20 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92BE4106564A; Tue, 5 Oct 2010 07:05:20 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E79B88FC0A; Tue, 5 Oct 2010 07:05:19 +0000 (UTC) Received: by mail-fx0-f54.google.com with SMTP id 9so4567035fxm.13 for ; Tue, 05 Oct 2010 00:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=UgQoTrG66aqcYQ29T4sKa9CWvFkQthVwd8H25HdbR1s=; b=RF4Bzz6cRI8kuUs6aqvShRqtpB1V8Q1Dr6GS/V7h2p1qq6u+xuRDYBR2Ly1Hv+J6zl wCeVMZPK8UE5KPLvHi76GsfktRyhZet2l6n7VKZRyCFY+v4tmUqt2FcSI6dWuR7xiFe7 tAEQSCpobFqjoD9obCRoDiwZgU1Oxt+tDAWJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=R1YbUlZwDCtWfsso1KiOAelMq4XZSc2HCyOC0nitp7nO1i2IMS9b2Hhdw3WUBS80SG h6RjOJ99ZA4a+vL6ix5mVAAFjIPKKY66O8+hAnuEhlsgRwa+RdLcgzLt6rTLO5fJu+vd gUPPSpzAnc98YTFqbnh2x9uFTI5Du/i2lncTs= Received: by 10.223.126.15 with SMTP id a15mr10018089fas.67.1286262319649; Tue, 05 Oct 2010 00:05:19 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id 2sm2698431faz.38.2010.10.05.00.05.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 Oct 2010 00:05:16 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek Organization: TOA Ukraine References: <86hbh44wgl.fsf@kopusha.home.net> <86aamw4l42.fsf@kopusha.home.net> <20101004213647.GK7322@garage.freebsd.pl> Date: Tue, 05 Oct 2010 10:05:13 +0300 In-Reply-To: <20101004213647.GK7322@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Mon, 4 Oct 2010 23:36:47 +0200") Message-ID: <86tyl1m85y.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: hastd: assertion (res->hr_event != NULL) fails in secondary on split-brain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 07:05:20 -0000 On Mon, 4 Oct 2010 23:36:47 +0200 Pawel Jakub Dawidek wrote: PJD> I see three problems:) PJD> 1. In child_kill() you interpret status value always, even if it is PJD> invalid due to earlier errors. PJD> 2. While copying the code you changed style. Don't you like style(9)?:) Me like :-). But it looks like my emacs don't. Need to teach it somehow... PJD> 3. The patch doesn't fix the root cause of the problem. Thank you for your comments. -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 07:48:10 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FF1C106566B for ; Tue, 5 Oct 2010 07:48:10 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 2850E8FC0A for ; Tue, 5 Oct 2010 07:48:09 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4B72E45E6F; Tue, 5 Oct 2010 09:48:08 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id EF53945CDC; Tue, 5 Oct 2010 09:48:02 +0200 (CEST) Date: Tue, 5 Oct 2010 09:47:36 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20101005074736.GM7322@garage.freebsd.pl> References: <86hbh44wgl.fsf@kopusha.home.net> <86aamw4l42.fsf@kopusha.home.net> <20101004213647.GK7322@garage.freebsd.pl> <86tyl1m85y.fsf@zhuzha.ua1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SgT04PEqo/+yUDw3" Content-Disposition: inline In-Reply-To: <86tyl1m85y.fsf@zhuzha.ua1> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: hastd: assertion (res->hr_event != NULL) fails in secondary on split-brain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 07:48:10 -0000 --SgT04PEqo/+yUDw3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 05, 2010 at 10:05:13AM +0300, Mikolaj Golub wrote: >=20 > On Mon, 4 Oct 2010 23:36:47 +0200 Pawel Jakub Dawidek wrote: >=20 > PJD> I see three problems:) >=20 > PJD> 1. In child_kill() you interpret status value always, even if it is > PJD> invalid due to earlier errors. > PJD> 2. While copying the code you changed style. Don't you like style(9= )?:) >=20 > Me like :-). But it looks like my emacs don't. Need to teach it somehow... >=20 > PJD> 3. The patch doesn't fix the root cause of the problem. >=20 > Thank you for your comments. The hang you reported is still not fixed, but I'm working on it. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --SgT04PEqo/+yUDw3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyq2BgACgkQForvXbEpPzRkwgCZAaD9pxGIGoFhDA0U3H4yg4VP ZqQAnRlcqx9F8nPn3VD9+aBP+1rNwGc2 =ww4h -----END PGP SIGNATURE----- --SgT04PEqo/+yUDw3-- From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 08:23:03 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5EB3106567A; Tue, 5 Oct 2010 08:23:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 581238FC29; Tue, 5 Oct 2010 08:23:03 +0000 (UTC) Received: by iwn34 with SMTP id 34so1262281iwn.13 for ; Tue, 05 Oct 2010 01:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JArzsFFSJ+FuSoOj/DeBVyk0NpKJfyiUzmCHPEDBhXA=; b=UZVaAaz3QmuQ3+WzB0Ls+vUiQRs1opbqWyPVLfgr7hzqdaCwZcVN64LrB1UYujMxGW N8+xi+o/2x5LoN7DwPpvQHd1JNkCYZB9VhGojW9Iz6XALj9ur6tG/+YxkMKlWdskFXLi I5c/EO9YzZdwDPmFE0jo63+pefOovzDVLtw48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=m6gRg5oyzazzP0hg2kT1XI/xqulA7r7/f1ftGb4IFVlu9nZDihjvx3HrIDqTKZoSbS 6gklePBAZjGDs+O+cu1s4HTWWkQDqH/I8YWCR6jG2ymnXCxhJ862reIM1ZVg9Vxpa7G8 NciIQ2rAWGW0PxacBJUgeX4DhjyqKdWlweaT0= MIME-Version: 1.0 Received: by 10.231.19.197 with SMTP id c5mr11679456ibb.151.1286266982419; Tue, 05 Oct 2010 01:23:02 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 5 Oct 2010 01:23:02 -0700 (PDT) In-Reply-To: <20101005153410.598e4484.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> Date: Tue, 5 Oct 2010 01:23:02 -0700 X-Google-Sender-Auth: ph4VKMZ6u0Ndth8K4UhH-8EqFxM Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 08:23:03 -0000 2010/10/4 Daichi GOTO : > Thanks nice test tool :) =C2=A0And at last I got it excepting one mystery= ! > > On Mon, 4 Oct 2010 20:17:08 -0700 > Garrett Cooper wrote: >> Following through the same process on FreeBSD... >> >> Window 1: >> $ ls -l /tmp/lockfile >> ls: /tmp/lockfile: No such file or directory >> $ ./test_fcntl >> >> Window 2: >> >> $ ls -l /tmp/lockfile >> -rwsr-x--- =C2=A01 garrcoop =C2=A0wheel =C2=A00 Oct =C2=A04 20:14 /tmp/l= ockfile >> $ ./test_fcntl >> test_fcntl: fcntl: Resource temporarily unavailable > > Just my mystery is as follow: > > Windows 1: > % ./test_fcntl > My pid: 43490 > > Windows 2: > % ls -l /tmp/lockfile > -r-sr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:02 /= tmp/lockfile =C2=A0 =C2=A0<--- is it weird, isn't it? > % ./test_fcntl > test_fcntl: open: Permission denied > % > > Oops... What's wrong... /tmp is as follow: > > % mount | grep tmp > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) > % dumpfs /tmp | grep journal > flags =C2=A0 soft-updates+journal > % > > And working scene: > > Windows 2: > % chmod u+w /tmp/lockfile > % ls -l /tmp/lockfile > -rwsr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:22 /= tmp/lockfile > % ./test_fcntl > My pid: 43646 > test_fcntl: fcntl[1]: Resource temporarily unavailable > PID=3D43490 has the lock > % What's your umask and what are the permissions on /tmp? From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 08:55:37 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C4D8106566C; Tue, 5 Oct 2010 08:55:37 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id E94888FC29; Tue, 5 Oct 2010 08:55:36 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 2369412543B; Tue, 5 Oct 2010 17:55:36 +0900 (JST) Date: Tue, 5 Oct 2010 17:55:36 +0900 From: Daichi GOTO To: Garrett Cooper Message-Id: <20101005175536.a67998ae.daichi@ongs.co.jp> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 08:55:37 -0000 On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper wrote: > 2010/10/4 Daichi GOTO : > > Thanks nice test tool :)  And at last I got it excepting one mystery! > > > > On Mon, 4 Oct 2010 20:17:08 -0700 > > Garrett Cooper wrote: > >> Following through the same process on FreeBSD... > >> > >> Window 1: > >> $ ls -l /tmp/lockfile > >> ls: /tmp/lockfile: No such file or directory > >> $ ./test_fcntl > >> > >> Window 2: > >> > >> $ ls -l /tmp/lockfile > >> -rwsr-x---  1 garrcoop  wheel  0 Oct  4 20:14 /tmp/lockfile > >> $ ./test_fcntl > >> test_fcntl: fcntl: Resource temporarily unavailable > > > > Just my mystery is as follow: > > > > Windows 1: > > % ./test_fcntl > > My pid: 43490 > > > > Windows 2: > > % ls -l /tmp/lockfile > > -r-sr-x---  1 daichi  wheel  0 10月  5 15:02 /tmp/lockfile    <--- is it weird, isn't it? > > % ./test_fcntl > > test_fcntl: open: Permission denied > > % > > > > Oops... What's wrong... /tmp is as follow: > > > > % mount | grep tmp > > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) > > % dumpfs /tmp | grep journal > > flags   soft-updates+journal > > % > > > > And working scene: > > > > Windows 2: > > % chmod u+w /tmp/lockfile > > % ls -l /tmp/lockfile > > -rwsr-x---  1 daichi  wheel  0 10月  5 15:22 /tmp/lockfile > > % ./test_fcntl > > My pid: 43646 > > test_fcntl: fcntl[1]: Resource temporarily unavailable > > PID=43490 has the lock > > % > > What's your umask and what are the permissions on /tmp? % ll / | grep tmp drwxrwxrwt 14 root wheel 1024 10月 5 17:19 tmp % umask 022 % rm -f test % touch test % ll | grep test -rw-r--r-- 1 daichi wheel 0 10月 5 17:52 test % From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 14:52:10 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECA63106566C; Tue, 5 Oct 2010 14:52:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBA98FC13; Tue, 5 Oct 2010 14:52:10 +0000 (UTC) Received: by iwn34 with SMTP id 34so1721279iwn.13 for ; Tue, 05 Oct 2010 07:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=B6iy/Zws2i8RacFvzW4QWA/COTEl4rMxqVbeg/0B6C0=; b=Z3Mu5r9KR7GXr1gCRlVrCeSUEF5TbwrMdPGC7xve+fpKTyvkSRwlFUBWlW8YUeP8H+ KieS61y8WPJdO06Qtw1n0iKFD6FXucPF0QByqXpEkalpQcS7y6wSP5Cu+QhD2uvLKGt0 1hWPbg+bGXqS5LqK9r+Z11NShP9AqjNK+F9IA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GiHI64FdHWNdWd+kFK1k5or7fPbQ1zPMFPRhD2hb3x/C9XRDcPq/Y2YjyX8WbTLkEk r5rcsY9nE5frlBFwXlwiqFxRl9vKxGWTj2btmaq/y7dCogti2t6NRFSpJr9/dKFZwBij eZwGvbOQXgw+d8FF4sDuci6yLbJBUJI7JV8JE= MIME-Version: 1.0 Received: by 10.231.170.21 with SMTP id b21mr12233750ibz.122.1286290330040; Tue, 05 Oct 2010 07:52:10 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 5 Oct 2010 07:52:10 -0700 (PDT) In-Reply-To: <20101005175536.a67998ae.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> Date: Tue, 5 Oct 2010 07:52:10 -0700 X-Google-Sender-Auth: fZE9pnABiLTA_pqXjSeeX6N6ao4 Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:52:11 -0000 On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO wrote: > On Tue, 5 Oct 2010 01:23:02 -0700 > Garrett Cooper wrote: >> 2010/10/4 Daichi GOTO : >> > Thanks nice test tool :) =C2=A0And at last I got it excepting one myst= ery! >> > >> > On Mon, 4 Oct 2010 20:17:08 -0700 >> > Garrett Cooper wrote: >> >> Following through the same process on FreeBSD... >> >> >> >> Window 1: >> >> $ ls -l /tmp/lockfile >> >> ls: /tmp/lockfile: No such file or directory >> >> $ ./test_fcntl >> >> >> >> Window 2: >> >> >> >> $ ls -l /tmp/lockfile >> >> -rwsr-x--- =C2=A01 garrcoop =C2=A0wheel =C2=A00 Oct =C2=A04 20:14 /tm= p/lockfile >> >> $ ./test_fcntl >> >> test_fcntl: fcntl: Resource temporarily unavailable >> > >> > Just my mystery is as follow: >> > >> > Windows 1: >> > % ./test_fcntl >> > My pid: 43490 >> > >> > Windows 2: >> > % ls -l /tmp/lockfile >> > -r-sr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:0= 2 /tmp/lockfile =C2=A0 =C2=A0<--- is it weird, isn't it? >> > % ./test_fcntl >> > test_fcntl: open: Permission denied >> > % >> > >> > Oops... What's wrong... /tmp is as follow: >> > >> > % mount | grep tmp >> > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >> > % dumpfs /tmp | grep journal >> > flags =C2=A0 soft-updates+journal >> > % >> > >> > And working scene: >> > >> > Windows 2: >> > % chmod u+w /tmp/lockfile >> > % ls -l /tmp/lockfile >> > -rwsr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:2= 2 /tmp/lockfile >> > % ./test_fcntl >> > My pid: 43646 >> > test_fcntl: fcntl[1]: Resource temporarily unavailable >> > PID=3D43490 has the lock >> > % >> >> What's your umask and what are the permissions on /tmp? > > % ll / | grep tmp > drwxrwxrwt =C2=A014 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A01024 10=E6=9C=88= =C2=A05 17:19 tmp > % umask > 022 > % rm -f test > % touch test > % ll | grep test > -rw-r--r-- =C2=A0 1 daichi =C2=A0wheel =C2=A0 =C2=A0 0 10=E6=9C=88 =C2=A0= 5 17:52 test > % The permissions look ok from my perspective, but the umask is different, so you might want to try my umask to make sure that your results match mine (and we need to check the requirements to determine whether or not the behavior for FreeBSD's umask syscall is correct): $ ls -la /tmp/ | head -n 2 total 462686 drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . $ umask 0022 Where and how is /tmp mounted (is it a real partition, what filesystem, etc)? BTW, when I change my umask to match your's I don't get the same results you do on my home machine: Window 1: $ umask 022 $ ./test_fcntl My pid: 17353 Window 2: $ ./test_fcntl My pid: 17356 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=3D17353 has the lock $ ls -l /tmp/lockfile -rwSr----- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile Just to note, the tests before were run on the RHEL 4.8 box with the following info, and the FreeBSD box with the following info: Red Hat Enterprise Linux AS release 4 (Nahant Update 8) Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r211767M: Sat Aug 28 00:28:45 PDT 2010 garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 The tests above were run on a FreeBSD box with the following info: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 On bayonetta /tmp is SUJ backed (probably should change that though), and on bioshock it's not SUJ backed. Thanks! -Garrett From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 15:58:08 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84E1E106566C; Tue, 5 Oct 2010 15:58:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 241D08FC17; Tue, 5 Oct 2010 15:58:07 +0000 (UTC) Received: by iwn34 with SMTP id 34so1803829iwn.13 for ; Tue, 05 Oct 2010 08:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RAqk0+SeSYAJNS6EGKSvPed6R9+QoyAAlt1ANPDSOZo=; b=rHAFEpqThKQXseEBYDhs/Ul/UKwPMlubo5w0J2btLkLrlI3G7aLPc+iBOhIKMWUa7K 5Gi+wLVFseF0Evd6gXnpMUSvu1WY5/L1dde/MGo+cWo+6vEN3OrmqsD4s02j8pcQ3P9B aZFBBe6zNlvqkAHxJgNDnfKhKTPSq25iMb5+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=F+gYod09XdZE8gHa4A3i9PRcYqrL/Yp/p0vEZUHMF9G+2jSvE6TpfKxgegbcdKG7lx gLgvH9dYl/I1dTu4neTmWSLPXpN+cAxlqz7B9L3r0nru3MwMu6o0XLJp2HP7ZCcdO2hI UOqtF/1gpIEYm3uOzXPumGuuFtYvgLassKusE= MIME-Version: 1.0 Received: by 10.231.183.10 with SMTP id ce10mr12373147ibb.96.1286294287204; Tue, 05 Oct 2010 08:58:07 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 5 Oct 2010 08:58:07 -0700 (PDT) In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> Date: Tue, 5 Oct 2010 08:58:07 -0700 X-Google-Sender-Auth: H6sxQwLzCHNKeat0qtNKlqCf_AE Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 15:58:08 -0000 On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO wrote: >> On Tue, 5 Oct 2010 01:23:02 -0700 >> Garrett Cooper wrote: >>> 2010/10/4 Daichi GOTO : >>> > Thanks nice test tool :) =C2=A0And at last I got it excepting one mys= tery! >>> > >>> > On Mon, 4 Oct 2010 20:17:08 -0700 >>> > Garrett Cooper wrote: >>> >> Following through the same process on FreeBSD... >>> >> >>> >> Window 1: >>> >> $ ls -l /tmp/lockfile >>> >> ls: /tmp/lockfile: No such file or directory >>> >> $ ./test_fcntl >>> >> >>> >> Window 2: >>> >> >>> >> $ ls -l /tmp/lockfile >>> >> -rwsr-x--- =C2=A01 garrcoop =C2=A0wheel =C2=A00 Oct =C2=A04 20:14 /t= mp/lockfile >>> >> $ ./test_fcntl >>> >> test_fcntl: fcntl: Resource temporarily unavailable >>> > >>> > Just my mystery is as follow: >>> > >>> > Windows 1: >>> > % ./test_fcntl >>> > My pid: 43490 >>> > >>> > Windows 2: >>> > % ls -l /tmp/lockfile >>> > -r-sr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:= 02 /tmp/lockfile =C2=A0 =C2=A0<--- is it weird, isn't it? >>> > % ./test_fcntl >>> > test_fcntl: open: Permission denied >>> > % >>> > >>> > Oops... What's wrong... /tmp is as follow: >>> > >>> > % mount | grep tmp >>> > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >>> > % dumpfs /tmp | grep journal >>> > flags =C2=A0 soft-updates+journal >>> > % >>> > >>> > And working scene: >>> > >>> > Windows 2: >>> > % chmod u+w /tmp/lockfile >>> > % ls -l /tmp/lockfile >>> > -rwsr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:= 22 /tmp/lockfile >>> > % ./test_fcntl >>> > My pid: 43646 >>> > test_fcntl: fcntl[1]: Resource temporarily unavailable >>> > PID=3D43490 has the lock >>> > % >>> >>> What's your umask and what are the permissions on /tmp? >> >> % ll / | grep tmp >> drwxrwxrwt =C2=A014 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A01024 10=E6=9C= =88 =C2=A05 17:19 tmp >> % umask >> 022 >> % rm -f test >> % touch test >> % ll | grep test >> -rw-r--r-- =C2=A0 1 daichi =C2=A0wheel =C2=A0 =C2=A0 0 10=E6=9C=88 =C2= =A05 17:52 test >> % > > =C2=A0 =C2=A0The permissions look ok from my perspective, but the umask i= s > different, so you might want to try my umask to make sure that your > results match mine (and we need to check the requirements to determine > whether or not the behavior for FreeBSD's umask syscall is correct): > > $ ls -la /tmp/ | head -n 2 > total 462686 > drwxrwxrwt =C2=A051 root =C2=A0 =C2=A0 wheel =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 11776 Oct =C2=A05 03:11 . > $ umask > 0022 > > =C2=A0 =C2=A0Where and how is /tmp mounted (is it a real partition, what > filesystem, etc)? > =C2=A0 =C2=A0BTW, when I change my umask to match your's I don't get the = same > results you do on my home machine: > > Window 1: > > $ umask 022 > $ ./test_fcntl > My pid: 17353 > > Window 2: > > $ ./test_fcntl > My pid: 17356 > test_fcntl: fcntl[1]: Resource temporarily unavailable > PID=3D17353 has the lock > $ ls -l /tmp/lockfile > -rwSr----- =C2=A01 gcooper =C2=A0wheel =C2=A00 Oct =C2=A05 07:49 /tmp/loc= kfile > > =C2=A0 =C2=A0Just to note, the tests before were run on the RHEL 4.8 box = with > the following info, and the FreeBSD box with the following info: > > Red Hat Enterprise Linux AS release 4 (Nahant Update 8) > Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT > 2009 x86_64 x86_64 x86_64 GNU/Linux > > FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 > r211767M: Sat Aug 28 00:28:45 PDT 2010 > garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK =C2=A0amd64 > > =C2=A0 =C2=A0The tests above were run on a FreeBSD box with the following= info: > > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > Thu Aug 19 22:50:36 PDT 2010 > root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =C2=A0amd64 > > =C2=A0 =C2=A0On bayonetta /tmp is SUJ backed (probably should change that > though), and on bioshock it's not SUJ backed. And while this might be a good mental exercise, I think we're missing the original point of your bug: You were getting ECONNREFUSED because a socket was in `use', even though all instances of mozc_server were dead (at least that's the case with me). So the question I guess that's worth asking is: 1. What process/application does it need to establish a Unix style socket w= ith? 2. Why isn't that socket being cleaned up by the OS at exit? Thanks! -Garrett From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 17:09:19 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83EF3106566B; Tue, 5 Oct 2010 17:09:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 24FF58FC12; Tue, 5 Oct 2010 17:09:19 +0000 (UTC) Received: by iwn34 with SMTP id 34so1892686iwn.13 for ; Tue, 05 Oct 2010 10:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ecVuMdFNpCr0ADGRJnGUVWQA6DxDKlhAJIkZry85au4=; b=rMHCLvb7njYctbm3+xjlH2N5hgq8HcR3/Ee/hh4CvqlJSKEnChioIJU1WkWFAQ3Ma9 OatVGloDgH4vQA+tViLq9SFf6BxslLh/WitpvA/W4EqEwv55u96Sz1YH+j8c+0uCj54N iHH1fqnL/xMYPeLOuOAW5KFNo4L0izS5X10gM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=I3oym9Vtv0GcN6LoarXn5voTMSQQ5A10VE7/Rk2+yK4caUlIih95rjzyYKUIa2rOcJ dF8SqfQM3PN4mAacV2MYTXOia2f7guLn+vrrcXiy+TP3aP5HvP9TwB43X2ZLhNi8bSJ3 fmx0kUb78wW4qRAijUr17dnetPUCf9zSb1SR4= MIME-Version: 1.0 Received: by 10.231.170.208 with SMTP id e16mr12462933ibz.44.1286298558688; Tue, 05 Oct 2010 10:09:18 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 5 Oct 2010 10:09:18 -0700 (PDT) In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> Date: Tue, 5 Oct 2010 10:09:18 -0700 X-Google-Sender-Auth: Gf6mQNSXTqDyWTkOG8_fb_kYWrs Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:09:19 -0000 On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper wrot= e: >> On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO wrote: >>> On Tue, 5 Oct 2010 01:23:02 -0700 >>> Garrett Cooper wrote: >>>> 2010/10/4 Daichi GOTO : >>>> > Thanks nice test tool :) =C2=A0And at last I got it excepting one my= stery! >>>> > >>>> > On Mon, 4 Oct 2010 20:17:08 -0700 >>>> > Garrett Cooper wrote: >>>> >> Following through the same process on FreeBSD... >>>> >> >>>> >> Window 1: >>>> >> $ ls -l /tmp/lockfile >>>> >> ls: /tmp/lockfile: No such file or directory >>>> >> $ ./test_fcntl >>>> >> >>>> >> Window 2: >>>> >> >>>> >> $ ls -l /tmp/lockfile >>>> >> -rwsr-x--- =C2=A01 garrcoop =C2=A0wheel =C2=A00 Oct =C2=A04 20:14 /= tmp/lockfile >>>> >> $ ./test_fcntl >>>> >> test_fcntl: fcntl: Resource temporarily unavailable >>>> > >>>> > Just my mystery is as follow: >>>> > >>>> > Windows 1: >>>> > % ./test_fcntl >>>> > My pid: 43490 >>>> > >>>> > Windows 2: >>>> > % ls -l /tmp/lockfile >>>> > -r-sr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15= :02 /tmp/lockfile =C2=A0 =C2=A0<--- is it weird, isn't it? >>>> > % ./test_fcntl >>>> > test_fcntl: open: Permission denied >>>> > % >>>> > >>>> > Oops... What's wrong... /tmp is as follow: >>>> > >>>> > % mount | grep tmp >>>> > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >>>> > % dumpfs /tmp | grep journal >>>> > flags =C2=A0 soft-updates+journal >>>> > % >>>> > >>>> > And working scene: >>>> > >>>> > Windows 2: >>>> > % chmod u+w /tmp/lockfile >>>> > % ls -l /tmp/lockfile >>>> > -rwsr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15= :22 /tmp/lockfile >>>> > % ./test_fcntl >>>> > My pid: 43646 >>>> > test_fcntl: fcntl[1]: Resource temporarily unavailable >>>> > PID=3D43490 has the lock >>>> > % >>>> >>>> What's your umask and what are the permissions on /tmp? >>> >>> % ll / | grep tmp >>> drwxrwxrwt =C2=A014 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A01024 10=E6=9C= =88 =C2=A05 17:19 tmp >>> % umask >>> 022 >>> % rm -f test >>> % touch test >>> % ll | grep test >>> -rw-r--r-- =C2=A0 1 daichi =C2=A0wheel =C2=A0 =C2=A0 0 10=E6=9C=88 =C2= =A05 17:52 test >>> % >> >> =C2=A0 =C2=A0The permissions look ok from my perspective, but the umask = is >> different, so you might want to try my umask to make sure that your >> results match mine (and we need to check the requirements to determine >> whether or not the behavior for FreeBSD's umask syscall is correct): >> >> $ ls -la /tmp/ | head -n 2 >> total 462686 >> drwxrwxrwt =C2=A051 root =C2=A0 =C2=A0 wheel =C2=A0 =C2=A0 =C2=A0 =C2=A0= 11776 Oct =C2=A05 03:11 . >> $ umask >> 0022 >> >> =C2=A0 =C2=A0Where and how is /tmp mounted (is it a real partition, what >> filesystem, etc)? >> =C2=A0 =C2=A0BTW, when I change my umask to match your's I don't get the= same >> results you do on my home machine: >> >> Window 1: >> >> $ umask 022 >> $ ./test_fcntl >> My pid: 17353 >> >> Window 2: >> >> $ ./test_fcntl >> My pid: 17356 >> test_fcntl: fcntl[1]: Resource temporarily unavailable >> PID=3D17353 has the lock >> $ ls -l /tmp/lockfile >> -rwSr----- =C2=A01 gcooper =C2=A0wheel =C2=A00 Oct =C2=A05 07:49 /tmp/lo= ckfile >> >> =C2=A0 =C2=A0Just to note, the tests before were run on the RHEL 4.8 box= with >> the following info, and the FreeBSD box with the following info: >> >> Red Hat Enterprise Linux AS release 4 (Nahant Update 8) >> Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT >> 2009 x86_64 x86_64 x86_64 GNU/Linux >> >> FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 >> r211767M: Sat Aug 28 00:28:45 PDT 2010 >> garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK =C2=A0amd64 >> >> =C2=A0 =C2=A0The tests above were run on a FreeBSD box with the followin= g info: >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: >> Thu Aug 19 22:50:36 PDT 2010 >> root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =C2=A0amd64 >> >> =C2=A0 =C2=A0On bayonetta /tmp is SUJ backed (probably should change tha= t >> though), and on bioshock it's not SUJ backed. > > And while this might be a good mental exercise, I think we're missing > the original point of your bug: > > You were getting ECONNREFUSED because a socket was in `use', even > though all instances of mozc_server were dead (at least that's the > case with me). So the question I guess that's worth asking is: Statement incorrect: socket wasn't in use. The logic needs to be rewritten to account for this case and setup the socket again if this occurs. It would be a good idea to do this if the file wasn't locked. > 1. What process/application does it need to establish a Unix style socket= with? > 2. Why isn't that socket being cleaned up by the OS at exit? Thanks! -Garrett From owner-freebsd-fs@FreeBSD.ORG Tue Oct 5 22:21:34 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7021065672; Tue, 5 Oct 2010 22:21:34 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 50F4C8FC19; Tue, 5 Oct 2010 22:21:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o95MLYQV012114; Tue, 5 Oct 2010 22:21:34 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o95MLYXk012110; Tue, 5 Oct 2010 22:21:34 GMT (envelope-from arundel) Date: Tue, 5 Oct 2010 22:21:34 GMT Message-Id: <201010052221.o95MLYXk012110@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: bin/143572: [zfs] zpool(1): [patch] The verbose output from iostat does not set the correct column width when multiple pools are displayed. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 22:21:34 -0000 Synopsis: [zfs] zpool(1): [patch] The verbose output from iostat does not set the correct column width when multiple pools are displayed. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: arundel Responsible-Changed-When: Tue Oct 5 22:21:12 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143572 From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 00:54:02 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC27A1065672 for ; Wed, 6 Oct 2010 00:54:01 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id D47138FC15 for ; Wed, 6 Oct 2010 00:54:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by goat.gigo.com (Postfix) with ESMTP id B190F114C2 for ; Tue, 5 Oct 2010 17:54:01 -0700 (PDT) Received: from goat.gigo.com ([127.0.0.1]) by localhost (vette.gigo.com [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id D7ycn+oCjhwX for ; Tue, 5 Oct 2010 17:54:01 -0700 (PDT) Received: from 200.181.39.170 (200-181-39-170.bsace702.dsl.brasiltelecom.net.br [200.181.39.170]) by goat.gigo.com (Postfix) with ESMTPSA id 45B0211432 for ; Tue, 5 Oct 2010 17:54:00 -0700 (PDT) Received: (qmail 62914 invoked by uid 1001); 5 Oct 2010 21:53:26 -0300 Message-ID: <20101006005350.62837.qmail@exxodus.fedaykin.here> Date: Tue, 5 Oct 2010 21:53:26 -0300 From: Mario Sergio Fujikawa Ferreira To: freebsd-fs@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Panic with msdosfs vs 1.3TB FAT32 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 00:54:02 -0000 Hi, I mounted a 1.3TB FAT32 (32k cluster) filesystem on esata /dev/ada4s1 under /media/esata/ with the '-l' (large option). I tried to create a directory and files but got errors: ------ g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 ------ Then, I tried unmounting the filesystem which resulted on ------ fsync: giving up on dirty 0xffffff01bad6e1d8: tag devfs, type VCHR usecount 1, writecount 0, refcount 38253 mountedhere 0xffffff00ac899600 flags () v_object 0xffffff008b839ca8 ref 0 pages 44786 lock type devfs: EXCL by thread 0xffffff016506cba0 (pid 76462) dev ada4s1 g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 fsync: giving up on dirty 0xffffff01bad6e1d8: tag devfs, type VCHR usecount 1, writecount 0, refcount 38253 mountedhere 0xffffff00ac899600 flags () v_object 0xffffff008b839ca8 ref 0 pages 44786 lock type devfs: UNLOCKED dev ada4s1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x4 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803e60e4 stack pointer = 0x28:0xffffff80e79ba860 frame pointer = 0x28:0xffffff80e79ba8a0 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 = 25 (syncer) ------ The filesystem is clean since I find no errors under Windows ('chkdsk /f'). I can otherwise mount, read and write on smaller FAT32 filesystems. I think there might be a problem with the handling of such a big FAT32 filesystem. A complete textdump is available at http://people.freebsd.org/~lioux/panic/2010100500/textdump.tar.2 Is this kind of error expected? Is there anything I can do to help? I can reproduce this error with the 1.3TB fs easily. Regards, -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 01:02:38 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50F05106564A for ; Wed, 6 Oct 2010 01:02:38 +0000 (UTC) (envelope-from anti_spamsys@yahoo.com) Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by mx1.freebsd.org (Postfix) with SMTP id 307178FC13 for ; Wed, 6 Oct 2010 01:02:38 +0000 (UTC) Received: from [98.139.91.64] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 06 Oct 2010 00:50:05 -0000 Received: from [98.139.91.39] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 06 Oct 2010 00:50:05 -0000 Received: from [127.0.0.1] by omp1039.mail.sp2.yahoo.com with NNFMP; 06 Oct 2010 00:50:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 717039.30410.bm@omp1039.mail.sp2.yahoo.com Received: (qmail 4064 invoked by uid 60001); 6 Oct 2010 00:50:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1286326204; bh=vj6bQL2g6N4Zf8wNS0Ivg6+omTgpSwbztEWSj884fuk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=GgrPIQP3+CAWfUWM6dhGZvG7LnpBbbJXS0l70p5nRsnnZhLNdCnqDQ9bgaD4TVGXPPl8n97Qk00F/VTG/aajz9QiDOeyneY59AW8lUy46tGkIL7CtQDlJahddwdOHCkiCXsozrQnEI0CfoWZgvJqO7ZAGA4xwn0JHVCMIhVin7c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=NIwH4xYRT+Wy3espenI2g2pTyS31VasBmI8QKjVayZW9nEH8TB7FSZLYaV7KKLBBHg6KJU9KR2za99NprIS2i3c3dN/kT5/PkoPVHKsT+qAH2+P4J2hDjCQSpAL8gwJy5nqot/zMRfMIjq4U31PVfNkDhBqdLjfRN3R6r0U/sUQ=; Message-ID: <162340.85805.qm@web113215.mail.gq1.yahoo.com> X-YMail-OSG: NXNbUYcVM1mSXbfOwbNlQ4qWlb.KVQTRSBOh7EKfNQXlkHU ZHZr07_mDbR0b4je4x6SpZUThcCDHxNQH7KQeFGQpCOJzYQG_0pebnY21cvK kGaEj6147FqRS8AkBwIkvEclORlN4MdR9uUd9QFG8Z1VTqjuV376EnuSE9lG jMVYIv6uDpJrK8C4AtrPPkyiuLLnn4qVZZh996gLxTooclq1.DwBaUiVcHT1 fOYuEcTj5Vs2fB_80EDvnTI.hbz4Yx9CZHy1LUexQDPx78eDUbRqqdfiloh6 qA4v6XO8- Received: from [128.55.19.49] by web113215.mail.gq1.yahoo.com via HTTP; Tue, 05 Oct 2010 17:50:03 PDT X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.106.282862 Date: Tue, 5 Oct 2010 17:50:03 -0700 (PDT) From: Trever To: freebsd-fs@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Are any adjustments for ZFS necessary in 8.1 amd64? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 01:02:38 -0000 Apologies if this has been answered previously, but I can't find definitive info. The FBSD handbook recommends a customized loader.conf when using ZFS (for all architectures): vm.kmem_size="330M" vm.kmem_size_max="330M" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M" Is this still true for the 8.1 amd64 release? I've read various places that it is not and that handbook is NOT up-to-date. Out of the box, amd64 8.1 ZFS so far "just works" without any customizations other than to make sure it turns on at reboot. But systems are fairly quiescent, we have not gone to production yet. In addition to the handbook recommendations, are there 8.1 amd64 tunings that should be done for a vanilla server? (Will be imap server, actually.) Without tuning as per above, I see this on our systems (sysctl -a): vm.kmem_size: 8318648320 vm.kmem_size_max: 329853485875 vfs.zfs.arc_max: 7244906496 vfs.zfs.vdev.cache.size: 10485760 Our systems have 24 GB of RAM. Thanks! Trever From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 03:15:45 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 887B2106566B for ; Wed, 6 Oct 2010 03:15:45 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3AC1D8FC13 for ; Wed, 6 Oct 2010 03:15:44 +0000 (UTC) Received: by qyk4 with SMTP id 4so185729qyk.13 for ; Tue, 05 Oct 2010 20:15:44 -0700 (PDT) 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 :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=r1crpQr4PC6W6AVliYTTH5Jc+9cuIafAZz9NtOhecdY=; b=wAzVRc+9kKX3xdTXlNBRtQS4GvPsDMA/vq2VuIN2VVarBBc8x7FIImpMJjjbB3FRWo ceU2/8QQQ11o282lW0+Ugd8NNCMOdVkpvSYsgA0Kq2R4XnPy2Sjqtg7J3Aq4320pTMyb WSyWZLNU2mONtbqIGKsmdYoFR8cRh+3OftJvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Z1gyL0vapyA9EKEoaJAFcnYCVg8/W1yIHr6kmK3K/TbYifr1GDlwjLwyoq3oEtM/J5 9o7ugGSDHHonJ2p6RWLCJaJgftnxjFXLm/2Den3ecYJ6aOm6IuquHR753YdmS3szVRKY vChOtnNPRKVfEL+o2FgH4KbQGWH52H9NZhGqo= Received: by 10.224.54.140 with SMTP id q12mr8901858qag.232.1286334944336; Tue, 05 Oct 2010 20:15:44 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-144-115.dsl.klmzmi.sbcglobal.net [99.181.144.115]) by mx.google.com with ESMTPS id y14sm271375vch.28.2010.10.05.20.15.42 (version=SSLv3 cipher=RC4-MD5); Tue, 05 Oct 2010 20:15:43 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CABE9DC.7080601@DataIX.net> Date: Tue, 05 Oct 2010 23:15:40 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100917 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Trever References: <162340.85805.qm@web113215.mail.gq1.yahoo.com> In-Reply-To: <162340.85805.qm@web113215.mail.gq1.yahoo.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Are any adjustments for ZFS necessary in 8.1 amd64? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 03:15:45 -0000 On 10/05/2010 20:50, Trever wrote: > Apologies if this has been answered previously, but I can't find definitive info. > > The FBSD handbook recommends a customized loader.conf when using ZFS (for all architectures): > vm.kmem_size="330M" > vm.kmem_size_max="330M" > vfs.zfs.arc_max="40M" > vfs.zfs.vdev.cache.size="5M" > > Is this still true for the 8.1 amd64 release? I've read various places that it is not and that handbook is NOT up-to-date. Out of the box, amd64 8.1 ZFS so far "just works" without any customizations other than to make sure it turns on at reboot. But systems are fairly quiescent, we have not gone to production yet. > > In addition to the handbook recommendations, are there 8.1 amd64 tunings that should be done for a vanilla server? (Will be imap server, actually.) > > Without tuning as per above, I see this on our systems (sysctl -a): > vm.kmem_size: 8318648320 > vm.kmem_size_max: 329853485875 > vfs.zfs.arc_max: 7244906496 > vfs.zfs.vdev.cache.size: 10485760 > > Our systems have 24 GB of RAM. > With the amount of RAM that you have available in your system I would not recommend using the above values that you quoted from the Wiki. Those values from the wiki IIRC were based on a i386 system that has less than 1G of RAM and were used as an example more than a definitive tuning to achieve better performance. With all the available configurations that are possible with a ZFS based FreeBSD system I would suggest that you try out the defaults and move from that point onward before you try tuning for a specific scenario. It will be best to have a definitive starting point at which you can always refer back to in your performance testing. Good luck, -- jhell,v From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 04:04:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2163F1065679 for ; Wed, 6 Oct 2010 04:04:05 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id CBCBC8FC13 for ; Wed, 6 Oct 2010 04:04:04 +0000 (UTC) Received: by qyk35 with SMTP id 35so3803491qyk.13 for ; Tue, 05 Oct 2010 21:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ahSAR1InSWYiRwMJOZbqOTDaxswQNz9whCXJxgQlqz4=; b=xw2vdrPbdYtmN073wRfXQ1oTXc+Uq+sWkUohZYa1n+naKwGTS52YwUqwmPbIMW9nOo 3mP2xIE36+m7ilvsXvouhUWr/0ZM1wEbhkMx6qEh/tPOypZjsygGI+oMzXPCnE6ypHyN 6oYlniqlCoxZM1QAbgn3x03t1bIJvWSyA/PNc= 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=oY/SErv78ttOVj9gE6dbdIk4qxG1aUlXcUJPjy5CkvIBh0Is/a5SdXnP72fXjOf1QN B0RCsHK7RU7bvS+tQXaZGK4aLrubyhDwNw4TxocbpR+famhwuBiylnqqCuow4PvZu6ct /scI08FsuFo6JiQjpXpJQ32EJzRAnOqb4kjQk= MIME-Version: 1.0 Received: by 10.224.10.204 with SMTP id q12mr8986360qaq.192.1286336216122; Tue, 05 Oct 2010 20:36:56 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Tue, 5 Oct 2010 20:36:56 -0700 (PDT) In-Reply-To: <20101006005350.62837.qmail@exxodus.fedaykin.here> References: <20101006005350.62837.qmail@exxodus.fedaykin.here> Date: Wed, 6 Oct 2010 03:36:56 +0000 Message-ID: From: Paul B Mahol To: Mario Sergio Fujikawa Ferreira Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Panic with msdosfs vs 1.3TB FAT32 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 04:04:05 -0000 On 10/6/10, Mario Sergio Fujikawa Ferreira wrote: > Hi, > > I mounted a 1.3TB FAT32 (32k cluster) filesystem on esata > /dev/ada4s1 under /media/esata/ with the '-l' (large option). > > I tried to create a directory and files but got errors: > > ------ > > g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 > > ------ > > Then, I tried unmounting the filesystem which resulted on > > ------ > > fsync: giving up on dirty > 0xffffff01bad6e1d8: tag devfs, type VCHR > usecount 1, writecount 0, refcount 38253 mountedhere 0xffffff00ac899600 > flags () > v_object 0xffffff008b839ca8 ref 0 pages 44786 > lock type devfs: EXCL by thread 0xffffff016506cba0 (pid 76462) > dev ada4s1 > g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 > g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 > fsync: giving up on dirty > 0xffffff01bad6e1d8: tag devfs, type VCHR > usecount 1, writecount 0, refcount 38253 mountedhere 0xffffff00ac899600 > flags () > v_object 0xffffff008b839ca8 ref 0 pages 44786 > lock type devfs: UNLOCKED > dev ada4s1 > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x4 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff803e60e4 > stack pointer = 0x28:0xffffff80e79ba860 > frame pointer = 0x28:0xffffff80e79ba8a0 > 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 = 25 (syncer) > > ------ > > The filesystem is clean since I find no errors under Windows > ('chkdsk /f'). > > I can otherwise mount, read and write on smaller FAT32 > filesystems. I think there might be a problem with the handling > of such a big FAT32 filesystem. > > A complete textdump is available at > > http://people.freebsd.org/~lioux/panic/2010100500/textdump.tar.2 > > Is this kind of error expected? Is there anything I can do > to help? > > I can reproduce this error with the 1.3TB fs easily. Comment in source claims that support for large fs are experimental and safe only in read only mode. Looking at your output it is obvious that offset should not be negative... From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 05:05:27 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF77D106564A for ; Wed, 6 Oct 2010 05:05:27 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2748FC0A for ; Wed, 6 Oct 2010 05:05:23 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id o964nYIq049994; Tue, 5 Oct 2010 23:49:34 -0500 (CDT) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=fail (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:content-type; b=AhWQ9PHR73xANBKv4OSzeahrJ8AfO3tb3P9s7OHaYsfDp4TpgSKJlMNp5CGXC+KRF eSfJGBH6GtiBG/BxHqrYDHgU7KScmWzBrCs6MCv9wQf2NEuC1SD7OQTQDKeb0qs8QND EgjdJJ950P6bJHupMJjfmyFGB1/mrRyF+GblPkU= Message-ID: <4CABFFDE.5090408@jrv.org> Date: Tue, 05 Oct 2010 23:49:34 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20100831215915.GE1932@garage.freebsd.pl> In-Reply-To: <20100831215915.GE1932@garage.freebsd.pl> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------040405010801000906030309" Cc: freebsd-fs Subject: ZFS v28 recv panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 05:05:28 -0000 This is a multi-part message in MIME format. --------------040405010801000906030309 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The following series of commands cause a kernel panic with pjd's 8/31 zfs v28 patches on svn 212080: zpool create rec1 da3 zpool create rec2 da4 zfs create rec1/a zfs create rec1/a/b zfs snapshot -r rec1@s1 zfs rename rec1/a/b rec1/c zfs destroy -r rec1/a zfs create rec1/a zfs rename rec1/c rec1/a/d zfs snapshot -r rec1@s2 zfs send -R rec1@s1 | zfs recv -dvuF rec2 zfs send -R -I @s1 rec1@s2 | zfs recv -dvuF rec2 (this is an attempt to wreak havoc on zfs send/recv by having a child dataset that is older than the parent, but it tickles a kernel bug rather than the zfs recv code) The textdump.tar file is available upon request. The panic string is: solaris assert: vp->v_count == 1, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line: 4510 The kernel config file: kraken:/root# cat /usr/src/sys/amd64/conf/BIGTEX include GENERIC ident BIGTEX nodevice hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #options PRINTF_BUFR_SIZE=128 nodevice uhid # "Human Interface Devices" options DEBUG_LOCKS options DEBUG_VFS_LOCKS kraken:/root# --------------040405010801000906030309 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="BIGTEX" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="BIGTEX" aW5jbHVkZSAJR0VORVJJQwppZGVudCAJCUJJR1RFWAoKbm9kZXZpY2UJaHB0cnIJCSMgSGln aHBvaW50IFJvY2tldFJBSUQgMTd4eCwgMjJ4eCwgMjN4eCwgMjV4eAoKI29wdGlvbnMJCVBS SU5URl9CVUZSX1NJWkU9MTI4Cgpub2RldmljZSAgICAgICAgIHVoaWQgICAgICAgICAgICAj ICJIdW1hbiBJbnRlcmZhY2UgRGV2aWNlcyIKCm9wdGlvbnMgICAgICAgICBERUJVR19MT0NL UwpvcHRpb25zICAgICAgICAgREVCVUdfVkZTX0xPQ0tTCg== --------------040405010801000906030309 Content-Type: application/octet-stream; x-mac-type="0"; x-mac-creator="0"; name="textdump.tar.1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="textdump.tar.1" ZGRiLnR4dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADA2MDAAAAAA MAAAAAAAAAAwAAAAAAAAADE0MDAwMAAAAAAAADExNDUyNzczMTI3ACAgNzEwMwAgAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAAAHJvb3QA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd2hlZWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkYjowOmtkYi5lbnRlci5wYW5pYz4gIHJ1biBs b2NraW5mbwpkYjoxOmxvY2tpbmZvPiBzaG93IGxvY2tzCmV4Y2x1c2l2ZSBzbGVlcCBtdXRl eCB2bm9kZSBpbnRlcmxvY2sgKHZub2RlIGludGVybG9jaykgciA9IDAgKDB4ZmZmZmZmMDAw OGQ1ZDhjOCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwv Y29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96ZnNfdm5vcHMuYzo0NTA5 CnNoYXJlZCBzeCB6ZnN2ZnMtPnpfdGVhcmRvd25faW5hY3RpdmVfbG9jayAoemZzdmZzLT56 X3RlYXJkb3duX2luYWN0aXZlX2xvY2spIHIgPSAwICgweGZmZmZmZjAxMzE5YTAyMDApIGxv Y2tlZCBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3Bl bnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvemZzX3Zub3BzLmM6NDUwMwpleGNsdXNpdmUg c2xlZXAgbXV0ZXggR2lhbnQgKEdpYW50KSByID0gMCAoMHhmZmZmZmZmZjgwYzNkZGEwKSBs b2NrZWQgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfbW91bnQuYzoxMTI5CmV4Y2x1c2l2ZSBs b2NrbWdyIHpmcyAoemZzKSByID0gMCAoMHhmZmZmZmYwMDA4ZDVkODAwKSBsb2NrZWQgQCAv dXNyL3NyYy9zeXMva2Vybi92ZnNfbW91bnQuYzoxMTk5CmRiOjE6bG9ja3M+ICBzaG93IGFs bGxvY2tzClByb2Nlc3MgMTcxMSAoemZzKSB0aHJlYWQgMHhmZmZmZmYwMDNkNGVlNDQwICgx MDAyMTQpCmV4Y2x1c2l2ZSBzbGVlcCBtdXRleCB2bm9kZSBpbnRlcmxvY2sgKHZub2RlIGlu dGVybG9jaykgciA9IDAgKDB4ZmZmZmZmMDAwOGQ1ZDhjOCkgbG9ja2VkIEAgL3Vzci9zcmMv c3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29t bW9uL2ZzL3pmcy96ZnNfdm5vcHMuYzo0NTA5CnNoYXJlZCBzeCB6ZnN2ZnMtPnpfdGVhcmRv d25faW5hY3RpdmVfbG9jayAoemZzdmZzLT56X3RlYXJkb3duX2luYWN0aXZlX2xvY2spIHIg PSAwICgweGZmZmZmZjAxMzE5YTAyMDApIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9tb2R1bGVz L3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMv emZzX3Zub3BzLmM6NDUwMwpleGNsdXNpdmUgc2xlZXAgbXV0ZXggR2lhbnQgKEdpYW50KSBy ID0gMCAoMHhmZmZmZmZmZjgwYzNkZGEwKSBsb2NrZWQgQCAvdXNyL3NyYy9zeXMva2Vybi92 ZnNfbW91bnQuYzoxMTI5CmV4Y2x1c2l2ZSBsb2NrbWdyIHpmcyAoemZzKSByID0gMCAoMHhm ZmZmZmYwMDA4ZDVkODAwKSBsb2NrZWQgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfbW91bnQu YzoxMTk5ClByb2Nlc3MgMTYxMSAoZnNja191ZnMpIHRocmVhZCAweGZmZmZmZjAwMDhlODA4 ODAgKDEwMDE0NikKZXhjbHVzaXZlIGxvY2ttZ3IgYnVmd2FpdCAoYnVmd2FpdCkgciA9IDAg KDB4ZmZmZmZmODBhNTU4ODNmOCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jp by5jOjE5MTIKZXhjbHVzaXZlIGxvY2ttZ3IgYnVmd2FpdCAoYnVmd2FpdCkgciA9IDAgKDB4 ZmZmZmZmODBhNWNlODMwMCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5j OjI2NTkKZXhjbHVzaXZlIGxvY2ttZ3IgdWZzICh1ZnMpIHIgPSAwICgweGZmZmZmZjAwMDhl MWM1ODgpIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNvcHMuYzoxNTA0 CmRiOjE6YWxsbG9ja3M+ICBzaG93IGxvY2tlZHZub2RzCkxvY2tlZCB2bm9kZXMKZGI6MDpr ZGIuZW50ZXIucGFuaWM+ICBzaG93IHBjcHUKY3B1aWQgICAgICAgID0gMgpkeW5hbWljIHBj cHUgPSAweGZmZmZmZjgwN2Y0MjJjMDAKY3VydGhyZWFkICAgID0gMHhmZmZmZmYwMDNkNGVl NDQwOiBwaWQgMTcxMSAiaW5pdGlhbCB0aHJlYWQiCmN1cnBjYiAgICAgICA9IDB4ZmZmZmZm ODBlZDdjY2QwMApmcGN1cnRocmVhZCAgPSBub25lCmlkbGV0aHJlYWQgICA9IDB4ZmZmZmZm MDAwMjhlMDg4MDogdGlkIDEwMDAwOCAiaWRsZTogY3B1MiIKY3VycG1hcCAgICAgID0gMHhm ZmZmZmYwMDA4ZGEwNzcwCnRzc3AgICAgICAgICA9IDB4ZmZmZmZmZmY4MGUxZTZkMApjb21t b250c3NwICAgPSAweGZmZmZmZmZmODBlMWU2ZDAKcnNwMCAgICAgICAgID0gMHhmZmZmZmY4 MGVkN2NjZDAwCmdzMzJwICAgICAgICA9IDB4ZmZmZmZmZmY4MGUxZDUwOApsZHQgICAgICAg ICAgPSAweGZmZmZmZmZmODBlMWQ1NDgKdHNzICAgICAgICAgID0gMHhmZmZmZmZmZjgwZTFk NTM4CnNwaW4gbG9ja3MgaGVsZDoKZGI6MDprZGIuZW50ZXIucGFuaWM+ICBidApUcmFjaW5n IHBpZCAxNzExIHRpZCAxMDAyMTQgdGQgMHhmZmZmZmYwMDNkNGVlNDQwCmtkYl9lbnRlcigp IGF0IGtkYl9lbnRlcisweDNkCnBhbmljKCkgYXQgcGFuaWMrMHgxN2IKemZzX2ZyZWVic2Rf aW5hY3RpdmUoKSBhdCB6ZnNfZnJlZWJzZF9pbmFjdGl2ZQp6ZnNfZnJlZWJzZF9pbmFjdGl2 ZSgpIGF0IHpmc19mcmVlYnNkX2luYWN0aXZlKzB4MWEKVk9QX0lOQUNUSVZFX0FQVigpIGF0 IFZPUF9JTkFDVElWRV9BUFYrMHhiNQp2aW5hY3RpdmUoKSBhdCB2aW5hY3RpdmUrMHg5MAp2 cHV0eCgpIGF0IHZwdXR4KzB4MmRjCmRvdW5tb3VudCgpIGF0IGRvdW5tb3VudCsweDM4OAp1 bm1vdW50KCkgYXQgdW5tb3VudCsweDI3ZQpzeXNjYWxsZW50ZXIoKSBhdCBzeXNjYWxsZW50 ZXIrMHgxYWEKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHg0YwpYZmFzdF9zeXNjYWxsKCkgYXQg WGZhc3Rfc3lzY2FsbCsweGUyCi0tLSBzeXNjYWxsICgyMiwgRnJlZUJTRCBFTEY2NCwgdW5t b3VudCksIHJpcCA9IDB4ODAxMDYzMzVjLCByc3AgPSAweDdmZmZmZmZmNjVmOCwgcmJwID0g MHg4MDE4MTA4MDAgLS0tCmRiOjA6a2RiLmVudGVyLnBhbmljPiAgcHMKICBwaWQgIHBwaWQg IHBncnAgICB1aWQgICBzdGF0ZSAgIHdtZXNnICAgICAgICAgd2NoYW4gICAgICAgIGNtZAog MTcxMSAgMTY5NyAgMTY5NyAgICAgMCAgUisgICAgICBDUFUgMiAgICAgICAgICAgICAgICAg ICAgICAgaW5pdGlhbCB0aHJlYWQKIDE2OTcgIDE2MjkgIDE2OTcgICAgIDAgIFMrICAgICAg d2FpdCAgICAgMHhmZmZmZmYwMTMwOWJlOGMwIGJhc2gKIDE2MjkgIDE2MjYgIDE2MjkgICAg IDAgIFNzKyAgICAgd2FpdCAgICAgMHhmZmZmZmYwMDNkNTEwMDAwIGJhc2gKIDE2MjYgIDE1 MTIgIDE2MjYgICAgIDAgIFNzICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMDNkMjRlYjQwIHNz aGQKIDE2MTEgIDE1OTQgICAgMjkgICAgIDAgIEQgICAgICAgYmlvcmQgICAgMHhmZmZmZmY4 MGE1NTg4MzYwIGZzY2tfdWZzCiAxNjA2ICAgICAxICAxNjA2ICAgICAwICBTcysgICAgIHR0 eWluICAgIDB4ZmZmZmZmMDAwODg3MjBhOCBnZXR0eQogMTYwNSAgICAgMSAgMTYwNSAgICAg MCAgU3MrICAgICB0dHlpbiAgICAweGZmZmZmZjAwMDg4NzI0YTggZ2V0dHkKIDE2MDQgICAg IDEgIDE2MDQgICAgIDAgIFNzKyAgICAgdHR5aW4gICAgMHhmZmZmZmYwMDAyOWQxNGE4IGdl dHR5CiAxNjAzICAgICAxICAxNjAzICAgICAwICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZm MDAwMjlkMThhOCBnZXR0eQogMTYwMiAgICAgMSAgMTYwMiAgICAgMCAgU3MrICAgICB0dHlp biAgICAweGZmZmZmZjAwMDI5ZDFjYTggZ2V0dHkKIDE2MDEgICAgIDEgIDE2MDEgICAgIDAg IFNzKyAgICAgdHR5aW4gICAgMHhmZmZmZmYwMDA4ODcwMGE4IGdldHR5CiAxNjAwICAgICAx ICAxNjAwICAgICAwICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZmMDAwODg3MDRhOCBnZXR0 eQogMTU5OSAgICAgMSAgMTU5OSAgICAgMCAgU3MrICAgICB0dHlpbiAgICAweGZmZmZmZjAw MDg4NzA4YTggZ2V0dHkKIDE1OTUgICAgIDEgICAgMjkgICAgIDAgIFMrICAgICAgcGlwZXJk ICAgMHhmZmZmZmYwMDA4ZTI1MDAwIGxvZ2dlcgogMTU5NCAgICAgMSAgICAyOSAgICAgMCAg UysgICAgICB3YWl0ICAgICAweGZmZmZmZjAwM2Q1MGY0NjAgZnNjawogMTU2NSAgICAgMSAg MTU2NSAgICAgMCAgU3MgICAgICBzZWxlY3QgICAweGZmZmZmZjAwMDhiNDUyNDAgaW5ldGQK IDE1MzMgICAgIDEgIDE1MzMgICAgIDAgIFNzICAgICAgbmFuc2xwICAgMHhmZmZmZmZmZjgw YzNlYTQ4IGNyb24KIDE1MjYgICAgIDEgIDE1MjYgICAgMjUgIFNzICAgICAgcGF1c2UgICAg MHhmZmZmZmYwMDA4ZDM4NTAwIHNlbmRtYWlsCiAxNTIwICAgICAxICAxNTIwICAgICAwICBT cyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDAzZDI0ZjI0MCBzZW5kbWFpbAogMTUxMiAgICAg MSAgMTUxMiAgICAgMCAgU3MgICAgICBzZWxlY3QgICAweGZmZmZmZjAwMDhhZWE5NDAgc3No ZAogMTQzMiAgICAgMSAgMTQzMiAgICAgMCAgU3MgICAgICBzZWxlY3QgICAweGZmZmZmZjAw MDhiOWI2YzAgbnRwZAogMTM2NyAgICAgMSAgMTM2NiAgICAgMCAgUyAgICAgICBuYW5zbHAg ICAweGZmZmZmZmZmODBjM2VhNDggc21hcnRkCiAxMzQwICAgICAxICAxMzQwICAgICAwICBT cyAgICAgIHJwY3N2YyAgIDB4ZmZmZmZmMDAwOGUwMjlhMCBOTE06IG1hc3RlcgogMTMzMyAg ICAgMSAgMTMzMyAgICAgMCAgU3MgICAgICBzZWxlY3QgICAweGZmZmZmZjAwMDhhZWEwYzAg cnBjLnN0YXRkCiAxMjI3ICAgICAxICAxMjI3ICAgICAwICBTcyAgICAgIHNlbGVjdCAgIDB4 ZmZmZmZmMDAwOGFlYWJjMCBycGNiaW5kCiAxMjAzICAgICAxICAxMjAzICAgICAwICBTcyAg ICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDAwOGI0NzQ0MCBzeXNsb2dkCiAgOTcxICAgICAxICAg OTcxICAgICAwICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDAwOGI0NzFjMCBkZXZkCiAg MTI2ICAgICAxICAgMTI2ICAgICAwICBTcyAgICAgIHBhdXNlICAgIDB4ZmZmZmZmMDAwOGQ1 Mzk2MCBhZGprZXJudHoKICAgMjggICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgbTp3MSAg ICAgMHhmZmZmZmYwMDA4YzQ2NDAwIFtnX21pcnJvciBQNTVVRDYtdXNyXQogICAyNyAgICAg MCAgICAgMCAgICAgMCAgREwgICAgICBtOncxICAgICAweGZmZmZmZjAwMDI2NjQ0MDAgW2df bWlycm9yIFA1NVVENi12YXJdCiAgIDI2ICAgICAwICAgICAwICAgICAwICBETCAgICAgIG06 dzEgICAgIDB4ZmZmZmZmMDAwMjY2NDIwMCBbZ19taXJyb3IgUDU1VUQ2LXRtcF0KICAgMjUg ICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgbTp3MSAgICAgMHhmZmZmZmYwMDAyNjY0ODAw IFtnX21pcnJvciBQNTVVRDYtc3dhXQogICAyNCAgICAgMCAgICAgMCAgICAgMCAgREwgICAg ICBtOncxICAgICAweGZmZmZmZjAwMDI2NjQ2MDAgW2dfbWlycm9yIFA1NVVENi1yb29dCiAg IDIzICAgICAwICAgICAwICAgICAwICBETCAgICAgIGZsb3djbGVhIDB4ZmZmZmZmZmY4MGUw MGRiMCBbZmxvd2NsZWFuZXJdCiAgIDIyICAgICAwICAgICAwICAgICAwICBETCAgICAgIHNk Zmx1c2ggIDB4ZmZmZmZmZmY4MGUwZmVkOCBbc29mdGRlcGZsdXNoXQogICAyMSAgICAgMCAg ICAgMCAgICAgMCAgREwgICAgICB2bHJ1d3QgICAweGZmZmZmZjAwMDhiMDU0NjAgW3ZubHJ1 XQogICAyMCAgICAgMCAgICAgMCAgICAgMCAgREwgICAgICBzeW5jZXIgICAweGZmZmZmZmZm ODBlMDBiMDAgW3N5bmNlcl0KICAgMTkgICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgcHNs ZWVwICAgMHhmZmZmZmZmZjgwZTAwNjI4IFtidWZkYWVtb25dCiAgIDE4ICAgICAwICAgICAw ICAgICAwICBETCAgICAgIHBnemVybyAgIDB4ZmZmZmZmZmY4MGUxOWQzYyBbcGFnZXplcm9d CiAgIDE3ICAgICAwICAgICAwICAgICAwICBETCAgICAgIHBzbGVlcCAgIDB4ZmZmZmZmZmY4 MGUxOGZlOCBbdm1kYWVtb25dCiAgIDE2ICAgICAwICAgICAwICAgICAwICBETCAgICAgIHBz bGVlcCAgIDB4ZmZmZmZmZmY4MGUxOGZhYyBbcGFnZWRhZW1vbl0KICAgMTUgICAgIDAgICAg IDAgICAgIDAgIERMICAgICAgY2NiX3NjYW4gMHhmZmZmZmZmZjgwYzA2Y2UwIFt4cHRfdGhy ZF0KICAgIDkgICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgd2FpdGluZ18gMHhmZmZmZmZm ZjgwZTAzOTgwIFtzY3RwX2l0ZXJhdG9yXQogICAgOCAgICAgMCAgICAgMCAgICAgMCAgREwg ICAgICAodGhyZWFkZWQpICAgICAgICAgICAgICAgICAgW3pmc2tlcm5dCjEwMDk5MSAgICAg ICAgICAgICAgICAgICBEICAgICAgIHR4LT50eF9zIDB4ZmZmZmZmMDE0MjNjZDYxMCBbdHhn X3RocmVhZF9lbnRlcl0KMTAwOTkwICAgICAgICAgICAgICAgICAgIEQgICAgICAgdHgtPnR4 X3EgMHhmZmZmZmYwMTQyM2NkNjMwIFt0eGdfdGhyZWFkX2VudGVyXQoxMDA4MzggICAgICAg ICAgICAgICAgICAgRCAgICAgICB0eC0+dHhfcyAweGZmZmZmZjAxMjMyNjJlMTAgW3R4Z190 aHJlYWRfZW50ZXJdCjEwMDgzNyAgICAgICAgICAgICAgICAgICBEICAgICAgIHR4LT50eF9x IDB4ZmZmZmZmMDEyMzI2MmUzMCBbdHhnX3RocmVhZF9lbnRlcl0KMTAwNjg2ICAgICAgICAg ICAgICAgICAgIEQgICAgICAgdHgtPnR4X3MgMHhmZmZmZmYwMTQyZmI5MjEwIFt0eGdfdGhy ZWFkX2VudGVyXQoxMDA2ODUgICAgICAgICAgICAgICAgICAgRCAgICAgICB0eC0+dHhfcSAw eGZmZmZmZjAxNDJmYjkyMzAgW3R4Z190aHJlYWRfZW50ZXJdCjEwMDUzNCAgICAgICAgICAg ICAgICAgICBEICAgICAgIHR4LT50eF9zIDB4ZmZmZmZmMDEyZDJhYzYxMCBbdHhnX3RocmVh ZF9lbnRlcl0KMTAwNTMzICAgICAgICAgICAgICAgICAgIEQgICAgICAgdHgtPnR4X3EgMHhm ZmZmZmYwMTJkMmFjNjMwIFt0eGdfdGhyZWFkX2VudGVyXQoxMDAzODIgICAgICAgICAgICAg ICAgICAgRCAgICAgICB0eC0+dHhfcyAweGZmZmZmZjAxMmQyNGRlMTAgW3R4Z190aHJlYWRf ZW50ZXJdCjEwMDM4MSAgICAgICAgICAgICAgICAgICBEICAgICAgIHR4LT50eF9xIDB4ZmZm ZmZmMDEyZDI0ZGUzMCBbdHhnX3RocmVhZF9lbnRlcl0KMTAwMDk1ICAgICAgICAgICAgICAg ICAgIEQgICAgICAgbDJhcmNfZmUgMHhmZmZmZmZmZjgxMTk3MDQwIFtsMmFyY19mZWVkX3Ro cmVhZF0KMTAwMDk0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgYXJjX3JlY2wgMHhmZmZm ZmZmZjgxMTg3MTIwIFthcmNfcmVjbGFpbV90aHJlYWRdCiAgICA3ICAgICAwICAgICAwICAg ICAwICBETCAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwMmMwODg0OCBbZmRjMF0KICAgIDYg ICAgIDAgICAgIDAgICAgIDAgIFNMICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwOWQzMDAw IFtmdzBfcHJvYmVdCiAgICA1ICAgICAwICAgICAwICAgICAwICBETCAgICAgIGlkbGUgICAg IDB4ZmZmZmZmODAwMDk4ZDAwMCBbbXB0X3JlY292ZXJ5MF0KICAgMTQgICAgIDAgICAgIDAg ICAgIDAgIERMICAgICAgKHRocmVhZGVkKSAgICAgICAgICAgICAgICAgIFt1c2JdCjEwMDA3 OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDlkMGRk MCBbdXNidXM4XQoxMDAwNzcgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAw eGZmZmZmZjgwMDA5ZDBkNzggW3VzYnVzOF0KMTAwMDc2ICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwOWQwZDIwIFt1c2J1czhdCjEwMDA3NSAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDlkMGNjOCBbdXNi dXM4XQoxMDAwNzQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZm ZjgwMDA5YzdlZjAgW3VzYnVzN10KMTAwMDczICAgICAgICAgICAgICAgICAgIEQgICAgICAg LSAgICAgICAgMHhmZmZmZmY4MDAwOWM3ZTk4IFt1c2J1czddCjEwMDA3MiAgICAgICAgICAg ICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDljN2U0MCBbdXNidXM3XQox MDAwNzEgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDA5 YzdkZTggW3VzYnVzN10KMTAwMDcwICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmY4MDAwOWJlZWYwIFt1c2J1czZdCjEwMDA2OSAgICAgICAgICAgICAgICAg ICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDliZWU5OCBbdXNidXM2XQoxMDAwNjgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDA5YmVlNDAg W3VzYnVzNl0KMTAwMDY3ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmY4MDAwOWJlZGU4IFt1c2J1czZdCjEwMDA2NiAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDliNWVmMCBbdXNidXM1XQoxMDAwNjUgICAgICAg ICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDA5YjVlOTggW3VzYnVz NV0KMTAwMDY0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4 MDAwOWI1ZTQwIFt1c2J1czVdCjEwMDA2MyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0g ICAgICAgIDB4ZmZmZmZmODAwMDliNWRlOCBbdXNidXM1XQoxMDAwNjIgICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDA5YWNlZjAgW3VzYnVzNF0KMTAw MDYxICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwOWFj ZTk4IFt1c2J1czRdCjEwMDA2MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmODAwMDlhY2U0MCBbdXNidXM0XQoxMDAwNTkgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDA5YWNkZTggW3VzYnVzNF0KMTAwMDU1ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwOTdjZGQwIFt1 c2J1czNdCjEwMDA1NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmODAwMDk3Y2Q3OCBbdXNidXMzXQoxMDAwNTMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjgwMDA5N2NkMjAgW3VzYnVzM10KMTAwMDUyICAgICAgICAg ICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwOTdjY2M4IFt1c2J1czNd CjEwMDA1MSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAw MDk3M2VmMCBbdXNidXMyXQoxMDAwNTAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGZmZmZmZjgwMDA5NzNlOTggW3VzYnVzMl0KMTAwMDQ5ICAgICAgICAgICAgICAg ICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwOTczZTQwIFt1c2J1czJdCjEwMDA0 OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDk3M2Rl OCBbdXNidXMyXQoxMDAwNDYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAw eGZmZmZmZjgwMDA5NmFlZjAgW3VzYnVzMV0KMTAwMDQ1ICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwOTZhZTk4IFt1c2J1czFdCjEwMDA0NCAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDk2YWU0MCBbdXNi dXMxXQoxMDAwNDMgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZm ZjgwMDA5NmFkZTggW3VzYnVzMV0KMTAwMDQxICAgICAgICAgICAgICAgICAgIEQgICAgICAg LSAgICAgICAgMHhmZmZmZmY4MDAwOTYxZWYwIFt1c2J1czBdCjEwMDA0MCAgICAgICAgICAg ICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDk2MWU5OCBbdXNidXMwXQox MDAwMzkgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDA5 NjFlNDAgW3VzYnVzMF0KMTAwMDM4ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmY4MDAwOTYxZGU4IFt1c2J1czBdCiAgIDEzICAgICAwICAgICAwICAgICAw ICBETCAgICAgIC0gICAgICAgIDB4ZmZmZmZmZmY4MGMzZTc0NCBbeWFycm93XQogICAgNCAg ICAgMCAgICAgMCAgICAgMCAgREwgICAgICAtICAgICAgICAweGZmZmZmZmZmODBjM2FkMjgg W2dfZG93bl0KICAgIDMgICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgLSAgICAgICAgMHhm ZmZmZmZmZjgwYzNhZDIwIFtnX3VwXQogICAgMiAgICAgMCAgICAgMCAgICAgMCAgREwgICAg ICAtICAgICAgICAweGZmZmZmZmZmODBjM2FkMTAgW2dfZXZlbnRdCiAgIDEyICAgICAwICAg ICAwICAgICAwICBXTCAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBbaW50cl0K MTAwMDg1ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtpcnExOiBhdGtiZDBdCjEwMDA4NCAgICAgICAgICAgICAgICAgICBJICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpMDogdWFydF0KMTAwMDgyICAgICAg ICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtpcnEy NTk6IGFoY2kzXQoxMDAwNzkgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW2lycTE3OiBmd29oY2kwXQoxMDAwNTggICAgICAgICAgICAg ICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTIzOiB1aGNp MyBlaGNpMV0KMTAwMDU2ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtpcnExOTogYXRhcGNpMCsrXQoxMDAwNDcgICAgICAgICAgICAg ICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTE4OiB1aGNp MiBlaGNpMCpdCjEwMDA0MiAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbaXJxMjE6IHVoY2kxXQoxMDAwMzcgICAgICAgICAgICAgICAg ICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTE2OiB1aGNpMCBt cHQwK10KMTAwMDM2ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtpcnEyNTY6IHNpaXMwXQoxMDAwMzUgICAgICAgICAgICAgICAgICAg SSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTk6IGFjcGkwXQoxMDAw MzEgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW3N3aTY6IHRhc2sgcXVldWVdCjEwMDAzMCAgICAgICAgICAgICAgICAgICBJICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNjogR2lhbnQgdGFza3FdCjEwMDAy OCAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbc3dpNTogK10KMTAwMDI2ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFtzd2kyOiBjYW1iaW9dCjEwMDAyMCAgICAgICAgICAgICAg ICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpMzogdm1dCjEw MDAxOSAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbc3dpMTogbmV0aXNyIDBdCjEwMDAxOCAgICAgICAgICAgICAgICAgICBJICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNDogY2xvY2tdCjEwMDAxNyAgICAg ICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dp NDogY2xvY2tdCjEwMDAxNiAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbc3dpNDogY2xvY2tdCjEwMDAxNSAgICAgICAgICAgICAgICAg ICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNDogY2xvY2tdCjEw MDAxNCAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbc3dpNDogY2xvY2tdCjEwMDAxMyAgICAgICAgICAgICAgICAgICBJICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNDogY2xvY2tdCjEwMDAxMiAgICAgICAg ICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNDog Y2xvY2tdCjEwMDAxMSAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBbc3dpNDogY2xvY2tdCiAgIDExICAgICAwICAgICAwICAgICAwICBS TCAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBbaWRsZV0KMTAwMDEwICAgICAg ICAgICAgICAgICAgIFJ1biAgICAgQ1BVIDAgICAgICAgICAgICAgICAgICAgICAgIFtpZGxl OiBjcHUwXQoxMDAwMDkgICAgICAgICAgICAgICAgICAgUnVuICAgICBDUFUgMSAgICAgICAg ICAgICAgICAgICAgICAgW2lkbGU6IGNwdTFdCjEwMDAwOCAgICAgICAgICAgICAgICAgICBD YW5SdW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaWRsZTogY3B1Ml0KMTAwMDA3 ICAgICAgICAgICAgICAgICAgIFJ1biAgICAgQ1BVIDMgICAgICAgICAgICAgICAgICAgICAg IFtpZGxlOiBjcHUzXQoxMDAwMDYgICAgICAgICAgICAgICAgICAgUnVuICAgICBDUFUgNCAg ICAgICAgICAgICAgICAgICAgICAgW2lkbGU6IGNwdTRdCjEwMDAwNSAgICAgICAgICAgICAg ICAgICBSdW4gICAgIENQVSA1ICAgICAgICAgICAgICAgICAgICAgICBbaWRsZTogY3B1NV0K MTAwMDA0ICAgICAgICAgICAgICAgICAgIFJ1biAgICAgQ1BVIDYgICAgICAgICAgICAgICAg ICAgICAgIFtpZGxlOiBjcHU2XQoxMDAwMDMgICAgICAgICAgICAgICAgICAgUnVuICAgICBD UFUgNyAgICAgICAgICAgICAgICAgICAgICAgW2lkbGU6IGNwdTddCiAgICAxICAgICAwICAg ICAxICAgICAwICBTTHMgICAgIHdhaXQgICAgIDB4ZmZmZmZmMDAwMjhkYjhjMCBbaW5pdF0K ICAgMTAgICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgYXVkaXRfd28gMHhmZmZmZmZmZjgw ZTBmMDEwIFthdWRpdF0KICAgIDAgICAgIDAgICAgIDAgICAgIDAgIERMcyAgICAgKHRocmVh ZGVkKSAgICAgICAgICAgICAgICAgIFtrZXJuZWxdCjEwMDk5MiAgICAgICAgICAgICAgICAg ICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExODg1NjgwMCBbemlsX2NsZWFuXQoxMDA5 OTQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDhhMGQ0 ODAgW3ppbF9jbGVhbl0KMTAwOTkzICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmYwMTE4ODU2ODgwIFt6aWxfY2xlYW5dCjEwMDk4OSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExYjZkZjIwMCBbemZzX3ZuX3JlbGVf dGFza3FdCjEwMDk4OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAzZDIyYzAwMCBbemlvX2lvY3RsX2ludHJdCjEwMDk4NyAgICAgICAgICAgICAgICAg ICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExODg1NzI4MCBbemlvX2lvY3RsX2lzc3Vl XQoxMDA5ODYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAw M2Q2MTQ2MDAgW3ppb19jbGFpbV9pbnRyXQoxMDA5ODUgICAgICAgICAgICAgICAgICAgRCAg ICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ2ODAgW3ppb19jbGFpbV9pc3N1ZV0KMTAw OTg0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0 NzAwIFt6aW9fZnJlZV9pbnRyXQoxMDA5ODMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzk5XQoxMDA5ODIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzk4XQoxMDA5ODEgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzk3XQoxMDA5ODAg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzk2XQoxMDA5NzkgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzk1XQoxMDA5Nzgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzk0XQoxMDA5NzcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzkzXQoxMDA5NzYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzkyXQoxMDA5NzUgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzkxXQoxMDA5NzQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzkwXQoxMDA5NzMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzg5XQoxMDA5NzIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzg4XQoxMDA5NzEgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzg3XQoxMDA5NzAg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzg2XQoxMDA5NjkgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzg1XQoxMDA5Njgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzg0XQoxMDA5NjcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzgzXQoxMDA5NjYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzgyXQoxMDA5NjUgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzgxXQoxMDA5NjQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzgwXQoxMDA5NjMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzc5XQoxMDA5NjIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzc4XQoxMDA5NjEgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzc3XQoxMDA5NjAg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzc2XQoxMDA5NTkgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzc1XQoxMDA5NTgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzc0XQoxMDA5NTcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzczXQoxMDA5NTYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzcyXQoxMDA5NTUgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzcxXQoxMDA5NTQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzcwXQoxMDA5NTMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzY5XQoxMDA5NTIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzY4XQoxMDA5NTEgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzY3XQoxMDA5NTAg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzY2XQoxMDA5NDkgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzY1XQoxMDA5NDgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzY0XQoxMDA5NDcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzYzXQoxMDA5NDYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzYyXQoxMDA5NDUgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzYxXQoxMDA5NDQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzYwXQoxMDA5NDMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzU5XQoxMDA5NDIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzU4XQoxMDA5NDEgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzU3XQoxMDA5NDAg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzU2XQoxMDA5MzkgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzU1XQoxMDA5Mzgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzU0XQoxMDA5MzcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzUzXQoxMDA5MzYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzUyXQoxMDA5MzUgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzUxXQoxMDA5MzQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzUwXQoxMDA5MzMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzQ5XQoxMDA5MzIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzQ4XQoxMDA5MzEgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzQ3XQoxMDA5MzAg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzQ2XQoxMDA5MjkgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzQ1XQoxMDA5Mjgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzQ0XQoxMDA5MjcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzQzXQoxMDA5MjYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzQyXQoxMDA5MjUgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzQxXQoxMDA5MjQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzQwXQoxMDA5MjMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzM5XQoxMDA5MjIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzM4XQoxMDA5MjEgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzM3XQoxMDA5MjAg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzM2XQoxMDA5MTkgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzM1XQoxMDA5MTgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzM0XQoxMDA5MTcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzMzXQoxMDA5MTYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzMyXQoxMDA5MTUgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzMxXQoxMDA5MTQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzMwXQoxMDA5MTMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzI5XQoxMDA5MTIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzI4XQoxMDA5MTEgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzI3XQoxMDA5MTAg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzI2XQoxMDA5MDkgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzI1XQoxMDA5MDgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzI0XQoxMDA5MDcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzIzXQoxMDA5MDYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzIyXQoxMDA5MDUgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzIxXQoxMDA5MDQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzIwXQoxMDA5MDMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzE5XQoxMDA5MDIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzE4XQoxMDA5MDEgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzE3XQoxMDA5MDAg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzE2XQoxMDA4OTkgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzE1XQoxMDA4OTgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzE0XQoxMDA4OTcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzEzXQoxMDA4OTYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzEyXQoxMDA4OTUgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzExXQoxMDA4OTQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAg W3ppb19mcmVlX2lzc3VlXzEwXQoxMDA4OTMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzldCjEwMDg5MiAg ICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNDc4MCBb emlvX2ZyZWVfaXNzdWVfOF0KMTAwODkxICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAg ICAgICAgMHhmZmZmZmYwMDNkNjE0NzgwIFt6aW9fZnJlZV9pc3N1ZV83XQoxMDA4OTAgICAg ICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3pp b19mcmVlX2lzc3VlXzZdCjEwMDg4OSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAg ICAgIDB4ZmZmZmZmMDAzZDYxNDc4MCBbemlvX2ZyZWVfaXNzdWVfNV0KMTAwODg4ICAgICAg ICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0NzgwIFt6aW9f ZnJlZV9pc3N1ZV80XQoxMDA4ODcgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVlX2lzc3VlXzNdCjEwMDg4NiAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNDc4MCBbemlvX2Zy ZWVfaXNzdWVfMl0KMTAwODg1ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAg MHhmZmZmZmYwMDNkNjE0NzgwIFt6aW9fZnJlZV9pc3N1ZV8xXQoxMDA4ODQgICAgICAgICAg ICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ3ODAgW3ppb19mcmVl X2lzc3VlXzBdCjEwMDg4MyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4 ZmZmZmZmMDAzZDI4ZDg4MCBbemlvX3dyaXRlX2ludHJfaGlnaF0KMTAwODgyICAgICAgICAg ICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkMjhkODgwIFt6aW9fd3Jp dGVfaW50cl9oaWdoXQoxMDA4ODEgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjAwM2QyOGQ4ODAgW3ppb193cml0ZV9pbnRyX2hpZ2hdCjEwMDg4MCAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDg4MCBbemlv X3dyaXRlX2ludHJfaGlnaF0KMTAwODc5ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAg ICAgICAgMHhmZmZmZmYwMDNkMjhkODgwIFt6aW9fd3JpdGVfaW50cl9oaWdoXQoxMDA4Nzgg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2QzZWVkODAg W3ppb193cml0ZV9pbnRyXzddCjEwMDg3NyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0g ICAgICAgIDB4ZmZmZmZmMDAzZDNlZWQ4MCBbemlvX3dyaXRlX2ludHJfNl0KMTAwODc2ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkM2VlZDgwIFt6 aW9fd3JpdGVfaW50cl81XQoxMDA4NzUgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGZmZmZmZjAwM2QzZWVkODAgW3ppb193cml0ZV9pbnRyXzRdCjEwMDg3NCAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDNlZWQ4MCBbemlv X3dyaXRlX2ludHJfM10KMTAwODczICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmYwMDNkM2VlZDgwIFt6aW9fd3JpdGVfaW50cl8yXQoxMDA4NzIgICAgICAg ICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2QzZWVkODAgW3ppb193 cml0ZV9pbnRyXzFdCjEwMDg3MSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmMDAzZDNlZWQ4MCBbemlvX3dyaXRlX2ludHJfMF0KMTAwODcwICAgICAgICAg ICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkMjhkYTAwIFt6aW9fd3Jp dGVfaXNzdWVfaGlnXQoxMDA4NjkgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjAwM2QyOGRhMDAgW3ppb193cml0ZV9pc3N1ZV9oaWddCjEwMDg2OCAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZGEwMCBbemlv X3dyaXRlX2lzc3VlX2hpZ10KMTAwODY3ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAg ICAgICAgMHhmZmZmZmYwMDNkMjhkYTAwIFt6aW9fd3JpdGVfaXNzdWVfaGlnXQoxMDA4NjYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2QyOGRhMDAg W3ppb193cml0ZV9pc3N1ZV9oaWddCjEwMDg2NSAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDk4MCBbemlvX3dyaXRlX2lzc3VlXzddCjEwMDg2 NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDk4 MCBbemlvX3dyaXRlX2lzc3VlXzZdCjEwMDg2MyAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDk4MCBbemlvX3dyaXRlX2lzc3VlXzVdCjEwMDg2 MiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDk4 MCBbemlvX3dyaXRlX2lzc3VlXzRdCjEwMDg2MSAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDk4MCBbemlvX3dyaXRlX2lzc3VlXzNdCjEwMDg2 MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDk4 MCBbemlvX3dyaXRlX2lzc3VlXzJdCjEwMDg1OSAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDk4MCBbemlvX3dyaXRlX2lzc3VlXzFdCjEwMDg1 OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDk4 MCBbemlvX3dyaXRlX2lzc3VlXzBdCjEwMDg1NyAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDkwMCBbemlvX3JlYWRfaW50cl83XQoxMDA4NTYg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2QyOGQ5MDAg W3ppb19yZWFkX2ludHJfNl0KMTAwODU1ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAg ICAgICAgMHhmZmZmZmYwMDNkMjhkOTAwIFt6aW9fcmVhZF9pbnRyXzVdCjEwMDg1NCAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDI4ZDkwMCBbemlv X3JlYWRfaW50cl80XQoxMDA4NTMgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjAwM2QyOGQ5MDAgW3ppb19yZWFkX2ludHJfM10KMTAwODUyICAgICAgICAg ICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkMjhkOTAwIFt6aW9fcmVh ZF9pbnRyXzJdCjEwMDg1MSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4 ZmZmZmZmMDAzZDI4ZDkwMCBbemlvX3JlYWRfaW50cl8xXQoxMDA4NTAgICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2QyOGQ5MDAgW3ppb19yZWFkX2lu dHJfMF0KMTAwODQ5ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZm ZmYwMTE4OWNmODgwIFt6aW9fcmVhZF9pc3N1ZV83XQoxMDA4NDggICAgICAgICAgICAgICAg ICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTg5Y2Y4ODAgW3ppb19yZWFkX2lzc3Vl XzZdCjEwMDg0NyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm MDExODljZjg4MCBbemlvX3JlYWRfaXNzdWVfNV0KMTAwODQ2ICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTE4OWNmODgwIFt6aW9fcmVhZF9pc3N1ZV80 XQoxMDA4NDUgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAx MTg5Y2Y4ODAgW3ppb19yZWFkX2lzc3VlXzNdCjEwMDg0NCAgICAgICAgICAgICAgICAgICBE ICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExODljZjg4MCBbemlvX3JlYWRfaXNzdWVfMl0K MTAwODQzICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTE4 OWNmODgwIFt6aW9fcmVhZF9pc3N1ZV8xXQoxMDA4NDIgICAgICAgICAgICAgICAgICAgRCAg ICAgICAtICAgICAgICAweGZmZmZmZjAxMTg5Y2Y4ODAgW3ppb19yZWFkX2lzc3VlXzBdCjEw MDg0MSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExZjVl ZGQ4MCBbemlvX251bGxfaW50cl0KMTAwODQwICAgICAgICAgICAgICAgICAgIEQgICAgICAg LSAgICAgICAgMHhmZmZmZmYwMTFmNWVkZTAwIFt6aW9fbnVsbF9pc3N1ZV0KMTAwODM5ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTE4ODU3MzAwIFt6 aWxfY2xlYW5dCjEwMDgzNiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4 ZmZmZmZmMDAzZDNlZTIwMCBbemZzX3ZuX3JlbGVfdGFza3FdCjEwMDgzNSAgICAgICAgICAg ICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExYTM3MDY4MCBbemlvX2lvY3Rs X2ludHJdCjEwMDgzNCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDExODlmMDU4MCBbemlvX2lvY3RsX2lzc3VlXQoxMDA4MzMgICAgICAgICAgICAgICAg ICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2QyMmQ3ODAgW3ppb19jbGFpbV9pbnRy XQoxMDA4MzIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAw M2QyMmQ2ODAgW3ppb19jbGFpbV9pc3N1ZV0KMTAwODMxICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTFhMzcwMjgwIFt6aW9fZnJlZV9pbnRyXQoxMDA4 MzAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzk5XQoxMDA4MjkgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzk4XQoxMDA4 MjggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzk3XQoxMDA4MjcgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzk2XQoxMDA4 MjYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzk1XQoxMDA4MjUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzk0XQoxMDA4 MjQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzkzXQoxMDA4MjMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzkyXQoxMDA4 MjIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzkxXQoxMDA4MjEgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzkwXQoxMDA4 MjAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzg5XQoxMDA4MTkgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzg4XQoxMDA4 MTggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzg3XQoxMDA4MTcgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzg2XQoxMDA4 MTYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzg1XQoxMDA4MTUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzg0XQoxMDA4 MTQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzgzXQoxMDA4MTMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzgyXQoxMDA4 MTIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzgxXQoxMDA4MTEgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzgwXQoxMDA4 MTAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzc5XQoxMDA4MDkgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzc4XQoxMDA4 MDggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzc3XQoxMDA4MDcgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzc2XQoxMDA4 MDYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzc1XQoxMDA4MDUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzc0XQoxMDA4 MDQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzczXQoxMDA4MDMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzcyXQoxMDA4 MDIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzcxXQoxMDA4MDEgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzcwXQoxMDA4 MDAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzY5XQoxMDA3OTkgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzY4XQoxMDA3 OTggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzY3XQoxMDA3OTcgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzY2XQoxMDA3 OTYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzY1XQoxMDA3OTUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzY0XQoxMDA3 OTQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzYzXQoxMDA3OTMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzYyXQoxMDA3 OTIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzYxXQoxMDA3OTEgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzYwXQoxMDA3 OTAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzU5XQoxMDA3ODkgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzU4XQoxMDA3 ODggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzU3XQoxMDA3ODcgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzU2XQoxMDA3 ODYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzU1XQoxMDA3ODUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzU0XQoxMDA3 ODQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzUzXQoxMDA3ODMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzUyXQoxMDA3 ODIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzUxXQoxMDA3ODEgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzUwXQoxMDA3 ODAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzQ5XQoxMDA3NzkgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzQ4XQoxMDA3 NzggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzQ3XQoxMDA3NzcgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzQ2XQoxMDA3 NzYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzQ1XQoxMDA3NzUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzQ0XQoxMDA3 NzQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzQzXQoxMDA3NzMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzQyXQoxMDA3 NzIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzQxXQoxMDA3NzEgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzQwXQoxMDA3 NzAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzM5XQoxMDA3NjkgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzM4XQoxMDA3 NjggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzM3XQoxMDA3NjcgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzM2XQoxMDA3 NjYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzM1XQoxMDA3NjUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzM0XQoxMDA3 NjQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzMzXQoxMDA3NjMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzMyXQoxMDA3 NjIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzMxXQoxMDA3NjEgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzMwXQoxMDA3 NjAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzI5XQoxMDA3NTkgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzI4XQoxMDA3 NTggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzI3XQoxMDA3NTcgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzI2XQoxMDA3 NTYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzI1XQoxMDA3NTUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzI0XQoxMDA3 NTQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzIzXQoxMDA3NTMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzIyXQoxMDA3 NTIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzIxXQoxMDA3NTEgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzIwXQoxMDA3 NTAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzE5XQoxMDA3NDkgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzE4XQoxMDA3 NDggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzE3XQoxMDA3NDcgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzE2XQoxMDA3 NDYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzE1XQoxMDA3NDUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzE0XQoxMDA3 NDQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzEzXQoxMDA3NDMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzEyXQoxMDA3 NDIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzExXQoxMDA3NDEgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzEwXQoxMDA3 NDAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4 MDAgW3ppb19mcmVlX2lzc3VlXzldCjEwMDczOSAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDExNTk3OTgwMCBbemlvX2ZyZWVfaXNzdWVfOF0KMTAwNzM4 ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTE1OTc5ODAw IFt6aW9fZnJlZV9pc3N1ZV83XQoxMDA3MzcgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzZdCjEwMDczNiAg ICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExNTk3OTgwMCBb emlvX2ZyZWVfaXNzdWVfNV0KMTAwNzM1ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAg ICAgICAgMHhmZmZmZmYwMTE1OTc5ODAwIFt6aW9fZnJlZV9pc3N1ZV80XQoxMDA3MzQgICAg ICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTU5Nzk4MDAgW3pp b19mcmVlX2lzc3VlXzNdCjEwMDczMyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAg ICAgIDB4ZmZmZmZmMDExNTk3OTgwMCBbemlvX2ZyZWVfaXNzdWVfMl0KMTAwNzMyICAgICAg ICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTE1OTc5ODAwIFt6aW9f ZnJlZV9pc3N1ZV8xXQoxMDA3MzEgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjAxMTU5Nzk4MDAgW3ppb19mcmVlX2lzc3VlXzBdCjEwMDczMCAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYwOTk4MCBbemlvX3dy aXRlX2ludHJfaGlnaF0KMTAwNzI5ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmYwMDNkNjA5OTgwIFt6aW9fd3JpdGVfaW50cl9oaWdoXQoxMDA3MjggICAg ICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MDk5ODAgW3pp b193cml0ZV9pbnRyX2hpZ2hdCjEwMDcyNyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0g ICAgICAgIDB4ZmZmZmZmMDAzZDYwOTk4MCBbemlvX3dyaXRlX2ludHJfaGlnaF0KMTAwNzI2 ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjA5OTgw IFt6aW9fd3JpdGVfaW50cl9oaWdoXQoxMDA3MjUgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAwM2Q2MDljMDAgW3ppb193cml0ZV9pbnRyXzddCjEwMDcy NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYwOWMw MCBbemlvX3dyaXRlX2ludHJfNl0KMTAwNzIzICAgICAgICAgICAgICAgICAgIEQgICAgICAg LSAgICAgICAgMHhmZmZmZmYwMDNkNjA5YzAwIFt6aW9fd3JpdGVfaW50cl81XQoxMDA3MjIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MDljMDAg W3ppb193cml0ZV9pbnRyXzRdCjEwMDcyMSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0g ICAgICAgIDB4ZmZmZmZmMDAzZDYwOWMwMCBbemlvX3dyaXRlX2ludHJfM10KMTAwNzIwICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjA5YzAwIFt6 aW9fd3JpdGVfaW50cl8yXQoxMDA3MTkgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGZmZmZmZjAwM2Q2MDljMDAgW3ppb193cml0ZV9pbnRyXzFdCjEwMDcxOCAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYwOWMwMCBbemlv X3dyaXRlX2ludHJfMF0KMTAwNzE3ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmYwMDNkNjA5ZDgwIFt6aW9fd3JpdGVfaXNzdWVfaGlnXQoxMDA3MTYgICAg ICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MDlkODAgW3pp b193cml0ZV9pc3N1ZV9oaWddCjEwMDcxNSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0g ICAgICAgIDB4ZmZmZmZmMDAzZDYwOWQ4MCBbemlvX3dyaXRlX2lzc3VlX2hpZ10KMTAwNzE0 ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjA5ZDgw IFt6aW9fd3JpdGVfaXNzdWVfaGlnXQoxMDA3MTMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAwM2Q2MDlkODAgW3ppb193cml0ZV9pc3N1ZV9oaWddCjEw MDcxMiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYx NDAwMCBbemlvX3dyaXRlX2lzc3VlXzddCjEwMDcxMSAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNDAwMCBbemlvX3dyaXRlX2lzc3VlXzZdCjEw MDcxMCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYx NDAwMCBbemlvX3dyaXRlX2lzc3VlXzVdCjEwMDcwOSAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNDAwMCBbemlvX3dyaXRlX2lzc3VlXzRdCjEw MDcwOCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYx NDAwMCBbemlvX3dyaXRlX2lzc3VlXzNdCjEwMDcwNyAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNDAwMCBbemlvX3dyaXRlX2lzc3VlXzJdCjEw MDcwNiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYx NDAwMCBbemlvX3dyaXRlX2lzc3VlXzFdCjEwMDcwNSAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNDAwMCBbemlvX3dyaXRlX2lzc3VlXzBdCjEw MDcwNCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExODlj ZjQwMCBbemlvX3JlYWRfaW50cl83XQoxMDA3MDMgICAgICAgICAgICAgICAgICAgRCAgICAg ICAtICAgICAgICAweGZmZmZmZjAxMTg5Y2Y0MDAgW3ppb19yZWFkX2ludHJfNl0KMTAwNzAy ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTE4OWNmNDAw IFt6aW9fcmVhZF9pbnRyXzVdCjEwMDcwMSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0g ICAgICAgIDB4ZmZmZmZmMDExODljZjQwMCBbemlvX3JlYWRfaW50cl80XQoxMDA3MDAgICAg ICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMTg5Y2Y0MDAgW3pp b19yZWFkX2ludHJfM10KMTAwNjk5ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmYwMTE4OWNmNDAwIFt6aW9fcmVhZF9pbnRyXzJdCjEwMDY5OCAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExODljZjQwMCBbemlvX3Jl YWRfaW50cl8xXQoxMDA2OTcgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAw eGZmZmZmZjAxMTg5Y2Y0MDAgW3ppb19yZWFkX2ludHJfMF0KMTAwNjk2ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA4YTBkOTAwIFt6aW9fcmVhZF9p c3N1ZV83XQoxMDA2OTUgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZm ZmZmZjAwMDhhMGQ5MDAgW3ppb19yZWFkX2lzc3VlXzZdCjEwMDY5NCAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwOGEwZDkwMCBbemlvX3JlYWRfaXNz dWVfNV0KMTAwNjkzICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZm ZmYwMDA4YTBkOTAwIFt6aW9fcmVhZF9pc3N1ZV80XQoxMDA2OTIgICAgICAgICAgICAgICAg ICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDhhMGQ5MDAgW3ppb19yZWFkX2lzc3Vl XzNdCjEwMDY5MSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm MDAwOGEwZDkwMCBbemlvX3JlYWRfaXNzdWVfMl0KMTAwNjkwICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA4YTBkOTAwIFt6aW9fcmVhZF9pc3N1ZV8x XQoxMDA2ODkgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAw MDhhMGQ5MDAgW3ppb19yZWFkX2lzc3VlXzBdCjEwMDY4OCAgICAgICAgICAgICAgICAgICBE ICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNTQ4MCBbemlvX251bGxfaW50cl0KMTAw Njg3ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE1 NDAwIFt6aW9fbnVsbF9pc3N1ZV0KMTAwNjg0ICAgICAgICAgICAgICAgICAgIEQgICAgICAg LSAgICAgICAgMHhmZmZmZmYwMDA4YTBkNDAwIFt6ZnNfdm5fcmVsZV90YXNrcV0KMTAwNjgz ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA4YTBkMzgw IFt6aW9faW9jdGxfaW50cl0KMTAwNjgyICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAg ICAgICAgMHhmZmZmZmYwMDA4YTBkYTAwIFt6aW9faW9jdGxfaXNzdWVdCjEwMDY4MSAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwOGEwZGE4MCBbemlv X2NsYWltX2ludHJdCjEwMDY4MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmMDAwOGEwZGI4MCBbemlvX2NsYWltX2lzc3VlXQoxMDA2NzkgICAgICAgICAg ICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDg4ZjVkODAgW3ppb19mcmVl X2ludHJdCjEwMDY3OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfOTldCjEwMDY3NyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfOThdCjEwMDY3NiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfOTddCjEwMDY3NSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfOTZdCjEwMDY3NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfOTVdCjEwMDY3MyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfOTRdCjEwMDY3MiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfOTNdCjEwMDY3MSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfOTJdCjEwMDY3MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfOTFdCjEwMDY2OSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfOTBdCjEwMDY2OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfODldCjEwMDY2NyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfODhdCjEwMDY2NiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfODddCjEwMDY2NSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfODZdCjEwMDY2NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfODVdCjEwMDY2MyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfODRdCjEwMDY2MiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfODNdCjEwMDY2MSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfODJdCjEwMDY2MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfODFdCjEwMDY1OSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfODBdCjEwMDY1OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNzldCjEwMDY1NyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNzhdCjEwMDY1NiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNzddCjEwMDY1NSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNzZdCjEwMDY1NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNzVdCjEwMDY1MyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNzRdCjEwMDY1MiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNzNdCjEwMDY1MSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNzJdCjEwMDY1MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNzFdCjEwMDY0OSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNzBdCjEwMDY0OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNjldCjEwMDY0NyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNjhdCjEwMDY0NiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNjddCjEwMDY0NSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNjZdCjEwMDY0NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNjVdCjEwMDY0MyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNjRdCjEwMDY0MiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNjNdCjEwMDY0MSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNjJdCjEwMDY0MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNjFdCjEwMDYzOSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNjBdCjEwMDYzOCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNTldCjEwMDYzNyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNThdCjEwMDYzNiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNTddCjEwMDYzNSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNTZdCjEwMDYzNCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNTVdCjEwMDYzMyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNTRdCjEwMDYzMiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNTNdCjEwMDYzMSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNTJdCjEwMDYzMCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNTFdCjEwMDYyOSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNTBdCjEwMDYyOCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNDldCjEwMDYyNyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNDhdCjEwMDYyNiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNDddCjEwMDYyNSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNDZdCjEwMDYyNCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNDVdCjEwMDYyMyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNDRdCjEwMDYyMiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNDNdCjEwMDYyMSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNDJdCjEwMDYyMCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfNDFdCjEwMDYxOSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfNDBdCjEwMDYxOCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMzldCjEwMDYxNyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMzhdCjEwMDYxNiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMzddCjEwMDYxNSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMzZdCjEwMDYxNCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMzVdCjEwMDYxMyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMzRdCjEwMDYxMiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMzNdCjEwMDYxMSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMzJdCjEwMDYxMCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMzFdCjEwMDYwOSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMzBdCjEwMDYwOCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMjldCjEwMDYwNyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMjhdCjEwMDYwNiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMjddCjEwMDYwNSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMjZdCjEwMDYwNCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMjVdCjEwMDYwMyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMjRdCjEwMDYwMiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMjNdCjEwMDYwMSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMjJdCjEwMDYwMCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMjFdCjEwMDU5OSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMjBdCjEwMDU5OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMTldCjEwMDU5NyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMThdCjEwMDU5NiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMTddCjEwMDU5NSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMTZdCjEwMDU5NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMTVdCjEwMDU5MyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMTRdCjEwMDU5MiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMTNdCjEwMDU5MSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMTJdCjEwMDU5MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMTFdCjEwMDU4OSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNz dWVfMTBdCjEwMDU4OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfOV0KMTAwNTg3ICAgICAgICAgICAgICAg ICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA4OWQxODgwIFt6aW9fZnJlZV9pc3N1 ZV84XQoxMDA1ODYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZm ZjAwMDg5ZDE4ODAgW3ppb19mcmVlX2lzc3VlXzddCjEwMDU4NSAgICAgICAgICAgICAgICAg ICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVf Nl0KMTAwNTg0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYw MDA4OWQxODgwIFt6aW9fZnJlZV9pc3N1ZV81XQoxMDA1ODMgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDg5ZDE4ODAgW3ppb19mcmVlX2lzc3VlXzRd CjEwMDU4MiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAw ODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfM10KMTAwNTgxICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA4OWQxODgwIFt6aW9fZnJlZV9pc3N1ZV8yXQox MDA1ODAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDg5 ZDE4ODAgW3ppb19mcmVlX2lzc3VlXzFdCjEwMDU3OSAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwODlkMTg4MCBbemlvX2ZyZWVfaXNzdWVfMF0KMTAw NTc4ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0 NDAwIFt6aW9fd3JpdGVfaW50cl9oaWdoXQoxMDA1NzcgICAgICAgICAgICAgICAgICAgRCAg ICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQ0MDAgW3ppb193cml0ZV9pbnRyX2hpZ2hd CjEwMDU3NiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAz ZDYxNDQwMCBbemlvX3dyaXRlX2ludHJfaGlnaF0KMTAwNTc1ICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0NDAwIFt6aW9fd3JpdGVfaW50cl9o aWdoXQoxMDA1NzQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZm ZjAwM2Q2MTQ0MDAgW3ppb193cml0ZV9pbnRyX2hpZ2hdCjEwMDU3MyAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNDM4MCBbemlvX3dyaXRlX2lu dHJfN10KMTAwNTcyICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZm ZmYwMDNkNjE0MzgwIFt6aW9fd3JpdGVfaW50cl82XQoxMDA1NzEgICAgICAgICAgICAgICAg ICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQzODAgW3ppb193cml0ZV9pbnRy XzVdCjEwMDU3MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm MDAzZDYxNDM4MCBbemlvX3dyaXRlX2ludHJfNF0KMTAwNTY5ICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0MzgwIFt6aW9fd3JpdGVfaW50cl8z XQoxMDA1NjggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAw M2Q2MTQzODAgW3ppb193cml0ZV9pbnRyXzJdCjEwMDU2NyAgICAgICAgICAgICAgICAgICBE ICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNDM4MCBbemlvX3dyaXRlX2ludHJfMV0K MTAwNTY2ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNk NjE0MzgwIFt6aW9fd3JpdGVfaW50cl8wXQoxMDA1NjUgICAgICAgICAgICAgICAgICAgRCAg ICAgICAtICAgICAgICAweGZmZmZmZjAwM2Q2MTQzMDAgW3ppb193cml0ZV9pc3N1ZV9oaWdd CjEwMDU2NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAz ZDYxNDMwMCBbemlvX3dyaXRlX2lzc3VlX2hpZ10KMTAwNTYzICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0MzAwIFt6aW9fd3JpdGVfaXNzdWVf aGlnXQoxMDA1NjIgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZm ZjAwM2Q2MTQzMDAgW3ppb193cml0ZV9pc3N1ZV9oaWddCjEwMDU2MSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAzZDYxNDMwMCBbemlvX3dyaXRlX2lz c3VlX2hpZ10KMTAwNTYwICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmYwMDNkNjE0MjgwIFt6aW9fd3JpdGVfaXNzdWVfN10KMTAwNTU5ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0MjgwIFt6aW9fd3JpdGVf aXNzdWVfNl0KMTAwNTU4ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmYwMDNkNjE0MjgwIFt6aW9fd3JpdGVfaXNzdWVfNV0KMTAwNTU3ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0MjgwIFt6aW9fd3JpdGVf aXNzdWVfNF0KMTAwNTU2ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmYwMDNkNjE0MjgwIFt6aW9fd3JpdGVfaXNzdWVfM10KMTAwNTU1ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0MjgwIFt6aW9fd3JpdGVf aXNzdWVfMl0KMTAwNTU0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmYwMDNkNjE0MjgwIFt6aW9fd3JpdGVfaXNzdWVfMV0KMTAwNTUzICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDNkNjE0MjgwIFt6aW9fd3JpdGVf aXNzdWVfMF0KMTAwNTUyICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmYwMTFhMzcwYTgwIFt6aW9fcmVhZF9pbnRyXzddCjEwMDU1MSAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDExYTM3MGE4MCBbemlvX3JlYWRfaW50 cl82XQoxMDA1NTAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZm ZjAxMWEzNzBhODAgW3ppb19yZWFkX2ludHJfNV0KMTAwNTQ5ICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTFhMzcwYTgwIFt6aW9fcmVhZF9pbnRyXzRd CjEwMDU0OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDEx YTM3MGE4MCBbemlvX3JlYWRfaW50cl8zXQoxMDA1NDcgICAgICAgICAgICAgICAgICAgRCAg ICAgICAtICAgICAgICAweGZmZmZmZjAxMWEzNzBhODAgW3ppb19yZWFkX2ludHJfMl0KMTAw NTQ2ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTFhMzcw YTgwIFt6aW9fcmVhZF9pbnRyXzFdCjEwMDU0NSAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDExYTM3MGE4MCBbemlvX3JlYWRfaW50cl8wXQoxMDA1NDQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAxMWEzNzBiMDAg W3ppb19yZWFkX2lzc3VlXzddCjEwMDU0MyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0g ICAgICAgIDB4ZmZmZmZmMDExYTM3MGIwMCBbemlvX3JlYWRfaXNzdWVfNl0KMTAwNTQyICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMTFhMzcwYjAwIFt6 aW9fcmVhZF9pc3N1ZV81XQoxMDA1NDEgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGZmZmZmZjAxMWEzNzBiMDAgW3ppb19yZWFkX2lzc3VlXzRdCjEwMDU0MCAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZjb25maWcudHh0AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDYwMAAAAAAwAAAAAAAAADAAAAAAAAAA NjUwMQAAAAAAAAAAMTE0NTI3NzMxMjcAICA3NDY2ACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyAAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB3aGVlbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAG9wdGlvbnMJQ09ORklHX0FVVE9HRU5FUkFURUQKaWRlbnQJQklHVEVYCm1h Y2hpbmUJYW1kNjQKY3B1CUhBTU1FUgptYWtlb3B0aW9ucwlERUJVRz0tZwpvcHRpb25zCURF QlVHX1ZGU19MT0NLUwpvcHRpb25zCURFQlVHX0xPQ0tTCm9wdGlvbnMJVVNCX0RFQlVHCm9w dGlvbnMJQUhfU1VQUE9SVF9BUjU0MTYKb3B0aW9ucwlJRUVFODAyMTFfU1VQUE9SVF9NRVNI Cm9wdGlvbnMJSUVFRTgwMjExX0FNUERVX0FHRQpvcHRpb25zCUlFRUU4MDIxMV9ERUJVRwpv cHRpb25zCUFIRF9SRUdfUFJFVFRZX1BSSU5UCm9wdGlvbnMJQUhDX1JFR19QUkVUVFlfUFJJ TlQKb3B0aW9ucwlBVEFfU1RBVElDX0lECm9wdGlvbnMJU01QCm9wdGlvbnMJTUFMTE9DX0RF QlVHX01BWFpPTkVTPTgKb3B0aW9ucwlXSVRORVNTX1NLSVBTUElOCm9wdGlvbnMJV0lUTkVT UwpvcHRpb25zCUlOVkFSSUFOVF9TVVBQT1JUCm9wdGlvbnMJSU5WQVJJQU5UUwpvcHRpb25z CURFQURMS1JFUwpvcHRpb25zCUdEQgpvcHRpb25zCUREQgpvcHRpb25zCUtEQgpvcHRpb25z CUlOQ0xVREVfQ09ORklHX0ZJTEUKb3B0aW9ucwlGTE9XVEFCTEUKb3B0aW9ucwlNQUMKb3B0 aW9ucwlBVURJVApvcHRpb25zCUhXUE1DX0hPT0tTCm9wdGlvbnMJS0JEX0lOU1RBTExfQ0RF VgpvcHRpb25zCVBSSU5URl9CVUZSX1NJWkU9MTI4Cm9wdGlvbnMJX0tQT1NJWF9QUklPUklU WV9TQ0hFRFVMSU5HCm9wdGlvbnMJUDEwMDNfMUJfU0VNQVBIT1JFUwpvcHRpb25zCVNZU1ZT RU0Kb3B0aW9ucwlTWVNWTVNHCm9wdGlvbnMJU1lTVlNITQpvcHRpb25zCVNUQUNLCm9wdGlv bnMJS1RSQUNFCm9wdGlvbnMJU0NTSV9ERUxBWT01MDAwCm9wdGlvbnMJQ09NUEFUX0ZSRUVC U0Q3Cm9wdGlvbnMJQ09NUEFUX0ZSRUVCU0Q2Cm9wdGlvbnMJQ09NUEFUX0ZSRUVCU0Q1Cm9w dGlvbnMJQ09NUEFUX0ZSRUVCU0Q0Cm9wdGlvbnMJQ09NUEFUX0ZSRUVCU0QzMgpvcHRpb25z CUdFT01fTEFCRUwKb3B0aW9ucwlHRU9NX1BBUlRfR1BUCm9wdGlvbnMJUFNFVURPRlMKb3B0 aW9ucwlQUk9DRlMKb3B0aW9ucwlDRDk2NjAKb3B0aW9ucwlNU0RPU0ZTCm9wdGlvbnMJTkZT X1JPT1QKb3B0aW9ucwlORlNMT0NLRApvcHRpb25zCU5GU1NFUlZFUgpvcHRpb25zCU5GU0NM SUVOVApvcHRpb25zCU1EX1JPT1QKb3B0aW9ucwlVRlNfR0pPVVJOQUwKb3B0aW9ucwlVRlNf RElSSEFTSApvcHRpb25zCVVGU19BQ0wKb3B0aW9ucwlTT0ZUVVBEQVRFUwpvcHRpb25zCUZG UwpvcHRpb25zCVNDVFAKb3B0aW9ucwlJTkVUNgpvcHRpb25zCUlORVQKb3B0aW9ucwlQUkVF TVBUSU9OCm9wdGlvbnMJU0NIRURfVUxFCm9wdGlvbnMJR0VPTV9QQVJUX01CUgpvcHRpb25z CUdFT01fUEFSVF9FQlJfQ09NUEFUCm9wdGlvbnMJR0VPTV9QQVJUX0VCUgpvcHRpb25zCUdF T01fUEFSVF9CU0QKZGV2aWNlCWlzYQpkZXZpY2UJbWVtCmRldmljZQlpbwpkZXZpY2UJdWFy dF9uczgyNTAKZGV2aWNlCWNwdWZyZXEKZGV2aWNlCWFjcGkKZGV2aWNlCXBjaQpkZXZpY2UJ ZmRjCmRldmljZQlhdGEKZGV2aWNlCWF0YWRpc2sKZGV2aWNlCWF0YXJhaWQKZGV2aWNlCWF0 YXBpY2QKZGV2aWNlCWF0YXBpZmQKZGV2aWNlCWF0YXBpc3QKZGV2aWNlCWFoYwpkZXZpY2UJ YWhkCmRldmljZQlhbWQKZGV2aWNlCWhwdGlvcApkZXZpY2UJaXNwCmRldmljZQltcHQKZGV2 aWNlCXN5bQpkZXZpY2UJdHJtCmRldmljZQlhZHYKZGV2aWNlCWFkdwpkZXZpY2UJYWljCmRl dmljZQlidApkZXZpY2UJc2NidXMKZGV2aWNlCWNoCmRldmljZQlkYQpkZXZpY2UJc2EKZGV2 aWNlCWNkCmRldmljZQlwYXNzCmRldmljZQlzZXMKZGV2aWNlCWFtcgpkZXZpY2UJYXJjbXNy CmRldmljZQljaXNzCmRldmljZQlkcHQKZGV2aWNlCWhwdG12CmRldmljZQlpaXIKZGV2aWNl CWlwcwpkZXZpY2UJbWx5CmRldmljZQl0d2EKZGV2aWNlCWFhYwpkZXZpY2UJYWFjcApkZXZp Y2UJaWRhCmRldmljZQltZmkKZGV2aWNlCW1seApkZXZpY2UJdHdlCmRldmljZQlhdGtiZGMK ZGV2aWNlCWF0a2JkCmRldmljZQlwc20KZGV2aWNlCWtiZG11eApkZXZpY2UJdmdhCmRldmlj ZQlzcGxhc2gKZGV2aWNlCXNjCmRldmljZQlhZ3AKZGV2aWNlCWNiYgpkZXZpY2UJcGNjYXJk CmRldmljZQljYXJkYnVzCmRldmljZQl1YXJ0CmRldmljZQlwcGMKZGV2aWNlCXBwYnVzCmRl dmljZQlscHQKZGV2aWNlCXBsaXAKZGV2aWNlCXBwaQpkZXZpY2UJZGUKZGV2aWNlCWVtCmRl dmljZQlpZ2IKZGV2aWNlCWl4Z2JlCmRldmljZQlsZQpkZXZpY2UJdGkKZGV2aWNlCXR4cApk ZXZpY2UJdngKZGV2aWNlCW1paWJ1cwpkZXZpY2UJYWUKZGV2aWNlCWFnZQpkZXZpY2UJYWxj CmRldmljZQlhbGUKZGV2aWNlCWJjZQpkZXZpY2UJYmZlCmRldmljZQliZ2UKZGV2aWNlCWRj CmRldmljZQlldApkZXZpY2UJZnhwCmRldmljZQlqbWUKZGV2aWNlCWxnZQpkZXZpY2UJbXNr CmRldmljZQluZmUKZGV2aWNlCW5nZQpkZXZpY2UJcGNuCmRldmljZQlyZQpkZXZpY2UJcmwK ZGV2aWNlCXNmCmRldmljZQlzZ2UKZGV2aWNlCXNpcwpkZXZpY2UJc2sKZGV2aWNlCXN0ZQpk ZXZpY2UJc3RnZQpkZXZpY2UJdGwKZGV2aWNlCXR4CmRldmljZQl2Z2UKZGV2aWNlCXZyCmRl dmljZQl3YgpkZXZpY2UJeGwKZGV2aWNlCWNzCmRldmljZQllZApkZXZpY2UJZXgKZGV2aWNl CWVwCmRldmljZQlmZQpkZXZpY2UJc24KZGV2aWNlCXhlCmRldmljZQl3bGFuCmRldmljZQl3 bGFuX3dlcApkZXZpY2UJd2xhbl9jY21wCmRldmljZQl3bGFuX3RraXAKZGV2aWNlCXdsYW5f YW1ycgpkZXZpY2UJYW4KZGV2aWNlCWF0aApkZXZpY2UJYXRoX2hhbApkZXZpY2UJYXRoX3Jh dGVfc2FtcGxlCmRldmljZQlyYWwKZGV2aWNlCXdpCmRldmljZQlsb29wCmRldmljZQlyYW5k b20KZGV2aWNlCWV0aGVyCmRldmljZQl2bGFuCmRldmljZQl0dW4KZGV2aWNlCXB0eQpkZXZp Y2UJbWQKZGV2aWNlCWdpZgpkZXZpY2UJZmFpdGgKZGV2aWNlCWZpcm13YXJlCmRldmljZQli cGYKZGV2aWNlCXVoY2kKZGV2aWNlCW9oY2kKZGV2aWNlCWVoY2kKZGV2aWNlCXVzYgpkZXZp Y2UJdWtiZApkZXZpY2UJdWxwdApkZXZpY2UJdW1hc3MKZGV2aWNlCXVtcwpkZXZpY2UJdXJp bwpkZXZpY2UJdTNnCmRldmljZQl1YXJrCmRldmljZQl1YnNhCmRldmljZQl1ZnRkaQpkZXZp Y2UJdWlwYXEKZGV2aWNlCXVwbGNvbQpkZXZpY2UJdXNsY29tCmRldmljZQl1dmlzb3IKZGV2 aWNlCXV2c2NvbQpkZXZpY2UJYXVlCmRldmljZQlheGUKZGV2aWNlCWNkY2UKZGV2aWNlCWN1 ZQpkZXZpY2UJa3VlCmRldmljZQlydWUKZGV2aWNlCXVkYXYKZGV2aWNlCXJ1bQpkZXZpY2UJ dWF0aApkZXZpY2UJdXJhbApkZXZpY2UJenlkCmRldmljZQlmaXJld2lyZQpkZXZpY2UJc2Jw CmRldmljZQlmd2UKZGV2aWNlCWZ3aXAKZGV2aWNlCWRjb25zCmRldmljZQlkY29uc19jcm9t CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbXNnYnVmLnR4dAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADA2MDAAAAAAMAAAAAAAAAAwAAAAAAAAADE3Nzc0MAAA AAAAADExNDUyNzczMTI3ACAgNzY2MgAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAAAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAd2hlZWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAwOmFoY2ljaDg6MDowOjApOiBSZXF1ZXN0aW5nIFNDU0kgc2Vuc2UgZGF0YQooY2QxOmFo Y2ljaDk6MDowOjApOiBTQ1NJIHN0YXR1cyBlcnJvcgooY2QxOmFoY2ljaDk6MDowOjApOiBS ZXF1ZXN0aW5nIFNDU0kgc2Vuc2UgZGF0YQpkYTEgYXQgbXB0MCBidXMgMCBzY2J1czggdGFy Z2V0IDEzIGx1biAwCmRhMTogPEFUQSBTVDMyMDAwNTQyQVMgQ0MzMj4gRml4ZWQgRGlyZWN0 IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTE6IFNlcmlhbCBOdW1iZXIgICAgICAgICAgICAg NVhXMDFSOUIKZGExOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOiBDb21tYW5kIFF1ZXVl aW5nIGVuYWJsZWQKZGExOiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9y czogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTIgYXQgbXB0MCBidXMgMCBzY2J1czggdGFyZ2V0 IDE0IGx1biAwCmRhMjogPEFUQSBTVDMyMDAwNTQyQVMgQ0MzMj4gRml4ZWQgRGlyZWN0IEFj Y2VzcyBTQ1NJLTUgZGV2aWNlIApkYTI6IFNlcmlhbCBOdW1iZXIgICAgICAgICAgICAgNVhX MDFTWUYKZGEyOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEyOiBDb21tYW5kIFF1ZXVlaW5n IGVuYWJsZWQKZGEyOiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczog MjU1SCA2M1MvVCAyNDMyMDFDKQpkYTMgYXQgbXB0MCBidXMgMCBzY2J1czggdGFyZ2V0IDE1 IGx1biAwCmRhMzogPEFUQSBTVDMyMDAwNTQyQVMgQ0MzMj4gRml4ZWQgRGlyZWN0IEFjY2Vz cyBTQ1NJLTUgZGV2aWNlIApkYTM6IFNlcmlhbCBOdW1iZXIgICAgICAgICAgICAgNVhXMDBG TVAKZGEzOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEzOiBDb21tYW5kIFF1ZXVlaW5nIGVu YWJsZWQKZGEzOiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1 SCA2M1MvVCAyNDMyMDFDKQooY2QwOmFoY2ljaDg6MDowOjApOiBTQ1NJIHN0YXR1cyBlcnJv cgooY2QwOmFoY2ljaDg6MDowOjApOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDAgMCAwIDAg MCAwIDAgMCAwIAooY2QwOmFoY2ljaDg6MDowOjApOiBDQU0gc3RhdHVzOiBTQ1NJIFN0YXR1 cyBFcnJvcgooY2QwOmFoY2ljaDg6MDowOjApOiBTQ1NJIHN0YXR1czogQ2hlY2sgQ29uZGl0 aW9uCihjZDA6YWhjaWNoODowOjA6MCk6IFNDU0kgc2Vuc2U6IE5PVCBSRUFEWSBhc2M6M2Es MSAoTWVkaXVtIG5vdCBwcmVzZW50IC0gdHJheSBjbG9zZWQpCihjZDA6YWhjaWNoODowOjA6 MCk6IEVycm9yIDYsIFVucmV0cnlhYmxlIGVycm9yCmNkMCBhdCBhaGNpY2g4IGJ1cyAwIHNj YnVzMTQgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8T3B0aWFyYyBEVkQgUlcgQUQtNzI0MVMgMS4w Mz4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlIApjZDA6IDE1MC4wMDBNQi9zIHRy YW5zZmVycyAoU0FUQSAxLngsIFVETUE1LCBBVEFQSSAxMmJ5dGVzLCBQSU8gODE5MmJ5dGVz KQpjZDA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFks IE1lZGl1bSBub3QgcHJlc2VudCAtIHRyYXkgY2xvc2VkCihjZDE6YWhjaWNoOTowOjA6MCk6 IFNDU0kgc3RhdHVzIGVycm9yCihjZDE6YWhjaWNoOTowOjA6MCk6IFJFQUQgQ0FQQUNJVFku IENEQjogMjUgMCAwIDAgMCAwIDAgMCAwIDAgCihjZDE6YWhjaWNoOTowOjA6MCk6IENBTSBz dGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihjZDE6YWhjaWNoOTowOjA6MCk6IFNDU0kgc3Rh dHVzOiBDaGVjayBDb25kaXRpb24KKGNkMTphaGNpY2g5OjA6MDowKTogU0NTSSBzZW5zZTog VU5JVCBBVFRFTlRJT04gY3NpOjAsMCwwLGUgYXNjOjI5LDAgKFBvd2VyIG9uLCByZXNldCwg b3IgYnVzIGRldmljZSByZXNldCBvY2N1cnJlZCkKKGNkMTphaGNpY2g5OjA6MDowKTogUmV0 cnlpbmcgY29tbWFuZCAocGVyIHNlbnNlIGRhdGEpCkdFT006IG5ldyBkaXNrIGNkMApHRU9N OiBuZXcgZGlzayBjZDEKR0VPTTogbmV3IGRpc2sgZGEwCkdFT006IG5ldyBkaXNrIGRhMQpH RU9NOiBuZXcgZGlzayBkYTIKR0VPTTogbmV3IGRpc2sgZGEzCmRhNCBhdCBtcHQwIGJ1cyAw IHNjYnVzOCB0YXJnZXQgMTYgbHVuIDAKZGE0OiA8QVRBIFNUMzIwMDA1NDJBUyBDQzMyPiBG aXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhNDogU2VyaWFsIE51bWJlciAg ICAgICAgICAgICA2WFcwMFY5RQpkYTQ6IDMwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTQ6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTQ6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIg Ynl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0MzIwMUMpCmNkMSBhdCBhaGNpY2g5IGJ1cyAw IHNjYnVzMTUgdGFyZ2V0IDAgbHVuIDAKY2QxOiA8SEwtRFQtU1QgQkQtUkUgIEdHVy1IMjBM IFlMMDU+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKY2QxOiBTZXJpYWwgTnVt YmVyIEsxNzkxR0EwMDU0CmNkMTogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwg VURNQTYsIEFUQVBJIDEyYnl0ZXMsIFBJTyA4MTkyYnl0ZXMpCmNkMTogY2QgcHJlc2VudCBb MTA1ODExMiB4IDIwNDggYnl0ZSByZWNvcmRzXQpkYTUgYXQgbXB0MCBidXMgMCBzY2J1czgg dGFyZ2V0IDE3IGx1biAwCmRhNTogPEFUQSBTVDMyMDAwNTQyQVMgQ0MzMj4gRml4ZWQgRGly ZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTU6IFNlcmlhbCBOdW1iZXIgICAgICAgICAg ICAgNlhXMDM3RFkKZGE1OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGE1OiBDb21tYW5kIFF1 ZXVlaW5nIGVuYWJsZWQKZGE1OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2Vj dG9yczogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTYgYXQgbXB0MCBidXMgMCBzY2J1czggdGFy Z2V0IDE4IGx1biAwCmRhNjogPEFUQSBTVDMyMDAwNTQyQVMgQ0MzMj4gRml4ZWQgRGlyZWN0 IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTY6IFNlcmlhbCBOdW1iZXIgICAgICAgICAgICAg NVhXMDJNWFkKZGE2OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGE2OiBDb21tYW5kIFF1ZXVl aW5nIGVuYWJsZWQKZGE2OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9y czogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTcgYXQgbXB0MCBidXMgMCBzY2J1czggdGFyZ2V0 IDE5IGx1biAwCmRhNzogPEFUQSBTVDMyMDAwNTQyQVMgQ0MzMj4gRml4ZWQgRGlyZWN0IEFj Y2VzcyBTQ1NJLTUgZGV2aWNlIApkYTc6IFNlcmlhbCBOdW1iZXIgICAgICAgICAgICAgNVhX MDJON1gKZGE3OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGE3OiBDb21tYW5kIFF1ZXVlaW5n IGVuYWJsZWQKZGE3OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczog MjU1SCA2M1MvVCAyNDMyMDFDKQphZGEwIGF0IHNpaXNjaDAgYnVzIDAgc2NidXMwIHRhcmdl dCAwIGx1biAwCmFkYTA6IDxTVDMyMDAwNTQyQVMgQ0MzND4gQVRBLTggU0FUQSAyLngoY2Qw OmFoY2ljaDg6MDowOjApOiBTQ1NJIHN0YXR1cyBlcnJvcgooY2QwOmFoY2ljaDg6MDowOjAp OiBSZXF1ZXN0aW5nIFNDU0kgc2Vuc2UgZGF0YQogZGV2aWNlCmFkYTA6IFNlcmlhbCBOdW1i ZXIgOVhXMDdaWDIKYWRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURN QTYsIChjZDA6YWhjaWNoODowOjA6MCk6IFNDU0kgc3RhdHVzIGVycm9yCihjZDA6YWhjaWNo ODowOjA6MCk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMCAwIDAgMCAwIDAgMCAwIDAgCihj ZDA6YWhjaWNoODowOjA6MCk6IENBTSBzdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihjZDA6 YWhjaWNoODowOjA6MCk6IFNDU0kgc3RhdHVzOiBDaGVjayBDb25kaXRpb24KKGNkMDphaGNp Y2g4OjA6MDowKTogU0NTSSBzZW5zZTogTk9UIFJFQURZIGFzYzozYSwxIChNZWRpdW0gbm90 IHByZXNlbnQgLSB0cmF5IGNsb3NlZCkKKGNkMDphaGNpY2g4OjA6MDowKTogRXJyb3IgNiwg VW5yZXRyeWFibGUgZXJyb3IKUElPIDgxOTJieXRlcykKYWRhMDogQ29tbWFuZCBRdWV1ZWlu ZyBlbmFibGVkCmFkYTA6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3Jz OiAxNkggNjNTL1QgMTYzODNDKQphZGExIGF0IHNpaXNjaDAgYnVzIDAgc2NidXMwIHRhcmdl dCAxIGx1biAwCmFkYTE6IDxTVDMyMDAwNTQyQVMgQ0MzMj4gQVRBLTggU0FUQSAyLnggZGV2 aWNlKGNkMDphaGNpY2g4OjA6MDowKTogU0NTSSBzdGF0dXMgZXJyb3IKKGNkMDphaGNpY2g4 OjA6MDowKTogUmVxdWVzdGluZyBTQ1NJIHNlbnNlIGRhdGEKCmFkYTE6IFNlcmlhbCBOdW1i ZXIgNVhXMDJQMEQKYWRhMTogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURN QTYsIFBJTyA4MTkyYnl0ZXMpKGNkMDphaGNpY2g4OjA6MDowKTogU0NTSSBzdGF0dXMgZXJy b3IKKGNkMDphaGNpY2g4OjA6MDowKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSAwIDAgMCAw IDAgMCAwIDAgMCAKKGNkMDphaGNpY2g4OjA6MDowKTogQ0FNIHN0YXR1czogU0NTSSBTdGF0 dXMgRXJyb3IKKGNkMDphaGNpY2g4OjA6MDowKTogU0NTSSBzdGF0dXM6IENoZWNrIENvbmRp dGlvbgooY2QwOmFoY2ljaDg6MDowOjApOiBTQ1NJIHNlbnNlOiBOT1QgUkVBRFkgYXNjOjNh LDEgKE1lZGl1bSBub3QgcHJlc2VudCAtIHRyYXkgY2xvc2VkKQooY2QwOmFoY2ljaDg6MDow OjApOiBFcnJvciA2LCBVbnJldHJ5YWJsZSBlcnJvcgoKYWRhMTogQ29tbWFuZCBRdWV1ZWlu ZyBlbmFibGVkCmFkYTE6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3Jz OiAxNkggNjNTL1QgMTYzODNDKQphZGEyIGF0IHNpaXNjaDAgYnVzIDAgc2NidXMwIHRhcmdl dCAyIGx1biAwCmFkYTI6IDxTVDMyMDAwNTQyQVMgQ0MzMj4gQVRBLTggU0FUQSAyLnggZGV2 aWNlCmFkYTI6IFNlcmlhbCBOdW1iZXIgNVhXMDFQSDYoY2QwOmFoY2ljaDg6MDowOjApOiBT Q1NJIHN0YXR1cyBlcnJvcgooY2QwOmFoY2ljaDg6MDowOjApOiBSZXF1ZXN0aW5nIFNDU0kg c2Vuc2UgZGF0YQoKYWRhMjogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURN QTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTI6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZChjZDA6 YWhjaWNoODowOjA6MCk6IFNDU0kgc3RhdHVzIGVycm9yCihjZDA6YWhjaWNoODowOjA6MCk6 IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMCAwIDAgMCAwIDAgMCAwIDAgCihjZDA6YWhjaWNo ODowOjA6MCk6IENBTSBzdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihjZDA6YWhjaWNoODow OjA6MCk6IFNDU0kgc3RhdHVzOiBDaGVjayBDb25kaXRpb24KKGNkMDphaGNpY2g4OjA6MDow KTogU0NTSSBzZW5zZTogTk9UIFJFQURZIGFzYzozYSwxIChNZWRpdW0gbm90IHByZXNlbnQg LSB0cmF5IGNsb3NlZCkKKGNkMDphaGNpY2g4OjA6MDowKTogRXJyb3IgNiwgVW5yZXRyeWFi bGUgZXJyb3IKCmFkYTI6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3Jz OiAxNkggNjNTL1QgMTYzODNDKQphZGEzIGF0IHNpaXNjaDAgYnVzIDAgc2NidXMwIHRhcmdl dCAzIGx1biAwCmFkYTM6IDxTVDMyMDAwNTQyQVMgQ0MzMj4gQVRBLTggU0FUQSAyLnggZGV2 aWNlCmFkYTM6IFNlcmlhbCBOdW1iZXIgNVhXMDFQMFgKYWRhMzogMzAwLjAwME1CL3MgdHJh bnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTM6IENvbW1hbmQg UXVldWVpbmcgZW5hYmxlZAphZGEzOiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUg c2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhNCBhdCBzaWlzY2gxIGJ1cyAwIHNjYnVz MSB0YXJnZXQgMCBsdW4gMAphZGE0OiA8U1QzMjAwMDU0MkFTIENDMzQ+IEFUQS04IFNBVEEg Mi54IGRldmljZQphZGE0OiBTZXJpYWwgTnVtYmVyIDlYVzBCV1pOCmFkYTQ6IDMwMC4wMDBN Qi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGE0OiBD b21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhNDogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUx MiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTUgYXQgc2lpc2NoMSBidXMg MCBzY2J1czEgdGFyZ2V0IDEgbHVuIDAKYWRhNTogPFNUMzIwMDA1NDJBUyBDQzM0PiBBVEEt OCBTQVRBIDIueCBkZXZpY2UKYWRhNTogU2VyaWFsIE51bWJlciA5WFcwNzYyNwphZGE1OiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRlcykK YWRhNTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTU6IDE5MDc3MjlNQiAoMzkwNzAy OTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGE2IGF0IHNpaXNj aDEgYnVzIDAgc2NidXMxIHRhcmdldCAyIGx1biAwCmFkYTY6IDxTVDMyMDAwNTQyQVMgQ0Mz ND4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFkYTY6IFNlcmlhbCBOdW1iZXIgOVhXMEFRSzYK YWRhNjogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTky Ynl0ZXMpCmFkYTY6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE2OiAxOTA3NzI5TUIg KDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhNyBh dCBzaWlzY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMyBsdW4gMAphZGE3OiA8U1QzMjAwMDU0 MkFTIENDMzQ+IEFUQS04IFNBVEEgMi54IGRldmljZQphZGE3OiBTZXJpYWwgTnVtYmVyIDlY VzBCTTI2CmFkYTc6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQ SU8gODE5MmJ5dGVzKQphZGE3OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhNzogMTkw NzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0Mp CmFkYTggYXQgYWhjaWNoNiBidXMgMCBzY2J1czEyIHRhcmdldCAwIGx1biAwCmFkYTg6IDxX REMgV0QyMDAyRllQUy0wMVUxQjAgMDQuMDVHMDQ+IEFUQS04IFNBVEEgMi54IGRldmljZQph ZGE4OiBTZXJpYWwgTnVtYmVyIFdELVdDQVZZMDg2NDIyNgphZGE4OiAzMDAuMDAwTUIvcyB0 cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhODogQ29tbWFu ZCBRdWV1ZWluZyBlbmFibGVkCmFkYTg6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0 ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGE5IGF0IGFoY2ljaDcgYnVzIDAgc2Ni dXMxMyB0YXJnZXQgMCBsdW4gMAphZGE5OiA8U1QzMjAwMDU0MkFTIENDMzI+IEFUQS04IFNB VEEgMi54IGRldmljZQphZGE5OiBTZXJpYWwgTnVtYmVyIDZYVzAzS1JUCmFkYTk6IDMwMC4w MDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGE5 OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhOTogMTkwNzcyOU1CICgzOTA3MDI5MTY4 IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCnBhc3MwIGF0IHNpaXNjaDAg YnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCnBhc3MwOiA8U1QzMjAwMDU0MkFTIENDMzQ+ IEFUQS04IFNBVEEgMi54IGRldmljZQpwYXNzMDogU2VyaWFsIE51bWJlciA5WFcwN1pYMgpw YXNzMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTky Ynl0ZXMpCnBhc3MwOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKcGFzczEgYXQgc2lpc2No MCBidXMgMCBzY2J1czAgdGFyZ2V0IDEgbHVuIDAKcGFzczE6IDxTVDMyMDAwNTQyQVMgQ0Mz Mj4gQVRBLTggU0FUQSAyLnggZGV2aWNlCnBhc3MxOiBTZXJpYWwgTnVtYmVyIDVYVzAyUDBE CnBhc3MxOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgx OTJieXRlcykKcGFzczE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApwYXNzMiBhdCBzaWlz Y2gwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMiBsdW4gMApwYXNzMjogPFNUMzIwMDA1NDJBUyBD QzMyPiBBVEEtOCBTQVRBIDIueCBkZXZpY2UKcGFzczI6IFNlcmlhbCBOdW1iZXIgNVhXMDFQ SDYKcGFzczI6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8g ODE5MmJ5dGVzKQpwYXNzMjogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCnBhc3MzIGF0IHNp aXNjaDAgYnVzIDAgc2NidXMwIHRhcmdldCAzIGx1biAwCnBhc3MzOiA8U1QzMjAwMDU0MkFT IENDMzI+IEFUQS04IFNBVEEgMi54IGRldmljZQpwYXNzMzogU2VyaWFsIE51bWJlciA1WFcw MVAwWApwYXNzMzogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJ TyA4MTkyYnl0ZXMpCnBhc3MzOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKcGFzczQgYXQg c2lpc2NoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDE1IGx1biAwCnBhc3M0OiA8UG9ydCBNdWx0 aXBsaWVyIDM3MjYxMDk1IDE3MDY+IEFUQS0wIGRldmljZQpwYXNzNDogMzAwLjAwME1CL3Mg dHJhbnNmZXJzIChTQVRBIDIueCwgTk9ORSwgUElPIDgxOTJieXRlcykKcGFzczUgYXQgc2lp c2NoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKcGFzczU6IDxTVDMyMDAwNTQyQVMg Q0MzND4gQVRBLTggU0FUQSAyLnggZGV2aWNlCnBhc3M1OiBTZXJpYWwgTnVtYmVyIDlYVzBC V1pOCnBhc3M1OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElP IDgxOTJieXRlcykKcGFzczU6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApwYXNzNiBhdCBz aWlzY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMSBsdW4gMApwYXNzNjogPFNUMzIwMDA1NDJB UyBDQzM0PiBBVEEtOCBTQVRBIDIueCBkZXZpY2UKcGFzczY6IFNlcmlhbCBOdW1iZXIgOVhX MDc2MjcKcGFzczY6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQ SU8gODE5MmJ5dGVzKQpwYXNzNjogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCnBhc3M3IGF0 IHNpaXNjaDEgYnVzIDAgc2NidXMxIHRhcmdldCAyIGx1biAwCnBhc3M3OiA8U1QzMjAwMDU0 MkFTIENDMzQ+IEFUQS04IFNBVEEgMi54IGRldmljZQpwYXNzNzogU2VyaWFsIE51bWJlciA5 WFcwQVFLNgpwYXNzNzogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYs IFBJTyA4MTkyYnl0ZXMpCnBhc3M3OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKcGFzczgg YXQgc2lpc2NoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDMgbHVuIDAKcGFzczg6IDxTVDMyMDAw NTQyQVMgQ0MzND4gQVRBLTggU0FUQSAyLnggZGV2aWNlCnBhc3M4OiBTZXJpYWwgTnVtYmVy IDlYVzBCTTI2CnBhc3M4OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1B NiwgUElPIDgxOTJieXRlcykKcGFzczg6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApwYXNz OSBhdCBzaWlzY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMTUgbHVuIDAKcGFzczk6IDxQb3J0 IE11bHRpcGxpZXIgMzcyNjEwOTUgMTcwNj4gQVRBLTAgZGV2aWNlCnBhc3M5OiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBOT05FLCBQSU8gODE5MmJ5dGVzKQpwYXNzMTAg YXQgbXB0MCBidXMgMCBzY2J1czggdGFyZ2V0IDEyIGx1biAwCnBhc3MxMDogPEFUQSBTVDMy MDAwNTQyQVMgQ0MzMj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApwYXNz MTA6IFNlcmlhbCBOdW1iZXIgICAgICAgICAgICAgNVhXMDFUWEoKcGFzczEwOiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMKcGFzczEwOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKcGFzczEx IGF0IG1wdDAgYnVzIDAgc2NidXM4IHRhcmdldCAxMyBsdW4gMApwYXNzMTE6IDxBVEEgU1Qz MjAwMDU0MkFTIENDMzI+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKcGFz czExOiBTZXJpYWwgTnVtYmVyICAgICAgICAgICAgIDVYVzAxUjlCCnBhc3MxMTogMzAwLjAw ME1CL3MgdHJhbnNmZXJzCnBhc3MxMTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCnBhc3Mx MiBhdCBtcHQwIGJ1cyAwIHNjYnVzOCB0YXJnZXQgMTQgbHVuIDAKcGFzczEyOiA8QVRBIFNU MzIwMDA1NDJBUyBDQzMyPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCnBh c3MxMjogU2VyaWFsIE51bWJlciAgICAgICAgICAgICA1WFcwMVNZRgpwYXNzMTI6IDMwMC4w MDBNQi9zIHRyYW5zZmVycwpwYXNzMTI6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApwYXNz MTMgYXQgbXB0MCBidXMgMCBzY2J1czggdGFyZ2V0IDE1IGx1biAwCnBhc3MxMzogPEFUQSBT VDMyMDAwNTQyQVMgQ0MzMj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApw YXNzMTM6IFNlcmlhbCBOdW1iZXIgICAgICAgICAgICAgNVhXMDBGTVAKcGFzczEzOiAzMDAu MDAwTUIvcyB0cmFuc2ZlcnMKcGFzczEzOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKcGFz czE0IGF0IG1wdDAgYnVzIDAgc2NidXM4IHRhcmdldCAxNiBsdW4gMApwYXNzMTQ6IDxBVEEg U1QzMjAwMDU0MkFTIENDMzI+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAK cGFzczE0OiBTZXJpYWwgTnVtYmVyICAgICAgICAgICAgIDZYVzAwVjlFCnBhc3MxNDogMzAw LjAwME1CL3MgdHJhbnNmZXJzCnBhc3MxNDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCnBh c3MxNSBhdCBtcHQwIGJ1cyAwIHNjYnVzOCB0YXJnZXQgMTcgbHVuIDAKcGFzczE1OiA8QVRB IFNUMzIwMDA1NDJBUyBDQzMyPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2Ug CnBhc3MxNTogU2VyaWFsIE51bWJlciAgICAgICAgICAgICA2WFcwMzdEWQpwYXNzMTU6IDMw MC4wMDBNQi9zIHRyYW5zZmVycwpwYXNzMTU6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApw YXNzMTYgYXQgbXB0MCBidXMgMCBzY2J1czggdGFyZ2V0IDE4IGx1biAwCnBhc3MxNjogPEFU QSBTVDMyMDAwNTQyQVMgQ0MzMj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNl IApwYXNzMTY6IFNlcmlhbCBOdW1iZXIgICAgICAgICAgICAgNVhXMDJNWFkKcGFzczE2OiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMKcGFzczE2OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQK cGFzczE3IGF0IG1wdDAgYnVzIDAgc2NidXM4IHRhcmdldCAxOSBsdW4gMApwYXNzMTc6IDxB VEEgU1QzMjAwMDU0MkFTIENDMzI+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmlj ZSAKcGFzczE3OiBTZXJpYWwgTnVtYmVyICAgICAgICAgICAgIDVYVzAyTjdYCnBhc3MxNzog MzAwLjAwME1CL3MgdHJhbnNmZXJzCnBhc3MxNzogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVk CnBhc3MxOCBhdCBhaGNpY2g2IGJ1cyAwIHNjYnVzMTIgdGFyZ2V0IDAgbHVuIDAKcGFzczE4 OiA8V0RDIFdEMjAwMkZZUFMtMDFVMUIwIDA0LjA1RzA0PiBBVEEtOCBTQVRBIDIueCBkZXZp Y2UKcGFzczE4OiBTZXJpYWwgTnVtYmVyIFdELVdDQVZZMDg2NDIyNgpwYXNzMTg6IDMwMC4w MDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQpwYXNz MTg6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApwYXNzMTkgYXQgYWhjaWNoNyBidXMgMCBz Y2J1czEzIHRhcmdldCAwIGx1biAwCnBhc3MxOTogPFNUMzIwMDA1NDJBUyBDQzMyPiBBVEEt OCBTQVRBIDIueCBkZXZpY2UKcGFzczE5OiBTZXJpYWwgTnVtYmVyIDZYVzAzS1JUCnBhc3Mx OTogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0 ZXMpCnBhc3MxOTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCnBhc3MyMCBhdCBhaGNpY2g4 IGJ1cyAwIHNjYnVzMTQgdGFyZ2V0IDAgbHVuIDAKcGFzczIwOiA8T3B0aWFyYyBEVkQgUlcg QUQtNzI0MVMgMS4wMz4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlIApwYXNzMjA6 IDE1MC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAxLngsIFVETUE1LCBBVEFQSSAxMmJ5dGVz LCBQSU8gODE5MmJ5dGVzKQpwYXNzMjEgYXQgYWhjaWNoOSBidXMgMCBzY2J1czE1IHRhcmdl dCAwIGx1biAwCnBhc3MyMTogPEhMLURULVNUIEJELVJFICBHR1ctSDIwTCBZTDA1PiBSZW1v dmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgCnBhc3MyMTogU2VyaWFsIE51bWJlciBLMTc5 MUdBMDA1NApwYXNzMjE6IDE1MC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAxLngsIFVETUE2 LCBBVEFQSSAxMmJ5dGVzLCBQSU8gODE5MmJ5dGVzKQpBVEEgUHNldWRvUkFJRCBsb2FkZWQK bGxhYWxwbGlwbGFhbGlhcGFwcGlwY2ljY2lpYzVjMjQ6OjY6N2MgIDpDOkMzIE0gIE06Q0ND IE1NQ0NNTUNDQ0lJSUkgICBDIENJdSB1dW5ubm1tSW1hYXUgYXVuc3Nuc211a2tta2VlYWVk YWRuc2RzbWtrZWRlYWRza2VkCgoKCgoKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhCmNwdTEg QVA6CiAgICAgSUQ6IDB4MDEwMDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAw MDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAw NDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBl ZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMDAwZjAgcG1jOiAweDAwMDEwNDAwCiAg IGNtY2k6IDB4MDAwMTAwZjIKU01QOiBBUCBDUFUgIzcgTGF1bmNoZWQhCmNwdTcgQVA6CiAg ICAgSUQ6IDB4MDcwMDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERG UjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQ UjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVy bTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMDAwZjAgcG1jOiAweDAwMDEwNDAwCiAgIGNtY2k6 IDB4MDAwMDAwZjIKU01QOiBBUCBDUFUgIzUgTGF1bmNoZWQhCmNwdTUgQVA6CiAgICAgSUQ6 IDB4MDUwMDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhm ZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgw MDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgw MDAxMDAwMCBlcnI6IDB4MDAwMDAwZjAgcG1jOiAweDAwMDEwNDAwCiAgIGNtY2k6IDB4MDAw MDAwZjIKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhCmNwdTMgQVA6CiAgICAgSUQ6IDB4MDMw MDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZm ZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAw MCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAw MCBlcnI6IDB4MDAwMDAwZjAgcG1jOiAweDAwMDEwNDAwCiAgIGNtY2k6IDB4MDAwMDAwZjIK U01QOiBBUCBDUFUgIzYgTGF1bmNoZWQhCmNwdTYgQVA6CiAgICAgSUQ6IDB4MDYwMDAwMDAg ICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxp bnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6 IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6 IDB4MDAwMDAwZjAgcG1jOiAweDAwMDEwNDAwCiAgIGNtY2k6IDB4MDAwMDAwZjIKU01QOiBB UCBDUFUgIzQgTGF1bmNoZWQhCmNwdTQgQVA6CiAgICAgSUQ6IDB4MDQwMDAwMDAgICBWRVI6 IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAw eDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAw MDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAw MDAwZjAgcG1jOiAweDAwMDEwNDAwCiAgIGNtY2k6IDB4MDAwMDAwZjIKU01QOiBBUCBDUFUg IzIgTGF1bmNoZWQhCmNwdTIgQVA6CiAgICAgSUQ6IDB4MDIwMDAwMDAgICBWRVI6IDB4MDAw NjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEw NzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYK ICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMDAwZjAg cG1jOiAweDAwMDEwNDAwCiAgIGNtY2k6IDB4MDAwMDAwZjIKaW9hcGljMDogcm91dGluZyBp bnRwaW4gMSAoSVNBIElSUSAxKSB0byBsYXBpYyAxIHZlY3RvciA0OAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiA0IChJU0EgSVJRIDQpIHRvIGxhcGljIDIgdmVjdG9yIDQ4CmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDYgKElTQSBJUlEgNikgdG8gbGFwaWMgMyB2ZWN0b3IgNDgKaW9h cGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBsYXBpYyA0IHZlY3RvciA0 OAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNiAoUENJIElSUSAxNikgdG8gbGFwaWMgNSB2 ZWN0b3IgNDgKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTcgKFBDSSBJUlEgMTcpIHRvIGxh cGljIDYgdmVjdG9yIDQ4CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE4IChQQ0kgSVJRIDE4 KSB0byBsYXBpYyA3IHZlY3RvciA0OAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMSAoUENJ IElSUSAyMSkgdG8gbGFwaWMgMSB2ZWN0b3IgNDkKaW9hcGljMDogcm91dGluZyBpbnRwaW4g MjMgKFBDSSBJUlEgMjMpIHRvIGxhcGljIDIgdmVjdG9yIDQ5Cm1zaTogQXNzaWduaW5nIE1T SSBJUlEgMjU2IHRvIGxvY2FsIEFQSUMgMyB2ZWN0b3IgNDkKbXNpOiBBc3NpZ25pbmcgTVNJ IElSUSAyNTcgdG8gbG9jYWwgQVBJQyA0IHZlY3RvciA0OQptc2k6IEFzc2lnbmluZyBNU0kg SVJRIDI1OCB0byBsb2NhbCBBUElDIDUgdmVjdG9yIDQ5Cm1zaTogQXNzaWduaW5nIE1TSSBJ UlEgMjU5IHRvIGxvY2FsIEFQSUMgNiB2ZWN0b3IgNDkKbXNpOiBBc3NpZ25pbmcgTVNJLVgg SVJRIDI2MSB0byBsb2NhbCBBUElDIDEgdmVjdG9yIDUwCm1zaTogQXNzaWduaW5nIE1TSS1Y IElSUSAyNjIgdG8gbG9jYWwgQVBJQyAyIHZlY3RvciA1MAptc2k6IEFzc2lnbmluZyBNU0kt WCBJUlEgMjYzIHRvIGxvY2FsIEFQSUMgMyB2ZWN0b3IgNTAKbXNpOiBBc3NpZ25pbmcgTVNJ LVggSVJRIDI2NCB0byBsb2NhbCBBUElDIDQgdmVjdG9yIDUwCm1zaTogQXNzaWduaW5nIE1T SS1YIElSUSAyNjUgdG8gbG9jYWwgQVBJQyA1IHZlY3RvciA1MAptc2k6IEFzc2lnbmluZyBN U0ktWCBJUlEgMjY2IHRvIGxvY2FsIEFQSUMgNiB2ZWN0b3IgNTAKbXNpOiBBc3NpZ25pbmcg TVNJLVggSVJRIDI2NyB0byBsb2NhbCBBUElDIDcgdmVjdG9yIDQ5CldBUk5JTkc6IFdJVE5F U1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpHRU9NOiBu ZXcgZGlzayBkYTQKR0VPTTogbmV3IGRpc2sgZGE1CkdFT006IG5ldyBkaXNrIGRhNgpHRU9N OiBuZXcgZGlzayBkYTcKR0VPTTogbmV3IGRpc2sgYWRhMApHRU9NOiBuZXcgZGlzayBhZGEx CkdFT006IG5ldyBkaXNrIGFkYTIKR0VPTTogbmV3IGRpc2sgYWRhMwpHRU9NOiBuZXcgZGlz ayBhZGE0CkdFT006IG5ldyBkaXNrIGFkYTUKR0VPTTogbmV3IGRpc2sgYWRhNgpHRU9NOiBu ZXcgZGlzayBhZGE3CkdFT006IG5ldyBkaXNrIGFkYTgKR0VPTTogbmV3IGRpc2sgYWRhOQpH RU9NX01JUlJPUjogRGV2aWNlIG1pcnJvci9QNTVVRDYtcm9vdCBsYXVuY2hlZCAoMS8xKS4K R0VPTV9NSVJST1I6IERldmljZSBtaXJyb3IvUDU1VUQ2LXN3YXAgbGF1bmNoZWQgKDEvMSku CkdFT01fTUlSUk9SOiBEZXZpY2UgbWlycm9yL1A1NVVENi10bXAgbGF1bmNoZWQgKDEvMSku CkdFT01fTUlSUk9SOiBEZXZpY2UgbWlycm9yL1A1NVVENi12YXIgbGF1bmNoZWQgKDEvMSku CkdFT01fTUlSUk9SOiBEZXZpY2UgbWlycm9yL1A1NVVENi11c3IgbGF1bmNoZWQgKDEvMSku ClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOnVmcy9QNTVVRDZ4Uk9PVApXQVJOSU5H OiAvIHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRlZApjdF90b190cyhbMjAxMC0xMC0wNSAy Mjo1MTo1Ml0pID0gMTI4NjMxOTExMi4wMDAwMDAwMDAKc3RhcnRfaW5pdDogdHJ5aW5nIC9z YmluL2luaXQKPDExOD5TZXR0aW5nIGhvc3R1dWlkOiAwMDAwMDAwMC0wMDAwLTAwMDAtMDAw MC0wMDI0MWQ3ZjMxYmUuCjwxMTg+U2V0dGluZyBob3N0aWQ6IDB4ZTVmYmEyYjcuCjwxMTg+ RW50cm9weSBoYXJ2ZXN0aW5nOgo8MTE4PiBpbnRlcnJ1cHRzCjwxMTg+IGV0aGVybmV0Cjwx MTg+IHBvaW50X3RvX3BvaW50CjwxMTg+IGtpY2tzdGFydAo8MTE4Pi4KPDExOD5TdGFydGlu ZyBmaWxlIHN5c3RlbSBjaGVja3M6CjwxMTg+L2Rldi91ZnMvUDU1VUQ2eFJPT1Q6IElOQ09S UkVDVCBCTE9DSyBDT1VOVCBJPTcxODc5ICgxNiBzaG91bGQgYmUgMCkgKENPUlJFQ1RFRCkK PDExOD4vZGV2L3Vmcy9QNTVVRDZ4Uk9PVDogSU5DT1JSRUNUIEJMT0NLIENPVU5UIEk9NjU5 NDk0ICg0IHNob3VsZCBiZSAwKSAoQ09SUkVDVEVEKQo8MTE4Pi9kZXYvdWZzL1A1NVVENnhS T09UOiBJTkNPUlJFQ1QgQkxPQ0sgQ09VTlQgST03NTM2NjQgKDQgc2hvdWxkIGJlIDApIChD T1JSRUNURUQpCjwxMTg+L2Rldi91ZnMvUDU1VUQ2eFJPT1Q6IExJTksgQ09VTlQgRklMRSBJ PTcxODc4ICBPV05FUj1yb290IE1PREU9MTAwNjQ0CjwxMTg+L2Rldi91ZnMvUDU1VUQ2eFJP T1Q6IFNJWkU9Nzc5NiBNVElNRT1PY3QgIDUgMjI6NDcgMjAxMCAgQ09VTlQgMiBTSE9VTEQg QkUgMSAoQURKVVNURUQpCjwxMTg+L2Rldi91ZnMvUDU1VUQ2eFJPT1Q6IFVOUkVGIEZJTEUg ST03MTg3OSAgT1dORVI9cm9vdCBNT0RFPTEwMDY0NAo8MTE4Pi9kZXYvdWZzL1A1NVVENnhS T09UOiBTSVpFPTAgTVRJTUU9T2N0ICA1IDIyOjQ3IDIwMTAgIChDTEVBUkVEKQo8MTE4Pi9k ZXYvdWZzL1A1NVVENnhST09UOiBVTlJFRiBGSUxFIEk9NjU5NDk0ICBPV05FUj1yb290IE1P REU9MTAwNjQ0CjwxMTg+L2Rldi91ZnMvUDU1VUQ2eFJPT1Q6IFNJWkU9MCBNVElNRT1PY3Qg IDUgMjI6NDcgMjAxMCAgKENMRUFSRUQpCjwxMTg+L2Rldi91ZnMvUDU1VUQ2eFJPT1Q6IFpF Uk8gTEVOR1RIIERJUiBJPTc1MzY2NCAgT1dORVI9cm9vdCBNT0RFPTQwNzU1CjwxMTg+L2Rl di91ZnMvUDU1VUQ2eFJPT1Q6IFNJWkU9MCBNVElNRT1PY3QgIDUgMjI6NDcgMjAxMCAgKENM RUFSRUQpCjwxMTg+L2Rldi91ZnMvUDU1VUQ2eFJPT1Q6IFNVTU1BUlkgSU5GT1JNQVRJT04g QkFEIChTQUxWQUdFRCkKPDExOD4vZGV2L3Vmcy9QNTVVRDZ4Uk9PVDogQkxLKFMpIE1JU1NJ TkcgSU4gQklUIE1BUFMgKFNBTFZBR0VEKQo8MTE4Pi9kZXYvdWZzL1A1NVVENnhST09UOiA1 NDgzIGZpbGVzLCA1NzQyNTUgdXNlZCwgMzQ4NjgwNyBmcmVlICg5OTkgZnJhZ3MsIDQzNTcy NiBibG9ja3MsIDAuMCUgZnJhZ21lbnRhdGlvbikKPDExOD4vZGV2L3Vmcy9QNTVVRDZ4VE1Q OiBERUZFUiBGT1IgQkFDS0dST1VORCBDSEVDS0lORwo8MTE4Pi9kZXYvdWZzL1A1NVVENnhV U1I6IERFRkVSIEZPUiBCQUNLR1JPVU5EIENIRUNLSU5HCjwxMTg+L2Rldi91ZnMvUDU1VUQ2 eFZBUjogREVGRVIgRk9SIEJBQ0tHUk9VTkQgQ0hFQ0tJTkcKPDExOD5Nb3VudGluZyBsb2Nh bCBmaWxlIHN5c3RlbXM6CldBUk5JTkc6IC90bXAgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3Vu dGVkCldBUk5JTkc6IC91c3Igd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6 IC92YXIgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCjwxMTg+Lgo8MTE4PlNldHRpbmcg aG9zdG5hbWU6IGtyYWtlbi5ob3VzZW5ldC5qcnYKPDExOD4uCjwxMTg+U3RhcnRpbmcgTmV0 d29yazogbG8wIHJlMCByZTEgZndlMCBmd2lwMC4KPDExOD5sbzA6IGZsYWdzPTgwNDk8VVAs TE9PUEJBQ0ssUlVOTklORyxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNjM4NAo8MTE4Pglv cHRpb25zPTM8UlhDU1VNLFRYQ1NVTT4KPDExOD4JaW5ldCAxMjcuMC4wLjEgbmV0bWFzayAw eGZmMDAwMDAwIAo8MTE4PglpbmV0NiA6OjEgcHJlZml4bGVuIDEyOCAKPDExOD4JaW5ldDYg ZmU4MDo6MSVsbzAgcHJlZml4bGVuIDY0IHNjb3BlaWQgMHg1IAo8MTE4PgluZDYgb3B0aW9u cz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FMPgo8MTE4PnJlMDogZmxhZ3M9ODg0MzxV UCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1 MDAKPDExOD4Jb3B0aW9ucz0zODliPFJYQ1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9IV1RB R0dJTkcsVkxBTl9IV0NTVU0sV09MX1VDQVNULFdPTF9NQ0FTVCxXT0xfTUFHSUM+CjwxMTg+ CWV0aGVyIDAwOjI0OjFkOjdmOjMxOmJjCjwxMTg+CW1lZGlhOiBFdGhlcm5ldCBhdXRvc2Vs ZWN0IChub25lKQo8MTE4PglzdGF0dXM6IG5vIGNhcnJpZXIKPDExOD5yZTE6IGZsYWdzPTg4 NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10 dSAxNTAwCjwxMTg+CW9wdGlvbnM9Mzg5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5f SFdUQUdHSU5HLFZMQU5fSFdDU1VNLFdPTF9VQ0FTVCxXT0xfTUNBU1QsV09MX01BR0lDPgo8 MTE4PglldGhlciAwMDoyNDoxZDo3ZjozMTpiZQo8MTE4PglpbmV0IDE5Mi4xNjguMy4yMyBu ZXRtYXNrIDB4ZmZmZmZmMDAgYnJvYWRjYXN0IDE5Mi4xNjguMy4yNTUKPDExOD4JaW5ldDYg ZmU4MDo6MjI0OjFkZmY6ZmU3ZjozMWJlJXJlMSBwcmVmaXhsZW4gNjQgdGVudGF0aXZlIHNj b3BlaWQgMHgyIAo8MTE4PgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQs QVVUT19MSU5LTE9DQUw+CjwxMTg+CW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0IChub25l KQo8MTE4PglzdGF0dXM6IG5vIGNhcnJpZXIKPDExOD5md2UwOiBmbGFncz04ODAyPEJST0FE Q0FTVCxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKPDExOD4Jb3B0aW9u cz04PFZMQU5fTVRVPgo8MTE4PglldGhlciAwMjo3YTpjYTowMDoyNDoxZAo8MTE4PgljaCAx IGRtYSAtMQo8MTE4PmZ3aXAwOiBmbGFncz04ODAyPEJST0FEQ0FTVCxTSU1QTEVYLE1VTFRJ Q0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKPDExOD4JbGxhZGRyIDAuN2EuY2EuN2YuMC4wLjI0 LjFkLmEuMi5mZi5mZS4wLjAuMC4wCjwxMTg+U3RhcnRpbmcgZGV2ZC4KPDExOD5TdGFydGlu ZyBOZXR3b3JrOiBmd2UwLgo8MTE4PmZ3ZTA6IGZsYWdzPTg4MDI8QlJPQURDQVNULFNJTVBM RVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4PglvcHRpb25zPTg8VkxBTl9N VFU+CjwxMTg+CWV0aGVyIDAyOjdhOmNhOjAwOjI0OjFkCjwxMTg+CWNoIDEgZG1hIC0xCjwx MTg+U3RhcnRpbmcgTmV0d29yazogZndpcDAuCjwxMTg+ZndpcDA6IGZsYWdzPTg4MDI8QlJP QURDQVNULFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4PglsbGFk ZHIgMC43YS5jYS43Zi4wLjAuMjQuMWQuYS4yLmZmLmZlLjAuMC4wLjAKPDExOD5hZGQgbmV0 IGRlZmF1bHQ6IGdhdGV3YXkgMTkyLjE2OC4zLjEKPDExOD5hZGQgbmV0IDo6ZmZmZjowLjAu MC4wOiBnYXRld2F5IDo6MQo8MTE4PmFkZCBuZXQgOjowLjAuMC4wOiBnYXRld2F5IDo6MQo8 MTE4PmFkZCBuZXQgZmU4MDo6OiBnYXRld2F5IDo6MQo8MTE4PmFkZCBuZXQgZmYwMjo6OiBn YXRld2F5IDo6MQo8MTE4Pk1vdW50aW5nIE5GUyBmaWxlIHN5c3RlbXM6CjwxMTg+Lgo8MTE4 PkVMRiBsZGNvbmZpZyBwYXRoOiAvbGliIC91c3IvbGliIC91c3IvbGliL2NvbXBhdCAvdXNy L2xvY2FsL2xpYgo8MTE4PjMyLWJpdCBjb21wYXRpYmlsaXR5IGxkY29uZmlnIHBhdGg6IC91 c3IvbGliMzIKPDExOD5DcmVhdGluZyBhbmQvb3IgdHJpbW1pbmcgbG9nIGZpbGVzCjwxMTg+ Lgo8MTE4PlN0YXJ0aW5nIHN5c2xvZ2QuCjwxMTg+Tm8gY29yZSBkdW1wcyBmb3VuZC4KPDEx OD5TdGFydGluZyBycGNiaW5kLgo8MTE4Pk5GUyBhY2Nlc3MgY2FjaGUgdGltZT02MAo8MTE4 PkNsZWFyaW5nIC90bXAgKFggcmVsYXRlZCkuCjwxMTg+U3RhcnRpbmcgc3RhdGQuCjwxMTg+ U3RhcnRpbmcgbG9ja2QuCjwxMTg+U3RhcnRpbmcgc21hcnRkLgo8MTE4PihwYXNzNDpzaWlz Y2gwOjA6MTU6MCk6IEFUQV9JREVOVElGWS4gQUNCOiBlYyAwMCAwMCAwMCAwMCA0MCAwMCAw MCAwMCAwMCAwMCAwMAo8MTE4PihwYXNzNDpzaWlzY2gwOjA6MTU6MCk6IENBTSBzdGF0dXM6 IEFUQSBTdGF0dXMgRXJyb3IKPDExOD4ocGFzczQ6c2lpc2NoMDowOjE1OjApOiBBVEEgc3Rh dHVzOiA1MSAoRFJEWSBTRVJWIEVSUiksIGVycm9yOiAwNCAoQUJSVCApCjwxMTg+KHBhc3M0 OnNpaXNjaDA6MDoxNTowKTogUkVTOiA1MSAwNCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MAo8MTE4PihwYXNzNDpzaWlzY2gwOjA6MTU6MCk6IEFUQVBJX0lERU5USUZZLiBBQ0I6IGEx IDAwIDAwIDAwIDAwIDQwIDAwIDAwIDAwIDAwIDAwIDAwCjwxMTg+KHBhc3M0OnNpaXNjaDA6 MDoxNTowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgo8MTE4PihwYXNzNDpzaWlz Y2gwOjA6MTU6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNFUlYgRVJSKSwgZXJyb3I6IDA0 IChBQlJUICkKPDExOD4ocGFzczQ6c2lpc2NoMDowOjE1OjApOiBSRVM6IDUxIDA0IDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwCjwxMTg+KHBhc3M5OnNpaXNjaDE6MDoxNTowKTogQVRB X0lERU5USUZZLiBBQ0I6IGVjIDAwIDAwIDAwIDAwIDQwIDAwIDAwIDAwIDAwIDAwIDAwCjwx MTg+KHBhc3M5OnNpaXNjaDE6MDoxNTowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJv cgo8MTE4PihwYXNzOTpzaWlzY2gxOjA6MTU6MCk6IEFUQSBzdGF0dXM6IDUxIChEUkRZIFNF UlYgRVJSKSwgZXJyb3I6IDA0IChBQlJUICkKPDExOD4ocGFzczk6c2lpc2NoMTowOjE1OjAp OiBSRVM6IDUxIDA0IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjwxMTg+KHBhc3M5OnNp aXNjaDE6MDoxNTowKTogQVRBUElfSURFTlRJRlkuIEFDQjogYTEgMDAgMDAgMDAgMDAgNDAg MDAgMDAgMDAgMDAgMDAgMDAKPDExOD4ocGFzczk6c2lpc2NoMTowOjE1OjApOiBDQU0gc3Rh dHVzOiBBVEEgU3RhdHVzIEVycm9yCjwxMTg+KHBhc3M5OnNpaXNjaDE6MDoxNTowKTogQVRB IHN0YXR1czogNTEgKERSRFkgU0VSViBFUlIpLCBlcnJvcjogMDQgKEFCUlQgKQo8MTE4Pihw YXNzOTpzaWlzY2gxOjA6MTU6MCk6IFJFUzogNTEgMDQgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAKPDExOD5VcGRhdGluZyBtb3RkOgo8MTE4Pi4KPDExOD5TdGFydGluZyBudHBkLgo8 MTE4PkNvbmZpZ3VyaW5nIHN5c2NvbnM6CjwxMTg+IGJsYW5rdGltZQo8MTE4Pi4KPDExOD5T dGFydGluZyBzc2hkLgo8MTE4PlN0YXJ0aW5nIGNyb24uCjwxMTg+U3RhcnRpbmcgaW5ldGQu CjwxMTg+U3RhcnRpbmcgYmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3MgaW4gNjAgc2Vj b25kcy4KPDExOD4KPDExOD5UdWUgT2N0ICA1IDIyOjUyOjEzIENEVCAyMDEwCnRzX3RvX2N0 KDEyODYzMTkxNDEuOTUzMTIwNTU4KSA9IFsyMDEwLTEwLTA1IDIyOjUyOjIxXQpsb2NrIG9y ZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmMDAzZDJiNzgwMCB1ZnMgKHVmcykgQCAvdXNy L3NyYy9zeXMvdWZzL2Zmcy9mZnNfc25hcHNob3QuYzo0MjMKIDJuZCAweGZmZmZmZjgwYTUz OWRhOTggYnVmd2FpdCAoYnVmd2FpdCkgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6 MjY1OQogM3JkIDB4ZmZmZmZmMDAwOGQ0NTMxMCB1ZnMgKHVmcykgQCAvdXNyL3NyYy9zeXMv dWZzL2Zmcy9mZnNfc25hcHNob3QuYzo1NDQKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3Ry YWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRu ZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNr b3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MDcKX19sb2NrbWdyX2FyZ3MoKSBh dCBfX2xvY2ttZ3JfYXJncysweGQ1MwpmZnNfbG9jaygpIGF0IGZmc19sb2NrKzB4OWMKVk9Q X0xPQ0sxX0FQVigpIGF0IFZPUF9MT0NLMV9BUFYrMHg5Ygpfdm5fbG9jaygpIGF0IF92bl9s b2NrKzB4NTcKZmZzX3NuYXBzaG90KCkgYXQgZmZzX3NuYXBzaG90KzB4MWMyNwpmZnNfbW91 bnQoKSBhdCBmZnNfbW91bnQrMHg1ZWIKdmZzX2Rvbm1vdW50KCkgYXQgdmZzX2Rvbm1vdW50 KzB4Y2RlCm5tb3VudCgpIGF0IG5tb3VudCsweDYzCnN5c2NhbGxlbnRlcigpIGF0IHN5c2Nh bGxlbnRlcisweDFhYQpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDRjClhmYXN0X3N5c2NhbGwo KSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTIKLS0tIHN5c2NhbGwgKDM3OCwgRnJlZUJTRCBFTEY2 NCwgbm1vdW50KSwgcmlwID0gMHg4MDA3YjllM2MsIHJzcCA9IDB4N2ZmZmZmZmZlOTU4LCBy YnAgPSAweDgwMGMwODAzMCAtLS0KbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZm ZjgwYTUzOWRhOTggYnVmd2FpdCAoYnVmd2FpdCkgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf YmlvLmM6MjY1OQogMm5kIDB4ZmZmZmZmMDAzZDhiODIzMCBzbmFwbGsgKHNuYXBsaykgQCAv dXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc25hcHNob3QuYzo4MTYKS0RCOiBzdGFjayBiYWNr dHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBl cisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3 aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MDcKX19sb2Nr bWdyX2FyZ3MoKSBhdCBfX2xvY2ttZ3JfYXJncysweGQ1MwpmZnNfbG9jaygpIGF0IGZmc19s b2NrKzB4OWMKVk9QX0xPQ0sxX0FQVigpIGF0IFZPUF9MT0NLMV9BUFYrMHg5Ygpfdm5fbG9j aygpIGF0IF92bl9sb2NrKzB4NTcKZmZzX3NuYXBzaG90KCkgYXQgZmZzX3NuYXBzaG90KzB4 MWIwMgpmZnNfbW91bnQoKSBhdCBmZnNfbW91bnQrMHg1ZWIKdmZzX2Rvbm1vdW50KCkgYXQg dmZzX2Rvbm1vdW50KzB4Y2RlCm5tb3VudCgpIGF0IG5tb3VudCsweDYzCnN5c2NhbGxlbnRl cigpIGF0IHN5c2NhbGxlbnRlcisweDFhYQpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDRjClhm YXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTIKLS0tIHN5c2NhbGwgKDM3OCwg RnJlZUJTRCBFTEY2NCwgbm1vdW50KSwgcmlwID0gMHg4MDA3YjllM2MsIHJzcCA9IDB4N2Zm ZmZmZmZlOTU4LCByYnAgPSAweDgwMGMwODAzMCAtLS0KbG9jayBvcmRlciByZXZlcnNhbDoK IDFzdCAweGZmZmZmZjAwM2Q4YjgyMzAgc25hcGxrIChzbmFwbGspIEAgL3Vzci9zcmMvc3lz L2tlcm4vdmZzX3Zub3BzLmM6MzAxCiAybmQgMHhmZmZmZmYwMDNkMmI3ODAwIHVmcyAodWZz KSBAIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zbmFwc2hvdC5jOjE2MTYKS0RCOiBzdGFj ayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZf d3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIr MHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MDcK X19sb2NrbWdyX2FyZ3MoKSBhdCBfX2xvY2ttZ3JfYXJncysweGQ1MwpmZnNfc25hcHJlbW92 ZSgpIGF0IGZmc19zbmFwcmVtb3ZlKzB4ZTcKZmZzX3RydW5jYXRlKCkgYXQgZmZzX3RydW5j YXRlKzB4NjM1CnVmc19pbmFjdGl2ZSgpIGF0IHVmc19pbmFjdGl2ZSsweDI4NQpWT1BfSU5B Q1RJVkVfQVBWKCkgYXQgVk9QX0lOQUNUSVZFX0FQVisweGI1CnZpbmFjdGl2ZSgpIGF0IHZp bmFjdGl2ZSsweDkwCnZwdXR4KCkgYXQgdnB1dHgrMHgyZGMKdm5fY2xvc2UoKSBhdCB2bl9j bG9zZSsweDExOAp2bl9jbG9zZWZpbGUoKSBhdCB2bl9jbG9zZWZpbGUrMHg1YQpfZmRyb3Ao KSBhdCBfZmRyb3ArMHgyMwpjbG9zZWYoKSBhdCBjbG9zZWYrMHg1YgprZXJuX2Nsb3NlKCkg YXQga2Vybl9jbG9zZSsweDExMApzeXNjYWxsZW50ZXIoKSBhdCBzeXNjYWxsZW50ZXIrMHgx YWEKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHg0YwpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rf c3lzY2FsbCsweGUyCi0tLSBzeXNjYWxsICg2LCBGcmVlQlNEIEVMRjY0LCBjbG9zZSksIHJp cCA9IDB4ODAwODVhNzljLCByc3AgPSAweDdmZmZmZmZmZTk1OCwgcmJwID0gMCAtLS0KY2Fs Y3J1OiBydW50aW1lIHdlbnQgYmFja3dhcmRzIGZyb20gNDk5IHVzZWMgdG8gNDg2IHVzZWMg Zm9yIHBpZCAxNTY1IChpbmV0ZCkKY2FsY3J1OiBydW50aW1lIHdlbnQgYmFja3dhcmRzIGZy b20gMTIzMSB1c2VjIHRvIDExOTggdXNlYyBmb3IgcGlkIDE1MjYgKHNlbmRtYWlsKQpjYWxj cnU6IHJ1bnRpbWUgd2VudCBiYWNrd2FyZHMgZnJvbSA5ODcgdXNlYyB0byA5NjEgdXNlYyBm b3IgcGlkIDE1MjYgKHNlbmRtYWlsKQpjYWxjcnU6IHJ1bnRpbWUgd2VudCBiYWNrd2FyZHMg ZnJvbSAxMDI1IHVzZWMgdG8gOTk3IHVzZWMgZm9yIHBpZCAxNTIwIChzZW5kbWFpbCkKY2Fs Y3J1OiBydW50aW1lIHdlbnQgYmFja3dhcmRzIGZyb20gOTQxNSB1c2VjIHRvIDkxNjQgdXNl YyBmb3IgcGlkIDEzNjcgKHNtYXJ0ZCkKY2FsY3J1OiBydW50aW1lIHdlbnQgYmFja3dhcmRz IGZyb20gODUzMiB1c2VjIHRvIDgzNjMgdXNlYyBmb3IgcGlkIDk3MSAoZGV2ZCkKY2FsY3J1 OiBydW50aW1lIHdlbnQgYmFja3dhcmRzIGZyb20gMTA0ODAgdXNlYyB0byAxMDIwMSB1c2Vj IGZvciBwaWQgOTcxIChkZXZkKQpjYWxjcnU6IHJ1bnRpbWUgd2VudCBiYWNrd2FyZHMgZnJv bSA1MDcgdXNlYyB0byA0OTQgdXNlYyBmb3IgcGlkIDEyNiAoYWRqa2VybnR6KQpjYWxjcnU6 IHJ1bnRpbWUgd2VudCBiYWNrd2FyZHMgZnJvbSA1NTAgdXNlYyB0byA1MzYgdXNlYyBmb3Ig cGlkIDI1IChnX21pcnJvciBQNTVVRDYtc3dhKQpjYWxjcnU6IHJ1bnRpbWUgd2VudCBiYWNr d2FyZHMgZnJvbSAxOTYwNTc0IHVzZWMgdG8gMTkxNTkwMSB1c2VjIGZvciBwaWQgMSAoaW5p dCkKdmRldl9nZW9tX29wZW5fYnlfcGF0aDozODRbMV06IEZvdW5kIHByb3ZpZGVyIGJ5IG5h bWUgL2Rldi9hZGEwLgp2ZGV2X2dlb21fYXR0YWNoOjk1WzFdOiBBdHRhY2hpbmcgdG8gYWRh MC4KdmRldl9nZW9tX2F0dGFjaDoxMTZbMV06IENyZWF0ZWQgZ2VvbSBhbmQgY29uc3VtZXIg Zm9yIGFkYTAuCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjM5WzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBhZGEwLi4uCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjczWzFdOiBndWlkIGZvciBhZGEwIGlz IDExODYxOTI0NjgxODIwMzQxNDQzCnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6Mzk4WzFdOiBn dWlkIG1hdGNoIGZvciBwcm92aWRlciAvZGV2L2FkYTAuCnZkZXZfZ2VvbV9vcGVuX2J5X3Bh dGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBieSBuYW1lIC9kZXYvYWRhMS4KdmRldl9nZW9t X2F0dGFjaDo5NVsxXTogQXR0YWNoaW5nIHRvIGFkYTEuCnZkZXZfZ2VvbV9hdHRhY2g6MTM2 WzFdOiBDcmVhdGVkIGNvbnN1bWVyIGZvciBhZGExLgp2ZGV2X2dlb21fcmVhZF9ndWlkOjIz OVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhMS4uLgp2ZGV2X2dlb21fcmVhZF9ndWlkOjI3 M1sxXTogZ3VpZCBmb3IgYWRhMSBpcyA0MjIyMDcwODM1MjQ2MDkwNTc5CnZkZXZfZ2VvbV9v cGVuX2J5X3BhdGg6Mzk4WzFdOiBndWlkIG1hdGNoIGZvciBwcm92aWRlciAvZGV2L2FkYTEu CnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBieSBuYW1l IC9kZXYvYWRhMi4KdmRldl9nZW9tX2F0dGFjaDo5NVsxXTogQXR0YWNoaW5nIHRvIGFkYTIu CnZkZXZfZ2VvbV9hdHRhY2g6MTM2WzFdOiBDcmVhdGVkIGNvbnN1bWVyIGZvciBhZGEyLgp2 ZGV2X2dlb21fcmVhZF9ndWlkOjIzOVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhMi4uLgp2 ZGV2X2dlb21fcmVhZF9ndWlkOjI3M1sxXTogZ3VpZCBmb3IgYWRhMiBpcyA2ODc5NzA3NTI3 OTgyMTQxNTAxCnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6Mzk4WzFdOiBndWlkIG1hdGNoIGZv ciBwcm92aWRlciAvZGV2L2FkYTIuCmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAxc3QgMHhmZmZm ZmYwMTJlMzZjNDMwIGRiLT5kYl9tdHggKGRiLT5kYl9tdHgpIEAgL3Vzci9zcmMvc3lzL21v ZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2Zz L3pmcy9kYnVmLmM6MjAwOQogMm5kIDB4ZmZmZmZmMDEyZTM3NjUxMCBkbi0+ZG5fbXR4IChk bi0+ZG5fbXR4KSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRy aWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZG5vZGUuYzoxMTc0CktEQjogc3Rh Y2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxm X3dyYXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2Vy KzB4MmUKd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODA3 Cl9zeF94bG9jaygpIGF0IF9zeF94bG9jaysweDU1CmRub2RlX3JlbGUoKSBhdCBkbm9kZV9y ZWxlKzB4NGUKZHNsX2RlYWRsaXN0X2Nsb3NlKCkgYXQgZHNsX2RlYWRsaXN0X2Nsb3NlKzB4 NDcKZHNsX2RhdGFzZXRfZXZpY3QoKSBhdCBkc2xfZGF0YXNldF9ldmljdCsweDdkCmRidWZf ZXZpY3RfdXNlcigpIGF0IGRidWZfZXZpY3RfdXNlcisweDU1CmRidWZfcmVsZV9hbmRfdW5s b2NrKCkgYXQgZGJ1Zl9yZWxlX2FuZF91bmxvY2srMHgxNTQKZHNsX3Bvb2xfb3BlbigpIGF0 IGRzbF9wb29sX29wZW4rMHgxYjUKc3BhX2xvYWQoKSBhdCBzcGFfbG9hZCsweDU0ZgpzcGFf bG9hZF9iZXN0KCkgYXQgc3BhX2xvYWRfYmVzdCsweDUyCnNwYV9vcGVuX2NvbW1vbigpIGF0 IHNwYV9vcGVuX2NvbW1vbisweDE0YQpzcGFfZ2V0X3N0YXRzKCkgYXQgc3BhX2dldF9zdGF0 cysweDQ0Cnpmc19pb2NfcG9vbF9zdGF0cygpIGF0IHpmc19pb2NfcG9vbF9zdGF0cysweDJj Cnpmc2Rldl9pb2N0bCgpIGF0IHpmc2Rldl9pb2N0bCsweGE0CmRldmZzX2lvY3RsX2YoKSBh dCBkZXZmc19pb2N0bF9mKzB4N2EKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhiZQpp b2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbGVudGVyKCkgYXQgc3lzY2FsbGVudGVyKzB4 MWFhCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4NGMKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0 X3N5c2NhbGwrMHhlMgotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwg cmlwID0gMHg4MDEyMDg3N2MsIHJzcCA9IDB4N2ZmZmZmZmY5Mjg4LCByYnAgPSAweDgwMTgz ZjE0MCAtLS0KbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZmZjAxMmUzNmNkMjgg ZGItPmRiX210eCAoZGItPmRiX210eCkgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMvLi4v Li4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL2Rub2RlX3N5 bmMuYzozOTYKIDJuZCAweGZmZmZmZjAxMjI5NzRlNjAgb3MtPm9zX2xvY2sgKG9zLT5vc19s b2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3Bl bnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZG5vZGUuYzo0MzkKS0RCOiBzdGFjayBiYWNr dHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBl cisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3 aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MDcKX3N4X3hs b2NrKCkgYXQgX3N4X3hsb2NrKzB4NTUKZG5vZGVfZGVzdHJveSgpIGF0IGRub2RlX2Rlc3Ry b3krMHgzZQpkbm9kZV9idWZfcGFnZW91dCgpIGF0IGRub2RlX2J1Zl9wYWdlb3V0KzB4OWQK ZGJ1Zl9ldmljdF91c2VyKCkgYXQgZGJ1Zl9ldmljdF91c2VyKzB4NTUKZGJ1Zl9jbGVhcigp IGF0IGRidWZfY2xlYXIrMHg1OApkbm9kZV9ldmljdF9kYnVmcygpIGF0IGRub2RlX2V2aWN0 X2RidWZzKzB4OTgKZG11X29ianNldF9ldmljdF9kYnVmcygpIGF0IGRtdV9vYmpzZXRfZXZp Y3RfZGJ1ZnMrMHgxMWMKZG11X29ianNldF9ldmljdCgpIGF0IGRtdV9vYmpzZXRfZXZpY3Qr MHhhMwpkc2xfcG9vbF9jbG9zZSgpIGF0IGRzbF9wb29sX2Nsb3NlKzB4NmEKc3BhX3VubG9h ZCgpIGF0IHNwYV91bmxvYWQrMHg3OQpzcGFfbG9hZCgpIGF0IHNwYV9sb2FkKzB4NjJkCnNw YV9sb2FkX2Jlc3QoKSBhdCBzcGFfbG9hZF9iZXN0KzB4NTIKc3BhX29wZW5fY29tbW9uKCkg YXQgc3BhX29wZW5fY29tbW9uKzB4MTRhCnNwYV9nZXRfc3RhdHMoKSBhdCBzcGFfZ2V0X3N0 YXRzKzB4NDQKemZzX2lvY19wb29sX3N0YXRzKCkgYXQgemZzX2lvY19wb29sX3N0YXRzKzB4 MmMKemZzZGV2X2lvY3RsKCkgYXQgemZzZGV2X2lvY3RsKzB4YTQKZGV2ZnNfaW9jdGxfZigp IGF0IGRldmZzX2lvY3RsX2YrMHg3YQprZXJuX2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweGJl CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxsZW50ZXIoKSBhdCBzeXNjYWxsZW50ZXIr MHgxYWEKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHg0YwpYZmFzdF9zeXNjYWxsKCkgYXQgWGZh c3Rfc3lzY2FsbCsweGUyCi0tLSBzeXNjYWxsICg1NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwp LCByaXAgPSAweDgwMTIwODc3YywgcnNwID0gMHg3ZmZmZmZmZjkyODgsIHJicCA9IDB4ODAx ODNmMTQwIC0tLQp2ZGV2X2dlb21fZGV0YWNoOjE1NlsxXTogQ2xvc2luZyBhY2Nlc3MgdG8g YWRhMC4KdmRldl9nZW9tX2RldGFjaDoxNjBbMV06IERlc3Ryb3llZCBjb25zdW1lciB0byBh ZGEwLgp2ZGV2X2dlb21fZGV0YWNoOjE1NlsxXTogQ2xvc2luZyBhY2Nlc3MgdG8gYWRhMS4K dmRldl9nZW9tX2RldGFjaDoxNjBbMV06IERlc3Ryb3llZCBjb25zdW1lciB0byBhZGExLgp2 ZGV2X2dlb21fZGV0YWNoOjE1NlsxXTogQ2xvc2luZyBhY2Nlc3MgdG8gYWRhMi4KdmRldl9n ZW9tX2RldGFjaDoxNjBbMV06IERlc3Ryb3llZCBjb25zdW1lciB0byBhZGEyLgp2ZGV2X2dl b21fZGV0YWNoOjE2OFsxXTogRGVzdHJveWVkIGdlb20gemZzOjp2ZGV2Lgp2ZGV2X2dlb21f b3Blbl9ieV9wYXRoOjM4NFsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2FkYTAu CnZkZXZfZ2VvbV9hdHRhY2g6OTVbMV06IEF0dGFjaGluZyB0byBhZGEwLgp2ZGV2X2dlb21f YXR0YWNoOjExNlsxXTogQ3JlYXRlZCBnZW9tIGFuZCBjb25zdW1lciBmb3IgYWRhMC4KdmRl dl9nZW9tX3JlYWRfZ3VpZDoyMzlbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTAuLi4KdmRl dl9nZW9tX3JlYWRfZ3VpZDoyNzNbMV06IGd1aWQgZm9yIGFkYTAgaXMgMTE4NjE5MjQ2ODE4 MjAzNDE0NDMKdmRldl9nZW9tX29wZW5fYnlfcGF0aDozOThbMV06IGd1aWQgbWF0Y2ggZm9y IHByb3ZpZGVyIC9kZXYvYWRhMC4KdmRldl9nZW9tX29wZW5fYnlfcGF0aDozODRbMV06IEZv dW5kIHByb3ZpZGVyIGJ5IG5hbWUgL2Rldi9hZGExLgp2ZGV2X2dlb21fYXR0YWNoOjk1WzFd OiBBdHRhY2hpbmcgdG8gYWRhMS4KdmRldl9nZW9tX2F0dGFjaDoxMzZbMV06IENyZWF0ZWQg Y29uc3VtZXIgZm9yIGFkYTEuCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjM5WzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBhZGExLi4uCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjczWzFdOiBndWlkIGZv ciBhZGExIGlzIDQyMjIwNzA4MzUyNDYwOTA1NzkKdmRldl9nZW9tX29wZW5fYnlfcGF0aDoz OThbMV06IGd1aWQgbWF0Y2ggZm9yIHByb3ZpZGVyIC9kZXYvYWRhMS4KdmRldl9nZW9tX29w ZW5fYnlfcGF0aDozODRbMV06IEZvdW5kIHByb3ZpZGVyIGJ5IG5hbWUgL2Rldi9hZGEyLgp2 ZGV2X2dlb21fYXR0YWNoOjk1WzFdOiBBdHRhY2hpbmcgdG8gYWRhMi4KdmRldl9nZW9tX2F0 dGFjaDoxMzZbMV06IENyZWF0ZWQgY29uc3VtZXIgZm9yIGFkYTIuCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MjM5WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEyLi4uCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MjczWzFdOiBndWlkIGZvciBhZGEyIGlzIDY4Nzk3MDc1Mjc5ODIxNDE1MDEKdmRl dl9nZW9tX29wZW5fYnlfcGF0aDozOThbMV06IGd1aWQgbWF0Y2ggZm9yIHByb3ZpZGVyIC9k ZXYvYWRhMi4KbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZmZjAxMmRhMjM1Nzgg ZGItPmRiX210eCAoZGItPmRiX210eCkgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMvLi4v Li4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL2RidWYuYzox MjQyCiAybmQgMHhmZmZmZmYwMTMxYTQwMzM4IGRyLT5kdC5kaS5kcl9tdHggKGRyLT5kdC5k aS5kcl9tdHgpIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy9kYnVmLmM6MTI0NgpLREI6IHN0YWNr IGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93 cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisw eDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDgwNwpf c3hfeGxvY2soKSBhdCBfc3hfeGxvY2srMHg1NQpkYnVmX2RpcnR5KCkgYXQgZGJ1Zl9kaXJ0 eSsweDZjZQpkYnVmX2RpcnR5KCkgYXQgZGJ1Zl9kaXJ0eSsweDUyYgpkbm9kZV9zZXRkaXJ0 eSgpIGF0IGRub2RlX3NldGRpcnR5KzB4MWE1CmRidWZfZGlydHkoKSBhdCBkYnVmX2RpcnR5 KzB4NTkzCmJwb2JqX2l0ZXJhdGVfaW1wbCgpIGF0IGJwb2JqX2l0ZXJhdGVfaW1wbCsweDVh MQpzcGFfc3luYygpIGF0IHNwYV9zeW5jKzB4MjdmCnR4Z19zeW5jX3RocmVhZCgpIGF0IHR4 Z19zeW5jX3RocmVhZCsweDE0Nwpmb3JrX2V4aXQoKSBhdCBmb3JrX2V4aXQrMHgxMmEKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4ZQotLS0gdHJhcCAwLCByaXAg PSAwLCByc3AgPSAweGZmZmZmZjgwZWRiMThjZjAsIHJicCA9IDAgLS0tCnZkZXZfZ2VvbV9v cGVuX2J5X3BhdGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBieSBuYW1lIC9kZXYvZGEwLgp2 ZGV2X2dlb21fYXR0YWNoOjk1WzFdOiBBdHRhY2hpbmcgdG8gZGEwLgp2ZGV2X2dlb21fYXR0 YWNoOjEzNlsxXTogQ3JlYXRlZCBjb25zdW1lciBmb3IgZGEwLgp2ZGV2X2dlb21fcmVhZF9n dWlkOjIzOVsxXTogUmVhZGluZyBndWlkIGZyb20gZGEwLi4uCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MjczWzFdOiBndWlkIGZvciBkYTAgaXMgOTM1ODE2NDMzMjU1Nzk4ODU4Mwp2ZGV2X2dl b21fb3Blbl9ieV9wYXRoOjM5OFsxXTogZ3VpZCBtYXRjaCBmb3IgcHJvdmlkZXIgL2Rldi9k YTAuCnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBieSBu YW1lIC9kZXYvZGExLgp2ZGV2X2dlb21fYXR0YWNoOjk1WzFdOiBBdHRhY2hpbmcgdG8gZGEx Lgp2ZGV2X2dlb21fYXR0YWNoOjEzNlsxXTogQ3JlYXRlZCBjb25zdW1lciBmb3IgZGExLgp2 ZGV2X2dlb21fcmVhZF9ndWlkOjIzOVsxXTogUmVhZGluZyBndWlkIGZyb20gZGExLi4uCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MjczWzFdOiBndWlkIGZvciBkYTEgaXMgMTM0NDA2MDc5NDQ3 ODI4NjAwNjgKdmRldl9nZW9tX29wZW5fYnlfcGF0aDozOThbMV06IGd1aWQgbWF0Y2ggZm9y IHByb3ZpZGVyIC9kZXYvZGExLgp2ZGV2X2dlb21fb3Blbl9ieV9wYXRoOjM4NFsxXTogRm91 bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2RhMi4KdmRldl9nZW9tX2F0dGFjaDo5NVsxXTog QXR0YWNoaW5nIHRvIGRhMi4KdmRldl9nZW9tX2F0dGFjaDoxMzZbMV06IENyZWF0ZWQgY29u c3VtZXIgZm9yIGRhMi4KdmRldl9nZW9tX3JlYWRfZ3VpZDoyMzlbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGRhMi4uLgp2ZGV2X2dlb21fcmVhZF9ndWlkOjI3M1sxXTogZ3VpZCBmb3IgZGEy IGlzIDUyNTkyODQxNzg0MTg2NDc3NTAKdmRldl9nZW9tX29wZW5fYnlfcGF0aDozOThbMV06 IGd1aWQgbWF0Y2ggZm9yIHByb3ZpZGVyIC9kZXYvZGEyLgp2ZGV2X2dlb21fb3Blbl9ieV9w YXRoOjM4NFsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2RhNy4KdmRldl9nZW9t X2F0dGFjaDo5NVsxXTogQXR0YWNoaW5nIHRvIGRhNy4KdmRldl9nZW9tX2F0dGFjaDoxMzZb MV06IENyZWF0ZWQgY29uc3VtZXIgZm9yIGRhNy4KdmRldl9nZW9tX3JlYWRfZ3VpZDoyMzlb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGRhNy4uLgp2ZGV2X2dlb21fcmVhZF9ndWlkOjI3M1sx XTogZ3VpZCBmb3IgZGE3IGlzIDEwOTM3MzAxMTAzNTA5NzU0MzY0CnZkZXZfZ2VvbV9vcGVu X2J5X3BhdGg6Mzk4WzFdOiBndWlkIG1hdGNoIGZvciBwcm92aWRlciAvZGV2L2RhNy4KdmRl dl9nZW9tX2RldGFjaDoxNTZbMV06IENsb3NpbmcgYWNjZXNzIHRvIGRhMC4KdmRldl9nZW9t X2RldGFjaDoxNjBbMV06IERlc3Ryb3llZCBjb25zdW1lciB0byBkYTAuCnZkZXZfZ2VvbV9k ZXRhY2g6MTU2WzFdOiBDbG9zaW5nIGFjY2VzcyB0byBkYTEuCnZkZXZfZ2VvbV9kZXRhY2g6 MTYwWzFdOiBEZXN0cm95ZWQgY29uc3VtZXIgdG8gZGExLgp2ZGV2X2dlb21fZGV0YWNoOjE1 NlsxXTogQ2xvc2luZyBhY2Nlc3MgdG8gZGEyLgp2ZGV2X2dlb21fZGV0YWNoOjE2MFsxXTog RGVzdHJveWVkIGNvbnN1bWVyIHRvIGRhMi4KdmRldl9nZW9tX2RldGFjaDoxNTZbMV06IENs b3NpbmcgYWNjZXNzIHRvIGRhNy4KdmRldl9nZW9tX2RldGFjaDoxNjBbMV06IERlc3Ryb3ll ZCBjb25zdW1lciB0byBkYTcuCnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6Mzg0WzFdOiBGb3Vu ZCBwcm92aWRlciBieSBuYW1lIC9kZXYvZGEwLgp2ZGV2X2dlb21fYXR0YWNoOjk1WzFdOiBB dHRhY2hpbmcgdG8gZGEwLgp2ZGV2X2dlb21fYXR0YWNoOjEzNlsxXTogQ3JlYXRlZCBjb25z dW1lciBmb3IgZGEwLgp2ZGV2X2dlb21fcmVhZF9ndWlkOjIzOVsxXTogUmVhZGluZyBndWlk IGZyb20gZGEwLi4uCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjczWzFdOiBndWlkIGZvciBkYTAg aXMgOTM1ODE2NDMzMjU1Nzk4ODU4Mwp2ZGV2X2dlb21fb3Blbl9ieV9wYXRoOjM5OFsxXTog Z3VpZCBtYXRjaCBmb3IgcHJvdmlkZXIgL2Rldi9kYTAuCnZkZXZfZ2VvbV9vcGVuX2J5X3Bh dGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBieSBuYW1lIC9kZXYvZGExLgp2ZGV2X2dlb21f YXR0YWNoOjk1WzFdOiBBdHRhY2hpbmcgdG8gZGExLgp2ZGV2X2dlb21fYXR0YWNoOjEzNlsx XTogQ3JlYXRlZCBjb25zdW1lciBmb3IgZGExLgp2ZGV2X2dlb21fcmVhZF9ndWlkOjIzOVsx XTogUmVhZGluZyBndWlkIGZyb20gZGExLi4uCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjczWzFd OiBndWlkIGZvciBkYTEgaXMgMTM0NDA2MDc5NDQ3ODI4NjAwNjgKdmRldl9nZW9tX29wZW5f YnlfcGF0aDozOThbMV06IGd1aWQgbWF0Y2ggZm9yIHByb3ZpZGVyIC9kZXYvZGExLgp2ZGV2 X2dlb21fb3Blbl9ieV9wYXRoOjM4NFsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2 L2RhMi4KdmRldl9nZW9tX2F0dGFjaDo5NVsxXTogQXR0YWNoaW5nIHRvIGRhMi4KdmRldl9n ZW9tX2F0dGFjaDoxMzZbMV06IENyZWF0ZWQgY29uc3VtZXIgZm9yIGRhMi4KdmRldl9nZW9t X3JlYWRfZ3VpZDoyMzlbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGRhMi4uLgp2ZGV2X2dlb21f cmVhZF9ndWlkOjI3M1sxXTogZ3VpZCBmb3IgZGEyIGlzIDUyNTkyODQxNzg0MTg2NDc3NTAK dmRldl9nZW9tX29wZW5fYnlfcGF0aDozOThbMV06IGd1aWQgbWF0Y2ggZm9yIHByb3ZpZGVy IC9kZXYvZGEyLgp2ZGV2X2dlb21fb3Blbl9ieV9wYXRoOjM4NFsxXTogRm91bmQgcHJvdmlk ZXIgYnkgbmFtZSAvZGV2L2RhNy4KdmRldl9nZW9tX2F0dGFjaDo5NVsxXTogQXR0YWNoaW5n IHRvIGRhNy4KdmRldl9nZW9tX2F0dGFjaDoxMzZbMV06IENyZWF0ZWQgY29uc3VtZXIgZm9y IGRhNy4KdmRldl9nZW9tX3JlYWRfZ3VpZDoyMzlbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGRh Ny4uLgp2ZGV2X2dlb21fcmVhZF9ndWlkOjI3M1sxXTogZ3VpZCBmb3IgZGE3IGlzIDEwOTM3 MzAxMTAzNTA5NzU0MzY0CnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6Mzk4WzFdOiBndWlkIG1h dGNoIGZvciBwcm92aWRlciAvZGV2L2RhNy4KbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAw eGZmZmZmZjAxMzFhYjMzMzggZHItPmR0LmRpLmRyX210eCAoZHItPmR0LmRpLmRyX210eCkg QCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xh cmlzL3V0cy9jb21tb24vZnMvemZzL2RidWYuYzoyMjQzCiAybmQgMHhmZmZmZmYwMTQyNWQ2 ODUwIGRuLT5kbl9zdHJ1Y3Rfcndsb2NrIChkbi0+ZG5fc3RydWN0X3J3bG9jaykgQCAvdXNy L3NyYy9zeXMvbW9kdWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0 cy9jb21tb24vZnMvemZzL2RidWYuYzoyMTk0CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90 cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQpfd2l0 bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0bmVzc19jaGVj a29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODA3Cl9zeF9zbG9jaygpIGF0IF9z eF9zbG9jaysweDU1CmRidWZfY2hlY2tfYmxrcHRyKCkgYXQgZGJ1Zl9jaGVja19ibGtwdHIr MHgyMTAKZGJ1Zl9zeW5jX2xpc3QoKSBhdCBkYnVmX3N5bmNfbGlzdCsweDM2YwpkYnVmX3N5 bmNfbGlzdCgpIGF0IGRidWZfc3luY19saXN0KzB4MTdmCmRub2RlX3N5bmMoKSBhdCBkbm9k ZV9zeW5jKzB4ZTljCmRtdV9vYmpzZXRfc3luY19kbm9kZXMoKSBhdCBkbXVfb2Jqc2V0X3N5 bmNfZG5vZGVzKzB4OTIKZG11X29ianNldF9zeW5jKCkgYXQgZG11X29ianNldF9zeW5jKzB4 MTlkCmRzbF9wb29sX3N5bmMoKSBhdCBkc2xfcG9vbF9zeW5jKzB4MzNiCnNwYV9zeW5jKCkg YXQgc3BhX3N5bmMrMHgzM2YKdHhnX3N5bmNfdGhyZWFkKCkgYXQgdHhnX3N5bmNfdGhyZWFk KzB4MTQ3CmZvcmtfZXhpdCgpIGF0IGZvcmtfZXhpdCsweDEyYQpmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUrMHhlCi0tLSB0cmFwIDAsIHJpcCA9IDAsIHJzcCA9IDB4 ZmZmZmZmODBlZGUxNGNmMCwgcmJwID0gMCAtLS0KdmRldl9nZW9tX29wZW5fYnlfcGF0aDoz ODRbMV06IEZvdW5kIHByb3ZpZGVyIGJ5IG5hbWUgL2Rldi9hZGE0Lgp2ZGV2X2dlb21fYXR0 YWNoOjk1WzFdOiBBdHRhY2hpbmcgdG8gYWRhNC4KdmRldl9nZW9tX2F0dGFjaDoxMzZbMV06 IENyZWF0ZWQgY29uc3VtZXIgZm9yIGFkYTQuCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjM5WzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE0Li4uCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjczWzFd OiBndWlkIGZvciBhZGE0IGlzIDEwMDAwOTY5MTg5OTY1OTg0ODg5CnZkZXZfZ2VvbV9vcGVu X2J5X3BhdGg6Mzk4WzFdOiBndWlkIG1hdGNoIGZvciBwcm92aWRlciAvZGV2L2FkYTQuCnZk ZXZfZ2VvbV9vcGVuX2J5X3BhdGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBieSBuYW1lIC9k ZXYvYWRhNS4KdmRldl9nZW9tX2F0dGFjaDo5NVsxXTogQXR0YWNoaW5nIHRvIGFkYTUuCnZk ZXZfZ2VvbV9hdHRhY2g6MTM2WzFdOiBDcmVhdGVkIGNvbnN1bWVyIGZvciBhZGE1Lgp2ZGV2 X2dlb21fcmVhZF9ndWlkOjIzOVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhNS4uLgp2ZGV2 X2dlb21fcmVhZF9ndWlkOjI3M1sxXTogZ3VpZCBmb3IgYWRhNSBpcyAzODA1NzA0MzExNDM2 MDIyMTEKdmRldl9nZW9tX29wZW5fYnlfcGF0aDozOThbMV06IGd1aWQgbWF0Y2ggZm9yIHBy b3ZpZGVyIC9kZXYvYWRhNS4KdmRldl9nZW9tX29wZW5fYnlfcGF0aDozODRbMV06IEZvdW5k IHByb3ZpZGVyIGJ5IG5hbWUgL2Rldi9hZGE2Lgp2ZGV2X2dlb21fYXR0YWNoOjk1WzFdOiBB dHRhY2hpbmcgdG8gYWRhNi4KdmRldl9nZW9tX2F0dGFjaDoxMzZbMV06IENyZWF0ZWQgY29u c3VtZXIgZm9yIGFkYTYuCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjM5WzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBhZGE2Li4uCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjczWzFdOiBndWlkIGZvciBh ZGE2IGlzIDcyNDM4ODU3Nzc2NzQ0NDMyNDcKdmRldl9nZW9tX29wZW5fYnlfcGF0aDozOThb MV06IGd1aWQgbWF0Y2ggZm9yIHByb3ZpZGVyIC9kZXYvYWRhNi4KdmRldl9nZW9tX2RldGFj aDoxNTZbMV06IENsb3NpbmcgYWNjZXNzIHRvIGFkYTQuCnZkZXZfZ2VvbV9kZXRhY2g6MTYw WzFdOiBEZXN0cm95ZWQgY29uc3VtZXIgdG8gYWRhNC4KdmRldl9nZW9tX2RldGFjaDoxNTZb MV06IENsb3NpbmcgYWNjZXNzIHRvIGFkYTUuCnZkZXZfZ2VvbV9kZXRhY2g6MTYwWzFdOiBE ZXN0cm95ZWQgY29uc3VtZXIgdG8gYWRhNS4KdmRldl9nZW9tX2RldGFjaDoxNTZbMV06IENs b3NpbmcgYWNjZXNzIHRvIGFkYTYuCnZkZXZfZ2VvbV9kZXRhY2g6MTYwWzFdOiBEZXN0cm95 ZWQgY29uc3VtZXIgdG8gYWRhNi4KdmRldl9nZW9tX29wZW5fYnlfcGF0aDozODRbMV06IEZv dW5kIHByb3ZpZGVyIGJ5IG5hbWUgL2Rldi9hZGE0Lgp2ZGV2X2dlb21fYXR0YWNoOjk1WzFd OiBBdHRhY2hpbmcgdG8gYWRhNC4KdmRldl9nZW9tX2F0dGFjaDoxMzZbMV06IENyZWF0ZWQg Y29uc3VtZXIgZm9yIGFkYTQuCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjM5WzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBhZGE0Li4uCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjczWzFdOiBndWlkIGZv ciBhZGE0IGlzIDEwMDAwOTY5MTg5OTY1OTg0ODg5CnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6 Mzk4WzFdOiBndWlkIG1hdGNoIGZvciBwcm92aWRlciAvZGV2L2FkYTQuCnZkZXZfZ2VvbV9v cGVuX2J5X3BhdGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBieSBuYW1lIC9kZXYvYWRhNS4K dmRldl9nZW9tX2F0dGFjaDo5NVsxXTogQXR0YWNoaW5nIHRvIGFkYTUuCnZkZXZfZ2VvbV9h dHRhY2g6MTM2WzFdOiBDcmVhdGVkIGNvbnN1bWVyIGZvciBhZGE1Lgp2ZGV2X2dlb21fcmVh ZF9ndWlkOjIzOVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhNS4uLgp2ZGV2X2dlb21fcmVh ZF9ndWlkOjI3M1sxXTogZ3VpZCBmb3IgYWRhNSBpcyAzODA1NzA0MzExNDM2MDIyMTEKdmRl dl9nZW9tX29wZW5fYnlfcGF0aDozOThbMV06IGd1aWQgbWF0Y2ggZm9yIHByb3ZpZGVyIC9k ZXYvYWRhNS4KdmRldl9nZW9tX29wZW5fYnlfcGF0aDozODRbMV06IEZvdW5kIHByb3ZpZGVy IGJ5IG5hbWUgL2Rldi9hZGE2Lgp2ZGV2X2dlb21fYXR0YWNoOjk1WzFdOiBBdHRhY2hpbmcg dG8gYWRhNi4KdmRldl9nZW9tX2F0dGFjaDoxMzZbMV06IENyZWF0ZWQgY29uc3VtZXIgZm9y IGFkYTYuCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjM5WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBh ZGE2Li4uCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjczWzFdOiBndWlkIGZvciBhZGE2IGlzIDcy NDM4ODU3Nzc2NzQ0NDMyNDcKdmRldl9nZW9tX29wZW5fYnlfcGF0aDozOThbMV06IGd1aWQg bWF0Y2ggZm9yIHByb3ZpZGVyIC9kZXYvYWRhNi4KdmRldl9nZW9tX29wZW5fYnlfcGF0aDoz ODRbMV06IEZvdW5kIHByb3ZpZGVyIGJ5IG5hbWUgL2Rldi9kYTMuCnZkZXZfZ2VvbV9hdHRh Y2g6OTVbMV06IEF0dGFjaGluZyB0byBkYTMuCnZkZXZfZ2VvbV9hdHRhY2g6MTM2WzFdOiBD cmVhdGVkIGNvbnN1bWVyIGZvciBkYTMuCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjM5WzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBkYTMuLi4KdmRldl9nZW9tX3JlYWRfZ3VpZDoyNzNbMV06IGd1 aWQgZm9yIGRhMyBpcyAyNDcwMjU0MDA3MzcxNjY2NjQ2CnZkZXZfZ2VvbV9vcGVuX2J5X3Bh dGg6Mzk4WzFdOiBndWlkIG1hdGNoIGZvciBwcm92aWRlciAvZGV2L2RhMy4KdmRldl9nZW9t X2RldGFjaDoxNTZbMV06IENsb3NpbmcgYWNjZXNzIHRvIGRhMy4KdmRldl9nZW9tX2RldGFj aDoxNjBbMV06IERlc3Ryb3llZCBjb25zdW1lciB0byBkYTMuCnZkZXZfZ2VvbV9vcGVuX2J5 X3BhdGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBieSBuYW1lIC9kZXYvZGEzLgp2ZGV2X2dl b21fYXR0YWNoOjk1WzFdOiBBdHRhY2hpbmcgdG8gZGEzLgp2ZGV2X2dlb21fYXR0YWNoOjEz NlsxXTogQ3JlYXRlZCBjb25zdW1lciBmb3IgZGEzLgp2ZGV2X2dlb21fcmVhZF9ndWlkOjIz OVsxXTogUmVhZGluZyBndWlkIGZyb20gZGEzLi4uCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6Mjcz WzFdOiBndWlkIGZvciBkYTMgaXMgMjQ3MDI1NDAwNzM3MTY2NjY0Ngp2ZGV2X2dlb21fb3Bl bl9ieV9wYXRoOjM5OFsxXTogZ3VpZCBtYXRjaCBmb3IgcHJvdmlkZXIgL2Rldi9kYTMuCnZk ZXZfZ2VvbV9vcGVuX2J5X3BhdGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBieSBuYW1lIC9k ZXYvZGE0Lgp2ZGV2X2dlb21fYXR0YWNoOjk1WzFdOiBBdHRhY2hpbmcgdG8gZGE0Lgp2ZGV2 X2dlb21fYXR0YWNoOjEzNlsxXTogQ3JlYXRlZCBjb25zdW1lciBmb3IgZGE0Lgp2ZGV2X2dl b21fcmVhZF9ndWlkOjIzOVsxXTogUmVhZGluZyBndWlkIGZyb20gZGE0Li4uCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MjczWzFdOiBndWlkIGZvciBkYTQgaXMgMTIyMDEzODI3OTM1MDc5NDQ2 MTUKdmRldl9nZW9tX29wZW5fYnlfcGF0aDozOThbMV06IGd1aWQgbWF0Y2ggZm9yIHByb3Zp ZGVyIC9kZXYvZGE0Lgp2ZGV2X2dlb21fZGV0YWNoOjE1NlsxXTogQ2xvc2luZyBhY2Nlc3Mg dG8gZGE0Lgp2ZGV2X2dlb21fZGV0YWNoOjE2MFsxXTogRGVzdHJveWVkIGNvbnN1bWVyIHRv IGRhNC4KdmRldl9nZW9tX29wZW5fYnlfcGF0aDozODRbMV06IEZvdW5kIHByb3ZpZGVyIGJ5 IG5hbWUgL2Rldi9kYTQuCnZkZXZfZ2VvbV9hdHRhY2g6OTVbMV06IEF0dGFjaGluZyB0byBk YTQuCnZkZXZfZ2VvbV9hdHRhY2g6MTM2WzFdOiBDcmVhdGVkIGNvbnN1bWVyIGZvciBkYTQu CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MjM5WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBkYTQuLi4K dmRldl9nZW9tX3JlYWRfZ3VpZDoyNzNbMV06IGd1aWQgZm9yIGRhNCBpcyAxMjIwMTM4Mjc5 MzUwNzk0NDYxNQp2ZGV2X2dlb21fb3Blbl9ieV9wYXRoOjM5OFsxXTogZ3VpZCBtYXRjaCBm b3IgcHJvdmlkZXIgL2Rldi9kYTQuCnZkZXZfZ2VvbV9kZXRhY2g6MTU2WzFdOiBDbG9zaW5n IGFjY2VzcyB0byBkYTMuCnZkZXZfZ2VvbV9kZXRhY2g6MTYwWzFdOiBEZXN0cm95ZWQgY29u c3VtZXIgdG8gZGEzLgp2ZGV2X2dlb21fZGV0YWNoOjE1NlsxXTogQ2xvc2luZyBhY2Nlc3Mg dG8gZGE0Lgp2ZGV2X2dlb21fZGV0YWNoOjE2MFsxXTogRGVzdHJveWVkIGNvbnN1bWVyIHRv IGRhNC4KdmRldl9nZW9tX29wZW5fYnlfcGF0aDozODRbMV06IEZvdW5kIHByb3ZpZGVyIGJ5 IG5hbWUgL2Rldi9kYTMuCnZkZXZfZ2VvbV9hdHRhY2g6OTVbMV06IEF0dGFjaGluZyB0byBk YTMuCnZkZXZfZ2VvbV9hdHRhY2g6MTM2WzFdOiBDcmVhdGVkIGNvbnN1bWVyIGZvciBkYTMu CmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAxc3QgMHhmZmZmZmYwMTQyMjEyMTAwIHNhLT5zYV9s b2NrIChzYS0+c2FfbG9jaykgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMvLi4vLi4vY2Rk bC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL3NhLmM6OTk1CiAybmQg MHhmZmZmZmYwMTQ5MWU0MDAwIGRuLT5kbl9zdHJ1Y3Rfcndsb2NrIChkbi0+ZG5fc3RydWN0 X3J3bG9jaykgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmli L29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL2Rub2RlLmM6MjA1CktEQjogc3RhY2sg YmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dy YXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4 MmUKd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODA3Cl9z eF9zbG9jaygpIGF0IF9zeF9zbG9jaysweDU1CmRub2RlX3ZlcmlmeSgpIGF0IGRub2RlX3Zl cmlmeSsweDdjCmRub2RlX2hvbGRfaW1wbCgpIGF0IGRub2RlX2hvbGRfaW1wbCsweDk0CmRt dV9idWZfaG9sZCgpIGF0IGRtdV9idWZfaG9sZCsweDQ4CnphcF9sb2NrZGlyKCkgYXQgemFw X2xvY2tkaXIrMHg3NAp6YXBfbG9va3VwX25vcm0oKSBhdCB6YXBfbG9va3VwX25vcm0rMHg0 NQp6YXBfbG9va3VwKCkgYXQgemFwX2xvb2t1cCsweDJlCnNhX3NldHVwKCkgYXQgc2Ffc2V0 dXArMHgyMTQKemZzX2NyZWF0ZV9mcygpIGF0IHpmc19jcmVhdGVfZnMrMHgzYTkKZHNsX3Bv b2xfY3JlYXRlKCkgYXQgZHNsX3Bvb2xfY3JlYXRlKzB4MjAxCnNwYV9jcmVhdGUoKSBhdCBz cGFfY3JlYXRlKzB4NGE4Cnpmc19pb2NfcG9vbF9jcmVhdGUoKSBhdCB6ZnNfaW9jX3Bvb2xf Y3JlYXRlKzB4MWMyCnpmc2Rldl9pb2N0bCgpIGF0IHpmc2Rldl9pb2N0bCsweGE0CmRldmZz X2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4N2EKa2Vybl9pb2N0bCgpIGF0IGtlcm5f aW9jdGwrMHhiZQppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbGVudGVyKCkgYXQgc3lz Y2FsbGVudGVyKzB4MWFhCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4NGMKWGZhc3Rfc3lzY2Fs bCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMgotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxG NjQsIGlvY3RsKSwgcmlwID0gMHg4MDEyMDg3N2MsIHJzcCA9IDB4N2ZmZmZmZmY4YWI4LCBy YnAgPSAweDdmZmZmZmZmOGIyMCAtLS0KbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZm ZmZmZjAxNDIyMTIxMDAgc2EtPnNhX2xvY2sgKHNhLT5zYV9sb2NrKSBAIC91c3Ivc3JjL3N5 cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1v bi9mcy96ZnMvc2EuYzo5OTUKIDJuZCAweGZmZmZmZjAxMjkyN2NjMTggemFwLT56YXBfcnds b2NrICh6YXAtPnphcF9yd2xvY2spIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4u L2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96YXBfbWljcm8u YzozNzUKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0 IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dp dG5lc3NfZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2No ZWNrb3JkZXIrMHg4MDcKX3N4X3hsb2NrKCkgYXQgX3N4X3hsb2NrKzB4NTUKemFwX2xvY2tk aXIoKSBhdCB6YXBfbG9ja2RpcisweDM0Ywp6YXBfbG9va3VwX25vcm0oKSBhdCB6YXBfbG9v a3VwX25vcm0rMHg0NQp6YXBfbG9va3VwKCkgYXQgemFwX2xvb2t1cCsweDJlCnNhX3NldHVw KCkgYXQgc2Ffc2V0dXArMHgyMTQKemZzX2NyZWF0ZV9mcygpIGF0IHpmc19jcmVhdGVfZnMr MHgzYTkKZHNsX3Bvb2xfY3JlYXRlKCkgYXQgZHNsX3Bvb2xfY3JlYXRlKzB4MjAxCnNwYV9j cmVhdGUoKSBhdCBzcGFfY3JlYXRlKzB4NGE4Cnpmc19pb2NfcG9vbF9jcmVhdGUoKSBhdCB6 ZnNfaW9jX3Bvb2xfY3JlYXRlKzB4MWMyCnpmc2Rldl9pb2N0bCgpIGF0IHpmc2Rldl9pb2N0 bCsweGE0CmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4N2EKa2Vybl9pb2N0 bCgpIGF0IGtlcm5faW9jdGwrMHhiZQppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbGVu dGVyKCkgYXQgc3lzY2FsbGVudGVyKzB4MWFhCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4NGMK WGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMgotLS0gc3lzY2FsbCAoNTQs IEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDEyMDg3N2MsIHJzcCA9IDB4N2Zm ZmZmZmY4YWI4LCByYnAgPSAweDdmZmZmZmZmOGIyMCAtLS0KbG9jayBvcmRlciByZXZlcnNh bDoKIDFzdCAweGZmZmZmZjAxNDIyMTIxMDAgc2EtPnNhX2xvY2sgKHNhLT5zYV9sb2NrKSBA IC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFy aXMvdXRzL2NvbW1vbi9mcy96ZnMvc2EuYzoxNTQ2CiAybmQgMHhmZmZmZmYwMTQyNTFjNjM4 IG9zLT5vc19vYmpfbG9jayAob3MtPm9zX29ial9sb2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1 bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96 ZnMvZG11X29iamVjdC5jOjQwCktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxm X3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1 Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0bmVzc19jaGVja29yZGVyKCkg YXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODA3Cl9zeF94bG9jaygpIGF0IF9zeF94bG9jaysw eDU1CmRtdV9vYmplY3RfYWxsb2MoKSBhdCBkbXVfb2JqZWN0X2FsbG9jKzB4NzAKemFwX2Ny ZWF0ZV9ub3JtKCkgYXQgemFwX2NyZWF0ZV9ub3JtKzB4MmQKc2FfYXR0cl9yZWdpc3Rlcl9z eW5jKCkgYXQgc2FfYXR0cl9yZWdpc3Rlcl9zeW5jKzB4MTliCnNhX3JlcGxhY2VfYWxsX2J5 X3RlbXBsYXRlX2xvY2tlZCgpIGF0IHNhX3JlcGxhY2VfYWxsX2J5X3RlbXBsYXRlX2xvY2tl ZCsweDQxCnNhX3JlcGxhY2VfYWxsX2J5X3RlbXBsYXRlKCkgYXQgc2FfcmVwbGFjZV9hbGxf YnlfdGVtcGxhdGUrMHg0Ygp6ZnNfbWtub2RlKCkgYXQgemZzX21rbm9kZSsweDU0OAp6ZnNf Y3JlYXRlX2ZzKCkgYXQgemZzX2NyZWF0ZV9mcysweDUyZApkc2xfcG9vbF9jcmVhdGUoKSBh dCBkc2xfcG9vbF9jcmVhdGUrMHgyMDEKc3BhX2NyZWF0ZSgpIGF0IHNwYV9jcmVhdGUrMHg0 YTgKemZzX2lvY19wb29sX2NyZWF0ZSgpIGF0IHpmc19pb2NfcG9vbF9jcmVhdGUrMHgxYzIK emZzZGV2X2lvY3RsKCkgYXQgemZzZGV2X2lvY3RsKzB4YTQKZGV2ZnNfaW9jdGxfZigpIGF0 IGRldmZzX2lvY3RsX2YrMHg3YQprZXJuX2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweGJlCmlv Y3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxsZW50ZXIoKSBhdCBzeXNjYWxsZW50ZXIrMHgx YWEKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHg0YwpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rf c3lzY2FsbCsweGUyCi0tLSBzeXNjYWxsICg1NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwpLCBy aXAgPSAweDgwMTIwODc3YywgcnNwID0gMHg3ZmZmZmZmZjhhYjgsIHJicCA9IDB4N2ZmZmZm ZmY4YjIwIC0tLQpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmMDE0MjIxMjEw MCBzYS0+c2FfbG9jayAoc2EtPnNhX2xvY2spIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZz Ly4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy9zYS5j OjE1NDYKIDJuZCAweGZmZmZmZjAxNDI1MWM2NjAgb3MtPm9zX2xvY2sgKG9zLT5vc19sb2Nr KSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNv bGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZG5vZGUuYzoxMjI4CktEQjogc3RhY2sgYmFja3Ry YWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIr MHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0 bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODA3Cl9zeF94bG9j aygpIGF0IF9zeF94bG9jaysweDU1CmRub2RlX3NldGRpcnR5KCkgYXQgZG5vZGVfc2V0ZGly dHkrMHhjOQpkYnVmX2RpcnR5KCkgYXQgZGJ1Zl9kaXJ0eSsweDU5MwptemFwX2NyZWF0ZV9p bXBsKCkgYXQgbXphcF9jcmVhdGVfaW1wbCsweDgwCnphcF9jcmVhdGVfbm9ybSgpIGF0IHph cF9jcmVhdGVfbm9ybSsweDQzCnNhX2F0dHJfcmVnaXN0ZXJfc3luYygpIGF0IHNhX2F0dHJf cmVnaXN0ZXJfc3luYysweDE5YgpzYV9yZXBsYWNlX2FsbF9ieV90ZW1wbGF0ZV9sb2NrZWQo KSBhdCBzYV9yZXBsYWNlX2FsbF9ieV90ZW1wbGF0ZV9sb2NrZWQrMHg0MQpzYV9yZXBsYWNl X2FsbF9ieV90ZW1wbGF0ZSgpIGF0IHNhX3JlcGxhY2VfYWxsX2J5X3RlbXBsYXRlKzB4NGIK emZzX21rbm9kZSgpIGF0IHpmc19ta25vZGUrMHg1NDgKemZzX2NyZWF0ZV9mcygpIGF0IHpm c19jcmVhdGVfZnMrMHg1MmQKZHNsX3Bvb2xfY3JlYXRlKCkgYXQgZHNsX3Bvb2xfY3JlYXRl KzB4MjAxCnNwYV9jcmVhdGUoKSBhdCBzcGFfY3JlYXRlKzB4NGE4Cnpmc19pb2NfcG9vbF9j cmVhdGUoKSBhdCB6ZnNfaW9jX3Bvb2xfY3JlYXRlKzB4MWMyCnpmc2Rldl9pb2N0bCgpIGF0 IHpmc2Rldl9pb2N0bCsweGE0CmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4 N2EKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhiZQppb2N0bCgpIGF0IGlvY3RsKzB4 ZmQKc3lzY2FsbGVudGVyKCkgYXQgc3lzY2FsbGVudGVyKzB4MWFhCnN5c2NhbGwoKSBhdCBz eXNjYWxsKzB4NGMKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMgotLS0g c3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDEyMDg3N2Ms IHJzcCA9IDB4N2ZmZmZmZmY4YWI4LCByYnAgPSAweDdmZmZmZmZmOGIyMCAtLS0KbG9jayBv cmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZmZjAxNDkxOWQ5NTAgZGItPmRiX210eCAoZGIt PmRiX210eCkgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmli L29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL2RidWYuYzoyMDA5CiAybmQgMHhmZmZm ZmYwMTQyMjEyMTAwIHNhLT5zYV9sb2NrIChzYS0+c2FfbG9jaykgQCAvdXNyL3NyYy9zeXMv bW9kdWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24v ZnMvemZzL3NhLmM6MTI5MgpLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93 cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdn ZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisweDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0 IHdpdG5lc3NfY2hlY2tvcmRlcisweDgwNwpfc3hfeGxvY2soKSBhdCBfc3hfeGxvY2srMHg1 NQpzYV9pZHhfdGFiX3JlbGUoKSBhdCBzYV9pZHhfdGFiX3JlbGUrMHg0MQpzYV90ZWFyX2Rv d24oKSBhdCBzYV90ZWFyX2Rvd24rMHg5MgpkbXVfb2Jqc2V0X2V2aWN0KCkgYXQgZG11X29i anNldF9ldmljdCsweDliCmRzbF9kYXRhc2V0X2V2aWN0KCkgYXQgZHNsX2RhdGFzZXRfZXZp Y3QrMHg0NgpkYnVmX2V2aWN0X3VzZXIoKSBhdCBkYnVmX2V2aWN0X3VzZXIrMHg1NQpkYnVm X3JlbGVfYW5kX3VubG9jaygpIGF0IGRidWZfcmVsZV9hbmRfdW5sb2NrKzB4MTU0CmRzbF9w b29sX3N5bmNfZG9uZSgpIGF0IGRzbF9wb29sX3N5bmNfZG9uZSsweDVlCnNwYV9zeW5jKCkg YXQgc3BhX3N5bmMrMHg2OTUKdHhnX3N5bmNfdGhyZWFkKCkgYXQgdHhnX3N5bmNfdGhyZWFk KzB4MTQ3CmZvcmtfZXhpdCgpIGF0IGZvcmtfZXhpdCsweDEyYQpmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUrMHhlCi0tLSB0cmFwIDAsIHJpcCA9IDAsIHJzcCA9IDB4 ZmZmZmZmODBlZTQwY2NmMCwgcmJwID0gMCAtLS0KbG9jayBvcmRlciByZXZlcnNhbDoKIDFz dCAweGZmZmZmZjAxNDkxOWQ5NTAgZGItPmRiX210eCAoZGItPmRiX210eCkgQCAvdXNyL3Ny Yy9zeXMvbW9kdWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9j b21tb24vZnMvemZzL2RidWYuYzoyMDA5CiAybmQgMHhmZmZmZmYwMTQ5MGNiNzY4IGRuLT5k bl9kYnVmc19tdHggKGRuLT5kbl9kYnVmc19tdHgpIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMv emZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy9k bm9kZV9zeW5jLmM6Mzg0CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dy YXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dl cigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0bmVzc19jaGVja29yZGVyKCkgYXQg d2l0bmVzc19jaGVja29yZGVyKzB4ODA3Cl9zeF94bG9jaygpIGF0IF9zeF94bG9jaysweDU1 CmRub2RlX2V2aWN0X2RidWZzKCkgYXQgZG5vZGVfZXZpY3RfZGJ1ZnMrMHg1NwpkbXVfb2Jq c2V0X2V2aWN0X2RidWZzKCkgYXQgZG11X29ianNldF9ldmljdF9kYnVmcysweGQ0CmRtdV9v YmpzZXRfZXZpY3QoKSBhdCBkbXVfb2Jqc2V0X2V2aWN0KzB4YTMKZHNsX2RhdGFzZXRfZXZp Y3QoKSBhdCBkc2xfZGF0YXNldF9ldmljdCsweDQ2CmRidWZfZXZpY3RfdXNlcigpIGF0IGRi dWZfZXZpY3RfdXNlcisweDU1CmRidWZfcmVsZV9hbmRfdW5sb2NrKCkgYXQgZGJ1Zl9yZWxl X2FuZF91bmxvY2srMHgxNTQKZHNsX3Bvb2xfc3luY19kb25lKCkgYXQgZHNsX3Bvb2xfc3lu Y19kb25lKzB4NWUKc3BhX3N5bmMoKSBhdCBzcGFfc3luYysweDY5NQp0eGdfc3luY190aHJl YWQoKSBhdCB0eGdfc3luY190aHJlYWQrMHgxNDcKZm9ya19leGl0KCkgYXQgZm9ya19leGl0 KzB4MTJhCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweGUKLS0tIHRy YXAgMCwgcmlwID0gMCwgcnNwID0gMHhmZmZmZmY4MGVlNDBjY2YwLCByYnAgPSAwIC0tLQps b2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmMDE0OTE5ZDk1MCBkYi0+ZGJfbXR4 IChkYi0+ZGJfbXR4KSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2Nv bnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZGJ1Zi5jOjIwMDkKIDJuZCAw eGZmZmZmZjAxNDkwY2I0MjggZG4tPmRuX3N0cnVjdF9yd2xvY2sgKGRuLT5kbl9zdHJ1Y3Rf cndsb2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIv b3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZG5vZGVfc3luYy5jOjQyNApLREI6IHN0 YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2Vs Zl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dl cisweDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDgw Nwpfc3hfeGxvY2soKSBhdCBfc3hfeGxvY2srMHg1NQpkbm9kZV9ldmljdF9kYnVmcygpIGF0 IGRub2RlX2V2aWN0X2RidWZzKzB4MWQ4CmRtdV9vYmpzZXRfZXZpY3RfZGJ1ZnMoKSBhdCBk bXVfb2Jqc2V0X2V2aWN0X2RidWZzKzB4ZDQKZG11X29ianNldF9ldmljdCgpIGF0IGRtdV9v YmpzZXRfZXZpY3QrMHhhMwpkc2xfZGF0YXNldF9ldmljdCgpIGF0IGRzbF9kYXRhc2V0X2V2 aWN0KzB4NDYKZGJ1Zl9ldmljdF91c2VyKCkgYXQgZGJ1Zl9ldmljdF91c2VyKzB4NTUKZGJ1 Zl9yZWxlX2FuZF91bmxvY2soKSBhdCBkYnVmX3JlbGVfYW5kX3VubG9jaysweDE1NApkc2xf cG9vbF9zeW5jX2RvbmUoKSBhdCBkc2xfcG9vbF9zeW5jX2RvbmUrMHg1ZQpzcGFfc3luYygp IGF0IHNwYV9zeW5jKzB4Njk1CnR4Z19zeW5jX3RocmVhZCgpIGF0IHR4Z19zeW5jX3RocmVh ZCsweDE0Nwpmb3JrX2V4aXQoKSBhdCBmb3JrX2V4aXQrMHgxMmEKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lKzB4ZQotLS0gdHJhcCAwLCByaXAgPSAwLCByc3AgPSAw eGZmZmZmZjgwZWU0MGNjZjAsIHJicCA9IDAgLS0tClNvbGFyaXMoY29udCk6ICFjcmVhdGVk IHZlcnNpb24gMjggcG9vbCByZWMxIHVzaW5nIDI4CmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAx c3QgMHhmZmZmZmYwMTJlMWQ4MzEwIHpmcyAoemZzKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVz L3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy9nZnMu Yzo0ODgKIDJuZCAweGZmZmZmZjAxNDJkYjIzNTAgemZzdmZzLT56X2hvbGRfbXR4W2ldICh6 ZnN2ZnMtPnpfaG9sZF9tdHhbaV0pIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4u L2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96ZnNfem5vZGUu YzoxMTE2CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBh dCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93 aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19j aGVja29yZGVyKzB4ODA3Cl9zeF94bG9jaygpIGF0IF9zeF94bG9jaysweDU1Cnpmc196Z2V0 KCkgYXQgemZzX3pnZXQrMHgyNDEKemZzX3Jvb3QoKSBhdCB6ZnNfcm9vdCsweDUwCnpmc2N0 bF9jcmVhdGUoKSBhdCB6ZnNjdGxfY3JlYXRlKzB4ODEKemZzX21vdW50KCkgYXQgemZzX21v dW50KzB4NWY0CnZmc19kb25tb3VudCgpIGF0IHZmc19kb25tb3VudCsweGNkZQpubW91bnQo KSBhdCBubW91bnQrMHg2MwpzeXNjYWxsZW50ZXIoKSBhdCBzeXNjYWxsZW50ZXIrMHgxYWEK c3lzY2FsbCgpIGF0IHN5c2NhbGwrMHg0YwpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lz Y2FsbCsweGUyCi0tLSBzeXNjYWxsICgzNzgsIEZyZWVCU0QgRUxGNjQsIG5tb3VudCksIHJp cCA9IDB4ODAxMTY3ZTNjLCByc3AgPSAweDdmZmZmZmZmOWIwOCwgcmJwID0gMHg4MDE4ODcx MGMgLS0tCnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6Mzg0WzFdOiBGb3VuZCBwcm92aWRlciBi eSBuYW1lIC9kZXYvZGE0Lgp2ZGV2X2dlb21fYXR0YWNoOjk1WzFdOiBBdHRhY2hpbmcgdG8g ZGE0Lgp2ZGV2X2dlb21fYXR0YWNoOjEzNlsxXTogQ3JlYXRlZCBjb25zdW1lciBmb3IgZGE0 Lgpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmMDE0MmUxYTkwMCBsLT5sX3J3 bG9jayAobC0+bF9yd2xvY2spIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2Nk ZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96YXAuYzo1MjIKIDJu ZCAweGZmZmZmZjAxNDJjNWI4NTAgZG4tPmRuX3N0cnVjdF9yd2xvY2sgKGRuLT5kbl9zdHJ1 Y3Rfcndsb2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRy aWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZGJ1Zi5jOjYxMQpLREI6IHN0YWNr IGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93 cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisw eDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDgwNwpf c3hfc2xvY2soKSBhdCBfc3hfc2xvY2srMHg1NQpkYnVmX3JlYWQoKSBhdCBkYnVmX3JlYWQr MHgzMTkKZGJ1Zl93aWxsX2RpcnR5KCkgYXQgZGJ1Zl93aWxsX2RpcnR5KzB4ODAKemFwX2dl dF9sZWFmX2J5YmxrKCkgYXQgemFwX2dldF9sZWFmX2J5YmxrKzB4MWRkCnphcF9kZXJlZl9s ZWFmKCkgYXQgemFwX2RlcmVmX2xlYWYrMHhiNgpmemFwX3VwZGF0ZSgpIGF0IGZ6YXBfdXBk YXRlKzB4YzcKemFwX3VwZGF0ZSgpIGF0IHphcF91cGRhdGUrMHgyMDIKc2FfYWRkX2xheW91 dF9lbnRyeSgpIGF0IHNhX2FkZF9sYXlvdXRfZW50cnkrMHgxMTYKc2FfZmluZF9sYXlvdXQo KSBhdCBzYV9maW5kX2xheW91dCsweDE0MgpzYV9idWlsZF9sYXlvdXRzKCkgYXQgc2FfYnVp bGRfbGF5b3V0cysweDVkMQpzYV9yZXBsYWNlX2FsbF9ieV90ZW1wbGF0ZSgpIGF0IHNhX3Jl cGxhY2VfYWxsX2J5X3RlbXBsYXRlKzB4NGIKemZzX21rbm9kZSgpIGF0IHpmc19ta25vZGUr MHg1NDgKemZzX2NyZWF0ZV9mcygpIGF0IHpmc19jcmVhdGVfZnMrMHg1MmQKZHNsX3Bvb2xf Y3JlYXRlKCkgYXQgZHNsX3Bvb2xfY3JlYXRlKzB4MjAxCnNwYV9jcmVhdGUoKSBhdCBzcGFf Y3JlYXRlKzB4NGE4Cnpmc19pb2NfcG9vbF9jcmVhdGUoKSBhdCB6ZnNfaW9jX3Bvb2xfY3Jl YXRlKzB4MWMyCnpmc2Rldl9pb2N0bCgpIGF0IHpmc2Rldl9pb2N0bCsweGE0CmRldmZzX2lv Y3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4N2EKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9j dGwrMHhiZQppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbGVudGVyKCkgYXQgc3lzY2Fs bGVudGVyKzB4MWFhCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4NGMKWGZhc3Rfc3lzY2FsbCgp IGF0IFhmYXN0X3N5c2NhbGwrMHhlMgotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQs IGlvY3RsKSwgcmlwID0gMHg4MDEyMDg3N2MsIHJzcCA9IDB4N2ZmZmZmZmY4YWI4LCByYnAg PSAweDdmZmZmZmZmOGIyMCAtLS0KU29sYXJpcyhjb250KTogIWNyZWF0ZWQgdmVyc2lvbiAy OCBwb29sIHJlYzIgdXNpbmcgMjgKbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZm ZjAxMjMyNjJmNjggZHAtPmRwX2NvbmZpZ19yd2xvY2sgKGRwLT5kcF9jb25maWdfcndsb2Nr KSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNv bGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZHNsX3N5bmN0YXNrLmM6MTg0CiAybmQgMHhmZmZm ZmYwMTQyNTBhMjAwIGRzLT5kc19vcGVuaW5nX2xvY2sgKGRzLT5kc19vcGVuaW5nX2xvY2sp IEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29s YXJpcy91dHMvY29tbW9uL2ZzL3pmcy9kbXVfb2Jqc2V0LmM6NDIyCktEQjogc3RhY2sgYmFj a3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBw ZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUK d2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODA3Cl9zeF94 bG9jaygpIGF0IF9zeF94bG9jaysweDU1CmRtdV9vYmpzZXRfZnJvbV9kcygpIGF0IGRtdV9v YmpzZXRfZnJvbV9kcysweDNlCmRtdV9vYmpzZXRfY3JlYXRlX2ltcGwoKSBhdCBkbXVfb2Jq c2V0X2NyZWF0ZV9pbXBsKzB4NDUKZG11X29ianNldF9jcmVhdGVfc3luYygpIGF0IGRtdV9v YmpzZXRfY3JlYXRlX3N5bmMrMHhkOApkc2xfc3luY190YXNrX2dyb3VwX3N5bmMoKSBhdCBk c2xfc3luY190YXNrX2dyb3VwX3N5bmMrMHgxNTUKZHNsX3Bvb2xfc3luYygpIGF0IGRzbF9w b29sX3N5bmMrMHgyNjMKc3BhX3N5bmMoKSBhdCBzcGFfc3luYysweDMzZgp0eGdfc3luY190 aHJlYWQoKSBhdCB0eGdfc3luY190aHJlYWQrMHgxNDcKZm9ya19leGl0KCkgYXQgZm9ya19l eGl0KzB4MTJhCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweGUKLS0t IHRyYXAgMCwgcmlwID0gMCwgcnNwID0gMHhmZmZmZmY4MGVlNDBjY2YwLCByYnAgPSAwIC0t LQpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmMDEwMDMyZjM4OCB6cC0+el9u YW1lX2xvY2sgKHpwLT56X25hbWVfbG9jaykgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMv Li4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL3pmc19k aXIuYzoyMjAKIDJuZCAweGZmZmZmZjAxNDJkYjIzZDAgemZzdmZzLT56X2hvbGRfbXR4W2ld ICh6ZnN2ZnMtPnpfaG9sZF9tdHhbaV0pIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4u Ly4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96ZnNfem5v ZGUuYzo4MTkKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigp IGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQg X3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNz X2NoZWNrb3JkZXIrMHg4MDcKX3N4X3hsb2NrKCkgYXQgX3N4X3hsb2NrKzB4NTUKemZzX21r bm9kZSgpIGF0IHpmc19ta25vZGUrMHgxNTcKemZzX2ZyZWVic2RfbWtkaXIoKSBhdCB6ZnNf ZnJlZWJzZF9ta2RpcisweDRmZQpWT1BfTUtESVJfQVBWKCkgYXQgVk9QX01LRElSX0FQVisw eGI5Cmtlcm5fbWtkaXJhdCgpIGF0IGtlcm5fbWtkaXJhdCsweDI3MApzeXNjYWxsZW50ZXIo KSBhdCBzeXNjYWxsZW50ZXIrMHgxYWEKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHg0YwpYZmFz dF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUyCi0tLSBzeXNjYWxsICgxMzYsIEZy ZWVCU0QgRUxGNjQsIG1rZGlyKSwgcmlwID0gMHg4MDEwZjQzYWMsIHJzcCA9IDB4N2ZmZmZm ZmZkNzU4LCByYnAgPSAweDgwMTg5NzA2MCAtLS0KbG9jayBvcmRlciByZXZlcnNhbDoKIDFz dCAweGZmZmZmZjAxNDJkYjIyMDAgemZzdmZzLT56X3RlYXJkb3duX2luYWN0aXZlX2xvY2sg KHpmc3Zmcy0+el90ZWFyZG93bl9pbmFjdGl2ZV9sb2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1 bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96 ZnMvemZzX3Zub3BzLmM6NDUwMwogMm5kIDB4ZmZmZmZmMDE0MmRiMjNkMCB6ZnN2ZnMtPnpf aG9sZF9tdHhbaV0gKHpmc3Zmcy0+el9ob2xkX210eFtpXSkgQCAvdXNyL3NyYy9zeXMvbW9k dWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMv emZzL3pmc196bm9kZS5jOjEzNDUKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3Nl bGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCl93aXRuZXNzX2Rl YnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIo KSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MDcKX3N4X3hsb2NrKCkgYXQgX3N4X3hsb2Nr KzB4NTUKemZzX3ppbmFjdGl2ZSgpIGF0IHpmc196aW5hY3RpdmUrMHg4Ygp6ZnNfaW5hY3Rp dmUoKSBhdCB6ZnNfaW5hY3RpdmUrMHg3ZQp6ZnNfZnJlZWJzZF9pbmFjdGl2ZSgpIGF0IHpm c19mcmVlYnNkX2luYWN0aXZlKzB4MWEKVk9QX0lOQUNUSVZFX0FQVigpIGF0IFZPUF9JTkFD VElWRV9BUFYrMHhiNQp2aW5hY3RpdmUoKSBhdCB2aW5hY3RpdmUrMHg5MAp2cHV0eCgpIGF0 IHZwdXR4KzB4MmRjCmtlcm5fbWtkaXJhdCgpIGF0IGtlcm5fbWtkaXJhdCsweDJmMApzeXNj YWxsZW50ZXIoKSBhdCBzeXNjYWxsZW50ZXIrMHgxYWEKc3lzY2FsbCgpIGF0IHN5c2NhbGwr MHg0YwpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUyCi0tLSBzeXNjYWxs ICgxMzYsIEZyZWVCU0QgRUxGNjQsIG1rZGlyKSwgcmlwID0gMHg4MDEwZjQzYWMsIHJzcCA9 IDB4N2ZmZmZmZmZkNzU4LCByYnAgPSAweDgwMTg5NzA2MCAtLS0KbG9jayBvcmRlciByZXZl cnNhbDoKIDFzdCAweGZmZmZmZjAxMjMxZjcwOTggemZzICh6ZnMpIEAgL3Vzci9zcmMvc3lz L2tlcm4vdmZzX21vdW50LmM6MTE5OQogMm5kIDB4ZmZmZmZmMDEyMzJiZDgwMCBzeW5jZXIg KHN5bmNlcikgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIyMjQKS0RCOiBzdGFj ayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZf d3JhcHBlcisweDJhCl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIr MHgyZQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MDcK X19sb2NrbWdyX2FyZ3MoKSBhdCBfX2xvY2ttZ3JfYXJncysweGQ1Mwp2b3Bfc3RkbG9jaygp IGF0IHZvcF9zdGRsb2NrKzB4MzkKVk9QX0xPQ0sxX0FQVigpIGF0IFZPUF9MT0NLMV9BUFYr MHg5Ygpfdm5fbG9jaygpIGF0IF92bl9sb2NrKzB4NTcKdnB1dHgoKSBhdCB2cHV0eCsweDJm ZQpkb3VubW91bnQoKSBhdCBkb3VubW91bnQrMHgyYWIKdW5tb3VudCgpIGF0IHVubW91bnQr MHgyN2UKc3lzY2FsbGVudGVyKCkgYXQgc3lzY2FsbGVudGVyKzB4MWFhCnN5c2NhbGwoKSBh dCBzeXNjYWxsKzB4NGMKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMgot LS0gc3lzY2FsbCAoMjIsIEZyZWVCU0QgRUxGNjQsIHVubW91bnQpLCByaXAgPSAweDgwMTA2 MzM1YywgcnNwID0gMHg3ZmZmZmZmZmM1YzgsIHJicCA9IDB4ODAxODEwODAwIC0tLQpsb2Nr IG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmMDEyMjljYmQ5MCBkcy0+ZHNfbG9jayAo ZHMtPmRzX2xvY2spIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29u dHJpYi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy9kc2xfZGF0YXNldC5jOjM1NDcK IDJuZCAweGZmZmZmZjAxNDkwYjI0MjggZG4tPmRuX3N0cnVjdF9yd2xvY2sgKGRuLT5kbl9z dHJ1Y3Rfcndsb2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2Nv bnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZGJ1Zi5jOjYxMQpLREI6IHN0 YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2Vs Zl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dl cisweDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDgw Nwpfc3hfc2xvY2soKSBhdCBfc3hfc2xvY2srMHg1NQpkYnVmX3JlYWQoKSBhdCBkYnVmX3Jl YWQrMHgzMTkKZGJ1Zl93aWxsX2RpcnR5KCkgYXQgZGJ1Zl93aWxsX2RpcnR5KzB4ODAKZHNs X2RhdGFzZXRfdXNlcl9ob2xkX3N5bmMoKSBhdCBkc2xfZGF0YXNldF91c2VyX2hvbGRfc3lu YysweDEzYwpkc2xfc3luY190YXNrX2dyb3VwX3N5bmMoKSBhdCBkc2xfc3luY190YXNrX2dy b3VwX3N5bmMrMHgxNTUKZHNsX3Bvb2xfc3luYygpIGF0IGRzbF9wb29sX3N5bmMrMHgyNjMK c3BhX3N5bmMoKSBhdCBzcGFfc3luYysweDMzZgp0eGdfc3luY190aHJlYWQoKSBhdCB0eGdf c3luY190aHJlYWQrMHgxNDcKZm9ya19leGl0KCkgYXQgZm9ya19leGl0KzB4MTJhCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweGUKLS0tIHRyYXAgMCwgcmlwID0g MCwgcnNwID0gMHhmZmZmZmY4MGVlNDBjY2YwLCByYnAgPSAwIC0tLQpsb2NrIG9yZGVyIHJl dmVyc2FsOgogMXN0IDB4ZmZmZmZmMDEyMjljYmQ5MCBkcy0+ZHNfbG9jayAoZHMtPmRzX2xv Y2spIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVu c29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy9kc2xfZGF0YXNldC5jOjM1NDcKIDJuZCAweGZm ZmZmZjAxNDJjOGIyZTggZGItPmRiX210eCAoZGItPmRiX210eCkgQCAvdXNyL3NyYy9zeXMv bW9kdWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24v ZnMvemZzL2RidWYuYzoxMDMyCktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxm X3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1 Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MmUKd2l0bmVzc19jaGVja29yZGVyKCkg YXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODA3Cl9zeF94bG9jaygpIGF0IF9zeF94bG9jaysw eDU1CmRidWZfZGlydHkoKSBhdCBkYnVmX2RpcnR5KzB4YzcKZHNsX2RhdGFzZXRfdXNlcl9o b2xkX3N5bmMoKSBhdCBkc2xfZGF0YXNldF91c2VyX2hvbGRfc3luYysweDEzYwpkc2xfc3lu Y190YXNrX2dyb3VwX3N5bmMoKSBhdCBkc2xfc3luY190YXNrX2dyb3VwX3N5bmMrMHgxNTUK ZHNsX3Bvb2xfc3luYygpIGF0IGRzbF9wb29sX3N5bmMrMHgyNjMKc3BhX3N5bmMoKSBhdCBz cGFfc3luYysweDMzZgp0eGdfc3luY190aHJlYWQoKSBhdCB0eGdfc3luY190aHJlYWQrMHgx NDcKZm9ya19leGl0KCkgYXQgZm9ya19leGl0KzB4MTJhCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZSsweGUKLS0tIHRyYXAgMCwgcmlwID0gMCwgcnNwID0gMHhmZmZm ZmY4MGVlNDBjY2YwLCByYnAgPSAwIC0tLQpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4 ZmZmZmZmMDEyMjljYmQ5MCBkcy0+ZHNfbG9jayAoZHMtPmRzX2xvY2spIEAgL3Vzci9zcmMv c3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMvY29t bW9uL2ZzL3pmcy9kc2xfZGF0YXNldC5jOjM1NDcKIDJuZCAweGZmZmZmZjAxNDkwYjI1MTAg ZG4tPmRuX210eCAoZG4tPmRuX210eCkgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMvLi4v Li4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL2RidWYuYzox MTg5CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBk Yl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRu ZXNzX2RlYnVnZ2VyKzB4MmUKd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVj a29yZGVyKzB4ODA3Cl9zeF94bG9jaygpIGF0IF9zeF94bG9jaysweDU1CmRidWZfZGlydHko KSBhdCBkYnVmX2RpcnR5KzB4YjA1CmRzbF9kYXRhc2V0X3VzZXJfaG9sZF9zeW5jKCkgYXQg ZHNsX2RhdGFzZXRfdXNlcl9ob2xkX3N5bmMrMHgxM2MKZHNsX3N5bmNfdGFza19ncm91cF9z eW5jKCkgYXQgZHNsX3N5bmNfdGFza19ncm91cF9zeW5jKzB4MTU1CmRzbF9wb29sX3N5bmMo KSBhdCBkc2xfcG9vbF9zeW5jKzB4MjYzCnNwYV9zeW5jKCkgYXQgc3BhX3N5bmMrMHgzM2YK dHhnX3N5bmNfdGhyZWFkKCkgYXQgdHhnX3N5bmNfdGhyZWFkKzB4MTQ3CmZvcmtfZXhpdCgp IGF0IGZvcmtfZXhpdCsweDEyYQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUrMHhlCi0tLSB0cmFwIDAsIHJpcCA9IDAsIHJzcCA9IDB4ZmZmZmZmODBlZTQwY2NmMCwg cmJwID0gMCAtLS0KbG9jayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZmZjAxMjI5Y2Jk OTAgZHMtPmRzX2xvY2sgKGRzLT5kc19sb2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pm cy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZHNs X2RhdGFzZXQuYzozNTQ3CiAybmQgMHhmZmZmZmYwMTIyOTc2MjYwIG9zLT5vc19sb2NrIChv cy0+b3NfbG9jaykgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMvLi4vLi4vY2RkbC9jb250 cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL2Rub2RlLmM6MTIyOApLREI6IHN0 YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2Vs Zl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIoKSBhdCBfd2l0bmVzc19kZWJ1Z2dl cisweDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDgw Nwpfc3hfeGxvY2soKSBhdCBfc3hfeGxvY2srMHg1NQpkbm9kZV9zZXRkaXJ0eSgpIGF0IGRu b2RlX3NldGRpcnR5KzB4YzkKZGJ1Zl9kaXJ0eSgpIGF0IGRidWZfZGlydHkrMHg1OTMKZHNs X2RhdGFzZXRfdXNlcl9ob2xkX3N5bmMoKSBhdCBkc2xfZGF0YXNldF91c2VyX2hvbGRfc3lu YysweDEzYwpkc2xfc3luY190YXNrX2dyb3VwX3N5bmMoKSBhdCBkc2xfc3luY190YXNrX2dy b3VwX3N5bmMrMHgxNTUKZHNsX3Bvb2xfc3luYygpIGF0IGRzbF9wb29sX3N5bmMrMHgyNjMK c3BhX3N5bmMoKSBhdCBzcGFfc3luYysweDMzZgp0eGdfc3luY190aHJlYWQoKSBhdCB0eGdf c3luY190aHJlYWQrMHgxNDcKZm9ya19leGl0KCkgYXQgZm9ya19leGl0KzB4MTJhCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweGUKLS0tIHRyYXAgMCwgcmlwID0g MCwgcnNwID0gMHhmZmZmZmY4MGVlNDBjY2YwLCByYnAgPSAwIC0tLQpsb2NrIG9yZGVyIHJl dmVyc2FsOgogMXN0IDB4ZmZmZmZmMDEyMjljYmQ5MCBkcy0+ZHNfbG9jayAoZHMtPmRzX2xv Y2spIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVu c29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy9kc2xfZGF0YXNldC5jOjM1NDcKIDJuZCAweGZm ZmZmZjAxMjI5NzYyMzggb3MtPm9zX29ial9sb2NrIChvcy0+b3Nfb2JqX2xvY2spIEAgL3Vz ci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91 dHMvY29tbW9uL2ZzL3pmcy9kbXVfb2JqZWN0LmM6NDAKS0RCOiBzdGFjayBiYWNrdHJhY2U6 CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJh Cl93aXRuZXNzX2RlYnVnZ2VyKCkgYXQgX3dpdG5lc3NfZGVidWdnZXIrMHgyZQp3aXRuZXNz X2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNzX2NoZWNrb3JkZXIrMHg4MDcKX3N4X3hsb2NrKCkg YXQgX3N4X3hsb2NrKzB4NTUKZG11X29iamVjdF9hbGxvYygpIGF0IGRtdV9vYmplY3RfYWxs b2MrMHg3MAp6YXBfY3JlYXRlX25vcm0oKSBhdCB6YXBfY3JlYXRlX25vcm0rMHgyZApkc2xf ZGF0YXNldF91c2VyX2hvbGRfc3luYygpIGF0IGRzbF9kYXRhc2V0X3VzZXJfaG9sZF9zeW5j KzB4MTU5CmRzbF9zeW5jX3Rhc2tfZ3JvdXBfc3luYygpIGF0IGRzbF9zeW5jX3Rhc2tfZ3Jv dXBfc3luYysweDE1NQpkc2xfcG9vbF9zeW5jKCkgYXQgZHNsX3Bvb2xfc3luYysweDI2Mwpz cGFfc3luYygpIGF0IHNwYV9zeW5jKzB4MzNmCnR4Z19zeW5jX3RocmVhZCgpIGF0IHR4Z19z eW5jX3RocmVhZCsweDE0Nwpmb3JrX2V4aXQoKSBhdCBmb3JrX2V4aXQrMHgxMmEKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4ZQotLS0gdHJhcCAwLCByaXAgPSAw LCByc3AgPSAweGZmZmZmZjgwZWU0MGNjZjAsIHJicCA9IDAgLS0tCmxvY2sgb3JkZXIgcmV2 ZXJzYWw6CiAxc3QgMHhmZmZmZmYwMDA4ZDI0ODAwIHVmcyAodWZzKSBAIC91c3Ivc3JjL3N5 cy9rZXJuL3Zmc19tb3VudC5jOjExOTkKIDJuZCAweGZmZmZmZjAxMjMxZjdjZjAgc3luY2Vy IChzeW5jZXIpIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMjI0CktEQjogc3Rh Y2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxm X3dyYXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2Vy KzB4MmUKd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODA3 Cl9fbG9ja21ncl9hcmdzKCkgYXQgX19sb2NrbWdyX2FyZ3MrMHhkNTMKdm9wX3N0ZGxvY2so KSBhdCB2b3Bfc3RkbG9jaysweDM5ClZPUF9MT0NLMV9BUFYoKSBhdCBWT1BfTE9DSzFfQVBW KzB4OWIKX3ZuX2xvY2soKSBhdCBfdm5fbG9jaysweDU3CnZwdXR4KCkgYXQgdnB1dHgrMHgy ZmUKZG91bm1vdW50KCkgYXQgZG91bm1vdW50KzB4MmFiCnVubW91bnQoKSBhdCB1bm1vdW50 KzB4MjdlCnN5c2NhbGxlbnRlcigpIGF0IHN5c2NhbGxlbnRlcisweDFhYQpzeXNjYWxsKCkg YXQgc3lzY2FsbCsweDRjClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTIK LS0tIHN5c2NhbGwgKDIyLCBGcmVlQlNEIEVMRjY0LCB1bm1vdW50KSwgcmlwID0gMHg4MDEw NjMzNWMsIHJzcCA9IDB4N2ZmZmZmZmY1NGY4LCByYnAgPSAweDgwMTgxMDgwMCAtLS0KbG9j ayBvcmRlciByZXZlcnNhbDoKIDFzdCAweGZmZmZmZjAxNDIzYzUxOTAgZHMtPmRzX2xvY2sg KGRzLT5kc19sb2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2Nv bnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvZHNsX2RhdGFzZXQuYzozNzEx CiAybmQgMHhmZmZmZmYwMTA3ZDIxMjk4IHphcC0+emFwX3J3bG9jayAoemFwLT56YXBfcnds b2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3Bl bnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvemFwX21pY3JvLmM6NDkwCktEQjogc3RhY2sg YmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dy YXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4 MmUKd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ODA3Cl9z eF9zbG9jaygpIGF0IF9zeF9zbG9jaysweDU1CnphcF9sb2NrZGlyKCkgYXQgemFwX2xvY2tk aXIrMHgxMTEKemFwX2xvb2t1cF9ub3JtKCkgYXQgemFwX2xvb2t1cF9ub3JtKzB4NDUKemFw X2xvb2t1cCgpIGF0IHphcF9sb29rdXArMHgyZQpkc2xfZGF0YXNldF9yZWxlYXNlX21pZ2h0 X2Rlc3Ryb3koKSBhdCBkc2xfZGF0YXNldF9yZWxlYXNlX21pZ2h0X2Rlc3Ryb3krMHhiMApk c2xfZGF0YXNldF91c2VyX3JlbGVhc2Vfb25lKCkgYXQgZHNsX2RhdGFzZXRfdXNlcl9yZWxl YXNlX29uZSsweGE2CmRzbF9kYXRhc2V0X3VzZXJfcmVsZWFzZSgpIGF0IGRzbF9kYXRhc2V0 X3VzZXJfcmVsZWFzZSsweDFiNQpkc2xfZGF0YXNldF91c2VyX3JlbGVhc2VfdG1wKCkgYXQg ZHNsX2RhdGFzZXRfdXNlcl9yZWxlYXNlX3RtcCsweGVlCmRzbF9kYXRhc2V0X3VzZXJfcmVs ZWFzZV9vbmV4aXQoKSBhdCBkc2xfZGF0YXNldF91c2VyX3JlbGVhc2Vfb25leGl0KzB4MjEK emZzX29uZXhpdF9kZXN0cm95KCkgYXQgemZzX29uZXhpdF9kZXN0cm95KzB4NTYKemZzZGV2 X2Nsb3NlKCkgYXQgemZzZGV2X2Nsb3NlKzB4NmIKZGV2ZnNfZGVzdHJveV9jZGV2cHJpdigp IGF0IGRldmZzX2Rlc3Ryb3lfY2RldnByaXYrMHg4YgpfZmRyb3AoKSBhdCBfZmRyb3ArMHgz NQpjbG9zZWYoKSBhdCBjbG9zZWYrMHg1YgprZXJuX2Nsb3NlKCkgYXQga2Vybl9jbG9zZSsw eDExMApzeXNjYWxsZW50ZXIoKSBhdCBzeXNjYWxsZW50ZXIrMHgxYWEKc3lzY2FsbCgpIGF0 IHN5c2NhbGwrMHg0YwpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUyCi0t LSBzeXNjYWxsICg2LCBGcmVlQlNEIEVMRjY0LCBjbG9zZSksIHJpcCA9IDB4ODAxMTAyNzlj LCByc3AgPSAweDdmZmZmZmZmZDYwOCwgcmJwID0gMCAtLS0KbG9jayBvcmRlciByZXZlcnNh bDoKIDFzdCAweGZmZmZmZjAxMzE5YTAyMDAgemZzdmZzLT56X3RlYXJkb3duX2luYWN0aXZl X2xvY2sgKHpmc3Zmcy0+el90ZWFyZG93bl9pbmFjdGl2ZV9sb2NrKSBAIC91c3Ivc3JjL3N5 cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1v bi9mcy96ZnMvemZzX3Zmc29wcy5jOjE3MjcKIDJuZCAweGZmZmZmZjAxMjJhMDc5YzAgZHMt PmRzX3J3bG9jayAoZHMtPmRzX3J3bG9jaykgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy96ZnMv Li4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL2RzbF9k YXRhc2V0LmM6MzIwMApLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFw cGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIo KSBhdCBfd2l0bmVzc19kZWJ1Z2dlcisweDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdp dG5lc3NfY2hlY2tvcmRlcisweDgwNwpfc3hfeGxvY2soKSBhdCBfc3hfeGxvY2srMHg1NQpk c2xfZGF0YXNldF9jbG9uZV9zd2FwKCkgYXQgZHNsX2RhdGFzZXRfY2xvbmVfc3dhcCsweDdj CmRtdV9yZWN2X2VuZCgpIGF0IGRtdV9yZWN2X2VuZCsweDVlCnpmc19pb2NfcmVjdigpIGF0 IHpmc19pb2NfcmVjdisweDgzZQp6ZnNkZXZfaW9jdGwoKSBhdCB6ZnNkZXZfaW9jdGwrMHhh NApkZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNfaW9jdGxfZisweDdhCmtlcm5faW9jdGwoKSBh dCBrZXJuX2lvY3RsKzB4YmUKaW9jdGwoKSBhdCBpb2N0bCsweGZkCnN5c2NhbGxlbnRlcigp IGF0IHN5c2NhbGxlbnRlcisweDFhYQpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDRjClhmYXN0 X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTIKLS0tIHN5c2NhbGwgKDU0LCBGcmVl QlNEIEVMRjY0LCBpb2N0bCksIHJpcCA9IDB4ODAxMTAyNzdjLCByc3AgPSAweDdmZmZmZmZm NTU2OCwgcmJwID0gMHg3ZmZmZmZmZjZjNjAgLS0tCmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAx c3QgMHhmZmZmZmYwMTMxOWEwMjAwIHpmc3Zmcy0+el90ZWFyZG93bl9pbmFjdGl2ZV9sb2Nr ICh6ZnN2ZnMtPnpfdGVhcmRvd25faW5hY3RpdmVfbG9jaykgQCAvdXNyL3NyYy9zeXMvbW9k dWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMv emZzL3pmc192ZnNvcHMuYzoxNzI3CiAybmQgMHhmZmZmZmZmZjgxMTk5NDQwIHNwYV9uYW1l c3BhY2VfbG9jayAoc3BhX25hbWVzcGFjZV9sb2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVz L3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMv c3BhLmM6MjM3NwpLREI6IHN0YWNrIGJhY2t0cmFjZToKZGJfdHJhY2Vfc2VsZl93cmFwcGVy KCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmEKX3dpdG5lc3NfZGVidWdnZXIoKSBh dCBfd2l0bmVzc19kZWJ1Z2dlcisweDJlCndpdG5lc3NfY2hlY2tvcmRlcigpIGF0IHdpdG5l c3NfY2hlY2tvcmRlcisweDgwNwpfc3hfeGxvY2soKSBhdCBfc3hfeGxvY2srMHg1NQpzcGFf b3Blbl9jb21tb24oKSBhdCBzcGFfb3Blbl9jb21tb24rMHg3YQpkc2xfZGlyX29wZW5fc3Bh KCkgYXQgZHNsX2Rpcl9vcGVuX3NwYSsweDNiZQpkc2xfZGF0YXNldF9ob2xkKCkgYXQgZHNs X2RhdGFzZXRfaG9sZCsweDNiCmRzbF9kYXRhc2V0X293bigpIGF0IGRzbF9kYXRhc2V0X293 bisweDJmCmRtdV9vYmpzZXRfb3duKCkgYXQgZG11X29ianNldF9vd24rMHgzNgp6ZnNfcmVz dW1lX2ZzKCkgYXQgemZzX3Jlc3VtZV9mcysweDcwCnpmc19pb2NfcmVjdigpIGF0IHpmc19p b2NfcmVjdisweGQ1MQp6ZnNkZXZfaW9jdGwoKSBhdCB6ZnNkZXZfaW9jdGwrMHhhNApkZXZm c19pb2N0bF9mKCkgYXQgZGV2ZnNfaW9jdGxfZisweDdhCmtlcm5faW9jdGwoKSBhdCBrZXJu X2lvY3RsKzB4YmUKaW9jdGwoKSBhdCBpb2N0bCsweGZkCnN5c2NhbGxlbnRlcigpIGF0IHN5 c2NhbGxlbnRlcisweDFhYQpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDRjClhmYXN0X3N5c2Nh bGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTIKLS0tIHN5c2NhbGwgKDU0LCBGcmVlQlNEIEVM RjY0LCBpb2N0bCksIHJpcCA9IDB4ODAxMTAyNzdjLCByc3AgPSAweDdmZmZmZmZmNTU2OCwg cmJwID0gMHg3ZmZmZmZmZjZjNjAgLS0tCmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAxc3QgMHhm ZmZmZmYwMTMxOWEwMjQwIHpmc3Zmcy0+el96bm9kZXNfbG9jayAoemZzdmZzLT56X3pub2Rl c19sb2NrKSBAIC91c3Ivc3JjL3N5cy9tb2R1bGVzL3pmcy8uLi8uLi9jZGRsL2NvbnRyaWIv b3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvemZzX3Zmc29wcy5jOjIxNTIKIDJuZCAw eGZmZmZmZjAxMzE5YTAzNTAgemZzdmZzLT56X2hvbGRfbXR4W2ldICh6ZnN2ZnMtPnpfaG9s ZF9tdHhbaV0pIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96ZnNfem5vZGUuYzoxMjQ1CktEQjog c3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9z ZWxmX3dyYXBwZXIrMHgyYQpfd2l0bmVzc19kZWJ1Z2dlcigpIGF0IF93aXRuZXNzX2RlYnVn Z2VyKzB4MmUKd2l0bmVzc19jaGVja29yZGVyKCkgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4 ODA3Cl9zeF94bG9jaygpIGF0IF9zeF94bG9jaysweDU1Cnpmc19yZXpnZXQoKSBhdCB6ZnNf cmV6Z2V0KzB4NTgKemZzX3Jlc3VtZV9mcygpIGF0IHpmc19yZXN1bWVfZnMrMHgxZmQKemZz X2lvY19yZWN2KCkgYXQgemZzX2lvY19yZWN2KzB4ZDUxCnpmc2Rldl9pb2N0bCgpIGF0IHpm c2Rldl9pb2N0bCsweGE0CmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4N2EK a2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhiZQppb2N0bCgpIGF0IGlvY3RsKzB4ZmQK c3lzY2FsbGVudGVyKCkgYXQgc3lzY2FsbGVudGVyKzB4MWFhCnN5c2NhbGwoKSBhdCBzeXNj YWxsKzB4NGMKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMgotLS0gc3lz Y2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDExMDI3N2MsIHJz cCA9IDB4N2ZmZmZmZmY1NTY4LCByYnAgPSAweDdmZmZmZmZmNmM2MCAtLS0KcGFuaWM6IHNv bGFyaXMgYXNzZXJ0OiB2cC0+dl9jb3VudCA9PSAxLCBmaWxlOiAvdXNyL3NyYy9zeXMvbW9k dWxlcy96ZnMvLi4vLi4vY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMv emZzL3pmc192bm9wcy5jLCBsaW5lOiA0NTEwCmNwdWlkID0gMgpLREI6IGVudGVyOiBwYW5p YwoKMHhmZmZmZmYwMDA4ZTFjNGYwOiB0YWcgdWZzLCB0eXBlIFZSRUcKICAgIHVzZWNvdW50 IDEsIHdyaXRlY291bnQgMCwgcmVmY291bnQgNDMwNzEgbW91bnRlZGhlcmUgMAogICAgZmxh Z3MgKFZWX1NZU1RFTSkKICAgIGxvY2sgdHlwZSB1ZnM6IEVYQ0wgYnkgdGhyZWFkIDB4ZmZm ZmZmMDAwOGU4MDg4MCAocGlkIDE2MTEpCiMwIDB4ZmZmZmZmZmY4MDU5ZjdjOCBhdCBfX2xv Y2ttZ3JfYXJncysweDc4OAojMSAweGZmZmZmZmZmODA3ZjM3ZjMgYXQgZmZzX3ZnZXRmKzB4 MTYzCiMyIDB4ZmZmZmZmZmY4MDdkMGQ2NyBhdCBmZnNfdmFsbG9jKzB4MTc3CiMzIDB4ZmZm ZmZmZmY4MDgwNDdlNyBhdCB1ZnNfbWFrZWlub2RlKzB4OTcKIzQgMHhmZmZmZmZmZjgwOGI0 ODQzIGF0IFZPUF9DUkVBVEVfQVBWKzB4YjMKIzUgMHhmZmZmZmZmZjgwN2RkNTg0IGF0IGZm c19zbmFwc2hvdCsweDM1NAojNiAweGZmZmZmZmZmODA3ZjUyZGIgYXQgZmZzX21vdW50KzB4 NWViCiM3IDB4ZmZmZmZmZmY4MDY0Njg2ZSBhdCB2ZnNfZG9ubW91bnQrMHhjZGUKIzggMHhm ZmZmZmZmZjgwNjQ4MDkzIGF0IG5tb3VudCsweDYzCiM5IDB4ZmZmZmZmZmY4MDVmNmRmYSBh dCBzeXNjYWxsZW50ZXIrMHgxYWEKIzEwIDB4ZmZmZmZmZmY4MDg1YmM5YyBhdCBzeXNjYWxs KzB4NGMKIzExIDB4ZmZmZmZmZmY4MDg0NjAwMiBhdCBYZmFzdF9zeXNjYWxsKzB4ZTIKCWlu byA0LCBvbiBkZXYgdWZzL1A1NVVENnhVU1IKCjB4ZmZmZmZmMDAwOGQ1ZDc2ODogdGFnIHpm cywgdHlwZSBWRElSCiAgICB1c2Vjb3VudCAwLCB3cml0ZWNvdW50IDAsIHJlZmNvdW50IDEg bW91bnRlZGhlcmUgMAogICAgZmxhZ3MgKFZJX0RPSU5HSU5BQ1QpCiBWSV9MT0NLZWQgICAg bG9jayB0eXBlIHpmczogRVhDTCBieSB0aHJlYWQgMHhmZmZmZmYwMDNkNGVlNDQwIChwaWQg MTcxMSkKIzAgMHhmZmZmZmZmZjgwNTlmN2M4IGF0IF9fbG9ja21ncl9hcmdzKzB4Nzg4CiMx IDB4ZmZmZmZmZmY4MDYzZDBiOSBhdCB2b3Bfc3RkbG9jaysweDM5CiMyIDB4ZmZmZmZmZmY4 MDhiM2FkYiBhdCBWT1BfTE9DSzFfQVBWKzB4OWIKIzMgMHhmZmZmZmZmZjgwNjVhMGM3IGF0 IF92bl9sb2NrKzB4NTcKIzQgMHhmZmZmZmZmZjgwNjQ1MmYzIGF0IGRvdW5tb3VudCsweDkz CiM1IDB4ZmZmZmZmZmY4MDY0NWFlZSBhdCB1bm1vdW50KzB4MjdlCiM2IDB4ZmZmZmZmZmY4 MDVmNmRmYSBhdCBzeXNjYWxsZW50ZXIrMHgxYWEKIzcgMHhmZmZmZmZmZjgwODViYzljIGF0 IHN5c2NhbGwrMHg0YwojOCAweGZmZmZmZmZmODA4NDYwMDIgYXQgWGZhc3Rfc3lzY2FsbCsw eGUyCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcGFuaWMudHh0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADA2MDAAAAAAMAAAAAAAAAAwAAAAAAAAADIx MQAAAAAAAAAAADExNDUyNzczMTI3ACAgNzIyMwAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAAAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAd2hlZWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABzb2xhcmlzIGFzc2VydDogdnAtPnZfY291bnQgPT0gMSwgZmlsZTogL3Vzci9z cmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91dHMv Y29tbW9uL2ZzL3pmcy96ZnNfdm5vcHMuYywgbGluZTogNDUxMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZlcnNpb24udHh0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwNjAwAAAAADAAAAAAAAAAMAAAAAAAAAAxNjcA AAAAAAAAAAAxMTQ1Mjc3MzEyNwAgIDc2MzAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAAAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHdoZWVsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAARnJlZUJTRCA5LjAtQ1VSUkVOVCAjMyByMjEyMDgwTTogRnJpIFNlcCAgMyAxNTo0 MzoyMyBDRFQgMjAxMAogICAgcm9vdEBrcmFrZW4uaG91c2VuZXQuanJ2Oi91c3Ivb2JqL3Vz ci9zcmMvc3lzL0JJR1RFWAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------040405010801000906030309-- From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 07:35:31 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5EA3106566C for ; Wed, 6 Oct 2010 07:35:31 +0000 (UTC) (envelope-from torbjoern@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3567B8FC14 for ; Wed, 6 Oct 2010 07:35:31 +0000 (UTC) Received: by bwz15 with SMTP id 15so6799640bwz.13 for ; Wed, 06 Oct 2010 00:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=qXqmF/eDuGBrclyIH2cM3KJS42bPV0lniFDsz4WqwDc=; b=YYbgYqls75slTUfljqU02QeW7hzu1rBw1QhIkLDzUJPWPaXJlowL++MO5ZLvqNnETC Mjfp6U5a4GRE2XwrCPsFE2/835k4kiGO7CWXmnYacsA/BkR/iJDxRK4VHVpRJbH+bkR8 AEQZ49hcoFcyvpapE3SZzmaThwMIRbivRXbH4= 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=DS4u6Rh+59rqaRidDLKxxvfyE7zcKoEq2iAV4y7ICcmxCqA3+6iUFRXNTdgxpeLN71 FgEbpGh4ANrPKSP264tC8ICGPGFf1KrQO14zfKbmBGnVWAQLxxOz2b1gh/f4KyjUbv6c wtidueqjKWulWH2WlSBp/CUfNbgWy3TOq/Kjc= MIME-Version: 1.0 Received: by 10.204.66.79 with SMTP id m15mr9496891bki.82.1286350529450; Wed, 06 Oct 2010 00:35:29 -0700 (PDT) Received: by 10.204.71.138 with HTTP; Wed, 6 Oct 2010 00:35:29 -0700 (PDT) In-Reply-To: <4CABE9DC.7080601@DataIX.net> References: <162340.85805.qm@web113215.mail.gq1.yahoo.com> <4CABE9DC.7080601@DataIX.net> Date: Wed, 6 Oct 2010 09:35:29 +0200 Message-ID: From: Torbjorn Kristoffersen To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Are any adjustments for ZFS necessary in 8.1 amd64? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 07:35:31 -0000 On Wed, Oct 6, 2010 at 5:15 AM, jhell wrote: > On 10/05/2010 20:50, Trever wrote: >> Apologies if this has been answered previously, but I can't find definit= ive info. >> >> The FBSD handbook recommends a customized loader.conf when using ZFS (fo= r all architectures): >> vm.kmem_size=3D"330M" >> vm.kmem_size_max=3D"330M" >> vfs.zfs.arc_max=3D"40M" >> vfs.zfs.vdev.cache.size=3D"5M" >> >> Is this still true for the 8.1 amd64 release? =A0I've read various place= s that it is not and that handbook is NOT up-to-date. =A0Out of the box, am= d64 8.1 ZFS so far "just works" without any customizations other than to ma= ke sure it turns on at reboot. =A0But systems are fairly quiescent, we have= not gone to production yet. >> >> In addition to the handbook recommendations, are there 8.1 amd64 tunings= that should be done for a vanilla server? =A0(Will be imap server, actuall= y.) >> >> Without tuning as per above, I see this on our systems (sysctl -a): >> vm.kmem_size: 8318648320 >> vm.kmem_size_max: 329853485875 >> vfs.zfs.arc_max: 7244906496 >> vfs.zfs.vdev.cache.size: 10485760 >> >> Our systems have 24 GB of RAM. >> > > With the amount of RAM that you have available in your system I would > not recommend using the above values that you quoted from the Wiki. > Those values from the wiki IIRC were based on a i386 system that has > less than 1G of RAM and were used as an example more than a definitive > tuning to achieve better performance. > > With all the available configurations that are possible with a ZFS based > FreeBSD system I would suggest that you try out the defaults and move > from that point onward before you try tuning for a specific scenario. It > will be best to have a definitive starting point at which you can always > refer back to in your performance testing. > I've got the same setup except 8GB of memory. I'd also like to tune as best as I can, but I'm uncertain of how far I should try to go. It's a production system so I'm playing it a bit careful. Using default settings now, but I'm also interested in better performance. TK From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 08:39:40 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B810106564A for ; Wed, 6 Oct 2010 08:39:40 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id E1F338FC13 for ; Wed, 6 Oct 2010 08:39:39 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id o968OZpg088364; Wed, 6 Oct 2010 03:24:36 -0500 (CDT) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=pvp5DYis/aspSytB4xzqbvQwshN02PqvUfMtiePojOlPCFruo2zH1n0d2mCG7aDTm oK9fs62/8p1v1rQbBSViEsdz/rOLyLhkXQ8FaD8a2CYkw9/mBYd0IjwBvPVgHMoZKIY 8RhxQ8Q0r1H0BE2JZroXuRC4WjuZygDwHUPVQuk= Message-ID: <4CAC3243.6040802@jrv.org> Date: Wed, 06 Oct 2010 03:24:35 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <30455085.1048.1283538007526.JavaMail.root@zimbra> In-Reply-To: <30455085.1048.1283538007526.JavaMail.root@zimbra> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs Subject: ZFS v28 zfs recv leaves filesystems with wrong names X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 08:39:40 -0000 James R. Van Artsdalen wrote: > I get the following assertion with "zfs recv": > > bigback:/root# zfs send -R -I @syssnap-1249124822.2009-08-01.06:07:02.213-30-6 bigtex@syssnap-1254395222.2009-10-01.06:07:02.274-39-4 | ssh kraken zfs recv -dvF bigz > Assertion failed: (!clp->cl_alldependents), file /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c, line 470. I found a simple reproducible test case. The assertion is correct because an earlier "zfs recv" left the datasets with the wrong names. This test case leaves the pool in the wrong state, which causes a later "zfs recv" to assert/fail (the assertion isn't induced by this script since that's not where the bug is). kraken:/root# uname -a FreeBSD kraken.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r212080M: Fri Sep 3 15:43:23 CDT 2010 root@kraken.housenet.jrv:/usr/obj/usr/src/sys/BIGTEX amd64 kraken:/root# cat zt zpool create rec1 da3 zpool create rec2 da4 zfs create rec1/a zfs create rec1/a/b zfs snapshot -r rec1@s1 zfs send -R rec1@s1 | zfs recv -dvuF rec2 zfs rename rec1/a/b rec1/c zfs destroy -r rec1/a zfs create rec1/a zfs rename rec1/c rec1/a/b # if the rename target is anything other than rec1/a/b the "zfs recv" result is right zfs snapshot -r rec1@s2 zfs send -R -I @s1 rec1@s2 | zfs recv -dvuF rec2 kraken:/root# sh -x zt + zpool create rec1 da3 + zpool create rec2 da4 + zfs create rec1/a + zfs create rec1/a/b + zfs snapshot -r rec1@s1 + zfs send -R rec1@s1 + zfs recv -dvuF rec2 receiving full stream of rec1@s1 into rec2@s1 received 47.4KB stream in 2 seconds (23.7KB/sec) receiving full stream of rec1/a@s1 into rec2/a@s1 received 47.9KB stream in 1 seconds (47.9KB/sec) receiving full stream of rec1/a/b@s1 into rec2/a/b@s1 received 46.3KB stream in 1 seconds (46.3KB/sec) + zfs rename rec1/a/b rec1/c + zfs destroy -r rec1/a + zfs create rec1/a + zfs rename rec1/c rec1/a/b + zfs snapshot -r rec1@s2 + zfs send -R -I @s1 rec1@s2 + zfs recv -dvuF rec2 attempting destroy rec2/a@s1 success attempting destroy rec2/a failed - trying rename rec2/a to rec2/recv-2176-1 local fs rec2/a/b new parent not found cannot open 'rec2/a/b': dataset does not exist another pass: attempting destroy rec2/recv-2176-1 failed (0) receiving incremental stream of rec1@s2 into rec2@s2 received 10.8KB stream in 2 seconds (5.41KB/sec) receiving full stream of rec1/a@s2 into rec2/a@s2 received 47.9KB stream in 1 seconds (47.9KB/sec) receiving incremental stream of rec1/a/b@s2 into rec2/recv-2176-1/b@s2 received 312B stream in 2 seconds (156B/sec) local fs rec2/a does not have fromsnap (s1 in stream); must have been deleted locally; ignoring attempting destroy rec2/recv-2176-1 failed (0) kraken:/root# zfs list | grep rec1 rec1 238K 1.78T 32K /rec1 rec1/a 63K 1.78T 32K /rec1/a rec1/a/b 31K 1.78T 31K /rec1/a/b kraken:/root# zfs list | grep rec2 rec2 293K 1.78T 32K /rec2 rec2/a 32K 1.78T 32K /rec2/a rec2/recv-2176-1 64K 1.78T 32K /rec2/recv-2176-1 rec2/recv-2176-1/b 32K 1.78T 31K /rec2/recv-2176-1/b kraken:/root# From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 10:34:40 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80EE1065697 for ; Wed, 6 Oct 2010 10:34:40 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id 891088FC1C for ; Wed, 6 Oct 2010 10:34:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by goat.gigo.com (Postfix) with ESMTP id 5427811624 for ; Wed, 6 Oct 2010 03:34:40 -0700 (PDT) Received: from goat.gigo.com ([127.0.0.1]) by localhost (vette.gigo.com [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id iGr8uw-Zr646 for ; Wed, 6 Oct 2010 03:34:40 -0700 (PDT) Received: from 200.181.39.170 (200-181-39-170.bsace702.dsl.brasiltelecom.net.br [200.181.39.170]) by goat.gigo.com (Postfix) with ESMTPSA id 3A27811618 for ; Wed, 6 Oct 2010 03:34:39 -0700 (PDT) Received: (qmail 48371 invoked from network); 6 Oct 2010 07:32:47 -0300 Received: from unknown (HELO exxodus.fedaykin.here) (127.0.0.1) by exxodus.fedaykin.here with SMTP; 6 Oct 2010 07:32:47 -0300 Message-ID: <4CAC5067.3090106@uol.com.br> Date: Wed, 06 Oct 2010 07:32:47 -0300 From: Mario Sergio Fujikawa Ferreira User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; pt-BR; rv:1.9.1.12) Gecko/20101005 Thunderbird/3.0.8 MIME-Version: 1.0 To: Paul B Mahol References: <20101006005350.62837.qmail@exxodus.fedaykin.here> (sfid-20101006_00540_26A53ED6) In-Reply-To: (sfid-20101006_00540_26A53ED6) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Panic with msdosfs vs 1.3TB FAT32 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 10:34:40 -0000 On 06/10/2010 00:36, Paul B Mahol wrote: > On 10/6/10, Mario Sergio Fujikawa Ferreira wrote: >> Hi, >> >> I mounted a 1.3TB FAT32 (32k cluster) filesystem on esata >> /dev/ada4s1 under /media/esata/ with the '-l' (large option). >> >> I tried to create a directory and files but got errors: >> >> ------ >> >> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >> >> ------ >> >> Then, I tried unmounting the filesystem which resulted on >> >> ------ >> >> fsync: giving up on dirty >> 0xffffff01bad6e1d8: tag devfs, type VCHR >> usecount 1, writecount 0, refcount 38253 mountedhere 0xffffff00ac899600 >> flags () >> v_object 0xffffff008b839ca8 ref 0 pages 44786 >> lock type devfs: EXCL by thread 0xffffff016506cba0 (pid 76462) >> dev ada4s1 >> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >> fsync: giving up on dirty >> 0xffffff01bad6e1d8: tag devfs, type VCHR >> usecount 1, writecount 0, refcount 38253 mountedhere 0xffffff00ac899600 >> flags () >> v_object 0xffffff008b839ca8 ref 0 pages 44786 >> lock type devfs: UNLOCKED >> dev ada4s1 >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x4 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff803e60e4 >> stack pointer = 0x28:0xffffff80e79ba860 >> frame pointer = 0x28:0xffffff80e79ba8a0 >> 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 = 25 (syncer) >> >> ------ >> >> The filesystem is clean since I find no errors under Windows >> ('chkdsk /f'). >> >> I can otherwise mount, read and write on smaller FAT32 >> filesystems. I think there might be a problem with the handling >> of such a big FAT32 filesystem. >> >> A complete textdump is available at >> >> http://people.freebsd.org/~lioux/panic/2010100500/textdump.tar.2 >> >> Is this kind of error expected? Is there anything I can do >> to help? >> >> I can reproduce this error with the 1.3TB fs easily. > > Comment in source claims that support for large fs are experimental > and safe only in read only mode. > > Looking at your output it is obvious that offset should not be negative... Now that you mention it... :) I guess I might have overflown some internal variable, possibly a 32 bit integer. I checked http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/msdosfs/msdosfs_vfsops.c?rev=1.199 but it did not make much sense to me. :( Any ideas where I might look or for a patch? Unfortunately, I am not kernel knowledgeable but I'll help however I can. Regards, -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 12:55:15 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD569106566B for ; Wed, 6 Oct 2010 12:55:15 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id EF6578FC17 for ; Wed, 6 Oct 2010 12:55:14 +0000 (UTC) Received: (qmail 22364 invoked from network); 6 Oct 2010 14:28:32 +0200 Received: from smtp.free.de (HELO orwell.free.de) ([91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 6 Oct 2010 14:28:32 +0200 From: Kai Gallasch Content-Type: text/plain; charset=us-ascii Message-Id: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> Date: Wed, 6 Oct 2010 14:28:31 +0200 To: freebsd-fs@freebsd.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: Locked up processes after upgrade to ZFS v15 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 12:55:15 -0000 Hi. Two days ago I upgraded my server to 8.1-STABLE (amd64) and upgraded ZFS = from v14 to v15. After zpool & zfs upgrade the server was running stable for about half a = day, but then apache processes running inside jails would lock up and = could not be terminated any more. In the end apache (both worker and prefork) itself locked up, because it = lost control of its child processes. - only webserver jails with a prefork or worker apache do lock up - non-apache processes in other jails do not show this problem - locked httpd processes will not terminate when rebooting. in 'top' the stuck processes show up with state zfs or zfsmrb: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 2341 root 1 44 0 112M 12760K select 3 0:04 0.00% httpd 2365 root 1 44 0 12056K 4312K select 0 0:00 0.00% = sendmail 2376 root 1 48 0 7972K 1628K nanslp 4 0:00 0.00% cron 2214 root 1 44 0 6916K 1440K select 0 0:00 0.00% = syslogd 24731 www 1 44 0 114M 13464K zfsmrb 6 0:00 0.00% httpd 12111 www 1 44 0 114M 13520K zfs 5 0:00 0.00% httpd 24729 www 1 44 0 114M 13408K zfsmrb 4 0:00 0.00% httpd 24728 www 1 47 0 114M 13404K zfsmrb 5 0:00 0.00% httpd 11051 www 1 44 0 114M 13456K zfs 1 0:00 0.00% httpd 26368 www 1 44 0 114M 13460K zfsmrb 6 0:00 0.00% httpd 24730 www 1 44 0 114M 13444K zfsmrb 5 0:00 0.00% httpd 88803 www 1 44 0 114M 13388K zfs 1 0:00 0.00% httpd 10887 www 1 44 0 114M 13436K zfs 6 0:00 0.00% httpd 16493 www 1 44 0 114M 13528K zfs 5 0:00 0.00% httpd 12461 www 1 44 0 114M 13340K zfs 1 0:00 0.00% httpd 89018 www 1 51 0 114M 13260K zfs 1 0:00 0.00% httpd 48699 www 1 52 0 114M 13308K zfs 3 0:00 0.00% httpd 31090 www 1 44 0 114M 13404K zfs 3 0:00 0.00% httpd 18094 www 1 44 0 114M 13312K zfs 2 0:00 0.00% httpd 69479 www 1 46 0 114M 13424K zfs 4 0:00 0.00% httpd 12890 www 1 44 0 114M 13336K zfs 5 0:00 0.00% httpd 67204 www 1 44 0 114M 13328K zfs 5 0:00 0.00% httpd 69402 www 1 60 0 114M 13432K zfs 4 0:00 0.00% httpd 91162 www 1 56 0 114M 13408K zfs 0 0:00 0.00% httpd 89781 www 1 45 0 114M 13428K zfs 4 0:00 0.00% httpd 48663 www 1 45 0 114M 13388K zfs 4 0:00 0.00% httpd 12112 www 1 44 0 114M 13340K zfs 6 0:00 0.00% httpd 91161 www 1 54 0 114M 13280K zfs 5 0:00 0.00% httpd 88839 www 1 44 0 114M 13592K zfsmrb 5 0:00 0.00% httpd 89144 www 1 58 0 114M 13304K zfs 0 0:00 0.00% httpd 78946 www 1 45 0 114M 13420K zfs 0 0:00 0.00% httpd 81984 www 1 44 0 114M 13396K zfs 5 0:00 0.00% httpd 93431 www 1 61 0 114M 13340K zfs 5 0:00 0.00% httpd 91179 www 1 76 0 114M 13360K zfs 4 0:00 0.00% httpd 69400 www 1 53 0 114M 13324K zfs 0 0:00 0.00% httpd 54211 www 1 45 0 114M 13404K zfs 6 0:00 0.00% httpd 36335 www 1 45 0 114M 13400K zfs 4 0:00 0.00% httpd 31093 www 1 44 0 114M 13348K zfs 2 0:00 0.00% httpd I compiled a debug kernel with following options: options KDB # Enable kernel debugger = support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS options WITNESS # Enable checks to detect = deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed # options SW_WATCHDOG options DEBUG_LOCKS options DEBUG_VFS_LOCKS After process lockups only output on console was: witness_lock_list_get: witness exhausted I also moved the jails with the stuck httpd processes to another server = (also 8.1-STABLE, ZFS v15) - but the lockup also ouccured there. How can I debug this and get further information? At the moment I am = thinking about reverting from zfs to ufs - to save some nerves. Would be = a big disappointment for me, after all the time and effort trying to use = zfs in production. Regards, Kai. From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 15:02:04 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B50571065693 for ; Wed, 6 Oct 2010 15:02:04 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 89D8B8FC1D for ; Wed, 6 Oct 2010 15:02:04 +0000 (UTC) Received: by pxi17 with SMTP id 17so2384910pxi.13 for ; Wed, 06 Oct 2010 08:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dIvEhQ4QAxmLhx3bELX5pN8xqBwlE6AxNrx9xEUUv2A=; b=hfOWI56wEiIB534+QESoDs8qx1slV7z1u8cXZVtUlhLuFY6Eq9x5FBeFq7CJlI+jlt sgNnRaMGkK8I7n63a50hLufoyTcvh2e+JQZt9NPM6Kv2jAUbEit3A/IlXpuLPCAIMtXY xsSPC2QlmvcDpRFfHPS6l73oh/0KcoMOdsz/I= 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=ti330E/46NIdmAVhjI7CzBV6BFNM9p6lOvbSsuZkLk2b2JB/LbLuP1AXuNlO/Ux0wk 7AmoBfkoYfJ1JKd/ygJspozcrBkr0D4sonTTcavVgYIbV6Y5jbXKg6C4OKW4hSf45dF6 jaW0T0a+T96y6AEfw/Vvs9AJVGHMee3f70Yvg= MIME-Version: 1.0 Received: by 10.142.136.2 with SMTP id j2mr11747305wfd.159.1286377324101; Wed, 06 Oct 2010 08:02:04 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Wed, 6 Oct 2010 08:02:03 -0700 (PDT) In-Reply-To: <4CAC5067.3090106@uol.com.br> References: <20101006005350.62837.qmail@exxodus.fedaykin.here> <4CAC5067.3090106@uol.com.br> Date: Wed, 6 Oct 2010 15:02:03 +0000 Message-ID: From: Paul B Mahol To: Mario Sergio Fujikawa Ferreira Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Panic with msdosfs vs 1.3TB FAT32 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 15:02:04 -0000 On 10/6/10, Mario Sergio Fujikawa Ferreira wrote: > On 06/10/2010 00:36, Paul B Mahol wrote: >> On 10/6/10, Mario Sergio Fujikawa Ferreira wrote: >>> Hi, >>> >>> I mounted a 1.3TB FAT32 (32k cluster) filesystem on esata >>> /dev/ada4s1 under /media/esata/ with the '-l' (large option). What FreeBSD version is this and how many files that fs have? >>> >>> I tried to create a directory and files but got errors: If you mount it read only, can you read all files? This could eat all memory if there are many small files.... But it can be useful to know if you can read files with different inodes (or whatever FAT calls it) >>> >>> ------ >>> >>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >>> >>> ------ >>> >>> Then, I tried unmounting the filesystem which resulted on >>> >>> ------ >>> >>> fsync: giving up on dirty >>> 0xffffff01bad6e1d8: tag devfs, type VCHR >>> usecount 1, writecount 0, refcount 38253 mountedhere >>> 0xffffff00ac899600 >>> flags () >>> v_object 0xffffff008b839ca8 ref 0 pages 44786 >>> lock type devfs: EXCL by thread 0xffffff016506cba0 (pid 76462) >>> dev ada4s1 >>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >>> fsync: giving up on dirty >>> 0xffffff01bad6e1d8: tag devfs, type VCHR >>> usecount 1, writecount 0, refcount 38253 mountedhere >>> 0xffffff00ac899600 >>> flags () >>> v_object 0xffffff008b839ca8 ref 0 pages 44786 >>> lock type devfs: UNLOCKED >>> dev ada4s1 >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 1; apic id = 01 >>> fault virtual address = 0x4 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0xffffffff803e60e4 >>> stack pointer = 0x28:0xffffff80e79ba860 >>> frame pointer = 0x28:0xffffff80e79ba8a0 >>> 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 = 25 (syncer) >>> >>> ------ >>> >>> The filesystem is clean since I find no errors under Windows >>> ('chkdsk /f'). >>> >>> I can otherwise mount, read and write on smaller FAT32 >>> filesystems. I think there might be a problem with the handling >>> of such a big FAT32 filesystem. >>> >>> A complete textdump is available at >>> >>> http://people.freebsd.org/~lioux/panic/2010100500/textdump.tar.2 >>> >>> Is this kind of error expected? Is there anything I can do >>> to help? >>> >>> I can reproduce this error with the 1.3TB fs easily. >> >> Comment in source claims that support for large fs are experimental >> and safe only in read only mode. >> >> Looking at your output it is obvious that offset should not be negative... > > Now that you mention it... :) > > I guess I might have overflown some internal variable, possibly a 32 > bit integer. > > I checked > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/msdosfs/msdosfs_vfsops.c?rev=1.199 > > but it did not make much sense to me. :( > > Any ideas where I might look or for a patch? Unfortunately, I am not > kernel knowledgeable but I'll help however I can. Something is very buggy with msdosfs and vfs. kern/93634 is clear example. I can reproduce it on i386. Note that I'm freebsd vfs/vm noob. So do not expect anything from me. From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 17:32:06 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1038F106566C for ; Wed, 6 Oct 2010 17:32:06 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8A74D8FC22 for ; Wed, 6 Oct 2010 17:32:05 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX1/dM9grWfrOLfbRIFgDO2Jaa2Bij29ajS8@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id o96HW2tr080534; Wed, 6 Oct 2010 18:32:02 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o96HW23i005948; Wed, 6 Oct 2010 18:32:02 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o96HW2Vi005945; Wed, 6 Oct 2010 18:32:02 +0100 Date: Wed, 6 Oct 2010 18:32:02 +0100 Message-Id: <201010061732.o96HW2Vi005945@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org In-reply-to: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> (message from Kai Gallasch on Wed, 6 Oct 2010 14:28:31 +0200) References: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> Subject: Re: Locked up processes after upgrade to ZFS v15 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:32:06 -0000 >>>>> On Wed, 6 Oct 2010 14:28:31 +0200, Kai Gallasch said: > > How can I debug this and get further information? procstat -k -k $pid will generate a backtrace (or replace $pid by -a for all processes). __Martin From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 18:51:53 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7650D106566B for ; Wed, 6 Oct 2010 18:51:53 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id D324D8FC21 for ; Wed, 6 Oct 2010 18:51:52 +0000 (UTC) Received: (qmail 86282 invoked from network); 6 Oct 2010 20:51:51 +0200 Received: from smtp.free.de (HELO orwell.free.de) ([91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 6 Oct 2010 20:51:51 +0200 References: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> <201010061732.o96HW2Vi005945@higson.cam.lispworks.com> In-Reply-To: <201010061732.o96HW2Vi005945@higson.cam.lispworks.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Kai Gallasch Date: Wed, 6 Oct 2010 20:51:49 +0200 To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.1081) Subject: Re: Locked up processes after upgrade to ZFS v15 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 18:51:53 -0000 Am 06.10.2010 um 19:32 schrieb Martin Simmons: >>>>>> On Wed, 6 Oct 2010 14:28:31 +0200, Kai Gallasch said: >>=20 >> How can I debug this and get further information? >=20 > procstat -k -k $pid will generate a backtrace (or replace $pid by -a = for all > processes). procstat for process 12111 (state: zfs) sonnenkraft:~ # procstat -k -k 12111 PID TID COMM TDNAME KSTACK = =20 12111 102385 httpd - mi_switch+0x21b = sleepq_switch+0x123 sleepq_wait+0x4d __lockmgr_args+0x7ae = vop_stdlock+0x39 VOP_LOCK1_APV+0x9b _vn_lock+0x57 vget+0x7b = cache_lookup+0x4e0 vfs_cache_lookup+0xc0 VOP_LOOKUP_APV+0xb7 = lookup+0x3d3 namei+0x457 vn_open_cred+0x1e3 kern_openat+0x181 = syscall+0x102 Xfast_syscall+0xe2 procstat for process 24731 (state: zfsmrb) # procstat -k -k 24731 PID TID COMM TDNAME KSTACK = =20 24731 102273 httpd - mi_switch+0x21b = sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x369 zfs_freebsd_read+0x2a6 = VOP_READ_APV+0xaf vnode_pager_generic_getpages+0x3ea = VOP_GETPAGES_APV+0xb5 vnode_pager_getpages+0x8c vm_fault+0x685 = trap_pfault+0x128 trap+0x52c calltrap+0x8 In my original post I wrote that only apache httpd processes would lock = up.. This is wrong. Several other non-httpd processes also got stuck in state = zfs or zfsmrb. -Kai.= From owner-freebsd-fs@FreeBSD.ORG Wed Oct 6 20:01:09 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EF681065675 for ; Wed, 6 Oct 2010 20:01:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id EC2378FC08 for ; Wed, 6 Oct 2010 20:01:08 +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 o96K14Ur072858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2010 23:01:04 +0300 (EEST) (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.4/8.14.4) with ESMTP id o96K149n031658; Wed, 6 Oct 2010 23:01:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o96K13P4031657; Wed, 6 Oct 2010 23:01:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 6 Oct 2010 23:01:03 +0300 From: Kostik Belousov To: Paul B Mahol Message-ID: <20101006200103.GG2392@deviant.kiev.zoral.com.ua> References: <20101006005350.62837.qmail@exxodus.fedaykin.here> <4CAC5067.3090106@uol.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nlttjmhgc7EeTk3T" Content-Disposition: inline In-Reply-To: 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=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: Panic with msdosfs vs 1.3TB FAT32 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:01:09 -0000 --nlttjmhgc7EeTk3T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 06, 2010 at 03:02:03PM +0000, Paul B Mahol wrote: > On 10/6/10, Mario Sergio Fujikawa Ferreira wrote: > > On 06/10/2010 00:36, Paul B Mahol wrote: > >> On 10/6/10, Mario Sergio Fujikawa Ferreira wro= te: > >>> Hi, > >>> > >>> I mounted a 1.3TB FAT32 (32k cluster) filesystem on esata > >>> /dev/ada4s1 under /media/esata/ with the '-l' (large option). > What FreeBSD version is this and how many files that fs have? >=20 > >>> > >>> I tried to create a directory and files but got errors: >=20 > If you mount it read only, can you read all files? >=20 > This could eat all memory if there are many small files.... > But it can be useful to know if you can read files with different > inodes (or whatever FAT calls it) > >>> > >>> ------ > >>> > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247646208, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247646208, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247613440, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247646208, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247613440, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247580672, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247646208, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247613440, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247580672, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247646208, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247613440, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247580672, length=3D32768)]err= or =3D 5 > >>> > >>> ------ > >>> > >>> Then, I tried unmounting the filesystem which resulted on > >>> > >>> ------ > >>> > >>> fsync: giving up on dirty > >>> 0xffffff01bad6e1d8: tag devfs, type VCHR > >>> usecount 1, writecount 0, refcount 38253 mountedhere > >>> 0xffffff00ac899600 > >>> flags () > >>> v_object 0xffffff008b839ca8 ref 0 pages 44786 > >>> lock type devfs: EXCL by thread 0xffffff016506cba0 (pid 76462) > >>> dev ada4s1 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247646208, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247613440, length=3D32768)]err= or =3D 5 > >>> g_vfs_done():ada4s1[WRITE(offset=3D-980247580672, length=3D32768)]err= or =3D 5 > >>> fsync: giving up on dirty > >>> 0xffffff01bad6e1d8: tag devfs, type VCHR > >>> usecount 1, writecount 0, refcount 38253 mountedhere > >>> 0xffffff00ac899600 > >>> flags () > >>> v_object 0xffffff008b839ca8 ref 0 pages 44786 > >>> lock type devfs: UNLOCKED > >>> dev ada4s1 > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> cpuid =3D 1; apic id =3D 01 > >>> fault virtual address =3D 0x4 > >>> fault code =3D supervisor read data, page not present > >>> instruction pointer =3D 0x20:0xffffffff803e60e4 > >>> stack pointer =3D 0x28:0xffffff80e79ba860 > >>> frame pointer =3D 0x28:0xffffff80e79ba8a0 > >>> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >>> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > >>> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >>> current process =3D 25 (syncer) > >>> > >>> ------ > >>> > >>> The filesystem is clean since I find no errors under Windows > >>> ('chkdsk /f'). > >>> > >>> I can otherwise mount, read and write on smaller FAT32 > >>> filesystems. I think there might be a problem with the handling > >>> of such a big FAT32 filesystem. > >>> > >>> A complete textdump is available at > >>> > >>> http://people.freebsd.org/~lioux/panic/2010100500/textdump.tar.2 > >>> > >>> Is this kind of error expected? Is there anything I can do > >>> to help? > >>> > >>> I can reproduce this error with the 1.3TB fs easily. > >> > >> Comment in source claims that support for large fs are experimental > >> and safe only in read only mode. > >> > >> Looking at your output it is obvious that offset should not be negativ= e... > > > > Now that you mention it... :) > > > > I guess I might have overflown some internal variable, possibly a 32 > > bit integer. > > > > I checked > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/msdosfs/msdosfs_vfsops= .c?rev=3D1.199 > > > > but it did not make much sense to me. :( > > > > Any ideas where I might look or for a patch? Unfortunately, I am not > > kernel knowledgeable but I'll help however I can. >=20 > Something is very buggy with msdosfs and vfs. >=20 > kern/93634 is clear example. I can reproduce it on i386. >=20 > Note that I'm freebsd vfs/vm noob. So do not expect anything from me. This is a consequence of case-insensitive nature of msdosfs, and the fact that our namecache is case-sensitive. When doing a rename, lookup of the fvp (the vnode which is to be renamed) is performed with DELETE operation, that clears namecache from the entry for the vnode that was specified to lookup. If any alias exists due to case-insensitive lookup done earlier, it will not be removed. The simplest fix seems to purge the cache for the fvp if rename was successfull. Patch below contains the change and an optimization for msdosfs that I apparently had long enough in my local tree. Namely, I get a reference to the root vnode to prevent its constant recycling after each lookup. diff --git a/sys/fs/msdosfs/msdosfs_vfsops.c b/sys/fs/msdosfs/msdosfs_vfsop= s.c index a0801bd..964cc2d 100644 --- a/sys/fs/msdosfs/msdosfs_vfsops.c +++ b/sys/fs/msdosfs/msdosfs_vfsops.c @@ -421,6 +421,7 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp) int ronly, error; struct g_consumer *cp; struct bufobj *bo; + struct vnode *rootvp; =20 bp =3D NULL; /* This and pmp both used in error_exit. */ pmp =3D NULL; @@ -758,7 +759,13 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp) if (pmp->pm_flags & MSDOSFS_LARGEFS) msdosfs_fileno_init(mp); =20 - return 0; + error =3D msdosfs_root(mp, LK_EXCLUSIVE, &rootvp); + if (error =3D=3D 0) { + pmp->pm_root_refs =3D 1; + VOP_UNLOCK(rootvp, 0); + } + + return (0); =20 error_exit: if (bp) @@ -793,10 +800,10 @@ msdosfs_unmount(struct mount *mp, int mntflags) flags =3D 0; if (mntflags & MNT_FORCE) flags |=3D FORCECLOSE; - error =3D vflush(mp, 0, flags, curthread); - if (error && error !=3D ENXIO) - return error; pmp =3D VFSTOMSDOSFS(mp); + error =3D vflush(mp, pmp->pm_root_refs, flags, curthread); + if (error !=3D 0 && error !=3D ENXIO) + return (error); if ((pmp->pm_flags & MSDOSFSMNT_RONLY) =3D=3D 0) { error =3D markvoldirty(pmp, 0); if (error && error !=3D ENXIO) { diff --git a/sys/fs/msdosfs/msdosfs_vnops.c b/sys/fs/msdosfs/msdosfs_vnops.c index 7a19412..416e702 100644 --- a/sys/fs/msdosfs/msdosfs_vnops.c +++ b/sys/fs/msdosfs/msdosfs_vnops.c @@ -1258,6 +1258,7 @@ abortit: } } =20 + cache_purge(fvp); VOP_UNLOCK(fvp, 0); bad: if (xp) diff --git a/sys/fs/msdosfs/msdosfsmount.h b/sys/fs/msdosfs/msdosfsmount.h index 2951b2c..7e6b234 100644 --- a/sys/fs/msdosfs/msdosfsmount.h +++ b/sys/fs/msdosfs/msdosfsmount.h @@ -112,6 +112,7 @@ struct msdosfsmount { RB_HEAD(msdosfs_filenotree, msdosfs_fileno) pm_filenos; /* 64<->32-bit fileno mapping */ struct lock pm_fatlock; /* lockmgr protecting allocations and rb tree */ + int pm_root_refs; /* Did we obtained root reference ? */ }; =20 /* --nlttjmhgc7EeTk3T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkys1X4ACgkQC3+MBN1Mb4gqtgCbBXPIz5pp1RQsuER1y+ToTZUP qyoAn2oqh+G8fizRrHF1h92HEByAmKaJ =3Nm1 -----END PGP SIGNATURE----- --nlttjmhgc7EeTk3T-- From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 00:15:36 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F26106566B for ; Thu, 7 Oct 2010 00:15:36 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id EE8788FC08 for ; Thu, 7 Oct 2010 00:15:35 +0000 (UTC) Received: (qmail 46655 invoked from network); 7 Oct 2010 02:15:34 +0200 Received: from smtp.free.de (HELO orwell.free.de) ([91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 7 Oct 2010 02:15:34 +0200 References: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> In-Reply-To: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <65756266-A549-4F78-8BBA-414F24A633F9@free.de> Content-Transfer-Encoding: quoted-printable From: Kai Gallasch Date: Thu, 7 Oct 2010 02:15:33 +0200 To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.1081) Subject: Re: Locked up processes after upgrade to ZFS v15 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 00:15:36 -0000 Am 06.10.2010 um 14:28 schrieb Kai Gallasch: > Hi. >=20 > Two days ago I upgraded my server to 8.1-STABLE (amd64) and upgraded = ZFS from v14 to v15. > After zpool & zfs upgrade the server was running stable for about half = a day, but then apache processes running inside jails would lock up and = could not be terminated any more. >=20 > In the end apache (both worker and prefork) itself locked up, because = it lost control of its child processes. sorry for replying to my own mail, but there is some new information on = this issue: 'zfs send' triggered a panic: MCA: Bank 0, Status 0xf600000000010015 MCA: Global Cap 0x0000000000000106, = Status 0x0000000000000004 MCA: Vendor "AuthenticAMD", ID 0x100f23, APIC ID 2 MCA: CPU 2 UNCOR PCC OVER DTLB L1 error MCA: Address 0xff80d4611000 Fatal trap 28: machine check trap while in kernel mode cpuid =3D 2; apic id =3D 02 instruction pointer =3D 0x20:0xffffffff80e60f25 stack pointer =3D 0x28:0xffffff832a2e17d0 frame pointer =3D 0x28:0xffffff832a2e1a40 code segment =3D base 0x0, limit 0xfffff, = type 0x1b =3D DPL 0, pres 1, long 1, def32 = 0, gran 1 processor eflags =3D interrupt enabled, IOPL =3D = 0 current process =3D 0 = (zio_write_issue_0) [thread pid 0 tid 101159 ] Stopped at lzjb_compress+0x165: addq = $0x1,%rdx db> bt Tracing pid 0 tid 101159 td 0xffffff00aa64a3e0 lzjb_compress() at lzjb_compress+0x165 zio_compress_data() at zio_compress_data+0xbe zio_write_bp_init() at zio_write_bp_init+0xc2 zio_execute() at zio_execute+0x77 zio_ready() at zio_ready+0x162 zio_execute() at zio_execute+0x77 taskq_run_safe() at taskq_run_safe+0x13 taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff832a2e1d30, rbp =3D 0 --- I sure know this one: "CPU 2 UNCOR PCC OVER DTLB L1 error", because this particular server in the past had some problems with FreeBSD 8.0-REL and "super pages" enabled. Workaround was to set vm.pmap.pg_ps_enabled=3D"0" in /boot/loader.conf Later on with 8.0-STABLE setting the tunable was not necessary any more, because a workaround for this was commited to src/sys. So, just to test this I again set vm.pmap.pg_ps_enabled=3D"0" and will = see if processes still lock up. Regards, Kai. From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 06:35:51 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06BB31065670 for ; Thu, 7 Oct 2010 06:35:51 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.55]) by mx1.freebsd.org (Postfix) with ESMTP id B9A098FC08 for ; Thu, 7 Oct 2010 06:35:50 +0000 (UTC) Received: from edmwaa02.telusplanet.net ([66.183.53.162]) by priv-edmwes33.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20101007063549.BQSR17374.priv-edmwes33.telusplanet.net@edmwaa02.telusplanet.net> for ; Thu, 7 Oct 2010 00:35:49 -0600 Received: from oliver.bc.lan (d66-183-53-162.bchsia.telus.net [66.183.53.162]) by edmwaa02.telusplanet.net (BorderWare Security Platform) with ESMTP id A95330776F8F3E2D for ; Thu, 7 Oct 2010 00:35:49 -0600 (MDT) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id 4410762A4 for ; Wed, 6 Oct 2010 23:35:49 -0700 (PDT) Message-ID: <4CAD6A44.8010707@telus.net> Date: Wed, 06 Oct 2010 23:35:48 -0700 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=VRk8ggRbID116JoYb+Pzz07NkPEh5LDahQQ5ZEpV7yM= c=1 sm=0 a=qlfKZ_JmYfsA:10 a=8nJEP1OIZ-IA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:17 a=rSJd4UaPh3VtohMZ7-sA:9 a=GyhKEj6f5ImM56sw94gA:7 a=IGdtSNsUNW4gAZfRHHy4nO1VhqoA:4 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Mailman-Approved-At: Thu, 07 Oct 2010 11:12:54 +0000 Subject: Should gmirrored gjournal provider have auto-synchronization? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 06:35:51 -0000 Suppose I've used a pair of drives laid out with GPT partitions to create a mirror. Actually, this situation requires that individual partitions be mirrored instead of the whole drive. Then suppose one of these partitions is to be gjournaled, but with separate data and journal providers. The separate journal provider will be in another partition. I believe I should gmirror the journal provider partition just as I did the data provider partition. Correct me if this is wrong. Then, should I be enabling or disabling auto-synchronization for the mirrored journal provider partition? It is clear to me that it should be disabled for the mirrored data provider partition because the journaling will ensure data consistency, but is the content of the journal provider itself guaranteed consistent under all circumstances? Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 14:27:09 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E758010656B3; Thu, 7 Oct 2010 14:27:09 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id A0F268FC1B; Thu, 7 Oct 2010 14:27:09 +0000 (UTC) Received: from scc-wkit-clx-208-149.scc.kit.edu (scc-wkit-clx-208-149.scc.kit.edu [141.3.208.149]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 28AB312543B; Thu, 7 Oct 2010 23:27:05 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Daichi GOTO In-Reply-To: Date: Thu, 7 Oct 2010 16:27:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40A99AF1-8989-4121-8659-CF3E169FD2F8@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:27:10 -0000 On Oct 5, 2010, at 4:52 PM, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO wrote: >> On Tue, 5 Oct 2010 01:23:02 -0700 >> Garrett Cooper wrote: >>> 2010/10/4 Daichi GOTO : >>>> Thanks nice test tool :) And at last I got it excepting one = mystery! >>>>=20 >>>> On Mon, 4 Oct 2010 20:17:08 -0700 >>>> Garrett Cooper wrote: >>>>> Following through the same process on FreeBSD... >>>>>=20 >>>>> Window 1: >>>>> $ ls -l /tmp/lockfile >>>>> ls: /tmp/lockfile: No such file or directory >>>>> $ ./test_fcntl >>>>>=20 >>>>> Window 2: >>>>>=20 >>>>> $ ls -l /tmp/lockfile >>>>> -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile >>>>> $ ./test_fcntl >>>>> test_fcntl: fcntl: Resource temporarily unavailable >>>>=20 >>>> Just my mystery is as follow: >>>>=20 >>>> Windows 1: >>>> % ./test_fcntl >>>> My pid: 43490 >>>>=20 >>>> Windows 2: >>>> % ls -l /tmp/lockfile >>>> -r-sr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:02 /tmp/lockfile = <--- is it weird, isn't it? >>>> % ./test_fcntl >>>> test_fcntl: open: Permission denied >>>> % >>>>=20 >>>> Oops... What's wrong... /tmp is as follow: >>>>=20 >>>> % mount | grep tmp >>>> /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >>>> % dumpfs /tmp | grep journal >>>> flags soft-updates+journal >>>> % >>>>=20 >>>> And working scene: >>>>=20 >>>> Windows 2: >>>> % chmod u+w /tmp/lockfile >>>> % ls -l /tmp/lockfile >>>> -rwsr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:22 /tmp/lockfile >>>> % ./test_fcntl >>>> My pid: 43646 >>>> test_fcntl: fcntl[1]: Resource temporarily unavailable >>>> PID=3D43490 has the lock >>>> % >>>=20 >>> What's your umask and what are the permissions on /tmp? >>=20 >> % ll / | grep tmp >> drwxrwxrwt 14 root wheel 1024 10=E6=9C=88 5 17:19 tmp >> % umask >> 022 >> % rm -f test >> % touch test >> % ll | grep test >> -rw-r--r-- 1 daichi wheel 0 10=E6=9C=88 5 17:52 test >> % >=20 > The permissions look ok from my perspective, but the umask is > different, so you might want to try my umask to make sure that your > results match mine (and we need to check the requirements to determine > whether or not the behavior for FreeBSD's umask syscall is correct): >=20 > $ ls -la /tmp/ | head -n 2 > total 462686 > drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . > $ umask > 0022 The results are different on some users, even on the same user! (022 and 0022 shows the same results.) test user: $ rm -f /tmp/lockfile $ ./test_fcntl My pid: 63133 ^C $ ll /tmp/lockfile ---sr----- 1 test wheel - 0 Oct 7 23:16 /tmp/lockfile* $ daichi: % rm -f /tmp/lockfile =20 % ./test_fcntl=20 My pid: 63140 ^C % ll /tmp/lockfile ---Sr-x--- 1 daichi wheel 0 10=E6=9C=88 7 23:17 /tmp/lockfile %=20 But above daichi's result was ---sr----- as the same as test user. After some operation, it turns into returing ---Sr-x---. I didn't = remember=20 what operation did that. root: # rm -f /tmp/lockfile # ./test_fcntl My pid: 63147 ^C # ls -l /tmp/lockfile --wSr-S--- 1 root wheel 0 Oct 7 23:20 /tmp/lockfile #=20 It is mystery. > Where and how is /tmp mounted (is it a real partition, what > filesystem, etc)? UFS+SUJ+noatime real pertition. I checked atime version, and got the = same=20 result. > BTW, when I change my umask to match your's I don't get the same > results you do on my home machine: >=20 > Window 1: >=20 > $ umask 022 > $ ./test_fcntl > My pid: 17353 >=20 > Window 2: >=20 > $ ./test_fcntl > My pid: 17356 > test_fcntl: fcntl[1]: Resource temporarily unavailable > PID=3D17353 has the lock > $ ls -l /tmp/lockfile > -rwSr----- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile >=20 > Just to note, the tests before were run on the RHEL 4.8 box with > the following info, and the FreeBSD box with the following info: >=20 > Red Hat Enterprise Linux AS release 4 (Nahant Update 8) > Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT > 2009 x86_64 x86_64 x86_64 GNU/Linux >=20 > FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 > r211767M: Sat Aug 28 00:28:45 PDT 2010 > garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 >=20 > The tests above were run on a FreeBSD box with the following info: >=20 > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > Thu Aug 19 22:50:36 PDT 2010 > root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >=20 > On bayonetta /tmp is SUJ backed (probably should change that > though), and on bioshock it's not SUJ backed. > Thanks! > -Garrett Still now, I couldn't find the cause of this issue, but it's ok by code = following, and program should set permission at creating time I guess. fd =3D open("/tmp/lockfile", O_CREAT|O_WRONLY,0600); > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 14:36:57 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0229F1065670; Thu, 7 Oct 2010 14:36:57 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE268FC1B; Thu, 7 Oct 2010 14:36:56 +0000 (UTC) Received: from scc-wkit-clx-208-149.scc.kit.edu (scc-wkit-clx-208-149.scc.kit.edu [141.3.208.149]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 95B8212543B; Thu, 7 Oct 2010 23:36:53 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Daichi GOTO In-Reply-To: Date: Thu, 7 Oct 2010 16:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:36:57 -0000 On Oct 5, 2010, at 7:09 PM, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper = wrote: >> On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper = wrote: >>> On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO = wrote: >>>> On Tue, 5 Oct 2010 01:23:02 -0700 >>>> Garrett Cooper wrote: >>>>> 2010/10/4 Daichi GOTO : >>>>>> Thanks nice test tool :) And at last I got it excepting one = mystery! >>>>>>=20 >>>>>> On Mon, 4 Oct 2010 20:17:08 -0700 >>>>>> Garrett Cooper wrote: >>>>>>> Following through the same process on FreeBSD... >>>>>>>=20 >>>>>>> Window 1: >>>>>>> $ ls -l /tmp/lockfile >>>>>>> ls: /tmp/lockfile: No such file or directory >>>>>>> $ ./test_fcntl >>>>>>>=20 >>>>>>> Window 2: >>>>>>>=20 >>>>>>> $ ls -l /tmp/lockfile >>>>>>> -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile >>>>>>> $ ./test_fcntl >>>>>>> test_fcntl: fcntl: Resource temporarily unavailable >>>>>>=20 >>>>>> Just my mystery is as follow: >>>>>>=20 >>>>>> Windows 1: >>>>>> % ./test_fcntl >>>>>> My pid: 43490 >>>>>>=20 >>>>>> Windows 2: >>>>>> % ls -l /tmp/lockfile >>>>>> -r-sr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:02 /tmp/lockfile = <--- is it weird, isn't it? >>>>>> % ./test_fcntl >>>>>> test_fcntl: open: Permission denied >>>>>> % >>>>>>=20 >>>>>> Oops... What's wrong... /tmp is as follow: >>>>>>=20 >>>>>> % mount | grep tmp >>>>>> /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >>>>>> % dumpfs /tmp | grep journal >>>>>> flags soft-updates+journal >>>>>> % >>>>>>=20 >>>>>> And working scene: >>>>>>=20 >>>>>> Windows 2: >>>>>> % chmod u+w /tmp/lockfile >>>>>> % ls -l /tmp/lockfile >>>>>> -rwsr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:22 /tmp/lockfile >>>>>> % ./test_fcntl >>>>>> My pid: 43646 >>>>>> test_fcntl: fcntl[1]: Resource temporarily unavailable >>>>>> PID=3D43490 has the lock >>>>>> % >>>>>=20 >>>>> What's your umask and what are the permissions on /tmp? >>>>=20 >>>> % ll / | grep tmp >>>> drwxrwxrwt 14 root wheel 1024 10=E6=9C=88 5 17:19 tmp >>>> % umask >>>> 022 >>>> % rm -f test >>>> % touch test >>>> % ll | grep test >>>> -rw-r--r-- 1 daichi wheel 0 10=E6=9C=88 5 17:52 test >>>> % >>>=20 >>> The permissions look ok from my perspective, but the umask is >>> different, so you might want to try my umask to make sure that your >>> results match mine (and we need to check the requirements to = determine >>> whether or not the behavior for FreeBSD's umask syscall is correct): >>>=20 >>> $ ls -la /tmp/ | head -n 2 >>> total 462686 >>> drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . >>> $ umask >>> 0022 >>>=20 >>> Where and how is /tmp mounted (is it a real partition, what >>> filesystem, etc)? >>> BTW, when I change my umask to match your's I don't get the same >>> results you do on my home machine: >>>=20 >>> Window 1: >>>=20 >>> $ umask 022 >>> $ ./test_fcntl >>> My pid: 17353 >>>=20 >>> Window 2: >>>=20 >>> $ ./test_fcntl >>> My pid: 17356 >>> test_fcntl: fcntl[1]: Resource temporarily unavailable >>> PID=3D17353 has the lock >>> $ ls -l /tmp/lockfile >>> -rwSr----- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile >>>=20 >>> Just to note, the tests before were run on the RHEL 4.8 box with >>> the following info, and the FreeBSD box with the following info: >>>=20 >>> Red Hat Enterprise Linux AS release 4 (Nahant Update 8) >>> Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT >>> 2009 x86_64 x86_64 x86_64 GNU/Linux >>>=20 >>> FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 >>> r211767M: Sat Aug 28 00:28:45 PDT 2010 >>> garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 >>>=20 >>> The tests above were run on a FreeBSD box with the following = info: >>>=20 >>> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: >>> Thu Aug 19 22:50:36 PDT 2010 >>> root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >>>=20 >>> On bayonetta /tmp is SUJ backed (probably should change that >>> though), and on bioshock it's not SUJ backed. >>=20 >> And while this might be a good mental exercise, I think we're missing >> the original point of your bug: >>=20 >> You were getting ECONNREFUSED because a socket was in `use', even >> though all instances of mozc_server were dead (at least that's the >> case with me). So the question I guess that's worth asking is: >=20 > Statement incorrect: socket wasn't in use. The logic needs to be > rewritten to account for this case and setup the socket again if this > occurs. It would be a good idea to do this if the file wasn't locked. Maybe behavior difference of fcntl when called with F_SETLN or F_GETLN=20= you found is the answer of this issue. I'll try to check it out. Thanks! And I'll try to treat correct l_pid when called with F_SETLN. I guess = this change will be benefits for other applications that use fcntl(2) like = mozc_server does. >> 1. What process/application does it need to establish a Unix style = socket with? >> 2. Why isn't that socket being cleaned up by the OS at exit? >=20 > Thanks! > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 15:46:16 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B75BC106566B for ; Thu, 7 Oct 2010 15:46:16 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.freebsd.org (Postfix) with SMTP id 425478FC18 for ; Thu, 7 Oct 2010 15:46:15 +0000 (UTC) Received: (qmail 38569 invoked from network); 7 Oct 2010 15:46:15 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp101.rog.mail.re2.yahoo.com with SMTP; 07 Oct 2010 08:46:15 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: i_UBIe8VM1kDflKCEmIFrkMjzKT1mMB39oxk_w1KIcuYxN8 vgAeqeLZFVzpinraiAL49qrTyLCljVAajFhIoYlopOOdv6s_it1gBI_bEhle A_949_Kon46wUupRQeJYsDKzGWngpRbZ9AoLBPDSUyzPM41jMDrI6zAtGKTB PgMt9xXjHIei3z4nVN_kpwFkQYcCN7IjiWQSlXCMkl3TWaMp_qJpoJbPaomq yFa6ilJmThkiWGQsV3LoG0DlTHWKQ2N2t141nMTDcpkBX9i2XhaZh_1nN12c idOoSJsvWzZ9rFE3jKF_sYHA3msxC63jB4cl9zTH5C7KLKwzyfb6xoJKr52c ktcgOM5jI7E5Z1iQqEq_asoredwjO3aCmtx9aySlwsICzCOOp4pVSWGfKvjA zoEE7prz6ZMeTfAjPPlBL8C7TnioBeAhl0OMFFHyqv7s- X-Yahoo-Newman-Property: ymail-3 Received: by smtp.irbisnet.com (Postfix, from userid 80) id C3B74AB7B; Thu, 7 Oct 2010 11:46:14 -0400 (EDT) To: "Richard Lee" , "Jeremy Chadwick" , "jhell" , "Andriy Gapon" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Oct 2010 11:46:14 -0400 From: Andriy Bakay Message-ID: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> X-Sender: andriy@irbisnet.com User-Agent: RoundCube Webmail/0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 15:46:16 -0000 Hi All, Do we have any new information about this issue (fixes, work arounds etc.)? Any input will be highly useful. http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057682.html I am experiencing kind of same problem on FreeBSD 8.1-RELEASE-p1 i386 2G RAM. Thanks, Andriy From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 18:25:08 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E413106564A for ; Thu, 7 Oct 2010 18:25:08 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id E1A398FC08 for ; Thu, 7 Oct 2010 18:25:07 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7BA5E45C9C; Thu, 7 Oct 2010 20:25:06 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8AFC245685; Thu, 7 Oct 2010 20:25:00 +0200 (CEST) Date: Thu, 7 Oct 2010 20:24:36 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20101007182436.GB1733@garage.freebsd.pl> References: <86hbh44wgl.fsf@kopusha.home.net> <86aamw4l42.fsf@kopusha.home.net> <20101004213647.GK7322@garage.freebsd.pl> <86tyl1m85y.fsf@zhuzha.ua1> <20101005074736.GM7322@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline In-Reply-To: <20101005074736.GM7322@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: hastd: assertion (res->hr_event != NULL) fails in secondary on split-brain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:25:08 -0000 --gatW/ieO32f1wygP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 05, 2010 at 09:47:36AM +0200, Pawel Jakub Dawidek wrote: > On Tue, Oct 05, 2010 at 10:05:13AM +0300, Mikolaj Golub wrote: > >=20 > > On Mon, 4 Oct 2010 23:36:47 +0200 Pawel Jakub Dawidek wrote: > >=20 > > PJD> I see three problems:) > >=20 > > PJD> 1. In child_kill() you interpret status value always, even if it = is > > PJD> invalid due to earlier errors. > > PJD> 2. While copying the code you changed style. Don't you like style= (9)?:) > >=20 > > Me like :-). But it looks like my emacs don't. Need to teach it somehow= ... > >=20 > > PJD> 3. The patch doesn't fix the root cause of the problem. > >=20 > > Thank you for your comments. >=20 > The hang you reported is still not fixed, but I'm working on it. Could you verify if the primary/secondary loop doesn't cause hangs anymore with most recent hast? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyuEGQACgkQForvXbEpPzQa1ACgkY4v73X1hvxGw3xjtgpJReNO /MEAoJw6YR8bZgJvUT5KfFwpqbWGnWHx =0n0/ -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 18:30:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDE25106576E; Thu, 7 Oct 2010 18:30:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E9C098FC29; Thu, 7 Oct 2010 18:30:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA19232; Thu, 07 Oct 2010 21:29:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CAE11A2.1000604@icyb.net.ua> Date: Thu, 07 Oct 2010 21:29:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Bakay References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> In-Reply-To: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Richard Lee Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:30:06 -0000 on 07/10/2010 18:46 Andriy Bakay said the following: > Hi All, > > Do we have any new information about this issue (fixes, work arounds etc.)? Any > input will be highly useful. Yes, _we_ do. Where have you been? :-) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 18:47:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 646151065695 for ; Thu, 7 Oct 2010 18:47:05 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.freebsd.org (Postfix) with SMTP id E32698FC26 for ; Thu, 7 Oct 2010 18:47:04 +0000 (UTC) Received: (qmail 55274 invoked from network); 7 Oct 2010 18:47:04 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp104.rog.mail.re2.yahoo.com with SMTP; 07 Oct 2010 11:47:03 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: TrO1ZjgVM1ks2odRnmjQuEEi.8.pixVMIRJQSuV.yo4Aufb cdQat3WHKbHM2bkFhS3F8AbioGE9M8k7mnNX4klYYygR_RIamTnmSEmThE7Q 8eR5.TXxShEzlPr10HfVIchGKxf9OwXPjS0QJbo1YaIkA4KfUDcIUQUqu9yu Fn_gkOa3IbV_3peiv_4tVg.qgge0U8CaDHDcRTRx0QhPxOpJmVJoQ0XhdAtd _5AxNMF_8qegcrt6XFzrC04Tv8KXTQ.tMHR35S.s2rua9Bs5bdJMREqwphyp HqUpq66dyd0EBBx51ps1U2dto.tf1U.SECFml4Vp7Rq.izW7kIbWi.5w2Gww 1S5TgT_yyrVchjdjsHL7YmQ3i_FEyMzg3H.enIc7JJtWpNbm0yg9j4Upkl81 kJp_1gcwNkfEyeOBkXNmk2ff2anjabzBqHoTSxAVULCkX X-Yahoo-Newman-Property: ymail-3 Received: by smtp.irbisnet.com (Postfix, from userid 80) id 52ED5AC11; Thu, 7 Oct 2010 14:47:03 -0400 (EDT) To: Andriy Gapon MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Thu, 07 Oct 2010 14:47:03 -0400 From: Andriy Bakay In-Reply-To: <4CAE11A2.1000604@icyb.net.ua> References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> Message-ID: <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> X-Sender: andriy@irbisnet.com User-Agent: RoundCube Webmail/0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Richard Lee Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:47:05 -0000 I expressed myself incorrectly. Sorry. :-( Do you Andriy :-) or anybody else from list(s) have more info how to fix or work around this issue? On Thu, 07 Oct 2010 21:29:54 +0300, Andriy Gapon wrote: > on 07/10/2010 18:46 Andriy Bakay said the following: >> Hi All, >> >> Do we have any new information about this issue (fixes, work arounds etc.)? Any >> input will be highly useful. > > Yes, _we_ do. Where have you been? :-) From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 19:20:26 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06E67106566C; Thu, 7 Oct 2010 19:20:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 039298FC12; Thu, 7 Oct 2010 19:20:24 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA19762; Thu, 07 Oct 2010 22:20:19 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P3w0p-0007WW-Ch; Thu, 07 Oct 2010 22:20:19 +0300 Message-ID: <4CAE1D72.20208@icyb.net.ua> Date: Thu, 07 Oct 2010 22:20:18 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Bakay References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> In-Reply-To: <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:20:26 -0000 on 07/10/2010 21:47 Andriy Bakay said the following: > I expressed myself incorrectly. Sorry. :-( > > Do you Andriy :-) or anybody else from list(s) have more info how to > fix or work around this issue? First, I recommend to try to upgrade to the recent stable/8. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 21:04:19 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04FE31065675 for ; Thu, 7 Oct 2010 21:04:19 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.freebsd.org (Postfix) with SMTP id 7B7BF8FC17 for ; Thu, 7 Oct 2010 21:04:18 +0000 (UTC) Received: (qmail 39494 invoked from network); 7 Oct 2010 21:04:17 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 07 Oct 2010 14:04:17 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: 9qFN0U4VM1nhcUSLmGqABhn.gpFX6ft5h2CmuhP67DRcx44 7fuT5RlEul4DUF6brQwoNeHQFAjZXt2YV.mlom2TQC_uc_jNLUb6wKdKfdtP QtJ4wG1pqdItP6Ib23J9tcP_FNQeXjkoMeTG34dxFuN9WPNRiyCZTVz.N7Xo 5NBQBJmLGUofMD__4ZM1w.3fjiMQUI9YIKWOSrhZNFPlMfETqC4X9OFzq7vU Rw7DQXT4PsmYQPEUuxDQKN97VsDO3Q9vakCyn2SsokUew X-Yahoo-Newman-Property: ymail-3 Received: by smtp.irbisnet.com (Postfix, from userid 80) id 2ADE2AC59; Thu, 7 Oct 2010 17:04:17 -0400 (EDT) To: Andriy Gapon MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Thu, 07 Oct 2010 17:04:17 -0400 From: Andriy Bakay In-Reply-To: <4CAE1D72.20208@icyb.net.ua> References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> <4CAE1D72.20208@icyb.net.ua> Message-ID: <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> X-Sender: andriy@irbisnet.com User-Agent: RoundCube Webmail/0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:04:19 -0000 Understood, but is it possible to apply "local" ZFS+UFS related changes? Because STABLE will bring all deltas which was accumulated since RELEASE and I really concern about stability of this box (which is router/firewall/mail server). Other people depend on it. On Thu, 07 Oct 2010 22:20:18 +0300, Andriy Gapon wrote: > on 07/10/2010 21:47 Andriy Bakay said the following: >> I expressed myself incorrectly. Sorry. :-( >> >> Do you Andriy :-) or anybody else from list(s) have more info how to >> fix or work around this issue? > > First, I recommend to try to upgrade to the recent stable/8. From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 22:13:03 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECAE8106566C; Thu, 7 Oct 2010 22:13:03 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0BFE58FC21; Thu, 7 Oct 2010 22:13:02 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA21899; Fri, 08 Oct 2010 01:12:58 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P3yhu-0007fk-G7; Fri, 08 Oct 2010 01:12:58 +0300 Message-ID: <4CAE45EA.5070607@icyb.net.ua> Date: Fri, 08 Oct 2010 01:12:58 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Bakay References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> <4CAE1D72.20208@icyb.net.ua> <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> In-Reply-To: <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:13:04 -0000 on 08/10/2010 00:04 Andriy Bakay said the following: > Understood, but is it possible to apply "local" ZFS+UFS related > changes? Because STABLE will bring all deltas which was accumulated > since RELEASE and I really concern about stability of this box (which is > router/firewall/mail server). Other people depend on it. Nothing is impossible. But it's up to you to separate the changes you want from the changes you don't want. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 22:24:12 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08513106566B for ; Thu, 7 Oct 2010 22:24:12 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by mx1.freebsd.org (Postfix) with SMTP id 7EBD88FC08 for ; Thu, 7 Oct 2010 22:24:11 +0000 (UTC) Received: (qmail 72635 invoked from network); 7 Oct 2010 22:24:10 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp105.rog.mail.re2.yahoo.com with SMTP; 07 Oct 2010 15:24:10 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: MHLmKiYVM1nCf6dolE8mayOGWP5GpV.GpTnmH.jil.ZrLIq tZyG0A3uwJ0JJs49HHtctHmyWYxbRUn.2wx9gqQLX6BPJJWuC287t5JztNB3 _ZJnPblB2Sru.NAoHa6UQowOmZU8Xg6qRlB7nmc9E.B9oIr25pBIhfmcBXI_ DneiWHLhyYM4odIMx1XSZLtZ7RNZs7.24chxqW4bf5fgV9M9eIRskNMDfGRa tU2RtWIncgO4omWhZtShAh2iLYf6b_.G1Tof7R.LJYOtkeV8kMTC_gzF4e2. l_MOX7eTLaB.3pwHyBYwJHAy.LX0NfkDR98yVc.SUrglSow9w1iT6iejT5jy 1t.F_iEdvXqYrtb6FBtTFJXcz_tRinBplxfHguG8QeZBngAtA9Z2qqzYCXZI YsO8vDH_YsaWPkVULX7l4h31J85ZhhFB23VXTGVhSnudl X-Yahoo-Newman-Property: ymail-3 Received: from [10.121.225.39] (unknown [74.198.28.216]) by smtp.irbisnet.com (Postfix) with ESMTPSA id 16105AC78; Thu, 7 Oct 2010 18:24:10 -0400 (EDT) References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> <4CAE1D72.20208@icyb.net.ua> <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> <4CAE45EA.5070607@icyb.net.ua> In-Reply-To: <4CAE45EA.5070607@icyb.net.ua> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7C062F92-B514-49FF-BE28-90B7784A5CB6@irbisnet.com> X-Mailer: iPhone Mail (8B117) From: Andriy Bakay Date: Thu, 7 Oct 2010 18:24:41 -0400 To: Andriy Gapon Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:24:12 -0000 Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is your o= pinion? On 2010-10-07, at 18:12, Andriy Gapon wrote: > on 08/10/2010 00:04 Andriy Bakay said the following: >> Understood, but is it possible to apply "local" ZFS+UFS related >> changes? Because STABLE will bring all deltas which was accumulated >> since RELEASE and I really concern about stability of this box (which is >> router/firewall/mail server). Other people depend on it. >=20 > Nothing is impossible. But it's up to you to separate the changes you wan= t from > the changes you don't want. >=20 > --=20 > Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 23:02:18 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 031CD1065670 for ; Thu, 7 Oct 2010 23:02:18 +0000 (UTC) (envelope-from hywel@hmallett.co.uk) Received: from lisbon.directrouter.com (lisbon.directrouter.com [72.249.30.130]) by mx1.freebsd.org (Postfix) with ESMTP id C893E8FC14 for ; Thu, 7 Oct 2010 23:02:17 +0000 (UTC) Received: from [88.87.193.130] (helo=[192.168.49.80]) by lisbon.directrouter.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P3ytJ-0004Cy-Rm; Thu, 07 Oct 2010 17:24:46 -0500 References: <4CAD6A44.8010707@telus.net> In-Reply-To: <4CAD6A44.8010707@telus.net> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4813F683-1FF0-4DC4-9BC0-A512258C81CA@hmallett.co.uk> X-Mailer: iPhone Mail (8B117) From: Hywel Mallett Date: Fri, 8 Oct 2010 00:21:54 +0200 To: Carl X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - lisbon.directrouter.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hmallett.co.uk X-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-fs@freebsd.org" Subject: Re: Should gmirrored gjournal provider have auto-synchronization? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 23:02:18 -0000 On 7 Oct 2010, at 08:35, Carl wrote: > Suppose I've used a pair of drives laid out with GPT partitions to create a= mirror. Actually, this situation requires that individual partitions be mir= rored instead of the whole drive. Then suppose one of these partitions is to= be gjournaled, but with separate data and journal providers. The separate j= ournal provider will be in another partition. >=20 > I believe I should gmirror the journal provider partition just as I did th= e data provider partition. Correct me if this is wrong. I would gmirror the journal. If it "goes away" unexpectedly, that won't be g= ood for gjournal. I assume it'll panic.=20 > Then, should I be enabling or disabling auto-synchronization for the mirro= red journal provider partition? It is clear to me that it should be disabled= for the mirrored data provider partition because the journaling will ensure= data consistency, but is the content of the journal provider itself guarant= eed consistent under all circumstances? That's an interesting question. I think you're correct that you should be ab= le to disable auto-sync for the data slice, provided that gmirror returns a w= rite as succeeded only when it has been written to both parts of the mirror.= If not, then you could theoretically end up with a situation where data has= only been written to one half of the mirror, but the write has been returne= d as successful, and gjournal won't re-write the data, which would leave you= with an unsynchronized mirror.=20 With gmirror, when you say "guaranteed consistent", you may need to qualify t= hat more. gmirror guarantees that a collection of writes either happens in i= t's entirety, or not at all. If you have for example an msdosfs on top of th= is, there's no guarantee of consistency anyway. With ufs + softupdates, it s= hould guarantee consistency anyway, but the journal allows certain operation= s to be shortcutted.= From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 01:17:51 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAA7D106564A for ; Fri, 8 Oct 2010 01:17:51 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 18A278FC15 for ; Fri, 8 Oct 2010 01:17:50 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 07 Oct 2010 20:49:11 -0400 Received: from mx04.lnh.mail.rcn.net (mx04.lnh.mail.rcn.net [207.172.157.54]) by mr16.lnh.mail.rcn.net (MOS 4.1.9-GA) with ESMTP id AQQ56351; Thu, 7 Oct 2010 20:48:35 -0400 X-Auth-ID: gcorcoran Received: from 64-121-74-167.c3-0.tlg-ubr2.atw-tlg.pa.cable.rcn.com (HELO [10.56.78.161]) ([64.121.74.167]) by smtp04.lnh.mail.rcn.net with ESMTP; 07 Oct 2010 20:48:35 -0400 Message-ID: <4CAE6C3A.5070509@rcn.com> Date: Thu, 07 Oct 2010 20:56:26 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr16.lnh.mail.rcn.net) Subject: ZFS and Samsung Spinpoint F4 4K sector drive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 01:17:51 -0000 I've tried to read up on the issue of using ZFS with 4K sector drives, but haven't seen any definitive answers with regards to FreeBSD. The Samsung Spinpoint F4 is their latest 2TB drive, which has 4K sectors and "emulation", and no info on whether the emulation can be disabled. But it is on sale for the next few days, and the price is very tempting. So I would like to ask: Can these 4K drives, emulating 512 byte sectors, be successfully used with ZFS raidz via _some_ tweak, without getting a major slowdown? That is, is there some sysctl, some option to zpool create, or anything else, that can cause a zpool which uses whole disks, to be aligned to 4K sectors in FreeBSD? Thanks, Gary From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 02:21:08 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8E40106566C for ; Fri, 8 Oct 2010 02:21:08 +0000 (UTC) (envelope-from nowak@xpam.de) Received: from mail.csp-systems.de (mail.csp-systems.de [83.246.83.230]) by mx1.freebsd.org (Postfix) with ESMTP id A3DFC8FC0A for ; Fri, 8 Oct 2010 02:21:08 +0000 (UTC) Received: by mail.csp-systems.de (Postfix, from userid 602) id E7B2768F1D7; Fri, 8 Oct 2010 03:53:25 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.csp-systems.de X-Spam-Level: ** X-Spam-Status: No, score=2.9 required=6.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RDNS_NONE autolearn=no version=3.2.5 Received: from master.sinuspl.net (unknown [83.246.67.202]) by mail.csp-systems.de (Postfix) with ESMTP id 46CF568F187 for ; Fri, 8 Oct 2010 03:53:21 +0200 (CEST) Received: by master.sinuspl.net (Postfix, from userid 8) id ACD851080318; Fri, 8 Oct 2010 03:53:20 +0200 (CEST) Received: from [172.19.191.2] (088156221125.bialystok.vectranet.pl [88.156.221.125]) by master.sinuspl.net (Postfix) with ESMTPA id E65F910801AA for ; Fri, 8 Oct 2010 03:53:19 +0200 (CEST) Message-ID: <4CAE798D.6040905@xpam.de> Date: Fri, 08 Oct 2010 03:53:17 +0200 From: Adam Nowacki User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4CAE6C3A.5070509@rcn.com> In-Reply-To: <4CAE6C3A.5070509@rcn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS and Samsung Spinpoint F4 4K sector drive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 02:21:09 -0000 Nothing user friendly but if you're willing to modify sources and rebuild kernel there is a one line tweak. /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c find: *ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; and modify to something like: *ashift = highbit(MAX(MAX(4096, pp->sectorsize), SPA_MINBLOCKSIZE)) - 1; I'm using this for 3 months with 20 2TB 4kb sector WDC disks (in 2 raidz2 arrays of 10) without any issues. Writes go at 300MB/s. Gary Corcoran wrote: > I've tried to read up on the issue of using ZFS with 4K sector drives, > but haven't seen any definitive answers with regards to FreeBSD. > The Samsung Spinpoint F4 is their latest 2TB drive, which has 4K sectors > and "emulation", and no info on whether the emulation can be disabled. > But it is on sale for the next few days, and the price is very tempting. > > So I would like to ask: Can these 4K drives, emulating 512 byte sectors, > be successfully used with ZFS raidz via _some_ tweak, without getting a > major > slowdown? That is, is there some sysctl, some option to zpool create, or > anything else, that can cause a zpool which uses whole disks, to be aligned > to 4K sectors in FreeBSD? > > Thanks, > Gary > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 03:22:17 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9F81065670 for ; Fri, 8 Oct 2010 03:22:17 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (outbound02.telus.net [199.185.220.221]) by mx1.freebsd.org (Postfix) with ESMTP id 5111C8FC0C for ; Fri, 8 Oct 2010 03:22:17 +0000 (UTC) Received: from edtnaa04.telusplanet.net ([66.183.53.162]) by priv-edtnes28.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20101008032216.OEDG12546.priv-edtnes28.telusplanet.net@edtnaa04.telusplanet.net>; Thu, 7 Oct 2010 21:22:16 -0600 Received: from oliver.bc.lan (d66-183-53-162.bchsia.telus.net [66.183.53.162]) by edtnaa04.telusplanet.net (BorderWare Security Platform) with ESMTP id 90E392D12BF51450; Thu, 7 Oct 2010 21:22:16 -0600 (MDT) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id F2A7762A4; Thu, 7 Oct 2010 20:22:15 -0700 (PDT) Message-ID: <4CAE8E67.3080201@telus.net> Date: Thu, 07 Oct 2010 20:22:15 -0700 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Hywel Mallett References: <4CAD6A44.8010707@telus.net> <4813F683-1FF0-4DC4-9BC0-A512258C81CA@hmallett.co.uk> In-Reply-To: <4813F683-1FF0-4DC4-9BC0-A512258C81CA@hmallett.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=xzQzVvirXe8hBlOIrSXzJe7ImzW1YEUKF9Q3r6h0Mno= c=1 sm=0 a=p-OJjGmPj4MA:10 a=8nJEP1OIZ-IA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:17 a=aatUQebYAAAA:8 a=rt9fHxs5rGgGI8XyeLQA:9 a=u9KkB1HKLPl6r43OOuIA:7 a=AJAAz9zk7vd98phR2PE0T3eqjIMA:4 a=wPNLvfGTeEIA:10 a=rBKJJ2Jc0C4A:10 a=bURaG8XmhAi4FTBd:21 a=lOOtqiMLxKmJ6CIv:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: "freebsd-fs@freebsd.org" Subject: Re: Should gmirrored gjournal provider have auto-synchronization? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 03:22:17 -0000 On 2010-10-07 3:21 PM, Hywel Mallett wrote: > On 7 Oct 2010, at 08:35, Carl wrote: >> Then, should I be enabling or disabling auto-synchronization for >> the mirrored journal provider partition? It is clear to me that it >> should be disabled for the mirrored data provider partition because >> the journaling will ensure data consistency, but is the content of >> the journal provider itself guaranteed consistent under all >> circumstances? > > That's an interesting question. I think you're correct that you > should be able to disable auto-sync for the data slice, provided that > gmirror returns a write as succeeded only when it has been written to > both parts of the mirror. If not, then you could theoretically end up > with a situation where data has only been written to one half of the > mirror, but the write has been returned as successful, and gjournal > won't re-write the data, which would leave you with an unsynchronized > mirror. With gmirror, when you say "guaranteed consistent", you may > need to qualify that more. gmirror guarantees that a collection of > writes either happens in it's entirety, or not at all. My admittedly limited understanding of gmirror is that it makes no such guarantee. I think it is gjournal that guarantees the consistency of the file system that sits on top of it, not gmirror, and this would be true even if there were no gmirror below it. The gjournal(8) man page tells us that when gmirror does exist below gjournal that gmirror's auto-sync need not be enabled because of that consistency guarantee. But again, we've been given a guarantee that the file system is consistent, but no where (that I can find) are we told whether the design of the journal itself is such that it too is guaranteed consistent. My best guess is that a separate journal provider is inherently guaranteed consistent. My reasoning is that when it is not separate (ie. data and journal share same provider) we are told that we can disable auto-sync if gmirror is below it, which seems like bad advice if the consistency guarantee applies only to the data and not the journal. It would nonetheless be nice to have a confirmation that auto-synchronization can be disabled safely for a separate journal provider. Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 06:24:13 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B159106564A; Fri, 8 Oct 2010 06:24:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6E38FC1E; Fri, 8 Oct 2010 06:24:11 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA27952; Fri, 08 Oct 2010 09:24:07 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P46ND-000A80-7y; Fri, 08 Oct 2010 09:24:07 +0300 Message-ID: <4CAEB906.10603@icyb.net.ua> Date: Fri, 08 Oct 2010 09:24:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Bakay References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> <4CAE1D72.20208@icyb.net.ua> <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> <4CAE45EA.5070607@icyb.net.ua> <7C062F92-B514-49FF-BE28-90B7784A5CB6@irbisnet.com> In-Reply-To: <7C062F92-B514-49FF-BE28-90B7784A5CB6@irbisnet.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 06:24:13 -0000 on 08/10/2010 01:24 Andriy Bakay said the following: > Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is your opinion? I use it all the time :-) (And head too). In general, and this opinion is not only my own, the best FreeBSD "release" is the latest stable branch. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 09:17:00 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E822106564A for ; Fri, 8 Oct 2010 09:17:00 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3865F8FC16 for ; Fri, 8 Oct 2010 09:17:00 +0000 (UTC) Received: by gxk8 with SMTP id 8so334632gxk.13 for ; Fri, 08 Oct 2010 02:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5rkxwrH/kKplo6ulg1bx/CBW+UL1nOrRs4fuguEKiMA=; b=YyDZj9siGOf9uIWOKlAnCsz3VVLTUiakqSLorh3O3cz17+DN1zlcG99Opp9fS0FaAN CCDn6tnt0J7zdBL4VZ3898COTUqLDNAXFvD3opkBeLx7/8dcr5R5Z/lqWM9OqJsu7UAe pPTF7aZovItO6wxhwtq7NK7qZ74T3L2U68dU0= 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=L0/YXC5RTUP+WS3hTXi98kOWDrTsY5/Xbgx7buI1OTQkyZ+8nx0RUouAs5ayorX522 olbCVDqqPP8jWrLrDAMfqqOr2R/JRfuJIplRAwMr9BiNaM2YQMyIoWNms12+jCpCRPj4 sr0VHoAzjLJ7T3oGJbIKGvn/AJyX639ct0fAY= MIME-Version: 1.0 Received: by 10.151.108.6 with SMTP id k6mr2596130ybm.186.1286527883298; Fri, 08 Oct 2010 01:51:23 -0700 (PDT) Received: by 10.150.229.20 with HTTP; Fri, 8 Oct 2010 01:51:23 -0700 (PDT) In-Reply-To: <4CAE798D.6040905@xpam.de> References: <4CAE6C3A.5070509@rcn.com> <4CAE798D.6040905@xpam.de> Date: Fri, 8 Oct 2010 01:51:23 -0700 Message-ID: From: Xin LI To: Adam Nowacki Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and Samsung Spinpoint F4 4K sector drive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 09:17:00 -0000 On Thu, Oct 7, 2010 at 6:53 PM, Adam Nowacki wrote: > Nothing user friendly but if you're willing to modify sources and rebuild > kernel there is a one line tweak. > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c find: > *ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; > and modify to something like: > *ashift = highbit(MAX(MAX(4096, pp->sectorsize), SPA_MINBLOCKSIZE)) - 1; > I'm using this for 3 months with 20 2TB 4kb sector WDC disks (in 2 raidz2 > arrays of 10) without any issues. Writes go at 300MB/s. Just a suggestion - pp->stripesize might be better than hard coding 4096 for here when the drive, potentially a hardware RAID or some SSD, etc, and reports a higher value via GEOM framework. Cheers, -- Xin LI http://www.delphij.net From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 09:59:46 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87513106566C; Fri, 8 Oct 2010 09:59:46 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF9A8FC18; Fri, 8 Oct 2010 09:59:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o989xkEX032471; Fri, 8 Oct 2010 09:59:46 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o989xkhD032467; Fri, 8 Oct 2010 09:59:46 GMT (envelope-from jh) Date: Fri, 8 Oct 2010 09:59:46 GMT Message-Id: <201010080959.o989xkhD032467@freefall.freebsd.org> To: jeffb.misc@gmail.com, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/133150: [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while writing data X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 09:59:46 -0000 Synopsis: [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while writing data State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri Oct 8 09:59:45 UTC 2010 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=133150 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 10:00:31 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20B2F1065693 for ; Fri, 8 Oct 2010 10:00:31 +0000 (UTC) (envelope-from gvidals@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A7E7B8FC12 for ; Fri, 8 Oct 2010 10:00:30 +0000 (UTC) Received: by fxm4 with SMTP id 4so159971fxm.13 for ; Fri, 08 Oct 2010 03:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=9jaCMwt3+oDTOBddU5RQld517g6gW8ZuZRm6hcW9G3k=; b=nczV/5J2UFWRaQS8ynXIixBINJeXAOPrqprdQwnO9me3FUiehYTLSStkEGcok1BICt l2G9Ga4So2xYULoobm3//SSXODA/6240gTPwE5lD232T7ijO+uACbIPIkgLsakUON4G0 66YyP0tTrcO7nF/nsBzIlCrs4RuFSLqZsNu+k= 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=ueMieFkdiN4I+6vS64SQPeWk6a7IU7AQYZ5VDTksJpZW+Btki0tiFok5oCBaQcj476 B5Ht3+JVWpY20pmAiPCkz2rymIdsPla1y4h1c1F5YtePKbv0tAo5jtyZroYKeOAeZc15 Ugpzb4Rsw7FzRFukEO/+Kb1JXDnt78/1tqjtQ= MIME-Version: 1.0 Received: by 10.239.172.69 with SMTP id z5mr105809hbe.170.1286532028446; Fri, 08 Oct 2010 03:00:28 -0700 (PDT) Received: by 10.239.153.75 with HTTP; Fri, 8 Oct 2010 03:00:28 -0700 (PDT) Date: Fri, 8 Oct 2010 03:00:28 -0700 Message-ID: From: Gil Vidals To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: moving away from freebsd and zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gil@vidals.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 10:00:31 -0000 I'm hoping that somebody can help me as I've spent about a month studying FreeBSD + ZFS to use as a NAS for my VMware ESX environment; however, it looks like my hopes were completely dashed yesterday as my ZFS server based on 64-bit i7 CPU with 8 GB of RAM and SSD slogs came crumbling down when I added a second NFS mount point. After several hours of research on the crash, it seems that FreeBSD 8.1 won't launch more than one nfsd, no matter what is configured in rc.conf. (FreeBSD 7.x does launch multiple NFS daemons). So when I added my second mount point, the CPU load went very high for the RPC services and the second NFS mount point disconnected, brining down the running VMs. PROBLEM: only one nfsd zambia# ps waux | grep nfs root 1213 0.0 0.0 5804 1508 ?? Is 5:23PM 0:00.02 nfsd: master (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 8:06.88 nfsd: server (nfsd) The solution described here, http://forums.freebsd.org/showthread.php?t=11873 points to compiling a kernel with these options: options NFSD options DEVICE_POLLING options HZ=1000 The NFSD seems to be what solved the problem for the forum poster, but NFSD option means that NFSv4 (experimental) is what is running and that isn't supported by the VMware NFS client, so I can't use it. I don't know what to do and I would be grateful for any suggestions. Gil Vidals / VMRacks.com [image: Reply With Quote] From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 10:02:34 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1B47106564A; Fri, 8 Oct 2010 10:02:34 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 875F58FC0C; Fri, 8 Oct 2010 10:02:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o98A2YQP044932; Fri, 8 Oct 2010 10:02:34 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o98A2Yui044928; Fri, 8 Oct 2010 10:02:34 GMT (envelope-from jh) Date: Fri, 8 Oct 2010 10:02:34 GMT Message-Id: <201010081002.o98A2Yui044928@freefall.freebsd.org> To: killasmurf86@gmail.com, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/137037: [zfs] [hang] zfs rollback on root causes FreeBSD to freeze in few seconds X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 10:02:34 -0000 Synopsis: [zfs] [hang] zfs rollback on root causes FreeBSD to freeze in few seconds State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri Oct 8 10:02:34 UTC 2010 State-Changed-Why: Not a problem on 8.1 according to submitter. http://www.freebsd.org/cgi/query-pr.cgi?pr=137037 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 10:11:43 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20AF6106566B; Fri, 8 Oct 2010 10:11:43 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id B80CD8FC17; Fri, 8 Oct 2010 10:11:42 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1P49vP-000AcZ-BX; Fri, 08 Oct 2010 11:11:39 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P49vP-000NDI-Ah; Fri, 08 Oct 2010 11:11:39 +0100 Date: Fri, 08 Oct 2010 11:11:39 +0100 Message-Id: To: andriy@irbisnet.com, avg@icyb.net.ua In-Reply-To: <7C062F92-B514-49FF-BE28-90B7784A5CB6@irbisnet.com> From: Pete French Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 10:11:43 -0000 > Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is your opinion? I am running 8-STABLE from 27th September on all our ptoduction machines (from webservers to database servers to the company mail server) and it is fine. I am going to update again over the next few days, as there are some ZFS fixes in which I want - and which may benifit you too - so I will be able to report back next week as to how a more recent version behaves. In general though, I have never had problems running STABLE on prodyction systems over the years. Of course what I do is to test it on a singlre machine before rolling it out (a leaf in a webfarm so if it goes down it wont affect the business) but it is usually fine. keep an eye on -STABLE mailing list though, as that is where problems arise. I watch that, and also the dailing commits, either here http://www.freshbsd.org/?branch=RELENG_8&project=freebsd&committer=&module=&q= or here http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/8 Just to see whats going into the tree relative to whats being discussed. It only takes a few minutes a dat to monitor the mailin lists and the commits, and the result is that we've been running STABLE for a very long time (close to a decade I suspect) with great success. -pete. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 10:29:09 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3108E106566C; Fri, 8 Oct 2010 10:29:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 06ECD8FC13; Fri, 8 Oct 2010 10:29:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o98AT8CG067657; Fri, 8 Oct 2010 10:29:08 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o98AT8ZE067653; Fri, 8 Oct 2010 10:29:08 GMT (envelope-from linimon) Date: Fri, 8 Oct 2010 10:29:08 GMT Message-Id: <201010081029.o98AT8ZE067653@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147560: [zfs] [boot] Booting 8.1-PRERELEASE raidz system take ages X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 10:29:09 -0000 Old Synopsis: [boot] Booting 8.1-PRERELEASE raidz system take ages New Synopsis: [zfs] [boot] Booting 8.1-PRERELEASE raidz system take ages Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 8 10:28:51 UTC 2010 Responsible-Changed-Why: apparently ZFS-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=147560 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 11:00:34 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E81A106566B for ; Fri, 8 Oct 2010 11:00:34 +0000 (UTC) (envelope-from marco@tolstoy.tols.org) Received: from tolstoy.tols.org (tolstoy.tols.org [IPv6:2a02:898:0:20::57:1]) by mx1.freebsd.org (Postfix) with ESMTP id A855E8FC22 for ; Fri, 8 Oct 2010 11:00:33 +0000 (UTC) Received: from tolstoy.tols.org (localhost [127.0.0.1]) by tolstoy.tols.org (8.14.4/8.14.4) with ESMTP id o98B0Unn096343; Fri, 8 Oct 2010 11:00:30 GMT (envelope-from marco@tolstoy.tols.org) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.3 at tolstoy.tols.org Received: (from marco@localhost) by tolstoy.tols.org (8.14.4/8.14.4/Submit) id o98B0UXn096342; Fri, 8 Oct 2010 13:00:30 +0200 (CEST) (envelope-from marco) Date: Fri, 8 Oct 2010 13:00:30 +0200 From: Marco van Tol To: gil@vidals.net Message-ID: <20101008110030.GD94234@tolstoy.tols.org> Mail-Followup-To: gil@vidals.net, freebsd-fs@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 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on tolstoy.tols.org Cc: freebsd-fs@freebsd.org Subject: Re: moving away from freebsd and zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 11:00:34 -0000 On Fri, Oct 08, 2010 at 03:00:28AM -0700, Gil Vidals wrote: > I'm hoping that somebody can help me as I've spent about a month studying > FreeBSD + ZFS to use as a NAS for my VMware ESX environment; however, it > looks like my hopes were completely dashed yesterday as my ZFS server based > on 64-bit i7 CPU with 8 GB of RAM and SSD slogs came crumbling down when I > added a second NFS mount point. > > After several hours of research on the crash, it seems that FreeBSD 8.1 > won't launch more than one nfsd, no matter what is configured in rc.conf. > (FreeBSD 7.x does launch multiple NFS daemons). So when I added my second > mount point, the CPU load went very high for the RPC services and the second > NFS mount point disconnected, brining down the running VMs. Check out the '-n' flag to nfsd, which is defaulted to 4 in /etc/defaults/rc.conf through nfs_server_flags. > PROBLEM: only one nfsd > zambia# ps waux | grep nfs > root 1213 0.0 0.0 5804 1508 ?? Is 5:23PM 0:00.02 nfsd: master > (nfsd) > root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 8:06.88 nfsd: server > (nfsd) Try this one with 'ps Hjax | grep nfs'. The capital H is used to display threads next to processes. Add w flags to ps if necessary. > The solution described here, > http://forums.freebsd.org/showthread.php?t=11873 points to compiling a > kernel with these options: > > options NFSD > options DEVICE_POLLING > options HZ=1000 > > The NFSD seems to be what solved the problem for the forum poster, but NFSD > option means that NFSv4 (experimental) is what is running and that isn't > supported by the VMware NFS client, so I can't use it. I don't know what to > do and I would be grateful for any suggestions. I haven't got much experience with nfs4, sorry. :) Marco -- Most general statements are false, including this one. - Alexander Dumas From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 12:30:46 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04D6310656A6 for ; Fri, 8 Oct 2010 12:30:46 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id BD9B18FC18 for ; Fri, 8 Oct 2010 12:30:45 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1P4C60-000BRT-9q; Fri, 08 Oct 2010 13:30:44 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4C60-000O4X-8u; Fri, 08 Oct 2010 13:30:44 +0100 Date: Fri, 08 Oct 2010 13:30:44 +0100 Message-Id: To: freebsd-fs@freebsd.org, gvidals@gmail.com In-Reply-To: From: Pete French Cc: Subject: Re: moving away from freebsd and zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 12:30:46 -0000 > After several hours of research on the crash, it seems that FreeBSD 8.1 > won't launch more than one nfsd, no matter what is configured in rc.conf. > (FreeBSD 7.x does launch multiple NFS daemons). So when I added my second > mount point, the CPU load went very high for the RPC services and the second > NFS mount point disconnected, brining down the running VMs. > > PROBLEM: only one nfsd > zambia# ps waux | grep nfs > root 1213 0.0 0.0 5804 1508 ?? Is 5:23PM 0:00.02 nfsd: master (nfsd) > root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 8:06.88 nfsd: server (nfsd) try adding '-H' to the 'ps' line and see if you can see all your nfs daemons - as far as I know the nfsd in 8.x is multi-threaded so instead of luaunching multiple processes you get a single process with the number of threads defined. e.g., on my server: [pete@skerry ~]$ ps waux | grep nfs root 1479 0.0 0.0 5824 944 ?? Is 28Sep10 0:00.01 nfsd: master (nfsd) root 1480 0.0 0.0 5824 944 ?? S 28Sep10 0:07.48 nfsd: server (nfsd [pete@skerry ~]$ grep nfs /etc/rc.conf nfs_server_enable="YES" nfs_server_flags="-t -n 4 -a" nfs_client_enable="YES" [pete@skerry ~]$ ps wauxH | grep nfs root 1479 0.0 0.0 5824 944 ?? Is 28Sep10 0:00.01 nfsd: master (nfsd) root 1480 0.0 0.0 5824 944 ?? S 28Sep10 0:01.91 nfsd: server (nfsd) root 1480 0.0 0.0 5824 944 ?? S 28Sep10 0:01.90 nfsd: server (nfsd) root 1480 0.0 0.0 5824 944 ?? S 28Sep10 0:01.85 nfsd: server (nfsd) root 1480 0.0 0.0 5824 944 ?? S 28Sep10 0:01.82 nfsd: server (nfsd) ...and there they all are, all four of them. So it looks like you were running as many nfsd processes as you thought - which makes the crash caused by something different I guess :-( -pete. From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 12:31:20 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEEB3106566B for ; Fri, 8 Oct 2010 12:31:20 +0000 (UTC) (envelope-from weldon@excelsusphoto.com) Received: from mx0.excelsus.net (emmett.excelsus.com [74.93.113.252]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF938FC25 for ; Fri, 8 Oct 2010 12:31:20 +0000 (UTC) Received: (qmail 44630 invoked by uid 89); 8 Oct 2010 12:03:17 -0000 Received: by simscan 1.2.0 ppid: 44623, pid: 44627, t: 0.5290s scanners: clamav: 0.96.3/m: Received: from unknown (HELO 228.sub-70-210-69.myvzw.com) (weldon@excelsusphoto.com@70.210.69.228) by emmett.excelsus.com with ESMTPA; 8 Oct 2010 12:03:17 -0000 X-User-Agent: K-9 Mail for Android References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit From: Weldon Godfrey Date: Fri, 08 Oct 2010 07:03:22 -0500 To: gil@vidals.net,freebsd-fs@freebsd.org Message-ID: Cc: Subject: Re: moving away from freebsd and zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 12:31:21 -0000 nfsd runs in multiple threads now...which you can see with top. the default limit is 4. you can increase this limit with a sysctl varible (dont remember exactly the name but it is obvious with sysctl -a | grep nfs ) you do not need multiple nfsd deamons with multiple nfs shares. you will need enough threads to serve requests from clients. i would just up the threads to 100 to start. if you up the count with the sysctl varible...it will increase on the fly. set this also in /etc/sysctl.conf so it is set on reboot "Gil Vidals" wrote: >I'm hoping that somebody can help me as I've spent about a month studying >FreeBSD + ZFS to use as a NAS for my VMware ESX environment; however, it >looks like my hopes were completely dashed yesterday as my ZFS server based >on 64-bit i7 CPU with 8 GB of RAM and SSD slogs came crumbling down when I >added a second NFS mount point. > >After several hours of research on the crash, it seems that FreeBSD 8.1 >won't launch more than one nfsd, no matter what is configured in rc.conf. >(FreeBSD 7.x does launch multiple NFS daemons). So when I added my second >mount point, the CPU load went very high for the RPC services and the second >NFS mount point disconnected, brining down the running VMs. > >PROBLEM: only one nfsd >zambia# ps waux | grep nfs >root 1213 0.0 0.0 5804 1508 ?? Is 5:23PM 0:00.02 nfsd: master >(nfsd) >root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 8:06.88 nfsd: server >(nfsd) > >The solution described here, >http://forums.freebsd.org/showthread.php?t=11873 points to compiling a >kernel with these options: > > options NFSD > options DEVICE_POLLING > options HZ=1000 > >The NFSD seems to be what solved the problem for the forum poster, but NFSD >option means that NFSv4 (experimental) is what is running and that isn't >supported by the VMware NFS client, so I can't use it. I don't know what to >do and I would be grateful for any suggestions. > >Gil Vidals / VMRacks.com > > > >[image: Reply With >Quote] >_______________________________________________ >freebsd-fs@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-fs >To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 14:46:26 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 431D2106564A; Fri, 8 Oct 2010 14:46:26 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 34E6C8FC0A; Fri, 8 Oct 2010 14:46:25 +0000 (UTC) Received: by fxm4 with SMTP id 4so373570fxm.13 for ; Fri, 08 Oct 2010 07:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=XN7sqWsZl4Y2WJyuTFhlYf3kSJWc2pgoLWr42ZKaF6c=; b=L4HGKLJOP4B87Z1pe4CgcDgEAaeZjcc5BKJRYqN4ZcM/UnsaeuwXajkR4yitMkGg7N 1ajfaxF6IsOs/EtUYHbJmLMIiFShrc2Oqn//iyXdAKEOhXxGbw5WJ+gETlRgBzSG5maY DtCUcHj+a8lwBIMtDbS+V/eJgKS8+p+v8hL9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=g7YHQGFWR8o5GLk23icwTAuXWchAXATUyMK1Lm2wj/o/318fUncB7zUmgSoVdAwEQJ CWCUBOJxKx0im+Xw+rboaj90WGOvvOjDWE3Ztb+Pxyo6iAjuUmT6vqFE5HOjngrqG8Ve wEG1/CJA/Xnr3WVmPfqAS3NQb3Ub1rM6zclaE= Received: by 10.223.125.207 with SMTP id z15mr3246880far.107.1286549184276; Fri, 08 Oct 2010 07:46:24 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id 10sm1666018fax.18.2010.10.08.07.46.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Oct 2010 07:46:17 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek Organization: TOA Ukraine References: <86hbh44wgl.fsf@kopusha.home.net> <86aamw4l42.fsf@kopusha.home.net> <20101004213647.GK7322@garage.freebsd.pl> <86tyl1m85y.fsf@zhuzha.ua1> <20101005074736.GM7322@garage.freebsd.pl> <20101007182436.GB1733@garage.freebsd.pl> Date: Fri, 08 Oct 2010 17:45:49 +0300 In-Reply-To: <20101007182436.GB1733@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Thu, 7 Oct 2010 20:24:36 +0200") Message-ID: <86lj68n3oi.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-fs@freebsd.org Subject: Re: hastd: assertion (res->hr_event != NULL) fails in secondary on split-brain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 14:46:26 -0000 --=-=-= On Thu, 7 Oct 2010 20:24:36 +0200 Pawel Jakub Dawidek wrote: PJD> On Tue, Oct 05, 2010 at 09:47:36AM +0200, Pawel Jakub Dawidek wrote: >> On Tue, Oct 05, 2010 at 10:05:13AM +0300, Mikolaj Golub wrote: >> > >> > On Mon, 4 Oct 2010 23:36:47 +0200 Pawel Jakub Dawidek wrote: >> > >> > PJD> I see three problems:) >> > >> > PJD> 1. In child_kill() you interpret status value always, even if it is >> > PJD> invalid due to earlier errors. >> > PJD> 2. While copying the code you changed style. Don't you like style(9)?:) >> > >> > Me like :-). But it looks like my emacs don't. Need to teach it somehow... >> > >> > PJD> 3. The patch doesn't fix the root cause of the problem. >> > >> > Thank you for your comments. >> >> The hang you reported is still not fixed, but I'm working on it. PJD> Could you verify if the primary/secondary loop doesn't cause hangs PJD> anymore with most recent hast? It doesn't, thanks! But to test I had to run hastd with two changes. The first was needed to fix the issue that described in Subject :-) (adding (res->hr_event != NULL) check in child_cleanup() -- you wrote that the fix was correct but did not commit it). The second one was needed to fix the issue that I observed after the latest commit r213533: Oct 8 16:14:04 hasta hastd[2175]: [storage] (primary) G_GATE_CMD_START failed: Invalid argument. Oct 8 16:14:04 hasta kernel: Version mismatch 0 != 2. Zerroing hio->hio_ggio we clear version and data pointer. This looks wrong for me -- they are set and allocated in init_environment(). Also it looks like setting ggio->gctl_length = MAXPHYS is not needed here too. See the attached patch. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=hastd.patch Index: sbin/hastd/control.c =================================================================== --- sbin/hastd/control.c (revision 213573) +++ sbin/hastd/control.c (working copy) @@ -58,8 +58,10 @@ child_cleanup(struct hast_resource *res) proto_close(res->hr_ctrl); res->hr_ctrl = NULL; - proto_close(res->hr_event); - res->hr_event = NULL; + if (res->hr_event != NULL) { + proto_close(res->hr_event); + res->hr_event = NULL; + } res->hr_workerpid = 0; } Index: sbin/hastd/primary.c =================================================================== --- sbin/hastd/primary.c (revision 213573) +++ sbin/hastd/primary.c (working copy) @@ -930,9 +930,7 @@ ggate_recv_thread(void *arg) QUEUE_TAKE2(hio, free); pjdlog_debug(2, "ggate_recv: (%p) Got free request.", hio); ggio = &hio->hio_ggio; - bzero(ggio, sizeof(*ggio)); ggio->gctl_unit = res->hr_ggateunit; - ggio->gctl_length = MAXPHYS; ggio->gctl_error = 0; pjdlog_debug(2, "ggate_recv: (%p) Waiting for request from the kernel.", --=-=-=-- From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 15:10:33 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66EEB1065774 for ; Fri, 8 Oct 2010 15:10:33 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 0DDAE8FC1B for ; Fri, 8 Oct 2010 15:10:32 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8C5B745C9C; Fri, 8 Oct 2010 17:10:30 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 85A0145C9B; Fri, 8 Oct 2010 17:10:23 +0200 (CEST) Date: Fri, 8 Oct 2010 17:09:57 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20101008150957.GH1733@garage.freebsd.pl> References: <86hbh44wgl.fsf@kopusha.home.net> <86aamw4l42.fsf@kopusha.home.net> <20101004213647.GK7322@garage.freebsd.pl> <86tyl1m85y.fsf@zhuzha.ua1> <20101005074736.GM7322@garage.freebsd.pl> <20101007182436.GB1733@garage.freebsd.pl> <86lj68n3oi.fsf@zhuzha.ua1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X+nYw8KZ/oNxZ8JS" Content-Disposition: inline In-Reply-To: <86lj68n3oi.fsf@zhuzha.ua1> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: hastd: assertion (res->hr_event != NULL) fails in secondary on split-brain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:10:33 -0000 --X+nYw8KZ/oNxZ8JS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 08, 2010 at 05:45:49PM +0300, Mikolaj Golub wrote: > But to test I had to run hastd with two changes. The first was needed to = fix > the issue that described in Subject :-) (adding (res->hr_event !=3D NULL)= check > in child_cleanup() -- you wrote that the fix was correct but did not comm= it > it).=20 Ah, right, thanks for the reminder! > The second one was needed to fix the issue that I observed after the late= st > commit r213533: >=20 > Oct 8 16:14:04 hasta hastd[2175]: [storage] (primary) G_GATE_CMD_START f= ailed: Invalid argument. > Oct 8 16:14:04 hasta kernel: Version mismatch 0 !=3D 2. >=20 > Zerroing hio->hio_ggio we clear version and data pointer. This looks wron= g for > me -- they are set and allocated in init_environment(). Also it looks like > setting ggio->gctl_length =3D MAXPHYS is not needed here too. See the att= ached > patch. Zeroing ggio is indeed a bug, but setting gctl_length to MAXPHYS is correct. By setting it for G_GATE_CMD_START we declare how much memory do we have in the passed buffer and the GEOM_GATE class updates this field with the I/O request size, so we need to set gctl_length back to MAXPHYS before every G_GATE_CMD_START. We could remove setting it from init_environment(), but I kinda like it there for consistency. All should be now committed, thanks! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --X+nYw8KZ/oNxZ8JS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyvNEUACgkQForvXbEpPzRJlwCeJXpaszitDzBX8ljFGA+Pa+g0 zvcAoJE/xon0WQcuQkzRq1WVmBO22gUW =GaQz -----END PGP SIGNATURE----- --X+nYw8KZ/oNxZ8JS-- From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 15:19:10 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4EB9106566C for ; Fri, 8 Oct 2010 15:19:10 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 50D368FC0A for ; Fri, 8 Oct 2010 15:19:09 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX1/fLTiF8p2ELvuc74FyKm2jD/prQbn4XXk@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id o98FJ76Z054742; Fri, 8 Oct 2010 16:19:07 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o98FJ7s7026878; Fri, 8 Oct 2010 16:19:07 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o98FJ7qJ026875; Fri, 8 Oct 2010 16:19:07 +0100 Date: Fri, 8 Oct 2010 16:19:07 +0100 Message-Id: <201010081519.o98FJ7qJ026875@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org In-reply-to: (message from Kai Gallasch on Wed, 6 Oct 2010 20:51:49 +0200) References: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> <201010061732.o96HW2Vi005945@higson.cam.lispworks.com> Subject: Re: Locked up processes after upgrade to ZFS v15 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:19:10 -0000 >>>>> On Wed, 6 Oct 2010 20:51:49 +0200, Kai Gallasch said: > > Am 06.10.2010 um 19:32 schrieb Martin Simmons: > > >>>>>> On Wed, 6 Oct 2010 14:28:31 +0200, Kai Gallasch said: > >> > >> How can I debug this and get further information? > > > > procstat -k -k $pid will generate a backtrace (or replace $pid by -a for all > > processes). > > procstat for process 12111 (state: zfs) > sonnenkraft:~ # procstat -k -k 12111 > PID TID COMM TDNAME KSTACK > 12111 102385 httpd - mi_switch+0x21b sleepq_switch+0x123 sleepq_wait+0x4d __lockmgr_args+0x7ae vop_stdlock+0x39 VOP_LOCK1_APV+0x9b _vn_lock+0x57 vget+0x7b cache_lookup+0x4e0 vfs_cache_lookup+0xc0 VOP_LOOKUP_APV+0xb7 lookup+0x3d3 namei+0x457 vn_open_cred+0x1e3 kern_openat+0x181 syscall+0x102 Xfast_syscall+0xe2 It looks like this thread is waiting for a lock. So the question is, which thread is holding the lock? It might be possible to see from procstat -k -k -a but otherwise I think you will need to run it with kdb and look at the lock. __Martin From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 16:25:04 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA918106566B for ; Fri, 8 Oct 2010 16:25:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 016328FC19 for ; Fri, 8 Oct 2010 16:25:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08865; Fri, 08 Oct 2010 19:24:09 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CAF45A8.3020401@icyb.net.ua> Date: Fri, 08 Oct 2010 19:24:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Kai Gallasch References: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> <201010061732.o96HW2Vi005945@higson.cam.lispworks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Locked up processes after upgrade to ZFS v15 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 16:25:04 -0000 on 06/10/2010 21:51 Kai Gallasch said the following: > > Am 06.10.2010 um 19:32 schrieb Martin Simmons: > >>>>>>> On Wed, 6 Oct 2010 14:28:31 +0200, Kai Gallasch said: >>> >>> How can I debug this and get further information? >> >> procstat -k -k $pid will generate a backtrace (or replace $pid by -a for all >> processes). > > procstat for process 12111 (state: zfs) > sonnenkraft:~ # procstat -k -k 12111 > PID TID COMM TDNAME KSTACK > 12111 102385 httpd - mi_switch+0x21b sleepq_switch+0x123 sleepq_wait+0x4d __lockmgr_args+0x7ae vop_stdlock+0x39 VOP_LOCK1_APV+0x9b _vn_lock+0x57 vget+0x7b cache_lookup+0x4e0 vfs_cache_lookup+0xc0 VOP_LOOKUP_APV+0xb7 lookup+0x3d3 namei+0x457 vn_open_cred+0x1e3 kern_openat+0x181 syscall+0x102 Xfast_syscall+0xe2 > > procstat for process 24731 (state: zfsmrb) > # procstat -k -k 24731 > PID TID COMM TDNAME KSTACK > 24731 102273 httpd - mi_switch+0x21b sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x369 zfs_freebsd_read+0x2a6 VOP_READ_APV+0xaf vnode_pager_generic_getpages+0x3ea VOP_GETPAGES_APV+0xb5 vnode_pager_getpages+0x8c vm_fault+0x685 trap_pfault+0x128 trap+0x52c calltrap+0x8 > > In my original post I wrote that only apache httpd processes would lock up.. > This is wrong. Several other non-httpd processes also got stuck in state zfs or zfsmrb. Interesting. It's possible that TID 102385 might be waiting on a vnode lock held by TID 102273. But TID 102273 seems to be waiting on a vnode's page lock. It would be very interesting to learn what process has that page busy, for how long and why. Perhaps there is a code path that busies a page, but never un-busies it... -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 17:06:40 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C8F1106564A for ; Fri, 8 Oct 2010 17:06:40 +0000 (UTC) (envelope-from gvidals@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CA0958FC13 for ; Fri, 8 Oct 2010 17:06:39 +0000 (UTC) Received: by fxm4 with SMTP id 4so535571fxm.13 for ; Fri, 08 Oct 2010 10:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=OH2ZTs60mzopinUmffKQG6IXrIFMPUH+56VaCsrPXgY=; b=ismkF9jXsyXB8t5JLF8Uk42h0UGHYXZaODvIw9QQ2Nfi16IhifXaYK0sgkSW/mtMQw dY25N095ub/SxtlnG1nfwwfPpRwFEH5JxPwztCV5V/ocybt//W7g5j1CCi/4owSAXw0Q +FvffiXX8s32vbFrccmvztl0hhkckBq6OBuDE= 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=YTF5/8aZZ7+S4SF7bq4Pm9Sb/J0bE25QopdDAG6P1jFkf5vyvmi2DIhYJZgJKrukal COb4wUhxymakccXVo2wkezqej4qfJAvTE2BJLzi/tC+sBy/+2GqtsMRmULkySTkajz2+ bBkD1hKSTYDVfMncp5yaBR4ItGGbq1o63AdTU= MIME-Version: 1.0 Received: by 10.239.193.68 with SMTP id h4mr149503hbi.144.1286557598634; Fri, 08 Oct 2010 10:06:38 -0700 (PDT) Received: by 10.239.153.75 with HTTP; Fri, 8 Oct 2010 10:06:38 -0700 (PDT) Date: Fri, 8 Oct 2010 10:06:38 -0700 Message-ID: From: Gil Vidals To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: rpcsvc wcpu 500% X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gil@vidals.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:06:40 -0000 My FreeBSD 8.1 running 64-bit / 8 GB of RAM from two mirrored HP USB Sticks. The FreeBSD 8.1 server is a new NAS for my ESX Hosting environment. The file system I am using is ZFS and the ESX hosts connect as clients to the NAS. I am using link aggregation on two NICs. The FreeBSD NAS hung when WCPU went to 500 percent. It happened after I started a second mount point from my ESX Host to the NFS store. Since I read a thread from another soul who experience the similar situation when launching VMs on a SECOND mount point (NFS), the assumption was that FreeBSD 8.1 doesn't run more than one NFS Server and that is what causes the crash, but I've been corrected by others in this forum. FreeBSD 8.1 runs one NFS Master and Server, but many threads. I do now see that with the ps wauxH | grep nfs command. In any case, I'm back to square one. How should I go about investigating what caused the RPCSVC spike to 500% causing my VMs to hang and I had to hard reboot the server? (i tried shutting down nfsd, but that just hung). last pid: 3899; load averages: 0.00, 0.00, 0.00 up 0+15:58:33 09:21:15 62 processes: 1 running, 61 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 18M Active, 11M Inact, 2163M Wired, 4K Cache, 557M Buf, 5719M Free Swap: 3942M Total, 3942M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1214 root 24 44 0 5804K 1588K rpcsvc 2 8:38 0.00% nfsd <======= WCPU had spiked to 500% zambia# ps wauxH | grep nfs root 1213 0.0 0.0 5804 1508 ?? Is 5:23PM 0:00.03 nfsd: master (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.79 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:22.25 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.02 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.17 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.77 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.31 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:20.15 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.99 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.86 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:23.37 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:22.36 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:22.57 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:20.13 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:22.62 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.30 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:22.47 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:20.99 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:22.24 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.26 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:22.09 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.72 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:20.60 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.07 nfsd: server (nfsd) root 1214 0.0 0.0 5804 1588 ?? S 5:23PM 0:21.03 nfsd: server (nfsd) Thanks, Gil Vidals From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 23:10:04 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98F86106564A for ; Fri, 8 Oct 2010 23:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7618FC0C for ; Fri, 8 Oct 2010 23:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o98NA4fB065400 for ; Fri, 8 Oct 2010 23:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o98NA4OS065399; Fri, 8 Oct 2010 23:10:04 GMT (envelope-from gnats) Date: Fri, 8 Oct 2010 23:10:04 GMT Message-Id: <201010082310.o98NA4OS065399@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/149495: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 23:10:04 -0000 The following reply was made to PR kern/149495; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/149495: commit references a PR Date: Fri, 8 Oct 2010 23:01:43 +0000 (UTC) Author: mm Date: Fri Oct 8 23:01:38 2010 New Revision: 213634 URL: http://svn.freebsd.org/changeset/base/213634 Log: Change FAPPEND to IO_APPEND as this is a ioflag and not a fflag. This corrects writing to append-only files on ZFS. PR: kern/149495 [1], kern/151082 [2] Submitted by: Daniel Zhelev [1], Michael Naef [2] Approved by: delphij (mentor) MFC after: 1 week Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Fri Oct 8 21:54:33 2010 (r213633) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Fri Oct 8 23:01:38 2010 (r213634) @@ -755,7 +755,7 @@ zfs_write(vnode_t *vp, uio_t *uio, int i */ pflags = zp->z_phys->zp_flags; if ((pflags & (ZFS_IMMUTABLE | ZFS_READONLY)) || - ((pflags & ZFS_APPENDONLY) && !(ioflag & FAPPEND) && + ((pflags & ZFS_APPENDONLY) && !(ioflag & IO_APPEND) && (uio->uio_loffset < zp->z_phys->zp_size))) { ZFS_EXIT(zfsvfs); return (EPERM); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 23:10:06 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BC131065670 for ; Fri, 8 Oct 2010 23:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6250E8FC13 for ; Fri, 8 Oct 2010 23:10:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o98NA6Cs065434 for ; Fri, 8 Oct 2010 23:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o98NA65a065427; Fri, 8 Oct 2010 23:10:06 GMT (envelope-from gnats) Date: Fri, 8 Oct 2010 23:10:06 GMT Message-Id: <201010082310.o98NA65a065427@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/151082: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 23:10:06 -0000 The following reply was made to PR kern/151082; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/151082: commit references a PR Date: Fri, 8 Oct 2010 23:01:44 +0000 (UTC) Author: mm Date: Fri Oct 8 23:01:38 2010 New Revision: 213634 URL: http://svn.freebsd.org/changeset/base/213634 Log: Change FAPPEND to IO_APPEND as this is a ioflag and not a fflag. This corrects writing to append-only files on ZFS. PR: kern/149495 [1], kern/151082 [2] Submitted by: Daniel Zhelev [1], Michael Naef [2] Approved by: delphij (mentor) MFC after: 1 week Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Fri Oct 8 21:54:33 2010 (r213633) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Fri Oct 8 23:01:38 2010 (r213634) @@ -755,7 +755,7 @@ zfs_write(vnode_t *vp, uio_t *uio, int i */ pflags = zp->z_phys->zp_flags; if ((pflags & (ZFS_IMMUTABLE | ZFS_READONLY)) || - ((pflags & ZFS_APPENDONLY) && !(ioflag & FAPPEND) && + ((pflags & ZFS_APPENDONLY) && !(ioflag & IO_APPEND) && (uio->uio_loffset < zp->z_phys->zp_size))) { ZFS_EXIT(zfsvfs); return (EPERM); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 23:40:05 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C2561065674 for ; Fri, 8 Oct 2010 23:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 327D68FC13 for ; Fri, 8 Oct 2010 23:40:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o98Ne4ti096132 for ; Fri, 8 Oct 2010 23:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o98Ne4fJ096131; Fri, 8 Oct 2010 23:40:04 GMT (envelope-from gnats) Date: Fri, 8 Oct 2010 23:40:04 GMT Message-Id: <201010082340.o98Ne4fJ096131@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Marcin Gryszkalis Cc: Subject: Re: kern/114676: [ufs] snapshot creation panics: snapacct_ufs2: bad block X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcin Gryszkalis List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 23:40:05 -0000 The following reply was made to PR kern/114676; it has been noted by GNATS. From: Marcin Gryszkalis To: freebsd-gnats-submit@freebsd.org, gael.roualland@dial.oleane.com Cc: Subject: Re: kern/114676: [ufs] snapshot creation panics: snapacct_ufs2: bad block Date: Sat, 9 Oct 2010 01:21:12 +0200 I have this panic after crash caused by failed UPS. The system is 8.0-RELEASE-pX. The worse thing is that it caused endless loop of reboots (crash caused background fsck+snapshot which caused panic which caused reboot+fsck etc.) UFS is placed over gmirror-ed disks (additionally checked with smartctl) so I guess low level disk failure is not the cause. I have few dumps available. *blkp is BLK_SNAP *ibp is $5 = {b_bufobj = 0xc585ea14, b_bcount = 16384, b_caller1 = 0x0, b_data = 0xdd1f3000 "\001", b_error = 0, b_iocmd = 2 '\002', b_ioflags = 2 '\002', b_iooffset = 19662389248, b_resid = 0, b_iodone = 0, b_blkno = 38403104, b_offset = -140257722368, b_bobufs = {tqe_next = 0xd9226e90, tqe_prev = 0xd90e9a08}, b_left = 0xd92c08e0, b_right = 0xd9281790, b_vflags = 0, b_freelist = {tqe_next = 0xd90e99d0, tqe_prev = 0xd9226edc}, b_qindex = 2, b_flags = 2147483808, b_xflags = 1 '\001', b_lock = { lock_object = {lo_name = 0xc0a74500 "bufwait", lo_flags = 91422720, lo_data = 0, lo_witness = 0x0}, lk_lock = 3311290624, lk_timo = 0, lk_pri = 80}, b_bufsize = 16384, b_runningbufspace = 0, b_kvabase = 0xdd1f3000 "\001", b_kvasize = 16384, b_lblkno = -8560652, b_vp = 0xc585e96c, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xdd1f3000, b_pager = {pg_reqpage = 0}, b_cluster = {cluster_head = {tqh_first = 0x0, tqh_last = 0x0}, cluster_entry = {tqe_next = 0x0, tqe_prev = 0x0}}, b_pages = {0xc1a7e050, 0xc1a0a568, 0xc1a16ec8, 0xc16fdfe0, 0x0 }, b_npages = 4, b_dep = {lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0} -- Marcin Gryszkalis, PGP 0x9F183FA3 jabber jid:mg@fork.pl, gg:2532994 http://the.fork.pl From owner-freebsd-fs@FreeBSD.ORG Sat Oct 9 11:12:44 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2C871065672 for ; Sat, 9 Oct 2010 11:12:44 +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 A83B18FC18 for ; Sat, 9 Oct 2010 11:12:43 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta06.emeryville.ca.mail.comcast.net with comcast id GbCe1f0070QkzPwA6bCjiZ; Sat, 09 Oct 2010 11:12:43 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta02.emeryville.ca.mail.comcast.net with comcast id GbCi1f0013LrwQ28NbCi51; Sat, 09 Oct 2010 11:12:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 083C99B418; Sat, 9 Oct 2010 04:12:42 -0700 (PDT) Date: Sat, 9 Oct 2010 04:12:42 -0700 From: Jeremy Chadwick To: Kai Gallasch Message-ID: <20101009111241.GA58948@icarus.home.lan> References: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Locked up processes after upgrade to ZFS v15 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 11:12:44 -0000 On Wed, Oct 06, 2010 at 02:28:31PM +0200, Kai Gallasch wrote: > Two days ago I upgraded my server to 8.1-STABLE (amd64) and upgraded ZFS from v14 to v15. > After zpool & zfs upgrade the server was running stable for about half a day, but then apache processes running inside jails would lock up and could not be terminated any more. > > In the end apache (both worker and prefork) itself locked up, because it lost control of its child processes. > > - only webserver jails with a prefork or worker apache do lock up > - non-apache processes in other jails do not show this problem > - locked httpd processes will not terminate when rebooting. > > in 'top' the stuck processes show up with state zfs or zfsmrb: > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 2341 root 1 44 0 112M 12760K select 3 0:04 0.00% httpd > 2365 root 1 44 0 12056K 4312K select 0 0:00 0.00% sendmail > 2376 root 1 48 0 7972K 1628K nanslp 4 0:00 0.00% cron > 2214 root 1 44 0 6916K 1440K select 0 0:00 0.00% syslogd > 24731 www 1 44 0 114M 13464K zfsmrb 6 0:00 0.00% httpd > 12111 www 1 44 0 114M 13520K zfs 5 0:00 0.00% httpd > 24729 www 1 44 0 114M 13408K zfsmrb 4 0:00 0.00% httpd > 24728 www 1 47 0 114M 13404K zfsmrb 5 0:00 0.00% httpd > 11051 www 1 44 0 114M 13456K zfs 1 0:00 0.00% httpd > 26368 www 1 44 0 114M 13460K zfsmrb 6 0:00 0.00% httpd > 24730 www 1 44 0 114M 13444K zfsmrb 5 0:00 0.00% httpd > 88803 www 1 44 0 114M 13388K zfs 1 0:00 0.00% httpd > 10887 www 1 44 0 114M 13436K zfs 6 0:00 0.00% httpd > 16493 www 1 44 0 114M 13528K zfs 5 0:00 0.00% httpd > 12461 www 1 44 0 114M 13340K zfs 1 0:00 0.00% httpd > 89018 www 1 51 0 114M 13260K zfs 1 0:00 0.00% httpd > 48699 www 1 52 0 114M 13308K zfs 3 0:00 0.00% httpd > 31090 www 1 44 0 114M 13404K zfs 3 0:00 0.00% httpd > 18094 www 1 44 0 114M 13312K zfs 2 0:00 0.00% httpd > 69479 www 1 46 0 114M 13424K zfs 4 0:00 0.00% httpd > 12890 www 1 44 0 114M 13336K zfs 5 0:00 0.00% httpd > 67204 www 1 44 0 114M 13328K zfs 5 0:00 0.00% httpd > 69402 www 1 60 0 114M 13432K zfs 4 0:00 0.00% httpd > 91162 www 1 56 0 114M 13408K zfs 0 0:00 0.00% httpd > 89781 www 1 45 0 114M 13428K zfs 4 0:00 0.00% httpd > 48663 www 1 45 0 114M 13388K zfs 4 0:00 0.00% httpd > 12112 www 1 44 0 114M 13340K zfs 6 0:00 0.00% httpd > 91161 www 1 54 0 114M 13280K zfs 5 0:00 0.00% httpd > 88839 www 1 44 0 114M 13592K zfsmrb 5 0:00 0.00% httpd > 89144 www 1 58 0 114M 13304K zfs 0 0:00 0.00% httpd > 78946 www 1 45 0 114M 13420K zfs 0 0:00 0.00% httpd > 81984 www 1 44 0 114M 13396K zfs 5 0:00 0.00% httpd > 93431 www 1 61 0 114M 13340K zfs 5 0:00 0.00% httpd > 91179 www 1 76 0 114M 13360K zfs 4 0:00 0.00% httpd > 69400 www 1 53 0 114M 13324K zfs 0 0:00 0.00% httpd > 54211 www 1 45 0 114M 13404K zfs 6 0:00 0.00% httpd > 36335 www 1 45 0 114M 13400K zfs 4 0:00 0.00% httpd > 31093 www 1 44 0 114M 13348K zfs 2 0:00 0.00% httpd > > I compiled a debug kernel with following options: > > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > options GDB # Support remote GDB. > options INVARIANTS # Enable calls of extra sanity checking > options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks and cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > # > options SW_WATCHDOG > options DEBUG_LOCKS > options DEBUG_VFS_LOCKS > > After process lockups only output on console was: > witness_lock_list_get: witness exhausted > > I also moved the jails with the stuck httpd processes to another server (also 8.1-STABLE, ZFS v15) - but the lockup also ouccured there. > > How can I debug this and get further information? At the moment I am thinking about reverting from zfs to ufs - to save some nerves. Would be a big disappointment for me, after all the time and effort trying to use zfs in production. We're seeing (what we believe) to be this exact situation. We just migrated our main RELENG_7 system to RELENG_8 last night (full OS reinstall, kernel/world built from sources dated October 8 @ 01:30 PDT). The system is dedicated to httpd + postfix + named. We do not use jails. Memory/RAM is ECC, and the system does have serial console. SMP is in use (physical CPU is an Intel Core 2 Duo). ZFS is in use on this system (a very simple configuration). Filesystems which use ZFS are mapped to /home and /var/mail (thus heavily accessed given the hosts' role): pool: pool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 mirror ONLINE 0 0 0 ada0s1g ONLINE 0 0 0 ada1 ONLINE 0 0 0 errors: No known data errors httpd exclusively uses prefork and *was not* built with any threading support. On RELENG_7, the system used ZFS v14, had the same tunings, and had an uptime of 221 days w/out issue. With RELENG_8, the system lasted approximately 12 hours (about half a day) before getting into a state that looks almost identical to Kai's system: existing processes were stuck (unkillable, even with -9). New processes could be spawned (including ones which used the ZFS filesystems), and commands executed successfully. init complained about wedged processes when the system was rebooted: Oct 9 02:00:56 init: some processes would not die; ps axl advised No indication of any hardware issues on the console. The administrator who was handling the issue did not use "ps -l", "top", nor "procstat -k", so we don't have any indication of what the process state was in, nor what the kernel calling stack looked like that lead up to the wedging. All he stated was that the processes were in D/I states, which doesn't help since that's what they're in normally anyway. If I was around I would have forced DDB and done "call doadump" to investigate things post-mortem. Monitoring graphs of the system during this time don't indicate any signs of memory thrashing (though bsnmp-ucd doesn't provide as much granularity as top does); the system looks normal except for a slightly decreased load average (probably as a result of the deadlocked processes). /boot/loader.conf tunings on the system. Please note some of these may already be the defaults: kern.maxdsiz="1536M" kern.dfldsiz="1536M" kern.maxssiz="256M" vm.kmem_size="4096M" vfs.zfs.arc_max="3584M" vfs.zfs.prefetch_disable="1" vfs.zfs.zio.use_uma="0" vfs.zfs.txg.timeout="5" vfs.zfs.txg.write_limit_override="268435456" /etc/sysctl.conf tunings: kern.ipc.shm_use_phys=1 net.inet.icmp.icmplim=1500 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 vfs.ufs.dirhash_maxmem=16777216 kern.maxvnodes=200000 Aside from the top/procstat/kernel dump aspect, what other information would kernel folks be interested in? Is "call doadump" sufficient for post-mortem investigation? I need to know since if/when this happens again (likely), I want to get folks as much information as possible. Also, a question for Kai: what did you end up doing to resolve this problem? Did you roll back to an older FreeBSD, or...? -- | 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-fs@FreeBSD.ORG Sat Oct 9 12:35:30 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC7C8106566B for ; Sat, 9 Oct 2010 12:35:30 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id CC83C8FC08 for ; Sat, 9 Oct 2010 12:35:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by goat.gigo.com (Postfix) with ESMTP id 86E61114D9 for ; Sat, 9 Oct 2010 05:35:30 -0700 (PDT) Received: from goat.gigo.com ([127.0.0.1]) by localhost (vette.gigo.com [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id pO492gUIzc+S for ; Sat, 9 Oct 2010 05:35:30 -0700 (PDT) Received: from 189.72.242.161 (unknown [189.72.242.161]) by goat.gigo.com (Postfix) with ESMTPSA id 23466114D6 for ; Sat, 9 Oct 2010 05:35:29 -0700 (PDT) Received: (qmail 68946 invoked from network); 9 Oct 2010 09:34:34 -0300 Received: from unknown (HELO exxodus.fedaykin.here) (127.0.0.1) by exxodus.fedaykin.here with SMTP; 9 Oct 2010 09:34:34 -0300 Message-ID: <4CB06171.9000007@uol.com.br> Date: Sat, 09 Oct 2010 09:34:33 -0300 From: Mario Sergio Fujikawa Ferreira User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; pt-BR; rv:1.9.1.12) Gecko/20101005 Thunderbird/3.0.8 MIME-Version: 1.0 To: Paul B Mahol References: <20101006005350.62837.qmail@exxodus.fedaykin.here> <4CAC5067.3090106@uol.com.br> (sfid-20101006_12270_04810444) In-Reply-To: (sfid-20101006_12270_04810444) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Panic with msdosfs vs 1.3TB FAT32 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 12:35:31 -0000 On 06/10/2010 12:01, Paul B Mahol wrote: > On 10/6/10, Mario Sergio Fujikawa Ferreira wrote: >> On 06/10/2010 00:36, Paul B Mahol wrote: >>> On 10/6/10, Mario Sergio Fujikawa Ferreira wrote: >>>> Hi, >>>> >>>> I mounted a 1.3TB FAT32 (32k cluster) filesystem on esata >>>> /dev/ada4s1 under /media/esata/ with the '-l' (large option). > What FreeBSD version is this and how many files that fs have? csup, make world 8-STABLE on 07 October, 2010. $ uname -a FreeBSD exxodus.fedaykin.here 8.1-STABLE FreeBSD 8.1-STABLE #1: Thu Oct 7 22:45:57 BRT 2010 lioux@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ada4s1 1464778560 1189423520 275355040 81% /media/esata Number of files 4595 File size average in bytes 517580,14 File size standard deviation in bytes 745362,08 File size variance in bytes 555564632228,95 Smaller file size in bytes 23 Largest file size in bytes 3681407635 Smaller inode number 11446148 Largest inode number 4026536433 A complete textdump is available at http://people.freebsd.org/~lioux/panic/2010100500/textdump.tar.2 Let me know if you need further information. >>>> I tried to create a directory and files but got errors: > > If you mount it read only, can you read all files? I can read files (tried md5 checksum on 20 files) whether I mount it read only or not. I have the md5 checksum of those files saved elsewhere for comparison purposes. The problem only arise when I try to do a write operation. > This could eat all memory if there are many small files.... > But it can be useful to know if you can read files with different > inodes (or whatever FAT calls it) I tried reading several files of 4Gb size each. No problem. >>>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >>>> >>>> ------ >>>> >>>> Then, I tried unmounting the filesystem which resulted on >>>> >>>> ------ >>>> >>>> fsync: giving up on dirty >>>> 0xffffff01bad6e1d8: tag devfs, type VCHR >>>> usecount 1, writecount 0, refcount 38253 mountedhere >>>> 0xffffff00ac899600 >>>> flags () >>>> v_object 0xffffff008b839ca8 ref 0 pages 44786 >>>> lock type devfs: EXCL by thread 0xffffff016506cba0 (pid 76462) >>>> dev ada4s1 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247646208, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247613440, length=32768)]error = 5 >>>> g_vfs_done():ada4s1[WRITE(offset=-980247580672, length=32768)]error = 5 >>>> fsync: giving up on dirty >>>> 0xffffff01bad6e1d8: tag devfs, type VCHR >>>> usecount 1, writecount 0, refcount 38253 mountedhere >>>> 0xffffff00ac899600 >>>> flags () >>>> v_object 0xffffff008b839ca8 ref 0 pages 44786 >>>> lock type devfs: UNLOCKED >>>> dev ada4s1 >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 1; apic id = 01 >>>> fault virtual address = 0x4 >>>> fault code = supervisor read data, page not present >>>> instruction pointer = 0x20:0xffffffff803e60e4 >>>> stack pointer = 0x28:0xffffff80e79ba860 >>>> frame pointer = 0x28:0xffffff80e79ba8a0 >>>> 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 = 25 (syncer) >>>> >>>> ------ >>>> >>>> The filesystem is clean since I find no errors under Windows >>>> ('chkdsk /f'). >>>> >>>> I can otherwise mount, read and write on smaller FAT32 >>>> filesystems. I think there might be a problem with the handling >>>> of such a big FAT32 filesystem. >>>> >>>> A complete textdump is available at >>>> >>>> http://people.freebsd.org/~lioux/panic/2010100500/textdump.tar.2 >>>> >>>> Is this kind of error expected? Is there anything I can do >>>> to help? >>>> >>>> I can reproduce this error with the 1.3TB fs easily. >>> >>> Comment in source claims that support for large fs are experimental >>> and safe only in read only mode. >>> >>> Looking at your output it is obvious that offset should not be negative... >> >> Now that you mention it... :) >> >> I guess I might have overflown some internal variable, possibly a 32 >> bit integer. >> >> I checked >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/msdosfs/msdosfs_vfsops.c?rev=1.199 >> >> but it did not make much sense to me. :( >> >> Any ideas where I might look or for a patch? Unfortunately, I am not >> kernel knowledgeable but I'll help however I can. > > Something is very buggy with msdosfs and vfs. > > kern/93634 is clear example. I can reproduce it on i386. > > Note that I'm freebsd vfs/vm noob. So do not expect anything from me. -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature From owner-freebsd-fs@FreeBSD.ORG Sat Oct 9 13:07:59 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B4D8106564A for ; Sat, 9 Oct 2010 13:07:59 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 211488FC1C for ; Sat, 9 Oct 2010 13:07:58 +0000 (UTC) Received: by vws1 with SMTP id 1so443679vws.13 for ; Sat, 09 Oct 2010 06:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4d26AJFRWK1PBNWQ2wdBmze64T2KwHoYHsNNk81iSrI=; b=W7wLryLslIPvHXxFqvr5GauFxM3pi0vGEXvzKGy9JYyFiFJ3IFI7o/DadQ3asZ/j3t c2uCVvci3jq4VoeUrulZ4y5lQ9OPxJqtX8Hn09jALuzKTZliISfjOsVvkYwu9j+bBzET YGnmArcMtnWWn6AgXs6VxnrRSUnXNnnT627uE= 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=GgAkGvYeNLURZIYTHcTBU65ndOmURtzjkOOohXFLAaiq5Ffv91jfsi+2qFzS8y76Hq cpQ3ISfpW8mTWI8wAzyenE5t02iYV7uqJVrCIXN5SgHSvKWT0MWme/Vq/Xe/xZdVfKJN fvd5p29ST4/WAckWXydXXAN13sbH1LTAQU3gM= MIME-Version: 1.0 Received: by 10.220.97.18 with SMTP id j18mr1135859vcn.11.1286629677425; Sat, 09 Oct 2010 06:07:57 -0700 (PDT) Received: by 10.220.180.135 with HTTP; Sat, 9 Oct 2010 06:07:57 -0700 (PDT) In-Reply-To: <4CB06171.9000007@uol.com.br> References: <20101006005350.62837.qmail@exxodus.fedaykin.here> <4CAC5067.3090106@uol.com.br> <4CB06171.9000007@uol.com.br> Date: Sat, 9 Oct 2010 13:07:57 +0000 Message-ID: From: Paul B Mahol To: Mario Sergio Fujikawa Ferreira Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Panic with msdosfs vs 1.3TB FAT32 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 13:07:59 -0000 On 10/9/10, Mario Sergio Fujikawa Ferreira wrote: > On 06/10/2010 12:01, Paul B Mahol wrote: > > On 10/6/10, Mario Sergio Fujikawa Ferreira wrote: > >> On 06/10/2010 00:36, Paul B Mahol wrote: > >>> On 10/6/10, Mario Sergio Fujikawa Ferreira > wrote: > >>>> Hi, > >>>> > >>>> I mounted a 1.3TB FAT32 (32k cluster) filesystem on esata > >>>> /dev/ada4s1 under /media/esata/ with the '-l' (large option). > > What FreeBSD version is this and how many files that fs have? > > csup, make world 8-STABLE on 07 October, 2010. > > $ uname -a > FreeBSD exxodus.fedaykin.here 8.1-STABLE FreeBSD 8.1-STABLE #1: Thu Oct > 7 22:45:57 BRT 2010 lioux@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ada4s1 1464778560 1189423520 275355040 81% /media/esata > > Number of files 4595 > File size average in bytes 517580,14 > File size standard deviation in bytes 745362,08 > File size variance in bytes 555564632228,95 > Smaller file size in bytes 23 > Largest file size in bytes 3681407635 > > Smaller inode number 11446148 > Largest inode number 4026536433 > > A complete textdump is available at > > http://people.freebsd.org/~lioux/panic/2010100500/textdump.tar.2 Show bawrite(), from bt, exact position (line number in your source code) and other variables inspecting stack. Optionally build msdosfs with MSDOSFS_DEBUG. From owner-freebsd-fs@FreeBSD.ORG Sat Oct 9 13:37:08 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79D641065672 for ; Sat, 9 Oct 2010 13:37:08 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id BC66F8FC16 for ; Sat, 9 Oct 2010 13:37:07 +0000 (UTC) Received: (qmail 90429 invoked from network); 9 Oct 2010 15:37:05 +0200 Received: from smtp.free.de (HELO orwell.free.de) ([91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 9 Oct 2010 15:37:05 +0200 References: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> <20101009111241.GA58948@icarus.home.lan> In-Reply-To: <20101009111241.GA58948@icarus.home.lan> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Kai Gallasch Date: Sat, 9 Oct 2010 15:37:04 +0200 To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.1081) Cc: Subject: Re: Locked up processes after upgrade to ZFS v15 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 13:37:08 -0000 Am 09.10.2010 um 13:12 schrieb Jeremy Chadwick: > On Wed, Oct 06, 2010 at 02:28:31PM +0200, Kai Gallasch wrote: >> Two days ago I upgraded my server to 8.1-STABLE (amd64) and upgraded = ZFS from v14 to v15. >> After zpool & zfs upgrade the server was running stable for about = half a day, but then apache processes running inside jails would lock up = and could not be terminated any more. > On RELENG_7, the system used ZFS v14, had the same tunings, and had an > uptime of 221 days w/out issue. 8.0 and 8.1-STABLE + ZFS v14 also ran very solid on my servers - dang! > With RELENG_8, the system lasted approximately 12 hours (about half a > day) before getting into a state that looks almost identical to Kai's > system: existing processes were stuck (unkillable, even with -9). New > processes could be spawned (including ones which used the ZFS > filesystems), and commands executed successfully. same here. I can provoke this locked process problem by starting one of my webserver jails. The first httpd process will lock up after = max. 30 minutes. Problem is, that after lot httpd forks, apache can not fork any more = child processes and the stuck (not killable) httpd processes all have a = socket open, with the IP address of the webserver. So a restart of = apache is not possible, because $IP:80 is already occupied. The jail also cannot be stopped/started in this state.. Only choice = there is: Restart the whole jail-host server (some processes would not = die - ps -axl advised + unclean umounts of ufs partitions) or delete the = IP-Adresse from the network interface and migrate the jail to another = server (zfs send/receive).. no fun at all. BTW: zfs destroy also does = not work here. > init complained about wedged processes when the system was rebooted: I use 'procstat -k -k -a | grep faul' to look for this condition.. This will find all processes in the table that contain 'trap_pfault' > Oct 9 02:00:56 init: some processes would not die; ps axl advised >=20 > No indication of any hardware issues on the console. here too. > The administrator who was handling the issue did not use "ps -l", = "top", > nor "procstat -k", so we don't have any indication of what the process > state was in, nor what the kernel calling stack looked like that lead = up > to the wedging. All he stated was that the processes were in D/I > states, which doesn't help since that's what they're in normally = anyway. > If I was around I would have forced DDB and done "call doadump" to > investigate things post-mortem. Another sign is an increased count of processes in 'top'.=20 > Monitoring graphs of the system during this time don't indicate any > signs of memory thrashing (though bsnmp-ucd doesn't provide as much > granularity as top does); the system looks normal except for a = slightly > decreased load average (probably as a result of the deadlocked > processes). My server currently has 28 GB RAM, with < 60% usage and no special zfs = tuning in loader.conf - although I tried to set = vm.pmap.pg_ps_enabled=3D"0" to find out if the locked processes had = anything to do with it. But setting it, did not prevent the problem from reoccurring. > Aside from the top/procstat/kernel dump aspect, what other information > would kernel folks be interested in? Is "call doadump" sufficient for > post-mortem investigation? I need to know since if/when this happens > again (likely), I want to get folks as much information as possible. I'm also willing to help, but need explicit instructions. I could = provoke such a lockup on one of my servers, but don't have that much = time to leave the server in this state.. So only a small time frame to = collect wanted debug data. > Also, a question for Kai: what did you end up doing to resolve this > problem? Did you roll back to an older FreeBSD, or...? This bug struck me really hard, because the affected server is not part = of a cluster and hosts about 50 jails (mail, web, databases). Problem is: Sockets held open by locked processes cannot be closed.. So = a restart of a jammed service is not possible. Theoretically I had the option to boot into the old world/kernel, but = I'm sure with the old zfs.ko a zfs mount of ZFS v15 wouldn't be = possible. AFAIK there is no zfs downgrade command or utility.. Of course a bare metal recovery of the whole server from tape was also a = last option. But really?? my 'solution': - move the most instable jails to other servers and restore them to UFS = partitions. - move everything else in the zpool temporarily to other servers running = zfs (zfs send/recieve) - zfs destroy -r - zpool delete - gpart create -t freebsd-ufs - gpart add ... - restore all jails from zfs to ufs So the server was now reverted to ufs - just for the piece of (my) mind, = although I waste around 50% of the raid capacity for reserved FS = allocation and all the other disadvantages compared to a volume manager. = I will still use zfs on several machines, but for some time not for = critical data. ZFS is a nifty thing, but I really depend on a stable FS. = (Of course for other people zfs v15 may be running smoothly) I must repeat. I offer my help if someone wants to dig into the locking = problem. =20 Regards, Kai. From owner-freebsd-fs@FreeBSD.ORG Sat Oct 9 13:55:58 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E946D106566B for ; Sat, 9 Oct 2010 13:55:58 +0000 (UTC) (envelope-from hywel@hmallett.co.uk) Received: from lisbon.directrouter.com (lisbon.directrouter.com [72.249.30.130]) by mx1.freebsd.org (Postfix) with ESMTP id C70288FC25 for ; Sat, 9 Oct 2010 13:55:58 +0000 (UTC) Received: from [83.60.14.249] (helo=[192.168.1.36]) by lisbon.directrouter.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P4Ztz-0002Wg-9I; Sat, 09 Oct 2010 08:55:55 -0500 References: <4CAD6A44.8010707@telus.net> <4813F683-1FF0-4DC4-9BC0-A512258C81CA@hmallett.co.uk> <4CAE8E67.3080201@telus.net> In-Reply-To: <4CAE8E67.3080201@telus.net> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: Hywel Mallett Date: Sat, 9 Oct 2010 15:52:41 +0200 To: Carl X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - lisbon.directrouter.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hmallett.co.uk X-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-fs@freebsd.org" Subject: Re: Should gmirrored gjournal provider have auto-synchronization? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 13:55:59 -0000 On 8 Oct 2010, at 05:22, Carl wrote: > On 2010-10-07 3:21 PM, Hywel Mallett wrote: >> gmirror guarantees that a collection of >> writes either happens in it's entirety, or not at all. >=20 > My admittedly limited understanding of gmirror is that it makes no such gu= arantee. I think it is gjournal that guarantees the consistency of the file s= ystem that sits on top of it, not gmirror, and this would be true even if th= ere were no gmirror below it.=20 You are correct. I wrote gmirror in that sentence, but I meant gjournal.=20= From owner-freebsd-fs@FreeBSD.ORG Sat Oct 9 14:34:42 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86AED1065675 for ; Sat, 9 Oct 2010 14:34:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 340148FC1D for ; Sat, 9 Oct 2010 14:34:41 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id GdLe1f0040EZKEL59eaiqW; Sat, 09 Oct 2010 14:34:42 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta01.westchester.pa.mail.comcast.net with comcast id Geah1f0043LrwQ23MeahPC; Sat, 09 Oct 2010 14:34:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D52B69B418; Sat, 9 Oct 2010 07:34:39 -0700 (PDT) Date: Sat, 9 Oct 2010 07:34:39 -0700 From: Jeremy Chadwick To: Kai Gallasch Message-ID: <20101009143439.GA63604@icarus.home.lan> References: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> <20101009111241.GA58948@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101009111241.GA58948@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Locked up processes after upgrade to ZFS v15 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 14:34:42 -0000 On Sat, Oct 09, 2010 at 04:12:42AM -0700, Jeremy Chadwick wrote: > [...snipping for brevity...] > > We're seeing (what we believe) to be this exact situation. Because of Kai's follow-up, I've decided to move our RELENG_8 system to using gmirror(8) instead of ZFS. The system has only been up for 4.5 hours. Upon shutting down httpd, I checked ps/top to see what things looked like. There are tons of httpd processes (now with ppid of init, indicating they're to be reaped but can't be) in "zfs" and "zfsmrb" states, and these processes are hung/stuck. So yes, the behaviour I'm seeing is identical to Kai's, and the problem is easily reproducible. I have much less RAM than he does (8GB) as well, so it isn't a RAM thing. Below is some simple debugging information for whoever wants to take this on. If someone wants to figure this out, I'll need time to build a test/debug system that mimics our production system. The UIDs differ (80, 1014, 1004, etc.) because of the Apache ITK MPM that we use. I doubt that has anything to do with the problem. horus# /usr/local/etc/rc.d/apache22 stop Stopping apache22. Waiting for PIDS: 1192. horus# ps -auxw | grep 1192 | grep -v grep horus# ps -axlH | grep httpd 1014 1243 1 0 44 0 97944 15068 zfs D ?? 0:00.00 /usr/local/sbin/httpd 1014 1462 1 0 44 0 98008 15280 zfsmrb DL ?? 0:00.00 /usr/local/sbin/httpd 1014 1585 1 0 44 0 97944 15068 zfs D ?? 0:00.00 /usr/local/sbin/httpd 1014 1633 1 0 44 0 97944 15068 zfs D ?? 0:00.00 /usr/local/sbin/httpd 1004 1805 1 0 44 0 97948 15236 zfsmrb DL ?? 0:00.00 /usr/local/sbin/httpd 1014 1998 1 0 44 0 97944 15068 zfs D ?? 0:00.00 /usr/local/sbin/httpd 1014 2038 1 0 44 0 97944 15064 zfs D ?? 0:00.00 /usr/local/sbin/httpd 1014 2077 1 0 44 0 97944 15068 zfs D ?? 0:00.00 /usr/local/sbin/httpd 80 3186 1 0 45 0 97984 15432 zfsmrb DL ?? 0:00.01 /usr/local/sbin/httpd 80 4806 1 0 44 0 97944 15128 zfs D ?? 0:00.00 /usr/local/sbin/httpd ... horus# procstat -k -k 3186 PID TID COMM TDNAME KSTACK 3186 100443 httpd - mi_switch+0x176 sleepq_wait+0x3b _sleep+0x322 zfs_freebsd_read+0x26c vnode_pager_generic_getpages+0x454 vnode_pager_getpages+0x8e vm_fault+0xbd1 trap_pfault+0x111 trap+0x479 calltrap+0x8 horus# procstat -k -k 4806 PID TID COMM TDNAME KSTACK 4806 100475 httpd - mi_switch+0x176 sleepq_wait+0x3b __lockmgr_args+0x642 vop_stdlock+0x39 VOP_LOCK1_APV+0x46 _vn_lock+0x44 vget+0x67 cache_lookup+0x4fd vfs_cache_lookup+0xad VOP_LOOKUP_APV+0x40 lookup+0x48a namei+0x518 vn_open_cred+0x390 kern_openat+0x165 syscall+0x1cd Xfast_syscall+0xe2 horus# procstat -k -k 2077 PID TID COMM TDNAME KSTACK 2077 100339 httpd - mi_switch+0x176 sleepq_wait+0x3b __lockmgr_args+0x642 vop_stdlock+0x39 VOP_LOCK1_APV+0x46 _vn_lock+0x44 vget+0x67 cache_lookup+0x4fd vfs_cache_lookup+0xad VOP_LOOKUP_APV+0x40 lookup+0x48a namei+0x518 vn_open_cred+0x390 kern_openat+0x165 syscall+0x1cd Xfast_syscall+0xe2 horus# procstat -k -k 1462 PID TID COMM TDNAME KSTACK 1462 100157 httpd - mi_switch+0x176 sleepq_wait+0x3b _sleep+0x322 zfs_freebsd_read+0x26c vnode_pager_generic_getpages+0x454 vnode_pager_getpages+0x8e vm_fault+0xbd1 trap_pfault+0x111 trap+0x479 calltrap+0x8 -- | 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-fs@FreeBSD.ORG Sat Oct 9 14:55:08 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74DBB106564A for ; Sat, 9 Oct 2010 14:55:08 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.freebsd.org (Postfix) with SMTP id 097F38FC0C for ; Sat, 9 Oct 2010 14:55:07 +0000 (UTC) Received: (qmail 21100 invoked from network); 9 Oct 2010 14:55:07 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 09 Oct 2010 07:55:06 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: lxj2XXEVM1mL.tU9HRkmISBAe5HCbOolKKWxWDeiIgwsHyO dYq5oGv4TAM4eRu1FRTBfh9.jjkx0He72cZs4fJLkncnb0RpDET4V.4eXR8U jIx6Yc4CPdWV9xitHAmasi8lOjWjAwNW4LDLboR4WXD4UD3hSO0tDue15mdF x60pKStio95VvvQwYVsj2jTPze6EGsnybLUjZO6mxR5cQE1sHAikGFiXm9uG XxP_Ntr1yud1MpM8n5sIKPjZngy1asOGgMX0REyqlf6ojJo2aSAPSgB..uTC lznkTcdKTp.S1kjHvFbJp7VgTPB83RW5Mxl30cGpyaBSk8IpMav88HT3.CYA GjKvTU0GqHCLfWwvRN74NkX1A2n_t38mVdbshEbYNfqJ2aSrPPpH17VzD8tM 4VZlUwXEZTRDqTPS3MPR3bZl4Wd3gLQimVWuHj98DRlaFQA-- X-Yahoo-Newman-Property: ymail-3 Received: from [10.123.50.70] (unknown [74.198.12.74]) by smtp.irbisnet.com (Postfix) with ESMTPSA id 262CFA4F6; Sat, 9 Oct 2010 10:55:06 -0400 (EDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <169A4F62-0509-4AE9-A4A5-F9CADD08140D@irbisnet.com> X-Mailer: iPhone Mail (8B117) From: Andriy Bakay Date: Sat, 9 Oct 2010 10:55:35 -0400 To: Pete French , Andriy Gapon Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 14:55:08 -0000 Do you know any more convenient way (except make buildword, etc.) to upgrade= /update several boxes to STABLE on regular basis? Something like freebsd-upd= ate or maybe some process, tips, tricks, etc? Thanks. On 2010-10-08, at 6:11, Pete French wrote: >> Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is yo= ur opinion? >=20 > I am running 8-STABLE from 27th September on all our ptoduction > machines (from webservers to database servers to the company mail > server) and it is fine. I am going to update again over the next > few days, as there are some ZFS fixes in which I want - and which > may benifit you too - so I will be able to report back next > week as to how a more recent version behaves. >=20 > In general though, I have never had problems running STABLE on > prodyction systems over the years. Of course what I do is to test it > on a singlre machine before rolling it out (a leaf in a webfarm > so if it goes down it wont affect the business) but it is usually > fine. keep an eye on -STABLE mailing list though, as that is where > problems arise. I watch that, and also the dailing commits, either here >=20 > http://www.freshbsd.org/?branch=3DRELENG_8&project=3Dfreebsd&committer=3D&= module=3D&q=3D >=20 > or here >=20 > http://www.secnetix.de/olli/FreeBSD/svnews/?p=3Dstable/8 >=20 > Just to see whats going into the tree relative to whats being discussed. > It only takes a few minutes a dat to monitor the mailin lists and the > commits, and the result is that we've been running STABLE for a very > long time (close to a decade I suspect) with great success. >=20 > -pete. From owner-freebsd-fs@FreeBSD.ORG Sat Oct 9 19:52:13 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52F1B106564A for ; Sat, 9 Oct 2010 19:52:13 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF528FC13 for ; Sat, 9 Oct 2010 19:52:12 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P4fSi-0001ZB-6T for freebsd-fs@freebsd.org; Sat, 09 Oct 2010 21:52:08 +0200 Received: from 93-138-93-169.adsl.net.t-com.hr ([93.138.93.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Oct 2010 21:52:08 +0200 Received: from ivoras by 93-138-93-169.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Oct 2010 21:52:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Sat, 09 Oct 2010 21:51:47 +0200 Lines: 22 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-93-169.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20101008 Thunderbird/3.1.4 Subject: Increasing ufs.dirhash_maxmem by default X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 19:52:13 -0000 hi, Several people have worked on dirhash in the past so I'm posting here instead of individually pinging them. The default dirhash_maxmem is currently set as 2 MB, which while may be sufficient some time ago it certainly isn't now. I've had to increase it on practically all non-trivial servers and even high-end desktops, and there are occasional reports on the lists that suggest it's a fairly common thing. What I'd like to do is either: 1) Simply increase the default to e.g. 32 MB (trivial change) or 2) Make it a function of hibufspace (e.g. 1/32th of it, capped at 64 MB) which is itself autotuned. This would happen in ufsdirhash_init(). The current incarnation of dirhash has a vm_lowmem handler so it doesn't look like it could starve a system if overtuned. Ideas? Objections? From owner-freebsd-fs@FreeBSD.ORG Sat Oct 9 21:31:31 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEAE1106564A for ; Sat, 9 Oct 2010 21:31:31 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD098FC0A for ; Sat, 9 Oct 2010 21:31:31 +0000 (UTC) X-AuditID: 1209190f-b7c1dae000000a2b-9e-4cb0dbb051fe Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id F2.2C.02603.0BBD0BC4; Sat, 9 Oct 2010 17:16:32 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id o99LGSCL018079; Sat, 9 Oct 2010 17:16:29 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o99LGQjn001255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 9 Oct 2010 17:16:27 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o99LGPRn016770; Sat, 9 Oct 2010 17:16:25 -0400 (EDT) Date: Sat, 9 Oct 2010 17:16:25 -0400 (EDT) From: Benjamin Kaduk To: gil@vidals.net In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: AAAAAA== Cc: freebsd-fs@freebsd.org Subject: Re: moving away from freebsd and zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 21:31:31 -0000 On Fri, 8 Oct 2010, Gil Vidals wrote: > The solution described here, > http://forums.freebsd.org/showthread.php?t=11873 points to compiling a > kernel with these options: > > options NFSD > options DEVICE_POLLING > options HZ=1000 > > The NFSD seems to be what solved the problem for the forum poster, but NFSD > option means that NFSv4 (experimental) is what is running and that isn't > supported by the VMware NFS client, so I can't use it. I don't know what to > do and I would be grateful for any suggestions. I thought that the experimental server can speak both NFSv4 and NFSv3 -- have you actually tried using it and had the VMware client fail to talk to it? It seems that one can specify the -e argument to nfsd and skip the kernel rebuild, if I am reading the man page correctly ... -Ben Kaduk From owner-freebsd-fs@FreeBSD.ORG Sat Oct 9 21:34:40 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 685F2106564A for ; Sat, 9 Oct 2010 21:34:40 +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 23D928FC08 for ; Sat, 9 Oct 2010 21:34:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAKd8sEyDaFvO/2dsb2JhbACDH6AViBmiGJFxgSKDMXQEikA X-IronPort-AV: E=Sophos;i="4.57,309,1283745600"; d="scan'208";a="96731072" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 09 Oct 2010 17:34:39 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 39B60B3F59; Sat, 9 Oct 2010 17:34:39 -0400 (EDT) Date: Sat, 9 Oct 2010 17:34:39 -0400 (EDT) From: Rick Macklem To: Marco van Tol Message-ID: <2095120971.471944.1286660079166.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101008110030.GD94234@tolstoy.tols.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [174.114.48.168] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-fs@freebsd.org, gil@vidals.net Subject: Re: moving away from freebsd and zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 21:34:40 -0000 > On Fri, Oct 08, 2010 at 03:00:28AM -0700, Gil Vidals wrote: > > The solution described here, > > http://forums.freebsd.org/showthread.php?t=11873 points to compiling > > a > > kernel with these options: > > > > options NFSD > > options DEVICE_POLLING > > options HZ=1000 > > > > The NFSD seems to be what solved the problem for the forum poster, > > but NFSD > > option means that NFSv4 (experimental) is what is running and that > > isn't > > supported by the VMware NFS client, so I can't use it. I don't know > > what to > > do and I would be grateful for any suggestions. > > I haven't got much experience with nfs4, sorry. :) > > Marco > The experimental NFS server (NFSD) handles NFSv2 and NFSv3 as well as NFSv4, so it should be usable for this. I've also pointed Gil to the patch at: http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch which I believe might fix his problem w.r.t. the regular server. (pjd@ has a nicer one, but they both fix the same problem) rick From owner-freebsd-fs@FreeBSD.ORG Sat Oct 9 21:40:37 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F31A8106566B for ; Sat, 9 Oct 2010 21:40:37 +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 AE9F08FC08 for ; Sat, 9 Oct 2010 21:40:37 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAIZ+sEyDaFvO/2dsb2JhbACDH6AVqkKRaoEigzF0BIpAiyI X-IronPort-AV: E=Sophos;i="4.57,309,1283745600"; d="scan'208";a="94811227" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 09 Oct 2010 17:40:35 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BC7C2B3F61; Sat, 9 Oct 2010 17:40:35 -0400 (EDT) Date: Sat, 9 Oct 2010 17:40:35 -0400 (EDT) From: Rick Macklem To: Benjamin Kaduk Message-ID: <627785309.472007.1286660435759.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [174.114.48.168] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-fs@freebsd.org, gil@vidals.net Subject: Re: moving away from freebsd and zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 21:40:38 -0000 > On Fri, 8 Oct 2010, Gil Vidals wrote: > > I thought that the experimental server can speak both NFSv4 and NFSv3 > -- > have you actually tried using it and had the VMware client fail to > talk to > it? It seems that one can specify the -e argument to nfsd and skip the > kernel rebuild, if I am reading the man page correctly ... > > -Ben Kaduk > Yes, it should do NFSv3 and run when "-e" is specified for both nfsd and mountd (or set nfsv4_server_enable="YES" in /etc/rc.conf, which sets the "-e" flag for both). You will need to create the empty file called /var/db/nfs_stablerestart using something like install -o root -g wheel -m 600 /dev/null /var/db/nfs-stablerestart before it will start up the first time. Good luck with it, rick