From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 07:01:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 484E4106564A; Sun, 20 May 2012 07:01:51 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7A78FC08; Sun, 20 May 2012 07:01:50 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Sun, 20 May 2012 09:01:43 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 May 2012 09:01:43 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 May 2012 09:01:42 +0200 From: Marko Zec To: Date: Sun, 20 May 2012 09:01:32 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201205200901.32613.zec@fer.hr> X-OriginalArrivalTime: 20 May 2012 07:01:42.0696 (UTC) FILETIME=[69658280:01CD3656] Cc: freebsd-amd64@freebsd.org Subject: superpages and kmem on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 07:01:51 -0000 Hi all, I'm playing with an algorithm which makes use of large contiguous blocks of kernel memory (ranging from 1M to 1G in size), so it would be nice if those could be somehow forcibly mapped to superpages. I was hoping that the VM system would automagically map (merge) contiguous 4k pages to superpages, but apparently it doesn't: vm.pmap.pdpe.demotions: 2 vm.pmap.pde.promotions: 543 vm.pmap.pde.p_failures: 266253 vm.pmap.pde.mappings: 0 vm.pmap.pde.demotions: 31 I.e. I have 1G of kmem allocated using via malloc(1024 * 1024 * 1024, M_TEMP, M_NOWAIT); but vm.pmap.pde.mappings: 0 suggests that no superpages are in use. Is there an alternative kernel memory allocation method which might force superpages to be used for contiguous memory blocks? And how do I find more details about page mappings for a given kmem virtual address? I'm running 8.3-STABLE on amd64. Thanks, Marko From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 07:26:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0854C1065670; Sun, 20 May 2012 07:26:02 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8E2B8FC08; Sun, 20 May 2012 07:26:01 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so6079916pbb.13 for ; Sun, 20 May 2012 00:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xKYg64oQ2049hcmN3hiXpwIa8A+EScJareT06D+AZ0M=; b=jdCr+4C3tm/uPvx2qwfBmPqJMAj8h62frZRFdaQH/LmTxqCgtwyCAc2Exn3ZrLw0cL xDw1xAn+XaYecUCptpToIlVrF2Ss9b6c0ON2F+BSxe2yEyKDvh1F7QD7YYLYIi7sLq8f /eWBLycOA6YpMmrNqnWWSuBsh4cxflG2N5uxZB7R9jD0dirz685VN7S9XSUJH+fcJDWh WhADeWOmI1TicKrerQ33Ot3+ao6lqclPphm8r4hGeRdBvlPgFMR23hyEjA6S7IjZjpjr ka84DLGAxvOlJ8WsFkzHfKJedXeq/+IXO9J/ZwW6t0eE3uaD4HLhzFcLL/tF70wm2Pxr /AMw== MIME-Version: 1.0 Received: by 10.68.238.73 with SMTP id vi9mr23354111pbc.14.1337498759601; Sun, 20 May 2012 00:25:59 -0700 (PDT) Received: by 10.68.226.7 with HTTP; Sun, 20 May 2012 00:25:59 -0700 (PDT) In-Reply-To: <201205200901.32613.zec@fer.hr> References: <201205200901.32613.zec@fer.hr> Date: Sun, 20 May 2012 02:25:59 -0500 Message-ID: From: Alan Cox To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 07:26:04 -0000 On Sun, May 20, 2012 at 2:01 AM, Marko Zec wrote: > Hi all, > > I'm playing with an algorithm which makes use of large contiguous blocks of > kernel memory (ranging from 1M to 1G in size), so it would be nice if those > could be somehow forcibly mapped to superpages. I was hoping that the VM > system would automagically map (merge) contiguous 4k pages to superpages, > but > apparently it doesn't: > > vm.pmap.pdpe.demotions: 2 > vm.pmap.pde.promotions: 543 > vm.pmap.pde.p_failures: 266253 > vm.pmap.pde.mappings: 0 > vm.pmap.pde.demotions: 31 > > No, your conclusion is incorrect. These counts show that 543 superpage mappings were created by promotion. Alan From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 11:31:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A260106566C; Sun, 20 May 2012 11:31:39 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 718758FC0A; Sun, 20 May 2012 11:31:38 +0000 (UTC) Received: by laai10 with SMTP id i10so4243449laa.13 for ; Sun, 20 May 2012 04:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tMw2WaEL3jz8YjrmSFw+KzThWVJN9BAipAVcb3wUyjU=; b=Fpnz/VVIypvMdpC5WMXYbpkxmnne9Ze6mEBcjL3JR1Ka9FJwydPxHfzWgjB7EkbIW4 PpVZMNfpZR5WiSUjVwsuP6y4lPkZVGfqQs87PN85SrQMsapWlxsqLtw/j1a3z4wCc/dF VDfFfEJWZv8SftTr0+gV8rAQGWPGsfzli9JpTyhWdMkFO0R9Nk70daa4c6EBR9bFuyaP D422vjQh6j6nJCcAxM1znKkge0lYo1321izDnro46271RR8czDeXLufAXgb4IvdDRRv6 o/tDv5mBqPN52n7H5a4/bMSwXHptsFscnLOVUgzidTSlkrchz3KJat7xKmyRPunMb2u1 z7Hg== MIME-Version: 1.0 Received: by 10.112.99.71 with SMTP id eo7mr7420304lbb.84.1337513497184; Sun, 20 May 2012 04:31:37 -0700 (PDT) Received: by 10.152.24.131 with HTTP; Sun, 20 May 2012 04:31:37 -0700 (PDT) In-Reply-To: <4FB7F743.9020405@FreeBSD.org> References: <4FB7F743.9020405@FreeBSD.org> Date: Sun, 20 May 2012 13:31:37 +0200 Message-ID: From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers Subject: Re: Radeon, DRM and crash on 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 11:31:39 -0000 On Sat, May 19, 2012 at 9:40 PM, Andriy Gapon wrote: > on 19/05/2012 17:52 Fernando Apestegu=EDa said the following: >> Hi, >> >> I'm having some system crashes from time to time. I had this before >> but until recently I couldn't set my system so I could get crash >> dumps. >> >> My video card is a ATI Mobility Radeon 9700. I'm running FreeBSD >> 9.0-RELEASE for amd64. These are excerpts from two crash dumps text >> files: >> >> core.txt.3: >> >> Fatal trap 28: machine check trap while in kernel mode >> cpuid =3D 0; apic id =3D 00 >> instruction pointer =A0 =A0 =3D 0x20:0xffffffff816480a3 >> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff804a5eb970 >> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff804a5eb990 >> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x= 1b >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1= , def32 0, gran 1 >> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, IOPL =3D 3 >> current process =A0 =A0 =A0 =A0 =3D 2254 (Xorg) >> trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 28 >> panic: machine check trap >> cpuid =3D 0 >> KDB: stack backtrace: >> #0 0xffffffff80869abe at kdb_backtrace+0x5e >> #1 0xffffffff80833fb7 at panic+0x187 >> #2 0xffffffff80b18b80 at trap_fatal+0x290 >> #3 0xffffffff80b190c0 at trap+0x110 >> #4 0xffffffff80b0396f at calltrap+0x8 >> #5 0xffffffff816a305b at drm_ioctl+0x31b >> #6 0xffffffff8075597b at devfs_ioctl_f+0x7b >> #7 0xffffffff8087afb1 at kern_ioctl+0x111 >> #8 0xffffffff8087b1df at sys_ioctl+0xef >> #9 0xffffffff80b18480 at amd64_syscall+0x450 >> #10 0xffffffff80b03c57 at Xfast_syscall+0xf7 >> >> >> Unread portion of the kernel message buffer: >> MCA: Bank 4, Status 0xb200000000070f0f >> MCA: Global Cap 0x0000000000000105, Status 0x0000000000000004 >> MCA: Vendor "AuthenticAMD", ID 0xf4a, APIC ID 0 >> MCA: CPU 0 UNCOR PCC BUSLG ??? ERR Other timed out > > Did you notice that you were getting the machine check exceptions? > You might want to google for this term. > Anyway, there is sysutils/mcelog port and this is how mcelog utility deco= des the > above report: > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 0 4 northbridge > =A0Northbridge Watchdog error > =A0 =A0 =A0 bit57 =3D processor context corrupt > =A0 =A0 =A0 bit61 =3D error uncorrected > =A0bus error 'generic participation, request timed out > =A0 =A0 =A0 =A0 =A0 =A0 generic error mem transaction > =A0 =A0 =A0 =A0 =A0 =A0 generic access, level generic' > STATUS b200000000070f0f MCGSTATUS 4 > MCGCAP 105 APICID 0 SOCKETID 0 > CPUID Vendor AMD Family 15 Model 4 Thanks for the reply. I found some information about this specific error. It seems it could be caused by overheating (among other things), and it's true this laptop can become really hot at times. I'll have a look at it. Thanks! > >> core.txt.4 >> >> Fatal trap 28: machine check trap while in kernel mode >> cpuid =3D 0; apic id =3D 00 >> instruction pointer =A0 =A0 =3D 0x20:0xffffffff816462b6 >> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff804a5eb930 >> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff804a5eb940 >> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x= 1b >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1= , def32 0, gran 1 >> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, IOPL =3D 3 >> current process =A0 =A0 =A0 =A0 =3D 2254 (Xorg) >> trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 28 >> panic: machine check trap >> cpuid =3D 0 >> KDB: stack backtrace: >> #0 0xffffffff80869abe at kdb_backtrace+0x5e >> #1 0xffffffff80833fb7 at panic+0x187 >> #2 0xffffffff80b18b80 at trap_fatal+0x290 >> #3 0xffffffff80b190c0 at trap+0x110 >> #4 0xffffffff80b0396f at calltrap+0x8 >> #5 0xffffffff8164f3cc at radeon_cp_indirect+0x24c >> #6 0xffffffff816a305b at drm_ioctl+0x31b >> #7 0xffffffff8075597b at devfs_ioctl_f+0x7b >> #8 0xffffffff8087afb1 at kern_ioctl+0x111 >> #9 0xffffffff8087b1df at sys_ioctl+0xef >> #10 0xffffffff80b18480 at amd64_syscall+0x450 >> #11 0xffffffff80b03c57 at Xfast_syscall+0xf7 >> >> dmesg | grep agp >> agp0: on hostb0 >> >> drm.ko is loaded and agp is included in kernel. >> >> AGP =A0for the card seems to be properly detected: >> >> dmesg | grep drm >> drm0: on vgapci0 >> info: [drm] AGP at 0xe0000000 256MB >> info: [drm] Initialized radeon 1.31.0 20080613 >> info: [drm] Setting GART location based on new memory map >> info: [drm] Loading R300 Microcode >> info: [drm] Num pipes: 1 >> >> grep -i "Direct rendering" /var/log/Xorg.0.log >> (II) RADEON(0): Direct rendering enabled >> >> The crash is not easily reproducible but seems to be more likely to >> occur the more activity there is in the screen (like when scrolling a >> window quite fast). >> >> Any help is appreciated. >> >> Thanks in advance. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >> > > > -- > Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 14:15:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B84551065670 for ; Sun, 20 May 2012 14:15:21 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id ED1188FC0C for ; Sun, 20 May 2012 14:15:20 +0000 (UTC) Received: (qmail 77470 invoked by uid 1004); 20 May 2012 14:09:12 -0000 Message-ID: <4FB8FADF.50808@uffe.org> Date: Sun, 20 May 2012 16:08:31 +0200 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Booting Ubuntu and freebsd side by side X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 14:15:21 -0000 Hi, On 2012-05-19 20:59, سید احمد حسینی wrote: > I used boot0 with boot9cfg : boot0cfg -B -b /boot/boot0 ada0 > And I can see boot0 menu ,but Ubuntu can't boot! > On May 19, 2012 11:26 PM, "سید احمد حسینی" wrote: > You should make sure that GRUB is installed in the PBR (partition boot record) of your ubuntu partition and not in the MBR since boot0 lives there. I've done that with Linux Mint Debian Edition - and it works. /Uffe >> I used boot0 with boot9cfg : >> boot0cfg -B -b /boot/boot0 >> And I can see boot0 menu ,but Ubuntu can't boot! >> On May 19, 2012 11:17 PM, "User Wojtek" >> wrote: >> >>> How can I boot Ubuntu12.4 do with FreeBSD9 ? >>>> when I using boot0 , Linux was shown, but would not start without a >>>> message! >>>> Where is the problem? >>>> >>>> can launch freebsd with Ubuntu GRUB? >>>> How? >>>> >>> >>> install ubuntu (or whatever) on one MBR partition, FreeBSD on another >>> then install partition selector with >>> >>> boot0cfg -B /dev/yourdisk >>> >>> and select F1...F4 at boot. >>> that simple >>> From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 14:45:03 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 871221065670; Sun, 20 May 2012 14:45:03 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (slavko2.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 102AE8FC08; Sun, 20 May 2012 14:45:02 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Sun, 20 May 2012 16:45:00 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 May 2012 16:45:00 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 May 2012 16:43:06 +0200 From: Marko Zec To: Date: Sun, 20 May 2012 16:43:00 +0200 User-Agent: KMail/1.9.10 References: <201205200901.32613.zec@fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201205201643.01194.zec@fer.hr> X-OriginalArrivalTime: 20 May 2012 14:43:06.0377 (UTC) FILETIME=[DE27FF90:01CD3696] Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 14:45:03 -0000 On Sunday 20 May 2012 09:25:59 Alan Cox wrote: > On Sun, May 20, 2012 at 2:01 AM, Marko Zec wrote: > > Hi all, > > > > I'm playing with an algorithm which makes use of large contiguous blocks > > of kernel memory (ranging from 1M to 1G in size), so it would be nice if > > those could be somehow forcibly mapped to superpages. I was hoping that > > the VM system would automagically map (merge) contiguous 4k pages to > > superpages, but > > apparently it doesn't: > > > > vm.pmap.pdpe.demotions: 2 > > vm.pmap.pde.promotions: 543 > > vm.pmap.pde.p_failures: 266253 > > vm.pmap.pde.mappings: 0 > > vm.pmap.pde.demotions: 31 > > No, your conclusion is incorrect. These counts show that 543 superpage > mappings were created by promotion. OK, that sounds promising. Does "created by promotion" count reflect historic / cumulative stats, or is vm.pmap.pde.promotions the actual number of superpages active? Or should we subtract vm.pmap.pde.demotions from it to get the current value? In any case, I wish to be certain that a particular kmem virtual address range is mapped to superpages - how can I enforce that at malloc time, and / or find out later if I really got my kmem mapped to superpages? Perhaps vm_map_lookup() could provide more info, but I'm wondering if someone already wrote a wrapper function for that, which takes only the base virtual address as a single argument? BTW, apparently malloc(size, M_TEMP, M_NOWAIT) requests fail for size > 1G, even at boot time. Any ideas how to circumvent that (8.3-STABLE, amd64, 4G physical RAM)? Thanks, Marko From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 15:55:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3362D1065670 for ; Sun, 20 May 2012 15:55:32 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B01C48FC08 for ; Sun, 20 May 2012 15:55:31 +0000 (UTC) Received: by bkvi18 with SMTP id i18so4600917bkv.13 for ; Sun, 20 May 2012 08:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=7nPZkuMU/AkXb5TeoDEVTK6jjipCHXskR3SmK5XiTVo=; b=CPye3tjVB3oOLeQvg7lwfappfbM4Yv21TcSz85/TElfXrksXbipxnvJ2a844KopovA O3N/nj6y9RuHx3Vjk0Q1ql/M093DC2hBOUSZgowgGURCw9Sr69PKIHZyxcp/4qHi+Aqe heHt7rC8IdkCN7/f5yU9uVsALnJfpQD7nFNcJXupBqbn4evwR3PH3xbVUutlpgxsynM/ DEjMRN/8dYwH8fz7tCitBm3MEWmHCpWNbv5fmeZieJ7e1xlOOe3ePDc+6GG9VHC/JkC6 31jf2aImsx8HkPkMiA2LeEU9L4quYYSmg7z3kNPqlpeS0NTyMR8OvYqBiCDlmjjlGnME c3ww== Received: by 10.204.154.193 with SMTP id p1mr6429490bkw.102.1337529330456; Sun, 20 May 2012 08:55:30 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.171.138 with HTTP; Sun, 20 May 2012 08:55:00 -0700 (PDT) In-Reply-To: <4FB8FADF.50808@uffe.org> References: <4FB8FADF.50808@uffe.org> From: Chris Rees Date: Sun, 20 May 2012 16:55:00 +0100 X-Google-Sender-Auth: Cy2YVxX-fOHjcJMmluhZf9HwpAE Message-ID: To: Uffe Jakobsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Booting Ubuntu and freebsd side by side X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 15:55:32 -0000 On 20 May 2012 15:08, Uffe Jakobsen wrote: > > > Hi, > > > On 2012-05-19 20:59, =D8=B3=DB=8C=D8=AF =D8=A7=D8=AD=D9=85=D8=AF =D8=AD= =D8=B3=DB=8C=D9=86=DB=8C wrote: >> >> I used boot0 with boot9cfg : boot0cfg -B -b /boot/boot0 ada0 >> And I can see boot0 menu ,but Ubuntu can't boot! >> On May 19, 2012 11:26 PM, "=D8=B3=DB=8C=D8=AF =D8=A7=D8=AD=D9=85=D8=AF = =D8=AD=D8=B3=DB=8C=D9=86=DB=8C" =C2=A0wrote: >> > > You should make sure that GRUB is installed in the PBR (partition boot > record) of your ubuntu partition and not in the MBR since boot0 lives the= re. > > I've done that with Linux Mint Debian Edition - and it works. Yes, and grub2 is a particularly horrifying thing to work with. I'd ask on ubuntu-users@ubuntu.com; there were some clued-up people there when I used to be on that list-- however don't let them talk you into using grub2 to boot FreeBSD ;) Chris From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 17:42:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF53C1065674; Sun, 20 May 2012 17:42:26 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id B33CE8FC17; Sun, 20 May 2012 17:42:26 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id CAFBE290FF2; Sun, 20 May 2012 12:34:27 -0500 (CDT) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id BD24B290FE3; Sun, 20 May 2012 12:34:27 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id Xl56zmO57n7D; Sun, 20 May 2012 12:34:27 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 37F3E290FD2; Sun, 20 May 2012 12:34:27 -0500 (CDT) Message-ID: <4FB92B22.5020304@rice.edu> Date: Sun, 20 May 2012 12:34:26 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Marko Zec References: <201205200901.32613.zec@fer.hr> <201205201643.01194.zec@fer.hr> In-Reply-To: <201205201643.01194.zec@fer.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 17:42:27 -0000 On 05/20/2012 09:43, Marko Zec wrote: > On Sunday 20 May 2012 09:25:59 Alan Cox wrote: >> On Sun, May 20, 2012 at 2:01 AM, Marko Zec wrote: >>> Hi all, >>> >>> I'm playing with an algorithm which makes use of large contiguous blocks >>> of kernel memory (ranging from 1M to 1G in size), so it would be nice if >>> those could be somehow forcibly mapped to superpages. I was hoping that >>> the VM system would automagically map (merge) contiguous 4k pages to >>> superpages, but >>> apparently it doesn't: >>> >>> vm.pmap.pdpe.demotions: 2 >>> vm.pmap.pde.promotions: 543 >>> vm.pmap.pde.p_failures: 266253 >>> vm.pmap.pde.mappings: 0 >>> vm.pmap.pde.demotions: 31 >> No, your conclusion is incorrect. These counts show that 543 superpage >> mappings were created by promotion. > OK, that sounds promising. Does "created by promotion" count reflect > historic / cumulative stats, or is vm.pmap.pde.promotions the actual number > of superpages active? Or should we subtract vm.pmap.pde.demotions from it to > get the current value? The count is cumulative. There is no instantaneous count. Subtracting demotions from promotions plus mappings is not a reliable way to get the instantaneous total because a superpage mapping can be destroyed without first being demoted. > In any case, I wish to be certain that a particular kmem virtual address range > is mapped to superpages - how can I enforce that at malloc time, and / or > find out later if I really got my kmem mapped to superpages? Perhaps > vm_map_lookup() could provide more info, but I'm wondering if someone already > wrote a wrapper function for that, which takes only the base virtual address > as a single argument? Try using pmap_mincore() to verify that the mappings are superpages. > BTW, apparently malloc(size, M_TEMP, M_NOWAIT) requests fail for size> 1G, > even at boot time. Any ideas how to circumvent that (8.3-STABLE, amd64, 4G > physical RAM)? I suspect that you need to increase the size of your kmem map. Alan From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 18:09:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BE5D1065674 for ; Sun, 20 May 2012 18:09:15 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id E59458FC0C for ; Sun, 20 May 2012 18:09:14 +0000 (UTC) Received: from kibab-darwin.local (unknown [46.115.2.123]) by mx0.deglitch.com (Postfix) with ESMTPSA id 71E658FC27; Sun, 20 May 2012 22:09:11 +0400 (MSK) Message-ID: <4FB933B7.5080004@kibab.com> Date: Sun, 20 May 2012 20:11:03 +0200 From: Ilya Bakulin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mel Flynn References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <20120516140033.GB2470@dft-labs.eu> <20120516233744.1314398bowqaykuw@webmail.teithe.gr> <20120517125348.GA26081@dft-labs.eu> <4FB6620D.8060001@acsalaska.net> <01A33A03-3068-46E8-958F-500216E4E912@kientzle.com> <4FB7FC55.2060905@acsalaska.net> In-Reply-To: <4FB7FC55.2060905@acsalaska.net> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig79C04B0217AF2EF778BC1490" Cc: Mateusz Guzik , tzabal@it.teithe.gr, freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 18:09:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig79C04B0217AF2EF778BC1490 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 19.05.12 22:02, Mel Flynn wrote: > As I read the original intent is to post crashdumps at a specified > remote location through rc(8) using an sh(1) script on the next > reboot. tar seemed appropriate. I'm only mentioning extending > libfetch(3), because it will be easy for fetch(1) to pick it up, it > benefits more than just this project and once integrated into fetch(1) > can be used in said script above. Other than openssh we don't really > have a good tool in the base system to put local files elsewhere > securely. Also, if the BUGS section of fetch(3) is out of date, I'm > happy to be corrected :)=20 I'm not going to make you happy... =46rom lib/libfetch/http.c: /* * Store a file by HTTP */ FILE * fetchPutHTTP(struct url *URL __unused, const char *flags __unused) { warnx("fetchPutHTTP(): not implemented"); return (NULL); } Adding HTTP PUT support to libfetch would be cool, but I doubt that it's worth wasting GSoC time for that. Most people use curl for that just because Google tells them to. On the other hand, SSH is available in FreeBSD system in 99% of use cases, and it would be quite easy to setup secure file transfer. The final decision should however be made by TS. --=20 Regards, Ilya Bakulin http://kibab.com xmpp://kibab612@jabber.ru --------------enig79C04B0217AF2EF778BC1490 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+5M74ACgkQo9vlj1oadwhnRACgjZ5XYJiHHbWzhyD/xFBe0W5l 4AQAoKGiV/oSJYrmFdQ6b8NvlJJeR04P =J8wF -----END PGP SIGNATURE----- --------------enig79C04B0217AF2EF778BC1490-- From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 19:50:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EBE7106564A for ; Sun, 20 May 2012 19:50:13 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 65A708FC08 for ; Sun, 20 May 2012 19:50:13 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4KJo7c6025106; Sun, 20 May 2012 19:50:07 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id xvquy4kj7fuwv3n788r8if5jhn; Sun, 20 May 2012 19:50:06 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> Date: Sun, 20 May 2012 12:50:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> To: Rozhuk.IM@gmail.com X-Mailer: Apple Mail (2.1257) Cc: 'User Wojtek' , 'Matthias Apitz' , freebsd-hackers@freebsd.org Subject: Geom_mbr vs. SSD disks (was: proper newts options for SSD disks) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 19:50:13 -0000 On May 19, 2012, at 11:36 AM, rozhuk.im@gmail.com wrote: > Do not use MBR (or manually do all to align). > 63 - not 4k aligned. Right now, the "-a" alignment option for "gpart add" is broken when used with MBR partitions. It looks like the gpart command uses it to correctly align the start/end, but then the actual MBR geom code does another alignment pass that rounds the start/size to a multiple of gpt_sectors, which defaults to 63. This seems problematic. It's tempting to change sys/geom/part/g_part_mbr.c so that it skips this additional alignment when the geometry has defaulted. Something like this: Index: sys/geom/part/g_part_mbr.c =================================================================== --- part/g_part_mbr.c (revision 235597) +++ part/g_part_mbr.c (working copy) @@ -211,6 +211,7 @@ start = gpp->gpp_start; size = gpp->gpp_size; + if (sectors != 63 || basetable->gpt_heads != 255) { if (size < sectors) return (EINVAL); if (start % sectors) { @@ -221,6 +222,7 @@ size = size - (size % sectors); if (size < sectors) return (EINVAL); + } if (baseentry->gpe_deleted) bzero(&entry->ent, sizeof(entry->ent)); I'm not really certain I understand all of the implications of this change, though. Tim From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 20:18:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537731065673; Sun, 20 May 2012 20:18:57 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id BAD188FC0A; Sun, 20 May 2012 20:18:56 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4KKImis049460; Sun, 20 May 2012 22:18:48 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4KKImRo049448; Sun, 20 May 2012 22:18:48 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 20 May 2012 22:18:48 +0200 (CEST) From: User Wojtek To: Marko Zec In-Reply-To: <201205201643.01194.zec@fer.hr> Message-ID: References: <201205200901.32613.zec@fer.hr> <201205201643.01194.zec@fer.hr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 20 May 2012 22:18:48 +0200 (CEST) Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 20:18:57 -0000 > historic / cumulative stats, or is vm.pmap.pde.promotions the actual number > of superpages active? Or should we subtract vm.pmap.pde.demotions from it to > get the current value? yes substracting gives current value. From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 20:22:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 550CE1065673; Sun, 20 May 2012 20:22:23 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id B47638FC16; Sun, 20 May 2012 20:22:22 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4KKMIcA058093; Sun, 20 May 2012 22:22:18 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4KKMIPf058086; Sun, 20 May 2012 22:22:18 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 20 May 2012 22:22:18 +0200 (CEST) From: User Wojtek To: Marko Zec In-Reply-To: <201205201643.01194.zec@fer.hr> Message-ID: References: <201205200901.32613.zec@fer.hr> <201205201643.01194.zec@fer.hr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 20 May 2012 22:22:18 +0200 (CEST) Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 20:22:23 -0000 >>> vm.pmap.pde.demotions: 31 >> >> No, your conclusion is incorrect. These counts show that 543 superpage >> mappings were created by promotion. > > OK, that sounds promising. Does "created by promotion" count reflect > historic / cumulative stats, or is vm.pmap.pde.promotions the actual number > of superpages active? Or should we subtract vm.pmap.pde.demotions from it to > get the current value? correction to my last answer. something is just wrong IMHO on my 2GB laptop: [root@wojtek ~]# sysctl -ad vm.pmap.pde vm.pmap.pde: 2MB page mapping counters vm.pmap.pde.promotions: 2MB page promotions vm.pmap.pde.p_failures: 2MB page promotion failures vm.pmap.pde.mappings: 2MB page mappings vm.pmap.pde.demotions: 2MB page demotions [root@wojtek ~]# sysctl -a vm.pmap.pde vm.pmap.pde.promotions: 61196 vm.pmap.pde.p_failures: 4796 vm.pmap.pde.mappings: 3051 vm.pmap.pde.demotions: 2306 from description seems like mappings could be current amount , but both it's value as well as promotions-demotions gives nonsense. with 2GB RAM there can not be 3051 or more 2MB pages mapped! and i - at present - doesn't run many large programs actually only some xterms and one compiling task. From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 22:48:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D15C3106564A; Sun, 20 May 2012 22:48:58 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (slavko2.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 587798FC18; Sun, 20 May 2012 22:48:57 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Mon, 21 May 2012 00:48:55 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 00:48:23 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 00:48:22 +0200 From: Marko Zec To: Alan Cox Date: Mon, 21 May 2012 00:48:16 +0200 User-Agent: KMail/1.9.10 References: <201205200901.32613.zec@fer.hr> <201205201643.01194.zec@fer.hr> <4FB92B22.5020304@rice.edu> In-Reply-To: <4FB92B22.5020304@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201205210048.16877.zec@fer.hr> X-OriginalArrivalTime: 20 May 2012 22:48:22.0826 (UTC) FILETIME=[A8E988A0:01CD36DA] Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 22:48:58 -0000 On Sunday 20 May 2012 19:34:26 Alan Cox wrote: ... > > In any case, I wish to be certain that a particular kmem virtual address > > range is mapped to superpages - how can I enforce that at malloc time, > > and / or find out later if I really got my kmem mapped to superpages? > > Perhaps vm_map_lookup() could provide more info, but I'm wondering if > > someone already wrote a wrapper function for that, which takes only the > > base virtual address as a single argument? > > Try using pmap_mincore() to verify that the mappings are superpages. flags = pmap_mincore(vmspace_pmap(curthread->td_proc->p_vmspace), (vm_offset_t) addr)); OK, that works, and now I know my kmem chunk is on a superpage, horray!!! Thanks! > > BTW, apparently malloc(size, M_TEMP, M_NOWAIT) requests fail for size> > > 1G, even at boot time. Any ideas how to circumvent that (8.3-STABLE, > > amd64, 4G physical RAM)? > > I suspect that you need to increase the size of your kmem map. Huh any hints how should I achieve that? In desperation I placed vm.kmem_size=8G in /boot/loader.conf and got this: vm.kmem_map_free: 8123924480 vm.kmem_map_size: 8364032 vm.kmem_size_scale: 1 vm.kmem_size_max: 329853485875 vm.kmem_size_min: 0 vm.kmem_size: 8132288512 but malloc(2G) still fails... Thanks, Marko From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 23:12:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67B04106566B; Sun, 20 May 2012 23:12:04 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx1.freebsd.org (Postfix) with ESMTP id 381728FC0A; Sun, 20 May 2012 23:12:04 +0000 (UTC) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 456854C01A3; Sun, 20 May 2012 18:12:03 -0500 (CDT) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 43DD54C01A0; Sun, 20 May 2012 18:12:03 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id p5KMCTUttkT3; Sun, 20 May 2012 18:12:03 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id C51E34C0199; Sun, 20 May 2012 18:12:02 -0500 (CDT) Message-ID: <4FB97A41.70405@rice.edu> Date: Sun, 20 May 2012 18:12:01 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Marko Zec References: <201205200901.32613.zec@fer.hr> <201205201643.01194.zec@fer.hr> <4FB92B22.5020304@rice.edu> <201205210048.16877.zec@fer.hr> In-Reply-To: <201205210048.16877.zec@fer.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 23:12:04 -0000 On 05/20/2012 17:48, Marko Zec wrote: > On Sunday 20 May 2012 19:34:26 Alan Cox wrote: > ... >>> In any case, I wish to be certain that a particular kmem virtual address >>> range is mapped to superpages - how can I enforce that at malloc time, >>> and / or find out later if I really got my kmem mapped to superpages? >>> Perhaps vm_map_lookup() could provide more info, but I'm wondering if >>> someone already wrote a wrapper function for that, which takes only the >>> base virtual address as a single argument? >> Try using pmap_mincore() to verify that the mappings are superpages. > flags = pmap_mincore(vmspace_pmap(curthread->td_proc->p_vmspace), > (vm_offset_t) addr)); > > OK, that works, and now I know my kmem chunk is on a superpage, horray!!! > Thanks! > >>> BTW, apparently malloc(size, M_TEMP, M_NOWAIT) requests fail for size> >>> 1G, even at boot time. Any ideas how to circumvent that (8.3-STABLE, >>> amd64, 4G physical RAM)? >> I suspect that you need to increase the size of your kmem map. > Huh any hints how should I achieve that? In desperation I placed > > vm.kmem_size=8G > > in /boot/loader.conf and got this: > > vm.kmem_map_free: 8123924480 > vm.kmem_map_size: 8364032 > vm.kmem_size_scale: 1 > vm.kmem_size_max: 329853485875 > vm.kmem_size_min: 0 > vm.kmem_size: 8132288512 > > but malloc(2G) still fails... Here is at least one reason why it fails: void * uma_large_malloc(int size, int wait) Note the type of "size". Can you malloc 1GB? From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 23:29:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E4F31065675; Sun, 20 May 2012 23:29:52 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 159248FC14; Sun, 20 May 2012 23:29:51 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Mon, 21 May 2012 01:29:50 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 01:29:20 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 01:29:20 +0200 From: Marko Zec To: Alan Cox Date: Mon, 21 May 2012 01:29:14 +0200 User-Agent: KMail/1.9.10 References: <201205200901.32613.zec@fer.hr> <201205210048.16877.zec@fer.hr> <4FB97A41.70405@rice.edu> In-Reply-To: <4FB97A41.70405@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201205210129.14718.zec@fer.hr> X-OriginalArrivalTime: 20 May 2012 23:29:20.0682 (UTC) FILETIME=[61E898A0:01CD36E0] Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 23:29:52 -0000 On Monday 21 May 2012 01:12:01 Alan Cox wrote: ... > >>> BTW, apparently malloc(size, M_TEMP, M_NOWAIT) requests fail for size> > >>> 1G, even at boot time. Any ideas how to circumvent that (8.3-STABLE, > >>> amd64, 4G physical RAM)? > >> > >> I suspect that you need to increase the size of your kmem map. > > > > Huh any hints how should I achieve that? In desperation I placed > > > > vm.kmem_size=8G > > > > in /boot/loader.conf and got this: > > > > vm.kmem_map_free: 8123924480 > > vm.kmem_map_size: 8364032 > > vm.kmem_size_scale: 1 > > vm.kmem_size_max: 329853485875 > > vm.kmem_size_min: 0 > > vm.kmem_size: 8132288512 > > > > but malloc(2G) still fails... > > Here is at least one reason why it fails: > > void * > uma_large_malloc(int size, int wait) > > Note the type of "size". Can you malloc 1GB? Uff, good catch... malloc(1G) works, malloc(1.99G) works, malloc(2G) doesn't! Anyhow, malloc(1G) is big enough for what I want to do ATM, I was just curious why it breaks with bigger requests. Thanks, Marko From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 06:45:38 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50600106566B; Mon, 21 May 2012 06:45:38 +0000 (UTC) (envelope-from alienablel71@axsone.com) Received: from ltea-178-013-129-170.pools.arcor-ip.net (ltea-178-013-129-170.pools.arcor-ip.net [178.13.129.170]) by mx1.freebsd.org (Postfix) with ESMTP id F3B1C8FC17; Mon, 21 May 2012 06:45:36 +0000 (UTC) Received: from apache by kckigafiemjjdkha.uky.edu with local (Exim 4.63) (envelope-from <, , , >) id 680CPX-YSSF77-VS for , , , ; Mon, 21 May 2012 07:45:37 +0100 To: , , , Date: Mon, 21 May 2012 07:45:37 +0100 From: , , , Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-2" Cc: Subject: We invite you to work in your spare time for $ 100 per hour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 06:45:38 -0000 We invite you to work in the remote assistant position. This work takes 2-3 hours per week and requires absolutely no investment. The essence of this work for incoming client requests in your city. The starting salary is about 2500 EUR per month + bonuses. You get paid your salary every 2 weeks and your bonuses after fulfilling each task! We guarantee work for everyone. But we accept applications this week only! Therefore, you should write a request right now. And you will start earning money, starting from next week. Please indicate in the request: Your name: Your email address: City of residence: Please send the request to my email Mario@jobmarketeurope.com and I will answer you personally as soon as possible Sincerely, Mario Hargrove From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 10:46:39 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13B89106566C for ; Mon, 21 May 2012 10:46:39 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id BBF1B8FC1B for ; Mon, 21 May 2012 10:46:38 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SWQ8F-000DFt-QM for hackers@freebsd.org; Mon, 21 May 2012 13:46:32 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 May 2012 13:46:31 +0300 From: Daniel Braniss Message-ID: Cc: Subject: USB over IP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 10:46:39 -0000 I need to control some lab equipment with several usb based controllers (mostly serial) and was wondering if it can be done over IP, there is such a thing called usbip, but couldn't find what 'server' is needed. all the boxes I found are not cheep, but worse, only provide binaries for windows, or linux. cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 11:27:00 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DBD71065670 for ; Mon, 21 May 2012 11:27:00 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id 765AD8FC1A for ; Mon, 21 May 2012 11:26:59 +0000 (UTC) Received: (qmail 3922 invoked by uid 1004); 21 May 2012 11:27:31 -0000 Message-ID: <4FBA25DE.4050500@uffe.org> Date: Mon, 21 May 2012 13:24:14 +0200 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: hackers@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: USB over IP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 11:27:00 -0000 Hi, On 2012-05-21 12:46, Daniel Braniss wrote: > I need to control some lab equipment with several usb based controllers > (mostly serial) and was wondering if it can be done over IP, there is such a > thing called usbip, but couldn't find what 'server' is needed. > all the boxes I found are not cheep, but worse, only provide binaries > for windows, or linux. I'm not entirely sure about your setup - you write usb based controllers - and then mostly serial... I know it is not strictly speaking usb over ip - but did you look at RFC 2217 ? https://tools.ietf.org/html/rfc2217 There are several projects supporting RFC 2217: http://ser2net.sourceforge.net/ http://sourceforge.net/projects/sercd/ http://sourceforge.net/projects/cyclades-serial/ "ser2net" and "sredird" are in FreeBSD ports: http://www.freshports.org/comms/ser2net/ http://www.freshports.org/comms/sredird/ /Uffe From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 12:24:53 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4EF9106566C for ; Mon, 21 May 2012 12:24:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 77DD58FC0A for ; Mon, 21 May 2012 12:24:53 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SWRfP-000EaY-2P; Mon, 21 May 2012 15:24:51 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Uffe Jakobsen In-reply-to: <4FBA25DE.4050500@uffe.org> References: <4FBA25DE.4050500@uffe.org> Comments: In-reply-to Uffe Jakobsen message dated "Mon, 21 May 2012 13:24:14 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 May 2012 15:24:51 +0300 From: Daniel Braniss Message-ID: Cc: hackers@freebsd.org Subject: Re: USB over IP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 12:24:53 -0000 > > > Hi, > > On 2012-05-21 12:46, Daniel Braniss wrote: > > I need to control some lab equipment with several usb based controllers > > (mostly serial) and was wondering if it can be done over IP, there is such a > > thing called usbip, but couldn't find what 'server' is needed. > > all the boxes I found are not cheep, but worse, only provide binaries > > for windows, or linux. > > I'm not entirely sure about your setup - you write usb based controllers > - and then mostly serial... > I know, the word serial is confusing, what I meant is that the USB connection (which could be a mass-storage, camera, etc) is in my case serial (ie rs232) > I know it is not strictly speaking usb over ip - but did you look at RFC > 2217 ? yes, but it's not relevant to what I'm looking for, I want to send/receive the USB protocol over IP. I only mentioned the serial (rs232) because I don't need speed (as opposed to a camera, audio, etc) cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 12:36:23 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F46F1065672 for ; Mon, 21 May 2012 12:36:23 +0000 (UTC) (envelope-from dgre090@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D50A18FC0A for ; Mon, 21 May 2012 12:36:22 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so7401311pbb.13 for ; Mon, 21 May 2012 05:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8la7EA55O3l1FqvCD4756LiHtk7V+0tsVoxFObdfk6Y=; b=HtFwYAGFxHdJX7Wvp4FgkoRodcbTdelqvnJn8VZaaLpPtx/3WgcjKGNEC3NIgbXdP+ kGcwhW1T2NDsBMHH/ME5pRBz5N4FlzsFxuwPlQidpafg5uxZXDNU4pS4k8o411577gAW nuQK75mKzdaVwxIKvoDNLkEWdqLWnmGCccEtnDmAQg3gO89EPedzbmJD727xaxZOCPJv 19od/ykvqPdnLcOL3IqZTIm4YwoWENQdWkRex6O2c7l8dzzFK3Dlx1O9SheXs7GFei1J wyg2ZI4fxCtE4Ti3WG7nKj+U1u0PQvBt6TDSRYzFMRhdUsBxgDB1NjZU3zp/02JypqHz MaxQ== MIME-Version: 1.0 Received: by 10.68.132.201 with SMTP id ow9mr67760029pbb.160.1337603782433; Mon, 21 May 2012 05:36:22 -0700 (PDT) Received: by 10.66.221.197 with HTTP; Mon, 21 May 2012 05:36:22 -0700 (PDT) In-Reply-To: References: <4FBA25DE.4050500@uffe.org> Date: Mon, 21 May 2012 14:36:22 +0200 Message-ID: From: Daniel Grech To: Daniel Braniss Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org, Uffe Jakobsen Subject: Re: USB over IP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 12:36:23 -0000 something similar is being done in the latest versions of qemu. There is a usb redirection module which is in the form of a client/server architecture where USB packets are sent over IP. These two modules communicate with eachother through a protocol developed specifically for the redirection of USB devices over IP so if I were you I would have a look at the qemu code for some ideas. On Mon, May 21, 2012 at 2:24 PM, Daniel Braniss wrote: > > > > > > Hi, > > > > On 2012-05-21 12:46, Daniel Braniss wrote: > > > I need to control some lab equipment with several usb based controllers > > > (mostly serial) and was wondering if it can be done over IP, there is > such a > > > thing called usbip, but couldn't find what 'server' is needed. > > > all the boxes I found are not cheep, but worse, only provide binaries > > > for windows, or linux. > > > > I'm not entirely sure about your setup - you write usb based controllers > > - and then mostly serial... > > > I know, the word serial is confusing, what I meant is that the USB > connection > (which could be a mass-storage, camera, etc) is in my case serial (ie > rs232) > > > I know it is not strictly speaking usb over ip - but did you look at RFC > > 2217 ? > yes, but it's not relevant to what I'm looking for, I want to send/receive > the USB protocol over IP. I only mentioned the serial (rs232) because I > don't > need speed (as opposed to a camera, audio, etc) > > cheers, > danny > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 13:36:09 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AFBC106566B for ; Mon, 21 May 2012 13:36:09 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1B34C8FC0A for ; Mon, 21 May 2012 13:36:09 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SWSmN-000FgV-8k; Mon, 21 May 2012 16:36:07 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Daniel Grech In-reply-to: References: <4FBA25DE.4050500@uffe.org> Comments: In-reply-to Daniel Grech message dated "Mon, 21 May 2012 14:36:22 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 May 2012 16:36:07 +0300 From: Daniel Braniss Message-ID: Cc: hackers@freebsd.org, Uffe Jakobsen Subject: Re: USB over IP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 13:36:09 -0000 > --047d7b10ce794d5a1004c08b261e > Content-Type: text/plain; charset=ISO-8859-1 > > something similar is being done in the latest versions of qemu. There is a > usb redirection module which is in the form of a client/server architecture > where USB packets are sent over IP. These two modules communicate with > eachother through a protocol developed specifically for the redirection of > USB devices over IP so if I were you I would have a look at the qemu code > for some ideas. do you know if there is a description of the protocol (rfc?) like there is for iscsi, or ata ip? there is alos the usbip project for linux, maybe it can be ported ... cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 14:34:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F03B106566B; Mon, 21 May 2012 14:34:18 +0000 (UTC) (envelope-from shuffleboard7@greaterlouisville.com) Received: from mail.lincolnassoc.com (mail.lincolnassoc.com [69.15.40.194]) by mx1.freebsd.org (Postfix) with ESMTP id DA4888FC1A; Mon, 21 May 2012 14:34:17 +0000 (UTC) Received: from 69.15.40.194(helo=freebsd.org) by freebsd.org with esmtpa (Exim 4.69) (envelope-from ) id 1MM1RQ-4944px-CB for ; Mon, 21 May 2012 09:34:18 -0500 From: , , , To: , , , Date: Mon, 21 May 2012 09:34:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: yvepimf_51 Message-ID: <6430424134.DLG65TG4508630@jurnt.dxefsnzwkph.tv> Cc: Subject: We invite you to a remote job $ 100 per hour helping sick people X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 14:34:18 -0000 We invite you to work in the remote assistant position. This work takes 2-3 hours per week and requires absolutely no investment. The essence of this work for incoming client requests in your city. The starting salary is about 2500 EUR per month + bonuses. You get paid your salary every 2 weeks and your bonuses after fulfilling each task! We guarantee work for everyone. But we accept applications this week only! Therefore, you should write a request right now. And you will start earning money, starting from next week. Please indicate in the request: Your name: Your email address: City of residence: Please send the request to my email Ahmed@topeuropajobs.com,and I will answer you personally as soon as possible Sincerely, Ahmed Hurst From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 13:47:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59FC31065670; Mon, 21 May 2012 13:47:56 +0000 (UTC) (envelope-from dwindsor@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6CA8FC18; Mon, 21 May 2012 13:47:54 +0000 (UTC) Received: by werg1 with SMTP id g1so4190212wer.13 for ; Mon, 21 May 2012 06:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=F4DZpLFC0dHIT9uEwYSWZElvWqepdi++zNk8IQ/LO78=; b=Bhxwiz6H5vvjTUyWE5GzXR0eKfuLGD889QPZGXlI7yom74uAl+bFfrS4r/4uZselIQ FcytGvEum4/0eSDtAwJ7UR1CBKhg48xfbyRtLW3ynCx3vkuLElXF4+N4t/XOD7w/2j6z SXQUMLpsiGGpt/ACwNDs7pmljPWKqIA4qhDXQCfRUyUCAOkbXVd4dr4MkmEY/zn1t2AI Tg6UD64jgSzkB37C0DGy8TuST6AIDHuX9ZDEdyn4dxqfveB8X/t+EBgtoy59VnoFslHG yLBvaoBDeA0FBnfoHjhyFISTDJsKj9xj2UAfCK97m55pJKC/WuexYLP8WQa8mxEJAmi5 vrMw== MIME-Version: 1.0 Received: by 10.180.107.99 with SMTP id hb3mr25671078wib.0.1337608073978; Mon, 21 May 2012 06:47:53 -0700 (PDT) Received: by 10.194.59.107 with HTTP; Mon, 21 May 2012 06:47:53 -0700 (PDT) Date: Mon, 21 May 2012 09:47:53 -0400 Message-ID: From: David Windsor To: freebsd-jail@freebsd.org X-Mailman-Approved-At: Mon, 21 May 2012 15:23:41 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: PID/UID namespaces X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 13:47:56 -0000 Hi, While doing some research on FreeBSD jails, I came across an item in the jails' TODO: - be able to have a separate PID space for it - be able to specify a separate UID space for it In other projects, these goals have been accomplished using namespaces. I tried to see if PID/UID namespaces existed in BSD and came across something called Capsicum, a sandboxing project which does not appear to implement outright namespaces for descriptors like PID/UID, but uses something called a "Process Descriptor." Is namespacing of PIDs and UIDs an eventual goal of the jails project of FreeBSD? Thanks, David PS: Excuse my ignorance of anything related to BSD, as I come from a Linux background. -- PGP: 6141 5FFD 11AE 9844 153E F268 7C98 7268 6B19 6CC9 From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 16:21:32 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55916106566B for ; Mon, 21 May 2012 16:21:32 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 34B648FC08 for ; Mon, 21 May 2012 16:21:32 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta04.emeryville.ca.mail.comcast.net with comcast id CgAz1j0041u4NiLA4gLSef; Mon, 21 May 2012 16:20:26 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta21.emeryville.ca.mail.comcast.net with comcast id CgLQ1j00X4NgCEG8hgLRoQ; Mon, 21 May 2012 16:20:26 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q4LGKLN3001910; Mon, 21 May 2012 10:20:21 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Svatopluk Kraus In-Reply-To: References: <1337285248.1503.308.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 May 2012 10:20:21 -0600 Message-ID: <1337617221.2516.38.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Richard Hodges , freebsd-arm@freebsd.org, hackers@freebsd.org Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 16:21:32 -0000 On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote: > On Thu, May 17, 2012 at 10:07 PM, Ian Lepore > wrote: > > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: > >> Hi, > >> > >> I'm working on DMA bus implementation for ARM11mpcore platform. I've > >> looked at implementation in ARM tree, but IMHO it only works with some > >> assumptions. There is a problem with DMA on memory block which is not > >> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. > >> > >> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > >> Then first cache line associated with the buffer can be divided into > >> two parts, A and B, where A is a memory we know nothing about it and B > >> is buffer memory. The same stands for last cache line associatted with > >> the buffer. We have no problem if a memory is coherent. Otherwise it > >> depends on memory attributes. > >> > >> 1. [no cache] attribute > >> No problem as memory is coherent. > >> > >> 2. [write throught] attribute > >> The part A can be invalidated without loss of any data. It's not problem too. > >> > >> 3. [write back] attribute > >> In general, there is no way how to keep both parts consistent. At the > >> start of DMA transaction, the cache line is written back and > >> invalidated. However, as we know nothing about memory associated with > >> part A of the cache line, the cache line can be filled again at any > >> time and messing up DMA transaction if flushed. Even if the cache line > >> is only filled but not flushed during DMA transaction, we must make it > >> coherent with memory after that. There is a trick with saving part A > >> of the line into temporary buffer, invalidating the line, and > >> restoring part A in current ARM (MIPS) implementation. However, if > >> somebody is writting to memory associated with part A of the line > >> during this trick, the part A will be messed up. Moreover, the part A > >> can be part of another DMA transaction. > >> > >> To safely use DMA with no coherent memory, a memory with [no cache] or > >> [write throught] attributes can be used without problem. A memory with > >> [write back] attribute must be aligned on CACHE_LINE_SIZE. > >> > >> However, for example mbuf, a buffer for DMA can be part of a structure > >> which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We > >> can know that nobody will write to the structure during DMA > >> transaction, so it's safe to use the buffer event if it's not aligned > >> on CACHE_LINE_SIZE. > >> > >> So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > >> we want to avoid bounce pages overhead, we must support additional > >> information to DMA transaction. It should be easy to support the > >> information about drivers data buffers. However, what about OS data > >> buffers like mentioned mbufs? > >> > >> The question is following. Is or can be guaranteed for all or at least > >> well-known OS data buffers which can be part of DMA access that the > >> not CACHE_LINE_SIZE aligned buffers are surrounded by data which > >> belongs to the same object as the buffer and the data is not written > >> by OS when given to a driver? > >> > >> Any answer is appreciated. However, 'bounce pages' is not an answer. > >> > >> Thanks, Svata > > > > I'm adding freebsd-arm@ to the CC list; that's where this has been > > discussed before. > > > > Your analysis is correct... to the degree that it works at all right > > now, it's working by accident. At work we've been making the good > > accident a bit more likely by setting the minimum allocation size to > > arm_dcache_align in kern_malloc.c. This makes it somewhat less likely > > that unrelated objects in the kernel are sharing a cache line, but it > > also reduces the effectiveness of the cache somewhat. > > > > Another factor, not mentioned in your analysis, is the size of the IO > > operation. Even if the beginning of the DMA buffer is cache-aligned, if > > the size isn't exactly a multiple of the cache line size you still have > > the partial flush situation and all of its problems. > > > > It's not guaranteed that data surrounding a DMA buffer will be untouched > > during the DMA, even when that surrounding data is part of the same > > conceptual object as the IO buffer. It's most often true, but certainly > > not guaranteed. In addition, as Mark pointed out in a prior reply, > > sometimes the DMA buffer is on the stack, and even returning from the > > function that starts the IO operation affects the cacheline associated > > with the DMA buffer. Consider something like this: > > > > void do_io() > > { > > int buffer; > > start_read(&buffer); > > // maybe do other stuff here > > wait_for_read_done(); > > } > > > > start_read() gets some IO going, so before it returns a call has been > > made to bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) and an invalidate gets > > done on the cacheline containing the variable 'buffer'. The act of > > returning from the start_read() function causes that cacheline to get > > reloaded, so now the stale pre-DMA value of the variable 'buffer' is in > > cache again. Right after that, the DMA completes so that ram has a > > newer value that belongs in the buffer variable and the copy in the > > cacheline is stale. > > > > Before control gets into the wait_for_read_done() routine that will > > attempt to handle the POSTREAD partial cacheline flush, another thread > > gets control and begins setting up a new DMA for another device, > > different buffer. This time it's a read using a 64K buffer for disk IO. > > The busdma sync code calls cpu_dcache_inv_range() for that buffer but > > because the range is so large, it gets turned into a > > cpu_dcache_wbinv_all() because that's cheaper than looping through an > > arbitrarily large range invalidating a line at a time. > > > > Except, ooops, that means we write back to ram the cacheline holding the > > stale value of the 'buffer' variable, wiping out the data brought in by > > DMA before the partial cachline flush code could do its dance to > > preserve it. > > > > There are several variations of the above scenario; it doesn't require a > > stack-allocated buffer to trigger a writeback of a stale value. Any > > cacheline that gets dirtied after a PREREAD invalidate can end up > > overwriting fresh DMA data in ram with stale data from the cacheline at > > any time, because any call to cpu_dcache_inv_range() or > > cpu_dcache_wbinv_range() can get turned into a cpu_dcache_wbinv_all(). > > That means any DMA operation and also a context switch which calls > > cpu_dcache_wbinv_all(). > > > > If you rule out bounce buffers as a solution, then I think that may > > leave us with just one option: make the pages uncacheable for the > > duration of the DMA. Essentially force a DMA_COHERENT buffer if the > > driver didn't already do so. I think doing so blindly may have > > performance implications every bit as bad as using bounce buffers. (For > > example, turning off cache on a stack page could really hurt.) The code > > to do the remapping already exists in pmap.c as part of handling > > multiple mappings for VIVT caches. From the busdma code you could > > accomplish the remapping by making a temporary writable kernel mapping > > for the buffer pages in the PRE handling and undo that mapping in the > > POST handling. > > > > It may be that a hybrid approach would work. For an unaligned buffer, > > if it isn't already DMA_COHERENT, then if it is below a certain size > > bounce it, otherwise remap the buffer's pages. When I was knee-deep in > > this problem last summer one of the things I noticed in our systems was > > that large DMA operations (1 KByte or larger buffers) tend to be > > DMA_COHERENT buffers, and when not they're already cache aligned and a > > power of two in size. For us the partial cacheline flush situations are > > almost always caused by tiny IO of 1 to 128 bytes length, usually > > serial-comms or usb related. > Good to know. > > > > > I think pre-allocating a few pages for bouncing small unaligned IO would > > be a big win compared to remapping the pages as uncacheable. The > > remapping has to take locks and search lists of pages and so on; it > > should be way faster to do a small memcpy() instead. Buffers bigger > > than some (perhaps tunable) limit would get remapped instead of > > bounced. > > > > It also might be nice to have a knob to enable logging when bouncing or > > remapping is used to avoid partial cacheline operations, to make it easy > > to find drivers that could be tweaked for better performance. If you're > > bouncing 2 or 3 operations per second with a 4-byte buffer that's no big > > deal. If every network packet is resulting in bouncing/remapping you'd > > want to know about that. > It sounds resonable for me. > > > > > -- Ian > > Thanks for replies. > > So, we have to check DMA buffers if they are aligned and if not, we > have two possibilies in general. > > 1. To not assume anything about surrounding data around unaligned DMA > buffer at all. This always leads to bouncing or memory attributes > changing in no coherent case. > I think this is the only safe starting assumption. Even if every driver in the current source base is fixed, there are 3rd party drivers that aren't checked in, and also it's possible that the IO buffers are in userspace and it's impossible for the kernel to make any assumptions about how the surrounding memory is being accessed during the IO. At work we have several proprietary drivers that do IO directly to/from userspace buffers. > 2. To add new flag (something like BUS_DMA_UNALIGNED_SAFE) and set it > in dmamap load functions in cases that we know it's safe to use an > unaligned buffer. This way we can avoid bouncing in some cases. > This seems like it could be a useful optimization for a driver that can't afford the performance hit of the automatic handling from item 1 above. It also seems like it could be a "please shoot me in the foot" flag if it's used unwisely (or, more likely, if code is blindly cloned from an existing driver that does use it wisely into a new driver where it's not appropriate). > I didn't know about drivers that are using DMA buffers on stack. > However, to patch such a driver is something I can do on my own. I.e., > I always can decide that a driver buffer is safe for DMA even > unaligned. Moreover, for example, DMA descriptors rings are defined as > an array in some net drivers and a descriptor size could be smaller > than CACHE_LINE_SIZE. The drivers must be modified anyway to made > descriptors coherent or aligned. > > What I can do in a driver it's not so simple in case of OS buffers > like mbufs. I can check how mbufs are used in current implementation > and say, yes, it's safe to use them unaligned. However, it can be > changed in next release if anybody won't take care of it. It would be > nice to have a maintained list of OS buffers which are DMA safe in > respect of CACHE_LINE_SIZE. Is the flag and the list interesting for > somebody else? > I don't have a definitive answer for this, but my assumption has always been that once an mbuf is handed to a driver (for example, when it's added to an interface's send queue), the driver then "owns" that mbuf and nothing else in the system will touch it until the driver makes a call to hand it off or free it. If that assumption is true, a driver could make good use of a BUS_DMA_UNALIGNED_SAFE flag with mbufs. The part that scares me about my assumption is the m_ext.ref_cnt field of the mbuf. Its existance seems to imply that multiple entities concurrently have an interest in the data. On the other hand, the lack of any built in provisions for locking seems to imply that concurrent access isn't happening, or perhaps it implies that any required synchronization is temporal rather than lock-based. I've never found anything in writing that explains mbuf usage conventions at this level of detail. > Some more notes. > > SMP makes things worse and ARM11mpcore is about SMP too. For example, > another thread could be open about that how to flush caches (exclusive > L1 cache) in SMP case. > > I'm not sure how to correctly change memory attributes on page which > is in use. Making new temporary mapping with different attributes is > wrong and does not help at all. It's question how to do TLB and cache > flushes on two and more processors and be sure that everything is OK. > It could be slow and maybe, changing memory attributes on the fly is > not a good idea at all. > My suggestion of making a temporary writable mapping was the answer to how to correctly change memory attributes on a page which is in use, at least in the existing code, which is for a single processor. You don't need, and won't even use, the temporary mapping. You would make it just because doing so invokes logic in arm/arm/pmap.c which will find all existing virtual mappings of the given physical pages, and disable caching in each of those existing mappings. In effect, it makes all existing mappings of the physical pages DMA_COHERENT. When you later free the temporary mapping, all other existing mappings are changed back to being cacheable (as long as no more than one of the mappings that remain is writable). I don't know that making a temporary mapping just for its side effect of changing other existing mappings is a good idea, it's just a quick and easy thing to do if you want to try changing all existing mappings to non-cacheable. It could be that a better way would be to have the busdma_machdep code call directly to lower-level routines in pmap.c to change existing mappings without making a new temporary mapping in the kernel pmap. The actual changes to the existing mappings are made by pmap_fix_cache() but that routine isn't directly callable right now. Also, as far as I know all of this automatic disabling of cache for multiple writable mappings applies only to VIVT cache architectures. I'm not sure how the pmap code is going to change to support VIPT and PIPT caches, but it may no longer be true that making a second writable mapping of a page will lead to changing all existing mappings to non-cacheable. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 16:18:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A6531065670 for ; Mon, 21 May 2012 16:18:38 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm26-vm3.bullet.mail.ne1.yahoo.com (nm26-vm3.bullet.mail.ne1.yahoo.com [98.138.91.156]) by mx1.freebsd.org (Postfix) with SMTP id 4629E8FC1D for ; Mon, 21 May 2012 16:18:38 +0000 (UTC) Received: from [98.138.90.48] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2012 16:18:32 -0000 Received: from [98.138.87.3] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2012 16:18:32 -0000 Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 21 May 2012 16:18:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 281355.94203.bm@omp1003.mail.ne1.yahoo.com Received: (qmail 65525 invoked by uid 60001); 21 May 2012 16:18:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337617112; bh=isxGUQhWtoyp3sClI2aWB+6Sn7DRKeebzY0I3siJUcY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fHhNg5lfTRLYFm0cTfj7bib58OW8eUDxNR8ugNnD+8ttM9Vb7u4qjyz68aUldv8vqmz1AuOy2qJsKRJb9q473IJog0ahuoBde1R0PfZkUyGknq88d/hGkfEI7cA7Tb3H0K9c6D/1vYVrpA+DwZwL902XTn1FxzoUNl9ARgXijgc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sww3OYnDUlFju5foJEma79BEnp1HvWnaeQNd8YkwTrlKA9Kx2vgW2pwADHeFLsYXQi4eKKAJf8fjMhMJSaoB5KdESWe/iY29bZKjLLE6kLA8ZVsQvPDtq9iJfKzEWZfVp86oiz9/toB/yF74D8h2tpOP0MokikKbeblfQvwD9yA=; X-YMail-OSG: a0Og5l8VM1nqSYx1Co21.U9gVVbAQcbbOG7Kc_68b8LH48v eBwA.3PQupTemI24aC5OJ1AaxKEwrhHEk2M0aEwn.YErf09o1qeN1buPYaZK xpUZ89x8puuREdVZn36FqmboEhtEHcbcV3q3C_AxJ1OF6yMDoeB4Z_vizONm cvIULz9Z6uy7SF9uyRMouqNEBUa8VrmlNfJJjT3sdes5eRu2_a_Kqo81TXYd p_nYeGHwyLi_wTkixNpkqY08_utN2SdoFdogC4Ez3g2boQSnLT5SenBpyMQK h4iBd94GhzpTqjKpfksDSU55ZTbAB2H0JTe8EnEkqzOTrjd2ZyHVMCTcGAvV W4Te_0InolOo2liM4WvC_UH0lUUPft3YfpBwoI8wDkAmE.OzkQlTvNot8neM m14f0_WiAi8tvbA9ydrl0rqZWnzjdEfsXs6tUOXwViCe1pUnakg-- Received: from [173.164.238.34] by web122505.mail.ne1.yahoo.com via HTTP; Mon, 21 May 2012 09:18:32 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337617112.24292.YahooMailClassic@web122505.mail.ne1.yahoo.com> Date: Mon, 21 May 2012 09:18:32 -0700 (PDT) From: Jason Usher To: Jason Hellenthal In-Reply-To: <20120517232238.GA91365@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 May 2012 16:33:43 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 16:18:38 -0000 =0AFolks,=0A=0AIs there a better list for this - perhaps freebsd-security ?= =0A=0AI originally posted to -hackers because it *appears* that reverting "= rsa, then dsa" to "dsa, then rsa" was a simple change to myproposal.h, but = since that doesn't work, and since I haven't gotten any replies here ...=0A= =0AThoughts ?=0A=0A=0A--- On Thu, 5/17/12, Jason Hellenthal wrote:=0A=0A> > > > I have some old 6.x FreeBSD systems that need= =0A> their=0A> > > OpenSSH upgraded.=0A> > > > =0A> > > > Everything goes j= ust fine, but when I am=0A> done, existing=0A> > > clients are now presente= d with this message:=0A> > > > =0A> > > > =0A> > > > WARNING: DSA key found= for host hostname=0A> > > > in /root/.ssh/known_hosts:12=0A> > > > DSA key= fingerprint=0A> 4c:29:4b:6e:b8:6b:fa:49.......=0A> > > > =0A> > > > The au= thenticity of host 'hostname=0A> (10.1.2.3)' can't be=0A> > > established= =0A> > > > but keys of different type are already known=0A> for this=0A> > = > host.=0A> > > > RSA key fingerprint is=0A> a3:22:3d:cf:f2:46:09:f2......= =0A> > > > Are you sure you want to continue connecting=0A> (yes/no)=0A> > = > > =0A> > > =0A> > > You must be using different keys for your server=0A> = than the=0A> > > one that has=0A> > > been generated before the upgrade. Ju= st copy your=0A> keys over=0A> > > to the new=0A> > > location and restart = the server daemon and you=0A> should be=0A> > > fine.=0A> > > =0A> > > copy= /etc/ssh/* -> /usr/local/etc/ssh/=0A> > =0A> > =0A> > You didn't read that= error message.=0A> =0A> Sorry I misread that. Decieving message...=0A> =0A= > > =0A> > That is not the standard "key mismatch" error that you=0A> assum= ed it was.=A0 Look at it again - it is saying that=0A> we do have a key for= this server of type DSA, but the client=0A> is receiving one of type RSA, = etc.=0A> > =0A> > The keys are the same - they have not changed at all -=0A= > they are just being presented to clients in the reverse=0A> order, which = is confusing them and breaking automated,=0A> key-based login.=0A> > =0A> >= I need to take current ssh server behavior (rsa, then=0A> dss) and change = it back to the old order (dss, then rsa).=0A> =0A> Have you attempted to ch= ange that order via sshd_config and=0A> placing the=0A> DSA directive befor= e the RSA one ?=0A> =0A> =0A> -- =0A> =0A> - (2^(N-1))=0A> From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 16:41:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30D601065677; Mon, 21 May 2012 16:41:54 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3922F8FC23; Mon, 21 May 2012 16:41:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=I2Yk5ShcxO8I5YmHjGdt1oy0JLGatJBu3bSukJzztZA=; b=AD8Ks0kb7IVZehINEb53evCenPc1YfnPPd/e9tapU/TgDkY3lcrwWom7CZQ5rUjG2PdcfWrxHr7VGw27Tw7LzP3I2zjR1sqJFWie8KFuMX1Lrp6BDGwkrB2g3D7pqzfK; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWVg9-0005cb-Aa; Mon, 21 May 2012 11:41:53 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1337618507-3288-3287/5/16; Mon, 21 May 2012 16:41:47 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org References: Date: Mon, 21 May 2012 11:41:46 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: User-Agent: Opera Mail/11.64 (FreeBSD) X-SA-Score: -1.5 Cc: Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 16:41:55 -0000 OK guys I've been talking with another user who can recreate this crash and the last bit of information we've learned seems to be leaning towards interrupts/IRQ issues like someone (bz@ perhaps?) suggested. I'm still trying to test this myself, but the other user was able to recreate my crash pretty much on demand. The fix was to not use the first NIC in the VM because it will always share an IRQ with mpt0. Once mpt0 is on its own the crash does not seem to be reproducible anymore. Before: $ vmstat -i interrupt total rate irq1: atkbd0 378 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1 687237 1 irq18: em0 mpt0 319094024 539 cpu0: timer 236770821 400 Total 556552503 940 After: $ vmstat -i interrupt total rate irq1: atkbd0 38 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1 2811 15 irq17: em2 5 0 cpu0: timer 71013 398 irq256: mpt0 12163 68 Total 86073 483 Is there any other way we can make mpt0 get its own dedicated IRQ without having to do this? The problem is that it causes us to have to make rc.conf changes, pf.conf changes, and who knows what other software could be on these machines that is trying to bind to a specific NIC... Thanks! From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 16:41:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 244C31065677; Mon, 21 May 2012 16:41:57 +0000 (UTC) (envelope-from shen.elf@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id E76418FC1F; Mon, 21 May 2012 16:41:56 +0000 (UTC) Received: by dadv36 with SMTP id v36so7585102dad.13 for ; Mon, 21 May 2012 09:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=xKtPay+agdjIV6e7j6OYFkg1svxCrHDSthDs08OIL4w=; b=WiKQ7H3rpN9vz3R+loIhXwkA6fhEhz0c/8to6wfNzauAOgR2wLsUtsVcAIPEy4YaAB Y+0ZjHx64ZQdPI/Uz5IsbYzLdWKuFf2AWdF8D3p6QCtIPbCM9Bi/DFg8MbPh8Z47vAA/ Hpt1sG/FlL9edEgQO6WNqdU1ZEchMYwQeluFUkT3rPkAUR+SdvbCh1wHKfLrZSYlq73C z6Tfsi2NmLCAPq98GmnunjzT+jUI0/ZufoK5wUXW1Wa8ZDkTAZ0ohw5yZPnd7XUgRv1R 2szEGdSmcnxB9xhuhF3FYdjIH+sTPSJQfQGxDNiDjrULRMKUUgwcfwVaBPmoObC6kBhz Js3A== MIME-Version: 1.0 Received: by 10.68.240.71 with SMTP id vy7mr12283326pbc.78.1337618516389; Mon, 21 May 2012 09:41:56 -0700 (PDT) Received: by 10.142.149.5 with HTTP; Mon, 21 May 2012 09:41:56 -0700 (PDT) Date: Tue, 22 May 2012 00:41:56 +0800 Message-ID: From: Yanhui Shen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Something wrong with curs_threads(3X) ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 16:41:57 -0000 Hi, In curs_threads(3X), at the beginning of the manual: typedef int (*NCURSES_WINDOW_CB)(WINDOW *, void *); typedef int > (*NCURSES_SCREEN_CB)(SCREEN *, void *); > int set_escdelay(int size); > int set_tabsize(int size); > int use_screen(SCREEN *scr, NCURSES_WINDOW_CB func, void *data); > int use_window(WINDOW *win, NCURSES_SCREEN_CB func, void *data); use_screen => NCURSES_WINDOW_CB use_window = > NCURSES_SCREEN_CB Target is not matched, I'm really confused. So I open /usr/include/curses.h, and find these: extern NCURSES_EXPORT(int) use_screen (SCREEN *, NCURSES_SCREEN_CB, void *); > extern NCURSES_EXPORT(int) use_window (WINDOW *, NCURSES_WINDOW_CB, void > *); Seems much proper. So is this a bug? -- Best regards, Yanhui Shen From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 17:06:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 093F41065679; Mon, 21 May 2012 17:06:57 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from mail.averesystems.com (50-73-27-109-cpennsylvania.hfc.comcastbusiness.net [50.73.27.109]) by mx1.freebsd.org (Postfix) with ESMTP id C91A48FC1E; Mon, 21 May 2012 17:06:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.averesystems.com (Postfix) with ESMTP id 04B994801C4; Mon, 21 May 2012 13:01:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.averesystems.com Received: from mail.averesystems.com ([127.0.0.1]) by localhost (mail.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBtSQY8W+wMT; Mon, 21 May 2012 13:01:22 -0400 (EDT) Received: from riven.arriad.com (206.193.225.214.nauticom.net [206.193.225.214]) by mail.averesystems.com (Postfix) with ESMTPSA id A2B444801BE; Mon, 21 May 2012 13:01:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: Date: Mon, 21 May 2012 13:01:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <490F2075-3E4D-4F85-9935-937CED8FB10B@averesystems.com> References: To: Mark Felder X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:06:57 -0000 On May 21, 2012, at 12:41 PM, Mark Felder wrote: > OK guys I've been talking with another user who can recreate this = crash and the last bit of information we've learned seems to be leaning = towards interrupts/IRQ issues like someone (bz@ perhaps?) suggested. >=20 > I'm still trying to test this myself, but the other user was able to = recreate my crash pretty much on demand. The fix was to not use the = first NIC in the VM because it will always share an IRQ with mpt0. Once = mpt0 is on its own the crash does not seem to be reproducible anymore. >=20 > Before: >=20 > $ vmstat -i > interrupt total rate > irq1: atkbd0 378 0 > irq6: fdc0 9 0 > irq15: ata1 34 0 > irq16: em1 687237 1 > irq18: em0 mpt0 319094024 539 > cpu0: timer 236770821 400 > Total 556552503 940 >=20 > After: >=20 > $ vmstat -i > interrupt total rate > irq1: atkbd0 38 0 > irq6: fdc0 9 0 > irq15: ata1 34 0 > irq16: em1 2811 15 > irq17: em2 5 0 > cpu0: timer 71013 398 > irq256: mpt0 12163 68 > Total 86073 483 >=20 >=20 > Is there any other way we can make mpt0 get its own dedicated IRQ = without having to do this? The problem is that it causes us to have to = make rc.conf changes, pf.conf changes, and who knows what other software = could be on these machines that is trying to bind to a specific NIC... >=20 >=20 > Thanks! >=20 You could try switching mpt to MSI. MSI interrupts are never shared. = Add this to /boot/device.hints: > hint.mpt.0.msi_enable=3D"1" -Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 17:17:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CDE01065670 for ; Mon, 21 May 2012 17:17:51 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 407338FC21 for ; Mon, 21 May 2012 17:17:50 +0000 (UTC) Received: by ggnm2 with SMTP id m2so5696149ggn.13 for ; Mon, 21 May 2012 10:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=BGO5K82sWBlK2iw5t2ZenI1OvoFUAJksURfCNWi2RUE=; b=K20P3k4jAvupiTMXYGw5VHg09PksVBlfaVXG5NxT81l0fxJOx7omnv4AW+NkmOLrgW 2XGMOELlw50gNCOXAZeo2B3OBf5RFASBuZerIXp4Subz+YvISeavYS+cYorAiuklKYtm Vo1vjvvu873Q9oUpH39b7OxohSHM+BiRYeDFw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=BGO5K82sWBlK2iw5t2ZenI1OvoFUAJksURfCNWi2RUE=; b=WEifXYlQX2Br3Iwk3t4vsNJivYcL2OYtDar2YrZk+5fs/7XY8tQDGnD9n+NKB4uruu ANauaQ/krAsZFriQNsjLNT1oU+rE3r03Ar4VJy4i5mFoep7TCZJefWQ4OhMAkckHTug5 8Q62E90gP2TS6qtuMUFL2QF0d6u6RTqaA19CPzRxJnoxA4CgUEUpSCB4v6zaTvdZq+zE WMelk+KigWPkTrUpBIbLrgdSV9ICFRzLW839GTm7Akc999nE8bDBKDXp24Bmp8c+CNXP aKMhU7nI/el1MDdQeVaVLXkKGG9Lojw7Iqv7Yr+icnp1qIADmi3xskyF/ldLozVrp97d iSYg== Received: by 10.50.12.199 with SMTP id a7mr7206777igc.71.1337620670250; Mon, 21 May 2012 10:17:50 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id k6sm410863igz.9.2012.05.21.10.17.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 10:17:49 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4LHHkgG037363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2012 13:17:46 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4LHHjSB037362; Mon, 21 May 2012 13:17:45 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Mon, 21 May 2012 13:17:45 -0400 From: Jason Hellenthal To: Jason Usher Message-ID: <20120521171745.GA9418@DataIX.net> References: <20120517232238.GA91365@DataIX.net> <1337617112.24292.YahooMailClassic@web122505.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <1337617112.24292.YahooMailClassic@web122505.mail.ne1.yahoo.com> X-Gm-Message-State: ALoCoQnO+Oe2TFCxZJm4jA9IbRhuzjEpltfnSux9O8FKQGGaCj00yQxQ+MjpSEXffJ2pZ6iwDpE9 Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:17:51 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 21, 2012 at 09:18:32AM -0700, Jason Usher wrote: >=20 > Folks, >=20 > Is there a better list for this - perhaps freebsd-security ? >=20 > I originally posted to -hackers because it *appears* that reverting "rsa,= then dsa" to "dsa, then rsa" was a simple change to myproposal.h, but sinc= e that doesn't work, and since I haven't gotten any replies here ... >=20 > Thoughts ? OpenBSD ? http://www.openssh.org/list.html >=20 >=20 > --- On Thu, 5/17/12, Jason Hellenthal wrote: >=20 > > > > > I have some old 6.x FreeBSD systems that need > > their > > > > OpenSSH upgraded. > > > > >=20 > > > > > Everything goes just fine, but when I am > > done, existing > > > > clients are now presented with this message: > > > > >=20 > > > > >=20 > > > > > WARNING: DSA key found for host hostname > > > > > in /root/.ssh/known_hosts:12 > > > > > DSA key fingerprint > > 4c:29:4b:6e:b8:6b:fa:49....... > > > > >=20 > > > > > The authenticity of host 'hostname > > (10.1.2.3)' can't be > > > > established > > > > > but keys of different type are already known > > for this > > > > host. > > > > > RSA key fingerprint is > > a3:22:3d:cf:f2:46:09:f2...... > > > > > Are you sure you want to continue connecting > > (yes/no) > > > > >=20 > > > >=20 > > > > You must be using different keys for your server > > than the > > > > one that has > > > > been generated before the upgrade. Just copy your > > keys over > > > > to the new > > > > location and restart the server daemon and you > > should be > > > > fine. > > > >=20 > > > > copy /etc/ssh/* -> /usr/local/etc/ssh/ > > >=20 > > >=20 > > > You didn't read that error message. > >=20 > > Sorry I misread that. Decieving message... > >=20 > > >=20 > > > That is not the standard "key mismatch" error that you > > assumed it was.=A0 Look at it again - it is saying that > > we do have a key for this server of type DSA, but the client > > is receiving one of type RSA, etc. > > >=20 > > > The keys are the same - they have not changed at all - > > they are just being presented to clients in the reverse > > order, which is confusing them and breaking automated, > > key-based login. > > >=20 > > > I need to take current ssh server behavior (rsa, then > > dss) and change it back to the old order (dss, then rsa). > >=20 > > Have you attempted to change that order via sshd_config and > > placing the > > DSA directive before the RSA one ? > >=20 > >=20 > > --=20 > >=20 > > - (2^(N-1)) > >=20 --=20 - (2^(N-1)) --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPuni4AAoJEBSh2Dr1DU7WVccIALXlcuUwd/2Z8+C5uUqFNXFu mozYYm9V9Vctxhga2Zi5dygj/Q10952XV1vvEutNTTjmbgDdcFtFo+1uPcLeAbd9 7Hd3fpTweao2OXNwUigIUGkxXFgv0qHvuj+KJYd7RHk5JZI+wMXNll3jc0P1CLmy j20lPJr3QgzwHgwFLx1Gy8H880u1L9hM5aTA6pbiNdWSr3PywBTiliPAcACxCsRj /eugtsjGJbB38Ay1X5dDz1tl6tYjPxu/ko0ohIUlwsuwSUUbfPYqrSZh3TiTYTkD OOeNz/MRYAYYqOlO6OyM2Go5uDridJHLhNubWIOuAn6ZBIekWIb9Qi1z6gCbFYA= =suFK -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 17:19:21 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1F861065678 for ; Mon, 21 May 2012 17:19:21 +0000 (UTC) (envelope-from rightlyhh2@cochamber.com) Received: from gp176-30.iu13.org (gp176-30.iu13.org [206.82.30.176]) by mx1.freebsd.org (Postfix) with ESMTP id 7A69E8FC21 for ; Mon, 21 May 2012 17:19:21 +0000 (UTC) Received: from apache by pcjqdfrffeqhhhhpcjep.wonderware.com with local (Exim 4.67) (envelope-from <>) id GBYAF0-Z3QOU3-E0 for ; Mon, 21 May 2012 12:19:20 -0500 To: X-PHP-Script: pcjqdfrffeqhhhhpcjep.surewest.com/sendmail.php for 206.82.30.176 From: X-Sender: X-Mailer: PHP X-Priority: 1 Content-Type: text/plain; charset="iso-8859-1" Message-Id: Date: Mon, 21 May 2012 12:19:20 -0500 Cc: Subject: We invite you to a remote job $ 100 per hour helping sick people X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:19:21 -0000 We invite you to work in the remote assistant position. This work takes 2-3 hours per week and requires absolutely no investment. The essence of this work for incoming client requests in your city. The starting salary is about 2500 EUR per month + bonuses. You get paid your salary every 2 weeks and your bonuses after fulfilling each task! We guarantee work for everyone. But we accept applications this week only! Therefore, you should write a request right now. And you will start earning money, starting from next week. Please indicate in the request: Your name: Your email address: City of residence: Please send the request to my email Collin@topeuropajobs.com,and I will answer you personally as soon as possible Sincerely, Collin Burns From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 17:19:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D268106564A; Mon, 21 May 2012 17:19:22 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 223888FC23; Mon, 21 May 2012 17:19:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=QDQYTsKicQApn4memU3LH+y8nPxTe/XWsXZ1eFbpqIc=; b=rDK17jY5hUhhbF4mpZrcMwtjYuAGGnFrRYKmMKwcnCyii5OigN1mH7AAwdf3CNN0cStCnQMry04Nq3vEwcsfGeOoaM8xgvlsyfJ/ckwZc6g9ItofnuUdBeTT0rKFk61G; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWWGO-0006lk-9c; Mon, 21 May 2012 12:19:21 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1337620754-3288-3287/5/17; Mon, 21 May 2012 17:19:14 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org, freebsd-questions@FreeBSD.org References: <490F2075-3E4D-4F85-9935-937CED8FB10B@averesystems.com> Date: Mon, 21 May 2012 12:19:14 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <490F2075-3E4D-4F85-9935-937CED8FB10B@averesystems.com> User-Agent: Opera Mail/11.64 (FreeBSD) X-SA-Score: -1.5 Cc: Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:19:22 -0000 On Mon, 21 May 2012 12:01:19 -0500, Andrew Boyer wrote: > You could try switching mpt to MSI. MSI interrupts are never shared. > Add this to /boot/device.hints: > >> hint.mpt.0.msi_enable="1" Currently implementing this on the known crashy servers. I've been looking around and all of our VM's that do NOT crash also do not share interrupts between em0/mpt0. Thank you very much.... if this is the fix we will be SO grateful. From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 17:46:50 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 712691065678; Mon, 21 May 2012 17:46:50 +0000 (UTC) (envelope-from Daan@vitsch.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 08B278FC20; Mon, 21 May 2012 17:46:49 +0000 (UTC) Received: from [192.168.45.11] (180-161.ftth.onsbrabantnet.nl [88.159.161.180]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id q4LHkljd092457; Mon, 21 May 2012 19:46:47 +0200 (CEST) (envelope-from Daan@vitsch.nl) From: Daan Vreeken Organization: Vitsch Electronics To: freebsd-arm@freebsd.org Date: Mon, 21 May 2012 19:46:23 +0200 User-Agent: KMail/1.9.10 References: <1337617221.2516.38.camel@revolution.hippie.lan> In-Reply-To: <1337617221.2516.38.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201205211946.23306.Daan@vitsch.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl X-Mailman-Approved-At: Mon, 21 May 2012 17:48:06 +0000 Cc: Ian Lepore , hackers@freebsd.org, Svatopluk Kraus , Richard Hodges Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:46:50 -0000 Hi Ian (and list), just commenting on the mbuf part : On Monday 21 May 2012 18:20:21 Ian Lepore wrote: > On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote: > > On Thu, May 17, 2012 at 10:07 PM, Ian Lepore > > wrote: > > > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: > > >> Hi, ... > > What I can do in a driver it's not so simple in case of OS buffers > > like mbufs. I can check how mbufs are used in current implementation > > and say, yes, it's safe to use them unaligned. However, it can be > > changed in next release if anybody won't take care of it. It would be > > nice to have a maintained list of OS buffers which are DMA safe in > > respect of CACHE_LINE_SIZE. Is the flag and the list interesting for > > somebody else? > > I don't have a definitive answer for this, but my assumption has always > been that once an mbuf is handed to a driver (for example, when it's > added to an interface's send queue), the driver then "owns" that mbuf > and nothing else in the system will touch it until the driver makes a > call to hand it off or free it. If that assumption is true, a driver > could make good use of a BUS_DMA_UNALIGNED_SAFE flag with mbufs. > > The part that scares me about my assumption is the m_ext.ref_cnt field > of the mbuf. Its existance seems to imply that multiple entities > concurrently have an interest in the data. On the other hand, the lack > of any built in provisions for locking seems to imply that concurrent > access isn't happening, or perhaps it implies that any required > synchronization is temporal rather than lock-based. > > I've never found anything in writing that explains mbuf usage > conventions at this level of detail. This assumption isn't always true. 'man 9 mbuf' mentions this, but not in one place. M_WRITABLE() can be used to tell wether or not you're allowed to modify an mbuf. If it returns false, you can create a writable copy of the mbuf and alter the copy instead of the original. A writable copy of an mbuf can be made using m_dup(). Writing to non-writable mbuf's will cause data corruption in e.g. BPF and TCP retransmits (even in the non-SMP case). Regards, -- Daan Vreeken Vitsch Electronics http://Vitsch.nl tel: +31-(0)40-7113051 KvK nr: 17174380 From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 18:44:36 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A4C10657C4 for ; Mon, 21 May 2012 18:44:36 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.freebsd.org (Postfix) with ESMTP id 24EF78FC19 for ; Mon, 21 May 2012 18:44:36 +0000 (UTC) Received: from gilead.netel.rpi.edu (gilead.netel.rpi.edu [128.113.124.121]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id q4LHYQ4k008770; Mon, 21 May 2012 13:34:26 -0400 Message-ID: <4FBA7CA2.5080703@FreeBSD.org> Date: Mon, 21 May 2012 13:34:26 -0400 From: Garance A Drosehn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Jason Usher References: <1337617112.24292.YahooMailClassic@web122505.mail.ne1.yahoo.com> In-Reply-To: <1337617112.24292.YahooMailClassic@web122505.mail.ne1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 1.50 (*) [Hold at 8.00] COMBINED_FROM,RATWARE_GECKO_BUILD X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: 49639179 - 94b2ba05d542 X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Cc: freebsd-hackers@FreeBSD.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 18:44:36 -0000 I may have missed some emails in this thread, but did you try this suggestion: But have you tried it in this order ? HostKey /usr/local/etc/ssh/ssh_host_key HostKey /usr/local/etc/ssh/ssh_host_dsa_key HostKey /usr/local/etc/ssh/ssh_host_rsa_key HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key Which is to say, have your sshd_config file list multiple hostkey's, and then restart sshd after making that change? I tried a similar change and it seemed to have some effect on what clients saw when connecting, but I can't tell if it has the effect that you want. -- garance On 5/21/12 12:18 PM, Jason Usher wrote: > Folks, > > Is there a better list for this - perhaps freebsd-security ? > > I originally posted to -hackers because it *appears* that reverting "rsa, then dsa" to "dsa, then rsa" was a simple change to myproposal.h, but since that doesn't work, and since I haven't gotten any replies here ... > > Thoughts ? > From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 19:02:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3E5A1065673 for ; Mon, 21 May 2012 19:02:50 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from ps-1-b.compliancesafe.com (ps-1-b.compliancesafe.com [216.81.161.162]) by mx1.freebsd.org (Postfix) with ESMTP id 889148FC1B for ; Mon, 21 May 2012 19:02:50 +0000 (UTC) Received: from mail.palisadesystems.com (localhost [127.0.0.1]) by ps-1-b.compliancesafe.com (8.14.4/8.14.3) with ESMTP id q4LJAVpn049528; Mon, 21 May 2012 14:10:31 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Received: from guysmbp.dyn.palisadesys.com (GuysMBP.dyn.palisadesys.com [172.16.2.90]) (authenticated bits=0) by mail.palisadesystems.com (8.14.3/8.14.3) with ESMTP id q4LJ2HRg013820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 May 2012 14:02:18 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.palisadesystems.com q4LJ2HRg013820 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=palisadesys.com; s=mail; t=1337626938; bh=FCfpZdCKZD7KUqVWFWWCufeUWdVPKXU7liya1ThW8fo=; l=128; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rHRreSFuoCQIKygvt2NqybBxF/sS+DBJVduBVirDMYAjVB1xCaqQ/q8+tUzY8ZP3C r2oUptqI1xDdaNIDuH/keddSOzX5iRayhq8IpZ3MuSTW93RuQw9ancAnHajJoMp06w fjouB7/ULI9Gcb0pq6KkUddrw23jWlTxNKivRzEs= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Guy Helmer In-Reply-To: <4FB6D698.9030305@delphij.net> Date: Mon, 21 May 2012 14:02:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EE466CC-5F93-485C-8E1F-907F8049FD61@palisadesys.com> <4FB6D698.9030305@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.palisadesystems.com [172.16.1.5]); Mon, 21 May 2012 14:02:18 -0500 (CDT) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner-ID: q4LJ2HRg013820 X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.284, required 5, ALL_TRUSTED -1.00, BAYES_00 -1.90, J_CHICKENPOX_54 0.60, J_CHICKENPOX_63 0.60, RP_8BIT 1.98) X-Palisade-MailScanner-From: ghelmer@palisadesys.com X-Spam-Status: No X-PacketSure-Scanned: Yes Cc: freebsd-hackers@freebsd.org Subject: Re: Review of changes for getnetgrent.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 19:02:50 -0000 On May 18, 2012, at 6:09 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 05/18/12 14:58, Guy Helmer wrote: >> To close PR bin/83340, I have this change worked up to resolve >> memory allocation failure handling and avoid creating bad entries >> in the grp list due to memory allocation failures while building a >> new entry. >>=20 >> Before committing, I wanted to run it past others to see if there >> were any problems with it. >=20 > %%% > @@ -477,6 +475,13 @@ > if (len > 0) { > grp->ng_str[strpos] =3D = (char *) > malloc(len + 1); > + if (grp->ng_str[strpos] = =3D=3D NULL) { > + for (freepos =3D = 0; freepos < strpos; freepos++) > + if = (grp->ng_str[freepos] !=3D NULL) > + = free(grp->ng_str[freepos]); > + free(grp); > + return(1); > + } > bcopy(spos, = grp->ng_str[strpos], > len + 1); > %%% Like this? if (len > 0) { grp->ng_str[strpos] =3D = (char *) malloc(len + 1); + if (grp->ng_str[strpos] = =3D=3D NULL) { + int freepos; + for (freepos =3D = 0; freepos < strpos; freepos++) + = free(grp->ng_str[freepos]); + free(grp); + return(1); + } bcopy(spos, = grp->ng_str[strpos], len + 1); } >=20 > There are a few return without space between the keyword and return = value. Do you recommend I fix all those instances in the file, or just the = instances in this patch? Thanks, Guy -------- This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure. From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 19:21:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83D2C106564A; Mon, 21 May 2012 19:21:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5214C8FC0A; Mon, 21 May 2012 19:21:06 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q4LJKxrW050526 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 May 2012 12:21:00 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4FBA95A1.9050404@freebsd.org> Date: Mon, 21 May 2012 12:21:05 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: David Windsor References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-jail@freebsd.org Subject: Re: PID/UID namespaces X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 19:21:06 -0000 On 5/21/12 6:47 AM, David Windsor wrote: > Hi, > > While doing some research on FreeBSD jails, I came across an item in the > jails' TODO: > > > - be able to have a separate PID space for it > - be able to specify a separate UID space for it > > In other projects, these goals have been accomplished using namespaces. I > tried to see if PID/UID namespaces existed in BSD and came across something > called Capsicum, a sandboxing project which does not appear to implement > outright namespaces for descriptors like PID/UID, but uses something called > a "Process Descriptor." > > Is namespacing of PIDs and UIDs an eventual goal of the jails project of > FreeBSD? "kinda" Note terribly explicitly, but somewhere in our collective subconscious.. > Thanks, > > David > > PS: Excuse my ignorance of anything related to BSD, as I come from a Linux > background. > > From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 19:26:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 564A61065674; Mon, 21 May 2012 19:26:47 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9FAA28FC23; Mon, 21 May 2012 19:26:46 +0000 (UTC) Received: by bkvi18 with SMTP id i18so5868132bkv.13 for ; Mon, 21 May 2012 12:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=RnV2xWrS9cGpVO/sgyoZ8src6UMP30WTcC8P1Ac/3cI=; b=VvUtGirvBZGmzcHeZgGfN1AvKM7MUCMaBB5mUm3eJBjUVTiEFc+kBhGHVAZT14QuTQ GiJ9dArEBvFCsgQXo+rqza4SUEA90I3fZ+Otp5OXgaXfEzDzsmXk8gjcvfvqWgACEXb3 gNJ5e4y0CiWIW7BWgx90Ev4qpY6J354I5yjqUImZmrcmsxToKnS2mRzZTtRPdCeHDDN1 AOzIOdBBkY/4Sn7EVf+pQFZ1R5Cg9X9h7dUxV2qLl5DzUMY5YjBYDSGIiW2XggRLzJbd g8rbMyxt2y0pXKgJ3H8lh/4RDSxP2wk0VJ5R3RA4rOZoBvNSfYudqK6CsdKg6j0Xl/C3 Dl4w== Received: by 10.204.154.214 with SMTP id p22mr8097532bkw.115.1337628405499; Mon, 21 May 2012 12:26:45 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.171.138 with HTTP; Mon, 21 May 2012 12:26:15 -0700 (PDT) In-Reply-To: References: From: Chris Rees Date: Mon, 21 May 2012 20:26:15 +0100 X-Google-Sender-Auth: BreNSxghnRaCkGnboNNdn2Koj34 Message-ID: To: David Windsor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-jail@freebsd.org Subject: Re: PID/UID namespaces X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 19:26:47 -0000 On 21 May 2012 14:47, David Windsor wrote: > Hi, > > While doing some research on FreeBSD jails, I came across an item in the > jails' TODO: > > > =A0 - be able to have a separate PID space for it > =A0 - be able to specify a separate UID space for it > > In other projects, these goals have been accomplished using namespaces. = =A0I > tried to see if PID/UID namespaces existed in BSD and came across somethi= ng > called Capsicum, a sandboxing project which does not appear to implement > outright namespaces for descriptors like PID/UID, but uses something call= ed > a "Process Descriptor." > > Is namespacing of PIDs and UIDs an eventual goal of the jails project of > FreeBSD? It would certainly prevent many common problems when setting up jails; UID collision is much more common than you'd think, given that the default UIDs remain the same. Chris From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 19:27:43 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1A821065674; Mon, 21 May 2012 19:27:43 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5918FC19; Mon, 21 May 2012 19:27:43 +0000 (UTC) Received: by dadv36 with SMTP id v36so7789614dad.13 for ; Mon, 21 May 2012 12:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ioRQofufxc0jHzZA6LgY7/JNjOZBWaADmPyCh7gTsPA=; b=yjd+JQyJPUoH/y/MzgpxYgRYNWWcSaYHwxVmsWooKlnkD+G2rXKdxDOPyhOVucuRsj P+cX1c1l0r2ZmZOK9aRv7XkvkGKgeBFBW57qCwSH9SrH282uK7Wl/3s1PB1NEqmd8fQg NEBWCNjIUe4x6z//qrf0P3Em5JyyzuvQjkPdROG2e1aso0eRU+JbJ5nGRPBJj7+8XR/5 Z/HHD8KVH8eY+MqEJD2BNKodq+BhGxdHT7ucpZ6phyV9iAsL2EuFthGxEfkEIc3bohkB lpc/2gHjn/AYmqCW8r5P4TrikRg+KL21Tn1qi9lBba1VXIad+zjA4NjeNdYjRLVwNIKc Blkw== MIME-Version: 1.0 Received: by 10.68.232.135 with SMTP id to7mr520502pbc.143.1337628463040; Mon, 21 May 2012 12:27:43 -0700 (PDT) Received: by 10.68.72.195 with HTTP; Mon, 21 May 2012 12:27:42 -0700 (PDT) In-Reply-To: <1337617221.2516.38.camel@revolution.hippie.lan> References: <1337285248.1503.308.camel@revolution.hippie.lan> <1337617221.2516.38.camel@revolution.hippie.lan> Date: Mon, 21 May 2012 14:27:42 -0500 Message-ID: From: Mark Tinguely To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Richard Hodges , freebsd-arm@freebsd.org, hackers@freebsd.org, Svatopluk Kraus Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 19:27:43 -0000 On Mon, May 21, 2012 at 11:20 AM, Ian Lepore wrote: > On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote: >> On Thu, May 17, 2012 at 10:07 PM, Ian Lepore >> wrote: >> > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: >> >> Hi, >> >> >> >> I'm working on DMA bus implementation for ARM11mpcore platform. I've >> >> looked at implementation in ARM tree, but IMHO it only works with som= e >> >> assumptions. There is a problem with DMA on memory block which is not >> >> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. >> >> >> >> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. >> >> Then first cache line associated with the buffer can be divided into >> >> two parts, A and B, where A is a memory we know nothing about it and = B >> >> is buffer memory. The same stands for last cache line associatted wit= h >> >> the buffer. We have no problem if a memory is coherent. Otherwise it >> >> depends on memory attributes. ... > My suggestion of making a temporary writable mapping was the answer to > how to correctly change memory attributes on a page which is in use, at > least in the existing code, which is for a single processor. > > You don't need, and won't even use, the temporary mapping. =A0You would > make it just because doing so invokes logic in arm/arm/pmap.c which will > find all existing virtual mappings of the given physical pages, and > disable caching in each of those existing mappings. =A0In effect, it make= s > all existing mappings of the physical pages DMA_COHERENT. =A0When you > later free the temporary mapping, all other existing mappings are > changed back to being cacheable (as long as no more than one of the > mappings that remain is writable). > > I don't know that making a temporary mapping just for its side effect of > changing other existing mappings is a good idea, it's just a quick and > easy thing to do if you want to try changing all existing mappings to > non-cacheable. =A0It could be that a better way would be to have the > busdma_machdep code call directly to lower-level routines in pmap.c to > change existing mappings without making a new temporary mapping in the > kernel pmap. =A0The actual changes to the existing mappings are made by > pmap_fix_cache() but that routine isn't directly callable right now. > > Also, as far as I know all of this automatic disabling of cache for > multiple writable mappings applies only to VIVT cache architectures. > I'm not sure how the pmap code is going to change to support VIPT and > PIPT caches, but it may no longer be true that making a second writable > mapping of a page will lead to changing all existing mappings to > non-cacheable. > > -- Ian We don't want to carry the VIVT cache fixing code to VIPT/PIPT. I like the x86 approach of marking the page with a cache type (default/device/uncached/etc). The page mapping routines (for example pmap_qenter() on a clustered write) will honor that cache type in all future mappings. It is easy to implement. Other allocations, such as page tables, can benefit from an attributed allocation too. I also like having a separate allocator for the sub-page bus_dmamem_alloc() requests that want uncached buffers. These entries can stick around for a long time. If we just malloced the entries, then the other threads that happen to allocate data from the same page are penalized with uncached buffers too. --Mark. From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 19:29:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C9631065693 for ; Mon, 21 May 2012 19:29:21 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7D58FC1B for ; Mon, 21 May 2012 19:29:21 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 9BDB7C656; Mon, 21 May 2012 12:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1337628560; bh=BY++wY+MgJ+bh4eGjpgv+XutDZiFvy1ptlDzOmQ09Dk=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=AM/JIQJrUgtL7vod+B0wfOi+MC2ZC1g5j3zR/lJb/ZQcFZ+MzKGnhIGs+fATtSIXP 2zsEXh+omTrFS+M9JQNJKDk9xCi+JkWESe+gCaFFkUMnEbrm5vNngn0sjFqiRkYMvO 6jH/SUjPRUN2QoUwAiiYCCPpez7J+800DlQUu68g= Message-ID: <4FBA978F.2030908@delphij.net> Date: Mon, 21 May 2012 12:29:19 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Guy Helmer References: <4EE466CC-5F93-485C-8E1F-907F8049FD61@palisadesys.com> <4FB6D698.9030305@delphij.net> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, d@delphij.net Subject: Re: Review of changes for getnetgrent.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 19:29:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/21/12 12:02, Guy Helmer wrote: > > On May 18, 2012, at 6:09 PM, Xin Li wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 05/18/12 14:58, Guy Helmer wrote: >>> To close PR bin/83340, I have this change worked up to resolve >>> memory allocation failure handling and avoid creating bad >>> entries in the grp list due to memory allocation failures while >>> building a new entry. >>> >>> Before committing, I wanted to run it past others to see if >>> there were any problems with it. >> >> %%% @@ -477,6 +475,13 @@ if (len > 0) { grp->ng_str[strpos] = >> (char *) malloc(len + 1); + if (grp->ng_str[strpos] == NULL) >> { + for (freepos = 0; freepos < strpos; freepos++) + >> if (grp->ng_str[freepos] != NULL) + >> free(grp->ng_str[freepos]); + free(grp); + >> return(1); + } bcopy(spos, grp->ng_str[strpos], len + 1); >> %%% > > Like this? > > if (len > 0) { grp->ng_str[strpos] = (char *) malloc(len + 1); + > if (grp->ng_str[strpos] == NULL) { + int freepos; + for > (freepos = 0; freepos < strpos; freepos++) + > free(grp->ng_str[freepos]); + free(grp); + return(1); + > } bcopy(spos, grp->ng_str[strpos], len + 1); } >> >> There are a few return without space between the keyword and >> return value. > > Do you recommend I fix all those instances in the file, or just the > instances in this patch? I'd recommend fixing them all (note that you could run into a bigger commit as the switch() is not style(9) conformant at this time) and we normally do it in two different commits (one style, and another functional) when possible. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPupePAAoJEG80Jeu8UPuz52wH/RVJXpCyea+ep08XDx82D7tG us+ujKa1aNOUumzwJRsJ4SNVBiyc+hqCtb8s7FjjeF4/SJk8oei/I1/M1JIyMuIh FawSB8rNJCbn/u9Od19iOeh/f/IDeCN+q8OrUK5mqQ7G1KDcHs12h86AFlm9HA7K 8UyxneTkPfKhED6hkgSll6bqYAJLeR5jJ3CCGvBeXxNgzJyyAhICWv0UgzUpcY9d l2beuIXc57toDaLrbWkooLfQclDWPWyyPXq7okexQAq8OUjqmQFE+EhcYsIbtBkH uBW67jhH81MZf/Ryl83VeqT9IChOySAU0YiwOQxaxdlqR53VAenAY0sWS1QvuX8= =drgy -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 19:57:51 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35BD8106566C; Mon, 21 May 2012 19:57:51 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A63638FC15; Mon, 21 May 2012 19:57:50 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 64FEB13F36; Mon, 21 May 2012 19:57:48 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q4LJvmKt039150; Mon, 21 May 2012 19:57:48 GMT (envelope-from phk@phk.freebsd.dk) To: Chris Rees From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 21 May 2012 20:26:15 +0100." Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 21 May 2012 19:57:48 +0000 Message-ID: <39149.1337630268@critter.freebsd.dk> X-Mailman-Approved-At: Mon, 21 May 2012 20:08:05 +0000 Cc: freebsd-hackers@FreeBSD.org, freebsd-jail@FreeBSD.org, David Windsor Subject: Re: PID/UID namespaces X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 19:57:51 -0000 In message , Chris Rees writes: >It would certainly prevent many common problems when setting up jails; >UID collision is much more common than you'd think, given that the >default UIDs remain the same. Uhm... jails have separate UID/GID spaces. Filesystems mounted or visible in multiple jails act as shared UID/GID (sub-)spaces for those jails, but there is now way to avoid that, it's a direct consequence of the sharing of the filesystems. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 20:23:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 824EE1065689; Mon, 21 May 2012 20:23:50 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0E98FC21; Mon, 21 May 2012 20:23:49 +0000 (UTC) Received: by bkvi18 with SMTP id i18so5921852bkv.13 for ; Mon, 21 May 2012 13:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=+3gUUACBlt1FRomjjF2sZQVa9sAGNd7ls/TNeLfSxJA=; b=DrvqpjhBkb7TZQcEbl4J6ZrMMfJ3aWEJnGJ3Mkpdfk4Br79u1U0T1beBdheQItGV+p Y1qnbstX0kpxvgq40aNrG4SeJ1zauxHOfeSpgtBVe+iurqAw3d6i+fbJueJQ5jUAKzcv 3GgkfvXtg073p5xqYTFgElf0j3WPcx6mfQQdBNikv7UQreoDNHMNghFRhMIoYSj0fnU2 FBuLgg5eO1m2oFjE9FShDyu3mJleJeGCkfHi+O20o3sxIyF1uMgEOTF+gMgkzL4ZGTat FxLyFfuLPOypKNlDuIoIE1bZjNa7B4l8Sz/SmPFJrPafMtH/NB+fCHJyx1WkXPH0WQcO BwFg== Received: by 10.204.154.214 with SMTP id p22mr8154969bkw.115.1337631828214; Mon, 21 May 2012 13:23:48 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.171.138 with HTTP; Mon, 21 May 2012 13:23:17 -0700 (PDT) In-Reply-To: <39149.1337630268@critter.freebsd.dk> References: <39149.1337630268@critter.freebsd.dk> From: Chris Rees Date: Mon, 21 May 2012 21:23:17 +0100 X-Google-Sender-Auth: i8E4VIzuT8icu-otOqTxWSu5MFA Message-ID: To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-jail@freebsd.org, David Windsor Subject: Re: PID/UID namespaces X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 20:23:50 -0000 On 21 May 2012 20:57, Poul-Henning Kamp wrote: > In message > , Chris Rees writes: > >>It would certainly prevent many common problems when setting up jails; >>UID collision is much more common than you'd think, given that the >>default UIDs remain the same. > > Uhm... jails have separate UID/GID spaces. > > Filesystems mounted or visible in multiple jails act as shared UID/GID > (sub-)spaces for those jails, but there is now way to avoid that, it's > a direct consequence of the sharing of the filesystems. Yes, beg pardon, my mistake-- that's what I was meaning to refer to. I still have a patch in GNATS for the docs about that, but it's been the subject of amazing controversy. Chris From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 21:11:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66C50106566C for ; Mon, 21 May 2012 21:11:22 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from ps-1-b.compliancesafe.com (ps-1-b.compliancesafe.com [216.81.161.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5818FC0C for ; Mon, 21 May 2012 21:11:22 +0000 (UTC) Received: from mail.palisadesystems.com (localhost [127.0.0.1]) by ps-1-b.compliancesafe.com (8.14.4/8.14.3) with ESMTP id q4LLJ9p6054860; Mon, 21 May 2012 16:19:09 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Received: from guysmbp.dyn.palisadesys.com (GuysMBP.dyn.palisadesys.com [172.16.2.90]) (authenticated bits=0) by mail.palisadesystems.com (8.14.3/8.14.3) with ESMTP id q4LLApH2017526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 May 2012 16:10:52 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.palisadesystems.com q4LLApH2017526 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=palisadesys.com; s=mail; t=1337634652; bh=R1LcdHe7Xj0xIEPRYEJQ6xkxqbVc3WW042MTcvFb5cg=; l=128; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=m8g41U/4QTA1FfFIGQsr5fFuJvlgviwXS3T6XLFakiipbc7MnHO/KEwTBdMLdkwQL c/PX/YYc9phOkJ6OOotWxmTcKX8GtVswY+5Tv2gVFVyXTDy03s03O9j7uTklPmtZ1A JgG53MRh3dUVPa33aGnP4UxbXdmxYVifzT7LvTrY= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Guy Helmer In-Reply-To: <4FBA978F.2030908@delphij.net> Date: Mon, 21 May 2012 16:10:51 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0C6268C5-3E3C-40F2-A8C6-23615D05893D@palisadesys.com> References: <4EE466CC-5F93-485C-8E1F-907F8049FD61@palisadesys.com> <4FB6D698.9030305@delphij.net> <4FBA978F.2030908@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.palisadesystems.com [172.16.1.5]); Mon, 21 May 2012 16:10:52 -0500 (CDT) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner-ID: q4LLApH2017526 X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.284, required 5, ALL_TRUSTED -1.00, BAYES_00 -1.90, J_CHICKENPOX_54 0.60, J_CHICKENPOX_63 0.60, RP_8BIT 1.98) X-Palisade-MailScanner-From: ghelmer@palisadesys.com X-Spam-Status: No X-PacketSure-Scanned: Yes Cc: freebsd-hackers@freebsd.org Subject: Re: Review of changes for getnetgrent.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 21:11:22 -0000 On May 21, 2012, at 2:29 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 05/21/12 12:02, Guy Helmer wrote: >> >> On May 18, 2012, at 6:09 PM, Xin Li wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> On 05/18/12 14:58, Guy Helmer wrote: >>>> To close PR bin/83340, I have this change worked up to resolve >>>> memory allocation failure handling and avoid creating bad >>>> entries in the grp list due to memory allocation failures while >>>> building a new entry. >>>> >>>> Before committing, I wanted to run it past others to see if >>>> there were any problems with it. >>> >>> %%% @@ -477,6 +475,13 @@ if (len > 0) { grp->ng_str[strpos] = >>> (char *) malloc(len + 1); + if (grp->ng_str[strpos] == NULL) >>> { + for (freepos = 0; freepos < strpos; freepos++) + >>> if (grp->ng_str[freepos] != NULL) + >>> free(grp->ng_str[freepos]); + free(grp); + >>> return(1); + } bcopy(spos, grp->ng_str[strpos], len + 1); >>> %%% >> >> Like this? >> >> if (len > 0) { grp->ng_str[strpos] = (char *) malloc(len + 1); + >> if (grp->ng_str[strpos] == NULL) { + int freepos; + for >> (freepos = 0; freepos < strpos; freepos++) + >> free(grp->ng_str[freepos]); + free(grp); + return(1); + >> } bcopy(spos, grp->ng_str[strpos], len + 1); } >>> >>> There are a few return without space between the keyword and >>> return value. >> >> Do you recommend I fix all those instances in the file, or just the >> instances in this patch? > > I'd recommend fixing them all (note that you could run into a bigger > commit as the switch() is not style(9) conformant at this time) and we > normally do it in two different commits (one style, and another > functional) when possible. > OK, thank you. Guy -------- This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure. From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 21:28:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 101D6106564A for ; Mon, 21 May 2012 21:28:19 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm12-vm1.bullet.mail.ne1.yahoo.com (nm12-vm1.bullet.mail.ne1.yahoo.com [98.138.91.41]) by mx1.freebsd.org (Postfix) with SMTP id 81EF88FC12 for ; Mon, 21 May 2012 21:28:18 +0000 (UTC) Received: from [98.138.90.57] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2012 21:26:27 -0000 Received: from [98.138.89.165] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 21 May 2012 21:26:27 -0000 Received: from [127.0.0.1] by omp1021.mail.ne1.yahoo.com with NNFMP; 21 May 2012 21:26:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 720210.78484.bm@omp1021.mail.ne1.yahoo.com Received: (qmail 75790 invoked by uid 60001); 21 May 2012 21:26:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337635587; bh=sip5a/WtZBkiM6jDFU47c+ICnC1q7Y1jl7eF496zMTk=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ApJz48e591ECmjJ5YAZazjShsIUQ6sCjQLSJV3L6Jq3hMeF/WMWJJ7513NNnlKtGNPTYPwjoc5e5UUE1BJdrU/6gJbHODJajXNGbgEFamwyi2eWF0hIOZR0I20acEmLwCX4kkJmIoVeoOScP18nbVNSs5hu5ri5Bh9D1fr8N4Tc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=43j442wk38F5f6jPlVtT7AEr9tegT3V92ffz09um2LzJ28eFw1IEA+mYbIJ3WqMXqi6YMdIyWCgd8RAPiZnZ9+YYtjfTjKiJDgWZQWNpOLFc6EnHA6GX8JztLf3h8qwWBIYb/mciOvDRlEAl5bNfO4+GTZeshzkOjWrHRUhRJFQ=; X-YMail-OSG: 7Up6DaMVM1lrg0w064YJBo1Haz05rRvuBqzFLiojwMRGV_V xcwL5bZ7ShfpJ2C_qdzilJCU9Z_BV.g8sgmdLy0iYdWTGyiO105bSQJFYAL0 c7mNYxarFhsgGaUtca_n2Ar3d9QGpcG_JZ4Xv9nUo4mHSkYU1TCUQQrtcrL5 r04uvzzqyrU4MdPL9Zk780FMhkPeAih1xDbTHyWFsrHRg.aFUWBdaH3OfMw4 3HEzjYaBomwhXq.GCPG3AVezRL4tXhnpkULIfFXPUz9vIdkyXjNdovoelJ0L m1si56n_qH7JuQqG5voZGfQT0HdN6XZGD04zwy5U9Zbk11csuV4OnyoFmdq4 LtapMJgf8RkBtFbeQn6nZkhgKFK9hVddH3Wwj4hYOB.72waV0KGetuRPgAo5 oI8dwW9E4nSY6LlT2sMg45ov0 Received: from [173.164.238.34] by web122503.mail.ne1.yahoo.com via HTTP; Mon, 21 May 2012 14:26:27 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337635587.57757.YahooMailClassic@web122503.mail.ne1.yahoo.com> Date: Mon, 21 May 2012 14:26:27 -0700 (PDT) From: Jason Usher To: Garance A Drosehn In-Reply-To: <4FBA7CA2.5080703@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 May 2012 21:45:51 +0000 Cc: freebsd-hackers@FreeBSD.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 21:28:19 -0000 =0A=0A--- On Mon, 5/21/12, Garance A Drosehn wrote:=0A = =0A> =A0=A0=A0But have you tried it in this order ?=0A> =0A> =A0=A0=A0HostK= ey /usr/local/etc/ssh/ssh_host_key=0A> =A0=A0=A0HostKey=0A> /usr/local/etc/= ssh/ssh_host_dsa_key=0A> =A0=A0=A0HostKey=0A> /usr/local/etc/ssh/ssh_host_r= sa_key=0A> =A0=A0=A0HostKey=0A> /usr/local/etc/ssh/ssh_host_ecdsa_key=0A> = =0A> Which is to say, have your sshd_config file list multiple=0A> hostkey'= s, and then restart sshd after making that change?=0A> I tried a similar ch= ange and it seemed to have some effect=0A> on what clients saw when connect= ing, but I can't tell if=0A> it has the effect that you want.=0A=0A=0AThe o= rder of HostKey directives in sshd_config does not change the actual order.= In newer implementations, RSA is provided first, no matter how you config= ure the sshd_config.=0A=0AAs I mentioned before, removing RSA completely is= sort of a fix, but I can't do that because some people might actually be e= xplicitly using RSA, and they would all break.=0A=0AAnyone ? From owner-freebsd-hackers@FreeBSD.ORG Mon May 21 23:36:02 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77B971065674 for ; Mon, 21 May 2012 23:36:02 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id 29B258FC15 for ; Mon, 21 May 2012 23:36:02 +0000 (UTC) Received: by qabj40 with SMTP id j40so2497682qab.15 for ; Mon, 21 May 2012 16:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=OBfHjsa9EDKos5hwfjJOdWcg1JI6ECJENmfwMLA9sRE=; b=E6DOW4Zn+Nz816cYE0pfCKhLoExgnz5fPYF4HC0Qu1icNeNqnjf4DkWxW5ts5hfuDR CKufXH54P/UtpfB/9TqHac+9bKO/eEIgDsWbdaxwZ60KN5517VgRPiFfMBZyp0tlOL4H Or3kHAWDyrzpiZqU7Soxr7LmOjev+9U/90Kgg7CPbtaNViw2J5i/tSo4Q4Y7onCGDyLJ 7UXH0VkNiFu9DhdQ4h0EhJ9T0Q3oZGLYIWgD0FM9M3AUoxBHkTF3vF1HE3hVtPIjIwDD nLTdWdbyeGydR7j2Z5jcuplo/lU53kw6MwxxGnh6yqPZBVNB3KXtN4A43Z+rBtWwE/AX cRPQ== Received: by 10.224.115.208 with SMTP id j16mr41621545qaq.84.1337643361366; Mon, 21 May 2012 16:36:01 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id u2sm41860340qaa.13.2012.05.21.16.35.59 (version=SSLv3 cipher=OTHER); Mon, 21 May 2012 16:36:00 -0700 (PDT) Date: Mon, 21 May 2012 19:35:48 -0400 From: Alexander Kabaev To: Mark Tinguely Message-ID: <20120521193548.0b03a39a@kan.dyndns.org> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/pHCWVeAVip/ysIJVHmMEvUv"; protocol="application/pgp-signature" Cc: hackers@freebsd.org, Svatopluk Kraus Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 23:36:02 -0000 --Sig_/pHCWVeAVip/ysIJVHmMEvUv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 17 May 2012 11:01:34 -0500 Mark Tinguely wrote: > On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus > wrote: > > Hi, > > > > I'm working on DMA bus implementation for ARM11mpcore platform. I've > > looked at implementation in ARM tree, but IMHO it only works with > > some assumptions. There is a problem with DMA on memory block which > > is not aligned on CACHE_LINE_SIZE (start and end) if memory is not > > coherent. > > > > Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > > Then first cache line associated with the buffer can be divided into > > two parts, A and B, where A is a memory we know nothing about it > > and B is buffer memory. The same stands for last cache line > > associatted with the buffer. We have no problem if a memory is > > coherent. Otherwise it depends on memory attributes. > > > > 1. [no cache] attribute > > No problem as memory is coherent. > > > > 2. [write throught] attribute > > The part A can be invalidated without loss of any data. It's not > > problem too. > > > > 3. [write back] attribute > > In general, there is no way how to keep both parts consistent. At > > the start of DMA transaction, the cache line is written back and > > invalidated. However, as we know nothing about memory associated > > with part A of the cache line, the cache line can be filled again > > at any time and messing up DMA transaction if flushed. Even if the > > cache line is only filled but not flushed during DMA transaction, > > we must make it coherent with memory after that. There is a trick > > with saving part A of the line into temporary buffer, invalidating > > the line, and restoring part A in current ARM (MIPS) > > implementation. However, if somebody is writting to memory > > associated with part A of the line during this trick, the part A > > will be messed up. Moreover, the part A can be part of another DMA > > transaction. > > > > To safely use DMA with no coherent memory, a memory with [no cache] > > or [write throught] attributes can be used without problem. A > > memory with [write back] attribute must be aligned on > > CACHE_LINE_SIZE. > > > > However, for example mbuf, a buffer for DMA can be part of a > > structure which can be aligned on CACHE_LINE_SIZE, but not the > > buffer itself. We can know that nobody will write to the structure > > during DMA transaction, so it's safe to use the buffer event if > > it's not aligned on CACHE_LINE_SIZE. > > > > So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > > we want to avoid bounce pages overhead, we must support additional > > information to DMA transaction. It should be easy to support the > > information about drivers data buffers. However, what about OS data > > buffers like mentioned mbufs? > > > > The question is following. Is or can be guaranteed for all or at > > least well-known OS data buffers which can be part of DMA access > > that the not CACHE_LINE_SIZE aligned buffers are surrounded by data > > which belongs to the same object as the buffer and the data is not > > written by OS when given to a driver? > > > > Any answer is appreciated. However, 'bounce pages' is not an answer. > > > > Thanks, Svata >=20 > Sigh. A several ideas by several people, but a good answer has not > been created yet. SMP will make this worse. >=20 > To make things worse, there are drivers that use memory from the > stack as DMA buffers. >=20 > I was hoping that mbufs are pretty well self-contained, unless you > expect to modify them while DMA is happening. >=20 > This is on my to-do list. >=20 > --Mark. Drivers that do DMA from memory that was not allocated by proper busdma methods or load buffers for DMA using not properly constrained busdma tags are broken drivers. We did not have a busdma tag inheritance from parent bus to child devices before, but now we should just take advantage of that and just make cache line alignment a requirement for the platform. USB is firmly in that 'broken' category btw and is currently being worked around by the USB_HOST_ALIGN hack on MIPS, which suffers from the very same cache coherency issues you describe. --=20 Alexander Kabaev --Sig_/pHCWVeAVip/ysIJVHmMEvUv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPutFeQ6z1jMm+XZYRAqB9AJ49ZfOlIH3tV+xHt3sX7QwEE04nhACeP4k3 YMdpbSyHoLsLAtCU9oYy9bQ= =ResP -----END PGP SIGNATURE----- --Sig_/pHCWVeAVip/ysIJVHmMEvUv-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 02:43:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B66A71065673 for ; Tue, 22 May 2012 02:43:34 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8798FC18 for ; Tue, 22 May 2012 02:43:34 +0000 (UTC) Received: by yenl8 with SMTP id l8so6235026yen.13 for ; Mon, 21 May 2012 19:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=6eBV7oQmT7hHHznbs7dqVbnCssdapqPOPDh5lzzc5bY=; b=f2Tl9O6p0jem5Dxyc9r/GSmvugnIvj0F6fEBEYFu0R3cu2dbvgCBbR9Y+gGVzp3nMm +2Q+YfAdIW7oq8ztnJ3df9Gfhu16cDpZVI45H9FeXKvRwjfTYybQ6STJzhB6ONsxTCmz 4DY1GzjpHAuYdYgqWmlj6IpUhG0IEcd0ZBPKo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=6eBV7oQmT7hHHznbs7dqVbnCssdapqPOPDh5lzzc5bY=; b=kk7ABLlXDsqt86estV0tC0amZpPRO6VgzeM7TYRj8/51UaWNk8Q1Hnhcl/GENhxy7R CkkUHsioBIxrhoJaEmIlpkkCmZOJGnF+iepeA02XvKqhUVLQJ7IBhvDU3VOXmm/Is6o0 jUQphrrJPwKmS9hBwjcc88k6l10z08As3QhhYBZh2vc7f4D98fT1qvUWSBvcyg+4nfvp X/q7pN8gF9PwBonSAMBoHpPKz4Z1bMcOO2cEwJvQoUpLQCaHeDkWx9zwLp1CVUyqzyFA orCkxVvn+Hg5EsIV/yZZ3HzjEM6VRfbItENFh7/iC5VQl9ioeLcri/qbRCsPuQF8Y61y 7CrQ== Received: by 10.50.186.196 with SMTP id fm4mr74824igc.34.1337654613160; Mon, 21 May 2012 19:43:33 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id d5sm15630310iga.15.2012.05.21.19.43.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 19:43:32 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4M2hTrM050704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2012 22:43:30 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4M2hTaU050703; Mon, 21 May 2012 22:43:29 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Mon, 21 May 2012 22:43:29 -0400 From: Jason Hellenthal To: Jason Usher Message-ID: <20120522024329.GB17218@DataIX.net> References: <4FBA7CA2.5080703@FreeBSD.org> <1337635587.57757.YahooMailClassic@web122503.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1337635587.57757.YahooMailClassic@web122503.mail.ne1.yahoo.com> X-Gm-Message-State: ALoCoQk76mcuekQXmKqBc660dwH2FhMg4p0vSsH+FWCf1U+ilAsQic0FS2fgHtors89kLxsYZzZ6 Cc: freebsd-hackers@freebsd.org, Garance A Drosehn Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 02:43:34 -0000 On Mon, May 21, 2012 at 02:26:27PM -0700, Jason Usher wrote: > > > --- On Mon, 5/21/12, Garance A Drosehn wrote: > > > ???But have you tried it in this order ? > > > > ???HostKey /usr/local/etc/ssh/ssh_host_key > > ???HostKey > > /usr/local/etc/ssh/ssh_host_dsa_key > > ???HostKey > > /usr/local/etc/ssh/ssh_host_rsa_key > > ???HostKey > > /usr/local/etc/ssh/ssh_host_ecdsa_key > > > > Which is to say, have your sshd_config file list multiple > > hostkey's, and then restart sshd after making that change? > > I tried a similar change and it seemed to have some effect > > on what clients saw when connecting, but I can't tell if > > it has the effect that you want. > > > The order of HostKey directives in sshd_config does not change the actual order. In newer implementations, RSA is provided first, no matter how you configure the sshd_config. > > As I mentioned before, removing RSA completely is sort of a fix, but I can't do that because some people might actually be explicitly using RSA, and they would all break. > > Anyone ? The problem to me seems to be on the client end. Where the new ssh installation is attempting RSA authentication first rather than DSA and your ssh server has just now caught up to the clients. If I were you, I would just make an announcement providing the host fingerprints to clients and asking them to update known_hosts appropriately, rather than creating a virtual fix for sshd that you will have to maintain yourself. -- - (2^(N-1)) From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 06:02:38 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A205C1065692; Tue, 22 May 2012 06:02:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id DD0AA8FC17; Tue, 22 May 2012 06:02:37 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 110189664; Tue, 22 May 2012 07:57:29 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Tue, 22 May 2012 07:56:42 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120521193548.0b03a39a@kan.dyndns.org> In-Reply-To: <20120521193548.0b03a39a@kan.dyndns.org> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201205220756.43031.hselasky@c2i.net> Cc: hackers@freebsd.org, Svatopluk Kraus Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 06:02:38 -0000 On Tuesday 22 May 2012 01:35:48 Alexander Kabaev wrote: > On Thu, 17 May 2012 11:01:34 -0500 > > Mark Tinguely wrote: > > On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus > > > > wrote: > > > Hi, > > > > > > I'm working on DMA bus implementation for ARM11mpcore platform. I've > > > looked at implementation in ARM tree, but IMHO it only works with > > > some assumptions. There is a problem with DMA on memory block which > > > is not aligned on CACHE_LINE_SIZE (start and end) if memory is not > > > coherent. > > > > > > Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > > > Then first cache line associated with the buffer can be divided into > > > two parts, A and B, where A is a memory we know nothing about it > > > and B is buffer memory. The same stands for last cache line > > > associatted with the buffer. We have no problem if a memory is > > > coherent. Otherwise it depends on memory attributes. > > > > > > 1. [no cache] attribute > > > No problem as memory is coherent. > > > > > > 2. [write throught] attribute > > > The part A can be invalidated without loss of any data. It's not > > > problem too. > > > > > > 3. [write back] attribute > > > In general, there is no way how to keep both parts consistent. At > > > the start of DMA transaction, the cache line is written back and > > > invalidated. However, as we know nothing about memory associated > > > with part A of the cache line, the cache line can be filled again > > > at any time and messing up DMA transaction if flushed. Even if the > > > cache line is only filled but not flushed during DMA transaction, > > > we must make it coherent with memory after that. There is a trick > > > with saving part A of the line into temporary buffer, invalidating > > > the line, and restoring part A in current ARM (MIPS) > > > implementation. However, if somebody is writting to memory > > > associated with part A of the line during this trick, the part A > > > will be messed up. Moreover, the part A can be part of another DMA > > > transaction. > > > > > > To safely use DMA with no coherent memory, a memory with [no cache] > > > or [write throught] attributes can be used without problem. A > > > memory with [write back] attribute must be aligned on > > > CACHE_LINE_SIZE. > > > > > > However, for example mbuf, a buffer for DMA can be part of a > > > structure which can be aligned on CACHE_LINE_SIZE, but not the > > > buffer itself. We can know that nobody will write to the structure > > > during DMA transaction, so it's safe to use the buffer event if > > > it's not aligned on CACHE_LINE_SIZE. > > > > > > So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > > > we want to avoid bounce pages overhead, we must support additional > > > information to DMA transaction. It should be easy to support the > > > information about drivers data buffers. However, what about OS data > > > buffers like mentioned mbufs? > > > > > > The question is following. Is or can be guaranteed for all or at > > > least well-known OS data buffers which can be part of DMA access > > > that the not CACHE_LINE_SIZE aligned buffers are surrounded by data > > > which belongs to the same object as the buffer and the data is not > > > written by OS when given to a driver? > > > > > > Any answer is appreciated. However, 'bounce pages' is not an answer. > > > > > > Thanks, Svata > > > > Sigh. A several ideas by several people, but a good answer has not > > been created yet. SMP will make this worse. > > > > To make things worse, there are drivers that use memory from the > > stack as DMA buffers. > > > > I was hoping that mbufs are pretty well self-contained, unless you > > expect to modify them while DMA is happening. > > > > This is on my to-do list. > > > > --Mark. > > Drivers that do DMA from memory that was not allocated by proper busdma > methods or load buffers for DMA using not properly constrained busdma > tags are broken drivers. We did not have a busdma tag inheritance from > parent bus to child devices before, but now we should just take > advantage of that and just make cache line alignment a requirement for > the platform. USB is firmly in that 'broken' category btw and is > currently being worked around by the USB_HOST_ALIGN hack on MIPS, which > suffers from the very same cache coherency issues you describe. Hi, Drivers do not always use the same buffer format. That mean two entities exchanging data using different buffer allocations must either: 1) Copy the data 2) Negotiate parameters for zero copy Many USB protocols have headers which are designed without any thought about ARM's and CACHE alignment. That means byte access via DMA must be supported, else you end up having to copy the data en-mass. The USB_HOST_ALIGN is not a hack. It is coherently implemented across EHCI, OHCI, UHCI and XHCI drivers, which are currently the only USB drivers using DMA. BUSDMA must instruct use of bounce buffers for case 1) for such CPU's where the loading address does not satisfy the CACHE alignment restrictions for DMA. Simply copying the data into a correctly aligned buffer can sometimes be much quicker than trying to handle the cache correctly. Even though the data will be copied one extra time. This of course depends on how much data is moved at a time. --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 06:02:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A205C1065692; Tue, 22 May 2012 06:02:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id DD0AA8FC17; Tue, 22 May 2012 06:02:37 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 110189664; Tue, 22 May 2012 07:57:29 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Tue, 22 May 2012 07:56:42 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120521193548.0b03a39a@kan.dyndns.org> In-Reply-To: <20120521193548.0b03a39a@kan.dyndns.org> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201205220756.43031.hselasky@c2i.net> Cc: hackers@freebsd.org, Svatopluk Kraus Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 06:02:38 -0000 On Tuesday 22 May 2012 01:35:48 Alexander Kabaev wrote: > On Thu, 17 May 2012 11:01:34 -0500 > > Mark Tinguely wrote: > > On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus > > > > wrote: > > > Hi, > > > > > > I'm working on DMA bus implementation for ARM11mpcore platform. I've > > > looked at implementation in ARM tree, but IMHO it only works with > > > some assumptions. There is a problem with DMA on memory block which > > > is not aligned on CACHE_LINE_SIZE (start and end) if memory is not > > > coherent. > > > > > > Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > > > Then first cache line associated with the buffer can be divided into > > > two parts, A and B, where A is a memory we know nothing about it > > > and B is buffer memory. The same stands for last cache line > > > associatted with the buffer. We have no problem if a memory is > > > coherent. Otherwise it depends on memory attributes. > > > > > > 1. [no cache] attribute > > > No problem as memory is coherent. > > > > > > 2. [write throught] attribute > > > The part A can be invalidated without loss of any data. It's not > > > problem too. > > > > > > 3. [write back] attribute > > > In general, there is no way how to keep both parts consistent. At > > > the start of DMA transaction, the cache line is written back and > > > invalidated. However, as we know nothing about memory associated > > > with part A of the cache line, the cache line can be filled again > > > at any time and messing up DMA transaction if flushed. Even if the > > > cache line is only filled but not flushed during DMA transaction, > > > we must make it coherent with memory after that. There is a trick > > > with saving part A of the line into temporary buffer, invalidating > > > the line, and restoring part A in current ARM (MIPS) > > > implementation. However, if somebody is writting to memory > > > associated with part A of the line during this trick, the part A > > > will be messed up. Moreover, the part A can be part of another DMA > > > transaction. > > > > > > To safely use DMA with no coherent memory, a memory with [no cache] > > > or [write throught] attributes can be used without problem. A > > > memory with [write back] attribute must be aligned on > > > CACHE_LINE_SIZE. > > > > > > However, for example mbuf, a buffer for DMA can be part of a > > > structure which can be aligned on CACHE_LINE_SIZE, but not the > > > buffer itself. We can know that nobody will write to the structure > > > during DMA transaction, so it's safe to use the buffer event if > > > it's not aligned on CACHE_LINE_SIZE. > > > > > > So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > > > we want to avoid bounce pages overhead, we must support additional > > > information to DMA transaction. It should be easy to support the > > > information about drivers data buffers. However, what about OS data > > > buffers like mentioned mbufs? > > > > > > The question is following. Is or can be guaranteed for all or at > > > least well-known OS data buffers which can be part of DMA access > > > that the not CACHE_LINE_SIZE aligned buffers are surrounded by data > > > which belongs to the same object as the buffer and the data is not > > > written by OS when given to a driver? > > > > > > Any answer is appreciated. However, 'bounce pages' is not an answer. > > > > > > Thanks, Svata > > > > Sigh. A several ideas by several people, but a good answer has not > > been created yet. SMP will make this worse. > > > > To make things worse, there are drivers that use memory from the > > stack as DMA buffers. > > > > I was hoping that mbufs are pretty well self-contained, unless you > > expect to modify them while DMA is happening. > > > > This is on my to-do list. > > > > --Mark. > > Drivers that do DMA from memory that was not allocated by proper busdma > methods or load buffers for DMA using not properly constrained busdma > tags are broken drivers. We did not have a busdma tag inheritance from > parent bus to child devices before, but now we should just take > advantage of that and just make cache line alignment a requirement for > the platform. USB is firmly in that 'broken' category btw and is > currently being worked around by the USB_HOST_ALIGN hack on MIPS, which > suffers from the very same cache coherency issues you describe. Hi, Drivers do not always use the same buffer format. That mean two entities exchanging data using different buffer allocations must either: 1) Copy the data 2) Negotiate parameters for zero copy Many USB protocols have headers which are designed without any thought about ARM's and CACHE alignment. That means byte access via DMA must be supported, else you end up having to copy the data en-mass. The USB_HOST_ALIGN is not a hack. It is coherently implemented across EHCI, OHCI, UHCI and XHCI drivers, which are currently the only USB drivers using DMA. BUSDMA must instruct use of bounce buffers for case 1) for such CPU's where the loading address does not satisfy the CACHE alignment restrictions for DMA. Simply copying the data into a correctly aligned buffer can sometimes be much quicker than trying to handle the cache correctly. Even though the data will be copied one extra time. This of course depends on how much data is moved at a time. --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 06:17:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86CF0106566C for ; Tue, 22 May 2012 06:17:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 171238FC08 for ; Tue, 22 May 2012 06:17:41 +0000 (UTC) Received: from [89.204.153.130] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SWiPY-0003gy-Pa; Tue, 22 May 2012 08:17:37 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q4M6HaNK001258; Tue, 22 May 2012 08:17:36 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q4M6HZfv001257; Tue, 22 May 2012 08:17:35 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 22 May 2012 08:17:35 +0200 From: Matthias Apitz To: rozhuk.im@gmail.com Message-ID: <20120522061734.GA1210@tiny> References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.153.130 Cc: 'User Wojtek' , freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 06:17:41 -0000 El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk.im@gmail.com escribió: > > My EeePC netbook shows for the two SSD: > > > > $ uname -a > > FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 > > 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 > > $ gpart show > > => 63 7880481 ada0 MBR (3.8G) > > 63 7880481 1 freebsd [active] (3.8G) > > > > => 63 31522113 ada1 MBR (15G) > > 63 31522113 1 freebsd [active] (15G) > > > > => 0 7880481 ada0s1 BSD (3.8G) > > 0 16 - free - (8.0k) > > 16 7880465 1 freebsd-ufs (3.8G) > > > > => 0 31522113 ada1s1 BSD (15G) > > 0 16 - free - (8.0k) > > 16 31522097 1 freebsd-ufs (15G) > > > > Do not use MBR (or manually do all to align). > 63 - not 4k aligned. Hi, To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 # bsdlabel -w ada0s1 auto # bsdlabel -B ada0s1 changed partition "a" from "unused" to "4.2BSD" as partition type: # setenv EDITOR /usr/bin/vi # bsdlabel -e ada0s1 created the future root-filesystem on it # newfs -m 0 -o space /dev/ada0s1a The 2nd SSD was formated like this: # dd if=/dev/zero of=/dev/ada1 count=2 # fdisk -I /dev/ada1 # newfs -m 0 -o space /dev/ada1s1a # echo "/dev/ada1s1a /usr/local ufs rw,noatime 1 1" >> /etc/fstab # mount /usr/local What is wrong with this procedure? Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 06:29:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5DD91065674; Tue, 22 May 2012 06:29:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3CF8FC22; Tue, 22 May 2012 06:29:58 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id 286CDA7071; Tue, 22 May 2012 08:29:39 +0200 (CEST) Message-ID: <4FBB3268.5070105@FreeBSD.org> Date: Tue, 22 May 2012 08:30:00 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120512 Thunderbird/13.0 MIME-Version: 1.0 To: Yanhui Shen References: In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Something wrong with curs_threads(3X) ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 06:29:58 -0000 On 2012-05-21 18:41, Yanhui Shen wrote: > In curs_threads(3X), at the beginning of the manual: > > typedef int (*NCURSES_WINDOW_CB)(WINDOW *, void *); typedef int >> (*NCURSES_SCREEN_CB)(SCREEN *, void *); >> int set_escdelay(int size); >> int set_tabsize(int size); >> int use_screen(SCREEN *scr, NCURSES_WINDOW_CB func, void *data); >> int use_window(WINDOW *win, NCURSES_SCREEN_CB func, void *data); That's indeed a documentation error. Fixed in r235773, thanks! From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 08:50:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A639D1065674 for ; Tue, 22 May 2012 08:50:32 +0000 (UTC) (envelope-from scherfreebsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 26CA08FC0A for ; Tue, 22 May 2012 08:50:31 +0000 (UTC) Received: by bkvi18 with SMTP id i18so6426008bkv.13 for ; Tue, 22 May 2012 01:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:resent-from:date:cc :content-transfer-encoding:resent-date:message-id:resent-to:to :x-mailer; bh=Y7zyjZlWd+/desSSRuMjpcuJQ/IIjo0BvXqTm/4DHtQ=; b=WxfaQMiNbMZeDVQVZo3OAUKL8CJ9PYiBnOR5Eu5VUb+L9smBeZLy3nvhr1sAYRVze+ 9FraO+7fOJe/e+sH3XWS5FjvCDxvtszqU5swKzJ+GCuVZHuLNyINwXKsVfG+biY797+0 MTmYlkCmYaLHhCg/P0wqedN5fzEzb39lKQ+dMdd5WIm16HL4jg2jr3SrVRvIEQ1ezL4l J4LSRLT7P95h/17T+ypoml/T0R67Jo/igkw2h/bAaZkLroUwYUNlzi3g9nonyJrBO5HF kwMFJoVJpXW6knUiVY3FlK1Szv3Z6QlyMg57sCwHmwPwSvGnlAFjL4dSw7WU4m79iSH+ APJg== Received: by 10.205.133.197 with SMTP id hz5mr9396819bkc.126.1337676630903; Tue, 22 May 2012 01:50:30 -0700 (PDT) Received: from [192.168.0.100] ([77.66.153.242]) by mx.google.com with ESMTPS id gw6sm30730116bkc.16.2012.05.22.01.50.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 May 2012 01:50:30 -0700 (PDT) Sender: Alexander Pronin Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alexander Pronin Resent-From: Alexander Pronin Date: Mon, 21 May 2012 10:12:14 +0400 Content-Transfer-Encoding: quoted-printable Resent-Date: Tue, 22 May 2012 12:50:24 +0400 Message-Id: <30492E12-34D8-4F8B-B9DA-92166F3586E1@FreeBSD.org> Resent-To: freebsd-hackers@freebsd.org To: freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.1278) Resent-Message-Id: <20120522085032.A639D1065674@hub.freebsd.org> Cc: Marcus von Appen Subject: [ GSOC ] Project: Parallelization in the ports collection X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 08:50:32 -0000 Hello Community. My name is Alexander Pronin. I am a GSOC student at The FreeBSD Project. My project is "Parallelization in the ports collection and pkgng = utility" I have created wiki page where I described problems that I have to solve = and approaches to solving this problems. ( = http://wiki.freebsd.org/SummerOfCode2012/Parallelization_in_the_ports_coll= ection ) But some problems still seem to be unsolved. I would be grateful to discuss my project ideas. So any feedback is more = that appreciated. --- Best regards, Alexander Pronin= From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 10:05:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CE45106564A for ; Tue, 22 May 2012 10:05:51 +0000 (UTC) (envelope-from s@samu.pl) Received: from mail.mydevil.net (mail.mydevil.net [94.23.92.220]) by mx1.freebsd.org (Postfix) with ESMTP id 41EC48FC14 for ; Tue, 22 May 2012 10:05:51 +0000 (UTC) Received: from [192.168.1.101] (user-46-113-83-171.play-internet.pl [46.113.83.171]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.mydevil.net (Postfix) with ESMTPSA id 4772FA7F3 for ; Tue, 22 May 2012 12:04:50 +0200 (CEST) Message-ID: <4FBB64F2.1020000@samu.pl> Date: Tue, 22 May 2012 12:05:38 +0200 From: =?UTF-8?B?SmFrdWIgU3phZnJhxYRza2k=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org. X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Separating IP addresses between users X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 10:05:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16.05.2012 21:06, Will Froning wrote: > Hello Jakub, > > I've never used it, but have you looked at authpf(8)? A quick look at the man pages suggest you can have different NAT entries per-user. > > Thanks, > Will > > -- > Will Froning > Unix SysAdmin > Will.Froning@GMail.com > MSN: wfroning@angui.sh Hi, If I understand the manual page correctly, it allows for per user NAT entriees, but only on their sshd(8) sessions. What I need is to separate every service of an user - crontab launched software, php-spawned applications, every possible aspect of his account. A jail-based solution would be fine, so that the user can 'see' all the IPs I allow him to 'see' in a network interface. (I hope that my mail client isn't screwed up again and I've actually replied to the maillist, and not started a new thread...) - -- Best Regards, Jakub SzafraÅ„ski -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEbBAEBAgAGBQJPu2TyAAoJEMFTYabJw8eXj84H+MY9NU1jrEfvzvJOL+Kf8+A/ 8l4XzN/qkmsDV2WuzwGByZNmeTSH89V3iVSic6mAL1agMnDuY1TV5rbslX/b+uNd fwwbFW279OEsRhVXAFTT6i+8yGab47Zw28SoF+fTPvW+FarL2rCROrsYnI7qff0L 9kRJ4BD8taS1RFDZZj13nHuHWnQlApCib3NAEQumiWXILS9eNHLAs9lNV1P24baW JWpz4spCYnN6jKjDPnN4PXERHMLYTvZy9DUl6x9GWcT7V4OL80z72ur/tomIXvZ6 UHYrBU72TkJCTMi8Nw7DV/NYeL3ACFWQN8lFO4cOB07mc3bJrdy4tylu/iFqlA== =kdWX -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 11:15:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8560106564A; Tue, 22 May 2012 11:15:37 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 61FEB8FC12; Tue, 22 May 2012 11:15:37 +0000 (UTC) Received: by qcsg15 with SMTP id g15so4864321qcs.13 for ; Tue, 22 May 2012 04:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=4MjPEAGLOZVZ5IiS05JhTund/TrvaFY6h/1LJomtBhU=; b=kbM17urX3cqR7FIDzjkF9OZseZKhF+6jdhnDBq7iSOF2XNe3hkcdNDHxb3EfR38pov WegGdg9ubAQrsay/FE2F++tgYdiaijTBI7ImaL82hhXzHeJwkzs7O+VBJ01hpLfTE2ez pSaAw+K01T/ijgLgvfqSH3ousGcobn0MJL+ukcogEb7NIQDaUpRiEOx0ZL2vBO1r2RG5 2Mw+9uKMCG7gdyhBlLRMVClT57X4/wKvXXo0cIhCLYHFbNpBVAiYYAg6RSq7WPU4Gm9d PA5vRUjD0aBLxVV5YFxRWpKs0a/khc4y9ejovwY0lPoZ/+ND2f9S+1jMuChif4yo7bvT Q5fA== Received: by 10.224.34.9 with SMTP id j9mr44074318qad.14.1337685336580; Tue, 22 May 2012 04:15:36 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id s20sm44884906qap.16.2012.05.22.04.15.34 (version=SSLv3 cipher=OTHER); Tue, 22 May 2012 04:15:35 -0700 (PDT) Date: Tue, 22 May 2012 07:15:29 -0400 From: Alexander Kabaev To: Hans Petter Selasky Message-ID: <20120522071529.7024604c@kan.dyndns.org> In-Reply-To: <201205220756.43031.hselasky@c2i.net> References: <20120521193548.0b03a39a@kan.dyndns.org> <201205220756.43031.hselasky@c2i.net> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/.VimYYiHvRXBu6csQ.HtaeF"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Svatopluk Kraus Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 11:15:37 -0000 --Sig_/.VimYYiHvRXBu6csQ.HtaeF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 22 May 2012 07:56:42 +0200 Hans Petter Selasky wrote: > On Tuesday 22 May 2012 01:35:48 Alexander Kabaev wrote: > > On Thu, 17 May 2012 11:01:34 -0500 > >=20 > > Mark Tinguely wrote: > > > On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus > > > > > >=20 > > > wrote: > > > > Hi, > > > >=20 > > > > I'm working on DMA bus implementation for ARM11mpcore platform. > > > > I've looked at implementation in ARM tree, but IMHO it only > > > > works with some assumptions. There is a problem with DMA on > > > > memory block which is not aligned on CACHE_LINE_SIZE (start and > > > > end) if memory is not coherent. > > > >=20 > > > > Let's have a buffer for DMA which is no aligned on > > > > CACHE_LINE_SIZE. Then first cache line associated with the > > > > buffer can be divided into two parts, A and B, where A is a > > > > memory we know nothing about it and B is buffer memory. The > > > > same stands for last cache line associatted with the buffer. We > > > > have no problem if a memory is coherent. Otherwise it depends > > > > on memory attributes. > > > >=20 > > > > 1. [no cache] attribute > > > > No problem as memory is coherent. > > > >=20 > > > > 2. [write throught] attribute > > > > The part A can be invalidated without loss of any data. It's not > > > > problem too. > > > >=20 > > > > 3. [write back] attribute > > > > In general, there is no way how to keep both parts consistent. > > > > At the start of DMA transaction, the cache line is written back > > > > and invalidated. However, as we know nothing about memory > > > > associated with part A of the cache line, the cache line can be > > > > filled again at any time and messing up DMA transaction if > > > > flushed. Even if the cache line is only filled but not flushed > > > > during DMA transaction, we must make it coherent with memory > > > > after that. There is a trick with saving part A of the line > > > > into temporary buffer, invalidating the line, and restoring > > > > part A in current ARM (MIPS) implementation. However, if > > > > somebody is writting to memory associated with part A of the > > > > line during this trick, the part A will be messed up. Moreover, > > > > the part A can be part of another DMA transaction. > > > >=20 > > > > To safely use DMA with no coherent memory, a memory with [no > > > > cache] or [write throught] attributes can be used without > > > > problem. A memory with [write back] attribute must be aligned on > > > > CACHE_LINE_SIZE. > > > >=20 > > > > However, for example mbuf, a buffer for DMA can be part of a > > > > structure which can be aligned on CACHE_LINE_SIZE, but not the > > > > buffer itself. We can know that nobody will write to the > > > > structure during DMA transaction, so it's safe to use the > > > > buffer event if it's not aligned on CACHE_LINE_SIZE. > > > >=20 > > > > So, in practice, if DMA buffer is not aligned on > > > > CACHE_LINE_SIZE and we want to avoid bounce pages overhead, we > > > > must support additional information to DMA transaction. It > > > > should be easy to support the information about drivers data > > > > buffers. However, what about OS data buffers like mentioned > > > > mbufs? > > > >=20 > > > > The question is following. Is or can be guaranteed for all or at > > > > least well-known OS data buffers which can be part of DMA access > > > > that the not CACHE_LINE_SIZE aligned buffers are surrounded by > > > > data which belongs to the same object as the buffer and the > > > > data is not written by OS when given to a driver? > > > >=20 > > > > Any answer is appreciated. However, 'bounce pages' is not an > > > > answer. > > > >=20 > > > > Thanks, Svata > > >=20 > > > Sigh. A several ideas by several people, but a good answer has not > > > been created yet. SMP will make this worse. > > >=20 > > > To make things worse, there are drivers that use memory from the > > > stack as DMA buffers. > > >=20 > > > I was hoping that mbufs are pretty well self-contained, unless you > > > expect to modify them while DMA is happening. > > >=20 > > > This is on my to-do list. > > >=20 > > > --Mark. > >=20 > > Drivers that do DMA from memory that was not allocated by proper > > busdma methods or load buffers for DMA using not properly > > constrained busdma tags are broken drivers. We did not have a > > busdma tag inheritance from parent bus to child devices before, but > > now we should just take advantage of that and just make cache line > > alignment a requirement for the platform. USB is firmly in that > > 'broken' category btw and is currently being worked around by the > > USB_HOST_ALIGN hack on MIPS, which suffers from the very same cache > > coherency issues you describe. >=20 > Hi, >=20 > Drivers do not always use the same buffer format. That mean two > entities exchanging data using different buffer allocations must > either: >=20 > 1) Copy the data > 2) Negotiate parameters for zero copy >=20 > Many USB protocols have headers which are designed without any > thought about ARM's and CACHE alignment. That means byte access via > DMA must be supported, else you end up having to copy the data > en-mass. >=20 > The USB_HOST_ALIGN is not a hack. It is coherently implemented across > EHCI, OHCI, UHCI and XHCI drivers, which are currently the only USB > drivers using DMA. >=20 > BUSDMA must instruct use of bounce buffers for case 1) for such CPU's > where the loading address does not satisfy the CACHE alignment > restrictions for DMA. >=20 > Simply copying the data into a correctly aligned buffer can sometimes > be much quicker than trying to handle the cache correctly. Even > though the data will be copied one extra time. This of course depends > on how much data is moved at a time. >=20 > --HPS There is a difference between dealing with data of arbitrary origin, such as zero-copy userland buffer, which might force the use of bounce buffers, and allocating dma-able region in the middle of data structure which itself is allocated by the plain malloc, with no regards to DMA restrictions that device's parent bus might we trying to enforce on its children. Former is a necessity, latter is a self-inflicted pain. --=20 Alexander Kabaev --Sig_/.VimYYiHvRXBu6csQ.HtaeF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPu3VVQ6z1jMm+XZYRAms6AKDCNkgASUTvFNrFD0oQSUmpL8lzbwCeOlfe wVRp9mtE/20r5EgaGtsCQys= =4n6g -----END PGP SIGNATURE----- --Sig_/.VimYYiHvRXBu6csQ.HtaeF-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 11:15:37 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8560106564A; Tue, 22 May 2012 11:15:37 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 61FEB8FC12; Tue, 22 May 2012 11:15:37 +0000 (UTC) Received: by qcsg15 with SMTP id g15so4864321qcs.13 for ; Tue, 22 May 2012 04:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=4MjPEAGLOZVZ5IiS05JhTund/TrvaFY6h/1LJomtBhU=; b=kbM17urX3cqR7FIDzjkF9OZseZKhF+6jdhnDBq7iSOF2XNe3hkcdNDHxb3EfR38pov WegGdg9ubAQrsay/FE2F++tgYdiaijTBI7ImaL82hhXzHeJwkzs7O+VBJ01hpLfTE2ez pSaAw+K01T/ijgLgvfqSH3ousGcobn0MJL+ukcogEb7NIQDaUpRiEOx0ZL2vBO1r2RG5 2Mw+9uKMCG7gdyhBlLRMVClT57X4/wKvXXo0cIhCLYHFbNpBVAiYYAg6RSq7WPU4Gm9d PA5vRUjD0aBLxVV5YFxRWpKs0a/khc4y9ejovwY0lPoZ/+ND2f9S+1jMuChif4yo7bvT Q5fA== Received: by 10.224.34.9 with SMTP id j9mr44074318qad.14.1337685336580; Tue, 22 May 2012 04:15:36 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id s20sm44884906qap.16.2012.05.22.04.15.34 (version=SSLv3 cipher=OTHER); Tue, 22 May 2012 04:15:35 -0700 (PDT) Date: Tue, 22 May 2012 07:15:29 -0400 From: Alexander Kabaev To: Hans Petter Selasky Message-ID: <20120522071529.7024604c@kan.dyndns.org> In-Reply-To: <201205220756.43031.hselasky@c2i.net> References: <20120521193548.0b03a39a@kan.dyndns.org> <201205220756.43031.hselasky@c2i.net> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/.VimYYiHvRXBu6csQ.HtaeF"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Svatopluk Kraus Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 11:15:37 -0000 --Sig_/.VimYYiHvRXBu6csQ.HtaeF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 22 May 2012 07:56:42 +0200 Hans Petter Selasky wrote: > On Tuesday 22 May 2012 01:35:48 Alexander Kabaev wrote: > > On Thu, 17 May 2012 11:01:34 -0500 > >=20 > > Mark Tinguely wrote: > > > On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus > > > > > >=20 > > > wrote: > > > > Hi, > > > >=20 > > > > I'm working on DMA bus implementation for ARM11mpcore platform. > > > > I've looked at implementation in ARM tree, but IMHO it only > > > > works with some assumptions. There is a problem with DMA on > > > > memory block which is not aligned on CACHE_LINE_SIZE (start and > > > > end) if memory is not coherent. > > > >=20 > > > > Let's have a buffer for DMA which is no aligned on > > > > CACHE_LINE_SIZE. Then first cache line associated with the > > > > buffer can be divided into two parts, A and B, where A is a > > > > memory we know nothing about it and B is buffer memory. The > > > > same stands for last cache line associatted with the buffer. We > > > > have no problem if a memory is coherent. Otherwise it depends > > > > on memory attributes. > > > >=20 > > > > 1. [no cache] attribute > > > > No problem as memory is coherent. > > > >=20 > > > > 2. [write throught] attribute > > > > The part A can be invalidated without loss of any data. It's not > > > > problem too. > > > >=20 > > > > 3. [write back] attribute > > > > In general, there is no way how to keep both parts consistent. > > > > At the start of DMA transaction, the cache line is written back > > > > and invalidated. However, as we know nothing about memory > > > > associated with part A of the cache line, the cache line can be > > > > filled again at any time and messing up DMA transaction if > > > > flushed. Even if the cache line is only filled but not flushed > > > > during DMA transaction, we must make it coherent with memory > > > > after that. There is a trick with saving part A of the line > > > > into temporary buffer, invalidating the line, and restoring > > > > part A in current ARM (MIPS) implementation. However, if > > > > somebody is writting to memory associated with part A of the > > > > line during this trick, the part A will be messed up. Moreover, > > > > the part A can be part of another DMA transaction. > > > >=20 > > > > To safely use DMA with no coherent memory, a memory with [no > > > > cache] or [write throught] attributes can be used without > > > > problem. A memory with [write back] attribute must be aligned on > > > > CACHE_LINE_SIZE. > > > >=20 > > > > However, for example mbuf, a buffer for DMA can be part of a > > > > structure which can be aligned on CACHE_LINE_SIZE, but not the > > > > buffer itself. We can know that nobody will write to the > > > > structure during DMA transaction, so it's safe to use the > > > > buffer event if it's not aligned on CACHE_LINE_SIZE. > > > >=20 > > > > So, in practice, if DMA buffer is not aligned on > > > > CACHE_LINE_SIZE and we want to avoid bounce pages overhead, we > > > > must support additional information to DMA transaction. It > > > > should be easy to support the information about drivers data > > > > buffers. However, what about OS data buffers like mentioned > > > > mbufs? > > > >=20 > > > > The question is following. Is or can be guaranteed for all or at > > > > least well-known OS data buffers which can be part of DMA access > > > > that the not CACHE_LINE_SIZE aligned buffers are surrounded by > > > > data which belongs to the same object as the buffer and the > > > > data is not written by OS when given to a driver? > > > >=20 > > > > Any answer is appreciated. However, 'bounce pages' is not an > > > > answer. > > > >=20 > > > > Thanks, Svata > > >=20 > > > Sigh. A several ideas by several people, but a good answer has not > > > been created yet. SMP will make this worse. > > >=20 > > > To make things worse, there are drivers that use memory from the > > > stack as DMA buffers. > > >=20 > > > I was hoping that mbufs are pretty well self-contained, unless you > > > expect to modify them while DMA is happening. > > >=20 > > > This is on my to-do list. > > >=20 > > > --Mark. > >=20 > > Drivers that do DMA from memory that was not allocated by proper > > busdma methods or load buffers for DMA using not properly > > constrained busdma tags are broken drivers. We did not have a > > busdma tag inheritance from parent bus to child devices before, but > > now we should just take advantage of that and just make cache line > > alignment a requirement for the platform. USB is firmly in that > > 'broken' category btw and is currently being worked around by the > > USB_HOST_ALIGN hack on MIPS, which suffers from the very same cache > > coherency issues you describe. >=20 > Hi, >=20 > Drivers do not always use the same buffer format. That mean two > entities exchanging data using different buffer allocations must > either: >=20 > 1) Copy the data > 2) Negotiate parameters for zero copy >=20 > Many USB protocols have headers which are designed without any > thought about ARM's and CACHE alignment. That means byte access via > DMA must be supported, else you end up having to copy the data > en-mass. >=20 > The USB_HOST_ALIGN is not a hack. It is coherently implemented across > EHCI, OHCI, UHCI and XHCI drivers, which are currently the only USB > drivers using DMA. >=20 > BUSDMA must instruct use of bounce buffers for case 1) for such CPU's > where the loading address does not satisfy the CACHE alignment > restrictions for DMA. >=20 > Simply copying the data into a correctly aligned buffer can sometimes > be much quicker than trying to handle the cache correctly. Even > though the data will be copied one extra time. This of course depends > on how much data is moved at a time. >=20 > --HPS There is a difference between dealing with data of arbitrary origin, such as zero-copy userland buffer, which might force the use of bounce buffers, and allocating dma-able region in the middle of data structure which itself is allocated by the plain malloc, with no regards to DMA restrictions that device's parent bus might we trying to enforce on its children. Former is a necessity, latter is a self-inflicted pain. --=20 Alexander Kabaev --Sig_/.VimYYiHvRXBu6csQ.HtaeF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPu3VVQ6z1jMm+XZYRAms6AKDCNkgASUTvFNrFD0oQSUmpL8lzbwCeOlfe wVRp9mtE/20r5EgaGtsCQys= =4n6g -----END PGP SIGNATURE----- --Sig_/.VimYYiHvRXBu6csQ.HtaeF-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 13:42:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC65B106566B for ; Tue, 22 May 2012 13:42:19 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 92DDF8FC08 for ; Tue, 22 May 2012 13:42:19 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q4MDgIYr051678; Tue, 22 May 2012 07:42:18 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q4MDgID5051675; Tue, 22 May 2012 07:42:18 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 22 May 2012 07:42:18 -0600 (MDT) From: Warren Block To: Matthias Apitz In-Reply-To: <20120522061734.GA1210@tiny> Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-248074046-1337694138=:51493" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 22 May 2012 07:42:18 -0600 (MDT) Cc: 'User Wojtek' , rozhuk.im@gmail.com, freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 13:42:19 -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. ---902635197-248074046-1337694138=:51493 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 22 May 2012, Matthias Apitz wrote: > El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk.im@gmail.com escribió: >> >> Do not use MBR (or manually do all to align). >> 63 - not 4k aligned. > > To create the above shown partition layout I have not used gpart(8); I > just said: > > # fdisk -I /dev/ada0 > # fdisk -B /dev/ada0 > > # bsdlabel -w ada0s1 auto > # bsdlabel -B ada0s1 > > changed partition "a" from "unused" to "4.2BSD" as partition type: > > # setenv EDITOR /usr/bin/vi > # bsdlabel -e ada0s1 > > created the future root-filesystem on it > > # newfs -m 0 -o space /dev/ada0s1a > > The 2nd SSD was formated like this: > > # dd if=/dev/zero of=/dev/ada1 count=2 > # fdisk -I /dev/ada1 > # newfs -m 0 -o space /dev/ada1s1a > # echo "/dev/ada1s1a /usr/local ufs rw,noatime 1 1" >> /etc/fstab > # mount /usr/local > > What is wrong with this procedure? The filesystem partitions end up at locations that aren't even multiples of 4K. This can reduce performance. How much probably depends on the SSD. ---902635197-248074046-1337694138=:51493-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 13:48:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 349621065670 for ; Tue, 22 May 2012 13:48:55 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id DE0898FC0A for ; Tue, 22 May 2012 13:48:54 +0000 (UTC) Received: from [89.204.153.130] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SWpSD-0005Ur-Oc for freebsd-hackers@freebsd.org; Tue, 22 May 2012 15:48:50 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q4MDmlCS002280 for ; Tue, 22 May 2012 15:48:48 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q4MDml3n002279 for freebsd-hackers@freebsd.org; Tue, 22 May 2012 15:48:47 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 22 May 2012 15:48:47 +0200 From: Matthias Apitz To: freebsd-hackers@freebsd.org Message-ID: <20120522134846.GA2274@tiny> References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.153.130 Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 13:48:55 -0000 El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió: > On Tue, 22 May 2012, Matthias Apitz wrote: > > > El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk.im@gmail.com escribió: > >> > >> Do not use MBR (or manually do all to align). > >> 63 - not 4k aligned. > > > > To create the above shown partition layout I have not used gpart(8); I > > just said: > > > > # fdisk -I /dev/ada0 > > # fdisk -B /dev/ada0 > > > > ... > > What is wrong with this procedure? > > The filesystem partitions end up at locations that aren't even multiples > of 4K. This can reduce performance. How much probably depends on the > SSD. But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 14:40:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 839CE1065680 for ; Tue, 22 May 2012 14:40:57 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 3ADE48FC15 for ; Tue, 22 May 2012 14:40:56 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q4MEeuHu051909; Tue, 22 May 2012 08:40:56 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q4MEeufD051906; Tue, 22 May 2012 08:40:56 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 22 May 2012 08:40:56 -0600 (MDT) From: Warren Block To: Matthias Apitz In-Reply-To: <20120522134846.GA2274@tiny> Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> <20120522134846.GA2274@tiny> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-698640261-1337697656=:51493" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 22 May 2012 08:40:56 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:40:57 -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. ---902635197-698640261-1337697656=:51493 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 22 May 2012, Matthias Apitz wrote: > El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió: > >> On Tue, 22 May 2012, Matthias Apitz wrote: >> >>> El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk.im@gmail.com escribió: >>>> >>>> Do not use MBR (or manually do all to align). >>>> 63 - not 4k aligned. >>> >>> To create the above shown partition layout I have not used gpart(8); I >>> just said: >>> >>> # fdisk -I /dev/ada0 >>> # fdisk -B /dev/ada0 >>> >>> ... >>> What is wrong with this procedure? >> >> The filesystem partitions end up at locations that aren't even multiples >> of 4K. This can reduce performance. How much probably depends on the >> SSD. > > But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) A bug in the design of MBR. Which probably can be forgiven, considering when it was created and the other problems with it. :) gpart's alignment option can be used with MBR slices and bsdlabel partitions. ---902635197-698640261-1337697656=:51493-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 14:52:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 479051065688 for ; Tue, 22 May 2012 14:52:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 255598FC1F for ; Tue, 22 May 2012 14:52:25 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta09.emeryville.ca.mail.comcast.net with comcast id D1AB1j0031u4NiLA92rKoh; Tue, 22 May 2012 14:51:19 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta21.emeryville.ca.mail.comcast.net with comcast id D2rJ1j0044NgCEG8h2rJN1; Tue, 22 May 2012 14:51:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q4MEpG5B003421; Tue, 22 May 2012 08:51:16 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Jason Usher In-Reply-To: <1337635587.57757.YahooMailClassic@web122503.mail.ne1.yahoo.com> References: <1337635587.57757.YahooMailClassic@web122503.mail.ne1.yahoo.com> Content-Type: multipart/mixed; boundary="=-a0c6cJ9uCGd4jRa9ODOg" Date: Tue, 22 May 2012 08:51:16 -0600 Message-ID: <1337698276.1116.28.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:52:25 -0000 --=-a0c6cJ9uCGd4jRa9ODOg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, 2012-05-21 at 14:26 -0700, Jason Usher wrote: > > --- On Mon, 5/21/12, Garance A Drosehn wrote: > > > But have you tried it in this order ? > > > > HostKey /usr/local/etc/ssh/ssh_host_key > > HostKey > > /usr/local/etc/ssh/ssh_host_dsa_key > > HostKey > > /usr/local/etc/ssh/ssh_host_rsa_key > > HostKey > > /usr/local/etc/ssh/ssh_host_ecdsa_key > > > > Which is to say, have your sshd_config file list multiple > > hostkey's, and then restart sshd after making that change? > > I tried a similar change and it seemed to have some effect > > on what clients saw when connecting, but I can't tell if > > it has the effect that you want. > > > The order of HostKey directives in sshd_config does not change the actual order. In newer implementations, RSA is provided first, no matter how you configure the sshd_config. > > As I mentioned before, removing RSA completely is sort of a fix, but I can't do that because some people might actually be explicitly using RSA, and they would all break. > > Anyone ? After poking through the sshd code a bit, it looks to me like this is working as designed and it's the clients that are broken. For host key algorithm, and other things where both the server and the client side have a list of possibilities and have to agree on a match from those lists, the client side is completely in control of precedence, by design. The server has a list of things it can support, A,B,C,D. The client sends a list of things it desires, in order of preference, D,A,C. The server chooses a match as follows: for each client list item for each server list item if current-client-item matches current-server-item return current-client-item as the match end if end for end for In your case it appears that the client sends "rsa,dsa" as the host key algorithm list. The server has "dsa,rsa,maybe,other,stuff" and since rsa is the client's first choice and exists in the server list, it gets used. Then the client rejects the rsa key because it was really only ever going to be happy with a dsa key. IMO, this is a client-side bug; if it's only going to accept dsa (because that's the only thing in the known_hosts file) then it should only ask for that. So I think you have two choices... 1) Only offer a dsa key. It appears the right way to do this would be to have just one HostKey statement in the sshd config file that names your dsa key file. The presence of at least one HostKey statement will prevent the code from adding the default keyfile names internally, so you should end up with only a dsa key being offered. 2) Try the attached patch to violate the design and force the server's configuration order to override the precedence implied by the client's request list. Put HostKey statements the sshd_config file in the order you want enforced. I don't think #2 is a good option, but I know how it is in a production world... sometimes you've got to do things that you know are bad to keep the show running. Hopefully when you do such things it's just to buy some time to deploy a better fix (but it doesn't always work out that way; I still maintain horrible "temporary" hacks like this from years and years ago). Maybe option 1 would work okay for you in light of this info: When I look in the openssh source from freebsd 6.4, it appears that while an rsa hostkey was supported, it would not be added to the server config by default; it would only be used if you specifically configured it with a HostKey statement in sshd_config. So maybe you can safely assume that nobody was ever connecting to your freebsd 6.x machines using an rsa hostkey. Now for The Big Caveat: All of the above is based on code inspection. I haven't tested anything, including the attached patch. -- Ian --=-a0c6cJ9uCGd4jRa9ODOg Content-Description: Content-Disposition: inline; filename="revkeys.diff" Content-Type: text/x-patch; name="revkeys.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: crypto/openssh/kex.c =================================================================== --- crypto/openssh/kex.c (revision 235554) +++ crypto/openssh/kex.c (working copy) @@ -371,7 +371,7 @@ static void choose_hostkeyalg(Kex *k, char *client, char *server) { - char *hostkeyalg = match_list(client, server, NULL); + char *hostkeyalg = match_list(server, client, NULL); if (hostkeyalg == NULL) fatal("no hostkey alg"); k->hostkey_type = key_type_from_name(hostkeyalg); --=-a0c6cJ9uCGd4jRa9ODOg-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 17:15:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3F341065670 for ; Tue, 22 May 2012 17:15:26 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 19E0C8FC16 for ; Tue, 22 May 2012 17:15:25 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4MHFI7O061186; Tue, 22 May 2012 19:15:18 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4MHFIqi061183; Tue, 22 May 2012 19:15:18 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 22 May 2012 19:15:17 +0200 (CEST) From: User Wojtek To: Warren Block In-Reply-To: Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 22 May 2012 19:15:18 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Matthias Apitz , rozhuk.im@gmail.com Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 17:15:26 -0000 >> What is wrong with this procedure? > > The filesystem partitions end up at locations that aren't even multiples of > 4K. This can reduce performance. How much probably depends on the SSD. well in my case it is a multiply of any number you like [root@wojtek ~]# bsdlabel ada0 # /dev/ada0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 117231408 0 4.2BSD 0 0 0 c: 117231408 0 unused 0 0 # "raw" part, don't edit From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 16:59:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D0D91065673 for ; Tue, 22 May 2012 16:59:22 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm10-vm2.bullet.mail.ne1.yahoo.com (nm10-vm2.bullet.mail.ne1.yahoo.com [98.138.90.158]) by mx1.freebsd.org (Postfix) with SMTP id 328338FC19 for ; Tue, 22 May 2012 16:59:22 +0000 (UTC) Received: from [98.138.90.49] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 22 May 2012 16:59:16 -0000 Received: from [98.138.89.175] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 22 May 2012 16:59:16 -0000 Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 22 May 2012 16:59:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 419649.48871.bm@omp1031.mail.ne1.yahoo.com Received: (qmail 96649 invoked by uid 60001); 22 May 2012 16:59:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337705956; bh=WhoIfq6EaG4rLcNzaRdE58Bpq27wnbhxWI5707TSvuw=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qxPkxrPBfr3cYWl6kzi8Rh8EUerGesuytw5/ttLUHrVspjQNSe0OLOm8EhLbOSnfyKEKN0K3N3trjQX/6K7VNBZwfEMOibHO/XR/VDFi21jzwrz0kiOYwEe3T5UrOxnAlrhHIM4BVI0TCEcVk31fz2+wq7oB2TvwWmr6Y5pMPtw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=R8eFO2vRg1Dzvxt9JeZdfPaewJd8EQtEsIpUQ+hpBll+eMBK8KaBVMLlBIFlP0IgPS56/yfj3NMlVz8qM8nvcBKJIBT2eBXVK4OsL6blNHmFWSm26HCdBtzzfwXFZa+ykVT8i7bLAkpM+WKvxfHiHaPbTANKbUOTXpDtj+6nN5Q=; X-YMail-OSG: ARmQtKAVM1mPeun2JwKGEfRQOQlekj9LZjgwfeQFFZ37qqO bDisuok_q8INRCV1wABf4sAD98YX1yct9ovAU5U3gYeWWDRtVfLzicwWgrVw 5Y6DBPR34iIe.2Xnrj4tea6UPwYRe6USr8Vd0_zQZEf5eNOYxkPwYOvvbxvp rbPP66L9xGi02KTCFyv3UiWOA3wZqOxhzoklPVsLyle7Kj1HR2vH0YGI97Uv ki45cfg8IBQVdLnrK7r.85i6dXBtvQnQJzmOHDktqURdO83leuTxNXMrGtoN pBb6YTpHpvL8EhrTRos4v.3AO0M_hqObQfh7c_RRCPF86WL9GNZUq4xca32D Fj5iav4ZsePMlKQ9slJLXdSIuVHBC03j.eiFQjklCyWBy6wa4g.AyXSkE9Pm BVQ-- Received: from [173.164.238.34] by web122505.mail.ne1.yahoo.com via HTTP; Tue, 22 May 2012 09:59:16 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337705956.52238.YahooMailClassic@web122505.mail.ne1.yahoo.com> Date: Tue, 22 May 2012 09:59:16 -0700 (PDT) From: Jason Usher To: Ian Lepore MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 22 May 2012 18:00:22 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 16:59:22 -0000 Hi Ian,=0A=0AThank you very much for taking a look at this, and for underst= anding what I'm talking about here.=0A=0AComments inline, below...=0A=0A=0A= --- On Tue, 5/22/12, Ian Lepore wrote:=0A= =0A> >=A0 =0A> > >=A0 =A0 But have you tried it in this order=0A> ?=0A> > >= =0A> > >=A0 =A0 HostKey=0A> /usr/local/etc/ssh/ssh_host_key=0A> > >=A0 =A0= HostKey=0A> > > /usr/local/etc/ssh/ssh_host_dsa_key=0A> > >=A0 =A0 HostKey= =0A> > > /usr/local/etc/ssh/ssh_host_rsa_key=0A> > >=A0 =A0 HostKey=0A> > >= /usr/local/etc/ssh/ssh_host_ecdsa_key=0A> > > =0A> > > Which is to say, ha= ve your sshd_config file list=0A> multiple=0A> > > hostkey's, and then rest= art sshd after making that=0A> change?=0A> > > I tried a similar change and= it seemed to have=0A> some effect=0A> > > on what clients saw when connect= ing, but I can't=0A> tell if=0A> > > it has the effect that you want.=0A> >= =0A> > =0A> > The order of HostKey directives in sshd_config does not=0A> = change the actual order.=A0 In newer implementations, RSA=0A> is provided f= irst, no matter how you configure the=0A> sshd_config.=0A> > =0A> > As I me= ntioned before, removing RSA completely is sort=0A> of a fix, but I can't d= o that because some people might=0A> actually be explicitly using RSA, and = they would all break.=0A> > =0A> > Anyone ?=0A> =0A> After poking through t= he sshd code a bit, it looks to me=0A> like this is=0A> working as designed= and it's the clients that are=0A> broken.=A0 For host key=0A> algorithm, a= nd other things where both the server and the=0A> client side=0A> have a li= st of possibilities and have to agree on a match=0A> from those=0A> lists, = the client side is completely in control of=0A> precedence, by=0A> design.= =0A=0A=0AOK.=A0 That's bad news, as I have no influence on the clients at a= ll.=0A=0A=0A=0A> In your case it appears that the client sends "rsa,dsa" as= =0A> the host key=0A> algorithm list.=A0 The server has=0A> "dsa,rsa,maybe,= other,stuff" and since=0A> rsa is the client's first choice and exists in t= he server=0A> list, it gets=0A> used.=A0 Then the client rejects the rsa ke= y because it=0A> was really only=0A> ever going to be happy with a dsa key.= =A0 IMO, this is a=0A> client-side bug;=0A> if it's only going to accept ds= a (because that's the only=0A> thing in the=0A> known_hosts file) then it s= hould only ask for that.=0A=0A=0AExactly.=A0 It would be nice if the client= at least tried the other algorithm to see if that does indeed match up wit= h the public key it is sitting on ... breaking automation out in the field = is really problematic.=0A=0A=0A=0A>=A0 1) Only offer a dsa key.=A0 It appea= rs the right way to=0A> do this would be=0A> to have just one HostKey state= ment in the sshd config file=0A> that names=0A> your dsa key file.=A0 The p= resence of at least one=0A> HostKey statement will=0A> prevent the code fro= m adding the default keyfile names=0A> internally, so=0A> you should end up= with only a dsa key being offered.=0A=0A=0AOk, I did this - I explicitly d= efined a HostKey in sshd_config that happens to be my DSA key:=0A=0A#HostKe= y for protocol version 1=0A#HostKey /etc/ssh/ssh_host_key=0A#HostKeys for p= rotocol version 2=0AHostKey /etc/ssh/ssh_host_dsa_key=0A=0A(note the last l= ine is uncommented)=0A=0Aand sshd does indeed just present the DSA key (to = clients that were previously negotiating the RSA key, after the upgrade).= =0A=0ASo this is great... I was originally wary of forcing DSA only like th= is, since there might be clients out in the world that had somehow negotiat= ed an RSA key, but based on your further comments, it sounds like that is n= ot the case.=0A=0ASo if everyone has DSA keys (we'll find out ...) then we = are all set.=0A=0AThank you very much for examining this issue - I hope the= archives of this conversation will help others in the future. From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 19:12:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76028106564A for ; Tue, 22 May 2012 19:12:16 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE6A8FC08 for ; Tue, 22 May 2012 19:12:16 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta12.emeryville.ca.mail.comcast.net with comcast id D1GB1j00D1eYJf8AC7CAc0; Tue, 22 May 2012 19:12:10 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta19.emeryville.ca.mail.comcast.net with comcast id D7C91j00c4NgCEG017CAnV; Tue, 22 May 2012 19:12:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q4MJC79W003592; Tue, 22 May 2012 13:12:07 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Jason Usher In-Reply-To: <1337705956.52238.YahooMailClassic@web122505.mail.ne1.yahoo.com> References: <1337705956.52238.YahooMailClassic@web122505.mail.ne1.yahoo.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 May 2012 13:12:07 -0600 Message-ID: <1337713927.1116.40.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 19:12:16 -0000 On Tue, 2012-05-22 at 09:59 -0700, Jason Usher wrote: > Hi Ian, > > Thank you very much for taking a look at this, and for understanding what I'm talking about here. > > Comments inline, below... > > > --- On Tue, 5/22/12, Ian Lepore wrote: > > > > > > > > But have you tried it in this order > > ? > > > > > > > > HostKey > > /usr/local/etc/ssh/ssh_host_key > > > > HostKey > > > > /usr/local/etc/ssh/ssh_host_dsa_key > > > > HostKey > > > > /usr/local/etc/ssh/ssh_host_rsa_key > > > > HostKey > > > > /usr/local/etc/ssh/ssh_host_ecdsa_key > > > > > > > > Which is to say, have your sshd_config file list > > multiple > > > > hostkey's, and then restart sshd after making that > > change? > > > > I tried a similar change and it seemed to have > > some effect > > > > on what clients saw when connecting, but I can't > > tell if > > > > it has the effect that you want. > > > > > > > > > The order of HostKey directives in sshd_config does not > > change the actual order. In newer implementations, RSA > > is provided first, no matter how you configure the > > sshd_config. > > > > > > As I mentioned before, removing RSA completely is sort > > of a fix, but I can't do that because some people might > > actually be explicitly using RSA, and they would all break. > > > > > > Anyone ? > > > > After poking through the sshd code a bit, it looks to me > > like this is > > working as designed and it's the clients that are > > broken. For host key > > algorithm, and other things where both the server and the > > client side > > have a list of possibilities and have to agree on a match > > from those > > lists, the client side is completely in control of > > precedence, by > > design. > > > OK. That's bad news, as I have no influence on the clients at all. > > > > > In your case it appears that the client sends "rsa,dsa" as > > the host key > > algorithm list. The server has > > "dsa,rsa,maybe,other,stuff" and since > > rsa is the client's first choice and exists in the server > > list, it gets > > used. Then the client rejects the rsa key because it > > was really only > > ever going to be happy with a dsa key. IMO, this is a > > client-side bug; > > if it's only going to accept dsa (because that's the only > > thing in the > > known_hosts file) then it should only ask for that. > > > Exactly. It would be nice if the client at least tried the other algorithm to see if that does indeed match up with the public key it is sitting on ... breaking automation out in the field is really problematic. > > > > > 1) Only offer a dsa key. It appears the right way to > > do this would be > > to have just one HostKey statement in the sshd config file > > that names > > your dsa key file. The presence of at least one > > HostKey statement will > > prevent the code from adding the default keyfile names > > internally, so > > you should end up with only a dsa key being offered. > > > Ok, I did this - I explicitly defined a HostKey in sshd_config that happens to be my DSA key: > > #HostKey for protocol version 1 > #HostKey /etc/ssh/ssh_host_key > #HostKeys for protocol version 2 > HostKey /etc/ssh/ssh_host_dsa_key > > (note the last line is uncommented) > > and sshd does indeed just present the DSA key (to clients that were previously negotiating the RSA key, after the upgrade). > > So this is great... I was originally wary of forcing DSA only like this, since there might be clients out in the world that had somehow negotiated an RSA key, but based on your further comments, it sounds like that is not the case. > > So if everyone has DSA keys (we'll find out ...) then we are all set. > > Thank you very much for examining this issue - I hope the archives of this conversation will help others in the future. Seeing your example config with the commented-out HostKey lines made me realize that you probably want to have two HostKey lines, one for the protocol v1 key and another for the dsa key for v2. The 6.x server added the v1 key and the v2 dsa key by default, so you could have existing clients relying on a v1 key. Since you now have a HostKey statement the new server code won't add the v1 key by default so you'd need to be explicit about it. Based on examining the code, I think this will be safe because the keys have different type-names ("rsa1" vs "rsa") so a client wanting to use a protocol v2 rsa key won't accidentally match the protcol v1 rsa key named in the config file (and it will still match the dsa key). -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 21:14:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31C281065670 for ; Tue, 22 May 2012 21:14:39 +0000 (UTC) (envelope-from alex323@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B43528FC08 for ; Tue, 22 May 2012 21:14:38 +0000 (UTC) Received: by obcni5 with SMTP id ni5so13686362obc.13 for ; Tue, 22 May 2012 14:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iSVzgY25qubakaAi9WLV8fha+hXIvctBzJwLkRH8rio=; b=aud/Y8Wur6+Umr+5FTOTP4fNcLvSE4i//uE5d2FG2a/v7vSKWuCoTJHvmCFLn8WLIS QCmUDJ78rI815GkEK28VKrXNtao9cKqAPZ/dx4nH5eij58RkTeGekJh6TGe6etiolRFH 5r9cREENCHrXz/FHQZQueK46E1i12AtFENa1DaB3oYwafwYYlV0oY8Pv6mnBMWCvuYDd UI9mmWge6GZKZFUdYxVvhA98oobijmple02zw8x30zuRmdzdfVVBSARBom7/c/DkGZzC myh3Y6L5U8ROFwnAgkuzLm+KjGA7r12TG3xrGuVGqcfPzoFpIGIJQeuXwfzZGlX23+Na 2C3g== MIME-Version: 1.0 Received: by 10.60.22.201 with SMTP id g9mr2418401oef.8.1337721278073; Tue, 22 May 2012 14:14:38 -0700 (PDT) Received: by 10.182.49.201 with HTTP; Tue, 22 May 2012 14:14:37 -0700 (PDT) Date: Tue, 22 May 2012 17:14:37 -0400 Message-ID: From: Alex To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=e89a8fb1ed4a968b5104c0a68118 X-Mailman-Approved-At: Tue, 22 May 2012 21:31:53 +0000 Subject: Page fault when using IPsec with AESNI enabled on 9.0-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 21:14:39 -0000 --e89a8fb1ed4a968b5104c0a68118 Content-Type: text/plain; charset=ISO-8859-1 Hi there. I am running FreeBSD 9.0-RELEASE-p1 #18 r235095 amd64 and am experiencing a reproducible page fault when using IPsec with "device aesni" enabled. Strongswan successfully negotiates the SAs and uses aes256 for ESP, however once a packet is sent, the page fault occurs. This does not happen when aesni is disabled. I have a core dump, the text of which is attached to this email. Should I file a PR for this? Thanks. -- Alex --e89a8fb1ed4a968b5104c0a68118 Content-Type: application/octet-stream; name="core.txt.0" Content-Disposition: attachment; filename="core.txt.0" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h2jgch1l0 cG9zZWlkb24gZHVtcGVkIGNvcmUgLSBzZWUgL2FyY2hpdmUvY3Jhc2gvdm1jb3JlLjAKClR1ZSBN YXkgMjIgMTY6MjU6NTcgRURUIDIwMTIKCkZyZWVCU0QgcG9zZWlkb24gOS4wLVJFTEVBU0UtcDEg RnJlZUJTRCA5LjAtUkVMRUFTRS1wMSAjMTggcjIzNTA5NTogVHVlIE1heSAyMiAxNjowMTo0MyBF RFQgMjAxMiAgICAgYWxleEBwb3NlaWRvbjovdXNyL29iai91c3Ivc3JjL3N5cy9QT1NFSURPTiAg YW1kNjQKCnBhbmljOiAKCkdOVSBnZGIgNi4xLjEgW0ZyZWVCU0RdCkNvcHlyaWdodCAyMDA0IEZy ZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgpHREIgaXMgZnJlZSBzb2Z0d2FyZSwgY292ZXJl ZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGFuZCB5b3UgYXJlCndlbGNvbWUg dG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRlciBjZXJ0YWlu IGNvbmRpdGlvbnMuClR5cGUgInNob3cgY29weWluZyIgdG8gc2VlIHRoZSBjb25kaXRpb25zLgpU aGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdhcnJhbnR5IGZvciBHREIuICBUeXBlICJzaG93IHdhcnJh bnR5IiBmb3IgZGV0YWlscy4KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMgImFtZDY0LW1hcmNl bC1mcmVlYnNkIi4uLgoKVW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBtZXNzYWdlIGJ1ZmZl cjoKCgpGYXRhbCB0cmFwIDEyOiBwYWdlIGZhdWx0IHdoaWxlIGluIGtlcm5lbCBtb2RlCmNwdWlk ID0gMjsgYXBpYyBpZCA9IDAyCmZhdWx0IHZpcnR1YWwgYWRkcmVzcwk9IDB4MjgKZmF1bHQgY29k ZQkJPSBzdXBlcnZpc29yIHJlYWQgZGF0YSwgcGFnZSBub3QgcHJlc2VudAppbnN0cnVjdGlvbiBw b2ludGVyCT0gMHgyMDoweGZmZmZmZmZmODA4OTdkNDcKc3RhY2sgcG9pbnRlcgkgICAgICAgID0g MHgyODoweGZmZmZmZjgwMDAyYmJiMzAKZnJhbWUgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZm ZmZmZjgwMDAyYmJiOTAKY29kZSBzZWdtZW50CQk9IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0 eXBlIDB4MWIKCQkJPSBEUEwgMCwgcHJlcyAxLCBsb25nIDEsIGRlZjMyIDAsIGdyYW4gMQpwcm9j ZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0IGVuYWJsZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVu dCBwcm9jZXNzCQk9IDMgKGNyeXB0byByZXR1cm5zKQpEdW1waW5nIDI2MSBvdXQgb2YgOTkwIE1C Oi4uNyUuLjEzJS4uMjUlLi4zMSUuLjQzJS4uNTYlLi42MiUuLjc0JS4uODYlLi45MiUKClJlYWRp bmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC96ZnMua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJv bSAvYm9vdC9rZXJuZWwvemZzLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9s cyBmb3IgL2Jvb3Qva2VybmVsL3pmcy5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJu ZWwvb3BlbnNvbGFyaXMua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvb3Bl bnNvbGFyaXMua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9v dC9rZXJuZWwvb3BlbnNvbGFyaXMua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3QvbW9kdWxl cy9udmlkaWEua28uLi5kb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3QvbW9kdWxlcy9udmlk aWEua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3QvbW9kdWxlcy92Ym94ZHJ2LmtvLi4uZG9u ZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L21vZHVsZXMvdmJveGRydi5rbwpSZWFkaW5nIHN5 bWJvbHMgZnJvbSAvdXNyL2xvY2FsL21vZHVsZXMvZnVzZS5rby4uLmRvbmUuCkxvYWRlZCBzeW1i b2xzIGZvciAvdXNyL2xvY2FsL21vZHVsZXMvZnVzZS5rbwojMCAgZG9hZHVtcCAodGV4dGR1bXA9 MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjI1NQoyNTUJCWR1bXB0aWQg PSBjdXJ0aHJlYWQtPnRkX3RpZDsKKGtnZGIpICMwICBkb2FkdW1wICh0ZXh0ZHVtcD0wKSBhdCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6MjU1CiMxICAweGZmZmZmZmZmODAzM2U2 ODEgaW4gZGJfZHVtcCAoZHVtbXk9LTIxMzg0NzMxNDUsIGR1bW15Mj0wLCBkdW1teTM9LTEsIAog ICAgZHVtbXk0PTB4ZmZmZmZmODAwMDJiYjY4MCAiIikgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9j b21tYW5kLmM6NTM3CiMyICAweGZmZmZmZmZmODAzM2U0NDkgaW4gZGJfY29tbWFuZCAobGFzdF9j bWRwPTB4ZmZmZmZmZmY4MGQ5Y2FhMCwgCiAgICBjbWRfdGFibGU9MHgwLCBkb3BhZ2VyPTEpIGF0 IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjQ0OAojMyAgMHhmZmZmZmZmZjgwMzNlNWM0 IGluIGRiX2NvbW1hbmRfbG9vcCAoKQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5k LmM6NTAxCiM0ICAweGZmZmZmZmZmODAzNDE0NDAgaW4gZGJfdHJhcCAodHlwZT0xMiwgY29kZT0w KQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9tYWluLmM6MjI5CiM1ICAweGZmZmZmZmZmODA2 MzAyMDQgaW4ga2RiX3RyYXAgKHR5cGU9MTIsIGNvZGU9MCwgdGY9MHhmZmZmZmY4MDAwMmJiYTgw KQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9rZGIuYzo2MjAKIzYgIDB4ZmZmZmZmZmY4 MDlhZjY4NyBpbiB0cmFwX2ZhdGFsIChmcmFtZT0weGZmZmZmZjgwMDAyYmJhODAsIGV2YT00MCkK ICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6ODE0CiM3ICAweGZmZmZmZmZm ODA5YWVlZWMgaW4gdHJhcF9wZmF1bHQgKGZyYW1lPTB4ZmZmZmZmODAwMDJiYmE4MCwgdXNlcm1v ZGU9MCkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6Njg4CiM4ICAweGZm ZmZmZmZmODA5YWU5ZTQgaW4gdHJhcCAoZnJhbWU9MHhmZmZmZmY4MDAwMmJiYTgwKQogICAgYXQg L3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo0NzQKIzkgIDB4ZmZmZmZmZmY4MDk5Mzc0 ZiBpbiBjYWxsdHJhcCAoKQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlv bi5TOjIyOAojMTAgMHhmZmZmZmZmZjgwODk3ZDQ3IGluIGVzcF9vdXRwdXRfY2IgKGNycD0weGZm ZmZmZTAwMjdhYTUwYjApCiAgICBhdCAvdXNyL3NyYy9zeXMvbmV0aXBzZWMveGZvcm1fZXNwLmM6 OTY4CiMxMSAweGZmZmZmZmZmODA4YWYyMTQgaW4gY3J5cHRvX3JldF9wcm9jICgpCiAgICBhdCAv dXNyL3NyYy9zeXMvb3BlbmNyeXB0by9jcnlwdG8uYzoxNDI4CiMxMiAweGZmZmZmZmZmODA1YjUz YzcgaW4gZm9ya19leGl0ICgKICAgIGNhbGxvdXQ9MHhmZmZmZmZmZjgwOGFmMDcwIDxjcnlwdG9f cmV0X3Byb2M+LCBhcmc9MHgwLCAKICAgIGZyYW1lPTB4ZmZmZmZmODAwMDJiYmM1MCkgYXQgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmM6OTk1CiMxMyAweGZmZmZmZmZmODA5OTNjN2UgaW4g Zm9ya190cmFtcG9saW5lICgpCiAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvZXhjZXB0 aW9uLlM6NjAyCiMxNCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzE1IDB4MDAwMDAwMDAw MDAwMDAwMCBpbiA/PyAoKQojMTYgMHgwMDAwMDAwMDAwMDAwMDAxIGluID8/ICgpCiMxNyAweDAw MDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzE4IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQoj MTkgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMyMCAweDAwMDAwMDAwMDAwMDAwMDAgaW4g Pz8gKCkKIzIxIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMjIgMHgwMDAwMDAwMDAwMDAw MDAwIGluID8/ICgpCiMyMyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzI0IDB4MDAwMDAw MDAwMDAwMDAwMCBpbiA/PyAoKQojMjUgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMyNiAw eDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzI3IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAo KQojMjggMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMyOSAweDAwMDAwMDAwMDAwMDAwMDAg aW4gPz8gKCkKIzMwIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzEgMHgwMDAwMDAwMDAw MDAwMDAwIGluID8/ICgpCiMzMiAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzMzIDB4MDAw MDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMz NSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzM2IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/ PyAoKQojMzcgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMzOCAweDAwMDAwMDAwMDAwMDAw MDAgaW4gPz8gKCkKIzM5IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojNDAgMHgwMDAwMDAw MDAwMDAwMDAwIGluID8/ICgpCiM0MSAweGZmZmZmZmZmODA4YWYwNzAgaW4gY3J5cHRvX3Byb2Mg KCkKICAgIGF0IC91c3Ivc3JjL3N5cy9vcGVuY3J5cHRvL2NyeXB0by5jOjEzODUKKGtnZGIpIAoK LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCnBzIC1heGwKCiAgVUlEICAgUElEICBQUElEIENQVSBQUkkgTkkgICAg VlNaICAgIFJTUyBNV0NIQU4gU1RBVCAgVFQgICAgIFRJTUUgQ09NTUFORAogICAgMCAgICAgMCAg ICAgMCAgIDAgIC04ICAwICAgICAgMCAgICAgIDAgLSAgICAgIERMcyAgID8/ICAwOjAwLjE0IFtr ZXJuZWxdCiAgICAwICAgICAxICAgICAwICAgMCAgMjAgIDAgICA2MjgwICAgICAgMCB3YWl0ICAg RExzICAgPz8gIDA6MDAuMDQgW2luaXRdCiAgICAwICAgICAyICAgICAwICAgMCAtMTYgIDAgICAg ICAwICAgICAgMCBjcnlwdG8gREwgICAgPz8gIDA6MDAuMDAgW2NyeXB0b10KICAgIDAgICAgIDMg ICAgIDAgICAwIC0xNiAgMCAgICAgIDAgICAgICAwIC0gICAgICBSTCAgICA/PyAgMDowMC4wMCBb Y3J5cHRvIHJldAogICAgMCAgICAgNCAgICAgMCAgIDAgIC04ICAwICAgICAgMCAgICAgIDAgdHgt PnR4IERMICAgID8/ICAwOjAwLjAwIFt6ZnNrZXJuXQogICAgMCAgICAgNSAgICAgMCAgIDAgLTE2 ICAwICAgICAgMCAgICAgIDAgcGZ0bSAgIERMICAgID8/ICAwOjAwLjAwIFtwZnB1cmdlXQogICAg MCAgICAgNiAgICAgMCAgIDAgLTE2ICAwICAgICAgMCAgICAgIDAgd2FpdGluIERMICAgID8/ICAw OjAwLjAwIFtzY3RwX2l0ZXJhCiAgICAwICAgICA3ICAgICAwICAgMCAtMTYgIDAgICAgICAwICAg ICAgMCBjY2Jfc2MgREwgICAgPz8gIDA6MDAuMDAgW3hwdF90aHJkXQogICAgMCAgICAgOCAgICAg MCAgIDAgLTE2ICAwICAgICAgMCAgICAgIDAgciAgICAgIERMICAgID8/ICAwOjAwLjAwIFtnX2pv dXJuYWwgCiAgICAwICAgICA5ICAgICAwICAgMCAtMTYgIDAgICAgICAwICAgICAgMCBwc2xlZXAg REwgICAgPz8gIDA6MDAuMDAgW3BhZ2VkYWVtb24KICAgIDAgICAgMTAgICAgIDAgICAwIC0xNiAg MCAgICAgIDAgICAgICAwIGF1ZGl0XyBETCAgICA/PyAgMDowMC4wMCBbYXVkaXRdCiAgICAwICAg IDExICAgICAwICAgMCAxNTUgIDAgICAgICAwICAgICAgMCAtICAgICAgUkwgICAgPz8gIDI6MTku OTEgW2lkbGVdCiAgICAwICAgIDEyICAgICAwICAgMCAtNzIgIDAgICAgICAwICAgICAgMCAtICAg ICAgV0wgICAgPz8gIDA6MDEuMjAgW2ludHJdCiAgICAwICAgIDEzICAgICAwICAgMCAgLTggIDAg ICAgICAwICAgICAgMCAtICAgICAgREwgICAgPz8gIDA6MDAuMDMgW2dlb21dCiAgICAwICAgIDE0 ICAgICAwICAgMCAtMTYgIDAgICAgICAwICAgICAgMCAtICAgICAgREwgICAgPz8gIDA6MDAuMDAg W3lhcnJvd10KICAgIDAgICAgMTUgICAgIDAgICAwIC02OCAgMCAgICAgIDAgICAgICAwIC0gICAg ICBETCAgICA/PyAgMDowMC40MiBbdXNiXQogICAgMCAgICAxNiAgICAgMCAgIDAgLTIwICAwICAg ICAgMCAgICAgIDAgSVBSVCBTIERMICAgID8/ICAwOjAwLjAwIFtUSU1FUl0KICAgIDAgICAgMTcg ICAgIDAgICAwIC0xNiAgMCAgICAgIDAgICAgICAwIHBzbGVlcCBETCAgICA/PyAgMDowMC4wMCBb dm1kYWVtb25dCiAgICAwICAgIDE4ICAgICAwICAgMCAxNTUgIDAgICAgICAwICAgICAgMCBwZ3pl cm8gREwgICAgPz8gIDA6MDAuMDAgW3BhZ2V6ZXJvXQogICAgMCAgICAxOSAgICAgMCAgIDAgLTE2 ICAwICAgICAgMCAgICAgIDAgcHNsZWVwIERMICAgID8/ICAwOjAwLjAwIFtidWZkYWVtb25dCiAg ICAwICAgIDIwICAgICAwICAgMCAtMTYgIDAgICAgICAwICAgICAgMCB2bHJ1d3QgREwgICAgPz8g IDA6MDAuMDAgW3ZubHJ1XQogICAgMCAgICAyMSAgICAgMCAgIDAgIDE2ICAwICAgICAgMCAgICAg IDAgc3luY2VyIERMICAgID8/ICAwOjAwLjAwIFtzeW5jZXJdCiAgICAwICAgIDIyICAgICAwICAg MCAtMTYgIDAgICAgICAwICAgICAgMCBzZGZsdXMgREwgICAgPz8gIDA6MDAuMDAgW3NvZnRkZXBm bHUKICAgIDAgICAxMzMgICAgIDEgICAwICA1MiAgMCAgMTAwNjAgICAgICAwIHBhdXNlICBEcyAg ICA/PyAgMDowMC4wMCBbYWRqa2VybnR6XQogICAgMCAgMTIxMyAgICAgMSAgIDAgIDUyICAwICAx NDM2NCAgICAgIDAgc2VsZWN0IERzICAgID8/ICAwOjAwLjAwIFttb3VzZWRdCiAgICAwICAxMjM2 ICAgICAxICAgMCAgMjAgIDAgIDE0MzY0ICAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDA6MDAuMDAg W21vdXNlZF0KICAgIDAgIDEyNTQgICAgIDEgICAwICAzNCAgMCAgMTAzNzIgICAgICAwIHNlbGVj dCBEcyAgICA/PyAgMDowMC4wMCBbZGV2ZF0KICAgIDAgIDE0MTQgICAgIDEgICAwICA1MiAgMCAg MTAwNTIgICAgICAwIHNlbGVjdCBEcyAgICA/PyAgMDowMC4wMCBbZGhjbGllbnRdCiAgIDY1ICAx NDUyICAgICAxICAgMCAgMjAgIDAgIDEwMDUyICAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDA6MDAu MDAgW2RoY2xpZW50XQogICAgMCAgMTU3MyAgICAgMSAgIDAgIDIwICAwICAxMjE4OCAgICAgIDAg c2VsZWN0IERzICAgID8/ICAwOjAwLjAxIFtzeXNsb2dkXQogICAgMCAgMTc0OCAgICAgMSAgIDAg IDIwICAwICAyMjMzNiAgICAgIDAgc2VsZWN0IERzICAgID8/ICAwOjAwLjAxIFtudHBkXQogIDEz NiAgMTgwNSAgICAgMSAgIDAgIDUyICAwICA0MDg0OCAgICAgIDAgc2VsZWN0IERzICAgID8/ICAw OjAwLjAwIFtkaGNwZF0KICAgIDAgIDE4MzYgICAgIDEgICAwICAyMCAgMCAgOTI5MjAgICAgICAw IHNlbGVjdCBEcyAgICA/PyAgMDowMC4zOSBbc2xpbV0KICAgIDAgIDE4MzkgIDE4MzYgICAwICA1 MiAgMCAzMzAwMzAwICAgICAgMCBzZWxlY3QgRCAgICAgPz8gIDA6MDEuNjEgW1hvcmddCiAgNTU2 ICAxODUzICAgICAxICAgMCAgMzAgIDAgIDE0NDQ4ICAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDA6 MDAuMDEgW2RidXMtZGFlbW8KICAgIDAgIDE4NzQgICAgIDEgICAwICA1MiAgMCAgMzQ5NDggICAg ICAwIGtxcmVhZCBEcyAgICA/PyAgMDowMC4wMSBbY3Vwc2RdCiAgICAwICAxODk5ICAgICAxICAg MCAgNTIgIDAgIDQ2ODgwICAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDA6MDAuMDAgW3NzaGRdCiAg ICAwICAxOTA4ICAgICAxICAgMCAgMjAgIDAgIDE0MjY0ICAgICAgMCBuYW5zbHAgRHMgICAgPz8g IDA6MDAuMDAgW2Nyb25dCiAgICAwICAxOTg3ICAgICAxICAgMCAgNTIgIDAgIDEyMTg4ICAgICAg MCB0dHlpbiAgRHMrICAgPz8gIDA6MDAuMDAgW2dldHR5XQogICAgMCAgMTk4OCAgICAgMSAgIDAg IDIwICAwICA0MTMwNCAgICAgIDAgd2FpdCAgIERzICAgID8/ICAwOjAwLjAwIFtsb2dpbl0KICAg IDAgIDE5ODkgICAgIDEgICAwICAyMCAgMCAgNDEzMDQgICAgICAwIHdhaXQgICBEcyAgICA/PyAg MDowMC4wMCBbbG9naW5dCiAgICAwICAxOTkwICAgICAxICAgMCAgNTIgIDAgIDEyMTg4ICAgICAg MCB0dHlpbiAgRHMrICAgPz8gIDA6MDAuMDAgW2dldHR5XQogICAgMCAgMTk5MSAgICAgMSAgIDAg IDUyICAwICAxMjE4OCAgICAgIDAgdHR5aW4gIERzKyAgID8/ICAwOjAwLjAwIFtnZXR0eV0KICAg IDAgIDE5OTIgICAgIDEgICAwICA1MiAgMCAgMTIxODggICAgICAwIHR0eWluICBEcysgICA/PyAg MDowMC4wMCBbZ2V0dHldCiAgICAwICAxOTkzICAgICAxICAgMCAgNTIgIDAgIDEyMTg4ICAgICAg MCB0dHlpbiAgRHMrICAgPz8gIDA6MDAuMDAgW2dldHR5XQogICAgMCAgMTk5NCAgICAgMSAgIDAg IDUyICAwICAxMjE4OCAgICAgIDAgdHR5aW4gIERzKyAgID8/ICAwOjAwLjAwIFtnZXR0eV0KICA1 NjAgIDE5OTkgICAgIDEgICAwICAzMyAgMCAgNTcwNDggICAgICAwIHBpcGVyZCBEcyAgICA/PyAg MDowMC4xMiBbaGFsZF0KICAgIDAgIDIwMDEgICAgIDEgICAwICAyMCAgMCAxMDYzMzYgICAgICAw IC0gICAgICBSICAgICA/PyAgMDowMC4wMiBbY29uc29sZS1raQogICAgMCAgMjAwMyAgICAgMSAg IDAgIDI2ICAwICA2NDYzNiAgICAgIDAgc2VsZWN0IEQgICAgID8/ICAwOjAwLjAyIFtwb2xraXRk XQogICAgMCAgMjAwNSAgICAgMSAgIDAgIDM4ICAwICAyMjc4OCAgICAgIDAgc2VsZWN0IEQgICAg ID8/ICAwOjAwLjAxIFtnYW1fc2VydmVyCiAgICAwICAyMDA2ICAxOTk5ICAgMCAgNTIgIDAgIDM5 MTU2ICAgICAgMCBzZWxlY3QgRCAgICAgPz8gIDA6MDAuMDIgW2hhbGQtcnVubmUKICAgIDAgIDIw MjggIDIwMDYgICAwICA1MiAgMCAgMjk0MDggICAgICAwIHMgICAgICBEICAgICA/PyAgMDowMC4w MCBbaGFsZC1hZGRvbgogICAgMCAgMjAzNCAgMjAwNiAgIDAgIDUyICAwICAyOTQwOCAgICAgIDAg cyAgICAgIEQgICAgID8/ICAwOjAwLjAwIFtoYWxkLWFkZG9uCiAxMDAxICAyMDYwICAxOTg4ICAg MCAgMjAgIDAgIDE3NTg0ICAgICAgMCB3YWl0ICAgRCAgICAgPz8gIDA6MDAuMDAgW2Jhc2hdCiAx MDAxICAyMDcwICAxOTg5ICAgMCAgMjAgIDAgIDE3NTg0ICAgICAgMCB0dHlpbiAgRCsgICAgPz8g IDA6MDAuMDAgW2Jhc2hdCiAgICAwICAyMDgwICAyMDYwICAgMCAgMjAgIDAgIDQxMzA0ICAgICAg MCB3YWl0ICAgRCAgICAgPz8gIDA6MDAuMDAgW3N1XQogICAgMCAgMjA4MSAgMjA4MCAgIDAgIDIw ICAwICAxNzY3MiAgICAgIDAgdHR5aW4gIEQrICAgID8/ICAwOjAwLjAwIFtjc2hdCiAgICAwICAy MTA0ICAgICAxICAgMCAgMjMgIDAgIDE4ODMyICAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDA6MDAu MDAgW3N0YXJ0ZXJdCiAgICAwICAyMTA1ICAyMTA0ICAgMCAgMjQgIDAgMTY4MjIwICAgICAgMCB1 d2FpdCAgRHMgICAgPz8gIDA6MDAuMDAgW2NoYXJvbl0KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQg LXMKCiAgIDEyODE2MiBjcHUgY29udGV4dCBzd2l0Y2hlcwogICAgIDc1ODcgZGV2aWNlIGludGVy cnVwdHMKICAgIDE1ODU0IHNvZnR3YXJlIGludGVycnVwdHMKICAgMjE0MDEzIHRyYXBzCiAgMTEz ODA0OSBzeXN0ZW0gY2FsbHMKICAgICAgIDIyIGtlcm5lbCB0aHJlYWRzIGNyZWF0ZWQKICAgICAy MDcyICBmb3JrKCkgY2FsbHMKICAgICAgIDExIHZmb3JrKCkgY2FsbHMKICAgICAgICAwIHJmb3Jr KCkgY2FsbHMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZWlucwogICAgICAgIDAgc3dhcCBwYWdl ciBwYWdlcyBwYWdlZCBpbgogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlb3V0cwogICAgICAgIDAg c3dhcCBwYWdlciBwYWdlcyBwYWdlZCBvdXQKICAgIDEyMDc2IHZub2RlIHBhZ2VyIHBhZ2VpbnMK ICAgIDEyMDc2IHZub2RlIHBhZ2VyIHBhZ2VzIHBhZ2VkIGluCiAgICAgICAgMCB2bm9kZSBwYWdl ciBwYWdlb3V0cwogICAgICAgIDAgdm5vZGUgcGFnZXIgcGFnZXMgcGFnZWQgb3V0CiAgICAgICAg MCBwYWdlIGRhZW1vbiB3YWtldXBzCiAgICAgICAgMCBwYWdlcyBleGFtaW5lZCBieSB0aGUgcGFn ZSBkYWVtb24KICAgICA1MzI5IHBhZ2VzIHJlYWN0aXZhdGVkCiAgICA3MDA1MSBjb3B5LW9uLXdy aXRlIGZhdWx0cwogICAgICA2NTQgY29weS1vbi13cml0ZSBvcHRpbWl6ZWQgZmF1bHRzCiAgICA3 NTQ3MiB6ZXJvIGZpbGwgcGFnZXMgemVyb2VkCiAgICAgICAgMCB6ZXJvIGZpbGwgcGFnZXMgcHJl emVyb2VkCiAgICAgICA0MiBpbnRyYW5zaXQgYmxvY2tpbmcgcGFnZSBmYXVsdHMKICAgMjIwMDU5 IHRvdGFsIFZNIGZhdWx0cyB0YWtlbgogICAgICAgIDAgcGFnZXMgYWZmZWN0ZWQgYnkga2VybmVs IHRocmVhZCBjcmVhdGlvbgogIDEwNTMzMTQgcGFnZXMgYWZmZWN0ZWQgYnkgIGZvcmsoKQogICAg IDUwNTMgcGFnZXMgYWZmZWN0ZWQgYnkgdmZvcmsoKQogICAgICAgIDAgcGFnZXMgYWZmZWN0ZWQg YnkgcmZvcmsoKQogICAgICAgIDAgcGFnZXMgY2FjaGVkCiAgIDE5MzYxMyBwYWdlcyBmcmVlZAog ICAgICAgIDAgcGFnZXMgZnJlZWQgYnkgZGFlbW9uCiAgICAgICAgMCBwYWdlcyBmcmVlZCBieSBl eGl0aW5nIHByb2Nlc3NlcwogICAgMjYzNTUgcGFnZXMgYWN0aXZlCiAgICAgNTUzOSBwYWdlcyBp bmFjdGl2ZQogICAgIDIzMTUgcGFnZXMgaW4gVk0gY2FjaGUKICAgIDUwNTU2IHBhZ2VzIHdpcmVk IGRvd24KICAgMTYwODM1IHBhZ2VzIGZyZWUKICAgICA0MDk2IGJ5dGVzIHBlciBwYWdlCiAgICA4 NTIyMyB0b3RhbCBuYW1lIGxvb2t1cHMKICAgICAgICAgIGNhY2hlIGhpdHMgKDg0JSBwb3MgKyA1 JSBuZWcpIHN5c3RlbSAwJSBwZXItZGlyZWN0b3J5CiAgICAgICAgICBkZWxldGlvbnMgMCUsIGZh bHNlaGl0cyAwJSwgdG9vbG9uZyAwJQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnZtc3RhdCAtbQoKICAgICAg ICAgVHlwZSBJblVzZSBNZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQogICAgICAgIHNp Z2lvICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAyICA2NAogICAgICAgICBrZW52ICAgMTE2 ICAgIDEzSyAgICAgICAtICAgICAgMTI5ICAxNiwzMiw2NCwxMjgKICAgICAgIGtxdWV1ZSAgICAx NiAgICAxNEsgICAgICAgLSAgICAgICAzNCAgMjU2LDUxMiwyMDQ4CiAgICBwcm9jLWFyZ3MgICAg MzcgICAgIDNLICAgICAgIC0gICAgICA3NzMgIDE2LDMyLDY0LDEyOCwyNTYKICAgICAgICBoaG9v ayAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4CiAgICAgIGl0aHJlYWQgICAxMTgg ICAgMTlLICAgICAgIC0gICAgICAxMTggIDMyLDEyOCwyNTYKICAgICAgIEtUUkFDRSAgIDEwMCAg ICAxM0sgICAgICAgLSAgICAgIDEwMCAgMTI4CiAgICAgYWNwaXRhc2sgICAgIDEgICAgIDJLICAg ICAgIC0gICAgICAgIDEgIDIwNDgKICAgICAgYWNwaXNlbSAgICAyMCAgICAgM0sgICAgICAgLSAg ICAgICAyMCAgMTI4CiAgICAgICBsaW5rZXIgICAxMzYgICAgNjFLICAgICAgIC0gICAgICAxNTUg IDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICAgIGhkYWMgICAgMjgg ICAgMzRLICAgICAgIC0gICAgICAgMzAgIDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAg ICAgICAgbG9ja2YgICAgMTcgICAgIDJLICAgICAgIC0gICAgICAgMzcgIDY0LDEyOAogICBsb2dp bmNsYXNzICAgICAyICAgICAxSyAgICAgICAtICAgICAgICA0ICA2NAogICAgICAgZGV2YnVmIDE5 Nzk3IDM4ODc4SyAgICAgICAtICAgIDE5OTk2ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIw NDgsNDA5NgogICAgICAgICB0ZW1wICAgIDc5ICAgIDE1SyAgICAgICAtICAgICA4Nzk3ICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgaXA2b3B0ICAgICAxICAgICAx SyAgICAgICAtICAgICAgICAzICAzMiwyNTYKICAgICAgIGlwNm5kcCAgICAxNCAgICAgMksgICAg ICAgLSAgICAgICAxNyAgNjQsMTI4CiAgICAgIENBTSBTSU0gICAgMTIgICAgIDNLICAgICAgIC0g ICAgICAgMTIgIDI1NgogICAgICAgbW9kdWxlICAgMjQzICAgIDMxSyAgICAgICAtICAgICAgMjQz ICAxMjgKICAgICBtdHhfcG9vbCAgICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgCiAgICAg IGFjcGlkZXYgICAgNDAgICAgIDNLICAgICAgIC0gICAgICAgNDAgIDY0CiAgICAgIENBTSBYUFQg ICAxMjMgICAxMTVLICAgICAgIC0gICAgICAyOTIgIDMyLDY0LDEyOCwxMDI0LDIwNDgKICAgICAg ICAgIG9zZCAgICAgNCAgICAgMUsgICAgICAgLSAgICAgICAxMCAgMTYsNjQsMTI4CiAgICAgICAg IHBncnAgICAgMzIgICAgIDRLICAgICAgIC0gICAgICAgNDMgIDEyOAogICAgICBzZXNzaW9uICAg IDI3ICAgICA0SyAgICAgICAtICAgICAgIDI4ICAxMjgKICAgICAgICAgcHJvYyAgICAgMiAgICAx NksgICAgICAgLSAgICAgICAgMiAgCiAgICAgIHN1YnByb2MgICAyNDEgICAzMjdLICAgICAgIC0g ICAgIDIyODggIDUxMiw0MDk2CiAgICAgICAgIGNyZWQgICAgODYgICAgMTRLICAgICAgIC0gICAg MTE3MDYgIDY0LDI1NgogICAgICAgcGxpbWl0ICAgIDE0ICAgICA0SyAgICAgICAtICAgICAgMTcy ICAyNTYKICAgICAgdWlkaW5mbyAgICAgNyAgICAgM0sgICAgICAgLSAgICAgICAgOSAgMTI4LDIw NDgKICAgICAgIERFVkZTMyAgIDE3NSAgICA0NEsgICAgICAgLSAgICAgIDE4NCAgMjU2CiAgICAg ICBERVZGUzEgICAxNTUgICAgNzhLICAgICAgIC0gICAgICAxNjAgIDUxMgogICAgICAgc3lzY3Rs ICAgICAwICAgICAwSyAgICAgICAtICAgICAxMzY5ICAxNiwzMiw2NAogICAgc3lzY3Rsb2lkICA2 MjEwICAgMzA4SyAgICAgICAtICAgICA2MzYzICAxNiwzMiw2NCwxMjgKICAgIHN5c2N0bHRtcCAg ICAgMCAgICAgMEsgICAgICAgLSAgICAgIDcxMSAgMTYsMzIsNjQsMTI4LDI1NiwyMDQ4CiAgICAg IHRpZGhhc2ggICAgIDEgICAgMTZLICAgICAgIC0gICAgICAgIDEgIAogICAgICBjYWxsb3V0ICAg ICA3ICAzNTg0SyAgICAgICAtICAgICAgICA3ICAKICAgICAgICAgdW10eCAgMTUzNiAgIDE5Mksg ICAgICAgLSAgICAgMTUzNiAgMTI4CiAgICAgcDEwMDMuMWIgICAgIDEgICAgIDFLICAgICAgIC0g ICAgICAgIDEgIDE2CiAgICAgICAgIFNXQVAgICAgIDIgIDEwOTdLICAgICAgIC0gICAgICAgIDIg IDY0CiAgICAgICAgICBidXMgICA5MDYgICAgODZLICAgICAgIC0gICAgIDQyNjggIDE2LDMyLDY0 LDEyOCwyNTYsMTAyNAogICAgICAgYnVzLXNjICAgMTI4ICAgODE2SyAgICAgICAtICAgICAxNDQ0 ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICBkZXZzdGF0ICAgIDEy ICAgIDI1SyAgICAgICAtICAgICAgIDEyICAzMiw0MDk2CiBldmVudGhhbmRsZXIgICAgOTMgICAg IDhLICAgICAgIC0gICAgICAgOTMgIDY0LDEyOAogICBERVZGU19SVUxFICAgIDU3ICAgIDI3SyAg ICAgICAtICAgICAgIDU3ICA2NCw1MTIKICAgICAgICBERVZGUyAgICAzMSAgICAgMUsgICAgICAg LSAgICAgICAzMiAgMTYsMTI4CiAgICAgICAgIGtvYmogICAxNTMgICA2MTJLICAgICAgIC0gICAg ICAyMjggIDQwOTYKICAgICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg MzIKICAgICAgIERFVkZTUCAgICAxNyAgICAgMksgICAgICAgLSAgICAgIDI5MyAgNjQKICAgICAg ICAgcm1hbiAgIDI2MyAgICAzMEsgICAgICAgLSAgICAgIDU0NyAgMTYsMzIsMTI4CiAgICAgICAg IHNidWYgICAgIDAgICAgIDBLICAgICAgIC0gICAgIDE1NDYgIDE2LDMyLDY0LDEyOCwyNTYsNTEy LDEwMjQsMjA0OCw0MDk2CiAgICAgICBzZ2xpc3QgICAgMTggICAgIDVLICAgICAgIC0gICAgICAg MjYgIDMyLDY0LDUxMiwxMDI0LDIwNDgKICAgICAgICBzdGFjayAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAgMiAgMjU2CiAgICB0YXNrcXVldWUgICAxMTcgICAgMTFLICAgICAgIC0gICAgICAx NzcgIDE2LDMyLDY0LDEyOCwxMDI0CiAgICAgICBVbml0bm8gICAgMTUgICAgIDFLICAgICAgIC0g ICAgIDU2NjcgIDMyLDY0CiAgICAgaW9jdGxvcHMgICAgIDAgICAgIDBLICAgICAgIC0gICAgIDYw MzkgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICBzZWxlY3QgICAg NTMgICAgIDdLICAgICAgIC0gICAgICAgNTMgIDEyOAogICAgICAgICAgaW92ICAgICAwICAgICAw SyAgICAgICAtICAgICA1MDI4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgICAgICAgbXNnICAg ICA0ICAgIDMwSyAgICAgICAtICAgICAgICA0ICAyMDQ4LDQwOTYKICAgICAgICAgIHNlbSAgICAg NCAgIDEwNksgICAgICAgLSAgICAgICAgNCAgMjA0OCw0MDk2CiAgICAgICAgICBzaG0gICAgIDEg ICAgMjBLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgICAgdHR5ICAgIDE4ICAgIDE4SyAgICAg ICAtICAgICAgIDIwICAxMDI0LDIwNDgKICAgICBtYnVmX3RhZyAgICAgMCAgICAgMEsgICAgICAg LSAgICAgIDMwMyAgMzIsNjQsMTI4CiAgICAgICAgc2htZmQgICAgIDEgICAgIDhLICAgICAgIC0g ICAgICAgIDEgIAogICAgICAgc29uYW1lICAgIDIzICAgICAzSyAgICAgICAtICAgICAgNzI1ICAx NiwzMiw2NCwxMjgKICAgICAgICAgIHBjYiAgICAyOCAgIDE1N0sgICAgICAgLSAgICAgICA2NiAg MTYsMzIsNjQsMTI4LDEwMjQsMjA0OCw0MDk2CiAgICAgICAgICBhY2wgICAgIDAgICAgIDBLICAg ICAgIC0gICAgICAgIDQgIDQwOTYKICAgICB2ZnNjYWNoZSAgICAgMSAgMTAyNEsgICAgICAgLSAg ICAgICAgMSAgCiAgICAgdmZzX2hhc2ggICAgIDEgICA1MTJLICAgICAgIC0gICAgICAgIDEgIAog ICAgICAgdm5vZGVzICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAyNTYKICAgICAgICBt b3VudCAgIDIwMSAgICAgN0sgICAgICAgLSAgICAgIDQ4NyAgMTYsMzIsNjQsMTI4LDI1NgogIHZu b2RlbWFya2VyICAgICAwICAgICAwSyAgICAgICAtICAgICAgMTc2ICA1MTIKICAgICAgICAgIEJQ RiAgICAxOSAgICAxOUsgICAgICAgLSAgICAgICAxOSAgMTI4LDUxMiw0MDk2CiAgICAgICAgaWZu ZXQgICAgMTEgICAgMjFLICAgICAgIC0gICAgICAgMTEgIDEyOCwyMDQ4CiAgICAgICBpZmFkZHIg ICAxMjYgICAgMzBLICAgICAgIC0gICAgICAxMjcgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgs NDA5NgogIGV0aGVyX211bHRpICAgIDQ4ICAgICAzSyAgICAgICAtICAgICAgIDYwICAxNiwzMiw2 NAogICAgICAgIGNsb25lICAgIDExICAgIDQ0SyAgICAgICAtICAgICAgIDExICA0MDk2CiAgICAg ICBhcnBjb20gICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDE2CiAgICAgICAgICBnaWYg ICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDI1NgogICAgICBsbHRhYmxlICAgIDI5ICAg IDEzSyAgICAgICAtICAgICAgIDI5ICAyNTYsNTEyCiAgICAgcm91dGV0YmwgICAgNDggICAgIDZL ICAgICAgIC0gICAgICAyMTYgIDMyLDY0LDEyOCwyNTYsNTEyCiAgICAgICAgIHZuZXQgICAgIDEg ICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICB2bmV0X2RhdGEgICAgIDEgICAgNjRLICAg ICAgIC0gICAgICAgIDEgIAp2bmV0X2RhdGFfZnJlZSAgICAgMSAgICAgMUsgICAgICAgLSAgICAg ICAgMSAgMzIKICAgICAgICAgaWdtcCAgICAxMCAgICAgM0sgICAgICAgLSAgICAgICAxMCAgMjU2 CiAgICAgICAgIGlwaWQgICAgIDIgICAgMjRLICAgICAgIC0gICAgICAgIDIgIAogICAgIGluX211 bHRpICAgICAzICAgICAxSyAgICAgICAtICAgICAgICA0ICAyNTYKZW5jYXBfZXhwb3J0X2hvc3Qg ICAgIDMgICAgIDNLICAgICAgIC0gICAgICAgIDMgIDEwMjQKICAgIHNjdHBfYV9pdCAgICAgMCAg ICAgMEsgICAgICAgLSAgICAgICAgNSAgMTYKICAgICBzY3RwX3ZyZiAgICAgMSAgICAgMUsgICAg ICAgLSAgICAgICAgMSAgNjQKICAgICBzY3RwX2lmYSAgICAgOCAgICAgMUsgICAgICAgLSAgICAg ICAgOCAgMTI4CiAgICAgc2N0cF9pZm4gICAgIDQgICAgIDFLICAgICAgIC0gICAgICAgIDQgIDEy OAogICAgc2N0cF9pdGVyICAgICAwICAgICAwSyAgICAgICAtICAgICAgICA1ICAyNTYKICAgIGhv c3RjYWNoZSAgICAgMSAgICAyOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgc3luY2FjaGUgICAg IDEgICAgOTZLICAgICAgIC0gICAgICAgIDEgIAogICAgaW42X211bHRpICAgIDMzICAgICA0SyAg ICAgICAtICAgICAgIDMzICAzMiwyNTYKICAgICAgICAgIG1sZCAgICAxMCAgICAgMksgICAgICAg LSAgICAgICAxMCAgMTI4CiAgbnVsbGZzX2hhc2ggICAgIDEgICAgIDFLICAgICAgIC0gICAgICAg IDEgIDEyOAogIGlucGNicG9saWN5ICAgIDIzICAgICAxSyAgICAgICAtICAgICAgNDE3ICAzMgog ICAgIHNlY2FzdmFyICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAyNTYKICAgICAgIHNh aGVhZCAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMjU2CiAgaXBzZWNwb2xpY3kgICAg NDggICAgMTJLICAgICAgIC0gICAgICA4NDYgIDI1NgogaXBzZWNyZXF1ZXN0ICAgICAyICAgICAx SyAgICAgICAtICAgICAgICAyICAxMjgKICAgaXBzZWMtbWlzYyAgICAxMiAgICAgMUsgICAgICAg LSAgICAgICAxMiAgMTYsMzIsNjQKICAgIGlwc2VjLXJlZyAgICAgMiAgICAgMUsgICAgICAgLSAg ICAgICAgMiAgMzIKICAgICAgIGNyeXB0byAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg NTEyCiAgICAgICAgeGZvcm0gICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgNzQgIDE2LDMyLDEy OCwyNTYsNDA5NgogICAgICAgICAgcnBjICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAy NTYKYXVkaXRfZXZjbGFzcyAgIDE3OSAgICAgNksgICAgICAgLSAgICAgIDIxOCAgMzIKICAgICAg cGFnZWRlcCAgICAgMSAgICA2NEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgaW5vZGVkZXAgICAg IDEgICA1MTJLICAgICAgIC0gICAgICAgIDEgIAogICAgYm1zYWZlbWFwICAgICAxICAgICA4SyAg ICAgICAtICAgICAgICAxICAKICAgICAgIG5ld2JsayAgICAgMSAgICA2NEsgICAgICAgLSAgICAg ICAgMSAgCiAgICAgZnJlZXdvcmsgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDE2CiAg ICB1ZnNfbW91bnQgICAgIDMgICAgMTdLICAgICAgIC0gICAgICAgIDMgIDUxMiw0MDk2CiAgICB2 bV9wZ2RhdGEgICAgIDIgICAxMjlLICAgICAgIC0gICAgICAgIDIgIDEyOAogICAgcGZzX25vZGVz ICAgIDczICAgIDE5SyAgICAgICAtICAgICAgIDczICAyNTYKICAgICAgIGZlZWRlciAgICAyOSAg ICAgM0sgICAgICAgLSAgICAgICAzOSAgMzIsMTI4CiAgICAgICBrYmRtdXggICAgIDggICAgMThL ICAgICAgIC0gICAgICAgIDggIDE2LDUxMiwxMDI0LDIwNDgKICAgICAgbWVtZGVzYyAgICAgMSAg ICAgNEsgICAgICAgLSAgICAgICAgMiAgNDA5NgogICAgICAgICAgTEVEICAgIDEyICAgICAxSyAg ICAgICAtICAgICAgIDEyICAxNiwxMjgKICAgICAgICAgR0VPTSAgIDEyMyAgICAyM0sgICAgICAg LSAgICAgIDg5NSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNAogICBhZXNuaV9kYXRhICAgICAy ICAgICA0SyAgICAgICAtICAgICAgICAzICAzMiwyMDQ4CiAgICAgYXRrYmRkZXYgICAgIDIgICAg IDFLICAgICAgIC0gICAgICAgIDIgIDY0CiAgICAgICAgbWl4ZXIgICAgIDggICAgMzJLICAgICAg IC0gICAgICAgIDggIDQwOTYKICAgQ0FNIHBlcmlwaCAgICAxMSAgICAgM0sgICAgICAgLSAgICAg ICAyOCAgMTYsMzIsNjQsMjU2CiAgICBDQU0gcXVldWUgICAgNDYgICAgIDJLICAgICAgIC0gICAg ICAxNTEgIDE2LDMyLDI1NgpDQU0gZGV2IHF1ZXVlICAgIDEyICAgICAySyAgICAgICAtICAgICAg IDEyICAxMjgKICBkZGJfY2FwdHVyZSAgICAgMSAgICA0OEsgICAgICAgLSAgICAgICAgMSAgCiAg ICAgICAgIFVBUlQgICAgIDMgICAgIDJLICAgICAgIC0gICAgICAgIDMgIDE2LDUxMiwxMDI0CiAg ICAgICAgbGludXggICAgMTggICAgIDJLICAgICAgIC0gICAgICAgMTggIDY0CiAgICAgYWNwaWlu dHIgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAgICBhcG1kZXYgICAgIDEg ICAgIDFLICAgICAgIC0gICAgICAgIDEgIDEyOAogICAgICAgYWNwaWNhICAzOTE4ICAgMzk5SyAg ICAgICAtICAgIDQ4NTYwICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgKICAgICBwY2lf bGluayAgICAxNiAgICAgMksgICAgICAgLSAgICAgICAxNiAgNjQsMTI4CiAgICAgICBpc2FkZXYg ICAgIDcgICAgIDFLICAgICAgIC0gICAgICAgIDcgIDEyOAogICAgYWNwaV9wZXJmICAgICA4ICAg ICA0SyAgICAgICAtICAgICAgICA4ICA1MTIKICAgICAgaW9fYXBpYyAgICAgMSAgICAgMksgICAg ICAgLSAgICAgICAgMSAgMjA0OAogICAgICBlbnRyb3B5ICAxMDI0ICAgIDY0SyAgICAgICAtICAg ICAxMDI0ICA2NAogICAgICAgICAgTUNBICAgICA5ICAgICAySyAgICAgICAtICAgICAgICA5ICA2 NCwxMjgKICAgICAgICAgY2RldiAgICAgOCAgICAgMksgICAgICAgLSAgICAgICAgOCAgMjU2CiAg ICAgICAgICBtc2kgICAgMTMgICAgIDJLICAgICAgIC0gICAgICAgMTMgIDEyOAogICAgIG5leHVz ZGV2ICAgICA1ICAgICAxSyAgICAgICAtICAgICAgICA1ICAxNgogICAgICAgICAgVVNCICAgIDgz ICAgIDkwSyAgICAgICAtICAgICAgIDkyICAxNiwzMiw2NCwxMjgsMjU2LDIwNDgsNDA5NgogICAg ICAgVVNCZGV2ICAgIDkzICAgIDQxSyAgICAgICAtICAgICAgMzY3ICA2NCwxMjgsNTEyLDEwMjQs NDA5NgogICAgIGZpbGVkZXNjICAgIDc3ICAgIDU0SyAgICAgICAtICAgICAyMTk5ICAzMiw1MTIs MTAyNCw0MDk2CiAgICAgIHNvbGFyaXMgMzE5MTMgOTg5MTJLICAgICAgIC0gICAyMzIzOTcgIDE2 LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgIGtzdGF0X2RhdGEgICAgIDQgICAg IDFLICAgICAgIC0gICAgICAgIDQgIDY0CiAgICAgICBudmlkaWEgIDEwMjEgIDI5NTNLICAgICAg IC0gICAgIDQyNTEgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgaXBy dGhlYXAgICAgMTIgICAgIDFLICAgICAgIC0gICAgICAgMTIgIDMyLDY0LDEyOCwyNTYKCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQp2bXN0YXQgLXoKCklURU0gICAgICAgICAgICAgICAgICAgU0laRSAgTElNSVQg ICAgIFVTRUQgICAgIEZSRUUgICAgICBSRVEgRkFJTCBTTEVFUAoKVU1BIEtlZ3M6ICAgICAgICAg ICAgICAgMjA4LCAgICAgIDAsICAgICAyMDksICAgICAgMTIsICAgICAyMDksICAgMCwgICAwClVN QSBab25lczogICAgICAgICAgICAgMTQwOCwgICAgICAwLCAgICAgMjA5LCAgICAgICAxLCAgICAg MjA5LCAgIDAsICAgMApVTUEgU2xhYnM6ICAgICAgICAgICAgICA1NjgsICAgICAgMCwgICAgNDMx MSwgICAgICAxNSwgICAgNjE5NywgICAwLCAgIDAKVU1BIFJDbnRTbGFiczogICAgICAgICAgNTY4 LCAgICAgIDAsICAgICA3NjUsICAgICAgIDUsICAgICA3NjUsICAgMCwgICAwClVNQSBIYXNoOiAg ICAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgIDgyLCAgICAgICA4LCAgICAgIDgyLCAgIDAs ICAgMAoxNiBCdWNrZXQ6ICAgICAgICAgICAgICAxNTIsICAgICAgMCwgICAgIDE2NCwgICAgICAx MSwgICAgIDE2NCwgICAwLCAgIDAKMzIgQnVja2V0OiAgICAgICAgICAgICAgMjgwLCAgICAgIDAs ICAgICAxNzcsICAgICAgIDUsICAgICAxNzcsICAgMSwgICAwCjY0IEJ1Y2tldDogICAgICAgICAg ICAgIDUzNiwgICAgICAwLCAgICAgMjIxLCAgICAgICAzLCAgICAgMjIxLCAxNjIsICAgMAoxMjgg QnVja2V0OiAgICAgICAgICAgIDEwNDgsICAgICAgMCwgICAgIDI1NSwgICAgICAgMCwgICAgIDI1 NSwgNTc1LCAgIDAKVk0gT0JKRUNUOiAgICAgICAgICAgICAgMjE2LCAgICAgIDAsICAgIDI3Nzcs ICAgICA0NDUsICAgMzAxOTUsICAgMCwgICAwCk1BUDogICAgICAgICAgICAgICAgICAgIDIzMiwg ICAgICAwLCAgICAgICA3LCAgICAgIDI1LCAgICAgICA3LCAgIDAsICAgMApLTUFQIEVOVFJZOiAg ICAgICAgICAgICAxMjAsICA1NTM5NywgICAgICA2MSwgICAgIDk2MiwgICAxNTMwOSwgICAwLCAg IDAKTUFQIEVOVFJZOiAgICAgICAgICAgICAgMTIwLCAgICAgIDAsICAgIDE1NjgsICAgICA0NDcs ICAgNjcwMzMsICAgMCwgICAwCmZha2VwZzogICAgICAgICAgICAgICAgIDEyMCwgICAgICAwLCAg ICAgMTUyLCAgICAgIDk2LCAgICAgMTc3LCAgIDAsICAgMAptdF96b25lOiAgICAgICAgICAgICAg IDQxMTIsICAgICAgMCwgICAgIDI5OSwgICAgICAyMywgICAgIDI5OSwgICAwLCAgIDAKMTY6ICAg ICAgICAgICAgICAgICAgICAgIDE2LCAgICAgIDAsICAgIDQxMTgsICAgICA3NTQsICAgNzI1NTQs ICAgMCwgICAwCjMyOiAgICAgICAgICAgICAgICAgICAgICAzMiwgICAgICAwLCAgICA0NzAzLCAg ICAxMDU0LCAgIDMxNjQ2LCAgIDAsICAgMAo2NDogICAgICAgICAgICAgICAgICAgICAgNjQsICAg ICAgMCwgICAzMzU1NiwgICAgIDk5NiwgIDExMTgzMiwgICAwLCAgIDAKMTI4OiAgICAgICAgICAg ICAgICAgICAgMTI4LCAgICAgIDAsICAgIDg2MjYsICAgICA3NDEsICAgNDk1OTEsICAgMCwgICAw CjI1NjogICAgICAgICAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICA0MjEyLCAgICAgNTczLCAg IDIwMjAxLCAgIDAsICAgMAo1MTI6ICAgICAgICAgICAgICAgICAgICA1MTIsICAgICAgMCwgICAg MzEyNSwgICAgIDI5MSwgICA1NTIzOCwgICAwLCAgIDAKMTAyNDogICAgICAgICAgICAgICAgICAx MDI0LCAgICAgIDAsICAgICAzNzcsICAgIDE4NjMsICAgIDkzNzgsICAgMCwgICAwCjIwNDg6ICAg ICAgICAgICAgICAgICAgMjA0OCwgICAgICAwLCAgICAgNjEwLCAgICAgMTU0LCAgICAyNDU2LCAg IDAsICAgMAo0MDk2OiAgICAgICAgICAgICAgICAgIDQwOTYsICAgICAgMCwgICAgIDkxNCwgICAg IDI0NSwgICAgOTc1MSwgICAwLCAgIDAKRmlsZXM6ICAgICAgICAgICAgICAgICAgIDgwLCAgICAg IDAsICAgICAzMDQsICAgICA0NjEsICAgMTE2OTIsICAgMCwgICAwClRVUk5TVElMRTogICAgICAg ICAgICAgIDEzNiwgICAgICAwLCAgICAgNzY5LCAgICAgIDUxLCAgICAgNzY5LCAgIDAsICAgMAp1 bXR4IHBpOiAgICAgICAgICAgICAgICAgOTYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDAKTUFDIGxhYmVsczogICAgICAgICAgICAgIDQwLCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwClBST0M6ICAgICAgICAgICAgICAgICAgMTE2 MCwgICAgICAwLCAgICAgIDU4LCAgICAgMTIyLCAgICAyMTA1LCAgIDAsICAgMApUSFJFQUQ6ICAg ICAgICAgICAgICAgIDExMTIsICAgICAgMCwgICAgIDU5NiwgICAgIDE3MiwgICAgIDkwNCwgICAw LCAgIDAKU0xFRVBRVUVVRTogICAgICAgICAgICAgIDgwLCAgICAgIDAsICAgICA3NjksICAgICAx MzAsICAgICA3NjksICAgMCwgICAwClZNU1BBQ0U6ICAgICAgICAgICAgICAgIDM5MiwgICAgICAw LCAgICAgIDM3LCAgICAgMTgzLCAgICAyMDg1LCAgIDAsICAgMApjcHVzZXQ6ICAgICAgICAgICAg ICAgICAgNzIsICAgICAgMCwgICAgICAgMiwgICAgICA5OCwgICAgICAgMiwgICAwLCAgIDAKYXVk aXRfcmVjb3JkOiAgICAgICAgICAgOTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCm1idWZfcGFja2V0OiAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgNTEy LCAgICAgNzgyLCAgICAxMjQ2LCAgIDAsICAgMAptYnVmOiAgICAgICAgICAgICAgICAgICAyNTYs ICAgICAgMCwgICAgICAxNSwgICAgIDg5NSwgICAgNDE1MywgICAwLCAgIDAKbWJ1Zl9jbHVzdGVy OiAgICAgICAgICAyMDQ4LCAgMjU2MDAsICAgIDEyODAsICAgICAxNDIsICAgIDEyOTgsICAgMCwg ICAwCm1idWZfanVtYm9fcGFnZTogICAgICAgNDA5NiwgIDEyODAwLCAgICAgICAwLCAgICAgIDU0 LCAgICAyMTg0LCAgIDAsICAgMAptYnVmX2p1bWJvXzlrOiAgICAgICAgIDkyMTYsICAxOTIwMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKbWJ1Zl9qdW1ib18xNms6ICAgICAg IDE2Mzg0LCAgMTI4MDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCm1idWZf ZXh0X3JlZmNudDogICAgICAgICAgNCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMApnX2JpbzogICAgICAgICAgICAgICAgICAyMzIsICAgICAgMCwgICAgICAgMCwg ICAgIDMzNiwgICAxNTM1NywgICAwLCAgIDAKdHR5aW5xOiAgICAgICAgICAgICAgICAgMTYwLCAg ICAgIDAsICAgICAxMzUsICAgICAxMjksICAgICA3NTAsICAgMCwgICAwCnR0eW91dHE6ICAgICAg ICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgIDcyLCAgICAgIDkzLCAgICAgMzg0LCAgIDAsICAg MAphdGFfcmVxdWVzdDogICAgICAgICAgICAzMjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKYXRhX2NvbXBvc2l0ZTogICAgICAgICAgMzM2LCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCmNyeXB0b3A6ICAgICAgICAgICAgICAg ICA4OCwgICAgICAwLCAgICAgICAxLCAgICAgMTI1LCAgICAgICAyLCAgIDAsICAgMApjcnlwdG9k ZXNjOiAgICAgICAgICAgICAgNzIsICAgICAgMCwgICAgICAgMSwgICAgIDE0OSwgICAgICAgMiwg ICAwLCAgIDAKbnZfc3RhY2tfdDogICAgICAgICAgIDEyMjg4LCAgICAgIDAsICAgICAgIDcsICAg ICAgMjAsICAgICAyMTcsICAgMCwgICAwCnRhc2txX3pvbmU6ICAgICAgICAgICAgICA0OCwgICAg ICAwLCAgICAgICAwLCAgICAgMzYwLCAgICAgIDQ5LCAgIDAsICAgMApWTk9ERTogICAgICAgICAg ICAgICAgICA0ODAsICAgICAgMCwgICAgMTc1NiwgICAgIDIxMiwgICAgMTgwMSwgICAwLCAgIDAK Vk5PREVQT0xMOiAgICAgICAgICAgICAgMTEyLCAgICAgIDAsICAgICAgNTUsICAgICAxMTAsICAg ICAgNTUsICAgMCwgICAwCk5BTUVJOiAgICAgICAgICAgICAgICAgMTAyNCwgICAgICAwLCAgICAg ICAwLCAgICAgIDk2LCAgIDI5OTcxLCAgIDAsICAgMApTIFZGUyBDYWNoZTogICAgICAgICAgICAx MDgsICAgICAgMCwgICAgMTUyNSwgICAgIDI1NywgICAgODAxNCwgICAwLCAgIDAKTCBWRlMgQ2Fj aGU6ICAgICAgICAgICAgMzI4LCAgICAgIDAsICAgICAgNzQsICAgICAgMzQsICAgICAgNzQsICAg MCwgICAwCkRJUkhBU0g6ICAgICAgICAgICAgICAgMTAyNCwgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMApOQ0xOT0RFOiAgICAgICAgICAgICAgICA1NjAsICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGlwZTogICAgICAgICAgICAg ICAgICAgNzI4LCAgICAgIDAsICAgICAgNTcsICAgICAxMTMsICAgIDE0NDUsICAgMCwgICAwCk1v dW50cG9pbnRzOiAgICAgICAgICAgIDc2OCwgICAgICAwLCAgICAgIDIwLCAgICAgIDEwLCAgICAg IDIwLCAgIDAsICAgMApBSU86ICAgICAgICAgICAgICAgICAgICAyMDgsICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKQUlPUDogICAgICAgICAgICAgICAgICAgIDMy LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCkFJT0NCOiAgICAg ICAgICAgICAgICAgIDQ4MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMApBSU9MOiAgICAgICAgICAgICAgICAgICAxMjgsICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKQUlPTElPOiAgICAgICAgICAgICAgICAgMjcyLCAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19jYWNoZTogICAgICAgICAg ICAgIDg4MCwgICAgICAwLCAgICAgICAyLCAgICAxNzEwLCAgIDU5NDA1LCAgIDAsICAgMAp6aW9f bGlua19jYWNoZTogICAgICAgICAgNDgsICAgICAgMCwgICAgICAgMCwgICAgMjk1MiwgICAyMDcz OCwgICAwLCAgIDAKemlvX2J1Zl81MTI6ICAgICAgICAgICAgNTEyLCAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl81MTI6ICAgICAgIDUxMiwg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzEwMjQ6 ICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKemlvX2RhdGFfYnVmXzEwMjQ6ICAgICAxMDI0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMTUzNjogICAgICAgICAgMTUzNiwgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTUzNjogICAg IDE1MzYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1 Zl8yMDQ4OiAgICAgICAgICAyMDQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCnppb19kYXRhX2J1Zl8yMDQ4OiAgICAgMjA0OCwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzI1NjA6ICAgICAgICAgIDI1NjAsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzI1 NjA6ICAgICAyNTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw Cnppb19idWZfMzA3MjogICAgICAgICAgMzA3MiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMzA3MjogICAgIDMwNzIsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8zNTg0OiAgICAgICAgICAz NTg0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRh X2J1Zl8zNTg0OiAgICAgMzU4NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMAp6aW9fYnVmXzQwOTY6ICAgICAgICAgIDQwOTYsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzQwOTY6ICAgICA0MDk2LCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfNTEyMDogICAg ICAgICAgNTEyMCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6 aW9fZGF0YV9idWZfNTEyMDogICAgIDUxMjAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDAKemlvX2J1Zl82MTQ0OiAgICAgICAgICA2MTQ0LCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl82MTQ0OiAgICAgNjE0 NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzcx Njg6ICAgICAgICAgIDcxNjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAw LCAgIDAKemlvX2RhdGFfYnVmXzcxNjg6ICAgICA3MTY4LCAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfODE5MjogICAgICAgICAgODE5MiwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfODE5Mjog ICAgIDgxOTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlv X2J1Zl8xMDI0MDogICAgICAgIDEwMjQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8xMDI0MDogICAxMDI0MCwgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzEyMjg4OiAgICAgICAgMTIyODgs ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVm XzEyMjg4OiAgIDEyMjg4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCnppb19idWZfMTQzMzY6ICAgICAgICAxNDMzNiwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTQzMzY6ICAgMTQzMzYsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8xNjM4NDogICAgICAg IDE2Mzg0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19k YXRhX2J1Zl8xNjM4NDogICAxNjM4NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMAp6aW9fYnVmXzIwNDgwOiAgICAgICAgMjA0ODAsICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzIwNDgwOiAgIDIwNDgwLCAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMjQ1NzY6 ICAgICAgICAyNDU3NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MAp6aW9fZGF0YV9idWZfMjQ1NzY6ICAgMjQ1NzYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8yODY3MjogICAgICAgIDI4NjcyLCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8yODY3MjogICAy ODY3MiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVm XzMyNzY4OiAgICAgICAgMzI3NjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKemlvX2RhdGFfYnVmXzMyNzY4OiAgIDMyNzY4LCAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMzY4NjQ6ICAgICAgICAzNjg2NCwgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMzY4 NjQ6ICAgMzY4NjQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAK emlvX2J1Zl80MDk2MDogICAgICAgIDQwOTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl80MDk2MDogICA0MDk2MCwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzQ1MDU2OiAgICAgICAgNDUw NTYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFf YnVmXzQ1MDU2OiAgIDQ1MDU2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwCnppb19idWZfNDkxNTI6ICAgICAgICA0OTE1MiwgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfNDkxNTI6ICAgNDkxNTIsICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl81MzI0ODogICAg ICAgIDUzMjQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnpp b19kYXRhX2J1Zl81MzI0ODogICA1MzI0OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMAp6aW9fYnVmXzU3MzQ0OiAgICAgICAgNTczNDQsICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzU3MzQ0OiAgIDU3MzQ0 LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfNjE0 NDA6ICAgICAgICA2MTQ0MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMAp6aW9fZGF0YV9idWZfNjE0NDA6ICAgNjE0NDAsICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl82NTUzNjogICAgICAgIDY1NTM2LCAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl82NTUzNjog ICA2NTUzNiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9f YnVmXzY5NjMyOiAgICAgICAgNjk2MzIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzY5NjMyOiAgIDY5NjMyLCAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfNzM3Mjg6ICAgICAgICA3MzcyOCwg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZf NzM3Mjg6ICAgNzM3MjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKemlvX2J1Zl83NzgyNDogICAgICAgIDc3ODI0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl83NzgyNDogICA3NzgyNCwgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzgxOTIwOiAgICAgICAg ODE5MjAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2Rh dGFfYnVmXzgxOTIwOiAgIDgxOTIwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCnppb19idWZfODYwMTY6ICAgICAgICA4NjAxNiwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfODYwMTY6ICAgODYwMTYsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl85MDExMjog ICAgICAgIDkwMTEyLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw Cnppb19kYXRhX2J1Zl85MDExMjogICA5MDExMiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzk0MjA4OiAgICAgICAgOTQyMDgsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzk0MjA4OiAgIDk0 MjA4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZf OTgzMDQ6ICAgICAgICA5ODMwNCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMAp6aW9fZGF0YV9idWZfOTgzMDQ6ICAgOTgzMDQsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8xMDI0MDA6ICAgICAgMTAyNDAwLCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8xMDI0 MDA6IDEwMjQwMCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6 aW9fYnVmXzEwNjQ5NjogICAgICAxMDY0OTYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzEwNjQ5NjogMTA2NDk2LCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMTEwNTkyOiAgICAgIDExMDU5 MiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9i dWZfMTEwNTkyOiAxMTA1OTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAw LCAgIDAKemlvX2J1Zl8xMTQ2ODg6ICAgICAgMTE0Njg4LCAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8xMTQ2ODg6IDExNDY4OCwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzExODc4NDogICAg ICAxMTg3ODQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlv X2RhdGFfYnVmXzExODc4NDogMTE4Nzg0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCnppb19idWZfMTIyODgwOiAgICAgIDEyMjg4MCwgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTIyODgwOiAxMjI4ODAs ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8xMjY5 NzY6ICAgICAgMTI2OTc2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCnppb19kYXRhX2J1Zl8xMjY5NzY6IDEyNjk3NiwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzEzMTA3MjogICAgICAxMzEwNzIsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzEzMTA3Mjog MTMxMDcyLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNhX2Nh Y2hlOiAgICAgICAgICAgICAgICA4MCwgICAgICAwLCAgICAxNjEyLCAgICAgMzY4LCAgICAxNjU2 LCAgIDAsICAgMApkbm9kZV90OiAgICAgICAgICAgICAgICA4NTYsICAgICAgMCwgICAgMjA3MCwg ICAgIDE1OCwgICAgMjY5NSwgICAwLCAgIDAKZG11X2J1Zl9pbXBsX3Q6ICAgICAgICAgMjI0LCAg ICAgIDAsICAgIDQzNzIsICAgICAzMjAsICAgIDQ1NjgsICAgMCwgICAwCmFyY19idWZfaGRyX3Q6 ICAgICAgICAgIDIxNiwgICAgICAwLCAgICAyNjc4LCAgICAgMjAyLCAgICAyNzk1LCAgIDAsICAg MAphcmNfYnVmX3Q6ICAgICAgICAgICAgICAxMDQsICAgICAgMCwgICAgMjYyOSwgICAgIDI4Nywg ICAgMjg3NywgICAwLCAgIDAKemlsX2x3Yl9jYWNoZTogICAgICAgICAgMTkyLCAgICAgIDAsICAg ICAgIDMsICAgICAgNzcsICAgICAgMTQsICAgMCwgICAwCnpmc196bm9kZV9jYWNoZTogICAgICAg IDQwMCwgICAgICAwLCAgICAxNjEyLCAgICAgMTE2LCAgICAxNjU2LCAgIDAsICAgMAprc2lnaW5m bzogICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAgIDE1OSwgICAgIDg5NywgICAgIDIyMSwg ICAwLCAgIDAKaXRpbWVyOiAgICAgICAgICAgICAgICAgMzQ0LCAgICAgIDAsICAgICAgIDEsICAg ICAgMjEsICAgICAgIDEsICAgMCwgICAwCmJyaWRnZV9ydG5vZGU6ICAgICAgICAgICA2NCwgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApLTk9URTogICAgICAgICAg ICAgICAgICAxMjgsICAgICAgMCwgICAgICA3NCwgICAgIDEwMCwgICAgICA5NSwgICAwLCAgIDAK cGZzcmN0cnBsOiAgICAgICAgICAgICAgMTUyLCAgMTAwMDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwCnBmcnVsZXBsOiAgICAgICAgICAgICAgIDkzNiwgICAgICAwLCAgICAg IDE1LCAgICAgICA1LCAgICAgIDE1LCAgIDAsICAgMApwZnN0YXRlcGw6ICAgICAgICAgICAgICAy ODgsICAxMDAxMCwgICAgICAgOSwgICAgICA1NiwgICAgICAyNiwgICAwLCAgIDAKcGZzdGF0ZWtl eXBsOiAgICAgICAgICAgMjg4LCAgICAgIDAsICAgICAgIDksICAgICAgNTYsICAgICAgMjYsICAg MCwgICAwCnBmc3RhdGVpdGVtcGw6ICAgICAgICAgIDI4OCwgICAgICAwLCAgICAgICA5LCAgICAg IDU2LCAgICAgIDI2LCAgIDAsICAgMApwZmFsdHFwbDogICAgICAgICAgICAgICAyNDAsICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZwb29sYWRkcnBsOiAgICAg ICAgICAgIDg4LCAgICAgIDAsICAgICAgIDEsICAgICAgODMsICAgICAgIDEsICAgMCwgICAwCnBm cmt0YWJsZTogICAgICAgICAgICAgMTI5NiwgICAxMDAyLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMApwZnJrZW50cnk6ICAgICAgICAgICAgICAxNjAsIDIwMDAxNiwgICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZmcmVudDogICAgICAgICAgICAgICAgIDMy LCAgIDUwNTAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmZnJhZzogICAg ICAgICAgICAgICAgICA4MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMApwZmZyY2FjaGU6ICAgICAgICAgICAgICAgODAsICAxMDAzNSwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKcGZmcmNlbnQ6ICAgICAgICAgICAgICAgIDI0LCAgNTAwMjIs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmc3RhdGVzY3J1YjogICAgICAg ICAgICA0MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZmlh ZGRycGw6ICAgICAgICAgICAgICAxMjAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKcGZvc3BmZW46ICAgICAgICAgICAgICAgMTEyLCAgICAgIDAsICAgICA3MDAs ICAgICAgMjYsICAgICA3MDAsICAgMCwgICAwCnBmb3NmcDogICAgICAgICAgICAgICAgICA0MCwg ICAgICAwLCAgICAgNDEwLCAgICAgIDk0LCAgICAgNDEwLCAgIDAsICAgMApwZnN5bmM6ICAgICAg ICAgICAgICAgICAgODgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKc29ja2V0OiAgICAgICAgICAgICAgICAgNjgwLCAgMjU2MDIsICAgICAgNzEsICAgICAgNzks ICAgICA2MjAsICAgMCwgICAwCnVucGNiOiAgICAgICAgICAgICAgICAgIDI0MCwgIDI1NjAwLCAg ICAgIDQzLCAgICAgMTMzLCAgICAgMTg2LCAgIDAsICAgMAppcHE6ICAgICAgICAgICAgICAgICAg ICAgNTYsICAgIDgxOSwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKdWRwX2lu cGNiOiAgICAgICAgICAgICAgMzkyLCAgMjU2MDAsICAgICAgMTcsICAgICAgODMsICAgICA0MDgs ICAgMCwgICAwCnVkcGNiOiAgICAgICAgICAgICAgICAgICAxNiwgIDI1NzA0LCAgICAgIDE3LCAg ICAgODIzLCAgICAgNDA4LCAgIDAsICAgMAp0Y3BfaW5wY2I6ICAgICAgICAgICAgICAzOTIsICAy NTYwMCwgICAgICAgNCwgICAgICAzNiwgICAgICAgNywgICAwLCAgIDAKdGNwY2I6ICAgICAgICAg ICAgICAgICAgOTc2LCAgMjU2MDAsICAgICAgIDMsICAgICAgMTcsICAgICAgIDcsICAgMCwgICAw CnRjcHR3OiAgICAgICAgICAgICAgICAgICA3MiwgICA1MTUwLCAgICAgICAxLCAgICAgIDk5LCAg ICAgICAxLCAgIDAsICAgMApzeW5jYWNoZTogICAgICAgICAgICAgICAxNTIsICAxNTM3NSwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKaG9zdGNhY2hlOiAgICAgICAgICAgICAg MTM2LCAgMTUzNzIsICAgICAgIDEsICAgICAgNTUsICAgICAgIDEsICAgMCwgICAwCnRjcHJlYXNz OiAgICAgICAgICAgICAgICA0MCwgICAxNjgwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMApzYWNraG9sZTogICAgICAgICAgICAgICAgMzIsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDAKc2N0cF9lcDogICAgICAgICAgICAgICAxMzY4LCAgMjU2 MDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfYXNvYzogICAgICAg ICAgICAgMjI4MCwgIDQwMDAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApz Y3RwX2xhZGRyOiAgICAgICAgICAgICAgNDgsICA4MDA2NCwgICAgICAgMCwgICAgIDIxNiwgICAg ICAgNywgICAwLCAgIDAKc2N0cF9yYWRkcjogICAgICAgICAgICAgNzA0LCAgODAwMDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfY2h1bms6ICAgICAgICAgICAgIDEz NiwgNDAwMDA4LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3RwX3JlYWRx OiAgICAgICAgICAgICAxMDQsIDQwMDAzMiwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAw LCAgIDAKc2N0cF9zdHJlYW1fbXNnX291dDogICAgMTEyLCA0MDAwMjYsICAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfYXNjb25mOiAgICAgICAgICAgICA0MCwgNDAwMDA4 LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3RwX2FzY29uZl9hY2s6ICAg ICAgICAgNDgsIDQwMDAzMiwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcmlw Y2I6ICAgICAgICAgICAgICAgICAgMzkyLCAgMjU2MDAsICAgICAgIDIsICAgICAgMjgsICAgICAg IDIsICAgMCwgICAwCnJ0ZW50cnk6ICAgICAgICAgICAgICAgIDIwMCwgICAgICAwLCAgICAgIDI1 LCAgICAgIDUxLCAgICAgIDI2LCAgIDAsICAgMApzZWxmZDogICAgICAgICAgICAgICAgICAgNTYs ICAgICAgMCwgICAgIDEyNSwgICAgIDQ0MiwgICAzMzgxOCwgICAwLCAgIDAKU1dBUE1FVEE6ICAg ICAgICAgICAgICAgMjg4LCAxMTY1MTksICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCkZGUyBpbm9kZTogICAgICAgICAgICAgIDE2OCwgICAgICAwLCAgICAgICAyLCAgICAgIDY0 LCAgICAgICAyLCAgIDAsICAgMApGRlMxIGRpbm9kZTogICAgICAgICAgICAxMjgsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKRkZTMiBkaW5vZGU6ICAgICAgICAg ICAgMjU2LCAgICAgIDAsICAgICAgIDIsICAgICAgNDMsICAgICAgIDIsICAgMCwgICAwCgoKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCnZtc3RhdCAtaQoKaW50ZXJydXB0ICAgICAgICAgICAgICAgICAgICAgICAg ICB0b3RhbCAgICAgICByYXRlCmlycTE6IGF0a2JkMCAgICAgICAgICAgICAgICAgICAgICAgICAx NTAgICAgICAgICAgMwppcnExNjogdmdhcGNpMCByZTArICAgICAgICAgICAgICAgICAxNzkxICAg ICAgICAgNDQKaXJxMjM6IGVoY2kxICAgICAgICAgICAgICAgICAgICAgICAgIDI2NiAgICAgICAg ICA2CmNwdTA6dGltZXIgICAgICAgICAgICAgICAgICAgICAgICAgMTM4MzYgICAgICAgIDM0NQpp cnEyNTY6IGhkYWMwICAgICAgICAgICAgICAgICAgICAgICAgICAxICAgICAgICAgIDAKaXJxMjU3 OiBoZGFjMSAgICAgICAgICAgICAgICAgICAgICAgICA0MiAgICAgICAgICAxCmlycTI1ODogYWhj aTAgICAgICAgICAgICAgICAgICAgICAgIDQyMjUgICAgICAgIDEwNQppcnEyNTk6IHJlMSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAzICAgICAgICAgIDAKaXJxMjYwOiBhaGNpMSAgICAgICAg ICAgICAgICAgICAgICAgMTEwOSAgICAgICAgIDI3CmNwdTE6dGltZXIgICAgICAgICAgICAgICAg ICAgICAgICAgIDIxNTEgICAgICAgICA1MwpjcHU0OnRpbWVyICAgICAgICAgICAgICAgICAgICAg ICAgICA1NDczICAgICAgICAxMzYKY3B1Mjp0aW1lciAgICAgICAgICAgICAgICAgICAgICAgICAg NzI4NiAgICAgICAgMTgyCmNwdTM6dGltZXIgICAgICAgICAgICAgICAgICAgICAgICAgIDIwNTgg ICAgICAgICA1MQpjcHU1OnRpbWVyICAgICAgICAgICAgICAgICAgICAgICAgICAxNTUyICAgICAg ICAgMzgKY3B1Njp0aW1lciAgICAgICAgICAgICAgICAgICAgICAgICAgMzExNCAgICAgICAgIDc3 CmNwdTc6dGltZXIgICAgICAgICAgICAgICAgICAgICAgICAgIDEyMDggICAgICAgICAzMApUb3Rh bCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDQ0MjY1ICAgICAgIDExMDYKCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpwc3RhdCAtVAoKMzA0LzEyMzI4IGZpbGVzCjBNLzgxOTFNIHN3YXAgc3BhY2UKCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQpwc3RhdCAtcwoKRGV2aWNlICAgICAgICAgIDUxMi1ibG9ja3MgICAgIFVz ZWQgICAgQXZhaWwgQ2FwYWNpdHkKL2Rldi8jQzowOjB4N2UgICAgMTY3NzY5NjAgICAgICAgIDAg MTY3NzY5NjAgICAgIDAlCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KaW9zdGF0Cgppb3N0YXQ6IGt2bV9yZWFk KF90a19uaW4pOiBpbnZhbGlkIGFkZHJlc3MgKDB4MCkKaW9zdGF0OiBkaXNhYmxpbmcgVFRZIHN0 YXRpc3RpY3MKICAgICAgICAgICAgYWRhMCAgICAgICAgICAgICBhZGExICAgICAgICAgICAgIGFk YTIgICAgICAgICAgICAgY3B1CiAgS0IvdCB0cHMgIE1CL3MgICBLQi90IHRwcyAgTUIvcyAgIEtC L3QgdHBzICBNQi9zICB1cyBuaSBzeSBpbiBpZAogMjIuNDcgMTA1ICAyLjMwICAgNy4xNSAgMTAg IDAuMDcgICA4LjEwICAgOSAgMC4wNyAgIDAgIDAgIDEgIDEgOTgKCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpp cGNzIC1hCgpNZXNzYWdlIFF1ZXVlczoKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUg ICAgICAgIE9XTkVSICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgICAgICAgICAg Q0JZVEVTICAgICAgICAgICAgICAgICBRTlVNICAgICAgICAgICAgICAgUUJZVEVTICAgICAgICBM U1BJRCAgICAgICAgTFJQSUQgU1RJTUUgICAgUlRJTUUgICAgQ1RJTUUgICAKClNoYXJlZCBNZW1v cnk6ClQgICAgICAgICAgIElEICAgICAgICAgIEtFWSBNT0RFICAgICAgICBPV05FUiAgICBHUk9V UCAgICBDUkVBVE9SICBDR1JPVVAgICAgICAgICBOQVRUQ0ggICAgICAgIFNFR1NaICAgICAgICAg Q1BJRCAgICAgICAgIExQSUQgQVRJTUUgICAgRFRJTUUgICAgQ1RJTUUgICAKClNlbWFwaG9yZXM6 ClQgICAgICAgICAgIElEICAgICAgICAgIEtFWSBNT0RFICAgICAgICBPV05FUiAgICBHUk9VUCAg ICBDUkVBVE9SICBDR1JPVVAgICAgICAgICAgTlNFTVMgT1RJTUUgICAgQ1RJTUUgICAKCgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KaXBjcyAtVAoKbXNnaW5mbzoKCW1zZ21heDogICAgICAgIDE2Mzg0CShtYXgg Y2hhcmFjdGVycyBpbiBhIG1lc3NhZ2UpCgltc2dtbmk6ICAgICAgICAgICA0MAkoIyBvZiBtZXNz YWdlIHF1ZXVlcykKCW1zZ21uYjogICAgICAgICAyMDQ4CShtYXggY2hhcmFjdGVycyBpbiBhIG1l c3NhZ2UgcXVldWUpCgltc2d0cWw6ICAgICAgICAgICA0MAkobWF4ICMgb2YgbWVzc2FnZXMgaW4g c3lzdGVtKQoJbXNnc3N6OiAgICAgICAgICAgIDgJKHNpemUgb2YgYSBtZXNzYWdlIHNlZ21lbnQp Cgltc2dzZWc6ICAgICAgICAgMjA0OAkoIyBvZiBtZXNzYWdlIHNlZ21lbnRzIGluIHN5c3RlbSkK CnNobWluZm86CglzaG1tYXg6ICAgIDUzNjg3MDkxMgkobWF4IHNoYXJlZCBtZW1vcnkgc2VnbWVu dCBzaXplKQoJc2htbWluOiAgICAgICAgICAgIDEJKG1pbiBzaGFyZWQgbWVtb3J5IHNlZ21lbnQg c2l6ZSkKCXNobW1uaTogICAgICAgICAgMTkyCShtYXggbnVtYmVyIG9mIHNoYXJlZCBtZW1vcnkg aWRlbnRpZmllcnMpCglzaG1zZWc6ICAgICAgICAgIDEyOAkobWF4IHNoYXJlZCBtZW1vcnkgc2Vn bWVudHMgcGVyIHByb2Nlc3MpCglzaG1hbGw6ICAgICAgIDEzMTA3MgkobWF4IGFtb3VudCBvZiBz aGFyZWQgbWVtb3J5IGluIHBhZ2VzKQoKc2VtaW5mbzoKCXNlbW1uaTogICAgICAgICAgIDUwCSgj IG9mIHNlbWFwaG9yZSBpZGVudGlmaWVycykKCXNlbW1uczogICAgICAgICAgMzQwCSgjIG9mIHNl bWFwaG9yZXMgaW4gc3lzdGVtKQoJc2VtbW51OiAgICAgICAgICAxNTAJKCMgb2YgdW5kbyBzdHJ1 Y3R1cmVzIGluIHN5c3RlbSkKCXNlbW1zbDogICAgICAgICAgMzQwCShtYXggIyBvZiBzZW1hcGhv cmVzIHBlciBpZCkKCXNlbW9wbTogICAgICAgICAgMTAwCShtYXggIyBvZiBvcGVyYXRpb25zIHBl ciBzZW1vcCBjYWxsKQoJc2VtdW1lOiAgICAgICAgICAgNTAJKG1heCAjIG9mIHVuZG8gZW50cmll cyBwZXIgcHJvY2VzcykKCXNlbXVzejogICAgICAgICAgNjMyCShzaXplIGluIGJ5dGVzIG9mIHVu ZG8gc3RydWN0dXJlKQoJc2Vtdm14OiAgICAgICAgMzI3NjcJKHNlbWFwaG9yZSBtYXhpbXVtIHZh bHVlKQoJc2VtYWVtOiAgICAgICAgMTYzODQJKGFkanVzdCBvbiBleGl0IG1heCB2YWx1ZSkKCgot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KbmZzc3RhdAoKQ2xpZW50IEluZm86ClJwYyBDb3VudHM6CiAgR2V0YXR0 ciAgIFNldGF0dHIgICAgTG9va3VwICBSZWFkbGluayAgICAgIFJlYWQgICAgIFdyaXRlICAgIENy ZWF0ZSAgICBSZW1vdmUKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAogICBSZW5hbWUgICAgICBMaW5r ICAgU3ltbGluayAgICAgTWtkaXIgICAgIFJtZGlyICAgUmVhZGRpciAgUmRpclBsdXMgICAgQWNj ZXNzCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAKICAgIE1rbm9kICAgIEZzc3RhdCAgICBGc2luZm8g IFBhdGhDb25mICAgIENvbW1pdAogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAg IDAgICAgICAgICAwClJwYyBJbmZvOgogVGltZWRPdXQgICBJbnZhbGlkIFggUmVwbGllcyAgIFJl dHJpZXMgIFJlcXVlc3RzCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAKQ2FjaGUgSW5mbzoKQXR0ciBIaXRzICAgIE1pc3NlcyBMa3VwIEhpdHMgICAgTWlz c2VzIEJpb1IgSGl0cyAgICBNaXNzZXMgQmlvVyBIaXRzICAgIE1pc3NlcwogICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAg ICAgICAgICAwCkJpb1JMSGl0cyAgICBNaXNzZXMgQmlvRCBIaXRzICAgIE1pc3NlcyBEaXJFIEhp dHMgICAgTWlzc2VzIEFjY3MgSGl0cyAgICBNaXNzZXMKICAgICAgICAwICAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAoK U2VydmVyIEluZm86CiAgR2V0YXR0ciAgIFNldGF0dHIgICAgTG9va3VwICBSZWFkbGluayAgICAg IFJlYWQgICAgIFdyaXRlICAgIENyZWF0ZSAgICBSZW1vdmUKICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAg MAogICBSZW5hbWUgICAgICBMaW5rICAgU3ltbGluayAgICAgTWtkaXIgICAgIFJtZGlyICAgUmVh ZGRpciAgUmRpclBsdXMgICAgQWNjZXNzCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKICAgIE1rbm9k ICAgIEZzc3RhdCAgICBGc2luZm8gIFBhdGhDb25mICAgIENvbW1pdAogICAgICAgIDAgICAgICAg ICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwClNlcnZlciBSZXQtRmFpbGVkCiAgICAg ICAgICAgICAgICAwClNlcnZlciBGYXVsdHMKICAgICAgICAgICAgMApTZXJ2ZXIgQ2FjaGUgU3Rh dHM6CiAgIElucHJvZyAgICAgIElkZW0gIE5vbi1pZGVtICAgIE1pc3NlcwogICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAKU2VydmVyIFdyaXRlIEdhdGhlcmluZzoKIFdyaXRl T3BzICBXcml0ZVJQQyAgIE9wc2F2ZWQKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1zCgp0Y3A6Cgk5MyBwYWNrZXRzIHNlbnQKCQk1OSBkYXRh IHBhY2tldHMgKDYwODEgYnl0ZXMpCgkJMCBkYXRhIHBhY2tldHMgKDAgYnl0ZXMpIHJldHJhbnNt aXR0ZWQKCQkwIGRhdGEgcGFja2V0cyB1bm5lY2Vzc2FyaWx5IHJldHJhbnNtaXR0ZWQKCQkwIHJl c2VuZHMgaW5pdGlhdGVkIGJ5IE1UVSBkaXNjb3ZlcnkKCQkzMiBhY2stb25seSBwYWNrZXRzICgy MCBkZWxheWVkKQoJCTAgVVJHIG9ubHkgcGFja2V0cwoJCTAgd2luZG93IHByb2JlIHBhY2tldHMK CQkwIHdpbmRvdyB1cGRhdGUgcGFja2V0cwoJCTIgY29udHJvbCBwYWNrZXRzCgk5MSBwYWNrZXRz IHJlY2VpdmVkCgkJNjAgYWNrcyAoZm9yIDYwODIgYnl0ZXMpCgkJMSBkdXBsaWNhdGUgYWNrCgkJ MCBhY2tzIGZvciB1bnNlbnQgZGF0YQoJCTc0IHBhY2tldHMgKDY1MDMgYnl0ZXMpIHJlY2VpdmVk IGluLXNlcXVlbmNlCgkJMCBjb21wbGV0ZWx5IGR1cGxpY2F0ZSBwYWNrZXRzICgwIGJ5dGVzKQoJ CTAgb2xkIGR1cGxpY2F0ZSBwYWNrZXRzCgkJMCBwYWNrZXRzIHdpdGggc29tZSBkdXAuIGRhdGEg KDAgYnl0ZXMgZHVwZWQpCgkJMCBvdXQtb2Ytb3JkZXIgcGFja2V0cyAoMCBieXRlcykKCQkwIHBh Y2tldHMgKDAgYnl0ZXMpIG9mIGRhdGEgYWZ0ZXIgd2luZG93CgkJMCB3aW5kb3cgcHJvYmVzCgkJ MSB3aW5kb3cgdXBkYXRlIHBhY2tldAoJCTAgcGFja2V0cyByZWNlaXZlZCBhZnRlciBjbG9zZQoJ CTAgZGlzY2FyZGVkIGZvciBiYWQgY2hlY2tzdW1zCgkJMCBkaXNjYXJkZWQgZm9yIGJhZCBoZWFk ZXIgb2Zmc2V0IGZpZWxkcwoJCTAgZGlzY2FyZGVkIGJlY2F1c2UgcGFja2V0IHRvbyBzaG9ydAoJ CTAgZGlzY2FyZGVkIGR1ZSB0byBtZW1vcnkgcHJvYmxlbXMKCTEgY29ubmVjdGlvbiByZXF1ZXN0 CgkwIGNvbm5lY3Rpb24gYWNjZXB0cwoJMCBiYWQgY29ubmVjdGlvbiBhdHRlbXB0cwoJMCBsaXN0 ZW4gcXVldWUgb3ZlcmZsb3dzCgkwIGlnbm9yZWQgUlNUcyBpbiB0aGUgd2luZG93cwoJMSBjb25u ZWN0aW9uIGVzdGFibGlzaGVkIChpbmNsdWRpbmcgYWNjZXB0cykKCTMgY29ubmVjdGlvbnMgY2xv c2VkIChpbmNsdWRpbmcgMCBkcm9wcykKCQkxIGNvbm5lY3Rpb24gdXBkYXRlZCBjYWNoZWQgUlRU IG9uIGNsb3NlCgkJMSBjb25uZWN0aW9uIHVwZGF0ZWQgY2FjaGVkIFJUVCB2YXJpYW5jZSBvbiBj bG9zZQoJCTAgY29ubmVjdGlvbnMgdXBkYXRlZCBjYWNoZWQgc3N0aHJlc2ggb24gY2xvc2UKCTAg ZW1icnlvbmljIGNvbm5lY3Rpb25zIGRyb3BwZWQKCTYwIHNlZ21lbnRzIHVwZGF0ZWQgcnR0IChv ZiA1OSBhdHRlbXB0cykKCTAgcmV0cmFuc21pdCB0aW1lb3V0cwoJCTAgY29ubmVjdGlvbnMgZHJv cHBlZCBieSByZXhtaXQgdGltZW91dAoJMCBwZXJzaXN0IHRpbWVvdXRzCgkJMCBjb25uZWN0aW9u cyBkcm9wcGVkIGJ5IHBlcnNpc3QgdGltZW91dAoJMCBDb25uZWN0aW9ucyAoZmluX3dhaXRfMikg ZHJvcHBlZCBiZWNhdXNlIG9mIHRpbWVvdXQKCTAga2VlcGFsaXZlIHRpbWVvdXRzCgkJMCBrZWVw YWxpdmUgcHJvYmVzIHNlbnQKCQkwIGNvbm5lY3Rpb25zIGRyb3BwZWQgYnkga2VlcGFsaXZlCgky IGNvcnJlY3QgQUNLIGhlYWRlciBwcmVkaWN0aW9ucwoJMTcgY29ycmVjdCBkYXRhIHBhY2tldCBo ZWFkZXIgcHJlZGljdGlvbnMKCTAgc3luY2FjaGUgZW50cmllcyBhZGRlZAoJCTAgcmV0cmFuc21p dHRlZAoJCTAgZHVwc3luCgkJMCBkcm9wcGVkCgkJMCBjb21wbGV0ZWQKCQkwIGJ1Y2tldCBvdmVy ZmxvdwoJCTAgY2FjaGUgb3ZlcmZsb3cKCQkwIHJlc2V0CgkJMCBzdGFsZQoJCTAgYWJvcnRlZAoJ CTAgYmFkYWNrCgkJMCB1bnJlYWNoCgkJMCB6b25lIGZhaWx1cmVzCgkwIGNvb2tpZXMgc2VudAoJ MCBjb29raWVzIHJlY2VpdmVkCgkxIGhvc3RjYWNoZSBlbnRyaWUgYWRkZWQKCQkwIGJ1Y2tldCBv dmVyZmxvdwoJMCBTQUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkwIHNlZ21lbnQgcmV4bWl0cyBpbiBT QUNLIHJlY292ZXJ5IGVwaXNvZGVzCgkwIGJ5dGUgcmV4bWl0cyBpbiBTQUNLIHJlY292ZXJ5IGVw aXNvZGVzCgkwIFNBQ0sgb3B0aW9ucyAoU0FDSyBibG9ja3MpIHJlY2VpdmVkCgkwIFNBQ0sgb3B0 aW9ucyAoU0FDSyBibG9ja3MpIHNlbnQKCTAgU0FDSyBzY29yZWJvYXJkIG92ZXJmbG93CgkwIHBh Y2tldHMgd2l0aCBFQ04gQ0UgYml0IHNldAoJMCBwYWNrZXRzIHdpdGggRUNOIEVDVCgwKSBiaXQg c2V0CgkwIHBhY2tldHMgd2l0aCBFQ04gRUNUKDEpIGJpdCBzZXQKCTAgc3VjY2Vzc2Z1bCBFQ04g aGFuZHNoYWtlcwoJMCB0aW1lcyBFQ04gcmVkdWNlZCB0aGUgY29uZ2VzdGlvbiB3aW5kb3cKdWRw OgoJMjkgZGF0YWdyYW1zIHJlY2VpdmVkCgkwIHdpdGggaW5jb21wbGV0ZSBoZWFkZXIKCTAgd2l0 aCBiYWQgZGF0YSBsZW5ndGggZmllbGQKCTAgd2l0aCBiYWQgY2hlY2tzdW0KCTAgd2l0aCBubyBj aGVja3N1bQoJMCBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTAgYnJvYWRjYXN0L211bHRpY2Fz dCBkYXRhZ3JhbXMgdW5kZWxpdmVyZWQKCTAgZHJvcHBlZCBkdWUgdG8gZnVsbCBzb2NrZXQgYnVm ZmVycwoJMCBub3QgZm9yIGhhc2hlZCBwY2IKCTI5IGRlbGl2ZXJlZAoJMjkgZGF0YWdyYW1zIG91 dHB1dAoJMCB0aW1lcyBtdWx0aWNhc3Qgc291cmNlIGZpbHRlciBtYXRjaGVkCmlwOgoJMTMxIHRv dGFsIHBhY2tldHMgcmVjZWl2ZWQKCTAgYmFkIGhlYWRlciBjaGVja3N1bXMKCTAgd2l0aCBzaXpl IHNtYWxsZXIgdGhhbiBtaW5pbXVtCgkwIHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5ndGgKCTAg d2l0aCBpcCBsZW5ndGggPiBtYXggaXAgcGFja2V0IHNpemUKCTAgd2l0aCBoZWFkZXIgbGVuZ3Ro IDwgZGF0YSBzaXplCgkwIHdpdGggZGF0YSBsZW5ndGggPCBoZWFkZXIgbGVuZ3RoCgkwIHdpdGgg YmFkIG9wdGlvbnMKCTAgd2l0aCBpbmNvcnJlY3QgdmVyc2lvbiBudW1iZXIKCTAgZnJhZ21lbnRz IHJlY2VpdmVkCgkwIGZyYWdtZW50cyBkcm9wcGVkIChkdXAgb3Igb3V0IG9mIHNwYWNlKQoJMCBm cmFnbWVudHMgZHJvcHBlZCBhZnRlciB0aW1lb3V0CgkwIHBhY2tldHMgcmVhc3NlbWJsZWQgb2sK CTEyMCBwYWNrZXRzIGZvciB0aGlzIGhvc3QKCTQgcGFja2V0cyBmb3IgdW5rbm93bi91bnN1cHBv cnRlZCBwcm90b2NvbAoJMCBwYWNrZXRzIGZvcndhcmRlZCAoMCBwYWNrZXRzIGZhc3QgZm9yd2Fy ZGVkKQoJMCBwYWNrZXRzIG5vdCBmb3J3YXJkYWJsZQoJMCBwYWNrZXRzIHJlY2VpdmVkIGZvciB1 bmtub3duIG11bHRpY2FzdCBncm91cAoJMCByZWRpcmVjdHMgc2VudAoJMTI4IHBhY2tldHMgc2Vu dCBmcm9tIHRoaXMgaG9zdAoJMCBwYWNrZXRzIHNlbnQgd2l0aCBmYWJyaWNhdGVkIGlwIGhlYWRl cgoJMCBvdXRwdXQgcGFja2V0cyBkcm9wcGVkIGR1ZSB0byBubyBidWZzLCBldGMuCgkwIG91dHB1 dCBwYWNrZXRzIGRpc2NhcmRlZCBkdWUgdG8gbm8gcm91dGUKCTAgb3V0cHV0IGRhdGFncmFtcyBm cmFnbWVudGVkCgkwIGZyYWdtZW50cyBjcmVhdGVkCgkwIGRhdGFncmFtcyB0aGF0IGNhbid0IGJl IGZyYWdtZW50ZWQKCTAgdHVubmVsaW5nIHBhY2tldHMgdGhhdCBjYW4ndCBmaW5kIGdpZgoJMCBk YXRhZ3JhbXMgd2l0aCBiYWQgYWRkcmVzcyBpbiBoZWFkZXIKaWNtcDoKCTAgY2FsbHMgdG8gaWNt cF9lcnJvcgoJMCBlcnJvcnMgbm90IGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBhbiBpY21wIG1l c3NhZ2UKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY29kZSBmaWVsZHMKCTAgbWVzc2FnZXMgbGVzcyB0 aGFuIHRoZSBtaW5pbXVtIGxlbmd0aAoJMCBtZXNzYWdlcyB3aXRoIGJhZCBjaGVja3N1bQoJMCBt ZXNzYWdlcyB3aXRoIGJhZCBsZW5ndGgKCTAgbXVsdGljYXN0IGVjaG8gcmVxdWVzdHMgaWdub3Jl ZAoJMCBtdWx0aWNhc3QgdGltZXN0YW1wIHJlcXVlc3RzIGlnbm9yZWQKCTAgbWVzc2FnZSByZXNw b25zZXMgZ2VuZXJhdGVkCgkwIGludmFsaWQgcmV0dXJuIGFkZHJlc3NlcwoJMCBubyByZXR1cm4g cm91dGVzCmlnbXA6CgkwIG1lc3NhZ2VzIHJlY2VpdmVkCgkwIG1lc3NhZ2VzIHJlY2VpdmVkIHdp dGggdG9vIGZldyBieXRlcwoJMCBtZXNzYWdlcyByZWNlaXZlZCB3aXRoIHdyb25nIFRUTAoJMCBt ZXNzYWdlcyByZWNlaXZlZCB3aXRoIGJhZCBjaGVja3N1bQoJMCBWMS9WMiBtZW1iZXJzaGlwIHF1 ZXJpZXMgcmVjZWl2ZWQKCTAgVjMgbWVtYmVyc2hpcCBxdWVyaWVzIHJlY2VpdmVkCgkwIG1lbWJl cnNoaXAgcXVlcmllcyByZWNlaXZlZCB3aXRoIGludmFsaWQgZmllbGQocykKCTAgZ2VuZXJhbCBx dWVyaWVzIHJlY2VpdmVkCgkwIGdyb3VwIHF1ZXJpZXMgcmVjZWl2ZWQKCTAgZ3JvdXAtc291cmNl IHF1ZXJpZXMgcmVjZWl2ZWQKCTAgZ3JvdXAtc291cmNlIHF1ZXJpZXMgZHJvcHBlZAoJMCBtZW1i ZXJzaGlwIHJlcG9ydHMgcmVjZWl2ZWQKCTAgbWVtYmVyc2hpcCByZXBvcnRzIHJlY2VpdmVkIHdp dGggaW52YWxpZCBmaWVsZChzKQoJMCBtZW1iZXJzaGlwIHJlcG9ydHMgcmVjZWl2ZWQgZm9yIGdy b3VwcyB0byB3aGljaCB3ZSBiZWxvbmcKCTAgVjMgcmVwb3J0cyByZWNlaXZlZCB3aXRob3V0IFJv dXRlciBBbGVydAoJMCBtZW1iZXJzaGlwIHJlcG9ydHMgc2VudAppcHNlYzoKCTAgaW5ib3VuZCBw YWNrZXRzIHByb2Nlc3NlZCBzdWNjZXNzZnVsbHkKCTAgaW5ib3VuZCBwYWNrZXRzIHZpb2xhdGVk IHByb2Nlc3Mgc2VjdXJpdHkgcG9saWN5CgkwIGluYm91bmQgcGFja2V0cyB3aXRoIG5vIFNBIGF2 YWlsYWJsZQoJMCBpbnZhbGlkIGluYm91bmQgcGFja2V0cwoJMCBpbmJvdW5kIHBhY2tldHMgZmFp bGVkIGR1ZSB0byBpbnN1ZmZpY2llbnQgbWVtb3J5CgkwIGluYm91bmQgcGFja2V0cyBmYWlsZWQg Z2V0dGluZyBTUEkKCTAgaW5ib3VuZCBwYWNrZXRzIGZhaWxlZCBvbiBBSCByZXBsYXkgY2hlY2sK CTAgaW5ib3VuZCBwYWNrZXRzIGZhaWxlZCBvbiBFU1AgcmVwbGF5IGNoZWNrCgkwIGluYm91bmQg cGFja2V0cyBjb25zaWRlcmVkIGF1dGhlbnRpYwoJMCBpbmJvdW5kIHBhY2tldHMgZmFpbGVkIG9u IGF1dGhlbnRpY2F0aW9uCgkwIG91dGJvdW5kIHBhY2tldHMgcHJvY2Vzc2VkIHN1Y2Nlc3NmdWxs eQoJMCBvdXRib3VuZCBwYWNrZXRzIHZpb2xhdGVkIHByb2Nlc3Mgc2VjdXJpdHkgcG9saWN5Cgkw IG91dGJvdW5kIHBhY2tldHMgd2l0aCBubyBTQSBhdmFpbGFibGUKCTAgaW52YWxpZCBvdXRib3Vu ZCBwYWNrZXRzCgkwIG91dGJvdW5kIHBhY2tldHMgZmFpbGVkIGR1ZSB0byBpbnN1ZmZpY2llbnQg bWVtb3J5CgkwIG91dGJvdW5kIHBhY2tldHMgd2l0aCBubyByb3V0ZQoJMCBTUEQgY2FjaGUgbG9v a3VwcwoJMCBTUEQgY2FjaGUgbWlzc2VzCgkwIGluYm91bmQgcGFja2V0cyB2aW9sYXRlZCBwcm9j ZXNzIHNlY3VyaXR5IHBvbGljeQoJMCBvdXRib3VuZCBwYWNrZXRzIHZpb2xhdGVkIHByb2Nlc3Mg c2VjdXJpdHkgcG9saWN5CgkwIG91dGJvdW5kIHBhY2tldHMgd2l0aCBubyBTQSBhdmFpbGFibGUK CTAgb3V0Ym91bmQgcGFja2V0cyBmYWlsZWQgZHVlIHRvIGluc3VmZmljaWVudCBtZW1vcnkKCTAg b3V0Ym91bmQgcGFja2V0cyB3aXRoIG5vIHJvdXRlIGF2YWlsYWJsZQoJMCBpbnZhbGlkIG91dGJv dW5kIHBhY2tldHMKCTAgb3V0Ym91bmQgcGFja2V0cyB3aXRoIGJ1bmRsZWQgU0FzCgkwIG1idWZz IGNvYWxlc2NlZCBkdXJpbmcgY2xvbmUKCTAgY2x1c3RlcnMgY29hbGVzY2VkIGR1cmluZyBjbG9u ZQoJMCBjbHVzdGVycyBjb3BpZWQgZHVyaW5nIGNsb25lCgkxIG1idWYgaW5zZXJ0ZWQgZHVyaW5n IG1ha2VzcGFjZQphaDoKCTAgcGFja2V0cyBzaG9ydGVyIHRoYW4gaGVhZGVyIHNob3dzCgkwIHBh Y2tldHMgZHJvcHBlZDsgcHJvdG9jb2wgZmFtaWx5IG5vdCBzdXBwb3J0ZWQKCTAgcGFja2V0cyBk cm9wcGVkOyBubyBUREIKCTAgcGFja2V0cyBkcm9wcGVkOyBiYWQgS0NSCgkwIHBhY2tldHMgZHJv cHBlZDsgcXVldWUgZnVsbAoJMCBwYWNrZXRzIGRyb3BwZWQ7IG5vIHRyYW5zZm9ybQoJMCByZXBs YXkgY291bnRlciB3cmFwcwoJMCBwYWNrZXRzIGRyb3BwZWQ7IGJhZCBhdXRoZW50aWNhdGlvbiBk ZXRlY3RlZAoJMCBwYWNrZXRzIGRyb3BwZWQ7IGJhZCBhdXRoZW50aWNhdGlvbiBsZW5ndGgKCTAg cG9zc2libGUgcmVwbGF5IHBhY2tldHMgZGV0ZWN0ZWQKCTAgcGFja2V0cyBpbgoJMCBwYWNrZXRz IG91dAoJMCBwYWNrZXRzIGRyb3BwZWQ7IGludmFsaWQgVERCCgkwIGJ5dGVzIGluCgkwIGJ5dGVz IG91dAoJMCBwYWNrZXRzIGRyb3BwZWQ7IGxhcmdlciB0aGFuIElQX01BWFBBQ0tFVAoJMCBwYWNr ZXRzIGJsb2NrZWQgZHVlIHRvIHBvbGljeQoJMCBjcnlwdG8gcHJvY2Vzc2luZyBmYWlsdXJlcwoJ MCB0dW5uZWwgc2FuaXR5IGNoZWNrIGZhaWx1cmVzCmVzcDoKCTAgcGFja2V0cyBzaG9ydGVyIHRo YW4gaGVhZGVyIHNob3dzCgkwIHBhY2tldHMgZHJvcHBlZDsgcHJvdG9jb2wgZmFtaWx5IG5vdCBz dXBwb3J0ZWQKCTAgcGFja2V0cyBkcm9wcGVkOyBubyBUREIKCTAgcGFja2V0cyBkcm9wcGVkOyBi YWQgS0NSCgkwIHBhY2tldHMgZHJvcHBlZDsgcXVldWUgZnVsbAoJMCBwYWNrZXRzIGRyb3BwZWQ7 IG5vIHRyYW5zZm9ybQoJMCBwYWNrZXRzIGRyb3BwZWQ7IGJhZCBpbGVuCgkwIHJlcGxheSBjb3Vu dGVyIHdyYXBzCgkwIHBhY2tldHMgZHJvcHBlZDsgYmFkIGVuY3J5cHRpb24gZGV0ZWN0ZWQKCTAg cGFja2V0cyBkcm9wcGVkOyBiYWQgYXV0aGVudGljYXRpb24gZGV0ZWN0ZWQKCTAgcG9zc2libGUg cmVwbGF5IHBhY2tldHMgZGV0ZWN0ZWQKCTAgcGFja2V0cyBpbgoJMSBwYWNrZXQgb3V0CgkwIHBh Y2tldHMgZHJvcHBlZDsgaW52YWxpZCBUREIKCTAgYnl0ZXMgaW4KCTI0IGJ5dGVzIG91dAoJMCBw YWNrZXRzIGRyb3BwZWQ7IGxhcmdlciB0aGFuIElQX01BWFBBQ0tFVAoJMCBwYWNrZXRzIGJsb2Nr ZWQgZHVlIHRvIHBvbGljeQoJMCBjcnlwdG8gcHJvY2Vzc2luZyBmYWlsdXJlcwoJMCB0dW5uZWwg c2FuaXR5IGNoZWNrIGZhaWx1cmVzCmlwY29tcDoKCTAgcGFja2V0cyBzaG9ydGVyIHRoYW4gaGVh ZGVyIHNob3dzCgkwIHBhY2tldHMgZHJvcHBlZDsgcHJvdG9jb2wgZmFtaWx5IG5vdCBzdXBwb3J0 ZWQKCTAgcGFja2V0cyBkcm9wcGVkOyBubyBUREIKCTAgcGFja2V0cyBkcm9wcGVkOyBiYWQgS0NS CgkwIHBhY2tldHMgZHJvcHBlZDsgcXVldWUgZnVsbAoJMCBwYWNrZXRzIGRyb3BwZWQ7IG5vIHRy YW5zZm9ybQoJMCByZXBsYXkgY291bnRlciB3cmFwcwoJMCBwYWNrZXRzIGluCgkwIHBhY2tldHMg b3V0CgkwIHBhY2tldHMgZHJvcHBlZDsgaW52YWxpZCBUREIKCTAgYnl0ZXMgaW4KCTAgYnl0ZXMg b3V0CgkwIHBhY2tldHMgZHJvcHBlZDsgbGFyZ2VyIHRoYW4gSVBfTUFYUEFDS0VUCgkwIHBhY2tl dHMgYmxvY2tlZCBkdWUgdG8gcG9saWN5CgkwIGNyeXB0byBwcm9jZXNzaW5nIGZhaWx1cmVzCgkw IHBhY2tldHMgc2VudCB1bmNvbXByZXNzZWQ7IHNpemUgPCBjb21wci4gYWxnby4gdGhyZXNob2xk CgkwIHBhY2tldHMgc2VudCB1bmNvbXByZXNzZWQ7IGNvbXByZXNzaW9uIHdhcyB1c2VsZXNzCnBm c3luYzoKCTAgcGFja2V0cyByZWNlaXZlZCAoSVB2NCkKCTAgcGFja2V0cyByZWNlaXZlZCAoSVB2 NikKCQkwIHBhY2tldHMgZGlzY2FyZGVkIGZvciBiYWQgaW50ZXJmYWNlCgkJMCBwYWNrZXRzIGRp c2NhcmRlZCBmb3IgYmFkIHR0bAoJCTAgcGFja2V0cyBzaG9ydGVyIHRoYW4gaGVhZGVyCgkJMCBw YWNrZXRzIGRpc2NhcmRlZCBmb3IgYmFkIHZlcnNpb24KCQkwIHBhY2tldHMgZGlzY2FyZGVkIGZv ciBiYWQgSE1BQwoJCTAgcGFja2V0cyBkaXNjYXJkZWQgZm9yIGJhZCBhY3Rpb24KCQkwIHBhY2tl dHMgZGlzY2FyZGVkIGZvciBzaG9ydCBwYWNrZXQKCQkwIHN0YXRlcyBkaXNjYXJkZWQgZm9yIGJh ZCB2YWx1ZXMKCQkwIHN0YWxlIHN0YXRlcwoJCTAgZmFpbGVkIHN0YXRlIGxvb2t1cC9pbnNlcnRz CgkwIHBhY2tldHMgc2VudCAoSVB2NCkKCTAgcGFja2V0cyBzZW50IChJUHY2KQoJCTEwIHNlbmQg ZmFpbGVkIGR1ZSB0byBtYnVmIG1lbW9yeSBlcnJvcgoJCTAgc2VuZCBlcnJvcgphcnA6CgkzIEFS UCByZXF1ZXN0cyBzZW50CgkzIEFSUCByZXBsaWVzIHNlbnQKCTMgQVJQIHJlcXVlc3RzIHJlY2Vp dmVkCgkxIEFSUCByZXBseSByZWNlaXZlZAoJNCBBUlAgcGFja2V0cyByZWNlaXZlZAoJMCB0b3Rh bCBwYWNrZXRzIGRyb3BwZWQgZHVlIHRvIG5vIEFSUCBlbnRyeQoJMCBBUlAgZW50cnlzIHRpbWVk IG91dAoJMCBEdXBsaWNhdGUgSVBzIHNlZW4KaXA2OgoJMiB0b3RhbCBwYWNrZXRzIHJlY2VpdmVk CgkwIHdpdGggc2l6ZSBzbWFsbGVyIHRoYW4gbWluaW11bQoJMCB3aXRoIGRhdGEgc2l6ZSA8IGRh dGEgbGVuZ3RoCgkwIHdpdGggYmFkIG9wdGlvbnMKCTAgd2l0aCBpbmNvcnJlY3QgdmVyc2lvbiBu dW1iZXIKCTAgZnJhZ21lbnRzIHJlY2VpdmVkCgkwIGZyYWdtZW50cyBkcm9wcGVkIChkdXAgb3Ig b3V0IG9mIHNwYWNlKQoJMCBmcmFnbWVudHMgZHJvcHBlZCBhZnRlciB0aW1lb3V0CgkwIGZyYWdt ZW50cyB0aGF0IGV4Y2VlZGVkIGxpbWl0CgkwIHBhY2tldHMgcmVhc3NlbWJsZWQgb2sKCTIgcGFj a2V0cyBmb3IgdGhpcyBob3N0CgkwIHBhY2tldHMgZm9yd2FyZGVkCgkwIHBhY2tldHMgbm90IGZv cndhcmRhYmxlCgkwIHJlZGlyZWN0cyBzZW50CgkxMyBwYWNrZXRzIHNlbnQgZnJvbSB0aGlzIGhv c3QKCTAgcGFja2V0cyBzZW50IHdpdGggZmFicmljYXRlZCBpcCBoZWFkZXIKCTAgb3V0cHV0IHBh Y2tldHMgZHJvcHBlZCBkdWUgdG8gbm8gYnVmcywgZXRjLgoJMyBvdXRwdXQgcGFja2V0cyBkaXNj YXJkZWQgZHVlIHRvIG5vIHJvdXRlCgkwIG91dHB1dCBkYXRhZ3JhbXMgZnJhZ21lbnRlZAoJMCBm cmFnbWVudHMgY3JlYXRlZAoJMCBkYXRhZ3JhbXMgdGhhdCBjYW4ndCBiZSBmcmFnbWVudGVkCgkw IHBhY2tldHMgdGhhdCB2aW9sYXRlZCBzY29wZSBydWxlcwoJMCBtdWx0aWNhc3QgcGFja2V0cyB3 aGljaCB3ZSBkb24ndCBqb2luCglJbnB1dCBoaXN0b2dyYW06CgkJVURQOiAyCglNYnVmIHN0YXRp c3RpY3M6CgkJMCBvbmUgbWJ1ZgoJCTIgb25lIGV4dCBtYnVmCgkJMCB0d28gb3IgbW9yZSBleHQg bWJ1ZgoJMCBwYWNrZXRzIHdob3NlIGhlYWRlcnMgYXJlIG5vdCBjb250aWd1b3VzCgkwIHR1bm5l bGluZyBwYWNrZXRzIHRoYXQgY2FuJ3QgZmluZCBnaWYKCTAgcGFja2V0cyBkaXNjYXJkZWQgYmVj YXVzZSBvZiB0b28gbWFueSBoZWFkZXJzCgkwIGZhaWx1cmVzIG9mIHNvdXJjZSBhZGRyZXNzIHNl bGVjdGlvbgoJU291cmNlIGFkZHJlc3NlcyBzZWxlY3Rpb24gcnVsZSBhcHBsaWVkOgoJCTEgZmly c3QgY2FuZGlkYXRlCgkJMSBhcHByb3ByaWF0ZSBzY29wZQppY21wNjoKCTAgY2FsbHMgdG8gaWNt cDZfZXJyb3IKCTAgZXJyb3JzIG5vdCBnZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gYW4gaWNtcDYg bWVzc2FnZQoJMCBlcnJvcnMgbm90IGdlbmVyYXRlZCBiZWNhdXNlIG9mIHJhdGUgbGltaXRhdGlv bgoJT3V0cHV0IGhpc3RvZ3JhbToKCQluZWlnaGJvciBzb2xpY2l0YXRpb246IDQKCQlNTER2MiBs aXN0ZW5lciByZXBvcnQ6IDQKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY29kZSBmaWVsZHMKCTAgbWVz c2FnZXMgPCBtaW5pbXVtIGxlbmd0aAoJMCBiYWQgY2hlY2tzdW1zCgkwIG1lc3NhZ2VzIHdpdGgg YmFkIGxlbmd0aAoJSGlzdG9ncmFtIG9mIGVycm9yIG1lc3NhZ2VzIHRvIGJlIGdlbmVyYXRlZDoK CQkwIG5vIHJvdXRlCgkJMCBhZG1pbmlzdHJhdGl2ZWx5IHByb2hpYml0ZWQKCQkwIGJleW9uZCBz Y29wZQoJCTAgYWRkcmVzcyB1bnJlYWNoYWJsZQoJCTAgcG9ydCB1bnJlYWNoYWJsZQoJCTAgcGFj a2V0IHRvbyBiaWcKCQkwIHRpbWUgZXhjZWVkIHRyYW5zaXQKCQkwIHRpbWUgZXhjZWVkIHJlYXNz ZW1ibHkKCQkwIGVycm9uZW91cyBoZWFkZXIgZmllbGQKCQkwIHVucmVjb2duaXplZCBuZXh0IGhl YWRlcgoJCTAgdW5yZWNvZ25pemVkIG9wdGlvbgoJCTAgcmVkaXJlY3QKCQkwIHVua25vd24KCTAg bWVzc2FnZSByZXNwb25zZXMgZ2VuZXJhdGVkCgkwIG1lc3NhZ2VzIHdpdGggdG9vIG1hbnkgTkQg b3B0aW9ucwoJMCBtZXNzYWdlcyB3aXRoIGJhZCBORCBvcHRpb25zCgkwIGJhZCBuZWlnaGJvciBz b2xpY2l0YXRpb24gbWVzc2FnZXMKCTAgYmFkIG5laWdoYm9yIGFkdmVydGlzZW1lbnQgbWVzc2Fn ZXMKCTAgYmFkIHJvdXRlciBzb2xpY2l0YXRpb24gbWVzc2FnZXMKCTAgYmFkIHJvdXRlciBhZHZl cnRpc2VtZW50IG1lc3NhZ2VzCgkwIGJhZCByZWRpcmVjdCBtZXNzYWdlcwoJMCBwYXRoIE1UVSBj aGFuZ2VzCmlwc2VjNjoKCTAgaW5ib3VuZCBwYWNrZXRzIHByb2Nlc3NlZCBzdWNjZXNzZnVsbHkK CTAgaW5ib3VuZCBwYWNrZXRzIHZpb2xhdGVkIHByb2Nlc3Mgc2VjdXJpdHkgcG9saWN5CgkwIGlu Ym91bmQgcGFja2V0cyB3aXRoIG5vIFNBIGF2YWlsYWJsZQoJMCBpbnZhbGlkIGluYm91bmQgcGFj a2V0cwoJMCBpbmJvdW5kIHBhY2tldHMgZmFpbGVkIGR1ZSB0byBpbnN1ZmZpY2llbnQgbWVtb3J5 CgkwIGluYm91bmQgcGFja2V0cyBmYWlsZWQgZ2V0dGluZyBTUEkKCTAgaW5ib3VuZCBwYWNrZXRz IGZhaWxlZCBvbiBBSCByZXBsYXkgY2hlY2sKCTAgaW5ib3VuZCBwYWNrZXRzIGZhaWxlZCBvbiBF U1AgcmVwbGF5IGNoZWNrCgkwIGluYm91bmQgcGFja2V0cyBjb25zaWRlcmVkIGF1dGhlbnRpYwoJ MCBpbmJvdW5kIHBhY2tldHMgZmFpbGVkIG9uIGF1dGhlbnRpY2F0aW9uCgkwIG91dGJvdW5kIHBh Y2tldHMgcHJvY2Vzc2VkIHN1Y2Nlc3NmdWxseQoJMCBvdXRib3VuZCBwYWNrZXRzIHZpb2xhdGVk IHByb2Nlc3Mgc2VjdXJpdHkgcG9saWN5CgkwIG91dGJvdW5kIHBhY2tldHMgd2l0aCBubyBTQSBh dmFpbGFibGUKCTAgaW52YWxpZCBvdXRib3VuZCBwYWNrZXRzCgkwIG91dGJvdW5kIHBhY2tldHMg ZmFpbGVkIGR1ZSB0byBpbnN1ZmZpY2llbnQgbWVtb3J5CgkwIG91dGJvdW5kIHBhY2tldHMgd2l0 aCBubyByb3V0ZQoJMCBTUEQgY2FjaGUgbG9va3VwcwoJMCBTUEQgY2FjaGUgbWlzc2VzCgkwIGlu Ym91bmQgcGFja2V0cyB2aW9sYXRlZCBwcm9jZXNzIHNlY3VyaXR5IHBvbGljeQoJMCBvdXRib3Vu ZCBwYWNrZXRzIHZpb2xhdGVkIHByb2Nlc3Mgc2VjdXJpdHkgcG9saWN5CgkwIG91dGJvdW5kIHBh Y2tldHMgd2l0aCBubyBTQSBhdmFpbGFibGUKCTAgb3V0Ym91bmQgcGFja2V0cyBmYWlsZWQgZHVl IHRvIGluc3VmZmljaWVudCBtZW1vcnkKCTAgb3V0Ym91bmQgcGFja2V0cyB3aXRoIG5vIHJvdXRl IGF2YWlsYWJsZQoJMCBpbnZhbGlkIG91dGJvdW5kIHBhY2tldHMKCTAgb3V0Ym91bmQgcGFja2V0 cyB3aXRoIGJ1bmRsZWQgU0FzCgkwIG1idWZzIGNvYWxlc2NlZCBkdXJpbmcgY2xvbmUKCTAgY2x1 c3RlcnMgY29hbGVzY2VkIGR1cmluZyBjbG9uZQoJMCBjbHVzdGVycyBjb3BpZWQgZHVyaW5nIGNs b25lCgkwIG1idWZzIGluc2VydGVkIGR1cmluZyBtYWtlc3BhY2UKcmlwNjoKCTAgbWVzc2FnZXMg cmVjZWl2ZWQKCTAgY2hlY2tzdW0gY2FsY3VsYXRpb25zIG9uIGluYm91bmQKCTAgbWVzc2FnZXMg d2l0aCBiYWQgY2hlY2tzdW0KCTAgbWVzc2FnZXMgZHJvcHBlZCBkdWUgdG8gbm8gc29ja2V0Cgkw IG11bHRpY2FzdCBtZXNzYWdlcyBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTAgbWVzc2FnZXMg ZHJvcHBlZCBkdWUgdG8gZnVsbCBzb2NrZXQgYnVmZmVycwoJMCBkZWxpdmVyZWQKCTAgZGF0YWdy YW1zIG91dHB1dApwZmtleToKCTkgcmVxdWVzdHMgc2VudCBmcm9tIHVzZXJsYW5kCgkxMjMyIGJ5 dGVzIHNlbnQgZnJvbSB1c2VybGFuZAoJaGlzdG9ncmFtIGJ5IG1lc3NhZ2UgdHlwZToKCQlnZXRz cGk6IDEKCQl1cGRhdGU6IDEKCQlhZGQ6IDEKCQlyZWdpc3RlcjogMgoJCXhfc3BkdXBkYXRlOiAy CgkJeF9zcGRhZGQ6IDIKCTAgbWVzc2FnZXMgd2l0aCBpbnZhbGlkIGxlbmd0aCBmaWVsZAoJMCBt ZXNzYWdlcyB3aXRoIGludmFsaWQgdmVyc2lvbiBmaWVsZAoJMCBtZXNzYWdlcyB3aXRoIGludmFs aWQgbWVzc2FnZSB0eXBlIGZpZWxkCgkwIG1lc3NhZ2VzIHRvbyBzaG9ydAoJMCBtZXNzYWdlcyB3 aXRoIG1lbW9yeSBhbGxvY2F0aW9uIGZhaWx1cmUKCTAgbWVzc2FnZXMgd2l0aCBkdXBsaWNhdGUg ZXh0ZW5zaW9uCgkwIG1lc3NhZ2VzIHdpdGggaW52YWxpZCBleHRlbnNpb24gdHlwZQoJMCBtZXNz YWdlcyB3aXRoIGludmFsaWQgc2EgdHlwZQoJMCBtZXNzYWdlcyB3aXRoIGludmFsaWQgYWRkcmVz cyBleHRlbnNpb24KCTkgcmVxdWVzdHMgc2VudCB0byB1c2VybGFuZAoJMTQ0MCBieXRlcyBzZW50 IHRvIHVzZXJsYW5kCgloaXN0b2dyYW0gYnkgbWVzc2FnZSB0eXBlOgoJCWdldHNwaTogMQoJCXVw ZGF0ZTogMQoJCWFkZDogMQoJCXJlZ2lzdGVyOiAyCgkJeF9zcGR1cGRhdGU6IDIKCQl4X3NwZGFk ZDogMgoJMSBtZXNzYWdlIHRvd2FyZCBzaW5nbGUgc29ja2V0Cgk2IG1lc3NhZ2VzIHRvd2FyZCBh bGwgc29ja2V0cwoJMiBtZXNzYWdlcyB0b3dhcmQgcmVnaXN0ZXJlZCBzb2NrZXRzCgkwIG1lc3Nh Z2VzIHdpdGggbWVtb3J5IGFsbG9jYXRpb24gZmFpbHVyZQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5ldHN0 YXQgLW0KCjUyNy8xNjc3LzIyMDQgbWJ1ZnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsKQo0 OTgvOTI0LzE0MjIvMjU2MDAgbWJ1ZiBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUvdG90 YWwvbWF4KQo1MTIvNzgyIG1idWYrY2x1c3RlcnMgb3V0IG9mIHBhY2tldCBzZWNvbmRhcnkgem9u ZSBpbiB1c2UgKGN1cnJlbnQvY2FjaGUpCjAvNTQvNTQvMTI4MDAgNGsgKHBhZ2Ugc2l6ZSkganVt Ym8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAvMTkyMDAg OWsganVtYm8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMC8wLzAv MTI4MDAgMTZrIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgp CjExMjdLLzI0ODNLLzM2MTFLIGJ5dGVzIGFsbG9jYXRlZCB0byBuZXR3b3JrIChjdXJyZW50L2Nh Y2hlL3RvdGFsKQowLzAvMCByZXF1ZXN0cyBmb3IgbWJ1ZnMgZGVuaWVkIChtYnVmcy9jbHVzdGVy cy9tYnVmK2NsdXN0ZXJzKQowLzAvMCByZXF1ZXN0cyBmb3IganVtYm8gY2x1c3RlcnMgZGVuaWVk ICg0ay85ay8xNmspCjAgcmVxdWVzdHMgZm9yIHNmYnVmcyBkZW5pZWQKMCByZXF1ZXN0cyBmb3Ig c2ZidWZzIGRlbGF5ZWQKMCByZXF1ZXN0cyBmb3IgSS9PIGluaXRpYXRlZCBieSBzZW5kZmlsZQow IGNhbGxzIHRvIHByb3RvY29sIGRyYWluIHJvdXRpbmVzCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3Rh dCAtaWQKCk5hbWUgICAgTXR1IE5ldHdvcmsgICAgICAgQWRkcmVzcyAgICAgICAgICAgICAgSXBr dHMgSWVycnMgSWRyb3AgICAgT3BrdHMgT2VycnMgIENvbGwgRHJvcAp1c2J1cyAgICAgMCA8TGlu ayMxPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAwICAgICAgICAw ICAgICAwICAgICAwICAgIDAgCnVzYnVzICAgICAwIDxMaW5rIzI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAKcmUw ICAgIDE1MDAgPExpbmsjMz4gICAgICAwMDplMDo0Yzo3ODoyMzo0YyAgICAgIDEzNSAgICAgMCAg ICAgMCAgICAgIDEzNCAgICAgMCAgICAgMCAgICAwIApyZTAgICAgMTUwMCAxOTIuMTY4LjEuMCAg IHBvc2VpZG9uLmxhbiAgICAgICAgICAgMTI0ICAgICAtICAgICAtICAgICAgMTI4ICAgICAtICAg ICAtICAgIC0gCnVzYnVzICAgICAwIDxMaW5rIzQ+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAKcmUxICAgIDE1MDAg PExpbmsjNT4gICAgICA4Yzo4OTphNTo2Zjo1Mjo0ZiAgICAgICAgMCAgICAgMCAgICAgMCAgICAg ICAgMCAgICAgMCAgICAgMCAgICAwIApyZTEgICAgMTUwMCAxMC4zLjAuMCAgICAgIDEwLjMuMC4x ICAgICAgICAgICAgICAgICAwICAgICAtICAgICAtICAgICAgICAwICAgICAtICAgICAtICAgIC0g CnJlMSAgICAxNTAwIGZlODA6OjhlODk6YTUgZmU4MDo6OGU4OTphNWZmOmYgICAgICAgIDAgICAg IC0gICAgIC0gICAgICAgIDEgICAgIC0gICAgIC0gICAgLSAKdXNidXMgICAgIDAgPExpbmsjNj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAgMCAgICAgMCAgICAgICAgMCAgICAg MCAgICAgMCAgICAwIApwZmxvZyAzMzE1MiA8TGluayM3PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAwICAgICAwICAgICAwICAgICAgICAwICAgICAwICAgICAwICAgIDAgCnBmc3luICAx NTAwIDxMaW5rIzg+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgIDAgICAgIDAg ICAgICAgIDAgICAgMTAgICAgIDAgICAgMCAKbG8wICAgMTYzODQgPExpbmsjOT4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMCAgICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAg ICAwIApsbzAgICAxNjM4NCBwb3NlaWRvbiAgICAgIDo6MSAgICAgICAgICAgICAgICAgICAgICAw ICAgICAtICAgICAtICAgICAgICAwICAgICAtICAgICAtICAgIC0gCmxvMCAgIDE2Mzg0IGZlODA6 OjElbG8wICAgZmU4MDo6MSAgICAgICAgICAgICAgICAgIDAgICAgIC0gICAgIC0gICAgICAgIDAg ICAgIC0gICAgIC0gICAgLSAKbG8wICAgMTYzODQgeW91ci1uZXQgICAgICBwb3NlaWRvbiAgICAg ICAgICAgICAgICAgMCAgICAgLSAgICAgLSAgICAgICAgMCAgICAgLSAgICAgLSAgICAtIApnaWYw ICAgMTI4MCA8TGluayMxMD4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyICAgICAwICAg ICAwICAgICAgICA4ICAgICAwICAgICAwICAgIDAgCmdpZjAgICAxMjgwIGZkYWU6MWNlYTo2ODkg ZmRhZToxY2VhOjY4OTI6OTUgICAgICAgIDIgICAgIC0gICAgIC0gICAgICAgIDIgICAgIC0gICAg IC0gICAgLSAKZ2lmMCAgIDEyODAgZmU4MDo6MmUwOjRjZiBmZTgwOjoyZTA6NGNmZjpmZSAgICAg ICAgMCAgICAgLSAgICAgLSAgICAgICAgMiAgICAgLSAgICAgLSAgICAtIAoKLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCm5ldHN0YXQgLWFucgoKUm91dGluZyB0YWJsZXMKCkludGVybmV0OgpEZXN0aW5hdGlvbiAg ICAgICAgR2F0ZXdheSAgICAgICAgICAgIEZsYWdzICAgIFJlZnMgICAgICBVc2UgIE5ldGlmIEV4 cGlyZQpkZWZhdWx0ICAgICAgICAgICAgMTkyLjE2OC4xLjEgICAgICAgIFVHUyAgICAgICAgIDAg ICAgICAxMTkgICAgcmUwCjEwLjMuMC4wLzE2ICAgICAgICBsaW5rIzUgICAgICAgICAgICAgVSAg ICAgICAgICAgMCAgICAgICAgMCAgICByZTEKMTAuMy4wLjEgICAgICAgICAgIGxpbmsjNSAgICAg ICAgICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMAoxMjcuMC4wLjEgICAgICAgICAg bGluayM5ICAgICAgICAgICAgIFVIICAgICAgICAgIDAgICAgICAgIDAgICAgbG8wCjE5Mi4xNjgu MS4wLzI0ICAgICBsaW5rIzMgICAgICAgICAgICAgVSAgICAgICAgICAgMCAgICAgICAgOSAgICBy ZTAKMTkyLjE2OC4xLjEwMSAgICAgIGxpbmsjMyAgICAgICAgICAgICBVSFMgICAgICAgICAwICAg ICAgICAwICAgIGxvMAoKSW50ZXJuZXQ2OgpEZXN0aW5hdGlvbiAgICAgICAgICAgICAgICAgICAg ICAgR2F0ZXdheSAgICAgICAgICAgICAgICAgICAgICAgRmxhZ3MgICAgICBOZXRpZiBFeHBpcmUK OjovOTYgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDo6MSAgICAgICAgICAgICAgICAgICAg ICAgICAgIFVHUlMgICAgICAgIGxvMAo6OjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg OjoxICAgICAgICAgICAgICAgICAgICAgICAgICAgVUggICAgICAgICAgbG8wCjo6ZmZmZjowLjAu MC4wLzk2ICAgICAgICAgICAgICAgICA6OjEgICAgICAgICAgICAgICAgICAgICAgICAgICBVR1JT ICAgICAgICBsbzAKZmRhZToxY2VhOjY4OTI6OTVhMzo6LzY0ICAgICAgICAgIGxpbmsjMTAgICAg ICAgICAgICAgICAgICAgICAgIFUgICAgICAgICAgZ2lmMApmZGFlOjFjZWE6Njg5Mjo5NWEzOjox ICAgICAgICAgICAgbGluayMxMCAgICAgICAgICAgICAgICAgICAgICAgVUhTICAgICAgICAgbG8w CmZlODA6Oi8xMCAgICAgICAgICAgICAgICAgICAgICAgICA6OjEgICAgICAgICAgICAgICAgICAg ICAgICAgICBVR1JTICAgICAgICBsbzAKZmU4MDo6JXJlMS82NCAgICAgICAgICAgICAgICAgICAg IGxpbmsjNSAgICAgICAgICAgICAgICAgICAgICAgIFUgICAgICAgICAgIHJlMQpmZTgwOjo4ZTg5 OmE1ZmY6ZmU2Zjo1MjRmJXJlMSAgICAgbGluayM1ICAgICAgICAgICAgICAgICAgICAgICAgVUhT ICAgICAgICAgbG8wCmZlODA6OiVsbzAvNjQgICAgICAgICAgICAgICAgICAgICBsaW5rIzkgICAg ICAgICAgICAgICAgICAgICAgICBVICAgICAgICAgICBsbzAKZmU4MDo6MSVsbzAgICAgICAgICAg ICAgICAgICAgICAgIGxpbmsjOSAgICAgICAgICAgICAgICAgICAgICAgIFVIUyAgICAgICAgIGxv MApmZTgwOjolMTAvNjQgICAgICAgICAgICAgICAgICAgICAgbGluayMxMCAgICAgICAgICAgICAg ICAgICAgICAgVSAgICAgICAgICBnaWYwCmZlODA6OjJlMDo0Y2ZmOmZlNzg6MjM0YyUxMCAgICAg ICBsaW5rIzEwICAgICAgICAgICAgICAgICAgICAgICBVSFMgICAgICAgICBsbzAKZmYwMTo6JXJl MS8zMiAgICAgICAgICAgICAgICAgICAgIGZlODA6OjhlODk6YTVmZjpmZTZmOjUyNGYlcmUxIFUg ICAgICAgICAgIHJlMQpmZjAxOjolbG8wLzMyICAgICAgICAgICAgICAgICAgICAgOjoxICAgICAg ICAgICAgICAgICAgICAgICAgICAgVSAgICAgICAgICAgbG8wCmZmMDE6OiUxMC8zMiAgICAgICAg ICAgICAgICAgICAgICBmZGFlOjFjZWE6Njg5Mjo5NWEzOjoxICAgICAgICBVICAgICAgICAgIGdp ZjAKZmYwMjo6LzE2ICAgICAgICAgICAgICAgICAgICAgICAgIDo6MSAgICAgICAgICAgICAgICAg ICAgICAgICAgIFVHUlMgICAgICAgIGxvMApmZjAyOjolcmUxLzMyICAgICAgICAgICAgICAgICAg ICAgZmU4MDo6OGU4OTphNWZmOmZlNmY6NTI0ZiVyZTEgVSAgICAgICAgICAgcmUxCmZmMDI6OiVs bzAvMzIgICAgICAgICAgICAgICAgICAgICA6OjEgICAgICAgICAgICAgICAgICAgICAgICAgICBV ICAgICAgICAgICBsbzAKZmYwMjo6JTEwLzMyICAgICAgICAgICAgICAgICAgICAgIGZkYWU6MWNl YTo2ODkyOjk1YTM6OjEgICAgICAgIFUgICAgICAgICAgZ2lmMAoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5l dHN0YXQgLWFuQQoKQWN0aXZlIEludGVybmV0IGNvbm5lY3Rpb25zIChpbmNsdWRpbmcgc2VydmVy cykKVGNwY2IgICAgICAgICAgICBQcm90byBSZWN2LVEgU2VuZC1RIExvY2FsIEFkZHJlc3MgICAg ICBGb3JlaWduIEFkZHJlc3MgICAgKHN0YXRlKQpmZmZmZmUwMDI3OTBlMDAwIHRjcDQgICAgICAg MCAgICAgIDAgMTkyLjE2OC4xLjEwMS42NDc1IDIwOS4xNjAuNzQuMTU0LjM3OSBUSU1FX1dBSVQK ZmZmZmZlMDAwOWIzMzdhMCB0Y3A0ICAgICAgIDAgICAgICAwICouMjIgICAgICAgICAgICAgICAq LiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZTAwMDlmMWEzZDAgdGNwNCAgICAgICAwICAg ICAgMCAxMjcuMC4wLjEuNjMxICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmUw MDA5ZjFhN2EwIHRjcDYgICAgICAgMCAgICAgIDAgOjoxLjYzMSAgICAgICAgICAgICouKiAgICAg ICAgICAgICAgICBMSVNURU4KZmZmZmZlMDAwOTU4N2M0MCB1ZHA2ICAgICAgIDAgICAgICAwICou NDUwMCAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMDk1ODc5MzAgdWRw NiAgICAgICAwICAgICAgMCAqLjUwMCAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIApm ZmZmZmUwMDA5NTg3N2E4IHVkcDQgICAgICAgMCAgICAgIDAgKi40NTAwICAgICAgICAgICAgICou KiAgICAgICAgICAgICAgICAKZmZmZmZlMDAwOTU4NzYyMCB1ZHA0ICAgICAgIDAgICAgICAwICou NTAwICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMjc2NmYxODggdWRw NiAgICAgICAwICAgICAgMCBmZGFlOjFjZWE6Njg5Mjo5LjEgKi4qICAgICAgICAgICAgICAgIApm ZmZmZmUwMDA5NTg3MTg4IHVkcDQgICAgICAgMCAgICAgIDAgKi42MzEgICAgICAgICAgICAgICou KiAgICAgICAgICAgICAgICAKZmZmZmZlMDAwOTYzMjMxMCB1ZHA0ICAgICAgIDAgICAgICAwICou NjcgICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMDk2MzIwMDAgdWRw NiAgICAgICAwICAgICAgMCAqLjI2MTMxICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIApm ZmZmZmUwMDA5NTZjYWI4IHVkcDQgICAgICAgMCAgICAgIDAgKi4xNjgxNCAgICAgICAgICAgICou KiAgICAgICAgICAgICAgICAKZmZmZmZlMDAwOTYzMjYyMCB1ZHA0ICAgICAgIDAgICAgICAwIDEy Ny4wLjAuMS4xMjMgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMDk2MzI3YTggdWRw NiAgICAgICAwICAgICAgMCBmZTgwOjk6OjEuMTIzICAgICAgKi4qICAgICAgICAgICAgICAgIApm ZmZmZmUwMDA5NjMyMTg4IHVkcDYgICAgICAgMCAgICAgIDAgOjoxLjEyMyAgICAgICAgICAgICou KiAgICAgICAgICAgICAgICAKZmZmZmZlMDAwOTU2Y2RjOCB1ZHA2ICAgICAgIDAgICAgICAwIGZl ODA6NTo6OGU4OTphNWYuMSAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMDk1NmNjNDAgdWRw NCAgICAgICAwICAgICAgMCAxMC4zLjAuMS4xMjMgICAgICAgKi4qICAgICAgICAgICAgICAgIApm ZmZmZmUwMDA5NTZjOTMwIHVkcDQgICAgICAgMCAgICAgIDAgMTkyLjE2OC4xLjEwMS4xMjMgICou KiAgICAgICAgICAgICAgICAKZmZmZmZlMDAwOTU2YzdhOCB1ZHA2ICAgICAgIDAgICAgICAwICou MTIzICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMDk1NmM2MjAgdWRw NCAgICAgICAwICAgICAgMCAqLjEyMyAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIApm ZmZmZmUwMDA5YmY1MzEwIGljbTQgICAgICAgMCAgICAgIDAgKi4qICAgICAgICAgICAgICAgICou KiAgICAgICAgICAgICAgICAKQWN0aXZlIFVOSVggZG9tYWluIHNvY2tldHMKQWRkcmVzcyAgVHlw ZSAgIFJlY3YtUSBTZW5kLVEgICAgSW5vZGUgICAgIENvbm4gICAgIFJlZnMgIE5leHRyZWYgQWRk cgpmZmZmZmUwMDI3MjE4MWUwIHN0cmVhbSAgICAgIDAgICAgICAwIGZmZmZmZTAwMjc5ZDI3ODAg ICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vY2hhcm9uLmN0bApmZmZmZmUwMDA5 NjIwM2MwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMjcyMTgzYzAgICAg ICAgIDAgICAgICAgIDAgL3Zhci9ydW4vaGFsZC9kYnVzLW9HRUhEc3Y2dk4KZmZmZmZlMDAyNzIx ODNjMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA5NjIwM2MwICAgICAg ICAwICAgICAgICAwCmZmZmZmZTAwMjcyMTg0YjAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAg IDAgZmZmZmZlMDAyNzIxODVhMCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9oYWxkL2RidXMt b0dFSERzdjZ2TgpmZmZmZmUwMDI3MjE4NWEwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAw IGZmZmZmZTAwMjcyMTg0YjAgICAgICAgIDAgICAgICAgIDAKZmZmZmZlMDAyNzIxODY5MCBzdHJl YW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDI3MjE4NzgwICAgICAgICAwICAgICAg ICAwIC90bXAvLlgxMS11bml4L1gwCmZmZmZmZTAwMjcyMTg3ODAgc3RyZWFtICAgICAgMCAgICAg IDAgICAgICAgIDAgZmZmZmZlMDAyNzIxODY5MCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDA5 NjIwNzgwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMDk2MjA2OTAgICAg ICAgIDAgICAgICAgIDAgL3Zhci9ydW4vZGJ1cy9zeXN0ZW1fYnVzX3NvY2tldApmZmZmZmUwMDI3 MjE4YTUwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMjcyMThiNDAgICAg ICAgIDAgICAgICAgIDAgL3RtcC8uWDExLXVuaXgvWDAKZmZmZmZlMDAwOTYyMDY5MCBzdHJlYW0g ICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA5NjIwNzgwICAgICAgICAwICAgICAgICAw CmZmZmZmZTAwMjcyMThiNDAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAy NzIxOGE1MCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDA5NWVmOTYwIHN0cmVhbSAgICAgIDAg ICAgICAwICAgICAgICAwIGZmZmZmZTAwMDk2MjAwZjAgICAgICAgIDAgICAgICAgIDAgL3Zhci9y dW4vZGV2ZC5waXBlCmZmZmZmZTAwMDk2MjAwZjAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAg IDAgZmZmZmZlMDAwOTVlZjk2MCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDI3MjE4ZTEwIHN0 cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMjcyMTkwMDAgICAgICAgIDAgICAg ICAgIDAgL3Zhci9ydW4vaGFsZC9kYnVzLUFSTktaWUl0a0gKZmZmZmZlMDAyNzIxOTAwMCBzdHJl YW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDI3MjE4ZTEwICAgICAgICAwICAgICAg ICAwCmZmZmZmZTAwMjcxZmRiNDAgc3RyZWFtICAgICAgMCAgICAgIDAgZmZmZmZlMDAyNzFmNGQy MCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9oYWxkL2RidXMtQVJOS1pZSXRr SApmZmZmZmUwMDI3MjE5MWUwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAw MjcyMTkyZDAgICAgICAgIDAgICAgICAgIDAgL3RtcC9mYW0tcm9vdC9mYW0tCmZmZmZmZTAwMjcy MTkyZDAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAyNzIxOTFlMCAgICAg ICAgMCAgICAgICAgMApmZmZmZmUwMDA5NWVmMGYwIHN0cmVhbSAgICAgIDAgICAgICAwIGZmZmZm ZTAwMDljZmZkMjAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3RtcC9mYW0tcm9vdC9mYW0t CmZmZmZmZTAwMDk1ZWYzYzAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAw OTVlZjc4MCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9kYnVzL3N5c3RlbV9idXNfc29ja2V0 CmZmZmZmZTAwMDk1ZWY3ODAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAw OTVlZjNjMCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDA5NjIwMDAwIHN0cmVhbSAgICAgIDAg ICAgICAwICAgICAgICAwIGZmZmZmZTAwMDk1ZWZlMTAgICAgICAgIDAgICAgICAgIDAgL3Zhci9y dW4vZGJ1cy9zeXN0ZW1fYnVzX3NvY2tldApmZmZmZmUwMDA5NWVmZTEwIHN0cmVhbSAgICAgIDAg ICAgICAwICAgICAgICAwIGZmZmZmZTAwMDk2MjAwMDAgICAgICAgIDAgICAgICAgIDAKZmZmZmZl MDAwOTVlZmQyMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA5NWVmYzMw ICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2RidXMvc3lzdGVtX2J1c19zb2NrZXQKZmZmZmZl MDAwOTVlZmMzMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA5NWVmZDIw ICAgICAgICAwICAgICAgICAwCmZmZmZmZTAwMjcxMTA2OTAgc3RyZWFtICAgICAgMCAgICAgIDAg ICAgICAgIDAgZmZmZmZlMDAyNzExMDc4MCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9kYnVz L3N5c3RlbV9idXNfc29ja2V0CmZmZmZmZTAwMjcxMTA3ODAgc3RyZWFtICAgICAgMCAgICAgIDAg ICAgICAgIDAgZmZmZmZlMDAyNzExMDY5MCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDI3MTEw ODcwIHN0cmVhbSAgICAgIDAgICAgICAwIGZmZmZmZTAwMDkwOGEwMDAgICAgICAgIDAgICAgICAg IDAgICAgICAgIDAgL3Zhci9ydW4vaGFsZC9kYnVzLW9HRUhEc3Y2dk4KZmZmZmZlMDAwOTYyMDFl MCBzdHJlYW0gICAgICAwICAgICAgMCBmZmZmZmUwMDA5ZjBlMWUwICAgICAgICAwICAgICAgICAw ICAgICAgICAwIC92YXIvcnVuL2N1cHMuc29jawpmZmZmZmUwMDA5YTczM2MwIHN0cmVhbSAgICAg IDAgICAgICAwIGZmZmZmZTAwMDlkNjU1YTAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Rt cC8uWDExLXVuaXgvWDAKZmZmZmZlMDAwOTVlZjY5MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAg ICAgMCBmZmZmZmUwMDA5NWVmNWEwICAgICAgICAwICAgICAgICAwCmZmZmZmZTAwMDk1ZWY1YTAg c3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAwOTVlZjY5MCAgICAgICAgMCAg ICAgICAgMApmZmZmZmUwMDA5NjIwMmQwIHN0cmVhbSAgICAgIDAgICAgICAwIGZmZmZmZTAwMDlk MzRkMjAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vZGJ1cy9zeXN0ZW1fYnVz X3NvY2tldApmZmZmZmUwMDA5NWVmYTUwIHN0cmVhbSAgICAgIDAgICAgICAwIGZmZmZmZTAwMDk1 ZDEzYzAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vZGV2ZC5waXBlCmZmZmZm ZTAwMjcyMTkwZjAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAwOTVlZjJk MCAgICAgICAgMCBmZmZmZmUwMDI3NjIzMGYwCmZmZmZmZTAwMjc2MjMwZjAgZGdyYW0gICAgICAg MCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAwOTVlZjJkMCAgICAgICAgMCBmZmZmZmUwMDI3NjIy YzMwCmZmZmZmZTAwMjc2MjJjMzAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZl MDAwOTVlZjJkMCAgICAgICAgMCBmZmZmZmUwMDA5NWVmNGIwCmZmZmZmZTAwMDk1ZWY4NzAgZGdy YW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAwOTVlZjFlMCAgICAgICAgMCAgICAg ICAgMApmZmZmZmUwMDA5NWVmNGIwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZm ZTAwMDk1ZWYyZDAgICAgICAgIDAgZmZmZmZlMDAwOTYyMDRiMApmZmZmZmUwMDA5NjIwNGIwIGRn cmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMDk1ZWYyZDAgICAgICAgIDAgICAg ICAgIDAKZmZmZmZlMDAwOTVlZjJkMCBkZ3JhbSAgICAgICAwICAgICAgMCBmZmZmZmUwMDA5YTkw NzgwICAgICAgICAwIGZmZmZmZTAwMjcyMTkwZjAgICAgICAgIDAgL3Zhci9ydW4vbG9ncHJpdgpm ZmZmZmUwMDA5NWVmMWUwIGRncmFtICAgICAgIDAgICAgICAwIGZmZmZmZTAwMDlhOTA5NjAgICAg ICAgIDAgZmZmZmZlMDAwOTVlZjg3MCAgICAgICAgMCAvdmFyL3J1bi9sb2cKZmZmZmZlMDAyNzIx ODk2MCBzZXFwYWMgICAgICAwICAgICAgMCBmZmZmZmUwMDI3YTAyYjQwICAgICAgICAwICAgICAg ICAwICAgICAgICAwIC92YXIvcnVuL2NoYXJvbi53bHN0CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3Rh dCAtYUwKCkN1cnJlbnQgbGlzdGVuIHF1ZXVlIHNpemVzIChxbGVuL2luY3FsZW4vbWF4cWxlbikK UHJvdG8gTGlzdGVuICAgICAgICAgTG9jYWwgQWRkcmVzcyAgICAgICAgIAp0Y3A0ICAwLzAvMTI4 ICAgICAgICAqLnNzaCAgICAgICAgICAgICAgICAgIAp0Y3A0ICAwLzAvMTI4ICAgICAgICBwb3Nl aWRvbi5pcHAgICAgICAgICAgIAp0Y3A2ICAwLzAvMTI4ICAgICAgICBwb3NlaWRvbi5pcHAgICAg ICAgICAgIAp1bml4ICAwLzAvMTAgICAgICAgICAvdmFyL3J1bi9jaGFyb24uY3RsCnVuaXggIDAv MC8zMCAgICAgICAgIC92YXIvcnVuL2hhbGQvZGJ1cy1BUk5LWllJdGtICnVuaXggIDAvMC8zMCAg ICAgICAgIC90bXAvZmFtLXJvb3QvZmFtLQp1bml4ICAwLzAvMzAgICAgICAgICAvdmFyL3J1bi9o YWxkL2RidXMtb0dFSERzdjZ2Tgp1bml4ICAwLzAvMTI4ICAgICAgICAvdmFyL3J1bi9jdXBzLnNv Y2sKdW5peCAgMC8wLzEyOCAgICAgICAgL3RtcC8uWDExLXVuaXgvWDAKdW5peCAgMC8wLzMwICAg ICAgICAgL3Zhci9ydW4vZGJ1cy9zeXN0ZW1fYnVzX3NvY2tldAp1bml4ICAwLzAvNCAgICAgICAg ICAvdmFyL3J1bi9kZXZkLnBpcGUKdW5peCAgMC8wLzEwICAgICAgICAgL3Zhci9ydW4vY2hhcm9u Lndsc3QKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpmc3RhdAoKVVNFUiAgICAgQ01EICAgICAgICAgIFBJRCAg IEZEIE1PVU5UICAgICAgSU5VTSBNT0RFICAgICAgICAgU1p8RFYgUi9XCnJvb3QgICAgIGNoYXJv biAgICAgIDIxMDUgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1 ODAxMjk0MDEgIHIKcm9vdCAgICAgY2hhcm9uICAgICAgMjEwNSAgIHdkIC8gICAgICAgICAgIDE4 NyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBjaGFyb24gICAg ICAyMTA1IHRleHQgL3VzciAgICAgMjIyMjUyID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5 NDAxICByCnJvb3QgICAgIGNoYXJvbiAgICAgIDIxMDUgICAgMCAvZGV2ICAgICAgICAgIDcgY3J3 LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGNoYXJvbiAgICAgIDIxMDUgICAgMSAvZGV2ICAg ICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGNoYXJvbiAgICAgIDIxMDUg ICAgMiAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGNoYXJv biAgICAgIDIxMDUgICAgMyAvdmFyL2xvZyAgICAgNTQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1 ODAxMjk0MDEgIHcKcm9vdCAgICAgY2hhcm9uICAgICAgMjEwNSAgICA0IC9kZXYgICAgICAgICA3 MCBjcnctcnctcnctICBjcnlwdG8gcncKcm9vdCAgICAgY2hhcm9uICAgICAgMjEwNSAgICA1KiBr ZXkgcmF3IDIgZmZmZmZlMDAyNzM1ZmFhMApyb290ICAgICBjaGFyb24gICAgICAyMTA1ICAgIDYq IGtleSByYXcgMiBmZmZmZmUwMDI3MzVmNTUwCnJvb3QgICAgIGNoYXJvbiAgICAgIDIxMDUgICAg Nyogcm91dGUgcmF3IDAgZmZmZmZlMDAyNzI2ZmFhMApyb290ICAgICBjaGFyb24gICAgICAyMTA1 ICAgIDgqIHJvdXRlIHJhdyAwIGZmZmZmZTAwMjcyNmRhYTAKcm9vdCAgICAgY2hhcm9uICAgICAg MjEwNSAgICA5KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAwOTU4NzYyMApyb290ICAgICBj aGFyb24gICAgICAyMTA1ICAgMTAqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmUwMDA5NTg3N2E4 CnJvb3QgICAgIGNoYXJvbiAgICAgIDIxMDUgICAxMSogaW50ZXJuZXQ2IGRncmFtIHVkcCBmZmZm ZmUwMDA5NTg3OTMwCnJvb3QgICAgIGNoYXJvbiAgICAgIDIxMDUgICAxMiogaW50ZXJuZXQ2IGRn cmFtIHVkcCBmZmZmZmUwMDA5NTg3YzQwCnJvb3QgICAgIGNoYXJvbiAgICAgIDIxMDUgICAxMyog bG9jYWwgc3RyZWFtIGZmZmZmZTAwMjcyMTgxZTAKcm9vdCAgICAgY2hhcm9uICAgICAgMjEwNSAg IDE0KiBsb2NhbCBzZXFwYWsgZmZmZmZlMDAyNzIxODk2MApyb290ICAgICBjaGFyb24gICAgICAy MTA1ICAgMTUgL2RldiAgICAgICAgIDExIGNydy1ydy1ydy0gIHJhbmRvbSAgcgpyb290ICAgICBj aGFyb24gICAgICAyMTA1ICAgMTYgL2RldiAgICAgICAgIDExIGNydy1ydy1ydy0gIHJhbmRvbSAg cgpyb290ICAgICBjaGFyb24gICAgICAyMTA1ICAgMTcgL3Zhci9ydW4gICAgIDU3ID8tLS0tLS0t LS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICB3CnJvb3QgICAgIHN0YXJ0ZXIgICAgIDIxMDQgcm9v dCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9v dCAgICAgc3RhcnRlciAgICAgMjEwNCAgIHdkIC8gICAgICAgICAgIDE4NyA/LS0tLS0tLS0tICAx ODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBzdGFydGVyICAgICAyMTA0IHRleHQgL3Vz ciAgICAgMjIyMjQ2ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAg IHN0YXJ0ZXIgICAgIDIxMDQgICAgMCAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxs IHJ3CnJvb3QgICAgIHN0YXJ0ZXIgICAgIDIxMDQgICAgMSAvZGV2ICAgICAgICAgIDcgY3J3LXJ3 LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHN0YXJ0ZXIgICAgIDIxMDQgICAgMiAvZGV2ICAgICAg ICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHN0YXJ0ZXIgICAgIDIxMDQgICAg MyogbG9jYWwgZGdyYW0gZmZmZmZlMDAyNzIxOTBmMCA8LT4gZmZmZmZlMDAwOTVlZjJkMApyb290 ICAgICBjc2ggICAgICAgICAyMDgxIHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4 NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGNzaCAgICAgICAgIDIwODEgICB3ZCAvICAg ICAgICAgICAxODcgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAg Y3NoICAgICAgICAgMjA4MSB0ZXh0IC8gICAgICAgICAgOTU2OCA/LS0tLS0tLS0tICAxODQ0Njc0 NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBjc2ggICAgICAgICAyMDgxIGN0dHkgL2RldiAgICAg ICAgIDQ5IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBjc2ggICAgICAgICAyMDgxICAg MTUgL2RldiAgICAgICAgIDQ5IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBjc2ggICAg ICAgICAyMDgxICAgMTYgL2RldiAgICAgICAgIDQ5IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290 ICAgICBjc2ggICAgICAgICAyMDgxICAgMTcgL2RldiAgICAgICAgIDQ5IGNydy0tLS0tLS0gICB0 dHl2MSBydwpyb290ICAgICBjc2ggICAgICAgICAyMDgxICAgMTggL2RldiAgICAgICAgIDQ5IGNy dy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBjc2ggICAgICAgICAyMDgxICAgMTkgL2RldiAg ICAgICAgIDQ5IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBzdSAgICAgICAgICAyMDgw IHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICBy CnJvb3QgICAgIHN1ICAgICAgICAgIDIwODAgICB3ZCAvdXNyL2hvbWUgICAgIDE3ID8tLS0tLS0t LS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIHN1ICAgICAgICAgIDIwODAgdGV4 dCAvdXNyICAgICAgMTkwNzEgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9v dCAgICAgc3UgICAgICAgICAgMjA4MCBjdHR5IC9kZXYgICAgICAgICA0OSBjcnctLS0tLS0tICAg dHR5djEgcncKcm9vdCAgICAgc3UgICAgICAgICAgMjA4MCAgICAwIC9kZXYgICAgICAgICA0OSBj cnctLS0tLS0tICAgdHR5djEgcncKcm9vdCAgICAgc3UgICAgICAgICAgMjA4MCAgICAxIC9kZXYg ICAgICAgICA0OSBjcnctLS0tLS0tICAgdHR5djEgcncKcm9vdCAgICAgc3UgICAgICAgICAgMjA4 MCAgICAyIC9kZXYgICAgICAgICA0OSBjcnctLS0tLS0tICAgdHR5djEgcncKYWxleCAgICAgYmFz aCAgICAgICAgMjA3MCByb290IC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3 MTU4MDEyOTQwMSAgcgphbGV4ICAgICBiYXNoICAgICAgICAyMDcwICAgd2QgL3Vzci9ob21lICAg ICAxNyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgphbGV4ICAgICBiYXNoICAg ICAgICAyMDcwIHRleHQgL3VzciAgICAgICA5MTQzID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgw MTI5NDAxICByCmFsZXggICAgIGJhc2ggICAgICAgIDIwNzAgY3R0eSAvZGV2ICAgICAgICAgNTAg Y3J3LS0tLS0tLSAgIHR0eXYyIHJ3CmFsZXggICAgIGJhc2ggICAgICAgIDIwNzAgICAgMCAvZGV2 ICAgICAgICAgNTAgY3J3LS0tLS0tLSAgIHR0eXYyIHJ3CmFsZXggICAgIGJhc2ggICAgICAgIDIw NzAgICAgMSAvZGV2ICAgICAgICAgNTAgY3J3LS0tLS0tLSAgIHR0eXYyIHJ3CmFsZXggICAgIGJh c2ggICAgICAgIDIwNzAgICAgMiAvZGV2ICAgICAgICAgNTAgY3J3LS0tLS0tLSAgIHR0eXYyIHJ3 CmFsZXggICAgIGJhc2ggICAgICAgIDIwNzAgIDI1NSAvZGV2ICAgICAgICAgNTAgY3J3LS0tLS0t LSAgIHR0eXYyIHJ3CmFsZXggICAgIGJhc2ggICAgICAgIDIwNjAgcm9vdCAvICAgICAgICAgICAg IDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKYWxleCAgICAgYmFzaCAgICAg ICAgMjA2MCAgIHdkIC91c3IvaG9tZSAgICAgMTcgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAx Mjk0MDEgIHIKYWxleCAgICAgYmFzaCAgICAgICAgMjA2MCB0ZXh0IC91c3IgICAgICAgOTE0MyA/ LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgphbGV4ICAgICBiYXNoICAgICAgICAy MDYwIGN0dHkgL2RldiAgICAgICAgIDQ5IGNydy0tLS0tLS0gICB0dHl2MSBydwphbGV4ICAgICBi YXNoICAgICAgICAyMDYwICAgIDAgL2RldiAgICAgICAgIDQ5IGNydy0tLS0tLS0gICB0dHl2MSBy dwphbGV4ICAgICBiYXNoICAgICAgICAyMDYwICAgIDEgL2RldiAgICAgICAgIDQ5IGNydy0tLS0t LS0gICB0dHl2MSBydwphbGV4ICAgICBiYXNoICAgICAgICAyMDYwICAgIDIgL2RldiAgICAgICAg IDQ5IGNydy0tLS0tLS0gICB0dHl2MSBydwphbGV4ICAgICBiYXNoICAgICAgICAyMDYwICAyNTUg L2RldiAgICAgICAgIDQ5IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBoYWxkLWFkZG9u LW1vdXNlLXMgIDIwMzQgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQw NzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgaGFsZC1hZGRvbi1tb3VzZS1zICAyMDM0ICAgd2QgL3Vz ciAgICAgIDE4NjA4ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAg IGhhbGQtYWRkb24tbW91c2UtcyAgMjAzNCB0ZXh0IC91c3IgICAgICAxODk5OCA/LS0tLS0tLS0t ICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBoYWxkLWFkZG9uLW1vdXNlLXMgIDIw MzQgICAgMCAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsICByCnJvb3QgICAgIGhh bGQtYWRkb24tbW91c2UtcyAgMjAzNCAgICAxIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAg IG51bGwgcncKcm9vdCAgICAgaGFsZC1hZGRvbi1tb3VzZS1zICAyMDM0ICAgIDIgL2RldiAgICAg ICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBoYWxkLWFkZG9uLW1vdXNlLXMg IDIwMzQgICAgMyogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMjcyMTgzYzAgPC0+IGZmZmZmZTAwMDk2 MjAzYzAKcm9vdCAgICAgaGFsZC1hZGRvbi1tb3VzZS1zICAyMDI4IHJvb3QgLyAgICAgICAgICAg ICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGhhbGQtYWRk b24tbW91c2UtcyAgMjAyOCAgIHdkIC91c3IgICAgICAxODYwOCA/LS0tLS0tLS0tICAxODQ0Njc0 NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBoYWxkLWFkZG9uLW1vdXNlLXMgIDIwMjggdGV4dCAv dXNyICAgICAgMTg5OTggPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAg ICAgaGFsZC1hZGRvbi1tb3VzZS1zICAyMDI4ICAgIDAgL2RldiAgICAgICAgICA3IGNydy1ydy1y dy0gICAgbnVsbCAgcgpyb290ICAgICBoYWxkLWFkZG9uLW1vdXNlLXMgIDIwMjggICAgMSAvZGV2 ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGhhbGQtYWRkb24tbW91 c2UtcyAgMjAyOCAgICAyIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAgIG51bGwgcncKcm9v dCAgICAgaGFsZC1hZGRvbi1tb3VzZS1zICAyMDI4ICAgIDMqIGxvY2FsIHN0cmVhbSBmZmZmZmUw MDI3MjE4NWEwIDwtPiBmZmZmZmUwMDI3MjE4NGIwCnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2 IHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICBy CnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgd2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0t LS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2IHRl eHQgL3VzciAgICAgIDE4OTc4ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJv b3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgIDAgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0g ICAgbnVsbCAgcgpyb290ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgICAxIC9kZXYgICAgICAgICAg NyBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICAgMiAv ZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVy ICAyMDA2ICAgIDMqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDI3MjE5MDAwIDwtPiBmZmZmZmUwMDI3 MjE4ZTEwCnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgIDcqIHBpcGUgZmZmZmZlMDAwOTdk MmNiOCA8LT4gZmZmZmZlMDAwOTdkMmI2MCAgICAgIDAgcncKcm9vdCAgICAgaGFsZC1ydW5uZXIg IDIwMDYgICAgOCogcGlwZSBmZmZmZmUwMDA5ODAzMTU4IDwtPiBmZmZmZmUwMDA5ODAzMDAwICAg ICAgMCBydwpyb290ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgICA5KiBwaXBlIGZmZmZmZTAwMDlm MWUxNTggPC0+IGZmZmZmZTAwMDlmMWUwMDAgICAgICAwIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVy ICAyMDA2ICAgMTAqIHBpcGUgZmZmZmZlMDAwOWYxZTcwOCA8LT4gZmZmZmZlMDAwOWYxZTViMCAg ICAgIDAgcncKcm9vdCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICAxMSogcGlwZSBmZmZmZmUwMDA5 ZjFlY2I4IDwtPiBmZmZmZmUwMDA5ZjFlYjYwICAgICAgMCBydwpyb290ICAgICBoYWxkLXJ1bm5l ciAgMjAwNiAgIDEyKiBwaXBlIGZmZmZmZTAwMDlmMWU5ZTAgPC0+IGZmZmZmZTAwMDlmMWU4ODgg ICAgICAwIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgMTMqIHBpcGUgZmZmZmZlMDAw OWM2NGNiOCA8LT4gZmZmZmZlMDAwOWM2NGI2MCAgICAgIDAgcncKcm9vdCAgICAgaGFsZC1ydW5u ZXIgIDIwMDYgICAxNCogcGlwZSBmZmZmZmUwMDI3MThlY2I4IDwtPiBmZmZmZmUwMDI3MThlYjYw ICAgICAgMCBydwpyb290ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgIDE1KiBwaXBlIGZmZmZmZTAw MDlmMWU0MzAgPC0+IGZmZmZmZTAwMDlmMWUyZDggICAgICAwIHJ3CnJvb3QgICAgIGhhbGQtcnVu bmVyICAyMDA2ICAgMTYqIHBpcGUgZmZmZmZlMDAwOWM2NDllMCA8LT4gZmZmZmZlMDAwOWM2NDg4 OCAgICAgIDAgcncKcm9vdCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICAxNyogcGlwZSBmZmZmZmUw MDI3MzQzNDMwIDwtPiBmZmZmZmUwMDI3MzQzMmQ4ICAgICAgMCBydwpyb290ICAgICBoYWxkLXJ1 bm5lciAgMjAwNiAgIDE4KiBwaXBlIGZmZmZmZTAwMDlmZGU0MzAgPC0+IGZmZmZmZTAwMDlmZGUy ZDggICAgICAwIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgMTkqIHBpcGUgZmZmZmZl MDAwOWZkZGNiOCA8LT4gZmZmZmZlMDAwOWZkZGI2MCAgICAgIDAgcncKcm9vdCAgICAgaGFsZC1y dW5uZXIgIDIwMDYgICAyMCogcGlwZSBmZmZmZmUwMDA5ZmRkNzA4IDwtPiBmZmZmZmUwMDA5ZmRk NWIwICAgICAgMCBydwpyb290ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgIDIxKiBwaXBlIGZmZmZm ZTAwMDlmZGQxNTggPC0+IGZmZmZmZTAwMDlmZGQwMDAgICAgICAwIHJ3CnJvb3QgICAgIGhhbGQt cnVubmVyICAyMDA2ICAgMjIqIHBpcGUgZmZmZmZlMDAwOWZkYzllMCA8LT4gZmZmZmZlMDAwOWZk Yzg4OCAgICAgIDAgcncKcm9vdCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICAyMyogcGlwZSBmZmZm ZmUwMDA5ZmRjNDMwIDwtPiBmZmZmZmUwMDA5ZmRjMmQ4ICAgICAgMCBydwpyb290ICAgICBoYWxk LXJ1bm5lciAgMjAwNiAgIDI0KiBwaXBlIGZmZmZmZTAwMDlmZGM3MDggPC0+IGZmZmZmZTAwMDlm ZGM1YjAgICAgICAwIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgMjUqIHBpcGUgZmZm ZmZlMDAwOWZkZDllMCA8LT4gZmZmZmZlMDAwOWZkZDg4OCAgICAgIDAgcncKcm9vdCAgICAgaGFs ZC1ydW5uZXIgIDIwMDYgICAyNiogcGlwZSBmZmZmZmUwMDA5ZmRlNzA4IDwtPiBmZmZmZmUwMDA5 ZmRlNWIwICAgICAgMCBydwpyb290ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgIDI3KiBwaXBlIGZm ZmZmZTAwMDlmZGQ0MzAgPC0+IGZmZmZmZTAwMDlmZGQyZDggICAgICAwIHJ3CnJvb3QgICAgIGhh bGQtcnVubmVyICAyMDA2ICAgMjgqIHBpcGUgZmZmZmZlMDAwOWZkYzE1OCA8LT4gZmZmZmZlMDAw OWZkYzAwMCAgICAgIDAgcncKcm9vdCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICAyOSogcGlwZSBm ZmZmZmUwMDA5ZmRlMTU4IDwtPiBmZmZmZmUwMDA5ZmRlMDAwICAgICAgMCBydwpyb290ICAgICBo YWxkLXJ1bm5lciAgMjAwNiAgIDMwKiBwaXBlIGZmZmZmZTAwMjczNGI3MDggPC0+IGZmZmZmZTAw MjczNGI1YjAgICAgICAwIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgMzEqIHBpcGUg ZmZmZmZlMDAyNzM0YjE1OCA8LT4gZmZmZmZlMDAyNzM0YjAwMCAgICAgIDAgcncKcm9vdCAgICAg aGFsZC1ydW5uZXIgIDIwMDYgICAzMiogcGlwZSBmZmZmZmUwMDI3MzMyOWUwIDwtPiBmZmZmZmUw MDI3MzMyODg4ICAgICAgMCBydwpyb290ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgIDMzKiBwaXBl IGZmZmZmZTAwMjczMzI0MzAgPC0+IGZmZmZmZTAwMjczMzIyZDggICAgICAwIHJ3CnJvb3QgICAg IGhhbGQtcnVubmVyICAyMDA2ICAgMzQqIHBpcGUgZmZmZmZlMDAyNzVkYTcwOCA8LT4gZmZmZmZl MDAyNzVkYTViMCAgICAgIDAgcncKcm9vdCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICAzNSogcGlw ZSBmZmZmZmUwMDI3NWRhMTU4IDwtPiBmZmZmZmUwMDI3NWRhMDAwICAgICAgMCBydwpyb290ICAg ICBoYWxkLXJ1bm5lciAgMjAwNiAgIDM2KiBwaXBlIGZmZmZmZTAwMjc2MTU5ZTAgPC0+IGZmZmZm ZTAwMjc2MTU4ODggICAgICAwIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgMzcqIHBp cGUgZmZmZmZlMDAyNzYxNTQzMCA8LT4gZmZmZmZlMDAyNzYxNTJkOCAgICAgIDAgcncKcm9vdCAg ICAgaGFsZC1ydW5uZXIgIDIwMDYgICAzOCogcGlwZSBmZmZmZmUwMDI3NjBhY2I4IDwtPiBmZmZm ZmUwMDI3NjBhYjYwICAgICAgMCBydwpyb290ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgIDM5KiBw aXBlIGZmZmZmZTAwMjc2MGE3MDggPC0+IGZmZmZmZTAwMjc2MGE1YjAgICAgICAwIHJ3CnJvb3Qg ICAgIGhhbGQtcnVubmVyICAyMDA2ICAgNDAqIHBpcGUgZmZmZmZlMDAyNzYwYTE1OCA8LT4gZmZm ZmZlMDAyNzYwYTAwMCAgICAgIDAgcncKcm9vdCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICA0MSog cGlwZSBmZmZmZmUwMDI3MzQzOWUwIDwtPiBmZmZmZmUwMDI3MzQzODg4ICAgICAgMCBydwpyb290 ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgIDQyKiBwaXBlIGZmZmZmZTAwMjczNDNjYjggPC0+IGZm ZmZmZTAwMjczNDNiNjAgICAgICAwIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgNDMq IHBpcGUgZmZmZmZlMDAyNzYwYTllMCA8LT4gZmZmZmZlMDAyNzYwYTg4OCAgICAgIDAgcncKcm9v dCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICA0NCogcGlwZSBmZmZmZmUwMDI3NjE1NzA4IDwtPiBm ZmZmZmUwMDI3NjE1NWIwICAgICAgMCBydwpyb290ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgIDQ1 KiBwaXBlIGZmZmZmZTAwMjc1ZGE0MzAgPC0+IGZmZmZmZTAwMjc1ZGEyZDggICAgICAwIHJ3CnJv b3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAgNDYqIHBpcGUgZmZmZmZlMDAyNzYxNWNiOCA8LT4g ZmZmZmZlMDAyNzYxNWI2MCAgICAgIDAgcncKcm9vdCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICA0 NyogcGlwZSBmZmZmZmUwMDI3NjBhNDMwIDwtPiBmZmZmZmUwMDI3NjBhMmQ4ICAgICAgMCBydwpy b290ICAgICBoYWxkLXJ1bm5lciAgMjAwNiAgIDQ4KiBwaXBlIGZmZmZmZTAwMjc2MTUxNTggPC0+ IGZmZmZmZTAwMjc2MTUwMDAgICAgICAwIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVyICAyMDA2ICAg NDkqIHBpcGUgZmZmZmZlMDAyNzM0MzcwOCA8LT4gZmZmZmZlMDAyNzM0MzViMCAgICAgIDAgcncK cm9vdCAgICAgaGFsZC1ydW5uZXIgIDIwMDYgICA1MCogcGlwZSBmZmZmZmUwMDI3NjJjOWUwIDwt PiBmZmZmZmUwMDI3NjJjODg4ICAgICAgMCBydwpyb290ICAgICBnYW1fc2VydmVyICAyMDA1IHJv b3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJv b3QgICAgIGdhbV9zZXJ2ZXIgIDIwMDUgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjAwNSB0ZXh0IC91 c3IgICAgICAxODk2NyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAg ICBnYW1fc2VydmVyICAyMDA1ICAgIDAgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVs bCAgcgpyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAgIDEgL2RldiAgICAgICAgICA3IGNydy1y dy1ydy0gICAgbnVsbCAgdwpyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAgIDIgL2RldiAgICAg ICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCAgdwpyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAg IDQqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDA5NWVmMGYwCnJvb3QgICAgIGdhbV9zZXJ2ZXIgIDIw MDUgICAgNSogcGlwZSBmZmZmZmUwMDI3MThlMDAwIDwtPiBmZmZmZmUwMDI3MThlMTU4ICAgICAg MCBydwpyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAgIDYqIHBpcGUgZmZmZmZlMDAyNzE4ZTE1 OCA8LT4gZmZmZmZlMDAyNzE4ZTAwMCAgICAgIDAgcncKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjAw NSAgICA3KiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAyNzIxOTFlMCA8LT4gZmZmZmZlMDAyNzIxOTJk MApyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAgIDggL3VzciAgICAgMTQ4Mzc5ID8tLS0tLS0t LS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGdhbV9zZXJ2ZXIgIDIwMDUgICAg OSAvdXNyICAgICAxNDgzODIgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9v dCAgICAgZ2FtX3NlcnZlciAgMjAwNSAgIDEwIC91c3IgICAgIDE0ODM4MyA/LS0tLS0tLS0tICAx ODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAgMTEgL3Vz ciAgICAgMTQ4MzgwID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAg IGdhbV9zZXJ2ZXIgIDIwMDUgICAxMiAvdXNyICAgICAxNDgzODQgPy0tLS0tLS0tLSAgMTg0NDY3 NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjAwNSAgIDEzIC91c3IgICAg IDE0ODM4MSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBnYW1f c2VydmVyICAyMDA1ICAgMTQgL3Zhci9ydW4gICAgIDUxID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcx NTgwMTI5NDAxICByCnJvb3QgICAgIGdhbV9zZXJ2ZXIgIDIwMDUgICAxNSAvdXNyICAgICAgMTgw OTQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2FtX3NlcnZl ciAgMjAwNSAgIDE2IC91c3IgICAgICAxODA5NSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEy OTQwMSAgcgpyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAgMTcgL3ZhciAgICAgICA5MjI4ID8t LS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGdhbV9zZXJ2ZXIgIDIw MDUgICAxOCAvdXNyICAgICAgMTgxMDEgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEg IHIKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjAwNSAgIDE5IC92YXIgICAgICAgOTIyOSA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAg MjAgL3VzciAgICAgIDE4MDk5ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJv b3QgICAgIGdhbV9zZXJ2ZXIgIDIwMDUgICAyMSAvdmFyICAgICAgIDkyMjUgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjAwNSAgIDIyIC91 c3IgICAgICAxODEwNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAg ICBnYW1fc2VydmVyICAyMDA1ICAgMjMgL3ZhciAgICAgICA5MjI3ID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGdhbV9zZXJ2ZXIgIDIwMDUgICAyNCAvdXNyICAg ICAgMTgxMDIgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2Ft X3NlcnZlciAgMjAwNSAgIDI1IC91c3IgICAgICAxODEwMyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3 MTU4MDEyOTQwMSAgcgpyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAgMjYgL3ZhciAgICAgICA5 MjI2ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGdhbV9zZXJ2 ZXIgIDIwMDUgICAyNyAvdXNyICAgICAgMTgxMDAgPy0tLS0tLS0tLSAgICAgICAwICByCnJvb3Qg ICAgIGdhbV9zZXJ2ZXIgIDIwMDUgICAyOCAvdmFyICAgICAgIDkyMjQgPy0tLS0tLS0tLSAgMTg0 NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjAwNSAgIDI5IC92YXIg ICAgICAgOTIyNyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBn YW1fc2VydmVyICAyMDA1ICAgMzAgL3ZhciAgICAgICA5MjI5ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGdhbV9zZXJ2ZXIgIDIwMDUgICAzMSAvdmFyICAgICAg IDkyMjggPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2FtX3Nl cnZlciAgMjAwNSAgIDMyIC92YXIgICAgICAgOTIyNiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4 MDEyOTQwMSAgcgpyb290ICAgICBnYW1fc2VydmVyICAyMDA1ICAgMzMgL3ZhciAgICAgICA5MjI1 ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGdhbV9zZXJ2ZXIg IDIwMDUgICAzNCAvdXNyICAgICAgMTgwOTggPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0 MDEgIHIKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjAwNSAgIDM1IC91c3IgICAgICAxODEwMCA/LS0t LS0tLS0tICAgICAgIDAgIHIKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjAwNSAgIDM2IC91c3IgICAg ICAxODEwNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBnYW1f c2VydmVyICAyMDA1ICAgMzcgL3VzciAgICAgIDE4MTAxID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcx NTgwMTI5NDAxICByCnJvb3QgICAgIGdhbV9zZXJ2ZXIgIDIwMDUgICAzOCAvdXNyICAgICAgMTgw OTkgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2FtX3NlcnZl ciAgMjAwNSAgIDM5IC91c3IgICAgICAxODEwMiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEy OTQwMSAgcgpyb290ICAgICBwb2xraXRkICAgICAyMDAzIHJvb3QgLyAgICAgICAgICAgICA0ID8t LS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIHBvbGtpdGQgICAgIDIw MDMgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEg IHIKcm9vdCAgICAgcG9sa2l0ZCAgICAgMjAwMyB0ZXh0IC91c3IgICAgICAxODk5NyA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBwb2xraXRkICAgICAyMDAzICAg IDAgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBwb2xraXRk ICAgICAyMDAzICAgIDEgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290 ICAgICBwb2xraXRkICAgICAyMDAzICAgIDIgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAg bnVsbCBydwpyb290ICAgICBwb2xraXRkICAgICAyMDAzICAgIDMqIHBpcGUgZmZmZmZlMDAwOTgw Mzg4OCA8LT4gZmZmZmZlMDAwOTgwMzllMCAgICAgIDAgcncKcm9vdCAgICAgcG9sa2l0ZCAgICAg MjAwMyAgICA0IC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAg cG9sa2l0ZCAgICAgMjAwMyAgICA1KiBwaXBlIGZmZmZmZTAwMDk4MDM5ZTAgPC0+IGZmZmZmZTAw MDk4MDM4ODggICAgICAwIHJ3CnJvb3QgICAgIHBvbGtpdGQgICAgIDIwMDMgICAgNiAvdXNyICAg ICAgMTg1NDAgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgcG9s a2l0ZCAgICAgMjAwMyAgICA3IC91c3IgICAgICA1OTkyMSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3 MTU4MDEyOTQwMSAgcgpyb290ICAgICBwb2xraXRkICAgICAyMDAzICAgIDggL3VzciAgICAgMTIw MDg1ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIHBvbGtpdGQg ICAgIDIwMDMgICAxMCogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDk1ZWY3ODAgPC0+IGZmZmZmZTAw MDk1ZWYzYzAKcm9vdCAgICAgcG9sa2l0ZCAgICAgMjAwMyAgIDExKiBwaXBlIGZmZmZmZTAwMjcx OGU1YjAgPC0+IGZmZmZmZTAwMjcxOGU3MDggICAgICAwIHJ3CnJvb3QgICAgIHBvbGtpdGQgICAg IDIwMDMgICAxMiogcGlwZSBmZmZmZmUwMDI3MThlNzA4IDwtPiBmZmZmZmUwMDI3MThlNWIwICAg ICAgMCBydwpyb290ICAgICBwb2xraXRkICAgICAyMDAzICAgMTMqIHBpcGUgZmZmZmZlMDAwOWM2 NDJkOCA8LT4gZmZmZmZlMDAwOWM2NDQzMCAgICAgIDAgcncKcm9vdCAgICAgcG9sa2l0ZCAgICAg MjAwMyAgIDE0KiBwaXBlIGZmZmZmZTAwMDljNjQ0MzAgPC0+IGZmZmZmZTAwMDljNjQyZDggICAg ICAwIHJ3CnJvb3QgICAgIHBvbGtpdGQgICAgIDIwMDMgICAxNSogbG9jYWwgc3RyZWFtIGZmZmZm ZTAwMjcyMTkyZDAgPC0+IGZmZmZmZTAwMjcyMTkxZTAKcm9vdCAgICAgY29uc29sZS1raXQtZGFl bW9uICAyMDAxIHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgw MTI5NDAxICByCnJvb3QgICAgIGNvbnNvbGUta2l0LWRhZW1vbiAgMjAwMSAgIHdkIC8gICAgICAg ICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBjb25z b2xlLWtpdC1kYWVtb24gIDIwMDEgdGV4dCAvdXNyICAgICAgMTc5ODggPy0tLS0tLS0tLSAgMTg0 NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgY29uc29sZS1raXQtZGFlbW9uICAyMDAxICAg IDAgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjb25zb2xl LWtpdC1kYWVtb24gIDIwMDEgICAgMSAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxs IHJ3CnJvb3QgICAgIGNvbnNvbGUta2l0LWRhZW1vbiAgMjAwMSAgICAyIC9kZXYgICAgICAgICAg NyBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgY29uc29sZS1raXQtZGFlbW9uICAyMDAx ICAgIDMqIHBpcGUgZmZmZmZlMDAwOTBlNDViMCA8LT4gZmZmZmZlMDAwOTBlNDcwOCAgICAgIDAg cncKcm9vdCAgICAgY29uc29sZS1raXQtZGFlbW9uICAyMDAxICAgIDQgL2RldiAgICAgICAgICA3 IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIwMDEg ICAgNSogcGlwZSBmZmZmZmUwMDA5MGU0NzA4IDwtPiBmZmZmZmUwMDA5MGU0NWIwICAgICAgMCBy dwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIwMDEgICAgNiAvdXNyICAgICAgMTg1NDAg Py0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgY29uc29sZS1raXQt ZGFlbW9uICAyMDAxICAgIDcgL3VzciAgICAgIDU5OTIxID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcx NTgwMTI5NDAxICByCnJvb3QgICAgIGNvbnNvbGUta2l0LWRhZW1vbiAgMjAwMSAgICA4IC91c3Ig ICAgIDEyMDA4NSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBj b25zb2xlLWtpdC1kYWVtb24gIDIwMDEgICAgOSogcGlwZSBmZmZmZmUwMDA5MGU0YjYwIDwtPiBm ZmZmZmUwMDA5MGU0Y2I4ICAgICAgMCBydwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIw MDEgICAxMCogcGlwZSBmZmZmZmUwMDA5MGU0Y2I4IDwtPiBmZmZmZmUwMDA5MGU0YjYwICAgICAg MCBydwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIwMDEgICAxMSogbG9jYWwgc3RyZWFt IGZmZmZmZTAwMDk1ZWZjMzAgPC0+IGZmZmZmZTAwMDk1ZWZkMjAKcm9vdCAgICAgY29uc29sZS1r aXQtZGFlbW9uICAyMDAxICAgMTIgL3Zhci9sb2cgICAgICA5ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTgwMTI5NDAxICB3CnJvb3QgICAgIGNvbnNvbGUta2l0LWRhZW1vbiAgMjAwMSAgIDEzKiBs b2NhbCBzdHJlYW0gZmZmZmZlMDAwOTVlZmUxMCA8LT4gZmZmZmZlMDAwOTYyMDAwMApyb290ICAg ICBjb25zb2xlLWtpdC1kYWVtb24gIDIwMDEgICAxNCAvZGV2ICAgICAgICAgIDQgY3J3LS0tLS0t LSAgY29uc29sZSAgcgpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIwMDEgICAxNSogcGlw ZSBmZmZmZmUwMDA2ZjU2MDAwIDwtPiBmZmZmZmUwMDA2ZjU2MTU4ICAgICAgMCBydwpyb290ICAg ICBjb25zb2xlLWtpdC1kYWVtb24gIDIwMDEgICAxNiogcGlwZSBmZmZmZmUwMDA2ZjU2MTU4IDwt PiBmZmZmZmUwMDA2ZjU2MDAwICAgICAgMCBydwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24g IDIwMDEgICAxOSogcGlwZSBmZmZmZmUwMDI3MThkNWIwIDwtPiBmZmZmZmUwMDI3MThkNzA4ICAg ICAgMCBydwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIwMDEgICAyMCogcGlwZSBmZmZm ZmUwMDI3MThkNzA4IDwtPiBmZmZmZmUwMDI3MThkNWIwICAgICAgMCBydwpoYWxkYWVtbyBoYWxk ICAgICAgICAxOTk5IHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcx NTgwMTI5NDAxICByCmhhbGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICB3ZCAvICAgICAgICAgICAg IDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKaGFsZGFlbW8gaGFsZCAgICAg ICAgMTk5OSB0ZXh0IC91c3IgICAgICAxODAzMiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEy OTQwMSAgcgpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5ICAgIDAgL2RldiAgICAgICAgICA3IGNy dy1ydy1ydy0gICAgbnVsbCBydwpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5ICAgIDEgL2RldiAg ICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5 ICAgIDIgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpoYWxkYWVtbyBoYWxk ICAgICAgICAxOTk5ICAgIDMqIHBpcGUgZmZmZmZlMDAwOTgwMTJkOCA8LT4gZmZmZmZlMDAwOTgw MTQzMCAgICAgIDAgcncKaGFsZGFlbW8gaGFsZCAgICAgICAgMTk5OSAgICA0KiBwaXBlIGZmZmZm ZTAwMDk4MDE0MzAgPC0+IGZmZmZmZTAwMDk4MDEyZDggICAgICAwIHJ3CmhhbGRhZW1vIGhhbGQg ICAgICAgIDE5OTkgICAgNyogcGlwZSBmZmZmZmUwMDA5NWEyYjYwIDwtPiBmZmZmZmUwMDA5NWEy Y2I4ICAgICAgMCBydwpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5ICAgIDgqIHBpcGUgZmZmZmZl MDAwOTVhMmNiOCA8LT4gZmZmZmZlMDAwOTVhMmI2MCAgICAgIDAgcncKaGFsZGFlbW8gaGFsZCAg ICAgICAgMTk5OSAgICA5KiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAyNzExMDg3MApoYWxkYWVtbyBo YWxkICAgICAgICAxOTk5ICAgMTAqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDI3MTEwNzgwIDwtPiBm ZmZmZmUwMDI3MTEwNjkwCmhhbGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICAxMSogbG9jYWwgc3Ry ZWFtIGZmZmZmZTAwMjcxZmRiNDAKaGFsZGFlbW8gaGFsZCAgICAgICAgMTk5OSAgIDEyKiBwaXBl IGZmZmZmZTAwMDlmZGViNjAgPC0+IGZmZmZmZTAwMDlmZGVjYjggICAgICAwIHJ3CmhhbGRhZW1v IGhhbGQgICAgICAgIDE5OTkgICAxMyogcGlwZSBmZmZmZmUwMDA5ZmRlY2I4IDwtPiBmZmZmZmUw MDA5ZmRlYjYwICAgICAgMCBydwpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5ICAgMTQqIGxvY2Fs IHN0cmVhbSBmZmZmZmUwMDI3MjE4ZTEwIDwtPiBmZmZmZmUwMDI3MjE5MDAwCmhhbGRhZW1vIGhh bGQgICAgICAgIDE5OTkgICAxNiAvZGV2ICAgICAgICAgIDkgY3J3LXItLXItLSAgICAgcGNpIHJ3 CmhhbGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICAxNyAvZGV2ICAgICAgICAgNzIgY3J3LS0tLS0t LSAgICB4cHQwIHJ3CmhhbGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICAxOSAvdXNyICAgICAgMTgy MTEgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKaGFsZGFlbW8gaGFsZCAgICAg ICAgMTk5OSAgIDIwIC91c3IgICAgIDE0NzIzOSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEy OTQwMSAgcgpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5ICAgMjEgL3ZhciAgICAgICA5MjM1ID8t LS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCmhhbGRhZW1vIGhhbGQgICAgICAgIDE5 OTkgICAyMiAvdXNyICAgICAxNDc5NzAgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEg IHIKaGFsZGFlbW8gaGFsZCAgICAgICAgMTk5OSAgIDIzIC91c3IgICAgIDE0Nzk3MSA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5ICAg MjQgL3VzciAgICAgMTQ3OTcyID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCmhh bGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICAyNSAvdXNyICAgICAgMTg1NTcgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKaGFsZGFlbW8gaGFsZCAgICAgICAgMTk5OSAgIDI2IC91 c3IgICAgIDE0Nzk4OCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpoYWxkYWVt byBoYWxkICAgICAgICAxOTk5ICAgMjcgL3VzciAgICAgMTQ3OTg5ID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTgwMTI5NDAxICByCmhhbGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICAyOCAvdXNyICAg ICAxNDc5OTAgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKaGFsZGFlbW8gaGFs ZCAgICAgICAgMTk5OSAgIDI5IC91c3IgICAgIDE0Nzk5MSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3 MTU4MDEyOTQwMSAgcgpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5ICAgMzAgL3VzciAgICAgIDE4 NTU5ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCmhhbGRhZW1vIGhhbGQgICAg ICAgIDE5OTkgICAzMSAvdXNyICAgICAxNDc5NzMgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAx Mjk0MDEgIHIKaGFsZGFlbW8gaGFsZCAgICAgICAgMTk5OSAgIDMyIC91c3IgICAgIDE0Nzk4NyA/ LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpoYWxkYWVtbyBoYWxkICAgICAgICAx OTk5ICAgMzMgL3VzciAgICAgMTQ3OTc0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAx ICByCmhhbGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICAzNCAvdXNyICAgICAxNDc5NzYgPy0tLS0t LS0tLSAgICAgICAwICByCmhhbGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICAzNSAvdXNyICAgICAx NDc5ODQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKaGFsZGFlbW8gaGFsZCAg ICAgICAgMTk5OSAgIDM2IC91c3IgICAgIDE0Nzk3NyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4 MDEyOTQwMSAgcgpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5ICAgMzcgL3VzciAgICAgMTQ3OTc1 ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCmhhbGRhZW1vIGhhbGQgICAgICAg IDE5OTkgICAzOCAvdXNyICAgICAxNDc5ODYgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0 MDEgIHIKaGFsZGFlbW8gaGFsZCAgICAgICAgMTk5OSAgIDM5IC91c3IgICAgIDE0Nzk4MyA/LS0t LS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5 ICAgNDAgL3VzciAgICAgMTQ3OTgxID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICBy CmhhbGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICA0MSAvdXNyICAgICAxNDc5ODUgPy0tLS0tLS0t LSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKaGFsZGFlbW8gaGFsZCAgICAgICAgMTk5OSAgIDQy IC91c3IgICAgIDE0Nzk4MiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpoYWxk YWVtbyBoYWxkICAgICAgICAxOTk5ICAgNDMgL3VzciAgICAgMTQ3OTc4ID8tLS0tLS0tLS0gIDE4 NDQ2NzQ0MDcxNTgwMTI5NDAxICByCmhhbGRhZW1vIGhhbGQgICAgICAgIDE5OTkgICA0NCAvdXNy ICAgICAxNDc5NzkgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKaGFsZGFlbW8g aGFsZCAgICAgICAgMTk5OSAgIDQ1IC91c3IgICAgIDE0Nzk4MCA/LS0tLS0tLS0tICAxODQ0Njc0 NDA3MTU4MDEyOTQwMSAgcgpoYWxkYWVtbyBoYWxkICAgICAgICAxOTk5ICAgNDYgL3VzciAgICAg IDE4NTU4ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCmhhbGRhZW1vIGhhbGQg ICAgICAgIDE5OTkgICA0NyogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDk2MjAwZjAgPC0+IGZmZmZm ZTAwMDk1ZWY5NjAKaGFsZGFlbW8gaGFsZCAgICAgICAgMTk5OSAgIDQ4KiBsb2NhbCBzdHJlYW0g ZmZmZmZlMDAyNzIxODRiMCA8LT4gZmZmZmZlMDAyNzIxODVhMApoYWxkYWVtbyBoYWxkICAgICAg ICAxOTk5ICAgNDkqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDA5NjIwM2MwIDwtPiBmZmZmZmUwMDI3 MjE4M2MwCnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTQgcm9vdCAvICAgICAgICAgICAgIDQgPy0t LS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTk5 NCAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAg cgpyb290ICAgICBnZXR0eSAgICAgICAxOTk0IHRleHQgL3VzciAgICAgMjUxNzUxID8tLS0tLS0t LS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTQgY3R0 eSAvZGV2ICAgICAgICAgNTUgY3J3LS0tLS0tLSAgIHR0eXY3IHJ3CnJvb3QgICAgIGdldHR5ICAg ICAgIDE5OTQgICAgMCAvZGV2ICAgICAgICAgNTUgY3J3LS0tLS0tLSAgIHR0eXY3IHJ3CnJvb3Qg ICAgIGdldHR5ICAgICAgIDE5OTQgICAgMSAvZGV2ICAgICAgICAgNTUgY3J3LS0tLS0tLSAgIHR0 eXY3IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTQgICAgMiAvZGV2ICAgICAgICAgNTUgY3J3 LS0tLS0tLSAgIHR0eXY3IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTMgcm9vdCAvICAgICAg ICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2V0 dHkgICAgICAgMTk5MyAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3 MTU4MDEyOTQwMSAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTkzIHRleHQgL3VzciAgICAgMjUx NzUxID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGdldHR5ICAg ICAgIDE5OTMgY3R0eSAvZGV2ICAgICAgICAgNTQgY3J3LS0tLS0tLSAgIHR0eXY2IHJ3CnJvb3Qg ICAgIGdldHR5ICAgICAgIDE5OTMgICAgMCAvZGV2ICAgICAgICAgNTQgY3J3LS0tLS0tLSAgIHR0 eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTMgICAgMSAvZGV2ICAgICAgICAgNTQgY3J3 LS0tLS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTMgICAgMiAvZGV2ICAg ICAgICAgNTQgY3J3LS0tLS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTIg cm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIK cm9vdCAgICAgZ2V0dHkgICAgICAgMTk5MiAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0t ICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTkyIHRleHQg L3VzciAgICAgMjUxNzUxID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3Qg ICAgIGdldHR5ICAgICAgIDE5OTIgY3R0eSAvZGV2ICAgICAgICAgNTMgY3J3LS0tLS0tLSAgIHR0 eXY1IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTIgICAgMCAvZGV2ICAgICAgICAgNTMgY3J3 LS0tLS0tLSAgIHR0eXY1IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTIgICAgMSAvZGV2ICAg ICAgICAgNTMgY3J3LS0tLS0tLSAgIHR0eXY1IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTIg ICAgMiAvZGV2ICAgICAgICAgNTMgY3J3LS0tLS0tLSAgIHR0eXY1IHJ3CnJvb3QgICAgIGdldHR5 ICAgICAgIDE5OTEgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1 ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTk5MSAgIHdkIC8gICAgICAgICAgICAg NCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBnZXR0eSAgICAg ICAxOTkxIHRleHQgL3VzciAgICAgMjUxNzUxID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5 NDAxICByCnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTEgY3R0eSAvZGV2ICAgICAgICAgNTIgY3J3 LS0tLS0tLSAgIHR0eXY0IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTEgICAgMCAvZGV2ICAg ICAgICAgNTIgY3J3LS0tLS0tLSAgIHR0eXY0IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTEg ICAgMSAvZGV2ICAgICAgICAgNTIgY3J3LS0tLS0tLSAgIHR0eXY0IHJ3CnJvb3QgICAgIGdldHR5 ICAgICAgIDE5OTEgICAgMiAvZGV2ICAgICAgICAgNTIgY3J3LS0tLS0tLSAgIHR0eXY0IHJ3CnJv b3QgICAgIGdldHR5ICAgICAgIDE5OTAgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTk5MCAgIHdkIC8g ICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAg ICBnZXR0eSAgICAgICAxOTkwIHRleHQgL3VzciAgICAgMjUxNzUxID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTAgY3R0eSAvZGV2ICAg ICAgICAgNTEgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5OTAg ICAgMCAvZGV2ICAgICAgICAgNTEgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJvb3QgICAgIGdldHR5 ICAgICAgIDE5OTAgICAgMSAvZGV2ICAgICAgICAgNTEgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJv b3QgICAgIGdldHR5ICAgICAgIDE5OTAgICAgMiAvZGV2ICAgICAgICAgNTEgY3J3LS0tLS0tLSAg IHR0eXYzIHJ3CnJvb3QgICAgIGxvZ2luICAgICAgIDE5ODkgcm9vdCAvICAgICAgICAgICAgIDQg Py0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgbG9naW4gICAgICAg MTk4OSAgIHdkIC91c3IvaG9tZSAgICAgMTcgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0 MDEgIHIKcm9vdCAgICAgbG9naW4gICAgICAgMTk4OSB0ZXh0IC91c3IgICAgICAxNTcyNCA/LS0t LS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBsb2dpbiAgICAgICAxOTg5 IGN0dHkgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2MiBydwpyb290ICAgICBsb2dp biAgICAgICAxOTg5ICAgIDAgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2MiBydwpy b290ICAgICBsb2dpbiAgICAgICAxOTg5ICAgIDEgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0g ICB0dHl2MiBydwpyb290ICAgICBsb2dpbiAgICAgICAxOTg5ICAgIDIgL2RldiAgICAgICAgIDUw IGNydy0tLS0tLS0gICB0dHl2MiBydwpyb290ICAgICBsb2dpbiAgICAgICAxOTg5ICAgIDMqIGxv Y2FsIGRncmFtIGZmZmZmZTAwMjc2MjMwZjAgPC0+IGZmZmZmZTAwMDk1ZWYyZDAKcm9vdCAgICAg bG9naW4gICAgICAgMTk4OCByb290IC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0 NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBsb2dpbiAgICAgICAxOTg4ICAgd2QgL3Vzci9ob21l ICAgICAxNyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBsb2dp biAgICAgICAxOTg4IHRleHQgL3VzciAgICAgIDE1NzI0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcx NTgwMTI5NDAxICByCnJvb3QgICAgIGxvZ2luICAgICAgIDE5ODggY3R0eSAvZGV2ICAgICAgICAg NDkgY3J3LS0tLS0tLSAgIHR0eXYxIHJ3CnJvb3QgICAgIGxvZ2luICAgICAgIDE5ODggICAgMCAv ZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXYxIHJ3CnJvb3QgICAgIGxvZ2luICAgICAg IDE5ODggICAgMSAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXYxIHJ3CnJvb3QgICAg IGxvZ2luICAgICAgIDE5ODggICAgMiAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXYx IHJ3CnJvb3QgICAgIGxvZ2luICAgICAgIDE5ODggICAgMyogbG9jYWwgZGdyYW0gZmZmZmZlMDAy NzYyMmMzMCA8LT4gZmZmZmZlMDAwOTVlZjJkMApyb290ICAgICBnZXR0eSAgICAgICAxOTg3IHJv b3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJv b3QgICAgIGdldHR5ICAgICAgIDE5ODcgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTk4NyB0ZXh0IC91 c3IgICAgIDI1MTc1MSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAg ICBnZXR0eSAgICAgICAxOTg3IGN0dHkgL2RldiAgICAgICAgIDQ4IGNydy0tLS0tLS0gICB0dHl2 MCBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTg3ICAgIDAgL2RldiAgICAgICAgIDQ4IGNydy0t LS0tLS0gICB0dHl2MCBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTg3ICAgIDEgL2RldiAgICAg ICAgIDQ4IGNydy0tLS0tLS0gICB0dHl2MCBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTg3ICAg IDIgL2RldiAgICAgICAgIDQ4IGNydy0tLS0tLS0gICB0dHl2MCBydwpyb290ICAgICBjcm9uICAg ICAgICAxOTA4IHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgw MTI5NDAxICByCnJvb3QgICAgIGNyb24gICAgICAgIDE5MDggICB3ZCAvdmFyICAgICAgICAgMTUg Py0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgY3JvbiAgICAgICAg MTkwOCB0ZXh0IC91c3IgICAgICAxOTU4OSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQw MSAgcgpyb290ICAgICBjcm9uICAgICAgICAxOTA4ICAgIDAgL2RldiAgICAgICAgICA3IGNydy1y dy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9uICAgICAgICAxOTA4ICAgIDEgL2RldiAgICAg ICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9uICAgICAgICAxOTA4ICAg IDIgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9uICAg ICAgICAxOTA4ICAgIDMgL3Zhci9ydW4gICAgIDQ4ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgw MTI5NDAxICB3CnJvb3QgICAgIHNzaGQgICAgICAgIDE4OTkgcm9vdCAvICAgICAgICAgICAgIDQg Py0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgc3NoZCAgICAgICAg MTg5OSAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQw MSAgcgpyb290ICAgICBzc2hkICAgICAgICAxODk5IHRleHQgL3VzciAgICAgMjUzMjkxID8tLS0t LS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIHNzaGQgICAgICAgIDE4OTkg ICAgMCAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHNzaGQg ICAgICAgIDE4OTkgICAgMSAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJv b3QgICAgIHNzaGQgICAgICAgIDE4OTkgICAgMiAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAg ICBudWxsIHJ3CnJvb3QgICAgIHNzaGQgICAgICAgIDE4OTkgICAgMyAvZGV2ICAgICAgICAgNzAg Y3J3LXJ3LXJ3LSAgY3J5cHRvIHJ3CnJvb3QgICAgIHNzaGQgICAgICAgIDE4OTkgICAgNCogaW50 ZXJuZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDA5YjMzN2EwCnJvb3QgICAgIGN1cHNkICAgICAgIDE4 NzQgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEg IHIKcm9vdCAgICAgY3Vwc2QgICAgICAgMTg3NCAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBjdXBzZCAgICAgICAxODc0IHRl eHQgL3VzciAgICAgIDE3OTkyID8tLS0tLS0tLS0gICAgICAgMCAgcgpyb290ICAgICBjdXBzZCAg ICAgICAxODc0ICAgIDAgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCAgcgpyb290 ICAgICBjdXBzZCAgICAgICAxODc0ICAgIDEgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAg bnVsbCAgdwpyb290ICAgICBjdXBzZCAgICAgICAxODc0ICAgIDIgL2RldiAgICAgICAgICA3IGNy dy1ydy1ydy0gICAgbnVsbCAgdwpyb290ICAgICBjdXBzZCAgICAgICAxODc0ICAgIDQgL3Zhci9s b2cgICAgIDE0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxIHJ3CnJvb3QgICAgIGN1 cHNkICAgICAgIDE4NzQgICAgNSAvdmFyL2xvZyAgICAgMTMgPy0tLS0tLS0tLSAgMTg0NDY3NDQw NzE1ODAxMjk0MDEgcncKcm9vdCAgICAgY3Vwc2QgICAgICAgMTg3NCAgICA2IC92YXIvbG9nICAg ICAxMiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSBydwpyb290ICAgICBjdXBzZCAg ICAgICAxODc0ICAgIDcqIGludGVybmV0NiBzdHJlYW0gdGNwIGZmZmZmZTAwMDlmMWE3YTAKcm9v dCAgICAgY3Vwc2QgICAgICAgMTg3NCAgICA4KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZmZTAw MDlmMWEzZDAKcm9vdCAgICAgY3Vwc2QgICAgICAgMTg3NCAgICA5KiBsb2NhbCBzdHJlYW0gZmZm ZmZlMDAwOTYyMDFlMApyb290ICAgICBjdXBzZCAgICAgICAxODc0ICAgMTAqIGludGVybmV0IGRn cmFtIHVkcCBmZmZmZmUwMDA5NTg3MTg4CnJvb3QgICAgIGN1cHNkICAgICAgIDE4NzQgICAxMSog cGlwZSBmZmZmZmUwMDA5ZjFmYjYwIDwtPiBmZmZmZmUwMDA5ZjFmY2I4ICAgICAgMCBydwpyb290 ICAgICBjdXBzZCAgICAgICAxODc0ICAgMTIqIHBpcGUgZmZmZmZlMDAwOWYxZmNiOCA8LT4gZmZm ZmZlMDAwOWYxZmI2MCAgICAgIDAgcncKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE4NTMgcm9vdCAv ICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKbWVzc2Fn ZWIgZGJ1cy1kYWVtb24gIDE4NTMgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0 NDY3NDQwNzE1ODAxMjk0MDEgIHIKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE4NTMgdGV4dCAvdXNy ICAgICAgMTcyMzcgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKbWVzc2FnZWIg ZGJ1cy1kYWVtb24gIDE4NTMgICAgMCAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxs IHJ3Cm1lc3NhZ2ViIGRidXMtZGFlbW9uICAxODUzICAgIDEgL2RldiAgICAgICAgICA3IGNydy1y dy1ydy0gICAgbnVsbCBydwptZXNzYWdlYiBkYnVzLWRhZW1vbiAgMTg1MyAgICAyIC9kZXYgICAg ICAgICAgNyBjcnctcnctcnctICAgIG51bGwgcncKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE4NTMg ICAgMyogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDk2MjAyZDAKbWVzc2FnZWIgZGJ1cy1kYWVtb24g IDE4NTMgICAgNCAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm1lc3NhZ2Vi IGRidXMtZGFlbW9uICAxODUzICAgIDYgL3VzciAgICAgIDE4NTQwID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTgwMTI5NDAxICByCm1lc3NhZ2ViIGRidXMtZGFlbW9uICAxODUzICAgIDcgL3VzciAg ICAgIDU5OTIxID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCm1lc3NhZ2ViIGRi dXMtZGFlbW9uICAxODUzICAgIDggL3VzciAgICAgMTIwMDg1ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTgwMTI5NDAxICByCm1lc3NhZ2ViIGRidXMtZGFlbW9uICAxODUzICAgIDkqIGxvY2FsIHN0 cmVhbSBmZmZmZmUwMDA5NWVmNWEwIDwtPiBmZmZmZmUwMDA5NWVmNjkwCm1lc3NhZ2ViIGRidXMt ZGFlbW9uICAxODUzICAgMTAqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDA5NWVmNjkwIDwtPiBmZmZm ZmUwMDA5NWVmNWEwCm1lc3NhZ2ViIGRidXMtZGFlbW9uICAxODUzICAgMTEqIGxvY2FsIHN0cmVh bSBmZmZmZmUwMDI3MTEwNjkwIDwtPiBmZmZmZmUwMDI3MTEwNzgwCm1lc3NhZ2ViIGRidXMtZGFl bW9uICAxODUzICAgMTIqIGxvY2FsIGRncmFtIGZmZmZmZTAwMDk1ZWY4NzAgPC0+IGZmZmZmZTAw MDk1ZWYxZTAKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE4NTMgICAxMyogbG9jYWwgc3RyZWFtIGZm ZmZmZTAwMDk2MjA3ODAgPC0+IGZmZmZmZTAwMDk2MjA2OTAKbWVzc2FnZWIgZGJ1cy1kYWVtb24g IDE4NTMgICAxNCogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDk1ZWZkMjAgPC0+IGZmZmZmZTAwMDk1 ZWZjMzAKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE4NTMgICAxNiogbG9jYWwgc3RyZWFtIGZmZmZm ZTAwMDk2MjAwMDAgPC0+IGZmZmZmZTAwMDk1ZWZlMTAKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE4 NTMgICAxOCogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDk1ZWYzYzAgPC0+IGZmZmZmZTAwMDk1ZWY3 ODAKcm9vdCAgICAgWG9yZyAgICAgICAgMTgzOSByb290IC8gICAgICAgICAgICAgNCA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBYb3JnICAgICAgICAxODM5ICAg d2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJv b3QgICAgIFhvcmcgICAgICAgIDE4MzkgdGV4dCAvdXNyICAgICAgMTcwODUgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgWG9yZyAgICAgICAgMTgzOSAgICAwIC92 YXIvbG9nICAgICAxOCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgdwpyb290ICAg ICBYb3JnICAgICAgICAxODM5ICAgIDEqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDA5YTczM2MwCnJv b3QgICAgIFhvcmcgICAgICAgIDE4MzkgICAgMiAvdmFyL2xvZyAgICAgNDIgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1ODAxMjk0MDEgIHcKcm9vdCAgICAgWG9yZyAgICAgICAgMTgzOSAgICAzIC91 c3IgICAgICAyNjI0NCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAg ICBYb3JnICAgICAgICAxODM5ICAgIDQgL2RldiAgICAgICAgIDU2IGNydy0tLS0tLS0gICB0dHl2 OCBydwpyb290ICAgICBYb3JnICAgICAgICAxODM5ICAgIDUgL2RldiAgICAgICAgICA5IGNydy1y LS1yLS0gICAgIHBjaSBydwpyb290ICAgICBYb3JnICAgICAgICAxODM5ICAgIDYgL2RldiAgICAg ICAgIDI1IGNydy1yLS0tLS0gICAgIG1lbSBydwpyb290ICAgICBYb3JnICAgICAgICAxODM5ICAg IDggL2RldiAgICAgICAgIDM1IGNydy1ydy1ydy0gIG52aWRpYWN0bCBydwpyb290ICAgICBYb3Jn ICAgICAgICAxODM5ICAgIDkgL2RldiAgICAgICAgIDM0IGNydy1ydy1ydy0gIG52aWRpYTAgcncK cm9vdCAgICAgWG9yZyAgICAgICAgMTgzOSAgIDEwIC9kZXYgICAgICAgICAzNCBjcnctcnctcnct ICBudmlkaWEwIHJ3CnJvb3QgICAgIFhvcmcgICAgICAgIDE4MzkgICAxMSAvZGV2ICAgICAgICAg MzQgY3J3LXJ3LXJ3LSAgbnZpZGlhMCBydwpyb290ICAgICBYb3JnICAgICAgICAxODM5ICAgMTIg L2RldiAgICAgICAgIDM0IGNydy1ydy1ydy0gIG52aWRpYTAgcncKcm9vdCAgICAgWG9yZyAgICAg ICAgMTgzOSAgIDEzIC9kZXYgICAgICAgICAzNCBjcnctcnctcnctICBudmlkaWEwIHJ3CnJvb3Qg ICAgIFhvcmcgICAgICAgIDE4MzkgICAxNCAvZGV2ICAgICAgICAgMzQgY3J3LXJ3LXJ3LSAgbnZp ZGlhMCBydwpyb290ICAgICBYb3JnICAgICAgICAxODM5ICAgMTUgL2RldiAgICAgICAgIDM0IGNy dy1ydy1ydy0gIG52aWRpYTAgcncKcm9vdCAgICAgWG9yZyAgICAgICAgMTgzOSAgIDE2IC9kZXYg ICAgICAgICAzNCBjcnctcnctcnctICBudmlkaWEwIHJ3CnJvb3QgICAgIFhvcmcgICAgICAgIDE4 MzkgICAyMCAvZGV2ICAgICAgICAgMzQgY3J3LXJ3LXJ3LSAgbnZpZGlhMCBydwpyb290ICAgICBY b3JnICAgICAgICAxODM5ICAgMjEgL2RldiAgICAgICAgIDM1IGNydy1ydy1ydy0gIG52aWRpYWN0 bCBydwpyb290ICAgICBYb3JnICAgICAgICAxODM5ICAgMjIgL2RldiAgICAgICAgIDM0IGNydy1y dy1ydy0gIG52aWRpYTAgcncKcm9vdCAgICAgWG9yZyAgICAgICAgMTgzOSAgIDIzIC9kZXYgICAg ICAgICAzNCBjcnctcnctcnctICBudmlkaWEwIHJ3CnJvb3QgICAgIFhvcmcgICAgICAgIDE4Mzkg ICAyNCogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDk2MjA2OTAgPC0+IGZmZmZmZTAwMDk2MjA3ODAK cm9vdCAgICAgWG9yZyAgICAgICAgMTgzOSAgIDI1KiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAyNzIx OGE1MCA8LT4gZmZmZmZlMDAyNzIxOGI0MApyb290ICAgICBYb3JnICAgICAgICAxODM5ICAgMjYq IGxvY2FsIHN0cmVhbSBmZmZmZmUwMDI3MjE4NjkwIDwtPiBmZmZmZmUwMDI3MjE4NzgwCnJvb3Qg ICAgIHNsaW0gICAgICAgIDE4MzYgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0 NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgc2xpbSAgICAgICAgMTgzNiAgIHdkIC8gICAg ICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBz bGltICAgICAgICAxODM2IHRleHQgL3VzciAgICAgIDE2NDM3ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIHNsaW0gICAgICAgIDE4MzYgICAgMCAtICAgICAgICAg LSAgICAgICAgIGJhZCAgICAtCnJvb3QgICAgIHNsaW0gICAgICAgIDE4MzYgICAgMSAvdmFyL2xv ZyAgICAgNDIgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHcKcm9vdCAgICAgc2xp bSAgICAgICAgMTgzNiAgICAyIC92YXIvbG9nICAgICA0MiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3 MTU4MDEyOTQwMSAgdwpyb290ICAgICBzbGltICAgICAgICAxODM2ICAgIDMqIGxvY2FsIHN0cmVh bSBmZmZmZmUwMDI3MjE4YjQwIDwtPiBmZmZmZmUwMDI3MjE4YTUwCnJvb3QgICAgIHNsaW0gICAg ICAgIDE4MzYgICAgNCogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMjcyMTg3ODAgPC0+IGZmZmZmZTAw MjcyMTg2OTAKZGhjcGQgICAgZGhjcGQgICAgICAgMTgwNSByb290IC8gICAgICAgICAgICAgNCA/ LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpkaGNwZCAgICBkaGNwZCAgICAgICAx ODA1ICAgd2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAx ICByCmRoY3BkICAgIGRoY3BkICAgICAgIDE4MDUgdGV4dCAvdXNyICAgICAyNTg4MDIgPy0tLS0t LS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKZGhjcGQgICAgZGhjcGQgICAgICAgMTgwNSAg ICAwIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAgIG51bGwgcncKZGhjcGQgICAgZGhjcGQg ICAgICAgMTgwNSAgICAxIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAgIG51bGwgcncKZGhj cGQgICAgZGhjcGQgICAgICAgMTgwNSAgICAyIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAg IG51bGwgcncKZGhjcGQgICAgZGhjcGQgICAgICAgMTgwNSAgICAzKiBsb2NhbCBkZ3JhbSBmZmZm ZmUwMDA5NWVmNGIwIDwtPiBmZmZmZmUwMDA5NWVmMmQwCmRoY3BkICAgIGRoY3BkICAgICAgIDE4 MDUgICAgNCogaW50ZXJuZXQgcmF3IGljbXAgZmZmZmZlMDAwOWJmNTMxMApkaGNwZCAgICBkaGNw ZCAgICAgICAxODA1ICAgIDUgL2RldiAgICAgICAgIDMxIGNydy1yLS0tLS0gICAgIGJwZiBydwpk aGNwZCAgICBkaGNwZCAgICAgICAxODA1ICAgIDYgL3Zhci9kYiAgIDI4NjczID8tLS0tLS0tLS0g IDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICB3CmRoY3BkICAgIGRoY3BkICAgICAgIDE4MDUgICAgNyog aW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZTAwMDk2MzIzMTAKZGhjcGQgICAgZGhjcGQgICAgICAg MTgwNSAgIDIwKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAwOTU2Y2FiOApkaGNwZCAgICBk aGNwZCAgICAgICAxODA1ICAgMjEqIGludGVybmV0NiBkZ3JhbSB1ZHAgZmZmZmZlMDAwOTYzMjAw MApyb290ICAgICBudHBkICAgICAgICAxNzQ4IHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0t LS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIG50cGQgICAgICAgIDE3NDggICB3 ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9v dCAgICAgbnRwZCAgICAgICAgMTc0OCB0ZXh0IC91c3IgICAgICAxOTkzMyA/LS0tLS0tLS0tICAx ODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBudHBkICAgICAgICAxNzQ4ICAgIDAgL2Rl diAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBudHBkICAgICAgICAx NzQ4ICAgIDEgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBu dHBkICAgICAgICAxNzQ4ICAgIDIgL2RldiAgICAgICAgICA3IGNydy1ydy1ydy0gICAgbnVsbCBy dwpyb290ICAgICBudHBkICAgICAgICAxNzQ4ICAgIDMqIGxvY2FsIGRncmFtIGZmZmZmZTAwMDk2 MjA0YjAgPC0+IGZmZmZmZTAwMDk1ZWYyZDAKcm9vdCAgICAgbnRwZCAgICAgICAgMTc0OCAgIDIw KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAwOTU2YzYyMApyb290ICAgICBudHBkICAgICAg ICAxNzQ4ICAgMjEqIGludGVybmV0NiBkZ3JhbSB1ZHAgZmZmZmZlMDAwOTU2YzdhOApyb290ICAg ICBudHBkICAgICAgICAxNzQ4ICAgMjIqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmUwMDA5NTZj OTMwCnJvb3QgICAgIG50cGQgICAgICAgIDE3NDggICAyMyogaW50ZXJuZXQgZGdyYW0gdWRwIGZm ZmZmZTAwMDk1NmNjNDAKcm9vdCAgICAgbnRwZCAgICAgICAgMTc0OCAgIDI0KiBpbnRlcm5ldDYg ZGdyYW0gdWRwIGZmZmZmZTAwMDk1NmNkYzgKcm9vdCAgICAgbnRwZCAgICAgICAgMTc0OCAgIDI1 KiBpbnRlcm5ldDYgZGdyYW0gdWRwIGZmZmZmZTAwMDk2MzIxODgKcm9vdCAgICAgbnRwZCAgICAg ICAgMTc0OCAgIDI2KiBpbnRlcm5ldDYgZGdyYW0gdWRwIGZmZmZmZTAwMDk2MzI3YTgKcm9vdCAg ICAgbnRwZCAgICAgICAgMTc0OCAgIDI3KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAwOTYz MjYyMApyb290ICAgICBudHBkICAgICAgICAxNzQ4ICAgMjgqIHJvdXRlIHJhdyAwIGZmZmZmZTAw MDlhZDZkNDgKcm9vdCAgICAgbnRwZCAgICAgICAgMTc0OCAgIDI5KiBpbnRlcm5ldDYgZGdyYW0g dWRwIGZmZmZmZTAwMjc2NmYxODgKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU3MyByb290IC8gICAg ICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBz eXNsb2dkICAgICAxNTczICAgd2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1NzMgdGV4dCAvdXNyICAgICAg MjQ3MjEgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgc3lzbG9n ZCAgICAgMTU3MyAgICAwIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAgIG51bGwgcncKcm9v dCAgICAgc3lzbG9nZCAgICAgMTU3MyAgICAxIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAg IG51bGwgcncKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU3MyAgICAyIC9kZXYgICAgICAgICAgNyBj cnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU3MyAgICAzIC92YXIv cnVuICAgICAzNiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgdwpyb290ICAgICBz eXNsb2dkICAgICAxNTczICAgIDQqIGxvY2FsIGRncmFtIGZmZmZmZTAwMDk1ZWYxZTAKcm9vdCAg ICAgc3lzbG9nZCAgICAgMTU3MyAgICA1KiBsb2NhbCBkZ3JhbSBmZmZmZmUwMDA5NWVmMmQwCnJv b3QgICAgIHN5c2xvZ2QgICAgIDE1NzMgICAgNiAvZGV2ICAgICAgICAgMTMgY3J3LS0tLS0tLSAg ICBrbG9nICByCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1NzMgICAgOCAtICAgICAgICAgLSAgICAg ICAgIGJhZCAgICAtCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1NzMgICAgOSAvdmFyL2xvZyAgICAg MzIgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHcKcm9vdCAgICAgc3lzbG9nZCAg ICAgMTU3MyAgIDEwIC92YXIvbG9nICAgICAyNyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEy OTQwMSAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNTczICAgMTEgL3Zhci9sb2cgICAgIDU2ID8t LS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICB3CnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1 NzMgICAxMiAvdmFyL2xvZyAgICAgMzkgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEg IHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU3MyAgIDEzIC92YXIvbG9nICAgICAyNSA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNTczICAg MTQgL3Zhci9sb2cgICAgIDUwID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICB3CnJv b3QgICAgIHN5c2xvZ2QgICAgIDE1NzMgICAxNSAvdmFyL2xvZyAgICAxMTYgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1ODAxMjk0MDEgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU3MyAgIDE2IC92 YXIvbG9nICAgICAzMCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgdwpyb290ICAg ICBzeXNsb2dkICAgICAxNTczICAgMTcgL3Zhci9sb2cgICAgIDcwID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTgwMTI5NDAxICB3Cl9kaGNwICAgIGRoY2xpZW50ICAgIDE0NTIgcm9vdCAvdmFyL2Vt cHR5ICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpfZGhjcCAgICBk aGNsaWVudCAgICAxNDUyICAgd2QgL3Zhci9lbXB0eSAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3 NDQwNzE1ODAxMjk0MDEgIHIKX2RoY3AgICAgZGhjbGllbnQgICAgMTQ1MiBqYWlsIC92YXIvZW1w dHkgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICByCl9kaGNwICAgIGRo Y2xpZW50ICAgIDE0NTIgdGV4dCAvICAgICAgICAgIDk2OTAgPy0tLS0tLS0tLSAgMTg0NDY3NDQw NzE1ODAxMjk0MDEgIHIKX2RoY3AgICAgZGhjbGllbnQgICAgMTQ1MiAgICAwIC9kZXYgICAgICAg ICAgNyBjcnctcnctcnctICAgIG51bGwgcncKX2RoY3AgICAgZGhjbGllbnQgICAgMTQ1MiAgICAx IC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAgIG51bGwgcncKX2RoY3AgICAgZGhjbGllbnQg ICAgMTQ1MiAgICAyIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAgIG51bGwgcncKX2RoY3Ag ICAgZGhjbGllbnQgICAgMTQ1MiAgICA0KiByb3V0ZSByYXcgMCBmZmZmZmUwMDA5NTg1N2Y4Cl9k aGNwICAgIGRoY2xpZW50ICAgIDE0NTIgICAgNSogcGlwZSBmZmZmZmUwMDA5N2QyOWUwIDwtPiBm ZmZmZmUwMDA5N2QyODg4ICAgICAgMCBydwpfZGhjcCAgICBkaGNsaWVudCAgICAxNDUyICAgIDYg L3Zhci9kYiAgIDI0NjEwID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICB3Cl9kaGNw ICAgIGRoY2xpZW50ICAgIDE0NTIgICAgNyAvZGV2ICAgICAgICAgMzEgY3J3LXItLS0tLSAgICAg YnBmIHJ3Cl9kaGNwICAgIGRoY2xpZW50ICAgIDE0NTIgICAgOCogaW50ZXJuZXQgcmF3IGlwIGZm ZmZmZTAwMDk5ZmYwMDAKcm9vdCAgICAgZGhjbGllbnQgICAgMTQxNCByb290IC8gICAgICAgICAg ICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBkaGNsaWVu dCAgICAxNDE0ICAgd2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgw MTI5NDAxICByCnJvb3QgICAgIGRoY2xpZW50ICAgIDE0MTQgdGV4dCAvICAgICAgICAgIDk2OTAg Py0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgZGhjbGllbnQgICAg MTQxNCAgICAwIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAg ZGhjbGllbnQgICAgMTQxNCAgICAxIC9kZXYgICAgICAgICAgNyBjcnctcnctcnctICAgIG51bGwg cncKcm9vdCAgICAgZGhjbGllbnQgICAgMTQxNCAgICAyIC9kZXYgICAgICAgICAgNyBjcnctcnct cnctICAgIG51bGwgcncKcm9vdCAgICAgZGhjbGllbnQgICAgMTQxNCAgICA0KiBwaXBlIGZmZmZm ZTAwMDk3ZDI4ODggPC0+IGZmZmZmZTAwMDk3ZDI5ZTAgICAgICAwIHJ3CnJvb3QgICAgIGRldmQg ICAgICAgIDEyNTQgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1 ODAxMjk0MDEgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMTI1NCAgIHdkIC8gICAgICAgICAgICAg NCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBkZXZkICAgICAg ICAxMjU0IHRleHQgLyAgICAgICAgICA5Njg2ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5 NDAxICByCnJvb3QgICAgIGRldmQgICAgICAgIDEyNTQgICAgMCAvZGV2ICAgICAgICAgIDcgY3J3 LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGRldmQgICAgICAgIDEyNTQgICAgMSAvZGV2ICAg ICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGRldmQgICAgICAgIDEyNTQg ICAgMiAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGRldmQg ICAgICAgIDEyNTQgICAgMyAvZGV2ICAgICAgICAgIDUgY3J3LS0tLS0tLSAgZGV2Y3RsICByCnJv b3QgICAgIGRldmQgICAgICAgIDEyNTQgICAgNCogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDk1ZWZh NTAKcm9vdCAgICAgZGV2ZCAgICAgICAgMTI1NCAgICA1IC92YXIvcnVuICAgICAzMCA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgdwpyb290ICAgICBkZXZkICAgICAgICAxMjU0ICAg IDYqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDA5NWVmOTYwIDwtPiBmZmZmZmUwMDA5NjIwMGYwCnJv b3QgICAgIG1vdXNlZCAgICAgIDEyMzYgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgbW91c2VkICAgICAgMTIzNiAgIHdkIC8g ICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAg ICBtb3VzZWQgICAgICAxMjM2IHRleHQgL3VzciAgICAgIDE5ODU2ID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIG1vdXNlZCAgICAgIDEyMzYgICAgMCAvZGV2ICAg ICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1vdXNlZCAgICAgIDEyMzYg ICAgMSAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1vdXNl ZCAgICAgIDEyMzYgICAgMiAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJv b3QgICAgIG1vdXNlZCAgICAgIDEyMzYgICAgMyAvZGV2ICAgICAgICAxNDggY3J3LXItLXItLSAg ICB1bXMxIHJ3CnJvb3QgICAgIG1vdXNlZCAgICAgIDEyMzYgICAgNCAvZGV2ICAgICAgICAgNjQg Y3J3LS0tLS0tLSAgY29uc29sZWN0bCBydwpyb290ICAgICBtb3VzZWQgICAgICAxMjM2ICAgIDUg L3Zhci9ydW4gICAgIDI5ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICB3CnJvb3Qg ICAgIG1vdXNlZCAgICAgIDEyMTMgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0 NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgbW91c2VkICAgICAgMTIxMyAgIHdkIC8gICAg ICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBt b3VzZWQgICAgICAxMjEzIHRleHQgL3VzciAgICAgIDE5ODU2ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTgwMTI5NDAxICByCnJvb3QgICAgIG1vdXNlZCAgICAgIDEyMTMgICAgMCAvZGV2ICAgICAg ICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1vdXNlZCAgICAgIDEyMTMgICAg MSAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1vdXNlZCAg ICAgIDEyMTMgICAgMiAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3Qg ICAgIG1vdXNlZCAgICAgIDEyMTMgICAgMyAvZGV2ICAgICAgICAxNDAgY3J3LXItLXItLSAgICB1 bXMwIHJ3CnJvb3QgICAgIG1vdXNlZCAgICAgIDEyMTMgICAgNCAvZGV2ICAgICAgICAgNjQgY3J3 LS0tLS0tLSAgY29uc29sZWN0bCBydwpyb290ICAgICBtb3VzZWQgICAgICAxMjEzICAgIDUgL3Zh ci9ydW4gICAgIDI4ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTgwMTI5NDAxICB3CnJvb3QgICAg IGFkamtlcm50eiAgICAxMzMgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3 NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgYWRqa2VybnR6ICAgIDEzMyAgIHdkIC8gICAgICAg ICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBhZGpr ZXJudHogICAgMTMzIHRleHQgLyAgICAgICAgICA5NjY0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcx NTgwMTI5NDAxICByCnJvb3QgICAgIGFkamtlcm50eiAgICAxMzMgICAgMCAvZGV2ICAgICAgICAg IDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGFkamtlcm50eiAgICAxMzMgICAgMSAv ZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGFkamtlcm50eiAg ICAxMzMgICAgMiAvZGV2ICAgICAgICAgIDcgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAg IGluaXQgICAgICAgICAgIDEgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3 NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSAgIHdkIC8gICAgICAg ICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEyOTQwMSAgcgpyb290ICAgICBpbml0 ICAgICAgICAgICAxIHRleHQgLyAgICAgICAgICA5NzY3ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcx NTgwMTI5NDAxICByCnJvb3QgICAgIGtlcm5lbCAgICAgICAgIDAgcm9vdCAvICAgICAgICAgICAg IDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1ODAxMjk0MDEgIHIKcm9vdCAgICAga2VybmVsICAg ICAgICAgMCAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU4MDEy OTQwMSAgcgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmRtZXNnCgozIExhdW5jaGVkIQpTTVA6IEFQIENQVSAj NSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzcgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMyIExhdW5j aGVkIQpTTVA6IEFQIENQVSAjNCBMYXVuY2hlZCEKVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1 ZW5jeSAxMzI1MTQyNiBIeiBxdWFsaXR5IDEwMDAKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5h YmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuCnVodWIxOiA0IHBvcnRzIHdpdGggNCBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMjogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMzIHVzYnVzMAp1aHViMzog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjA6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVz MyB1c2J1czAKdWdlbjAuMjogPHZlbmRvciAweDgwODc+IGF0IHVzYnVzMAp1Z2VuMy4yOiA8dmVu ZG9yIDB4ODA4Nz4gYXQgdXNidXMzCnVodWI0OiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4MDAy NCwgY2xhc3MgOS8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDI+IG9uIHVzYnVzMAp1aHViNTogPHZl bmRvciAweDgwODcgcHJvZHVjdCAweDAwMjQsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMCwgYWRk ciAyPiBvbiB1c2J1czMKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMzIHVzYnVzMAp1aHVi NDogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjU6IDggcG9ydHMg d2l0aCA4IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW4wLjM6IDx2ZW5kb3IgMHgwNGQ5PiBh dCB1c2J1czAKdWtiZDA6IDx2ZW5kb3IgMHgwNGQ5IGRhc2tleWJvYXJkLCBjbGFzcyAwLzAsIHJl diAxLjEwLzMuOTAsIGFkZHIgMz4gb24gdXNidXMwCmtiZDIgYXQgdWtiZDAKdW1zMDogPHZlbmRv ciAweDA0ZDkgZGFza2V5Ym9hcmQsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMy45MCwgYWRkciAzPiBv biB1c2J1czAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwCnVnZW4wLjQ6IDx2ZW5kb3Ig MHgwNWUzPiBhdCB1c2J1czAKdWh1YjY6IDx2ZW5kb3IgMHgwNWUzIFVTQjIuMCBIdWIsIGNsYXNz IDkvMCwgcmV2IDIuMDAvNzcuNjMsIGFkZHIgND4gb24gdXNidXMwCnVodWI2OiA0IHBvcnRzIHdp dGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1 czAKdWdlbjAuNTogPExvZ2l0ZWNoPiBhdCB1c2J1czAKdW1zMTogPExvZ2l0ZWNoIEc1MDAsIGNs YXNzIDAvMCwgcmV2IDIuMDAvNTguMDIsIGFkZHIgNT4gb24gdXNidXMwCnVtczE6IDE2IGJ1dHRv bnMgYW5kIFtYWVpUXSBjb29yZGluYXRlcyBJRD0wCnVrYmQxOiA8TG9naXRlY2ggRzUwMCwgY2xh c3MgMC8wLCByZXYgMi4wMC81OC4wMiwgYWRkciA1PiBvbiB1c2J1czAKa2JkMyBhdCB1a2JkMQp1 Z2VuMC42OiA8dmVuZG9yIDB4MDkxZT4gYXQgdXNidXMwClRyeWluZyB0byBtb3VudCByb290IGZy b20gemZzOnpyb290IFtdLi4uClNldHRpbmcgaG9zdHV1aWQ6IDAwMDAwMDAwLTAwMDAtMDAwMC0w MDAwLThjODlhNTZmNTI0Zi4KU2V0dGluZyBob3N0aWQ6IDB4NTFhNzYwZmMuCkVudHJvcHkgaGFy dmVzdGluZzogaW50ZXJydXB0cyBldGhlcm5ldCBwb2ludF90b19wb2ludCBraWNrc3RhcnQuClN0 YXJ0aW5nIGZpbGUgc3lzdGVtIGNoZWNrczoKL2Rldi9ncHQvYXJjaGl2ZTogRklMRSBTWVNURU0g Q0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2dwdC9hcmNoaXZlOiBjbGVhbiwgNTg1OTc5NjYg ZnJlZSAoODYgZnJhZ3MsIDczMjQ3MzUgYmxvY2tzLCAwLjAlIGZyYWdtZW50YXRpb24pCk1vdW50 aW5nIGxvY2FsIGZpbGUgc3lzdGVtczouClNldHRpbmcgaG9zdG5hbWU6IHBvc2VpZG9uLgpTdGFy dGluZyBOZXR3b3JrOiBsbzAgcmUwIHJlMSBwZmxvZzAgcGZzeW5jMC4KbG8wOiBmbGFncz04MDQ5 PFVQLExPT1BCQUNLLFJVTk5JTkcsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTYzODQKCW9wdGlv bnM9MzxSWENTVU0sVFhDU1VNPgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjggCglpbmV0NiBmZTgw OjoxJWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDkgCglpbmV0IDEyNy4wLjAuMSBuZXRtYXNr IDB4ZmYwMDAwMDAgCgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FMPgpy ZTA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1l dHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTM4OWI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFO X0hXVEFHR0lORyxWTEFOX0hXQ1NVTSxXT0xfVUNBU1QsV09MX01DQVNULFdPTF9NQUdJQz4KCWV0 aGVyIDAwOmUwOjRjOjc4OjIzOjRjCgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJM RUQsQVVUT19MSU5LTE9DQUw+CgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdCAobm9uZSkKCXN0 YXR1czogbm8gY2FycmllcgpyZTE6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lN UExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTM4OWI8UlhDU1VNLFRY Q1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lORyxWTEFOX0hXQ1NVTSxXT0xfVUNBU1QsV09MX01D QVNULFdPTF9NQUdJQz4KCWV0aGVyIDhjOjg5OmE1OjZmOjUyOjRmCglpbmV0IDEwLjMuMC4xIG5l dG1hc2sgMHhmZmZmMDAwMCBicm9hZGNhc3QgMTAuMy4yNTUuMjU1CglpbmV0NiBmZTgwOjo4ZTg5 OmE1ZmY6ZmU2Zjo1MjRmJXJlMSBwcmVmaXhsZW4gNjQgdGVudGF0aXZlIHNjb3BlaWQgMHg1IAoJ bmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJbWVk aWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKG5vbmUpCglzdGF0dXM6IG5vIGNhcnJpZXIKcGZsb2cw OiBmbGFncz0wPD4gbWV0cmljIDAgbXR1IDMzMTUyCgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVE LElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+CnBmc3luYzA6IGZsYWdzPTA8PiBtZXRyaWMgMCBt dHUgMTUwMAoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xP Q0FMPgoJc3luY3BlZXI6IDAuMC4wLjAgbWF4dXBkOiAxMjgKU3RhcnRpbmcgZGV2ZC4KU3RhcnRp bmcgTmV0d29yazogdXNidXMwLgpTdGFydGluZyBOZXR3b3JrOiB1c2J1czEuClN0YXJ0aW5nIE5l dHdvcms6IHVzYnVzMi4KU3RhcnRpbmcgTmV0d29yazogdXNidXMzLgpTdGFydGluZyBOZXR3b3Jr OiBwZmxvZzAuCnBmbG9nMDogZmxhZ3M9MDw+IG1ldHJpYyAwIG10dSAzMzE1MgoJbmQ2IG9wdGlv bnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgpTdGFydGluZyBOZXR3 b3JrOiBwZnN5bmMwLgpwZnN5bmMwOiBmbGFncz0wPD4gbWV0cmljIDAgbXR1IDE1MDAKCW5kNiBv cHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCXN5bmNwZWVy OiAwLjAuMC4wIG1heHVwZDogMTI4ClN0YXJ0aW5nIHVtczAgbW91c2VkLgpTdGFydGluZyB1bXMx IG1vdXNlZC4KRW5hYmxpbmcgcGYuCkFkZGl0aW9uYWwgaW5ldCByb3V0aW5nIG9wdGlvbnM6IGln bm9yZSBJQ01QIHJlZGlyZWN0PVlFUy4KYWRkIG5ldCA6OmZmZmY6MC4wLjAuMDogZ2F0ZXdheSA6 OjEKYWRkIG5ldCA6OjAuMC4wLjA6IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmU4MDo6OiBnYXRld2F5 IDo6MQphZGQgbmV0IGZmMDI6OjogZ2F0ZXdheSA6OjEKV2FpdGluZyAzMHMgZm9yIHRoZSBkZWZh dWx0IHJvdXRlIGludGVyZmFjZTogLi4ocmUwKQpFTEYgbGRjb25maWcgcGF0aDogL2xpYiAvdXNy L2xpYiAvdXNyL2xpYi9jb21wYXQgL3Vzci9sb2NhbC9saWIgL3Vzci9sb2NhbC9saWIvY29tcGF0 L3BrZyAvdXNyL2xvY2FsL2tkZTQvbGliIC91c3IvbG9jYWwvbGliL2V2ZW50MiAvdXNyL2xvY2Fs L2xpYi9nZWdsLTAuMSAvdXNyL2xvY2FsL2xpYi9ncmFwaHZpeiAvdXNyL2xvY2FsL2xpYi9saWJ4 dWwgL3Vzci9sb2NhbC9saWIvbnNzIC91c3IvbG9jYWwvbGliL3B0aCAvdXNyL2xvY2FsL2xpYi9x dDQgL3Vzci9sb2NhbC9saWIvdmlydHVhbGJveAozMi1iaXQgY29tcGF0aWJpbGl0eSBsZGNvbmZp ZyBwYXRoOiAvdXNyL2xpYjMyCkNyZWF0aW5nIGFuZC9vciB0cmltbWluZyBsb2cgZmlsZXMuClN0 YXJ0aW5nIHN5c2xvZ2QuCnNhdmVjb3JlOiAvZGV2L2FkYTNwMzogT3BlcmF0aW9uIG5vdCBwZXJt aXR0ZWQKTWF5IDIyIDE1OjE0OjAzIHBvc2VpZG9uIHNhdmVjb3JlOiAvZGV2L2FkYTNwMzogT3Bl cmF0aW9uIG5vdCBwZXJtaXR0ZWQKTm8gY29yZSBkdW1wcyBmb3VuZC4KQWRkaXRpb25hbCBBQkkg c3VwcG9ydDogbGludXguCkNsZWFyaW5nIC90bXAuClN0YXJ0aW5nIGZ1c2Vmcy4KZnVzZTRic2Q6 IHZlcnNpb24gMC4zLjktcHJlMSwgRlVTRSBBQkkgNy44ClN0YXJ0aW5nIG50cGQuClN0YXJ0aW5n IGRoY3BkLgpJbnRlcm5ldCBTeXN0ZW1zIENvbnNvcnRpdW0gREhDUCBTZXJ2ZXIgNC4yLjMtUDIK Q29weXJpZ2h0IDIwMDQtMjAxMiBJbnRlcm5ldCBTeXN0ZW1zIENvbnNvcnRpdW0uCkFsbCByaWdo dHMgcmVzZXJ2ZWQuCkZvciBpbmZvLCBwbGVhc2UgdmlzaXQgaHR0cHM6Ly93d3cuaXNjLm9yZy9z b2Z0d2FyZS9kaGNwLwpXcm90ZSAxIGxlYXNlcyB0byBsZWFzZXMgZmlsZS4KTGlzdGVuaW5nIG9u IEJQRi9yZTEvOGM6ODk6YTU6NmY6NTI6NGYvMTAuMy4wLjAvMTYKU2VuZGluZyBvbiAgIEJQRi9y ZTEvOGM6ODk6YTU6NmY6NTI6NGYvMTAuMy4wLjAvMTYKCk5vIHN1Ym5ldCBkZWNsYXJhdGlvbiBm b3IgcmUwICgxOTIuMTY4LjEuMTAxKS5NYXkgMjIgMTU6MTQ6MDMgcG9zZWlkb24gZGhjcGQ6IAoK KiogSWdub3JpbmcgcmVxdWVzdHMgb24gcmUwLiAgSWYgdGhpcyBpcyBub3Qgd2hhdAogICB5b3Ug d2FudCwgcGxlYXNlIHdyaXRlIGEgc3VibmV0IGRlY2xhcmF0aW9uCiAgIGluIHlvdXIgZGhjcGQu Y29uZiBmaWxlIGZvciB0aGUgbmV0d29yayBzZWdtZW50CiAgIHRvIHdoaWNoIGludGVyZmFjZSBy ZTAgaXMgYXR0YWNoZWQuICoqCgpNYXkgMjIgMTU6MTQ6MDMgcG9zZWlkb24gZGhjcGQ6IE5vIHN1 Ym5ldCBkZWNsYXJhdGlvbiBmb3IgcmUwICgxOTIuMTY4LjEuMTAxKS4KU2VuZGluZyBvbiAgIFNv Y2tldC9mYWxsYmFjay9mYWxsYmFjay1uZXQKTWF5IDIyIDE1OjE0OjAzIHBvc2VpZG9uIGRoY3Bk OiAqKiBJZ25vcmluZyByZXF1ZXN0cyBvbiByZTAuICBJZiB0aGlzIGlzIG5vdCB3aGF0Ck1heSAy MiAxNToxNDowMyBwb3NlaWRvbiBkaGNwZDogICAgeW91IHdhbnQsIHBsZWFzZSB3cml0ZSBhIHN1 Ym5ldCBkZWNsYXJhdGlvbgpNYXkgMjIgMTU6MTQ6MDMgcG9zZWlkb24gZGhjcGQ6ICAgIGluIHlv dXIgZGhjcGQuY29uZiBmaWxlIGZvciB0aGUgbmV0d29yayBzZWdtZW50Ck1heSAyMiAxNToxNDow MyBwb3NlaWRvbiBkaGNwZDogICAgdG8gd2hpY2ggaW50ZXJmYWNlIHJlMCBpcyBhdHRhY2hlZC4g KioKTWF5IDIyIDE1OjE0OjAzIHBvc2VpZG9uIGRoY3BkOiAKL2V0Yy9yYzogV0FSTklORzogJHN0 cm9uZ3N3YW5fZW5hYmxlIGlzIG5vdCBzZXQgcHJvcGVybHkgLSBzZWUgcmMuY29uZig1KS4KU3Rh cnRpbmcgc2xpbS4KU3RhcnRpbmcgZGJ1cy4KU3RhcnRpbmcgaGFsZC4KU3RhcnRpbmcgY3Vwc2Qu CkNvbmZpZ3VyaW5nIHN5c2NvbnM6IGJsYW5rdGltZS4KU3RhcnRpbmcgc3NoZC4KU3RhcnRpbmcg Y3Jvbi4KU3RhcnRpbmcgYmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3MgaW4gNjAgc2Vjb25k cy4KClR1ZSBNYXkgMjIgMTU6MTQ6MDQgRURUIDIwMTIKYWNxdWlyaW5nIGR1cGxpY2F0ZSBsb2Nr IG9mIHNhbWUgdHlwZTogIm9zLmxvY2tfbXR4IgogMXN0IG9zLmxvY2tfbXR4IEAgbnZpZGlhX29z LmM6ODcyCiAybmQgb3MubG9ja19tdHggQCBudmlkaWFfb3MuYzo4NzIKS0RCOiBzdGFjayBiYWNr dHJhY2U6CiMwIDB4ZmZmZmZmZmY4MDVlNDdlNCBhdCBrZGJfYmFja3RyYWNlKzB4NjQKIzEgMHhm ZmZmZmZmZjgwNWZmNTY0IGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MjQKIzIgMHhmZmZmZmZmZjgw NWZiYWU2IGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDUwNgojMyAweGZmZmZmZmZmODA1OTgxOTIg YXQgX210eF9sb2NrX2ZsYWdzKzB4MzIKIzQgMHhmZmZmZmZmZjgxYTMzYTNhIGF0IG9zX2FjcXVp cmVfc3BpbmxvY2srMHgxYQojNSAweGZmZmZmZmZmODFhMGI1MWIgYXQgX252MDE0NDU2cm0rMHg5 Ck1heSAyMiAxNToxNDoxOCBwb3NlaWRvbiBzdTogYWxleCB0byByb290IG9uIC9kZXYvdHR5djEK V0FSTklORzogcHNldWRvLXJhbmRvbSBudW1iZXIgZ2VuZXJhdG9yIHVzZWQgZm9yIElQc2VjIHBy b2Nlc3NpbmcKS2VybmVsIHBhZ2UgZmF1bHQgd2l0aCB0aGUgZm9sbG93aW5nIG5vbi1zbGVlcGFi bGUgbG9ja3MgaGVsZDoKc2hhcmVkIHJ3IGlwc2VjIHJlcXVlc3QgKGlwc2VjIHJlcXVlc3QpIHIg PSAwICgweGZmZmZmZTAwMzM1MDcwZTApIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9uZXRpcHNlYy94 Zm9ybV9lc3AuYzo5MzEKS0RCOiBzdGFjayBiYWNrdHJhY2U6CiMwIDB4ZmZmZmZmZmY4MDVlNDdl NCBhdCBrZGJfYmFja3RyYWNlKzB4NjQKIzEgMHhmZmZmZmZmZjgwNWZmNTY0IGF0IF93aXRuZXNz X2RlYnVnZ2VyKzB4MjQKIzIgMHhmZmZmZmZmZjgwNWZjZmMyIGF0IHdpdG5lc3Nfd2FybisweDQw MgojMyAweGZmZmZmZmZmODA4ZjlhMDcgYXQgdHJhcCsweDFmNwojNCAweGZmZmZmZmZmODA4ZTA4 MWYgYXQgY2FsbHRyYXArMHg4CiM1IDB4ZmZmZmZmZmY4MDgxOWY0ZiBhdCBjcnlwdG9fcmV0X3By b2MrMHgxNWYKIzYgMHhmZmZmZmZmZjgwNTc4YmZhIGF0IGZvcmtfZXhpdCsweGJhCiM3IDB4ZmZm ZmZmZmY4MDhlMGQ0ZSBhdCBmb3JrX3RyYW1wb2xpbmUrMHhlCgoKRmF0YWwgdHJhcCAxMjogcGFn ZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQpjcHVpZCA9IDA7IGFwaWMgaWQgPSAwMApmYXVs dCB2aXJ0dWFsIGFkZHJlc3MJPSAweDI4CmZhdWx0IGNvZGUJCT0gc3VwZXJ2aXNvciByZWFkIGRh dGEsIHBhZ2Ugbm90IHByZXNlbnQKaW5zdHJ1Y3Rpb24gcG9pbnRlcgk9IDB4MjA6MHhmZmZmZmZm ZjgwODA0MzRiCnN0YWNrIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmY4MDAwMmJiYjUw CmZyYW1lIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmY4MDAwMmJiYmIwCmNvZGUgc2Vn bWVudAkJPSBiYXNlIDB4MCwgbGltaXQgMHhmZmZmZiwgdHlwZSAweDFiCgkJCT0gRFBMIDAsIHBy ZXMgMSwgbG9uZyAxLCBkZWYzMiAwLCBncmFuIDEKcHJvY2Vzc29yIGVmbGFncwk9IGludGVycnVw dCBlbmFibGVkLCByZXN1bWUsIElPUEwgPSAwCmN1cnJlbnQgcHJvY2VzcwkJPSAzIChjcnlwdG8g cmV0dXJucykKdHJhcCBudW1iZXIJCT0gMTIKcGFuaWM6IHBhZ2UgZmF1bHQKY3B1aWQgPSAwCktE Qjogc3RhY2sgYmFja3RyYWNlOgojMCAweGZmZmZmZmZmODA1ZTQ3ZTQgYXQga2RiX2JhY2t0cmFj ZSsweDY0CiMxIDB4ZmZmZmZmZmY4MDVhYTQ0ZiBhdCBwYW5pYysweDIwZgojMiAweGZmZmZmZmZm ODA4ZmE5NDMgYXQgdHJhcF9mYXRhbCsweDRiMwojMyAweGZmZmZmZmZmODA4ZjlhMjggYXQgdHJh cCsweDIxOAojNCAweGZmZmZmZmZmODA4ZTA4MWYgYXQgY2FsbHRyYXArMHg4CiM1IDB4ZmZmZmZm ZmY4MDgxOWY0ZiBhdCBjcnlwdG9fcmV0X3Byb2MrMHgxNWYKIzYgMHhmZmZmZmZmZjgwNTc4YmZh IGF0IGZvcmtfZXhpdCsweGJhCiM3IDB4ZmZmZmZmZmY4MDhlMGQ0ZSBhdCBmb3JrX3RyYW1wb2xp bmUrMHhlClVwdGltZTogNDdzCkR1bXBpbmcgMjU4IG91dCBvZiA5ODkgTUI6Q29weXJpZ2h0IChj KSAxOTkyLTIwMTIgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgw LCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVn ZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVk LgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRh dGlvbi4KRnJlZUJTRCA5LjAtUkVMRUFTRS1wMSAjMTcgcjIzNTA5NTogVHVlIE1heSAyMiAxNTow MjoxNSBFRFQgMjAxMgogICAgYWxleEBwb3NlaWRvbjovdXNyL29iai91c3Ivc3JjL3N5cy9QT1NF SURPTiBhbWQ2NApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNl ZCBwZXJmb3JtYW5jZS4KQ1BVOiBJbnRlbChSKSBDb3JlKFRNKSBpNy0yNjAwIENQVSBAIDMuNDBH SHogKDMzOTIuMzctTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAg SWQgPSAweDIwNmE3ICBGYW1pbHkgPSA2ICBNb2RlbCA9IDJhICBTdGVwcGluZyA9IDcKICBGZWF0 dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxT RVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1Is U1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9MHgxN2JhZTNmZjxTU0UzLFBDTE1V TFFEUSxEVEVTNjQsTU9OLERTX0NQTCxWTVgsU01YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBE Q00sUENJRCxTU0U0LjEsU1NFNC4yLHgyQVBJQyxQT1BDTlQsVFNDRExULEFFU05JLFhTQVZFLEFW WD4KICBBTUQgRmVhdHVyZXM9MHgyODEwMDgwMDxTWVNDQUxMLE5YLFJEVFNDUCxMTT4KICBBTUQg RmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQsIHBlcmZvcm1hbmNl IHN0YXRpc3RpY3MKcmVhbCBtZW1vcnkgID0gMTcxNzk4NjkxODQgKDE2Mzg0IE1CKQphdmFpbCBt ZW1vcnkgPSA5OTQ1NDU2NjQgKDk0OCBNQikKRXZlbnQgdGltZXIgIkxBUElDIiBxdWFsaXR5IDYw MApBQ1BJIEFQSUMgVGFibGU6IDxBTEFTS0EgQSBNIEk+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nl c3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDggQ1BVcwpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHgg NCBjb3JlKHMpIHggMiBTTVQgdGhyZWFkcwogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEg KEFQKTogQVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJQyBJRDogIDIKIGNwdTMgKEFQKTogQVBJ QyBJRDogIDMKIGNwdTQgKEFQKTogQVBJQyBJRDogIDQKIGNwdTUgKEFQKTogQVBJQyBJRDogIDUK IGNwdTYgKEFQKTogQVBJQyBJRDogIDYKIGNwdTcgKEFQKTogQVBJQyBJRDogIDcKV0FSTklORzog VklNQUdFICh2aXJ0dWFsaXplZCBuZXR3b3JrIHN0YWNrKSBpcyBhIGhpZ2hseSBleHBlcmltZW50 YWwgZmVhdHVyZS4KaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2Fy ZAprYmQxIGF0IGtiZG11eDAKYWVzbmkwOiA8QUVTLUNCQyxBRVMtWFRTPiBvbiBtb3RoZXJib2Fy ZApjcnlwdG9zb2Z0MDogPHNvZnR3YXJlIGNyeXB0bz4gb24gbW90aGVyYm9hcmQKYWNwaTA6IDxB TEFTS0EgQSBNIEk+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpU aW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDkwMAph Y3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQw YiBvbiBhY3BpMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24g YWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkw CmNwdTQ6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1NTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU2 OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTc6IDxBQ1BJIENQVT4gb24gYWNwaTAKcGNpYjA6IDxB Q1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBh dCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKdmdhcGNp MDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHhlMDAwLTB4ZTA3ZiBtZW0gMHhmYTAw MDAwMC0weGZhZmZmZmZmLDB4ZDAwMDAwMDAtMHhkN2ZmZmZmZiwweGQ4MDAwMDAwLTB4ZDlmZmZm ZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMQpudmlkaWEwOiA8R2VGb3JjZSBHVCA0NDA+ IG9uIHZnYXBjaTAKdmdhcGNpMDogY2hpbGQgbnZpZGlhMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9p bwp2Z2FwY2kwOiBjaGlsZCBudmlkaWEwIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lvCmhkYWMwOiA8 TlZpZGlhIChVbmtub3duKSBIaWdoIERlZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4 ZmIwODAwMDAtMHhmYjA4M2ZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMSBvbiBwY2kxCnBjaTA6IDxz aW1wbGUgY29tbXM+IGF0IGRldmljZSAyMi4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmVoY2kwOiA8 RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmYjUwNzAwMC0weGZiNTA3 M2ZmIGlycSAxNiBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVzYnVzMDogRUhDSSB2ZXJzaW9uIDEu MAp1c2J1czA6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCmhk YWMxOiA8SW50ZWwgQ291Z2FyIFBvaW50IEhpZ2ggRGVmaW5pdGlvbiBBdWRpbyBDb250cm9sbGVy PiBtZW0gMHhmYjUwMDAwMC0weGZiNTAzZmZmIGlycSAyMiBhdCBkZXZpY2UgMjcuMCBvbiBwY2kw CnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC4wIG9uIHBj aTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBpcnEgMTggYXQgZGV2aWNlIDI4LjIgb24gcGNpMApwY2kzOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMwphaGNpMDogPE1hcnZlbGwgODhTRTkxMnggQUhDSSBTQVRBIGNvbnRyb2xsZXI+IHBv cnQgMHhkMDQwLTB4ZDA0NywweGQwMzAtMHhkMDMzLDB4ZDAyMC0weGQwMjcsMHhkMDEwLTB4ZDAx MywweGQwMDAtMHhkMDBmIG1lbSAweGZiNDEwMDAwLTB4ZmI0MTA3ZmYgaXJxIDE4IGF0IGRldmlj ZSAwLjAgb24gcGNpMwphaGNpMDogQUhDSSB2MS4yMCB3aXRoIDggNkdicHMgcG9ydHMsIFBvcnQg TXVsdGlwbGllciBub3Qgc3VwcG9ydGVkCmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5u ZWwgMCBvbiBhaGNpMAphaGNpY2gxOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gYWhj aTAKYWhjaWNoMjogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAyIG9uIGFoY2kwCmFoY2ljaDM6 IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMyBvbiBhaGNpMAphaGNpY2g0OiA8QUhDSSBjaGFu bmVsPiBhdCBjaGFubmVsIDQgb24gYWhjaTAKYWhjaWNoNTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hh bm5lbCA1IG9uIGFoY2kwCmFoY2ljaDY6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNiBvbiBh aGNpMAphaGNpY2g3OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDcgb24gYWhjaTAKcGNpYjQ6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTkgYXQgZGV2aWNlIDI4LjMgb24gcGNpMApwY2k0 OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNAp4aGNpMDogPFhIQ0kgKGdlbmVyaWMpIFVTQiAzLjAg Y29udHJvbGxlcj4gbWVtIDB4ZmIzMDAwMDAtMHhmYjMwMWZmZiBpcnEgMTkgYXQgZGV2aWNlIDAu MCBvbiBwY2k0CnhoY2kwOiAzMiBieXRlIGNvbnRleHQgc2l6ZS4KdXNidXMxIG9uIHhoY2kwCnBj aWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC40IG9uIHBjaTAK cGNpNTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKcGNpYjY6IDxQQ0ktUENJIGJyaWRnZT4gaXJx IDE2IGF0IGRldmljZSAwLjAgb24gcGNpNQpwY2k2OiA8UENJIGJ1cz4gb24gcGNpYjYKcmUwOiA8 UmVhbFRlayA4MTY5LzgxNjlTLzgxNjlTQihMKS84MTEwUy84MTEwU0IoTCkgR2lnYWJpdCBFdGhl cm5ldD4gcG9ydCAweGMwMDAtMHhjMGZmIG1lbSAweGZiMjIwMDAwLTB4ZmIyMjAwZmYgaXJxIDE2 IGF0IGRldmljZSAwLjAgb24gcGNpNgpyZTA6IENoaXAgcmV2LiAweDEwMDAwMDAwCnJlMDogTUFD IHJldi4gMHgwMDAwMDAwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24gcmUwCnJnZXBoeTA6IDxSVEw4 MTY5Uy84MTEwUy84MjExIDEwMDBCQVNFLVQgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBtaWli dXMwCnJnZXBoeTA6ICBub25lLCAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTBiYXNlVC1GRFgtZmxv dywgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDBiYXNlVFgtRkRYLWZsb3csIDEwMDBiYXNl VCwgMTAwMGJhc2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1tYXN0ZXIs IDEwMDBiYXNlVC1GRFgtZmxvdywgMTAwMGJhc2VULUZEWC1mbG93LW1hc3RlciwgYXV0bywgYXV0 by1mbG93CnJlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6ZTA6NGM6Nzg6MjM6NGMKcGNpYjc6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjUgb24gcGNpMApwY2k3OiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liNwp4aGNpMTogPFhIQ0kgKGdlbmVyaWMpIFVTQiAzLjAgY29u dHJvbGxlcj4gbWVtIDB4ZmIxMDAwMDAtMHhmYjEwMWZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBv biBwY2k3CnhoY2kxOiAzMiBieXRlIGNvbnRleHQgc2l6ZS4KdXNidXMyIG9uIHhoY2kxCnBjaWI4 OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE4IGF0IGRldmljZSAyOC42IG9uIHBjaTAKcGNp ODogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjgKcmUxOiA8UmVhbFRlayA4MTY4LzgxMTEgQi9DL0NQ L0QvRFAvRSBQQ0llIEdpZ2FiaXQgRXRoZXJuZXQ+IHBvcnQgMHhiMDAwLTB4YjBmZiBtZW0gMHhk YTEwNDAwMC0weGRhMTA0ZmZmLDB4ZGExMDAwMDAtMHhkYTEwM2ZmZiBpcnEgMTggYXQgZGV2aWNl IDAuMCBvbiBwY2k4CnJlMTogVXNpbmcgMSBNU0ktWCBtZXNzYWdlCnJlMTogQ2hpcCByZXYuIDB4 MmM4MDAwMDAKcmUxOiBNQUMgcmV2LiAweDAwMDAwMDAwCm1paWJ1czE6IDxNSUkgYnVzPiBvbiBy ZTEKcmdlcGh5MTogPFJUTDgxNjlTLzgxMTBTLzgyMTEgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZh Y2U+IFBIWSAxIG9uIG1paWJ1czEKcmdlcGh5MTogIG5vbmUsIDEwYmFzZVQsIDEwYmFzZVQtRkRY LCAxMGJhc2VULUZEWC1mbG93LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMGJhc2VUWC1G RFgtZmxvdywgMTAwMGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAxMDAw YmFzZVQtRkRYLW1hc3RlciwgMTAwMGJhc2VULUZEWC1mbG93LCAxMDAwYmFzZVQtRkRYLWZsb3ct bWFzdGVyLCBhdXRvLCBhdXRvLWZsb3cKcmUxOiBFdGhlcm5ldCBhZGRyZXNzOiA4Yzo4OTphNTo2 Zjo1Mjo0ZgplaGNpMTogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4 ZmI1MDYwMDAtMHhmYjUwNjNmZiBpcnEgMjMgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1c2J1czM6 IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMzOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9s bGVyPiBvbiBlaGNpMQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBw Y2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphaGNpMTogPEludGVsIENvdWdhciBQb2ludCBB SENJIFNBVEEgY29udHJvbGxlcj4gcG9ydCAweGYwNzAtMHhmMDc3LDB4ZjA2MC0weGYwNjMsMHhm MDUwLTB4ZjA1NywweGYwNDAtMHhmMDQzLDB4ZjAyMC0weGYwM2YgbWVtIDB4ZmI1MDUwMDAtMHhm YjUwNTdmZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphaGNpMTogQUhDSSB2MS4zMCB3 aXRoIDYgNkdicHMgcG9ydHMsIFBvcnQgTXVsdGlwbGllciBub3Qgc3VwcG9ydGVkCmFoY2ljaDg6 IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhaGNpMQphaGNpY2g5OiA8QUhDSSBjaGFu bmVsPiBhdCBjaGFubmVsIDEgb24gYWhjaTEKYWhjaWNoMTA6IDxBSENJIGNoYW5uZWw+IGF0IGNo YW5uZWwgMyBvbiBhaGNpMQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4z IChubyBkcml2ZXIgYXR0YWNoZWQpCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNw aTAKaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0w eGZlZDAwM2ZmIG9uIGFjcGkwClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAg SHogcXVhbGl0eSA5NTAKRXZlbnQgdGltZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBx dWFsaXR5IDU1MAp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYg aXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMAphdHRpbWVyMDogPEFUIHRpbWVyPiBwb3J0IDB4NDAt MHg0MyBpcnEgMCBvbiBhY3BpMApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgy IEh6IHF1YWxpdHkgMApFdmVudCB0aW1lciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1 YWxpdHkgMTAwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSBpcnEg OCBvbiBhY3BpMApFdmVudCB0aW1lciAiUlRDIiBmcmVxdWVuY3kgMzI3NjggSHogcXVhbGl0eSAw CnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwx NiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4g YXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMAphdGtiZGMw OiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBpc2Ew CmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0 a2JkMDogW0dJQU5ULUxPQ0tFRF0KY29yZXRlbXAwOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNv cnM+IG9uIGNwdTAKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4g b24gY3B1MApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MApj b3JldGVtcDE6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1MQplc3QxOiA8RW5o YW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxCnA0dGNjMTogPENQVSBG cmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxCmNvcmV0ZW1wMjogPENQVSBPbi1EaWUg VGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUyCmVzdDI6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTIKcDR0Y2MyOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRy b2w+IG9uIGNwdTIKY29yZXRlbXAzOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNw dTMKZXN0MzogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1Mwpw NHRjYzM6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1Mwpjb3JldGVtcDQ6 IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1NAplc3Q0OiA8RW5oYW5jZWQgU3Bl ZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHU0CnA0dGNjNDogPENQVSBGcmVxdWVuY3kg VGhlcm1hbCBDb250cm9sPiBvbiBjcHU0CmNvcmV0ZW1wNTogPENQVSBPbi1EaWUgVGhlcm1hbCBT ZW5zb3JzPiBvbiBjcHU1CmVzdDU6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRy b2w+IG9uIGNwdTUKcDR0Y2M1OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNw dTUKY29yZXRlbXA2OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTYKZXN0Njog PEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1NgpwNHRjYzY6IDxD UFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1Ngpjb3JldGVtcDc6IDxDUFUgT24t RGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1Nwplc3Q3OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZy ZXF1ZW5jeSBDb250cm9sPiBvbiBjcHU3CnA0dGNjNzogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBD b250cm9sPiBvbiBjcHU3ClpGUyBOT1RJQ0U6IFByZWZldGNoIGlzIGRpc2FibGVkIGJ5IGRlZmF1 bHQgaWYgbGVzcyB0aGFuIDRHQiBvZiBSQU0gaXMgcHJlc2VudDsKICAgICAgICAgICAgdG8gZW5h YmxlLCBhZGQgInZmcy56ZnMucHJlZmV0Y2hfZGlzYWJsZT0wIiB0byAvYm9vdC9sb2FkZXIuY29u Zi4KWkZTIGZpbGVzeXN0ZW0gdmVyc2lvbiA1ClpGUyBzdG9yYWdlIHBvb2wgdmVyc2lvbiAyOApU aW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCnZib3hkcnY6IGZBc3luYz0wIG9mZk1p bj0weDgzOCBvZmZNYXg9MHhhMTAKSVBzZWM6IEluaXRpYWxpemVkIFNlY3VyaXR5IEFzc29jaWF0 aW9uIFByb2Nlc3NpbmcuCmhkYWMwOiBIREEgQ29kZWMgIzA6IE5WaWRpYSAoVW5rbm93bikKaGRh YzA6IEhEQSBDb2RlYyAjMTogTlZpZGlhIChVbmtub3duKQpoZGFjMDogSERBIENvZGVjICMyOiBO VmlkaWEgKFVua25vd24pCmhkYWMwOiBIREEgQ29kZWMgIzM6IE5WaWRpYSAoVW5rbm93bikKcGNt MDogPEhEQSBOVmlkaWEgKFVua25vd24pIFBDTSAjMCBEaXNwbGF5UG9ydD4gYXQgY2FkIDAgbmlk IDEgb24gaGRhYzAKcGNtMTogPEhEQSBOVmlkaWEgKFVua25vd24pIFBDTSAjMCBEaXNwbGF5UG9y dD4gYXQgY2FkIDEgbmlkIDEgb24gaGRhYzAKcGNtMjogPEhEQSBOVmlkaWEgKFVua25vd24pIFBD TSAjMCBEaXNwbGF5UG9ydD4gYXQgY2FkIDIgbmlkIDEgb24gaGRhYzAKcGNtMzogPEhEQSBOVmlk aWEgKFVua25vd24pIFBDTSAjMCBEaXNwbGF5UG9ydD4gYXQgY2FkIDMgbmlkIDEgb24gaGRhYzAK aGRhYzE6IEhEQSBDb2RlYyAjMTogUmVhbHRlayBBTEM4OTIKcGNtNDogPEhEQSBSZWFsdGVrIEFM Qzg5MiBQQ00gIzAgQW5hbG9nPiBhdCBjYWQgMSBuaWQgMSBvbiBoZGFjMQpwY201OiA8SERBIFJl YWx0ZWsgQUxDODkyIFBDTSAjMSBBbmFsb2c+IGF0IGNhZCAxIG5pZCAxIG9uIGhkYWMxCnBjbTY6 IDxIREEgUmVhbHRlayBBTEM4OTIgUENNICMyIERpZ2l0YWw+IGF0IGNhZCAxIG5pZCAxIG9uIGhk YWMxCnBjbTc6IDxIREEgUmVhbHRlayBBTEM4OTIgUENNICMzIERpZ2l0YWw+IGF0IGNhZCAxIG5p ZCAxIG9uIGhkYWMxCnVzYnVzMDogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVzYnVzMTog NS4wR2JwcyBTdXBlciBTcGVlZCBVU0IgdjMuMAp1c2J1czI6IDUuMEdicHMgU3VwZXIgU3BlZWQg VVNCIHYzLjAKdXNidXMzOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdWdlbjAuMTogPElu dGVsPiBhdCB1c2J1czAKdWh1YjA6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6IDwweDEwMzM+IGF0IHVzYnVz MQp1aHViMTogPDB4MTAzMyBYSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAzLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDwweDEwMzM+IGF0IHVzYnVzMgp1aHViMjogPDB4 MTAzMyBYSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAzLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXMyCnVnZW4zLjE6IDxJbnRlbD4gYXQgdXNidXMzCnVodWIzOiA8SW50ZWwgRUhDSSByb290 IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMwphZGEwIGF0 IGFoY2ljaDAgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCmFkYTA6IDxNNC1DVDA2NE00U1NE MiAwMzA5PiBBVEEtOSBTQVRBIDMueCBkZXZpY2UKYWRhMDogNjAwLjAwME1CL3MgdHJhbnNmZXJz IChTQVRBIDMueCwgVURNQTUsIFBJTyA4MTkyYnl0ZXMpCmFkYTA6IENvbW1hbmQgUXVldWVpbmcg ZW5hYmxlZAphZGEwOiA2MTA1N01CICgxMjUwNDU0MjQgNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYz Uy9UIDE2MzgzQykKYWRhMDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ0CmFkYTEgYXQgYWhj aWNoOCBidXMgMCBzY2J1czggdGFyZ2V0IDAgbHVuIDAKYWRhMTogPFdEQyBXRDEwMDJGQUVYLTAw WTlBMCAwNS4wMUQwNT4gQVRBLTggU0FUQSAzLnggZGV2aWNlCmFkYTE6IDYwMC4wMDBNQi9zIHRy YW5zZmVycyAoU0FUQSAzLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGExOiBDb21tYW5kIFF1 ZXVlaW5nIGVuYWJsZWQKYWRhMTogOTUzODY5TUIgKDE5NTM1MjUxNjggNTEyIGJ5dGUgc2VjdG9y czogMTZIIDYzUy9UIDE2MzgzQykKYWRhMTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQyMAph ZGEyIGF0IGFoY2ljaDkgYnVzIDAgc2NidXM5IHRhcmdldCAwIGx1biAwCmFkYTI6IDxXREMgV0Qx MDAyRkFFWC0wMFozQTAgMDUuMDFEMDU+IEFUQS04IFNBVEEgMy54IGRldmljZQphZGEyOiA2MDAu MDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMy54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMjog Q29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTI6IDk1Mzg2OU1CICgxOTUzNTI1MTY4IDUxMiBi eXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTI6IFByZXZpb3VzbHkgd2FzIGtub3du IGFzIGFkMjIKYWRhMyBhdCBhaGNpY2gxMCBidXMgMCBzY2J1czEwIHRhcmdldCAwIGx1biAwCmFk YTM6IDxXREMgV0QzMjAwS1MtMDBQRkIwIDIxLjAwTTIxPiBBVEEtNyBTQVRBIDIueCBkZXZpY2UK YWRhMzogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0 ZXMpCmFkYTM6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEzOiAzMDUyNDVNQiAoNjI1MTQy NDQ4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTM6IFByZXZpb3VzbHkg d2FzIGtub3duIGFzIGFkMjQKcGFzczEgYXQgYWhjaWNoNyBidXMgMCBzY2J1czcgdGFyZ2V0IDAg bHVuIDAKcGFzczE6IDxNYXJ2ZWxsIDkxeHggQ29uZmlnIDEuMDE+IFJlbW92YWJsZSBQcm9jZXNz b3IgU0NTSS0wIGRldmljZSAKcGFzczE6IDE1MC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAxLngs IFVETUE0LCBBVEFQSSAxMmJ5dGVzLCBQSU8gODE5MmJ5dGVzKQpTTVA6IEFQIENQVSAjMSBMYXVu Y2hlZCEKU01QOiBBUCBDUFUgIzYgTGF1bmNoZWQhClNNUDogQVAgQ1BVICM1IExhdW5jaGVkIQpT TVA6IEFQIENQVSAjNyBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzIgTGF1bmNoZWQhClNNUDogQVAg Q1BVICM0IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMyBMYXVuY2hlZCEKVGltZWNvdW50ZXIgIlRT Qy1sb3ciIGZyZXF1ZW5jeSAxMzI1MTQ0MCBIeiBxdWFsaXR5IDEwMDAKV0FSTklORzogV0lUTkVT UyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuCnVodWIyOiA0IHBv cnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogNCBwb3J0cyB3aXRoIDQg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMzIHVz YnVzMAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjA6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGlu ZyBmb3I6IHVzYnVzMyB1c2J1czAKdWdlbjAuMjogPHZlbmRvciAweDgwODc+IGF0IHVzYnVzMAp1 Z2VuMy4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQgdXNidXMzCnVodWI0OiA8dmVuZG9yIDB4ODA4NyBw cm9kdWN0IDB4MDAyNCwgY2xhc3MgOS8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDI+IG9uIHVzYnVz MAp1aHViNTogPHZlbmRvciAweDgwODcgcHJvZHVjdCAweDAwMjQsIGNsYXNzIDkvMCwgcmV2IDIu MDAvMC4wMCwgYWRkciAyPiBvbiB1c2J1czMKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMz IHVzYnVzMAp1aHViNDogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1 YjU6IDggcG9ydHMgd2l0aCA4IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW4wLjM6IDx2ZW5k b3IgMHgwNGQ5PiBhdCB1c2J1czAKdWtiZDA6IDx2ZW5kb3IgMHgwNGQ5IGRhc2tleWJvYXJkLCBj bGFzcyAwLzAsIHJldiAxLjEwLzMuOTAsIGFkZHIgMz4gb24gdXNidXMwCmtiZDIgYXQgdWtiZDAK dW1zMDogPHZlbmRvciAweDA0ZDkgZGFza2V5Ym9hcmQsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMy45 MCwgYWRkciAzPiBvbiB1c2J1czAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwCnVnZW4w LjQ6IDx2ZW5kb3IgMHgwNWUzPiBhdCB1c2J1czAKdWh1YjY6IDx2ZW5kb3IgMHgwNWUzIFVTQjIu MCBIdWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvNzcuNjMsIGFkZHIgND4gb24gdXNidXMwCnVodWI2 OiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRp bmcgZm9yOiB1c2J1czAKdWdlbjAuNTogPExvZ2l0ZWNoPiBhdCB1c2J1czAKdW1zMTogPExvZ2l0 ZWNoIEc1MDAsIGNsYXNzIDAvMCwgcmV2IDIuMDAvNTguMDIsIGFkZHIgNT4gb24gdXNidXMwCnVt czE6IDE2IGJ1dHRvbnMgYW5kIFtYWVpUXSBjb29yZGluYXRlcyBJRD0wCnVrYmQxOiA8TG9naXRl Y2ggRzUwMCwgY2xhc3MgMC8wLCByZXYgMi4wMC81OC4wMiwgYWRkciA1PiBvbiB1c2J1czAKa2Jk MyBhdCB1a2JkMQp1Z2VuMC42OiA8dmVuZG9yIDB4MDkxZT4gYXQgdXNidXMwClRyeWluZyB0byBt b3VudCByb290IGZyb20gemZzOnpyb290IFtdLi4uClNldHRpbmcgaG9zdHV1aWQ6IDAwMDAwMDAw LTAwMDAtMDAwMC0wMDAwLThjODlhNTZmNTI0Zi4KU2V0dGluZyBob3N0aWQ6IDB4NTFhNzYwZmMu CkVudHJvcHkgaGFydmVzdGluZzogaW50ZXJydXB0cyBldGhlcm5ldCBwb2ludF90b19wb2ludCBr aWNrc3RhcnQuClN0YXJ0aW5nIGZpbGUgc3lzdGVtIGNoZWNrczoKL2Rldi9ncHQvYXJjaGl2ZTog RklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2dwdC9hcmNoaXZlOiBjbGVh biwgNTg1OTc5NjUgZnJlZSAoOTMgZnJhZ3MsIDczMjQ3MzQgYmxvY2tzLCAwLjAlIGZyYWdtZW50 YXRpb24pCk1vdW50aW5nIGxvY2FsIGZpbGUgc3lzdGVtczouClNldHRpbmcgaG9zdG5hbWU6IHBv c2VpZG9uLgpTdGFydGluZyBOZXR3b3JrOiBsbzAgcmUwIHJlMSBwZmxvZzAgcGZzeW5jMC4KbG8w OiBmbGFncz04MDQ5PFVQLExPT1BCQUNLLFJVTk5JTkcsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUg MTYzODQKCW9wdGlvbnM9MzxSWENTVU0sVFhDU1VNPgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjgg CglpbmV0NiBmZTgwOjoxJWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDkgCglpbmV0IDEyNy4w LjAuMSBuZXRtYXNrIDB4ZmYwMDAwMDAgCgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9f TElOS0xPQ0FMPgpyZTA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxN VUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTM4OWI8UlhDU1VNLFRYQ1NVTSxW TEFOX01UVSxWTEFOX0hXVEFHR0lORyxWTEFOX0hXQ1NVTSxXT0xfVUNBU1QsV09MX01DQVNULFdP TF9NQUdJQz4KCWV0aGVyIDAwOmUwOjRjOjc4OjIzOjRjCgluZDYgb3B0aW9ucz0yOTxQRVJGT1JN TlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+CgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVj dCAobm9uZSkKCXN0YXR1czogbm8gY2FycmllcgpyZTE6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNU LFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTM4 OWI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lORyxWTEFOX0hXQ1NVTSxXT0xf VUNBU1QsV09MX01DQVNULFdPTF9NQUdJQz4KCWV0aGVyIDhjOjg5OmE1OjZmOjUyOjRmCglpbmV0 IDEwLjMuMC4xIG5ldG1hc2sgMHhmZmZmMDAwMCBicm9hZGNhc3QgMTAuMy4yNTUuMjU1CglpbmV0 NiBmZTgwOjo4ZTg5OmE1ZmY6ZmU2Zjo1MjRmJXJlMSBwcmVmaXhsZW4gNjQgdGVudGF0aXZlIHNj b3BlaWQgMHg1IAoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElO S0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKG5vbmUpCglzdGF0dXM6IG5vIGNh cnJpZXIKcGZsb2cwOiBmbGFncz0wPD4gbWV0cmljIDAgbXR1IDMzMTUyCgluZDYgb3B0aW9ucz0y OTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+CnBmc3luYzA6IGZsYWdzPTA8 PiBtZXRyaWMgMCBtdHUgMTUwMAoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVE LEFVVE9fTElOS0xPQ0FMPgoJc3luY3BlZXI6IDAuMC4wLjAgbWF4dXBkOiAxMjgKU3RhcnRpbmcg ZGV2ZC4KU3RhcnRpbmcgTmV0d29yazogdXNidXMwLgpTdGFydGluZyBOZXR3b3JrOiB1c2J1czEu ClN0YXJ0aW5nIE5ldHdvcms6IHVzYnVzMi4KU3RhcnRpbmcgTmV0d29yazogdXNidXMzLgpTdGFy dGluZyBOZXR3b3JrOiBwZmxvZzAuCnBmbG9nMDogZmxhZ3M9MDw+IG1ldHJpYyAwIG10dSAzMzE1 MgoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgpT dGFydGluZyBOZXR3b3JrOiBwZnN5bmMwLgpwZnN5bmMwOiBmbGFncz0wPD4gbWV0cmljIDAgbXR1 IDE1MDAKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NB TD4KCXN5bmNwZWVyOiAwLjAuMC4wIG1heHVwZDogMTI4ClN0YXJ0aW5nIHVtczAgbW91c2VkLgpT dGFydGluZyB1bXMxIG1vdXNlZC4KRW5hYmxpbmcgcGYuCkFkZGl0aW9uYWwgaW5ldCByb3V0aW5n IG9wdGlvbnM6IGlnbm9yZSBJQ01QIHJlZGlyZWN0PVlFUy4KYWRkIG5ldCA6OmZmZmY6MC4wLjAu MDogZ2F0ZXdheSA6OjEKYWRkIG5ldCA6OjAuMC4wLjA6IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmU4 MDo6OiBnYXRld2F5IDo6MQphZGQgbmV0IGZmMDI6OjogZ2F0ZXdheSA6OjEKV2FpdGluZyAzMHMg Zm9yIHRoZSBkZWZhdWx0IHJvdXRlIGludGVyZmFjZTogLi4ocmUwKQpFTEYgbGRjb25maWcgcGF0 aDogL2xpYiAvdXNyL2xpYiAvdXNyL2xpYi9jb21wYXQgL3Vzci9sb2NhbC9saWIgL3Vzci9sb2Nh bC9saWIvY29tcGF0L3BrZyAvdXNyL2xvY2FsL2tkZTQvbGliIC91c3IvbG9jYWwvbGliL2V2ZW50 MiAvdXNyL2xvY2FsL2xpYi9nZWdsLTAuMSAvdXNyL2xvY2FsL2xpYi9ncmFwaHZpeiAvdXNyL2xv Y2FsL2xpYi9saWJ4dWwgL3Vzci9sb2NhbC9saWIvbnNzIC91c3IvbG9jYWwvbGliL3B0aCAvdXNy L2xvY2FsL2xpYi9xdDQgL3Vzci9sb2NhbC9saWIvdmlydHVhbGJveAozMi1iaXQgY29tcGF0aWJp bGl0eSBsZGNvbmZpZyBwYXRoOiAvdXNyL2xpYjMyCkNyZWF0aW5nIGFuZC9vciB0cmltbWluZyBs b2cgZmlsZXMuClN0YXJ0aW5nIHN5c2xvZ2QuCnNhdmVjb3JlOiAvZGV2L2FkYTNwMzogT3BlcmF0 aW9uIG5vdCBwZXJtaXR0ZWQKTWF5IDIyIDE1OjQzOjA4IHBvc2VpZG9uIHNhdmVjb3JlOiAvZGV2 L2FkYTNwMzogT3BlcmF0aW9uIG5vdCBwZXJtaXR0ZWQKTm8gY29yZSBkdW1wcyBmb3VuZC4KQWRk aXRpb25hbCBBQkkgc3VwcG9ydDogbGludXguCkNsZWFyaW5nIC90bXAuClN0YXJ0aW5nIGZ1c2Vm cy4KZnVzZTRic2Q6IHZlcnNpb24gMC4zLjktcHJlMSwgRlVTRSBBQkkgNy44ClN0YXJ0aW5nIG50 cGQuClN0YXJ0aW5nIGRoY3BkLgpJbnRlcm5ldCBTeXN0ZW1zIENvbnNvcnRpdW0gREhDUCBTZXJ2 ZXIgNC4yLjMtUDIKQ29weXJpZ2h0IDIwMDQtMjAxMiBJbnRlcm5ldCBTeXN0ZW1zIENvbnNvcnRp dW0uCkFsbCByaWdodHMgcmVzZXJ2ZWQuCkZvciBpbmZvLCBwbGVhc2UgdmlzaXQgaHR0cHM6Ly93 d3cuaXNjLm9yZy9zb2Z0d2FyZS9kaGNwLwpXcm90ZSAxIGxlYXNlcyB0byBsZWFzZXMgZmlsZS4K TGlzdGVuaW5nIG9uIEJQRi9yZTEvOGM6ODk6YTU6NmY6NTI6NGYvMTAuMy4wLjAvMTYKU2VuZGlu ZyBvbiAgIEJQRi9yZTEvOGM6ODk6YTU6NmY6NTI6NGYvMTAuMy4wLjAvMTYKCk5vIHN1Ym5ldCBk ZWNsYXJhdGlvbiBmb3IgcmUwICgxOTIuMTY4LjEuMTAxKS5NYXkgMjIgMTU6NDM6MDggcG9zZWlk b24gZGhjcGQ6IAoKKiogSWdub3JpbmcgcmVxdWVzdHMgb24gcmUwLiAgSWYgdGhpcyBpcyBub3Qg d2hhdAogICB5b3Ugd2FudCwgcGxlYXNlIHdyaXRlIGEgc3VibmV0IGRlY2xhcmF0aW9uCiAgIGlu IHlvdXIgZGhjcGQuY29uZiBmaWxlIGZvciB0aGUgbmV0d29yayBzZWdtZW50CiAgIHRvIHdoaWNo IGludGVyZmFjZSByZTAgaXMgYXR0YWNoZWQuICoqCgpNYXkgMjIgMTU6NDM6MDggcG9zZWlkb24g ZGhjcGQ6IE5vIHN1Ym5ldCBkZWNsYXJhdGlvbiBmb3IgcmUwICgxOTIuMTY4LjEuMTAxKS4KU2Vu ZGluZyBvbiAgIFNvY2tldC9mYWxsYmFjay9mYWxsYmFjay1uZXQKTWF5IDIyIDE1OjQzOjA4IHBv c2VpZG9uIGRoY3BkOiAqKiBJZ25vcmluZyByZXF1ZXN0cyBvbiByZTAuICBJZiB0aGlzIGlzIG5v dCB3aGF0Ck1heSAyMiAxNTo0MzowOCBwb3NlaWRvbiBkaGNwZDogICAgeW91IHdhbnQsIHBsZWFz ZSB3cml0ZSBhIHN1Ym5ldCBkZWNsYXJhdGlvbgpNYXkgMjIgMTU6NDM6MDggcG9zZWlkb24gZGhj cGQ6ICAgIGluIHlvdXIgZGhjcGQuY29uZiBmaWxlIGZvciB0aGUgbmV0d29yayBzZWdtZW50Ck1h eSAyMiAxNTo0MzowOCBwb3NlaWRvbiBkaGNwZDogICAgdG8gd2hpY2ggaW50ZXJmYWNlIHJlMCBp cyBhdHRhY2hlZC4gKioKTWF5IDIyIDE1OjQzOjA4IHBvc2VpZG9uIGRoY3BkOiAKL2V0Yy9yYzog V0FSTklORzogJHN0cm9uZ3N3YW5fZW5hYmxlIGlzIG5vdCBzZXQgcHJvcGVybHkgLSBzZWUgcmMu Y29uZig1KS4KU3RhcnRpbmcgc2xpbS4KU3RhcnRpbmcgZGJ1cy4KU3RhcnRpbmcgaGFsZC4KU3Rh cnRpbmcgY3Vwc2QuCkNvbmZpZ3VyaW5nIHN5c2NvbnM6IGJsYW5rdGltZS4KU3RhcnRpbmcgc3No ZC4KU3RhcnRpbmcgY3Jvbi4KU3RhcnRpbmcgYmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3Mg aW4gNjAgc2Vjb25kcy4KClR1ZSBNYXkgMjIgMTU6NDM6MDkgRURUIDIwMTIKYWNxdWlyaW5nIGR1 cGxpY2F0ZSBsb2NrIG9mIHNhbWUgdHlwZTogIm9zLmxvY2tfbXR4IgogMXN0IG9zLmxvY2tfbXR4 IEAgbnZpZGlhX29zLmM6ODcyCiAybmQgb3MubG9ja19tdHggQCBudmlkaWFfb3MuYzo4NzIKS0RC OiBzdGFjayBiYWNrdHJhY2U6CiMwIDB4ZmZmZmZmZmY4MDVlNDdlNCBhdCBrZGJfYmFja3RyYWNl KzB4NjQKIzEgMHhmZmZmZmZmZjgwNWZmNTY0IGF0IF93aXRuZXNzX2RlYnVnZ2VyKzB4MjQKIzIg MHhmZmZmZmZmZjgwNWZiYWU2IGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweDUwNgojMyAweGZmZmZm ZmZmODA1OTgxOTIgYXQgX210eF9sb2NrX2ZsYWdzKzB4MzIKIzQgMHhmZmZmZmZmZjgxYTMzYTNh IGF0IG9zX2FjcXVpcmVfc3BpbmxvY2srMHgxYQojNSAweGZmZmZmZmZmODFhMGI1MWIgYXQgX252 MDE0NDU2cm0rMHg5Ck1heSAyMiAxNTo0MzoyNiBwb3NlaWRvbiBzdTogYWxleCB0byByb290IG9u IC9kZXYvdHR5djIKS2VybmVsIHBhZ2UgZmF1bHQgd2l0aCB0aGUgZm9sbG93aW5nIG5vbi1zbGVl cGFibGUgbG9ja3MgaGVsZDoKc2hhcmVkIHJ3IGlwc2VjIHJlcXVlc3QgKGlwc2VjIHJlcXVlc3Qp IHIgPSAwICgweGZmZmZmZTAwMjYwZWY3NjApIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9uZXRpcHNl Yy94Zm9ybV9lc3AuYzo5MzEKS0RCOiBzdGFjayBiYWNrdHJhY2U6CiMwIDB4ZmZmZmZmZmY4MDVl NDdlNCBhdCBrZGJfYmFja3RyYWNlKzB4NjQKIzEgMHhmZmZmZmZmZjgwNWZmNTY0IGF0IF93aXRu ZXNzX2RlYnVnZ2VyKzB4MjQKIzIgMHhmZmZmZmZmZjgwNWZjZmMyIGF0IHdpdG5lc3Nfd2Fybisw eDQwMgojMyAweGZmZmZmZmZmODA4ZjlhMDcgYXQgdHJhcCsweDFmNwojNCAweGZmZmZmZmZmODA4 ZTA4MWYgYXQgY2FsbHRyYXArMHg4CiM1IDB4ZmZmZmZmZmY4MDgxOWY0ZiBhdCBjcnlwdG9fcmV0 X3Byb2MrMHgxNWYKIzYgMHhmZmZmZmZmZjgwNTc4YmZhIGF0IGZvcmtfZXhpdCsweGJhCiM3IDB4 ZmZmZmZmZmY4MDhlMGQ0ZSBhdCBmb3JrX3RyYW1wb2xpbmUrMHhlCgoKRmF0YWwgdHJhcCAxMjog cGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQpjcHVpZCA9IDI7IGFwaWMgaWQgPSAwMgpm YXVsdCB2aXJ0dWFsIGFkZHJlc3MJPSAweDI4CmZhdWx0IGNvZGUJCT0gc3VwZXJ2aXNvciByZWFk IGRhdGEsIHBhZ2Ugbm90IHByZXNlbnQKaW5zdHJ1Y3Rpb24gcG9pbnRlcgk9IDB4MjA6MHhmZmZm ZmZmZjgwODA0MzRiCnN0YWNrIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmY4MDAwMmJi YjUwCmZyYW1lIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmY4MDAwMmJiYmIwCmNvZGUg c2VnbWVudAkJPSBiYXNlIDB4MCwgbGltaXQgMHhmZmZmZiwgdHlwZSAweDFiCgkJCT0gRFBMIDAs IHByZXMgMSwgbG9uZyAxLCBkZWYzMiAwLCBncmFuIDEKcHJvY2Vzc29yIGVmbGFncwk9IGludGVy cnVwdCBlbmFibGVkLCByZXN1bWUsIElPUEwgPSAwCmN1cnJlbnQgcHJvY2VzcwkJPSAzIChjcnlw dG8gcmV0dXJucykKdHJhcCBudW1iZXIJCT0gMTIKcGFuaWM6IHBhZ2UgZmF1bHQKY3B1aWQgPSAy CktEQjogc3RhY2sgYmFja3RyYWNlOgojMCAweGZmZmZmZmZmODA1ZTQ3ZTQgYXQga2RiX2JhY2t0 cmFjZSsweDY0CiMxIDB4ZmZmZmZmZmY4MDVhYTQ0ZiBhdCBwYW5pYysweDIwZgojMiAweGZmZmZm ZmZmODA4ZmE5NDMgYXQgdHJhcF9mYXRhbCsweDRiMwojMyAweGZmZmZmZmZmODA4ZjlhMjggYXQg dHJhcCsweDIxOAojNCAweGZmZmZmZmZmODA4ZTA4MWYgYXQgY2FsbHRyYXArMHg4CiM1IDB4ZmZm ZmZmZmY4MDgxOWY0ZiBhdCBjcnlwdG9fcmV0X3Byb2MrMHgxNWYKIzYgMHhmZmZmZmZmZjgwNTc4 YmZhIGF0IGZvcmtfZXhpdCsweGJhCiM3IDB4ZmZmZmZmZmY4MDhlMGQ0ZSBhdCBmb3JrX3RyYW1w b2xpbmUrMHhlClVwdGltZTogNTZzCkR1bXBpbmcgMjU5IG91dCBvZiA5ODkgTUI6Q29weXJpZ2h0 IChjKSAxOTkyLTIwMTIgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAx OTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUg UmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2Vy dmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91 bmRhdGlvbi4KRnJlZUJTRCA5LjAtUkVMRUFTRS1wMSAjMTggcjIzNTA5NTogVHVlIE1heSAyMiAx NjowMTo0MyBFRFQgMjAxMgogICAgYWxleEBwb3NlaWRvbjovdXNyL29iai91c3Ivc3JjL3N5cy9Q T1NFSURPTiBhbWQ2NApDUFU6IEludGVsKFIpIENvcmUoVE0pIGk3LTI2MDAgQ1BVIEAgMy40MEdI eiAoMzM5Mi4zNy1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJ ZCA9IDB4MjA2YTcgIEZhbWlseSA9IDYgIE1vZGVsID0gMmEgIFN0ZXBwaW5nID0gNwogIEZlYXR1 cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNF UCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixT U0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDE3YmFlM2ZmPFNTRTMsUENMTVVM UURRLERURVM2NCxNT04sRFNfQ1BMLFZNWCxTTVgsRVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERD TSxQQ0lELFNTRTQuMSxTU0U0LjIseDJBUElDLFBPUENOVCxUU0NETFQsQUVTTkksWFNBVkUsQVZY PgogIEFNRCBGZWF0dXJlcz0weDI4MTAwODAwPFNZU0NBTEwsTlgsUkRUU0NQLExNPgogIEFNRCBG ZWF0dXJlczI9MHgxPExBSEY+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFudCwgcGVyZm9ybWFuY2Ug c3RhdGlzdGljcwpyZWFsIG1lbW9yeSAgPSAxNzE3OTg2OTE4NCAoMTYzODQgTUIpCmF2YWlsIG1l bW9yeSA9IDk5NTQ3OTU1MiAoOTQ5IE1CKQpFdmVudCB0aW1lciAiTEFQSUMiIHF1YWxpdHkgNjAw CkFDUEkgQVBJQyBUYWJsZTogPEFMQVNLQSBBIE0gST4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vz c29yIFN5c3RlbSBEZXRlY3RlZDogOCBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2UocykgeCA0 IGNvcmUocykgeCAyIFNNVCB0aHJlYWRzCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAo QVApOiBBUElDIElEOiAgMQogY3B1MiAoQVApOiBBUElDIElEOiAgMgogY3B1MyAoQVApOiBBUElD IElEOiAgMwogY3B1NCAoQVApOiBBUElDIElEOiAgNAogY3B1NSAoQVApOiBBUElDIElEOiAgNQog Y3B1NiAoQVApOiBBUElDIElEOiAgNgogY3B1NyAoQVApOiBBUElDIElEOiAgNwpXQVJOSU5HOiBW SU1BR0UgKHZpcnR1YWxpemVkIG5ldHdvcmsgc3RhY2spIGlzIGEgaGlnaGx5IGV4cGVyaW1lbnRh bCBmZWF0dXJlLgppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJk CmtiZDEgYXQga2JkbXV4MAphZXNuaTA6IDxBRVMtQ0JDLEFFUy1YVFM+IG9uIG1vdGhlcmJvYXJk CmNyeXB0b3NvZnQwOiA8c29mdHdhcmUgY3J5cHRvPiBvbiBtb3RoZXJib2FyZAphY3BpMDogPEFM QVNLQSBBIE0gST4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpClRp bWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgOTAwCmFj cGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBi IG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBh Y3BpMApjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTAK Y3B1NDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU1OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTY6 IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1NzogPEFDUEkgQ1BVPiBvbiBhY3BpMApwY2liMDogPEFD UEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0 IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQp2Z2FwY2kw OiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweGUwMDAtMHhlMDdmIG1lbSAweGZhMDAw MDAwLTB4ZmFmZmZmZmYsMHhkMDAwMDAwMC0weGQ3ZmZmZmZmLDB4ZDgwMDAwMDAtMHhkOWZmZmZm ZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCm52aWRpYTA6IDxHZUZvcmNlIEdUIDQ0MD4g b24gdmdhcGNpMAp2Z2FwY2kwOiBjaGlsZCBudmlkaWEwIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lv CnZnYXBjaTA6IGNoaWxkIG52aWRpYTAgcmVxdWVzdGVkIHBjaV9lbmFibGVfaW8KaGRhYzA6IDxO VmlkaWEgKFVua25vd24pIEhpZ2ggRGVmaW5pdGlvbiBBdWRpbyBDb250cm9sbGVyPiBtZW0gMHhm YjA4MDAwMC0weGZiMDgzZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4xIG9uIHBjaTEKcGNpMDogPHNp bXBsZSBjb21tcz4gYXQgZGV2aWNlIDIyLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKZWhjaTA6IDxF SENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGZiNTA3MDAwLTB4ZmI1MDcz ZmYgaXJxIDE2IGF0IGRldmljZSAyNi4wIG9uIHBjaTAKdXNidXMwOiBFSENJIHZlcnNpb24gMS4w CnVzYnVzMDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKaGRh YzE6IDxJbnRlbCBDb3VnYXIgUG9pbnQgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXI+ IG1lbSAweGZiNTAwMDAwLTB4ZmI1MDNmZmYgaXJxIDIyIGF0IGRldmljZSAyNy4wIG9uIHBjaTAK cGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjAgb24gcGNp MApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2liMzogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGlycSAxOCBhdCBkZXZpY2UgMjguMiBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIzCmFoY2kwOiA8TWFydmVsbCA4OFNFOTEyeCBBSENJIFNBVEEgY29udHJvbGxlcj4gcG9y dCAweGQwNDAtMHhkMDQ3LDB4ZDAzMC0weGQwMzMsMHhkMDIwLTB4ZDAyNywweGQwMTAtMHhkMDEz LDB4ZDAwMC0weGQwMGYgbWVtIDB4ZmI0MTAwMDAtMHhmYjQxMDdmZiBpcnEgMTggYXQgZGV2aWNl IDAuMCBvbiBwY2kzCmFoY2kwOiBBSENJIHYxLjIwIHdpdGggOCA2R2JwcyBwb3J0cywgUG9ydCBN dWx0aXBsaWVyIG5vdCBzdXBwb3J0ZWQKYWhjaWNoMDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5l bCAwIG9uIGFoY2kwCmFoY2ljaDE6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMSBvbiBhaGNp MAphaGNpY2gyOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDIgb24gYWhjaTAKYWhjaWNoMzog PEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAzIG9uIGFoY2kwCmFoY2ljaDQ6IDxBSENJIGNoYW5u ZWw+IGF0IGNoYW5uZWwgNCBvbiBhaGNpMAphaGNpY2g1OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFu bmVsIDUgb24gYWhjaTAKYWhjaWNoNjogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA2IG9uIGFo Y2kwCmFoY2ljaDc6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNyBvbiBhaGNpMApwY2liNDog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxOSBhdCBkZXZpY2UgMjguMyBvbiBwY2kwCnBjaTQ6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnhoY2kwOiA8WEhDSSAoZ2VuZXJpYykgVVNCIDMuMCBj b250cm9sbGVyPiBtZW0gMHhmYjMwMDAwMC0weGZiMzAxZmZmIGlycSAxOSBhdCBkZXZpY2UgMC4w IG9uIHBjaTQKeGhjaTA6IDMyIGJ5dGUgY29udGV4dCBzaXplLgp1c2J1czEgb24geGhjaTAKcGNp YjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjQgb24gcGNpMApw Y2k1OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpwY2liNjogPFBDSS1QQ0kgYnJpZGdlPiBpcnEg MTYgYXQgZGV2aWNlIDAuMCBvbiBwY2k1CnBjaTY6IDxQQ0kgYnVzPiBvbiBwY2liNgpyZTA6IDxS ZWFsVGVrIDgxNjkvODE2OVMvODE2OVNCKEwpLzgxMTBTLzgxMTBTQihMKSBHaWdhYml0IEV0aGVy bmV0PiBwb3J0IDB4YzAwMC0weGMwZmYgbWVtIDB4ZmIyMjAwMDAtMHhmYjIyMDBmZiBpcnEgMTYg YXQgZGV2aWNlIDAuMCBvbiBwY2k2CnJlMDogQ2hpcCByZXYuIDB4MTAwMDAwMDAKcmUwOiBNQUMg cmV2LiAweDAwMDAwMDAwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiByZTAKcmdlcGh5MDogPFJUTDgx NjlTLzgxMTBTLzgyMTEgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1 czAKcmdlcGh5MDogIG5vbmUsIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMGJhc2VULUZEWC1mbG93 LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMGJhc2VUWC1GRFgtZmxvdywgMTAwMGJhc2VU LCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAxMDAwYmFzZVQtRkRYLW1hc3Rlciwg MTAwMGJhc2VULUZEWC1mbG93LCAxMDAwYmFzZVQtRkRYLWZsb3ctbWFzdGVyLCBhdXRvLCBhdXRv LWZsb3cKcmUwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDplMDo0Yzo3ODoyMzo0YwpwY2liNzogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMjguNSBvbiBwY2kwCnBjaTc6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWI3CnhoY2kxOiA8WEhDSSAoZ2VuZXJpYykgVVNCIDMuMCBjb250 cm9sbGVyPiBtZW0gMHhmYjEwMDAwMC0weGZiMTAxZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9u IHBjaTcKeGhjaTE6IDMyIGJ5dGUgY29udGV4dCBzaXplLgp1c2J1czIgb24geGhjaTEKcGNpYjg6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTggYXQgZGV2aWNlIDI4LjYgb24gcGNpMApwY2k4 OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liOApyZTE6IDxSZWFsVGVrIDgxNjgvODExMSBCL0MvQ1Av RC9EUC9FIFBDSWUgR2lnYWJpdCBFdGhlcm5ldD4gcG9ydCAweGIwMDAtMHhiMGZmIG1lbSAweGRh MTA0MDAwLTB4ZGExMDRmZmYsMHhkYTEwMDAwMC0weGRhMTAzZmZmIGlycSAxOCBhdCBkZXZpY2Ug MC4wIG9uIHBjaTgKcmUxOiBVc2luZyAxIE1TSS1YIG1lc3NhZ2UKcmUxOiBDaGlwIHJldi4gMHgy YzgwMDAwMApyZTE6IE1BQyByZXYuIDB4MDAwMDAwMDAKbWlpYnVzMTogPE1JSSBidXM+IG9uIHJl MQpyZ2VwaHkxOiA8UlRMODE2OVMvODExMFMvODIxMSAxMDAwQkFTRS1UIG1lZGlhIGludGVyZmFj ZT4gUEhZIDEgb24gbWlpYnVzMQpyZ2VwaHkxOiAgbm9uZSwgMTBiYXNlVCwgMTBiYXNlVC1GRFgs IDEwYmFzZVQtRkRYLWZsb3csIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwYmFzZVRYLUZE WC1mbG93LCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIsIDEwMDBiYXNlVC1GRFgsIDEwMDBi YXNlVC1GRFgtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLWZsb3csIDEwMDBiYXNlVC1GRFgtZmxvdy1t YXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpyZTE6IEV0aGVybmV0IGFkZHJlc3M6IDhjOjg5OmE1OjZm OjUyOjRmCmVoY2kxOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhm YjUwNjAwMC0weGZiNTA2M2ZmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVzYnVzMzog RUhDSSB2ZXJzaW9uIDEuMAp1c2J1czM6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xs ZXI+IG9uIGVoY2kxCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBj aTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmFoY2kxOiA8SW50ZWwgQ291Z2FyIFBvaW50IEFI Q0kgU0FUQSBjb250cm9sbGVyPiBwb3J0IDB4ZjA3MC0weGYwNzcsMHhmMDYwLTB4ZjA2MywweGYw NTAtMHhmMDU3LDB4ZjA0MC0weGYwNDMsMHhmMDIwLTB4ZjAzZiBtZW0gMHhmYjUwNTAwMC0weGZi NTA1N2ZmIGlycSAxOSBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCmFoY2kxOiBBSENJIHYxLjMwIHdp dGggNiA2R2JwcyBwb3J0cywgUG9ydCBNdWx0aXBsaWVyIG5vdCBzdXBwb3J0ZWQKYWhjaWNoODog PEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAwIG9uIGFoY2kxCmFoY2ljaDk6IDxBSENJIGNoYW5u ZWw+IGF0IGNoYW5uZWwgMSBvbiBhaGNpMQphaGNpY2gxMDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hh bm5lbCAzIG9uIGFoY2kxCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMg KG5vIGRyaXZlciBhdHRhY2hlZCkKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3Bp MApocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4 ZmVkMDAzZmYgb24gYWNwaTAKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBI eiBxdWFsaXR5IDk1MApFdmVudCB0aW1lciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1 YWxpdHkgNTUwCnVhcnQwOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNmOC0weDNmZiBp cnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCmF0dGltZXIwOiA8QVQgdGltZXI+IHBvcnQgMHg0MC0w eDQzIGlycSAwIG9uIGFjcGkwClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIg SHogcXVhbGl0eSAwCkV2ZW50IHRpbWVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVh bGl0eSAxMDAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4 IG9uIGFjcGkwCkV2ZW50IHRpbWVyICJSVEMiIGZyZXF1ZW5jeSAzMjc2OCBIeiBxdWFsaXR5IDAK c2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBh dCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCmF0a2JkYzA6 IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0IG9uIGlzYTAK YXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRr YmQwOiBbR0lBTlQtTE9DS0VEXQpjb3JldGVtcDA6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29y cz4gb24gY3B1MAplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBv biBjcHUwCnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwCmNv cmV0ZW1wMTogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUxCmVzdDE6IDxFbmhh bmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEKcDR0Y2MxOiA8Q1BVIEZy ZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKY29yZXRlbXAyOiA8Q1BVIE9uLURpZSBU aGVybWFsIFNlbnNvcnM+IG9uIGNwdTIKZXN0MjogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVu Y3kgQ29udHJvbD4gb24gY3B1MgpwNHRjYzI6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJv bD4gb24gY3B1Mgpjb3JldGVtcDM6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1 Mwplc3QzOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUzCnA0 dGNjMzogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUzCmNvcmV0ZW1wNDog PENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHU0CmVzdDQ6IDxFbmhhbmNlZCBTcGVl ZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTQKcDR0Y2M0OiA8Q1BVIEZyZXF1ZW5jeSBU aGVybWFsIENvbnRyb2w+IG9uIGNwdTQKY29yZXRlbXA1OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNl bnNvcnM+IG9uIGNwdTUKZXN0NTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJv bD4gb24gY3B1NQpwNHRjYzU6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1 NQpjb3JldGVtcDY6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1Ngplc3Q2OiA8 RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHU2CnA0dGNjNjogPENQ VSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHU2CmNvcmV0ZW1wNzogPENQVSBPbi1E aWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHU3CmVzdDc6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJl cXVlbmN5IENvbnRyb2w+IG9uIGNwdTcKcDR0Y2M3OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENv bnRyb2w+IG9uIGNwdTcKWkZTIE5PVElDRTogUHJlZmV0Y2ggaXMgZGlzYWJsZWQgYnkgZGVmYXVs dCBpZiBsZXNzIHRoYW4gNEdCIG9mIFJBTSBpcyBwcmVzZW50OwogICAgICAgICAgICB0byBlbmFi bGUsIGFkZCAidmZzLnpmcy5wcmVmZXRjaF9kaXNhYmxlPTAiIHRvIC9ib290L2xvYWRlci5jb25m LgpaRlMgZmlsZXN5c3RlbSB2ZXJzaW9uIDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uIDI4ClRp bWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdmJveGRydjogZkFzeW5jPTAgb2ZmTWlu PTB4ODVjIG9mZk1heD0weGE4NApJUHNlYzogSW5pdGlhbGl6ZWQgU2VjdXJpdHkgQXNzb2NpYXRp b24gUHJvY2Vzc2luZy4KaGRhYzA6IEhEQSBDb2RlYyAjMDogTlZpZGlhIChVbmtub3duKQpoZGFj MDogSERBIENvZGVjICMxOiBOVmlkaWEgKFVua25vd24pCmhkYWMwOiBIREEgQ29kZWMgIzI6IE5W aWRpYSAoVW5rbm93bikKaGRhYzA6IEhEQSBDb2RlYyAjMzogTlZpZGlhIChVbmtub3duKQpwY20w OiA8SERBIE5WaWRpYSAoVW5rbm93bikgUENNICMwIERpc3BsYXlQb3J0PiBhdCBjYWQgMCBuaWQg MSBvbiBoZGFjMApwY20xOiA8SERBIE5WaWRpYSAoVW5rbm93bikgUENNICMwIERpc3BsYXlQb3J0 PiBhdCBjYWQgMSBuaWQgMSBvbiBoZGFjMApwY20yOiA8SERBIE5WaWRpYSAoVW5rbm93bikgUENN ICMwIERpc3BsYXlQb3J0PiBhdCBjYWQgMiBuaWQgMSBvbiBoZGFjMApwY20zOiA8SERBIE5WaWRp YSAoVW5rbm93bikgUENNICMwIERpc3BsYXlQb3J0PiBhdCBjYWQgMyBuaWQgMSBvbiBoZGFjMApo ZGFjMTogSERBIENvZGVjICMxOiBSZWFsdGVrIEFMQzg5MgpwY200OiA8SERBIFJlYWx0ZWsgQUxD ODkyIFBDTSAjMCBBbmFsb2c+IGF0IGNhZCAxIG5pZCAxIG9uIGhkYWMxCnBjbTU6IDxIREEgUmVh bHRlayBBTEM4OTIgUENNICMxIEFuYWxvZz4gYXQgY2FkIDEgbmlkIDEgb24gaGRhYzEKcGNtNjog PEhEQSBSZWFsdGVrIEFMQzg5MiBQQ00gIzIgRGlnaXRhbD4gYXQgY2FkIDEgbmlkIDEgb24gaGRh YzEKcGNtNzogPEhEQSBSZWFsdGVrIEFMQzg5MiBQQ00gIzMgRGlnaXRhbD4gYXQgY2FkIDEgbmlk IDEgb24gaGRhYzEKdXNidXMwOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdXNidXMxOiA1 LjBHYnBzIFN1cGVyIFNwZWVkIFVTQiB2My4wCnVzYnVzMjogNS4wR2JwcyBTdXBlciBTcGVlZCBV U0IgdjMuMAp1c2J1czM6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuMC4xOiA8SW50 ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2 IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPDB4MTAzMz4gYXQgdXNidXMx CnVodWIxOiA8MHgxMDMzIFhIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDMuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2J1czEKdWdlbjIuMTogPDB4MTAzMz4gYXQgdXNidXMyCnVodWIyOiA8MHgx MDMzIFhIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDMuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMKdWh1YjM6IDxJbnRlbCBFSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzCmFkYTAgYXQg YWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKYWRhMDogPE00LUNUMDY0TTRTU0Qy IDAzMDk+IEFUQS05IFNBVEEgMy54IGRldmljZQphZGEwOiA2MDAuMDAwTUIvcyB0cmFuc2ZlcnMg KFNBVEEgMy54LCBVRE1BNSwgUElPIDgxOTJieXRlcykKYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBl bmFibGVkCmFkYTA6IDYxMDU3TUIgKDEyNTA0NTQyNCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNT L1QgMTYzODNDKQphZGEwOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDQKYWRhMSBhdCBhaGNp Y2g4IGJ1cyAwIHNjYnVzOCB0YXJnZXQgMCBsdW4gMAphZGExOiA8V0RDIFdEMTAwMkZBRVgtMDBZ OUEwIDA1LjAxRDA1PiBBVEEtOCBTQVRBIDMueCBkZXZpY2UKYWRhMTogNjAwLjAwME1CL3MgdHJh bnNmZXJzIChTQVRBIDMueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTE6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZAphZGExOiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIgYnl0ZSBzZWN0b3Jz OiAxNkggNjNTL1QgMTYzODNDKQphZGExOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDIwCmFk YTIgYXQgYWhjaWNoOSBidXMgMCBzY2J1czkgdGFyZ2V0IDAgbHVuIDAKYWRhMjogPFdEQyBXRDEw MDJGQUVYLTAwWjNBMCAwNS4wMUQwNT4gQVRBLTggU0FUQSAzLnggZGV2aWNlCmFkYTI6IDYwMC4w MDBNQi9zIHRyYW5zZmVycyAoU0FUQSAzLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGEyOiBD b21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhMjogOTUzODY5TUIgKDE5NTM1MjUxNjggNTEyIGJ5 dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhMjogUHJldmlvdXNseSB3YXMga25vd24g YXMgYWQyMgphZGEzIGF0IGFoY2ljaDEwIGJ1cyAwIHNjYnVzMTAgdGFyZ2V0IDAgbHVuIDAKYWRh MzogPFdEQyBXRDMyMDBLUy0wMFBGQjAgMjEuMDBNMjE+IEFUQS03IFNBVEEgMi54IGRldmljZQph ZGEzOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRl cykKYWRhMzogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTM6IDMwNTI0NU1CICg2MjUxNDI0 NDggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhMzogUHJldmlvdXNseSB3 YXMga25vd24gYXMgYWQyNApwYXNzMSBhdCBhaGNpY2g3IGJ1cyAwIHNjYnVzNyB0YXJnZXQgMCBs dW4gMApwYXNzMTogPE1hcnZlbGwgOTF4eCBDb25maWcgMS4wMT4gUmVtb3ZhYmxlIFByb2Nlc3Nv ciBTQ1NJLTAgZGV2aWNlIApwYXNzMTogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwg VURNQTQsIEFUQVBJIDEyYnl0ZXMsIFBJTyA4MTkyYnl0ZXMpClNNUDogQVAgQ1BVICMxIExhdW5j aGVkIQpTTVA6IEFQIENQVSAjNiBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzIgTGF1bmNoZWQhClNN UDogQVAgQ1BVICM0IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNyBMYXVuY2hlZCEKU01QOiBBUCBD UFUgIzUgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpUaW1lY291bnRlciAiVFND LWxvdyIgZnJlcXVlbmN5IDEzMjUxNDQxIEh6IHF1YWxpdHkgMTAwMAp1aHViMjogNCBwb3J0cyB3 aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjE6IDQgcG9ydHMgd2l0aCA0IHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMyB1c2J1czAK dWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIzOiAyIHBv cnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9y OiB1c2J1czMgdXNidXMwCnVnZW4zLjI6IDx2ZW5kb3IgMHg4MDg3PiBhdCB1c2J1czMKdWdlbjAu MjogPHZlbmRvciAweDgwODc+IGF0IHVzYnVzMAp1aHViNDogPHZlbmRvciAweDgwODcgcHJvZHVj dCAweDAwMjQsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMCwgYWRkciAyPiBvbiB1c2J1czMKdWh1 YjU6IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgwMDI0LCBjbGFzcyA5LzAsIHJldiAyLjAwLzAu MDAsIGFkZHIgMj4gb24gdXNidXMwClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMyB1c2J1 czAKdWh1YjU6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI0OiA4 IHBvcnRzIHdpdGggOCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuMC4zOiA8dmVuZG9yIDB4 MDRkOT4gYXQgdXNidXMwCnVrYmQwOiA8dmVuZG9yIDB4MDRkOSBkYXNrZXlib2FyZCwgY2xhc3Mg MC8wLCByZXYgMS4xMC8zLjkwLCBhZGRyIDM+IG9uIHVzYnVzMAprYmQyIGF0IHVrYmQwCnVtczA6 IDx2ZW5kb3IgMHgwNGQ5IGRhc2tleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzMuOTAsIGFk ZHIgMz4gb24gdXNidXMwClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMAp1Z2VuMC40OiA8 dmVuZG9yIDB4MDVlMz4gYXQgdXNidXMwCnVodWI2OiA8dmVuZG9yIDB4MDVlMyBVU0IyLjAgSHVi LCBjbGFzcyA5LzAsIHJldiAyLjAwLzc3LjYzLCBhZGRyIDQ+IG9uIHVzYnVzMAp1aHViNjogNCBw b3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZv cjogdXNidXMwCnVnZW4wLjU6IDxMb2dpdGVjaD4gYXQgdXNidXMwCnVtczE6IDxMb2dpdGVjaCBH NTAwLCBjbGFzcyAwLzAsIHJldiAyLjAwLzU4LjAyLCBhZGRyIDU+IG9uIHVzYnVzMAp1bXMxOiAx NiBidXR0b25zIGFuZCBbWFlaVF0gY29vcmRpbmF0ZXMgSUQ9MAp1a2JkMTogPExvZ2l0ZWNoIEc1 MDAsIGNsYXNzIDAvMCwgcmV2IDIuMDAvNTguMDIsIGFkZHIgNT4gb24gdXNidXMwCmtiZDMgYXQg dWtiZDEKdWdlbjAuNjogPHZlbmRvciAweDA5MWU+IGF0IHVzYnVzMApUcnlpbmcgdG8gbW91bnQg cm9vdCBmcm9tIHpmczp6cm9vdCBbXS4uLgpTZXR0aW5nIGhvc3R1dWlkOiAwMDAwMDAwMC0wMDAw LTAwMDAtMDAwMC04Yzg5YTU2ZjUyNGYuClNldHRpbmcgaG9zdGlkOiAweDUxYTc2MGZjLgpFbnRy b3B5IGhhcnZlc3Rpbmc6IGludGVycnVwdHMgZXRoZXJuZXQgcG9pbnRfdG9fcG9pbnQga2lja3N0 YXJ0LgpTdGFydGluZyBmaWxlIHN5c3RlbSBjaGVja3M6Ci9kZXYvZ3B0L2FyY2hpdmU6IEZJTEUg U1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVDS1MKL2Rldi9ncHQvYXJjaGl2ZTogY2xlYW4sIDU4 NTk3OTY1IGZyZWUgKDkzIGZyYWdzLCA3MzI0NzM0IGJsb2NrcywgMC4wJSBmcmFnbWVudGF0aW9u KQpNb3VudGluZyBsb2NhbCBmaWxlIHN5c3RlbXM6LgpTZXR0aW5nIGhvc3RuYW1lOiBwb3NlaWRv bi4KU3RhcnRpbmcgTmV0d29yazogbG8wIHJlMCByZTEgcGZsb2cwIHBmc3luYzAuCmxvMDogZmxh Z3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE2Mzg0 CglvcHRpb25zPTM8UlhDU1VNLFRYQ1NVTT4KCWluZXQ2IDo6MSBwcmVmaXhsZW4gMTI4IAoJaW5l dDYgZmU4MDo6MSVsbzAgcHJlZml4bGVuIDY0IHNjb3BlaWQgMHg5IAoJaW5ldCAxMjcuMC4wLjEg bmV0bWFzayAweGZmMDAwMDAwIAoJbmQ2IG9wdGlvbnM9MjE8UEVSRk9STU5VRCxBVVRPX0xJTktM T0NBTD4KcmUwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElD QVNUPiBtZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz0zODliPFJYQ1NVTSxUWENTVU0sVkxBTl9N VFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sV09MX1VDQVNULFdPTF9NQ0FTVCxXT0xfTUFH SUM+CglldGhlciAwMDplMDo0Yzo3ODoyMzo0YwoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJ RkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKG5v bmUpCglzdGF0dXM6IG5vIGNhcnJpZXIKcmUxOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5O SU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz0zODliPFJY Q1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sV09MX1VDQVNU LFdPTF9NQ0FTVCxXT0xfTUFHSUM+CglldGhlciA4Yzo4OTphNTo2Zjo1Mjo0ZgoJaW5ldCAxMC4z LjAuMSBuZXRtYXNrIDB4ZmZmZjAwMDAgYnJvYWRjYXN0IDEwLjMuMjU1LjI1NQoJaW5ldDYgZmU4 MDo6OGU4OTphNWZmOmZlNmY6NTI0ZiVyZTEgcHJlZml4bGVuIDY0IHRlbnRhdGl2ZSBzY29wZWlk IDB4NSAKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NB TD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0IChub25lKQoJc3RhdHVzOiBubyBjYXJyaWVy CnBmbG9nMDogZmxhZ3M9MDw+IG1ldHJpYyAwIG10dSAzMzE1MgoJbmQ2IG9wdGlvbnM9Mjk8UEVS Rk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgpwZnN5bmMwOiBmbGFncz0wPD4gbWV0 cmljIDAgbXR1IDE1MDAKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRP X0xJTktMT0NBTD4KCXN5bmNwZWVyOiAwLjAuMC4wIG1heHVwZDogMTI4ClN0YXJ0aW5nIGRldmQu ClN0YXJ0aW5nIE5ldHdvcms6IHVzYnVzMC4KU3RhcnRpbmcgTmV0d29yazogdXNidXMxLgpTdGFy dGluZyBOZXR3b3JrOiB1c2J1czIuClN0YXJ0aW5nIE5ldHdvcms6IHVzYnVzMy4KU3RhcnRpbmcg TmV0d29yazogcGZsb2cwLgpwZmxvZzA6IGZsYWdzPTA8PiBtZXRyaWMgMCBtdHUgMzMxNTIKCW5k NiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KU3RhcnRp bmcgTmV0d29yazogcGZzeW5jMC4KcGZzeW5jMDogZmxhZ3M9MDw+IG1ldHJpYyAwIG10dSAxNTAw CgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+Cglz eW5jcGVlcjogMC4wLjAuMCBtYXh1cGQ6IDEyOApTdGFydGluZyB1bXMwIG1vdXNlZC4KU3RhcnRp bmcgdW1zMSBtb3VzZWQuCkVuYWJsaW5nIHBmLgpBZGRpdGlvbmFsIGluZXQgcm91dGluZyBvcHRp b25zOiBpZ25vcmUgSUNNUCByZWRpcmVjdD1ZRVMuCmFkZCBuZXQgOjpmZmZmOjAuMC4wLjA6IGdh dGV3YXkgOjoxCmFkZCBuZXQgOjowLjAuMC4wOiBnYXRld2F5IDo6MQphZGQgbmV0IGZlODA6Ojog Z2F0ZXdheSA6OjEKYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxCldhaXRpbmcgMzBzIGZvciB0 aGUgZGVmYXVsdCByb3V0ZSBpbnRlcmZhY2U6IC4uKHJlMCkKRUxGIGxkY29uZmlnIHBhdGg6IC9s aWIgL3Vzci9saWIgL3Vzci9saWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGli L2NvbXBhdC9wa2cgL3Vzci9sb2NhbC9rZGU0L2xpYiAvdXNyL2xvY2FsL2xpYi9ldmVudDIgL3Vz ci9sb2NhbC9saWIvZ2VnbC0wLjEgL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXogL3Vzci9sb2NhbC9s aWIvbGlieHVsIC91c3IvbG9jYWwvbGliL25zcyAvdXNyL2xvY2FsL2xpYi9wdGggL3Vzci9sb2Nh bC9saWIvcXQ0IC91c3IvbG9jYWwvbGliL3ZpcnR1YWxib3gKMzItYml0IGNvbXBhdGliaWxpdHkg bGRjb25maWcgcGF0aDogL3Vzci9saWIzMgpDcmVhdGluZyBhbmQvb3IgdHJpbW1pbmcgbG9nIGZp bGVzLgpTdGFydGluZyBzeXNsb2dkLgpzYXZlY29yZTogL2Rldi9hZGEzcDM6IE9wZXJhdGlvbiBu b3QgcGVybWl0dGVkCk1heSAyMiAxNjowNDoxNyBwb3NlaWRvbiBzYXZlY29yZTogL2Rldi9hZGEz cDM6IE9wZXJhdGlvbiBub3QgcGVybWl0dGVkCk5vIGNvcmUgZHVtcHMgZm91bmQuCkFkZGl0aW9u YWwgQUJJIHN1cHBvcnQ6IGxpbnV4LgpDbGVhcmluZyAvdG1wLgpTdGFydGluZyBmdXNlZnMuCmZ1 c2U0YnNkOiB2ZXJzaW9uIDAuMy45LXByZTEsIEZVU0UgQUJJIDcuOApTdGFydGluZyBudHBkLgpT dGFydGluZyBkaGNwZC4KSW50ZXJuZXQgU3lzdGVtcyBDb25zb3J0aXVtIERIQ1AgU2VydmVyIDQu Mi4zLVAyCkNvcHlyaWdodCAyMDA0LTIwMTIgSW50ZXJuZXQgU3lzdGVtcyBDb25zb3J0aXVtLgpB bGwgcmlnaHRzIHJlc2VydmVkLgpGb3IgaW5mbywgcGxlYXNlIHZpc2l0IGh0dHBzOi8vd3d3Lmlz Yy5vcmcvc29mdHdhcmUvZGhjcC8KV3JvdGUgMSBsZWFzZXMgdG8gbGVhc2VzIGZpbGUuCkxpc3Rl bmluZyBvbiBCUEYvcmUxLzhjOjg5OmE1OjZmOjUyOjRmLzEwLjMuMC4wLzE2ClNlbmRpbmcgb24g ICBCUEYvcmUxLzhjOjg5OmE1OjZmOjUyOjRmLzEwLjMuMC4wLzE2CgpObyBzdWJuZXQgZGVjbGFy YXRpb24gZm9yIHJlMCAoMTkyLjE2OC4xLjEwMSkuTWF5IDIyIDE2OjA0OjE3IHBvc2VpZG9uIGRo Y3BkOiAKCioqIElnbm9yaW5nIHJlcXVlc3RzIG9uIHJlMC4gIElmIHRoaXMgaXMgbm90IHdoYXQK ICAgeW91IHdhbnQsIHBsZWFzZSB3cml0ZSBhIHN1Ym5ldCBkZWNsYXJhdGlvbgogICBpbiB5b3Vy IGRoY3BkLmNvbmYgZmlsZSBmb3IgdGhlIG5ldHdvcmsgc2VnbWVudAogICB0byB3aGljaCBpbnRl cmZhY2UgcmUwIGlzIGF0dGFjaGVkLiAqKgoKTWF5IDIyIDE2OjA0OjE3IHBvc2VpZG9uIGRoY3Bk OiBObyBzdWJuZXQgZGVjbGFyYXRpb24gZm9yIHJlMCAoMTkyLjE2OC4xLjEwMSkuClNlbmRpbmcg b24gICBTb2NrZXQvZmFsbGJhY2svZmFsbGJhY2stbmV0Ck1heSAyMiAxNjowNDoxNyBwb3NlaWRv biBkaGNwZDogKiogSWdub3JpbmcgcmVxdWVzdHMgb24gcmUwLiAgSWYgdGhpcyBpcyBub3Qgd2hh dApNYXkgMjIgMTY6MDQ6MTcgcG9zZWlkb24gZGhjcGQ6ICAgIHlvdSB3YW50LCBwbGVhc2Ugd3Jp dGUgYSBzdWJuZXQgZGVjbGFyYXRpb24KTWF5IDIyIDE2OjA0OjE3IHBvc2VpZG9uIGRoY3BkOiAg ICBpbiB5b3VyIGRoY3BkLmNvbmYgZmlsZSBmb3IgdGhlIG5ldHdvcmsgc2VnbWVudApNYXkgMjIg MTY6MDQ6MTcgcG9zZWlkb24gZGhjcGQ6ICAgIHRvIHdoaWNoIGludGVyZmFjZSByZTAgaXMgYXR0 YWNoZWQuICoqCk1heSAyMiAxNjowNDoxNyBwb3NlaWRvbiBkaGNwZDogCi9ldGMvcmM6IFdBUk5J Tkc6ICRzdHJvbmdzd2FuX2VuYWJsZSBpcyBub3Qgc2V0IHByb3Blcmx5IC0gc2VlIHJjLmNvbmYo NSkuClN0YXJ0aW5nIHNsaW0uClN0YXJ0aW5nIGRidXMuClN0YXJ0aW5nIGhhbGQuClN0YXJ0aW5n IGN1cHNkLgpDb25maWd1cmluZyBzeXNjb25zOiBibGFua3RpbWUuClN0YXJ0aW5nIHNzaGQuClN0 YXJ0aW5nIGNyb24uClN0YXJ0aW5nIGJhY2tncm91bmQgZmlsZSBzeXN0ZW0gY2hlY2tzIGluIDYw IHNlY29uZHMuCgpUdWUgTWF5IDIyIDE2OjA0OjE4IEVEVCAyMDEyCk1heSAyMiAxNjowNDozOCBw b3NlaWRvbiBzdTogYWxleCB0byByb290IG9uIC9kZXYvdHR5djEKTWF5IDIyIDE2OjA0OjQ3IHBv c2VpZG9uIG50cGRbMTc0OF06IGJpbmQoKSBmZCAzMCwgZmFtaWx5IEFGX0lORVQ2LCBwb3J0IDEy Mywgc2NvcGUgMTAsIGFkZHIgZmU4MDo6MmUwOjRjZmY6ZmU3ODoyMzRjLCBtY2FzdD0wIGZsYWdz PTB4MTMgZmFpbHM6IENhbid0IGFzc2lnbiByZXF1ZXN0ZWQgYWRkcmVzcwpNYXkgMjIgMTY6MDQ6 NDcgcG9zZWlkb24gbnRwZFsxNzQ4XTogdW5hYmxlIHRvIGNyZWF0ZSBzb2NrZXQgb24gZ2lmMCAo OSkgZm9yIGZlODA6OjJlMDo0Y2ZmOmZlNzg6MjM0YyMxMjMKCgpGYXRhbCB0cmFwIDEyOiBwYWdl IGZhdWx0IHdoaWxlIGluIGtlcm5lbCBtb2RlCmNwdWlkID0gMjsgYXBpYyBpZCA9IDAyCmZhdWx0 IHZpcnR1YWwgYWRkcmVzcwk9IDB4MjgKZmF1bHQgY29kZQkJPSBzdXBlcnZpc29yIHJlYWQgZGF0 YSwgcGFnZSBub3QgcHJlc2VudAppbnN0cnVjdGlvbiBwb2ludGVyCT0gMHgyMDoweGZmZmZmZmZm ODA4OTdkNDcKc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgwMDAyYmJiMzAK ZnJhbWUgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgwMDAyYmJiOTAKY29kZSBzZWdt ZW50CQk9IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0eXBlIDB4MWIKCQkJPSBEUEwgMCwgcHJl cyAxLCBsb25nIDEsIGRlZjMyIDAsIGdyYW4gMQpwcm9jZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0 IGVuYWJsZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVudCBwcm9jZXNzCQk9IDMgKGNyeXB0byBy ZXR1cm5zKQpEdW1waW5nIDMyOSBvdXQgb2YgOTkwIE1COi4uNSUuLjE1JS4uMjUlLi4zNCUuLjQ0 JS4uNTQlLi42NCUuLjczJS4uODMlLi45MyVDb3B5cmlnaHQgKGMpIDE5OTItMjAxMiBUaGUgRnJl ZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgs IDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJz aXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdp c3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNEIDkuMC1S RUxFQVNFLXAxICMxOCByMjM1MDk1OiBUdWUgTWF5IDIyIDE2OjAxOjQzIEVEVCAyMDEyCiAgICBh bGV4QHBvc2VpZG9uOi91c3Ivb2JqL3Vzci9zcmMvc3lzL1BPU0VJRE9OIGFtZDY0CkNQVTogSW50 ZWwoUikgQ29yZShUTSkgaTctMjYwMCBDUFUgQCAzLjQwR0h6ICgzMzkyLjM3LU1IeiBLOC1jbGFz cyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHgyMDZhNyAgRmFtaWx5ID0g NiAgTW9kZWwgPSAyYSAgU3RlcHBpbmcgPSA3CiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1F LERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBB VCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+ CiAgRmVhdHVyZXMyPTB4MTdiYWUzZmY8U1NFMyxQQ0xNVUxRRFEsRFRFUzY0LE1PTixEU19DUEws Vk1YLFNNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNLFBDSUQsU1NFNC4xLFNTRTQuMix4 MkFQSUMsUE9QQ05ULFRTQ0RMVCxBRVNOSSxYU0FWRSxBVlg+CiAgQU1EIEZlYXR1cmVzPTB4Mjgx MDA4MDA8U1lTQ0FMTCxOWCxSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBU U0M6IFAtc3RhdGUgaW52YXJpYW50LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzCnJlYWwgbWVtb3J5 ICA9IDE3MTc5ODY5MTg0ICgxNjM4NCBNQikKYXZhaWwgbWVtb3J5ID0gOTk1NDc5NTUyICg5NDkg TUIpCkV2ZW50IHRpbWVyICJMQVBJQyIgcXVhbGl0eSA2MDAKQUNQSSBBUElDIFRhYmxlOiA8QUxB U0tBIEEgTSBJPgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA4 IENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDQgY29yZShzKSB4IDIgU01UIHRocmVh ZHMKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxCiBjcHUy IChBUCk6IEFQSUMgSUQ6ICAyCiBjcHUzIChBUCk6IEFQSUMgSUQ6ICAzCiBjcHU0IChBUCk6IEFQ SUMgSUQ6ICA0CiBjcHU1IChBUCk6IEFQSUMgSUQ6ICA1CiBjcHU2IChBUCk6IEFQSUMgSUQ6ICA2 CiBjcHU3IChBUCk6IEFQSUMgSUQ6ICA3CldBUk5JTkc6IFZJTUFHRSAodmlydHVhbGl6ZWQgbmV0 d29yayBzdGFjaykgaXMgYSBoaWdobHkgZXhwZXJpbWVudGFsIGZlYXR1cmUuCmlvYXBpYzAgPFZl cnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKa2JkMSBhdCBrYmRtdXgwCmFlc25p MDogPEFFUy1DQkMsQUVTLVhUUz4gb24gbW90aGVyYm9hcmQKY3J5cHRvc29mdDA6IDxzb2Z0d2Fy ZSBjcnlwdG8+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiA8QUxBU0tBIEEgTSBJPiBvbiBtb3RoZXJi b2FyZAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIg ZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA5MDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGlt ZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg0MDgtMHg0MGIgb24gYWNwaTAKY3B1MDogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTI6IDxBQ1BJIENQVT4g b24gYWNwaTAKY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU0OiA8QUNQSSBDUFU+IG9uIGFj cGkwCmNwdTU6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1NjogPEFDUEkgQ1BVPiBvbiBhY3BpMApj cHU3OiA8QUNQSSBDUFU+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBv cnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNp YjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBj aTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNw bGF5PiBwb3J0IDB4ZTAwMC0weGUwN2YgbWVtIDB4ZmEwMDAwMDAtMHhmYWZmZmZmZiwweGQwMDAw MDAwLTB4ZDdmZmZmZmYsMHhkODAwMDAwMC0weGQ5ZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4w IG9uIHBjaTEKbnZpZGlhMDogPEdlRm9yY2UgR1QgNDQwPiBvbiB2Z2FwY2kwCnZnYXBjaTA6IGNo aWxkIG52aWRpYTAgcmVxdWVzdGVkIHBjaV9lbmFibGVfaW8KdmdhcGNpMDogY2hpbGQgbnZpZGlh MCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9pbwpoZGFjMDogPE5WaWRpYSAoVW5rbm93bikgSGlnaCBE ZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXI+IG1lbSAweGZiMDgwMDAwLTB4ZmIwODNmZmYgaXJx IDE3IGF0IGRldmljZSAwLjEgb24gcGNpMQpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2Ug MjIuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQplaGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAg Y29udHJvbGxlcj4gbWVtIDB4ZmI1MDcwMDAtMHhmYjUwNzNmZiBpcnEgMTYgYXQgZGV2aWNlIDI2 LjAgb24gcGNpMAp1c2J1czA6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMwOiA8RUhDSSAoZ2VuZXJp YykgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMApoZGFjMTogPEludGVsIENvdWdhciBQb2lu dCBIaWdoIERlZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4ZmI1MDAwMDAtMHhmYjUw M2ZmZiBpcnEgMjIgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApwY2liMjogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGlycSAxNyBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIyCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE4IGF0IGRldmljZSAy OC4yIG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKYWhjaTA6IDxNYXJ2ZWxs IDg4U0U5MTJ4IEFIQ0kgU0FUQSBjb250cm9sbGVyPiBwb3J0IDB4ZDA0MC0weGQwNDcsMHhkMDMw LTB4ZDAzMywweGQwMjAtMHhkMDI3LDB4ZDAxMC0weGQwMTMsMHhkMDAwLTB4ZDAwZiBtZW0gMHhm YjQxMDAwMC0weGZiNDEwN2ZmIGlycSAxOCBhdCBkZXZpY2UgMC4wIG9uIHBjaTMKYWhjaTA6IEFI Q0kgdjEuMjAgd2l0aCA4IDZHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgbm90IHN1cHBvcnRl ZAphaGNpY2gwOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTAKYWhjaWNoMTog PEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCmFoY2ljaDI6IDxBSENJIGNoYW5u ZWw+IGF0IGNoYW5uZWwgMiBvbiBhaGNpMAphaGNpY2gzOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFu bmVsIDMgb24gYWhjaTAKYWhjaWNoNDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9uIGFo Y2kwCmFoY2ljaDU6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBvbiBhaGNpMAphaGNpY2g2 OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDYgb24gYWhjaTAKYWhjaWNoNzogPEFIQ0kgY2hh bm5lbD4gYXQgY2hhbm5lbCA3IG9uIGFoY2kwCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g aXJxIDE5IGF0IGRldmljZSAyOC4zIG9uIHBjaTAKcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjQKeGhjaTA6IDxYSENJIChnZW5lcmljKSBVU0IgMy4wIGNvbnRyb2xsZXI+IG1lbSAweGZiMzAw MDAwLTB4ZmIzMDFmZmYgaXJxIDE5IGF0IGRldmljZSAwLjAgb24gcGNpNAp4aGNpMDogMzIgYnl0 ZSBjb250ZXh0IHNpemUuCnVzYnVzMSBvbiB4aGNpMApwY2liNTogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGlycSAxNyBhdCBkZXZpY2UgMjguNCBvbiBwY2kwCnBjaTU6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI1CnBjaWI2OiA8UENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBj aTUKcGNpNjogPFBDSSBidXM+IG9uIHBjaWI2CnJlMDogPFJlYWxUZWsgODE2OS84MTY5Uy84MTY5 U0IoTCkvODExMFMvODExMFNCKEwpIEdpZ2FiaXQgRXRoZXJuZXQ+IHBvcnQgMHhjMDAwLTB4YzBm ZiBtZW0gMHhmYjIyMDAwMC0weGZiMjIwMGZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTYK cmUwOiBDaGlwIHJldi4gMHgxMDAwMDAwMApyZTA6IE1BQyByZXYuIDB4MDAwMDAwMDAKbWlpYnVz MDogPE1JSSBidXM+IG9uIHJlMApyZ2VwaHkwOiA8UlRMODE2OVMvODExMFMvODIxMSAxMDAwQkFT RS1UIG1lZGlhIGludGVyZmFjZT4gUEhZIDEgb24gbWlpYnVzMApyZ2VwaHkwOiAgbm9uZSwgMTBi YXNlVCwgMTBiYXNlVC1GRFgsIDEwYmFzZVQtRkRYLWZsb3csIDEwMGJhc2VUWCwgMTAwYmFzZVRY LUZEWCwgMTAwYmFzZVRYLUZEWC1mbG93LCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIsIDEw MDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLWZsb3csIDEw MDBiYXNlVC1GRFgtZmxvdy1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpyZTA6IEV0aGVybmV0IGFk ZHJlc3M6IDAwOmUwOjRjOjc4OjIzOjRjCnBjaWI3OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJx IDE2IGF0IGRldmljZSAyOC41IG9uIHBjaTAKcGNpNzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcK eGhjaTE6IDxYSENJIChnZW5lcmljKSBVU0IgMy4wIGNvbnRyb2xsZXI+IG1lbSAweGZiMTAwMDAw LTB4ZmIxMDFmZmYgaXJxIDE3IGF0IGRldmljZSAwLjAgb24gcGNpNwp4aGNpMTogMzIgYnl0ZSBj b250ZXh0IHNpemUuCnVzYnVzMiBvbiB4aGNpMQpwY2liODogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGlycSAxOCBhdCBkZXZpY2UgMjguNiBvbiBwY2kwCnBjaTg6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWI4CnJlMTogPFJlYWxUZWsgODE2OC84MTExIEIvQy9DUC9EL0RQL0UgUENJZSBHaWdhYml0IEV0 aGVybmV0PiBwb3J0IDB4YjAwMC0weGIwZmYgbWVtIDB4ZGExMDQwMDAtMHhkYTEwNGZmZiwweGRh MTAwMDAwLTB4ZGExMDNmZmYgaXJxIDE4IGF0IGRldmljZSAwLjAgb24gcGNpOApyZTE6IFVzaW5n IDEgTVNJLVggbWVzc2FnZQpyZTE6IENoaXAgcmV2LiAweDJjODAwMDAwCnJlMTogTUFDIHJldi4g MHgwMDAwMDAwMAptaWlidXMxOiA8TUlJIGJ1cz4gb24gcmUxCnJnZXBoeTE6IDxSVEw4MTY5Uy84 MTEwUy84MjExIDEwMDBCQVNFLVQgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBtaWlidXMxCnJn ZXBoeTE6ICBub25lLCAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTBiYXNlVC1GRFgtZmxvdywgMTAw YmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDBiYXNlVFgtRkRYLWZsb3csIDEwMDBiYXNlVCwgMTAw MGJhc2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1tYXN0ZXIsIDEwMDBi YXNlVC1GRFgtZmxvdywgMTAwMGJhc2VULUZEWC1mbG93LW1hc3RlciwgYXV0bywgYXV0by1mbG93 CnJlMTogRXRoZXJuZXQgYWRkcmVzczogOGM6ODk6YTU6NmY6NTI6NGYKZWhjaTE6IDxFSENJIChn ZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGZiNTA2MDAwLTB4ZmI1MDYzZmYgaXJx IDIzIGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdXNidXMzOiBFSENJIHZlcnNpb24gMS4wCnVzYnVz MzogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTEKaXNhYjA6IDxQ Q0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24g aXNhYjAKYWhjaTE6IDxJbnRlbCBDb3VnYXIgUG9pbnQgQUhDSSBTQVRBIGNvbnRyb2xsZXI+IHBv cnQgMHhmMDcwLTB4ZjA3NywweGYwNjAtMHhmMDYzLDB4ZjA1MC0weGYwNTcsMHhmMDQwLTB4ZjA0 MywweGYwMjAtMHhmMDNmIG1lbSAweGZiNTA1MDAwLTB4ZmI1MDU3ZmYgaXJxIDE5IGF0IGRldmlj ZSAzMS4yIG9uIHBjaTAKYWhjaTE6IEFIQ0kgdjEuMzAgd2l0aCA2IDZHYnBzIHBvcnRzLCBQb3J0 IE11bHRpcGxpZXIgbm90IHN1cHBvcnRlZAphaGNpY2g4OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFu bmVsIDAgb24gYWhjaTEKYWhjaWNoOTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFo Y2kxCmFoY2ljaDEwOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDMgb24gYWhjaTEKcGNpMDog PHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQph Y3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCmhwZXQwOiA8SGlnaCBQcmVjaXNp b24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1l Y291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRp bWVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA1NTAKdWFydDA6IDwxNjU1 MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNw aTAKYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAweDQwLTB4NDMgaXJxIDAgb24gYWNwaTAKVGlt ZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGlt ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMAphdHJ0YzA6IDxBVCBy ZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzEgaXJxIDggb24gYWNwaTAKRXZlbnQgdGltZXIg IlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMApzYzA6IDxTeXN0ZW0gY29uc29sZT4g YXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxh Z3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9t ZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIg KGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4g aXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmNv cmV0ZW1wMDogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUwCmVzdDA6IDxFbmhh bmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTAKcDR0Y2MwOiA8Q1BVIEZy ZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKY29yZXRlbXAxOiA8Q1BVIE9uLURpZSBU aGVybWFsIFNlbnNvcnM+IG9uIGNwdTEKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVu Y3kgQ29udHJvbD4gb24gY3B1MQpwNHRjYzE6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJv bD4gb24gY3B1MQpjb3JldGVtcDI6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1 Mgplc3QyOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUyCnA0 dGNjMjogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUyCmNvcmV0ZW1wMzog PENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUzCmVzdDM6IDxFbmhhbmNlZCBTcGVl ZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTMKcDR0Y2MzOiA8Q1BVIEZyZXF1ZW5jeSBU aGVybWFsIENvbnRyb2w+IG9uIGNwdTMKY29yZXRlbXA0OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNl bnNvcnM+IG9uIGNwdTQKZXN0NDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJv bD4gb24gY3B1NApwNHRjYzQ6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1 NApjb3JldGVtcDU6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1NQplc3Q1OiA8 RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHU1CnA0dGNjNTogPENQ VSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHU1CmNvcmV0ZW1wNjogPENQVSBPbi1E aWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHU2CmVzdDY6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJl cXVlbmN5IENvbnRyb2w+IG9uIGNwdTYKcDR0Y2M2OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENv bnRyb2w+IG9uIGNwdTYKY29yZXRlbXA3OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9u IGNwdTcKZXN0NzogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1 NwpwNHRjYzc6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1NwpaRlMgTk9U SUNFOiBQcmVmZXRjaCBpcyBkaXNhYmxlZCBieSBkZWZhdWx0IGlmIGxlc3MgdGhhbiA0R0Igb2Yg UkFNIGlzIHByZXNlbnQ7CiAgICAgICAgICAgIHRvIGVuYWJsZSwgYWRkICJ2ZnMuemZzLnByZWZl dGNoX2Rpc2FibGU9MCIgdG8gL2Jvb3QvbG9hZGVyLmNvbmYuClpGUyBmaWxlc3lzdGVtIHZlcnNp b24gNQpaRlMgc3RvcmFnZSBwb29sIHZlcnNpb24gMjgKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkg MS4wMDAgbXNlYwp2Ym94ZHJ2OiBmQXN5bmM9MCBvZmZNaW49MHg4NmMgb2ZmTWF4PTB4YWUwCklQ c2VjOiBJbml0aWFsaXplZCBTZWN1cml0eSBBc3NvY2lhdGlvbiBQcm9jZXNzaW5nLgpoZGFjMDog SERBIENvZGVjICMwOiBOVmlkaWEgKFVua25vd24pCmhkYWMwOiBIREEgQ29kZWMgIzE6IE5WaWRp YSAoVW5rbm93bikKaGRhYzA6IEhEQSBDb2RlYyAjMjogTlZpZGlhIChVbmtub3duKQpoZGFjMDog SERBIENvZGVjICMzOiBOVmlkaWEgKFVua25vd24pCnBjbTA6IDxIREEgTlZpZGlhIChVbmtub3du KSBQQ00gIzAgRGlzcGxheVBvcnQ+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMwCnBjbTE6IDxIREEg TlZpZGlhIChVbmtub3duKSBQQ00gIzAgRGlzcGxheVBvcnQ+IGF0IGNhZCAxIG5pZCAxIG9uIGhk YWMwCnBjbTI6IDxIREEgTlZpZGlhIChVbmtub3duKSBQQ00gIzAgRGlzcGxheVBvcnQ+IGF0IGNh ZCAyIG5pZCAxIG9uIGhkYWMwCnBjbTM6IDxIREEgTlZpZGlhIChVbmtub3duKSBQQ00gIzAgRGlz cGxheVBvcnQ+IGF0IGNhZCAzIG5pZCAxIG9uIGhkYWMwCmhkYWMxOiBIREEgQ29kZWMgIzE6IFJl YWx0ZWsgQUxDODkyCnBjbTQ6IDxIREEgUmVhbHRlayBBTEM4OTIgUENNICMwIEFuYWxvZz4gYXQg Y2FkIDEgbmlkIDEgb24gaGRhYzEKcGNtNTogPEhEQSBSZWFsdGVrIEFMQzg5MiBQQ00gIzEgQW5h bG9nPiBhdCBjYWQgMSBuaWQgMSBvbiBoZGFjMQpwY202OiA8SERBIFJlYWx0ZWsgQUxDODkyIFBD TSAjMiBEaWdpdGFsPiBhdCBjYWQgMSBuaWQgMSBvbiBoZGFjMQpwY203OiA8SERBIFJlYWx0ZWsg QUxDODkyIFBDTSAjMyBEaWdpdGFsPiBhdCBjYWQgMSBuaWQgMSBvbiBoZGFjMQp1c2J1czA6IDQ4 ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1czE6IDUuMEdicHMgU3VwZXIgU3BlZWQgVVNC IHYzLjAKdXNidXMyOiA1LjBHYnBzIFN1cGVyIFNwZWVkIFVTQiB2My4wCnVzYnVzMzogNDgwTWJw cyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNidXMwCnVodWIwOiA8 SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYnVzMAp1Z2VuMS4xOiA8MHgxMDMzPiBhdCB1c2J1czEKdWh1YjE6IDwweDEwMzMgWEhDSSBy b290IEhVQiwgY2xhc3MgOS8wLCByZXYgMy4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2Vu Mi4xOiA8MHgxMDMzPiBhdCB1c2J1czIKdWh1YjI6IDwweDEwMzMgWEhDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMy4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2VuMy4xOiA8SW50ZWw+ IGF0IHVzYnVzMwp1aHViMzogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKYWRhMCBhdCBhaGNpY2gwIGJ1cyAwIHNjYnVzMCB0 YXJnZXQgMCBsdW4gMAphZGEwOiA8TTQtQ1QwNjRNNFNTRDIgMDMwOT4gQVRBLTkgU0FUQSAzLngg ZGV2aWNlCmFkYTA6IDYwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAzLngsIFVETUE1LCBQSU8g ODE5MmJ5dGVzKQphZGEwOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhMDogNjEwNTdNQiAo MTI1MDQ1NDI0IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTA6IFByZXZp b3VzbHkgd2FzIGtub3duIGFzIGFkNAphZGExIGF0IGFoY2ljaDggYnVzIDAgc2NidXM4IHRhcmdl dCAwIGx1biAwCmFkYTE6IDxXREMgV0QxMDAyRkFFWC0wMFk5QTAgMDUuMDFEMDU+IEFUQS04IFNB VEEgMy54IGRldmljZQphZGExOiA2MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMy54LCBVRE1B NiwgUElPIDgxOTJieXRlcykKYWRhMTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTE6IDk1 Mzg2OU1CICgxOTUzNTI1MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFk YTE6IFByZXZpb3VzbHkgd2FzIGtub3duIGFzIGFkMjAKYWRhMiBhdCBhaGNpY2g5IGJ1cyAwIHNj YnVzOSB0YXJnZXQgMCBsdW4gMAphZGEyOiA8V0RDIFdEMTAwMkZBRVgtMDBaM0EwIDA1LjAxRDA1 PiBBVEEtOCBTQVRBIDMueCBkZXZpY2UKYWRhMjogNjAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRB IDMueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTI6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxl ZAphZGEyOiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1Qg MTYzODNDKQphZGEyOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDIyCmFkYTMgYXQgYWhjaWNo MTAgYnVzIDAgc2NidXMxMCB0YXJnZXQgMCBsdW4gMAphZGEzOiA8V0RDIFdEMzIwMEtTLTAwUEZC MCAyMS4wME0yMT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTM6IDMwMC4wMDBNQi9zIHRyYW5z ZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGEzOiBDb21tYW5kIFF1ZXVl aW5nIGVuYWJsZWQKYWRhMzogMzA1MjQ1TUIgKDYyNTE0MjQ0OCA1MTIgYnl0ZSBzZWN0b3JzOiAx NkggNjNTL1QgMTYzODNDKQphZGEzOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDI0CnBhc3Mx IGF0IGFoY2ljaDcgYnVzIDAgc2NidXM3IHRhcmdldCAwIGx1biAwCnBhc3MxOiA8TWFydmVsbCA5 MXh4IENvbmZpZyAxLjAxPiBSZW1vdmFibGUgUHJvY2Vzc29yIFNDU0ktMCBkZXZpY2UgCnBhc3Mx OiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNCwgQVRBUEkgMTJieXRlcywg UElPIDgxOTJieXRlcykKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICM0IExh dW5jaGVkIQpTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQh ClNNUDogQVAgQ1BVICM1IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNiBMYXVuY2hlZCEKU01QOiBB UCBDUFUgIzcgTGF1bmNoZWQhClRpbWVjb3VudGVyICJUU0MtbG93IiBmcmVxdWVuY3kgMTMyNTE0 NDYgSHogcXVhbGl0eSAxMDAwCnVodWIyOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAp1aHViMTogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9v dCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMzIHVzYnVzMAp1aHViMDogMiBwb3J0cyB3aXRoIDIg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjM6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwg c2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMyB1c2J1czAKdWdlbjAu MjogPHZlbmRvciAweDgwODc+IGF0IHVzYnVzMAp1Z2VuMy4yOiA8dmVuZG9yIDB4ODA4Nz4gYXQg dXNidXMzCnVodWI0OiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4MDAyNCwgY2xhc3MgOS8wLCBy ZXYgMi4wMC8wLjAwLCBhZGRyIDI+IG9uIHVzYnVzMAp1aHViNTogPHZlbmRvciAweDgwODcgcHJv ZHVjdCAweDAwMjQsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMCwgYWRkciAyPiBvbiB1c2J1czMK Um9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMzIHVzYnVzMAp1aHViNDogNiBwb3J0cyB3aXRo IDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjU6IDggcG9ydHMgd2l0aCA4IHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCnVnZW4wLjM6IDx2ZW5kb3IgMHgwNGQ5PiBhdCB1c2J1czAKdWtiZDA6 IDx2ZW5kb3IgMHgwNGQ5IGRhc2tleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzMuOTAsIGFk ZHIgMz4gb24gdXNidXMwCmtiZDIgYXQgdWtiZDAKdW1zMDogPHZlbmRvciAweDA0ZDkgZGFza2V5 Ym9hcmQsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMy45MCwgYWRkciAzPiBvbiB1c2J1czAKUm9vdCBt b3VudCB3YWl0aW5nIGZvcjogdXNidXMwCnVnZW4wLjQ6IDx2ZW5kb3IgMHgwNWUzPiBhdCB1c2J1 czAKdWh1YjY6IDx2ZW5kb3IgMHgwNWUzIFVTQjIuMCBIdWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAv NzcuNjMsIGFkZHIgND4gb24gdXNidXMwCnVodWI2OiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUs IHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czAKdWdlbjAuNTogPExv Z2l0ZWNoPiBhdCB1c2J1czAKdW1zMTogPExvZ2l0ZWNoIEc1MDAsIGNsYXNzIDAvMCwgcmV2IDIu MDAvNTguMDIsIGFkZHIgNT4gb24gdXNidXMwCnVtczE6IDE2IGJ1dHRvbnMgYW5kIFtYWVpUXSBj b29yZGluYXRlcyBJRD0wCnVrYmQxOiA8TG9naXRlY2ggRzUwMCwgY2xhc3MgMC8wLCByZXYgMi4w MC81OC4wMiwgYWRkciA1PiBvbiB1c2J1czAKa2JkMyBhdCB1a2JkMQp1Z2VuMC42OiA8dmVuZG9y IDB4MDkxZT4gYXQgdXNidXMwClRyeWluZyB0byBtb3VudCByb290IGZyb20gemZzOnpyb290IFtd Li4uClNldHRpbmcgaG9zdHV1aWQ6IDAwMDAwMDAwLTAwMDAtMDAwMC0wMDAwLThjODlhNTZmNTI0 Zi4KU2V0dGluZyBob3N0aWQ6IDB4NTFhNzYwZmMuCkVudHJvcHkgaGFydmVzdGluZzogaW50ZXJy dXB0cyBldGhlcm5ldCBwb2ludF90b19wb2ludCBraWNrc3RhcnQuClN0YXJ0aW5nIGZpbGUgc3lz dGVtIGNoZWNrczoKL2Rldi9ncHQvYXJjaGl2ZTogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5H IENIRUNLUwovZGV2L2dwdC9hcmNoaXZlOiBjbGVhbiwgNTg1OTc5NjUgZnJlZSAoOTMgZnJhZ3Ms IDczMjQ3MzQgYmxvY2tzLCAwLjAlIGZyYWdtZW50YXRpb24pCk1vdW50aW5nIGxvY2FsIGZpbGUg c3lzdGVtczouClNldHRpbmcgaG9zdG5hbWU6IHBvc2VpZG9uLgpTdGFydGluZyBOZXR3b3JrOiBs bzAgcmUwIHJlMSBwZmxvZzAgcGZzeW5jMC4KbG8wOiBmbGFncz04MDQ5PFVQLExPT1BCQUNLLFJV Tk5JTkcsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTYzODQKCW9wdGlvbnM9MzxSWENTVU0sVFhD U1VNPgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjggCglpbmV0NiBmZTgwOjoxJWxvMCBwcmVmaXhs ZW4gNjQgc2NvcGVpZCAweDkgCglpbmV0IDEyNy4wLjAuMSBuZXRtYXNrIDB4ZmYwMDAwMDAgCglu ZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FMPgpyZTA6IGZsYWdzPTg4NDM8 VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAw CglvcHRpb25zPTM4OWI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lORyxWTEFO X0hXQ1NVTSxXT0xfVUNBU1QsV09MX01DQVNULFdPTF9NQUdJQz4KCWV0aGVyIDAwOmUwOjRjOjc4 OjIzOjRjCgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9D QUw+CgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdCAobm9uZSkKCXN0YXR1czogbm8gY2Fycmll cgpyZTE6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+ IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTM4OWI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxW TEFOX0hXVEFHR0lORyxWTEFOX0hXQ1NVTSxXT0xfVUNBU1QsV09MX01DQVNULFdPTF9NQUdJQz4K CWV0aGVyIDhjOjg5OmE1OjZmOjUyOjRmCglpbmV0IDEwLjMuMC4xIG5ldG1hc2sgMHhmZmZmMDAw MCBicm9hZGNhc3QgMTAuMy4yNTUuMjU1CglpbmV0NiBmZTgwOjo4ZTg5OmE1ZmY6ZmU2Zjo1MjRm JXJlMSBwcmVmaXhsZW4gNjQgdGVudGF0aXZlIHNjb3BlaWQgMHg1IAoJbmQ2IG9wdGlvbnM9Mjk8 UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1 dG9zZWxlY3QgKG5vbmUpCglzdGF0dXM6IG5vIGNhcnJpZXIKcGZsb2cwOiBmbGFncz0wPD4gbWV0 cmljIDAgbXR1IDMzMTUyCgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVU T19MSU5LTE9DQUw+CnBmc3luYzA6IGZsYWdzPTA8PiBtZXRyaWMgMCBtdHUgMTUwMAoJbmQ2IG9w dGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJc3luY3BlZXI6 IDAuMC4wLjAgbWF4dXBkOiAxMjgKU3RhcnRpbmcgZGV2ZC4KU3RhcnRpbmcgTmV0d29yazogdXNi dXMwLgpTdGFydGluZyBOZXR3b3JrOiB1c2J1czEuClN0YXJ0aW5nIE5ldHdvcms6IHVzYnVzMi4K U3RhcnRpbmcgTmV0d29yazogdXNidXMzLgpTdGFydGluZyBOZXR3b3JrOiBwZmxvZzAuCnBmbG9n MDogZmxhZ3M9MDw+IG1ldHJpYyAwIG10dSAzMzE1MgoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5V RCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgpTdGFydGluZyBOZXR3b3JrOiBwZnN5bmMwLgpw ZnN5bmMwOiBmbGFncz0wPD4gbWV0cmljIDAgbXR1IDE1MDAKCW5kNiBvcHRpb25zPTI5PFBFUkZP Uk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCXN5bmNwZWVyOiAwLjAuMC4wIG1heHVw ZDogMTI4ClN0YXJ0aW5nIHVtczAgbW91c2VkLgpTdGFydGluZyB1bXMxIG1vdXNlZC4KRW5hYmxp bmcgcGYuCkFkZGl0aW9uYWwgaW5ldCByb3V0aW5nIG9wdGlvbnM6IGlnbm9yZSBJQ01QIHJlZGly ZWN0PVlFUy4KYWRkIG5ldCA6OmZmZmY6MC4wLjAuMDogZ2F0ZXdheSA6OjEKYWRkIG5ldCA6OjAu MC4wLjA6IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmU4MDo6OiBnYXRld2F5IDo6MQphZGQgbmV0IGZm MDI6OjogZ2F0ZXdheSA6OjEKV2FpdGluZyAzMHMgZm9yIHRoZSBkZWZhdWx0IHJvdXRlIGludGVy ZmFjZTogLi4ocmUwKQpFTEYgbGRjb25maWcgcGF0aDogL2xpYiAvdXNyL2xpYiAvdXNyL2xpYi9j b21wYXQgL3Vzci9sb2NhbC9saWIgL3Vzci9sb2NhbC9saWIvY29tcGF0L3BrZyAvdXNyL2xvY2Fs L2tkZTQvbGliIC91c3IvbG9jYWwvbGliL2V2ZW50MiAvdXNyL2xvY2FsL2xpYi9nZWdsLTAuMSAv dXNyL2xvY2FsL2xpYi9ncmFwaHZpeiAvdXNyL2xvY2FsL2xpYi9saWJ4dWwgL3Vzci9sb2NhbC9s aWIvbnNzIC91c3IvbG9jYWwvbGliL3B0aCAvdXNyL2xvY2FsL2xpYi9xdDQgL3Vzci9sb2NhbC9s aWIvdmlydHVhbGJveAozMi1iaXQgY29tcGF0aWJpbGl0eSBsZGNvbmZpZyBwYXRoOiAvdXNyL2xp YjMyCkNyZWF0aW5nIGFuZC9vciB0cmltbWluZyBsb2cgZmlsZXMuClN0YXJ0aW5nIHN5c2xvZ2Qu CnNhdmVjb3JlOiAvZGV2L2FkYTNwMzogT3BlcmF0aW9uIG5vdCBwZXJtaXR0ZWQKTWF5IDIyIDE2 OjIyOjIxIHBvc2VpZG9uIHNhdmVjb3JlOiAvZGV2L2FkYTNwMzogT3BlcmF0aW9uIG5vdCBwZXJt aXR0ZWQKTm8gY29yZSBkdW1wcyBmb3VuZC4KQWRkaXRpb25hbCBBQkkgc3VwcG9ydDogbGludXgu CkNsZWFyaW5nIC90bXAuClN0YXJ0aW5nIGZ1c2Vmcy4KZnVzZTRic2Q6IHZlcnNpb24gMC4zLjkt cHJlMSwgRlVTRSBBQkkgNy44ClN0YXJ0aW5nIG50cGQuClN0YXJ0aW5nIGRoY3BkLgpJbnRlcm5l dCBTeXN0ZW1zIENvbnNvcnRpdW0gREhDUCBTZXJ2ZXIgNC4yLjMtUDIKQ29weXJpZ2h0IDIwMDQt MjAxMiBJbnRlcm5ldCBTeXN0ZW1zIENvbnNvcnRpdW0uCkFsbCByaWdodHMgcmVzZXJ2ZWQuCkZv ciBpbmZvLCBwbGVhc2UgdmlzaXQgaHR0cHM6Ly93d3cuaXNjLm9yZy9zb2Z0d2FyZS9kaGNwLwpX cm90ZSAxIGxlYXNlcyB0byBsZWFzZXMgZmlsZS4KTGlzdGVuaW5nIG9uIEJQRi9yZTEvOGM6ODk6 YTU6NmY6NTI6NGYvMTAuMy4wLjAvMTYKU2VuZGluZyBvbiAgIEJQRi9yZTEvOGM6ODk6YTU6NmY6 NTI6NGYvMTAuMy4wLjAvMTYKCk5vIHN1Ym5ldCBkZWNsYXJhdGlvbiBmb3IgcmUwICgxOTIuMTY4 LjEuMTAxKS5NYXkgMjIgMTY6MjI6MjEgcG9zZWlkb24gZGhjcGQ6IAoKKiogSWdub3JpbmcgcmVx dWVzdHMgb24gcmUwLiAgSWYgdGhpcyBpcyBub3Qgd2hhdAogICB5b3Ugd2FudCwgcGxlYXNlIHdy aXRlIGEgc3VibmV0IGRlY2xhcmF0aW9uCiAgIGluIHlvdXIgZGhjcGQuY29uZiBmaWxlIGZvciB0 aGUgbmV0d29yayBzZWdtZW50CiAgIHRvIHdoaWNoIGludGVyZmFjZSByZTAgaXMgYXR0YWNoZWQu ICoqCgpNYXkgMjIgMTY6MjI6MjEgcG9zZWlkb24gZGhjcGQ6IE5vIHN1Ym5ldCBkZWNsYXJhdGlv biBmb3IgcmUwICgxOTIuMTY4LjEuMTAxKS4KU2VuZGluZyBvbiAgIFNvY2tldC9mYWxsYmFjay9m YWxsYmFjay1uZXQKTWF5IDIyIDE2OjIyOjIxIHBvc2VpZG9uIGRoY3BkOiAqKiBJZ25vcmluZyBy ZXF1ZXN0cyBvbiByZTAuICBJZiB0aGlzIGlzIG5vdCB3aGF0Ck1heSAyMiAxNjoyMjoyMSBwb3Nl aWRvbiBkaGNwZDogICAgeW91IHdhbnQsIHBsZWFzZSB3cml0ZSBhIHN1Ym5ldCBkZWNsYXJhdGlv bgpNYXkgMjIgMTY6MjI6MjEgcG9zZWlkb24gZGhjcGQ6ICAgIGluIHlvdXIgZGhjcGQuY29uZiBm aWxlIGZvciB0aGUgbmV0d29yayBzZWdtZW50Ck1heSAyMiAxNjoyMjoyMSBwb3NlaWRvbiBkaGNw ZDogICAgdG8gd2hpY2ggaW50ZXJmYWNlIHJlMCBpcyBhdHRhY2hlZC4gKioKTWF5IDIyIDE2OjIy OjIxIHBvc2VpZG9uIGRoY3BkOiAKL2V0Yy9yYzogV0FSTklORzogJHN0cm9uZ3N3YW5fZW5hYmxl IGlzIG5vdCBzZXQgcHJvcGVybHkgLSBzZWUgcmMuY29uZig1KS4KU3RhcnRpbmcgc2xpbS4KU3Rh cnRpbmcgZGJ1cy4KU3RhcnRpbmcgaGFsZC4KU3RhcnRpbmcgY3Vwc2QuCkNvbmZpZ3VyaW5nIHN5 c2NvbnM6IGJsYW5rdGltZS4KU3RhcnRpbmcgc3NoZC4KU3RhcnRpbmcgY3Jvbi4KU3RhcnRpbmcg YmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3MgaW4gNjAgc2Vjb25kcy4KClR1ZSBNYXkgMjIg MTY6MjI6MjIgRURUIDIwMTIKTWF5IDIyIDE2OjIyOjQyIHBvc2VpZG9uIHN1OiBCQUQgU1UgYWxl eCB0byByb290IG9uIC9kZXYvdHR5djEKTWF5IDIyIDE2OjIzOjEwIHBvc2VpZG9uIHN1OiBhbGV4 IHRvIHJvb3Qgb24gL2Rldi90dHl2MQpNYXkgMjIgMTY6MjM6MTQgcG9zZWlkb24gbnRwZFsxNzQ4 XTogYmluZCgpIGZkIDMwLCBmYW1pbHkgQUZfSU5FVDYsIHBvcnQgMTIzLCBzY29wZSAxMCwgYWRk ciBmZTgwOjoyZTA6NGNmZjpmZTc4OjIzNGMsIG1jYXN0PTAgZmxhZ3M9MHgxMyBmYWlsczogQ2Fu J3QgYXNzaWduIHJlcXVlc3RlZCBhZGRyZXNzCk1heSAyMiAxNjoyMzoxNCBwb3NlaWRvbiBudHBk WzE3NDhdOiB1bmFibGUgdG8gY3JlYXRlIHNvY2tldCBvbiBnaWYwICg5KSBmb3IgZmU4MDo6MmUw OjRjZmY6ZmU3ODoyMzRjIzEyMwoKCkZhdGFsIHRyYXAgMTI6IHBhZ2UgZmF1bHQgd2hpbGUgaW4g a2VybmVsIG1vZGUKY3B1aWQgPSAyOyBhcGljIGlkID0gMDIKZmF1bHQgdmlydHVhbCBhZGRyZXNz CT0gMHgyOApmYXVsdCBjb2RlCQk9IHN1cGVydmlzb3IgcmVhZCBkYXRhLCBwYWdlIG5vdCBwcmVz ZW50Cmluc3RydWN0aW9uIHBvaW50ZXIJPSAweDIwOjB4ZmZmZmZmZmY4MDg5N2Q0NwpzdGFjayBw b2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZmODAwMDJiYmIzMApmcmFtZSBwb2ludGVyCSAg ICAgICAgPSAweDI4OjB4ZmZmZmZmODAwMDJiYmI5MApjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDAs IGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYgoJCQk9IERQTCAwLCBwcmVzIDEsIGxvbmcgMSwgZGVm MzIgMCwgZ3JhbiAxCnByb2Nlc3NvciBlZmxhZ3MJPSBpbnRlcnJ1cHQgZW5hYmxlZCwgcmVzdW1l LCBJT1BMID0gMApjdXJyZW50IHByb2Nlc3MJCT0gMyAoY3J5cHRvIHJldHVybnMpCkR1bXBpbmcg MjYxIG91dCBvZiA5OTAgTUI6Li43JS4uMTMlLi4yNSUuLjMxJS4uNDMlLi41NiUuLjYyJS4uNzQl Li44NiUuLjkyJQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmtlcm5lbCBjb25maWcKCm9wdGlvbnMJQ09ORklH X0FVVE9HRU5FUkFURUQKaWRlbnQJUE9TRUlET04KbWFjaGluZQlhbWQ2NApjcHUJSEFNTUVSCm1h a2VvcHRpb25zCU1PRFVMRVNfT1ZFUlJJREU9b3BlbnNvbGFyaXMgemZzIG5ldGdyYXBoCm1ha2Vv cHRpb25zCUNPUFRGTEFHUz0tcGlwZQptYWtlb3B0aW9ucwlERUJVRz0tZwpvcHRpb25zCVVTQl9E RUJVRwpvcHRpb25zCVNDX1BJWEVMX01PREUKb3B0aW9ucwlBVEFfU1RBVElDX0lECm9wdGlvbnMJ QVRBX0NBTQpvcHRpb25zCVNNUApvcHRpb25zCU5VTExGUwpvcHRpb25zCVZJTUFHRQpvcHRpb25z CUxJTlBST0NGUwpvcHRpb25zCUNPTVBBVF9MSU5VWDMyCm9wdGlvbnMJSVBTRUNfTkFUX1QKb3B0 aW9ucwlJUFNFQwpvcHRpb25zCUFMVFFfUFJJUQpvcHRpb25zCUFMVFFfQ0JRCm9wdGlvbnMJQUxU UQpvcHRpb25zCUdFT01fSk9VUk5BTApvcHRpb25zCUdFT01fRUxJCm9wdGlvbnMJR0VPTV9BRVMK b3B0aW9ucwlWRlNfQUlPCm9wdGlvbnMJS0RCX1RSQUNFCm9wdGlvbnMJS0RCCm9wdGlvbnMJSU5D TFVERV9DT05GSUdfRklMRQpvcHRpb25zCU1BQwpvcHRpb25zCUFVRElUCm9wdGlvbnMJSFdQTUNf SE9PS1MKb3B0aW9ucwlLQkRfSU5TVEFMTF9DREVWCm9wdGlvbnMJUFJJTlRGX0JVRlJfU0laRT0x MjgKb3B0aW9ucwlfS1BPU0lYX1BSSU9SSVRZX1NDSEVEVUxJTkcKb3B0aW9ucwlTWVNWU0VNCm9w dGlvbnMJU1lTVk1TRwpvcHRpb25zCVNZU1ZTSE0Kb3B0aW9ucwlTVEFDSwpvcHRpb25zCUtUUkFD RQpvcHRpb25zCVNDU0lfREVMQVk9NTAwMApvcHRpb25zCUNPTVBBVF9GUkVFQlNENwpvcHRpb25z CUNPTVBBVF9GUkVFQlNEMzIKb3B0aW9ucwlHRU9NX0xBQkVMCm9wdGlvbnMJR0VPTV9QQVJUX0dQ VApvcHRpb25zCVBTRVVET0ZTCm9wdGlvbnMJUFJPQ0ZTCm9wdGlvbnMJQ0Q5NjYwCm9wdGlvbnMJ TVNET1NGUwpvcHRpb25zCU5GU19ST09UCm9wdGlvbnMJTkZTTE9DS0QKb3B0aW9ucwlORlNECm9w dGlvbnMJTkZTQ0wKb3B0aW9ucwlNRF9ST09UCm9wdGlvbnMJVUZTX0dKT1VSTkFMCm9wdGlvbnMJ VUZTX0RJUkhBU0gKb3B0aW9ucwlVRlNfQUNMCm9wdGlvbnMJU09GVFVQREFURVMKb3B0aW9ucwlG RlMKb3B0aW9ucwlTQ1RQCm9wdGlvbnMJSU5FVDYKb3B0aW9ucwlJTkVUCm9wdGlvbnMJUFJFRU1Q VElPTgpvcHRpb25zCVNDSEVEX1VMRQpvcHRpb25zCUREQgpvcHRpb25zCU5FV19QQ0lCCm9wdGlv bnMJR0VPTV9QQVJUX01CUgpvcHRpb25zCUdFT01fUEFSVF9FQlJfQ09NUEFUCm9wdGlvbnMJR0VP TV9QQVJUX0VCUgpvcHRpb25zCUdFT01fUEFSVF9CU0QKZGV2aWNlCWlzYQpkZXZpY2UJbWVtCmRl dmljZQlpbwpkZXZpY2UJdWFydF9uczgyNTAKZGV2aWNlCWNyeXB0bwpkZXZpY2UJY3J5cHRvZGV2 CmRldmljZQlhZXNuaQpkZXZpY2UJdGFwCmRldmljZQlpZl9icmlkZ2UKZGV2aWNlCWVwYWlyCmRl dmljZQljb3JldGVtcApkZXZpY2UJcGYKZGV2aWNlCXBmbG9nCmRldmljZQlwZnN5bmMKZGV2aWNl CWNwdWZyZXEKZGV2aWNlCWFjcGkKZGV2aWNlCXBjaQpkZXZpY2UJYWhjaQpkZXZpY2UJYXRhCmRl dmljZQlzY2J1cwpkZXZpY2UJZGEKZGV2aWNlCXBhc3MKZGV2aWNlCW1maQpkZXZpY2UJYXRrYmRj CmRldmljZQlhdGtiZApkZXZpY2UJcHNtCmRldmljZQlrYmRtdXgKZGV2aWNlCXZnYQpkZXZpY2UJ c3BsYXNoCmRldmljZQlzYwpkZXZpY2UJdWFydApkZXZpY2UJbWlpYnVzCmRldmljZQlyZQpkZXZp Y2UJbG9vcApkZXZpY2UJcmFuZG9tCmRldmljZQlldGhlcgpkZXZpY2UJdmxhbgpkZXZpY2UJdHVu CmRldmljZQlwdHkKZGV2aWNlCW1kCmRldmljZQlnaWYKZGV2aWNlCWZhaXRoCmRldmljZQlmaXJt d2FyZQpkZXZpY2UJYnBmCmRldmljZQl1aGNpCmRldmljZQlvaGNpCmRldmljZQllaGNpCmRldmlj ZQl4aGNpCmRldmljZQl1c2IKZGV2aWNlCXVoaWQKZGV2aWNlCXVrYmQKZGV2aWNlCXVscHQKZGV2 aWNlCXVtYXNzCmRldmljZQl1bXMKZGV2aWNlCWZpcmV3aXJlCmRldmljZQlzb3VuZApkZXZpY2UJ c25kX2hkYQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmRkYiBjYXB0dXJlIGJ1ZmZlcgoKCg== --e89a8fb1ed4a968b5104c0a68118 Content-Type: application/octet-stream; name="info.0" Content-Disposition: attachment; filename="info.0" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h2jgch1t1 RHVtcCBoZWFkZXIgZnJvbSBkZXZpY2UgL2Rldi9hZGEzcDMKICBBcmNoaXRlY3R1cmU6IGFtZDY0 CiAgQXJjaGl0ZWN0dXJlIFZlcnNpb246IDIKICBEdW1wIExlbmd0aDogMjczNjc4MzM2QiAoMjYx IE1CKQogIEJsb2Nrc2l6ZTogNTEyCiAgRHVtcHRpbWU6IFR1ZSBNYXkgMjIgMTY6MjM6NTcgMjAx MgogIEhvc3RuYW1lOiBwb3NlaWRvbgogIE1hZ2ljOiBGcmVlQlNEIEtlcm5lbCBEdW1wCiAgVmVy c2lvbiBTdHJpbmc6IEZyZWVCU0QgOS4wLVJFTEVBU0UtcDEgIzE4IHIyMzUwOTU6IFR1ZSBNYXkg MjIgMTY6MDE6NDMgRURUIDIwMTIKICAgIGFsZXhAcG9zZWlkb246L3Vzci9vYmovdXNyL3NyYy9z eXMvUE9TRUlET04KICBQYW5pYyBTdHJpbmc6IAogIER1bXAgUGFyaXR5OiAzMTMzNzI5MzU0CiAg Qm91bmRzOiAwCiAgRHVtcCBTdGF0dXM6IGdvb2QK --e89a8fb1ed4a968b5104c0a68118-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 22:57:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC261065670 for ; Tue, 22 May 2012 22:57:27 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id AB8DB8FC17 for ; Tue, 22 May 2012 22:57:26 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id B00A625D389C; Tue, 22 May 2012 22:57:25 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id DEB69BE7854; Tue, 22 May 2012 22:57:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id czdjv1sTtqhq; Tue, 22 May 2012 22:57:24 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id F0091BE7852; Tue, 22 May 2012 22:57:23 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Tue, 22 May 2012 22:57:23 +0000 Content-Transfer-Encoding: 7bit Message-Id: <6A752DE8-5AAC-4BD2-9F26-C2AAF0641033@lists.zabbadoz.net> References: To: Alex X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org Subject: Re: Page fault when using IPsec with AESNI enabled on 9.0-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 22:57:27 -0000 On 22. May 2012, at 21:14 , Alex wrote: > Hi there. I am running FreeBSD 9.0-RELEASE-p1 #18 r235095 amd64 and am > experiencing a reproducible page fault when using IPsec with "device > aesni" enabled. Strongswan successfully negotiates the SAs and uses > aes256 for ESP, however once a packet is sent, the page fault occurs. > This does not happen when aesni is disabled. I have a core dump, the > text of which is attached to this email. > > Should I file a PR for this? Thanks. > Sure it's aesni related? kern/164400 ? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-hackers@FreeBSD.ORG Wed May 23 00:23:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61955106566B for ; Wed, 23 May 2012 00:23:40 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm27-vm4.bullet.mail.ne1.yahoo.com (nm27-vm4.bullet.mail.ne1.yahoo.com [98.138.91.187]) by mx1.freebsd.org (Postfix) with SMTP id 23EA68FC15 for ; Wed, 23 May 2012 00:23:40 +0000 (UTC) Received: from [98.138.90.49] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 23 May 2012 00:23:34 -0000 Received: from [98.138.89.198] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 23 May 2012 00:23:34 -0000 Received: from [127.0.0.1] by omp1056.mail.ne1.yahoo.com with NNFMP; 23 May 2012 00:23:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 565403.46662.bm@omp1056.mail.ne1.yahoo.com Received: (qmail 66522 invoked by uid 60001); 23 May 2012 00:23:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337732614; bh=C5pHQGbh+JJAC8OsyLkp3j64jfRo0goKiCbz3nS6WEU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ucwSsMyes6E57SXF9z1bSAMdJzxNqPmJxfvYlfV6VZ1di4BRh1ZG2NAe8qje19fUIwyecfoRAbQCc1cAn2gtAHmVkI+nP7uhVT+t/aHksb4wivRnYTAa28Myjqi/CMiMQnQfWdjHTwWsvVDhSFJE7iuEKweHGXY11V9Kln+qTz0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dJ83trNMwh5tx8VtJ3xhbkdz7NywfTQDfoTD7AfzE6gye0K5v4R13XcAm2c/aVS9GDVvd9IyIUxJynPDI1o8rXiFrJzLuDUvv6bueNGiv6lO9N717tSgIVlPjLN7VJeCwFoJgyHWdv6WubW8INgOgl2quppx71RsCOxyWF8YNeo=; X-YMail-OSG: vQFDqMUVM1lrfH6lGMfR_FnhDvWIyUJKPLpSyy8ENj.bUAo brL19n9cp7eXzNtI.PUQTYhxefrjODtz3J3BT66MZ5r3D5PZGBRwfXF_.vN. 4McdkqkFvggPj2SWpaBMp_41oxXC31TlQEpvTEd5LtsBjm3_FQeqnTdjAQRg XgWCxx47x0i3P1vzZ5Ei_aDyc9ScLXPrin6aXn_IbKC9NJgLE1jX73PqPosr uPel_qtfB_N5M7Oq22W6wK8sOHdveQHJwWwrUU1Z0cDLMBwEiK3qQR6aIjRA r4IXlfo9U9CQIJJpQ979vcZRj9KnciKHoBaCofPY1vvg65Brh4EROrnBuYZL XJkRbCHhSlqchxkfMbZ9bQ4r2WKhWLOhf8izqEBzh6X1Rrpdmyi5ZLuTQumL fDTOw3sZ0WBN56Uq0jMJPrYT. Received: from [173.164.238.34] by web122506.mail.ne1.yahoo.com via HTTP; Tue, 22 May 2012 17:23:34 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337732614.39678.YahooMailClassic@web122506.mail.ne1.yahoo.com> Date: Tue, 22 May 2012 17:23:34 -0700 (PDT) From: Jason Usher To: Ian Lepore In-Reply-To: <1337713927.1116.40.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 23 May 2012 00:48:55 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 00:23:40 -0000 =0A=0A--- On Tue, 5/22/12, Ian Lepore wrote= :=0A=0A> Seeing your example config with the commented-out HostKey=0A> line= s made me=0A> realize that you probably want to have two HostKey lines,=0A>= one for the=0A> protocol v1 key and another for the dsa key for v2.=A0=0A>= The 6.x server=0A> added the v1 key and the v2 dsa key by default, so you = could=0A> have=0A> existing clients relying on a v1 key.=A0 Since you now= =0A> have a HostKey=0A> statement the new server code won't add the v1 key = by=0A> default so you'd=0A> need to be explicit about it.=A0 =0A> =0A> Base= d on examining the code, I think this will be safe=0A> because the keys=0A>= have different type-names ("rsa1" vs "rsa") so a client=0A> wanting to use= a=0A> protocol v2 rsa key won't accidentally match the protcol v1=0A> rsa = key=0A> named in the config file (and it will still match the dsa=0A> key).= =0A=0A=0AWell, yes - and after restarting sshd, this was made clear:=0A=0AS= topping sshd.=0AStarting sshd.=0ADisabling protocol version 1. Could not lo= ad host key=0A=0AHowever, those commented out HostKey lines were always com= mented out - I did not comment them out. In fact, my change was to uncomme= nt the last one.=0A=0AFurther, I think the:=0A=0A/etc/ssh/ssh_host_key=0A= =0Akey, for protocol v1, is an RSA key, right ? But you are saying it's an= older rsa1 key ?=0A=0AOk, I will uncomment both lines now, and it will rea= d:=0A=0A# HostKey for protocol version 1=0AHostKey /etc/ssh/ssh_host_key=0A= # HostKeys for protocol version 2=0AHostKey /etc/ssh/ssh_host_dsa_key=0A=0A= I just tried it and it seems to work (no scary key mismatch messages for DS= A clients)=0A=0AThanks. From owner-freebsd-hackers@FreeBSD.ORG Wed May 23 06:02:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAC9A1065670 for ; Wed, 23 May 2012 06:02:18 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9B58FC0A for ; Wed, 23 May 2012 06:02:17 +0000 (UTC) Received: by laai10 with SMTP id i10so7020868laa.13 for ; Tue, 22 May 2012 23:02:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=30SjEa1Bzg6kwTsM3nnB6/NXi+Iq+aYkTWkJQcsKVXo=; b=jWH2FqKxRE5maTTd2NzbVzcGu0B10Ng4msSWW8WEJ7nvxb6F6VOgUG0iT9BES4IrJr EJSXHLSwJMlsEulnHNMX7jM0/Mf2J6RP/ZFyN9DuGKd/RWhjtPS9wxxnalYiHIlQhY0s Tf4x8Ho8m2sqkymYXIWKWkGo2IEZswlWpLwWFkNMXTC1BnunDrtUlKC0qHSyU9LRWdTT uSzwYkuq5jvNuRVJnp8EVi3HKuFwC/ppxK6ToxNjb4SWDOP43C5rknHYNHtYI3MFZFFm LQwe85WcOzL0DA3VH+iyKd6KMJ5qTaE6/SgGnCNxzNVYzw6O3CVU5zUuLxxlBnUHb1vm ApDQ== Received: by 10.152.102.234 with SMTP id fr10mr24072604lab.32.1337752936645; Tue, 22 May 2012 23:02:16 -0700 (PDT) Received: from zont-osx.local (ppp95-165-130-190.pppoe.spdop.ru. [95.165.130.190]) by mx.google.com with ESMTPS id hz16sm34457964lab.6.2012.05.22.23.02.15 (version=SSLv3 cipher=OTHER); Tue, 22 May 2012 23:02:16 -0700 (PDT) Message-ID: <4FBC7D66.2080605@zonov.org> Date: Wed, 23 May 2012 10:02:14 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alan Cox References: <4F7B495D.3010402@zonov.org> <20120404071746.GJ2358@deviant.kiev.zoral.com.ua> <4F7DC037.9060803@rice.edu> <201204091126.25260.jhb@freebsd.org> <4F845D9B.10004@rice.edu> <4F851F87.3050206@zonov.org> <4F9DD372.1020001@rice.edu> In-Reply-To: <4F9DD372.1020001@rice.edu> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl3nc/UfPzMd9vYdBkQLmRDNjxQvQsDP4CwRZxz2FUP33EHqzKpQJBDtVxhttG45Cj1Hcmf Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, alc@freebsd.org Subject: Re: problems with mmap() and disk caching X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 06:02:19 -0000 On 4/30/12 3:49 AM, Alan Cox wrote: > On 04/11/2012 01:07, Andrey Zonov wrote: >> On 10.04.2012 20:19, Alan Cox wrote: >>> On 04/09/2012 10:26, John Baldwin wrote: >>>> On Thursday, April 05, 2012 11:54:31 am Alan Cox wrote: >>>>> On 04/04/2012 02:17, Konstantin Belousov wrote: >>>>>> On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I open the file, then call mmap() on the whole file and get pointer, >>>>>>> then I work with this pointer. I expect that page should be only >>>>>>> once >>>>>>> touched to get it into the memory (disk cache?), but this doesn't >>>>>>> work! >>>>>>> >>>>>>> I wrote the test (attached) and ran it for the 1G file generated >>>>>>> from >>>>>>> /dev/random, the result is the following: >>>>>>> >>>>>>> Prepare file: >>>>>>> # swapoff -a >>>>>>> # newfs /dev/ada0b >>>>>>> # mount /dev/ada0b /mnt >>>>>>> # dd if=/dev/random of=/mnt/random-1024 bs=1m count=1024 >>>>>>> >>>>>>> Purge cache: >>>>>>> # umount /mnt >>>>>>> # mount /dev/ada0b /mnt >>>>>>> >>>>>>> Run test: >>>>>>> $ ./mmap /mnt/random-1024 30 >>>>>>> mmap: 1 pass took: 7.431046 (none: 262112; res: 32; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 2 pass took: 7.356670 (none: 261648; res: 496; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 3 pass took: 7.307094 (none: 260521; res: 1623; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 4 pass took: 7.350239 (none: 258904; res: 3240; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 5 pass took: 7.392480 (none: 257286; res: 4858; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 6 pass took: 7.292069 (none: 255584; res: 6560; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 7 pass took: 7.048980 (none: 251142; res: 11002; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 8 pass took: 6.899387 (none: 247584; res: 14560; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 9 pass took: 7.190579 (none: 242992; res: 19152; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 10 pass took: 6.915482 (none: 239308; res: 22836; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 11 pass took: 6.565909 (none: 232835; res: 29309; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 12 pass took: 6.423945 (none: 226160; res: 35984; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 13 pass took: 6.315385 (none: 208555; res: 53589; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 14 pass took: 6.760780 (none: 192805; res: 69339; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 15 pass took: 5.721513 (none: 174497; res: 87647; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 16 pass took: 5.004424 (none: 155938; res: 106206; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 17 pass took: 4.224926 (none: 135639; res: 126505; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 18 pass took: 3.749608 (none: 117952; res: 144192; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 19 pass took: 3.398084 (none: 99066; res: 163078; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 20 pass took: 3.029557 (none: 74994; res: 187150; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 21 pass took: 2.379430 (none: 55231; res: 206913; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 22 pass took: 2.046521 (none: 40786; res: 221358; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 23 pass took: 1.152797 (none: 30311; res: 231833; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 24 pass took: 0.972617 (none: 16196; res: 245948; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 25 pass took: 0.577515 (none: 8286; res: 253858; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 26 pass took: 0.380738 (none: 3712; res: 258432; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 27 pass took: 0.253583 (none: 1193; res: 260951; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 28 pass took: 0.157508 (none: 0; res: 262144; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 29 pass took: 0.156169 (none: 0; res: 262144; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 30 pass took: 0.156550 (none: 0; res: 262144; super: >>>>>>> 0; other: 0) >>>>>>> >>>>>>> If I ran this: >>>>>>> $ cat /mnt/random-1024> /dev/null >>>>>>> before test, when result is the following: >>>>>>> >>>>>>> $ ./mmap /mnt/random-1024 5 >>>>>>> mmap: 1 pass took: 0.337657 (none: 0; res: 262144; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 2 pass took: 0.186137 (none: 0; res: 262144; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 3 pass took: 0.186132 (none: 0; res: 262144; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 4 pass took: 0.186535 (none: 0; res: 262144; super: >>>>>>> 0; other: 0) >>>>>>> mmap: 5 pass took: 0.190353 (none: 0; res: 262144; super: >>>>>>> 0; other: 0) >>>>>>> >>>>>>> This is what I expect. But why this doesn't work without reading >>>>>>> file >>>>>>> manually? >>>>>> Issue seems to be in some change of the behaviour of the reserv or >>>>>> phys allocator. I Cc:ed Alan. >>>>> I'm pretty sure that the behavior here hasn't significantly changed in >>>>> about twelve years. Otherwise, I agree with your analysis. >>>>> >>>>> On more than one occasion, I've been tempted to change: >>>>> >>>>> pmap_remove_all(mt); >>>>> if (mt->dirty != 0) >>>>> vm_page_deactivate(mt); >>>>> else >>>>> vm_page_cache(mt); >>>>> >>>>> to: >>>>> >>>>> vm_page_dontneed(mt); >>>>> >>>>> because I suspect that the current code does more harm than good. In >>>>> theory, it saves activations of the page daemon. However, more often >>>>> than not, I suspect that we are spending more on page reactivations >>>>> than >>>>> we are saving on page daemon activations. The sequential access >>>>> detection heuristic is just too easily triggered. For example, I've >>>>> seen it triggered by demand paging of the gcc text segment. Also, I >>>>> think that pmap_remove_all() and especially vm_page_cache() are too >>>>> severe for a detection heuristic that is so easily triggered. >>>> Are you planning to commit this? >>>> >>> >>> Not yet. I did some tests with a file that was several times larger than >>> DRAM, and I didn't like what I saw. Initially, everything behaved as >>> expected, but about halfway through the test the bulk of the pages were >>> active. Despite the call to pmap_clear_reference() in >>> vm_page_dontneed(), the page daemon is finding the pages to be >>> referenced and reactivating them. The net result is that the time it >>> takes to read the file (from a relatively fast SSD) goes up by about >>> 12%. So, this still needs work. >>> >> >> Hi Alan, >> >> What do you think about attached patch? >> >> > > Sorry for the slow reply, I've been rather busy for the past couple of > weeks. What you propose is clearly good for sequential accesses, but not > so good for random accesses. Keep in mind, the potential costs of > unconditionally increasing the read window include not only wasted I/O > but also increased memory pressure. Rather than argue about which is > more important, sequential or random access, I think it's more > productive to replace the sequential access heuristic. The current > heuristic is just not that sophisticated. It's easy to do better. > > The attached patch implements a new heuristic, which starts with the > same initial read window as the current heuristic, but arithmetically > grows the window on sequential page faults. From a stylistic standpoint, > this patch also cleanly separates the "read ahead" logic from the "cache > behind" logic. > > At the same time, this new heuristic is more selective about performing > cache behind. It requires three or four sequential page faults before > cache behind is enabled. More precisely, it requires the read ahead > window to reach its maximum size before cache behind is enabled. > > For long, sequential accesses, the results of my performance tests are > just good as unconditionally increasing the window size. I'm also seeing > fewer pages needlessly cached by the cache behind heuristic. That said, > there is still room for improvement. We are still not achieving the same > sequential performance as "dd", and there are still more pages being > cached than I would like. > > Alan > > I've widely tested your patch and it showed good enough results. I've commited it in our tree and it will be soon on production cluster. Thanks a lot for help and your improvements! -- Andrey Zonov From owner-freebsd-hackers@FreeBSD.ORG Wed May 23 13:08:12 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8EA41065674; Wed, 23 May 2012 13:08:12 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 28AE68FC0C; Wed, 23 May 2012 13:08:11 +0000 (UTC) Received: by laai10 with SMTP id i10so7364004laa.13 for ; Wed, 23 May 2012 06:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dTsmDqf7g35CaImyWT3E9iHi2fLy6ii7RfFvbR1rI8c=; b=DJJStQLW87/XST8z2xoaW7IzDievb2Q/m5fJ6iRdbb1DYiMVsR7aNORx2M0ktO5kDm 3F+TA1H5P0rnXbveT6PRfSu372nXTVUnW2Owe7TCzRCfQgyRX61ygLPy8yS+DT8nahiK 1shHpbyibTCcpclRsr0032uTwq69gU5bOG3QI2xcmOiYgEUfVhBJfQDtbaeegfsFLUki rxY7yGmXDlafRAr8GgiYWuhqThLmphCpPB2VNsbULGX3T1EG4lPTBHQOh7nSxTQIPcJ3 QhenD+5FAhTyKEeLq/xrVDZjGpt7qHDRu2Q8cBuI2PXUxBPHM74LkFp+3zZr0fpvn1Xe FKQQ== MIME-Version: 1.0 Received: by 10.112.27.226 with SMTP id w2mr11821461lbg.57.1337778490111; Wed, 23 May 2012 06:08:10 -0700 (PDT) Received: by 10.112.60.228 with HTTP; Wed, 23 May 2012 06:08:10 -0700 (PDT) In-Reply-To: <1337617221.2516.38.camel@revolution.hippie.lan> References: <1337285248.1503.308.camel@revolution.hippie.lan> <1337617221.2516.38.camel@revolution.hippie.lan> Date: Wed, 23 May 2012 15:08:10 +0200 Message-ID: From: Svatopluk Kraus To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Richard Hodges , freebsd-arm@freebsd.org, hackers@freebsd.org Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 13:08:13 -0000 On Mon, May 21, 2012 at 6:20 PM, Ian Lepore wrote: >> ... >> Some more notes. >> >> SMP makes things worse and ARM11mpcore is about SMP too. For example, >> another thread could be open about that how to flush caches (exclusive >> L1 cache) in SMP case. >> >> I'm not sure how to correctly change memory attributes on page which >> is in use. Making new temporary mapping with different attributes is >> wrong and does not help at all. It's question how to do TLB and cache >> flushes on two and more processors and be sure that everything is OK. >> It could be slow and maybe, changing memory attributes on the fly is >> not a good idea at all. >> > > My suggestion of making a temporary writable mapping was the answer to > how to correctly change memory attributes on a page which is in use, at > least in the existing code, which is for a single processor. > > You don't need, and won't even use, the temporary mapping. =A0You would > make it just because doing so invokes logic in arm/arm/pmap.c which will > find all existing virtual mappings of the given physical pages, and > disable caching in each of those existing mappings. =A0In effect, it make= s > all existing mappings of the physical pages DMA_COHERENT. =A0When you > later free the temporary mapping, all other existing mappings are > changed back to being cacheable (as long as no more than one of the > mappings that remain is writable). > > I don't know that making a temporary mapping just for its side effect of > changing other existing mappings is a good idea, it's just a quick and > easy thing to do if you want to try changing all existing mappings to > non-cacheable. =A0It could be that a better way would be to have the > busdma_machdep code call directly to lower-level routines in pmap.c to > change existing mappings without making a new temporary mapping in the > kernel pmap. =A0The actual changes to the existing mappings are made by > pmap_fix_cache() but that routine isn't directly callable right now. > Thanks for explanation. In fact, I known only a little about current ARM pmap implementation in FreeBSD tree. I took i386 pmap implementation and modified it according to arm11mpcore. > Also, as far as I know all of this automatic disabling of cache for > multiple writable mappings applies only to VIVT cache architectures. > I'm not sure how the pmap code is going to change to support VIPT and > PIPT caches, but it may no longer be true that making a second writable > mapping of a page will lead to changing all existing mappings to > non-cacheable. > > -- Ian Svata From owner-freebsd-hackers@FreeBSD.ORG Wed May 23 13:13:08 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C902A1065670; Wed, 23 May 2012 13:13:08 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19EC88FC17; Wed, 23 May 2012 13:13:07 +0000 (UTC) Received: by lbon10 with SMTP id n10so7316692lbo.13 for ; Wed, 23 May 2012 06:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ht/a4Yyu+Pi+OKYcTM9+ILnoF4hBDFZ0IOsqqrqpdL8=; b=EIx3g1ttNA+GumVZXz6bWZcqZ2cLPodavKMklHQaSYteLszLjAf8eEyfaVFyVb9IIx 4nuqyzmWok3648ffFhtbh8AFy7RUonIqjBr3IZKscAsgrx5zJ1qi0bm2Pjv45Y+gNYsJ PdAVsf2S4mMoA4aNQvC8pl6zn5cu4Q6EMHHiA6e2d19hKg60+yT6mkw94/SN04Gvdcsq Il7CwPNK07tVJocagoddc+YD/yV0XT6L0b3M8KkGP1mTrsPZknaxBVjgrRn+W62Cz+FT 3BVFytDZ3ACQ4buptvOEafI/tKh9xeUP2geRsQAKTqokpxE6VuAa+tV7gJ87fX9QNlbZ iYJQ== MIME-Version: 1.0 Received: by 10.112.44.132 with SMTP id e4mr2622509lbm.51.1337778780810; Wed, 23 May 2012 06:13:00 -0700 (PDT) Received: by 10.112.60.228 with HTTP; Wed, 23 May 2012 06:13:00 -0700 (PDT) In-Reply-To: <1337617221.2516.38.camel@revolution.hippie.lan> References: <1337285248.1503.308.camel@revolution.hippie.lan> <1337617221.2516.38.camel@revolution.hippie.lan> Date: Wed, 23 May 2012 15:13:00 +0200 Message-ID: From: Svatopluk Kraus To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: Richard Hodges , freebsd-arm@freebsd.org, hackers@freebsd.org Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 13:13:08 -0000 Hi, with respect to your replies and among other things, the following summary could be made: There are three kinds of DMA buffers according to their origin: 1. driver buffers As Alexander wrote, the buffers should be allocated by bus_dmamap_alloc(). The function should be implemented to allocate the buffers correctly aligned with help of bus_dma_tag_t. For these buffers, we can avoid bouncing totally just by correct driver implementation. For badly implemented drivers, bouncing penalty is paid in case of unaligned buffers. For BUS_DMA_COHERENT allocations, as Mark wrote, an allocation pool of coherent pages is good optimalization. 2. well-known system buffers Mbufs and vfs buffers. The buffers should be aligned on CACHE_LINE_SIZE (start and size). It should be enough for vfs buffers as they are carring data only and only whole buffers should be accessed by DMA. The mbuf is a structure and data can be carried on three possible locations. The first one, the external buffer, should be aligned on CACHE_LINE_SIZE. The next two locations, which are parts of the mbuf structure, could be unaligned in general. If we assume that no one else is writing any part of the mbuf during DMA access, we can set BUS_DMA_UNALIGNED_SAFE flag in mbuf load functions. I.e., we don't bounce unaligned buffers if the flag is set in dmamap. A tunable can be implemented to suppres the flag for debugging purposes. 3. other buffers As we know nothing about these buffers, we must always bounce unaligned ones. Just two more notes. The DMA buffer should not be access by anyone (except DMA itself) after PRESYNC and before POSTSYNC. For DMA descriptors (for example), using bus_dmamap_alloc() with BUS_DMA_COHERENT flag could be inevitable. As I'm implementing bus dma for ARM11mpcore, I'm doing it with next assumptions: 1. ARMv6k and higher 2. PIPT data cache 3. SMP ready Svata From owner-freebsd-hackers@FreeBSD.ORG Wed May 23 14:30:38 2012 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5650F106566B; Wed, 23 May 2012 14:30:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0298C8FC0A; Wed, 23 May 2012 14:30:37 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4NEStUq054927 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 23 May 2012 08:28:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 23 May 2012 08:28:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1337285248.1503.308.camel@revolution.hippie.lan> <1337617221.2516.38.camel@revolution.hippie.lan> To: Svatopluk Kraus X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 23 May 2012 08:28:56 -0600 (MDT) Cc: Ian Lepore , freebsd-arm@FreeBSD.org, hackers@FreeBSD.org, Richard Hodges Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:30:38 -0000 Hi Svatopluk, That looks very interesting. You may be interested in the efforts of various people to bring up the = armv6 multi-core boards. You can checkout the source from = http://svn.freebsd.org/base/projects/armv6 to see where we are in that = effort. I believe that many of these issues have been addressed. = Perhaps you could take a look and contribute to any areas that are = incomplete rather than starting from scratch? Hope you are doing well! We need more people that truly understand the = ARM cache issues. Warner On May 23, 2012, at 7:13 AM, Svatopluk Kraus wrote: > Hi, >=20 > with respect to your replies and among other things, the following > summary could be made: >=20 > There are three kinds of DMA buffers according to their origin: >=20 > 1. driver buffers > As Alexander wrote, the buffers should be allocated by > bus_dmamap_alloc(). The function should be implemented to allocate the > buffers correctly aligned with help of bus_dma_tag_t. For these > buffers, we can avoid bouncing totally just by correct driver > implementation. For badly implemented drivers, bouncing penalty is > paid in case of unaligned buffers. For BUS_DMA_COHERENT allocations, > as Mark wrote, an allocation pool of coherent pages is good > optimalization. >=20 > 2. well-known system buffers > Mbufs and vfs buffers. The buffers should be aligned on > CACHE_LINE_SIZE (start and size). > It should be enough for vfs buffers as they are carring data only and > only whole buffers should be accessed by DMA. The mbuf is a structure > and data can be carried on three possible locations. The first one, > the external buffer, should be aligned on CACHE_LINE_SIZE. The next > two locations, which are parts of the mbuf structure, could be > unaligned in general. If we assume that no one else is writing any > part of the mbuf during DMA access, we can set BUS_DMA_UNALIGNED_SAFE > flag in mbuf load functions. I.e., we don't bounce unaligned buffers > if the flag is set in dmamap. A tunable can be implemented to suppres > the flag for debugging purposes. >=20 > 3. other buffers > As we know nothing about these buffers, we must always bounce = unaligned ones. >=20 > Just two more notes. The DMA buffer should not be access by anyone > (except DMA itself) after PRESYNC and before POSTSYNC. For DMA > descriptors (for example), using bus_dmamap_alloc() with > BUS_DMA_COHERENT flag could be inevitable. >=20 > As I'm implementing bus dma for ARM11mpcore, I'm doing it with next = assumptions: > 1. ARMv6k and higher > 2. PIPT data cache > 3. SMP ready >=20 > Svata > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-hackers@FreeBSD.ORG Wed May 23 22:30:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49CF1106566B; Wed, 23 May 2012 22:30:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 15FF78FC16; Wed, 23 May 2012 22:30:41 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so11375724pbb.13 for ; Wed, 23 May 2012 15:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9L2OEEm7OzRSx51qsNQvE2zo3+P2eulW0CuhLkKhV2s=; b=YH2839Ku+L4mfBNa+gvGNFWwATdKQn1QtQ29lebaEW+tdVaverM20DYVkkrmZNJ4ye reAYRtwUChOQMERYdVJrbfifqMJawHBgQOK3gJ1jwSQkAi/TjmIJhgWVAjhwIy3c2kUl hefNk7nM20rHJSa+qHFylPkp9jSlNoOWKAFhxziyTzvEd3BvrRl3BqtxFug+Ldsot7z4 b2xRaanwLFfl/RLqCPQow/ocB4NP2wVuojAWtULLGKky/dYqsZlb/Pk96QAUjork+r54 YvtF/LLi6SQBVVzMiuvXts1ufdz5A6wcJ4H/RW1UuSA8Wk9C3dLqDLKlwzpB6wh/PDbz ETDw== MIME-Version: 1.0 Received: by 10.68.232.129 with SMTP id to1mr5075523pbc.27.1337812240616; Wed, 23 May 2012 15:30:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.203.2 with HTTP; Wed, 23 May 2012 15:30:40 -0700 (PDT) In-Reply-To: References: <490F2075-3E4D-4F85-9935-937CED8FB10B@averesystems.com> Date: Wed, 23 May 2012 15:30:40 -0700 X-Google-Sender-Auth: hc1bGub3x6XFJXxtcw9PwZuAOiA Message-ID: From: Adrian Chadd To: Mark Felder Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:30:41 -0000 Hi, can you please, -please- file a PR? And place all of the above information in it so we don't lose it? If this is indeed the problem then I really think we should root cause why the driver and/or interrupt handling code is getting angry with the shared interrupt. I'd also appreciate it if you and the other people who can reproduce this could work with the em/mpt driver people and root cause why this is going. I think having FreeBSD on vmware work stable out of the box without these kinds of tweaks is the way to go - who knows what else is lurking here.. I'm very very glad you've persisted with this and if I had them, I'd send you a "FreeBSD persistent bug reporter!" t-shirt. Thanks, Adrian From owner-freebsd-hackers@FreeBSD.ORG Thu May 24 04:49:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E19106566B for ; Thu, 24 May 2012 04:49:17 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 04DA88FC08 for ; Thu, 24 May 2012 04:49:16 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4O4nF3C048368; Thu, 24 May 2012 04:49:15 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id m9m7p95eywmy63444kvkjpaxvw; Thu, 24 May 2012 04:49:15 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: Date: Wed, 23 May 2012 21:49:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> <20120522134846.GA2274@tiny> To: Warren Block X-Mailer: Apple Mail (2.1278) Cc: freebsd-hackers@freebsd.org, Matthias Apitz Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 04:49:17 -0000 On May 22, 2012, at 7:40 AM, Warren Block wrote: > On Tue, 22 May 2012, Matthias Apitz wrote: >=20 >> El d=EDa Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block = escribi=F3: >>=20 >>> On Tue, 22 May 2012, Matthias Apitz wrote: >>>=20 >>>> El d=EDa Sunday, May 20, 2012 a las 03:36:01AM +0900, = rozhuk.im@gmail.com escribi=F3: >>>>>=20 >>>>> Do not use MBR (or manually do all to align). >>>>> 63 - not 4k aligned. >>>>=20 >>>> To create the above shown partition layout I have not used = gpart(8); I >>>> just said: >>>>=20 >>>> # fdisk -I /dev/ada0 >>>> # fdisk -B /dev/ada0 >>>>=20 >>>> ... >>>> What is wrong with this procedure? >>>=20 >>> The filesystem partitions end up at locations that aren't even = multiples >>> of 4K. This can reduce performance. How much probably depends on = the >>> SSD. >>=20 >> But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) >=20 > A bug in the design of MBR. Which probably can be forgiven, = considering when it was created and the other problems with it. :) >=20 > gpart's alignment option can be used with MBR slices and bsdlabel = partitions. GPart's alignment option doesn't work for MBR slices. It rounds to the requested alignment, and then rounds again to the track size, which defaults to 63 sectors. I'm not convinced this is a bug in the design of MBR. I don't think anything in the MBR design requires that partitions be track-aligned. Tim From owner-freebsd-hackers@FreeBSD.ORG Thu May 24 12:22:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51CFB1065670 for ; Thu, 24 May 2012 12:22:17 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by mx1.freebsd.org (Postfix) with ESMTP id 2C26A8FC0C for ; Thu, 24 May 2012 12:22:07 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT74n7k+WpdOsKzxO0vSMYKYP2Wu1XNOM@postini.com; Thu, 24 May 2012 05:22:16 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 24 May 2012 05:16:27 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 24 May 2012 08:16:26 -0400 From: Andrew Duane To: Tim Kientzle , Warren Block Date: Thu, 24 May 2012 08:16:26 -0400 Thread-Topic: proper newfs options for SSD disk Thread-Index: Ac05aL8GJV1xscvwQaOw9bi6X7F8uwAPdA/Q Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> <20120522134846.GA2274@tiny> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" , Apitz , Matthias Subject: RE: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 12:22:17 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@fre= ebsd.org] On Behalf Of Tim Kientzle > Sent: Thursday, May 24, 2012 12:49 AM > To: Warren Block > Cc: freebsd-hackers@freebsd.org; Matthias Apitz > Subject: Re: proper newfs options for SSD disk >=20 > GPart's alignment option doesn't work for MBR slices. > It rounds to the requested alignment, and then rounds again > to the track size, which defaults to 63 sectors. >=20 > I'm not convinced this is a bug in the design of MBR. I don't > think anything in the MBR design requires that partitions > be track-aligned. >=20 > Tim It really doesn't. This is old school thinking based around minimizing seek= and rotation time on slow multiplatter HDDs. It also helped the redundant = superblock layout scheme of UFS make that spiral striping down a set of dis= k platters. My bet is no one has ever bothered to rethink this in the 25 ye= ars since.... ................................... Andrew Duane Juniper Networks +1 978-589-0551 (o) +1 603-770-7088 (m) aduane@juniper.net =A0 From owner-freebsd-hackers@FreeBSD.ORG Thu May 24 12:35:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B62C106566B for ; Thu, 24 May 2012 12:35:52 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2E44C8FC16 for ; Thu, 24 May 2012 12:35:52 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q4OCZpA7054036; Thu, 24 May 2012 06:35:51 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q4OCZpLn054033; Thu, 24 May 2012 06:35:51 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 24 May 2012 06:35:51 -0600 (MDT) From: Warren Block To: Tim Kientzle In-Reply-To: Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> <20120522134846.GA2274@tiny> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-107453168-1337862951=:53872" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 24 May 2012 06:35:51 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, Matthias Apitz Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 12:35:52 -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. ---902635197-107453168-1337862951=:53872 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 23 May 2012, Tim Kientzle wrote: > On May 22, 2012, at 7:40 AM, Warren Block wrote: > >> On Tue, 22 May 2012, Matthias Apitz wrote: >> >>> El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió: >>> >>>> On Tue, 22 May 2012, Matthias Apitz wrote: >>>> >>>>> El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk.im@gmail.com escribió: >>>>>> >>>>>> Do not use MBR (or manually do all to align). >>>>>> 63 - not 4k aligned. >>>>> >>>>> To create the above shown partition layout I have not used gpart(8); I >>>>> just said: >>>>> >>>>> # fdisk -I /dev/ada0 >>>>> # fdisk -B /dev/ada0 >>>>> >>>>> ... >>>>> What is wrong with this procedure? >>>> >>>> The filesystem partitions end up at locations that aren't even multiples >>>> of 4K. This can reduce performance. How much probably depends on the >>>> SSD. >>> >>> But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) >> >> A bug in the design of MBR. Which probably can be forgiven, considering when it was created and the other problems with it. :) >> >> gpart's alignment option can be used with MBR slices and bsdlabel partitions. > > GPart's alignment option doesn't work for MBR slices. > It rounds to the requested alignment, and then rounds again > to the track size, which defaults to 63 sectors. There's an example in my proposed rewrite of the Handbook RAID1 section: http://www.wonkity.com/~wblock/mirror/book.html The slice starts at block 126, two blocks shy of 4K alignment. With the added two blocks for the bsdlabel, all of the FreeBSD partitions end up aligned at even 4K multiples. A filesystem in the raw slice would be misaligned. Presumably the answer is "well don't do that, then" (always use a bsdlabel with MBR), or some trick to skip a couple of blocks like gnop. If there are any mistakes in that example, please help me correct them to avert steps 4 and 5 of the traditional commit process (4: apologize, and 5: fix and recommit). > I'm not convinced this is a bug in the design of MBR. I don't > think anything in the MBR design requires that partitions > be track-aligned. I meant "bug" in the sense of a missing feature. MBR may not have a provision for fixed alignment, but to its credit, doesn't prevent it either. ---902635197-107453168-1337862951=:53872-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 24 13:47:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 124AE106566B; Thu, 24 May 2012 13:47:58 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id C8D928FC25; Thu, 24 May 2012 13:47:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=Dx+tidjkZx7ELxUmKjjjsoraPEkfl5PkhgQl3nNjujg=; b=lVxSZQvsk8h6FKbJ5CJOG5Lgu79L7Dm6Ut89wR+yGf8P8bH/8+VvDxevBD3GuRbRE19pPTNYSFyt7S8oapiW+K5QhNOA7fZn7grFbFpYm140CDxBIQmVBTc3SR6Kov0/; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXYOO-0004kx-89; Thu, 24 May 2012 08:47:56 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1337867266-3288-3287/5/24; Thu, 24 May 2012 13:47:46 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org References: <490F2075-3E4D-4F85-9935-937CED8FB10B@averesystems.com> Date: Thu, 24 May 2012 08:47:46 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: User-Agent: Opera Mail/11.64 (FreeBSD) X-SA-Score: -1.5 Cc: Adrian Chadd , dene@ilovedene.com Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 13:47:58 -0000 On Wed, 23 May 2012 17:30:40 -0500, Adrian Chadd wrote: > Hi, > > can you please, -please- file a PR? And place all of the above > information in it so we don't lose it? > I'd be glad to post a PR and assist in helping to get it permanently fixed. I certainly don't want this data to get lost and honestly our business uses FreeBSD on VMWare so much that we really need a permanent fix as much as anyone else :-) The reason I've hesitated to post a PR so far is that I didn't have any truly useful or concrete evidence of where the problem lies. After Dane Foster contacted me and told me he could recreate the crash on demand with his workload it was easier to narrow things down. The suggestion that it was an interrupts issue (by possibly Bjoern Zeeb?) and Dane's discovery that his crashes ceased when em0 and mpt0 share an IRQ, but em0 is completely unused was starting to prove there is some strong evidence here in favor of the interrupts issue. Dane, what's the status on your end? Has your fix still been successful? Is it also stable if you simply set hint.mpt.0.msi_enable="1" ? Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu May 24 21:02:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECCC4106566B; Thu, 24 May 2012 21:02:51 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 7D42A8FC14; Thu, 24 May 2012 21:02:51 +0000 (UTC) Received: from aspire.rulingia.com (12.58.233.220.static.exetel.com.au [220.233.58.12]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q4OL2cnU070426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 May 2012 07:02:44 +1000 (EST) (envelope-from peter@rulingia.com) Received: from aspire.rulingia.com (localhost [127.0.0.1]) by aspire.rulingia.com (8.14.5/8.14.5) with ESMTP id q4OKfvkW025632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2012 06:41:57 +1000 (EST) (envelope-from peter@aspire.rulingia.com) Received: (from peter@localhost) by aspire.rulingia.com (8.14.5/8.14.5/Submit) id q4OKfuCS025631; Fri, 25 May 2012 06:41:56 +1000 (EST) (envelope-from peter) Date: Fri, 25 May 2012 06:41:55 +1000 From: Peter Jeremy To: Dimitry Andric Message-ID: <20120524204155.GB2675@aspire.rulingia.com> References: <4FB6B713.7080807@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline In-Reply-To: <4FB6B713.7080807@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: User Wojtek , freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:02:52 -0000 --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-May-18 22:54:43 +0200, Dimitry Andric wrote: >Be sure to use "-t enable" when creating the filesystem: Only if your SSD supports TRIM. Some consumer-grade SSDs don't and get very confused if sent TRIM commands. --=20 Peter Jeremy --Yylu36WmvOXNoKYn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk++nRMACgkQ/opHv/APuIfVbwCfbXxABKZVUus9meq3u51w9mwZ AwwAn2dzWEzdM1DsGsaX7h8BH7nS4F9M =b/tJ -----END PGP SIGNATURE----- --Yylu36WmvOXNoKYn-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 24 20:54:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4781106574D for ; Thu, 24 May 2012 20:54:08 +0000 (UTC) (envelope-from dene@ilovedene.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id AB7368FC14 for ; Thu, 24 May 2012 20:54:08 +0000 (UTC) Received: by dadv36 with SMTP id v36so294222dad.13 for ; Thu, 24 May 2012 13:54:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=aCTK+HsF8F3LiCKwDqDpivn/GJYURHffv4Ei3tE1kfc=; b=Dm+GqvCp2hTz7Oh9ZJxqKZJHILw7oOSSSXRh7pGs5HlOjkej07sB2UY2lZPMOFmmF4 bFPlA3Mxodmi5m8bF2yD+Rhm8zWIjwUzSQT/6d09oh4u4j+lNjxTV3flQ0B3rduCmWna L7FILuwzogF8eqzHhA2oAs6TY5nu6WYO0PpI3nNSFOzKzyP8c9d1KE2ZTOjETefUNMgZ nhUphVY90zWLex/m6tqNoztfL9dYK5YmCe+7ZO4cIN+LfjUqsMO1OUgiVOO6dbbnhLAJ zJPpCukfluhWiEj76+7sAFwjdsOmQL2gUzwAWMWnNhw8xUPBc+fVvDsCbExbhHbmefuz NLBw== Received: by 10.68.213.71 with SMTP id nq7mr4154247pbc.25.1337892848238; Thu, 24 May 2012 13:54:08 -0700 (PDT) Received: from pdene.citylink.co.nz (banks.citylink.co.nz. [202.8.44.8]) by mx.google.com with ESMTPS id ub8sm6557349pbc.44.2012.05.24.13.54.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 13:54:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: dane foster In-Reply-To: Date: Fri, 25 May 2012 08:54:04 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <62F1D149-FC1C-4E00-98FD-DF6C46A5DC55@ilovedene.com> References: <490F2075-3E4D-4F85-9935-937CED8FB10B@averesystems.com> To: Mark Felder X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQki/Vtr89gtavPooS62R7uZ6XqQ8W5JKJAFZXE5rlWviyGaT3Zk1QJqYrRImr26fioCxzL+ X-Mailman-Approved-At: Thu, 24 May 2012 22:31:02 +0000 Cc: freebsd-hackers@freebsd.org, Adrian Chadd , freebsd-questions@freebsd.org Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:54:09 -0000 Hey all, On 25/05/2012, at 1:47 AM, Mark Felder wrote: > On Wed, 23 May 2012 17:30:40 -0500, Adrian Chadd = wrote: >=20 >> Hi, >>=20 >> can you please, -please- file a PR? And place all of the above >> information in it so we don't lose it? >>=20 >=20 > I'd be glad to post a PR and assist in helping to get it permanently = fixed. I certainly don't want this data to get lost and honestly our = business uses FreeBSD on VMWare so much that we really need a permanent = fix as much as anyone else :-) >=20 > The reason I've hesitated to post a PR so far is that I didn't have = any truly useful or concrete evidence of where the problem lies. After = Dane Foster contacted me and told me he could recreate the crash on = demand with his workload it was easier to narrow things down. The = suggestion that it was an interrupts issue (by possibly Bjoern Zeeb?) = and Dane's discovery that his crashes ceased when em0 and mpt0 share an = IRQ, but em0 is completely unused was starting to prove there is some = strong evidence here in favor of the interrupts issue. >=20 > Dane, what's the status on your end? Has your fix still been = successful? Is it also stable if you simply set = hint.mpt.0.msi_enable=3D"1" ? >=20 The situation I've got that's stable now is: hw.pci.enable_msi=3D"0" hw.pci.enable_msix=3D"0" in /boot/loader.conf and: samael:~:% vmstat -i [ = 6:31PM] interrupt total rate irq1: atkbd0 6 0 irq18: em0 mpt0 3061100 15 irq19: em1 6891706 35 cpu0: timer 166383735 868 cpu1: timer 166382123 868 cpu3: timer 166382123 868 cpu2: timer 166382121 868 Total 675482914 3525 Not using em0. This works for 8 (FreeBSD samael.slush.ca 8.3-STABLE = FreeBSD 8.3-STABLE #1: Mon May 7 11:51:03 NZST 2012 = root@samael.slush.ca:/usr/obj/usr/src/sys/DENE amd64). Neither of those settings on their own seem to stop it from happening. The 9 box I've tried this on still hangs almost every time i run = handbrake, no matter whether MSI/MSIX is enabled, or I have separate = IRQs for mpt0 and em0/1 I can cause the hang mostly on demand, but not quite sure what = information to provide from the hung system. If somebody can let me know = what they need, including root access, I can make that happen. Cheers, Dane >=20 > Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu May 24 22:36:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA2CC106564A; Thu, 24 May 2012 22:36:04 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4FF608FC0A; Thu, 24 May 2012 22:36:04 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 59B5325D385D; Thu, 24 May 2012 22:36:02 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1A2FABE7A90; Thu, 24 May 2012 22:36:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id yU5rtw+kCAAp; Thu, 24 May 2012 22:36:00 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 65C9EBE7A8E; Thu, 24 May 2012 22:35:59 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Thu, 24 May 2012 22:35:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7E933377-1E19-4EEF-BE89-ED70E9A2A7C1@lists.zabbadoz.net> References: <490F2075-3E4D-4F85-9935-937CED8FB10B@averesystems.com> To: Mark Felder X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:36:04 -0000 On 24. May 2012, at 13:47 , Mark Felder wrote: > On Wed, 23 May 2012 17:30:40 -0500, Adrian Chadd = wrote: >=20 >> Hi, >>=20 >> can you please, -please- file a PR? And place all of the above >> information in it so we don't lose it? >>=20 >=20 > I'd be glad to post a PR and assist in helping to get it permanently = fixed. I certainly don't want this data to get lost and honestly our = business uses FreeBSD on VMWare so much that we really need a permanent = fix as much as anyone else :-) >=20 > The reason I've hesitated to post a PR so far is that I didn't have = any truly useful or concrete evidence of where the problem lies. After = Dane Foster contacted me and told me he could recreate the crash on = demand with his workload it was easier to narrow things down. The = suggestion that it was an interrupts issue (by possibly Bjoern Zeeb?)=20 Just for the public archives. Interrupts wasn't me. I might have = mentioned disabling cdrom and fdc as good as possible but everything = else I cannot remember... > and Dane's discovery that his crashes ceased when em0 and mpt0 share = an IRQ, but em0 is completely unused was starting to prove there is some = strong evidence here in favor of the interrupts issue. >=20 > Dane, what's the status on your end? Has your fix still been = successful? Is it also stable if you simply set = hint.mpt.0.msi_enable=3D"1" ? --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 00:56:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D30A31065686; Fri, 25 May 2012 00:56:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3758FC16; Fri, 25 May 2012 00:56:01 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so1110551pbb.13 for ; Thu, 24 May 2012 17:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I7HheE1ZGCtCHC7jctudiPdqfUjkw5uVEiuH2vvq9WE=; b=RC7DbixAUpHAmuGbksX6wLbr8Hwp7VSEAB2SHgnD6zNdIAxdLQweWHdPgeVzHElxyD wYggtMa6NPL8wCIN/gKERtwDuCZaMhT1reSuJ/46KTx6dBwt8SwQf5cZ6fl5fIi5oJbI 2r5G5osJPvMPP2S6MQ18ykYuedbz7taN0xJsaJ1Ojko9xlGApmdz1HuDm+my4QBNQIjx FDp25tMF+qwkPGjQZvex5HKgqaMKiBjGl2fvJNC6qdRWO23tK6x0RqFlTYzEPoKTWlBi /4ABPuUvh9SWyFOehwEZSmm+qkNwDZHb8rgKu6qGFb7pu5EeOblMwj05o7jRNjmMqbMt lzcg== MIME-Version: 1.0 Received: by 10.68.232.129 with SMTP id to1mr16852467pbc.27.1337907361063; Thu, 24 May 2012 17:56:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.203.2 with HTTP; Thu, 24 May 2012 17:56:00 -0700 (PDT) In-Reply-To: <62F1D149-FC1C-4E00-98FD-DF6C46A5DC55@ilovedene.com> References: <490F2075-3E4D-4F85-9935-937CED8FB10B@averesystems.com> <62F1D149-FC1C-4E00-98FD-DF6C46A5DC55@ilovedene.com> Date: Thu, 24 May 2012 17:56:00 -0700 X-Google-Sender-Auth: FTak9jtnuLEV_Oxpxg7_rw9Ncso Message-ID: From: Adrian Chadd To: dane foster Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Mark Felder , freebsd-questions@freebsd.org Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 00:56:01 -0000 Hi, You guys now absolutely, positively have enough information for a PR. It's still not clear whether it's a device/interrupt layer issue in FreeBSD, or whether vmware is doing something wrong with how it implements shared interrupts, or a bit of both.. Adrian On 24 May 2012 13:54, dane foster wrote: > Hey all, > > On 25/05/2012, at 1:47 AM, Mark Felder wrote: > >> On Wed, 23 May 2012 17:30:40 -0500, Adrian Chadd wr= ote: >> >>> Hi, >>> >>> can you please, -please- file a PR? And place all of the above >>> information in it so we don't lose it? >>> >> >> I'd be glad to post a PR and assist in helping to get it permanently fix= ed. I certainly don't want this data to get lost and honestly our business = uses FreeBSD on VMWare so much that we really need a permanent fix as much = as anyone else :-) >> >> The reason I've hesitated to post a PR so far is that I didn't have any = truly useful or concrete evidence of where the problem lies. After Dane Fos= ter contacted me and told me he could recreate the crash on demand with his= workload it was easier to narrow things down. The suggestion that it was a= n interrupts issue (by possibly Bjoern Zeeb?) and Dane's discovery that his= crashes ceased when em0 and mpt0 share an IRQ, but em0 is completely unuse= d was starting to prove there is some strong evidence here in favor of the = interrupts issue. >> >> Dane, what's the status on your end? Has your fix still been successful?= Is it also stable if you simply set hint.mpt.0.msi_enable=3D"1" ? >> > > The situation I've got that's stable now is: > > hw.pci.enable_msi=3D"0" > hw.pci.enable_msix=3D"0" > > in /boot/loader.conf > > and: > > samael:~:% vmstat -i =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[ 6:31PM] > interrupt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0total =A0 = =A0 =A0 rate > irq1: atkbd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6 =A0 = =A0 =A0 =A0 =A00 > irq18: em0 mpt0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03061100 =A0 =A0 =A0 = =A0 15 > irq19: em1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6891706 =A0 =A0 = =A0 =A0 35 > cpu0: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0166383735 =A0 =A0 =A0 = =A0868 > cpu1: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0166382123 =A0 =A0 =A0 = =A0868 > cpu3: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0166382123 =A0 =A0 =A0 = =A0868 > cpu2: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0166382121 =A0 =A0 =A0 = =A0868 > Total =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0675482914 =A0 = =A0 =A0 3525 > > Not using em0. This works for 8 (FreeBSD samael.slush.ca 8.3-STABLE FreeB= SD 8.3-STABLE #1: Mon May =A07 11:51:03 NZST 2012 =A0 =A0 root@samael.slush= .ca:/usr/obj/usr/src/sys/DENE =A0amd64). > > Neither of those settings on their own seem to stop it from happening. > > The 9 box I've tried this on still hangs almost every time i run handbrak= e, no matter whether MSI/MSIX is enabled, or I have separate IRQs for mpt0 = and em0/1 > > I can cause the hang mostly on demand, but not quite sure what informatio= n to provide from the hung system. If somebody can let me know what they ne= ed, including root access, I can make that happen. > > Cheers, > > Dane > > > >> >> Thanks! > > > > From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 08:54:42 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E562106566C for ; Fri, 25 May 2012 08:54:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4B3E08FC19 for ; Fri, 25 May 2012 08:54:42 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q4P8sVtS071449 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 25 May 2012 01:54:33 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4FBF48D1.1050402@freebsd.org> Date: Fri, 25 May 2012 01:54:41 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Warren Block References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> <20120522134846.GA2274@tiny> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Matthias Apitz , freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 08:54:42 -0000 On 5/24/12 5:35 AM, Warren Block wrote: > On Wed, 23 May 2012, Tim Kientzle wrote: > >> On May 22, 2012, at 7:40 AM, Warren Block wrote: >> >>> On Tue, 22 May 2012, Matthias Apitz wrote: >>> >>>> El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block >>>> escribió: >>>> >>>>> On Tue, 22 May 2012, Matthias Apitz wrote: >>>>> >>>>>> El día Sunday, May 20, 2012 a las 03:36:01AM +0900, >>>>>> rozhuk.im@gmail.com escribió: >>>>>>> >>>>>>> Do not use MBR (or manually do all to align). >>>>>>> 63 - not 4k aligned. >>>>>> >>>>>> To create the above shown partition layout I have not used >>>>>> gpart(8); I >>>>>> just said: >>>>>> >>>>>> # fdisk -I /dev/ada0 >>>>>> # fdisk -B /dev/ada0 >>>>>> >>>>>> ... >>>>>> What is wrong with this procedure? >>>>> >>>>> The filesystem partitions end up at locations that aren't even >>>>> multiples >>>>> of 4K. This can reduce performance. How much probably depends >>>>> on the >>>>> SSD. >>>> >>>> But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) >>> >>> A bug in the design of MBR. Which probably can be forgiven, >>> considering when it was created and the other problems with it. :) >>> >>> gpart's alignment option can be used with MBR slices and bsdlabel >>> partitions. >> >> GPart's alignment option doesn't work for MBR slices. >> It rounds to the requested alignment, and then rounds again >> to the track size, which defaults to 63 sectors. > > There's an example in my proposed rewrite of the Handbook RAID1 > section: http://www.wonkity.com/~wblock/mirror/book.html > > The slice starts at block 126, two blocks shy of 4K alignment. With > the added two blocks for the bsdlabel, all of the FreeBSD partitions > end up aligned at even 4K multiples. > > A filesystem in the raw slice would be misaligned. Presumably the > answer is "well don't do that, then" (always use a bsdlabel with > MBR), or some trick to skip a couple of blocks like gnop. > > If there are any mistakes in that example, please help me correct > them to avert steps 4 and 5 of the traditional commit process (4: > apologize, and 5: fix and recommit). > >> I'm not convinced this is a bug in the design of MBR. I don't >> think anything in the MBR design requires that partitions >> be track-aligned. > > I meant "bug" in the sense of a missing feature. MBR may not have a > provision for fixed alignment, but to its credit, doesn't prevent it > either. WAAAAYYY back when disk drives and BIOS cared about this the size of a track was signalled past various scope barriers to the actual driver by setting the sectors per-track and heads-per-drive to the maximum values for that actual drive.. i.e. we assumed that the partition ENDED on a cylinder boundary and used that to extrapolate the actual geometry, which the driver actually needed to be able to drive the driver correctly. (a block number had to be divided into cyls and heads to get teh right place to go to.) none of that is true any more on any drive we care about and even if it was we can now read bios tables. so we can stick the damned partitions where ever we want, and Even the BIOS can find them (since mid 90's).. yeah I wrote it.. about time to remove it.. take that 63/255 out and shoot it. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 13:18:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 541A6106564A; Fri, 25 May 2012 13:18:50 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id B45938FC15; Fri, 25 May 2012 13:18:49 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4PDIlXe022531; Fri, 25 May 2012 15:18:47 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4PDIkMO022528; Fri, 25 May 2012 15:18:47 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 25 May 2012 15:18:46 +0200 (CEST) From: Wojciech Puchar To: Peter Jeremy In-Reply-To: <20120524204155.GB2675@aspire.rulingia.com> Message-ID: References: <4FB6B713.7080807@FreeBSD.org> <20120524204155.GB2675@aspire.rulingia.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 25 May 2012 15:18:48 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Dimitry Andric Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 13:18:50 -0000 > On 2012-May-18 22:54:43 +0200, Dimitry Andric wrote: >> Be sure to use "-t enable" when creating the filesystem: > > Only if your SSD supports TRIM. Some consumer-grade SSDs don't and > get very confused if sent TRIM commands. > mine do. From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 13:37:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A21A1065670; Fri, 25 May 2012 13:37:54 +0000 (UTC) (envelope-from prvs=1492bd7dae=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id B2FCE8FC0C; Fri, 25 May 2012 13:37:53 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Fri, 25 May 2012 14:37:50 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50019948910.msg; Fri, 25 May 2012 14:37:49 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1492bd7dae=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <9FDF084EF4094D758CEE603E8FB5F61E@multiplay.co.uk> From: "Steven Hartland" To: "Wojciech Puchar" , "Peter Jeremy" References: <4FB6B713.7080807@FreeBSD.org><20120524204155.GB2675@aspire.rulingia.com> Date: Fri, 25 May 2012 14:38:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-hackers@freebsd.org, Dimitry Andric Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 13:37:54 -0000 ----- Original Message ----- From: "Wojciech Puchar" >> On 2012-May-18 22:54:43 +0200, Dimitry Andric wrote: >>> Be sure to use "-t enable" when creating the filesystem: >> >> Only if your SSD supports TRIM. Some consumer-grade SSDs don't and >> get very confused if sent TRIM commands. >> > mine do. The disk also has be be connected to a disk arch which supports BIO_DELETE which ATM is only ata unless your running HEAD which also has support in da Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 14:05:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A4831065780; Fri, 25 May 2012 14:05:17 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 30A738FC18; Fri, 25 May 2012 14:05:01 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4PE50kk022869; Fri, 25 May 2012 16:05:00 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4PE4xQx022866; Fri, 25 May 2012 16:04:59 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 25 May 2012 16:04:59 +0200 (CEST) From: Wojciech Puchar To: Steven Hartland In-Reply-To: <9FDF084EF4094D758CEE603E8FB5F61E@multiplay.co.uk> Message-ID: References: <4FB6B713.7080807@FreeBSD.org><20120524204155.GB2675@aspire.rulingia.com> <9FDF084EF4094D758CEE603E8FB5F61E@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 25 May 2012 16:05:00 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Dimitry Andric Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 14:05:17 -0000 >> mine do. > > The disk also has be be connected to a disk arch which supports > BIO_DELETE which ATM is only ata unless your running HEAD which > also has support in da FreeBSD 9 support it and it do works. From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 16:48:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 948AD106564A for ; Fri, 25 May 2012 16:48:53 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 518A88FC0C for ; Fri, 25 May 2012 16:48:53 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4PGmZcK035262 for ; Fri, 25 May 2012 09:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337964515; bh=8J8FSD3+4d6lfwwl4IpAh9T3vCCTvXhCo5xJwU3+yOI=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=iU4yPI1JR9MIXp72z0mVdrrF4UpzUs6vTE+zfzAWQfROq/ZiFD5veegYGP8vLD26T 8aLuL1ZP6PAveIXW5wkLoIyuw/LXJsZp46KKNxKap488TkKxtRZS/CAU8rKJ8Y07Ko y7n7Ibhz9MLJqVrzPn1sEqg8Y4HZRM9RP5NIsM48= From: Sean Bruno To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 May 2012 09:48:34 -0700 Message-ID: <1337964514.8951.2.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 964515003 Subject: [jail] Allowing root privledged users to renice X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:48:53 -0000 I've been toying with the idea of letting jails renice processes ... how dangerous and/or stupid is this idea? ==== //depot/yahoo/ybsd_9/src/sys/kern/kern_jail.c#5 - /home/seanbru/ybsd_9/src/sys/kern/kern_jail.c ==== 270a271,275 + int jail_allow_renice = 0; + SYSCTL_INT(_security_jail, OID_AUTO, allow_renice, CTLFLAG_RW, + &jail_allow_renice, 0, + "Prison root can renice processes"); 3857a3863,3865 + case PRIV_SCHED_SETPRIORITY: + if (!jail_allow_renice) + return (EPERM); From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 17:04:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76A4B1065674; Fri, 25 May 2012 17:04:39 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 23B018FC0A; Fri, 25 May 2012 17:04:39 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 21EB725D389C; Fri, 25 May 2012 17:04:38 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2C1E9BE7B6D; Fri, 25 May 2012 17:04:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id tFypQbVmH0nJ; Fri, 25 May 2012 17:04:36 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4C2A2BE7B6C; Fri, 25 May 2012 17:04:34 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <1337964514.8951.2.camel@powernoodle-l7.corp.yahoo.com> Date: Fri, 25 May 2012 17:04:34 +0000 Content-Transfer-Encoding: 7bit Message-Id: <8EE125C9-9FA7-495B-A6ED-CF3F7C2E8A3E@lists.zabbadoz.net> References: <1337964514.8951.2.camel@powernoodle-l7.corp.yahoo.com> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Hackers , FreeBSD-Jail Subject: Re: [jail] Allowing root privledged users to renice X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:04:39 -0000 On 25. May 2012, at 16:48 , Sean Bruno wrote: > I've been toying with the idea of letting jails renice processes ... how > dangerous and/or stupid is this idea? > > ==== //depot/yahoo/ybsd_9/src/sys/kern/kern_jail.c#5 - > /home/seanbru/ybsd_9/src/sys/kern/kern_jail.c ==== > 270a271,275 > + int jail_allow_renice = 0; > + SYSCTL_INT(_security_jail, OID_AUTO, allow_renice, CTLFLAG_RW, > + &jail_allow_renice, 0, > + "Prison root can renice processes"); > > 3857a3863,3865 > + case PRIV_SCHED_SETPRIORITY: > + if (!jail_allow_renice) > + return (EPERM); I think sysctls are a bad idea given jails have per-jail flags these days. Maybe also only allow re-nicing to be nicer but not less nice? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 17:23:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20D901065672; Fri, 25 May 2012 17:23:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id E25568FC1D; Fri, 25 May 2012 17:23:47 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q4PHNhRS075645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 25 May 2012 10:23:45 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4FBFC029.10401@freebsd.org> Date: Fri, 25 May 2012 10:23:53 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <1337964514.8951.2.camel@powernoodle-l7.corp.yahoo.com> <8EE125C9-9FA7-495B-A6ED-CF3F7C2E8A3E@lists.zabbadoz.net> In-Reply-To: <8EE125C9-9FA7-495B-A6ED-CF3F7C2E8A3E@lists.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , FreeBSD-Jail Subject: Re: [jail] Allowing root privledged users to renice X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:23:48 -0000 On 5/25/12 10:04 AM, Bjoern A. Zeeb wrote: > On 25. May 2012, at 16:48 , Sean Bruno wrote: > >> I've been toying with the idea of letting jails renice processes ... how >> dangerous and/or stupid is this idea? >> >> ==== //depot/yahoo/ybsd_9/src/sys/kern/kern_jail.c#5 - >> /home/seanbru/ybsd_9/src/sys/kern/kern_jail.c ==== >> 270a271,275 >> + int jail_allow_renice = 0; >> + SYSCTL_INT(_security_jail, OID_AUTO, allow_renice, CTLFLAG_RW, >> +&jail_allow_renice, 0, >> + "Prison root can renice processes"); >> >> 3857a3863,3865 >> + case PRIV_SCHED_SETPRIORITY: >> + if (!jail_allow_renice) >> + return (EPERM); > > I think sysctls are a bad idea given jails have per-jail flags these days. > > Maybe also only allow re-nicing to be nicer but not less nice? ^^^^ for sure ! start a jail with it's max priority and the root within can allow nicer priorities only.. you can always add priority from teh master (parent) environment outside. > /bz > From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 18:30:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 060FA106566B for ; Fri, 25 May 2012 18:30:31 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id B171B8FC0A for ; Fri, 25 May 2012 18:30:30 +0000 (UTC) Received: from [89.204.138.91] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SXzHF-0005F2-63; Fri, 25 May 2012 20:30:17 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q4PIUDC2001324; Fri, 25 May 2012 20:30:14 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q4PIU7uu001323; Fri, 25 May 2012 20:30:07 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 25 May 2012 20:30:07 +0200 From: Matthias Apitz To: rozhuk.im@gmail.com, "'User Wojtek'" , freebsd-hackers@freebsd.org Message-ID: <20120525183006.GA1259@tiny> References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120519180901.GA1264@tiny> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.138.91 Cc: Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 18:30:31 -0000 El día Saturday, May 19, 2012 a las 08:09:01PM +0200, Matthias Apitz escribió: > My EeePC netbook shows for the two SSD: > > $ uname -a > FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 > 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 > $ gpart show > ... Talking about another question, related to file systems on SSD: My netbook with the two SSD has file systems mounted as: $ df -kh Filesystem Size Used Avail Capacity Mounted on /dev/ada0s1a 3.7G 567M 3.1G 15% / /dev/ada1s1a 14G 8.7G 5.9G 60% /usr/local /dev/md0 125M 88k 115M 0% /tmp Below /usr/local is also my (one and only) HOME dir; I'm on the way to reinstall all with 10-CURRENT and I'd like to crypt the partition /dev/ada1s1a with geli(8). Any objections against running geli(8) on SSD? Should I split /dev/ada1 into two separate partitions, one for real /usr/local and one for my HOME and only crypt this with geli(8)? I think it would be good to crypt my HOME on a netbook. Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 19:25:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B709F1065737 for ; Fri, 25 May 2012 19:25:57 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 868FD8FC0A for ; Fri, 25 May 2012 19:25:57 +0000 (UTC) Received: (qmail 30603 invoked by uid 0); 25 May 2012 19:25:51 -0000 Received: from 67.206.183.108 by rms-us016 with HTTP Content-Type: text/plain; charset="utf-8" Date: Fri, 25 May 2012 15:25:50 -0400 From: "Dieter BSD" Message-ID: <20120525192551.153770@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: 6LnNb3Vd3zOlNR3dAHAhZG1+IGRvb0C9 Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:25:57 -0000 1) tar up files 2) encrypt tarball 3) copy encrypted tarball with rcp, ftp, uucp, ... From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 20:46:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3E7C1065675 for ; Fri, 25 May 2012 20:46:12 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id D7AA98FC20 for ; Fri, 25 May 2012 20:46:11 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4PKkAfQ031395; Fri, 25 May 2012 22:46:10 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4PKkA2c031392; Fri, 25 May 2012 22:46:10 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 25 May 2012 22:46:10 +0200 (CEST) From: Wojciech Puchar To: Matthias Apitz In-Reply-To: <20120525183006.GA1259@tiny> Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 25 May 2012 22:46:10 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, rozhuk.im@gmail.com Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:46:12 -0000 > Talking about another question, related to file systems on SSD: > > My netbook with the two SSD has file systems mounted as: > > $ df -kh > Filesystem Size Used Avail Capacity Mounted on > /dev/ada0s1a 3.7G 567M 3.1G 15% / > /dev/ada1s1a 14G 8.7G 5.9G 60% /usr/local > /dev/md0 125M 88k 115M 0% /tmp try tmpfs instead od md backed filesystem for /tmp. Really it is better. > > Below /usr/local is also my (one and only) HOME dir; > > I'm on the way to reinstall all with 10-CURRENT and I'd like to crypt the > partition /dev/ada1s1a with geli(8). > > Any objections against running geli(8) on SSD? NONE. As i see you have one of these "famous" laptops with 4+16GB SSDs. they are quite slow (they have pendrive/SD style stupid translation hardware) i would recommend reducing writes even more eg. change syslog.conf to: *.* -/var/log/messages (all to one file, no forced sync) You may put /var/tmp in ramdisk too, but it break few things (doesn't matter for me) > > Should I split /dev/ada1 into two separate partitions, one for real > /usr/local and one for my HOME and only crypt this with geli(8)? i would make / on 16GB SSD (including /usr, /usr/local, don't divide to partitions) and geli encrypted home on 4GB SSD (whole device). if sometimes 4GB would be too little for /home then you would manually move things that don't need encryption somewhere else. Why? Your laptop have most probably slow CPU and it will make everything too slow if you make everything encrypted. From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 20:47:57 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A37A71065673 for ; Fri, 25 May 2012 20:47:57 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 27D0A8FC19 for ; Fri, 25 May 2012 20:47:56 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBE030.dip.t-dialin.net [93.203.224.48]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id q4PKlnP5010910 for ; Fri, 25 May 2012 20:47:50 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id q4PKlvfa005782 for ; Fri, 25 May 2012 22:47:57 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id q4PKlpr0022917 for ; Fri, 25 May 2012 22:47:57 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201205252047.q4PKlpr0022917@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Fri, 25 May 2012 22:47:51 +0200 Sender: jhs@berklix.com Cc: Subject: upgrade from 8.2 to 8.3 kernel needs setenv MK_INET_SUPPORT YES X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:47:57 -0000 Hi hackers@ I'm not sure if this is a generic bug or a local oddity: I upgraded an 8.2-RELEASE amd64 to 8.3-rel using src/ First building a new kernel, & that broke, I've lost the error message, but the problem & fix was: cd /sys/amd64/conf config GENERIC cd ../compile/GENERIC make cleandepend # failed line 373 of /sys/modules/Makefile .if ${MK_INET_SUPPORT} != "no" || defined(ALL_MODULES) setenv MK_INET_SUPPORT YES make cleandepend # OK make depend # OK make install # OK make world # OK There's no mention of MK_INET_SUPPORT in src/UPDATING Nor is set in my /etc/make.conf Nor set in any of 8.3 src/ eg include/ Any comment ? Cheers, Julian - -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, & indent with "> ". Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 21:12:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D80991065783 for ; Fri, 25 May 2012 21:12:55 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 918BC8FC08 for ; Fri, 25 May 2012 21:12:55 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q4PLCsID063292; Fri, 25 May 2012 15:12:54 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q4PLCsBX063289; Fri, 25 May 2012 15:12:54 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 25 May 2012 15:12:54 -0600 (MDT) From: Warren Block To: Matthias Apitz In-Reply-To: <20120525183006.GA1259@tiny> Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 25 May 2012 15:12:54 -0600 (MDT) Cc: 'User Wojtek' , rozhuk.im@gmail.com, freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:12:55 -0000 On Fri, 25 May 2012, Matthias Apitz wrote: > Talking about another question, related to file systems on SSD: > > My netbook with the two SSD has file systems mounted as: > > $ df -kh > Filesystem Size Used Avail Capacity Mounted on > /dev/ada0s1a 3.7G 567M 3.1G 15% / > /dev/ada1s1a 14G 8.7G 5.9G 60% /usr/local > /dev/md0 125M 88k 115M 0% /tmp > > Below /usr/local is also my (one and only) HOME dir; > > I'm on the way to reinstall all with 10-CURRENT and I'd like to crypt the > partition /dev/ada1s1a with geli(8). > > Any objections against running geli(8) on SSD? Not that I know of. The encryption happens before the write, so it won't (shouldn't) cause any extra writes. Be prepared for a performance drop. If you have a CPU with AESNI, it helps. > Should I split /dev/ada1 into two separate partitions, one for real > /usr/local and one for my HOME and only crypt this with geli(8)? Hard to say, but I think that encrypting only the necessary data would be better for netbooks with relatively slow CPUs. From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 21:24:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 114FF106566B for ; Fri, 25 May 2012 21:24:02 +0000 (UTC) (envelope-from e.durso@live.com) Received: from dub0-omc2-s15.dub0.hotmail.com (dub0-omc2-s15.dub0.hotmail.com [157.55.1.154]) by mx1.freebsd.org (Postfix) with ESMTP id A00AB8FC15 for ; Fri, 25 May 2012 21:24:01 +0000 (UTC) Received: from DUB116-W85 ([157.55.1.138]) by dub0-omc2-s15.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 14:22:53 -0700 Message-ID: X-Originating-IP: [79.9.55.171] From: enrico d'urso To: Date: Fri, 25 May 2012 23:22:53 +0200 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 May 2012 21:22:53.0663 (UTC) FILETIME=[8BC21EF0:01CD3ABC] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [Kevent] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:24:02 -0000 Hi=2C I'm Italian =2C so sorry for my bad English. I would understand something about Kevent function. Please=2C look this code: nev =3D kevent( kqueue_descr=2C events_list=2C how_many_targets=2Cevents_tr= ig=2C how_many_targets=2C&tmout)=3B When kevent returns and nev is >0=2C nev is equal to ready descriptor and t= o understand what are ready I have to look in events_trig array? For example I can use a cycle as: for(i=3D0=3B i< nev=3B i++) if( events_trig[i].ident =3D=3D mysocket) .... In the case you would look code it is here: http://forums.freebsd.org/showthread.php?p=3D178443#post178443 Bye Enrico = From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 21:39:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86C46106564A for ; Fri, 25 May 2012 21:39:16 +0000 (UTC) (envelope-from raysonlogin@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7C58FC19 for ; Fri, 25 May 2012 21:39:16 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2446325pbb.13 for ; Fri, 25 May 2012 14:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bzI6ggOPUavoIse21UvZZdVjIAI1rBjWepIaxMGFdso=; b=oAph8Dw5l8h1PV0/IhaqYIN38jLYbFwwtX0cmb4MqDpg9iXNpuVMn0Iq7/JIyYJOZp Icf8QaCDShWaeIXKvG47HngCji145TTrdkSIMtOujihTwdKw+fCaBIRDisbDRH7zEd44 Ku4mM9pvNxLZLXIgaH4jRDTua33Xq+aYLpIY5VrP23spuUSR0IrDe93fvVKw07WGd11S CpP3MVSNBYcxl0rWbvOgQ4/DIuQCRa9d/1XlkHNrsFnY69sE5CkwwTAcaTAcrxx+rXzb c8ZoS5susYeGie4Z8bHJzwYZjXa4QF7r3CqzCY04LVhv9t3vez4MPX4Zn4PcrvvNkVUp ku7A== MIME-Version: 1.0 Received: by 10.68.242.166 with SMTP id wr6mr1572085pbc.28.1337981955953; Fri, 25 May 2012 14:39:15 -0700 (PDT) Received: by 10.68.28.71 with HTTP; Fri, 25 May 2012 14:39:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 May 2012 17:39:15 -0400 Message-ID: From: Rayson Ho To: "enrico d'urso" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [Kevent] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:39:16 -0000 You can google kqueue tutorial and get lots of example... Sadly, Google Code Search is dead, but Google is still your friend! Rayson =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Open Grid Scheduler / Grid Engine http://gridscheduler.sourceforge.net/ Scalable Grid Engine Support Program http://www.scalablelogic.com/ On Fri, May 25, 2012 at 5:22 PM, enrico d'urso wrote: > > Hi, I'm Italian , so sorry for my bad English. > > I would understand something about Kevent function. > > Please, look this code: > > nev =3D kevent( kqueue_descr, events_list, how_many_targets,events_trig, = how_many_targets,&tmout); > > When kevent returns and nev is >0, nev is equal to ready descriptor and t= o understand what are ready I have to > look in events_trig array? > > For example I can use a cycle as: > > for(i=3D0; i< nev; i++) > if( events_trig[i].ident =3D=3D mysocket) > .... > > In the case you would look code it is here: > http://forums.freebsd.org/showthread.php?p=3D178443#post178443 > > Bye > > Enrico > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0_______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 22:58:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22500106564A for ; Fri, 25 May 2012 22:58:57 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 6D62B8FC08 for ; Fri, 25 May 2012 22:58:56 +0000 (UTC) Received: from server.rulingia.com (c220-239-254-65.belrs5.nsw.optusnet.com.au [220.239.254.65]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q4PMwlV2086146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 May 2012 08:58:49 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q4PMwfjG085074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 May 2012 08:58:41 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q4PMwdN9085073; Sat, 26 May 2012 08:58:39 +1000 (EST) (envelope-from peter) Date: Sat, 26 May 2012 08:58:39 +1000 From: Peter Jeremy To: Wojciech Puchar Message-ID: <20120525225839.GA7347@server.rulingia.com> References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Matthias Apitz , rozhuk.im@gmail.com Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 22:58:58 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-May-25 22:46:10 +0200, Wojciech Puchar wrote: >> Should I split /dev/ada1 into two separate partitions, one for real >> /usr/local and one for my HOME and only crypt this with geli(8)? > >i would make / on 16GB SSD (including /usr, /usr/local, don't divide=20 >to partitions) and geli encrypted home on 4GB SSD (whole device). if=20 >sometimes 4GB would be too little for /home then you would manually move= =20 >things that don't need encryption somewhere else. This may be a worthwhile suggestion. >Why? Your laptop have most probably slow CPU and it will make everything= =20 >too slow if you make everything encrypted. I'd suggest some experiments - create a largish RAMdisk with and without GELI and see how the performance compares (this will be a lot faster than converting your SSD as well as saving a full-SSD erase/write cycle). As for the overall SSD write rate, some time ago, I worked through minimising the write activity on the SSD in my laptop (I wrote a tool that monitors write transfers via devstat(3) and it would be possible to track down the actual modified files via kqueue(2) if necessary). I'm now down to about two chunks of about 13 transfers each per hour (due to entopy saving and ntp.drift updating). The changes were: 1) Mount the SSD filesystems as noatime 2) Turn off all local syslogging (syslog is directed to another system when my laptop is at home, lost otherwise). 3) Change maillog rotation to size instead of daily 4) Run save-entropy once per hour instead of roughly every 11 minutes. [Note that */11 means 0,11,22,33,44,55 not every 11 minute] 5) Patch the save-entropy script to reduce the write load when it's run (see PR bin/134225). 6) Use a swap-back /tmp As for applications - firefox generates quite a heavy write load during normal use. Moving the cache to /tmp will help but I don't think there's any complete solution. Also, you're probably better off running a traditional lightweight window manager than something like KDE or Gnome. --=20 Peter Jeremy --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/ADp8ACgkQ/opHv/APuIcsWACgjf/aT+PpUcNvlPlLlq8KPFnT Cn4AoLF9+5NQQiz1pOIHtAkIYim6RlgV =J635 -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-hackers@FreeBSD.ORG Sat May 26 10:45:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C3E106564A for ; Sat, 26 May 2012 10:45:38 +0000 (UTC) (envelope-from sam.lin4ml@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 47B428FC14 for ; Sat, 26 May 2012 10:45:37 +0000 (UTC) Received: by laai10 with SMTP id i10so1569632laa.13 for ; Sat, 26 May 2012 03:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xNX9id7nxgIrW43xh6h/vKtAOORxom1+zW9SB4chcok=; b=kCA29AqD8q9Xi2v1wHR3V9s3t6ja4mT/GHAuKR1YoNNwtrVRHPw8KJEOwGkVI2PLn7 uEzUfD+R1mYmrJI2T8J7h5i/q7Qs/zG14at2HdOgaOV1D4E6tfFxBv5JJYWX1xpaaGHn chLDzaCE0Vp+ovFh09o9X6C7XphHolFyxkpzZtm/lCkyt+NA131czydPDxF5tT6eGL/b nWTjIkzrwV+JKdRR34x1oOJf3BqHgFo22fmZZGFAU3lz3BzOC74B/N7BDcIJUn9Jzbvx NwysAF9aJtcnc6HRmPmvyUiTwM8lqqhE9qvDIwDNberoNTfsLFbt1Z9S79qVDaCSdkDH rq0w== MIME-Version: 1.0 Received: by 10.112.37.71 with SMTP id w7mr944221lbj.2.1338029137134; Sat, 26 May 2012 03:45:37 -0700 (PDT) Received: by 10.112.127.102 with HTTP; Sat, 26 May 2012 03:45:37 -0700 (PDT) Date: Sat, 26 May 2012 22:45:37 +1200 Message-ID: From: Sam Lin To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: TeXLive merge into FreeBSD ports tree - FreeBSD project idea X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 10:45:38 -0000 Hi FreeBSD fellows, Those who are using LaTeX on FreeBSD must know that tetex has been discontinued years ago and that TeXLive is now recommended, however TeXLive has never been merged in the ports tree on FreeBSD and that tetex is still used on FreeBSD ports. Although there have been some "customized" work so that FreeBSD users can install and use TeXLive on FreeBSD machine (for example, http://code.google.com/p/freebsd-texlive/wiki/Installing), this is quite confusing and may still cause conflict on the system side when using or maintaining it. There has also been years of gossips that a Japanese developer Hiroki Sato (hrs@freebsd) has been working on this matter for the last years and therefore the FreeBSD admin panel don't want anyone else to work on this and merge it into the ports tree. I actually contacted Hiroki Sato in the beginning of last year (2011) regarding this, and in his reply he said that there had been several technical issues but most of them had been solved and almost ready to merge into the port tree, and that he was planning to go forward after the 8.2/7.4 releases (one or two weeks later from that time stage) are out. However, more than a year has passed since then and still nothing happened. I tried to contact him several times after that (email, tweet, etc) but haven't heard anything back from him at all. Is TeXLive really going to be merged into the FreeBSD ports tree as Hiroki Sato mentioned previously? Or is this just a myth?? I am now thinking that this should be put into the "FreeBSD Project ideas List" [http://wiki.freebsd.org/IdeasPage]. Regards, Sam From owner-freebsd-hackers@FreeBSD.ORG Sat May 26 14:01:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94121106566C for ; Sat, 26 May 2012 14:01:56 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id EEEFF8FC0C for ; Sat, 26 May 2012 14:01:54 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4QE1t4o070320; Sat, 26 May 2012 16:01:55 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4QE1se4070317; Sat, 26 May 2012 16:01:55 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 26 May 2012 16:01:54 +0200 (CEST) From: Wojciech Puchar To: Peter Jeremy In-Reply-To: <20120525225839.GA7347@server.rulingia.com> Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> <20120525225839.GA7347@server.rulingia.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 26 May 2012 16:01:55 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Matthias Apitz , rozhuk.im@gmail.com Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 14:01:56 -0000 >> Why? Your laptop have most probably slow CPU and it will make everything >> too slow if you make everything encrypted. > > I'd suggest some experiments - create a largish RAMdisk with and without > GELI and see how the performance compares (this will be a lot faster than > converting your SSD as well as saving a full-SSD erase/write cycle). right. DO TESTs. mdconfig -a -t swap -s512m -u 0 dd if=/dev/zero of=/dev/md0 bs=128k count=4k dd if=/dev/md0 of=/dev/null bs=128k count=4k geli init -s 2048 /dev/md0 geli attach /dev/md0 dd if=/dev/md0.eli of=/dev/null bs=128k count=4k (*) dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k (*) geli detach /dev/md0 mdconfig -d -u 0 but from my experience intel atom have very low geli performance, esp. older models. and your laptop is atom based IMHO. result from commands marked with * on my atom based machine: [root@bk ~/NOBACKUP]# dd if=/dev/md0.eli of=/dev/null bs=128k count=4k 4095+1 records in 4095+1 records out 536868864 bytes transferred in 25.030418 secs (21448658 bytes/sec) [root@bk ~/NOBACKUP]# dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k dd: /dev/md0.eli: short write on character device dd: /dev/md0.eli: end of device 4096+0 records in 4095+1 records out 536868864 bytes transferred in 26.050000 secs (20609169 bytes/sec) as you can see results are awful, in spite it is CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1827.08-MHz K8-class CPU) And i actually do use geli on it, but as the only thing it does is regularly running rsync to backup several other servers, it isn't a problem it can put heavy CPU load. > As for the overall SSD write rate, some time ago, I worked through > minimising the write activity on the SSD in my laptop (I wrote a tool > that monitors write transfers via devstat(3) and it would be possible > to track down the actual modified files via kqueue(2) if necessary). > I'm now down to about two chunks of about 13 transfers each per hour > (due to entopy saving and ntp.drift updating). The changes were: > 1) Mount the SSD filesystems as noatime forgot about this. But this is good for ANY type of storage. I run noatime everywhere and don't have problems. > 2) Turn off all local syslogging (syslog is directed to another > system when my laptop is at home, lost otherwise). of course, or use /tmp/ for syslog. syslog is useful even on private computer. > 3) Change maillog rotation to size instead of daily i - by default, and everywhere - turn off most things from default /etc/crontab including rotation. and if you have syslog turned off or changed as i recommended you don't have maillog file produced at all so no need to rotate. i recommend turning log rotation off at all everywhere, then turn it on willingly based on actual needs. > 4) Run save-entropy once per hour instead of roughly every 11 minutes. > [Note that */11 means 0,11,22,33,44,55 not every 11 minute] > 5) Patch the save-entropy script to reduce the write load when > it's run (see PR bin/134225). > 6) Use a swap-back /tmp use tmpfs and don't fear to add /var/tmp to it. > As for applications - firefox generates quite a heavy write load > during normal use. Moving the cache to /tmp will help but I don't > think there's any complete solution. isn't simpler to just turn cache off in firefox? > > Also, you're probably better off running a traditional lightweight > window manager than something like KDE or Gnome. Which is good recommendation on any kind of computer and disk type, not just yours. another recomendation - why you everywhere put DOS/MBR partitions? it's just a mess and completely useless unless you run windoze on the same disk. when using whole device filesystem just clean head (dd if=/dev/zero of=/dev/device bs=1m count=1) and then just do newfs if now just bsdlabel -w device, bsdlabel -e device and possibly bsdlabel -B device it's that simple From owner-freebsd-hackers@FreeBSD.ORG Sat May 26 14:31:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 887351065674 for ; Sat, 26 May 2012 14:31:48 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0984D8FC08 for ; Sat, 26 May 2012 14:31:47 +0000 (UTC) Received: by bkvi18 with SMTP id i18so1792401bkv.13 for ; Sat, 26 May 2012 07:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ezsRJpfoUfh/oCsuBFCC57dafPsA9UaKCe3UiVOgkus=; b=OG4lbPe7mKGlzyZMddFD8z04xQvT+u9i+JRzk6EwlXh0zhKUlwBZ4KWU87n7AInMqn bqRefdigrdq0TuAlVbAq3lRYTsMeIIe9TLP1tHojSEEbLsuRTnZT5i5fILdNI3VJHLpy ORkYa7bL8kEWnL7R2pckBr8M8tK2MP1Jh/PFPOw62pj1TLPO9erUjti9Za6fNF05o1FN UKdzr/h8SCoKzGBryjVRZmB7+RlvCRs3RSN0gs4FGxmbhEoSva4Yc6fzhzP7WTKKjfPL TRu2hhQm+cdM+9+WI/okmbbei5rt607704pH1kCsuCi5/U6QKi6Pk98SktyglhQpbsbj jHZQ== Received: by 10.204.153.15 with SMTP id i15mr1026885bkw.74.1338042706832; Sat, 26 May 2012 07:31:46 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.171.138 with HTTP; Sat, 26 May 2012 07:31:16 -0700 (PDT) In-Reply-To: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> <20120525225839.GA7347@server.rulingia.com> From: Chris Rees Date: Sat, 26 May 2012 15:31:16 +0100 X-Google-Sender-Auth: JwQ5Rvb7rYQUbgslHwP_DqoqHWM Message-ID: To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Matthias Apitz , rozhuk.im@gmail.com Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 14:31:48 -0000 On 26 May 2012 15:01, Wojciech Puchar wrot= e: >>> Why? Your laptop have most probably slow CPU and it will make everythin= g >>> too slow if you make everything encrypted. >> >> >> I'd suggest some experiments - create a largish RAMdisk with and without >> GELI and see how the performance compares (this will be a lot faster tha= n >> converting your SSD as well as saving a full-SSD erase/write cycle). > > > right. DO TESTs. > > mdconfig -a -t swap -s512m -u 0 > dd if=3D/dev/zero of=3D/dev/md0 bs=3D128k count=3D4k > dd if=3D/dev/md0 of=3D/dev/null bs=3D128k count=3D4k > > geli init -s 2048 /dev/md0 > geli attach /dev/md0 > dd if=3D/dev/md0.eli of=3D/dev/null bs=3D128k count=3D4k (*) > dd if=3D/dev/zero of=3D/dev/md0.eli bs=3D128k count=3D4k (*) > geli detach /dev/md0 > mdconfig -d -u 0 > > > but from my experience intel atom have very low geli performance, esp. ol= der > models. and your laptop is atom based IMHO. > > result from commands marked with * on my atom based machine: > [root@bk ~/NOBACKUP]# dd if=3D/dev/md0.eli of=3D/dev/null bs=3D128k count= =3D4k > 4095+1 records in > 4095+1 records out > 536868864 bytes transferred in 25.030418 secs (21448658 bytes/sec) > [root@bk ~/NOBACKUP]# dd if=3D/dev/zero of=3D/dev/md0.eli bs=3D128k count= =3D4k > dd: /dev/md0.eli: short write on character device > dd: /dev/md0.eli: end of device > 4096+0 records in > 4095+1 records out > 536868864 bytes transferred in 26.050000 secs (20609169 bytes/sec) > > > as you can see results are awful, in spite it is > CPU: Intel(R) Atom(TM) CPU D525 =A0 @ 1.80GHz (1827.08-MHz K8-class CPU) > > And i actually do use geli on it, but as the only thing it does is regula= rly > running rsync to backup several other servers, it isn't a problem it can = put > heavy CPU load. > > >> As for the overall SSD write rate, some time ago, I worked through >> minimising the write activity on the SSD in my laptop (I wrote a tool >> that monitors write transfers via devstat(3) and it would be possible >> to track down the actual modified files via kqueue(2) if necessary). >> I'm now down to about two chunks of about 13 transfers each per hour >> (due to entopy saving and ntp.drift updating). =A0The changes were: >> 1) Mount the SSD filesystems as noatime > > > forgot about this. But this is good for ANY type of storage. > I run noatime everywhere and don't have problems. > > >> 2) Turn off all local syslogging (syslog is directed to another >> =A0system when my laptop is at home, lost otherwise). > > > of course, or use /tmp/ for syslog. syslog is useful even on private > computer. > > >> 3) Change maillog rotation to size instead of daily > > > i - by default, and everywhere - turn off most things from default > /etc/crontab including rotation. > > and if you have syslog turned off or changed as i recommended you don't h= ave > maillog file produced at all so no need to rotate. > > i recommend turning log rotation off at all everywhere, then turn it on > willingly based on actual needs. > > >> 4) Run save-entropy once per hour instead of roughly every 11 minutes. >> =A0[Note that */11 means 0,11,22,33,44,55 not every 11 minute] >> 5) Patch the save-entropy script to reduce the write load when >> =A0it's run (see PR bin/134225). >> 6) Use a swap-back /tmp > > use tmpfs and don't fear to add /var/tmp to it. I would fear to add /var/tmp-- /var/tmp should persist across reboots. Chris From owner-freebsd-hackers@FreeBSD.ORG Sat May 26 15:04:59 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A90C9106564A; Sat, 26 May 2012 15:04:59 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 049048FC0C; Sat, 26 May 2012 15:04:58 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4QF4xb1070786; Sat, 26 May 2012 17:04:59 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4QF4wW8070783; Sat, 26 May 2012 17:04:58 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 26 May 2012 17:04:58 +0200 (CEST) From: Wojciech Puchar To: Chris Rees In-Reply-To: Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> <20120525225839.GA7347@server.rulingia.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 26 May 2012 17:04:59 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.org, Matthias Apitz , rozhuk.im@gmail.com Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 15:04:59 -0000 >> >> use tmpfs and don't fear to add /var/tmp to it. > > I would fear to add /var/tmp-- /var/tmp should persist across reboots. > > Chris > > as i noted - check your case.in my case it is not a problem. it your it may. Never blindly follow "rules", "good practices" etc.. From owner-freebsd-hackers@FreeBSD.ORG Sat May 26 15:06:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54E231065672 for ; Sat, 26 May 2012 15:06:24 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id A5F0A8FC0C for ; Sat, 26 May 2012 15:06:23 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4QF6O5a070799 for ; Sat, 26 May 2012 17:06:24 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4QF6OWN070796 for ; Sat, 26 May 2012 17:06:24 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 26 May 2012 17:06:24 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 26 May 2012 17:06:24 +0200 (CEST) Subject: BIO_DELETE equivalent for file on FFS filesystem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 15:06:24 -0000 is it possible. suppose i have 1GB file with my data and 100 1 megabyte parts of it is no longer needed. i could reorganize that file to take 900MB or... can i call some system function to "punch" holes? From owner-freebsd-hackers@FreeBSD.ORG Sat May 26 15:07:25 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B035E106566B for ; Sat, 26 May 2012 15:07:25 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 368AE8FC1C for ; Sat, 26 May 2012 15:07:24 +0000 (UTC) Received: by bkvi18 with SMTP id i18so1806934bkv.13 for ; Sat, 26 May 2012 08:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=rF9665nbJ6zwcNqq8kRF6JiHgLBMkSFOoqedDxu0tts=; b=Xf6CnhJt1hR9TOpj75TX6kzMsM1X10o8WcXKKkvzHx8f9kJDJV0RmLZXigaJjz9TnG wtBSDaqaaoaZ9BI+NjPebWUQlJZSpwHHud8v5GDASoNwvHahG+C7ujuvJqu1nu528pj3 ygJi/Kc5lHmx4V6siimcp1pCU39O7++ujMg9njitqonTZPqs2JEmsDZGzyUf6v7cWksG L8QpFlVRpnS6lV9InWwqqGPyzZuZev0jBNfUeddFsrysRMFY3T/U1xkZw5aXZEhskR1j tET0ajCpX7Ywfkfgm6C2imLARSRNPtx+8AbDCpSQTHZJYT9zaLxBXmE15/uLsmof5L2x 1tQA== Received: by 10.204.154.214 with SMTP id p22mr987307bkw.115.1338044844100; Sat, 26 May 2012 08:07:24 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.171.138 with HTTP; Sat, 26 May 2012 08:06:53 -0700 (PDT) In-Reply-To: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> <20120525225839.GA7347@server.rulingia.com> From: Chris Rees Date: Sat, 26 May 2012 16:06:53 +0100 X-Google-Sender-Auth: 4OX2PYfyLWy8oNoxUmhD529h1FQ Message-ID: To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 15:07:25 -0000 On 26 May 2012 16:04, Wojciech Puchar wrote: >>> >>> use tmpfs and don't fear to add /var/tmp to it. >> >> >> I would fear to add /var/tmp-- /var/tmp should persist across reboots. >> >> Chris >> >> > as i noted - check your case.in my case it is not a problem. it your it may. > > Never blindly follow "rules", "good practices" etc.. If you have read every line of source code of every port you've installed, as well as /usr/src that's a great idea. If not, it's a bad idea, and you'll get some weird failure at some point, and it will be difficult to help you. Chris