From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 11:29:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4186106564A for ; Sun, 3 Oct 2010 11:29:00 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7ED8FC17 for ; Sun, 3 Oct 2010 11:29:00 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o93BSxbS096674; Sun, 3 Oct 2010 04:28:59 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o93BSxg3096673; Sun, 3 Oct 2010 04:28:59 -0700 (PDT) (envelope-from david) Date: Sun, 3 Oct 2010 04:28:59 -0700 From: David Wolfskill To: Brandon Gooch , current@freebsd.org Message-ID: <20101003112859.GW1535@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Brandon Gooch , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zge/9PCkZKCDTZ2X" Content-Disposition: inline In-Reply-To: <20101002033859.GK1535@albert.catwhisker.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 11:29:00 -0000 --Zge/9PCkZKCDTZ2X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2010 at 08:38:59PM -0700, David Wolfskill wrote: > On Fri, Oct 01, 2010 at 08:56:13PM -0500, Brandon Gooch wrote: > > ... > > > Any ideas on what mught be causing CURRENT to hang -- sometimes > > > -- given that it appears to involve the Modular Bay (or the specific > > > device that is in the bay during the hang)? > > > > >=20 > > If you haven't already, it may be worth trying 'options ATA_CAM' in > > your kernel config. > ... > And -- probably more important for this discussion -- I was unable to > re-create the failing condition: the machine booted Just Fine every > time I tried it, whether the CD/DVD drive was inserted or not. > ... That assessment (on my part) was premature. The attempt to boot from slice 4, running: FreeBSD g1-222.catwhisker.org. 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r213357: = Sat Oct 2 06:29:23 PDT 2010 root@g1-222.catwhisker.org.:/usr/obj/usr/s= rc/sys/CANARY i386 immediately prior to the one I just did: * was using a kernel with the ATA_CAM enabled, as may be noted by the device name in: g1-222(9.0-C)[2] df -h / Filesystem Size Used Avail Capacity Mounted on /dev/ada0s4a 1.4G 327M 1.0G 25% / g1-222(9.0-C)[3]=20 * hung at the previously-discussed point. It appears that running a kernel with option ATA_CAM may well reduce the probability of this apparently intermittent mode of failure. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Zge/9PCkZKCDTZ2X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkyoaPoACgkQmprOCmdXAD2iAgCeITG0aLUJ+rrotwEK6kZf5qVs XAAAnRL0liKKQlgO1BGgbcpXCi7wx+wD =hZGU -----END PGP SIGNATURE----- --Zge/9PCkZKCDTZ2X-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 11:52:32 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DFB21065674 for ; Sun, 3 Oct 2010 11:52:32 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3398FC15 for ; Sun, 3 Oct 2010 11:52:30 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA11644; Sun, 03 Oct 2010 14:52:20 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P2N76-000JXP-8m; Sun, 03 Oct 2010 14:52:20 +0300 Message-ID: <4CA86E73.9080707@icyb.net.ua> Date: Sun, 03 Oct 2010 14:52:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Wolfskill , Brandon Gooch , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> <20101003112859.GW1535@albert.catwhisker.org> In-Reply-To: <20101003112859.GW1535@albert.catwhisker.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 11:52:32 -0000 on 03/10/2010 14:28 David Wolfskill said the following: [snipped] Can't you just drop to DDB prompt and examine where the threads are? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 13:14:09 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0FC5106564A for ; Sun, 3 Oct 2010 13:14:09 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id BC9C58FC13 for ; Sun, 3 Oct 2010 13:14:09 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o93DE9rf017651; Sun, 3 Oct 2010 06:14:09 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o93DE9hb017650; Sun, 3 Oct 2010 06:14:09 -0700 (PDT) (envelope-from david) Date: Sun, 3 Oct 2010 06:14:09 -0700 From: David Wolfskill To: Andriy Gapon Message-ID: <20101003131409.GX1535@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Andriy Gapon , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> <20101003112859.GW1535@albert.catwhisker.org> <4CA86E73.9080707@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="reitHOQ4cdJB34v7" Content-Disposition: inline In-Reply-To: <4CA86E73.9080707@icyb.net.ua> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 13:14:10 -0000 --reitHOQ4cdJB34v7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 03, 2010 at 02:52:19PM +0300, Andriy Gapon wrote: > on 03/10/2010 14:28 David Wolfskill said the following: > [snipped] >=20 > Can't you just drop to DDB prompt and examine where the threads are? Eh -- thanks for the reality check; I needed that. :-} OK; I enabled the KDB & DDB options & rebuilt the kernel; 2nd reboot after "make installkernel" huhng as before. Now, unfortunately, the new laptop doesn't have a serial console, so below is hand-transcribed: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 524288K of memory above 4GB ignored Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #4 r213380: Sun Oct 3 04:35:15 PDT 2010 =2E.. ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered cd0 at ata3 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed ada0 at ata2 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, device =20 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. uhub7: 6 ports with 6 removable, self powered ugen2.2: at usbus2 bt Tracing pid 12 tid 100017 td 0xc94575a0 kdb_enter(c0c737ab,c0caf6cb,1,0,1,...) at 0xc06d992a =3D kdb_enter+0x3a scgetc(c0e21950,0,c0caf5f1,2a1,c9457644,...) at 0xc07930a8 =3D scgetc+0x568 sckbdevent)c92f7500,0,c0fb3ea0,c92f9400,c6da9c4c,...) at 0xc0793424 =3D sck= bdevent+0x1e4 kbdmux_intr(c92f7500,0,c92f9608,c6da9c78,c08e63e3,...) at 0xc069c86b =3D kb= dmux_intr+0x2b kbdmux_kbd_intr(c92f7500,1,c0ccd301,53,c9194a94,...) at 0xc069ce45 =3D kbdm= ux_kbd_intr+0x25 taskqueue_run(c9194a98,0,c0ccd301,4a,c6da9cb8,...) at 0xc08e63e3 =3D taskqu= eue_run+0xc3 taskqueue_swi_giant_run(0,0,c0cc37a5,4c3,c945a0b8,...) at 0xc08e6be6 =3D ta= skqueue_swi_giant_run+0x66 intr_event_execute_handlers(c91d37f8,c945a080,c0cc37a5,533,c945a0f0,...) at= 0xc087e655 =3D intr_event_execute_handlers+0x125 ithread_loop(c943f980,c6da9d28,c0cc3520,349,c91d37f8,...) at 0xc087f42f =3D= ithread_loop+-x9f fork_exit(c087f390,c943f980,c6da9d28) at 0xc087c3a8 =3D fork_exit+0xb8 fork_trampoline() at 0xc0bd5824 =3D fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc6da9d60, ebp =3D 0 --- db>=20 I used the "ps" command at that point to see that PID 12 is "[intr]", with the following assignments: PID state wmesg cmd 100072 I [irq15: ata1] 100071 I [irq14: ata0] 100070 I [irq12: psm0] 100069 I [irq1: atkbd0] 100067 I [irq19: cbb0 atapci+] 100064 I [irq17: fwohci0] 100045 I [irq1258: iwn0] 100044 I [irq1257: hdac0] 100035 I [irq122: uhci2 ehci0+] 100030 I [irq121: uhci1 ehci4] 100025 I [irq120: hpet0 ehci0*] 100023 I [irq19: acpi0] 100018 I [swi6: task queue] 100017 Run CPU 1 [swi6: Giant taskq] 100015 I [swi5: +] 100014 I [swi2: cambio] 100008 I [swi4: clock] 100007 I [swi4: clock] 100006 I [swi1: netisr 0] 100005 I [swi3: vm] I then tried "panic", but that does not appear to have been successful. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --reitHOQ4cdJB34v7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkyogaAACgkQmprOCmdXAD3OYwCfa1gtlVGzGFzQnaVcmhCIKUCS 1M4An2C8/G+j7o7L3ARHuQE+IM/Wp242 =ibbB -----END PGP SIGNATURE----- --reitHOQ4cdJB34v7-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 13:41:15 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4272C1065674 for ; Sun, 3 Oct 2010 13:41:15 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail941c35.nsolutionszone.com (mail941c35.nsolutionszone.com [209.235.152.131]) by mx1.freebsd.org (Postfix) with ESMTP id D877E8FC18 for ; Sun, 3 Oct 2010 13:41:14 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail941c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id o93DfBkw011434 for ; Sun, 3 Oct 2010 13:41:13 GMT Date: Sun, 3 Oct 2010 09:41:11 -0400 From: Derek Tattersall To: current@FreeBSD.org Message-ID: <20101003134111.GA98699@oriental.arm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-CSC: 0 X-CHA: v=1.1 cv=2hHc7UCzMB0CKmcVFN9PBDTmInQfOH1C8PynVZUvi2c= c=1 sm=1 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=-Ae4FPTvpqZWVLMiuAMA:9 a=GUyn5p-65itJroCGBS8GoTGS6q0A:4 a=CjuIK1q_8ugA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: Subject: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 13:41:15 -0000 In updating gnash to 8.8 the build failed while linking with libvgl.so. My current system was built last week, with both kernel and world built with clang. The linkage failure was due to an inlined function, "set4pixels" which is only referred to, as far as I can tell, within the source file simple.c which contains the function definition. I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at least in this case, that clang has some problems dealing with inlined functions. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 13:54:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C46B1065673 for ; Sun, 3 Oct 2010 13:54:51 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id E1FB58FC1B for ; Sun, 3 Oct 2010 13:54:50 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id 1889311B821; Sun, 3 Oct 2010 08:54:50 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id 74QDDOX8SNMC; Sun, 03 Oct 2010 08:54:50 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <20101003134111.GA98699@oriental.arm.org> Date: Sun, 3 Oct 2010 14:54:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9825922F-0808-4A60-97B7-2A6818FA409F@FreeBSD.org> References: <20101003134111.GA98699@oriental.arm.org> To: dlt@mebtel.net X-Mailer: Apple Mail (2.1081) Cc: current@FreeBSD.org Subject: Re: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 13:54:51 -0000 On 3 Oct 2010, at 14:41, Derek Tattersall wrote: > In updating gnash to 8.8 the build failed while linking with = libvgl.so. My > current system was built last week, with both kernel and world built > with clang. The linkage failure was due to an inlined function, > "set4pixels" which is only referred to, as far as I can tell, within = the > source file simple.c which contains the function definition. >=20 > I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at > least in this case, that clang has some problems dealing with inlined > functions. We are still in the process of identifying which ports have problems, = but we are aware that building ports with clang is not an easy job: = several ports assume a gcc behavior and there some LLVM/Clang problems = that need to be ironed out. Given this, we need some sort of way to identify ports that can be built = with clang, but that requires man-hours. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 14:04:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70A1C1065673 for ; Sun, 3 Oct 2010 14:04:28 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail962c35.nsolutionszone.com (mail962c35.nsolutionszone.com [209.235.152.152]) by mx1.freebsd.org (Postfix) with ESMTP id 141C38FC17 for ; Sun, 3 Oct 2010 14:04:27 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail962c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id o93E4PLm005639; Sun, 3 Oct 2010 14:04:26 GMT Date: Sun, 3 Oct 2010 10:04:25 -0400 From: Derek Tattersall To: Rui Paulo Message-ID: <20101003140425.GA98803@oriental.arm.org> References: <20101003134111.GA98699@oriental.arm.org> <9825922F-0808-4A60-97B7-2A6818FA409F@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9825922F-0808-4A60-97B7-2A6818FA409F@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-CSC: 0 X-CHA: v=1.1 cv=uVrN/md/HB0tP65KUyQDxMIwb8qE6v9oaXSvIWlxpDE= c=1 sm=1 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=6I5d2MoRAAAA:8 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=qLhAwP0VI7mI3CG8kv0A:9 a=2z0-z6XcfZcqZkgloxIA:7 a=er4h19l_Ptjy-15PX5RXyvOg2YEA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: current@freebsd.org Subject: Re: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 14:04:28 -0000 * Rui Paulo [101003 09:57]: > On 3 Oct 2010, at 14:41, Derek Tattersall wrote: > > > In updating gnash to 8.8 the build failed while linking with libvgl.so. My > > current system was built last week, with both kernel and world built > > with clang. The linkage failure was due to an inlined function, > > "set4pixels" which is only referred to, as far as I can tell, within the > > source file simple.c which contains the function definition. > > > > I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at > > least in this case, that clang has some problems dealing with inlined > > functions. > > We are still in the process of identifying which ports have problems, but we are aware that building ports with clang is not an easy job: several ports assume a gcc behavior and there some LLVM/Clang problems that need to be ironed out. > > Given this, we need some sort of way to identify ports that can be built with clang, but that requires man-hours. > > Regards, > -- > Rui Paulo I was not completely clear, I'm afraid. Gnash was built with gcc under all circumstances. libvgl.so is part of the world build and is installed in /usr/lib. It was originally built with clang when I built both the kernel and the world with clang last week. I found that building /usr/src/lib/libvgl with gcc was necessary to get gnash to build properly. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 15:21:09 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72DB7106566B for ; Sun, 3 Oct 2010 15:21:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 33EB88FC14 for ; Sun, 3 Oct 2010 15:21:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:9dad:5e85:9a1:37cf] (unknown [IPv6:2001:7b8:3a7:0:9dad:5e85:9a1:37cf]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0E15D5C43; Sun, 3 Oct 2010 17:21:08 +0200 (CEST) Message-ID: <4CA89F6B.8050108@FreeBSD.org> Date: Sun, 03 Oct 2010 17:21:15 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12pre) Gecko/20101001 Lanikai/3.1.5pre MIME-Version: 1.0 To: dlt@mebtel.net References: <20101003134111.GA98699@oriental.arm.org> In-Reply-To: <20101003134111.GA98699@oriental.arm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 15:21:09 -0000 On 2010-10-03 15:41, Derek Tattersall wrote: > In updating gnash to 8.8 the build failed while linking with libvgl.so. My > current system was built last week, with both kernel and world built > with clang. The linkage failure was due to an inlined function, > "set4pixels" which is only referred to, as far as I can tell, within the > source file simple.c which contains the function definition. The problem is that set4pixels() and another function set2lines() are defined as 'inline' functions in simple.c, but it is compiled with -std=gnu99. This means that these definitions cannot be called from another object file. So, either libvgl should be compiled with -std=gnu89, or somebody who knows about libvgl's "official" API should decide whether these functions must be externally accessible or not. Since libvgl looks very old (it was imported 8 years ago, and the last functional change was 6 years ago), the former is probably the easiest fix. > I rebuilt libvgl.so using gcc and gnash linked properly. It seems, at > least in this case, that clang has some problems dealing with inlined > functions. Since gnash has about a gazillion dependencies, and I have the idea that after 12 hours of building stuff, I will not be able to reproduce your error message anyway, could you please post it (or upload it, if it is very large)? Also, please note that building ports with clang is still experimental, although various people are actively working on it. And there are *many* ports that have totally broken configure scripts, or that just assume the only software in the world is GNU. :) See http://wiki.freebsd.org/PortsAndClang for some information (although it is a little outdated now), and a link to patches. Any help in this area is appreciated! From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 18:30:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 532321065670 for ; Sun, 3 Oct 2010 18:30:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D0D7E8FC14 for ; Sun, 3 Oct 2010 18:30:07 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P2TK0-0001lJ-Kn for freebsd-current@freebsd.org; Sun, 03 Oct 2010 20:30:04 +0200 Received: from 93-141-115-47.adsl.net.t-com.hr ([93.141.115.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Oct 2010 20:30:04 +0200 Received: from ivoras by 93-141-115-47.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Oct 2010 20:30:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 03 Oct 2010 20:24:27 +0200 Lines: 72 Message-ID: References: <4CA4BCD2.4070303@freebsd.org> <4CA5A1B1.7050902@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 93-141-115-47.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100620 Thunderbird/3.0.4 In-Reply-To: <4CA5A1B1.7050902@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 18:30:08 -0000 On 10/01/10 10:54, Andre Oppermann wrote: > On 30.09.2010 19:51, Ivan Voras wrote: >> On 09/30/10 18:37, Andre Oppermann wrote: >> >>> Both the vmmap and page table make use of splay trees to manage the >>> entries and to speed up lookups compared to long to traverse linked >>> lists or more memory expensive hash tables. Some structures though >>> do have an additional linked list to simplify ordered traversals. >> >> The property of splay tree requiring *writes* for nearly every read >> really is a thorn in the eye for SMP. It seems to me that even if the >> immediate benefits from converting to something else are not directly >> observable, it will still be worth doing it. > > Fully agreed. > >> It's a shame that RCU is still a patent minefield :/ >> >> http://mirror.leaseweb.com/kernel/people/npiggin/patches/lockless/2.6.16-rc5/radix-intro.pdf >> > > I'm not convinced that RCU is the only scalable way of sharing a > data structure across a possibly large number of CPU's. Of course, it's just well understood currently. > The term "lockless" is often used and frequently misunderstood. > Having a lockess data structure *doesn't* mean that is either > performant, scalable or both. It heavily depends on a number > of additional factors. Many times "lockless" just replaces a > simple lock/unlock cycle with a number of atomic operations on > the data structure. This can easily backfire because an atomic Yes. > operation just hides the computational complexity and also dirties > the CPU's cache lines. Generally on cache coherent architectures > almost all of the atomic operation is in HW with bus lock cycles, > bus snooping and whatnot. While seemingly simple form the programmers > point of view, the overhead and latency is still there. Needless Yes, you basically just offload the operation to hardware but the steps it needs to make are the same in concept. > a) make sure the lock is held for only a small amount of time > to avoid lock contention. > b) do everything you can outside of the lock. > c) if the lock is found to be heavily contended rethink the > whole approach and check if other data structures can be used. > d) minimize write accesses to memory in the lock protected > shared data structure. > e) PROFILE, DON'T SPECULATE! Measure the access pattern and > measure the locking/data access strategy's cost in terms > of CPU cycles consumed. > > f) on lookup heavy data structures avoid writing to memory and > by it dirtying CPU caches. > g) on modify heavy data structures avoid touching too many > elements. > h) on lookup and modify heavy data structure that are used > across many CPU's all bets are off and a different data > structure approach should be considered resulting ideally > in case f). > > It all starts with the hypothesis that a data structure is not > optimally locked. This looks like material for a developer-centric wiki page :) There is a lot of dispersed wisdom in this thread which would be nice if gathered in one place. From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 19:50:39 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CED47106566B; Sun, 3 Oct 2010 19:50:39 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 870848FC12; Sun, 3 Oct 2010 19:50:38 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id EB5CB9CB0F1; Sun, 3 Oct 2010 21:50:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1wOpJizMtsw; Sun, 3 Oct 2010 21:50:36 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 3F08C9CB16A; Sun, 3 Oct 2010 21:50:36 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o93JoZuO035712; Sun, 3 Oct 2010 21:50:35 +0200 (CEST) (envelope-from rdivacky) Date: Sun, 3 Oct 2010 21:50:35 +0200 From: Roman Divacky To: Dimitry Andric Message-ID: <20101003195035.GA35617@freebsd.org> References: <20101003134111.GA98699@oriental.arm.org> <4CA89F6B.8050108@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA89F6B.8050108@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: dlt@mebtel.net, current@FreeBSD.org Subject: Re: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 19:50:39 -0000 On Sun, Oct 03, 2010 at 05:21:15PM +0200, Dimitry Andric wrote: > On 2010-10-03 15:41, Derek Tattersall wrote: > >In updating gnash to 8.8 the build failed while linking with libvgl.so. My > >current system was built last week, with both kernel and world built > >with clang. The linkage failure was due to an inlined function, > >"set4pixels" which is only referred to, as far as I can tell, within the > >source file simple.c which contains the function definition. > > The problem is that set4pixels() and another function set2lines() are > defined as 'inline' functions in simple.c, but it is compiled with > -std=gnu99. This means that these definitions cannot be called from > another object file. > > So, either libvgl should be compiled with -std=gnu89, or somebody who > knows about libvgl's "official" API should decide whether these > functions must be externally accessible or not. Since libvgl looks very > old (it was imported 8 years ago, and the last functional change was 6 > years ago), the former is probably the easiest fix. we compile world with -std=gnu99 even with gcc, why isnt this problem with gcc? From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 20:30:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2714E106566C; Sun, 3 Oct 2010 20:30:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C03668FC0C; Sun, 3 Oct 2010 20:30:04 +0000 (UTC) Received: by iwn10 with SMTP id 10so1426888iwn.13 for ; Sun, 03 Oct 2010 13:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=L6CeD7PYXeofZOuulkj8l7TXoNJ4apB9WmZJ3kNAvFg=; b=QGnMu8nOCKUrHdQnrvW+pfZZ/CABPCFpaj91xcELpT2+J7h0zgIilF3/dGBUKv6dV6 +rRs4l1OCHFgutwfc/kh3jljrwsRT4wQ97nyKWnRHjLm8+xieVKSpnHMVYjkJgEy18Z9 YwzS/43UhQ1UyBB3Yij7X3lqZO3qLw5Qr06A4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=v+YIZdIdNMSCGgN5Fomnh5bvaqbxK1flXjXv19bHtAWvWxuRsE3tolAr531qAkZUpF jVoVchbDg2j7SEC9MivReMxZ9XeY6YwGcZDMam+pxkeZ5c0H2x0UG8CmLdvN+fWiyYsM T8TEglka3qUC1qhLDXxRtUFbBoeucW1vVMOl4= MIME-Version: 1.0 Received: by 10.231.161.16 with SMTP id p16mr9026639ibx.61.1286137803506; Sun, 03 Oct 2010 13:30:03 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.190.68 with HTTP; Sun, 3 Oct 2010 13:30:03 -0700 (PDT) In-Reply-To: <20101003195035.GA35617@freebsd.org> References: <20101003134111.GA98699@oriental.arm.org> <4CA89F6B.8050108@FreeBSD.org> <20101003195035.GA35617@freebsd.org> Date: Sun, 3 Oct 2010 13:30:03 -0700 X-Google-Sender-Auth: MyRkOTs-Ib42osmVJ2n2EULQNpA Message-ID: From: Garrett Cooper To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dlt@mebtel.net, Dimitry Andric , current@freebsd.org Subject: Re: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 20:30:05 -0000 On Sun, Oct 3, 2010 at 12:50 PM, Roman Divacky wrote= : > On Sun, Oct 03, 2010 at 05:21:15PM +0200, Dimitry Andric wrote: >> On 2010-10-03 15:41, Derek Tattersall wrote: >> >In updating gnash to 8.8 the build failed while linking with libvgl.so.= =A0My >> >current system was built last week, with both kernel and world built >> >with clang. =A0The linkage failure was due to an inlined function, >> >"set4pixels" which is only referred to, as far as I can tell, within th= e >> >source file simple.c which contains the function definition. >> >> The problem is that set4pixels() and another function set2lines() are >> defined as 'inline' functions in simple.c, but it is compiled with >> -std=3Dgnu99. =A0This means that these definitions cannot be called from >> another object file. >> >> So, either libvgl should be compiled with -std=3Dgnu89, or somebody who >> knows about libvgl's "official" API should decide whether these >> functions must be externally accessible or not. =A0Since libvgl looks ve= ry >> old (it was imported 8 years ago, and the last functional change was 6 >> years ago), the former is probably the easiest fix. > > we compile world with -std=3Dgnu99 even with gcc, why isnt this problem > with gcc? Has someone tried compiling with clang and c99, as opposed to gnu99? I'm curious as to whether or not the c99 implementation with clang is always correct, and if that works, whether or not the gnu99 implementation on gcc has a subtlety that isn't implemented properly on clang. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 22:34:29 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87C1A1065673 for ; Sun, 3 Oct 2010 22:34:29 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 46B9F8FC14 for ; Sun, 3 Oct 2010 22:34:29 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:9dad:5e85:9a1:37cf] (unknown [IPv6:2001:7b8:3a7:0:9dad:5e85:9a1:37cf]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2CD185C43; Mon, 4 Oct 2010 00:34:28 +0200 (CEST) Message-ID: <4CA904FB.4040105@FreeBSD.org> Date: Mon, 04 Oct 2010 00:34:35 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12pre) Gecko/20101001 Lanikai/3.1.5pre MIME-Version: 1.0 To: dlt@mebtel.net References: <20101003134111.GA98699@oriental.arm.org> <4CA89F6B.8050108@FreeBSD.org> In-Reply-To: <4CA89F6B.8050108@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 22:34:29 -0000 On 2010-10-03 17:21, Dimitry Andric wrote: > Since gnash has about a gazillion dependencies, and I have the idea that > after 12 hours of building stuff, I will not be able to reproduce your > error message anyway, could you please post it (or upload it, if it is > very large)? I cannot reproduce your problem, even after installing the gazillion dependencies. :) However, gnash has the same problem that a lot of other ports have: its configure script assumes the verbose output of a linking command has a certain format. The end result is almost always a linking error "hidden symbol `__dso_handle' in /usr/lib/crtbegin.o is referenced by DSO", or similar. That problem should be fixed by this patch: http://www.andric.com/freebsd/clang/graphics-gnash-clang.diff There is also a chance this might fix your issue, can you please try it out? From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 22:43:10 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E307D1065670 for ; Sun, 3 Oct 2010 22:43:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-36.mx.aerioconnect.net [216.240.47.96]) by mx1.freebsd.org (Postfix) with ESMTP id BF5738FC12 for ; Sun, 3 Oct 2010 22:43:10 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o93MgA0R017897; Sun, 3 Oct 2010 15:42:10 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 5737D2D6013; Sun, 3 Oct 2010 15:42:09 -0700 (PDT) Message-ID: <4CA906EB.5090305@freebsd.org> Date: Sun, 03 Oct 2010 15:42:51 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Wolfskill , Andriy Gapon , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> <20101003112859.GW1535@albert.catwhisker.org> <4CA86E73.9080707@icyb.net.ua> <20101003131409.GX1535@albert.catwhisker.org> In-Reply-To: <20101003131409.GX1535@albert.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 22:43:11 -0000 On 10/3/10 6:14 AM, David Wolfskill wrote: > On Sun, Oct 03, 2010 at 02:52:19PM +0300, Andriy Gapon wrote: >> on 03/10/2010 14:28 David Wolfskill said the following: >> [snipped] >> >> Can't you just drop to DDB prompt and examine where the threads are? > Eh -- thanks for the reality check; I needed that. :-} > > OK; I enabled the KDB& DDB options& rebuilt the kernel; 2nd reboot > after "make installkernel" huhng as before. > > Now, unfortunately, the new laptop doesn't have a serial console, so > below is hand-transcribed: > > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > 524288K of memory above 4GB ignored > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #4 r213380: Sun Oct 3 04:35:15 PDT 2010 > ... > ugen7.1: at usbus7 > uhub7: on usbus7 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > uhub3: 6 ports with 6 removable, self powered > cd0 at ata3 bus 0 scbus2 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed > ada0 at ata2 bus 0 scbus1 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) > SMP: AP CPU #1 Launched! > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > uhub7: 6 ports with 6 removable, self powered > ugen2.2: at usbus2 > > > KDB: enter: manual escape to debugger > [ thread pid 12 tid 100017 ] > Stopped at 0xc08d992a = kdb_enter+0x3a: movl $0,0xc0e33574 = kdb_why > db> bt > Tracing pid 12 tid 100017 td 0xc94575a0 > kdb_enter(c0c737ab,c0caf6cb,1,0,1,...) at 0xc06d992a = kdb_enter+0x3a > scgetc(c0e21950,0,c0caf5f1,2a1,c9457644,...) at 0xc07930a8 = scgetc+0x568 > sckbdevent)c92f7500,0,c0fb3ea0,c92f9400,c6da9c4c,...) at 0xc0793424 = sckbdevent+0x1e4 > kbdmux_intr(c92f7500,0,c92f9608,c6da9c78,c08e63e3,...) at 0xc069c86b = kbdmux_intr+0x2b > kbdmux_kbd_intr(c92f7500,1,c0ccd301,53,c9194a94,...) at 0xc069ce45 = kbdmux_kbd_intr+0x25 > taskqueue_run(c9194a98,0,c0ccd301,4a,c6da9cb8,...) at 0xc08e63e3 = taskqueue_run+0xc3 > taskqueue_swi_giant_run(0,0,c0cc37a5,4c3,c945a0b8,...) at 0xc08e6be6 = taskqueue_swi_giant_run+0x66 > intr_event_execute_handlers(c91d37f8,c945a080,c0cc37a5,533,c945a0f0,...) at 0xc087e655 = intr_event_execute_handlers+0x125 > ithread_loop(c943f980,c6da9d28,c0cc3520,349,c91d37f8,...) at 0xc087f42f = ithread_loop+-x9f > fork_exit(c087f390,c943f980,c6da9d28) at 0xc087c3a8 = fork_exit+0xb8 > fork_trampoline() at 0xc0bd5824 = fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc6da9d60, ebp = 0 --- > db> > > I used the "ps" command at that point to see that PID 12 is "[intr]", > with the following assignments: > > PID state wmesg cmd > 100072 I [irq15: ata1] > 100071 I [irq14: ata0] > 100070 I [irq12: psm0] > 100069 I [irq1: atkbd0] > 100067 I [irq19: cbb0 atapci+] > 100064 I [irq17: fwohci0] > 100045 I [irq1258: iwn0] > 100044 I [irq1257: hdac0] > 100035 I [irq122: uhci2 ehci0+] > 100030 I [irq121: uhci1 ehci4] > 100025 I [irq120: hpet0 ehci0*] > 100023 I [irq19: acpi0] > 100018 I [swi6: task queue] > 100017 Run CPU 1 [swi6: Giant taskq] > 100015 I [swi5: +] > 100014 I [swi2: cambio] > 100008 I [swi4: clock] > 100007 I [swi4: clock] > 100006 I [swi1: netisr 0] > 100005 I [swi3: vm] > > I then tried "panic", but that does not appear to have been successful. > > Peace, > david well you got the stacktrace of the keyboard handler since you got into ddb via the keyboard.. you need to see what ELSE is running.. especially the initial threads. and look at THOSE stacks I think "bt [thread-ID]" works or maybe "thread [ID]" (it's bee a year). From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 00:49:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210AC106566B; Mon, 4 Oct 2010 00:49:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id E2A498FC12; Mon, 4 Oct 2010 00:49:10 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o940nAvL004725; Sun, 3 Oct 2010 17:49:10 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o940nArO004724; Sun, 3 Oct 2010 17:49:10 -0700 (PDT) (envelope-from david) Date: Sun, 3 Oct 2010 17:49:10 -0700 From: David Wolfskill To: Julian Elischer Message-ID: <20101004004910.GD1410@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Julian Elischer , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> <20101003112859.GW1535@albert.catwhisker.org> <4CA86E73.9080707@icyb.net.ua> <20101003131409.GX1535@albert.catwhisker.org> <4CA906EB.5090305@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IDYEmSnFhs3mNXr+" Content-Disposition: inline In-Reply-To: <4CA906EB.5090305@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 00:49:12 -0000 --IDYEmSnFhs3mNXr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 03, 2010 at 03:42:51PM -0700, Julian Elischer wrote: > ... > well you got the stacktrace of the keyboard handler since you got into=20 > ddb via the keyboard.. OK.... > you need to see what ELSE is running.. especially the initial threads. > and look at THOSE stacks Ah. My lack of practice is showing. :-} > I think "bt [thread-ID]" works or maybe > "thread [ID]" (it's bee a year). OK. Armed with that, I tried to re-create the problem a few more times. First, I used loader.conf to: boot_verbose=3D"YES" dumpdev=3D"/dev/ada0s4b" And then just tried rebooting to single-user. I noticed, then, that for *successful* boots, I got start_init: trying /sbin/init Enter full pathname of shell or RETURN for bin/sh: *before* I saw ugen2.2: at usbus2 This, together with the observation that DDB's "ps" output showed just about everything other than interrupt threads in state "D" or "DL" encouraged me to check the backtraces for PID 1 (init) and PID 2 [g_event]. Hmm... actually going to single user on a successfull boot & issuing "ps axwwl" shows most things in stat "D" or "DL" normally, so maybe I'm chasing a "red herring." But at least in this case, init is not in a D state -- it's "ILs". Well, maybe this will be of some use anywya: battery0: battery initialization done, tried 1 times uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered (probe0:abp0:0:0:0): Error 22, Unretryable error (probe2:abp0:0:0:0): Error 22, Unretryable error (probe4:abp0:0:0:0): Error 22, Unretryable error (probe5:abp0:0:0:0): Error 22, Unretryable error (probe1:abp0:0:0:0): Error 22, Unretryable error (probe3:abp0:0:0:0): Error 22, Unretryable error (probe6:abp0:0:0:0): Error 22, Unretryable error GEOM: new disk cd0 (cd0:ata3:0:0:0): SCSI status error (cd0:ata3:0:0:0): Requesting SCSI sense data (cd0:ata3:0:0:0): SCSI status error (cd0:ata3:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata3:0:0:0): CAM status: SCSI Status Error (cd0:ata3:0:0:0): SCSI status: Check Condition (cd0:ata3:0:0:0): SCSI sense: NOT READY asc:3a, 1 (Medium not present - tra= y closed) (cd0:ata3:0:0:0): Error 6, Unretryable error cd0 at ata3 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed ada0 at ata2 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 5TH0BAZX ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) pass0 at ata2 bus 0 scbus2 target 0 lun 0 pass0: ATA-8 SATA 2.x device pass0: Serial Number 5TH0BAZX pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) pass1 at ata3 bus 0 scbus2 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device=20 pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x00000000 CPU1: local APIC error 0x80 ooapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48f wtable ciloeaapniecr0 :s troaurttiendg intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 51 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 52 msi: Assigning MSI IRQ 257 to local APIC 1 vector 53 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen2.2: at usbus2 battery1: battery initialization failed, giving up KDB: enter: manual escape to debugger [ thread pid 12 tid 100017 ] Stopped at 0xc08d992a =3D kdb_enter+0x3a: movl $0,0xc0e33574 =3D = kdb_why db> show locks exclusive sleep mutex Giant (Giant) r =3D 1 (0xc0e21950) locked @ /usr/src/= sys/dev/syscons/syscons.c:673 db> bt 1 Tracing pid 1 tid 100002 td 0xc91d6b40 sched_switch(c91d6b40,0,104,191,a4bfdaac,...) at 0xc08cccec =3D sched_switc= h+0x3bc mi_switch(104,0,c0cccb89,1f3,68,...) at 0xc08af3a0 =3D mi_switch+0x200 sleepq_switch(c91d6b40,0,c0cccb89,28b,0,...) at 0xc08e4b7b =3D sleepq_switc= h+0x15f sleepq_timedwait(c0e1fc24,69,c0cbe3e4,0,0,...) at 0xc08e4b7b =3D sleepq_tim= edwait+0x6b _sleep(c0e1fc24,c0e1fc28,68,c0cbe3e4,c8,...) at 0xc08af892 =3D _sleep+0x342 g_waitidle(c0e21950,0,c0cd59c7,a2,29e,...) at 0xc083ee90 =3D g_waitidle+0xc0 vfs_mountroot(c0e21950,4,c0cc12a9,2a0,0,...) at 0xc09378c8 =3D vfs_mountroo= t+0x98 start_init(0,c6d76d28,c0cc3520,349,c91d3d48,...) at 0xc085f2b5 =3D start_in= it+0x65 fork_exit(c085f250,0,c6d76d28) at 0xc087c3a8 =3D fork_exit+0xb8 fork_trampoline() at 0xc0bd5824 =3D fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc6d76d60, ebp =3D 0 --- db> bt 2 sched_switch(c922f000,0,104,191,d0c3a239,...) at 0xc08cccec =3D sched_switc= h+0x3bc mi_switch(104,0,c0cccb89,1f3,4c,...) at 0xc08af3a0 =3D mi_switch+0x200 sleepq_switch(c922f000,0,c0cccb89,268,0,...) at 0xc08e3f6f =3D sleepq_switc= h+0x15f sleepq_wait(c959e7bc,4c,c0c644ec,0,0,...) at 0xc08e4c73 =3D sleepq_wait+0x63 _sleep(c959e7bc,c9b31d74,4c,c0c644ec,0,...) at 0xc08af8c2 =3D _sleep+0x372 cam_periph_getccb(c959e780,480,80246,c91462e0,c922f0a4,480) at 0xc04860af = =3D cam_periph_getccb+0xaf cdgetccb(c0dc7914,c0c64915,c922f000,c0e00998,12d2,...) at 0xc0499e08 =3D cd= getccb+0xd8 cdprevent(14c,c6d8db64,c04883ca,c0e00998,0,...) at 0xc049a602 =3D cdprevent= +0c52 cdcheckmedia(c959e780,14c,c0c659d6,bc,0,...) at 0xc049a6a9 =3D cdcheckmedia= +0x19 cdopen(c953aa00,4,c0cbdd7f,76,0,...) at 0xc049bb2d =3D cdopen+0xed g_disk_access(ca8c5e80,1,0,0,ca8c5ed8,...) at 0xc083ddcd =3D g_disk_access+= 0x11d g_access(ca8c5680,1,0,0,ca8c5ed8,...) at 0xc084365e =3D g_access+0x23e g_part_taste(c0dbcca0,ca8c5e80,0,228,ca8c5d80,...) at 0xc084a0a6 =3D g_part= _taste+0xc6 g_new_provider_event(ca8c5e80,0,c0cbe313,d9,c922f000,...) at 0xc0843316 =3D= g_new_provider_event+0xb6 g_run_events(c0e1fcd8,0,4c,c0ce99a5,64,...) at 0xc083f290 =3D g_run_events+= 0x3c0 g_event_procbody(0,c6d8dd28,c0cc3520,349,c91d3550,...) at 0xc0840d8a =3D g_= event_procbody+0x8a fork_exit(c0840d00,0,c6d8dd28) at 0xc087c3a8 =3D fork_exit+0xb8 fork_trampoline() at 0xc0bd5824 =3D fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc6d8dd60, ebp =3D 0 --- db>=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --IDYEmSnFhs3mNXr+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkypJIUACgkQmprOCmdXAD0qtACeP2UStN5sdWvloO/Ian6G/d6e bdEAn37vWKaP85QlM2Of9vPqI44iKCLT =RK7e -----END PGP SIGNATURE----- --IDYEmSnFhs3mNXr+-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 02:16:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 203881065674 for ; Mon, 4 Oct 2010 02:16:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 049488FC17 for ; Mon, 4 Oct 2010 02:16:55 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o942GtjY012966 for ; Sun, 3 Oct 2010 19:16:55 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o942Gtn0012965 for freebsd-current@freebsd.org; Sun, 3 Oct 2010 19:16:55 -0700 (PDT) (envelope-from sgk) Date: Sun, 3 Oct 2010 19:16:55 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20101004021655.GA12956@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: dmesg mangled by acd0 probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 02:16:56 -0000 I suspect that 517 ( are not expected during boot. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((cd0 at ata0 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! Root mount waiting for: usbus6 usbus2 -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 03:05:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED9D51065696; Mon, 4 Oct 2010 03:05:50 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A7C3F8FC17; Mon, 4 Oct 2010 03:05:50 +0000 (UTC) Received: by iwn10 with SMTP id 10so1773149iwn.13 for ; Sun, 03 Oct 2010 20:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MZd/GVO+sKCs3wJaqPYz6bfhSUk+oUetnfoH2kmQ3kE=; b=ctk60mo03KVEQW1JzDN3L+T1TdYmD4OUH6Nm7Vg/Wx0So8Xaag1PB63t4PVIpkPnlT Zq2HyCiBggZHKEU9Yd3uWAxL7gEV9Yz1k7pef/wXCkHL1hphzOHFkZ6fq1sLBvd05+X+ Yz2dsvl8KLpXluSx4C8IYvKvv2b6OlJMVQb5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LmDmddO90NSF74QseGaBrV0Me8TAEPRy8wOlmawVlbXAP25Szc6iqIBqJmbQyIGrut YHX85R0tjGarD+bCYe2210hhQ5ufWSoYCb508CPie5/VukdWzwkkT7fRZLnTj7c58TBu pbGubRaK0+DWbfH+dcZli89LLNXcARWxcDWqs= MIME-Version: 1.0 Received: by 10.231.191.147 with SMTP id dm19mr9461806ibb.6.1286161549926; Sun, 03 Oct 2010 20:05:49 -0700 (PDT) Received: by 10.231.167.140 with HTTP; Sun, 3 Oct 2010 20:05:49 -0700 (PDT) In-Reply-To: <20101004021655.GA12956@troutmask.apl.washington.edu> References: <20101004021655.GA12956@troutmask.apl.washington.edu> Date: Sun, 3 Oct 2010 20:05:49 -0700 Message-ID: From: Matthew Fleming To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: dmesg mangled by acd0 probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 03:05:51 -0000 On Sun, Oct 3, 2010 at 7:16 PM, Steve Kargl wrote: > I suspect that 517 ( are not expected during boot. > > > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 > (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((= (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((= (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((= (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((= (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((= (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((= (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((cd0 at ata0 = bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device Does this always happen with acd0? There was another instance I think mav@ saw for a different driver that showed up when I made the sbuf drain additions. I can't think of how my code could cause that, but there's always a possibility. Thanks, matthew > cd0: 33.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > SMP: AP CPU #1 Launched! > Root mount waiting for: usbus6 usbus2 > > > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 03:30:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1535F106566C; Mon, 4 Oct 2010 03:30:43 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id C60208FC14; Mon, 4 Oct 2010 03:30:42 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o943UgCU013310; Sun, 3 Oct 2010 20:30:42 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o943UgiX013309; Sun, 3 Oct 2010 20:30:42 -0700 (PDT) (envelope-from sgk) Date: Sun, 3 Oct 2010 20:30:42 -0700 From: Steve Kargl To: Matthew Fleming Message-ID: <20101004033042.GA13286@troutmask.apl.washington.edu> References: <20101004021655.GA12956@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: dmesg mangled by acd0 probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 03:30:43 -0000 On Sun, Oct 03, 2010 at 08:05:49PM -0700, Matthew Fleming wrote: > On Sun, Oct 3, 2010 at 7:16 PM, Steve Kargl > wrote: > > I suspect that 517 ( are not expected during boot. > > > > > > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (517 '(' deleted) > > cd0 at ata0 bus 0 scbus1 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 device > > Does this always happen with acd0? There was another instance I think > mav@ saw for a different driver that showed up when I made the sbuf > drain additions. I can't think of how my code could cause that, but > there's always a possibility. This is first time I spotted this output. My /usr/src and kernel/world are from Oct 1, roughly 2000 PST. Looking through /var/log/message, the string of '(' show up after the acd0 probes and once here: Oct 2 15:58:30 laptop kernel: drm0: [ITHREAD] Oct 2 15:59:24 laptop kernel: (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((g_vfs_done():da1s1[WRITE(offset=512, length=4096)]error = 13 Oct 2 15:59:24 laptop kernel: (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((g_vfs_done():da1s1[WRITE(offset=512, length=4096)]error = 13 I don't know if it matters, but for this kernel I have the following commented out #options INVARIANTS #options INVARIANT_SUPPORT #options WITNESS #options WITNESS_SKIPSPIN Is there a kernel option or patch you want me to use to get additional information? -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 03:52:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A83D1065672; Mon, 4 Oct 2010 03:52:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id EFFDA8FC12; Mon, 4 Oct 2010 03:52:47 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o943qlx3013390; Sun, 3 Oct 2010 20:52:47 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o943qleb013389; Sun, 3 Oct 2010 20:52:47 -0700 (PDT) (envelope-from sgk) Date: Sun, 3 Oct 2010 20:52:47 -0700 From: Steve Kargl To: Matthew Fleming Message-ID: <20101004035247.GA13382@troutmask.apl.washington.edu> References: <20101004021655.GA12956@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: dmesg mangled by acd0 probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 03:52:48 -0000 On Sun, Oct 03, 2010 at 08:05:49PM -0700, Matthew Fleming wrote: > > Does this always happen with acd0? The long string of '(' appeared in 5 out of 5 'shutdown -r now'. So, this is definitely reproducible for me. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 03:56:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC38B106566B; Mon, 4 Oct 2010 03:56:12 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAEC8FC0C; Mon, 4 Oct 2010 03:56:12 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 23AC712543B; Mon, 4 Oct 2010 12:37:26 +0900 (JST) Date: Mon, 4 Oct 2010 12:37:25 +0900 From: Daichi GOTO To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-Id: <20101004123725.65d09b9e.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 03:56:12 -0000 It looks very strange. fcntl() always fails to delete lock file and command.l_pid is always -6464. This issue is disclosed in porting Google's Japanese input system called "mozc". details follow: http://code.google.com/p/mozc/issues/detail?id=40 % uname -a FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 root@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL amd64 % My home directory on NFS server. Does anyone have any ideas? -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 04:58:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADAF7106566C for ; Mon, 4 Oct 2010 04:58:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 32CC18FC08 for ; Mon, 4 Oct 2010 04:58:56 +0000 (UTC) Received: by bwz15 with SMTP id 15so4506279bwz.13 for ; Sun, 03 Oct 2010 21:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=8IGKm/9AiFdaJlLSxF0axQxt2DhDPxYBqjB66WZRhao=; b=hhsI2OLYLXAXZqAHKwDhbf7ONvJB+acAj5/g2IMQPFZNmsjZ6FAv16VdD68lCMM7YB 878SymRm46Spgetu9/jq59jEIW9LpkpHuZPZg6SMWWC1z1A1R7SHdv1UL/T/pzLdPVxh B//T6qXdWxIHRqQF/T9ER8m3ZuyMy1aDa2xcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=uTIiURkpxncHI2CB0uh50hJ1nhHjwtWw1bGOH80+sjWjp4t0nNoysPFEM/rCkT4v9D 1UkpIZVKClfn4C1Y3zmZVo0iph/bXCnUCsyzIdAEZnMoQ0p2o37r9FbHmOzDEfw/J51v tFXatJFlZeCgmabE2koviawIZ8jvwqYCJuhEw= Received: by 10.204.73.211 with SMTP id r19mr6434888bkj.131.1286168335922; Sun, 03 Oct 2010 21:58:55 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d27sm3298601bku.10.2010.10.03.21.58.53 (version=SSLv3 cipher=RC4-MD5); Sun, 03 Oct 2010 21:58:54 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CA95F05.4050400@FreeBSD.org> Date: Mon, 04 Oct 2010 07:58:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Matthew Fleming References: <20101004021655.GA12956@troutmask.apl.washington.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: dmesg mangled by acd0 probe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 04:58:57 -0000 Matthew Fleming wrote: > On Sun, Oct 3, 2010 at 7:16 PM, Steve Kargl > wrote: >> I suspect that 517 ( are not expected during boot. >> >> >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((cd0 at ata0 bus 0 scbus1 target 0 lun 0 >> cd0: Removable CD-ROM SCSI-0 device > > Does this always happen with acd0? There was another instance I think > mav@ saw for a different driver that showed up when I made the sbuf > drain additions. I can't think of how my code could cause that, but > there's always a possibility. I indeed saw that thing. But it gone after few days. AFAIR kib@ fixed missing "++" somewhere there, but I haven't checked especially. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 05:05:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 301D6106564A for ; Mon, 4 Oct 2010 05:05:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D968D8FC13 for ; Mon, 4 Oct 2010 05:05:12 +0000 (UTC) Received: by iwn10 with SMTP id 10so1883183iwn.13 for ; Sun, 03 Oct 2010 22:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qK+IPUx355CreqOQa3BHUD675ChlcyfksF757/I/VDQ=; b=KFVqGV8qZj64Y3h1LD58Oo1HdM3SwH1m+6nMugtfdeDBBFYl+K8/JKuf0L0Q3jOVcp 2yDkUlIBpi+d21dGNhcsOluk8uvzbgJSBWLvAxPQk3s4ORs4myOnnftYQxBdfakAoBKx qJk4JTEltt3aszdCAIK5fsbfT5MMAYnrwAu3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WSUw3EKPC2FoGJRBJG7FBSu/bPwSomrJ7/vHCVOr7ozPuI4laGhm1lFsetkrAyIhFN 9M4f72q8mOrpHS3/9Lymey3QP+5+iK4jYIaKd0jdeyf8DTU4e9Nx+0raNyO4USpzWteN 7iXO07KNUk1zETOxAOFb/dZrWk2Ytqy31SV8M= MIME-Version: 1.0 Received: by 10.231.182.201 with SMTP id cd9mr9591344ibb.21.1286168712174; Sun, 03 Oct 2010 22:05:12 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.190.68 with HTTP; Sun, 3 Oct 2010 22:05:12 -0700 (PDT) In-Reply-To: <20101004123725.65d09b9e.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> Date: Sun, 3 Oct 2010 22:05:12 -0700 X-Google-Sender-Auth: QQ0cDYuvaGg3Nc64JvVHKc8Ae0M Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 05:05:13 -0000 On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO wrote: > It looks very strange. fcntl() always fails to delete lock file > and command.l_pid is always -6464. This issue is disclosed in > porting Google's Japanese input system called "mozc". > > =A0details follow: > =A0 =A0http://code.google.com/p/mozc/issues/detail?id=3D40 > > % uname -a > FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: = Thu Sep 30 10:30:06 JST 2010 =A0 =A0 root@parancell.ongs.co.jp:/usr/obj/usr= /src/sys/PARANCELL =A0amd64 > % > > My home directory on NFS server. =A0Does anyone have any ideas? I see some bad assumptions in the code: const int result =3D ::fcntl(*fd, F_SETLK, &command); if (-1 =3D=3D result) { // failed ::close(*fd); LOG(WARNING) << "already locked"; return false; // another server is already running } If the developer actually coded to POSIX expectations, he/she would be checking for EACCES/EAGAIN; there are a myriad of other issues that might be occurring with the software, as per my copy of SUSv4 (see the ERRORS section of fcntl). I would print out the strerror for that case. Providing a backtrace of the application's execution and the architecture and what version of FreeBSD you're using would be helpful. Thanks, -Garrett PS Quickly looking over this code, it has portability issues assuming that all Unix based OSes (that aren't under some Mac OSX guard) are Linux, based on the number of /proc filesystem opens and reads I see in the code. From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 05:08:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79148106564A; Mon, 4 Oct 2010 05:08:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4838FC15; Mon, 4 Oct 2010 05:08:31 +0000 (UTC) Received: by iwn10 with SMTP id 10so1886391iwn.13 for ; Sun, 03 Oct 2010 22:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=T8sJlTX6m2VXUPw3MEsCAwwXYVgfNMFwyV/D1H71fiY=; b=pkz3ha9QjaB+Oc8SjQ4+3LrbVYJWsGeIRHeJuXstAF3NRXQEjr3YqlJHAHw7n8zSJm MWCsmw51Dt/QyiqBWv+o7z8d4A5l7QvRf9SzJocZt91pB8mAjDZnGg+rYhtSr28NR3Ej wZ/Ehy2UaZMba5jdnGK2yFnKA5WuBmsUe2W8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=t3Hd8ncsIL5DWFrW9M+X2EVvLdWqaWu1zuMZSM7l9lyXMU+EDDI1vq6ru7INmj/dx3 /s1CGbzqzaRglyNo+ia4dndkOafbSlvinOTtYkwka2KRLZ/D8BPbWPaRLnNoh0jgUFIm F4Jdm/mndwrP3UDDTa26GQ3+CXYZhPVZGBvdk= MIME-Version: 1.0 Received: by 10.231.36.8 with SMTP id r8mr4848856ibd.128.1286168911251; Sun, 03 Oct 2010 22:08:31 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.190.68 with HTTP; Sun, 3 Oct 2010 22:08:31 -0700 (PDT) In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> Date: Sun, 3 Oct 2010 22:08:31 -0700 X-Google-Sender-Auth: wFNpcEJfI6OajxaH5pYis1Yk-Ic Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Daichi GOTO Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 05:08:32 -0000 On Sun, Oct 3, 2010 at 10:05 PM, Garrett Cooper wrote= : > On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO wrote: >> It looks very strange. fcntl() always fails to delete lock file >> and command.l_pid is always -6464. This issue is disclosed in >> porting Google's Japanese input system called "mozc". >> >> =A0details follow: >> =A0 =A0http://code.google.com/p/mozc/issues/detail?id=3D40 >> >> % uname -a >> FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257:= Thu Sep 30 10:30:06 JST 2010 =A0 =A0 root@parancell.ongs.co.jp:/usr/obj/us= r/src/sys/PARANCELL =A0amd64 >> % >> >> My home directory on NFS server. =A0Does anyone have any ideas? > > > =A0 =A0I see some bad assumptions in the code: > > =A0 =A0const int result =3D ::fcntl(*fd, F_SETLK, &command); > =A0 =A0if (-1 =3D=3D result) { =A0// failed > =A0 =A0 =A0::close(*fd); > =A0 =A0 =A0LOG(WARNING) << "already locked"; > =A0 =A0 =A0return false; =A0 // another server is already running > =A0 =A0} > > =A0 =A0If the developer actually coded to POSIX expectations, he/she > would be checking for EACCES/EAGAIN; there are a myriad of other > issues that might be occurring with the software, as per my copy of > SUSv4 (see the ERRORS section of fcntl). I would print out the > strerror for that case. > =A0 =A0Providing a backtrace of the application's execution and the > architecture and what version of FreeBSD you're using would be > helpful. > Thanks, > -Garrett > > PS Quickly looking over this code, it has portability issues assuming > that all Unix based OSes (that aren't under some Mac OSX guard) are > Linux, based on the number of /proc filesystem opens and reads I see > in the code. Sorry... missed some of the details in spite of the trees (FreeBSD version in particular). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 05:49:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9C551065670; Mon, 4 Oct 2010 05:49:28 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id B30468FC0A; Mon, 4 Oct 2010 05:49:28 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 9A87312543B; Mon, 4 Oct 2010 14:49:27 +0900 (JST) Date: Mon, 4 Oct 2010 14:49:27 +0900 From: Daichi GOTO To: freebsd-current@freebsd.org, gcooper@FreeBSD.org, freebsd-fs@freebsd.org Message-Id: <20101004144927.36822f07.daichi@ongs.co.jp> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 05:49:29 -0000 On Sun, 3 Oct 2010 22:05:12 -0700 Garrett Cooper wrote: > On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO wrote: > > It looks very strange. fcntl() always fails to delete lock file > > and command.l_pid is always -6464. This issue is disclosed in > > porting Google's Japanese input system called "mozc". > > > >  details follow: > >    http://code.google.com/p/mozc/issues/detail?id=40 > > > > % uname -a > > FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010     root@parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL  amd64 > > % > > > > My home directory on NFS server.  Does anyone have any ideas? > > > I see some bad assumptions in the code: > > const int result = ::fcntl(*fd, F_SETLK, &command); > if (-1 == result) { // failed > ::close(*fd); > LOG(WARNING) << "already locked"; > return false; // another server is already running > } > > If the developer actually coded to POSIX expectations, he/she > would be checking for EACCES/EAGAIN; there are a myriad of other It was EAGAIN, when I checked. And -6464 is very strange.... It should be -1 when it fails with EGAIN according to FreeBSD fcntl(2) manual. Repeat is easy: # cd /usr/ports/japanese/mozc-server/ # rm files/patch-server_mozc_server.cc # make WITH_DEBUG_CODE=yes install clean % mozc_server ^C --> in this timing, lock files should be deleted, but not working. % mozc_server --> so server will not run and finish soon % % cat ~/.mozc/mozc_server.log > issues that might be occurring with the software, as per my copy of > SUSv4 (see the ERRORS section of fcntl). I would print out the > strerror for that case. > Providing a backtrace of the application's execution and the > architecture and what version of FreeBSD you're using would be > helpful. > Thanks, > -Garrett -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 07:18:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 427DE1065673 for ; Mon, 4 Oct 2010 07:18:24 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id CF2C68FC0A for ; Mon, 4 Oct 2010 07:18:23 +0000 (UTC) Received: by wwb17 with SMTP id 17so6301620wwb.31 for ; Mon, 04 Oct 2010 00:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=3A9DZKncomfiK4Fb54Gsa0QeZJwKeS9XMdkM4n/13u4=; b=JUDzgMovEuCH346RpBaIxPLQu4FcF5AH9AehQDre22u8ko7pjffSqzZWDT28v+ZDpA fkbLXYGYxNGOkcZ8plGjY79O1ya8wdxdAxGFWg+Yiybutpj66PIMO/uapkpCXyWGq89u rr7XGcA8FVvAQFUu3ZxrZPVOb/7XtzyDL+1Xk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=GWvqTY4b/7cKEMWMvZiad+rxG/7hI04kgNlBXwnH9NsleHx316oQkfJRL51oVL8ZB8 JxJBXDSElmqR5kUVs+N35h5UU3ZaZw0KpsIl24jlcsc4lKvWrAxpEWbz1nMxYC01P/RD 3CAXHmK5HShiIQEQdM9r/OerD/v2X+wqDdBBc= MIME-Version: 1.0 Received: by 10.227.24.141 with SMTP id v13mr7119175wbb.210.1286176702762; Mon, 04 Oct 2010 00:18:22 -0700 (PDT) Sender: giovanni.trematerra@gmail.com Received: by 10.227.144.203 with HTTP; Mon, 4 Oct 2010 00:18:22 -0700 (PDT) Date: Mon, 4 Oct 2010 09:18:22 +0200 X-Google-Sender-Auth: UOoevgjXC8HgTLibvpmyCIvFIVQ Message-ID: From: Giovanni Trematerra To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: [PATCH] panic on boot with QEMU a multiple cpu emulated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 07:18:24 -0000 Qemu 0.11.1 installed from port with -CURRENT as host, emulating 8 CPU on a 8-way box makes my FreeBSD -CURRENT guest kernel, panic with this bt at boot: panic: sched_priority: invalid priority 230: nice 0, ticks 2289712 ftick 353 ltick 1363 tick pri 50 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x182 sched_priority() at sched_priority+0x1f8 sched_clock() at sched_clock+0x136 statclock() at statclock+0xc6 handleevents() at handleevents+0xda timercb() at timercb+0x1cb lapic_handle_timer() at lapic_handle_timer+0xb2 Xtimerint() at Xtimerint+0x8d The panic is due a KASSERT in sched_priority (sched_ule.c) KASSERT(pri >= PRI_MIN_TIMESHARE && pri <= PRI_MAX_TIMESHARE, ("sched_priority: invalid priority %d: nice %d, " "ticks %d ftick %d ltick %d tick pri %d", pri, td->td_proc->p_nice, td->td_sched->ts_ticks, td->td_sched->ts_ftick, td->td_sched->ts_ltick, SCHED_PRI_TICKS(td->td_sched))); ts->ts_ticks is higher than what you could expect. I figured out that sched_tick is being passed a huge number of ticks elapsed for the cpu at startup by hardclock_anycpu (kern_clock.c). I assume that QEMU is not doing a proper job of distributing run-time amongst cores. My hack, below, will assure that we won't be running for more than 5s solid, if we have a huge number of ticks in input to sched_tick, which is something that ULE can still handle. I don't think it's worth to have the hack into the tree for now. I'm just posting it FYI. -- Gianni diff -r d16464301129 sys/kern/kern_clock.c --- a/sys/kern/kern_clock.c Thu Sep 23 11:56:35 2010 -0400 +++ b/sys/kern/kern_clock.c Sun Oct 03 17:53:39 2010 -0400 @@ -525,7 +525,7 @@ hardclock_anycpu(int cnt, int usermode) PROC_SUNLOCK(p); } thread_lock(td); - sched_tick(cnt); + sched_tick((cnt < (hz*10)/2) ? cnt : (hz*10)/2); td->td_flags |= flags; thread_unlock(td); From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 07:45:04 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 092581065670 for ; Mon, 4 Oct 2010 07:45:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0C58FC0A for ; Mon, 4 Oct 2010 07:45:02 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA24905; Mon, 04 Oct 2010 10:44:20 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P2fie-000N1I-1c; Mon, 04 Oct 2010 10:44:20 +0300 Message-ID: <4CA985D2.3000805@icyb.net.ua> Date: Mon, 04 Oct 2010 10:44:18 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Wolfskill , Julian Elischer , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> <20101003112859.GW1535@albert.catwhisker.org> <4CA86E73.9080707@icyb.net.ua> <20101003131409.GX1535@albert.catwhisker.org> <4CA906EB.5090305@freebsd.org> <20101004004910.GD1410@albert.catwhisker.org> In-Reply-To: <20101004004910.GD1410@albert.catwhisker.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: [geom, cam] Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 07:45:04 -0000 on 04/10/2010 03:49 David Wolfskill said the following: > db> bt 1 > Tracing pid 1 tid 100002 td 0xc91d6b40 > sched_switch(c91d6b40,0,104,191,a4bfdaac,...) at 0xc08cccec = sched_switch+0x3bc > mi_switch(104,0,c0cccb89,1f3,68,...) at 0xc08af3a0 = mi_switch+0x200 > sleepq_switch(c91d6b40,0,c0cccb89,28b,0,...) at 0xc08e4b7b = sleepq_switch+0x15f > sleepq_timedwait(c0e1fc24,69,c0cbe3e4,0,0,...) at 0xc08e4b7b = sleepq_timedwait+0x6b > _sleep(c0e1fc24,c0e1fc28,68,c0cbe3e4,c8,...) at 0xc08af892 = _sleep+0x342 > g_waitidle(c0e21950,0,c0cd59c7,a2,29e,...) at 0xc083ee90 = g_waitidle+0xc0 > vfs_mountroot(c0e21950,4,c0cc12a9,2a0,0,...) at 0xc09378c8 = vfs_mountroot+0x98 > start_init(0,c6d76d28,c0cc3520,349,c91d3d48,...) at 0xc085f2b5 = start_init+0x65 > fork_exit(c085f250,0,c6d76d28) at 0xc087c3a8 = fork_exit+0xb8 > fork_trampoline() at 0xc0bd5824 = fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc6d76d60, ebp = 0 --- > db> bt 2 > sched_switch(c922f000,0,104,191,d0c3a239,...) at 0xc08cccec = sched_switch+0x3bc > mi_switch(104,0,c0cccb89,1f3,4c,...) at 0xc08af3a0 = mi_switch+0x200 > sleepq_switch(c922f000,0,c0cccb89,268,0,...) at 0xc08e3f6f = sleepq_switch+0x15f > sleepq_wait(c959e7bc,4c,c0c644ec,0,0,...) at 0xc08e4c73 = sleepq_wait+0x63 > _sleep(c959e7bc,c9b31d74,4c,c0c644ec,0,...) at 0xc08af8c2 = _sleep+0x372 > cam_periph_getccb(c959e780,480,80246,c91462e0,c922f0a4,480) at 0xc04860af = cam_periph_getccb+0xaf > cdgetccb(c0dc7914,c0c64915,c922f000,c0e00998,12d2,...) at 0xc0499e08 = cdgetccb+0xd8 > cdprevent(14c,c6d8db64,c04883ca,c0e00998,0,...) at 0xc049a602 = cdprevent+0c52 > cdcheckmedia(c959e780,14c,c0c659d6,bc,0,...) at 0xc049a6a9 = cdcheckmedia+0x19 > cdopen(c953aa00,4,c0cbdd7f,76,0,...) at 0xc049bb2d = cdopen+0xed > g_disk_access(ca8c5e80,1,0,0,ca8c5ed8,...) at 0xc083ddcd = g_disk_access+0x11d > g_access(ca8c5680,1,0,0,ca8c5ed8,...) at 0xc084365e = g_access+0x23e > g_part_taste(c0dbcca0,ca8c5e80,0,228,ca8c5d80,...) at 0xc084a0a6 = g_part_taste+0xc6 > g_new_provider_event(ca8c5e80,0,c0cbe313,d9,c922f000,...) at 0xc0843316 = g_new_provider_event+0xb6 > g_run_events(c0e1fcd8,0,4c,c0ce99a5,64,...) at 0xc083f290 = g_run_events+0x3c0 > g_event_procbody(0,c6d8dd28,c0cc3520,349,c91d3550,...) at 0xc0840d8a = g_event_procbody+0x8a > fork_exit(c0840d00,0,c6d8dd28) at 0xc087c3a8 = fork_exit+0xb8 > fork_trampoline() at 0xc0bd5824 = fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc6d8dd60, ebp = 0 --- Interesting! So, init thread is blocked in vfs_mountroot()->g_waitidle() waiting for geom to complete probing cd device, but the latter is blocked in cam_periph_getccb() waiting for a ccb. Can you try to reproduce this again and examine other thread for anything interesting in geom/cam department? Thread named as "xpt_thrd" might be of particular interest. We urgently need geom and cam experts here :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 10:22:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A8A31065675 for ; Mon, 4 Oct 2010 10:22:55 +0000 (UTC) (envelope-from mayur.shardul@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id E5C578FC1A for ; Mon, 4 Oct 2010 10:22:54 +0000 (UTC) Received: by qyk8 with SMTP id 8so2965095qyk.13 for ; Mon, 04 Oct 2010 03:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=MVqLoRNkD2wl+YckhEtiIL1tWVlWGlP5AmrUkWTmUDI=; b=MrEsVRVs2FekUkVqlwp6mqYm+Q8oZwzOoU/ViKZ3yQE0sVyJzC2krTWieZAm2+7F5h QGWEpONedxCXctZZkqx5nVUyox7SzQq9CN14nO919K/uOSuTjJ4F3PobBkn35XXOKhvj 9HWLKJIEoIQjnPqU8g21obUjOXbDSm1xUvCHI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WNZpOCHQZpi3bpfGb5DTbogGp0na7stC8pY5dQWVPnRTKwmBCGPkvn+ShLLuw7Lnpl LKxecJuWPQBe3mnh1J0sIDJ/ORS6A8Trp5IQa3t9KYfHABUNFeGDz8Ki+67InbC113sW Xb6repEYOqyyXg7/CAAPGhVXgpYV4rvMIQJfA= MIME-Version: 1.0 Received: by 10.224.19.200 with SMTP id c8mr6754698qab.129.1286186116672; Mon, 04 Oct 2010 02:55:16 -0700 (PDT) Received: by 10.229.11.25 with HTTP; Mon, 4 Oct 2010 02:55:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Oct 2010 15:25:16 +0530 Message-ID: From: Mayur To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: Examining the VM splay tree effectiveness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 10:22:55 -0000 By mistake last mail went to hackers.... sending it to freebsd-current -- Hi, Sorry for pitching in late on the discussion.... Looks like I have missed many mails, Will start from this point in the discussion I just took a look (not in-depth though) at the patch and can't follow your conclusion. It is not ready to go into svn in its current state. Even though it is called a radix trie it doesn't look like one. On first impression it looks much more like an AA tree. A radix trie, which we already have in our network routing table code, is a variable length (mask) tree that does path compression. See net/radix.[ch] and <> The data-structure is just like a page table where the index is chopped in to sub-indices. i th sub-index is offset into corresponding node node on (i+1)th level. The difference between then wikipedia description of radixtree and our implementation is that nodes with single child are not merged with parent (level compression). Also, we started with variable size slots (sub-indices) but Jeff thought its little too flexible. Current implementation works with fixed sized sub-indices (size is multiple of sizeof original index) About the benchmark: It works on uniform random numbers. Objective was to optimize random accesses on large objects (~4G-2T) Take a look at radix_tree_shrink() this function reduces the depth of the tree (if possible). Special case of path compression. <> http://en.wikipedia.org/wiki/Radix_tree Extrapolating in a complete guesstimating way from the lookup function I'd say it may perform only slightly better in an ideal case than a RB tree but with the added overall expense of requiring external memory to store the index and branch nodes. This is probably a nasty disadvantage. <> I don't get you, please elaborate. The way tree is structured we do not need space to store index (nor does radix-trie), it is implicit from the position of the "value" corresponding the index. <> Thanks, Mayur From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 14:19:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7298106564A; Mon, 4 Oct 2010 14:19:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 401AF8FC13; Mon, 4 Oct 2010 14:19:46 +0000 (UTC) Received: by gyg4 with SMTP id 4so2144997gyg.13 for ; Mon, 04 Oct 2010 07:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=McWN10CyqTvEM5AfOGhXqP/g3cxPlJcAQhTJVJtmMzo=; b=C8fWBgWaCUWQZ2E/NLPi0AvJx+fE2e14Il2PC9MKEHROBnPKrcFdP2yAoxPV7JGcFm FjkCxh6Wlk8vbXQXuBm/fc++XLvSMXxSdqvWFgvHUDQbBugJdaYHdH4c+AigpDbumj1E WTu2VU3sIQPW3bOCCsTcDODeu8DB++S+SmiRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=VYMIUbyFdhog8TzI64fDLOcnC0eapYYG9gGo13dyq1y5Ni6nqP4aNcEHaxRBDpaP+p ETjs9LlwAj6CATJOKwLAC98ZPZxivvbguY/tax9lfF48Z1S6WaRaMZhTHSojbCY8kGG3 S8VXPKVWclv1egeZVxar7+QdI0NH5gvGns4Uw= MIME-Version: 1.0 Received: by 10.90.65.7 with SMTP id n7mr4683905aga.51.1286201985988; Mon, 04 Oct 2010 07:19:45 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.91.78.6 with HTTP; Mon, 4 Oct 2010 07:19:45 -0700 (PDT) In-Reply-To: <20101004144927.36822f07.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> Date: Mon, 4 Oct 2010 07:19:45 -0700 X-Google-Sender-Auth: DAbRmEHIOoaV-WdRWpRUWfJigCA Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: multipart/mixed; boundary=0016e6509cc27bfbb10491cb3c91 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 14:19:48 -0000 --0016e6509cc27bfbb10491cb3c91 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Oct 3, 2010 at 10:49 PM, Daichi GOTO wrote: > On Sun, 3 Oct 2010 22:05:12 -0700 > Garrett Cooper wrote: >> On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO wrote: >> > It looks very strange. fcntl() always fails to delete lock file >> > and command.l_pid is always -6464. This issue is disclosed in >> > porting Google's Japanese input system called "mozc". >> > >> > =A0details follow: >> > =A0 =A0http://code.google.com/p/mozc/issues/detail?id=3D40 >> > >> > % uname -a >> > FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r21325= 7: Thu Sep 30 10:30:06 JST 2010 =A0 =A0 root@parancell.ongs.co.jp:/usr/obj/= usr/src/sys/PARANCELL =A0amd64 >> > % >> > >> > My home directory on NFS server. =A0Does anyone have any ideas? >> >> >> =A0 =A0 I see some bad assumptions in the code: >> >> =A0 =A0 const int result =3D ::fcntl(*fd, F_SETLK, &command); >> =A0 =A0 if (-1 =3D=3D result) { =A0// failed >> =A0 =A0 =A0 ::close(*fd); >> =A0 =A0 =A0 LOG(WARNING) << "already locked"; >> =A0 =A0 =A0 return false; =A0 // another server is already running >> =A0 =A0 } >> >> =A0 =A0 If the developer actually coded to POSIX expectations, he/she >> would be checking for EACCES/EAGAIN; there are a myriad of other > > It was EAGAIN, when I checked. =A0And -6464 is very strange.... > It should be -1 when it fails with EGAIN according to FreeBSD > fcntl(2) manual. > > Repeat is easy: > =A0# cd /usr/ports/japanese/mozc-server/ > =A0# rm files/patch-server_mozc_server.cc > =A0# make WITH_DEBUG_CODE=3Dyes install clean > > =A0% mozc_server > =A0^C =A0 =A0--> in this timing, lock files should be deleted, but not wo= rking. > =A0% mozc_server =A0--> so server will not run and finish soon > =A0% > > =A0% cat ~/.mozc/mozc_server.log > >> issues that might be occurring with the software, as per my copy of >> SUSv4 (see the ERRORS section of fcntl). I would print out the >> strerror for that case. >> =A0 =A0 Providing a backtrace of the application's execution and the >> architecture and what version of FreeBSD you're using would be >> helpful. I'm not even getting that far. Logs attached from both runs (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 I completely blasted past the part of your reply above where you said your home directory is served up via NFS. It might be a problem if you don't have lockd running (/etc/rc.d/lockd onestatus ? It isn't enabled by default, and definitely isn't on on my machine) or the mount isn't setup with lockd on the client side (nolockd will do this on the initial mount, according to the manpage). There might be `dragons' in the nfsd code that fail to do locking properly, but I think that Rick (rmacklem@) or someone else on the list might be better at answering whether or not things work from an NFS perspective. I'd definitely divulge which version of NFS you're using as well as what your NFS server and client are running if enabling lockd both client and server side doesn't solve your problems right away. Cheers, -Garrett --0016e6509cc27bfbb10491cb3c91 Content-Type: application/octet-stream; name=mozc-server-WITHOUT_DEBUG Content-Disposition: attachment; filename=mozc-server-WITHOUT_DEBUG Content-Transfer-Encoding: base64 X-Attachment-Id: f_gevf4lv40 W2djb29wZXJAYmF5b25ldHRhIC91c3IvcG9ydHMvamFwYW5lc2UvbW96Yy1zZXJ2ZXJdJCB0cnVz cyAtZmYgbW96Y19zZXJ2ZXIKOTU3OTg6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMmYwLDB4MiwweDdm ZmZmZmZmZTMwYywweDdmZmZmZmZmZTMwMCwweDAsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IG1tYXAo MHgwLDMyNzY4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9OLC0xLDB4 MCkgPSAzNDM4MjQzMDIwOCAoMHg4MDE1YTQwMDApCjk1Nzk4OiBpc3NldHVnaWQoMHg4MDE1YTUw MTUsMHg4MDE1OWY4ZTQsMHg3ZmZmZmZmZmU5OTgsMHg4MDE2YmIwNDAsMHg1NzMxLDB4MCkgPSAw ICgweDApCjk1Nzk4OiBvcGVuKCIvZXRjL2xpYm1hcC5jb25mIixPX1JET05MWSwwNjY2KQkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBvcGVuKCIvdmFyL3J1bi9sZC1l bGYuc28uaGludHMiLE9fUkRPTkxZLDA1NykgPSAyICgweDIpCjk1Nzk4OiByZWFkKDIsIkVobnRc XkFcMFwwXDBcTV5AXDBcMFwwXE1eWlwwXDAiLi4uLDEyOCkgPSAxMjggKDB4ODApCjk1Nzk4OiBs c2VlaygyLDB4ODAsU0VFS19TRVQpCQkJID0gMTI4ICgweDgwKQo5NTc5ODogcmVhZCgyLCIvbGli Oi91c3IvbGliOi91c3IvbGliL2NvbXBhdDovdSIuLi4sMTU0KSA9IDE1NCAoMHg5YSkKOTU3OTg6 IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCjk1Nzk4OiBhY2Nlc3MoIi9saWIvbGliY3VybC5zby42 IiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIv dXNyL2xpYi9saWJjdXJsLnNvLjYiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y eScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvY29tcGF0L2xpYmN1cmwuc28uNiIsMCkJIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xp Yi9saWJjdXJsLnNvLjYiLDApCSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi91c3IvbG9jYWwvbGli L2xpYmN1cmwuc28uNiIsT19SRE9OTFksMDEzMjU2Mzc0MCkgPSAyICgweDIpCjk1Nzk4OiBmc3Rh dCgyLHsgbW9kZT0tcnd4ci14ci14ICxpbm9kZT0yODI2Mzk3LHNpemU9MzU0MzczLGJsa3NpemU9 MTYzODQgfSkgPSAwICgweDApCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDE2YWQ3YzAsMHgxMDAwLDB4 MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQo5 NTc5ODogbW1hcCgweDAsMTM1OTg3MixQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQ X05PQ09SRSwtMSwweDApID0gMzQzODM1NzcwODggKDB4ODAxNmJjMDAwKQo5NTc5ODogbW1hcCgw eDgwMTZiYzAwMCwyODI2MjQsUFJPVF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklY RUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM4MzU3NzA4OCAoMHg4MDE2YmMwMDApCjk1Nzk4OiBt bWFwKDB4ODAxODAxMDAwLDI4NjcyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1B UF9GSVhFRCwyLDB4NDUwMDApID0gMzQzODQ5MDgyODggKDB4ODAxODAxMDAwKQo5NTc5ODogY2xv c2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IGFjY2VzcygiL2xpYi9saWJjcnlwdG8uc28uNiIs MCkJCSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi9saWIvbGliY3J5cHRvLnNvLjYiLE9fUkRPTkxZ LDAxMzI1NjM3NDApID0gMiAoMHgyKQo5NTc5ODogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAs aW5vZGU9NDAwNDQ4LHNpemU9MTY2OTA4OCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQo5NTc5 ODogcHJlYWQoMHgyLDB4ODAxNmFkN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4 MDgwODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6IG1tYXAoMHgwLDI3MDc0NTYs UFJPVF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzg0 OTM2OTYwICgweDgwMTgwODAwMCkKOTU3OTg6IG1tYXAoMHg4MDE4MDgwMDAsMTM1OTg3MixQUk9U X1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9 IDM0Mzg0OTM2OTYwICgweDgwMTgwODAwMCkKOTU3OTg6IG1tYXAoMHg4MDFhNTQwMDAsMjkwODE2 LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MTRjMDAwKSA9 IDM0Mzg3MzQ1NDA4ICgweDgwMWE1NDAwMCkKOTU3OTg6IG1wcm90ZWN0KDB4ODAxYTliMDAwLDgx OTIsUFJPVF9SRUFEfFBST1RfV1JJVEUpID0gMCAoMHgwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9 IDAgKDB4MCkKOTU3OTg6IGFjY2VzcygiL2xpYi9saWJ0aHIuc28uMyIsMCkJCSA9IDAgKDB4MCkK OTU3OTg6IG9wZW4oIi9saWIvbGlidGhyLnNvLjMiLE9fUkRPTkxZLDAxMzI1NjM3NDApID0gMiAo MHgyKQo5NTc5ODogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAsaW5vZGU9NDAwNDI2LHNpemU9 ODc5NTIsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IHByZWFkKDB4MiwweDgwMTZh ZDdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0 MDk2ICgweDEwMDApCjk1Nzk4OiBtbWFwKDB4MCwxMTQyNzg0LFBST1RfTk9ORSxNQVBfUFJJVkFU RXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4NzY0NDQxNiAoMHg4MDFhOWQwMDAp Cjk1Nzk4OiBtbWFwKDB4ODAxYTlkMDAwLDczNzI4LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BS SVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzODc2NDQ0MTYgKDB4ODAxYTlk MDAwKQo5NTc5ODogbW1hcCgweDgwMWJhZTAwMCwxNjM4NCxQUk9UX1JFQUR8UFJPVF9XUklURSxN QVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDExMDAwKSA9IDM0Mzg4NzYyNjI0ICgweDgwMWJhZTAw MCkKOTU3OTg6IG1wcm90ZWN0KDB4ODAxYmIyMDAwLDgxOTIsUFJPVF9SRUFEfFBST1RfV1JJVEUp ID0gMCAoMHgwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IGFjY2Vzcygi L2xpYi9saWJydC5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5 NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9saWJydC5zby4xIiwwKQkJID0gMCAoMHgwKQo5NTc5ODog b3BlbigiL3Vzci9saWIvbGlicnQuc28uMSIsT19SRE9OTFksMDEzMjU2Mzc0MCkgPSAyICgweDIp Cjk1Nzk4OiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT0yNTY3OTAzLHNpemU9MjE3 NDQsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IHByZWFkKDB4MiwweDgwMTZhZDdj MCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2 ICgweDEwMDApCjk1Nzk4OiBtbWFwKDB4MCwxMDY5MDU2LFBST1RfTk9ORSxNQVBfUFJJVkFURXxN QVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4ODc4NzIwMCAoMHg4MDFiYjQwMDApCjk1 Nzk4OiBtbWFwKDB4ODAxYmI0MDAwLDIwNDgwLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZB VEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzODg3ODcyMDAgKDB4ODAxYmI0MDAw KQo5NTc5ODogbW1hcCgweDgwMWNiODAwMCw0MDk2LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9Q UklWQVRFfE1BUF9GSVhFRCwyLDB4NDAwMCkgPSAzNDM4OTg1MjE2MCAoMHg4MDFjYjgwMDApCjk1 Nzk4OiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQo5NTc5ODogYWNjZXNzKCIvbGliL2xpYnNzbC5z by42IiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNz KCIvdXNyL2xpYi9saWJzc2wuc28uNiIsMCkJCSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi91c3Iv bGliL2xpYnNzbC5zby42IixPX1JET05MWSwwMTMyNTYzNzQwKSA9IDIgKDB4MikKOTU3OTg6IGZz dGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTI1NjcxOTIsc2l6ZT0zMzQxNTIsYmxrc2l6 ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IHByZWFkKDB4MiwweDgwMTZhZDdjMCwweDEwMDAs MHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgweDEwMDAp Cjk1Nzk4OiBtbWFwKDB4MCwxMzgwMzUyLFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBfQU5PTnxN QVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4OTg1NjI1NiAoMHg4MDFjYjkwMDApCjk1Nzk4OiBtbWFw KDB4ODAxY2I5MDAwLDI4NjcyMCxQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9G SVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0Mzg5ODU2MjU2ICgweDgwMWNiOTAwMCkKOTU3OTg6 IG1tYXAoMHg4MDFkZmYwMDAsNDUwNTYsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8 TUFQX0ZJWEVELDIsMHg0NjAwMCkgPSAzNDM5MTE5MTU1MiAoMHg4MDFkZmYwMDApCjk1Nzk4OiBj bG9zZSgyKQkJCQkJID0gMCAoMHgwKQo5NTc5ODogYWNjZXNzKCIvbGliL2xpYnouc28uNiIsMCkJ CSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi9saWIvbGliei5zby42IixPX1JET05MWSwwMTMyNTYz NzQwKSA9IDIgKDB4MikKOTU3OTg6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQw MDQzMCxzaXplPTg5NTI4LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1Nzk4OiBwcmVhZCgw eDIsMHg4MDE2YWQ3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4 MDgwODApID0gNDA5NiAoMHgxMDAwKQo5NTc5ODogbW1hcCgweDAsMTEzODY4OCxQUk9UX05PTkUs TUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTEyMzY2MDggKDB4 ODAxZTBhMDAwKQo5NTc5ODogbW1hcCgweDgwMWUwYTAwMCw4MTkyMCxQUk9UX1JFQUR8UFJPVF9F WEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0MzkxMjM2NjA4 ICgweDgwMWUwYTAwMCkKOTU3OTg6IG1tYXAoMHg4MDFmMWUwMDAsODE5MixQUk9UX1JFQUR8UFJP VF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDE0MDAwKSA9IDM0MzkyMzY3MTA0ICgw eDgwMWYxZTAwMCkKOTU3OTg6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCjk1Nzk4OiBhY2Nlc3Mo Ii9saWIvbGlicHJvdG9idWYuc28uNiIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9saWJwcm90b2J1Zi5zby42IiwwKQkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbGliL2NvbXBh dC9saWJwcm90b2J1Zi5zby42IiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScK OTU3OTg6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvbGlicHJvdG9idWYuc28uNiIsMCkgPSAwICgw eDApCjk1Nzk4OiBvcGVuKCIvdXNyL2xvY2FsL2xpYi9saWJwcm90b2J1Zi5zby42IixPX1JET05M WSwwMTMyNTYzNzQwKSA9IDIgKDB4MikKOTU3OTg6IGZzdGF0KDIseyBtb2RlPS1yd3hyLXhyLXgg LGlub2RlPTI4Mjc3ODQsc2l6ZT0xNDEzMjg1LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1 Nzk4OiBwcmVhZCgweDIsMHg4MDE2YWQ3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSww eDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQo5NTc5ODogbW1hcCgweDAsMjE4MzE2 OCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQz OTIzNzUyOTYgKDB4ODAxZjIwMDAwKQo5NTc5ODogbW1hcCgweDgwMWYyMDAwMCw5OTUzMjgsUFJP VF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkg PSAzNDM5MjM3NTI5NiAoMHg4MDFmMjAwMDApCjk1Nzk4OiBtbWFwKDB4ODAyMTEyMDAwLDE0MzM2 MCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweGYyMDAwKSA9 IDM0Mzk0NDE1MTA0ICgweDgwMjExMjAwMCkKOTU3OTg6IGNsb3NlKDIpCQkJCQkgPSAwICgweDAp Cjk1Nzk4OiBhY2Nlc3MoIi9saWIvbGlic3RkYysrLnNvLjYiLDApCQkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbGliL2xpYnN0ZGMrKy5zby42 IiwwKQkgPSAwICgweDApCjk1Nzk4OiBvcGVuKCIvdXNyL2xpYi9saWJzdGRjKysuc28uNiIsT19S RE9OTFksMDEzMjU2Mzc0MCkgPSAyICgweDIpCjk1Nzk4OiBmc3RhdCgyLHsgbW9kZT0tci0tci0t ci0tICxpbm9kZT0yNTY4MDEwLHNpemU9MTAxODU4NCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgw KQo5NTc5ODogcHJlYWQoMHgyLDB4ODAxNmFkN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAx MDEsMHg4MDgwODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6IG1tYXAoMHgwLDIx NDIyMDgsUFJPVF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9 IDM0Mzk0NTU4NDY0ICgweDgwMjEzNTAwMCkKOTU3OTg6IG1tYXAoMHg4MDIxMzUwMDAsODc2NTQ0 LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiww eDApID0gMzQzOTQ1NTg0NjQgKDB4ODAyMTM1MDAwKQo5NTc5ODogbW1hcCgweDgwMjMwYTAwMCwx NDMzNjAsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHhkNTAw MCkgPSAzNDM5NjQ3OTQ4OCAoMHg4MDIzMGEwMDApCjk1Nzk4OiBtcHJvdGVjdCgweDgwMjMyZDAw MCw3NzgyNCxQUk9UX1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCjk1Nzk4OiBjbG9zZSgyKQkJ CQkJID0gMCAoMHgwKQo5NTc5ODogYWNjZXNzKCIvbGliL2xpYm0uc28uNSIsMCkJCSA9IDAgKDB4 MCkKOTU3OTg6IG9wZW4oIi9saWIvbGlibS5zby41IixPX1JET05MWSwwMTMyNTYzNzQwKSA9IDIg KDB4MikKOTU3OTg6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQwMDM5MSxzaXpl PTEzNjc0NCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQo5NTc5ODogcHJlYWQoMHgyLDB4ODAx NmFkN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgwODA4MDgwODA4MDgwKSA9 IDQwOTYgKDB4MTAwMCkKOTU3OTg6IG1tYXAoMHgwLDExNzU1NTIsUFJPVF9OT05FLE1BUF9QUklW QVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzk2NzAwNjcyICgweDgwMjM0MDAw MCkKOTU3OTg6IG1tYXAoMHg4MDIzNDAwMDAsMTIyODgwLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQ X1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTY3MDA2NzIgKDB4ODAy MzQwMDAwKQo5NTc5ODogbW1hcCgweDgwMjQ1ZDAwMCw4MTkyLFBST1RfUkVBRHxQUk9UX1dSSVRF LE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MWQwMDApID0gMzQzOTc4NjgwMzIgKDB4ODAyNDVk MDAwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IGFjY2VzcygiL2xpYi9s aWJnY2Nfcy5zby4xIiwwKQkJID0gMCAoMHgwKQo5NTc5ODogb3BlbigiL2xpYi9saWJnY2Nfcy5z by4xIixPX1JET05MWSwwMTMyNTYzNzQwKSA9IDIgKDB4MikKOTU3OTg6IGZzdGF0KDIseyBtb2Rl PS1yLS1yLS1yLS0gLGlub2RlPTQwMDQ0NCxzaXplPTU2MTkyLGJsa3NpemU9MTYzODQgfSkgPSAw ICgweDApCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDE2YWQ3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEw MTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQo5NTc5ODogbW1hcCgw eDAsMTEwMTgyNCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSww eDApID0gMzQzOTc4NzYyMjQgKDB4ODAyNDVmMDAwKQo5NTc5ODogbW1hcCgweDgwMjQ1ZjAwMCw0 OTE1MixQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JF LDIsMHgwKSA9IDM0Mzk3ODc2MjI0ICgweDgwMjQ1ZjAwMCkKOTU3OTg6IG1tYXAoMHg4MDI1NmEw MDAsODE5MixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweGIw MDApID0gMzQzOTg5Njk4NTYgKDB4ODAyNTZhMDAwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9IDAg KDB4MCkKOTU3OTg6IGFjY2VzcygiL2xpYi9saWJjLnNvLjciLDApCQkgPSAwICgweDApCjk1Nzk4 OiBvcGVuKCIvbGliL2xpYmMuc28uNyIsT19SRE9OTFksMDEzMjU2Mzc0MCkgPSAyICgweDIpCjk1 Nzk4OiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT00MDAzODgsc2l6ZT0xMTgwMDA4 LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDE2YWQ3YzAs MHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAo MHgxMDAwKQo5NTc5ODogbW1hcCgweDAsMjMwNjA0OCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQ X0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTg5NzgwNDggKDB4ODAyNTZjMDAwKQo5NTc5 ODogbW1hcCgweDgwMjU2YzAwMCwxMDE1ODA4LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZB VEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTg5NzgwNDggKDB4ODAyNTZjMDAw KQo5NTc5ODogbW1hcCgweDgwMjc2NDAwMCwxMzEwNzIsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQ X1BSSVZBVEV8TUFQX0ZJWEVELDIsMHhmODAwMCkgPSAzNDQwMTA0MjQzMiAoMHg4MDI3NjQwMDAp Cjk1Nzk4OiBtcHJvdGVjdCgweDgwMjc4NDAwMCwxMTA1OTIsUFJPVF9SRUFEfFBST1RfV1JJVEUp ID0gMCAoMHgwKQo5NTc5ODogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IHN5c2FyY2go MHg4MSwweDdmZmZmZmZmZTQwMCwweDgwMTVhOTYwOCwweDAsMHhmZmZmZmZmZmZlZTNiZWQwLDB4 ODA4MDgwODA4MDgwODA4MCkgPSAwICgweDApCjk1Nzk4OiBtbWFwKDB4MCw0NTA1NixQUk9UX1JF QUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwtMSwweDApID0gMzQzODI0NjI5NzYg KDB4ODAxNWFjMDAwKQo5NTc5ODogbXVubWFwKDB4ODAxNWIwMDAwLDI4NjcyKQkJID0gMCAoMHgw KQo5NTc5ODogbW1hcCgweDAsMTAyNDAwLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRF fE1BUF9BTk9OLC0xLDB4MCkgPSAzNDM4MjQ3OTM2MCAoMHg4MDE1YjAwMDApCjk1Nzk4OiBzaWdw cm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxT SUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lH VFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdX SU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJv Y21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IF9fc3lzY3RsKDB4 N2ZmZmZmZmZlMzkwLDB4MiwweDgwMjc4YTMyMCwweDdmZmZmZmZmZTM4OCwweDAsMHgwKSA9IDAg KDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8 U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJ R0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZU QUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgw eDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5 NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxM fFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxT SUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJ R1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3 OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQ RXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8 U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxT SUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2ln cHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IGdldHBpZCgp CQkJCQkgPSA5NTc5OCAoMHgxNzYzNikKOTU3OTg6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMzUwLDB4 MiwweDgwMWJiM2U3MCwweDdmZmZmZmZmZTM1OCwweDAsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IF9f c3lzY3RsKDB4N2ZmZmZmZmZlMjcwLDB4MiwweDdmZmZmZmZmZTI5MCwweDdmZmZmZmZmZTJmOCww eDgwMWFhZGZkOCwweGQpID0gMCAoMHgwKQo5NTc5ODogX19zeXNjdGwoMHg3ZmZmZmZmZmUyOTAs MHgzLDB4ODAxYmIyZDY4LDB4N2ZmZmZmZmZlMzU4LDB4MCwweDApID0gMCAoMHgwKQo5NTc5ODog X19zeXNjdGwoMHg3ZmZmZmZmZmRlMDAsMHgyLDB4N2ZmZmZmZmZkZTJjLDB4N2ZmZmZmZmZkZTIw LDB4MCwweDApID0gMCAoMHgwKQo5NTc5ODogX19zeXNjdGwoMHg3ZmZmZmZmZmRjZjAsMHgyLDB4 N2ZmZmZmZmZkZDEwLDB4N2ZmZmZmZmZkZDc4LDB4ODAyNjU3NTQwLDB4YykgPSAwICgweDApCjk1 Nzk4OiBfX3N5c2N0bCgweDdmZmZmZmZmZGQxMCwweDIsMHg4MDI3ODlkNzAsMHg3ZmZmZmZmZmRk YzAsMHgwLDB4MCkgPSAwICgweDApCjk1Nzk4OiByZWFkbGluaygiL2V0Yy9tYWxsb2MuY29uZiIs MHg3ZmZmZmZmZmRlMzAsMTAyNCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1 Nzk4OiBpc3NldHVnaWQoMHg4MDI2NTYxNGYsMHg3ZmZmZmZmZmRlMzAsMHhmZmZmZmZmZmZmZmZm ZmZmLDB4MCwweDIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IGJyZWFrKDB4MTgwMDAwMCkJCQkJID0g MCAoMHgwKQo5NTc5ODogX19zeXNjdGwoMHg3ZmZmZmZmZmRlNTAsMHgyLDB4N2ZmZmZmZmZkZTZj LDB4N2ZmZmZmZmZkZTYwLDB4MCwweDApID0gMCAoMHgwKQo5NTc5ODogbW1hcCgweDAsNDE5NDMw NCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwtMSwweDApID0gMzQ0 MDEyODQwOTYgKDB4ODAyNzlmMDAwKQo5NTc5ODogbW1hcCgweDgwMmI5ZjAwMCwzOTczMTIsUFJP VF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0FOT04sLTEsMHgwKSA9IDM0NDA1NDc4 NDAwICgweDgwMmI5ZjAwMCkKOTU3OTg6IG11bm1hcCgweDgwMjc5ZjAwMCwzOTczMTIpCQkgPSAw ICgweDApCjk1Nzk4OiB0aHJfc2VsZigweDgwMjgwNzFjMCwweDAsMHgwLDB4MCwweDE4OCwweDE2 MzFjZjApID0gMCAoMHgwKQo5NTc5ODogbW1hcCgweDdmZmZmZmJmZjAwMCw0MDk2LFBST1RfTk9O RSxNQVBfQU5PTiwtMSwweDApID0gMTQwNzM3NDg0MTU2OTI4ICgweDdmZmZmZmJmZjAwMCkKOTU3 OTg6IHRocl9zZXRfbmFtZSgweDE4N2YyLDB4ODAxYWFlMDIwLDB4MCwweDEwMDAsMHhmZmZmZmZm ZiwweDApID0gMCAoMHgwKQo5NTc5ODogcnRwcmlvX3RocmVhZCgweDAsMHgxODdmMiwweDdmZmZm ZmZmZTMwMCwweDEwMDAsMHhmZmZmZmZmZiwweDApID0gMCAoMHgwKQo5NTc5ODogc3lzYXJjaCgw eDgxLDB4N2ZmZmZmZmZlMzIwLDB4ODAxYmIyOTQwLDB4ODAxYmIyY2M4LDB4ZmZmZmZmZmYsMHgw KSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLFNJR0hVUHxTSUdJTlR8 U0lHUVVJVHxTSUdJTEx8U0lHQUJSVHxTSUdFTVR8U0lHRlBFfFNJR0tJTEx8U0lHQlVTfFNJR1NF R1Z8U0lHU1lTfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8 U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lH VlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAg KDB4MCkKOTU3OTg6IHNpZ2FjdGlvbigzMix7IDB4ODAxYWE4Mzc1IFNBX1JFU1RBUlR8U0FfU0lH SU5GTyBzc190IH0sMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNL LDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQ fFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJ R1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hD UFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lH VVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4 MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5U fFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxT SUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdY RlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4 MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0g MCAoMHgwKQo5NTc5ODogbWFkdmlzZSgweDgwMjgwZjAwMCwweDEwMDAsMHg1LDB4ZSwweDIwMDgs MHhiKSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4MGYwMDAsMHgxMDAwLDB4NSwweGUs MHgyMDA4LDB4N2ZmZmZmZmZkNzQwKSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4MjAw MDAsMHgxMDAwLDB4NSwweDFmLDB4MjAwOCwweDE2MzFjZjApID0gMCAoMHgwKQo5NTc5ODogbWFk dmlzZSgweDgwMjgyNjAwMCwweDEwMDAsMHg1LDB4MjUsMHg1MDA4LDB4N2ZmZmZmZmZkNTgwKSA9 IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4MjIwMDAsMHgxMDAwLDB4NSwweDIxLDB4NTAw OCwweDdmZmZmZmZmZDU4MCkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyODFlMDAwLDB4 MTAwMCwweDUsMHgxZCwweDIwMDgsMHg3ZmZmZmZmZmQ1ODApID0gMCAoMHgwKQo5NTc5ODogbWFk dmlzZSgweDgwMjgxOTAwMCwweDEwMDAsMHg1LDB4MTgsMHgxLDB4N2ZmZmZmZmZkNWEwKSA9IDAg KDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4MTgwMDAsMHgxMDAwLDB4NSwweDE3LDB4MTYzMWRl MCwweDdmZmZmZmZmZDVlMCkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyODIwMDAwLDB4 MTAwMCwweDUsMHgxZiwweGYwMDAsMHg3ZmZmZmZmZmQ2MDApID0gMCAoMHgwKQo5NTc5ODogbWFk dmlzZSgweDgwMjgxYTAwMCwweDEwMDAsMHg1LDB4MTksMHgxMDA4LDB4MTYzMWNmMCkgPSAwICgw eDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJ R0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdD T05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFM Uk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgw KQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3 OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxT SUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lH Q0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQ Uk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCjk1Nzk4 OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogc2ln cHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8 U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJ R1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lH V0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3By b2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFz ayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJN fFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxT SUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxT SUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2so U0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19C TE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVS TXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8 U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98 U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VU TUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJ R0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VS R3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xT SUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1Ix fFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4 MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyODQ0MDAwLDB4MTAwMCwweDUs MHg0MywweDEsMHg3ZmZmZmZmZmRhZDApID0gMCAoMHgwKQo5NTc5ODogbWFkdmlzZSgweDgwMjgz ZDAwMCwweDEwMDAsMHg1LDB4M2MsMHgxLDB4N2ZmZmZmZmZkYWQwKSA9IDAgKDB4MCkKOTU3OTg6 IG1hZHZpc2UoMHg4MDI4M2MwMDAsMHgxMDAwLDB4NSwweDNiLDB4MTYzMWRlMCwweDdmZmZmZmZm ZGJhMCkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyODI1MDAwLDB4MTAwMCwweDUsMHgy NCwweDE2MzFkZTAsMHg3ZmZmZmZmZmRiYTApID0gMCAoMHgwKQo5NTc5ODogbWFkdmlzZSgweDgw MjgyNDAwMCwweDEwMDAsMHg1LDB4MjMsMHgxLDB4N2ZmZmZmZmZkYjIwKSA9IDAgKDB4MCkKOTU3 OTg6IG1hZHZpc2UoMHg4MDI4MWMwMDAsMHgyMDAwLDB4NSwweDFiLDB4MSwweDdmZmZmZmZmZGIy MCkgPSAwICgweDApCjk1Nzk4OiBnZXRldWlkKCkJCQkJID0gMTAwMCAoMHgzZTgpCjk1Nzk4OiBn ZXR1aWQoKQkJCQkJID0gMTAwMCAoMHgzZTgpCjk1Nzk4OiBnZXRldWlkKCkJCQkJID0gMTAwMCAo MHgzZTgpCjk1Nzk4OiBzdGF0KCIvZXRjL25zc3dpdGNoLmNvbmYiLHsgbW9kZT0tcnctci0tci0t ICxpbm9kZT0xNDEzNTksc2l6ZT0yNTUsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6 IG9wZW4oIi9ldGMvbnNzd2l0Y2guY29uZiIsT19SRE9OTFksMDY2NikJID0gMiAoMHgyKQo5NTc5 ODogaW9jdGwoMixUSU9DR0VUQSwweGZmZmZkZjkwKQkJIEVSUiMyNSAnSW5hcHByb3ByaWF0ZSBp b2N0bCBmb3IgZGV2aWNlJwo5NTc5ODogZnN0YXQoMix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9 MTQxMzU5LHNpemU9MjU1LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1Nzk4OiByZWFkKDIs IiNcbiMgbnNzd2l0Y2guY29uZig1KSAtIG5hbWUgc2VyIi4uLiwxNjM4NCkgPSAyNTUgKDB4ZmYp Cjk1Nzk4OiByZWFkKDIsMHg4MDI4NTQwMDAsMTYzODQpCQkgPSAwICgweDApCjk1Nzk4OiBzaWdw cm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxT SUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lH VFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdX SU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogYWNjZXNz KCIvbGliL25zc19jb21wYXQuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvbnNzX2NvbXBhdC5zby4xIiwwKQkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbGliL2NvbXBh dC9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5 NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2tkZTQv bGliL25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnkn Cjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2NvbXBhdC9uc3NfY29tcGF0LnNvLjEiLDAp IEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xv Y2FsL2xpYi9nZWdsLTAuMS9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUg b3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9ncmFwaHZpei9uc3Nf Y29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODog YWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9xdDQvbnNzX2NvbXBhdC5zby4xIiwwKSBFUlIjMiAnTm8g c3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL2xpYi9uc3NfY29tcGF0LnNv LjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3Mo Ii91c3IvbGliL25zc19jb21wYXQuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5Jwo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4 MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lH S0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NP TlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxS TXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDAp Cjk1Nzk4OiBhY2Nlc3MoIi9saWIvbnNzX25pcy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9uc3NfbmlzLnNvLjEiLDAp CSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9s aWIvY29tcGF0L25zc19uaXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfbmlzLnNvLjEiLDApCSBFUlIj MiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9sb2NhbC9r ZGU0L2xpYi9uc3NfbmlzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX25pcy5zby4xIiwwKSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9sb2Nh bC9saWIvZ2VnbC0wLjEvbnNzX25pcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXovbnNzX25pcy5z by4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2Vzcygi L3Vzci9sb2NhbC9saWIvcXQ0L25zc19uaXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi9saWIvbnNzX25pcy5zby4xIiwwKQkJIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9uc3Nf bmlzLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IHNp Z3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9j bWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdB TFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJ TnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5D SHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogYWNjZXNzKCIv bGliL25zc19maWxlcy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJIEVSUiMyICdObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xpYi9jb21wYXQvbnNz X2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODog YWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwva2RlNC9saWIvbnNz X2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODog YWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9n ZWdsLTAuMS9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dyYXBodml6L25zc19maWxlcy5zby4x IiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vz ci9sb2NhbC9saWIvcXQ0L25zc19maWxlcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9y IGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJCSBFUlIj MiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvbnNz X2ZpbGVzLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6 IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdw cm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxT SUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lH VFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdX SU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogYWNjZXNz KCIvbGliL25zc19kbnMuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y eScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvbnNzX2Rucy5zby4xIiwwKQkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbGliL2NvbXBhdC9uc3Nf ZG5zLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFj Y2VzcygiL3Vzci9sb2NhbC9saWIvbnNzX2Rucy5zby4xIiwwKQkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwva2RlNC9saWIvbnNzX2Ru cy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2Vz cygiL3Vzci9sb2NhbC9saWIvY29tcGF0L25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dlZ2wtMC4x L25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4 OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dyYXBodml6L25zc19kbnMuc28uMSIsMCkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBhY2Nlc3MoIi91c3IvbG9jYWwvbGli L3F0NC9uc3NfZG5zLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5 NTc5ODogYWNjZXNzKCIvbGliL25zc19kbnMuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxl IG9yIGRpcmVjdG9yeScKOTU3OTg6IGFjY2VzcygiL3Vzci9saWIvbnNzX2Rucy5zby4xIiwwKQkg RVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdf U0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogaW9jdGwoMixUSU9DR0VUQSwweGZm ZmZkZmEwKQkJIEVSUiMyNSAnSW5hcHByb3ByaWF0ZSBpb2N0bCBmb3IgZGV2aWNlJwo5NTc5ODog Y2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4NTQwMDAsMHg0MDAw LDB4NSwweDUzLDB4NGMwMDgsMHg4MDI3OGJmYzApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21h c2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxS TXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58 U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8 U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNr KFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdf QkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RF Uk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9V fFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZP fFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NF VE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IGdldGV1aWQoKQkJCQkgPSAxMDAwICgw eDNlOCkKOTU3OTg6IG9wZW4oIi9ldGMvcHdkLmRiIixPX1JET05MWSwwMCkJCSA9IDIgKDB4MikK OTU3OTg6IGZjbnRsKDIsRl9TRVRGRCxGRF9DTE9FWEVDKQkJID0gMCAoMHgwKQo5NTc5ODogZnN0 YXQoMix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MTQxNTM3LHNpemU9NDA5NjAsYmxrc2l6ZT0x NjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IHJlYWQoMiwiXDBcXkZcXlVhXDBcMFwwXF5CXDBcMFxe RFxNLVJcMCIuLi4sMjYwKSA9IDI2MCAoMHgxMDQpCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDI4YTIw MDAsMHgxMDAwLDB4NjAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6IHByZWFkKDB4 MiwweDgwMjhhMzAwMCwweDEwMDAsMHg0MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQo5NTc5 ODogcHJlYWQoMHgyLDB4ODAyOGE0MDAwLDB4MTAwMCwweDUwMDAsMHgxLDB4MCkgPSA0MDk2ICgw eDEwMDApCjk1Nzk4OiBwcmVhZCgweDIsMHg4MDI4YTUwMDAsMHgxMDAwLDB4NzAwMCwweDEsMHgw KSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6IHByZWFkKDB4MiwweDgwMjhhNjAwMCwweDEwMDAsMHg4 MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQo5NTc5ODogcHJlYWQoMHgyLDB4ODAyOGE3MDAw LDB4MTAwMCwweDEwMDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCjk1Nzk4OiBwcmVhZCgweDIs MHg4MDI4YTgwMDAsMHgxMDAwLDB4MjAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKOTU3OTg6 IHByZWFkKDB4MiwweDgwMjhhOTAwMCwweDEwMDAsMHgzMDAwLDB4MSwweDApID0gNDA5NiAoMHgx MDAwKQo5NTc5ODogbWFkdmlzZSgweDgwMjhhODAwMCwweDIwMDAsMHg1LDB4YTcsMHgxLDB4MCkg PSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyOGEyMDAwLDB4NDAwMCwweDUsMHhhMSwweDEs MHgwKSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4YTYwMDAsMHgyMDAwLDB4NSwweGE1 LDB4MSwweDdmZmZmZmZmZDQyMCkgPSAwICgweDApCjk1Nzk4OiBtYWR2aXNlKDB4ODAyOGExMDAw LDB4MTAwMCwweDUsMHhhMCwweDEsMHg3ZmZmZmZmZmQ0MjApID0gMCAoMHgwKQo5NTc5ODogY2xv c2UoMikJCQkJCSA9IDAgKDB4MCkKOTU3OTg6IG1hZHZpc2UoMHg4MDI4NTkwMDAsMHgyMDAwLDB4 NSwweDU4LDB4NGMwMDgsMHg3ZmZmZmZmZmQ0NjApID0gMCAoMHgwKQo5NTc5ODogbWtkaXIoIi91 c3IvaG9tZS9nY29vcGVyLy5tb3pjIiwwNzAwKQkgRVJSIzE3ICdGaWxlIGV4aXN0cycKOTU3OTg6 IHN0YXQoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjIix7IG1vZGU9ZHJ3eC0tLS0tLSAsaW5vZGU9 MzAzOTI1MSxzaXplPTUxMixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQo5NTc5ODogY2htb2Qo Ii91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5zZXJ2ZXIubG9jayIsMDYwMCkgPSAwICgweDApCjk1 Nzk4OiBvcGVuKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96Yy8uc2VydmVyLmxvY2siLE9fUkRXUnxP X0NSRUFUfE9fVFJVTkMsMDYwMCkgPSAyICgweDIpCjk1Nzk4OiBmY250bCgyLEZfU0VUTEssMHg3 ZmZmZmZmZmU4MDApCQkgPSAwICgweDApCjk1Nzk4OiBjaG1vZCgiL3Vzci9ob21lL2djb29wZXIv Lm1vemMvLnNlcnZlci5sb2NrIiwwNDAwKSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi9kZXYvdXJh bmRvbSIsT19SRE9OTFksMDY2NikJID0gMyAoMHgzKQo5NTc5ODogcmVhZCgzLCJcTS03SWJCZ2Bc TS0pNVxNLTdZW1xNLVFcTV5GXE0tYiIuLi4sMTAyMykgPSAxMDIzICgweDNmZikKOTU3OTg6IGNs b3NlKDMpCQkJCQkgPSAwICgweDApCjk1Nzk4OiBzdGF0KCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96 Yy8uc2Vzc2lvbi5pcGMiLHsgbW9kZT0tci0tLS0tLS0tICxpbm9kZT0zMDM5MjUzLHNpemU9NTYs Ymxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKOTU3OTg6IG9wZW4oIi91c3IvaG9tZS9nY29vcGVy Ly5tb3pjLy5zZXNzaW9uLmlwYyIsT19SRE9OTFksMDY2NikgPSAzICgweDMpCjk1Nzk4OiByZWFk KDMsIlxuIGVmZDIxZGZiNmZjMDJkOTJiMzc3NWMwYjkxOTE4Ii4uLiw4MTkyKSA9IDU2ICgweDM4 KQo5NTc5ODogcmVhZCgzLDB4ODAyOGIzMDM4LDgxMzYpCQkJID0gMCAoMHgwKQo5NTc5ODogc3Rh dCgiL3Vzci9ob21lL2djb29wZXIvLm1vemMvLnNlc3Npb24uaXBjIix7IG1vZGU9LXItLS0tLS0t LSAsaW5vZGU9MzAzOTI1MyxzaXplPTU2LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCjk1Nzk4 OiBjbG9zZSgzKQkJCQkJID0gMCAoMHgwKQo5NTc5ODogbWtkaXIoIi90bXAiLDA3MDApCQkJIEVS UiMxNyAnRmlsZSBleGlzdHMnCjk1Nzk4OiBzb2NrZXQoUEZfTE9DQUwsU09DS19TVFJFQU0sMCkJ CSA9IDMgKDB4MykKOTU3OTg6IGZjbnRsKDMsRl9HRVRGRCwpCQkJID0gMCAoMHgwKQo5NTc5ODog ZmNudGwoMyxGX1NFVEZELEZEX0NMT0VYRUMpCQkgPSAwICgweDApCjk1Nzk4OiBzZXRzb2Nrb3B0 KDB4MywweGZmZmYsMHg0LDB4N2ZmZmZmZmZlODI4LDB4NCwweDQpID0gMCAoMHgwKQo5NTc5ODog YmluZCgzLHsgQUZfVU5JWCAiL3RtcC8ubW96Yy5lZmQyMWRmYjZmYzAyZDkyYjM3NzVjMGI5MTkx OGExOS5zZXNzaW9uIiB9LDEwNikgRVJSIzQ4ICdBZGRyZXNzIGFscmVhZHkgaW4gdXNlJwo5NTc5 ODogc3RhdCgiL3Vzci9zaGFyZS9ubHMvQy9saWJjLmNhdCIsMHg3ZmZmZmZmZmUyNTApIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwo5NTc5ODogc3RhdCgiL3Vzci9zaGFyZS9ubHMv bGliYy9DIiwweDdmZmZmZmZmZTI1MCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnkn Cjk1Nzk4OiBzdGF0KCIvdXNyL2xvY2FsL3NoYXJlL25scy9DL2xpYmMuY2F0IiwweDdmZmZmZmZm ZTI1MCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCjk1Nzk4OiBzdGF0KCIvdXNy L2xvY2FsL3NoYXJlL25scy9saWJjL0MiLDB4N2ZmZmZmZmZlMjUwKSBFUlIjMiAnTm8gc3VjaCBm aWxlIG9yIGRpcmVjdG9yeScKOTU3OTg6IG1hZHZpc2UoMHg4MDI4YjMwMDAsMHgyMDAwLDB4NSww eGIyLDB4MTAwOCwweDApID0gMCAoMHgwKQo5NTc5ODogbWFkdmlzZSgweDgwMjhiMTAwMCwweDEw MDAsMHg1LDB4YjAsMHgxMDA4LDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdf QkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RF Uk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9V fFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZP fFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NF VE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxT SUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdV Ukd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98 U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNS MXxTSUdVU1IyLDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSyww eDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxT SUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdT VE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BV fFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VT UjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDAp CQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxT SUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lH VFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZT WnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDAp ID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAg KDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8 U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJ R0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZU QUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgw eDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5 NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxM fFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxT SUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJ R1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3 OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQ RXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8 U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxT SUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2ln cHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2Nt YXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FM Uk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElO fFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNI fFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFz ayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lH X0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdU RVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRP VXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5G T3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19T RVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ss U0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lH VVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lP fFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VT UjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX1NFVE1BU0ss MHgwLDB4MCkJCSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8 U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lH U1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQ VXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdV U1IyLDB4MCkgPSAwICgweDApCjk1Nzk4OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgw KQkJID0gMCAoMHgwKQo5NTc5ODogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8 U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJ R1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hG U1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgw KSA9IDAgKDB4MCkKOTU3OTg6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAw ICgweDApCjk1Nzk4OiBwcm9jZXNzIGV4aXQsIHJ2YWwgPSAyNTUK --0016e6509cc27bfbb10491cb3c91 Content-Type: application/octet-stream; name=mozc-server-WITH_DEBUG Content-Disposition: attachment; filename=mozc-server-WITH_DEBUG Content-Transfer-Encoding: base64 X-Attachment-Id: f_gevf4tvs1 JCB0cnVzcyAtZmYgbW96Y19zZXJ2ZXIKICAyMjI6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMmYwLDB4 MiwweDdmZmZmZmZmZTMwYywweDdmZmZmZmZmZTMwMCwweDAsMHgwKSA9IDAgKDB4MCkKICAyMjI6 IG1tYXAoMHgwLDMyNzY4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9O LC0xLDB4MCkgPSAzNDM4MzI3ODA4MCAoMHg4MDE2NzMwMDApCiAgMjIyOiBpc3NldHVnaWQoMHg4 MDE2NzQwMTUsMHg4MDE2NmU4ZTQsMHg3ZmZmZmZmZmU5OTgsMHg4MDE3OGEwNDAsMHg1NzMxLDB4 MCkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvZXRjL2xpYm1hcC5jb25mIixPX1JET05MWSwwNjY2 KQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBvcGVuKCIvdmFyL3J1 bi9sZC1lbGYuc28uaGludHMiLE9fUkRPTkxZLDA1NykgPSAyICgweDIpCiAgMjIyOiByZWFkKDIs IkVobnRcXkFcMFwwXDBcTV5AXDBcMFwwXE1eWlwwXDAiLi4uLDEyOCkgPSAxMjggKDB4ODApCiAg MjIyOiBsc2VlaygyLDB4ODAsU0VFS19TRVQpCQkJID0gMTI4ICgweDgwKQogIDIyMjogcmVhZCgy LCIvbGliOi91c3IvbGliOi91c3IvbGliL2NvbXBhdDovdSIuLi4sMTU0KSA9IDE1NCAoMHg5YSkK ICAyMjI6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjIyOiBhY2Nlc3MoIi9saWIvbGliY3Vy bC5zby42IiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNj ZXNzKCIvdXNyL2xpYi9saWJjdXJsLnNvLjYiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIvY29tcGF0L2xpYmN1cmwuc28uNiIsMCkJ IEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xv Y2FsL2xpYi9saWJjdXJsLnNvLjYiLDApCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi91c3IvbG9j YWwvbGliL2xpYmN1cmwuc28uNiIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAyICgweDIpCiAgMjIy OiBmc3RhdCgyLHsgbW9kZT0tcnd4ci14ci14ICxpbm9kZT0yODI2Mzk3LHNpemU9MzU0MzczLGJs a3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgx MDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgx MDAwKQogIDIyMjogbW1hcCgweDAsMTM1OTg3MixQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FO T058TUFQX05PQ09SRSwtMSwweDApID0gMzQzODQ0MjQ5NjAgKDB4ODAxNzhiMDAwKQogIDIyMjog bW1hcCgweDgwMTc4YjAwMCwyODI2MjQsUFJPVF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxN QVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM4NDQyNDk2MCAoMHg4MDE3OGIwMDApCiAg MjIyOiBtbWFwKDB4ODAxOGQwMDAwLDI4NjcyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklW QVRFfE1BUF9GSVhFRCwyLDB4NDUwMDApID0gMzQzODU3NTYxNjAgKDB4ODAxOGQwMDAwKQogIDIy MjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IGFjY2VzcygiL2xpYi9saWJjcnlwdG8u c28uNiIsMCkJCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi9saWIvbGliY3J5cHRvLnNvLjYiLE9f UkRPTkxZLDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIyMjogZnN0YXQoMix7IG1vZGU9LXItLXIt LXItLSAsaW5vZGU9NDAwNDQ4LHNpemU9MTY2OTA4OCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgw KQogIDIyMjogcHJlYWQoMHgyLDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAx MDEsMHg4MDgwODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IG1tYXAoMHgwLDI3 MDc0NTYsUFJPVF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9 IDM0Mzg1Nzg0ODMyICgweDgwMThkNzAwMCkKICAyMjI6IG1tYXAoMHg4MDE4ZDcwMDAsMTM1OTg3 MixQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIs MHgwKSA9IDM0Mzg1Nzg0ODMyICgweDgwMThkNzAwMCkKICAyMjI6IG1tYXAoMHg4MDFiMjMwMDAs MjkwODE2LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MTRj MDAwKSA9IDM0Mzg4MTkzMjgwICgweDgwMWIyMzAwMCkKICAyMjI6IG1wcm90ZWN0KDB4ODAxYjZh MDAwLDgxOTIsUFJPVF9SRUFEfFBST1RfV1JJVEUpID0gMCAoMHgwKQogIDIyMjogY2xvc2UoMikJ CQkJCSA9IDAgKDB4MCkKICAyMjI6IGFjY2VzcygiL2xpYi9saWJ0aHIuc28uMyIsMCkJCSA9IDAg KDB4MCkKICAyMjI6IG9wZW4oIi9saWIvbGlidGhyLnNvLjMiLE9fUkRPTkxZLDAxMzU3NTM3NDAp ID0gMiAoMHgyKQogIDIyMjogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAsaW5vZGU9NDAwNDI2 LHNpemU9ODc5NTIsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHByZWFkKDB4Miww eDgwMTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4 MCkgPSA0MDk2ICgweDEwMDApCiAgMjIyOiBtbWFwKDB4MCwxMTQyNzg0LFBST1RfTk9ORSxNQVBf UFJJVkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4ODQ5MjI4OCAoMHg4MDFi NmMwMDApCiAgMjIyOiBtbWFwKDB4ODAxYjZjMDAwLDczNzI4LFBST1RfUkVBRHxQUk9UX0VYRUMs TUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzODg0OTIyODggKDB4 ODAxYjZjMDAwKQogIDIyMjogbW1hcCgweDgwMWM3ZDAwMCwxNjM4NCxQUk9UX1JFQUR8UFJPVF9X UklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDExMDAwKSA9IDM0Mzg5NjEwNDk2ICgweDgw MWM3ZDAwMCkKICAyMjI6IG1wcm90ZWN0KDB4ODAxYzgxMDAwLDgxOTIsUFJPVF9SRUFEfFBST1Rf V1JJVEUpID0gMCAoMHgwKQogIDIyMjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IGFj Y2VzcygiL2xpYi9saWJydC5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9saWJydC5zby4xIiwwKQkJID0gMCAoMHgwKQog IDIyMjogb3BlbigiL3Vzci9saWIvbGlicnQuc28uMSIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAy ICgweDIpCiAgMjIyOiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT0yNTY3OTAzLHNp emU9MjE3NDQsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHByZWFkKDB4MiwweDgw MTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkg PSA0MDk2ICgweDEwMDApCiAgMjIyOiBtbWFwKDB4MCwxMDY5MDU2LFBST1RfTk9ORSxNQVBfUFJJ VkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4OTYzNTA3MiAoMHg4MDFjODMw MDApCiAgMjIyOiBtbWFwKDB4ODAxYzgzMDAwLDIwNDgwLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQ X1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzODk2MzUwNzIgKDB4ODAx YzgzMDAwKQogIDIyMjogbW1hcCgweDgwMWQ4NzAwMCw0MDk2LFBST1RfUkVBRHxQUk9UX1dSSVRF LE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4NDAwMCkgPSAzNDM5MDcwMDAzMiAoMHg4MDFkODcw MDApCiAgMjIyOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIyMjogYWNjZXNzKCIvbGliL2xp YnNzbC5zby42IiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjog YWNjZXNzKCIvdXNyL2xpYi9saWJzc2wuc28uNiIsMCkJCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4o Ii91c3IvbGliL2xpYnNzbC5zby42IixPX1JET05MWSwwMTM1NzUzNzQwKSA9IDIgKDB4MikKICAy MjI6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTI1NjcxOTIsc2l6ZT0zMzQxNTIs Ymxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHByZWFkKDB4MiwweDgwMTc3YzdjMCww eDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgw eDEwMDApCiAgMjIyOiBtbWFwKDB4MCwxMzgwMzUyLFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBf QU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM5MDcwNDEyOCAoMHg4MDFkODgwMDApCiAgMjIy OiBtbWFwKDB4ODAxZDg4MDAwLDI4NjcyMCxQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRF fE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0MzkwNzA0MTI4ICgweDgwMWQ4ODAwMCkK ICAyMjI6IG1tYXAoMHg4MDFlY2UwMDAsNDUwNTYsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BS SVZBVEV8TUFQX0ZJWEVELDIsMHg0NjAwMCkgPSAzNDM5MjAzOTQyNCAoMHg4MDFlY2UwMDApCiAg MjIyOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIyMjogYWNjZXNzKCIvbGliL2xpYnouc28u NiIsMCkJCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi9saWIvbGliei5zby42IixPX1JET05MWSww MTM1NzUzNzQwKSA9IDIgKDB4MikKICAyMjI6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlu b2RlPTQwMDQzMCxzaXplPTg5NTI4LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiBw cmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4 MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIyMjogbW1hcCgweDAsMTEzODY4OCxQUk9U X05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTIwODQ0 ODAgKDB4ODAxZWQ5MDAwKQogIDIyMjogbW1hcCgweDgwMWVkOTAwMCw4MTkyMCxQUk9UX1JFQUR8 UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0Mzky MDg0NDgwICgweDgwMWVkOTAwMCkKICAyMjI6IG1tYXAoMHg4MDFmZWQwMDAsODE5MixQUk9UX1JF QUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDE0MDAwKSA9IDM0MzkzMjE0 OTc2ICgweDgwMWZlZDAwMCkKICAyMjI6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjIyOiBh Y2Nlc3MoIi9saWIvbGlicHJvdG9idWYuc28uNiIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9saWJwcm90b2J1Zi5zby42IiwwKQkg RVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbGli L2NvbXBhdC9saWJwcm90b2J1Zi5zby42IiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvbGlicHJvdG9idWYuc28uNiIsMCkg PSAwICgweDApCiAgMjIyOiBvcGVuKCIvdXNyL2xvY2FsL2xpYi9saWJwcm90b2J1Zi5zby42IixP X1JET05MWSwwMTM1NzUzNzQwKSA9IDIgKDB4MikKICAyMjI6IGZzdGF0KDIseyBtb2RlPS1yd3hy LXhyLXggLGlub2RlPTI4Mjc3ODQsc2l6ZT0xNDEzMjg1LGJsa3NpemU9MTYzODQgfSkgPSAwICgw eDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAx MDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIyMjogbW1hcCgweDAs MjE4MzE2OCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDAp ID0gMzQzOTMyMjMxNjggKDB4ODAxZmVmMDAwKQogIDIyMjogbW1hcCgweDgwMWZlZjAwMCw5OTUz MjgsUFJPVF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwy LDB4MCkgPSAzNDM5MzIyMzE2OCAoMHg4MDFmZWYwMDApCiAgMjIyOiBtbWFwKDB4ODAyMWUxMDAw LDE0MzM2MCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweGYy MDAwKSA9IDM0Mzk1MjYyOTc2ICgweDgwMjFlMTAwMCkKICAyMjI6IGNsb3NlKDIpCQkJCQkgPSAw ICgweDApCiAgMjIyOiBhY2Nlc3MoIi9saWIvbGlic3RkYysrLnNvLjYiLDApCQkgRVJSIzIgJ05v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbGliL2xpYnN0ZGMr Ky5zby42IiwwKQkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvdXNyL2xpYi9saWJzdGRjKysuc28u NiIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAyICgweDIpCiAgMjIyOiBmc3RhdCgyLHsgbW9kZT0t ci0tci0tci0tICxpbm9kZT0yNTY4MDEwLHNpemU9MTAxODU4NCxibGtzaXplPTE2Mzg0IH0pID0g MCAoMHgwKQogIDIyMjogcHJlYWQoMHgyLDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAx MDEwMTAxMDEsMHg4MDgwODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IG1tYXAo MHgwLDIxNDIyMDgsUFJPVF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEs MHgwKSA9IDM0Mzk1NDA2MzM2ICgweDgwMjIwNDAwMCkKICAyMjI6IG1tYXAoMHg4MDIyMDQwMDAs ODc2NTQ0LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NP UkUsMiwweDApID0gMzQzOTU0MDYzMzYgKDB4ODAyMjA0MDAwKQogIDIyMjogbW1hcCgweDgwMjNk OTAwMCwxNDMzNjAsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIs MHhkNTAwMCkgPSAzNDM5NzMyNzM2MCAoMHg4MDIzZDkwMDApCiAgMjIyOiBtcHJvdGVjdCgweDgw MjNmYzAwMCw3NzgyNCxQUk9UX1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCiAgMjIyOiBjbG9z ZSgyKQkJCQkJID0gMCAoMHgwKQogIDIyMjogYWNjZXNzKCIvbGliL2xpYm0uc28uNSIsMCkJCSA9 IDAgKDB4MCkKICAyMjI6IG9wZW4oIi9saWIvbGlibS5zby41IixPX1JET05MWSwwMTM1NzUzNzQw KSA9IDIgKDB4MikKICAyMjI6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQwMDM5 MSxzaXplPTEzNjc0NCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogcHJlYWQoMHgy LDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgwODA4MDgwODA4 MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IG1tYXAoMHgwLDExNzU1NTIsUFJPVF9OT05FLE1B UF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzk3NTQ4NTQ0ICgweDgw MjQwZjAwMCkKICAyMjI6IG1tYXAoMHg4MDI0MGYwMDAsMTIyODgwLFBST1RfUkVBRHxQUk9UX0VY RUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTc1NDg1NDQg KDB4ODAyNDBmMDAwKQogIDIyMjogbW1hcCgweDgwMjUyYzAwMCw4MTkyLFBST1RfUkVBRHxQUk9U X1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MWQwMDApID0gMzQzOTg3MTU5MDQgKDB4 ODAyNTJjMDAwKQogIDIyMjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IGFjY2Vzcygi L2xpYi9saWJnY2Nfcy5zby4xIiwwKQkJID0gMCAoMHgwKQogIDIyMjogb3BlbigiL2xpYi9saWJn Y2Nfcy5zby4xIixPX1JET05MWSwwMTM1NzUzNzQwKSA9IDIgKDB4MikKICAyMjI6IGZzdGF0KDIs eyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQwMDQ0NCxzaXplPTU2MTkyLGJsa3NpemU9MTYzODQg fSkgPSAwICgweDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEw MTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIyMjog bW1hcCgweDAsMTEwMTgyNCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09S RSwtMSwweDApID0gMzQzOTg3MjQwOTYgKDB4ODAyNTJlMDAwKQogIDIyMjogbW1hcCgweDgwMjUy ZTAwMCw0OTE1MixQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBf Tk9DT1JFLDIsMHgwKSA9IDM0Mzk4NzI0MDk2ICgweDgwMjUyZTAwMCkKICAyMjI6IG1tYXAoMHg4 MDI2MzkwMDAsODE5MixQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQs MiwweGIwMDApID0gMzQzOTk4MTc3MjggKDB4ODAyNjM5MDAwKQogIDIyMjogY2xvc2UoMikJCQkJ CSA9IDAgKDB4MCkKICAyMjI6IGFjY2VzcygiL2xpYi9saWJjLnNvLjciLDApCQkgPSAwICgweDAp CiAgMjIyOiBvcGVuKCIvbGliL2xpYmMuc28uNyIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAyICgw eDIpCiAgMjIyOiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT00MDAzODgsc2l6ZT0x MTgwMDA4LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDE3 N2M3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0g NDA5NiAoMHgxMDAwKQogIDIyMjogbW1hcCgweDAsMjMwNjA0OCxQUk9UX05PTkUsTUFQX1BSSVZB VEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTk4MjU5MjAgKDB4ODAyNjNiMDAw KQogIDIyMjogbW1hcCgweDgwMjYzYjAwMCwxMDE1ODA4LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQ X1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTk4MjU5MjAgKDB4ODAy NjNiMDAwKQogIDIyMjogbW1hcCgweDgwMjgzMzAwMCwxMzEwNzIsUFJPVF9SRUFEfFBST1RfV1JJ VEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHhmODAwMCkgPSAzNDQwMTg5MDMwNCAoMHg4MDI4 MzMwMDApCiAgMjIyOiBtcHJvdGVjdCgweDgwMjg1MzAwMCwxMTA1OTIsUFJPVF9SRUFEfFBST1Rf V1JJVEUpID0gMCAoMHgwKQogIDIyMjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IHN5 c2FyY2goMHg4MSwweDdmZmZmZmZmZTQwMCwweDgwMTY3ODYwOCwweDAsMHhmZmZmZmZmZmZlZTNi ZWQwLDB4ODA4MDgwODA4MDgwODA4MCkgPSAwICgweDApCiAgMjIyOiBtbWFwKDB4MCw0NTA1NixQ Uk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwtMSwweDApID0gMzQzODMz MTA4NDggKDB4ODAxNjdiMDAwKQogIDIyMjogbXVubWFwKDB4ODAxNjdmMDAwLDI4NjcyKQkJID0g MCAoMHgwKQogIDIyMjogbW1hcCgweDAsMTAyNDAwLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9Q UklWQVRFfE1BUF9BTk9OLC0xLDB4MCkgPSAzNDM4MzMyNzIzMiAoMHg4MDE2N2YwMDApCiAgMjIy OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lH UElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NI TER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJP RnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjog c2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IF9fc3lz Y3RsKDB4N2ZmZmZmZmZlMzkwLDB4MiwweDgwMjg1OTMyMCwweDdmZmZmZmZmZTM4OCwweDAsMHgw KSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJ R1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdU U1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNa fFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkg PSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAo MHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxT SUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lH Q09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRB TFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4 MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAg MjIyOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8 U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJ R0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lH UFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIy Mjogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IGdl dHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiBfX3N5c2N0bCgweDdmZmZmZmZmZTM1MCww eDIsMHg4MDFjODJlNzAsMHg3ZmZmZmZmZmUzNTgsMHgwLDB4MCkgPSAwICgweDApCiAgMjIyOiBf X3N5c2N0bCgweDdmZmZmZmZmZTI3MCwweDIsMHg3ZmZmZmZmZmUyOTAsMHg3ZmZmZmZmZmUyZjgs MHg4MDFiN2NmZDgsMHhkKSA9IDAgKDB4MCkKICAyMjI6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMjkw LDB4MywweDgwMWM4MWQ2OCwweDdmZmZmZmZmZTM1OCwweDAsMHgwKSA9IDAgKDB4MCkKICAyMjI6 IF9fc3lzY3RsKDB4N2ZmZmZmZmZkZTAwLDB4MiwweDdmZmZmZmZmZGUyYywweDdmZmZmZmZmZGUy MCwweDAsMHgwKSA9IDAgKDB4MCkKICAyMjI6IF9fc3lzY3RsKDB4N2ZmZmZmZmZkY2YwLDB4Miww eDdmZmZmZmZmZGQxMCwweDdmZmZmZmZmZGQ3OCwweDgwMjcyNjU0MCwweGMpID0gMCAoMHgwKQog IDIyMjogX19zeXNjdGwoMHg3ZmZmZmZmZmRkMTAsMHgyLDB4ODAyODU4ZDcwLDB4N2ZmZmZmZmZk ZGMwLDB4MCwweDApID0gMCAoMHgwKQogIDIyMjogcmVhZGxpbmsoIi9ldGMvbWFsbG9jLmNvbmYi LDB4N2ZmZmZmZmZkZTMwLDEwMjQpIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwog IDIyMjogaXNzZXR1Z2lkKDB4ODAyNzI1MTRmLDB4N2ZmZmZmZmZkZTMwLDB4ZmZmZmZmZmZmZmZm ZmZmZiwweDAsMHgyLDB4MCkgPSAwICgweDApCiAgMjIyOiBicmVhaygweDE4MDAwMDApCQkJCSA9 IDAgKDB4MCkKICAyMjI6IF9fc3lzY3RsKDB4N2ZmZmZmZmZkZTUwLDB4MiwweDdmZmZmZmZmZGU2 YywweDdmZmZmZmZmZGU2MCwweDAsMHgwKSA9IDAgKDB4MCkKICAyMjI6IG1tYXAoMHgwLDQxOTQz MDQsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0FOT04sLTEsMHgwKSA9IDM0 NDAyMTMxOTY4ICgweDgwMjg2ZTAwMCkKICAyMjI6IG1tYXAoMHg4MDJjNmUwMDAsMzc0Mzc0NCxQ Uk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwtMSwweDApID0gMzQ0MDYz MjYyNzIgKDB4ODAyYzZlMDAwKQogIDIyMjogbXVubWFwKDB4ODAyODZlMDAwLDM3NDM3NDQpCQkg PSAwICgweDApCiAgMjIyOiB0aHJfc2VsZigweDgwMmMwNzFjMCwweDAsMHgwLDB4MCwweDE4OCww eDE3M2FkNDApID0gMCAoMHgwKQogIDIyMjogbW1hcCgweDdmZmZmZmJmZjAwMCw0MDk2LFBST1Rf Tk9ORSxNQVBfQU5PTiwtMSwweDApID0gMTQwNzM3NDg0MTU2OTI4ICgweDdmZmZmZmJmZjAwMCkK ICAyMjI6IHRocl9zZXRfbmFtZSgweDE4ODFjLDB4ODAxYjdkMDIwLDB4MCwweDEwMDAsMHhmZmZm ZmZmZiwweDApID0gMCAoMHgwKQogIDIyMjogcnRwcmlvX3RocmVhZCgweDAsMHgxODgxYywweDdm ZmZmZmZmZTMwMCwweDEwMDAsMHhmZmZmZmZmZiwweDApID0gMCAoMHgwKQogIDIyMjogc3lzYXJj aCgweDgxLDB4N2ZmZmZmZmZlMzIwLDB4ODAxYzgxOTQwLDB4ODAxYzgxY2M4LDB4ZmZmZmZmZmYs MHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLFNJR0hVUHxTSUdJ TlR8U0lHUVVJVHxTSUdJTEx8U0lHQUJSVHxTSUdFTVR8U0lHRlBFfFNJR0tJTEx8U0lHQlVTfFNJ R1NFR1Z8U0lHU1lTfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RT VFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8 U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9 IDAgKDB4MCkKICAyMjI6IHNpZ2FjdGlvbigzMix7IDB4ODAxYjc3Mzc1IFNBX1JFU1RBUlR8U0Ff U0lHSU5GTyBzc190IH0sMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRN QVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lH SFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJH fFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJ R1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8 U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgw LDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lH SU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RP UHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxT SUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1Iy LDB4MCkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJ ID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgwMmMwZjAwMCwweDEwMDAsMHg1LDB4ZSwweDIw MDgsMHhiKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjMGYwMDAsMHgxMDAwLDB4NSww eGUsMHgyMDA4LDB4N2ZmZmZmZmZkNzQwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJj MjAwMDAsMHgxMDAwLDB4NSwweDFmLDB4MjAwOCwweDE3M2FkNDApID0gMCAoMHgwKQogIDIyMjog bWFkdmlzZSgweDgwMmMyNjAwMCwweDEwMDAsMHg1LDB4MjUsMHg1MDA4LDB4N2ZmZmZmZmZkNTgw KSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjMjIwMDAsMHgxMDAwLDB4NSwweDIxLDB4 NTAwOCwweDdmZmZmZmZmZDU4MCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzFlMDAw LDB4MTAwMCwweDUsMHgxZCwweDIwMDgsMHg3ZmZmZmZmZmQ1ODApID0gMCAoMHgwKQogIDIyMjog bWFkdmlzZSgweDgwMmMxOTAwMCwweDEwMDAsMHg1LDB4MTgsMHgxLDB4N2ZmZmZmZmZkNWEwKSA9 IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjMTgwMDAsMHgxMDAwLDB4NSwweDE3LDB4MTcz YWUzMCwweDdmZmZmZmZmZDVlMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzIwMDAw LDB4MTAwMCwweDUsMHgxZiwweGYwMDAsMHg3ZmZmZmZmZmQ2MDApID0gMCAoMHgwKQogIDIyMjog bWFkdmlzZSgweDgwMmMxYTAwMCwweDEwMDAsMHg1LDB4MTksMHgxMDA4LDB4MTczYWQ0MCkgPSAw ICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlU fFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxT SUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdW VEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAo MHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkK ICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lM THxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8 U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxT SUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAg MjIyOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjog c2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJ UEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExE fFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8 U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNp Z3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9j bWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdB TFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJ TnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5D SHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21h c2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJ R19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lH VEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RU T1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lO Rk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdf U0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX0JMT0NL LFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJ R1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJ T3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdV U1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNL LDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzQ0MDAwLDB4MTAwMCww eDUsMHg0MywweDEsMHg3ZmZmZmZmZmRhYTApID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgw MmMzZDAwMCwweDEwMDAsMHg1LDB4M2MsMHgxLDB4N2ZmZmZmZmZkYWEwKSA9IDAgKDB4MCkKICAy MjI6IG1hZHZpc2UoMHg4MDJjM2MwMDAsMHgxMDAwLDB4NSwweDNiLDB4MTczYWUzMCwweDdmZmZm ZmZmZGI3MCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzI1MDAwLDB4MTAwMCwweDUs MHgyNCwweDE3M2FlMzAsMHg3ZmZmZmZmZmRiNzApID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgw eDgwMmMyNDAwMCwweDEwMDAsMHg1LDB4MjMsMHgxLDB4N2ZmZmZmZmZkYWYwKSA9IDAgKDB4MCkK ICAyMjI6IG1hZHZpc2UoMHg4MDJjMWMwMDAsMHgyMDAwLDB4NSwweDFiLDB4MSwweDdmZmZmZmZm ZGFmMCkgPSAwICgweDApCiAgMjIyOiBnZXRldWlkKCkJCQkJID0gMTAwMCAoMHgzZTgpCiAgMjIy OiBnZXR1aWQoKQkJCQkJID0gMTAwMCAoMHgzZTgpCiAgMjIyOiBnZXRldWlkKCkJCQkJID0gMTAw MCAoMHgzZTgpCiAgMjIyOiBzdGF0KCIvZXRjL25zc3dpdGNoLmNvbmYiLHsgbW9kZT0tcnctci0t ci0tICxpbm9kZT0xNDEzNTksc2l6ZT0yNTUsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAy MjI6IG9wZW4oIi9ldGMvbnNzd2l0Y2guY29uZiIsT19SRE9OTFksMDY2NikJID0gMiAoMHgyKQog IDIyMjogaW9jdGwoMixUSU9DR0VUQSwweGZmZmZkZDgwKQkJIEVSUiMyNSAnSW5hcHByb3ByaWF0 ZSBpb2N0bCBmb3IgZGV2aWNlJwogIDIyMjogZnN0YXQoMix7IG1vZGU9LXJ3LXItLXItLSAsaW5v ZGU9MTQxMzU5LHNpemU9MjU1LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiByZWFk KDIsIiNcbiMgbnNzd2l0Y2guY29uZig1KSAtIG5hbWUgc2VyIi4uLiwxNjM4NCkgPSAyNTUgKDB4 ZmYpCiAgMjIyOiByZWFkKDIsMHg4MDJjNTQwMDAsMTYzODQpCQkgPSAwICgweDApCiAgMjIyOiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQ RXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8 U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxT SUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogYWNj ZXNzKCIvbGliL25zc19jb21wYXQuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIvbnNzX2NvbXBhdC5zby4xIiwwKQkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbGliL2Nv bXBhdC9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2tk ZTQvbGliL25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2NvbXBhdC9uc3NfY29tcGF0LnNvLjEi LDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNy L2xvY2FsL2xpYi9nZWdsLTAuMS9uc3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9ncmFwaHZpei9u c3NfY29tcGF0LnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIy MjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9xdDQvbnNzX2NvbXBhdC5zby4xIiwwKSBFUlIjMiAn Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL2xpYi9uc3NfY29tcGF0 LnNvLjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nl c3MoIi91c3IvbGliL25zc19jb21wYXQuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5JwogIDIyMjogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAg KDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8 U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJ R0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZU QUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgw eDApCiAgMjIyOiBhY2Nlc3MoIi9saWIvbnNzX25pcy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9uc3NfbmlzLnNvLjEi LDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vz ci9saWIvY29tcGF0L25zc19uaXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfbmlzLnNvLjEiLDApCSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9sb2Nh bC9rZGU0L2xpYi9uc3NfbmlzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX25pcy5zby4xIiww KSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9s b2NhbC9saWIvZ2VnbC0wLjEvbnNzX25pcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9y IGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXovbnNzX25p cy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2Vz cygiL3Vzci9sb2NhbC9saWIvcXQ0L25zc19uaXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi9saWIvbnNzX25pcy5zby4xIiwwKQkJIEVS UiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9u c3NfbmlzLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6 IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdw cm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxT SUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lH VFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdX SU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogYWNjZXNz KCIvbGliL25zc19maWxlcy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xpYi9jb21wYXQv bnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIy MjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwva2RlNC9saWIv bnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIy MjogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIyMjogYWNjZXNzKCIvdXNyL2xvY2FsL2xp Yi9nZWdsLTAuMS9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dyYXBodml6L25zc19maWxlcy5z by4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2Vzcygi L3Vzci9sb2NhbC9saWIvcXQ0L25zc19maWxlcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxl IG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJCSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIv bnNzX2ZpbGVzLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAy MjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQ RXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8 U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxT SUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogYWNj ZXNzKCIvbGliL25zc19kbnMuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIvbnNzX2Rucy5zby4xIiwwKQkgRVJSIzIgJ05v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbGliL2NvbXBhdC9u c3NfZG5zLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6 IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvbnNzX2Rucy5zby4xIiwwKQkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwva2RlNC9saWIvbnNz X2Rucy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFj Y2VzcygiL3Vzci9sb2NhbC9saWIvY29tcGF0L25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dlZ2wt MC4xL25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAg MjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2dyYXBodml6L25zc19kbnMuc28uMSIsMCkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBhY2Nlc3MoIi91c3IvbG9jYWwv bGliL3F0NC9uc3NfZG5zLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 JwogIDIyMjogYWNjZXNzKCIvbGliL25zc19kbnMuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBm aWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGFjY2VzcygiL3Vzci9saWIvbnNzX2Rucy5zby4xIiww KQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIyOiBzaWdwcm9jbWFzayhT SUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjogaW9jdGwoMixUSU9DR0VUQSww eGZmZmZkZDkwKQkJIEVSUiMyNSAnSW5hcHByb3ByaWF0ZSBpb2N0bCBmb3IgZGV2aWNlJwogIDIy MjogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjNTQwMDAsMHg0 MDAwLDB4NSwweDUzLDB4NGMwMDgsMHg4MDI4NWFmYzApID0gMCAoMHgwKQogIDIyMjogc2lncHJv Y21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lH QUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RU SU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lO Q0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2Nt YXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhT SUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJ R1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdU VE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJ TkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21hc2soU0lH X1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMjI6IGdldGV1aWQoKQkJCQkgPSAxMDAw ICgweDNlOCkKICAyMjI6IG9wZW4oIi9ldGMvcHdkLmRiIixPX1JET05MWSwwMCkJCSA9IDIgKDB4 MikKICAyMjI6IGZjbnRsKDIsRl9TRVRGRCxGRF9DTE9FWEVDKQkJID0gMCAoMHgwKQogIDIyMjog ZnN0YXQoMix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MTQxNTM3LHNpemU9NDA5NjAsYmxrc2l6 ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHJlYWQoMiwiXDBcXkZcXlVhXDBcMFwwXF5CXDBc MFxeRFxNLVJcMCIuLi4sMjYwKSA9IDI2MCAoMHgxMDQpCiAgMjIyOiBwcmVhZCgweDIsMHg4MDJj YTIwMDAsMHgxMDAwLDB4NjAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IHByZWFk KDB4MiwweDgwMmNhMzAwMCwweDEwMDAsMHg0MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQog IDIyMjogcHJlYWQoMHgyLDB4ODAyY2E0MDAwLDB4MTAwMCwweDUwMDAsMHgxLDB4MCkgPSA0MDk2 ICgweDEwMDApCiAgMjIyOiBwcmVhZCgweDIsMHg4MDJjYTUwMDAsMHgxMDAwLDB4NzAwMCwweDEs MHgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IHByZWFkKDB4MiwweDgwMmNhNjAwMCwweDEwMDAs MHg4MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQogIDIyMjogcHJlYWQoMHgyLDB4ODAyY2E3 MDAwLDB4MTAwMCwweDEwMDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCiAgMjIyOiBwcmVhZCgw eDIsMHg4MDJjYTgwMDAsMHgxMDAwLDB4MjAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKICAy MjI6IHByZWFkKDB4MiwweDgwMmNhOTAwMCwweDEwMDAsMHgzMDAwLDB4MSwweDApID0gNDA5NiAo MHgxMDAwKQogIDIyMjogbWFkdmlzZSgweDgwMmNhODAwMCwweDIwMDAsMHg1LDB4YTcsMHgxLDB4 MCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyY2EyMDAwLDB4NDAwMCwweDUsMHhhMSww eDEsMHgwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjYTYwMDAsMHgyMDAwLDB4NSww eGE1LDB4MSwweDdmZmZmZmZmZDIxMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyY2Ex MDAwLDB4MTAwMCwweDUsMHhhMCwweDEsMHg3ZmZmZmZmZmQyMTApID0gMCAoMHgwKQogIDIyMjog Y2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJjNTkwMDAsMHgyMDAw LDB4NSwweDU4LDB4NGMwMDgsMHg3ZmZmZmZmZmQyNTApID0gMCAoMHgwKQogIDIyMjogbWtkaXIo Ii91c3IvaG9tZS9nY29vcGVyLy5tb3pjIiwwNzAwKQkgRVJSIzE3ICdGaWxlIGV4aXN0cycKICAy MjI6IHN0YXQoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjIix7IG1vZGU9ZHJ3eC0tLS0tLSAsaW5v ZGU9MzAzOTI1MSxzaXplPTUxMixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogb3Bl bigiL3Vzci9ob21lL2djb29wZXIvLm1vemMvbW96Y19zZXJ2ZXIubG9nIixPX1dST05MWXxPX0FQ UEVORHxPX0NSRUFULDA2NjYpID0gMiAoMHgyKQogIDIyMjogbHNlZWsoMiwweDAsU0VFS19FTkQp CQkJID0gMCAoMHgwKQogIDIyMjogY2htb2QoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjL21vemNf c2VydmVyLmxvZyIsMDYwMCkgPSAwICgweDApCiAgMjIyOiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2 MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IGFjY2VzcygiL2V0Yy9sb2NhbHRp bWUiLDQpCQkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvZXRjL2xvY2FsdGltZSIsT19SRE9OTFks MDEpCSA9IDMgKDB4MykKICAyMjI6IGZzdGF0KDMseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTE0 MTQwMyxzaXplPTI4MTksYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IHJlYWQoMywi VFppZjJcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sNDE0NDgpID0gMjgxOSAoMHhiMDMp CiAgMjIyOiBjbG9zZSgzKQkJCQkJID0gMCAoMHgwKQogIDIyMjogaXNzZXR1Z2lkKDB4ODAyNzJj ZTU5LDB4N2ZmZmZmZmY5YzEwLDB4MCwweDdmZmZmZmZlZmEyNSwweDUwLDB4OCkgPSAwICgweDAp CiAgMjIyOiBvcGVuKCIvdXNyL3NoYXJlL3pvbmVpbmZvL3Bvc2l4cnVsZXMiLE9fUkRPTkxZLDA1 NikgPSAzICgweDMpCiAgMjIyOiBmc3RhdCgzLHsgbW9kZT0tci0tci0tci0tICxpbm9kZT0yMTUw NTE0LHNpemU9MzUxOSxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogcmVhZCgzLCJU WmlmMlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiw0MTQ0OCkgPSAzNTE5ICgweGRiZikK ICAyMjI6IGNsb3NlKDMpCQkJCQkgPSAwICgweDApCiAgMjIyOiBnZXRwaWQoKQkJCQkJID0gMjIy ICgweGRlKQogIDIyMjogd3JpdGUoMiwiTG9nIGZpbGUgY3JlYXRlZCBhdDogMjAxMC0xMC0wNCAi Li4uLDU3KSA9IDU3ICgweDM5KQogIDIyMjogd3JpdGUoMiwiUHJvZ3JhbSBuYW1lOiBtb3pjX3Nl cnZlclxuIiwyNikgPSAyNiAoMHgxYSkKICAyMjI6IGNobW9kKCIvdXNyL2hvbWUvZ2Nvb3Blci8u bW96Yy8uc2VydmVyLmxvY2siLDA2MDApID0gMCAoMHgwKQogIDIyMjogb3BlbigiL3Vzci9ob21l L2djb29wZXIvLm1vemMvLnNlcnZlci5sb2NrIixPX1JEV1J8T19DUkVBVHxPX1RSVU5DLDA2MDAp ID0gMyAoMHgzKQogIDIyMjogZmNudGwoMyxGX1NFVExLLDB4N2ZmZmZmZmZlNWYwKQkJID0gMCAo MHgwKQogIDIyMjogY2htb2QoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5zZXJ2ZXIubG9jayIs MDQwMCkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvZGV2L3VyYW5kb20iLE9fUkRPTkxZLDA2NjYp CSA9IDQgKDB4NCkKICAyMjI6IHJlYWQoNCwiXE1eTXZcTS1aXE0tYlxNLTpcTS1cXF5WXE0te1xN XkoiLi4uLDEwMjMpID0gMTAyMyAoMHgzZmYpCiAgMjIyOiBjbG9zZSg0KQkJCQkJID0gMCAoMHgw KQogIDIyMjogc3RhdCgiL3Vzci9ob21lL2djb29wZXIvLm1vemMvLnNlc3Npb24uaXBjIix7IG1v ZGU9LXItLS0tLS0tLSAsaW5vZGU9MzAzOTI1MyxzaXplPTU2LGJsa3NpemU9MTYzODQgfSkgPSAw ICgweDApCiAgMjIyOiBvcGVuKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96Yy8uc2Vzc2lvbi5pcGMi LE9fUkRPTkxZLDA2NjYpID0gNCAoMHg0KQogIDIyMjogcmVhZCg0LCJcbiBlZmQyMWRmYjZmYzAy ZDkyYjM3NzVjMGI5MTkxOCIuLi4sODE5MikgPSA1NiAoMHgzOCkKICAyMjI6IHJlYWQoNCwweDgw MmNlNDAzOCw4MTM2KQkJCSA9IDAgKDB4MCkKICAyMjI6IHN0YXQoIi91c3IvaG9tZS9nY29vcGVy Ly5tb3pjLy5zZXNzaW9uLmlwYyIseyBtb2RlPS1yLS0tLS0tLS0gLGlub2RlPTMwMzkyNTMsc2l6 ZT01NixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogY2xvc2UoNCkJCQkJCSA9IDAg KDB4MCkKICAyMjI6IG1rZGlyKCIvdG1wIiwwNzAwKQkJCSBFUlIjMTcgJ0ZpbGUgZXhpc3RzJwog IDIyMjogc29ja2V0KFBGX0xPQ0FMLFNPQ0tfU1RSRUFNLDApCQkgPSA0ICgweDQpCiAgMjIyOiBm Y250bCg0LEZfR0VURkQsKQkJCSA9IDAgKDB4MCkKICAyMjI6IGZjbnRsKDQsRl9TRVRGRCxGRF9D TE9FWEVDKQkJID0gMCAoMHgwKQogIDIyMjogc2V0c29ja29wdCgweDQsMHhmZmZmLDB4NCwweDdm ZmZmZmZmZTY3YywweDQsMHg0KSA9IDAgKDB4MCkKICAyMjI6IGJpbmQoNCx7IEFGX1VOSVggIi90 bXAvLm1vemMuZWZkMjFkZmI2ZmMwMmQ5MmIzNzc1YzBiOTE5MThhMTkuc2Vzc2lvbiIgfSwxMDYp ID0gMCAoMHgwKQogIDIyMjogY2htb2QoIi90bXAvLm1vemMuZWZkMjFkZmI2ZmMwMmQ5MmIzNzc1 YzBiOTE5MThhMTkuc2Vzc2lvbiIsMDYwMCkgPSAwICgweDApCiAgMjIyOiBsaXN0ZW4oMHg0LDB4 YSwweDZhLDB4MmUsMHhmZWZlZmVmZWZlZmVmZWZmLDB4NCkgPSAwICgweDApCiAgMjIyOiBnZXRw aWQoKQkJCQkJID0gMjIyICgweGRlKQogIDIyMjogY2htb2QoIi91c3IvaG9tZS9nY29vcGVyLy5t b3pjLy5zZXNzaW9uLmlwYyIsMDYwMCkgPSAwICgweDApCiAgMjIyOiBvcGVuKCIvdXNyL2hvbWUv Z2Nvb3Blci8ubW96Yy8uc2Vzc2lvbi5pcGMiLE9fUkRXUnxPX0NSRUFUfE9fVFJVTkMsMDYwMCkg PSA1ICgweDUpCiAgMjIyOiBmY250bCg1LEZfU0VUTEssMHg3ZmZmZmZmZmUzMjApCQkgPSAwICgw eDApCiAgMjIyOiB3cml0ZSg1LCJcbiBlZmQyMWRmYjZmYzAyZDkyYjM3NzVjMGI5MTkxOCIuLi4s NTUpID0gNTUgKDB4MzcpCiAgMjIyOiBjaG1vZCgiL3Vzci9ob21lL2djb29wZXIvLm1vemMvLnNl c3Npb24uaXBjIiwwNDAwKSA9IDAgKDB4MCkKICAyMjI6IHN0YXQoIi91c3IvaG9tZS9nY29vcGVy Ly5tb3pjLy5zZXNzaW9uLmlwYyIseyBtb2RlPS1yLS0tLS0tLS0gLGlub2RlPTMwMzkyNTMsc2l6 ZT01NSxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogb3BlbigiL3Vzci9ob21lL2dj b29wZXIvLm1vemMvY29uZmlnMS5kYiIsT19SRE9OTFksMDY2NikgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjIyOiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAw MDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IGdldHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIy OiB3cml0ZSgyLCIyMDEwLTEwLTA0IDA3OjA2OjU4IDIyMiAzNDQwNTkwNCIuLi4sMTA5KSA9IDEw OSAoMHg2ZCkKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0p ID0gMCAoMHgwKQogIDIyMjogZ2V0cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRl KDIsIjIwMTAtMTAtMDQgMDc6MDY6NTggMjIyIDM0NDA1OTA0Ii4uLiwxMzgpID0gMTM4ICgweDhh KQogIDIyMjogY2xvY2tfZ2V0dGltZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgw eDApCiAgMjIyOiBnZXRwaWQoKQkJCQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAx MC0xMC0wNCAwNzowNjo1OCAyMjIgMzQ0MDU5MDQiLi4uLDE0MikgPSAxNDIgKDB4OGUpCiAgMjIy OiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAy MjI6IGdldHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiB3cml0ZSgyLCIyMDEwLTEwLTA0 IDA3OjA2OjU4IDIyMiAzNDQwNTkwNCIuLi4sMTM1KSA9IDEzNSAoMHg4NykKICAyMjI6IGNsb2Nr X2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogZ2V0 cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIsIjIwMTAtMTAtMDQgMDc6MDY6 NTggMjIyIDM0NDA1OTA0Ii4uLiwxMzkpID0gMTM5ICgweDhiKQogIDIyMjogY2xvY2tfZ2V0dGlt ZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgweDApCiAgMjIyOiBnZXRwaWQoKQkJ CQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAxMC0xMC0wNCAwNzowNjo1OCAyMjIg MzQ0MDU5MDQiLi4uLDEzNCkgPSAxMzQgKDB4ODYpCiAgMjIyOiBjbG9ja19nZXR0aW1lKDEzLHsx Mjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IGdldHBpZCgpCQkJCQkgPSAy MjIgKDB4ZGUpCiAgMjIyOiB3cml0ZSgyLCIyMDEwLTEwLTA0IDA3OjA2OjU4IDIyMiAzNDQwNTkw NCIuLi4sMTM4KSA9IDEzOCAoMHg4YSkKICAyMjI6IG1hZHZpc2UoMHg4MDJjZTQwMDAsMHg0MDAw LDB4NSwweGUzLDB4MTczYWUzMCwweDdmZmZmZmZmZDViMCkgPSAwICgweDApCiAgMjIyOiBjbG9j a19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IG9w ZW4oIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjL2JvdW5kYXJ5LmRiIixPX1JEV1IsMDApID0gNiAo MHg2KQogIDIyMjogZnN0YXQoNix7IG1vZGU9LXJ3LXItLXItLSAsaW5vZGU9MzAzOTI1NCxzaXpl PTgwMDEyLGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjIyOiBtbWFwKDB4MCw4MDAxMixQ Uk9UX1JFQUR8UFJPVF9XUklURSxNQVBfU0hBUkVELDYsMHgwKSA9IDM0MzgzNDI5NjMyICgweDgw MTY5ODAwMCkKICAyMjI6IGNsb3NlKDYpCQkJCQkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4 ODAyZDM3MDAwLDB4ODAwMCwweDUsMHgxMzYsMHgxLDB4N2ZmZmZmZmZkNWUwKSA9IDAgKDB4MCkK ICAyMjI6IG1hZHZpc2UoMHg4MDJjZTcwMDAsMHg0MDAwLDB4NSwweGU2LDB4MSwweDdmZmZmZmZm ZDVlMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyZDJmMDAwLDB4MTAwMCwweDUsMHgx MmUsMHhlMDA4LDB4N2ZmZmZmZmZkNmUwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJj ZTMwMDAsMHgxMDAwLDB4NSwweGUyLDB4ZTAwOCwweDdmZmZmZmZmZDZlMCkgPSAwICgweDApCiAg MjIyOiBtYWR2aXNlKDB4ODAyYzc1MDAwLDB4YTAwMCwweDUsMHg3NCwweGUwMDgsMHg3ZmZmZmZm ZmQ2ZTApID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgwMmM2NTAwMCwweDEwMDAwLDB4NSww eDY0LDB4MWUwMDgsMHg3ZmZmZmZmZmQ2ZTApID0gMCAoMHgwKQogIDIyMjogb3BlbigiL3Vzci9o b21lL2djb29wZXIvLm1vemMvc2VnbWVudC5kYiIsT19SRFdSLDAwKSA9IDYgKDB4NikKICAyMjI6 IGZzdGF0KDYseyBtb2RlPS1ydy1yLS1yLS0gLGlub2RlPTMwMzkyNTUsc2l6ZT0zMjAwMTIsYmxr c2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMjI6IG1tYXAoMHgwLDMyMDAxMixQUk9UX1JFQUR8 UFJPVF9XUklURSxNQVBfU0hBUkVELDYsMHgwKSA9IDM0MzgzNTExNTUyICgweDgwMTZhYzAwMCkK ICAyMjI6IGNsb3NlKDYpCQkJCQkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyZDM3MDAw LDB4ODAwMCwweDUsMHgxMzYsMHgxLDB4N2ZmZmZmZmZkNWUwKSA9IDAgKDB4MCkKICAyMjI6IG1h ZHZpc2UoMHg4MDJjZTcwMDAsMHg0MDAwLDB4NSwweGU2LDB4MSwweDdmZmZmZmZmZDVlMCkgPSAw ICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyZDJmMDAwLDB4MTAwMCwweDUsMHgxMmUsMHgxZTAw OCwweDdmZmZmZmZmZDZhMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAyYzY1MDAwLDB4 MTAwMDAsMHg1LDB4NjQsMHgxZTAwOCwweDdmZmZmZmZmZDZhMCkgPSAwICgweDApCiAgMjIyOiBt YWR2aXNlKDB4ODAyY2UzMDAwLDB4MjAwMDAsMHg1LDB4ZTIsMHgxNzNhZTMwLDB4N2ZmZmZmZmZk NWQwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDJkNDMwMDAsMHgyODAwMCwweDUsMHgx NDIsMHg4MDJjMDA5YTAsMHg3ZmZmZmZmZmQ2ZTApID0gMCAoMHgwKQogIDIyMjogbWFkdmlzZSgw eDgwMmQwMzAwMCwweDQwMDAwLDB4NSwweDEwMiwweDE3M2FlMzAsMHg3ZmZmZmZmZmQ2ZDApID0g MCAoMHgwKQogIDIyMjogX3VtdHhfb3AoMHg3ZmZmZmZmZmUzZTgsMHgzLDB4MSwweDAsMHgwLDB4 MTczYWQ0MCkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJ R0lOVHxTSUdRVUlUfFNJR0FCUlR8U0lHRU1UfFNJR0tJTEx8U0lHU1lTfFNJR1BJUEV8U0lHQUxS TXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58 U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8 U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNr KFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdf QkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0FCUlR8U0lHRU1UfFNJR0tJTEx8U0lHU1lT fFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxT SUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJ R1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAy MjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBt bWFwKDB4N2ZmZmZmOWZlMDAwLDIxMDEyNDgsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1NUQUNL LC0xLDB4MCkgPSAxNDA3Mzc0ODIwNTU2ODAgKDB4N2ZmZmZmOWZlMDAwKQogIDIyMjogbXByb3Rl Y3QoMHg3ZmZmZmY5ZmUwMDAsNDA5NixQUk9UX05PTkUpCSA9IDAgKDB4MCkKICAyMjI6IHRocl9u ZXcoMHg3ZmZmZmZmZmU0MzAsMHg2OCwweDgwMWM4MTk0MCwweDE4ODFjLDB4ZmZmZmZmZmYsMHgw KSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5oaXN0b3J5 LmRiIixPX1JET05MWSwwMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjIy OiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAy MjI6IGdldHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiB3cml0ZSgyLCIyMDEwLTEwLTA0 IDA3OjA2OjU4IDIyMiAzNDQwNTkwNiIuLi4sMTE3KSA9IDExNyAoMHg3NSkKICAyMjI6IGNsb2Nr X2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogZ2V0 cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIsIjIwMTAtMTAtMDQgMDc6MDY6 NTggMjIyIDM0NDA1OTA2Ii4uLiwxMTkpID0gMTE5ICgweDc3KQogIDIyMjogY2xvY2tfZ2V0dGlt ZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgweDApCiAgMjIyOiBnZXRwaWQoKQkJ CQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAxMC0xMC0wNCAwNzowNjo1OCAyMjIg MzQ0MDU5MDQiLi4uLDEzOSkgPSAxMzkgKDB4OGIpCiAgMjIyOiBzaWdwcm9jbWFzayhTSUdfQkxP Q0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0FCUlR8U0lHRU1UfFNJR0tJTEx8U0lHU1lTfFNJ R1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdD SExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BS T0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMjI6 IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjIyOiBtbWFw KDB4N2ZmZmZmN2ZkMDAwLDIxMDEyNDgsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1NUQUNLLC0x LDB4MCkgPSAxNDA3Mzc0Nzk5NTQ0MzIgKDB4N2ZmZmZmN2ZkMDAwKQogIDIyMjogbXByb3RlY3Qo MHg3ZmZmZmY3ZmQwMDAsNDA5NixQUk9UX05PTkUpCSA9IDAgKDB4MCkKICAyMjI6IHRocl9uZXco MHg3ZmZmZmZmZmUyZjAsMHg2OCwweDgwMWM4MTk0MCwweDE4ODFjLDB4ZmZmZmZmZmYsMHgwKSA9 IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FV SVR8U0lHQUJSVHxTSUdFTVR8U0lHS0lMTHxTSUdTWVN8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18 U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJ R0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJ R1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIyMjogX3VtdHhfb3AoMHg4MDFjODE0ODAs MHhkLDB4MCwweDAsMHgwLDB4MSkgPSA0NTQgKDB4MWM2KQotLSBVTktOT1dOIFNZU0NBTEwgMjk4 ODk2NjQgLS0KICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgw eDApCi0tIFVOS05PV04gU1lTQ0FMTCAtNjMwMDA4MCAtLQogIDIyMjogbW1hcCgweDdmZmZmZjVm YzAwMCwyMTAxMjQ4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9TVEFDSywtMSwweDApID0gMTQw NzM3NDc3ODUzMTg0ICgweDdmZmZmZjVmYzAwMCkKICAyMjI6IG1wcm90ZWN0KDB4N2ZmZmZmNWZj MDAwLDQwOTYsUFJPVF9OT05FKQkgPSAwICgweDApCiAgMjIyOiB0aHJfbmV3KDB4N2ZmZmZmZmZl MmIwLDB4NjgsMHg4MDFjODE5NDAsMHgxODgxYywweGZmZmZmZmZmLDB4MCkgPSAwICgweDApCiAg MjIyOiBtbWFwKDB4MCw0MTk0MzA0LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1B UF9BTk9OLC0xLDB4MCkgPSAzNDQxMDA3MDAxNiAoMHg4MDMwMDAwMDApCiAgMjIyOiBtbWFwKDB4 MCw4Mzg4NjA4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9OLC0xLDB4 MCkgPSAzNDQxNDI2NDMyMCAoMHg4MDM0MDAwMDApCiAgMjIyOiBtdW5tYXAoMHg4MDM4MDAwMDAs NDE5NDMwNCkJCSA9IDAgKDB4MCkKICAyMjI6IG9wZW4oIi91c3IvaG9tZS9nY29vcGVyLy5tb3pj L3VzZXJfZGljdGlvbmFyeS5kYiIsT19SRE9OTFksMDY2NikgRVJSIzIgJ05vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnknCiAgMjIyOiBjbG9ja19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAw MCB9KSA9IDAgKDB4MCkKICAyMjI6IGdldHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiB3 cml0ZSgyLCIyMDEwLTEwLTA0IDA3OjA2OjU4IDIyMiAzNDQwNTkwNyIuLi4sMTUxKSA9IDE1MSAo MHg5NykKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0g MCAoMHgwKQogIDIyMjogZ2V0cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIs IjIwMTAtMTAtMDQgMDc6MDY6NTggMjIyIDM0NDA1OTA3Ii4uLiwxNDIpID0gMTQyICgweDhlKQog IDIyMjogbWFkdmlzZSgweDgwMzAyNDAwMCwweDEwMDAsMHg1LDB4MjMsMHgxMDA4LDB4MmQpID0g MCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgwMzAyMzAwMCwweDEwMDAsMHg1LDB4MjIsMHgyMDA4 LDB4N2ZmZmZmN2ZjNDcwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDMwMjIwMDAsMHgx MDAwLDB4NSwweDIxLDB4MzAwOCwweDdmZmZmZjdmYzQ3MCkgPSAwICgweDApCiAgMjIyOiBtYWR2 aXNlKDB4ODAzMDIxMDAwLDB4MTAwMCwweDUsMHgyMCwweDQwMDgsMHg3ZmZmZmY3ZmM0NzApID0g MCAoMHgwKQogIDIyMjogbWFkdmlzZSgweDgwMzAyNjAwMCwweDEwMDAsMHg1LDB4MjUsMHgxLDB4 N2ZmZmZmN2ZjNDcwKSA9IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDMwMjUwMDAsMHgxMDAw LDB4NSwweDI0LDB4N2ZmZmZmN2ZjNDYwLDB4N2ZmZmZmN2ZjNDYwKSA9IDAgKDB4MCkKICAyMjI6 IG1hZHZpc2UoMHg4MDMwMGYwMDAsMHgxMDAwLDB4NSwweGUsMHgxLDB4N2ZmZmZmN2ZjNDcwKSA9 IDAgKDB4MCkKICAyMjI6IG1hZHZpc2UoMHg4MDMwMGUwMDAsMHgxMDAwLDB4NSwweGQsMHgxMDAw OCwweDdmZmZmZjdmYzQzMCkgPSAwICgweDApCiAgMjIyOiBtYWR2aXNlKDB4ODAzMDA3MDAwLDB4 MTAwMCwweDUsMHg2LDB4MTcwMDgsMHg3ZmZmZmY3ZmM0YzApID0gMCAoMHgwKQogIDIyMjogdGhy X2V4aXQoMHg4MDJjMDdjNDAsMHgyLDB4MCwweDE4YTBhLDB4N2ZmZmZmN2ZjNGMwLDB4N2ZmZmZm N2ZjNGMwKSA9IDQzMSAoMHgxYWYpCiAgMjIyOiBvcGVuKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96 Yy8ucmVnaXN0cnkuZGIiLE9fUkRPTkxZLDAwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeScKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0g MCAoMHgwKQogIDIyMjogZ2V0cGlkKCkJCQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIs IjIwMTAtMTAtMDQgMDc6MDY6NTggMjIyIDM0NDA1OTA0Ii4uLiwxMTgpID0gMTE4ICgweDc2KQog IDIyMjogY2xvY2tfZ2V0dGltZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgweDAp CiAgMjIyOiBnZXRwaWQoKQkJCQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAxMC0x MC0wNCAwNzowNjo1OCAyMjIgMzQ0MDU5MDQiLi4uLDEyNykgPSAxMjcgKDB4N2YpCiAgMjIyOiBz aWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0FCUlR8U0lHRU1U fFNJR0tJTEx8U0lHU1lTfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJ R1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hG U1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgw KSA9IDAgKDB4MCkKICAyMjI6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAw ICgweDApCiAgMjIyOiBtbWFwKDB4N2ZmZmZmM2ZiMDAwLDIxMDEyNDgsUFJPVF9SRUFEfFBST1Rf V1JJVEUsTUFQX1NUQUNLLC0xLDB4MCkgPSAxNDA3Mzc0NzU3NTE5MzYgKDB4N2ZmZmZmM2ZiMDAw KQogIDIyMjogbXByb3RlY3QoMHg3ZmZmZmYzZmIwMDAsNDA5NixQUk9UX05PTkUpCSA9IDAgKDB4 MCkKICAyMjI6IHRocl9uZXcoMHg3ZmZmZmZmZmU2NzAsMHg2OCwweDgwMWM4MTk0MCwweDE4ODFj LDB4ZmZmZmZmZmYsMHgwKSA9IDAgKDB4MCkKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYy MDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogc2lncHJvY21hc2soU0lHX0JMT0NL LFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdBQlJUfFNJR0VNVHxTSUdLSUxMfFNJR1NZU3xTSUdQ SVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hM RHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9G fFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjIyOiBz aWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjogbW1hcCgw eDdmZmZmZjFmYTAwMCwyMTAxMjQ4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9TVEFDSywtMSww eDApID0gMTQwNzM3NDczNjUwNjg4ICgweDdmZmZmZjFmYTAwMCkKICAyMjI6IG1tYXAoMHgwLDQx OTQzMDQsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0FOT04sLTEsMHgwKSA9 IDM0NDE4NDU4NjI0ICgweDgwMzgwMDAwMCkKICAyMjI6IG1wcm90ZWN0KDB4N2ZmZmZmMWZhMDAw LDQwOTYsUFJPVF9OT05FKQkgPSAwICgweDApCiAgMjIyOiB0aHJfbmV3KDB4N2ZmZmZmZmZlMzEw LDB4NjgsMHg4MDFjODE5NDAsMHgxODgxYywweGZmZmZmZmZmLDB4MCkgPSAwICgweDApCiAgMjIy OiBnZXRldWlkKCkJCQkJID0gMTAwMCAoMHgzZTgpCiAgMjIyOiBzdGF0KCIvZXRjL25zc3dpdGNo LmNvbmYiLHsgbW9kZT0tcnctci0tci0tICxpbm9kZT0xNDEzNTksc2l6ZT0yNTUsYmxrc2l6ZT0x NjM4NCB9KSA9IDAgKDB4MCkKLS0gVU5LTk9XTiBTWVNDQUxMIC0xMjYwMzg1NiAtLQogIDIyMjog Z2V0ZXVpZCgpCQkJCSA9IDEwMDAgKDB4M2U4KQogIDIyMjogb3BlbigiL2V0Yy9wd2QuZGIiLE9f UkRPTkxZLDAwKQkJID0gNiAoMHg2KQogIDIyMjogZmNudGwoNixGX1NFVEZELEZEX0NMT0VYRUMp CQkgPSAwICgweDApCiAgMjIyOiBmc3RhdCg2LHsgbW9kZT0tcnctci0tci0tICxpbm9kZT0xNDE1 Mzcsc2l6ZT00MDk2MCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIyMjogcmVhZCg2LCJc MFxeRlxeVWFcMFwwXDBcXkJcMFwwXF5EXE0tUlwwIi4uLiwyNjApID0gMjYwICgweDEwNCkKICAy MjI6IHByZWFkKDB4NiwweDgwMzU4YjAwMCwweDEwMDAsMHg2MDAwLDB4MSwweDApID0gNDA5NiAo MHgxMDAwKQogIDIyMjogcHJlYWQoMHg2LDB4ODAzNThjMDAwLDB4MTAwMCwweDQwMDAsMHgxLDB4 MCkgPSA0MDk2ICgweDEwMDApCiAgMjIyOiBwcmVhZCgweDYsMHg4MDM1OGQwMDAsMHgxMDAwLDB4 NTAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMjI6IHByZWFkKDB4NiwweDgwMzU4ZTAw MCwweDEwMDAsMHg3MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQogIDIyMjogcHJlYWQoMHg2 LDB4ODAzNThmMDAwLDB4MTAwMCwweDgwMDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCiAgMjIy OiBwcmVhZCgweDYsMHg4MDM1OTAwMDAsMHgxMDAwLDB4MTAwMCwweDEsMHgwKSA9IDQwOTYgKDB4 MTAwMCkKICAyMjI6IHByZWFkKDB4NiwweDgwMzU5MTAwMCwweDEwMDAsMHgyMDAwLDB4MSwweDAp ID0gNDA5NiAoMHgxMDAwKQogIDIyMjogcHJlYWQoMHg2LDB4ODAzNTkyMDAwLDB4MTAwMCwweDMw MDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCiAgMjIyOiBjbG9zZSg2KQkJCQkJID0gMCAoMHgw KQogIDIyMjogb3BlbigiL3RtcC9TRU1EYzkxYzAwOTI2OTk4IixPX1JEV1IsMDApCSBFUlIjMiAn Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IGNsb2NrX2dldHRpbWUoMTMsezEyODYy MDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogZ2V0dGltZW9mZGF5KHsxMjg2MjAx MjE4Ljc4MzE1MSB9LDB4MCkJID0gMCAoMHgwKQogIDIyMjogY2xvY2tfZ2V0dGltZSgwLHsxMjg2 MjAxMjE4Ljc4MzE5MTI2NiB9KQkgPSAwICgweDApCiAgMjIyOiBzdGF0KCIvdXNyL3NoYXJlL25s cy9DL2xpYmMuY2F0IiwweDdmZmZmZmZmZTFmMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjIyOiBzdGF0KCIvdXNyL3NoYXJlL25scy9saWJjL0MiLDB4N2ZmZmZmZmZlMWYw KSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IHN0YXQoIi91c3IvbG9j YWwvc2hhcmUvbmxzL0MvbGliYy5jYXQiLDB4N2ZmZmZmZmZlMWYwKSBFUlIjMiAnTm8gc3VjaCBm aWxlIG9yIGRpcmVjdG9yeScKICAyMjI6IHN0YXQoIi91c3IvbG9jYWwvc2hhcmUvbmxzL2xpYmMv QyIsMHg3ZmZmZmZmZmUxZjApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIy MjogY2xvY2tfZ2V0dGltZSgxMyx7MTI4NjIwMTIxOC4wMDAwMDAwMDAgfSkgPSAwICgweDApCiAg MjIyOiBnZXRwaWQoKQkJCQkJID0gMjIyICgweGRlKQogIDIyMjogd3JpdGUoMiwiMjAxMC0xMC0w NCAwNzowNjo1OCAyMjIgMzQ0MDU5MDQiLi4uLDExNCkgPSAxMTQgKDB4NzIpCiAgMjIyOiBjbG9j a19nZXR0aW1lKDEzLHsxMjg2MjAxMjE4LjAwMDAwMDAwMCB9KSA9IDAgKDB4MCkKICAyMjI6IGdl dHBpZCgpCQkJCQkgPSAyMjIgKDB4ZGUpCiAgMjIyOiB3cml0ZSgyLCIyMDEwLTEwLTA0IDA3OjA2 OjU4IDIyMiAzNDQwNTkwNCIuLi4sMTA3KSA9IDEwNyAoMHg2YikKICAyMjI6IGNsb2NrX2dldHRp bWUoMTMsezEyODYyMDEyMTguMDAwMDAwMDAwIH0pID0gMCAoMHgwKQogIDIyMjogZ2V0cGlkKCkJ CQkJCSA9IDIyMiAoMHhkZSkKICAyMjI6IHdyaXRlKDIsIjIwMTAtMTAtMDQgMDc6MDY6NTggMjIy IDM0NDA1OTA0Ii4uLiwxMTEpID0gMTExICgweDZmKQogIDIyMjogc2lncHJvY21hc2soU0lHX0JM T0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdBQlJUfFNJR0VNVHxTSUdLSUxMfFNJR1NZU3xT SUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lH Q0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQ Uk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjIy OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIyMjogbW1h cCgweDdmZmZmZWZmOTAwMCwyMTAxMjQ4LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9TVEFDSywt MSwweDApID0gMTQwNzM3NDcxNTQ5NDQwICgweDdmZmZmZWZmOTAwMCkKICAyMjI6IG1wcm90ZWN0 KDB4N2ZmZmZlZmY5MDAwLDQwOTYsUFJPVF9OT05FKQkgPSAwICgweDApCiAgMjIyOiB0aHJfbmV3 KDB4N2ZmZmZmZmZlNmQwLDB4NjgsMHg4MDFjODE5NDAsMHgxODgxYywweGZmZmZmZmZmLDB4MCkg PSAwICgweDApCl5DXkMgIDIyMjogYWNjZXB0KDQsMHgwLDB4MCkJCQkgRVJSIzQgJ0ludGVycnVw dGVkIHN5c3RlbSBjYWxsJwogIDIyMjogU0lHTkFMIDE1IChTSUdURVJNKQogIDIyMjogcHJvY2Vz cyBleGl0LCBydmFsID0gMApbZ2Nvb3BlckBiYXlvbmV0dGEgL3Vzci9wb3J0cy9qYXBhbmVzZS9t b3pjLXNlcnZlcl0kIHRydXNzIC1mZiBtb3pjX3NlcnZlcgogIDIzMDogX19zeXNjdGwoMHg3ZmZm ZmZmZmUyZjAsMHgyLDB4N2ZmZmZmZmZlMzBjLDB4N2ZmZmZmZmZlMzAwLDB4MCwweDApID0gMCAo MHgwKQogIDIzMDogbW1hcCgweDAsMzI3NjgsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZB VEV8TUFQX0FOT04sLTEsMHgwKSA9IDM0MzgzMjc4MDgwICgweDgwMTY3MzAwMCkKICAyMzA6IGlz c2V0dWdpZCgweDgwMTY3NDAxNSwweDgwMTY2ZThlNCwweDdmZmZmZmZmZTk5OCwweDgwMTc4YTA0 MCwweDU3MzEsMHgwKSA9IDAgKDB4MCkKICAyMzA6IG9wZW4oIi9ldGMvbGlibWFwLmNvbmYiLE9f UkRPTkxZLDA2NjYpCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IG9w ZW4oIi92YXIvcnVuL2xkLWVsZi5zby5oaW50cyIsT19SRE9OTFksMDU3KSA9IDIgKDB4MikKICAy MzA6IHJlYWQoMiwiRWhudFxeQVwwXDBcMFxNXkBcMFwwXDBcTV5aXDBcMCIuLi4sMTI4KSA9IDEy OCAoMHg4MCkKICAyMzA6IGxzZWVrKDIsMHg4MCxTRUVLX1NFVCkJCQkgPSAxMjggKDB4ODApCiAg MjMwOiByZWFkKDIsIi9saWI6L3Vzci9saWI6L3Vzci9saWIvY29tcGF0Oi91Ii4uLiwxNTQpID0g MTU0ICgweDlhKQogIDIzMDogY2xvc2UoMikJCQkJCSA9IDAgKDB4MCkKICAyMzA6IGFjY2Vzcygi L2xpYi9saWJjdXJsLnNvLjYiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnkn CiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL2xpYmN1cmwuc28uNiIsMCkJIEVSUiMyICdObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xpYi9jb21wYXQvbGliY3Vy bC5zby42IiwwKQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nl c3MoIi91c3IvbG9jYWwvbGliL2xpYmN1cmwuc28uNiIsMCkJID0gMCAoMHgwKQogIDIzMDogb3Bl bigiL3Vzci9sb2NhbC9saWIvbGliY3VybC5zby42IixPX1JET05MWSwwMTM1NzUzNzQwKSA9IDIg KDB4MikKICAyMzA6IGZzdGF0KDIseyBtb2RlPS1yd3hyLXhyLXggLGlub2RlPTI4MjYzOTcsc2l6 ZT0zNTQzNzMsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMzA6IHByZWFkKDB4MiwweDgw MTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkg PSA0MDk2ICgweDEwMDApCiAgMjMwOiBtbWFwKDB4MCwxMzU5ODcyLFBST1RfTk9ORSxNQVBfUFJJ VkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM4NDQyNDk2MCAoMHg4MDE3OGIw MDApCiAgMjMwOiBtbWFwKDB4ODAxNzhiMDAwLDI4MjYyNCxQUk9UX1JFQUR8UFJPVF9FWEVDLE1B UF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfTk9DT1JFLDIsMHgwKSA9IDM0Mzg0NDI0OTYwICgweDgw MTc4YjAwMCkKICAyMzA6IG1tYXAoMHg4MDE4ZDAwMDAsMjg2NzIsUFJPVF9SRUFEfFBST1RfV1JJ VEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHg0NTAwMCkgPSAzNDM4NTc1NjE2MCAoMHg4MDE4 ZDAwMDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogYWNjZXNzKCIvbGli L2xpYmNyeXB0by5zby42IiwwKQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2xpYi9saWJjcnlw dG8uc28uNiIsT19SRE9OTFksMDEzNTc1Mzc0MCkgPSAyICgweDIpCiAgMjMwOiBmc3RhdCgyLHsg bW9kZT0tci0tci0tci0tICxpbm9kZT00MDA0NDgsc2l6ZT0xNjY5MDg4LGJsa3NpemU9MTYzODQg fSkgPSAwICgweDApCiAgMjMwOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEw MTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIzMDog bW1hcCgweDAsMjcwNzQ1NixQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09S RSwtMSwweDApID0gMzQzODU3ODQ4MzIgKDB4ODAxOGQ3MDAwKQogIDIzMDogbW1hcCgweDgwMThk NzAwMCwxMzU5ODcyLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1B UF9OT0NPUkUsMiwweDApID0gMzQzODU3ODQ4MzIgKDB4ODAxOGQ3MDAwKQogIDIzMDogbW1hcCgw eDgwMWIyMzAwMCwyOTA4MTYsUFJPVF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJ WEVELDIsMHgxNGMwMDApID0gMzQzODgxOTMyODAgKDB4ODAxYjIzMDAwKQogIDIzMDogbXByb3Rl Y3QoMHg4MDFiNmEwMDAsODE5MixQUk9UX1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCiAgMjMw OiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogYWNjZXNzKCIvbGliL2xpYnRoci5zby4z IiwwKQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2xpYi9saWJ0aHIuc28uMyIsT19SRE9OTFks MDEzNTc1Mzc0MCkgPSAyICgweDIpCiAgMjMwOiBmc3RhdCgyLHsgbW9kZT0tci0tci0tci0tICxp bm9kZT00MDA0MjYsc2l6ZT04Nzk1MixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDog cHJlYWQoMHgyLDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgw ODA4MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMzA6IG1tYXAoMHgwLDExNDI3ODQsUFJP VF9OT05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzg4NDky Mjg4ICgweDgwMWI2YzAwMCkKICAyMzA6IG1tYXAoMHg4MDFiNmMwMDAsNzM3MjgsUFJPVF9SRUFE fFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM4 ODQ5MjI4OCAoMHg4MDFiNmMwMDApCiAgMjMwOiBtbWFwKDB4ODAxYzdkMDAwLDE2Mzg0LFBST1Rf UkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MTEwMDApID0gMzQzODk2 MTA0OTYgKDB4ODAxYzdkMDAwKQogIDIzMDogbXByb3RlY3QoMHg4MDFjODEwMDAsODE5MixQUk9U X1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgw KQogIDIzMDogYWNjZXNzKCIvbGliL2xpYnJ0LnNvLjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL2xpYnJ0LnNvLjEiLDApCQkg PSAwICgweDApCiAgMjMwOiBvcGVuKCIvdXNyL2xpYi9saWJydC5zby4xIixPX1JET05MWSwwMTM1 NzUzNzQwKSA9IDIgKDB4MikKICAyMzA6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2Rl PTI1Njc5MDMsc2l6ZT0yMTc0NCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDogcHJl YWQoMHgyLDB4ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgwODA4 MDgwODA4MDgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMzA6IG1tYXAoMHgwLDEwNjkwNTYsUFJPVF9O T05FLE1BUF9QUklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0Mzg5NjM1MDcy ICgweDgwMWM4MzAwMCkKICAyMzA6IG1tYXAoMHg4MDFjODMwMDAsMjA0ODAsUFJPVF9SRUFEfFBS T1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM4OTYz NTA3MiAoMHg4MDFjODMwMDApCiAgMjMwOiBtbWFwKDB4ODAxZDg3MDAwLDQwOTYsUFJPVF9SRUFE fFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHg0MDAwKSA9IDM0MzkwNzAwMDMy ICgweDgwMWQ4NzAwMCkKICAyMzA6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjMwOiBhY2Nl c3MoIi9saWIvbGlic3NsLnNvLjYiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL2xpYnNzbC5zby42IiwwKQkJID0gMCAoMHgwKQog IDIzMDogb3BlbigiL3Vzci9saWIvbGlic3NsLnNvLjYiLE9fUkRPTkxZLDAxMzU3NTM3NDApID0g MiAoMHgyKQogIDIzMDogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAsaW5vZGU9MjU2NzE5Mixz aXplPTMzNDE1MixibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDogcHJlYWQoMHgyLDB4 ODAxNzdjN2MwLDB4MTAwMCwweDAsMHgxMDEwMTAxMDEwMTAxMDEsMHg4MDgwODA4MDgwODA4MDgw KSA9IDQwOTYgKDB4MTAwMCkKICAyMzA6IG1tYXAoMHgwLDEzODAzNTIsUFJPVF9OT05FLE1BUF9Q UklWQVRFfE1BUF9BTk9OfE1BUF9OT0NPUkUsLTEsMHgwKSA9IDM0MzkwNzA0MTI4ICgweDgwMWQ4 ODAwMCkKICAyMzA6IG1tYXAoMHg4MDFkODgwMDAsMjg2NzIwLFBST1RfUkVBRHxQUk9UX0VYRUMs TUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTA3MDQxMjggKDB4 ODAxZDg4MDAwKQogIDIzMDogbW1hcCgweDgwMWVjZTAwMCw0NTA1NixQUk9UX1JFQUR8UFJPVF9X UklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweDQ2MDAwKSA9IDM0MzkyMDM5NDI0ICgweDgw MWVjZTAwMCkKICAyMzA6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjMwOiBhY2Nlc3MoIi9s aWIvbGliei5zby42IiwwKQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2xpYi9saWJ6LnNvLjYi LE9fUkRPTkxZLDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIzMDogZnN0YXQoMix7IG1vZGU9LXIt LXItLXItLSAsaW5vZGU9NDAwNDMwLHNpemU9ODk1MjgsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4 MCkKICAyMzA6IHByZWFkKDB4MiwweDgwMTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEw MTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgweDEwMDApCiAgMjMwOiBtbWFwKDB4MCwx MTM4Njg4LFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkg PSAzNDM5MjA4NDQ4MCAoMHg4MDFlZDkwMDApCiAgMjMwOiBtbWFwKDB4ODAxZWQ5MDAwLDgxOTIw LFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9OT0NPUkUsMiww eDApID0gMzQzOTIwODQ0ODAgKDB4ODAxZWQ5MDAwKQogIDIzMDogbW1hcCgweDgwMWZlZDAwMCw4 MTkyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9GSVhFRCwyLDB4MTQwMDAp ID0gMzQzOTMyMTQ5NzYgKDB4ODAxZmVkMDAwKQogIDIzMDogY2xvc2UoMikJCQkJCSA9IDAgKDB4 MCkKICAyMzA6IGFjY2VzcygiL2xpYi9saWJwcm90b2J1Zi5zby42IiwwKQkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL2xpYnByb3RvYnVm LnNvLjYiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2Vz cygiL3Vzci9saWIvY29tcGF0L2xpYnByb3RvYnVmLnNvLjYiLDApIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9saWJwcm90b2J1 Zi5zby42IiwwKSA9IDAgKDB4MCkKICAyMzA6IG9wZW4oIi91c3IvbG9jYWwvbGliL2xpYnByb3Rv YnVmLnNvLjYiLE9fUkRPTkxZLDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIzMDogZnN0YXQoMix7 IG1vZGU9LXJ3eHIteHIteCAsaW5vZGU9MjgyNzc4NCxzaXplPTE0MTMyODUsYmxrc2l6ZT0xNjM4 NCB9KSA9IDAgKDB4MCkKICAyMzA6IHByZWFkKDB4MiwweDgwMTc3YzdjMCwweDEwMDAsMHgwLDB4 MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgweDEwMDApCiAgMjMw OiBtbWFwKDB4MCwyMTgzMTY4LFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBfQU5PTnxNQVBfTk9D T1JFLC0xLDB4MCkgPSAzNDM5MzIyMzE2OCAoMHg4MDFmZWYwMDApCiAgMjMwOiBtbWFwKDB4ODAx ZmVmMDAwLDk5NTMyOCxQUk9UX1JFQUR8UFJPVF9FWEVDLE1BUF9QUklWQVRFfE1BUF9GSVhFRHxN QVBfTk9DT1JFLDIsMHgwKSA9IDM0MzkzMjIzMTY4ICgweDgwMWZlZjAwMCkKICAyMzA6IG1tYXAo MHg4MDIxZTEwMDAsMTQzMzYwLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9G SVhFRCwyLDB4ZjIwMDApID0gMzQzOTUyNjI5NzYgKDB4ODAyMWUxMDAwKQogIDIzMDogY2xvc2Uo MikJCQkJCSA9IDAgKDB4MCkKICAyMzA6IGFjY2VzcygiL2xpYi9saWJzdGRjKysuc28uNiIsMCkJ CSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9s aWIvbGlic3RkYysrLnNvLjYiLDApCSA9IDAgKDB4MCkKICAyMzA6IG9wZW4oIi91c3IvbGliL2xp YnN0ZGMrKy5zby42IixPX1JET05MWSwwMTM1NzUzNzQwKSA9IDIgKDB4MikKICAyMzA6IGZzdGF0 KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTI1NjgwMTAsc2l6ZT0xMDE4NTg0LGJsa3NpemU9 MTYzODQgfSkgPSAwICgweDApCiAgMjMwOiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4 MCwweDEwMTAxMDEwMTAxMDEwMSwweDgwODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQog IDIzMDogbW1hcCgweDAsMjE0MjIwOCxQUk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQ X05PQ09SRSwtMSwweDApID0gMzQzOTU0MDYzMzYgKDB4ODAyMjA0MDAwKQogIDIzMDogbW1hcCgw eDgwMjIwNDAwMCw4NzY1NDQsUFJPVF9SRUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklY RUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM5NTQwNjMzNiAoMHg4MDIyMDQwMDApCiAgMjMwOiBt bWFwKDB4ODAyM2Q5MDAwLDE0MzM2MCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxN QVBfRklYRUQsMiwweGQ1MDAwKSA9IDM0Mzk3MzI3MzYwICgweDgwMjNkOTAwMCkKICAyMzA6IG1w cm90ZWN0KDB4ODAyM2ZjMDAwLDc3ODI0LFBST1RfUkVBRHxQUk9UX1dSSVRFKSA9IDAgKDB4MCkK ICAyMzA6IGNsb3NlKDIpCQkJCQkgPSAwICgweDApCiAgMjMwOiBhY2Nlc3MoIi9saWIvbGlibS5z by41IiwwKQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2xpYi9saWJtLnNvLjUiLE9fUkRPTkxZ LDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIzMDogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAs aW5vZGU9NDAwMzkxLHNpemU9MTM2NzQ0LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDApCiAgMjMw OiBwcmVhZCgweDIsMHg4MDE3N2M3YzAsMHgxMDAwLDB4MCwweDEwMTAxMDEwMTAxMDEwMSwweDgw ODA4MDgwODA4MDgwODApID0gNDA5NiAoMHgxMDAwKQogIDIzMDogbW1hcCgweDAsMTE3NTU1MixQ Uk9UX05PTkUsTUFQX1BSSVZBVEV8TUFQX0FOT058TUFQX05PQ09SRSwtMSwweDApID0gMzQzOTc1 NDg1NDQgKDB4ODAyNDBmMDAwKQogIDIzMDogbW1hcCgweDgwMjQwZjAwMCwxMjI4ODAsUFJPVF9S RUFEfFBST1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAz NDM5NzU0ODU0NCAoMHg4MDI0MGYwMDApCiAgMjMwOiBtbWFwKDB4ODAyNTJjMDAwLDgxOTIsUFJP VF9SRUFEfFBST1RfV1JJVEUsTUFQX1BSSVZBVEV8TUFQX0ZJWEVELDIsMHgxZDAwMCkgPSAzNDM5 ODcxNTkwNCAoMHg4MDI1MmMwMDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIz MDogYWNjZXNzKCIvbGliL2xpYmdjY19zLnNvLjEiLDApCQkgPSAwICgweDApCiAgMjMwOiBvcGVu KCIvbGliL2xpYmdjY19zLnNvLjEiLE9fUkRPTkxZLDAxMzU3NTM3NDApID0gMiAoMHgyKQogIDIz MDogZnN0YXQoMix7IG1vZGU9LXItLXItLXItLSAsaW5vZGU9NDAwNDQ0LHNpemU9NTYxOTIsYmxr c2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMzA6IHByZWFkKDB4MiwweDgwMTc3YzdjMCwweDEw MDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4MDgwODA4MCkgPSA0MDk2ICgweDEw MDApCiAgMjMwOiBtbWFwKDB4MCwxMTAxODI0LFBST1RfTk9ORSxNQVBfUFJJVkFURXxNQVBfQU5P TnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM5ODcyNDA5NiAoMHg4MDI1MmUwMDApCiAgMjMwOiBt bWFwKDB4ODAyNTJlMDAwLDQ5MTUyLFBST1RfUkVBRHxQUk9UX0VYRUMsTUFQX1BSSVZBVEV8TUFQ X0ZJWEVEfE1BUF9OT0NPUkUsMiwweDApID0gMzQzOTg3MjQwOTYgKDB4ODAyNTJlMDAwKQogIDIz MDogbW1hcCgweDgwMjYzOTAwMCw4MTkyLFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRF fE1BUF9GSVhFRCwyLDB4YjAwMCkgPSAzNDM5OTgxNzcyOCAoMHg4MDI2MzkwMDApCiAgMjMwOiBj bG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogYWNjZXNzKCIvbGliL2xpYmMuc28uNyIsMCkJ CSA9IDAgKDB4MCkKICAyMzA6IG9wZW4oIi9saWIvbGliYy5zby43IixPX1JET05MWSwwMTM1NzUz NzQwKSA9IDIgKDB4MikKICAyMzA6IGZzdGF0KDIseyBtb2RlPS1yLS1yLS1yLS0gLGlub2RlPTQw MDM4OCxzaXplPTExODAwMDgsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMzA6IHByZWFk KDB4MiwweDgwMTc3YzdjMCwweDEwMDAsMHgwLDB4MTAxMDEwMTAxMDEwMTAxLDB4ODA4MDgwODA4 MDgwODA4MCkgPSA0MDk2ICgweDEwMDApCiAgMjMwOiBtbWFwKDB4MCwyMzA2MDQ4LFBST1RfTk9O RSxNQVBfUFJJVkFURXxNQVBfQU5PTnxNQVBfTk9DT1JFLC0xLDB4MCkgPSAzNDM5OTgyNTkyMCAo MHg4MDI2M2IwMDApCiAgMjMwOiBtbWFwKDB4ODAyNjNiMDAwLDEwMTU4MDgsUFJPVF9SRUFEfFBS T1RfRVhFQyxNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX05PQ09SRSwyLDB4MCkgPSAzNDM5OTgy NTkyMCAoMHg4MDI2M2IwMDApCiAgMjMwOiBtbWFwKDB4ODAyODMzMDAwLDEzMTA3MixQUk9UX1JF QUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfRklYRUQsMiwweGY4MDAwKSA9IDM0NDAxODkw MzA0ICgweDgwMjgzMzAwMCkKICAyMzA6IG1wcm90ZWN0KDB4ODAyODUzMDAwLDExMDU5MixQUk9U X1JFQUR8UFJPVF9XUklURSkgPSAwICgweDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgw KQogIDIzMDogc3lzYXJjaCgweDgxLDB4N2ZmZmZmZmZlNDAwLDB4ODAxNjc4NjA4LDB4MCwweGZm ZmZmZmZmZmVlM2JlZDAsMHg4MDgwODA4MDgwODA4MDgwKSA9IDAgKDB4MCkKICAyMzA6IG1tYXAo MHgwLDQ1MDU2LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9OLC0xLDB4 MCkgPSAzNDM4MzMxMDg0OCAoMHg4MDE2N2IwMDApCiAgMjMwOiBtdW5tYXAoMHg4MDE2N2YwMDAs Mjg2NzIpCQkgPSAwICgweDApCiAgMjMwOiBtbWFwKDB4MCwxMDI0MDAsUFJPVF9SRUFEfFBST1Rf V1JJVEUsTUFQX1BSSVZBVEV8TUFQX0FOT04sLTEsMHgwKSA9IDM0MzgzMzI3MjMyICgweDgwMTY3 ZjAwMCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8 U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJ R0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZU QUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgw eDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQog IDIzMDogX19zeXNjdGwoMHg3ZmZmZmZmZmUzOTAsMHgyLDB4ODAyODU5MzIwLDB4N2ZmZmZmZmZl Mzg4LDB4MCwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hV UHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xT SUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdY Q1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJ R1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCww eDApCQkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lO VHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8 U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lH WEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiww eDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9 IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FV SVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQ fFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJ R1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAw ICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgw KQogIDIzMDogZ2V0cGlkKCkJCQkJCSA9IDIzMCAoMHhlNikKICAyMzA6IF9fc3lzY3RsKDB4N2Zm ZmZmZmZlMzUwLDB4MiwweDgwMWM4MmU3MCwweDdmZmZmZmZmZTM1OCwweDAsMHgwKSA9IDAgKDB4 MCkKICAyMzA6IF9fc3lzY3RsKDB4N2ZmZmZmZmZlMjcwLDB4MiwweDdmZmZmZmZmZTI5MCwweDdm ZmZmZmZmZTJmOCwweDgwMWI3Y2ZkOCwweGQpID0gMCAoMHgwKQogIDIzMDogX19zeXNjdGwoMHg3 ZmZmZmZmZmUyOTAsMHgzLDB4ODAxYzgxZDY4LDB4N2ZmZmZmZmZlMzU4LDB4MCwweDApID0gMCAo MHgwKQogIDIzMDogX19zeXNjdGwoMHg3ZmZmZmZmZmRlMDAsMHgyLDB4N2ZmZmZmZmZkZTJjLDB4 N2ZmZmZmZmZkZTIwLDB4MCwweDApID0gMCAoMHgwKQogIDIzMDogX19zeXNjdGwoMHg3ZmZmZmZm ZmRjZjAsMHgyLDB4N2ZmZmZmZmZkZDEwLDB4N2ZmZmZmZmZkZDc4LDB4ODAyNzI2NTQwLDB4Yykg PSAwICgweDApCiAgMjMwOiBfX3N5c2N0bCgweDdmZmZmZmZmZGQxMCwweDIsMHg4MDI4NThkNzAs MHg3ZmZmZmZmZmRkYzAsMHgwLDB4MCkgPSAwICgweDApCiAgMjMwOiByZWFkbGluaygiL2V0Yy9t YWxsb2MuY29uZiIsMHg3ZmZmZmZmZmRlMzAsMTAyNCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBk aXJlY3RvcnknCiAgMjMwOiBpc3NldHVnaWQoMHg4MDI3MjUxNGYsMHg3ZmZmZmZmZmRlMzAsMHhm ZmZmZmZmZmZmZmZmZmZmLDB4MCwweDIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IGJyZWFrKDB4MTgw MDAwMCkJCQkJID0gMCAoMHgwKQogIDIzMDogX19zeXNjdGwoMHg3ZmZmZmZmZmRlNTAsMHgyLDB4 N2ZmZmZmZmZkZTZjLDB4N2ZmZmZmZmZkZTYwLDB4MCwweDApID0gMCAoMHgwKQogIDIzMDogbW1h cCgweDAsNDE5NDMwNCxQUk9UX1JFQUR8UFJPVF9XUklURSxNQVBfUFJJVkFURXxNQVBfQU5PTiwt MSwweDApID0gMzQ0MDIxMzE5NjggKDB4ODAyODZlMDAwKQogIDIzMDogbW1hcCgweDgwMmM2ZTAw MCwzNzQzNzQ0LFBST1RfUkVBRHxQUk9UX1dSSVRFLE1BUF9QUklWQVRFfE1BUF9BTk9OLC0xLDB4 MCkgPSAzNDQwNjMyNjI3MiAoMHg4MDJjNmUwMDApCiAgMjMwOiBtdW5tYXAoMHg4MDI4NmUwMDAs Mzc0Mzc0NCkJCSA9IDAgKDB4MCkKICAyMzA6IHRocl9zZWxmKDB4ODAyYzA3MWMwLDB4MCwweDAs MHgwLDB4MTg4LDB4MTczYWQ0MCkgPSAwICgweDApCiAgMjMwOiBtbWFwKDB4N2ZmZmZmYmZmMDAw LDQwOTYsUFJPVF9OT05FLE1BUF9BTk9OLC0xLDB4MCkgPSAxNDA3Mzc0ODQxNTY5MjggKDB4N2Zm ZmZmYmZmMDAwKQogIDIzMDogdGhyX3NldF9uYW1lKDB4MTg4YzcsMHg4MDFiN2QwMjAsMHgwLDB4 MTAwMCwweGZmZmZmZmZmLDB4MCkgPSAwICgweDApCiAgMjMwOiBydHByaW9fdGhyZWFkKDB4MCww eDE4OGM3LDB4N2ZmZmZmZmZlMzAwLDB4MTAwMCwweGZmZmZmZmZmLDB4MCkgPSAwICgweDApCiAg MjMwOiBzeXNhcmNoKDB4ODEsMHg3ZmZmZmZmZmUzMjAsMHg4MDFjODE5NDAsMHg4MDFjODFjYzgs MHhmZmZmZmZmZiwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ss U0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0lMTHxTSUdBQlJUfFNJR0VNVHxTSUdGUEV8U0lHS0lM THxTSUdCVVN8U0lHU0VHVnxTSUdTWVN8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJ R1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hD UFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lH VVNSMiwweDApID0gMCAoMHgwKQogIDIzMDogc2lnYWN0aW9uKDMyLHsgMHg4MDFiNzczNzUgU0Ff UkVTVEFSVHxTQV9TSUdJTkZPIHNzX3QgfSwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21h c2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJ R19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lH VEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RU T1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lO Rk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdf U0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NL LFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJ R1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJ T3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdV U1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNL LDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyYzBmMDAwLDB4MTAwMCww eDUsMHhlLDB4MjAwOCwweGIpID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMwZjAwMCww eDEwMDAsMHg1LDB4ZSwweDIwMDgsMHg3ZmZmZmZmZmQ3NDApID0gMCAoMHgwKQogIDIzMDogbWFk dmlzZSgweDgwMmMyMDAwMCwweDEwMDAsMHg1LDB4MWYsMHgyMDA4LDB4MTczYWQ0MCkgPSAwICgw eDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyYzI2MDAwLDB4MTAwMCwweDUsMHgyNSwweDUwMDgsMHg3 ZmZmZmZmZmQ1ODApID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMyMjAwMCwweDEwMDAs MHg1LDB4MjEsMHg1MDA4LDB4N2ZmZmZmZmZkNTgwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2Uo MHg4MDJjMWUwMDAsMHgxMDAwLDB4NSwweDFkLDB4MjAwOCwweDdmZmZmZmZmZDU4MCkgPSAwICgw eDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyYzE5MDAwLDB4MTAwMCwweDUsMHgxOCwweDEsMHg3ZmZm ZmZmZmQ1YTApID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMxODAwMCwweDEwMDAsMHg1 LDB4MTcsMHgxNzNhZTMwLDB4N2ZmZmZmZmZkNWUwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2Uo MHg4MDJjMjAwMDAsMHgxMDAwLDB4NSwweDFmLDB4ZjAwMCwweDdmZmZmZmZmZDYwMCkgPSAwICgw eDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyYzFhMDAwLDB4MTAwMCwweDUsMHgxOSwweDEwMDgsMHgx NzNhZDQwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lH SU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RP UHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxT SUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1Iy LDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJ ID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lH UVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RT VFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8 U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9 IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgw eDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJ R0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdD T05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFM Uk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgw KQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAy MzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxT SUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lH Q0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQ Uk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMw OiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2ln cHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8 U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJ R1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lH V0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3By b2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFz ayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJN fFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxT SUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxT SUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2so U0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2UoMHg4MDJjNDQw MDAsMHgxMDAwLDB4NSwweDQzLDB4MSwweDdmZmZmZmZmZGFhMCkgPSAwICgweDApCiAgMjMwOiBt YWR2aXNlKDB4ODAyYzNkMDAwLDB4MTAwMCwweDUsMHgzYywweDEsMHg3ZmZmZmZmZmRhYTApID0g MCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMzYzAwMCwweDEwMDAsMHg1LDB4M2IsMHgxNzNh ZTMwLDB4N2ZmZmZmZmZkYjcwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2UoMHg4MDJjMjUwMDAs MHgxMDAwLDB4NSwweDI0LDB4MTczYWUzMCwweDdmZmZmZmZmZGI3MCkgPSAwICgweDApCiAgMjMw OiBtYWR2aXNlKDB4ODAyYzI0MDAwLDB4MTAwMCwweDUsMHgyMywweDEsMHg3ZmZmZmZmZmRhZjAp ID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmMxYzAwMCwweDIwMDAsMHg1LDB4MWIsMHgx LDB4N2ZmZmZmZmZkYWYwKSA9IDAgKDB4MCkKICAyMzA6IGdldGV1aWQoKQkJCQkgPSAxMDAwICgw eDNlOCkKICAyMzA6IGdldHVpZCgpCQkJCQkgPSAxMDAwICgweDNlOCkKICAyMzA6IGdldGV1aWQo KQkJCQkgPSAxMDAwICgweDNlOCkKICAyMzA6IHN0YXQoIi9ldGMvbnNzd2l0Y2guY29uZiIseyBt b2RlPS1ydy1yLS1yLS0gLGlub2RlPTE0MTM1OSxzaXplPTI1NSxibGtzaXplPTE2Mzg0IH0pID0g MCAoMHgwKQogIDIzMDogb3BlbigiL2V0Yy9uc3N3aXRjaC5jb25mIixPX1JET05MWSwwNjY2KQkg PSAyICgweDIpCiAgMjMwOiBpb2N0bCgyLFRJT0NHRVRBLDB4ZmZmZmRkODApCQkgRVJSIzI1ICdJ bmFwcHJvcHJpYXRlIGlvY3RsIGZvciBkZXZpY2UnCiAgMjMwOiBmc3RhdCgyLHsgbW9kZT0tcnct ci0tci0tICxpbm9kZT0xNDEzNTksc2l6ZT0yNTUsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkK ICAyMzA6IHJlYWQoMiwiI1xuIyBuc3N3aXRjaC5jb25mKDUpIC0gbmFtZSBzZXIiLi4uLDE2Mzg0 KSA9IDI1NSAoMHhmZikKICAyMzA6IHJlYWQoMiwweDgwMmM1NDAwMCwxNjM4NCkJCSA9IDAgKDB4 MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lH S0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NP TlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxS TXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDAp CiAgMjMwOiBhY2Nlc3MoIi9saWIvbnNzX2NvbXBhdC5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xpYi9uc3NfY29tcGF0LnNv LjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2Vzcygi L3Vzci9saWIvY29tcGF0L25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL25zc19jb21wYXQuc28u MSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91 c3IvbG9jYWwva2RlNC9saWIvbnNzX2NvbXBhdC5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxl IG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvY29tcGF0L25zc19j b21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBh Y2Nlc3MoIi91c3IvbG9jYWwvbGliL2dlZ2wtMC4xL25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIg J05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGli L2dyYXBodml6L25zc19jb21wYXQuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL3F0NC9uc3NfY29tcGF0LnNvLjEi LDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvbGli L25zc19jb21wYXQuc28uMSIsMCkJCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScK ICAyMzA6IGFjY2VzcygiL3Vzci9saWIvbnNzX2NvbXBhdC5zby4xIiwwKQkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAs MHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJ TlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9Q fFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJ R1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIs MHgwKSA9IDAgKDB4MCkKICAyMzA6IGFjY2VzcygiL2xpYi9uc3NfbmlzLnNvLjEiLDApCQkgRVJS IzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL25z c19uaXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDog YWNjZXNzKCIvdXNyL2xpYi9jb21wYXQvbnNzX25pcy5zby4xIiwwKQkgRVJSIzIgJ05vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL25zc19uaXMu c28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNz KCIvdXNyL2xvY2FsL2tkZTQvbGliL25zc19uaXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2NvbXBhdC9uc3Nf bmlzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNj ZXNzKCIvdXNyL2xvY2FsL2xpYi9nZWdsLTAuMS9uc3NfbmlzLnNvLjEiLDApIEVSUiMyICdObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9ncmFw aHZpei9uc3NfbmlzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Jwog IDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9xdDQvbnNzX25pcy5zby4xIiwwKSBFUlIjMiAn Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL2xpYi9uc3NfbmlzLnNv LjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3Mo Ii91c3IvbGliL25zc19uaXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkK ICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lM THxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8 U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxT SUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAg MjMwOiBhY2Nlc3MoIi9saWIvbnNzX2ZpbGVzLnNvLjEiLDApCQkgRVJSIzIgJ05vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbGliL25zc19maWxlcy5zby4xIiww KQkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3Iv bGliL2NvbXBhdC9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL25zc19maWxlcy5zby4xIiwwKSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2Nh bC9rZGU0L2xpYi9uc3NfZmlsZXMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91c3IvbG9jYWwvbGliL2NvbXBhdC9uc3NfZmlsZXMuc28u MSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi91 c3IvbG9jYWwvbGliL2dlZ2wtMC4xL25zc19maWxlcy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBm aWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXov bnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIz MDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9xdDQvbnNzX2ZpbGVzLnNvLjEiLDApIEVSUiMyICdO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvbGliL25zc19maWxlcy5z by4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNz KCIvdXNyL2xpYi9uc3NfZmlsZXMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5JwogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4 MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lH S0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NP TlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxS TXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDAp CiAgMjMwOiBhY2Nlc3MoIi9saWIvbnNzX2Rucy5zby4xIiwwKQkJIEVSUiMyICdObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xpYi9uc3NfZG5zLnNvLjEiLDAp CSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9s aWIvY29tcGF0L25zc19kbnMuc28uMSIsMCkJIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9uc3NfZG5zLnNvLjEiLDApCSBFUlIj MiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2NhbC9r ZGU0L2xpYi9uc3NfZG5zLnNvLjEiLDApIEVSUiMyICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 JwogIDIzMDogYWNjZXNzKCIvdXNyL2xvY2FsL2xpYi9jb21wYXQvbnNzX2Rucy5zby4xIiwwKSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2Nh bC9saWIvZ2VnbC0wLjEvbnNzX2Rucy5zby4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeScKICAyMzA6IGFjY2VzcygiL3Vzci9sb2NhbC9saWIvZ3JhcGh2aXovbnNzX2Rucy5z by4xIiwwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IGFjY2Vzcygi L3Vzci9sb2NhbC9saWIvcXQ0L25zc19kbnMuc28uMSIsMCkgRVJSIzIgJ05vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnknCiAgMjMwOiBhY2Nlc3MoIi9saWIvbnNzX2Rucy5zby4xIiwwKQkJIEVSUiMy ICdObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5JwogIDIzMDogYWNjZXNzKCIvdXNyL2xpYi9uc3Nf ZG5zLnNvLjEiLDApCSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IHNp Z3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBpb2N0bCgy LFRJT0NHRVRBLDB4ZmZmZmRkOTApCQkgRVJSIzI1ICdJbmFwcHJvcHJpYXRlIGlvY3RsIGZvciBk ZXZpY2UnCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgw MmM1NDAwMCwweDQwMDAsMHg1LDB4NTMsMHg0YzAwOCwweDgwMjg1YWZjMCkgPSAwICgweDApCiAg MjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8 U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJ R0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lH UFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIz MDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IHNp Z3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBF fFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxT SUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJ R1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdw cm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIzMDogZ2V0ZXVpZCgp CQkJCSA9IDEwMDAgKDB4M2U4KQogIDIzMDogb3BlbigiL2V0Yy9wd2QuZGIiLE9fUkRPTkxZLDAw KQkJID0gMiAoMHgyKQogIDIzMDogZmNudGwoMixGX1NFVEZELEZEX0NMT0VYRUMpCQkgPSAwICgw eDApCiAgMjMwOiBmc3RhdCgyLHsgbW9kZT0tcnctci0tci0tICxpbm9kZT0xNDE1Mzcsc2l6ZT00 MDk2MCxibGtzaXplPTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDogcmVhZCgyLCJcMFxeRlxeVWFc MFwwXDBcXkJcMFwwXF5EXE0tUlwwIi4uLiwyNjApID0gMjYwICgweDEwNCkKICAyMzA6IHByZWFk KDB4MiwweDgwMmNhMjAwMCwweDEwMDAsMHg2MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQog IDIzMDogcHJlYWQoMHgyLDB4ODAyY2EzMDAwLDB4MTAwMCwweDQwMDAsMHgxLDB4MCkgPSA0MDk2 ICgweDEwMDApCiAgMjMwOiBwcmVhZCgweDIsMHg4MDJjYTQwMDAsMHgxMDAwLDB4NTAwMCwweDEs MHgwKSA9IDQwOTYgKDB4MTAwMCkKICAyMzA6IHByZWFkKDB4MiwweDgwMmNhNTAwMCwweDEwMDAs MHg3MDAwLDB4MSwweDApID0gNDA5NiAoMHgxMDAwKQogIDIzMDogcHJlYWQoMHgyLDB4ODAyY2E2 MDAwLDB4MTAwMCwweDgwMDAsMHgxLDB4MCkgPSA0MDk2ICgweDEwMDApCiAgMjMwOiBwcmVhZCgw eDIsMHg4MDJjYTcwMDAsMHgxMDAwLDB4MTAwMCwweDEsMHgwKSA9IDQwOTYgKDB4MTAwMCkKICAy MzA6IHByZWFkKDB4MiwweDgwMmNhODAwMCwweDEwMDAsMHgyMDAwLDB4MSwweDApID0gNDA5NiAo MHgxMDAwKQogIDIzMDogcHJlYWQoMHgyLDB4ODAyY2E5MDAwLDB4MTAwMCwweDMwMDAsMHgxLDB4 MCkgPSA0MDk2ICgweDEwMDApCiAgMjMwOiBtYWR2aXNlKDB4ODAyY2E4MDAwLDB4MjAwMCwweDUs MHhhNywweDEsMHgwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZpc2UoMHg4MDJjYTIwMDAsMHg0MDAw LDB4NSwweGExLDB4MSwweDApID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmNhNjAwMCww eDIwMDAsMHg1LDB4YTUsMHgxLDB4N2ZmZmZmZmZkMjEwKSA9IDAgKDB4MCkKICAyMzA6IG1hZHZp c2UoMHg4MDJjYTEwMDAsMHgxMDAwLDB4NSwweGEwLDB4MSwweDdmZmZmZmZmZDIxMCkgPSAwICgw eDApCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmM1 OTAwMCwweDIwMDAsMHg1LDB4NTgsMHg0YzAwOCwweDdmZmZmZmZmZDI1MCkgPSAwICgweDApCiAg MjMwOiBta2RpcigiL3Vzci9ob21lL2djb29wZXIvLm1vemMiLDA3MDApCSBFUlIjMTcgJ0ZpbGUg ZXhpc3RzJwogIDIzMDogc3RhdCgiL3Vzci9ob21lL2djb29wZXIvLm1vemMiLHsgbW9kZT1kcnd4 LS0tLS0tICxpbm9kZT0zMDM5MjUxLHNpemU9NTEyLGJsa3NpemU9MTYzODQgfSkgPSAwICgweDAp CiAgMjMwOiBvcGVuKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96Yy9tb3pjX3NlcnZlci5sb2ciLE9f V1JPTkxZfE9fQVBQRU5EfE9fQ1JFQVQsMDY2NikgPSAyICgweDIpCiAgMjMwOiBsc2VlaygyLDB4 MCxTRUVLX0VORCkJCQkgPSAyMjYzICgweDhkNykKICAyMzA6IGNobW9kKCIvdXNyL2hvbWUvZ2Nv b3Blci8ubW96Yy9tb3pjX3NlcnZlci5sb2ciLDA2MDApID0gMCAoMHgwKQogIDIzMDogY2xvY2tf Z2V0dGltZSgxMyx7MTI4NjIwMTI0NS4wMDAwMDAwMDAgfSkgPSAwICgweDApCiAgMjMwOiBhY2Nl c3MoIi9ldGMvbG9jYWx0aW1lIiw0KQkJID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2V0Yy9sb2Nh bHRpbWUiLE9fUkRPTkxZLDAxKQkgPSAzICgweDMpCiAgMjMwOiBmc3RhdCgzLHsgbW9kZT0tci0t ci0tci0tICxpbm9kZT0xNDE0MDMsc2l6ZT0yODE5LGJsa3NpemU9MTYzODQgfSkgPSAwICgweDAp CiAgMjMwOiByZWFkKDMsIlRaaWYyXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDAiLi4uLDQxNDQ4 KSA9IDI4MTkgKDB4YjAzKQogIDIzMDogY2xvc2UoMykJCQkJCSA9IDAgKDB4MCkKICAyMzA6IGlz c2V0dWdpZCgweDgwMjcyY2U1OSwweDdmZmZmZmZmOWMxMCwweDAsMHg3ZmZmZmZmZWZhMjUsMHg1 MCwweDgpID0gMCAoMHgwKQogIDIzMDogb3BlbigiL3Vzci9zaGFyZS96b25laW5mby9wb3NpeHJ1 bGVzIixPX1JET05MWSwwNTYpID0gMyAoMHgzKQogIDIzMDogZnN0YXQoMyx7IG1vZGU9LXItLXIt LXItLSAsaW5vZGU9MjE1MDUxNCxzaXplPTM1MTksYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkK ICAyMzA6IHJlYWQoMywiVFppZjJcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sNDE0NDgp ID0gMzUxOSAoMHhkYmYpCiAgMjMwOiBjbG9zZSgzKQkJCQkJID0gMCAoMHgwKQogIDIzMDogZ2V0 cGlkKCkJCQkJCSA9IDIzMCAoMHhlNikKICAyMzA6IHdyaXRlKDIsIkxvZyBmaWxlIGNyZWF0ZWQg YXQ6IDIwMTAtMTAtMDQgIi4uLiw1NykgPSA1NyAoMHgzOSkKICAyMzA6IHdyaXRlKDIsIlByb2dy YW0gbmFtZTogbW96Y19zZXJ2ZXJcbiIsMjYpID0gMjYgKDB4MWEpCiAgMjMwOiBjaG1vZCgiL3Vz ci9ob21lL2djb29wZXIvLm1vemMvLnNlcnZlci5sb2NrIiwwNjAwKSA9IDAgKDB4MCkKICAyMzA6 IG9wZW4oIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5zZXJ2ZXIubG9jayIsT19SRFdSfE9fQ1JF QVR8T19UUlVOQywwNjAwKSA9IDMgKDB4MykKICAyMzA6IGZjbnRsKDMsRl9TRVRMSywweDdmZmZm ZmZmZTVmMCkJCSA9IDAgKDB4MCkKICAyMzA6IGNobW9kKCIvdXNyL2hvbWUvZ2Nvb3Blci8ubW96 Yy8uc2VydmVyLmxvY2siLDA0MDApID0gMCAoMHgwKQogIDIzMDogb3BlbigiL2Rldi91cmFuZG9t IixPX1JET05MWSwwNjY2KQkgPSA0ICgweDQpCiAgMjMwOiByZWFkKDQsIlxNLTxcTS1bcUNcXl5d dlxNLXJcTS1lX1xNXl5eIi4uLiwxMDIzKSA9IDEwMjMgKDB4M2ZmKQogIDIzMDogY2xvc2UoNCkJ CQkJCSA9IDAgKDB4MCkKICAyMzA6IHN0YXQoIi91c3IvaG9tZS9nY29vcGVyLy5tb3pjLy5zZXNz aW9uLmlwYyIseyBtb2RlPS1yLS0tLS0tLS0gLGlub2RlPTMwMzkyNTMsc2l6ZT01NSxibGtzaXpl PTE2Mzg0IH0pID0gMCAoMHgwKQogIDIzMDogb3BlbigiL3Vzci9ob21lL2djb29wZXIvLm1vemMv LnNlc3Npb24uaXBjIixPX1JET05MWSwwNjY2KSA9IDQgKDB4NCkKICAyMzA6IHJlYWQoNCwiXG4g ZWZkMjFkZmI2ZmMwMmQ5MmIzNzc1YzBiOTE5MTgiLi4uLDgxOTIpID0gNTUgKDB4MzcpCiAgMjMw OiByZWFkKDQsMHg4MDJjZTQwMzcsODEzNykJCQkgPSAwICgweDApCiAgMjMwOiBzdGF0KCIvdXNy L2hvbWUvZ2Nvb3Blci8ubW96Yy8uc2Vzc2lvbi5pcGMiLHsgbW9kZT0tci0tLS0tLS0tICxpbm9k ZT0zMDM5MjUzLHNpemU9NTUsYmxrc2l6ZT0xNjM4NCB9KSA9IDAgKDB4MCkKICAyMzA6IGNsb3Nl KDQpCQkJCQkgPSAwICgweDApCiAgMjMwOiBta2RpcigiL3RtcCIsMDcwMCkJCQkgRVJSIzE3ICdG aWxlIGV4aXN0cycKICAyMzA6IHNvY2tldChQRl9MT0NBTCxTT0NLX1NUUkVBTSwwKQkJID0gNCAo MHg0KQogIDIzMDogZmNudGwoNCxGX0dFVEZELCkJCQkgPSAwICgweDApCiAgMjMwOiBmY250bCg0 LEZfU0VURkQsRkRfQ0xPRVhFQykJCSA9IDAgKDB4MCkKICAyMzA6IHNldHNvY2tvcHQoMHg0LDB4 ZmZmZiwweDQsMHg3ZmZmZmZmZmU2N2MsMHg0LDB4NCkgPSAwICgweDApCiAgMjMwOiBiaW5kKDQs eyBBRl9VTklYICIvdG1wLy5tb3pjLmVmZDIxZGZiNmZjMDJkOTJiMzc3NWMwYjkxOTE4YTE5LnNl c3Npb24iIH0sMTA2KSBFUlIjNDggJ0FkZHJlc3MgYWxyZWFkeSBpbiB1c2UnCiAgMjMwOiBzdGF0 KCIvdXNyL3NoYXJlL25scy9DL2xpYmMuY2F0IiwweDdmZmZmZmZmZTBhMCkgRVJSIzIgJ05vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnknCiAgMjMwOiBzdGF0KCIvdXNyL3NoYXJlL25scy9saWJjL0Mi LDB4N2ZmZmZmZmZlMGEwKSBFUlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6 IHN0YXQoIi91c3IvbG9jYWwvc2hhcmUvbmxzL0MvbGliYy5jYXQiLDB4N2ZmZmZmZmZlMGEwKSBF UlIjMiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeScKICAyMzA6IHN0YXQoIi91c3IvbG9jYWwv c2hhcmUvbmxzL2xpYmMvQyIsMHg3ZmZmZmZmZmUwYTApIEVSUiMyICdObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5JwogIDIzMDogY2xvY2tfZ2V0dGltZSgxMyx7MTI4NjIwMTI0NS4wMDAwMDAwMDAg fSkgPSAwICgweDApCiAgMjMwOiBnZXRwaWQoKQkJCQkJID0gMjMwICgweGU2KQogIDIzMDogd3Jp dGUoMiwiMjAxMC0xMC0wNCAwNzowNzoyNSAyMzAgMzQ0MDU5MDQiLi4uLDEwNikgPSAxMDYgKDB4 NmEpCiAgMjMwOiBjbG9zZSgyKQkJCQkJID0gMCAoMHgwKQogIDIzMDogbWFkdmlzZSgweDgwMmNl NDAwMCwweDIwMDAsMHg1LDB4ZTMsMHgxMDA4LDB4N2ZmZmZmZmZkYTQwKSA9IDAgKDB4MCkKICAy MzA6IG1hZHZpc2UoMHg4MDJjZTIwMDAsMHgxMDAwLDB4NSwweGUxLDB4MTAwOCwweDdmZmZmZmZm ZGE0MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lO VHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8 U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lH WEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiww eDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9 IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FV SVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQ fFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJ R1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAw ICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgw KQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdL SUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09O VHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJN fFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkK ICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMw OiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lH UElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NI TER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJP RnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIzMDog c2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IHNpZ3By b2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJ R0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdU VElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJ TkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9j bWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2so U0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxT SUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lH VFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lH SU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJ R19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxP Q0ssU0lHSFVQfFNJR0lOVHxTSUdRVUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18 U0lHVVJHfFNJR1NUT1B8U0lHVFNUUHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJ R0lPfFNJR1hDUFV8U0lHWEZTWnxTSUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJ R1VTUjF8U0lHVVNSMiwweDApID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1B U0ssMHgwLDB4MCkJCSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdI VVB8U0lHSU5UfFNJR1FVSVR8U0lHS0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8 U0lHU1RPUHxTSUdUU1RQfFNJR0NPTlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lH WENQVXxTSUdYRlNafFNJR1ZUQUxSTXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxT SUdVU1IyLDB4MCkgPSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAs MHgwKQkJID0gMCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJ TlR8U0lHUVVJVHxTSUdLSUxMfFNJR1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9Q fFNJR1RTVFB8U0lHQ09OVHxTSUdDSExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJ R1hGU1p8U0lHVlRBTFJNfFNJR1BST0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIs MHgwKSA9IDAgKDB4MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkg PSAwICgweDApCiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfQkxPQ0ssU0lHSFVQfFNJR0lOVHxTSUdR VUlUfFNJR0tJTEx8U0lHUElQRXxTSUdBTFJNfFNJR1RFUk18U0lHVVJHfFNJR1NUT1B8U0lHVFNU UHxTSUdDT05UfFNJR0NITER8U0lHVFRJTnxTSUdUVE9VfFNJR0lPfFNJR1hDUFV8U0lHWEZTWnxT SUdWVEFMUk18U0lHUFJPRnxTSUdXSU5DSHxTSUdJTkZPfFNJR1VTUjF8U0lHVVNSMiwweDApID0g MCAoMHgwKQogIDIzMDogc2lncHJvY21hc2soU0lHX1NFVE1BU0ssMHgwLDB4MCkJCSA9IDAgKDB4 MCkKICAyMzA6IHNpZ3Byb2NtYXNrKFNJR19CTE9DSyxTSUdIVVB8U0lHSU5UfFNJR1FVSVR8U0lH S0lMTHxTSUdQSVBFfFNJR0FMUk18U0lHVEVSTXxTSUdVUkd8U0lHU1RPUHxTSUdUU1RQfFNJR0NP TlR8U0lHQ0hMRHxTSUdUVElOfFNJR1RUT1V8U0lHSU98U0lHWENQVXxTSUdYRlNafFNJR1ZUQUxS TXxTSUdQUk9GfFNJR1dJTkNIfFNJR0lORk98U0lHVVNSMXxTSUdVU1IyLDB4MCkgPSAwICgweDAp CiAgMjMwOiBzaWdwcm9jbWFzayhTSUdfU0VUTUFTSywweDAsMHgwKQkJID0gMCAoMHgwKQogIDIz MDogc2lncHJvY21hc2soU0lHX0JMT0NLLFNJR0hVUHxTSUdJTlR8U0lHUVVJVHxTSUdLSUxMfFNJ R1BJUEV8U0lHQUxSTXxTSUdURVJNfFNJR1VSR3xTSUdTVE9QfFNJR1RTVFB8U0lHQ09OVHxTSUdD SExEfFNJR1RUSU58U0lHVFRPVXxTSUdJT3xTSUdYQ1BVfFNJR1hGU1p8U0lHVlRBTFJNfFNJR1BS T0Z8U0lHV0lOQ0h8U0lHSU5GT3xTSUdVU1IxfFNJR1VTUjIsMHgwKSA9IDAgKDB4MCkKICAyMzA6 IHNpZ3Byb2NtYXNrKFNJR19TRVRNQVNLLDB4MCwweDApCQkgPSAwICgweDApCiAgMjMwOiBwcm9j ZXNzIGV4aXQsIHJ2YWwgPSAyNTUK --0016e6509cc27bfbb10491cb3c91-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 15:43:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 361C110656A4; Mon, 4 Oct 2010 15:43:06 +0000 (UTC) (envelope-from me@zan.st) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0F15F8FC1B; Mon, 4 Oct 2010 15:43:05 +0000 (UTC) Received: by pwi8 with SMTP id 8so1726452pwi.13 for ; Mon, 04 Oct 2010 08:43:05 -0700 (PDT) Received: by 10.142.132.15 with SMTP id f15mr8783372wfd.299.1286205540554; Mon, 04 Oct 2010 08:19:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.165.4 with HTTP; Mon, 4 Oct 2010 08:18:40 -0700 (PDT) X-Originating-IP: [187.35.28.248] In-Reply-To: <4CA630F5.9060500@networx.ch> References: <4CA630F5.9060500@networx.ch> From: stephano zanzin Date: Mon, 4 Oct 2010 12:18:40 -0300 Message-ID: To: Andre Oppermann X-Mailman-Approved-At: Mon, 04 Oct 2010 15:55:24 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Very interesting paper: An Analysis of Linux Scalability to many Cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 15:43:06 -0000 Very interesting! Thanks On Fri, Oct 1, 2010 at 4:05 PM, Andre Oppermann wrote= : > Just saw the link to a very interesting paper on SMP scalability. > A very good read and highly relevant for our efforts as well. In > certain areas we may already fare better, in others we still have > some work to do. > > An Analysis of Linux Scalability to many Cores > > ABSTRACT > This paper analyzes the scalability of seven system applications > (Exim, memcached, Apache, PostgreSQL, gmake, Psearchy, and MapReduce) > running on Linux on a 48-core computer. Except for gmake, all > applications trigger scalability bottlenecks inside a recent Linux > kernel. Using mostly standard parallel programming techniques=97 > this paper introduces one new technique, sloppy counters=97 > these bottlenecks can be removed from the kernel or avoided by > changing the applications slightly. Modifying the kernel required > in total 3002 lines of code changes. A speculative conclusion from > this analysis is that there is no scalability reason to give up on > traditional operating system organizations just yet. > > http://pdos.csail.mit.edu/papers/linux:osdi10.pdf > > -- > Andre > > _______________________________________________ > 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 stephano From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 16:14:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70DC2106566C for ; Mon, 4 Oct 2010 16:14:17 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 243928FC08 for ; Mon, 4 Oct 2010 16:14:16 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o94GEGp0010176; Mon, 4 Oct 2010 09:14:16 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o94GEFTD010175; Mon, 4 Oct 2010 09:14:15 -0700 (PDT) (envelope-from david) Date: Mon, 4 Oct 2010 09:14:15 -0700 From: David Wolfskill To: Andriy Gapon Message-ID: <20101004161415.GF1410@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Andriy Gapon , current@freebsd.org References: <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> <20101003112859.GW1535@albert.catwhisker.org> <4CA86E73.9080707@icyb.net.ua> <20101003131409.GX1535@albert.catwhisker.org> <4CA906EB.5090305@freebsd.org> <20101004004910.GD1410@albert.catwhisker.org> <4CA985D2.3000805@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7mxbaLlpDEyR1+x6" Content-Disposition: inline In-Reply-To: <4CA985D2.3000805@icyb.net.ua> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: [geom, cam] Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:14:17 -0000 --7mxbaLlpDEyR1+x6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 04, 2010 at 10:44:18AM +0300, Andriy Gapon wrote: > ... > Interesting! :-} > So, init thread is blocked in vfs_mountroot()->g_waitidle() waiting for g= eom to > complete probing cd device, but the latter is blocked in cam_periph_getcc= b() > waiting for a ccb. > Can you try to reproduce this again and examine other thread for anything > interesting in geom/cam department? Thread named as "xpt_thrd" might be = of > particular interest. Yes; I can do that. Bearing in mind that each of us has a finite number of keystrokes in his (or her) life, typing all that stuff by hand, though, tends to eat into that upper limit a bit faster than most other forms of recreation do. :-} Is there a way I can use USB or firewire in a way similar to a serial console? The laptop has both of those (though I only have connectors for USB at the moment), and does not have a DB9 (let alone a DB25) serial port. I'd welcome a pointer. Anyway: I have a couple of slices where I can re-create it: * Slice 3 uses "standard ATA", and runs head as of r213322. * Slice 4 uses ATA_CAM and is presently running head as of r213400. Symptoms are fairly similar in each, though ?I seem to see the hang less frequently when I use ATA_CAM. In either case, PID 8 is [xpt_thrd], and wmesg is "ccb_scan". I'll hold off on transcribing the backtrace for PID 8, in hope of being able to let the machine do the clerical work. :-} > We urgently need geom and cam experts here :-) Given sufficient pointers on actions to take, patches to apply, or code to hack, I'm willing. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --7mxbaLlpDEyR1+x6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkyp/VYACgkQmprOCmdXAD1WhgCffQGpdHtpbTqmjejRaL0nZpfp jN8An1L36NUf03u/wQZhre0WjYrS1xSS =rpiL -----END PGP SIGNATURE----- --7mxbaLlpDEyR1+x6-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 16:29:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 201211065786 for ; Mon, 4 Oct 2010 16:29:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 6D42F8FC13 for ; Mon, 4 Oct 2010 16:29:57 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=4dE6tNKVm/0afO7MQGRPv7y2YwMo4emTIiDjbh74onY= c=1 sm=1 a=NzH_YkiikfIA:10 a=Q9fys5e9bTEA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=sD1TDXKpkObTemEpdjgA:9 a=AVdV_SAXyNplk1qrAXPjJDJ_ENEA:4 a=PUjeQqilurYA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 30427312; Mon, 04 Oct 2010 18:29:56 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 4 Oct 2010 18:31:08 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101001233001.GG1535@albert.catwhisker.org> <4CA985D2.3000805@icyb.net.ua> <20101004161415.GF1410@albert.catwhisker.org> In-Reply-To: <20101004161415.GF1410@albert.catwhisker.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010041831.08733.hselasky@c2i.net> Cc: current@freebsd.org, Andriy Gapon Subject: Re: [geom, cam] Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:29:59 -0000 On Monday 04 October 2010 18:14:15 David Wolfskill wrote: > Is there a way I can use USB or firewire in a way similar to a serial > console? If a USB keyboard is enumerated at the point of break, it will be available from KDB. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 16:30:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C544D1065672 for ; Mon, 4 Oct 2010 16:30:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1832D8FC23 for ; Mon, 4 Oct 2010 16:30:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA06756; Mon, 04 Oct 2010 19:30:22 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CAA011D.1070401@icyb.net.ua> Date: Mon, 04 Oct 2010 19:30:21 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Wolfskill , current@freebsd.org References: <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> <20101003112859.GW1535@albert.catwhisker.org> <4CA86E73.9080707@icyb.net.ua> <20101003131409.GX1535@albert.catwhisker.org> <4CA906EB.5090305@freebsd.org> <20101004004910.GD1410@albert.catwhisker.org> <4CA985D2.3000805@icyb.net.ua> <20101004161415.GF1410@albert.catwhisker.org> In-Reply-To: <20101004161415.GF1410@albert.catwhisker.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Subject: Re: [geom, cam] Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:30:42 -0000 on 04/10/2010 19:14 David Wolfskill said the following: > On Mon, Oct 04, 2010 at 10:44:18AM +0300, Andriy Gapon wrote: >> ... >> Interesting! > > :-} > >> So, init thread is blocked in vfs_mountroot()->g_waitidle() waiting for geom to >> complete probing cd device, but the latter is blocked in cam_periph_getccb() >> waiting for a ccb. >> Can you try to reproduce this again and examine other thread for anything >> interesting in geom/cam department? Thread named as "xpt_thrd" might be of >> particular interest. > > Yes; I can do that. Bearing in mind that each of us has a finite > number of keystrokes in his (or her) life, typing all that stuff > by hand, though, tends to eat into that upper limit a bit faster than > most other forms of recreation do. :-} > > Is there a way I can use USB or firewire in a way similar to a serial > console? The laptop has both of those (though I only have connectors > for USB at the moment), and does not have a DB9 (let alone a DB25) > serial port. I'd welcome a pointer. You should be able to use firewire console. I have never done that myself, so can't help with setting it up. BTW, personally for me links to screenshots (e.g. taken with a digital camera) are OK. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 16:40:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4592106567A for ; Mon, 4 Oct 2010 16:40:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 477BF8FC13 for ; Mon, 4 Oct 2010 16:39:59 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=4dE6tNKVm/0afO7MQGRPv7y2YwMo4emTIiDjbh74onY= c=1 sm=1 a=NzH_YkiikfIA:10 a=Q9fys5e9bTEA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=sD1TDXKpkObTemEpdjgA:9 a=AVdV_SAXyNplk1qrAXPjJDJ_ENEA:4 a=PUjeQqilurYA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 30427312; Mon, 04 Oct 2010 18:29:56 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 4 Oct 2010 18:31:08 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101001233001.GG1535@albert.catwhisker.org> <4CA985D2.3000805@icyb.net.ua> <20101004161415.GF1410@albert.catwhisker.org> In-Reply-To: <20101004161415.GF1410@albert.catwhisker.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010041831.08733.hselasky@c2i.net> Cc: current@freebsd.org, Andriy Gapon Subject: Re: [geom, cam] Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:40:00 -0000 On Monday 04 October 2010 18:14:15 David Wolfskill wrote: > Is there a way I can use USB or firewire in a way similar to a serial > console? If a USB keyboard is enumerated at the point of break, it will be available from KDB. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 16:43:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 979AA1065673 for ; Mon, 4 Oct 2010 16:43:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DD5FA8FC0A for ; Mon, 4 Oct 2010 16:43:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA06927; Mon, 04 Oct 2010 19:42:56 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CAA040F.3090000@icyb.net.ua> Date: Mon, 04 Oct 2010 19:42:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Wolfskill , current@freebsd.org References: <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> <20101002033859.GK1535@albert.catwhisker.org> <20101003112859.GW1535@albert.catwhisker.org> <4CA86E73.9080707@icyb.net.ua> <20101003131409.GX1535@albert.catwhisker.org> <4CA906EB.5090305@freebsd.org> <20101004004910.GD1410@albert.catwhisker.org> <4CA985D2.3000805@icyb.net.ua> <20101004161415.GF1410@albert.catwhisker.org> <4CAA011D.1070401@icyb.net.ua> In-Reply-To: <4CAA011D.1070401@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Subject: Re: [geom, cam] Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:43:11 -0000 on 04/10/2010 19:30 Andriy Gapon said the following: > on 04/10/2010 19:14 David Wolfskill said the following: >> Is there a way I can use USB or firewire in a way similar to a serial >> console? The laptop has both of those (though I only have connectors >> for USB at the moment), and does not have a DB9 (let alone a DB25) >> serial port. I'd welcome a pointer. > > You should be able to use firewire console. > I have never done that myself, so can't help with setting it up. Found this link: http://wiki.freebsd.org/DebugWithDcons > BTW, personally for me links to screenshots (e.g. taken with a digital camera) are OK. > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 18:16:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44CCC1065675 for ; Mon, 4 Oct 2010 18:16:01 +0000 (UTC) (envelope-from kma@mrecic.gov.ar) Received: from mx1.mrecic.gov.ar (mx1.mrecic.gov.ar [200.16.99.221]) by mx1.freebsd.org (Postfix) with ESMTP id AF56E8FC19 for ; Mon, 4 Oct 2010 18:16:00 +0000 (UTC) Received: from mrelmx07.mrec.ar ([140.191.48.38]) by mx1.mrecic.gov.ar with ESMTP; 04 Oct 2010 14:46:02 -0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by mrelmx07.mrec.ar (Postfix) with ESMTP id 7C36E71D2C for ; Mon, 4 Oct 2010 14:46:02 -0300 (ART) X-Virus-Scanned: amavisd-new at mrelmx07.mrec.ar Received: from mrelmx07.mrec.ar ([127.0.0.1]) by localhost (mrelmx07.mrec.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIxWSXW4CC+u for ; Mon, 4 Oct 2010 14:46:01 -0300 (ART) Received: from mrelmx06.mrec.ar (mrelmx10.mrec.ar [140.191.48.45]) by mrelmx07.mrec.ar (Postfix) with ESMTP id E3F7471D2B for ; Mon, 4 Oct 2010 14:46:01 -0300 (ART) Date: Mon, 4 Oct 2010 13:46:01 -0400 (EDT) From: Kevin Mai To: freebsd-current@freebsd.org Message-ID: <7459633.69735.1286214361816.JavaMail.root@mrelmx10.mrec.ar> MIME-Version: 1.0 X-Originating-IP: [140.191.48.40] X-Mailer: Zimbra 6.0.6_GA_2330.DEBIAN5_64 (ZimbraWebClient - FF3.0 (Linux)/6.0.6_GA_2330.DEBIAN5_64) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Multithread Make in multicore server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:16:01 -0000 I'm trying to do a "make buildworld" to build some jails on a Dell R710 server. It has 16 cores: [root@mrefns09 ~]# sysctl hw.ncpu hw.ncpu: 16 but, when doing running the "make buildworld" command: last pid: 77993; load averages: 1.07, 1.03, 0.95 up 38+01:12:10 17:42:09 87 processes: 2 running, 85 sleeping CPU 0: 1.9% user, 0.0% nice, 2.6% system, 0.0% interrupt, 95.5% idle CPU 1: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle CPU 2: 1.9% user, 0.0% nice, 2.3% system, 0.0% interrupt, 95.9% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 8: 90.6% user, 0.0% nice, 5.6% system, 0.0% interrupt, 3.8% idle CPU 9: 0.4% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.3% idle CPU 10: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 11: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 12: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 13: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 14: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 15: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 159M Active, 6514M Inact, 782M Wired, 126M Cache, 827M Buf, 324M Free Swap: 8192M Total, 44K Used, 8192M Free I see that there's no multithreading when running make.. is there a way to enable multiprocessing when running make? Many thanks, Kevin From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 18:23:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9471065672 for ; Mon, 4 Oct 2010 18:23:04 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 5074C8FC16 for ; Mon, 4 Oct 2010 18:23:04 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id 8CF0511BABC; Mon, 4 Oct 2010 13:23:03 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id 5WJLLBGG84T5; Mon, 04 Oct 2010 13:23:03 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <7459633.69735.1286214361816.JavaMail.root@mrelmx10.mrec.ar> Date: Mon, 4 Oct 2010 19:23:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47E32F6D-498C-4706-8AD6-355F9BD7887C@FreeBSD.org> References: <7459633.69735.1286214361816.JavaMail.root@mrelmx10.mrec.ar> To: Kevin Mai X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org Subject: Re: Multithread Make in multicore server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:23:04 -0000 On 4 Oct 2010, at 18:46, Kevin Mai wrote: > I'm trying to do a "make buildworld" to build some jails on a Dell = R710 server.=20 >=20 > It has 16 cores:=20 >=20 > [root@mrefns09 ~]# sysctl hw.ncpu=20 > hw.ncpu: 16=20 >=20 > but, when doing running the "make buildworld" command:=20 >=20 > last pid: 77993; load averages: 1.07, 1.03, 0.95 up 38+01:12:10 = 17:42:09=20 > 87 processes: 2 running, 85 sleeping=20 > CPU 0: 1.9% user, 0.0% nice, 2.6% system, 0.0% interrupt, 95.5% idle=20= > CPU 1: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle=20= > CPU 2: 1.9% user, 0.0% nice, 2.3% system, 0.0% interrupt, 95.9% idle=20= > CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20 > CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20 > CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20 > CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20 > CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20 > CPU 8: 90.6% user, 0.0% nice, 5.6% system, 0.0% interrupt, 3.8% idle=20= > CPU 9: 0.4% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.3% idle=20= > CPU 10: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20= > CPU 11: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20= > CPU 12: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20= > CPU 13: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20= > CPU 14: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20= > CPU 15: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle=20= > Mem: 159M Active, 6514M Inact, 782M Wired, 126M Cache, 827M Buf, 324M = Free=20 > Swap: 8192M Total, 44K Used, 8192M Free=20 >=20 > I see that there's no multithreading when running make.. is there a = way to enable multiprocessing when running make?=20 Try 'make -j16 buildworld'. 16 is the maximum number of parallels = processes that make is going to run. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 18:41:23 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF541065670; Mon, 4 Oct 2010 18:41:23 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f68.google.com (mail-ww0-f68.google.com [74.125.82.68]) by mx1.freebsd.org (Postfix) with ESMTP id E2F1B8FC13; Mon, 4 Oct 2010 18:41:22 +0000 (UTC) Received: by wwi17 with SMTP id 17so1913725wwi.7 for ; Mon, 04 Oct 2010 11:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=zFqrmy6vcKN7uX+P8FGxGGS8ypO76HMsK5Zd/q+UkrM=; b=cNWXWrcXUldTtcPC90yLc0CjAQ4QQa+7gXtpx7WfhgiLnGpug4nxjpaUvd45Ecuoub O8wSL37hJ0DE+gOiTBG6CTDSttSIFxKR1G4mQebaLYbmvnipXXKq/b/r6YJb/xMyJKcD iPZtadKaL3y2ImfGkX4VZjCzgA+iBEfm9dszQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=mKn5jzS5ywezFT66f1ospcLMSG42DRMe3gi+ScAt2d9XPNcSvxflJysxegMqkMhz5w VpunJQXatPIl5tVUGqd8vvq8Oine2AKHy21cNVKKwaZoK8qQVSIYaNrstlSgD13BKqFX ImyDdGA/yAlDGOErotSZuDVR/gLtjwkC5yECc= Received: by 10.216.90.132 with SMTP id e4mr8088042wef.73.1286217680799; Mon, 04 Oct 2010 11:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.181.142 with HTTP; Mon, 4 Oct 2010 11:41:00 -0700 (PDT) In-Reply-To: <4CA904FB.4040105@FreeBSD.org> References: <20101003134111.GA98699@oriental.arm.org> <4CA89F6B.8050108@FreeBSD.org> <4CA904FB.4040105@FreeBSD.org> From: Renato Botelho Date: Mon, 4 Oct 2010 15:41:00 -0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dlt@mebtel.net, current@freebsd.org Subject: Re: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:41:23 -0000 On Sun, Oct 3, 2010 at 7:34 PM, Dimitry Andric wrote: > On 2010-10-03 17:21, Dimitry Andric wrote: >> >> Since gnash has about a gazillion dependencies, and I have the idea that >> after 12 hours of building stuff, I will not be able to reproduce your >> error message anyway, could you please post it (or upload it, if it is >> very large)? > > I cannot reproduce your problem, even after installing the gazillion > dependencies. :) > > However, gnash has the same problem that a lot of other ports have: its > configure script assumes the verbose output of a linking command has a > certain format. =A0The end result is almost always a linking error > "hidden symbol `__dso_handle' in /usr/lib/crtbegin.o is referenced by > DSO", or similar. > > That problem should be fixed by this patch: > http://www.andric.com/freebsd/clang/graphics-gnash-clang.diff > > There is also a chance this might fix your issue, can you please try it > out? Same problem here with this patch --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 18:45:43 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E20A1065672 for ; Mon, 4 Oct 2010 18:45:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5DFB58FC1A for ; Mon, 4 Oct 2010 18:45:43 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4491:c9ed:90e6:a13b] (unknown [IPv6:2001:7b8:3a7:0:4491:c9ed:90e6:a13b]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 90D365C43; Mon, 4 Oct 2010 20:45:42 +0200 (CEST) Message-ID: <4CAA20DF.6000504@FreeBSD.org> Date: Mon, 04 Oct 2010 20:45:51 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12pre) Gecko/20101001 Lanikai/3.1.5pre MIME-Version: 1.0 To: Renato Botelho References: <20101003134111.GA98699@oriental.arm.org> <4CA89F6B.8050108@FreeBSD.org> <4CA904FB.4040105@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dlt@mebtel.net, current@freebsd.org Subject: Re: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:45:43 -0000 On 2010-10-04 20:41, Renato Botelho wrote: >> There is also a chance this might fix your issue, can you please try it >> out? > Same problem here with this patch It turns out it was an issue in libvgl, which should be fixed by r213412. Can you please try to update to that revision, rebuild and reinstall (at least) lib/libvgl with clang, and then build the port again? From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 19:23:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA9D6106566B for ; Mon, 4 Oct 2010 19:23:36 +0000 (UTC) (envelope-from kma@mrecic.gov.ar) Received: from mx1.mrecic.gov.ar (mx1.mrecic.gov.ar [200.16.99.221]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD5A8FC0A for ; Mon, 4 Oct 2010 19:23:35 +0000 (UTC) Received: from mrelmx07.mrec.ar ([140.191.48.38]) by mx1.mrecic.gov.ar with ESMTP; 04 Oct 2010 16:23:34 -0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by mrelmx07.mrec.ar (Postfix) with ESMTP id 71BC371D2C for ; Mon, 4 Oct 2010 16:23:34 -0300 (ART) X-Virus-Scanned: amavisd-new at mrelmx07.mrec.ar Received: from mrelmx07.mrec.ar ([127.0.0.1]) by localhost (mrelmx07.mrec.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X-vpref7AMr for ; Mon, 4 Oct 2010 16:23:33 -0300 (ART) Received: from mrelmx06.mrec.ar (mrelmx10.mrec.ar [140.191.48.45]) by mrelmx07.mrec.ar (Postfix) with ESMTP id BC19E71D2B for ; Mon, 4 Oct 2010 16:23:33 -0300 (ART) Date: Mon, 4 Oct 2010 15:23:33 -0400 (EDT) From: Kevin Mai To: freebsd-current Message-ID: <2069590490.70039.1286220213689.JavaMail.root@mrelmx10.mrec.ar> MIME-Version: 1.0 X-Originating-IP: [140.191.48.40] X-Mailer: Zimbra 6.0.6_GA_2330.DEBIAN5_64 (ZimbraWebClient - FF3.0 (Linux)/6.0.6_GA_2330.DEBIAN5_64) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Issues after running make installworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:23:36 -0000 I've just tried to do a make installworld DESTDIR=$jail1 where jail1='/var/lib/jail1' and I changed my mind. I tried to delete the folder but it seems somehow some ACLs got between. I'm doing this make as root: [root@mrefns09 /var/lib]# setfacl -k jail1/bin/rcp setfacl: jail1/bin/rcp: acl_get_file() failed: Operation not supported [root@mrefns09 /var/lib]# getfacl jail1/bin/rcp # file: jail1/bin/rcp # owner: root # group: wheel user::r-x group::r-x other::r-x [root@mrefns09 /var/lib]# id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator),5551(Domain Admins) I cannot change the ACL, nor delete the flag, even though I'm root. Any ideas? From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 19:37:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9975B1065672 for ; Mon, 4 Oct 2010 19:37:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E162A8FC14 for ; Mon, 4 Oct 2010 19:37:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA10629; Mon, 04 Oct 2010 22:37:11 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P2qqU-000NyC-RW; Mon, 04 Oct 2010 22:37:10 +0300 Message-ID: <4CAA2CE6.2020409@icyb.net.ua> Date: Mon, 04 Oct 2010 22:37:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Kevin Mai References: <2069590490.70039.1286220213689.JavaMail.root@mrelmx10.mrec.ar> In-Reply-To: <2069590490.70039.1286220213689.JavaMail.root@mrelmx10.mrec.ar> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: Issues after running make installworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:37:19 -0000 on 04/10/2010 22:23 Kevin Mai said the following: > I've just tried to do a make installworld DESTDIR=$jail1 where jail1='/var/lib/jail1' and I changed my mind. > > I tried to delete the folder but it seems somehow some ACLs got between. I'm doing this make as root: > > [root@mrefns09 /var/lib]# setfacl -k jail1/bin/rcp > setfacl: jail1/bin/rcp: acl_get_file() failed: Operation not supported > [root@mrefns09 /var/lib]# getfacl jail1/bin/rcp > # file: jail1/bin/rcp > # owner: root > # group: wheel > user::r-x > group::r-x > other::r-x > [root@mrefns09 /var/lib]# id > uid=0(root) gid=0(wheel) groups=0(wheel),5(operator),5551(Domain Admins) > > > I cannot change the ACL, nor delete the flag, even though I'm root. ls -l -o jail1/bin/rcp -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 20:43:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 972E01065673 for ; Mon, 4 Oct 2010 20:43:26 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4EA8FC13 for ; Mon, 4 Oct 2010 20:43:26 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id CF3BDA2D30; Mon, 4 Oct 2010 22:43:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <2069590490.70039.1286220213689.JavaMail.root@mrelmx10.mrec.ar> Date: Mon, 4 Oct 2010 22:43:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98D95524-D229-49F0-8738-DD5111F22FD8@lassitu.de> References: <2069590490.70039.1286220213689.JavaMail.root@mrelmx10.mrec.ar> To: Kevin Mai X-Mailer: Apple Mail (2.1081) Cc: freebsd-current Subject: Re: Issues after running make installworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 20:43:26 -0000 Am 04.10.2010 um 21:23 schrieb Kevin Mai: > I've just tried to do a make installworld DESTDIR=3D$jail1 where = jail1=3D'/var/lib/jail1' and I changed my mind.=20 >=20 > I tried to delete the folder but it seems somehow some ACLs got = between. I don't think installworld does anything with ACLs. What's the actual = error message from what command? What revision of -current are you = using? What type of filesystem is /var/lib/jail1, which options was it = created with, and how is it mounted? It's most likely the flags (see chflags(8)), so try chflags -R noschg = /var/lib/jail1. Stefan p.s. such questions are more appropriate on freebsd-questions@. --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 21:23:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92C50106566C for ; Mon, 4 Oct 2010 21:23:29 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0868FC0C for ; Mon, 4 Oct 2010 21:23:28 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P2sVM-0001Vq-5i for freebsd-current@freebsd.org; Mon, 04 Oct 2010 23:23:28 +0200 Received: from k.saper.info ([91.121.151.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Oct 2010 23:23:28 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Oct 2010 23:23:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Mon, 4 Oct 2010 21:23:19 +0000 (UTC) Organization: http://saper.info Lines: 27 Message-ID: References: <201009151749.45038.jhb@freebsd.org> <201009170854.56516.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: k.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) X-Mailman-Approved-At: Mon, 04 Oct 2010 21:26:16 +0000 Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 21:23:29 -0000 >> John Baldwin wrote: > On Thursday, September 16, 2010 9:02:23 am Marcin Cieslak wrote: >> Dnia 15.09.2010 John Baldwin napisał/a: >> > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: >> >> Output queue of tun(4) gets full after some time when sending lots of data. >> >> I have been observing this on -CURRENT at least since March this year. >> >> >> >> Looks like it's a race condition (same in tun(4) and tap(4)), >> >> the following patch seems to address the issue: >> > >> > This is a good find. I actually went through these drivers a bit further and >> > have a bit of a larger patch to extend the locking some. Would you care to >> > test it? >> >> Do you think those drivers could be taken out of Giant after this change? >> I think that networking code path (via if_start etc.) is not using Giant >> at all, only cdevsw routines are. Am I right? > > Oh, yes. I've updated the patch to remove D_NEEDGIANT. I just want to report back that may tun(4) tunnel has been rock-solid since I applied the patch. Didn't have a chance to test tap(4) and it won't happen for another week or so - I hope somebody else jumps in the meantime. Thank you! //Marcin From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 22:15:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE0A1065670; Mon, 4 Oct 2010 22:15:17 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail962c35.nsolutionszone.com (mail962c35.nsolutionszone.com [209.235.152.152]) by mx1.freebsd.org (Postfix) with ESMTP id E81048FC12; Mon, 4 Oct 2010 22:15:16 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail962c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id o94MFDIJ027620; Mon, 4 Oct 2010 22:15:15 GMT Date: Mon, 4 Oct 2010 18:15:13 -0400 From: Derek Tattersall To: Dimitry Andric Message-ID: <20101004221513.GA27890@oriental.arm.org> References: <20101003134111.GA98699@oriental.arm.org> <4CA89F6B.8050108@FreeBSD.org> <4CA904FB.4040105@FreeBSD.org> <4CAA20DF.6000504@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CAA20DF.6000504@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-CSC: 0 X-CHA: v=1.1 cv=uVrN/md/HB0tP65KUyQDxMIwb8qE6v9oaXSvIWlxpDE= c=1 sm=1 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=6I5d2MoRAAAA:8 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=1KopmBxczQOOOsNxHBMA:9 a=uReBgmIcBd6QN6oAo54A:7 a=BuwAp7slAorTNU-pRGgDtcMN3woA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: Renato Botelho , current@freebsd.org Subject: Re: Another clang problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 22:15:17 -0000 * Dimitry Andric [101004 17:12]: > On 2010-10-04 20:41, Renato Botelho wrote: > >>There is also a chance this might fix your issue, can you please try it > >>out? > >Same problem here with this patch > > It turns out it was an issue in libvgl, which should be fixed by > r213412. Can you please try to update to that revision, rebuild and > reinstall (at least) lib/libvgl with clang, and then build the port > again? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I updated kernel and world via csup at approximately 1730 EST. simple.c was at version 1.9. No problems were encountered. I rebuilt libvgl with clang and installed it. I then rebuilt gnash with gcc and it builds and installs properly. Thanks for your successful resolution to this problem! -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 23:08:39 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDA90106566B for ; Mon, 4 Oct 2010 23:08:39 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 75E5E8FC13 for ; Mon, 4 Oct 2010 23:08:39 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o94N8c2a012455; Mon, 4 Oct 2010 16:08:38 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o94N8cfJ012454; Mon, 4 Oct 2010 16:08:38 -0700 (PDT) (envelope-from david) Date: Mon, 4 Oct 2010 16:08:38 -0700 From: David Wolfskill To: Brandon Gooch Message-ID: <20101004230838.GM1410@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Brandon Gooch , current@freebsd.org References: <20101001212038.GE1535@albert.catwhisker.org> <20101001233001.GG1535@albert.catwhisker.org> <20101002013344.GI1535@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tDYGg60iReQ7u8wj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: Hang near end of kernel probes since r213267 (likely earlier) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 23:08:39 -0000 --tDYGg60iReQ7u8wj Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2010 at 08:56:13PM -0500, Brandon Gooch wrote: > On Fri, Oct 1, 2010 at 8:33 PM, David Wolfskill wr= ote: > > On Fri, Oct 01, 2010 at 04:30:01PM -0700, David Wolfskill wrote: > >> ... > >> I found the disabling the "Module Bay" appears to avoid the hang -- > >> reliably. > >> > >> That appears to be the minimally-invasive change necessary to avoid the > >> hang. > >> .... > > > > Until I realized what was in the Modular Bay: the CD/CVD reader/burner. > > > > So I tried a variation on the theme: =A0I left all the devices enabled, > > but I physically removed the device from the bay before booting -- and > > was unable to get it to fail. > > > > And -- just now -- I disabled the channel (via atacontrol(8)), inserted > > the drive, and enabled the channel: > ... > If you haven't already, it may be worth trying 'options ATA_CAM' in > your kernel config. As an illustration of the expression "a little knowledge is a dangerous thing," I relay the results of a recent experiment. The hardware on the laptop is AHCI-capable; after reading a bit (and recalling that fact about the hardware), then noting that my kernel config didn't include "device ahci", I tried loading ahci via /boot/loader.conf. I was pleased to note that the same device names were use as with ATA_CAM (disk drive was /dev/ada0), so no further change was needed to fstab. More to the point, I rebooted the machine at least 10 times in succession, and (again, so far!) was unable to re-create the "hang". I am still somewhat concerned that there may be a rather nasty issue with order-of-operations -- at least, in some cases -- and I'm quite willing to help identify the problem and test fixes. But so far, it *appears* that letting the ahci(4) driver attach may avoid the problem. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --tDYGg60iReQ7u8wj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkyqXhIACgkQmprOCmdXAD3MwgCfTnCtK/aycbofryrq2CsYmL/8 /4IAn2C/zCmOZqqjd/Sp3r4K6WVu6ati =XZCq -----END PGP SIGNATURE----- --tDYGg60iReQ7u8wj-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 23:45:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF326106564A; Mon, 4 Oct 2010 23:45:29 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 369A98FC19; Mon, 4 Oct 2010 23:45:28 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=2wVBBF9wa6oA:10 a=kj9zAlcOel0A:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=Kb1ui0xwIw8xraB3kp0A:9 a=w_xaAYqGnn05PGxHOxZxA4XtCvEA:4 a=CjuIK1q_8ugA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 30271879; Tue, 05 Oct 2010 01:45:27 +0200 Received-SPF: softfail receiver=mailfe05.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Tue, 5 Oct 2010 01:46:39 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?utf-8?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?utf-8?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7CoTlKM?= =?utf-8?q?usi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201010050146.39923.hselasky@freebsd.org> Cc: freebsd-current@freebsd.org Subject: FYI: USB 3.0 support and the XHCI driver is now fully committed to FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 23:45:29 -0000 http://svn.freebsd.org/changeset/base/213437 Please test if you have USB 3.0 hardware. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 00:38:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45DED10656A6; Tue, 5 Oct 2010 00:38:29 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id CB97A8FC0C; Tue, 5 Oct 2010 00:38:28 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 82BE112543B; Tue, 5 Oct 2010 09:38:26 +0900 (JST) Date: Tue, 5 Oct 2010 09:38:26 +0900 From: Daichi GOTO To: Garrett Cooper Message-Id: <20101005093826.17432b1e.daichi@ongs.co.jp> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 00:38:29 -0000 On Mon, 4 Oct 2010 07:19:45 -0700 Garrett Cooper wrote: > >> issues that might be occurring with the software, as per my copy of > >> SUSv4 (see the ERRORS section of fcntl). I would print out the > >> strerror for that case. > >>     Providing a backtrace of the application's execution and the > >> architecture and what version of FreeBSD you're using would be > >> helpful. > > I'm not even getting that far. Logs attached from both runs > (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). Yeah, it looks like the same situation. 1) mozc_server was killed lock file remains (even though it should be removed) 2) mozc_server try to boot 1. check lock file there 2. there is lock file, so cannot get lock file via fcntl 3. lock file means there is another mozc_server running, so mozc_server will stop boot and finish The cause of problem is that kernel does not remove lock file after mozc_server killed. Mozc developer explained me that fcntl will remove lock file after that process killed. But it looks like fnctl() does not remove lock file itself. According to FreeBSD fcntl(2) manual: All locks associated with a file for a given process are removed when the process terminates. No explanation lock file removing. Does FreeBSD fnctl(2) not remove lock file after process killed? Apparently from Mozc developer, Linux kernel removes lock files after process killed. > $ uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > Thu Aug 19 22:50:36 PDT 2010 > root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > I completely blasted past the part of your reply above where you > said your home directory is served up via NFS. It might be a problem > if you don't have lockd running (/etc/rc.d/lockd onestatus ? It isn't > enabled by default, and definitely isn't on on my machine) or the > mount isn't setup with lockd on the client side (nolockd will do this > on the initial mount, according to the manpage). There might be > `dragons' in the nfsd code that fail to do locking properly, but I > think that Rick (rmacklem@) or someone else on the list might be > better at answering whether or not things work from an NFS > perspective. server side: FreeBSD 7.3-PRERELEASE #0: Mon Mar 1 15:10:07 JST 2010 i386 rc.conf nfs_server_enable="YES" mountd_enable="YES" nfs_reserved_port_only="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" client side: FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 amd64 rc.conf: nfs_client_enable="YES" nfs_reserved_port_only="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" > I'd definitely divulge which version of NFS you're using as well > as what your NFS server and client are running if enabling lockd both > client and server side doesn't solve your problems right away. > Cheers, > -Garrett I have tested with ZFS because I was doubting NFS working well, but result was the same. (I didn't test with UFS.) Thanks truss output! From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 03:17:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1E78106566C; Tue, 5 Oct 2010 03:17:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A39EE8FC13; Tue, 5 Oct 2010 03:17:09 +0000 (UTC) Received: by iwn34 with SMTP id 34so931503iwn.13 for ; Mon, 04 Oct 2010 20:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=/ERprHhIg583y5L+Y5LSUftQcnUv5eY73L8qRpFQmfQ=; b=OARqQ+8jUxKLFD833qUjE/z83dn1yPJJj+CknxeBcxGofRO+OOU0DkJO2JqJOUkX/6 //v8YWK5p5owl8ZsM0vk4mK7r8+Ru/M3TNFrK45Ry2yhQ9XLqLB0rQfqkxNbK5je08J5 ZhkQr6bACepfz43jUUesB9Q0qdiEaaNWbyipc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SrmwKjK21j6lLVkwaA89mQ9jml+tsG6e1f5hUh3h6Qaw2VM7TQdE5hmzbcpgbBSCmo 63eIP8R+jACMJpdfzFqrgvtu8YN/2ffSq7toc42GU4Q1tXpoREtKUqMNCuX44Xcwk4A/ Hxma/C8Cdf9mM1Udy5ELmE1pM4iHRVqpBt55A= MIME-Version: 1.0 Received: by 10.231.160.17 with SMTP id l17mr11272294ibx.102.1286248628681; Mon, 04 Oct 2010 20:17:08 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Mon, 4 Oct 2010 20:17:08 -0700 (PDT) In-Reply-To: <20101005093826.17432b1e.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> Date: Mon, 4 Oct 2010 20:17:08 -0700 X-Google-Sender-Auth: 3KWLRms_3eyJB8TMeWGijBSD5NU Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: multipart/mixed; boundary=0050450157519afb400491d61878 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 03:17:10 -0000 --0050450157519afb400491d61878 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 4, 2010 at 5:38 PM, Daichi GOTO wrote: > On Mon, 4 Oct 2010 07:19:45 -0700 > Garrett Cooper wrote: >> >> issues that might be occurring with the software, as per my copy of >> >> SUSv4 (see the ERRORS section of fcntl). I would print out the >> >> strerror for that case. >> >> =A0 =A0 Providing a backtrace of the application's execution and the >> >> architecture and what version of FreeBSD you're using would be >> >> helpful. >> >> =A0 =A0 I'm not even getting that far. Logs attached from both runs >> (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). > > Yeah, it looks like the same situation. > > =A01) mozc_server was killed > =A0 =A0 =A0lock file remains =A0(even though it should be removed) > =A02) mozc_server try to boot > =A0 =A01. check lock file there > =A0 =A02. there is lock file, so cannot get lock file via fcntl > =A0 =A03. lock file means there is another mozc_server running, > =A0 =A0 =A0 so mozc_server will stop boot and finish Ok, weird. fstat on the file didn't yield anything nasty when I ran the app, and deleting the file in /tmp allowed the server to go a ways, then die, as opposed to die quickly, like what happened on the second try. > The cause of problem is that kernel does not remove lock file > after mozc_server killed. Mozc developer explained me that > fcntl will remove lock file after that process killed. But > it looks like fnctl() does not remove lock file itself. According > to FreeBSD fcntl(2) manual: > > =A0 =A0 All locks associated with a file for a given process are removed = when the > =A0 =A0 process terminates. > > No explanation lock file removing. Does FreeBSD fnctl(2) not remove lock = file > after process killed? =A0Apparently from Mozc developer, Linux kernel rem= oves > lock files after process killed. On Linux (RHEL 4.8): Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile --wxr-s--T 1 garrcoop eng 0 Oct 4 19:49 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Ok. This (EAGAIN) matches the Linux requirements specified in the manpage [1] I found, as well as the POSIX manpage [2]. The author is wrong about fcntl removing the file at exit though: $ ls -l /tmp/lockfile --wxr-s--T 1 garrcoop eng 0 Oct 4 19:49 /tmp/lockfile The file descriptor is closed though, so I can remove it at will: $ rm /tmp/lockfile $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory Following through the same process on FreeBSD... Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Well, lookie here! It locked as expected :). $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ rm /tmp/lockfile $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory So something else is going on with the application that needs to be resolved in that area. With that aside though, after modifying the test app a bit, I'm confused at the value of l_pid... Window 1: $ ./test_fcntl My pid: 5372 Window 2: $ ./test_fcntl My pid: 5373 test_fcntl: fcntl: Resource temporarily unavailable PID=3D1 has the lock Huh...? init has the file locked...? WTF?! So assuming Occam's Razor, I did a bit more reading and it turns out that l_pid is only populated when you call with F_GETLK: negative, l_start means end edge of the region. >>> The l_pid and l_s= ysid fields are only used with F_GETLK to return the process ID of the proc= ess holding a blocking lock and the system ID of the system that owns that process. Locks created by the local system will have a system ID of zero. <<< After a successful F_GETLK request, the value of l_whence i= s SEEK_SET. Thus, after fixing the test app I'm getting a sensical value: Window 1: $ ./test_fcntl My pid: 5394 Window 2: $ ./test_fcntl My pid: 5395 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=3D5394 has the lock Linux operates in the same manner: Window 1: $ ./test_fcntl My pid: 17861 Window 2: $ ./test_fcntl My pid: 17963 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=3D17861 has the lock Which I would expect because I'm not using anything exotic with fcntl(2) / open(2). I suspect mozc isn't properly initializing / calling fcntl(2), or the author used a non-POSIX extension that is implementation dependent and doesn't realize it (the Linux manpage has a pretty fat set of warnings about POSIX compatibility up at the top of the manpage). The developer might also want to use O_EXCL in the flags passed to open(2) as well, unless they want to lock specific sections in the file. Verified on UFS2 with SUJ. Test app attached. >> $ uname -a >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: >> Thu Aug 19 22:50:36 PDT 2010 >> root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =A0amd64 >> >> =A0 =A0 I completely blasted past the part of your reply above where you >> said your home directory is served up via NFS. It might be a problem >> if you don't have lockd running (/etc/rc.d/lockd onestatus ? It isn't >> enabled by default, and definitely isn't on on my machine) or the >> mount isn't setup with lockd on the client side (nolockd will do this >> on the initial mount, according to the manpage). There might be >> `dragons' in the nfsd code that fail to do locking properly, but I >> think that Rick (rmacklem@) or someone else on the list might be >> better at answering whether or not things work from an NFS >> perspective. > > server side: > =A0FreeBSD 7.3-PRERELEASE #0: Mon Mar =A01 15:10:07 JST 2010 i386 > =A0rc.conf > =A0 =A0nfs_server_enable=3D"YES" > =A0 =A0mountd_enable=3D"YES" > =A0 =A0nfs_reserved_port_only=3D"YES" > =A0 =A0rpc_lockd_enable=3D"YES" > =A0 =A0rpc_statd_enable=3D"YES" > > client side: > =A0FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 amd64 > =A0rc.conf: > =A0 =A0nfs_client_enable=3D"YES" > =A0 =A0nfs_reserved_port_only=3D"YES" > =A0 =A0rpc_lockd_enable=3D"YES" > =A0 =A0rpc_statd_enable=3D"YES" > >> =A0 =A0 I'd definitely divulge which version of NFS you're using as well >> as what your NFS server and client are running if enabling lockd both >> client and server side doesn't solve your problems right away. [...] > I have tested with ZFS because I was doubting NFS working well, > but result was the same. (I didn't test with UFS.) > > Thanks truss output! No problem :). Cheers, -Garrett [1] http://linux.die.net/man/2/fcntl [2] http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html --0050450157519afb400491d61878 Content-Type: application/octet-stream; name="test_fcntl.c" Content-Disposition: attachment; filename="test_fcntl.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gew700ol0 I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8ZXJyLmg+CiNpbmNsdWRlIDxlcnJuby5o PgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDx1bmlzdGQu aD4KCmludAptYWluKHZvaWQpCnsKCXN0cnVjdCBmbG9jayBmbG9jazsKCWludCBlcnJvciwgZmQ7 CgoJZmQgPSBvcGVuKCIvdG1wL2xvY2tmaWxlIiwgT19DUkVBVHxPX1dST05MWSk7CglpZiAoZmQg PT0gLTEpCgkJZXJyKDEsICJvcGVuIik7CgoJcHJpbnRmKCJNeSBwaWQ6ICVkXG4iLCBnZXRwaWQo KSk7CgoJZmxvY2subF90eXBlID0gRl9XUkxDSzsKCWZsb2NrLmxfc3RhcnQgPSAwOwoJZmxvY2su bF93aGVuY2UgPSBTRUVLX1NFVDsKCWZsb2NrLmxfbGVuID0gMDsKCglpZiAoZmNudGwoZmQsIEZf U0VUTEssICZmbG9jaykgPT0gLTEpIHsKCQllcnJvciA9IGVycm5vOwoJCXdhcm4oImZjbnRsWzFd Iik7CgkJaWYgKGVycm9yID09IEVBR0FJTikgewoJCQlpZiAoZmNudGwoZmQsIEZfR0VUTEssICZm bG9jaykgPT0gLTEpCgkJCQllcnIoMSwgImZjbnRsWzJdIik7CgkJCXByaW50ZigiUElEPSVkIGhh cyB0aGUgbG9ja1xuIiwgZmxvY2subF9waWQpOwoJCX0KCQlyZXR1cm4gKDEpOwoJfQoKCXdoaWxl ICgxKQoJCXNsZWVwKDEpOwoKCXJldHVybiAoMCk7Cgp9Cg== --0050450157519afb400491d61878-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 06:34:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63E13106564A; Tue, 5 Oct 2010 06:34:12 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 286B48FC15; Tue, 5 Oct 2010 06:34:12 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id E1F6A12543B; Tue, 5 Oct 2010 15:34:10 +0900 (JST) Date: Tue, 5 Oct 2010 15:34:10 +0900 From: Daichi GOTO To: Garrett Cooper Message-Id: <20101005153410.598e4484.daichi@ongs.co.jp> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 06:34:12 -0000 Thanks nice test tool :) And at last I got it excepting one mystery! On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper wrote: > Following through the same process on FreeBSD... > > Window 1: > $ ls -l /tmp/lockfile > ls: /tmp/lockfile: No such file or directory > $ ./test_fcntl > > Window 2: > > $ ls -l /tmp/lockfile > -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile > $ ./test_fcntl > test_fcntl: fcntl: Resource temporarily unavailable Just my mystery is as follow: Windows 1: % ./test_fcntl My pid: 43490 Windows 2: % ls -l /tmp/lockfile -r-sr-x--- 1 daichi wheel 0 10$B7n(B 5 15:02 /tmp/lockfile <--- is it weird, isn't it? % ./test_fcntl test_fcntl: open: Permission denied % Oops... What's wrong... /tmp is as follow: % mount | grep tmp /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) % dumpfs /tmp | grep journal flags soft-updates+journal % And working scene: Windows 2: % chmod u+w /tmp/lockfile % ls -l /tmp/lockfile -rwsr-x--- 1 daichi wheel 0 10$B7n(B 5 15:22 /tmp/lockfile % ./test_fcntl My pid: 43646 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=43490 has the lock % -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 06:56:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1F6106566C; Tue, 5 Oct 2010 06:56:12 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id A91358FC08; Tue, 5 Oct 2010 06:56:12 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 69B5812543B; Tue, 5 Oct 2010 15:39:26 +0900 (JST) Date: Tue, 5 Oct 2010 15:39:26 +0900 From: Daichi GOTO To: Garrett Cooper Message-Id: <20101005153926.88b4c1e1.daichi@freebsd.org> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> Organization: FreeBSD Project X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 06:56:13 -0000 Next step discussion engaged from this research I guess. Should we do change FreeBSD's fcntl(2) to return correct l_pid when called with F_SETLK? Or keep current behavior?? I want to hear other developers ideas and suggetions. On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper wrote: > test_fcntl: fcntl: Resource temporarily unavailable > PID=1 has the lock > > Huh...? init has the file locked...? WTF?! > So assuming Occam's Razor, I did a bit more reading and it turns > out that l_pid is only populated when you call with F_GETLK: > > negative, l_start means end edge of the region. >>> The l_pid and l_sysid > fields are only used with F_GETLK to return the process ID of the process > holding a blocking lock and the system ID of the system that owns that > process. Locks created by the local system will have a system ID of > zero. <<< After a successful F_GETLK request, the value of l_whence is > SEEK_SET. > > Thus, after fixing the test app I'm getting a sensical value: -- Daichi GOTO 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 08:23:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5EB3106567A; Tue, 5 Oct 2010 08:23:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 581238FC29; Tue, 5 Oct 2010 08:23:03 +0000 (UTC) Received: by iwn34 with SMTP id 34so1262281iwn.13 for ; Tue, 05 Oct 2010 01:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JArzsFFSJ+FuSoOj/DeBVyk0NpKJfyiUzmCHPEDBhXA=; b=UZVaAaz3QmuQ3+WzB0Ls+vUiQRs1opbqWyPVLfgr7hzqdaCwZcVN64LrB1UYujMxGW N8+xi+o/2x5LoN7DwPpvQHd1JNkCYZB9VhGojW9Iz6XALj9ur6tG/+YxkMKlWdskFXLi I5c/EO9YzZdwDPmFE0jo63+pefOovzDVLtw48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=m6gRg5oyzazzP0hg2kT1XI/xqulA7r7/f1ftGb4IFVlu9nZDihjvx3HrIDqTKZoSbS 6gklePBAZjGDs+O+cu1s4HTWWkQDqH/I8YWCR6jG2ymnXCxhJ862reIM1ZVg9Vxpa7G8 NciIQ2rAWGW0PxacBJUgeX4DhjyqKdWlweaT0= MIME-Version: 1.0 Received: by 10.231.19.197 with SMTP id c5mr11679456ibb.151.1286266982419; Tue, 05 Oct 2010 01:23:02 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 5 Oct 2010 01:23:02 -0700 (PDT) In-Reply-To: <20101005153410.598e4484.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> Date: Tue, 5 Oct 2010 01:23:02 -0700 X-Google-Sender-Auth: ph4VKMZ6u0Ndth8K4UhH-8EqFxM Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 08:23:03 -0000 2010/10/4 Daichi GOTO : > Thanks nice test tool :) =C2=A0And at last I got it excepting one mystery= ! > > On Mon, 4 Oct 2010 20:17:08 -0700 > Garrett Cooper wrote: >> Following through the same process on FreeBSD... >> >> Window 1: >> $ ls -l /tmp/lockfile >> ls: /tmp/lockfile: No such file or directory >> $ ./test_fcntl >> >> Window 2: >> >> $ ls -l /tmp/lockfile >> -rwsr-x--- =C2=A01 garrcoop =C2=A0wheel =C2=A00 Oct =C2=A04 20:14 /tmp/l= ockfile >> $ ./test_fcntl >> test_fcntl: fcntl: Resource temporarily unavailable > > Just my mystery is as follow: > > Windows 1: > % ./test_fcntl > My pid: 43490 > > Windows 2: > % ls -l /tmp/lockfile > -r-sr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:02 /= tmp/lockfile =C2=A0 =C2=A0<--- is it weird, isn't it? > % ./test_fcntl > test_fcntl: open: Permission denied > % > > Oops... What's wrong... /tmp is as follow: > > % mount | grep tmp > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) > % dumpfs /tmp | grep journal > flags =C2=A0 soft-updates+journal > % > > And working scene: > > Windows 2: > % chmod u+w /tmp/lockfile > % ls -l /tmp/lockfile > -rwsr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:22 /= tmp/lockfile > % ./test_fcntl > My pid: 43646 > test_fcntl: fcntl[1]: Resource temporarily unavailable > PID=3D43490 has the lock > % What's your umask and what are the permissions on /tmp? From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 08:55:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C4D8106566C; Tue, 5 Oct 2010 08:55:37 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id E94888FC29; Tue, 5 Oct 2010 08:55:36 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 2369412543B; Tue, 5 Oct 2010 17:55:36 +0900 (JST) Date: Tue, 5 Oct 2010 17:55:36 +0900 From: Daichi GOTO To: Garrett Cooper Message-Id: <20101005175536.a67998ae.daichi@ongs.co.jp> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 08:55:37 -0000 On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper wrote: > 2010/10/4 Daichi GOTO : > > Thanks nice test tool :)  And at last I got it excepting one mystery! > > > > On Mon, 4 Oct 2010 20:17:08 -0700 > > Garrett Cooper wrote: > >> Following through the same process on FreeBSD... > >> > >> Window 1: > >> $ ls -l /tmp/lockfile > >> ls: /tmp/lockfile: No such file or directory > >> $ ./test_fcntl > >> > >> Window 2: > >> > >> $ ls -l /tmp/lockfile > >> -rwsr-x---  1 garrcoop  wheel  0 Oct  4 20:14 /tmp/lockfile > >> $ ./test_fcntl > >> test_fcntl: fcntl: Resource temporarily unavailable > > > > Just my mystery is as follow: > > > > Windows 1: > > % ./test_fcntl > > My pid: 43490 > > > > Windows 2: > > % ls -l /tmp/lockfile > > -r-sr-x---  1 daichi  wheel  0 10月  5 15:02 /tmp/lockfile    <--- is it weird, isn't it? > > % ./test_fcntl > > test_fcntl: open: Permission denied > > % > > > > Oops... What's wrong... /tmp is as follow: > > > > % mount | grep tmp > > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) > > % dumpfs /tmp | grep journal > > flags   soft-updates+journal > > % > > > > And working scene: > > > > Windows 2: > > % chmod u+w /tmp/lockfile > > % ls -l /tmp/lockfile > > -rwsr-x---  1 daichi  wheel  0 10月  5 15:22 /tmp/lockfile > > % ./test_fcntl > > My pid: 43646 > > test_fcntl: fcntl[1]: Resource temporarily unavailable > > PID=43490 has the lock > > % > > What's your umask and what are the permissions on /tmp? % ll / | grep tmp drwxrwxrwt 14 root wheel 1024 10月 5 17:19 tmp % umask 022 % rm -f test % touch test % ll | grep test -rw-r--r-- 1 daichi wheel 0 10月 5 17:52 test % From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 08:56:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 713201065670; Tue, 5 Oct 2010 08:56:03 +0000 (UTC) (envelope-from i@levsha.me) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id CF7C68FC2E; Tue, 5 Oct 2010 08:56:02 +0000 (UTC) Received: from [178.92.255.63] (helo=laptop.levsha.me) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P32re-000K5n-AU; Tue, 05 Oct 2010 11:27:15 +0300 Received: from levsha by laptop.levsha.me with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P32rs-0002BU-EA; Tue, 05 Oct 2010 11:27:24 +0300 Date: Tue, 5 Oct 2010 11:27:24 +0300 From: Mykola Dzham To: kientzle@freebsd.org, freebsd-current@freebsd.org Message-ID: <20101005082723.GA2540@laptop.levsha.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Mykola Dzham X-SA-Exim-Connect-IP: 178.92.255.63 X-SA-Exim-Mail-From: i@levsha.me X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false Cc: Subject: bin/tar incorrectly parse '[^...]' patterns in --exclude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 08:56:03 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! bsd tar parse only '[!...]' as negate pattern, but gnu tar and bsd tar on 8-STABLE parse '[^...]' too: # uname -a FreeBSD laptop.levsha.me 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r212602M: Wed S= ep 15 04:50:20 EEST 2010 root@laptop.levsha.me:/usr/obj/usr/src/sys/LEV= SHA amd64 # tar --version bsdtar 2.8.3 - libarchive 2.7.901a # tar -tzvf test.tbz -rw-r--r-- 0 levsha levsha 0 Oct 5 01:27 a -rw-r--r-- 0 levsha levsha 0 Oct 5 01:27 b -rw-r--r-- 0 levsha levsha 0 Oct 5 01:27 c -rw-r--r-- 0 levsha levsha 0 Oct 5 01:27 d # tar -tzvf test.tbz --exclude '[!a]'=20 -rw-r--r-- 0 levsha levsha 0 Oct 5 01:27 a # tar -tzvf test.tbz --exclude '[^a]' -rw-r--r-- 0 levsha levsha 0 Oct 5 01:27 b -rw-r--r-- 0 levsha levsha 0 Oct 5 01:27 c -rw-r--r-- 0 levsha levsha 0 Oct 5 01:27 d # gtar -tzvf test.tbz --exclude '[^a]' -rw-r--r-- levsha/levsha 0 2010-10-05 01:27 a # # uname -a FreeBSD levsha.kiev.xxx.com.ua 8.1-STABLE FreeBSD 8.1-STABLE #10 r212252: M= on Sep 6 13:12:07 EEST 2010 root@levsha.kiev.xxx.com.ua:/usr/obj/usr/s= rc/sys/LEVSHA i386 # tar --version bsdtar 2.7.0 - libarchive 2.7.0 # tar -tzvf test.tbz -rw-r--r-- 0 levsha levsha 0 5 =D6=CF=D7 01:27 a -rw-r--r-- 0 levsha levsha 0 5 =D6=CF=D7 01:27 b -rw-r--r-- 0 levsha levsha 0 5 =D6=CF=D7 01:27 c -rw-r--r-- 0 levsha levsha 0 5 =D6=CF=D7 01:27 d # tar -tzvf test.tbz --exclude '[!a]' -rw-r--r-- 0 levsha levsha 0 5 =D6=CF=D7 01:27 a # tar -tzvf test.tbz --exclude '[^a]' -rw-r--r-- 0 levsha levsha 0 5 =D6=CF=D7 01:27 a #=20 Fix: Index: usr.bin/tar/pathmatch.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.bin/tar/pathmatch.c (revision 212602) +++ usr.bin/tar/pathmatch.c (working copy) @@ -35,7 +35,7 @@ =20 /* * Check whether a character 'c' is matched by a list specification [...]: - * * Leading '!' negates the class. + * * Leading '!' or '^' negates the class. * * - is a range of characters * * \ removes any special meaning for * @@ -60,7 +60,7 @@ (void)flags; /* UNUSED */ =20 /* If this is a negated class, return success for nomatch. */ - if (*p =3D=3D '!' && p < end) { + if ((*p =3D=3D '!' || *p =3D=3D '^') && p < end) { match =3D 0; nomatch =3D 1; ++p; --=20 LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iQEcBAEBAgAGBQJMquFqAAoJEH5nYZ5OcpKAAogH/2FkLl3MSbRIHVYrVfHllJUr mLRiSJAUXMezUHS+gZwELYDw0IikXL6RBDdbzruNoR/CvaGSML+qKw1s27PCADQx /6D5/JDVHd0oSQe/gMQhBJrxWnOnJSfo+o9YoK0Re5+AmZWtOuwv0vQtDqb2z0Qc VQun9lJ2lsiIF7w+NkX0O6AOYtWDSTl04UoPtj7hQcONvx32NxaqX3Lj2/garrFV lzAHXbaWJRGqnDt7bd/bpuVaBvqHWU3J8RySqALFkixTVUx3o7uObIeJpej596GV U2/y+gybKEXQVwwY2QSENOLhnlJnl1P7kIoYHCasH3z2eYmtfk89u2ef/JWUVyQ= =zRg9 -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 12:23:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFD771065673 for ; Tue, 5 Oct 2010 12:23:52 +0000 (UTC) (envelope-from kma@mrecic.gov.ar) Received: from mx1.mrecic.gov.ar (mx1.mrecic.gov.ar [200.16.99.221]) by mx1.freebsd.org (Postfix) with ESMTP id 550198FC0A for ; Tue, 5 Oct 2010 12:23:51 +0000 (UTC) Received: from mrelmx07.mrec.ar ([140.191.48.38]) by mx1.mrecic.gov.ar with ESMTP; 05 Oct 2010 09:23:50 -0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by mrelmx07.mrec.ar (Postfix) with ESMTP id B1F3371D2C; Tue, 5 Oct 2010 09:23:49 -0300 (ART) X-Virus-Scanned: amavisd-new at mrelmx07.mrec.ar Received: from mrelmx07.mrec.ar ([127.0.0.1]) by localhost (mrelmx07.mrec.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js+2xZ5nm4Hm; Tue, 5 Oct 2010 09:23:49 -0300 (ART) Received: from mrelmx06.mrec.ar (mrelmx10.mrec.ar [140.191.48.45]) by mrelmx07.mrec.ar (Postfix) with ESMTP id 411E871D2B; Tue, 5 Oct 2010 09:23:49 -0300 (ART) Date: Tue, 5 Oct 2010 08:23:49 -0400 (EDT) From: Kevin Mai To: Stefan Bethke Message-ID: <1789917369.70927.1286281429036.JavaMail.root@mrelmx10.mrec.ar> In-Reply-To: <98D95524-D229-49F0-8738-DD5111F22FD8@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [200.16.110.42] X-Mailer: Zimbra 6.0.6_GA_2330.DEBIAN5_64 (ZimbraWebClient - FF3.0 (Win)/6.0.6_GA_2330.DEBIAN5_64) Cc: freebsd-current Subject: Re: Issues after running make installworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 12:23:52 -0000 Dankesch=C3=B6n Herr Bethke! I have already figured this out, it was an issue with flags (don't really u= nderstand why those files had those flags, as I never worked with schg flag= s on this system.. ----- Mensaje original ----- De: "Stefan Bethke" Para: "Kevin Mai" CC: "freebsd-current" Enviados: Lunes, 4 de Octubre 2010 17:43:22 Asunto: Re: Issues after running make installworld Am 04.10.2010 um 21:23 schrieb Kevin Mai: > I've just tried to do a make installworld DESTDIR=3D$jail1 where > jail1=3D'/var/lib/jail1' and I changed my mind. > > I tried to delete the folder but it seems somehow some ACLs got > between. I don't think installworld does anything with ACLs. What's the actual error message from what command? What revision of -current are you using? What type of filesystem is /var/lib/jail1, which options was it created with, and how is it mounted? It's most likely the flags (see chflags(8)), so try chflags -R noschg /var/lib/jail1. Stefan p.s. such questions are more appropriate on freebsd-questions@. -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 12:35:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0E7A1065670 for ; Tue, 5 Oct 2010 12:35:39 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 354E58FC1B for ; Tue, 5 Oct 2010 12:35:38 +0000 (UTC) Received: by wyb29 with SMTP id 29so5546975wyb.13 for ; Tue, 05 Oct 2010 05:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PAxsJsl0MS4DjjmEfLYSl68m6hneDt7wjcHyl+GIL6E=; b=Djttq2CYI+pbzG8DioTpFXyOg0T+NyH72ILFwZ1x/7ejLTWBN9aiNKonNXYxdd2/fJ W9kjmY249ivd2TFbMYRZ7yn5731EesdeDu21EQWoqPktVL1N11jUGDZ2nvtOjge71V8J 4yElxrNB5aOIfz1xAKAhZoDnqK2d4g8FC8HXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W9KEupI+0v21+HI3BqaiW54YB3hCm+NwrTSq32z5ipcS7aOjNLli3lwlFtigxjiuW6 BG9foZK9e8U/1zHC4IBnEo0G2SAxglLsOALrQMdNSWEpaxQETUYC9j5xNiMD+4muiSXs LI/5ORKgWEJfJAO6g6rAfmk/s1Ef6TAcuAUlk= MIME-Version: 1.0 Received: by 10.216.150.195 with SMTP id z45mr975028wej.63.1286282138049; Tue, 05 Oct 2010 05:35:38 -0700 (PDT) Received: by 10.216.172.210 with HTTP; Tue, 5 Oct 2010 05:35:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Oct 2010 14:35:38 +0200 Message-ID: From: Svatopluk Kraus To: Matthew Fleming Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: CACHE_LINE_SIZE too small, so struct vpglocks size alignment doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 12:35:39 -0000 On Fri, Oct 1, 2010 at 4:01 PM, Matthew Fleming wrote: > On Fri, Oct 1, 2010 at 1:00 PM, Svatopluk Kraus wrote: >> Hallo, >> >> =A0a size of 'struct vpglocks' is padded to CACHE_LINE_SIZE size in >> 'sys/vm/vm_page.h' >> header file. I work on a 'coldfire' port where CACHE_LINE_SIZE is 16 byt= es and >> sizeof(struct mtx) is 20 bytes thus size alignment doesn't work. >> >> =A0I solved it somehow, but I like to learn how to solve it in spirit >> of FreeBSD. >> There are a couple of possibilities: >> >> A1. Do nothing for small CACHE_LINE_SIZE. >> A2. Pad to multiple of CACHE_LINE_SIZE. >> >> B1. use #if with CACHE_LINE_SIZE >> B2. use #if with __coldfire__ >> >> When I use B1 solution I need to known sizeof(struct mtx) value in >> preprocessing time. >> So, is it correct to use something like 'assym.s' magic >> (sys/i386/i386/genassym.c) >> in MI code? Or has someone another suggestion? > > What about padding to CACHE_LINE_SIZE - (sizeof(struct vpglocks) & > (CACHE_LINE_SIZE-1)) ? > > Some compilers will complain about 0-sized arrays, but gcc isn't one of t= hem. > > Cheers, > matthew Thanks for your nice suggestion. Probably, CACHE_LINE_SIZE size is a multiple of 2 at all times, so your solution is applicable. BTW, I use gcc 4.5.1 and when a structure is aligned to a value, then a sizeof of the structure is padded to the value too implicitly. So no explicit padding is needed. Cheers, Svata From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 12:43:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF0FB106564A; Tue, 5 Oct 2010 12:43:43 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82F4B8FC1B; Tue, 5 Oct 2010 12:43:43 +0000 (UTC) Received: by yxn35 with SMTP id 35so2527233yxn.13 for ; Tue, 05 Oct 2010 05:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gSWKjBZ89rEQrEGLTxOpe+85VZ+DSVWvGzWsfjpWwuE=; b=VTzkxRkZMUp5cH+HA0AooqowVBJ1gtWbiJw+sMcFiRrNITSp2seG80Hl2LfFdl5Hpj 13IBJBO6BJGkOPTNHe/UAiwBfXtY2P5D03OCzNsuab/7A4+Kk0XmGrLxq6u6gwfHzKXy UYq5hRQ5k2vOWmZmI/m2DD9faCpXIqx1MbO6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qsf9ZWQ4NVaI2EFeH+GZsSMtzcbbq1LrsNzhud6a7eNKCkoWe52Ud89qXtYM7KLhQn WLHeOiBIMFt3qyi4QNLCTwoczOW5tlC/XJ/lxKMHh7It2VtSgqxayDeHO3WhPNHiQ34+ oNL5HNsZxlEzRODh3PP7x1jnb7FL74vU31i5A= MIME-Version: 1.0 Received: by 10.101.175.18 with SMTP id c18mr7892981anp.98.1286281140423; Tue, 05 Oct 2010 05:19:00 -0700 (PDT) Received: by 10.220.191.139 with HTTP; Tue, 5 Oct 2010 05:19:00 -0700 (PDT) In-Reply-To: <47E32F6D-498C-4706-8AD6-355F9BD7887C@FreeBSD.org> References: <7459633.69735.1286214361816.JavaMail.root@mrelmx10.mrec.ar> <47E32F6D-498C-4706-8AD6-355F9BD7887C@FreeBSD.org> Date: Tue, 5 Oct 2010 22:49:00 +1030 Message-ID: From: Matt Thyer To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Kevin Mai Subject: Re: Multithread Make in multicore server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 12:43:44 -0000 On 5 October 2010 04:53, Rui Paulo wrote: > On 4 Oct 2010, at 18:46, Kevin Mai wrote: > > I see that there's no multithreading when running make.. is there a way > to enable multiprocessing when running make? > > Try 'make -j16 buildworld'. 16 is the maximum number of parallels processes > that make is going to run. > Try -j32 or even -j48 and let us know which is faster. -j16 will still show lots of idle time. From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 14:52:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECA63106566C; Tue, 5 Oct 2010 14:52:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBA98FC13; Tue, 5 Oct 2010 14:52:10 +0000 (UTC) Received: by iwn34 with SMTP id 34so1721279iwn.13 for ; Tue, 05 Oct 2010 07:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=B6iy/Zws2i8RacFvzW4QWA/COTEl4rMxqVbeg/0B6C0=; b=Z3Mu5r9KR7GXr1gCRlVrCeSUEF5TbwrMdPGC7xve+fpKTyvkSRwlFUBWlW8YUeP8H+ KieS61y8WPJdO06Qtw1n0iKFD6FXucPF0QByqXpEkalpQcS7y6wSP5Cu+QhD2uvLKGt0 1hWPbg+bGXqS5LqK9r+Z11NShP9AqjNK+F9IA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GiHI64FdHWNdWd+kFK1k5or7fPbQ1zPMFPRhD2hb3x/C9XRDcPq/Y2YjyX8WbTLkEk r5rcsY9nE5frlBFwXlwiqFxRl9vKxGWTj2btmaq/y7dCogti2t6NRFSpJr9/dKFZwBij eZwGvbOQXgw+d8FF4sDuci6yLbJBUJI7JV8JE= MIME-Version: 1.0 Received: by 10.231.170.21 with SMTP id b21mr12233750ibz.122.1286290330040; Tue, 05 Oct 2010 07:52:10 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 5 Oct 2010 07:52:10 -0700 (PDT) In-Reply-To: <20101005175536.a67998ae.daichi@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> Date: Tue, 5 Oct 2010 07:52:10 -0700 X-Google-Sender-Auth: fZE9pnABiLTA_pqXjSeeX6N6ao4 Message-ID: From: Garrett Cooper To: Daichi GOTO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:52:11 -0000 On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO wrote: > On Tue, 5 Oct 2010 01:23:02 -0700 > Garrett Cooper wrote: >> 2010/10/4 Daichi GOTO : >> > Thanks nice test tool :) =C2=A0And at last I got it excepting one myst= ery! >> > >> > On Mon, 4 Oct 2010 20:17:08 -0700 >> > Garrett Cooper wrote: >> >> Following through the same process on FreeBSD... >> >> >> >> Window 1: >> >> $ ls -l /tmp/lockfile >> >> ls: /tmp/lockfile: No such file or directory >> >> $ ./test_fcntl >> >> >> >> Window 2: >> >> >> >> $ ls -l /tmp/lockfile >> >> -rwsr-x--- =C2=A01 garrcoop =C2=A0wheel =C2=A00 Oct =C2=A04 20:14 /tm= p/lockfile >> >> $ ./test_fcntl >> >> test_fcntl: fcntl: Resource temporarily unavailable >> > >> > Just my mystery is as follow: >> > >> > Windows 1: >> > % ./test_fcntl >> > My pid: 43490 >> > >> > Windows 2: >> > % ls -l /tmp/lockfile >> > -r-sr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:0= 2 /tmp/lockfile =C2=A0 =C2=A0<--- is it weird, isn't it? >> > % ./test_fcntl >> > test_fcntl: open: Permission denied >> > % >> > >> > Oops... What's wrong... /tmp is as follow: >> > >> > % mount | grep tmp >> > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >> > % dumpfs /tmp | grep journal >> > flags =C2=A0 soft-updates+journal >> > % >> > >> > And working scene: >> > >> > Windows 2: >> > % chmod u+w /tmp/lockfile >> > % ls -l /tmp/lockfile >> > -rwsr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:2= 2 /tmp/lockfile >> > % ./test_fcntl >> > My pid: 43646 >> > test_fcntl: fcntl[1]: Resource temporarily unavailable >> > PID=3D43490 has the lock >> > % >> >> What's your umask and what are the permissions on /tmp? > > % ll / | grep tmp > drwxrwxrwt =C2=A014 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A01024 10=E6=9C=88= =C2=A05 17:19 tmp > % umask > 022 > % rm -f test > % touch test > % ll | grep test > -rw-r--r-- =C2=A0 1 daichi =C2=A0wheel =C2=A0 =C2=A0 0 10=E6=9C=88 =C2=A0= 5 17:52 test > % The permissions look ok from my perspective, but the umask is different, so you might want to try my umask to make sure that your results match mine (and we need to check the requirements to determine whether or not the behavior for FreeBSD's umask syscall is correct): $ ls -la /tmp/ | head -n 2 total 462686 drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . $ umask 0022 Where and how is /tmp mounted (is it a real partition, what filesystem, etc)? BTW, when I change my umask to match your's I don't get the same results you do on my home machine: Window 1: $ umask 022 $ ./test_fcntl My pid: 17353 Window 2: $ ./test_fcntl My pid: 17356 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=3D17353 has the lock $ ls -l /tmp/lockfile -rwSr----- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile Just to note, the tests before were run on the RHEL 4.8 box with the following info, and the FreeBSD box with the following info: Red Hat Enterprise Linux AS release 4 (Nahant Update 8) Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r211767M: Sat Aug 28 00:28:45 PDT 2010 garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 The tests above were run on a FreeBSD box with the following info: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 On bayonetta /tmp is SUJ backed (probably should change that though), and on bioshock it's not SUJ backed. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 15:58:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84E1E106566C; Tue, 5 Oct 2010 15:58:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 241D08FC17; Tue, 5 Oct 2010 15:58:07 +0000 (UTC) Received: by iwn34 with SMTP id 34so1803829iwn.13 for ; Tue, 05 Oct 2010 08:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RAqk0+SeSYAJNS6EGKSvPed6R9+QoyAAlt1ANPDSOZo=; b=rHAFEpqThKQXseEBYDhs/Ul/UKwPMlubo5w0J2btLkLrlI3G7aLPc+iBOhIKMWUa7K 5Gi+wLVFseF0Evd6gXnpMUSvu1WY5/L1dde/MGo+cWo+6vEN3OrmqsD4s02j8pcQ3P9B aZFBBe6zNlvqkAHxJgNDnfKhKTPSq25iMb5+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=F+gYod09XdZE8gHa4A3i9PRcYqrL/Yp/p0vEZUHMF9G+2jSvE6TpfKxgegbcdKG7lx gLgvH9dYl/I1dTu4neTmWSLPXpN+cAxlqz7B9L3r0nru3MwMu6o0XLJp2HP7ZCcdO2hI UOqtF/1gpIEYm3uOzXPumGuuFtYvgLassKusE= MIME-Version: 1.0 Received: by 10.231.183.10 with SMTP id ce10mr12373147ibb.96.1286294287204; Tue, 05 Oct 2010 08:58:07 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 5 Oct 2010 08:58:07 -0700 (PDT) In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> Date: Tue, 5 Oct 2010 08:58:07 -0700 X-Google-Sender-Auth: H6sxQwLzCHNKeat0qtNKlqCf_AE Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Daichi GOTO Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 15:58:08 -0000 On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO wrote: >> On Tue, 5 Oct 2010 01:23:02 -0700 >> Garrett Cooper wrote: >>> 2010/10/4 Daichi GOTO : >>> > Thanks nice test tool :) =C2=A0And at last I got it excepting one mys= tery! >>> > >>> > On Mon, 4 Oct 2010 20:17:08 -0700 >>> > Garrett Cooper wrote: >>> >> Following through the same process on FreeBSD... >>> >> >>> >> Window 1: >>> >> $ ls -l /tmp/lockfile >>> >> ls: /tmp/lockfile: No such file or directory >>> >> $ ./test_fcntl >>> >> >>> >> Window 2: >>> >> >>> >> $ ls -l /tmp/lockfile >>> >> -rwsr-x--- =C2=A01 garrcoop =C2=A0wheel =C2=A00 Oct =C2=A04 20:14 /t= mp/lockfile >>> >> $ ./test_fcntl >>> >> test_fcntl: fcntl: Resource temporarily unavailable >>> > >>> > Just my mystery is as follow: >>> > >>> > Windows 1: >>> > % ./test_fcntl >>> > My pid: 43490 >>> > >>> > Windows 2: >>> > % ls -l /tmp/lockfile >>> > -r-sr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:= 02 /tmp/lockfile =C2=A0 =C2=A0<--- is it weird, isn't it? >>> > % ./test_fcntl >>> > test_fcntl: open: Permission denied >>> > % >>> > >>> > Oops... What's wrong... /tmp is as follow: >>> > >>> > % mount | grep tmp >>> > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >>> > % dumpfs /tmp | grep journal >>> > flags =C2=A0 soft-updates+journal >>> > % >>> > >>> > And working scene: >>> > >>> > Windows 2: >>> > % chmod u+w /tmp/lockfile >>> > % ls -l /tmp/lockfile >>> > -rwsr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15:= 22 /tmp/lockfile >>> > % ./test_fcntl >>> > My pid: 43646 >>> > test_fcntl: fcntl[1]: Resource temporarily unavailable >>> > PID=3D43490 has the lock >>> > % >>> >>> What's your umask and what are the permissions on /tmp? >> >> % ll / | grep tmp >> drwxrwxrwt =C2=A014 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A01024 10=E6=9C= =88 =C2=A05 17:19 tmp >> % umask >> 022 >> % rm -f test >> % touch test >> % ll | grep test >> -rw-r--r-- =C2=A0 1 daichi =C2=A0wheel =C2=A0 =C2=A0 0 10=E6=9C=88 =C2= =A05 17:52 test >> % > > =C2=A0 =C2=A0The permissions look ok from my perspective, but the umask i= s > different, so you might want to try my umask to make sure that your > results match mine (and we need to check the requirements to determine > whether or not the behavior for FreeBSD's umask syscall is correct): > > $ ls -la /tmp/ | head -n 2 > total 462686 > drwxrwxrwt =C2=A051 root =C2=A0 =C2=A0 wheel =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 11776 Oct =C2=A05 03:11 . > $ umask > 0022 > > =C2=A0 =C2=A0Where and how is /tmp mounted (is it a real partition, what > filesystem, etc)? > =C2=A0 =C2=A0BTW, when I change my umask to match your's I don't get the = same > results you do on my home machine: > > Window 1: > > $ umask 022 > $ ./test_fcntl > My pid: 17353 > > Window 2: > > $ ./test_fcntl > My pid: 17356 > test_fcntl: fcntl[1]: Resource temporarily unavailable > PID=3D17353 has the lock > $ ls -l /tmp/lockfile > -rwSr----- =C2=A01 gcooper =C2=A0wheel =C2=A00 Oct =C2=A05 07:49 /tmp/loc= kfile > > =C2=A0 =C2=A0Just to note, the tests before were run on the RHEL 4.8 box = with > the following info, and the FreeBSD box with the following info: > > Red Hat Enterprise Linux AS release 4 (Nahant Update 8) > Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT > 2009 x86_64 x86_64 x86_64 GNU/Linux > > FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 > r211767M: Sat Aug 28 00:28:45 PDT 2010 > garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK =C2=A0amd64 > > =C2=A0 =C2=A0The tests above were run on a FreeBSD box with the following= info: > > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > Thu Aug 19 22:50:36 PDT 2010 > root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =C2=A0amd64 > > =C2=A0 =C2=A0On bayonetta /tmp is SUJ backed (probably should change that > though), and on bioshock it's not SUJ backed. And while this might be a good mental exercise, I think we're missing the original point of your bug: You were getting ECONNREFUSED because a socket was in `use', even though all instances of mozc_server were dead (at least that's the case with me). So the question I guess that's worth asking is: 1. What process/application does it need to establish a Unix style socket w= ith? 2. Why isn't that socket being cleaned up by the OS at exit? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 17:09:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83EF3106566B; Tue, 5 Oct 2010 17:09:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 24FF58FC12; Tue, 5 Oct 2010 17:09:19 +0000 (UTC) Received: by iwn34 with SMTP id 34so1892686iwn.13 for ; Tue, 05 Oct 2010 10:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ecVuMdFNpCr0ADGRJnGUVWQA6DxDKlhAJIkZry85au4=; b=rMHCLvb7njYctbm3+xjlH2N5hgq8HcR3/Ee/hh4CvqlJSKEnChioIJU1WkWFAQ3Ma9 OatVGloDgH4vQA+tViLq9SFf6BxslLh/WitpvA/W4EqEwv55u96Sz1YH+j8c+0uCj54N iHH1fqnL/xMYPeLOuOAW5KFNo4L0izS5X10gM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=I3oym9Vtv0GcN6LoarXn5voTMSQQ5A10VE7/Rk2+yK4caUlIih95rjzyYKUIa2rOcJ dF8SqfQM3PN4mAacV2MYTXOia2f7guLn+vrrcXiy+TP3aP5HvP9TwB43X2ZLhNi8bSJ3 fmx0kUb78wW4qRAijUr17dnetPUCf9zSb1SR4= MIME-Version: 1.0 Received: by 10.231.170.208 with SMTP id e16mr12462933ibz.44.1286298558688; Tue, 05 Oct 2010 10:09:18 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 5 Oct 2010 10:09:18 -0700 (PDT) In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> Date: Tue, 5 Oct 2010 10:09:18 -0700 X-Google-Sender-Auth: Gf6mQNSXTqDyWTkOG8_fb_kYWrs Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Daichi GOTO Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:09:19 -0000 On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper wrot= e: >> On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO wrote: >>> On Tue, 5 Oct 2010 01:23:02 -0700 >>> Garrett Cooper wrote: >>>> 2010/10/4 Daichi GOTO : >>>> > Thanks nice test tool :) =C2=A0And at last I got it excepting one my= stery! >>>> > >>>> > On Mon, 4 Oct 2010 20:17:08 -0700 >>>> > Garrett Cooper wrote: >>>> >> Following through the same process on FreeBSD... >>>> >> >>>> >> Window 1: >>>> >> $ ls -l /tmp/lockfile >>>> >> ls: /tmp/lockfile: No such file or directory >>>> >> $ ./test_fcntl >>>> >> >>>> >> Window 2: >>>> >> >>>> >> $ ls -l /tmp/lockfile >>>> >> -rwsr-x--- =C2=A01 garrcoop =C2=A0wheel =C2=A00 Oct =C2=A04 20:14 /= tmp/lockfile >>>> >> $ ./test_fcntl >>>> >> test_fcntl: fcntl: Resource temporarily unavailable >>>> > >>>> > Just my mystery is as follow: >>>> > >>>> > Windows 1: >>>> > % ./test_fcntl >>>> > My pid: 43490 >>>> > >>>> > Windows 2: >>>> > % ls -l /tmp/lockfile >>>> > -r-sr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15= :02 /tmp/lockfile =C2=A0 =C2=A0<--- is it weird, isn't it? >>>> > % ./test_fcntl >>>> > test_fcntl: open: Permission denied >>>> > % >>>> > >>>> > Oops... What's wrong... /tmp is as follow: >>>> > >>>> > % mount | grep tmp >>>> > /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >>>> > % dumpfs /tmp | grep journal >>>> > flags =C2=A0 soft-updates+journal >>>> > % >>>> > >>>> > And working scene: >>>> > >>>> > Windows 2: >>>> > % chmod u+w /tmp/lockfile >>>> > % ls -l /tmp/lockfile >>>> > -rwsr-x--- =C2=A01 daichi =C2=A0wheel =C2=A00 10=E6=9C=88 =C2=A05 15= :22 /tmp/lockfile >>>> > % ./test_fcntl >>>> > My pid: 43646 >>>> > test_fcntl: fcntl[1]: Resource temporarily unavailable >>>> > PID=3D43490 has the lock >>>> > % >>>> >>>> What's your umask and what are the permissions on /tmp? >>> >>> % ll / | grep tmp >>> drwxrwxrwt =C2=A014 root =C2=A0wheel =C2=A0 =C2=A0 =C2=A01024 10=E6=9C= =88 =C2=A05 17:19 tmp >>> % umask >>> 022 >>> % rm -f test >>> % touch test >>> % ll | grep test >>> -rw-r--r-- =C2=A0 1 daichi =C2=A0wheel =C2=A0 =C2=A0 0 10=E6=9C=88 =C2= =A05 17:52 test >>> % >> >> =C2=A0 =C2=A0The permissions look ok from my perspective, but the umask = is >> different, so you might want to try my umask to make sure that your >> results match mine (and we need to check the requirements to determine >> whether or not the behavior for FreeBSD's umask syscall is correct): >> >> $ ls -la /tmp/ | head -n 2 >> total 462686 >> drwxrwxrwt =C2=A051 root =C2=A0 =C2=A0 wheel =C2=A0 =C2=A0 =C2=A0 =C2=A0= 11776 Oct =C2=A05 03:11 . >> $ umask >> 0022 >> >> =C2=A0 =C2=A0Where and how is /tmp mounted (is it a real partition, what >> filesystem, etc)? >> =C2=A0 =C2=A0BTW, when I change my umask to match your's I don't get the= same >> results you do on my home machine: >> >> Window 1: >> >> $ umask 022 >> $ ./test_fcntl >> My pid: 17353 >> >> Window 2: >> >> $ ./test_fcntl >> My pid: 17356 >> test_fcntl: fcntl[1]: Resource temporarily unavailable >> PID=3D17353 has the lock >> $ ls -l /tmp/lockfile >> -rwSr----- =C2=A01 gcooper =C2=A0wheel =C2=A00 Oct =C2=A05 07:49 /tmp/lo= ckfile >> >> =C2=A0 =C2=A0Just to note, the tests before were run on the RHEL 4.8 box= with >> the following info, and the FreeBSD box with the following info: >> >> Red Hat Enterprise Linux AS release 4 (Nahant Update 8) >> Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT >> 2009 x86_64 x86_64 x86_64 GNU/Linux >> >> FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 >> r211767M: Sat Aug 28 00:28:45 PDT 2010 >> garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK =C2=A0amd64 >> >> =C2=A0 =C2=A0The tests above were run on a FreeBSD box with the followin= g info: >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: >> Thu Aug 19 22:50:36 PDT 2010 >> root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =C2=A0amd64 >> >> =C2=A0 =C2=A0On bayonetta /tmp is SUJ backed (probably should change tha= t >> though), and on bioshock it's not SUJ backed. > > And while this might be a good mental exercise, I think we're missing > the original point of your bug: > > You were getting ECONNREFUSED because a socket was in `use', even > though all instances of mozc_server were dead (at least that's the > case with me). So the question I guess that's worth asking is: Statement incorrect: socket wasn't in use. The logic needs to be rewritten to account for this case and setup the socket again if this occurs. It would be a good idea to do this if the file wasn't locked. > 1. What process/application does it need to establish a Unix style socket= with? > 2. Why isn't that socket being cleaned up by the OS at exit? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 20:18:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B73106566B; Tue, 5 Oct 2010 20:18:59 +0000 (UTC) (envelope-from pyunyh@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 B2E2C8FC17; Tue, 5 Oct 2010 20:18:59 +0000 (UTC) Received: by pzk7 with SMTP id 7so93406pzk.13 for ; Tue, 05 Oct 2010 13:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=7nTfMGq1eShS6vBqCmN+wyU1U2ECqUy92oOk983RS5I=; b=PG7rpRvd8n2RZZ4pgRy1RgXbZEpjLOe+KavLa9LsjthMiA3CmSACG3o2gFzxhxzRX0 UQS4SMN1Gf3plVploULiflB/RPLIidU3Fk8qGo6Vlm5VvJ6cLytPtkDe1QQQc7Tevz1A 5OR7hfQVtUEv2vAz0BdQWH7yyP5o2p7BmQcQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=DKJ4r9pGCq5n30FnCoXyChHYMnDYv5Ikp4ZjrKpsBgJ44T28O8ekcOw+0gaSqL76kE 777Awa3hJGwMgKleHuc4Nx+XGfA7Xx3NS+06CaNTgtZGT12uaxnYe3Tjm2M1Nm9g7OKN VavNKtDsSHK91Svd1sTXmvOU88U4BIACKlYJY= Received: by 10.115.77.17 with SMTP id e17mr14336323wal.108.1286309939099; Tue, 05 Oct 2010 13:18:59 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q6sm12013099waj.22.2010.10.05.13.18.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 Oct 2010 13:18:57 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 5 Oct 2010 13:17:11 -0700 From: Pyun YongHyeon Date: Tue, 5 Oct 2010 13:17:11 -0700 To: Mark Atkinson Message-ID: <20101005201711.GD9920@michelle.cdnetworks.com> References: <201010050146.39923.hselasky@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: FYI: USB 3.0 support and the XHCI driver is now fully committed to FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 20:19:00 -0000 On Tue, Oct 05, 2010 at 11:39:33AM -0700, Mark Atkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 10/05/2010 10:09, Mark Atkinson wrote: > > Root mount waiting for: usbus3 usbus0 > > [hang, waits forever...] > > Well reverting to r213377 exhibits similar behavior, so I guess this is > not suspect. I'll keep reverting until I find the breakage. It seems I also see the similar behavior. Booting to single user and going back to single user does not work. But USB keyboard still seems to work. From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 22:23:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A929C1065675; Tue, 5 Oct 2010 22:23:19 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 242A78FC0A; Tue, 5 Oct 2010 22:23:18 +0000 (UTC) Received: by wyb29 with SMTP id 29so6354460wyb.13 for ; Tue, 05 Oct 2010 15:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.141.138 with SMTP id m10mr10335258wbu.20.1286316094472; Tue, 05 Oct 2010 15:01:34 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.227.141.76 with HTTP; Tue, 5 Oct 2010 15:01:34 -0700 (PDT) In-Reply-To: References: <201010050146.39923.hselasky@freebsd.org> Date: Wed, 6 Oct 2010 11:01:34 +1300 X-Google-Sender-Auth: M1gy50heQby705Xyh3o4JcCZLGM Message-ID: From: Andrew Thompson To: Mark Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: FYI: USB 3.0 support and the XHCI driver is now fully committed to FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 22:23:19 -0000 On 6 October 2010 10:58, Mark Atkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/05/2010 11:39, Mark Atkinson wrote: >> >> >> On 10/05/2010 10:09, Mark Atkinson wrote: >>> Root mount waiting for: usbus3 usbus0 >>> [hang, waits forever...] >> >> Well reverting to r213377 exhibits similar behavior, so I guess this is >> not suspect. =A0I'll keep reverting until I find the breakage. > > Wish I had kept his machine on a closer track with current: > > r212532: working > r212553: fail > r212541 seems to be the only likely candidate between these ranges. Maybe you could try before and after. Andrew From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 23:00:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6094B1065670 for ; Tue, 5 Oct 2010 23:00:05 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-19.mx.aerioconnect.net [216.240.47.79]) by mx1.freebsd.org (Postfix) with ESMTP id 380918FC1B for ; Tue, 5 Oct 2010 23:00:05 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o95MbXEC009518; Tue, 5 Oct 2010 15:37:33 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id DE3502D6014; Tue, 5 Oct 2010 15:37:31 -0700 (PDT) Message-ID: <4CABA8DB.4050902@freebsd.org> Date: Tue, 05 Oct 2010 15:38:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Mark Atkinson References: <201010050146.39923.hselasky@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: FYI: USB 3.0 support and the XHCI driver is now fully committed to FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 23:00:05 -0000 On 10/5/10 2:58 PM, Mark Atkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/05/2010 11:39, Mark Atkinson wrote: >> >> On 10/05/2010 10:09, Mark Atkinson wrote: >>> Root mount waiting for: usbus3 usbus0 >>> [hang, waits forever...] >> Well reverting to r213377 exhibits similar behavior, so I guess this is >> not suspect. I'll keep reverting until I find the breakage. > Wish I had kept his machine on a closer track with current: > > r212532: working > r212553: fail > > I'm currently suspecting the one-shot timers are causing this box to hang. -current hangs around there on boot under Xen. setting kern.eventtimers.periodic=1 from the boot prompt allows it to continue. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkyrn3cACgkQrDN5kXnx8yba5wCdGOkoUzm7nnJQQfj2Tc3v5Ptg > +xYAnRgcOL3HqjGbm9hAVrpotjg0lLOa > =PA/u > -----END PGP SIGNATURE----- > > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Oct 6 02:02:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0299C106567A for ; Wed, 6 Oct 2010 02:02:59 +0000 (UTC) (envelope-from alexander@kojevnikov.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id C01A28FC0A for ; Wed, 6 Oct 2010 02:02:58 +0000 (UTC) Received: by qyk4 with SMTP id 4so122139qyk.13 for ; Tue, 05 Oct 2010 19:02:57 -0700 (PDT) Received: by 10.224.51.218 with SMTP id e26mr8124360qag.342.1286330576879; Tue, 05 Oct 2010 19:02:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.84.73 with HTTP; Tue, 5 Oct 2010 19:02:36 -0700 (PDT) From: Alexander Kojevnikov Date: Wed, 6 Oct 2010 13:02:36 +1100 Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: sysctl debug.cpufreq.highest X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 02:02:59 -0000 Are there plans to add debug.cpufreq.highest support into CURRENT and eventually into 8-STABLE? Corresponding patches [0] have been available since Nov 2008 [1] and they work pretty well. This variable allows to underclock the CPU, which is useful when building quiet or low-power systems. [0] http://acm.poly.edu/~spawk/cpufreq/ [1] http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000316.html From owner-freebsd-current@FreeBSD.ORG Wed Oct 6 04:49:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28581106566B for ; Wed, 6 Oct 2010 04:49:08 +0000 (UTC) (envelope-from kientzle@freebsd.org) 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 7F5DA8FC13 for ; Wed, 6 Oct 2010 04:49:07 +0000 (UTC) Received: from [10.123.2.179] ([192.168.1.65]) by monday.kientzle.com (8.14.3/8.14.3) with ESMTP id o964VTUu001405; Wed, 6 Oct 2010 04:31:29 GMT (envelope-from kientzle@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20101005082723.GA2540@laptop.levsha.me> Date: Tue, 5 Oct 2010 21:31:29 -0700 Content-Transfer-Encoding: 7bit Message-Id: <18B9EF7D-BFBD-41D7-9BC8-46B52DF9D83C@freebsd.org> References: <20101005082723.GA2540@laptop.levsha.me> To: Mykola Dzham X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org Subject: Re: bin/tar incorrectly parse '[^...]' patterns in --exclude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 04:49:08 -0000 On Oct 5, 2010, at 1:27 AM, Mykola Dzham wrote: > Hi! > bsd tar parse only '[!...]' as negate pattern, but gnu tar and bsd tar > on 8-STABLE parse '[^...]' too: > > Fix: > > Index: usr.bin/tar/pathmatch.c > =================================================================== > --- usr.bin/tar/pathmatch.c (revision 212602) > +++ usr.bin/tar/pathmatch.c (working copy) > @@ -35,7 +35,7 @@ > > /* > * Check whether a character 'c' is matched by a list specification [...]: > - * * Leading '!' negates the class. > + * * Leading '!' or '^' negates the class. > * * - is a range of characters > * * \ removes any special meaning for > * > @@ -60,7 +60,7 @@ > (void)flags; /* UNUSED */ > > /* If this is a negated class, return success for nomatch. */ > - if (*p == '!' && p < end) { > + if ((*p == '!' || *p == '^') && p < end) { > match = 0; > nomatch = 1; > ++p; Thanks! Committed at r213469. Tim From owner-freebsd-current@FreeBSD.ORG Wed Oct 6 06:18:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4515B106564A for ; Wed, 6 Oct 2010 06:18:42 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id D0CE38FC19 for ; Wed, 6 Oct 2010 06:18:41 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D1293E8B7C; Wed, 6 Oct 2010 07:18:40 +0100 (BST) Received: from core.nessbank (client-82-31-12-174.midd.adsl.virginmedia.com [82.31.12.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 6 Oct 2010 07:18:39 +0100 (BST) From: Bruce Cran To: freebsd-current@freebsd.org Date: Wed, 6 Oct 2010 07:18:38 +0100 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201010060718.39137.bruce@cran.org.uk> Cc: Alexander Kojevnikov Subject: Re: sysctl debug.cpufreq.highest X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 06:18:42 -0000 On Wednesday 06 October 2010 03:02:36 Alexander Kojevnikov wrote: > This variable allows to underclock the CPU, which is useful when > building quiet or low-power systems. You can use the new -m and -M switches to powerd to control the minimum and maximum frequencies instead. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Oct 6 06:48:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 117581065670 for ; Wed, 6 Oct 2010 06:48:31 +0000 (UTC) (envelope-from alexander@kojevnikov.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id CE0FF8FC0C for ; Wed, 6 Oct 2010 06:48:30 +0000 (UTC) Received: by qyk35 with SMTP id 35so3908622qyk.13 for ; Tue, 05 Oct 2010 23:48:30 -0700 (PDT) Received: by 10.224.36.207 with SMTP id u15mr8960016qad.317.1286347710047; Tue, 05 Oct 2010 23:48:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.84.73 with HTTP; Tue, 5 Oct 2010 23:48:09 -0700 (PDT) In-Reply-To: <201010060718.39137.bruce@cran.org.uk> References: <201010060718.39137.bruce@cran.org.uk> From: Alexander Kojevnikov Date: Wed, 6 Oct 2010 17:48:09 +1100 Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Bruce Cran , spawk@acm.poly.edu Subject: Re: sysctl debug.cpufreq.highest X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 06:48:31 -0000 On 6 October 2010 17:18, Bruce Cran wrote: > On Wednesday 06 October 2010 03:02:36 Alexander Kojevnikov wrote: > >> This variable allows to underclock the CPU, which is useful when >> building quiet or low-power systems. > > You can use the new -m and -M switches to powerd to control the minimum and > maximum frequencies instead. Thanks Bruce, now I have a good reason to upgrade to CURRENT :) Still, it would be nice to have debug.cpufreq.highest exposed via sysctl. Especially considering that the patch is quite short and straightforward. From owner-freebsd-current@FreeBSD.ORG Wed Oct 6 15:26:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A303B10656AC for ; Wed, 6 Oct 2010 15:26:24 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 586F58FC18 for ; Wed, 6 Oct 2010 15:26:24 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P3Vsq-0006CE-80 for freebsd-current@freebsd.org; Wed, 06 Oct 2010 17:26:20 +0200 Received: from 207.155.204.151.ptr.us.xo.net ([207.155.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Oct 2010 17:26:20 +0200 Received: from atkin901 by 207.155.204.151.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Oct 2010 17:26:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Wed, 06 Oct 2010 08:26:08 -0700 Lines: 21 Message-ID: References: <201010050146.39923.hselasky@freebsd.org> <4CABA8DB.4050902@freebsd.org> <4CABB6E9.2070606@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 207.155.204.151.ptr.us.xo.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100920 Thunderbird/3.1.4 In-Reply-To: X-Enigmail-Version: 1.1.2 Subject: Re: timer selection w/ one shot timer prevents HP DL385G5 from booting (was usb 3.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 15:26:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/06/2010 08:04, Mark Atkinson wrote: >>> On 10/05/2010 11:39, Mark Atkinson wrote: > kern.eventtimer.periodic: 0 *sigh* Although I misspelled eventtimer as 'eventtimers' in loader.conf it still fails to boot without manually selecting the timer. It's also annoying since '~ ^b' fails to break when it hangs, but '~ ^r' will work if I give it twice with ALT_BREAK_TO_DEBUGGER. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyslRAACgkQrDN5kXnx8ybMzQCfbLwSk+W7RDmkBnzT4pgsc3oT I3oAnRMsbPJ1suKgeQ4zJ9M3nw3vM/Jp =GR7T -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Oct 6 15:30:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E79FA106564A for ; Wed, 6 Oct 2010 15:30:02 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id CAF8A8FC14 for ; Wed, 6 Oct 2010 15:30:02 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o96FTwGU029437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Oct 2010 08:29:58 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 40A0D1CC3E; Wed, 6 Oct 2010 08:29:58 -0700 (PDT) To: Bruce Cran In-reply-to: Your message of "Wed, 06 Oct 2010 07:18:38 BST." <201010060718.39137.bruce@cran.org.uk> Date: Wed, 06 Oct 2010 08:29:58 -0700 From: "Kevin Oberman" Message-Id: <20101006152958.40A0D1CC3E@ptavv.es.net> Cc: freebsd-current@freebsd.org, Alexander Kojevnikov Subject: Re: sysctl debug.cpufreq.highest X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 15:30:03 -0000 > From: Bruce Cran > Date: Wed, 6 Oct 2010 07:18:38 +0100 > Sender: owner-freebsd-current@freebsd.org > > On Wednesday 06 October 2010 03:02:36 Alexander Kojevnikov wrote: > > > This variable allows to underclock the CPU, which is useful when > > building quiet or low-power systems. > > You can use the new -m and -M switches to powerd to control the minimum and > maximum frequencies instead. Ack! Did this really make it into the code? This is NOT the answer. the answer is to get rid of the useless CPU throttling and TCC which is the real cause of this. Neither of these methods was designed as a power management mechanism. They were designed to keep the processor from over-heating. They both can do what they were designed for quite well, but they can provide only very limited power savings and can actually result in higher power consumption in some cases. (I reported on my research into this several years ago, but the definitive work was done by mav@ and can be read on the FreeBSD wiki at http://wiki.freebsd.org/TuningPowerConsumption If we would just get rid of this (or at least turn it off by default), this whole problems requiring -m would go away. (I can see real use for -M, though.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 07:27:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 056881065674 for ; Thu, 7 Oct 2010 07:27:37 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B2CD58FC17 for ; Thu, 7 Oct 2010 07:27:36 +0000 (UTC) Received: by vws2 with SMTP id 2so271227vws.13 for ; Thu, 07 Oct 2010 00:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=OhqvIxBuusvVwa/hctDGTn+XYGK1+l8iQB3H06rF7rA=; b=GG9D9l1qfJNR2p66jugP3GWjA77Ykv593ipkvqVN8FUgqK80xAorJawjJpDibo47h8 L2oC3UDh99BgLI5h2Fw0XPb4P0uIcWZijgn+3geWXRxfjhLrKN+7y0RRC/oFS+fRJ31q UvJl/h6mk2Ynkwcps41cJrwbEJmJ9rQkiPYd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=b5dOlNH17PjChROdwDu0OXM1eHLfuRUNPkkPKL8EFkkDpW2yPmKjGUTTJcIUDh1b56 BL61INWjbEyOCKbSkeUpPrN5R/2fDHKT8myNbyqsPG6kss3F/lsW0gqaQJxv2qPLJKQY +/1Pbi1NkzQRElJaFskHMlnxHRzth9dot4C3c= MIME-Version: 1.0 Received: by 10.220.178.139 with SMTP id bm11mr154384vcb.0.1286436454501; Thu, 07 Oct 2010 00:27:34 -0700 (PDT) Received: by 10.220.193.77 with HTTP; Thu, 7 Oct 2010 00:27:34 -0700 (PDT) Date: Thu, 7 Oct 2010 11:27:34 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: c++: Internal error: Killed: 9 (program ld) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 07:27:37 -0000 Hello All, I have a problem with building CURRENT tree (rev. 213491). Below is a command which fails: root@csx-spb-freebsd9 11:04:40 /usr/src/obj/usr/src/usr.bin/clang/clang # [0] c++ -O2 -pipe -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -fno-exceptions -fno-rtti -g -O0 -fstack-protector -g -O0 -o clang cc1_main.o cc1as_main.o driver.o /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangserialization/libclangserialization.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangchecker/libclangchecker.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/libclangindex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmprinter/libllvmpowerpcasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86asmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disassembler/libllvmx86disassembler.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codegen/libllvmx86codegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmprinter/libllvmx86asmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86info/libllvmx86info.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmprinter/libllvmmipsasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmprinter/libllvmarmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinter/libllvmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalaropts/libllvmscalaropts.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransformutils/libllvmtransformutils.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparser/libllvmmcparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libllvmipa.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysis/libllvmanalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtarget/libllvmtarget.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcore/libllvmcore.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/libllvmarminfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsupport/libllvmsupport.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsystem/libllvmsystem.a c++: Internal error: Killed: 9 (program ld) Please submit a full bug report. See for instructions. root@csx-spb-freebsd9 11:12:52 /usr/src/obj/usr/src/usr.bin/clang/clang # [1] Have anyone seen this problem before? Any workarounds? Should I go ahead and submit gcc bug? Thanks in advance! P.S. Some system info: root@csx-spb-freebsd9 11:18:56 /usr/src/obj/usr/src/usr.bin/clang/clang # [0] c++ --version c++ (GCC) 4.2.1 20070719 [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. root@csx-spb-freebsd9 11:21:22 /usr/src/obj/usr/src/usr.bin/clang/clang # [0] ld --version GNU ld version 2.15 [FreeBSD] 2004-05-23 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. root@csx-spb-freebsd9 11:21:33 /usr/src/obj/usr/src/usr.bin/clang/clang # [0] uname -a FreeBSD csx-spb-freebsd9 9.0-CURRENT FreeBSD 9.0-CURRENT #8 r212898: Mon Sep 20 22:30:44 MSD 2010 root@csx-spb-freebsd9:/usr/obj/usr/src/sys/GENERIC amd64 root@csx-spb-freebsd9 11:24:53 /usr/src/obj/usr/src/usr.bin/clang/clang # [0] -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 09:52:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C10A106566B for ; Thu, 7 Oct 2010 09:52:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9FEE38FC0C for ; Thu, 7 Oct 2010 09:52:42 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f586:565f:fda1:7015] (unknown [IPv6:2001:7b8:3a7:0:f586:565f:fda1:7015]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 812145C43; Thu, 7 Oct 2010 11:52:41 +0200 (CEST) Message-ID: <4CAD986B.6010107@FreeBSD.org> Date: Thu, 07 Oct 2010 11:52:43 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12pre) Gecko/20101001 Lanikai/3.1.5pre MIME-Version: 1.0 To: Dmitry Krivenok References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: c++: Internal error: Killed: 9 (program ld) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 09:52:43 -0000 On 2010-10-07 09:27, Dmitry Krivenok wrote: > c++: Internal error: Killed: 9 (program ld) > Please submit a full bug report. > See for instructions. > root@csx-spb-freebsd9 11:12:52 /usr/src/obj/usr/src/usr.bin/clang/clang # [1] > > Have anyone seen this problem before? Any workarounds? > Should I go ahead and submit gcc bug? This is 'ld' dying, not gcc. As to what the cause of the problem is, I have no idea, since it links fine here, I just tested it. Can you try appending "-Wl,--verbose" to your link command line, and post the output somewhere? Alternatively, add "-v" to the command line, figure out what arguments c++ calls ld with, and run that command separately under gdb. E.g. it should run something similar to (formatted for clarity): /usr/obj/usr/src/tmp/usr/bin/ld \ --eh-frame-hdr \ -V \ -dynamic-linker /libexec/ld-elf.so.1 \ -o clang \ /usr/obj/usr/src/tmp/usr/lib/crt1.o \ /usr/obj/usr/src/tmp/usr/lib/crti.o \ /usr/obj/usr/src/tmp/usr/lib/crtbegin.o \ -L/usr/obj/usr/src/tmp/usr/lib \ -L/usr/obj/usr/src/tmp/usr/lib \ cc1_main.o \ cc1as_main.o \ driver.o \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangserialization/libclangserialization.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangchecker/libclangchecker.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/libclangindex.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmprinter/libllvmpowerpcasmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86asmparser.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disassembler/libllvmx86disassembler.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codegen/libllvmx86codegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmprinter/libllvmx86asmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86info/libllvmx86info.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmprinter/libllvmmipsasmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmprinter/libllvmarmasmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinter/libllvmasmprinter.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalaropts/libllvmscalaropts.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransformutils/libllvmtransformutils.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparser/libllvmmcparser.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libllvmipa.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysis/libllvmanalysis.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtarget/libllvmtarget.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcore/libllvmcore.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/libllvmarminfo.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsupport/libllvmsupport.a \ /usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsystem/libllvmsystem.a \ -lstdc++ \ -lm \ -lgcc_s \ -lgcc \ -lc \ -lssp_nonshared \ -lgcc_s \ -lgcc \ /usr/obj/usr/src/tmp/usr/lib/crtend.o \ /usr/obj/usr/src/tmp/usr/lib/crtn.o From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 10:51:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5528D106566B; Thu, 7 Oct 2010 10:51:20 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DAF1C8FC0A; Thu, 7 Oct 2010 10:51:19 +0000 (UTC) Received: by vws2 with SMTP id 2so339902vws.13 for ; Thu, 07 Oct 2010 03:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/cooQ+wuVb/pdg4K1Mt65TmN+R9Miyo7lIsVOjXR/Wc=; b=cpvqJvIFfZXBJblX0uomXEd5O+gmc4Hf1OBPkLKPr9DIrFBbRwoafgOaCe8ViSbjhj DiMEiW8q2JP99D3rwiv3oH0tazGEyByCG0T2NFu4snaLHda11oy9qp41iilNHllvP2hl 75a32CnY9QpPLkHClZqjgApO8/PimR66NVim0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KXoLttnYNIeVSMgGewm/CgKtok3ia9uhdi85Dv38VYcq/hf3pa3XBnJiNl1HwqaEQh RV/kp5tlCbWV5IWHtMS6eVv39eyTHZm6vXmNxL30V6BzxLfX8mfdc2tfnWI8YHeuWS3U Tsl3lUSUdoXbSYDRhG2F0t7exB4Pq9U3RoDlg= MIME-Version: 1.0 Received: by 10.229.229.9 with SMTP id jg9mr567801qcb.272.1286448677799; Thu, 07 Oct 2010 03:51:17 -0700 (PDT) Received: by 10.220.193.77 with HTTP; Thu, 7 Oct 2010 03:51:17 -0700 (PDT) In-Reply-To: <4CAD986B.6010107@FreeBSD.org> References: <4CAD986B.6010107@FreeBSD.org> Date: Thu, 7 Oct 2010 14:51:17 +0400 Message-ID: From: Dmitry Krivenok To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: c++: Internal error: Killed: 9 (program ld) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 10:51:20 -0000 I run ld under gdb and found the place where it fails: root@csx-spb-freebsd9 14:34:22 /usr/src/obj/usr/src/usr.bin/clang/clang # [137] gdb --args /usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o clang /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -L/usr/lib cc1_main.o cc1as_main.o driver.o /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfronten= dtool/libclangfrontendtool.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfronten= d/libclangfrontend.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/= libclangdriver.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangseriali= zation/libclangserialization.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen= /libclangcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/l= ibclangparse.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/li= bclangsema.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangchecker= /libclangchecker.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysi= s/libclanganalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/l= ibclangindex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite= /libclangrewrite.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangast/lib= clangast.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/lib= clanglex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/l= ibclangbasic.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcomb= ine/libllvminstcombine.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libl= lvmipo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwrite= r/libllvmbitwriter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreade= r/libllvmbitreader.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcc= odegen/libllvmpowerpccodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpca= smprinter/libllvmpowerpcasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpci= nfo/libllvmpowerpcinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmpa= rser/libllvmx86asmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disas= sembler/libllvmx86disassembler.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codeg= en/libllvmx86codegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmpr= inter/libllvmx86asmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86info/= libllvmx86info.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmp= rinter/libllvmmipsasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscode= gen/libllvmmipscodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo= /libllvmmipsinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmpa= rser/libllvmarmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodeg= en/libllvmarmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmpr= inter/libllvmarmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparse= r/libllvmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectio= ndag/libllvmselectiondag.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprint= er/libllvmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/= libllvmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalarop= ts/libllvmscalaropts.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransfor= mutils/libllvmtransformutils.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libll= vmmc.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparser= /libllvmmcparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libl= lvmipa.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysis= /libllvmanalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtarget/l= ibllvmtarget.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libll= vmmc.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcore/lib= llvmcore.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/= libllvmarminfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsupport/= libllvmsupport.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsystem/l= ibllvmsystem.a -lstdc++ -lm -lgcc_s -lgcc -lc -lssp_nonshared -lgcc_s -lgcc /usr/lib/crtend.o /usr/lib/crtn.o GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar= e welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... (gdb) r Starting program: /usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o clang /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -L/usr/lib cc1_main.o cc1as_main.o driver.o /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libcla= ngfrontendtool/libclangfrontendtool.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfronten= d/libclangfrontend.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/= libclangdriver.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangseriali= zation/libclangserialization.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen= /libclangcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/l= ibclangparse.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/li= bclangsema.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangchecker= /libclangchecker.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysi= s/libclanganalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/l= ibclangindex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite= /libclangrewrite.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangast/lib= clangast.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/lib= clanglex.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/l= ibclangbasic.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcomb= ine/libllvminstcombine.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libl= lvmipo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwrite= r/libllvmbitwriter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreade= r/libllvmbitreader.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcc= odegen/libllvmpowerpccodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpca= smprinter/libllvmpowerpcasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpci= nfo/libllvmpowerpcinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmpa= rser/libllvmx86asmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disas= sembler/libllvmx86disassembler.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codeg= en/libllvmx86codegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmpr= inter/libllvmx86asmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86info/= libllvmx86info.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmp= rinter/libllvmmipsasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscode= gen/libllvmmipscodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo= /libllvmmipsinfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmpa= rser/libllvmarmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodeg= en/libllvmarmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmpr= inter/libllvmarmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparse= r/libllvmasmparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectio= ndag/libllvmselectiondag.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprint= er/libllvmasmprinter.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/= libllvmcodegen.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalarop= ts/libllvmscalaropts.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransfor= mutils/libllvmtransformutils.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libll= vmmc.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparser= /libllvmmcparser.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libl= lvmipa.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysis= /libllvmanalysis.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtarget/l= ibllvmtarget.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libll= vmmc.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcore/lib= llvmcore.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/= libllvmarminfo.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsupport/= libllvmsupport.a /usr/src/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsystem/l= ibllvmsystem.a -lstdc++ -lm -lgcc_s -lgcc -lc -lssp_nonshared -lgcc_s -lgcc /usr/lib/crtend.o /usr/lib/crtn.o GNU ld version 2.15 [FreeBSD] 2004-05-23 Supported emulations: elf_i386_fbsd elf_x86_64_fbsd Program received signal SIGKILL, Killed. 0x000000000042e093 in bfd_elf_final_link (abfd=3D0x800915140, info=3D0x66c9= 00) at /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bf= d/elflink.c:7247 7247 ext_size =3D elf_section_data (sec)->rel_hdr.sh_size; (gdb) bt #0 0x000000000042e093 in bfd_elf_final_link (abfd=3D0x800915140, info=3D0x= 66c900) at /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bf= d/elflink.c:7247 #1 0x000000000041ce31 in ldwrite () at /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldwrite.c:= 565 #2 0x0000000000418959 in main (argc=3D73, argv=3D0x7fffffffd518) at /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:4= 75 (gdb) On Thu, Oct 7, 2010 at 1:52 PM, Dimitry Andric wrote: > On 2010-10-07 09:27, Dmitry Krivenok wrote: >> >> c++: Internal error: Killed: 9 (program ld) >> Please submit a full bug report. >> See =A0for instructions. >> root@csx-spb-freebsd9 11:12:52 /usr/src/obj/usr/src/usr.bin/clang/clang = # >> [1] >> >> Have anyone seen this problem before? Any workarounds? >> Should I go ahead and submit gcc bug? > > This is 'ld' dying, not gcc. =A0As to what the cause of the problem is, I > have no idea, since it links fine here, I just tested it. > > Can you try appending "-Wl,--verbose" to your link command line, and > post the output somewhere? > > Alternatively, add "-v" to the command line, figure out what arguments > c++ calls ld with, and run that command separately under gdb. =A0E.g. it > should run something similar to (formatted for clarity): > > /usr/obj/usr/src/tmp/usr/bin/ld \ > =A0--eh-frame-hdr \ > =A0-V \ > =A0-dynamic-linker /libexec/ld-elf.so.1 \ > =A0-o clang \ > =A0/usr/obj/usr/src/tmp/usr/lib/crt1.o \ > =A0/usr/obj/usr/src/tmp/usr/lib/crti.o \ > =A0/usr/obj/usr/src/tmp/usr/lib/crtbegin.o \ > =A0-L/usr/obj/usr/src/tmp/usr/lib \ > =A0-L/usr/obj/usr/src/tmp/usr/lib \ > =A0cc1_main.o \ > =A0cc1as_main.o \ > =A0driver.o \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfronte= ndtool/libclangfrontendtool.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangfronte= nd/libclangfrontend.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver= /libclangdriver.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangserial= ization/libclangserialization.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangcodege= n/libclangcodegen.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/= libclangparse.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/l= ibclangsema.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangchecke= r/libclangchecker.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanganalys= is/libclanganalysis.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/= libclangindex.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrit= e/libclangrewrite.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangast/li= bclangast.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/li= bclanglex.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/= libclangbasic.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcom= bine/libllvminstcombine.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/lib= llvmipo.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwrit= er/libllvmbitwriter.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitread= er/libllvmbitreader.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpc= codegen/libllvmpowerpccodegen.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpc= asmprinter/libllvmpowerpcasmprinter.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpc= info/libllvmpowerpcinfo.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmp= arser/libllvmx86asmparser.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disa= ssembler/libllvmx86disassembler.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86code= gen/libllvmx86codegen.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmp= rinter/libllvmx86asmprinter.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86info= /libllvmx86info.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasm= printer/libllvmmipsasmprinter.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscod= egen/libllvmmipscodegen.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinf= o/libllvmmipsinfo.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmp= arser/libllvmarmasmparser.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcode= gen/libllvmarmcodegen.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmp= rinter/libllvmarmasmprinter.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmpars= er/libllvmasmparser.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmselecti= ondag/libllvmselectiondag.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprin= ter/libllvmasmprinter.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen= /libllvmcodegen.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalaro= pts/libllvmscalaropts.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransfo= rmutils/libllvmtransformutils.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libl= lvmmc.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparse= r/libllvmmcparser.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/lib= llvmipa.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysi= s/libllvmanalysis.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmtarget/= libllvmtarget.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libl= lvmmc.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmcore/li= bllvmcore.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo= /libllvmarminfo.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsupport= /libllvmsupport.a > \ > =A0/usr/obj/usr/src/usr.bin/clang/clang/../../../lib/clang/libllvmsystem/= libllvmsystem.a > \ > =A0-lstdc++ \ > =A0-lm \ > =A0-lgcc_s \ > =A0-lgcc \ > =A0-lc \ > =A0-lssp_nonshared \ > =A0-lgcc_s \ > =A0-lgcc \ > =A0/usr/obj/usr/src/tmp/usr/lib/crtend.o \ > =A0/usr/obj/usr/src/tmp/usr/lib/crtn.o > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 11:51:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F73F106566B for ; Thu, 7 Oct 2010 11:51:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3D54E8FC21 for ; Thu, 7 Oct 2010 11:51:04 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f586:565f:fda1:7015] (unknown [IPv6:2001:7b8:3a7:0:f586:565f:fda1:7015]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 71B905C43; Thu, 7 Oct 2010 13:51:03 +0200 (CEST) Message-ID: <4CADB42A.2000605@FreeBSD.org> Date: Thu, 07 Oct 2010 13:51:06 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12pre) Gecko/20101001 Lanikai/3.1.5pre MIME-Version: 1.0 To: Dmitry Krivenok References: <4CAD986B.6010107@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: c++: Internal error: Killed: 9 (program ld) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 11:51:04 -0000 On 2010-10-07 12:51, Dmitry Krivenok wrote: > I run ld under gdb and found the place where it fails: ... > Program received signal SIGKILL, Killed. > 0x000000000042e093 in bfd_elf_final_link (abfd=0x800915140, info=0x66c900) > at /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elflink.c:7247 > 7247 ext_size = elf_section_data > (sec)->rel_hdr.sh_size; Since you are getting SIGKILL, not SIGSEGV, it suggests that you may be running out of memory, and ld is killed. Can you check memory/swap usage during this linking? You should also see messages in the system logs, if programs are killed because of memory exhaustion. From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 11:57:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1576C106566B; Thu, 7 Oct 2010 11:57:14 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id AE8408FC0A; Thu, 7 Oct 2010 11:57:13 +0000 (UTC) Received: by gyg4 with SMTP id 4so283854gyg.13 for ; Thu, 07 Oct 2010 04:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Co4uaJvUft/XXguDUsefaT9Le+0F5TqjUk4liS8xfxw=; b=byD1n8iqHg1caakBPGJaaSCmcZ6K4nWsYcIT2IRVIJckXDZHlm9q2srLteethwFem/ emxLCXXeE9VMkaxM4sxS2ub9XOMYUMW21+868dSVNdZyRWHMe9O9u26xapapVGTj3anv fjnat/K6WkGGukZt4RdeluUkbDw5CBzJRU88s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nTqjIeqRJbI/orTeOYNxtEtAy3e0HjzOH/iZMeY9BdvukN26FYn9rE/UGiWj6H4Gd1 gWRax0dhkKX23FmvYDy990Amu6bZN8uM7SNToMx2gD79bi+MO4DMQdGySiASDgyaBfgC 47+x+X6UXbqcgDFuZkf+d2wKFvaKGroIiu7ao= MIME-Version: 1.0 Received: by 10.90.90.20 with SMTP id n20mr551146agb.201.1286452632840; Thu, 07 Oct 2010 04:57:12 -0700 (PDT) Received: by 10.220.193.77 with HTTP; Thu, 7 Oct 2010 04:57:12 -0700 (PDT) In-Reply-To: <4CADB42A.2000605@FreeBSD.org> References: <4CAD986B.6010107@FreeBSD.org> <4CADB42A.2000605@FreeBSD.org> Date: Thu, 7 Oct 2010 15:57:12 +0400 Message-ID: From: Dmitry Krivenok To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: c++: Internal error: Killed: 9 (program ld) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 11:57:14 -0000 Yes, you are right. I see a lot of messages like below in dmesg output: swap_pager_getswapspace(5): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed pid 50038 (ld), uid 0, was killed: out of swap space pid 60947 (sshd), uid 1001, was killed: out of swap space swap_pager: out of swap space swap_pager_getswapspace(16): failed pid 50872 (ld), uid 0, was killed: out of swap space swap_pager: out of swap space swap_pager_getswapspace(2): failed pid 51222 (ld), uid 0, was killed: out of swap space swap_pager: out of swap space swap_pager_getswapspace(16): failed pid 51240 (ld), uid 0, was killed: out of swap space Perhaps I just need to add more swap and memory: krived@csx-spb-freebsd9 15:54:47 ~ $ [0] swapinfo Device 1K-blocks Used Avail Capacity /dev/da0s1b 500000 499992 8 100% krived@csx-spb-freebsd9 15:54:49 ~ $ [0] Thanks! On Thu, Oct 7, 2010 at 3:51 PM, Dimitry Andric wrote: > On 2010-10-07 12:51, Dmitry Krivenok wrote: >> >> I run ld under gdb and found the place where it fails: > > ... >> >> Program received signal SIGKILL, Killed. >> 0x000000000042e093 in bfd_elf_final_link (abfd=3D0x800915140, info=3D0x6= 6c900) >> =A0 =A0 at >> /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/el= flink.c:7247 >> 7247 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ext_size =3D elf= _section_data >> (sec)->rel_hdr.sh_size; > > Since you are getting SIGKILL, not SIGSEGV, it suggests that you may be > running out of memory, and ld is killed. =A0Can you check memory/swap > usage during this linking? =A0You should also see messages in the system > logs, if programs are killed because of memory exhaustion. > --=20 Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 13:17:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7091E1065728 for ; Thu, 7 Oct 2010 13:17:17 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 432358FC08 for ; Thu, 7 Oct 2010 13:17:17 +0000 (UTC) Received: by pxi17 with SMTP id 17so151243pxi.13 for ; Thu, 07 Oct 2010 06:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qP8Cl9F3u0YU7Rg65B0RbLh4LlIu2+Ojc/sE9msYVd4=; b=RCf00jrC8edTTJRlNINSY3Ek8iW8YPGYzESi4YkW+5HZNktcVLZLiyIFHarc5qEjmo cS6Hu0xO/X9Mp/pqarnMe8Kk5ylI0/gY8Fy29l+YZ1AERCB/Xbzc55Tw/grgHT9lZz2G bb7u1UuwGpXlASSGSAtEGpTodSaj3kAzjBglU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KWJV0TMmh2Iw8z/ppRnFGLheHwNX1JnTWsLEv0DPufp4VkEn23yI4Xb9tDUxlyrWrT 7MjhpCKFKpxosg8hdmP/X21kSWj2FeTt1X0jJouPXv8oBpbYwhsjlnqjN4Oo/q6p1a8C xDS4MqxpTPJ91FbjEJ5zwz4WDyyIKDjMOgEWk= MIME-Version: 1.0 Received: by 10.142.103.10 with SMTP id a10mr571199wfc.116.1286457436781; Thu, 07 Oct 2010 06:17:16 -0700 (PDT) Received: by 10.220.187.194 with HTTP; Thu, 7 Oct 2010 06:17:16 -0700 (PDT) In-Reply-To: <4CADC453.7010404@googlemail.com> References: <4CADC453.7010404@googlemail.com> Date: Thu, 7 Oct 2010 13:17:16 +0000 Message-ID: From: Paul B Mahol To: "army.of.root" Content-Type: text/plain; charset=ISO-8859-1 Cc: Brandon Gooch , freebsd-current@freebsd.org Subject: Re: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 13:17:17 -0000 On 10/7/10, army.of.root wrote: > On 10\10\02 18:48, Paul B Mahol wrote: >> On 10/2/10, Brandon Gooch wrote: >>> On Sat, Oct 2, 2010 at 7:36 AM, Paul B Mahol wrote: >>>> Hi, >>>> >>>> I see no point to have it in usr/bin. >>> >>> Cool! This is the first time I've heard of this program! How come the >>> folks at my university who manage the line printers have never let me >>> on to this?! >>> >>> Ahh -- wait a sec -- I'm beginning to see your point about the whole >>> "move it to games thing"... >>> >>> -Brandon aka "The Green Bar Bandit" >>> >> >> NetBSD and OpenBSD have this version in games and horizontal version >> of banner in usr/bin. >> >> I see no point to have this program(s) in base at all. >> >> I will just stop here. > > Hi, > > A horizontal version of banner could be nice for motd etc. > > I like banner. > It makes me smile and think that FreeBSD is a cosy place to be. > > have a nice day :) You have figlet and toilet with other sundry amusements in ports. From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 13:30:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32F60106566B for ; Thu, 7 Oct 2010 13:30:06 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B198F8FC08 for ; Thu, 7 Oct 2010 13:30:05 +0000 (UTC) Received: by fxm9 with SMTP id 9so414537fxm.13 for ; Thu, 07 Oct 2010 06:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Na/qWIuWQNe4hohKkKxxayjKP7bKaL2ku4U8BNxG1u8=; b=Tgx4DHyEA3BWHeuxZqZ4kV39pX2qKtNfL8hzevT1Blq0YH5BXYMKbkaJj49JLt5jp1 ugtMwsK0yog4QjufVlZXkYKCLg49aZk8ZcDotkMI7CMKBrkzo0cRJkweFUEJRHUdMzj8 h9kyrh4QhdZIqrHFxk+1g/r22X/91sIOF7SD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=nDvqYPVLDnSh9uHEWQqqdwAUyuBoQrnb5np1WYV75UFfucbyHePj2+X9dBTSmfdJ/F DwVCxiUB2lbZD0xpbMDNnML7ZLtbITypftuInQ5m69W2ShyJRCniEP39k8p/K2oCziI/ ibxvyt4sg4zly2LmqmvVlxqfXkF9WmQ28VhMA= Received: by 10.103.226.14 with SMTP id d14mr55564mur.114.1286456407017; Thu, 07 Oct 2010 06:00:07 -0700 (PDT) Received: from titanium.local ([131.234.67.123]) by mx.google.com with ESMTPS id a16sm504771fak.19.2010.10.07.06.00.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 Oct 2010 06:00:05 -0700 (PDT) Message-ID: <4CADC453.7010404@googlemail.com> Date: Thu, 07 Oct 2010 15:00:03 +0200 From: "army.of.root" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Paul B Mahol References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brandon Gooch , freebsd-current@freebsd.org Subject: Re: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 13:30:06 -0000 On 10\10\02 18:48, Paul B Mahol wrote: > On 10/2/10, Brandon Gooch wrote: >> On Sat, Oct 2, 2010 at 7:36 AM, Paul B Mahol wrote: >>> Hi, >>> >>> I see no point to have it in usr/bin. >> >> Cool! This is the first time I've heard of this program! How come the >> folks at my university who manage the line printers have never let me >> on to this?! >> >> Ahh -- wait a sec -- I'm beginning to see your point about the whole >> "move it to games thing"... >> >> -Brandon aka "The Green Bar Bandit" >> > > NetBSD and OpenBSD have this version in games and horizontal version > of banner in usr/bin. > > I see no point to have this program(s) in base at all. > > I will just stop here. Hi, A horizontal version of banner could be nice for motd etc. I like banner. It makes me smile and think that FreeBSD is a cosy place to be. have a nice day :) From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 14:27:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E758010656B3; Thu, 7 Oct 2010 14:27:09 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id A0F268FC1B; Thu, 7 Oct 2010 14:27:09 +0000 (UTC) Received: from scc-wkit-clx-208-149.scc.kit.edu (scc-wkit-clx-208-149.scc.kit.edu [141.3.208.149]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 28AB312543B; Thu, 7 Oct 2010 23:27:05 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Daichi GOTO In-Reply-To: Date: Thu, 7 Oct 2010 16:27:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40A99AF1-8989-4121-8659-CF3E169FD2F8@ongs.co.jp> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:27:10 -0000 On Oct 5, 2010, at 4:52 PM, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO wrote: >> On Tue, 5 Oct 2010 01:23:02 -0700 >> Garrett Cooper wrote: >>> 2010/10/4 Daichi GOTO : >>>> Thanks nice test tool :) And at last I got it excepting one = mystery! >>>>=20 >>>> On Mon, 4 Oct 2010 20:17:08 -0700 >>>> Garrett Cooper wrote: >>>>> Following through the same process on FreeBSD... >>>>>=20 >>>>> Window 1: >>>>> $ ls -l /tmp/lockfile >>>>> ls: /tmp/lockfile: No such file or directory >>>>> $ ./test_fcntl >>>>>=20 >>>>> Window 2: >>>>>=20 >>>>> $ ls -l /tmp/lockfile >>>>> -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile >>>>> $ ./test_fcntl >>>>> test_fcntl: fcntl: Resource temporarily unavailable >>>>=20 >>>> Just my mystery is as follow: >>>>=20 >>>> Windows 1: >>>> % ./test_fcntl >>>> My pid: 43490 >>>>=20 >>>> Windows 2: >>>> % ls -l /tmp/lockfile >>>> -r-sr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:02 /tmp/lockfile = <--- is it weird, isn't it? >>>> % ./test_fcntl >>>> test_fcntl: open: Permission denied >>>> % >>>>=20 >>>> Oops... What's wrong... /tmp is as follow: >>>>=20 >>>> % mount | grep tmp >>>> /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >>>> % dumpfs /tmp | grep journal >>>> flags soft-updates+journal >>>> % >>>>=20 >>>> And working scene: >>>>=20 >>>> Windows 2: >>>> % chmod u+w /tmp/lockfile >>>> % ls -l /tmp/lockfile >>>> -rwsr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:22 /tmp/lockfile >>>> % ./test_fcntl >>>> My pid: 43646 >>>> test_fcntl: fcntl[1]: Resource temporarily unavailable >>>> PID=3D43490 has the lock >>>> % >>>=20 >>> What's your umask and what are the permissions on /tmp? >>=20 >> % ll / | grep tmp >> drwxrwxrwt 14 root wheel 1024 10=E6=9C=88 5 17:19 tmp >> % umask >> 022 >> % rm -f test >> % touch test >> % ll | grep test >> -rw-r--r-- 1 daichi wheel 0 10=E6=9C=88 5 17:52 test >> % >=20 > The permissions look ok from my perspective, but the umask is > different, so you might want to try my umask to make sure that your > results match mine (and we need to check the requirements to determine > whether or not the behavior for FreeBSD's umask syscall is correct): >=20 > $ ls -la /tmp/ | head -n 2 > total 462686 > drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . > $ umask > 0022 The results are different on some users, even on the same user! (022 and 0022 shows the same results.) test user: $ rm -f /tmp/lockfile $ ./test_fcntl My pid: 63133 ^C $ ll /tmp/lockfile ---sr----- 1 test wheel - 0 Oct 7 23:16 /tmp/lockfile* $ daichi: % rm -f /tmp/lockfile =20 % ./test_fcntl=20 My pid: 63140 ^C % ll /tmp/lockfile ---Sr-x--- 1 daichi wheel 0 10=E6=9C=88 7 23:17 /tmp/lockfile %=20 But above daichi's result was ---sr----- as the same as test user. After some operation, it turns into returing ---Sr-x---. I didn't = remember=20 what operation did that. root: # rm -f /tmp/lockfile # ./test_fcntl My pid: 63147 ^C # ls -l /tmp/lockfile --wSr-S--- 1 root wheel 0 Oct 7 23:20 /tmp/lockfile #=20 It is mystery. > Where and how is /tmp mounted (is it a real partition, what > filesystem, etc)? UFS+SUJ+noatime real pertition. I checked atime version, and got the = same=20 result. > BTW, when I change my umask to match your's I don't get the same > results you do on my home machine: >=20 > Window 1: >=20 > $ umask 022 > $ ./test_fcntl > My pid: 17353 >=20 > Window 2: >=20 > $ ./test_fcntl > My pid: 17356 > test_fcntl: fcntl[1]: Resource temporarily unavailable > PID=3D17353 has the lock > $ ls -l /tmp/lockfile > -rwSr----- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile >=20 > Just to note, the tests before were run on the RHEL 4.8 box with > the following info, and the FreeBSD box with the following info: >=20 > Red Hat Enterprise Linux AS release 4 (Nahant Update 8) > Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT > 2009 x86_64 x86_64 x86_64 GNU/Linux >=20 > FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 > r211767M: Sat Aug 28 00:28:45 PDT 2010 > garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 >=20 > The tests above were run on a FreeBSD box with the following info: >=20 > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > Thu Aug 19 22:50:36 PDT 2010 > root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >=20 > On bayonetta /tmp is SUJ backed (probably should change that > though), and on bioshock it's not SUJ backed. > Thanks! > -Garrett Still now, I couldn't find the cause of this issue, but it's ok by code = following, and program should set permission at creating time I guess. fd =3D open("/tmp/lockfile", O_CREAT|O_WRONLY,0600); > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 14:36:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0229F1065670; Thu, 7 Oct 2010 14:36:57 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE268FC1B; Thu, 7 Oct 2010 14:36:56 +0000 (UTC) Received: from scc-wkit-clx-208-149.scc.kit.edu (scc-wkit-clx-208-149.scc.kit.edu [141.3.208.149]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 95B8212543B; Thu, 7 Oct 2010 23:36:53 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Daichi GOTO In-Reply-To: Date: Thu, 7 Oct 2010 16:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:36:57 -0000 On Oct 5, 2010, at 7:09 PM, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper = wrote: >> On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper = wrote: >>> On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO = wrote: >>>> On Tue, 5 Oct 2010 01:23:02 -0700 >>>> Garrett Cooper wrote: >>>>> 2010/10/4 Daichi GOTO : >>>>>> Thanks nice test tool :) And at last I got it excepting one = mystery! >>>>>>=20 >>>>>> On Mon, 4 Oct 2010 20:17:08 -0700 >>>>>> Garrett Cooper wrote: >>>>>>> Following through the same process on FreeBSD... >>>>>>>=20 >>>>>>> Window 1: >>>>>>> $ ls -l /tmp/lockfile >>>>>>> ls: /tmp/lockfile: No such file or directory >>>>>>> $ ./test_fcntl >>>>>>>=20 >>>>>>> Window 2: >>>>>>>=20 >>>>>>> $ ls -l /tmp/lockfile >>>>>>> -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile >>>>>>> $ ./test_fcntl >>>>>>> test_fcntl: fcntl: Resource temporarily unavailable >>>>>>=20 >>>>>> Just my mystery is as follow: >>>>>>=20 >>>>>> Windows 1: >>>>>> % ./test_fcntl >>>>>> My pid: 43490 >>>>>>=20 >>>>>> Windows 2: >>>>>> % ls -l /tmp/lockfile >>>>>> -r-sr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:02 /tmp/lockfile = <--- is it weird, isn't it? >>>>>> % ./test_fcntl >>>>>> test_fcntl: open: Permission denied >>>>>> % >>>>>>=20 >>>>>> Oops... What's wrong... /tmp is as follow: >>>>>>=20 >>>>>> % mount | grep tmp >>>>>> /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >>>>>> % dumpfs /tmp | grep journal >>>>>> flags soft-updates+journal >>>>>> % >>>>>>=20 >>>>>> And working scene: >>>>>>=20 >>>>>> Windows 2: >>>>>> % chmod u+w /tmp/lockfile >>>>>> % ls -l /tmp/lockfile >>>>>> -rwsr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:22 /tmp/lockfile >>>>>> % ./test_fcntl >>>>>> My pid: 43646 >>>>>> test_fcntl: fcntl[1]: Resource temporarily unavailable >>>>>> PID=3D43490 has the lock >>>>>> % >>>>>=20 >>>>> What's your umask and what are the permissions on /tmp? >>>>=20 >>>> % ll / | grep tmp >>>> drwxrwxrwt 14 root wheel 1024 10=E6=9C=88 5 17:19 tmp >>>> % umask >>>> 022 >>>> % rm -f test >>>> % touch test >>>> % ll | grep test >>>> -rw-r--r-- 1 daichi wheel 0 10=E6=9C=88 5 17:52 test >>>> % >>>=20 >>> The permissions look ok from my perspective, but the umask is >>> different, so you might want to try my umask to make sure that your >>> results match mine (and we need to check the requirements to = determine >>> whether or not the behavior for FreeBSD's umask syscall is correct): >>>=20 >>> $ ls -la /tmp/ | head -n 2 >>> total 462686 >>> drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . >>> $ umask >>> 0022 >>>=20 >>> Where and how is /tmp mounted (is it a real partition, what >>> filesystem, etc)? >>> BTW, when I change my umask to match your's I don't get the same >>> results you do on my home machine: >>>=20 >>> Window 1: >>>=20 >>> $ umask 022 >>> $ ./test_fcntl >>> My pid: 17353 >>>=20 >>> Window 2: >>>=20 >>> $ ./test_fcntl >>> My pid: 17356 >>> test_fcntl: fcntl[1]: Resource temporarily unavailable >>> PID=3D17353 has the lock >>> $ ls -l /tmp/lockfile >>> -rwSr----- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile >>>=20 >>> Just to note, the tests before were run on the RHEL 4.8 box with >>> the following info, and the FreeBSD box with the following info: >>>=20 >>> Red Hat Enterprise Linux AS release 4 (Nahant Update 8) >>> Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT >>> 2009 x86_64 x86_64 x86_64 GNU/Linux >>>=20 >>> FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 >>> r211767M: Sat Aug 28 00:28:45 PDT 2010 >>> garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 >>>=20 >>> The tests above were run on a FreeBSD box with the following = info: >>>=20 >>> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: >>> Thu Aug 19 22:50:36 PDT 2010 >>> root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >>>=20 >>> On bayonetta /tmp is SUJ backed (probably should change that >>> though), and on bioshock it's not SUJ backed. >>=20 >> And while this might be a good mental exercise, I think we're missing >> the original point of your bug: >>=20 >> You were getting ECONNREFUSED because a socket was in `use', even >> though all instances of mozc_server were dead (at least that's the >> case with me). So the question I guess that's worth asking is: >=20 > Statement incorrect: socket wasn't in use. The logic needs to be > rewritten to account for this case and setup the socket again if this > occurs. It would be a good idea to do this if the file wasn't locked. Maybe behavior difference of fcntl when called with F_SETLN or F_GETLN=20= you found is the answer of this issue. I'll try to check it out. Thanks! And I'll try to treat correct l_pid when called with F_SETLN. I guess = this change will be benefits for other applications that use fcntl(2) like = mozc_server does. >> 1. What process/application does it need to establish a Unix style = socket with? >> 2. Why isn't that socket being cleaned up by the OS at exit? >=20 > Thanks! > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 14:39:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E5CE1065695 for ; Thu, 7 Oct 2010 14:39:07 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 142D28FC19 for ; Thu, 7 Oct 2010 14:39:06 +0000 (UTC) Received: from pd5ml2no-ssvc.prod.shaw.ca ([10.0.153.164]) by pd5mo1no-svcs.prod.shaw.ca with ESMTP; 07 Oct 2010 08:24:05 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=dyVpuHYQJROgCHwBBw1H+I+7e1rgZIKdHwrI0HSbuo4= c=1 sm=1 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=xA7i7079zcQA:10 a=kj9zAlcOel0A:10 a=+J+gTUrb/Bhkr9chPx4Sww==:17 a=mK_AVkanAAAA:8 a=pGLkceISAAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=2kXSBunzLASjmdhlAo8A:9 a=Z372G5jMGNmgbdtdZCwA:7 a=CqygALOJ_sq1E4omWiHdq51alhAA:4 a=CjuIK1q_8ugA:10 a=9xyTavCNlvEA:10 a=MSl-tDqOz04A:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([24.68.75.245]) by pd5ml2no-dmz.prod.shaw.ca with ESMTP; 07 Oct 2010 08:24:05 -0600 Received: from cwsys.cwsent.com (cwsys [10.1.1.1]) by spqr.komquats.com (Postfix) with ESMTP id 8C57946E69; Thu, 7 Oct 2010 07:24:04 -0700 (PDT) Received: from cwsys (localhost [127.0.0.1]) by cwsys.cwsent.com (8.14.4/8.14.4) with ESMTP id o97EO4dJ028760; Thu, 7 Oct 2010 07:24:04 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201010071424.o97EO4dJ028760@cwsys.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: "army.of.root" In-Reply-To: Message from "army.of.root" of "Thu, 07 Oct 2010 15:00:03 +0200." <4CADC453.7010404@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Oct 2010 07:24:04 -0700 Sender: Cy.Schubert@komquats.com Cc: Brandon Gooch , freebsd-current@freebsd.org Subject: Re: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:39:07 -0000 In message <4CADC453.7010404@googlemail.com>, "army.of.root" writes: > On 10\10\02 18:48, Paul B Mahol wrote: > > On 10/2/10, Brandon Gooch wrote: > >> On Sat, Oct 2, 2010 at 7:36 AM, Paul B Mahol wrote: > >>> Hi, > >>> > >>> I see no point to have it in usr/bin. > >> > >> Cool! This is the first time I've heard of this program! How come the > >> folks at my university who manage the line printers have never let me > >> on to this?! > >> > >> Ahh -- wait a sec -- I'm beginning to see your point about the whole > >> "move it to games thing"... > >> > >> -Brandon aka "The Green Bar Bandit" > >> > > > > NetBSD and OpenBSD have this version in games and horizontal version > > of banner in usr/bin. > > > > I see no point to have this program(s) in base at all. > > > > I will just stop here. > > Hi, > > A horizontal version of banner could be nice for motd etc. > > I like banner. > It makes me smile and think that FreeBSD is a cosy place to be. It's been in the base for decades. People used it to print banners on reports, before laser and ink jet printers were around, when tractor feed printers ruled. Banner was more than just a game. People used it for production work. I suppose you could still use it for its intended purpose today however with the graphical tools we have today it's a little archaic. Having said that, it doesn't take up a lot of space and should probably remain where it is. BTW, I'm of the age where I did use it and tools like it (on the IBM mainframe) for real work. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org e**(i*pi)+1=0 From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 15:14:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D12F0106572B for ; Thu, 7 Oct 2010 15:14:54 +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 81EAC8FC22 for ; Thu, 7 Oct 2010 15:14:54 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1P3rmx-000Gvv-Rw; Thu, 07 Oct 2010 16:49:44 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Cy Schubert In-reply-to: <201010071424.o97EO4dJ028760@cwsys.cwsent.com> References: <201010071424.o97EO4dJ028760@cwsys.cwsent.com> Comments: In-reply-to Cy Schubert message dated "Thu, 07 Oct 2010 07:24:04 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Oct 2010 16:49:43 +0200 From: Daniel Braniss Message-ID: Cc: "army.of.root" , Brandon Gooch , freebsd-current@freebsd.org Subject: Re: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 15:14:55 -0000 > In message <4CADC453.7010404@googlemail.com>, "army.of.root" writes: > > On 10\10\02 18:48, Paul B Mahol wrote: > > > On 10/2/10, Brandon Gooch wrote: > > >> On Sat, Oct 2, 2010 at 7:36 AM, Paul B Mahol wrote: > > >>> Hi, > > >>> > > >>> I see no point to have it in usr/bin. > > >> > > >> Cool! This is the first time I've heard of this program! How come the > > >> folks at my university who manage the line printers have never let me > > >> on to this?! > > >> > > >> Ahh -- wait a sec -- I'm beginning to see your point about the whole > > >> "move it to games thing"... > > >> > > >> -Brandon aka "The Green Bar Bandit" > > >> > > > > > > NetBSD and OpenBSD have this version in games and horizontal version > > > of banner in usr/bin. > > > > > > I see no point to have this program(s) in base at all. > > > > > > I will just stop here. > > > > Hi, > > > > A horizontal version of banner could be nice for motd etc. > > > > I like banner. > > It makes me smile and think that FreeBSD is a cosy place to be. > > It's been in the base for decades. People used it to print banners on > reports, before laser and ink jet printers were around, when tractor feed > printers ruled. Banner was more than just a game. People used it for > production work. I suppose you could still use it for its intended purpose > today however with the graphical tools we have today it's a little archaic. > Having said that, it doesn't take up a lot of space and should probably > remain where it is. > > BTW, I'm of the age where I did use it and tools like it (on the IBM > mainframe) for real work. ah memories, I had the walls of my office covered with pi with some very long precision :-) danny From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 15:41:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B0B5106564A for ; Thu, 7 Oct 2010 15:41:26 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id E76FC8FC17 for ; Thu, 7 Oct 2010 15:41:25 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o97FexfH003795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Oct 2010 08:40:59 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id E68D71CC41; Thu, 7 Oct 2010 08:40:58 -0700 (PDT) To: Daniel Braniss In-reply-to: Your message of "Thu, 07 Oct 2010 16:49:43 +0200." Date: Thu, 07 Oct 2010 08:40:58 -0700 From: "Kevin Oberman" Message-Id: <20101007154058.E68D71CC41@ptavv.es.net> Cc: "army.of.root" , Brandon Gooch , freebsd-current@freebsd.org Subject: Re: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 15:41:26 -0000 > Date: Thu, 07 Oct 2010 16:49:43 +0200 > From: Daniel Braniss > Sender: owner-freebsd-current@freebsd.org > > > In message <4CADC453.7010404@googlemail.com>, "army.of.root" writes: > > > On 10\10\02 18:48, Paul B Mahol wrote: > > > > On 10/2/10, Brandon Gooch wrote: > > > >> On Sat, Oct 2, 2010 at 7:36 AM, Paul B Mahol wrote: > > > >>> Hi, > > > >>> > > > >>> I see no point to have it in usr/bin. > > > >> > > > >> Cool! This is the first time I've heard of this program! How come the > > > >> folks at my university who manage the line printers have never let me > > > >> on to this?! > > > >> > > > >> Ahh -- wait a sec -- I'm beginning to see your point about the whole > > > >> "move it to games thing"... > > > >> > > > >> -Brandon aka "The Green Bar Bandit" > > > >> > > > > > > > > NetBSD and OpenBSD have this version in games and horizontal version > > > > of banner in usr/bin. > > > > > > > > I see no point to have this program(s) in base at all. > > > > > > > > I will just stop here. > > > > > > Hi, > > > > > > A horizontal version of banner could be nice for motd etc. > > > > > > I like banner. > > > It makes me smile and think that FreeBSD is a cosy place to be. > > > > It's been in the base for decades. People used it to print banners on > > reports, before laser and ink jet printers were around, when tractor feed > > printers ruled. Banner was more than just a game. People used it for > > production work. I suppose you could still use it for its intended purpose > > today however with the graphical tools we have today it's a little archaic. > > Having said that, it doesn't take up a lot of space and should probably > > remain where it is. > > > > BTW, I'm of the age where I did use it and tools like it (on the IBM > > mainframe) for real work. > > ah memories, I had the walls of my office covered with pi with some very long > precision :-) I'm so sorry. I'm more prone to remember the ASCII rendering of the artwork of rather long images from a popular magazine which would certainly (and properly) be unacceptble in the workplace today. :-) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 16:52:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F94D106566C; Thu, 7 Oct 2010 16:52:54 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4538FC0A; Thu, 7 Oct 2010 16:52:52 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA17536; Thu, 07 Oct 2010 19:52:51 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CADFAE2.1090107@freebsd.org> Date: Thu, 07 Oct 2010 19:52:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-mobile@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: acpi_ec: request for review and testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:52:54 -0000 FYI: http://article.gmane.org/gmane.os.freebsd.devel.acpi/6440 If you can test and would like to report, please followup to that thread on acpi@ mailing list. Please do not followup to this post. Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 17:16:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5277106564A; Thu, 7 Oct 2010 17:16:19 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D9D408FC0A; Thu, 7 Oct 2010 17:16:18 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA17980; Thu, 07 Oct 2010 20:16:17 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CAE0060.7050607@freebsd.org> Date: Thu, 07 Oct 2010 20:16:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> In-Reply-To: <4CA5911E.3000101@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox , Garrett Cooper , Alan Cox Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 17:16:19 -0000 on 01/10/2010 10:43 Andriy Gapon said the following: > The idea. We dump contiguously only pages with PDEs (which means both valid and > invalid PDEs), valid pages with PTEs are dumped the same way as data physical > pages (i.e. via dump_add_page, etc); no fake PTEs for 2MB pages. > PDE area of the dump takes about 20MB as opposed to 1GB for PTE area (the math > is obvious, but just in case). > > libkva is changed to treat former PTE area as PDE area and is also taught to > understand PG_PS in PDE. > There is now an overhead of having to first read a PTE page in V-to-P-to-offset > lookup for !PG_PS case. Perhaps we could cache all PTEs in memory and have a > lookup table for them, but I didn't bother with this possibly premature > optimization at this time. > > There is an unrelated change in minidumpsys - "bitmap_frozen". > I had to do it despite having a patch in my local tree to stop other CPUs on > panic->dump. Code in dump path (peripheral disk driver, CAM, SIM driver, > something else?) seems to do some memory allocations and change dump bitmap, > which leads to a mismatch between dump size and dump bitmap; and also > potentially to inconsistencies in the bitmap itself. So I decided that it's a > good idea to freeze the bitmap once we decided what pages we want to dump. > > Some variables and structure fields with 'pte' in them should probably be > renamed to have 'pde' instead. Here's an updated patch: http://people.freebsd.org/~avg/amd64-minidump.3.diff I went ahead and changed 'pte' to 'pde' in various names. Also, I ditched somewhat questionable "bitmap_frozen" approach and instead opted for restarting a dump on a size mismatch. This was suggested by kib@. Garret Cooper has pointed out some problems with bitmap_frozen approach. I think that actual problem was a scenario where a dump is done, then the system is allowed to continue and then another dump is done. An exotic case perhaps? :-) One probably desirable feature that is missing is backward compatibility in libkvm. If that is a showstopper, then I'll have to work on preserving it. As usual, I will appreciate any feedback - reviews, testing, etc. Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 17:40:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 647691065697 for ; Thu, 7 Oct 2010 17:40:52 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0B18FC1B for ; Thu, 7 Oct 2010 17:40:51 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA18557; Thu, 07 Oct 2010 20:40:50 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CAE0621.3070809@freebsd.org> Date: Thu, 07 Oct 2010 20:40:49 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: hackers@freebsd.org, freebsd-current@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: panic_cpu should be volatile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 17:40:52 -0000 panic_cpu variable in kern_shutdown.c should be volatile otherwise it's cached in a register in the innermost while-loop in this code (observed on amd64 with base gcc and -O2): if (panic_cpu != PCPU_GET(cpuid)) while (atomic_cmpset_int(&panic_cpu, NOCPU, PCPU_GET(cpuid)) == 0) while (panic_cpu != NOCPU) ; /* nothing */ The patch is here: http://people.freebsd.org/~avg/panic_cpu.diff I also took a liberty to move the variable into the scope of panic() functions as it doesn't seem to be useful outside of it. But this is not necessary, of course. Big thanks to mdf@ for the hint and to kib@ and kan@ for memory model expertise. P.S. The assembly: .loc 1 544 0 movl panic_cpu(%rip), %eax .LVL134: .p2align 4,,7 .L210: cmpl $255, %eax jne .L210 jmp .L225 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 18:25:02 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 675F21065674 for ; Thu, 7 Oct 2010 18:25:02 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id 2430B8FC0C for ; Thu, 7 Oct 2010 18:25:01 +0000 (UTC) Received: from a91-153-123-205.elisa-laajakaista.fi (a91-153-123-205.elisa-laajakaista.fi [91.153.123.205]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 96E45151739 for ; Thu, 7 Oct 2010 21:06:59 +0300 (EEST) Date: Thu, 7 Oct 2010 21:06:57 +0300 From: Jaakko Heinonen To: freebsd-current@FreeBSD.org Message-ID: <20101007180657.GA1383@a91-153-123-205.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: HEADS UP: device name checking on device registration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:25:02 -0000 Since r213526 device names are checked on device registration. That is, if you call a make_dev*() function with an invalid device name, a panic will occur by default. For make_dev_credf(9) or make_dev_p(9) you can specify the MAKEDEV_CHECKNAME flag to get an error return instead of a panic. Invalid names are as follows: - empty name - names longer than SPECNAMELEN - names containing "." or ".." path component - names ending with '/' - already existing device names So, if you see a "bad si_name" panic you may have encountered a driver bug. Currently several GEOM classes (notably geom_label) allow to create devices with invalid names. Below is a link to a patch which converts g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not a complete solution and essentially changes the panic to a printf. http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff -- Jaakko From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 19:44:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F16FA106566C for ; Thu, 7 Oct 2010 19:44:36 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id B905D8FC14 for ; Thu, 7 Oct 2010 19:44:36 +0000 (UTC) Received: from pd3ml3so-ssvc.prod.shaw.ca ([10.0.141.149]) by pd2mo1so-svcs.prod.shaw.ca with ESMTP; 07 Oct 2010 13:44:36 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=uT3SUsFrUxSLMLkvWEyF5PJ45gYvcyNzEdQWRoVmi+I= c=1 sm=1 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=xA7i7079zcQA:10 a=kj9zAlcOel0A:10 a=+J+gTUrb/Bhkr9chPx4Sww==:17 a=vtXoPY2jAAAA:8 a=6I5d2MoRAAAA:8 a=mK_AVkanAAAA:8 a=pGLkceISAAAA:8 a=BWvPGDcYAAAA:8 a=_PnGQ5lAVYZWvhehhtEA:9 a=TkFAV2LH_vQ5mFR8sI0A:7 a=0ET0_2HzzVNTkR8VDQvAZGmq4vEA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=9xyTavCNlvEA:10 a=MSl-tDqOz04A:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([24.68.75.245]) by pd3ml3so-dmz.prod.shaw.ca with ESMTP; 07 Oct 2010 13:44:35 -0600 Received: from cwsys.cwsent.com (cwsys [10.1.1.1]) by spqr.komquats.com (Postfix) with ESMTP id 5ADCC46ECB; Thu, 7 Oct 2010 12:44:35 -0700 (PDT) Received: from cwsys (localhost [127.0.0.1]) by cwsys.cwsent.com (8.14.4/8.14.4) with ESMTP id o97JiXHX059273; Thu, 7 Oct 2010 12:44:34 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201010071944.o97JiXHX059273@cwsys.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: "Kevin Oberman" In-Reply-To: Message from "Kevin Oberman" of "Thu, 07 Oct 2010 08:40:58 PDT." <20101007154058.E68D71CC41@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Oct 2010 12:44:33 -0700 Sender: Cy.Schubert@komquats.com Cc: Brandon Gooch , "army.of.root" , freebsd-current@freebsd.org Subject: Re: Move banner to games X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:44:37 -0000 In message <20101007154058.E68D71CC41@ptavv.es.net>, "Kevin Oberman" writes: > > Date: Thu, 07 Oct 2010 16:49:43 +0200 > > From: Daniel Braniss > > Sender: owner-freebsd-current@freebsd.org > > > > > In message <4CADC453.7010404@googlemail.com>, "army.of.root" writes: > > > > On 10\10\02 18:48, Paul B Mahol wrote: > > > > > On 10/2/10, Brandon Gooch wrote: > > > > >> On Sat, Oct 2, 2010 at 7:36 AM, Paul B Mahol wrot > e: > > > > >>> Hi, > > > > >>> > > > > >>> I see no point to have it in usr/bin. > > > > >> > > > > >> Cool! This is the first time I've heard of this program! How come th > e > > > > >> folks at my university who manage the line printers have never let m > e > > > > >> on to this?! > > > > >> > > > > >> Ahh -- wait a sec -- I'm beginning to see your point about the whole > > > > >> "move it to games thing"... > > > > >> > > > > >> -Brandon aka "The Green Bar Bandit" > > > > >> > > > > > > > > > > NetBSD and OpenBSD have this version in games and horizontal version > > > > > of banner in usr/bin. > > > > > > > > > > I see no point to have this program(s) in base at all. > > > > > > > > > > I will just stop here. > > > > > > > > Hi, > > > > > > > > A horizontal version of banner could be nice for motd etc. > > > > > > > > I like banner. > > > > It makes me smile and think that FreeBSD is a cosy place to be. > > > > > > It's been in the base for decades. People used it to print banners on > > > reports, before laser and ink jet printers were around, when tractor fee > d > > > printers ruled. Banner was more than just a game. People used it for > > > production work. I suppose you could still use it for its intended purpos > e > > > today however with the graphical tools we have today it's a little archai > c. > > > Having said that, it doesn't take up a lot of space and should probably > > > remain where it is. > > > > > > BTW, I'm of the age where I did use it and tools like it (on the IBM > > > mainframe) for real work. > > > > ah memories, I had the walls of my office covered with pi with some very lo > ng > > precision :-) > > I'm so sorry. > > I'm more prone to remember the ASCII rendering of the artwork of rather > long images from a popular magazine which would certainly (and properly) > be unacceptble in the workplace today. :-) I can recall my first exposure to ASCII art. I was 17 in Computing Science class in high school. A friend had brought in some artwork his brother had printed on the mainframe at the University of Alberta. The source was a Fortran program with a huge number of punched cards as input. It certainly wouldn't be accepted anywhere here either. What I found quite intriguing was the ASCII art produced by arcane single line APL programs. You could pack a lot of function into a very few bytes of code. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org e**(i*pi)+1=0 From owner-freebsd-current@FreeBSD.ORG Thu Oct 7 23:16:45 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFD81106566C; Thu, 7 Oct 2010 23:16:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 90D168FC12; Thu, 7 Oct 2010 23:16:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o97NGiL4052836; Thu, 7 Oct 2010 19:16:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o97NGi07052834; Thu, 7 Oct 2010 23:16:44 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 7 Oct 2010 23:16:44 GMT Message-Id: <201010072316.o97NGi07052834@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 23:16:45 -0000 TB --- 2010-10-07 16:53:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-07 16:53:41 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-10-07 16:53:41 - cleaning the object tree TB --- 2010-10-07 16:56:13 - cvsupping the source tree TB --- 2010-10-07 16:56:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-10-07 17:00:56 - building world TB --- 2010-10-07 17:00:56 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-07 17:00:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-07 17:00:56 - TARGET=sparc64 TB --- 2010-10-07 17:00:56 - TARGET_ARCH=sparc64 TB --- 2010-10-07 17:00:56 - TZ=UTC TB --- 2010-10-07 17:00:56 - __MAKE_CONF=/dev/null TB --- 2010-10-07 17:00:56 - cd /src TB --- 2010-10-07 17:00:56 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 7 17:00:57 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Oct 7 21:50:14 UTC 2010 TB --- 2010-10-07 21:50:14 - generating LINT kernel config TB --- 2010-10-07 21:50:14 - cd /src/sys/sparc64/conf TB --- 2010-10-07 21:50:14 - /usr/bin/make -B LINT TB --- 2010-10-07 21:50:15 - building LINT kernel TB --- 2010-10-07 21:50:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-07 21:50:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-07 21:50:15 - TARGET=sparc64 TB --- 2010-10-07 21:50:15 - TARGET_ARCH=sparc64 TB --- 2010-10-07 21:50:15 - TZ=UTC TB --- 2010-10-07 21:50:15 - __MAKE_CONF=/dev/null TB --- 2010-10-07 21:50:15 - cd /src TB --- 2010-10-07 21:50:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 7 21:50:15 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64.sparc64/src/sys/LINT -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci_pci.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64.sparc64/src/sys/LINT -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c cc1: warnings being treated as errors /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c: In function 'xhci_setup_generic_chain_sub': /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: right shift count >= width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: right shift count >= width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: left shift count >= width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: left shift count >= width of type *** Error code 1 Stop in /src/sys/modules/usb/xhci. *** Error code 1 Stop in /src/sys/modules/usb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-07 23:16:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-07 23:16:44 - ERROR: failed to build lint kernel TB --- 2010-10-07 23:16:44 - 4033.84 user 12539.78 system 22983.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 00:43:57 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 897AE1065672; Fri, 8 Oct 2010 00:43:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5174A8FC21; Fri, 8 Oct 2010 00:43:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o980huZs055428; Thu, 7 Oct 2010 20:43:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o980huqg055427; Fri, 8 Oct 2010 00:43:56 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 8 Oct 2010 00:43:56 GMT Message-Id: <201010080043.o980huqg055427@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 00:43:57 -0000 TB --- 2010-10-07 18:54:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-07 18:54:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-10-07 18:54:35 - cleaning the object tree TB --- 2010-10-07 18:56:48 - cvsupping the source tree TB --- 2010-10-07 18:56:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-10-07 19:01:52 - building world TB --- 2010-10-07 19:01:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-07 19:01:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-07 19:01:52 - TARGET=sun4v TB --- 2010-10-07 19:01:52 - TARGET_ARCH=sparc64 TB --- 2010-10-07 19:01:52 - TZ=UTC TB --- 2010-10-07 19:01:52 - __MAKE_CONF=/dev/null TB --- 2010-10-07 19:01:52 - cd /src TB --- 2010-10-07 19:01:52 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 7 19:01:53 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Oct 7 23:42:31 UTC 2010 TB --- 2010-10-07 23:42:31 - generating LINT kernel config TB --- 2010-10-07 23:42:31 - cd /src/sys/sun4v/conf TB --- 2010-10-07 23:42:31 - /usr/bin/make -B LINT TB --- 2010-10-07 23:42:31 - building LINT kernel TB --- 2010-10-07 23:42:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-07 23:42:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-07 23:42:31 - TARGET=sun4v TB --- 2010-10-07 23:42:31 - TARGET_ARCH=sparc64 TB --- 2010-10-07 23:42:31 - TZ=UTC TB --- 2010-10-07 23:42:31 - __MAKE_CONF=/dev/null TB --- 2010-10-07 23:42:31 - cd /src TB --- 2010-10-07 23:42:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 7 23:42:31 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v.sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v.sparc64/src/sys/LINT -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci_pci.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v.sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v.sparc64/src/sys/LINT -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c cc1: warnings being treated as errors /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c: In function 'xhci_setup_generic_chain_sub': /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: right shift count >= width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: right shift count >= width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: left shift count >= width of type /src/sys/modules/usb/xhci/../../../dev/usb/controller/xhci.c:1540: warning: left shift count >= width of type *** Error code 1 Stop in /src/sys/modules/usb/xhci. *** Error code 1 Stop in /src/sys/modules/usb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-08 00:43:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-08 00:43:56 - ERROR: failed to build lint kernel TB --- 2010-10-08 00:43:56 - 3953.21 user 12352.39 system 20960.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 09:11:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B848A106566B; Fri, 8 Oct 2010 09:11:31 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4578FC0A; Fri, 8 Oct 2010 09:11:29 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA01714; Fri, 08 Oct 2010 12:11:28 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P48zA-000AID-HT; Fri, 08 Oct 2010 12:11:28 +0300 Resent-From: Andriy Gapon Resent-To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Resent-Date: Fri, 8 Oct 2010 12:11:28 +0300 Resent-Message-Id: <4CAEE040.8020401@freebsd.org> Resent-User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 Message-ID: <4CAEDF48.1030602@freebsd.org> Date: Fri, 08 Oct 2010 12:07:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BCDEBF6.3030609@icyb.net.ua> <20100423184412.GA5016@nargothrond.kdm.org> <4BD1FC74.3090504@freebsd.org> <4CA30B24.8040707@freebsd.org> In-Reply-To: <4CA30B24.8040707@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UID: 18468 X-Keywords: Cc: Subject: [HEADSUP] changes to cam_get_device() and cam_open_device() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 09:11:31 -0000 As there was no objections, I am going to commit changes to cam_get_device() that remove the following features: - ignoring 'r' and 'n' at the start of device name - ignoring whitespace at end of device name - parsing and ignoring slice and partition names in a device name cam(3) manual page is going to be updated to reflect the changes. This would simplify the code and disambiguate its behavior. Non-rewound and character disk/SCSI devices has not been supported for quite a while now. Support for parsing partition/slice names is incomplete (e.g. GPT scheme is not supported) and of questionable usefulness. Full diff is here: http://people.freebsd.org/~avg/cam.diff If you know of any functionality or application that would be broken by this change please stop me ASAP. Also, if you have any other reason to object to the change please speak up before the change is committed. Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 07:46:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E34BE1065673; Fri, 8 Oct 2010 07:46:24 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh6.mail.rice.edu (mh6.mail.rice.edu [128.42.201.4]) by mx1.freebsd.org (Postfix) with ESMTP id ACB748FC0C; Fri, 8 Oct 2010 07:46:24 +0000 (UTC) Received: from mh6.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh6.mail.rice.edu (Postfix) with ESMTP id 1D2A728F768; Fri, 8 Oct 2010 02:46:23 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh6.mail.rice.edu, auth channel Received: from mh6.mail.rice.edu ([127.0.0.1]) by mh6.mail.rice.edu (mh6.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id VAvAnF49UAPg; Fri, 8 Oct 2010 02:46:22 -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 mh6.mail.rice.edu (Postfix) with ESMTPSA id 7962528F743; Fri, 8 Oct 2010 02:46:22 -0500 (CDT) Message-ID: <4CAECC4D.90707@rice.edu> Date: Fri, 08 Oct 2010 02:46:21 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Andriy Gapon References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> In-Reply-To: <4CAE0060.7050607@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 08 Oct 2010 11:03:11 +0000 Cc: Alan Cox , Garrett Cooper , freebsd-current@freebsd.org Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 07:46:25 -0000 Andriy Gapon wrote: > on 01/10/2010 10:43 Andriy Gapon said the following: > >> The idea. We dump contiguously only pages with PDEs (which means both valid and >> invalid PDEs), valid pages with PTEs are dumped the same way as data physical >> pages (i.e. via dump_add_page, etc); no fake PTEs for 2MB pages. >> PDE area of the dump takes about 20MB as opposed to 1GB for PTE area (the math >> is obvious, but just in case). >> >> libkva is changed to treat former PTE area as PDE area and is also taught to >> understand PG_PS in PDE. >> There is now an overhead of having to first read a PTE page in V-to-P-to-offset >> lookup for !PG_PS case. Perhaps we could cache all PTEs in memory and have a >> lookup table for them, but I didn't bother with this possibly premature >> optimization at this time. >> >> There is an unrelated change in minidumpsys - "bitmap_frozen". >> I had to do it despite having a patch in my local tree to stop other CPUs on >> panic->dump. Code in dump path (peripheral disk driver, CAM, SIM driver, >> something else?) seems to do some memory allocations and change dump bitmap, >> which leads to a mismatch between dump size and dump bitmap; and also >> potentially to inconsistencies in the bitmap itself. So I decided that it's a >> good idea to freeze the bitmap once we decided what pages we want to dump. >> >> Some variables and structure fields with 'pte' in them should probably be >> renamed to have 'pde' instead. >> > > Here's an updated patch: > http://people.freebsd.org/~avg/amd64-minidump.3.diff > > I went ahead and changed 'pte' to 'pde' in various names. > Also, I ditched somewhat questionable "bitmap_frozen" approach and instead opted > for restarting a dump on a size mismatch. This was suggested by kib@. > Garret Cooper has pointed out some problems with bitmap_frozen approach. > I think that actual problem was a scenario where a dump is done, then the system > is allowed to continue and then another dump is done. An exotic case perhaps? :-) > > One probably desirable feature that is missing is backward compatibility in > libkvm. If that is a showstopper, then I'll have to work on preserving it. > > As usual, I will appreciate any feedback - reviews, testing, etc. > The kernel part of the patch looks good. That said, I have one suggestion. The current generation of AMD and Intel processors has support for 1GB pages. If you want to make sure that this change will last us a long time, I would suggest translating the old trick of generating a fake page table page for 2MB pages into generating a fake page directory page for 1GB pages, rather than disposing of this code. Alan From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 11:21:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 288631065679; Fri, 8 Oct 2010 11:21:28 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id B33BB8FC25; Fri, 8 Oct 2010 11:21:27 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 29DEBE8B9E; Fri, 8 Oct 2010 12:21:26 +0100 (BST) Received: from core.nessbank (client-86-31-20-104.midd.adsl.virginmedia.com [86.31.20.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 8 Oct 2010 12:21:25 +0100 (BST) From: Bruce Cran To: freebsd-current@freebsd.org Date: Fri, 8 Oct 2010 12:21:24 +0100 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.1; amd64; ; ) References: <4BCDEBF6.3030609@icyb.net.ua> <4CA30B24.8040707@freebsd.org> <4CAEDF48.1030602@freebsd.org> In-Reply-To: <4CAEDF48.1030602@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010081221.24584.bruce@cran.org.uk> Cc: freebsd-scsi@freebsd.org, Andriy Gapon Subject: Re: [HEADSUP] changes to cam_get_device() and cam_open_device() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 11:21:28 -0000 On Friday 08 October 2010 10:07:20 Andriy Gapon wrote: > Non-rewound and character disk/SCSI devices has not been supported for > quite a while now. Support for parsing partition/slice names is > incomplete (e.g. GPT scheme is not supported) and of questionable > usefulness. If we no longer create non-rewound and character device nodes then sa(4), mtio(4) and scd(4) should probably be updated at some point too. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 11:40:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ECEF106566B for ; Fri, 8 Oct 2010 11:40:28 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 219F68FC1F for ; Fri, 8 Oct 2010 11:40:27 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.27.254]) by work.netasq.com (Postfix) with ESMTPSA id D522A74007F for ; Fri, 8 Oct 2010 13:39:42 +0200 (CEST) From: Fabien Thomas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 8 Oct 2010 13:40:26 +0200 Message-Id: <7839CA44-E467-4C77-AC41-BF5389FFCCDC@netasq.com> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: OpenSSL 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fabien Thomas List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 11:40:28 -0000 Is there any plan to import OpenSSL 1.0 into the tree? Fabien From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 13:07:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A16B11065694; Fri, 8 Oct 2010 13:07:21 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 39F0B8FC16; Fri, 8 Oct 2010 13:07:20 +0000 (UTC) Received: from [194.32.164.28] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by gid1.gid.co.uk (8.14.2/8.14.2) with ESMTP id o98Cmj2d009007; Fri, 8 Oct 2010 13:48:45 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <4CAEDF48.1030602@freebsd.org> Date: Fri, 8 Oct 2010 13:48:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6690327C-C8E2-48C3-8982-812ED226975F@gid.co.uk> References: <4BCDEBF6.3030609@icyb.net.ua> <20100423184412.GA5016@nargothrond.kdm.org> <4BD1FC74.3090504@freebsd.org> <4CA30B24.8040707@freebsd.org> <4CAEDF48.1030602@freebsd.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: freebsd-scsi@freebsd.org, FreeBSD Current Subject: Re: [HEADSUP] changes to cam_get_device() and cam_open_device() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 13:07:21 -0000 Hi, On 8 Oct 2010, at 10:07, Andriy Gapon wrote: > As there was no objections, I am going to commit changes to = cam_get_device() > that remove the following features: >=20 > - ignoring 'r' and 'n' at the start of device name > - ignoring whitespace at end of device name > - parsing and ignoring slice and partition names in a device name >=20 > cam(3) manual page is going to be updated to reflect the changes. > This would simplify the code and disambiguate its behavior. >=20 > Non-rewound and character disk/SCSI devices has not been supported for = quite a > while now. [etc] Just a clarification, does this mean no /dev/nsa.. ? That would be a = showstopper for many tape users. -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 14:10:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 464241065675; Fri, 8 Oct 2010 14:10:53 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id D7D3E8FC27; Fri, 8 Oct 2010 14:10:52 +0000 (UTC) Received: from roadkill.tharned.org (11008@roadkill.tharned.org [75.145.12.185]) (authenticated bits=0) by roadkill.tharned.org (8.14.4/8.14.4) with ESMTP id o98DieQj013369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Oct 2010 08:44:40 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2010; t=1286545480; bh=dqYKxOUeVx3n1UfPoTBk/kSWJxcraKNE1mKOvkMMEek=; l=1218; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=BeqytzSRQw2Tkmuz9rBpOlpjYRIuXWDrpQ0iml0duPjIPv3Q2vm9UKhKOWim6DvDe wHIoKelzDv5n3fVf4NjAn+CiJjtCKMuAhxO8YCSBfMMxoOL3xNjiSSbSD3IxStXeNo 25+0J1X+W1GGwTQWTYMRReHQHpuD+zySuVz3DGpE= Date: Fri, 8 Oct 2010 08:44:40 -0500 (CDT) From: Greg Rivers To: Andriy Gapon In-Reply-To: <6690327C-C8E2-48C3-8982-812ED226975F@gid.co.uk> Message-ID: References: <4BCDEBF6.3030609@icyb.net.ua> <20100423184412.GA5016@nargothrond.kdm.org> <4BD1FC74.3090504@freebsd.org> <4CA30B24.8040707@freebsd.org> <4CAEDF48.1030602@freebsd.org> <6690327C-C8E2-48C3-8982-812ED226975F@gid.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 succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (roadkill.tharned.org [75.145.12.185]); Fri, 08 Oct 2010 08:44:40 -0500 (CDT) Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADSUP] changes to cam_get_device() and cam_open_device() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 14:10:53 -0000 On Fri, 8 Oct 2010, Bob Bishop wrote: > On 8 Oct 2010, at 10:07, Andriy Gapon wrote: > >> As there was no objections, I am going to commit changes to >> cam_get_device() that remove the following features: >> >> - ignoring 'r' and 'n' at the start of device name >> - ignoring whitespace at end of device name >> - parsing and ignoring slice and partition names in a device name >> >> cam(3) manual page is going to be updated to reflect the changes. This >> would simplify the code and disambiguate its behavior. >> >> Non-rewound and character disk/SCSI devices has not been supported for >> quite a while now. [etc] > > Just a clarification, does this mean no /dev/nsa.. ? That would be a > showstopper for many tape users. > Yes, the no-rewind tape device is a practical requirement. I think it's ok for 'r' to go away for disk devices, but 'n' for tape devices needs to be retained. If we really want to remove the 'n', then all tape devices need to be no-rewind on close, and the rewind-on-close devices need to be deprecated just like the block devices for disks were. Of course doing this would change traditional behavior and might violate POLA. -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 15:31:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A00CA106566B for ; Fri, 8 Oct 2010 15:31:09 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 1DAA28FC19 for ; Fri, 8 Oct 2010 15:31:09 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id D16FB1D1C70 for ; Fri, 8 Oct 2010 17:31:07 +0200 (CEST) Authentication-Results: mail.ijs.si; dkim=pass (1024-bit key) header.i=@ijs.si; dkim-adsp=pass DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:user-agent:date:date:subject:subject:organization :from:from:received:received:received; s=jakla2; t=1286551865; x=1289143865; bh=smBcI4WWooOtAfAHobl6IPE2tiqIVpiQsA71Lxlgw4k=; b= ce/OzvvdyhNbbsVDYV8AGdjySuOhJI10oVDUYafyV2Qn1KuLX1waND92HmBNaDDo K1jopEETNr6DJx+gXSdxivIsC+ruhKs3L19U3W/KuqVDWg1lKOM1uyig+GqZohwa UYNJRP8WdYgsr/ELISsmJUqD5KxbBYy/vObH/ri6r2U= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id VWRjFAE5V_Hn for ; Fri, 8 Oct 2010 17:31:05 +0200 (CEST) Received: from edina.ijs.si (unknown [IPv6:2001:1470:ff80:0:2e0:81ff:fe72:51d]) by mail.ijs.si (Postfix) with ESMTP for ; Fri, 8 Oct 2010 17:31:05 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by edina.ijs.si (Postfix) with ESMTPSA id 6C63922F2BD for ; Fri, 8 Oct 2010 17:31:05 +0200 (CEST) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-current@freebsd.org Date: Fri, 8 Oct 2010 17:31:03 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.1; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201010081731.04127.Mark.Martinec+freebsd@ijs.si> Subject: Support for newer Ethernet chips in RE(4) driver? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:31:09 -0000 The current re(4) Realtek Ethernet adapter driver supports the 8139C+/8169/816xS/811xS/8101E chips, but lacks support for newer Realtek network interface controllers such as RTL8111 C/E/D, the RTL8168 series and some other. This is unfortunate as the RTL8111E and RTL8111D controllers found their way (in singles or in pairs) into the current families of GigaByte motherboards (such as GA-X58A-UD9/7/5/3R, GA-H55M*, ...), and RTL8111C found its way into Asus motherboards (such as P6T), and quite likely into other newer products. An updated re driver source for FreeBSD 8.0 is available from the Realtek's web site ( http://www.realtek.com.tw/downloads/ ) and claims to add support for chips and chipsets: RTL8111/RTL8111B/RTL8111C/RTL8111CP/RTL8111D(L)/RTL8111DP/RTL8111E RTL8168/RTL8168B/RTL8168C/RTL8168CP/RTL8168D/RTL8168E RTL8169S/RTL8169SB/RTL8169SC RTL8101E/RTL8102E/RTL8103E/RTL8401E/RTL8105E I tested the new Realtek driver with RTL8111E on FreeBSD 8.1-RELEASE, works well. Any chance of importing the updated driver (or adding support for newer chips in some other way) into CURRENT so that it could find its way to the 9.0 ? Mark From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 17:02:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00FD1106566B for ; Fri, 8 Oct 2010 17:02:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id C6B2B8FC17 for ; Fri, 8 Oct 2010 17:02:31 +0000 (UTC) Received: by pxi17 with SMTP id 17so399345pxi.13 for ; Fri, 08 Oct 2010 10:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=w/xHa35DOVmvOtk2XxbzzKYHXbNPrxEDelru7/ZsT/M=; b=vEYNDVjz5UgUkPFOY3u+5mKO9hC4Cb22Wo3pUTEkBT8adXfCchnz79/Jarezz3B2G1 gpZ+SeGJ1NZHOH4fQJVDZAK/lcrSuUNn30AEv31inFDtgliT9sfol4AJ8N+UXceaXBdY 1frni5Xrcv1WlnFSixI5kpTLwd/Ui1IJOdXEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=GZl74tZ2yZe6S7oScKHPHg+0Q8QuxpUUMGipdbIXUFUSrsnepSqWqT9IruMGTgXOf9 VOq0oFo9czp0eK8TKQYxfr6lfjv3+9HwmrLWw24p54d8vQbiVC62q2WGF3Ug4DsP7QEA gD7fNEON4fjBlvjVdGED2Z/NvtOWH8J3rRyx4= Received: by 10.142.13.19 with SMTP id 19mr2228183wfm.406.1286557351196; Fri, 08 Oct 2010 10:02:31 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id p8sm3914944wff.4.2010.10.08.10.02.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Oct 2010 10:02:29 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 8 Oct 2010 10:00:46 -0700 From: Pyun YongHyeon Date: Fri, 8 Oct 2010 10:00:45 -0700 To: Mark Martinec Message-ID: <20101008170045.GA25411@michelle.cdnetworks.com> References: <201010081731.04127.Mark.Martinec+freebsd@ijs.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010081731.04127.Mark.Martinec+freebsd@ijs.si> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Support for newer Ethernet chips in RE(4) driver? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:02:32 -0000 On Fri, Oct 08, 2010 at 05:31:03PM +0200, Mark Martinec wrote: > The current re(4) Realtek Ethernet adapter driver supports the > 8139C+/8169/816xS/811xS/8101E chips, but lacks support for newer > Realtek network interface controllers such as RTL8111 C/E/D, > the RTL8168 series and some other. > Actually re(4) supports much more controllers than that. Man page needs updating to reflect this. > This is unfortunate as the RTL8111E and RTL8111D controllers > found their way (in singles or in pairs) into the current families > of GigaByte motherboards (such as GA-X58A-UD9/7/5/3R, GA-H55M*, ...), > and RTL8111C found its way into Asus motherboards (such as P6T), > and quite likely into other newer products. > RTL8111C/D/DP are supported. Because there are too many variants there might be some revisions which are not supported yet but I didn't see any other reports that request supports for newer RealTek controllers. > An updated re driver source for FreeBSD 8.0 is available from > the Realtek's web site ( http://www.realtek.com.tw/downloads/ ) > and claims to add support for chips and chipsets: > > RTL8111/RTL8111B/RTL8111C/RTL8111CP/RTL8111D(L)/RTL8111DP/RTL8111E > RTL8168/RTL8168B/RTL8168C/RTL8168CP/RTL8168D/RTL8168E > RTL8169S/RTL8169SB/RTL8169SC > RTL8101E/RTL8102E/RTL8103E/RTL8401E/RTL8105E > Specifically I don't know RTL8104E/RTL8105E controllers but others would be supported by re(4). > I tested the new Realtek driver with RTL8111E on FreeBSD 8.1-RELEASE, > works well. > Does stock re(4) fail to recognize your controller? If yes, please send me dmesg output(pciconf output is useless for RealTek controllers). > Any chance of importing the updated driver (or adding support I don't see any reason importing their driver. > for newer chips in some other way) into CURRENT so that it > could find its way to the 9.0 ? > As I said if your controller is not supported by re(4), show me more information about your controller. From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 17:56:54 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50181106564A; Fri, 8 Oct 2010 17:56:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id CA66D8FC15; Fri, 8 Oct 2010 17:56:53 +0000 (UTC) Received: by qyk35 with SMTP id 35so1655394qyk.13 for ; Fri, 08 Oct 2010 10:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=IfT9LvQeZ7d8Fha5IgG/+Bcw7wrmkdRWLV/iXuZgX/0=; b=gfHOxnO9/UJziGsPuGVuN1MU/g17YHv5vOEacVIPxF/CGhXp0RL2siE3UcqnceAaAj W7U9DgTQOqqZF6PxJS3YOg070/i3LtmvKXqE2AVKN31k9vDM0rFqtphWb5Q2oO7/Ok6u wsNgbPhjROBIC9ntKtu1phADFeo3MFTIk3HQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cFQ7wsMN/BXNjlXR5ChnLMUmAuNW48z4IxapFiqGYNBxqKI1rv8efHqBns5cW/dOs/ uCXOJ5Oaby2Zjr08Uuv2p2qSCeZ1EMs7DJLMHhM+kE9u3ixpfbrqKxyyB/5clLCA5qE4 LAMFg7SO4tW1J1l3pDU89OZvMO+bSXcnOuKVk= MIME-Version: 1.0 Received: by 10.224.27.225 with SMTP id j33mr1784127qac.228.1286560612490; Fri, 08 Oct 2010 10:56:52 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Fri, 8 Oct 2010 10:56:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Oct 2010 19:56:52 +0200 X-Google-Sender-Auth: vz1p3-LAsWxNWYFZNLhJwF6QtDk Message-ID: From: Attilio Rao To: freebsd-net@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jack F Vogel , Ryan Stone , Sergey Kandaurov , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:56:54 -0000 2010/9/28 Attilio Rao : > In the last weeks I worked for porting the netdump infrastructure to > FreeBSD-CURRENT on the behalf of Sandvine Incorporated. > Netdump is a framework that aims for handling kernel coredumps over > the TCP/IP suite in order to dump to a separate machine than the > running one. That may be used on an interesting number of cases > involving disk-less workstations, disk driver debugging or embedded > devices. > > GENERAL FRAMEWORK ARCHITECTURE > > Netdump is composed, right now, by an userland "server" and a kernel > "client". The former is run on the target machine (where the dump will > phisically happen) and it is responsible for receiving =C2=A0the packets > containing coredumps frame and for correctly writing them on-disk. > The latter is part of the kernel installed on the source machine > (where the dump is initiated) and is responsible for building > correctly UDP packets containing the coredump frames, pushing through > the network interface and routing them appropriately. > > While the server may appear as, pretty much, a simple userland deamon > dealing with UDP packets, the client imposes interesting problems as > long as its activity is linked to handling kernel core dumping. More > precisely, as long as the client is part of the dumping mechanism and > the kernel may be in general panic conditions, netdump must ensure > "robustness" of operations. That is partially achieved by reworking > (and someway replicating) locally some UDP, ARP and IP operations, > hardsetting some values (like the default gateway, the destination and > the client address) and reducing further interactions with the kernel > just to the network interface acitivities. > More specifically, it implements a very basic UDP / IPv4 / ARP stack > separate from the standard stack (since that may not be in a > consistent state). > It can dump to a server on the same LAN or via a router (correctly > specifying the connection gateway). > In order to receive packet on critical conditions, netdump polls the > interface. Every network driver can implement hooks to be used by > netdump independently by DEVICE_POLLING option, even if it is > probabilly a good idea to share some code among them. The reference > set of hooks is contained into "struct netdump_methods". > And if_lem/if_em driver modifies may be set as reference for netdump > hooks implementation. > > In order to work into an "up and running" system (meant as with all > the devices in place) the netdump handler hooks as a pre-sync handler > (differently from other dumping routines). It however suffers some > problems typical of other dumping mechanism. For example, on DDB > entering unlocked version of polling handler is used, in order to > reduce the risk of deadlocks during inspections*. That reflects, among > the netdump methods, the existence of 2 versions of polling hooks, > where the "unlocked" is meant as reducing locking as much as possible. > > PATCH AND FURTHER WORK > > The patch is not totally complete and it is not intended to be > committed in SVN yet. What I'm looking for now is more testing and > review (in particular in terms of architecture) coverage by community. > The server should be in realtively "committable" state, though, but I > encourage its stress-testing. A manpage is provided along that should > be very easy to understand how to use it. > > Things that can be further improved, as it is now, in the client, are: > - Deciding if hardcoding of the kernel parameter is done properly. I > personally don't like the sysctl usage and I would prefer an userland > small utility used to testing and maybe add some tunables for enabling > netdump early in the boot. You may have several opinions on this > though. > - VIMAGE and IPv6 support. > - More drivers support. Right now only if_em (and if_lem) are > converted to use netdump and can be used as a draft for other device > drivers. if_ixgb should came along in the final, committing, version > too. In general I think that all drivers supporting device polling > could easilly support also netdump > - Ideally dumpsys() in FreeBSD is too much disk-activity oriented. It > should be made, instead, more neutral and more flexible to cope better > with different interfaces. It is a quite a bit of work, however, and > beyond the scope of netdump introduction (even if it could be > beneficial for it) > > Netdump has been developed on a FreeBSD project branch located here: > svn://svn.freebsd.org/base/projects/sv/ > > which could also forsee further informations about every single > change. However, for your convenience, also a patch has been made > public which is located here (against FreeBSD-CURRENT@213246): > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_0= .diff This followup is made in order to signal the code has been further refined and some bugfixes (reported mostly by pluknet@ testing) have been fixed. More support for interfaces has been added (igb, ixgb, ixgbe). You can fetch the sourcecode from projects/sv/, as described in previous e-mail, or use this other patch: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_1.d= iff I didn't try netdump with VIMAGE, but for people willing to do that, they can apply the following further patch, on top of the projects/sv/ patchset and report: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_1.f= ix.diff That is not contained in the "official" projects/sv/. Right now I plan to just move netdump_client.c to be style compliant and add further comments, and eventually commit all the infrastructure on next Friday, 15th October, if no problems are reported by reviewers and testers. You are encouraged to review and test it (and in particular I added jfv@ and rstone@ on CC in order to give them a look at driver specific parts). Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 19:08:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FD631065775; Fri, 8 Oct 2010 19:08:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A339D8FC15; Fri, 8 Oct 2010 19:08:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 48C9246B32; Fri, 8 Oct 2010 15:08:44 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3FFBC8A04F; Fri, 8 Oct 2010 15:08:43 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 8 Oct 2010 15:01:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CAE0621.3070809@freebsd.org> In-Reply-To: <4CAE0621.3070809@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201010081501.18870.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 08 Oct 2010 15:08:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: hackers@freebsd.org, Andriy Gapon Subject: Re: panic_cpu should be volatile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:08:45 -0000 On Thursday, October 07, 2010 1:40:49 pm Andriy Gapon wrote: > > panic_cpu variable in kern_shutdown.c should be volatile otherwise it's cached in > a register in the innermost while-loop in this code (observed on amd64 with base > gcc and -O2): > if (panic_cpu != PCPU_GET(cpuid)) > while (atomic_cmpset_int(&panic_cpu, NOCPU, > PCPU_GET(cpuid)) == 0) > while (panic_cpu != NOCPU) > ; /* nothing */ > > The patch is here: > http://people.freebsd.org/~avg/panic_cpu.diff > > I also took a liberty to move the variable into the scope of panic() functions as > it doesn't seem to be useful outside of it. But this is not necessary, of course. Looks fine to me. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 8 21:42:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E5451065674; Fri, 8 Oct 2010 21:42:25 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE858FC0C; Fri, 8 Oct 2010 21:42:25 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id C388611BA21; Fri, 8 Oct 2010 16:42:24 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id G19X18RC0JSJ; Fri, 08 Oct 2010 16:42:24 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <7839CA44-E467-4C77-AC41-BF5389FFCCDC@netasq.com> Date: Fri, 8 Oct 2010 22:42:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7839CA44-E467-4C77-AC41-BF5389FFCCDC@netasq.com> To: Fabien Thomas X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org Subject: Re: OpenSSL 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 21:42:25 -0000 On 8 Oct 2010, at 12:40, Fabien Thomas wrote: >=20 > Is there any plan to import OpenSSL 1.0 into the tree? You should ask the maintainers. I suspect it's just a matter of = available time (for them). Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sat Oct 9 01:15:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C316106564A; Sat, 9 Oct 2010 01:15:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 46B078FC13; Sat, 9 Oct 2010 01:15:40 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id BC9EC46B5C; Fri, 8 Oct 2010 21:15:39 -0400 (EDT) Date: Sat, 9 Oct 2010 02:15:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1924871622-1286586939=:1232" Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 01:15:40 -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. --621616949-1924871622-1286586939=:1232 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 8 Oct 2010, Attilio Rao wrote: >> GENERAL FRAMEWORK ARCHITECTURE >> >> Netdump is composed, right now, by an userland "server" and a kernel >> "client". The former is run on the target machine (where the dump will >> phisically happen) and it is responsible for receiving  the packets >> containing coredumps frame and for correctly writing them on-disk. The >> latter is part of the kernel installed on the source machine (where the >> dump is initiated) and is responsible for building correctly UDP packets >> containing the coredump frames, pushing through the network interface and >> routing them appropriately. Hi Attilio: Network dumps would be a great addition to the FreeBSD debugging suite! A few casual comments and questions, I need to spend some more time pondering the implications of the current netdump design later in the week. (1) Did you consider using tftp as the network dump protocol, rather than a custom protocol? It's also a simple UDP-based, ACKed file transfer protocol, with the advantage that it's widely supported by exiting tftp daemons, packet sniffers, security devices, etc. This wouldn't require using a stock tftpd, although that would certainly be a benefit as well. The post-processing of crashdumps that seems to happen in the netdump server could, presumably, happen "offline" as easily...? (2) Have you thought about adding a checksum to the dump format, since packets are going over the wire on UDP, etc? Even an MD5 sum wouldn't be too hard to arrange: all the code is in the kernel already, requires relatively little state storage, and is designed for streamed data. (3) As the bounds checking/etc behavior in dumping grows more complex, it seems a shame to replicate it in architecture-specific code. Could we pull the mediaoffset/mediasize checking into common code? Also, a reserved size/offset of "0" meaning "no limit" sounds slightly worrying; it might be slightly more conservative to add a flags field to dumperinfo and have a flag indicating "size is no object" for netdump, rather than overloading the existing fields. Some specific patch comments: + * XXX: This should be split into machdep and non-machdep parts What MD parts are in the file? The sysctl parts of the patch have a number of issues: - Please use sysctl_handle_string rather than manual calls and string bounds checking with SYSCTL_IN/SYSCTL_OUT. In general, type-specific sysctl handlers are named sysctl_handle_, which I recommend here as well. - Please use stack-local, fixed-length string buffers as the source/destination of copyin/copyout on ifnet names, rather than the fields in the structure itself. We support interface renaming, so the field can change, and sysctl has the potential to block for extended periods mid-copyin/copyout. - Because we support ifnet renaming, "none" is probably not a good reserved name. Could you use the empty string or something similar, or just a flag to indicate that netdump is disabled? - "ifp" rather than "ifn" and "nic" is the preferred variable name for ifnet pointers throughout the kernel. - ifnets can, and are, removeable at runtime. We have a refcount, but that's not really what you want. I suggest simply looking up the ifnet by name when it's needed during a dump or for sysctl output, rather than maintaining a long-term pointer, which can become stale. Especially with the auto-detect code. - Since sysctl_nic is only used once, I'd prefer it were inlined into a use-specific handler function, avoiding the arg1/arg2 complications that make this code a bit harder to read. sysctl_ip is useful because it's used more than once, though. However, it also very much wants you to call sysctl_handle_string! +sysctl_force_crash(SYSCTL_HANDLER_ARGS) Does this belong in the netdump code? We already have some of these options in debug.kdb.*, but perhaps others should be added there as well. + /* + * get and fill a header mbuf, then chain data as an extended + * mbuf. + */ + MGETHDR(m, M_DONTWAIT, MT_DATA); The idea of calling into the mbuf allocator in this context is just freaky, and may have some truly awful side effects. I suppose this is the cost of trying to combine code paths in the network device driver rather than have an independent path in the netdump case, but it's quite unfortunate and will significantly reduce the robustness of netdumps in the face of, for example, mbuf starvation. + if (ntohs(ah->ar_hrd) != ARPHRD_ETHER && + ntohs(ah->ar_hrd) != ARPHRD_IEEE802 && + ntohs(ah->ar_hrd) != ARPHRD_ARCNET && + ntohs(ah->ar_hrd) != ARPHRD_IEEE1394) { + NETDDEBUG("nd_handle_arp: unknown hardware address fmt " + "0x%2D)\n", (unsigned char *)&ah->ar_hrd, ""); + return; + } Are you sure you don't want to just check for ETHER here? + /* XXX: Probably should check if we're the recipient MAC address */ + /* Done ethernet processing. Strip off the ethernet header */ Yes, quite probably. What if you panic in promiscuous mode? + /* + * The first write (at offset 0) is the kernel dump header. Flag it + * for the server to treat specially. XXX: This doesn't strip out the + * footer KDH, although it shouldn't hurt anything. + */ The footer allows us to confirm that the tail end of a dump matches the beginning; while probably not strictly necessary in this scenario, it's not a bad idea given the lack of a checksum. + /* Default the nic to the first available interface */ + if ((ifn = TAILQ_FIRST(&ifnet)) != NULL) do { + if ((ifn->if_flags & IFF_UP) == 0) + continue; More locking needed. I'm not sure I like the idea of defaulting to net dumping out the first interface -- in the future, we'll want to compile netdump into the kernel in GENERIC so that it's always available. But we won't want to default to doing the above for a number of reasons. This means the defaults need to be sensible and quite conservative (i.e., disabled and non-autoconfigured). + /* Default the client to the first IP on nd_nic */ + if ((ifa = TAILQ_FIRST(&nd_nic->if_addrhead)) != NULL) do { + if (ifa->ifa_addr->sa_family != AF_INET) { + continue; + } + nd_client = ((struct sockaddr_in *)ifa->ifa_addr)->sin_addr; + } while ((ifa = TAILQ_NEXT(ifa, ifa_link)) != NULL && + nd_client.s_addr == INADDR_ANY); More locking needed here too. I'm guess this code is forward-ported from an older FreeBSD version without locking here, so you will want to check for other changes in the replicated code paths, such as input / arp / etc handling. And is this really a good idea? Addresses change, and I think you aren't registering a callback to pick up the change in the event you're using an auto-configured address. In some ways, in the same way you might want to look up the ifnet to use at dump-time, you might simultaneously want to auto-configure an address then, if auto-configuration is selected (i.e., netdump is enabled and no IP is configured). - void *if_pspare[7]; + struct netdump_methods *if_ndumpfuncs; /* netdump virtual methods */ + void *if_pspare[6]; int if_ispare[4]; In HEAD, at least, you should add your field and not use the spare. The spare should only be used on a merge to a KBI-stable branch (such as 8.x). I need to ponder your changes to ifnet and to the drivers some more; I recognize the benefits of maximal code alignment, but I worry a lot about these code paths having side effects (not least, calls into memory allocators, which in turn can enter VM, etc). I wonder if, given that, we need to teach the mbuf allocator to be much more conservative if netdumping is active... There are style bugs throughout. Robert --621616949-1924871622-1286586939=:1232-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 9 01:24:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BE69106564A for ; Sat, 9 Oct 2010 01:24:53 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 99D148FC0C for ; Sat, 9 Oct 2010 01:24:52 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 83BE21D1C09 for ; Sat, 9 Oct 2010 03:24:51 +0200 (CEST) Authentication-Results: mail.ijs.si; dkim=pass (1024-bit key) header.i=@ijs.si; dkim-adsp=pass DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :organization:mime-version:in-reply-to:references:user-agent :date:date:subject:subject:from:from:received:received:received; s=jakla2; t=1286587488; x=1289179488; bh=ZcNgQOv+sMmwV4/4Ab4dFG jKG+Krb2BlN1PMAvxsTP4=; b=jHCrkM/eEOj7ai5PFh9U2r0l6hPlBnoXAaVDxa tXr+hSEmlcdEC/EoUgiiONBdNQKJSG/eJlBLEr+5o7oNp+ZXxMXAq62qPzw7zIjm o14h/Z2EGk6kthVXrtpXGrsfLRQgejHTprlJ4UyOBVa1RYij4moDipvlvB6dthR+ nqTkY= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id tPJFpvg1W08i for ; Sat, 9 Oct 2010 03:24:48 +0200 (CEST) Received: from edina.ijs.si (unknown [IPv6:2001:1470:ff80:0:2e0:81ff:fe72:51d]) by mail.ijs.si (Postfix) with ESMTP for ; Sat, 9 Oct 2010 03:24:48 +0200 (CEST) Received: from siesta.ijs.si (upc.si.94.140.92.23.dc.cable.static.telemach.net [94.140.92.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by edina.ijs.si (Postfix) with ESMTPSA id 93CCB22EFA1 for ; Sat, 9 Oct 2010 03:24:48 +0200 (CEST) From: Mark Martinec To: freebsd-current@freebsd.org Date: Sat, 9 Oct 2010 03:24:47 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.2; amd64; ; ) References: <201010081731.04127.Mark.Martinec+freebsd@ijs.si> <20101008170045.GA25411@michelle.cdnetworks.com> In-Reply-To: <20101008170045.GA25411@michelle.cdnetworks.com> MIME-Version: 1.0 Organization: J. Stefan Institute Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010090324.47592.Mark.Martinec+freebsd@ijs.si> Subject: Re: Support for newer Ethernet chips in RE(4) driver? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 01:24:53 -0000 On Friday October 8 2010 19:00:45 Pyun YongHyeon wrote: > Actually re(4) supports much more controllers than that. > Man page needs updating to reflect this. False alarm. Indeed it does work with RTL8111E. I was distracted by the lack of its mention on the man page, and by the presence of a FreeBSD 8.0 re(4) driver on the Realtek's web page, whose source code is much larger than the base driver from the FreeBSD 8.1 distribution. Updating the docs could help others deciding what hw to purchase or what OS to run on it. > Does stock re(4) fail to recognize your controller? If yes, please > send me dmesg output (pciconf output is useless for RealTek > controllers). The same report in dmesg comes from using either the base or the vendor's driver, so no problems there. Here it is anyway (the second of the two ethernet controllers): pcib8: irq 17 at device 28.5 on pci0 pci8: on pcib8 re1: port 0xbe00-0xbeff mem 0xfbaff000-0xfbafffff,0xfbaf8000-0xfbafbfff irq 17 at device 0.0 on pci8 re1: Using 1 MSI messages re1: Chip rev. 0x2c000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 6c:f0:49:ef:99:e7 re1: [FILTER] and ifconfig tells: re1: flags=8843 metric 0 mtu 1500 options=389b ether 6c:f0:49:ef:99:e7 inet6 fe80::6ef0:49ff:feef:99e7%re1 prefixlen 64 scopeid 0x2 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active Thanks for a prompt response! Mark From owner-freebsd-current@FreeBSD.ORG Sat Oct 9 09:55:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C40071065679; Sat, 9 Oct 2010 09:55:46 +0000 (UTC) (envelope-from Zdenek.Roubicek@t-systems.cz) Received: from mx2.t-systems.cz (mx2o.t-systems.cz [212.67.76.203]) by mx1.freebsd.org (Postfix) with ESMTP id 220208FC18; Sat, 9 Oct 2010 09:55:45 +0000 (UTC) X-AuditID: d4434cc9-b7c66ae000007e6b-5f-4cb0389abc44 Received: from SRVPP06.t-systems.cz (Unknown_Domain [10.246.109.17]) by mx2.t-systems.cz (TSSMSGW) with SMTP id B7.E0.32363.A9830BC4; Sat, 9 Oct 2010 11:40:42 +0200 (CEST) Received: from SRVPPE02.t-systems.cz ([10.246.109.16]) by SRVPP06.t-systems.cz ([10.246.109.17]) with mapi; Sat, 9 Oct 2010 11:40:42 +0200 From: =?iso-8859-2?Q?Roub=ED=E8ek_Zden=ECk?= To: Rui Paulo , Fabien Thomas Date: Sat, 9 Oct 2010 11:37:49 +0200 Thread-Topic: OpenSSL 1.0 Thread-Index: ActnMeYR9bg2ewW1RIy+AD2YAZOgDgAY7zq1 Message-ID: References: <7839CA44-E467-4C77-AC41-BF5389FFCCDC@netasq.com>, In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, cs-CZ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Sat, 09 Oct 2010 11:12:13 +0000 Cc: "freebsd-current@freebsd.org" Subject: RE: OpenSSL 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 09:55:46 -0000 I would be also happy to see that coming as I have a problem using current = openssl as ipv6 client for tests, though it is bsd v7.3. Sorry for not providing anything more then just my wish. regards, zdenek ________________________________________ From: owner-freebsd-current@freebsd.org [owner-freebsd-current@freebsd.org]= On Behalf Of Rui Paulo [rpaulo@FreeBSD.org] Sent: Friday, October 08, 2010 11:42 PM To: Fabien Thomas Cc: freebsd-current@freebsd.org Subject: Re: OpenSSL 1.0 On 8 Oct 2010, at 12:40, Fabien Thomas wrote: > > Is there any plan to import OpenSSL 1.0 into the tree? You should ask the maintainers. I suspect it's just a matter of available t= ime (for them). Regards, -- Rui Paulo _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"