From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 05:33:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C943106566B for ; Sun, 17 Jan 2010 05:33:57 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 2227A8FC08 for ; Sun, 17 Jan 2010 05:33:56 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id o0H5M302002157 for ; Sun, 17 Jan 2010 14:22:03 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id o0H5M3124516 for ; Sun, 17 Jan 2010 14:22:03 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla2) id o0H5M3KI000757 for freebsd-current@freebsd.org; Sun, 17 Jan 2010 14:22:03 +0900 (JST) Received: from localhost by somla2.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0H5M0v0000701; Sun, 17 Jan 2010 14:22:00 +0900 (JST) Date: Sun, 17 Jan 2010 14:22:00 +0900 (JST) Message-Id: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> To: freebsd-current@freebsd.org From: Kohji Okuno Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: okuno.kohji@jp.panasonic.com Subject: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 05:33:57 -0000 Hello, I think that sched_4bsd.c:sched_switch() has a problem. I encounterd the problem that a process could not exit. That process has multi threads and p_flag was as below. p_flag : (P_INMEM|P_STOPPED_SINGLE|P_EXEC|P_SINGLE_EXIT|P_PPWAIT|P_CONTROLT) One thread (THREAD A) was suspended as below. sched_switch() mi_switch() thread_suspend_switch() thread_single() exit1() sys_exit() td_flags : TDF_NEEDSIGCHK|TDF_ASTPENDING|TDF_CANSWAP|TDF_INMEM Another thread (THREAD B) was sleeping as below. sched_switch() mi_switch() sleepq_switch() sleepq_catch_signals() sleepq_wait_sig() _cv_wait_sig() seltdwait() kern_select() select() td_flags : TDF_CANSWAP|TDF_SINTR|TDF_INMEM That process could not exit, because THREAD B did not execute "thread_suspend_check()" and THREAD A had been suspended. I think that the race condition had occurred about td_flags as below. In sched_switch(), when td->td_lock is not &sched_lock, td->td_lock will be unlocked as shown below. And then, td->td_flags will change without td->td_lock. <> kern_thread.c: int thread_single(int mode) { ... thread_lock(td2); td2->td_flags |= TDF_ASTPENDING | TDF_NEEDSUSPCHK; *** I think that td2 specified THREAD B in this time. <> sched_4bsd.c: void sched_switch(struct thread *td, struct thread *newtd, int flags) { ... /* * Switch to the sched lock to fix things up and pick * a new thread. */ if (td->td_lock != &sched_lock) { mtx_lock_spin(&sched_lock); thread_unlock(td); } *** I think that td_lock was sleepqueue_chagin->sc_lock. ... td->td_lastcpu = td->td_oncpu; td->td_flags &= ~TDF_NEEDRESCHED; td->td_owepreempt = 0; td->td_oncpu = NOCPU; -- Thanks, Kohji Okuno. From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 06:28:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30161065692 for ; Sun, 17 Jan 2010 06:28:52 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3A68FC22 for ; Sun, 17 Jan 2010 06:28:52 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id o0H6Sowd009399 for ; Sun, 17 Jan 2010 15:28:50 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id o0H6So405832 for ; Sun, 17 Jan 2010 15:28:50 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla8) id o0H6So4h005075 for freebsd-current@freebsd.org; Sun, 17 Jan 2010 15:28:50 +0900 (JST) Received: from localhost by somla8.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0H6ShFx005038; Sun, 17 Jan 2010 15:28:43 +0900 (JST) Date: Sun, 17 Jan 2010 15:28:35 +0900 (JST) Message-Id: <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> To: freebsd-current@freebsd.org From: Kohji Okuno In-Reply-To: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Jan_17_15_28_35_2010_654)--" Content-Transfer-Encoding: 7bit Cc: okuno.kohji@jp.panasonic.com Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 06:28:52 -0000 ----Next_Part(Sun_Jan_17_15_28_35_2010_654)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Could you check sched_4bsd.patch, please? -- Best regards, Kohji Okuno. > Hello, > > I think that sched_4bsd.c:sched_switch() has a problem. > > > I encounterd the problem that a process could not exit. > That process has multi threads and p_flag was as below. > > p_flag : (P_INMEM|P_STOPPED_SINGLE|P_EXEC|P_SINGLE_EXIT|P_PPWAIT|P_CONTROLT) > > > One thread (THREAD A) was suspended as below. > sched_switch() > mi_switch() > thread_suspend_switch() > thread_single() > exit1() > sys_exit() > > td_flags : TDF_NEEDSIGCHK|TDF_ASTPENDING|TDF_CANSWAP|TDF_INMEM > > > Another thread (THREAD B) was sleeping as below. > sched_switch() > mi_switch() > sleepq_switch() > sleepq_catch_signals() > sleepq_wait_sig() > _cv_wait_sig() > seltdwait() > kern_select() > select() > > td_flags : TDF_CANSWAP|TDF_SINTR|TDF_INMEM > > > That process could not exit, because THREAD B did not execute > "thread_suspend_check()" and THREAD A had been suspended. > > > I think that the race condition had occurred about td_flags as below. > > In sched_switch(), when td->td_lock is not &sched_lock, td->td_lock > will be unlocked as shown below. And then, td->td_flags will change > without td->td_lock. > > > <> > kern_thread.c: > int > thread_single(int mode) > { > ... > > thread_lock(td2); > td2->td_flags |= TDF_ASTPENDING | TDF_NEEDSUSPCHK; > > *** I think that td2 specified THREAD B in this time. > > <> > sched_4bsd.c: > void > sched_switch(struct thread *td, struct thread *newtd, int flags) > { > ... > > /* > * Switch to the sched lock to fix things up and pick > * a new thread. > */ > if (td->td_lock != &sched_lock) { > mtx_lock_spin(&sched_lock); > thread_unlock(td); > } > > *** I think that td_lock was sleepqueue_chagin->sc_lock. > ... > > td->td_lastcpu = td->td_oncpu; > td->td_flags &= ~TDF_NEEDRESCHED; > td->td_owepreempt = 0; > td->td_oncpu = NOCPU; > > -- > Thanks, > Kohji Okuno. > > _______________________________________________ > 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" ----Next_Part(Sun_Jan_17_15_28_35_2010_654)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sched_4bsd.patch" diff --git a/kern/sched_4bsd.c b/kern/sched_4bsd.c index 2a8c442..5602493 100644 --- a/kern/sched_4bsd.c +++ b/kern/sched_4bsd.c @@ -269,8 +269,18 @@ maybe_resched(struct thread *td) { THREAD_LOCK_ASSERT(td, MA_OWNED); +#if 1 /* Added */ + if (td->td_lock != &sched_lock) { + mtx_lock_spin(&sched_lock); + } +#endif if (td->td_priority < curthread->td_priority) curthread->td_flags |= TDF_NEEDRESCHED; +#if 1 /* Added */ + if (td->td_lock != &sched_lock) { + mtx_unlock_spin(&sched_lock); + } +#endif } /* @@ -928,6 +938,12 @@ sched_switch(struct thread *td, struct thread *newtd, int flags) THREAD_LOCK_ASSERT(td, MA_OWNED); +#if 1 /* Moved */ + td->td_lastcpu = td->td_oncpu; + td->td_flags &= ~TDF_NEEDRESCHED; + td->td_owepreempt = 0; + td->td_oncpu = NOCPU; +#endif /* * Switch to the sched lock to fix things up and pick * a new thread. @@ -943,10 +959,12 @@ sched_switch(struct thread *td, struct thread *newtd, int flags) if (newtd) newtd->td_flags |= (td->td_flags & TDF_NEEDRESCHED); +#if 0 /* Original */ td->td_lastcpu = td->td_oncpu; td->td_flags &= ~TDF_NEEDRESCHED; td->td_owepreempt = 0; td->td_oncpu = NOCPU; +#endif /* * At the last moment, if this thread is still marked RUNNING, ----Next_Part(Sun_Jan_17_15_28_35_2010_654)---- From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 08:43:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B6031065670; Sun, 17 Jan 2010 08:43:11 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id DFEA08FC0A; Sun, 17 Jan 2010 08:43:10 +0000 (UTC) Received: from ameno.mahoroba.org (IDENT:FtH3TfvlSs8sXnP80Tu14nV2B5V1nscVZlycY21hbP2FvblZEVx/XX+84VORYyCK@ameno.mahoroba.org [IPv6:2001:2f0:104:8010:20a:79ff:fe69:ee6b]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id o0H8gweH013376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jan 2010 17:43:01 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 17 Jan 2010 17:42:58 +0900 Message-ID: From: Hajimu UMEMOTO To: Luigi Rizzo In-Reply-To: <20100110185232.GA27907@onelab2.iet.unipi.it> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> <20100110185232.GA27907@onelab2.iet.unipi.it> User-Agent: xcite1.58> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-RELEASE-p2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 17 Jan 2010 17:43:01 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, David Horn , freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 08:43:11 -0000 Hi, >>>>> On Sun, 10 Jan 2010 19:52:32 +0100 >>>>> Luigi Rizzo said: rizzo> We only need one 'me' option that matches v4 and v6, because the rizzo> other two can be implemented as 'ip4 me' and 'ip6 me' at no extra rizzo> cost (the code for 'me' only scans the list corresponding to the rizzo> actual address family of the packet). I would actually vote for rizzo> removing the 'me6' microinstruction from the kernel, and implement rizzo> it in /sbin/ipfw by generating 'ip6 me'. rizzo> Feel free to commit the change yourself. Thank you. I've committed 1st patch and 3rd patch. I think it is better removing the 'me6' microinstruction from the kernel, and implement it in /sbin/ipfw by generating 'ip6 me'. However, it seems to me that /sbin/ipfw is not designed to generate two microinstructions (ip6 me) per one 'me6' easily. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 09:17:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F5CC106566B; Sun, 17 Jan 2010 09:17:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 24D448FC14; Sun, 17 Jan 2010 09:17:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0H9HlJb024891; Sun, 17 Jan 2010 04:17:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0H9Hl4L024869; Sun, 17 Jan 2010 09:17:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 17 Jan 2010 09:17:47 GMT Message-Id: <201001170917.o0H9Hl4L024869@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 09:17:48 -0000 TB --- 2010-01-17 07:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-17 07:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-01-17 07:50:00 - cleaning the object tree TB --- 2010-01-17 07:50:21 - cvsupping the source tree TB --- 2010-01-17 07:50:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-01-17 07:50:59 - building world TB --- 2010-01-17 07:50:59 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-17 07:50:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-17 07:50:59 - TARGET=pc98 TB --- 2010-01-17 07:50:59 - TARGET_ARCH=i386 TB --- 2010-01-17 07:50:59 - TZ=UTC TB --- 2010-01-17 07:50:59 - __MAKE_CONF=/dev/null TB --- 2010-01-17 07:50:59 - cd /src TB --- 2010-01-17 07:50:59 - /usr/bin/make -B buildworld >>> World build started on Sun Jan 17 07:50:59 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jan 17 08:50:49 UTC 2010 TB --- 2010-01-17 08:50:49 - generating LINT kernel config TB --- 2010-01-17 08:50:49 - cd /src/sys/pc98/conf TB --- 2010-01-17 08:50:49 - /usr/bin/make -B LINT TB --- 2010-01-17 08:50:49 - building LINT kernel TB --- 2010-01-17 08:50:49 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-17 08:50:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-17 08:50:49 - TARGET=pc98 TB --- 2010-01-17 08:50:49 - TARGET_ARCH=i386 TB --- 2010-01-17 08:50:49 - TZ=UTC TB --- 2010-01-17 08:50:49 - __MAKE_CONF=/dev/null TB --- 2010-01-17 08:50:49 - cd /src TB --- 2010-01-17 08:50:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 17 08:50:49 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Jan 17 09:12:13 UTC 2010 TB --- 2010-01-17 09:12:13 - building GENERIC kernel TB --- 2010-01-17 09:12:13 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-17 09:12:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-17 09:12:13 - TARGET=pc98 TB --- 2010-01-17 09:12:13 - TARGET_ARCH=i386 TB --- 2010-01-17 09:12:13 - TZ=UTC TB --- 2010-01-17 09:12:13 - __MAKE_CONF=/dev/null TB --- 2010-01-17 09:12:13 - cd /src TB --- 2010-01-17 09:12:13 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jan 17 09:12:13 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/qdivrem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/pc98/cbus/cbus_dma.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/pc98/cbus/clock.c /src/sys/pc98/cbus/clock.c:104: error: variable 'using_lapic_timer' has initializer but incomplete type /src/sys/pc98/cbus/clock.c:104: error: 'LAPIC_CLOCK_NONE' undeclared here (not in a function) *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-17 09:17:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-17 09:17:47 - ERROR: failed to build GENERIC kernel TB --- 2010-01-17 09:17:47 - 3911.79 user 858.51 system 5266.39 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 10:56:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53F01106566C; Sun, 17 Jan 2010 10:56:31 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1458FC0C; Sun, 17 Jan 2010 10:56:30 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B503F730A1; Sun, 17 Jan 2010 12:04:43 +0100 (CET) Date: Sun, 17 Jan 2010 12:04:43 +0100 From: Luigi Rizzo To: Hajimu UMEMOTO Message-ID: <20100117110443.GA58434@onelab2.iet.unipi.it> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> <20100110185232.GA27907@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, David Horn , freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 10:56:32 -0000 On Sun, Jan 17, 2010 at 05:42:58PM +0900, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Sun, 10 Jan 2010 19:52:32 +0100 > >>>>> Luigi Rizzo said: > > rizzo> We only need one 'me' option that matches v4 and v6, because the > rizzo> other two can be implemented as 'ip4 me' and 'ip6 me' at no extra > rizzo> cost (the code for 'me' only scans the list corresponding to the > rizzo> actual address family of the packet). I would actually vote for > rizzo> removing the 'me6' microinstruction from the kernel, and implement > rizzo> it in /sbin/ipfw by generating 'ip6 me'. > > rizzo> Feel free to commit the change yourself. > > Thank you. I've committed 1st patch and 3rd patch. > I think it is better removing the 'me6' microinstruction from the > kernel, and implement it in /sbin/ipfw by generating 'ip6 me'. > However, it seems to me that /sbin/ipfw is not designed to generate > two microinstructions (ip6 me) per one 'me6' easily. Indeed, it might be useful to insert, at the beginning of function ipfw_add, a small preprocessing step that translates all instances of 'me6' into 'ip6 me' and then proceed with the current parsing. While doing that, one could even NULL-terminate the array av[] so we don't need to carry both ac and av throught the code. Something like new_av = safe_calloc(ac*2 + 1, sizeof(char *); for (src = dst = 0; src < ac; src++) { if (!strcmp(av[src], "me6")) { new_av[dst++] = "ip6"; new_av[dst++] = "me"; } else { new_av[dst++] = av[src]; } } new_av[dst++] = NULL; av = new_av; ac = dst; should do the job. Replacing the tests for 'ac > 0' and ac>1 is straightforward though it touches a large number of lines (most of the usage is in the 'NEED1' macro. cheers luigi > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 11:47:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47BCB106566B for ; Sun, 17 Jan 2010 11:47:32 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 0A33B8FC12 for ; Sun, 17 Jan 2010 11:47:31 +0000 (UTC) Received: from [85.175.178.193] (helo=izar) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1NWTbO-0008gM-6w for freebsd-current@freebsd.org; Sun, 17 Jan 2010 14:47:30 +0300 From: Boris Samorodov To: freebsd-current@freebsd.org Date: Sun, 17 Jan 2010 14:47:28 +0300 Message-ID: <89252191@ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: ROOT MOUNT ERROR: booting from a built-in flash reader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 11:47:32 -0000 Hi! I've got a EEEPC-1000 and boot FreeBSD 9.0-CURRENT i386 r202342 from a SDHC card inserted into the built-in flash reader. The OS stops while mounting a root filesystem and prompts for a manual root filesystem specification. The da0 disk appears at the system console just after the "mountroot>" propmt. If I type ufs:/dev/da0s1a the boot proceeds. Are there any patches for testing? ;-) Thanks! -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 15:00:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F22FE106566C for ; Sun, 17 Jan 2010 15:00:49 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 7EEA78FC0C for ; Sun, 17 Jan 2010 15:00:49 +0000 (UTC) Received: by fxm10 with SMTP id 10so1453990fxm.14 for ; Sun, 17 Jan 2010 07:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=y2eYyhQYQ4TWrSVVLmXfGpaDezbGI3nEU2EtZh1TuSo=; b=kaj7GnjN9dM/SAeclBspYxU5OueTy9wgtJ/3QMYHSiVMkk5BfkCnepAcmYuGokQKcx 9BKNrnzSvphVEoyvEjIhrq0CH26WpYE6euVzn0scKEtKCL1r0y1RTmtgj5qePZpnyWtI qvSyScdHSGWXxLlVVFZEgoxEYTz1qZv9dlEPk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=uZio0oEr9kd77huZ2axOdOGDacE6WXgZkD/9uc3+7swj094Fur08RDbIQOsQxenxR/ s9swknRVIT3u6VmV+ChIXx1jIioU7xMysSgVwwqkw2zfAgQ6zW0nkLkPH/idK0BJTKWg MnKLyADLA8plfC9QOs2rbrVqzZk92x/dTSBro= Received: by 10.223.5.14 with SMTP id 14mr64369fat.83.1263740448191; Sun, 17 Jan 2010 07:00:48 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm1231137fxm.4.2010.01.17.07.00.47 (version=SSLv3 cipher=RC4-MD5); Sun, 17 Jan 2010 07:00:47 -0800 (PST) Sender: Alexander Motin Message-ID: <4B53261E.3020102@FreeBSD.org> Date: Sun, 17 Jan 2010 17:00:46 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Boris Samorodov , FreeBSD-Current References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: ROOT MOUNT ERROR: booting from a built-in flash reader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 15:00:50 -0000 Boris Samorodov wrote: > I've got a EEEPC-1000 and boot FreeBSD 9.0-CURRENT i386 r202342 > from a SDHC card inserted into the built-in flash reader. The OS > stops while mounting a root filesystem and prompts for a manual > root filesystem specification. > > The da0 disk appears at the system console just after the > "mountroot>" propmt. If I type ufs:/dev/da0s1a the boot proceeds. > > Are there any patches for testing? ;-) Now I am working on a new scan routine for CAM. I'll probably publish patches in a few days. If your card reader (AFAIK there are USB-based one) will be able to register it's SCSI bus to CAM before the rest of CAM-supported controllers (for example, ata(4) with ATA_CAM) finish their scan, new routine will manage system waiting for it also. It not - it will be a another question. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 17:42:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA6E31065693; Sun, 17 Jan 2010 17:42:11 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8598FC08; Sun, 17 Jan 2010 17:42:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0HHgBYB008072; Sun, 17 Jan 2010 17:42:11 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0HHgBf1008071; Sun, 17 Jan 2010 17:42:11 GMT (envelope-from danger) Date: Sun, 17 Jan 2010 17:42:11 +0000 From: Daniel Gerzo To: hackers@freebsd.org Message-ID: <20100117174211.GA99840@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: FreeBSD Quarterly Status Report for October - December 2009 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 17:42:11 -0000 Introduction This report covers FreeBSD related projects between October and December 2009. This is the last of the four reports covering 2009, which has shown to be a very important year for the FreeBSD Project. Besides other notable things, a new major version of FreeBSD, 8.0-RELEASE, has been released, while the release process for 7.3-RELEASE is soon to begin. Thanks to all the reporters for the excellent work! We hope you enjoy reading. Let us also take this opportunity to wish you all a happy and successful new year for 2010. Please note that the deadline for submissions covering the period between January and March 2010 is April 15th, 2010. __________________________________________________________________ Google Summer of Code * BSD-licensed iconv Projects * 3G USB support * Clang replacing GCC in the base system * FreeBSD TDM Framework * HAST -- Highly Available Storage * Intel XScale hwpmc(9) support * POSIX utmpx for FreeBSD * SUJ -- Journaled SoftUpdates * The webcamd deamon FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Release Engineering * The FreeBSD Foundation Status Report Network Infrastructure * bwn(4) -- Broadcom Wireless driver * IP Payload Compression Protocol support * Ralink wireless RT2700U/2800U/3000U run(4) USB driver * Syncing pf(4) with OpenBSD 4.5 * Wireless mesh networking Kernel * CAM-based ATA implementation * Group Limit Increase * NFSv4 ACL support * V4L support in Linux emulator Documentation * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project Architectures * Flattened Device Tree for embedded FreeBSD * FreeBSD/ia64 * FreeBSD/mips * FreeBSD/sparc64 Ports * Chromium web browser * Ports Collection * VirtualBox on FreeBSD Vendor / 3rd Party Software * DAHDI (Zaptel) support for FreeBSD * NVIDIA amd64 driver Miscellaneous * AsiaBSDCon 2010 -- The BSD Conference * BSDCan 2010 -- The BSD Conference * meetBSD 2010 -- The BSD Conference * The FreeBSD Forums Userland utilities * BSD-licensed text processing tools __________________________________________________________________ 3G USB support Contact: Andrew Thompson Recently, a bunch of new device IDs have been added for the u3g(4) cellular wireless driver; the list should be comparable now with other operating systems around. A lot of these devices have a feature where the unit first attaches as a disk or CD-ROM that contains the Win/Mac drivers. This state should be detected by the u3g driver and the usb device is sent a command to switch to modem mode. This has been working for quite some time but as it is implemented differently for each vendor I am looking for feedback on any units where the auto switchover is not working (or the init is not recognized at all). Please ensure you are running an up to date kernel, like r201681 or later from 9.0-CURRENT, or 8-STABLE after the future merge of this revision. __________________________________________________________________ AsiaBSDCon 2010 -- The BSD Conference URL: http://2010.AsiaBSDCon.org/ Contact: AsiaBSDCon Information AsiaBSDCon is a conference for users and developers on BSD based systems. AsiaBSDCon is a technical conference and aims to collect the best technical papers and presentations available to ensure that the latest developments in our open source community are shared with the widest possible audience. The conference is for anyone developing, deploying and using systems based on FreeBSD, NetBSD, OpenBSD, DragonFlyBSD, Darwin and MacOS X. The next conference will be held at the Tokyo University of Science, Tokyo, Japan, on 11th to 14th March, 2010. For more detailed information, please check the conference web site. __________________________________________________________________ BSD-licensed iconv URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 009/gabor_iconv Contact: Gábor Kövesdán Good compatibility has been ensured and there are only few pending items that have to be reviewed/enhanced. Recently, an enhancement has been completed, which makes it possible to accomplish better transliteration, just like in the GNU version. An initial testing patch is expected at the beginning of February. Open tasks: 1. Enhance conversion tables to make use of enhanced transliteration. 2. A performance optimization might be done later. __________________________________________________________________ BSD-licensed text processing tools URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 008/gabor_textproc Contact: Gábor Kövesdán As 8.0-RELEASE is out, BSD bc/dc can be now committed to 9.0-CURRENT. We are only waiting for an experimental package building to make sure there are no regressions after this change. BSD grep is complete but it cannot be integrated yet because of some regex library issues. We need first a fast and modern regex library so that we can change to BSD grep. BSD sort has few incomplete features and needs some performance review. Open tasks: 1. Commit BSD bc/dc. 2. Implement remaining features for sort and optimize performance. __________________________________________________________________ BSDCan 2010 -- The BSD Conference URL: http://www.BSDCan.org/2010/ Contact: BSDCan Information BSDCan, a BSD conference held in Ottawa, Canada, has quickly established itself as the technical conference for people working on and with 4.4BSD based operating systems and related projects. The organizers have found a fantastic formula that appeals to a wide range of people from extreme novices to advanced developers. BSDCan 2010 will be held on 13-14 May 2010 at the University of Ottawa, and will be preceded by two days of Tutorials on 11-12 May 2010. There will be related events (of a social nature, for the most part) on the day before and after the conference. Please check the conference web site for more information. __________________________________________________________________ bwn(4) -- Broadcom Wireless driver URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/weongyo/ wireless/src/sys/dev/bwn&HIDEDEL=NO Contact: Weongyo Jeong bwn(4) is replacing bwi(4) driver for to the following reasons: * Uses latest v4 firmware image instead of using the much older v3 firmware. In this way, we have some great benefits, such as support for N-PHYs and the fixes of various earlier firmware bugs. * Supports PIO mode. This is important because -- as you might know -- the Broadcom Wireless Driver is created by reverse-engineering so some pieces of hardware might not work with DMA operations. * Supports 64 bit DMA operations. * Separates bwi(4) driver into two parts; siba(4) driver and bwn(4) driver. Many Broadcom wireless and NIC devices are based on Silicon Sonics Backplane, such as bwi(4), which implemented the SIBA operations internally. This resulted in code duplication as other drivers had to implement their own routines to deal with SIBA. In the case of bwn(4), these two parts have been separated and implemented in their own kernel modules to avoid this problem and help further development by providing a standalone siba(4) driver. Currently, it is tested on big/little endian machines and 32/64-bit DMA operation with STA mode. A major patch for siba(4) is being reviewed before committing into 9.0-CURRENT. Open tasks: 1. MESH/IBSS/HOSTAP mode is not supported. 2. LP/N PHYs are not supported. __________________________________________________________________ CAM-based ATA implementation Contact: Alexander Motin Contact: Scott Long Existing ata(4) infrastructure, which has been around many years, has various problems and limitations when compared to modern controllers/device support. Although the CAM subsystem (used for SCSI) is almost as old as ata(4), it is more eligible to solve the current problems. To reduce code duplication and better support border cases such as ATAPI and SAS, we have started to develop a new CAM based ATA implementation. As such, CAM infrastructure has been extended to support different transports. New transport has been implemented to support PATA/SATA buses. To support ATA disks, a new CAM driver (ada) has been written. ATAPI devices are supported by existing SCSI drivers cd, da, sa, etc. To support SATA port-multipliers another new CAM driver (pmp) has been written. To support most featured and widespread SATA controllers, new drivers ahci(4) and siis(4) have been developed. To support legacy ATA controllers, a kernel option ATA_CAM has been added. When used, it makes all ata(4) controllers directly available to CAM, deprecating ata(4) peripheral drivers and external APIs. To make this possible, ata(4) code has been heavily refactored, making controller driver API stricter. Command queuing support gives new ATA implementation up to double performance benefit on some workloads, with 20-30% improvement quite usual. SATA Port Multiplier support makes it easy to build fast and cheap storage with huge capacities, by using dozens of SATA drives in one system or external enclosures, Some of that code has been presented in the recently released FreeBSD 8.0-RELEASE but 8-STABLE now includes a much improved version. Open tasks: 1. Improve timeout and transport error recovery. 2. Improve hot-plug support. 3. Find and fix any show stoppers for legacy ata(4) deprecation. 4. Write a new, more featured driver for Marvell SATA controllers (specifications desired). 5. Write SAS-specific transport and drivers for SAS HBAs (specifications desired). SAS controllers can support SATA devices and multipliers, so it should fit nicely into the new infrastructure. __________________________________________________________________ Chromium web browser URL: http://chromium.jaggeri.com URL: http://www.links.org/?p=724 Contact: Ben Laurie Chromium is a Webkit-based web browser that is largely BSD licensed. It has been ported from Linux to FreeBSD in October and we have been posting patches and test builds periodically since then. Chromium works well on FreeBSD -- it is very fast and stable but there are a handful of rough edges that need to be polished up. Two remaining bugs should probably be fixed before releasing a chromium-devel port. We are looking for volunteers to test and maintain this port to make this BSD browser a viable option on FreeBSD desktop systems. Open tasks: 1. Fix sporadic rendering freezes. 2. Fix JavaScript interpreter, v8, on i386 architecture. __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach We are again able to build bootable i386/amd64 kernel. Nathan Whitehorn committed a fix to FreeBSD, which enabled LLVM/clang to work mostly fine on PowerPC. There is some preliminary testing of LLVM/clang on ARM and MIPS being done. We have some ideas about sparc64 support which are currently being investigated. You are welcome to contact us if you want to help. Since the last report, a lot has happened mostly in the area of C++; clang is currently able to build working groff, gperf and devd, i.e. all of the C++ apps we have in base. Unfortunately, it still cannot build any of the C++ libraries -- two of them are missing builtins and libstdc++ is broken for other reasons. Not much happened in the clangbsd branch as we cannot upgrade the clang/llvm there because we are blocked by a bug that requires using newer assembler than we can ship. This might be solved by either fixing this (short term) or using llvm-mc instead of GNU as for assembling (longer term). Open tasks: 1. Help with ARM/MIPS/sparc64. 2. More testing of clang on 3rd party apps (ports). 3. Discussion on integrating LLVM/clang into FreeBSD. __________________________________________________________________ DAHDI (Zaptel) support for FreeBSD URL: http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg39598.html URL: http://svn.digium.com/svn/dahdi/freebsd/trunk/ Contact: Max Khon A DAHDI support module for FreeBSD has been created in the official Asterisk SVN repository. The following drivers are currently ported: * main DAHDI driver * all software echo cancellation drivers * dahdi_dynamic * dahdi_dynamic_loc The following HW drivers are currently ported and tested: * wct4xxp, including HW echo cancellation support (Octasic) + Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port T1/E1/J1 + Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port T1/E1/J1 + Digium TE220: PCI-Express dual-port T1/E1/J1 + Digium TE420: PCI-Express quad-port T1/E1/J1 * wcb4xxp + Digium B410: PCI quad-port BRI + Junghanns.NET HFC-2S/4S/8S duo/quad/octoBRI + OpenVox B200P/B400P/B800P + BeroNet BN2S0/BN4S0/BN8S0 Open tasks: 1. The port for dahdi_dynamic_eth and dahdi_dynamic_ethmf is underway. 2. More HW drivers need to be ported. 3. Please let me know if you can provide remote access with serial console to any box with ISDN/T1/E1 HW not currently supported by DAHDI for FreeBSD but supported by DAHDI for Linux. I am also interested in porting drivers for FXO/FXS cards. Please let me know if you can provide a remote access or donate a card. __________________________________________________________________ Flattened Device Tree for embedded FreeBSD URL: http://wiki.FreeBSD.org/FlattenedDeviceTree URL: http://p4db.FreeBSD.org/changeList.cgi?FSPC=//depot/projects/fdt/... Contact: Rafal Jaworowski The purpose of this project is to provide FreeBSD with support for the Flattened Device Tree (FDT) technology, the mechanism for describing computer hardware resources, which cannot be probed or self enumerated, in a uniform and portable way. The primary consumers of this technology are embedded FreeBSD platforms (ARM, AVR32, MIPS, PowerPC), where a lot of designs are based on similar chips but have different assignment of pins, memory layout, addresses bindings, interrupts routing and other resources. Current state highlights: * Environment, supported tools + Integrated device tree compiler (dtc) and libfdt into FreeBSD userspace, kernel and loader build * loader(8) + Full support for device tree blob handling + Load, traverse, modify (including add/remove) device tree nodes and properties + Pass the device tree blob to the kernel + Both ARM and PowerPC loader(8) supported * Kernel side FDT support (common) + Developed OF interface for FDT-backed platforms + ofw_bus I/F (and /dev/openfirm) available with FDT + Integrated FDT resources representation with newbus (fdtbus and simplebus drivers) * PowerPC kernel (Freescale MPC85XX SOC) + MPC8555CDS and MPC8572DS successfully converted to FDT conventions * ARM kernel (Marvell Orion, Kirkwood and Discovery SOC) + Work in progress on integrating FDT infrastructure with ARM platform code Work on this project has been sponsored by the FreeBSD Foundation. Open tasks: 1. Complete missing pieces for PowerPC (PCI bridge driver conversion to FDT). 2. Complete ARM support. 3. Merge to SVN. __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html URL: http://people.FreeBSD.org/~linimon/recommended_subscribers.txt Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth Bugmeister Gavin Atkinson has now been granted a src commit bit, and is now starting to work through some of our backlog. The list of PRs recommended for committer evaluation by the Bugbusting Team continues to receive new additions; however, it has not yet achieved high visibility. (This list contains PRs, mostly with patches, that the Bugbusting Team consider potentially ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem.) One of the suggestions at the Cambridge devsummit was to create a way for people to be emailed the weekly summary that is posted to freebsd-bugs@, and this has now been implemented. Please email linimon@FreeBSD.org to ask to be added to the recommended_subscribers.txt file (see above). We continue to classify PRs as they arrive, adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage. At this point most of the PRs that refer to supported versions of FreeBSD have been converted, and we are keeping up as new ones come in. We hope that this is making it easier to browse the PR database. The overall PR count jumped to over 6,200 during the 8.0-RELEASE release cycle but seems to have stabilized at around 6,100. As in the past, we have a fairly good clearance rate for ports PRs but much less so for other PRs. (Partly this is due to the concept of individual ports having 'maintainers'.) Open tasks: 1. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Release Engineering URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team announced FreeBSD 8.0-RELEASE on November 26th, 2009. With 8.0-RELEASE completed planning has begun for 7.3-RELEASE. The schedule has been set with the release date planned for early March 2010. The Release Engineering Team would like to thank George Neville-Neil (gnn@) for his service on the team. George continues to work with the FreeBSD Project but has stepped down from the Release Engineering Team to focus on other activities. __________________________________________________________________ FreeBSD TDM Framework Contact: Rafal Czubak Contact: Michal Hajduk Important changes regarding FreeBSD TDM Framework since the last status report: * Fully functional TDM controller driver for Marvell Kirkwood and Discovery SoCs. * Working voiceband channel character device driver. * Working Si3215, Si3050 codec drivers on corresponding FXS, FXO ports. * Demo application, which is capable of manipulating voiceband channel and codec state, starting/stopping channel transfers and echoing on single channel. * Preliminary version of driver bridging the voiceband infrastructure with Zaptel/DAHDI. Open tasks: 1. Improve various issues regarding working drivers and demo application. 2. Test Si3050 codec driver operation with PSTN. 3. Fully integrate voiceband infrastructure with Zaptel/DAHDI telephony hardware drivers. __________________________________________________________________ FreeBSD/ia64 Contact: Marcel Moolenaar Work continues on our ia64 port. Many recent commits to help improve stability have been made to 9.0-CURRENT and MFCed to 8-STABLE. Due to interest from a very motivated user, package builds have been restarted for ia64-8. This is primarily intended as a QA step to discover and fix bugs on ia64, rather than to create packages for upload. Based on the above, Mark Linimon documented how to add more architectures to the package cluster scheduler. (This work will also be of use in an upcoming effort to start powerpc package builds.) There are currently 3 ia64 machines online and building packages. The machines seem stable as long as multiple simultaneous package builds are not attempted, in which case they get machine checks. This is puzzling, since other heavy workloads seem stable on the same machines. Open tasks: 1. Continue to try to understand why multiple simultaneous package builds bring the machines down. 2. Upgrade the firmware on the two machines at Yahoo! to see if that helps the problem. 3. Configure a fourth machine that has been made available to us. 4. Figure out the problems with the latest GCC port on ia64. 5. We can use some help with reviewing the ia64 platform pages and bringing them up-to-date. __________________________________________________________________ FreeBSD/mips URL: http://www.FreeBSD.org/projects/mips/index.html URL: http://wiki.FreeBSD.org/FreeBSD/mips Contact: The FreeBSD/mips mailing list Contact: Warner Losh The base/projects/mips branch has been merged into 9.0-CURRENT. The merge is complete and the sanity tests have passed. The code has booted on both a Ubiquiti RouterStation (big endian) as well as in gxemul (little endian). The branch lived for one year, minus a day, and accumulated much work: * A new port to the Atheros AR71xx series of processors. This port supports the RouterStation and RouterStation PRO boards from Ubiquiti. Other boards should work with minimal tweaking. This port should be considered as nearing production quality, and has been used extensively by the developers. The primary author of this port is Oleksandr Tymoshenko (gonzo@FreeBSD.org). * A new port to the SiByte BCM1250 SoC on the BCM91250 evaluation board (aka SWARM). This port is reported to be stable, but this hardware is a little old and not widely available. The primary author of this port is Neel Natu (neel@FreeBSD.org). Only one core is presently supported. * A port, donated by Cavium, to their Octeon and Octeon plus series of SoC (CN3xxx and CN5xxx). This code is preliminary, supporting only a single core right now. It has been lightly tested on the CN3860 evaluation board only in 32-bit mode. Warner Losh (imp@FreeBSD.org) has been driving the efforts to get this code into the tree. * A port, donated by RMI, to their XLR series of SoCs. This port is single core only, as well. The code reaches multi-user but should be considered beta quality for the moment. Randal Stewart (rrs@FreeBSD.org) has been driving the efforts to integrate this into the tree. * Preliminary support for building a mips64 kernel from this source base. More work is needed here, but at least two kernels successfully build in 64-bit mode (OCTEON1 and MALTA64). * Very early support for N32 and N64 ABIs * Support for booting compressed kernels has been added (gonzo@). * Improved support for debugging * Improved busdma and bus_space support * Many bug fixes * More types of MIPS cores are recognized * Expanded cache handling for newer processors * Beginning of a port to the alchemy au1XXX cpus is present, but experimental. * Work on SMP is underway to support multicore processors like the SiByte, Octeon and XLR processors. The development branch had been updated incorrectly several times over the past year, and the damage was too much to repair. We have retired the branch and will do further mips development in 9.0-CURRENT for the time being. If you have a checked out tree, the suggested way to update the projects/mips tree you have is to do a "svn switch svn://svn.FreeBSD.org/base/head" in that tree. I would like to thank everybody that has contributed time, code or hardware to make FreeBSD/mips better. As development proceeds, I will keep posting updates. In addition, I hope to have some mini "how-to" wiki pages done for people that want to try it out. Open tasks: 1. We are still investigating how feasible merging all this work into 8-STABLE will be, as it represents a huge leap forward in code stability and quality. __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl The main thing that has taken place since the last Status Report is that I have gotten to the bottom of the remaining PCI problems with Sun Fire V215/V245 and support for these has been completed and since r202023 now is part of 9.0-CURRENT. With some luck it will also be part of the upcoming 7.3-RELEASE. Some other news: * Two bugs in the NFS server causing unaligned access and thus panics on sparc64 and all other architectures with strict alignment requirements (basically all Tier-2 ones) have been fixed. There likely will be a 8.0-RELEASE Erratum Notice released for these. * FreeBSD has been adopted to the changed firmware of newer Sun Fire V480 (those equipped with version 7 Schizo bridges) and has been reported to now run fine on these. The necessary change will be part of 7.3-RELEASE. Unfortunately, using the on-board NICs in older models of Sun Fire V480 (at least those equipped with version 4 Schizo bridges) under FreeBSD still leads to the firmware issuing a FATAL RESET due to what appears to be a CPU bug, which needs to be worked around. * Work on supporting Sun Fire V1280 has been started but still is in very early stages. Unfortunately, these are rather quirky machines. After solving two firmware specialties the loader now is able to boot the kernel but the latter currently still fails in early cycles as trying to take the trap table over from the firmware results in a solid hang. __________________________________________________________________ Group Limit Increase Contact: Brooks Davis Historically, FreeBSD has limited the number of supplemental groups per process to 15 (NGROUPS_MAX was incorrectly declared to be 16). In FreeBSD 8.0-RELEASE we raised the limit to 1023, which should be sufficient for most users and will be acceptably efficient for incorrectly written applications that statically allocate NGROUPS_MAX + 1 entries. Because some systems such as Linux 2.6 support a larger group limit, we have further relaxed this restriction in 9.0-CURRENT and made kern.ngroups a tunable value, which supports values between 1023 and INT_MAX - 1. We plan to merge this to 8-STABLE before 8.1-RELEASE. __________________________________________________________________ HAST -- Highly Available Storage URL: http://lists.FreeBSD.org/pipermail/freebsd-announce/2009-October/001279 .html Contact: Pawel Jakub Dawidek HAST software will provide synchronous replication of any GEOM provider (eg. disk, partition, mirror, etc.) or file from one FreeBSD machine (primary node) to another one (secondary node). Because data is replicated at the block level neither applications, nor file systems have to be modified to take advantage of this functionality. The functionality that HAST software will provide is very similar to the functionality provided by the DRBD project for Linux. The HAST project is sponsored by the FreeBSD Foundation. Work is progressing well; first milestone was reached in December 2009 and the expected project completion date is January 31, 2010. Check out FreeBSD mailing lists for patches to test in February and wish me good luck! And by the way, do not forget to donate to the FreeBSD Foundation, as your donations make projects like this possible. Thank you! __________________________________________________________________ Intel XScale hwpmc(9) support Contact: Rui Paulo Preliminary Hardware Performance Counter support for Intel XScale ARM processors was committed to FreeBSD 9.0-CURRENT in December. This adds another supported architecture to hwpmc(9). The system works for basic performance counter usage but more advanced usage scenarios, namely callchain support, are not yet implemented. __________________________________________________________________ IP Payload Compression Protocol support Contact: Bjoern A. Zeeb One of the longer outstanding feature problems with the FreeBSD IP security stack, broken IP Payload Compression Protocol (IPcomp) support, has been fixed. While working on the fix, various problems had been identified: * Problems with the IPcomp packet handling in IPsec. * opencrypto compression handling and deflate implementation limitations. These were debugged using DTrace SDT probes. * Problems due to an outdated version of zlib used in some parts of the network stack and by the opencrypto framework. Patches for all but the zlib support have been committed to 9.0-RELEASE and merged to all supported stable branches including 6-STABLE. Special thanks to Eugene Grosbein for helping with testing. Open tasks: 1. Fix ng_deflate so that we can make use of Kip Macy's work on an up-to-date unified zlib version in the kernel, which would also fix the last occasional IPcomp hiccups. __________________________________________________________________ meetBSD 2010 -- The BSD Conference URL: http://www.meetBSD.org Contact: meetBSD Information The meetBSD conference is an annual event gathering users and developers of the BSD operating system family, mostly FreeBSD, NetBSD and OpenBSD. Afer the special California edition, meetBSD Wintercamp in Livigno, this year we are back to Krakow, Poland. In 2010, meetBSD will be held on 2-3 July at the Jagiellonian University. See the conference main web site for more details. __________________________________________________________________ NFSv4 ACL support URL: http://wiki.FreeBSD.org/NFSv4_ACLs Contact: Edward Tomasz Napierala Native NFSv4 ACL support in ZFS and UFS has been committed into 9.0-CURRENT. It is expected to be MFCed in order to make it into FreeBSD 8.1-RELEASE. Open tasks: 1. Support for NFSv4 ACLs in tar(1). 2. MFC. __________________________________________________________________ NVIDIA amd64 driver URL: http://www.nvnews.net/vbulletin/showthread.php?t=142120 Contact: John Baldwin NVIDIA has released the first BETA version of its graphics drivers for FreeBSD/amd64. Note that this driver will work on FreeBSD versions 7.3-RELEASE or 8.0-RELEASE and later. It also works on very recent versions of 7.2-STABLE. More details are provided in the official release announcement. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon Most of the recent activity has been dealing with the 8.0-RELEASE process. As an experiment, we have tried to decouple the ports QA timeline as much as possible from the src QA timeline. Although this meant that the impact on people actively maintaining and using ports has been much less than in previous releases, it still has not solved the problem of the release going out with a stale set of packages. We are still trying to come up with a better solution for the problem. The ports count is over 21,000. The PR count jumped to over 1,000 but is now back to around 950. We are currently building packages for amd64-6, amd64-7, amd64-8, i386-6, i386-7, i386-8, i386-9, ia64-8, sparc64-7, and sparc64-8. This represents the addition of i386-9 and ia64-8 since the last report. There has been some discussion of when to drop regular package builds for 6.X but no decision has been made yet. The cluster and the port managers are struggling to keep up with so many branches being active all at the same time. Mark Linimon continues to make progress on the cluster nodes. Almost every node that does not have a hard disk failure is now online. In addition, he continues to make progress debugging problems that occasionally take nodes offline. The next task is to characterize the overall performance of the build cluster. The question has been asked of us, "what would it take to speed up package builds?" There is no one simple answer. It is not merely a matter of having a larger number of package building machines, so before asking for funding we first need to identify the current bottlenecks. While we are starting to understand the problems on the nodes, the problems on the dispatch machine itself are much harder. Complicating the matter is that there are several periodic processes (ZFS backup, ZFS expiration, and errorlog compression, among others) that can combine to slow that machine significantly. The simultaneous interaction of all these is proving difficult to quantify. Between Pav Lucistnik and Martin Wilke, many more experimental ports runs have been completed and committed. We have added 3 new committers since the last report, and 1 older one has rejoined us. Open tasks: 1. We are still trying to set up ports tinderboxes that can be made available to committers for pre-testing. 2. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 3. Although we have added many maintainers, we still have more than 4,700 unmaintained ports. (See, for instance, the list on portsmon. The percentage remains steady at just over 22%.) We are always looking for dedicated volunteers to adopt at least a few unmaintained ports. As well, the packages on amd64 and especially sparc64 lag behind i386, and we need more testers for those. __________________________________________________________________ POSIX utmpx for FreeBSD URL: http://lists.FreeBSD.org/pipermail/freebsd-current/2010-January/014893. html URL: http://www.opengroup.org/onlinepubs/9699919799/functions/endutxent.html URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/lib/libc/gen/utmpx.c URL: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/ port/gen/getutx.c Contact: Ed Schouten On January 13, I removed the utmp user accounting database and replaced it with a new POSIX utmpx implementation. Unfortunately, the upgrade path is a bit complex, because the utmp interface provided almost no library interface to interact with the database files. This change may have caused some regressions. Some ports may fail to build, while there could also be bugs in the library functions. Open tasks: 1. Get a list of broken ports. 2. Fix them to comply to standards. 3. Send patches upstream. __________________________________________________________________ Ralink wireless RT2700U/2800U/3000U run(4) USB driver URL: http://forums.FreeBSD.org/showthread.php?t=7562 Contact: Akinori Furukoshi The run(4) driver brings support for Ralink RT2700U/2800U/3000U USB wireless devices. For detailed information and list of all the supported devices, please see the above mentioned URL. The source code has been imported to the USB P4 repository on January 10, 2010 (172906). Open tasks: 1. Solve USB_TIMEOUT problem when sending beacons, and/or confirm which chipsets supports AP mode if all of them do not support it. 2. Read TX stats for AMRR on AP mode, and/or confirm which chipsets supports AP mode if all of them do not support it. 3. Maintain the code. __________________________________________________________________ SUJ -- Journaled SoftUpdates URL: http://jeffr_tech.livejournal.com/ Contact: Jeff Roberson I have been adding a small intent log to SoftUpdates to eliminate the requirement for fsck after an unclean shutdown. This work has been funded by Yahoo!, iXsystems, and Juniper. Kirk McKusick has been aiding me with design critiques and helping me better understand SoftUpdates. Extensive testing by myself and Peter Holm has yielded a stable patch. Current users are encouraged to follow the instructions posted to the current@FreeBSD.org mailing list to verify stability in your own workloads. Updates are forthcoming and it is expected to be merged to 9.0-CURRENT before the end of January. Ports to older versions of FreeBSD will be available in SVN under alternate branches. Official backports will be decided by re@ when 9.0-CURRENT is stable. The changes are fully backwards and forwards compatible as there are very few metadata changes to the filesystem. The journal may be enabled or disabled on existing FFS filesystems using tunefs(8). The log consumes 64 MB of space at maximum and fsck time is bounded by the size of the log rather than the size of the filesystem. Other details are available in my technical journal. __________________________________________________________________ Syncing pf(4) with OpenBSD 4.5 URL: http://svn.FreeBSD.org/viewvc/base/user/eri/pf45/ URL: http://svn.FreeBSD.org/base/user/eri/pf45/head/ Contact: Ermal Luçi This import is based on OpenBSD 4.5 state of pf(4). It includes many improvements over the code currently present in FreeBSD. The actual new feature present in pf45 repository is support for divert(4), which should allow tools like snort_inline to work with pf(4) too. Currently, the pf(4) import is considered stable with normal kernel, as well as VIMAGE enabled kernels. Open tasks: 1. pflow(4)/pflog(4)/pfsync(4) need to be made VIMAGE aware. 2. More regression testing is needed. __________________________________________________________________ The FreeBSD Forums URL: http://forums.FreeBSD.org/ Contact: FreeBSD Forums Admins Contact: FreeBSD Forums Moderators Since the last report we have seen a growth of 2,000 users on our forums resulting in approximately 10,000 registered users at this time. The posts count is about to reach 60,000 soon, which are contained in almost 9,000 threads. The sign-up rate still hovers between 50-100 each week. The total number of visitors (including 'guests') is currently hard to gauge, but is likely to be a substantial multiple of the registered userbase. New topics and posts are actively 'pushed out' to search engines. This in turn makes the forums show up in search results more and more often, making it a valuable and very accessible source of information for the FreeBSD community. One of the contributing factors to the forums' success is their 'BSD-style' approach when it comes to administration and moderation. The forums have a strong and unified identity and are very actively moderated, spam-free, and with a core group of very active and helpful members, dispensing many combined decades' worth of knowledge to starting, intermediate and professional users of FreeBSD. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.FreeBSDFoundation.org/ URL: https://twitter.com/freebsdfndation Contact: Deb Goodkin Despite a difficult economy, we more than doubled our number of donors, we raised $269K towards our goal of $300K, and with an improved economy hope to surpass that this year. We have funded two new projects. One is the Flattened Device Tree by Rafal Jaworowski. And, the second one is Highly Available Storage by Pawel Jakub Dawidek. We continued supporting the New Console Driver by Ed Schouten and Improvements to the FreeBSD TCP Stack by Lawrence Stewart. We also purchased equipment for several projects. We have big plans for the new year! We are going to significantly increase our project development and equipment spending. Stay tuned for a project proposal submission announcement soon. We just announced that we are accepting travel grant applications for AsiaBSDCon and will be accepting them soon for BSDCan. And, we are working on infrastructure projects to beef up hardware for package-building, network-testing, etc. Read more about how we supported the project and community by reading our end-of-year newsletter available at http://www.FreeBSDFoundation.org/press/2009Dec-newsletter.shtml. We are fund-raising for 2010 now! Find out more at http://www.FreeBSDFoundation.org/donate/. __________________________________________________________________ The FreeBSD German Documentation Project URL: http://doc.bsdgroup.de Contact: Johann Kois Contact: Benedict Reuschling Contact: Martin Wilke We are happy to announce that Benedict Reuschling is now free from mentorship and can commit to the documentation tree on his own. Since the last status report, the German Documentation Team has chased updates to various sections of the FreeBSD Handbook, FAQ and the German website. Many handbook pages have been updated to the latest version, including chapters about configuration, disks, kernel configuration, printing, multimedia and virtualization. We require help from volunteers that are willing to contribute bug fixes or translations. The following documents need active maintainership and are a good training ground for those willing to join the translation team: * arch-handbook/jail/ * developers-handbook/I10n/ * developers-handbook/policies/ * developers-handbook/sockets/ (translation from scratch) * handbook/firewalls/ (translation from scratch) * handbook/security/ * porters-handbook/ Open tasks: 1. Read the translations and report bugs to de-bsd-translators@de.FreeBSD.org. 2. Translate articles or missing sections listed above. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu/ URL: http://www.FreeBSD.org/doc/hu/ URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli In the last months, no new translation has been added. Lacking human resources, we can only manage to keep the existing documentation and web page translations up to date. If you are interested in helping us, please contact us via the the email addresses noted above. Open tasks: 1. Translate release notes. 2. Add more article translations. __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/doc/es/articles/fdp-es/ URL: https://listas.es.FreeBSD.org/mailman/listinfo/doc Contact: Gábor Kövesdán There is one article translation pending review. Apart from this, neither translations nor maintainance work have been done. We need more volunteers, mostly translators but we are glad to have more reviewers, as well. One can join by simply subscribing to the translators' mailing list where all the work is done. Open tasks: 1. Update Handbook translation. 2. Update webpage translation. 3. Add more article translations. __________________________________________________________________ The webcamd deamon URL: http://www.selasky.org/hans_petter/video4bsd/ Contact: Hans Petter Selasky The webcamd daemon enables hundreds of different USB based webcam devices to be used under the FreeBSD-8/9 operating system. The webcam daemon is basically an application, which is a port of Video4Linux USB webcam drivers into userspace on FreeBSD. The daemon currently depends on libc, pthreads, libusb and the VIDEO4BSD kernel module. Open tasks: 1. Add support for the remaining Video4Linux USB devices. 2. Make patches for increased buffer sizes, due to higher latency in userspace. Especially for High Speed USB. __________________________________________________________________ V4L support in Linux emulator URL: http://opal.com/freebsd/sys/compat/linux/ Contact: J.R. Oldroyd V4L video support in the Linux emulator is now available. This work allows Linux applications using V4L video calls to work with existing FreeBSD video drivers that provide V4L interfaces. It is tested and working with the net/skype port and also with browser-based Flash applications that access webcams. An early version has been committed to 9.0-CURRENT and work is in progress to commit the latest version and then MFC. It is also tested on FreeBSD-8.0/amd64 and FreeBSD-7.2/i386. Note: to be clear, this does not add V4L support to all webcams. The FreeBSD camera driver must already offer V4L support itself in order for a Linux application to be able to use that camera. The multimedia/pwcbsd port provides the pwc(4) driver that already has V4L support. If your camera is supported by a different driver, you will need to enhance that driver to add V4L support. __________________________________________________________________ VirtualBox on FreeBSD URL: http://wiki.FreeBSD.org/VirtualBox Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Juergen Lock Contact: Martin Wilke VirtualBox 3.1.2 has been committed to the ports tree. Several changes to the port have been performed with this update including: * Port has been renamed to virtualbox-ose to reflect that we are now using the OSE version. * A seperate port for the kernel modules has been created -- virtualbox-ose-kmod. * A seperate port for guest additions for FreeBSD guests has been created -- virtualbox-ose-additions. * Proper FreeBSD support for PulseAudio has been added. * Procfs is not required anymore because vbox uses sysctl(3) now. * Juergen Lock's FreeBSD host networking patches have been added. They are now also in the upstream vbox SVN (modulo vbox variable naming style adjustments). * Allow direct tap networking again (for users that need the best network performance and/or need more complex network setups, like when they want to use routing instead of bridging to e.g. protect guests from messing with the lan's ARP tables; a tap + routing + proxy arp example is in the above freebsd-emulation@ posting.) * Enable vbox's shared MAC feature when using bridged mode on a Wifi interface, together with the virtualbox-ose-kmod change this should fix bridged mode for Wifi users. * We would like to say thanks to all the people that helped us by reporting bugs and submitting fixes. We also thank the VirtualBox developers for their help with the ongoing effort to port VirtualBox to FreeBSD __________________________________________________________________ Wireless mesh networking URL: http://wiki.FreeBSD.org/WifiMesh Contact: Rui Paulo Development of the FreeBSD 802.11s stack continues. The code in FreeBSD HEAD has been updated to comply with draft 4.0. Merge to FreeBSD 8-STABLE will be done soon. The developer is looking for funding to be able to implement mesh link security algorithms and/or coordinated channel access (performance improvement). From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 19:42:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E33E106566C; Sun, 17 Jan 2010 19:42:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 178A58FC14; Sun, 17 Jan 2010 19:42:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0HJgfRo068794; Sun, 17 Jan 2010 14:42:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0HJgfJx068742; Sun, 17 Jan 2010 19:42:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 17 Jan 2010 19:42:41 GMT Message-Id: <201001171942.o0HJgfJx068742@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 19:42:42 -0000 TB --- 2010-01-17 18:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-17 18:15:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-01-17 18:15:00 - cleaning the object tree TB --- 2010-01-17 18:15:19 - cvsupping the source tree TB --- 2010-01-17 18:15:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-01-17 18:16:19 - building world TB --- 2010-01-17 18:16:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-17 18:16:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-17 18:16:19 - TARGET=pc98 TB --- 2010-01-17 18:16:19 - TARGET_ARCH=i386 TB --- 2010-01-17 18:16:19 - TZ=UTC TB --- 2010-01-17 18:16:19 - __MAKE_CONF=/dev/null TB --- 2010-01-17 18:16:19 - cd /src TB --- 2010-01-17 18:16:19 - /usr/bin/make -B buildworld >>> World build started on Sun Jan 17 18:16:19 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jan 17 19:15:44 UTC 2010 TB --- 2010-01-17 19:15:44 - generating LINT kernel config TB --- 2010-01-17 19:15:44 - cd /src/sys/pc98/conf TB --- 2010-01-17 19:15:44 - /usr/bin/make -B LINT TB --- 2010-01-17 19:15:44 - building LINT kernel TB --- 2010-01-17 19:15:44 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-17 19:15:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-17 19:15:44 - TARGET=pc98 TB --- 2010-01-17 19:15:44 - TARGET_ARCH=i386 TB --- 2010-01-17 19:15:44 - TZ=UTC TB --- 2010-01-17 19:15:44 - __MAKE_CONF=/dev/null TB --- 2010-01-17 19:15:44 - cd /src TB --- 2010-01-17 19:15:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 17 19:15:44 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Jan 17 19:37:07 UTC 2010 TB --- 2010-01-17 19:37:07 - building GENERIC kernel TB --- 2010-01-17 19:37:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-17 19:37:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-17 19:37:07 - TARGET=pc98 TB --- 2010-01-17 19:37:07 - TARGET_ARCH=i386 TB --- 2010-01-17 19:37:07 - TZ=UTC TB --- 2010-01-17 19:37:07 - __MAKE_CONF=/dev/null TB --- 2010-01-17 19:37:07 - cd /src TB --- 2010-01-17 19:37:07 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jan 17 19:37:08 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/qdivrem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/pc98/cbus/cbus_dma.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/pc98/cbus/clock.c /src/sys/pc98/cbus/clock.c:104: error: variable 'using_lapic_timer' has initializer but incomplete type /src/sys/pc98/cbus/clock.c:104: error: 'LAPIC_CLOCK_NONE' undeclared here (not in a function) *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-17 19:42:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-17 19:42:41 - ERROR: failed to build GENERIC kernel TB --- 2010-01-17 19:42:41 - 3905.27 user 856.39 system 5260.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 19:58:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 026B410657BF for ; Sun, 17 Jan 2010 19:58:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id BE72E8FC0C for ; Sun, 17 Jan 2010 19:58:32 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id o0HJwcNT069288; Sun, 17 Jan 2010 11:58:38 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id o0HJwcL4069287; Sun, 17 Jan 2010 11:58:38 -0800 (PST) (envelope-from sgk) Date: Sun, 17 Jan 2010 11:58:38 -0800 From: Steve Kargl To: Kohji Okuno Message-ID: <20100117195838.GA69278@troutmask.apl.washington.edu> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 19:58:33 -0000 On Sun, Jan 17, 2010 at 03:28:35PM +0900, Kohji Okuno wrote: > > Could you check sched_4bsd.patch, please? > Kohji, I do not have the proper skills to evaluate your patch. Hopefully, one of the scheduler gurus can read over your analysis and patch, because I use the 4BSD scheduler on all my systems due to ULE's poor performance. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 20:10:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBBF21065692; Sun, 17 Jan 2010 20:10:59 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF9B8FC1A; Sun, 17 Jan 2010 20:10:59 +0000 (UTC) Received: from [85.175.178.193] (helo=izar) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1NWbSc-000EKQ-9w; Sun, 17 Jan 2010 23:10:58 +0300 From: Boris Samorodov To: Alexander Motin References: <4B53261E.3020102@FreeBSD.org> Date: Sun, 17 Jan 2010 23:10:56 +0300 In-Reply-To: <4B53261E.3020102@FreeBSD.org> (Alexander Motin's message of "Sun, 17 Jan 2010 17:00:46 +0200") Message-ID: <07161983@ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD-Current Subject: Re: ROOT MOUNT ERROR: booting from a built-in flash reader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 20:10:59 -0000 On Sun, 17 Jan 2010 17:00:46 +0200 Alexander Motin wrote: > Boris Samorodov wrote: > > I've got a EEEPC-1000 and boot FreeBSD 9.0-CURRENT i386 r202342 > > from a SDHC card inserted into the built-in flash reader. The OS > > stops while mounting a root filesystem and prompts for a manual > > root filesystem specification. > > > > The da0 disk appears at the system console just after the > > "mountroot>" propmt. If I type ufs:/dev/da0s1a the boot proceeds. > > > > Are there any patches for testing? ;-) > Now I am working on a new scan routine for CAM. I'll probably publish > patches in a few days. If your card reader (AFAIK there are USB-based > one) Yes, it's the USD device. > will be able to register it's SCSI bus to CAM before the rest of > CAM-supported controllers (for example, ata(4) with ATA_CAM) finish > their scan, new routine will manage system waiting for it also. It not - > it will be a another question. OK, I'll wait for your patches, thanks. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Jan 17 21:32:17 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 017CD106566B; Sun, 17 Jan 2010 21:32:17 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id B47358FC13; Sun, 17 Jan 2010 21:32:16 +0000 (UTC) Received: from [85.175.178.193] (helo=izar) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1NWcLV-000EyO-9h; Mon, 18 Jan 2010 00:07:41 +0300 From: Boris Samorodov To: Ed Schouten References: <20100113194254.GR64905@hoeg.nl> Date: Mon, 18 Jan 2010 00:07:39 +0300 In-Reply-To: <20100113194254.GR64905@hoeg.nl> (Ed Schouten's message of "Wed, 13 Jan 2010 20:42:54 +0100") Message-ID: <30368580@ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: ports@FreeBSD.org, vbox@FreeBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 21:32:17 -0000 Hello Ed, thanks for your hard work! On Wed, 13 Jan 2010 20:42:54 +0100 Ed Schouten wrote: > I've noticed there is some breakage in ports, but it shouldn't be too > serious. Seems that emulators/virtualbox-ose is broken: ----- ... kBuild: Compiling VBoxService - /usr/ports/emulators/virtualbox-ose/work/Vi= rtualBox-3.1.2_OSE/src/VBox/Additions/common/VBoxService/VBoxServiceVMInfo.= cpp In file included from /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3= .1.2_OSE/src/VBox/Additions/common/VBoxService/VBoxServiceVMInfo.cpp:41: /usr/include/utmp.h:2:2: error: #error " has been replaced by " kBuild: Forcing static libstdc++ kBuild: Compiling VBoxClient - /usr/ports/emulators/virtualbox-ose/work/Vir= tualBox-3.1.2_OSE/src/VBox/GuestHost/SharedClipboard/clipboard-helper.cpp kmk[2]: *** [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/= out/freebsd.x86/release/obj/VBoxService/VBoxServiceVMInfo.o] Error 1 The failing command: @c++ -c -O2 -g -pipe -pedantic -Wall -Wextra -Wno-missing-field-initializer= s -Wno-unused -Wno-trigraphs -Wno-long-long -Wno-variadic-macros -march=3Di= 586 -O2 -mtune=3Dgeneric -fno-omit-frame-pointer -fno-strict-aliasing -fvis= ibility=3Dhidden -DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT = -fvisibility-inlines-hidden -fno-exceptions -m32 -I/usr/include -I/usr/X11R= 6/include -I/usr/local/include -I/usr/ports/emulators/virtualbox-ose/work/V= irtualBox-3.1.2_OSE/include -I/usr/ports/emulators/virtualbox-ose/work/Virt= ualBox-3.1.2_OSE/out/freebsd.x86/release -DVBOX -DVBOX_OSE -DVBOX_WITH_64_B= ITS_GUESTS -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=3D\"/usr/local/share/= virtualbox-ose\" -DRTPATH_APP_PRIVATE_ARCH=3D\"/usr/local/lib/virtualbox\" = -DRTPATH_SHARED_LIBS=3D\"/usr/local/lib/virtualbox\" -DRTPATH_APP_DOCS=3D\"= /usr/local/share/doc/virtualbox-ose\" -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_AR= CH_X86 -D__X86__ -DIN_RING3 -DHC_ARCH_BITS=3D32 -DGC_ARCH_BITS=3D64 -DIN_GU= EST -DIN_GUEST_R3 -DIN_RT_R3 -DVBOXSERVICE_TIMESYNC -DVBOX_WITH_GUEST_PROPS= -DVBOXSERVICE_VMINFO -DVBOX_SVN_REV=3D56127 -Wp,-MD,/usr/ports/emulators/v= irtualbox-ose/work/VirtualBox-3.1.2_OSE/out/freebsd.x86/release/obj/VBoxSer= vice/VBoxServiceVMInfo.o.dep -Wp,-MT,/usr/ports/emulators/virtualbox-ose/wo= rk/VirtualBox-3.1.2_OSE/out/freebsd.x86/release/obj/VBoxService/VBoxService= VMInfo.o -Wp,-MP -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1= .2_OSE/out/freebsd.x86/release/obj/VBoxService/VBoxServiceVMInfo.o /usr/por= ts/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox/Additions/co= mmon/VBoxService/VBoxServiceVMInfo.cpp kmk[2]: *** Waiting for unfinished jobs.... kmk[2]: Leaving directory `/usr/ports/emulators/virtualbox-ose/work/Virtual= Box-3.1.2_OSE' kmk[2]: Entering directory `/usr/ports/emulators/virtualbox-ose/work/Virtua= lBox-3.1.2_OSE' kmk[2]: *** Exiting with status 2 kmk[1]: *** [pass_binaries_this] Error 2 kmk[1]: Leaving directory `/usr/ports/emulators/virtualbox-ose/work/Virtual= Box-3.1.2_OSE' kmk: *** [pass_binaries_order] Error 2 *** Error code 2 Stop in /usr/ports/emulators/virtualbox-ose. *** Error code 1 ... ----- --=20 WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 02:58:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FA5D1065670 for ; Mon, 18 Jan 2010 02:58:43 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id A76108FC13 for ; Mon, 18 Jan 2010 02:58:42 +0000 (UTC) Received: by fxm27 with SMTP id 27so1849122fxm.3 for ; Sun, 17 Jan 2010 18:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=Hys3Ea1hVWTUMRFcifGkYPEsgL0vnZ19kL6NWi/jyrE=; b=P2RADtv8Z0WHiUNGcuYx+w7zd+LcjkzR16saAMTgtxDL+uuatYbbOQp4Skd+D3JgpF sjXjHZsrQxFLSrku7TQUb3RSiSpcuFW8UJtVlpHuQEzftkTbt1XkJ9ch+TnZYpk+8CZP lQ0KEWG6Cd2Yg4gqRUtlUKk4No4re/KULCQG0= 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=LQaTZVHsF9vkCMjjCjQ7pFKDcsdYDk/t0l5y8ftwMbDYregUZHcjT4wmuc49+0PUV8 irHxknfAm7MdPydfWpS9+2SeBcY0gCjVw46bPpit3ZDmeP91wHNt6wIDTBXlHTJsfM2I KhS8Pjr/SptRIebo62DyMHaUoXtQIg1osjMd8= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.132.203 with SMTP id c11mr6836621fat.27.1263783521393; Sun, 17 Jan 2010 18:58:41 -0800 (PST) In-Reply-To: <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> Date: Mon, 18 Jan 2010 03:58:41 +0100 X-Google-Sender-Auth: d23c91cda06b0eb1 Message-ID: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> From: Attilio Rao To: Kohji Okuno Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Jeff Roberson Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 02:58:43 -0000 2010/1/17 Kohji Okuno : > Hello, > > Could you check sched_4bsd.patch, please? I think, instead, that what needs to happen is to have sched_switch() to do a lock handover from sleepq/turnstile spinlock to schedlock. That way, if threads are willing to contest on td_lock they will be still inhibited. I'm not sure if this patch breaks any invariant, if you may test I would appreciate: http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff Reviews and comments are appreciated. BTW, nice catch. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 02:59:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C15106566B for ; Mon, 18 Jan 2010 02:59:53 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id ED16C8FC1E for ; Mon, 18 Jan 2010 02:59:52 +0000 (UTC) Received: by fxm27 with SMTP id 27so1849508fxm.3 for ; Sun, 17 Jan 2010 18:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=lBN+EZ1n/IwFS9XtpDnsxqiMzWCcOi3cWrxw6pukFlY=; b=iQe91cckE02AKBdALvMHJSQy9tLz5v1aTp4xXv78tWCF2CK1r7jlxOm8wBUWX3aSRR FoyJBHRBpr71aly9VIl0GNFE1XjorUvrDd8g0F6RfCnS5sMl7dVu7buHBhmoRR8VnKdE EQjJ8R3KjebKrBpdHqvMyXTB3TnMvUPmaz52w= 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=HcRsxreHO2ZEh0mpjTC/VR+jVeozOe/SCs3gyT3+pkH62Dg89PSrAwmjS2f9GQTNll 11zI0faraHBZqPVvSaFIU/52XybthQOUOy5RKuFAJgaG06RQ+ZUguvAIXw7TSBLjHygJ uAZePc26TuFv/HXUk1tSPB4f5glb62FstsK5M= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.5.18 with SMTP id 18mr6745134fat.58.1263783592082; Sun, 17 Jan 2010 18:59:52 -0800 (PST) In-Reply-To: <20100117195838.GA69278@troutmask.apl.washington.edu> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <20100117195838.GA69278@troutmask.apl.washington.edu> Date: Mon, 18 Jan 2010 03:59:52 +0100 X-Google-Sender-Auth: a02aacc5b6ee15f8 Message-ID: <3bbf2fe11001171859h278b7e74p898d219697e3802e@mail.gmail.com> From: Attilio Rao To: Steve Kargl Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Kohji Okuno Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 02:59:53 -0000 2010/1/17 Steve Kargl : > On Sun, Jan 17, 2010 at 03:28:35PM +0900, Kohji Okuno wrote: >> >> Could you check sched_4bsd.patch, please? >> > > Kohji, > > I do not have the proper skills to evaluate your patch. > Hopefully, one of the scheduler gurus can read over > your analysis and patch, because I use the 4BSD scheduler > on all my systems due to ULE's poor performance. Did you fill any PR with datas or mailed MLs? If yes, can you point to the e-mail reports/PR you did? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 03:40:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02BA51065672; Mon, 18 Jan 2010 03:40:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id D55C38FC15; Mon, 18 Jan 2010 03:40:11 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id o0I3eHQG071221; Sun, 17 Jan 2010 19:40:17 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id o0I3eHmi071220; Sun, 17 Jan 2010 19:40:17 -0800 (PST) (envelope-from sgk) Date: Sun, 17 Jan 2010 19:40:17 -0800 From: Steve Kargl To: Attilio Rao Message-ID: <20100118034017.GA71183@troutmask.apl.washington.edu> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <20100117195838.GA69278@troutmask.apl.washington.edu> <3bbf2fe11001171859h278b7e74p898d219697e3802e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe11001171859h278b7e74p898d219697e3802e@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Kohji Okuno Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 03:40:12 -0000 On Mon, Jan 18, 2010 at 03:59:52AM +0100, Attilio Rao wrote: > 2010/1/17 Steve Kargl : > > On Sun, Jan 17, 2010 at 03:28:35PM +0900, Kohji Okuno wrote: > >> > >> Could you check sched_4bsd.patch, please? > >> > > > > Kohji, > > > > I do not have the proper skills to evaluate your patch. > > Hopefully, one of the scheduler gurus can read over > > your analysis and patch, because I use the 4BSD scheduler > > on all my systems due to ULE's poor performance. > > Did you fill any PR with datas or mailed MLs? If yes, can you point to > the e-mail reports/PR you did? > I have communicated directly with Jeff about the problem. There are also emails to freebsd-current about the issue [1]. In fact, I setup one of the nodes on my cluster to given Jeff root access. Unfortunately, Jeff like many others including myself have limited time. [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=199808+0+archive/2009/freebsd-current/20091018.freebsd-current -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 06:54:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6AB8106566B for ; Mon, 18 Jan 2010 06:54:02 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 457D78FC08 for ; Mon, 18 Jan 2010 06:54:02 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id o0I6s0qT020168; Mon, 18 Jan 2010 15:54:00 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id o0I6s0g27890; Mon, 18 Jan 2010 15:54:00 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla4) id o0I6s0Jf008854; Mon, 18 Jan 2010 15:54:00 +0900 (JST) Received: from localhost by somla4.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0I6rq9t008686; Mon, 18 Jan 2010 15:53:52 +0900 (JST) Date: Mon, 18 Jan 2010 15:53:52 +0900 (JST) Message-Id: <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org From: Kohji Okuno In-Reply-To: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: okuno.kohji@jp.panasonic.com, freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 06:54:02 -0000 Hello, Thank you, Attilio. I checked your patch. I think that your patch is better. I tested the patch quickly, and I think it's OK. # This probrem does not occur easily :-< What do you think about maybe_resched()? I have never experienced about maybe_resched(), but I think that the race condition may occur. <> sched_4bsd.c: maybe_resched() sched_4bsd.c: resetpriority_thread() sched_4bsd.c: sched_nice() get thread_lock(td) kern_resource.c: donice() kern_resource.c: setpriority() get PROC_LOCK() static void maybe_resched(struct thread *td) { THREAD_LOCK_ASSERT(td, MA_OWNED); if (td->td_priority < curthread->td_priority) curthread->td_flags |= TDF_NEEDRESCHED; } I think, when td->td_lock is not &sched_lock, curthread->td_lock is not locked in maybe_resched(). Best regards, Kohji Okuno. From: Attilio Rao Subject: Re: Bug about sched_4bsd? Date: Mon, 18 Jan 2010 03:58:41 +0100 Message-ID: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> > 2010/1/17 Kohji Okuno : >> Hello, >> >> Could you check sched_4bsd.patch, please? > > I think, instead, that what needs to happen is to have sched_switch() > to do a lock handover from sleepq/turnstile spinlock to schedlock. > That way, if threads are willing to contest on td_lock they will be > still inhibited. > I'm not sure if this patch breaks any invariant, if you may test I > would appreciate: > http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff > > Reviews and comments are appreciated. > BTW, nice catch. > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 07:05:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D9C3106566B; Mon, 18 Jan 2010 07:05:06 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 037888FC16; Mon, 18 Jan 2010 07:05:05 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id o0I754Yc027066; Mon, 18 Jan 2010 16:05:04 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id o0I754116469; Mon, 18 Jan 2010 16:05:04 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla2) id o0I753v8009257; Mon, 18 Jan 2010 16:05:03 +0900 (JST) Received: from localhost by somla2.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0I74wVH008904; Mon, 18 Jan 2010 16:04:58 +0900 (JST) Date: Mon, 18 Jan 2010 16:04:56 +0900 (JST) Message-Id: <20100118.160456.519459540419521301.okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org From: Kohji Okuno In-Reply-To: <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> References: <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jroberson@jroberson.net, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 07:05:06 -0000 Hello, I have a question. The sleeping thread (on turnstile or on sleepque) can set sched_lock to td_lock, kernel are allowed? Best regards, Kohji Okuno. > Hello, > > Thank you, Attilio. > I checked your patch. I think that your patch is better. > I tested the patch quickly, and I think it's OK. > # This probrem does not occur easily :-< > > > What do you think about maybe_resched()? > I have never experienced about maybe_resched(), but I think that the > race condition may occur. > > <> > sched_4bsd.c: maybe_resched() > sched_4bsd.c: resetpriority_thread() > sched_4bsd.c: sched_nice() get thread_lock(td) > kern_resource.c: donice() > kern_resource.c: setpriority() get PROC_LOCK() > > static void > maybe_resched(struct thread *td) > { > THREAD_LOCK_ASSERT(td, MA_OWNED); > if (td->td_priority < curthread->td_priority) > curthread->td_flags |= TDF_NEEDRESCHED; > } > > I think, when td->td_lock is not &sched_lock, curthread->td_lock is > not locked in maybe_resched(). > > Best regards, > Kohji Okuno. > > From: Attilio Rao > Subject: Re: Bug about sched_4bsd? > Date: Mon, 18 Jan 2010 03:58:41 +0100 > Message-ID: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> > >> 2010/1/17 Kohji Okuno : >>> Hello, >>> >>> Could you check sched_4bsd.patch, please? >> >> I think, instead, that what needs to happen is to have sched_switch() >> to do a lock handover from sleepq/turnstile spinlock to schedlock. >> That way, if threads are willing to contest on td_lock they will be >> still inhibited. >> I'm not sure if this patch breaks any invariant, if you may test I >> would appreciate: >> http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff >> >> Reviews and comments are appreciated. >> BTW, nice catch. >> >> Attilio >> >> >> -- >> Peace can only be achieved by understanding - A. Einstein >> _______________________________________________ >> 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" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 07:06:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4F701065692 for ; Mon, 18 Jan 2010 07:06:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 458948FC17 for ; Mon, 18 Jan 2010 07:06:51 +0000 (UTC) Received: by fxm27 with SMTP id 27so1933250fxm.3 for ; Sun, 17 Jan 2010 23:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=qpwKPMuLrYF9KI0tjRzA69CZc4o2EfuSzmxzSv9IY7A=; b=IC0WXojG8WFZaMWFfDxkoOi+lnXtSyWzVAAiwg+DQhUMaVPgJxEbKplaFayq9sOsmo jxUFDIcYU1nlvSKAtg5mNEzq4rr+yHEi/xP0MRMIO0C4LJmsKgkowunthEDlYM4Mokfv eWFP8pilV29wrCbCbpEBh5p0SktYWYgQWQb80= 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=bBm63vD09zSvRP3CuGa9JaFHWKLWkFTNgYn+8Iw+OrxYwe2ECZez+RJW+IVOpm37+B dKQ1e42AQLKPMqw9n1/KR8i04GeWR7yhGq22hHJJKJ5HJRuPx55W2N+e94ZHFXd7oDRn H+l4ccu93wwfZg2bXOARS4OsieZpp9F3i1ytE= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.143.82 with SMTP id t18mr7040790fau.52.1263798411213; Sun, 17 Jan 2010 23:06:51 -0800 (PST) In-Reply-To: <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> Date: Mon, 18 Jan 2010 08:06:51 +0100 X-Google-Sender-Auth: 90acd4bdead2b246 Message-ID: <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com> From: Attilio Rao To: Kohji Okuno Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 07:06:52 -0000 2010/1/18 Kohji Okuno : > Hello, > > Thank you, Attilio. > I checked your patch. I think that your patch is better. > I tested the patch quickly, and I think it's OK. > # This probrem does not occur easily :-< > > > What do you think about maybe_resched()? > I have never experienced about maybe_resched(), but I think that the > race condition may occur. > > <> > sched_4bsd.c: =C2=A0 =C2=A0 maybe_resched() > sched_4bsd.c: =C2=A0 =C2=A0 resetpriority_thread() > sched_4bsd.c: =C2=A0 =C2=A0 sched_nice() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0get thread_lock(td) > kern_resource.c: =C2=A0donice() > kern_resource.c: =C2=A0setpriority() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 get PROC_LOCK() > > static void > maybe_resched(struct thread *td) > { > =C2=A0 =C2=A0 =C2=A0 =C2=A0THREAD_LOCK_ASSERT(td, MA_OWNED); > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (td->td_priority < curthread->td_priority) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0curthread->td_flag= s |=3D TDF_NEEDRESCHED; > } > > I think, when td->td_lock is not &sched_lock, curthread->td_lock is > not locked in maybe_resched(). I didn't look closely to the maybe_resched() callers but I think it is ok. The thread_lock() function works in a way that the callers don't need to know which container lock is present in a particular moment, there is always a guarantee that the contenders will spin if the lock on the struct can't be held. In the case you outlined something very particular was happening. Basically, we get &sched_lock but sched_lock was not the lock present on td_lock. That means all the other paths willing to access to td_lock for that thread (via thread_lock()) were allowed to do that even if we wanted to keep the critical path closed. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 12:22:00 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7602106566B for ; Mon, 18 Jan 2010 12:22:00 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 60C7D8FC0A for ; Mon, 18 Jan 2010 12:22:00 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0ICLh0Q085726; Mon, 18 Jan 2010 13:21:58 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0ICLhWA085725; Mon, 18 Jan 2010 13:21:43 +0100 (CET) (envelope-from olli) Date: Mon, 18 Jan 2010 13:21:43 +0100 (CET) Message-Id: <201001181221.o0ICLhWA085725@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com In-Reply-To: <20100114191738.GZ1228@michelle.cdnetworks.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 18 Jan 2010 13:21:58 +0100 (CET) Cc: Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 12:22:00 -0000 Sorry for the late reply, I was offline during the weekend. Pyun YongHyeon wrote: > On Thu, Jan 14, 2010 at 07:39:47PM +0100, Oliver Fromme wrote: > > Yes! The patch works perfectly. Thank you very much! > > With that patch, brgphy correctly detects 1000baseSX. > > I get a link, and tcpdump sees packets flying by. > > > > Would you please commit this, and MFC to stable/[78] > > after a while? > > Done(r202293, r202294). Cool. Thanks again! > Ok, now let's open new thread for bce(4) issues. Will do that in a few minutes. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 15:32:00 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEE98106568F for ; Mon, 18 Jan 2010 15:32:00 +0000 (UTC) (envelope-from mjs@rakupottery.org.uk) Received: from anchor-post-2.mail.demon.net (anchor-post-2.mail.demon.net [195.173.77.133]) by mx1.freebsd.org (Postfix) with ESMTP id B729B8FC15 for ; Mon, 18 Jan 2010 15:32:00 +0000 (UTC) Received: from rakuman.demon.co.uk ([80.177.154.53] helo=rakuba.rakupottery.org.uk) by anchor-post-2.mail.demon.net with esmtp (Exim 4.69) id 1NWtaB-0006hH-kt; Mon, 18 Jan 2010 15:31:59 +0000 Message-ID: <4B547EEF.6000105@rakupottery.org.uk> Date: Mon, 18 Jan 2010 15:31:59 +0000 From: Martin Smith User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: current@FreeBSD.org References: <20100113194254.GR64905@hoeg.nl> In-Reply-To: <20100113194254.GR64905@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 15:32:01 -0000 Ed Schouten wrote: > Hello everyone, > > I just made various commits to FreeBSD HEAD to remove our old user > accounting database interface (see utmp(5)) and replace it by the POSIX > standardized utmpx interface (see getutxent(3)). This means we just got > rid of some annoyances that are as old as the FreeBSD project itself: > snipped > > Be sure to give it a try and report any issues. Thanks! building xorg on a current box of 2 days ago In file referenced from sessreg.h:60 from sessreg.c:77 /usr/include/utmp.h:2:2 error #error " has been replaced by " continues with more related errors and stops any fix for this yet -- Martin From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 15:39:53 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42E801065670 for ; Mon, 18 Jan 2010 15:39:53 +0000 (UTC) (envelope-from mjs@rakupottery.org.uk) Received: from anchor-post-2.mail.demon.net (anchor-post-2.mail.demon.net [195.173.77.133]) by mx1.freebsd.org (Postfix) with ESMTP id 0C0598FC17 for ; Mon, 18 Jan 2010 15:39:53 +0000 (UTC) Received: from rakuman.demon.co.uk ([80.177.154.53] helo=rakuba.rakupottery.org.uk) by anchor-post-2.mail.demon.net with esmtp (Exim 4.69) id 1NWtho-0001on-kW; Mon, 18 Jan 2010 15:39:52 +0000 Message-ID: <4B5480C8.9040102@rakupottery.org.uk> Date: Mon, 18 Jan 2010 15:39:52 +0000 From: Martin Smith User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: current@FreeBSD.org References: <20100113194254.GR64905@hoeg.nl> <4B547EEF.6000105@rakupottery.org.uk> In-Reply-To: <4B547EEF.6000105@rakupottery.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 15:39:53 -0000 Martin Smith wrote: > Ed Schouten wrote: >> Hello everyone, >> >> I just made various commits to FreeBSD HEAD to remove our old user >> accounting database interface (see utmp(5)) and replace it by the POSIX >> standardized utmpx interface (see getutxent(3)). This means we just got >> rid of some annoyances that are as old as the FreeBSD project itself: >> > snipped > >> >> Be sure to give it a try and report any issues. Thanks! > > building xorg on a current box of 2 days ago > > In file referenced from sessreg.h:60 > from sessreg.c:77 > /usr/include/utmp.h:2:2 error #error " has been replaced by > " > continues with more related errors and stops > > any fix for this yet sorry for the noise, csupped the ports again and it is fixed, many thanks to whoever did it > > -- Martin From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 15:46:26 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97EDD10656B9; Mon, 18 Jan 2010 15:46:26 +0000 (UTC) (envelope-from beat@FreeBSD.org) Received: from marvin.chruetertee.ch (marvin.chruetertee.ch [217.150.245.55]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1248FC0C; Mon, 18 Jan 2010 15:46:25 +0000 (UTC) Received: from daedalus.network.local (gprs23.swisscom-mobile.ch [193.247.250.23]) (authenticated bits=0) by marvin.chruetertee.ch (8.14.3/8.14.3) with ESMTP id o0IFkIri028411 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 18 Jan 2010 15:46:20 GMT (envelope-from beat@FreeBSD.org) Message-ID: <4B5482A2.8030209@FreeBSD.org> Date: Mon, 18 Jan 2010 16:47:46 +0100 From: Beat Gaetzi User-Agent: Thunderbird 2.0.0.23 (X11/20090821) MIME-Version: 1.0 To: Boris Samorodov References: <20100113194254.GR64905@hoeg.nl> <30368580@ipt.ru> In-Reply-To: <30368580@ipt.ru> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, Ed Schouten , vbox@FreeBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 15:46:26 -0000 Hi, Boris Samorodov wrote: > Hello Ed, > > thanks for your hard work! > > On Wed, 13 Jan 2010 20:42:54 +0100 Ed Schouten wrote: > >> I've noticed there is some breakage in ports, but it shouldn't be too >> serious. > > Seems that emulators/virtualbox-ose is broken: Yes, there is a pr open with a patch attached: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/142855 The fix is already in our development repository: http://svn.bluelife.at/index.cgi/blueports/revision/?rev=662 Once everything is tested we will commit the patch. Beat From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 16:33:03 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 329D5106568B for ; Mon, 18 Jan 2010 16:33:03 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id AEB4B8FC16 for ; Mon, 18 Jan 2010 16:33:02 +0000 (UTC) Received: by fxm27 with SMTP id 27so2454036fxm.3 for ; Mon, 18 Jan 2010 08:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=PN+8ZmUYvC3fOBBrSn2RUN9+2+QSH6+uswf1JqFxHJ0=; b=eLBGW1l4EZcbN3jNatY7zu5OL3gAG+d0270CPxpAn6fDZ552j4UNYzSVLen4nXzno0 wv0lSHZu1HHQjfP8W/ndpqGiq7YlbmjGLyxeJFHTK4zKp+/BTWxX5EZkYwWlh+NkfeHg CeH7tAixJKz4NG5tofe5WbTOr133qtJum7xcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=CBMuh04i9mM4M4qBRE96fUeA2bIYwXMYu22ymYOKipi1xCyoJLEsl70nP9AEaHJK1d f0OKE2szSRL3uGPU2ZI6FyGm0u/NABC/oEbN6SZOPTamGhzzAdWBWqeMZOGdwbtfAXvJ ffjz95hclRFCj6Elqe3Ah9ibfPJ15dXXZsyCg= Received: by 10.87.45.14 with SMTP id x14mr7914281fgj.6.1263830756578; Mon, 18 Jan 2010 08:05:56 -0800 (PST) Received: from darklight.org.ru ([213.132.76.16]) by mx.google.com with ESMTPS id l19sm10656214fgb.13.2010.01.18.08.05.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 Jan 2010 08:05:55 -0800 (PST) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.3/8.14.3) with ESMTP id o0IG5qYj003440; Mon, 18 Jan 2010 19:05:52 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.org.ru (8.14.3/8.14.3/Submit) id o0IG5pCQ003439; Mon, 18 Jan 2010 19:05:51 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.org.ru: yuri set sender to yuri.pankov@gmail.com using -f Date: Mon, 18 Jan 2010 19:05:51 +0300 From: Yuri Pankov To: Ed Schouten Message-ID: <20100118160551.GA1699@darklight.org.ru> References: <20100113194254.GR64905@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100113194254.GR64905@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ports@freebsd.org, mav@freebsd.org, current@freebsd.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 16:33:03 -0000 On Wed, Jan 13, 2010 at 08:42:54PM +0100, Ed Schouten wrote: > Hello everyone, > > I just made various commits to FreeBSD HEAD to remove our old user > accounting database interface (see utmp(5)) and replace it by the POSIX > standardized utmpx interface (see getutxent(3)). This means we just got > rid of some annoyances that are as old as the FreeBSD project itself: > > - Hostnames were originally restricted to 16 bytes, which is way too > short for your average hostname generated by your ISP, but also for > IPv6 addresses, which are at most 32 + 7 = 39 characters. > > - No support for login sessions not related to TTYs, like ppp(8), > ftpd(8) sessions. > > - No support for multiple login sessions on one TTY, for example > generated by login(1). > > I was not able to give us a smooth transition from utmp towards utmpx, > simply because our utmp implementation offered almost no utility > functions, which means all consumers modify the database files > themselves. This means you should probably recompile any applications > you're interested in that uses the user accounting database. I realize > this may be quite uncomfortable, but we can't always win. > > [ This information is mainly for port maintainers: ] > > I've noticed there is some breakage in ports, but it shouldn't be too > serious. I've seen cases where an application includes , even > though it doesn't use anything provided by that header. In other cases > they used fields like UT_NAMESIZE to derive the maximum user name length > supported by the system, which is clearly not what this definition was > intended for. I've incremented __FreeBSD_version to 900007 to identify > the import of utmpx. In case a certain port breaks badly, let me know > and I'm willing to take a look at it. > > Be sure to give it a try and report any issues. Thanks! > > -- > Ed Schouten > WWW: http://80386.nl/ net/mpd{4,5} seem to be broken as well: In file included from auth.h:22, from bund.h:22, from ppp.h:117, from modem.c:10: /usr/include/utmp.h:2:2: error: #error " has been replaced by " *** Error code 1 Yuri From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 16:50:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D91001065694 for ; Mon, 18 Jan 2010 16:50:38 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id 6E72D8FC19 for ; Mon, 18 Jan 2010 16:50:38 +0000 (UTC) Received: from [195.4.92.19] (helo=9.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NWuoH-00062K-Ei; Mon, 18 Jan 2010 17:50:37 +0100 Received: from p57ae2ecb.dip0.t-ipconnect.de ([87.174.46.203]:61492 helo=ernst.jennejohn.org) by 9.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NWuoH-0003x5-4k; Mon, 18 Jan 2010 17:50:37 +0100 Date: Mon, 18 Jan 2010 17:50:33 +0100 From: Gary Jennejohn To: Jeff Roberson Message-ID: <20100118175033.7ba10de0@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 16:50:38 -0000 On Fri, 8 Jan 2010 14:56:45 -1000 (HST) Jeff Roberson wrote: > I have been augmenting softupdates with a small journal that will be processed > in lieu of fsck in the event of a crash. I have written some about this > project here: http://jeffr_tech.livejournal.com/ > For some reason I can't access this location. Hmm, firefox doesn't seem to like the '_'. > To install you will need to apply http://people.freebsd.org/~jeff/suj.diff to a > recent current source tree. > I had to apply part of the patch by hand, namely sys/ufs/ufs/ufs_lookup.c here (but only this block, all other patches applied OK) @@ -1221,21 +1210,29 @@ ufs_dirrewrite(dp, oip, newinum, newtype, isrmdir) > You can enable suj by running tunefs -j enable /dev/{device}. > For some reason I was unable to enable SUJ on /usr. I see the error "insufficient contiguous free space for the journal", even though /usr has 31GB free: Filesystem Size Used Avail Capacity Mounted on /dev/ada0s1e 63G 27G 31G 46% /usr /usr does have lots of fragments, but it seems like, with 31GB free, the kernel should be able to find 64MB of free, contiguous space. I didn't try specifying a journal size, however. Kind of inconvenient having /usr without soft-updates :( However, on all other filesystems (/ doesn't use SU) turning on SUJ worked: /dev/ada0s1a on / (ufs, local) /dev/ada0s1d on /var (ufs, local, soft-updates) /dev/ada0s1e on /usr (ufs, NFS exported, local) <== fails /dev/ada0s1f on /home (ufs, NFS exported, local, soft-updates) /dev/ada1a on /oldzfs (ufs, NFS exported, local, soft-updates) /dev/da1a on /uvbox (ufs, local, soft-updates) /dev/ada0s1g on /opt (ufs, NFS exported, local, soft-updates) --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 16:54:30 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ACAF1065670 for ; Mon, 18 Jan 2010 16:54:30 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 127D08FC18 for ; Mon, 18 Jan 2010 16:54:30 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 7FA701CFE8; Mon, 18 Jan 2010 17:54:29 +0100 (CET) Date: Mon, 18 Jan 2010 17:54:29 +0100 From: Ed Schouten To: Gary Jennejohn Message-ID: <20100118165429.GH64905@hoeg.nl> References: <20100118175033.7ba10de0@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ml9JVKHy3wwGZOmd" Content-Disposition: inline In-Reply-To: <20100118175033.7ba10de0@ernst.jennejohn.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Jeff Roberson , FreeBSD Current Subject: Re: Help test softupdates journaling (SUJ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 16:54:30 -0000 --ml9JVKHy3wwGZOmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Gary Jennejohn wrote: > On Fri, 8 Jan 2010 14:56:45 -1000 (HST) > Jeff Roberson wrote: >=20 > > I have been augmenting softupdates with a small journal that will be pr= ocessed=20 > > in lieu of fsck in the event of a crash. I have written some about thi= s=20 > > project here: http://jeffr_tech.livejournal.com/ > >=20 >=20 > For some reason I can't access this location. Hmm, firefox doesn't seem = to like > the '_'. Yeah. '_' isn't a valid character for hostnames, IIRC. http://jeffr-tech.livejournal.com/ also works. Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --ml9JVKHy3wwGZOmd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktUkkUACgkQ52SDGA2eCwUGtwCffN3W1qE0Z56FUX70sFMGAI/R b68An0A6cNEVKnAFravHLGEELmRmA4dZ =otqf -----END PGP SIGNATURE----- --ml9JVKHy3wwGZOmd-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 18:44:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E174F1065676 for ; Mon, 18 Jan 2010 18:44:57 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 3ACC98FC12 for ; Mon, 18 Jan 2010 18:44:55 +0000 (UTC) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0IGtenv032547 for ; Tue, 19 Jan 2010 03:55:40 +1100 Received: from camelot.theinternet.com.au (110.32.243.145.optusnet.com.au [110.32.243.145] (may be forged)) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0IGtclr027724; Tue, 19 Jan 2010 03:55:38 +1100 Received: by camelot.theinternet.com.au (Postfix, from userid 1000) id EC4731703F; Tue, 19 Jan 2010 03:55:37 +1100 (EST) Date: Tue, 19 Jan 2010 03:55:37 +1100 From: Andrew Milton To: Gary Jennejohn Message-ID: <20100118165537.GG81608@camelot.theinternet.com.au> References: <20100118175033.7ba10de0@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100118175033.7ba10de0@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i Cc: Jeff Roberson , current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 18:44:59 -0000 +-------[ Gary Jennejohn ]---------------------- | On Fri, 8 Jan 2010 14:56:45 -1000 (HST) | Jeff Roberson wrote: | | > I have been augmenting softupdates with a small journal that will be processed | > in lieu of fsck in the event of a crash. I have written some about this | > project here: http://jeffr_tech.livejournal.com/ | > | | For some reason I can't access this location. Hmm, firefox doesn't seem to like | the '_'. Because DNS hostnames can't contain underscores... ? -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 19:55:23 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD39E106566C; Mon, 18 Jan 2010 19:55:23 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 95A8E8FC14; Mon, 18 Jan 2010 19:55:23 +0000 (UTC) Received: from [85.173.16.216] (helo=izar) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1NWxh3-0004WZ-Rw; Mon, 18 Jan 2010 22:55:21 +0300 From: Boris Samorodov To: Beat Gaetzi References: <20100113194254.GR64905@hoeg.nl> <30368580@ipt.ru> <4B5482A2.8030209@FreeBSD.org> Date: Mon, 18 Jan 2010 22:55:19 +0300 In-Reply-To: <4B5482A2.8030209@FreeBSD.org> (Beat Gaetzi's message of "Mon, 18 Jan 2010 16:47:46 +0100") Message-ID: <21395448@ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ports@FreeBSD.org, Ed Schouten , vbox@FreeBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 19:55:24 -0000 On Mon, 18 Jan 2010 16:47:46 +0100 Beat Gaetzi wrote: > Boris Samorodov wrote: > > Hello Ed, > > > > thanks for your hard work! > > > > On Wed, 13 Jan 2010 20:42:54 +0100 Ed Schouten wrote: > > > >> I've noticed there is some breakage in ports, but it shouldn't be too > >> serious. > > > > Seems that emulators/virtualbox-ose is broken: > Yes, there is a pr open with a patch attached: > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/142855 > The fix is already in our development repository: > http://svn.bluelife.at/index.cgi/blueports/revision/?rev=662 > Once everything is tested we will commit the patch. Great, thanks! PS. The patch from your repository works good for me. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 20:14:56 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86BB7106568D for ; Mon, 18 Jan 2010 20:14:56 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A5AB8FC16 for ; Mon, 18 Jan 2010 20:14:55 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0IKEdsD004208; Mon, 18 Jan 2010 21:14:54 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0IKEd8A004207; Mon, 18 Jan 2010 21:14:39 +0100 (CET) (envelope-from olli) Date: Mon, 18 Jan 2010 21:14:39 +0100 (CET) Message-Id: <201001182014.o0IKEd8A004207@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 18 Jan 2010 21:14:54 +0100 (CET) Cc: Subject: bce(4) on IBM BladeCenter HS22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:14:56 -0000 Pyun YongHyeon wrote: > Ok, now let's open new thread for bce(4) issues. Ok, it took a little longer because I re-installed one of the blades with 9-current as of today. Again, these are "HS22" blades installed in an IBM BladeCenter. There are two bce(4) interfaces that don't attach correctly. The problem seems to be the same as in PRs kern/136417 and kern/139761 (which are duplicates of each other). Here's the excerpt from dmesg (verbose kernel): bce0: mem 0x92000000-0x93ffffff irq 30 at device 0.0 on pci16 bce0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 260 to local APIC 0 vector 112 bce0: using IRQ 260 for MSI bce0: /usr/src/sys/dev/bce/if_bce.c(1097): No PHY found on child MII bus! device_attach: bce0 attach returned 6 bce1: mem 0x94000000-0x95ffffff irq 37 at device 0.1 on pci16 bce1: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 260 to local APIC 0 vector 112 bce1: using IRQ 260 for MSI bce1: /usr/src/sys/dev/bce/if_bce.c(1097): No PHY found on child MII bus! device_attach: bce1 attach returned 6 Attaching the driver fails, so ifconfig doesn't list anything. The ports are fiber, i.e. they should appear as 1000baseSX. This is what pciconf -lcv says: bce0@pci0:16:0:0: class=0x020000 card=0x03701014 chip=0x163a14e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II BCM5709S Gigabit Ethernet' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 16 messages, 64 bit cap 11[a0] = MSI-X supports 9 messages in map 0x10 cap 10[ac] = PCI-Express 2 endpoint max data 256(512) link x4(x4) bce1@pci0:16:0:1: class=0x020000 card=0x03701014 chip=0x163a14e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II BCM5709S Gigabit Ethernet' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 16 messages, 64 bit cap 11[a0] = MSI-X supports 9 messages in map 0x10 cap 10[ac] = PCI-Express 2 endpoint max data 256(512) link x4(x4) And the relevant parts from devinfo -rv: pcib6 pnpinfo vendor=0x8086 device=0x340e subvendor=0x1014 subdevice=0x340e class=0x060400 at slot=7 function=0 handle=\_SB_.PCI0.ETH1 pci16 bce0 pnpinfo vendor=0x14e4 device=0x163a subvendor=0x1014 subdevice=0x0370 class=0x020000 at slot=0 function=0 I/O memory addresses: 0x92000000-0x93ffffff bce1 pnpinfo vendor=0x14e4 device=0x163a subvendor=0x1014 subdevice=0x0370 class=0x020000 at slot=0 function=1 Interrupt request lines: 260 I/O memory addresses: 0x94000000-0x95ffffff If you need more information, or want me to test any patches, please let me know. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "It combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript." -- Jamie Zawinski, when asked: "What's wrong with perl?" From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 20:19:18 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92291106566C for ; Mon, 18 Jan 2010 20:19:18 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2036B8FC0C for ; Mon, 18 Jan 2010 20:19:17 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0IKJ19d004405; Mon, 18 Jan 2010 21:19:17 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0IKJ1Vn004404; Mon, 18 Jan 2010 21:19:01 +0100 (CET) (envelope-from olli) Date: Mon, 18 Jan 2010 21:19:01 +0100 (CET) Message-Id: <201001182019.o0IKJ1Vn004404@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com In-Reply-To: <20100114191738.GZ1228@michelle.cdnetworks.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 18 Jan 2010 21:19:17 +0100 (CET) Cc: Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:19:18 -0000 Pyun YongHyeon wrote: > Done(r202293, r202294). By the way, I think this probably fixes PR kern/122551, so the PR can be closed after the MFC. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "[...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed." -- Bruce Eckel From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 20:28:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EB4E1065672 for ; Mon, 18 Jan 2010 20:28:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id D2EE18FC14 for ; Mon, 18 Jan 2010 20:28:12 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so721510qwd.7 for ; Mon, 18 Jan 2010 12:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=mnwzJ3UOXD54plzrIGiIyxER3YXScvK8svY75V4HqQ4=; b=EfADXXihSXSdVXtYnW4XRNcrcMWxhK9B03LqHblzEQWK9BymYrvlKlz59apCsL4aCx 9Or7o2H4ZQWdOZLwihVhDD0CTbn+z6ara9SPVuT5yLbD3IMY8yYipqsxHFl0hW+7NTKB NyA6LJohOmoO/mGn5Vizv87rLMZ+g3tXpaK8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=lzujMZXtTb/Iyf4g1c0KIUgKlSlVKSp7xejyox3k4uVv62Uj590u4iQANjo6gWcUrm C73whRJBLuE3S4Af04OpWjqo6N2xpWedh0mMkYQQHUXHZx6fpXQS7OYjTeffFxt3B8xW kfY5rBND5Bh9j2g9zKICLT2xFabSRJ+Cyyd94= Received: by 10.224.71.233 with SMTP id i41mr4736875qaj.89.1263846491930; Mon, 18 Jan 2010 12:28:11 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 23sm5397851qyk.7.2010.01.18.12.28.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 Jan 2010 12:28:11 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 18 Jan 2010 12:28:05 -0800 From: Pyun YongHyeon Date: Mon, 18 Jan 2010 12:28:05 -0800 To: Oliver Fromme Message-ID: <20100118202805.GB1336@michelle.cdnetworks.com> References: <201001182014.o0IKEd8A004207@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline In-Reply-To: <201001182014.o0IKEd8A004207@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.ORG Subject: Re: bce(4) on IBM BladeCenter HS22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:28:13 -0000 --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 18, 2010 at 09:14:39PM +0100, Oliver Fromme wrote: > Pyun YongHyeon wrote: > > Ok, now let's open new thread for bce(4) issues. > > Ok, it took a little longer because I re-installed one of the > blades with 9-current as of today. > > Again, these are "HS22" blades installed in an IBM BladeCenter. > There are two bce(4) interfaces that don't attach correctly. > The problem seems to be the same as in PRs kern/136417 and > kern/139761 (which are duplicates of each other). > > Here's the excerpt from dmesg (verbose kernel): > > bce0: mem 0x92000000-0x93ffffff irq 30 at device 0.0 on pci16 > bce0: attempting to allocate 1 MSI vectors (16 supported) > msi: routing MSI IRQ 260 to local APIC 0 vector 112 > bce0: using IRQ 260 for MSI > bce0: /usr/src/sys/dev/bce/if_bce.c(1097): No PHY found on child MII bus! > device_attach: bce0 attach returned 6 > bce1: mem 0x94000000-0x95ffffff irq 37 at device 0.1 on pci16 > bce1: attempting to allocate 1 MSI vectors (16 supported) > msi: routing MSI IRQ 260 to local APIC 0 vector 112 > bce1: using IRQ 260 for MSI > bce1: /usr/src/sys/dev/bce/if_bce.c(1097): No PHY found on child MII bus! > device_attach: bce1 attach returned 6 > > Attaching the driver fails, so ifconfig doesn't list anything. > The ports are fiber, i.e. they should appear as 1000baseSX. > > This is what pciconf -lcv says: > > bce0@pci0:16:0:0: class=0x020000 card=0x03701014 chip=0x163a14e4 rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme II BCM5709S Gigabit Ethernet' > class = network > subclass = ethernet > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 03[50] = VPD > cap 05[58] = MSI supports 16 messages, 64 bit > cap 11[a0] = MSI-X supports 9 messages in map 0x10 > cap 10[ac] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > bce1@pci0:16:0:1: class=0x020000 card=0x03701014 chip=0x163a14e4 rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme II BCM5709S Gigabit Ethernet' > class = network > subclass = ethernet > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 03[50] = VPD > cap 05[58] = MSI supports 16 messages, 64 bit > cap 11[a0] = MSI-X supports 9 messages in map 0x10 > cap 10[ac] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > > And the relevant parts from devinfo -rv: > > pcib6 pnpinfo vendor=0x8086 device=0x340e subvendor=0x1014 subdevice=0x340e class=0x060400 at slot=7 function=0 handle=\_SB_.PCI0.ETH1 > pci16 > bce0 pnpinfo vendor=0x14e4 device=0x163a subvendor=0x1014 subdevice=0x0370 class=0x020000 at slot=0 function=0 > I/O memory addresses: > 0x92000000-0x93ffffff > bce1 pnpinfo vendor=0x14e4 device=0x163a subvendor=0x1014 subdevice=0x0370 class=0x020000 at slot=0 function=1 > Interrupt request lines: > 260 > I/O memory addresses: > 0x94000000-0x95ffffff > > If you need more information, or want me to test any patches, > please let me know. > Ok, it seems brgphy(4) does not know the PHY. Let's see what PHY you have. Please apply attached patch and let me know the output of the patch. It will show PHYID1 and PHYID2 value. --QTprm0S8XgL7H0Dt Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bce.phyid.diff" Index: sys/dev/bce/if_bce.c =================================================================== --- sys/dev/bce/if_bce.c (revision 202586) +++ sys/dev/bce/if_bce.c (working copy) @@ -1095,6 +1095,12 @@ bce_ifmedia_sts)) { BCE_PRINTF("%s(%d): No PHY found on child MII bus!\n", __FILE__, __LINE__); +#if 1 + printf("PHYID1: 0x%04x\n", bce_miibus_read_reg(dev, + sc->bce_phy_addr, MII_PHYIDR1)); + printf("PHYID2: 0x%04x\n", bce_miibus_read_reg(dev, + sc->bce_phy_addr, MII_PHYIDR2)); +#endif rc = ENXIO; goto bce_attach_fail; } --QTprm0S8XgL7H0Dt-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 20:29:26 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33F7A106568D for ; Mon, 18 Jan 2010 20:29:26 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id BA98F8FC1C for ; Mon, 18 Jan 2010 20:29:25 +0000 (UTC) Received: (qmail 32627 invoked by uid 399); 18 Jan 2010 20:29:25 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Jan 2010 20:29:25 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B54C4A4.3030108@FreeBSD.org> Date: Mon, 18 Jan 2010 12:29:24 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100114 Thunderbird/3.0 MIME-Version: 1.0 To: Ed Schouten References: <20100113194254.GR64905@hoeg.nl> In-Reply-To: <20100113194254.GR64905@hoeg.nl> X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:29:26 -0000 Out of curiosity, was there ever an experimental pointyhat run done for these changes? If there was not one previously, can we do one ASAP? Doug From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 20:30:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A711C1065757 for ; Mon, 18 Jan 2010 20:30:02 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 543348FC13 for ; Mon, 18 Jan 2010 20:30:02 +0000 (UTC) Received: by qyk4 with SMTP id 4so1955599qyk.7 for ; Mon, 18 Jan 2010 12:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=kPmTl5H+cRWWsDMWyu+0ZObu7SuUTzwCtcr1RBOALgc=; b=IOuTKbTw0EeOC73EBQCEfmbM7VjQ+fxL8WQER0Beyjizw/BjhKRSEE7KN4TSGSjvwA PU1ievfv/kxo9j40v3X5tnJDvwRBgy881kBnrZk33A0Ymgvds1l07yhrGh+cjI6WjmLJ dykmcXfzhqXf6fbh7FAAhuyihmzyUK6Zkf6YI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=m8g9fxlcivzYZIjmgIRyo7hQZwSiG4udLxQj9ieOetVqdibM9TQiJ/Qaz/oTy37seX u7627uaXyuGO2UfOrDB3JFmva9IRWbg7sH1Rj3CgLCmin2QVsgyH3tTrKDz8daVy3TRL K036JX/UPvPmP6ZRraJdTJUEIL77WamW45imE= Received: by 10.229.68.11 with SMTP id t11mr2483558qci.25.1263846601075; Mon, 18 Jan 2010 12:30:01 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 22sm5410076qyk.6.2010.01.18.12.29.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 Jan 2010 12:29:59 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 18 Jan 2010 12:29:55 -0800 From: Pyun YongHyeon Date: Mon, 18 Jan 2010 12:29:55 -0800 To: Oliver Fromme Message-ID: <20100118202955.GC1336@michelle.cdnetworks.com> References: <20100114191738.GZ1228@michelle.cdnetworks.com> <201001182019.o0IKJ1Vn004404@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001182019.o0IKJ1Vn004404@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.ORG Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:30:02 -0000 On Mon, Jan 18, 2010 at 09:19:01PM +0100, Oliver Fromme wrote: > Pyun YongHyeon wrote: > > Done(r202293, r202294). > > By the way, I think this probably fixes PR kern/122551, > so the PR can be closed after the MFC. > Thanks, I'll take care of that. From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 20:52:28 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC373106566C; Mon, 18 Jan 2010 20:52:28 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB4D8FC12; Mon, 18 Jan 2010 20:52:28 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 3667E1CC11; Mon, 18 Jan 2010 21:52:27 +0100 (CET) Date: Mon, 18 Jan 2010 21:52:27 +0100 From: Erwin Lansing To: Doug Barton Message-ID: <20100118205226.GO23919@droso.net> References: <20100113194254.GR64905@hoeg.nl> <4B54C4A4.3030108@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aSOv3uy5xJSQbCk1" Content-Disposition: inline In-Reply-To: <4B54C4A4.3030108@FreeBSD.org> X-Operating-System: FreeBSD/i386 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ports@FreeBSD.org, Ed Schouten , current@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:52:28 -0000 --aSOv3uy5xJSQbCk1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 18, 2010 at 12:29:24PM -0800, Doug Barton wrote: > Out of curiosity, was there ever an experimental pointyhat run done for > these changes? If there was not one previously, can we do one ASAP? >=20 Already started. -erwin --=20 Erwin Lansing http://droso.org Prediction is very difficult especially about the future erwin@FreeBSD.org --aSOv3uy5xJSQbCk1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFLVMoKqy9aWxUlaZARAoxjAJ4s5raVYZYup8DiCWoGXyWMM5CylgCgszff XOPL6LiftVwE7eWWoyLCWI8= =exQn -----END PGP SIGNATURE----- --aSOv3uy5xJSQbCk1-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 20:53:21 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AAA4106568D for ; Mon, 18 Jan 2010 20:53:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8B60D8FC13 for ; Mon, 18 Jan 2010 20:53:20 +0000 (UTC) Received: (qmail 5015 invoked by uid 399); 18 Jan 2010 20:53:19 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Jan 2010 20:53:19 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B54CA3E.8020606@FreeBSD.org> Date: Mon, 18 Jan 2010 12:53:18 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100114 Thunderbird/3.0 MIME-Version: 1.0 To: Erwin Lansing References: <20100113194254.GR64905@hoeg.nl> <4B54C4A4.3030108@FreeBSD.org> <20100118205226.GO23919@droso.net> In-Reply-To: <20100118205226.GO23919@droso.net> X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, Ed Schouten , current@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:53:21 -0000 On 01/18/10 12:52, Erwin Lansing wrote: > On Mon, Jan 18, 2010 at 12:29:24PM -0800, Doug Barton wrote: >> Out of curiosity, was there ever an experimental pointyhat run done for >> these changes? If there was not one previously, can we do one ASAP? >> > Already started. Awesome, you guys rock! :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 22:02:43 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 979521065672 for ; Mon, 18 Jan 2010 22:02:43 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 422E08FC15 for ; Mon, 18 Jan 2010 22:02:43 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 069B65AC5C; Mon, 18 Jan 2010 22:40:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 021335AC42; Mon, 18 Jan 2010 22:40:06 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CDB155CDCC; Mon, 18 Jan 2010 22:40:05 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.1) with ESMTP id 2010011822400432-109441 ; Mon, 18 Jan 2010 22:40:04 +0100 Received: by wep4035 (sSMTP sendmail emulation); Mon, 18 Jan 2010 22:40:04 +0100 Date: Mon, 18 Jan 2010 22:40:04 +0100 From: Alexey Shuvaev To: Ed Schouten Message-ID: <20100118214004.GA5240@wep4035.physik.uni-wuerzburg.de> References: <20100113194254.GR64905@hoeg.nl> MIME-Version: 1.0 In-Reply-To: <20100113194254.GR64905@hoeg.nl> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.20 (2009-06-14) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.1|September 28, 2009) at 01/18/2010 10:40:05 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.1|September 28, 2009) at 01/18/2010 10:40:05 PM, Serialize complete at 01/18/2010 10:40:05 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: current@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 22:02:43 -0000 On Wed, Jan 13, 2010 at 08:42:54PM +0100, Ed Schouten wrote: > Hello everyone, > > I just made various commits to FreeBSD HEAD to remove our old user > accounting database interface (see utmp(5)) and replace it by the POSIX > standardized utmpx interface (see getutxent(3)). This means we just got > rid of some annoyances that are as old as the FreeBSD project itself: > > - Hostnames were originally restricted to 16 bytes, which is way too > short for your average hostname generated by your ISP, but also for > IPv6 addresses, which are at most 32 + 7 = 39 characters. > > - No support for login sessions not related to TTYs, like ppp(8), > ftpd(8) sessions. > > [snip] > > Be sure to give it a try and report any issues. Thanks! > Great work, thanks! The system is a little bit old already: ~> uname -a FreeBSD wep4035 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r202285: Thu Jan 14 19:04:21 CET 2010 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 but nevetheless, looks like ftpd does not logout (or whatever): ~> ac -p ftp 3305.13 root 14.92 lexx 63.20 total 3383.25 Standard ftpd from base: 2011 ?? Is 0:00.03 /usr/libexec/ftpd -D -Am Two shots of w(1), during ftp session from localhost: [snip] ftp - wep4059.physik.uni-wuerz 11:32AM 10:51 - ftp - wep4059.physik.uni-wuerz 11:40AM 10:43 - ftp - wep4018.physik.uni-wuerz 1:04PM 9:20 - ftp - wep4059.physik.uni-wuerz 1:19PM 9:05 - ftp - wep4016.physik.uni-wuerz 4:36PM 5:48 - lexx v2 - 7:49PM 2:34 xinit lexx pts/0 :0.0 7:50PM - ftp ftp@localhost ftp - localhost 7:51PM 2:33 - ftp - localhost 7:52PM 2:31 - ftp - localhost 10:24PM - - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ftp - wep4019.physik.uni-wuerz 7:01PM 3:22 - lexx pts/1 :0.0 8:03PM 34 ssh wep4059 lexx pts/2 :0.0 8:19PM - w and after closing it: [snip] ftp - wep4059.physik.uni-wuerz 11:32AM 10:52 - ftp - wep4059.physik.uni-wuerz 11:40AM 10:44 - ftp - wep4018.physik.uni-wuerz 1:04PM 9:21 - ftp - wep4059.physik.uni-wuerz 1:19PM 9:06 - ftp - wep4016.physik.uni-wuerz 4:36PM 5:49 - lexx v2 - 7:49PM 2:35 xinit lexx pts/0 :0.0 7:50PM - tcsh ftp - localhost 7:51PM 2:34 - ftp - localhost 7:52PM 2:32 - ftp - localhost 10:24PM 1 - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ftp - wep4019.physik.uni-wuerz 7:01PM 3:23 - lexx pts/1 :0.0 8:03PM 35 ssh wep4059 lexx pts/2 :0.0 8:19PM - w lexx pts/3 :0.0 10:25PM - vi after ftp - wep4059.physik.uni-wuerz 10:25PM - - Sorry if it is already fixed, Alexey. From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 22:18:21 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B094B1065692 for ; Mon, 18 Jan 2010 22:18:21 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 742658FC0A for ; Mon, 18 Jan 2010 22:18:21 +0000 (UTC) Received: from gloom.rink.nu (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 4DD9A6D440; Mon, 18 Jan 2010 23:18:45 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by gloom.rink.nu (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aybNuYxrFUgR; Mon, 18 Jan 2010 23:18:43 +0100 (CET) Received: by mx1.rink.nu (Postfix, from userid 1000) id 6EBF06D43F; Mon, 18 Jan 2010 23:18:43 +0100 (CET) Date: Mon, 18 Jan 2010 23:18:43 +0100 From: Rink Springer To: Andrew Milton Message-ID: <20100118221843.GB65074@rink.nu> References: <20100118175033.7ba10de0@ernst.jennejohn.org> <20100118165537.GG81608@camelot.theinternet.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100118165537.GG81608@camelot.theinternet.com.au> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Jeff Roberson , current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 22:18:21 -0000 On Tue, Jan 19, 2010 at 03:55:37AM +1100, Andrew Milton wrote: > +-------[ Gary Jennejohn ]---------------------- > | On Fri, 8 Jan 2010 14:56:45 -1000 (HST) > | Jeff Roberson wrote: > | > | > I have been augmenting softupdates with a small journal that will be processed > | > in lieu of fsck in the event of a crash. I have written some about this > | > project here: http://jeffr_tech.livejournal.com/ > | > > | > | For some reason I can't access this location. Hmm, firefox doesn't seem to like > | the '_'. > > Because DNS hostnames can't contain underscores... ? That is false, they can (in fact, SVR records depend on this). However, Jeff's blog is at http://jeffr-tech.livejournal.com/; his username appears to be 'jeffr_tech'. Regards, -- Rink P.W. Springer - http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 23:04:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D0981065676 for ; Mon, 18 Jan 2010 23:04:58 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0566F8FC16 for ; Mon, 18 Jan 2010 23:04:57 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KWG005E4TG7XF50@asmtp027.mac.com>; Mon, 18 Jan 2010 15:04:56 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1001180220 From: Chuck Swiger In-reply-to: <20100118221843.GB65074@rink.nu> Date: Mon, 18 Jan 2010 15:04:55 -0800 Message-id: References: <20100118175033.7ba10de0@ernst.jennejohn.org> <20100118165537.GG81608@camelot.theinternet.com.au> <20100118221843.GB65074@rink.nu> To: Rink Springer X-Mailer: Apple Mail (2.1077) Cc: Jeff Roberson , current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 23:04:58 -0000 On Jan 18, 2010, at 2:18 PM, Rink Springer wrote: >> Because DNS hostnames can't contain underscores... ? > > That is false, they can (in fact, SVR records depend on this). However, > Jeff's blog is at http://jeffr-tech.livejournal.com/; his username > appears to be 'jeffr_tech'. Underscores appear in SRV records for the explicit purpose of not conflicting with any valid hostname: The format of the SRV RR Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target Service The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. ...from http://www.ietf.org/rfc/rfc2782.txt. See http://www.ietf.org/rfc/rfc952.txt 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). ...which was slightly modified by http://www.ietf.org/rfc/rfc1123.txt 2.1 Host Names and Numbers The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 01:30:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E1691065672 for ; Tue, 19 Jan 2010 01:30:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id C0CDD8FC1A for ; Tue, 19 Jan 2010 01:30:47 +0000 (UTC) Received: (qmail 25309 invoked by uid 399); 19 Jan 2010 01:30:47 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Jan 2010 01:30:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B550B46.90502@FreeBSD.org> Date: Mon, 18 Jan 2010 17:30:46 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100114 Thunderbird/3.0 MIME-Version: 1.0 To: Chuck Swiger References: <20100118175033.7ba10de0@ernst.jennejohn.org> <20100118165537.GG81608@camelot.theinternet.com.au> <20100118221843.GB65074@rink.nu> In-Reply-To: X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rink Springer , Jeff Roberson , current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 01:30:48 -0000 On 01/18/10 15:04, Chuck Swiger wrote: > Underscores appear in SRV records for the explicit purpose of not conflicting with any valid hostname: Chuck did a fine job so I'll only add that rather than debating the fine points of "What is a hostname?" on this list, let's just say that "If you want maximum compatibility with the rest of the Internet don't put underscores in things that look like hostnames and are meant to be seen by humans." Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 01:39:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 794F41065670; Tue, 19 Jan 2010 01:39:12 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0993C8FC12; Tue, 19 Jan 2010 01:39:11 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id o0J1dAja018445; Tue, 19 Jan 2010 10:39:10 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id o0J1d9S26194; Tue, 19 Jan 2010 10:39:09 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla1) id o0J1dAm1026843; Tue, 19 Jan 2010 10:39:10 +0900 (JST) Received: from localhost by somla1.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0J1d3MD026582; Tue, 19 Jan 2010 10:39:03 +0900 (JST) Date: Tue, 19 Jan 2010 10:38:58 +0900 (JST) Message-Id: <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org From: Kohji Okuno In-Reply-To: <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com> References: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: okuno.kohji@jp.panasonic.com, freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 01:39:12 -0000 Hello, Attilio, I think setpriority() can set priority to sleeping threads. Is it really safe? Thank you, Kohji Okuno > 2010/1/18 Kohji Okuno : >> Hello, >> >> Thank you, Attilio. >> I checked your patch. I think that your patch is better. >> I tested the patch quickly, and I think it's OK. >> # This probrem does not occur easily :-< >> >> >> What do you think about maybe_resched()? >> I have never experienced about maybe_resched(), but I think that the= >> race condition may occur. >> >> <> >> sched_4bsd.c: =A0 =A0 maybe_resched() >> sched_4bsd.c: =A0 =A0 resetpriority_thread() >> sched_4bsd.c: =A0 =A0 sched_nice() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= get thread_lock(td) >> kern_resource.c: =A0donice() >> kern_resource.c: =A0setpriority() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ge= t PROC_LOCK() >> >> static void >> maybe_resched(struct thread *td) >> { >> =A0 =A0 =A0 =A0THREAD_LOCK_ASSERT(td, MA_OWNED); >> =A0 =A0 =A0 =A0if (td->td_priority < curthread->td_priority) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0curthread->td_flags |=3D TDF_NEEDRESC= HED; >> } >> >> I think, when td->td_lock is not &sched_lock, curthread->td_lock is >> not locked in maybe_resched(). > = > I didn't look closely to the maybe_resched() callers but I think it i= s > ok. The thread_lock() function works in a way that the callers don't > need to know which container lock is present in a particular moment, > there is always a guarantee that the contenders will spin if the lock= > on the struct can't be held. > In the case you outlined something very particular was happening. > Basically, we get &sched_lock but sched_lock was not the lock present= > on td_lock. That means all the other paths willing to access to > td_lock for that thread (via thread_lock()) were allowed to do that > even if we wanted to keep the critical path closed. > = > Attilio > = > = > -- = > Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 01:43:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D1851065670; Tue, 19 Jan 2010 01:43:55 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 39BE68FC14; Tue, 19 Jan 2010 01:43:54 +0000 (UTC) Received: by yxe1 with SMTP id 1so34303yxe.3 for ; Mon, 18 Jan 2010 17:43:54 -0800 (PST) Received: by 10.101.134.39 with SMTP id l39mr10685505ann.130.1263865434376; Mon, 18 Jan 2010 17:43:54 -0800 (PST) Received: from ?10.0.1.198? (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id 15sm2944405gxk.12.2010.01.18.17.43.52 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Jan 2010 17:43:53 -0800 (PST) Date: Mon, 18 Jan 2010 15:47:33 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Kohji Okuno In-Reply-To: <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> Message-ID: References: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com> <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-1844873231-1263865655=:1027" Cc: attilio@freebsd.org, freebsd-current@freebsd.org Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 01:43:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2547152148-1844873231-1263865655=:1027 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 19 Jan 2010, Kohji Okuno wrote: > Hello, Attilio, > > I think setpriority() can set priority to sleeping threads. > Is it really safe? I agree, in this code path maybe_resched is not properly locking curthread. curthread will be sched_lock and the sleeping thread will be a sleepq lock. I believe that since &sched_lock is ordered after container locks it would be sufficient to compare the two td_lock pointers and acquire sched_lock if they are not equal. Someone should look at other maybe_resched callers or add an assert that curthread->td_lock is always &sched_lock in this function. Thanks, Jeff > > Thank you, > Kohji Okuno > >> 2010/1/18 Kohji Okuno : >>> Hello, >>> >>> Thank you, Attilio. >>> I checked your patch. I think that your patch is better. >>> I tested the patch quickly, and I think it's OK. >>> # This probrem does not occur easily :-< >>> >>> >>> What do you think about maybe_resched()? >>> I have never experienced about maybe_resched(), but I think that the >>> race condition may occur. >>> >>> <> >>> sched_4bsd.c:     maybe_resched() >>> sched_4bsd.c:     resetpriority_thread() >>> sched_4bsd.c:     sched_nice()                  get thread_lock(td) >>> kern_resource.c:  donice() >>> kern_resource.c:  setpriority()                 get PROC_LOCK() >>> >>> static void >>> maybe_resched(struct thread *td) >>> { >>>        THREAD_LOCK_ASSERT(td, MA_OWNED); >>>        if (td->td_priority < curthread->td_priority) >>>                curthread->td_flags |= TDF_NEEDRESCHED; >>> } >>> >>> I think, when td->td_lock is not &sched_lock, curthread->td_lock is >>> not locked in maybe_resched(). >> >> I didn't look closely to the maybe_resched() callers but I think it is >> ok. The thread_lock() function works in a way that the callers don't >> need to know which container lock is present in a particular moment, >> there is always a guarantee that the contenders will spin if the lock >> on the struct can't be held. >> In the case you outlined something very particular was happening. >> Basically, we get &sched_lock but sched_lock was not the lock present >> on td_lock. That means all the other paths willing to access to >> td_lock for that thread (via thread_lock()) were allowed to do that >> even if we wanted to keep the critical path closed. >> >> Attilio >> >> >> -- >> Peace can only be achieved by understanding - A. Einstein > --2547152148-1844873231-1263865655=:1027-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 04:13:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE42C106566B; Tue, 19 Jan 2010 04:13:19 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8037E8FC21; Tue, 19 Jan 2010 04:13:19 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0J4AeH2022019; Tue, 19 Jan 2010 14:40:40 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Tue, 19 Jan 2010 14:43:18 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 14:43:17 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 12:13:16 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0J47gRv039632; Tue, 19 Jan 2010 12:07:42 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0J47gg9039631; Tue, 19 Jan 2010 12:07:42 +0800 (WST) (envelope-from wilkinsa) Date: Tue, 19 Jan 2010 12:07:42 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20100119040742.GM35418@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, marcus@FreeBSD.org References: <20100113194254.GR64905@hoeg.nl> <4B4F1DF8.1040603@icyb.net.ua> <20100114134151.GA98196@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100114134151.GA98196@stlux503.dsto.defence.gov.au> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 19 Jan 2010 04:13:16.0522 (UTC) FILETIME=[B9B2BCA0:01CA98BD] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17140.004 X-TM-AS-Result: No-2.466400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: marcus@freebsd.org Subject: Re: HEADS UP: gone. All welcome . [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 04:13:20 -0000 0n Thu, Jan 14, 2010 at 09:41:51PM +0800, Wilkinson, Alex wrote: > 0n Thu, Jan 14, 2010 at 03:36:56PM +0200, Andriy Gapon wrote: > > >on 13/01/2010 21:42 Ed Schouten said the following: > >> Hello everyone, > >> > >> I just made various commits to FreeBSD HEAD to remove our old user > >> accounting database interface (see utmp(5)) and replace it by the POSIX > >> standardized utmpx interface (see getutxent(3)). some more port breakage /usr/ports/net-im/libpurple: /usr/include/utmp.h:2:2: error: #error " has been replaced by " gmake[5]: *** [libzephyr_la-Zinternal.lo] Error 1 gmake[5]: Leaving directory `/usr/ports/net-im/libpurple/work/pidgin-2.6.5/libpurple/protocols/zephyr' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/usr/ports/net-im/libpurple/work/pidgin-2.6.5/libpurple/protocols' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/net-im/libpurple/work/pidgin-2.6.5/libpurple' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/net-im/libpurple/work/pidgin-2.6.5/libpurple' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/net-im/libpurple/work/pidgin-2.6.5' gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/net-im/libpurple. *** Error code 1 Stop in /usr/ports/net-im/libpurple. *** Error code 1 Stop in /usr/ports/net-im/pidgin-sipe. Exit 1 -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 04:34:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F5BF1065670; Tue, 19 Jan 2010 04:34:59 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id D71838FC1A; Tue, 19 Jan 2010 04:34:58 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id o0J4YvvF025133; Tue, 19 Jan 2010 13:34:57 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id o0J4Yxg12598; Tue, 19 Jan 2010 13:34:59 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla2) id o0J4YvOL009134; Tue, 19 Jan 2010 13:34:57 +0900 (JST) Received: from localhost by somla2.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0J4Yulk009092; Tue, 19 Jan 2010 13:34:56 +0900 (JST) Date: Tue, 19 Jan 2010 13:34:55 +0900 (JST) Message-Id: <20100119.133455.123339447290605132.okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org, jroberson@jroberson.net From: Kohji Okuno In-Reply-To: <20100118.160456.519459540419521301.okuno.kohji@jp.panasonic.com> References: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> <20100118.160456.519459540419521301.okuno.kohji@jp.panasonic.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 04:34:59 -0000 Hello, >>> I'm not sure if this patch breaks any invariant, if you may test I >>> would appreciate: >>> http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff >>> >>> Reviews and comments are appreciated. >>> BTW, nice catch. Why did you introduce "td->td_lock" to the kernel? I think that this reason is an improvment of the performance by avoiding the competition of the only lock. If it is a correct anser, a sleeping thread shoud not set &sched_lock to td->td_lock, I think. Could you comment, please? Thank you, Kohji Okuno > Hello, > > I have a question. > > The sleeping thread (on turnstile or on sleepque) can set sched_lock > to td_lock, kernel are allowed? > > Best regards, > Kohji Okuno. > >> Hello, >> >> Thank you, Attilio. >> I checked your patch. I think that your patch is better. >> I tested the patch quickly, and I think it's OK. >> # This probrem does not occur easily :-< >> >> >> What do you think about maybe_resched()? >> I have never experienced about maybe_resched(), but I think that the >> race condition may occur. >> >> <> >> sched_4bsd.c: maybe_resched() >> sched_4bsd.c: resetpriority_thread() >> sched_4bsd.c: sched_nice() get thread_lock(td) >> kern_resource.c: donice() >> kern_resource.c: setpriority() get PROC_LOCK() >> >> static void >> maybe_resched(struct thread *td) >> { >> THREAD_LOCK_ASSERT(td, MA_OWNED); >> if (td->td_priority < curthread->td_priority) >> curthread->td_flags |= TDF_NEEDRESCHED; >> } >> >> I think, when td->td_lock is not &sched_lock, curthread->td_lock is >> not locked in maybe_resched(). >> >> Best regards, >> Kohji Okuno. >> >> From: Attilio Rao >> Subject: Re: Bug about sched_4bsd? >> Date: Mon, 18 Jan 2010 03:58:41 +0100 >> Message-ID: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> >> >>> 2010/1/17 Kohji Okuno : >>>> Hello, >>>> >>>> Could you check sched_4bsd.patch, please? >>> >>> I think, instead, that what needs to happen is to have sched_switch() >>> to do a lock handover from sleepq/turnstile spinlock to schedlock. >>> That way, if threads are willing to contest on td_lock they will be >>> still inhibited. >>> I'm not sure if this patch breaks any invariant, if you may test I >>> would appreciate: >>> http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff >>> >>> Reviews and comments are appreciated. >>> BTW, nice catch. >>> >>> Attilio >>> >>> >>> -- >>> Peace can only be achieved by understanding - A. Einstein >>> _______________________________________________ >>> 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" >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 06:30:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6098B1065679 for ; Tue, 19 Jan 2010 06:30:04 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 136208FC0A for ; Tue, 19 Jan 2010 06:30:03 +0000 (UTC) Received: from [195.93.241.18] (port=47645 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NX7bG-000Dvd-1u for freebsd-current@freebsd.org; Tue, 19 Jan 2010 09:30:02 +0300 Message-ID: <4B555169.3050801@lissyara.su> Date: Tue, 19 Jan 2010 09:30:01 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: ps -axo user,%cpu,%mem - most processes using 0% of memory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 06:30:04 -0000 Hi! Modern computers have a large amount of memory. But, in ps(1) source I see: (void)printf("%*.1f", v->width, getpcpu(k)); (void)printf("%*.1f", v->width, getpmem(k)); 0.1% - it very big. for 8Gb ram it = 8mb Many of the processes is less than this number. I attach patch to correct this srv2# diff -Nru bin/ps/print.c ~lissyara/print.c --- bin/ps/print.c 2009-09-07 13:51:23.000000000 +0400 +++ /usr/home/lissyara/print.c 2010-01-19 09:17:25.000000000 +0300 @@ -629,7 +629,7 @@ VAR *v; v = ve->var; - (void)printf("%*.1f", v->width, getpcpu(k)); + (void)printf("%*.2f", v->width, getpcpu(k)); } static double @@ -657,7 +657,7 @@ VAR *v; v = ve->var; - (void)printf("%*.1f", v->width, getpmem(k)); + (void)printf("%*.2f", v->width, getpmem(k)); } void srv2# From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 07:20:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FC26106568B for ; Tue, 19 Jan 2010 07:20:54 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id A29EF8FC13 for ; Tue, 19 Jan 2010 07:20:53 +0000 (UTC) Received: by ewy26 with SMTP id 26so644110ewy.3 for ; Mon, 18 Jan 2010 23:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=0jiH8/jKOaSdVL9ls8Tdctwg/hpkER6fU/JqzIv7Q2s=; b=MdZ9chLlaBMAu4uyvVPEZOY8nGqB9jUC3YoXcAznc56BCflZ/aIOE4xE944HKD/MF3 RazNs+b7BuPvVsXY9X1h0NgtIkWEkSClMLMfq0FEbFOP9oio9GydMBr9teVccmTt7DSO anPAWFsnPdd7d2Fn7f5RY8dPPcGq2vhh4uhSs= 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=kq880tg8RzrMUEaQoobbp3LwffRWNKlvoZOkzLq8/D36lD7xQPK/RwtTyfrHZnxg6N ozlm9amlNulG1KDcNH/SvI+6MPguyAkqScVHWteAhz5+TF3wUFs1LoFf+mOH36Iqiqc6 DmDfeUilLCVWmkLWoFC4i9vdwUGzJ6qCrF5sA= MIME-Version: 1.0 Received: by 10.213.109.156 with SMTP id j28mr4964509ebp.79.1263885652387; Mon, 18 Jan 2010 23:20:52 -0800 (PST) In-Reply-To: <20100119040742.GM35418@stlux503.dsto.defence.gov.au> References: <20100113194254.GR64905@hoeg.nl> <4B4F1DF8.1040603@icyb.net.ua> <20100114134151.GA98196@stlux503.dsto.defence.gov.au> <20100119040742.GM35418@stlux503.dsto.defence.gov.au> Date: Tue, 19 Jan 2010 02:20:52 -0500 Message-ID: <47d0403c1001182320m1b117a71waa38d354e6e4ac49@mail.gmail.com> From: Ben Kaduk To: freebsd-current@freebsd.org, marcus@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: HEADS UP: gone. All welcome . [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 07:20:54 -0000 On Mon, Jan 18, 2010 at 11:07 PM, Wilkinson, Alex wrote: > > =A0 =A00n Thu, Jan 14, 2010 at 09:41:51PM +0800, Wilkinson, Alex wrote: > > =A0 =A0> =A0 =A00n Thu, Jan 14, 2010 at 03:36:56PM +0200, Andriy Gapon wr= ote: > =A0 =A0> > =A0 =A0> =A0 =A0>on 13/01/2010 21:42 Ed Schouten said the following: > =A0 =A0> =A0 =A0>> Hello everyone, > =A0 =A0> =A0 =A0>> > =A0 =A0> =A0 =A0>> I just made various commits to FreeBSD HEAD to remove = our old user > =A0 =A0> =A0 =A0>> accounting database interface (see utmp(5)) and replac= e it by the POSIX > =A0 =A0> =A0 =A0>> standardized utmpx interface (see getutxent(3)). > > some more port breakage /usr/ports/net-im/libpurple: > > =A0 /usr/include/utmp.h:2:2: error: #error " has been replaced by= " > =A0 gmake[5]: *** [libzephyr_la-Zinternal.lo] Error 1 > =A0 gmake[5]: Leaving directory `/usr/ports/net-im/libpurple/work/pidgin-= 2.6.5/libpurple/protocols/zephyr' The zephyr support in libpurple is incredibly ancient, and doesn't really work very well. I have a port prepared that packages libzephyr and the standard zephyr clients directly, in ports/141790 (though I have a couple of tweaks to the submitted version in my queue). I'd almost say it would be worth just ripping the zephyr support out of the libpurple port. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 07:51:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F319106566B; Tue, 19 Jan 2010 07:51:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BE1198FC16; Tue, 19 Jan 2010 07:51:08 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E18E773106; Tue, 19 Jan 2010 08:59:25 +0100 (CET) Date: Tue, 19 Jan 2010 08:59:25 +0100 From: Luigi Rizzo To: Hajimu UMEMOTO Message-ID: <20100119075925.GA42257@onelab2.iet.unipi.it> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> <20100110185232.GA27907@onelab2.iet.unipi.it> <20100117110443.GA58434@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100117110443.GA58434@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, David Horn , freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 07:51:09 -0000 On Sun, Jan 17, 2010 at 12:04:43PM +0100, Luigi Rizzo wrote: > On Sun, Jan 17, 2010 at 05:42:58PM +0900, Hajimu UMEMOTO wrote: > > Hi, > > > > >>>>> On Sun, 10 Jan 2010 19:52:32 +0100 > > >>>>> Luigi Rizzo said: > > > > rizzo> We only need one 'me' option that matches v4 and v6, because the > > rizzo> other two can be implemented as 'ip4 me' and 'ip6 me' at no extra > > rizzo> cost (the code for 'me' only scans the list corresponding to the > > rizzo> actual address family of the packet). I would actually vote for > > rizzo> removing the 'me6' microinstruction from the kernel, and implement > > rizzo> it in /sbin/ipfw by generating 'ip6 me'. now that i think of it -- if we have an "or block" ie something like ... { opt1 OR me6 OR .. } the replacement of 'me6' with 'ip6 me' will not work as only one microinstruction is allowed in an or block. To fix this we would need some more radical change in expression parsing, both in userland and in the kernel. I guess one way to handle this is to signal a syntax error if we find a 'me6' or 'me4' within an OR block (can be done during the rewriting in the loop below, because it is easy to know if we are within a block). cheers luigi > > rizzo> Feel free to commit the change yourself. > > > > Thank you. I've committed 1st patch and 3rd patch. > > I think it is better removing the 'me6' microinstruction from the > > kernel, and implement it in /sbin/ipfw by generating 'ip6 me'. > > However, it seems to me that /sbin/ipfw is not designed to generate > > two microinstructions (ip6 me) per one 'me6' easily. > > Indeed, it might be useful to insert, at the beginning of function > ipfw_add, a small preprocessing step that translates all instances > of 'me6' into 'ip6 me' and then proceed with the current parsing. > While doing that, one could even NULL-terminate the array av[] so > we don't need to carry both ac and av throught the code. > > Something like > > new_av = safe_calloc(ac*2 + 1, sizeof(char *); > for (src = dst = 0; src < ac; src++) { > if (!strcmp(av[src], "me6")) { > new_av[dst++] = "ip6"; > new_av[dst++] = "me"; > } else { > new_av[dst++] = av[src]; > } > } > new_av[dst++] = NULL; > av = new_av; > ac = dst; > > should do the job. Replacing the tests for 'ac > 0' and ac>1 > is straightforward though it touches a large number of lines > (most of the usage is in the 'NEED1' macro. > > cheers > luigi > > Sincerely, > > > > -- > > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > > ume@mahoroba.org ume@{,jp.}FreeBSD.org > > http://www.imasy.org/~ume/ > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 09:17:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 839711065670; Tue, 19 Jan 2010 09:17:57 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0C0158FC0A; Tue, 19 Jan 2010 09:17:56 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0J9FHUC017438; Tue, 19 Jan 2010 19:45:17 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Tue, 19 Jan 2010 19:47:55 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 19:47:55 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 17:17:52 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0J9CInH041111; Tue, 19 Jan 2010 17:12:18 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0J9CHSa041110; Tue, 19 Jan 2010 17:12:17 +0800 (WST) (envelope-from wilkinsa) Date: Tue, 19 Jan 2010 17:12:17 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Message-ID: <20100119091217.GR39820@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org References: <201001101437.37269.hselasky@c2i.net> <20100114072753.GJ80705@stlux503.dsto.defence.gov.au> <201001140924.47454.hselasky@c2i.net> <20100114084831.GL80705@stlux503.dsto.defence.gov.au> <20100114090329.GH63408@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100114090329.GH63408@citylink.fud.org.nz> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 19 Jan 2010 09:17:52.0282 (UTC) FILETIME=[46E667A0:01CA98E8] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17140.005 X-TM-AS-Result: No--6.468800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:17:57 -0000 0n Thu, Jan 14, 2010 at 10:03:29PM +1300, Andrew Thompson wrote: >On Thu, Jan 14, 2010 at 04:48:31PM +0800, Wilkinson, Alex wrote: >> >> 0n Thu, Jan 14, 2010 at 09:24:47AM +0100, Hans Petter Selasky wrote: >> >> >I think Andrew made a fixed port which you can test. >> >> Can you please point me in the direction to this ? > >I'l update the tarball tomorrow and send it out. Got these errors: [FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010] ===> Building for webcamd-0.1.0 Warning: Object directory not changed from original /usr/ports/multimedia/webcamd/work/webcamd-0.1.0 cc -O2 -pipe -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/drivers/media/video/gspca -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/include -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0 -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/dummy -DCONFIG_VIDEO_V4L1_COMPAT -DHAVE_WEBCAMD -include webcamd_global.h -O2 -Wall -Wno-pointer-sign -fvisibility=hidden -std=gnu99 -fstack-protector -c webcamd.c webcamd.c:37:23: error: video4bsd.h: No such file or directory webcamd.c:55: error: 'V4B_ALLOC_UNIT_MAX' undeclared here (not in a function) webcamd.c: In function 'main': webcamd.c:126: error: storage size of 'cmd' isn't known webcamd.c:176: error: 'V4B_DEVICES_MAX' undeclared (first use in this function) webcamd.c:176: error: (Each undeclared identifier is reported only once webcamd.c:176: error: for each function it appears in.) webcamd.c:206: error: 'V4B_IOCTL_GET_COMMAND' undeclared (first use in this function) webcamd.c:212: error: 'V4B_CMD_OPEN' undeclared (first use in this function) webcamd.c:223: error: 'V4B_IOCTL_SYNC_COMMAND' undeclared (first use in this function) webcamd.c:226: error: 'V4B_CMD_CLOSE' undeclared (first use in this function) webcamd.c:236: error: 'V4B_CMD_READ' undeclared (first use in this function) webcamd.c:244: error: 'V4B_CMD_WRITE' undeclared (first use in this function) webcamd.c:252: error: 'V4B_CMD_IOCTL' undeclared (first use in this function) webcamd.c:264: error: 'V4B_CMD_MMAP' undeclared (first use in this function) webcamd.c:126: warning: unused variable 'cmd' webcamd.c: In function 'copy_to_user': webcamd.c:299: error: variable 'cmd' has initializer but incomplete type webcamd.c:300: error: unknown field 'client_ptr' specified in initializer webcamd.c:300: warning: excess elements in struct initializer webcamd.c:300: warning: (near initialization for 'cmd') webcamd.c:301: error: unknown field 'peer_ptr' specified in initializer webcamd.c:301: warning: excess elements in struct initializer webcamd.c:301: warning: (near initialization for 'cmd') webcamd.c:302: error: unknown field 'length' specified in initializer webcamd.c:302: warning: excess elements in struct initializer webcamd.c:302: warning: (near initialization for 'cmd') webcamd.c:299: error: storage size of 'cmd' isn't known webcamd.c:306: error: 'V4B_IOCTL_WRITE_DATA' undeclared (first use in this function) webcamd.c:299: warning: unused variable 'cmd' webcamd.c: In function 'copy_from_user': webcamd.c:315: error: variable 'cmd' has initializer but incomplete type webcamd.c:316: error: unknown field 'client_ptr' specified in initializer webcamd.c:316: warning: excess elements in struct initializer webcamd.c:316: warning: (near initialization for 'cmd') webcamd.c:317: error: unknown field 'peer_ptr' specified in initializer webcamd.c:317: warning: excess elements in struct initializer webcamd.c:317: warning: (near initialization for 'cmd') webcamd.c:318: error: unknown field 'length' specified in initializer webcamd.c:318: warning: excess elements in struct initializer webcamd.c:318: warning: (near initialization for 'cmd') webcamd.c:315: error: storage size of 'cmd' isn't known webcamd.c:322: error: 'V4B_IOCTL_READ_DATA' undeclared (first use in this function) webcamd.c:315: warning: unused variable 'cmd' webcamd.c: In function 'set_mmap': webcamd.c:370: error: variable 'cmd' has initializer but incomplete type webcamd.c:370: warning: excess elements in struct initializer webcamd.c:370: warning: (near initialization for 'cmd') webcamd.c:370: warning: excess elements in struct initializer webcamd.c:370: warning: (near initialization for 'cmd') webcamd.c:370: error: storage size of 'cmd' isn't known webcamd.c:389: error: 'V4B_IOCTL_MAP_MEMORY' undeclared (first use in this function) webcamd.c:370: warning: unused variable 'cmd' webcamd.c: In function 'malloc_vm': webcamd.c:403: error: variable 'cmd' has initializer but incomplete type webcamd.c:403: warning: excess elements in struct initializer webcamd.c:403: warning: (near initialization for 'cmd') webcamd.c:403: warning: excess elements in struct initializer webcamd.c:403: warning: (near initialization for 'cmd') webcamd.c:403: error: storage size of 'cmd' isn't known webcamd.c:428: error: 'V4B_IOCTL_ALLOC_MEMORY' undeclared (first use in this function) webcamd.c:442: error: 'V4B_ALLOC_PAGES_MAX' undeclared (first use in this function) webcamd.c:446: error: 'V4B_IOCTL_FREE_MEMORY' undeclared (first use in this function) webcamd.c:403: warning: unused variable 'cmd' webcamd.c: In function 'free_vm': webcamd.c:466: error: variable 'cmd' has initializer but incomplete type webcamd.c:466: warning: excess elements in struct initializer webcamd.c:466: warning: (near initialization for 'cmd') webcamd.c:466: warning: excess elements in struct initializer webcamd.c:466: warning: (near initialization for 'cmd') webcamd.c:466: error: storage size of 'cmd' isn't known webcamd.c:483: error: 'V4B_IOCTL_FREE_MEMORY' undeclared (first use in this function) webcamd.c:466: warning: unused variable 'cmd' *** Error code 1 Stop in /usr/ports/multimedia/webcamd/work/webcamd-0.1.0. *** Error code 1 Stop in /usr/ports/multimedia/webcamd. Exit 1 -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 09:52:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16F681065701 for ; Tue, 19 Jan 2010 09:52:29 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3708FC1C for ; Tue, 19 Jan 2010 09:52:28 +0000 (UTC) Received: by fxm27 with SMTP id 27so3159729fxm.3 for ; Tue, 19 Jan 2010 01:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=oY5taU1D65AmPO6O8X5waKpGGn2gOxiyp4/1p+IOZJY=; b=c1v7fOJwhPL6yMzGF32zLxLXbblRGXhjOO4EDhDqQMnaOfhUN7/lO+jIec+xcQ/21e 3kbtB1aJoWbIEJcPmccfKMHL0n0i3oFy27f4QlHyEvsgjongR5HbYvZ5mme+MujgpsRi W2cH0pvMPVlVplVCN1tOetxuHJtfXdP9SW+G0= 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=aau3MFXVAo2GIonBrTl+YnxwscsBP2UWTdoRM2W/diWfqbeub1DOUanmfuHjQeY+XK VaAkgket4F2O/u8hfAxIUGMgwj7xKLWgk9U14DzBSEvV/TQu4mYtVJ0tOQROvN9sR4ba X50AHzTPt/08GK/Xg/Ce1peURnyrYMpjjtRik= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.13.209 with SMTP id d17mr8760697faa.100.1263894747532; Tue, 19 Jan 2010 01:52:27 -0800 (PST) In-Reply-To: References: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com> <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> Date: Tue, 19 Jan 2010 10:52:27 +0100 X-Google-Sender-Auth: 74962f5af9d25712 Message-ID: <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com> From: Attilio Rao To: Jeff Roberson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Kohji Okuno Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:52:29 -0000 2010/1/19 Jeff Roberson : > On Tue, 19 Jan 2010, Kohji Okuno wrote: > >> Hello, Attilio, >> >> I think setpriority() can set priority to sleeping threads. >> Is it really safe? > > I agree, in this code path maybe_resched is not properly locking curthrea= d. > =C2=A0curthread will be sched_lock and the sleeping thread will be a slee= pq lock. > =C2=A0I believe that since &sched_lock is ordered after container locks i= t would > be sufficient to compare the two td_lock pointers and acquire sched_lock = if > they are not equal. =C2=A0Someone should look at other maybe_resched call= ers or > add an assert that curthread->td_lock is always &sched_lock in this > function. I'm not sure I understand you well here, but I generally don't agree, if we speak about the current code plus the patch I posted. Without the patch, there is a general problem of maybe_preempt() because sched_switch() will handle TDF_NEEDRESCHED just in racy ways (not ensuring atomicity of td_lock operations for sleeping threads). That's, however, still not specific to maybe_preempt() only. However: * If you make a problem about the callers of maybe_resched() I agree. The callers should assert for sched_lock to be in place. But that is not a general problem of maybe_resched(), it is on the callers ballpark * If you make a problem about the locking itself, the patch IMHO should fix it or there is still something I can't see. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 09:53:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CDB31065697 for ; Tue, 19 Jan 2010 09:53:25 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id C0A9A8FC2C for ; Tue, 19 Jan 2010 09:53:24 +0000 (UTC) Received: by fxm27 with SMTP id 27so3160517fxm.3 for ; Tue, 19 Jan 2010 01:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=L0xw2hd145sNMH0ZraiBEk0XwPaAgPysKEhzVfeLqCM=; b=piyBGl5HKH3NbWRkTEnYMlorTxM1dHmIdki1E7QGd5+GRik2oFV6TJUmYQ905c1nB2 Cm0f/IOO52J1vApandsQHRlGTMDeh14NrJQ5r4hna4ntqqE/seBDO6uhGYXkBZYzSBL8 XIoi6KuRoSSyfNysdQgU9eSWCZMrc3BOt1zMk= 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=ZUUQzonZ/IzNVlzuYdOYpO9HaWxQmiPIGz1XQoXbBFI1zDfeGQh2v8tt1Xyx6DUU7z gDKTEmUBQLeUohepf1nhGd2odDQFk5m77ojIQGdEUwhwiSw7h8/lZlWccpLmzn7T1PM2 itl/EEfulm+TXsKbFFVNHiZVmxod15cj8fs6w= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.76.142 with SMTP id c14mr8834045fak.92.1263894803905; Tue, 19 Jan 2010 01:53:23 -0800 (PST) In-Reply-To: <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com> References: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com> <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com> Date: Tue, 19 Jan 2010 10:53:23 +0100 X-Google-Sender-Auth: 8057d9c0f40524ed Message-ID: <3bbf2fe11001190153s1d42a020pecb343993b7971a2@mail.gmail.com> From: Attilio Rao To: Jeff Roberson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Kohji Okuno Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:53:25 -0000 2010/1/19 Attilio Rao : > 2010/1/19 Jeff Roberson : >> On Tue, 19 Jan 2010, Kohji Okuno wrote: >> >>> Hello, Attilio, >>> >>> I think setpriority() can set priority to sleeping threads. >>> Is it really safe? >> >> I agree, in this code path maybe_resched is not properly locking curthre= ad. >> =C2=A0curthread will be sched_lock and the sleeping thread will be a sle= epq lock. >> =C2=A0I believe that since &sched_lock is ordered after container locks = it would >> be sufficient to compare the two td_lock pointers and acquire sched_lock= if >> they are not equal. =C2=A0Someone should look at other maybe_resched cal= lers or >> add an assert that curthread->td_lock is always &sched_lock in this >> function. > > I'm not sure I understand you well here, but I generally don't agree, > if we speak about the current code plus the patch I posted. > Without the patch, there is a general problem of maybe_preempt() > because sched_switch() will handle TDF_NEEDRESCHED just in racy ways > (not ensuring atomicity of td_lock operations for sleeping threads). > That's, however, still not specific to maybe_preempt() only. However: > * If you make a problem about the callers of maybe_resched() I agree. > The callers should assert for sched_lock to be in place. But that is > not a general problem of maybe_resched(), it is on the callers > ballpark > * If you make a problem about the locking itself, the patch IMHO > should fix it or there is still something I can't see. s/maybe_preempt/maybe_resched, of course :( Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 10:25:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 653B81065695; Tue, 19 Jan 2010 10:25:13 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 21AEC8FC15; Tue, 19 Jan 2010 10:25:12 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B5B641FFC22; Tue, 19 Jan 2010 10:25:11 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7F29A844BD; Tue, 19 Jan 2010 11:25:11 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Barton References: <20100118175033.7ba10de0@ernst.jennejohn.org> <20100118165537.GG81608@camelot.theinternet.com.au> <20100118221843.GB65074@rink.nu> <4B550B46.90502@FreeBSD.org> Date: Tue, 19 Jan 2010 11:25:11 +0100 In-Reply-To: <4B550B46.90502@FreeBSD.org> (Doug Barton's message of "Mon, 18 Jan 2010 17:30:46 -0800") Message-ID: <86ljfufl2w.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Jeff Roberson , Rink Springer , current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 10:25:13 -0000 "What's in a hostname? That which we call an underscore By any other name would be as invalid." Sorry, couldn't resist. And yes, I know it doesn't scan. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 11:46:05 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C08D01065676 for ; Tue, 19 Jan 2010 11:46:05 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3AF8FC08 for ; Tue, 19 Jan 2010 11:46:05 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0JBjmix042244; Tue, 19 Jan 2010 12:46:03 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0JBjmpH042243; Tue, 19 Jan 2010 12:45:48 +0100 (CET) (envelope-from olli) Date: Tue, 19 Jan 2010 12:45:48 +0100 (CET) Message-Id: <201001191145.o0JBjmpH042243@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com In-Reply-To: <20100118202805.GB1336@michelle.cdnetworks.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 19 Jan 2010 12:46:04 +0100 (CET) Cc: Subject: Re: bce(4) on IBM BladeCenter HS22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 11:46:05 -0000 Pyun YongHyeon wrote: > On Mon, Jan 18, 2010 at 09:14:39PM +0100, Oliver Fromme wrote: > > bce0: mem 0x92000000-0x93ffffff irq 30 at device 0.0 on pci16 > > bce0: attempting to allocate 1 MSI vectors (16 supported) > > msi: routing MSI IRQ 260 to local APIC 0 vector 112 > > bce0: using IRQ 260 for MSI > > bce0: /usr/src/sys/dev/bce/if_bce.c(1097): No PHY found on child MII bus! > > device_attach: bce0 attach returned 6 > > bce1: mem 0x94000000-0x95ffffff irq 37 at device 0.1 on pci16 > > bce1: attempting to allocate 1 MSI vectors (16 supported) > > msi: routing MSI IRQ 260 to local APIC 0 vector 112 > > bce1: using IRQ 260 for MSI > > bce1: /usr/src/sys/dev/bce/if_bce.c(1097): No PHY found on child MII bus! > > device_attach: bce1 attach returned 6 > > Ok, it seems brgphy(4) does not know the PHY. Let's see what PHY > you have. Please apply attached patch and let me know the output of > the patch. It will show PHYID1 and PHYID2 value. I get this for both bce0 and bce1: PHYID1: 0x0000 PHYID2: 0x0000 Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 11:48:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F0C31065695 for ; Tue, 19 Jan 2010 11:48:26 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout7.freenet.de (mout7.freenet.de [IPv6:2001:748:100:40::2:9]) by mx1.freebsd.org (Postfix) with ESMTP id EC9FB8FC1C for ; Tue, 19 Jan 2010 11:48:25 +0000 (UTC) Received: from [195.4.92.24] (helo=14.mx.freenet.de) by mout7.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NXCZM-0002jy-OH for current@freebsd.org; Tue, 19 Jan 2010 12:48:24 +0100 Received: from p57ae2844.dip0.t-ipconnect.de ([87.174.40.68]:50187 helo=ernst.jennejohn.org) by 14.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NXCZM-0001xz-1v for current@freebsd.org; Tue, 19 Jan 2010 12:48:24 +0100 Date: Tue, 19 Jan 2010 12:48:23 +0100 From: Gary Jennejohn Message-ID: <20100119124823.2397a59c@ernst.jennejohn.org> In-Reply-To: <20100118221843.GB65074@rink.nu> References: <20100118175033.7ba10de0@ernst.jennejohn.org> <20100118165537.GG81608@camelot.theinternet.com.au> <20100118221843.GB65074@rink.nu> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 11:48:26 -0000 On Mon, 18 Jan 2010 23:18:43 +0100 Rink Springer wrote: > On Tue, Jan 19, 2010 at 03:55:37AM +1100, Andrew Milton wrote: > > +-------[ Gary Jennejohn ]---------------------- > > | On Fri, 8 Jan 2010 14:56:45 -1000 (HST) > > | Jeff Roberson wrote: > > | > > | > I have been augmenting softupdates with a small journal that will be processed > > | > in lieu of fsck in the event of a crash. I have written some about this > > | > project here: http://jeffr_tech.livejournal.com/ > > | > > > | > > | For some reason I can't access this location. Hmm, firefox doesn't seem to like > > | the '_'. > > > > Because DNS hostnames can't contain underscores... ? > > That is false, they can (in fact, SVR records depend on this). However, > Jeff's blog is at http://jeffr-tech.livejournal.com/; his username > appears to be 'jeffr_tech'. > It's truly amazing how much traffic my mentioning that firefox didn't appear to like '_' has generated. Actually, it appears that it's wwwoflle which has problems. The more technical aspects of my post haven't been addressed in any way, shape or form. Just shows that modern humans still share the propensity of their primate ancestors for going after the low hanging fruit first. Creationists can go pack sand. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 08:28:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB3B11065672; Tue, 19 Jan 2010 08:28:32 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3ECA48FC1E; Tue, 19 Jan 2010 08:28:32 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 3F744153433; Tue, 19 Jan 2010 09:28:31 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3b8yueSNiT9; Tue, 19 Jan 2010 09:28:29 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 2095C15342F; Tue, 19 Jan 2010 09:28:25 +0100 (CET) Message-ID: <4B556D26.7040503@digiware.nl> Date: Tue, 19 Jan 2010 09:28:22 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Luigi Rizzo References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> <20100110185232.GA27907@onelab2.iet.unipi.it> <20100117110443.GA58434@onelab2.iet.unipi.it> <20100119075925.GA42257@onelab2.iet.unipi.it> In-Reply-To: <20100119075925.GA42257@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Jan 2010 12:23:18 +0000 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Hajimu UMEMOTO , freebsd-ipfw@freebsd.org, David Horn Subject: Re: Unified rc.firewall ipfw me/me6 issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 08:28:32 -0000 Luigi Rizzo wrote: > On Sun, Jan 17, 2010 at 12:04:43PM +0100, Luigi Rizzo wrote: >> On Sun, Jan 17, 2010 at 05:42:58PM +0900, Hajimu UMEMOTO wrote: >>> Hi, >>> >>>>>>>> On Sun, 10 Jan 2010 19:52:32 +0100 >>>>>>>> Luigi Rizzo said: While we are at it, might I suggest one more "nice" thing... For several of my projects I reduced configuring a gateway/nat/firewall to just stuffing hostipnrs:ports into some shell variables. eg: firewall_forward_services="192.168.10.0/24^22 192.168.10.74^873 192.168.10.74^1195 192.168.10.66^80 192.168.10.117^10000 192.168.10.67^45457 2001:4cb8:3::67^45457 192.168.10.116^sip 192.168.10.113^sip" And I used to do that with the "std"-notation host:port. But once I got ipv6 connected, that no longer worked. And I also found that the ipv6 parser did some wierd stuff on other places as well. Is it posible to fix the ipv6nr parser and have it also recognise the versions: [a:b:c::d:e] and [a:b:c::d:e/64] (like firefox does) Yes, I know the stanza is: put your code where your mouth is. And I've been trying to find time to do this, and given enough days time will pop up. But this discussion is already running and people are already breaking up the code. Thanx, --WjW From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 13:12:07 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E426A106566C for ; Tue, 19 Jan 2010 13:12:07 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D5218FC12 for ; Tue, 19 Jan 2010 13:12:06 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0JDBnuO045510; Tue, 19 Jan 2010 14:12:05 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0JDBnT0045509; Tue, 19 Jan 2010 14:11:49 +0100 (CET) (envelope-from olli) Date: Tue, 19 Jan 2010 14:11:49 +0100 (CET) Message-Id: <201001191311.o0JDBnT0045509@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com In-Reply-To: <20100118202805.GB1336@michelle.cdnetworks.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 19 Jan 2010 14:12:05 +0100 (CET) Cc: Subject: Re: bce(4) on IBM BladeCenter HS22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 13:12:08 -0000 Ok, I've got more information. Maybe this is helpful. I enabled BCE_DEBUG and set bce_debug = BCE_INSANE_PHY. At first I got a compile error and had to apply this patch: --- src/sys/dev/bce/if_bce.c.orig 2009-10-21 14:47:09.000000000 +0200 +++ src/sys/dev/bce/if_bce.c 2010-01-19 13:13:36.000000000 +0100 @@ -10038,9 +10045,9 @@ BCE_PRINTF("0x%08X - (0x%06X) state\n", val, BCE_BC_STATE); - val = bce_shmem_rd(sc, BCE_BC_CONDITION); + val = bce_shmem_rd(sc, BCE_BC_STATE_CONDITION); BCE_PRINTF("0x%08X - (0x%06X) condition\n", - val, BCE_BC_CONDITION); + val, BCE_BC_STATE_CONDITION); val = bce_shmem_rd(sc, BCE_BC_STATE_DEBUG_CMD); BCE_PRINTF("0x%08X - (0x%06X) debug_cmd\n", Then I got this output during boot: bce0: mem 0x92000000-0x93ffffff irq 30 at device 0.0 on pci16 bce0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 260 to local APIC 0 vector 112 bce0: using IRQ 260 for MSI bce0: bce_get_media(enter) bce0: Using PHY address 2. bce0: bce_get_media(exit) bce0: bce_dma_alloc(): status_block_paddr = 0xCE36480 bce0: bce_dma_alloc(): stats_block_paddr = 0xCE21800 bce0: bce_dma_alloc(): ctx_paddr[0] = 0xCE77000 bce0: bce_dma_alloc(): ctx_paddr[1] = 0xCE37000 bce0: bce_dma_alloc(): tx_bd_chain_paddr[0] = 0x7D9F8000 bce0: bce_dma_alloc(): tx_bd_chain_paddr[1] = 0x7D9F9000 bce0: bce_dma_alloc(): rx_bd_chain_paddr[0] = 0x7D9FA000 bce0: bce_dma_alloc(): rx_bd_chain_paddr[1] = 0x7D9FB000 bce0: bce_dma_alloc(): Creating rx_mbuf_tag (max size = 0x2400 max segments = 1, max segment size = 0x2400) bce0: Invalid PHY address 0 for PHY read! bce0: Invalid PHY address 1 for PHY read! bce0: bce_miibus_read_reg(): phy = 2, reg = 0x0001 (BMSR ), val = 0x0 bce0: Invalid PHY address 3 for PHY read! bce0: Invalid PHY address 4 for PHY read! bce0: Invalid PHY address 5 for PHY read! bce0: Invalid PHY address 6 for PHY read! bce0: Invalid PHY address 7 for PHY read! bce0: Invalid PHY address 8 for PHY read! bce0: Invalid PHY address 9 for PHY read! bce0: Invalid PHY address 10 for PHY read! bce0: Invalid PHY address 11 for PHY read! bce0: Invalid PHY address 12 for PHY read! bce0: Invalid PHY address 13 for PHY read! bce0: Invalid PHY address 14 for PHY read! bce0: Invalid PHY address 15 for PHY read! bce0: Invalid PHY address 16 for PHY read! bce0: Invalid PHY address 17 for PHY read! bce0: Invalid PHY address 18 for PHY read! bce0: Invalid PHY address 19 for PHY read! bce0: Invalid PHY address 20 for PHY read! bce0: Invalid PHY address 21 for PHY read! bce0: Invalid PHY address 22 for PHY read! bce0: Invalid PHY address 23 for PHY read! bce0: Invalid PHY address 24 for PHY read! bce0: Invalid PHY address 25 for PHY read! bce0: Invalid PHY address 26 for PHY read! bce0: Invalid PHY address 27 for PHY read! bce0: Invalid PHY address 28 for PHY read! bce0: Invalid PHY address 29 for PHY read! bce0: Invalid PHY address 30 for PHY read! bce0: Invalid PHY address 31 for PHY read! bce0: /usr/src/sys/dev/bce/if_bce.c(1098): No PHY found on child MII bus! bce0: bce_miibus_read_reg(): phy = 2, reg = 0x0002, val = 0x0000 PHYID1: 0x0000 bce0: bce_miibus_read_reg(): phy = 2, reg = 0x0003, val = 0x0000 PHYID2: 0x0000 device_attach: bce0 attach returned 6 bce1: mem 0x94000000-0x95ffffff irq 37 at device 0.1 on pci16 bce1: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 260 to local APIC 0 vector 112 bce1: using IRQ 260 for MSI bce1: bce_get_media(enter) bce1: Using PHY address 2. bce1: bce_get_media(exit) bce1: bce_dma_alloc(): status_block_paddr = 0xCE362C0 bce1: bce_dma_alloc(): stats_block_paddr = 0xCE21800 bce1: bce_dma_alloc(): ctx_paddr[0] = 0xCE77000 bce1: bce_dma_alloc(): ctx_paddr[1] = 0xCE37000 bce1: bce_dma_alloc(): tx_bd_chain_paddr[0] = 0xCE58000 bce1: bce_dma_alloc(): tx_bd_chain_paddr[1] = 0xCE59000 bce1: bce_dma_alloc(): rx_bd_chain_paddr[0] = 0xCE5A000 bce1: bce_dma_alloc(): rx_bd_chain_paddr[1] = 0xCE5B000 bce1: bce_dma_alloc(): Creating rx_mbuf_tag (max size = 0x2400 max segments = 1, max segment size = 0x2400) bce1: Invalid PHY address 0 for PHY read! bce1: Invalid PHY address 1 for PHY read! bce1: bce_miibus_read_reg(): phy = 2, reg = 0x0001 (BMSR ), val = 0x0 bce1: Invalid PHY address 3 for PHY read! bce1: Invalid PHY address 4 for PHY read! bce1: Invalid PHY address 5 for PHY read! bce1: Invalid PHY address 6 for PHY read! bce1: Invalid PHY address 7 for PHY read! bce1: Invalid PHY address 8 for PHY read! bce1: Invalid PHY address 9 for PHY read! bce1: Invalid PHY address 10 for PHY read! bce1: Invalid PHY address 11 for PHY read! bce1: Invalid PHY address 12 for PHY read! bce1: Invalid PHY address 13 for PHY read! bce1: Invalid PHY address 14 for PHY read! bce1: Invalid PHY address 15 for PHY read! bce1: Invalid PHY address 16 for PHY read! bce1: Invalid PHY address 17 for PHY read! bce1: Invalid PHY address 18 for PHY read! bce1: Invalid PHY address 19 for PHY read! bce1: Invalid PHY address 20 for PHY read! bce1: Invalid PHY address 21 for PHY read! bce1: Invalid PHY address 22 for PHY read! bce1: Invalid PHY address 23 for PHY read! bce1: Invalid PHY address 24 for PHY read! bce1: Invalid PHY address 25 for PHY read! bce1: Invalid PHY address 26 for PHY read! bce1: Invalid PHY address 27 for PHY read! bce1: Invalid PHY address 28 for PHY read! bce1: Invalid PHY address 29 for PHY read! bce1: Invalid PHY address 30 for PHY read! bce1: Invalid PHY address 31 for PHY read! bce1: /usr/src/sys/dev/bce/if_bce.c(1098): No PHY found on child MII bus! bce1: bce_miibus_read_reg(): phy = 2, reg = 0x0002, val = 0x0000 PHYID1: 0x0000 bce1: bce_miibus_read_reg(): phy = 2, reg = 0x0003, val = 0x0000 PHYID2: 0x0000 device_attach: bce1 attach returned 6 Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97 From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 15:30:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD78B106568F; Tue, 19 Jan 2010 15:30:40 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id C07E48FC15; Tue, 19 Jan 2010 15:30:38 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=9zKBo0zsyzYA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=ldXBf-_B8ngLE07iZGMA:9 a=zuCo5EVPxe2ME6YR5X2INzG0KH0A:4 a=Zm-1vYCK5YE9VYxm:21 a=HhhIMW2kEs7IxnR4:21 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1359616748; Tue, 19 Jan 2010 16:30:36 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Tue, 19 Jan 2010 16:29:13 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <20100114090329.GH63408@citylink.fud.org.nz> <20100119091217.GR39820@stlux503.dsto.defence.gov.au> In-Reply-To: <20100119091217.GR39820@stlux503.dsto.defence.gov.au> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001191629.13323.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 15:30:40 -0000 On Tuesday 19 January 2010 10:12:17 Wilkinson, Alex wrote: > 0n Thu, Jan 14, 2010 at 10:03:29PM +1300, Andrew Thompson wrote: > >On Thu, Jan 14, 2010 at 04:48:31PM +0800, Wilkinson, Alex wrote: > >> 0n Thu, Jan 14, 2010 at 09:24:47AM +0100, Hans Petter Selasky wrote: > >> >I think Andrew made a fixed port which you can test. > >> > >> Can you please point me in the direction to this ? > > > >I'l update the tarball tomorrow and send it out. > > Got these errors: > > [FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010] > > ===> Building for webcamd-0.1.0 > Warning: Object directory not changed from original > /usr/ports/multimedia/webcamd/work/webcamd-0.1.0 cc -O2 -pipe > -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/drivers/m > edia/video/gspca > -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/include > -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux > -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0 > -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/dummy > -DCONFIG_VIDEO_V4L1_COMPAT -DHAVE_WEBCAMD -include webcamd_global.h -O2 > -Wall -Wno-pointer-sign -fvisibility=hidden -std=gnu99 -fstack-protector > -c webcamd.c webcamd.c:37:23: error: video4bsd.h: No such file or > directory > webcamd.c:55: error: 'V4B_ALLOC_UNIT_MAX' undeclared here (not in a > function) webcamd.c: In function 'main': > webcamd.c:126: error: storage size of 'cmd' isn't known > webcamd.c:176: error: 'V4B_DEVICES_MAX' undeclared (first use in this > function) webcamd.c:176: error: (Each undeclared identifier is reported > only once webcamd.c:176: error: for each function it appears in.) > webcamd.c:206: error: 'V4B_IOCTL_GET_COMMAND' undeclared (first use in > this function) webcamd.c:212: error: 'V4B_CMD_OPEN' undeclared (first use > in this function) webcamd.c:223: error: 'V4B_IOCTL_SYNC_COMMAND' > undeclared (first use in this function) webcamd.c:226: error: > 'V4B_CMD_CLOSE' undeclared (first use in this function) webcamd.c:236: > error: 'V4B_CMD_READ' undeclared (first use in this function) > webcamd.c:244: error: 'V4B_CMD_WRITE' undeclared (first use in this > function) webcamd.c:252: error: 'V4B_CMD_IOCTL' undeclared (first use in > this function) webcamd.c:264: error: 'V4B_CMD_MMAP' undeclared (first use > in this function) webcamd.c:126: warning: unused variable 'cmd' > webcamd.c: In function 'copy_to_user': > webcamd.c:299: error: variable 'cmd' has initializer but incomplete type > webcamd.c:300: error: unknown field 'client_ptr' specified in > initializer webcamd.c:300: warning: excess elements in struct initializer > webcamd.c:300: warning: (near initialization for 'cmd') > webcamd.c:301: error: unknown field 'peer_ptr' specified in initializer > webcamd.c:301: warning: excess elements in struct initializer > webcamd.c:301: warning: (near initialization for 'cmd') > webcamd.c:302: error: unknown field 'length' specified in initializer > webcamd.c:302: warning: excess elements in struct initializer > webcamd.c:302: warning: (near initialization for 'cmd') > webcamd.c:299: error: storage size of 'cmd' isn't known > webcamd.c:306: error: 'V4B_IOCTL_WRITE_DATA' undeclared (first use in > this function) webcamd.c:299: warning: unused variable 'cmd' > webcamd.c: In function 'copy_from_user': > webcamd.c:315: error: variable 'cmd' has initializer but incomplete type > webcamd.c:316: error: unknown field 'client_ptr' specified in > initializer webcamd.c:316: warning: excess elements in struct initializer > webcamd.c:316: warning: (near initialization for 'cmd') > webcamd.c:317: error: unknown field 'peer_ptr' specified in initializer > webcamd.c:317: warning: excess elements in struct initializer > webcamd.c:317: warning: (near initialization for 'cmd') > webcamd.c:318: error: unknown field 'length' specified in initializer > webcamd.c:318: warning: excess elements in struct initializer > webcamd.c:318: warning: (near initialization for 'cmd') > webcamd.c:315: error: storage size of 'cmd' isn't known > webcamd.c:322: error: 'V4B_IOCTL_READ_DATA' undeclared (first use in > this function) webcamd.c:315: warning: unused variable 'cmd' > webcamd.c: In function 'set_mmap': > webcamd.c:370: error: variable 'cmd' has initializer but incomplete type > webcamd.c:370: warning: excess elements in struct initializer > webcamd.c:370: warning: (near initialization for 'cmd') > webcamd.c:370: warning: excess elements in struct initializer > webcamd.c:370: warning: (near initialization for 'cmd') > webcamd.c:370: error: storage size of 'cmd' isn't known > webcamd.c:389: error: 'V4B_IOCTL_MAP_MEMORY' undeclared (first use in > this function) webcamd.c:370: warning: unused variable 'cmd' > webcamd.c: In function 'malloc_vm': > webcamd.c:403: error: variable 'cmd' has initializer but incomplete type > webcamd.c:403: warning: excess elements in struct initializer > webcamd.c:403: warning: (near initialization for 'cmd') > webcamd.c:403: warning: excess elements in struct initializer > webcamd.c:403: warning: (near initialization for 'cmd') > webcamd.c:403: error: storage size of 'cmd' isn't known > webcamd.c:428: error: 'V4B_IOCTL_ALLOC_MEMORY' undeclared (first use in > this function) webcamd.c:442: error: 'V4B_ALLOC_PAGES_MAX' undeclared > (first use in this function) webcamd.c:446: error: 'V4B_IOCTL_FREE_MEMORY' > undeclared (first use in this function) webcamd.c:403: warning: unused > variable 'cmd' > webcamd.c: In function 'free_vm': > webcamd.c:466: error: variable 'cmd' has initializer but incomplete type > webcamd.c:466: warning: excess elements in struct initializer > webcamd.c:466: warning: (near initialization for 'cmd') > webcamd.c:466: warning: excess elements in struct initializer > webcamd.c:466: warning: (near initialization for 'cmd') > webcamd.c:466: error: storage size of 'cmd' isn't known > webcamd.c:483: error: 'V4B_IOCTL_FREE_MEMORY' undeclared (first use in > this function) webcamd.c:466: warning: unused variable 'cmd' > *** Error code 1 > > Stop in /usr/ports/multimedia/webcamd/work/webcamd-0.1.0. > *** Error code 1 > > Stop in /usr/ports/multimedia/webcamd. > Exit 1 Please check /etc/make.conf and replace any CFLAGS= with CFLAGS+= --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 15:38:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD0E106566C; Tue, 19 Jan 2010 15:38:29 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA2E38FC1F; Tue, 19 Jan 2010 15:38:29 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id A94971FFC22; Tue, 19 Jan 2010 15:38:28 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 81B52844BD; Tue, 19 Jan 2010 16:38:28 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Hans Petter Selasky References: <201001101437.37269.hselasky@c2i.net> <20100114090329.GH63408@citylink.fud.org.nz> <20100119091217.GR39820@stlux503.dsto.defence.gov.au> <201001191629.13323.hselasky@c2i.net> Date: Tue, 19 Jan 2010 16:38:28 +0100 In-Reply-To: <201001191629.13323.hselasky@c2i.net> (Hans Petter Selasky's message of "Tue, 19 Jan 2010 16:29:13 +0100") Message-ID: <86bpgqds0b.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, "Wilkinson, Alex" , freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 15:38:30 -0000 Hans Petter Selasky writes: > Please check /etc/make.conf and replace any CFLAGS=3D with CFLAGS+=3D Bzzt, wrong. It will make no difference whatsoever; make.conf is included by sys.mk before the Makefile itself is read, so the Makefile overrides make.conf, not the other way around. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 16:12:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 950D61065692; Tue, 19 Jan 2010 16:12:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id CE3848FC19; Tue, 19 Jan 2010 16:12:58 +0000 (UTC) Received: by fxm10 with SMTP id 10so877465fxm.14 for ; Tue, 19 Jan 2010 08:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=/XHocK1ofq9DAD5JeBrI99DGHRuJIV+P/uZBNZX+i2o=; b=P1jeLhwD/fUM8znN/9CMDzIMZz4TGQYR8C/4nncSZWrQsQ4cF85/DZtJ/czMlqBPgo 5bYXtci7QBsigk0B0yDCNijR3thZrLNelyQIsokpJqoSuKetvxI6QyKS065XLOpB9m5G 83KlEtEtyqu8EDRDSevszdbciNimJptN0kRIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=JGBL5rHYs/SEzwZtSCOBonerveCTjFGm2SJMWqcuZT4m9iUPrM/PojnYyLGYzvIlpG C2cR7mfRMImk23z/IuouUEmLZFEN7oY+gELU8UoumndXxh6Wk3CfPs9bo1cg5IpH197z wPoHf+9gNiCSL3GfOOl/rl4Vt6zdwZEQ7cDt4= Received: by 10.223.76.77 with SMTP id b13mr4657539fak.74.1263917577637; Tue, 19 Jan 2010 08:12:57 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2598706fxm.4.2010.01.19.08.12.56 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 08:12:56 -0800 (PST) Sender: Alexander Motin Message-ID: <4B55D9D4.1000008@FreeBSD.org> Date: Tue, 19 Jan 2010 18:12:04 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: FreeBSD-Current , FreeBSD Stable X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 16:12:59 -0000 Hi. I've made a patch, that should solve set of problems of CAM ATA and CAM generally. I would like to ask for testing and feedback. What patch does: - It unifies bus reset/probe sequence. Whenever bus attached at boot or later, CAM will automatically reset and scan it. It allows to remove duplicate code from many drivers. - Any bus, attached before CAM completed it's boot-time initialization, will equally join to the process, delaying boot if needed. - New kern.cam.boot_delay loader tunable should help controllers that are still unable to register their buses in time (such as slow USB/ PCCard/ CardBus devices). - To allow synchronization between different CAM levels, concept of requests priorities was extended. Priorities now split between several "run levels". Device can be freezed at specified level, allowing higher priority requests to pass. For example, no payload requests allowed, until PMP driver enable port. ATA XPT negotiate transfer parameters, periph driver configure caching and so on. - Frozen requests are no more counted by request allocation scheduler. It fixes deadlocks, when frozen low priority payload requests occupying slots, required by higher levels to manage theit execution. - Two last changes were holding proper ATA reinitialization and error recovery implementation. Now it is done: SATA controllers and Port Multipliers now implement automatic hot-plug and should correctly recover from timeouts and bus resets. Patch can be found here: http://people.freebsd.org/~mav/cam-ata.20100119.patch Feedback as always welcome. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 16:53:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0722F1065706; Tue, 19 Jan 2010 16:53:14 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id B4F118FC15; Tue, 19 Jan 2010 16:53:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 1FFA17B847; Wed, 20 Jan 2010 05:53:12 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bArSIIRCQZQO; Wed, 20 Jan 2010 05:53:07 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 20 Jan 2010 05:53:07 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 1540111432; Wed, 20 Jan 2010 05:53:07 +1300 (NZDT) Date: Wed, 20 Jan 2010 05:53:06 +1300 From: Andrew Thompson To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Message-ID: <20100119165306.GA58342@citylink.fud.org.nz> References: <201001101437.37269.hselasky@c2i.net> <20100114072753.GJ80705@stlux503.dsto.defence.gov.au> <201001140924.47454.hselasky@c2i.net> <20100114084831.GL80705@stlux503.dsto.defence.gov.au> <20100114090329.GH63408@citylink.fud.org.nz> <20100119091217.GR39820@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100119091217.GR39820@stlux503.dsto.defence.gov.au> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 16:53:14 -0000 On Tue, Jan 19, 2010 at 05:12:17PM +0800, Wilkinson, Alex wrote: > > 0n Thu, Jan 14, 2010 at 10:03:29PM +1300, Andrew Thompson wrote: > > >On Thu, Jan 14, 2010 at 04:48:31PM +0800, Wilkinson, Alex wrote: > >> > >> 0n Thu, Jan 14, 2010 at 09:24:47AM +0100, Hans Petter Selasky wrote: > >> > >> >I think Andrew made a fixed port which you can test. > >> > >> Can you please point me in the direction to this ? > > > >I'l update the tarball tomorrow and send it out. > > Got these errors: > > [FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010] > > ===> Building for webcamd-0.1.0 > Warning: Object directory not changed from original /usr/ports/multimedia/webcamd/work/webcamd-0.1.0 > cc -O2 -pipe -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/drivers/media/video/gspca -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/include -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0 -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/dummy -DCONFIG_VIDEO_V4L1_COMPAT -DHAVE_WEBCAMD -include webcamd_global.h -O2 -Wall -Wno-pointer-sign -fvisibility=hidden -std=gnu99 -fstack-protector -c webcamd.c > webcamd.c:37:23: error: video4bsd.h: No such file or directory > webcamd.c:55: error: 'V4B_ALLOC_UNIT_MAX' undeclared here (not in a function) > webcamd.c: In function 'main': > webcamd.c:126: error: storage size of 'cmd' isn't known > webcamd.c:176: error: 'V4B_DEVICES_MAX' undeclared (first use in this function) Do you have CFLAGS set in /etc/make.conf by chance? Andrew From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 17:56:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCE76106568F; Tue, 19 Jan 2010 17:56:14 +0000 (UTC) (envelope-from henry.hu.sh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2CE8FC13; Tue, 19 Jan 2010 17:56:14 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so947851qwd.7 for ; Tue, 19 Jan 2010 09:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jBoaQWg8CFuleeXNeyGQumCcDv+CMxvJ0CmQG/JUs+I=; b=OeNDYezXVeZsc5CUgjwIBO+DlgJ0kODcRiwruV2AGzN3J3Sbc9isv5iYGxMqbwrMwz Ou+OpqC+sDgnQRb2R3LkPOfh9YShNUJeU1aimqJNFCR7oQjzgR7DqqFfMQ9BXfrYPUlg eU8+GcJcN1zQSkaz+fisDe0DT7YWihU9w55UE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tEk8nkvWOMxtdHE5x25Cm/v+rMNMqyJ6xzdPNw8zDMzaN5crSK/5+gckaBQvB7vN/x EorRhmgpPblY3rx8Tl7Ju0MPqgiePS6HiYrDsBsdAORgBLYW9Xm2eJKqsYQ0WIMwgKqA oYhHTr1bshwsjzfKoxidnSiO4Mq3rENxzATrc= MIME-Version: 1.0 Received: by 10.229.55.69 with SMTP id t5mr5102192qcg.34.1263922394571; Tue, 19 Jan 2010 09:33:14 -0800 (PST) In-Reply-To: <201001101437.37269.hselasky@c2i.net> References: <201001101437.37269.hselasky@c2i.net> Date: Wed, 20 Jan 2010 01:33:14 +0800 Message-ID: <53a1e0711001190933y64a41e98h60fa3dec641d44fd@mail.gmail.com> From: Henry Hu To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 19 Jan 2010 18:01:21 +0000 Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 17:56:14 -0000 Hello, On Sun, Jan 10, 2010 at 9:37 PM, Hans Petter Selasky wro= te: > Hi, > > During the last couple of days I've spent some time to finish my webcam > daemon. My webcam daemon is basically an application which consists of > userspace Video4Linux USB webcam drivers and some uLinux glue code which = links > with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX w= hich > is provided by the video4bsd kernel module. There is full support for > mmap/read/write/open/close. poll is not supported. I've tested on my webcam and it works here. I have an USB Video Class webcam: ugen2.2: at usbus2, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON This is the first time it works in FreeBSD! Thanks a lot! Currently, it works with -s vga and -s cif. There are many other modes supported by the webcam, but pwcview just does not support them. This webcam supports at most 1280x1024, and the quality is clearly better than 640x480. There are some problems, however. First, when I start pwcview with an unsupported mode, the content of the window is green, and I cannot kill the process. Only after terminating webcamd can I terminate the process. Second, I cannot restart pwcview without restarting webcamd. At the second time I start pwcview with -s vga, the window is green, and I cannot kill it. The situation is similar to unsupported size. I've also tried applications such as pidgin, skype and mplayer. However no one successfully played from the webcam. I doubt it needs some extra work. I've changed pwcview a bit to keep the settings in internal variables instead of fetching them every time. Else I cannot change most parameters. Maybe the webcam only supports a certain set of setting values, and use the nearest value after setting them. Thanks again for the great work! It never caused any kernel panic, and the programs are fairly stable. > Basic operation and idea: > > /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the > interface for the V4L application. The video4bsd transports all data betw= een > these two devices. In the case the V4L application is using mmap, no data= is > copied due to shared kernel memory buffer! > > Licensing issues: > > Effectivly the webcamd userland program becomes GPL'ed due to the V4L USB > drivers which are GPL licensed. Some files inside the webcamd remains BSD > licensed which allows for building similar BSD licensed daemons. > > The rest of the code is BSD licensed. > > Source code: > > 1) FreeBSD 8-stable > > 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: > > http://p4web.freebsd.org/chv.cgi?CH=3D172876 > > http://perforce.freebsd.org/chv.cgi?CH=3D172876 > > 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be che= cked > out in the same folder due to dependencies) > > svn --username anonsvn --password anonsvn \ > =A0 =A0 =A0checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd > > make all install > kldload video4bsd > > svn --username anonsvn --password anonsvn \ > =A0 =A0 =A0checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux > > make fetch > make patch > make all > make install > > # this will attach to the first detected webcam: > ./webcamd > > # this will try to attach to the given USB unit, interface and V4B unit. > ./webcamd -d ugen4.1 -i 0 -v 0 > > # this will display webcam contents from /dev/video0 by default. > ./pwcview/pwcview > > Feedback and bug reports are welcome. > > Yes, I am working on getting this into ports! > > Known issues: > > 1) If you detach the USB webcam you need to manually restart the webcamd. > > --HPS > > Support: I will be available at #bsdusb on efnet during the day. > _______________________________________________ > freebsd-multimedia@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia > To unsubscribe, send any mail to "freebsd-multimedia-unsubscribe@freebsd.= org" > Cheers, Henry From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 18:15:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0E67106566C for ; Tue, 19 Jan 2010 18:15:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id A15588FC15 for ; Tue, 19 Jan 2010 18:15:24 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so952450qwd.7 for ; Tue, 19 Jan 2010 10:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=UFThy//xpuHRSFNUGElwefLPuhbVbQ68LJXYQCkfVeI=; b=MUBWDvpTwfBOwJ1DKj23VrHtOdjKk4IPxkaFTc2XtJ9UMKOEwPUTxL+diu5lsiEwpD N3hvpzr2kwSm2uyfQtokSZwKKVC3BijvSmpdJbRsom+VrRtbOh7IQVYxFhnq+P59M3wD 1uwJzTWYqD2R8K8fHTV7gFkbYkQD/HNnBxvGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=S0ycuHDw9NIYNXaDIuVwH+gdVCHYt8QYD2MKsC5XC0i3Z5d5LIdhhrnKWu6j5vPxbq 13EcesJe9Bewi+hC5ajlv1GzXG8zkEuAr0JoGwreXtdTQdo8sDIAoO0VlKu6YNcBCmsF T+7BklxU9e4Ix3lmT9xehpC0W9nskldtuyARc= Received: by 10.229.106.156 with SMTP id x28mr2290139qco.44.1263924923690; Tue, 19 Jan 2010 10:15:23 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 22sm6259580qyk.2.2010.01.19.10.15.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 10:15:21 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 19 Jan 2010 10:15:18 -0800 From: Pyun YongHyeon Date: Tue, 19 Jan 2010 10:15:18 -0800 To: Oliver Fromme Message-ID: <20100119181518.GA6201@michelle.cdnetworks.com> References: <20100118202805.GB1336@michelle.cdnetworks.com> <201001191311.o0JDBnT0045509@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <201001191311.o0JDBnT0045509@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.ORG Subject: Re: bce(4) on IBM BladeCenter HS22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 18:15:25 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 19, 2010 at 02:11:49PM +0100, Oliver Fromme wrote: > Ok, I've got more information. Maybe this is helpful. > I enabled BCE_DEBUG and set bce_debug = BCE_INSANE_PHY. > At first I got a compile error and had to apply this patch: > > --- src/sys/dev/bce/if_bce.c.orig 2009-10-21 14:47:09.000000000 +0200 > +++ src/sys/dev/bce/if_bce.c 2010-01-19 13:13:36.000000000 +0100 > @@ -10038,9 +10045,9 @@ > BCE_PRINTF("0x%08X - (0x%06X) state\n", > val, BCE_BC_STATE); > > - val = bce_shmem_rd(sc, BCE_BC_CONDITION); > + val = bce_shmem_rd(sc, BCE_BC_STATE_CONDITION); > BCE_PRINTF("0x%08X - (0x%06X) condition\n", > - val, BCE_BC_CONDITION); > + val, BCE_BC_STATE_CONDITION); > > val = bce_shmem_rd(sc, BCE_BC_STATE_DEBUG_CMD); > BCE_PRINTF("0x%08X - (0x%06X) debug_cmd\n", > > Then I got this output during boot: > > bce0: mem 0x92000000-0x93ffffff irq 30 at device 0.0 on pci16 > bce0: attempting to allocate 1 MSI vectors (16 supported) > msi: routing MSI IRQ 260 to local APIC 0 vector 112 > bce0: using IRQ 260 for MSI > bce0: bce_get_media(enter) > bce0: Using PHY address 2. > bce0: bce_get_media(exit) > bce0: bce_dma_alloc(): status_block_paddr = 0xCE36480 > bce0: bce_dma_alloc(): stats_block_paddr = 0xCE21800 > bce0: bce_dma_alloc(): ctx_paddr[0] = 0xCE77000 > bce0: bce_dma_alloc(): ctx_paddr[1] = 0xCE37000 > bce0: bce_dma_alloc(): tx_bd_chain_paddr[0] = 0x7D9F8000 > bce0: bce_dma_alloc(): tx_bd_chain_paddr[1] = 0x7D9F9000 > bce0: bce_dma_alloc(): rx_bd_chain_paddr[0] = 0x7D9FA000 > bce0: bce_dma_alloc(): rx_bd_chain_paddr[1] = 0x7D9FB000 > bce0: bce_dma_alloc(): Creating rx_mbuf_tag (max size = 0x2400 max segments = 1, max segment size = 0x2400) > bce0: Invalid PHY address 0 for PHY read! > bce0: Invalid PHY address 1 for PHY read! > bce0: bce_miibus_read_reg(): phy = 2, reg = 0x0001 (BMSR ), val = 0x0 > bce0: Invalid PHY address 3 for PHY read! > bce0: Invalid PHY address 4 for PHY read! > bce0: Invalid PHY address 5 for PHY read! > bce0: Invalid PHY address 6 for PHY read! > bce0: Invalid PHY address 7 for PHY read! > bce0: Invalid PHY address 8 for PHY read! > bce0: Invalid PHY address 9 for PHY read! > bce0: Invalid PHY address 10 for PHY read! > bce0: Invalid PHY address 11 for PHY read! > bce0: Invalid PHY address 12 for PHY read! > bce0: Invalid PHY address 13 for PHY read! > bce0: Invalid PHY address 14 for PHY read! > bce0: Invalid PHY address 15 for PHY read! > bce0: Invalid PHY address 16 for PHY read! > bce0: Invalid PHY address 17 for PHY read! > bce0: Invalid PHY address 18 for PHY read! > bce0: Invalid PHY address 19 for PHY read! > bce0: Invalid PHY address 20 for PHY read! > bce0: Invalid PHY address 21 for PHY read! > bce0: Invalid PHY address 22 for PHY read! > bce0: Invalid PHY address 23 for PHY read! > bce0: Invalid PHY address 24 for PHY read! > bce0: Invalid PHY address 25 for PHY read! > bce0: Invalid PHY address 26 for PHY read! > bce0: Invalid PHY address 27 for PHY read! > bce0: Invalid PHY address 28 for PHY read! > bce0: Invalid PHY address 29 for PHY read! > bce0: Invalid PHY address 30 for PHY read! > bce0: Invalid PHY address 31 for PHY read! > bce0: /usr/src/sys/dev/bce/if_bce.c(1098): No PHY found on child MII bus! > bce0: bce_miibus_read_reg(): phy = 2, reg = 0x0002, val = 0x0000 > PHYID1: 0x0000 > bce0: bce_miibus_read_reg(): phy = 2, reg = 0x0003, val = 0x0000 > PHYID2: 0x0000 > device_attach: bce0 attach returned 6 Thanks for the detailed information. I vaguely guess bce(4) used wrong PHY address for controller. How about attached patch? The patch just reset the PHY address to 1, it's not correct way to set it but just wants to know whether brgphy(4) is attached to the PHY. --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bce.phyid.diff2" Index: sys/dev/bce/if_bce.c =================================================================== --- sys/dev/bce/if_bce.c (revision 202586) +++ sys/dev/bce/if_bce.c (working copy) @@ -1091,6 +1091,9 @@ ifp->if_baudrate = IF_Mbps(1000); /* Check for an MII child bus by probing the PHY. */ +#if 1 + sc->bce_phy_addr = 1; +#endif if (mii_phy_probe(dev, &sc->bce_miibus, bce_ifmedia_upd, bce_ifmedia_sts)) { BCE_PRINTF("%s(%d): No PHY found on child MII bus!\n", --0OAP2g/MAC+5xKAE-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 18:20:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41C751065670; Tue, 19 Jan 2010 18:20:33 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id F16968FC13; Tue, 19 Jan 2010 18:20:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id D6EA97B861; Wed, 20 Jan 2010 07:20:30 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZAiX1S4nCf4; Wed, 20 Jan 2010 07:20:26 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 20 Jan 2010 07:20:23 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 0C5AB11432; Wed, 20 Jan 2010 07:20:23 +1300 (NZDT) Date: Wed, 20 Jan 2010 07:20:22 +1300 From: Andrew Thompson To: Dag-Erling Sm??rgrav Message-ID: <20100119182022.GB58342@citylink.fud.org.nz> References: <201001101437.37269.hselasky@c2i.net> <20100114090329.GH63408@citylink.fud.org.nz> <20100119091217.GR39820@stlux503.dsto.defence.gov.au> <201001191629.13323.hselasky@c2i.net> <86bpgqds0b.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86bpgqds0b.fsf@ds4.des.no> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 18:20:33 -0000 On Tue, Jan 19, 2010 at 04:38:28PM +0100, Dag-Erling Sm??rgrav wrote: > Hans Petter Selasky writes: > > Please check /etc/make.conf and replace any CFLAGS= with CFLAGS+= > > Bzzt, wrong. It will make no difference whatsoever; make.conf is > included by sys.mk before the Makefile itself is read, so the Makefile > overrides make.conf, not the other way around. I have tested this with CFLAGS=-g in /etc/make.conf /usr/ports/multimedia/webcamd# make -dA ... Global:CFLAGS = -g -I/usr/local/include ... (cd /usr/ports/multimedia/webcamd/work/webcamd-0.1.0; if ! /usr/bin/env SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local X11BASE=/usr/local MOTIFLIB="-L/usr/local/lib -lXm -lXp" LIBDIR="/usr/lib" CC="cc" CFLAGS="-g -I/usr/local/include" CXX="c++" CXXFLAGS="-g -I/usr/local/include" MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -o root -g wheel -m 555" BSD_INSTALL_SCRIPT="install -o root -g wheel -m 555" BSD_INSTALL_DATA="install -o root -g wheel -m 444" BSD_INSTALL_MAN="install -o root -g wheel -m 444" make -f M akefile all; then if [ x != x ] ; then echo "===> Compilation failed unexpectedly."; (echo ) | /usr/bin/fmt 75 79 ; fi; false; fi) ... Global:CFLAGS = -g So CFLAGS is being properly passed to the /usr/ports/multimedia/webcamd/work/webcamd-0.1.0/Makefile via the environment but its getting overridden and causing the reported build error. Andrew From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 19:23:30 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB3631065670 for ; Tue, 19 Jan 2010 19:23:30 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2F2168FC20 for ; Tue, 19 Jan 2010 19:23:30 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0JJNDkA064137; Tue, 19 Jan 2010 20:23:28 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0JJNDPM064136; Tue, 19 Jan 2010 20:23:13 +0100 (CET) (envelope-from olli) Date: Tue, 19 Jan 2010 20:23:13 +0100 (CET) Message-Id: <201001191923.o0JJNDPM064136@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com In-Reply-To: <20100119181518.GA6201@michelle.cdnetworks.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 19 Jan 2010 20:23:29 +0100 (CET) Cc: Subject: Re: bce(4) on IBM BladeCenter HS22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 19:23:30 -0000 Pyun YongHyeon wrote: > Thanks for the detailed information. I vaguely guess bce(4) used > wrong PHY address for controller. How about attached patch? > The patch just reset the PHY address to 1, it's not correct way to > set it but just wants to know whether brgphy(4) is attached to the > PHY. Unfortunately, it produces almost the same output, except the registers now read 0xffff instead of 0x0000: bce0: mem 0x92000000-0x93ffffff irq 30 at device 0.0 on pci16 bce0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 260 to local APIC 0 vector 112 bce0: using IRQ 260 for MSI bce0: bce_get_media(enter) bce0: Using PHY address 2. bce0: bce_get_media(exit) bce0: bce_dma_alloc(): status_block_paddr = 0xCE36480 bce0: bce_dma_alloc(): stats_block_paddr = 0xCE21800 bce0: bce_dma_alloc(): ctx_paddr[0] = 0xCE77000 bce0: bce_dma_alloc(): ctx_paddr[1] = 0xCE37000 bce0: bce_dma_alloc(): tx_bd_chain_paddr[0] = 0x7D9F8000 bce0: bce_dma_alloc(): tx_bd_chain_paddr[1] = 0x7D9F9000 bce0: bce_dma_alloc(): rx_bd_chain_paddr[0] = 0x7D9FA000 bce0: bce_dma_alloc(): rx_bd_chain_paddr[1] = 0x7D9FB000 bce0: bce_dma_alloc(): Creating rx_mbuf_tag (max size = 0x2400 max segments = 1, max segment size = 0x2400) bce0: Invalid PHY address 0 for PHY read! bce0: bce_miibus_read_reg(): phy = 1, reg = 0x0001 (BMSR ), val = 0xffff bce0: Invalid PHY address 2 for PHY read! bce0: Invalid PHY address 3 for PHY read! bce0: Invalid PHY address 4 for PHY read! bce0: Invalid PHY address 5 for PHY read! bce0: Invalid PHY address 6 for PHY read! bce0: Invalid PHY address 7 for PHY read! bce0: Invalid PHY address 8 for PHY read! bce0: Invalid PHY address 9 for PHY read! bce0: Invalid PHY address 10 for PHY read! bce0: Invalid PHY address 11 for PHY read! bce0: Invalid PHY address 12 for PHY read! bce0: Invalid PHY address 13 for PHY read! bce0: Invalid PHY address 14 for PHY read! bce0: Invalid PHY address 15 for PHY read! bce0: Invalid PHY address 16 for PHY read! bce0: Invalid PHY address 17 for PHY read! bce0: Invalid PHY address 18 for PHY read! bce0: Invalid PHY address 19 for PHY read! bce0: Invalid PHY address 20 for PHY read! bce0: Invalid PHY address 21 for PHY read! bce0: Invalid PHY address 22 for PHY read! bce0: Invalid PHY address 23 for PHY read! bce0: Invalid PHY address 24 for PHY read! bce0: Invalid PHY address 25 for PHY read! bce0: Invalid PHY address 26 for PHY read! bce0: Invalid PHY address 27 for PHY read! bce0: Invalid PHY address 28 for PHY read! bce0: Invalid PHY address 29 for PHY read! bce0: Invalid PHY address 30 for PHY read! bce0: Invalid PHY address 31 for PHY read! bce0: /usr/src/sys/dev/bce/if_bce.c(1101): No PHY found on child MII bus! bce0: bce_miibus_read_reg(): phy = 1, reg = 0x0002, val = 0xFFFF PHYID1: 0xffff bce0: bce_miibus_read_reg(): phy = 1, reg = 0x0003, val = 0xFFFF PHYID2: 0xffff device_attach: bce0 attach returned 6 (the same for bce1.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The last good thing written in C was Franz Schubert's Symphony number 9." -- Erwin Dieterich From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 19:37:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67E27106568B for ; Tue, 19 Jan 2010 19:37:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 19FE98FC23 for ; Tue, 19 Jan 2010 19:37:48 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so971039qwd.7 for ; Tue, 19 Jan 2010 11:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=8Ni6KGMZIs1DiZ063vE24egZXpHrq2whwzJuPvgnklE=; b=V5KvemxHXezzgnsG1VOozfMLf6TWaXIx8ER1ox0HdGQ6yPLXLBCbeb0lKxDsawsBm+ uotQD0gkpDHg8F/5sR/yPhbLntpSKGzrmJ+Fl/xtWey5CBAQ/Siv3glY3THfVPam8PD7 AgjP1BZu51jn6M0HzZFaRstL8dr+BR+u4qm3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=q4smbR7V38Y3tvgk4pq6Zj7BWyDSB9e/irET+jzEdRfb+bJZ1nxFuTA4igNlI26ddW DKIml8q87iEiocCdq8FC9LTyuj4OiodSsbQ3eOkA8ZBQA9PpiuibYXnwkZfZTfhEFbU+ rd0f1z/2Y8IZg43Br8qE5oYaiwRR7V1NWWZKA= Received: by 10.224.89.196 with SMTP id f4mr5520297qam.90.1263929868299; Tue, 19 Jan 2010 11:37:48 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 23sm6296835qyk.3.2010.01.19.11.37.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 11:37:47 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 19 Jan 2010 11:37:43 -0800 From: Pyun YongHyeon Date: Tue, 19 Jan 2010 11:37:43 -0800 To: Oliver Fromme Message-ID: <20100119193743.GC6201@michelle.cdnetworks.com> References: <20100119181518.GA6201@michelle.cdnetworks.com> <201001191923.o0JJNDPM064136@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001191923.o0JJNDPM064136@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.ORG Subject: Re: bce(4) on IBM BladeCenter HS22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 19:37:49 -0000 On Tue, Jan 19, 2010 at 08:23:13PM +0100, Oliver Fromme wrote: > Pyun YongHyeon wrote: > > Thanks for the detailed information. I vaguely guess bce(4) used > > wrong PHY address for controller. How about attached patch? > > The patch just reset the PHY address to 1, it's not correct way to > > set it but just wants to know whether brgphy(4) is attached to the > > PHY. > > Unfortunately, it produces almost the same output, > except the registers now read 0xffff instead of 0x0000: > :-( Ok, could you remove the safety belt of bce_miibus_read_reg() to allow accessing all PHY address? You can comment out sc->bce_phy_addr check in bce_miibus_read_reg() to allow mii_phy_probe try to read all 32 possible PHY addresses. Does mii(4) probe manage to read something? From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 20:12:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D619106566B; Tue, 19 Jan 2010 20:12:41 +0000 (UTC) (envelope-from vova@parallels.com) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 27CD18FC14; Tue, 19 Jan 2010 20:12:40 +0000 (UTC) Received: from vbook.fbsd.ru ([77.232.23.6]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id o0JKCXYB026573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 23:12:34 +0300 (MSK) Received: from vova by vbook.fbsd.ru with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NXKRE-0000vD-HM; Tue, 19 Jan 2010 23:12:32 +0300 From: Vladimir Grebenschikov To: vova@fbsd.ru In-Reply-To: <1263244252.3558.29.camel@localhost> References: <201001101437.37269.hselasky@c2i.net> <1263244252.3558.29.camel@localhost> Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jan 2010 23:12:32 +0300 Message-ID: <1263931952.2993.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.29.5 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 20:12:41 -0000 Hi=20 I've tested with recent ports. pwcview works fine, both vga and sif but skype still sees /dev/video0 but fails to play anything from it, multimedia/cheese even does not sees webcam. Is it supposed, or I am so unlucky ? PS. microphone in cam work also as snd_uaudio pcm2 -----Original Message----- From: Vladimir Grebenschikov Reply-to: vova@fbsd.ru To: Hans Petter Selasky Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing Date: Tue, 12 Jan 2010 00:10:52 +0300 Hi=20 Thanks you for efforts! I've tested it with=20 ugen4.2: at usbus4, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON on 9-CURRENT pwcview works fine: $ ./pwcview/pwcview Webcam set to: 320x240 (sif) at 5 fps skype detects video device, but shows only black window instead of picture. build webcamd.c with debug shows: $ ./webcamd Probing for 0.0.0 KrefGet: 0x483e2304 =3D 1 KrefGet: 0x483e2304 =3D 2 KrefGet: 0x483e2554 =3D 1 KrefGet: 0x483e2610 =3D 1 Added device 0x48318b04 KrefGet: 0x48318b08 =3D 1 Received command 1 0x00000000 KrefGet: 0x48318b08 =3D 2 Status =3D 0 Received command 5 0x40047601 Status =3D -22 Received command 5 0x403c7601 Status =3D 0 Received command 5 0x400e7606 Status =3D 0 Received command 5 0x800e7607 Status =3D -22 Received command 5 0x800e7607 Status =3D 0 Received command 5 0x40207609 Status =3D 0 Received command 5 0x8020760a Status =3D 0 ... and then in loop: Status =3D -22 Received command 3 0x00025800 Status =3D -22 Received command 3 0x00025800 Status =3D -22 Received command 3 0x00025800 Status =3D -22 Received command 3 0x00025800 Status =3D -22 Received command 3 0x00025800 ... Side question, is it possible to use audio microphone of USB camera ? -----Original Message----- From: Hans Petter Selasky To: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing Date: Sun, 10 Jan 2010 14:37:37 +0100 Hi, During the last couple of days I've spent some time to finish my webcam=20 daemon. My webcam daemon is basically an application which consists of userspace Video4Linux USB webcam drivers and some uLinux glue code which links=20 with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX which=20 is provided by the video4bsd kernel module. There is full support for=20 mmap/read/write/open/close. poll is not supported. Basic operation and idea: /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the=20 interface for the V4L application. The video4bsd transports all data between=20 these two devices. In the case the V4L application is using mmap, no data is=20 copied due to shared kernel memory buffer! Licensing issues: Effectivly the webcamd userland program becomes GPL'ed due to the V4L USB=20 drivers which are GPL licensed. Some files inside the webcamd remains BSD=20 licensed which allows for building similar BSD licensed daemons. The rest of the code is BSD licensed. Source code: 1) FreeBSD 8-stable 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: http://p4web.freebsd.org/chv.cgi?CH=3D172876 http://perforce.freebsd.org/chv.cgi?CH=3D172876 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be checked=20 out in the same folder due to dependencies) svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd make all install kldload video4bsd svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux make fetch make patch make all make install # this will attach to the first detected webcam: ./webcamd # this will try to attach to the given USB unit, interface and V4B unit. ./webcamd -d ugen4.1 -i 0 -v 0 # this will display webcam contents from /dev/video0 by default. ./pwcview/pwcview Feedback and bug reports are welcome. Yes, I am working on getting this into ports! Known issues: 1) If you detach the USB webcam you need to manually restart the webcamd. --HPS Support: I will be available at #bsdusb on efnet during the day. _______________________________________________ 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" --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 21:20:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FB33106566B; Tue, 19 Jan 2010 21:20:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id C87428FC0A; Tue, 19 Jan 2010 21:20:25 +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 o0JLKJJa065277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 23:20:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0JLKJ5P007387; Tue, 19 Jan 2010 23:20:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0JLKJxR007386; Tue, 19 Jan 2010 23:20:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 19 Jan 2010 23:20:19 +0200 From: Kostik Belousov To: gabor@freebsd.org Message-ID: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j3olVFx0FsM75XyV" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: attilio@freebsd.org, current@freebsd.org Subject: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:20:26 -0000 --j3olVFx0FsM75XyV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, r189765 enabled NLS support for libc. Now, any strerror(3) call causes 4 (!) failing stat(2) calls. I think this is untolerable. Catopen() does not cache the catalog descriptor, at least for libc, at least for the case where the open failed. On the active web server, these msgcat activities easily become dominant in the CPU time of the web server process. 1715 nginx CALL open(0x804004bc0,O_RDONLY,0) 1715 nginx NAMI "/usr/home/guests/xenos/var/rvs/docroot/1/l/101/6/g" 1715 nginx RET open -1 errno 2 No such file or directory 1715 nginx CALL stat(0x7fffffffd9b0,0x7fffffffd930) 1715 nginx NAMI "/usr/share/nls/C/libc.cat" 1715 nginx RET stat -1 errno 2 No such file or directory 1715 nginx CALL stat(0x7fffffffd9b0,0x7fffffffd930) 1715 nginx NAMI "/usr/share/nls/libc/C" 1715 nginx RET stat -1 errno 2 No such file or directory 1715 nginx CALL stat(0x7fffffffd9b0,0x7fffffffd930) 1715 nginx NAMI "/usr/local/share/nls/C/libc.cat" 1715 nginx RET stat -1 errno 2 No such file or directory 1715 nginx CALL stat(0x7fffffffd9b0,0x7fffffffd930) 1715 nginx NAMI "/usr/local/share/nls/libc/C" 1715 nginx RET stat -1 errno 2 No such file or directory 1715 nginx CALL write(0x46,0x7fffffffdec0,0x109) 1715 nginx GIO fd 70 wrote 265 bytes "2010/01/19 14:41:09 [error] 1715#0: *40673092 open() "/usr/home/guests\ /xenos/var/rvs/docroot/1/l/101/6/g" failed (2: No such file or directo\ ry), client: YYY.YYY.YYY.YYY, server: do.not.say.this, reque\ st: "GET /1/l/101/6/g HTTP/1.1", host: "XXX.XXX.XXX.XXX" --j3olVFx0FsM75XyV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktWIhMACgkQC3+MBN1Mb4iyQgCfZnwjaBWr0mh1LmJa9AgkOdfq kYgAn3RWfD/WTyvwkYMB3B/08UNzeOtj =VCmO -----END PGP SIGNATURE----- --j3olVFx0FsM75XyV-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 21:56:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A382106568B; Tue, 19 Jan 2010 21:56:01 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id D12AB8FC12; Tue, 19 Jan 2010 21:56:00 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0JLrLu8003228; Wed, 20 Jan 2010 08:23:21 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Wed, 20 Jan 2010 08:25:59 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 08:25:58 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 05:55:57 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0JLoMmn045420; Wed, 20 Jan 2010 05:50:22 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0JLoM2r045419; Wed, 20 Jan 2010 05:50:22 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 20 Jan 2010 05:50:22 +0800 From: "Wilkinson, Alex" To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100119215022.GB45270@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org References: <201001101437.37269.hselasky@c2i.net> <20100114072753.GJ80705@stlux503.dsto.defence.gov.au> <201001140924.47454.hselasky@c2i.net> <20100114084831.GL80705@stlux503.dsto.defence.gov.au> <20100114090329.GH63408@citylink.fud.org.nz> <20100119091217.GR39820@stlux503.dsto.defence.gov.au> <20100119165306.GA58342@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100119165306.GA58342@citylink.fud.org.nz> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 19 Jan 2010 21:55:58.0011 (UTC) FILETIME=[2E81D8B0:01CA9952] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17142.000 X-TM-AS-Result: No--7.858600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:56:01 -0000 0n Wed, Jan 20, 2010 at 05:53:06AM +1300, Andrew Thompson wrote: >> Got these errors: >> >> [FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010] >> >> ===> Building for webcamd-0.1.0 >> Warning: Object directory not changed from original /usr/ports/multimedia/webcamd/work/webcamd-0.1.0 >> cc -O2 -pipe -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/drivers/media/video/gspca -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux/include -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/v4l-dvb/linux -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0 -I/usr/ports/multimedia/webcamd/work/webcamd-0.1.0/dummy -DCONFIG_VIDEO_V4L1_COMPAT -DHAVE_WEBCAMD -include webcamd_global.h -O2 -Wall -Wno-pointer-sign -fvisibility=hidden -std=gnu99 -fstack-protector -c webcamd.c >> webcamd.c:37:23: error: video4bsd.h: No such file or directory >> webcamd.c:55: error: 'V4B_ALLOC_UNIT_MAX' undeclared here (not in a function) >> webcamd.c: In function 'main': >> webcamd.c:126: error: storage size of 'cmd' isn't known >> webcamd.c:176: error: 'V4B_DEVICES_MAX' undeclared (first use in this function) > >Do you have CFLAGS set in /etc/make.conf by chance? yup: #grep CFLAGS /etc/make.conf CFLAGS= -O2 -pipe -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 22:03:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B998A106566B; Tue, 19 Jan 2010 22:03:13 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1B2128FC14; Tue, 19 Jan 2010 22:03:12 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0JM0Ykm004457; Wed, 20 Jan 2010 08:30:34 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Wed, 20 Jan 2010 08:33:11 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 08:33:11 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 06:03:10 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0JLvYtF045481; Wed, 20 Jan 2010 05:57:34 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0JLvYAX045480; Wed, 20 Jan 2010 05:57:34 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 20 Jan 2010 05:57:34 +0800 From: "Wilkinson, Alex" To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100119215734.GD45270@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org References: <201001101437.37269.hselasky@c2i.net> <20100114090329.GH63408@citylink.fud.org.nz> <20100119091217.GR39820@stlux503.dsto.defence.gov.au> <201001191629.13323.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <201001191629.13323.hselasky@c2i.net> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 19 Jan 2010 22:03:10.0699 (UTC) FILETIME=[3068CBB0:01CA9953] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17142.000 X-TM-AS-Result: No--5.096000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:03:13 -0000 0n Tue, Jan 19, 2010 at 04:29:13PM +0100, Hans Petter Selasky wrote: >Please check /etc/make.conf and replace any CFLAGS= with CFLAGS+= Yup, that worked! Great! ===> Installing rc.d startup script(s) ===> Running ldconfig /sbin/ldconfig -m /usr/local/lib ===> Registering installation for webcamd-0.1.0 ===> Cleaning for webcamd-0.1.0 -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 22:07:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21FD4106566C; Tue, 19 Jan 2010 22:07:16 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id CC3068FC1B; Tue, 19 Jan 2010 22:07:15 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id o0JM7C3f045321; Tue, 19 Jan 2010 15:07:12 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> Date: Tue, 19 Jan 2010 15:07:12 -0700 Content-Transfer-Encoding: 7bit Message-Id: <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> References: <4B55D9D4.1000008@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1076) X-Spam-Status: No, score=-7.4 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:07:16 -0000 On Jan 19, 2010, at 9:12 AM, Alexander Motin wrote: > Hi. > > I've made a patch, that should solve set of problems of CAM ATA and > CAM > generally. I would like to ask for testing and feedback. > > What patch does: > - It unifies bus reset/probe sequence. Whenever bus attached at boot > or > later, CAM will automatically reset and scan it. It allows to remove > duplicate code from many drivers. > - Any bus, attached before CAM completed it's boot-time > initialization, > will equally join to the process, delaying boot if needed. > - New kern.cam.boot_delay loader tunable should help controllers that > are still unable to register their buses in time (such as slow USB/ > PCCard/ CardBus devices). I've fought many times against delay values like this. They never work well enough. Drivers that have delayed scans should set up their own intrhook to delay the boot until their scan is done. To help this out, CAM should move to its own hook that is guaranteed to run after the normal intrhooks. However, this isn't required. Here's my alternate proposal: - move xpt_config() execution to a new config hook that runs after the normal intrhooks. - For self identifying buses (i.e. anything where device presence is known to the controller), have the SIM notify CAM of each target device, instead of assuming that CAM will scan for it. - Teach USB and whatnot to use a confighook to drive their discovery, instead of estimated timeouts. I'm doing exactly this for the new MPT2SAS driver. Scott From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 02:48:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 618C5106566C for ; Wed, 20 Jan 2010 02:48:28 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id D2E8A8FC17 for ; Wed, 20 Jan 2010 02:48:27 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0K2jmM5024682; Wed, 20 Jan 2010 13:15:48 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Wed, 20 Jan 2010 13:18:26 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 13:18:26 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 10:48:22 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0K2gkTF046943; Wed, 20 Jan 2010 10:42:46 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0K2gjHh046942; Wed, 20 Jan 2010 10:42:45 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 20 Jan 2010 10:42:45 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Message-ID: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 20 Jan 2010 02:48:22.0295 (UTC) FILETIME=[07B72270:01CA997B] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17142.003 X-TM-AS-Result: No--7.620600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: code.google -> Xpra (anyone planning to port it ?) [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 02:48:28 -0000 Howdy people, This looks like a very nice app, has anyone got it working on FreeBSD yet ? http://code.google.com/p/partiwm/wiki/xpra -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 02:52:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6672106568B; Wed, 20 Jan 2010 02:52:33 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 572958FC17; Wed, 20 Jan 2010 02:52:32 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id o0K2qV3w020582; Wed, 20 Jan 2010 11:52:31 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id o0K2qXa29730; Wed, 20 Jan 2010 11:52:33 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla6) id o0K2qV0M028857; Wed, 20 Jan 2010 11:52:31 +0900 (JST) Received: from localhost by somla6.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0K2qPLI028626; Wed, 20 Jan 2010 11:52:25 +0900 (JST) Date: Wed, 20 Jan 2010 11:52:18 +0900 (JST) Message-Id: <20100120.115218.999284356098982813.okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org From: Kohji Okuno In-Reply-To: <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com> References: <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: okuno.kohji@jp.panasonic.com, freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 02:52:33 -0000 Hello, Attilio >>> I think setpriority() can set priority to sleeping threads. >>> Is it really safe? >> >> I agree, in this code path maybe_resched is not properly locking cur= thread. >> =A0curthread will be sched_lock and the sleeping thread will be a sl= eepq lock. >> =A0I believe that since &sched_lock is ordered after container locks= it would >> be sufficient to compare the two td_lock pointers and acquire sched_= lock if >> they are not equal. =A0Someone should look at other maybe_resched ca= llers or >> add an assert that curthread->td_lock is always &sched_lock in this >> function. > = > I'm not sure I understand you well here, but I generally don't agree,= > if we speak about the current code plus the patch I posted. I understood. If the current code plus your patch, meybe_resched() is no problem. I think, your patch is perfect if theare is no problem even if a sleeping thread sets &sched_lock to td->td_lock. Why do we call thread_lock_set() in sleepq_switch() and turnstile_wait(= )? = In case of sched_4bsd, is not thread_lock_set() needed? Thank you, Kohji Okuno. > Without the patch, there is a general problem of maybe_preempt() > because sched_switch() will handle TDF_NEEDRESCHED just in racy ways > (not ensuring atomicity of td_lock operations for sleeping threads). > That's, however, still not specific to maybe_preempt() only. However:= > * If you make a problem about the callers of maybe_resched() I agree.= > The callers should assert for sched_lock to be in place. But that is > not a general problem of maybe_resched(), it is on the callers > ballpark > * If you make a problem about the locking itself, the patch IMHO > should fix it or there is still something I can't see. > = > Thanks, > Attilio > = > = > -- = > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 04:05:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B58A1065670; Wed, 20 Jan 2010 04:05:14 +0000 (UTC) (envelope-from rabbit8888@gmail.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0448FC18; Wed, 20 Jan 2010 04:05:13 +0000 (UTC) Received: by iwn7 with SMTP id 7so3451547iwn.7 for ; Tue, 19 Jan 2010 20:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=vtH1PbsmsnC7b+GNW0sEcb620w9R4+svl2UNu5JKrYM=; b=MtLxpXFHv8gFxFCVdh9eW8t0V0aNvMudHEWyhQBkdezxztsXmNY2MqcqzKYvGMQS3P r6UGNV7u2+zMDNT/AidHIITOWYjVCUCqmnvEAQfCnVISBywLlpeUAlkb4dm/Lle79fEu /Wy6FMm/h8CtE2ID/yHetlJdt0VBdOSZO7NUo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=j5vwFgIHPz9EVukx92LSmzGPfGw7azKDJTX/lsO+0A29euUopgC+Cwi/wOqaIFSSFm j7DomQJFKWrnnYiWGZwfalfS5qH1s5o3w1OwXzRjUgasg53h57UpufVG9vwZhl9zer41 YTi+Jda1B9O5j7i5WoanWbGWMq9rV6KO4UMUA= MIME-Version: 1.0 Received: by 10.231.79.136 with SMTP id p8mr4332525ibk.4.1263958574111; Tue, 19 Jan 2010 19:36:14 -0800 (PST) In-Reply-To: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> References: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> From: ALIP BUDIANTO Date: Tue, 19 Jan 2010 18:35:54 -0900 Message-ID: <7ae8b1001191935kfa83502m2c50e66dc7a3e38d@mail.gmail.com> To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: code.google -> Xpra (anyone planning to port it ?) [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 04:05:14 -0000 On Tue, Jan 19, 2010 at 5:42 PM, Wilkinson, Alex < alex.wilkinson@dsto.defence.gov.au> wrote: > Howdy people, > > This looks like a very nice app, has anyone got it working on FreeBSD yet ? > > http://code.google.com/p/partiwm/wiki/xpra > > -Alex > > IMPORTANT: This email remains the property of the Australian Defence > Organisation and is subject to the jurisdiction of section 70 of the CRIMES > ACT 1914. If you have received this email in error, you are requested to > contact the sender and delete the email. > > _______________________________________________ > 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" > Woah I never thought a application like this ever existed! Should really go in trunk due to the usefullness and beta status :( . From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 06:52:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B47A4106566B; Wed, 20 Jan 2010 06:52:00 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 17A448FC20; Wed, 20 Jan 2010 06:51:59 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0K6nK3k008129; Wed, 20 Jan 2010 17:19:20 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Wed, 20 Jan 2010 17:21:58 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 17:21:58 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 14:51:57 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0K6kK0n047815; Wed, 20 Jan 2010 14:46:20 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0K6kKeB047814; Wed, 20 Jan 2010 14:46:20 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 20 Jan 2010 14:46:20 +0800 From: "Wilkinson, Alex" To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100120064620.GJ46479@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org References: <201001101437.37269.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <201001101437.37269.hselasky@c2i.net> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 20 Jan 2010 06:51:57.0576 (UTC) FILETIME=[0F1A0880:01CA999D] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17142.005 X-TM-AS-Result: No--11.677200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 06:52:00 -0000 0n Sun, Jan 10, 2010 at 02:37:37PM +0100, Hans Petter Selasky wrote: >During the last couple of days I've spent some time to finish my webcam >daemon. My webcam daemon is basically an application which consists of >userspace Video4Linux USB webcam drivers and some uLinux glue code which links >with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX which >is provided by the video4bsd kernel module. There is full support for >mmap/read/write/open/close. poll is not supported. OK, after all the wresting i have it working! Great stuff Hans and Andrew! attaches as: kernel: ugen7.2: at usbus7 And works dam well. What apps could i expect this to work with in the future ? skype ? -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 07:29:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE29C106566B; Wed, 20 Jan 2010 07:29:30 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2EB8FC17; Wed, 20 Jan 2010 07:29:29 +0000 (UTC) Received: by fxm27 with SMTP id 27so4262784fxm.3 for ; Tue, 19 Jan 2010 23:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=JOfDSkhhB5roFhqWDu9cB8XzbbKalwDJiIKcpNdr9k4=; b=dKerXfj0GuiFCDDwh+LQx6MeDG7QUFmDSzQ7AJ2L/5F4vTbkDhaDj9XTa1nxlNGZ+a Jeh5/9BIqG2xaBConAgVHKRYbddogXfjgxFMQfQUlxpWZXfVsnYhO+0pMFHZVvTxI+Ib 8BcZ8zEuKBl4T8z8T2rsJVrnHzVvm6pUFq3/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Oj3FsakP6fU5vxUSwn+X5BWV8/MgBQwUVbrqj41PN/0L94V53WMG88xY4BgftR+Os/ IKqvjxk7yWDoxtJ0Ga6eFeI2DPTFX43yPqHv4xq6No8fJnxbiVXW9pJT/XBOoWp158/r Y7Dy3br7WzeGFQDDqh3ObfQmrN3iqvHB5QLBc= Received: by 10.223.68.155 with SMTP id v27mr7514453fai.10.1263972568709; Tue, 19 Jan 2010 23:29:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm3492966fxm.1.2010.01.19.23.29.27 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 23:29:28 -0800 (PST) Sender: Alexander Motin Message-ID: <4B56B0D6.1000402@FreeBSD.org> Date: Wed, 20 Jan 2010 09:29:26 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Scott Long References: <4B55D9D4.1000008@FreeBSD.org> <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> In-Reply-To: <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 07:29:30 -0000 Scott Long wrote: > On Jan 19, 2010, at 9:12 AM, Alexander Motin wrote: >> I've made a patch, that should solve set of problems of CAM ATA and CAM >> generally. I would like to ask for testing and feedback. >> >> What patch does: >> - It unifies bus reset/probe sequence. Whenever bus attached at boot or >> later, CAM will automatically reset and scan it. It allows to remove >> duplicate code from many drivers. >> - Any bus, attached before CAM completed it's boot-time initialization, >> will equally join to the process, delaying boot if needed. >> - New kern.cam.boot_delay loader tunable should help controllers that >> are still unable to register their buses in time (such as slow USB/ >> PCCard/ CardBus devices). > > I've fought many times against delay values like this. They never work > well enough. Drivers that have delayed scans should set up their own > intrhook to delay the boot until their scan is done. To help this out, > CAM should move to its own hook that is guaranteed to run after the > normal intrhooks. However, this isn't required. I am sure that using delay is not a perfect solution, but it nicely fits new scanning procedure and costs just a few lines of code. Nobody denies to add _more_ events to wait there. This is just a band-aid for cases when nothing else helps. May be I am mixing something, but AFAIR there were some USB devices, which doesn't appear on a first bus scan, but register later. > Here's my alternate proposal: > > - move xpt_config() execution to a new config hook that runs after the > normal intrhooks. To make scanning work in background, it is better to call xpt_config() same as now, as early as possible, to start scanning for already registered buses, but call xpt_release_boot() on some later event (or even several different events). > - For self identifying buses (i.e. anything where device presence is > known to the controller), have the SIM notify CAM of each target device, > instead of assuming that CAM will scan for it. Nobody denies your driver to call xpt_rescan on per-known-device basis. In such case CAM will still wait until all of your scan requests will be fulfilled. You may see it is already done by some SIMs and PMP driver. If you need a way to avoid full scan, it also can be done, while it is separate question. > - Teach USB and whatnot to use a confighook to drive their discovery, > instead of estimated timeouts. > > I'm doing exactly this for the new MPT2SAS driver. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 08:43:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83A39106568B; Wed, 20 Jan 2010 08:43:06 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 269D88FC0C; Wed, 20 Jan 2010 08:43:05 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0K8eQCe025487; Wed, 20 Jan 2010 19:10:26 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Wed, 20 Jan 2010 19:13:04 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 19:13:04 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 16:43:03 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0K8bQAb048205; Wed, 20 Jan 2010 16:37:26 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0K8bQ5R048204; Wed, 20 Jan 2010 16:37:26 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 20 Jan 2010 16:37:26 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Message-ID: <20100120083726.GK46479@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 20 Jan 2010 08:43:03.0873 (UTC) FILETIME=[94863B10:01CA99AC] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17142.006 X-TM-AS-Result: No--20.785700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: multimedia/libv4l/ (video4bsd.ko) -> Fatal trap 12: page fault while in kernel mode [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 08:43:06 -0000 The following ports initially installed and worked fine: multimedia/libv4l multimedia/webcamd multimedia/pwcview however, after a reboot video4bsd.ko panic'd my machine and i was unable to boot. I had to use the LiveFS to rescue the box. Here is the bt from DDB: FreeBSD 9.0-CURRENT #0 r202270: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 458752K of memory above 4GB ignored Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010 WARNING: WITNESS option enabled, expect reduced performance. Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex cdev (cdev) r = 0 (0xc0df5bd8) locked @ /usr/src/sys/kern/kern_conf.c:72 KDB: stack backtrace: db_trace_self_wrapper(c0c9e3fb,c1c20b7c,c08d5375,c0c94c4e,48,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0c94c4e,48,ffffffff,c0f3814c,c1c20bb4,...) at kdb_backtrace+0x29 _witness_debugger(c0ca08bd,c1c20bc8,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cd5368,c1c20ce8,c0df5540,...) at witness_warn+0x1fd trap(c1c20c54) at trap+0x19e calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc087f1c3, esp = 0xc1c20c94, ebp = 0xc1c20ca4 --- _mtx_assert(f000fea5,4,c0ca03dd,240,0,...) at _mtx_assert+0x53 alloc_unrl(0,4,c0c8fa0e,202,c7952000,...) at alloc_unrl+0x2f devfs_create(c7952000,40,20,c1bb1a3a,c1c20d60,...) at devfs_create+0x42 make_dev_credv(0,0,5,1a4,c1bb1a3a,...) at make_dev_credv+0x103 make_dev(c1bb2000,0,0,5,1a4,...) at make_dev+0x43 v4b_init(0,1c1ec00,1c1ec00,1c1e000,1c25000,...) at v4b_init+0x7b mi_startup() at mi_startup+0x96 begin() at begin+0x2c Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xf000feb5 fault code = supervisor read, page not present instruction pointer = 0x20:0xc087f1c3 stack pointer = 0x28:0xc1c20c94 frame pointer = 0x28:0xc1c20ca4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 () [thread pid 0 tid 0 ] Stopped at _mtx_assert+0x53: movl 0x10(%edx),%eax db> bt Tracing pid 0 tid 0 td 0xc0df57f0 _mtx_assert(f000fea5,4,c0ca03dd,240,0,...) at _mtx_assert+0x53 alloc_unrl(0,4,c0c8fa0e,202,c7952000,...) at alloc_unrl+0x2f devfs_create(c7952000,40,20,c1bb1a3a,c1c20d60,...) at devfs_create+0x42 make_dev_credv(0,0,5,1a4,c1bb1a3a,...) at make_dev_credv+0x103 make_dev(c1bb2000,0,0,5,1a4,...) at make_dev+0x43 v4b_init(0,1c1ec00,1c1ec00,1c1e000,1c25000,...) at v4b_init+0x7b mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> It was to early in the bootstrap process to get a core dump (call doadump). i.e. "no dumpdev available" message. -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 08:58:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BACA1065672 for ; Wed, 20 Jan 2010 08:58:36 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BA3CF8FC17 for ; Wed, 20 Jan 2010 08:58:35 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NXWOV-0006i5-3p for freebsd-current@freebsd.org; Wed, 20 Jan 2010 09:58:31 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jan 2010 09:58:31 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jan 2010 09:58:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 20 Jan 2010 09:58:14 +0100 Lines: 8 Message-ID: References: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> Sender: news Cc: freebsd-x11@freebsd.org Subject: Re: code.google -> Xpra (anyone planning to port it ?) [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 08:58:36 -0000 On 01/20/10 03:42, Wilkinson, Alex wrote: > Howdy people, > > This looks like a very nice app, has anyone got it working on FreeBSD yet ? > > http://code.google.com/p/partiwm/wiki/xpra x11vnc works reasonably good :) From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 09:05:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37CCC106566B; Wed, 20 Jan 2010 09:05:28 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8FEED8FC1D; Wed, 20 Jan 2010 09:05:27 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0K92leV028470; Wed, 20 Jan 2010 19:32:47 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Wed, 20 Jan 2010 19:35:25 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 19:35:25 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 17:05:24 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0K8xlCw048368; Wed, 20 Jan 2010 16:59:47 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0K8xl2i048367; Wed, 20 Jan 2010 16:59:47 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 20 Jan 2010 16:59:47 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Message-ID: <20100120085947.GA48329@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 20 Jan 2010 09:05:24.0420 (UTC) FILETIME=[B38D7840:01CA99AF] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17142.006 X-TM-AS-Result: No--5.578600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: code.google -> Xpra (anyone planning to port it ?) [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 09:05:28 -0000 0n Wed, Jan 20, 2010 at 09:58:14AM +0100, Ivan Voras wrote: >On 01/20/10 03:42, Wilkinson, Alex wrote: >> Howdy people, >> >> This looks like a very nice app, has anyone got it working on FreeBSD yet ? >> >> http://code.google.com/p/partiwm/wiki/xpra > >x11vnc works reasonably good :) true. but this still looks great :) -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 09:14:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DF15106566C; Wed, 20 Jan 2010 09:14:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id D2B368FC15; Wed, 20 Jan 2010 09:14:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=2_RHiNPu7QwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=MJPGnJ_TKvrAjsQp_30A:9 a=TJrprNxoB2apuwS68PX6bVBhw3IA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1329321292; Wed, 20 Jan 2010 10:14:33 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 20 Jan 2010 10:13:07 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <20100120083726.GK46479@stlux503.dsto.defence.gov.au> In-Reply-To: <20100120083726.GK46479@stlux503.dsto.defence.gov.au> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001201013.07894.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org, "Wilkinson, Alex" Subject: Re: multimedia/libv4l/ (video4bsd.ko) -> Fatal trap 12: page fault while in kernel mode [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 09:14:36 -0000 On Wednesday 20 January 2010 09:37:26 Wilkinson, Alex wrote: > The following ports initially installed and worked fine: > > multimedia/libv4l > multimedia/webcamd > multimedia/pwcview > > however, after a reboot video4bsd.ko panic'd my machine and i was unable to > boot. I had to use the LiveFS to rescue the box. Here is the bt from DDB: > This issue is fixed. Just update the ports. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 09:37:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 617941065672 for ; Wed, 20 Jan 2010 09:37:27 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 1CA528FC12 for ; Wed, 20 Jan 2010 09:37:26 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 9A97814DA30B; Wed, 20 Jan 2010 10:20:27 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cnwwpdR6YB7c; Wed, 20 Jan 2010 10:20:17 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 3668214DA2FD; Wed, 20 Jan 2010 10:20:17 +0100 (CET) Message-ID: <4B56CACF.50508@FreeBSD.org> Date: Wed, 20 Jan 2010 10:20:15 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Kostik Belousov References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> In-Reply-To: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: attilio@freebsd.org, current@freebsd.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 09:37:27 -0000 El 2010. 01. 19. 22:20, Kostik Belousov escribió: > Hi, > r189765 enabled NLS support for libc. Now, any strerror(3) call causes > 4 (!) failing stat(2) calls. I think this is untolerable. > > Catopen() does not cache the catalog descriptor, at least for libc, > at least for the case where the open failed. > Hi Kostik, thank you for pointing this out. I'll check the code to see how we could add a caching for the failing catalogs. I'll post the patch here when I'm done. Regards, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 10:01:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FA64106566B for ; Wed, 20 Jan 2010 10:01:33 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 997E18FC18 for ; Wed, 20 Jan 2010 10:01:32 +0000 (UTC) Received: by fxm27 with SMTP id 27so4366381fxm.3 for ; Wed, 20 Jan 2010 02:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=+IoG2ENZzHTR7s6PW+MeU8eqq8NFvyJ8zCDm3FmVpKc=; b=lR5BClX0X+WVSJxOKVIxFl/C8xJ4skCXtaA2Vr910K8CmwrJeO6Uz0DoTjZBRxs6T/ E+WhuNDjC2o5k75Fobc4gpbmdtVz2NiaofOYSS3EqjdgcBLz2Zd2PwUVQ33KvGiVizqK lCZDwTykFEEMjqZYdaBIkihNqGuOareiZin4o= 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; b=O7EU0VKB8vREWTKb7VxzEpdXHtwXbDyCWunMchOb3ndjWwIZSkf8qAIeifV1w6rwzN K6P6nRi8hWtioRiZ3qfCdbrAg/f1Q/XGHlxF6ey/WGzCPtkzJK0UrDv5AdAU52osIuBd b6QX+0IpcdzEDZToOnVOeaCHeze4J9pfmYCjw= MIME-Version: 1.0 Received: by 10.223.5.90 with SMTP id 26mr10470678fau.59.1263981691513; Wed, 20 Jan 2010 02:01:31 -0800 (PST) In-Reply-To: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> Date: Wed, 20 Jan 2010 11:01:31 +0100 Message-ID: <4e6cba831001200201m2ff9def8i2b6f72091a91eeee@mail.gmail.com> From: Giovanni Trematerra To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 10:01:33 -0000 On Mon, Jan 18, 2010 at 3:58 AM, Attilio Rao wrote: > 2010/1/17 Kohji Okuno : >> Hello, >> >> Could you check sched_4bsd.patch, please? > > I think, instead, that what needs to happen is to have sched_switch() > to do a lock handover from sleepq/turnstile spinlock to schedlock. > That way, if threads are willing to contest on td_lock they will be > still inhibited. > I'm not sure if this patch breaks any invariant, if you may test I > would appreciate: > http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff > > Reviews and comments are appreciated. > BTW, nice catch. > > Attilio > I stressed an 8-core machine with pho's stress2 kernel stress suite and your patch seems to break the invariant THREAD_LOCKPTR_ASSERT in turnstile_claim:subr_turnstile.c The relevant stack trace are: Tracing command creat pid 79098 tid 100624 td 0xc8c59af0 kdb_enter(c0c9b0d1,c0c9b0d1,c0c9f546,e978a85c,1,...) at kdb_enter+0x3a panic(c0c9f546,c9633af0,c0dfc024,c9d3e280,c0f5bd3c,...) at panic+0x136 turnstile_claim(c9d3e280,2,c0ca7376,1f0,4,...) at turnstile_claim+0x148 _rw_try_upgrade(c0f5bd3c,c0ca7376,1f0,e978a990,e978ab88,...) at _rw_try_upgrade+0xe6 cache_lookup(c99e9bb0,e978ab74,e978ab88,0,0,...) at cache_lookup+0x362 nfs_lookup(e978aa50,e978aa50,e978ab5c,200000,e978ab5c,...) at nfs_lookup+0xf6 VOP_LOOKUP_APV(c0da5fe0,e978aa50,e978ab88,1f1,e978ab74,...) at VOP_LOOKUP_APV+0xa5 lookup(e978ab5c,c0ca7aea,ea,c5,cc093d48,...) at lookup+0x66b namei(e978ab5c,c08d3aab,c0c94c96,c0c92df9,3,...) at namei+0x55f kern_statat_vnhook(c8c59af0,0,ffffff9c,bfbfdf78,0,...) at kern_statat_vnhook+0x72 kern_statat(c8c59af0,0,ffffff9c,bfbfdf78,0,...) at kern_statat+0x3c kern_stat(c8c59af0,bfbfdf78,0,e978ac18,2,...) at kern_stat+0x36 stat(c8c59af0,e978acf8,8,c0ca19f2,c0d88230,...) at stat+0x2f syscall(e978ad38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip = 0x2817d1a3, esp = 0xbfbfdecc, ebp = 0xbfbfe388 --- Tracing command creat pid 79122 tid 100202 td 0xc9633af0 sched_switch(c9633af0,0,103,18c,48fb36ba,...) at sched_switch+0x1c5 mi_switch(103,0,c0c9fc0e,2e2,c9d3e280,...) at mi_switch+0x200 turnstile_wait(c9d3e280,0,0,c0f5bd3c,c0f2cb10,...) at turnstile_wait+0x495 _rw_wlock_hard(c0f5bd3c,c9633af0,c0ca7376,209,0,...) at _rw_wlock_hard+0x20c _rw_wlock(c0f5bd3c,c0ca7376,209,e9147990,e9147b88,...) at _rw_wlock+0xae cache_lookup(c99e9aa0,e9147b74,e9147b88,0,0,...) at cache_lookup+0x46f nfs_lookup(e9147a50,e9147a50,e9147b5c,200000,e9147b5c,...) at nfs_lookup+0xf6 VOP_LOOKUP_APV(c0da5fe0,e9147a50,e9147b88,1f1,e9147b74,...) at VOP_LOOKUP_APV+0xa5 lookup(e9147b5c,c0ca7aea,ea,c5,c962caa0,...) at lookup+0x66b namei(e9147b5c,c08d3aab,c0c94c96,c0c92df9,3,...) at namei+0x55f kern_statat_vnhook(c9633af0,0,ffffff9c,bfbfdf78,0,...) at kern_statat_vnhook+0x72 kern_statat(c9633af0,0,ffffff9c,bfbfdf78,0,...) at kern_statat+0x3c kern_stat(c9633af0,bfbfdf78,0,e9147c18,2,...) at kern_stat+0x36 stat(c9633af0,e9147cf8,8,c0c828f4,c0d88230,...) at stat+0x2f syscall(e9147d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip = 0x2817d1a3, esp = 0xbfbfdecc, ebp = 0xbfbfe388 --- What seems to happen to me is: The thread 0xc8c59af0 sleeps on the turnstile queue by a previous call to turnstile_wait. The thread 0xc9633af0 call turnstile_wait and does a voluntary switch. The call to thread_lock_set added from your patch to sched_switch, wakes up the thread 0xc8c59af0 and while thread 0xc9633af0 is in the middle of sched_switch (so before cpu_switch), thread 0xc8c59af0 is running turnstile_claim that discover the thread 0xc9633af0 not hold a turnstile lock by THREAD_LOCKPTR_ASSERT invariant assertion. If needed I have the coredump and the entire stack trace. Hope this help. -- Gianni From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 07:32:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA5D71065692; Wed, 20 Jan 2010 07:32:46 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 221C38FC45; Wed, 20 Jan 2010 07:32:44 +0000 (UTC) Received: by fxm27 with SMTP id 27so4264426fxm.3 for ; Tue, 19 Jan 2010 23:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6FQQya69mzfN6ExKaflkFrsvYE7ZIqy2cqNO5Sf0ibs=; b=msWSdLL4vFE6xw6D5tddHWSVZCSPcC010IxnS7sDt8VuvTRrQ44T11T4pbWOcS8zOx 4M8NPeblIt5CTfdEDAhneGWsZqEN8ZgFRPoAsnfmcFGXb/qcMGLTMht9sHmlvrU6xdWU ucoTc0X3KwL30QqTg4wnqGaqR/mpoF/fV7HcY= 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=eMxWLl3a5PfFpIoK79q5JCKNzvgfK0iUBe0ZG5MuAYsb8Bd5SzGuAjranucYxrPiZW 7sHeU2KxEBnFui4QyMA+JwckOGvkk1afklXl7gmTWMECV2JifGRargeM/eZUnNW307EM 8dodHPjSz6S8Ka5/IOJ2sRc3tjGUBoLfCx6+0= MIME-Version: 1.0 Received: by 10.223.4.132 with SMTP id 4mr765077far.90.1263972763332; Tue, 19 Jan 2010 23:32:43 -0800 (PST) In-Reply-To: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> Date: Wed, 20 Jan 2010 08:32:43 +0100 Message-ID: <4e6cba831001192332j1e23bb1chdf2f47664d3cb14a@mail.gmail.com> From: Giovanni Trematerra To: Attilio Rao Content-Type: multipart/mixed; boundary=000e0cd1ff3e9073f6047d93971d X-Mailman-Approved-At: Wed, 20 Jan 2010 12:26:55 +0000 Cc: Jeff Roberson , freebsd-current@freebsd.org, Kohji Okuno Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 07:32:47 -0000 --000e0cd1ff3e9073f6047d93971d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 18, 2010 at 3:58 AM, Attilio Rao wrote: > 2010/1/17 Kohji Okuno : >> Hello, >> >> Could you check sched_4bsd.patch, please? > > I think, instead, that what needs to happen is to have sched_switch() > to do a lock handover from sleepq/turnstile spinlock to schedlock. > That way, if threads are willing to contest on td_lock they will be > still inhibited. > I'm not sure if this patch breaks any invariant, if you may test I > would appreciate: > http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff I stressed an 8-core machine with pho's stress2 kernel stress suite and your patch seems to break the invariant THREAD_LOCKPTR_ASSERT in turnstile_claim:subr_turnstile.c The relevant stack trace are: Tracing command creat pid 79098 tid 100624 td 0xc8c59af0 kdb_enter(c0c9b0d1,c0c9b0d1,c0c9f546,e978a85c,1,...) at kdb_enter+0x3a panic(c0c9f546,c9633af0,c0dfc024,c9d3e280,c0f5bd3c,...) at panic+0x136 turnstile_claim(c9d3e280,2,c0ca7376,1f0,4,...) at turnstile_claim+0x148 _rw_try_upgrade(c0f5bd3c,c0ca7376,1f0,e978a990,e978ab88,...) at _rw_try_upgrade+0xe6 cache_lookup(c99e9bb0,e978ab74,e978ab88,0,0,...) at cache_lookup+0x362 nfs_lookup(e978aa50,e978aa50,e978ab5c,200000,e978ab5c,...) at nfs_lookup+0xf6 VOP_LOOKUP_APV(c0da5fe0,e978aa50,e978ab88,1f1,e978ab74,...) at VOP_LOOKUP_APV+0xa5 lookup(e978ab5c,c0ca7aea,ea,c5,cc093d48,...) at lookup+0x66b namei(e978ab5c,c08d3aab,c0c94c96,c0c92df9,3,...) at namei+0x55f kern_statat_vnhook(c8c59af0,0,ffffff9c,bfbfdf78,0,...) at kern_statat_vnhook+0x72 kern_statat(c8c59af0,0,ffffff9c,bfbfdf78,0,...) at kern_statat+0x3c kern_stat(c8c59af0,bfbfdf78,0,e978ac18,2,...) at kern_stat+0x36 stat(c8c59af0,e978acf8,8,c0ca19f2,c0d88230,...) at stat+0x2f syscall(e978ad38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip = 0x2817d1a3, esp = 0xbfbfdecc, ebp = 0xbfbfe388 --- Tracing command creat pid 79122 tid 100202 td 0xc9633af0 sched_switch(c9633af0,0,103,18c,48fb36ba,...) at sched_switch+0x1c5 mi_switch(103,0,c0c9fc0e,2e2,c9d3e280,...) at mi_switch+0x200 turnstile_wait(c9d3e280,0,0,c0f5bd3c,c0f2cb10,...) at turnstile_wait+0x495 _rw_wlock_hard(c0f5bd3c,c9633af0,c0ca7376,209,0,...) at _rw_wlock_hard+0x20c _rw_wlock(c0f5bd3c,c0ca7376,209,e9147990,e9147b88,...) at _rw_wlock+0xae cache_lookup(c99e9aa0,e9147b74,e9147b88,0,0,...) at cache_lookup+0x46f nfs_lookup(e9147a50,e9147a50,e9147b5c,200000,e9147b5c,...) at nfs_lookup+0xf6 VOP_LOOKUP_APV(c0da5fe0,e9147a50,e9147b88,1f1,e9147b74,...) at VOP_LOOKUP_APV+0xa5 lookup(e9147b5c,c0ca7aea,ea,c5,c962caa0,...) at lookup+0x66b namei(e9147b5c,c08d3aab,c0c94c96,c0c92df9,3,...) at namei+0x55f kern_statat_vnhook(c9633af0,0,ffffff9c,bfbfdf78,0,...) at kern_statat_vnhook+0x72 kern_statat(c9633af0,0,ffffff9c,bfbfdf78,0,...) at kern_statat+0x3c kern_stat(c9633af0,bfbfdf78,0,e9147c18,2,...) at kern_stat+0x36 stat(c9633af0,e9147cf8,8,c0c828f4,c0d88230,...) at stat+0x2f syscall(e9147d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip = 0x2817d1a3, esp = 0xbfbfdecc, ebp = 0xbfbfe388 --- What seems to happen to me is: The thread 0xc8c59af0 sleeps on the turnstile queue by a previous call to turnstile_wait. The thread 0xc9633af0 call turnstile_wait and does a voluntary switch. The call to thread_lock_set added from your patch to sched_switch, wakes up the thread 0xc8c59af0 and while thread 0xc9633af0 is in the middle of sched_switch (so before cpu_switch), thread 0xc8c59af0 is running turnstile_claim that discover the thread 0xc9633af0 not hold a turnstile lock by THREAD_LOCKPTR_ASSERT invariant assertion. I attached the entire stack trace. If needed I have the coredump. Hope this help. -- Gianni --000e0cd1ff3e9073f6047d93971d Content-Type: text/plain; charset=US-ASCII; name="attilio_4bsd.txt" Content-Disposition: attachment; filename="attilio_4bsd.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g4nsc2wj0 U2NyaXB0IHN0YXJ0ZWQgb24gVHVlIEphbiAxOSAxMzowMDowMyAyMDEwCltFbnRlciBgXkVjPycg Zm9yIGhlbHBdCltva10KCmRiPiBidApUcmFjaW5nIHBpZCA3OTA5OCB0aWQgMTAwNjI0IHRkIDB4 YzhjNTlhZjAKa2RiX2VudGVyKGMwYzliMGQxLGMwYzliMGQxLGMwYzlmNTQ2LGU5NzhhODVjLDEs Li4uKSBhdCBrZGJfZW50ZXIrMHgzYQpwYW5pYyhjMGM5ZjU0NixjOTYzM2FmMCxjMGRmYzAyNCxj OWQzZTI4MCxjMGY1YmQzYywuLi4pIGF0IHBhbmljKzB4MTM2CnR1cm5zdGlsZV9jbGFpbShjOWQz ZTI4MCwyLGMwY2E3Mzc2LDFmMCw0LC4uLikgYXQgdHVybnN0aWxlX2NsYWltKzB4MTQ4Cl9yd190 cnlfdXBncmFkZShjMGY1YmQzYyxjMGNhNzM3NiwxZjAsZTk3OGE5OTAsZTk3OGFiODgsLi4uKSBh dCBfcndfdHJ5X3VwZ3JhZGUrMHhlNgpjYWNoZV9sb29rdXAoYzk5ZTliYjAsZTk3OGFiNzQsZTk3 OGFiODgsMCwwLC4uLikgYXQgY2FjaGVfbG9va3VwKzB4MzYyCm5mc19sb29rdXAoZTk3OGFhNTAs ZTk3OGFhNTAsZTk3OGFiNWMsMjAwMDAwLGU5NzhhYjVjLC4uLikgYXQgbmZzX2xvb2t1cCsweGY2 ClZPUF9MT09LVVBfQVBWKGMwZGE1ZmUwLGU5NzhhYTUwLGU5NzhhYjg4LDFmMSxlOTc4YWI3NCwu Li4pIGF0IFZPUF9MT09LVVBfQVBWKzB4YTUKbG9va3VwKGU5NzhhYjVjLGMwY2E3YWVhLGVhLGM1 LGNjMDkzZDQ4LC4uLikgYXQgbG9va3VwKzB4NjZiCm5hbWVpKGU5NzhhYjVjLGMwOGQzYWFiLGMw Yzk0Yzk2LGMwYzkyZGY5LDMsLi4uKSBhdCBuYW1laSsweDU1ZgprZXJuX3N0YXRhdF92bmhvb2so YzhjNTlhZjAsMCxmZmZmZmY5YyxiZmJmZGY3OCwwLC4uLikgYXQga2Vybl9zdGF0YXRfdm5ob29r KzB4NzIKa2Vybl9zdGF0YXQoYzhjNTlhZjAsMCxmZmZmZmY5YyxiZmJmZGY3OCwwLC4uLikgYXQg a2Vybl9zdGF0YXQrMHgzYwprZXJuX3N0YXQoYzhjNTlhZjAsYmZiZmRmNzgsMCxlOTc4YWMxOCwy LC4uLikgYXQga2Vybl9zdGF0KzB4MzYKc3RhdChjOGM1OWFmMCxlOTc4YWNmOCw4LGMwY2ExOWYy LGMwZDg4MjMwLC4uLikgYXQgc3RhdCsweDJmCnN5c2NhbGwoZTk3OGFkMzgpIGF0IHN5c2NhbGwr MHgyYTMKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lz Y2FsbCAoMTg4LCBGcmVlQlNEIEVMRjMyLCBzdGF0KSwgZWlwID0gMHgyODE3ZDFhMywgZXNwID0g MHhiZmJmZGVjYywgZWJwID0gMHhiZmJmZTM4OCAtLS0KZGI+IHNob3cgYWxsbG9ja3MKUHJvY2Vz cyA3OTEyMiAoY3JlYXQpIHRocmVhZCAweGM5NjMzYWYwICgxMDAyMDIpCnNoYXJlZCBsb2NrbWdy IG5mcyAobmZzKSByID0gMCAoMHhjOTllOWFmOCkgbG9ja2VkIEAgL3pvby9naWFubmkvdGVzdGJv eC9zeXMva2Vybi92ZnNfc3Vici5jOjIwOTEKUHJvY2VzcyA3OTEwNCAodGhyMSkgdGhyZWFkIDB4 YzlkYWU2OTAgKDEwMDMwNSkKZXhjbHVzaXZlIHNsZWVwIG11dGV4IHByb2Nlc3MgbG9jayAocHJv Y2VzcyBsb2NrKSByID0gMCAoMHhjOWMxNWRkMCkgbG9ja2VkIEAgL3pvby9naWFubmkvdGVzdGJv eC9zeXMva2Vybi9rZXJuX3Roci5jOjIzMQpQcm9jZXNzIDc5MDk4IChjcmVhdCkgdGhyZWFkIDB4 YzhjNTlhZjAgKDEwMDYyNCkKc2hhcmVkIHJ3IE5hbWUgQ2FjaGUgKE5hbWUgQ2FjaGUpIHIgPSAw ICgweGMwZjViZDNjKSBsb2NrZWQgQCAvem9vL2dpYW5uaS90ZXN0Ym94L3N5cy9rZXJuL3Zmc19j YWNoZS5jOjM5MApzaGFyZWQgbG9ja21nciBuZnMgKG5mcykgciA9IDAgKDB4Yzk5ZTljMDgpIGxv Y2tlZCBAIC96b28vZ2lhbm5pL3Rlc3Rib3gvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMDkxCmRiPiBw cwogIHBpZCAgcHBpZCAgcGdycCAgIHVpZCAgIHN0YXRlICAgd21lc2cgICAgIHdjaGFuICAgIGNt ZAo3OTE0NiAgIDk3NiAgIDk3NiAgICAgMCAgUiAgICAgICAgICAgICAgICAgICAgICAgICAgIHN5 c2xvZ2QKNzkxNDUgICA5NzYgICA5NzYgICAgIDAgIFIgICAgICAgICAgICAgICAgICAgICAgICAg ICBzeXNsb2dkCjc5MTM3IDc5MDkyICAzNTQ1ICAgICAwICBSKyAgICAgICAgICAgICAgICAgICAg ICAgICAgY3JlYXQKNzkxMzYgNzkwOTIgIDM1NDUgICAgIDAgIFIrICAgICAgICAgICAgICAgICAg ICAgICAgICBjcmVhdAo3OTEzNCA3OTA5MiAgMzU0NSAgICAgMCAgUisgICAgICAgICAgICAgICAg ICAgICAgICAgIGNyZWF0Cjc5MTMyIDc5MDkyICAzNTQ1ICAgICAwICBSKyAgICAgICAgICAgICAg ICAgICAgICAgICAgY3JlYXQKNzkxMzAgNzkwOTIgIDM1NDUgICAgIDAgIFIrICAgICAgICAgICAg ICAgICAgICAgICAgICBjcmVhdAo3OTEyOCA3OTA5MiAgMzU0NSAgICAgMCAgUisgICAgICAgICAg ICAgICAgICAgICAgICAgIGNyZWF0Cjc5MTI2IDc5MDkyICAzNTQ1ICAgICAwICBSKyAgICAgIENQ VSAwICAgICAgICAgICAgICAgY3JlYXQKNzkxMjQgNzkwOTIgIDM1NDUgICAgIDAgIFIrICAgICAg ICAgICAgICAgICAgICAgICAgICBjcmVhdAo3OTEyMiA3OTA5MiAgMzU0NSAgICAgMCAgTCsgICAg ICpOYW1lIENhYyAweGM5ZDNlMjgwIGNyZWF0Cjc5MTIwIDc5MDkyICAzNTQ1ICAgICAwICBSKyAg ICAgICAgICAgICAgICAgICAgICAgICAgY3JlYXQKNzkxMTggNzkwOTIgIDM1NDUgICAgIDAgIFIr ICAgICAgICAgICAgICAgICAgICAgICAgICBjcmVhdAo3OTExNiA3OTA4NyAgMzU0NSAgICAgMCAg UisgICAgICAodGhyZWFkZWQpICAgICAgICAgIHRocjEKMTAxMjU1ICAgICAgICAgICAgICAgICAg IFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTUyMCAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1MTMgICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAwMjc5ICAgICAgICAgICAgICAg ICAgIFMgICAgICAgdXdhaXQgICAgMHhjOGQ2OTY4MCB0aHIxCjc5MTE1IDc5MDkyICAzNTQ1ICAg ICAwICBSKyAgICAgIENQVSAzICAgICAgICAgICAgICAgY3JlYXQKLS1Nb3JlLS0gICAgICAgIDc5 MTEzIDc5MDkyICAzNTQ1ICAgICAwICBSKyAgICAgICAgICAgICAgICAgICAgICAgICAgY3JlYXQK NzkxMTEgNzkwODcgIDM1NDUgICAgIDAgIFIrICAgICAgKHRocmVhZGVkKSAgICAgICAgICB0aHIx CjEwMTQ1NSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDE0NDggICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxNDM5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTQzMiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDE0MjQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKMTAxNDE2ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICB0aHIxCjEwMTQxMCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAg ICAgdGhyMQoxMDE0MDMgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIHRocjEKMTAxMzk2ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAg ICAgICB0aHIxCjEwMTM4OSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAg ICAgICAgdGhyMQoxMDEzODAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxMzczICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTM3MCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDEzNjMgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxMzU3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCjEwMTM1MCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAg ICAgICAgICAgICAgdGhyMQoxMDEzMTYgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAg ICAgICAgICAgICAgIHRocjEKMTAxMzQyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCi0tTW9yZS0tICAgICAgICAxMDEzNDAgICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjk0ICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIzMiAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNjggICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMTk2ICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTE5NyAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzMzggICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzMzICAgICAgICAg ICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTMyOSAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzMjUgICAgICAg ICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzIxICAgICAg ICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTMxNSAgICAg ICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzMTAgICAg ICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzA1ICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIyMiAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyMTMg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjA0 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIw MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDA0 NjUgICAgICAgICAgICAgICAgICAgUyAgICAgICB1d2FpdCAgICAweGNiZTBlNjgwIHRocjEKNzkx MTAgNzkwOTIgIDM1NDUgICAgIDAgIFIrICAgICAgICAgICAgICAgICAgICAgICAgICBjcmVhdAot LU1vcmUtLSAgICAgICAgNzkxMDggNzkwOTIgIDM1NDUgICAgIDAgIFIrICAgICAgICAgICAgICAg ICAgICAgICAgICBjcmVhdAo3OTEwNyA3OTA4NyAgMzU0NSAgICAgMCAgUisgICAgICAodGhyZWFk ZWQpICAgICAgICAgIHRocjEKMTAxMjkwICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCjEwMTI4NSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAg ICAgICAgICAgICAgICAgdGhyMQoxMDEyNzkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAg ICAgICAgICAgICAgICAgIHRocjEKMTAxMjc2ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAg ICAgICAgICAgICAgICAgICB0aHIxCjEwMTI2MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNDQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjM5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIyMyAgICAgICAgICAgICAgICAgICBSdW5RICAg ICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyMTQgICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjA5ICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIzMCAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1ODMgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAwODk0ICAgICAgICAgICAgICAgICAgIFMg ICAgICAgdXdhaXQgICAgMHhjYmNhMjg4MCB0aHIxCjc5MTA2IDc5MDkyICAzNTQ1ICAgICAwICBS KyAgICAgICAgICAgICAgICAgICAgICAgICAgY3JlYXQKNzkxMDQgNzkwODcgIDM1NDUgICAgIDAg IFIrICAgICAgKHRocmVhZGVkKSAgICAgICAgICB0aHIxCjEwMTcxMyAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE3MDggICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNzA1ICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCi0tTW9yZS0tICAgICAgICAxMDE3 MDEgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAx Njk2ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEw MTY5MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQox MDE2ODkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEK MTAxNjg0ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIx CjEwMTY4MCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDE2NzYgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxNjcyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTY2OCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDE2NjUgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKMTAxNjYxICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICB0aHIxCjEwMTY1NiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAg ICAgdGhyMQoxMDE2NTMgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIHRocjEKMTAxNjQ5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAg ICAgICB0aHIxCjEwMTY0NSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAg ICAgICAgdGhyMQoxMDE2NDEgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxNjM3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTYzMyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDE2MjkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxNjI1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCi0tTW9yZS0tICAgICAgICAxMDE2MjAgICAgICAgICAgICAgICAgICAg UnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjE3ICAgICAgICAgICAgICAgICAg IFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYxMyAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2MDkgICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjA0ICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYwMCAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1OTYgICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTkwICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTU4NSAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1NzggICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTc0ICAgICAgICAg ICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTU2OSAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1NjQgICAgICAg ICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTU4ICAgICAg ICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTU1MyAgICAg ICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1NDcgICAg ICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTQyICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTUzNyAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1MzIg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTI3 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCi0tTW9y ZS0tICAgICAgICAxMDE1MjEgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxNTE1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTUwOSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDE1MDQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxNDk5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCjEwMTQ5MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAg ICAgICAgICAgICAgdGhyMQoxMDE0ODcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAg ICAgICAgICAgICAgIHRocjEKMTAxNDgxICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCjEwMTQ3NSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAg ICAgICAgICAgICAgICAgdGhyMQoxMDE0NjkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAg ICAgICAgICAgICAgICAgIHRocjEKMTAxNDYzICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAg ICAgICAgICAgICAgICAgICB0aHIxCjEwMTQ1OSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0NTIgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDQ1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQzOCAgICAgICAgICAgICAgICAgICBSdW5RICAg ICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0MzEgICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDI1ICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQxOCAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0MTEgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDA0ICAgICAgICAgICAgICAgICAgIFJ1 blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCi0tTW9yZS0tICAgICAgICAxMDEzOTcgICAg ICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzkwICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTM4MyAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzNzYg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzY2 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTM2 MCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEz NTUgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAx MzQ4ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEw MTE5MSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQox MDEyMjEgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEK MTAxMjQ1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIx CjEwMTI3NSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDEyNjAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxMTk1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTE5MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDEyMDIgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKMTAxMTk0ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICB0aHIxCjEwMTIyMCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAg ICAgdGhyMQoxMDEzMzYgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIHRocjEKMTAxMzMwICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAg ICAgICB0aHIxCi0tTW9yZS0tICAgICAgICAxMDEzMjYgICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzIwICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTMxNCAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzMDYgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjk2ICAgICAgICAgICAgICAgICAgIFJ1 blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTI5MSAgICAgICAgICAgICAgICAgICBS dW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyODYgICAgICAgICAgICAgICAgICAg UnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjgyICAgICAgICAgICAgICAgICAg IFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTI3NyAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNzEgICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjY1ICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTI1MyAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNDEgICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjM1ICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIyOCAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyMTEgICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjA1ICAgICAgICAg ICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIyNiAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNTIgICAgICAg ICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjY2ICAgICAg ICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCi0tTW9yZS0tICAg ICAgICAxMDAzMDUgICAgICAgICAgICAgICAgICAgUnVuICAgICBDUFUgNCAgICAgICAgICAgICAg IHRocjEKNzkxMDMgNzkwOTIgIDM1NDUgICAgIDAgIFIrICAgICAgICAgICAgICAgICAgICAgICAg ICBjcmVhdAo3OTEwMSA3OTA5MiAgMzU0NSAgICAgMCAgUisgICAgICAgICAgICAgICAgICAgICAg ICAgIGNyZWF0Cjc5MTAwIDc5MDg3ICAzNTQ1ICAgICAwICBSKyAgICAgICh0aHJlYWRlZCkgICAg ICAgICAgdGhyMQoxMDE3MTIgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxNzA5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTcwNCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDE3MDAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxNjk3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCjEwMTY5MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAg ICAgICAgICAgICAgdGhyMQoxMDE2ODggICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAg ICAgICAgICAgICAgIHRocjEKMTAxNjg1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCjEwMTY4MSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAg ICAgICAgICAgICAgICAgdGhyMQoxMDE2NzcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAg ICAgICAgICAgICAgICAgIHRocjEKMTAxNjczICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAg ICAgICAgICAgICAgICAgICB0aHIxCjEwMTY2OSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2NjQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjYwICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTY1NyAgICAgICAgICAgICAgICAgICBSdW5RICAg ICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2NTIgICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKLS1Nb3JlLS0gICAgICAgIDEwMTY0OCAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2NDQgICAgICAg ICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjQwICAgICAg ICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYzNiAgICAg ICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2MzIgICAg ICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjI4ICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYyNCAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2MjEg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjE2 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYx MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2 MDggICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAx NjA1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEw MTYwMSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQox MDE1OTcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEK MTAxNTkzICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIx CjEwMTU4OSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDE1ODQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxNTc5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTU3MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDE1NjggICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKLS1Nb3JlLS0gICAgICAgIDEwMTU2MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1NTkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTU1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTU1MCAgICAgICAgICAgICAgICAgICBSdW5RICAg ICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1NDUgICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTQwICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTUzNiAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1MzEgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTI2ICAgICAgICAgICAgICAgICAgIFJ1 blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTUyMiAgICAgICAgICAgICAgICAgICBS dW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1MTYgICAgICAgICAgICAgICAgICAg UnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTEwICAgICAgICAgICAgICAgICAg IFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTUwNiAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1MDEgICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDk1ICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQ4OSAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0ODMgICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDc3ICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQ3MSAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0NjUgICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKLS1Nb3JlLS0gICAgICAg IDEwMTQ1NyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDE0NTAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxNDQzICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTQzNiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDE0MjcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKMTAxNDIwICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICB0aHIxCjEwMTQxMyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAg ICAgdGhyMQoxMDE0MDcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIHRocjEKMTAxMzk5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAg ICAgICB0aHIxCjEwMTM5MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAg ICAgICAgdGhyMQoxMDEzODUgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxMzc5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTM3MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDEzNjUgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxMzU5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCjEwMTM1NCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAg ICAgICAgICAgICAgdGhyMQoxMDEzNDkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAg ICAgICAgICAgICAgIHRocjEKMTAxMzQ0ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCjEwMTIzOCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAg ICAgICAgICAgICAgICAgdGhyMQoxMDEzMDMgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAg ICAgICAgICAgICAgICAgIHRocjEKLS1Nb3JlLS0gICAgICAgIDEwMTI0OSAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyMjUgICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjE2ICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIwMSAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDExOTAgICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzM5ICAgICAgICAg ICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTMzNyAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDA3MjYgICAgICAg ICAgICAgICAgICAgUnVuICAgICBDUFUgNSAgICAgICAgICAgICAgIHRocjEKNzkwOTggNzkwOTIg IDM1NDUgICAgIDAgIFIrICAgICAgQ1BVIDEgICAgICAgICAgICAgICBjcmVhdAo3OTA5NiA3OTA4 NyAgMzU0NSAgICAgMCAgUisgICAgICAodGhyZWFkZWQpICAgICAgICAgIHRocjEKMTAxNzEwICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTcwNiAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE3MDIg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjk4 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTY5 NSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2 OTEgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAx Njg2ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEw MTY4MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQox MDE2NzggICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEK MTAxNjc0ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIx Ci0tTW9yZS0tICAgICAgICAxMDE2NzAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAg ICAgICAgICAgICAgIHRocjEKMTAxNjY2ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCjEwMTY2MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAg ICAgICAgICAgICAgICAgdGhyMQoxMDE2NTkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAg ICAgICAgICAgICAgICAgIHRocjEKMTAxNjU0ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAg ICAgICAgICAgICAgICAgICB0aHIxCjEwMTY1MCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2NDYgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjQyICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYzOCAgICAgICAgICAgICAgICAgICBSdW5RICAg ICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2MzQgICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjMwICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYyNiAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2MjIgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjE4ICAgICAgICAgICAgICAgICAgIFJ1 blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYxNCAgICAgICAgICAgICAgICAgICBS dW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2MTAgICAgICAgICAgICAgICAgICAg UnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjA2ICAgICAgICAgICAgICAgICAg IFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYwMiAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1OTggICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTk0ICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCi0tTW9yZS0tICAgICAgICAxMDE1 OTEgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAx NTg2ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEw MTU4MCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQox MDE1NzUgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEK MTAxNTcwICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIx CjEwMTU2NiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDE1NjEgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxNTU2ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTU1MSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDE1NDYgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKMTAxNTQxICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICB0aHIxCjEwMTUzNSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAg ICAgdGhyMQoxMDE1MzAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIHRocjEKMTAxNTI1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAg ICAgICB0aHIxCjEwMTUxOSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAg ICAgICAgdGhyMQoxMDE1MTQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxNTA3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTUwMyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDE0OTcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxNDkxICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCi0tTW9yZS0tICAgICAgICAxMDE0ODQgICAgICAgICAgICAgICAgICAg UnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDc4ICAgICAgICAgICAgICAgICAg IFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQ3MyAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0NjggICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDYwICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQ1MyAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0NDYgICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDQwICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQzMyAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0MjYgICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDE5ICAgICAgICAg ICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQxMiAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0MDYgICAgICAg ICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDAwICAgICAg ICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTM5MyAgICAg ICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzODYgICAg ICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzc4ICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTM3MSAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzNjQg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzU4 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCi0tTW9y ZS0tICAgICAgICAxMDEzNTIgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxMzQ2ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTI3MCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDExOTkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxMTkyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCjEwMTI5OSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAg ICAgICAgICAgICAgdGhyMQoxMDEzMDIgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAg ICAgICAgICAgICAgIHRocjEKMTAxMzI3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCjEwMTMyMiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAg ICAgICAgICAgICAgICAgdGhyMQoxMDEzMTcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAg ICAgICAgICAgICAgICAgIHRocjEKMTAxMzExICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAg ICAgICAgICAgICAgICAgICB0aHIxCjEwMTMwMSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyOTIgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjg3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTI4MSAgICAgICAgICAgICAgICAgICBSdW5RICAg ICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNzggICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjczICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTI1OCAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNTEgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjQzICAgICAgICAgICAgICAgICAgIFJ1 blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCi0tTW9yZS0tICAgICAgICAxMDEyMzcgICAg ICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjI0ICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIxOCAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyMzEg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjI5 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTI1 NyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDA4 MTIgICAgICAgICAgICAgICAgICAgUnVuICAgICBDUFUgNyAgICAgICAgICAgICAgIHRocjEKNzkw OTUgNzkwOTIgIDM1NDUgICAgIDAgIFIrICAgICAgQ1BVIDIgICAgICAgICAgICAgICBjcmVhdAo3 OTA5MyA3OTA4NyAgMzU0NSAgICAgMCAgUisgICAgICAodGhyZWFkZWQpICAgICAgICAgIHRocjEK MTAxNTg4ICAgICAgICAgICAgICAgICAgIEluYWN0diAgICAgICAgICAgICAgICAgICAgICB0aHIx CjEwMTU4MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDE1NzcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxNTcyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTU2NyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDE1NjIgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKMTAxNTU3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICB0aHIxCjEwMTU1MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAg ICAgdGhyMQoxMDE1NDggICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIHRocjEKMTAxNTQzICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAg ICAgICB0aHIxCjEwMTUzOCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAg ICAgICAgdGhyMQotLU1vcmUtLSAgICAgICAgMTAxNTMzICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTUyOCAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1MjMgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTE3ICAgICAgICAgICAgICAgICAgIFJ1 blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTUxMSAgICAgICAgICAgICAgICAgICBS dW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1MDUgICAgICAgICAgICAgICAgICAg UnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTAwICAgICAgICAgICAgICAgICAg IFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQ5NCAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0ODggICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDgyICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQ3NiAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0NzAgICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDY0ICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQ1OCAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0NTEgICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDQ0ICAgICAgICAg ICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQzNyAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0MjkgICAgICAg ICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNDIyICAgICAg ICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTQxNSAgICAg ICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQotLU1vcmUtLSAg ICAgICAgMTAxNDA4ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICB0aHIxCjEwMTQwMSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAg ICAgdGhyMQoxMDEzOTQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIHRocjEKMTAxMzg4ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAg ICAgICB0aHIxCjEwMTM4MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAg ICAgICAgdGhyMQoxMDEzNzUgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxMzY4ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTIxNyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDEyMTUgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxMjEyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCjEwMTE5OCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAg ICAgICAgICAgICAgdGhyMQoxMDEyMzYgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAg ICAgICAgICAgICAgIHRocjEKMTAxMjYyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCjEwMTI2MSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAg ICAgICAgICAgICAgICAgdGhyMQoxMDA0NTQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAg ICAgICAgICAgICAgICAgIHRocjEKNzkwOTIgNzkwNzYgIDM1NDUgICAgIDAgIFMrICAgICAgd2Fp dCAgICAgMHhjYzkyMDU1MCBjcmVhdAo3OTA5MCA3OTA4NyAgMzU0NSAgICAgMCAgUisgICAgICAo dGhyZWFkZWQpICAgICAgICAgIHRocjEKMTAxNzE1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTcxMSAgICAgICAgICAgICAgICAgICBSdW5RICAg ICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE3MDcgICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKLS1Nb3JlLS0gICAgICAgIDEwMTcwMyAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2OTkgICAgICAg ICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjk0ICAgICAg ICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTY5MCAgICAg ICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2ODcgICAg ICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjgzICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTY3OSAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2NzUg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjcx ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTY2 NyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2 NjMgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAx NjU4ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEw MTY1NSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQox MDE2NTEgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEK MTAxNjQ3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIx CjEwMTY0MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDE2MzkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxNjM1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTYzMSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDE2MjcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKLS1Nb3JlLS0gICAgICAgIDEwMTYyMyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2MTkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjE1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTYxMSAgICAgICAgICAgICAgICAgICBSdW5RICAg ICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE2MDcgICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNjAzICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTU5OSAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1OTUgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTkyICAgICAgICAgICAgICAgICAgIFJ1 blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTU4NyAgICAgICAgICAgICAgICAgICBS dW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1ODEgICAgICAgICAgICAgICAgICAg UnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTc2ICAgICAgICAgICAgICAgICAg IFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTU3MSAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1NjUgICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTYwICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTU1NCAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1NDkgICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxNTQ0ICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTUzOSAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE1MzQgICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKLS1Nb3JlLS0gICAgICAg IDEwMTUyOSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDE1MjQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxNTE4ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTUxMiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDE1MDggICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKMTAxNTAyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICB0aHIxCjEwMTQ5NiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAg ICAgdGhyMQoxMDE0OTAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIHRocjEKMTAxNDg1ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAg ICAgICB0aHIxCjEwMTQ3OSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAg ICAgICAgdGhyMQoxMDE0NzQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxNDY3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTQ2MSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDE0NTQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxNDQ3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCjEwMTQ0MSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAg ICAgICAgICAgICAgdGhyMQoxMDE0MzQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAg ICAgICAgICAgICAgIHRocjEKMTAxNDI4ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCjEwMTQyMSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAg ICAgICAgICAgICAgICAgdGhyMQoxMDE0MTQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAg ICAgICAgICAgICAgICAgIHRocjEKLS1Nb3JlLS0gICAgICAgIDEwMTQwNSAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzOTggICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzkxICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTM4NCAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzNzcgICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzY3ICAgICAgICAg ICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTM2MSAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzNTMgICAgICAg ICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzQ3ICAgICAg ICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTM0MyAgICAg ICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNTkgICAg ICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzA4ICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTMzNCAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzMzEg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzI4 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTMy NCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEz MTkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAx MzEyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEw MTMwNyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQox MDEyOTcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEK LS1Nb3JlLS0gICAgICAgIDEwMTI4OCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAg ICAgICAgICAgICAgdGhyMQoxMDEyODQgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAg ICAgICAgICAgICAgIHRocjEKMTAxMjgwICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICB0aHIxCjEwMTI3NCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAg ICAgICAgICAgICAgICAgdGhyMQoxMDEyNjkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAg ICAgICAgICAgICAgICAgIHRocjEKMTAxMjU0ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAg ICAgICAgICAgICAgICAgICB0aHIxCjEwMTI1MCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNDAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjM0ICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIzMyAgICAgICAgICAgICAgICAgICBSdW5RICAg ICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyMDAgICAgICAgICAgICAgICAgICAgUnVuUSAg ICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjEwICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIyNyAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNDggICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjU2ICAgICAgICAgICAgICAgICAgIFJ1 blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTI2NCAgICAgICAgICAgICAgICAgICBS dW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNjcgICAgICAgICAgICAgICAgICAg UnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAwMzIwICAgICAgICAgICAgICAgICAg IFJ1biAgICAgQ1BVIDYgICAgICAgICAgICAgICB0aHIxCjc5MDg4IDc5MDg3ICAzNTQ1ICAgICAw ICBSKyAgICAgICh0aHJlYWRlZCkgICAgICAgICAgdGhyMQoxMDE0OTggICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKLS1Nb3JlLS0gICAgICAgIDEwMTQ5 MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDE0 ODYgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAx NDgwICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEw MTQ3MiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQox MDE0NjYgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEK MTAxNDYyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIx CjEwMTQ1NiAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhy MQoxMDE0NDkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRo cjEKMTAxNDQyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0 aHIxCjEwMTQzNSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAg dGhyMQoxMDE0MzAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAg IHRocjEKMTAxNDIzICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICB0aHIxCjEwMTQxNyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAg ICAgdGhyMQoxMDE0MDkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIHRocjEKMTAxNDAyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAg ICAgICB0aHIxCjEwMTM5NSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAg ICAgICAgdGhyMQoxMDEzODcgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxMzgxICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTM3NCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDEzNjkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKLS1Nb3JlLS0gICAgICAgIDEwMTM2MiAgICAgICAgICAgICAgICAgICBS dW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzNTYgICAgICAgICAgICAgICAgICAg UnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzUxICAgICAgICAgICAgICAgICAg IFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTM0NSAgICAgICAgICAgICAgICAg ICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNDYgICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzQxICAgICAgICAgICAgICAg ICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTI5NSAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyNzIgICAgICAgICAgICAg ICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMjQ3ICAgICAgICAgICAg ICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTIxOSAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzMDAgICAgICAgICAg ICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzM1ICAgICAgICAg ICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTMzMiAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzMDQgICAgICAg ICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzIzICAgICAg ICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTMxOCAgICAg ICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEzMTMgICAg ICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKMTAxMzA5ICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICB0aHIxCjEwMTI5OCAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgdGhyMQoxMDEyOTMg ICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgIHRocjEKLS1Nb3Jl LS0gICAgICAgIDEwMTI4OSAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAg ICAgICAgdGhyMQoxMDEyODMgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgIHRocjEKMTAxMjA4ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAg ICAgICAgICB0aHIxCjEwMTIwNyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgdGhyMQoxMDEyMDYgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAg ICAgICAgICAgIHRocjEKMTAxMjQyICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAg ICAgICAgICAgICB0aHIxCjEwMDQ2NCAgICAgICAgICAgICAgICAgICBTICAgICAgIHV3YWl0ICAg IDB4Y2MwOTEyODAgdGhyMQo3OTA4NyA3OTA3OCAgMzU0NSAgICAgMCAgUysgICAgICB3YWl0ICAg ICAweGNjZGM4NTUwIHRocjEKNzkwNzggIDM1NTQgIDM1NDUgICAgIDAgIFMrICAgICAgbmFuc2xw ICAgMHhjMGRmODZjNCBpbml0aWFsIHRocmVhZAo3OTA3NyAgMzU1NCAgMzU0NSAgICAgMCAgUysg ICAgICBuYW5zbHAgICAweGMwZGY4NmM0IG1rZGlyCjc5MDc2ICAzNTU0ICAzNTQ1ICAgICAwICBT KyAgICAgIG5hbnNscCAgIDB4YzBkZjg2YzQgY3JlYXQKNzkwNzQgIDM1NTQgIDM1NDUgICAgIDAg IFMrICAgICAgbmFuc2xwICAgMHhjMGRmODZjNCBydwo3NzY3MSAgICAgMCAgICAgMCAgICAgMCAg U0wgICAgICAtICAgICAgICAweGMwZjYxODQwIFtuZnNpb2QgMF0KIDM1NTQgIDM1NTMgIDM1NDUg ICAgIDAgIFMrICAgICAgd2FpdCAgICAgMHhjOTI2NjAwMCBydW4KIDM1NTMgIDM1NTIgIDM1NDUg ICAgIDAgIFNXKyAgICAgd2FpdCAgICAgMHhjYmM0YmFhMCBydW4KIDM1NTIgIDM1NDUgIDM1NDUg ICAgIDAgIFMrICAgICAgbmFuc2xwICAgMHhjMGRmODZjNCBydW4KIDM1NDUgIDEzMzIgIDM1NDUg ICAgIDAgIFNXKyAgICAgd2FpdCAgICAgMHhjYmM1MjdmOCBzaAogMTg0NyAgICAgMCAgICAgMCAg ICAgMCAgREwgICAgICBtZHdhaXQgICAweGM5MWI5ODAwIFttZDBdCiAxMzMyICAxMzMwICAxMzMy ICAgICAwICBTVysgICAgIHBhdXNlICAgIDB4Yzk2MmU1YTggY3NoCiAxMzMwICAgICAxICAxMzMw ICAgICAwICBTV3MrICAgIHdhaXQgICAgIDB4Yzk1Mzc3ZjggbG9naW4KLS1Nb3JlLS0gICAgICAg ICAxMjUyICAgICAxICAxMjUyICAgICAwICBTcyAgICAgIHNlbGVjdCAgIDB4YzliMjM5YTQgc3No ZAogIDk3NiAgICAgMSAgIDk3NiAgICAgMCAgU3MgICAgICBzZWxlY3QgICAweGM5YjIyMmE0IHN5 c2xvZ2QKICA3OTkgICAgIDEgICA3OTkgICAgIDAgIFNzICAgICAgc2VsZWN0ICAgMHhjOTE4MTdh NCBkZXZkCiAgIDIwICAgICAwICAgICAwICAgICAwICBETCAgICAgIC0gICAgICAgIDB4YzBkZjg1 MjQgW3NjaGVkY3B1XQogICAxOSAgICAgMCAgICAgMCAgICAgMCAgREwgICAgICBmbG93Y2xlYSAw eGMwZjVjMTQ4IFtmbG93Y2xlYW5lcl0KICAgMTggICAgIDAgICAgIDAgICAgIDAgIERMICAgICAg c2RmbHVzaCAgMHhjMGY2NzhhMCBbc29mdGRlcGZsdXNoXQogICAxNyAgICAgMCAgICAgMCAgICAg MCAgREwgICAgICBzeW5jZXIgICAweGMwZjViZjU0IFtzeW5jZXJdCiAgIDE2ICAgICAwICAgICAw ICAgICAwICBETCAgICAgIHZscnV3dCAgIDB4YzkwOGFkNDggW3ZubHJ1XQogICAxNSAgICAgMCAg ICAgMCAgICAgMCAgREwgICAgICBwc2xlZXAgICAweGMwZjViYzg4IFtidWZkYWVtb25dCiAgICA5 ICAgICAwICAgICAwICAgICAwICBETCAgICAgIHBnemVybyAgIDB4YzBmNjhhMTQgW3BhZ2V6ZXJv XQogICAgOCAgICAgMCAgICAgMCAgICAgMCAgREwgICAgICBwc2xlZXAgICAweGMwZjY4NjQ0IFt2 bWRhZW1vbl0KICAgIDcgICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgcHNsZWVwICAgMHhjMGY2 ODYwYyBbcGFnZWRhZW1vbl0KICAgIDYgICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgLSAgICAg ICAgMHhjOGMxZTIzYyBbZmRjMF0KICAgMTQgICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgKHRo cmVhZGVkKSAgICAgICAgICBbdXNiXQoxMDAwNjIgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGM4YmIxZDBjIFt1c2J1czRdCjEwMDA2MSAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4YzhiYjFjZGMgW3VzYnVzNF0KMTAwMDYwICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhjOGJiMWNhYyBbdXNidXM0XQoxMDAwNTkgICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGM4YmIxYzdjIFt1c2J1czRdCjEwMDA1OCAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4YzhiODlkYWMgW3VzYnVzM10KMTAwMDU3ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhjOGI4OWQ3YyBbdXNidXMzXQotLU1v cmUtLSAgICAgICAgMTAwMDU2ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhj OGI4OWQ0YyBbdXNidXMzXQoxMDAwNTUgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGM4Yjg5ZDFjIFt1c2J1czNdCjEwMDA1MyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0g ICAgICAgIDB4YzhiNjdkYWMgW3VzYnVzMl0KMTAwMDUyICAgICAgICAgICAgICAgICAgIEQgICAg ICAgLSAgICAgICAgMHhjOGI2N2Q3YyBbdXNidXMyXQoxMDAwNTEgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGM4YjY3ZDRjIFt1c2J1czJdCjEwMDA1MCAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4YzhiNjdkMWMgW3VzYnVzMl0KMTAwMDQ4ICAgICAgICAg ICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhjOGIzZmRhYyBbdXNidXMxXQoxMDAwNDcgICAg ICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGM4YjNmZDdjIFt1c2J1czFdCjEwMDA0 NiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4YzhiM2ZkNGMgW3VzYnVzMV0K MTAwMDQ1ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhjOGIzZmQxYyBbdXNi dXMxXQoxMDAwNDMgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGM4YjAyZGFj IFt1c2J1czBdCjEwMDA0MiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4Yzhi MDJkN2MgW3VzYnVzMF0KMTAwMDQxICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAg MHhjOGIwMmQ0YyBbdXNidXMwXQoxMDAwNDAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGM4YjAyZDFjIFt1c2J1czBdCiAgICA1ICAgICAwICAgICAwICAgICAwICBETCAgICAg IGNjYl9zY2FuIDB4YzBkYzQ4ZDQgW3hwdF90aHJkXQogICAxMyAgICAgMCAgICAgMCAgICAgMCAg REwgICAgICAtICAgICAgICAweGMwZGY4NTI0IFt5YXJyb3ddCiAgICA0ICAgICAwICAgICAwICAg ICAwICBETCAgICAgIC0gICAgICAgIDB4YzBkZjYyZTQgW2dfZG93bl0KICAgIDMgICAgIDAgICAg IDAgICAgIDAgIERMICAgICAgLSAgICAgICAgMHhjMGRmNjJlMCBbZ191cF0KICAgIDIgICAgIDAg ICAgIDAgICAgIDAgIERMICAgICAgLSAgICAgICAgMHhjMGRmNjJkOCBbZ19ldmVudF0KICAgMTIg ICAgIDAgICAgIDAgICAgIDAgIFJMICAgICAgKHRocmVhZGVkKSAgICAgICAgICBbaW50cl0KLS1N b3JlLS0gICAgICAgIDEwMDA2NiAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAg ICAgICAgICAgW2lycTE6IGF0a2JkMF0KMTAwMDY0ICAgICAgICAgICAgICAgICAgIFJ1blEgICAg ICAgICAgICAgICAgICAgICAgICBbc3dpMDogdWFydCB1YXJ0XQoxMDAwNjMgICAgICAgICAgICAg ICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtpcnExNDogYXRhMF0KMTAwMDU0ICAg ICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJxMTY6IHVoY2kz XQoxMDAwNDkgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtp cnExODogZnhwMCB1aGNpMl0KMTAwMDQ0ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAg ICAgICAgICAgICAgICBbaXJxMTk6IHVoY2kxK10KMTAwMDM5ICAgICAgICAgICAgICAgICAgIEkg ICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJxMTc6IHVoY2kwIGVoY2kwXQoxMDAwMzYgICAg ICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtpcnE5OiBhY3BpMF0K MTAwMDM1ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dp MjogY2FtYmlvXQoxMDAwMzMgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtzd2k2OiB0YXNrIHF1ZXVlXQoxMDAwMzIgICAgICAgICAgICAgICAgICAgSSAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtzd2k2OiBHaWFudCB0YXNrcV0KMTAwMDMwICAgICAgICAg ICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNTogK10KMTAwMDIwICAg ICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpMzogdm1dCjEw MDAxOSAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N3aTQ6 IGNsb2NrXQoxMDAwMTggICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAgICAg ICAgIFtzd2k0OiBjbG9ja10KMTAwMDE3ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAg ICAgICAgICAgICAgICBbc3dpNDogY2xvY2tdCjEwMDAxNiAgICAgICAgICAgICAgICAgICBSdW5R ICAgICAgICAgICAgICAgICAgICAgICAgW3N3aTQ6IGNsb2NrXQoxMDAwMTUgICAgICAgICAgICAg ICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2k0OiBjbG9ja10KMTAwMDE0ICAg ICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNDogY2xvY2td CjEwMDAxMyAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N3 aTQ6IGNsb2NrXQotLU1vcmUtLSAgICAgICAgMTAwMDEyICAgICAgICAgICAgICAgICAgIFJ1blEg ICAgICAgICAgICAgICAgICAgICAgICBbc3dpNDogY2xvY2tdCjEwMDAxMSAgICAgICAgICAgICAg ICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N3aTE6IG5ldGlzciAwXQogICAxMSAg ICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAodGhyZWFkZWQpICAgICAgICAgIFtpZGxlXQoxMDAw MTAgICAgICAgICAgICAgICAgICAgQ2FuUnVuICAgICAgICAgICAgICAgICAgICAgIFtpZGxlOiBj cHUwXQoxMDAwMDkgICAgICAgICAgICAgICAgICAgQ2FuUnVuICAgICAgICAgICAgICAgICAgICAg IFtpZGxlOiBjcHUxXQoxMDAwMDggICAgICAgICAgICAgICAgICAgQ2FuUnVuICAgICAgICAgICAg ICAgICAgICAgIFtpZGxlOiBjcHUyXQoxMDAwMDcgICAgICAgICAgICAgICAgICAgQ2FuUnVuICAg ICAgICAgICAgICAgICAgICAgIFtpZGxlOiBjcHUzXQoxMDAwMDYgICAgICAgICAgICAgICAgICAg Q2FuUnVuICAgICAgICAgICAgICAgICAgICAgIFtpZGxlOiBjcHU0XQoxMDAwMDUgICAgICAgICAg ICAgICAgICAgQ2FuUnVuICAgICAgICAgICAgICAgICAgICAgIFtpZGxlOiBjcHU1XQoxMDAwMDQg ICAgICAgICAgICAgICAgICAgQ2FuUnVuICAgICAgICAgICAgICAgICAgICAgIFtpZGxlOiBjcHU2 XQoxMDAwMDMgICAgICAgICAgICAgICAgICAgQ2FuUnVuICAgICAgICAgICAgICAgICAgICAgIFtp ZGxlOiBjcHU3XQogICAgMSAgICAgMCAgICAgMSAgICAgMCAgU0xzICAgICB3YWl0ICAgICAweGM4 NTk3ZDQ4IFtpbml0XQogICAxMCAgICAgMCAgICAgMCAgICAgMCAgREwgICAgICBhdWRpdF93byAw eGMwZjY3MWMwIFthdWRpdF0KICAgIDAgICAgIDAgICAgIDAgICAgIDAgIERMcyAgICAgKHRocmVh ZGVkKSAgICAgICAgICBba2VybmVsXQoxMDAwMzggICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGM4YWJhZDgwIFtlbTEgdGFza3FdCjEwMDAzNyAgICAgICAgICAgICAgICAgICBE ICAgICAgIC0gICAgICAgIDB4YzhhOTk5ODAgW2VtMCB0YXNrcV0KMTAwMDMxICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhjODk5ZmE4MCBbdGhyZWFkIHRhc2txXQoxMDAwMjkg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGM4OWEwMDgwIFtrcXVldWUgdGFz a3FdCjEwMDAyOCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4Yzg5YTIwODAg W2FjcGlfdGFza18yXQoxMDAwMjcgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAw eGM4OWEyMDgwIFthY3BpX3Rhc2tfMV0KLS1Nb3JlLS0gICAgICAgIDEwMDAyNiAgICAgICAgICAg ICAgICAgICBEICAgICAgIC0gICAgICAgIDB4Yzg5YTIwODAgW2FjcGlfdGFza18wXQoxMDAwMjQg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGM4NThmMDgwIFtmaXJtd2FyZSB0 YXNrcV0KMTAwMDAwICAgICAgICAgICAgICAgICAgIEQgICAgICAgc2NoZWQgICAgMHhjMGRmNjNj MCBbc3dhcHBlcl0KNzkwODEgNzkwNzQgIDM1NDUgICAgIDAgIForICAgICAgICAgICAgICAgICAg ICAgICAgICBydwo3OTA4OSA3OTA3NyAgMzU0NSAgICAgMCAgWisgICAgICAgICAgICAgICAgICAg ICAgICAgIG1rZGlyCjc5MDc1ICAzNTU0ICAzNTQ1ICAgICAwICBaKyAgICAgICAgICAgICAgICAg ICAgICAgICAgc3dhcAo3OTA4MCAgMzU1NCAgMzU0NSAgICAgMCAgWisgICAgICAgICAgICAgICAg ICAgICAgICAgIHRjcAo3OTA3OSAgMzU1NCAgMzU0NSAgICAgMCAgWisgICAgICAgICAgICAgICAg ICAgICAgICAgIHVkcApkYj4gc2hpbwggCAggCG93IGFsbHBjcHUKQ3VycmVudCBDUFU6IDEKCmNw dWlkICAgICAgICA9IDAKZHluYW1pYyBwY3B1ICAgID0gMHg2NjE0MDAKY3VydGhyZWFkICAgID0g MHhjYmVhYzIzMDogcGlkIDc5MTI2ICJjcmVhdCIKY3VycGNiICAgICAgID0gMHhlOWViOWQ5MApm cGN1cnRocmVhZCAgPSBub25lCmlkbGV0aHJlYWQgICA9IDB4Yzg1YTYyMzA6IHBpZCAxMSAiaWRs ZTogY3B1MCIKQVBJQyBJRCAgICAgID0gMApjdXJyZW50bGR0ICAgPSAweDUwCnNwaW4gbG9ja3Mg aGVsZDoKCmNwdWlkICAgICAgICA9IDEKZHluYW1pYyBwY3B1ICAgID0gMHg1NTMwNDAwCmN1cnRo cmVhZCAgICA9IDB4YzhjNTlhZjA6IHBpZCA3OTA5OCAiY3JlYXQiCmN1cnBjYiAgICAgICA9IDB4 ZTk3OGFkOTAKZnBjdXJ0aHJlYWQgID0gbm9uZQppZGxldGhyZWFkICAgPSAweGM4NWE2NDYwOiBw aWQgMTEgImlkbGU6IGNwdTEiCkFQSUMgSUQgICAgICA9IDEKY3VycmVudGxkdCAgID0gMHg1MAot LU1vcmUtLSAgICAgICAgc3BpbiBsb2NrcyBoZWxkOgoKY3B1aWQgICAgICAgID0gMgpkeW5hbWlj IHBjcHUgICAgPSAweDU1MzM0MDAKY3VydGhyZWFkICAgID0gMHhjYmVkNjY5MDogcGlkIDc5MDk1 ICJjcmVhdCIKY3VycGNiICAgICAgID0gMHhlOWM2YmQ5MApmcGN1cnRocmVhZCAgPSBub25lCmlk bGV0aHJlYWQgICA9IDB4Yzg1OWEwMDA6IHBpZCAxMSAiaWRsZTogY3B1MiIKQVBJQyBJRCAgICAg ID0gMgpjdXJyZW50bGR0ICAgPSAweDUwCnNwaW4gbG9ja3MgaGVsZDoKCmNwdWlkICAgICAgICA9 IDMKZHluYW1pYyBwY3B1ICAgID0gMHg1NTM2NDAwCmN1cnRocmVhZCAgICA9IDB4YzlhZTYwMDA6 IHBpZCA3OTExNSAiY3JlYXQiCmN1cnBjYiAgICAgICA9IDB4ZTliNDJkOTAKZnBjdXJ0aHJlYWQg ID0gbm9uZQppZGxldGhyZWFkICAgPSAweGM4NTlhMjMwOiBwaWQgMTEgImlkbGU6IGNwdTMiCkFQ SUMgSUQgICAgICA9IDMKY3VycmVudGxkdCAgID0gMHg1MAotLU1vcmUtLSAgICAgICAgc3BpbiBs b2NrcyBoZWxkOgoKY3B1aWQgICAgICAgID0gNApkeW5hbWljIHBjcHUgICAgPSAweDU1Mzk0MDAK Y3VydGhyZWFkICAgID0gMHhjOWRhZTY5MDogcGlkIDc5MTA0ICJ0aHIxIgpjdXJwY2IgICAgICAg PSAweGU5MmNjZDkwCmZwY3VydGhyZWFkICA9IG5vbmUKaWRsZXRocmVhZCAgID0gMHhjODU5YTQ2 MDogcGlkIDExICJpZGxlOiBjcHU0IgpBUElDIElEICAgICAgPSA0CmN1cnJlbnRsZHQgICA9IDB4 NTAKc3BpbiBsb2NrcyBoZWxkOgoKY3B1aWQgICAgICAgID0gNQpkeW5hbWljIHBjcHUgICAgPSAw eDU1M2M0MDAKY3VydGhyZWFkICAgID0gMHhjOTQyYzAwMDogcGlkIDc5MTAwICJ0aHIxIgpjdXJw Y2IgICAgICAgPSAweGU5YTMxZDkwCmZwY3VydGhyZWFkICA9IG5vbmUKaWRsZXRocmVhZCAgID0g MHhjODU5YTY5MDogcGlkIDExICJpZGxlOiBjcHU1IgpBUElDIElEICAgICAgPSA1CmN1cnJlbnRs ZHQgICA9IDB4NTAKLS1Nb3JlLS0gICAgICAgIHNwaW4gbG9ja3MgaGVsZDoKCmNwdWlkICAgICAg ICA9IDYKZHluYW1pYyBwY3B1ICAgID0gMHg1NTNmNDAwCmN1cnRocmVhZCAgICA9IDB4YzllMjZk MjA6IHBpZCA3OTA5MCAidGhyMSIKY3VycGNiICAgICAgID0gMHhlOTMwMWQ5MApmcGN1cnRocmVh ZCAgPSBub25lCmlkbGV0aHJlYWQgICA9IDB4Yzg1OWE4YzA6IHBpZCAxMSAiaWRsZTogY3B1NiIK QVBJQyBJRCAgICAgID0gNgpjdXJyZW50bGR0ICAgPSAweDUwCnNwaW4gbG9ja3MgaGVsZDoKCmNw dWlkICAgICAgICA9IDcKZHluYW1pYyBwY3B1ICAgID0gMHg1NTQyNDAwCmN1cnRocmVhZCAgICA9 IDB4YzlhZGI0NjA6IHBpZCA3OTA5NiAidGhyMSIKY3VycGNiICAgICAgID0gMHhlOWJlYWQ5MApm cGN1cnRocmVhZCAgPSBub25lCmlkbGV0aHJlYWQgICA9IDB4Yzg1OWFhZjA6IHBpZCAxMSAiaWRs ZTogY3B1NyIKQVBJQyBJRCAgICAgID0gNwpjdXJyZW50bGR0ICAgPSAweDUwCi0tTW9yZS0tICAg ICAgICBzcGluIGxvY2tzIGhlbGQ6CgpkYj4gc2hvdyBsb2NrZWR2bm9kZXMKTm8gc3VjaCBjb21t YW5kCmRiPiBzaG93IGxvY2tlZHZub2RlcwgIcyAICApMb2NrZWQgdm5vZGVzCgoweGM5OWU5YmIw OiB0YWcgbmZzLCB0eXBlIFZESVIKICAgIHVzZWNvdW50IDEsIHdyaXRlY291bnQgMCwgcmVmY291 bnQgMiBtb3VudGVkaGVyZSAwCiAgICBmbGFncyAoKQogICAgbG9jayB0eXBlIG5mczogU0hBUkVE IChjb3VudCAxKQoJZmlsZWlkIC0zNzc5Njk1NjAgZnNpZCAweGMwY2JjODlkCgoweGM5OWU5YWEw OiB0YWcgbmZzLCB0eXBlIFZESVIKICAgIHVzZWNvdW50IDEsIHdyaXRlY291bnQgMCwgcmVmY291 bnQgMiBtb3VudGVkaGVyZSAwCiAgICBmbGFncyAoKQogICAgbG9jayB0eXBlIG5mczogU0hBUkVE IChjb3VudCAxKQoJZmlsZWlkIC0zNzc5Njk1NjAgZnNpZCAweGMwY2JjODlkCmRiPiBzaG93IG1v dW50CjB4YzkxZThjYTggMTkyLjE2OC41LjE6L3pvby9saW9uMSBvbiAvIChuZnMpCjB4YzkxZTkw MDAgZGV2ZnMgb24gL2RldiAoZGV2ZnMpCjB4YzljMGI1MTAgMTkyLjE2OC41LjE6L3pvby9naWFu bmkgb24gL3pvby9naWFubmkgKG5mcykKMHhjYjZlM2EyMCAvZGV2L21kMCBvbiAvcm9vdC90bXAg KHVmcykKCk1vcmUgaW5mbzogc2hvdyBtb3VudCA8YWRkcj4KZGI+IGFsbHQKClRyYWNpbmcgY29t bWFuZCBzeXNsb2dkIHBpZCA3OTE0NiB0aWQgMTAwNjA2IHRkIDB4YzkzODg4YzAKc2NoZWRfc3dp dGNoKGM5Mzg4OGMwLDAsMTA0LDE5MSxmMzIzMDdjMSwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFj NQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAK c2xlZXBxX3N3aXRjaChjOTM4ODhjMCwwLGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3 aXRjaCsweDE1ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscyhjMDg3ZmNlYSxjOGFjNzIwNCwwLGMwYzk5 N2U1LGM5Mzg4OGMwLC4uLikgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2Fp dF9zaWcoYzhhYzcyODAsMCxlOTczYmI2NCwxMDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysw eDE3Cl9jdl93YWl0X3NpZyhjOGFjNzI4MCxjOGFjNzIwNCxjMGNhMzMzZiw1MTEsYzhhYzcyMDAs Li4uKSBhdCBfY3Zfd2FpdF9zaWcrMHgyNDAKdHR5X3dhaXQoYzhhYzcyMDAsYzhhYzcyODAsYzBj YTMzM2YsOWYsY2MxNmE0ODAsLi4uKSBhdCB0dHlfd2FpdCsweDcxCnR0eWRldl93cml0ZShjODVl OWIwMCxjYzE2YTQ4MCwwKSBhdCB0dHlkZXZfd3JpdGUrMHhjYwp0dHljb25zZGV2X3dyaXRlKGM4 NWU5YjAwLGNjMTZhNDgwLDAsMCwwLC4uLikgYXQgdHR5Y29uc2Rldl93cml0ZSsweDI4CmRldmZz X3dyaXRlX2YoYzkzZWI2YzgsY2MxNmE0ODAsYzg1NzUyODAsMCxjOTM4ODhjMCwuLi4pIGF0IGRl dmZzX3dyaXRlX2YrMHg5ZQpkb2ZpbGV3cml0ZShjYzE2YTQ4MCxmZmZmZmZmZixmZmZmZmZmZiww LGM5M2ViNmM4LC4uLikgYXQgZG9maWxld3JpdGUrMHg5NQprZXJuX3dyaXRldihjOTM4ODhjMCw4 LGNjMTZhNDgwLGNjMTZhNDgwLGJmYmZjZTBjLC4uLikgYXQga2Vybl93cml0ZXYrMHg1OAp3cml0 ZXYoYzkzODg4YzAsZTk3M2JjZjgsYyxjMGNhMWJiMyxjMGQ4N2FkYywuLi4pIGF0IHdyaXRldisw eDQ2CnN5c2NhbGwoZTk3M2JkMzgpIGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBfc3lzY2FsbCgp IGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lzY2FsbCAoMTIxLCBGcmVlQlNEIEVMRjMy LCB3cml0ZXYpLCBlaXAgPSAweDI4MTc3M2ViLCBlc3AgPSAweGJmYmZjZDNjLCBlYnAgPSAweGJm YmZjZGI4IC0tLQoKVHJhY2luZyBjb21tYW5kIHN5c2xvZ2QgcGlkIDc5MTQ1IHRpZCAxMDExMTMg dGQgMHhjOTMzOGQyMAotLU1vcmUtLSAgICAgICAgc2NoZWRfc3dpdGNoKGM5MzM4ZDIwLDAsMTA0 LDE5MSxmMzIwNDUxNCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAs YzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjOTMz OGQyMCwwLGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFf Y2F0Y2hfc2lnbmFscyhjMDg3ZmNlYSxjOGFjNzIwNCwwLGMwYzk5N2U1LGM5MzM4ZDIwLC4uLikg YXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoYzhhYzcyODAsMCxl OWZkMGI2NCwxMDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysweDE3Cl9jdl93YWl0X3NpZyhj OGFjNzI4MCxjOGFjNzIwNCxjMGNhMzMzZiw1MTEsYzhhYzcyMDAsLi4uKSBhdCBfY3Zfd2FpdF9z aWcrMHgyNDAKdHR5X3dhaXQoYzhhYzcyMDAsYzhhYzcyODAsYzBjYTMzM2YsOWYsY2NjZDBiODAs Li4uKSBhdCB0dHlfd2FpdCsweDcxCnR0eWRldl93cml0ZShjODVlOWIwMCxjY2NkMGI4MCwwKSBh dCB0dHlkZXZfd3JpdGUrMHhjYwp0dHljb25zZGV2X3dyaXRlKGM4NWU5YjAwLGNjY2QwYjgwLDAs MCwwLC4uLikgYXQgdHR5Y29uc2Rldl93cml0ZSsweDI4CmRldmZzX3dyaXRlX2YoYzkzZWI1NDAs Y2NjZDBiODAsYzg1NzUyODAsMCxjOTMzOGQyMCwuLi4pIGF0IGRldmZzX3dyaXRlX2YrMHg5ZQpk b2ZpbGV3cml0ZShjY2NkMGI4MCxmZmZmZmZmZixmZmZmZmZmZiwwLGM5M2ViNTQwLC4uLikgYXQg ZG9maWxld3JpdGUrMHg5NQprZXJuX3dyaXRldihjOTMzOGQyMCw4LGNjY2QwYjgwLGNjY2QwYjgw LGJmYmZjZTBjLC4uLikgYXQga2Vybl93cml0ZXYrMHg1OAp3cml0ZXYoYzkzMzhkMjAsZTlmZDBj ZjgsYyxjMGNhMWJiMyxjMGQ4N2FkYywuLi4pIGF0IHdyaXRldisweDQ2CnN5c2NhbGwoZTlmZDBk MzgpIGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2Nh bGwrMHgyMAotLS0gc3lzY2FsbCAoMTIxLCBGcmVlQlNEIEVMRjMyLCB3cml0ZXYpLCBlaXAgPSAw eDI4MTc3M2ViLCBlc3AgPSAweGJmYmZjZDNjLCBlYnAgPSAweGJmYmZjZGI4IC0tLQoKVHJhY2lu ZyBjb21tYW5kIGNyZWF0IHBpZCA3OTEzNyB0aWQgMTAwNjAwIHRkIDB4Yzk1MGUwMDAKc2NoZWRf c3dpdGNoKGM5NTBlMDAwLDAsMTA0LDE5MSxkM2IyMzVhNSwuLi4pIGF0IHNjaGVkX3N3aXRjaCsw eDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgy MDAKLS1Nb3JlLS0gICAgICAgIHNsZWVwcV9zd2l0Y2goYzk1MGUwMDAsMCxjMGM5ZjM2ZiwxYTAs MCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoYzA4N2Zj ZWEsYzhhYzcyMDQsMCxjMGM5OTdlNSxjOTUwZTAwMCwuLi4pIGF0IHNsZWVwcV9jYXRjaF9zaWdu YWxzKzB4YjcKc2xlZXBxX3dhaXRfc2lnKGM4YWM3MjgwLDAsZTk3MjliNjAsMTAxLDAsLi4uKSBh dCBzbGVlcHFfd2FpdF9zaWcrMHgxNwpfY3Zfd2FpdF9zaWcoYzhhYzcyODAsYzhhYzcyMDQsYzBj YTMzM2YsNTExLGM4YWM3MjAwLC4uLikgYXQgX2N2X3dhaXRfc2lnKzB4MjQwCnR0eV93YWl0KGM4 YWM3MjAwLGM4YWM3MjgwLGMwY2EzMzNmLDlmLDE4LC4uLikgYXQgdHR5X3dhaXQrMHg3MQp0dHlk ZXZfd3JpdGUoYzhjYzY5MDAsZTk3MjljNTgsMCwwLDAsLi4uKSBhdCB0dHlkZXZfd3JpdGUrMHhj YwpkZXZmc193cml0ZV9mKGM5NGE3ZDIwLGU5NzI5YzU4LGM5YmFkYTgwLDAsYzk1MGUwMDAsLi4u KSBhdCBkZXZmc193cml0ZV9mKzB4OWUKZG9maWxld3JpdGUoZTk3MjljNTgsZmZmZmZmZmYsZmZm ZmZmZmYsMCxjOTRhN2QyMCwuLi4pIGF0IGRvZmlsZXdyaXRlKzB4OTUKa2Vybl93cml0ZXYoYzk1 MGUwMDAsMixlOTcyOWM1OCxlOTcyOWM3OCwxLC4uLikgYXQga2Vybl93cml0ZXYrMHg1OAp3cml0 ZShjOTUwZTAwMCxlOTcyOWNmOCxjLGMwY2ExOWYyLGMwZDg2ZTEwLC4uLikgYXQgd3JpdGUrMHg0 ZgpzeXNjYWxsKGU5NzI5ZDM4KSBhdCBzeXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBh dCBYaW50MHg4MF9zeXNjYWxsKzB4MjAKLS0tIHN5c2NhbGwgKDQsIEZyZWVCU0QgRUxGMzIsIHdy aXRlKSwgZWlwID0gMHgyODE4ZGM5MywgZXNwID0gMHhiZmJmZGUxYywgZWJwID0gMHhiZmJmZGUz OCAtLS0KClRyYWNpbmcgY29tbWFuZCBjcmVhdCBwaWQgNzkxMzYgdGlkIDEwMDg0MSB0ZCAweGM5 YWRiMjMwCnNjaGVkX3N3aXRjaChjOWFkYjIzMCwwLDEwNCwxOTEsZDNiNjQ5OTMsLi4uKSBhdCBz Y2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQg bWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzlhZGIyMzAsMCxjMGM5ZjM2ZiwxYTAsMCwu Li4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoYzA4N2ZjZWEs YzhhYzcyMDQsMCxjMGM5OTdlNSxjOWFkYjIzMCwuLi4pIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxz KzB4YjcKc2xlZXBxX3dhaXRfc2lnKGM4YWM3MjgwLDAsZTljOWJiNjAsMTAxLDAsLi4uKSBhdCBz bGVlcHFfd2FpdF9zaWcrMHgxNwotLU1vcmUtLSAgICAgICAgX2N2X3dhaXRfc2lnKGM4YWM3Mjgw LGM4YWM3MjA0LGMwY2EzMzNmLDUxMSxjOGFjNzIwMCwuLi4pIGF0IF9jdl93YWl0X3NpZysweDI0 MAp0dHlfd2FpdChjOGFjNzIwMCxjOGFjNzI4MCxjMGNhMzMzZiw5ZiwxOCwuLi4pIGF0IHR0eV93 YWl0KzB4NzEKdHR5ZGV2X3dyaXRlKGM4Y2M2OTAwLGU5YzliYzU4LDAsMCwwLC4uLikgYXQgdHR5 ZGV2X3dyaXRlKzB4Y2MKZGV2ZnNfd3JpdGVfZihjOTRhN2QyMCxlOWM5YmM1OCxjOWJhZGE4MCww LGM5YWRiMjMwLC4uLikgYXQgZGV2ZnNfd3JpdGVfZisweDllCmRvZmlsZXdyaXRlKGU5YzliYzU4 LGZmZmZmZmZmLGZmZmZmZmZmLDAsYzk0YTdkMjAsLi4uKSBhdCBkb2ZpbGV3cml0ZSsweDk1Cmtl cm5fd3JpdGV2KGM5YWRiMjMwLDIsZTljOWJjNTgsZTljOWJjNzgsMSwuLi4pIGF0IGtlcm5fd3Jp dGV2KzB4NTgKd3JpdGUoYzlhZGIyMzAsZTljOWJjZjgsYyxjMGNhMTlmMixjMGQ4NmUxMCwuLi4p IGF0IHdyaXRlKzB4NGYKc3lzY2FsbChlOWM5YmQzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4 MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIwCi0tLSBzeXNjYWxsICg0LCBGcmVl QlNEIEVMRjMyLCB3cml0ZSksIGVpcCA9IDB4MjgxOGRjOTMsIGVzcCA9IDB4YmZiZmRlMWMsIGVi cCA9IDB4YmZiZmRlMzggLS0tCgpUcmFjaW5nIGNvbW1hbmQgY3JlYXQgcGlkIDc5MTM0IHRpZCAx MDEwNjQgdGQgMHhjYzQyMTY5MApzY2hlZF9zd2l0Y2goY2M0MjE2OTAsMCwxMDQsMTkxLGQzYjgx MGUyLC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2Ziwx ZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGNjNDIxNjkwLDAsYzBj OWYzNmYsMWEwLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV9jYXRjaF9zaWdu YWxzKGMwODdmY2VhLGM4YWM3MjA0LDAsYzBjOTk3ZTUsY2M0MjE2OTAsLi4uKSBhdCBzbGVlcHFf Y2F0Y2hfc2lnbmFscysweGI3CnNsZWVwcV93YWl0X3NpZyhjOGFjNzI4MCwwLGU5ZjNkYjYwLDEw MSwwLC4uLikgYXQgc2xlZXBxX3dhaXRfc2lnKzB4MTcKX2N2X3dhaXRfc2lnKGM4YWM3MjgwLGM4 YWM3MjA0LGMwY2EzMzNmLDUxMSxjOGFjNzIwMCwuLi4pIGF0IF9jdl93YWl0X3NpZysweDI0MAp0 dHlfd2FpdChjOGFjNzIwMCxjOGFjNzI4MCxjMGNhMzMzZiw5ZiwxOCwuLi4pIGF0IHR0eV93YWl0 KzB4NzEKdHR5ZGV2X3dyaXRlKGM4Y2M2OTAwLGU5ZjNkYzU4LDAsMCwwLC4uLikgYXQgdHR5ZGV2 X3dyaXRlKzB4Y2MKLS1Nb3JlLS0gICAgICAgIGRldmZzX3dyaXRlX2YoYzk0YTdkMjAsZTlmM2Rj NTgsYzliYWRhODAsMCxjYzQyMTY5MCwuLi4pIGF0IGRldmZzX3dyaXRlX2YrMHg5ZQpkb2ZpbGV3 cml0ZShlOWYzZGM1OCxmZmZmZmZmZixmZmZmZmZmZiwwLGM5NGE3ZDIwLC4uLikgYXQgZG9maWxl d3JpdGUrMHg5NQprZXJuX3dyaXRldihjYzQyMTY5MCwyLGU5ZjNkYzU4LGU5ZjNkYzc4LDEsLi4u KSBhdCBrZXJuX3dyaXRldisweDU4CndyaXRlKGNjNDIxNjkwLGU5ZjNkY2Y4LGMsY2M0MjE2OTAs YzBkODZlMTAsLi4uKSBhdCB3cml0ZSsweDRmCnN5c2NhbGwoZTlmM2RkMzgpIGF0IHN5c2NhbGwr MHgyYTMKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lz Y2FsbCAoNCwgRnJlZUJTRCBFTEYzMiwgd3JpdGUpLCBlaXAgPSAweDI4MThkYzkzLCBlc3AgPSAw eGJmYmZkZTFjLCBlYnAgPSAweGJmYmZkZTM4IC0tLQoKVHJhY2luZyBjb21tYW5kIGNyZWF0IHBp ZCA3OTEzMiB0aWQgMTAwNDI0IHRkIDB4Y2JlMjg2OTAKc2NoZWRfc3dpdGNoKGNiZTI4NjkwLDAs MTA0LDE5MSxkM2I0MmRmNiwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0 LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChj YmUyODY5MCwwLGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVl cHFfY2F0Y2hfc2lnbmFscyhjMDg3ZmNlYSxjOGFjNzIwNCwwLGMwYzk5N2U1LGNiZTI4NjkwLC4u LikgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoYzhhYzcyODAs MCxlOTRjNGI2MCwxMDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysweDE3Cl9jdl93YWl0X3Np ZyhjOGFjNzI4MCxjOGFjNzIwNCxjMGNhMzMzZiw1MTEsYzhhYzcyMDAsLi4uKSBhdCBfY3Zfd2Fp dF9zaWcrMHgyNDAKdHR5X3dhaXQoYzhhYzcyMDAsYzhhYzcyODAsYzBjYTMzM2YsOWYsNywuLi4p IGF0IHR0eV93YWl0KzB4NzEKdHR5ZGV2X3dyaXRlKGM4Y2M2OTAwLGU5NGM0YzU4LDAsMCwwLC4u LikgYXQgdHR5ZGV2X3dyaXRlKzB4Y2MKZGV2ZnNfd3JpdGVfZihjOTRhN2QyMCxlOTRjNGM1OCxj OWJhZGE4MCwwLGNiZTI4NjkwLC4uLikgYXQgZGV2ZnNfd3JpdGVfZisweDllCmRvZmlsZXdyaXRl KGU5NGM0YzU4LGZmZmZmZmZmLGZmZmZmZmZmLDAsYzk0YTdkMjAsLi4uKSBhdCBkb2ZpbGV3cml0 ZSsweDk1Cmtlcm5fd3JpdGV2KGNiZTI4NjkwLDIsZTk0YzRjNTgsZTk0YzRjNzgsMSwuLi4pIGF0 IGtlcm5fd3JpdGV2KzB4NTgKLS1Nb3JlLS0gICAgICAgIHdyaXRlKGNiZTI4NjkwLGU5NGM0Y2Y4 LGMsY2JlMjg2OTAsYzBkODZlMTAsLi4uKSBhdCB3cml0ZSsweDRmCnN5c2NhbGwoZTk0YzRkMzgp IGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwr MHgyMAotLS0gc3lzY2FsbCAoNCwgRnJlZUJTRCBFTEYzMiwgd3JpdGUpLCBlaXAgPSAweDI4MThk YzkzLCBlc3AgPSAweGJmYmZkZTFjLCBlYnAgPSAweGJmYmZkZTM4IC0tLQoKVHJhY2luZyBjb21t YW5kIGNyZWF0IHBpZCA3OTEzMCB0aWQgMTAwMDk4IHRkIDB4Yzk2MjBkMjAKc2NoZWRfc3dpdGNo KGM5NjIwZDIwLDAsMTA0LDE5MSxkM2IzNDk3MiwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQpt aV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xl ZXBxX3N3aXRjaChjOTYyMGQyMCwwLGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3aXRj aCsweDE1ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscyhjMDg3ZmNlYSxjOGFjNzIwNCwwLGMwYzk5N2U1 LGM5NjIwZDIwLC4uLikgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9z aWcoYzhhYzcyODAsMCxlOGY4ZGI2MCwxMDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysweDE3 Cl9jdl93YWl0X3NpZyhjOGFjNzI4MCxjOGFjNzIwNCxjMGNhMzMzZiw1MTEsYzhhYzcyMDAsLi4u KSBhdCBfY3Zfd2FpdF9zaWcrMHgyNDAKdHR5X3dhaXQoYzhhYzcyMDAsYzhhYzcyODAsYzBjYTMz M2YsOWYsMTgsLi4uKSBhdCB0dHlfd2FpdCsweDcxCnR0eWRldl93cml0ZShjOGNjNjkwMCxlOGY4 ZGM1OCwwLDAsMCwuLi4pIGF0IHR0eWRldl93cml0ZSsweGNjCmRldmZzX3dyaXRlX2YoYzk0YTdk MjAsZThmOGRjNTgsYzliYWRhODAsMCxjOTYyMGQyMCwuLi4pIGF0IGRldmZzX3dyaXRlX2YrMHg5 ZQpkb2ZpbGV3cml0ZShlOGY4ZGM1OCxmZmZmZmZmZixmZmZmZmZmZiwwLGM5NGE3ZDIwLC4uLikg YXQgZG9maWxld3JpdGUrMHg5NQprZXJuX3dyaXRldihjOTYyMGQyMCwyLGU4ZjhkYzU4LGU4Zjhk Yzc4LDEsLi4uKSBhdCBrZXJuX3dyaXRldisweDU4CndyaXRlKGM5NjIwZDIwLGU4ZjhkY2Y4LGMs NTZjLGMwZDg2ZTEwLC4uLikgYXQgd3JpdGUrMHg0ZgpzeXNjYWxsKGU4ZjhkZDM4KSBhdCBzeXNj YWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjAKLS1N b3JlLS0gICAgICAgIC0tLSBzeXNjYWxsICg0LCBGcmVlQlNEIEVMRjMyLCB3cml0ZSksIGVpcCA9 IDB4MjgxOGRjOTMsIGVzcCA9IDB4YmZiZmRlMWMsIGVicCA9IDB4YmZiZmRlMzggLS0tCgpUcmFj aW5nIGNvbW1hbmQgY3JlYXQgcGlkIDc5MTI4IHRpZCAxMDA4MTMgdGQgMHhjOTQ3ZmFmMApzY2hl ZF9zd2l0Y2goYzk0N2ZhZjAsMCwxMDQsMTkxLGQzYjNhODFmLC4uLikgYXQgc2NoZWRfc3dpdGNo KzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsw eDIwMApzbGVlcHFfc3dpdGNoKGM5NDdmYWYwLDAsYzBjOWYzNmYsMWEwLDAsLi4uKSBhdCBzbGVl cHFfc3dpdGNoKzB4MTVmCnNsZWVwcV9jYXRjaF9zaWduYWxzKGMwODdmY2VhLGM4YWM3MjA0LDAs YzBjOTk3ZTUsYzk0N2ZhZjAsLi4uKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweGI3CnNsZWVw cV93YWl0X3NpZyhjOGFjNzI4MCwwLGU5YmVkYjYwLDEwMSwwLC4uLikgYXQgc2xlZXBxX3dhaXRf c2lnKzB4MTcKX2N2X3dhaXRfc2lnKGM4YWM3MjgwLGM4YWM3MjA0LGMwY2EzMzNmLDUxMSxjOGFj NzIwMCwuLi4pIGF0IF9jdl93YWl0X3NpZysweDI0MAp0dHlfd2FpdChjOGFjNzIwMCxjOGFjNzI4 MCxjMGNhMzMzZiw5ZiwxOCwuLi4pIGF0IHR0eV93YWl0KzB4NzEKdHR5ZGV2X3dyaXRlKGM4Y2M2 OTAwLGU5YmVkYzU4LDAsMCwwLC4uLikgYXQgdHR5ZGV2X3dyaXRlKzB4Y2MKZGV2ZnNfd3JpdGVf ZihjOTRhN2QyMCxlOWJlZGM1OCxjOWJhZGE4MCwwLGM5NDdmYWYwLC4uLikgYXQgZGV2ZnNfd3Jp dGVfZisweDllCmRvZmlsZXdyaXRlKGU5YmVkYzU4LGZmZmZmZmZmLGZmZmZmZmZmLDAsYzk0YTdk MjAsLi4uKSBhdCBkb2ZpbGV3cml0ZSsweDk1Cmtlcm5fd3JpdGV2KGM5NDdmYWYwLDIsZTliZWRj NTgsZTliZWRjNzgsMSwuLi4pIGF0IGtlcm5fd3JpdGV2KzB4NTgKd3JpdGUoYzk0N2ZhZjAsZTli ZWRjZjgsYyxjMGNhMTlmMixjMGQ4NmUxMCwuLi4pIGF0IHdyaXRlKzB4NGYKc3lzY2FsbChlOWJl ZGQzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lz Y2FsbCsweDIwCi0tLSBzeXNjYWxsICg0LCBGcmVlQlNEIEVMRjMyLCB3cml0ZSksIGVpcCA9IDB4 MjgxOGRjOTMsIGVzcCA9IDB4YmZiZmRlMWMsIGVicCA9IDB4YmZiZmRlMzggLS0tCgpUcmFjaW5n IGNvbW1hbmQgY3JlYXQgcGlkIDc5MTI2IHRpZCAxMDEwMjAgdGQgMHhjYmVhYzIzMAotLU1vcmUt LSAgICAgICAgY3B1c3RvcF9oYW5kbGVyKDEsZTllYjk4MzAsYzBiYzhmZDYsODAwMDAwMDAsMzY5 ZTk5LC4uLikgYXQgY3B1c3RvcF9oYW5kbGVyKzB4MzIKaXBpX25taV9oYW5kbGVyKDgwMDAwMDAw LDM2OWU5OSwwLDAsY2MzNzhkNDgsLi4uKSBhdCBpcGlfbm1pX2hhbmRsZXIrMHgyZgp0cmFwKGU5 ZWI5ODNjKSBhdCB0cmFwKzB4MzYKY2FsbHRyYXAoKSBhdCBjYWxsdHJhcCsweDYKLS0tIHRyYXAg MHgxMywgZWlwID0gMHhjMDg4ZGM3MiwgZXNwID0gMHhlOWViOTg3YywgZWJwID0gMHhlOWViOTg5 YyAtLS0KX3J3X3Jsb2NrKGMwZjViZDNjLGMwY2E3Mzc2LDE4NixjOWJhZGE4MCxjYmVhYzIzMCwu Li4pIGF0IF9yd19ybG9jaysweDE1MgpjYWNoZV9sb29rdXAoYzk2ZjE4ODAsZTllYjliYmMsZTll YjliZDAsZTllYjliYmMsYzliYWRhODAsLi4uKSBhdCBjYWNoZV9sb29rdXArMHg0Ngp2ZnNfY2Fj aGVfbG9va3VwKGU5ZWI5OTg4LGU5ZWI5OTg4LGU5ZWI5YmE0LDgwMDAwLGU5ZWI5YmE0LC4uLikg YXQgdmZzX2NhY2hlX2xvb2t1cCsweGFkClZPUF9MT09LVVBfQVBWKGMwZGE4YTgwLGU5ZWI5OTg4 LGU5ZWI5YmQwLDFmMSxlOWViOWJiYywuLi4pIGF0IFZPUF9MT09LVVBfQVBWKzB4YTUKbG9va3Vw KGU5ZWI5YmE0LGMwY2E3YWVhLGVhLGM1LGZmZmZmZjljLC4uLikgYXQgbG9va3VwKzB4NjZiCm5h bWVpKGU5ZWI5YmE0LGMwY2EzZjljLDIsMzgsMCwuLi4pIGF0IG5hbWVpKzB4NTVmCnZuX29wZW5f Y3JlZChlOWViOWJhNCxlOWViOWM1YywxYjAsMCxjOWJhZGE4MCwuLi4pIGF0IHZuX29wZW5fY3Jl ZCsweDkwCnZuX29wZW4oZTllYjliYTQsZTllYjljNWMsMWIwLGM5NDg2Yzc4LGMwODgwMjM5LC4u LikgYXQgdm5fb3BlbisweDNiCmtlcm5fb3BlbmF0KGNiZWFjMjMwLGZmZmZmZjljLGJmYmZlOGQ0 LDAsNjAyLC4uLikgYXQga2Vybl9vcGVuYXQrMHgxMWYKa2Vybl9vcGVuKGNiZWFjMjMwLGJmYmZl OGQ0LDAsNjAxLDFiMCwuLi4pIGF0IGtlcm5fb3BlbisweDM1Cm9wZW4oY2JlYWMyMzAsZTllYjlj ZjgsYyxjMGNhMTliNixjMGQ4NmUyYywuLi4pIGF0IG9wZW4rMHgzMApzeXNjYWxsKGU5ZWI5ZDM4 KSBhdCBzeXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxs KzB4MjAKLS0tIHN5c2NhbGwgKDUsIEZyZWVCU0QgRUxGMzIsIG9wZW4pLCBlaXAgPSAweDI4MTdk MjAzLCBlc3AgPSAweGJmYmZlODdjLCBlYnAgPSAweGJmYmZlODk4IC0tLQoKLS1Nb3JlLS0gICAg ICAgIFRyYWNpbmcgY29tbWFuZCBjcmVhdCBwaWQgNzkxMjQgdGlkIDEwMDg0NyB0ZCAweGNiZmY1 MDAwCnNjaGVkX3N3aXRjaChjYmZmNTAwMCwwLDEwNCwxOTEsZDNiNTc1NzEsLi4uKSBhdCBzY2hl ZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlf c3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goY2JmZjUwMDAsMCxjMGM5ZjM2ZiwxYTAsMCwuLi4p IGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoYzA4N2ZjZWEsYzhh YzcyMDQsMCxjMGM5OTdlNSxjYmZmNTAwMCwuLi4pIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4 YjcKc2xlZXBxX3dhaXRfc2lnKGM4YWM3MjgwLDAsZTljYWRiNjAsMTAxLDAsLi4uKSBhdCBzbGVl cHFfd2FpdF9zaWcrMHgxNwpfY3Zfd2FpdF9zaWcoYzhhYzcyODAsYzhhYzcyMDQsYzBjYTMzM2Ys NTExLGM4YWM3MjAwLC4uLikgYXQgX2N2X3dhaXRfc2lnKzB4MjQwCnR0eV93YWl0KGM4YWM3MjAw LGM4YWM3MjgwLGMwY2EzMzNmLDlmLDE4LC4uLikgYXQgdHR5X3dhaXQrMHg3MQp0dHlkZXZfd3Jp dGUoYzhjYzY5MDAsZTljYWRjNTgsMCwwLDAsLi4uKSBhdCB0dHlkZXZfd3JpdGUrMHhjYwpkZXZm c193cml0ZV9mKGM5NGE3ZDIwLGU5Y2FkYzU4LGM5YmFkYTgwLDAsY2JmZjUwMDAsLi4uKSBhdCBk ZXZmc193cml0ZV9mKzB4OWUKZG9maWxld3JpdGUoZTljYWRjNTgsZmZmZmZmZmYsZmZmZmZmZmYs MCxjOTRhN2QyMCwuLi4pIGF0IGRvZmlsZXdyaXRlKzB4OTUKa2Vybl93cml0ZXYoY2JmZjUwMDAs MixlOWNhZGM1OCxlOWNhZGM3OCwxLC4uLikgYXQga2Vybl93cml0ZXYrMHg1OAp3cml0ZShjYmZm NTAwMCxlOWNhZGNmOCxjLDU2YyxjMGQ4NmUxMCwuLi4pIGF0IHdyaXRlKzB4NGYKc3lzY2FsbChl OWNhZGQzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBf c3lzY2FsbCsweDIwCi0tLSBzeXNjYWxsICg0LCBGcmVlQlNEIEVMRjMyLCB3cml0ZSksIGVpcCA9 IDB4MjgxOGRjOTMsIGVzcCA9IDB4YmZiZmRlMWMsIGVicCA9IDB4YmZiZmRlMzggLS0tCgpUcmFj aW5nIGNvbW1hbmQgY3JlYXQgcGlkIDc5MTIyIHRpZCAxMDAyMDIgdGQgMHhjOTYzM2FmMApzY2hl ZF9zd2l0Y2goYzk2MzNhZjAsMCwxMDMsMThjLDQ4ZmIzNmJhLC4uLikgYXQgc2NoZWRfc3dpdGNo KzB4MWM1Cm1pX3N3aXRjaCgxMDMsMCxjMGM5ZmMwZSwyZTIsYzlkM2UyODAsLi4uKSBhdCBtaV9z d2l0Y2grMHgyMDAKLS1Nb3JlLS0gICAgICAgIHR1cm5zdGlsZV93YWl0KGM5ZDNlMjgwLDAsMCxj MGY1YmQzYyxjMGYyY2IxMCwuLi4pIGF0IHR1cm5zdGlsZV93YWl0KzB4NDk1Cl9yd193bG9ja19o YXJkKGMwZjViZDNjLGM5NjMzYWYwLGMwY2E3Mzc2LDIwOSwwLC4uLikgYXQgX3J3X3dsb2NrX2hh cmQrMHgyMGMKX3J3X3dsb2NrKGMwZjViZDNjLGMwY2E3Mzc2LDIwOSxlOTE0Nzk5MCxlOTE0N2I4 OCwuLi4pIGF0IF9yd193bG9jaysweGFlCmNhY2hlX2xvb2t1cChjOTllOWFhMCxlOTE0N2I3NCxl OTE0N2I4OCwwLDAsLi4uKSBhdCBjYWNoZV9sb29rdXArMHg0NmYKbmZzX2xvb2t1cChlOTE0N2E1 MCxlOTE0N2E1MCxlOTE0N2I1YywyMDAwMDAsZTkxNDdiNWMsLi4uKSBhdCBuZnNfbG9va3VwKzB4 ZjYKVk9QX0xPT0tVUF9BUFYoYzBkYTVmZTAsZTkxNDdhNTAsZTkxNDdiODgsMWYxLGU5MTQ3Yjc0 LC4uLikgYXQgVk9QX0xPT0tVUF9BUFYrMHhhNQpsb29rdXAoZTkxNDdiNWMsYzBjYTdhZWEsZWEs YzUsYzk2MmNhYTAsLi4uKSBhdCBsb29rdXArMHg2NmIKbmFtZWkoZTkxNDdiNWMsYzA4ZDNhYWIs YzBjOTRjOTYsYzBjOTJkZjksMywuLi4pIGF0IG5hbWVpKzB4NTVmCmtlcm5fc3RhdGF0X3ZuaG9v ayhjOTYzM2FmMCwwLGZmZmZmZjljLGJmYmZkZjc4LDAsLi4uKSBhdCBrZXJuX3N0YXRhdF92bmhv b2srMHg3MgprZXJuX3N0YXRhdChjOTYzM2FmMCwwLGZmZmZmZjljLGJmYmZkZjc4LDAsLi4uKSBh dCBrZXJuX3N0YXRhdCsweDNjCmtlcm5fc3RhdChjOTYzM2FmMCxiZmJmZGY3OCwwLGU5MTQ3YzE4 LDIsLi4uKSBhdCBrZXJuX3N0YXQrMHgzNgpzdGF0KGM5NjMzYWYwLGU5MTQ3Y2Y4LDgsYzBjODI4 ZjQsYzBkODgyMzAsLi4uKSBhdCBzdGF0KzB4MmYKc3lzY2FsbChlOTE0N2QzOCkgYXQgc3lzY2Fs bCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIwCi0tLSBz eXNjYWxsICgxODgsIEZyZWVCU0QgRUxGMzIsIHN0YXQpLCBlaXAgPSAweDI4MTdkMWEzLCBlc3Ag PSAweGJmYmZkZWNjLCBlYnAgPSAweGJmYmZlMzg4IC0tLQoKVHJhY2luZyBjb21tYW5kIGNyZWF0 IHBpZCA3OTEyMCB0aWQgMTAwOTI1IHRkIDB4Y2FkZWI4YzAKc2NoZWRfc3dpdGNoKGNhZGViOGMw LDAsMTA0LDE5MSxkM2IzNzQyMCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2go MTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRj aChjYWRlYjhjMCwwLGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1Zgot LU1vcmUtLSAgICAgICAgc2xlZXBxX2NhdGNoX3NpZ25hbHMoYzA4N2ZjZWEsYzhhYzcyMDQsMCxj MGM5OTdlNSxjYWRlYjhjMCwuLi4pIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4YjcKc2xlZXBx X3dhaXRfc2lnKGM4YWM3MjgwLDAsZTlkOTdiNjAsMTAxLDAsLi4uKSBhdCBzbGVlcHFfd2FpdF9z aWcrMHgxNwpfY3Zfd2FpdF9zaWcoYzhhYzcyODAsYzhhYzcyMDQsYzBjYTMzM2YsNTExLGM4YWM3 MjAwLC4uLikgYXQgX2N2X3dhaXRfc2lnKzB4MjQwCnR0eV93YWl0KGM4YWM3MjAwLGM4YWM3Mjgw LGMwY2EzMzNmLDlmLDE4LC4uLikgYXQgdHR5X3dhaXQrMHg3MQp0dHlkZXZfd3JpdGUoYzhjYzY5 MDAsZTlkOTdjNTgsMCwwLDAsLi4uKSBhdCB0dHlkZXZfd3JpdGUrMHhjYwpkZXZmc193cml0ZV9m KGM5NGE3ZDIwLGU5ZDk3YzU4LGM5YmFkYTgwLDAsY2FkZWI4YzAsLi4uKSBhdCBkZXZmc193cml0 ZV9mKzB4OWUKZG9maWxld3JpdGUoZTlkOTdjNTgsZmZmZmZmZmYsZmZmZmZmZmYsMCxjOTRhN2Qy MCwuLi4pIGF0IGRvZmlsZXdyaXRlKzB4OTUKa2Vybl93cml0ZXYoY2FkZWI4YzAsMixlOWQ5N2M1 OCxlOWQ5N2M3OCwxLC4uLikgYXQga2Vybl93cml0ZXYrMHg1OAp3cml0ZShjYWRlYjhjMCxlOWQ5 N2NmOCxjLGMwY2ExOWYyLGMwZDg2ZTEwLC4uLikgYXQgd3JpdGUrMHg0ZgpzeXNjYWxsKGU5ZDk3 ZDM4KSBhdCBzeXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNj YWxsKzB4MjAKLS0tIHN5c2NhbGwgKDQsIEZyZWVCU0QgRUxGMzIsIHdyaXRlKSwgZWlwID0gMHgy ODE4ZGM5MywgZXNwID0gMHhiZmJmZGUxYywgZWJwID0gMHhiZmJmZGUzOCAtLS0KClRyYWNpbmcg Y29tbWFuZCBjcmVhdCBwaWQgNzkxMTggdGlkIDEwMDQyMCB0ZCAweGM5NWE1MDAwCnNjaGVkX3N3 aXRjaChjOTVhNTAwMCwwLDEwNCwxOTEsZDNiNzZhMzUsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgx YzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAw CnNsZWVwcV9zd2l0Y2goYzk1YTUwMDAsMCxjMGM5ZjM2ZiwxYTAsMCwuLi4pIGF0IHNsZWVwcV9z d2l0Y2grMHgxNWYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoYzA4N2ZjZWEsYzhhYzcyMDQsMCxjMGM5 OTdlNSxjOTVhNTAwMCwuLi4pIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4YjcKc2xlZXBxX3dh aXRfc2lnKGM4YWM3MjgwLDAsZTk0YjJiNjAsMTAxLDAsLi4uKSBhdCBzbGVlcHFfd2FpdF9zaWcr MHgxNwpfY3Zfd2FpdF9zaWcoYzhhYzcyODAsYzhhYzcyMDQsYzBjYTMzM2YsNTExLGM4YWM3MjAw LC4uLikgYXQgX2N2X3dhaXRfc2lnKzB4MjQwCi0tTW9yZS0tICAgICAgICB0dHlfd2FpdChjOGFj NzIwMCxjOGFjNzI4MCxjMGNhMzMzZiw5ZiwxOCwuLi4pIGF0IHR0eV93YWl0KzB4NzEKdHR5ZGV2 X3dyaXRlKGM4Y2M2OTAwLGU5NGIyYzU4LDAsMCwwLC4uLikgYXQgdHR5ZGV2X3dyaXRlKzB4Y2MK ZGV2ZnNfd3JpdGVfZihjOTRhN2QyMCxlOTRiMmM1OCxjOWJhZGE4MCwwLGM5NWE1MDAwLC4uLikg YXQgZGV2ZnNfd3JpdGVfZisweDllCmRvZmlsZXdyaXRlKGU5NGIyYzU4LGZmZmZmZmZmLGZmZmZm ZmZmLDAsYzk0YTdkMjAsLi4uKSBhdCBkb2ZpbGV3cml0ZSsweDk1Cmtlcm5fd3JpdGV2KGM5NWE1 MDAwLDIsZTk0YjJjNTgsZTk0YjJjNzgsMSwuLi4pIGF0IGtlcm5fd3JpdGV2KzB4NTgKd3JpdGUo Yzk1YTUwMDAsZTk0YjJjZjgsYyxjMGNhMTlmMixjMGQ4NmUxMCwuLi4pIGF0IHdyaXRlKzB4NGYK c3lzY2FsbChlOTRiMmQzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQg WGludDB4ODBfc3lzY2FsbCsweDIwCi0tLSBzeXNjYWxsICg0LCBGcmVlQlNEIEVMRjMyLCB3cml0 ZSksIGVpcCA9IDB4MjgxOGRjOTMsIGVzcCA9IDB4YmZiZmRlMWMsIGVicCA9IDB4YmZiZmRlMzgg LS0tCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMTYgdGlkIDEwMTI1NSB0ZCAweGM5YTI4 NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5k IHRocjEgcGlkIDc5MTE2IHRpZCAxMDE1MjAgdGQgMHhjY2RlMjY5MApzY2hlZF9zd2l0Y2goY2Nk ZTI2OTAsMCwxMDQsMTkxLDQ3YmUwNTUxLC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3 aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFf c3dpdGNoKGNjZGUyNjkwLDAsYzBjOWYzNmYsMWEwLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4 MTVmCnNsZWVwcV9jYXRjaF9zaWduYWxzKGMwYzlmMzZmLDE2MCwwLDEwMCwxMDAsLi4uKSBhdCBz bGVlcHFfY2F0Y2hfc2lnbmFscysweGI3CnNsZWVwcV93YWl0X3NpZyhjOGFiOTk4MCwwLGMwYzlj ODllLDEwMCwwLC4uLikgYXQgc2xlZXBxX3dhaXRfc2lnKzB4MTcKX3NsZWVwKGM4YWI5OTgwLGMw ZGY5MmIwLDEwMCxjMGM5Yzg5ZSwwLC4uLikgYXQgX3NsZWVwKzB4MzU0Ci0tTW9yZS0tICAgICAg ICBfZG9fbG9ja191bXV0ZXgoMCwyLDI4MGI0MGUwLGNjZGUyNjkwLGMwODllNWQ1LC4uLikgYXQg X2RvX2xvY2tfdW11dGV4KzB4ODhjCmRvX2xvY2tfdW11dGV4KDIsMCxjY2RlMjY5MCxlYTU1MmM4 MCxjMDhjZDVkMCkgYXQgZG9fbG9ja191bXV0ZXgrMHg0ZApfX3VtdHhfb3Bfd2FpdF91bXV0ZXgo Y2NkZTI2OTAsZWE1NTJjZjgsZWE1NTJkMmMsYzBiYzhkNTMsY2NkZTI2OTAsLi4uKSBhdCBfX3Vt dHhfb3Bfd2FpdF91bXV0ZXgrMHg1MApfdW10eF9vcChjY2RlMjY5MCxlYTU1MmNmOCwxNCxjMGNh MTliNixjMGQ4OWY0OCwuLi4pIGF0IF91bXR4X29wKzB4MjcKc3lzY2FsbChlYTU1MmQzOCkgYXQg c3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIw Ci0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGMzIsIF91bXR4X29wKSwgZWlwID0gMHgyODBi MTMxNywgZXNwID0gMHhiNDU0YWVhYywgZWJwID0gMHhiNDU0YWVkOCAtLS0KClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTExNiB0aWQgMTAxNTEzIHRkIDB4Y2NmNjY4YzAKc2NoZWRfc3dpdGNo KGNjZjY2OGMwLDAsMTA0LDE5MSw0N2JiOTQ4NSwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQpt aV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xl ZXBxX3N3aXRjaChjY2Y2NjhjMCwwLGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3aXRj aCsweDE1ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscyhjMGM5ZjM2ZiwxNjAsMCwxMDAsMTAwLC4uLikg YXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoY2JmNDYyODAsMCxj MGM5Yzg5ZSwxMDAsMCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysweDE3Cl9zbGVlcChjYmY0NjI4 MCxjMGRmOTJiMCwxMDAsYzBjOWM4OWUsMCwuLi4pIGF0IF9zbGVlcCsweDM1NApfZG9fbG9ja191 bXV0ZXgoMCwyLDI4MGI0MGUwLGNjZjY2OGMwLGMwODllNWQ1LC4uLikgYXQgX2RvX2xvY2tfdW11 dGV4KzB4ODhjCmRvX2xvY2tfdW11dGV4KDIsMCxjY2Y2NjhjMCxlYTM5ZmM4MCxjMDhjZDVkMCkg YXQgZG9fbG9ja191bXV0ZXgrMHg0ZApfX3VtdHhfb3Bfd2FpdF91bXV0ZXgoY2NmNjY4YzAsZWEz OWZjZjgsZWEzOWZkMmMsYzBiYzhkNTMsY2NmNjY4YzAsLi4uKSBhdCBfX3VtdHhfb3Bfd2FpdF91 bXV0ZXgrMHg1MApfdW10eF9vcChjY2Y2NjhjMCxlYTM5ZmNmOCwxNCxjMGNhMTliNixjMGQ4OWY0 OCwuLi4pIGF0IF91bXR4X29wKzB4MjcKc3lzY2FsbChlYTM5ZmQzOCkgYXQgc3lzY2FsbCsweDJh MwotLU1vcmUtLSAgICAgICAgWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwr MHgyMAotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjMyLCBfdW10eF9vcCksIGVpcCA9IDB4 MjgwYjEzMTcsIGVzcCA9IDB4YjQ2NGJlYWMsIGVicCA9IDB4YjQ2NGJlZDggLS0tCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkxMTYgdGlkIDEwMDI3OSB0ZCAweGM5ZDNjMDAwCnNjaGVkX3N3 aXRjaChjOWQzYzAwMCwwLDEwNCwxOTEsNDdiZWM2ODksLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgx YzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAw CnNsZWVwcV9zd2l0Y2goYzlkM2MwMDAsMCxjMGM5ZjM2ZiwxYTAsMCwuLi4pIGF0IHNsZWVwcV9z d2l0Y2grMHgxNWYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoYzBjOWYzNmYsMTYwLDAsMTAwLDEwMCwu Li4pIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4YjcKc2xlZXBxX3dhaXRfc2lnKGM4ZDY5Njgw LDAsYzBjOWM5MTcsMTAwLDAsLi4uKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHgxNwpfc2xlZXAoYzhk Njk2ODAsYzBkZmE4NDAsMTAwLGMwYzljOTE3LDAsLi4uKSBhdCBfc2xlZXArMHgzNTQKZG9fd2Fp dCgwLDAsMCxlOTI3ZWM4MCxjMDhjZDVkMCkgYXQgZG9fd2FpdCsweDUxMQpfX3VtdHhfb3Bfd2Fp dChjOWQzYzAwMCxlOTI3ZWNmOCxlOTI3ZWQyYyxjMGJjOGQ1MyxjOWQzYzAwMCwuLi4pIGF0IF9f dW10eF9vcF93YWl0KzB4NWYKX3VtdHhfb3AoYzlkM2MwMDAsZTkyN2VjZjgsMTQsYzBjYTI4MzAs YzBkODlmNDgsLi4uKSBhdCBfdW10eF9vcCsweDI3CnN5c2NhbGwoZTkyN2VkMzgpIGF0IHN5c2Nh bGwrMHgyYTMKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0g c3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjMyLCBfdW10eF9vcCksIGVpcCA9IDB4MjgwYjEzMTcs IGVzcCA9IDB4YmZiZmU0YWMsIGVicCA9IDB4YmZiZmU0YzggLS0tCgpUcmFjaW5nIGNvbW1hbmQg Y3JlYXQgcGlkIDc5MTE1IHRpZCAxMDA3NTQgdGQgMHhjOWFlNjAwMApjcHVzdG9wX2hhbmRsZXIo OCxlOWI0MmJhOCxjMGJjOGZkNixlOWI0MmIzOCxjMDg3ZjkzNCwuLi4pIGF0IGNwdXN0b3BfaGFu ZGxlcisweDMyCmlwaV9ubWlfaGFuZGxlcihlOWI0MmIzOCxjMDg3ZjkzNCxjMGRmODdiNCw0LGNj NGZjMmE4LC4uLikgYXQgaXBpX25taV9oYW5kbGVyKzB4MmYKLS1Nb3JlLS0gICAgICAgIHRyYXAo ZTliNDJiYjQpIGF0IHRyYXArMHgzNgpjYWxsdHJhcCgpIGF0IGNhbGx0cmFwKzB4NgotLS0gdHJh cCAweDEzLCBlaXAgPSAweGMwODhkYzgwLCBlc3AgPSAweGU5YjQyYmY0LCBlYnAgPSAweGU5YjQy YzE0IC0tLQpfcndfcmxvY2soYzBmNWJkM2MsYzBjYTczNzYsNDc1LGNhMWNhZGQwLGM5MmI2MjIw LC4uLikgYXQgX3J3X3Jsb2NrKzB4MTYwCnZuX2Z1bGxwYXRoMShjOTc2YTQwMCxlOWI0MmM1OCwz ZmYsM2E0LGM5NzZhNDAwLC4uLikgYXQgdm5fZnVsbHBhdGgxKzB4NDMKa2Vybl9fX2dldGN3ZChj OWFlNjAwMCxiZmJmZGUyYiwwLDQwMSxlOWI0MmQyYywuLi4pIGF0IGtlcm5fX19nZXRjd2QrMHhk MApfX2dldGN3ZChjOWFlNjAwMCxlOWI0MmNmOCw4LGMwYzgxOWE3LGMwZDg5MTQ4LC4uLikgYXQg X19nZXRjd2QrMHgyOQpzeXNjYWxsKGU5YjQyZDM4KSBhdCBzeXNjYWxsKzB4MmEzClhpbnQweDgw X3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjAKLS0tIHN5c2NhbGwgKDMyNiwgRnJl ZUJTRCBFTEYzMiwgX19nZXRjd2QpLCBlaXAgPSAweDI4MTAwYzNiLCBlc3AgPSAweGJmYmZkZDNj LCBlYnAgPSAweGJmYmZkZGY4IC0tLQoKVHJhY2luZyBjb21tYW5kIGNyZWF0IHBpZCA3OTExMyB0 aWQgMTAwNDk1IHRkIDB4Yzk1YWJhZjAKc2NoZWRfc3dpdGNoKGM5NWFiYWYwLDAsMTA0LDE5MSw0 OGM2YzMxNCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYz NmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjOTVhYmFmMCww LGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfY2F0Y2hf c2lnbmFscyhjMDg3ZmNlYSxjOGFjNzIwNCwwLGMwYzk5N2U1LGM5NWFiYWYwLC4uLikgYXQgc2xl ZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoYzhhYzcyODAsMCxlOTVkZGI2 MCwxMDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysweDE3Cl9jdl93YWl0X3NpZyhjOGFjNzI4 MCxjOGFjNzIwNCxjMGNhMzMzZiw1MTEsYzhhYzcyMDAsLi4uKSBhdCBfY3Zfd2FpdF9zaWcrMHgy NDAKdHR5X3dhaXQoYzhhYzcyMDAsYzhhYzcyODAsYzBjYTMzM2YsOWYsMjAsLi4uKSBhdCB0dHlf d2FpdCsweDcxCnR0eWRldl93cml0ZShjOGNjNjkwMCxlOTVkZGM1OCwwLDAsMCwuLi4pIGF0IHR0 eWRldl93cml0ZSsweGNjCi0tTW9yZS0tICAgICAgICBkZXZmc193cml0ZV9mKGM5NGE3ZDIwLGU5 NWRkYzU4LGM5YmFkYTgwLDAsYzk1YWJhZjAsLi4uKSBhdCBkZXZmc193cml0ZV9mKzB4OWUKZG9m aWxld3JpdGUoZTk1ZGRjNTgsZmZmZmZmZmYsZmZmZmZmZmYsMCxjOTRhN2QyMCwuLi4pIGF0IGRv ZmlsZXdyaXRlKzB4OTUKa2Vybl93cml0ZXYoYzk1YWJhZjAsMixlOTVkZGM1OCxlOTVkZGM3OCwx LC4uLikgYXQga2Vybl93cml0ZXYrMHg1OAp3cml0ZShjOTVhYmFmMCxlOTVkZGNmOCxjLGMwYzgy OGY0LGMwZDg2ZTEwLC4uLikgYXQgd3JpdGUrMHg0ZgpzeXNjYWxsKGU5NWRkZDM4KSBhdCBzeXNj YWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjAKLS0t IHN5c2NhbGwgKDQsIEZyZWVCU0QgRUxGMzIsIHdyaXRlKSwgZWlwID0gMHgyODE4ZGM5MywgZXNw ID0gMHhiZmJmZGU0YywgZWJwID0gMHhiZmJmZGU2OCAtLS0KClRyYWNpbmcgY29tbWFuZCB0aHIx IHBpZCA3OTExMSB0aWQgMTAxNDU1IHRkIDB4Y2NlMGM0NjAKZm9ya190cmFtcG9saW5lKCkgYXQg Zm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTQ0 OCB0ZCAweGNjZjgxYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJh Y2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTExIHRpZCAxMDE0MzkgdGQgMHhjY2RlMTQ2MApmb3Jr X3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBp ZCA3OTExMSB0aWQgMTAxNDMyIHRkIDB4Y2JmMjk2OTAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lCgotLU1vcmUtLSAgICAgICAgVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5 MTExIHRpZCAxMDE0MjQgdGQgMHhjY2QzMjhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTExMSB0aWQgMTAxNDE2IHRkIDB4 Y2NkNzU4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNv bW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTQxMCB0ZCAweGNjZjI3NDYwCmZvcmtfdHJhbXBv bGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTEx IHRpZCAxMDE0MDMgdGQgMHhjY2RjNWQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1w b2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTExMSB0aWQgMTAxMzk2IHRkIDB4Y2Nm MTEyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1h bmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTM4OSB0ZCAweGNiNzg3MjMwCmZvcmtfdHJhbXBvbGlu ZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTExIHRp ZCAxMDEzODAgdGQgMHhjZDAwZGQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUKLS1Nb3JlLS0gICAgICAgIApUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEw MTM3MyB0ZCAweGNjZjJkOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoK VHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTExIHRpZCAxMDEzNzAgdGQgMHhjY2YwNjQ2MApm b3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIx IHBpZCA3OTExMSB0aWQgMTAxMzYzIHRkIDB4YzkzYWM4YzAKZm9ya190cmFtcG9saW5lKCkgYXQg Zm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTM1 NyB0ZCAweGM5MjI3ZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJh Y2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTExIHRpZCAxMDEzNTAgdGQgMHhjY2UzYmFmMApmb3Jr X3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBp ZCA3OTExMSB0aWQgMTAxMzE2IHRkIDB4Y2NlYWM0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTM0MiB0 ZCAweGNjZDM4NDYwCi0tTW9yZS0tICAgICAgICBmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTExMSB0aWQgMTAxMzQwIHRkIDB4 Y2NmMTAyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNv bW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTI5NCB0ZCAweGNjZTdmNjkwCmZvcmtfdHJhbXBv bGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTEx IHRpZCAxMDEyMzIgdGQgMHhjY2VmNzAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1w b2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTExMSB0aWQgMTAxMjY4IHRkIDB4Y2Nm NGEwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1h bmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTE5NiB0ZCAweGNjZjYwMjMwCmZvcmtfdHJhbXBvbGlu ZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTExIHRp ZCAxMDExOTcgdGQgMHhjY2QxZWFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUKCi0tTW9yZS0tICAgICAgICBUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEw MTMzOCB0ZCAweGNjZGFmMjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoK VHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTExIHRpZCAxMDEzMzMgdGQgMHhjY2Q0MWFmMApm b3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIx IHBpZCA3OTExMSB0aWQgMTAxMzI5IHRkIDB4Y2NkN2ZhZjAKZm9ya190cmFtcG9saW5lKCkgYXQg Zm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTMy NSB0ZCAweGNjZDg2NDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJh Y2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTExIHRpZCAxMDEzMjEgdGQgMHhjOTNhYzAwMApmb3Jr X3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBp ZCA3OTExMSB0aWQgMTAxMzE1IHRkIDB4YzliY2VkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTMxMCB0 ZCAweGM5YTI4MjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQotLU1vcmUt LSAgICAgICAgClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTExMSB0aWQgMTAxMzA1IHRkIDB4 Y2NkZmI4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNv bW1hbmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTIyMiB0ZCAweGNjZjAwMDAwCmZvcmtfdHJhbXBv bGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTEx IHRpZCAxMDEyMTMgdGQgMHhjY2YxYzhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1w b2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTExMSB0aWQgMTAxMjA0IHRkIDB4Y2I1 YWM2OTAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1h bmQgdGhyMSBwaWQgNzkxMTEgdGlkIDEwMTIwMyB0ZCAweGNjZDE3NDYwCmZvcmtfdHJhbXBvbGlu ZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTExIHRp ZCAxMDA0NjUgdGQgMHhjYmZhOGFmMApzY2hlZF9zd2l0Y2goY2JmYThhZjAsMCwxMDQsMTkxLDQ4 YzYxZjAxLC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2 ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGNiZmE4YWYwLDAs YzBjOWYzNmYsMWEwLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCi0tTW9yZS0tICAgICAg ICBzbGVlcHFfY2F0Y2hfc2lnbmFscyhjMGM5ZjM2ZiwxNjAsMCwxMDAsMTAwLC4uLikgYXQgc2xl ZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoY2JlMGU2ODAsMCxjMGM5Yzkx NywxMDAsMCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysweDE3Cl9zbGVlcChjYmUwZTY4MCxjMGRm YmJmMCwxMDAsYzBjOWM5MTcsMCwuLi4pIGF0IF9zbGVlcCsweDM1NApkb193YWl0KDAsMCwwLGU5 NTQ1YzgwLGMwOGNkNWQwKSBhdCBkb193YWl0KzB4NTExCl9fdW10eF9vcF93YWl0KGNiZmE4YWYw LGU5NTQ1Y2Y4LGU5NTQ1ZDJjLGMwYmM4ZDUzLGNiZmE4YWYwLC4uLikgYXQgX191bXR4X29wX3dh aXQrMHg1ZgpfdW10eF9vcChjYmZhOGFmMCxlOTU0NWNmOCwxNCxlOTU0NWNhMCxjMGQ4OWY0OCwu Li4pIGF0IF91bXR4X29wKzB4MjcKc3lzY2FsbChlOTU0NWQzOCkgYXQgc3lzY2FsbCsweDJhMwpY aW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIwCi0tLSBzeXNjYWxsICg0 NTQsIEZyZWVCU0QgRUxGMzIsIF91bXR4X29wKSwgZWlwID0gMHgyODBiMTMxNywgZXNwID0gMHhi ZmJmZTRhYywgZWJwID0gMHhiZmJmZTRjOCAtLS0KClRyYWNpbmcgY29tbWFuZCBjcmVhdCBwaWQg NzkxMTAgdGlkIDEwMDIyNSB0ZCAweGM5YTYwYWYwCnNjaGVkX3N3aXRjaChjOWE2MGFmMCwwLDIw NywxOGMsNDhlOTMxOTgsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDIwNyww LGMwYzlmYmI5LGQ2LGJjLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCmFzdChlOTFhN2QzOCkgYXQg YXN0KzB4MmIzCmRvcmV0aV9hc3QoKSBhdCBkb3JldGlfYXN0KzB4MTcKClRyYWNpbmcgY29tbWFu ZCBjcmVhdCBwaWQgNzkxMDggdGlkIDEwMDU3NCB0ZCAweGNhZGYxOGMwCnNjaGVkX3N3aXRjaChj YWRmMThjMCwwLDIwNywxOGMsNDhmNDkxZjksLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlf c3dpdGNoKDIwNywwLGMwYzlmYmI5LGQ2LGJjLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCmFzdChl OTZkYmQzOCkgYXQgYXN0KzB4MmIzCi0tTW9yZS0tICAgICAgICBkb3JldGlfYXN0KCkgYXQgZG9y ZXRpX2FzdCsweDE3CgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDcgdGlkIDEwMTI5MCB0 ZCAweGNjZGUzOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MTA3IHRpZCAxMDEyODUgdGQgMHhjY2U1ZjY5MApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTEwNyB0aWQgMTAxMjc5IHRkIDB4Y2NmMjcwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDcgdGlkIDEwMTI3NiB0ZCAw eGNhNjZjOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MTA3IHRpZCAxMDEyNjMgdGQgMHhjOTNjMzIzMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEw NyB0aWQgMTAxMjQ0IHRkIDB4Y2NmMTM2OTAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgotLU1vcmUtLSAgICAgICAgVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA3IHRp ZCAxMDEyMzkgdGQgMHhjYmVlNThjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNyB0aWQgMTAxMjIzIHRkIDB4Y2NmNjY0 NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkxMDcgdGlkIDEwMTIxNCB0ZCAweGNjZTI3ZDIwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA3IHRpZCAx MDEyMDkgdGQgMHhjY2Q5OGQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNyB0aWQgMTAxMjMwIHRkIDB4Y2QwMGNkMjAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkxMDcgdGlkIDEwMTU4MyB0ZCAweGNjNGIzOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA3IHRpZCAxMDA4 OTQgdGQgMHhjYmYwOGQyMApzY2hlZF9zd2l0Y2goY2JmMDhkMjAsMCwxMDQsMTkxLDQ4ODhiMGU5 LC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Ci0tTW9yZS0tICAgICAgICBtaV9zd2l0Y2goMTA0 LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChj YmYwOGQyMCwwLGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVl cHFfY2F0Y2hfc2lnbmFscyhjMGM5ZjM2ZiwxNjAsMCwxMDAsMTAwLC4uLikgYXQgc2xlZXBxX2Nh dGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoY2JjYTI4ODAsMCxjMGM5YzkxNywxMDAs MCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysweDE3Cl9zbGVlcChjYmNhMjg4MCxjMGRmYWYwMCwx MDAsYzBjOWM5MTcsMCwuLi4pIGF0IF9zbGVlcCsweDM1NApkb193YWl0KDAsMCwwLGU5ZDNhYzgw LGMwOGNkNWQwKSBhdCBkb193YWl0KzB4NTExCl9fdW10eF9vcF93YWl0KGNiZjA4ZDIwLGU5ZDNh Y2Y4LGU5ZDNhZDJjLGMwYmM4ZDUzLGNiZjA4ZDIwLC4uLikgYXQgX191bXR4X29wX3dhaXQrMHg1 ZgpfdW10eF9vcChjYmYwOGQyMCxlOWQzYWNmOCwxNCxlOWQzYWNhMCxjMGQ4OWY0OCwuLi4pIGF0 IF91bXR4X29wKzB4MjcKc3lzY2FsbChlOWQzYWQzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4 MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIwCi0tLSBzeXNjYWxsICg0NTQsIEZy ZWVCU0QgRUxGMzIsIF91bXR4X29wKSwgZWlwID0gMHgyODBiMTMxNywgZXNwID0gMHhiZmJmZTRh YywgZWJwID0gMHhiZmJmZTRjOCAtLS0KClRyYWNpbmcgY29tbWFuZCBjcmVhdCBwaWQgNzkxMDYg dGlkIDEwMDU4NSB0ZCAweGNiZGRiNDYwCnNjaGVkX3N3aXRjaChjYmRkYjQ2MCwwLDIwNywxOGMs NDhkNTU2M2YsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDIwNywwLGMwYzlm YmI5LGQ2LDE4YywuLi4pIGF0IG1pX3N3aXRjaCsweDIwMAphc3QoZTk2ZmNkMzgpIGF0IGFzdCsw eDJiMwpkb3JldGlfYXN0KCkgYXQgZG9yZXRpX2FzdCsweDE3CgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkxMDQgdGlkIDEwMTcxMyB0ZCAweGNjZTk3NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQotLU1vcmUtLSAgICAgICAgClRyYWNpbmcgY29tbWFuZCB0aHIxIHBp ZCA3OTEwNCB0aWQgMTAxNzA4IHRkIDB4Y2NlZjM0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTcwNSB0 ZCAweGNjZjYzNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE3MDEgdGQgMHhjY2U3NWQyMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTEwNCB0aWQgMTAxNjk2IHRkIDB4Y2NlZmYyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTY5MyB0ZCAw eGNjZTlkYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE2ODkgdGQgMHhjY2Q4YWFmMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEw NCB0aWQgMTAxNjg0IHRkIDB4Y2JkZGJhZjAKLS1Nb3JlLS0gICAgICAgIGZvcmtfdHJhbXBvbGlu ZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRp ZCAxMDE2ODAgdGQgMHhjY2VkNzAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxNjc2IHRkIDB4Y2NkMTky MzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkxMDQgdGlkIDEwMTY3MiB0ZCAweGNjZjAyOGMwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAx MDE2NjggdGQgMHhjZDAwZjIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxNjY1IHRkIDB4Y2NmMDYwMDAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkxMDQgdGlkIDEwMTY2MSB0ZCAweGNjZTg1YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKLS1Nb3JlLS0gICAgICAgIFRyYWNpbmcgY29tbWFuZCB0aHIxIHBp ZCA3OTEwNCB0aWQgMTAxNjU2IHRkIDB4Y2NkMWQyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTY1MyB0 ZCAweGNjZmY4YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE2NDkgdGQgMHhjOWEyODQ2MApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTEwNCB0aWQgMTAxNjQ1IHRkIDB4Y2NmNjJhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTY0MSB0ZCAw eGNjZjQ3NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE2MzcgdGQgMHhjYmVlNTAwMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEw NCB0aWQgMTAxNjMzIHRkIDB4YzhjNjUyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCi0tTW9yZS0tICAgICAgICAKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRp ZCAxMDE2MjkgdGQgMHhjY2Y2Y2QyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxNjI1IHRkIDB4Y2NmMzVh ZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkxMDQgdGlkIDEwMTYyMCB0ZCAweGNhNjI5ZDIwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAx MDE2MTcgdGQgMHhjY2Q0ZjQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxNjEzIHRkIDB4Y2NmOTc2OTAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkxMDQgdGlkIDEwMTYwOSB0ZCAweGNjZTg1MjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE2 MDQgdGQgMHhjY2QxYzAwMAotLU1vcmUtLSAgICAgICAgZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTYwMCB0 ZCAweGNjZTIwNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE1OTYgdGQgMHhjYmZhOGQyMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTEwNCB0aWQgMTAxNTkwIHRkIDB4Y2QwMTkwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTU4NSB0ZCAw eGNjZjk4ZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE1NzggdGQgMHhjYmY3YWQyMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEw NCB0aWQgMTAxNTc0IHRkIDB4Y2M0NzY4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgotLU1vcmUtLSAgICAgICAgVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRp ZCAxMDE1NjkgdGQgMHhjOTI0MmFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxNTY0IHRkIDB4YzkxMWFh ZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkxMDQgdGlkIDEwMTU1OCB0ZCAweGNjZjYyZDIwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAx MDE1NTMgdGQgMHhjY2Q0ZjY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxNTQ3IHRkIDB4YzlkZDlkMjAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkxMDQgdGlkIDEwMTU0MiB0ZCAweGNjZGRjZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE1 MzcgdGQgMHhjY2NmYmFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKLS1N b3JlLS0gICAgICAgIApUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTUzMiB0 ZCAweGNjZDRmYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE1MjcgdGQgMHhjY2YyODhjMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTEwNCB0aWQgMTAxNTIxIHRkIDB4Y2NkOGVkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTUxNSB0ZCAw eGNjZjkxOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE1MDkgdGQgMHhjOTQ0YzQ2MApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEw NCB0aWQgMTAxNTA0IHRkIDB4Y2MwNzQ0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTQ5OSB0ZCAweGM5 M2NkYWYwCi0tTW9yZS0tICAgICAgICBmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxNDkzIHRkIDB4Y2NmNzBk MjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkxMDQgdGlkIDEwMTQ4NyB0ZCAweGM5NDIxNDYwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAx MDE0ODEgdGQgMHhjY2Y2MTIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxNDc1IHRkIDB4Y2NkMWMyMzAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkxMDQgdGlkIDEwMTQ2OSB0ZCAweGM5NjQ4ZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE0 NjMgdGQgMHhjYzQ3NmFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKCi0t TW9yZS0tICAgICAgICBUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTQ1OSB0 ZCAweGNiNjhlOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE0NTIgdGQgMHhjOTIzOThjMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTEwNCB0aWQgMTAxNDQ1IHRkIDB4Y2NlNzU0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTQzOCB0ZCAw eGM5NmM5NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDE0MzEgdGQgMHhjY2U4MTIzMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEw NCB0aWQgMTAxNDI1IHRkIDB4Y2NkN2UwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTQxOCB0ZCAweGNj NGIzNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQotLU1vcmUtLSAgICAg ICAgClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxNDExIHRkIDB4Yzk3YmUw MDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkxMDQgdGlkIDEwMTQwNCB0ZCAweGNjZTA1YWYwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAx MDEzOTcgdGQgMHhjY2RlNTQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxMzkwIHRkIDB4Y2NmMWMyMzAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkxMDQgdGlkIDEwMTM4MyB0ZCAweGNjZjAyYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEz NzYgdGQgMHhjYzA2ZDY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxMzY2IHRkIDB4Yzk0OTE4YzAKLS1N b3JlLS0gICAgICAgIGZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEzNjAgdGQgMHhjYzQ3NmQyMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTEwNCB0aWQgMTAxMzU1IHRkIDB4Y2NlNGI0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTM0OCB0ZCAw eGNjZDg1NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDExOTEgdGQgMHhjYmY3YjY5MApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEw NCB0aWQgMTAxMjIxIHRkIDB4Yzk1YzVkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTI0NSB0ZCAweGNj ZDFkNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKLS1Nb3JlLS0gICAg ICAgIFRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxMjc1IHRkIDB4Y2NmOTMy MzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkxMDQgdGlkIDEwMTI2MCB0ZCAweGM5NmE4YWYwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAx MDExOTUgdGQgMHhjY2Q2NTQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxMTkzIHRkIDB4Y2NkNGYwMDAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkxMDQgdGlkIDEwMTIwMiB0ZCAweGNjZGJlMjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEx OTQgdGQgMHhjYmJkOTQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxMjIwIHRkIDB4Y2NkMmFhZjAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCi0tTW9yZS0tICAgICAgICAKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEzMzYgdGQgMHhjY2U4NThjMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTEwNCB0aWQgMTAxMzMwIHRkIDB4Y2NlOTIwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTMyNiB0ZCAw eGM5NDgyNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEzMjAgdGQgMHhjOTYwODY5MApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEw NCB0aWQgMTAxMzE0IHRkIDB4Y2NmZmVhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTMwNiB0ZCAweGNj ZjBmYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEyOTYgdGQgMHhjY2QzYjAwMAotLU1vcmUtLSAgICAg ICAgZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkxMDQgdGlkIDEwMTI5MSB0ZCAweGNjZmE4ZDIwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAx MDEyODYgdGQgMHhjY2Y5YmFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxMjgyIHRkIDB4Yzk3OTk0NjAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkxMDQgdGlkIDEwMTI3NyB0ZCAweGNjZWI5ZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEy NzEgdGQgMHhjZDAxODQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAxMjY1IHRkIDB4YzlkYTcwMDAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgotLU1vcmUtLSAgICAgICAgVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEyNTMgdGQgMHhjY2Y1NjhjMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTEwNCB0aWQgMTAxMjQxIHRkIDB4Y2NmYTg4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTIzNSB0ZCAw eGNjZjMwMjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEyMjggdGQgMHhjY2YwYzIzMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEw NCB0aWQgMTAxMjExIHRkIDB4Y2NkNTVhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDQgdGlkIDEwMTIwNSB0ZCAweGNj NDU0OGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MTA0IHRpZCAxMDEyMjYgdGQgMHhjY2Y3MThjMApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKLS1Nb3JlLS0gICAgICAgIApUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkxMDQgdGlkIDEwMTI1MiB0ZCAweGNjZTgwYWYwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTA0IHRpZCAx MDEyNjYgdGQgMHhjYzQwZDQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwNCB0aWQgMTAwMzA1IHRkIDB4YzlkYWU2OTAK Y3B1c3RvcF9oYW5kbGVyKDEwLGU5MmNjOWU4LGMwYmM4ZmQ2LGU5MmNjOTc4LGMwZGY4N2YwLC4u LikgYXQgY3B1c3RvcF9oYW5kbGVyKzB4MzIKaXBpX25taV9oYW5kbGVyKGU5MmNjOTc4LGMwZGY4 N2YwLGMwZGY4N2YwLGM5ZGFlNjkwLGM5YzE1ZDQ4LC4uLikgYXQgaXBpX25taV9oYW5kbGVyKzB4 MmYKdHJhcChlOTJjYzlmNCkgYXQgdHJhcCsweDM2CmNhbGx0cmFwKCkgYXQgY2FsbHRyYXArMHg2 Ci0tLSB0cmFwIDB4MTMsIGVpcCA9IDB4YzBiY2NmOTcsIGVzcCA9IDB4ZTkyY2NhMzQsIGVicCA9 IDB4ZTkyY2NhNTAgLS0tCkRFTEFZKDEsYzlkYWU2OTAsYzBlMDFjMzQsMCxlOTJjY2E5MCwuLi4p IGF0IERFTEFZKzB4ODcKX210eF9sb2NrX3NwaW4oYzBlMDFjMzQsYzlkYWU2OTAsMCxjMGNkNDBk ZCw0NjIsLi4uKSBhdCBfbXR4X2xvY2tfc3BpbisweDZjCl9tdHhfbG9ja19zcGluX2ZsYWdzKGMw ZTAxYzM0LDAsYzBjZDQwZGQsNDYyLGY1LC4uLikgYXQgX210eF9sb2NrX3NwaW5fZmxhZ3MrMHgx NDYKc21wX3RsYl9zaG9vdGRvd24oZTkyY2NhZTAsYzBiYmZkN2YsZWE3OTkwMDAsZWE3OWEwMDAs YzE0YjYwMDAsLi4uKSBhdCBzbXBfdGxiX3Nob290ZG93bisweDY2CnNtcF9pbnZscGdfcmFuZ2Uo ZWE3OTkwMDAsZWE3OWEwMDAsYzE0YjYwMDAsMCwxLC4uLikgYXQgc21wX2ludmxwZ19yYW5nZSsw eDFjCnBtYXBfaW52YWxpZGF0ZV9yYW5nZShjMGZiYjVlMCxlYTc5OTAwMCxlYTc5YTAwMCkgYXQg cG1hcF9pbnZhbGlkYXRlX3JhbmdlKzB4NGYKcG1hcF9xcmVtb3ZlKGVhNzk5MDAwLDEsMCwxNzEs Y2JmMmY1ZDgsLi4uKSBhdCBwbWFwX3FyZW1vdmUrMHg1OAotLU1vcmUtLSAgICAgICAgdm1fdGhy ZWFkX25ldyhjY2QzNTQ2MCwyLDIsZTkyY2NjNDQsZTkyY2NiZmMsLi4uKSBhdCB2bV90aHJlYWRf bmV3KzB4MTVlCnRocmVhZF9hbGxvYygwLGM5YzE1ZGQwLDQsYzBjOTk3ZTUsMjgwYTY2NzAsLi4u KSBhdCB0aHJlYWRfYWxsb2MrMHg0ZgpjcmVhdGVfdGhyZWFkKDI4MjMxNDQwLGIxZjI2MDAwLDEw MDAwMCwyODFkMDg5MCwyODIzMTQ0MCwyODIzMTQ0MCwyLDAsMCkgYXQgY3JlYXRlX3RocmVhZCsw eDljCmtlcm5fdGhyX25ldyhjOWRhZTY5MCxlOTJjY2M0NCwzNCwyODBhNjY3MCwyODIzMTQ0MCwu Li4pIGF0IGtlcm5fdGhyX25ldysweDc3CnRocl9uZXcoYzlkYWU2OTAsZTkyY2NjZjgsOCxjMGNh MWEzYSxjMGQ4OWY2NCwuLi4pIGF0IHRocl9uZXcrMHg1NQpzeXNjYWxsKGU5MmNjZDM4KSBhdCBz eXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjAK LS0tIHN5c2NhbGwgKDQ1NSwgRnJlZUJTRCBFTEYzMiwgdGhyX25ldyksIGVpcCA9IDB4MjgwZmQx Y2IsIGVzcCA9IDB4YmZiZmU0N2MsIGVicCA9IDB4YmZiZmU1MzggLS0tCgpUcmFjaW5nIGNvbW1h bmQgY3JlYXQgcGlkIDc5MTAzIHRpZCAxMDAyODEgdGQgMHhjOWQzYmFmMApzY2hlZF9zd2l0Y2go YzlkM2JhZjAsMCwxMDQsMTkxLGQzYjNmOTE2LC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1p X3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVl cHFfc3dpdGNoKGM5ZDNiYWYwLDAsYzBjOWYzNmYsMWEwLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNo KzB4MTVmCnNsZWVwcV9jYXRjaF9zaWduYWxzKGMwODdmY2VhLGM4YWM3MjA0LDAsYzBjOTk3ZTUs YzlkM2JhZjAsLi4uKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweGI3CnNsZWVwcV93YWl0X3Np ZyhjOGFjNzI4MCwwLGU5Mjg0YjYwLDEwMSwwLC4uLikgYXQgc2xlZXBxX3dhaXRfc2lnKzB4MTcK X2N2X3dhaXRfc2lnKGM4YWM3MjgwLGM4YWM3MjA0LGMwY2EzMzNmLDUxMSxjOGFjNzIwMCwuLi4p IGF0IF9jdl93YWl0X3NpZysweDI0MAp0dHlfd2FpdChjOGFjNzIwMCxjOGFjNzI4MCxjMGNhMzMz Ziw5Ziw3LC4uLikgYXQgdHR5X3dhaXQrMHg3MQp0dHlkZXZfd3JpdGUoYzhjYzY5MDAsZTkyODRj NTgsMCwwLDAsLi4uKSBhdCB0dHlkZXZfd3JpdGUrMHhjYwpkZXZmc193cml0ZV9mKGM5NGE3ZDIw LGU5Mjg0YzU4LGM5YmFkYTgwLDAsYzlkM2JhZjAsLi4uKSBhdCBkZXZmc193cml0ZV9mKzB4OWUK ZG9maWxld3JpdGUoZTkyODRjNTgsZmZmZmZmZmYsZmZmZmZmZmYsMCxjOTRhN2QyMCwuLi4pIGF0 IGRvZmlsZXdyaXRlKzB4OTUKLS1Nb3JlLS0gICAgICAgIGtlcm5fd3JpdGV2KGM5ZDNiYWYwLDIs ZTkyODRjNTgsZTkyODRjNzgsMSwuLi4pIGF0IGtlcm5fd3JpdGV2KzB4NTgKd3JpdGUoYzlkM2Jh ZjAsZTkyODRjZjgsYyxjMGNhMWUxZSxjMGQ4NmUxMCwuLi4pIGF0IHdyaXRlKzB4NGYKc3lzY2Fs bChlOTI4NGQzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4 ODBfc3lzY2FsbCsweDIwCi0tLSBzeXNjYWxsICg0LCBGcmVlQlNEIEVMRjMyLCB3cml0ZSksIGVp cCA9IDB4MjgxOGRjOTMsIGVzcCA9IDB4YmZiZmRlMWMsIGVicCA9IDB4YmZiZmRlMzggLS0tCgpU cmFjaW5nIGNvbW1hbmQgY3JlYXQgcGlkIDc5MTAxIHRpZCAxMDA2MjAgdGQgMHhjYmY2NTAwMApz Y2hlZF9zd2l0Y2goY2JmNjUwMDAsMCwxMDQsMTkxLGQzYjc4ZDY2LC4uLikgYXQgc2NoZWRfc3dp dGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRj aCsweDIwMApzbGVlcHFfc3dpdGNoKGNiZjY1MDAwLDAsYzBjOWYzNmYsMWEwLDAsLi4uKSBhdCBz bGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV9jYXRjaF9zaWduYWxzKGMwODdmY2VhLGM4YWM3MjA0 LDAsYzBjOTk3ZTUsY2JmNjUwMDAsLi4uKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweGI3CnNs ZWVwcV93YWl0X3NpZyhjOGFjNzI4MCwwLGU5NzdlYjYwLDEwMSwwLC4uLikgYXQgc2xlZXBxX3dh aXRfc2lnKzB4MTcKX2N2X3dhaXRfc2lnKGM4YWM3MjgwLGM4YWM3MjA0LGMwY2EzMzNmLDUxMSxj OGFjNzIwMCwuLi4pIGF0IF9jdl93YWl0X3NpZysweDI0MAp0dHlfd2FpdChjOGFjNzIwMCxjOGFj NzI4MCxjMGNhMzMzZiw5ZiwxOCwuLi4pIGF0IHR0eV93YWl0KzB4NzEKdHR5ZGV2X3dyaXRlKGM4 Y2M2OTAwLGU5NzdlYzU4LDAsMCwwLC4uLikgYXQgdHR5ZGV2X3dyaXRlKzB4Y2MKZGV2ZnNfd3Jp dGVfZihjOTRhN2QyMCxlOTc3ZWM1OCxjOWJhZGE4MCwwLGNiZjY1MDAwLC4uLikgYXQgZGV2ZnNf d3JpdGVfZisweDllCmRvZmlsZXdyaXRlKGU5NzdlYzU4LGZmZmZmZmZmLGZmZmZmZmZmLDAsYzk0 YTdkMjAsLi4uKSBhdCBkb2ZpbGV3cml0ZSsweDk1Cmtlcm5fd3JpdGV2KGNiZjY1MDAwLDIsZTk3 N2VjNTgsZTk3N2VjNzgsMSwuLi4pIGF0IGtlcm5fd3JpdGV2KzB4NTgKd3JpdGUoY2JmNjUwMDAs ZTk3N2VjZjgsYyxjMGNhMTlmMixjMGQ4NmUxMCwuLi4pIGF0IHdyaXRlKzB4NGYKc3lzY2FsbChl OTc3ZWQzOCkgYXQgc3lzY2FsbCsweDJhMwotLU1vcmUtLSAgICAgICAgWGludDB4ODBfc3lzY2Fs bCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lzY2FsbCAoNCwgRnJlZUJTRCBFTEYz Miwgd3JpdGUpLCBlaXAgPSAweDI4MThkYzkzLCBlc3AgPSAweGJmYmZkZTFjLCBlYnAgPSAweGJm YmZkZTM4IC0tLQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE3MTIgdGQg MHhjY2Y2MDAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcg Y29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNzA5IHRkIDB4Y2NkNzFkMjAKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkx MDAgdGlkIDEwMTcwNCB0ZCAweGM5Nzk5YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE3MDAgdGQgMHhj Y2U2YjAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNjk3IHRkIDB4Y2NkMzFhZjAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAg dGlkIDEwMTY5MiB0ZCAweGM5MjQyMDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQotLU1vcmUtLSAgICAgICAgClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQg MTAxNjg4IHRkIDB4Yzk0MjEwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5l CgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTY4NSB0ZCAweGNjZDc1YWYw CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRo cjEgcGlkIDc5MTAwIHRpZCAxMDE2ODEgdGQgMHhjY2Q4Y2FmMApmb3JrX3RyYW1wb2xpbmUoKSBh dCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAx Njc3IHRkIDB4Y2NlYWM4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpU cmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTY3MyB0ZCAweGNjZGMzNjkwCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MTAwIHRpZCAxMDE2NjkgdGQgMHhjY2ZlYWQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNjY0 IHRkIDB4Y2NkNmY0NjAKLS1Nb3JlLS0gICAgICAgIGZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtf dHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE2NjAgdGQg MHhjY2Y2N2FmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcg Y29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNjU3IHRkIDB4Y2M0MGIwMDAKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkx MDAgdGlkIDEwMTY1MiB0ZCAweGNjZGU1YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE2NDggdGQgMHhj Y2YwYzQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNjQ0IHRkIDB4Y2M0YjMyMzAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAg dGlkIDEwMTY0MCB0ZCAweGNjZjU0OGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKLS1Nb3JlLS0gICAgICAgIFRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQg MTAxNjM2IHRkIDB4Y2NkOWIyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5l CgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTYzMiB0ZCAweGNjZGUzZDIw CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRo cjEgcGlkIDc5MTAwIHRpZCAxMDE2MjggdGQgMHhjY2Q2MGQyMApmb3JrX3RyYW1wb2xpbmUoKSBh dCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAx NjI0IHRkIDB4YzlhZWFkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpU cmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTYyMSB0ZCAweGNjZDk2ZDIwCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MTAwIHRpZCAxMDE2MTYgdGQgMHhjY2RhNjY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNjEy IHRkIDB4Y2NkMWU4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCi0tTW9y ZS0tICAgICAgICAKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE2MDggdGQg MHhjY2ZmZTAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcg Y29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNjA1IHRkIDB4Y2NkOWM0NjAKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkx MDAgdGlkIDEwMTYwMSB0ZCAweGNjZDdkYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE1OTcgdGQgMHhj YzRkZWQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNTkzIHRkIDB4Y2JlYmVhZjAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAg dGlkIDEwMTU4OSB0ZCAweGNjZTQ0OGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE1ODQgdGQgMHhjY2Q4 YjAwMAotLU1vcmUtLSAgICAgICAgZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5l CgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTU3OSB0ZCAweGNjZmU5OGMw CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRo cjEgcGlkIDc5MTAwIHRpZCAxMDE1NzMgdGQgMHhjY2Y5YjY5MApmb3JrX3RyYW1wb2xpbmUoKSBh dCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAx NTY4IHRkIDB4Y2NlZDdkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpU cmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTU2MyB0ZCAweGNjZTU0NDYwCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MTAwIHRpZCAxMDE1NTkgdGQgMHhjY2Q4YzhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNTU1 IHRkIDB4Yzk2YWRkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgotLU1v cmUtLSAgICAgICAgVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE1NTAgdGQg MHhjOTVhNjhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcg Y29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNTQ1IHRkIDB4Y2NkOWYyMzAKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkx MDAgdGlkIDEwMTU0MCB0ZCAweGNjZmZmNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE1MzYgdGQgMHhj Y2RhNjAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNTMxIHRkIDB4Y2NmZjg4YzAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAg dGlkIDEwMTUyNiB0ZCAweGNhNWZhNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE1MjIgdGQgMHhjY2Y2 MGFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKLS1Nb3JlLS0gICAgICAg IApUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTUxNiB0ZCAweGNjNmE3NDYw CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRo cjEgcGlkIDc5MTAwIHRpZCAxMDE1MTAgdGQgMHhjY2Y2ZjQ2MApmb3JrX3RyYW1wb2xpbmUoKSBh dCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAx NTA2IHRkIDB4Y2NmMzE0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpU cmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTUwMSB0ZCAweGNjZjE5NjkwCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MTAwIHRpZCAxMDE0OTUgdGQgMHhjYjE2MTY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNDg5 IHRkIDB4Y2NkODRhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTQ4MyB0ZCAweGNjZTJhZDIwCi0tTW9y ZS0tICAgICAgICBmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcg Y29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNDc3IHRkIDB4Y2NmNGIwMDAKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkx MDAgdGlkIDEwMTQ3MSB0ZCAweGNkMDEzYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE0NjUgdGQgMHhj Y2Y0YzAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxNDU3IHRkIDB4Y2NkN2Y4YzAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAg dGlkIDEwMTQ1MCB0ZCAweGNjZjJlMDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDE0NDMgdGQgMHhjY2Zm ODQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKCi0tTW9yZS0tICAgICAg ICBUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTQzNiB0ZCAweGNjZjI3YWYw CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRo cjEgcGlkIDc5MTAwIHRpZCAxMDE0MjcgdGQgMHhjY2Q2ZjhjMApmb3JrX3RyYW1wb2xpbmUoKSBh dCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAx NDIwIHRkIDB4Y2NkNDk4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpU cmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTQxMyB0ZCAweGNjZGQyYWYwCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MTAwIHRpZCAxMDE0MDcgdGQgMHhjYzZhN2QyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxMzk5 IHRkIDB4Y2NkMzI0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTM5MiB0ZCAweGNjZTY2YWYwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQotLU1vcmUtLSAgICAgICAgClRyYWNpbmcg Y29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxMzg1IHRkIDB4Y2JjOTgwMDAKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkx MDAgdGlkIDEwMTM3OSB0ZCAweGNjZjdmNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDEzNzIgdGQgMHhj OWNkYmQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxMzY1IHRkIDB4Y2IxY2QyMzAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAg dGlkIDEwMTM1OSB0ZCAweGNkMDBkMDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDEzNTQgdGQgMHhjY2Jk YzY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxMzQ5IHRkIDB4Y2JhZWNhZjAKLS1Nb3JlLS0gICAgICAg IGZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRo cjEgcGlkIDc5MTAwIHRpZCAxMDEzNDQgdGQgMHhjY2RhNjhjMApmb3JrX3RyYW1wb2xpbmUoKSBh dCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAx MjM4IHRkIDB4Y2NlOTdkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpU cmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTMwMyB0ZCAweGM4YzU5NDYwCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MTAwIHRpZCAxMDEyNDkgdGQgMHhjY2VhMDQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxMjI1 IHRkIDB4Y2E4MjdhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAgdGlkIDEwMTIxNiB0ZCAweGM5MjM5ZDIwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKLS1Nb3JlLS0gICAgICAgIFRyYWNpbmcg Y29tbWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxMjAxIHRkIDB4Y2NmMDc0NjAKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkx MDAgdGlkIDEwMTE5MCB0ZCAweGNiZDRhMDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MTAwIHRpZCAxMDEzMzkgdGQgMHhj Y2Q0MzhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTEwMCB0aWQgMTAxMzM3IHRkIDB4Y2NkMTFkMjAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkxMDAg dGlkIDEwMDcyNiB0ZCAweGM5NDJjMDAwCmNwdXN0b3BfaGFuZGxlcigyMCxlOWEzMTllOCxjMGJj OGZkNixlOWEzMTk3OCxjMGRmODgyYywuLi4pIGF0IGNwdXN0b3BfaGFuZGxlcisweDMyCmlwaV9u bWlfaGFuZGxlcihlOWEzMTk3OCxjMGRmODgyYyxjMGRmODgyYyxjOTQyYzAwMCxjYzZlMDdmOCwu Li4pIGF0IGlwaV9ubWlfaGFuZGxlcisweDJmCnRyYXAoZTlhMzE5ZjQpIGF0IHRyYXArMHgzNgpj YWxsdHJhcCgpIGF0IGNhbGx0cmFwKzB4NgotLS0gdHJhcCAweDEzLCBlaXAgPSAweGMwYmNjZjk5 LCBlc3AgPSAweGU5YTMxYTM0LCBlYnAgPSAweGU5YTMxYTUwIC0tLQpERUxBWSgxLGM5NDJjMDAw LGMwZTAxYzM0LDAsZTlhMzFhOTAsLi4uKSBhdCBERUxBWSsweDg5Cl9tdHhfbG9ja19zcGluKGMw ZTAxYzM0LGM5NDJjMDAwLDAsYzBjZDQwZGQsNDYyLC4uLikgYXQgX210eF9sb2NrX3NwaW4rMHg2 YwotLU1vcmUtLSAgICAgICAgX210eF9sb2NrX3NwaW5fZmxhZ3MoYzBlMDFjMzQsMCxjMGNkNDBk ZCw0NjIsZjUsLi4uKSBhdCBfbXR4X2xvY2tfc3Bpbl9mbGFncysweDE0NgpzbXBfdGxiX3Nob290 ZG93bihlOWEzMWFlMCxjMGJiZmQ3ZixlYTc5YzAwMCxlYTc5ZDAwMCxjMTRiNjAwMCwuLi4pIGF0 IHNtcF90bGJfc2hvb3Rkb3duKzB4NjYKc21wX2ludmxwZ19yYW5nZShlYTc5YzAwMCxlYTc5ZDAw MCxjMTRiNjAwMCwwLDEsLi4uKSBhdCBzbXBfaW52bHBnX3JhbmdlKzB4MWMKcG1hcF9pbnZhbGlk YXRlX3JhbmdlKGMwZmJiNWUwLGVhNzljMDAwLGVhNzlkMDAwKSBhdCBwbWFwX2ludmFsaWRhdGVf cmFuZ2UrMHg0ZgpwbWFwX3FyZW1vdmUoZWE3OWMwMDAsMSwwLDE3MSxjYzdkOWQ0OCwuLi4pIGF0 IHBtYXBfcXJlbW92ZSsweDU4CnZtX3RocmVhZF9uZXcoY2NmNTk2OTAsMiwyLGU5YTMxYzQ0LGU5 YTMxYmZjLC4uLikgYXQgdm1fdGhyZWFkX25ldysweDE1ZQp0aHJlYWRfYWxsb2MoMCxjYzZlMDg4 MCw0LGMwYzk5N2U1LDI4MGE2NjcwLC4uLikgYXQgdGhyZWFkX2FsbG9jKzB4NGYKY3JlYXRlX3Ro cmVhZCgyODIwNDcwMCxiYTVhYzAwMCwxMDAwMDAsMjgxZGFlOTAsMjgyMDQ3MDAsMjgyMDQ3MDAs MiwwLDApIGF0IGNyZWF0ZV90aHJlYWQrMHg5YwprZXJuX3Rocl9uZXcoYzk0MmMwMDAsZTlhMzFj NDQsMzQsMjgwYTY2NzAsMjgyMDQ3MDAsLi4uKSBhdCBrZXJuX3Rocl9uZXcrMHg3Nwp0aHJfbmV3 KGM5NDJjMDAwLGU5YTMxY2Y4LDgsYzBjYTFhM2EsYzBkODlmNjQsLi4uKSBhdCB0aHJfbmV3KzB4 NTUKc3lzY2FsbChlOWEzMWQzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkg YXQgWGludDB4ODBfc3lzY2FsbCsweDIwCi0tLSBzeXNjYWxsICg0NTUsIEZyZWVCU0QgRUxGMzIs IHRocl9uZXcpLCBlaXAgPSAweDI4MGZkMWNiLCBlc3AgPSAweGJmYmZlNDdjLCBlYnAgPSAweGJm YmZlNTM4IC0tLQoKVHJhY2luZyBjb21tYW5kIGNyZWF0IHBpZCA3OTA5OCB0aWQgMTAwNjI0IHRk IDB4YzhjNTlhZjAKa2RiX2VudGVyKGMwYzliMGQxLGMwYzliMGQxLGMwYzlmNTQ2LGU5NzhhODVj LDEsLi4uKSBhdCBrZGJfZW50ZXIrMHgzYQpwYW5pYyhjMGM5ZjU0NixjOTYzM2FmMCxjMGRmYzAy NCxjOWQzZTI4MCxjMGY1YmQzYywuLi4pIGF0IHBhbmljKzB4MTM2CnR1cm5zdGlsZV9jbGFpbShj OWQzZTI4MCwyLGMwY2E3Mzc2LDFmMCw0LC4uLikgYXQgdHVybnN0aWxlX2NsYWltKzB4MTQ4Cl9y d190cnlfdXBncmFkZShjMGY1YmQzYyxjMGNhNzM3NiwxZjAsZTk3OGE5OTAsZTk3OGFiODgsLi4u KSBhdCBfcndfdHJ5X3VwZ3JhZGUrMHhlNgpjYWNoZV9sb29rdXAoYzk5ZTliYjAsZTk3OGFiNzQs ZTk3OGFiODgsMCwwLC4uLikgYXQgY2FjaGVfbG9va3VwKzB4MzYyCi0tTW9yZS0tICAgICAgICBu ZnNfbG9va3VwKGU5NzhhYTUwLGU5NzhhYTUwLGU5NzhhYjVjLDIwMDAwMCxlOTc4YWI1YywuLi4p IGF0IG5mc19sb29rdXArMHhmNgpWT1BfTE9PS1VQX0FQVihjMGRhNWZlMCxlOTc4YWE1MCxlOTc4 YWI4OCwxZjEsZTk3OGFiNzQsLi4uKSBhdCBWT1BfTE9PS1VQX0FQVisweGE1Cmxvb2t1cChlOTc4 YWI1YyxjMGNhN2FlYSxlYSxjNSxjYzA5M2Q0OCwuLi4pIGF0IGxvb2t1cCsweDY2YgpuYW1laShl OTc4YWI1YyxjMDhkM2FhYixjMGM5NGM5NixjMGM5MmRmOSwzLC4uLikgYXQgbmFtZWkrMHg1NWYK a2Vybl9zdGF0YXRfdm5ob29rKGM4YzU5YWYwLDAsZmZmZmZmOWMsYmZiZmRmNzgsMCwuLi4pIGF0 IGtlcm5fc3RhdGF0X3ZuaG9vaysweDcyCmtlcm5fc3RhdGF0KGM4YzU5YWYwLDAsZmZmZmZmOWMs YmZiZmRmNzgsMCwuLi4pIGF0IGtlcm5fc3RhdGF0KzB4M2MKa2Vybl9zdGF0KGM4YzU5YWYwLGJm YmZkZjc4LDAsZTk3OGFjMTgsMiwuLi4pIGF0IGtlcm5fc3RhdCsweDM2CnN0YXQoYzhjNTlhZjAs ZTk3OGFjZjgsOCxjMGNhMTlmMixjMGQ4ODIzMCwuLi4pIGF0IHN0YXQrMHgyZgpzeXNjYWxsKGU5 NzhhZDM4KSBhdCBzeXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9z eXNjYWxsKzB4MjAKLS0tIHN5c2NhbGwgKDE4OCwgRnJlZUJTRCBFTEYzMiwgc3RhdCksIGVpcCA9 IDB4MjgxN2QxYTMsIGVzcCA9IDB4YmZiZmRlY2MsIGVicCA9IDB4YmZiZmUzODggLS0tCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTcxMCB0ZCAweGNjZmRlNjkwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDk2IHRpZCAxMDE3MDYgdGQgMHhjYzZiMzIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNzAyIHRk IDB4Y2NlNTRhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCi0tTW9yZS0t ICAgICAgICAKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE2OTggdGQgMHhj Y2YwNjIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNjk1IHRkIDB4Y2NkOTEyMzAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYg dGlkIDEwMTY5MSB0ZCAweGNjZjFhNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE2ODYgdGQgMHhjOTY4 MThjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNjgyIHRkIDB4Y2NlNzVhZjAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlk IDEwMTY3OCB0ZCAweGNiZTlmNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE2NzQgdGQgMHhjY2RlNTAw MAotLU1vcmUtLSAgICAgICAgZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpU cmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTY3MCB0ZCAweGNjZTk4ZDIwCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MDk2IHRpZCAxMDE2NjYgdGQgMHhjY2RhODY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNjYy IHRkIDB4Y2NkNGNhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTY1OSB0ZCAweGNjZDcyMjMwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDk2IHRpZCAxMDE2NTQgdGQgMHhjZDAwMWFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNjUwIHRk IDB4Y2NlMmIwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgotLU1vcmUt LSAgICAgICAgVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE2NDYgdGQgMHhj YmZjNTAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNjQyIHRkIDB4Y2NmZjk4YzAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYg dGlkIDEwMTYzOCB0ZCAweGNjZjM1ZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE2MzQgdGQgMHhjYzI4 MmFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNjMwIHRkIDB4Y2NmZmU0NjAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlk IDEwMTYyNiB0ZCAweGNjMDNmNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE2MjIgdGQgMHhjY2Y3NzIz MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKLS1Nb3JlLS0gICAgICAgIApU cmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTYxOCB0ZCAweGNjZjQ3MDAwCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MDk2IHRpZCAxMDE2MTQgdGQgMHhjYmRkYWFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNjEw IHRkIDB4Y2NmZGEwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTYwNiB0ZCAweGNjZmIwMDAwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDk2IHRpZCAxMDE2MDIgdGQgMHhjY2QxYzY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNTk4IHRk IDB4Y2NkNzhkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTU5NCB0ZCAweGNjZjhjNDYwCi0tTW9yZS0t ICAgICAgICBmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNTkxIHRkIDB4Y2JkYzkwMDAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYg dGlkIDEwMTU4NiB0ZCAweGNjZDYwOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE1ODAgdGQgMHhjYzIy MDAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNTc1IHRkIDB4Y2NmNjcyMzAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlk IDEwMTU3MCB0ZCAweGNjZDI4YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE1NjYgdGQgMHhjY2VkNzQ2 MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKCi0tTW9yZS0tICAgICAgICBU cmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTU2MSB0ZCAweGNjZGFjMDAwCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MDk2IHRpZCAxMDE1NTYgdGQgMHhjY2U0MDIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNTUx IHRkIDB4Y2NkOTFkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTU0NiB0ZCAweGNjZTg1NjkwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDk2IHRpZCAxMDE1NDEgdGQgMHhjY2YxMThjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNTM1IHRk IDB4Y2NkMjA0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTUzMCB0ZCAweGNjZjU3MjMwCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQotLU1vcmUtLSAgICAgICAgClRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNTI1IHRkIDB4Y2NkOTUwMDAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYg dGlkIDEwMTUxOSB0ZCAweGNjZjZjMDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE1MTQgdGQgMHhjY2Yw N2FmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNTA3IHRkIDB4Y2NlMjdhZjAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlk IDEwMTUwMyB0ZCAweGM5NTdjMjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE0OTcgdGQgMHhjOWU0MGFm MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0 aHIxIHBpZCA3OTA5NiB0aWQgMTAxNDkxIHRkIDB4Y2NlNmY4YzAKLS1Nb3JlLS0gICAgICAgIGZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MDk2IHRpZCAxMDE0ODQgdGQgMHhjY2U2NjY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNDc4 IHRkIDB4Y2JmNTcwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTQ3MyB0ZCAweGNjZjZkOGMwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDk2IHRpZCAxMDE0NjggdGQgMHhjY2U5ZTIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNDYwIHRk IDB4Y2NmMDc4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTQ1MyB0ZCAweGNjZWY0YWYwCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKLS1Nb3JlLS0gICAgICAgIFRyYWNpbmcgY29t bWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNDQ2IHRkIDB4Y2NkNzIwMDAKZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYg dGlkIDEwMTQ0MCB0ZCAweGNjZGEwOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE0MzMgdGQgMHhjOTQ3 ZjIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxNDI2IHRkIDB4Y2NkMjA2OTAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlk IDEwMTQxOSB0ZCAweGNjZGQyNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDE0MTIgdGQgMHhjY2Y0N2Fm MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0 aHIxIHBpZCA3OTA5NiB0aWQgMTAxNDA2IHRkIDB4Y2NmMGNhZjAKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lCi0tTW9yZS0tICAgICAgICAKVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MDk2IHRpZCAxMDE0MDAgdGQgMHhjY2ZhYzhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxMzkz IHRkIDB4Y2NkNzZhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTM4NiB0ZCAweGNjZGFmYWYwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDk2IHRpZCAxMDEzNzggdGQgMHhjYzQwZDhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxMzcxIHRk IDB4Y2QwMGIyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTM2NCB0ZCAweGM5NWM1YWYwCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5 MDk2IHRpZCAxMDEzNTggdGQgMHhjY2QzNzAwMAotLU1vcmUtLSAgICAgICAgZm9ya190cmFtcG9s aW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYg dGlkIDEwMTM1MiB0ZCAweGNhZmE3OGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDEzNDYgdGQgMHhjY2Y1 NzQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxMjcwIHRkIDB4Y2NkODk2OTAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlk IDEwMTE5OSB0ZCAweGM5YTI4YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDExOTIgdGQgMHhjY2QyYTIz MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0 aHIxIHBpZCA3OTA5NiB0aWQgMTAxMjk5IHRkIDB4Y2NmZmYwMDAKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lCgotLU1vcmUtLSAgICAgICAgVHJhY2luZyBjb21tYW5kIHRocjEg cGlkIDc5MDk2IHRpZCAxMDEzMDIgdGQgMHhjY2VlMWQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxMzI3 IHRkIDB4YzljOWQyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTMyMiB0ZCAweGM5MjQyOGMwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDk2IHRpZCAxMDEzMTcgdGQgMHhjOGY0ODhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxMzExIHRk IDB4Y2NkMjIwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTMwMSB0ZCAweGNjNDQ4MjMwCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5 MDk2IHRpZCAxMDEyOTIgdGQgMHhjY2ZmODIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUKLS1Nb3JlLS0gICAgICAgIApUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYg dGlkIDEwMTI4NyB0ZCAweGM5YjZjNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBv bGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDEyODEgdGQgMHhjY2Y3 MWFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxMjc4IHRkIDB4Y2NlM2U0NjAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlk IDEwMTI3MyB0ZCAweGNjZjc5YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDk2IHRpZCAxMDEyNTggdGQgMHhjY2YwNjY5 MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0 aHIxIHBpZCA3OTA5NiB0aWQgMTAxMjUxIHRkIDB4Y2NmOWI4YzAKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEw MTI0MyB0ZCAweGM5MzA3YWYwCi0tTW9yZS0tICAgICAgICBmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxMjM3 IHRkIDB4Y2JlZmIyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTIyNCB0ZCAweGNkMDE2NDYwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDk2IHRpZCAxMDEyMTggdGQgMHhjY2ZkMWQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5NiB0aWQgMTAxMjMxIHRk IDB4Y2NkNTY2OTAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYgdGlkIDEwMTIyOSB0ZCAweGNjODFkNDYwCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5 MDk2IHRpZCAxMDEyNTcgdGQgMHhjY2YwMGFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUKCi0tTW9yZS0tICAgICAgICBUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTYg dGlkIDEwMDgxMiB0ZCAweGM5YWRiNDYwCmNwdXN0b3BfaGFuZGxlcig4MCxlOWJlYWE0YyxjMGJj OGZkNiw0LGMwY2M1YWQ4LC4uLikgYXQgY3B1c3RvcF9oYW5kbGVyKzB4MzIKaXBpX25taV9oYW5k bGVyKDQsYzBjYzVhZDgsYzg1MTcwYTgsZTliZWE5ZTQsY2M3MTVkNDgsLi4uKSBhdCBpcGlfbm1p X2hhbmRsZXIrMHgyZgp0cmFwKGU5YmVhYTU4KSBhdCB0cmFwKzB4MzYKY2FsbHRyYXAoKSBhdCBj YWxsdHJhcCsweDYKLS0tIHRyYXAgMHgxMywgZWlwID0gMHhjMGJiYjE2OCwgZXNwID0gMHhlOWJl YWE5OCwgZWJwID0gMHhlOWJlYWFiOCAtLS0Kc21wX3RsYl9zaG9vdGRvd24oZTliZWFhZTAsYzBi YmZkN2YsZWE3OTYwMDAsZWE3OTcwMDAsYzE0YjYwMDAsLi4uKSBhdCBzbXBfdGxiX3Nob290ZG93 bisweDk4CnNtcF9pbnZscGdfcmFuZ2UoZWE3OTYwMDAsZWE3OTcwMDAsYzE0YjYwMDAsMCwxLC4u LikgYXQgc21wX2ludmxwZ19yYW5nZSsweDFjCnBtYXBfaW52YWxpZGF0ZV9yYW5nZShjMGZiYjVl MCxlYTc5NjAwMCxlYTc5NzAwMCkgYXQgcG1hcF9pbnZhbGlkYXRlX3JhbmdlKzB4NGYKcG1hcF9x cmVtb3ZlKGVhNzk2MDAwLDEsMCwxNzEsY2MwYmMzYjgsLi4uKSBhdCBwbWFwX3FyZW1vdmUrMHg1 OAp2bV90aHJlYWRfbmV3KGNjZTgxMDAwLDIsMixlOWJlYWM0NCxlOWJlYWJmYywuLi4pIGF0IHZt X3RocmVhZF9uZXcrMHgxNWUKdGhyZWFkX2FsbG9jKDAsY2M3MTVkZDAsNCxjMGM5OTdlNSwyODBh NjY3MCwuLi4pIGF0IHRocmVhZF9hbGxvYysweDRmCmNyZWF0ZV90aHJlYWQoMjgyMjg5ODAsYjEz MWEwMDAsMTAwMDAwLDI4MWRlNzkwLDI4MjI4OTgwLDI4MjI4OTgwLDIsMCwwKSBhdCBjcmVhdGVf dGhyZWFkKzB4OWMKa2Vybl90aHJfbmV3KGM5YWRiNDYwLGU5YmVhYzQ0LDM0LDI4MGE2NjcwLDI4 MjI4OTgwLC4uLikgYXQga2Vybl90aHJfbmV3KzB4NzcKdGhyX25ldyhjOWFkYjQ2MCxlOWJlYWNm OCw4LGMwY2ExYTNhLGMwZDg5ZjY0LC4uLikgYXQgdGhyX25ldysweDU1CnN5c2NhbGwoZTliZWFk MzgpIGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2Nh bGwrMHgyMAotLS0gc3lzY2FsbCAoNDU1LCBGcmVlQlNEIEVMRjMyLCB0aHJfbmV3KSwgZWlwID0g MHgyODBmZDFjYiwgZXNwID0gMHhiZmJmZTQ3YywgZWJwID0gMHhiZmJmZTUzOCAtLS0KClRyYWNp bmcgY29tbWFuZCBjcmVhdCBwaWQgNzkwOTUgdGlkIDEwMDgyNSB0ZCAweGNiZWQ2NjkwCi0tTW9y ZS0tICAgICAgICBjcHVzdG9wX2hhbmRsZXIoNCxlOWM2YjQ4OCxjMGJjOGZkNixlOWM2YjQzOCwy NDYsLi4uKSBhdCBjcHVzdG9wX2hhbmRsZXIrMHgzMgppcGlfbm1pX2hhbmRsZXIoZTljNmI0Mzgs MjQ2LGMwODdmOTM0LGMwZTAyYWZjLGNjZGQ5YWEwLC4uLikgYXQgaXBpX25taV9oYW5kbGVyKzB4 MmYKdHJhcChlOWM2YjQ5NCkgYXQgdHJhcCsweDM2CmNhbGx0cmFwKCkgYXQgY2FsbHRyYXArMHg2 Ci0tLSB0cmFwIDB4MTMsIGVpcCA9IDB4YzA3OTc5NWYsIGVzcCA9IDB4ZTljNmI0ZDQsIGVicCA9 IDB4ZTljNmI0ZjQgLS0tCm5zODI1MF9idXNfaXBlbmQoYzhjMWU5MDAsYzA4NjkxOTgsYzBkZjg3 NzgsYzhjMWU5ODAsYzhjMWU5NTgsLi4uKSBhdCBuczgyNTBfYnVzX2lwZW5kKzB4NWYKdWFydF9p bnRyKGM4YzFlOTAwLGNiZWQ2NjkwLGM4NWU0NGQwLGM4NTk4ZTgwLDQsLi4uKSBhdCB1YXJ0X2lu dHIrMHgzM2IKaW50cl9ldmVudF9oYW5kbGUoYzg1OThlODAsZTljNmI1ODQsYzBmNzk0MzgsMCxj MGY1YmQzYywuLi4pIGF0IGludHJfZXZlbnRfaGFuZGxlKzB4NWMKaW50cl9leGVjdXRlX2hhbmRs ZXJzKGM4NWU0NGQwLGU5YzZiNTg0LDIsZTljNmI1ZTQsYzBiYWI0MDQsLi4uKSBhdCBpbnRyX2V4 ZWN1dGVfaGFuZGxlcnMrMHg0OQpsYXBpY19oYW5kbGVfaW50cigzMCxlOWM2YjU4NCkgYXQgbGFw aWNfaGFuZGxlX2ludHIrMHg0YwpYYXBpY19pc3IxKCkgYXQgWGFwaWNfaXNyMSsweDM0Ci0tLSBp bnRlcnJ1cHQsIGVpcCA9IDB4YzA4OGRjNzAsIGVzcCA9IDB4ZTljNmI1YzQsIGVicCA9IDB4ZTlj NmI1ZTQgLS0tCl9yd19ybG9jayhjMGY1YmQzYyxjMGNhNzM3NiwxODYsZTljNmI2ZDAsZTljNmI4 NzQsLi4uKSBhdCBfcndfcmxvY2srMHgxNTAKY2FjaGVfbG9va3VwKGM5MmI2MjIwLGU5YzZiODYw LGU5YzZiODc0LGMwZjIxOTY4LDAsLi4uKSBhdCBjYWNoZV9sb29rdXArMHg0NgpuZnNfbG9va3Vw KGU5YzZiNzkwLGU5YzZiNzkwLGU5YzZiODQ4LDIwMDAwMCxlOWM2Yjg0OCwuLi4pIGF0IG5mc19s b29rdXArMHhmNgpWT1BfTE9PS1VQX0FQVihjMGRhNWZlMCxlOWM2Yjc5MCxlOWM2Yjg3NCwxZjEs ZTljNmI4NjAsLi4uKSBhdCBWT1BfTE9PS1VQX0FQVisweGE1Cmxvb2t1cChlOWM2Yjg0OCxjMGNh N2FlYSxlYSxjNSxjY2RkOWFhMCwuLi4pIGF0IGxvb2t1cCsweDY2YgpuYW1laShlOWM2Yjg0OCxj YjZlM2E4MCwxZDgsZTljNmJiZDAsZTljNmJhOWMsLi4uKSBhdCBuYW1laSsweDU1ZgprZXJuX3N0 YXRmcyhjYmVkNjY5MCxiZmJmZGUzYiwwLGU5YzZiYTljLDIwMDMwNTE4LC4uLikgYXQga2Vybl9z dGF0ZnMrMHg4YwpzdGF0ZnMoY2JlZDY2OTAsZTljNmJjZjgsOCxjMGNhMjJmMSxjMGQ4OThmMCwu Li4pIGF0IHN0YXRmcysweDNiCi0tTW9yZS0tICAgICAgICBzeXNjYWxsKGU5YzZiZDM4KSBhdCBz eXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjAK LS0tIHN5c2NhbGwgKDM5NiwgRnJlZUJTRCBFTEYzMiwgc3RhdGZzKSwgZWlwID0gMHgyODBlOTc4 YiwgZXNwID0gMHhiZmJmZGUwYywgZWJwID0gMHhiZmJmZTQxOCAtLS0KClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxNTg4IHRkIDB4YzkyNDJkMjAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlk IDEwMTU4MiB0ZCAweGNiZjBhMjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkzIHRpZCAxMDE1NzcgdGQgMHhjY2Q2NzQ2 MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0 aHIxIHBpZCA3OTA5MyB0aWQgMTAxNTcyIHRkIDB4Y2QwMGIwMDAKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEw MTU2NyB0ZCAweGNjZjc1YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoK VHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkzIHRpZCAxMDE1NjIgdGQgMHhjY2Q3YzAwMAot LU1vcmUtLSAgICAgICAgZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEwMTU1NyB0ZCAweGNjZTNiOGMwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDkzIHRpZCAxMDE1NTIgdGQgMHhjYmNmMWFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxNTQ4IHRk IDB4Y2QwMGMyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEwMTU0MyB0ZCAweGNjZDNhOGMwCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5 MDkzIHRpZCAxMDE1MzggdGQgMHhjY2Q1MjAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxNTMzIHRkIDB4 Y2NkOTU0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgotLU1vcmUtLSAg ICAgICAgVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkzIHRpZCAxMDE1MjggdGQgMHhjY2Uw NThjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxNTIzIHRkIDB4Y2NkMjFhZjAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlk IDEwMTUxNyB0ZCAweGNjZTgwOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkzIHRpZCAxMDE1MTEgdGQgMHhjOTI4Zjhj MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0 aHIxIHBpZCA3OTA5MyB0aWQgMTAxNTA1IHRkIDB4Y2NlZjJkMjAKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEw MTUwMCB0ZCAweGNkMDAyZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoK VHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkzIHRpZCAxMDE0OTQgdGQgMHhjZDAxOGFmMApm b3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKLS1Nb3JlLS0gICAgICAgIApUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEwMTQ4OCB0ZCAweGNkMDAxZDIwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDkzIHRpZCAxMDE0ODIgdGQgMHhjOTNjYzIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxNDc2IHRk IDB4Y2NmODNhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEwMTQ3MCB0ZCAweGNjZDUyNDYwCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5 MDkzIHRpZCAxMDE0NjQgdGQgMHhjOTNjNjAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxNDU4IHRkIDB4 Y2NkMzYyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNv bW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEwMTQ1MSB0ZCAweGNjZjhkZDIwCi0tTW9yZS0tICAg ICAgICBmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxNDQ0IHRkIDB4Y2NmMjhkMjAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlk IDEwMTQzNyB0ZCAweGNkMDBkNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkzIHRpZCAxMDE0MjkgdGQgMHhjY2RkNGFm MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0 aHIxIHBpZCA3OTA5MyB0aWQgMTAxNDIyIHRkIDB4Y2NmZWFhZjAKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEw MTQxNSB0ZCAweGM5YmNlNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoK VHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkzIHRpZCAxMDE0MDggdGQgMHhjZDAxMzQ2MApm b3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKCi0tTW9yZS0tICAgICAgICBUcmFj aW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEwMTQwMSB0ZCAweGNjZDFkMDAwCmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlk IDc5MDkzIHRpZCAxMDEzOTQgdGQgMHhjY2Q2NThjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxMzg4IHRk IDB4YzhmNDg2OTAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5n IGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEwMTM4MiB0ZCAweGNjZGUyOGMwCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5 MDkzIHRpZCAxMDEzNzUgdGQgMHhjY2Y1NjQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxMzY4IHRkIDB4 Y2NlNjMyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNv bW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEwMTIxNyB0ZCAweGNiZWE4OGMwCmZvcmtfdHJhbXBv bGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQotLU1vcmUtLSAgICAgICAgClRyYWNpbmcgY29tbWFu ZCB0aHIxIHBpZCA3OTA5MyB0aWQgMTAxMjE1IHRkIDB4Yzk1Mjc2OTAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlk IDEwMTIxMiB0ZCAweGNiZjg1NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkzIHRpZCAxMDExOTggdGQgMHhjY2UyNzAw MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0 aHIxIHBpZCA3OTA5MyB0aWQgMTAxMjM2IHRkIDB4Y2JlZTU2OTAKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTMgdGlkIDEw MTI2MiB0ZCAweGNjMTcxZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoK VHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkzIHRpZCAxMDEyNjEgdGQgMHhjY2Q5NjhjMApm b3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIx IHBpZCA3OTA5MyB0aWQgMTAwNDU0IHRkIDB4Y2E2NDkwMDAKLS1Nb3JlLS0gICAgICAgIHNjaGVk X3N3aXRjaChjYTY0OTAwMCwwLDYwMiwxOGMsNDhkZGVjNDksLi4uKSBhdCBzY2hlZF9zd2l0Y2gr MHgxYzUKbWlfc3dpdGNoKDYwMiwwLGMwYzliN2MwLGNmLGMwZjc4ZGUwLC4uLikgYXQgbWlfc3dp dGNoKzB4MjAwCmNyaXRpY2FsX2V4aXQoMCxjMDg3ZmM2ZiwwKSBhdCBjcml0aWNhbF9leGl0KzB4 YTgKbGFwaWNfaGFuZGxlX3RpbWVyKGU5NTIzYjY0KSBhdCBsYXBpY19oYW5kbGVfdGltZXIrMHgx NTUKWHRpbWVyaW50KCkgYXQgWHRpbWVyaW50KzB4MWYKLS0tIGludGVycnVwdCwgZWlwID0gMHhj MDg3ZmM2ZiwgZXNwID0gMHhlOTUyM2JhNCwgZWJwID0gMHhlOTUyM2JjMCAtLS0KX210eF91bmxv Y2tfZmxhZ3MoY2JlYzlkZDAsMCxjMGM5YzE1NCxmMiwyODBhNjY3MCwuLi4pIGF0IF9tdHhfdW5s b2NrX2ZsYWdzKzB4ZWYKY3JlYXRlX3RocmVhZCgyODIwNDBjMCxiYTBhNzAwMCwxMDAwMDAsMjgx ZGE5OTAsMjgyMDQwYzAsMjgyMDQwYzAsMiwwLDApIGF0IGNyZWF0ZV90aHJlYWQrMHgzMjIKa2Vy bl90aHJfbmV3KGNhNjQ5MDAwLGU5NTIzYzQ0LDM0LDI4MGE2NjcwLDI4MjA0MGMwLC4uLikgYXQg a2Vybl90aHJfbmV3KzB4NzcKdGhyX25ldyhjYTY0OTAwMCxlOTUyM2NmOCw4LGMwY2ExYTNhLGMw ZDg5ZjY0LC4uLikgYXQgdGhyX25ldysweDU1CnN5c2NhbGwoZTk1MjNkMzgpIGF0IHN5c2NhbGwr MHgyYTMKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lz Y2FsbCAoNDU1LCBGcmVlQlNEIEVMRjMyLCB0aHJfbmV3KSwgZWlwID0gMHgyODBmZDFjYiwgZXNw ID0gMHhiZmJmZTQ3YywgZWJwID0gMHhiZmJmZTUzOCAtLS0KClRyYWNpbmcgY29tbWFuZCBjcmVh dCBwaWQgNzkwOTIgdGlkIDEwMDY3MyB0ZCAweGNjNWM0YWYwCnNjaGVkX3N3aXRjaChjYzVjNGFm MCwwLDEwNCwxOTEsOTgwN2Y1NDQsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNo KDEwNCwwLGMwYzlmMzZmLDFlYiw1YywuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dp dGNoKGNjNWM0YWYwLDAsYzBjOWYzNmYsMWEwLDVjLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1 ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscyhjMGM5ZjM2ZiwxNjAsMCwxMDAsMTAwLC4uLikgYXQgc2xl ZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoY2M5MjA1NTAsNWMsYzBjYTFi NjAsMTAwLDAsLi4uKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHgxNwotLU1vcmUtLSAgICAgICAgX3Ns ZWVwKGNjOTIwNTUwLGNjOTIwNWQ4LDE1YyxjMGNhMWI2MCwwLC4uLikgYXQgX3NsZWVwKzB4MzU0 Cmtlcm5fd2FpdChjYzVjNGFmMCwxMzRmNyxlOTk5MmM3NCwwLDAsLi4uKSBhdCBrZXJuX3dhaXQr MHhiNzYKd2FpdDQoY2M1YzRhZjAsZTk5OTJjZjgsMTAsY2M1YzRhZjAsYzBkODZlNjQsLi4uKSBh dCB3YWl0NCsweDNiCnN5c2NhbGwoZTk5OTJkMzgpIGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBf c3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lzY2FsbCAoNywgRnJlZUJT RCBFTEYzMiwgd2FpdDQpLCBlaXAgPSAweDI4MTAwY2RiLCBlc3AgPSAweGJmYmZlOTVjLCBlYnAg PSAweGJmYmZlOTc4IC0tLQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE3 MTUgdGQgMHhjYzMxOTY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNzExIHRkIDB4Yzk0NGNkMjAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBw aWQgNzkwOTAgdGlkIDEwMTcwNyB0ZCAweGNjZjRhMjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE3MDMg dGQgMHhjY2YwMjQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNp bmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNjk5IHRkIDB4Y2NkOTE4YzAKLS1Nb3Jl LS0gICAgICAgIGZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE2OTQgdGQgMHhjY2UyZWQyMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5 MCB0aWQgMTAxNjkwIHRkIDB4Y2NlMmFhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTY4NyB0ZCAweGNj ZWY0NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE2ODMgdGQgMHhjOTExYTY5MApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0 aWQgMTAxNjc5IHRkIDB4Y2NmMGM2OTAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTY3NSB0ZCAweGNkMDA1 MjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKLS1Nb3JlLS0gICAgICAg IFRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNjcxIHRkIDB4Y2NkMDgwMDAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkwOTAgdGlkIDEwMTY2NyB0ZCAweGNjZDVlNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE2 NjMgdGQgMHhjYzI4MjQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNjU4IHRkIDB4Y2NmMzU4YzAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBw aWQgNzkwOTAgdGlkIDEwMTY1NSB0ZCAweGNkMDE2NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE2NTEg dGQgMHhjY2U2Y2FmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNp bmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNjQ3IHRkIDB4Y2NlMGQ4YzAKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCi0tTW9yZS0tICAgICAgICAKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE2NDMgdGQgMHhjYmYwYWFmMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5 MCB0aWQgMTAxNjM5IHRkIDB4Y2NkNWVkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTYzNSB0ZCAweGNj ZDkxNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE2MzEgdGQgMHhjY2Y1OTIzMApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0 aWQgMTAxNjI3IHRkIDB4YzliNWE0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTYyMyB0ZCAweGNkMDBk OGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5k IHRocjEgcGlkIDc5MDkwIHRpZCAxMDE2MTkgdGQgMHhjY2VmNGQyMAotLU1vcmUtLSAgICAgICAg Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkwOTAgdGlkIDEwMTYxNSB0ZCAweGNjZDQ5MDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE2 MTEgdGQgMHhjY2RhNWFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNjA3IHRkIDB4YzllNjI2OTAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBw aWQgNzkwOTAgdGlkIDEwMTYwMyB0ZCAweGNjMzdiMDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE1OTkg dGQgMHhjY2RjNWFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNp bmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNTk1IHRkIDB4Y2NmYzlkMjAKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgotLU1vcmUtLSAgICAgICAgVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE1OTIgdGQgMHhjZDAxODAwMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5 MCB0aWQgMTAxNTg3IHRkIDB4Y2NkMTYwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTU4MSB0ZCAweGNj ZDdjOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE1NzYgdGQgMHhjY2Q5YThjMApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0 aWQgMTAxNTcxIHRkIDB4Yzk0NGM2OTAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTU2NSB0ZCAweGNjZjgz ZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5k IHRocjEgcGlkIDc5MDkwIHRpZCAxMDE1NjAgdGQgMHhjY2Q3ODAwMApmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUKLS1Nb3JlLS0gICAgICAgIApUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkwOTAgdGlkIDEwMTU1NCB0ZCAweGNjZTEyNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE1 NDkgdGQgMHhjY2UzNTIzMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNTQ0IHRkIDB4Y2NkMmE4YzAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBw aWQgNzkwOTAgdGlkIDEwMTUzOSB0ZCAweGNjZWQ3NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE1MzQg dGQgMHhjY2UwNjQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNp bmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNTI5IHRkIDB4Y2QwMTYwMDAKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQg NzkwOTAgdGlkIDEwMTUyNCB0ZCAweGNjZTI3NjkwCi0tTW9yZS0tICAgICAgICBmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5 MCB0aWQgMTAxNTE4IHRkIDB4Y2NkNDFkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTUxMiB0ZCAweGNk MDE1ZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE1MDggdGQgMHhjYzQ1NDQ2MApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0 aWQgMTAxNTAyIHRkIDB4Y2NmMmY4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTQ5NiB0ZCAweGNjZGE5 NDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5k IHRocjEgcGlkIDc5MDkwIHRpZCAxMDE0OTAgdGQgMHhjY2U0YTAwMApmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUKCi0tTW9yZS0tICAgICAgICBUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkwOTAgdGlkIDEwMTQ4NSB0ZCAweGNjZTQzNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE0 NzkgdGQgMHhjY2Q4NThjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNDc0IHRkIDB4Y2NkZjc0NjAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBw aWQgNzkwOTAgdGlkIDEwMTQ2NyB0ZCAweGNiNzg3YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE0NjEg dGQgMHhjY2QyZWFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNp bmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxNDU0IHRkIDB4Y2NlMDZkMjAKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQg NzkwOTAgdGlkIDEwMTQ0NyB0ZCAweGNjNDE2YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtf dHJhbXBvbGluZQotLU1vcmUtLSAgICAgICAgClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5 MCB0aWQgMTAxNDQxIHRkIDB4Y2NmMDJkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTQzNCB0ZCAweGM5 MjNhOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDE0MjggdGQgMHhjY2Y4MDAwMApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0 aWQgMTAxNDIxIHRkIDB4Y2JjYzRkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTQxNCB0ZCAweGNjZmU2 MDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5k IHRocjEgcGlkIDc5MDkwIHRpZCAxMDE0MDUgdGQgMHhjY2Q5ZDhjMApmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQg MTAxMzk4IHRkIDB4Y2NkNjYwMDAKLS1Nb3JlLS0gICAgICAgIGZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEz OTEgdGQgMHhjYjE2MWQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxMzg0IHRkIDB4Y2NmMmY2OTAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBw aWQgNzkwOTAgdGlkIDEwMTM3NyB0ZCAweGNjZjkyNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEzNjcg dGQgMHhjY2ZmZDQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNp bmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxMzYxIHRkIDB4Y2NkNzQ0NjAKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQg NzkwOTAgdGlkIDEwMTM1MyB0ZCAweGNkMDAyOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtf dHJhbXBvbGluZQoKLS1Nb3JlLS0gICAgICAgIFRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5 MCB0aWQgMTAxMzQ3IHRkIDB4Y2NkOTA0NjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTM0MyB0ZCAweGNj ZDg5YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEyNTkgdGQgMHhjYmY3ZmQyMApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0 aWQgMTAxMzA4IHRkIDB4Y2NkYTBkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTMzNCB0ZCAweGNjZDcw MDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5k IHRocjEgcGlkIDc5MDkwIHRpZCAxMDEzMzEgdGQgMHhjY2U2NTQ2MApmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQg MTAxMzI4IHRkIDB4Y2NmNWUyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5l Ci0tTW9yZS0tICAgICAgICAKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEz MjQgdGQgMHhjY2U1ZjQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxMzE5IHRkIDB4Y2NkOWNhZjAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBw aWQgNzkwOTAgdGlkIDEwMTMxMiB0ZCAweGNjZGEyOGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEzMDcg dGQgMHhjY2ZmZDAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNp bmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxMjk3IHRkIDB4Yzk0OTE2OTAKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQg NzkwOTAgdGlkIDEwMTI4OCB0ZCAweGNjZGMzYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtf dHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEyODQgdGQg MHhjY2Q3YTIzMAotLU1vcmUtLSAgICAgICAgZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTI4MCB0ZCAweGNj ZTU5MDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEyNzQgdGQgMHhjYmViNDQ2MApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0 aWQgMTAxMjY5IHRkIDB4Y2NmYzUwMDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTI1NCB0ZCAweGNjZjFh OGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5k IHRocjEgcGlkIDc5MDkwIHRpZCAxMDEyNTAgdGQgMHhjY2VlMTAwMApmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQg MTAxMjQwIHRkIDB4Y2JmNTcyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5l CgotLU1vcmUtLSAgICAgICAgVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEy MzQgdGQgMHhjYmQzMDY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxMjMzIHRkIDB4Y2NmZTlhZjAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBw aWQgNzkwOTAgdGlkIDEwMTIwMCB0ZCAweGNjZTA2MDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEyMTAg dGQgMHhjY2Y4MTY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNp bmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0aWQgMTAxMjI3IHRkIDB4Yzk3YmU4YzAKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQg NzkwOTAgdGlkIDEwMTI0OCB0ZCAweGNhZDMzYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtf dHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEyNTYgdGQg MHhjY2QxZmFmMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKLS1Nb3JlLS0g ICAgICAgIApUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwOTAgdGlkIDEwMTI2NCB0ZCAweGNj ZWY0OGMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDkwIHRpZCAxMDEyNjcgdGQgMHhjY2UyZTY5MApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA5MCB0 aWQgMTAwMzIwIHRkIDB4YzllMjZkMjAKY3B1c3RvcF9oYW5kbGVyKDQwLGU5MzAxOWU4LGMwYmM4 ZmQ2LGU5MzAxOTc4LGMwZGY4ODY4LC4uLikgYXQgY3B1c3RvcF9oYW5kbGVyKzB4MzIKaXBpX25t aV9oYW5kbGVyKGU5MzAxOTc4LGMwZGY4ODY4LGMwZGY4ODY4LGM5ZTI2ZDIwLGM5ZTEwYWEwLC4u LikgYXQgaXBpX25taV9oYW5kbGVyKzB4MmYKdHJhcChlOTMwMTlmNCkgYXQgdHJhcCsweDM2CmNh bGx0cmFwKCkgYXQgY2FsbHRyYXArMHg2Ci0tLSB0cmFwIDB4MTMsIGVpcCA9IDB4YzBiY2NmOTks IGVzcCA9IDB4ZTkzMDFhMzQsIGVicCA9IDB4ZTkzMDFhNTAgLS0tCkRFTEFZKDEsYzllMjZkMjAs YzBlMDFjMzQsMCxlOTMwMWE5MCwuLi4pIGF0IERFTEFZKzB4ODkKX210eF9sb2NrX3NwaW4oYzBl MDFjMzQsYzllMjZkMjAsMCxjMGNkNDBkZCw0NjIsLi4uKSBhdCBfbXR4X2xvY2tfc3BpbisweDZj Cl9tdHhfbG9ja19zcGluX2ZsYWdzKGMwZTAxYzM0LDAsYzBjZDQwZGQsNDYyLGY1LC4uLikgYXQg X210eF9sb2NrX3NwaW5fZmxhZ3MrMHgxNDYKc21wX3RsYl9zaG9vdGRvd24oZTkzMDFhZTAsYzBi YmZkN2YsZWE3OWYwMDAsZWE3YTAwMDAsYzE0YjYwMDAsLi4uKSBhdCBzbXBfdGxiX3Nob290ZG93 bisweDY2CnNtcF9pbnZscGdfcmFuZ2UoZWE3OWYwMDAsZWE3YTAwMDAsYzE0YjYwMDAsMCwxLC4u LikgYXQgc21wX2ludmxwZ19yYW5nZSsweDFjCnBtYXBfaW52YWxpZGF0ZV9yYW5nZShjMGZiYjVl MCxlYTc5ZjAwMCxlYTdhMDAwMCkgYXQgcG1hcF9pbnZhbGlkYXRlX3JhbmdlKzB4NGYKcG1hcF9x cmVtb3ZlKGVhNzlmMDAwLDEsMCwxNzEsYzlhMTY0NDAsLi4uKSBhdCBwbWFwX3FyZW1vdmUrMHg1 OAotLU1vcmUtLSAgICAgICAgdm1fdGhyZWFkX25ldyhjYmNjZDY5MCwyLDIsZTkzMDFjNDQsZTkz MDFiZmMsLi4uKSBhdCB2bV90aHJlYWRfbmV3KzB4MTVlCnRocmVhZF9hbGxvYygwLGM5ZTEwYjI4 LDQsYzBjOTk3ZTUsMjgwYTY2NzAsLi4uKSBhdCB0aHJlYWRfYWxsb2MrMHg0ZgpjcmVhdGVfdGhy ZWFkKDI4MjM0YjQwLGI0MDQ3MDAwLDEwMDAwMCwyODFkMjk5MCwyODIzNGI0MCwyODIzNGI0MCwy LDAsMCkgYXQgY3JlYXRlX3RocmVhZCsweDljCmtlcm5fdGhyX25ldyhjOWUyNmQyMCxlOTMwMWM0 NCwzNCwyODBhNjY3MCwyODIzNGI0MCwuLi4pIGF0IGtlcm5fdGhyX25ldysweDc3CnRocl9uZXco YzllMjZkMjAsZTkzMDFjZjgsOCxjMGNhMWEzYSxjMGQ4OWY2NCwuLi4pIGF0IHRocl9uZXcrMHg1 NQpzeXNjYWxsKGU5MzAxZDM4KSBhdCBzeXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBh dCBYaW50MHg4MF9zeXNjYWxsKzB4MjAKLS0tIHN5c2NhbGwgKDQ1NSwgRnJlZUJTRCBFTEYzMiwg dGhyX25ldyksIGVpcCA9IDB4MjgwZmQxY2IsIGVzcCA9IDB4YmZiZmU0N2MsIGVicCA9IDB4YmZi ZmU1MzggLS0tCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwODggdGlkIDEwMTQ5OCB0ZCAw eGNjZDg1YWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDE0OTIgdGQgMHhjYmQ3MjIzMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4 OCB0aWQgMTAxNDg2IHRkIDB4YzkyMzlhZjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwODggdGlkIDEwMTQ4MCB0ZCAweGNj ZjZkNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQotLU1vcmUtLSAgICAg ICAgClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4OCB0aWQgMTAxNDcyIHRkIDB4Y2NlZDc4 YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkwODggdGlkIDEwMTQ2NiB0ZCAweGM5M2NjMDAwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAx MDE0NjIgdGQgMHhjY2Q3YTQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4OCB0aWQgMTAxNDU2IHRkIDB4Y2NkMTdhZjAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkwODggdGlkIDEwMTQ0OSB0ZCAweGNjNGQzNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDE0 NDIgdGQgMHhjOTVkYWQyMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4OCB0aWQgMTAxNDM1IHRkIDB4Y2NlOWJhZjAKLS1N b3JlLS0gICAgICAgIGZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDE0MzAgdGQgMHhjY2U4ZjIzMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTA4OCB0aWQgMTAxNDIzIHRkIDB4Y2JlZmI2OTAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwODggdGlkIDEwMTQxNyB0ZCAw eGNjZjA5MjMwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDE0MDkgdGQgMHhjY2UyYTIzMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4 OCB0aWQgMTAxNDAyIHRkIDB4Y2NmZmRkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwODggdGlkIDEwMTM5NSB0ZCAweGNi ZTI5ZDIwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKLS1Nb3JlLS0gICAg ICAgIFRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4OCB0aWQgMTAxMzg3IHRkIDB4Y2JlOWYy MzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkwODggdGlkIDEwMTM4MSB0ZCAweGNjZmIwYWYwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAx MDEzNzQgdGQgMHhjY2Q2MDQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4OCB0aWQgMTAxMzY5IHRkIDB4Y2NlZDU2OTAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkwODggdGlkIDEwMTM2MiB0ZCAweGM4YzY1NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDEz NTYgdGQgMHhjY2Q3YzQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4OCB0aWQgMTAxMzUxIHRkIDB4Y2NkZDRkMjAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCi0tTW9yZS0tICAgICAgICAKVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDEzNDUgdGQgMHhjZDAxNmQyMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTA4OCB0aWQgMTAxMjQ2IHRkIDB4Y2NlNGIyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwODggdGlkIDEwMTM0MSB0ZCAw eGNjZjlhNDYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDEyOTUgdGQgMHhjY2Q3NWQyMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4 OCB0aWQgMTAxMjcyIHRkIDB4Y2NkMzhkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwODggdGlkIDEwMTI0NyB0ZCAweGNj ZmU2NjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDEyMTkgdGQgMHhjYzRlYjY5MAotLU1vcmUtLSAgICAg ICAgZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkwODggdGlkIDEwMTMwMCB0ZCAweGM5NGNlOGMwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAx MDEzMzUgdGQgMHhjZDAxNjhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4OCB0aWQgMTAxMzMyIHRkIDB4Y2NlNzY0NjAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkwODggdGlkIDEwMTMwNCB0ZCAweGNjZjAyNjkwCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDEz MjMgdGQgMHhjY2ZjNTY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4OCB0aWQgMTAxMzE4IHRkIDB4Y2NkNTlhZjAKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgotLU1vcmUtLSAgICAgICAgVHJhY2lu ZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDEzMTMgdGQgMHhjY2Q5YmFmMApmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3 OTA4OCB0aWQgMTAxMzA5IHRkIDB4Y2NmMTMyMzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwODggdGlkIDEwMTI5OCB0ZCAw eGNjZDZmYWYwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBj b21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDEyOTMgdGQgMHhjY2Q4ZDIzMApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4 OCB0aWQgMTAxMjg5IHRkIDB4Y2NiZGNkMjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhyMSBwaWQgNzkwODggdGlkIDEwMTI4MyB0ZCAweGNj ZmE5MDAwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDg4IHRpZCAxMDEyMDggdGQgMHhjY2RhNThjMApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKLS1Nb3JlLS0gICAgICAgIApUcmFjaW5nIGNvbW1hbmQg dGhyMSBwaWQgNzkwODggdGlkIDEwMTIwNyB0ZCAweGNjZDliOGMwCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDg4IHRpZCAx MDEyMDYgdGQgMHhjY2Y4ZDhjMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUK ClRyYWNpbmcgY29tbWFuZCB0aHIxIHBpZCA3OTA4OCB0aWQgMTAxMjQyIHRkIDB4Y2NkOWIwMDAK Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdGhy MSBwaWQgNzkwODggdGlkIDEwMDQ2NCB0ZCAweGM5MmQzMDAwCnNjaGVkX3N3aXRjaChjOTJkMzAw MCwwLDEwNCwxOTEsNDhkMGIwZTAsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNo KDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0 Y2goYzkyZDMwMDAsMCxjMGM5ZjM2ZiwxYTAsMCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYK c2xlZXBxX2NhdGNoX3NpZ25hbHMoYzBjOWYzNmYsMTYwLDAsMTAwLDEwMCwuLi4pIGF0IHNsZWVw cV9jYXRjaF9zaWduYWxzKzB4YjcKc2xlZXBxX3dhaXRfc2lnKGNjMDkxMjgwLDAsYzBjOWM5MTcs MTAwLDAsLi4uKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHgxNwpfc2xlZXAoY2MwOTEyODAsYzBkZmE5 YzAsMTAwLGMwYzljOTE3LDAsLi4uKSBhdCBfc2xlZXArMHgzNTQKZG9fd2FpdCgwLDAsMCxlOTU0 MmM4MCxjMDhjZDVkMCkgYXQgZG9fd2FpdCsweDUxMQpfX3VtdHhfb3Bfd2FpdChjOTJkMzAwMCxl OTU0MmNmOCxlOTU0MmQyYyxjMGJjOGQ1MyxjOTJkMzAwMCwuLi4pIGF0IF9fdW10eF9vcF93YWl0 KzB4NWYKX3VtdHhfb3AoYzkyZDMwMDAsZTk1NDJjZjgsMTQsYzBjYTI4MzksYzBkODlmNDgsLi4u KSBhdCBfdW10eF9vcCsweDI3Ci0tTW9yZS0tICAgICAgICBzeXNjYWxsKGU5NTQyZDM4KSBhdCBz eXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjAK LS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEYzMiwgX3VtdHhfb3ApLCBlaXAgPSAweDI4MGIx MzE3LCBlc3AgPSAweGJmYmZlNGFjLCBlYnAgPSAweGJmYmZlNGM4IC0tLQoKVHJhY2luZyBjb21t YW5kIHRocjEgcGlkIDc5MDg3IHRpZCAxMDA4ODIgdGQgMHhjYzRlM2FmMApzY2hlZF9zd2l0Y2go Y2M0ZTNhZjAsMCwxMDQsMTkxLDk3Nzk5NmE0LC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1p X3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsNWMsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xl ZXBxX3N3aXRjaChjYzRlM2FmMCwwLGMwYzlmMzZmLDFhMCw1YywuLi4pIGF0IHNsZWVwcV9zd2l0 Y2grMHgxNWYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoYzBjOWYzNmYsMTYwLDAsMTAwLDEwMCwuLi4p IGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4YjcKc2xlZXBxX3dhaXRfc2lnKGNjZGM4NTUwLDVj LGMwY2ExYjYwLDEwMCwwLC4uLikgYXQgc2xlZXBxX3dhaXRfc2lnKzB4MTcKX3NsZWVwKGNjZGM4 NTUwLGNjZGM4NWQ4LDE1YyxjMGNhMWI2MCwwLC4uLikgYXQgX3NsZWVwKzB4MzU0Cmtlcm5fd2Fp dChjYzRlM2FmMCwxMzRmMCxlOWQxNmM3NCwwLDAsLi4uKSBhdCBrZXJuX3dhaXQrMHhiNzYKd2Fp dDQoY2M0ZTNhZjAsZTlkMTZjZjgsMTAsY2M0ZTNhZjAsYzBkODZlNjQsLi4uKSBhdCB3YWl0NCsw eDNiCnN5c2NhbGwoZTlkMTZkMzgpIGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBfc3lzY2FsbCgp IGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lzY2FsbCAoNywgRnJlZUJTRCBFTEYzMiwg d2FpdDQpLCBlaXAgPSAweDI4MTE0Y2RiLCBlc3AgPSAweGJmYmZlOTRjLCBlYnAgPSAweGJmYmZl OTY4IC0tLQoKVHJhY2luZyBjb21tYW5kIHRocjEgcGlkIDc5MDc4IHRpZCAxMDEwNzYgdGQgMHhj OTMyOWFmMApzY2hlZF9zd2l0Y2goYzkzMjlhZjAsMCwxMDQsMTkxLDEzMDUxNDJkLC4uLikgYXQg c2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsNWMsLi4uKSBh dCBtaV9zd2l0Y2grMHgyMDAKLS1Nb3JlLS0gICAgICAgIHNsZWVwcV9zd2l0Y2goYzkzMjlhZjAs MCxjMGM5ZjM2ZiwxYTAsNWMsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV9jYXRj aF9zaWduYWxzKDNlOSxjMDhjYTUyMCxjOTMyOWFmMCwxLDEwMCwuLi4pIGF0IHNsZWVwcV9jYXRj aF9zaWduYWxzKzB4YjcKc2xlZXBxX3RpbWVkd2FpdF9zaWcoYzBkZjg2YzQsNWMsYzBjOWMzZjMs MTAwLDAsLi4uKSBhdCBzbGVlcHFfdGltZWR3YWl0X3NpZysweDFhCl9zbGVlcChjMGRmODZjNCww LDE1YyxjMGM5YzNmMywzZTksLi4uKSBhdCBfc2xlZXArMHgzMWUKa2Vybl9uYW5vc2xlZXAoYzkz MjlhZjAsZTlmNjFjNjQsZTlmNjFjNmMsMSwwLC4uLikgYXQga2Vybl9uYW5vc2xlZXArMHhjMQpu YW5vc2xlZXAoYzkzMjlhZjAsZTlmNjFjZjgsOCxjMGNhMWNhNCxjMGQ4ODdlMCwuLi4pIGF0IG5h bm9zbGVlcCsweDZmCnN5c2NhbGwoZTlmNjFkMzgpIGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBf c3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lzY2FsbCAoMjQwLCBGcmVl QlNEIEVMRjMyLCBuYW5vc2xlZXApLCBlaXAgPSAweDI4MTgyNmNmLCBlc3AgPSAweGJmYmZlOTZj LCBlYnAgPSAweGJmYmZlOTk4IC0tLQoKVHJhY2luZyBjb21tYW5kIG1rZGlyIHBpZCA3OTA3NyB0 aWQgMTAxMDg1IHRkIDB4Y2M0ZGE0NjAKc2NoZWRfc3dpdGNoKGNjNGRhNDYwLDAsMTA0LDE5MSwx MzZkOTA5MCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYz NmYsMWViLDVjLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goY2M0ZGE0NjAs MCxjMGM5ZjM2ZiwxYTAsNWMsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV9jYXRj aF9zaWduYWxzKDNlOSxjMDhjYTUyMCxjYzRkYTQ2MCwxLDEwMCwuLi4pIGF0IHNsZWVwcV9jYXRj aF9zaWduYWxzKzB4YjcKc2xlZXBxX3RpbWVkd2FpdF9zaWcoYzBkZjg2YzQsNWMsYzBjOWMzZjMs MTAwLDAsLi4uKSBhdCBzbGVlcHFfdGltZWR3YWl0X3NpZysweDFhCl9zbGVlcChjMGRmODZjNCww LDE1YyxjMGM5YzNmMywzZTksLi4uKSBhdCBfc2xlZXArMHgzMWUKa2Vybl9uYW5vc2xlZXAoY2M0 ZGE0NjAsZTlmN2NjNjQsZTlmN2NjNmMsMSwwLC4uLikgYXQga2Vybl9uYW5vc2xlZXArMHhjMQpu YW5vc2xlZXAoY2M0ZGE0NjAsZTlmN2NjZjgsOCxjMGNhMWNhNCxjMGQ4ODdlMCwuLi4pIGF0IG5h bm9zbGVlcCsweDZmCnN5c2NhbGwoZTlmN2NkMzgpIGF0IHN5c2NhbGwrMHgyYTMKLS1Nb3JlLS0g ICAgICAgIFhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjAKLS0tIHN5 c2NhbGwgKDI0MCwgRnJlZUJTRCBFTEYzMiwgbmFub3NsZWVwKSwgZWlwID0gMHgyODE2ZTZjZiwg ZXNwID0gMHhiZmJmZTk3YywgZWJwID0gMHhiZmJmZTlhOCAtLS0KClRyYWNpbmcgY29tbWFuZCBj cmVhdCBwaWQgNzkwNzYgdGlkIDEwMDQ4NiB0ZCAweGM5MzA3NDYwCnNjaGVkX3N3aXRjaChjOTMw NzQ2MCwwLDEwNCwxOTEsMTNjOTA0ODQsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dp dGNoKDEwNCwwLGMwYzlmMzZmLDFlYiw1YywuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFf c3dpdGNoKGM5MzA3NDYwLDAsYzBjOWYzNmYsMWEwLDVjLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsw eDE1ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygzZTksYzA4Y2E1MjAsYzkzMDc0NjAsMSwxMDAsLi4u KSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweGI3CnNsZWVwcV90aW1lZHdhaXRfc2lnKGMwZGY4 NmM0LDVjLGMwYzljM2YzLDEwMCwwLC4uLikgYXQgc2xlZXBxX3RpbWVkd2FpdF9zaWcrMHgxYQpf c2xlZXAoYzBkZjg2YzQsMCwxNWMsYzBjOWMzZjMsM2U5LC4uLikgYXQgX3NsZWVwKzB4MzFlCmtl cm5fbmFub3NsZWVwKGM5MzA3NDYwLGU5NTg0YzY0LGU5NTg0YzZjLDEsMCwuLi4pIGF0IGtlcm5f bmFub3NsZWVwKzB4YzEKbmFub3NsZWVwKGM5MzA3NDYwLGU5NTg0Y2Y4LDgsYzBjYTFjYTQsYzBk ODg3ZTAsLi4uKSBhdCBuYW5vc2xlZXArMHg2ZgpzeXNjYWxsKGU5NTg0ZDM4KSBhdCBzeXNjYWxs KzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjAKLS0tIHN5 c2NhbGwgKDI0MCwgRnJlZUJTRCBFTEYzMiwgbmFub3NsZWVwKSwgZWlwID0gMHgyODE2ZTZjZiwg ZXNwID0gMHhiZmJmZTk3YywgZWJwID0gMHhiZmJmZTlhOCAtLS0KClRyYWNpbmcgY29tbWFuZCBy dyBwaWQgNzkwNzQgdGlkIDEwMDUyNSB0ZCAweGNiZDRhOGMwCnNjaGVkX3N3aXRjaChjYmQ0YThj MCwwLDEwNCwxOTEsMTI1NmJhMDMsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNo KDEwNCwwLGMwYzlmMzZmLDFlYiw1YywuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dp dGNoKGNiZDRhOGMwLDAsYzBjOWYzNmYsMWEwLDVjLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1 ZgotLU1vcmUtLSAgICAgICAgc2xlZXBxX2NhdGNoX3NpZ25hbHMoM2U5LGMwOGNhNTIwLGNiZDRh OGMwLDQsMTAwLC4uLikgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfdGltZWR3 YWl0X3NpZyhjMGRmODZjNCw1YyxjMGM5YzNmMywxMDAsMCwuLi4pIGF0IHNsZWVwcV90aW1lZHdh aXRfc2lnKzB4MWEKX3NsZWVwKGMwZGY4NmM0LDAsMTVjLGMwYzljM2YzLDNlOSwuLi4pIGF0IF9z bGVlcCsweDMxZQprZXJuX25hbm9zbGVlcChjYmQ0YThjMCxlOTYzY2M2NCxlOTYzY2M2YywxLDAs Li4uKSBhdCBrZXJuX25hbm9zbGVlcCsweGMxCm5hbm9zbGVlcChjYmQ0YThjMCxlOTYzY2NmOCw4 LGMwY2ExY2E0LGMwZDg4N2UwLC4uLikgYXQgbmFub3NsZWVwKzB4NmYKc3lzY2FsbChlOTYzY2Qz OCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2Fs bCsweDIwCi0tLSBzeXNjYWxsICgyNDAsIEZyZWVCU0QgRUxGMzIsIG5hbm9zbGVlcCksIGVpcCA9 IDB4MjgxNmU2Y2YsIGVzcCA9IDB4YmZiZmU5OWMsIGVicCA9IDB4YmZiZmU5YzggLS0tCgpUcmFj aW5nIGNvbW1hbmQgbmZzaW9kIDAgcGlkIDc3NjcxIHRpZCAxMDExMDIgdGQgMHhjOTcwODIzMApz Y2hlZF9zd2l0Y2goYzk3MDgyMzAsMCwxMDQsMTkxLGYzZTRmZWMyLC4uLikgYXQgc2NoZWRfc3dp dGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsNWMsLi4uKSBhdCBtaV9zd2l0 Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjOTcwODIzMCwwLGMwYzlmMzZmLDFhMCw1YywuLi4pIGF0 IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoMWQ0YzAsYzA4Y2E1MjAs Yzk3MDgyMzAsMiwxMDAsLi4uKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweGI3CnNsZWVwcV90 aW1lZHdhaXRfc2lnKGMwZjYxODQwLDVjLGMwYzkwODFhLDEwMCwwLC4uLikgYXQgc2xlZXBxX3Rp bWVkd2FpdF9zaWcrMHgxYQpfc2xlZXAoYzBmNjE4NDAsYzBmNjE4MTAsMTVjLGMwYzkwODFhLDFk NGMwLC4uLikgYXQgX3NsZWVwKzB4MzFlCm5mc3N2Y19pb2QoYzBmNjExYzAsZTlmYWZkMzgsYzBj OTY0NmEsMzQzLGNiN2E1N2Y4LC4uLikgYXQgbmZzc3ZjX2lvZCsweGNmCmZvcmtfZXhpdChjMGE1 NDFiMCxjMGY2MTFjMCxlOWZhZmQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGU5 ZmFmZDcwLCBlYnAgPSAwIC0tLQotLU1vcmUtLSAgICAgICAgClRyYWNpbmcgY29tbWFuZCBydW4g cGlkIDM1NTQgdGlkIDEwMDM4NSB0ZCAweGNhZjhiNjkwCnNjaGVkX3N3aXRjaChjYWY4YjY5MCww LDEwNCwxOTEsOTYzMzQ5NmMsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEw NCwwLGMwYzlmMzZmLDFlYiw1YywuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNo KGNhZjhiNjkwLDAsYzBjOWYzNmYsMWEwLDVjLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1Zgpz bGVlcHFfY2F0Y2hfc2lnbmFscyhjMGM5ZjM2ZiwxNjAsMCwxMDAsMTAwLC4uLikgYXQgc2xlZXBx X2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoYzkyNjYwMDAsNWMsYzBjYTFiNjAs MTAwLDAsLi4uKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHgxNwpfc2xlZXAoYzkyNjYwMDAsYzkyNjYw ODgsMTVjLGMwY2ExYjYwLDAsLi4uKSBhdCBfc2xlZXArMHgzNTQKa2Vybl93YWl0KGNhZjhiNjkw LDEzNGUyLGU5NDMxYzc0LDAsMCwuLi4pIGF0IGtlcm5fd2FpdCsweGI3Ngp3YWl0NChjYWY4YjY5 MCxlOTQzMWNmOCwxMCxjYWY4YjY5MCxjMGQ4NmU2NCwuLi4pIGF0IHdhaXQ0KzB4M2IKc3lzY2Fs bChlOTQzMWQzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4 ODBfc3lzY2FsbCsweDIwCi0tLSBzeXNjYWxsICg3LCBGcmVlQlNEIEVMRjMyLCB3YWl0NCksIGVp cCA9IDB4MjgwZmZjZGIsIGVzcCA9IDB4YmZiZmU0MGMsIGVicCA9IDB4YmZiZmU0MjggLS0tCgpU cmFjaW5nIGNvbW1hbmQgcnVuIHBpZCAzNTUzIHRpZCAxMDA0MTAgdGQgMHhjYzRkZTQ2MAoKVHJh Y2luZyBjb21tYW5kIHJ1biBwaWQgMzU1MiB0aWQgMTAwMTQ1IHRkIDB4Yzk2M2EwMDAKc2NoZWRf c3dpdGNoKGM5NjNhMDAwLDAsMTA0LDE5MSxjMGFhZDMyZCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsw eDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDVjLC4uLikgYXQgbWlfc3dpdGNoKzB4 MjAwCnNsZWVwcV9zd2l0Y2goYzk2M2EwMDAsMCxjMGM5ZjM2ZiwxYTAsNWMsLi4uKSBhdCBzbGVl cHFfc3dpdGNoKzB4MTVmCi0tTW9yZS0tICAgICAgICBzbGVlcHFfY2F0Y2hfc2lnbmFscygzZTks YzA4Y2E1MjAsYzk2M2EwMDAsMSwxMDAsLi4uKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweGI3 CnNsZWVwcV90aW1lZHdhaXRfc2lnKGMwZGY4NmM0LDVjLGMwYzljM2YzLDEwMCwwLC4uLikgYXQg c2xlZXBxX3RpbWVkd2FpdF9zaWcrMHgxYQpfc2xlZXAoYzBkZjg2YzQsMCwxNWMsYzBjOWMzZjMs M2U5LC4uLikgYXQgX3NsZWVwKzB4MzFlCmtlcm5fbmFub3NsZWVwKGM5NjNhMDAwLGU5MDQ4YzY0 LGU5MDQ4YzZjLDEsMCwuLi4pIGF0IGtlcm5fbmFub3NsZWVwKzB4YzEKbmFub3NsZWVwKGM5NjNh MDAwLGU5MDQ4Y2Y4LDgsYzBjYTFjYTQsYzBkODg3ZTAsLi4uKSBhdCBuYW5vc2xlZXArMHg2Zgpz eXNjYWxsKGU5MDQ4ZDM4KSBhdCBzeXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBY aW50MHg4MF9zeXNjYWxsKzB4MjAKLS0tIHN5c2NhbGwgKDI0MCwgRnJlZUJTRCBFTEYzMiwgbmFu b3NsZWVwKSwgZWlwID0gMHgyODE2ZDZjZiwgZXNwID0gMHhiZmJmZThkYywgZWJwID0gMHhiZmJm ZTkwOCAtLS0KClRyYWNpbmcgY29tbWFuZCBzaCBwaWQgMzU0NSB0aWQgMTAwMTY5IHRkIDB4Yzkz MzgyMzAKClRyYWNpbmcgY29tbWFuZCBtZDAgcGlkIDE4NDcgdGlkIDEwMDE1NCB0ZCAweGM5YTA5 NDYwCnNjaGVkX3N3aXRjaChjOWEwOTQ2MCwwLDEwNCwxOTEsMjg0YWJjYTAsLi4uKSBhdCBzY2hl ZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiw0YywuLi4pIGF0IG1p X3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM5YTA5NDYwLDAsYzBjOWYzNmYsMjYwLDAsLi4u KSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV93YWl0KGM5MWI5ODAwLDRjLGMwYzZkYjRj LDAsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NjMKX3NsZWVwKGM5MWI5ODAwLGM5MWI5ODIwLDI0 YyxjMGM2ZGI0YywwLC4uLikgYXQgX3NsZWVwKzB4MzZiCm1kX2t0aHJlYWQoYzkxYjk4MDAsZTkw NjdkMzgsYzBjOTY0NmEsMzQzLGM5YTA0MmE4LC4uLikgYXQgbWRfa3RocmVhZCsweDEyNQpmb3Jr X2V4aXQoYzA2YjVjODAsYzkxYjk4MDAsZTkwNjdkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS1Nb3JlLS0gICAgICAgIC0tLSB0 cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTkwNjdkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNv bW1hbmQgY3NoIHBpZCAxMzMyIHRpZCAxMDAxMzYgdGQgMHhjOTYzYWQyMAoKVHJhY2luZyBjb21t YW5kIGxvZ2luIHBpZCAxMzMwIHRpZCAxMDAxNjMgdGQgMHhjOTYwOGQyMAoKVHJhY2luZyBjb21t YW5kIHNzaGQgcGlkIDEyNTIgdGlkIDEwMDExMCB0ZCAweGM5NTJiNDYwCnNjaGVkX3N3aXRjaChj OTUyYjQ2MCwwLDEwNCwxOTEsZjVkMGJhMCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9z d2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBx X3N3aXRjaChjOTUyYjQ2MCwwLGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsw eDE1ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscyhjMDg3ZmNlYSxjOWIyMzk5MCwwLGMwYzk5N2U1LGM5 NTJiNDYwLC4uLikgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWco YzliMjM5YTQsMCxlOGZjNGE3YywxMDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysweDE3Cl9j dl93YWl0X3NpZyhjOWIyMzlhNCxjOWIyMzk5MCxjMGNhMTU2ZCw2MDMsYzkzZWJiOTgsLi4uKSBh dCBfY3Zfd2FpdF9zaWcrMHgyNDAKc2VsdGR3YWl0KGM5M2ViYjk4LDU4LGM5YmU5YzgwLGM5NTJi NDYwLGViZSwuLi4pIGF0IHNlbHRkd2FpdCsweGEyCmtlcm5fc2VsZWN0KGM5NTJiNDYwLDUsMjg2 MDkwYjAsMCwwLDAsMjAsODA4MjMwOCwxKSBhdCBrZXJuX3NlbGVjdCsweDRmNApzZWxlY3QoYzk1 MmI0NjAsZThmYzRjZjgsMTQsYzk1MmI0NjAsYzBkODc3Y2MsLi4uKSBhdCBzZWxlY3QrMHg2Ngpz eXNjYWxsKGU4ZmM0ZDM4KSBhdCBzeXNjYWxsKzB4MmEzClhpbnQweDgwX3N5c2NhbGwoKSBhdCBY aW50MHg4MF9zeXNjYWxsKzB4MjAKLS0tIHN5c2NhbGwgKDkzLCBGcmVlQlNEIEVMRjMyLCBzZWxl Y3QpLCBlaXAgPSAweDI4M2NkYzMzLCBlc3AgPSAweGJmYmZkZjFjLCBlYnAgPSAweGJmYmZlZTM4 IC0tLQoKLS1Nb3JlLS0gICAgICAgIFRyYWNpbmcgY29tbWFuZCBzeXNsb2dkIHBpZCA5NzYgdGlk IDEwMDI2MCB0ZCAweGM5YjIxMjMwCnNjaGVkX3N3aXRjaChjOWIyMTIzMCwwLDEwNCwxOTEsMTY5 ZGQ5NTQsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZm LDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzliMjEyMzAsMCxj MGM5ZjM2ZiwxYTAsMCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX2NhdGNoX3Np Z25hbHMoYzA4N2ZjZWEsYzliMjIyOTAsMCxjMGM5OTdlNSxjOWIyMTIzMCwuLi4pIGF0IHNsZWVw cV9jYXRjaF9zaWduYWxzKzB4YjcKc2xlZXBxX3dhaXRfc2lnKGM5YjIyMmE0LDAsZTkyMWRhN2Ms MTAxLDAsLi4uKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHgxNwpfY3Zfd2FpdF9zaWcoYzliMjIyYTQs YzliMjIyOTAsYzBjYTE1NmQsNjAzLGM5NGE3OWQ4LC4uLikgYXQgX2N2X3dhaXRfc2lnKzB4MjQw CnNlbHRkd2FpdChjOTRhNzlkOCw1OCxjODU3NTI4MCxjOWIyMTIzMCw1OCwuLi4pIGF0IHNlbHRk d2FpdCsweGEyCmtlcm5fc2VsZWN0KGM5YjIxMjMwLDgsMjgyMjkwYWMsMCwwLDAsMjAsMCwyODIy YWMwMCkgYXQga2Vybl9zZWxlY3QrMHg0ZjQKc2VsZWN0KGM5YjIxMjMwLGU5MjFkY2Y4LDE0LGMw Y2MxNzRkLGMwZDg3N2NjLC4uLikgYXQgc2VsZWN0KzB4NjYKc3lzY2FsbChlOTIxZGQzOCkgYXQg c3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIw Ci0tLSBzeXNjYWxsICg5MywgRnJlZUJTRCBFTEYzMiwgc2VsZWN0KSwgZWlwID0gMHgyODE5MGMz MywgZXNwID0gMHhiZmJmZGU3YywgZWJwID0gMHhiZmJmZWUyOCAtLS0KClRyYWNpbmcgY29tbWFu ZCBkZXZkIHBpZCA3OTkgdGlkIDEwMDIwNSB0ZCAweGM5NjFkYWYwCnNjaGVkX3N3aXRjaChjOTYx ZGFmMCwwLDEwNCwxOTEsOTkxMjU0YywuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0 Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3 aXRjaChjOTYxZGFmMCwwLGMwYzlmMzZmLDFhMCwwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1 ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscyhjMDg3ZmNlYSxjOTE4MTc5MCwwLGMwYzk5N2U1LGM5NjFk YWYwLC4uLikgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoYzkx ODE3YTQsMCxlOTE1OGE3YywxMDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0X3NpZysweDE3Ci0tTW9y ZS0tICAgICAgICBfY3Zfd2FpdF9zaWcoYzkxODE3YTQsYzkxODE3OTAsYzBjYTE1NmQsNjAzLGM5 M2VjNzcwLC4uLikgYXQgX2N2X3dhaXRfc2lnKzB4MjQwCnNlbHRkd2FpdChjOTNlYzc3MCw1OCxj ODU3NTI4MCxjOTYxZGFmMCwwLC4uLikgYXQgc2VsdGR3YWl0KzB4YTIKa2Vybl9zZWxlY3QoYzk2 MWRhZjAsNixiZmJmZTliMCwwLDAsMCwyMCw4MDk3ZmJmLDEpIGF0IGtlcm5fc2VsZWN0KzB4NGY0 CnNlbGVjdChjOTYxZGFmMCxlOTE1OGNmOCwxNCxjOTYxZGFmMCxjMGQ4NzdjYywuLi4pIGF0IHNl bGVjdCsweDY2CnN5c2NhbGwoZTkxNThkMzgpIGF0IHN5c2NhbGwrMHgyYTMKWGludDB4ODBfc3lz Y2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgyMAotLS0gc3lzY2FsbCAoOTMsIEZyZWVCU0Qg RUxGMzIsIHNlbGVjdCksIGVpcCA9IDB4ODA4OGI2MywgZXNwID0gMHhiZmJmZTk3YywgZWJwID0g MHhiZmJmZWU1OCAtLS0KClRyYWNpbmcgY29tbWFuZCBzY2hlZGNwdSBwaWQgMjAgdGlkIDEwMDA3 NSB0ZCAweGM4ZDBmNDYwCnNjaGVkX3N3aXRjaChjOGQwZjQ2MCwwLDEwNCwxOTEsZmRkMWI2MTAs Li4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiww LC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzhkMGY0NjAsMCxjMGM5ZjM2 ZiwyODMsMiwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3RpbWVkd2FpdChjMGRm ODUyNCwwLGMwYzkwODFhLDIsMCwuLi4pIGF0IHNsZWVwcV90aW1lZHdhaXQrMHg2Ygpfc2xlZXAo YzBkZjg1MjQsMCwwLGMwYzkwODFhLDNlOCwuLi4pIGF0IF9zbGVlcCsweDMzOQpwYXVzZShjMGM5 MDgxYSwzZTgsMjFiLDIxOSxmYzdjLC4uLikgYXQgcGF1c2UrMHg0NwpzY2hlZGNwdV90aHJlYWQo MCxlOGYzM2QzOCxjMGM5NjQ2YSwzNDMsYzkwOGEyYTgsLi4uKSBhdCBzY2hlZGNwdV90aHJlYWQr MHgyNGMKZm9ya19leGl0KGMwOGIzOWYwLDAsZThmMzNkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0g MCwgZXNwID0gMHhlOGYzM2Q3MCwgZWJwID0gMCAtLS0KCi0tTW9yZS0tICAgICAgICBUcmFjaW5n IGNvbW1hbmQgZmxvd2NsZWFuZXIgcGlkIDE5IHRpZCAxMDAwNzQgdGQgMHhjOGQwZjY5MApzY2hl ZF9zd2l0Y2goYzhkMGY2OTAsMCwxMDQsMTkxLDc2NzBlOTZiLC4uLikgYXQgc2NoZWRfc3dpdGNo KzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsw eDIwMApzbGVlcHFfc3dpdGNoKGM4ZDBmNjkwLDAsYzBjOWYzNmYsMjgzLGM4ZDBmNjkwLC4uLikg YXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfdGltZWR3YWl0KGMwZjVjMTQ4LDAsZTZkNDRj YzQsMSwwLC4uLikgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDZiCl9jdl90aW1lZHdhaXQoYzBmNWMx NDgsYzBmNWMxNTAsMjcxMCwzZjAsMCwuLi4pIGF0IF9jdl90aW1lZHdhaXQrMHgyNTAKZmxvd3Rh YmxlX2NsZWFuZXIoMCxlNmQ0NGQzOCxjMGM5NjQ2YSwzNDMsYzkwOGE1NTAsLi4uKSBhdCBmbG93 dGFibGVfY2xlYW5lcisweDFiZgpmb3JrX2V4aXQoYzA5MzkzYjAsMCxlNmQ0NGQzOCkgYXQgZm9y a19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0g dHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGU2ZDQ0ZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBj b21tYW5kIHNvZnRkZXBmbHVzaCBwaWQgMTggdGlkIDEwMDA3MyB0ZCAweGM4ZDBmOGMwCnNjaGVk X3N3aXRjaChjOGQwZjhjMCwwLDEwNCwxOTEsZjVmMTBlZTUsLi4uKSBhdCBzY2hlZF9zd2l0Y2gr MHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiw0NCwuLi4pIGF0IG1pX3N3aXRjaCsw eDIwMApzbGVlcHFfc3dpdGNoKGM4ZDBmOGMwLDAsYzBjOWYzNmYsMjgzLDAsLi4uKSBhdCBzbGVl cHFfc3dpdGNoKzB4MTVmCnNsZWVwcV90aW1lZHdhaXQoYzBmNjc4YTAsNDQsYzBjYzIyNzMsMCww LC4uLikgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDZiCl9zbGVlcChjMGY2NzhhMCxjMGY2Nzg0NCw0 NCxjMGNjMjI3MywzZTgsLi4uKSBhdCBfc2xlZXArMHgzMzkKc29mdGRlcF9mbHVzaCgwLGU2ZDQx ZDM4LGMwYzk2NDZhLDM0MyxjOTA4YTdmOCwuLi4pIGF0IHNvZnRkZXBfZmx1c2grMHgyNDQKZm9y a19leGl0KGMwYWM4YjUwLDAsZTZkNDFkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBv bGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS1Nb3JlLS0gICAgICAgIC0tLSB0cmFwIDAs IGVpcCA9IDAsIGVzcCA9IDB4ZTZkNDFkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQg c3luY2VyIHBpZCAxNyB0aWQgMTAwMDcyIHRkIDB4YzhkMGZhZjAKc2NoZWRfc3dpdGNoKGM4ZDBm YWYwLDAsMTA0LDE5MSxkYTg3NjdjMCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0 Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3 aXRjaChjOGQwZmFmMCwwLGMwYzlmMzZmLDI4MyxjOGQwZmFmMCwuLi4pIGF0IHNsZWVwcV9zd2l0 Y2grMHgxNWYKc2xlZXBxX3RpbWVkd2FpdChjMGY1YmY1NCwwLGU2ZDNlYzg4LDEsMCwuLi4pIGF0 IHNsZWVwcV90aW1lZHdhaXQrMHg2YgpfY3ZfdGltZWR3YWl0KGMwZjViZjU0LGMwZjViZjQwLDNl OCw2ZDQsNGUyMCwuLi4pIGF0IF9jdl90aW1lZHdhaXQrMHgyNTAKc2NoZWRfc3luYygwLGU2ZDNl ZDM4LGMwYzk2NDZhLDM0MyxjOTA4YWFhMCwuLi4pIGF0IHNjaGVkX3N5bmMrMHg1MDIKZm9ya19l eGl0KGMwOTI0MDcwLDAsZTZkM2VkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGlu ZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhl NmQzZWQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCB2bmxydSBwaWQgMTYgdGlkIDEw MDA3MSB0ZCAweGM4ZDBmZDIwCnNjaGVkX3N3aXRjaChjOGQwZmQyMCwwLDEwNCwxOTEsYjUzYTQ4 MjUsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFl Yiw1MCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4ZDBmZDIwLDAsYzBj OWYzNmYsMjgzLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV90aW1lZHdhaXQo YzkwOGFkNDgsNTAsYzBjYTkyYmUsMCwwLC4uLikgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDZiCl9z bGVlcChjOTA4YWQ0OCxjMGY1YmYxNCwyNTAsYzBjYTkyYmUsM2U4LC4uLikgYXQgX3NsZWVwKzB4 MzM5CnZubHJ1X3Byb2MoMCxlNmQzYmQzOCxjMGM5NjQ2YSwzNDMsYzkwOGFkNDgsLi4uKSBhdCB2 bmxydV9wcm9jKzB4ZTcKLS1Nb3JlLS0gICAgICAgIGZvcmtfZXhpdChjMDkyNGMyMCwwLGU2ZDNi ZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZkM2JkNzAsIGVicCA9IDAgLS0t CgpUcmFjaW5nIGNvbW1hbmQgYnVmZGFlbW9uIHBpZCAxNSB0aWQgMTAwMDcwIHRkIDB4YzhkMTEw MDAKc2NoZWRfc3dpdGNoKGM4ZDExMDAwLDAsMTA0LDE5MSxhNjQ0ZjJhNiwuLi4pIGF0IHNjaGVk X3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDQ0LC4uLikgYXQgbWlf c3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzhkMTEwMDAsMCxjMGM5ZjM2ZiwyODMsMCwuLi4p IGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3RpbWVkd2FpdChjMGY1YmM4OCw0NCxjMGNh NmExOCwwLDAsLi4uKSBhdCBzbGVlcHFfdGltZWR3YWl0KzB4NmIKX3NsZWVwKGMwZjViYzg4LGMw ZjViYzhjLDQ0LGMwY2E2YTE4LDNlOCwuLi4pIGF0IF9zbGVlcCsweDMzOQpidWZfZGFlbW9uKDAs ZTZkMzhkMzgsYzBjOTY0NmEsMzQzLGM4NTk5MmE4LC4uLikgYXQgYnVmX2RhZW1vbisweDEzOApm b3JrX2V4aXQoYzA5MGNiYjAsMCxlNmQzOGQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3Ag PSAweGU2ZDM4ZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIHBhZ2V6ZXJvIHBpZCA5 IHRpZCAxMDAwNjkgdGQgMHhjOGQxMTIzMApzY2hlZF9zd2l0Y2goYzhkMTEyMzAsMCwxMDQsMTkx LDVlMGRlZGEzLC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5 ZjM2ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4ZDExMjMw LDAsYzBjOWYzNmYsMjgzLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV90aW1l ZHdhaXQoYzBmNjhhMTQsMCxjMGNjODJlNywwLDAsLi4uKSBhdCBzbGVlcHFfdGltZWR3YWl0KzB4 NmIKLS1Nb3JlLS0gICAgICAgIF9zbGVlcChjMGY2OGExNCxjMGY2ODUwMCwwLGMwY2M4MmU3LDQ5 M2UwLC4uLikgYXQgX3NsZWVwKzB4MzM5CnZtX3BhZ2V6ZXJvKDAsZTZkMzVkMzgsYzBjOTY0NmEs MzQzLGM4NTk5NTUwLC4uLikgYXQgdm1fcGFnZXplcm8rMHhkYwpmb3JrX2V4aXQoYzBiMDcwNTAs MCxlNmQzNWQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGU2ZDM1ZDcwLCBlYnAg PSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIHZtZGFlbW9uIHBpZCA4IHRpZCAxMDAwNjggdGQgMHhj OGQxMTQ2MApzY2hlZF9zd2l0Y2goYzhkMTE0NjAsMCwxMDQsMTkxLGZjNTE0NDRmLC4uLikgYXQg c2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsNjgsLi4uKSBh dCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjOGQxMTQ2MCwwLGMwYzlmMzZmLDI2MCww LC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfd2FpdChjMGY2ODY0NCw2OCxjMGNh NmExOCwwLDAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDYzCl9zbGVlcChjMGY2ODY0NCxjMGY2ODY0 OCw2OCxjMGNhNmExOCwwLC4uLikgYXQgX3NsZWVwKzB4MzZiCnZtX2RhZW1vbigwLGU2ZDMyZDM4 LGMwYzk2NDZhLDM0MyxjODU5OTdmOCwuLi4pIGF0IHZtX2RhZW1vbisweDU5CmZvcmtfZXhpdChj MGIwMTRmMCwwLGU2ZDMyZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBh dCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZkMzJk NzAsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgcGFnZWRhZW1vbiBwaWQgNyB0aWQgMTAw MDY3IHRkIDB4YzhkMTE2OTAKc2NoZWRfc3dpdGNoKGM4ZDExNjkwLDAsMTA0LDE5MSwzM2NjZWZh NCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWVi LDQ0LC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCi0tTW9yZS0tICAgICAgICBzbGVlcHFfc3dpdGNo KGM4ZDExNjkwLDAsYzBjOWYzNmYsMjgzLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNs ZWVwcV90aW1lZHdhaXQoYzBmNjg2MGMsNDQsYzBjYTZhMTgsMCwwLC4uLikgYXQgc2xlZXBxX3Rp bWVkd2FpdCsweDZiCl9zbGVlcChjMGY2ODYwYyxjMGY2ODUwMCw0NCxjMGNhNmExOCwxMzg4LC4u LikgYXQgX3NsZWVwKzB4MzM5CnZtX3BhZ2VvdXQoMCxlNmQyZmQzOCxjMGM5NjQ2YSwzNDMsYzg1 OTlhYTAsLi4uKSBhdCB2bV9wYWdlb3V0KzB4MmJiCmZvcmtfZXhpdChjMGIwMjM5MCwwLGU2ZDJm ZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZkMmZkNzAsIGVicCA9IDAgLS0t CgpUcmFjaW5nIGNvbW1hbmQgZmRjMCBwaWQgNiB0aWQgMTAwMDY1IHRkIDB4YzhkMTFhZjAKc2No ZWRfc3dpdGNoKGM4ZDExYWYwLDAsMTA0LDE5MSxkNDA3YTRmNywuLi4pIGF0IHNjaGVkX3N3aXRj aCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDRjLC4uLikgYXQgbWlfc3dpdGNo KzB4MjAwCnNsZWVwcV9zd2l0Y2goYzhkMTFhZjAsMCxjMGM5ZjM2ZiwyODMsMCwuLi4pIGF0IHNs ZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3RpbWVkd2FpdChjOGMxZTIzYyw0YyxjMGM5MDgxYSww LDAsLi4uKSBhdCBzbGVlcHFfdGltZWR3YWl0KzB4NmIKX3NsZWVwKGM4YzFlMjNjLGM4YzFlMmYw LDRjLGMwYzkwODFhLDNlOCwuLi4pIGF0IF9zbGVlcCsweDMzOQpmZGNfdGhyZWFkKGM4YzFlMjAw LGU2ZDI5ZDM4LGMwYzk2NDZhLDM0MyxjODU5OWQ0OCwuLi4pIGF0IGZkY190aHJlYWQrMHgyN2QK Zm9ya19leGl0KGMwYjg0NjUwLGM4YzFlMjAwLGU2ZDI5ZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApm b3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9 IDAsIGVzcCA9IDB4ZTZkMjlkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgdXNiIHBp ZCAxNCB0aWQgMTAwMDYyIHRkIDB4YzhiMjc0NjAKLS1Nb3JlLS0gICAgICAgIHNjaGVkX3N3aXRj aChjOGIyNzQ2MCwwLDEwNCwxOTEsYjlmYjQzYzksLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUK bWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNs ZWVwcV9zd2l0Y2goYzhiMjc0NjAsMCxjMGM5ZjM2ZiwyNjAsYzhiMjc0NjAsLi4uKSBhdCBzbGVl cHFfc3dpdGNoKzB4MTVmCnNsZWVwcV93YWl0KGM4YmIxZDBjLDAsZTZhZjVjYmMsMSwwLC4uLikg YXQgc2xlZXBxX3dhaXQrMHg2MwpfY3Zfd2FpdChjOGJiMWQwYyxjOGJiMWRhYyxjMGM4OTI3Yiw2 YyxjOGJiMWQxNCwuLi4pIGF0IF9jdl93YWl0KzB4MjQwCnVzYl9wcm9jZXNzKGM4YmIxZDA0LGU2 YWY1ZDM4LGMwYzk2NDZhLDM0MyxjODlhODAwMCwuLi4pIGF0IHVzYl9wcm9jZXNzKzB4MTkzCmZv cmtfZXhpdChjMDdjMWUwMCxjOGJiMWQwNCxlNmFmNWQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAw LCBlc3AgPSAweGU2YWY1ZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIHVzYiBwaWQg MTQgdGlkIDEwMDA2MSB0ZCAweGM4YjI3NjkwCnNjaGVkX3N3aXRjaChjOGIyNzY5MCwwLDEwNCwx OTEsMjk2MzhkMzIsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMw YzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzhiMjc2 OTAsMCxjMGM5ZjM2ZiwyNjAsYzhiMjc2OTAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNs ZWVwcV93YWl0KGM4YmIxY2RjLDAsZTZhZjJjYmMsMSwwLC4uLikgYXQgc2xlZXBxX3dhaXQrMHg2 MwpfY3Zfd2FpdChjOGJiMWNkYyxjOGJiMWRhYyxjMGM4OTI3Yiw2YyxjOGJiMWNlNCwuLi4pIGF0 IF9jdl93YWl0KzB4MjQwCnVzYl9wcm9jZXNzKGM4YmIxY2Q0LGU2YWYyZDM4LGMwYzk2NDZhLDM0 MyxjODlhODAwMCwuLi4pIGF0IHVzYl9wcm9jZXNzKzB4MTkzCmZvcmtfZXhpdChjMDdjMWUwMCxj OGJiMWNkNCxlNmFmMmQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQg Zm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGU2YWYyZDcw LCBlYnAgPSAwIC0tLQotLU1vcmUtLSAgICAgICAgClRyYWNpbmcgY29tbWFuZCB1c2IgcGlkIDE0 IHRpZCAxMDAwNjAgdGQgMHhjOGIyNzhjMApzY2hlZF9zd2l0Y2goYzhiMjc4YzAsMCwxMDQsMTkx LGIyZWI4YTI0LC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5 ZjM2ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4YjI3OGMw LDAsYzBjOWYzNmYsMjYwLGM4YjI3OGMwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVl cHFfd2FpdChjOGJiMWNhYywwLGU2YWVmY2JjLDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NjMK X2N2X3dhaXQoYzhiYjFjYWMsYzhiYjFkYWMsYzBjODkyN2IsNmMsYzhiYjFjYjQsLi4uKSBhdCBf Y3Zfd2FpdCsweDI0MAp1c2JfcHJvY2VzcyhjOGJiMWNhNCxlNmFlZmQzOCxjMGM5NjQ2YSwzNDMs Yzg5YTgwMDAsLi4uKSBhdCB1c2JfcHJvY2VzcysweDE5Mwpmb3JrX2V4aXQoYzA3YzFlMDAsYzhi YjFjYTQsZTZhZWZkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhlNmFlZmQ3MCwg ZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCB1c2IgcGlkIDE0IHRpZCAxMDAwNTkgdGQgMHhj OGIyN2FmMApzY2hlZF9zd2l0Y2goYzhiMjdhZjAsMCwxMDQsMTkxLGIyZWI3NTc4LC4uLikgYXQg c2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0 IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4YjI3YWYwLDAsYzBjOWYzNmYsMjYwLGM4 YjI3YWYwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfd2FpdChjOGJiMWM3Yyww LGU2YWVjY2JjLDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NjMKX2N2X3dhaXQoYzhiYjFjN2Ms YzhiYjFkYWMsYzBjODkyN2IsNmMsYzhiYjFjODQsLi4uKSBhdCBfY3Zfd2FpdCsweDI0MAp1c2Jf cHJvY2VzcyhjOGJiMWM3NCxlNmFlY2QzOCxjMGM5NjQ2YSwzNDMsYzg5YTgwMDAsLi4uKSBhdCB1 c2JfcHJvY2VzcysweDE5Mwpmb3JrX2V4aXQoYzA3YzFlMDAsYzhiYjFjNzQsZTZhZWNkMzgpIGF0 IGZvcmtfZXhpdCsweGI4Ci0tTW9yZS0tICAgICAgICBmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZhZWNkNzAsIGVi cCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgdXNiIHBpZCAxNCB0aWQgMTAwMDU4IHRkIDB4Yzhi MjdkMjAKc2NoZWRfc3dpdGNoKGM4YjI3ZDIwLDAsMTA0LDE5MSxiMmViNWVlZiwuLi4pIGF0IHNj aGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBt aV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjOGIyN2QyMCwwLGMwYzlmMzZmLDI2MCxjOGIy N2QyMCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3dhaXQoYzhiODlkYWMsMCxl NmFlN2NiYywxLDAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDYzCl9jdl93YWl0KGM4Yjg5ZGFjLGM4 Yjg5ZTRjLGMwYzg5MjdiLDZjLGM4Yjg5ZGI0LC4uLikgYXQgX2N2X3dhaXQrMHgyNDAKdXNiX3By b2Nlc3MoYzhiODlkYTQsZTZhZTdkMzgsYzBjOTY0NmEsMzQzLGM4OWE4MDAwLC4uLikgYXQgdXNi X3Byb2Nlc3MrMHgxOTMKZm9ya19leGl0KGMwN2MxZTAwLGM4Yjg5ZGE0LGU2YWU3ZDM4KSBhdCBm b3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0t LSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZhZTdkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5n IGNvbW1hbmQgdXNiIHBpZCAxNCB0aWQgMTAwMDU3IHRkIDB4YzhiODMwMDAKc2NoZWRfc3dpdGNo KGM4YjgzMDAwLDAsMTA0LDE5MSxmZDc5MWMyNSwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQpt aV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xl ZXBxX3N3aXRjaChjOGI4MzAwMCwwLGMwYzlmMzZmLDI2MCxjOGI4MzAwMCwuLi4pIGF0IHNsZWVw cV9zd2l0Y2grMHgxNWYKc2xlZXBxX3dhaXQoYzhiODlkN2MsMCxlNmFlNGNiYywxLDAsLi4uKSBh dCBzbGVlcHFfd2FpdCsweDYzCl9jdl93YWl0KGM4Yjg5ZDdjLGM4Yjg5ZTRjLGMwYzg5MjdiLDZj LGM4Yjg5ZDg0LC4uLikgYXQgX2N2X3dhaXQrMHgyNDAKLS1Nb3JlLS0gICAgICAgIHVzYl9wcm9j ZXNzKGM4Yjg5ZDc0LGU2YWU0ZDM4LGMwYzk2NDZhLDM0MyxjODlhODAwMCwuLi4pIGF0IHVzYl9w cm9jZXNzKzB4MTkzCmZvcmtfZXhpdChjMDdjMWUwMCxjOGI4OWQ3NCxlNmFlNGQzOCkgYXQgZm9y a19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0g dHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGU2YWU0ZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBj b21tYW5kIHVzYiBwaWQgMTQgdGlkIDEwMDA1NiB0ZCAweGM4YjgzMjMwCnNjaGVkX3N3aXRjaChj OGI4MzIzMCwwLDEwNCwxOTEsYWMwYmMzYzIsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlf c3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVw cV9zd2l0Y2goYzhiODMyMzAsMCxjMGM5ZjM2ZiwyNjAsYzhiODMyMzAsLi4uKSBhdCBzbGVlcHFf c3dpdGNoKzB4MTVmCnNsZWVwcV93YWl0KGM4Yjg5ZDRjLDAsZTZhZTFjYmMsMSwwLC4uLikgYXQg c2xlZXBxX3dhaXQrMHg2MwpfY3Zfd2FpdChjOGI4OWQ0YyxjOGI4OWU0YyxjMGM4OTI3Yiw2Yyxj OGI4OWQ1NCwuLi4pIGF0IF9jdl93YWl0KzB4MjQwCnVzYl9wcm9jZXNzKGM4Yjg5ZDQ0LGU2YWUx ZDM4LGMwYzk2NDZhLDM0MyxjODlhODAwMCwuLi4pIGF0IHVzYl9wcm9jZXNzKzB4MTkzCmZvcmtf ZXhpdChjMDdjMWUwMCxjOGI4OWQ0NCxlNmFlMWQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBl c3AgPSAweGU2YWUxZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIHVzYiBwaWQgMTQg dGlkIDEwMDA1NSB0ZCAweGM4YjgzNDYwCnNjaGVkX3N3aXRjaChjOGI4MzQ2MCwwLDEwNCwxOTEs YWMwYmIyYzcsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlm MzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzhiODM0NjAs MCxjMGM5ZjM2ZiwyNjAsYzhiODM0NjAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCi0tTW9y ZS0tICAgICAgICBzbGVlcHFfd2FpdChjOGI4OWQxYywwLGU2YWRlY2JjLDEsMCwuLi4pIGF0IHNs ZWVwcV93YWl0KzB4NjMKX2N2X3dhaXQoYzhiODlkMWMsYzhiODllNGMsYzBjODkyN2IsNmMsYzhi ODlkMjQsLi4uKSBhdCBfY3Zfd2FpdCsweDI0MAp1c2JfcHJvY2VzcyhjOGI4OWQxNCxlNmFkZWQz OCxjMGM5NjQ2YSwzNDMsYzg5YTgwMDAsLi4uKSBhdCB1c2JfcHJvY2VzcysweDE5Mwpmb3JrX2V4 aXQoYzA3YzFlMDAsYzhiODlkMTQsZTZhZGVkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNw ID0gMHhlNmFkZWQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCB1c2IgcGlkIDE0IHRp ZCAxMDAwNTMgdGQgMHhjOGI4MzhjMApzY2hlZF9zd2l0Y2goYzhiODM4YzAsMCwxMDQsMTkxLGFj MGI5YTEwLC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2 ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4YjgzOGMwLDAs YzBjOWYzNmYsMjYwLGM4YjgzOGMwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFf d2FpdChjOGI2N2RhYywwLGU2YWQ3Y2JjLDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NjMKX2N2 X3dhaXQoYzhiNjdkYWMsYzhiNjdlNGMsYzBjODkyN2IsNmMsYzhiNjdkYjQsLi4uKSBhdCBfY3Zf d2FpdCsweDI0MAp1c2JfcHJvY2VzcyhjOGI2N2RhNCxlNmFkN2QzOCxjMGM5NjQ2YSwzNDMsYzg5 YTgwMDAsLi4uKSBhdCB1c2JfcHJvY2VzcysweDE5Mwpmb3JrX2V4aXQoYzA3YzFlMDAsYzhiNjdk YTQsZTZhZDdkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtf dHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhlNmFkN2Q3MCwgZWJw ID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCB1c2IgcGlkIDE0IHRpZCAxMDAwNTIgdGQgMHhjOGI4 M2FmMApzY2hlZF9zd2l0Y2goYzhiODNhZjAsMCwxMDQsMTkxLGZkNzg1YmUwLC4uLikgYXQgc2No ZWRfc3dpdGNoKzB4MWM1Ci0tTW9yZS0tICAgICAgICBtaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYs MWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjOGI4M2FmMCwwLGMw YzlmMzZmLDI2MCxjOGI4M2FmMCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3dh aXQoYzhiNjdkN2MsMCxlNmFkNGNiYywxLDAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDYzCl9jdl93 YWl0KGM4YjY3ZDdjLGM4YjY3ZTRjLGMwYzg5MjdiLDZjLGM4YjY3ZDg0LC4uLikgYXQgX2N2X3dh aXQrMHgyNDAKdXNiX3Byb2Nlc3MoYzhiNjdkNzQsZTZhZDRkMzgsYzBjOTY0NmEsMzQzLGM4OWE4 MDAwLC4uLikgYXQgdXNiX3Byb2Nlc3MrMHgxOTMKZm9ya19leGl0KGMwN2MxZTAwLGM4YjY3ZDc0 LGU2YWQ0ZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZhZDRkNzAsIGVicCA9 IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgdXNiIHBpZCAxNCB0aWQgMTAwMDUxIHRkIDB4YzhiODNk MjAKc2NoZWRfc3dpdGNoKGM4YjgzZDIwLDAsMTA0LDE5MSxhNTJiMTI0OSwuLi4pIGF0IHNjaGVk X3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9z d2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjOGI4M2QyMCwwLGMwYzlmMzZmLDI2MCxjOGI4M2Qy MCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3dhaXQoYzhiNjdkNGMsMCxlNmFk MWNiYywxLDAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDYzCl9jdl93YWl0KGM4YjY3ZDRjLGM4YjY3 ZTRjLGMwYzg5MjdiLDZjLGM4YjY3ZDU0LC4uLikgYXQgX2N2X3dhaXQrMHgyNDAKdXNiX3Byb2Nl c3MoYzhiNjdkNDQsZTZhZDFkMzgsYzBjOTY0NmEsMzQzLGM4OWE4MDAwLC4uLikgYXQgdXNiX3By b2Nlc3MrMHgxOTMKZm9ya19leGl0KGMwN2MxZTAwLGM4YjY3ZDQ0LGU2YWQxZDM4KSBhdCBmb3Jr X2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0 cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZhZDFkNzAsIGVicCA9IDAgLS0tCgotLU1vcmUtLSAg ICAgICAgVHJhY2luZyBjb21tYW5kIHVzYiBwaWQgMTQgdGlkIDEwMDA1MCB0ZCAweGM4OWFmNjkw CnNjaGVkX3N3aXRjaChjODlhZjY5MCwwLDEwNCwxOTEsYTUyYjAwNDksLi4uKSBhdCBzY2hlZF9z d2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dp dGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzg5YWY2OTAsMCxjMGM5ZjM2ZiwyNjAsYzg5YWY2OTAs Li4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV93YWl0KGM4YjY3ZDFjLDAsZTZhY2Vj YmMsMSwwLC4uLikgYXQgc2xlZXBxX3dhaXQrMHg2MwpfY3Zfd2FpdChjOGI2N2QxYyxjOGI2N2U0 YyxjMGM4OTI3Yiw2YyxjOGI2N2QyNCwuLi4pIGF0IF9jdl93YWl0KzB4MjQwCnVzYl9wcm9jZXNz KGM4YjY3ZDE0LGU2YWNlZDM4LGMwYzk2NDZhLDM0MyxjODlhODAwMCwuLi4pIGF0IHVzYl9wcm9j ZXNzKzB4MTkzCmZvcmtfZXhpdChjMDdjMWUwMCxjOGI2N2QxNCxlNmFjZWQzOCkgYXQgZm9ya19l eGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJh cCAwLCBlaXAgPSAwLCBlc3AgPSAweGU2YWNlZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21t YW5kIHVzYiBwaWQgMTQgdGlkIDEwMDA0OCB0ZCAweGM4OWFmYWYwCnNjaGVkX3N3aXRjaChjODlh ZmFmMCwwLDEwNCwxOTEsYTUyYWU4MjIsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dp dGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9z d2l0Y2goYzg5YWZhZjAsMCxjMGM5ZjM2ZiwyNjAsYzg5YWZhZjAsLi4uKSBhdCBzbGVlcHFfc3dp dGNoKzB4MTVmCnNsZWVwcV93YWl0KGM4YjNmZGFjLDAsZTZhYzhjYmMsMSwwLC4uLikgYXQgc2xl ZXBxX3dhaXQrMHg2MwpfY3Zfd2FpdChjOGIzZmRhYyxjOGIzZmU0YyxjMGM4OTI3Yiw2YyxjOGIz ZmRiNCwuLi4pIGF0IF9jdl93YWl0KzB4MjQwCnVzYl9wcm9jZXNzKGM4YjNmZGE0LGU2YWM4ZDM4 LGMwYzk2NDZhLDM0MyxjODlhODAwMCwuLi4pIGF0IHVzYl9wcm9jZXNzKzB4MTkzCmZvcmtfZXhp dChjMDdjMWUwMCxjOGIzZmRhNCxlNmFjOGQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLU1vcmUtLSAgICAgICAgLS0tIHRyYXAg MCwgZWlwID0gMCwgZXNwID0gMHhlNmFjOGQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFu ZCB1c2IgcGlkIDE0IHRpZCAxMDAwNDcgdGQgMHhjODlhZmQyMApzY2hlZF9zd2l0Y2goYzg5YWZk MjAsMCwxMDQsMTkxLGZkNzdhMzk2LC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRj aCgxMDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dp dGNoKGM4OWFmZDIwLDAsYzBjOWYzNmYsMjYwLGM4OWFmZDIwLC4uLikgYXQgc2xlZXBxX3N3aXRj aCsweDE1ZgpzbGVlcHFfd2FpdChjOGIzZmQ3YywwLGU2YWM1Y2JjLDEsMCwuLi4pIGF0IHNsZWVw cV93YWl0KzB4NjMKX2N2X3dhaXQoYzhiM2ZkN2MsYzhiM2ZlNGMsYzBjODkyN2IsNmMsYzhiM2Zk ODQsLi4uKSBhdCBfY3Zfd2FpdCsweDI0MAp1c2JfcHJvY2VzcyhjOGIzZmQ3NCxlNmFjNWQzOCxj MGM5NjQ2YSwzNDMsYzg5YTgwMDAsLi4uKSBhdCB1c2JfcHJvY2VzcysweDE5Mwpmb3JrX2V4aXQo YzA3YzFlMDAsYzhiM2ZkNzQsZTZhYzVkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBv bGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0g MHhlNmFjNWQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCB1c2IgcGlkIDE0IHRpZCAx MDAwNDYgdGQgMHhjOGIyNjAwMApzY2hlZF9zd2l0Y2goYzhiMjYwMDAsMCwxMDQsMTkxLDllNGFi ZWFlLC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2Ziwx ZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4YjI2MDAwLDAsYzBj OWYzNmYsMjYwLGM4YjI2MDAwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfd2Fp dChjOGIzZmQ0YywwLGU2YWMyY2JjLDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NjMKX2N2X3dh aXQoYzhiM2ZkNGMsYzhiM2ZlNGMsYzBjODkyN2IsNmMsYzhiM2ZkNTQsLi4uKSBhdCBfY3Zfd2Fp dCsweDI0MAp1c2JfcHJvY2VzcyhjOGIzZmQ0NCxlNmFjMmQzOCxjMGM5NjQ2YSwzNDMsYzg5YTgw MDAsLi4uKSBhdCB1c2JfcHJvY2VzcysweDE5MwotLU1vcmUtLSAgICAgICAgZm9ya19leGl0KGMw N2MxZTAwLGM4YjNmZDQ0LGU2YWMyZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4 ZTZhYzJkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgdXNiIHBpZCAxNCB0aWQgMTAw MDQ1IHRkIDB4YzhiMjYyMzAKc2NoZWRfc3dpdGNoKGM4YjI2MjMwLDAsMTA0LDE5MSw5ZTRhYWM5 MywuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWVi LDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjOGIyNjIzMCwwLGMwYzlm MzZmLDI2MCxjOGIyNjIzMCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3dhaXQo YzhiM2ZkMWMsMCxlNmFiZmNiYywxLDAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDYzCl9jdl93YWl0 KGM4YjNmZDFjLGM4YjNmZTRjLGMwYzg5MjdiLDZjLGM4YjNmZDI0LC4uLikgYXQgX2N2X3dhaXQr MHgyNDAKdXNiX3Byb2Nlc3MoYzhiM2ZkMTQsZTZhYmZkMzgsYzBjOTY0NmEsMzQzLGM4OWE4MDAw LC4uLikgYXQgdXNiX3Byb2Nlc3MrMHgxOTMKZm9ya19leGl0KGMwN2MxZTAwLGM4YjNmZDE0LGU2 YWJmZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1w b2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZhYmZkNzAsIGVicCA9IDAg LS0tCgpUcmFjaW5nIGNvbW1hbmQgdXNiIHBpZCAxNCB0aWQgMTAwMDQzIHRkIDB4YzhiMjY2OTAK c2NoZWRfc3dpdGNoKGM4YjI2NjkwLDAsMTA0LDE5MSw5ZTRhOTI2MiwuLi4pIGF0IHNjaGVkX3N3 aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0 Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjOGIyNjY5MCwwLGMwYzlmMzZmLDI2MCxjOGIyNjY5MCwu Li4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3dhaXQoYzhiMDJkYWMsMCxlNmFiOWNi YywxLDAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDYzCi0tTW9yZS0tICAgICAgICBfY3Zfd2FpdChj OGIwMmRhYyxjOGIwMmU0YyxjMGM4OTI3Yiw2YyxjOGIwMmRiNCwuLi4pIGF0IF9jdl93YWl0KzB4 MjQwCnVzYl9wcm9jZXNzKGM4YjAyZGE0LGU2YWI5ZDM4LGMwYzk2NDZhLDM0MyxjODlhODAwMCwu Li4pIGF0IHVzYl9wcm9jZXNzKzB4MTkzCmZvcmtfZXhpdChjMDdjMWUwMCxjOGIwMmRhNCxlNmFi OWQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGU2YWI5ZDcwLCBlYnAgPSAwIC0t LQoKVHJhY2luZyBjb21tYW5kIHVzYiBwaWQgMTQgdGlkIDEwMDA0MiB0ZCAweGM4YjI2OGMwCnNj aGVkX3N3aXRjaChjOGIyNjhjMCwwLDEwNCwxOTEsZmQ3NmM2N2QsLi4uKSBhdCBzY2hlZF9zd2l0 Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNo KzB4MjAwCnNsZWVwcV9zd2l0Y2goYzhiMjY4YzAsMCxjMGM5ZjM2ZiwyNjAsYzhiMjY4YzAsLi4u KSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV93YWl0KGM4YjAyZDdjLDAsZTZhYjZjYmMs MSwwLC4uLikgYXQgc2xlZXBxX3dhaXQrMHg2MwpfY3Zfd2FpdChjOGIwMmQ3YyxjOGIwMmU0Yyxj MGM4OTI3Yiw2YyxjOGIwMmQ4NCwuLi4pIGF0IF9jdl93YWl0KzB4MjQwCnVzYl9wcm9jZXNzKGM4 YjAyZDc0LGU2YWI2ZDM4LGMwYzk2NDZhLDM0MyxjODlhODAwMCwuLi4pIGF0IHVzYl9wcm9jZXNz KzB4MTkzCmZvcmtfZXhpdChjMDdjMWUwMCxjOGIwMmQ3NCxlNmFiNmQzOCkgYXQgZm9ya19leGl0 KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAw LCBlaXAgPSAwLCBlc3AgPSAweGU2YWI2ZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5k IHVzYiBwaWQgMTQgdGlkIDEwMDA0MSB0ZCAweGM4YjI2YWYwCnNjaGVkX3N3aXRjaChjOGIyNmFm MCwwLDEwNCwxOTEsOTc2YTJlZGEsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNo KDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCi0tTW9yZS0tICAg ICAgICBzbGVlcHFfc3dpdGNoKGM4YjI2YWYwLDAsYzBjOWYzNmYsMjYwLGM4YjI2YWYwLC4uLikg YXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfd2FpdChjOGIwMmQ0YywwLGU2YWIzY2JjLDEs MCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NjMKX2N2X3dhaXQoYzhiMDJkNGMsYzhiMDJlNGMsYzBj ODkyN2IsNmMsYzhiMDJkNTQsLi4uKSBhdCBfY3Zfd2FpdCsweDI0MAp1c2JfcHJvY2VzcyhjOGIw MmQ0NCxlNmFiM2QzOCxjMGM5NjQ2YSwzNDMsYzg5YTgwMDAsLi4uKSBhdCB1c2JfcHJvY2Vzcysw eDE5Mwpmb3JrX2V4aXQoYzA3YzFlMDAsYzhiMDJkNDQsZTZhYjNkMzgpIGF0IGZvcmtfZXhpdCsw eGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwg ZWlwID0gMCwgZXNwID0gMHhlNmFiM2Q3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCB1 c2IgcGlkIDE0IHRpZCAxMDAwNDAgdGQgMHhjOGIyNmQyMApzY2hlZF9zd2l0Y2goYzhiMjZkMjAs MCwxMDQsMTkxLDk3NmExOTQ0LC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgx MDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNo KGM4YjI2ZDIwLDAsYzBjOWYzNmYsMjYwLGM4YjI2ZDIwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsw eDE1ZgpzbGVlcHFfd2FpdChjOGIwMmQxYywwLGU2YWIwY2JjLDEsMCwuLi4pIGF0IHNsZWVwcV93 YWl0KzB4NjMKX2N2X3dhaXQoYzhiMDJkMWMsYzhiMDJlNGMsYzBjODkyN2IsNmMsYzhiMDJkMjQs Li4uKSBhdCBfY3Zfd2FpdCsweDI0MAp1c2JfcHJvY2VzcyhjOGIwMmQxNCxlNmFiMGQzOCxjMGM5 NjQ2YSwzNDMsYzg5YTgwMDAsLi4uKSBhdCB1c2JfcHJvY2VzcysweDE5Mwpmb3JrX2V4aXQoYzA3 YzFlMDAsYzhiMDJkMTQsZTZhYjBkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGlu ZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhl NmFiMGQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCB4cHRfdGhyZCBwaWQgNSB0aWQg MTAwMDM0IHRkIDB4Yzg5YWQ2OTAKLS1Nb3JlLS0gICAgICAgIHNjaGVkX3N3aXRjaChjODlhZDY5 MCwwLDEwNCwxOTEsOTc2OWZjYTYsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNo KDEwNCwwLGMwYzlmMzZmLDFlYiw0YywuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dp dGNoKGM4OWFkNjkwLDAsYzBjOWYzNmYsMjYwLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVm CnNsZWVwcV93YWl0KGMwZGM0OGQ0LDRjLGMwYzM0NjE5LDAsMCwuLi4pIGF0IHNsZWVwcV93YWl0 KzB4NjMKX3NsZWVwKGMwZGM0OGQ0LGMwZGM0OGVjLDRjLGMwYzM0NjE5LDAsLi4uKSBhdCBfc2xl ZXArMHgzNmIKeHB0X3NjYW5uZXJfdGhyZWFkKDAsYzYzODNkMzgsYzBjOTY0NmEsMzQzLGM4OWE4 MmE4LC4uLikgYXQgeHB0X3NjYW5uZXJfdGhyZWFkKzB4NGEKZm9ya19leGl0KGMwNDg0NzEwLDAs YzYzODNkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhjNjM4M2Q3MCwgZWJwID0g MCAtLS0KClRyYWNpbmcgY29tbWFuZCB5YXJyb3cgcGlkIDEzIHRpZCAxMDAwMjUgdGQgMHhjODVh NmFmMApzY2hlZF9zd2l0Y2goYzg1YTZhZjAsMCwxMDQsMTkxLDQ2NWJjYmM3LC4uLikgYXQgc2No ZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0IG1p X3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4NWE2YWYwLDAsYzBjOWYzNmYsMjgzLDIsLi4u KSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV90aW1lZHdhaXQoYzBkZjg1MjQsMCxjMGM5 MDgxYSwyLDAsLi4uKSBhdCBzbGVlcHFfdGltZWR3YWl0KzB4NmIKX3NsZWVwKGMwZGY4NTI0LDAs MCxjMGM5MDgxYSw2NCwuLi4pIGF0IF9zbGVlcCsweDMzOQpwYXVzZShjMGM5MDgxYSw2NCxjMGM3 Y2NmZCwxMTEsMCwuLi4pIGF0IHBhdXNlKzB4NDcKcmFuZG9tX2t0aHJlYWQoMCxjNjM2OGQzOCxj MGM5NjQ2YSwzNDMsYzg5YTg1NTAsLi4uKSBhdCByYW5kb21fa3RocmVhZCsweDFlZgpmb3JrX2V4 aXQoYzA3Mzg4NTAsMCxjNjM2OGQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLU1vcmUtLSAgICAgICAgLS0tIHRyYXAgMCwgZWlw ID0gMCwgZXNwID0gMHhjNjM2OGQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBnX2Rv d24gcGlkIDQgdGlkIDEwMDAyMyB0ZCAweGM4NzM4MDAwCnNjaGVkX3N3aXRjaChjODczODAwMCww LDEwNCwxOTEsMjg0OGY2MDUsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEw NCwwLGMwYzlmMzZmLDFlYiw0YywuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNo KGM4NzM4MDAwLDAsYzBjOWYzNmYsMjYwLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNs ZWVwcV93YWl0KGMwZGY2MmU0LDRjLGMwYzkwODFhLDAsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4 NjMKX3NsZWVwKGMwZGY2MmU0LGMwZGY2MjQ4LDI0YyxjMGM5MDgxYSwwLC4uLikgYXQgX3NsZWVw KzB4MzZiCmdfaW9fc2NoZWR1bGVfZG93bihjODczODAwMCwwLGMwYzkxZTYyLDc0LDAsLi4uKSBh dCBnX2lvX3NjaGVkdWxlX2Rvd24rMHg1NgpnX2Rvd25fcHJvY2JvZHkoMCxjNjM1ZWQzOCxjMGM5 NjQ2YSwzNDMsYzg1OTcwMDAsLi4uKSBhdCBnX2Rvd25fcHJvY2JvZHkrMHg4ZApmb3JrX2V4aXQo YzA4MmRlMDAsMCxjNjM1ZWQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGM2MzVl ZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGdfdXAgcGlkIDMgdGlkIDEwMDAyMiB0 ZCAweGM4NzM4MjMwCnNjaGVkX3N3aXRjaChjODczODIzMCwwLDEwNCwxOTEsMjg0YjM2MzIsLi4u KSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiw0Yywu Li4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4NzM4MjMwLDAsYzBjOWYzNmYs MjYwLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV93YWl0KGMwZGY2MmUwLDRj LGMwYzkwODFhLDAsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NjMKX3NsZWVwKGMwZGY2MmUwLGMw ZGY2MjY4LDI0YyxjMGM5MDgxYSwwLC4uLikgYXQgX3NsZWVwKzB4MzZiCi0tTW9yZS0tICAgICAg ICBnX2lvX3NjaGVkdWxlX3VwKGM4NzM4MjMwLDAsYzBjOTFlNjIsNWQsMCwuLi4pIGF0IGdfaW9f c2NoZWR1bGVfdXArMHgxMWUKZ191cF9wcm9jYm9keSgwLGM2MzViZDM4LGMwYzk2NDZhLDM0Myxj ODU5NzJhOCwuLi4pIGF0IGdfdXBfcHJvY2JvZHkrMHg4ZApmb3JrX2V4aXQoYzA4MmRlOTAsMCxj NjM1YmQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGM2MzViZDcwLCBlYnAgPSAw IC0tLQoKVHJhY2luZyBjb21tYW5kIGdfZXZlbnQgcGlkIDIgdGlkIDEwMDAyMSB0ZCAweGM4NzM4 NDYwCnNjaGVkX3N3aXRjaChjODczODQ2MCwwLDEwNCwxOTEsNDNkYzNjNTcsLi4uKSBhdCBzY2hl ZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiw0YywuLi4pIGF0IG1p X3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4NzM4NDYwLDAsYzBjOWYzNmYsMjgzLDAsLi4u KSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV90aW1lZHdhaXQoYzBkZjYyZDgsNGMsYzBj OTA4MWEsMCwwLC4uLikgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDZiCl9zbGVlcChjMGRmNjJkOCww LDRjLGMwYzkwODFhLDY0LC4uLikgYXQgX3NsZWVwKzB4MzM5CmdfZXZlbnRfcHJvY2JvZHkoMCxj NjM1OGQzOCxjMGM5NjQ2YSwzNDMsYzg1OTc1NTAsLi4uKSBhdCBnX2V2ZW50X3Byb2Nib2R5KzB4 Y2IKZm9ya19leGl0KGMwODJkZjIwLDAsYzYzNThkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwg ZXNwID0gMHhjNjM1OGQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBpbnRyIHBpZCAx MiB0aWQgMTAwMDY2IHRkIDB4YzhkMTE4YzAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgotLU1vcmUtLSAgICAgICAgVHJhY2luZyBjb21tYW5kIGludHIgcGlkIDEyIHRpZCAx MDAwNjQgdGQgMHhjOGQxMWQyMApzY2hlZF9zd2l0Y2goYzhkMTFkMjAsMCwxMDksMTkxLDQ4OWNk OWI1LC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDksMCxjMGM5NjcwNyw1 MmQsYzhjYzY2ZjAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKaXRocmVhZF9sb29wKGM4ZDBhOTgw LGU2ZDFjZDM4LGMwYzk2NDZhLDM0MyxjODU5NzdmOCwuLi4pIGF0IGl0aHJlYWRfbG9vcCsweDFm Ngpmb3JrX2V4aXQoYzA4Njg5MDAsYzhkMGE5ODAsZTZkMWNkMzgpIGF0IGZvcmtfZXhpdCsweGI4 CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlw ID0gMCwgZXNwID0gMHhlNmQxY2Q3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBpbnRy IHBpZCAxMiB0aWQgMTAwMDYzIHRkIDB4YzhiMjcyMzAKc2NoZWRfc3dpdGNoKGM4YjI3MjMwLDAs MTA5LDE5MSxmMWMzNjA4MSwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA5 LDAsYzBjOTY3MDcsNTJkLGM4NWU1YWYwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCml0aHJlYWRf bG9vcChjOGNjYmI4MCxlNmQwNmQzOCxjMGM5NjQ2YSwzNDMsYzg1OTc3ZjgsLi4uKSBhdCBpdGhy ZWFkX2xvb3ArMHgxZjYKZm9ya19leGl0KGMwODY4OTAwLGM4Y2NiYjgwLGU2ZDA2ZDM4KSBhdCBm b3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0t LSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZkMDZkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5n IGNvbW1hbmQgaW50ciBwaWQgMTIgdGlkIDEwMDA1NCB0ZCAweGM4YjgzNjkwCmZvcmtfdHJhbXBv bGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIGludHIgcGlkIDEyIHRp ZCAxMDAwNDkgdGQgMHhjODlhZjhjMAotLU1vcmUtLSAgICAgICAgc2NoZWRfc3dpdGNoKGM4OWFm OGMwLDAsMTA5LDE5MSw5MTBlOWY0MSwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0 Y2goMTA5LDAsYzBjOTY3MDcsNTJkLGM4NWU1MmYwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCml0 aHJlYWRfbG9vcChjOGI3ZWU4MCxlNmFjYmQzOCxjMGM5NjQ2YSwzNDMsYzg1OTc3ZjgsLi4uKSBh dCBpdGhyZWFkX2xvb3ArMHgxZjYKZm9ya19leGl0KGMwODY4OTAwLGM4YjdlZTgwLGU2YWNiZDM4 KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUr MHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4ZTZhY2JkNzAsIGVicCA9IDAgLS0tCgpU cmFjaW5nIGNvbW1hbmQgaW50ciBwaWQgMTIgdGlkIDEwMDA0NCB0ZCAweGM4YjI2NDYwCnNjaGVk X3N3aXRjaChjOGIyNjQ2MCwwLDEwOSwxOTEsOGZlOWYzNzAsLi4uKSBhdCBzY2hlZF9zd2l0Y2gr MHgxYzUKbWlfc3dpdGNoKDEwOSwwLGMwYzk2NzA3LDUyZCxjODVlNTBmMCwuLi4pIGF0IG1pX3N3 aXRjaCsweDIwMAppdGhyZWFkX2xvb3AoYzhiNTJiODAsZTZhYmNkMzgsYzBjOTY0NmEsMzQzLGM4 NTk3N2Y4LC4uLikgYXQgaXRocmVhZF9sb29wKzB4MWY2CmZvcmtfZXhpdChjMDg2ODkwMCxjOGI1 MmI4MCxlNmFiY2QzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGU2YWJjZDcwLCBl YnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGludHIgcGlkIDEyIHRpZCAxMDAwMzkgdGQgMHhj OGIyNzAwMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCBpbnRyIHBpZCAxMiB0aWQgMTAwMDM2IHRkIDB4Yzg5YWQyMzAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCi0tTW9yZS0tICAgICAgICAKVHJhY2luZyBjb21tYW5kIGlu dHIgcGlkIDEyIHRpZCAxMDAwMzUgdGQgMHhjODlhZDQ2MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCBpbnRyIHBpZCAxMiB0aWQgMTAwMDMzIHRk IDB4Yzg5YWQ4YzAKc2NoZWRfc3dpdGNoKGM4OWFkOGMwLDAsMTA5LDE5MSxlYzJiZjgsLi4uKSBh dCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwOSwwLGMwYzk2NzA3LDUyZCxjODlhOWFm MCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMAppdGhyZWFkX2xvb3AoYzg5OWYzODAsYzYzODBkMzgs YzBjOTY0NmEsMzQzLGM4NTk3N2Y4LC4uLikgYXQgaXRocmVhZF9sb29wKzB4MWY2CmZvcmtfZXhp dChjMDg2ODkwMCxjODk5ZjM4MCxjNjM4MGQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3Ag PSAweGM2MzgwZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGludHIgcGlkIDEyIHRp ZCAxMDAwMzIgdGQgMHhjODlhZGFmMApzY2hlZF9zd2l0Y2goYzg5YWRhZjAsMCwxMDksMTkxLGYx MjBiNzBhLC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDksMCxjMGM5Njcw Nyw1MmQsYzg5YTljZjAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKaXRocmVhZF9sb29wKGM4OTlm NjgwLGM2MzdkZDM4LGMwYzk2NDZhLDM0MyxjODU5NzdmOCwuLi4pIGF0IGl0aHJlYWRfbG9vcCsw eDFmNgpmb3JrX2V4aXQoYzA4Njg5MDAsYzg5OWY2ODAsYzYzN2RkMzgpIGF0IGZvcmtfZXhpdCsw eGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwg ZWlwID0gMCwgZXNwID0gMHhjNjM3ZGQ3MCwgZWJwID0gMCAtLS0KCi0tTW9yZS0tICAgICAgICBU cmFjaW5nIGNvbW1hbmQgaW50ciBwaWQgMTIgdGlkIDEwMDAzMCB0ZCAweGM4OWFmMDAwCnNjaGVk X3N3aXRjaChjODlhZjAwMCwwLDEwOSwxOTEsZmIyNzExNzQsLi4uKSBhdCBzY2hlZF9zd2l0Y2gr MHgxYzUKbWlfc3dpdGNoKDEwOSwwLGMwYzk2NzA3LDUyZCxjODlhOWVmMCwuLi4pIGF0IG1pX3N3 aXRjaCsweDIwMAppdGhyZWFkX2xvb3AoYzg5OWZiODAsYzYzNzdkMzgsYzBjOTY0NmEsMzQzLGM4 NTk3N2Y4LC4uLikgYXQgaXRocmVhZF9sb29wKzB4MWY2CmZvcmtfZXhpdChjMDg2ODkwMCxjODk5 ZmI4MCxjNjM3N2QzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGM2Mzc3ZDcwLCBl YnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGludHIgcGlkIDEyIHRpZCAxMDAwMjAgdGQgMHhj ODczODY5MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29t bWFuZCBpbnRyIHBpZCAxMiB0aWQgMTAwMDE5IHRkIDB4Yzg3Mzg4YzAKc2NoZWRfc3dpdGNoKGM4 NzM4OGMwLDAsMTA5LDE5MSxmYzllNThiNywuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9z d2l0Y2goMTA5LDAsYzBjOTY3MDcsNTJkLGM4NWVjNmYwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAw Cml0aHJlYWRfbG9vcChjODU4ZmI4MCxjNjM1MmQzOCxjMGM5NjQ2YSwzNDMsYzg1OTc3ZjgsLi4u KSBhdCBpdGhyZWFkX2xvb3ArMHgxZjYKZm9ya19leGl0KGMwODY4OTAwLGM4NThmYjgwLGM2MzUy ZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xp bmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4YzYzNTJkNzAsIGVicCA9IDAgLS0t CgpUcmFjaW5nIGNvbW1hbmQgaW50ciBwaWQgMTIgdGlkIDEwMDAxOCB0ZCAweGM4NzM4YWYwCi0t TW9yZS0tICAgICAgICBzY2hlZF9zd2l0Y2goYzg3MzhhZjAsMCwxMDksMTkxLDEzMDQ1MmRhLC4u LikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDksMCxjMGM5NjcwNyw1MmQsYzg1 ZWM4ZjAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKaXRocmVhZF9sb29wKGM4NTkwYzgwLGM2MzRm ZDM4LGMwYzk2NDZhLDM0MyxjODU5NzdmOCwuLi4pIGF0IGl0aHJlYWRfbG9vcCsweDFmNgpmb3Jr X2V4aXQoYzA4Njg5MDAsYzg1OTBjODAsYzYzNGZkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtf dHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwg ZXNwID0gMHhjNjM0ZmQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBpbnRyIHBpZCAx MiB0aWQgMTAwMDE3IHRkIDB4Yzg1OWMyMzAKc2NoZWRfc3dpdGNoKGM4NTljMjMwLDAsMTA5LDE5 MSxlNWI5OTU2LC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDksMCxjMGM5 NjcwNyw1MmQsYzg1ZWNhZjAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKaXRocmVhZF9sb29wKGM4 NTkwZTgwLGM2MzRjZDM4LGMwYzk2NDZhLDM0MyxjODU5NzdmOCwuLi4pIGF0IGl0aHJlYWRfbG9v cCsweDFmNgpmb3JrX2V4aXQoYzA4Njg5MDAsYzg1OTBlODAsYzYzNGNkMzgpIGF0IGZvcmtfZXhp dCsweGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAg MCwgZWlwID0gMCwgZXNwID0gMHhjNjM0Y2Q3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFu ZCBpbnRyIHBpZCAxMiB0aWQgMTAwMDE2IHRkIDB4Yzg1OWM0NjAKc2NoZWRfc3dpdGNoKGM4NTlj NDYwLDAsMTA5LDE5MSwxMjU2MjFmZiwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0 Y2goMTA5LDAsYzBjOTY3MDcsNTJkLGM4NWVjY2YwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCml0 aHJlYWRfbG9vcChjODU5MTE4MCxjNjM0OWQzOCxjMGM5NjQ2YSwzNDMsYzg1OTc3ZjgsLi4uKSBh dCBpdGhyZWFkX2xvb3ArMHgxZjYKZm9ya19leGl0KGMwODY4OTAwLGM4NTkxMTgwLGM2MzQ5ZDM4 KSBhdCBmb3JrX2V4aXQrMHhiOAotLU1vcmUtLSAgICAgICAgZm9ya190cmFtcG9saW5lKCkgYXQg Zm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGM2MzQ5ZDcw LCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGludHIgcGlkIDEyIHRpZCAxMDAwMTUgdGQg MHhjODU5YzY5MApzY2hlZF9zd2l0Y2goYzg1OWM2OTAsMCwxMDksMTkxLDM4ZTU1YzQwLC4uLikg YXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDksMCxjMGM5NjcwNyw1MmQsYzg1ZWNl ZjAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKaXRocmVhZF9sb29wKGM4NTkxMzgwLGM2MzQ2ZDM4 LGMwYzk2NDZhLDM0MyxjODU5NzdmOCwuLi4pIGF0IGl0aHJlYWRfbG9vcCsweDFmNgpmb3JrX2V4 aXQoYzA4Njg5MDAsYzg1OTEzODAsYzYzNDZkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNw ID0gMHhjNjM0NmQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBpbnRyIHBpZCAxMiB0 aWQgMTAwMDE0IHRkIDB4Yzg1OWM4YzAKc2NoZWRfc3dpdGNoKGM4NTljOGMwLDAsMTA5LDE5MSw0 NjViNDRkOSwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA5LDAsYzBjOTY3 MDcsNTJkLGM4NWVkMGYwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCml0aHJlYWRfbG9vcChjODU5 MTU4MCxjNjM0M2QzOCxjMGM5NjQ2YSwzNDMsYzg1OTc3ZjgsLi4uKSBhdCBpdGhyZWFkX2xvb3Ar MHgxZjYKZm9ya19leGl0KGMwODY4OTAwLGM4NTkxNTgwLGM2MzQzZDM4KSBhdCBmb3JrX2V4aXQr MHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAs IGVpcCA9IDAsIGVzcCA9IDB4YzYzNDNkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQg aW50ciBwaWQgMTIgdGlkIDEwMDAxMyB0ZCAweGM4NTljYWYwCi0tTW9yZS0tICAgICAgICBzY2hl ZF9zd2l0Y2goYzg1OWNhZjAsMCwxMDksMTkxLDEzYzg1YWE0LC4uLikgYXQgc2NoZWRfc3dpdGNo KzB4MWM1Cm1pX3N3aXRjaCgxMDksMCxjMGM5NjcwNyw1MmQsYzg1ZWQyZjAsLi4uKSBhdCBtaV9z d2l0Y2grMHgyMDAKaXRocmVhZF9sb29wKGM4NTkxNzgwLGM2MzQwZDM4LGMwYzk2NDZhLDM0Myxj ODU5NzdmOCwuLi4pIGF0IGl0aHJlYWRfbG9vcCsweDFmNgpmb3JrX2V4aXQoYzA4Njg5MDAsYzg1 OTE3ODAsYzYzNDBkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhjNjM0MGQ3MCwg ZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBpbnRyIHBpZCAxMiB0aWQgMTAwMDEyIHRkIDB4 Yzg1OWNkMjAKc2NoZWRfc3dpdGNoKGM4NTljZDIwLDAsMTA5LDE5MSw0OGRlMzg1ZCwuLi4pIGF0 IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA5LDAsYzBjOTY3MDcsNTJkLGM4NWVkNGYw LC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCml0aHJlYWRfbG9vcChjODU5MTk4MCxjNjMzZGQzOCxj MGM5NjQ2YSwzNDMsYzg1OTc3ZjgsLi4uKSBhdCBpdGhyZWFkX2xvb3ArMHgxZjYKZm9ya19leGl0 KGMwODY4OTAwLGM4NTkxOTgwLGM2MzNkZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9 IDB4YzYzM2RkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgaW50ciBwaWQgMTIgdGlk IDEwMDAxMSB0ZCAweGM4NWE2MDAwCnNjaGVkX3N3aXRjaChjODVhNjAwMCwwLDEwOSwxOTEsMTI5 YzYxMmIsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwOSwwLGMwYzk2NzA3 LDUyZCxjODVlN2VmMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMAppdGhyZWFkX2xvb3AoYzg1OTFi ODAsYzYzM2FkMzgsYzBjOTY0NmEsMzQzLGM4NTk3N2Y4LC4uLikgYXQgaXRocmVhZF9sb29wKzB4 MWY2CmZvcmtfZXhpdChjMDg2ODkwMCxjODU5MWI4MCxjNjMzYWQzOCkgYXQgZm9ya19leGl0KzB4 YjgKLS1Nb3JlLS0gICAgICAgIGZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsw eDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhjNjMzYWQ3MCwgZWJwID0gMCAtLS0KClRy YWNpbmcgY29tbWFuZCBpZGxlIHBpZCAxMSB0aWQgMTAwMDEwIHRkIDB4Yzg1YTYyMzAKc2NoZWRf c3dpdGNoKGM4NWE2MjMwLDAsMTA4LDE4Yyw0NmExOTJiNCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsw eDFjNQptaV9zd2l0Y2goMTA4LDAsYzBjOWNkNWEsNjBjLGM2MzM1ZDI0LC4uLikgYXQgbWlfc3dp dGNoKzB4MjAwCnNjaGVkX2lkbGV0ZCgwLGM2MzM1ZDM4LGMwYzk2NDZhLDM0MyxjODU5N2FhMCwu Li4pIGF0IHNjaGVkX2lkbGV0ZCsweDgxCmZvcmtfZXhpdChjMDhiMmVkMCwwLGM2MzM1ZDM4KSBh dCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4 Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4YzYzMzVkNzAsIGVicCA9IDAgLS0tCgpUcmFj aW5nIGNvbW1hbmQgaWRsZSBwaWQgMTEgdGlkIDEwMDAwOSB0ZCAweGM4NWE2NDYwCnNjaGVkX3N3 aXRjaChjODVhNjQ2MCwwLDEwOCwxOGMsNDZhMWQzNjQsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgx YzUKbWlfc3dpdGNoKDEwOCwwLGMwYzljZDVhLDYwYyxjNjMzMmQyNCwuLi4pIGF0IG1pX3N3aXRj aCsweDIwMApzY2hlZF9pZGxldGQoMCxjNjMzMmQzOCxjMGM5NjQ2YSwzNDMsYzg1OTdhYTAsLi4u KSBhdCBzY2hlZF9pZGxldGQrMHg4MQpmb3JrX2V4aXQoYzA4YjJlZDAsMCxjNjMzMmQzOCkgYXQg Zm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAot LS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGM2MzMyZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2lu ZyBjb21tYW5kIGlkbGUgcGlkIDExIHRpZCAxMDAwMDggdGQgMHhjODU5YTAwMAotLU1vcmUtLSAg ICAgICAgc2NoZWRfc3dpdGNoKGM4NTlhMDAwLDAsMTA4LDE4YyxjYTMzMmQzOCwuLi4pIGF0IHNj aGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA4LDAsYzBjOWNkNWEsNjBjLGM2MzJmZDI0LC4u LikgYXQgbWlfc3dpdGNoKzB4MjAwCnNjaGVkX2lkbGV0ZCgwLGM2MzJmZDM4LGMwYzk2NDZhLDM0 MyxjODU5N2FhMCwuLi4pIGF0IHNjaGVkX2lkbGV0ZCsweDgxCmZvcmtfZXhpdChjMDhiMmVkMCww LGM2MzJmZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4YzYzMmZkNzAsIGVicCA9 IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgaWRsZSBwaWQgMTEgdGlkIDEwMDAwNyB0ZCAweGM4NTlh MjMwCnNjaGVkX3N3aXRjaChjODU5YTIzMCwwLDEwOCwxOGMsNDZhMTRmMTksLi4uKSBhdCBzY2hl ZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwOCwwLGMwYzljZDVhLDYwYyxjNjMyY2QyNCwuLi4p IGF0IG1pX3N3aXRjaCsweDIwMApzY2hlZF9pZGxldGQoMCxjNjMyY2QzOCxjMGM5NjQ2YSwzNDMs Yzg1OTdhYTAsLi4uKSBhdCBzY2hlZF9pZGxldGQrMHg4MQpmb3JrX2V4aXQoYzA4YjJlZDAsMCxj NjMyY2QzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGM2MzJjZDcwLCBlYnAgPSAw IC0tLQoKVHJhY2luZyBjb21tYW5kIGlkbGUgcGlkIDExIHRpZCAxMDAwMDYgdGQgMHhjODU5YTQ2 MApzY2hlZF9zd2l0Y2goYzg1OWE0NjAsMCwxMDgsMThjLDQ2YTIxODFmLC4uLikgYXQgc2NoZWRf c3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDgsMCxjMGM5Y2Q1YSw2MGMsYzYzMjlkMjQsLi4uKSBh dCBtaV9zd2l0Y2grMHgyMDAKc2NoZWRfaWRsZXRkKDAsYzYzMjlkMzgsYzBjOTY0NmEsMzQzLGM4 NTk3YWEwLC4uLikgYXQgc2NoZWRfaWRsZXRkKzB4ODEKZm9ya19leGl0KGMwOGIyZWQwLDAsYzYz MjlkMzgpIGF0IGZvcmtfZXhpdCsweGI4Ci0tTW9yZS0tICAgICAgICBmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4YzYz MjlkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgaWRsZSBwaWQgMTEgdGlkIDEwMDAw NSB0ZCAweGM4NTlhNjkwCnNjaGVkX3N3aXRjaChjODU5YTY5MCwwLDEwOCwxOGMsNDZhMjY1MGIs Li4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwOCwwLGMwYzljZDVhLDYwYyxj NjMyNmQyNCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzY2hlZF9pZGxldGQoMCxjNjMyNmQzOCxj MGM5NjQ2YSwzNDMsYzg1OTdhYTAsLi4uKSBhdCBzY2hlZF9pZGxldGQrMHg4MQpmb3JrX2V4aXQo YzA4YjJlZDAsMCxjNjMyNmQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGM2MzI2 ZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGlkbGUgcGlkIDExIHRpZCAxMDAwMDQg dGQgMHhjODU5YThjMApzY2hlZF9zd2l0Y2goYzg1OWE4YzAsMCwxMDgsMThjLDQ2YTJkNzU2LC4u LikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDgsMCxjMGM5Y2Q1YSw2MGMsYzYz MjNkMjQsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2NoZWRfaWRsZXRkKDAsYzYzMjNkMzgsYzBj OTY0NmEsMzQzLGM4NTk3YWEwLC4uLikgYXQgc2NoZWRfaWRsZXRkKzB4ODEKZm9ya19leGl0KGMw OGIyZWQwLDAsYzYzMjNkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhjNjMyM2Q3 MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBpZGxlIHBpZCAxMSB0aWQgMTAwMDAzIHRk IDB4Yzg1OWFhZjAKLS1Nb3JlLS0gICAgICAgIHNjaGVkX3N3aXRjaChjODU5YWFmMCwwLDEwOCwx OGMsNDZhMmFhOWUsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwOCwwLGMw YzljZDVhLDYwYyxjNjMyMGQyNCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzY2hlZF9pZGxldGQo MCxjNjMyMGQzOCxjMGM5NjQ2YSwzNDMsYzg1OTdhYTAsLi4uKSBhdCBzY2hlZF9pZGxldGQrMHg4 MQpmb3JrX2V4aXQoYzA4YjJlZDAsMCxjNjMyMGQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBl c3AgPSAweGM2MzIwZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGluaXQgcGlkIDEg dGlkIDEwMDAwMiB0ZCAweGM4NTlhZDIwCnNjaGVkX3N3aXRjaChjODU5YWQyMCwwLDEwNCwxOTEs MTAxYzA1NzksLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlm MzZmLDFlYiw1YywuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4NTlhZDIw LDAsYzBjOWYzNmYsMWEwLDVjLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfY2F0 Y2hfc2lnbmFscyhjMGM5ZjM2ZiwxNjAsMCwxMDAsMTAwLC4uLikgYXQgc2xlZXBxX2NhdGNoX3Np Z25hbHMrMHhiNwpzbGVlcHFfd2FpdF9zaWcoYzg1OTdkNDgsNWMsYzBjYTFiNjAsMTAwLDAsLi4u KSBhdCBzbGVlcHFfd2FpdF9zaWcrMHgxNwpfc2xlZXAoYzg1OTdkNDgsYzg1OTdkZDAsMTVjLGMw Y2ExYjYwLDAsLi4uKSBhdCBfc2xlZXArMHgzNTQKa2Vybl93YWl0KGM4NTlhZDIwLGZmZmZmZmZm LGM2MzFjYzc0LDAsMCwuLi4pIGF0IGtlcm5fd2FpdCsweGI3Ngp3YWl0NChjODU5YWQyMCxjNjMx Y2NmOCwxMCxjMGNhMTk3MyxjMGQ4NmU2NCwuLi4pIGF0IHdhaXQ0KzB4M2IKc3lzY2FsbChjNjMx Y2QzOCkgYXQgc3lzY2FsbCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lz Y2FsbCsweDIwCi0tLSBzeXNjYWxsICg3LCBGcmVlQlNEIEVMRjMyLCB3YWl0NCksIGVpcCA9IDB4 ODA1NGI4ZiwgZXNwID0gMHhiZmJmZTkwYywgZWJwID0gMHhiZmJmZTkyOCAtLS0KCi0tTW9yZS0t ICAgICAgICBUcmFjaW5nIGNvbW1hbmQgYXVkaXQgcGlkIDEwIHRpZCAxMDAwMDEgdGQgMHhjODU5 YzAwMApzY2hlZF9zd2l0Y2goYzg1OWMwMDAsMCwxMDQsMTkxLDk3Njc2MDAzLC4uLikgYXQgc2No ZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2ZiwxZWIsMCwuLi4pIGF0IG1p X3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4NTljMDAwLDAsYzBjOWYzNmYsMjYwLGM4NTlj MDAwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfd2FpdChjMGY2NzFjMCwwLGM2 MzE5YzljLDEsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NjMKX2N2X3dhaXQoYzBmNjcxYzAsYzBm NjcxYTQsYzBjYmY4YWQsMTk0LDAsLi4uKSBhdCBfY3Zfd2FpdCsweDI0MAphdWRpdF93b3JrZXIo MCxjNjMxOWQzOCxjMGM5NjQ2YSwzNDMsYzg1OTkwMDAsLi4uKSBhdCBhdWRpdF93b3JrZXIrMHg4 NApmb3JrX2V4aXQoYzBhOTgzNjAsMCxjNjMxOWQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBl c3AgPSAweGM2MzE5ZDcwLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGtlcm5lbCBwaWQg MCB0aWQgMTAwMDM4IHRkIDB4Yzg3MzhkMjAKc2NoZWRfc3dpdGNoKGM4NzM4ZDIwLDAsMTA0LDE5 MSw5MTBlNTQwZSwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBj OWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjODczOGQy MCwwLGMwYzlmMzZmLDI2MCxjODczOGQyMCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xl ZXBxX3dhaXQoYzhhYmFkODAsMCxjMGM5YmNmMCxjMGM5MDgxYSwwLC4uLikgYXQgc2xlZXBxX3dh aXQrMHg2Mwptc2xlZXBfc3BpbihjOGFiYWQ4MCxjOGFiYWQ5OCxjMGM5MDgxYSwwLGMwYzk5N2U1 LC4uLikgYXQgbXNsZWVwX3NwaW4rMHgyMWQKdGFza3F1ZXVlX3RocmVhZF9sb29wKGM4YWI0NWEw LGM2M2ZjZDM4LGMwYzk2NDZhLDM0MyxjMGRmNjNjMCwuLi4pIGF0IHRhc2txdWV1ZV90aHJlYWRf bG9vcCsweDk0CmZvcmtfZXhpdChjMDhjY2ZhMCxjOGFiNDVhMCxjNjNmY2QzOCkgYXQgZm9ya19l eGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLU1vcmUt LSAgICAgICAgLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhjNjNmY2Q3MCwgZWJwID0gMCAt LS0KClRyYWNpbmcgY29tbWFuZCBrZXJuZWwgcGlkIDAgdGlkIDEwMDAzNyB0ZCAweGM4OWFkMDAw CnNjaGVkX3N3aXRjaChjODlhZDAwMCwwLDEwNCwxOTEsMTRlNzcyNTQsLi4uKSBhdCBzY2hlZF9z d2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dp dGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzg5YWQwMDAsMCxjMGM5ZjM2ZiwyNjAsYzg5YWQwMDAs Li4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV93YWl0KGM4YTk5OTgwLDAsYzBjOWJj ZjAsYzBjOTA4MWEsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NjMKbXNsZWVwX3NwaW4oYzhhOTk5 ODAsYzhhOTk5OTgsYzBjOTA4MWEsMCxjMGM5OTdlNSwuLi4pIGF0IG1zbGVlcF9zcGluKzB4MjFk CnRhc2txdWV1ZV90aHJlYWRfbG9vcChjOGE5NTVhMCxjNjNmOWQzOCxjMGM5NjQ2YSwzNDMsYzBk ZjYzYzAsLi4uKSBhdCB0YXNrcXVldWVfdGhyZWFkX2xvb3ArMHg5NApmb3JrX2V4aXQoYzA4Y2Nm YTAsYzhhOTU1YTAsYzYzZjlkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhjNjNm OWQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBrZXJuZWwgcGlkIDAgdGlkIDEwMDAz MSB0ZCAweGM4OWFkZDIwCnNjaGVkX3N3aXRjaChjODlhZGQyMCwwLDEwNCwxOTEsZjY2NDg1NGEs Li4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiww LC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzg5YWRkMjAsMCxjMGM5ZjM2 ZiwyNjAsMCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3dhaXQoYzg5OWZhODAs MCxjMGM5MDgxYSwwLDAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDYzCl9zbGVlcChjODk5ZmE4MCxj ODk5ZmE5OCwwLGMwYzkwODFhLDAsLi4uKSBhdCBfc2xlZXArMHgzNmIKdGFza3F1ZXVlX3RocmVh ZF9sb29wKGMwZTAxZTg4LGM2MzdhZDM4LGMwYzk2NDZhLDM0MyxjMGRmNjNjMCwuLi4pIGF0IHRh c2txdWV1ZV90aHJlYWRfbG9vcCsweGJhCi0tTW9yZS0tICAgICAgICBmb3JrX2V4aXQoYzA4Y2Nm YTAsYzBlMDFlODgsYzYzN2FkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhjNjM3 YWQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBrZXJuZWwgcGlkIDAgdGlkIDEwMDAy OSB0ZCAweGM4OWFmMjMwCnNjaGVkX3N3aXRjaChjODlhZjIzMCwwLDEwNCwxOTEsZDI0NTJlN2Us Li4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiww LC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzg5YWYyMzAsMCxjMGM5ZjM2 ZiwyNjAsMCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3dhaXQoYzg5YTAwODAs MCxjMGM5MDgxYSwwLDAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDYzCl9zbGVlcChjODlhMDA4MCxj ODlhMDA5OCwwLGMwYzkwODFhLDAsLi4uKSBhdCBfc2xlZXArMHgzNmIKdGFza3F1ZXVlX3RocmVh ZF9sb29wKGMwZGY2YzM4LGM2Mzc0ZDM4LGMwYzk2NDZhLDM0MyxjMGRmNjNjMCwuLi4pIGF0IHRh c2txdWV1ZV90aHJlYWRfbG9vcCsweGJhCmZvcmtfZXhpdChjMDhjY2ZhMCxjMGRmNmMzOCxjNjM3 NGQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGM2Mzc0ZDcwLCBlYnAgPSAwIC0t LQoKVHJhY2luZyBjb21tYW5kIGtlcm5lbCBwaWQgMCB0aWQgMTAwMDI4IHRkIDB4Yzg5YWY0NjAK c2NoZWRfc3dpdGNoKGM4OWFmNDYwLDAsMTA0LDE5MSxkMjQ1MTgzZCwuLi4pIGF0IHNjaGVkX3N3 aXRjaCsweDFjNQptaV9zd2l0Y2goMTA0LDAsYzBjOWYzNmYsMWViLDAsLi4uKSBhdCBtaV9zd2l0 Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjODlhZjQ2MCwwLGMwYzlmMzZmLDI2MCxjODlhZjQ2MCwu Li4pIGF0IHNsZWVwcV9zd2l0Y2grMHgxNWYKc2xlZXBxX3dhaXQoYzg5YTIwODAsMCxjMGM5YmNm MCxjMGM5MDgxYSwwLC4uLikgYXQgc2xlZXBxX3dhaXQrMHg2MwotLU1vcmUtLSAgICAgICAgbXNs ZWVwX3NwaW4oYzg5YTIwODAsYzg5YTIwOTgsYzBjOTA4MWEsMCxjMGM5OTdlNSwuLi4pIGF0IG1z bGVlcF9zcGluKzB4MjFkCnRhc2txdWV1ZV90aHJlYWRfbG9vcChjMGRjNzcyMCxjNjM3MWQzOCxj MGM5NjQ2YSwzNDMsYzBkZjYzYzAsLi4uKSBhdCB0YXNrcXVldWVfdGhyZWFkX2xvb3ArMHg5NApm b3JrX2V4aXQoYzA4Y2NmYTAsYzBkYzc3MjAsYzYzNzFkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0g MCwgZXNwID0gMHhjNjM3MWQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBrZXJuZWwg cGlkIDAgdGlkIDEwMDAyNyB0ZCAweGM4NWE2NjkwCnNjaGVkX3N3aXRjaChjODVhNjY5MCwwLDEw NCwxOTEsZDI0NTA4MmMsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUKbWlfc3dpdGNoKDEwNCww LGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCnNsZWVwcV9zd2l0Y2goYzg1 YTY2OTAsMCxjMGM5ZjM2ZiwyNjAsYzg1YTY2OTAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVm CnNsZWVwcV93YWl0KGM4OWEyMDgwLDAsYzBjOWJjZjAsYzBjOTA4MWEsMCwuLi4pIGF0IHNsZWVw cV93YWl0KzB4NjMKbXNsZWVwX3NwaW4oYzg5YTIwODAsYzg5YTIwOTgsYzBjOTA4MWEsMCxjMGM5 OTdlNSwuLi4pIGF0IG1zbGVlcF9zcGluKzB4MjFkCnRhc2txdWV1ZV90aHJlYWRfbG9vcChjMGRj NzcyMCxjNjM2ZWQzOCxjMGM5NjQ2YSwzNDMsYzBkZjYzYzAsLi4uKSBhdCB0YXNrcXVldWVfdGhy ZWFkX2xvb3ArMHg5NApmb3JrX2V4aXQoYzA4Y2NmYTAsYzBkYzc3MjAsYzYzNmVkMzgpIGF0IGZv cmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0t IHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhjNjM2ZWQ3MCwgZWJwID0gMCAtLS0KClRyYWNpbmcg Y29tbWFuZCBrZXJuZWwgcGlkIDAgdGlkIDEwMDAyNiB0ZCAweGM4NWE2OGMwCnNjaGVkX3N3aXRj aChjODVhNjhjMCwwLDEwNCwxOTEsZDI0NGYzYWQsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxYzUK bWlfc3dpdGNoKDEwNCwwLGMwYzlmMzZmLDFlYiwwLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAwCi0t TW9yZS0tICAgICAgICBzbGVlcHFfc3dpdGNoKGM4NWE2OGMwLDAsYzBjOWYzNmYsMjYwLGM4NWE2 OGMwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfd2FpdChjODlhMjA4MCwwLGMw YzliY2YwLGMwYzkwODFhLDAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDYzCm1zbGVlcF9zcGluKGM4 OWEyMDgwLGM4OWEyMDk4LGMwYzkwODFhLDAsYzBjOTk3ZTUsLi4uKSBhdCBtc2xlZXBfc3Bpbisw eDIxZAp0YXNrcXVldWVfdGhyZWFkX2xvb3AoYzBkYzc3MjAsYzYzNmJkMzgsYzBjOTY0NmEsMzQz LGMwZGY2M2MwLC4uLikgYXQgdGFza3F1ZXVlX3RocmVhZF9sb29wKzB4OTQKZm9ya19leGl0KGMw OGNjZmEwLGMwZGM3NzIwLGM2MzZiZDM4KSBhdCBmb3JrX2V4aXQrMHhiOApmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDAsIGVpcCA9IDAsIGVzcCA9IDB4 YzYzNmJkNzAsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQga2VybmVsIHBpZCAwIHRpZCAx MDAwMjQgdGQgMHhjODVhNmQyMApzY2hlZF9zd2l0Y2goYzg1YTZkMjAsMCwxMDQsMTkxLDJiMjU5 ZDM1LC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2Ziwx ZWIsMCwuLi4pIGF0IG1pX3N3aXRjaCsweDIwMApzbGVlcHFfc3dpdGNoKGM4NWE2ZDIwLDAsYzBj OWYzNmYsMjYwLDAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4MTVmCnNsZWVwcV93YWl0KGM4NThm MDgwLDAsYzBjOTA4MWEsMCwwLC4uLikgYXQgc2xlZXBxX3dhaXQrMHg2Mwpfc2xlZXAoYzg1OGYw ODAsYzg1OGYwOTgsMCxjMGM5MDgxYSwwLC4uLikgYXQgX3NsZWVwKzB4MzZiCnRhc2txdWV1ZV90 aHJlYWRfbG9vcChjMGUwMDkyMCxjNjM2MWQzOCxjMGM5NjQ2YSwzNDMsYzBkZjYzYzAsLi4uKSBh dCB0YXNrcXVldWVfdGhyZWFkX2xvb3ArMHhiYQpmb3JrX2V4aXQoYzA4Y2NmYTAsYzBlMDA5MjAs YzYzNjFkMzgpIGF0IGZvcmtfZXhpdCsweGI4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZSsweDgKLS0tIHRyYXAgMCwgZWlwID0gMCwgZXNwID0gMHhjNjM2MWQ3MCwgZWJwID0g MCAtLS0KClRyYWNpbmcgY29tbWFuZCBrZXJuZWwgcGlkIDAgdGlkIDEwMDAwMCB0ZCAweGMwZGY2 NjcwCi0tTW9yZS0tICAgICAgICBzY2hlZF9zd2l0Y2goYzBkZjY2NzAsMCwxMDQsMTkxLDY5ZTc4 NzBjLC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MWM1Cm1pX3N3aXRjaCgxMDQsMCxjMGM5ZjM2Ziwx ZWIsNDQsLi4uKSBhdCBtaV9zd2l0Y2grMHgyMDAKc2xlZXBxX3N3aXRjaChjMGRmNjY3MCwwLGMw YzlmMzZmLDI4MywwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDE1ZgpzbGVlcHFfdGltZWR3YWl0 KGMwZGY2M2MwLDQ0LGMwYzlkMGZkLDAsMCwuLi4pIGF0IHNsZWVwcV90aW1lZHdhaXQrMHg2Ygpf c2xlZXAoYzBkZjYzYzAsMCw0NCxjMGM5ZDBmZCwyNzEwLC4uLikgYXQgX3NsZWVwKzB4MzM5CnNj aGVkdWxlcigwLDE0MWVjMDAsMTQxZWMwMCwxNDFlMDAwLDE0MjUwMDAsLi4uKSBhdCBzY2hlZHVs ZXIrMHgyM2UKbWlfc3RhcnR1cCgpIGF0IG1pX3N0YXJ0dXArMHg5NgpiZWdpbigpIGF0IGJlZ2lu KzB4MmMKZGI+Y2FsbCBkb2FkdW1wClBoeXNpY2FsIG1lbW9yeTogMzA1NCBNQgpEdW1waW5nIDE5 MyBNQjogMTc4IDE2MiAxNDYgMTMwIDExNCA5OCA4MiA2NiA1MCAzNCAxOCAyCkR1bXAgY29tcGxl dGUKPSAweGYKZGI+IHNob3cgbXNnYnVmCm1zZ2J1ZnAgPSAweGMxNDg4ZmU0Cm1hZ2ljID0gNjMw NjIsIHNpemUgPSA2NTUwOCwgcj0gNTc1MzE3LCB3ID0gNTc3NTY3LCBwdHIgPSAweGMxNDc5MDAw LCBja3N1bT0gNTA5NjI2NAo8Mz5waWQgNzkxMTMgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1Nzkg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCnBhbmljOiBUaHJlYWQgMHhjOTYzM2FmMCBsb2Nr IDB4YzBkZmMwMjQgZG9lcyBub3QgbWF0Y2ggMHhjOWQzZTI4MApjcHVpZCA9IDEKS0RCOiBzdGFj ayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcihjMGM5ZTFkYyxlOTc4YTg1MCxjMDg4 ZjY3OSxjMGNkNDIyYiwxLC4uLikgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MjYKa2RiX2Jh Y2t0cmFjZShjMGNkNDIyYiwxLGMwYzlmNTQ2LGU5NzhhODVjLDEsLi4uKSBhdCBrZGJfYmFja3Ry YWNlKzB4MjkKcGFuaWMoYzBjOWY1NDYsYzk2MzNhZjAsYzBkZmMwMjQsYzlkM2UyODAsYzBmNWJk M2MsLi4uKSBhdCBwYW5pYysweDExOQp0dXJuc3RpbGVfY2xhaW0oYzlkM2UyODAsMixjMGNhNzM3 NiwxZjAsNCwuLi4pIGF0IHR1cm5zdGlsZV9jbGFpbSsweDE0OApfcndfdHJ5X3VwZ3JhZGUoYzBm NWJkM2MsYzBjYTczNzYsMWYwLGU5NzhhOTkwLGU5NzhhYjg4LC4uLikgYXQgX3J3X3RyeV91cGdy YWRlKzB4ZTYKY2FjaGVfbG9va3VwKGM5OWU5YmIwLGU5NzhhYjc0LGU5NzhhYjg4LDAsMCwuLi4p IGF0IGNhY2hlX2xvb2t1cCsweDM2MgpuZnNfbG9va3VwKGU5NzhhYTUwLGU5NzhhYTUwLGU5Nzhh YjVjLDIwMDAwMCxlOTc4YWI1YywuLi4pIGF0IG5mc19sb29rdXArMHhmNgpWT1BfTE9PS1VQX0FQ VihjMGRhNWZlMCxlOTc4YWE1MCxlOTc4YWI4OCwxZjEsZTk3OGFiNzQsLi4uKSBhdCBWT1BfTE9P S1VQX0FQVisweGE1Cmxvb2t1cChlOTc4YWI1YyxjMGNhN2FlYSxlYSxjNSxjYzA5M2Q0OCwuLi4p IGF0IGxvb2t1cCsweDY2YgpuYW1laShlOTc4YWI1YyxjMDhkM2FhYixjMGM5NGM5NixjMGM5MmRm OSwzLC4uLikgYXQgbmFtZWkrMHg1NWYKa2Vybl9zdGF0YXRfdm5ob29rKGM4YzU5YWYwLDAsZmZm ZmZmOWMsYmZiZmRmNzgsMCwuLi4pIGF0IGtlcm5fc3RhdGF0X3ZuaG9vaysweDcyCmtlcm5fc3Rh dGF0KGM4YzU5YWYwLDAsZmZmZmZmOWMsYmZiZmRmNzgsMCwuLi4pIGF0IGtlcm5fc3RhdGF0KzB4 M2MKa2Vybl9zdGF0KGM4YzU5YWYwLGJmYmZkZjc4LDAsZTk3OGFjMTgsMiwuLi4pIGF0IGtlcm5f c3RhdCsweDM2CnN0YXQoYzhjNTlhZjAsZTk3OGFjZjgsOCxjMGNhMTlmMixjMGQ4ODIzMCwuLi4p IGF0IHN0YXQrMHgyZgotLU1vcmUtLSAgICAgICAgc3lzY2FsbChlOTc4YWQzOCkgYXQgc3lzY2Fs bCsweDJhMwpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIwCi0tLSBz eXNjYWxsICgxODgsIEZyZWVCU0QgRUxGMzIsIHN0YXQpLCBlaXAgPSAweDI4MTdkMWEzLCBlc3Ag PSAweGJmYmZkZWNjLCBlYnAgPSAweGJmYmZlMzg4IC0tLQpLREI6IGVudGVyOiBwYW5pYwpzaGFy ZWQgbG9ja21nciBuZnMgKG5mcykgciA9IDAgKDB4Yzk5ZTlhZjgpIGxvY2tlZCBAIC96b28vZ2lh bm5pL3Rlc3Rib3gvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMDkxCmV4Y2x1c2l2ZSBzbGVlcCBtdXRl eCBwcm9jZXNzIGxvY2sgKHByb2Nlc3MgbG9jaykgciA9IDAgKDB4YzljMTVkZDApIGxvY2tlZCBA IC96b28vZ2lhbm5pL3Rlc3Rib3gvc3lzL2tlcm4va2Vybl90aHIuYzoyMzEKc2hhcmVkIHJ3IE5h bWUgQ2FjaGUgKE5hbWUgQ2FjaGUpIHIgPSAwICgweGMwZjViZDNjKSBsb2NrZWQgQCAvem9vL2dp YW5uaS90ZXN0Ym94L3N5cy9rZXJuL3Zmc19jYWNoZS5jOjM5MApzaGFyZWQgbG9ja21nciBuZnMg KG5mcykgciA9IDAgKDB4Yzk5ZTljMDgpIGxvY2tlZCBAIC96b28vZ2lhbm5pL3Rlc3Rib3gvc3lz L2tlcm4vdmZzX3N1YnIuYzoyMDkxCgoweGM5OWU5YmIwOiB0YWcgbmZzLCB0eXBlIFZESVIKICAg IHVzZWNvdW50IDEsIHdyaXRlY291bnQgMCwgcmVmY291bnQgMiBtb3VudGVkaGVyZSAwCiAgICBm bGFncyAoKQogICAgbG9jayB0eXBlIG5mczogU0hBUkVEIChjb3VudCAxKQogICAgICAgIGZpbGVp ZCAtMzc3OTY5NTYwIGZzaWQgMHhjMGNiYzg5ZAoKMHhjOTllOWFhMDogdGFnIG5mcywgdHlwZSBW RElSCiAgICB1c2Vjb3VudCAxLCB3cml0ZWNvdW50IDAsIHJlZmNvdW50IDIgbW91bnRlZGhlcmUg MAogICAgZmxhZ3MgKCkKICAgIGxvY2sgdHlwZSBuZnM6IFNIQVJFRCAoY291bnQgMSkKICAgICAg ICBmaWxlaWQgLTM3Nzk2OTU2MCBmc2lkIDB4YzBjYmM4OWQKLS1Nb3JlLS0gICAgICAgIFBoeXNp Y2FsIG1lbW9yeTogMzA1NCBNQgpEdW1waW5nIDE5MyBNQjogMTc4IDE2MiAxNDYgMTMwIDExNCA5 OCA4MiA2NiA1MCAzNCAxOCAyCkR1bXAgY29tcGxldGUKIG9uIC9yb290L3RtcDogb3V0IG9mIGlu b2Rlcwo8MTE4PkphbiAxOSAxMjo1MTo0NyBsaW9uMSBrZXJuZWw6IHBpZCA0NjU1MSAoY3JlYXQp LCB1aWQgMCBpbnVtYmVyIDM5OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDQ2 NTQ1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk2IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rl cwo8MTE4PkphbiAxOSAxMjo1MTo0OSBsaW9uMSBrZXJuZWw6IHBpZCA0NjU0NSAoY3JlYXQpLCB1 aWQgMCBpbnVtYmVyIDM5NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkg MTI6NTE6NDkgbGlvbjEga2VybmVsOiBwaWQgNDY1NDUgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAz OTYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA0Nzk4MiAobWtkaXIpLCB1aWQg MCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTI6 NTY6NTUgbGlvbjEga2VybmVsOiBwaWQgNDc5ODIgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA0ODAxMiAobWtkaXIpLCB1aWQgMCBp bnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTI6NTY6 NTcgbGlvbjEga2VybmVsOiBwaWQgNDgwMTIgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA0ODAxOCAocncpLCB1aWQgMCBpbnVtYmVy IDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTI6NTc6MDAgbGlv bjEga2VybmVsOiBwaWQgNDgwMTggKHJ3KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1w OiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA0Nzk5MyAocncpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTI6NTc6MDIgbGlvbjEga2VybmVs OiBwaWQgNDc5OTMgKHJ3KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwzPnBpZCA0ODcyNyAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MDA6NDAgbGlvbjEga2VybmVsOiBwaWQg NDg3MjcgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwzPnBpZCA0ODczMyAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MDA6NDMgbGlvbjEga2VybmVsOiBwaWQgNDg3 MzMgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz Ci0tTW9yZS0tICAgICAgICA8Mz5waWQgNDg3NzUgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTkg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjAwOjQ1IGxpb24xIGtl cm5lbDogcGlkIDQ4Nzc1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk5IG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8Mz5waWQgNDg3NDUgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjAwOjQ4IGxpb24xIGtlcm5l bDogcGlkIDQ4NzQ1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0 IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzowMDo0OCBsaW9uMSBrZXJuZWw6IHBpZCA0ODc0NSAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+ cGlkIDQ4NzQ1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9m IGlub2Rlcwo8Mz5waWQgNDg3NTMgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTEgb24gL3Jvb3Qv dG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjAwOjUwIGxpb24xIGtlcm5lbDogcGlk IDQ4NzQ1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlu b2Rlcwo8MTE4PkphbiAxOSAxMzowMDo1MCBsaW9uMSBrZXJuZWw6IHBpZCA0ODc0NSAoY3JlYXQp LCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4g MTkgMTM6MDA6NTIgbGlvbjEga2VybmVsOiBwaWQgNDg3NTMgKGNyZWF0KSwgdWlkIDAgaW51bWJl ciAzOTEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjAwOjUyIGxp b24xIGtlcm5lbDogcGlkIDQ4NzUzIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkxIG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNDg3ODEgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1 Nzggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjAwOjU0IGxpb24x IGtlcm5lbDogcGlkIDQ4NzgxIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc4IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzowMDo1NCBsaW9uMSBrZXJuZWw6IHBpZCA0 ODc4MSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU3OCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDM+cGlkIDQ4NzczIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk3IG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzowMDo1NiBsaW9uMSBrZXJuZWw6IHBpZCA0ODc3 MyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMK PDExOD5KYW4gMTkgMTM6MDA6NTYgbGlvbjEga2VybmVsOiBwaWQgNDg3NzMgKGNyZWF0KSwgdWlk IDAgaW51bWJlciAzOTcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA0ODc3MyAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+ cGlkIDQ4NzU5IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkzIG9uIC9yb290L3RtcDogb3V0IG9m IGlub2Rlcwo8MTE4PkphbiAxOSAxMzowMDo1OCBsaW9uMSBrZXJuZWw6IHBpZCA0ODc3MyAoY3Jl YXQpLCB1aWQgMCBpbnVtYmVyIDM5NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKLS1Nb3Jl LS0gICAgICAgIDwxMTg+SmFuIDE5IDEzOjAwOjU4IGxpb24xIGtlcm5lbDogcGlkIDQ4NzczIChj cmVhdCksIHVpZCAwIGludW1iZXIgMzk3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4 PkphbiAxOSAxMzowMTowMCBsaW9uMSBrZXJuZWw6IHBpZCA0ODc1OSAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDM5MyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MDE6 MDAgbGlvbjEga2VybmVsOiBwaWQgNDg3NTkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTMgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA0OTQ4MSAocncpLCB1aWQgMCwgd2FzIGtp bGxlZDogZXhjZWVkZWQgbWF4aW11bSBDUFUgbGltaXQKPDExOD5KYW4gMTkgMTM6MDg6MzAgbGlv bjEga2VybmVsOiBwaWQgNDk0ODEgKHJ3KSwgdWlkIDAsIHdhcyBraWxsZWQ6IGV4Y2VlZGVkIG1h eGltdW0gQ1BVIGxpbWl0CjwzPnBpZCA1MDI4MiAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MDg6MzQgbGlvbjEga2Vy bmVsOiBwaWQgNTAyODIgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCjwzPnBpZCA1MDI0NyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MDg6MzUgbGlvbjEga2VybmVs OiBwaWQgNTAyNDcgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwzPnBpZCA1MDI3MCAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9v dC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MDg6MzYgbGlvbjEga2VybmVsOiBw aWQgNTAyNzAgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwzPnBpZCA1MDI0NyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MDg6MzcgbGlvbjEga2VybmVsOiBwaWQg NTAyNDcgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwxMTg+YW4gMTkgMTM6MDg6MzcgbGlvbjEga2VybmVsOiBwaWQgNTAyNDcgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+YW4gMTkg MTM6MDg6MzcgbGlvbjEga2VybmVsOiBwaWQgNTAyNDcgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAz ODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1MDI0NyAoY3JlYXQpLCB1aWQg MCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDUwMjQ3IChj cmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5w aWQgNTAyNTIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwxMTg+SmFuIDE5IDEzOjA4OjQyIGxpb24xIGxhc3QgbWVzc2FnZSByZXBlYXRlZCAy IHRpbWVzCjwxMTg+SmFuIDE5IDEzOjA4OjQ0IGxpb24xIGtlcm5lbDogcGlkIDUwMjUyIChjcmVh dCksIHVpZCAwIGludW1iZXIgMzg2IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2RlcwotLU1vcmUt LSAgICAgICAgPDM+cGlkIDUwMjQ3IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzowODo0NSBsaW9uMSBrZXJuZWw6IHBp ZCA1MDI0NyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDM+cGlkIDUwMjQ3IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTAyNDcgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1MDI0NyAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDUwMjQ3IChjcmVh dCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQg NTAyNDkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwxMTg+SmFuIDE5IDEzOjA4OjUzIGxpb24xIGxhc3QgbWVzc2FnZSByZXBlYXRlZCA0IHRp bWVzCjwxMTg+SmFuIDE5IDEzOjA4OjU1IGxpb24xIGtlcm5lbDogcGlkIDUwMjQ5IChjcmVhdCks IHVpZCAwIGludW1iZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAx OSAxMzowODo1MyBsaW9uMSBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgNCB0aW1lcwo8MTE4PkphbiAx OSAxMzowODo1NSBsaW9uMSBrZXJuZWw6IHBpZCA1MDI0OSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVy IDM4NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDUwMjU2IChjcmVhdCksIHVp ZCAwIGludW1iZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAx MzowODo1NyBsaW9uMSBrZXJuZWw6IHBpZCA1MDI1NiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4 OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MDg6NTcgbGlvbjEg a2VybmVsOiBwaWQgNTAyNTYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODkgb24gL3Jvb3QvdG1w OiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1MDI1NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OCBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MDk6MDAgbGlvbjEga2Vy bmVsOiBwaWQgNTAyNTQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODggb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjA5OjAwIGxpb24xIGtlcm5lbDogcGlkIDUwMjU0 IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg4IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8 Mz5waWQgNTAyNDkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjA5OjAyIGxpb24xIGtlcm5lbDogcGlkIDUwMjQ5IChj cmVhdCksIHVpZCAwIGludW1iZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4 PkphbiAxOSAxMzowOTowMiBsaW9uMSBrZXJuZWw6IHBpZCA1MDI0OSAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDM4NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKLS1Nb3JlLS0gICAgICAgIDwz PnBpZCA1MTA2MiAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MTE6NDAgbGlvbjEga2VybmVsOiBwaWQgNTEwNjIgKG1r ZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBp ZCA1MTA1NiAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDExOD5KYW4gMTkgMTM6MTE6NDMgbGlvbjEga2VybmVsOiBwaWQgNTEwNTYgKG1rZGly KSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1 MTAzNiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTM6MTE6NDUgbGlvbjEga2VybmVsOiBwaWQgNTEwMzYgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1MTAz OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMK PDExOD5KYW4gMTkgMTM6MTE6NDYgbGlvbjEga2VybmVsOiBwaWQgNTEwMzggKGNyZWF0KSwgdWlk IDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEz OjExOjQ2IGxpb24xIGtlcm5lbDogcGlkIDUxMDM4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg2 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTEwMzggKGNyZWF0KSwgdWlkIDAg aW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1MTAzOCAoY3Jl YXQpLCB1aWQgMCBpbnVtYmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlk IDUxMDM5IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg4IG9uIC9yb290L3RtcDogb3V0IG9mIGlu b2Rlcwo8MTE4PkphbiAxOSAxMzoxMTo1MCBsaW9uMSBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgMiB0 aW1lcwo8MTE4PkphbiAxOSAxMzoxMTo1MCBsaW9uMSBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgMiB0 aW1lcwo8MTE4PkphbiAxOSAxMzoxMTo1MiBsaW9uMSBrZXJuZWw6IHBpZCA1MTAzOSAoY3JlYXQp LCB1aWQgMCBpbnVtYmVyIDM4OCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4g MTkgMTM6MTE6NTIgbGlvbjEga2VybmVsOiBwaWQgNTEwMzkgKGNyZWF0KSwgdWlkIDAgaW51bWJl ciAzODggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1MTAzOCAoY3JlYXQpLCB1 aWQgMCBpbnVtYmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkg MTM6MTE6NTQgbGlvbjEga2VybmVsOiBwaWQgNTEwMzggKGNyZWF0KSwgdWlkIDAgaW51bWJlciAz ODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1MTAzNiAoY3JlYXQpLCB1aWQg MCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6 MTE6NTYgbGlvbjEga2VybmVsOiBwaWQgNTEwMzYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCi0tTW9yZS0tICAgICAgICA8MTE4PkphbiAxOSAx MzoxMTo1NiBsaW9uMSBrZXJuZWw6IHBpZCA1MTAzNiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4 NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDUxMDM3IChjcmVhdCksIHVpZCAw IGludW1iZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzox MTo1OCBsaW9uMSBrZXJuZWw6IHBpZCA1MTAzNyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NyBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDUxMDM2IChjcmVhdCksIHVpZCAwIGlu dW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoxMjow MCBsaW9uMSBrZXJuZWw6IHBpZCA1MTAzNiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MTI6MDAgbGlvbjEga2VybmVs OiBwaWQgNTEwMzYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwzPnBpZCA1MTA0OSAocncpLCB1aWQgMCwgd2FzIGtpbGxlZDogZXhjZWVkZWQg bWF4aW11bSBDUFUgbGltaXQKPDExOD5KYW4gMTkgMTM6MTQ6NTUgbGlvbjEga2VybmVsOiBwaWQg NTEwNDkgKHJ3KSwgdWlkIDAsIHdhcyBraWxsZWQ6IGV4Y2VlZGVkIG1heGltdW0gQ1BVIGxpbWl0 CjwzPnBpZCA1MTc5MSAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MTU6MjYgbGlvbjEga2VybmVsOiBwaWQgNTE3OTEg KG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwz PnBpZCA1MjUzMSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NSBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MTg6MTUgbGlvbjEga2VybmVsOiBwaWQgNTI1MzEgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciAzOTUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+ SmFuIDE5IDEzOjE4OjE1IGxpb24xIGtlcm5lbDogcGlkIDUyNTMxIChjcmVhdCksIHVpZCAwIGlu dW1iZXIgMzk1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTI1MjYgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciA1Nzcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDEzOjE4OjE3IGxpb24xIGtlcm5lbDogcGlkIDUyNTI2IChjcmVhdCksIHVpZCAwIGludW1i ZXIgNTc3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTI0OTUgKHJ3KSwgdWlk IDAgaW51bWJlciA2MTkgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDExOD5KYW4gMTkg MTM6MTg6MTcgbGlvbjEga2VybmVsOiBwaWQgNTI0OTUgKHJ3KSwgdWlkIDAgaW51bWJlciA2MTkg b24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDExOD5KYW4gMTkgMTM6MTg6MTcgbGlvbjEg a2VybmVsOiBwaWQgNTI0OTUgKHJ3KSwgdWlkIDAgaW51bWJlciA2MTkgb24gL3Jvb3QvdG1wOiBm aWxlc3lzdGVtIGZ1bGwKPDM+cGlkIDUyNTIyIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk3IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTI1MDkgKHJ3KSwgdWlkIDAgaW51bWJl ciA2MTkgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKLS1Nb3JlLS0gICAgICAgIDwzPnBp ZCA1MjUxMiAocncpLCB1aWQgMCBpbnVtYmVyIDYxNSBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0g ZnVsbAo8MTE4PkphbiAxOSAxMzoxODoxOCBsaW9uMSBrZXJuZWw6IHBpZCA1MjUyMiAoY3JlYXQp LCB1aWQgMCBpbnVtYmVyIDM5NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4g MTkgMTM6MTg6MTggbGlvbjEga2VybmVsOiBwaWQgNTI1MDkgKHJ3KSwgdWlkIDAgaW51bWJlciA2 MTkgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDExOD5KYW4gMTkgMTM6MTg6MTggbGlv bjEga2VybmVsOiBwaWQgNTI1MTIgKHJ3KSwgdWlkIDAgaW51bWJlciA2MTUgb24gL3Jvb3QvdG1w OiBmaWxlc3lzdGVtIGZ1bGwKPDM+cGlkIDUyNTMwIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk2 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoxODoxOSBsaW9uMSBr ZXJuZWw6IHBpZCA1MjUzMCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NiBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MTg6MTkgbGlvbjEga2VybmVsOiBwaWQgNTI1 MzAgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwzPnBpZCA1MjQ5NCAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MTg6MjEgbGlvbjEga2VybmVsOiBwaWQgNTI0OTQg KG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwz PnBpZCA1MjUzNCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MiBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MTg6MjMgbGlvbjEga2VybmVsOiBwaWQgNTI1MzQgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciA1ODIgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+ SmFuIDE5IDEzOjE4OjIzIGxpb24xIGtlcm5lbDogcGlkIDUyNTM0IChjcmVhdCksIHVpZCAwIGlu dW1iZXIgNTgyIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTI1MzMgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciA1ODMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDEzOjE4OjI1IGxpb24xIGtlcm5lbDogcGlkIDUyNTMzIChjcmVhdCksIHVpZCAwIGludW1i ZXIgNTgzIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTI1MjkgKGNyZWF0KSwg dWlkIDAgaW51bWJlciA1Nzkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDEzOjE4OjI3IGxpb24xIGtlcm5lbDogcGlkIDUyNTI5IChjcmVhdCksIHVpZCAwIGludW1iZXIg NTc5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoxODoyNyBsaW9u MSBrZXJuZWw6IHBpZCA1MjUyOSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU3OSBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDUyNTI0IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc2 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoxODoyOSBsaW9uMSBr ZXJuZWw6IHBpZCA1MjUyNCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU3NiBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDM+cGlkIDUyNTI0IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc2IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2RlcwotLU1vcmUtLSAgICAgICAgPDM+cGlkIDUyNTI4IChj cmVhdCksIHVpZCAwIGludW1iZXIgMzk5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4 PkphbiAxOSAxMzoxODozMiBsaW9uMSBrZXJuZWw6IHBpZCA1MjUyNCAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDU3NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MTg6 MzIgbGlvbjEga2VybmVsOiBwaWQgNTI1MjQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1NzYgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjE4OjM0IGxpb24xIGtlcm5l bDogcGlkIDUyNTI4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk5IG9uIC9yb290L3RtcDogb3V0 IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoxODozNCBsaW9uMSBrZXJuZWw6IHBpZCA1MjUyOCAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+ cGlkIDUyNTI5IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc5IG9uIC9yb290L3RtcDogb3V0IG9m IGlub2Rlcwo8MTE4PkphbiAxOSAxMzoxODozNiBsaW9uMSBrZXJuZWw6IHBpZCA1MjUyOSAoY3Jl YXQpLCB1aWQgMCBpbnVtYmVyIDU3OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlk IDUyNTI4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk5IG9uIC9yb290L3RtcDogb3V0IG9mIGlu b2Rlcwo8MTE4PkphbiAxOSAxMzoxODozOCBsaW9uMSBrZXJuZWw6IHBpZCA1MjUyOCAoY3JlYXQp LCB1aWQgMCBpbnVtYmVyIDM5OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4g MTkgMTM6MTg6MzggbGlvbjEga2VybmVsOiBwaWQgNTI1MjggKGNyZWF0KSwgdWlkIDAgaW51bWJl ciAzOTkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1MzI1OCAobWtkaXIpLCB1 aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkg MTM6MjA6MTkgbGlvbjEga2VybmVsOiBwaWQgNTMyNTggKG1rZGlyKSwgdWlkIDAgaW51bWJlciAz ODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1MzI2NCAobWtkaXIpLCB1aWQg MCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6 MjA6MjYgbGlvbjEga2VybmVsOiBwaWQgNTMyNjQgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1Mzk2NyAobWtkaXIpLCB1aWQgMCBp bnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MjM6 MTcgbGlvbjEga2VybmVsOiBwaWQgNTM5NjcgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1Mzk2MiAoY3JlYXQpLCB1aWQgMCBpbnVt YmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MjM6MTkg bGlvbjEga2VybmVsOiBwaWQgNTM5NjIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jv b3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+YW4gMTkgMTM6MjM6MTkgbGlvbjEga2VybmVsOiBw aWQgNTM5NjIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwxMTg+YW4gMTkgMTM6MjM6MTkgbGlvbjEga2VybmVsOiBwaWQgNTM5NjIgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCi0tTW9yZS0t ICAgICAgICA8Mz5waWQgNTM5NjIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3Qv dG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1Mzk1OSAocncpLCB1aWQgMCBpbnVtYmVyIDM4NSBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MjM6MjEgbGlvbjEga2Vy bmVsOiBwaWQgNTM5NjIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjIzOjIzIGxpb24xIGtlcm5lbDogcGlkIDUzOTU5 IChydyksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4 PkphbiAxOSAxMzoyMzoyMSBsaW9uMSBrZXJuZWw6IHBpZCA1Mzk2MiAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDUzOTkzIChta2Rp ciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQg NTM5NjYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwzPnBpZCA1Mzk4NyAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MjM6MjkgbGlvbjEga2VybmVsOiBwaWQgNTM5 OTMgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwzPnBpZCA1Mzk5MSAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MjM6MzAgbGlvbjEga2VybmVsOiBwaWQgNTM5NjYg KGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwx MTg+SmFuIDE5IDEzOjIzOjMwIGxpb24xIGtlcm5lbDogcGlkIDUzOTg3IChta2RpciksIHVpZCAw IGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoy MzozMCBsaW9uMSBrZXJuZWw6IHBpZCA1Mzk5MSAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDUzOTY2IChjcmVhdCksIHVpZCAwIGlu dW1iZXIgMzkzIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyMzoz MiBsaW9uMSBrZXJuZWw6IHBpZCA1Mzk2NiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5MyBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MjM6MzIgbGlvbjEga2VybmVs OiBwaWQgNTM5NjYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTMgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwzPnBpZCA1Mzk4OSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5OCBvbiAvcm9v dC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MjM6MzQgbGlvbjEga2VybmVsOiBw aWQgNTM5ODkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTggb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwxMTg+SmFuIDE5IDEzOjIzOjM0IGxpb24xIGtlcm5lbDogcGlkIDUzOTg5IChjcmVh dCksIHVpZCAwIGludW1iZXIgMzk4IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQg NTM5ODkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCi0tTW9yZS0tICAgICAgICA8Mz5waWQgNTM5ODEgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAz OTcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjIzOjM2IGxpb24x IGtlcm5lbDogcGlkIDUzOTg5IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk4IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyMzozOCBsaW9uMSBrZXJuZWw6IHBpZCA1 Mzk4MSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTM6MjM6MzYgbGlvbjEga2VybmVsOiBwaWQgNTM5ODkgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzOTggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDEzOjIzOjM4IGxpb24xIGtlcm5lbDogcGlkIDUzOTgxIChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzk3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTM5NjggKGNyZWF0KSwgdWlk IDAgaW51bWJlciAzODkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEz OjIzOjQwIGxpb24xIGtlcm5lbDogcGlkIDUzOTY4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg5 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PmFuIDE5IDEzOjIzOjQwIGxpb24xIGtl cm5lbDogcGlkIDUzOTY4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg5IG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8MTE4PmFuIDE5IDEzOjIzOjQwIGxpb24xIGtlcm5lbDogcGlkIDUzOTY4 IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8 Mz5waWQgNTQ3MDggKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjI1OjI3IGxpb24xIGtlcm5lbDogcGlkIDU0NzA4ICht a2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5w aWQgNTQ3MDQgKHJ3KSwgdWlkIDAgaW51bWJlciA1Nzggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwxMTg+SmFuIDE5IDEzOjI1OjI5IGxpb24xIGtlcm5lbDogcGlkIDU0NzA0IChydyksIHVp ZCAwIGludW1iZXIgNTc4IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAx MzoyNToyOSBsaW9uMSBrZXJuZWw6IHBpZCA1NDcwNCAocncpLCB1aWQgMCBpbnVtYmVyIDU3OCBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU0NzAyIChydyksIHVpZCAwIGludW1i ZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyNTozMCBs aW9uMSBrZXJuZWw6IHBpZCA1NDcwMiAocncpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU0NzI2IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc3 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyNTozMSBsaW9uMSBr ZXJuZWw6IHBpZCA1NDcyNiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU3NyBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MjU6MzEgbGlvbjEga2VybmVsOiBwaWQgNTQ3 MjYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1Nzcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwzPnBpZCA1NDc0NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDQwMCBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKLS1Nb3JlLS0gICAgICAgIDwxMTg+SmFuIDE5IDEzOjI1OjMzIGxpb24xIGtl cm5lbDogcGlkIDU0NzQ0IChjcmVhdCksIHVpZCAwIGludW1iZXIgNDAwIG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8Mz5waWQgNTQ3NDQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA0MDAgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1NDc0NCAoY3JlYXQpLCB1aWQgMCBpbnVt YmVyIDQwMCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU0NzQ0IChjcmVhdCks IHVpZCAwIGludW1iZXIgNDAwIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTQ3 NDQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA0MDAgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwzPnBpZCA1NDc0NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDQwMCBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDM+cGlkIDU0NzMxIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTg1IG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyNTo0MyBsaW9uMSBsYXN0IG1l c3NhZ2UgcmVwZWF0ZWQgNSB0aW1lcwo8Mz5waWQgNTQ3MzEgKGNyZWF0KSwgdWlkIDAgaW51bWJl ciA1ODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1NDczMSAoY3JlYXQpLCB1 aWQgMCBpbnVtYmVyIDU4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkg MTM6MjU6NDUgbGlvbjEga2VybmVsOiBwaWQgNTQ3MzEgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1 ODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjI1OjQzIGxpb24x IGxhc3QgbWVzc2FnZSByZXBlYXRlZCA1IHRpbWVzCjwxMTg+SmFuIDE5IDEzOjI1OjU0IGxpb24x IGxhc3QgbWVzc2FnZSByZXBlYXRlZCAyIHRpbWVzCjwzPnBpZCA1NTQ2OCAobWtkaXIpLCB1aWQg MCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6 Mjc6NDAgbGlvbjEga2VybmVsOiBwaWQgNTU0NjggKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1NjE5MyAobWtkaXIpLCB1aWQgMCBp bnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6Mjk6 MzcgbGlvbjEga2VybmVsOiBwaWQgNTYxOTMgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1NjIxMCAoY3JlYXQpLCB1aWQgMCBpbnVt YmVyIDM4OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6Mjk6NDAg bGlvbjEga2VybmVsOiBwaWQgNTYyMTAgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODkgb24gL3Jv b3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjI5OjQwIGxpb24xIGtlcm5lbDog cGlkIDU2MjEwIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9m IGlub2RlcwotLU1vcmUtLSAgICAgICAgPDM+cGlkIDU2MjEwIChjcmVhdCksIHVpZCAwIGludW1i ZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTYxODMgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDEzOjI5OjQyIGxpb24xIGtlcm5lbDogcGlkIDU2MjEwIChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyOTo0NCBsaW9u MSBrZXJuZWw6IHBpZCA1NjE4MyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU2MjAzIChta2RpciksIHVpZCAwIGludW1iZXIgMzg0 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyOTo0NiBsaW9uMSBr ZXJuZWw6IHBpZCA1NjIwMyAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU2MjEwIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg5IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyOTo0NyBsaW9uMSBrZXJu ZWw6IHBpZCA1NjIxMCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OSBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6Mjk6NDcgbGlvbjEga2VybmVsOiBwaWQgNTYyMTAg KGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwz PnBpZCA1NjIxMCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OSBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDM+cGlkIDU2MjA3IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk0IG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyOTo0OSBsaW9uMSBrZXJuZWw6IHBp ZCA1NjIxMCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OSBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDExOD5KYW4gMTkgMTM6Mjk6NTEgbGlvbjEga2VybmVsOiBwaWQgNTYyMDcgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciAzOTQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDEzOjI5OjQ5IGxpb24xIGtlcm5lbDogcGlkIDU2MjEwIChjcmVhdCksIHVpZCAwIGludW1i ZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyOTo1MSBs aW9uMSBrZXJuZWw6IHBpZCA1NjIwNyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NCBvbiAvcm9v dC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU2MjEwIChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyOTo1NCBsaW9u MSBrZXJuZWw6IHBpZCA1NjIxMCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OSBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU2MTg5IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkx IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyOTo1NSBsaW9uMSBr ZXJuZWw6IHBpZCA1NjE4OSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5MSBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6Mjk6NTUgbGlvbjEga2VybmVsOiBwaWQgNTYx ODkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz Ci0tTW9yZS0tICAgICAgICA8Mz5waWQgNTYxOTYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTMg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjI5OjU3IGxpb24xIGtl cm5lbDogcGlkIDU2MTk2IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkzIG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoyOTo1NyBsaW9uMSBrZXJuZWw6IHBpZCA1NjE5 NiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5MyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMK PDM+cGlkIDU2MTk2IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkzIG9uIC9yb290L3RtcDogb3V0 IG9mIGlub2Rlcwo8Mz5waWQgNTYxOTYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTMgb24gL3Jv b3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1NjE5NiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVy IDM5MyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MzA6MDQgbGlv bjEgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDMgdGltZXMKPDM+cGlkIDU2OTMwIChta2RpciksIHVp ZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAx MzozMzoxNiBsaW9uMSBrZXJuZWw6IHBpZCA1NjkzMCAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4 NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU2OTQyIChjcmVhdCksIHVpZCAw IGludW1iZXIgMzg4IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzoz MzoxOCBsaW9uMSBrZXJuZWw6IHBpZCA1Njk0MiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OCBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MzM6MTggbGlvbjEga2Vy bmVsOiBwaWQgNTY5NDIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODggb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCjwzPnBpZCA1NjkzNiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6MzM6MjAgbGlvbjEga2VybmVs OiBwaWQgNTY5MzYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjMzOjIwIGxpb24xIGtlcm5lbDogcGlkIDU2OTM2IChj cmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5w aWQgNTY5MzggKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwxMTg+SmFuIDE5IDEzOjMzOjIyIGxpb24xIGtlcm5lbDogcGlkIDU2OTM4IChjcmVh dCksIHVpZCAwIGludW1iZXIgMzg2IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQg NTY5NDIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwxMTg+SmFuIDE5IDEzOjMzOjI0IGxpb24xIGtlcm5lbDogcGlkIDU2OTQyIChjcmVhdCks IHVpZCAwIGludW1iZXIgMzg4IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAx OSAxMzozMzoyNCBsaW9uMSBrZXJuZWw6IHBpZCA1Njk0MiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVy IDM4OCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKLS1Nb3JlLS0gICAgICAgIDwzPnBpZCA1 Njk0MyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTM6MzM6MjcgbGlvbjEga2VybmVsOiBwaWQgNTY5NDMgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzODkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDEzOjMzOjI3IGxpb24xIGtlcm5lbDogcGlkIDU2OTQzIChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTY5MzggKGNyZWF0KSwgdWlk IDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEz OjMzOjI5IGxpb24xIGtlcm5lbDogcGlkIDU2OTM4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg2 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTY5NDEgKGNyZWF0KSwgdWlkIDAg aW51bWJlciAzOTEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjMz OjMxIGxpb24xIGtlcm5lbDogcGlkIDU2OTQxIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkxIG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzozMzozMSBsaW9uMSBrZXJu ZWw6IHBpZCA1Njk0MSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5MSBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDM+cGlkIDU2OTQxIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkxIG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTY5NDMgKGNyZWF0KSwgdWlkIDAgaW51bWJl ciAzODkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjMzOjMzIGxp b24xIGtlcm5lbDogcGlkIDU2OTQxIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkxIG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PD4xSjFhbjggPkoxYTluICAxMTkzOiAxMzMzOjozMzMg M2w6aTM1byBubGlvMW4gMWsgZXJrZW5yZW5lbDpsIDpwaSBkcCBpNWQ2OTQgMSA1KGNyNmU5NGF0 MyApLChjIHJldWlhdGQpICwwICB1aW5pdW1kIDBiIGllcm51IG1iZXIzIDM4OTkxICBvb25uICAv L3Jvcm90by90b3RtL3B0bTogcG86dSB0IG91b2Z0ICBpb2Ygbmlub2RvZWRzCmVzCjwxMTg+SmFu IDE5IDEzOjMzOjM1IGxpb24xIGtlcm5lbDogcGlkIDU2OTQzIChjcmVhdCksIHVpZCAwIGludW1i ZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTY5NDIgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzODggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDEzOjMzOjM3IGxpb24xIGtlcm5lbDogcGlkIDU2OTQyIChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzg4IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTY5NDAgKGNyZWF0KSwgdWlk IDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEz OjMzOjM5IGxpb24xIGtlcm5lbDogcGlkIDU2OTQwIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg3 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzozMzozOSBsaW9uMSBr ZXJuZWw6IHBpZCA1Njk0MCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NyBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU4NDA1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkxIG9u IC9yb290L3RtcDogb3V0IG9mIGlub2RlcwotLU1vcmUtLSAgICAgICAgPDExOD5KYW4gMTkgMTM6 Mzg6NTEgbGlvbjEga2VybmVsOiBwaWQgNTg0MDUgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTEg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjM4OjUxIGxpb24xIGtl cm5lbDogcGlkIDU4NDA1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkxIG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8Mz5waWQgNTg0MTUgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODkgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjM5OjAzIGxpb24xIGtlcm5l bDogcGlkIDU4NDE1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg5IG9uIC9yb290L3RtcDogb3V0 IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzozOTowMyBsaW9uMSBrZXJuZWw6IHBpZCA1ODQxNSAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+ cGlkIDU5MTM0IChydyksIHVpZCAwIGludW1iZXIgNDA1IG9uIC9yb290L3RtcDogZmlsZXN5c3Rl bSBmdWxsCjwxMTg+SmFuIDE5IDEzOjQyOjM1IGxpb24xIGtlcm5lbDogcGlkIDU5MTM0IChydyks IHVpZCAwIGludW1iZXIgNDA1IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwzPnBpZCA1 OTE1NSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTM6NDI6MzcgbGlvbjEga2VybmVsOiBwaWQgNTkxNTUgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzOTUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDEzOjQyOjM3IGxpb24xIGtlcm5lbDogcGlkIDU5MTU1IChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzk1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTkxNjIgKGNyZWF0KSwgdWlk IDAgaW51bWJlciA1ODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1OTE0NSAo cncpLCB1aWQgMCBpbnVtYmVyIDIwOSBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8Mz5w aWQgNTkxNTggKHJ3KSwgdWlkIDAgaW51bWJlciA0MTkgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVt IGZ1bGwKPDExOD5KYW4gMTkgMTM6NDI6MzkgbGlvbjEga2VybmVsOiBwaWQgNTkxNjIgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciA1ODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDEzOjQyOjM5IGxpb24xIGtlcm5lbDogcGlkIDU5MTQ1IChydyksIHVpZCAwIGludW1iZXIg MjA5IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwxMTg+SmFuIDE5IDEzOjQyOjM5IGxp b24xIGtlcm5lbDogcGlkIDU5MTU4IChydyksIHVpZCAwIGludW1iZXIgNDE5IG9uIC9yb290L3Rt cDogZmlsZXN5c3RlbSBmdWxsCjwzPnBpZCA1OTE2NiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4 OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NDI6NDEgbGlvbjEg a2VybmVsOiBwaWQgNTkxNjYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODkgb24gL3Jvb3QvdG1w OiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjQyOjQxIGxpb24xIGtlcm5lbDogcGlkIDU5 MTY2IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rl cwo8Mz5waWQgNTkxNTIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1NzYgb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCi0tTW9yZS0tICAgICAgICA8MTE4PkphbiAxOSAxMzo0Mjo0MyBsaW9uMSBr ZXJuZWw6IHBpZCA1OTE1MiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU3NiBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU5MTY0IChjcmVhdCksIHVpZCAwIGludW1iZXIgNDAyIG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo0Mjo0NSBsaW9uMSBrZXJu ZWw6IHBpZCA1OTE2NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDQwMiBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NDI6NDUgbGlvbjEga2VybmVsOiBwaWQgNTkxNjQg KGNyZWF0KSwgdWlkIDAgaW51bWJlciA0MDIgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwz PnBpZCA1OTE2MSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MiBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NDI6NDcgbGlvbjEga2VybmVsOiBwaWQgNTkxNjEgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciA1ODIgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBp ZCA1OTE2OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5OSBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDExOD5KYW4gMTkgMTM6NDI6NDkgbGlvbjEga2VybmVsOiBwaWQgNTkxNjggKGNyZWF0 KSwgdWlkIDAgaW51bWJlciAzOTkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDEzOjQyOjQ5IGxpb24xIGtlcm5lbDogcGlkIDU5MTY4IChjcmVhdCksIHVpZCAwIGludW1i ZXIgMzk5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTkxNTIgKGNyZWF0KSwg dWlkIDAgaW51bWJlciA1NzYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDEzOjQyOjUxIGxpb24xIGtlcm5lbDogcGlkIDU5MTUyIChjcmVhdCksIHVpZCAwIGludW1iZXIg NTc2IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTkxNjAgKGNyZWF0KSwgdWlk IDAgaW51bWJlciA1ODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEz OjQyOjU0IGxpb24xIGtlcm5lbDogcGlkIDU5MTYwIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTg1 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo0Mjo1NCBsaW9uMSBr ZXJuZWw6IHBpZCA1OTE2MCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NSBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU5MTY4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk5IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo0Mjo1NiBsaW9uMSBrZXJu ZWw6IHBpZCA1OTE2OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5OSBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDM+cGlkIDU5MTYxIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTgyIG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo0Mjo1OCBsaW9uMSBrZXJuZWw6 IHBpZCA1OTE2MSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MiBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NDI6NTggbGlvbjEga2VybmVsOiBwaWQgNTkxNjEgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciA1ODIgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBp ZCA1OTkzMCAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKLS1Nb3JlLS0gICAgICAgIDwxMTg+SmFuIDE5IDEzOjQ0OjQxIGxpb24xIGtlcm5lbDog cGlkIDU5OTMwIChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9m IGlub2Rlcwo8MTE4PkphbiAxOSAxMzo0NDo0MSBsaW9uMSBrZXJuZWw6IHBpZCA1OTkzMCAobWtk aXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlk IDU5OTI1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk2IG9uIC9yb290L3RtcDogb3V0IG9mIGlu b2Rlcwo8MTE4PkphbiAxOSAxMzo0NDo0MyBsaW9uMSBrZXJuZWw6IHBpZCA1OTkyNSAoY3JlYXQp LCB1aWQgMCBpbnVtYmVyIDM5NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4g MTkgMTM6NDQ6NDMgbGlvbjEga2VybmVsOiBwaWQgNTk5MjUgKGNyZWF0KSwgdWlkIDAgaW51bWJl ciAzOTYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1OTkyNyAoY3JlYXQpLCB1 aWQgMCBpbnVtYmVyIDU4MSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkg MTM6NDQ6NDUgbGlvbjEga2VybmVsOiBwaWQgNTk5MjcgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1 ODEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjQ0OjQ1IGxpb24x IGtlcm5lbDogcGlkIDU5OTI3IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTgxIG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTk5MjcgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODEg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA1OTkyNyAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDU4MSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDU5OTI3IChjcmVh dCksIHVpZCAwIGludW1iZXIgNTgxIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQg NTk5MjcgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwzPnBpZCA1OTkwMSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NyBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NDQ6NTMgbGlvbjEgbGFzdCBtZXNzYWdlIHJl cGVhdGVkIDQgdGltZXMKPDExOD5KYW4gMTkgMTM6NDQ6NTYgbGlvbjEga2VybmVsOiBwaWQgNTk5 MDEgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwxMTg+SmFuIDE5IDEzOjQ0OjUzIGxpb24xIGxhc3QgbWVzc2FnZSByZXBlYXRlZCA0IHRpbWVz CjwxMTg+SmFuIDE5IDEzOjQ0OjU2IGxpb24xIGtlcm5lbDogcGlkIDU5OTAxIChjcmVhdCksIHVp ZCAwIGludW1iZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTk5MDEg KGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwz PnBpZCA1OTkxMCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NDQ6NTggbGlvbjEga2VybmVsOiBwaWQgNTk5MDEgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCi0tTW9y ZS0tICAgICAgICA8MTE4PkphbiAxOSAxMzo0NTowMCBsaW9uMSBrZXJuZWw6IHBpZCA1OTkxMCAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDEx OD5KYW4gMTkgMTM6NDQ6NTggbGlvbjEga2VybmVsOiBwaWQgNTk5MDEgKGNyZWF0KSwgdWlkIDAg aW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjQ1 OjAwIGxpb24xIGtlcm5lbDogcGlkIDU5OTEwIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg2IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNTk5MTcgKGNyZWF0KSwgdWlkIDAgaW51 bWJlciA0MDEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjQ1OjAy IGxpb24xIGtlcm5lbDogcGlkIDU5OTE3IChjcmVhdCksIHVpZCAwIGludW1iZXIgNDAxIG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjEzNjcgKHJ3KSwgdWlkIDAgaW51bWJlciA0 MDYgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDM+cGlkIDYxMzY4IChydyksIHVpZCAw IGludW1iZXIgNDA0IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwxMTg+SmFuIDE5IDEz OjUxOjI5IGxpb24xIGtlcm5lbDogcGlkIDYxMzY3IChydyksIHVpZCAwIGludW1iZXIgNDA2IG9u IC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwxMTg+SmFuIDE5IDEzOjUxOjI5IGxpb24xIGtl cm5lbDogcGlkIDYxMzY3IChydyksIHVpZCAwIGludW1iZXIgNDA2IG9uIC9yb290L3RtcDogZmls ZXN5c3RlbSBmdWxsCjwxMTg+SmFuIDE5IDEzOjUxOjI5IGxpb24xIGtlcm5lbDogcGlkIDYxMzY4 IChydyksIHVpZCAwIGludW1iZXIgNDA0IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwx MTg+SmFuIDE5IDEzOjUxOjI5IGxpb24xIGtlcm5lbDogcGlkIDYxMzY4IChydyksIHVpZCAwIGlu dW1iZXIgNDA0IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwzPnBpZCA2MTM2MSAocncp LCB1aWQgMCBpbnVtYmVyIDQwOSBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8MTE4Pkph biAxOSAxMzo1MTozMSBsaW9uMSBrZXJuZWw6IHBpZCA2MTM2MSAocncpLCB1aWQgMCBpbnVtYmVy IDQwOSBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8Mz5waWQgNjIxNDQgKGNyZWF0KSwg dWlkIDAgaW51bWJlciA1ODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDEzOjUzOjMzIGxpb24xIGtlcm5lbDogcGlkIDYyMTQ0IChjcmVhdCksIHVpZCAwIGludW1iZXIg NTg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjIxMDAgKHJ3KSwgdWlkIDAg aW51bWJlciA0MDYgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDM+cGlkIDYyMTAxIChy dyksIHVpZCAwIGludW1iZXIgMzkzIG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwxMTg+ SmFuIDE5IDEzOjUzOjM0IGxpb24xIGtlcm5lbDogcGlkIDYyMTAwIChydyksIHVpZCAwIGludW1i ZXIgNDA2IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwxMTg+SmFuIDE5IDEzOjUzOjM0 IGxpb24xIGtlcm5lbDogcGlkIDYyMTAxIChydyksIHVpZCAwIGludW1iZXIgMzkzIG9uIC9yb290 L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwzPnBpZCA2Mjg1OSAobWtkaXIpLCB1aWQgMCBpbnVtYmVy IDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKLS1Nb3JlLS0gICAgICAgIDwxMTg+SmFu IDE5IDEzOjU1OjQ3IGxpb24xIGtlcm5lbDogcGlkIDYyODU5IChta2RpciksIHVpZCAwIGludW1i ZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjI4NTcgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDEzOjU1OjUxIGxpb24xIGtlcm5lbDogcGlkIDYyODU3IChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo1NTo1MSBsaW9u MSBrZXJuZWw6IHBpZCA2Mjg1NyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDYyODU3IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg1 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo1NTo1MyBsaW9uMSBr ZXJuZWw6IHBpZCA2Mjg1NyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDM+cGlkIDYzNTgzIChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo1OToyOSBsaW9uMSBrZXJu ZWw6IHBpZCA2MzU4MyAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDM+cGlkIDYzNTc0IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo1OTozMSBsaW9uMSBrZXJuZWw6 IHBpZCA2MzU3NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NTk6MzEgbGlvbjEga2VybmVsOiBwaWQgNjM1NzQgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBp ZCA2MzU5MiAocncpLCB1aWQgMCBpbnVtYmVyIDU3NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTM6NTk6MzIgbGlvbjEga2VybmVsOiBwaWQgNjM1OTIgKHJ3KSwgdWlk IDAgaW51bWJlciA1NzYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2MzU3OCAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDEx OD5KYW4gMTkgMTM6NTk6MzMgbGlvbjEga2VybmVsOiBwaWQgNjM1NzggKGNyZWF0KSwgdWlkIDAg aW51bWJlciAzOTQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjU5 OjMzIGxpb24xIGtlcm5lbDogcGlkIDYzNTc4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk0IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjM1ODcgKHJ3KSwgdWlkIDAgaW51bWJl ciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjU5OjM0IGxp b24xIGtlcm5lbDogcGlkIDYzNTg3IChydyksIHVpZCAwIGludW1iZXIgMzg2IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjM1NzcgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODgg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjU5OjM1IGxpb24xIGtl cm5lbDogcGlkIDYzNTc3IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg4IG9uIC9yb290L3RtcDog b3V0IG9mIGlub2RlcwotLU1vcmUtLSAgICAgICAgPDM+cGlkIDYzNTg4IChta2RpciksIHVpZCAw IGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo1 OTozOCBsaW9uMSBrZXJuZWw6IHBpZCA2MzU4OCAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NTk6MzggbGlvbjEga2Vy bmVsOiBwaWQgNjM1ODggKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCjwzPnBpZCA2MzU3NSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NyBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NTk6NDAgbGlvbjEga2VybmVs OiBwaWQgNjM1NzUgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwxMTg+SmFuIDE5IDEzOjU5OjQwIGxpb24xIGtlcm5lbDogcGlkIDYzNTc1IChj cmVhdCksIHVpZCAwIGludW1iZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5w aWQgNjM1ODEgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTEgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwxMTg+SmFuIDE5IDEzOjU5OjQyIGxpb24xIGtlcm5lbDogcGlkIDYzNTgxIChjcmVh dCksIHVpZCAwIGludW1iZXIgMzkxIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQg NjM1NzggKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwxMTg+SmFuIDE5IDEzOjU5OjQ0IGxpb24xIGtlcm5lbDogcGlkIDYzNTc4IChjcmVhdCks IHVpZCAwIGludW1iZXIgMzk0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAx OSAxMzo1OTo0NCBsaW9uMSBrZXJuZWw6IHBpZCA2MzU3OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVy IDM5NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDYzNTgxIChjcmVhdCksIHVp ZCAwIGludW1iZXIgMzkxIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAx Mzo1OTo0NiBsaW9uMSBrZXJuZWw6IHBpZCA2MzU4MSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5 MSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDYzNTc0IChjcmVhdCksIHVpZCAw IGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo1 OTo0OCBsaW9uMSBrZXJuZWw6IHBpZCA2MzU3NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NTk6NDggbGlvbjEga2Vy bmVsOiBwaWQgNjM1NzQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCjwzPnBpZCA2MzU3NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDYzNTgwIChjcmVhdCksIHVpZCAwIGludW1i ZXIgMzk3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxMzo1OTo1MCBs aW9uMSBrZXJuZWw6IHBpZCA2MzU3NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9v dC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NTk6NTAgbGlvbjEga2VybmVsOiBw aWQgNjM1NzQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCi0tTW9yZS0tICAgICAgICA8MTE4PkphbiAxOSAxMzo1OTo1MiBsaW9uMSBrZXJuZWw6 IHBpZCA2MzU4MCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NyBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTM6NTk6NTIgbGlvbjEga2VybmVsOiBwaWQgNjM1ODAgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciAzOTcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBp ZCA2NDMyMCAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDExOD5KYW4gMTkgMTQ6MDE6MzAgbGlvbjEga2VybmVsOiBwaWQgNjQzMjAgKG1rZGly KSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2 NDMxMCAocncpLCB1aWQgMCBpbnVtYmVyIDM5NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMK PDExOD5KYW4gMTkgMTQ6MDE6MzIgbGlvbjEga2VybmVsOiBwaWQgNjQzMTAgKHJ3KSwgdWlkIDAg aW51bWJlciAzOTYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjAx OjMyIGxpb24xIGtlcm5lbDogcGlkIDY0MzEwIChydyksIHVpZCAwIGludW1iZXIgMzk2IG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjQzMzcgKGNyZWF0KSwgdWlkIDAgaW51bWJl ciA0MDAgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjAxOjM0IGxp b24xIGtlcm5lbDogcGlkIDY0MzM3IChjcmVhdCksIHVpZCAwIGludW1iZXIgNDAwIG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowMTozNCBsaW9uMSBrZXJuZWw6IHBp ZCA2NDMzNyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDQwMCBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDM+cGlkIDY0MzM5IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTg0IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowMTozNiBsaW9uMSBrZXJuZWw6IHBpZCA2 NDMzOSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDM+cGlkIDY0MzIxIChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowMTozOCBsaW9uMSBrZXJuZWw6IHBpZCA2NDMy MSAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMK PDM+cGlkIDY0MzQzIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTgzIG9uIC9yb290L3RtcDogb3V0 IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowMTo0MCBsaW9uMSBrZXJuZWw6IHBpZCA2NDM0MyAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDEx OD5KYW4gMTkgMTQ6MDE6NDAgbGlvbjEga2VybmVsOiBwaWQgNjQzNDMgKGNyZWF0KSwgdWlkIDAg aW51bWJlciA1ODMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2NDMyNSAoY3Jl YXQpLCB1aWQgMCBpbnVtYmVyIDM5NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlk IDY0MzQxIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTgyIG9uIC9yb290L3RtcDogb3V0IG9mIGlu b2Rlcwo8Mz5waWQgNjQzNDUgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODUgb24gL3Jvb3QvdG1w OiBvdXQgb2YgaW5vZGVzCi0tTW9yZS0tICAgICAgICA8Mz5waWQgNjQzNDUgKGNyZWF0KSwgdWlk IDAgaW51bWJlciA1ODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2NDM0NSAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+ cGlkIDY0MzQ1IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTg1IG9uIC9yb290L3RtcDogb3V0IG9m IGlub2Rlcwo8Mz5waWQgNjQzNDMgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODMgb24gL3Jvb3Qv dG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2NDMyOSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5 OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY0MzMxIChjcmVhdCksIHVpZCAw IGludW1iZXIgNTc5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDow MTo0MiBsaW9uMSBrZXJuZWw6IHBpZCA2NDMyNSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NSBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MDI6MTcgbGlvbjEga2Vy bmVsOiBwaWQgNjQzNDEgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODIgb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjAyOjE3IGxpb24xIGtlcm5lbDogcGlkIDY0MzQ1 IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8 MTE4PkphbiAxOSAxNDowMjoxNyBsaW9uMSBsYXN0IG1lc3NhZ2UgcmVwZWF0ZWQgMyB0aW1lcwo8 MTE4PkphbiAxOSAxNDowMjoxNyBsaW9uMSBrZXJuZWw6IHBpZCA2NDM0MyAoY3JlYXQpLCB1aWQg MCBpbnVtYmVyIDU4MyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6 MDI6MTcgbGlvbjEga2VybmVsOiBwaWQgNjQzMjkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTkg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjAyOjE3IGxpb24xIGtl cm5lbDogcGlkIDY0MzMxIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc5IG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8Mz5waWQgNjUwNDUgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjAzOjQzIGxpb24xIGtlcm5l bDogcGlkIDY1MDQ1IChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0 IG9mIGlub2Rlcwo8Mz5waWQgNjU3MjkgKHJ3KSwgdWlkIDAgaW51bWJlciA0MDIgb24gL3Jvb3Qv dG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDExOD5KYW4gMTkgMTQ6MDU6NDIgbGlvbjEga2VybmVsOiBw aWQgNjU3MjkgKHJ3KSwgdWlkIDAgaW51bWJlciA0MDIgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVt IGZ1bGwKPDM+cGlkIDY1Nzc4IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTg0IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowNTo0NSBsaW9uMSBrZXJuZWw6IHBpZCA2 NTc3OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTQ6MDU6NDUgbGlvbjEga2VybmVsOiBwaWQgNjU3NzggKGNyZWF0KSwg dWlkIDAgaW51bWJlciA1ODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCi0tTW9yZS0tICAg ICAgICA8Mz5waWQgNjU3NzkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1Nzkgb24gL3Jvb3QvdG1w OiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjA1OjQ3IGxpb24xIGtlcm5lbDogcGlkIDY1 Nzc5IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rl cwo8MTE4PkphbiAxOSAxNDowNTo0NyBsaW9uMSBrZXJuZWw6IHBpZCA2NTc3OSAoY3JlYXQpLCB1 aWQgMCBpbnVtYmVyIDU3OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY1NzQ5 IChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8 MTE4PkphbiAxOSAxNDowNTo0OSBsaW9uMSBrZXJuZWw6IHBpZCA2NTc0OSAobWtkaXIpLCB1aWQg MCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY1Nzc5IChj cmVhdCksIHVpZCAwIGludW1iZXIgNTc5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4 PkphbiAxOSAxNDowNTo1MiBsaW9uMSBrZXJuZWw6IHBpZCA2NTc3OSAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDU3OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MDU6 NTIgbGlvbjEga2VybmVsOiBwaWQgNjU3NzkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1Nzkgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2NTc3OSAoY3JlYXQpLCB1aWQgMCBpbnVt YmVyIDU3OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY1Nzc5IChjcmVhdCks IHVpZCAwIGludW1iZXIgNTc5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjU3 NzkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1Nzkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwzPnBpZCA2NTc3NSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NSBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MDU6NTggbGlvbjEgbGFzdCBtZXNzYWdlIHJlcGVh dGVkIDMgdGltZXMKPDExOD5KYW4gMTkgMTQ6MDY6MDAgbGlvbjEga2VybmVsOiBwaWQgNjU3NzUg KGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwz PnBpZCA2NTc3MSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MCBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MDY6MDIgbGlvbjEga2VybmVsOiBwaWQgNjU3NzEgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciA1ODAgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+ SmFuIDE5IDE0OjA2OjAyIGxpb24xIGtlcm5lbDogcGlkIDY1NzcxIChjcmVhdCksIHVpZCAwIGlu dW1iZXIgNTgwIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjU3NjkgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciA1ODMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDE0OjA2OjA0IGxpb24xIGtlcm5lbDogcGlkIDY1NzY5IChjcmVhdCksIHVpZCAwIGludW1i ZXIgNTgzIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowNjowNCBs aW9uMSBrZXJuZWw6IHBpZCA2NTc2OSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MyBvbiAvcm9v dC90bXA6IG91dCBvZiBpbm9kZXMKLS1Nb3JlLS0gICAgICAgIDwzPnBpZCA2NTc3MiAoY3JlYXQp LCB1aWQgMCBpbnVtYmVyIDQwMSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4g MTkgMTQ6MDY6MDcgbGlvbjEga2VybmVsOiBwaWQgNjU3NzIgKGNyZWF0KSwgdWlkIDAgaW51bWJl ciA0MDEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjA2OjA3IGxp b24xIGtlcm5lbDogcGlkIDY1NzcyIChjcmVhdCksIHVpZCAwIGludW1iZXIgNDAxIG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjU3NjggKGNyZWF0KSwgdWlkIDAgaW51bWJlciAz OTkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjA2OjA5IGxpb24x IGtlcm5lbDogcGlkIDY1NzY4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk5IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowNjowOSBsaW9uMSBrZXJuZWw6IHBpZCA2 NTc2OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5OSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDM+cGlkIDY1NzcyIChjcmVhdCksIHVpZCAwIGludW1iZXIgNDAxIG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowNjoxMSBsaW9uMSBrZXJuZWw6IHBpZCA2NTc3 MiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDQwMSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMK PDExOD5KYW4gMTkgMTQ6MDY6MTEgbGlvbjEga2VybmVsOiBwaWQgNjU3NzIgKGNyZWF0KSwgdWlk IDAgaW51bWJlciA0MDEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2NjUwOSAo cncpLCB1aWQgMCBpbnVtYmVyIDYxMCBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8MTE4 PkphbiAxOSAxNDowNzo0NyBsaW9uMSBrZXJuZWw6IHBpZCA2NjUwOSAocncpLCB1aWQgMCBpbnVt YmVyIDYxMCBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8Mz5waWQgNjY0OTggKG1rZGly KSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDE0OjA3OjQ5IGxpb24xIGtlcm5lbDogcGlkIDY2NDk4IChta2RpciksIHVpZCAwIGludW1i ZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjY1NDYgKGNyZWF0KSwg dWlkIDAgaW51bWJlciA1OTcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDE0OjA3OjUxIGxpb24xIGtlcm5lbDogcGlkIDY2NTQ2IChjcmVhdCksIHVpZCAwIGludW1iZXIg NTk3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowNzo1MSBsaW9u MSBrZXJuZWw6IHBpZCA2NjU0NiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU5NyBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY2NTIyIChydyksIHVpZCAwIGludW1iZXIgNDA1IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowNzo1MiBsaW9uMSBrZXJu ZWw6IHBpZCA2NjUyMiAocncpLCB1aWQgMCBpbnVtYmVyIDQwNSBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDM+cGlkIDY2NTQ2IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTk3IG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDowNzo1MyBsaW9uMSBrZXJuZWw6IHBp ZCA2NjU0NiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU5NyBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKLS1Nb3JlLS0gICAgICAgIDwxMTg+SmFuIDE5IDE0OjA3OjUzIGxpb24xIGtlcm5lbDog cGlkIDY2NTQ2IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTk3IG9uIC9yb290L3RtcDogb3V0IG9m IGlub2Rlcwo8Mz5waWQgNjY1MDUgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3Qv dG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjA3OjU1IGxpb24xIGtlcm5lbDogcGlk IDY2NTA1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlu b2Rlcwo8MTE4PkphbiAxOSAxNDowNzo1NSBsaW9uMSBrZXJuZWw6IHBpZCA2NjUwNSAoY3JlYXQp LCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY2 NTM4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMjMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwxMTg+SmFuIDE5IDE0OjA3OjU3IGxpb24xIGtlcm5lbDogcGlkIDY2NTM4IChjcmVhdCksIHVp ZCAwIGludW1iZXIgMjMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0 OjA3OjU3IGxpb24xIGtlcm5lbDogcGlkIDY2NTM4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMjMg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2NjUzOCAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDIzIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjY1NDYgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciA1OTcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDE0OjA4OjAwIGxpb24xIGtlcm5lbDogcGlkIDY2NTM4IChjcmVhdCksIHVpZCAwIGludW1i ZXIgMjMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjA4OjAyIGxp b24xIGtlcm5lbDogcGlkIDY2NTQ2IChjcmVKYWFudCAxKTksIDE0IDp1MDg6aWQwIDAgMGxpbyBu aTEgbmtldW1yYm5lZWxyOiAgcGk1ZDkgNzYgbzZuIDUzOCAvKHJjcm9vZXRhL3R0bSlwLCA6dWkg b2QgdTAgaW50dW0gYm9lZnIgIDJpbjNvIGRlcwpvCjwxMTg+biAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDExOD5KYW4gMTkgMTQ6MDg6MDIgbGlvbjEga2VybmVsOiBwaWQgNjY1NDYgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciA1OTcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2 NjU0OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDYwMCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTQ6MDg6MDQgbGlvbjEga2VybmVsOiBwaWQgNjY1NDggKGNyZWF0KSwg dWlkIDAgaW51bWJlciA2MDAgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDE0OjA4OjA0IGxpb24xIGtlcm5lbDogcGlkIDY2NTQ4IChjcmVhdCksIHVpZCAwIGludW1iZXIg NjAwIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8PDM+cGlkMyA+cGlkIDY2NjUzNjYgNTQy ICgoY2NycmVhZWF0dCkpLCwgIHV1aWlkZCAgMDAgaSBuaXVubXVibWViZXJyICA0MDY2IDA5byBu byBuIC8vcnJvb29vdHQvdC9tcHQ6bXAgOiBvb3V0IHVvZnQgIGlvbmZvIGRpZW5zCm8KPDM+ZGVz Ci0tTW9yZS0tICAgICAgICA8MTE4PkphbiAxOSAxNDowODowNiBsaW9uMSBrZXJuZWw6IGRlcwo8 MTE4PkphbiAxOSAxNDowODowNiBsaW9uMSBrZXJuZWw6IGRlcwo8Mz5waWQgNjY1MDcgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDE0OjA4OjA4IGxpb24xIGtlcm5lbDogcGlkIDY2NTA3IChjcmVhdCksIHVpZCAwIGludW1i ZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjgwMDAgKG1rZGlyKSwg dWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDE0OjEyOjM3IGxpb24xIGtlcm5lbDogcGlkIDY4MDAwIChta2RpciksIHVpZCAwIGludW1iZXIg Mzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjc5OTMgKHJ3KSwgdWlkIDAg aW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjEy OjQxIGxpb24xIGtlcm5lbDogcGlkIDY3OTkzIChydyksIHVpZCAwIGludW1iZXIgMzg1IG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjc5OTQgKHJ3KSwgdWlkIDAgaW51bWJlciA1 NzYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjEyOjQzIGxpb24x IGtlcm5lbDogcGlkIDY3OTk0IChydyksIHVpZCAwIGludW1iZXIgNTc2IG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8Mz5waWQgNjgwMjMgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjEyOjQ1IGxpb24xIGtlcm5l bDogcGlkIDY4MDIzIChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0 IG9mIGlub2Rlcwo8MTE4PnIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PnIg Mzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjg4MzIgKGNyZWF0KSwgdWlk IDAgaW51bWJlciA1ODAgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA2ODgxMCAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDEx OD5KYW4gMTkgMTQ6MTY6NTUgbGlvbjEga2VybmVsOiBwaWQgNjg4MzIgKGNyZWF0KSwgdWlkIDAg aW51bWJlciA1ODAgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjE2 OjU1IGxpb24xIGtlcm5lbDogcGlkIDY4ODEwIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk3IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjg4MzIgKGNyZWF0KSwgdWlkIDAgaW51 bWJlciA1ODAgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjE2OjU2 IGxpb24xIGtlcm5lbDogcGlkIDY4ODMyIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTgwIG9uIC9y b290L3RtcDogb3V0IG9mIGlub2RlcwotLU1vcmUtLSAgICAgICAgPDM+cGlkIDY4ODAzIChjcmVh dCksIHVpZCAwIGludW1iZXIgMzkzIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4Pkph biAxOSAxNDoxNjo1OCBsaW9uMSBrZXJuZWw6IHBpZCA2ODgwMyAoY3JlYXQpLCB1aWQgMCBpbnVt YmVyIDM5MyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY4ODEwIChjcmVhdCks IHVpZCAwIGludW1iZXIgMzk3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAx OSAxNDoxNjo1OSBsaW9uMSBrZXJuZWw6IHBpZCA2ODgxMCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVy IDM5NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY4ODAzIChjcmVhdCksIHVp ZCAwIGludW1iZXIgMzkzIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAx NDoxNzowMCBsaW9uMSBrZXJuZWw6IHBpZCA2ODgwMyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5 MyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY4NzkxIChjcmVhdCksIHVpZCAw IGludW1iZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDox NzowMiBsaW9uMSBrZXJuZWw6IHBpZCA2ODc5MSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OSBv biAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY4NzgxIChjcmVhdCksIHVpZCAwIGlu dW1iZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoxNzow NCBsaW9uMSBrZXJuZWw6IHBpZCA2ODc4MSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NyBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY4NzgwIChydyksIHVpZCAwLCB3YXMga2ls bGVkOiBleGNlZWRlZCBtYXhpbXVtIENQVSBsaW1pdAo8MTE4PkphbiAxOSAxNDoyMToyOCBsaW9u MSBrZXJuZWw6IHBpZCA2ODc4MCAocncpLCB1aWQgMCwgd2FzIGtpbGxlZDogZXhjZWVkZWQgbWF4 aW11bSBDUFUgbGltaXQKPDM+cGlkIDY5NTUzIChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMTozNSBsaW9uMSBrZXJu ZWw6IHBpZCA2OTU1MyAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MjE6MzUgbGlvbjEga2VybmVsOiBwaWQgNjk1NTMg KG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwz PnBpZCA2OTU1MSAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MjE6MzYgbGlvbjEga2VybmVsOiBwaWQgNjk1NTEgKG1r ZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBp ZCA2OTU0MyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OSBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDExOD5KYW4gMTkgMTQ6MjE6MzcgbGlvbjEga2VybmVsOiBwaWQgNjk1NDMgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciAzODkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDE0OjIxOjM3IGxpb24xIGtlcm5lbDogcGlkIDY5NTQzIChjcmVhdCksIHVpZCAwIGludW1i ZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2RlcwotLU1vcmUtLSAgICAgICAgPDM+cGlk IDY5NTQzIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlu b2Rlcwo8Mz5waWQgNjk1NDQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTQgb24gL3Jvb3QvdG1w OiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjIxOjM5IGxpb24xIGtlcm5lbDogcGlkIDY5 NTQzIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rl cwo8MTE4PkphbiAxOSAxNDoyMTo0MSBsaW9uMSBrZXJuZWw6IHBpZCA2OTU0NCAoY3JlYXQpLCB1 aWQgMCBpbnVtYmVyIDM5NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKSgo8MTE4PmFuIDE5 IDE0OjIxOjM5IGxpb24xIGtlcm5lbDogcGlkIDY5NTQzIChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzg5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMTo0MSBsaW9u MSBrZXJuZWw6IHBpZCA2OTU0NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NCBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY5NTQ4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg4 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMTo0MyBsaW9uMSBr ZXJuZWw6IHBpZCA2OTU0OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OCBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDM+cGlkIDY5NTQ1IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc2IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMTo0NSBsaW9uMSBrZXJu ZWw6IHBpZCA2OTU0NSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU3NiBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDM+cGlkIDY5NTQ4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg4IG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMTo0NyBsaW9uMSBrZXJuZWw6 IHBpZCA2OTU0OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OCBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MjE6NDcgbGlvbjEga2VybmVsOiBwaWQgNjk1NDggKGNy ZWF0KSwgdWlkIDAgaW51bWJlciAzODggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBp ZCA2OTU0OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OCBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDM+cGlkIDY5NTQyIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkxIG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMTo0OSBsaW9uMSBrZXJuZWw6IHBpZCA2 OTU0OCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4OCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTQ6MjE6NDkgbGlvbjEga2VybmVsOiBwaWQgNjk1NDggKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzODggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDE0OjIxOjUxIGxpb24xIGtlcm5lbDogcGlkIDY5NTQyIChjcmVhdCksIHVpZCAwIGludW1iZXIg MzkxIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMTo1MSBsaW9u MSBrZXJuZWw6IHBpZCA2OTU0MiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5MSBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKLS1Nb3JlLS0gICAgICAgIDwzPnBpZCA2OTU0NSAoY3JlYXQpLCB1 aWQgMCBpbnVtYmVyIDU3NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkg MTQ6MjE6NTQgbGlvbjEga2VybmVsOiBwaWQgNjk1NDUgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1 NzYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjIxOjU0IGxpb24x IGtlcm5lbDogcGlkIDY5NTQ1IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc2IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNjk1NDIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTEg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjIxOjU2IGxpb24xIGtl cm5lbDogcGlkIDY5NTQyIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzkxIG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8Mz5waWQgNzAyOTMgKHJ3KSwgdWlkIDAgaW51bWJlciA2MTAgb24gL3Jv b3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDM+cGlkIDcwMzAwIChydyksIHVpZCAwIGludW1iZXIg NjA5IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwxMTg+SmFuIDE5IDE0OjIzOjM1IGxp b24xIGtlcm5lbDogcGlkIDcwMjkzIChydyksIHVpZCAwIGludW1iZXIgNjEwIG9uIC9yb290L3Rt cDogZmlsZXN5c3RlbSBmdWxsCjwxMTg+MTkgMTQ6MjM6MzUgbGlvbjEga2VybmVsOiBwaWQgNzAy OTMgKHJ3KSwgdWlkIDAgaW51bWJlciA2MTAgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwK PDExOD4xOSAxNDoyMzozNSBsaW9uMSBrZXJuZWw6IHBpZCA3MDI5MyAocncpLCB1aWQgMCBpbnVt YmVyIDYxMCBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8MTE4PkphbiAxOSAxNDoyMzoz NSBsaW9uMSBrZXJuZWw6IHBpZCA3MDMwMCAocncpLCB1aWQgMCBpbnVtYmVyIDYwOSBvbiAvcm9v dC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8MTE4PkphbiAxOSAxNDoyMzozNSBsaW9uMSBrZXJuZWw6 IHBpZCA3MDMwMCAocncpLCB1aWQgMCBpbnVtYmVyIDYwOSBvbiAvcm9vdC90bXA6IGZpbGVzeXN0 ZW0gZnVsbAo8Mz5waWQgNzAyODQgKHJ3KSwgdWlkIDAgaW51bWJlciA1NzYgb24gL3Jvb3QvdG1w OiBmaWxlc3lzdGVtIGZ1bGwKPDExOD5KYW4gMTkgMTQ6MjM6MzYgbGlvbjEga2VybmVsOiBwaWQg NzAyODQgKHJ3KSwgdWlkIDAgaW51bWJlciA1NzYgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1 bGwKPDM+cGlkIDcwMjc2IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTg2IG9uIC9yb290L3RtcDog b3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMzo0NCBsaW9uMSBrZXJuZWw6IHBpZCA3MDI3 NiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMK PDM+cGlkIDcwMjU4IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc4IG9uIC9yb290L3RtcDogb3V0 IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMzo0NiBsaW9uMSBrZXJuZWw6IHBpZCA3MDI1OCAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU3OCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+ cGlkIDcwMjkwIChjcmVhdCksIHVpZCAwIGludW1iZXIgNDA0IG9uIC9yb290L3RtcDogb3V0IG9m IGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyMzo0OSBsaW9uMSBrZXJuZWw6IHBpZCA3MDI5MCAoY3Jl YXQpLCB1aWQgMCBpbnVtYmVyIDQwNCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKLS1Nb3Jl LS0gICAgICAgIDwzPnBpZCA3MDI3NiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NiBvbiAvcm9v dC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MjM6NTQgbGlvbjEga2VybmVsOiBw aWQgNzAyNzYgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODYgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwzPnBpZCA3MDI2MyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDQwMCBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MjM6NTUgbGlvbjEga2VybmVsOiBwaWQg NzAyNjMgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA0MDAgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwzPnBpZCA3MDI5NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDYwMCBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6MjM6NTYgbGlvbjEga2VybmVsOiBwaWQgNzAy OTQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA2MDAgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwxMTg+SmFuIDE5IDE0OjIzOjU2IGxpb24xIGtlcm5lbDogcGlkIDcwMjk0IChjcmVhdCksIHVp ZCAwIGludW1iZXIgNjAwIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzAyNTYg KGNyZWF0KSwgdWlkIDAgaW51bWJlciA1Nzkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwx MTg+SmFuIDE5IDE0OjIzOjU4IGxpb24xIGtlcm5lbDogcGlkIDcwMjU2IChjcmVhdCksIHVpZCAw IGludW1iZXIgNTc5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzAyODEgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciA1OTEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+ SmFuIDE5IDE0OjI0OjAwIGxpb24xIGtlcm5lbDogcGlkIDcwMjgxIChjcmVhdCksIHVpZCAwIGlu dW1iZXIgNTkxIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzAyNTYgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciA1Nzkgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDE0OjI0OjAzIGxpb24xIGtlcm5lbDogcGlkIDcwMjU2IChjcmVhdCksIHVpZCAwIGludW1i ZXIgNTc5IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzAyODYgKGNyZWF0KSwg dWlkIDAgaW51bWJlciA0MDMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDE0OjI0OjA0IGxpb24xIGtlcm5lbDogcGlkIDcwMjg2IChjcmVhdCksIHVpZCAwIGludW1iZXIg NDAzIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzAyODEgKGNyZWF0KSwgdWlk IDAgaW51bWJlciA1OTEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0 OjI0OjA1IGxpb24xIGtlcm5lbDogcGlkIDcwMjgxIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTkx IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzAyNTkgKGNyZWF0KSwgdWlkIDAg aW51bWJlciA1ODIgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjI0 OjA2IGxpb24xIGtlcm5lbDogcGlkIDcwMjU5IChjcmVhdCksIHVpZCAwIGludW1iZXIgNTgyIG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzEwNDEgKGNyZWF0KSwgdWlkIDAgaW51 bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCi0tTW9yZS0tICAgICAgICA8MTE4 PkphbiAxOSAxNDoyNzoyNCBsaW9uMSBrZXJuZWw6IHBpZCA3MTA0MSAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6Mjc6 MjQgbGlvbjEga2VybmVsOiBwaWQgNzEwNDEgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODYgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3MTAzOSAoY3JlYXQpLCB1aWQgMCBpbnVt YmVyIDM4NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6Mjc6MjYg bGlvbjEga2VybmVsOiBwaWQgNzEwMzkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jv b3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3MTAzOSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVy IDM4NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDcxMDM5IChjcmVhdCksIHVp ZCAwIGludW1iZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzEwMzkg KGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwz PnBpZCA3MTAzOSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NyBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDM+cGlkIDcxMDM5IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg3IG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzEwMzkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAz ODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3MTAzOSAoY3JlYXQpLCB1aWQg MCBpbnVtYmVyIDM4NyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDcxMDM5IChj cmVhdCksIHVpZCAwIGludW1iZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5w aWQgNzEwMzkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwxMTg+SmFuIDE5IDE0OjI3OjQ1IGxpb24xIGxhc3QgbWVzc2FnZSByZXBlYXRlZCA5 IHRpbWVzCjwzPnBpZCA3MTcyNyAocncpLCB1aWQgMCBpbnVtYmVyIDQwMyBvbiAvcm9vdC90bXA6 IGZpbGVzeXN0ZW0gZnVsbAo8MTE4PkphbiAxOSAxNDoyOToyOCBsaW9uMSBrZXJuZWw6IHBpZCA3 MTcyNyAocncpLCB1aWQgMCBpbnVtYmVyIDQwMyBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVs bAo8Mz5waWQgNzE3NDQgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjI5OjMyIGxpb24xIGtlcm5lbDogcGlkIDcxNzQ0 IChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8 Mz5waWQgNzE3ODEgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODEgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjI5OjMzIGxpb24xIGtlcm5lbDogcGlkIDcxNzgxIChj cmVhdCksIHVpZCAwIGludW1iZXIgNTgxIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2RlcwotLU1v cmUtLSAgICAgICAgPDM+cGlkIDcxNzI5IChydyksIHVpZCAwIGludW1iZXIgMzkxIG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDoyOTozNSBsaW9uMSBrZXJuZWw6IHBp ZCA3MTcyOSAocncpLCB1aWQgMCBpbnVtYmVyIDM5MSBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDM+cGlkIDcxNzI4IChydyksIHVpZCAwIGludW1iZXIgMjA3IG9uIC9yb290L3RtcDogZmls ZXN5c3RlbSBmdWxsCjwxMTg+SmFuIDE5IDE0OjI5OjM2IGxpb24xIGtlcm5lbDogcGlkIDcxNzI4 IChydyksIHVpZCAwIGludW1iZXIgMjA3IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwz PnBpZCA3MjQ5MCAocncpLCB1aWQgMCwgd2FzIGtpbGxlZDogZXhjZWVkZWQgbWF4aW11bSBDUFUg bGltaXQKPDExOD5KYW4gMTkgMTQ6MzY6MTggbGlvbjEga2VybmVsOiBwaWQgNzI0OTAgKHJ3KSwg dWlkIDAsIHdhcyBraWxsZWQ6IGV4Y2VlZGVkIG1heGltdW0gQ1BVIGxpbWl0CjwzPnBpZCA3MzIz NyAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMK PDExOD5KYW4gMTkgMTQ6MzY6MzAgbGlvbjEga2VybmVsOiBwaWQgNzMyMzcgKG1rZGlyKSwgdWlk IDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3Mzk3MCAo cncpLCB1aWQgMCBpbnVtYmVyIDQwMyBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8MTE4 PkphbiAxOSAxNDozODoyOSBsaW9uMSBrZXJuZWw6IHBpZCA3Mzk3MCAocncpLCB1aWQgMCBpbnVt YmVyIDQwMyBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8Mz5waWQgNzM5NDUgKHJ3KSwg dWlkIDAgaW51bWJlciA1OTYgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDM+cGlkIDcz OTYyIChydyksIHVpZCAwIGludW1iZXIgNTk2IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxs CjwxMTg+SmFuIDE5IDE0OjM4OjMwIGxpb24xIGtlcm5lbDogcGlkIDczOTQ1IChydyksIHVpZCAw IGludW1iZXIgNTk2IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwxMTg+MTkgMTQ6Mzg6 MzAgbGlvbjEga2VybmVsOiBwaWQgNzM5NDUgKHJ3KSwgdWlkIDAgaW51bWJlciA1OTYgb24gL3Jv b3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDExOD4xOSAxNDozODozMCBsaW9uMSBrZXJuZWw6IHBp ZCA3Mzk0NSAocncpLCB1aWQgMCBpbnVtYmVyIDU5NiBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0g ZnVsbAo8MTE4PkphbiAxOSAxNDozODozMCBsaW9uMSBrZXJuZWw6IHBpZCA3Mzk2MiAocncpLCB1 aWQgMCBpbnVtYmVyIDU5NiBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8MTE4PkphbiAx OSAxNDozODozMCBsaW9uMSBrZXJuZWw6IHBpZCA3Mzk2MiAocncpLCB1aWQgMCBpbnVtYmVyIDU5 NiBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0gZnVsbAo8Mz5waWQgNzM5MjggKHJ3KSwgdWlkIDAg aW51bWJlciA0MDYgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDExOD5KYW4gMTkgMTQ6 Mzg6MzUgbGlvbjEga2VybmVsOiBwaWQgNzM5MjggKHJ3KSwgdWlkIDAgaW51bWJlciA0MDYgb24g L3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDM+cGlkIDczOTU4IChjcmVhdCksIHVpZCAwIGlu dW1iZXIgMzg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2RlcwotLU1vcmUtLSAgICAgICAgPDEx OD5KYW4gMTkgMTQ6Mzg6MzUgbGlvbjEga2VybmVsOiBwaWQgNzM5NTggKGNyZWF0KSwgdWlkIDAg aW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjM4 OjM1IGxpb24xIGtlcm5lbDogcGlkIDczOTU4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg3IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzM5NzYgKG1rZGlyKSwgdWlkIDAgaW51 bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjM4OjQw IGxpb24xIGtlcm5lbDogcGlkIDczOTc2IChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDozODo0MCBsaW9uMSBrZXJuZWw6 IHBpZCA3Mzk3NiAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDM+cGlkIDczOTY2IChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290 L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDozODo0MSBsaW9uMSBrZXJuZWw6IHBp ZCA3Mzk2NiAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDM+cGlkIDczOTYzIChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDozODo0MiBsaW9uMSBrZXJuZWw6IHBpZCA3 Mzk2MyAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTQ6Mzg6NDIgbGlvbjEga2VybmVsOiBwaWQgNzM5NjMgKG1rZGlyKSwg dWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3Mzk4 MiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMK PDExOD5KYW4gMTkgMTQ6Mzg6NDQgbGlvbjEga2VybmVsOiBwaWQgNzM5ODIgKGNyZWF0KSwgdWlk IDAgaW51bWJlciA1ODIgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3Mzk2OSAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDEx OD5KYW4gMTkgMTQ6Mzg6NDYgbGlvbjEga2VybmVsOiBwaWQgNzM5NjkgKGNyZWF0KSwgdWlkIDAg aW51bWJlciA1ODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+YW4gMTkgMTQ6Mzg6 NDYgbGlvbjEga2VybmVsOiBwaWQgNzM5NjkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODYgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+YW4gMTkgMTQ6Mzg6NDYgbGlvbjEga2VybmVs OiBwaWQgNzM5NjkgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODYgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwzPnBpZCA3Mzk4NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NyBvbiAvcm9v dC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6Mzg6NDggbGlvbjEga2VybmVsOiBw aWQgNzM5ODQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODcgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwxMTg+SmFuIDE5IDE0OjM4OjQ4IGxpb24xIGtlcm5lbDogcGlkIDczOTg0IChjcmVh dCksIHVpZCAwIGludW1iZXIgNTg3IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQg NzM5ODMgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCi0tTW9yZS0tICAgICAgICA8MTE4PkphbiAxOSAxNDozODo1MCBsaW9uMSBrZXJuZWw6IHBp ZCA3Mzk4MyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4NSBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDM+cGlkIDczOTgyIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTgyIG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDozODo1MiBsaW9uMSBrZXJuZWw6IHBpZCA3 Mzk4MiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9k ZXMKPDExOD5KYW4gMTkgMTQ6Mzg6NTIgbGlvbjEga2VybmVsOiBwaWQgNzM5ODIgKGNyZWF0KSwg dWlkIDAgaW51bWJlciA1ODIgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3NDcw MyAocncpLCB1aWQgMCwgd2FzIGtpbGxlZDogZXhjZWVkZWQgbWF4aW11bSBDUFUgbGltaXQKPDEx OD5KYW4gMTkgMTQ6NDQ6NDUgbGlvbjEga2VybmVsOiBwaWQgNzQ3MDMgKHJ3KSwgdWlkIDAsIHdh cyBraWxsZWQ6IGV4Y2VlZGVkIG1heGltdW0gQ1BVIGxpbWl0CjwzPnBpZCA3NTQwMSAobWtkaXIp LCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4g MTkgMTQ6NDU6MDcgbGlvbjEga2VybmVsOiBwaWQgNzU0MDEgKG1rZGlyKSwgdWlkIDAgaW51bWJl ciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3NTQxMiAoY3JlYXQpLCB1 aWQgMCBpbnVtYmVyIDU3NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkg MTQ6NDU6MTAgbGlvbjEga2VybmVsOiBwaWQgNzU0MTIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1 NzYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjQ1OjEwIGxpb24x IGtlcm5lbDogcGlkIDc1NDEyIChjcmVhdCksIHVpZCAwIGludW1iZXIgNTc2IG9uIC9yb290L3Rt cDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzU0MTIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1NzYg b24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3NTQwOCAoY3JlYXQpLCB1aWQgMCBp bnVtYmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6NDU6 MTIgbGlvbjEga2VybmVsOiBwaWQgNzU0MTIgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1NzYgb24g L3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjQ1OjE0IGxpb24xIGtlcm5l bDogcGlkIDc1NDA4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg2IG9uIC9yb290L3RtcDogb3V0 IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDo0NToxMiBsaW9uMSBrZXJuZWw6IHBpZCA3NTQxMiAo Y3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU3NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDEx OD5KYW4gMTkgMTQ6NDU6MTQgbGlvbjEga2VybmVsOiBwaWQgNzU0MDggKGNyZWF0KSwgdWlkIDAg aW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBpZCA3NTQwOCAoY3Jl YXQpLCB1aWQgMCBpbnVtYmVyIDM4NiBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlk IDc1NDA4IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg2IG9uIC9yb290L3RtcDogb3V0IG9mIGlu b2Rlcwo8Mz5waWQgNzU0MDggKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1w OiBvdXQgb2YgaW5vZGVzCi0tTW9yZS0tICAgICAgICA8Mz5waWQgNzU0MTAgKGNyZWF0KSwgdWlk IDAgaW51bWJlciAzODcgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0 OjQ1OjIwIGxpb24xIGxhc3QgbWVzc2FnZSByZXBlYXRlZCAzIHRpbWVzCjwxMTg+SmFuIDE5IDE0 OjQ1OjIyIGxpb24xIGtlcm5lbDogcGlkIDc1NDEwIChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg3 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDo0NToyMCBsaW9uMSBs YXN0IG1lc3NhZ2UgcmVwZWF0ZWQgMyB0aW1lcwo8MTE4PkphbiAxOSAxNDo0NToyMiBsaW9uMSBr ZXJuZWw6IHBpZCA3NTQxMCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NyBvbiAvcm9vdC90bXA6 IG91dCBvZiBpbm9kZXMKPDM+cGlkIDc2MTMwIChydyksIHVpZCAwIGludW1iZXIgNDAwIG9uIC9y b290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwzPnBpZCA3NjEzNSAobWtkaXIpLCB1aWQgMCBpbnVt YmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6NDc6NDgg bGlvbjEga2VybmVsOiBwaWQgNzYxMzAgKHJ3KSwgdWlkIDAgaW51bWJlciA0MDAgb24gL3Jvb3Qv dG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDExOD5KYW4gMTkgMTQ6NDc6NDggbGlvbjEga2VybmVsOiBw aWQgNzYxMzUgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwzPnBpZCA3NjE2MyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MSBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6NDc6NTMgbGlvbjEga2VybmVsOiBwaWQg NzYxNjMgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5v ZGVzCjwxMTg+SmFuIDE5IDE0OjQ3OjUzIGxpb24xIGtlcm5lbDogcGlkIDc2MTYzIChjcmVhdCks IHVpZCAwIGludW1iZXIgNTgxIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzYx NjMgKGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwzPnBpZCA3NjE2MiAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU3NiBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6NDc6NTUgbGlvbjEga2VybmVsOiBwaWQgNzYxNjMg KGNyZWF0KSwgdWlkIDAgaW51bWJlciA1ODEgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwx MTg+SmFuIDE5IDE0OjQ3OjU3IGxpb24xIGtlcm5lbDogcGlkIDc2MTYyIChjcmVhdCksIHVpZCAw IGludW1iZXIgNTc2IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzYxNDYgKHJ3 KSwgdWlkIDAgaW51bWJlciA0MDEgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKPDM+cGlk IDc2MTQyIChydyksIHVpZCAwIGludW1iZXIgNDA5IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBm dWxsCjwxMTg+SmFuIDE5IDE0OjQ3OjU4IGxpb24xIGtlcm5lbDogcGlkIDc2MTQ2IChydyksIHVp ZCAwIGludW1iZXIgNDAxIG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCjwxMTg+SmFuIDE5 IDE0OjQ3OjU4IGxpb24xIGtlcm5lbDogcGlkIDc2MTQyIChydyksIHVpZCAwIGludW1iZXIgNDA5 IG9uIC9yb290L3RtcDogZmlsZXN5c3RlbSBmdWxsCi0tTW9yZS0tICAgICAgICA8Mz5waWQgNzY5 MTYgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwxMTg+SmFuIDE5IDE0OjUwOjU2IGxpb24xIGtlcm5lbDogcGlkIDc2OTE2IChta2RpciksIHVp ZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzY5Mjcg KGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwx MTg+SmFuIDE5IDE0OjUwOjU5IGxpb24xIGtlcm5lbDogcGlkIDc2OTI3IChjcmVhdCksIHVpZCAw IGludW1iZXIgMzg1IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzY5MDkgKHJ3 KSwgdWlkIDAgaW51bWJlciAzODggb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDE0OjUxOjAwIGxpb24xIGtlcm5lbDogcGlkIDc2OTA5IChydyksIHVpZCAwIGludW1iZXIg Mzg4IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzY5NDcgKG1rZGlyKSwgdWlk IDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0 OjUxOjAxIGxpb24xIGtlcm5lbDogcGlkIDc2OTQ3IChta2RpciksIHVpZCAwIGludW1iZXIgMzg0 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzY5MjcgKGNyZWF0KSwgdWlkIDAg aW51bWJlciAzODUgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjUx OjAzIGxpb24xIGtlcm5lbDogcGlkIDc2OTI3IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg1IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDo1MTowMyBsaW9uMSBrZXJu ZWw6IHBpZCA3NjkyNyAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NSBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDM+cGlkIDc2OTQ0IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzk0IG9uIC9y b290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDo1MTowNSBsaW9uMSBrZXJuZWw6 IHBpZCA3Njk0NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NCBvbiAvcm9vdC90bXA6IG91dCBv ZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6NTE6MDUgbGlvbjEga2VybmVsOiBwaWQgNzY5NDQgKGNy ZWF0KSwgdWlkIDAgaW51bWJlciAzOTQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBp ZCA3NjkzNCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5MyBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDExOD5KYW4gMTkgMTQ6NTE6MDcgbGlvbjEga2VybmVsOiBwaWQgNzY5MzQgKGNyZWF0 KSwgdWlkIDAgaW51bWJlciAzOTMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDE0OjUxOjA3IGxpb24xIGtlcm5lbDogcGlkIDc2OTM0IChjcmVhdCksIHVpZCAwIGludW1i ZXIgMzkzIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzY5NDQgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzOTQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDE0OjUxOjA5IGxpb24xIGtlcm5lbDogcGlkIDc2OTQ0IChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzk0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDo1MTowOSBsaW9u MSBrZXJuZWw6IHBpZCA3Njk0NCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5NCBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKLS1Nb3JlLS0gICAgICAgIDwzPnBpZCA3NjkzNCAoY3JlYXQpLCB1 aWQgMCBpbnVtYmVyIDM5MyBvbiAvcm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkg MTQ6NTE6MTEgbGlvbjEga2VybmVsOiBwaWQgNzY5MzQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAz OTMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjw8Mz5wMz5waWlkZCAgNzc2OTY5MjM3NCAo IChjY3JlYXRyKWUsYSB0dWlkKSAsIHUwaWQgIDBpIG5pdW5tdWJtZXIgYmVyIDM5MyBvM24gOC81 IG9uciBvL29ydG8vb3R0bS9wdDptIHA6IG9vdXR1IHRvIGZvIGZpIG5pb25kb2Vkc2UKcwo8Mz4K PDExOD5KYW4gMTkgMTQ6NTE6MTMgbGlvbjEga2VybmVsOgo8MTE4PkphbiAxOSAxNDo1MToxMyBs aW9uMSBrZXJuZWw6CjwzPnBpZCA3NjkzNCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM5MyBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6NTE6MTUgbGlvbjEga2VybmVs OiBwaWQgNzY5MzQgKGNyZWF0KSwgdWlkIDAgaW51bWJlciAzOTMgb24gL3Jvb3QvdG1wOiBvdXQg b2YgaW5vZGVzCjwzPnBpZCA3NzY1OCAocncpLCB1aWQgMCBpbnVtYmVyIDM5OSBvbiAvcm9vdC90 bXA6IGZpbGVzeXN0ZW0gZnVsbAo8MTE4PkphbiAxOSAxNDo1NDowMCBsaW9uMSBrZXJuZWw6IHBp ZCA3NzY1OCAocncpLCB1aWQgMCBpbnVtYmVyIDM5OSBvbiAvcm9vdC90bXA6IGZpbGVzeXN0ZW0g ZnVsbAo8Mz5waWQgNzc2ODMgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1w OiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjU0OjA2IGxpb24xIGtlcm5lbDogcGlkIDc3 NjgzIChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rl cwo8Mz5waWQgNzc2NzQgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBv dXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjU0OjA3IGxpb24xIGtlcm5lbDogcGlkIDc3Njc0 IChta2RpciksIHVpZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8 Mz5waWQgNzc2NjUgKHJ3KSwgdWlkIDAgaW51bWJlciAzOTQgb24gL3Jvb3QvdG1wOiBvdXQgb2Yg aW5vZGVzCjwxMTg+SmFuIDE5IDE0OjU0OjA5IGxpb24xIGtlcm5lbDogcGlkIDc3NjY1IChydyks IHVpZCAwIGludW1iZXIgMzk0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzgz ODEgKG1rZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVz CjwxMTg+SmFuIDE5IDE0OjU2OjAyIGxpb24xIGtlcm5lbDogcGlkIDc4MzgxIChta2RpciksIHVp ZCAwIGludW1iZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzkwODIg KHJ3KSwgdWlkIDAgaW51bWJlciA0MDIgb24gL3Jvb3QvdG1wOiBmaWxlc3lzdGVtIGZ1bGwKLS1N b3JlLS0gICAgICAgIDwzPnBpZCA3OTA5MSAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAv cm9vdC90bXA6IG91dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6NTg6MDUgbGlvbjEga2VybmVs OiBwaWQgNzkwODIgKHJ3KSwgdWlkIDAgaW51bWJlciA0MDIgb24gL3Jvb3QvdG1wOiBmaWxlc3lz dGVtIGZ1bGwKPDExOD5KYW4gMTkgMTQ6NTg6MDUgbGlvbjEga2VybmVsOiBwaWQgNzkwOTEgKG1r ZGlyKSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwzPnBp ZCA3OTA5NCAobWtkaXIpLCB1aWQgMCBpbnVtYmVyIDM4NCBvbiAvcm9vdC90bXA6IG91dCBvZiBp bm9kZXMKPDExOD5KYW4gMTkgMTQ6NTg6MDcgbGlvbjEga2VybmVsOiBwaWQgNzkwOTQgKG1rZGly KSwgdWlkIDAgaW51bWJlciAzODQgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFu IDE5IDE0OjU4OjA3IGxpb24xIGtlcm5lbDogcGlkIDc5MDk0IChta2RpciksIHVpZCAwIGludW1i ZXIgMzg0IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzkwOTUgKGNyZWF0KSwg dWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5 IDE0OjU4OjExIGxpb24xIGtlcm5lbDogcGlkIDc5MDk1IChjcmVhdCksIHVpZCAwIGludW1iZXIg Mzg2IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDo1ODoxMSBsaW9u MSBrZXJuZWw6IHBpZCA3OTA5NSAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDM4NiBvbiAvcm9vdC90 bXA6IG91dCBvZiBpbm9kZXMKPDM+cGlkIDc5MDk1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg2 IG9uIC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8Mz5waWQgNzkxMjQgKGNyZWF0KSwgdWlkIDAg aW51bWJlciA1ODMgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwxMTg+SmFuIDE5IDE0OjU4 OjEzIGxpb24xIGtlcm5lbDogcGlkIDc5MDk1IChjcmVhdCksIHVpZCAwIGludW1iZXIgMzg2IG9u IC9yb290L3RtcDogb3V0IG9mIGlub2Rlcwo8MTE4PkphbiAxOSAxNDo1ODoxNiBsaW9uMSBrZXJu ZWw6IHBpZCA3OTEyNCAoY3JlYXQpLCB1aWQgMCBpbnVtYmVyIDU4MyBvbiAvcm9vdC90bXA6IG91 dCBvZiBpbm9kZXMKPDExOD5KYW4gMTkgMTQ6NTg6MTMgbGlvbjEga2VybmVsOiBwaWQgNzkwOTUg KGNyZWF0KSwgdWlkIDAgaW51bWJlciAzODYgb24gL3Jvb3QvdG1wOiBvdXQgb2YgaW5vZGVzCjwx MTg+SmFuIDE5IDE0OjU4OjE2IGxpb24xIGtlcm5lbDogcGlkIDc5MTI0IChjcmVhdCksIHVpZCAw IGludW1iZXIgNTgzIG9uIC9yb290L3RtcDogb3V0IG9mIGlub2RlcwoKZGI+cmVzZXQKY3B1X3Jl c2V0OiBSZXN0YXJ0aW5nIEJTUApjcHVfcmVzZXRfcHJveHk6IFN0b3BwZWQgQ1BVIDEKW2Rpc2Nv bm5lY3RdCgpTY3JpcHQgZG9uZSBvbiBUdWUgSmFuIDE5IDEzOjE5OjAwIDIwMTAK --000e0cd1ff3e9073f6047d93971d-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 13:34:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7492D1065692; Wed, 20 Jan 2010 13:34:16 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 00A1E8FC1F; Wed, 20 Jan 2010 13:34:16 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 02813FC43; Wed, 20 Jan 2010 14:34:14 +0100 (CET) Received: from meribel.restart.bel (meribel.restart.bel [IPv6:2001:41d0:2:2d29:1:8::]) (authenticated bits=0) by restart.be (8.14.4/8.14.4) with ESMTP id o0KDY7AH037848 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 14:34:08 +0100 (CET) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be o0KDY7AH037848 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1263994451; bh=uVHv5by+HJopdtcAk+ij7iaJpsb9Eztlw3KOmlqRwd0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lti5mxa6eF3Bs1wNK2rCNGI54UNrnE/IaHYdJRJLr/magAlkiekLeE7VR6OqjKxf4 ThnXg7sWS2ja7Ta8WmpHw== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be o0KDY7AH037848 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=1IbvqdhW+71pCj9JYKR30rFvAE4t7J8xGfySEH4m/ufnOyI434R4Udv450EzmHQem JCwTHFoAopDepFnq44f3w== Message-ID: <4B57064F.9060704@restart.be> Date: Wed, 20 Jan 2010 14:34:07 +0100 From: Henri Hennebert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20091220 Thunderbird/3.0 MIME-Version: 1.0 To: Alexander Motin References: <4B55D9D4.1000008@FreeBSD.org> In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2001:41d0:2:2d29:1:1:: Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 13:34:16 -0000 On 01/19/2010 17:12, Alexander Motin wrote: > Hi. > > I've made a patch, that should solve set of problems of CAM ATA and CAM > generally. I would like to ask for testing and feedback. > > What patch does: > - It unifies bus reset/probe sequence. Whenever bus attached at boot or > later, CAM will automatically reset and scan it. It allows to remove > duplicate code from many drivers. > - Any bus, attached before CAM completed it's boot-time initialization, > will equally join to the process, delaying boot if needed. > - New kern.cam.boot_delay loader tunable should help controllers that > are still unable to register their buses in time (such as slow USB/ > PCCard/ CardBus devices). With kern.cam.boot_delay=15000 (I suppose that it was in ms) I can now boot from my sim card reader. Thanks Henri > - To allow synchronization between different CAM levels, concept of > requests priorities was extended. Priorities now split between several > "run levels". Device can be freezed at specified level, allowing higher > priority requests to pass. For example, no payload requests allowed, > until PMP driver enable port. ATA XPT negotiate transfer parameters, > periph driver configure caching and so on. > - Frozen requests are no more counted by request allocation scheduler. > It fixes deadlocks, when frozen low priority payload requests occupying > slots, required by higher levels to manage theit execution. > - Two last changes were holding proper ATA reinitialization and error > recovery implementation. Now it is done: SATA controllers and Port > Multipliers now implement automatic hot-plug and should correctly > recover from timeouts and bus resets. > > Patch can be found here: > http://people.freebsd.org/~mav/cam-ata.20100119.patch > > Feedback as always welcome. > From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 13:43:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54084106566B for ; Wed, 20 Jan 2010 13:43:36 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id D1F408FC23 for ; Wed, 20 Jan 2010 13:43:35 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so1458295fga.13 for ; Wed, 20 Jan 2010 05:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=Q1YDPe+fZj8TG/WdFBHxF2b/tuuvo0a7eTqFHTVSqww=; b=PEFMiEIkgdGi+FyEvPc15xduyaS2EKws6fNGbGTBiV83aaIGXSWi97mwPSfryfIzRM BZu4VqIb9Rumb2gJlVAZJ76hlCl9dr0biEDOZsMP8lBW8RO77L/3/u3aHbJKMJvUeFur mRvvxemSTkqmWyaHQFOw/Qh7qdmiwi17ecARQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; b=R5qLoHPY3wKrM0BI26BcqmoyqHITl/YFpPqMwa8+k/JQThELpPtrXVQ4EalluIZrzh Te3RitN0Xn8RCdhtAD4F5uTnqxdmn6Y37GEqPSE9sc2LBKFUib5x4fQL7jeWTddU1NYO j1j33YPgt9PwD+nMrjp9jT7wB6KookNSZtiWc= Received: by 10.87.58.27 with SMTP id l27mr213602fgk.4.1263995014706; Wed, 20 Jan 2010 05:43:34 -0800 (PST) Received: from dragon.dg ([41.216.197.17]) by mx.google.com with ESMTPS id 3sm15234755fge.16.2010.01.20.05.43.12 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Jan 2010 05:43:33 -0800 (PST) From: David Naylor Organization: Private To: freebsd-current@freebsd.org Date: Wed, 20 Jan 2010 15:43:12 +0200 User-Agent: KMail/1.12.3 (FreeBSD/8.0-STABLE; KDE/4.3.3; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1543202.6aWtivkye5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001201543.15818.naylor.b.david@gmail.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: stacked unionfs freeze and crash FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 13:43:36 -0000 --nextPart1543202.6aWtivkye5 Content-Type: multipart/mixed; boundary="Boundary-01=_whwVLStpy8/R2mZ" Content-Transfer-Encoding: 7bit --Boundary-01=_whwVLStpy8/R2mZ Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, The attached script, that uses stacked unionfs, causes FreeBSD-9 (cvsup=20 yesterday) to freeze and FreeBSD-8 (cvsup two days ago) to crash: =20 =46atal double fault rip-0xffffffff81e4c1 rsp=3D0xffffff80b133ef50 rbp=3D0xffffff80b133f150 cupid =3D 2; apic id =3D 02 panic: double fault cpuid =3D 2 uptime: 1h44m35s cannot dump. Device not defined or unavailable Both systems use the stock GENERIC kernel, i.e. -9 had full diagnostics bui= lt=20 in (and was run under VirtualBox) and -8 had no diagnostics (and was run=20 native). =20 A LOR is produces prior to freezing under -9 (quiet a time prior). See=20 kern/141950. =20 The script uses unionfs to build ports (in an attempt to create a tinderbox= =20 without the need to delete and/or extract packages). To use the script to: # mkdir /tmp/localbase /tmp/builddir # env LOCALBASE=3D/tmp/localbase BUILDDIR=3D/tmp/builddir ./ports-union-bui= lder.sh This will try build everything for x11/xorg. =20 Is it possible that VirtualBox is interfering in getting usable diagnostics= =20 for -9 and how can I setup a dump device for -8. Currently I have: # swapinfo Device 1K-blocks Used Avail Capacity /dev/ad4s1b 8388608 0 8388608 0% /dev/ad8s1b 8388608 0 8388608 0% Total 16777216 0 16777216 0% Any advice? Regards --Boundary-01=_whwVLStpy8/R2mZ-- --nextPart1543202.6aWtivkye5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktXCHMACgkQUaaFgP9pFrLhjACgigVuFYBZp2G4auW4hgL5l/ea DXcAn2R6SV+tSDfGXK6UepguNtovQ83Y =O0Hj -----END PGP SIGNATURE----- --nextPart1543202.6aWtivkye5-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 13:55:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F89A1065670; Wed, 20 Jan 2010 13:55:26 +0000 (UTC) (envelope-from james-freebsd-current@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 462D68FC0A; Wed, 20 Jan 2010 13:55:25 +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 o0KDtOJK077360; Wed, 20 Jan 2010 07:55:24 -0600 (CST) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@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:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Eu1Q5A8hlZo1S7KQne6fNv8lmRHlSXQhzhJ7eSdLdzQyr6HDgzZU5Qb/XEqOaR/DR zOiSNu6lbNxngAipJufSD88/jQKp5PYn9UvvUKUrU2bZlJehOxBD9tW9XB5OpxyyVoV JG+JmjiSFGIhulVpyx+aueV/V5Ory2II+uH1BKQ= Message-ID: <4B570B4C.9000203@jrv.org> Date: Wed, 20 Jan 2010 07:55:24 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 References: <4B55D9D4.1000008@FreeBSD.org> <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> In-Reply-To: <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD-Current Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 13:55:26 -0000 Scott Long wrote: > I've fought many times against delay values like this. They never > work well enough. At some point I hope to add support for staggered spin-ups, perhaps a loader.conf setting for people with more than 20-30 disks. At the 100-120 disk level it seems unlikely that any reasonable fixed delay would be reasonable. From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 14:02:20 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AC65106566C for ; Wed, 20 Jan 2010 14:02:20 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 813F08FC1B for ; Wed, 20 Jan 2010 14:02:19 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0KE21Wp010265; Wed, 20 Jan 2010 15:02:17 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0KE21oc010264; Wed, 20 Jan 2010 15:02:01 +0100 (CET) (envelope-from olli) Date: Wed, 20 Jan 2010 15:02:01 +0100 (CET) Message-Id: <201001201402.o0KE21oc010264@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com In-Reply-To: <20100119193743.GC6201@michelle.cdnetworks.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 20 Jan 2010 15:02:17 +0100 (CET) Cc: Subject: Re: bce(4) on IBM BladeCenter HS22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 14:02:20 -0000 Pyun YongHyeon wrote: > On Tue, Jan 19, 2010 at 08:23:13PM +0100, Oliver Fromme wrote: > > Pyun YongHyeon wrote: > > > Thanks for the detailed information. I vaguely guess bce(4) used > > > wrong PHY address for controller. How about attached patch? > > > The patch just reset the PHY address to 1, it's not correct way to > > > set it but just wants to know whether brgphy(4) is attached to the > > > PHY. > > > > Unfortunately, it produces almost the same output, > > except the registers now read 0xffff instead of 0x0000: > > > :-( > > Ok, could you remove the safety belt of bce_miibus_read_reg() to > allow accessing all PHY address? You can comment out > sc->bce_phy_addr check in bce_miibus_read_reg() to allow > mii_phy_probe try to read all 32 possible PHY addresses. > Does mii(4) probe manage to read something? No luck, I'm afraid (as was expected). No PHY can be found on any of the addresses. The PHY addresses 2 and 31 return 0x0000, all others return 0xffff. While debugging and searching I found this message from David Christensen: http://lists.freebsd.org/pipermail/freebsd-net/2009-August/022648.html It seems that the PHY on the 5709S is different from the others and requires some non-trivial code to be written. :-( I posted a follow-up in the freebsd-net list and copied David. Maybe he has some news. This whole issue is quite important. IBM is phasing out the previous blade generation (HS21), so all new blades are HS22 which have the BCM5709S interfaces. As it stands now, FreeBSD cannot be used on IBM blades. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot)." -- Terry Lambert, FreeBSD-hackers mailing list. From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 15:28:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F047810656A8 for ; Wed, 20 Jan 2010 15:28:23 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 87A8A8FC27 for ; Wed, 20 Jan 2010 15:28:23 +0000 (UTC) Received: from [195.4.92.26] (helo=16.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NXcTm-0004AI-Bs; Wed, 20 Jan 2010 16:28:22 +0100 Received: from p57ae23bf.dip0.t-ipconnect.de ([87.174.35.191]:39878 helo=ernst.jennejohn.org) by 16.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NXcTl-0004cG-Rf; Wed, 20 Jan 2010 16:28:22 +0100 Date: Wed, 20 Jan 2010 16:28:21 +0100 From: Gary Jennejohn To: David Naylor Message-ID: <20100120162821.3f53af6a@ernst.jennejohn.org> In-Reply-To: <201001201543.15818.naylor.b.david@gmail.com> References: <201001201543.15818.naylor.b.david@gmail.com> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: stacked unionfs freeze and crash FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 15:28:24 -0000 On Wed, 20 Jan 2010 15:43:12 +0200 David Naylor wrote: > Hi, > > The attached script, that uses stacked unionfs, causes FreeBSD-9 (cvsup > yesterday) to freeze and FreeBSD-8 (cvsup two days ago) to crash: > > Fatal double fault > rip-0xffffffff81e4c1 > rsp=0xffffff80b133ef50 > rbp=0xffffff80b133f150 > cupid = 2; apic id = 02 > panic: double fault > cpuid = 2 > uptime: 1h44m35s > cannot dump. Device not defined or unavailable > > > Both systems use the stock GENERIC kernel, i.e. -9 had full diagnostics built > in (and was run under VirtualBox) and -8 had no diagnostics (and was run > native). > > A LOR is produces prior to freezing under -9 (quiet a time prior). See > kern/141950. > > The script uses unionfs to build ports (in an attempt to create a tinderbox > without the need to delete and/or extract packages). To use the script to: > > # mkdir /tmp/localbase /tmp/builddir > # env LOCALBASE=/tmp/localbase BUILDDIR=/tmp/builddir ./ports-union-builder.sh > Is your /tmp big enough? > This will try build everything for x11/xorg. > Is it possible that VirtualBox is interfering in getting usable diagnostics > for -9 > Who knows? You might try posting your shell script so others can give it a whirl on a "real" 9-current system. > and how can I setup a dump device for -8. Currently I have: > > # swapinfo > Device 1K-blocks Used Avail Capacity > /dev/ad4s1b 8388608 0 8388608 0% > /dev/ad8s1b 8388608 0 8388608 0% > Total 16777216 0 16777216 0% > Do you have dumpdev defined in /etc/rc.conf and/or do you see /dev/dumpdev? Having /dev/dumpdev indicates that dumpon succeeded. Do you have less than 8GB of memory? See dumpon(8) for restrictions. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 15:38:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C5C3106568D for ; Wed, 20 Jan 2010 15:38:36 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 049408FC17 for ; Wed, 20 Jan 2010 15:38:35 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so1509014fga.13 for ; Wed, 20 Jan 2010 07:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=/Hj1TJoyod3XI0DAV7OQjL7wVRLt4f4rBybEr/JHuU4=; b=G1xwt3hFR2p2oqo5SWHCLvhgX4baBtaD6RVj2/q92uKuyqrIR0JwJ5g8EedBNaic+D 8W9OFW50EtXxIi4014ZCKE4nr+Q36Ze1V/w2Jh0YhPgGrDQc5H2eUPTe1cjSKUcmW2JI qlivTTyv/2AHZ5SG7BCOMBGcZSENV8ngAW73s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ohfcSQdNs4tvjXNI0Htl42+Z4V8MPuANTO1CITkqtPpR1YkizmAJmwulxSwZVGCgDi Lye+hTFx3qnjMonJz4280j2VvsfRrZYA65RDGGKrBorP7L20YNQ0PhqYoIO04xeDI6Ch vBmw44xMAfHe67xJBy6mYB/NjRDRcc6JMyifY= MIME-Version: 1.0 Received: by 10.87.56.8 with SMTP id i8mr330436fgk.24.1264000178930; Wed, 20 Jan 2010 07:09:38 -0800 (PST) Date: Thu, 21 Jan 2010 01:39:38 +1030 Message-ID: From: Matt Thyer To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 15:38:36 -0000 I typically buildworld with a parallel make of hw.ncpu * 3 which results in -j24 on my new system (Intel Core i7-860, 8GB RAM). I've not been able to buildworld natively on this new system (with ZFS - I have not tried non-ZFS natively yet) but have been able to buildworld in a virtual machine under Windows 7 64bit VMware Server 2.0.2 with 2 virtual CPUs (hence -j6 for buildworld). Both 8-STABLE 32bit (this VM is non-ZFS) and CURRENT 64bit (a ZFS system) will build as a VM (-j6) but a native 64bit FreeBSD CURRENT (ZFS) fails. The CURRENT 64bit systems were installed from the allbsd.org JPSNAP DVD of 18 Jan 2010 and both can successfully buildworld with -j1 (Virtual and native). Build failure is: sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim_asn1.h cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h /usr/obj/usr/src/tmp/usr/include sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error I guess this is a FreeBSD ZFS bug of some kind. I have not yet prepared another non-ZFS hard disk for native testing (though I do have a spare hard disk available and will test this soon). From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 16:05:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F30F1106566C for ; Wed, 20 Jan 2010 16:05:52 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 79FC78FC14 for ; Wed, 20 Jan 2010 16:05:52 +0000 (UTC) Received: by ewy3 with SMTP id 3so1717545ewy.13 for ; Wed, 20 Jan 2010 08:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=iq4UEN6p36fy+svJAecyIDDk84grvyb1F30MmGanUw0=; b=pc8Jug4OnlX1J/W/ZGlPu52RRB7bFn1ljQCPJmQYpLhW3EIwogEa6jUE218LRHRLWw e7P4fwQFjcqiQ2B9ge93Iy5hngfZwsMxXHI7nGcoutgez55Rd6oiS4tqGpMKK8t4TKIt vb09ODEhziuQke6jdpHd99kMs0SJ5XR3NDtjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=O5ld3JxjZYy6wj9EdJIM34HDi4OtXoSD9DvKu67McBg08uBaP7G+JT1XoeIqpIzATn rFTdUS3OYocgJZSFtiwq9BeKKK5Cuo/pEU4gkEorO3KiOxrGK5LYaDkCQNvyO8NfNk+j tbhHXuqWSFmjaLXt4W2GxXgRwpR44fE4A2HqE= Received: by 10.213.42.79 with SMTP id r15mr1183148ebe.94.1264003551193; Wed, 20 Jan 2010 08:05:51 -0800 (PST) Received: from dragon.dg ([41.216.197.17]) by mx.google.com with ESMTPS id 10sm67643eyd.45.2010.01.20.08.05.48 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Jan 2010 08:05:50 -0800 (PST) From: David Naylor Organization: Private To: gary.jennejohn@freenet.de Date: Wed, 20 Jan 2010 18:05:54 +0200 User-Agent: KMail/1.12.3 (FreeBSD/8.0-STABLE; KDE/4.3.3; amd64; ; ) References: <201001201543.15818.naylor.b.david@gmail.com> <20100120162821.3f53af6a@ernst.jennejohn.org> In-Reply-To: <20100120162821.3f53af6a@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart20388899.MH42N7fnO0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001201805.57798.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: stacked unionfs freeze and crash FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 16:05:53 -0000 --nextPart20388899.MH42N7fnO0 Content-Type: multipart/mixed; boundary="Boundary-01=_inyVL6GVTrfFMMh" Content-Transfer-Encoding: 7bit --Boundary-01=_inyVL6GVTrfFMMh Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 20 January 2010 17:28:21 Gary Jennejohn wrote: > On Wed, 20 Jan 2010 15:43:12 +0200 David Naylor wrote: > > Hi, > > > > The attached script, that uses stacked unionfs, causes FreeBSD-9 (cvsup > > yesterday) to freeze and FreeBSD-8 (cvsup two days ago) to crash: > > > > Fatal double fault > > rip-0xffffffff81e4c1 > > rsp=3D0xffffff80b133ef50 > > rbp=3D0xffffff80b133f150 > > cupid =3D 2; apic id =3D 02 > > panic: double fault > > cpuid =3D 2 > > uptime: 1h44m35s > > cannot dump. Device not defined or unavailable > > > > > > Both systems use the stock GENERIC kernel, i.e. -9 had full diagnostics > > built in (and was run under VirtualBox) and -8 had no diagnostics (and > > was run native). > > > > A LOR is produces prior to freezing under -9 (quiet a time prior). See > > kern/141950. > > > > The script uses unionfs to build ports (in an attempt to create a > > tinderbox without the need to delete and/or extract packages). To use > > the script to: > > > > # mkdir /tmp/localbase /tmp/builddir > > # env LOCALBASE=3D/tmp/localbase BUILDDIR=3D/tmp/builddir > > ./ports-union-builder.sh >=20 > Is your /tmp big enough? I was actually using /home, didn't think people wanted to contaminate that= =20 directory. Plenty of space. =20 > > This will try build everything for x11/xorg. > > > > Is it possible that VirtualBox is interfering in getting usable > > diagnostics for -9 >=20 > Who knows? You might try posting your shell script so others can give > it a whirl on a "real" 9-current system. I did attach the script. Guess mailer ate it, again. I'll try again... =20 > > and how can I setup a dump device for -8. Currently I have: > > > > # swapinfo > > Device 1K-blocks Used Avail Capacity > > /dev/ad4s1b 8388608 0 8388608 0% > > /dev/ad8s1b 8388608 0 8388608 0% > > Total 16777216 0 16777216 0% >=20 > Do you have dumpdev defined in /etc/rc.conf and/or do you see > /dev/dumpdev? Having /dev/dumpdev indicates that dumpon succeeded. No I haven't and no I don't. I thought it automatically used swap? =20 I'll 'activate' it and post the results. =20 > Do you have less than 8GB of memory? See dumpon(8) for restrictions. I have 6GB. =20 --Boundary-01=_inyVL6GVTrfFMMh Content-Type: text/plain; charset="ISO-8859-1"; name="ports-union-builder.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ports-union-builder.txt" #!/bin/sh BUILDDIR=${BUILDDIR:-/usr/build} LOCALBASE=${LOCALBASE:-/usr/local} PORTSDIR=${PORTSDIR:-/usr/ports} PORT_DBDIR=${PKG_DBDIR:-$BUILDDIR/db_ports} PKG_DBDIR=${PKG_DBDIR:-$BUILDDIR/db_pkg} PACKAGES=${PACKAGES:-$BUILDDIR/packages} MAKE="env LOCALBASE=$LOCALBASE PORTSDIR=$PORTSDIR PORT_DBDIR=$PORT_DBDIR PKG_DBDIR=$PKG_DBDIR PACKAGES=$PACKAGES make" set -e mkdir -p $BUILDDIR $LOCALBASE $PKG_DBDIR $PACKAGES port2name() { echo $1 | sed 's|[/.-]|_|g' } port2pkg() { local pkg_name= local port= port=$1; shift eval pkg_name=PKG$(port2name $port) eval pkg=\$$pkg_name if [ -z "$pkg" ] then pkg=$($MAKE -C $port -V PKGNAME) eval $pkg_name=$pkg fi } depends() { local depend= local depends_name= local _deps= local name= local port= port=$1 eval depends_name=DEPEND$(port2name $port) eval deps=\"\$$depends_name\" if [ -z "$deps" ] then echo "Getting dependancies for $port" > /dev/stderr depend_list="$($MAKE -C $port -V BUILD_DEPENDS -V LIB_DEPENDS -V RUN_DEPENDS)" for depend in $depend_list do name=$(echo $depend | cut -f 2 -d ':') depends $name _deps="$_deps $deps $name" done deps=$(for depend in $_deps do echo $depend done | sort -u) depends_name=$depends_name eval $depends_name=\"$deps \" fi } build() { local _deps= local dep= local port= port=$1 depends $port _deps="$deps" for dep in $_deps do port2pkg $dep if [ ! -d $BUILDDIR/$pkg ] then if ! build $dep then echo "Port $port failed due to dependancy $dep" return 255 fi fi done echo "Building port $port..." for pkg in $_deps do port2pkg $pkg mount -t unionfs -r -o noatime $BUILDDIR/$pkg $LOCALBASE done port2pkg $port mkdir -p $BUILDDIR/$pkg mount -t unionfs -o noatime $BUILDDIR/$pkg $LOCALBASE set +e trap "true" INT TERM EXIT $MAKE -C $port clean build install package -DNO_DEPENDS -DBATCH status=$? trap - INT TERM EXIT set -e umount $LOCALBASE for pkg in $(echo $_deps | sort -r) do #port2pkg $pkg umount $LOCALBASE done if [ $status -ne 0 ] then echo "Port $port failed to build" rm -rf $BUILDDIR/$pkg || (chflags -R 0 $BUILDDIR/$pkg; rm -rf $BUILDDIR/$pkg) else $MAKE -C $port clean fi return $status } build /usr/ports/x11/xorg --Boundary-01=_inyVL6GVTrfFMMh-- --nextPart20388899.MH42N7fnO0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktXKeUACgkQUaaFgP9pFrIk7wCcDx86bUEgStouDH3kPTtSB+Vc /dQAn1fpKB81Svy1F2UJr9O4WN8hxBt9 =nFC2 -----END PGP SIGNATURE----- --nextPart20388899.MH42N7fnO0-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 16:34:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E4A41065695 for ; Wed, 20 Jan 2010 16:34:46 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 967718FC18 for ; Wed, 20 Jan 2010 16:34:45 +0000 (UTC) Received: by fxm10 with SMTP id 10so2094402fxm.34 for ; Wed, 20 Jan 2010 08:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=gvVaCaE19FZxn/k9WMaISvRgYQ6dlRJ8OszvqWEnMi8=; b=Qq58Y0ZPb8xMAj+i8yW1fWuxK/50LT2UwguMFhla4IlNnA9DW8GHzG5JbxmO4pC7ad CPLssMVAQ4ggAlQmfPrMRN7jwlY+L0iSXmF/YP3f5aAxwpvf+l9+KSaKTEurbcdAdRAK GoxdMa56ql7NLNjW6I+vT0/heueIHTkirsrQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=HJFO6w/7Vxpwe32PwXCLr1JLQyhAb7riCFeI0ct2Py5tvITvsRqbcp238HB124jvl6 42U0JDphzB+7cwMglN3UqueV4HFKijy2WdGCBvg8esdDQlOt/0JuflYpFqvNV5Vu9fKL VPlg+qPBz3wjXsBXuUl1KKIZYrg4laHJ7V2MU= Received: by 10.216.86.132 with SMTP id w4mr70716wee.87.1264005284267; Wed, 20 Jan 2010 08:34:44 -0800 (PST) Received: from dragon.dg ([41.216.197.17]) by mx.google.com with ESMTPS id 28sm9701534eye.3.2010.01.20.08.34.42 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Jan 2010 08:34:43 -0800 (PST) From: David Naylor Organization: Private To: gary.jennejohn@freenet.de Date: Wed, 20 Jan 2010 18:34:45 +0200 User-Agent: KMail/1.12.3 (FreeBSD/8.0-STABLE; KDE/4.3.3; amd64; ; ) References: <201001201543.15818.naylor.b.david@gmail.com> <20100120162821.3f53af6a@ernst.jennejohn.org> <201001201805.57798.naylor.b.david@gmail.com> In-Reply-To: <201001201805.57798.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4066690.RP3TjsJMoC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001201834.48466.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: stacked unionfs freeze and crash FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 16:34:46 -0000 --nextPart4066690.RP3TjsJMoC Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday 20 January 2010 18:05:54 David Naylor wrote: > On Wednesday 20 January 2010 17:28:21 Gary Jennejohn wrote: > > On Wed, 20 Jan 2010 15:43:12 +0200 David Naylor wrote: > > > Hi, > > > > > > The attached script, that uses stacked unionfs, causes FreeBSD-9 (cvs= up > > > yesterday) to freeze and FreeBSD-8 (cvsup two days ago) to crash: > > > > > > Fatal double fault > > > rip-0xffffffff81e4c1 > > > rsp=3D0xffffff80b133ef50 > > > rbp=3D0xffffff80b133f150 > > > cupid =3D 2; apic id =3D 02 > > > panic: double fault > > > cpuid =3D 2 > > > uptime: 1h44m35s > > > cannot dump. Device not defined or unavailable > > > > > > > > > Both systems use the stock GENERIC kernel, i.e. -9 had full diagnosti= cs > > > built in (and was run under VirtualBox) and -8 had no diagnostics (and > > > was run native). > > > > > > A LOR is produces prior to freezing under -9 (quiet a time prior). S= ee > > > kern/141950. > > > > > > The script uses unionfs to build ports (in an attempt to create a > > > tinderbox without the need to delete and/or extract packages). To use > > > the script to: > > > > > > # mkdir /tmp/localbase /tmp/builddir > > > # env LOCALBASE=3D/tmp/localbase BUILDDIR=3D/tmp/builddir > > > ./ports-union-builder.sh > > > > Is your /tmp big enough? >=20 > I was actually using /home, didn't think people wanted to contaminate that > directory. Plenty of space. >=20 > > > This will try build everything for x11/xorg. > > > > > > Is it possible that VirtualBox is interfering in getting usable > > > diagnostics for -9 > > > > Who knows? You might try posting your shell script so others can give > > it a whirl on a "real" 9-current system. >=20 > I did attach the script. Guess mailer ate it, again. I'll try again... >=20 > > > and how can I setup a dump device for -8. Currently I have: > > > > > > # swapinfo > > > Device 1K-blocks Used Avail Capacity > > > /dev/ad4s1b 8388608 0 8388608 0% > > > /dev/ad8s1b 8388608 0 8388608 0% > > > Total 16777216 0 16777216 0% > > > > Do you have dumpdev defined in /etc/rc.conf and/or do you see > > /dev/dumpdev? Having /dev/dumpdev indicates that dumpon succeeded. >=20 > No I haven't and no I don't. I thought it automatically used swap? >=20 > I'll 'activate' it and post the results. Here it is. If anyone ones the full core.txt just shout. =20 #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff80589ba9 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff80589fdc in panic (fmt=3D0xffffffff8098bd81 "double fault") at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff8086e546 in dblfault_handler (frame=3DVariable "frame" is not= =20 available.) at /usr/src/sys/amd64/amd64/trap.c:884 #4 0xffffffff808557fc in Xdblfault () at /usr/src/sys/amd64/amd64/exception.S:278 #5 0xffffffff81e464c1 in unionfs_statfs (mp=3DVariable "mp" is not availab= le.) at /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vfsops.c:428 Previous frame inner to this frame (corrupt stack?) (kgdb) --nextPart4066690.RP3TjsJMoC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktXMKgACgkQUaaFgP9pFrJ1TgCdFbDeTCPhyEJBL63GC7c89/e4 zkgAn2TjWNGRZ2C7r3whz05rSFRs+8f6 =7p12 -----END PGP SIGNATURE----- --nextPart4066690.RP3TjsJMoC-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 16:56:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 309BF106568B for ; Wed, 20 Jan 2010 16:56:40 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id E89FF8FC1A for ; Wed, 20 Jan 2010 16:56:39 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o0KGNRrA069226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 10:23:28 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o0KGNR52019012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 10:23:27 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o0KGNRPl018934; Wed, 20 Jan 2010 10:23:27 -0600 (CST) (envelope-from dan) Date: Wed, 20 Jan 2010 10:23:26 -0600 From: Dan Nelson To: Matt Thyer Message-ID: <20100120162326.GD50360@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Wed, 20 Jan 2010 10:23:28 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: current@freebsd.org Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 16:56:40 -0000 In the last episode (Jan 21), Matt Thyer said: > I typically buildworld with a parallel make of hw.ncpu * 3 which results > in -j24 on my new system (Intel Core i7-860, 8GB RAM). > > I've not been able to buildworld natively on this new system (with ZFS - I > have not tried non-ZFS natively yet) but have been able to buildworld in a > virtual machine under Windows 7 64bit VMware Server 2.0.2 with 2 virtual > CPUs (hence -j6 for buildworld). > > Both 8-STABLE 32bit (this VM is non-ZFS) and CURRENT 64bit (a ZFS system) > will build as a VM (-j6) but a native 64bit FreeBSD CURRENT (ZFS) fails. > > The CURRENT 64bit systems were installed from the allbsd.org JPSNAP DVD of > 18 Jan 2010 and both can successfully buildworld with -j1 (Virtual and > native). > > Build failure is: > > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h > /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim_asn1.h > cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h > pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h > /usr/obj/usr/src/tmp/usr/include > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libasn1.so.10 > /usr/obj/usr/src/tmp/usr/lib > ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error It's much more likely to be a Makefile dependency problem than a ZFS bug. You will need to look much farther up in your log to see the real error message. Make will wait for the other 23 jobs to finish before returning, so what you posted was the output of one of the other jobs, plus the output of each parent make as it exits with an error code. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 17:03:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E1BD1065676 for ; Wed, 20 Jan 2010 17:03:23 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from mail.haruhiism.net (mail.fujibayashi.jp [IPv6:2001:470:9954:ffff::2]) by mx1.freebsd.org (Postfix) with ESMTP id CE9F08FC17 for ; Wed, 20 Jan 2010 17:03:22 +0000 (UTC) Received: from [IPv6:2001:470:9f2d:0:1::1] (omoikane.gensokyo.fujibayashi.jp [IPv6:2001:470:9f2d:0:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.haruhiism.net (Postfix) with ESMTPSA id E9132139229 for ; Thu, 21 Jan 2010 02:03:20 +0900 (JST) Message-ID: <4B57375A.4000309@haruhiism.net> Date: Wed, 20 Jan 2010 20:03:22 +0300 From: "K.R." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 ThunderBrowse/3.2.7 MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: 8.0-STABLE r200182: weird behaviour of a service in a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:03:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm running FreeBSD 8.0-STABLE #0 r200182: Mon Dec 7 03:32:18 JST 2009 SMP (4 cores) with an uptime of ~44 days and starting about 1.5 weeks ago, I've noticed a weird behaviour with a jailed ircd (a hybrid spin-off); it listens on a cloned address on lo0 and the connections to it are redirected by pf. Everything was fine until once I noticed that I (and other users, of course) cannot connect to the irc server - the connection is established but then it just hangs indefinitely. This problem has never manifested itself on 7.0-STABLE and 7.2-STABLE on a single core system (ircd was also running inside a jail there). It looks like this from the outside: % telnet irc.server.here 6667 Trying (ip address here)... Connected to irc.server.here. Escape character is '^]'. And that's it; normally I'd get "439 * :Please wait while we process your connection." Same with another - server link - port. If I attempt to connect to the server's "real" listening IP from the machine running ircd, however, I get % telnet irc.server.here 6667 Trying (ip address here)... Connected to irc.server.here. Escape character is '^]'. Connection closed by foreign host. (immediately, with no pause) And on the server link port, it's still the same indefinite wait. Amusingly enough, a simple REHASH - which resets ircd's listening sockets - fixes the problem. The developers of the ircd state that this behaviour is unexpected and there's nothing wrong with the source code on their end (which I can believe). The ircd uses kqueue, if it matters. There are no abnormalities with sshd and sendmail in the same jail. No problems ever arised in the 5 other jails running HTTP, SMTP and other services; but that might be because ircd's load is much bigger in terms of total number of established connections. How should I debug this issue? For now, I've moved the jail to an external IP address to see if the problem persists. - -- Kamigishi Rei KREI-RIPE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJLVzdTAAoJEPAgyqbDpP+efJUIAKB9MJgLiTnlQYkPnLXCqroG fQqSilPODsztqkRc9MbbDLhUjk0PtBO/hFEIUrv2fUqOBbbf/H8TSRn7BdQuYUVU 6PsBrl+/e/jhP6y8wRsNudijlE1cQfxsjFJoNnoEHFKBY//6SedvMwMvxTy96CHf WOkBnNJVUt/YB/Fq/DdZtNUlZpOWxxtGWHf/C75q5IdGfjk6R3uLABazUhIGHJoK We/3gG2IVTf3zzKgCPwDaj3sLYQ1wkP4rOoAQjU+3pLynnR3xnQzv3XG2MtX3xEf bFh2RrN/0ufoNgUDJeEVptJDveTYbpHIzCm9iVkETM7Tv0A/CSzIwy6QMbB/eIU= =y1oH -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 17:17:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC209106568D for ; Wed, 20 Jan 2010 17:17: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 3AF308FC1A for ; Wed, 20 Jan 2010 17:17: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 TAA24070; Wed, 20 Jan 2010 19:17:00 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B573A8B.8080306@icyb.net.ua> Date: Wed, 20 Jan 2010 19:16:59 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: David Naylor References: <201001201543.15818.naylor.b.david@gmail.com> <20100120162821.3f53af6a@ernst.jennejohn.org> <201001201805.57798.naylor.b.david@gmail.com> <201001201834.48466.naylor.b.david@gmail.com> In-Reply-To: <201001201834.48466.naylor.b.david@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: stacked unionfs freeze and crash FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:17:05 -0000 on 20/01/2010 18:34 David Naylor said the following: > > Here it is. If anyone ones the full core.txt just shout. > > #0 doadump () at pcpu.h:223 > 223 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:223 > #1 0xffffffff80589ba9 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff80589fdc in panic (fmt=0xffffffff8098bd81 "double fault") > at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xffffffff8086e546 in dblfault_handler (frame=Variable "frame" is not > available.) > at /usr/src/sys/amd64/amd64/trap.c:884 > #4 0xffffffff808557fc in Xdblfault () > at /usr/src/sys/amd64/amd64/exception.S:278 > #5 0xffffffff81e464c1 in unionfs_statfs (mp=Variable "mp" is not available.) > at /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vfsops.c:428 > Previous frame inner to this frame (corrupt stack?) > (kgdb) Double-fault could indicate stack overflow. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 17:53:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30A1C106566B; Wed, 20 Jan 2010 17:53:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 851FB8FC15; Wed, 20 Jan 2010 17:53:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=9zKBo0zsyzYA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=1QOEjlIrGIGqMfsvmToA:9 a=MQBOjsDtMpGNYYZacRYA:7 a=v9YtR-xc4lA7SQTLIBpIrLA6gcwA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 593888539; Wed, 20 Jan 2010 18:53:13 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Wed, 20 Jan 2010 18:51:50 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <20100120064620.GJ46479@stlux503.dsto.defence.gov.au> In-Reply-To: <20100120064620.GJ46479@stlux503.dsto.defence.gov.au> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001201851.50069.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:53:16 -0000 On Wednesday 20 January 2010 07:46:20 Wilkinson, Alex wrote: > And works dam well. > Thanks. > What apps could i expect this to work with in the future ? skype ? Basically all V4L appllications. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 17:58:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4005C106568D; Wed, 20 Jan 2010 17:58:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 68D618FC1E; Wed, 20 Jan 2010 17:57:58 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=RYQgPGQ7BbsA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=7kGAbY5_nOuQvFgCT9sA:9 a=07Ygt_TCPVjRXVcRcOuNz-qIFLAA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1332816593; Wed, 20 Jan 2010 18:57:57 +0100 From: Hans Petter Selasky To: Henry Hu Date: Wed, 20 Jan 2010 18:56:34 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <53a1e0711001190933y64a41e98h60fa3dec641d44fd@mail.gmail.com> In-Reply-To: <53a1e0711001190933y64a41e98h60fa3dec641d44fd@mail.gmail.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001201856.35002.hselasky@c2i.net> Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:58:00 -0000 Hi, On Tuesday 19 January 2010 18:33:14 Henry Hu wrote: > There are some problems, however. First, when I start pwcview with an > unsupported mode, the content of the window is green, and I cannot > kill the process. Only after terminating webcamd can I terminate the > process. I know what the problem is, and I will try to fix it in the next release of webcamd. > Second, I cannot restart pwcview without restarting webcamd. At the > second time I start pwcview with -s vga, the window is green, and I > cannot kill it. The situation is similar to unsupported size. > > I've also tried applications such as pidgin, skype and mplayer. > However no one successfully played from the webcam. I doubt it needs > some extra work. You need to recompile these applications after installing libv4l. I have vlc working with the new stuff. > > Thanks again for the great work! It never caused any kernel panic, and > the programs are fairly stable. Thanks! --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 18:00:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F420F106566B; Wed, 20 Jan 2010 18:00:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 282428FC13; Wed, 20 Jan 2010 18:00:54 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=RYQgPGQ7BbsA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=obg1LsjmO9W_VvOtepQA:9 a=aHYi9kqB8Y5nidVInDxItgpaWSQA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1359912782; Wed, 20 Jan 2010 19:00:53 +0100 From: Hans Petter Selasky To: vova@fbsd.ru Date: Wed, 20 Jan 2010 18:59:30 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <1263244252.3558.29.camel@localhost> <1263931952.2993.7.camel@localhost> In-Reply-To: <1263931952.2993.7.camel@localhost> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201001201859.30886.hselasky@c2i.net> Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 18:00:56 -0000 On Tuesday 19 January 2010 21:12:32 Vladimir Grebenschikov wrote: > Hi > > I've tested with recent ports. > > pwcview works fine, both vga and sif > > but skype still sees /dev/video0 but fails to play anything from it, > multimedia/cheese even does not sees webcam. > > Is it supposed, or I am so unlucky ? Yes it is supposed to work, but you maybe need to tweak/rebuild the gstreamer V4L2 code. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 21:57:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D1FF106566B for ; Wed, 20 Jan 2010 21:57:29 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id E87998FC0A for ; Wed, 20 Jan 2010 21:57:27 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 376D414DA30E for ; Wed, 20 Jan 2010 22:39:42 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Jr7ujxEbESng for ; Wed, 20 Jan 2010 22:39:31 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 25AE514DA2FD for ; Wed, 20 Jan 2010 22:39:31 +0100 (CET) Message-ID: <4B57780F.4070907@FreeBSD.org> Date: Wed, 20 Jan 2010 22:39:27 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: HEADSUP: BSDL bc/dc in head [Was: svn commit: r202719 - in head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc usr.bin/dc usr.bin/dc/USD.doc] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 21:57:29 -0000 Hi all, I've just committed the BSDL versions of bc/dc ported from OpenBSD. Thanks goes to Erwin for the exp-run and to Google for sponsoring my work on text processing tools back in 2008. It is one of the results of that summer. Unfortunately, it took a bit long because there were more complicated problems with grep but the work I started that time hasn't got lost and further pieces are supposed to come slowly as they are ready. For now, the GNU version is still there in head but detached from the build. I'll add ports of GNU bc/dc and if BSDL bc/dc does fine I'll remove those form HEAD. Please report if you see any regressions or if you just have comments. Regards, Gabor -------- Mensaje original -------- Asunto: svn commit: r202719 - in head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc usr.bin/dc usr.bin/dc/USD.doc Fecha: Wed, 20 Jan 2010 21:30:52 +0000 (UTC) De: Gabor Kovesdan Para: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: gabor (doc,ports committer) Date: Wed Jan 20 21:30:52 2010 New Revision: 202719 URL: http://svn.freebsd.org/changeset/base/202719 Log: Replace GNU bc/dc with BSDL versions ported from OpenBSD. They have a good compatibility level with the GNU counterparts and have shown to be mature enough. For now, the GNU versions aren't removed from the tree, just detached from the build. Sponsored by: Google Summer of Code 2008 Portbuild run by: erwin Approved by: delphij Added: head/usr.bin/bc/ head/usr.bin/bc/Makefile (contents, props changed) head/usr.bin/bc/USD.doc/ head/usr.bin/bc/USD.doc/Makefile (contents, props changed) head/usr.bin/bc/USD.doc/bc (contents, props changed) head/usr.bin/bc/bc.1 (contents, props changed) head/usr.bin/bc/bc.library (contents, props changed) head/usr.bin/bc/bc.y (contents, props changed) head/usr.bin/bc/extern.h (contents, props changed) head/usr.bin/bc/pathnames.h (contents, props changed) head/usr.bin/bc/scan.l (contents, props changed) head/usr.bin/dc/ head/usr.bin/dc/Makefile (contents, props changed) head/usr.bin/dc/USD.doc/ head/usr.bin/dc/USD.doc/Makefile (contents, props changed) head/usr.bin/dc/USD.doc/dc (contents, props changed) head/usr.bin/dc/bcode.c (contents, props changed) head/usr.bin/dc/bcode.h (contents, props changed) head/usr.bin/dc/dc.1 (contents, props changed) head/usr.bin/dc/dc.c (contents, props changed) head/usr.bin/dc/extern.h (contents, props changed) head/usr.bin/dc/inout.c (contents, props changed) head/usr.bin/dc/mem.c (contents, props changed) head/usr.bin/dc/stack.c (contents, props changed) Modified: head/ObsoleteFiles.inc head/gnu/usr.bin/Makefile head/usr.bin/Makefile Modified: head/ObsoleteFiles.inc ============================================================================== --- head/ObsoleteFiles.inc Wed Jan 20 21:12:30 2010 (r202718) +++ head/ObsoleteFiles.inc Wed Jan 20 21:30:52 2010 (r202719) @@ -14,6 +14,13 @@ # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last. # +# 20100120: replacing GNU bc/dc with BSDL versions +OLD_FILES+=usr/share/examples/bc/ckbook.b +OLD_FILES+=usr/share/examples/bc/pi.b +OLD_FILES+=usr/share/examples/bc/primes.b +OLD_FILES+=usr/share/examples/bc/twins.b +OLD_FILES+=usr/share/info/dc.info.gz +OLD_DIRS+=usr/share/examples/bc # 20100114: removal of ttyslot(3) OLD_FILES+=usr/share/man/man3/ttyslot.3.gz # 20100113: remove utmp.h, replace it by utmpx.h Modified: head/gnu/usr.bin/Makefile ============================================================================== --- head/gnu/usr.bin/Makefile Wed Jan 20 21:12:30 2010 (r202718) +++ head/gnu/usr.bin/Makefile Wed Jan 20 21:30:52 2010 (r202719) @@ -2,12 +2,10 @@ .include -SUBDIR= bc \ - ${_binutils} \ +SUBDIR= ${_binutils} \ ${_cc} \ ${_cpio} \ ${_cvs} \ - dc \ dialog \ diff \ diff3 \ Modified: head/usr.bin/Makefile ============================================================================== --- head/usr.bin/Makefile Wed Jan 20 21:12:30 2010 (r202718) +++ head/usr.bin/Makefile Wed Jan 20 21:30:52 2010 (r202719) @@ -18,6 +18,7 @@ SUBDIR= alias \ awk \ banner \ basename \ + bc \ ${_biff} \ ${_bluetooth} \ brandelf \ @@ -49,6 +50,7 @@ SUBDIR= alias \ ${_csup} \ ${_ctags} \ cut \ + dc \ ${_dig} \ dirname \ du \ Added: head/usr.bin/bc/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/usr.bin/bc/Makefile Wed Jan 20 21:30:52 2010 (r202719) @@ -0,0 +1,17 @@ +# $FreeBSD$ +# $OpenBSD: Makefile,v 1.4 2006/06/30 19:02:28 otto Exp $ + +PROG= bc +SRCS= bc.y scan.l +CFLAGS+= -I. -I${.CURDIR} +WARNS?= 6 +#SUBDIR+= USD.doc + +FILES+= bc.library +FILESDIR= ${SHAREDIR}/misc + +#beforeinstall: +# install -c -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/bc.library \ +# ${DESTDIR}/usr/share/misc + +.include Added: head/usr.bin/bc/USD.doc/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/usr.bin/bc/USD.doc/Makefile Wed Jan 20 21:30:52 2010 (r202719) @@ -0,0 +1,13 @@ +# $FreeBSD$ +# $OpenBSD: Makefile,v 1.3 2004/02/01 15:18:01 jmc Exp $ + +DOC= bc +DIR= usd/06.bc +SRCS= bc +MACROS= -ms +BINDIR= /usr/share/doc/papers + +paper.txt: ${SRCS} + ${ROFF} -Tascii ${SRCS}> ${.TARGET} + +.include Added: head/usr.bin/bc/USD.doc/bc ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/usr.bin/bc/USD.doc/bc Wed Jan 20 21:30:52 2010 (r202719) @@ -0,0 +1,1241 @@ +.\" $FreeBSD$ +.\" $OpenBSD: bc,v 1.9 2004/07/09 10:23:05 jmc Exp $ +.\" +.\" Copyright (C) Caldera International Inc. 2001-2002. +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code and documentation must retain the above +.\" copyright notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. All advertising materials mentioning features or use of this software +.\" must display the following acknowledgement: +.\" This product includes software developed or owned by Caldera +.\" International, Inc. +.\" 4. Neither the name of Caldera International, Inc. nor the names of other +.\" contributors may be used to endorse or promote products derived from +.\" this software without specific prior written permission. +.\" +.\" USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA +.\" INTERNATIONAL, INC. AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE FOR ANY DIRECT, +.\" INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES +.\" (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR +.\" SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, +.\" STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING +.\" IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +.\" POSSIBILITY OF SUCH DAMAGE. +.\" +.\" @(#)bc 6.2 (Berkeley) 4/17/91 +.\" +.if n \{\ +.po 5n +.ll 70n +.\} +.EH 'USD:6-%''BC \- An Arbitrary Precision Desk-Calculator Language' +.OH 'BC \- An Arbitrary Precision Desk-Calculator Language''USD:6-%' +.\".RP +.TL +BC \- An Arbitrary Precision Desk-Calculator Language +.AU +Lorinda Cherry +.AU +Robert Morris +.AI +.\" .MH +.AB +BC is a language and a compiler for doing arbitrary precision arithmetic +on the PDP-11 under the +.UX +time-sharing +system. The output of the compiler is interpreted and executed by +a collection of routines which can input, output, and do +arithmetic on indefinitely large integers and on scaled fixed-point +numbers. +.PP +These routines are themselves based on a dynamic storage allocator. +Overflow does not occur until all available core storage +is exhausted. +.PP +The language has a complete control structure as well as immediate-mode +operation. Functions can be defined and saved for later execution. +.PP +Two five hundred-digit numbers can be multiplied to give a +thousand digit result in about ten seconds. +.PP +A small collection of library functions is also available, +including sin, cos, arctan, log, exponential, and Bessel functions of +integer order. +.PP +Some of the uses of this compiler are +.IP \- +to do computation with large integers, +.IP \- +to do computation accurate to many decimal places, +.IP \- +conversion of numbers from one base to another base. +.AE +.PP +.SH +Introduction +.PP +BC is a language and a compiler for doing arbitrary precision +arithmetic on the +.UX +time-sharing system [1]. +The compiler was written to make conveniently available a +collection of routines (called DC [5]) which are capable of doing +arithmetic on integers of arbitrary size. The compiler +is by no means intended to provide a complete programming +language. +It is a minimal language facility. +.PP +There is a scaling provision that permits the +use of decimal point notation. +Provision is made for input and output in bases other than +decimal. Numbers can be converted from decimal to octal by +simply setting the output base to equal 8. +.PP +The actual limit on the number of digits that can +be handled depends on the amount of storage available on the machine. +Manipulation of numbers with many hundreds of digits +is possible even on the smallest versions of +.UX . +.PP +The syntax of BC has been deliberately selected to agree +substantially with the C language [2]. Those who +are familiar with C will find few surprises in this language. +.SH +Simple Computations with Integers +.PP +The simplest kind of statement is an arithmetic expression +on a line by itself. +For instance, if you type in the line: +.DS +.ft B +142857 + 285714 +.ft P +.DE +the program responds immediately with the line +.DS +.ft B +428571 +.ft P +.DE +The operators \-, *, /, %, and ^ can also be used; they +indicate subtraction, multiplication, division, remaindering, and +exponentiation, respectively. Division of integers produces an +integer result truncated toward zero. +Division by zero produces an error +comment. +.PP +Any term in an expression may be prefixed by a minus sign to +indicate that it is to be negated (the `unary' minus sign). +The expression +.DS +.ft B +7+\-3 +.ft P +.DE +is interpreted to mean that \-3 is to be added to 7. +.PP +More complex expressions with several operators and with +parentheses are interpreted just as in +Fortran, with ^ having the greatest binding +power, then * and % and /, and finally + and \-. +Contents of parentheses are evaluated before material +outside the parentheses. +Exponentiations are +performed from right to left and the other operators +from left to right. +The two expressions +.DS +.ft B +a^b^c and a^(b^c) +.ft P +.DE +are equivalent, as are the two expressions +.DS +.ft B +a*b*c and (a*b)*c +.ft P +.DE +BC shares with Fortran and C the undesirable convention that +.DS +\fBa/b*c\fP is equivalent to \fB(a/b)*c\fP +.ft P +.DE +.PP +Internal storage registers to hold numbers have single lower-case +letter names. The value of an expression can be assigned to +a register in the usual way. The statement +.DS +.ft B +x = x + 3 +.ft P +.DE +has the effect of increasing by three the value of the contents of the +register named x. +When, as in this case, the outermost operator is an =, the +assignment is performed but the result is not printed. +Only 26 of these named storage registers are available. +.PP +There is a built-in square root function whose +result is truncated to an integer (but see scaling below). +The lines +.DS +.ft B +x = sqrt(191) +x +.ft P +.DE +produce the printed result +.DS +.ft B +13 +.ft P +.DE +.SH +Bases +.PP +There are special internal quantities, called `ibase' and `obase'. +The contents of `ibase', initially set to 10, +determines the base used for interpreting numbers read in. +For example, the lines +.DS +.ft B +ibase = 8 +11 +.ft P +.DE +will produce the output line +.DS +.ft B +9 +.ft P +.DE +and you are all set up to do octal to decimal conversions. +Beware, however of trying to change the input base back +to decimal by typing +.DS +.ft B +ibase = 10 +.ft P +.DE +Because the number 10 is interpreted as octal, this statement will +have no effect. +For those who deal in hexadecimal notation, +the characters A\-F are permitted in numbers +(no matter what base is in effect) +and are +interpreted as digits having values 10\-15 respectively. +The statement +.DS +.ft B +ibase = A +.ft P +.DE +will change you back to decimal input base no matter what the +current input base is. +Negative and large positive input bases are +permitted but useless. +No mechanism has been provided for the input of arbitrary +numbers in bases less than 1 and greater than 16. +.PP +The contents of `obase', initially set to 10, are used as the base for output +numbers. The lines +.DS +.ft B +obase = 16 +1000 +.ft P +.DE +will produce the output line +.DS +.ft B +3E8 +.ft P +.DE +which is to be interpreted as a 3-digit hexadecimal number. +Very large output bases are permitted, and they are sometimes useful. +For example, large numbers can be output in groups of five digits +by setting `obase' to 100000. +Strange (i.e. 1, 0, or negative) output bases are +handled appropriately. +.PP +Very large numbers are split across lines with 70 characters per line. +Lines which are continued end with \\. +Decimal output conversion is practically instantaneous, but output +of very large numbers (i.e., more than 100 digits) with other bases +is rather slow. +Non-decimal output conversion of +a one hundred digit number takes about +three seconds. +.PP +It is best to remember that `ibase' and `obase' have no effect +whatever on the course of internal computation or +on the evaluation of expressions, but only affect input and +output conversion, respectively. +.SH +Scaling +.PP +A third special internal quantity called `scale' is +used to determine the scale of calculated +quantities. +Numbers may have +up to a specific number of decimal digits after the decimal point. +This fractional part is retained in further computations. +We refer to the number of digits after the decimal point of +a number as its scale. +The current implementation allows scales to be as large as can be +represented by a 32-bit unsigned number minus one. +This is a non-portable extension. +The original implementation allowed for a maximum scale of 99. +.PP +When two scaled numbers are combined by +means of one of the arithmetic operations, the result +has a scale determined by the following rules. For +addition and subtraction, the scale of the result is the larger +of the scales of the two operands. In this case, +there is never any truncation of the result. +For multiplications, the scale of the result is never +less than the maximum of the two scales of the operands, +never more than the sum of the scales of the operands +and, subject to those two restrictions, +the scale of the result is set equal to the contents of the internal +quantity `scale'. +The scale of a quotient is the contents of the internal +quantity `scale'. The scale of a remainder is +the sum of the scales of the quotient and the divisor. +The result of an exponentiation is scaled as if +the implied multiplications were performed. +An exponent must be an integer. +The scale of a square root is set to the maximum of the scale +of the argument and the contents of `scale'. +.PP +All of the internal operations are actually carried out in terms +of integers, with digits being discarded when necessary. +In every case where digits are discarded, truncation and +not rounding is performed. +.PP +The contents of +`scale' must be no greater than +4294967294 and no less than 0. It is initially set to 0. +.PP +The internal quantities `scale', `ibase', and `obase' can be +used in expressions just like other variables. +The line +.DS +.ft B +scale = scale + 1 +.ft P +.DE +increases the value of `scale' by one, and the line +.DS +.ft B +scale +.ft P +.DE +causes the current value of `scale' to be printed. +.PP +The value of `scale' retains its meaning as a +number of decimal digits to be retained in internal +computation even when `ibase' or `obase' are not equal to 10. +The internal computations (which are still conducted in decimal, +regardless of the bases) are performed to the specified number +of decimal digits, never hexadecimal or octal or any +other kind of digits. +.SH +Functions +.PP +The name of a function is a single lower-case letter. +Function names are permitted to collide with simple +variable names. +Twenty-six different defined functions are permitted +in addition to the twenty-six variable names. +The line +.DS +.ft B + define a(x){ +.ft P +.DE +begins the definition of a function with one argument. +This line must be followed by one or more statements, +which make up the body of the function, ending +with a right brace }. +Return of control from a function occurs when a return +statement is executed or when the end of the function is reached. +The return statement can take either +of the two forms +.DS +.ft B +return +return(x) +.ft P +.DE +In the first case, the value of the function is 0, and in +the second, the value of the expression in parentheses. +.PP +Variables used in the function can be declared as automatic +by a statement of the form +.DS +.ft B +auto x,y,z +.ft P +.DE +There can be only one `auto' statement in a function and it must +be the first statement in the definition. +These automatic variables are allocated space and initialized +to zero on entry to the function and thrown away on return. The +values of any variables with the same names outside the function +are not disturbed. +Functions may be called recursively and the automatic variables +at each level of call are protected. +The parameters named in a function definition are treated in +the same way as the automatic variables of that function +with the single exception that they are given a value +on entry to the function. +An example of a function definition is +.DS +.ft B + define a(x,y){ + auto z + z = x*y + return(z) + } +.ft P +.DE +The value of this function, when called, will be the +product of its +two arguments. +.PP +A function is called by the appearance of its name +followed by a string of arguments enclosed in +parentheses and separated by commas. +The result +is unpredictable if the wrong number of arguments is used. +.PP +Functions with no arguments are defined and called using +parentheses with nothing between them: b(). +.PP +If the function +.ft I +a +.ft +above has been defined, then the line +.DS +.ft B +a(7,3.14) +.ft P +.DE +would cause the result 21.98 to be printed and the line +.DS +.ft B +x = a(a(3,4),5) +.ft P +.DE +would cause the value of x to become 60. +.SH +Subscripted Variables +.PP +A single lower-case letter variable name +followed by an expression in brackets is called a subscripted +variable (an array element). +The variable name is called the array name and the expression +in brackets is called the subscript. +Only one-dimensional arrays are +permitted. The names of arrays are permitted to +collide with the names of simple variables and function names. +Any fractional +part of a subscript is discarded before use. +Subscripts must be greater than or equal to zero and +less than or equal to 2047. +.PP +Subscripted variables may be freely used in expressions, in +function calls, and in return statements. +.PP +An array name may be used as an argument to a function, +or may be declared as automatic in +a function definition by the use of empty brackets: +.DS +.ft B +f(a[\|]) +define f(a[\|]) +auto a[\|] +.ft P +.DE +When an array name is so used, the whole contents of the array +are copied for the use of the function, and thrown away on exit +from the function. +Array names which refer to whole arrays cannot be used +in any other contexts. +.SH +Control Statements +.PP +The `if', the `while', and the `for' statements +may be used to alter the flow within programs or to cause iteration. +The range of each of them is a statement or +a compound statement consisting of a collection of +statements enclosed in braces. +They are written in the following way +.DS +.ft B +if(relation) statement +if(relation) statement else statement +while(relation) statement +for(expression1; relation; expression2) statement +.ft P +.DE +or +.DS +.ft B +if(relation) {statements} +if(relation) {statements} else {statements} +while(relation) {statements} +for(expression1; relation; expression2) {statements} +.ft P +.DE +.PP +A relation in one of the control statements is an expression of the form +.DS +.ft B +x>y +.ft P +.DE +where two expressions are related by one of the six relational +operators `<', `>', `<=', `>=', `==', or `!='. +The relation `==' +stands for `equal to' and `!=' stands for `not equal to'. +The meaning of the remaining relational operators is +clear. +.PP +BEWARE of using `=' instead of `==' in a relational. Unfortunately, +both of them are legal, so you will not get a diagnostic +message, but `=' really will not do a comparison. +.PP +The `if' statement causes execution of its range +if and only if the relation is true. +Then control passes to the next statement in sequence. +If an `else' branch is present, the statements in this branch are +executed if the relation is false. +The `else' keyword is a non-portable extension. +.PP +The `while' statement causes execution of its range +repeatedly as long as the relation +is true. The relation is tested before each execution +of its range and if the relation +is false, control passes to the next statement beyond the range +of the while. +.PP +The `for' statement begins +by executing `expression1'. Then the relation is tested +and, if true, the statements in the range of the `for' are executed. +Then `expression2' is executed. The relation is tested, and so on. +The typical use of the `for' statement is for a controlled iteration, +as in the statement +.DS +.ft B +for(i=1; i<=10; i=i+1) i +.ft P +.DE +which will print the integers from 1 to 10. +Here are some examples of the use of the control statements. +.DS +.ft B +define f(n){ +auto i, x +x=1 +for(i=1; i<=n; i=i+1) x=x*i +return(x) +} +.ft P +.DE +The line +.DS +.ft B + f(a) +.ft P +.DE +will print +.ft I +a +.ft +factorial if +.ft I +a +.ft +is a positive integer. +Here is the definition of a function which will +compute values of the binomial coefficient +(m and n are assumed to be positive integers). +.DS +.ft B +define b(n,m){ +auto x, j +x=1 +for(j=1; j<=m; j=j+1) x=x*(n\-j+1)/j +return(x) +} +.ft P +.DE +The following function computes values of the exponential function +by summing the appropriate series +without regard for possible truncation errors: +.DS +.ft B +scale = 20 +define e(x){ + auto a, b, c, d, n + a = 1 + b = 1 + c = 1 + d = 0 + n = 1 + while(1==1){ + a = a*x + b = b*n + c = c + a/b + n = n + 1 + if(c==d) return(c) + d = c + } +} +.ft P +.DE +.SH +Some Details +.PP +There are some language features that every user should know +about even if he will not use them. +.PP +Normally statements are typed one to a line. It is also permissible +to type several statements on a line separated by semicolons. +.PP +If an assignment statement is parenthesized, it then has +a value and it can be used anywhere that an expression can. +For example, the line +.DS +.ft B +(x=y+17) +.ft P +.DE +not only makes the indicated assignment, but also prints the +resulting value. +.PP +Here is an example of a use of the value of an +assignment statement even when it is not parenthesized. +.DS +.ft B +x = a[i=i+1] +.ft P +.DE +causes a value to be assigned to x and also increments i +before it is used as a subscript. +.PP +The following constructs work in BC in exactly the same manner +as they do in the C language. Consult the appendix or the +C manuals [2] for their exact workings. +.DS +.ft B +.ta 2i +x=y=z is the same as x=(y=z) +x += y x = x+y +x \-= y x = x\-y +x *= y x = x*y +x /= y x = x/y +x %= y x = x%y +x ^= y x = x^y +x++ (x=x+1)\-1 +x\-\- (x=x\-1)+1 +++x x = x+1 +\-\-x x = x\-1 +.ft P +.DE +Even if you don't intend to use the constructs, +if you type one inadvertently, something correct but unexpected +may happen. +.SH +Three Important Things +.PP +1. To exit a BC program, type `quit'. +.PP +2. There is a comment convention identical to that of C and +of PL/I. Comments begin with `/*' and end with `*/'. +As a non-portable extension, comments may also start with a `#' and end with +a newline. +The newline is not part of the comment. +.PP +3. There is a library of math functions which may be obtained by +typing at command level +.DS +.ft B +bc \-l +.ft P +.DE +This command will load a set of library functions +which, at the time of writing, consists of sine (named `s'), +cosine (`c'), arctangent (`a'), natural logarithm (`l'), +exponential (`e') and Bessel functions of integer order (`j(n,x)'). Doubtless more functions will be added +in time. +The library sets the scale to 20. You can reset it to something +else if you like. +The design of these mathematical library routines +is discussed elsewhere [3]. +.PP +If you type +.DS +.ft B +bc file ... +.ft P +.DE +BC will read and execute the named file or files before accepting +commands from the keyboard. In this way, you may load your +favorite programs and function definitions. +.SH +Acknowledgement +.PP +The compiler is written in YACC [4]; its original +version was written by S. C. Johnson. +.SH +References +.IP [1] +K. Thompson and D. M. Ritchie, +.ft I +UNIX Programmer's Manual, +.ft +Bell Laboratories, +1978. +.IP [2] +B. W. Kernighan and +D. M. Ritchie, +.ft I +The C Programming Language, +.ft +Prentice-Hall, 1978. +.IP [3] +R. Morris, +.ft I +A Library of Reference Standard Mathematical Subroutines, +.ft +Bell Laboratories internal memorandum, 1975. +.IP [4] +S. C. Johnson, +.ft I +YACC \(em Yet Another Compiler-Compiler. +.ft +Bell Laboratories Computing Science Technical Report #32, 1978. +.IP [5] +R. Morris and L. L. Cherry, +.ft I +DC \- An Interactive Desk Calculator. +.ft +.LP +.bp +.ft B +.DS C +Appendix +.DE +.ft +.NH +Notation +.PP +In the following pages syntactic categories are in \fIitalics\fP; +literals are in \fBbold\fP; material in brackets [\|] is optional. +.NH +Tokens +.PP +Tokens consist of keywords, identifiers, constants, operators, +and separators. +Token separators may be blanks, tabs or comments. +Newline characters or semicolons separate statements. +.NH 2 +Comments +.PP +Comments are introduced by the characters /* and terminated by +*/. +As a non-portable extension, comments may also start with a # and +end with a newline. +The newline is not part of the comment. +.NH 2 +Identifiers +.PP +There are three kinds of identifiers \- ordinary identifiers, array identifiers +and function identifiers. +All three types consist of single lower-case letters. +Array identifiers are followed by square brackets, possibly +enclosing an expression describing a subscript. +Arrays are singly dimensioned and may contain up to 2048 +elements. +Indexing begins at zero so an array may be indexed from 0 to 2047. +Subscripts are truncated to integers. +Function identifiers are followed by parentheses, possibly enclosing arguments. +The three types of identifiers do not conflict; +a program can have a variable named \fBx\fP, +an array named \fBx\fP and a function named \fBx\fP, all of which are separate and +distinct. +.NH 2 +Keywords +.PP +The following are reserved keywords: +.ft B +.ta .5i 1.0i +.nf + ibase if + obase break + scale define + sqrt auto + length return + while quit + for continue + else last + print +.fi +.ft +.NH 2 +Constants +.PP +Constants consist of arbitrarily long numbers +with an optional decimal point. +The hexadecimal digits \fBA\fP\-\fBF\fP are also recognized as digits with +values 10\-15, respectively. +.NH 1 +Expressions +.PP +The value of an expression is printed unless the main +operator is an assignment. +The value printed is assigned to the special variable \fBlast\fP. +A single dot may be used as a synonym for \fBlast\fP. +This is a non-portable extension. +Precedence is the same as the order +of presentation here, with highest appearing first. +Left or right associativity, where applicable, is +discussed with each operator. +.bp +.NH 2 +Primitive expressions +.NH 3 +Named expressions +.PP +Named expressions are +places where values are stored. +Simply stated, +named expressions are legal on the left +side of an assignment. +The value of a named expression is the value stored in the place named. +.NH 4 +\fIidentifiers\fR +.PP +Simple identifiers are named expressions. +They have an initial value of zero. +.NH 4 +\fIarray-name\fP\|[\|\fIexpression\fP\|] +.PP +Array elements are named expressions. +They have an initial value of zero. +.NH 4 +\fBscale\fR, \fBibase\fR and \fBobase\fR +.PP +The internal registers +\fBscale\fP, \fBibase\fP and \fBobase\fP are all named expressions. +\fBscale\fP is the number of digits after the decimal point to be +retained in arithmetic operations. +\fBscale\fR has an initial value of zero. +\fBibase\fP and \fBobase\fP are the input and output number +radix respectively. +Both \fBibase\fR and \fBobase\fR have initial values of 10. +.NH 3 +Function calls +.NH 4 +\fIfunction-name\fB\|(\fR[\fIexpression\fR\|[\fB,\|\fIexpression\|\fR.\|.\|.\|]\|]\fB) +.PP +A function call consists of a function name followed by parentheses +containing a comma-separated list of +expressions, which are the function arguments. +A whole array passed as an argument is specified by the +array name followed by empty square brackets. +All function arguments are passed by +value. +As a result, changes made to the formal parameters have +no effect on the actual arguments. +If the function terminates by executing a return +statement, the value of the function is +the value of the expression in the parentheses of the return +statement or is zero if no expression is provided +or if there is no return statement. +.NH 4 +sqrt\|(\|\fIexpression\fP\|) +.PP +The result is the square root of the expression. +The result is truncated in the least significant decimal place. +The scale of the result is +the scale of the expression or the +value of +.ft B +scale, +.ft +whichever is larger. +.NH 4 +length\|(\|\fIexpression\fP\|) +.PP +The result is the total number of significant decimal digits in the expression. +The scale of the result is zero. +.NH 4 +scale\|(\|\fIexpression\fP\|) +.PP +The result is the scale of the expression. +The scale of the result is zero. +.NH 3 +Constants +.PP +Constants are primitive expressions. +.NH 3 +Parentheses +.PP +An expression surrounded by parentheses is +a primitive expression. +The parentheses are used to alter the +normal precedence. +.NH 2 +Unary operators +.PP +The unary operators +bind right to left. +.NH 3 +\-\|\fIexpression\fP *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** _______________________________________________ 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-current@FreeBSD.ORG Wed Jan 20 23:20:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7241065670 for ; Wed, 20 Jan 2010 23:20:16 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0F5FF8FC16 for ; Wed, 20 Jan 2010 23:20:15 +0000 (UTC) Received: by fxm10 with SMTP id 10so2565522fxm.34 for ; Wed, 20 Jan 2010 15:20:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tkZ4LWJmQjJALYferkolNhy+GTFft1tyy98Kd0772wM=; b=B4aPdvf4W7pOhL2Q9g0xlA0wA4SjH9f7FahFdh1byGkfccbW4wyVQKPy/hOH90faql 5sfToEF4ByUAhqBKc3USgj7bHxqtnGDXot3jxww/79FqQC+wOd7t9W2jVX7v/iMc0rMy CG5ADIhxbYQQWFWgNYNjjlusWw2siCiIueYlQ= 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=j3b5dSBOxd7f3fP4yWOUVURZmIzhBY5xlgZzv2DMPJzQrBiScrsfkPGarfVWXp7eGh ijaJ53E2dhiwxiqnqXn2aK934vofRL+UmfQ4QqYphoKzNDB6Y1yL6OzpzPdP8luADafG 8u4TJpEdty/AfqyOc0oVfifLLa7duv6bMwv4U= MIME-Version: 1.0 Received: by 10.87.2.15 with SMTP id e15mr1214957fgi.22.1264029614769; Wed, 20 Jan 2010 15:20:14 -0800 (PST) In-Reply-To: <20100120162326.GD50360@dan.emsphone.com> References: <20100120162326.GD50360@dan.emsphone.com> Date: Thu, 21 Jan 2010 09:50:14 +1030 Message-ID: From: Matt Thyer To: Dan Nelson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 23:20:16 -0000 2010/1/21 Dan Nelson > In the last episode (Jan 21), Matt Thyer said: > > I typically buildworld with a parallel make of hw.ncpu * 3 which results > > in -j24 on my new system (Intel Core i7-860, 8GB RAM). > [snip] > > Build failure is: > > > > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h > > > /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim_asn1.h > > cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h > > pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h > > /usr/obj/usr/src/tmp/usr/include > > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libasn1.so.10 > > /usr/obj/usr/src/tmp/usr/lib > > ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > It's much more likely to be a Makefile dependency problem than a ZFS bug. > You will need to look much farther up in your log to see the real error > message. Make will wait for the other 23 jobs to finish before returning, > so what you posted was the output of one of the other jobs, plus the output > of each parent make as it exits with an error code. > This was my first thought so I grepped my log for "error" in a case insensitive way and found nothing. That's why I think that it may be a file system issue as the line prior to the link is the installation of the "libasn1.so.10" shared library. I have now installed the same JPSNAP on another identical hard disk (300GB Seagate SATA) in a UFS only system and will test again shortly. > -- > Dan Nelson > dnelson@allantgroup.com > From owner-freebsd-current@FreeBSD.ORG Wed Jan 20 23:50:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95D88106566C for ; Wed, 20 Jan 2010 23:50:29 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2928FC0C for ; Wed, 20 Jan 2010 23:50:29 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o0KNoPQH069140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 17:50:25 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o0KNoOPJ077793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2010 17:50:25 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o0KNoOWB077790; Wed, 20 Jan 2010 17:50:24 -0600 (CST) (envelope-from dan) Date: Wed, 20 Jan 2010 17:50:24 -0600 From: Dan Nelson To: Matt Thyer Message-ID: <20100120235024.GE50360@dan.emsphone.com> References: <20100120162326.GD50360@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Wed, 20 Jan 2010 17:50:26 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: current@freebsd.org Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 23:50:29 -0000 In the last episode (Jan 21), Matt Thyer said: > 2010/1/21 Dan Nelson > > In the last episode (Jan 21), Matt Thyer said: > > > I typically buildworld with a parallel make of hw.ncpu * 3 which > > > results in -j24 on my new system (Intel Core i7-860, 8GB RAM). [...] > > > Build failure is: > > > > > > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h > > > /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim_asn1.h > > > cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h > > > pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h > > > /usr/obj/usr/src/tmp/usr/include > > > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libasn1.so.10 > > > /usr/obj/usr/src/tmp/usr/lib > > > ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so > > > 1 error > > > *** Error code 2 > > > 1 error > > > *** Error code 2 > > > 1 error > > > *** Error code 2 > > > 1 error > > > > It's much more likely to be a Makefile dependency problem than a ZFS > > bug. You will need to look much farther up in your log to see the real > > error message. Make will wait for the other 23 jobs to finish before > > returning, so what you posted was the output of one of the other jobs, > > plus the output of each parent make as it exits with an error code. > > This was my first thought so I grepped my log for "error" in a case > insensitive way and found nothing. That's why I think that it may be a > file system issue as the line prior to the link is the installation of the > "libasn1.so.10" shared library. I have now installed the same JPSNAP on > another identical hard disk (300GB Seagate SATA) in a UFS only system and > will test again shortly. Since the ln command didn't print an error message itself, it's unlikely to have caused the build to fail. Try searching for "***" or ":" instead. You can try adding -v or -P to your initial make commandline; either will add extra lines to parallel builds that make it easier to tell exactly what make target caused a failure. I don't know if they will cause issues with the buildworld framework, though. Try running "make -j2", "make -v -j2", and "make -P -j2" on the following Makefile to see what the flags do: ( indented lines have leading tabs ) test: test1 test2 test1: @sleep 1 @false test2: @echo "hi I'm a successful target" -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 00:56:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A78F3106566B; Thu, 21 Jan 2010 00:56:56 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0BBA08FC17; Thu, 21 Jan 2010 00:56:55 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0L0sEZ8028807; Thu, 21 Jan 2010 11:24:14 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Thu, 21 Jan 2010 11:26:54 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 11:26:54 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 08:56:51 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0L0pCFa052835; Thu, 21 Jan 2010 08:51:12 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0L0pC7E052834; Thu, 21 Jan 2010 08:51:12 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 21 Jan 2010 08:51:12 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Message-ID: <20100121005111.GB48329@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org References: <20100120083726.GK46479@stlux503.dsto.defence.gov.au> <201001201013.07894.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <201001201013.07894.hselasky@c2i.net> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 21 Jan 2010 00:56:51.0317 (UTC) FILETIME=[9DFEAA50:01CA9A34] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17144.001 X-TM-AS-Result: No--15.390900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: multimedia/libv4l/ (video4bsd.ko) -> Fatal trap 12: page fault while in kernel mode [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 00:56:56 -0000 0n Wed, Jan 20, 2010 at 10:13:07AM +0100, Hans Petter Selasky wrote: >On Wednesday 20 January 2010 09:37:26 Wilkinson, Alex wrote: >> The following ports initially installed and worked fine: >> >> multimedia/libv4l >> multimedia/webcamd >> multimedia/pwcview >> >> however, after a reboot video4bsd.ko panic'd my machine and i was unable to >> boot. I had to use the LiveFS to rescue the box. Here is the bt from DDB: > >This issue is fixed. Just update the ports. Ah, yep. Updating multimedia/video4bsd-kmod/ fixed this issue. Thanks! -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 01:09:22 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A0991065692 for ; Thu, 21 Jan 2010 01:09:22 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from raven.customer.vol.cz (raven.customer.vol.cz [195.250.144.108]) by mx1.freebsd.org (Postfix) with ESMTP id D004A8FC12 for ; Thu, 21 Jan 2010 01:09:21 +0000 (UTC) Received: from [192.168.0.23] (r2bb217.net.upc.cz [62.245.117.217]) (authenticated bits=0) by raven.customer.vol.cz (8.14.3/8.14.3) with ESMTP id o0L0gGP8016456 for ; Thu, 21 Jan 2010 01:42:18 +0100 (CET) (envelope-from pav@FreeBSD.org) From: Pav Lucistnik To: current@FreeBSD.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fMkKaWyRiqX71UowkVIR" Date: Thu, 21 Jan 2010 01:42:16 +0100 Message-ID: <1264034536.1541.113.camel@hood.oook.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-Scanned-By: MIMEDefang 2.67 on 195.250.144.108 X-Milter: Spamilter (Reciever: raven.customer.vol.cz; Sender-ip: 62.245.117.217; Sender-helo: [192.168.0.23]; ) Cc: Subject: cvsup crashing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 01:09:22 -0000 --=-fMkKaWyRiqX71UowkVIR Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable We updated -CURRENT on pointyhat to r202579M: Tue Jan 19 08:43:56 UTC 2010 and now cvsup is catching SIGILL on every run updating ports checkout, in gmtime_r(). Any insights? --=20 Pav Lucistnik Angband in action! Constant escalation to new depths to find angrier, meaner letters and more punctuation! --=-fMkKaWyRiqX71UowkVIR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAktXoucACgkQntdYP8FOsoK9mQCfTj0A/8zi3otiBkpp5Xp20PFP U+sAoMETcGlmpy2Tx58bMr+0QgwlTTW9 =awJP -----END PGP SIGNATURE----- --=-fMkKaWyRiqX71UowkVIR-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 01:19:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0980210656A4 for ; Thu, 21 Jan 2010 01:19:00 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1EC8FC08 for ; Thu, 21 Jan 2010 01:18:59 +0000 (UTC) Received: by fxm10 with SMTP id 10so2640788fxm.34 for ; Wed, 20 Jan 2010 17:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=wfcDJ6bhWUx5vN4gALFbv6IIb1aIjII31hoQXqHXgZ0=; b=CEXmYOOo9NGQUI3i7NJLqPbfbHVekHrybDj0QLEiHBtFLup9qzCz7Fgco8yhxuU/Bv 3Cr3l1pnnpATLGxcHCH9MT/6zOebpwQbV9WBNTnvZ8K3ztw20E+kKbCZg13CHCQg1ePM b5daw07Z3Q1qpUQ2NHnuJ/p6rPGp+3A9k3LyE= 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=JQYoBQ0bNWNa/qC5HUNr8RrSerbQabwpDD/akC/9dlKYWZndRtU8eUgh/22w++ND+y uuw2U4qn98BEyCMVKsAoZj/I+L2hrcbWLw5Q1WiGH0YavCl3deQATDCDNcS0ESjeT6TW aUBwpJSf56Q2OZW9EACDec4LvDvBLsPFWUv3c= MIME-Version: 1.0 Received: by 10.87.5.15 with SMTP id h15mr1351698fgi.43.1264036738295; Wed, 20 Jan 2010 17:18:58 -0800 (PST) In-Reply-To: <20100120235024.GE50360@dan.emsphone.com> References: <20100120162326.GD50360@dan.emsphone.com> <20100120235024.GE50360@dan.emsphone.com> Date: Thu, 21 Jan 2010 11:48:58 +1030 Message-ID: From: Matt Thyer To: Dan Nelson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 01:19:00 -0000 2010/1/21 Dan Nelson > In the last episode (Jan 21), Matt Thyer said: > > 2010/1/21 Dan Nelson > > > In the last episode (Jan 21), Matt Thyer said: > > > > I typically buildworld with a parallel make of hw.ncpu * 3 which > > > > results in -j24 on my new system (Intel Core i7-860, 8GB RAM). > [...] > > > > Build failure is: > > > > > > > > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h > > > > > /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim_asn1.h > > > > cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h > > > > pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h > > > > /usr/obj/usr/src/tmp/usr/include > > > > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 > libasn1.so.10 > > > > /usr/obj/usr/src/tmp/usr/lib > > > > ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so > > > > 1 error > > > > *** Error code 2 > > > > 1 error > > > > *** Error code 2 > > > > 1 error > > > > *** Error code 2 > > > > 1 error > > > > > > It's much more likely to be a Makefile dependency problem than a ZFS > > > bug. You will need to look much farther up in your log to see the real > > > error message. Make will wait for the other 23 jobs to finish before > > > returning, so what you posted was the output of one of the other jobs, > > > plus the output of each parent make as it exits with an error code. > > > > This was my first thought so I grepped my log for "error" in a case > > insensitive way and found nothing. That's why I think that it may be a > > file system issue as the line prior to the link is the installation of > the > > "libasn1.so.10" shared library. I have now installed the same JPSNAP on > > another identical hard disk (300GB Seagate SATA) in a UFS only system and > > will test again shortly. > > Since the ln command didn't print an error message itself, it's unlikely to > have caused the build to fail. Try searching for "***" or ":" instead. [...] You are correct. I missed the error the first time. It is: make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop *** Error code 2 From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 01:29:46 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 846D1106568D; Thu, 21 Jan 2010 01:29:46 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 5224E8FC19; Thu, 21 Jan 2010 01:29:46 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.4/8.14.4) with ESMTP id o0L1TjLR076217; Wed, 20 Jan 2010 19:29:45 -0600 (CST) (envelope-from scf@FreeBSD.org) Date: Wed, 20 Jan 2010 19:29:45 -0600 (CST) From: "Sean C. Farley" To: Pav Lucistnik In-Reply-To: <1264034536.1541.113.camel@hood.oook.cz> Message-ID: References: <1264034536.1541.113.camel@hood.oook.cz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.farley.org Cc: current@FreeBSD.org Subject: Re: cvsup crashing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 01:29:46 -0000 On Thu, 21 Jan 2010, Pav Lucistnik wrote: > We updated -CURRENT on pointyhat to r202579M: Tue Jan 19 08:43:56 UTC > 2010 and now cvsup is catching SIGILL on every run updating ports > checkout, in gmtime_r(). Any insights? Is it anything similar to this thread[1]? Sean 1. http://lists.freebsd.org/pipermail/freebsd-current/2009-December/013946.html -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 01:47:08 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B5191065670 for ; Thu, 21 Jan 2010 01:47:08 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 383B08FC19 for ; Thu, 21 Jan 2010 01:47:07 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o0L1Qigw023247; Wed, 20 Jan 2010 20:26:44 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 20 Jan 2010 20:26:45 -0500 (EST) Date: Wed, 20 Jan 2010 20:26:44 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Matt Thyer In-Reply-To: Message-ID: References: <20100120162326.GD50360@dan.emsphone.com> <20100120235024.GE50360@dan.emsphone.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dan Nelson , current@freebsd.org Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 01:47:08 -0000 On Thu, 21 Jan 2010, Matt Thyer wrote: > 2010/1/21 Dan Nelson > >> >> Since the ln command didn't print an error message itself, it's unlikely to >> have caused the build to fail. Try searching for "***" or ":" instead. > > > [...] > > You are correct. I missed the error the first time. It is: > > make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop > *** Error code 2 It happens with -j8 also (amd64, UFS). -- DE From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 02:48:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5ECA1065679; Thu, 21 Jan 2010 02:48:40 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3AAC98FC1F; Thu, 21 Jan 2010 02:48:39 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0L2jxkM017204; Thu, 21 Jan 2010 13:15:59 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Thu, 21 Jan 2010 13:18:38 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 13:18:38 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 10:48:36 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0L2gvHh053476; Thu, 21 Jan 2010 10:42:57 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0L2gvo7053475; Thu, 21 Jan 2010 10:42:57 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 21 Jan 2010 10:42:57 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Message-ID: <20100121024257.GD48329@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 21 Jan 2010 02:48:36.0645 (UTC) FILETIME=[3AAE8550:01CA9A44] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17144.001 X-TM-AS-Result: No--2.323800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: libv4l2: error converting / decoding frame data: v4l-convert: ... [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 02:48:40 -0000 [FreeBSD 9.0-CURRENT #1 r202680M: Thu Jan 21 09:35:32] pwcview(1) is consistently crashing on me today with the following: #sudo pwcview Webcam set to: 320x240 (sif) at 5 fps libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Bogus jpeg format Error reading from webcam: Input/output error -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 08:07:56 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 724DA106566B for ; Thu, 21 Jan 2010 08:07:56 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from raven.customer.vol.cz (raven.customer.vol.cz [195.250.144.108]) by mx1.freebsd.org (Postfix) with ESMTP id F3E2A8FC24 for ; Thu, 21 Jan 2010 08:07:55 +0000 (UTC) Received: from [172.19.10.16] (nat-application.b1.lan.prg.vol.cz [195.122.204.152]) (authenticated bits=0) by raven.customer.vol.cz (8.14.3/8.14.3) with ESMTP id o0L87q1V050268; Thu, 21 Jan 2010 09:07:53 +0100 (CET) (envelope-from pav@FreeBSD.org) From: Pav Lucistnik To: "Sean C. Farley" In-Reply-To: References: <1264034536.1541.113.camel@hood.oook.cz> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-v4h2czMWeUuHOXVnJ54F" Date: Thu, 21 Jan 2010 09:07:51 +0100 Message-ID: <1264061271.53586.40.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-Scanned-By: MIMEDefang 2.67 on 195.250.144.108 X-Milter: Spamilter (Reciever: raven.customer.vol.cz; Sender-ip: 195.122.204.152; Sender-helo: [172.19.10.16]; ) Cc: current@FreeBSD.org Subject: Re: cvsup crashing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 08:07:56 -0000 --=-v4h2czMWeUuHOXVnJ54F Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sean C. Farley p=ED=B9e v st 20. 01. 2010 v 19:29 -0600: > On Thu, 21 Jan 2010, Pav Lucistnik wrote: >=20 > > We updated -CURRENT on pointyhat to r202579M: Tue Jan 19 08:43:56 UTC=20 > > 2010 and now cvsup is catching SIGILL on every run updating ports=20 > > checkout, in gmtime_r(). Any insights? >=20 > Is it anything similar to this thread[1]? >=20 > Sean > 1. http://lists.freebsd.org/pipermail/freebsd-current/2009-December/01= 3946.html Removing that UTC zoneinfo file fixed it here. --=20 Pav Lucistnik XML is a giant step in no direction at all. -- Erik Naggum --=-v4h2czMWeUuHOXVnJ54F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAktYC1YACgkQntdYP8FOsoLExgCgubwVsCW43MLL3YNPUnwIBQo3 B50AnjIyGFYL7WHNBehXIK12EcHtRUpA =95kh -----END PGP SIGNATURE----- --=-v4h2czMWeUuHOXVnJ54F-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 09:43:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C69106566C; Thu, 21 Jan 2010 09:43:42 +0000 (UTC) (envelope-from james-freebsd-current@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 556CA8FC17; Thu, 21 Jan 2010 09:43:41 +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 o0L9hfBO035553; Thu, 21 Jan 2010 03:43:41 -0600 (CST) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@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=JHdsjg8kxCMPGOiIgAEo2yod6LGmTRHvpwDwL5ifwgnrx7kAYbGIN9T+2k3yFWdWJ A8dH8m0oTA83JYWB4EKtxfXC+sqUKDlhFyMML7LJ5ScGUMa0QT64bRJcRA+YMqa1IJ8 ceN7WrIV+V6+VFRQqgO6hCfwlAk69NSHyxXlRfA= Message-ID: <4B5821CD.7070009@jrv.org> Date: Thu, 21 Jan 2010 03:43:41 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Kostik Belousov References: <20091128111501.34a7a2a4@ernst.jennejohn.org> <200912011009.59961.jhb@freebsd.org> <20091201204154.GC2368@deviant.kiev.zoral.com.ua> In-Reply-To: <20091201204154.GC2368@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: core dump in cvsup caused by _once()? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 09:43:42 -0000 >From early December: Kostik Belousov wrote: >>>> >> > Could you, please, also recompile rtld with debugging symbols ? > > SIGILL might be generated by kernel when signal frame cannot be copied > out to usermode stack. Check out the registers content and size of > stack too. Was this ever root caused? Unless the fault address being reported is wrong I don't see why the CALL fails. Is there a way to dump the CS: selector values to make sure the target address of the CALL is accessible that way? How to tell if that page is executable? OF interest: I have two bootable disks at svn 200727 on this system and the other doesn't crash here. The other was installed at 8.0-RELEASE and this one date from last summer, both upgraded to svn 200727 by installworld etc. However another system was originally installed a year ago, likewise upgrades since to 200727, and does not fail like this: bigback:/root# uname -a FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r200727M: Wed Jan 20 12:28:18 UTC 2010 root@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 bigback:/root# gdb cvsup GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) run ports-supfile Starting program: /usr/local/bin/cvsup ports-supfile Connected to cvsup10.FreeBSD.org Updating collection ports-all/cvs Edit ports/CHANGES Program received signal SIGSEGV, Segmentation fault. 0x00000008009fef3b in tzload (name=0x800a2d8e1 "posixrules", sp=0x7c0ed8, doextend=0) at /usr/src/lib/libc/stdtime/localtime.c:393 393 if (name != NULL && issetugid() != 0) (gdb) x/i $pc 0x8009fef3b : callq 0x80095a5dc <_init+6196> (gdb) x/20i tzload 0x8009feef0 : mov %rbx,0xffffffffffffffd0(%rsp) 0x8009feef5 : mov %r12,0xffffffffffffffe0(%rsp) 0x8009feefa : mov %rdi,%rbx 0x8009feefd : mov %r13,0xffffffffffffffe8(%rsp) 0x8009fef02 : mov %r14,0xfffffffffffffff0(%rsp) 0x8009fef07 : mov %rsi,%r12 0x8009fef0a : mov %rbp,0xffffffffffffffd8(%rsp) 0x8009fef0f : mov %r15,0xfffffffffffffff8(%rsp) 0x8009fef14 : sub $0xeea8,%rsp 0x8009fef1b : mov 1364782(%rip),%r14 # 0x800b4c250 <__thr_jtable+90512> 0x8009fef22 : mov %edx,%r13d 0x8009fef25 : mov (%r14),%rax 0x8009fef28 : mov %rax,0xee68(%rsp) 0x8009fef30 : xor %eax,%eax 0x8009fef32 : test %rdi,%rdi 0x8009fef35 : je 0x8009ff090 0x8009fef3b : callq 0x80095a5dc <_init+6196> 0x8009fef40 : test %eax,%eax 0x8009fef42 : jne 0x8009ff062 0x8009fef48 : movzbl (%rbx),%ebp (gdb) x/5i 0x80095a5dc 0x80095a5dc <_init+6196>: jmpq *2035238(%rip) # 0x800b4b408 <__thr_jtable+86856> 0x80095a5e2 <_init+6202>: pushq $0x181 0x80095a5e7 <_init+6207>: jmpq 0x800958dbc <_init+20> 0x80095a5ec <_init+6212>: jmpq *2035230(%rip) # 0x800b4b410 <__thr_jtable+86864> 0x80095a5f2 <_init+6218>: pushq $0x182 (gdb) bt #0 0x00000008009fef3b in tzload (name=0x800a2d8e1 "posixrules", sp=0x7c0ed8, doextend=0) at /usr/src/lib/libc/stdtime/localtime.c:393 #1 0x00000008009fe9ce in tzparse (name=0x7b6ced "", sp=0x7c0ed8, lastditch=Variable "lastditch" is not available. ) at /usr/src/lib/libc/stdtime/localtime.c:1002 #2 0x00000008009ff6a6 in tzload (name=Variable "name" is not available. ) at /usr/src/lib/libc/stdtime/localtime.c:579 #3 0x00000008009ff8b8 in gmtload (sp=0x800b601c0) at /usr/src/lib/libc/stdtime/localtime.c:1197 #4 0x0000000800a02ca8 in _once (once_control=0x800b5ba00, init_routine=Variable "init_routine" is not available. ) at /usr/src/lib/libc/gen/_once_stub.c:43 #5 0x00000008009fe64f in gmtsub (timep=0x7c5bb8, offset=0, tmp=0x800b64a60) at /usr/src/lib/libc/stdtime/localtime.c:1489 #6 0x00000008009fff27 in gmtime (timep=0x7c5bb8) at /usr/src/lib/libc/stdtime/localtime.c:1550 #7 0x00000000004a643a in calloc () #8 0x000000000043aec7 in ?? () #9 0x0000000000448eaa in ?? () #10 0x0000000000409ece in ?? () #11 0x00000000004191a4 in ?? () #12 0x0000000000417cbe in ?? () #13 0x000000000041529f in ?? () #14 0x0000000000414d7a in ?? () #15 0x000000000049f980 in calloc () #16 0x000000000048fa3d in fnmatch () #17 0x00007fffffffd3b8 in ?? () #18 0x00007fffffffe920 in ?? () #19 0x00007fffffffea10 in ?? () #20 0x00007fffffffe9f8 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x00001fa00000037f in ?? () #24 0x0000000000000000 in ?? () #25 0x00000000006476c0 in ?? () #26 0x00000000006476c0 in ?? () #27 0x0000000000494d89 in fnmatch () Previous frame inner to this frame (corrupt stack?) (gdb) info all-reg rax 0x0 0 rbx 0x800a2d8e1 34370410721 rcx 0xa7 167 rdx 0x0 0 rsi 0x7c0ed8 8130264 rdi 0x800a2d8e1 34370410721 rbp 0x7c0ed8 0x7c0ed8 rsp 0x7a7c68 0x7a7c68 r8 0x0 0 r9 0x0 0 r10 0x1f6 502 r11 0x682880 6826112 r12 0x7c0ed8 8130264 r13 0x0 0 r14 0x800b53920 34371615008 r15 0x7b6ce9 8088809 rip 0x8009fef3b 0x8009fef3b eflags 0x10206 66054 cs 0x43 67 ss 0x3b 59 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 st0 0 (raw 0x00000000000000000000) st1 0 (raw 0x00000000000000000000) st2 0 (raw 0x00000000000000000000) st3 0 (raw 0x00000000000000000000) st4 0 (raw 0x00000000000000000000) st5 0 (raw 0x00000000000000000000) st6 104.4456787109375 (raw 0x4005d0e4300000000000) st7 104.4456787109375 (raw 0x4005d0e4300000000000) fctrl 0x37f 895 fstat 0x0 0 ftag 0xffff 65535 fiseg 0x43 67 fioff 0x99b58c 10073484 foseg 0x3b 59 fooff 0x7c59f0 8149488 fop 0x55c 1372 xmm0 {f = {0x0, 0x1, 0x0, 0x0}} {f = {0, 1.75, 0, 0}} xmm1 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm2 {f = {0x0, 0x1, 0x0, 0x0}} {f = {-1.81759241e-12, 1.70399642, 0, 0}} xmm3 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm4 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm5 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm6 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm7 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm8 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm9 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm10 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm11 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm12 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm13 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm14 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm15 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} mxcsr 0x1fa0 8096 (gdb) From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 10:29:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E4E1065670 for ; Thu, 21 Jan 2010 10:29:00 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC2E8FC13 for ; Thu, 21 Jan 2010 10:29:00 +0000 (UTC) Received: from [195.4.92.16] (helo=6.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NXuHa-0003eI-Tp for freebsd-current@freebsd.org; Thu, 21 Jan 2010 11:28:58 +0100 Received: from p57ae1dcd.dip0.t-ipconnect.de ([87.174.29.205]:22434 helo=ernst.jennejohn.org) by 6.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NXuHa-0008NV-LG for freebsd-current@freebsd.org; Thu, 21 Jan 2010 11:28:58 +0100 Date: Thu, 21 Jan 2010 11:28:58 +0100 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20100121112858.605cb788@ernst.jennejohn.org> In-Reply-To: <1264061271.53586.40.camel@pav.hide.vol.cz> References: <1264034536.1541.113.camel@hood.oook.cz> <1264061271.53586.40.camel@pav.hide.vol.cz> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: cvsup crashing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 10:29:00 -0000 On Thu, 21 Jan 2010 09:07:51 +0100 Pav Lucistnik wrote: > Sean C. Farley p____e v st 20. 01. 2010 v 19:29 -0600: > > On Thu, 21 Jan 2010, Pav Lucistnik wrote: > > > > > We updated -CURRENT on pointyhat to r202579M: Tue Jan 19 08:43:56 UTC > > > 2010 and now cvsup is catching SIGILL on every run updating ports > > > checkout, in gmtime_r(). Any insights? > > > > Is it anything similar to this thread[1]? > > > > Sean > > 1. http://lists.freebsd.org/pipermail/freebsd-current/2009-December/013946.html > > Removing that UTC zoneinfo file fixed it here. > Removing this file doesn't seem to have any ill effects, but having it present most definitely does. Myabe it shouldn't be installed at all? --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 11:21:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FBA810656A5 for ; Thu, 21 Jan 2010 11:21:10 +0000 (UTC) (envelope-from shigeru@iij.ad.jp) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9B88FC1D for ; Thu, 21 Jan 2010 11:21:09 +0000 (UTC) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:Mime-Version:Content-Type: Content-Transfer-Encoding;i=shigeru@iij.ad.jp;s=omgo1;t=1264072037;x= 1265281637; bh=szuPkzHYupuMaAk5ts62LGwCyml0cO6vwmSTjbAxHds=; b=QgvC9OCDhRLVJW+R MpDz1q99Hrue3KtH/zs9Tl6kFKq141W+nbxa6kWirEPFLhIdgAUO3275DZph0TAzUO8Sih6PFPRyD EM/OooIracMhcve+OQxtqe3cbgTdHNjhuYkA4N8PjN/su1alzDQhVFsatnn8agYbHi5xfmYVO+31b g=; Received: by omgo.iij.ad.jp (mo30) id o0LB7HiR006878; Thu, 21 Jan 2010 20:07:17 +0900 Date: Thu, 21 Jan 2010 20:07:14 +0900 (JST) Message-Id: <20100121.200714.902529320050655899.shigeru@iij.ad.jp> To: freebsd-current@freebsd.org From: YAMAMOTO Shigeru X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: is 'sunlabel' required to cross-build 'make release' for sparc64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 11:21:10 -0000 Hi all, I have a question about 'make release' for sparc64 architecture on amd64/i386. release/sparc64/mkisoimages.sh is using 'sunlabel'. But, on amd64/i386, sunlabel is not installed when doing 'make release TARGET_ARCH=sparc64 TARGET=...'. Is it a ploblem? or no ploblem? If it is a bloblem, how do we fix it? 1) fix release/sparc64/mkisoimages.sh. 2) fix 'make release' script/Makefiles to install sunlabel which is cross-builded binary. 3) others Thanks, ------- YAMAMOTO Shigeru From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 12:26:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F27C106566C for ; Thu, 21 Jan 2010 12:26:39 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A86B28FC18 for ; Thu, 21 Jan 2010 12:26:38 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-169.lns6.adl6.internode.on.net [121.45.156.169]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0LCQUY3025802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 21 Jan 2010 22:56:32 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 21 Jan 2010 22:56:23 +1030 User-Agent: KMail/1.9.10 References: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> In-Reply-To: <20100120024245.GD46479@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2267507.VEe9x84caC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001212256.25294.doconnor@gsoft.com.au> X-Spam-Score: -1.664 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-x11@freebsd.org, "Wilkinson, Alex" Subject: Re: code.google -> Xpra (anyone planning to port it ?) [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 12:26:39 -0000 --nextPart2267507.VEe9x84caC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Jan 2010, Wilkinson, Alex wrote: > This looks like a very nice app, has anyone got it working on FreeBSD > yet ? > > http://code.google.com/p/partiwm/wiki/xpra It worked for me, and was pretty straight forward. It has a Linux'ism where it closes all the FD's after demonizing but I=20 have a patch for that (it works without it anyway). The README is very helpful, it mentions what you will need to install=20 (Xvfb, py-gtk2, pyrex, etc). =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2267507.VEe9x84caC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLWEfx5ZPcIHs/zowRAuqVAKClz65b7NREWpP5ldaXAZ0ZE9DDRwCgm/uu omt2tVOr/V+0v9VYy3uyntU= =ijiL -----END PGP SIGNATURE----- --nextPart2267507.VEe9x84caC-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 12:33:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 969B21065670 for ; Thu, 21 Jan 2010 12:33:58 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7EF8FC18 for ; Thu, 21 Jan 2010 12:33:57 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so3463fgg.13 for ; Thu, 21 Jan 2010 04:33:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=pnOezNVr4/2MgN8hfCdDaQ19IeExvrvAU/FVAmLKKiQ=; b=dM9UMJytR0zPijCBp8lLOCN90bLEjYYiOcwNwALJDz3AjE6hXLSmndhiNHkFG5AeH0 bZOP5RccUL1LNkig4cgK7ONxDGSDX2+pd5ctZ0uyKuAH+MHA4ZwiLiob/+4YXMegFY1k EDdUHcJca+8E1N041vKHhzJJiJcreYIeOHOUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=bL8hTE4BBXm/4jkqEXqnvG7SE58Fh0hgTxxdCi/F8r3YCMNYTwQfHO9Opmgk8/KV6Q Yz8b5hgYAeZ3Bsc4sVJsPX3mQ9+5Rqwn5irAprZ2SX9Pvb8hfXkQeUdLEnhpEdaRzcTb 8jg/pJGXTncQHUhRemUgtfQLOoawHj2wAoQt0= MIME-Version: 1.0 Received: by 10.87.48.15 with SMTP id a15mr2287061fgk.66.1264077236781; Thu, 21 Jan 2010 04:33:56 -0800 (PST) Date: Thu, 21 Jan 2010 23:03:56 +1030 Message-ID: From: Matt Thyer To: Daniel Eischen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Dan Nelson , current@freebsd.org Subject: CURRENT buildworld make dependency problem breaking parallel buildworld (Was: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 12:33:58 -0000 2010/1/21 Daniel Eischen > On Thu, 21 Jan 2010, Matt Thyer wrote: > > 2010/1/21 Dan Nelson >> >> >>> Since the ln command didn't print an error message itself, it's unlikely >>> to >>> have caused the build to fail. Try searching for "***" or ":" instead. >>> >> >> >> [...] >> >> You are correct. I missed the error the first time. It is: >> >> make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop >> *** Error code 2 >> > > It happens with -j8 also (amd64, UFS). > > -- > DE > Subject change to attract a wider audience. I have yet to perform a binary search to determine when this problem started but from memory I had no problem on a 32bit CURRENT VM with -j6 on November 22nd 2009. From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 16:38:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 052B71065679 for ; Thu, 21 Jan 2010 16:38:18 +0000 (UTC) (envelope-from ps81@mail.ru) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8607F8FC1D for ; Thu, 21 Jan 2010 16:38:15 +0000 (UTC) Received: from mx74.mail.ru (mx74.mail.ru [94.100.176.89]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id DECBCC3F9C for ; Thu, 21 Jan 2010 18:16:44 +0300 (MSK) Received: from [91.211.28.251] (port=62411 helo=[10.69.13.94]) by mx74.mail.ru with asmtp id 1NXylj-000Hkt-00 for freebsd-current@freebsd.org; Thu, 21 Jan 2010 18:16:25 +0300 Date: Thu, 21 Jan 2010 18:16:22 +0300 From: "ps81@mail.ru" To: "freebsd-current-request@freebsd.org" Message-ID: <1364614396.20100121181622@mail.ru> In-reply-to: <20100121014719.A3A111065798@hub.freebsd.org> References: <20100121014719.A3A111065798@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Mras: Ok Subject: Re: freebsd-current Digest, Vol 327, Issue 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:38:18 -0000 =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, Freebsd-current-request. =C2=FB =EF=E8=F1=E0=EB=E8 21 =FF=ED=E2=E0=F0=FF 2010 =E3., 4:47:19: > Send freebsd-current mailing list submissions to > freebsd-current@freebsd.org > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-request@freebsd.org > You can reach the person managing the list at > freebsd-current-owner@freebsd.org > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > Today's Topics: > 1. Re: Pack of CAM improvements (Henri Hennebert) > 2. stacked unionfs freeze and crash FreeBSD (David Naylor) > 3. Re: Pack of CAM improvements (James R. Van Artsdalen) > 4. Re: bce(4) on IBM BladeCenter HS22 (Oliver Fromme) > 5. Re: stacked unionfs freeze and crash FreeBSD (Gary Jennejohn) > 6. Buildworld failure with -j24 and ZFS on GPT on Core i7-860 > system (Matt Thyer) > 7. Re: stacked unionfs freeze and crash FreeBSD (David Naylor) > 8. Re: stacked unionfs freeze and crash FreeBSD (David Naylor) > 9. Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system (Dan Nelson) > 10. 8.0-STABLE r200182: weird behaviour of a service in a jail (K.R.) > 11. Re: stacked unionfs freeze and crash FreeBSD (Andriy Gapon) > 12. Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing > [SEC=3DUNCLASSIFIED] (Hans Petter Selasky) > 13. Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing > (Hans Petter Selasky) > 14. Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing > (Hans Petter Selasky) > 15. HEADSUP: BSDL bc/dc in head [Was: svn commit: r202719 - in > head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc > usr.bin/dc usr.bin/dc/USD.doc] (Gabor Kovesdan) > 16. Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system (Matt Thyer) > 17. Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system (Dan Nelson) > 18. Re: multimedia/libv4l/ (video4bsd.ko) -> Fatal trap 12: page > fault while in kernel mode [SEC=3DUNCLASSIFIED] (Wilkinson, Alex) > 19. cvsup crashing (Pav Lucistnik) > 20. Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system (Matt Thyer) > 21. Re: cvsup crashing (Sean C. Farley) > 22. Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system (Daniel Eischen) > ---------------------------------------------------------------------- > Message: 1 > Date: Wed, 20 Jan 2010 14:34:07 +0100 > From: Henri Hennebert > Subject: Re: Pack of CAM improvements > To: Alexander Motin > Cc: FreeBSD-Current , FreeBSD Stable > > Message-ID: <4B57064F.9060704@restart.be> > Content-Type: text/plain; charset=3DKOI8-R; format=3Dflowed > On 01/19/2010 17:12, Alexander Motin wrote: >> Hi. >> >> I've made a patch, that should solve set of problems of CAM ATA and CAM >> generally. I would like to ask for testing and feedback. >> >> What patch does: >> - It unifies bus reset/probe sequence. Whenever bus attached at boot or >> later, CAM will automatically reset and scan it. It allows to remove >> duplicate code from many drivers. >> - Any bus, attached before CAM completed it's boot-time initialization, >> will equally join to the process, delaying boot if needed. >> - New kern.cam.boot_delay loader tunable should help controllers that >> are still unable to register their buses in time (such as slow USB/ >> PCCard/ CardBus devices). > With kern.cam.boot_delay=3D15000 (I suppose that it was in ms) I can now > boot from my sim card reader. > Thanks > Henri >> - To allow synchronization between different CAM levels, concept of >> requests priorities was extended. Priorities now split between several >> "run levels". Device can be freezed at specified level, allowing higher >> priority requests to pass. For example, no payload requests allowed, >> until PMP driver enable port. ATA XPT negotiate transfer parameters, >> periph driver configure caching and so on. >> - Frozen requests are no more counted by request allocation scheduler. >> It fixes deadlocks, when frozen low priority payload requests occupying >> slots, required by higher levels to manage theit execution. >> - Two last changes were holding proper ATA reinitialization and error >> recovery implementation. Now it is done: SATA controllers and Port >> Multipliers now implement automatic hot-plug and should correctly >> recover from timeouts and bus resets. >> >> Patch can be found here: >> http://people.freebsd.org/~mav/cam-ata.20100119.patch >> >> Feedback as always welcome. >> > ------------------------------ > Message: 2 > Date: Wed, 20 Jan 2010 15:43:12 +0200 > From: David Naylor > Subject: stacked unionfs freeze and crash FreeBSD > To: freebsd-current@freebsd.org > Message-ID: <201001201543.15818.naylor.b.david@gmail.com> > Content-Type: text/plain; charset=3D"us-ascii" > Skipped content of type multipart/mixed-------------- next part ---------= ----- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 196 bytes > Desc: This is a digitally signed message part. > Url : > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100120/d= 55be9ea/attachment-0001.pgp > ------------------------------ > Message: 3 > Date: Wed, 20 Jan 2010 07:55:24 -0600 > From: "James R. Van Artsdalen" > Subject: Re: Pack of CAM improvements > Cc: Alexander Motin , FreeBSD-Current > > Message-ID: <4B570B4C.9000203@jrv.org> > Content-Type: text/plain; charset=3DISO-8859-1 > Scott Long wrote: >> I've fought many times against delay values like this. They never >> work well enough. > At some point I hope to add support for staggered spin-ups, perhaps a > loader.conf setting for people with more than 20-30 disks. At the > 100-120 disk level it seems unlikely that any reasonable fixed delay > would be reasonable. > ------------------------------ > Message: 4 > Date: Wed, 20 Jan 2010 15:02:01 +0100 (CET) > From: Oliver Fromme > Subject: Re: bce(4) on IBM BladeCenter HS22 > To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com > Message-ID: <201001201402.o0KE21oc010264@lurza.secnetix.de> > Content-Type: text/plain; charset=3DISO-8859-1 > Pyun YongHyeon wrote: >> On Tue, Jan 19, 2010 at 08:23:13PM +0100, Oliver Fromme wrote: >> > Pyun YongHyeon wrote: >> > > Thanks for the detailed information. I vaguely guess bce(4) used >> > > wrong PHY address for controller. How about attached patch? >> > > The patch just reset the PHY address to 1, it's not correct way to >> > > set it but just wants to know whether brgphy(4) is attached to the >> > > PHY. >> >=20 >> > Unfortunately, it produces almost the same output, >> > except the registers now read 0xffff instead of 0x0000: >> >=20 >> :-( >>=20 >> Ok, could you remove the safety belt of bce_miibus_read_reg() to >> allow accessing all PHY address? You can comment out >> sc->bce_phy_addr check in bce_miibus_read_reg() to allow >> mii_phy_probe try to read all 32 possible PHY addresses. >> Does mii(4) probe manage to read something? > No luck, I'm afraid (as was expected). No PHY can be found > on any of the addresses. The PHY addresses 2 and 31 return > 0x0000, all others return 0xffff. > While debugging and searching I found this message from > David Christensen: > http://lists.freebsd.org/pipermail/freebsd-net/2009-August/022648.html > It seems that the PHY on the 5709S is different from the > others and requires some non-trivial code to be written. :-( > I posted a follow-up in the freebsd-net list and copied > David. Maybe he has some news. > This whole issue is quite important. IBM is phasing out > the previous blade generation (HS21), so all new blades > are HS22 which have the BCM5709S interfaces. As it stands > now, FreeBSD cannot be used on IBM blades. > Best regards > Oliver > --=20 > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=E4ftsfuehrun= g: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M=FC= n- > chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Geb= hart > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > "If you aim the gun at your foot and pull the trigger, it's > UNIX's job to ensure reliable delivery of the bullet to > where you aimed the gun (in this case, Mr. Foot)." > -- Terry Lambert, FreeBSD-hackers mailing list. > ------------------------------ > Message: 5 > Date: Wed, 20 Jan 2010 16:28:21 +0100 > From: Gary Jennejohn > Subject: Re: stacked unionfs freeze and crash FreeBSD > To: David Naylor > Cc: freebsd-current@freebsd.org > Message-ID: <20100120162821.3f53af6a@ernst.jennejohn.org> > Content-Type: text/plain; charset=3DUS-ASCII > On Wed, 20 Jan 2010 15:43:12 +0200 > David Naylor wrote: >> Hi, >>=20 >> The attached script, that uses stacked unionfs, causes FreeBSD-9 (cvsup= =20 >> yesterday) to freeze and FreeBSD-8 (cvsup two days ago) to crash: =20 >>=20 >> Fatal double fault >> rip-0xffffffff81e4c1 >> rsp=3D0xffffff80b133ef50 >> rbp=3D0xffffff80b133f150 >> cupid =3D 2; apic id =3D 02 >> panic: double fault >> cpuid =3D 2 >> uptime: 1h44m35s >> cannot dump. Device not defined or unavailable >>=20 >>=20 >> Both systems use the stock GENERIC kernel, i.e. -9 had full diagnostics = built=20 >> in (and was run under VirtualBox) and -8 had no diagnostics (and was run= =20 >> native). =20 >>=20 >> A LOR is produces prior to freezing under -9 (quiet a time prior). See= =20 >> kern/141950. =20 >>=20 >> The script uses unionfs to build ports (in an attempt to create a tinder= box=20 >> without the need to delete and/or extract packages). To use the script = to: >>=20 >> # mkdir /tmp/localbase /tmp/builddir >> # env LOCALBASE=3D/tmp/localbase BUILDDIR=3D/tmp/builddir ./ports-union-= builder.sh >>=20 > Is your /tmp big enough? >> This will try build everything for x11/xorg. =20 >> Is it possible that VirtualBox is interfering in getting usable diagnost= ics=20 >> for -9 >> > Who knows? You might try posting your shell script so others can give > it a whirl on a "real" 9-current system. >> and how can I setup a dump device for -8. Currently I have: >>=20 >> # swapinfo >> Device 1K-blocks Used Avail Capacity >> /dev/ad4s1b 8388608 0 8388608 0% >> /dev/ad8s1b 8388608 0 8388608 0% >> Total 16777216 0 16777216 0% >>=20 > Do you have dumpdev defined in /etc/rc.conf and/or do you see > /dev/dumpdev? Having /dev/dumpdev indicates that dumpon succeeded. > Do you have less than 8GB of memory? See dumpon(8) for restrictions. > --- > Gary Jennejohn > ------------------------------ > Message: 6 > Date: Thu, 21 Jan 2010 01:39:38 +1030 > From: Matt Thyer > Subject: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 > system > To: current@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=3DISO-8859-1 > I typically buildworld with a parallel make of hw.ncpu * 3 which results = in > -j24 on my new system (Intel Core i7-860, 8GB RAM). > I've not been able to buildworld natively on this new system (with ZFS - I > have not tried non-ZFS natively yet) but have been able to buildworld in a > virtual machine under Windows 7 64bit VMware Server 2.0.2 with 2 virtual > CPUs (hence -j6 for buildworld). > Both 8-STABLE 32bit (this VM is non-ZFS) and CURRENT 64bit (a ZFS system) > will build as a VM (-j6) but a native 64bit FreeBSD CURRENT (ZFS) fails. > The CURRENT 64bit systems were installed from the allbsd.org JPSNAP DVD of > 18 Jan 2010 and both can successfully buildworld with -j1 (Virtual and > native). > Build failure is: > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h > /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim_asn1= .h > cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h > pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h > /usr/obj/usr/src/tmp/usr/include > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libasn1.so.10 > /usr/obj/usr/src/tmp/usr/lib > ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > I guess this is a FreeBSD ZFS bug of some kind. > I have not yet prepared another non-ZFS hard disk for native testing (tho= ugh > I do have a spare hard disk available and will test this soon). > ------------------------------ > Message: 7 > Date: Wed, 20 Jan 2010 18:05:54 +0200 > From: David Naylor > Subject: Re: stacked unionfs freeze and crash FreeBSD > To: gary.jennejohn@freenet.de > Cc: freebsd-current@freebsd.org > Message-ID: <201001201805.57798.naylor.b.david@gmail.com> > Content-Type: text/plain; charset=3D"us-ascii" > Skipped content of type multipart/mixed-------------- next part ---------= ----- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 196 bytes > Desc: This is a digitally signed message part. > Url : > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100120/b= 81ceda1/attachment-0001.pgp > ------------------------------ > Message: 8 > Date: Wed, 20 Jan 2010 18:34:45 +0200 > From: David Naylor > Subject: Re: stacked unionfs freeze and crash FreeBSD > To: gary.jennejohn@freenet.de > Cc: freebsd-current@freebsd.org > Message-ID: <201001201834.48466.naylor.b.david@gmail.com> > Content-Type: text/plain; charset=3D"us-ascii" > On Wednesday 20 January 2010 18:05:54 David Naylor wrote: >> On Wednesday 20 January 2010 17:28:21 Gary Jennejohn wrote: >> > On Wed, 20 Jan 2010 15:43:12 +0200 David Naylor wrote: >> > > Hi, >> > > >> > > The attached script, that uses stacked unionfs, causes FreeBSD-9 (cv= sup >> > > yesterday) to freeze and FreeBSD-8 (cvsup two days ago) to crash: >> > > >> > > Fatal double fault >> > > rip-0xffffffff81e4c1 >> > > rsp=3D0xffffff80b133ef50 >> > > rbp=3D0xffffff80b133f150 >> > > cupid =3D 2; apic id =3D 02 >> > > panic: double fault >> > > cpuid =3D 2 >> > > uptime: 1h44m35s >> > > cannot dump. Device not defined or unavailable >> > > >> > > >> > > Both systems use the stock GENERIC kernel, i.e. -9 had full diagnost= ics >> > > built in (and was run under VirtualBox) and -8 had no diagnostics (a= nd >> > > was run native). >> > > >> > > A LOR is produces prior to freezing under -9 (quiet a time prior). = See >> > > kern/141950. >> > > >> > > The script uses unionfs to build ports (in an attempt to create a >> > > tinderbox without the need to delete and/or extract packages). To u= se >> > > the script to: >> > > >> > > # mkdir /tmp/localbase /tmp/builddir >> > > # env LOCALBASE=3D/tmp/localbase BUILDDIR=3D/tmp/builddir >> > > ./ports-union-builder.sh >> > >> > Is your /tmp big enough? >>=20 >> I was actually using /home, didn't think people wanted to contaminate th= at >> directory. Plenty of space. >>=20 >> > > This will try build everything for x11/xorg. >> > > >> > > Is it possible that VirtualBox is interfering in getting usable >> > > diagnostics for -9 >> > >> > Who knows? You might try posting your shell script so others can give >> > it a whirl on a "real" 9-current system. >>=20 >> I did attach the script. Guess mailer ate it, again. I'll try again... >>=20 >> > > and how can I setup a dump device for -8. Currently I have: >> > > >> > > # swapinfo >> > > Device 1K-blocks Used Avail Capacity >> > > /dev/ad4s1b 8388608 0 8388608 0% >> > > /dev/ad8s1b 8388608 0 8388608 0% >> > > Total 16777216 0 16777216 0% >> > >> > Do you have dumpdev defined in /etc/rc.conf and/or do you see >> > /dev/dumpdev? Having /dev/dumpdev indicates that dumpon succeeded. >>=20 >> No I haven't and no I don't. I thought it automatically used swap? >>=20 >> I'll 'activate' it and post the results. > Here it is. If anyone ones the full core.txt just shout. =20 > #0 doadump () at pcpu.h:223 > 223 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:223 > #1 0xffffffff80589ba9 in boot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff80589fdc in panic (fmt=3D0xffffffff8098bd81 "double fault") > at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xffffffff8086e546 in dblfault_handler (frame=3DVariable "frame" is n= ot > available.) > at /usr/src/sys/amd64/amd64/trap.c:884 > #4 0xffffffff808557fc in Xdblfault () > at /usr/src/sys/amd64/amd64/exception.S:278 > #5 0xffffffff81e464c1 in unionfs_statfs (mp=3DVariable "mp" is not avail= able.) > at > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vfsops.c:428 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 196 bytes > Desc: This is a digitally signed message part. > Url : > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100120/c= 0325656/attachment-0001.pgp > ------------------------------ > Message: 9 > Date: Wed, 20 Jan 2010 10:23:26 -0600 > From: Dan Nelson > Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system > To: Matt Thyer > Cc: current@freebsd.org > Message-ID: <20100120162326.GD50360@dan.emsphone.com> > Content-Type: text/plain; charset=3Dus-ascii > In the last episode (Jan 21), Matt Thyer said: >> I typically buildworld with a parallel make of hw.ncpu * 3 which results >> in -j24 on my new system (Intel Core i7-860, 8GB RAM). >>=20 >> I've not been able to buildworld natively on this new system (with ZFS -= I >> have not tried non-ZFS natively yet) but have been able to buildworld in= a >> virtual machine under Windows 7 64bit VMware Server 2.0.2 with 2 virtual >> CPUs (hence -j6 for buildworld). >>=20 >> Both 8-STABLE 32bit (this VM is non-ZFS) and CURRENT 64bit (a ZFS system) >> will build as a VM (-j6) but a native 64bit FreeBSD CURRENT (ZFS) fails. >>=20 >> The CURRENT 64bit systems were installed from the allbsd.org JPSNAP DVD = of >> 18 Jan 2010 and both can successfully buildworld with -j1 (Virtual and >> native). >>=20 >> Build failure is: >>=20 >> sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h >> /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim_asn= 1.h >> cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h >> pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h >> /usr/obj/usr/src/tmp/usr/include >> sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libasn1.so.10 >> /usr/obj/usr/src/tmp/usr/lib >> ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so >> 1 error >> *** Error code 2 >> 1 error >> *** Error code 2 >> 1 error >> *** Error code 2 >> 1 error > It's much more likely to be a Makefile dependency problem than a ZFS bug. > You will need to look much farther up in your log to see the real error > message. Make will wait for the other 23 jobs to finish before returning, > so what you posted was the output of one of the other jobs, plus the outp= ut > of each parent make as it exits with an error code. > --=20 > Dan Nelson > dnelson@allantgroup.com > ------------------------------ > Message: 10 > Date: Wed, 20 Jan 2010 20:03:22 +0300 > From: "K.R." > Subject: 8.0-STABLE r200182: weird behaviour of a service in a jail > To: FreeBSD Current > Message-ID: <4B57375A.4000309@haruhiism.net> > Content-Type: text/plain; charset=3DUTF-8 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > =20 > Hello, > I'm running FreeBSD 8.0-STABLE #0 r200182: Mon Dec 7 03:32:18 JST > 2009 SMP (4 cores) with an uptime of ~44 days and starting about 1.5 > weeks ago, I've noticed a weird behaviour with a jailed ircd (a hybrid > spin-off); it listens on a cloned address on lo0 and the connections > to it are redirected by pf. Everything was fine until once I noticed > that I (and other users, of course) cannot connect to the irc server - > the connection is established but then it just hangs indefinitely. > This problem has never manifested itself on 7.0-STABLE and 7.2-STABLE > on a single core system (ircd was also running inside a jail there). > It looks like this from the outside: > % telnet irc.server.here 6667 > Trying (ip address here)... > Connected to irc.server.here. > Escape character is '^]'. > And that's it; normally I'd get "439 * :Please wait while we process > your connection." > Same with another - server link - port. > If I attempt to connect to the server's "real" listening IP from the > machine running ircd, however, I get > % telnet irc.server.here 6667 > Trying (ip address here)... > Connected to irc.server.here. > Escape character is '^]'. > Connection closed by foreign host. (immediately, with no pause) > And on the server link port, it's still the same indefinite wait. > Amusingly enough, a simple REHASH - which resets ircd's listening > sockets - fixes the problem. The developers of the ircd state that > this behaviour is unexpected and there's nothing wrong with the source > code on their end (which I can believe). The ircd uses kqueue, if it > matters. > There are no abnormalities with sshd and sendmail in the same jail. No > problems ever arised in the 5 other jails running HTTP, SMTP and other > services; but that might be because ircd's load is much bigger in > terms of total number of established connections. > How should I debug this issue? For now, I've moved the jail to an > external IP address to see if the problem persists. > - --=20 > Kamigishi Rei > KREI-RIPE > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > =20 > iQEcBAEBAgAGBQJLVzdTAAoJEPAgyqbDpP+efJUIAKB9MJgLiTnlQYkPnLXCqroG > fQqSilPODsztqkRc9MbbDLhUjk0PtBO/hFEIUrv2fUqOBbbf/H8TSRn7BdQuYUVU > 6PsBrl+/e/jhP6y8wRsNudijlE1cQfxsjFJoNnoEHFKBY//6SedvMwMvxTy96CHf > WOkBnNJVUt/YB/Fq/DdZtNUlZpOWxxtGWHf/C75q5IdGfjk6R3uLABazUhIGHJoK > We/3gG2IVTf3zzKgCPwDaj3sLYQ1wkP4rOoAQjU+3pLynnR3xnQzv3XG2MtX3xEf > bFh2RrN/0ufoNgUDJeEVptJDveTYbpHIzCm9iVkETM7Tv0A/CSzIwy6QMbB/eIU=3D > =3Dy1oH > -----END PGP SIGNATURE----- > ------------------------------ > Message: 11 > Date: Wed, 20 Jan 2010 19:16:59 +0200 > From: Andriy Gapon > Subject: Re: stacked unionfs freeze and crash FreeBSD > To: David Naylor > Cc: freebsd-current@freebsd.org > Message-ID: <4B573A8B.8080306@icyb.net.ua> > Content-Type: text/plain; charset=3DISO-8859-1 > on 20/01/2010 18:34 David Naylor said the following: >>=20 >> Here it is. If anyone ones the full core.txt just shout. =20 >>=20 >> #0 doadump () at pcpu.h:223 >> 223 pcpu.h: No such file or directory. >> in pcpu.h >> (kgdb) #0 doadump () at pcpu.h:223 >> #1 0xffffffff80589ba9 in boot (howto=3D260) >> at /usr/src/sys/kern/kern_shutdown.c:416 >> #2 0xffffffff80589fdc in panic (fmt=3D0xffffffff8098bd81 "double fault") >> at /usr/src/sys/kern/kern_shutdown.c:579 >> #3 0xffffffff8086e546 in dblfault_handler (frame=3DVariable "frame" is = not=20 >> available.) >> at /usr/src/sys/amd64/amd64/trap.c:884 >> #4 0xffffffff808557fc in Xdblfault () >> at /usr/src/sys/amd64/amd64/exception.S:278 >> #5 0xffffffff81e464c1 in unionfs_statfs (mp=3DVariable "mp" is not avai= lable.) >> at /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vfsops.c:428 >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) > Double-fault could indicate stack overflow. > --=20 > Andriy Gapon > ------------------------------ > Message: 12 > Date: Wed, 20 Jan 2010 18:51:50 +0100 > From: Hans Petter Selasky > Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing > [SEC=3DUNCLASSIFIED] > To: freebsd-usb@freebsd.org > Cc: freebsd-current@freebsd.org, "Wilkinson, Alex" > > Message-ID: <201001201851.50069.hselasky@c2i.net> > Content-Type: Text/Plain; charset=3D"iso-8859-1" > On Wednesday 20 January 2010 07:46:20 Wilkinson, Alex wrote: >> And works dam well. >>=20 > Thanks. >> What apps could i expect this to work with in the future ? skype ? > Basically all V4L appllications. > --HPS > ------------------------------ > Message: 13 > Date: Wed, 20 Jan 2010 18:56:34 +0100 > From: Hans Petter Selasky > Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing > To: Henry Hu > Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, > freebsd-usb@freebsd.org > Message-ID: <201001201856.35002.hselasky@c2i.net> > Content-Type: Text/Plain; charset=3D"iso-8859-1" > Hi, > On Tuesday 19 January 2010 18:33:14 Henry Hu wrote: >> There are some problems, however. First, when I start pwcview with an >> unsupported mode, the content of the window is green, and I cannot >> kill the process. Only after terminating webcamd can I terminate the >> process. > I know what the problem is, and I will try to fix it in the next release = of > webcamd. >> Second, I cannot restart pwcview without restarting webcamd. At the >> second time I start pwcview with -s vga, the window is green, and I >> cannot kill it. The situation is similar to unsupported size. >>=20 >> I've also tried applications such as pidgin, skype and mplayer. >> However no one successfully played from the webcam. I doubt it needs >> some extra work. > You need to recompile these applications after installing libv4l. I have = vlc > working with the new stuff. >>=20 >> Thanks again for the great work! It never caused any kernel panic, and >> the programs are fairly stable. > Thanks! > --HPS > ------------------------------ > Message: 14 > Date: Wed, 20 Jan 2010 18:59:30 +0100 > From: Hans Petter Selasky > Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing > To: vova@fbsd.ru > Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, > freebsd-usb@freebsd.org > Message-ID: <201001201859.30886.hselasky@c2i.net> > Content-Type: Text/Plain; charset=3D"koi8-r" > On Tuesday 19 January 2010 21:12:32 Vladimir Grebenschikov wrote: >> Hi >>=20 >> I've tested with recent ports. >>=20 >> pwcview works fine, both vga and sif >>=20 >> but skype still sees /dev/video0 but fails to play anything from it, >> multimedia/cheese even does not sees webcam. >>=20 >> Is it supposed, or I am so unlucky ? > Yes it is supposed to work, but you maybe need to tweak/rebuild the gstre= amer > V4L2 code. > --HPS > ------------------------------ > Message: 15 > Date: Wed, 20 Jan 2010 22:39:27 +0100 > From: Gabor Kovesdan > Subject: HEADSUP: BSDL bc/dc in head [Was: svn commit: r202719 - in > head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc usr.bi= n/dc > usr.bin/dc/USD.doc] > To: FreeBSD Current > Message-ID: <4B57780F.4070907@FreeBSD.org> > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > Hi all, > I've just committed the BSDL versions of bc/dc ported from OpenBSD.=20 > Thanks goes to Erwin for the exp-run and to Google for sponsoring my=20 > work on text processing tools back in 2008. It is one of the results of > that summer. Unfortunately, it took a bit long because there were more > complicated problems with grep but the work I started that time hasn't > got lost and further pieces are supposed to come slowly as they are ready. > For now, the GNU version is still there in head but detached from the=20 > build. I'll add ports of GNU bc/dc and if BSDL bc/dc does fine I'll=20 > remove those form HEAD. Please report if you see any regressions or if > you just have comments. > Regards, > Gabor > -------- Mensaje original -------- > Asunto: svn commit: r202719 - in head: . gnu/usr.bin usr.bin usr.= bin/bc > usr.bin/bc/USD.doc usr.bin/dc usr.bin/dc/USD.doc > Fecha: =09Wed, 20 Jan 2010 21:30:52 +0000 (UTC) > De: Gabor Kovesdan > Para: src-committers@freebsd.org, svn-src-all@freebsd.org,=20 > svn-src-head@freebsd.org > Author: gabor (doc,ports committer) > Date: Wed Jan 20 21:30:52 2010 > New Revision: 202719 > URL: http://svn.freebsd.org/changeset/base/202719 > Log: > Replace GNU bc/dc with BSDL versions ported from OpenBSD. They have a = good > compatibility level with the GNU counterparts and have shown to be mat= ure > enough. For now, the GNU versions aren't removed from the tree, just d= etached > from the build. > Sponsored by: Google Summer of Code 2008 > Portbuild run by: erwin > Approved by: delphij > Added: > head/usr.bin/bc/ > head/usr.bin/bc/Makefile (contents, props changed) > head/usr.bin/bc/USD.doc/ > head/usr.bin/bc/USD.doc/Makefile (contents, props changed) > head/usr.bin/bc/USD.doc/bc (contents, props changed) > head/usr.bin/bc/bc.1 (contents, props changed) > head/usr.bin/bc/bc.library (contents, props changed) > head/usr.bin/bc/bc.y (contents, props changed) > head/usr.bin/bc/extern.h (contents, props changed) > head/usr.bin/bc/pathnames.h (contents, props changed) > head/usr.bin/bc/scan.l (contents, props changed) > head/usr.bin/dc/ > head/usr.bin/dc/Makefile (contents, props changed) > head/usr.bin/dc/USD.doc/ > head/usr.bin/dc/USD.doc/Makefile (contents, props changed) > head/usr.bin/dc/USD.doc/dc (contents, props changed) > head/usr.bin/dc/bcode.c (contents, props changed) > head/usr.bin/dc/bcode.h (contents, props changed) > head/usr.bin/dc/dc.1 (contents, props changed) > head/usr.bin/dc/dc.c (contents, props changed) > head/usr.bin/dc/extern.h (contents, props changed) > head/usr.bin/dc/inout.c (contents, props changed) > head/usr.bin/dc/mem.c (contents, props changed) > head/usr.bin/dc/stack.c (contents, props changed) > Modified: > head/ObsoleteFiles.inc > head/gnu/usr.bin/Makefile > head/usr.bin/Makefile > Modified: head/ObsoleteFiles.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/ObsoleteFiles.inc Wed Jan 20 21:12:30 2010 (r202718) > +++ head/ObsoleteFiles.inc Wed Jan 20 21:30:52 2010 (r202719) > @@ -14,6 +14,13 @@ > # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS = last. > # > +# 20100120: replacing GNU bc/dc with BSDL versions > +OLD_FILES+=3Dusr/share/examples/bc/ckbook.b > +OLD_FILES+=3Dusr/share/examples/bc/pi.b > +OLD_FILES+=3Dusr/share/examples/bc/primes.b > +OLD_FILES+=3Dusr/share/examples/bc/twins.b > +OLD_FILES+=3Dusr/share/info/dc.info.gz > +OLD_DIRS+=3Dusr/share/examples/bc > # 20100114: removal of ttyslot(3) > OLD_FILES+=3Dusr/share/man/man3/ttyslot.3.gz > # 20100113: remove utmp.h, replace it by utmpx.h > Modified: head/gnu/usr.bin/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/gnu/usr.bin/Makefile Wed Jan 20 21:12:30 2010 (r202718) > +++ head/gnu/usr.bin/Makefile Wed Jan 20 21:30:52 2010 (r202719) > @@ -2,12 +2,10 @@ > .include > -SUBDIR=3D bc \ > - ${_binutils} \ > +SUBDIR=3D ${_binutils} \ > ${_cc} \ > ${_cpio} \ > ${_cvs} \ > - dc \ > dialog \ > diff \ > diff3 \ > Modified: head/usr.bin/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/usr.bin/Makefile Wed Jan 20 21:12:30 2010 (r202718) > +++ head/usr.bin/Makefile Wed Jan 20 21:30:52 2010 (r202719) > @@ -18,6 +18,7 @@ SUBDIR=3D alias \ > awk \ > banner \ > basename \ > + bc \ > ${_biff} \ > ${_bluetooth} \ > brandelf \ > @@ -49,6 +50,7 @@ SUBDIR=3D alias \ > ${_csup} \ > ${_ctags} \ > cut \ > + dc \ > ${_dig} \ > dirname \ > du \ > Added: head/usr.bin/bc/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/usr.bin/bc/Makefile Wed Jan 20 21:30:52 2010 (r202719) > @@ -0,0 +1,17 @@ > +# $FreeBSD$ > +# $OpenBSD: Makefile,v 1.4 2006/06/30 19:02:28 otto Exp $ > + > +PROG=3D bc > +SRCS=3D bc.y scan.l > +CFLAGS+=3D -I. -I${.CURDIR} > +WARNS?=3D 6 > +#SUBDIR+=3D USD.doc > + > +FILES+=3D bc.library > +FILESDIR=3D ${SHAREDIR}/misc > + > +#beforeinstall: > +# install -c -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/bc.library= \ > +# ${DESTDIR}/usr/share/misc > + > +.include > Added: head/usr.bin/bc/USD.doc/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/usr.bin/bc/USD.doc/Makefile Wed Jan 20 21:30:52 2010 (r202= 719) > @@ -0,0 +1,13 @@ > +# $FreeBSD$ > +# $OpenBSD: Makefile,v 1.3 2004/02/01 15:18:01 jmc Exp $ > + > +DOC=3D bc > +DIR=3D usd/06.bc > +SRCS=3D bc > +MACROS=3D -ms > +BINDIR=3D /usr/share/doc/papers > + > +paper.txt: ${SRCS} > + ${ROFF} -Tascii ${SRCS}> ${.TARGET} > + > +.include > Added: head/usr.bin/bc/USD.doc/bc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/usr.bin/bc/USD.doc/bc Wed Jan 20 21:30:52 2010 (r202719) > @@ -0,0 +1,1241 @@ > +.\" $FreeBSD$ > +.\" $OpenBSD: bc,v 1.9 2004/07/09 10:23:05 jmc Exp $ > +.\" > +.\" Copyright (C) Caldera International Inc. 2001-2002. > +.\" All rights reserved. > +.\" > +.\" Redistribution and use in source and binary forms, with or without > +.\" modification, are permitted provided that the following conditions > +.\" are met: > +.\" 1. Redistributions of source code and documentation must retain the = above > +.\" copyright notice, this list of conditions and the following discl= aimer. > +.\" 2. Redistributions in binary form must reproduce the above copyright > +.\" notice, this list of conditions and the following disclaimer in t= he > +.\" documentation and/or other materials provided with the distributi= on. > +.\" 3. All advertising materials mentioning features or use of this soft= ware > +.\" must display the following acknowledgement: > +.\" This product includes software developed or owned by Caldera > +.\" International, Inc. > +.\" 4. Neither the name of Caldera International, Inc. nor the names of = other > +.\" contributors may be used to endorse or promote products derived f= rom > +.\" this software without specific prior written permission. > +.\" > +.\" USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA > +.\" INTERNATIONAL, INC. AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR > +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRA= NTIES > +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIM= ED. > +.\" IN NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE FOR ANY DIRE= CT, > +.\" INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > +.\" (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR > +.\" SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > +.\" STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING > +.\" IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > +.\" POSSIBILITY OF SUCH DAMAGE. > +.\" > +.\" @(#)bc 6.2 (Berkeley) 4/17/91 > +.\" > +.if n \{\ > +.po 5n > +.ll 70n > +.\} > +.EH 'USD:6-%''BC \- An Arbitrary Precision Desk-Calculator Language' > +.OH 'BC \- An Arbitrary Precision Desk-Calculator Language''USD:6-%' > +.\".RP > +.TL > +BC \- An Arbitrary Precision Desk-Calculator Language > +.AU > +Lorinda Cherry > +.AU > +Robert Morris > +.AI > +.\" .MH > +.AB > +BC is a language and a compiler for doing arbitrary precision arithmetic > +on the PDP-11 under the > +.UX > +time-sharing > +system. The output of the compiler is interpreted and executed by > +a collection of routines which can input, output, and do > +arithmetic on indefinitely large integers and on scaled fixed-point > +numbers. > +.PP > +These routines are themselves based on a dynamic storage allocator. > +Overflow does not occur until all available core storage > +is exhausted. > +.PP > +The language has a complete control structure as well as immediate-mode > +operation. Functions can be defined and saved for later execution. > +.PP > +Two five hundred-digit numbers can be multiplied to give a > +thousand digit result in about ten seconds. > +.PP > +A small collection of library functions is also available, > +including sin, cos, arctan, log, exponential, and Bessel functions of > +integer order. > +.PP > +Some of the uses of this compiler are > +.IP \- > +to do computation with large integers, > +.IP \- > +to do computation accurate to many decimal places, > +.IP \- > +conversion of numbers from one base to another base. > +.AE > +.PP > +.SH > +Introduction > +.PP > +BC is a language and a compiler for doing arbitrary precision > +arithmetic on the > +.UX > +time-sharing system [1]. > +The compiler was written to make conveniently available a > +collection of routines (called DC [5]) which are capable of doing > +arithmetic on integers of arbitrary size. The compiler > +is by no means intended to provide a complete programming > +language. > +It is a minimal language facility. > +.PP > +There is a scaling provision that permits the > +use of decimal point notation. > +Provision is made for input and output in bases other than > +decimal. Numbers can be converted from decimal to octal by > +simply setting the output base to equal 8. > +.PP > +The actual limit on the number of digits that can > +be handled depends on the amount of storage available on the machine. > +Manipulation of numbers with many hundreds of digits > +is possible even on the smallest versions of > +.UX . > +.PP > +The syntax of BC has been deliberately selected to agree > +substantially with the C language [2]. Those who > +are familiar with C will find few surprises in this language. > +.SH > +Simple Computations with Integers > +.PP > +The simplest kind of statement is an arithmetic expression > +on a line by itself. > +For instance, if you type in the line: > +.DS > +.ft B > +142857 + 285714 > +.ft P > +.DE > +the program responds immediately with the line > +.DS > +.ft B > +428571 > +.ft P > +.DE > +The operators \-, *, /, %, and ^ can also be used; they > +indicate subtraction, multiplication, division, remaindering, and > +exponentiation, respectively. Division of integers produces an > +integer result truncated toward zero. > +Division by zero produces an error > +comment. > +.PP > +Any term in an expression may be prefixed by a minus sign to > +indicate that it is to be negated (the `unary' minus sign). > +The expression > +.DS > +.ft B > +7+\-3 > +.ft P > +.DE > +is interpreted to mean that \-3 is to be added to 7. > +.PP > +More complex expressions with several operators and with > +parentheses are interpreted just as in > +Fortran, with ^ having the greatest binding > +power, then * and % and /, and finally + and \-. > +Contents of parentheses are evaluated before material > +outside the parentheses. > +Exponentiations are > +performed from right to left and the other operators > +from left to right. > +The two expressions > +.DS > +.ft B > +a^b^c and a^(b^c) > +.ft P > +.DE > +are equivalent, as are the two expressions > +.DS > +.ft B > +a*b*c and (a*b)*c > +.ft P > +.DE > +BC shares with Fortran and C the undesirable convention that > +.DS > +\fBa/b*c\fP is equivalent to \fB(a/b)*c\fP > +.ft P > +.DE > +.PP > +Internal storage registers to hold numbers have single lower-case > +letter names. The value of an expression can be assigned to > +a register in the usual way. The statement > +.DS > +.ft B > +x =3D x + 3 > +.ft P > +.DE > +has the effect of increasing by three the value of the contents of the > +register named x. > +When, as in this case, the outermost operator is an =3D, the > +assignment is performed but the result is not printed. > +Only 26 of these named storage registers are available. > +.PP > +There is a built-in square root function whose > +result is truncated to an integer (but see scaling below). > +The lines > +.DS > +.ft B > +x =3D sqrt(191) > +x > +.ft P > +.DE > +produce the printed result > +.DS > +.ft B > +13 > +.ft P > +.DE > +.SH > +Bases > +.PP > +There are special internal quantities, called `ibase' and `obase'. > +The contents of `ibase', initially set to 10, > +determines the base used for interpreting numbers read in. > +For example, the lines > +.DS > +.ft B > +ibase =3D 8 > +11 > +.ft P > +.DE > +will produce the output line > +.DS > +.ft B > +9 > +.ft P > +.DE > +and you are all set up to do octal to decimal conversions. > +Beware, however of trying to change the input base back > +to decimal by typing > +.DS > +.ft B > +ibase =3D 10 > +.ft P > +.DE > +Because the number 10 is interpreted as octal, this statement will > +have no effect. > +For those who deal in hexadecimal notation, > +the characters A\-F are permitted in numbers > +(no matter what base is in effect) > +and are > +interpreted as digits having values 10\-15 respectively. > +The statement > +.DS > +.ft B > +ibase =3D A > +.ft P > +.DE > +will change you back to decimal input base no matter what the > +current input base is. > +Negative and large positive input bases are > +permitted but useless. > +No mechanism has been provided for the input of arbitrary > +numbers in bases less than 1 and greater than 16. > +.PP > +The contents of `obase', initially set to 10, are used as the base for o= utput > +numbers. The lines > +.DS > +.ft B > +obase =3D 16 > +1000 > +.ft P > +.DE > +will produce the output line > +.DS > +.ft B > +3E8 > +.ft P > +.DE > +which is to be interpreted as a 3-digit hexadecimal number. > +Very large output bases are permitted, and they are sometimes useful. > +For example, large numbers can be output in groups of five digits > +by setting `obase' to 100000. > +Strange (i.e. 1, 0, or negative) output bases are > +handled appropriately. > +.PP > +Very large numbers are split across lines with 70 characters per line. > +Lines which are continued end with \\. > +Decimal output conversion is practically instantaneous, but output > +of very large numbers (i.e., more than 100 digits) with other bases > +is rather slow. > +Non-decimal output conversion of > +a one hundred digit number takes about > +three seconds. > +.PP > +It is best to remember that `ibase' and `obase' have no effect > +whatever on the course of internal computation or > +on the evaluation of expressions, but only affect input and > +output conversion, respectively. > +.SH > +Scaling > +.PP > +A third special internal quantity called `scale' is > +used to determine the scale of calculated > +quantities. > +Numbers may have > +up to a specific number of decimal digits after the decimal point. > +This fractional part is retained in further computations. > +We refer to the number of digits after the decimal point of > +a number as its scale. > +The current implementation allows scales to be as large as can be > +represented by a 32-bit unsigned number minus one. > +This is a non-portable extension. > +The original implementation allowed for a maximum scale of 99. > +.PP > +When two scaled numbers are combined by > +means of one of the arithmetic operations, the result > +has a scale determined by the following rules. For > +addition and subtraction, the scale of the result is the larger > +of the scales of the two operands. In this case, > +there is never any truncation of the result. > +For multiplications, the scale of the result is never > +less than the maximum of the two scales of the operands, > +never more than the sum of the scales of the operands > +and, subject to those two restrictions, > +the scale of the result is set equal to the contents of the internal > +quantity `scale'. > +The scale of a quotient is the contents of the internal > +quantity `scale'. The scale of a remainder is > +the sum of the scales of the quotient and the divisor. > +The result of an exponentiation is scaled as if > +the implied multiplications were performed. > +An exponent must be an integer. > +The scale of a square root is set to the maximum of the scale > +of the argument and the contents of `scale'. > +.PP > +All of the internal operations are actually carried out in terms > +of integers, with digits being discarded when necessary. > +In every case where digits are discarded, truncation and > +not rounding is performed. > +.PP > +The contents of > +`scale' must be no greater than > +4294967294 and no less than 0. It is initially set to 0. > +.PP > +The internal quantities `scale', `ibase', and `obase' can be > +used in expressions just like other variables. > +The line > +.DS > +.ft B > +scale =3D scale + 1 > +.ft P > +.DE > +increases the value of `scale' by one, and the line > +.DS > +.ft B > +scale > +.ft P > +.DE > +causes the current value of `scale' to be printed. > +.PP > +The value of `scale' retains its meaning as a > +number of decimal digits to be retained in internal > +computation even when `ibase' or `obase' are not equal to 10. > +The internal computations (which are still conducted in decimal, > +regardless of the bases) are performed to the specified number > +of decimal digits, never hexadecimal or octal or any > +other kind of digits. > +.SH > +Functions > +.PP > +The name of a function is a single lower-case letter. > +Function names are permitted to collide with simple > +variable names. > +Twenty-six different defined functions are permitted > +in addition to the twenty-six variable names. > +The line > +.DS > +.ft B > + define a(x){ > +.ft P > +.DE > +begins the definition of a function with one argument. > +This line must be followed by one or more statements, > +which make up the body of the function, ending > +with a right brace }. > +Return of control from a function occurs when a return > +statement is executed or when the end of the function is reached. > +The return statement can take either > +of the two forms > +.DS > +.ft B > +return > +return(x) > +.ft P > +.DE > +In the first case, the value of the function is 0, and in > +the second, the value of the expression in parentheses. > +.PP > +Variables used in the function can be declared as automatic > +by a statement of the form > +.DS > +.ft B > +auto x,y,z > +.ft P > +.DE > +There can be only one `auto' statement in a function and it must > +be the first statement in the definition. > +These automatic variables are allocated space and initialized > +to zero on entry to the function and thrown away on return. The > +values of any variables with the same names outside the function > +are not disturbed. > +Functions may be called recursively and the automatic variables > +at each level of call are protected. > +The parameters named in a function definition are treated in > +the same way as the automatic variables of that function > +with the single exception that they are given a value > +on entry to the function. > +An example of a function definition is > +.DS > +.ft B > + define a(x,y){ > + auto z > + z =3D x*y > + return(z) > + } > +.ft P > +.DE > +The value of this function, when called, will be the > +product of its > +two arguments. > +.PP > +A function is called by the appearance of its name > +followed by a string of arguments enclosed in > +parentheses and separated by commas. > +The result > +is unpredictable if the wrong number of arguments is used. > +.PP > +Functions with no arguments are defined and called using > +parentheses with nothing between them: b(). > +.PP > +If the function > +.ft I > +a > +.ft > +above has been defined, then the line > +.DS > +.ft B > +a(7,3.14) > +.ft P > +.DE > +would cause the result 21.98 to be printed and the line > +.DS > +.ft B > +x =3D a(a(3,4),5) > +.ft P > +.DE > +would cause the value of x to become 60. > +.SH > +Subscripted Variables > +.PP > +A single lower-case letter variable name > +followed by an expression in brackets is called a subscripted > +variable (an array element). > +The variable name is called the array name and the expression > +in brackets is called the subscript. > +Only one-dimensional arrays are > +permitted. The names of arrays are permitted to > +collide with the names of simple variables and function names. > +Any fractional > +part of a subscript is discarded before use. > +Subscripts must be greater than or equal to zero and > +less than or equal to 2047. > +.PP > +Subscripted variables may be freely used in expressions, in > +function calls, and in return statements. > +.PP > +An array name may be used as an argument to a function, > +or may be declared as automatic in > +a function definition by the use of empty brackets: > +.DS > +.ft B > +f(a[\|]) > +define f(a[\|]) > +auto a[\|] > +.ft P > +.DE > +When an array name is so used, the whole contents of the array > +are copied for the use of the function, and thrown away on exit > +from the function. > +Array names which refer to whole arrays cannot be used > +in any other contexts. > +.SH > +Control Statements > +.PP > +The `if', the `while', and the `for' statements > +may be used to alter the flow within programs or to cause iteration. > +The range of each of them is a statement or > +a compound statement consisting of a collection of > +statements enclosed in braces. > +They are written in the following way > +.DS > +.ft B > +if(relation) statement > +if(relation) statement else statement > +while(relation) statement > +for(expression1; relation; expression2) statement > +.ft P > +.DE > +or > +.DS > +.ft B > +if(relation) {statements} > +if(relation) {statements} else {statements} > +while(relation) {statements} > +for(expression1; relation; expression2) {statements} > +.ft P > +.DE > +.PP > +A relation in one of the control statements is an expression of the form > +.DS > +.ft B +x>>y > +.ft P > +.DE > +where two expressions are related by one of the six relational > +operators `<', `>', `<=3D', `>=3D', `=3D=3D', or `!=3D'. > +The relation `=3D=3D' > +stands for `equal to' and `!=3D' stands for `not equal to'. > +The meaning of the remaining relational operators is > +clear. > +.PP > +BEWARE of using `=3D' instead of `=3D=3D' in a relational. Unfortunatel= y, > +both of them are legal, so you will not get a diagnostic > +message, but `=3D' really will not do a comparison. > +.PP > +The `if' statement causes execution of its range > +if and only if the relation is true. > +Then control passes to the next statement in sequence. > +If an `else' branch is present, the statements in this branch are > +executed if the relation is false. > +The `else' keyword is a non-portable extension. > +.PP > +The `while' statement causes execution of its range > +repeatedly as long as the relation > +is true. The relation is tested before each execution > +of its range and if the relation > +is false, control passes to the next statement beyond the range > +of the while. > +.PP > +The `for' statement begins > +by executing `expression1'. Then the relation is tested > +and, if true, the statements in the range of the `for' are executed. > +Then `expression2' is executed. The relation is tested, and so on. > +The typical use of the `for' statement is for a controlled iteration, > +as in the statement > +.DS > +.ft B > +for(i=3D1; i<=3D10; i=3Di+1) i > +.ft P > +.DE > +which will print the integers from 1 to 10. > +Here are some examples of the use of the control statements. > +.DS > +.ft B > +define f(n){ > +auto i, x > +x=3D1 > +for(i=3D1; i<=3Dn; i=3Di+1) x=3Dx*i > +return(x) > +} > +.ft P > +.DE > +The line > +.DS > +.ft B > + f(a) > +.ft P > +.DE > +will print > +.ft I > +a > +.ft > +factorial if > +.ft I > +a > +.ft > +is a positive integer. > +Here is the definition of a function which will > +compute values of the binomial coefficient > +(m and n are assumed to be positive integers). > +.DS > +.ft B > +define b(n,m){ > +auto x, j > +x=3D1 > +for(j=3D1; j<=3Dm; j=3Dj+1) x=3Dx*(n\-j+1)/j > +return(x) > +} > +.ft P > +.DE > +The following function computes values of the exponential function > +by summing the appropriate series > +without regard for possible truncation errors: > +.DS > +.ft B > +scale =3D 20 > +define e(x){ > + auto a, b, c, d, n > + a =3D 1 > + b =3D 1 > + c =3D 1 > + d =3D 0 > + n =3D 1 > + while(1=3D=3D1){ > + a =3D a*x > + b =3D b*n > + c =3D c + a/b > + n =3D n + 1 > + if(c=3D=3Dd) return(c) > + d =3D c > + } > +} > +.ft P > +.DE > +.SH > +Some Details > +.PP > +There are some language features that every user should know > +about even if he will not use them. > +.PP > +Normally statements are typed one to a line. It is also permissible > +to type several statements on a line separated by semicolons. > +.PP > +If an assignment statement is parenthesized, it then has > +a value and it can be used anywhere that an expression can. > +For example, the line > +.DS > +.ft B > +(x=3Dy+17) > +.ft P > +.DE > +not only makes the indicated assignment, but also prints the > +resulting value. > +.PP > +Here is an example of a use of the value of an > +assignment statement even when it is not parenthesized. > +.DS > +.ft B > +x =3D a[i=3Di+1] > +.ft P > +.DE > +causes a value to be assigned to x and also increments i > +before it is used as a subscript. > +.PP > +The following constructs work in BC in exactly the same manner > +as they do in the C language. Consult the appendix or the > +C manuals [2] for their exact workings. > +.DS > +.ft B > +.ta 2i > +x=3Dy=3Dz is the same as x=3D(y=3Dz) > +x +=3D y=09x =3D x+y > +x \-=3D y x =3D x\-y > +x *=3D y=09x =3D x*y > +x /=3D y=09x =3D x/y > +x %=3D y=09x =3D x%y > +x ^=3D y=09x =3D x^y > +x++ (x=3Dx+1)\-1 > +x\-\- (x=3Dx\-1)+1 > +++x x =3D x+1 > +\-\-x x =3D x\-1 > +.ft P > +.DE > +Even if you don't intend to use the constructs, > +if you type one inadvertently, something correct but unexpected > +may happen. > +.SH > +Three Important Things > +.PP > +1. To exit a BC program, type `quit'. > +.PP > +2. There is a comment convention identical to that of C and > +of PL/I. Comments begin with `/*' and end with `*/'. > +As a non-portable extension, comments may also start with a `#' and end = with > +a newline. > +The newline is not part of the comment. > +.PP > +3. There is a library of math functions which may be obtained by > +typing at command level > +.DS > +.ft B > +bc \-l > +.ft P > +.DE > +This command will load a set of library functions > +which, at the time of writing, consists of sine (named `s'), > +cosine (`c'), arctangent (`a'), natural logarithm (`l'), > +exponential (`e') and Bessel functions of integer order > (`j(n,x)'). Doubtless more functions will be added > +in time. > +The library sets the scale to 20. You can reset it to something > +else if you like. > +The design of these mathematical library routines > +is discussed elsewhere [3]. > +.PP > +If you type > +.DS > +.ft B > +bc file ... > +.ft P > +.DE > +BC will read and execute the named file or files before accepting > +commands from the keyboard. In this way, you may load your > +favorite programs and function definitions. > +.SH > +Acknowledgement > +.PP > +The compiler is written in YACC [4]; its original > +version was written by S. C. Johnson. > +.SH > +References > +.IP [1] > +K. Thompson and D. M. Ritchie, > +.ft I > +UNIX Programmer's Manual, > +.ft > +Bell Laboratories, > +1978. > +.IP [2] > +B. W. Kernighan and > +D. M. Ritchie, > +.ft I > +The C Programming Language, > +.ft > +Prentice-Hall, 1978. > +.IP [3] > +R. Morris, > +.ft I > +A Library of Reference Standard Mathematical Subroutines, > +.ft > +Bell Laboratories internal memorandum, 1975. > +.IP [4] > +S. C. Johnson, > +.ft I > +YACC \(em Yet Another Compiler-Compiler. > +.ft > +Bell Laboratories Computing Science Technical Report #32, 1978. > +.IP [5] > +R. Morris and L. L. Cherry, > +.ft I > +DC \- An Interactive Desk Calculator. > +.ft > +.LP > +.bp > +.ft B > +.DS C > +Appendix > +.DE > +.ft > +.NH > +Notation > +.PP > +In the following pages syntactic categories are in \fIitalics\fP; > +literals are in \fBbold\fP; material in brackets [\|] is optional. > +.NH > +Tokens > +.PP > +Tokens consist of keywords, identifiers, constants, operators, > +and separators. > +Token separators may be blanks, tabs or comments. > +Newline characters or semicolons separate statements. > +.NH 2 > +Comments > +.PP > +Comments are introduced by the characters /* and terminated by > +*/. > +As a non-portable extension, comments may also start with a # and > +end with a newline. > +The newline is not part of the comment. > +.NH 2 > +Identifiers > +.PP > +There are three kinds of identifiers \- ordinary identifiers, array iden= tifiers > +and function identifiers. > +All three types consist of single lower-case letters. > +Array identifiers are followed by square brackets, possibly > +enclosing an expression describing a subscript. > +Arrays are singly dimensioned and may contain up to 2048 > +elements. > +Indexing begins at zero so an array may be indexed from 0 to 2047. > +Subscripts are truncated to integers. > +Function identifiers are followed by parentheses, possibly enclosing arg= uments. > +The three types of identifiers do not conflict; > +a program can have a variable named \fBx\fP, > +an array named \fBx\fP and a function named \fBx\fP, all of which are se= parate and > +distinct. > +.NH 2 > +Keywords > +.PP > +The following are reserved keywords: > +.ft B > +.ta .5i 1.0i > +.nf > + ibase if > + obase break > + scale define > + sqrt auto > + length return > + while quit > + for continue > + else last > + print > +.fi > +.ft > +.NH 2 > +Constants > +.PP > +Constants consist of arbitrarily long numbers > +with an optional decimal point. > +The hexadecimal digits \fBA\fP\-\fBF\fP are also recognized as digits wi= th > +values 10\-15, respectively. > +.NH 1 > +Expressions > +.PP > +The value of an expression is printed unless the main > +operator is an assignment. > +The value printed is assigned to the special variable \fBlast\fP. > +A single dot may be used as a synonym for \fBlast\fP. > +This is a non-portable extension. > +Precedence is the same as the order > +of presentation here, with highest appearing first. > +Left or right associativity, where applicable, is > +discussed with each operator. > +.bp > +.NH 2 > +Primitive expressions > +.NH 3 > +Named expressions > +.PP > +Named expressions are > +places where values are stored. > +Simply stated, > +named expressions are legal on the left > +side of an assignment. > +The value of a named expression is the value stored in the place named. > +.NH 4 > +\fIidentifiers\fR > +.PP > +Simple identifiers are named expressions. > +They have an initial value of zero. > +.NH 4 > +\fIarray-name\fP\|[\|\fIexpression\fP\|] > +.PP > +Array elements are named expressions. > +They have an initial value of zero. > +.NH 4 > +\fBscale\fR, \fBibase\fR and \fBobase\fR > +.PP > +The internal registers > +\fBscale\fP, \fBibase\fP and \fBobase\fP are all named expressions. > +\fBscale\fP is the number of digits after the decimal point to be > +retained in arithmetic operations. > +\fBscale\fR has an initial value of zero. > +\fBibase\fP and \fBobase\fP are the input and output number > +radix respectively. > +Both \fBibase\fR and \fBobase\fR have initial values of 10. > +.NH 3 > +Function calls > +.NH 4 > +\fIfunction-name\fB\|(\fR[\fIexpression\fR\|[\fB,\|\fIexpression\|\fR.\|= .\|.\|]\|]\fB) > +.PP > +A function call consists of a function name followed by parentheses > +containing a comma-separated list of > +expressions, which are the function arguments. > +A whole array passed as an argument is specified by the > +array name followed by empty square brackets. > +All function arguments are passed by > +value. > +As a result, changes made to the formal parameters have > +no effect on the actual arguments. > +If the function terminates by executing a return > +statement, the value of the function is > +the value of the expression in the parentheses of the return > +statement or is zero if no expression is provided > +or if there is no return statement. > +.NH 4 > +sqrt\|(\|\fIexpression\fP\|) > +.PP > +The result is the square root of the expression. > +The result is truncated in the least significant decimal place. > +The scale of the result is > +the scale of the expression or the > +value of > +.ft B > +scale, > +.ft > +whichever is larger. > +.NH 4 > +length\|(\|\fIexpression\fP\|) > +.PP > +The result is the total number of significant decimal digits in the expr= ession. > +The scale of the result is zero. > +.NH 4 > +scale\|(\|\fIexpression\fP\|) > +.PP > +The result is the scale of the expression. > +The scale of the result is zero. > +.NH 3 > +Constants > +.PP > +Constants are primitive expressions. > +.NH 3 > +Parentheses > +.PP > +An expression surrounded by parentheses is > +a primitive expression. > +The parentheses are used to alter the > +normal precedence. > +.NH 2 > +Unary operators > +.PP > +The unary operators > +bind right to left. > +.NH 3 > +\-\|\fIexpression\fP > *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** > _______________________________________________ > 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" > ------------------------------ > Message: 16 > Date: Thu, 21 Jan 2010 09:50:14 +1030 > From: Matt Thyer > Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system > To: Dan Nelson > Cc: current@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=3DISO-8859-1 > 2010/1/21 Dan Nelson >> In the last episode (Jan 21), Matt Thyer said: >> > I typically buildworld with a parallel make of hw.ncpu * 3 which resul= ts >> > in -j24 on my new system (Intel Core i7-860, 8GB RAM). >> > [snip] >> > Build failure is: >> > >> > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h >> > >> /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim_asn= 1.h >> > cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h >> > pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h >> > /usr/obj/usr/src/tmp/usr/include >> > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libasn1.so= .10 >> > /usr/obj/usr/src/tmp/usr/lib >> > ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so >> > 1 error >> > *** Error code 2 >> > 1 error >> > *** Error code 2 >> > 1 error >> > *** Error code 2 >> > 1 error >> >> It's much more likely to be a Makefile dependency problem than a ZFS bug. >> You will need to look much farther up in your log to see the real error >> message. Make will wait for the other 23 jobs to finish before returnin= g, >> so what you posted was the output of one of the other jobs, plus the out= put >> of each parent make as it exits with an error code. >> > This was my first thought so I grepped my log for "error" in a case > insensitive way and found nothing. > That's why I think that it may be a file system issue as the line prior to > the link is the installation of the "libasn1.so.10" shared library. I have > now installed the same JPSNAP on another identical hard disk (300GB Seaga= te > SATA) in a UFS only system and will test again shortly. >> -- >> Dan Nelson >> dnelson@allantgroup.com >> > ------------------------------ > Message: 17 > Date: Wed, 20 Jan 2010 17:50:24 -0600 > From: Dan Nelson > Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system > To: Matt Thyer > Cc: current@freebsd.org > Message-ID: <20100120235024.GE50360@dan.emsphone.com> > Content-Type: text/plain; charset=3Dus-ascii > In the last episode (Jan 21), Matt Thyer said: >> 2010/1/21 Dan Nelson >> > In the last episode (Jan 21), Matt Thyer said: >> > > I typically buildworld with a parallel make of hw.ncpu * 3 which >> > > results in -j24 on my new system (Intel Core i7-860, 8GB RAM). > [...]=20 >> > > Build failure is: >> > > >> > > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h >> > > /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim= _asn1.h >> > > cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h >> > > pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h >> > > /usr/obj/usr/src/tmp/usr/include >> > > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libasn1.= so.10 >> > > /usr/obj/usr/src/tmp/usr/lib >> > > ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so >> > > 1 error >> > > *** Error code 2 >> > > 1 error >> > > *** Error code 2 >> > > 1 error >> > > *** Error code 2 >> > > 1 error >> > >> > It's much more likely to be a Makefile dependency problem than a ZFS >> > bug. You will need to look much farther up in your log to see the real >> > error message. Make will wait for the other 23 jobs to finish before >> > returning, so what you posted was the output of one of the other jobs, >> > plus the output of each parent make as it exits with an error code. >>=20 >> This was my first thought so I grepped my log for "error" in a case >> insensitive way and found nothing. That's why I think that it may be a >> file system issue as the line prior to the link is the installation of t= he >> "libasn1.so.10" shared library. I have now installed the same JPSNAP on >> another identical hard disk (300GB Seagate SATA) in a UFS only system and >> will test again shortly. > Since the ln command didn't print an error message itself, it's unlikely = to > have caused the build to fail. Try searching for "***" or ":" instead. > You can try adding -v or -P to your initial make commandline; either will > add extra lines to parallel builds that make it easier to tell exactly wh= at > make target caused a failure. I don't know if they will cause issues with > the buildworld framework, though. Try running "make -j2", "make -v -j2", > and "make -P -j2" on the following Makefile to see what the flags do: > ( indented lines have leading tabs ) > test: test1 test2 > test1: > @sleep 1 > @false > test2: > @echo "hi I'm a successful target" > =20 > --=20 > Dan Nelson > dnelson@allantgroup.com > ------------------------------ > Message: 18 > Date: Thu, 21 Jan 2010 08:51:12 +0800 > From: "Wilkinson, Alex" > Subject: Re: multimedia/libv4l/ (video4bsd.ko) -> Fatal trap 12: page > fault while in kernel mode [SEC=3DUNCLASSIFIED] > To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org > Message-ID: <20100121005111.GB48329@stlux503.dsto.defence.gov.au> > Content-Type: text/plain; charset=3D"us-ascii" > 0n Wed, Jan 20, 2010 at 10:13:07AM +0100, Hans Petter Selasky wrote: > >On Wednesday 20 January 2010 09:37:26 Wilkinson, Alex wrote: > >> The following ports initially installed and worked fine: > >>=20 > >> multimedia/libv4l > >> multimedia/webcamd > >> multimedia/pwcview > >>=20 > >> however, after a reboot video4bsd.ko panic'd my machine and i was = unable to > >> boot. I had to use the LiveFS to rescue the box. Here is the bt fr= om DDB: > > > >This issue is fixed. Just update the ports. > Ah, yep. Updating multimedia/video4bsd-kmod/ fixed this issue. Thanks! > -Alex > IMPORTANT: This email remains the property of the Australian > Defence Organisation and is subject to the jurisdiction of section > 70 of the CRIMES ACT 1914. If you have received this email in > error, you are requested to contact the sender and delete the email. > ------------------------------ > Message: 19 > Date: Thu, 21 Jan 2010 01:42:16 +0100 > From: Pav Lucistnik > Subject: cvsup crashing > To: current@FreeBSD.org > Message-ID: <1264034536.1541.113.camel@hood.oook.cz> > Content-Type: text/plain; charset=3D"iso-8859-2" > We updated -CURRENT on pointyhat to r202579M: Tue Jan 19 08:43:56 UTC > 2010 and now cvsup is catching SIGILL on every run updating ports > checkout, in gmtime_r(). Any insights? > --=20 > Pav Lucistnik > > Angband in action! Constant escalation to new depths to find angrier, > meaner letters and more punctuation! > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 196 bytes > Desc: Toto je =3D?UTF-8?Q?digit=3DC3=3DA1ln=3DC4=3D9B?=3D > =3D?ISO-8859-1?Q?_podepsan=3DE1?=3D =3D?UTF-8?Q?_=3DC4=3D8D=3DC3= =3DA1st?=3D > =3D?ISO-8859-1?Q?_zpr=3DE1vy?=3D > Url : > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100121/c= c88b46d/attachment-0001.pgp > ------------------------------ > Message: 20 > Date: Thu, 21 Jan 2010 11:48:58 +1030 > From: Matt Thyer > Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system > To: Dan Nelson > Cc: current@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=3DISO-8859-1 > 2010/1/21 Dan Nelson >> In the last episode (Jan 21), Matt Thyer said: >> > 2010/1/21 Dan Nelson >> > > In the last episode (Jan 21), Matt Thyer said: >> > > > I typically buildworld with a parallel make of hw.ncpu * 3 which >> > > > results in -j24 on my new system (Intel Core i7-860, 8GB RAM). >> [...] >> > > > Build failure is: >> > > > >> > > > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 asn1_err.h >> > > > >> /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/heim_asn= 1.h >> > > > cms_asn1.h rfc2459_asn1.h krb5_asn1.h pkinit_asn1.h pkcs8_asn1.h >> > > > pkcs9_asn1.h pkcs12_asn1.h digest_asn1.h kx509_asn1.h >> > > > /usr/obj/usr/src/tmp/usr/include >> > > > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 >> libasn1.so.10 >> > > > /usr/obj/usr/src/tmp/usr/lib >> > > > ln -fs libasn1.so.10 /usr/obj/usr/src/tmp/usr/lib/libasn1.so >> > > > 1 error >> > > > *** Error code 2 >> > > > 1 error >> > > > *** Error code 2 >> > > > 1 error >> > > > *** Error code 2 >> > > > 1 error >> > > >> > > It's much more likely to be a Makefile dependency problem than a ZFS >> > > bug. You will need to look much farther up in your log to see the r= eal >> > > error message. Make will wait for the other 23 jobs to finish before >> > > returning, so what you posted was the output of one of the other job= s, >> > > plus the output of each parent make as it exits with an error code. >> > >> > This was my first thought so I grepped my log for "error" in a case >> > insensitive way and found nothing. That's why I think that it may be a >> > file system issue as the line prior to the link is the installation of >> the >> > "libasn1.so.10" shared library. I have now installed the same JPSNAP = on >> > another identical hard disk (300GB Seagate SATA) in a UFS only system = and >> > will test again shortly. >> >> Since the ln command didn't print an error message itself, it's unlikely= to >> have caused the build to fail. Try searching for "***" or ":" instead. > [...] > You are correct. I missed the error the first time. It is: > make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop > *** Error code 2 > ------------------------------ > Message: 21 > Date: Wed, 20 Jan 2010 19:29:45 -0600 (CST) > From: "Sean C. Farley" > Subject: Re: cvsup crashing > To: Pav Lucistnik > Cc: current@FreeBSD.org > Message-ID: > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed > On Thu, 21 Jan 2010, Pav Lucistnik wrote: >> We updated -CURRENT on pointyhat to r202579M: Tue Jan 19 08:43:56 UTC=20 >> 2010 and now cvsup is catching SIGILL on every run updating ports=20 >> checkout, in gmtime_r(). Any insights? > Is it anything similar to this thread[1]? > Sean > 1. > http://lists.freebsd.org/pipermail/freebsd-current/2009-December/013946.h= tml > --=20 > scf@FreeBSD.org > ------------------------------ > Message: 22 > Date: Wed, 20 Jan 2010 20:26:44 -0500 (EST) > From: Daniel Eischen > Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core > i7-860 system > To: Matt Thyer > Cc: Dan Nelson , current@freebsd.org > Message-ID: > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed > On Thu, 21 Jan 2010, Matt Thyer wrote: >> 2010/1/21 Dan Nelson >> >>> >>> Since the ln command didn't print an error message itself, it's unlikel= y to >>> have caused the build to fail. Try searching for "***" or ":" instead. >> >> >> [...] >> >> You are correct. I missed the error the first time. It is: >> >> make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop >> *** Error code 2 > It happens with -j8 also (amd64, UFS). --=20 =D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC, Ps81 mailto:ps81@mail.ru From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 17:04:36 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D7021065670 for ; Thu, 21 Jan 2010 17:04:36 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id DCFF48FC16 for ; Thu, 21 Jan 2010 17:04:35 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0LH4Iie079955; Thu, 21 Jan 2010 18:04:34 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0LH4I0C079954; Thu, 21 Jan 2010 18:04:18 +0100 (CET) (envelope-from olli) Date: Thu, 21 Jan 2010 18:04:18 +0100 (CET) Message-Id: <201001211704.o0LH4I0C079954@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 21 Jan 2010 18:04:34 +0100 (CET) Cc: Subject: top(1) + vmstat(8): CPU percentages broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:04:36 -0000 Hello, On a 9-current system (sources as of Monday 2010-01-18), top(1) displays 0% for _all_ values in the "CPU" line (user, nice, sys, int, idle). Also, in vmstat(1) the cpu columns us/sy/id are always zero. Is there a know problem with CPU time accounting in 9-current? BTW, if it matters, this is with a GENERIC kernel minus WITNESS and INVARIANTS. The machine has two HT-enabled quadcore-packages, i.e. in total this is a 16-way SMP system. kern.timecounter.hardware is ACPI-fast. I've put dmesg and other information here: http://www.secnetix.de/olli/dmesg/hs22/ (There also seem to be problems with the performance of the mpt(4)-connected disks, but I guess that's an unrelated problem.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure." -- Eric Allman From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 17:06:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 316691065670 for ; Thu, 21 Jan 2010 17:06:26 +0000 (UTC) (envelope-from michael.gusek@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id A48E08FC17 for ; Thu, 21 Jan 2010 17:06:25 +0000 (UTC) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate02.web.de (Postfix) with ESMTP id 650E214C4ADEC for ; Thu, 21 Jan 2010 17:39:02 +0100 (CET) Received: from [82.144.33.34] (helo=kerkyra.vanguard.de) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1NY03i-0000IA-00 for current@FreeBSD.org; Thu, 21 Jan 2010 17:39:02 +0100 Message-ID: <4B588325.40009@web.de> Date: Thu, 21 Jan 2010 17:39:01 +0100 From: Michael Gusek User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.1.5) Gecko/20100105 Thunderbird/3.0 MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: michael.gusek@web.de X-Sender: michael.gusek@web.de X-Provags-ID: V01U2FsdGVkX18yIC8kjsG3ckWVnAhhqIsED9smzDkRfHJTsZSL GKnZ+f7/XK8b9LwweAXZ/Bs829K9vLZsQvZW68sio95OJ9hT3H gI2sZ30k5VSj0WLpomvA== Cc: Subject: USB pen encryption at boot-time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:06:26 -0000 Hi, i'm trying to decrypt an usb pen at boot. For this, i encrypt a slice on a pen: geli init -b -P -K da0.key /dev/da0s1a On my pc, the pen should encrypt on boot, so i have this in loader.conf: geom_eli_load="YES" geli_da0s1a_keyfile0_load="YES" geli_da0s1a_keyfile0_type="da0s1a:geli_keyfile0" geli_da0s1a_keyfile0_name="/boot/keys/da0.key" But it isn't encrypt on boot. I'm running 8.0-RELEASE on a Soekris 5501. If i encrypt another partition of my hard-disk (ad0s1b), this will be encrypt on boot time. So i think, this is a problem with the usb-stack ? In dmesg you can see geli is trying to find a key for ad0s1b, but not for /dev/da0s1a which is my encrypted slice on the usb pen. Yes, i can manually 'geli attach -p -k /boot/keys/da0.key /dev/da0s1a' after login. Hier is my dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RELEASE #2 r200252: Thu Jan 21 16:08:33 CET 2010 micha@kerkyra.vanguard.de:/usr/obj/usr/src/sys/ZSVA Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (433.25-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 268435456 (256 MB) avail memory = 252272640 (240 MB) kbd1 at kbdmux0 K6-family MTRR support enabled (2 registers) ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. cryptosoft0: on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 Geode LX: Soekris net5501 comBIOS ver. 1.33 20070103 Copyright (C) 2000-2007 glxsb0: mem 0xa0000000-0xa0003fff irq 10 at device 1.2 on pci0 vr0: port 0xe100-0xe1ff mem 0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0 vr0: Quirks: 0x2 vr0: Revision: 0x96 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:00:24:cb:5d:e0 vr0: [ITHREAD] vr1: port 0xe200-0xe2ff mem 0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0 vr1: Quirks: 0x2 vr1: Revision: 0x96 miibus1: on vr1 ukphy1: PHY 1 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: Ethernet address: 00:00:24:cb:5d:e1 vr1: [ITHREAD] vr2: port 0xe300-0xe3ff mem 0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0 vr2: Quirks: 0x2 vr2: Revision: 0x96 miibus2: on vr2 ukphy2: PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, autoad0s1b vr2: Ethernet address: 00:00:24:cb:5d:e2 vr2: [ITHREAD] vr3: port 0xe400-0xe4ff mem 0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0 vr3: Quirks: 0x2 vr3: Revision: 0x96 miibus3: on vr3 ukphy3: PHY 1 on miibus3 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr3: Ethernet address: 00:00:24:cb:5d:e3 vr3: [ITHREAD] pci0: at device 17.0 (no driver attached) isab0: at device 20.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 20.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] ohci0: mem 0xa0010000-0xa0010fff irq 7 at device 21.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xa0011000-0xa0011fff irq 7 at device 21.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 cpu0 on motherboard pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd27ff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] atrtc0: at port 0x70 irq 8 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: console (19200,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] Timecounter "TSC" frequency 433250443 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ad0: 1953MB at ata0-master WDMA2 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s). GEOM_ELI: Found no key files in loader.conf for ad0s1b. Root mount waiting for: usbus1 usbus0 uhub0: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 uhub1: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0100 Root mount waiting for: usbus1 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:/dev/label/root(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 1925MB (3944446 512 byte sectors: 255H 63S/T 245C) Thanks for help, Michael From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 17:52:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 776D4106568B for ; Thu, 21 Jan 2010 17:52:39 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id F03568FC17 for ; Thu, 21 Jan 2010 17:52:38 +0000 (UTC) Received: by ewy3 with SMTP id 3so256931ewy.33 for ; Thu, 21 Jan 2010 09:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=CIdeBMmdwAgcZ2dNlI1IEdPpP4Rwevzic6CLJmnNmQ8=; b=ETFcSjlW6jXl2NUx2t/uGGfcdALL1MR1emP/36ZbzmdV8rqw91FSZfoQBU0j4UKu6Z uhRHaSxxv7PuJ5V5oE7F/WwTQokji//kJOVjMkkmFoeXr+VTGkSUnohzdgBtDQyt8Mwd CTdhqVyp26sy6vQr6hJiAOeYh+b4/oG/+3b70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=x8Q3gRYfy71OfrXS3Ka/m8H7qm7iKbLS2Oc3RFZdV7HJRVFZDRGLjgAKFSjO1eRHqn 3YZFK9hkq245bYRPWJaJQQKF/tSiTEqjqpNyJZKdHwLukDsjThO29/PAfF4kbM0CWcDk gPX48yvFA0dHkLvoJBhNVLP+rONrRJcxzr4fs= Received: by 10.216.90.137 with SMTP id e9mr681450wef.141.1264096357753; Thu, 21 Jan 2010 09:52:37 -0800 (PST) Received: from dragon.dg ([41.216.197.17]) by mx.google.com with ESMTPS id 5sm1212718eyf.4.2010.01.21.09.52.18 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 09:52:35 -0800 (PST) From: David Naylor Organization: Private To: Andriy Gapon Date: Thu, 21 Jan 2010 19:52:16 +0200 User-Agent: KMail/1.12.3 (FreeBSD/8.0-STABLE; KDE/4.3.3; amd64; ; ) References: <201001201543.15818.naylor.b.david@gmail.com> <201001201834.48466.naylor.b.david@gmail.com> <4B573A8B.8080306@icyb.net.ua> In-Reply-To: <4B573A8B.8080306@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9632437.lP9HUY7ufi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001211952.20202.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: stacked unionfs freeze and crash FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:52:39 -0000 --nextPart9632437.lP9HUY7ufi Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday 20 January 2010 19:16:59 Andriy Gapon wrote: > on 20/01/2010 18:34 David Naylor said the following: > > Here it is. If anyone ones the full core.txt just shout. > > > > #0 doadump () at pcpu.h:223 > > 223 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) #0 doadump () at pcpu.h:223 > > #1 0xffffffff80589ba9 in boot (howto=3D260) > > at /usr/src/sys/kern/kern_shutdown.c:416 > > #2 0xffffffff80589fdc in panic (fmt=3D0xffffffff8098bd81 "double fault= ") > > at /usr/src/sys/kern/kern_shutdown.c:579 > > #3 0xffffffff8086e546 in dblfault_handler (frame=3DVariable "frame" is= not > > available.) > > at /usr/src/sys/amd64/amd64/trap.c:884 > > #4 0xffffffff808557fc in Xdblfault () > > at /usr/src/sys/amd64/amd64/exception.S:278 > > #5 0xffffffff81e464c1 in unionfs_statfs (mp=3DVariable "mp" is not > > available.) at > > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vfsops.c:428 Previo= us > > frame inner to this frame (corrupt stack?) > > (kgdb) >=20 > Double-fault could indicate stack overflow. Thanks, I bumped KSTACK_PAGES to 32 (just to be on the safe side) and it is= =20 working fairly well now. Only crash I have had since was related to tmpfs.= =20 So far I have successfully build a port with 59 stacked unionfs (1 rw, 58 r= o). =20 Regards, David --nextPart9632437.lP9HUY7ufi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktYlFQACgkQUaaFgP9pFrLkZgCeM6qrD+tZyw3mFRmc69eJfvj3 3F8An1bkTYMEKyt2qk34oKgtood2fTvD =+8eS -----END PGP SIGNATURE----- --nextPart9632437.lP9HUY7ufi-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 17:56:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D53910656C1 for ; Thu, 21 Jan 2010 17:56:22 +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 C1A538FC21 for ; Thu, 21 Jan 2010 17:56:21 +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 TAA13091; Thu, 21 Jan 2010 19:56:16 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B58953F.10404@icyb.net.ua> Date: Thu, 21 Jan 2010 19:56:15 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: David Naylor References: <201001201543.15818.naylor.b.david@gmail.com> <201001201834.48466.naylor.b.david@gmail.com> <4B573A8B.8080306@icyb.net.ua> <201001211952.20202.naylor.b.david@gmail.com> In-Reply-To: <201001211952.20202.naylor.b.david@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: stacked unionfs freeze and crash FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:56:22 -0000 on 21/01/2010 19:52 David Naylor said the following: > On Wednesday 20 January 2010 19:16:59 Andriy Gapon wrote: >> Double-fault could indicate stack overflow. > > Thanks, I bumped KSTACK_PAGES to 32 (just to be on the safe side) and it is > working fairly well now. Only crash I have had since was related to tmpfs. > So far I have successfully build a port with 59 stacked unionfs (1 rw, 58 ro). Good that you found a workaround, bad that there is no better way to handle this overflow. Or, is there? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 18:33:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7CE7106566C for ; Thu, 21 Jan 2010 18:33:29 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7238FC0C for ; Thu, 21 Jan 2010 18:33:29 +0000 (UTC) Received: by iwn1 with SMTP id 1so260241iwn.28 for ; Thu, 21 Jan 2010 10:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=OOHt3cWlXwtBzhC1PQWLWgStVlZh2nn8skrhSa77wrs=; b=P9oXNB6GTgilxxAtB9+G8wMJwKiXEowUDvMJX2YJvPfBebio4TpuZ3HjDxfyCKv8a3 ripJeZEdlx7wL6X4pARXtI33UevYH6/oJRIZ0i1koAJqtLDOdyCebNWE6PIRsBs5H/mX act4vb187ooK74Uk9I5ZioJrP3gkk4ysSLNgM= 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=O3UDQ5AOLYK/mb2JGQl86HLG5vbzHm8KBrV5ayuigk2BDtoX75pdt7+sT9EMoPdiaK gcw8jc9yfkEPMrB1Pe5+vippGj4kxzochdlqgkV1Rbwxi9wKOiubjGx2I4zUTGevWQ3u EuDKiVYUjVIZuhHjWeWtuWIfU2XOGLe4kvjlo= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.162.9 with SMTP id t9mr2955168ibx.5.1264098808695; Thu, 21 Jan 2010 10:33:28 -0800 (PST) In-Reply-To: <201001211704.o0LH4I0C079954@lurza.secnetix.de> References: <201001211704.o0LH4I0C079954@lurza.secnetix.de> Date: Thu, 21 Jan 2010 19:33:28 +0100 X-Google-Sender-Auth: 903c0ea3fbc8904f Message-ID: <3bbf2fe11001211033t4dfab54ai5d48156928fe7657@mail.gmail.com> From: Attilio Rao To: Oliver Fromme Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: top(1) + vmstat(8): CPU percentages broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 18:33:29 -0000 2010/1/21 Oliver Fromme : > Hello, > > On a 9-current system (sources as of Monday 2010-01-18), > top(1) displays 0% for _all_ values in the "CPU" line > (user, nice, sys, int, idle). =C2=A0Also, in vmstat(1) the > cpu columns us/sy/id are always zero. > > Is there a know problem with CPU time accounting in > 9-current? May you revert r202387, 202441 and 202534 and see if it does make a differe= nce? Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 19:26:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63859106568B; Thu, 21 Jan 2010 19:26:46 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9B58FC16; Thu, 21 Jan 2010 19:26:45 +0000 (UTC) Received: from [85.173.16.175] (helo=izar) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1NY2g0-0001aK-Rj; Thu, 21 Jan 2010 22:26:44 +0300 From: Boris Samorodov To: Alexander Motin References: <4B55D9D4.1000008@FreeBSD.org> <4B57064F.9060704@restart.be> Date: Thu, 21 Jan 2010 22:26:38 +0300 In-Reply-To: <4B57064F.9060704@restart.be> (Henri Hennebert's message of "Wed, 20 Jan 2010 14:34:07 +0100") Message-ID: <30311009@ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 19:26:46 -0000 On Wed, 20 Jan 2010 14:34:07 +0100 Henri Hennebert wrote: > On 01/19/2010 17:12, Alexander Motin wrote: > > Hi. > > > > I've made a patch, that should solve set of problems of CAM ATA and CAM Thanks! > > generally. I would like to ask for testing and feedback. > > > > What patch does: > > - It unifies bus reset/probe sequence. Whenever bus attached at boot or > > later, CAM will automatically reset and scan it. It allows to remove > > duplicate code from many drivers. > > - Any bus, attached before CAM completed it's boot-time initialization, > > will equally join to the process, delaying boot if needed. > > - New kern.cam.boot_delay loader tunable should help controllers that > > are still unable to register their buses in time (such as slow USB/ > > PCCard/ CardBus devices). > With kern.cam.boot_delay=15000 (I suppose that it was in ms) I can now > boot from my sim card reader. So do I with kern.cam.boot_delay=6000 for my EEEPC-1000: ----- % uname -a FreeBSD izar 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r202734M: Thu Jan 21 18:13:10 MSK 2010 bsam@izar:/obj/usr/src/sys/EEEBB i386 ----- > > - To allow synchronization between different CAM levels, concept of > > requests priorities was extended. Priorities now split between several > > "run levels". Device can be freezed at specified level, allowing higher > > priority requests to pass. For example, no payload requests allowed, > > until PMP driver enable port. ATA XPT negotiate transfer parameters, > > periph driver configure caching and so on. > > - Frozen requests are no more counted by request allocation scheduler. > > It fixes deadlocks, when frozen low priority payload requests occupying > > slots, required by higher levels to manage theit execution. > > - Two last changes were holding proper ATA reinitialization and error > > recovery implementation. Now it is done: SATA controllers and Port > > Multipliers now implement automatic hot-plug and should correctly > > recover from timeouts and bus resets. > > > > Patch can be found here: > > http://people.freebsd.org/~mav/cam-ata.20100119.patch > > > > Feedback as always welcome. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 19:58:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF3EA1065676 for ; Thu, 21 Jan 2010 19:58:12 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7730F8FC15 for ; Thu, 21 Jan 2010 19:58:11 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so106291eyd.9 for ; Thu, 21 Jan 2010 11:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=rpU0RmucqWbo6HFyc724SUqxUjH/a1z3KeAQRVnyFKI=; b=dgyQ58d66jBlk6Uf8yj1mKH24igAJqUxjDVRo32tp171OEBZ/tTTVfH6jvBuuu12ru Hrixk6xPBkMtiT2bT6enZfR5m98d5suto3W31CwWBExaDgEGLi7gFHuBp33ho7VWsYJ3 lzpRtEe2aq5rcWbi/QAcKgxW3qLedyvb+aI9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=r39Th1J4gx2bT4kVjf4+Z4O5/gTBYm70czGCasTNlRnDFCvsEZbsNqJpWzVAgdv6SN eRPtCtraBeaioPz9CA3VCbVYKLblNex5QBUZOxVqJpH79P+IwKWMUrufseFv+WEOqIzz bmte5X0/c6spzL0ZjWpw9z+ke6uzOhvTAw62A= Received: by 10.213.107.69 with SMTP id a5mr1734234ebp.73.1264103890981; Thu, 21 Jan 2010 11:58:10 -0800 (PST) Received: from dragon.dg ([41.216.197.17]) by mx.google.com with ESMTPS id 5sm1605500eyh.24.2010.01.21.11.58.08 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 11:58:10 -0800 (PST) From: David Naylor Organization: Private To: Andriy Gapon Date: Thu, 21 Jan 2010 21:58:07 +0200 User-Agent: KMail/1.12.3 (FreeBSD/8.0-STABLE; KDE/4.3.3; amd64; ; ) References: <201001201543.15818.naylor.b.david@gmail.com> <201001211952.20202.naylor.b.david@gmail.com> <4B58953F.10404@icyb.net.ua> In-Reply-To: <4B58953F.10404@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2244530.oVi6VMMIuN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001212158.13250.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: stacked unionfs freeze and crash FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 19:58:13 -0000 --nextPart2244530.oVi6VMMIuN Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday 21 January 2010 19:56:15 Andriy Gapon wrote: > on 21/01/2010 19:52 David Naylor said the following: > > On Wednesday 20 January 2010 19:16:59 Andriy Gapon wrote: > >> Double-fault could indicate stack overflow. > > > > Thanks, I bumped KSTACK_PAGES to 32 (just to be on the safe side) and it > > is working fairly well now. Only crash I have had since was related to > > tmpfs. So far I have successfully build a port with 59 stacked unionfs = (1 > > rw, 58 ro). >=20 > Good that you found a workaround, bad that there is no better way to hand= le > this overflow. Or, is there? What would make it easier is having kern.kstack_pages tunable (and having t= he=20 appropriate changes to use that variable). =20 I do not know the internals of the kernel but is it possible for unionfs=20 (assuming it runs in its own thread) to specify a stack size big enough?. = =20 It might even be possible to extend unionfs to mount multiple directories o= nto=20 another, at once (thus eliminating the need for multiple mounts). And=20 probably a measurable performance increase? P.S. Twice I have had processes freeze, these were restricted to directori= es=20 affected by unionfs mounts. --nextPart2244530.oVi6VMMIuN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktYsdUACgkQUaaFgP9pFrJ8EgCffURcPPOMn2X/PXngfsWxAMJD n9QAn0NS9hY4fF8y1Wi6Xy85EEd8DTAi =jLmX -----END PGP SIGNATURE----- --nextPart2244530.oVi6VMMIuN-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 21:43:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98D011065692 for ; Thu, 21 Jan 2010 21:43:19 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63901.mail.re1.yahoo.com (web63901.mail.re1.yahoo.com [69.147.97.116]) by mx1.freebsd.org (Postfix) with SMTP id 274508FC08 for ; Thu, 21 Jan 2010 21:43:18 +0000 (UTC) Received: (qmail 91769 invoked by uid 60001); 21 Jan 2010 21:43:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264110198; bh=z0QgphZo7O4b9bDOgqPofZbqb1qZU1roWswYlwmzm6U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Avo1KVLQMIAc9JlgOja4udZ4XNky904l1kqElMXblGKkZ2P5juNpQti27XBCuizftfw/l2rXF26HWqOmmHv+giKp2AuQInOLEExWZJalV80HI+dd/0VplwM/X8OE7O6yP9oYHu/PjtaY0PySwyMzYuJy8xO/cptoWwgT7naIRgI= 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=0kdwOjHzW1RaU3i3kWTLrJCZorG2eduLIu4LIlva32IIJFKMKhCfC4j7PQtblPFfdYF2yY08PS0/NP9SUix2N6KoYJ/btmmF1sDDLqaz5haqbjV8fHTzkRvspDi3mB5ulMj7YHlo5dSMT8SWRhzsbuYseZ7oo1AfYtCdkz+t8kA=; Message-ID: <229631.91265.qm@web63901.mail.re1.yahoo.com> X-YMail-OSG: ph4F5JMVM1k3V.rS1.uWsntd6VcoPDNuP5GeZlVlmPVDKwaIkJ1fQwSwR3QLZtShV0WsmKBmGgTV59VDvRhnltoi7nU_OvnxE_cuXkUngWtoaFqfQeyF9XcUzQkETsIyserC6e18ASaBOq8FRTIeYBLt1aTXYtmLfYTeCn_KlCIiSdZBgzY7CG3gzwwAHENyGsrsDlhSHM_UTiPpX4W327.EPgDMLy9QWBJdyg-- Received: from [98.203.21.152] by web63901.mail.re1.yahoo.com via HTTP; Thu, 21 Jan 2010 13:43:18 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Thu, 21 Jan 2010 13:43:18 -0800 (PST) From: Barney Cordoba To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Error with OCZ SSD drive in 7.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:43:19 -0000 Any clues as what this problem is or if there are newer patches? kernel: ad10: FAILURE - SET_MULTI status=51 error=4 kernel: ad10: 122114MB at ata5-master SATA300 Barney From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 21:58:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7A891065670 for ; Thu, 21 Jan 2010 21:58:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0B56D8FC1E for ; Thu, 21 Jan 2010 21:58:17 +0000 (UTC) Received: by fxm26 with SMTP id 26so302571fxm.33 for ; Thu, 21 Jan 2010 13:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/D3YnVkcAZWxxxwXTIgYdSfdOtiEYqSZ2khXL29yix0=; b=KbVOgFo6Vbe8iUSkjdOwcpEktLrnaSsXjuYEZhLlRNtkLiY+CjKB3BiS1drfRkNCg4 XNeetHVJ6z6lnG+lcmCruvPpQA2pRLCCYKF8cW7YWh115foFvHBTbgexZ2riKlHMbGBz amUe6eD6reV73uZ5444oL5aXXWy94+uaaBhJ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=RK+Nx9p1gFtNbGT2mOQjH5lg4l12a5LT4enA81dxIVx9Ew/fwxqhXYHS+NGANBksKl hrmwYYzRnF17DRyy+cKP8T1/QUCIK813sAcDV9J+If6e8V5LohwnhgPDl2vBOy2pEtjU Hq5NKWJjouPZ6A7FOnEhGBh/7kJr2sHT/T9eM= Received: by 10.223.144.207 with SMTP id a15mr2087244fav.70.1264111094629; Thu, 21 Jan 2010 13:58:14 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm913658fxm.1.2010.01.21.13.58.13 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 13:58:14 -0800 (PST) Sender: Alexander Motin Message-ID: <4B58CDF3.1030503@FreeBSD.org> Date: Thu, 21 Jan 2010 23:58:11 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Barney Cordoba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Error with OCZ SSD drive in 7.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:58:19 -0000 Barney Cordoba wrote: > Any clues as what this problem is or if there are newer patches? > > kernel: ad10: FAILURE - SET_MULTI status=51 error=4 > kernel: ad10: 122114MB at ata5-master SATA300 I think it is fixed in recent 7/8-STABLE. Try to update. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 21:23:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 001F41065672 for ; Thu, 21 Jan 2010 21:23:50 +0000 (UTC) (envelope-from tobias.rehbein@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 492F68FC1B for ; Thu, 21 Jan 2010 21:23:50 +0000 (UTC) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate03.web.de (Postfix) with ESMTP id 7C1BB13C6BB2B for ; Thu, 21 Jan 2010 22:05:27 +0100 (CET) Received: from [95.88.224.31] (helo=sushi.pseudo.local) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1NY4DW-0007zs-00 for freebsd-current@freebsd.org; Thu, 21 Jan 2010 22:05:27 +0100 Received: from sushi.pseudo.local (localhost [127.0.0.1]) by sushi.pseudo.local (8.14.3/8.14.3) with ESMTP id o0LL5O0e002035; Thu, 21 Jan 2010 22:05:24 +0100 (CET) (envelope-from tobi@sushi.pseudo.local) Received: (from tobi@localhost) by sushi.pseudo.local (8.14.3/8.14.3/Submit) id o0LL5NAs002034; Thu, 21 Jan 2010 22:05:24 +0100 (CET) (envelope-from tobi) Date: Thu, 21 Jan 2010 22:05:23 +0100 From: Tobias Rehbein To: freebsd-current@freebsd.org Message-ID: <20100121210523.GA1442@sushi.pseudo.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nmemrqcdn5VTmUEE" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: tobias.rehbein@web.de X-Sender: tobias.rehbein@web.de X-Provags-ID: V01U2FsdGVkX19WWoAmnsiKvD6MDji3iKT6JA2pn8jrFiMuT5Zv L4osc6oxAU4Y/D7hNj8TkInXvxVC3RxTL/vkV2mecdObAYUVml kkoesnQ5VDzwnDgqHUGw== X-Mailman-Approved-At: Thu, 21 Jan 2010 22:18:54 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [patch] Let indent(1) handle widecharacter literals correctly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:23:51 -0000 --nmemrqcdn5VTmUEE Content-Type: multipart/mixed; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I am not subscribed to this list, so please answer me off-list or cc me. I noticed that indent(1) handles widecharacter literals (e.g. L'c' or L"str= ing") incorrectly. indent(1)s parser treats the L-prefix and the quoted part as seperate tokens. The result is: L'c' -> L 'c' L"string" -> L "string" Of course this breaks any code using widecharacters. As I use indent(1) qui= te extensively I decided to fix this issue. As this is my first patch against = the FreeBSD user land feel free to comment! Find attached: indent.diff: the patch wcsxfrm.old.c: the result of `indent wcsxfrm.c`; using the indent(1) version from the base system =20 wcsxfrm.new.c: the result of `indent wcsxfrm.c`; using the patched indent(1) Please note the diff between wcsxfrm.old.c and wcsxfrm.new.c: =20 =3D=3D=3D=3D=3D=3D=3D=3D diff -u wcsxfrm.old.c wcsxfrm.new.c =3D=3D=3D=3D= =3D=3D=3D=3D --- wcsxfrm.old.c 2010-01-21 18:49:04.000000000 +0100 +++ wcsxfrm.new.c 2010-01-21 18:49:48.000000000 +0100 @@ -49,9 +49,9 @@ size_t slen; char *mbsrc, *s, *ss; =20 - if (*src =3D=3D L '\0') { + if (*src =3D=3D L'\0') { if (len !=3D 0) - *dest =3D L '\0'; + *dest =3D L'\0'; return (0); } if (__collate_load_error || MB_CUR_MAX > 1) { @@ -61,7 +61,7 @@ wcscpy(dest, src); else { wcsncpy(dest, src, len - 1); - dest[len - 1] =3D L '\0'; + dest[len - 1] =3D L'\0'; } } return (slen); @@ -87,7 +87,7 @@ free(ss); free(mbsrc); if (len !=3D 0) - *dest =3D L '\0'; + *dest =3D L'\0'; =20 return (slen); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Regards --=20 Tobias Rehbein PGP key: 4F2AE314 server: keys.gnupg.net fingerprint: ECDA F300 1B6E 9B87 8524 8663 E8B6 3138 4F2A E314 --PmA2V3Z32TCmWXqI Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="indent.diff" Content-Transfer-Encoding: quoted-printable diff -u /usr/src/usr.bin/indent/Makefile usr.bin/indent/Makefile --- /usr/src/usr.bin/indent/Makefile 2010-01-20 23:59:33.000000000 +0100 +++ usr.bin/indent/Makefile 2010-01-21 19:01:13.000000000 +0100 @@ -3,4 +3,6 @@ PROG=3D indent SRCS=3D indent.c io.c lexi.c parse.c pr_comment.c args.c =20 +WARNS?=3D 6 + .include diff -u /usr/src/usr.bin/indent/lexi.c usr.bin/indent/lexi.c --- /usr/src/usr.bin/indent/lexi.c 2010-01-20 23:59:33.000000000 +0100 +++ usr.bin/indent/lexi.c 2010-01-21 18:52:49.000000000 +0100 @@ -221,6 +221,13 @@ } else break; } + if (*buf_ptr =3D=3D 'L' && (*(buf_ptr + 1) =3D=3D '\'' || = *(buf_ptr + 1) =3D=3D '"' ) && (s_token =3D=3D e_token)) { + /* widecharacter literal */ + *e_token++ =3D *buf_ptr++; /* copy L */ + *e_token++ =3D *buf_ptr; /* copy ' or " */ + qchar =3D *buf_ptr++; /* set string de= limeter */ + goto found_string; + } CHECK_SIZE_TOKEN; /* copy it over */ *e_token++ =3D *buf_ptr++; @@ -361,6 +368,7 @@ case '\'': /* start of quoted character */ case '"': /* start of string */ qchar =3D *token; +found_string: if (troff) { e_token[-1] =3D '`'; if (qchar =3D=3D '"') --PmA2V3Z32TCmWXqI-- --nmemrqcdn5VTmUEE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktYwZEACgkQ6LYxOE8q4xSYWgCeJKty9Ypk6BCr1V+54q+R0xo8 jNgAoIcvAger3Oc9rsna5A0RXdnKeFrc =0vBN -----END PGP SIGNATURE----- --nmemrqcdn5VTmUEE-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 22:49:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 924CD106566C for ; Thu, 21 Jan 2010 22:49:24 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id 56B308FC0C for ; Thu, 21 Jan 2010 22:49:24 +0000 (UTC) Received: by iwn1 with SMTP id 1so482986iwn.28 for ; Thu, 21 Jan 2010 14:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=sVf+8pufJzAusc4LqBcXfJ5w4AK4rskMoIiKWE0rm9M=; b=U/lJ0PzEQvSXaR/hmtwYSQ3uIqULyEA6zSBB9bO0mpNDLSjWfUUOQWAAULjKLuOBxF 7CHdxWczQvvY4CBvCfOPzdowDJWh/PB9MX+dKSZVw0hVGdxlBUSBsOrrOIWZUNMl4QQf 0TULOdgw+f9Zqqr77HxpD964hocbL5k6mIoHw= 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=Pp30S578CFP9qU3aMNEoWtRkDX/ctMr4PyLdzhF78oeAmJhKUuF1tjsu0PzV4QglDV 7K10UJTv4x5EgJEM2nNEbHV1tZpBnUhygDPcHSJhQSSzDE/Rmwup5dX4odoV79MLNfuU 1id0FJuWJiULqqEZLPmjwP1bb0TK6MbuQ/Aps= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.150.2 with SMTP id w2mr2429021ibv.83.1264114163225; Thu, 21 Jan 2010 14:49:23 -0800 (PST) In-Reply-To: <4e6cba831001192332j1e23bb1chdf2f47664d3cb14a@mail.gmail.com> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <4e6cba831001192332j1e23bb1chdf2f47664d3cb14a@mail.gmail.com> Date: Thu, 21 Jan 2010 23:49:23 +0100 X-Google-Sender-Auth: ac054d512b66b2a6 Message-ID: <3bbf2fe11001211449je30b643y53fe0830bcbf3e5d@mail.gmail.com> From: Attilio Rao To: Giovanni Trematerra Content-Type: text/plain; charset=UTF-8 Cc: Jeff Roberson , freebsd-current@freebsd.org, Kohji Okuno Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 22:49:24 -0000 2010/1/20 Giovanni Trematerra : > On Mon, Jan 18, 2010 at 3:58 AM, Attilio Rao wrote: >> 2010/1/17 Kohji Okuno : >>> Hello, >>> >>> Could you check sched_4bsd.patch, please? >> >> I think, instead, that what needs to happen is to have sched_switch() >> to do a lock handover from sleepq/turnstile spinlock to schedlock. >> That way, if threads are willing to contest on td_lock they will be >> still inhibited. >> I'm not sure if this patch breaks any invariant, if you may test I >> would appreciate: >> http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff > > I stressed an 8-core machine with pho's stress2 kernel stress suite and > your patch seems to break the invariant THREAD_LOCKPTR_ASSERT in > turnstile_claim:subr_turnstile.c Oh, right, I guess what we really want is to block the td_lock. This is the new patch: http://www.freebsd.org/~attilio/sched_4bsd_schedlock2.diff Thanks a lot for your testing, it is much appreciated. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 23:02:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41386106568B for ; Thu, 21 Jan 2010 23:02:09 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63903.mail.re1.yahoo.com (web63903.mail.re1.yahoo.com [69.147.97.118]) by mx1.freebsd.org (Postfix) with SMTP id DE42F8FC2F for ; Thu, 21 Jan 2010 23:02:08 +0000 (UTC) Received: (qmail 41799 invoked by uid 60001); 21 Jan 2010 23:02:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264114928; bh=LXOjGS1cOrTrVKbvSTVK77Hd9EWtwLHggRU/Ts0hUNA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=J3G7nBonFNMpn+P8P697Nj2eehEy+hhnrwWDjFtUMqk00u9QYpulvGGx0ZMTKo7Kj5elzgoUA6KklTMOUbT5qSEoW576Gs0LuK10hgVAFlOJILTA4APygEFP6vJaoA+/2D+vvWuv7uw86fpMPVjVrPajmusVsaQ6k87rsXxpNhg= 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:Cc:In-Reply-To:MIME-Version:Content-Type; b=sJOeZCefNV1abC6KB+AG0xbpu7KoNYMn3BDAM0UzXX7JtnTW71jEMJe1kLstxb8COwTjRKfjStASxb5Rv/hIgudoJjlzAWnXpw+ycywzKKRGTasHDd1OE+2tPqJczNkFbl5oejN834W0VfrTO1SfWwBWDxmcgJl3Njw//VCE9hQ=; Message-ID: <140705.41585.qm@web63903.mail.re1.yahoo.com> X-YMail-OSG: J2RLWzAVM1l7EO.VviEHt6H5dnnIm3Eq6COyQzEFYLguY5VlrruxC4j4zbS7DKJcnX_Hwh86HrijzzBdrgRM2hznFBBwVajL_v5QNKCpmhfRMnnFp39x2x8ad8Kt5wCWDQxqqb4nf3ymwhIlrKv5Cq13AzJN_MUlPbKWDVPfuLTl9mAvgZwMUX_UYdw.5_y01KfIBswVLhBj7nxn3Xp2cB.uQniObb1bZaPOiIwcMDcVrEp0MknmHxHlHUujFPjWQveB5oCrQbdEVLM3MIHcauS_sZ7AO75WBuqQ Received: from [98.203.21.152] by web63903.mail.re1.yahoo.com via HTTP; Thu, 21 Jan 2010 15:02:07 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Thu, 21 Jan 2010 15:02:07 -0800 (PST) From: Barney Cordoba To: Alexander Motin In-Reply-To: <4B58CDF3.1030503@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD-Current Subject: Re: Error with OCZ SSD drive in 7.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 23:02:09 -0000 --- On Thu, 1/21/10, Alexander Motin wrote: > From: Alexander Motin > Subject: Re: Error with OCZ SSD drive in 7.2 > To: "Barney Cordoba" > Cc: "FreeBSD-Current" > Date: Thursday, January 21, 2010, 4:58 PM > Barney Cordoba wrote: > > Any clues as what this problem is or if there are > newer patches? > > > > kernel: ad10: FAILURE - SET_MULTI > status=51 error=4 > > kernel: ad10: 122114MB at > ata5-master SATA300 > > I think it is fixed in recent 7/8-STABLE. Try to update. Updating is an issue as there are some customizations. Can you point me at what code/file to look at? Barney From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 23:26:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53F7410656C7 for ; Thu, 21 Jan 2010 23:26:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id 178178FC16 for ; Thu, 21 Jan 2010 23:26:54 +0000 (UTC) Received: by iwn1 with SMTP id 1so509964iwn.28 for ; Thu, 21 Jan 2010 15:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=h02snSL1dg7s2+xphlxgnQfyM77+TggbeRMsGOwAQ4I=; b=ZWXzJqOGH9gBlvda1hRnY7SeReAEPtZYMEyyJqk8Ce+Lad5OxFB6YQc6j8+d7I6Z8S 78jJft2erbs6nOSSn40n9m5JLfZLSL//YCl4OOk9OOJr8WpJT6kAosNAqPCW7NLtUxNW i4AWGVqisVp4upwLd8BaVr9j3EcZRxP4GWPpM= 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=ruDvbNaBvk2CFoMMOMVcCPdsAbj/X5q3B2FclFZcgOn2NpnDGFvqgm8UfNXZpouiGY NDMrPa9DtGq6Ri4jFx29451XU4I6jSRssMi4p2I7B7zBvsTN5oedKjJRtpsuUTSzQp1c QDDA6F14J8Mipi701KWukdwl0oNcQ8JyPgU2Y= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.147.210 with SMTP id m18mr3481272ibv.48.1264116414320; Thu, 21 Jan 2010 15:26:54 -0800 (PST) In-Reply-To: <3bbf2fe11001211449je30b643y53fe0830bcbf3e5d@mail.gmail.com> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <4e6cba831001192332j1e23bb1chdf2f47664d3cb14a@mail.gmail.com> <3bbf2fe11001211449je30b643y53fe0830bcbf3e5d@mail.gmail.com> Date: Fri, 22 Jan 2010 00:26:54 +0100 X-Google-Sender-Auth: 89616ff8f315f7bd Message-ID: <3bbf2fe11001211526r1ac89d13md5fbc1e0d6b9a160@mail.gmail.com> From: Attilio Rao To: Giovanni Trematerra Content-Type: text/plain; charset=UTF-8 Cc: Jeff Roberson , freebsd-current@freebsd.org, Kohji Okuno Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 23:26:55 -0000 2010/1/21 Attilio Rao : > 2010/1/20 Giovanni Trematerra : >> On Mon, Jan 18, 2010 at 3:58 AM, Attilio Rao wrote: >>> 2010/1/17 Kohji Okuno : >>>> Hello, >>>> >>>> Could you check sched_4bsd.patch, please? >>> >>> I think, instead, that what needs to happen is to have sched_switch() >>> to do a lock handover from sleepq/turnstile spinlock to schedlock. >>> That way, if threads are willing to contest on td_lock they will be >>> still inhibited. >>> I'm not sure if this patch breaks any invariant, if you may test I >>> would appreciate: >>> http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff >> >> I stressed an 8-core machine with pho's stress2 kernel stress suite and >> your patch seems to break the invariant THREAD_LOCKPTR_ASSERT in >> turnstile_claim:subr_turnstile.c > > Oh, right, I guess what we really want is to block the td_lock. > This is the new patch: > http://www.freebsd.org/~attilio/sched_4bsd_schedlock2.diff FYI, I've updated the patch with a more correct use of thread_lock_block() and a merge of this interface with the custom interface of thread_block_switch() from ULE. The overall result should be better (and more correct). Please refresh your patch. Testing with ULE should be due as well. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Jan 21 23:32:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 217AE106566B for ; Thu, 21 Jan 2010 23:32:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id D98C58FC08 for ; Thu, 21 Jan 2010 23:32:37 +0000 (UTC) Received: by iwn1 with SMTP id 1so513780iwn.28 for ; Thu, 21 Jan 2010 15:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=frDr22ItqhWH9uJJ0lMg1+s9nt9RIODKGgDNmH/Ntl8=; b=i76DK8JzbAXLgSq1AcbZ62M4Y5QU8om4HnVUK+SxTYNFWBSCwNk3Qv/tcIAT5M2SON 58lfBMs9DO6Gs8RpLIoRv4a3+nje+6Zs7xZOG1eb/sLWmltmdVcZ6HawMFdmEy0QlgFz I7/y+t4BjB937ge0TwU3zjdmGATlCEYouIUGQ= 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=QSSkhTX6EZUgwkAASqJ1/5J+BnJ+tS+YUa/VF3OLApz1br6XFdZkGV+3cUqBqj7mG9 WVCXuI5Uch1BKzocIbF3PzR4sfiPaOAmFvMO8J+LCprgrZE3v2ZvMC1Z7Ah7wO3Z/2ai HwALIMsv2inoQggoS8wBZrXXaP47uL2EXvKTw= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.150.2 with SMTP id w2mr2503845ibv.83.1264116756925; Thu, 21 Jan 2010 15:32:36 -0800 (PST) In-Reply-To: <20100120.115218.999284356098982813.okuno.kohji@jp.panasonic.com> References: <20100119.103858.29593248145858473.okuno.kohji@jp.panasonic.com> <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com> <20100120.115218.999284356098982813.okuno.kohji@jp.panasonic.com> Date: Fri, 22 Jan 2010 00:32:36 +0100 X-Google-Sender-Auth: cf3d38b5c6808f03 Message-ID: <3bbf2fe11001211532i1cc4eaa8n3d56df04f337298@mail.gmail.com> From: Attilio Rao To: Kohji Okuno Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 23:32:38 -0000 2010/1/20 Kohji Okuno : > Hello, Attilio > >>>> I think setpriority() can set priority to sleeping threads. >>>> Is it really safe? >>> >>> I agree, in this code path maybe_resched is not properly locking curthr= ead. >>> =C2=A0curthread will be sched_lock and the sleeping thread will be a sl= eepq lock. >>> =C2=A0I believe that since &sched_lock is ordered after container locks= it would >>> be sufficient to compare the two td_lock pointers and acquire sched_loc= k if >>> they are not equal. =C2=A0Someone should look at other maybe_resched ca= llers or >>> add an assert that curthread->td_lock is always &sched_lock in this >>> function. >> >> I'm not sure I understand you well here, but I generally don't agree, >> if we speak about the current code plus the patch I posted. > > I understood. If the current code plus your patch, meybe_resched() is > no problem. I think, your patch is perfect if theare is no problem > even if a sleeping thread sets &sched_lock to td->td_lock. > > Why do we call thread_lock_set() in sleepq_switch() and turnstile_wait()? > In case of sched_4bsd, is not thread_lock_set() needed? This question may be needing a very long answer :) The short one, though, is that the thread_*lock*() interface handle the locking of the thread containers (runqueues, sleepqueues, turnstiles) transparently and in atomic way. What happens is that threads may be (mostly, with some notable exceptions like the ithread case being parked on IWAIT and not having a specific container) in one of the three above mentioned containers which also need to handle flags and option specific to the thread and the container. In order to do that atomically you may need 'global' locks that protects such interactions (thus you have sched_lock which protects runqueue, sleepqueue locks and turnstile locks). You could also have just a global spinlock, but that would mean having a lot of intollerable contention on it. thread_lock_set() is just used to switch locks when threads passes from a container to another. For example, immagine a thread running that goes blocking on a turnstile. At some point, the thread container lock, as the thread switches from runqueue to turnstile, needs to switch from sched_lock to ts_lock and it is precisely when thread_lock_set() takes place. Thus when the thread is resumed for running, it needs to switch again from ts_lock to sched_lock. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 00:55:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3B211065694 for ; Fri, 22 Jan 2010 00:55:38 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 4D1348FC15 for ; Fri, 22 Jan 2010 00:55:38 +0000 (UTC) Received: (qmail invoked by alias); 22 Jan 2010 00:55:36 -0000 Received: from e180217231.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [85.180.217.231] by mail.gmx.com (mp-eu003) with SMTP; 22 Jan 2010 01:55:36 +0100 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX18bRNE3BwsbIAVj8Tca3fvJT82coXV309EbF0D4P8 t2ql3kGL0hrHca Received: by myhost.mydomain.de (Postfix, from userid 1001) id 83A0472BB; Fri, 22 Jan 2010 01:55:35 +0100 (CET) From: Christof Schulze To: freebsd-current@freebsd.org Date: Fri, 22 Jan 2010 01:55:28 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> In-Reply-To: <201001101437.37269.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1275263.eOSmHdpN40"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001220155.34784.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53000000000000003 Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 00:55:39 -0000 --nextPart1275263.eOSmHdpN40 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am unsure whether I missed anything so here is what I did csup to 8_RELENG rebuild kernel & world portmanager webcamd (which built video4bsd also) kldload video4bsd webcamd webcamd -d ugen0.2 -i 0 -v 0 but I get Cannot open /dev/video_daemonX. Did you kldload video4bsd? this is the relevant part from dmesg: video4bsd: /dev/video0..9, /dev/video_daemon0..9 ugen0.2: at usbus0 (disconnected) uaudio0: at uhub0, port 2, addr 2 (disconnected) pcm2: detached ugen0.2: at usbus0 uaudio0: =20 on usbus0 uaudio0: No playback! uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format uaudio0: No midi sequencer pcm2: on uaudio0 what am I missing? The device is supported on linux by the gspca driver. Regards Christof Am Sonntag 10 Januar 2010 14:37:37 schrieb Hans Petter Selasky: > Hi, >=20 > During the last couple of days I've spent some time to finish my webcam > daemon. My webcam daemon is basically an application which consists of > userspace Video4Linux USB webcam drivers and some uLinux glue code which > links with libc, pthreads and libusb. The webcamd talks to > /dev/video_daemonX which is provided by the video4bsd kernel module.=20 There > is full support for mmap/read/write/open/close. poll is not supported. >=20 > Basic operation and idea: >=20 > /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the > interface for the V4L application. The video4bsd transports all data > between these two devices. In the case the V4L application is using=20 mmap, > no data is copied due to shared kernel memory buffer! >=20 > Licensing issues: >=20 > Effectivly the webcamd userland program becomes GPL'ed due to the V4L=20 USB > drivers which are GPL licensed. Some files inside the webcamd remains=20 BSD > licensed which allows for building similar BSD licensed daemons. >=20 > The rest of the code is BSD licensed. >=20 > Source code: >=20 > 1) FreeBSD 8-stable >=20 > 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: >=20 > http://p4web.freebsd.org/chv.cgi?CH=3D172876 >=20 > http://perforce.freebsd.org/chv.cgi?CH=3D172876 >=20 > 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be > checked out in the same folder due to dependencies) >=20 > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd >=20 > make all install > kldload video4bsd >=20 > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux >=20 > make fetch > make patch > make all > make install >=20 > # this will attach to the first detected webcam: > ./webcamd >=20 > # this will try to attach to the given USB unit, interface and V4B unit. > ./webcamd -d ugen4.1 -i 0 -v 0 >=20 > # this will display webcam contents from /dev/video0 by default. > ./pwcview/pwcview >=20 > Feedback and bug reports are welcome. >=20 > Yes, I am working on getting this into ports! >=20 > Known issues: >=20 > 1) If you detach the USB webcam you need to manually restart the=20 webcamd. >=20 > --HPS >=20 > Support: I will be available at #bsdusb on efnet during the day. > _______________________________________________ > 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" >=20 =2D-=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --nextPart1275263.eOSmHdpN40 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktY94YACgkQpZfyPAmdZJl84ACghTAQ4b0idPSirqUdMu0JJPYt +h4An2C/E6XISeuQMUelkSIfmS/3cHks =6cYm -----END PGP SIGNATURE----- --nextPart1275263.eOSmHdpN40-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 04:12:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91EAF1065692 for ; Fri, 22 Jan 2010 04:12:15 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 090858FC08 for ; Fri, 22 Jan 2010 04:12:14 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0M4CBne068622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 Jan 2010 14:42:11 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 22 Jan 2010 14:41:56 +1030 User-Agent: KMail/1.9.10 References: <201001101437.37269.hselasky@c2i.net> <201001220155.34784.christof.schulze@gmx.com> In-Reply-To: <201001220155.34784.christof.schulze@gmx.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1917666.SfmEZSaHeW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001221442.07624.doconnor@gsoft.com.au> X-Spam-Score: -3.637 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Christof Schulze Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 04:12:15 -0000 --nextPart1917666.SfmEZSaHeW Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 22 Jan 2010, Christof Schulze wrote: > kldload video4bsd > webcamd > webcamd -d ugen0.2 -i 0 -v 0 > > but I get > Cannot open /dev/video_daemonX. Did you kldload video4bsd? Did you run webcamd as root? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1917666.SfmEZSaHeW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLWSWX5ZPcIHs/zowRAjKnAKCAxPvRP5Tl8abBx3jL5S4X6JNcowCeMFJS 8uMwsVDSbgriI1N5bFbNXWo= =IlNf -----END PGP SIGNATURE----- --nextPart1917666.SfmEZSaHeW-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 05:04:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EE21106566C; Fri, 22 Jan 2010 05:04:36 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 174628FC0C; Fri, 22 Jan 2010 05:04:35 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0M51sPv009469; Fri, 22 Jan 2010 15:31:54 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Fri, 22 Jan 2010 15:34:34 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 15:34:33 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 13:04:32 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0M4voNl061201; Fri, 22 Jan 2010 12:57:50 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0M4voYd061200; Fri, 22 Jan 2010 12:57:50 +0800 (WST) (envelope-from wilkinsa) Date: Fri, 22 Jan 2010 12:57:50 +0800 From: "Wilkinson, Alex" To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100122045750.GF56085@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org References: <201001101437.37269.hselasky@c2i.net> <20100120064620.GJ46479@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100120064620.GJ46479@stlux503.dsto.defence.gov.au> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 22 Jan 2010 05:04:32.0819 (UTC) FILETIME=[628DA830:01CA9B20] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17146.002 X-TM-AS-Result: No-0.405400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 05:04:36 -0000 0n Wed, Jan 20, 2010 at 02:46:20PM +0800, Wilkinson, Alex wrote: > 0n Sun, Jan 10, 2010 at 02:37:37PM +0100, Hans Petter Selasky wrote: > > >During the last couple of days I've spent some time to finish my webcam > >daemon. My webcam daemon is basically an application which consists of > >userspace Video4Linux USB webcam drivers and some uLinux glue code which links > >with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX which > >is provided by the video4bsd kernel module. There is full support for > >mmap/read/write/open/close. poll is not supported. /usr/ports/multimedia/pwcview (PORTVERSION=1.4.1) crashes within 2-3mins of use with the following: #sudo pwcview Webcam set to: 320x240 (sif) at 5 fps libv4lconvert: Error decompressing JPEG: fill_nbits error: need 3 more bits libv4l2: error dequeuing buf: Device not configured Error reading from webcam: Device not configured I rebuilt /usr/ports/multimedia/pwcview with symbolls and got the following: #sudo gdb pwcview 75557 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Attaching to program: /usr/local/bin/pwcview, process 75557 Reading symbols from /usr/local/lib/libSDL-1.2.so.11...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libSDL-1.2.so.11 Reading symbols from /usr/local/lib/libjpeg.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libjpeg.so.10 Reading symbols from /usr/local/lib/libv4l1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libv4l1.so.0 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. [New Thread 28601140 (LWP 100451)] Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/lib/libvgl.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libvgl.so.6 Reading symbols from /usr/local/lib/libaa.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libaa.so.1 Reading symbols from /usr/local/lib/libncurses.so.5.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libncurses.so.5.7 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/local/lib/libxcb.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb.so.2 Reading symbols from /usr/local/lib/libXau.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libXdmcp.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /usr/local/lib/libpthread-stubs.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpthread-stubs.so.0 Reading symbols from /usr/lib/librpcsvc.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librpcsvc.so.5 Reading symbols from /usr/lib/libusbhid.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libusbhid.so.4 Reading symbols from /usr/local/lib/libv4l2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libv4l2.so.0 Reading symbols from /usr/local/lib/libtinfo.so.5.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libtinfo.so.5.7 Reading symbols from /usr/local/lib/libv4lconvert.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libv4lconvert.so.0 Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /usr/local/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXext.so.6 Reading symbols from /usr/local/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libXrandr.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/local/lib/libXcursor.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcursor.so.1 Reading symbols from /usr/local/lib/libXfixes.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXfixes.so.3 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to Thread 28601140 (LWP 100451)] 0x281958bf in syscall () from /lib/libc.so.7 (gdb) b exit Breakpoint 1 at 0x281bd974 (gdb) cont Continuing. Breakpoint 1, 0x281bd974 in exit () from /lib/libc.so.7 (gdb) bt #0 0x281bd974 in exit () from /lib/libc.so.7 #1 0x080494cf in ?? () #2 0x00000000 in ?? () #3 0xbfbfec64 in ?? () #4 0xbfbfec6c in ?? () #5 0xbfbfec50 in ?? () #6 0xbfbfec60 in ?? () #7 0x00000000 in ?? () #8 0xbfbfec5c in ?? () #9 0x08049435 in ?? () #10 0x28054f60 in dlclose () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) (gdb) (gdb) cont Continuing. Program exited normally. (gdb) IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 05:22:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73F15106566C; Fri, 22 Jan 2010 05:22:27 +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 126C18FC14; Fri, 22 Jan 2010 05:22:26 +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 E060312543B; Fri, 22 Jan 2010 14:03:07 +0900 (JST) Message-ID: <4B59318B.1020906@freebsd.org> Date: Fri, 22 Jan 2010 14:03:07 +0900 From: Daichi GOTO Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hans Petter Selasky References: <201001101437.37269.hselasky@c2i.net> In-Reply-To: <201001101437.37269.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 05:22:27 -0000 Hi Hans, I have checked your work, and it works well, great :) This is a little tweak, --- /usr/local/etc/devd/webcamd.conf.orig 2010-01-22 13:19:20.371987293 +0900 +++ /usr/local/etc/devd/webcamd.conf 2010-01-22 13:52:00.286912793 +0900 @@ -1,5 +1,5 @@ attach 100 { - device-name "ugen[0-9]+"; + device-name "ugen[0-9.]+"; match "intclass" "(0x0e|0xff)"; action "/usr/local/etc/rc.d/webcamd start $device-name"; }; I want to know what does "intclass" mean. The webcamd(8) cannot been engaged automatically by devd(8), because of not match of "intclass". when webcam device attached, cosole output: Jan 22 13:50:26 parancell daichi: Unknown USB device: vendor 0x046d product 0x09a2 bus uhub7 Jan 22 13:50:26 parancell kernel: ugen7.2: at usbus7 % sudo usbconfig -d ugen7.2 ugen7.2: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON % On 2010/01/10 22:37, Hans Petter Selasky wrote: > Hi, > > During the last couple of days I've spent some time to finish my webcam > daemon. My webcam daemon is basically an application which consists of > userspace Video4Linux USB webcam drivers and some uLinux glue code which links > with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX which > is provided by the video4bsd kernel module. There is full support for > mmap/read/write/open/close. poll is not supported. > > Basic operation and idea: > > /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the > interface for the V4L application. The video4bsd transports all data between > these two devices. In the case the V4L application is using mmap, no data is > copied due to shared kernel memory buffer! > > Licensing issues: > > Effectivly the webcamd userland program becomes GPL'ed due to the V4L USB > drivers which are GPL licensed. Some files inside the webcamd remains BSD > licensed which allows for building similar BSD licensed daemons. > > The rest of the code is BSD licensed. > > Source code: > > 1) FreeBSD 8-stable > > 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: > > http://p4web.freebsd.org/chv.cgi?CH=172876 > > http://perforce.freebsd.org/chv.cgi?CH=172876 > > 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be checked > out in the same folder due to dependencies) > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd > > make all install > kldload video4bsd > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux > > make fetch > make patch > make all > make install > > # this will attach to the first detected webcam: > ./webcamd > > # this will try to attach to the given USB unit, interface and V4B unit. > ./webcamd -d ugen4.1 -i 0 -v 0 > > # this will display webcam contents from /dev/video0 by default. > ./pwcview/pwcview > > Feedback and bug reports are welcome. > > Yes, I am working on getting this into ports! > > Known issues: > > 1) If you detach the USB webcam you need to manually restart the webcamd. > > --HPS > > Support: I will be available at #bsdusb on efnet during the day. > _______________________________________________ > 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" -- Daichi GOTO 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 06:24:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5146E106566B for ; Fri, 22 Jan 2010 06:24:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id D386B8FC12 for ; Fri, 22 Jan 2010 06:24:56 +0000 (UTC) Received: by fxm27 with SMTP id 27so81927fxm.3 for ; Thu, 21 Jan 2010 22:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=qAy9SyvcKd8IGgy4KPC/7u8f9aTvW6q55XJMbUn58mI=; b=erLaH9yJuOEFMbRidyZ505PD8GBYHYMCCwlvfhL/dr5zWg60NM60u5EAbaqKPwjbCn +QMGUjmy1l2UUSoWRJsv2gP5BtFmJ1IW1etKz+Wn51WgHVRTZygV4bELkbeJuk67x/og Ols9Dw9+V7oQaHR8lXqntU3pFPzNGggACCXDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=fjFonAcGP1T2HA2xLmPICz7y20hGHVsaUPVMk4XAmxcPlf9dxQwXf63hWCyCtfl5i0 751O7NS6DbW7IazPP1axzxax5vHCmyHgIo+b/fqbfkEZCMKomFKzVHEs3vtrj3NGk5Hd IpGxjh505pPQmpJIdYcRziZbYnfb0b6pMdvaA= Received: by 10.223.5.142 with SMTP id 14mr2487630fav.39.1264141495775; Thu, 21 Jan 2010 22:24:55 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm1049893fxm.11.2010.01.21.22.24.54 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 22:24:54 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5944B4.4040207@FreeBSD.org> Date: Fri, 22 Jan 2010 08:24:52 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Barney Cordoba References: <140705.41585.qm@web63903.mail.re1.yahoo.com> In-Reply-To: <140705.41585.qm@web63903.mail.re1.yahoo.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Error with OCZ SSD drive in 7.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 06:24:57 -0000 Barney Cordoba wrote: > --- On Thu, 1/21/10, Alexander Motin wrote: >> From: Alexander Motin >>> Any clues as what this problem is or if there are >> newer patches? >>> kernel: ad10: FAILURE - SET_MULTI >> status=51 error=4 >>> kernel: ad10: 122114MB at >> ata5-master SATA300 >> >> I think it is fixed in recent 7/8-STABLE. Try to update. > > Updating is an issue as there are some customizations. Can you > point me at what code/file to look at? Here: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-disk.c.diff?r1=1.204.2.4;r2=1.204.2.5;f=h -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 08:05:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C4BF1065676; Fri, 22 Jan 2010 08:05:26 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id DB77F8FC0C; Fri, 22 Jan 2010 08:05:25 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id o0M85Njo001694; Fri, 22 Jan 2010 17:05:23 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id o0M85Mm15269; Fri, 22 Jan 2010 17:05:22 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla5) id o0M85KjN012449; Fri, 22 Jan 2010 17:05:20 +0900 (JST) Received: from localhost by somla5.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0M85FZc012172; Fri, 22 Jan 2010 17:05:15 +0900 (JST) Date: Fri, 22 Jan 2010 17:05:13 +0900 (JST) Message-Id: <20100122.170513.468378203492549701.okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org From: Kohji Okuno In-Reply-To: <3bbf2fe11001211532i1cc4eaa8n3d56df04f337298@mail.gmail.com> References: <3bbf2fe11001190152k15c24f70k876762817bf522c1@mail.gmail.com> <20100120.115218.999284356098982813.okuno.kohji@jp.panasonic.com> <3bbf2fe11001211532i1cc4eaa8n3d56df04f337298@mail.gmail.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: okuno.kohji@jp.panasonic.com, freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 08:05:26 -0000 Hello, Attilio, >>>>> I think setpriority() can set priority to sleeping threads. >>>>> Is it really safe? >>>> >>>> I agree, in this code path maybe_resched is not properly locking c= urthread. >>>> =A0curthread will be sched_lock and the sleeping thread will be a = sleepq lock. >>>> =A0I believe that since &sched_lock is ordered after container loc= ks it would >>>> be sufficient to compare the two td_lock pointers and acquire sche= d_lock if >>>> they are not equal. =A0Someone should look at other maybe_resched = callers or >>>> add an assert that curthread->td_lock is always &sched_lock in thi= s >>>> function. >>> >>> I'm not sure I understand you well here, but I generally don't agre= e, >>> if we speak about the current code plus the patch I posted. >> >> I understood. If the current code plus your patch, meybe_resched() i= s >> no problem. I think, your patch is perfect if theare is no problem >> even if a sleeping thread sets &sched_lock to td->td_lock. >> >> Why do we call thread_lock_set() in sleepq_switch() and turnstile_wa= it()? >> In case of sched_4bsd, is not thread_lock_set() needed? > = > This question may be needing a very long answer :) > = > The short one, though, is that the thread_*lock*() interface handle > the locking of the thread containers (runqueues, sleepqueues, > turnstiles) transparently and in atomic way. > What happens is that threads may be (mostly, with some notable > exceptions like the ithread case being parked on IWAIT and not having= > a specific container) in one of the three above mentioned containers > which also need to handle flags and option specific to the thread and= > the container. In order to do that atomically you may need 'global' > locks that protects such interactions (thus you have sched_lock which= > protects runqueue, sleepqueue locks and turnstile locks). You could > also have just a global spinlock, but that would mean having a lot of= > intollerable contention on it. > thread_lock_set() is just used to switch locks when threads passes > from a container to another. > For example, immagine a thread running that goes blocking on a > turnstile. At some point, the thread container lock, as the thread > switches from runqueue to turnstile, needs to switch from sched_lock > to ts_lock and it is precisely when thread_lock_set() takes place. > Thus when the thread is resumed for running, it needs to switch again= > from ts_lock to sched_lock. > = > Attilio Thank you very much your detailed expositoin. I can understand. I'm looking forward to the good result of your new patch. Thank you, Kohji Okuno. From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 08:10:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D48071065694 for ; Fri, 22 Jan 2010 08:10:11 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5A58FC26 for ; Fri, 22 Jan 2010 08:10:10 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o0M8A41M083888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 09:10:10 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B595D56.8030408@omnilan.de> Date: Fri, 22 Jan 2010 09:09:58 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig104FE01C6BCB0CF42491EF83" Subject: single (debug) binaries from base source tree install fails (/usr/bin/true) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 08:10:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig104FE01C6BCB0CF42491EF83 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I try to install a DEBUG_FLAGS=3D-g version of top since it core dumps on= =20 my 8.0-RELEASE box. Compiling works with warnings, but installing fails with superfluous=20 "/usr/bin/true" after install: install /usr/bin/true -o root -g wheel -m 555 top /usr/bin install: -o: No such file or director Can someone please tell me how to correctly replace single binaries in=20 the base system with debug versions? Thanks, -Harry --------------enig104FE01C6BCB0CF42491EF83 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAktZXVwACgkQLDqVQ9VXb8jyfQCcCAwjvHg0i6fmsD1TRr6e8NHC FzIAoMHvdPVBE9iEmwesLM/rn6kAizvH =q8GF -----END PGP SIGNATURE----- --------------enig104FE01C6BCB0CF42491EF83-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 08:18:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1FFF1065692; Fri, 22 Jan 2010 08:18:20 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.tele2.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 22CDA8FC1D; Fri, 22 Jan 2010 08:18:19 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=RYQgPGQ7BbsA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Dyl4VEldmJR9PoooqasA:9 a=LCxFG0357GHgqYZ0tgudE_1yVjgA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1197443918; Fri, 22 Jan 2010 09:18:17 +0100 From: Hans Petter Selasky To: Daichi GOTO Date: Fri, 22 Jan 2010 09:16:51 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <4B59318B.1020906@freebsd.org> In-Reply-To: <4B59318B.1020906@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001220916.51236.hselasky@c2i.net> Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 08:18:21 -0000 On Friday 22 January 2010 06:03:07 Daichi GOTO wrote: > Hi Hans, I have checked your work, and it works well, great :) > > This is a little tweak, > > --- /usr/local/etc/devd/webcamd.conf.orig 2010-01-22 13:19:20.371987293 > +0900 > +++ /usr/local/etc/devd/webcamd.conf 2010-01-22 13:52:00.286912793 +0900 > @@ -1,5 +1,5 @@ > attach 100 { > - device-name "ugen[0-9]+"; > + device-name "ugen[0-9.]+"; > match "intclass" "(0x0e|0xff)"; > action "/usr/local/etc/rc.d/webcamd start $device-name"; > }; > > > I want to know what does "intclass" mean. The webcamd(8) cannot > been engaged automatically by devd(8), because of not match of > "intclass". Hi, See: usbconfig -u 7 -a 2 dump_curr_config_desc | grep -i class To figure out what interface class your USB device is using. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 08:22:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1D0D1065698; Fri, 22 Jan 2010 08:22:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.tele2.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 035AE8FC14; Fri, 22 Jan 2010 08:22:46 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=9zKBo0zsyzYA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=2UwofreFRcBtx4jehzgA:9 a=6Q9vSM1yiG_MHxnB6qwA:7 a=xikmeNiRoirvha36V6SIMZGC_WcA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 979686147; Fri, 22 Jan 2010 09:22:44 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 22 Jan 2010 09:21:19 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <20100120064620.GJ46479@stlux503.dsto.defence.gov.au> <20100122045750.GF56085@stlux503.dsto.defence.gov.au> In-Reply-To: <20100122045750.GF56085@stlux503.dsto.defence.gov.au> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001220921.19252.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org, "Wilkinson, Alex" Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 08:22:47 -0000 On Friday 22 January 2010 05:57:50 Wilkinson, Alex wrote: > 0n Wed, Jan 20, 2010 at 02:46:20PM +0800, Wilkinson, Alex wrote: > > 0n Sun, Jan 10, 2010 at 02:37:37PM +0100, Hans Petter Selasky wrote: > > >During the last couple of days I've spent some time to finish my > > > webcam daemon. My webcam daemon is basically an application > > > which consists of userspace Video4Linux USB webcam drivers and > > > some uLinux glue code which links with libc, pthreads and > > > libusb. The webcamd talks to /dev/video_daemonX which is > > > provided by the video4bsd kernel module. There is full support > > > for mmap/read/write/open/close. poll is not supported. > > /usr/ports/multimedia/pwcview (PORTVERSION=1.4.1) crashes within 2-3mins of > use with the following: > > #sudo pwcview > Webcam set to: 320x240 (sif) at 5 fps > libv4lconvert: Error decompressing JPEG: fill_nbits error: need 3 more > bits libv4l2: error dequeuing buf: Device not configured > Error reading from webcam: Device not configured > > I rebuilt /usr/ports/multimedia/pwcview with symbolls and got the > following: > Hi, Maye that is a bug in /usr/ports/multimedia/libv4l which is external code, where the printout comes from. Maybe the code should be more fault tolerant. Try googling first. Can you dump the USB descriptors of your device? usbconfig -u X -a Y dump_device_desc dump_curr_config_desc --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 09:21:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11A52106566C; Fri, 22 Jan 2010 09:21:23 +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 CD4088FC0A; Fri, 22 Jan 2010 09:21:22 +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 AF1A312543B; Fri, 22 Jan 2010 18:21:21 +0900 (JST) Message-ID: <4B596E11.1010601@freebsd.org> Date: Fri, 22 Jan 2010 18:21:21 +0900 From: Daichi GOTO Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hans Petter Selasky References: <201001101437.37269.hselasky@c2i.net> <4B59318B.1020906@freebsd.org> <201001220916.51236.hselasky@c2i.net> In-Reply-To: <201001220916.51236.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 09:21:23 -0000 On 2010/01/22 17:16, Hans Petter Selasky wrote: > On Friday 22 January 2010 06:03:07 Daichi GOTO wrote: >> Hi Hans, I have checked your work, and it works well, great :) >> >> This is a little tweak, >> >> --- /usr/local/etc/devd/webcamd.conf.orig 2010-01-22 13:19:20.371987293 >> +0900 >> +++ /usr/local/etc/devd/webcamd.conf 2010-01-22 13:52:00.286912793 +0900 >> @@ -1,5 +1,5 @@ >> attach 100 { >> - device-name "ugen[0-9]+"; >> + device-name "ugen[0-9.]+"; >> match "intclass" "(0x0e|0xff)"; >> action "/usr/local/etc/rc.d/webcamd start $device-name"; >> }; >> >> >> I want to know what does "intclass" mean. The webcamd(8) cannot >> been engaged automatically by devd(8), because of not match of >> "intclass". > > Hi, Thank you quick response :) > See: > > usbconfig -u 7 -a 2 dump_curr_config_desc | grep -i class # usbconfig -u 7 -a 2 dump_curr_config_desc | grep -i class bInterfaceClass = 0x000e bInterfaceSubClass = 0x0001 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x000e bInterfaceSubClass = 0x0002 bInterfaceClass = 0x0001 bInterfaceSubClass = 0x0001 bInterfaceClass = 0x0001 bInterfaceSubClass = 0x0002 bInterfaceClass = 0x0001 bInterfaceSubClass = 0x0002 # > To figure out what interface class your USB device is using. > > --HPS > _______________________________________________ > 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" -- Daichi GOTO 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 10:23:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DA7610656D0; Fri, 22 Jan 2010 10:23:57 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id DD5AE8FC08; Fri, 22 Jan 2010 10:23:56 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o0MANtYW085682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 11:23:55 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B597CBB.5040900@omnilan.de> Date: Fri, 22 Jan 2010 11:23:55 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Alexander Motin References: <4B55D9D4.1000008@FreeBSD.org> In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C16E17E03DE133328835B8F" Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 10:23:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C16E17E03DE133328835B8F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 19.01.2010 17:12 (localtime): =2E.. > Patch can be found here: > http://people.freebsd.org/~mav/cam-ata.20100119.patch >=20 > Feedback as always welcome. Again, thanks a lot for your ongoing great work! The patch doesn't cleanly apply with vpo, but I don't use vpo so I=20 didn't care. Otherwise I couldn't find any problems. The system detects reinserted SATA drives on ICH9 fine. This was tested on a zfs backup server which went to the backbone=20 yesterday, so I can't physically remove any devices any more for testing.= =2E. But I had some questions about zfs raidz states. I think that isn't a=20 matter of atacam but if I removed one disk, zpool status still showed me = the ada3 device "online". After reinserting (and proper detection/initialisazion with cam, ada3=20 was present again) and zpool clean, it set the devicea as UNAVAIL sinve=20 I/O errors. I coudn't get the device into the pool again, no matter what I tried. Only rebooting the machine helped. Then I could clean and scrub. What are the needed steps to provide a reinsterted hard disk to geom?=20 With the latest patches I don't need to issue any reset/rescan comman,=20 right? So it's a zfs problem, right? My mistake in understanding? Thanks, -Harry --------------enig1C16E17E03DE133328835B8F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAktZfLsACgkQLDqVQ9VXb8h6ywCgleNs3+7wtinOt4D+b+XKJtQs I5EAoJ2VkP8NmHzUxEl4AOHN4Q+TcoTq =82Q7 -----END PGP SIGNATURE----- --------------enig1C16E17E03DE133328835B8F-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 10:33:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D7B6106568F for ; Fri, 22 Jan 2010 10:33:25 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id EB7CA8FC12 for ; Fri, 22 Jan 2010 10:33:24 +0000 (UTC) Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NYGpP-0006yW-ON; Fri, 22 Jan 2010 11:33:23 +0100 Received: from p57ae24a7.dip0.t-ipconnect.de ([87.174.36.167]:46935 helo=ernst.jennejohn.org) by 11.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NYGpP-0006TW-FX; Fri, 22 Jan 2010 11:33:23 +0100 Date: Fri, 22 Jan 2010 11:33:21 +0100 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20100122113321.7fc11ed6@ernst.jennejohn.org> In-Reply-To: <4B595D56.8030408@omnilan.de> References: <4B595D56.8030408@omnilan.de> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer Subject: Re: single (debug) binaries from base source tree install fails (/usr/bin/true) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 10:33:25 -0000 On Fri, 22 Jan 2010 09:09:58 +0100 Harald Schmalzbauer wrote: > I try to install a DEBUG_FLAGS=-g version of top since it core dumps on > my 8.0-RELEASE box. > Compiling works with warnings, but installing fails with superfluous > "/usr/bin/true" after install: > > install /usr/bin/true -o root -g wheel -m 555 top /usr/bin > install: -o: No such file or director > > Can someone please tell me how to correctly replace single binaries in > the base system with debug versions? > Simply overwrite it with the binary from /usr/obj//usr/src/usr.bin/top. top is not schg (see chflgas(1)), so this will work. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 10:45:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDE5A106566B for ; Fri, 22 Jan 2010 10:45:06 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4DCF38FC08 for ; Fri, 22 Jan 2010 10:45:05 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0MAj3Wa026532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 21:45:04 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o0MAiwnE032058; Fri, 22 Jan 2010 21:44:58 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o0MAiwUs032057; Fri, 22 Jan 2010 21:44:58 +1100 (EST) (envelope-from peter) Date: Fri, 22 Jan 2010 21:44:58 +1100 From: Peter Jeremy To: Tobias Rehbein Message-ID: <20100122104457.GB31243@server.vk2pj.dyndns.org> References: <20100121210523.GA1442@sushi.pseudo.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b5gNqxB1S1yM7hjW" Content-Disposition: inline In-Reply-To: <20100121210523.GA1442@sushi.pseudo.local> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: [patch] Let indent(1) handle widecharacter literals correctly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 10:45:06 -0000 --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jan-21 22:05:23 +0100, Tobias Rehbein wrote: >I am not subscribed to this list, so please answer me off-list or cc me. > >I noticed that indent(1) handles widecharacter literals (e.g. L'c' or L"st= ring") >incorrectly. indent(1)s parser treats the L-prefix and the quoted part as >seperate tokens. The result is: > > L'c' -> L 'c' > L"string" -> L "string" Thank you for noticing that. Can you please submit your patch as a PR so it doesn't get lost (send-pr(1)). >Of course this breaks any code using widecharacters. As I use indent(1) qu= ite >extensively I decided to fix this issue. As this is my first patch against= the >FreeBSD user land feel free to comment! I don't know indent(1) well enough to comment on the functional aspects but there are some style issues with the patch. Two lines are longer than 80 characters and the indenting doesn't align - see style(9). --=20 Peter Jeremy --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktZgakACgkQ/opHv/APuIfI8ACgo7h/ZIyVAjDIChfqVJK1ZDBb 8KEAn2T3QixIbxZpNgRPd9kGhXn9j+rT =2TJK -----END PGP SIGNATURE----- --b5gNqxB1S1yM7hjW-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 11:51:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAF7D1065676 for ; Fri, 22 Jan 2010 11:51:31 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9E0CF8FC1A for ; Fri, 22 Jan 2010 11:51:31 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 86DF11FFC22; Fri, 22 Jan 2010 11:51:30 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 56FCD844B0; Fri, 22 Jan 2010 12:51:30 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Harald Schmalzbauer References: <4B595D56.8030408@omnilan.de> Date: Fri, 22 Jan 2010 12:51:29 +0100 In-Reply-To: <4B595D56.8030408@omnilan.de> (Harald Schmalzbauer's message of "Fri, 22 Jan 2010 09:09:58 +0100") Message-ID: <86d412gxxa.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: single (debug) binaries from base source tree install fails (/usr/bin/true) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 11:51:31 -0000 Harald Schmalzbauer writes: > I try to install a DEBUG_FLAGS=3D-g version of top since it core dumps > on my 8.0-RELEASE box. How? > Compiling works with warnings, but installing fails with superfluous > "/usr/bin/true" after install: > > install /usr/bin/true -o root -g wheel -m 555 top /usr/bin > install: -o: No such file or director You screwed up somewhere... built in the wrong directory or something. The correct procedure is simply: % cd /usr/src/usr.bin/top % make clean % make DEBUG_FLAGS=3D-g % make install DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 12:09:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F11D106566B for ; Fri, 22 Jan 2010 12:09:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 6D5CF8FC17 for ; Fri, 22 Jan 2010 12:09:01 +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 o0MC8uI0058678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 14:08:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0MC8uac021615; Fri, 22 Jan 2010 14:08:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0MC8uGL021614; Fri, 22 Jan 2010 14:08:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Jan 2010 14:08:56 +0200 From: Kostik Belousov To: Dag-Erling Sm??rgrav Message-ID: <20100122120856.GD59590@deviant.kiev.zoral.com.ua> References: <4B595D56.8030408@omnilan.de> <86d412gxxa.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OAsA6xQjj2jRKPG2" Content-Disposition: inline In-Reply-To: <86d412gxxa.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Harald Schmalzbauer , freebsd-current@freebsd.org Subject: Re: single (debug) binaries from base source tree install fails (/usr/bin/true) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 12:09:03 -0000 --OAsA6xQjj2jRKPG2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 22, 2010 at 12:51:29PM +0100, Dag-Erling Sm??rgrav wrote: > Harald Schmalzbauer writes: > > I try to install a DEBUG_FLAGS=3D-g version of top since it core dumps > > on my 8.0-RELEASE box. >=20 > How? >=20 > > Compiling works with warnings, but installing fails with superfluous > > "/usr/bin/true" after install: > > > > install /usr/bin/true -o root -g wheel -m 555 top /usr/bin > > install: -o: No such file or director >=20 > You screwed up somewhere... built in the wrong directory or something. > The correct procedure is simply: >=20 > % cd /usr/src/usr.bin/top > % make clean > % make DEBUG_FLAGS=3D-g > % make install make install shall be done with DEBUG_FLAGS=3D-g too, otherwise installed binary will be stripped. --OAsA6xQjj2jRKPG2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktZlVgACgkQC3+MBN1Mb4hsiACfQSiGG4+aYeuy0mETVSqPygRc Ei4AoJbSO8L/5+OVs5L06Vi6+irVywpF =uleA -----END PGP SIGNATURE----- --OAsA6xQjj2jRKPG2-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 13:40:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF241065706; Fri, 22 Jan 2010 13:40:34 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id A5BA58FC2B; Fri, 22 Jan 2010 13:40:34 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o0MDeXKF011833; Fri, 22 Jan 2010 08:40:33 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201001221340.o0MDeXKF011833@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Jan 2010 08:40:32 -0500 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Jack Vogel Subject: em0 on H55 chipset problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 13:40:34 -0000 Not sure how easy it is to repeat, but running HEAD from yesterday causes the em0 do post a em0: Watchdog timeout -- resetting to the serial console on a new i3 system that we just got to test with. At that point, the box's network is no longer responding. It netboots off em0 so not sure if the hang after that is nfs not recovering or not, but it does not respond to network traffic at all. em0@pci0:0:25:0: class=0x020000 card=0x00368086 chip=0x10f08086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:0: class=0x0c0320 card=0x00368086 chip=0x3b3c8086 rev=0x06 hdr=0x00 Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0: Thu Jan 21 15:14:14 EST 2010 mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz (2926.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x20652 Stepping = 2 Features=0xbfebfbff Features2=0x98e3bd AMD Features=0x28100000 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 894119936 (852 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 4 ACPI Warning: 32/64X FACS address mismatch in FADT - 3762AE40/ 03762AD40, using 32 (20091214/tbfadt-586) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf100-0xf107 mem 0xfe000000-0xfe3fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) atapci0: port 0xf0f0-0xf0f7,0xf0e0-0xf0e3,0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0bf irq 18 at device 22.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 22.3 (no driver attached) em0: port 0xf040-0xf05f mem 0xfe400000-0xfe41ffff,0xfe428000-0xfe428fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:27:0e:09:5e:00 ehci0: mem 0xfe427000-0xfe4273ff irq 16 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.4 on pci0 pci2: on pcib2 ehci1: mem 0xfe426000-0xfe4263ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib3: at device 30.0 on pci0 pci3: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xf090-0xf097,0xf080-0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem 0xfe425000-0xfe4257ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI v1.30 controller with 6 3Gbps ports, PM not supported ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] ata7: on atapci1 ata7: [ITHREAD] ata8: on atapci1 ata8: [ITHREAD] ata9: on atapci1 ata9: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xcd000-0xcdfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ad0: 76319MB at ata4-master UDMA100 SATA 1.5Gb/s SMP: AP CPU #1 Launched! ugen0.1: at usbus0ugen1.1: at usbus1 uhub0: on usbus0 uhub1: on usbus1 Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 usbus0 uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 uhub2: 6 ports with 6 removable, self powered Root mount waiting for: usbus1 uhub3: 6 ports with 6 removable, self powered Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 16:48:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F5C1065698; Fri, 22 Jan 2010 16:48:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1618FC27; Fri, 22 Jan 2010 16:48:33 +0000 (UTC) Received: by iwn36 with SMTP id 36so1149347iwn.3 for ; Fri, 22 Jan 2010 08:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=DK58rBGwTxxNOLhQXY2UxQg82Y0UH6VIeDKsv7w29Cs=; b=LKiXIx8QGAChQH66QP8W6PMRfygAGj3HsgQAXKQlKwlZMUTQ0CpQaPP3utnkP250/f E+aokt2ZWtEExcIuln5mSNnJYAaaeD8Fsgfa79ZohOQmWFnfyHcjVR2zhCWvcGAT7I1O PZtlF2CFT5phNyBQdC9csAJLPcUvPxZZHqGqc= 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; b=lqF4L6GECoFxJ73xO8F89QoTV6Af3zQSVses2bc+MTKFEToem0OX8yk3X8lGZZ16jZ aDUhBZMBBN0oHljwuQ+X20IijT2tpHMHAFdL8az0jnh57kOagOiJuQbLYJIiXYT3pvXM UO+w+Jic0LBVHnJy4iTr4BYNTrT3idyPFOAk4= MIME-Version: 1.0 Received: by 10.231.149.16 with SMTP id r16mr1987199ibv.93.1264178913588; Fri, 22 Jan 2010 08:48:33 -0800 (PST) In-Reply-To: <4B597CBB.5040900@omnilan.de> References: <4B55D9D4.1000008@FreeBSD.org> <4B597CBB.5040900@omnilan.de> Date: Fri, 22 Jan 2010 08:48:33 -0800 Message-ID: From: Freddie Cash To: FreeBSD-Current , FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:48:34 -0000 On Fri, Jan 22, 2010 at 2:23 AM, Harald Schmalzbauer < h.schmalzbauer@omnilan.de> wrote: > Alexander Motin schrieb am 19.01.2010 17:12 (localtime): > ... > > Patch can be found here: >> http://people.freebsd.org/~mav/cam-ata.20100119.patch >> >> Feedback as always welcome. >> > > Again, thanks a lot for your ongoing great work! > The patch doesn't cleanly apply with vpo, but I don't use vpo so I didn't > care. > Otherwise I couldn't find any problems. > The system detects reinserted SATA drives on ICH9 fine. > > This was tested on a zfs backup server which went to the backbone > yesterday, so I can't physically remove any devices any more for testing... > > But I had some questions about zfs raidz states. I think that isn't a > matter of atacam but if I removed one disk, zpool status still showed me the > ada3 device "online". > After reinserting (and proper detection/initialisazion with cam, ada3 was > present again) and zpool clean, it set the devicea as UNAVAIL sinve I/O > errors. > I coudn't get the device into the pool again, no matter what I tried. > Only rebooting the machine helped. Then I could clean and scrub. > > What are the needed steps to provide a reinsterted hard disk to geom? With > the latest patches I don't need to issue any reset/rescan comman, right? > So it's a zfs problem, right? My mistake in understanding? > > In my testing of pulling drives at random (using a 3Ware 9550SXU or 9650SE controller), you have to "zpool offline " while the drive is unplugged, before you can re-insert the same disk or a different disk. Without doing that step, it's very hard to re-insert the same disk, or replace it with a new one, without rebooting. Took me a couple of reboots and drive replacements before I figured that one out. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 17:44:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 092CE106566C for ; Fri, 22 Jan 2010 17:44:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 538BE8FC0A for ; Fri, 22 Jan 2010 17:43:59 +0000 (UTC) Received: by ewy26 with SMTP id 26so430571ewy.3 for ; Fri, 22 Jan 2010 09:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zhoF8ZAU5VQV8fJ952wME3wkQmmRhBJRdZRM+kJLuh0=; b=U0hmCba0Uv9vqQNn9oToRznSMRjzz5s4NO3qwGYb9fI1uzJoWAv4vF94R5j72QpKn0 qbXaIYQMagUmm0WyXezl83WNtJsgCCLJVfB+BkQCJQ5a6IOAfF4UJftoipDGMF0xmdHV 3KthsEtL1HdfTXNIc0hS1vKJDjtMc7bAqHt5k= 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=lxzN5PbrZls0gnzQD3SnliuPWTOiHbvayw8dky8KzAUoWil+6H9BrayyEwWMEHdIw3 AXF9lrNoJiNo9IaOpnx6qlJr0WS0NAQ1+zIdHF80XmHkMM3h+W8UN2DTdOGhrv/J98xA Uh++CGHxHzpIR3MfQktcSt2LKUhBiL35GwZMg= MIME-Version: 1.0 Received: by 10.216.90.81 with SMTP id d59mr1334358wef.29.1264182238890; Fri, 22 Jan 2010 09:43:58 -0800 (PST) In-Reply-To: <201001221340.o0MDeXKF011833@lava.sentex.ca> References: <201001221340.o0MDeXKF011833@lava.sentex.ca> Date: Fri, 22 Jan 2010 09:43:58 -0800 Message-ID: <2a41acea1001220943i5a519390ud107240b30856094@mail.gmail.com> From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: em0 on H55 chipset problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:44:01 -0000 Hmmm, ok I'll look into it. Thanks Mike. Jack On Fri, Jan 22, 2010 at 5:40 AM, Mike Tancsa wrote: > Not sure how easy it is to repeat, but running HEAD from yesterday causes > the em0 do post a > em0: Watchdog timeout -- resetting > to the serial console on a new i3 system that we just got to test with. At > that point, the box's network is no longer responding. It netboots off em0 > so not sure if the hang after that is nfs not recovering or not, but it does > not respond to network traffic at all. > > em0@pci0:0:25:0: class=0x020000 card=0x00368086 chip=0x10f08086 > rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 13[e0] = PCI Advanced Features: FLR TP > ehci0@pci0:0:26:0: class=0x0c0320 card=0x00368086 chip=0x3b3c8086 > rev=0x06 hdr=0x00 > > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #0: Thu Jan 21 15:14:14 EST 2010 > mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz (2926.02-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x20652 Stepping = 2 > > Features=0xbfebfbff > > Features2=0x98e3bd > AMD Features=0x28100000 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 1073741824 (1024 MB) > avail memory = 894119936 (852 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 4 > ACPI Warning: 32/64X FACS address mismatch in FADT - 3762AE40/ > 03762AD40, using 32 (20091214/tbfadt-586) > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0xf100-0xf107 mem > 0xfe000000-0xfe3fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 > pci0: at device 22.0 (no driver attached) > atapci0: port > 0xf0f0-0xf0f7,0xf0e0-0xf0e3,0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0bf irq 18 > at device 22.2 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > pci0: at device 22.3 (no driver attached) > em0: port 0xf040-0xf05f mem > 0xfe400000-0xfe41ffff,0xfe428000-0xfe428fff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:27:0e:09:5e:00 > ehci0: mem 0xfe427000-0xfe4273ff irq > 16 at device 26.0 on pci0 > ehci0: [ITHREAD] > usbus0: EHCI version 1.0 > usbus0: on ehci0 > pci0: at device 27.0 (no driver attached) > pcib1: irq 17 at device 28.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.4 on pci0 > pci2: on pcib2 > ehci1: mem 0xfe426000-0xfe4263ff irq > 23 at device 29.0 on pci0 > ehci1: [ITHREAD] > usbus1: EHCI version 1.0 > usbus1: on ehci1 > pcib3: at device 30.0 on pci0 > pci3: on pcib3 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port > 0xf090-0xf097,0xf080-0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem > 0xfe425000-0xfe4257ff irq 19 at device 31.2 on pci0 > atapci1: [ITHREAD] > atapci1: AHCI v1.30 controller with 6 3Gbps ports, PM not supported > ata4: on atapci1 > ata4: [ITHREAD] > ata5: on atapci1 > ata5: [ITHREAD] > ata6: on atapci1 > ata6: [ITHREAD] > ata7: on atapci1 > ata7: [ITHREAD] > ata8: on atapci1 > ata8: [ITHREAD] > ata9: on atapci1 > ata9: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > p4tcc1: on cpu1 > pmtimer0 on isa0 > orm0: at iomem 0xcd000-0xcdfff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata0: [ITHREAD] > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > ata1: [ITHREAD] > Timecounters tick every 1.000 msec > IPsec: Initialized Security Association Processing. > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > ad0: 76319MB at ata4-master UDMA100 SATA 1.5Gb/s > SMP: AP CPU #1 Launched! > ugen0.1: at usbus0ugen1.1: at usbus1 > uhub0: > on usbus0 > uhub1: on usbus1 > Root mount waiting for: usbus1 usbus0 > Root mount waiting for: usbus1 usbus0 > uhub0: 3 ports with 3 removable, self powered > uhub1: 3 ports with 3 removable, self powered > Root mount waiting for: usbus1 usbus0 > ugen0.2: at usbus0 > uhub2: on > usbus0 > ugen1.2: at usbus1 > uhub3: on > usbus1 > uhub2: 6 ports with 6 removable, self powered > Root mount waiting for: usbus1 > uhub3: 6 ports with 6 removable, self powered > Trying to mount root from nfs: > NFS ROOT: 10.255.255.1:/usr/home/pxe9/ > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 18:34:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A0C51065670; Fri, 22 Jan 2010 18:34:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id B4DC68FC1A; Fri, 22 Jan 2010 18:34:33 +0000 (UTC) Received: by iwn7 with SMTP id 7so1197277iwn.7 for ; Fri, 22 Jan 2010 10:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=4yu3IosZGCCIgPv3rz0snaGgWWkc5VLfzSxNfuW1/5k=; b=QySIfm0zmq0tbjSUrchnCGWMoUI2EymH6lcgxp8H9HRVIFgNBvMHGBDl647JseJMoj kWcEIKup+glZ4QGKbak8nuDlVw8L/OBvvsoJNcM8o7/0m8WHwy3BO33VI8Dr09j2p42X irWPvKB/BSPi+VPjY7Z+GJVrIYZwjUCJGHBNY= 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; b=A5tGzjCBQkkJhbAOiwYgAfcsEtXjEDUMYo/fqqdU0m7ls1HOiYz3W+sCNk3cWmJi1s yhdb7za4zH/I7SpDcmaKiYW1kYOE4M1BpM+yGmtJMrIVKOwGKXlvYwt9+rTO0IzYqGsQ Jas9IVWZDn7cbEnwhox3WiuRVZJsZAvtpntzs= MIME-Version: 1.0 Received: by 10.231.170.14 with SMTP id b14mr5392347ibz.26.1264185271378; Fri, 22 Jan 2010 10:34:31 -0800 (PST) In-Reply-To: <4B59EE52.8050400@comcast.net> References: <4B55D9D4.1000008@FreeBSD.org> <4B597CBB.5040900@omnilan.de> <4B59EE52.8050400@comcast.net> Date: Fri, 22 Jan 2010 10:34:31 -0800 Message-ID: From: Freddie Cash To: FreeBSD-Current , FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 18:34:34 -0000 On Fri, Jan 22, 2010 at 10:28 AM, Steve Polyack wrote: > On 01/22/10 11:48, Freddie Cash wrote: > >> In my testing of pulling drives at random (using a 3Ware 9550SXU or 9650SE >>> >>> >> controller), you have to "zpool offline " while the drive >> is >> unplugged, before you can re-insert the same disk or a different disk. >> Without doing that step, it's very hard to re-insert the same disk, or >> replace it with a new one, without rebooting. >> >> Took me a couple of reboots and drive replacements before I figured that >> one >> out. :) >> >> > I think you can do it without the 'zpool offline ' command; > I may be wrong, but I believe you can use 'zpool replace' to accomplish > what you're trying to do. i.e. if you have a bad drive ada3, and take it > out, then replace it with a new disk, you can issue a 'zpool replace > /dev/ada3 /dev/ada3' (yes, the same device is specified twice). ZFS should > recognize that its a different disk and/or that it is lacking ZFS metadata > and begin to resilver the pool onto the new device. If you watch 'zfs > status' in the process you'll see something like: > > Yes, that does work ... but it's not nearly as reliable as doing the offline first. If you do things in the right order, drives can be replaced and resilvering started within minutes (our process takes a little less than 5 minutes, but the bulk of that is removing the dead drive from the caddy, and adding the new drive to the caddy). Do things in the wrong order, and it can take 15 minutes or more, and may require rebooting the system (as our manager discovered trying to replace a drive while I was away). :) Just because there are shortcuts available ... doesn't mean you should always take them. :D -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 19:49:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E7E0106566C for ; Fri, 22 Jan 2010 19:49:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id C785A8FC0A for ; Fri, 22 Jan 2010 19:49:28 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so381415eyd.9 for ; Fri, 22 Jan 2010 11:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gZtD9i1+0Ur5c/qOP+rtJ3DgzNxBt0fXu6mUmNHfU94=; b=wBptd6Bv7A2f5ckaO1DWpOv5B+pgUhg0gRad2R3bpXiBXVX6yQn1Aj8A19DWjHv/E3 itzhhUuxBgqQnOfYOL8MtKdUzo8AGz2RHUYGpM88CurqPpfDnHvdrevFjk/fK84HHcGa nmfF6e/BxFQ9LZyMPIjReVw9m9HYPCIfpy1Tc= 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=qR+VWkqr/BAsz4OPff9LBFUjKCUYW13CBh43bT1PufZl7q7GT138PzyYm3ANxKIXge TM2kdxh7yQryf36Q6NA8sUrI6lEQpn62Hxt2RS681wPGxxeFdEXYIwVvmD+JzBZo+dIN CKQrJ8JLjDYcsxFS+ZhiI9K9YrxnrttsZygiQ= MIME-Version: 1.0 Received: by 10.216.153.208 with SMTP id f58mr1306911wek.36.1264189766882; Fri, 22 Jan 2010 11:49:26 -0800 (PST) In-Reply-To: <201001221340.o0MDeXKF011833@lava.sentex.ca> References: <201001221340.o0MDeXKF011833@lava.sentex.ca> Date: Fri, 22 Jan 2010 11:49:26 -0800 Message-ID: <2a41acea1001221149t6afffd26vaa98a5a3ad6a350f@mail.gmail.com> From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: em0 on H55 chipset problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 19:49:29 -0000 Mike, can you tell me more details about the system, is this a laptop? Jack On Fri, Jan 22, 2010 at 5:40 AM, Mike Tancsa wrote: > Not sure how easy it is to repeat, but running HEAD from yesterday causes > the em0 do post a > em0: Watchdog timeout -- resetting > to the serial console on a new i3 system that we just got to test with. At > that point, the box's network is no longer responding. It netboots off em0 > so not sure if the hang after that is nfs not recovering or not, but it does > not respond to network traffic at all. > > em0@pci0:0:25:0: class=0x020000 card=0x00368086 chip=0x10f08086 > rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 13[e0] = PCI Advanced Features: FLR TP > ehci0@pci0:0:26:0: class=0x0c0320 card=0x00368086 chip=0x3b3c8086 > rev=0x06 hdr=0x00 > > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #0: Thu Jan 21 15:14:14 EST 2010 > mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz (2926.02-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x20652 Stepping = 2 > > Features=0xbfebfbff > > Features2=0x98e3bd > AMD Features=0x28100000 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 1073741824 (1024 MB) > avail memory = 894119936 (852 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 4 > ACPI Warning: 32/64X FACS address mismatch in FADT - 3762AE40/ > 03762AD40, using 32 (20091214/tbfadt-586) > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0xf100-0xf107 mem > 0xfe000000-0xfe3fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 > pci0: at device 22.0 (no driver attached) > atapci0: port > 0xf0f0-0xf0f7,0xf0e0-0xf0e3,0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0bf irq 18 > at device 22.2 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > pci0: at device 22.3 (no driver attached) > em0: port 0xf040-0xf05f mem > 0xfe400000-0xfe41ffff,0xfe428000-0xfe428fff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:27:0e:09:5e:00 > ehci0: mem 0xfe427000-0xfe4273ff irq > 16 at device 26.0 on pci0 > ehci0: [ITHREAD] > usbus0: EHCI version 1.0 > usbus0: on ehci0 > pci0: at device 27.0 (no driver attached) > pcib1: irq 17 at device 28.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.4 on pci0 > pci2: on pcib2 > ehci1: mem 0xfe426000-0xfe4263ff irq > 23 at device 29.0 on pci0 > ehci1: [ITHREAD] > usbus1: EHCI version 1.0 > usbus1: on ehci1 > pcib3: at device 30.0 on pci0 > pci3: on pcib3 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port > 0xf090-0xf097,0xf080-0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem > 0xfe425000-0xfe4257ff irq 19 at device 31.2 on pci0 > atapci1: [ITHREAD] > atapci1: AHCI v1.30 controller with 6 3Gbps ports, PM not supported > ata4: on atapci1 > ata4: [ITHREAD] > ata5: on atapci1 > ata5: [ITHREAD] > ata6: on atapci1 > ata6: [ITHREAD] > ata7: on atapci1 > ata7: [ITHREAD] > ata8: on atapci1 > ata8: [ITHREAD] > ata9: on atapci1 > ata9: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > p4tcc1: on cpu1 > pmtimer0 on isa0 > orm0: at iomem 0xcd000-0xcdfff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata0: [ITHREAD] > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > ata1: [ITHREAD] > Timecounters tick every 1.000 msec > IPsec: Initialized Security Association Processing. > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > ad0: 76319MB at ata4-master UDMA100 SATA 1.5Gb/s > SMP: AP CPU #1 Launched! > ugen0.1: at usbus0ugen1.1: at usbus1 > uhub0: > on usbus0 > uhub1: on usbus1 > Root mount waiting for: usbus1 usbus0 > Root mount waiting for: usbus1 usbus0 > uhub0: 3 ports with 3 removable, self powered > uhub1: 3 ports with 3 removable, self powered > Root mount waiting for: usbus1 usbus0 > ugen0.2: at usbus0 > uhub2: on > usbus0 > ugen1.2: at usbus1 > uhub3: on > usbus1 > uhub2: 6 ports with 6 removable, self powered > Root mount waiting for: usbus1 > uhub3: 6 ports with 6 removable, self powered > Trying to mount root from nfs: > NFS ROOT: 10.255.255.1:/usr/home/pxe9/ > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 19:51:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12B71065694 for ; Fri, 22 Jan 2010 19:51:16 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 799268FC17 for ; Fri, 22 Jan 2010 19:51:16 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o0MJpF0Z013766; Fri, 22 Jan 2010 14:51:15 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201001221951.o0MJpF0Z013766@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Jan 2010 14:51:14 -0500 To: Jack Vogel From: Mike Tancsa In-Reply-To: <2a41acea1001221149t6afffd26vaa98a5a3ad6a350f@mail.gmail.co m> References: <201001221340.o0MDeXKF011833@lava.sentex.ca> <2a41acea1001221149t6afffd26vaa98a5a3ad6a350f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: em0 on H55 chipset problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 19:51:16 -0000 At 02:49 PM 1/22/2010, Jack Vogel wrote: >Mike, can you tell me more details about the system, is this a laptop? Hi, Its an intel desktop MB DH55TC. Driver shows the following features 0(i3)% ifconfig em0: flags=8843 metric 0 mtu 1500 options=399b ether 00:27:0e:09:5e:00 inet 10.255.255.117 netmask 0xffffff00 broadcast 10.255.255.255 inet6 fe80::227:eff:fe09:5e00%em0 prefixlen 64 tentative scopeid 0x1 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active >Jack > > >On Fri, Jan 22, 2010 at 5:40 AM, Mike Tancsa ><mike@sentex.net> wrote: >Not sure how easy it is to repeat, but running HEAD from yesterday >causes the em0 do post a >em0: Watchdog timeout -- resetting >to the serial console on a new i3 system that we just got to test >with. At that point, the box's network is no longer responding. It >netboots off em0 so not sure if the hang after that is nfs not >recovering or not, but it does not respond to network traffic at all. > >em0@pci0:0:25:0: class=0x020000 card=0x00368086 >chip=0x10f08086 rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 13[e0] = PCI Advanced Features: FLR TP >ehci0@pci0:0:26:0: class=0x0c0320 card=0x00368086 >chip=0x3b3c8086 rev=0x06 hdr=0x00 > >Copyright (c) 1992-2010 The FreeBSD Project. >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. >FreeBSD is a registered trademark of The FreeBSD Foundation. >FreeBSD 9.0-CURRENT #0: Thu Jan 21 15:14:14 EST 2010 > mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 >Timecounter "i8254" frequency 1193182 Hz quality 0 >CPU: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz (2926.02-MHz >686-class CPU) > Origin = "GenuineIntel" Id = 0x20652 Stepping = 2 > >Features=0xbfebfbff > >Features2=0x98e3bd > AMD Features=0x28100000 > AMD Features2=0x1 > TSC: P-state invariant >real memory = 1073741824 (1024 MB) >avail memory = 894119936 (852 MB) >ACPI APIC Table: >FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 4 >ACPI Warning: 32/64X FACS address mismatch in FADT - >3762AE40/ 03762AD40, using 32 (20091214/tbfadt-586) >ioapic0 irqs 0-23 on motherboard >kbd1 at kbdmux0 >cryptosoft0: on motherboard >acpi0: on motherboard >acpi0: [ITHREAD] >acpi0: Power Button (fixed) >Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >Timecounter "HPET" frequency 14318180 Hz quality 900 >pcib0: port 0xcf8-0xcff on acpi0 >pci0: on pcib0 >vgapci0: port 0xf100-0xf107 mem >0xfe000000-0xfe3fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 >pci0: at device 22.0 (no driver attached) >atapci0: port >0xf0f0-0xf0f7,0xf0e0-0xf0e3,0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0bf > irq 18 at device 22.2 on pci0 >atapci0: [ITHREAD] >ata2: on atapci0 >ata2: [ITHREAD] >ata3: on atapci0 >ata3: [ITHREAD] >pci0: at device 22.3 (no driver attached) >em0: port >0xf040-0xf05f mem 0xfe400000-0xfe41ffff,0xfe428000-0xfe428fff irq 20 >at device 25.0 on pci0 >em0: Using MSI interrupt >em0: [FILTER] >em0: Ethernet address: 00:27:0e:09:5e:00 >ehci0: mem >0xfe427000-0xfe4273ff irq 16 at device 26.0 on pci0 >ehci0: [ITHREAD] >usbus0: EHCI version 1.0 >usbus0: on ehci0 >pci0: at device 27.0 (no driver attached) >pcib1: irq 17 at device 28.0 on pci0 >pci1: on pcib1 >pcib2: irq 17 at device 28.4 on pci0 >pci2: on pcib2 >ehci1: mem >0xfe426000-0xfe4263ff irq 23 at device 29.0 on pci0 >ehci1: [ITHREAD] >usbus1: EHCI version 1.0 >usbus1: on ehci1 >pcib3: at device 30.0 on pci0 >pci3: on pcib3 >isab0: at device 31.0 on pci0 >isa0: on isab0 >atapci1: port >0xf090-0xf097,0xf080-0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f > mem 0xfe425000-0xfe4257ff irq 19 at device 31.2 on pci0 >atapci1: [ITHREAD] >atapci1: AHCI v1.30 controller with 6 3Gbps ports, PM not supported >ata4: on atapci1 >ata4: [ITHREAD] >ata5: on atapci1 >ata5: [ITHREAD] >ata6: on atapci1 >ata6: [ITHREAD] >ata7: on atapci1 >ata7: [ITHREAD] >ata8: on atapci1 >ata8: [ITHREAD] >ata9: on atapci1 >ata9: [ITHREAD] >pci0: at device 31.3 (no driver attached) >acpi_button0: on acpi0 >atrtc0: port 0x70-0x71 irq 8 on acpi0 >atkbdc0: port 0x60,0x64 irq 1 on acpi0 >atkbd0: irq 1 on atkbdc0 >kbd0 at atkbd0 >atkbd0: [GIANT-LOCKED] >atkbd0: [ITHREAD] >uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >uart0: [FILTER] >uart0: console (9600,n,8,1) >cpu0: on acpi0 >est0: on cpu0 >p4tcc0: on cpu0 >cpu1: on acpi0 >est1: on cpu1 >p4tcc1: on cpu1 >pmtimer0 on isa0 >orm0: at iomem 0xcd000-0xcdfff pnpid ORM0000 on isa0 >sc0: at flags 0x100 on isa0 >sc0: VGA <16 virtual consoles, flags=0x300> >vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 >ata0: [ITHREAD] >ata1 at port 0x170-0x177,0x376 irq 15 on isa0 >ata1: [ITHREAD] >Timecounters tick every 1.000 msec >IPsec: Initialized Security Association Processing. >usbus0: 480Mbps High Speed USB v2.0 >usbus1: 480Mbps High Speed USB v2.0 >ad0: 76319MB at ata4-master UDMA100 SATA 1.5Gb/s >SMP: AP CPU #1 Launched! >ugen0.1: at usbus0ugen1.1: at usbus1 >uhub0: > on usbus0 >uhub1: on usbus1 >Root mount waiting for: usbus1 usbus0 >Root mount waiting for: usbus1 usbus0 >uhub0: 3 ports with 3 removable, self powered >uhub1: 3 ports with 3 removable, self powered >Root mount waiting for: usbus1 usbus0 >ugen0.2: at usbus0 >uhub2: 2> on usbus0 >ugen1.2: at usbus1 >uhub3: 2> on usbus1 >uhub2: 6 ports with 6 removable, self powered >Root mount waiting for: usbus1 >uhub3: 6 ports with 6 removable, self powered >Trying to mount root from nfs: >NFS ROOT: 10.255.255.1:/usr/home/pxe9/ > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex >Communications, >mike@sentex.net >Providing Internet since >1994 www.sentex.net >Cambridge, Ontario >Canada www.sentex.net/mike > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 21:18:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39020106568B; Fri, 22 Jan 2010 21:18:14 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 786C88FC1F; Fri, 22 Jan 2010 21:18:13 +0000 (UTC) Received: by bwz5 with SMTP id 5so1494797bwz.3 for ; Fri, 22 Jan 2010 13:18:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.16.194 with SMTP id p2mr1952836bka.32.1264195092177; Fri, 22 Jan 2010 13:18:12 -0800 (PST) In-Reply-To: <4B597CBB.5040900@omnilan.de> References: <4B55D9D4.1000008@FreeBSD.org> <4B597CBB.5040900@omnilan.de> Date: Fri, 22 Jan 2010 22:18:11 +0100 Message-ID: <367b2c981001221318q6a59913av14cceca4a2dab132@mail.gmail.com> From: Olivier Smedts To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 21:18:14 -0000 2010/1/22 Harald Schmalzbauer : > Alexander Motin schrieb am 19.01.2010 17:12 (localtime): > ... >> >> Patch can be found here: >> http://people.freebsd.org/~mav/cam-ata.20100119.patch >> >> Feedback as always welcome. > > Again, thanks a lot for your ongoing great work! > The patch doesn't cleanly apply with vpo, but I don't use vpo so I didn't > care. Since r202799 it applies cleanly to 8-STABLE. > Otherwise I couldn't find any problems. > The system detects reinserted SATA drives on ICH9 fine. > > This was tested on a zfs backup server which went to the backbone yesterday, > so I can't physically remove any devices any more for testing... > > But I had some questions about zfs raidz states. I think that isn't a matter > of atacam but if I removed one disk, zpool status still showed me the ada3 > device "online". > After reinserting (and proper detection/initialisazion with cam, ada3 was > present again) and zpool clean, it set the devicea as UNAVAIL sinve I/O > errors. > I coudn't get the device into the pool again, no matter what I tried. > Only rebooting the machine helped. Then I could clean and scrub. > > What are the needed steps to provide a reinsterted hard disk to geom? With > the latest patches I don't need to issue any reset/rescan comman, right? > So it's a zfs problem, right? My mistake in understanding? > > Thanks, > > -Harry > > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 18:49:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E1E010656AD for ; Fri, 22 Jan 2010 18:49:29 +0000 (UTC) (envelope-from tobias.rehbein@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 1678E8FC17 for ; Fri, 22 Jan 2010 18:49:28 +0000 (UTC) Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate03.web.de (Postfix) with ESMTP id B5EF813C75A48 for ; Fri, 22 Jan 2010 19:49:27 +0100 (CET) Received: from [95.88.224.31] (helo=sushi.pseudo.local) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1NYOZR-0008Id-00 for freebsd-current@freebsd.org; Fri, 22 Jan 2010 19:49:25 +0100 Received: from sushi.pseudo.local (localhost [127.0.0.1]) by sushi.pseudo.local (8.14.3/8.14.3) with ESMTP id o0MInOHK013917 for ; Fri, 22 Jan 2010 19:49:25 +0100 (CET) (envelope-from tobi@sushi.pseudo.local) Received: (from tobi@localhost) by sushi.pseudo.local (8.14.3/8.14.3/Submit) id o0MInOiM013916 for freebsd-current@freebsd.org; Fri, 22 Jan 2010 19:49:24 +0100 (CET) (envelope-from tobi) Date: Fri, 22 Jan 2010 19:49:24 +0100 From: Tobias Rehbein To: freebsd-current@freebsd.org Message-ID: <20100122184924.GA12855@sushi.pseudo.local> References: <20100121210523.GA1442@sushi.pseudo.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100121210523.GA1442@sushi.pseudo.local> User-Agent: Mutt/1.4.2.3i Sender: tobias.rehbein@web.de X-Sender: tobias.rehbein@web.de X-Provags-ID: V01U2FsdGVkX18w9/4GqCP2l6pAk27MXBQd39JSsfvdxVQgeX38 duTBVE9NBl8tMgzOToZqRY428bMdzsbgYDMFuitgXjGIV8DMIT 7ctXYa0+1+t5sAm3VbWg== X-Mailman-Approved-At: Fri, 22 Jan 2010 21:37:32 +0000 Subject: Re: [patch] Let indent(1) handle widecharacter literals correctly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 18:49:29 -0000 Hi. I submitted the patch via send-pr[1]. Nonetheless I am still interested in comments. Regards Tobias [1]: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/143090 -- Tobias Rehbein PGP key: 4F2AE314 server: keys.gnupg.net fingerprint: ECDA F300 1B6E 9B87 8524 8663 E8B6 3138 4F2A E314 From owner-freebsd-current@FreeBSD.ORG Fri Jan 22 22:04:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC86410656A7 for ; Fri, 22 Jan 2010 22:04:01 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 1B31F8FC2A for ; Fri, 22 Jan 2010 22:04:00 +0000 (UTC) Received: (qmail invoked by alias); 22 Jan 2010 22:03:59 -0000 Received: from e181209228.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [85.181.209.228] by mail.gmx.com (mp-eu005) with SMTP; 22 Jan 2010 23:03:59 +0100 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX1/oOpInOl7oop7uIxSnKx/mRADCcXsSBOuSuKpFA9 stYED/DlCBfalw Received: by myhost.mydomain.de (Postfix, from userid 1001) id 8A2E773CE; Fri, 22 Jan 2010 23:03:58 +0100 (CET) From: Christof Schulze To: freebsd-current@freebsd.org Date: Fri, 22 Jan 2010 23:03:56 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <201001220155.34784.christof.schulze@gmx.com> <201001221442.07624.doconnor@gsoft.com.au> In-Reply-To: <201001221442.07624.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1678885.CAcSxGIDeI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001222303.57515.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68000000000000005 Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 22:04:01 -0000 --nextPart1678885.CAcSxGIDeI Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Freitag 22 Januar 2010 05:11:56 schrieb Daniel O'Connor: > On Fri, 22 Jan 2010, Christof Schulze wrote: > > kldload video4bsd > > webcamd > > webcamd -d ugen0.2 -i 0 -v 0 > > > > but I get > > Cannot open /dev/video_daemonX. Did you kldload video4bsd? >=20 > Did you run webcamd as root? >=20 yes - not sure what I did differently but pwcview shows a picture. Sorry fo= r=20 the noise. Interestingly skype does not seem to detect the webcam even though it claim= s=20 to support v4l viele Gr=FC=DFe Christof =2D-=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --nextPart1678885.CAcSxGIDeI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktaIM0ACgkQpZfyPAmdZJnxigCfROqDs1eORQm3OnTGR4vdISAM k4oAnihRakEDAqWN8ElcxQG6NAG4yIfH =PD0x -----END PGP SIGNATURE----- --nextPart1678885.CAcSxGIDeI-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 02:30:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5A8A106568B for ; Sat, 23 Jan 2010 02:30:56 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 59A108FC19 for ; Sat, 23 Jan 2010 02:30:55 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-195.lns6.adl6.internode.on.net [121.45.156.195]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0N2UrZI024629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 23 Jan 2010 13:00:54 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sat, 23 Jan 2010 13:00:40 +1030 User-Agent: KMail/1.9.10 References: <201001101437.37269.hselasky@c2i.net> <201001221442.07624.doconnor@gsoft.com.au> <201001222303.57515.christof.schulze@gmx.com> In-Reply-To: <201001222303.57515.christof.schulze@gmx.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart40783417.QhvNcLvNER"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001231300.49077.doconnor@gsoft.com.au> X-Spam-Score: -1.671 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Christof Schulze Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 02:30:57 -0000 --nextPart40783417.QhvNcLvNER Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 23 Jan 2010, Christof Schulze wrote: > yes - not sure what I did differently but pwcview shows a picture. > Sorry for the noise. OK, well it works :) > Interestingly skype does not seem to detect the webcam even though it > claims to support v4l Skype doesn't work for me either, it lists /dev/video0 but nothing=20 happens when I click test and it doesn't work in a video call (the=20 recipient sees nothing). I tred LD_PRELOAD'ing the v4l1 compat shim library but no change in=20 behaviour. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart40783417.QhvNcLvNER Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLWl9Z5ZPcIHs/zowRAua3AJwOgU0NwYYwVL67XhShcgnPzBRp6wCfY/ov YuhNNVnJwEpTIZYaql8I57Q= =7dGw -----END PGP SIGNATURE----- --nextPart40783417.QhvNcLvNER-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 07:52:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A690E106566B; Sat, 23 Jan 2010 07:52:47 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0EC8FC14; Sat, 23 Jan 2010 07:52:46 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so277750fgg.13 for ; Fri, 22 Jan 2010 23:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ttUny5J7GVt8IKEKrkakKGmq4Q6mWosQ15v9M3VpJBo=; b=qBUHpDJh/hAQXIjDmlqhkUZZYqjkb1I4S1bHFjjBoW4NJR2izqBy16LvhcW7BIxJJL 5WIN7LAgh9Jq4gIfbUV2xYQoPv7MCLEKADoXlLEn4rOuDSNItAFjrJ6v1m544vowWV7z ZxpZmlJC9jm8YE9/WdFtcZFFdPFPt6uVgeoJQ= 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=TPLigsAEV70HMJ9n8Y062ywE6kQWmBvdX33cOzniGA+wts+6EKKeGfYhG2byrZyUcd FqMvzyldnt1xuzEtubGdGtEqs6f8tKp8YtS6ipIsDHfrZ23xEbmiJyDjGP/3uYr7lAOG IG4Wc4o8BHfOBsIqv/RdGS5PLrNjsELUlgdXw= MIME-Version: 1.0 Received: by 10.86.239.1 with SMTP id m1mr1340157fgh.57.1264233165760; Fri, 22 Jan 2010 23:52:45 -0800 (PST) In-Reply-To: References: <20100120162326.GD50360@dan.emsphone.com> <20100120235024.GE50360@dan.emsphone.com> Date: Sat, 23 Jan 2010 18:22:45 +1030 Message-ID: From: Matt Thyer To: Daniel Eischen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Dan Nelson , current@freebsd.org Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 07:52:47 -0000 On 21 January 2010 11:56, Daniel Eischen wrote: > On Thu, 21 Jan 2010, Matt Thyer wrote: > > 2010/1/21 Dan Nelson >> >> >>> Since the ln command didn't print an error message itself, it's unlikely >>> to >>> have caused the build to fail. Try searching for "***" or ":" instead. >>> >> >> >> [...] >> >> You are correct. I missed the error the first time. It is: >> >> make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop >> *** Error code 2 >> > > It happens with -j8 also (amd64, UFS). > > -- > DE > Binary search shows the the failure to be between r202210 (working) and r202222 (fails). Now checking out r202216 for testing. From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 10:33:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B1DB1065696 for ; Sat, 23 Jan 2010 10:33:13 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0538D8FC1D for ; Sat, 23 Jan 2010 10:33:12 +0000 (UTC) Received: by fxm10 with SMTP id 10so247670fxm.14 for ; Sat, 23 Jan 2010 02:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=H2530PhJPVjsq9ILSQ73SbOeb591vZ6wzXhDKPD+1a8=; b=BEe7HH31Dh+vG0ZRIE1/lS2BwONf6c3gndCDXiC/wN9GRzy8hqp9K+ZtFCDy9PHQe6 wR2xSWl48nZnyJGQZbBMnxubzzO/SgNBCpCH0KeQJVhfos/g5PZKxoeZekdaCwMVdh6E M0+64zTgF0A0faLZfa/e53l/ca7w809fut3h4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; b=elsGrSKjElfsBbAy/nr2q6G5YIBPkyOQeTXFrR8LLSQMMqNKOsTtlZDECLRDyKd0Jj ifv/pvCoKGjjLRpe2DOeRFWS+XMZa7jYhofpveykjMKMPm2CWg22N0UFNyCy/mBmAA68 g1LLRz6cCjKXYyjbUO3tx27hCOsGqnu73m4T0= Received: by 10.223.77.129 with SMTP id g1mr3881736fak.11.1264242791776; Sat, 23 Jan 2010 02:33:11 -0800 (PST) Received: from dragon.dg ([41.216.197.17]) by mx.google.com with ESMTPS id 15sm1744952fxm.6.2010.01.23.02.33.09 (version=SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 02:33:11 -0800 (PST) From: David Naylor Organization: Private To: freebsd-current@freebsd.org Date: Sat, 23 Jan 2010 12:33:14 +0200 User-Agent: KMail/1.12.3 (FreeBSD/8.0-STABLE; KDE/4.3.3; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1831293.5iA22QSUzj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001231233.18832.naylor.b.david@gmail.com> Subject: "tinderbox" using stacked unionfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 10:33:13 -0000 --nextPart1831293.5iA22QSUzj Content-Type: multipart/mixed; boundary="Boundary-01=_qBtWLCFxlRT0g7U" Content-Transfer-Encoding: 7bit --Boundary-01=_qBtWLCFxlRT0g7U Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I have been experimenting with using unionfs to build ports in a "tinderbox= "=20 environment. This avoids having to remove and extract files for the build = of=20 each port and it allows the discovery of installed/modified files by the po= rt. =20 Please see attached for a (updated) shell script that handles all the "heav= y=20 lifting" of building ports. Of importance is LOCALBASE and BUILDDIR. If y= ou=20 want to override LOCALBASE please use `env` as the script needs to know abo= ut=20 it. BUILDDIR (/usr/build by default) is where the script stores everything= =20 (including PKG_DBDIR). =20 # env LOCALBASE=3D/tmp/local BUILDDIR=3D/tmp/build ./ports-union-builder.sh Will install x11/xorg without affecting already installed systems. =20 CURRENT STATUS: - *** Currently kernel stack size is too small and the above will trigger = a=20 stack overflow. Recompiling a kernel with ``options KSTACK_PAGES=3D32'' wi= ll=20 alleviate that problem. =20 - Currently there is a build problem that affects eggdbus/polkit (possibly= =20 others) thus preventing x11/xorg from being built. I will investigate the= =20 cause (help welcome). =20 - I highly recommend running this in a chroot - NO WARRANTY, SLIPPERY WHEN WET, EATS CHILDREN. =20 Since the script doesn't complete a full build I am unable to compare the=20 build speeds (thus the overhead of unionfs) but here are some partial resul= ts=20 (with FORCE_MAKE_JOBS and quad core): # time make -C /usr/ports/x11/xorg install clean 2185.180u 1066.927s 38:12.27 141.8% 4123+1745k 5185+1890io 51638pf+0w # time ./ports-union-builder.sh Port /usr/ports/devel/eggdbus failed to build Port /usr/ports/x11/xorg failed due to dependency /usr/ports/devel/eggdbus 1065.356u 862.073s 25:03.88 128.1% 4602+1840k 4582+57338io 18327pf+0w Regards, David --Boundary-01=_qBtWLCFxlRT0g7U Content-Type: text/plain; charset="ISO-8859-1"; name="ports-union-builder.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ports-union-builder.txt" #!/bin/sh BUILDDIR=${BUILDDIR:-/usr/build} LOCALBASE=${LOCALBASE:-/usr/local} PORTSDIR=${PORTSDIR:-/usr/ports} PORT_DBDIR=${PKG_DBDIR:-$BUILDDIR/db_ports} PKG_DBDIR=${PKG_DBDIR:-$BUILDDIR/db_pkg} PACKAGES=${PACKAGES:-$BUILDDIR/packages} MAKE="env LOCALBASE=$LOCALBASE PORTSDIR=$PORTSDIR PORT_DBDIR=$PORT_DBDIR PKG_DBDIR=$PKG_DBDIR PACKAGES=$PACKAGES make" set -e mkdir -p $BUILDDIR $LOCALBASE $PKG_DBDIR $PACKAGES [ -n "$(kldstat -v | grep unionfs)" ] || kldload unionfs port2name() { echo $1 | sed 's|[/.-]|_|g' } port2pkg() { local pkg_name= local port= port=$1; shift eval pkg_name=PKG$(port2name $port) eval pkg=\$$pkg_name if [ -z "$pkg" ] then pkg=$($MAKE -C $port -V PKGNAME) eval $pkg_name=$pkg fi } depends() { local depend= local depends_name= local _deps= local name= local port= local type type=$1 port=$2 eval depends_name=DEPEND_${type}_$(port2name $port) eval deps=\"\$$depends_name\" if [ -z "$deps" ] then echo "Getting dependancies for $port" > /dev/stderr if [ "$type" = "build" ] then depend_list="$($MAKE -C $port -V EXTRACT_DEPENDS -V BUILD_DEPENDS -V LIB_DEPENDS -V RUN_DEPENDS)" else depend_list="$($MAKE -C $port -V LIB_DEPENDS -V RUN_DEPENDS)" fi for depend in $depend_list do name=$(echo $depend | cut -f 2 -d ':') depends run $name _deps="$_deps $deps $name" done deps=$(for depend in $_deps do echo $depend done | sort -u) depends_name=$depends_name eval $depends_name=\"$deps \" fi } build() { local _deps= local dep= local port= port=$1 depends build $port _deps="$deps" for dep in $_deps do port2pkg $dep if [ ! -d $BUILDDIR/$pkg ] then if ! build $dep then echo "Port $port failed due to dependancy $dep" > /dev/stderr return 255 fi fi done echo "Building port $port..." for pkg in $_deps do port2pkg $pkg mount -t unionfs -r -o noatime $BUILDDIR/$pkg $LOCALBASE done port2pkg $port mkdir -p $BUILDDIR/$pkg mount -t unionfs -o noatime $BUILDDIR/$pkg $LOCALBASE set +e trap "true" INT TERM EXIT $MAKE -C $port clean build install package -DNO_DEPENDS -DBATCH status=$? trap - INT TERM EXIT set -e [ $status -ne 0 -a -n "$NO_CLEANUP" ] || umount $LOCALBASE for pkg in $(echo $_deps | sort -r) do [ $status -ne 0 -a -n "$NO_CLEANUP" ] || umount $LOCALBASE done if [ $status -ne 0 ] then echo "Port $port failed to build" > /dev/stderr port2pkg $port rm -rf $BUILDDIR/$pkg || (chflags -R 0 $BUILDDIR/$pkg; rm -rf $BUILDDIR/$pkg) else $MAKE -C $port clean fi return $status } build /usr/ports/x11/xorg --Boundary-01=_qBtWLCFxlRT0g7U-- --nextPart1831293.5iA22QSUzj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAkta0G4ACgkQUaaFgP9pFrItTQCdGKDQlAJ09H9EoUzJXuvQd6Nt wAUAnA2xKq05+IzRRQ+uYLD9LxJfKB9S =NlYM -----END PGP SIGNATURE----- --nextPart1831293.5iA22QSUzj-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 12:10:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5DB5106566B; Sat, 23 Jan 2010 12:10:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AD56D8FC1E; Sat, 23 Jan 2010 12:10:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0NCAZDO026923; Sat, 23 Jan 2010 07:10:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0NCAZn1026916; Sat, 23 Jan 2010 12:10:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Jan 2010 12:10:35 GMT Message-Id: <201001231210.o0NCAZn1026916@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 12:10:36 -0000 TB --- 2010-01-23 11:05:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-23 11:05:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-01-23 11:05:00 - cleaning the object tree TB --- 2010-01-23 11:05:21 - cvsupping the source tree TB --- 2010-01-23 11:05:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-01-23 11:05:59 - building world TB --- 2010-01-23 11:05:59 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 11:05:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 11:05:59 - TARGET=pc98 TB --- 2010-01-23 11:05:59 - TARGET_ARCH=i386 TB --- 2010-01-23 11:05:59 - TZ=UTC TB --- 2010-01-23 11:05:59 - __MAKE_CONF=/dev/null TB --- 2010-01-23 11:05:59 - cd /src TB --- 2010-01-23 11:05:59 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 23 11:05:59 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 23 12:05:02 UTC 2010 TB --- 2010-01-23 12:05:02 - generating LINT kernel config TB --- 2010-01-23 12:05:02 - cd /src/sys/pc98/conf TB --- 2010-01-23 12:05:02 - /usr/bin/make -B LINT TB --- 2010-01-23 12:05:02 - building LINT kernel TB --- 2010-01-23 12:05:02 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 12:05:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 12:05:02 - TARGET=pc98 TB --- 2010-01-23 12:05:02 - TARGET_ARCH=i386 TB --- 2010-01-23 12:05:02 - TZ=UTC TB --- 2010-01-23 12:05:02 - __MAKE_CONF=/dev/null TB --- 2010-01-23 12:05:02 - cd /src TB --- 2010-01-23 12:05:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 23 12:05:03 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ie/if_ie.c:1155: warning: 'ee16_read_eeprom' defined but not used /src/sys/dev/ie/if_ie.c:1097: warning: 'find_ie_mem_size' defined but not used cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ie/if_ie_isa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/ibfoo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/pcii.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/tnt4882.c /src/sys/dev/ieee488/tnt4882.c: In function 'tnt_attach': /src/sys/dev/ieee488/tnt4882.c:306: error: 'struct upd7210' has no member named 'reg_offset' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-23 12:10:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-23 12:10:35 - ERROR: failed to build lint kernel TB --- 2010-01-23 12:10:35 - 2869.50 user 691.18 system 3935.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 12:12:20 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A2D4106566B; Sat, 23 Jan 2010 12:12:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id ECD548FC12; Sat, 23 Jan 2010 12:12:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0NCCJYX042190; Sat, 23 Jan 2010 07:12:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0NCCJPZ042189; Sat, 23 Jan 2010 12:12:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Jan 2010 12:12:19 GMT Message-Id: <201001231212.o0NCCJPZ042189@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 12:12:20 -0000 TB --- 2010-01-23 11:05:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-23 11:05:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-01-23 11:05:00 - cleaning the object tree TB --- 2010-01-23 11:05:23 - cvsupping the source tree TB --- 2010-01-23 11:05:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-01-23 11:05:59 - building world TB --- 2010-01-23 11:05:59 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 11:05:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 11:05:59 - TARGET=i386 TB --- 2010-01-23 11:05:59 - TARGET_ARCH=i386 TB --- 2010-01-23 11:05:59 - TZ=UTC TB --- 2010-01-23 11:05:59 - __MAKE_CONF=/dev/null TB --- 2010-01-23 11:05:59 - cd /src TB --- 2010-01-23 11:05:59 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 23 11:05:59 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 23 12:05:34 UTC 2010 TB --- 2010-01-23 12:05:34 - generating LINT kernel config TB --- 2010-01-23 12:05:34 - cd /src/sys/i386/conf TB --- 2010-01-23 12:05:34 - /usr/bin/make -B LINT TB --- 2010-01-23 12:05:34 - building LINT kernel TB --- 2010-01-23 12:05:34 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 12:05:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 12:05:34 - TARGET=i386 TB --- 2010-01-23 12:05:34 - TARGET_ARCH=i386 TB --- 2010-01-23 12:05:34 - TZ=UTC TB --- 2010-01-23 12:05:34 - __MAKE_CONF=/dev/null TB --- 2010-01-23 12:05:34 - cd /src TB --- 2010-01-23 12:05:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 23 12:05:34 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ie/if_ie.c:1155: warning: 'ee16_read_eeprom' defined but not used /src/sys/dev/ie/if_ie.c:1097: warning: 'find_ie_mem_size' defined but not used cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ie/if_ie_isa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/ibfoo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/pcii.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/tnt4882.c /src/sys/dev/ieee488/tnt4882.c: In function 'tnt_attach': /src/sys/dev/ieee488/tnt4882.c:306: error: 'struct upd7210' has no member named 'reg_offset' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-23 12:12:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-23 12:12:19 - ERROR: failed to build lint kernel TB --- 2010-01-23 12:12:19 - 2958.45 user 683.40 system 4038.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 12:38:10 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B0891065676; Sat, 23 Jan 2010 12:38:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 232D58FC0A; Sat, 23 Jan 2010 12:38:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0NCc9KF067936; Sat, 23 Jan 2010 07:38:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0NCc9MZ067924; Sat, 23 Jan 2010 12:38:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Jan 2010 12:38:09 GMT Message-Id: <201001231238.o0NCc9MZ067924@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 12:38:10 -0000 TB --- 2010-01-23 11:05:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-23 11:05:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-01-23 11:05:00 - cleaning the object tree TB --- 2010-01-23 11:05:34 - cvsupping the source tree TB --- 2010-01-23 11:05:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-01-23 11:06:05 - building world TB --- 2010-01-23 11:06:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 11:06:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 11:06:05 - TARGET=amd64 TB --- 2010-01-23 11:06:05 - TARGET_ARCH=amd64 TB --- 2010-01-23 11:06:05 - TZ=UTC TB --- 2010-01-23 11:06:05 - __MAKE_CONF=/dev/null TB --- 2010-01-23 11:06:05 - cd /src TB --- 2010-01-23 11:06:05 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 23 11:06:05 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jan 23 12:32:03 UTC 2010 TB --- 2010-01-23 12:32:03 - generating LINT kernel config TB --- 2010-01-23 12:32:03 - cd /src/sys/amd64/conf TB --- 2010-01-23 12:32:03 - /usr/bin/make -B LINT TB --- 2010-01-23 12:32:03 - building LINT kernel TB --- 2010-01-23 12:32:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 12:32:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 12:32:03 - TARGET=amd64 TB --- 2010-01-23 12:32:03 - TARGET_ARCH=amd64 TB --- 2010-01-23 12:32:03 - TZ=UTC TB --- 2010-01-23 12:32:03 - __MAKE_CONF=/dev/null TB --- 2010-01-23 12:32:03 - cd /src TB --- 2010-01-23 12:32:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 23 12:32:03 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ida/ida.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ida/ida_disk.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ida/ida_pci.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/ibfoo.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/pcii.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/tnt4882.c /src/sys/dev/ieee488/tnt4882.c: In function 'tnt_attach': /src/sys/dev/ieee488/tnt4882.c:306: error: 'struct upd7210' has no member named 'reg_offset' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-23 12:38:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-23 12:38:09 - ERROR: failed to build lint kernel TB --- 2010-01-23 12:38:09 - 4106.97 user 956.88 system 5588.87 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 13:03:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07786106566B; Sat, 23 Jan 2010 13:03:36 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 613438FC17; Sat, 23 Jan 2010 13:03:34 +0000 (UTC) Received: by fxm26 with SMTP id 26so2028891fxm.13 for ; Sat, 23 Jan 2010 05:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=C5QSTRT0Lqq16kTO5e3uwnxgBxNe8lxuB6rDNW3JDZA=; b=icr0cg0ckk9xwktvJagxVoFLow4yMylKUEPOxhzrfme8tunDSn8t4RbdJDJSp/2id6 fXb12eJ2ZzeJ95wSC1MjTeE9/+/NIrKkrg6gO91oBFhvfIbTOTaYk2xXeX7VbYDXW6Y8 wQYUp+/0Ifw054ITafXWRHjHcy2xdoyMbnT7c= 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=dqVl7gpEACYwq/grr4XXKdJXWWF5+JKyNliJfRU+X6xs1bLXhc7rGJx5HSTrPziefm J18ZAZ9+BdronrICD/l0G7J5B7K2pe2HfbjtCRWa+Tde+Ey0GzdZqBKmXh/UgYsQ98Xu OS306lGocTMb3eWvnK4vkJHMIcYG9BCyr5IPw= MIME-Version: 1.0 Received: by 10.86.125.32 with SMTP id x32mr3382362fgc.63.1264251814194; Sat, 23 Jan 2010 05:03:34 -0800 (PST) In-Reply-To: References: <20100120162326.GD50360@dan.emsphone.com> <20100120235024.GE50360@dan.emsphone.com> Date: Sat, 23 Jan 2010 23:33:34 +1030 Message-ID: From: Matt Thyer To: Daniel Eischen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Dan Nelson , current@freebsd.org Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 13:03:36 -0000 On 23 January 2010 18:22, Matt Thyer wrote: > On 21 January 2010 11:56, Daniel Eischen wrote: > >> On Thu, 21 Jan 2010, Matt Thyer wrote: >> >> 2010/1/21 Dan Nelson >>> >>> >>>> Since the ln command didn't print an error message itself, it's unlikely >>>> to >>>> have caused the build to fail. Try searching for "***" or ":" instead. >>>> >>> >>> >>> [...] >>> >>> You are correct. I missed the error the first time. It is: >>> >>> make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop >>> *** Error code 2 >>> >> >> It happens with -j8 also (amd64, UFS). >> >> -- >> DE >> > > Binary search shows the the failure to be between r202210 (working) and > r202222 (fails). > Now checking out r202216 for testing. > r202214 works with make -j24 buildworld. r202215 fails make -j24 buildworld as does every revision since then: make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop *** Error code 2 The svn update from r202214 to r202215 is: % svn update --revision r202215 http://svn.freebsd.org/base/head /usr/src Skipped 'http://svn.freebsd.org/base/head' D /usr/src/lib/libulog/ulog_setutxfile.3 D /usr/src/lib/libulog/ulog_util.c D /usr/src/lib/libulog/ulog_internal.h D /usr/src/lib/libulog/ulog_pututxline.c D /usr/src/lib/libulog/ulog_getutxent.3 D /usr/src/lib/libulog/ulog_getutxent.c U /usr/src/lib/libulog/ulog_login.3 U /usr/src/lib/libulog/ulog_login.c U /usr/src/lib/libulog/Symbol.map U /usr/src/lib/libulog/utempter.c U /usr/src/lib/libulog/ulog.h U /usr/src/lib/libulog/utempter_add_record.3 U /usr/src/lib/libulog/Makefile U /usr/src/lib/libulog/ulog_login_pseudo.c U /usr/src/ObsoleteFiles.inc Updated to revision 202215. I can only assume there is a problem with "/usr/src/lib/libulog/Makefile". From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 13:17:49 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE7E2106566B; Sat, 23 Jan 2010 13:17:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 869908FC15; Sat, 23 Jan 2010 13:17:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0NDHmtx068115; Sat, 23 Jan 2010 08:17:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0NDHmRe068114; Sat, 23 Jan 2010 13:17:48 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Jan 2010 13:17:48 GMT Message-Id: <201001231317.o0NDHmRe068114@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 13:17:49 -0000 TB --- 2010-01-23 11:54:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-23 11:54:34 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-01-23 11:54:34 - cleaning the object tree TB --- 2010-01-23 11:54:54 - cvsupping the source tree TB --- 2010-01-23 11:54:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-01-23 11:55:19 - building world TB --- 2010-01-23 11:55:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 11:55:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 11:55:19 - TARGET=ia64 TB --- 2010-01-23 11:55:19 - TARGET_ARCH=ia64 TB --- 2010-01-23 11:55:19 - TZ=UTC TB --- 2010-01-23 11:55:19 - __MAKE_CONF=/dev/null TB --- 2010-01-23 11:55:19 - cd /src TB --- 2010-01-23 11:55:19 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 23 11:55:19 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 23 13:11:15 UTC 2010 TB --- 2010-01-23 13:11:15 - generating LINT kernel config TB --- 2010-01-23 13:11:15 - cd /src/sys/ia64/conf TB --- 2010-01-23 13:11:15 - /usr/bin/make -B LINT TB --- 2010-01-23 13:11:15 - building LINT kernel TB --- 2010-01-23 13:11:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 13:11:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 13:11:15 - TARGET=ia64 TB --- 2010-01-23 13:11:15 - TARGET_ARCH=ia64 TB --- 2010-01-23 13:11:15 - TZ=UTC TB --- 2010-01-23 13:11:15 - __MAKE_CONF=/dev/null TB --- 2010-01-23 13:11:15 - cd /src TB --- 2010-01-23 13:11:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 23 13:11:15 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ida/ida.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ida/ida_disk.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ida/ida_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ieee488/ibfoo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ieee488/pcii.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ieee488/tnt4882.c /src/sys/dev/ieee488/tnt4882.c: In function 'tnt_attach': /src/sys/dev/ieee488/tnt4882.c:306: error: 'struct upd7210' has no member named 'reg_offset' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-23 13:17:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-23 13:17:48 - ERROR: failed to build lint kernel TB --- 2010-01-23 13:17:48 - 3959.10 user 666.48 system 4993.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 13:39:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAD61106566B; Sat, 23 Jan 2010 13:39:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5D38FC16; Sat, 23 Jan 2010 13:39:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0NDdtvG087213; Sat, 23 Jan 2010 08:39:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0NDdtIK087198; Sat, 23 Jan 2010 13:39:55 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Jan 2010 13:39:55 GMT Message-Id: <201001231339.o0NDdtIK087198@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 13:39:56 -0000 TB --- 2010-01-23 12:38:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-23 12:38:09 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-01-23 12:38:09 - cleaning the object tree TB --- 2010-01-23 12:38:25 - cvsupping the source tree TB --- 2010-01-23 12:38:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-01-23 12:38:49 - building world TB --- 2010-01-23 12:38:49 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 12:38:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 12:38:49 - TARGET=sparc64 TB --- 2010-01-23 12:38:49 - TARGET_ARCH=sparc64 TB --- 2010-01-23 12:38:49 - TZ=UTC TB --- 2010-01-23 12:38:49 - __MAKE_CONF=/dev/null TB --- 2010-01-23 12:38:49 - cd /src TB --- 2010-01-23 12:38:49 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 23 12:38:49 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 23 13:35:17 UTC 2010 TB --- 2010-01-23 13:35:17 - generating LINT kernel config TB --- 2010-01-23 13:35:17 - cd /src/sys/sparc64/conf TB --- 2010-01-23 13:35:17 - /usr/bin/make -B LINT TB --- 2010-01-23 13:35:17 - building LINT kernel TB --- 2010-01-23 13:35:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 13:35:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 13:35:17 - TARGET=sparc64 TB --- 2010-01-23 13:35:17 - TARGET_ARCH=sparc64 TB --- 2010-01-23 13:35:17 - TZ=UTC TB --- 2010-01-23 13:35:17 - __MAKE_CONF=/dev/null TB --- 2010-01-23 13:35:17 - cd /src TB --- 2010-01-23 13:35:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 23 13:35:17 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ida/ida.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ida/ida_disk.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ida/ida_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ieee488/ibfoo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ieee488/pcii.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ieee488/tnt4882.c /src/sys/dev/ieee488/tnt4882.c: In function 'tnt_attach': /src/sys/dev/ieee488/tnt4882.c:306: error: 'struct upd7210' has no member named 'reg_offset' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-23 13:39:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-23 13:39:55 - ERROR: failed to build lint kernel TB --- 2010-01-23 13:39:55 - 2794.66 user 600.92 system 3706.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 14:10:48 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36DD01065670; Sat, 23 Jan 2010 14:10:48 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id B79398FC13; Sat, 23 Jan 2010 14:10:47 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 05D041E0076C; Sat, 23 Jan 2010 15:10:44 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o0NE7lqh002621; Sat, 23 Jan 2010 15:07:47 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o0NE7l8j002620; Sat, 23 Jan 2010 15:07:47 +0100 (CET) (envelope-from nox) Date: Sat, 23 Jan 2010 15:07:47 +0100 (CET) From: Juergen Lock Message-Id: <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> To: mav@FreeBSD.org X-Newsgroups: local.list.freebsd.current In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> Organization: home Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 14:10:48 -0000 In article <4B55D9D4.1000008@FreeBSD.org> you write: >Hi. Hi! > >I've made a patch, that should solve set of problems of CAM ATA and CAM >generally. I would like to ask for testing and feedback. > >What patch does: >- It unifies bus reset/probe sequence. Whenever bus attached at boot or >later, CAM will automatically reset and scan it. It allows to remove >duplicate code from many drivers. >- Any bus, attached before CAM completed it's boot-time initialization, >will equally join to the process, delaying boot if needed. >- New kern.cam.boot_delay loader tunable should help controllers that >are still unable to register their buses in time (such as slow USB/ >PCCard/ CardBus devices). >- To allow synchronization between different CAM levels, concept of >requests priorities was extended. Priorities now split between several >"run levels". Device can be freezed at specified level, allowing higher >priority requests to pass. For example, no payload requests allowed, >until PMP driver enable port. ATA XPT negotiate transfer parameters, >periph driver configure caching and so on. >- Frozen requests are no more counted by request allocation scheduler. >It fixes deadlocks, when frozen low priority payload requests occupying >slots, required by higher levels to manage theit execution. >- Two last changes were holding proper ATA reinitialization and error >recovery implementation. Now it is done: SATA controllers and Port >Multipliers now implement automatic hot-plug and should correctly >recover from timeouts and bus resets. > >Patch can be found here: >http://people.freebsd.org/~mav/cam-ata.20100119.patch > >Feedback as always welcome. Ok, applied this to stable/8, and the good news is the box still seems to run (using ahci(4) on an sb700 controller and siis(4) on a SiI3132 pcie card, altho atm there's only an optical drive on that one.) But what this still doesn't fix is the broken `test unit ready' command on ada devices, which also makes things like `cdrecord -scanbus' hang the bus. :( (A few days ago I also got a hang after wanting to try out xfburn, I suspect for the same reason...) Here is my earlier report: http://docs.freebsd.org/cgi/mid.cgi?20090817163144.GA2991 Oh and I also still use this patch to scsi_cd.c to be able to read discs that fail the `read toc' command, like bluray (data) discs. PR s here: http://www.freebsd.org/cgi/query-pr.cgi?pr=138789 Index: src/sys/cam/scsi/scsi_cd.c =================================================================== RCS file: /home/scvs/src/sys/cam/scsi/scsi_cd.c,v retrieving revision 1.107.2.6 diff -u -p -u -r1.107.2.6 scsi_cd.c --- src/sys/cam/scsi/scsi_cd.c 25 Dec 2009 08:06:35 -0000 1.107.2.6 +++ src/sys/cam/scsi/scsi_cd.c 23 Jan 2010 13:29:19 -0000 @@ -2874,11 +2874,17 @@ cdcheckmedia(struct cam_periph *periph) } softc->flags |= CD_FLAG_VALID_TOC; + +bailout: softc->disk->d_sectorsize = softc->params.blksize; softc->disk->d_mediasize = (off_t)softc->params.blksize * softc->params.disksize; +/* if bailout: + * is here read requests will fail when the toc cant be read although + * CD_FLAG_VALID_MEDIA is set. + */ /* * We unconditionally (re)set the blocksize each time the From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 17:46:24 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FAF0106566C; Sat, 23 Jan 2010 17:46:24 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout6.freenet.de (mout6.freenet.de [IPv6:2001:748:100:40::2:8]) by mx1.freebsd.org (Postfix) with ESMTP id 96B8A8FC16; Sat, 23 Jan 2010 17:46:23 +0000 (UTC) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout6.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NYk3y-0000aK-SJ; Sat, 23 Jan 2010 18:46:22 +0100 Received: from p57ae1388.dip0.t-ipconnect.de ([87.174.19.136]:36163 helo=ernst.jennejohn.org) by 10.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NYk3x-0005Do-Lr; Sat, 23 Jan 2010 18:46:22 +0100 Date: Sat, 23 Jan 2010 18:46:19 +0100 From: Gary Jennejohn To: Juergen Lock Message-ID: <20100123184619.257203d9@ernst.jennejohn.org> In-Reply-To: <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mav@FreeBSD.org, FreeBSD-Current , Stable , FreeBSD Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 17:46:24 -0000 On Sat, 23 Jan 2010 15:07:47 +0100 (CET) Juergen Lock wrote: > But what > this still doesn't fix is the broken `test unit ready' command on ada > devices, which also makes things like `cdrecord -scanbus' hang the bus. :( > (A few days ago I also got a hang after wanting to try out xfburn, > I suspect for the same reason...) > > Here is my earlier report: > http://docs.freebsd.org/cgi/mid.cgi?20090817163144.GA2991 > I started seeing a problem a few days ago with one of my DVD drives (a burner at cd0) under 9-current, which makes it impossible to use it even to simply read a DVD. Here the (rather strange IMO) output in dmesg: cd0: Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, or bus device reset occurred cd1 at ata0 bus 0 scbus6 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed I haven't the foggiest why cd0 behaves diffrently from cd1, which is a vanilla DVD drive and just works. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 19:18:59 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9448106566C; Sat, 23 Jan 2010 19:18:59 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 51F9F8FC18; Sat, 23 Jan 2010 19:18:59 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id o0NJInsZ060299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jan 2010 04:18:53 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 24 Jan 2010 04:18:48 +0900 Message-ID: From: Hajimu UMEMOTO To: Gabor Kovesdan In-Reply-To: <4B56CACF.50508@FreeBSD.org> References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Sun_Jan_24_04:18:48_2010-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 24 Jan 2010 04:18:54 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: Kostik Belousov , attilio@FreeBSD.org, current@FreeBSD.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 19:18:59 -0000 --Multipart_Sun_Jan_24_04:18:48_2010-1 Content-Type: text/plain; charset=ISO-2022-JP-2 Hi, >>>>> On Wed, 20 Jan 2010 10:20:15 +0100 >>>>> Gabor Kovesdan said: gabor> El 2010. 01. 19. 22:20, Kostik Belousov escribi$(D+Q(B: > Hi, > r189765 enabled NLS support for libc. Now, any strerror(3) call causes > 4 (!) failing stat(2) calls. I think this is untolerable. > > Catopen() does not cache the catalog descriptor, at least for libc, > at least for the case where the open failed. > gabor> Hi Kostik, gabor> thank you for pointing this out. I'll check the code to see how we could gabor> add a caching for the failing catalogs. I'll post the patch here when gabor> I'm done. The gai_strerror(3) has same issue. How about the attached patch in this mail? Sincerely, --Multipart_Sun_Jan_24_04:18:48_2010-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="strerror-lock.diff" Content-Transfer-Encoding: 7bit Index: lib/libc/include/libc_private.h diff -u lib/libc/include/libc_private.h.orig lib/libc/include/libc_private.h --- lib/libc/include/libc_private.h.orig 2010-01-01 02:14:04.000000000 +0900 +++ lib/libc/include/libc_private.h 2010-01-24 03:39:20.480514921 +0900 @@ -211,4 +211,10 @@ /* execve() with PATH processing to implement posix_spawnp() */ int _execvpe(const char *, char * const *, char * const *); +#ifdef NLS +extern char *__cat_gets(int, int, const char *); +extern void __cat_lock(void); +extern void __cat_unlock(void); +#endif + #endif /* _LIBC_PRIVATE_H_ */ Index: lib/libc/net/gai_strerror.c diff -u -p lib/libc/net/gai_strerror.c.orig lib/libc/net/gai_strerror.c --- lib/libc/net/gai_strerror.c.orig 2009-11-23 02:05:46.000000000 +0900 +++ lib/libc/net/gai_strerror.c 2010-01-24 03:30:15.086490501 +0900 @@ -41,6 +41,7 @@ __FBSDID("$FreeBSD: src/lib/libc/net/gai #include "reentrant.h" #endif #include "un-namespace.h" +#include "libc_private.h" /* Entries EAI_ADDRFAMILY (1) and EAI_NODATA (7) are obsoleted, but left */ /* for backward compatibility with userland code prior to 2553bis-02 */ @@ -79,7 +80,6 @@ const char * gai_strerror(int ecode) { #if defined(NLS) - nl_catd catd; char *buf; if (thr_main() != 0) @@ -98,17 +98,17 @@ gai_strerror(int ecode) } } - catd = catopen("libc", NL_CAT_LOCALE); + __cat_lock(); if (ecode > 0 && ecode < EAI_MAX) - strlcpy(buf, catgets(catd, 3, ecode, ai_errlist[ecode]), + strlcpy(buf, __cat_gets(3, ecode, ai_errlist[ecode]), sizeof(gai_buf)); else if (ecode == 0) - strlcpy(buf, catgets(catd, 3, NL_MSGMAX - 1, "Success"), + strlcpy(buf, __cat_gets(3, NL_MSGMAX - 1, "Success"), sizeof(gai_buf)); else - strlcpy(buf, catgets(catd, 3, NL_MSGMAX, "Unknown error"), + strlcpy(buf, __cat_gets(3, NL_MSGMAX, "Unknown error"), sizeof(gai_buf)); - catclose(catd); + __cat_unlock(); return buf; thr_err: Index: lib/libc/string/strerror.c diff -u -p lib/libc/string/strerror.c.orig lib/libc/string/strerror.c --- lib/libc/string/strerror.c.orig 2009-08-03 17:13:06.000000000 +0900 +++ lib/libc/string/strerror.c 2010-01-24 04:11:37.168662523 +0900 @@ -33,14 +33,16 @@ static char sccsid[] = "@(#)strerror.c 8 #include __FBSDID("$FreeBSD: src/lib/libc/string/strerror.c,v 1.16.10.1 2009/08/03 08:13:06 kensmith Exp $"); -#if defined(NLS) -#include -#endif - +#include "namespace.h" #include #include #include #include +#if defined(NLS) +#include +#include "reentrant.h" +#endif +#include "un-namespace.h" #define UPREFIX "Unknown error" @@ -52,6 +54,31 @@ __FBSDID("$FreeBSD: src/lib/libc/string/ */ #define EBUFSIZE (20 + 2 + sizeof(UPREFIX)) +#if defined(NLS) +static mutex_t catd_mutex = MUTEX_INITIALIZER; +static nl_catd catd; + +char * +__cat_gets(int set_id, int msg_id, const char *s) +{ + if (catd == NULL) + catd = catopen("libc", NL_CAT_LOCALE); + return (catgets(catd, set_id, msg_id, s)); +} + +void +__cat_lock(void) +{ + mutex_lock(&catd_mutex); +} + +void +__cat_unlock(void) +{ + mutex_unlock(&catd_mutex); +} +#endif + /* * Doing this by hand instead of linking with stdio(3) avoids bloat for * statically linked binaries. @@ -83,14 +110,14 @@ strerror_r(int errnum, char *strerrbuf, int retval = 0; #if defined(NLS) int saved_errno = errno; - nl_catd catd; - catd = catopen("libc", NL_CAT_LOCALE); + + __cat_lock(); #endif if (errnum < 1 || errnum >= sys_nerr) { errstr(errnum, #if defined(NLS) - catgets(catd, 1, 0xffff, UPREFIX), + __cat_gets(1, 0xffff, UPREFIX), #else UPREFIX, #endif @@ -99,7 +126,7 @@ strerror_r(int errnum, char *strerrbuf, } else { if (strlcpy(strerrbuf, #if defined(NLS) - catgets(catd, 1, errnum, sys_errlist[errnum]), + __cat_gets(1, errnum, sys_errlist[errnum]), #else sys_errlist[errnum], #endif @@ -108,7 +135,7 @@ strerror_r(int errnum, char *strerrbuf, } #if defined(NLS) - catclose(catd); + __cat_unlock(); errno = saved_errno; #endif --Multipart_Sun_Jan_24_04:18:48_2010-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Sun_Jan_24_04:18:48_2010-1-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 19:34:50 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0CF4106566B; Sat, 23 Jan 2010 19:34:49 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 496D38FC08; Sat, 23 Jan 2010 19:34:49 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 423B414DA362; Sat, 23 Jan 2010 20:34:47 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BbaZG5d1-Xom; Sat, 23 Jan 2010 20:34:37 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 44D2E14D9B2E; Sat, 23 Jan 2010 20:34:37 +0100 (CET) Message-ID: <4B5B4F4B.3030201@FreeBSD.org> Date: Sat, 23 Jan 2010 20:34:35 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000102010404010207030707" Cc: Kostik Belousov , attilio@FreeBSD.org, current@FreeBSD.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 19:34:50 -0000 This is a multi-part message in MIME format. --------------000102010404010207030707 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 2010. 01. 23. 20:18, Hajimu UMEMOTO escribió: > The gai_strerror(3) has same issue. How about the attached patch in > this mail? > I have a fix for msgcat.c to optimalize catalog handling. As I'm not an src committer, delphij@ is helping me in reviewing and approving my patches. I've sent the attached patch to him today and I'm waiting for his response now. This patch caches the failing and the succesful catopen() calls in a thread-safe way and in the latter case it counts references to cached catalog. Still, I consider it a good idea to have a static catalog descriptor in strerror.3 and use that instead of always opening and closing the catalog. Regards, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org --------------000102010404010207030707 Content-Type: text/plain; name="nls-caching.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nls-caching.diff" SW5kZXg6IG5scy9tc2djYXQuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIG5scy9tc2djYXQuYwko cmV2aXNp8246IDIwMjY1OCkNCisrKyBubHMvbXNnY2F0LmMJKGNvcGlhIGRlIHRyYWJham8p DQpAQCAtMzksNiArMzksNyBAQA0KICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiAjaW5jbHVk ZSA8c3lzL3N0YXQuaD4NCiAjaW5jbHVkZSA8c3lzL21tYW4uaD4NCisjaW5jbHVkZSA8c3lz L3F1ZXVlLmg+DQogDQogI2luY2x1ZGUgPGFycGEvaW5ldC5oPgkJLyogZm9yIG50b2hsKCkg Ki8NCiANCkBAIC00Nyw2ICs0OCw3IEBADQogI2luY2x1ZGUgPGxpbWl0cy5oPg0KICNpbmNs dWRlIDxsb2NhbGUuaD4NCiAjaW5jbHVkZSA8bmxfdHlwZXMuaD4NCisjaW5jbHVkZSA8cHRo cmVhZC5oPg0KICNpbmNsdWRlIDxzdGRpby5oPg0KICNpbmNsdWRlIDxzdGRsaWIuaD4NCiAj aW5jbHVkZSA8c3RyaW5nLmg+DQpAQCAtNTcsMjYgKzU5LDc0IEBADQogDQogI2RlZmluZSBf REVGQVVMVF9OTFNfUEFUSCAiL3Vzci9zaGFyZS9ubHMvJUwvJU4uY2F0Oi91c3Ivc2hhcmUv bmxzLyVOLyVMOi91c3IvbG9jYWwvc2hhcmUvbmxzLyVMLyVOLmNhdDovdXNyL2xvY2FsL3No YXJlL25scy8lTi8lTCINCiANCisjZGVmaW5lIFJMT0NLKGZhaWwpCXsgaWYgKF9wdGhyZWFk X3J3bG9ja19yZGxvY2soJnJ3bG9jaykgIT0gMCkgcmV0dXJuIChmYWlsKTsgfQ0KKyNkZWZp bmUgV0xPQ0soZmFpbCkJeyBpZiAoX3B0aHJlYWRfcndsb2NrX3dybG9jaygmcndsb2NrKSAh PSAwKSByZXR1cm4gKGZhaWwpOyB9DQorI2RlZmluZSBVTkxPQ0soZmFpbCkJeyBpZiAoX3B0 aHJlYWRfcndsb2NrX3VubG9jaygmcndsb2NrKSAhPSAwKSByZXR1cm4gKGZhaWwpOyB9DQor DQogI2RlZmluZQlOTEVSUgkJKChubF9jYXRkKSAtMSkNCiAjZGVmaW5lIE5MUkVURVJSKGVy cmMpICB7IGVycm5vID0gZXJyYzsgcmV0dXJuIChOTEVSUik7IH0NCisjZGVmaW5lIFNBVkVG QUlMKG4sIGUpCXsgV0xPQ0soTkxFUlIpOyBcDQorCQkJICBucCA9IG1hbGxvYyhzaXplb2Yo c3RydWN0IGNhdGVudHJ5KSk7IFwNCisJCQkgIGlmIChucCAhPSBOVUxMKSB7IFwNCisJCQkg IAlucC0+bmFtZSA9IHN0cmR1cChuKTsgXA0KKwkJCQlucC0+Y2F0ZXJybm8gPSBlOyBcDQor CQkJICAJU0xJU1RfSU5TRVJUX0hFQUQoJmZsaXN0LCBucCwgbGlzdCk7IFwNCisJCQkgIH0g XA0KKwkJCSAgVU5MT0NLKE5MRVJSKTsgXA0KKwkJCX0NCiANCi1zdGF0aWMgbmxfY2F0ZCBs b2FkX21zZ2NhdChjb25zdCBjaGFyICopOw0KK3N0YXRpYyBubF9jYXRkIGxvYWRfbXNnY2F0 KGNvbnN0IGNoYXIgKiwgY29uc3QgY2hhciAqKTsNCiANCitzdGF0aWMgcHRocmVhZF9yd2xv Y2tfdAkJIHJ3bG9jazsNCisNCitzdHJ1Y3QgY2F0ZW50cnkgew0KKwlTTElTVF9FTlRSWShj YXRlbnRyeSkJIGxpc3Q7DQorCWNoYXIJCQkqbmFtZTsNCisJY2hhcgkJCSpwYXRoOw0KKwlp bnQJCQkgY2F0ZXJybm87DQorCW5sX2NhdGQJCQkgY2F0ZDsNCisJaW50CQkJIHJlZmNvdW50 Ow0KK307DQorDQorU0xJU1RfSEVBRChsaXN0aGVhZCwgY2F0ZW50cnkpIGZsaXN0ID0NCisg ICAgU0xJU1RfSEVBRF9JTklUSUFMSVpFUihmbGlzdCk7DQorDQogbmxfY2F0ZA0KIGNhdG9w ZW4oY29uc3QgY2hhciAqbmFtZSwgaW50IHR5cGUpDQogew0KLQlpbnQgICAgICAgICAgICAg c3BjbGVmdCwgc2F2ZXJyOw0KLQljaGFyICAgICAgICAgICAgcGF0aFtQQVRIX01BWF07DQot CWNoYXIgICAgICAgICAgICAqbmxzcGF0aCwgKmxhbmcsICpiYXNlLCAqY3B0ciwgKnBhdGhQ LCAqdG1wcHRyOw0KLQljaGFyICAgICAgICAgICAgKmNwdHIxLCAqcGxhbmcsICpwdGVyLCAq cGNvZGU7DQotCXN0cnVjdCBzdGF0ICAgICBzYnVmOw0KKwlpbnQJCSBzcGNsZWZ0LCBzYXZl cnI7DQorCWNoYXIJCSBwYXRoW1BBVEhfTUFYXTsNCisJY2hhcgkJKm5sc3BhdGgsICpsYW5n LCAqYmFzZSwgKmNwdHIsICpwYXRoUCwgKnRtcHB0cjsNCisJY2hhcgkJKmNwdHIxLCAqcGxh bmcsICpwdGVyLCAqcGNvZGU7DQorCXN0cnVjdCBzdGF0CSBzYnVmOw0KKwlzdHJ1Y3QgY2F0 ZW50cnkJKm5wOw0KIA0KIAlpZiAobmFtZSA9PSBOVUxMIHx8ICpuYW1lID09ICdcMCcpDQog CQlOTFJFVEVSUihFSU5WQUwpOw0KIA0KKwlpZiAoKHJ3bG9jayA9PSAocHRocmVhZF9yd2xv Y2tfdCkwKSAmJg0KKwkgICAgKF9wdGhyZWFkX3J3bG9ja19pbml0KCZyd2xvY2ssIE5VTEwp ICE9IDApKQ0KKwkJcmV0dXJuIChOTEVSUik7DQorDQorCS8qIFRyeSB0byBnZXQgaXQgZnJv bSB0aGUgY2FjaGUgZmlyc3QgKi8NCisJUkxPQ0soTkxFUlIpOw0KKwlTTElTVF9GT1JFQUNI KG5wLCAmZmxpc3QsIGxpc3QpIHsNCisJCWlmIChzdHJjbXAobnAtPm5hbWUsIG5hbWUpID09 IDApIHsNCisJCQlpZiAobnAtPmNhdGVycm5vICE9IDApIHsNCisJCQkJVU5MT0NLKE5MRVJS KTsNCisJCQkJTkxSRVRFUlIobnAtPmNhdGVycm5vKTsNCisJCQl9IGVsc2Ugew0KKwkJCQlV TkxPQ0soTkxFUlIpOw0KKwkJCQlucC0+cmVmY291bnQrKzsNCisJCQkJcmV0dXJuIChucC0+ Y2F0ZCk7DQorCQkJfQ0KKwkJfQ0KKwl9DQorCVVOTE9DSyhOTEVSUik7DQorDQogCS8qIGlz IGl0IGFic29sdXRlIHBhdGggPyBpZiB5ZXMsIGxvYWQgaW1tZWRpYXRlbHkgKi8NCiAJaWYg KHN0cmNocihuYW1lLCAnLycpICE9IE5VTEwpDQotCQlyZXR1cm4gKGxvYWRfbXNnY2F0KG5h bWUpKTsNCisJCXJldHVybiAobG9hZF9tc2djYXQobmFtZSwgbmFtZSkpOw0KIA0KIAlpZiAo dHlwZSA9PSBOTF9DQVRfTE9DQUxFKQ0KIAkJbGFuZyA9IHNldGxvY2FsZShMQ19NRVNTQUdF UywgTlVMTCk7DQpAQCAtODUsNyArMTM1LDcgQEANCiANCiAJaWYgKGxhbmcgPT0gTlVMTCB8 fCAqbGFuZyA9PSAnXDAnIHx8IHN0cmxlbihsYW5nKSA+IEVOQ09ESU5HX0xFTiB8fA0KIAkg ICAgKGxhbmdbMF0gPT0gJy4nICYmDQotCSAgICAgKGxhbmdbMV0gPT0gJ1wwJyB8fCAobGFu Z1sxXSA9PSAnLicgJiYgbGFuZ1syXSA9PSAnXDAnKSkpIHx8DQorCSAgICAobGFuZ1sxXSA9 PSAnXDAnIHx8IChsYW5nWzFdID09ICcuJyAmJiBsYW5nWzJdID09ICdcMCcpKSkgfHwNCiAJ ICAgIHN0cmNocihsYW5nLCAnLycpICE9IE5VTEwpDQogCQlsYW5nID0gIkMiOw0KIA0KQEAg LTE2Niw3ICsyMTYsNyBAQA0KIAkJCWlmIChzdGF0KHBhdGgsICZzYnVmKSA9PSAwKSB7DQog CQkJCWZyZWUocGxhbmcpOw0KIAkJCQlmcmVlKGJhc2UpOw0KLQkJCQlyZXR1cm4gKGxvYWRf bXNnY2F0KHBhdGgpKTsNCisJCQkJcmV0dXJuIChsb2FkX21zZ2NhdChwYXRoLCBuYW1lKSk7 DQogCQkJfQ0KIAkJfSBlbHNlIHsNCiAJCQl0bXBwdHIgPSAoY2hhciAqKW5hbWU7DQpAQCAt MTgyLDIwICsyMzIsMjAgQEANCiBjaGFyICoNCiBjYXRnZXRzKG5sX2NhdGQgY2F0ZCwgaW50 IHNldF9pZCwgaW50IG1zZ19pZCwgY29uc3QgY2hhciAqcykNCiB7DQotCXN0cnVjdCBfbmxz X2NhdF9oZHIgKmNhdF9oZHI7DQotCXN0cnVjdCBfbmxzX3NldF9oZHIgKnNldF9oZHI7DQot CXN0cnVjdCBfbmxzX21zZ19oZHIgKm1zZ19oZHI7DQotCWludCBsLCB1LCBpLCByOw0KKwlz dHJ1Y3QgX25sc19jYXRfaGRyCSpjYXRfaGRyOw0KKwlzdHJ1Y3QgX25sc19zZXRfaGRyCSpz ZXRfaGRyOw0KKwlzdHJ1Y3QgX25sc19tc2dfaGRyCSptc2dfaGRyOw0KKwlpbnQJCQkgbCwg dSwgaSwgcjsNCiANCiAJaWYgKGNhdGQgPT0gTlVMTCB8fCBjYXRkID09IE5MRVJSKSB7DQog CQllcnJubyA9IEVCQURGOw0KIAkJLyogTElOVEVEIGludGVyZmFjZSBwcm9ibGVtICovDQot CQlyZXR1cm4gKGNoYXIgKikgczsNCi19DQorCQlyZXR1cm4gKChjaGFyICopcyk7DQorCX0N CiANCiAJY2F0X2hkciA9IChzdHJ1Y3QgX25sc19jYXRfaGRyICopY2F0ZC0+X19kYXRhOyAN CiAJc2V0X2hkciA9IChzdHJ1Y3QgX25sc19zZXRfaGRyICopKHZvaWQgKikoKGNoYXIgKilj YXRkLT5fX2RhdGENCi0JCQkrIHNpemVvZihzdHJ1Y3QgX25sc19jYXRfaGRyKSk7DQorCSAg ICArIHNpemVvZihzdHJ1Y3QgX25sc19jYXRfaGRyKSk7DQogDQogCS8qIGJpbmFyeSBzZWFy Y2gsIHNlZSBrbnV0aCBhbGdvcml0aG0gYiAqLw0KIAlsID0gMDsNCkBAIC0yMjgsNyArMjc4 LDcgQEANCiAJCQkJfSBlbHNlIHsNCiAJCQkJCWwgPSBpICsgMTsNCiAJCQkJfQ0KLX0NCisJ CQl9DQogDQogCQkJLyogbm90IGZvdW5kICovDQogCQkJZ290byBub3Rmb3VuZDsNCkBAIC0y MzgsMjUgKzI4OCw0MCBAQA0KIAkJfSBlbHNlIHsNCiAJCQlsID0gaSArIDE7DQogCQl9DQot fQ0KKwl9DQogDQogbm90Zm91bmQ6DQogCS8qIG5vdCBmb3VuZCAqLw0KIAllcnJubyA9IEVO T01TRzsNCiAJLyogTElOVEVEIGludGVyZmFjZSBwcm9ibGVtICovDQotCXJldHVybiAoY2hh ciAqKSBzOw0KKwlyZXR1cm4gKChjaGFyICopcyk7DQogfQ0KIA0KIGludA0KIGNhdGNsb3Nl KG5sX2NhdGQgY2F0ZCkNCiB7DQorCXN0cnVjdCBjYXRlbnRyeQkJKm5wOw0KKw0KIAlpZiAo Y2F0ZCA9PSBOVUxMIHx8IGNhdGQgPT0gTkxFUlIpIHsNCiAJCWVycm5vID0gRUJBREY7DQog CQlyZXR1cm4gKC0xKTsNCiAJfQ0KIA0KLQltdW5tYXAoY2F0ZC0+X19kYXRhLCAoc2l6ZV90 KWNhdGQtPl9fc2l6ZSk7DQotCWZyZWUoY2F0ZCk7DQorCVdMT0NLKC0xKTsNCisJU0xJU1Rf Rk9SRUFDSChucCwgJmZsaXN0LCBsaXN0KSB7DQorCQlpZiAoKG5wLT5jYXRkLT5fX3NpemUg PT0gY2F0ZC0+X19zaXplKSAmJg0KKwkJICAgIG1lbWNtcCgoY29uc3Qgdm9pZCAqKW5wLT5j YXRkLCAoY29uc3Qgdm9pZCAqKWNhdGQsIG5wLT5jYXRkLT5fX3NpemUpID09IDApIHsNCisJ CQlucC0+cmVmY291bnQtLTsNCisJCQlpZiAobnAtPnJlZmNvdW50ID09IDApIHsNCisJCQkJ bXVubWFwKGNhdGQtPl9fZGF0YSwgKHNpemVfdCljYXRkLT5fX3NpemUpOw0KKwkJCQlmcmVl KGNhdGQpOw0KKwkJCQlTTElTVF9SRU1PVkUoJmZsaXN0LCBucCwgY2F0ZW50cnksIGxpc3Qp Ow0KKwkJCQlmcmVlKG5wKTsNCisJCQl9DQorCQkJYnJlYWs7DQorCQl9DQorCX0NCisJVU5M T0NLKC0xKTsNCiAJcmV0dXJuICgwKTsNCiB9DQogDQpAQCAtMjY1LDE5ICszMzAsMzggQEAN CiAgKi8NCiANCiBzdGF0aWMgbmxfY2F0ZA0KLWxvYWRfbXNnY2F0KGNvbnN0IGNoYXIgKnBh dGgpDQorbG9hZF9tc2djYXQoY29uc3QgY2hhciAqcGF0aCwgY29uc3QgY2hhciAqbmFtZSkN CiB7DQotCXN0cnVjdCBzdGF0IHN0Ow0KLQlubF9jYXRkIGNhdGQ7DQotCXZvaWQgKmRhdGE7 DQotCWludCBmZDsNCisJc3RydWN0IHN0YXQJIHN0Ow0KKwlubF9jYXRkCQkgY2F0ZDsNCisJ c3RydWN0IGNhdGVudHJ5CSpucDsNCisJdm9pZAkJKmRhdGE7DQorCWludAkJIGZkOw0KIA0K LQkvKiBYWFg6IHBhdGggIT0gTlVMTD8gKi8NCisJaWYgKHBhdGggPT0gTlVMTCkgew0KKwkJ ZXJybm8gPSBFSU5WQUw7DQorCQlyZXR1cm4gKE5MRVJSKTsNCisJfQ0KIA0KLQlpZiAoKGZk ID0gX29wZW4ocGF0aCwgT19SRE9OTFkpKSA9PSAtMSkNCisJLyogT25lIG1vcmUgdHJ5IGlu IGNhY2hlOyBpZiBpdCB3YXMgbm90IGZvdW5kIGJ5IG5hbWUsDQorCSAgIGl0IG1pZ2h0IHN0 aWxsIGJlIGZvdW5kIGJ5IGFic29sdXRlIHBhdGguICovDQorCVJMT0NLKE5MRVJSKTsNCisJ U0xJU1RfRk9SRUFDSChucCwgJmZsaXN0LCBsaXN0KSB7DQorCQlpZiAoc3RyY21wKG5wLT5w YXRoLCBwYXRoKSA9PSAwKSB7DQorCQkJbnAtPnJlZmNvdW50Kys7DQorCQkJVU5MT0NLKE5M RVJSKTsNCisJCQlyZXR1cm4gKG5wLT5jYXRkKTsNCisJCX0NCisJfQ0KKwlVTkxPQ0soTkxF UlIpOw0KKw0KKwlpZiAoKGZkID0gX29wZW4ocGF0aCwgT19SRE9OTFkpKSA9PSAtMSkgew0K KwkJU0FWRUZBSUwobmFtZSwgZXJybm8pOw0KIAkJcmV0dXJuIChOTEVSUik7DQorCX0NCiAN CiAJaWYgKF9mc3RhdChmZCwgJnN0KSAhPSAwKSB7DQorCQlTQVZFRkFJTChuYW1lLCBlcnJu byk7DQogCQlfY2xvc2UoZmQpOw0KIAkJcmV0dXJuIChOTEVSUik7DQogCX0NCkBAIC0yODYs MjIgKzM3MCwzNyBAQA0KIAkgICAgKG9mZl90KTApOw0KIAlfY2xvc2UoZmQpOw0KIA0KLQlp ZiAoZGF0YSA9PSBNQVBfRkFJTEVEKQ0KKwlpZiAoZGF0YSA9PSBNQVBfRkFJTEVEKSB7DQor CQlTQVZFRkFJTChuYW1lLCBlcnJubyk7DQogCQlyZXR1cm4gKE5MRVJSKTsNCisJfQ0KIA0K IAlpZiAobnRvaGwoKHVfaW50MzJfdCkoKHN0cnVjdCBfbmxzX2NhdF9oZHIgKilkYXRhKS0+ X19tYWdpYykgIT0NCiAJICAgIF9OTFNfTUFHSUMpIHsNCisJCVNBVkVGQUlMKG5hbWUsIGVy cm5vKTsNCiAJCW11bm1hcChkYXRhLCAoc2l6ZV90KXN0LnN0X3NpemUpOw0KIAkJTkxSRVRF UlIoRUlOVkFMKTsNCiAJfQ0KIA0KIAlpZiAoKGNhdGQgPSBtYWxsb2Moc2l6ZW9mICgqY2F0 ZCkpKSA9PSBOVUxMKSB7DQorCQlTQVZFRkFJTChuYW1lLCBlcnJubyk7DQogCQltdW5tYXAo ZGF0YSwgKHNpemVfdClzdC5zdF9zaXplKTsNCiAJCXJldHVybiAoTkxFUlIpOw0KIAl9DQog DQogCWNhdGQtPl9fZGF0YSA9IGRhdGE7DQogCWNhdGQtPl9fc2l6ZSA9IChpbnQpc3Quc3Rf c2l6ZTsNCisNCisJV0xPQ0soTkxFUlIpOw0KKwlpZiAoKG5wID0gbWFsbG9jKHNpemVvZihz dHJ1Y3QgY2F0ZW50cnkpKSkgIT0gTlVMTCkgew0KKwkJbnAtPm5hbWUgPSBzdHJkdXAobmFt ZSk7DQorCQlucC0+cGF0aCA9IHN0cmR1cChwYXRoKTsNCisJCW5wLT5jYXRkID0gY2F0ZDsN CisJCW5wLT5yZWZjb3VudCA9IDE7DQorCQlucC0+Y2F0ZXJybm8gPSAwOw0KKwkJU0xJU1Rf SU5TRVJUX0hFQUQoJmZsaXN0LCBucCwgbGlzdCk7DQorCX0NCisJVU5MT0NLKE5MRVJSKTsN CiAJcmV0dXJuIChjYXRkKTsNCiB9DQogDQo= --------------000102010404010207030707-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 19:38:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EB68106566B; Sat, 23 Jan 2010 19:38:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5BC8FC0C; Sat, 23 Jan 2010 19:38:38 +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 o0NJcZfl012447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2010 21:38:35 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0NJcZif002925; Sat, 23 Jan 2010 21:38:35 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0NJcZg3002924; Sat, 23 Jan 2010 21:38:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 23 Jan 2010 21:38:35 +0200 From: Kostik Belousov To: Hajimu UMEMOTO Message-ID: <20100123193834.GM59590@deviant.kiev.zoral.com.ua> References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L9+4a/fGFceRH8Zi" 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=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: attilio@freebsd.org, Gabor Kovesdan , current@freebsd.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 19:38:40 -0000 --L9+4a/fGFceRH8Zi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 24, 2010 at 04:18:48AM +0900, Hajimu UMEMOTO wrote: > Hi, >=20 > >>>>> On Wed, 20 Jan 2010 10:20:15 +0100 > >>>>> Gabor Kovesdan said: >=20 > gabor> El 2010. 01. 19. 22:20, Kostik Belousov escribi?$(D+Q: > > Hi, > > r189765 enabled NLS support for libc. Now, any strerror(3) call causes > > 4 (!) failing stat(2) calls. I think this is untolerable. > > > > Catopen() does not cache the catalog descriptor, at least for libc, > > at least for the case where the open failed. > > =20 > gabor> Hi Kostik, >=20 > gabor> thank you for pointing this out. I'll check the code to see how we= could=20 > gabor> add a caching for the failing catalogs. I'll post the patch here w= hen=20 > gabor> I'm done. >=20 > The gai_strerror(3) has same issue. How about the attached patch in > this mail? Wouldn't this cause the locale for error strings to be fixated at the time of the first strerror/gai_strerror call ? Current code, despite it inefficiency, allow dynamic change of locale that is reflected in strerror() output, I believe. --L9+4a/fGFceRH8Zi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktbUDoACgkQC3+MBN1Mb4jDgQCg8gfoCrHpPesz7cSd4mM+zSOU tZkAoIAwNUre6ZZrBuIH04Rt+EMY7iDI =jAbQ -----END PGP SIGNATURE----- --L9+4a/fGFceRH8Zi-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 19:43:37 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CADD31065670; Sat, 23 Jan 2010 19:43:37 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 7B62B8FC1F; Sat, 23 Jan 2010 19:43:37 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 5FF5B14DA313; Sat, 23 Jan 2010 20:43:36 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bhcxdkPmtGeI; Sat, 23 Jan 2010 20:43:26 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id C4AA514DA363; Sat, 23 Jan 2010 20:43:26 +0100 (CET) Message-ID: <4B5B515C.9000109@FreeBSD.org> Date: Sat, 23 Jan 2010 20:43:24 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Kostik Belousov References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <20100123193834.GM59590@deviant.kiev.zoral.com.ua> In-Reply-To: <20100123193834.GM59590@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: attilio@freebsd.org, Hajimu UMEMOTO , current@freebsd.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 19:43:37 -0000 El 2010. 01. 23. 20:38, Kostik Belousov escribió: > Wouldn't this cause the locale for error strings to be fixated at the > time of the first strerror/gai_strerror call ? > > Current code, despite it inefficiency, allow dynamic change of locale > that is reflected in strerror() output, I believe. > That's a good point. Imho, it should be cached in another static variable just like in my patch, where I should store it in another member of the struct. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 21:59:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86C57106568D; Sat, 23 Jan 2010 21:59:18 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (yamagi.org [88.198.78.242]) by mx1.freebsd.org (Postfix) with ESMTP id 48ED58FC13; Sat, 23 Jan 2010 21:59:17 +0000 (UTC) Received: from [192.168.1.150] (f054138044.adsl.alicedsl.de [78.54.138.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTP id 6D8321084A16; Sat, 23 Jan 2010 22:39:30 +0100 (CET) Date: Sat, 23 Jan 2010 22:39:29 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@idate.home.yamagi.org To: Alexander Motin In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> Message-ID: References: <4B55D9D4.1000008@FreeBSD.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current , FreeBSD Stable Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 21:59:18 -0000 On Tue, 19 Jan 2010, Alexander Motin wrote: > Hi. > > I've made a patch, that should solve set of problems of CAM ATA and CAM > generally. I would like to ask for testing and feedback. [snip] Hello, applied this patch to 8-stable recompiled the kernel and rebooted. The kernel did not boot it hangs while probing the ahci-controller. The error message is: ahcich0: Timeout on slot 0 ahcich0: is 00000002 cs 00000000 ss 000000000 rs 00000001 tfs 50 serr 00000000 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config After that the kernel hangs forever. A 8-stable without the patch shows ahcich0: Timeout on slot 0 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config and boots but doesn't find any hard disks. It's an Asus M3A-H/HDMI motherboard with AMD SB710 southbridge. The harddisk is an Western Digital WD10EAVS. Both are working with the old ata implementation in AHCI mode. pciconf output of the controller is atapci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 rev=0x00 hdr=0x00 Thanks, Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 22:05:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23B31106566B; Sat, 23 Jan 2010 22:05:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EDE9B8FC08; Sat, 23 Jan 2010 22:05:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0NM5sNN037795; Sat, 23 Jan 2010 17:05:54 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0NM5sBx037793; Sat, 23 Jan 2010 22:05:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Jan 2010 22:05:54 GMT Message-Id: <201001232205.o0NM5sBx037793@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 22:05:55 -0000 TB --- 2010-01-23 21:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-23 21:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-01-23 21:00:00 - cleaning the object tree TB --- 2010-01-23 21:00:21 - cvsupping the source tree TB --- 2010-01-23 21:00:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-01-23 21:00:54 - building world TB --- 2010-01-23 21:00:54 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 21:00:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 21:00:54 - TARGET=pc98 TB --- 2010-01-23 21:00:54 - TARGET_ARCH=i386 TB --- 2010-01-23 21:00:54 - TZ=UTC TB --- 2010-01-23 21:00:54 - __MAKE_CONF=/dev/null TB --- 2010-01-23 21:00:54 - cd /src TB --- 2010-01-23 21:00:54 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 23 21:00:55 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 23 22:00:18 UTC 2010 TB --- 2010-01-23 22:00:18 - generating LINT kernel config TB --- 2010-01-23 22:00:18 - cd /src/sys/pc98/conf TB --- 2010-01-23 22:00:18 - /usr/bin/make -B LINT TB --- 2010-01-23 22:00:18 - building LINT kernel TB --- 2010-01-23 22:00:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 22:00:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 22:00:18 - TARGET=pc98 TB --- 2010-01-23 22:00:18 - TARGET_ARCH=i386 TB --- 2010-01-23 22:00:18 - TZ=UTC TB --- 2010-01-23 22:00:18 - __MAKE_CONF=/dev/null TB --- 2010-01-23 22:00:18 - cd /src TB --- 2010-01-23 22:00:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 23 22:00:18 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ie/if_ie.c:1155: warning: 'ee16_read_eeprom' defined but not used /src/sys/dev/ie/if_ie.c:1097: warning: 'find_ie_mem_size' defined but not used cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ie/if_ie_isa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/ibfoo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/pcii.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/tnt4882.c /src/sys/dev/ieee488/tnt4882.c: In function 'tnt_attach': /src/sys/dev/ieee488/tnt4882.c:306: error: 'struct upd7210' has no member named 'reg_offset' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-23 22:05:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-23 22:05:54 - ERROR: failed to build lint kernel TB --- 2010-01-23 22:05:54 - 2869.77 user 697.81 system 3953.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 22:07:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A20E106566C; Sat, 23 Jan 2010 22:07:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 515878FC0A; Sat, 23 Jan 2010 22:07:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0NM7BL0045964; Sat, 23 Jan 2010 17:07:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0NM7B5M045951; Sat, 23 Jan 2010 22:07:11 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Jan 2010 22:07:11 GMT Message-Id: <201001232207.o0NM7B5M045951@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 22:07:12 -0000 TB --- 2010-01-23 21:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-23 21:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-01-23 21:00:00 - cleaning the object tree TB --- 2010-01-23 21:00:21 - cvsupping the source tree TB --- 2010-01-23 21:00:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-01-23 21:00:54 - building world TB --- 2010-01-23 21:00:54 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 21:00:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 21:00:54 - TARGET=i386 TB --- 2010-01-23 21:00:54 - TARGET_ARCH=i386 TB --- 2010-01-23 21:00:54 - TZ=UTC TB --- 2010-01-23 21:00:54 - __MAKE_CONF=/dev/null TB --- 2010-01-23 21:00:54 - cd /src TB --- 2010-01-23 21:00:54 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 23 21:00:55 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 23 22:00:28 UTC 2010 TB --- 2010-01-23 22:00:28 - generating LINT kernel config TB --- 2010-01-23 22:00:28 - cd /src/sys/i386/conf TB --- 2010-01-23 22:00:28 - /usr/bin/make -B LINT TB --- 2010-01-23 22:00:28 - building LINT kernel TB --- 2010-01-23 22:00:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 22:00:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 22:00:28 - TARGET=i386 TB --- 2010-01-23 22:00:28 - TARGET_ARCH=i386 TB --- 2010-01-23 22:00:28 - TZ=UTC TB --- 2010-01-23 22:00:28 - __MAKE_CONF=/dev/null TB --- 2010-01-23 22:00:28 - cd /src TB --- 2010-01-23 22:00:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 23 22:00:29 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ie/if_ie.c:1155: warning: 'ee16_read_eeprom' defined but not used /src/sys/dev/ie/if_ie.c:1097: warning: 'find_ie_mem_size' defined but not used cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ie/if_ie_isa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/ibfoo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/pcii.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/tnt4882.c /src/sys/dev/ieee488/tnt4882.c: In function 'tnt_attach': /src/sys/dev/ieee488/tnt4882.c:306: error: 'struct upd7210' has no member named 'reg_offset' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-23 22:07:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-23 22:07:11 - ERROR: failed to build lint kernel TB --- 2010-01-23 22:07:11 - 2956.14 user 678.33 system 4031.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 22:33:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A5961065670; Sat, 23 Jan 2010 22:33:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 519CB8FC14; Sat, 23 Jan 2010 22:33:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0NMX6KW076730; Sat, 23 Jan 2010 17:33:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0NMX6oK076728; Sat, 23 Jan 2010 22:33:06 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Jan 2010 22:33:06 GMT Message-Id: <201001232233.o0NMX6oK076728@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 22:33:07 -0000 TB --- 2010-01-23 21:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-23 21:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-01-23 21:00:00 - cleaning the object tree TB --- 2010-01-23 21:00:26 - cvsupping the source tree TB --- 2010-01-23 21:00:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-01-23 21:01:01 - building world TB --- 2010-01-23 21:01:01 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 21:01:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 21:01:01 - TARGET=amd64 TB --- 2010-01-23 21:01:01 - TARGET_ARCH=amd64 TB --- 2010-01-23 21:01:01 - TZ=UTC TB --- 2010-01-23 21:01:01 - __MAKE_CONF=/dev/null TB --- 2010-01-23 21:01:01 - cd /src TB --- 2010-01-23 21:01:01 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 23 21:01:01 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jan 23 22:26:54 UTC 2010 TB --- 2010-01-23 22:26:54 - generating LINT kernel config TB --- 2010-01-23 22:26:54 - cd /src/sys/amd64/conf TB --- 2010-01-23 22:26:54 - /usr/bin/make -B LINT TB --- 2010-01-23 22:26:54 - building LINT kernel TB --- 2010-01-23 22:26:54 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 22:26:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 22:26:54 - TARGET=amd64 TB --- 2010-01-23 22:26:54 - TARGET_ARCH=amd64 TB --- 2010-01-23 22:26:54 - TZ=UTC TB --- 2010-01-23 22:26:54 - __MAKE_CONF=/dev/null TB --- 2010-01-23 22:26:54 - cd /src TB --- 2010-01-23 22:26:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 23 22:26:54 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ida/ida.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ida/ida_disk.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ida/ida_pci.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/ibfoo.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/pcii.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ieee488/tnt4882.c /src/sys/dev/ieee488/tnt4882.c: In function 'tnt_attach': /src/sys/dev/ieee488/tnt4882.c:306: error: 'struct upd7210' has no member named 'reg_offset' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-23 22:33:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-23 22:33:06 - ERROR: failed to build lint kernel TB --- 2010-01-23 22:33:06 - 4104.05 user 961.04 system 5585.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 23 23:13:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F20B106566B; Sat, 23 Jan 2010 23:13:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6760E8FC18; Sat, 23 Jan 2010 23:13:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0NNDSjZ079023; Sat, 23 Jan 2010 18:13:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0NNDSqL079019; Sat, 23 Jan 2010 23:13:28 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Jan 2010 23:13:28 GMT Message-Id: <201001232313.o0NNDSqL079019@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 23:13:29 -0000 TB --- 2010-01-23 21:49:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-23 21:49:51 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-01-23 21:49:51 - cleaning the object tree TB --- 2010-01-23 21:50:06 - cvsupping the source tree TB --- 2010-01-23 21:50:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-01-23 21:50:37 - building world TB --- 2010-01-23 21:50:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 21:50:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 21:50:37 - TARGET=ia64 TB --- 2010-01-23 21:50:37 - TARGET_ARCH=ia64 TB --- 2010-01-23 21:50:37 - TZ=UTC TB --- 2010-01-23 21:50:37 - __MAKE_CONF=/dev/null TB --- 2010-01-23 21:50:37 - cd /src TB --- 2010-01-23 21:50:37 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 23 21:50:37 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 23 23:06:48 UTC 2010 TB --- 2010-01-23 23:06:48 - generating LINT kernel config TB --- 2010-01-23 23:06:48 - cd /src/sys/ia64/conf TB --- 2010-01-23 23:06:48 - /usr/bin/make -B LINT TB --- 2010-01-23 23:06:48 - building LINT kernel TB --- 2010-01-23 23:06:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-23 23:06:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-23 23:06:48 - TARGET=ia64 TB --- 2010-01-23 23:06:48 - TARGET_ARCH=ia64 TB --- 2010-01-23 23:06:48 - TZ=UTC TB --- 2010-01-23 23:06:48 - __MAKE_CONF=/dev/null TB --- 2010-01-23 23:06:48 - cd /src TB --- 2010-01-23 23:06:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 23 23:06:48 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ida/ida.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ida/ida_disk.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ida/ida_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ieee488/ibfoo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ieee488/pcii.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ieee488/tnt4882.c /src/sys/dev/ieee488/tnt4882.c: In function 'tnt_attach': /src/sys/dev/ieee488/tnt4882.c:306: error: 'struct upd7210' has no member named 'reg_offset' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-23 23:13:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-23 23:13:28 - ERROR: failed to build lint kernel TB --- 2010-01-23 23:13:28 - 3958.49 user 665.55 system 5017.01 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full