From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 00:55: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 CC1CD106564A for ; Sun, 21 Mar 2010 00:55:05 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFFB8FC08 for ; Sun, 21 Mar 2010 00:55:04 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,280,1267398000"; d="scan'208";a="28927954" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 21 Mar 2010 01:55:02 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 536671B0768; Sun, 21 Mar 2010 01:55:02 +0100 (CET) Date: Sun, 21 Mar 2010 01:55:01 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: <201003171654.15017.ken@mthelicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: build failures after stdlib update 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, 21 Mar 2010 00:55:06 -0000 ok. i think i finally solved this riddle. the cause for the problem seems to have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've been using the 'native' keyword for years now and never had any problems with it, but it seems a recent commit broke 'native' as CPUTYPE. for me this is 100% reproducable: 1. put 'CPUTYPE = native' in /etc/make.conf 2. build and install gnu/usr.bin/cc 3. do 'buildkernel' or 'buildworld' and observe the segfault. for some reason this always occurs in lib/libc/string/strlen.c (r205108). i've tested this with older version of libc.so (built 22. Feb) and got the same result. so i assume this is not a libc problem, but a problem with gcc tripping over some code in libc. i have no clue however why this happend just now and not earlier. i don't think there has been a recent commit to gcc. to solve this there are two ways: 1. set CPUTYPE to 'nocona' (i'm running amd64). this will let you compile everything just fine even with a gcc that has itself been built with 'CPUTYPE = native'. 2. build and install gnu/usr.bin/cc with 'CPUTYPE = nocona'. the gcc version that has been built this way will compile everything just fine even with 'CPUTYPE = native'. the only way to break this is to go and compile gcc again with the CPUTYPE set to 'native'. so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to 'native' will give you a broken gcc! cheers. alex ps: i don't know if the situation is the same on archs != amd64. i could only test this on amd64. From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 02:28:15 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 396FA106566B for ; Sun, 21 Mar 2010 02:28:15 +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 7985C8FC0C for ; Sun, 21 Mar 2010 02:28:14 +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 EAA24068; Sun, 21 Mar 2010 04:28:11 +0200 (EET) (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 1NtAte-0009sM-PA; Sun, 21 Mar 2010 04:28:10 +0200 Message-ID: <4BA58439.8070304@icyb.net.ua> Date: Sun, 21 Mar 2010 04:28:09 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Alexander Best References: <201003171654.15017.ken@mthelicon.com> 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 Subject: Re: build failures after stdlib update 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, 21 Mar 2010 02:28:15 -0000 on 21/03/2010 02:55 Alexander Best said the following: > ok. i think i finally solved this riddle. the cause for the problem seems to > have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've > been using the 'native' keyword for years now and never had any problems with > it, but it seems a recent commit broke 'native' as CPUTYPE. for me this is > 100% reproducable: > > 1. put 'CPUTYPE = native' in /etc/make.conf > 2. build and install gnu/usr.bin/cc > 3. do 'buildkernel' or 'buildworld' and observe the segfault. for some reason > this always occurs in lib/libc/string/strlen.c (r205108). i've tested this > with older version of libc.so (built 22. Feb) and got the same result. so i > assume this is not a libc problem, but a problem with gcc tripping over some > code in libc. i have no clue however why this happend just now and not > earlier. i don't think there has been a recent commit to gcc. Interestingly enough, there have recent commits to lib/libc/string/strlen.c. > to solve this there are two ways: > > 1. set CPUTYPE to 'nocona' (i'm running amd64). this will let you compile > everything just fine even with a gcc that has itself been built with 'CPUTYPE > = native'. > 2. build and install gnu/usr.bin/cc with 'CPUTYPE = nocona'. the gcc version > that has been built this way will compile everything just fine even with > 'CPUTYPE = native'. the only way to break this is to go and compile gcc again > with the CPUTYPE set to 'native'. > > so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to 'native' will > give you a broken gcc! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 04:48:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29ED2106566C for ; Sun, 21 Mar 2010 04:48:00 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by mx1.freebsd.org (Postfix) with ESMTP id F2E6E8FC12 for ; Sun, 21 Mar 2010 04:47:59 +0000 (UTC) Received: by pxi14 with SMTP id 14so2683382pxi.15 for ; Sat, 20 Mar 2010 21:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LFg4dJUrirA9VDm5F7pjXF8gyLAYR8dNbW0LXcAMz2s=; b=YR31/t6gHWkKNiuQoOX+n2u5Hm2rACoPL6HtmkqfFbliOhS657gH5BVP9ASVvQPuJi VJRcsLb92dFJQWaine9HHZ9lupsyoULiCXTJmBb77pKhLzVQaQohEp/I90u7E7afhcIM XChis3yD3+rNoEwBYexkJcEwWXFKYycDwuyfc= 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=wGv3LBbdIBDvjX5u4kJkz9WSIn3NpIAgSOtqxahPLmcbIzW+oD5CJizZPyYRayOnzr 1V1V7YgXAuNxouAl0linSWZLI1FAwck5sj3bEu9fp9Bou+tqYao0VJ8b7ZgLW/fPN3yN A3weOeTTDypPhDuXsF0em+8DTE4UVd8iZsA1s= MIME-Version: 1.0 Received: by 10.142.152.34 with SMTP id z34mr800250wfd.176.1269146879561; Sat, 20 Mar 2010 21:47:59 -0700 (PDT) In-Reply-To: References: <201003171654.15017.ken@mthelicon.com> Date: Sat, 20 Mar 2010 21:47:59 -0700 Message-ID: <7d6fde3d1003202147i1af5969bi333b58db6430c100@mail.gmail.com> From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 04:48:00 -0000 On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best wrote: > ok. i think i finally solved this riddle. the cause for the problem seems to > have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've > been using the 'native' keyword for years now and never had any problems with > it, but it seems a recent commit broke 'native' as CPUTYPE. for me this is > 100% reproducable: > > 1. put 'CPUTYPE = native' in /etc/make.conf > 2. build and install gnu/usr.bin/cc > 3. do 'buildkernel' or 'buildworld' and observe the segfault. for some reason > this always occurs in lib/libc/string/strlen.c (r205108). i've tested this > with older version of libc.so (built 22. Feb) and got the same result. so i > assume this is not a libc problem, but a problem with gcc tripping over some > code in libc. i have no clue however why this happend just now and not > earlier. i don't think there has been a recent commit to gcc. > > to solve this there are two ways: > > 1. set CPUTYPE to 'nocona' (i'm running amd64). this will let you compile > everything just fine even with a gcc that has itself been built with 'CPUTYPE > = native'. > 2. build and install gnu/usr.bin/cc with 'CPUTYPE = nocona'. the gcc version > that has been built this way will compile everything just fine even with > 'CPUTYPE = native'. the only way to break this is to go and compile gcc again > with the CPUTYPE set to 'native'. > > so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to 'native' will > give you a broken gcc! What does -march=native yield in your case? There haven't been any recent commits to gcc, so I'm not sure whether or not that's the issue. The libraries that I provided could have just been built from a sane system -- maybe it's something else that needs to be explored a bit more closely to root cause the issue. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 04:58: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 CE47D106564A; Sun, 21 Mar 2010 04:58:09 +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 A4B248FC17; Sun, 21 Mar 2010 04:58:08 +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 o2L4w8Jx041169; Sun, 21 Mar 2010 00:58:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2L4w8ZN041165; Sun, 21 Mar 2010 04:58:08 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 21 Mar 2010 04:58:08 GMT Message-Id: <201003210458.o2L4w8ZN041165@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 04:58:10 -0000 TB --- 2010-03-21 03:05:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-21 03:05:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-03-21 03:05:00 - cleaning the object tree TB --- 2010-03-21 03:05:29 - cvsupping the source tree TB --- 2010-03-21 03:05:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-03-21 03:09:01 - building world TB --- 2010-03-21 03:09:01 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-21 03:09:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-21 03:09:01 - TARGET=i386 TB --- 2010-03-21 03:09:01 - TARGET_ARCH=i386 TB --- 2010-03-21 03:09:01 - TZ=UTC TB --- 2010-03-21 03:09:01 - __MAKE_CONF=/dev/null TB --- 2010-03-21 03:09:01 - cd /src TB --- 2010-03-21 03:09:01 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 21 03:09:01 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Mar 21 04:08:32 UTC 2010 TB --- 2010-03-21 04:08:32 - generating LINT kernel config TB --- 2010-03-21 04:08:32 - cd /src/sys/i386/conf TB --- 2010-03-21 04:08:32 - /usr/bin/make -B LINT TB --- 2010-03-21 04:08:32 - building LINT kernel TB --- 2010-03-21 04:08:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-21 04:08:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-21 04:08:32 - TARGET=i386 TB --- 2010-03-21 04:08:32 - TARGET_ARCH=i386 TB --- 2010-03-21 04:08:32 - TZ=UTC TB --- 2010-03-21 04:08:32 - __MAKE_CONF=/dev/null TB --- 2010-03-21 04:08:32 - cd /src TB --- 2010-03-21 04:08:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 21 04:08:32 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Mar 21 04:33:32 UTC 2010 TB --- 2010-03-21 04:33:32 - building GENERIC kernel TB --- 2010-03-21 04:33:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-21 04:33:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-21 04:33:32 - TARGET=i386 TB --- 2010-03-21 04:33:32 - TARGET_ARCH=i386 TB --- 2010-03-21 04:33:32 - TZ=UTC TB --- 2010-03-21 04:33:32 - __MAKE_CONF=/dev/null TB --- 2010-03-21 04:33:32 - cd /src TB --- 2010-03-21 04:33:32 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Mar 21 04:33:32 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Mar 21 04:53:21 UTC 2010 TB --- 2010-03-21 04:53:25 - building PAE kernel TB --- 2010-03-21 04:53:25 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-21 04:53:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-21 04:53:25 - TARGET=i386 TB --- 2010-03-21 04:53:25 - TARGET_ARCH=i386 TB --- 2010-03-21 04:53:25 - TZ=UTC TB --- 2010-03-21 04:53:25 - __MAKE_CONF=/dev/null TB --- 2010-03-21 04:53:25 - cd /src TB --- 2010-03-21 04:53:25 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sun Mar 21 04:53:25 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/qdivrem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/compat/x86bios/x86bios.c cc1: warnings being treated as errors /src/sys/compat/x86bios/x86bios.c: In function 'x86bios_map_mem': /src/sys/compat/x86bios/x86bios.c:558: warning: cast to pointer from integer of different size *** Error code 1 Stop in /obj/i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-21 04:58:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-21 04:58:08 - ERROR: failed to build PAE kernel TB --- 2010-03-21 04:58:08 - 5080.43 user 936.95 system 6788.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 06:25:37 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA9C2106566C; Sun, 21 Mar 2010 06:25:37 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id AEEC78FC13; Sun, 21 Mar 2010 06:25:37 +0000 (UTC) Received: by pvc7 with SMTP id 7so1082964pvc.13 for ; Sat, 20 Mar 2010 23:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m44ojDAqkgUGL4WoGJ8ccTaGPJut1LtdrV5j8oxvTf0=; b=gcPAgezPOJiL/IxogBRsv7i6Lj3/b5WwQxsv++Oy4b5tG5UCXuP6Mu0w81pImzzoSw GNOIWKLLpSsCx5cxalunMiQR89Of7evvBASooXGhZAV3f68llF0fcPDmiT1ejGxO7IPQ 5U9Wg3ytonF4cMlxY1y1AMW9Eoh+uLqq4FYQs= 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=aHqYSA+gL1DHcLQApQ4OA210gDlW/PO4eG+UNGlSOLDZwz73wmEZtl2TQHf1MYK3Ip ZZpj9TGQ2o+dBcew8XeayjLL2lMuAEO46VJ0s/rjMyJCn7xHyJecXIR0vAsvmdjxiZck VdLvU3nkWr0hOH+kmLgZL5DMNQX4NO/If45ww= MIME-Version: 1.0 Received: by 10.142.152.34 with SMTP id z34mr821318wfd.176.1269152737100; Sat, 20 Mar 2010 23:25:37 -0700 (PDT) In-Reply-To: <201003210458.o2L4w8ZN041165@freebsd-current.sentex.ca> References: <201003210458.o2L4w8ZN041165@freebsd-current.sentex.ca> Date: Sat, 20 Mar 2010 23:25:37 -0700 Message-ID: <7d6fde3d1003202325u5bc2adf0sfec35a9d0509eb55@mail.gmail.com> From: Garrett Cooper To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 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, 21 Mar 2010 06:25:38 -0000 On Sat, Mar 20, 2010 at 9:58 PM, FreeBSD Tinderbox wrote: > TB --- 2010-03-21 03:05:00 - tinderbox 2.6 running on freebsd-current.sen= tex.ca > TB --- 2010-03-21 03:05:00 - starting HEAD tinderbox run for i386/i386 > TB --- 2010-03-21 03:05:00 - cleaning the object tree > TB --- 2010-03-21 03:05:29 - cvsupping the source tree > TB --- 2010-03-21 03:05:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sente= x.ca /tinderbox/HEAD/i386/i386/supfile > TB --- 2010-03-21 03:09:01 - building world > TB --- 2010-03-21 03:09:01 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2010-03-21 03:09:01 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-03-21 03:09:01 - TARGET=3Di386 > TB --- 2010-03-21 03:09:01 - TARGET_ARCH=3Di386 > TB --- 2010-03-21 03:09:01 - TZ=3DUTC > TB --- 2010-03-21 03:09:01 - __MAKE_CONF=3D/dev/null > TB --- 2010-03-21 03:09:01 - cd /src > TB --- 2010-03-21 03:09:01 - /usr/bin/make -B buildworld >>>> World build started on Sun Mar 21 03:09:01 UTC 2010 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> World build completed on Sun Mar 21 04:08:32 UTC 2010 > TB --- 2010-03-21 04:08:32 - generating LINT kernel config > TB --- 2010-03-21 04:08:32 - cd /src/sys/i386/conf > TB --- 2010-03-21 04:08:32 - /usr/bin/make -B LINT > TB --- 2010-03-21 04:08:32 - building LINT kernel > TB --- 2010-03-21 04:08:32 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2010-03-21 04:08:32 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-03-21 04:08:32 - TARGET=3Di386 > TB --- 2010-03-21 04:08:32 - TARGET_ARCH=3Di386 > TB --- 2010-03-21 04:08:32 - TZ=3DUTC > TB --- 2010-03-21 04:08:32 - __MAKE_CONF=3D/dev/null > TB --- 2010-03-21 04:08:32 - cd /src > TB --- 2010-03-21 04:08:32 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Sun Mar 21 04:08:32 UTC 2010 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for LINT completed on Sun Mar 21 04:33:32 UTC 2010 > TB --- 2010-03-21 04:33:32 - building GENERIC kernel > TB --- 2010-03-21 04:33:32 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2010-03-21 04:33:32 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-03-21 04:33:32 - TARGET=3Di386 > TB --- 2010-03-21 04:33:32 - TARGET_ARCH=3Di386 > TB --- 2010-03-21 04:33:32 - TZ=3DUTC > TB --- 2010-03-21 04:33:32 - __MAKE_CONF=3D/dev/null > TB --- 2010-03-21 04:33:32 - cd /src > TB --- 2010-03-21 04:33:32 - /usr/bin/make -B buildkernel KERNCONF=3DGENE= RIC >>>> Kernel build for GENERIC started on Sun Mar 21 04:33:32 UTC 2010 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for GENERIC completed on Sun Mar 21 04:53:21 UTC 2010 > TB --- 2010-03-21 04:53:25 - building PAE kernel > TB --- 2010-03-21 04:53:25 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2010-03-21 04:53:25 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-03-21 04:53:25 - TARGET=3Di386 > TB --- 2010-03-21 04:53:25 - TARGET_ARCH=3Di386 > TB --- 2010-03-21 04:53:25 - TZ=3DUTC > TB --- 2010-03-21 04:53:25 - __MAKE_CONF=3D/dev/null > TB --- 2010-03-21 04:53:25 - cd /src > TB --- 2010-03-21 04:53:25 - /usr/bin/make -B buildkernel KERNCONF=3DPAE >>>> Kernel build for PAE started on Sun Mar 21 04:53:25 UTC 2010 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything > [...] > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/= src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-gro= wth=3D100 --param large-function-growth=3D1000 =A0-mno-align-long-strings -= mpreferred-stack-boundary=3D2 =A0-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mn= o-sse3 -ffreestanding -fstack-protector -Werror =A0/src/sys/libkern/qdivrem= .c > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/= src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-gro= wth=3D100 --param large-function-growth=3D1000 =A0-mno-align-long-strings -= mpreferred-stack-boundary=3D2 =A0-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mn= o-sse3 -ffreestanding -fstack-protector -Werror =A0/src/sys/libkern/ucmpdi2= .c > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/= src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-gro= wth=3D100 --param large-function-growth=3D1000 =A0-mno-align-long-strings -= mpreferred-stack-boundary=3D2 =A0-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mn= o-sse3 -ffreestanding -fstack-protector -Werror =A0/src/sys/libkern/udivdi3= .c > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/= src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-gro= wth=3D100 --param large-function-growth=3D1000 =A0-mno-align-long-strings -= mpreferred-stack-boundary=3D2 =A0-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mn= o-sse3 -ffreestanding -fstack-protector -Werror =A0/src/sys/libkern/umoddi3= .c > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/= src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-gro= wth=3D100 --param large-function-growth=3D1000 =A0-mno-align-long-strings -= mpreferred-stack-boundary=3D2 =A0-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mn= o-sse3 -ffreestanding -fstack-protector -Werror =A0/src/sys/compat/x86bios/= x86bios.c > cc1: warnings being treated as errors > /src/sys/compat/x86bios/x86bios.c: In function 'x86bios_map_mem': > /src/sys/compat/x86bios/x86bios.c:558: warning: cast to pointer from inte= ger of different size > *** Error code 1 > > Stop in /obj/i386/src/sys/PAE. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2010-03-21 04:58:08 - WARNING: /usr/bin/make returned exit code = =A01 > TB --- 2010-03-21 04:58:08 - ERROR: failed to build PAE kernel > TB --- 2010-03-21 04:58:08 - 5080.43 user 936.95 system 6788.14 real Hi Jung, Could you please resolve this error? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 11:00: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 D1921106566B for ; Sun, 21 Mar 2010 11:00:19 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id 626328FC08 for ; Sun, 21 Mar 2010 11:00:17 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,282,1267398000"; d="txt'?scan'208";a="28950065" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 21 Mar 2010 12:00:16 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 5A46E1B0768; Sun, 21 Mar 2010 12:00:16 +0100 (CET) Date: Sun, 21 Mar 2010 12:00:09 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Garrett Cooper Message-ID: In-Reply-To: <7d6fde3d1003202147i1af5969bi333b58db6430c100@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20100321110009f0889e84000039fe-a_best01+ Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 11:00:19 -0000 This is a MIME encoded multipart message. --+permail-20100321110009f0889e84000039fe-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Garrett Cooper schrieb am 2010-03-21: > On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best > wrote: > > ok. i think i finally solved this riddle. the cause for the problem > > seems to > > have been my CPUTYPE in /etc/make.conf. it is set to 'native'. > > actually i've > > been using the 'native' keyword for years now and never had any > > problems with > > it, but it seems a recent commit broke 'native' as CPUTYPE. for me > > this is > > 100% reproducable: > > 1. put 'CPUTYPE = native' in /etc/make.conf > > 2. build and install gnu/usr.bin/cc > > 3. do 'buildkernel' or 'buildworld' and observe the segfault. for > > some reason > > this always occurs in lib/libc/string/strlen.c (r205108). i've > > tested this > > with older version of libc.so (built 22. Feb) and got the same > > result. so i > > assume this is not a libc problem, but a problem with gcc tripping > > over some > > code in libc. i have no clue however why this happend just now and > > not > > earlier. i don't think there has been a recent commit to gcc. > > to solve this there are two ways: > > 1. set CPUTYPE to 'nocona' (i'm running amd64). this will let you > > compile > > everything just fine even with a gcc that has itself been built > > with 'CPUTYPE > > = native'. > > 2. build and install gnu/usr.bin/cc with 'CPUTYPE = nocona'. the > > gcc version > > that has been built this way will compile everything just fine even > > with > > 'CPUTYPE = native'. the only way to break this is to go and compile > > gcc again > > with the CPUTYPE set to 'native'. > > so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to > > 'native' will > > give you a broken gcc! > What does -march=native yield in your case? There haven't been > any > recent commits to gcc, so I'm not sure whether or not that's the > issue. The libraries that I provided could have just been built from > a > sane system -- maybe it's something else that needs to be explored a > bit more closely to root cause the issue. i've experimented with setting CPUTYPE to native yesterday, but still couldn't figure out what the cause of it is. only a few points i'd like to point out: 1. this is very easily reproducible for me. i just need to set CPUTYPE=native in my /etc/make.conf and everything that gets linked against libc and uses the strlen() function won't compile due to gcc segfaulting. this is the case with /usr/src/bin/cat e.g. as well as kernel, world and probably lots of other stuff. also the following gcc command segfaults too (no need for setting CPUTYPE=native in this case, because -mtune gets set manually): gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 2. there seems to be a connection with strlen.c because gcc alaways segfaults here. also i've been using CPUTYPE=native for years now and never had any problems with it. for me the segfault always happens in: #0 strlen (str=Variable "str" is not available. ) at /usr/src/lib/libc/string/strlen.c:100 100 va = (*lp - mask01); it would be nice if people with arch i386 and amd64 could try to reproduce this (i believe the other archs don't support CPUTYPE=native). again the easiest way to trigger this (you don't need to edit your /etc/make.conf for this) should be running: gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 for now i'm using the attached patch to prevent myself from shooting me in the foot again. ;) cheers. alex > Cheers, > -Garrett -- Alexander Best --+permail-20100321110009f0889e84000039fe-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="bsd.cpu.mk.patch.txt" SW5kZXg6IHNoYXJlL21rL2JzZC5jcHUubWsKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWsvYnNkLmNw dS5tawkocmV2aXNpb24gMjA1MzkwKQorKysgc2hhcmUvbWsvYnNkLmNwdS5tawkod29ya2luZyBj b3B5KQpAQCAtNTMsMTAgKzUzLDE2IEBACiBDUFVUWVBFID0gYXRobG9uLW1wCiAuICBlbGlmICR7 Q1BVVFlQRX0gPT0gIms3IgogQ1BVVFlQRSA9IGF0aGxvbgorI1hYWDogY29tcGlsaW5nIGdjYyB3 aXRoIC1tYXJjaD1uYXRpdmUgY2F1c2VzIGxpYmMgcHJvYmxlbXMKKy4gIGVsaWYgJHtDUFVUWVBF fSA9PSAibmF0aXZlIgorLmVycm9yIENQVVRZUEUgbmF0aXZlIGlzIG5vdCBzdXBwb3J0ZWQuCiAu ICBlbmRpZgogLiBlbGlmICR7TUFDSElORV9BUkNIfSA9PSAiYW1kNjQiCiAuICBpZiAke0NQVVRZ UEV9ID09ICJwcmVzY290dCIgfHwgJHtDUFVUWVBFfSA9PSAiY29yZTIiCiBDUFVUWVBFID0gbm9j b25hCisjWFhYOiBjb21waWxpbmcgZ2NjIHdpdGggLW1hcmNoPW5hdGl2ZSBjYXVzZXMgbGliYyBw cm9ibGVtcworLiAgZWxpZiAke0NQVVRZUEV9ID09ICJuYXRpdmUiCisuZXJyb3IgQ1BVVFlQRSBu YXRpdmUgaXMgbm90IHN1cHBvcnRlZC4KIC4gIGVuZGlmCiAuIGVuZGlmCiAK --+permail-20100321110009f0889e84000039fe-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 11:43: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 F2EAD106566B for ; Sun, 21 Mar 2010 11:43:21 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by mx1.freebsd.org (Postfix) with ESMTP id C6C738FC08 for ; Sun, 21 Mar 2010 11:43:21 +0000 (UTC) Received: by pxi14 with SMTP id 14so2770022pxi.15 for ; Sun, 21 Mar 2010 04:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0hD3dTIcjG3Y2G9K2doTvn44B3yb3Bb5Cwg37sC47bI=; b=oHM5yakuVSAGJzIYXMI+pvgRUkWqYBgoMRwJ1QBvJRjmOozDTe1JhNzqMLVszvBnc9 Shr+3xnkz7hANERldtIfm/A5988m62y2sAQhlBhof3lBiqX0Pub+7zgG4QXnPbT5E9ak LzB0j8Y8n8yrtOT5wjwBE/P/hvgnHD40QSQPU= 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=BiWh0q7ULrcKgUwjOpWwLdIiPnYbXr5iPiWaldZGuPJYrUcXQOwErzEFQt9BEocSTm aNuZKqcLRHZJAIWDbuQdZ/5xFImG20huzmLlhzQrlLzknUIYtiwk5e/T8pg+7CTCbJeN mPG5QW+P8StpZ66TDzXxQBLca9225nwmhKQEs= MIME-Version: 1.0 Received: by 10.142.210.12 with SMTP id i12mr1845535wfg.62.1269171801266; Sun, 21 Mar 2010 04:43:21 -0700 (PDT) In-Reply-To: References: <7d6fde3d1003202147i1af5969bi333b58db6430c100@mail.gmail.com> Date: Sun, 21 Mar 2010 04:43:21 -0700 Message-ID: <7d6fde3d1003210443j2879aca4lbd7187d9e41a5db2@mail.gmail.com> From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 11:43:22 -0000 On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best wrote: > Garrett Cooper schrieb am 2010-03-21: >> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best >> wrote: >> > ok. i think i finally solved this riddle. the cause for the problem >> > seems to >> > have been my CPUTYPE in /etc/make.conf. it is set to 'native'. >> > actually i've >> > been using the 'native' keyword for years now and never had any >> > problems with >> > it, but it seems a recent commit broke 'native' as CPUTYPE. for me >> > this is >> > 100% reproducable: > >> > 1. put 'CPUTYPE =3D native' in /etc/make.conf >> > 2. build and install gnu/usr.bin/cc >> > 3. do 'buildkernel' or 'buildworld' and observe the segfault. for >> > =A0 =A0some reason >> > this always occurs in lib/libc/string/strlen.c (r205108). i've >> > tested this >> > with older version of libc.so (built 22. Feb) and got the same >> > result. so i >> > assume this is not a libc problem, but a problem with gcc tripping >> > over some >> > code in libc. i have no clue however why this happend just now and >> > not >> > earlier. i don't think there has been a recent commit to gcc. > >> > to solve this there are two ways: > >> > 1. set CPUTYPE to 'nocona' (i'm running amd64). this will let you >> > =A0 =A0compile >> > everything just fine even with a gcc that has itself been built >> > with 'CPUTYPE >> > =3D native'. >> > 2. build and install gnu/usr.bin/cc with 'CPUTYPE =3D nocona'. the >> > =A0 =A0gcc version >> > that has been built this way will compile everything just fine even >> > with >> > 'CPUTYPE =3D native'. the only way to break this is to go and compile >> > gcc again >> > with the CPUTYPE set to 'native'. > >> > so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to >> > 'native' will >> > give you a broken gcc! > >> =A0 =A0 What does -march=3Dnative yield in your case? There haven't been >> =A0 =A0 any >> recent commits to gcc, so I'm not sure whether or not that's the >> issue. The libraries that I provided could have just been built from >> a >> sane system -- maybe it's something else that needs to be explored a >> bit more closely to root cause the issue. > > i've experimented with setting CPUTYPE to native yesterday, but still cou= ldn't > figure out what the cause of it is. only a few points i'd like to point o= ut: > > 1. this is very easily reproducible for me. i just need to set CPUTYPE=3D= native > in my /etc/make.conf and everything that gets linked against libc and use= s the > strlen() function won't compile due to gcc segfaulting. this is the case = with > /usr/src/bin/cat e.g. as well as kernel, world and probably lots of other > stuff. > > also the following gcc command segfaults too (no need for setting > CPUTYPE=3Dnative in this case, because -mtune gets set manually): > > gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 > > 2. there seems to be a connection with strlen.c because gcc alaways segfa= ults > here. also i've been using CPUTYPE=3Dnative for years now and never had a= ny > problems with it. for me the segfault always happens in: > > #0 =A0strlen (str=3DVariable "str" is not available. > ) at /usr/src/lib/libc/string/strlen.c:100 > 100 =A0 =A0 =A0 =A0 =A0 =A0 va =3D (*lp - mask01); > > it would be nice if people with arch i386 and amd64 could try to reproduc= e > this (i believe the other archs don't support CPUTYPE=3Dnative). again th= e > easiest way to trigger this (you don't need to edit your /etc/make.conf f= or > this) should be running: > > gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 > > for now i'm using the attached patch to prevent myself from shooting me i= n the > foot again. ;) Works for me *shrugs*: $ gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null -mtune=3D= generic ignoring duplicate directory "/usr/include" #include "..." search starts here: #include <...> search starts here: /usr/include End of search list. $ echo $? 0 Could you provide more specific details, i.e.: 1. Hardware specs: $ sysctl hw.machine hw.model hw.physmem hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz hw.physmem: 12852424704 2. Do you have IA32 compatibility installed (now referred to as FREEBSD_32)= ? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 12:01:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8DFE1065675 for ; Sun, 21 Mar 2010 12:01:51 +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 270E88FC08 for ; Sun, 21 Mar 2010 12:01:50 +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 OAA28481; Sun, 21 Mar 2010 14:01:47 +0200 (EET) (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 1NtJqk-000AUx-Ns; Sun, 21 Mar 2010 14:01:46 +0200 Message-ID: <4BA60AAA.1080403@icyb.net.ua> Date: Sun, 21 Mar 2010 14:01:46 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d1003202147i1af5969bi333b58db6430c100@mail.gmail.com> <7d6fde3d1003210443j2879aca4lbd7187d9e41a5db2@mail.gmail.com> In-Reply-To: <7d6fde3d1003210443j2879aca4lbd7187d9e41a5db2@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 12:01:51 -0000 on 21/03/2010 13:43 Garrett Cooper said the following: > > Works for me *shrugs*: > > $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null -mtune=generic > ignoring duplicate directory "/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/include > End of search list. > $ echo $? > 0 Do you also have the latest version of libc _installed_ in the system? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 12:27: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 62B51106566C for ; Sun, 21 Mar 2010 12:27:28 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id A014C8FC13 for ; Sun, 21 Mar 2010 12:27:27 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,282,1267398000"; d="conf'?scan'208";a="28954446" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 21 Mar 2010 13:27:26 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 4D5581B07E7; Sun, 21 Mar 2010 13:27:25 +0100 (CET) Date: Sun, 21 Mar 2010 13:27:12 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Garrett Cooper Message-ID: In-Reply-To: <7d6fde3d1003210443j2879aca4lbd7187d9e41a5db2@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20100321122712f7e55a9d00006c06-a_best01+ Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 12:27:28 -0000 This is a MIME encoded multipart message. --+permail-20100321122712f7e55a9d00006c06-a_best01+ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Garrett Cooper schrieb am 2010-03-21: > On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best > wrote: > > Garrett Cooper schrieb am 2010-03-21: > >> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best > >> > >> wrote: > >> > ok. i think i finally solved this riddle. the cause for the > >> > problem > >> > seems to > >> > have been my CPUTYPE in /etc/make.conf. it is set to 'native'. > >> > actually i've > >> > been using the 'native' keyword for years now and never had any > >> > problems with > >> > it, but it seems a recent commit broke 'native' as CPUTYPE. for > >> > me > >> > this is > >> > 100% reproducable: > >> > 1. put 'CPUTYPE =3D native' in /etc/make.conf > >> > 2. build and install gnu/usr.bin/cc > >> > 3. do 'buildkernel' or 'buildworld' and observe the segfault. > >> > for > >> > =A0 =A0some reason > >> > this always occurs in lib/libc/string/strlen.c (r205108). i've > >> > tested this > >> > with older version of libc.so (built 22. Feb) and got the same > >> > result. so i > >> > assume this is not a libc problem, but a problem with gcc > >> > tripping > >> > over some > >> > code in libc. i have no clue however why this happend just now > >> > and > >> > not > >> > earlier. i don't think there has been a recent commit to gcc. > >> > to solve this there are two ways: > >> > 1. set CPUTYPE to 'nocona' (i'm running amd64). this will let > >> > you > >> > =A0 =A0compile > >> > everything just fine even with a gcc that has itself been built > >> > with 'CPUTYPE > >> > =3D native'. > >> > 2. build and install gnu/usr.bin/cc with 'CPUTYPE =3D nocona'. the > >> > =A0 =A0gcc version > >> > that has been built this way will compile everything just fine > >> > even > >> > with > >> > 'CPUTYPE =3D native'. the only way to break this is to go and > >> > compile > >> > gcc again > >> > with the CPUTYPE set to 'native'. > >> > so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to > >> > 'native' will > >> > give you a broken gcc! > >> =A0 =A0 What does -march=3Dnative yield in your case? There haven't be= en > >> =A0 =A0 any > >> recent commits to gcc, so I'm not sure whether or not that's the > >> issue. The libraries that I provided could have just been built > >> from > >> a > >> sane system -- maybe it's something else that needs to be explored > >> a > >> bit more closely to root cause the issue. > > i've experimented with setting CPUTYPE to native yesterday, but > > still couldn't > > figure out what the cause of it is. only a few points i'd like to > > point out: > > 1. this is very easily reproducible for me. i just need to set > > CPUTYPE=3Dnative > > in my /etc/make.conf and everything that gets linked against libc > > and uses the > > strlen() function won't compile due to gcc segfaulting. this is the > > case with > > /usr/src/bin/cat e.g. as well as kernel, world and probably lots of > > other > > stuff. > > also the following gcc command segfaults too (no need for setting > > CPUTYPE=3Dnative in this case, because -mtune gets set manually): > > gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 > > 2. there seems to be a connection with strlen.c because gcc alaways > > segfaults > > here. also i've been using CPUTYPE=3Dnative for years now and never > > had any > > problems with it. for me the segfault always happens in: > > #0 =A0strlen (str=3DVariable "str" is not available. > > ) at /usr/src/lib/libc/string/strlen.c:100 > > 100 =A0 =A0 =A0 =A0 =A0 =A0 va =3D (*lp - mask01); > > it would be nice if people with arch i386 and amd64 could try to > > reproduce > > this (i believe the other archs don't support CPUTYPE=3Dnative). > > again the > > easiest way to trigger this (you don't need to edit your > > /etc/make.conf for > > this) should be running: > > gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 > > for now i'm using the attached patch to prevent myself from > > shooting me in the > > foot again. ;) > Works for me *shrugs*: > $ gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null > -mtune=3Dgeneric > ignoring duplicate directory "/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/include > End of search list. > $ echo $? > 0 > Could you provide more specific details, i.e.: > 1. Hardware specs: > $ sysctl hw.machine hw.model hw.physmem > hw.machine: amd64 > hw.model: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz > hw.physmem: 12852424704 hw.machine: amd64 hw.model: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz hw.physmem: 2122203136 > 2. Do you have IA32 compatibility installed (now referred to as > FREEBSD_32)? yes. also i've attached by kernel conf, my make.conf and my src.conf. > Thanks, > -Garrett --=20 Alexander Best --+permail-20100321122712f7e55a9d00006c06-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="make.conf" IyBXT1JMRC9LRVJORUwgb3B0aW9ucwpLRVJOQ09ORiA9IEFSVU5ERUwKTU9EVUxFU19PVkVSUklE RSA9IFwKbmV0Z3JhcGgvbmV0Z3JhcGggXApuZXRncmFwaC9zb2NrZXQgbmV0Z3JhcGgvYmx1ZXRv b3RoL2JsdWV0b290aCBuZXRncmFwaC9ibHVldG9vdGgvaGNpIFwKbmV0Z3JhcGgvYmx1ZXRvb3Ro L2wyY2FwIG5ldGdyYXBoL2JsdWV0b290aC9zb2NrZXQgbmV0Z3JhcGgvYmx1ZXRvb3RoL3VidCBc CmxpbnV4IGxpbnByb2NmcyBsaW5zeXNmcyB0bXBmcyBcCnVzYi9xdWlyayBmZGVzY2ZzIFwKdXNi L3VoaWQgdXNiL3VrYmQgdXNiL3VtcwoKIyBHQ0Mgb3B0aW9ucwouaWYgIWVtcHR5KC5DVVJESVI6 TS91c3IvcG9ydHMvKikgJiYgZXhpc3RzKC91c3IvbG9jYWwvYmluL2djYzQ0KQpDQyA9ICBnY2M0 NApDWFggPSBnKys0NApDUFAgPSBjcHA0NAouZW5kaWYKCiNDUFVUWVBFID0gbmF0aXZlCkNQVVRZ UEUgPSBub2NvbmEKQ09QVEZMQUdTPSAtTzAgLXBpcGUgLWZuby1idWlsdGluCkNGTEFHUyA9IC1P MiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAtZm5vLWJ1aWx0aW4KQ1hYRkxBR1MgKz0gLWZj b25zZXJ2ZS1zcGFjZQpERUJVR19GTEFHUyA9IC1nCgojIFNFTkRNQUlMIG9wdGlvbnMKU0VORE1B SUxfTUMgPSAvZXRjL21haWwvZnJlZWJzZC5tYwpTRU5ETUFJTF9TVUJNSVRfTUMgPSAvZXRjL21h aWwvZnJlZWJzZC5zdWJtaXQubWMKCiMgUE9SVFMgb3B0aW9ucwpPVkVSUklERV9MSU5VWF9CQVNF X1BPUlQgPSBmMTAKT1ZFUlJJREVfTElOVVhfTk9OQkFTRV9QT1JUUyA9IGYxMApEQTQgPSB5ZXMK I1dJVEhfQlNERUwgPSB5ZXMKI1dJVEhfMjU2X0NPTE9SID0geWVzCgojIE1JU0Mgb3B0aW9ucwpE T0NfTEFORyA9IGVuX1VTLklTTzg4NTktMSBkZV9ERS5JU084ODU5LTE1CgojIGFkZGVkIGJ5IHVz ZS5wZXJsIDIwMTAtMDItMjAgMTQ6NTg6MTMKUEVSTF9WRVJTSU9OID0gNS4xMC4xCg== --+permail-20100321122712f7e55a9d00006c06-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="src.conf" IyBCVUlMRFdPUkxEIG9wdGlvbnMKV0lUSE9VVF9BQ0NUPXRydWUKV0lUSE9VVF9BTUQ9dHJ1ZQpX SVRIT1VUX0FQTT10cnVlCldJVEhPVVRfQVRNPXRydWUKV0lUSE9VVF9BVURJVD10cnVlCldJVEhP VVRfQklORD10cnVlCldJVEhPVVRfQlNOTVA9dHJ1ZQpXSVRIT1VUX0NEREw9dHJ1ZQpXSVRIT1VU X0NUTT10cnVlCldJVEhPVVRfQ1ZTPXRydWUKV0lUSE9VVF9GTE9QUFk9dHJ1ZQpXSVRIT1VUX0ZS RUVCU0RfVVBEQVRFPXRydWUKV0lUSE9VVF9HQU1FUz10cnVlCldJVEhPVVRfR1BJQj10cnVlCldJ VEhfSURFQT10cnVlCldJVEhPVVRfSU5FVDY9dHJ1ZQpXSVRIT1VUX0lQRklMVEVSPXRydWUKV0lU SE9VVF9JUEZXPXRydWUKV0lUSE9VVF9JUFg9dHJ1ZQpXSVRIT1VUX0pBSUw9dHJ1ZQpXSVRIT1VU X0xQUj10cnVlCldJVEhPVVRfTUFJTFdSQVBQRVI9dHJ1ZQpXSVRIT1VUX05DUD10cnVlCldJVEhP VVRfTkRJUz10cnVlCldJVEhPVVRfTkVUQ0FUPXRydWUKV0lUSE9VVF9OSVM9dHJ1ZQpXSVRIT1VU X05MUz10cnVlCldJVEhPVVRfTkxTX0NBVEFMT0dTPXRydWUKV0lUSE9VVF9OU19DQUNISU5HPXRy dWUKV0lUSE9VVF9QQU09dHJ1ZQpXSVRIT1VUX1BGPXRydWUKV0lUSE9VVF9QUk9GSUxFPXRydWUK V0lUSE9VVF9QUFA9dHJ1ZQpXSVRIT1VUX1FVT1RBUz10cnVlCldJVEhPVVRfUkNNRFM9dHJ1ZQpX SVRIT1VUX1JDUz10cnVlCldJVEhPVVRfUk9VVEVEPXRydWUKV0lUSE9VVF9TTElQPXRydWUKV0lU SE9VVF9TWVNJTlNUQUxMPXRydWUKV0lUSE9VVF9UQ1NIPXRydWUKV0lUSE9VVF9URUxORVQ9dHJ1 ZQoKIyBDTEFORyBvcHRpb25zCldJVEhfQ0xBTkc9CldJVEhfQ0xBTkdfSVNfQ0M9Ck5PX1dFUlJP Uj0KV0VSUk9SPQojIERvbid0IGZvcmdldCB0aGlzIHdoZW4gdXNpbmcgSmFpbHMhCk5PX0ZTQ0hH PQo= --+permail-20100321122712f7e55a9d00006c06-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 12:32: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 3AFA91065672 for ; Sun, 21 Mar 2010 12:32:42 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 065508FC13 for ; Sun, 21 Mar 2010 12:32:41 +0000 (UTC) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id o2LCWa6E057144; Sun, 21 Mar 2010 12:32:36 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: freebsd-current@freebsd.org Date: Sun, 21 Mar 2010 12:32:35 +0000 User-Agent: KMail/1.12.4 (FreeBSD/9.0-CURRENT; KDE/4.3.5; amd64; ; ) References: <7d6fde3d1003202147i1af5969bi333b58db6430c100@mail.gmail.com> <7d6fde3d1003210443j2879aca4lbd7187d9e41a5db2@mail.gmail.com> In-Reply-To: <7d6fde3d1003210443j2879aca4lbd7187d9e41a5db2@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003211232.35497.ken@mthelicon.com> X-Spam-Status: No, score=4.1 required=5.0 tests=BAYES_40,DNS_FROM_OPENWHOIS, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hercules.mthelicon.com Cc: Garrett Cooper , Alexander Best Subject: Re: build failures after stdlib update 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, 21 Mar 2010 12:32:42 -0000 > > it would be nice if people with arch i386 and amd64 could try to > > reproduce this (i believe the other archs don't support CPUTYPE=native). > > again the easiest way to trigger this (you don't need to edit your > > /etc/make.conf for this) should be running: > > > > gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > > I didnt think you could add CPUTYPE=native to the /etc/make.conf What I used to do when I was compiling native was to do something like the following in the /etc/make.conf CPUTYPE?=core2 NO_CPU_CFLAGS= CFLAGS= -mtune=native -O2 -fno-strict-aliasing -pipe -s Peg From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 12:36: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 43DAE106564A for ; Sun, 21 Mar 2010 12:36:13 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id 0A5358FC1C for ; Sun, 21 Mar 2010 12:36:09 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,282,1267398000"; d="txt'?scan'208";a="28954816" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 21 Mar 2010 13:36:07 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id C17D51B07E7; Sun, 21 Mar 2010 13:36:07 +0100 (CET) Date: Sun, 21 Mar 2010 13:35:59 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Andriy Gapon , Garrett Cooper Message-ID: In-Reply-To: <4BA60AAA.1080403@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20100321123559f7e55a9d00007007-a_best01+ Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 12:36:13 -0000 This is a MIME encoded multipart message. --+permail-20100321123559f7e55a9d00007007-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andriy Gapon schrieb am 2010-03-21: > on 21/03/2010 13:43 Garrett Cooper said the following: > > Works for me *shrugs*: > > $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > > Using built-in specs. > > Target: amd64-undermydesk-freebsd > > Configured with: FreeBSD/amd64 system compiler > > Thread model: posix > > gcc version 4.2.1 20070719 [FreeBSD] > > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null > > -mtune=generic > > ignoring duplicate directory "/usr/include" > > #include "..." search starts here: > > #include <...> search starts here: > > /usr/include > > End of search list. > > $ echo $? > > 0 > Do you also have the latest version of libc _installed_ in the > system? i think so. i grabbed a fresh src copy yesterday and did buildworld/installworld a few ours ago. i've attached the output of `ident /lib/libc.so.7`. cheers. alex -- Alexander Best --+permail-20100321123559f7e55a9d00007007-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="ident.txt" L2xpYi9saWJjLnNvLjc6CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2NzdS9hbWQ2NC9jcnRpLlMg MTI3MjUyIDIwMDQtMDMtMjEgMDE6Mzk6MDFaIHBldGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvY3N1L2FtZDY0L2NydG4uUyAxMjcyNTIgMjAwNC0wMy0yMSAwMTozOTowMVogcGV0ZXIgJAog ICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy93bWVtc2V0LmMgMTg4MDk4IDIwMDkt MDItMDMgMjA6MjU6MzZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5n L3dtZW1tb3ZlLmMgMTg4MDgwIDIwMDktMDItMDMgMTc6NTg6MjBaIGRhbmdlciAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3dtZW1jbXAuYyAxODgwODAgMjAwOS0wMi0wMyAx Nzo1ODoyMFogZGFuZ2VyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvd2Nz eGZybS5jIDEyNzk5OCAyMDA0LTA0LTA3IDA5OjQ3OjU2WiB0anIgJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL3N0cmluZy93Y3N3aWR0aC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2 WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy93Y3N0b2suYyAxNzQ1 NTMgMjAwNy0xMi0xMiAxODozMzowNlogd2VzICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9zdHJpbmcvd2Nzc3RyLmMgMTg4MDgwIDIwMDktMDItMDMgMTc6NTg6MjBaIGRhbmdlciAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3djc3Nwbi5jIDE4ODA4MCAyMDA5LTAy LTAzIDE3OjU4OjIwWiBkYW5nZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmlu Zy93Y3NyY2hyLmMgMTA1Nzg2IDIwMDItMTAtMjMgMTA6NTI6MDRaIHRqciAkCiAgICAgJEZyZWVC U0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3djc3BicmsuYyAxODgwODAgMjAwOS0wMi0wMyAxNzo1 ODoyMFogZGFuZ2VyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvd2NzbmNw eS5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL3N0cmluZy93Y3NuY21wLmMgMTg4MDgwIDIwMDktMDItMDMgMTc6NTg6MjBaIGRh bmdlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3djc25jYXQuYyAxODgw ODAgMjAwOS0wMi0wMyAxNzo1ODoyMFogZGFuZ2VyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIv bGliYy9zdHJpbmcvd2NzbmNhc2VjbXAuYyAxODkxMzYgMjAwOS0wMi0yOCAwNjowMDo1OFogZGFz ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvd2NzbGNweS5jIDE4ODA4MCAy MDA5LTAyLTAzIDE3OjU4OjIwWiBkYW5nZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3N0cmluZy93Y3NsY2F0LmMgMTg4MDgwIDIwMDktMDItMDMgMTc6NTg6MjBaIGRhbmdlciAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3djc2R1cC5jIDE0OTAxMSAyMDA1LTA4 LTEzIDA1OjU0OjMzWiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy93 Y3Njc3BuLmMgMTg4MDgwIDIwMDktMDItMDMgMTc6NTg6MjBaIGRhbmdlciAkCiAgICAgJEZyZWVC U0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3djc2NweS5jIDE4ODA4MCAyMDA5LTAyLTAzIDE3OjU4 OjIwWiBkYW5nZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy93Y3Njb2xs LmMgMTI3OTk4IDIwMDQtMDQtMDcgMDk6NDc6NTZaIHRqciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQv bGliL2xpYmMvc3RyaW5nL3djc2NtcC5jIDE4ODA4MCAyMDA5LTAyLTAzIDE3OjU4OjIwWiBkYW5n ZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy93Y3NjaHIuYyAxMDU3ODUg MjAwMi0xMC0yMyAxMDo0Nzo0N1ogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9z dHJpbmcvd2NzY2F0LmMgMTg4MDgwIDIwMDktMDItMDMgMTc6NTg6MjBaIGRhbmdlciAkCiAgICAg JEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3djc2Nhc2VjbXAuYyAxODkxMzYgMjAwOS0w Mi0yOCAwNjowMDo1OFogZGFzICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcv d2NwbmNweS5jIDE5OTA5NiAyMDA5LTExLTA5IDE4OjUwOjM0WiBqaGIgJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL3N0cmluZy93Y3BjcHkuYyAxOTkwOTYgMjAwOS0xMS0wOSAxODo1MDoz NFogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvc3dhYi5jIDE2NTkw MyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3N0cmluZy9zdHJ4ZnJtLmMgMTg0MDU1IDIwMDgtMTAtMTkgMDk6MTA6NDRaIGRlbHBoaWogJAog ICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy9zdHJzcG4uYyAxNDQ1NDUgMjAwNS0w NC0wMiAxODo1Mjo0NFogZGFzICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcv c3Ryc2lnbmFsLmMgMjAyOTE2IDIwMTAtMDEtMjQgMTA6MzU6MjZaIHVtZSAkCiAgICAgJEZyZWVC U0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3N0cm5zdHIuYyAxODgwODAgMjAwOS0wMi0wMyAxNzo1 ODoyMFogZGFuZ2VyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvc3RybmR1 cC5jIDIwMzM5MSAyMDEwLTAyLTAyIDE5OjAyOjA4WiBlZCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQv bGliL2xpYmMvc3RyaW5nL3N0cm1vZGUuYyAxOTEwNTUgMjAwOS0wNC0xNCAxMTozOTo1NlogdHJh c3ogJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy9zdHJjYXNlc3RyLmMgMTg4 MDgwIDIwMDktMDItMDMgMTc6NTg6MjBaIGRhbmdlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvc3RyaW5nL3N0cG5jcHkuYyAxODkxMzYgMjAwOS0wMi0yOCAwNjowMDo1OFogZGFzICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvcmluZGV4LmMgMTY1OTAzIDIwMDct MDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5n L21lbW1lbS5jIDE4ODA4MCAyMDA5LTAyLTAzIDE3OjU4OjIwWiBkYW5nZXIgJAogICAgICRGcmVl QlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy9tZW1jY3B5LmMgMTg4MDgwIDIwMDktMDItMDMgMTc6 NTg6MjBaIGRhbmdlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL2Zsc2xs LmMgMTk5MDk2IDIwMDktMTEtMDkgMTg6NTA6MzRaIGpoYiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQv bGliL2xpYmMvc3RyaW5nL2Zsc2wuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvZmxzLmMgMTY1OTAzIDIwMDctMDEt MDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL2Zm c2xsLmMgMTk5MDk2IDIwMDktMTEtMDkgMTg6NTA6MzRaIGpoYiAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvc3RkbGliL3R3YWxrLmMgMTA4Njk0IDIwMDMtMDEtMDUgMDI6NDM6MThaIHRq ciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL3RzZWFyY2guYyAxMDg2OTQg MjAwMy0wMS0wNSAwMjo0MzoxOFogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9z dGRsaWIvdGZpbmQuYyAxMDg2OTQgMjAwMy0wMS0wNSAwMjo0MzoxOFogdGpyICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9zdGRsaWIvdGRlbGV0ZS5jIDEwODY5NCAyMDAzLTAxLTA1IDAy OjQzOjE4WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9zeXN0ZW0u YyAyMDAxNTAgMjAwOS0xMi0wNSAxOTozMTozOFogZWQgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3N0ZGxpYi9zdHJ0b3VxLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL3N0cnRvdWxsLmMgMTY1OTAzIDIw MDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3Rk bGliL3N0cnRvbnVtLmMgMTU2NzE2IDIwMDYtMDMtMTQgMTk6NTM6MDNaIGFjaGUgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9zdHJ0b3EuYyAxNjU5MDMgMjAwNy0wMS0wOSAw MDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRsaWIvc3RyZm1v bi5jIDIwMzczNCAyMDEwLTAyLTEwIDAwOjAyOjA5WiBjcmFjYXVlciAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvc3RkbGliL3JlbXF1ZS5jIDEwODY0NCAyMDAzLTAxLTA0IDA3OjM0OjQx WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9yZWFscGF0aC5jIDEx NTM2MiAyMDAzLTA1LTI4IDA4OjIzOjAxWiBmam9lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIv bGliYy9zdGRsaWIvcmFuZG9tLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL3JhbmQuYyAxNzQ1NDEgMjAwNy0xMi0x MSAyMDozOTozMlogYWNoZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL3Jh ZGl4c29ydC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9wdHNuYW1lLmMgMTg4NDk3IDIwMDktMDItMTEgMjA6MjQ6 NTlaIGVkICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRsaWIvbHNlYXJjaC5jIDEw NTI1MCAyMDAyLTEwLTE2IDE0OjI5OjIzWiByb2JlcnQgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3N0ZGxpYi9sbGFicy5jIDg2MzY4IDIwMDEtMTEtMTUgMDI6MDU6MDNaIG1pa2UgJAog ICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9sYWJzLmMgMTY1OTAzIDIwMDctMDEt MDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL2w2 NGEuYyAxNTM3MDcgMjAwNS0xMi0yNCAyMjozNzo1OVogdHJob2RlcyAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvc3RkbGliL2luc3F1ZS5jIDEwODY0NCAyMDAzLTAxLTA0IDA3OjM0OjQx WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9pbWF4ZGl2LmMgODYz NjggMjAwMS0xMS0xNSAwMjowNTowM1ogbWlrZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xp YmMvc3RkbGliL2ltYXhhYnMuYyA4NjM2OCAyMDAxLTExLTE1IDAyOjA1OjAzWiBtaWtlICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRsaWIvaGVhcHNvcnQuYyAxNzUyNTkgMjAwOC0w MS0xMyAwMjoxMToxMFogZGFzICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRsaWIv aGNyZWF0ZS5jIDE4MDMyMyAyMDA4LTA3LTA2IDExOjMxOjIwWiBkYW5nZXIgJAogICAgICRGcmVl QlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9nZXRzdWJvcHQuYyAxNjU5MDMgMjAwNy0wMS0wOSAw MDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRsaWIvZ2V0b3B0 X2xvbmcuYyAxNjI1NzQgMjAwNi0wOS0yMyAxNDo0ODozMVogYWNoZSAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvc3RkbGliL2dldG9wdC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2 WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9hdG9sbC5jIDE2NTkw MyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3N0ZGxpYi9hdG9mLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL2Ficy5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4 OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9hNjRsLmMgMTU4 NzQ5IDIwMDYtMDUtMTkgMTk6MDY6MzhaIGpraW0gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL2FtZDY0L3N0ZGxpYi9sbGRpdi5TIDE4NDU0NyAyMDA4LTExLTAyIDAxOjEwOjU0WiBwZXRl ciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvYW1kNjQvc3RkbGliL2xkaXYuUyAxODQ1 NDcgMjAwOC0xMS0wMiAwMToxMDo1NFogcGV0ZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL2FtZDY0L3N0ZGxpYi9kaXYuUyAxODQ1NDcgMjAwOC0xMS0wMiAwMToxMDo1NFogcGV0ZXIg JAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3hkci94ZHJfc3RkaW8uYyAxMzY1ODIgMjAw NC0xMC0xNiAwNjozMjo0M1ogb2JyaWVuICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy94 ZHIveGRyX2Zsb2F0LmMgMTM2NTgyIDIwMDQtMTAtMTYgMDY6MzI6NDNaIG9icmllbiAkCiAgICAg JEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvdXVpZC91dWlkX3N0cmVhbS5jIDE4MTc0MyAyMDA4LTA4 LTE0IDIyOjIzOjE2WiBlbWF4ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvcnRp bWUuYyAxNDMzNDQgMjAwNS0wMy0xMCAwMDo1NzowMVogc3RlZmFuZiAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvcnBjL2Rlc19zb2Z0LmMgMTM2NTgxIDIwMDQtMTAtMTYgMDY6MTE6MzVa IG9icmllbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL3N2Y19ydW4uYyAxNTYw OTAgMjAwNi0wMi0yNyAyMjoxMDo1OVogZGVpc2NoZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3JwYy9ycGNiX3N0X3hkci5jIDE3Mzc2MyAyMDA3LTExLTIwIDAxOjUxOjIwWiBqYiAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL3BtYXBfZ2V0bWFwcy5jIDEzNjU4MSAy MDA0LTEwLTE2IDA2OjExOjM1WiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3JwYy9nZXRycGNwb3J0LmMgMTM2NTgxIDIwMDQtMTAtMTYgMDY6MTE6MzVaIG9icmllbiAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL2dldHJwY2VudC5jIDE5OTc4NyAyMDA5LTEx LTI1IDA0OjUzOjM4WiB3b2xsbWFuICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMv Y2xudF9wZXJyb3IuYyAxODEzNDQgMjAwOC0wOC0wNiAxNDowMjowNVogZGZyICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9zeXMvc2lncmV0dXJuLlMgMTY1OTAzIDIwMDctMDEt MDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvYW1kNjQvc3lz L3NldGxvZ2luLlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9zeXMvcmVib290LlMgMTg0NTQ3IDIwMDgtMTEtMDIg MDE6MTA6NTRaIHBldGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9zeXMv cHRyYWNlLlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9hbWQ2NC9zeXMvZ2V0Y29udGV4dC5TIDE4NDU0NyAyMDA4LTExLTAy IDAxOjEwOjU0WiBwZXRlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvYW1kNjQvc3lz L2V4ZWN0LlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9hbWQ2NC9zeXMvYnJrLlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6 NTRaIHBldGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9zeXMvYW1kNjRf c2V0X2dzYmFzZS5jIDEyNDI5NiAyMDA0LTAxLTA5IDE2OjUyOjA5WiBuZWN0YXIgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL2FtZDY0L3N5cy9hbWQ2NF9nZXRfZ3NiYXNlLmMgMTI0Mjk2 IDIwMDQtMDEtMDkgMTY6NTI6MDlaIG5lY3RhciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xp YmMvYW1kNjQvc3lzL2FtZDY0X2dldF9mc2Jhc2UuYyAxMjQyOTYgMjAwNC0wMS0wOSAxNjo1Mjow OVogbmVjdGFyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGR0aW1lL3RpbWUzMi5j IDk4MzEzIDIwMDItMDYtMTcgMDE6NDI6MzNaIHdvbGxtYW4gJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL3N0ZHRpbWUvc3RycHRpbWUuYyAxOTY3NTIgMjAwOS0wOS0wMiAwNDo1NjozMFog YWNoZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvY29udHJpYi90emNvZGUvc3RkdGltZS9kaWZmdGlt ZS5jIDE5MjYyNSAyMDA5LTA1LTIzIDA2OjMxOjUwWiBlZHdpbiAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvc3RkaW8vd3NjYW5mLmMgMTAzODU2IDIwMDItMDktMjMgMTI6NDA6MDZaIHRq ciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vd3ByaW50Zi5jIDEwMzczOSAy MDAyLTA5LTIxIDEzOjAwOjMwWiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0 ZGlvL3Z3c2NhbmYuYyAxMDM4NTYgMjAwMi0wOS0yMyAxMjo0MDowNlogdGpyICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby92d3ByaW50Zi5jIDEwMzczOSAyMDAyLTA5LTIxIDEz OjAwOjMwWiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL3ZzY2FuZi5j IDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3N0ZGlvL3ZwcmludGYuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby90bXBuYW0uYyAxNjU5MDMgMjAwNy0w MS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby90 bXBmaWxlLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvc3RkaW8vdGVtcG5hbS5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2 WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL3N3c2NhbmYuYyAxMDM4 NTYgMjAwMi0wOS0yMyAxMjo0MDowNlogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9zdGRpby9zd3ByaW50Zi5jIDEwMzczOSAyMDAyLTA5LTIxIDEzOjAwOjMwWiB0anIgJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL3NldGJ1ZmZlci5jIDE2NTkwMyAyMDA3LTAx LTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL3Nj YW5mLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvc3RkaW8vcmVtb3ZlLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGlt cCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vcHV0d2NoYXIuYyAxMjk3MDUg MjAwNC0wNS0yNSAxMDo0Mjo1MlogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9z dGRpby9wdXR3Yy5jIDEyOTcwNSAyMDA0LTA1LTI1IDEwOjQyOjUyWiB0anIgJAogICAgICRGcmVl QlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL3B1dHcuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODox NlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9wdXRzLmMgMTY1OTAz IDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv c3RkaW8vcHV0Y2hhci5jIDE3ODc3OCAyMDA4LTA1LTA1IDE2OjAzOjUyWiBqaGIgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL2dldHdjaGFyLmMgMTI5NzA1IDIwMDQtMDUtMjUg MTA6NDI6NTJaIHRqciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vZ2V0d2Mu YyAxMjk3MDUgMjAwNC0wNS0yNSAxMDo0Mjo1MlogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9zdGRpby9nZXR3LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vZ2V0cy5jIDE2NTkwMyAyMDA3LTAxLTA5 IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL2dldGxp bmUuYyAxODkxMzYgMjAwOS0wMi0yOCAwNjowMDo1OFogZGFzICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9zdGRpby9nZXRkZWxpbS5jIDE5Nzc1MiAyMDA5LTEwLTA0IDE5OjQzOjM2WiBk YXMgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL2dldGNoYXIuYyAxNzg3Nzgg MjAwOC0wNS0wNSAxNjowMzo1MlogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9z dGRpby9md3NjYW5mLmMgMTAzODU2IDIwMDItMDktMjMgMTI6NDA6MDZaIHRqciAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vZndwcmludGYuYyAxMDM3MzkgMjAwMi0wOS0yMSAx MzowMDozMFogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9md2lkZS5j IDE3ODI4NyAyMDA4LTA0LTE3IDIyOjE3OjU0WiBqaGIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3N0ZGlvL2ZzZXRwb3MuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9mc2NhbmYuYyAxNjU5MDMgMjAwNy0w MS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9m cmVvcGVuLmMgMTc4Mjg3IDIwMDgtMDQtMTcgMjI6MTc6NTRaIGpoYiAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvc3RkaW8vZnB1dHdzLmMgMTg3MzAyIDIwMDktMDEtMTUgMTg6NTM6NTJa IHJkaXZhY2t5ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9mcHVyZ2UuYyAx NjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIv bGliYy9zdGRpby9mZ2V0d3MuYyAxOTk3ODQgMjAwOS0xMS0yNSAwNDo0NTo0NVogd29sbG1hbiAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vZmdldHdsbi5jIDEzMzIyMyAyMDA0 LTA4LTA2IDE3OjAwOjA5WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlv L2ZnZXRwb3MuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9zdGRpby9mZ2V0Yy5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2 WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL2ZjbG9zZWFsbC5jIDE1 Nzk2MyAyMDA2LTA0LTIyIDE2OjQ3OjU5WiBkZWlzY2hlbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQv bGliL2xpYmMvc3RkaW8vZHByaW50Zi5jIDE4OTM1NiAyMDA5LTAzLTA0IDAzOjM4OjUxWiBkYXMg JAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL2NscmVyci5jIDE3ODc3OCAyMDA4 LTA1LTA1IDE2OjAzOjUyWiBqaGIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3Jlc29s di9oZXJyb3IuYyAxNzAyNDQgMjAwNy0wNi0wMyAxNzoyMDoyN1ogdW1lICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9yZWdleC9yZWdlcnJvci5jIDE3MDUyOCAyMDA3LTA2LTExIDAzOjA1 OjU0WiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9wb3NpeDFlL21hY19z ZXQuYyAxNzY5MDEgMjAwOC0wMy0wNyAxNToyNTo1NlogcndhdHNvbiAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvcG9zaXgxZS9tYWNfZ2V0LmMgMTc2OTAxIDIwMDgtMDMtMDcgMTU6MjU6 NTZaIHJ3YXRzb24gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3Bvc2l4MWUvbWFjX2V4 ZWMuYyAxNzY5MDEgMjAwOC0wMy0wNyAxNToyNTo1NlogcndhdHNvbiAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvcG9zaXgxZS9tYWMuYyAxNzY5MDEgMjAwOC0wMy0wNyAxNToyNTo1Nlog cndhdHNvbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcG9zaXgxZS9leHRhdHRyLmMg MTUwMDY1IDIwMDUtMDktMTIgMTk6NTI6NDJaIHN0ZWZhbmYgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL3Bvc2l4MWUvYWNsX3RvX3RleHQuYyAyMDAxNDIgMjAwOS0xMi0wNSAxOTowNDoy MVogZWQgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3Bvc2l4MWUvYWNsX3N0cmlwLmMg MjA0ODE5IDIwMTAtMDMtMDcgMDc6NTk6MDVaIGpvZWwgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3Bvc2l4MWUvYWNsX2Zyb21fdGV4dC5jIDE5OTMxNyAyMDA5LTExLTE2IDA5OjI4OjIy WiBicnVlZmZlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcG9zaXgxZS9hY2xfZGVs ZXRlLmMgMTkyNTg2IDIwMDktMDUtMjIgMTU6NTY6NDNaIHRyYXN6ICQKICAgICAkRnJlZUJTRDog aGVhZC9saWIvbGliYy9wb3NpeDFlL2FjbF9jb21wYXQuYyAxOTI4MDQgMjAwOS0wNS0yNiAxMTo0 MjowNlogdHJhc3ogJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3Bvc2l4MWUvYWNsX2Nv cHkuYyAxOTQ5NTUgMjAwOS0wNi0yNSAxMjo0Njo1OVogdHJhc3ogJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL3Bvc2l4MWUvYWNsX2NhbGNfbWFzay5jIDE5Njc0MCAyMDA5LTA5LTAxIDE4 OjMwOjE3WiB0cmFzeiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbmV0L3ZhcnMuYyA5 NTAyMyAyMDAyLTA0LTE5IDA0OjQ2OjI0WiBzdXogJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL25ldC9zb3VyY2VmaWx0ZXIuYyAxOTE2NTQgMjAwOS0wNC0yOSAwOTo1ODozMVogYm1zICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uZXQvc2N0cF9zeXNfY2FsbHMuYyAyMDMzMjMg MjAxMC0wMS0zMSAyMTo0NzozOVogYnJ1Y2VjICQKICAgICAkRnJlZUJTRDogaGVhZC9zeXMvbmV0 aW5ldC9zY3RwX3Vpby5oIDIwMjc4MiAyMDEwLTAxLTIyIDA3OjUzOjQxWiB0dWV4ZW4gJAogICAg ICRGcmVlQlNEOiBoZWFkL3N5cy9uZXRpbmV0L3NjdHAuaCAxOTQzNTUgMjAwOS0wNi0xNyAxMjoz NDo1NlogcnJzICQKICAgICAkRnJlZUJTRDogaGVhZC9zeXMvbmV0aW5ldC9zY3RwX3Vpby5oIDIw Mjc4MiAyMDEwLTAxLTIyIDA3OjUzOjQxWiB0dWV4ZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL25ldC9ydGhkci5jIDE2ODg2NyAyMDA3LTA0LTE5IDE1OjQ4OjE2WiBtdG0gJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9yZWN2LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6 Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbmV0L3JjbWQuYyAxNjU5 MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9uZXQvbnNzX2NvbXBhdC5jIDEyNzYyNSAyMDA0LTAzLTMwIDE1OjU2OjE1WiBuZWN0YXIgJAog ICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9udG9oLmMgMTY0MDUzIDIwMDYtMTEtMDYg MjI6MDc6NDdaIGNvZ25ldCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbmV0L2xpbmth ZGRyLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvbmV0L2lwNm9wdC5jIDE5OTE4OCAyMDA5LTExLTExIDE1OjIxOjA2WiB1bWUg JAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9pZl9uYW1laW5kZXguYyAxMDAxMzgg MjAwMi0wNy0xNSAxOTo1ODo1NlogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9u ZXQvaWZfaW5kZXh0b25hbWUuYyAxMDAxMzggMjAwMi0wNy0xNSAxOTo1ODo1NlogdW1lICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uZXQvZ2V0cHJvdG9uYW1lLmMgMTY1OTAzIDIwMDct MDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbmV0L2dl dHByb3RvLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvbmV0L2dldG5ldGJ5bmlzLmMgMTU3Nzc5IDIwMDYtMDQtMTUgMTY6MjA6 MjdaIHVtZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbmV0L2dldGlmbWFkZHJzLmMg MTQ0ODE2IDIwMDUtMDQtMDggMjE6MjQ6MjNaIHN0ZWZhbmYgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL25ldC9nZXRob3N0YnluaXMuYyAxNTg0NzcgMjAwNi0wNS0xMiAxNTozNzoyM1og dW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uZXQvZXVpNjQuYyAxMjk5NTcgMjAw NC0wNi0wMSAxOTozMDoxM1ogYnJvb2tzICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9u ZXQvZXRoZXJfYWRkci5jIDE2OTUyMiAyMDA3LTA1LTEzIDEzOjU3OjQ1WiByd2F0c29uICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvd2N3aWR0aC5jIDE2NTkwMyAyMDA3LTAx LTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS93 Y3RyYW5zLmMgMTIxODUyIDIwMDMtMTEtMDEgMDg6MjA6NThaIHRqciAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvbG9jYWxlL3djdG9tYi5jIDEzMjgyMSAyMDA0LTA3LTI5IDA2OjE4OjQw WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS93Y3N0b3VsbC5jIDE2 NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL2xvY2FsZS93Y3N0b3VsLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9jYWxlL3djc3RvbWJzLmMgMTg3MzAyIDIwMDkt MDEtMTUgMTg6NTM6NTJaIHJkaXZhY2t5ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9s b2NhbGUvd2NzdG9sbC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS93Y3N0b2wuYyAxNjU5MDMgMjAwNy0wMS0wOSAw MDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvd2NzZnRp bWUuYyAxODczMTIgMjAwOS0wMS0xNSAyMDo0NTo1OVogcmRpdmFja3kgJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL2xvY2FsZS9ycG1hdGNoLmMgMTM5OTIyIDIwMDUtMDEtMDkgMDM6NTU6 MTNaIHRqciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9jYWxlL25vbWFjcm9zLmMg OTI5ODYgMjAwMi0wMy0yMiAyMTo1MzoyOVogb2JyaWVuICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9sb2NhbGUvbmxfbGFuZ2luZm8uYyAxOTc3NjUgMjAwOS0xMC0wNSAwNzoxMzoxNVog ZWR3aW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS9uZXh0d2N0eXBlLmMg MTMxNzg3IDIwMDQtMDctMDggMDY6NDM6MzdaIHRqciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvbG9jYWxlL21ic3Rvd2NzLmMgMTg3MzAyIDIwMDktMDEtMTUgMTg6NTM6NTJaIHJkaXZh Y2t5ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvbWJ0b3djLmMgMTMyODIx IDIwMDQtMDctMjkgMDY6MTg6NDBaIHRqciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv bG9jYWxlL21ic2luaXQuYyAxMjkxNTMgMjAwNC0wNS0xMiAxNDowOTowNFogdGpyICQKICAgICAk RnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvbWJsZW4uYyAxMzI4MjEgMjAwNC0wNy0yOSAw NjoxODo0MFogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvaXN3Y3R5 cGUuYyAxNzI5MDkgMjAwNy0xMC0yMyAxNzozOToyOFogYWNoZSAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvaW5ldC9pbmV0X25ldG9mLmMgMTcwMjQ0IDIwMDctMDYtMDMgMTc6MjA6Mjda IHVtZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvaW5ldC9pbmV0X25ldGEuYyAxNzAy NDQgMjAwNy0wNi0wMyAxNzoyMDoyN1ogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9pbmV0L2luZXRfbmV0X3B0b24uYyAxODYwOTAgMjAwOC0xMi0xNCAxOTozOTo1M1ogdW1lICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9pbmV0L2luZXRfbmV0X250b3AuYyAxNzAyNDQg MjAwNy0wNi0wMyAxNzoyMDoyN1ogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9p bmV0L2luZXRfbWFrZWFkZHIuYyAxNzAyNDQgMjAwNy0wNi0wMyAxNzoyMDoyN1ogdW1lICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9pbmV0L2luZXRfbG5hb2YuYyAxNzAyNDQgMjAwNy0w Ni0wMyAxNzoyMDoyN1ogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9pbmV0L2lu ZXRfY2lkcl9wdG9uLmMgMTcwMjQ0IDIwMDctMDYtMDMgMTc6MjA6MjdaIHVtZSAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ21vbi9tY291bnQuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoy ODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nbW9uL2dtb24uYyAyMDAx NTAgMjAwOS0xMi0wNSAxOTozMTozOFogZWQgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L2FtZDY0L2dlbi9zaWduYWxjb250ZXh0LmMgMTMyNzk1IDIwMDQtMDctMjggMTM6MDg6MjRaIGRh dmlkeHUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2FtZDY0L2dlbi9tYWtlY29udGV4 dC5jIDEzMjkxMiAyMDA0LTA3LTMxIDAxOjQxOjQxWiBkYXZpZHh1ICQKICAgICAkRnJlZUJTRDog aGVhZC9saWIvbGliYy9hbWQ2NC9nZW4vaW5maW5pdHkuYyAxMTA1NjYgMjAwMy0wMi0wOCAyMDoz Nzo1NVogbWlrZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvYW1kNjQvZ2VuL21vZGYu UyAxODQ1NDcgMjAwOC0xMS0wMiAwMToxMDo1NFogcGV0ZXIgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL2FtZDY0L2dlbi9mYWJzLlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBl dGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9nZW4vc2lnc2V0am1wLlMg MTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9hbWQ2NC9nZW4vc2V0am1wLlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBl dGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9nZW4vcmZvcmtfdGhyZWFk LlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9hbWQ2NC9nZW4vX3NldGptcC5TIDE4NDU0NyAyMDA4LTExLTAyIDAxOjEwOjU0 WiBwZXRlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3dvcmRleHAuYyAxOTk3 ODQgMjAwOS0xMS0yNSAwNDo0NTo0NVogd29sbG1hbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvZ2VuL3dhaXRwaWQuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vd2FpdDMuYyAxNjU5MDMgMjAwNy0wMS0wOSAw MDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vdmFsbG9jLmMg MTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvZ2VuL3V0aW1lLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAg JEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3VudmlzLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6 Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3VuYW1lLmMgMjAy NjYxIDIwMTAtMDEtMTkgMjM6MDc6MTJaIGVkICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9nZW4vdWFsYXJtLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3R0eXNsb3QuYyAyMDI0ODcgMjAxMC0wMS0xNyAxNTo0 MzoxNFogZWQgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi90dHluYW1lLmMgMTg4 NDk3IDIwMDktMDItMTEgMjA6MjQ6NTlaIGVkICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9nZW4vdGltZXpvbmUuYyAyMDAxNTAgMjAwOS0xMi0wNSAxOTozMTozOFogZWQgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi90aW1lcy5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4 OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9zdHJ0b2ZmbGFncy5j IDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL2dlbi9zdGF0dmZzLmMgMTAzMDEyIDIwMDItMDktMDYgMTE6MjQ6MDZaIHRqciAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3NsZWVwLmMgMjAwMTUwIDIwMDktMTItMDUg MTk6MzE6MzhaIGVkICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vc2lnaW50ZXJy dXB0LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvZ2VuL3NldHByb2duYW1lLmMgOTMzOTkgMjAwMi0wMy0yOSAyMjo0Mzo0M1og bWFya20gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9zZXRwcm9jdGl0bGUuYyAx MTcxMDIgMjAwMy0wNy0wMSAwOTo0NTozNVogYWxmcmVkICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9nZW4vc2V0bW9kZS5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAog ICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9zZXRqbXBlcnIuYyAxNjU5MDMgMjAwNy0w MS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vc2V0 aG9zdG5hbWUuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9nZW4vc2V0ZG9tYWlubmFtZS5jIDE2NTkwMyAyMDA3LTAxLTA5IDAw OjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9zZW1jdGwuYyAx OTQ5MTAgMjAwOS0wNi0yNCAyMToxMDo1MlogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIv bGliYy9nZW4vc2Vla2Rpci5jIDE3NDIyMSAyMDA3LTEyLTAzIDE0OjMzOjUxWiBkZXMgJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9zZWVkNDguYyA5Mjk4NiAyMDAyLTAzLTIyIDIx OjUzOjI5WiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9zY2FuZGly LmMgMjAyNjkzIDIwMTAtMDEtMjAgMTE6NTk6NDZaIGFjaGUgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL2dlbi9yZXdpbmRkaXIuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1w ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vcmVhZHBhc3NwaHJhc2UuYyA5MTky MiAyMDAyLTAzLTA5IDAzOjE2OjQxWiBncmVlbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xp YmMvZ2VuL3B3Y2FjaGUuYyAyMDAxNDIgMjAwOS0xMi0wNSAxOTowNDoyMVogZWQgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9wdXR1dHhsaW5lLmMgMjAyODc2IDIwMTAtMDEtMjMg MDg6NDM6MjFaIGVkICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vcHNpZ25hbC5j IDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL2dlbi9wb3NpeF9zcGF3bi5jIDE4NDIwMyAyMDA4LTEwLTIzIDE1OjMyOjA2WiByZGl2 YWNreSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3BvcGVuLmMgMTkyOTI2IDIw MDktMDUtMjcgMTk6Mjg6MDRaIGVkICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4v cG1hZHZpc2UuYyAxMTg2ODQgMjAwMy0wOC0wOSAwMzoyMzoyNFogYm1zICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9nZW4vcGF1c2UuYyAyMDQzMDcgMjAxMC0wMi0yNSAxMzo1MToxMVog a2liICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vbnJhbmQ0OC5jIDkyOTg2IDIw MDItMDMtMjIgMjE6NTM6MjlaIG9icmllbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv Z2VuL25saXN0LmMgMjAwMTUwIDIwMDktMTItMDUgMTk6MzE6MzhaIGVkICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9nZW4vbmljZS5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBp bXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9uZnR3LmMgMTM0MjQ0IDIwMDQt MDgtMjQgMTM6MDA6NTVaIHRqciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL21y YW5kNDguYyA5Mjk4NiAyMDAyLTAzLTIyIDIxOjUzOjI5WiBvYnJpZW4gJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL2dlbi9scmFuZDQ4LmMgOTI5ODYgMjAwMi0wMy0yMiAyMTo1MzoyOVog b2JyaWVuICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vbG9ja2YuYyAxODkzMjgg MjAwOS0wMy0wNCAwMTowMToyNlogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xp YmMvZ2VuL2xjb25nNDguYyA5Mjk4NiAyMDAyLTAzLTIyIDIxOjUzOjI5WiBvYnJpZW4gJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9qcmFuZDQ4LmMgOTI5ODYgMjAwMi0wMy0yMiAy MTo1MzoyOVogb2JyaWVuICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vaW5pdGdy b3Vwcy5jIDE5NDQ5NCAyMDA5LTA2LTE5IDE1OjU4OjI0WiBicm9va3MgJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL2dlbi9nbG9iLmMgMTgwMDIxIDIwMDgtMDYtMjYgMDc6MTI6MzVaIG10 bSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2dldHZmc2J5bmFtZS5jIDE2NTkw MyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L2dlbi9nZXR1dHhlbnQuYyAyMDI1MzAgMjAxMC0wMS0xNyAyMTo0MDowNVogZWQgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9nZXR0dHllbnQuYyAyMDMwNjggMjAxMC0wMS0yNyAx MTo1NDo0MlogZWQgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9nZXRvc3JlbGRh dGUuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9nZW4vZ2V0bW50aW5mby5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBp bXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9nZXRsb2dpbi5jIDIwMDE0MiAy MDA5LTEyLTA1IDE5OjA0OjIxWiBlZCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2Vu L2dldGxvYWRhdmcuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9nZW4vZ2V0Z3JvdXBsaXN0LmMgMTc0NTQ3IDIwMDctMTItMTIg MTA6MDg6MDNaIGJ1c2htYW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9nZXRi c2l6ZS5jIDE4MTI4MCAyMDA4LTA4LTA0IDA2OjUzOjEzWiBjcGVyY2l2YSAkCiAgICAgJEZyZWVC U0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2dldGJvb3RmaWxlLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6 Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2Z0dy5jIDEzNDI0 NCAyMDA0LTA4LTI0IDEzOjAwOjU1WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L2dlbi9mdHMtY29tcGF0LmMgMTc1Njg4IDIwMDgtMDEtMjYgMTc6MDk6NDBaIHlhciAkCiAgICAg JEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2Z0cy5jIDE5OTg0NCAyMDA5LTExLTI2IDE5OjEx OjQ0WiBqaCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2Z0b2suYyAxMjk5MjYg MjAwNC0wNi0wMSAwNjo1MzowN1ogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9n ZW4vZnN0YWIuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9nZW4vZm5tYXRjaC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2 WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9mbXRtc2cuYyAxOTkwNDYg MjAwOS0xMS0wOCAxNDowMjo1NFogYnJ1ZWZmZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL2dlbi9mbXRjaGVjay5jIDE5NDgwMCAyMDA5LTA2LTIzIDIzOjUyOjEyWiBkZWxwaGlqICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vZmVhdHVyZV9wcmVzZW50LmMgMTc1MjIw IDIwMDgtMDEtMTAgMjI6MTE6MjFaIGpoYiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv Z2VuL2ZkZXZuYW1lLmMgMjAwMTMzIDIwMDktMTItMDUgMTg6NTE6NDRaIGVkICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9nZW4vZXJybm8uYyAxMDQ3MDQgMjAwMi0xMC0wOSAwODowNDoy NFogcGV0ZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9kcmFuZDQ4LmMgOTI5 ODYgMjAwMi0wMy0yMiAyMTo1MzoyOVogb2JyaWVuICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIv bGliYy9nZW4vZGlza2xhYmVsLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2Rpcm5hbWUuYyAxODQ1NzggMjAwOC0xMS0w MyAwNToxOTo0NVogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2Rl dm5hbWUuYyAyMDMyOTAgMjAxMC0wMS0zMSAxNDo1MTowNFogZWQgJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL2dlbi9kYWVtb24uYyAyMDUxNjUgMjAxMC0wMy0xNSAwODo1ODozNVogcGhr ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vY3Rlcm1pZC5jIDE2NTkwMyAyMDA3 LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9j cnlwdC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL2dlbi9jb25mc3RyLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGlt cCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2Nsb2NrLmMgMTY1OTAzIDIwMDct MDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2No ZWNrX3V0aWxpdHlfY29tcGF0LmMgMTE0NDQzIDIwMDMtMDUtMDEgMTk6MDM6MTRaIG5lY3RhciAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2Jhc2VuYW1lLmMgMTk3ODA0IDIwMDkt MTAtMDYgMTQ6MDU6NTdaIHJ3YXRzb24gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dl bi9fdGhyZWFkX2luaXQuYyA5MDAzOSAyMDAyLTAyLTAxIDAwOjU3OjI5WiBvYnJpZW4gJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2NvbXBhdC00My9zaWdjb21wYXQuYyAxOTk4MjcgMjAw OS0xMS0yNiAxMzo0OTozN1oga2liICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9jb21w YXQtNDMvc2V0cnVpZC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL2NvbXBhdC00My9zZXRyZ2lkLmMgMTY1OTAzIDIwMDctMDEt MDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvY29tcGF0LTQz L3NldHBncnAuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9jb21wYXQtNDMvc2V0aG9zdGlkLmMgMTY1OTAzIDIwMDctMDEtMDkg MDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvY29tcGF0LTQzL2tp bGxwZy5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL2NvbXBhdC00My9nZXR3ZC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2 WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2NvbXBhdC00My9nZXRob3N0aWQu YyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9jb21wYXQtNDMvY3JlYXQuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1w ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9kYi9tcG9vbC9tcG9vbC1jb21wYXQuYyAx OTA0OTggMjAwOS0wMy0yOCAwNzozMTowMlogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQv bGliL2xpYmMvZGIvaGFzaC9uZGJtLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZGIvYnRyZWUvYnRfZGVidWcuYyAxOTA0OTgg MjAwOS0wMy0yOCAwNzozMTowMlogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xp YmMvc3lzL3RydW5jYXRlLmMgMTcxMjE5IDIwMDctMDctMDQgMjM6Mjc6MzhaIHBldGVyICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zeXMvZmNudGwuYyAxNzk0MzQgMjAwOC0wNS0zMCAx NDo0Nzo0MlogZGZyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvd21lbWNw eS5jIDE4ODA4MCAyMDA5LTAyLTAzIDE3OjU4OjIwWiBkYW5nZXIgJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL3N0cmluZy9zdHJuY2F0LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZa IGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL3N0cnRvbGwuYyAxNjU5 MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9zdGRsaWIvcXNvcnQuYyAxNzUzMTcgMjAwOC0wMS0xNCAwOToyMTozNFogZGFzICQKICAgICAk RnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvcG1hcF9wcm90Mi5jIDEzNjU4MSAyMDA0LTEwLTE2 IDA2OjExOjM1WiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2FtZDY0L3N5 cy9waXBlLlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9hbWQ2NC9zeXMvdmZvcmsuUyAxODQ1NDcgMjAwOC0xMS0wMiAwMTox MDo1NFogcGV0ZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2FtZDY0L3N5cy9hbWQ2 NF9zZXRfZnNiYXNlLmMgMTI0Mjk2IDIwMDQtMDEtMDkgMTY6NTI6MDlaIG5lY3RhciAkCiAgICAg JEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vdnN3c2NhbmYuYyAyMDUwMjEgMjAxMC0wMy0x MSAxNzowMzozMlogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby92c3dw cmludGYuYyAyMDUwMjEgMjAxMC0wMy0xMSAxNzowMzozMlogamhiICQKICAgICAkRnJlZUJTRDog aGVhZC9saWIvbGliYy9zdGRpby92ZndzY2FuZi5jIDE4NzQyMiAyMDA5LTAxLTE5IDA2OjE5OjUx WiBkYXMgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL3Zmd3ByaW50Zi5jIDE5 OTc4MiAyMDA5LTExLTI1IDA0OjI3OjU1WiB3b2xsbWFuICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9zdGRpby92ZHByaW50Zi5jIDIwNTAyMSAyMDEwLTAzLTExIDE3OjAzOjMyWiBqaGIg JAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL3VuZ2V0d2MuYyAxNzgyODcgMjAw OC0wNC0xNyAyMjoxNzo1NFogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRp by9mcHV0d2MuYyAxNzgyODcgMjAwOC0wNC0xNyAyMjoxNzo1NFogamhiICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9zdGRpby9mZ2V0d2MuYyAxNzgyODcgMjAwOC0wNC0xNyAyMjoxNzo1 NFogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9mZW9mLmMgMTc4Nzc4 IDIwMDgtMDUtMDUgMTY6MDM6NTJaIGpoYiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv cmVnZXgvcmVnZXhlYy5jIDE3MDUyOCAyMDA3LTA2LTExIDAzOjA1OjU0WiBkZWxwaGlqICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9yZWdleC9lbmdpbmUuYyAxOTcyNDYgMjAwOS0wOS0x NiAwNjozMjoyM1ogZGRzICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9yZWdleC9lbmdp bmUuYyAxOTcyNDYgMjAwOS0wOS0xNiAwNjozMjoyM1ogZGRzICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9yZWdleC9lbmdpbmUuYyAxOTcyNDYgMjAwOS0wOS0xNiAwNjozMjoyM1ogZGRz ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9yZWdleC9yZWdjb21wLmMgMTcwNTI4IDIw MDctMDYtMTEgMDM6MDU6NTRaIGRlbHBoaWogJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3Bvc2l4MWUvYWNsX3ZhbGlkLmMgMTk0OTU1IDIwMDktMDYtMjUgMTI6NDY6NTlaIHRyYXN6ICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9wb3NpeDFlL2FjbF90b190ZXh0X25mczQuYyAx OTQ5NTcgMjAwOS0wNi0yNSAxMzowODowMlogdHJhc3ogJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3Bvc2l4MWUvYWNsX3Blcm0uYyAxODQ2MDcgMjAwOC0xMS0wNCAwMDoyMDo0M1ogaW1w ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9wb3NpeDFlL2FjbF9mcm9tX3RleHRfbmZz NC5jIDE5NDk1NyAyMDA5LTA2LTI1IDEzOjA4OjAyWiB0cmFzeiAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvcG9zaXgxZS9hY2xfZmxhZy5jIDE5NDk1NyAyMDA5LTA2LTI1IDEzOjA4OjAy WiB0cmFzeiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcG9zaXgxZS9hY2xfZW50cnku YyAxOTQ5NTUgMjAwOS0wNi0yNSAxMjo0Njo1OVogdHJhc3ogJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL3Bvc2l4MWUvYWNsX2RlbGV0ZV9lbnRyeS5jIDIwMDk5MiAyMDA5LTEyLTI1IDE4 OjA1OjA2WiBtYXJrdXMgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9yY21kc2gu YyAxMTE2MTggMjAwMy0wMi0yNyAxMzo0MDowMVogbmVjdGFyICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9uZXQvZ2FpX3N0cmVycm9yLmMgMTk5MDgzIDIwMDktMTEtMDkgMTI6NDY6NTla IHVtZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9jYWxlL3djdHlwZS5jIDE3NzMx MSAyMDA4LTAzLTE3IDE4OjIyOjIzWiBhbnRvaW5lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIv bGliYy9sb2NhbGUvd2NzdG91bWF4LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9jYWxlL3djc3RvbGQuYyAxMjc5OTggMjAw NC0wNC0wNyAwOTo0Nzo1NlogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2Nh bGUvd2NzdG9pbWF4LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9jYWxlL3djc3RvZC5jIDEyNzk5OCAyMDA0LTA0LTA3IDA5 OjQ3OjU2WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS93Y3N0b2Yu YyAxMjc5OTggMjAwNC0wNC0wNyAwOTo0Nzo1NlogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9sb2NhbGUvdG91cHBlci5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAg JAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS90b2xvd2VyLmMgMTY1OTAzIDIw MDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9j YWxlL21ic3J0b3djcy5jIDEzMjQ5NyAyMDA0LTA3LTIxIDEwOjU0OjU3WiB0anIgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS9tYnJsZW4uYyAxMjkxNTQgMjAwNC0wNS0xMiAx NDoyNjo1NFogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvYnRvd2Mu YyAxMjkxNTQgMjAwNC0wNS0xMiAxNDoyNjo1NFogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9nZW4vd2FpdC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi91dHhkYi5jIDIwMjg3NiAyMDEwLTAxLTIzIDA4 OjQzOjIxWiBlZCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3NpZ2xpc3QuYyAx NjYxMzQgMjAwNy0wMS0yMCAwODoyNDowMlogbWF4aW0gJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL2dlbi9nZXRjd2QuYyAxOTgwNTMgMjAwOS0xMC0xMyAyMDo1ODoyMlogamlsbGVzICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vZ2V0Y2FwLmMgMTk5Nzg0IDIwMDktMTEt MjUgMDQ6NDU6NDVaIHdvbGxtYW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9l eGVjLmMgMjAwMTM2IDIwMDktMTItMDUgMTg6NTU6MTZaIGVkICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9nZW4vZXJhbmQ0OC5jIDkyOTg2IDIwMDItMDMtMjIgMjE6NTM6MjlaIG9icmll biAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2Nsb3NlZGlyLmMgMTc0MjIxIDIw MDctMTItMDMgMTQ6MzM6NTFaIGRlcyAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2Vu L19yYW5kNDguYyA5Mjk4NiAyMDAyLTAzLTIyIDIxOjUzOjI5WiBvYnJpZW4gJAogICAgICRGcmVl QlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy93bWVtY2hyLmMgMTg4MDgwIDIwMDktMDItMDMgMTc6 NTg6MjBaIGRhbmdlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3djc25s ZW4uYyAxODkxMzYgMjAwOS0wMi0yOCAwNjowMDo1OFogZGFzICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9zdHJpbmcvd2NzbGVuLmMgMTg4MDgwIDIwMDktMDItMDMgMTc6NTg6MjBaIGRh bmdlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL2luZGV4LmMgMTY1OTAz IDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv c3RkaW8vcGVycm9yLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvcmVnZXgvcmVnZnJlZS5jIDE3MDUyOCAyMDA3LTA2LTExIDAz OjA1OjU0WiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9wb3NpeDFlL2Fj bF9zdXBwb3J0X25mczQuYyAxOTQ5NTcgMjAwOS0wNi0yNSAxMzowODowMlogdHJhc3ogJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3Bvc2l4MWUvYWNsX3NldC5jIDE5NTAwNCAyMDA5LTA2 LTI1IDIwOjU3OjUzWiB0cmFzeiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcG9zaXgx ZS9hY2xfZ2V0LmMgMTk1MDA0IDIwMDktMDYtMjUgMjA6NTc6NTNaIHRyYXN6ICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9wb3NpeDFlL2FjbF9mcmVlLmMgOTI5ODYgMjAwMi0wMy0yMiAy MTo1MzoyOVogb2JyaWVuICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9nZW4v bGRleHAuYyAxNjU5MDUgMjAwNy0wMS0wOSAwMDozODoyNFogaW1wICQKICAgICAkRnJlZUJTRDog aGVhZC9saWIvbGliYy9nZW4vb3BlbmRpci5jIDIwMjY3OSAyMDEwLTAxLTIwIDA3OjM2OjI5WiBh Y2hlICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRsaWIvbWVyZ2UuYyAxNjU5MDMg MjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9w b3NpeDFlL2FjbF9zdXBwb3J0LmMgMTk2NjM4IDIwMDktMDgtMjkgMDM6MTc6MjRaIGtpZW50emxl ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9wb3NpeDFlL2FjbF9pbml0LmMgMTk0OTU1 IDIwMDktMDYtMjUgMTI6NDY6NTlaIHRyYXN6ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9wb3NpeDFlL2FjbF9icmFuZGluZy5jIDE5NDk1NyAyMDA5LTA2LTI1IDEzOjA4OjAyWiB0cmFz eiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3RlbGxkaXIuYyAxNzg3NzIgMjAw OC0wNS0wNSAxNDowNToyM1oga2liICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4v cmVhZGRpci5jIDE3ODc3MiAyMDA4LTA1LTA1IDE0OjA1OjIzWiBraWIgJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL3N0cmluZy9zdHJlcnJvci5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4 OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25scy9tc2djYXQuYyAyMDQx MTAgMjAxMC0wMi0yMCAwODoxOToxOVogZ2Fib3IgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL2xvY2FsZS9zZXRsb2NhbGUuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvbG1lc3NhZ2VzLmMgMTE2ODc1IDIw MDMtMDYtMjYgMTA6NDY6MTZaIHBoYW50b20gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L2dlbi9lcnJsc3QuYyAxOTc4NDEgMjAwOS0xMC0wNyAyMDoyMDo1MVogcndhdHNvbiAkCiAgICAg JEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9jYWxlL3NldHJ1bmVsb2NhbGUuYyAxNzU1ODYgMjAw OC0wMS0yMyAwMzowNTozNVogYWNoZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9j YWxlL3J1bmUuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9sb2NhbGUvbXNrYW5qaS5jIDE3MjYxOSAyMDA3LTEwLTEzIDE2OjI4 OjIyWiBhY2hlICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvbWJzbnJ0b3dj cy5jIDEzMjQ5NyAyMDA0LTA3LTIxIDEwOjU0OjU3WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL2xvY2FsZS9nYmsuYyAxNzI2MTkgMjAwNy0xMC0xMyAxNjoyODoyMlogYWNoZSAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9jYWxlL2diMjMxMi5jIDE3MjYxOSAyMDA3 LTEwLTEzIDE2OjI4OjIyWiBhY2hlICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2Nh bGUvZ2IxODAzMC5jIDE3MjYxOSAyMDA3LTEwLTEzIDE2OjI4OjIyWiBhY2hlICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvZXVjLmMgMTcyNjE5IDIwMDctMTAtMTMgMTY6Mjg6 MjJaIGFjaGUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS9iaWc1LmMgMTcy NjE5IDIwMDctMTAtMTMgMTY6Mjg6MjJaIGFjaGUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL2xvY2FsZS9hc2NpaS5jIDE3NTU1MyAyMDA4LTAxLTIxIDIzOjQ4OjEyWiBhY2hlICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvd2NzbnJ0b21icy5jIDE0MTcxNiAyMDA1 LTAyLTEyIDA4OjQ1OjEyWiBzdGVmYW5mICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9s b2NhbGUvdXRmOC5jIDE3MjY2MSAyMDA3LTEwLTE1IDA5OjUxOjMwWiBhY2hlICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvc3RyZHVwLmMgMTg4MDgwIDIwMDktMDItMDMgMTc6 NTg6MjBaIGRhbmdlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL3JlYWxs b2NmLmMgMjA0NjM2IDIwMTAtMDMtMDMgMTU6NDM6MjZaIGpoICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9zdGRsaWIvbWFsbG9jLmMgMjA0NDkzIDIwMTAtMDItMjggMjI6NTc6MTNaIGph c29uZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL3JiLmggMjA0NDkzIDIw MTAtMDItMjggMjI6NTc6MTNaIGphc29uZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv c3RkbGliL3FyLmggMjAzMzI5IDIwMTAtMDEtMzEgMjM6MTY6MTBaIGphc29uZSAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL3FsLmggMjAzMzI5IDIwMTAtMDEtMzEgMjM6MTY6 MTBaIGphc29uZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL2Zmcy5jIDE2 NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL2FtZDY0L3N5cy9zYnJrLlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby92c25wcmludGYuYyAyMDUwMjEgMjAx MC0wMy0xMSAxNzowMzozMlogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4v Z2V0cGFnZXNpemVzLmMgMTk3MzMxIDIwMDktMDktMTkgMTg6MDE6MzJaIGFsYyAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3lzL21tYXAuYyAxNzEyMTkgMjAwNy0wNy0wNCAyMzoyNzoz OFogcGV0ZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9leGl0LmMgMTY1 OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xp YmMvcnBjL2F1dGhfZGVzLmMgMTU2MDkwIDIwMDYtMDItMjcgMjI6MTA6NTlaIGRlaXNjaGVuICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvbmV0bmFtZS5jIDE5NDQ5OCAyMDA5LTA2 LTE5IDE3OjEwOjM1WiBicm9va3MgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9h dXRoZGVzX3Byb3QuYyAxNzM3NjMgMjAwNy0xMS0yMCAwMTo1MToyMFogamIgJAogICAgICRGcmVl QlNEOiBoZWFkL2xpYi9saWJjL3JwYy9hdXRoX3RpbWUuYyAxNzIyNTkgMjAwNy0wOS0yMCAyMjoz NToyNFogbWF0dGVvICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvcnBjX2R0YWJs ZXNpemUuYyAxMzY1ODEgMjAwNC0xMC0xNiAwNjoxMTozNVogb2JyaWVuICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9pbmV0L2luZXRfbnRvYS5jIDE3MDcxNSAyMDA3LTA2LTE0IDA3OjEz OjI4WiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vc2lnbmFsLmMg MTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvZ2VuL2FsYXJtLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAg JEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL3JwY2JfY2xudC5jIDE3MjI1OSAyMDA3LTA5LTIw IDIyOjM1OjI0WiBtYXR0ZW8gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9ycGNf c29jLmMgMjA0OTUwIDIwMTAtMDMtMTAgMTM6MjM6MjVaIGpoYiAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvcnBjL3N2Y19zaW1wbGUuYyAxNjIxOTUgMjAwNi0wOS0wOSAyMjozMjowN1og bWJyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvc3ZjX3Jhdy5jIDE5OTc4NSAy MDA5LTExLTI1IDA0OjQ5OjQxWiB3b2xsbWFuICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9ycGMvc3ZjX2dlbmVyaWMuYyAxOTQ0NDggMjAwOS0wNi0xOCAxNzoxMDo0M1oga2FuICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvc3ZjX2RnLmMgMTk0NDQ4IDIwMDktMDYtMTgg MTc6MTA6NDNaIGthbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL3BtYXBfZ2V0 cG9ydC5jIDEzNjU4MSAyMDA0LTEwLTE2IDA2OjExOjM1WiBvYnJpZW4gJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL3JwYy9jbG50X3NpbXBsZS5jIDIwNDk1MCAyMDEwLTAzLTEwIDEzOjIz OjI1WiBqaGIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9jbG50X3Jhdy5jIDE5 OTc4NiAyMDA5LTExLTI1IDA0OjUyOjEyWiB3b2xsbWFuICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9ycGMvY2xudF9iY2FzdC5jIDE5MDg3MSAyMDA5LTA0LTA5IDIwOjU3OjM1WiBlbWFz dGUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9pZl9uYW1ldG9pbmRleC5jIDEx NDQ0MyAyMDAzLTA1LTAxIDE5OjAzOjE0WiBuZWN0YXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL25ldC9nZXRpZmFkZHJzLmMgMTk3MDI5IDIwMDktMDktMDkgMTA6MzE6MjBaIHBoayAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL3N2Y192Yy5jIDE4MTM0NCAyMDA4LTA4 LTA2IDE0OjAyOjA1WiBkZnIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9zdmMu YyAyMDAwNjEgMjAwOS0xMi0wMyAxNToxNDozMFogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9ycGMvcnBjYl9wcm90LmMgMTczNzYzIDIwMDctMTEtMjAgMDE6NTE6MjBaIGpiICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvcnBjX2NhbGxtc2cuYyAxNzM3NjMgMjAw Ny0xMS0yMCAwMTo1MToyMFogamIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9y cGNfY29tbW9uZGF0YS5jIDkyOTkwIDIwMDItMDMtMjIgMjM6MTg6MzdaIG9icmllbiAkCiAgICAg JEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL3BtYXBfcm10LmMgMTM2NTgxIDIwMDQtMTAtMTYg MDY6MTE6MzVaIG9icmllbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL3BtYXBf cHJvdC5jIDEzNjU4MSAyMDA0LTEwLTE2IDA2OjExOjM1WiBvYnJpZW4gJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL3JwYy9wbWFwX2NsbnQuYyAxMzY1ODEgMjAwNC0xMC0xNiAwNjoxMToz NVogb2JyaWVuICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vZ2V0cGVlcmVpZC5j IDEwNzkyOSAyMDAyLTEyLTE2IDEzOjQyOjEzWiBtYXhpbSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQv bGliL2xpYmMvc3RyaW5nL2Zmc2wuYyAxODQ1ODYgMjAwOC0xMS0wMyAxMDoxNDo0N1oga2liICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy94ZHIveGRyX3JlZmVyZW5jZS5jIDEzNjU4MiAy MDA0LTEwLTE2IDA2OjMyOjQzWiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3JwYy9zdmNfYXV0aC5jIDE4Mjg5MSAyMDA4LTA5LTA5IDE0OjE1OjU1WiBkZnIgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9zdmNfYXV0aF9kZXMuYyAyMDE5NTkgMjAxMC0wMS0w OSAyMzozNjo1MVogYnJvb2tzICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvZ2V0 cHVibGlja2V5LmMgMTU2MTA5IDIwMDYtMDItMjggMTY6MDI6MjZaIGRlaXNjaGVuICQKICAgICAk RnJlZUJTRDogaGVhZC9pbmNsdWRlL3JwY3N2Yy9rZXlfcHJvdC54IDExNDYyOSAyMDAzLTA1LTA0 IDAyOjUxOjQyWiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9rZXlf Y2FsbC5jIDIwNDk1MCAyMDEwLTAzLTEwIDEzOjIzOjI1WiBqaGIgJAogICAgICRGcmVlQlNEOiBo ZWFkL2luY2x1ZGUvcnBjc3ZjL2tleV9wcm90LnggMTE0NjI5IDIwMDMtMDUtMDQgMDI6NTE6NDJa IG9icmllbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL2Rlc19jcnlwdC5jIDEz NjU4MSAyMDA0LTEwLTE2IDA2OjExOjM1WiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3JwYy9zdmNfYXV0aF91bml4LmMgMTM2NTgxIDIwMDQtMTAtMTYgMDY6MTE6MzVaIG9i cmllbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL2F1dGhfdW5peC5jIDE5NDQ5 NCAyMDA5LTA2LTE5IDE1OjU4OjI0WiBicm9va3MgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL2dlbi9zeXNjb25mLmMgMjA0MzQ3IDIwMTAtMDItMjYgMDY6NDQ6MDBaIGVkd2luICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vZ2V0cGFnZXNpemUuYyAxNjU5MDMgMjAwNy0w MS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vX194 dW5hbWUuYyAxODQxODUgMjAwOC0xMC0yMiAyMTo1Njo1N1oga2liICQKICAgICAkRnJlZUJTRDog aGVhZC9saWIvbGliYy9ycGMvbmV0bmFtZXIuYyAxOTQ0OTggMjAwOS0wNi0xOSAxNzoxMDozNVog YnJvb2tzICQKICAgICAkRnJlZUJTRDogaGVhZC9pbmNsdWRlL3JwY3N2Yy9rZXlfcHJvdC54IDEx NDYyOSAyMDAzLTA1LTA0IDAyOjUxOjQyWiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3JwYy9rZXlfcHJvdF94ZHIuYyAxNzM3NjMgMjAwNy0xMS0yMCAwMTo1MToyMFogamIg JAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9jcnlwdF9jbGllbnQuYyAxMTEwMTAg MjAwMy0wMi0xNiAxNzoyOToxMVogbmVjdGFyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9ycGMvY2xudF9nZW5lcmljLmMgMTM2NTgxIDIwMDQtMTAtMTYgMDY6MTE6MzVaIG9icmllbiAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL2NsbnRfZGcuYyAxODMwMzkgMjAwOC0w OS0xNSAxNDowMjo0OVogZGZyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvYmlu ZHJlc3Zwb3J0LmMgMTM2NTgxIDIwMDQtMTAtMTYgMDY6MTE6MzVaIG9icmllbiAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL2F1dGh1bml4X3Byb3QuYyAxNzM3NjMgMjAwNy0xMS0y MCAwMTo1MToyMFogamIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9zeXNjdGxi eW5hbWUuYyAyMDQxNzIgMjAxMC0wMi0yMSAxNDo1ODowMVogZWQgJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL2dlbi9nZXRwd2VudC5jIDE1ODExNSAyMDA2LTA0LTI4IDEyOjAzOjM4WiB1 bWUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9nZXRuZXRncmVudC5jIDE2NTkw MyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L2dlbi9nZXRncmVudC5jIDE3NDU0NyAyMDA3LTEyLTEyIDEwOjA4OjAzWiBidXNobWFuICQKICAg ICAkRnJlZUJTRDogaGVhZC9pbmNsdWRlL3JwY3N2Yy9jcnlwdC54IDExNDYyOSAyMDAzLTA1LTA0 IDAyOjUxOjQyWiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9ycGNk bmFtZS5jIDEzNjU4MSAyMDA0LTEwLTE2IDA2OjExOjM1WiBvYnJpZW4gJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL3JwYy9jbG50X3ZjLmMgMTgxMzQ0IDIwMDgtMDgtMDYgMTQ6MDI6MDVa IGRmciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcnBjL2F1dGhfbm9uZS5jIDE1NjA5 MCAyMDA2LTAyLTI3IDIyOjEwOjU5WiBkZWlzY2hlbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvZ2VuL3N5c2N0bG5hbWV0b21pYi5jIDIwNDE3MCAyMDEwLTAyLTIxIDEzOjU3OjAyWiBl ZCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3B3X3NjYW4uYyAxOTU4MjcgMjAw OS0wNy0yMiAyMDo0NjoxN1oga2Vuc21pdGggJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L2dlbi9nZXR1c2Vyc2hlbGwuYyAxOTk3ODQgMjAwOS0xMS0yNSAwNDo0NTo0NVogd29sbG1hbiAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2dldGRvbWFpbm5hbWUuYyAxNjU5MDMg MjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9z dHJpbmcvc3Ryc2VwLmMgMTg4MDgwIDIwMDktMDItMDMgMTc6NTg6MjBaIGRhbmdlciAkCiAgICAg JEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL2F0b2wuYyAxNjU5MDMgMjAwNy0wMS0wOSAw MDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9zdHJpbmcv Ynplcm8uUyAxODQ1NDcgMjAwOC0xMS0wMiAwMToxMDo1NFogcGV0ZXIgJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL3hkci94ZHJfcmVjLmMgMTgxMzQ0IDIwMDgtMDgtMDYgMTQ6MDI6MDVa IGRmciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMveGRyL3hkcl9tZW0uYyAxMzY1ODIg MjAwNC0xMC0xNiAwNjozMjo0M1ogb2JyaWVuICQKICAgICAkRnJlZUJTRDogaGVhZC9pbmNsdWRl L3JwY3N2Yy9jcnlwdC54IDExNDYyOSAyMDAzLTA1LTA0IDAyOjUxOjQyWiBvYnJpZW4gJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9ycGNfZ2VuZXJpYy5jIDIwNTAyMCAyMDEwLTAz LTExIDE2OjU4OjE1WiBqaGIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3JwYy9ycGNf cHJvdC5jIDE3Mzc2MyAyMDA3LTExLTIwIDAxOjUxOjIwWiBqYiAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvcnBjL210X21pc2MuYyAyMDQ5NTAgMjAxMC0wMy0xMCAxMzoyMzoyNVogamhi ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9hc3ByaW50Zi5jIDE5OTA5NiAy MDA5LTExLTA5IDE4OjUwOjM0WiBqaGIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dl bi9zdHJpbmdsaXN0LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3N0cnJjaHIuYyA5Mjk4NiAyMDAyLTAzLTIyIDIx OjUzOjI5WiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy9yaW5k ZXguYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy94ZHIveGRyX2FycmF5LmMgMTM2NTgyIDIwMDQtMTAtMTYgMDY6MzI6NDNaIG9i cmllbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMveGRyL3hkci5jIDE4NDU4OCAyMDA4 LTExLTAzIDEwOjM4OjAwWiBkZnIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlv L3Zhc3ByaW50Zi5jIDIwNTAyMSAyMDEwLTAzLTExIDE3OjAzOjMyWiBqaGIgJAogICAgICRGcmVl QlNEOiBoZWFkL2xpYi9saWJjL3JwYy9nZXRuZXRwYXRoLmMgMjAxNjAzIDIwMTAtMDEtMDUgMjA6 MTg6NDFaIGJydWVmZmVyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9ycGMvZ2V0bmV0 Y29uZmlnLmMgMjA0OTUwIDIwMTAtMDMtMTAgMTM6MjM6MjVaIGpoYiAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvc3RyaW5nL3N0cnRvay5jIDE3NDU1MyAyMDA3LTEyLTEyIDE4OjMzOjA2 WiB3ZXMgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N5cy9zdGFja19wcm90ZWN0b3Iu YyAxOTcyNzcgMjAwOS0wOS0xNyAxMzoyMTo1M1oga2FuICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9zdGR0aW1lL3N0cmZ0aW1lLmMgMTkzODE3IDIwMDktMDYtMDkgMDk6MDI6NThaIGRl bHBoaWogJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZHRpbWUvdGltZWxvY2FsLmMg MTE2Mjc0IDIwMDMtMDYtMTMgMDA6MTQ6MDdaIGpraCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvZ2VuL3Zpcy5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9lcnIuYyAxNzc4OTMgMjAwOC0wNC0wMyAyMDozNjo0 NFogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9md2Fsay5jIDE2NTkw MyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3Jlc29sdi9yZXNfdXBkYXRlLmMgMTcwMjQ0IDIwMDctMDYtMDMgMTc6MjA6MjdaIHVtZSAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvcmVzb2x2L3Jlc19maW5kem9uZWN1dC5jIDE3MDI0 NCAyMDA3LTA2LTAzIDE3OjIwOjI3WiB1bWUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3Jlc29sdi9yZXNfc2VuZC5jIDE4NjA5MCAyMDA4LTEyLTE0IDE5OjM5OjUzWiB1bWUgJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9nZXRuYW1laW5mby5jIDE5OTIyMSAyMDA5LTEx LTEyIDExOjU0OjEyWiB1bWUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2lzYy9ldl90 aW1lcnMuYyAxNzAyNDQgMjAwNy0wNi0wMyAxNzoyMDoyN1ogdW1lICQKICAgICAkRnJlZUJTRDog aGVhZC9saWIvbGliYy9pc2MvZXZfc3RyZWFtcy5jIDE3MDI0NCAyMDA3LTA2LTAzIDE3OjIwOjI3 WiB1bWUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9uYW1lNi5jIDE3MTY3MSAy MDA3LTA3LTMxIDE2OjA5OjQxWiBidXNobWFuICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9yZXNvbHYvcmVzX3F1ZXJ5LmMgMTg2MDkwIDIwMDgtMTItMTQgMTk6Mzk6NTNaIHVtZSAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vc2V0YnVmLmMgMTY1OTAzIDIwMDctMDEt MDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vc2V0 dmJ1Zi5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL3Jlc29sdi9yZXNfbWt1cGRhdGUuYyAxNzAyNDQgMjAwNy0wNi0wMyAxNzoy MDoyN1ogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9zc2NhbmYuYyAy MDA4MDAgMjAwOS0xMi0yMSAxOTo1NjowM1ogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQv bGliL2xpYmMvbmV0L2dldHByb3RvZW50LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGlt cCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vdnNzY2FuZi5jIDIwNTAyMSAy MDEwLTAzLTExIDE3OjAzOjMyWiBqaGIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0 ZGlvL3Zmc2NhbmYuYyAxODc0MjIgMjAwOS0wMS0xOSAwNjoxOTo1MVogZGFzICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby91bmdldGMuYyAxNzgyODcgMjAwOC0wNC0xNyAyMjox Nzo1NFogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvd2N0b2IuYyAx MjkxNTQgMjAwNC0wNS0xMiAxNDoyNjo1NFogdGpyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIv bGliYy9sb2NhbGUvcnVuZXR5cGUuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvbWJydG93Yy5jIDEyOTE1MyAyMDA0 LTA1LTEyIDE0OjA5OjA0WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2Fs ZS9jb2xsY21wLmMgMTQyNjUzIDIwMDUtMDItMjcgMTQ6NTQ6MjNaIHBoYW50b20gJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy9zdHJjb2xsLmMgMTg4MDgwIDIwMDktMDItMDMg MTc6NTg6MjBaIGRhbmdlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL3N0 cnRvdW1heC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9zdHJ0b2ltYXguYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoy ODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZHRvYS9tYWNoZGVwX2xk aXN4LmMgMTc0MjA0IDIwMDctMTItMDMgMDc6MTc6MzNaIGRhcyAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvbG9jYWxlL2lzY3R5cGUuYyAxNzI2MTkgMjAwNy0xMC0xMyAxNjoyODoyMlog YWNoZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9jYWxlL2NvbGxhdGUuYyAxNDI2 ODYgMjAwNS0wMi0yNyAyMDozMToxM1ogcnUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3Jlc29sdi9yZXNfbWtxdWVyeS5jIDE4NjA5MCAyMDA4LTEyLTE0IDE5OjM5OjUzWiB1bWUgJAog ICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3Jlc29sdi9yZXNfaW5pdC5jIDE3NDIyNiAyMDA3 LTEyLTAzIDE1OjEzOjQ0WiB1bWUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmlu Zy9zdHJjc3BuLmMgMTQ0NTQ1IDIwMDUtMDQtMDIgMTg6NTI6NDRaIGRhcyAkCiAgICAgJEZyZWVC U0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL2F0b2kuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODox NlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uZXQvZ2V0YWRkcmluZm8uYyAx OTA1MjUgMjAwOS0wMy0yOSAxNzo1NToxMVogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIv bGliYy9nZW4vZ2V0aG9zdG5hbWUuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uZXQvZ2V0c2VydmVudC5jIDE2NTkwMyAyMDA3 LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlv L2ZnZXRsbi5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNE OiBoZWFkL2xpYi9saWJjL3Jlc29sdi9yZXNfZGVidWcuYyAxODYwOTAgMjAwOC0xMi0xNCAxOToz OTo1M1ogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRsaWIvc3RydG91bC5j IDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL3N0ZGlvL3B1dGMuYyAxNzg3NzggMjAwOC0wNS0wNSAxNjowMzo1MlogamhiICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9yZXNvbHYvcmVzX2RhdGEuYyAxNzQyMjYgMjAwNy0x Mi0wMyAxNToxMzo0NFogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uYW1lc2Vy L25zX3ByaW50LmMgMTcwMjQ0IDIwMDctMDYtMDMgMTc6MjA6MjdaIHVtZSAkCiAgICAgJEZyZWVC U0Q6IGhlYWQvbGliL2xpYmMvaW5ldC9uc2FwX2FkZHIuYyAxNzAyNDQgMjAwNy0wNi0wMyAxNzoy MDoyN1ogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9pbmV0L2luZXRfbnRvcC5j IDE3MDI0NCAyMDA3LTA2LTAzIDE3OjIwOjI3WiB1bWUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL2dlbi9hc3NlcnQuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9yZXNvbHYvbXRjdHhyZXMuYyAxNjUyNTggMjAwNi0x Mi0xNSAyMDo1OTo1NVogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uZXQvYmFz ZTY0LmMgOTI5ODYgMjAwMi0wMy0yMiAyMTo1MzoyOVogb2JyaWVuICQKICAgICAkRnJlZUJTRDog aGVhZC9saWIvbGliYy9uYW1lc2VyL25zX3NhbWVkb21haW4uYyAxNzAyNDQgMjAwNy0wNi0wMyAx NzoyMDoyN1ogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uZXQvbnNwYXJzZXIu eSAxNjk2NDQgMjAwNy0wNS0xNyAwMzozMzoyM1ogam9uICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9zdGRpby9md3JpdGUuYyAyMDE5OTkgMjAxMC0wMS0xMCAxNDozMDozMFogY3BlcmNp dmEgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL2ZyZWFkLmMgMjAxOTk5IDIw MTAtMDEtMTAgMTQ6MzA6MzBaIGNwZXJjaXZhICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9zdGRpby9maWxlbm8uYyAxNzg3NzggMjAwOC0wNS0wNSAxNjowMzo1MlogamhiICQKICAgICAk RnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9mZXJyb3IuYyAxNzg3NzggMjAwOC0wNS0wNSAx NjowMzo1MlogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uZXQvZ2V0bmV0bmFt YWRyLmMgMTU4MTE1IDIwMDYtMDQtMjggMTI6MDM6MzhaIHVtZSAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvbmV0L2dldG5ldGJ5aHQuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlog aW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9uZXQvZ2V0bmV0YnlkbnMuYyAxNjU5 MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9pbmV0L2luZXRfbmV0d29yay5jIDE3NTMzMCAyMDA4LTAxLTE0IDIyOjU2OjA1WiBjcGVyY2l2 YSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbmV0L2dldGhvc3RuYW1hZHIuYyAxNTg3 OTEgMjAwNi0wNS0yMSAxMToyNzoyOFogdW1lICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9uZXQvbnNkaXNwYXRjaC5jIDE5MjkxMSAyMDA5LTA1LTI3IDE3OjAxOjU5WiB6bWwgJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9nZXRob3N0YnlodC5jIDE2NTkwMyAyMDA3LTAx LTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9nZXRo b3N0YnlkbnMuYyAxODgzMTYgMjAwOS0wMi0wOCAxNjo1ODowNVogdW1lICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9pbmV0L2luZXRfcHRvbi5jIDE3MDI0NCAyMDA3LTA2LTAzIDE3OjIw OjI3WiB1bWUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2luZXQvaW5ldF9hZGRyLmMg MTcwMjQ0IDIwMDctMDYtMDMgMTc6MjA6MjdaIHVtZSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvZ2VuL3N5c2xvZy5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi9kbGZjbi5jIDE5MDY3MyAyMDA5LTA0LTAzIDE5 OjE3OjIzWiBraWIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy9zdHJzdHIu YyAxODgwODAgMjAwOS0wMi0wMyAxNzo1ODoyMFogZGFuZ2VyICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9zdHJpbmcvc3RycGJyay5jIDE4ODA4MCAyMDA5LTAyLTAzIDE3OjU4OjIwWiBk YW5nZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy9zdHJsY3B5LmMgMTg5 MTMzIDIwMDktMDItMjggMDU6MTU6MDJaIGRhcyAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xp YmMvc3RyaW5nL3N0cmxjYXQuYyAxODkxMzMgMjAwOS0wMi0yOCAwNToxNTowMlogZGFzICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvc3RyY2FzZWNtcC5jIDE4ODA4MCAyMDA5 LTAyLTAzIDE3OjU4OjIwWiBkYW5nZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0 ZGxpYi9xc29ydC5jIDE3NTMxNyAyMDA4LTAxLTE0IDA5OjIxOjM0WiBkYXMgJAogICAgICRGcmVl QlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9ic2VhcmNoLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6 Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkbGliL2F0ZXhpdC5j IDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xp Yi9saWJjL2FtZDY0L3N0cmluZy9iY21wLlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBl dGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9jb250cmliL3R6Y29kZS9zdGR0aW1lL2xvY2FsdGlt ZS5jIDIwMTY2OSAyMDEwLTAxLTA2IDIwOjQzOjQwWiBqaGIgJAogICAgICRGcmVlQlNEOiBoZWFk L2NvbnRyaWIvdHpjb2RlL3N0ZHRpbWUvYXNjdGltZS5jIDE5MjYyNSAyMDA5LTA1LTIzIDA2OjMx OjUwWiBlZHdpbiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vcmV3aW5kLmMg MTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvc3RkaW8vcHJpbnRmLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vZnVub3Blbi5jIDIwMDE1MCAyMDA5LTEy LTA1IDE5OjMxOjM4WiBlZCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vZnNl ZWsuYyAxNzgyODcgMjAwOC0wNC0xNyAyMjoxNzo1NFogamhiICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9zdGRpby9mcHV0cy5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAg JAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL2ZwdXRjLmMgMTY1OTAzIDIwMDct MDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8v Zm9wZW4uYyAxNzg0MjcgMjAwOC0wNC0yMiAxNzowMzozMlogamhiICQKICAgICAkRnJlZUJTRDog aGVhZC9saWIvbGliYy9zdGRpby9mZ2V0cy5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBp bXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3Jlc29sdi9yZXNfY29tcC5jIDE5MzAy MyAyMDA5LTA1LTI5IDA3OjM0OjU0WiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIv bGliYy9uZXQvc2VuZC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL25ldC9tYXBfdjR2Ni5jIDE2NTkwMyAyMDA3LTAxLTA5IDAw OjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi91c2xlZXAuYyAy MDAxNTAgMjAwOS0xMi0wNSAxOTozMTozOFogZWQgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL2dlbi90aW1lLmMgMjAxMTk0IDIwMDktMTItMjkgMTI6NDc6NDdaIGtpYiAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL19vbmNlX3N0dWIuYyAxOTk2MTQgMjAwOS0xMS0yMCAy MDo0MzozNFogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJpbmcvc3RybmNw eS5jIDE4ODA4MCAyMDA5LTAyLTAzIDE3OjU4OjIwWiBkYW5nZXIgJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL3N0ZGlvL3didWYuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1w ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9zcHJpbnRmLmMgMjAwODAyIDIw MDktMTItMjEgMTk6NTk6MzhaIGRlbHBoaWogJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJj L3N0ZGlvL2Z0ZWxsLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vdnNwcmludGYuYyAyMDUwMjEgMjAxMC0wMy0xMSAx NzowMzozMlogamhiICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvbG9jYWxl Y29udi5jIDE3NDU0NiAyMDA3LTEyLTEyIDA3OjQzOjIzWiBwaGFudG9tICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9sb2NhbGUvbG51bWVyaWMuYyAxMTY4NzUgMjAwMy0wNi0yNiAxMDo0 NjoxNlogcGhhbnRvbSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvbG9jYWxlL2xtb25l dGFyeS5jIDExNjg3NSAyMDAzLTA2LTI2IDEwOjQ2OjE2WiBwaGFudG9tICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9sb2NhbGUvbGRwYXJ0LmMgMTI4NjUwIDIwMDQtMDQtMjUgMTk6NTY6 NTBaIGFjaGUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS9maXhfZ3JvdXBp bmcuYyAxMTY4NzUgMjAwMy0wNi0yNiAxMDo0NjoxNlogcGhhbnRvbSAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvc3RkbGliL3N0cnRvbC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2 WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2FtZDY0L3N0cmluZy9zdHJjbXAu UyAxODQ1NDcgMjAwOC0xMS0wMiAwMToxMDo1NFogcGV0ZXIgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL2FtZDY0L3N0cmluZy9zdHJjYXQuUyAxODQ1NDcgMjAwOC0xMS0wMiAwMToxMDo1 NFogcGV0ZXIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2RiL3JlY25vL3JlY19wdXQu YyAxOTA0ODQgMjAwOS0wMy0yOCAwNTo0NToyOVogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvZGIvcmVjbm8vcmVjX29wZW4uYyAxODkzMjcgMjAwOS0wMy0wNCAwMDo1ODow NFogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vZmRvcGVuLmMg MTc4OTIxIDIwMDgtMDUtMTAgMTg6Mzk6MjBaIGFudG9pbmUgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL2RiL3JlY25vL3JlY19zZXEuYyAxODkzMjcgMjAwOS0wMy0wNCAwMDo1ODowNFog ZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZGIvcmVjbm8vcmVjX2dldC5j IDE4OTM4NyAyMDA5LTAzLTA1IDAwOjU3OjAxWiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9kYi9yZWNuby9yZWNfZGVsZXRlLmMgMTg5MjkyIDIwMDktMDMtMDMgMDI6MTY6 MTJaIGRlbHBoaWogJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2RiL3JlY25vL3JlY19j bG9zZS5jIDE5MDQ4NCAyMDA5LTAzLTI4IDA1OjQ1OjI5WiBkZWxwaGlqICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9zeXMvZnRydW5jYXRlLmMgMTcxMjE5IDIwMDctMDctMDQgMjM6Mjc6 MzhaIHBldGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9nZXRjLmMgMTc4 Nzc4IDIwMDgtMDUtMDUgMTY6MDM6NTJaIGpoYiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xp YmMvc3RkaW8vZmxhZ3MuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAk RnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9mY2xvc2UuYyAxNjU5MDMgMjAwNy0wMS0wOSAw MDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9kYi9yZWNuby9yZWNf dXRpbHMuYyAxODkzODcgMjAwOS0wMy0wNSAwMDo1NzowMVogZGVscGhpaiAkCiAgICAgJEZyZWVC U0Q6IGhlYWQvbGliL2xpYmMvZGIvcmVjbm8vcmVjX3NlYXJjaC5jIDE4OTMyNyAyMDA5LTAzLTA0 IDAwOjU4OjA0WiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9y Z2V0LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvc3RkaW8vcmVmaWxsLmMgMTc4Mjg3IDIwMDgtMDQtMTcgMjI6MTc6NTRaIGpo YiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZGIvaGFzaC9oYXNoX3BhZ2UuYyAxOTA1 MDAgMjAwOS0wMy0yOCAwNzo0NDowOFogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGli L2xpYmMvZGIvaGFzaC9oYXNoX2JpZ2tleS5jIDE5MDQ5NCAyMDA5LTAzLTI4IDA2OjQ3OjA1WiBk ZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9kYi9kYi9kYi5jIDE5MDQ5NyAy MDA5LTAzLTI4IDA3OjI2OjAwWiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9kYi9oYXNoL2hhc2guYyAxOTY1MjUgMjAwOS0wOC0yNCAyMzo0NDowN1ogZGVscGhpaiAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZGIvYnRyZWUvYnRfb3Blbi5jIDE5MDQ5OCAyMDA5 LTAzLTI4IDA3OjMxOjAyWiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9k Yi9idHJlZS9idF9nZXQuYyAxODkyOTEgMjAwOS0wMy0wMiAyMzo0NzoxOFogZGVscGhpaiAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZGIvYnRyZWUvYnRfY29udi5jIDE4OTI5MSAyMDA5 LTAzLTAyIDIzOjQ3OjE4WiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9k Yi9idHJlZS9idF9jbG9zZS5jIDE4OTI5MSAyMDA5LTAzLTAyIDIzOjQ3OjE4WiBkZWxwaGlqICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9zdHJpbmcvbWVtY21wLlMgMTg0NTQ3 IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGli Yy9zdGRpby9zbnByaW50Zi5jIDIwNTAyMSAyMDEwLTAzLTExIDE3OjAzOjMyWiBqaGIgJAogICAg ICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGlvL21rdGVtcC5jIDIwNDQ0NyAyMDEwLTAyLTI4 IDEzOjMxOjI5WiBqaCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL2FyYzRyYW5k b20uYyAxODI4ODYgMjAwOC0wOS0wOSAwOTo0NjozNlogYWNoZSAkCiAgICAgJEZyZWVCU0Q6IGhl YWQvbGliL2xpYmMvZGIvaGFzaC9oYXNoX2xvZzIuYyAxOTA0ODQgMjAwOS0wMy0yOCAwNTo0NToy OVogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZGIvaGFzaC9oYXNoX2Z1 bmMuYyAxOTA0OTggMjAwOS0wMy0yOCAwNzozMTowMlogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvZGIvaGFzaC9oYXNoX2J1Zi5jIDE5MDQ5MyAyMDA5LTAzLTI4IDA2OjQw OjQ4WiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9kYi9idHJlZS9idF9w dXQuYyAxOTA0ODQgMjAwOS0wMy0yOCAwNTo0NToyOVogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6 IGhlYWQvbGliL2xpYmMvZGIvYnRyZWUvYnRfZGVsZXRlLmMgMTg5MzI3IDIwMDktMDMtMDQgMDA6 NTg6MDRaIGRlbHBoaWogJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2RiL2J0cmVlL2J0 X3NwbGl0LmMgMTk0ODA0IDIwMDktMDYtMjQgMDE6MTU6MTBaIGRlbHBoaWogJAogICAgICRGcmVl QlNEOiBoZWFkL2xpYi9saWJjL2RiL2J0cmVlL2J0X3NlcS5jIDE4OTMyNyAyMDA5LTAzLTA0IDAw OjU4OjA0WiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9kYi9idHJlZS9i dF9zZWFyY2guYyAxODkyOTIgMjAwOS0wMy0wMyAwMjoxNjoxMlogZGVscGhpaiAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvZGIvYnRyZWUvYnRfdXRpbHMuYyAxODkzODcgMjAwOS0wMy0w NSAwMDo1NzowMVogZGVscGhpaiAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZGIvYnRy ZWUvYnRfb3ZlcmZsb3cuYyAxODkzODcgMjAwOS0wMy0wNSAwMDo1NzowMVogZGVscGhpaiAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZGIvYnRyZWUvYnRfcGFnZS5jIDE5MDQ5OCAyMDA5 LTAzLTI4IDA3OjMxOjAyWiBkZWxwaGlqICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9k Yi9tcG9vbC9tcG9vbC5jIDE5NDgwNCAyMDA5LTA2LTI0IDAxOjE1OjEwWiBkZWxwaGlqICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zeXMvcHdyaXRlLmMgMTcxMjE5IDIwMDctMDctMDQg MjM6Mjc6MzhaIHBldGVyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zeXMvcHJlYWQu YyAxNzEyMTkgMjAwNy0wNy0wNCAyMzoyNzozOFogcGV0ZXIgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL3N0ZGlvL2ZwcmludGYuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1w ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby92ZnByaW50Zi5jIDIwNTAyMSAy MDEwLTAzLTExIDE3OjAzOjMyWiBqaGIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0 ZGlvL3ByaW50Zi1wb3MuYyAxODkyNjggMjAwOS0wMy0wMiAwNDowNzo1OFogZGFzICQKICAgICAk RnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9mdndyaXRlLmMgMTk5NzgxIDIwMDktMTEtMjUg MDQ6MjE6NDJaIHdvbGxtYW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS93 Y3NydG9tYnMuYyAxMzI0OTcgMjAwNC0wNy0yMSAxMDo1NDo1N1ogdGpyICQKICAgICAkRnJlZUJT RDogaGVhZC9saWIvbGliYy9sb2NhbGUvd2NydG9tYi5jIDEyOTE1MyAyMDA0LTA1LTEyIDE0OjA5 OjA0WiB0anIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2xvY2FsZS9ub25lLmMgMTcy NjE5IDIwMDctMTAtMTMgMTY6Mjg6MjJaIGFjaGUgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9s aWJjL3N0cmluZy9zdHJubGVuLmMgMTg5MTM2IDIwMDktMDItMjggMDY6MDA6NThaIGRhcyAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL21lbWNoci5jIDE4ODI5NSAyMDA5LTAy LTA3IDE5OjM0OjQ0WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0ZGxpYi9n ZXRlbnYuYyAyMDAxOTggMjAwOS0xMi0wNyAwMDoyMjoxMFogc2NmICQKICAgICAkRnJlZUJTRDog aGVhZC9saWIvbGliYy9nZHRvYS9fbGR0b2EuYyAxNzQ0ODggMjAwNy0xMi0wOSAxOTo0ODo1N1og ZGFzICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZHRvYS9faGxkdG9hLmMgMTc4MTU0 IDIwMDgtMDQtMTIgMTQ6NTM6NTJaIGRhcyAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv Z2R0b2EvX2hkdG9hLmMgMTc4MTU0IDIwMDgtMDQtMTIgMTQ6NTM6NTJaIGRhcyAkCiAgICAgJEZy ZWVCU0Q6IGhlYWQvbGliL2xpYmMvYW1kNjQvc3RyaW5nL3N0cmNweS5TIDE4NDU0NyAyMDA4LTEx LTAyIDAxOjEwOjU0WiBwZXRlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvYW1kNjQv c3RyaW5nL2Jjb3B5LlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAgICAk RnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby93c2V0dXAuYyAxODY4ODcgMjAwOS0wMS0wOCAw NjozODowNlogZGFzICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9tYWtlYnVm LmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQv bGliL2xpYmMvc3RkaW8vZmluZGZwLmMgMjA1MDIxIDIwMTAtMDMtMTEgMTc6MDM6MzJaIGpoYiAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8vZmZsdXNoLmMgMTY1OTAzIDIwMDct MDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RkaW8v X2Zsb2NrX3N0dWIuYyAxNzgyODcgMjAwOC0wNC0xNyAyMjoxNzo1NFogamhiICQKICAgICAkRnJl ZUJTRDogaGVhZC9saWIvbGliYy9sb2NhbGUvdGFibGUuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoy ODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9nZW4vZmx0X3Jv dW5kcy5jIDEzMjM4MyAyMDA0LTA3LTE5IDA4OjE3OjI1WiBkYXMgJAogICAgICRGcmVlQlNEOiBo ZWFkL2xpYi9saWJjL2dlbi9pc2F0dHkuYyAxNjU5MDMgMjAwNy0wMS0wOSAwMDoyODoxNlogaW1w ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vZ2V0cHJvZ25hbWUuYyA5MzM5OSAy MDAyLTAzLTI5IDIyOjQzOjQzWiBtYXJrbSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv Z2VuL19zcGlubG9ja19zdHViLmMgMTY1OTY4IDIwMDctMDEtMTIgMDc6MzE6MzBaIGltcCAkCiAg ICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvc3RyaW5nL3N0cm5jbXAuYyAxODgwODAgMjAwOS0w Mi0wMyAxNzo1ODoyMFogZGFuZ2VyICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdHJp bmcvc3RybGVuLmMgMjA1MTA4IDIwMTAtMDMtMTMgMDA6MTU6MDZaIGRlbHBoaWogJAogICAgICRG cmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy9zdHJjaHIuYyA5Mjk4NiAyMDAyLTAzLTIyIDIx OjUzOjI5WiBvYnJpZW4gJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL3N0cmluZy9pbmRl eC5jIDE2NTkwMyAyMDA3LTAxLTA5IDAwOjI4OjE2WiBpbXAgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL3N0cmluZy9zdHBjcHkuYyAxODkxMzcgMjAwOS0wMi0yOCAwNjowNTozN1ogZGFz ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRsaWIvYWJvcnQuYyAxNjU5MDMgMjAw Ny0wMS0wOSAwMDoyODoxNlogaW1wICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2 NC9zdHJpbmcvbWVtc2V0LlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAg ICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zdGRpby9zdGRpby5jIDE3ODc4MiAyMDA4LTA1LTA1 IDE2OjE0OjAyWiBqaGIgJAogICAgICRGcmVlQlNEOiBoZWFkL2xpYi9saWJjL2dlbi90ZXJtaW9z LmMgMjAwMTM0IDIwMDktMTItMDUgMTg6NTM6MDRaIGVkICQKICAgICAkRnJlZUJTRDogaGVhZC9s aWIvbGliYy9nZW4vc2lnc2V0b3BzLmMgMTY1OTAzIDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAk CiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvZ2VuL3JhaXNlLmMgMjAwMTUwIDIwMDktMTIt MDUgMTk6MzE6MzhaIGVkICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9zeXMvbHNlZWsu YyAxNzEyMTkgMjAwNy0wNy0wNCAyMzoyNzozOFogcGV0ZXIgJAogICAgICRGcmVlQlNEOiBoZWFk L2xpYi9saWJjL2dlbi9fX2dldG9zcmVsZGF0ZS5jIDE3MTIxOSAyMDA3LTA3LTA0IDIzOjI3OjM4 WiBwZXRlciAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMvYW1kNjQvc3RyaW5nL2Jjb3B5 LlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVyICQKICAgICAkRnJlZUJTRDogaGVh ZC9saWIvbGliYy9nZW4vc3lzY3RsLmMgMjA0MTcwIDIwMTAtMDItMjEgMTM6NTc6MDJaIGVkICQK ICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9nZW4vX3B0aHJlYWRfc3R1YnMuYyAyMDE1NDYg MjAxMC0wMS0wNSAwMjozNzo1OVogZGF2aWR4dSAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xp YmMvYW1kNjQvc3RyaW5nL2Jjb3B5LlMgMTg0NTQ3IDIwMDgtMTEtMDIgMDE6MTA6NTRaIHBldGVy ICQKICAgICAkRnJlZUJTRDogaGVhZC9saWIvbGliYy9hbWQ2NC9zeXMvY2Vycm9yLlMgMTY1OTAz IDIwMDctMDEtMDkgMDA6Mjg6MTZaIGltcCAkCiAgICAgJEZyZWVCU0Q6IGhlYWQvbGliL2xpYmMv c3lzL19fZXJyb3IuYyAyMDAxNTAgMjAwOS0xMi0wNSAxOTozMTozOFogZWQgJAogICAgICRJZDog cmVzX3VwZGF0ZS5jLHYgMS4xMi4xOC4xIDIwMDUvMDQvMjcgMDU6MDE6MTIgc3JhIEV4cCAkCiAg ICAgJElkOiByZXNfZmluZHpvbmVjdXQuYyx2IDEuNy4xOC4zIDIwMDUvMTAvMTEgMDA6MjU6MTEg bWFya2EgRXhwICQKICAgICAkSWQ6IGV2X3RpbWVycy5jLHYgMS41LjE4LjEgMjAwNS8wNC8yNyAw NTowMTowNiBzcmEgRXhwICQKICAgICAkSWQ6IGV2X3N0cmVhbXMuYyx2IDEuNC4xOC4xIDIwMDUv MDQvMjcgMDU6MDE6MDYgc3JhIEV4cCAkCiAgICAgJElkOiByZXNfbWt1cGRhdGUuYyx2IDEuNC4x OC40IDIwMDUvMTAvMTQgMDU6NDQ6MTIgbWFya2EgRXhwICQKICAgICAkSWQ6IG5zX3ByaW50LmMs diAxLjYuMTguNCAyMDA1LzA0LzI3IDA1OjAxOjA5IHNyYSBFeHAgJAogICAgICRJZDogbnNfcGFy c2UuYyx2IDEuNS4xOC40IDIwMDcvMDgvMjcgMDM6MzQ6MjQgbWFya2EgRXhwICQKICAgICAkSWQ6 IG5zX3R0bC5jLHYgMS4yLjE4LjIgMjAwNS8wNy8yOCAwNzozODoxMCBtYXJrYSBFeHAgJAogICAg ICRJZDogbnNfc2FtZWRvbWFpbi5jLHYgMS41LjE4LjEgMjAwNS8wNC8yNyAwNTowMTowOSBzcmEg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL3Vzci5iaW4veWFjYy9za2VsZXRvbi5jLHYgMS40MCAy MDA5LzEyLzMwIDIyOjQ2OjA4IGVkIEV4cCAkCiAgICAgJElkOiBuc19uZXRpbnQuYyx2IDEuMi4x OC4xIDIwMDUvMDQvMjcgMDU6MDE6MDggc3JhIEV4cCAkCiAgICAgJElkOiBuc19uYW1lLmMsdiAx LjguMTguMiAyMDA1LzA0LzI3IDA1OjAxOjA4IHNyYSBFeHAgJAo= --+permail-20100321123559f7e55a9d00007007-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 12:43:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAD301065672 for ; Sun, 21 Mar 2010 12:43:55 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay1.uni-muenster.de (ZIVM-RELAY1.UNI-MUENSTER.DE [128.176.192.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB978FC1F for ; Sun, 21 Mar 2010 12:43:55 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,282,1267398000"; d="scan'208";a="299722681" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 21 Mar 2010 13:43:53 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 722641B07E7; Sun, 21 Mar 2010 13:43:53 +0100 (CET) Date: Sun, 21 Mar 2010 13:43:52 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Pegasus Mc Cleaft , Message-ID: In-Reply-To: <201003211232.35497.ken@mthelicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Garrett Cooper Subject: Re: build failures after stdlib update 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, 21 Mar 2010 12:43:55 -0000 Pegasus Mc Cleaft schrieb am 2010-03-21: > > > it would be nice if people with arch i386 and amd64 could try to > > > reproduce this (i believe the other archs don't support > > > CPUTYPE=native). > > > again the easiest way to trigger this (you don't need to edit > > > your > > > /etc/make.conf for this) should be running: > > > gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > I didnt think you could add CPUTYPE=native to the > /etc/make.conf > What I used to do when I was compiling native was to do > something like > the following in the /etc/make.conf no you can. /usr/share/mk/bsd.cpu.mk doesn't perform any 'native' checks so when you set 'CPUTYPE=native' -mtune gets set to native. so you can just do: CPUTYPE=native CFLAGS=-O2 -fno-strict-aliasing -pipe -s btw: what's the -s switch doing? alex > CPUTYPE?=core2 > NO_CPU_CFLAGS= > CFLAGS= -mtune=native -O2 -fno-strict-aliasing -pipe -s > Peg -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 12:51: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 96A69106566B for ; Sun, 21 Mar 2010 12:51:06 +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 DAAF08FC26 for ; Sun, 21 Mar 2010 12:51:05 +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 OAA28872; Sun, 21 Mar 2010 14:51:01 +0200 (EET) (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 1NtKcP-000AYB-Cq; Sun, 21 Mar 2010 14:51:01 +0200 Message-ID: <4BA61634.8090006@icyb.net.ua> Date: Sun, 21 Mar 2010 14:51:00 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 12:51:06 -0000 on 21/03/2010 14:35 Alexander Best said the following: > Andriy Gapon schrieb am 2010-03-21: >> on 21/03/2010 13:43 Garrett Cooper said the following: > >>> Works for me *shrugs*: > >>> $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 >>> Using built-in specs. >>> Target: amd64-undermydesk-freebsd >>> Configured with: FreeBSD/amd64 system compiler >>> Thread model: posix >>> gcc version 4.2.1 20070719 [FreeBSD] >>> /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null >>> -mtune=generic >>> ignoring duplicate directory "/usr/include" >>> #include "..." search starts here: >>> #include <...> search starts here: >>> /usr/include >>> End of search list. >>> $ echo $? >>> 0 > >> Do you also have the latest version of libc _installed_ in the >> system? > > i think so. i grabbed a fresh src copy yesterday and did > buildworld/installworld a few ours ago. > > i've attached the output of `ident /lib/libc.so.7`. The question was for Garrett :) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 12:53: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 AF4851065670 for ; Sun, 21 Mar 2010 12:53:59 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id 40A908FC1D for ; Sun, 21 Mar 2010 12:53:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,282,1267398000"; d="scan'208";a="28955551" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 21 Mar 2010 13:53:58 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 0ACD61B07E7; Sun, 21 Mar 2010 13:53:58 +0100 (CET) Date: Sun, 21 Mar 2010 13:53:57 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Andriy Gapon Message-ID: In-Reply-To: <4BA61634.8090006@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 12:53:59 -0000 Andriy Gapon schrieb am 2010-03-21: > on 21/03/2010 14:35 Alexander Best said the following: > > Andriy Gapon schrieb am 2010-03-21: > >> on 21/03/2010 13:43 Garrett Cooper said the following: > >>> Works for me *shrugs*: > >>> $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > >>> Using built-in specs. > >>> Target: amd64-undermydesk-freebsd > >>> Configured with: FreeBSD/amd64 system compiler > >>> Thread model: posix > >>> gcc version 4.2.1 20070719 [FreeBSD] > >>> /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null > >>> -mtune=generic > >>> ignoring duplicate directory "/usr/include" > >>> #include "..." search starts here: > >>> #include <...> search starts here: > >>> /usr/include > >>> End of search list. > >>> $ echo $? > >>> 0 > >> Do you also have the latest version of libc _installed_ in the > >> system? > > i think so. i grabbed a fresh src copy yesterday and did > > buildworld/installworld a few ours ago. > > i've attached the output of `ident /lib/libc.so.7`. > The question was for Garrett :) *lol* sorry. ;) -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 13:03: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 D09E5106564A for ; Sun, 21 Mar 2010 13:03:08 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 65A488FC0A for ; Sun, 21 Mar 2010 13:03:08 +0000 (UTC) Received: from [195.4.92.18] (helo=8.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1NtKo6-0000Fw-Pn; Sun, 21 Mar 2010 14:03:06 +0100 Received: from p57ae1520.dip0.t-ipconnect.de ([87.174.21.32]:37806 helo=ernst.jennejohn.org) by 8.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1NtKo6-0003UH-Gx; Sun, 21 Mar 2010 14:03:06 +0100 Date: Sun, 21 Mar 2010 14:03:04 +0100 From: Gary Jennejohn To: Alexander Best Message-ID: <20100321140304.37618e59@ernst.jennejohn.org> In-Reply-To: References: <201003211232.35497.ken@mthelicon.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Pegasus Mc Cleaft , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 13:03:08 -0000 On Sun, 21 Mar 2010 13:43:52 +0100 (CET) Alexander Best wrote: > Pegasus Mc Cleaft schrieb am 2010-03-21: > > > > it would be nice if people with arch i386 and amd64 could try to > > > > reproduce this (i believe the other archs don't support > > > > CPUTYPE=native). > > > > again the easiest way to trigger this (you don't need to edit > > > > your > > > > /etc/make.conf for this) should be running: > > > > > gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > > > > I didnt think you could add CPUTYPE=native to the > > /etc/make.conf > > > What I used to do when I was compiling native was to do > > something like > > the following in the /etc/make.conf > > no you can. /usr/share/mk/bsd.cpu.mk doesn't perform any 'native' checks so > when you set 'CPUTYPE=native' -mtune gets set to native. > > so you can just do: > > CPUTYPE=native > CFLAGS=-O2 -fno-strict-aliasing -pipe -s > > btw: what's the -s switch doing? > It "silences" make. See the man page. It's useful because basically only errors are emitted. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 13:08: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 B5D89106566C for ; Sun, 21 Mar 2010 13:08:07 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 4B3C28FC1C for ; Sun, 21 Mar 2010 13:08:07 +0000 (UTC) Received: from [195.4.92.22] (helo=12.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1NtKsv-0002x0-O7; Sun, 21 Mar 2010 14:08:05 +0100 Received: from p57ae1520.dip0.t-ipconnect.de ([87.174.21.32]:37960 helo=ernst.jennejohn.org) by 12.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1NtKsv-0003HK-HY; Sun, 21 Mar 2010 14:08:05 +0100 Date: Sun, 21 Mar 2010 14:08:04 +0100 From: Gary Jennejohn To: Alexander Best Message-ID: <20100321140804.48cd1876@ernst.jennejohn.org> In-Reply-To: <20100321140304.37618e59@ernst.jennejohn.org> References: <201003211232.35497.ken@mthelicon.com> <20100321140304.37618e59@ernst.jennejohn.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Pegasus Mc Cleaft , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 13:08:07 -0000 On Sun, 21 Mar 2010 14:03:04 +0100 Gary Jennejohn wrote: > On Sun, 21 Mar 2010 13:43:52 +0100 (CET) > Alexander Best wrote: > > > Pegasus Mc Cleaft schrieb am 2010-03-21: > > > > > it would be nice if people with arch i386 and amd64 could try to > > > > > reproduce this (i believe the other archs don't support > > > > > CPUTYPE=native). > > > > > again the easiest way to trigger this (you don't need to edit > > > > > your > > > > > /etc/make.conf for this) should be running: > > > > > > > gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > > > > > > > I didnt think you could add CPUTYPE=native to the > > > /etc/make.conf > > > > > What I used to do when I was compiling native was to do > > > something like > > > the following in the /etc/make.conf > > > > no you can. /usr/share/mk/bsd.cpu.mk doesn't perform any 'native' checks so > > when you set 'CPUTYPE=native' -mtune gets set to native. > > > > so you can just do: > > > > CPUTYPE=native > > CFLAGS=-O2 -fno-strict-aliasing -pipe -s > > > > btw: what's the -s switch doing? > > > > It "silences" make. See the man page. It's useful because basically only > errors are emitted. > Oops. That's wrong. I got confused. I'd like to know that myself, now that I'm no longer confused :) -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 14:04: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 405D11065673; Sun, 21 Mar 2010 14:04:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 8E77E8FC15; Sun, 21 Mar 2010 14:04:12 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so157839fga.13 for ; Sun, 21 Mar 2010 07:04:11 -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=PrrFva0kbQYNEA6MUrI01eUuqXd4VQBIKirXR/fKBj4=; b=d3VbPi3SyUt/Q7szCjvpA+EBTqdOpWJtRKCj0TxnUfoUgX53r4MSnEweoStSnvXRAJ 05iTulqA0CyEWNaq2qvhdLUMJkrPd2rrK//TAL/4qfel0zlPhre05ILXoez4TXbJKp+Q l3hFfc9kCgOgBRpjAnyAjjwgwveSeK74Xa2v4= 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=njKgfKaDyDThztxFPemi0xSFgbR2fLi5MWzlnEsckerPTzlYj6CgrPBMc91NvcPdU2 wrzL01tQLdlBj9hnNP7+2DoYhMELKQpo3UZWyFc9KAVjLSPjHRKtHugOyPVuVLZZl9QW MjzjPhXVU7wPII9xEnvg2n3IcgtOXuJCVrdak= Received: by 10.87.62.1 with SMTP id p1mr4192349fgk.42.1269180251307; Sun, 21 Mar 2010 07:04:11 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm920679fxm.0.2010.03.21.07.04.10 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 07:04:10 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BA62757.7090400@FreeBSD.org> Date: Sun, 21 Mar 2010 16:04:07 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Julian Elischer References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <4BA532FF.6040407@elischer.org> In-Reply-To: <4BA532FF.6040407@elischer.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 14:04:13 -0000 Julian Elischer wrote: > In the Fusion-io driver we find that the limiting factor is not the > size of MAXPHYS, but the fact that we can not push more than > 170k tps through geom. (in my test machine. I've seen more on some > beefier machines), but that is only a limit on small transacrtions, > or in the case of large transfers the DMA engine tops out before a > bigger MAXPHYS would make any difference. Yes, GEOM is quite CPU-hungry on high request rates due to number of context switches. But impact probably may be reduced from two sides: by reducing overhead per request, or by reducing number of requests. Both ways may give benefits. If common opinion is not to touch defaults now - OK, agreed. (Note, Scott, I have agreed :)) But returning to the original question, does somebody knows real situation when increased MAXPHYS still causes problems? At least to make it safe. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 14:05:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B060E1065679; Sun, 21 Mar 2010 14:05:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id DEE0B8FC24; Sun, 21 Mar 2010 14:05:22 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so158042fga.13 for ; Sun, 21 Mar 2010 07:05:21 -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 :content-type:content-transfer-encoding; bh=BRJ41r/r91Fq55DvNWe6LznhUMxpmLSNAg11fbo4tys=; b=c7H3BUIot8BPnUVeIqVVf7kEIL8dDdTg2RDfY4J93sKY8LqtXpFWKmHOHvrFltqe3U pZLwFk8Hdtqo9lbFzkQBFzLHqkBYpoRZce88Iu0h29lTwWn4FcRpiqEAeWjNRmW8LhDc x35+Fcfg7G6l3fiWo5i8TfxJWGp8gddNpZD0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ofxrZSgSLrIcBX/hC8/q0gtZtPNeYhHv/QdrtnOOAtiJ599BsnD2ZTQcWI+MT+f3b/ saHVVWMwQfiScHRaHYzoce6uMewIxujxrRjnUo8ULVF3njrT2APHUYPGVTnepz9BSHom LCN97/uW2jCcRpmoU18mkJHArX0H4KBzLH7RQ= Received: by 10.87.2.15 with SMTP id e15mr1915544fgi.22.1269180321552; Sun, 21 Mar 2010 07:05:21 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm921439fxm.0.2010.03.21.07.05.20 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 07:05:20 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BA6279E.3010201@FreeBSD.org> Date: Sun, 21 Mar 2010 16:05:18 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Ivan Voras References: <1269109391.00231800.1269099002@10.7.7.3> <1269120182.00231865.1269108002@10.7.7.3> <1269120188.00231888.1269109203@10.7.7.3> <1269123795.00231922.1269113402@10.7.7.3> <1269130981.00231933.1269118202@10.7.7.3> <1269130986.00231939.1269119402@10.7.7.3> <1269134581.00231948.1269121202@10.7.7.3> <1269134585.00231959.1269122405@10.7.7.3> In-Reply-To: <1269134585.00231959.1269122405@10.7.7.3> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 14:05:23 -0000 Ivan Voras wrote: > Julian Elischer wrote: >> You can get better throughput by using TSC for timing because the geom >> and devstat code does a bit of timing.. Geom can be told to turn off >> it's timing but devstat can't. The 170 ktps is with TSC as timer, >> and geom timing turned off. > > I see. I just ran randomio on a gzero device and with 10 userland > threads (this is a slow 2xquad machine) I get g_up and g_down saturated > fast with ~~ 120 ktps. Randomio uses gettimeofday() for measurements. I've just got 140Ktps from two real Intel X25-M SSDs on ICH10R AHCI controller and single Core2Quad CPU. So at least on synthetic tests it is potentially reachable even with casual hardware, while it completely saturated quad-core CPU. > Hmm, it looks like it could be easy to spawn more g_* threads (and, > barring specific class behaviour, it has a fair chance of working out of > the box) but the incoming queue will need to also be broken up for > greater effect. According to "notes", looks there is a good chance to obtain races, as some places expect only one up and one down thread. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 14:56: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 A90AB106566B; Sun, 21 Mar 2010 14:56:36 +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 464E08FC27; Sun, 21 Mar 2010 14:56:34 +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 QAA00267; Sun, 21 Mar 2010 16:56:33 +0200 (EET) (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 1NtMZt-000AgC-3A; Sun, 21 Mar 2010 16:56:33 +0200 Message-ID: <4BA633A0.2090108@icyb.net.ua> Date: Sun, 21 Mar 2010 16:56:32 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Alexander Motin References: <1269109391.00231800.1269099002@10.7.7.3> <1269120182.00231865.1269108002@10.7.7.3> <1269120188.00231888.1269109203@10.7.7.3> <1269123795.00231922.1269113402@10.7.7.3> <1269130981.00231933.1269118202@10.7.7.3> <1269130986.00231939.1269119402@10.7.7.3> <1269134581.00231948.1269121202@10.7.7.3> <1269134585.00231959.1269122405@10.7.7.3> <4BA6279E.3010201@FreeBSD.org> In-Reply-To: <4BA6279E.3010201@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Ivan Voras , freebsd-arch@FreeBSD.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 14:56:36 -0000 on 21/03/2010 16:05 Alexander Motin said the following: > Ivan Voras wrote: >> Hmm, it looks like it could be easy to spawn more g_* threads (and, >> barring specific class behaviour, it has a fair chance of working out of >> the box) but the incoming queue will need to also be broken up for >> greater effect. > > According to "notes", looks there is a good chance to obtain races, as > some places expect only one up and one down thread. I haven't given any deep thought to this issue, but I remember us discussing them over beer :-) I think one idea was making sure (somehow) that requests traveling over the same edge of a geom graph (in the same direction) do it using the same queue/thread. Another idea was to bring some netgraph-like optimization where some (carefully chosen) geom vertices pass requests by a direct call instead of requeuing. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 15:10:35 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 AA7751065672 for ; Sun, 21 Mar 2010 15:10:35 +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 D273D8FC13 for ; Sun, 21 Mar 2010 15:10:34 +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 RAA00406; Sun, 21 Mar 2010 17:10:31 +0200 (EET) (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 1NtMnO-000AhJ-MP; Sun, 21 Mar 2010 17:10:30 +0200 Message-ID: <4BA636E6.5000604@icyb.net.ua> Date: Sun, 21 Mar 2010 17:10:30 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 15:10:35 -0000 on 21/03/2010 14:53 Alexander Best said the following: > *lol* sorry. ;) No worries. BTW, when that rash happens, are you able to examine the core with gdb? Is it possible to examine values of 's' and 'p' in strlen? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 15:24:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9F26106566B; Sun, 21 Mar 2010 15:24:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C3DFC8FC18; Sun, 21 Mar 2010 15:24:49 +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 o2LFOmvj095196; Sun, 21 Mar 2010 11:24:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2LFOmZP095195; Sun, 21 Mar 2010 15:24:48 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 21 Mar 2010 15:24:48 GMT Message-Id: <201003211524.o2LFOmZP095195@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 15:24:50 -0000 TB --- 2010-03-21 13:35:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-21 13:35:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-03-21 13:35:00 - cleaning the object tree TB --- 2010-03-21 13:35:25 - cvsupping the source tree TB --- 2010-03-21 13:35:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-03-21 13:35:49 - building world TB --- 2010-03-21 13:35:49 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-21 13:35:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-21 13:35:49 - TARGET=i386 TB --- 2010-03-21 13:35:49 - TARGET_ARCH=i386 TB --- 2010-03-21 13:35:49 - TZ=UTC TB --- 2010-03-21 13:35:49 - __MAKE_CONF=/dev/null TB --- 2010-03-21 13:35:49 - cd /src TB --- 2010-03-21 13:35:49 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 21 13:35:50 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Mar 21 14:35:19 UTC 2010 TB --- 2010-03-21 14:35:19 - generating LINT kernel config TB --- 2010-03-21 14:35:19 - cd /src/sys/i386/conf TB --- 2010-03-21 14:35:19 - /usr/bin/make -B LINT TB --- 2010-03-21 14:35:19 - building LINT kernel TB --- 2010-03-21 14:35:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-21 14:35:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-21 14:35:19 - TARGET=i386 TB --- 2010-03-21 14:35:19 - TARGET_ARCH=i386 TB --- 2010-03-21 14:35:19 - TZ=UTC TB --- 2010-03-21 14:35:19 - __MAKE_CONF=/dev/null TB --- 2010-03-21 14:35:19 - cd /src TB --- 2010-03-21 14:35:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 21 14:35:19 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Mar 21 15:00:21 UTC 2010 TB --- 2010-03-21 15:00:21 - building GENERIC kernel TB --- 2010-03-21 15:00:21 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-21 15:00:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-21 15:00:21 - TARGET=i386 TB --- 2010-03-21 15:00:21 - TARGET_ARCH=i386 TB --- 2010-03-21 15:00:21 - TZ=UTC TB --- 2010-03-21 15:00:21 - __MAKE_CONF=/dev/null TB --- 2010-03-21 15:00:21 - cd /src TB --- 2010-03-21 15:00:21 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Mar 21 15:00:21 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Mar 21 15:20:03 UTC 2010 TB --- 2010-03-21 15:20:03 - building PAE kernel TB --- 2010-03-21 15:20:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-21 15:20:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-21 15:20:03 - TARGET=i386 TB --- 2010-03-21 15:20:03 - TARGET_ARCH=i386 TB --- 2010-03-21 15:20:03 - TZ=UTC TB --- 2010-03-21 15:20:03 - __MAKE_CONF=/dev/null TB --- 2010-03-21 15:20:03 - cd /src TB --- 2010-03-21 15:20:03 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sun Mar 21 15:20:03 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/qdivrem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/compat/x86bios/x86bios.c cc1: warnings being treated as errors /src/sys/compat/x86bios/x86bios.c: In function 'x86bios_map_mem': /src/sys/compat/x86bios/x86bios.c:558: warning: cast to pointer from integer of different size *** Error code 1 Stop in /obj/i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-21 15:24:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-21 15:24:48 - ERROR: failed to build PAE kernel TB --- 2010-03-21 15:24:48 - 5074.94 user 911.83 system 6588.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 15:35: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 DFF54106564A for ; Sun, 21 Mar 2010 15:35:43 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id A0FEE8FC0C for ; Sun, 21 Mar 2010 15:35:43 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:a9ce:5ce1:c6f8:9a4c] (unknown [IPv6:2001:7b8:3a7:0:a9ce:5ce1:c6f8:9a4c]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E6A685C59; Sun, 21 Mar 2010 16:35:10 +0100 (CET) Message-ID: <4BA63CB1.3000201@andric.com> Date: Sun, 21 Mar 2010 16:35:13 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.2pre) Gecko/20100311 Lanikai/3.1b2pre MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <201003211232.35497.ken@mthelicon.com> <20100321140304.37618e59@ernst.jennejohn.org> <20100321140804.48cd1876@ernst.jennejohn.org> In-Reply-To: <20100321140804.48cd1876@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Best , Pegasus Mc Cleaft , freebsd-current@freebsd.org, Garrett Cooper Subject: Re: build failures after stdlib update 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, 21 Mar 2010 15:35:44 -0000 On 2010-03-21 14:08, Gary Jennejohn wrote: >>> CPUTYPE=native >>> CFLAGS=-O2 -fno-strict-aliasing -pipe -s >>> >>> btw: what's the -s switch doing? >> >> It "silences" make. See the man page. It's useful because basically only >> errors are emitted. > > Oops. That's wrong. I got confused. I'd like to know that myself, now > that I'm no longer confused :) From gcc(1): -s Remove all symbol table and relocation information from the exe- cutable. This is more or less the same as running strip(1) over the produced executables. Usually one uses it for non-debug builds. From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 15:46: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 26798106566B; Sun, 21 Mar 2010 15:46:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-5.mx.aerioconnect.net [216.240.47.65]) by mx1.freebsd.org (Postfix) with ESMTP id ABC138FC24; Sun, 21 Mar 2010 15:46:56 +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 o2LFktDv015391; Sun, 21 Mar 2010 08:46:55 -0700 X-Client-Authorized: MaGic Cook1e 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 63C4B2D601C; Sun, 21 Mar 2010 08:46:55 -0700 (PDT) Message-ID: <4BA63F72.5000806@elischer.org> Date: Sun, 21 Mar 2010 08:46:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alexander Motin References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <4BA532FF.6040407@elischer.org> <4BA62757.7090400@FreeBSD.org> In-Reply-To: <4BA62757.7090400@FreeBSD.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: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 15:46:57 -0000 Alexander Motin wrote: > Julian Elischer wrote: >> In the Fusion-io driver we find that the limiting factor is not the >> size of MAXPHYS, but the fact that we can not push more than >> 170k tps through geom. (in my test machine. I've seen more on some >> beefier machines), but that is only a limit on small transacrtions, >> or in the case of large transfers the DMA engine tops out before a >> bigger MAXPHYS would make any difference. > > Yes, GEOM is quite CPU-hungry on high request rates due to number of > context switches. But impact probably may be reduced from two sides: by > reducing overhead per request, or by reducing number of requests. Both > ways may give benefits. > > If common opinion is not to touch defaults now - OK, agreed. (Note, > Scott, I have agreed :)) But returning to the original question, does > somebody knows real situation when increased MAXPHYS still causes > problems? At least to make it safe. well I know we havn't tested our bsd driver yet with MAXPHYS > 128KB at this time.. Must try that some time :-) From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 15:51:23 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2363B106566B; Sun, 21 Mar 2010 15:51:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-5.mx.aerioconnect.net [216.240.47.65]) by mx1.freebsd.org (Postfix) with ESMTP id E698B8FC21; Sun, 21 Mar 2010 15:51:22 +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 o2LFpLad015549; Sun, 21 Mar 2010 08:51:22 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e 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 748D62D6013; Sun, 21 Mar 2010 08:51:21 -0700 (PDT) Message-ID: <4BA6407C.3020103@elischer.org> Date: Sun, 21 Mar 2010 08:51:24 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Andriy Gapon References: <1269109391.00231800.1269099002@10.7.7.3> <1269120182.00231865.1269108002@10.7.7.3> <1269120188.00231888.1269109203@10.7.7.3> <1269123795.00231922.1269113402@10.7.7.3> <1269130981.00231933.1269118202@10.7.7.3> <1269130986.00231939.1269119402@10.7.7.3> <1269134581.00231948.1269121202@10.7.7.3> <1269134585.00231959.1269122405@10.7.7.3> <4BA6279E.3010201@FreeBSD.org> <4BA633A0.2090108@icyb.net.ua> In-Reply-To: <4BA633A0.2090108@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Alexander Motin , freebsd-current@FreeBSD.org, Ivan Voras , freebsd-arch@FreeBSD.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 15:51:23 -0000 Andriy Gapon wrote: > on 21/03/2010 16:05 Alexander Motin said the following: >> Ivan Voras wrote: >>> Hmm, it looks like it could be easy to spawn more g_* threads (and, >>> barring specific class behaviour, it has a fair chance of working out of >>> the box) but the incoming queue will need to also be broken up for >>> greater effect. >> According to "notes", looks there is a good chance to obtain races, as >> some places expect only one up and one down thread. > > I haven't given any deep thought to this issue, but I remember us discussing > them over beer :-) > I think one idea was making sure (somehow) that requests traveling over the same > edge of a geom graph (in the same direction) do it using the same queue/thread. > Another idea was to bring some netgraph-like optimization where some (carefully > chosen) geom vertices pass requests by a direct call instead of requeuing. > yeah, like the 1:1 single provider case. (which we an most of our custommers mostly use on our cards). i.e. no slicing or dicing, and just the raw flash card presented as /dev/fio0 From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 16:13: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 052F3106564A; Sun, 21 Mar 2010 16:13:07 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A9AA88FC21; Sun, 21 Mar 2010 16:13:04 +0000 (UTC) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o2LGD1Tn036769; Sun, 21 Mar 2010 10:13:01 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4BA6279E.3010201@FreeBSD.org> Date: Sun, 21 Mar 2010 10:13:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1269109391.00231800.1269099002@10.7.7.3> <1269120182.00231865.1269108002@10.7.7.3> <1269120188.00231888.1269109203@10.7.7.3> <1269123795.00231922.1269113402@10.7.7.3> <1269130981.00231933.1269118202@10.7.7.3> <1269130986.00231939.1269119402@10.7.7.3> <1269134581.00231948.1269121202@10.7.7.3> <1269134585.00231959.1269122405@10.7.7.3> <4BA6279E.3010201@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 16:13:07 -0000 On Mar 21, 2010, at 8:05 AM, Alexander Motin wrote: > Ivan Voras wrote: >> Julian Elischer wrote: >>> You can get better throughput by using TSC for timing because the = geom >>> and devstat code does a bit of timing.. Geom can be told to turn off >>> it's timing but devstat can't. The 170 ktps is with TSC as timer, >>> and geom timing turned off. >>=20 >> I see. I just ran randomio on a gzero device and with 10 userland >> threads (this is a slow 2xquad machine) I get g_up and g_down = saturated >> fast with ~~ 120 ktps. Randomio uses gettimeofday() for measurements. >=20 > I've just got 140Ktps from two real Intel X25-M SSDs on ICH10R AHCI > controller and single Core2Quad CPU. So at least on synthetic tests it > is potentially reachable even with casual hardware, while it = completely > saturated quad-core CPU. >=20 >> Hmm, it looks like it could be easy to spawn more g_* threads (and, >> barring specific class behaviour, it has a fair chance of working out = of >> the box) but the incoming queue will need to also be broken up for >> greater effect. >=20 > According to "notes", looks there is a good chance to obtain races, as > some places expect only one up and one down thread. >=20 I agree that more threads just creates many more race complications. = Even if it didn't, the storage driver is a serialization point; it = doesn't matter if you have a dozen g_* threads if only one of them can = be in the top half of the driver at a time. No amount of fine-grained = locking is going to help this. I'd like to go in the opposite direction. The queue-dispatch-queue = model of GEOM is elegant and easy to extend, but very wasteful for the = simple case, where the simple case is one or two simple partition = transforms (mbr, bsdlabel) and/or a simple stripe/mirror transform. = None of these need a dedicated dispatch context in order to operate. = What I'd like to explore is compiling the GEOM stack at creation time = into a linear array of operations that happen without a g_down/g_up = context switch. As providers and consumers taste each other and build a = stack, that stack gets compiled into a graph, and that graph gets = executed directly from the calling context, both from the dev_strategy() = side on the top and the bio_done() on the bottom. GEOM classes that = need a detached context can mark themselves as such, doing so will = prevent a graph from being created, and the current dispatch model will = be retained. I expect that this will reduce i/o latency by a great margin, thus = directly addressing the performance problem that FusionIO makes an = example of. I'd like to also explore having the g_bio model not require = a malloc at every stage in the stack/graph; even though going through = UMA is fairly fast, it still represents overhead that can be eliminated. = It also represents an out-of-memory failure case that can be prevented. I might try to work on this over the summer. It's really a research = project in my head at this point, but I'm hopeful that it'll show = results. Scott From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 16: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 B3F20106566B; Sun, 21 Mar 2010 16:18:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1AA8FC17; Sun, 21 Mar 2010 16:18:59 +0000 (UTC) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o2LGIu2N036802; Sun, 21 Mar 2010 10:18:56 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4BA633A0.2090108@icyb.net.ua> Date: Sun, 21 Mar 2010 10:18:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <082B2047-44AE-45DB-985B-D8928EBB4871@samsco.org> References: <1269109391.00231800.1269099002@10.7.7.3> <1269120182.00231865.1269108002@10.7.7.3> <1269120188.00231888.1269109203@10.7.7.3> <1269123795.00231922.1269113402@10.7.7.3> <1269130981.00231933.1269118202@10.7.7.3> <1269130986.00231939.1269119402@10.7.7.3> <1269134581.00231948.1269121202@10.7.7.3> <1269134585.00231959.1269122405@10.7.7.3> <4BA6279E.3010201@FreeBSD.org> <4BA633A0.2090108@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , freebsd-current@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 16:18:59 -0000 m On Mar 21, 2010, at 8:56 AM, Andriy Gapon wrote: > on 21/03/2010 16:05 Alexander Motin said the following: >> Ivan Voras wrote: >>> Hmm, it looks like it could be easy to spawn more g_* threads (and, >>> barring specific class behaviour, it has a fair chance of working = out of >>> the box) but the incoming queue will need to also be broken up for >>> greater effect. >>=20 >> According to "notes", looks there is a good chance to obtain races, = as >> some places expect only one up and one down thread. >=20 > I haven't given any deep thought to this issue, but I remember us = discussing > them over beer :-) > I think one idea was making sure (somehow) that requests traveling = over the same > edge of a geom graph (in the same direction) do it using the same = queue/thread. > Another idea was to bring some netgraph-like optimization where some = (carefully > chosen) geom vertices pass requests by a direct call instead of = requeuing. >=20 Ah, I see that we were thinking about similar things. Another tactic, = and one that is easier to prototype and implement than moving GEOM to a graph, is to = allow separate but related bio's to be chained. If a caller, like maybe physio or the = bufdaemon or=20 even a middle geom transform, knows that it's going to send multiple = bio's at once, it chains them together into a single request, and that request gets = pipelined through the stack. Each layer operates on the entire chain before requeueing to = the next layer. Layers/classes that can't operate this way will get the bio serialized = automatically for them, breaking the chain, but those won't be the common cases. This will = bring cache locality benefits, and is something that know benefits high-transaction load = network applications. Scott From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 16:30: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 E2041106564A; Sun, 21 Mar 2010 16:30:53 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF258FC0A; Sun, 21 Mar 2010 16:30:53 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (Postfix) with ESMTPS id E440D5C84; Sun, 21 Mar 2010 17:30:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1269189053; bh=heyuYa2JPG0lu7GUHvqXqkH+knPoUivhy4eDx2zeqFU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=lgKgFcyaynWP13u3Jc0RVgSAvrsfPi8iyUqvKWr6M+HGGUlsQdwMR5EMZrftjYVcG q26bX0RQ3mPHYuuBsU+wetU5XqPA/ifWmeB3myY8BxMR1vjmRhstr6JDwvcipDzBGl 5Rzrb4HputN8l8Vuy5t0+QLf/oG8JlvHcRrSR3oQ= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o2LGUqKH088946; Sun, 21 Mar 2010 17:30:52 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sun, 21 Mar 2010 17:30:52 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Scott Long Message-ID: <20100321163051.GT99813@acme.spoerlein.net> Mail-Followup-To: Scott Long , Matthew Dillon , Alexander Motin , freebsd-current@freebsd.org, freebsd-arch@freebsd.org References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Alexander Motin , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 16:30:54 -0000 On Sat, 20.03.2010 at 12:17:33 -0600, Scott Long wrote: > Windows has a MAXPHYS equivalent of 1M. Linux has an equivalent of an > odd number less than 512k. For the purpose of benchmarking against these > OS's, having comparable capabilities is essential; Linux easily beats FreeBSD > in the silly-i/o-test because of the MAXPHYS difference (though FreeBSD typically > stomps linux in real I/O because of vastly better latency and caching algorithms). > I'm fine with raising MAXPHYS in production once the problems are addressed. Hi Scott, while I'm sure that most of the FreeBSD admins are aware of "silly" benchmarks where Linux I/O seems to dwarf FreeBSD, do you have some pointers regarding your statement that FreeBSD triumphs for real-world I/O loads? Can this be simulated using iozone, bonnie, etc? More importantly, is there a way to do this file system independently? Regards, Uli From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 16:32: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 0A6E1106566C; Sun, 21 Mar 2010 16:32:43 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 9CDF78FC22; Sun, 21 Mar 2010 16:32:42 +0000 (UTC) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o2LGWdqu036885; Sun, 21 Mar 2010 10:32:39 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4BA52179.9030903@FreeBSD.org> Date: Sun, 21 Mar 2010 10:32:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <39C5864C-8A6B-4137-8743-D7B9F30F5939@samsco.org> References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 16:32:43 -0000 On Mar 20, 2010, at 1:26 PM, Alexander Motin wrote: > Scott Long wrote: >> On Mar 20, 2010, at 11:53 AM, Matthew Dillon wrote: >>> Diminishing returns get hit pretty quickly with larger MAXPHYS = values. >>> As long as the I/O can be pipelined the reduced transaction rate >>> becomes less interesting when the transaction rate is less than a >>> certain level. Off the cuff I'd say 2000 tps is a good basis for >>> considering whether it is an issue or not. 256K is actually quite >>> a reasonable value. Even 128K is reasonable. >>=20 >> I agree completely. I did quite a bit of testing on this in 2008 and = 2009. >> I even added some hooks into CAM to support this, and I thought that = I had >> discussed this extensively with Alexander at the time. Guess it was = yet another >> wasted conversation with him =3D-( I'll repeat it here for the = record. >=20 > AFAIR at that time you've agreed that 256K gives improvements, and 64K > of DFLTPHYS limiting most SCSI SIMs is too small. That's why you've > implemented that hooks in CAM. I have not forgot that conversation = (pity > that it quietly died for SCSI SIMs). I agree that too high value could > be just a waste of resources. As you may see I haven't blindly = committed > it, but asked public opinion. If you think 256K is OK - let it be = 256K. > If you think that 256K needed only for media servers - OK, but lets = make > it usable there. >=20 I think that somewhere in the range of 128-512k is appropriate for a = given platform. Maybe big-iron gets 512k and notebooks and embedded systems get 128k? = It's partially a platform architecture issue, and partially a platform = application issue. Ultimately, it should be possible to have up to 1M, and maybe even more. = I don't know how best to make that selectable, or whether it should just be the = default. >> Besides the nswbuf sizing problem, there is a real problem that a lot = of drivers >> have incorrectly assumed over the years that MAXPHYS and DFLTPHYS are >> particular values, and they've sized their data structures = accordingly. Before >> these values are changed, an audit needs to be done OF EVERY SINGLE >> STORAGE DRIVER. No exceptions. This isn't a case of changing MAXHYS >> in the ata driver, testing that your machine boots, and then = committing the change >> to source control. Some drivers will have non-obvious restrictions = based on >> the number of SG elements allowed in a particular command format. = MPT >> comes to mind (its multi message SG code seems to be broken when I = tried >> testing large MAXPHYS on it), but I bet that there are others. >=20 > As you should remember, we have made it in such way, that all = unchecked > drivers keep using DFLTPHYS, which is not going to be changed ever. So > there is no problem. I would more worry about non-CAM storages and = above > stuff, like some rare GEOM classes. And that's why I say that everything needs to be audited. Are there CAM = drivers that default to being silent on cpi->maxio, but still look at DFLTPHYS = and MAXPHYS? Are there non-CAM drivers that look at MAXPHYS, or that silently assume = that MAXPHYS will never be more than 128k? Scott From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 16:39: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 46AB3106566C; Sun, 21 Mar 2010 16:39:20 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id DA6AB8FC0C; Sun, 21 Mar 2010 16:39:19 +0000 (UTC) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o2LGdAUv036941; Sun, 21 Mar 2010 10:39:10 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <20100321163051.GT99813@acme.spoerlein.net> Date: Sun, 21 Mar 2010 10:39:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9524C333-F191-4F7A-A5FA-BD52498169C0@samsco.org> References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <20100321163051.GT99813@acme.spoerlein.net> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Alexander Motin , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 16:39:20 -0000 On Mar 21, 2010, at 10:30 AM, Ulrich Sp=F6rlein wrote: > On Sat, 20.03.2010 at 12:17:33 -0600, Scott Long wrote: >> Windows has a MAXPHYS equivalent of 1M. Linux has an equivalent of = an >> odd number less than 512k. For the purpose of benchmarking against = these >> OS's, having comparable capabilities is essential; Linux easily beats = FreeBSD >> in the silly-i/o-test because of the MAXPHYS difference (though = FreeBSD typically >> stomps linux in real I/O because of vastly better latency and caching = algorithms). >> I'm fine with raising MAXPHYS in production once the problems are = addressed. >=20 > Hi Scott, >=20 > while I'm sure that most of the FreeBSD admins are aware of "silly" > benchmarks where Linux I/O seems to dwarf FreeBSD, do you have some > pointers regarding your statement that FreeBSD triumphs for real-world > I/O loads? Can this be simulated using iozone, bonnie, etc? More > importantly, is there a way to do this file system independently? >=20 iozone and bonnie tend to be good at testing serialized I/O latency; = each read and write is serialized without any buffering. My experience = is that they give mixed results, sometimes they favor freebsd, sometime = linux, sometimes it's a wash, all because they are so sensitive to = latency. And that's where is also gets hard to have a "universal" = benchmark; what are you really trying to model, and how does that model = reflect your actual workload? Are you running a single-instance, single = threaded application that is sensitive to latency? Are you running a = multi-instance/multi-threaded app that is sensitive to bandwidth? Are = you operating on a single file, or on a large tree of files, or on a raw = device? Are you sharing a small number of relatively stable file = descriptors, or constantly creating and deleting files and truncating = space?= From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 17:03: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 6BBB2106566C for ; Sun, 21 Mar 2010 17:03:02 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 01E7B8FC0A for ; Sun, 21 Mar 2010 17:03:02 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (Postfix) with ESMTPS id F211D5C84; Sun, 21 Mar 2010 17:53:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1269190397; bh=o2mmxpb8Ol6Va50nCfh3b6uJrRt/9DfdyoTAD/Y1P7E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=fdfvNQoZhGZYBjsrCRzcwHTFuWtrjlPR/nwEToJ6WwliOMvFz0s6o9ZQ9wZhWIaue STSEHXx4+CCJFhWAKhDVbhB6oZtB0tmrUAgmS9AuszZsqauCyvRsFqWM6GGeFJLbI1 Zmo3+kP9OT6gXzJGI4kPw2YvYdPwmb0dYcw/ZeX4= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o2LGrGoJ089397; Sun, 21 Mar 2010 17:53:16 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sun, 21 Mar 2010 17:53:16 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Scott Long Message-ID: <20100321165316.GU99813@acme.spoerlein.net> Mail-Followup-To: Scott Long , freebsd-current@freebsd.org, freebsd-arch@freebsd.org References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <20100321163051.GT99813@acme.spoerlein.net> <9524C333-F191-4F7A-A5FA-BD52498169C0@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9524C333-F191-4F7A-A5FA-BD52498169C0@samsco.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 17:03:02 -0000 [CC trimmed] On Sun, 21.03.2010 at 10:39:10 -0600, Scott Long wrote: > On Mar 21, 2010, at 10:30 AM, Ulrich Spörlein wrote: > > On Sat, 20.03.2010 at 12:17:33 -0600, Scott Long wrote: > >> Windows has a MAXPHYS equivalent of 1M. Linux has an equivalent of an > >> odd number less than 512k. For the purpose of benchmarking against these > >> OS's, having comparable capabilities is essential; Linux easily beats FreeBSD > >> in the silly-i/o-test because of the MAXPHYS difference (though FreeBSD typically > >> stomps linux in real I/O because of vastly better latency and caching algorithms). > >> I'm fine with raising MAXPHYS in production once the problems are addressed. > > > > Hi Scott, > > > > while I'm sure that most of the FreeBSD admins are aware of "silly" > > benchmarks where Linux I/O seems to dwarf FreeBSD, do you have some > > pointers regarding your statement that FreeBSD triumphs for real-world > > I/O loads? Can this be simulated using iozone, bonnie, etc? More > > importantly, is there a way to do this file system independently? > > > > iozone and bonnie tend to be good at testing serialized I/O latency; each read and write is serialized without any buffering. My experience is that they give mixed results, sometimes they favor freebsd, sometime linux, sometimes it's a wash, all because they are so sensitive to latency. And that's where is also gets hard to have a "universal" benchmark; what are you really trying to model, and how does that model reflect your actual workload? Are you running a single-instance, single threaded application that is sensitive to latency? Are you running a multi-instance/multi-threaded app that is sensitive to bandwidth? Are you operating on a single file, or on a large tree of files, or on a raw device? Are you sharing a small number of relatively stable file descriptors, or constantly creating and deleting files and truncating space? All true, that's why I wanted to know from you, which real world situations you encountered where FreeBSD did/does outperform Linux in regards to I/O throughput and/or latency (depending on scenario, of course). I hope you don't mind, Uli From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 17:04:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D2641065673; Sun, 21 Mar 2010 17:04:01 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id D20C58FC1C; Sun, 21 Mar 2010 17:04:00 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so188509fga.13 for ; Sun, 21 Mar 2010 10:03:59 -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=meK1mei+IjxUsyPxLAGaHWPeu8K/ID5pXFAbI25Lnt0=; b=E5w+64ki2goCY5cMnXr88PjVoJj1GqRddGK3Fk0N8GlvlMIHtTJWwJtI2sYnxH9y+h DtLJhRyvXqUPZPIed6Jr0OtxwZjFkxCBkUAgEJdhuoshfE7NODaZCWcuuEav3i2x4Sx0 hTO3A75NSPcywoYZRTOUGcZQzK4aXasKv+AzE= 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=Ts/oIeOHaw9ejSXRrQv95SFPfAZ0DHS18EnQHpmqo3XMF0bCqW5MOAE+i+uIIM2Kmq tgrzZBdXoW8ipbiRLL4NjAwDnThHQZhJrAcqi6eU7TSSBl4GKBC5kCwN2QT2/sBYwB4r Hlv/zOk0d6VPcteHzDJdYX62Is6FmGrMJXcoA= Received: by 10.86.22.2 with SMTP id 2mr511612fgv.17.1269191039808; Sun, 21 Mar 2010 10:03:59 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm1041828fxm.8.2010.03.21.10.03.58 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 10:03:59 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BA6517C.3050509@FreeBSD.org> Date: Sun, 21 Mar 2010 19:03:56 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Scott Long References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <39C5864C-8A6B-4137-8743-D7B9F30F5939@samsco.org> In-Reply-To: <39C5864C-8A6B-4137-8743-D7B9F30F5939@samsco.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 17:04:01 -0000 Scott Long wrote: > On Mar 20, 2010, at 1:26 PM, Alexander Motin wrote: >> As you should remember, we have made it in such way, that all unchecked >> drivers keep using DFLTPHYS, which is not going to be changed ever. So >> there is no problem. I would more worry about non-CAM storages and above >> stuff, like some rare GEOM classes. > > And that's why I say that everything needs to be audited. Are there CAM drivers > that default to being silent on cpi->maxio, but still look at DFLTPHYS and MAXPHYS? If some (most of) drivers silent on cpi->maxio - they will be limited by safe level of DFLTPHYS, which should not be changed ever. There should be no problem. > Are there non-CAM drivers that look at MAXPHYS, or that silently assume that > MAXPHYS will never be more than 128k? That is a question. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 17:10: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 5D9AC1065670; Sun, 21 Mar 2010 17:10:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id EED398FC1E; Sun, 21 Mar 2010 17:10:51 +0000 (UTC) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o2LHAmOJ037217; Sun, 21 Mar 2010 11:10:48 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <20100321165316.GU99813@acme.spoerlein.net> Date: Sun, 21 Mar 2010 11:10:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <574BA80D-61C3-4E3A-A5D3-898ABC605AED@samsco.org> References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <20100321163051.GT99813@acme.spoerlein.net> <9524C333-F191-4F7A-A5FA-BD52498169C0@samsco.org> <20100321165316.GU99813@acme.spoerlein.net> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 17:10:52 -0000 On Mar 21, 2010, at 10:53 AM, Ulrich Sp=F6rlein wrote: > [CC trimmed] > On Sun, 21.03.2010 at 10:39:10 -0600, Scott Long wrote: >> On Mar 21, 2010, at 10:30 AM, Ulrich Sp=F6rlein wrote: >>> On Sat, 20.03.2010 at 12:17:33 -0600, Scott Long wrote: >>>> Windows has a MAXPHYS equivalent of 1M. Linux has an equivalent of = an >>>> odd number less than 512k. For the purpose of benchmarking against = these >>>> OS's, having comparable capabilities is essential; Linux easily = beats FreeBSD >>>> in the silly-i/o-test because of the MAXPHYS difference (though = FreeBSD typically >>>> stomps linux in real I/O because of vastly better latency and = caching algorithms). >>>> I'm fine with raising MAXPHYS in production once the problems are = addressed. >>>=20 >>> Hi Scott, >>>=20 >>> while I'm sure that most of the FreeBSD admins are aware of "silly" >>> benchmarks where Linux I/O seems to dwarf FreeBSD, do you have some >>> pointers regarding your statement that FreeBSD triumphs for = real-world >>> I/O loads? Can this be simulated using iozone, bonnie, etc? More >>> importantly, is there a way to do this file system independently? >>>=20 >>=20 >> iozone and bonnie tend to be good at testing serialized I/O latency; = each read and write is serialized without any buffering. My experience = is that they give mixed results, sometimes they favor freebsd, sometime = linux, sometimes it's a wash, all because they are so sensitive to = latency. And that's where is also gets hard to have a "universal" = benchmark; what are you really trying to model, and how does that model = reflect your actual workload? Are you running a single-instance, single = threaded application that is sensitive to latency? Are you running a = multi-instance/multi-threaded app that is sensitive to bandwidth? Are = you operating on a single file, or on a large tree of files, or on a raw = device? Are you sharing a small number of relatively stable file = descriptors, or constantly creating and deleting files and truncating = space? >=20 > All true, that's why I wanted to know from you, which real world > situations you encountered where FreeBSD did/does outperform Linux in > regards to I/O throughput and/or latency (depending on scenario, of > course). I have some tests that spawn N number of threads and then do sequential = and random i/o either into a filesystem or a raw disk. FreeBSD gets = more work done with fewer I/O's than linux when you're operating through = the filesystem, thanks to softupdates and the block layer. Linux has a = predictive cache that often times will generate too much i/o in a vain = attempt to aggressively prefetch blocks. So even then it's hard to = measure in a simple way; linux will do more i/o, but less of it will be = useful to the application, thereby increasing latency and increasing = application runtime. Sorry I can't be more specific, but you're asking = for something that I explicitly say I can't provide. Scott From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 18:22: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 0F309106566B; Sun, 21 Mar 2010 18:22:19 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id B43948FC08; Sun, 21 Mar 2010 18:22:17 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1NtPmy-00015f-Ig; Sun, 21 Mar 2010 18:22:16 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NtPmx-0006ho-Il; Sun, 21 Mar 2010 18:22:15 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.3) with ESMTP id o2LIMFCb093264; Sun, 21 Mar 2010 18:22:15 GMT (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.3/Submit) id o2LIMEaM093263; Sun, 21 Mar 2010 18:22:14 GMT (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Sun, 21 Mar 2010 18:22:14 +0000 From: Anton Shterenlikht To: Anton Shterenlikht Message-ID: <20100321182214.GK84236@mech-cluster241.men.bris.ac.uk> References: <20100317163230.GJ87732@mech-cluster241.men.bris.ac.uk> <20100319211535.GA76683@mech-cluster241.men.bris.ac.uk> <20100320154446.GE84236@mech-cluster241.men.bris.ac.uk> <20100320205337.GF84236@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100320205337.GF84236@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jhell , FreeBSD Current , freebsd-ia64@freebsd.org Subject: csup/svn/ldd make host unresponsive [WAS: Re: ldd leaves the machine unresponsive] 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, 21 Mar 2010 18:22:19 -0000 On Sat, Mar 20, 2010 at 08:53:37PM +0000, Anton Shterenlikht wrote: > On Sat, Mar 20, 2010 at 03:44:46PM +0000, Anton Shterenlikht wrote: > > On Sat, Mar 20, 2010 at 07:27:43AM -0400, jhell wrote: > > > > > > On Fri, 19 Mar 2010 17:15, Anton Shterenlikht wrote: > > > In Message-Id: <20100319211535.GA76683@mech-cluster241.men.bris.ac.uk> > > > > > > > On Thu, Mar 18, 2010 at 11:29:36AM -0400, jhell wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > > > >> Hash: SHA1 > > > >> > > > >> > > > >> > > > >> On Wed, 17 Mar 2010 12:32, Anton Shterenlikht wrote: > > > >> In Message-Id: <20100317163230.GJ87732@mech-cluster241.men.bris.ac.uk> > > > >> > > > >>> Just updated to ia64 r205248 > > > >>> > > > >>> If my problem is due to my mis-configuration, > > > >>> I apologise in advance. > > > >>> > > > >>> I run this shell script after each upgrade > > > >>> and 'make delete-old-libs' to check > > > >>> if any shared objects need to be rebuilt: > > > >>> > > > >>> > > > >>> > > > >>> #!/bin/sh > > > >>> > > > >>> for file in `find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/local -name "*"` > > > >>> do > > > >>> echo $file > > > >>> ldd $file >> /root/ldd_results 2> /dev/zero > > > >>> done > > > >>> > > > >>> > > > >>> > > > >> > > > >> This will probably do closer to what you actually would want to look for. > > > >> > > > >> Writing to /dev/zero ... I don't know never tried it since /dev/null is > > > >> usually the standard place to throw trash. > > > >> > > > >> #!/bin/sh > > > >> for file in `find /*bin /usr/*bin /usr/lib* /usr/local/*bin -type f` do > > > >> echo $file > > > >> ldd $file >>/root/ldd_results 2>/dev/null > > > >> done > > > >> > > > >> The problem with your script is that it finds most files that it can not > > > >> or is not useful to run ldd on and leaves you junk in return. > > > >> > > > >> It might be more useful if you searched for dynamically linked ELF > > > >> binaries to run ldd against like the following. > > > >> > > > >> === Script starts here === > > > >> #!/bin/sh > > > >> > > > >> SEARCHPATH="/*bin /usr/*bin /usr/lib* /usr/local/*bin" > > > >> > > > >> trap 'exit 1' 2 > > > >> > > > >> check_libs() { > > > >> for spath in $SEARCHPATH; do > > > >> for ifelf in `find $spath -type f`; do > > > >> ldd `file $ifelf | grep dynamically | cut -f1 -d:` > > > >> done > > > >> done > > > >> } > > > >> > > > >> check_libs 2>/dev/null > > > >> === Script ends here === > > > >> > > > >> The above will find all type ELF * that are dynamically linked within the > > > >> SEARCHPATH variable and run ldd on them and print the results to stdout. > > > >> > > > >> Obviously since you are going to have thousands of files being questioned, > > > >> stdout is not going to be useful. > > > >> > > > >> So with the about stated: > > > >> save the script to: checklibs.sh > > > >> run with: "sh checklibs.sh >/root/checklibs_output" > > > >> or: "script /root/checklibs_output checklibs.sh" > > > >> > > > >>> After the upgrade to r205248, the script > > > >>> freezes at seemingly random points. > > > >>> > > > >> > > > >> Unneeded disk usage & execution. > > > >> > > > >>> I can still ssh to the machine (using keys), i.e. > > > >>> I see the welcome message, but cannot get to the console prompt. > > > >> > > > >> Of course... to many open files or processes in wait. SSH already has the > > > >> information it needs loaded into memory, that's why you can get sort-of-in > > > >> > > > >> ZFS file-system perhaps ? > > > > > > > > I've no ZFS. > > > > > > > > I'm seeing very similar behaviour now with csup: > > > > > > > > ( I do csup -L2 /root/ports-supfile, where > > > > > > > > # cat /root/ports-supfile > > > > *default host=cvsup.uk.FreeBSD.org > > > > *default base=/var/db > > > > *default prefix=/usr > > > > *default release=cvs tag=. delete use-rel-suffix compress > > > > > > > > ports-all > > > > # ) > > > > > > > > top(1) shows: > > > > > > > > last pid: 1160; load averages: 0.00, 0.06, 0.07 up 0+00:10:53 15:05:52 > > > > 81 processes: 3 running, 61 sleeping, 17 waiting > > > > CPU 0: 0.0% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.8% idle > > > > CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > > > > Mem: 23M Active, 19M Inact, 75M Wired, 136K Cache, 34M Buf, 5900M Free > > > > Swap: 2780M Total, 2780M Free > > > > > > > > PID UID THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > > > 10 0 2 171 ki31 0K 64K RUN 0 20:18 198.00% idle > > > > 11 0 17 -48 - 0K 544K WAIT 0 0:01 0.00% intr > > > > 1118 1001 1 96 0 12800K 3920K CPU0 0 0:00 0.00% top > > > > 4 0 1 -8 - 0K 32K - 1 0:00 0.00% g_down > > > > 1158 0 4 -8 0 43672K 6296K biowr 0 0:00 0.00% csup > > > > > > > > > > > > which stays in biowr state indefinitely. > > > > > > > > I can issue kill -9 or kill -HUP from top(1), > > > > which makes csup change state to STOP, but > > > > nothing else happens. > > > > > > > > As before, I can't log in from other terminals > > > > and have to do a cold reset. I've reinstalled > > > > on another disk, so not sure what's going on. > > > > > > > > I think rm(1) is also extremely slow, but > > > > maybe I'm imagining things. > > > > > > > > many thanks > > > > anton > > > > > > > > > > > > > > > > > I would post up the contents of your make.conf & your kernel config & your > > > dmesg somewhere so it can be evaluated. > > > > When I reinstalled 8.0 from a CD, > > I updated source with csup, that worked. > > However, after upgrading to current, I can't get > > any luck with csup. The important bit is that > > I don't really know what revision this is. > > > > I've no /etc/make.conf > > > > kernel config: > > http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/UZI > > > > dmesg: > > http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/dmesg.boot > > > > Marcel, this might be of some interest. > > I managed to csup /usr/src, probably because > there was not too many updates from 3 days ago. > I proceeded with updating the system, but > had a freeze again in single user at the very > beginning of 'make installworld'. > > Now I've reinstalled 8.0-CURRENT-200906 > snapshot and have no issues with csup, > just completed downloading the ports tree. > It seems something is wrong with csup(1), > or pehaps disk i/o, in the recent ia64 updates. > > I'll try building svn from ports and update > via svn, will report the results. An update: 1. reinstalled from 8.0-CURRENT-200906 2. installed the ports tree via csup(1) 3. installed svn(1) from ports 4. updated src with svn. Both svn and csup worked fine here. 5. rebuilt and reinstalled kernel and world as usual to r205403. 6. rebooted. The kernel config file: http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/UZI dmesg: http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/dmesg.boot ifconfig -a: http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/ifconfig-a 7. tried to update the src again with svn and got stuck. All I can issue is CTRL/T, which shows for svn: mech-as221# svn co svn://svn.freebsd.org/base/head/ /usr/src/ load: 0.00 cmd: svn 888 [biord] 8008.53r 0.09u 0.30s 0% 13992k load: 0.00 cmd: svn 888 [biord] 8009.53r 0.09u 0.30s 0% 13992k load: 0.00 cmd: svn 888 [biord] 8015.07r 0.09u 0.30s 0% 13992k in another ssh session I was running gstat(8) which showed zero activity in the disk. and in yet another ssh session I tried to launch top: mech-as221# top load: 0.00 cmd: csh 915 [ufs] 6146.33r 0.00u 0.00s 0% 5008k load: 0.00 cmd: csh 915 [ufs] 6147.15r 0.00u 0.00s 0% 5008k and on the serial console: load: 0.00 cmd: getty 828 [ufs] 8129.90r 0.00u 0.00s 0% 2560k load: 0.00 cmd: getty 828 [ufs] 8130.70r 0.00u 0.00s 0% 2560k but the shell prompt never appears. I've waited maybe 2-3 hours. Can't do much else, but a cold reboot. many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 18:46: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 E9901106566C for ; Sun, 21 Mar 2010 18:46:06 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay1.uni-muenster.de (ZIVM-RELAY1.UNI-MUENSTER.DE [128.176.192.12]) by mx1.freebsd.org (Postfix) with ESMTP id 566308FC1B for ; Sun, 21 Mar 2010 18:46:04 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,284,1267398000"; d="scan'208";a="299745570" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 21 Mar 2010 19:46:02 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 970CB1B0768; Sun, 21 Mar 2010 19:46:02 +0100 (CET) Date: Sun, 21 Mar 2010 19:46:01 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Andriy Gapon Message-ID: In-Reply-To: <4BA636E6.5000604@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 18:46:07 -0000 Andriy Gapon schrieb am 2010-03-21: > on 21/03/2010 14:53 Alexander Best said the following: > > *lol* sorry. ;) > No worries. > BTW, when that rash happens, are you able to examine the core with > gdb? > Is it possible to examine values of 's' and 'p' in strlen? 'p' is not available. i guess because the segfault happens before 'p' gets assigned. but mask01 = 0x101010101010101 and lp = (const long unsigned int *) 0xc092d8. but i'm not really familiar with gdb and debugging. so you might want to ask for certain commands. ;) alex -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 19:14: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 4FF47106564A; Sun, 21 Mar 2010 19:14:43 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC95A8FC08; Sun, 21 Mar 2010 19:14:42 +0000 (UTC) Received: by gwj15 with SMTP id 15so2605465gwj.13 for ; Sun, 21 Mar 2010 12:14:42 -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 :content-type:content-transfer-encoding; bh=+toFUVuysJTKGI6mHO1fI+e5Mp83VbA6/PyJPof96cQ=; b=Ru4G6j89dTAYDrOuyslHkZIUVhvNHFmLuARg6oPrMxRCCvsPtE1SR7jZlVQeeJuowW cEcUIMv8UblwNejsoJ4YQkZQAVaQ7vG8b/K4yO7AIcSe4Dg3OkP80zBey/4E8/6Wm/Cl 58JioF4/6DuutmarEQxvWKcf0VX+vpcMksJsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=l2GIF0+dBVWiMr3zvPQWT12pQbqwsnSHnGEA+j8QmdftSbp3J4o9yg8p970o1B2FgG E5SYzlhIM+vAOsgdZNpaI5no9gGLocSusJo3Om+bAXD9nmvs2AXtB+/r9P4rgZjoE0Mn +23tT7MCrUDo9dJfU7WXgsFL7MFwPoixPHmM8= Received: by 10.90.18.33 with SMTP id 33mr3236754agr.12.1269197000835; Sun, 21 Mar 2010 11:43:20 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 7sm1276334ywc.4.2010.03.21.11.43.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 11:43:20 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BA668C9.5080407@elischer.org> Date: Sun, 21 Mar 2010 11:43:21 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Scott Long References: <1269109391.00231800.1269099002@10.7.7.3> <1269120182.00231865.1269108002@10.7.7.3> <1269120188.00231888.1269109203@10.7.7.3> <1269123795.00231922.1269113402@10.7.7.3> <1269130981.00231933.1269118202@10.7.7.3> <1269130986.00231939.1269119402@10.7.7.3> <1269134581.00231948.1269121202@10.7.7.3> <1269134585.00231959.1269122405@10.7.7.3> <4BA6279E.3010201@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 21 Mar 2010 19:14:43 -0000 Scott Long wrote: > I agree that more threads just creates many more race > complications. Even if it didn't, the storage driver is a > serialization point; it doesn't matter if you have a dozen g_* > threads if only one of them can be in the top half of the driver at > a time. No amount of fine-grained locking is going to help this. Well that depends on the driver and device.. We have multiple linux threads coming in the top under some setups so it wouldn't be a problem. > > I'd like to go in the opposite direction. The queue-dispatch-queue > model of GEOM is elegant and easy to extend, but very wasteful for > the simple case, where the simple case is one or two simple > partition transforms (mbr, bsdlabel) and/or a simple stripe/mirror > transform. None of these need a dedicated dispatch context in > order to operate. What I'd like to explore is compiling the GEOM > stack at creation time into a linear array of operations that > happen without a g_down/g_up context switch. As providers and > consumers taste each other and build a stack, that stack gets > compiled into a graph, and that graph gets executed directly from > the calling context, both from the dev_strategy() side on the top > and the bio_done() on the bottom. GEOM classes that need a > detached context can mark themselves as such, doing so will prevent > a graph from being created, and the current dispatch model will be > retained. I've considered similar ideas. Or providing a non-queuing options for some simple transformations. > > I expect that this will reduce i/o latency by a great margin, thus > directly addressing the performance problem that FusionIO makes an > example of. I'd like to also explore having the g_bio model not > require a malloc at every stage in the stack/graph; even though > going through UMA is fairly fast, it still represents overhead that > can be eliminated. It also represents an out-of-memory failure > case that can be prevented. > > I might try to work on this over the summer. It's really a > research project in my head at this point, but I'm hopeful that > it'll show results. > > Scott > > _______________________________________________ > 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 Sun Mar 21 19:41:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A05B51065672; Sun, 21 Mar 2010 19:41:38 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 38D128FC22; Sun, 21 Mar 2010 19:41:37 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so824833qwi.7 for ; Sun, 21 Mar 2010 12:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=tZ6eKi3240H08Z3I2dELOSbKUUzkD83XHYZoH8v91w4=; b=qknubNV1G+l4lHxxnVXF1NUi31FWFEbBtyDd6A/1cIpiSyYEt3baqk9O60s6DrtKrE 7yS4vwNqczvLeTgoqAHgOzXoVULLCMnJ/yDeDfflVs3J5WoPbUdeJoeVw4j9zg7npat9 b12L1wje16OaetrW7fVcD/po3twxA7yxwpAoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=k+uteu2v7lEQn8N8ef0ZHVBs0g/cnb9dffY5EirM6ya5LSMw1o+H+B3yiG3CRKhVuV C9gXMhIm9zCrRCTk1f6Oe64+oQaXXD5Aa+Ar0/2lCyouelwJ350a8CNtpF1b608xA4mp x1UjMrRV8Dpxra1dcLuNjAm8XirrDmfwDu9+s= MIME-Version: 1.0 Sender: kmatthew.macy@gmail.com Received: by 10.229.192.7 with SMTP id do7mr235450qcb.68.1269200497381; Sun, 21 Mar 2010 12:41:37 -0700 (PDT) In-Reply-To: <20100319140948.GN35333@bunrab.catwhisker.org> References: <20100318133540.GQ35333@bunrab.catwhisker.org> <1CA4C3D2-675E-4FE9-8574-4E17A073C389@gmail.com> <000C4323-1DD2-4EA1-BAEE-FDAF1F7B679C@freebsd.org> <82c4140e1003181338ue9c7561r4d8cfa167cebfb51@mail.gmail.com> <82c4140e1003181515r5c43ad86k90fe8abd8cd3f832@mail.gmail.com> <20100319140948.GN35333@bunrab.catwhisker.org> Date: Sun, 21 Mar 2010 12:41:37 -0700 X-Google-Sender-Auth: d5ad8c6934ba3f3a Message-ID: <82c4140e1003211241v64612bc5v538a898ecb2794c@mail.gmail.com> From: "K. Macy" To: David Wolfskill , Rui Paulo , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Panic @r205276 (Fatal trap 12: page fault while in kernel mode) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 19:41:38 -0000 On Fri, Mar 19, 2010 at 7:09 AM, David Wolfskill wrote: > On Fri, Mar 19, 2010 at 01:09:11PM +0000, Rui Paulo wrote: >> ... >> > Do you all have either out-of-tree modules or modules that you did not >> > re-build when re-compiling your kernel? >> >> I have in-tree modules, but I tried a clean build. > > I corresponded with kmacy@ a bit yesterday. > > Pending resolution, he's committed r205298 to "turn 205266 in to a no-op > until the problem can be properly diagnosed." > Did anyone see this on amd64 with cleanly compiled modules? I now know that this changes the initialization paths in an unworkable way on i386. Thanks, Kip From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 20:27: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 35B051065670; Sun, 21 Mar 2010 20:27:53 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id E17DF8FC16; Sun, 21 Mar 2010 20:27:52 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1NtRkV-00034a-RS; Sun, 21 Mar 2010 20:27:51 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NtRkV-0007m8-Mk; Sun, 21 Mar 2010 20:27:51 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.3) with ESMTP id o2LKRp11093523; Sun, 21 Mar 2010 20:27:51 GMT (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.3/Submit) id o2LKRpk2093522; Sun, 21 Mar 2010 20:27:51 GMT (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Sun, 21 Mar 2010 20:27:51 +0000 From: Anton Shterenlikht To: xcllnt@mac.com Message-ID: <20100321202750.GL84236@mech-cluster241.men.bris.ac.uk> References: <20100317163230.GJ87732@mech-cluster241.men.bris.ac.uk> <20100319211535.GA76683@mech-cluster241.men.bris.ac.uk> <20100320154446.GE84236@mech-cluster241.men.bris.ac.uk> <20100320205337.GF84236@mech-cluster241.men.bris.ac.uk> <20100321182214.GK84236@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100321182214.GK84236@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: rm/csup/svn/ldd make host unresponsive [WAS: Re: ldd leaves the machine unresponsive] 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, 21 Mar 2010 20:27:53 -0000 Marcel On Sun, Mar 21, 2010 at 06:22:14PM +0000, Anton Shterenlikht wrote: > > An update: > > 1. reinstalled from 8.0-CURRENT-200906 > > 2. installed the ports tree via csup(1) > > 3. installed svn(1) from ports > > 4. updated src with svn. > Both svn and csup worked fine here. > > 5. rebuilt and reinstalled kernel and world as > usual to r205403. > > 6. rebooted. > The kernel config file: > http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/UZI > > dmesg: > http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/dmesg.boot > > ifconfig -a: > http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/ifconfig-a > > > 7. tried to update the src again with svn and got stuck. > All I can issue is CTRL/T, which shows for svn: > > mech-as221# svn co svn://svn.freebsd.org/base/head/ /usr/src/ > > load: 0.00 cmd: svn 888 [biord] 8008.53r 0.09u 0.30s 0% 13992k > load: 0.00 cmd: svn 888 [biord] 8009.53r 0.09u 0.30s 0% 13992k > load: 0.00 cmd: svn 888 [biord] 8015.07r 0.09u 0.30s 0% 13992k > > in another ssh session I was running gstat(8) which showed > zero activity in the disk. > > and in yet another ssh session I tried to launch top: > > mech-as221# top > load: 0.00 cmd: csh 915 [ufs] 6146.33r 0.00u 0.00s 0% 5008k > load: 0.00 cmd: csh 915 [ufs] 6147.15r 0.00u 0.00s 0% 5008k > > and on the serial console: > > load: 0.00 cmd: getty 828 [ufs] 8129.90r 0.00u 0.00s 0% 2560k > load: 0.00 cmd: getty 828 [ufs] 8130.70r 0.00u 0.00s 0% 2560k > > but the shell prompt never appears. > I've waited maybe 2-3 hours. On reboot I did # cd /usr/obj # chflags -R noschg * # rm -rf * I monitor disk activity with iostat(8) and gstat(8), and system activity with top(1) from 3 separate ssh sessions. For about 5-10 sec iostat(8) and gstat(8) show significant disk activity. After that both iostat and gstat show zero disk activity. top(1) shows: [skip] PID UID THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 0 2 171 ki31 0K 64K RUN 0 28:40 198.00% idle 11 0 17 -48 - 0K 544K WAIT 0 0:02 0.00% intr 893 0 1 96 0 12800K 4008K CPU0 0 0:00 0.00% top 918 0 1 -4 0 11592K 2424K getblk 0 0:00 0.00% rm [skip] rm never exits (well.. within 20 minutes). kill -9 918 (issued from top(1)) makes no effect. No new ssh logins are possible, and the existing ssh sessions and the serial line don't show the shell prompt. It seems the problems I've had in the last several days with ldd/csup/svn/rm have the same root cause. I'm just not sure if it's someting simple that I've messed up, or something went wrong in current.. many thanks for your help anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 20:29: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 BA7AF1065673 for ; Sun, 21 Mar 2010 20:29:24 +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 091D88FC13 for ; Sun, 21 Mar 2010 20:29:23 +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 WAA05464; Sun, 21 Mar 2010 22:29:19 +0200 (EET) (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 1NtRlv-000B4x-3d; Sun, 21 Mar 2010 22:29:19 +0200 Message-ID: <4BA6819E.4050504@icyb.net.ua> Date: Sun, 21 Mar 2010 22:29:18 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 20:29:24 -0000 on 21/03/2010 20:46 Alexander Best said the following: > Andriy Gapon schrieb am 2010-03-21: >> on 21/03/2010 14:53 Alexander Best said the following: >>> *lol* sorry. ;) > >> No worries. >> BTW, when that rash happens, are you able to examine the core with >> gdb? >> Is it possible to examine values of 's' and 'p' in strlen? > > 'p' is not available. i guess because the segfault happens before 'p' gets > assigned. > > but mask01 = 0x101010101010101 and lp = (const long unsigned int *) 0xc092d8. > > but i'm not really familiar with gdb and debugging. so you might want to ask > for certain commands. ;) Not sure what I was dreaming of when I wrote my request. I actually meant 'str' and 'lp'. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 20:38: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 B1168106566C; Sun, 21 Mar 2010 20:38:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF608FC08; Sun, 21 Mar 2010 20:38:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZN00CRTG0GI790@asmtp023.mac.com>; Sun, 21 Mar 2010 13:38:41 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003210204 From: Marcel Moolenaar In-reply-to: <20100321202750.GL84236@mech-cluster241.men.bris.ac.uk> Date: Sun, 21 Mar 2010 13:38:40 -0700 Message-id: References: <20100317163230.GJ87732@mech-cluster241.men.bris.ac.uk> <20100319211535.GA76683@mech-cluster241.men.bris.ac.uk> <20100320154446.GE84236@mech-cluster241.men.bris.ac.uk> <20100320205337.GF84236@mech-cluster241.men.bris.ac.uk> <20100321182214.GK84236@mech-cluster241.men.bris.ac.uk> <20100321202750.GL84236@mech-cluster241.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: rm/csup/svn/ldd make host unresponsive [WAS: Re: ldd leaves the machine unresponsive] 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, 21 Mar 2010 20:38:56 -0000 On Mar 21, 2010, at 1:27 PM, Anton Shterenlikht wrote: > It seems the problems I've had in the last > several days with ldd/csup/svn/rm have the > same root cause. I'm aware of the issue. Give me a few days to fix it. I have a fix under test, but it exposes other problems... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 21:11: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 371F4106566B for ; Sun, 21 Mar 2010 21:11:26 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay1.uni-muenster.de (ZIVM-RELAY1.UNI-MUENSTER.DE [128.176.192.12]) by mx1.freebsd.org (Postfix) with ESMTP id B72D38FC08 for ; Sun, 21 Mar 2010 21:11:25 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,284,1267398000"; d="scan'208";a="299752727" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 21 Mar 2010 22:11:11 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 6E9611B0750; Sun, 21 Mar 2010 22:11:11 +0100 (CET) Date: Sun, 21 Mar 2010 22:11:11 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Andriy Gapon Message-ID: In-Reply-To: <4BA6819E.4050504@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?Q?Civka=2C_G=FCnter_=28LNG-MUE=29?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 21:11:26 -0000 Andriy Gapon schrieb am 2010-03-21: > on 21/03/2010 20:46 Alexander Best said the following: > > Andriy Gapon schrieb am 2010-03-21: > >> on 21/03/2010 14:53 Alexander Best said the following: > >>> *lol* sorry. ;) > >> No worries. > >> BTW, when that rash happens, are you able to examine the core with > >> gdb? > >> Is it possible to examine values of 's' and 'p' in strlen? > > 'p' is not available. i guess because the segfault happens before > > 'p' gets > > assigned. > > but mask01 = 0x101010101010101 and lp = (const long unsigned int *) > > 0xc092d8. > > but i'm not really familiar with gdb and debugging. so you might > > want to ask > > for certain commands. ;) > Not sure what I was dreaming of when I wrote my request. > I actually meant 'str' and 'lp'. *hehe* that makes more sense. well i already sent you lp. unfortunately str is not available to gdb: (gdb) print str Variable "str" is not available. alex -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 21:19: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 D1E311065680 for ; Sun, 21 Mar 2010 21:19:24 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A2C8F8FC15 for ; Sun, 21 Mar 2010 21:19:24 +0000 (UTC) Received: by pwj4 with SMTP id 4so3726428pwj.13 for ; Sun, 21 Mar 2010 14:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/x01JyjdJpEa0alSmrgWFX+1d2mZ1o1WqLUfyxFvyLs=; b=i7vPkXKiqwODZpopySb2uYQ/C1ZKImX2niFpZATZYzUG1Myix6Jce7UxL8vzQxQUvZ FSc5zkNGvinT9FyHr+oip1h5hbEFuUQhoWzw1qes64yFl7WaQngydOMgvQ0z3vJNIX33 nlTmEvtwNpGf9/2+34pZYAY+2jpAQIgMRrsLQ= 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=bX2PeMmv9olKtL5lYF3wtcO5s9lYuwy0Ldvmyafs8NLUaM72tcxMj253w30AqrBj0I FIxayQLdI+MDmcpTliGnihZNS4AtmwSMqvlyYTO04I/ORHdk6+XbHxVoQJKwsZhY5G2k aKXa2TywVyS+Fiz63mOdkuHbE9wz26Lf/8IZI= MIME-Version: 1.0 Received: by 10.142.120.3 with SMTP id s3mr417682wfc.35.1269206364052; Sun, 21 Mar 2010 14:19:24 -0700 (PDT) In-Reply-To: <4BA61634.8090006@icyb.net.ua> References: <4BA61634.8090006@icyb.net.ua> Date: Sun, 21 Mar 2010 14:19:23 -0700 Message-ID: <7d6fde3d1003211419q280909f1tec61cd8a0cc85afb@mail.gmail.com> From: Garrett Cooper To: Andriy Gapon Content-Type: multipart/mixed; boundary=001636e0b9c579df190482562218 Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 21:19:24 -0000 --001636e0b9c579df190482562218 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Mar 21, 2010 at 5:51 AM, Andriy Gapon wrote: > on 21/03/2010 14:35 Alexander Best said the following: >> Andriy Gapon schrieb am 2010-03-21: >>> on 21/03/2010 13:43 Garrett Cooper said the following: >> >>>> Works for me *shrugs*: >> >>>> $ gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 >>>> Using built-in specs. >>>> Target: amd64-undermydesk-freebsd >>>> Configured with: FreeBSD/amd64 system compiler >>>> Thread model: posix >>>> gcc version 4.2.1 20070719 =A0[FreeBSD] >>>> =A0/usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null >>>> =A0-mtune=3Dgeneric >>>> ignoring duplicate directory "/usr/include" >>>> #include "..." search starts here: >>>> #include <...> search starts here: >>>> =A0/usr/include >>>> End of search list. >>>> $ echo $? >>>> 0 >> >>> Do you also have the latest version of libc _installed_ in the >>> system? >> >> i think so. i grabbed a fresh src copy yesterday and did >> buildworld/installworld a few ours ago. >> >> i've attached the output of `ident /lib/libc.so.7`. > > The question was for Garrett :) Pinky promise ... I've started basing /usr/src off SVN recently (instead of csup) and this is what I have: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #5 r205310: Sat Mar 20 01:32:51 PDT 2010 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Thanks, -Garrett --001636e0b9c579df190482562218 Content-Type: application/octet-stream; name="libc-ident.log" Content-Disposition: attachment; filename="libc-ident.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g72cofqn0 L2xpYi9saWJjLnNvLjc6CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvY3N1L2FtZDY0L2NydGkuUyx2 IDEuNyAyMDA0LzAzLzIxIDAxOjM5OjAxIHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvY3N1L2FtZDY0L2NydG4uUyx2IDEuNiAyMDA0LzAzLzIxIDAxOjM5OjAxIHBldGVyIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvd21lbXNldC5jLHYgMS44IDIwMDkv MDIvMDMgMjA6MjU6MzYgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJp bmcvd21lbW1vdmUuYyx2IDEuNyAyMDA5LzAyLzAzIDE3OjU4OjIwIGRhbmdlciBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3dtZW1jbXAuYyx2IDEuNyAyMDA5LzAyLzAz IDE3OjU4OjIwIGRhbmdlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5n L3djc3hmcm0uYyx2IDEuMyAyMDA0LzA0LzA3IDA5OjQ3OjU2IHRqciBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3djc3dpZHRoLmMsdiAxLjcgMjAwNy8wMS8wOSAwMDoy ODoxMiBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy93Y3N0b2su Yyx2IDEuMyAyMDA3LzEyLzEyIDE4OjMzOjA2IHdlcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvc3RyaW5nL3djc3N0ci5jLHYgMS4xMCAyMDA5LzAyLzAzIDE3OjU4OjIwIGRhbmdl ciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3djc3Nwbi5jLHYgMS44 IDIwMDkvMDIvMDMgMTc6NTg6MjAgZGFuZ2VyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9zdHJpbmcvd2NzcmNoci5jLHYgMS43IDIwMDIvMTAvMjMgMTA6NTI6MDQgdGpyIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvd2NzcGJyay5jLHYgMS43IDIwMDkv MDIvMDMgMTc6NTg6MjAgZGFuZ2VyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9z dHJpbmcvd2NzbmNweS5jLHYgMS4xMCAyMDA3LzAxLzA5IDAwOjI4OjEyIGltcCBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3djc25jbXAuYyx2IDEuOSAyMDA5LzAyLzAz IDE3OjU4OjIwIGRhbmdlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5n L3djc25jYXQuYyx2IDEuOCAyMDA5LzAyLzAzIDE3OjU4OjIwIGRhbmdlciBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3djc25jYXNlY21wLmMsdiAxLjEgMjAwOS8wMi8y OCAwNjowMDo1OCBkYXMgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy93 Y3NsY3B5LmMsdiAxLjcgMjAwOS8wMi8wMyAxNzo1ODoyMCBkYW5nZXIgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy93Y3NsY2F0LmMsdiAxLjcgMjAwOS8wMi8wMyAxNzo1 ODoyMCBkYW5nZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy93Y3Nk dXAuYyx2IDEuMSAyMDA1LzA4LzEzIDA1OjU0OjMzIHRqciBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvc3RyaW5nL3djc2NzcG4uYyx2IDEuNyAyMDA5LzAyLzAzIDE3OjU4OjIwIGRh bmdlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3djc2NweS5jLHYg MS45IDIwMDkvMDIvMDMgMTc6NTg6MjAgZGFuZ2VyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9zdHJpbmcvd2NzY29sbC5jLHYgMS4zIDIwMDQvMDQvMDcgMDk6NDc6NTYgdGpyIEV4 cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvd2NzY21wLmMsdiAxLjkgMjAw OS8wMi8wMyAxNzo1ODoyMCBkYW5nZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJj L3N0cmluZy93Y3NjaHIuYyx2IDEuNyAyMDAyLzEwLzIzIDEwOjQ3OjQ3IHRqciBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3djc2NhdC5jLHYgMS45IDIwMDkvMDIvMDMg MTc6NTg6MjAgZGFuZ2VyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcv d2NzY2FzZWNtcC5jLHYgMS4xIDIwMDkvMDIvMjggMDY6MDA6NTggZGFzIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvd2NwbmNweS5jLHYgMS4xIDIwMDkvMDMvMDQgMDY6 MDE6MjcgZGFzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvd2NwY3B5 LmMsdiAxLjEgMjAwOS8wMy8wNCAwNjowMToyNyBkYXMgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL3N0cmluZy9zd2FiLmMsdiAxLjcgMjAwNy8wMS8wOSAwMDoyODoxMiBpbXAgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy9zdHJ4ZnJtLmMsdiAxLjE3IDIw MDgvMTAvMTkgMDk6MTA6NDQgZGVscGhpaiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xp YmMvc3RyaW5nL3N0cnNwbi5jLHYgMS41IDIwMDUvMDQvMDIgMTg6NTI6NDQgZGFzIEV4cCAkCiAg ICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvc3Ryc2lnbmFsLmMsdiAxLjkgMjAxMC8w MS8yNCAxMDozNToyNiB1bWUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmlu Zy9zdHJuc3RyLmMsdiAxLjUgMjAwOS8wMi8wMyAxNzo1ODoyMCBkYW5nZXIgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy9zdHJuZHVwLmMsdiAxLjIgMjAxMC8wMi8wMiAx OTowMjowOCBlZCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0cm1v ZGUuYyx2IDEuOCAyMDA5LzA0LzE0IDExOjM5OjU2IHRyYXN6IEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9zdHJpbmcvc3RybGVuLmMsdiAxLjEwIDIwMTAvMDMvMTMgMDA6MTU6MDYg ZGVscGhpaiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0cmNhc2Vz dHIuYyx2IDEuNSAyMDA5LzAyLzAzIDE3OjU4OjIwIGRhbmdlciBFeHAgJAogICAgICRGcmVlQlNE OiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0cG5jcHkuYyx2IDEuMSAyMDA5LzAyLzI4IDA2OjAwOjU4 IGRhcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3JpbmRleC5jLHYg MS44IDIwMDcvMDEvMDkgMDA6Mjg6MTIgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9zdHJpbmcvbWVtbWVtLmMsdiAxLjIgMjAwOS8wMi8wMyAxNzo1ODoyMCBkYW5nZXIgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy9tZW1jY3B5LmMsdiAxLjcgMjAw OS8wMi8wMyAxNzo1ODoyMCBkYW5nZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJj L3N0cmluZy9mbHNsbC5jLHYgMS4xIDIwMDgvMTEvMDMgMTA6MjI6MTkga2liIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvZmxzbC5jLHYgMS4zIDIwMDcvMDEvMDkgMDA6 Mjg6MTIgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvZmxzLmMs diAxLjMgMjAwNy8wMS8wOSAwMDoyODoxMiBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xp Yi9saWJjL3N0cmluZy9mZnNsbC5jLHYgMS4xIDIwMDgvMTEvMDMgMTA6MjI6MTkga2liIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvZmZzbC5jLHYgMS40IDIwMDgvMTEv MDMgMTA6MTQ6NDcga2liIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcv ZmZzLmMsdiAxLjggMjAwNy8wMS8wOSAwMDoyODoxMSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL3N0ZGxpYi90d2Fsay5jLHYgMS41IDIwMDMvMDEvMDUgMDI6NDM6MTggdGpy IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRsaWIvdHNlYXJjaC5jLHYgMS40 IDIwMDMvMDEvMDUgMDI6NDM6MTggdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9zdGRsaWIvdGZpbmQuYyx2IDEuNSAyMDAzLzAxLzA1IDAyOjQzOjE4IHRqciBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL3RkZWxldGUuYyx2IDEuNiAyMDAzLzAxLzA1 IDAyOjQzOjE4IHRqciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL3N5 c3RlbS5jLHYgMS4xMiAyMDA5LzEyLzA1IDE5OjMxOjM4IGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9zdGRsaWIvc3RydG91cS5jLHYgMS4xMiAyMDA3LzAxLzA5IDAwOjI4OjEw IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL3N0cnRvdWxsLmMs diAxLjIxIDIwMDcvMDEvMDkgMDA6Mjg6MTAgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9zdGRsaWIvc3RydG9udW0uYyx2IDEuMiAyMDA2LzAzLzE0IDE5OjUzOjAzIGFjaGUg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGxpYi9zdHJ0b3EuYyx2IDEuMTIg MjAwNy8wMS8wOSAwMDoyODoxMCBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJj L3N0ZGxpYi9zdHJmbW9uLmMsdiAxLjIwIDIwMTAvMDIvMTAgMDA6MDI6MDkgY3JhY2F1ZXIgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGxpYi9yZW1xdWUuYyx2IDEuMyAyMDAz LzAxLzA0IDA3OjM0OjQxIHRqciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3Rk bGliL3JlYWxwYXRoLmMsdiAxLjIwIDIwMDMvMDUvMjggMDg6MjM6MDEgZmpvZSBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL3JhbmRvbS5jLHYgMS4yNSAyMDA3LzAxLzA5 IDAwOjI4OjEwIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL3Jh bmQuYyx2IDEuMTcgMjAwNy8xMi8xMSAyMDozOTozMiBhY2hlIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9zdGRsaWIvcmFkaXhzb3J0LmMsdiAxLjggMjAwNy8wMS8wOSAwMDoyODox MCBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGxpYi9wdHNuYW1lLmMs diAxLjIgMjAwOS8wMi8xMSAyMDoyNDo1OSBlZCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvc3RkbGliL2xzZWFyY2guYyx2IDEuMSAyMDAyLzEwLzE2IDE0OjI5OjIyIHJvYmVydCBF eHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL2xsYWJzLmMsdiAxLjEgMjAw MS8xMS8xNSAwMjowNTowMyBtaWtlIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9z dGRsaWIvbGFicy5jLHYgMS4zIDIwMDcvMDEvMDkgMDA6Mjg6MTAgaW1wIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRsaWIvbDY0YS5jLHYgMS4xIDIwMDUvMTIvMjQgMjI6Mzc6 NTkgdHJob2RlcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL2luc3F1 ZS5jLHYgMS4zIDIwMDMvMDEvMDQgMDc6MzQ6NDEgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9zdGRsaWIvaW1heGRpdi5jLHYgMS4xIDIwMDEvMTEvMTUgMDI6MDU6MDMgbWlr ZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL2ltYXhhYnMuYyx2IDEu MSAyMDAxLzExLzE1IDAyOjA1OjAzIG1pa2UgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL3N0ZGxpYi9oZWFwc29ydC5jLHYgMS42IDIwMDgvMDEvMTMgMDI6MTE6MTAgZGFzIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRsaWIvaGNyZWF0ZS5jLHYgMS40IDIwMDgv MDcvMDYgMTE6MzE6MjAgZGFuZ2VyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9z dGRsaWIvZ2V0c3Vib3B0LmMsdiAxLjcgMjAwNy8wMS8wOSAwMDoyODoxMCBpbXAgRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGxpYi9nZXRvcHRfbG9uZy5jLHYgMS4xNSAyMDA2 LzA5LzIzIDE0OjQ4OjMxIGFjaGUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0 ZGxpYi9nZXRvcHQuYyx2IDEuOCAyMDA3LzAxLzA5IDAwOjI4OjEwIGltcCBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL2F0b2xsLmMsdiAxLjUgMjAwNy8wMS8wOSAwMDoy ODowOSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGxpYi9hdG9mLmMs diAxLjYgMjAwNy8wMS8wOSAwMDoyODowOSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xp Yi9saWJjL3N0ZGxpYi9hYnMuYyx2IDEuMyAyMDA3LzAxLzA5IDAwOjI4OjA5IGltcCBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL2E2NGwuYyx2IDEuMiAyMDA2LzA1LzE5 IDE5OjA2OjM4IGpraW0gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L3N0 cmluZy9tZW1jbXAuUyx2IDEuMiAyMDA4LzExLzAyIDAxOjEwOjU0IHBldGVyIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9hbWQ2NC9zdHJpbmcvYnplcm8uUyx2IDEuMyAyMDA4LzEx LzAyIDAxOjEwOjU0IHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9hbWQ2 NC9zdHJpbmcvYmNtcC5TLHYgMS4zIDIwMDgvMTEvMDIgMDE6MTA6NTQgcGV0ZXIgRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L3N0ZGxpYi9sbGRpdi5TLHYgMS4yIDIwMDgv MTEvMDIgMDE6MTA6NTQgcGV0ZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2Ft ZDY0L3N0ZGxpYi9sZGl2LlMsdiAxLjIgMjAwOC8xMS8wMiAwMToxMDo1NCBwZXRlciBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvYW1kNjQvc3RkbGliL2Rpdi5TLHYgMS4yIDIwMDgv MTEvMDIgMDE6MTA6NTQgcGV0ZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3hk ci94ZHJfc3RkaW8uYyx2IDEuMTMgMjAwNC8xMC8xNiAwNjozMjo0MyBvYnJpZW4gRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3hkci94ZHJfZmxvYXQuYyx2IDEuMTQgMjAwNC8xMC8x NiAwNjozMjo0MyBvYnJpZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3V1aWQv dXVpZF9zdHJlYW0uYyx2IDEuMSAyMDA4LzA4LzE0IDIyOjIzOjE2IGVtYXggRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9ydGltZS5jLHYgMS45IDIwMDUvMDMvMTAgMDA6NTc6 MDEgc3RlZmFuZiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL2Rlc19zb2Z0 LmMsdiAxLjMgMjAwNC8xMC8xNiAwNjoxMTozNCBvYnJpZW4gRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL3JwYy9zdmNfcnVuLmMsdiAxLjIwIDIwMDYvMDIvMjcgMjI6MTA6NTkgZGVp c2NoZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9ycGNiX3N0X3hkci5j LHYgMS40IDIwMDcvMTEvMjAgMDE6NTE6MjAgamIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xp Yi9saWJjL3JwYy9wbWFwX2dldG1hcHMuYyx2IDEuMTYgMjAwNC8xMC8xNiAwNjoxMTozNSBvYnJp ZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9nZXRycGNwb3J0LmMsdiAx LjEzIDIwMDQvMTAvMTYgMDY6MTE6MzQgb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9ycGMvZ2V0cnBjZW50LmMsdiAxLjE3IDIwMDkvMTEvMjUgMDQ6NTM6Mzggd29sbG1h biBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvYW1kNjQvc3lzL3NpZ3JldHVybi5T LHYgMS4xMyAyMDA3LzAxLzA5IDAwOjI3OjQ5IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvYW1kNjQvc3lzL3NldGxvZ2luLlMsdiAxLjE0IDIwMDgvMTEvMDIgMDE6MTA6NTQg cGV0ZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L3N5cy9yZWJvb3Qu Uyx2IDEuMTEgMjAwOC8xMS8wMiAwMToxMDo1NCBwZXRlciBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvYW1kNjQvc3lzL3B0cmFjZS5TLHYgMS4xMyAyMDA4LzExLzAyIDAxOjEwOjU0 IHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9hbWQ2NC9zeXMvZ2V0Y29u dGV4dC5TLHYgMS4zIDIwMDgvMTEvMDIgMDE6MTA6NTQgcGV0ZXIgRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL2FtZDY0L3N5cy9leGVjdC5TLHYgMS4xMyAyMDA4LzExLzAyIDAxOjEw OjU0IHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9hbWQ2NC9zeXMvYnJr LlMsdiAxLjE1IDIwMDgvMTEvMDIgMDE6MTA6NTQgcGV0ZXIgRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL2FtZDY0L3N5cy9hbWQ2NF9zZXRfZ3NiYXNlLmMsdiAxLjIgMjAwNC8wMS8w OSAxNjo1MjowOSBuZWN0YXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0 L3N5cy9hbWQ2NF9nZXRfZ3NiYXNlLmMsdiAxLjIgMjAwNC8wMS8wOSAxNjo1MjowOSBuZWN0YXIg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L3N5cy9hbWQ2NF9nZXRfZnNi YXNlLmMsdiAxLjIgMjAwNC8wMS8wOSAxNjo1MjowOSBuZWN0YXIgRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL3N0ZHRpbWUvdGltZTMyLmMsdiAxLjUgMjAwMi8wNi8xNyAwMTo0Mjoy OSB3b2xsbWFuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGR0aW1lL3N0cnB0 aW1lLmMsdiAxLjM3IDIwMDkvMDkvMDIgMDQ6NTY6MzAgYWNoZSBFeHAgJAogICAgICRGcmVlQlNE OiBzcmMvY29udHJpYi90emNvZGUvc3RkdGltZS9kaWZmdGltZS5jLHYgMS4xIDIwMTAvMDIvMjUg MjE6MjE6MzQgZWR3aW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL3dz Y2FuZi5jLHYgMS4xIDIwMDIvMDkvMjMgMTI6NDA6MDYgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9zdGRpby93cHJpbnRmLmMsdiAxLjEgMjAwMi8wOS8yMSAxMzowMDozMCB0 anIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL3Z3c2NhbmYuYyx2IDEu MSAyMDAyLzA5LzIzIDEyOjQwOjA2IHRqciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xp YmMvc3RkaW8vdndwcmludGYuYyx2IDEuMSAyMDAyLzA5LzIxIDEzOjAwOjMwIHRqciBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vdnNjYW5mLmMsdiAxLjEzIDIwMDcvMDEv MDkgMDA6Mjg6MDggaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby92 cHJpbnRmLmMsdiAxLjExIDIwMDcvMDEvMDkgMDA6Mjg6MDggaW1wIEV4cCAkCiAgICAgJEZyZWVC U0Q6IHNyYy9saWIvbGliYy9zdGRpby90bXBuYW0uYyx2IDEuNiAyMDA3LzAxLzA5IDAwOjI4OjA3 IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vdG1wZmlsZS5jLHYg MS4xMCAyMDA3LzAxLzA5IDAwOjI4OjA3IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvc3RkaW8vdGVtcG5hbS5jLHYgMS4xMSAyMDA3LzAxLzA5IDAwOjI4OjA3IGltcCBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vc3dzY2FuZi5jLHYgMS4xIDIwMDIv MDkvMjMgMTI6NDA6MDYgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRp by9zd3ByaW50Zi5jLHYgMS4xIDIwMDIvMDkvMjEgMTM6MDA6MzAgdGpyIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9zZXRidWZmZXIuYyx2IDEuOCAyMDA3LzAxLzA5IDAw OjI4OjA3IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vc2NhbmYu Yyx2IDEuMTMgMjAwNy8wMS8wOSAwMDoyODowNyBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL3N0ZGlvL3JlbW92ZS5jLHYgMS45IDIwMDcvMDEvMDkgMDA6Mjg6MDcgaW1wIEV4 cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9wdXR3Y2hhci5jLHYgMS4zIDIw MDQvMDUvMjUgMTA6NDI6NTIgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9z dGRpby9wdXR3Yy5jLHYgMS4zIDIwMDQvMDUvMjUgMTA6NDI6NTIgdGpyIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9wdXR3LmMsdiAxLjEwIDIwMDcvMDEvMDkgMDA6Mjg6 MDcgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9wdXRjaGFyLmMs diAxLjE2IDIwMDgvMDUvMDUgMTY6MDM6NTIgamhiIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9zdGRpby9nZXR3Y2hhci5jLHYgMS4zIDIwMDQvMDUvMjUgMTA6NDI6NTIgdGpyIEV4 cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9nZXR3Yy5jLHYgMS4zIDIwMDQv MDUvMjUgMTA6NDI6NTIgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRp by9nZXR3LmMsdiAxLjggMjAwNy8wMS8wOSAwMDoyODowNiBpbXAgRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL3N0ZGlvL2dldHMuYyx2IDEuMTcgMjAwNy8wMS8wOSAwMDoyODowNiBp bXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL2dldGxpbmUuYyx2IDEu MSAyMDA5LzAyLzI4IDA2OjAwOjU4IGRhcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xp YmMvc3RkaW8vZ2V0ZGVsaW0uYyx2IDEuMyAyMDA5LzEwLzA0IDE5OjQzOjM2IGRhcyBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vZ2V0Y2hhci5jLHYgMS4xNSAyMDA4LzA1 LzA1IDE2OjAzOjUyIGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8v ZndzY2FuZi5jLHYgMS4xIDIwMDIvMDkvMjMgMTI6NDA6MDYgdGpyIEV4cCAkCiAgICAgJEZyZWVC U0Q6IHNyYy9saWIvbGliYy9zdGRpby9md3ByaW50Zi5jLHYgMS4xIDIwMDIvMDkvMjEgMTM6MDA6 MzAgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9md2lkZS5jLHYg MS4yIDIwMDgvMDQvMTcgMjI6MTc6NTQgamhiIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9zdGRpby9mc2V0cG9zLmMsdiAxLjkgMjAwNy8wMS8wOSAwMDoyODowNiBpbXAgRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL2ZyZW9wZW4uYyx2IDEuMjEgMjAwOC8w NC8xNyAyMjoxNzo1NCBqaGIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlv L2ZwdXR3cy5jLHYgMS44IDIwMDkvMDEvMTUgMTg6NTM6NTIgcmRpdmFja3kgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL2ZwdXJnZS5jLHYgMS4xMSAyMDA3LzAxLzA5IDAw OjI4OjA2IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vZmdldHdz LmMsdiAxLjggMjAwOS8xMS8yNSAwNDo0NTo0NSB3b2xsbWFuIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9zdGRpby9mZ2V0d2xuLmMsdiAxLjIgMjAwNC8wOC8wNiAxNzowMDowOSB0 anIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL2ZnZXRwb3MuYyx2IDEu MTMgMjAwNy8wMS8wOSAwMDoyODowNiBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL3N0ZGlvL2ZnZXRjLmMsdiAxLjEzIDIwMDcvMDEvMDkgMDA6Mjg6MDYgaW1wIEV4cCAkCiAg ICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9mY2xvc2VhbGwuYyx2IDEuMiAyMDA2LzA0 LzIyIDE2OjQ3OjU5IGRlaXNjaGVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9z dGRpby9kcHJpbnRmLmMsdiAxLjEgMjAwOS8wMy8wNCAwMzozODo1MSBkYXMgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL2NscmVyci5jLHYgMS4xMiAyMDA4LzA1LzA1IDE2 OjAzOjUyIGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcmVzb2x2L2hlcnJv ci5jLHYgMS40IDIwMDcvMDYvMDMgMTc6MjA6MjcgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9yZWdleC9yZWdlcnJvci5jLHYgMS4xMSAyMDA3LzA2LzExIDAzOjA1OjU0IGRl bHBoaWogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Bvc2l4MWUvbWFjX3NldC5j LHYgMS40IDIwMDgvMDMvMDcgMTU6MjU6NTYgcndhdHNvbiBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvcG9zaXgxZS9tYWNfZ2V0LmMsdiAxLjYgMjAwOC8wMy8wNyAxNToyNTo1NiBy d2F0c29uIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9wb3NpeDFlL21hY19leGVj LmMsdiAxLjMgMjAwOC8wMy8wNyAxNToyNTo1NiByd2F0c29uIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9wb3NpeDFlL21hYy5jLHYgMS4xMyAyMDA4LzAzLzA3IDE1OjI1OjU2IHJ3 YXRzb24gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Bvc2l4MWUvZXh0YXR0ci5j LHYgMS43IDIwMDUvMDkvMTIgMTk6NTI6NDEgc3RlZmFuZiBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvcG9zaXgxZS9hY2xfdG9fdGV4dC5jLHYgMS4xNCAyMDA5LzEyLzA1IDE5OjA0 OjIxIGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9wb3NpeDFlL2FjbF9zdHJp cC5jLHYgMS4zIDIwMTAvMDMvMDcgMDc6NTk6MDUgam9lbCBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvcG9zaXgxZS9hY2xfZnJvbV90ZXh0LmMsdiAxLjEzIDIwMDkvMTEvMTYgMDk6 Mjg6MjIgYnJ1ZWZmZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Bvc2l4MWUv YWNsX2RlbGV0ZS5jLHYgMS45IDIwMDkvMDUvMjIgMTU6NTY6NDMgdHJhc3ogRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL3Bvc2l4MWUvYWNsX2NvbXBhdC5jLHYgMS4yIDIwMDkvMDUv MjYgMTE6NDI6MDYgdHJhc3ogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Bvc2l4 MWUvYWNsX2NvcHkuYyx2IDEuNyAyMDA5LzA2LzI1IDEyOjQ2OjU5IHRyYXN6IEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9wb3NpeDFlL2FjbF9jYWxjX21hc2suYyx2IDEuMTEgMjAw OS8wOS8wMSAxODozMDoxNyB0cmFzeiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv bmV0L3ZhcnMuYyx2IDEuMyAyMDAyLzA0LzE5IDA0OjQ2OjIwIHN1eiBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMvbmV0L3NvdXJjZWZpbHRlci5jLHYgMS41IDIwMDkvMDQvMjkgMDk6 NTg6MzEgYm1zIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQvc2N0cF9zeXNf Y2FsbHMuYyx2IDEuMTUgMjAxMC8wMS8zMSAyMTo0NzozOSBicnVjZWMgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL3N5cy9uZXRpbmV0L3NjdHBfdWlvLmgsdiAxLjQ2IDIwMTAvMDEvMjIgMDc6NTM6 NDEgdHVleGVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9zeXMvbmV0aW5ldC9zY3RwLmgsdiAx LjI5IDIwMDkvMDYvMTcgMTI6MzQ6NTYgcnJzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9zeXMv bmV0aW5ldC9zY3RwX3Vpby5oLHYgMS40NiAyMDEwLzAxLzIyIDA3OjUzOjQxIHR1ZXhlbiBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L3J0aGRyLmMsdiAxLjkgMjAwNy8wNC8x OSAxNTo0ODoxNiBtdG0gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL25ldC9yZWN2 LmMsdiAxLjQgMjAwNy8wMS8wOSAwMDoyODowMiBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL25ldC9yY21kLmMsdiAxLjQyIDIwMDcvMDEvMDkgMDA6Mjg6MDIgaW1wIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQvbnNzX2NvbXBhdC5jLHYgMS4zIDIwMDQv MDMvMzAgMTU6NTY6MTUgbmVjdGFyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9u ZXQvbnRvaC5jLHYgMS4xIDIwMDYvMTEvMDYgMjI6MDc6NDcgY29nbmV0IEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQvbGlua2FkZHIuYyx2IDEuNCAyMDA3LzAxLzA5IDAwOjI4 OjAyIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L2lwNm9wdC5jLHYg MS45IDIwMDkvMTEvMTEgMTU6MjE6MDYgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9uZXQvaWZfbmFtZWluZGV4LmMsdiAxLjEgMjAwMi8wNy8xNSAxOTo1ODo1NiB1bWUgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL25ldC9pZl9pbmRleHRvbmFtZS5jLHYgMS4x IDIwMDIvMDcvMTUgMTk6NTg6NTYgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9uZXQvZ2V0cHJvdG9uYW1lLmMsdiAxLjcgMjAwNy8wMS8wOSAwMDoyODowMiBpbXAgRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL25ldC9nZXRwcm90by5jLHYgMS43IDIwMDcvMDEv MDkgMDA6Mjg6MDIgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQvZ2V0 aWZtYWRkcnMuYyx2IDEuMiAyMDA1LzA0LzA4IDIxOjI0OjIzIHN0ZWZhbmYgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL25ldC9ldWk2NC5jLHYgMS4yIDIwMDQvMDYvMDEgMTk6MzA6 MTMgYnJvb2tzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQvZXRoZXJfYWRk ci5jLHYgMS4xNyAyMDA3LzA1LzEzIDEzOjU3OjQ0IHJ3YXRzb24gRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL2xvY2FsZS93Y3dpZHRoLmMsdiAxLjggMjAwNy8wMS8wOSAwMDoyODow MSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS93Y3RyYW5zLmMs diAxLjMgMjAwMy8xMS8wMSAwODoyMDo1OCB0anIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xp Yi9saWJjL2xvY2FsZS93Y3RvbWIuYyx2IDEuOCAyMDA0LzA3LzI5IDA2OjE4OjQwIHRqciBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbG9jYWxlL3djc3RvdWxsLmMsdiAxLjIgMjAw Ny8wMS8wOSAwMDoyODowMSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xv Y2FsZS93Y3N0b3VsLmMsdiAxLjIgMjAwNy8wMS8wOSAwMDoyODowMSBpbXAgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS93Y3N0b21icy5jLHYgMS4xMSAyMDA5LzAxLzE1 IDE4OjUzOjUyIHJkaXZhY2t5IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9sb2Nh bGUvd2NzdG9sbC5jLHYgMS4yIDIwMDcvMDEvMDkgMDA6Mjg6MDEgaW1wIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9sb2NhbGUvd2NzdG9sLmMsdiAxLjIgMjAwNy8wMS8wOSAwMDoy ODowMSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS93Y3NmdGlt ZS5jLHYgMS42IDIwMDkvMDEvMTUgMjA6NDU6NTkgcmRpdmFja3kgRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL2xvY2FsZS9ycG1hdGNoLmMsdiAxLjEgMjAwNS8wMS8wOSAwMzo1NTox MyB0anIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS9ub21hY3Jvcy5j LHYgMS41IDIwMDIvMDMvMjIgMjE6NTI6MTggb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9sb2NhbGUvbmxfbGFuZ2luZm8uYyx2IDEuMTggMjAwOS8xMC8wNSAwNzoxMzox NSBlZHdpbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbG9jYWxlL25leHR3Y3R5 cGUuYyx2IDEuMSAyMDA0LzA3LzA4IDA2OjQzOjM3IHRqciBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvbG9jYWxlL21ic3Rvd2NzLmMsdiAxLjEyIDIwMDkvMDEvMTUgMTg6NTM6NTIg cmRpdmFja3kgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS9tYnRvd2Mu Yyx2IDEuMTEgMjAwNC8wNy8yOSAwNjoxODo0MCB0anIgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL2xvY2FsZS9tYnNpbml0LmMsdiAxLjMgMjAwNC8wNS8xMiAxNDowOTowNCB0anIg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS9tYmxlbi5jLHYgMS45IDIw MDQvMDcvMjkgMDY6MTg6NDAgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9s b2NhbGUvaXN3Y3R5cGUuYyx2IDEuOSAyMDA3LzEwLzIzIDE3OjM5OjI4IGFjaGUgRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2luZXQvaW5ldF9uZXRvZi5jLHYgMS40IDIwMDcvMDYv MDMgMTc6MjA6MjYgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9pbmV0L2lu ZXRfbmV0YS5jLHYgMS4zIDIwMDcvMDYvMDMgMTc6MjA6MjYgdW1lIEV4cCAkCiAgICAgJEZyZWVC U0Q6IHNyYy9saWIvbGliYy9pbmV0L2luZXRfbmV0X3B0b24uYyx2IDEuNCAyMDA4LzEyLzE0IDE5 OjM5OjUzIHVtZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvaW5ldC9pbmV0X25l dF9udG9wLmMsdiAxLjQgMjAwNy8wNi8wMyAxNzoyMDoyNiB1bWUgRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL2luZXQvaW5ldF9tYWtlYWRkci5jLHYgMS40IDIwMDcvMDYvMDMgMTc6 MjA6MjYgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9pbmV0L2luZXRfbG5h b2YuYyx2IDEuNCAyMDA3LzA2LzAzIDE3OjIwOjI2IHVtZSBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvaW5ldC9pbmV0X2NpZHJfcHRvbi5jLHYgMS4zIDIwMDcvMDYvMDMgMTc6MjA6 MjYgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nbW9uL21jb3VudC5jLHYg MS4yMiAyMDA3LzAxLzA5IDAwOjI3OjU4IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvZ21vbi9nbW9uLmMsdiAxLjIzIDIwMDkvMTIvMDUgMTk6MzE6MzggZWQgRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L2dlbi9zaWduYWxjb250ZXh0LmMsdiAxLjUg MjAwNC8wNy8yOCAxMzowODoyNCBkYXZpZHh1IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9hbWQ2NC9nZW4vbWFrZWNvbnRleHQuYyx2IDEuNCAyMDA0LzA3LzMxIDAxOjQxOjQxIGRh dmlkeHUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L2dlbi9pbmZpbml0 eS5jLHYgMS4xMCAyMDAzLzAyLzA4IDIwOjM3OjUyIG1pa2UgRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL2FtZDY0L2dlbi9tb2RmLlMsdiAxLjQgMjAwOC8xMS8wMiAwMToxMDo1NCBw ZXRlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvYW1kNjQvZ2VuL2ZhYnMuUyx2 IDEuNCAyMDA4LzExLzAyIDAxOjEwOjU0IHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9hbWQ2NC9nZW4vc2lnc2V0am1wLlMsdiAxLjMwIDIwMDgvMTEvMDIgMDE6MTA6NTQg cGV0ZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L2dlbi9zZXRqbXAu Uyx2IDEuMjkgMjAwOC8xMS8wMiAwMToxMDo1NCBwZXRlciBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvYW1kNjQvZ2VuL3Jmb3JrX3RocmVhZC5TLHYgMS4yIDIwMDgvMTEvMDIgMDE6 MTA6NTQgcGV0ZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L2dlbi9f c2V0am1wLlMsdiAxLjIxIDIwMDgvMTEvMDIgMDE6MTA6NTQgcGV0ZXIgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2xpYi9saWJjL2dlbi93b3JkZXhwLmMsdiAxLjggMjAwOS8xMS8yNSAwNDo0NTo0 NSB3b2xsbWFuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vd2FpdHBpZC5j LHYgMS43IDIwMDcvMDEvMDkgMDA6Mjc6NTYgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9nZW4vd2FpdDMuYyx2IDEuNCAyMDA3LzAxLzA5IDAwOjI3OjU2IGltcCBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL3ZhbGxvYy5jLHYgMS41IDIwMDcvMDEvMDkg MDA6Mjc6NTYgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vdXRpbWUu Yyx2IDEuMyAyMDA3LzAxLzA5IDAwOjI3OjU2IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvZ2VuL3VudmlzLmMsdiAxLjEwIDIwMDcvMDEvMDkgMDA6Mjc6NTYgaW1wIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vdW5hbWUuYyx2IDEuMTIgMjAxMC8wMS8x OSAyMzowNzoxMiBlZCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL3VhbGFy bS5jLHYgMS41IDIwMDcvMDEvMDkgMDA6Mjc6NTYgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9nZW4vdHR5c2xvdC5jLHYgMS44IDIwMTAvMDEvMTcgMTU6NDM6MTQgZWQgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi90dHluYW1lLmMsdiAxLjI1IDIwMDkv MDIvMTEgMjA6MjQ6NTkgZWQgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi90 aW1lem9uZS5jLHYgMS43IDIwMDkvMTIvMDUgMTk6MzE6MzggZWQgRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL2dlbi90aW1lcy5jLHYgMS40IDIwMDcvMDEvMDkgMDA6Mjc6NTUgaW1w IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vc3RydG9mZmxhZ3MuYyx2IDEu MjQgMjAwNy8wMS8wOSAwMDoyNzo1NSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL2dlbi9zdGF0dmZzLmMsdiAxLjIgMjAwMi8wOS8wNiAxMToyMzo0MCB0anIgRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9zbGVlcC5jLHYgMS4zMyAyMDA5LzEyLzA1IDE5 OjMxOjM4IGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vc2lnaW50ZXJy dXB0LmMsdiAxLjUgMjAwNy8wMS8wOSAwMDoyNzo1NSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL2dlbi9zZXRwcm9nbmFtZS5jLHYgMS44IDIwMDIvMDMvMjkgMjI6NDM6NDEg bWFya20gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9zZXRwcm9jdGl0bGUu Yyx2IDEuMTggMjAwMy8wNy8wMSAwOTo0NTozNSBhbGZyZWQgRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL2dlbi9zZXRtb2RlLmMsdiAxLjExIDIwMDcvMDEvMDkgMDA6Mjc6NTUgaW1w IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vc2V0am1wZXJyLmMsdiAxLjYg MjAwNy8wMS8wOSAwMDoyNzo1NSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJj L2dlbi9zZXRob3N0bmFtZS5jLHYgMS42IDIwMDcvMDEvMDkgMDA6Mjc6NTUgaW1wIEV4cCAkCiAg ICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vc2V0ZG9tYWlubmFtZS5jLHYgMS44IDIwMDcv MDEvMDkgMDA6Mjc6NTUgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4v c2VtY3RsLmMsdiAxLjEwIDIwMDkvMDYvMjQgMjE6MTA6NTIgamhiIEV4cCAkCiAgICAgJEZyZWVC U0Q6IHNyYy9saWIvbGliYy9nZW4vc2Vla2Rpci5jLHYgMS43IDIwMDcvMTIvMDMgMTQ6MzM6NTEg ZGVzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vc2VlZDQ4LmMsdiAxLjIg MjAwMi8wMy8yMiAyMTo1MjowNSBvYnJpZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL2dlbi9zY2FuZGlyLmMsdiAxLjE0IDIwMTAvMDEvMjAgMTE6NTk6NDYgYWNoZSBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL3Jld2luZGRpci5jLHYgMS42IDIwMDcvMDEv MDkgMDA6Mjc6NTUgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vcmVh ZHBhc3NwaHJhc2UuYyx2IDEuNiAyMDAyLzAzLzA5IDAzOjE2OjQxIGdyZWVuIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vcHdjYWNoZS5jLHYgMS4xMiAyMDA5LzEyLzA1IDE5 OjA0OjIxIGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vcHV0dXR4bGlu ZS5jLHYgMS41IDIwMTAvMDEvMjMgMDg6NDM6MjEgZWQgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL2dlbi9wc2lnbmFsLmMsdiAxLjggMjAwNy8wMS8wOSAwMDoyNzo1NCBpbXAgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9wb3NpeF9zcGF3bi5jLHYgMS42IDIw MDgvMTAvMjMgMTU6MzI6MDYgcmRpdmFja3kgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL2dlbi9wb3Blbi5jLHYgMS4yMSAyMDA5LzA1LzI3IDE5OjI4OjA0IGVkIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vcG1hZHZpc2UuYyx2IDEuMyAyMDAzLzA4LzA5IDAz OjIzOjI0IGJtcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL3BhdXNlLmMs diAxLjkgMjAxMC8wMi8yNSAxMzo1MToxMSBraWIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xp Yi9saWJjL2dlbi9ucmFuZDQ4LmMsdiAxLjIgMjAwMi8wMy8yMiAyMTo1MjowNSBvYnJpZW4gRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9ubGlzdC5jLHYgMS4yMSAyMDA5LzEy LzA1IDE5OjMxOjM4IGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vbmlj ZS5jLHYgMS40IDIwMDcvMDEvMDkgMDA6Mjc6NTQgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9nZW4vbmZ0dy5jLHYgMS4xIDIwMDQvMDgvMjQgMTM6MDA6NTUgdGpyIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vbXJhbmQ0OC5jLHYgMS4yIDIwMDIvMDMv MjIgMjE6NTI6MDUgb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4v bHJhbmQ0OC5jLHYgMS4yIDIwMDIvMDMvMjIgMjE6NTI6MDUgb2JyaWVuIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vbG9ja2YuYyx2IDEuMTAgMjAwOS8wMy8wNCAwMTowMToy NiBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vbGNvbmc0OC5j LHYgMS4yIDIwMDIvMDMvMjIgMjE6NTI6MDUgb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9nZW4vanJhbmQ0OC5jLHYgMS4yIDIwMDIvMDMvMjIgMjE6NTI6MDUgb2JyaWVu IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vaW5pdGdyb3Vwcy5jLHYgMS4x MCAyMDA5LzA2LzE5IDE1OjU4OjI0IGJyb29rcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvZ2VuL2dsb2IuYyx2IDEuMjcgMjAwOC8wNi8yNiAwNzoxMjozNSBtdG0gRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9nZXR2ZnNieW5hbWUuYyx2IDEuMTEgMjAwNy8w MS8wOSAwMDoyNzo1NCBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9n ZXR1dHhlbnQuYyx2IDEuMyAyMDEwLzAxLzE3IDIxOjQwOjA1IGVkIEV4cCAkCiAgICAgJEZyZWVC U0Q6IHNyYy9saWIvbGliYy9nZW4vZ2V0dHR5ZW50LmMsdiAxLjIwIDIwMTAvMDEvMjcgMTE6NTQ6 NDIgZWQgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9nZXRvc3JlbGRhdGUu Yyx2IDEuOSAyMDA3LzAxLzA5IDAwOjI3OjU0IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvZ2VuL2dldG1udGluZm8uYyx2IDEuNSAyMDA3LzAxLzA5IDAwOjI3OjU0IGltcCBF eHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2dldGxvZ2luLmMsdiAxLjExIDIw MDkvMTIvMDUgMTk6MDQ6MjEgZWQgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dl bi9nZXRsb2FkYXZnLmMsdiAxLjMgMjAwNy8wMS8wOSAwMDoyNzo1NCBpbXAgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9nZXRncm91cGxpc3QuYyx2IDEuMTYgMjAwNy8xMi8x MiAxMDowODowMiBidXNobWFuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4v Z2V0YnNpemUuYyx2IDEuOSAyMDA4LzA4LzA0IDA2OjUzOjEzIGNwZXJjaXZhIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vZ2V0Ym9vdGZpbGUuYyx2IDEuOSAyMDA3LzAxLzA5 IDAwOjI3OjUzIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2Z0dy5j LHYgMS40IDIwMDQvMDgvMjQgMTM6MDA6NTUgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9nZW4vZnRzLWNvbXBhdC5jLHYgMS4zMCAyMDA4LzAxLzI2IDE3OjA5OjQwIHlhciBF eHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2Z0cy5jLHYgMS4zMiAyMDA5LzEx LzI2IDE5OjExOjQ0IGpoIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vZnRv ay5jLHYgMS43IDIwMDQvMDYvMDEgMDY6NTM6MDcgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9nZW4vZnN0YWIuYyx2IDEuMTUgMjAwNy8wMS8wOSAwMDoyNzo1MyBpbXAgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9mbm1hdGNoLmMsdiAxLjE4IDIwMDcv MDEvMDkgMDA6Mjc6NTMgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4v Zm10bXNnLmMsdiAxLjYgMjAwOS8xMS8wOCAxNDowMjo1NCBicnVlZmZlciBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2ZtdGNoZWNrLmMsdiAxLjEwIDIwMDkvMDYvMjMgMjM6 NTI6MTIgZGVscGhpaiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2ZlYXR1 cmVfcHJlc2VudC5jLHYgMS4xIDIwMDgvMDEvMTAgMjI6MTE6MjEgamhiIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vZmRldm5hbWUuYyx2IDEuMiAyMDA5LzEyLzA1IDE4OjUx OjQ0IGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vZXJybm8uYyx2IDEu MSAyMDAyLzEwLzA5IDA4OjA0OjI0IHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9nZW4vZHJhbmQ0OC5jLHYgMS4yIDIwMDIvMDMvMjIgMjE6NTI6MDUgb2JyaWVuIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vZGlza2xhYmVsLmMsdiAxLjE3IDIwMDcv MDEvMDkgMDA6Mjc6NTMgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4v ZGlybmFtZS5jLHYgMS44IDIwMDgvMTEvMDMgMDU6MTk6NDUgZGVscGhpaiBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2Rldm5hbWUuYyx2IDEuMTIgMjAxMC8wMS8zMSAxNDo1 MTowNCBlZCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2RhZW1vbi5jLHYg MS44IDIwMDcvMDEvMDkgMDA6Mjc6NTMgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9nZW4vY3Rlcm1pZC5jLHYgMS40IDIwMDcvMDEvMDkgMDA6Mjc6NTMgaW1wIEV4cCAkCiAg ICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vY3J5cHQuYyx2IDEuOSAyMDA3LzAxLzA5IDAw OjI3OjUzIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2NvbmZzdHIu Yyx2IDEuMTAgMjAwNy8wMS8wOSAwMDoyNzo1MyBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL2dlbi9jbG9jay5jLHYgMS40IDIwMDcvMDEvMDkgMDA6Mjc6NTMgaW1wIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vY2hlY2tfdXRpbGl0eV9jb21wYXQuYyx2 IDEuMyAyMDAzLzA1LzAxIDE5OjAzOjEzIG5lY3RhciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvZ2VuL2Jhc2VuYW1lLmMsdiAxLjggMjAwOS8xMC8wNiAxNDowNTo1NyByd2F0c29u IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vX3RocmVhZF9pbml0LmMsdiAx LjUgMjAwMi8wMi8wMSAwMDo1NzoyOSBvYnJpZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xp Yi9saWJjL2NvbXBhdC00My9zaWdjb21wYXQuYyx2IDEuMTIgMjAwOS8xMS8yNiAxMzo0OTozNyBr aWIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2NvbXBhdC00My9zZXRydWlkLmMs diAxLjQgMjAwNy8wMS8wOSAwMDoyNzo0OSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xp Yi9saWJjL2NvbXBhdC00My9zZXRyZ2lkLmMsdiAxLjQgMjAwNy8wMS8wOSAwMDoyNzo0OSBpbXAg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2NvbXBhdC00My9zZXRwZ3JwLmMsdiAx LjUgMjAwNy8wMS8wOSAwMDoyNzo0OSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL2NvbXBhdC00My9zZXRob3N0aWQuYyx2IDEuNSAyMDA3LzAxLzA5IDAwOjI3OjQ5IGltcCBF eHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvY29tcGF0LTQzL2tpbGxwZy5jLHYgMS41 IDIwMDcvMDEvMDkgMDA6Mjc6NDkgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9jb21wYXQtNDMvZ2V0d2QuYyx2IDEuNiAyMDA3LzAxLzA5IDAwOjI3OjQ5IGltcCBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvY29tcGF0LTQzL2dldGhvc3RpZC5jLHYgMS41IDIw MDcvMDEvMDkgMDA6Mjc6NDkgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9j b21wYXQtNDMvY3JlYXQuYyx2IDEuOCAyMDA3LzAxLzA5IDAwOjI3OjQ5IGltcCBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZGIvbXBvb2wvbXBvb2wtY29tcGF0LmMsdiAxLjEgMjAw OS8wMy8yOCAwNzozMTowMiBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9kYi9oYXNoL25kYm0uYyx2IDEuNyAyMDA3LzAxLzA5IDAwOjI3OjUxIGltcCBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZGIvYnRyZWUvYnRfZGVidWcuYyx2IDEuNyAyMDA5LzAz LzI4IDA3OjMxOjAyIGRlbHBoaWogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N5 cy90cnVuY2F0ZS5jLHYgMS41IDIwMDcvMDcvMDQgMjM6Mjc6MzggcGV0ZXIgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL3N5cy9mY250bC5jLHYgMS4zIDIwMDgvMDUvMzAgMTQ6NDc6 NDAgZGZyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvd21lbWNweS5j LHYgMS44IDIwMDkvMDIvMDMgMTc6NTg6MjAgZGFuZ2VyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9zdGRsaWIvc3RydG9sbC5jLHYgMS4yMiAyMDA3LzAxLzA5IDAwOjI4OjEwIGlt cCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL3Fzb3J0LmMsdiAxLjE1 IDIwMDgvMDEvMTQgMDk6MjE6MzQgZGFzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9ycGMvcG1hcF9wcm90Mi5jLHYgMS4xMCAyMDA0LzEwLzE2IDA2OjExOjM1IG9icmllbiBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvYW1kNjQvc3lzL3BpcGUuUyx2IDEuMTUgMjAw OC8xMS8wMiAwMToxMDo1NCBwZXRlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv YW1kNjQvc3lzL3Zmb3JrLlMsdiAxLjI0IDIwMDgvMTEvMDIgMDE6MTA6NTQgcGV0ZXIgRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L3N5cy9hbWQ2NF9zZXRfZnNiYXNlLmMs diAxLjIgMjAwNC8wMS8wOSAxNjo1MjowOSBuZWN0YXIgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL3N0ZGlvL3Zzd3NjYW5mLmMsdiAxLjcgMjAxMC8wMy8xMSAxNzowMzozMiBqaGIg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL3Zzd3ByaW50Zi5jLHYgMS44 IDIwMTAvMDMvMTEgMTc6MDM6MzIgamhiIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9zdGRpby92ZndzY2FuZi5jLHYgMS4xNyAyMDA5LzAxLzE5IDA2OjE5OjUxIGRhcyBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vdmZ3cHJpbnRmLmMsdiAxLjQyIDIwMDkv MTEvMjUgMDQ6Mjc6NTUgd29sbG1hbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv c3RkaW8vdmRwcmludGYuYyx2IDEuMiAyMDEwLzAzLzExIDE3OjAzOjMyIGpoYiBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vdW5nZXR3Yy5jLHYgMS4xMSAyMDA4LzA0LzE3 IDIyOjE3OjU0IGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vZnB1 dHdjLmMsdiAxLjExIDIwMDgvMDQvMTcgMjI6MTc6NTMgamhiIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9zdGRpby9mZ2V0d2MuYyx2IDEuMTMgMjAwOC8wNC8xNyAyMjoxNzo1MyBq aGIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL2Zlb2YuYyx2IDEuMTIg MjAwOC8wNS8wNSAxNjowMzo1MiBqaGIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJj L3JlZ2V4L3JlZ2V4ZWMuYyx2IDEuOCAyMDA3LzA2LzExIDAzOjA1OjU0IGRlbHBoaWogRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JlZ2V4L2VuZ2luZS5jLHYgMS4yMyAyMDA5LzA5 LzE2IDA2OjMyOjIzIGRkcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcmVnZXgv ZW5naW5lLmMsdiAxLjIzIDIwMDkvMDkvMTYgMDY6MzI6MjMgZGRzIEV4cCAkCiAgICAgJEZyZWVC U0Q6IHNyYy9saWIvbGliYy9yZWdleC9lbmdpbmUuYyx2IDEuMjMgMjAwOS8wOS8xNiAwNjozMjoy MyBkZHMgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JlZ2V4L3JlZ2NvbXAuYyx2 IDEuMzYgMjAwNy8wNi8xMSAwMzowNTo1NCBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9wb3NpeDFlL2FjbF92YWxpZC5jLHYgMS4xMiAyMDA5LzA2LzI1IDEyOjQ2OjU5 IHRyYXN6IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9wb3NpeDFlL2FjbF90b190 ZXh0X25mczQuYyx2IDEuMiAyMDA5LzA2LzI1IDEzOjA4OjAyIHRyYXN6IEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9wb3NpeDFlL2FjbF9wZXJtLmMsdiAxLjcgMjAwOC8xMS8wNCAw MDoyMDo0MyBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Bvc2l4MWUvYWNs X2Zyb21fdGV4dF9uZnM0LmMsdiAxLjIgMjAwOS8wNi8yNSAxMzowODowMiB0cmFzeiBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcG9zaXgxZS9hY2xfZmxhZy5jLHYgMS4yIDIwMDkv MDYvMjUgMTM6MDg6MDIgdHJhc3ogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Bv c2l4MWUvYWNsX2VudHJ5LmMsdiAxLjEwIDIwMDkvMDYvMjUgMTI6NDY6NTkgdHJhc3ogRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Bvc2l4MWUvYWNsX2RlbGV0ZV9lbnRyeS5jLHYg MS45IDIwMDkvMTIvMjUgMTg6MDU6MDYgbWFya3VzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9uZXQvcmNtZHNoLmMsdiAxLjUgMjAwMy8wMi8yNyAxMzo0MDowMCBuZWN0YXIgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL25ldC9nYWlfc3RyZXJyb3IuYyx2IDEuMyAy MDA5LzExLzA5IDEyOjQ2OjU5IHVtZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv bG9jYWxlL3djdHlwZS5jLHYgMS40IDIwMDgvMDMvMTcgMTg6MjI6MjMgYW50b2luZSBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbG9jYWxlL3djc3RvdW1heC5jLHYgMS4yIDIwMDcv MDEvMDkgMDA6Mjg6MDEgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9sb2Nh bGUvd2NzdG9sZC5jLHYgMS40IDIwMDQvMDQvMDcgMDk6NDc6NTYgdGpyIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9sb2NhbGUvd2NzdG9pbWF4LmMsdiAxLjMgMjAwNy8wMS8wOSAw MDoyODowMSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS93Y3N0 b2QuYyx2IDEuNCAyMDA0LzA0LzA3IDA5OjQ3OjU2IHRqciBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvbG9jYWxlL3djc3RvZi5jLHYgMS4zIDIwMDQvMDQvMDcgMDk6NDc6NTYgdGpy IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9sb2NhbGUvdG91cHBlci5jLHYgMS4x MyAyMDA3LzAxLzA5IDAwOjI4OjAxIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xp YmMvbG9jYWxlL3RvbG93ZXIuYyx2IDEuMTMgMjAwNy8wMS8wOSAwMDoyODowMSBpbXAgRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS9tYnNydG93Y3MuYyx2IDEuNiAyMDA0 LzA3LzIxIDEwOjU0OjU3IHRqciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbG9j YWxlL21icmxlbi5jLHYgMS40IDIwMDQvMDUvMTIgMTQ6MjY6NTQgdGpyIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9sb2NhbGUvYnRvd2MuYyx2IDEuNCAyMDA0LzA1LzEyIDE0OjI2 OjU0IHRqciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL3dhaXQuYyx2IDEu NyAyMDA3LzAxLzA5IDAwOjI3OjU2IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xp YmMvZ2VuL3V0eGRiLmMsdiAxLjQgMjAxMC8wMS8yMyAwODo0MzoyMSBlZCBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL3NpZ2xpc3QuYyx2IDEuNiAyMDA3LzAxLzIwIDA4OjI0 OjAxIG1heGltIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vZ2V0Y3dkLmMs diAxLjMwIDIwMDkvMTAvMTMgMjA6NTg6MjIgamlsbGVzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9nZW4vZ2V0Y2FwLmMsdiAxLjIzIDIwMDkvMTEvMjUgMDQ6NDU6NDUgd29sbG1h biBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2V4ZWMuYyx2IDEuMjcgMjAw OS8xMi8wNSAxODo1NToxNiBlZCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2Vu L2VyYW5kNDguYyx2IDEuMiAyMDAyLzAzLzIyIDIxOjUyOjA1IG9icmllbiBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2Nsb3NlZGlyLmMsdiAxLjEzIDIwMDcvMTIvMDMgMTQ6 MzM6NTAgZGVzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vX3JhbmQ0OC5j LHYgMS4yIDIwMDIvMDMvMjIgMjE6NTI6MDUgb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9zdHJpbmcvd21lbWNoci5jLHYgMS43IDIwMDkvMDIvMDMgMTc6NTg6MjAgZGFu Z2VyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvd2Nzbmxlbi5jLHYg MS4xIDIwMDkvMDIvMjggMDY6MDA6NTggZGFzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9zdHJpbmcvd2NzbGVuLmMsdiAxLjcgMjAwOS8wMi8wMyAxNzo1ODoyMCBkYW5nZXIgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JlZ2V4L3JlZ2ZyZWUuYyx2IDEuOCAyMDA3 LzA2LzExIDAzOjA1OjU0IGRlbHBoaWogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJj L3Bvc2l4MWUvYWNsX3N1cHBvcnRfbmZzNC5jLHYgMS4yIDIwMDkvMDYvMjUgMTM6MDg6MDIgdHJh c3ogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Bvc2l4MWUvYWNsX3NldC5jLHYg MS4xNSAyMDA5LzA2LzI1IDIwOjU3OjUzIHRyYXN6IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9wb3NpeDFlL2FjbF9nZXQuYyx2IDEuMTUgMjAwOS8wNi8yNSAyMDo1Nzo1MyB0cmFz eiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcG9zaXgxZS9hY2xfZnJlZS5jLHYg MS41IDIwMDIvMDMvMjIgMjE6NTI6Mzggb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9hbWQ2NC9nZW4vbGRleHAuYyx2IDEuMTQgMjAwNy8wMS8wOSAwMDozODoyNCBpbXAg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9vcGVuZGlyLmMsdiAxLjMwIDIw MTAvMDEvMjAgMDc6MzY6MjkgYWNoZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv c3RkbGliL21lcmdlLmMsdiAxLjggMjAwNy8wMS8wOSAwMDoyODoxMCBpbXAgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL3Bvc2l4MWUvYWNsX3N1cHBvcnQuYyx2IDEuMTggMjAwOS8w OC8yOSAwMzoxNzoyNCBraWVudHpsZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv cG9zaXgxZS9hY2xfaW5pdC5jLHYgMS4xMiAyMDA5LzA2LzI1IDEyOjQ2OjU5IHRyYXN6IEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9wb3NpeDFlL2FjbF9icmFuZGluZy5jLHYgMS4y IDIwMDkvMDYvMjUgMTM6MDg6MDIgdHJhc3ogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL2dlbi90ZWxsZGlyLmMsdiAxLjExIDIwMDgvMDUvMDUgMTQ6MDU6MjMga2liIEV4cCAkCiAg ICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vcmVhZGRpci5jLHYgMS4xNSAyMDA4LzA1LzA1 IDE0OjA1OjIzIGtpYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0 cmVycm9yLmMsdiAxLjE2IDIwMDcvMDEvMDkgMDA6Mjg6MTIgaW1wIEV4cCAkCiAgICAgJEZyZWVC U0Q6IHNyYy9saWIvbGliYy9ubHMvbXNnY2F0LmMsdiAxLjU1IDIwMTAvMDIvMjAgMDg6MTk6MTkg Z2Fib3IgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS9zZXRsb2NhbGUu Yyx2IDEuNTEgMjAwNy8wMS8wOSAwMDoyODowMCBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL2xvY2FsZS9sbWVzc2FnZXMuYyx2IDEuMTQgMjAwMy8wNi8yNiAxMDo0NjoxNiBw aGFudG9tIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vZXJybHN0LmMsdiAx LjEwIDIwMDkvMTAvMDcgMjA6MjA6NTEgcndhdHNvbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvbG9jYWxlL3NldHJ1bmVsb2NhbGUuYyx2IDEuNTEgMjAwOC8wMS8yMyAwMzowNToz NSBhY2hlIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9sb2NhbGUvcnVuZS5jLHYg MS4xNSAyMDA3LzAxLzA5IDAwOjI4OjAwIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvbG9jYWxlL21za2FuamkuYyx2IDEuMTggMjAwNy8xMC8xMyAxNjoyODoyMiBhY2hlIEV4 cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9sb2NhbGUvbWJzbnJ0b3djcy5jLHYgMS4x IDIwMDQvMDcvMjEgMTA6NTQ6NTcgdGpyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9sb2NhbGUvZ2JrLmMsdiAxLjE0IDIwMDcvMTAvMTMgMTY6Mjg6MjEgYWNoZSBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbG9jYWxlL2diMjMxMi5jLHYgMS4xMCAyMDA3LzEwLzEz IDE2OjI4OjIxIGFjaGUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS9n YjE4MDMwLmMsdiAxLjggMjAwNy8xMC8xMyAxNjoyODoyMSBhY2hlIEV4cCAkCiAgICAgJEZyZWVC U0Q6IHNyYy9saWIvbGliYy9sb2NhbGUvZXVjLmMsdiAxLjIyIDIwMDcvMTAvMTMgMTY6Mjg6MjEg YWNoZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbG9jYWxlL2JpZzUuYyx2IDEu MTggMjAwNy8xMC8xMyAxNjoyODoyMSBhY2hlIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9sb2NhbGUvYXNjaWkuYyx2IDEuMSAyMDA4LzAxLzIxIDIzOjQ4OjEyIGFjaGUgRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS93Y3NucnRvbWJzLmMsdiAxLjMgMjAw NS8wMi8xMiAwODo0NToxMiBzdGVmYW5mIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9sb2NhbGUvdXRmOC5jLHYgMS4xNiAyMDA3LzEwLzE1IDA5OjUxOjMwIGFjaGUgRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy9zdHJkdXAuYyx2IDEuNiAyMDA5LzAyLzAz IDE3OjU4OjIwIGRhbmdlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGli L3JlYWxsb2NmLmMsdiAxLjUgMjAxMC8wMy8wMyAxNTo0MzoyNiBqaCBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL21hbGxvYy5jLHYgMS4xOTMgMjAxMC8wMi8yOCAyMjo1 NzoxMyBqYXNvbmUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGxpYi9yYi5o LHYgMS41IDIwMTAvMDIvMjggMjI6NTc6MTMgamFzb25lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9zdGRsaWIvcXIuaCx2IDEuMSAyMDEwLzAxLzMxIDIzOjE2OjEwIGphc29uZSBF eHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL3FsLmgsdiAxLjEgMjAxMC8w MS8zMSAyMzoxNjoxMCBqYXNvbmUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2Ft ZDY0L3N5cy9zYnJrLlMsdiAxLjE1IDIwMDgvMTEvMDIgMDE6MTA6NTQgcGV0ZXIgRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL3ZzbnByaW50Zi5jLHYgMS4yNSAyMDEwLzAz LzExIDE3OjAzOjMyIGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2dl dHBhZ2VzaXplcy5jLHYgMS4xIDIwMDkvMDkvMTkgMTg6MDE6MzIgYWxjIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9zeXMvbW1hcC5jLHYgMS43IDIwMDcvMDcvMDQgMjM6Mjc6Mzgg cGV0ZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGxpYi9leGl0LmMsdiAx LjkgMjAwNy8wMS8wOSAwMDoyODowOSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL3lwL3lwbGliLmMsdiAxLjUyIDIwMDkvMTEvMjUgMDQ6NDU6NDUgd29sbG1hbiBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMveXAveGRyeXAuYyx2IDEuMTUgMjAwOC8wMy8yNiAw NzozMjowNiBicnVlZmZlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL2Ns bnRfcGVycm9yLmMsdiAxLjE4IDIwMDgvMDgvMDYgMTQ6MDI6MDUgZGZyIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9wZXJyb3IuYyx2IDEuOSAyMDA3LzAxLzA5IDAwOjI4 OjA3IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0cm5jYXQu Yyx2IDEuNyAyMDA3LzAxLzA5IDAwOjI4OjEyIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv aW5jbHVkZS9ycGNzdmMveXAueCx2IDEuMTMgMjAwMy8wNS8wNCAwMjo1MTo0MiBvYnJpZW4gRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9hdXRoX2Rlcy5jLHYgMS4xMCAyMDA2 LzAyLzI3IDIyOjEwOjU4IGRlaXNjaGVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9ycGMvbmV0bmFtZS5jLHYgMS45IDIwMDkvMDYvMTkgMTc6MTA6MzUgYnJvb2tzIEV4cCAkCiAg ICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9ycGMvYXV0aGRlc19wcm90LmMsdiAxLjUgMjAwNy8x MS8yMCAwMTo1MToyMCBqYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL2F1 dGhfdGltZS5jLHYgMS4xMiAyMDA3LzA5LzIwIDIyOjM1OjI0IG1hdHRlbyBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL3JwY19kdGFibGVzaXplLmMsdiAxLjE1IDIwMDQvMTAv MTYgMDY6MTE6MzUgb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9pbmV0 L2luZXRfbnRvYS5jLHYgMS42IDIwMDcvMDYvMTQgMDc6MTM6MjggZGVscGhpaiBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL3NpZ25hbC5jLHYgMS40IDIwMDcvMDEvMDkgMDA6 Mjc6NTUgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vYWxhcm0uYyx2 IDEuMyAyMDA3LzAxLzA5IDAwOjI3OjUzIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvcnBjL3JwY2JfY2xudC5jLHYgMS4xNyAyMDA3LzA5LzIwIDIyOjM1OjI0IG1hdHRlbyBF eHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL3JwY19zb2MuYyx2IDEuMTYgMjAx MC8wMy8xMCAxMzoyMzoyNSBqaGIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Jw Yy9zdmNfc2ltcGxlLmMsdiAxLjE2IDIwMDYvMDkvMDkgMjI6MzI6MDcgbWJyIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9ycGMvc3ZjX3Jhdy5jLHYgMS4xNyAyMDA5LzExLzI1IDA0 OjQ5OjQxIHdvbGxtYW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9zdmNf Z2VuZXJpYy5jLHYgMS4xMCAyMDA5LzA2LzE4IDE3OjEwOjQzIGthbiBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMvcnBjL3N2Y19kZy5jLHYgMS4xMiAyMDA5LzA2LzE4IDE3OjEwOjQz IGthbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL3BtYXBfZ2V0cG9ydC5j LHYgMS4xNSAyMDA0LzEwLzE2IDA2OjExOjM1IG9icmllbiBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvcnBjL2NsbnRfc2ltcGxlLmMsdiAxLjIxIDIwMTAvMDMvMTAgMTM6MjM6MjUg amhiIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9ycGMvY2xudF9yYXcuYyx2IDEu MjEgMjAwOS8xMS8yNSAwNDo1MjoxMiB3b2xsbWFuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9ycGMvY2xudF9iY2FzdC5jLHYgMS4xMCAyMDA5LzA0LzA5IDIwOjU3OjM1IGVtYXN0 ZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L2lmX25hbWV0b2luZGV4LmMs diAxLjUgMjAwMy8wNS8wMSAxOTowMzoxNCBuZWN0YXIgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL25ldC9nZXRpZmFkZHJzLmMsdiAxLjggMjAwOS8wOS8wOSAxMDozMToyMCBwaGsg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9zdmNfdmMuYyx2IDEuMjggMjAw OC8wOC8wNiAxNDowMjowNSBkZnIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Jw Yy9zdmMuYyx2IDEuMjcgMjAwOS8xMi8wMyAxNToxNDozMCBqaGIgRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL3JwYy9ycGNiX3Byb3QuYyx2IDEuNyAyMDA3LzExLzIwIDAxOjUxOjIw IGpiIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9ycGMvcnBjX2NhbGxtc2cuYyx2 IDEuMTMgMjAwNy8xMS8yMCAwMTo1MToyMCBqYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvcnBjL3JwY19jb21tb25kYXRhLmMsdiAxLjkgMjAwMi8wMy8yMiAyMzoxODozNyBvYnJp ZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9wbWFwX3JtdC5jLHYgMS4y MCAyMDA0LzEwLzE2IDA2OjExOjM1IG9icmllbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvcnBjL3BtYXBfcHJvdC5jLHYgMS45IDIwMDQvMTAvMTYgMDY6MTE6MzUgb2JyaWVuIEV4 cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9ycGMvcG1hcF9jbG50LmMsdiAxLjE1IDIw MDQvMTAvMTYgMDY6MTE6MzUgb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9nZW4vZ2V0cGVlcmVpZC5jLHYgMS42IDIwMDIvMTIvMTYgMTM6NDI6MTMgbWF4aW0gRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3hkci94ZHJfcmVmZXJlbmNlLmMsdiAxLjEyIDIw MDQvMTAvMTYgMDY6MzI6NDMgb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9ycGMvc3ZjX2F1dGguYyx2IDEuMTUgMjAwOC8wOS8wOSAxNDoxNTo1NSBkZnIgRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9zdmNfYXV0aF9kZXMuYyx2IDEuMTAgMjAxMC8w MS8wOSAyMzozNjo1MSBicm9va3MgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Jw Yy9nZXRwdWJsaWNrZXkuYyx2IDEuOSAyMDA2LzAyLzI4IDE2OjAyOjI2IGRlaXNjaGVuIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9pbmNsdWRlL3JwY3N2Yy9rZXlfcHJvdC54LHYgMS40IDIwMDMv MDUvMDQgMDI6NTE6NDIgb2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9y cGMva2V5X2NhbGwuYyx2IDEuMTggMjAxMC8wMy8xMCAxMzoyMzoyNSBqaGIgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2luY2x1ZGUvcnBjc3ZjL2tleV9wcm90LngsdiAxLjQgMjAwMy8wNS8wNCAw Mjo1MTo0MiBvYnJpZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9kZXNf Y3J5cHQuYyx2IDEuOCAyMDA0LzEwLzE2IDA2OjExOjM0IG9icmllbiBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMvcnBjL3N2Y19hdXRoX3VuaXguYyx2IDEuMTEgMjAwNC8xMC8xNiAw NjoxMTozNSBvYnJpZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9hdXRo X3VuaXguYyx2IDEuMTkgMjAwOS8wNi8xOSAxNTo1ODoyNCBicm9va3MgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2xpYi9saWJjL2dlbi9zeXNjb25mLmMsdiAxLjI3IDIwMTAvMDIvMjYgMDY6NDQ6 MDAgZWR3aW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9nZXRwYWdlc2l6 ZS5jLHYgMS42IDIwMDcvMDEvMDkgMDA6Mjc6NTQgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9nZW4vX194dW5hbWUuYyx2IDEuMTUgMjAwOC8xMC8yMiAyMTo1Njo1NyBraWIg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9uZXRuYW1lci5jLHYgMS4xMyAy MDA5LzA2LzE5IDE3OjEwOjM1IGJyb29rcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvaW5jbHVk ZS9ycGNzdmMva2V5X3Byb3QueCx2IDEuNCAyMDAzLzA1LzA0IDAyOjUxOjQyIG9icmllbiBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL2tleV9wcm90X3hkci5jLHYgMS42IDIw MDcvMTEvMjAgMDE6NTE6MjAgamIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Jw Yy9jcnlwdF9jbGllbnQuYyx2IDEuOSAyMDAzLzAyLzE2IDE3OjI5OjEwIG5lY3RhciBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL2NsbnRfZ2VuZXJpYy5jLHYgMS4xNSAyMDA0 LzEwLzE2IDA2OjExOjM0IG9icmllbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv cnBjL2NsbnRfZGcuYyx2IDEuMjEgMjAwOC8wOS8xNSAxNDowMjo0OSBkZnIgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9iaW5kcmVzdnBvcnQuYyx2IDEuMTYgMjAwNC8xMC8x NiAwNjoxMTozNCBvYnJpZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9h dXRodW5peF9wcm90LmMsdiAxLjEwIDIwMDcvMTEvMjAgMDE6NTE6MjAgamIgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9zeXNjdGxieW5hbWUuYyx2IDEuNyAyMDEwLzAyLzIx IDE0OjU4OjAxIGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vZ2V0cHdl bnQuYyx2IDEuOTAgMjAwNi8wNC8yOCAxMjowMzozNSB1bWUgRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL2dlbi9nZXRuZXRncmVudC5jLHYgMS4zNSAyMDA3LzAxLzA5IDAwOjI3OjU0 IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL2dldGdyZW50LmMsdiAx LjM3IDIwMDcvMTIvMTIgMTA6MDg6MDIgYnVzaG1hbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv aW5jbHVkZS9ycGNzdmMvY3J5cHQueCx2IDEuNSAyMDAzLzA1LzA0IDAyOjUxOjQyIG9icmllbiBF eHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL3JwY2RuYW1lLmMsdiAxLjUgMjAw NC8xMC8xNiAwNjoxMTozNSBvYnJpZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJj L3JwYy9jbG50X3ZjLmMsdiAxLjIxIDIwMDgvMDgvMDYgMTQ6MDI6MDUgZGZyIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9ycGMvYXV0aF9ub25lLmMsdiAxLjE0IDIwMDYvMDIvMjcg MjI6MTA6NTggZGVpc2NoZW4gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlv L2ZzY2FuZi5jLHYgMS4xMyAyMDA3LzAxLzA5IDAwOjI4OjA2IGltcCBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMvZ2VuL3N5c2N0bG5hbWV0b21pYi5jLHYgMS41IDIwMTAvMDIvMjEg MTM6NTc6MDIgZWQgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9wd19zY2Fu LmMsdiAxLjI3IDIwMDkvMDcvMjIgMjA6NDY6MTcga2Vuc21pdGggRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL2dlbi9nZXR1c2Vyc2hlbGwuYyx2IDEuMTEgMjAwOS8xMS8yNSAwNDo0 NTo0NSB3b2xsbWFuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvc3Ry c2VwLmMsdiAxLjcgMjAwOS8wMi8wMyAxNzo1ODoyMCBkYW5nZXIgRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL3N0ZGxpYi9hdG9sLmMsdiAxLjUgMjAwNy8wMS8wOSAwMDoyODowOSBp bXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3hkci94ZHJfcmVjLmMsdiAxLjIz IDIwMDgvMDgvMDYgMTQ6MDI6MDUgZGZyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy94ZHIveGRyX21lbS5jLHYgMS4xMyAyMDA0LzEwLzE2IDA2OjMyOjQzIG9icmllbiBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvaW5jbHVkZS9ycGNzdmMvY3J5cHQueCx2IDEuNSAyMDAzLzA1LzA0 IDAyOjUxOjQyIG9icmllbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL3Jw Y19nZW5lcmljLmMsdiAxLjE2IDIwMTAvMDMvMTEgMTY6NTg6MTUgamhiIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9ycGMvcnBjX3Byb3QuYyx2IDEuMTMgMjAwNy8xMS8yMCAwMTo1 MToyMCBqYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcnBjL210X21pc2MuYyx2 IDEuOCAyMDEwLzAzLzEwIDEzOjIzOjI1IGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvc3RkaW8vYXNwcmludGYuYyx2IDEuMTUgMjAwOS8wMy8wMiAwNDoxMTo0MiBkYXMgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9zdHJpbmdsaXN0LmMsdiAxLjggMjAw Ny8wMS8wOSAwMDoyNzo1NSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0 cmluZy9zdHJyY2hyLmMsdiAxLjIgMjAwMi8wMy8yMiAyMTo1MzoxOSBvYnJpZW4gRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy9yaW5kZXguYyx2IDEuOCAyMDA3LzAxLzA5 IDAwOjI4OjEyIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMveGRyL3hkcl9h cnJheS5jLHYgMS4xNSAyMDA0LzEwLzE2IDA2OjMyOjQzIG9icmllbiBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMveGRyL3hkci5jLHYgMS4xNSAyMDA4LzExLzAzIDEwOjM4OjAwIGRm ciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vdmFzcHJpbnRmLmMsdiAx LjIwIDIwMTAvMDMvMTEgMTc6MDM6MzIgamhiIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9ycGMvZ2V0bmV0cGF0aC5jLHYgMS45IDIwMTAvMDEvMDUgMjA6MTg6NDEgYnJ1ZWZmZXIg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3JwYy9nZXRuZXRjb25maWcuYyx2IDEu MTggMjAxMC8wMy8xMCAxMzoyMzoyNSBqaGIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL3N0cmluZy9zdHJ0b2suYyx2IDEuMTAgMjAwNy8xMi8xMiAxODozMzowNiB3ZXMgRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N5cy9zdGFja19wcm90ZWN0b3IuYyx2IDEuNiAy MDA5LzA5LzE3IDEzOjIxOjUzIGthbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv c3RkdGltZS9zdHJmdGltZS5jLHYgMS40NCAyMDA5LzA2LzA5IDA5OjAyOjU4IGRlbHBoaWogRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZHRpbWUvdGltZWxvY2FsLmMsdiAxLjI1 IDIwMDMvMDYvMTMgMDA6MTQ6MDcgamtoIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9nZW4vdmlzLmMsdiAxLjE0IDIwMDcvMDEvMDkgMDA6Mjc6NTYgaW1wIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vZXJyLmMsdiAxLjE1IDIwMDgvMDQvMDMgMjA6MzY6NDQg aW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9md2Fsay5jLHYgMS4x MCAyMDA3LzAxLzA5IDAwOjI4OjA2IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xp YmMvcmVzb2x2L3Jlc191cGRhdGUuYyx2IDEuMyAyMDA3LzA2LzAzIDE3OjIwOjI3IHVtZSBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcmVzb2x2L3Jlc19maW5kem9uZWN1dC5jLHYg MS4zIDIwMDcvMDYvMDMgMTc6MjA6MjcgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9yZXNvbHYvcmVzX3NlbmQuYyx2IDEuOSAyMDA4LzEyLzE0IDE5OjM5OjUzIHVtZSBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L2dldG5hbWVpbmZvLmMsdiAxLjIxIDIw MDkvMTEvMTIgMTE6NTQ6MTIgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9p c2MvZXZfdGltZXJzLmMsdiAxLjMgMjAwNy8wNi8wMyAxNzoyMDoyNiB1bWUgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL2lzYy9ldl9zdHJlYW1zLmMsdiAxLjMgMjAwNy8wNi8wMyAx NzoyMDoyNiB1bWUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL25ldC9uYW1lNi5j LHYgMS42MiAyMDA3LzA3LzMxIDE2OjA5OjQxIGJ1c2htYW4gRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL3Jlc29sdi9yZXNfcXVlcnkuYyx2IDEuNiAyMDA4LzEyLzE0IDE5OjM5OjUz IHVtZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vc2V0YnVmLmMsdiAx LjUgMjAwNy8wMS8wOSAwMDoyODowNyBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL3N0ZGlvL3NldHZidWYuYyx2IDEuMTQgMjAwNy8wMS8wOSAwMDoyODowNyBpbXAgRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Jlc29sdi9yZXNfbWt1cGRhdGUuYyx2IDEuMyAy MDA3LzA2LzAzIDE3OjIwOjI3IHVtZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv c3RkaW8vc3NjYW5mLmMsdiAxLjE0IDIwMDkvMTIvMjEgMTk6NTY6MDMgZGVscGhpaiBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L2dldHByb3RvZW50LmMsdiAxLjkgMjAwNy8w MS8wOSAwMDoyODowMiBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlv L3Zzc2NhbmYuYyx2IDEuMTYgMjAxMC8wMy8xMSAxNzowMzozMiBqaGIgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL3Zmc2NhbmYuYyx2IDEuNDMgMjAwOS8wMS8xOSAwNjox OTo1MSBkYXMgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL3VuZ2V0Yy5j LHYgMS4xOCAyMDA4LzA0LzE3IDIyOjE3OjU0IGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvbG9jYWxlL3djdG9iLmMsdiAxLjQgMjAwNC8wNS8xMiAxNDoyNjo1NCB0anIgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS9ydW5ldHlwZS5jLHYgMS4xNCAy MDA3LzAxLzA5IDAwOjI4OjAwIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv bG9jYWxlL21icnRvd2MuYyx2IDEuNyAyMDA0LzA1LzEyIDE0OjA5OjA0IHRqciBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbG9jYWxlL2NvbGxjbXAuYyx2IDEuMTggMjAwNS8wMi8y NyAxNDo1NDoyMyBwaGFudG9tIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJp bmcvc3RyY29sbC5jLHYgMS4xNCAyMDA5LzAyLzAzIDE3OjU4OjIwIGRhbmdlciBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL3N0cnRvdW1heC5jLHYgMS4xMSAyMDA3LzAx LzA5IDAwOjI4OjEwIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGli L3N0cnRvaW1heC5jLHYgMS4xMiAyMDA3LzAxLzA5IDAwOjI4OjEwIGltcCBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvZ2R0b2EvbWFjaGRlcF9sZGlzeC5jLHYgMS4zIDIwMDcvMTIv MDMgMDc6MTc6MzIgZGFzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9sb2NhbGUv aXNjdHlwZS5jLHYgMS4xMSAyMDA3LzEwLzEzIDE2OjI4OjIyIGFjaGUgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS9jb2xsYXRlLmMsdiAxLjM1IDIwMDUvMDIvMjcgMjA6 MzE6MTMgcnUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Jlc29sdi9yZXNfbWtx dWVyeS5jLHYgMS41IDIwMDgvMTIvMTQgMTk6Mzk6NTMgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9yZXNvbHYvcmVzX2luaXQuYyx2IDEuNyAyMDA3LzEyLzAzIDE1OjEzOjQ0 IHVtZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0cmNzcG4uYyx2 IDEuNSAyMDA1LzA0LzAyIDE4OjUyOjQ0IGRhcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvc3RkbGliL2F0b2kuYyx2IDEuNiAyMDA3LzAxLzA5IDAwOjI4OjA5IGltcCBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L2dldGFkZHJpbmZvLmMsdiAxLjkxIDIwMDkv MDMvMjkgMTc6NTU6MTEgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4v Z2V0aG9zdG5hbWUuYyx2IDEuOCAyMDA3LzAxLzA5IDAwOjI3OjU0IGltcCBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L2dldHNlcnZlbnQuYyx2IDEuMjMgMjAwNy8wMS8wOSAw MDoyODowMiBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9nZXRkb21h aW5uYW1lLmMsdiAxLjggMjAwNy8wMS8wOSAwMDoyNzo1MyBpbXAgRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL3N0ZGlvL2ZnZXRsbi5jLHYgMS4xMSAyMDA3LzAxLzA5IDAwOjI4OjA2 IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcmVzb2x2L3Jlc19kZWJ1Zy5j LHYgMS42IDIwMDgvMTIvMTQgMTk6Mzk6NTMgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9zdGRsaWIvc3RydG91bC5jLHYgMS4xOSAyMDA3LzAxLzA5IDAwOjI4OjEwIGltcCBF eHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vcHV0Yy5jLHYgMS4xNiAyMDA4 LzA1LzA1IDE2OjAzOjUyIGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvcmVz b2x2L3Jlc19kYXRhLmMsdiAxLjUgMjAwNy8xMi8wMyAxNToxMzo0NCB1bWUgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL25hbWVzZXIvbnNfcHJpbnQuYyx2IDEuMyAyMDA3LzA2LzAz IDE3OjIwOjI2IHVtZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvaW5ldC9uc2Fw X2FkZHIuYyx2IDEuMyAyMDA3LzA2LzAzIDE3OjIwOjI2IHVtZSBFeHAgJAogICAgICRGcmVlQlNE OiBzcmMvbGliL2xpYmMvcmVzb2x2L210Y3R4cmVzLmMsdiAxLjMgMjAwNi8xMi8xNSAyMDo1OTo1 NSB1bWUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL25ldC9iYXNlNjQuYyx2IDEu NSAyMDAyLzAzLzIyIDIxOjUyOjI4IG9icmllbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvbmFtZXNlci9uc19zYW1lZG9tYWluLmMsdiAxLjQgMjAwNy8wNi8wMyAxNzoyMDoyNiB1 bWUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL25ldC9uc3BhcnNlci55LHYgMS42 IDIwMDcvMDUvMTcgMDM6MzM6MjMgam9uIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9zdGRpby9mcmVhZC5jLHYgMS4xNyAyMDEwLzAxLzEwIDE0OjMwOjMwIGNwZXJjaXZhIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9maWxlbm8uYyx2IDEuMTMgMjAwOC8w NS8wNSAxNjowMzo1MiBqaGIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlv L2ZlcnJvci5jLHYgMS4xMiAyMDA4LzA1LzA1IDE2OjAzOjUyIGpoYiBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMvbmV0L2dldG5ldG5hbWFkci5jLHYgMS4yMyAyMDA2LzA0LzI4IDEy OjAzOjM1IHVtZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L2dldG5ldGJ5 bmlzLmMsdiAxLjIxIDIwMDYvMDQvMTUgMTY6MjA6MjcgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9uZXQvZ2V0bmV0YnlodC5jLHYgMS4xOSAyMDA3LzAxLzA5IDAwOjI4OjAy IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L2dldG5ldGJ5ZG5zLmMs diAxLjM0IDIwMDcvMDEvMDkgMDA6Mjg6MDIgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9pbmV0L2luZXRfbmV0d29yay5jLHYgMS41IDIwMDgvMDEvMTQgMjI6NTU6MjAgY3Bl cmNpdmEgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL3B1dHMuYyx2IDEu MTEgMjAwNy8wMS8wOSAwMDoyODowNyBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL25ldC9nZXRob3N0bmFtYWRyLmMsdiAxLjMzIDIwMDYvMDUvMjEgMTE6Mjc6MjggdW1lIEV4 cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQvbnNkaXNwYXRjaC5jLHYgMS4xOCAy MDA5LzA1LzI3IDE3OjAxOjU5IHptbCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv bmV0L2dldGhvc3RieW5pcy5jLHYgMS4yOCAyMDA2LzA1LzEyIDE1OjM3OjIzIHVtZSBFeHAgJAog ICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbmV0L2dldGhvc3RieWh0LmMsdiAxLjI3IDIwMDcv MDEvMDkgMDA6Mjg6MDIgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQv Z2V0aG9zdGJ5ZG5zLmMsdiAxLjU5IDIwMDkvMDIvMDggMTY6NTg6MDUgdW1lIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9pbmV0L2luZXRfcHRvbi5jLHYgMS4zIDIwMDcvMDYvMDMg MTc6MjA6MjYgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9pbmV0L2luZXRf bnRvcC5jLHYgMS4zIDIwMDcvMDYvMDMgMTc6MjA6MjYgdW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9pbmV0L2luZXRfYWRkci5jLHYgMS40IDIwMDcvMDYvMDMgMTc6MjA6MjYg dW1lIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vc3lzbG9nLmMsdiAxLjM5 IDIwMDcvMDEvMDkgMDA6Mjc6NTUgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9nZW4vZGxmY24uYyx2IDEuMTYgMjAwOS8wNC8wMyAxOToxNzoyMyBraWIgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy9zdHJzdHIuYyx2IDEuNiAyMDA5LzAyLzAzIDE3 OjU4OjIwIGRhbmdlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0 cnBicmsuYyx2IDEuNiAyMDA5LzAyLzAzIDE3OjU4OjIwIGRhbmdlciBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0cmxjcHkuYyx2IDEuMTEgMjAwOS8wMi8yOCAwNTox NTowMiBkYXMgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0cmluZy9zdHJsY2F0 LmMsdiAxLjEyIDIwMDkvMDIvMjggMDU6MTU6MDIgZGFzIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9zdHJpbmcvc3RyY2FzZWNtcC5jLHYgMS44IDIwMDkvMDIvMDMgMTc6NTg6MjAg ZGFuZ2VyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvaW5kZXguYyx2 IDEuOCAyMDA3LzAxLzA5IDAwOjI4OjEyIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvc3RkbGliL3Fzb3J0LmMsdiAxLjE1IDIwMDgvMDEvMTQgMDk6MjE6MzQgZGFzIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRsaWIvYnNlYXJjaC5jLHYgMS40IDIwMDcv MDEvMDkgMDA6Mjg6MDkgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRs aWIvYXRleGl0LmMsdiAxLjggMjAwNy8wMS8wOSAwMDoyODowOSBpbXAgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2NvbnRyaWIvdHpjb2RlL3N0ZHRpbWUvbG9jYWx0aW1lLmMsdiAxLjEgMjAxMC8w Mi8yNSAyMToyMTozNCBlZHdpbiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvY29udHJpYi90emNv ZGUvc3RkdGltZS9hc2N0aW1lLmMsdiAxLjEgMjAxMC8wMi8yNSAyMToyMTozNCBlZHdpbiBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vcmV3aW5kLmMsdiAxLjEyIDIwMDcv MDEvMDkgMDA6Mjg6MDcgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRp by9wcmludGYuYyx2IDEuMTEgMjAwNy8wMS8wOSAwMDoyODowNyBpbXAgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL2Z1bm9wZW4uYyx2IDEuNyAyMDA5LzEyLzA1IDE5OjMx OjM4IGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9mc2Vlay5jLHYg MS40NCAyMDA4LzA0LzE3IDIyOjE3OjU0IGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvc3RkaW8vZnB1dHMuYyx2IDEuMTIgMjAwNy8wMS8wOSAwMDoyODowNiBpbXAgRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL2ZwdXRjLmMsdiAxLjE0IDIwMDcvMDEv MDkgMDA6Mjg6MDYgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9m b3Blbi5jLHYgMS4xNCAyMDA4LzA0LzIyIDE3OjAzOjMyIGpoYiBFeHAgJAogICAgICRGcmVlQlNE OiBzcmMvbGliL2xpYmMvc3RkaW8vZmdldHMuYyx2IDEuMTQgMjAwNy8wMS8wOSAwMDoyODowNiBp bXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3Jlc29sdi9yZXNfY29tcC5jLHYg MS42IDIwMDkvMDUvMjkgMDc6MzQ6NTQgZGVscGhpaiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvbmV0L25zY2FjaGUuYyx2IDEuMiAyMDA3LzEwLzE3IDIzOjIwOjQ5IHRtY2xhdWdo IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQvc2VuZC5jLHYgMS40IDIwMDcv MDEvMDkgMDA6Mjg6MDIgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQv bWFwX3Y0djYuYyx2IDEuMTAgMjAwNy8wMS8wOSAwMDoyODowMiBpbXAgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2xpYi9saWJjL2dlbi91c2xlZXAuYyx2IDEuMzEgMjAwOS8xMi8wNSAxOTozMToz OCBlZCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL3RpbWUuYyx2IDEuNiAy MDA5LzEyLzI5IDEyOjQ3OjQ3IGtpYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv Z2VuL19vbmNlX3N0dWIuYyx2IDEuMiAyMDA5LzExLzIwIDIwOjQzOjM0IGpoYiBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vd2J1Zi5jLHYgMS4xMiAyMDA3LzAxLzA5IDAw OjI4OjA4IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vc3ByaW50 Zi5jLHYgMS4xNyAyMDA5LzEyLzIxIDE5OjU5OjM4IGRlbHBoaWogRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL3N0ZGlvL2Z0ZWxsLmMsdiAxLjI3IDIwMDcvMDEvMDkgMDA6Mjg6MDYg aW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQvbnNjYWNoZWRjbGkuYyx2 IDEuMyAyMDA2LzEyLzA0IDE3OjA4OjQzIHVtZSBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvZ2VuL2Fzc2VydC5jLHYgMS44IDIwMDcvMDEvMDkgMDA6Mjc6NTMgaW1wIEV4cCAkCiAg ICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvc3RybmNweS5jLHYgMS44IDIwMDkvMDIv MDMgMTc6NTg6MjAgZGFuZ2VyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRp by92c3ByaW50Zi5jLHYgMS4xNyAyMDEwLzAzLzExIDE3OjAzOjMyIGpoYiBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vZnByaW50Zi5jLHYgMS4xMSAyMDA3LzAxLzA5IDAw OjI4OjA2IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbG9jYWxlL2xvY2Fs ZWNvbnYuYyx2IDEuMTQgMjAwNy8xMi8xMiAwNzo0MzoyMyBwaGFudG9tIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9sb2NhbGUvbG51bWVyaWMuYyx2IDEuMTYgMjAwMy8wNi8yNiAx MDo0NjoxNiBwaGFudG9tIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9sb2NhbGUv bG1vbmV0YXJ5LmMsdiAxLjE5IDIwMDMvMDYvMjYgMTA6NDY6MTYgcGhhbnRvbSBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvbG9jYWxlL2xkcGFydC5jLHYgMS4xNSAyMDA0LzA0LzI1 IDE5OjU2OjUwIGFjaGUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS9m aXhfZ3JvdXBpbmcuYyx2IDEuOCAyMDAzLzA2LzI2IDEwOjQ2OjE2IHBoYW50b20gRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGxpYi9zdHJ0b2wuYyx2IDEuMjAgMjAwNy8wMS8w OSAwMDoyODoxMCBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L3N0 cmluZy9zdHJjbXAuUyx2IDEuMiAyMDA4LzExLzAyIDAxOjEwOjU0IHBldGVyIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9hbWQ2NC9zdHJpbmcvc3RyY2F0LlMsdiAxLjIgMjAwOC8x MS8wMiAwMToxMDo1NCBwZXRlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZGIv cmVjbm8vcmVjX3B1dC5jLHYgMS4xMSAyMDA5LzAzLzI4IDA1OjQ1OjI5IGRlbHBoaWogRXhwICQK ICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2RiL3JlY25vL3JlY19vcGVuLmMsdiAxLjkgMjAw OS8wMy8wNCAwMDo1ODowNCBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9zdGRpby9mZG9wZW4uYyx2IDEuMTEgMjAwOC8wNS8xMCAxODozOToyMCBhbnRvaW5lIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9kYi9yZWNuby9yZWNfc2VxLmMsdiAxLjggMjAw OS8wMy8wNCAwMDo1ODowNCBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9kYi9yZWNuby9yZWNfZ2V0LmMsdiAxLjggMjAwOS8wMy8wNSAwMDo1NzowMSBkZWxwaGlqIEV4 cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9kYi9yZWNuby9yZWNfZGVsZXRlLmMsdiAx LjUgMjAwOS8wMy8wMyAwMjoxNjoxMiBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9kYi9yZWNuby9yZWNfY2xvc2UuYyx2IDEuMTEgMjAwOS8wMy8yOCAwNTo0NToyOSBk ZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zeXMvZnRydW5jYXRlLmMs diAxLjcgMjAwNy8wNy8wNCAyMzoyNzozOCBwZXRlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvc3RkaW8vZ2V0Yy5jLHYgMS4xNiAyMDA4LzA1LzA1IDE2OjAzOjUyIGpoYiBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vZmxhZ3MuYyx2IDEuMTAgMjAwNy8w MS8wOSAwMDoyODowNiBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlv L2ZjbG9zZS5jLHYgMS4xMiAyMDA3LzAxLzA5IDAwOjI4OjA2IGltcCBFeHAgJAogICAgICRGcmVl QlNEOiBzcmMvbGliL2xpYmMvZGIvcmVjbm8vcmVjX3V0aWxzLmMsdiAxLjYgMjAwOS8wMy8wNSAw MDo1NzowMSBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9kYi9yZWNu by9yZWNfc2VhcmNoLmMsdiAxLjggMjAwOS8wMy8wNCAwMDo1ODowNCBkZWxwaGlqIEV4cCAkCiAg ICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9yZ2V0LmMsdiAxLjYgMjAwNy8wMS8wOSAw MDoyODowNyBpbXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL3JlZmls bC5jLHYgMS4yMCAyMDA4LzA0LzE3IDIyOjE3OjU0IGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvZGIvaGFzaC9oYXNoX3BhZ2UuYyx2IDEuMTcgMjAwOS8wMy8yOCAwNzo0NDow OCBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9kYi9oYXNoL2hhc2hf Ymlna2V5LmMsdiAxLjEwIDIwMDkvMDMvMjggMDY6NDc6MDUgZGVscGhpaiBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvZGIvZGIvZGIuYyx2IDEuNSAyMDA5LzAzLzI4IDA3OjI2OjAw IGRlbHBoaWogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2RiL2hhc2gvaGFzaC5j LHYgMS4yMiAyMDA5LzA4LzI0IDIzOjQ0OjA3IGRlbHBoaWogRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL2RiL2J0cmVlL2J0X29wZW4uYyx2IDEuMTggMjAwOS8wMy8yOCAwNzozMTow MiBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9kYi9idHJlZS9idF9n ZXQuYyx2IDEuNCAyMDA5LzAzLzAyIDIzOjQ3OjE4IGRlbHBoaWogRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL2RiL2J0cmVlL2J0X2NvbnYuYyx2IDEuNCAyMDA5LzAzLzAyIDIzOjQ3 OjE4IGRlbHBoaWogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2RiL2J0cmVlL2J0 X2Nsb3NlLmMsdiAxLjEwIDIwMDkvMDMvMDIgMjM6NDc6MTggZGVscGhpaiBFeHAgJAogICAgICRG cmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vc25wcmludGYuYyx2IDEuMjMgMjAxMC8wMy8xMSAx NzowMzozMiBqaGIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL21rdGVt cC5jLHYgMS4zMiAyMDEwLzAyLzI4IDEzOjMxOjI5IGpoIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9nZW4vYXJjNHJhbmRvbS5jLHYgMS4yNSAyMDA4LzA5LzA5IDA5OjQ2OjM2IGFj aGUgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2RiL2hhc2gvaGFzaF9sb2cyLmMs diAxLjUgMjAwOS8wMy8yOCAwNTo0NToyOSBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9kYi9oYXNoL2hhc2hfZnVuYy5jLHYgMS43IDIwMDkvMDMvMjggMDc6MzE6MDIg ZGVscGhpaiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZGIvaGFzaC9oYXNoX2J1 Zi5jLHYgMS4xMiAyMDA5LzAzLzI4IDA2OjQwOjQ4IGRlbHBoaWogRXhwICQKICAgICAkRnJlZUJT RDogc3JjL2xpYi9saWJjL2RiL2J0cmVlL2J0X3B1dC5jLHYgMS45IDIwMDkvMDMvMjggMDU6NDU6 MjkgZGVscGhpaiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZGIvYnRyZWUvYnRf ZGVsZXRlLmMsdiAxLjYgMjAwOS8wMy8wNCAwMDo1ODowNCBkZWxwaGlqIEV4cCAkCiAgICAgJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby92ZnByaW50Zi5jLHYgMS45MSAyMDEwLzAzLzExIDE3 OjAzOjMyIGpoYiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vcHJpbnRm LXBvcy5jLHYgMS42IDIwMDkvMDMvMDIgMDQ6MDc6NTggZGFzIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9sb2NhbGUvd2NzcnRvbWJzLmMsdiAxLjYgMjAwNC8wNy8yMSAxMDo1NDo1 NyB0anIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2xvY2FsZS93Y3J0b21iLmMs diAxLjggMjAwNC8wNS8xMiAxNDowOTowNCB0anIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xp Yi9saWJjL2xvY2FsZS9ub25lLmMsdiAxLjE1IDIwMDcvMTAvMTMgMTY6Mjg6MjIgYWNoZSBFeHAg JAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZGIvYnRyZWUvYnRfc3BsaXQuYyx2IDEuMTQg MjAwOS8wNi8yNCAwMToxNToxMCBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIv bGliYy9kYi9idHJlZS9idF9zZXEuYyx2IDEuNyAyMDA5LzAzLzA0IDAwOjU4OjA0IGRlbHBoaWog RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2RiL2J0cmVlL2J0X3NlYXJjaC5jLHYg MS41IDIwMDkvMDMvMDMgMDI6MTY6MTIgZGVscGhpaiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMv bGliL2xpYmMvc3RyaW5nL3N0cm5sZW4uYyx2IDEuMSAyMDA5LzAyLzI4IDA2OjAwOjU4IGRhcyBF eHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkbGliL2dldGVudi5jLHYgMS4yMCAy MDA5LzEyLzA3IDAwOjIyOjEwIHNjZiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMv Z2R0b2EvX2xkdG9hLmMsdiAxLjUgMjAwNy8xMi8wOSAxOTo0ODo1NyBkYXMgRXhwICQKICAgICAk RnJlZUJTRDogc3JjL2xpYi9saWJjL2dkdG9hL19obGR0b2EuYyx2IDEuMiAyMDA4LzA0LzEyIDE0 OjUzOjUyIGRhcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2R0b2EvX2hkdG9h LmMsdiAxLjcgMjAwOC8wNC8xMiAxNDo1Mzo1MiBkYXMgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL2FtZDY0L3N0cmluZy9zdHJjcHkuUyx2IDEuMyAyMDA4LzExLzAyIDAxOjEwOjU0 IHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9hbWQ2NC9zdHJpbmcvYmNv cHkuUyx2IDEuMyAyMDA4LzExLzAyIDAxOjEwOjU0IHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6 IHNyYy9saWIvbGliYy9sb2NhbGUvdGFibGUuYyx2IDEuMjggMjAwNy8wMS8wOSAwMDoyODowMCBp bXAgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2FtZDY0L2dlbi9mbHRfcm91bmRz LmMsdiAxLjEgMjAwNC8wNy8xOSAwODoxNzoyNCBkYXMgRXhwICQKICAgICAkRnJlZUJTRDogc3Jj L2xpYi9saWJjL2dlbi9nZXRwcm9nbmFtZS5jLHYgMS40IDIwMDIvMDMvMjkgMjI6NDM6NDEgbWFy a20gRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2RiL2J0cmVlL2J0X3V0aWxzLmMs diAxLjcgMjAwOS8wMy8wNSAwMDo1NzowMSBkZWxwaGlqIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNy Yy9saWIvbGliYy9kYi9idHJlZS9idF9vdmVyZmxvdy5jLHYgMS42IDIwMDkvMDMvMDUgMDA6NTc6 MDEgZGVscGhpaiBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0cm5j bXAuYyx2IDEuNyAyMDA5LzAyLzAzIDE3OjU4OjIwIGRhbmdlciBFeHAgJAogICAgICRGcmVlQlNE OiBzcmMvbGliL2xpYmMvc3RyaW5nL3N0cmNoci5jLHYgMS4yIDIwMDIvMDMvMjIgMjE6NTM6MTkg b2JyaWVuIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJpbmcvaW5kZXguYyx2 IDEuOCAyMDA3LzAxLzA5IDAwOjI4OjEyIGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGli L2xpYmMvc3RyaW5nL3N0cGNweS5jLHYgMS4yIDIwMDkvMDIvMjggMDY6MDU6MzcgZGFzIEV4cCAk CiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9hbWQ2NC9zdHJpbmcvYmNvcHkuUyx2IDEuMyAy MDA4LzExLzAyIDAxOjEwOjU0IHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGli Yy9kYi9idHJlZS9idF9wYWdlLmMsdiAxLjYgMjAwOS8wMy8yOCAwNzozMTowMiBkZWxwaGlqIEV4 cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9kYi9tcG9vbC9tcG9vbC5jLHYgMS4xOSAy MDA5LzA2LzI0IDAxOjE1OjEwIGRlbHBoaWogRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL3N5cy9wd3JpdGUuYyx2IDEuNCAyMDA3LzA3LzA0IDIzOjI3OjM4IHBldGVyIEV4cCAkCiAg ICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zeXMvcHJlYWQuYyx2IDEuNCAyMDA3LzA3LzA0IDIz OjI3OjM4IHBldGVyIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRsaWIvYWJv cnQuYyx2IDEuMTEgMjAwNy8wMS8wOSAwMDoyODowOSBpbXAgRXhwICQKICAgICAkRnJlZUJTRDog c3JjL2xpYi9saWJjL3N0ZGlvL2Z3cml0ZS5jLHYgMS4xNCAyMDEwLzAxLzEwIDE0OjMwOjMwIGNw ZXJjaXZhIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdGRpby9mdndyaXRlLmMs diAxLjE5IDIwMDkvMTEvMjUgMDQ6MjE6NDIgd29sbG1hbiBFeHAgJAogICAgICRGcmVlQlNEOiBz cmMvbGliL2xpYmMvZ2VuL3NpZ3NldG9wcy5jLHYgMS45IDIwMDcvMDEvMDkgMDA6Mjc6NTUgaW1w IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vcmFpc2UuYyx2IDEuNiAyMDA5 LzEyLzA1IDE5OjMxOjM4IGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zdHJp bmcvbWVtY2hyLmMsdiAxLjggMjAwOS8wMi8wNyAxOTozNDo0NCBpbXAgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL3dzZXR1cC5jLHYgMS4xMSAyMDA5LzAxLzA4IDA2OjM4 OjA2IGRhcyBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3RkaW8vbWFrZWJ1Zi5j LHYgMS42IDIwMDcvMDEvMDkgMDA6Mjg6MDcgaW1wIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9s aWIvbGliYy9zdGRpby9maW5kZnAuYyx2IDEuMzUgMjAxMC8wMy8xMSAxNzowMzozMiBqaGIgRXhw ICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N0ZGlvL2ZmbHVzaC5jLHYgMS4xNCAyMDA3 LzAxLzA5IDAwOjI4OjA2IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3Rk aW8vX2Zsb2NrX3N0dWIuYyx2IDEuMTYgMjAwOC8wNC8xNyAyMjoxNzo1MyBqaGIgRXhwICQKICAg ICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9pc2F0dHkuYyx2IDEuNiAyMDA3LzAxLzA5IDAw OjI3OjU0IGltcCBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvZ2VuL19zcGlubG9j a19zdHViLmMsdiAxLjEwIDIwMDcvMDEvMTIgMDc6MzE6MzAgaW1wIEV4cCAkCiAgICAgJEZyZWVC U0Q6IHNyYy9saWIvbGliYy9nZW4vX3B0aHJlYWRfc3R1YnMuYyx2IDEuMTcgMjAxMC8wMS8wNSAw MjozNzo1OSBkYXZpZHh1IEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9hbWQ2NC9z dHJpbmcvbWVtc2V0LlMsdiAxLjIgMjAwOC8xMS8wMiAwMToxMDo1NCBwZXRlciBFeHAgJAogICAg ICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvYW1kNjQvc3RyaW5nL2Jjb3B5LlMsdiAxLjMgMjAwOC8x MS8wMiAwMToxMDo1NCBwZXRlciBFeHAgJAogICAgICRGcmVlQlNEOiBzcmMvbGliL2xpYmMvc3Rk aW8vc3RkaW8uYyx2IDEuMjggMjAwOC8wNS8wNSAxNjoxNDowMiBqaGIgRXhwICQKICAgICAkRnJl ZUJTRDogc3JjL2xpYi9saWJjL2dlbi90ZXJtaW9zLmMsdiAxLjE3IDIwMDkvMTIvMDUgMTg6NTM6 MDQgZWQgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL3N5cy9sc2Vlay5jLHYgMS43 IDIwMDcvMDcvMDQgMjM6Mjc6MzggcGV0ZXIgRXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9s aWJjL2dlbi9fX2dldG9zcmVsZGF0ZS5jLHYgMS4xIDIwMDcvMDcvMDQgMjM6Mjc6MzggcGV0ZXIg RXhwICQKICAgICAkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9zeXNjdGwuYyx2IDEuNyAyMDEw LzAyLzIxIDEzOjU3OjAyIGVkIEV4cCAkCiAgICAgJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9hbWQ2 NC9zeXMvY2Vycm9yLlMsdiAxLjE1IDIwMDcvMDEvMDkgMDA6Mjc6NDkgaW1wIEV4cCAkCiAgICAg JEZyZWVCU0Q6IHNyYy9saWIvbGliYy9zeXMvX19lcnJvci5jLHYgMS42IDIwMDkvMTIvMDUgMTk6 MzE6MzggZWQgRXhwICQK --001636e0b9c579df190482562218-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 21:20: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 3470D1065670 for ; Sun, 21 Mar 2010 21:20:56 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 06F178FC2D for ; Sun, 21 Mar 2010 21:20:55 +0000 (UTC) Received: by pwj4 with SMTP id 4so3726758pwj.13 for ; Sun, 21 Mar 2010 14:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=r6e87tWbDxIYpDxZYB818k39jvdAqTt6fF/cXv//8Ks=; b=cCslSZ9XKMLjIHa0RVcoksb5JRMtlaR1DFnSuG2DFNnDT0WH0pfcGbSagpKvOkURPC U7zbPDaKwHbzp38FJRS3U9SmfYm2RPTlDYC38m4+QRJutnSrHwH5KBR9ocIgxdU3KSvw RSgfAupRK2K9AuhAPto3d4popnNi9+yM5CKgE= 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=SHULIxQxwgogcUunCyLEvHVmoqqbkEsd9dSVjjgafq9ua/TaZE/zwRZ+EEK7boUGkX rqfNliu8dm8/viIn0nXoZZ9qP0AgJiiPoGelqwL9bNquaTutO6T5GGcgrR5gXtdRH+GL DkvFgTAJadyBZwmDAkct9iMvZAOmw5jKAlOmc= MIME-Version: 1.0 Received: by 10.143.153.24 with SMTP id f24mr417944wfo.307.1269206455644; Sun, 21 Mar 2010 14:20:55 -0700 (PDT) In-Reply-To: <4BA63CB1.3000201@andric.com> References: <201003211232.35497.ken@mthelicon.com> <20100321140304.37618e59@ernst.jennejohn.org> <20100321140804.48cd1876@ernst.jennejohn.org> <4BA63CB1.3000201@andric.com> Date: Sun, 21 Mar 2010 14:20:55 -0700 Message-ID: <7d6fde3d1003211420j77b916cdt48de132ebe9a0b23@mail.gmail.com> From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , Pegasus Mc Cleaft , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 21:20:56 -0000 On Sun, Mar 21, 2010 at 8:35 AM, Dimitry Andric wrote: > On 2010-03-21 14:08, Gary Jennejohn wrote: >>>> >>>> CPUTYPE=3Dnative >>>> CFLAGS=3D-O2 -fno-strict-aliasing -pipe -s >>>> >>>> btw: what's the -s switch doing? >>> >>> It "silences" make. =A0See the man page. =A0It's useful because basical= ly >>> only >>> errors are emitted. >> >> Oops. =A0That's wrong. =A0I got confused. =A0I'd like to know that mysel= f, now >> that I'm no longer confused :) > > From gcc(1): > > =A0 =A0 =A0 -s =A0Remove all symbol table and relocation information from= the exe- > =A0 =A0 =A0 =A0 =A0 cutable. > > This is more or less the same as running strip(1) over the produced > executables. =A0Usually one uses it for non-debug builds. That seems a bit harsh (especially because that makes certain libraries uses kind of moot, like *_p.a, right?). Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 21:23: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 AB2DD1065679 for ; Sun, 21 Mar 2010 21:23:45 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 46CAA8FC21 for ; Sun, 21 Mar 2010 21:23:44 +0000 (UTC) Received: by pxi12 with SMTP id 12so1237115pxi.14 for ; Sun, 21 Mar 2010 14:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Y1RQpgloaeKcCpvEYcj6hg8M8QCsgDS7CJ25UX4g2sI=; b=sf5zqH/T1vQfQnty/1n4kKrxMmU86NkqUMi+AlTHCcC5BxBIEPSCmMz5HqNTp1T8Rh RCXylIPg/g2Hw6VZLN3jBWCeMrQYDYyv1zjS6WniLtyheMklHasXkDmidjVbL7hy/17d +hsXPWIdBaTEtJ625qrOH/TP1jbEJ8gn7xUGw= 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=tSwJHS8zbkL0KMGAAhyLM1enRztNtTa0ghbA6g0Oa/AuZnJUW6J7KZ24XgtjX0D/lF e6v42bV9BjUayYVg9EW9ZmSId7s57DhhTVKPSjZCRUc3fdaKDWy1f33Q1UmcPeaYfsY7 h6IkVpte1pB2wsX6lSTq+DeWqIUaM6Jn81SOQ= MIME-Version: 1.0 Received: by 10.143.21.5 with SMTP id y5mr2732786wfi.324.1269206624581; Sun, 21 Mar 2010 14:23:44 -0700 (PDT) In-Reply-To: References: <4BA6819E.4050504@icyb.net.ua> Date: Sun, 21 Mar 2010 14:23:44 -0700 Message-ID: <7d6fde3d1003211423p5c43161au12723f248d34de3f@mail.gmail.com> From: Garrett Cooper To: =?ISO-8859-1?B?Q2l2a2EsIEf8bnRlciAoTE5HLU1VRSk=?= Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: build failures after stdlib update 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, 21 Mar 2010 21:23:45 -0000 On Sun, Mar 21, 2010 at 2:11 PM, Alexander Best wrote: > Andriy Gapon schrieb am 2010-03-21: >> on 21/03/2010 20:46 Alexander Best said the following: >> > Andriy Gapon schrieb am 2010-03-21: >> >> on 21/03/2010 14:53 Alexander Best said the following: >> >>> *lol* sorry. ;) > >> >> No worries. >> >> BTW, when that rash happens, are you able to examine the core with >> >> gdb? >> >> Is it possible to examine values of 's' and 'p' in strlen? > >> > 'p' is not available. i guess because the segfault happens before >> > 'p' gets >> > assigned. > >> > but mask01 = 0x101010101010101 and lp = (const long unsigned int *) >> > 0xc092d8. > >> > but i'm not really familiar with gdb and debugging. so you might >> > want to ask >> > for certain commands. ;) > >> Not sure what I was dreaming of when I wrote my request. >> I actually meant 'str' and 'lp'. > > *hehe* that makes more sense. well i already sent you lp. unfortunately str is > not available to gdb: > > (gdb) print str > Variable "str" is not available. Sadly it may have been optimized out, which means that the best way to resolve that little item is to compile with -O0 and DEBUG_FLAGS=-g HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 21:31: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 925CB106564A for ; Sun, 21 Mar 2010 21:31:39 +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 D24E98FC08 for ; Sun, 21 Mar 2010 21:31:38 +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 XAA06410; Sun, 21 Mar 2010 23:31:34 +0200 (EET) (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 1NtSkA-000BAE-AK; Sun, 21 Mar 2010 23:31:34 +0200 Message-ID: <4BA69035.5020904@icyb.net.ua> Date: Sun, 21 Mar 2010 23:31:33 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22G=FCnter_=28LNG-MUE=29=22?= References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org, Alexander Best Subject: Re: build failures after stdlib update 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, 21 Mar 2010 21:31:39 -0000 on 21/03/2010 23:11 Alexander Best said the following: > *hehe* that makes more sense. well i already sent you lp. unfortunately str is > not available to gdb: > > (gdb) print str > Variable "str" is not available. In cases like this sometimes the argument is still available for examination as a variable further down the stack (i.e. in one of the calling functions). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 22:12: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 383F61065670 for ; Sun, 21 Mar 2010 22:12:08 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay2.uni-muenster.de (ZIVM-RELAY2.UNI-MUENSTER.DE [128.176.192.13]) by mx1.freebsd.org (Postfix) with ESMTP id A419C8FC08 for ; Sun, 21 Mar 2010 22:12:07 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,284,1267398000"; d="scan'208";a="239701989" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 21 Mar 2010 23:12:05 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 721C01B07C1; Sun, 21 Mar 2010 23:12:05 +0100 (CET) Date: Sun, 21 Mar 2010 23:12:04 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Andriy Gapon Message-ID: In-Reply-To: <4BA69035.5020904@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 21 Mar 2010 22:12:08 -0000 Andriy Gapon schrieb am 2010-03-21: > on 21/03/2010 23:11 Alexander Best said the following: > > *hehe* that makes more sense. well i already sent you lp. > > unfortunately str is > > not available to gdb: > > (gdb) print str > > Variable "str" is not available. > In cases like this sometimes the argument is still available for > examination as > a variable further down the stack (i.e. in one of the calling > functions). hmmm... str might be "-m" then, because of: #1 0x0000000000416782 in concat (first=0x417618 "-m") at /usr/src/gnu/usr.bin/cc/libiberty/../../../../contrib/gcclibs/libiberty/concat.c:76 -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 00:29: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 902DD106564A for ; Mon, 22 Mar 2010 00:29:06 +0000 (UTC) (envelope-from jhellenthal@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 38D9B8FC12 for ; Mon, 22 Mar 2010 00:29:05 +0000 (UTC) Received: by vws1 with SMTP id 1so179582vws.13 for ; Sun, 21 Mar 2010 17:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=3QSOYfZrs/KIu//vEvB+5OHNCwau4MpJV5At9MramVA=; b=SJxqhCViypLQ6RcZwUrOZy59yZ3wSXml5nxuoMZONcQbbK6tgau4PDbNe/zmTeaGTs jUDz2nM3ZRpQymWDYXtwgZNg2F5L2zWja2U+MQvZyLLAU1eQ8I/WTrigsuz080en+NUK 7CzFaxURwVepjgKKWnGd6u3ZDh1AAMxWQbyHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=sOCvsGr8TL1bk2e2aKA82GK5q82lXEfPNSIHtcU/KeoafSlnWmtAld8lEfaQrCGzwd ktkOmpn82AOZceML3bNKRIah6N92YCBCWuMwbgicKgPEyVPeCL3x271ELFtd9NWo/4V9 D/2iqMy3pTWbcPfHsgaUjwY5ubXgXGg7+KrKA= Received: by 10.220.122.24 with SMTP id j24mr1970769vcr.28.1269217742591; Sun, 21 Mar 2010 17:29:02 -0700 (PDT) Received: from ppp-21.206.dialinfree.com (ppp-21.206.dialinfree.com [209.172.21.206]) by mx.google.com with ESMTPS id 31sm30488855vws.11.2010.03.21.17.28.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 17:29:01 -0700 (PDT) Sender: "J. Hellenthal" Date: Sun, 21 Mar 2010 20:29:16 -0400 From: jhell To: Alexander Best In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 22 Mar 2010 00:29:06 -0000 On Sun, 21 Mar 2010 07:00, alexbestms@ wrote: > Garrett Cooper schrieb am 2010-03-21: >> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best >> wrote: >>> ok. i think i finally solved this riddle. the cause for the problem >>> seems to >>> have been my CPUTYPE in /etc/make.conf. it is set to 'native'. >>> actually i've >>> been using the 'native' keyword for years now and never had any >>> problems with >>> it, but it seems a recent commit broke 'native' as CPUTYPE. for me >>> this is >>> 100% reproducable: > >>> 1. put 'CPUTYPE = native' in /etc/make.conf >>> 2. build and install gnu/usr.bin/cc >>> 3. do 'buildkernel' or 'buildworld' and observe the segfault. for >>> some reason >>> this always occurs in lib/libc/string/strlen.c (r205108). i've >>> tested this >>> with older version of libc.so (built 22. Feb) and got the same >>> result. so i >>> assume this is not a libc problem, but a problem with gcc tripping >>> over some >>> code in libc. i have no clue however why this happend just now and >>> not >>> earlier. i don't think there has been a recent commit to gcc. > >>> to solve this there are two ways: > >>> 1. set CPUTYPE to 'nocona' (i'm running amd64). this will let you >>> compile >>> everything just fine even with a gcc that has itself been built >>> with 'CPUTYPE >>> = native'. >>> 2. build and install gnu/usr.bin/cc with 'CPUTYPE = nocona'. the >>> gcc version >>> that has been built this way will compile everything just fine even >>> with >>> 'CPUTYPE = native'. the only way to break this is to go and compile >>> gcc again >>> with the CPUTYPE set to 'native'. > >>> so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to >>> 'native' will >>> give you a broken gcc! > >> What does -march=native yield in your case? There haven't been >> any >> recent commits to gcc, so I'm not sure whether or not that's the >> issue. The libraries that I provided could have just been built from >> a >> sane system -- maybe it's something else that needs to be explored a >> bit more closely to root cause the issue. > > i've experimented with setting CPUTYPE to native yesterday, but still couldn't > figure out what the cause of it is. only a few points i'd like to point out: > > 1. this is very easily reproducible for me. i just need to set CPUTYPE=native > in my /etc/make.conf and everything that gets linked against libc and uses the > strlen() function won't compile due to gcc segfaulting. this is the case with > /usr/src/bin/cat e.g. as well as kernel, world and probably lots of other > stuff. > > also the following gcc command segfaults too (no need for setting > CPUTYPE=native in this case, because -mtune gets set manually): > > gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > > 2. there seems to be a connection with strlen.c because gcc alaways segfaults > here. also i've been using CPUTYPE=native for years now and never had any > problems with it. for me the segfault always happens in: > > #0 strlen (str=Variable "str" is not available. > ) at /usr/src/lib/libc/string/strlen.c:100 > 100 va = (*lp - mask01); > > it would be nice if people with arch i386 and amd64 could try to reproduce > this (i believe the other archs don't support CPUTYPE=native). again the > easiest way to trigger this (you don't need to edit your /etc/make.conf for > this) should be running: > > gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > > for now i'm using the attached patch to prevent myself from shooting me in the > foot again. ;) > > cheers. > alex > >> Cheers, >> -Garrett > > Native is equal to CPUTYPE not being defined right ? So if the above is true why would you set CPUTYPE to native in the first place ? when you can just leave it unset and its equal to native. Nowhere in /usr/share/examples/etc/make.conf do I see a referance to this type of CPUTYPE so unless I am totally missing the point of this thread, I do not see a problem that has to be fixed. With all due respect, -- jhell From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 00:54: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 E0DE8106566B; Mon, 22 Mar 2010 00:54:41 +0000 (UTC) (envelope-from jhellenthal@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 11FAA8FC18; Mon, 22 Mar 2010 00:54:40 +0000 (UTC) Received: by vws1 with SMTP id 1so184060vws.13 for ; Sun, 21 Mar 2010 17:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=CCBCoeSdGBY5/LyK2DKG78COsETPwjg37vGlqWHzStQ=; b=PSE7OuLEr2Jxa5KYNcqCDtnRyIqlGqcND5j2JU4zlyC9HC/UVRHzbqrBZkBrP2I1pf 25PehvLVVukCOgIlpx5+mE0yQr22sATFpyMqKXxxm3giWGvwziIFD1tD/eblNtSc6avv /lezHJlrjuyCklvHuo+MB/EgppyeDNh8U0/l8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=cXocjCDcbsteYexf+YwfKw9zmsEdzaZpuvYOF+XMjMcMjFAF39EFsoCbv7jw3VO2eV byCTnhU431KFGd6lJZQ/Ww31YqgYoH4rnYDdEX5yE+KbN1OwxpUkKCo/Dy3kJuTdqvZe 1KlH1LgyaN6uCa/iJphGt4wTALo+KEjf5thsc= Received: by 10.220.126.222 with SMTP id d30mr2983568vcs.198.1269219280436; Sun, 21 Mar 2010 17:54:40 -0700 (PDT) Received: from ppp-21.206.dialinfree.com (ppp-21.206.dialinfree.com [209.172.21.206]) by mx.google.com with ESMTPS id 21sm30691517vws.2.2010.03.21.17.54.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 17:54:39 -0700 (PDT) Sender: "J. Hellenthal" Date: Sun, 21 Mar 2010 20:54:59 -0400 From: jhell To: Alexander Motin In-Reply-To: <4BA62757.7090400@FreeBSD.org> Message-ID: References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <4BA532FF.6040407@elischer.org> <4BA62757.7090400@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 00:54:42 -0000 On Sun, 21 Mar 2010 10:04, mav@ wrote: > Julian Elischer wrote: >> In the Fusion-io driver we find that the limiting factor is not the >> size of MAXPHYS, but the fact that we can not push more than >> 170k tps through geom. (in my test machine. I've seen more on some >> beefier machines), but that is only a limit on small transacrtions, >> or in the case of large transfers the DMA engine tops out before a >> bigger MAXPHYS would make any difference. > > Yes, GEOM is quite CPU-hungry on high request rates due to number of > context switches. But impact probably may be reduced from two sides: by > reducing overhead per request, or by reducing number of requests. Both > ways may give benefits. > > If common opinion is not to touch defaults now - OK, agreed. (Note, > Scott, I have agreed :)) But returning to the original question, does > somebody knows real situation when increased MAXPHYS still causes > problems? At least to make it safe. > > I played with it on one re-compile of a kernel and for the sake of it DFLTPHYS=128 MAXPHYS=256 and found out that I could not cause a crash dump to be performed upon request (reboot -d) due to the boundary being hit for DMA which is 65536. Obviously this would have to be adjusted in ata-dma.c. I suppose that there would have to be a better way to get the real allowable boundary from the running system instead of setting it statically. Other then the above I do not see a reason why not... It is HEAD and this is the type of experimental stuff it was meant for. Regards, -- jhell From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 01:54: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 CC415106564A; Mon, 22 Mar 2010 01:54:43 +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 A666F8FC0A; Mon, 22 Mar 2010 01:54:43 +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 o2M1sgHc046223; Sun, 21 Mar 2010 21:54:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2M1sg84046196; Mon, 22 Mar 2010 01:54:42 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 22 Mar 2010 01:54:42 GMT Message-Id: <201003220154.o2M1sg84046196@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 01:54:43 -0000 TB --- 2010-03-22 00:05:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-22 00:05:01 - starting HEAD tinderbox run for i386/i386 TB --- 2010-03-22 00:05:01 - cleaning the object tree TB --- 2010-03-22 00:05:26 - cvsupping the source tree TB --- 2010-03-22 00:05:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-03-22 00:05:53 - building world TB --- 2010-03-22 00:05:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-22 00:05:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-22 00:05:53 - TARGET=i386 TB --- 2010-03-22 00:05:53 - TARGET_ARCH=i386 TB --- 2010-03-22 00:05:53 - TZ=UTC TB --- 2010-03-22 00:05:53 - __MAKE_CONF=/dev/null TB --- 2010-03-22 00:05:53 - cd /src TB --- 2010-03-22 00:05:53 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 22 00:05:54 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 Mon Mar 22 01:05:17 UTC 2010 TB --- 2010-03-22 01:05:17 - generating LINT kernel config TB --- 2010-03-22 01:05:17 - cd /src/sys/i386/conf TB --- 2010-03-22 01:05:17 - /usr/bin/make -B LINT TB --- 2010-03-22 01:05:17 - building LINT kernel TB --- 2010-03-22 01:05:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-22 01:05:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-22 01:05:17 - TARGET=i386 TB --- 2010-03-22 01:05:17 - TARGET_ARCH=i386 TB --- 2010-03-22 01:05:17 - TZ=UTC TB --- 2010-03-22 01:05:17 - __MAKE_CONF=/dev/null TB --- 2010-03-22 01:05:17 - cd /src TB --- 2010-03-22 01:05:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 22 01:05:18 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Mar 22 01:30:04 UTC 2010 TB --- 2010-03-22 01:30:04 - building GENERIC kernel TB --- 2010-03-22 01:30:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-22 01:30:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-22 01:30:04 - TARGET=i386 TB --- 2010-03-22 01:30:04 - TARGET_ARCH=i386 TB --- 2010-03-22 01:30:04 - TZ=UTC TB --- 2010-03-22 01:30:04 - __MAKE_CONF=/dev/null TB --- 2010-03-22 01:30:04 - cd /src TB --- 2010-03-22 01:30:04 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Mar 22 01:30:04 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Mar 22 01:49:53 UTC 2010 TB --- 2010-03-22 01:49:53 - building PAE kernel TB --- 2010-03-22 01:49:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-22 01:49:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-22 01:49:53 - TARGET=i386 TB --- 2010-03-22 01:49:53 - TARGET_ARCH=i386 TB --- 2010-03-22 01:49:53 - TZ=UTC TB --- 2010-03-22 01:49:53 - __MAKE_CONF=/dev/null TB --- 2010-03-22 01:49:53 - cd /src TB --- 2010-03-22 01:49:53 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon Mar 22 01:49:53 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/qdivrem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/compat/x86bios/x86bios.c cc1: warnings being treated as errors /src/sys/compat/x86bios/x86bios.c: In function 'x86bios_map_mem': /src/sys/compat/x86bios/x86bios.c:558: warning: cast to pointer from integer of different size *** Error code 1 Stop in /obj/i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-22 01:54:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-22 01:54:42 - ERROR: failed to build PAE kernel TB --- 2010-03-22 01:54:42 - 5071.82 user 904.86 system 6581.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 02:00: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 4E831106564A; Mon, 22 Mar 2010 02:00:03 +0000 (UTC) (envelope-from jhellenthal@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 8A4548FC18; Mon, 22 Mar 2010 02:00:02 +0000 (UTC) Received: by gyg13 with SMTP id 13so858788gyg.13 for ; Sun, 21 Mar 2010 19:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=lnt2qNgAuxpKpdjwMqwtOPKBUNHtTgq0InbXtTpmM/M=; b=Nl87VGlHgHZ3E9fLZDedJ1RIY5ohRk94naKPVyg0anuva6N8yvee9Q92Cd51mGA3D5 yQCjg269ytiPuA5cS6KKdh975ciD5fQ+piWe/onmyd6/h4T5Jddv4cC3Q+hifrb/pMnp F2VmuwIhaN+mWNx6T7p7MEee8CcBpYSxAdLoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=KnwlFLO7KAHKOiNCAsTxvOI9uoNy/UamB7ZaqvDPGZ/I9i15lq62RJrdbfSAnLNjj6 mgBo5i/ujKqBpsTK87mj1+stO34yVpx7P6HqA7lgPmjxEJVLWOyV4CNUmrhZLlRp6S5m nicdZkC2Rx+PpHnDB5LzknO8XL7qN1HgEyzO0= Received: by 10.90.40.17 with SMTP id n17mr3603308agn.3.1269223201919; Sun, 21 Mar 2010 19:00:01 -0700 (PDT) Received: from ppp-23.181.dialinfree.com (ppp-23.181.dialinfree.com [209.172.23.181]) by mx.google.com with ESMTPS id 22sm2697042iwn.4.2010.03.21.18.59.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 19:00:01 -0700 (PDT) Sender: "J. Hellenthal" Date: Sun, 21 Mar 2010 22:00:21 -0400 From: jhell To: Alexander Motin In-Reply-To: Message-ID: References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <4BA532FF.6040407@elischer.org> <4BA62757.7090400@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 02:00:03 -0000 On Sun, 21 Mar 2010 20:54, jhell@ wrote: > > On Sun, 21 Mar 2010 10:04, mav@ wrote: >> Julian Elischer wrote: >>> In the Fusion-io driver we find that the limiting factor is not the >>> size of MAXPHYS, but the fact that we can not push more than >>> 170k tps through geom. (in my test machine. I've seen more on some >>> beefier machines), but that is only a limit on small transacrtions, >>> or in the case of large transfers the DMA engine tops out before a >>> bigger MAXPHYS would make any difference. >> >> Yes, GEOM is quite CPU-hungry on high request rates due to number of >> context switches. But impact probably may be reduced from two sides: by >> reducing overhead per request, or by reducing number of requests. Both >> ways may give benefits. >> >> If common opinion is not to touch defaults now - OK, agreed. (Note, >> Scott, I have agreed :)) But returning to the original question, does >> somebody knows real situation when increased MAXPHYS still causes >> problems? At least to make it safe. >> >> > > I played with it on one re-compile of a kernel and for the sake of it > DFLTPHYS=128 MAXPHYS=256 and found out that I could not cause a crash dump to > be performed upon request (reboot -d) due to the boundary being hit for DMA > which is 65536. Obviously this would have to be adjusted in ata-dma.c. > > I suppose that there would have to be a better way to get the real allowable > boundary from the running system instead of setting it statically. > > Other then the above I do not see a reason why not... It is HEAD and this is > the type of experimental stuff it was meant for. > > Regards, > > I should have also said that I also repeated the above without setting DFLTPHYS and setting MAXPHYS to 256. Regards, -- jhell From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 02:06: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 36D59106566C; Mon, 22 Mar 2010 02:06:39 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by mx1.freebsd.org (Postfix) with ESMTP id DD32B8FC12; Mon, 22 Mar 2010 02:06:38 +0000 (UTC) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by services.rulez.sk (Postfix) with ESMTP id 4F131133474B; Mon, 22 Mar 2010 03:06:37 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.rulez.sk ([92.240.234.125]) by services.rulez.sk (services.rulez.sk [92.240.234.125]) (amavisd-new, port 10024) with ESMTP id TdvBe5qPEFWy; Mon, 22 Mar 2010 03:06:31 +0100 (CET) Received: from danger-mbp.local (danger.mcrn.sk [84.16.37.254]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.rulez.sk (Postfix) with ESMTPSA id C75A51334715; Mon, 22 Mar 2010 03:06:31 +0100 (CET) Message-ID: <4BA6D0A7.7010107@FreeBSD.org> Date: Mon, 22 Mar 2010 03:06:31 +0100 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.2pre) Gecko/20100311 Lanikai/3.1b2pre MIME-Version: 1.0 To: current@freebsd.org, stable@freebsd.org, hackers@freebsd.org, questions@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: HEADSUP: Call for FreeBSD Status Reports - 1Q/2010 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, 22 Mar 2010 02:06:39 -0000 Dear all, I would like to remind you that the next round of status reports covering the first quarter of 2010 is due on April 15th, 2010. This initiative is very welcome in our community. Therefore, I would like to ask you to submit your status reports as soon as possible, so that we can compile the report on time. There is a lot of projects which are currently being worked on, so do not hesitate and write us a few lines - a short description about what you are working on, what are your plans and goals, so we can inform our community about your great work! Check out the reports from past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved with the FreeBSD community, you do not have to be a FreeBSD committer. Submissions about anything related to FreeBSD are very welcome! Please email us the filled-in XML template to be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 05:53: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 E5782106566B; Mon, 22 Mar 2010 05:53:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3FDCF8FC0C; Mon, 22 Mar 2010 05:53:19 +0000 (UTC) Received: by fxm1 with SMTP id 1so4966687fxm.33 for ; Sun, 21 Mar 2010 22:53:19 -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=LjlcvBytxdFQIJQwccw31J8lb75cHk6eQciz2IhvwG8=; b=SepHsS2rn5zJs84hWeqxl4zmqXBpYpATOv7BBjkTEYM8gF5vlXiXnRCh5u1/VRzgfL tCugsD+97NuC2I5uyvINHcFTjtjYhFwiQRVIeKJGVRvBkNyju4QWFDT4GXEHL/YKJPf8 CszrVTT3nxcAXPWSPyKS/jkDOCE4K4PB8ohu4= 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=vCkXmbo8zXDVgMBKWi0I26CY5GGVhFdjYp2dV1Zudo11qqLLCoABj9b9j/KoCVlBOt lq95kS7wr2tu9ZywI7dhtWBv7+Qa8uzJomtwNNNHyTjBOGtrN37ssghh3JIxEiLzdvBa WyBzJoUTlPc8ucrTc5Tu0gxZqABaDGeG4UWRA= Received: by 10.223.5.75 with SMTP id 11mr3756400fau.46.1269237199101; Sun, 21 Mar 2010 22:53:19 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm3294631fxm.13.2010.03.21.22.53.17 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 22:53:18 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BA705CB.9090705@FreeBSD.org> Date: Mon, 22 Mar 2010 07:53:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: jhell References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <4BA532FF.6040407@elischer.org> <4BA62757.7090400@FreeBSD.org> 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-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 05:53:21 -0000 jhell wrote: > On Sun, 21 Mar 2010 20:54, jhell@ wrote: >> I played with it on one re-compile of a kernel and for the sake of it >> DFLTPHYS=128 MAXPHYS=256 and found out that I could not cause a crash >> dump to be performed upon request (reboot -d) due to the boundary >> being hit for DMA which is 65536. Obviously this would have to be >> adjusted in ata-dma.c. >> >> I suppose that there would have to be a better way to get the real >> allowable boundary from the running system instead of setting it >> statically. >> >> Other then the above I do not see a reason why not... It is HEAD and >> this is the type of experimental stuff it was meant for. > > I should have also said that I also repeated the above without setting > DFLTPHYS and setting MAXPHYS to 256. It was bad idea to increase DFLTPHYS. It is not intended to be increased. About DMA boundary, I do not very understand the problem. Yes, legacy ATA has DMA boundary of 64K, but there is no problem to submit S/G list of several segments. How long ago have you tried it, on which controller and which diagnostics do you have? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 07:55:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F327106564A for ; Mon, 22 Mar 2010 07:55:23 +0000 (UTC) (envelope-from dimitry@andric.com) 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 20E678FC12 for ; Mon, 22 Mar 2010 07:55:22 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:99c7:b547:bf57:f30c] (unknown [IPv6:2001:7b8:3a7:0:99c7:b547:bf57:f30c]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D80DC5C59; Mon, 22 Mar 2010 08:55:18 +0100 (CET) Message-ID: <4BA7226C.9050907@andric.com> Date: Mon, 22 Mar 2010 08:55:24 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.2pre) Gecko/20100311 Lanikai/3.1b2pre MIME-Version: 1.0 To: Garrett Cooper References: <201003211232.35497.ken@mthelicon.com> <20100321140304.37618e59@ernst.jennejohn.org> <20100321140804.48cd1876@ernst.jennejohn.org> <4BA63CB1.3000201@andric.com> <7d6fde3d1003211420j77b916cdt48de132ebe9a0b23@mail.gmail.com> In-Reply-To: <7d6fde3d1003211420j77b916cdt48de132ebe9a0b23@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Best , Pegasus Mc Cleaft , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 22 Mar 2010 07:55:23 -0000 On 2010-03-21 22:20, Garrett Cooper wrote: >> From gcc(1): >> >> -s Remove all symbol table and relocation information from the exe- >> cutable. >> >> This is more or less the same as running strip(1) over the produced >> executables. Usually one uses it for non-debug builds. > > That seems a bit harsh (especially because that makes certain > libraries uses kind of moot, like *_p.a, right?). No, since -s only applies to the linking stage, so for executables or shared libraries. It does not apply to object files or libraries. It could be argued that -s really belongs in LDFLAGS... :) From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 08:07: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 92FB81065670 for ; Mon, 22 Mar 2010 08:07:36 +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 D74278FC28 for ; Mon, 22 Mar 2010 08:07:35 +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 KAA15455; Mon, 22 Mar 2010 10:07:32 +0200 (EET) (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 1Ntcfc-000Dg8-4F; Mon, 22 Mar 2010 10:07:32 +0200 Message-ID: <4BA72543.4060006@icyb.net.ua> Date: Mon, 22 Mar 2010 10:07:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Alexander Best References: 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 Subject: Re: build failures after stdlib update 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, 22 Mar 2010 08:07:36 -0000 on 22/03/2010 00:12 Alexander Best said the following: > Andriy Gapon schrieb am 2010-03-21: >> on 21/03/2010 23:11 Alexander Best said the following: >>> *hehe* that makes more sense. well i already sent you lp. >>> unfortunately str is >>> not available to gdb: > >>> (gdb) print str >>> Variable "str" is not available. > >> In cases like this sometimes the argument is still available for >> examination as >> a variable further down the stack (i.e. in one of the calling >> functions). > > hmmm... > > str might be "-m" then, because of: > > #1 0x0000000000416782 in concat (first=0x417618 "-m") at > /usr/src/gnu/usr.bin/cc/libiberty/../../../../contrib/gcclibs/libiberty/concat.c:76 > Perhaps, but doesn't look like it. Could you please do 'print *lp'? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 08:19:35 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 CD1E2106566B; Mon, 22 Mar 2010 08:19:35 +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 D1EE08FC1B; Mon, 22 Mar 2010 08:19:34 +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 KAA16328; Mon, 22 Mar 2010 10:19:31 +0200 (EET) (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 1NtcrD-000DoM-68; Mon, 22 Mar 2010 10:19:31 +0200 Message-ID: <4BA72812.8080405@icyb.net.ua> Date: Mon, 22 Mar 2010 10:19:30 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Garrett Cooper References: <201003210458.o2L4w8ZN041165@freebsd-current.sentex.ca> <7d6fde3d1003202325u5bc2adf0sfec35a9d0509eb55@mail.gmail.com> In-Reply-To: <7d6fde3d1003202325u5bc2adf0sfec35a9d0509eb55@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, Jung-uk Kim , i386@FreeBSD.org Subject: Re: [head tinderbox] failure on i386/i386 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, 22 Mar 2010 08:19:35 -0000 on 21/03/2010 08:25 Garrett Cooper said the following: > On Sat, Mar 20, 2010 at 9:58 PM, FreeBSD Tinderbox > wrote: >> TB --- 2010-03-21 04:53:25 - /usr/bin/make -B buildkernel KERNCONF=PAE >>>>> Kernel build for PAE started on Sun Mar 21 04:53:25 UTC 2010 >>>>> stage 1: configuring the kernel >>>>> stage 2.1: cleaning up the object tree >>>>> stage 2.2: rebuilding the object tree >>>>> stage 2.3: build tools >>>>> stage 3.1: making dependencies >>>>> stage 3.2: building everything >> [...] >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/qdivrem.c >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/udivdi3.c >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/compat/x86bios/x86bios.c >> cc1: warnings being treated as errors >> /src/sys/compat/x86bios/x86bios.c: In function 'x86bios_map_mem': >> /src/sys/compat/x86bios/x86bios.c:558: warning: cast to pointer from integer of different size >> *** Error code 1 >> >> Stop in /obj/i386/src/sys/PAE. >> *** Error code 1 >> >> Stop in /src. >> *** Error code 1 >> >> Stop in /src. >> TB --- 2010-03-21 04:58:08 - WARNING: /usr/bin/make returned exit code 1 >> TB --- 2010-03-21 04:58:08 - ERROR: failed to build PAE kernel >> TB --- 2010-03-21 04:58:08 - 5080.43 user 936.95 system 6788.14 real > > Hi Jung, > Could you please resolve this error? > Thanks, It would have been nice to actually CC Jung-uk :-) The problem seems to be that with PAE type of x86bios_rom_phys, vm_paddr_t, is 64-bit. I am not sure what values x86bios_rom_phys can have, but most likely it can be simply cast to a 32-bit value. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 08:23: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 351A01065673; Mon, 22 Mar 2010 08:23:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E88F98FC1A; Mon, 22 Mar 2010 08:23:45 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 27AF56435; Mon, 22 Mar 2010 08:23:44 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id o2M8NhGQ005755; Mon, 22 Mar 2010 08:23:43 GMT (envelope-from phk@critter.freebsd.dk) To: Andriy Gapon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 21 Mar 2010 16:56:32 +0200." <4BA633A0.2090108@icyb.net.ua> Date: Mon, 22 Mar 2010 08:23:43 +0000 Message-ID: <5754.1269246223@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Alexander Motin , freebsd-current@FreeBSD.org, Ivan Voras , freebsd-arch@FreeBSD.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 08:23:46 -0000 In message <4BA633A0.2090108@icyb.net.ua>, Andriy Gapon writes: >on 21/03/2010 16:05 Alexander Motin said the following: >> Ivan Voras wrote: >>> Hmm, it looks like it could be easy to spawn more g_* threads (and, >>> barring specific class behaviour, it has a fair chance of working out of >>> the box) but the incoming queue will need to also be broken up for >>> greater effect. >> >> According to "notes", looks there is a good chance to obtain races, as >> some places expect only one up and one down thread. > >I haven't given any deep thought to this issue, but I remember us discussing >them over beer :-) The easiest way to obtain more parallelism, is to divide the mesh into multiple independent meshes. This will do you no good if you have five disks in a RAID-5 config, but if you have two disks each mounted on its own filesystem, you can run a g_up & g_down for each of them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 09:40: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 1A87F10656DB for ; Mon, 22 Mar 2010 09:40:20 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay2.uni-muenster.de (ZIVM-RELAY2.UNI-MUENSTER.DE [128.176.192.13]) by mx1.freebsd.org (Postfix) with ESMTP id 684218FC1C for ; Mon, 22 Mar 2010 09:40:18 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,286,1267398000"; d="scan'208";a="239732949" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 22 Mar 2010 10:40:17 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 5D5F71B0750; Mon, 22 Mar 2010 10:40:17 +0100 (CET) Date: Mon, 22 Mar 2010 10:40:16 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Andriy Gapon Message-ID: In-Reply-To: <4BA72543.4060006@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 22 Mar 2010 09:40:20 -0000 Andriy Gapon schrieb am 2010-03-22: > on 22/03/2010 00:12 Alexander Best said the following: > > Andriy Gapon schrieb am 2010-03-21: > >> on 21/03/2010 23:11 Alexander Best said the following: > >>> *hehe* that makes more sense. well i already sent you lp. > >>> unfortunately str is > >>> not available to gdb: > >>> (gdb) print str > >>> Variable "str" is not available. > >> In cases like this sometimes the argument is still available for > >> examination as > >> a variable further down the stack (i.e. in one of the calling > >> functions). > > hmmm... > > str might be "-m" then, because of: > > #1 0x0000000000416782 in concat (first=0x417618 "-m") at > > /usr/src/gnu/usr.bin/cc/libiberty/../../../../contrib/gcclibs/libiberty/concat.c:76 > Perhaps, but doesn't look like it. > Could you please do 'print *lp'? (gdb) print *lp Cannot access memory at address 0xc092f0 -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 11:40:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67F76106566B; Mon, 22 Mar 2010 11:40:22 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id F05B68FC1C; Mon, 22 Mar 2010 11:40:21 +0000 (UTC) Received: from [195.4.92.23] (helo=13.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1NtfzY-00006b-7Q; Mon, 22 Mar 2010 12:40:20 +0100 Received: from p57ae04cc.dip0.t-ipconnect.de ([87.174.4.204]:10019 helo=ernst.jennejohn.org) by 13.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1NtfzY-0005Bb-0v; Mon, 22 Mar 2010 12:40:20 +0100 Date: Mon, 22 Mar 2010 12:40:18 +0100 From: Gary Jennejohn To: Alexander Motin Message-ID: <20100322124018.7430f45e@ernst.jennejohn.org> In-Reply-To: <4BA6517C.3050509@FreeBSD.org> References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <39C5864C-8A6B-4137-8743-D7B9F30F5939@samsco.org> <4BA6517C.3050509@FreeBSD.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 11:40:22 -0000 On Sun, 21 Mar 2010 19:03:56 +0200 Alexander Motin wrote: > Scott Long wrote: > > Are there non-CAM drivers that look at MAXPHYS, or that silently assume that > > MAXPHYS will never be more than 128k? > > That is a question. > I only did a quick&dirty grep looking for MAXPHYS in /sys. Some drivers redefine MAXPHYS to be 512KiB. Some use their own local MAXPHYS which is usually 128KiB. Some look at MAXPHYS to figure out other things; the details escape me. There's one driver which actually uses 100*MAXPHYS for something, but I didn't check the details. Lots of them were non-CAM drivers AFAICT. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 12:04:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EB591065672; Mon, 22 Mar 2010 12:04:11 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by mx1.freebsd.org (Postfix) with ESMTP id 26F888FC1C; Mon, 22 Mar 2010 12:04:10 +0000 (UTC) Received: by ywh1 with SMTP id 1so2170814ywh.3 for ; Mon, 22 Mar 2010 05:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=Q0TLee2Xb/op3xmQ9a+cXBbAbLdMvc2aiEzid93P5q0=; b=Z4bUjcMKqcpWet+SLF3N5Ye3tj4Jyjs94hd1cZPGuqkvDkdpNpLHuaIxuc4BJsUOLG qyZxXDmgbmMN/uT+nSC+LOz5Yev+bdNmXDzQ+9h4oeGukew0jf+SCkkX0XGsDvoLZQbh qvUY5d3FvV7OiX1AQN0PDQf5bwBWD9BScrhsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=OzSNpoKlj9FwfCJpgW4QZ37jBLC6ZsoPF721wX88D0BfIxz6cwi+QmCnwCr8gdPMFl 6J4WspbZKfT2hHSgJXddIghx68+fnFF/f1uTUoh6YOwqLxKXX9aElkg8g8a/FbamIECX 40AkmUULIcwiLVvDGfkGe6yqFzRLCMrIDvgPw= Received: by 10.91.24.1 with SMTP id b1mr4137577agj.96.1269259433858; Mon, 22 Mar 2010 05:03:53 -0700 (PDT) Received: from centel.dataix.local (ppp-22.128.dialinfree.com [209.172.22.128]) by mx.google.com with ESMTPS id 21sm1764826ywh.32.2010.03.22.05.03.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 05:03:52 -0700 (PDT) Sender: "J. Hellenthal" Date: Mon, 22 Mar 2010 08:04:00 -0400 From: jhell To: Anton Shterenlikht In-Reply-To: <20100321182214.GK84236@mech-cluster241.men.bris.ac.uk> Message-ID: References: <20100317163230.GJ87732@mech-cluster241.men.bris.ac.uk> <20100319211535.GA76683@mech-cluster241.men.bris.ac.uk> <20100320154446.GE84236@mech-cluster241.men.bris.ac.uk> <20100320205337.GF84236@mech-cluster241.men.bris.ac.uk> <20100321182214.GK84236@mech-cluster241.men.bris.ac.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , freebsd-ia64@freebsd.org Subject: Re: csup/svn/ldd make host unresponsive [WAS: Re: ldd leaves the machine unresponsive] 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, 22 Mar 2010 12:04:11 -0000 On Sun, 21 Mar 2010 14:22, Anton Shterenlikht wrote: In Message-Id: <20100321182214.GK84236@mech-cluster241.men.bris.ac.uk> > On Sat, Mar 20, 2010 at 08:53:37PM +0000, Anton Shterenlikht wrote: >> On Sat, Mar 20, 2010 at 03:44:46PM +0000, Anton Shterenlikht wrote: >>> On Sat, Mar 20, 2010 at 07:27:43AM -0400, jhell wrote: >>>> >>>> On Fri, 19 Mar 2010 17:15, Anton Shterenlikht wrote: >>>> In Message-Id: <20100319211535.GA76683@mech-cluster241.men.bris.ac.uk> >>>> >>>>> On Thu, Mar 18, 2010 at 11:29:36AM -0400, jhell wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> >>>>>> >>>>>> On Wed, 17 Mar 2010 12:32, Anton Shterenlikht wrote: >>>>>> In Message-Id: <20100317163230.GJ87732@mech-cluster241.men.bris.ac.uk> >>>>>> >>>>>>> Just updated to ia64 r205248 >>>>>>> >>>>>>> If my problem is due to my mis-configuration, >>>>>>> I apologise in advance. >>>>>>> >>>>>>> I run this shell script after each upgrade >>>>>>> and 'make delete-old-libs' to check >>>>>>> if any shared objects need to be rebuilt: >>>>>>> >>>>>>> >>>>>>> >>>>>>> #!/bin/sh >>>>>>> >>>>>>> for file in `find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/local -name "*"` >>>>>>> do >>>>>>> echo $file >>>>>>> ldd $file >> /root/ldd_results 2> /dev/zero >>>>>>> done >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> This will probably do closer to what you actually would want to look for. >>>>>> >>>>>> Writing to /dev/zero ... I don't know never tried it since /dev/null is >>>>>> usually the standard place to throw trash. >>>>>> >>>>>> #!/bin/sh >>>>>> for file in `find /*bin /usr/*bin /usr/lib* /usr/local/*bin -type f` do >>>>>> echo $file >>>>>> ldd $file >>/root/ldd_results 2>/dev/null >>>>>> done >>>>>> >>>>>> The problem with your script is that it finds most files that it can not >>>>>> or is not useful to run ldd on and leaves you junk in return. >>>>>> >>>>>> It might be more useful if you searched for dynamically linked ELF >>>>>> binaries to run ldd against like the following. >>>>>> >>>>>> === Script starts here === >>>>>> #!/bin/sh >>>>>> >>>>>> SEARCHPATH="/*bin /usr/*bin /usr/lib* /usr/local/*bin" >>>>>> >>>>>> trap 'exit 1' 2 >>>>>> >>>>>> check_libs() { >>>>>> for spath in $SEARCHPATH; do >>>>>> for ifelf in `find $spath -type f`; do >>>>>> ldd `file $ifelf | grep dynamically | cut -f1 -d:` >>>>>> done >>>>>> done >>>>>> } >>>>>> >>>>>> check_libs 2>/dev/null >>>>>> === Script ends here === >>>>>> >>>>>> The above will find all type ELF * that are dynamically linked within the >>>>>> SEARCHPATH variable and run ldd on them and print the results to stdout. >>>>>> >>>>>> Obviously since you are going to have thousands of files being questioned, >>>>>> stdout is not going to be useful. >>>>>> >>>>>> So with the about stated: >>>>>> save the script to: checklibs.sh >>>>>> run with: "sh checklibs.sh >/root/checklibs_output" >>>>>> or: "script /root/checklibs_output checklibs.sh" >>>>>> >>>>>>> After the upgrade to r205248, the script >>>>>>> freezes at seemingly random points. >>>>>>> >>>>>> >>>>>> Unneeded disk usage & execution. >>>>>> >>>>>>> I can still ssh to the machine (using keys), i.e. >>>>>>> I see the welcome message, but cannot get to the console prompt. >>>>>> >>>>>> Of course... to many open files or processes in wait. SSH already has the >>>>>> information it needs loaded into memory, that's why you can get sort-of-in >>>>>> >>>>>> ZFS file-system perhaps ? >>>>> >>>>> I've no ZFS. >>>>> >>>>> I'm seeing very similar behaviour now with csup: >>>>> >>>>> ( I do csup -L2 /root/ports-supfile, where >>>>> >>>>> # cat /root/ports-supfile >>>>> *default host=cvsup.uk.FreeBSD.org >>>>> *default base=/var/db >>>>> *default prefix=/usr >>>>> *default release=cvs tag=. delete use-rel-suffix compress >>>>> >>>>> ports-all >>>>> # ) >>>>> >>>>> top(1) shows: >>>>> >>>>> last pid: 1160; load averages: 0.00, 0.06, 0.07 up 0+00:10:53 15:05:52 >>>>> 81 processes: 3 running, 61 sleeping, 17 waiting >>>>> CPU 0: 0.0% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.8% idle >>>>> CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle >>>>> Mem: 23M Active, 19M Inact, 75M Wired, 136K Cache, 34M Buf, 5900M Free >>>>> Swap: 2780M Total, 2780M Free >>>>> >>>>> PID UID THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >>>>> 10 0 2 171 ki31 0K 64K RUN 0 20:18 198.00% idle >>>>> 11 0 17 -48 - 0K 544K WAIT 0 0:01 0.00% intr >>>>> 1118 1001 1 96 0 12800K 3920K CPU0 0 0:00 0.00% top >>>>> 4 0 1 -8 - 0K 32K - 1 0:00 0.00% g_down >>>>> 1158 0 4 -8 0 43672K 6296K biowr 0 0:00 0.00% csup >>>>> >>>>> >>>>> which stays in biowr state indefinitely. >>>>> >>>>> I can issue kill -9 or kill -HUP from top(1), >>>>> which makes csup change state to STOP, but >>>>> nothing else happens. >>>>> >>>>> As before, I can't log in from other terminals >>>>> and have to do a cold reset. I've reinstalled >>>>> on another disk, so not sure what's going on. >>>>> >>>>> I think rm(1) is also extremely slow, but >>>>> maybe I'm imagining things. >>>>> >>>>> many thanks >>>>> anton >>>>> >>>>> >>>> >>>> >>>> I would post up the contents of your make.conf & your kernel config & your >>>> dmesg somewhere so it can be evaluated. >>> >>> When I reinstalled 8.0 from a CD, >>> I updated source with csup, that worked. >>> However, after upgrading to current, I can't get >>> any luck with csup. The important bit is that >>> I don't really know what revision this is. >>> >>> I've no /etc/make.conf >>> >>> kernel config: >>> http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/UZI >>> >>> dmesg: >>> http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/dmesg.boot >>> >> >> Marcel, this might be of some interest. >> >> I managed to csup /usr/src, probably because >> there was not too many updates from 3 days ago. >> I proceeded with updating the system, but >> had a freeze again in single user at the very >> beginning of 'make installworld'. >> >> Now I've reinstalled 8.0-CURRENT-200906 >> snapshot and have no issues with csup, >> just completed downloading the ports tree. >> It seems something is wrong with csup(1), >> or pehaps disk i/o, in the recent ia64 updates. >> >> I'll try building svn from ports and update >> via svn, will report the results. > > An update: > > 1. reinstalled from 8.0-CURRENT-200906 > > 2. installed the ports tree via csup(1) > > 3. installed svn(1) from ports > > 4. updated src with svn. > Both svn and csup worked fine here. > > 5. rebuilt and reinstalled kernel and world as > usual to r205403. > > 6. rebooted. > The kernel config file: > http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/UZI > > dmesg: > http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/dmesg.boot > > ifconfig -a: > http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/ifconfig-a > > > 7. tried to update the src again with svn and got stuck. > All I can issue is CTRL/T, which shows for svn: : : mech-as221# svn co svn://svn.freebsd.org/base/head/ /usr/src/ : Not that this has anything to do with your problem but might turn into a problem if it is not your intent. But the above command will update your src to 9.0-CURRENT If it is your intention to stay on 8.0-* you might want to use one of the following: For checkout: (8.0-STABLE) svn co svn://svn.freebsd.org/base/stable/8/ /usr/src/ For checkout: (8.0-RELEASE-pN) svn co svn://svn.freebsd.org/base/releng/8.0/ /usr/src/ For updating: (after initial checkout) cd /usr/src ;svn update [-r%REVISION%] Then again maybe this is the problem... If you updated to current and did not rebuild your ports tree then that might be a factor of the problem. Regards, -- jhell From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 12:45:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B6821065675; Mon, 22 Mar 2010 12:45:13 +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 632808FC1B; Mon, 22 Mar 2010 12:45:13 +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 o2MCjCAN083845; Mon, 22 Mar 2010 08:45:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2MCjCEJ083840; Mon, 22 Mar 2010 12:45:12 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 22 Mar 2010 12:45:12 GMT Message-Id: <201003221245.o2MCjCEJ083840@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 12:45:13 -0000 TB --- 2010-03-22 10:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-22 10:55:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-03-22 10:55:00 - cleaning the object tree TB --- 2010-03-22 10:55:21 - cvsupping the source tree TB --- 2010-03-22 10:55:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-03-22 10:57:06 - building world TB --- 2010-03-22 10:57:06 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-22 10:57:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-22 10:57:06 - TARGET=i386 TB --- 2010-03-22 10:57:06 - TARGET_ARCH=i386 TB --- 2010-03-22 10:57:06 - TZ=UTC TB --- 2010-03-22 10:57:06 - __MAKE_CONF=/dev/null TB --- 2010-03-22 10:57:06 - cd /src TB --- 2010-03-22 10:57:06 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 22 10:57:07 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 Mon Mar 22 11:56:20 UTC 2010 TB --- 2010-03-22 11:56:20 - generating LINT kernel config TB --- 2010-03-22 11:56:20 - cd /src/sys/i386/conf TB --- 2010-03-22 11:56:20 - /usr/bin/make -B LINT TB --- 2010-03-22 11:56:20 - building LINT kernel TB --- 2010-03-22 11:56:20 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-22 11:56:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-22 11:56:20 - TARGET=i386 TB --- 2010-03-22 11:56:20 - TARGET_ARCH=i386 TB --- 2010-03-22 11:56:20 - TZ=UTC TB --- 2010-03-22 11:56:20 - __MAKE_CONF=/dev/null TB --- 2010-03-22 11:56:20 - cd /src TB --- 2010-03-22 11:56:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 22 11:56:20 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Mar 22 12:21:18 UTC 2010 TB --- 2010-03-22 12:21:18 - building GENERIC kernel TB --- 2010-03-22 12:21:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-22 12:21:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-22 12:21:18 - TARGET=i386 TB --- 2010-03-22 12:21:18 - TARGET_ARCH=i386 TB --- 2010-03-22 12:21:18 - TZ=UTC TB --- 2010-03-22 12:21:18 - __MAKE_CONF=/dev/null TB --- 2010-03-22 12:21:18 - cd /src TB --- 2010-03-22 12:21:18 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Mar 22 12:21:18 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Mar 22 12:40:30 UTC 2010 TB --- 2010-03-22 12:40:30 - building PAE kernel TB --- 2010-03-22 12:40:30 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-22 12:40:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-22 12:40:30 - TARGET=i386 TB --- 2010-03-22 12:40:30 - TARGET_ARCH=i386 TB --- 2010-03-22 12:40:30 - TZ=UTC TB --- 2010-03-22 12:40:30 - __MAKE_CONF=/dev/null TB --- 2010-03-22 12:40:30 - cd /src TB --- 2010-03-22 12:40:30 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon Mar 22 12:40:30 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/qdivrem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/compat/x86bios/x86bios.c cc1: warnings being treated as errors /src/sys/compat/x86bios/x86bios.c: In function 'x86bios_map_mem': /src/sys/compat/x86bios/x86bios.c:558: warning: cast to pointer from integer of different size *** Error code 1 Stop in /obj/i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-22 12:45:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-22 12:45:12 - ERROR: failed to build PAE kernel TB --- 2010-03-22 12:45:12 - 5066.77 user 912.35 system 6611.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 12:49:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E97541065672; Mon, 22 Mar 2010 12:49:39 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6438FC13; Mon, 22 Mar 2010 12:49:39 +0000 (UTC) Received: from outgoing.leidinger.net (pD954FF67.dip.t-dialin.net [217.84.255.103]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id B0E49844B26; Mon, 22 Mar 2010 13:49:32 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id B6DFA51BD; Mon, 22 Mar 2010 13:49:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1269262169; bh=miJRW5cP0VaYHI4A2iGYb0DMJ9f7jCJcF67EwyWNwqI=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ril+FxhmXGESKr4Za6mQCSymfbUrc9XBXsD9zGFHNes2J1PIiOB+QUdZ1r3AL9+Jb wyUYVJVWbVjmZjDwNno1QKujzbFPm/HIUMTdaX2EtXrJ+bLxn1rgEz2mUMAO65sq5U Mx5HtrRF0RiGNIwStS9YPuFg0N/3XypjWxvg6iJFSu4yubdWOGybi4FLTjU6ctLf9v oM1uXvwSAbJ66NHWIMyM9SHSrF32BZEdj7cdDUXfyoEjyUV9dOQmEFyUwtrPhHjJBw 8JMorRcHCIDAcTC1nU6oL0rPjmPM0xJO8vj71sMxFxj/l1YM0YY6xVoXfaoyjbBp3M t7ikQld7icwcA== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o2MCnSxq048872; Mon, 22 Mar 2010 13:49:28 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 22 Mar 2010 13:49:28 +0100 Message-ID: <20100322134928.83045xnbh4nkqzok@webmail.leidinger.net> Date: Mon, 22 Mar 2010 13:49:28 +0100 From: Alexander Leidinger To: Scott Long References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> In-Reply-To: <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: B0E49844B26.A3C70 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1269866973.60709@WBDkZuiQeW9/cn/c0e+A1Q X-EBL-Spam-Status: No Cc: FreeBSD-Current , Alexander Motin , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 12:49:40 -0000 Quoting Scott Long (from Sat, 20 Mar 2010 12:17:33 -0600): > code was actually taking advantage of the larger I/O's. The > improvement really > depends on the workload, of course, and I wouldn't expect it to be noticeable > for most people unless they're running something like a media server. I don't think this is limited to media servers, think about situations where you process a large amount of data seuqntially... (seuqntial access case in a big data-warehouse scenario or a 3D render farm which get's the huge amount of data from a shared resource ("how many render-clients can I support at the same time with my disk infrastructure"-scenario) or some of the bigtable/nosql stuff which seems to be more and more popular at some sites). There are enough situations where sequential file access is the key performance metric so that I wouldn't say that only media servers depend upon large sequential I/O's. Bye, Alexander. -- That's life. What's life? A magazine. How much does it cost? Two-fifty. I only have a dollar. That's life. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 14:51: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 EEBA31065676; Mon, 22 Mar 2010 14:51:03 +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 BE70A8FC1D; Mon, 22 Mar 2010 14:51:03 +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 7237346B35; Mon, 22 Mar 2010 10:51:03 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A67E98A025; Mon, 22 Mar 2010 10:51:02 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org, gary.jennejohn@freenet.de Date: Mon, 22 Mar 2010 08:39:12 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BA4E7A9.3070502@FreeBSD.org> <4BA6517C.3050509@FreeBSD.org> <20100322124018.7430f45e@ernst.jennejohn.org> In-Reply-To: <20100322124018.7430f45e@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003220839.12907.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 22 Mar 2010 10:51:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 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: Alexander Motin , FreeBSD-Current Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 14:51:04 -0000 On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote: > On Sun, 21 Mar 2010 19:03:56 +0200 > Alexander Motin wrote: > > > Scott Long wrote: > > > Are there non-CAM drivers that look at MAXPHYS, or that silently assume that > > > MAXPHYS will never be more than 128k? > > > > That is a question. > > > > I only did a quick&dirty grep looking for MAXPHYS in /sys. > > Some drivers redefine MAXPHYS to be 512KiB. Some use their own local > MAXPHYS which is usually 128KiB. > > Some look at MAXPHYS to figure out other things; the details escape me. > > There's one driver which actually uses 100*MAXPHYS for something, but I > didn't check the details. > > Lots of them were non-CAM drivers AFAICT. The problem is the drivers that _don't_ reference MAXPHYS. The driver author at the time "knew" that MAXPHYS was 128k, so he did the MAXPHYS-dependent calculation and just put the result in the driver (e.g. only supporting up to 32 segments (32 4k pages == 128k) in a bus dma tag as a magic number to bus_dma_tag_create() w/o documenting that the '32' was derived from 128k or what the actual hardware limit on nsegments is). These cannot be found by a simple grep, they require manually inspecting each driver. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 15:13:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EABF106566C; Mon, 22 Mar 2010 15:13:15 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 403A88FC0C; Mon, 22 Mar 2010 15:13:14 +0000 (UTC) Received: by fxm24 with SMTP id 24so1747017fxm.3 for ; Mon, 22 Mar 2010 08:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=DsRv+5AHwNnZAxbyt2GiWovNe3F9FVZXx5YY0zZIM3k=; b=cMFUq1MxzJL1ie5YQCMyJKtoccBfrg6XvNvcgOne9/4RllPgIR3Yrn3l+cVk0is0a/ dDcpF6X4W6p9ecQKE44WTPgxGfPQrWVNqGEuyPch1CX1NTem3GJfUnCWHqebvmojicuS A4jlQGYXlBLIrnutF645ShZ7mpeEOatO+ztaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=vfmy+Ly6x0Efvy4ohd+N4UjfdonSCczYib5P6Knfvs6azXETqPnPeJED1YuhOD0OyX +Pco24Lzt0MoTieJahGIyCsSEErWLHpUGgvcwdlcu6Tw16gyCvE5MU/7RkIoM/YinWym PLBTfOHfP6je0B8POWS4APM3s6r2+VoiP+56E= Received: by 10.223.58.83 with SMTP id f19mr2826229fah.88.1269270793405; Mon, 22 Mar 2010 08:13:13 -0700 (PDT) Received: from centel.dataix.local (ppp-21.63.dialinfree.com [209.172.21.63]) by mx.google.com with ESMTPS id 13sm3894781fxm.14.2010.03.22.08.12.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 08:13:12 -0700 (PDT) Sender: "J. Hellenthal" Date: Mon, 22 Mar 2010 11:11:55 -0400 From: jhell To: Alexander Motin In-Reply-To: <4BA705CB.9090705@FreeBSD.org> Message-ID: References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <4BA532FF.6040407@elischer.org> <4BA62757.7090400@FreeBSD.org> <4BA705CB.9090705@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 15:13:15 -0000 On Mon, 22 Mar 2010 01:53, Alexander Motin wrote: In Message-Id: <4BA705CB.9090705@FreeBSD.org> > jhell wrote: >> On Sun, 21 Mar 2010 20:54, jhell@ wrote: >>> I played with it on one re-compile of a kernel and for the sake of it >>> DFLTPHYS=128 MAXPHYS=256 and found out that I could not cause a crash >>> dump to be performed upon request (reboot -d) due to the boundary >>> being hit for DMA which is 65536. Obviously this would have to be >>> adjusted in ata-dma.c. >>> >>> I suppose that there would have to be a better way to get the real >>> allowable boundary from the running system instead of setting it >>> statically. >>> >>> Other then the above I do not see a reason why not... It is HEAD and >>> this is the type of experimental stuff it was meant for. >> >> I should have also said that I also repeated the above without setting >> DFLTPHYS and setting MAXPHYS to 256. > > It was bad idea to increase DFLTPHYS. It is not intended to be increased. > I just wanted to see what I could break; when I increased DFLTPHYS it was just for that purpose. It booted and everything was running after. Wasn't long enough to do any damage. > About DMA boundary, I do not very understand the problem. Yes, legacy > ATA has DMA boundary of 64K, but there is no problem to submit S/G list > of several segments. How long ago have you tried it, on which controller > and which diagnostics do you have? > > atapci0@pci0:0:31:1: class=0x01018a card=0x01271028 chip=0x24cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL (ICH4/ICH4-L) UltraATA/100 EIDE Controller' class = mass storage subclass = ATA I do not have any diagnostics but if any are requested I do have the kernel's that I have tuned to the above values readily available to run again. The first time I tuned MAXPHYS was roughly about 7 weeks ago. That was until I noticed I could not get a crash dump for a problem I was having a week later and had to revert back to its default setting of 128. The problem I had a week later was unrelated. Two days ago when I saw this thread I recalled having modified MAXPHYS but could not remember the problem it caused so I re-enabled it again to reproduce the problem for sureness. Anything else you need please address, Regards, -- jhell From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 15:52: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 5D58F1065742 for ; Mon, 22 Mar 2010 15:52:47 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CF9AC8FC12 for ; Mon, 22 Mar 2010 15:52:45 +0000 (UTC) Received: by gwj15 with SMTP id 15so3029253gwj.13 for ; Mon, 22 Mar 2010 08:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4kQo9/KiBiBLYVqfysneIeFu6+5+qsMJTr9lZrB0DLo=; b=xl5XQtSQwiLPK/zdSCeOm/L5erXKwLi8BNrgxczQYPoXBtupxOKVc3M0wD5WsdxER8 QwhcW3IZ77tKPs68ghbe2xv3uCyZAkB4drn2OJHzbwwlaBmA9xJuxGo/Fxcwi0wWj88w j1I6tJ8Bh/drdDXU2qhGpvBlPl9Q2ik/gKdWc= 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=mN8jORWhrg/qEYHrz+01St/nvznheNnXdYZp7aqfCNyHBkpDlmbkCL3MjsQc96K7z9 WeLd3FwZZlwHjpDez94qH+iL10cGDWaf7SucgFy2aa0OY+cm6XB2IoK88IxWrRGUF3zZ SD/HBR1cWqbF9SRIubpe87oQk14KG3Epp9ui0= MIME-Version: 1.0 Received: by 10.101.189.30 with SMTP id r30mr8435712anp.70.1269273165090; Mon, 22 Mar 2010 08:52:45 -0700 (PDT) In-Reply-To: <201003220839.12907.jhb@freebsd.org> References: <4BA4E7A9.3070502@FreeBSD.org> <4BA6517C.3050509@FreeBSD.org> <20100322124018.7430f45e@ernst.jennejohn.org> <201003220839.12907.jhb@freebsd.org> Date: Mon, 22 Mar 2010 11:52:44 -0400 Message-ID: <3c0b01821003220852r61ca0ae3o95bea1c23ddc34d9@mail.gmail.com> From: Alexander Sack To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 15:52:47 -0000 On Mon, Mar 22, 2010 at 8:39 AM, John Baldwin wrote: > On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote: >> On Sun, 21 Mar 2010 19:03:56 +0200 >> Alexander Motin wrote: >> >> > Scott Long wrote: >> > > Are there non-CAM drivers that look at MAXPHYS, or that silently ass= ume > that >> > > MAXPHYS will never be more than 128k? >> > >> > That is a question. >> > >> >> I only did a quick&dirty grep looking for MAXPHYS in /sys. >> >> Some drivers redefine MAXPHYS to be 512KiB. =A0Some use their own local >> MAXPHYS which is usually 128KiB. >> >> Some look at MAXPHYS to figure out other things; the details escape me. >> >> There's one driver which actually uses 100*MAXPHYS for something, but I >> didn't check the details. >> >> Lots of them were non-CAM drivers AFAICT. > > The problem is the drivers that _don't_ reference MAXPHYS. =A0The driver = author > at the time "knew" that MAXPHYS was 128k, so he did the MAXPHYS-dependent > calculation and just put the result in the driver (e.g. only supporting u= p to > 32 segments (32 4k pages =3D=3D 128k) in a bus dma tag as a magic number = to > bus_dma_tag_create() w/o documenting that the '32' was derived from 128k = or > what the actual hardware limit on nsegments is). =A0These cannot be found= by a > simple grep, they require manually inspecting each driver. 100% awesome comment. On another kernel, I myself was guilty of this crime (I did have a nice comment though above the def). This has been a great thread since our application really needs some of the optimizations that are being thrown around here. We have found in real live performance testing that we are almost always either controller bound (i.e. adding more disks to spread IOPs has little to no effect in large array configurations on throughput, we suspect that is hitting the RAID controller's firmware limitations) or tps bound, i.e. I never thought going from 128k -> 256k per transaction would have a dramatic effect on throughput (but I never verified). Back to HBAs, AFAIK, every modern iteration of the most popular HBAs can easily do way more than a 128k scatter/gather I/O. Do you guys know of any *modern* (circa within the last 3-4 years) that can not do more than 128k at a shot? In other words, I've always thought the limit was kernel imposed and not what the memory controller on the card can do (I certainly never got the impression talking with some of the IHVs over the years that they were designing their hardware for a 128k limit - I sure hope not!). -aps From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 16:11:38 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 184111065673; Mon, 22 Mar 2010 16:11:31 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 22 Mar 2010 12:11:08 -0400 User-Agent: KMail/1.6.2 References: <201003210458.o2L4w8ZN041165@freebsd-current.sentex.ca> <7d6fde3d1003202325u5bc2adf0sfec35a9d0509eb55@mail.gmail.com> <4BA72812.8080405@icyb.net.ua> In-Reply-To: <4BA72812.8080405@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003221211.13384.jkim@FreeBSD.org> Cc: Garrett Cooper , i386@freebsd.org, Andriy Gapon , current@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 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, 22 Mar 2010 16:11:38 -0000 On Monday 22 March 2010 04:19 am, Andriy Gapon wrote: > on 21/03/2010 08:25 Garrett Cooper said the following: > > On Sat, Mar 20, 2010 at 9:58 PM, FreeBSD Tinderbox > > > > wrote: > >> TB --- 2010-03-21 04:53:25 - /usr/bin/make -B buildkernel > >> KERNCONF=PAE > >> > >>>>> Kernel build for PAE started on Sun Mar 21 04:53:25 UTC 2010 > >>>>> stage 1: configuring the kernel > >>>>> stage 2.1: cleaning up the object tree > >>>>> stage 2.2: rebuilding the object tree > >>>>> stage 2.3: build tools > >>>>> stage 3.1: making dependencies > >>>>> stage 3.2: building everything > >> > >> [...] > >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls > >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > >> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/libkern/qdivrem.c cc -c -O > >> -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c cc -c -O > >> -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/libkern/udivdi3.c cc -c -O > >> -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O > >> -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/compat/x86bios/x86bios.c > >> cc1: warnings being treated as errors > >> /src/sys/compat/x86bios/x86bios.c: In function > >> 'x86bios_map_mem': /src/sys/compat/x86bios/x86bios.c:558: > >> warning: cast to pointer from integer of different size *** > >> Error code 1 > >> > >> Stop in /obj/i386/src/sys/PAE. > >> *** Error code 1 > >> > >> Stop in /src. > >> *** Error code 1 > >> > >> Stop in /src. > >> TB --- 2010-03-21 04:58:08 - WARNING: /usr/bin/make returned > >> exit code 1 TB --- 2010-03-21 04:58:08 - ERROR: failed to build > >> PAE kernel TB --- 2010-03-21 04:58:08 - 5080.43 user 936.95 > >> system 6788.14 real > > > > Hi Jung, > > Could you please resolve this error? > > Thanks, > > It would have been nice to actually CC Jung-uk :-) > The problem seems to be that with PAE type of x86bios_rom_phys, > vm_paddr_t, is 64-bit. > I am not sure what values x86bios_rom_phys can have, but most > likely it can be simply cast to a 32-bit value. Oops, sorry. It will be fixed soon. I am testing an i386/PAE kernel now. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 16:11:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 184111065673; Mon, 22 Mar 2010 16:11:31 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 22 Mar 2010 12:11:08 -0400 User-Agent: KMail/1.6.2 References: <201003210458.o2L4w8ZN041165@freebsd-current.sentex.ca> <7d6fde3d1003202325u5bc2adf0sfec35a9d0509eb55@mail.gmail.com> <4BA72812.8080405@icyb.net.ua> In-Reply-To: <4BA72812.8080405@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003221211.13384.jkim@FreeBSD.org> Cc: Garrett Cooper , i386@freebsd.org, Andriy Gapon , current@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 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, 22 Mar 2010 16:11:38 -0000 On Monday 22 March 2010 04:19 am, Andriy Gapon wrote: > on 21/03/2010 08:25 Garrett Cooper said the following: > > On Sat, Mar 20, 2010 at 9:58 PM, FreeBSD Tinderbox > > > > wrote: > >> TB --- 2010-03-21 04:53:25 - /usr/bin/make -B buildkernel > >> KERNCONF=PAE > >> > >>>>> Kernel build for PAE started on Sun Mar 21 04:53:25 UTC 2010 > >>>>> stage 1: configuring the kernel > >>>>> stage 2.1: cleaning up the object tree > >>>>> stage 2.2: rebuilding the object tree > >>>>> stage 2.3: build tools > >>>>> stage 3.1: making dependencies > >>>>> stage 3.2: building everything > >> > >> [...] > >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls > >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > >> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/libkern/qdivrem.c cc -c -O > >> -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c cc -c -O > >> -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/libkern/udivdi3.c cc -c -O > >> -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O > >> -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign > >> -fformat-extensions -nostdinc -I. -I/src/sys > >> -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >> -include opt_global.h -fno-common -finline-limit=8000 --param > >> inline-unit-growth=100 --param large-function-growth=1000 > >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding > >> -fstack-protector -Werror /src/sys/compat/x86bios/x86bios.c > >> cc1: warnings being treated as errors > >> /src/sys/compat/x86bios/x86bios.c: In function > >> 'x86bios_map_mem': /src/sys/compat/x86bios/x86bios.c:558: > >> warning: cast to pointer from integer of different size *** > >> Error code 1 > >> > >> Stop in /obj/i386/src/sys/PAE. > >> *** Error code 1 > >> > >> Stop in /src. > >> *** Error code 1 > >> > >> Stop in /src. > >> TB --- 2010-03-21 04:58:08 - WARNING: /usr/bin/make returned > >> exit code 1 TB --- 2010-03-21 04:58:08 - ERROR: failed to build > >> PAE kernel TB --- 2010-03-21 04:58:08 - 5080.43 user 936.95 > >> system 6788.14 real > > > > Hi Jung, > > Could you please resolve this error? > > Thanks, > > It would have been nice to actually CC Jung-uk :-) > The problem seems to be that with PAE type of x86bios_rom_phys, > vm_paddr_t, is 64-bit. > I am not sure what values x86bios_rom_phys can have, but most > likely it can be simply cast to a 32-bit value. Oops, sorry. It will be fixed soon. I am testing an i386/PAE kernel now. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 16:20:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B8BE1065673; Mon, 22 Mar 2010 16:20:22 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC608FC1C; Mon, 22 Mar 2010 16:20:22 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZO00EACYPK4F50@asmtp027.mac.com>; Mon, 22 Mar 2010 09:20:11 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003220173 From: Marcel Moolenaar In-reply-to: Date: Mon, 22 Mar 2010 09:20:07 -0700 Message-id: <2AEAB236-0168-42F1-B08B-9D23E8F6DE27@mac.com> References: <20100317163230.GJ87732@mech-cluster241.men.bris.ac.uk> <20100319211535.GA76683@mech-cluster241.men.bris.ac.uk> <20100320154446.GE84236@mech-cluster241.men.bris.ac.uk> <20100320205337.GF84236@mech-cluster241.men.bris.ac.uk> <20100321182214.GK84236@mech-cluster241.men.bris.ac.uk> To: jhell X-Mailer: Apple Mail (2.1077) Cc: FreeBSD Current , Anton Shterenlikht , freebsd-ia64@freebsd.org Subject: Re: csup/svn/ldd make host unresponsive [WAS: Re: ldd leaves the machine unresponsive] 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, 22 Mar 2010 16:20:22 -0000 On Mar 22, 2010, at 5:04 AM, jhell wrote: > > Not that this has anything to do with your problem but might turn into a problem if it is not your intent. But the above command will update your src to 9.0-CURRENT That is his intend. Anton: I fixed a bunch of things yesterday. You should be able to upgrade to HEAD. I have one more fix pending that's needed for preemption, but you should not hold off an upgrade for that... FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 16:27: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 93FC1106566B; Mon, 22 Mar 2010 16:27:19 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 5A26B8FC0C; Mon, 22 Mar 2010 16:27:19 +0000 (UTC) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o2MGRFPX050285; Mon, 22 Mar 2010 10:27:15 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <3c0b01821003220852r61ca0ae3o95bea1c23ddc34d9@mail.gmail.com> Date: Mon, 22 Mar 2010 10:27:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <50456989-F196-4907-A170-85806A73D25F@samsco.org> References: <4BA4E7A9.3070502@FreeBSD.org> <4BA6517C.3050509@FreeBSD.org> <20100322124018.7430f45e@ernst.jennejohn.org> <201003220839.12907.jhb@freebsd.org> <3c0b01821003220852r61ca0ae3o95bea1c23ddc34d9@mail.gmail.com> To: Alexander Sack X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 16:27:19 -0000 On Mar 22, 2010, at 9:52 AM, Alexander Sack wrote: > On Mon, Mar 22, 2010 at 8:39 AM, John Baldwin wrote: >> On Monday 22 March 2010 7:40:18 am Gary Jennejohn wrote: >>> On Sun, 21 Mar 2010 19:03:56 +0200 >>> Alexander Motin wrote: >>>=20 >>>> Scott Long wrote: >>>>> Are there non-CAM drivers that look at MAXPHYS, or that silently = assume >> that >>>>> MAXPHYS will never be more than 128k? >>>>=20 >>>> That is a question. >>>>=20 >>>=20 >>> I only did a quick&dirty grep looking for MAXPHYS in /sys. >>>=20 >>> Some drivers redefine MAXPHYS to be 512KiB. Some use their own = local >>> MAXPHYS which is usually 128KiB. >>>=20 >>> Some look at MAXPHYS to figure out other things; the details escape = me. >>>=20 >>> There's one driver which actually uses 100*MAXPHYS for something, = but I >>> didn't check the details. >>>=20 >>> Lots of them were non-CAM drivers AFAICT. >>=20 >> The problem is the drivers that _don't_ reference MAXPHYS. The = driver author >> at the time "knew" that MAXPHYS was 128k, so he did the = MAXPHYS-dependent >> calculation and just put the result in the driver (e.g. only = supporting up to >> 32 segments (32 4k pages =3D=3D 128k) in a bus dma tag as a magic = number to >> bus_dma_tag_create() w/o documenting that the '32' was derived from = 128k or >> what the actual hardware limit on nsegments is). These cannot be = found by a >> simple grep, they require manually inspecting each driver. >=20 > 100% awesome comment. On another kernel, I myself was guilty of this > crime (I did have a nice comment though above the def). >=20 > This has been a great thread since our application really needs some > of the optimizations that are being thrown around here. We have found > in real live performance testing that we are almost always either > controller bound (i.e. adding more disks to spread IOPs has little to > no effect in large array configurations on throughput, we suspect that > is hitting the RAID controller's firmware limitations) or tps bound, > i.e. I never thought going from 128k -> 256k per transaction would > have a dramatic effect on throughput (but I never verified). >=20 > Back to HBAs, AFAIK, every modern iteration of the most popular HBAs > can easily do way more than a 128k scatter/gather I/O. Do you guys > know of any *modern* (circa within the last 3-4 years) that can not do > more than 128k at a shot? >64K broken in MPT at the moment. The hardware can do it, the driver = thinks it can do it, but it fails. AAC hardware traditionally cannot, = but maybe the firmware has been improved in the past few years. I know = that there are other low-performance devices that can't do more than 64 = or 128K, but none are coming to mind at the moment. Still, it shouldn't = be a universal assumption that all hardware can do big I/O's. Another consideration is that some hardware can do big I/O's, but not = very efficiently. Not all DMA engines are created equal, and moving to = compound commands and excessively long S/G lists can be a pessimization. = For example, MFI hardware does a hinted prefetch on the segment list, = but once you exceed a certain limit, that prefetch doesn't work anymore = and the firmware has to take the slow path to execute the i/o. I = haven't quantified this penalty yet, but it's something that should be = thought about. >=20 > In other words, I've always thought the limit was kernel imposed and > not what the memory controller on the card can do (I certainly never > got the impression talking with some of the IHVs over the years that > they were designing their hardware for a 128k limit - I sure hope > not!). You'd be surprised at the engineering compromises and handicaps that are = committed at IHVs because of misguided marketters. Scott From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 17:52: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 D6A221065673 for ; Mon, 22 Mar 2010 17:52:13 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id A7D968FC0C for ; Mon, 22 Mar 2010 17:52:13 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id o2MHqD3d087650 for ; Mon, 22 Mar 2010 10:52:13 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id o2MHqDPh087649 for freebsd-current@freebsd.org; Mon, 22 Mar 2010 10:52:13 -0700 (PDT) (envelope-from obrien) Date: Mon, 22 Mar 2010 10:52:13 -0700 From: "David O'Brien" To: freebsd-current@freebsd.org Message-ID: <20100322175213.GA87475@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, freebsd-current@freebsd.org References: <4B9E332D.3090909@stillbilde.net> <4B9E5992.6020207@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9E5992.6020207@elischer.org> X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Subject: [PATCH] rename COMPAT_FREEBSD32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 17:52:13 -0000 On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote: > I certainly agree.. can it be changed please? I've waited a while to see what other opinions would be expressed on this topic. I believe there is sufficient support to rename COMPAT_FREEBSD32 to something else based on responses in the mailing lists. I am sorry if some may wish to label this a "bikeshead". But we seem to have many folks disliking "COMPAT_FREEBSD32". Based on responses to the topic of COMPAT_FREEBSD32, the following were the suggestions offered: COMPAT_ARCH32, COMPAT_ARCH_32BIT, COMPAT_32BIT_ARCH, COMPAT_32BIT, COMPAT_FREEBSD32BIT I went with the first as it seemed the most direct to me, but I find all but the last are suitable as well. (The last is probably too close to COMPAT_FREEBSDn given we do have other suggestions.) This patch was produced by checking out a fresh tree and running this command from the top level: wcfind sys -type f | xargs fgrep -l COMPAT_FREEBSD32 | xargs \ sed -i '' \ -e 's/COMPAT_FREEBSD32/COMPAT_ARCH32/g' \ -e 's/compat_freebsd32/compat_arch32/g' svn revert -R sys/compat/freebsd32 Thoughts? -- -- David (obrien@FreeBSD.org) Index: conf/options.amd64 =================================================================== --- conf/options.amd64 (revision 205451) +++ conf/options.amd64 (working copy) @@ -11,7 +11,7 @@ MP_WATCHDOG # Options for emulators. These should only be used at config time, so # they are handled like options for static filesystems # (see src/sys/conf/options), except for broken debugging options. -COMPAT_FREEBSD32 opt_compat.h +COMPAT_ARCH32 opt_compat.h #IBCS2 opt_dontuse.h #COMPAT_LINUX opt_dontuse.h COMPAT_LINUX32 opt_compat.h Index: conf/options.ia64 =================================================================== --- conf/options.ia64 (revision 205451) +++ conf/options.ia64 (working copy) @@ -9,7 +9,7 @@ LOG2_PAGE_SIZE opt_global.h UWX_TRACE_ENABLE opt_global.h -COMPAT_FREEBSD32 opt_compat.h +COMPAT_ARCH32 opt_compat.h EXCEPTION_TRACING opt_xtrace.h Index: conf/files.ia64 =================================================================== --- conf/files.ia64 (revision 205451) +++ conf/files.ia64 (working copy) @@ -28,11 +28,11 @@ ukbdmap.h optional ukbd_dflt_keymap \ no-obj no-implicit-rule before-depend \ clean "ukbdmap.h" # -compat/freebsd32/freebsd32_ioctl.c optional compat_freebsd32 -compat/freebsd32/freebsd32_misc.c optional compat_freebsd32 -compat/freebsd32/freebsd32_syscalls.c optional compat_freebsd32 -compat/freebsd32/freebsd32_sysent.c optional compat_freebsd32 -compat/ia32/ia32_sysvec.c optional compat_freebsd32 +compat/freebsd32/freebsd32_ioctl.c optional compat_arch32 +compat/freebsd32/freebsd32_misc.c optional compat_arch32 +compat/freebsd32/freebsd32_syscalls.c optional compat_arch32 +compat/freebsd32/freebsd32_sysent.c optional compat_arch32 +compat/ia32/ia32_sysvec.c optional compat_arch32 contrib/ia64/libuwx/src/uwx_bstream.c standard contrib/ia64/libuwx/src/uwx_context.c standard contrib/ia64/libuwx/src/uwx_env.c standard @@ -68,10 +68,10 @@ ia64/acpica/madt.c optional acpi ia64/disasm/disasm_decode.c standard ia64/disasm/disasm_extract.c standard ia64/disasm/disasm_format.c standard -ia64/ia32/ia32_misc.c optional compat_freebsd32 -ia64/ia32/ia32_reg.c optional compat_freebsd32 -ia64/ia32/ia32_signal.c optional compat_freebsd32 -ia64/ia32/ia32_trap.c optional compat_freebsd32 +ia64/ia32/ia32_misc.c optional compat_arch32 +ia64/ia32/ia32_reg.c optional compat_arch32 +ia64/ia32/ia32_signal.c optional compat_arch32 +ia64/ia32/ia32_trap.c optional compat_arch32 ia64/ia64/autoconf.c standard ia64/ia64/bus_machdep.c standard ia64/ia64/busdma_machdep.c standard @@ -117,7 +117,7 @@ ia64/isa/isa_dma.c optional isa ia64/pci/pci_cfgreg.c optional pci isa/syscons_isa.c optional sc isa/vga_isa.c optional vga -kern/imgact_elf32.c optional compat_freebsd32 +kern/imgact_elf32.c optional compat_arch32 libkern/bcmp.c standard libkern/ffsl.c standard libkern/fls.c standard Index: conf/files.amd64 =================================================================== --- conf/files.amd64 (revision 205451) +++ conf/files.amd64 (working copy) @@ -227,20 +227,20 @@ kern/link_elf_obj.c standard # # IA32 binary support # -#amd64/ia32/ia32_exception.S optional compat_freebsd32 -amd64/ia32/ia32_reg.c optional compat_freebsd32 -amd64/ia32/ia32_signal.c optional compat_freebsd32 -amd64/ia32/ia32_sigtramp.S optional compat_freebsd32 -amd64/ia32/ia32_syscall.c optional compat_freebsd32 -amd64/ia32/ia32_misc.c optional compat_freebsd32 -compat/freebsd32/freebsd32_ioctl.c optional compat_freebsd32 -compat/freebsd32/freebsd32_misc.c optional compat_freebsd32 -compat/freebsd32/freebsd32_syscalls.c optional compat_freebsd32 -compat/freebsd32/freebsd32_sysent.c optional compat_freebsd32 -compat/ia32/ia32_sysvec.c optional compat_freebsd32 +#amd64/ia32/ia32_exception.S optional compat_arch32 +amd64/ia32/ia32_reg.c optional compat_arch32 +amd64/ia32/ia32_signal.c optional compat_arch32 +amd64/ia32/ia32_sigtramp.S optional compat_arch32 +amd64/ia32/ia32_syscall.c optional compat_arch32 +amd64/ia32/ia32_misc.c optional compat_arch32 +compat/freebsd32/freebsd32_ioctl.c optional compat_arch32 +compat/freebsd32/freebsd32_misc.c optional compat_arch32 +compat/freebsd32/freebsd32_syscalls.c optional compat_arch32 +compat/freebsd32/freebsd32_sysent.c optional compat_arch32 +compat/ia32/ia32_sysvec.c optional compat_arch32 compat/linprocfs/linprocfs.c optional linprocfs compat/linsysfs/linsysfs.c optional linsysfs -kern/imgact_elf32.c optional compat_freebsd32 +kern/imgact_elf32.c optional compat_arch32 # # Linux/i386 binary support # Index: kern/kern_jail.c =================================================================== --- kern/kern_jail.c (revision 205451) +++ kern/kern_jail.c (working copy) @@ -734,7 +734,7 @@ kern_jail_set(struct thread *td, struct } } -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (td->td_proc->p_sysent->sv_flags & SV_ILP32) { uint32_t hid32; @@ -1961,7 +1961,7 @@ kern_jail_get(struct thread *td, struct error = vfs_setopts(opts, "host.hostuuid", pr->pr_hostuuid); if (error != 0 && error != ENOENT) goto done_deref; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (td->td_proc->p_sysent->sv_flags & SV_ILP32) { uint32_t hid32 = pr->pr_hostid; Index: kern/sysv_msg.c =================================================================== --- kern/sysv_msg.c (revision 205451) +++ kern/sysv_msg.c (working copy) @@ -165,7 +165,7 @@ static struct syscall_helper_data msg_sy SYSCALL_INIT_LAST }; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #include @@ -274,7 +274,7 @@ msginit() error = syscall_helper_register(msg_syscalls); if (error != 0) return (error); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 error = syscall32_helper_register(msg32_syscalls); if (error != 0) return (error); @@ -292,7 +292,7 @@ msgunload() #endif syscall_helper_unregister(msg_syscalls); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 syscall32_helper_unregister(msg32_syscalls); #endif @@ -1304,7 +1304,7 @@ SYSCTL_INT(_kern_ipc, OID_AUTO, msgseg, SYSCTL_PROC(_kern_ipc, OID_AUTO, msqids, CTLFLAG_RD, NULL, 0, sysctl_msqids, "", "Message queue IDs"); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 int freebsd32_msgsys(struct thread *td, struct freebsd32_msgsys_args *uap) { Index: kern/uipc_mqueue.c =================================================================== --- kern/uipc_mqueue.c (revision 205451) +++ kern/uipc_mqueue.c (working copy) @@ -2563,7 +2563,7 @@ static struct syscall_helper_data mq_sys SYSCALL_INIT_LAST }; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #include @@ -2711,7 +2711,7 @@ mqinit(void) error = syscall_helper_register(mq_syscalls); if (error != 0) return (error); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 error = syscall32_helper_register(mq32_syscalls); if (error != 0) return (error); @@ -2723,7 +2723,7 @@ static int mqunload(void) { -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 syscall32_helper_unregister(mq32_syscalls); #endif syscall_helper_unregister(mq_syscalls); Index: kern/kern_umtx.c =================================================================== --- kern/kern_umtx.c (revision 205451) +++ kern/kern_umtx.c (working copy) @@ -54,7 +54,7 @@ __FBSDID("$FreeBSD$"); #include -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #endif @@ -818,7 +818,7 @@ do_unlock_umtx(struct thread *td, struct return (0); } -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 /* * Lock a umtx object. @@ -3269,7 +3269,7 @@ _umtx_op(struct thread *td, struct _umtx return (EINVAL); } -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 int freebsd32_umtx_lock(struct thread *td, struct freebsd32_umtx_lock_args *uap) /* struct umtx *umtx */ Index: kern/kern_thr.c =================================================================== --- kern/kern_thr.c (revision 205451) +++ kern/kern_thr.c (working copy) @@ -55,7 +55,7 @@ __FBSDID("$FreeBSD$"); #include -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 static inline int suword_lwpid(void *addr, lwpid_t lwpid) Index: kern/uipc_syscalls.c =================================================================== --- kern/uipc_syscalls.c (revision 205451) +++ kern/uipc_syscalls.c (working copy) @@ -70,7 +70,7 @@ __FBSDID("$FreeBSD$"); #ifdef KTRACE #include #endif -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #endif @@ -2517,7 +2517,7 @@ sctp_generic_sendmsg_iov(td, uap) if (error) goto sctp_bad1; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (SV_CURPROC_FLAG(SV_ILP32)) error = freebsd32_copyiniov((struct iovec32 *)uap->iov, uap->iovlen, &iov, EMSGSIZE); @@ -2625,7 +2625,7 @@ sctp_generic_recvmsg(td, uap) if (error) { return (error); } -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (SV_CURPROC_FLAG(SV_ILP32)) error = freebsd32_copyiniov((struct iovec32 *)uap->iov, uap->iovlen, &iov, EMSGSIZE); Index: kern/sysv_sem.c =================================================================== --- kern/sysv_sem.c (revision 205451) +++ kern/sysv_sem.c (working copy) @@ -226,7 +226,7 @@ static struct syscall_helper_data sem_sy SYSCALL_INIT_LAST }; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #include @@ -295,7 +295,7 @@ seminit(void) error = syscall_helper_register(sem_syscalls); if (error != 0) return (error); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 error = syscall32_helper_register(sem32_syscalls); if (error != 0) return (error); @@ -312,7 +312,7 @@ semunload(void) if (semtot != 0) return (EBUSY); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 syscall32_helper_unregister(sem32_syscalls); #endif syscall_helper_unregister(sem_syscalls); @@ -1479,7 +1479,7 @@ freebsd7___semctl(struct thread *td, str #endif /* COMPAT_FREEBSD{4,5,6,7} */ -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 int freebsd32_semsys(struct thread *td, struct freebsd32_semsys_args *uap) @@ -1645,4 +1645,4 @@ freebsd32_semctl(struct thread *td, stru return (error); } -#endif /* COMPAT_FREEBSD32 */ +#endif /* COMPAT_ARCH32 */ Index: kern/uipc_socket.c =================================================================== --- kern/uipc_socket.c (revision 205451) +++ kern/uipc_socket.c (working copy) @@ -136,7 +136,7 @@ __FBSDID("$FreeBSD$"); #include -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #include @@ -2507,7 +2507,7 @@ sosetopt(struct socket *so, struct socko case SO_SNDTIMEO: case SO_RCVTIMEO: -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (SV_CURPROC_FLAG(SV_ILP32)) { struct timeval32 tv32; @@ -2688,7 +2688,7 @@ integer: tv.tv_sec = optval / hz; tv.tv_usec = (optval % hz) * tick; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (SV_CURPROC_FLAG(SV_ILP32)) { struct timeval32 tv32; Index: kern/imgact_elf.c =================================================================== --- kern/imgact_elf.c (revision 205451) +++ kern/imgact_elf.c (working copy) @@ -1298,7 +1298,7 @@ __elfN(corehdr)(td, vp, cred, numsegs, h } } -#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32 +#if defined(COMPAT_ARCH32) && __ELF_WORD_SIZE == 32 #include typedef struct prstatus32 elf_prstatus_t; @@ -1384,7 +1384,7 @@ __elfN(puthdr)(struct thread *td, void * status->pr_osreldate = osreldate; status->pr_cursig = p->p_sig; status->pr_pid = thr->td_tid; -#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32 +#if defined(COMPAT_ARCH32) && __ELF_WORD_SIZE == 32 fill_regs32(thr, &status->pr_reg); fill_fpregs32(thr, fpregset); #else @@ -1436,7 +1436,7 @@ __elfN(puthdr)(struct thread *td, void * ehdr->e_ident[EI_ABIVERSION] = 0; ehdr->e_ident[EI_PAD] = 0; ehdr->e_type = ET_CORE; -#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32 +#if defined(COMPAT_ARCH32) && __ELF_WORD_SIZE == 32 ehdr->e_machine = ELF_ARCH32; #else ehdr->e_machine = ELF_ARCH; Index: kern/sysv_shm.c =================================================================== --- kern/sysv_shm.c (revision 205451) +++ kern/sysv_shm.c (working copy) @@ -831,7 +831,7 @@ static struct syscall_helper_data shm_sy SYSCALL_INIT_LAST }; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #include @@ -896,7 +896,7 @@ shminit() error = syscall_helper_register(shm_syscalls); if (error != 0) return (error); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 error = syscall32_helper_register(shm32_syscalls); if (error != 0) return (error); @@ -914,7 +914,7 @@ shmunload() if (shm_nused > 0) return (EBUSY); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 syscall32_helper_unregister(shm32_syscalls); #endif syscall_helper_unregister(shm_syscalls); @@ -1039,7 +1039,7 @@ shmsys(td, uap) #endif /* i386 && (COMPAT_FREEBSD4 || COMPAT_43) */ -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 int freebsd32_shmsys(struct thread *td, struct freebsd32_shmsys_args *uap) Index: kern/uipc_sem.c =================================================================== --- kern/uipc_sem.c (revision 205451) +++ kern/uipc_sem.c (working copy) @@ -380,13 +380,13 @@ ksem_create_copyout_semid(struct thread int compat32) { semid_t semid; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 int32_t semid32; #endif void *ptr; size_t ptrs; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (compat32) { semid32 = fd; ptr = &semid32; @@ -397,7 +397,7 @@ ksem_create_copyout_semid(struct thread ptr = &semid; ptrs = sizeof(semid); compat32 = 0; /* silence gcc */ -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 } #endif @@ -874,7 +874,7 @@ static struct syscall_helper_data ksem_s SYSCALL_INIT_LAST }; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #include @@ -955,7 +955,7 @@ ksem_module_init(void) error = syscall_helper_register(ksem_syscalls); if (error) return (error); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 error = syscall32_helper_register(ksem32_syscalls); if (error) return (error); @@ -967,7 +967,7 @@ static void ksem_module_destroy(void) { -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 syscall32_helper_unregister(ksem32_syscalls); #endif syscall_helper_unregister(ksem_syscalls); Index: kern/vfs_aio.c =================================================================== --- kern/vfs_aio.c (revision 205451) +++ kern/vfs_aio.c (working copy) @@ -435,7 +435,7 @@ static struct syscall_helper_data aio_sy SYSCALL_INIT_LAST }; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #include @@ -508,7 +508,7 @@ aio_onceonly(void) error = syscall_helper_register(aio_syscalls); if (error) return (error); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 error = syscall32_helper_register(aio32_syscalls); if (error) return (error); @@ -535,7 +535,7 @@ aio_unload(void) if (!unloadable) return (EOPNOTSUPP); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 syscall32_helper_unregister(aio32_syscalls); #endif syscall_helper_unregister(aio_syscalls); @@ -2577,7 +2577,7 @@ filt_lio(struct knote *kn, long hint) return (lj->lioj_flags & LIOJ_KEVENT_POSTED); } -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 struct __aiocb_private32 { int32_t status; Index: kern/sys_process.c =================================================================== --- kern/sys_process.c (revision 205451) +++ kern/sys_process.c (working copy) @@ -62,7 +62,7 @@ __FBSDID("$FreeBSD$"); #include #include -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include struct ptrace_io_desc32 { @@ -170,7 +170,7 @@ proc_write_fpregs(struct thread *td, str PROC_ACTION(set_fpregs(td, fpregs)); } -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 /* For 32 bit binaries, we need to expose the 32 bit regs layouts. */ int proc_read_regs32(struct thread *td, struct reg32 *regs32) @@ -471,7 +471,7 @@ ptrace_vm_entry(struct thread *td, struc return (error); } -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 static int ptrace_vm_entry32(struct thread *td, struct proc *p, struct ptrace_vm_entry32 *pve32) @@ -498,7 +498,7 @@ ptrace_vm_entry32(struct thread *td, str pve32->pve_pathlen = pve.pve_pathlen; return (error); } -#endif /* COMPAT_FREEBSD32 */ +#endif /* COMPAT_ARCH32 */ /* * Process debugging system call. @@ -512,7 +512,7 @@ struct ptrace_args { }; #endif -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 /* * This CPP subterfuge is to try and reduce the number of ifdefs in * the body of the code. @@ -547,7 +547,7 @@ ptrace(struct thread *td, struct ptrace_ struct dbreg dbreg; struct fpreg fpreg; struct reg reg; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 struct dbreg32 dbreg32; struct fpreg32 fpreg32; struct reg32 reg32; @@ -557,7 +557,7 @@ ptrace(struct thread *td, struct ptrace_ } r; void *addr; int error = 0; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 int wrap32 = 0; if (SV_CURPROC_FLAG(SV_ILP32)) @@ -625,7 +625,7 @@ ptrace(struct thread *td, struct ptrace_ #undef COPYIN #undef COPYOUT -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 /* * PROC_READ(regs, td2, addr); * becomes either: @@ -659,7 +659,7 @@ kern_ptrace(struct thread *td, int req, int error, write, tmp, num; int proctree_locked = 0; lwpid_t tid = 0, *buf; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 int wrap32 = 0, safe = 0; struct ptrace_io_desc32 *piod32 = NULL; #endif @@ -747,7 +747,7 @@ kern_ptrace(struct thread *td, int req, tid = td2->td_tid; } -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 /* * Test if we're a 32 bit client and what the target is. * Set the wrap controls accordingly. @@ -1015,7 +1015,7 @@ kern_ptrace(struct thread *td, int req, break; case PT_IO: -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (wrap32) { piod32 = addr; iov.iov_base = (void *)(uintptr_t)piod32->piod_addr; @@ -1035,7 +1035,7 @@ kern_ptrace(struct thread *td, int req, uio.uio_iovcnt = 1; uio.uio_segflg = UIO_USERSPACE; uio.uio_td = td; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 tmp = wrap32 ? piod32->piod_op : piod->piod_op; #else tmp = piod->piod_op; @@ -1056,7 +1056,7 @@ kern_ptrace(struct thread *td, int req, } PROC_UNLOCK(p); error = proc_rwmem(p, &uio); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (wrap32) piod32->piod_len -= uio.uio_resid; else @@ -1145,7 +1145,7 @@ kern_ptrace(struct thread *td, int req, case PT_VM_ENTRY: PROC_UNLOCK(p); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (wrap32) error = ptrace_vm_entry32(td, p, addr); else Index: kern/sysv_ipc.c =================================================================== --- kern/sysv_ipc.c (revision 205451) +++ kern/sysv_ipc.c (working copy) @@ -179,7 +179,7 @@ ipcperm_new2old(struct ipc_perm *new, st } #endif -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #include Index: kern/kern_module.c =================================================================== --- kern/kern_module.c (revision 205451) +++ kern/kern_module.c (working copy) @@ -446,7 +446,7 @@ modfind(struct thread *td, struct modfin MODULE_VERSION(kernel, __FreeBSD_version); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #include Index: ia64/ia64/exception.S =================================================================== --- ia64/ia64/exception.S (revision 205451) +++ ia64/ia64/exception.S (working copy) @@ -676,7 +676,7 @@ ivt_##name: \ #define IVT_END(name) \ .endp ivt_##name -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #define IA32_TRAP ia32_trap #else #define IA32_TRAP trap Index: ia64/ia64/genassym.c =================================================================== --- ia64/ia64/genassym.c (revision 205451) +++ ia64/ia64/genassym.c (working copy) @@ -61,8 +61,8 @@ #include #include -#ifdef COMPAT_FREEBSD32 -ASSYM(COMPAT_FREEBSD32, COMPAT_FREEBSD32); +#ifdef COMPAT_ARCH32 +ASSYM(COMPAT_ARCH32, COMPAT_ARCH32); #endif ASSYM(DT_NULL, DT_NULL); Index: ia64/ia64/machdep.c =================================================================== --- ia64/ia64/machdep.c (revision 205451) +++ ia64/ia64/machdep.c (working copy) @@ -440,7 +440,7 @@ cpu_switch(struct thread *old, struct th struct pcb *oldpcb, *newpcb; oldpcb = old->td_pcb; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 ia32_savectx(oldpcb); #endif if (PCPU_GET(fpcurthread) == old) @@ -459,7 +459,7 @@ cpu_switch(struct thread *old, struct th PCPU_SET(curthread, new); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 ia32_restorectx(newpcb); #endif @@ -487,7 +487,7 @@ cpu_throw(struct thread *old __unused, s PCPU_SET(curthread, new); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 ia32_restorectx(newpcb); #endif Index: ia64/include/reg.h =================================================================== --- ia64/include/reg.h (revision 205451) +++ ia64/include/reg.h (working copy) @@ -52,7 +52,7 @@ struct dbreg { unsigned long dbr_inst[8]; }; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #endif Index: ia64/conf/NOTES =================================================================== --- ia64/conf/NOTES (revision 205451) +++ ia64/conf/NOTES (working copy) @@ -12,10 +12,10 @@ cpu ITANIUM cpu ITANIUM2 -# option: COMPAT_FREEBSD32 +# option: COMPAT_ARCH32 # This option enables the support for execution of i386 (32-bit) programs on # ia64. It is based on the ia32 emulation in the processor. -options COMPAT_FREEBSD32 +options COMPAT_ARCH32 # option: LOG2_ID_PAGE_SIZE # Specify the log2 size of the identity (direct) mappings in regions 6 and 7 Index: modules/procfs/Makefile =================================================================== --- modules/procfs/Makefile (revision 205451) +++ modules/procfs/Makefile (working copy) @@ -35,7 +35,7 @@ opt_compat.h: echo "#define COMPAT_FREEBSD5 1" >> ${.TARGET} echo "#define COMPAT_FREEBSD6 1" >> ${.TARGET} .if ${MACHINE_ARCH} == "amd64" - echo "#define COMPAT_FREEBSD32 1" >> ${.TARGET} + echo "#define COMPAT_ARCH32 1" >> ${.TARGET} echo "#define COMPAT_LINUX32 1" >> ${.TARGET} .endif .endif Index: modules/linux/Makefile =================================================================== --- modules/linux/Makefile (revision 205451) +++ modules/linux/Makefile (working copy) @@ -2,7 +2,7 @@ .if ${MACHINE_ARCH} == "amd64" SFX= 32 -CFLAGS+=-DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 +CFLAGS+=-DCOMPAT_ARCH32 -DCOMPAT_LINUX32 .endif .PATH: ${.CURDIR}/../../compat/linux ${.CURDIR}/../../${MACHINE_ARCH}/linux${SFX} Index: fs/procfs/procfs_fpregs.c =================================================================== --- fs/procfs/procfs_fpregs.c (revision 205451) +++ fs/procfs/procfs_fpregs.c (working copy) @@ -53,7 +53,7 @@ #include #include -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include @@ -83,7 +83,7 @@ procfs_doprocfpregs(PFS_FILL_ARGS) int error; struct fpreg r; struct thread *td2; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 struct fpreg32 r32; int wrap32 = 0; #endif @@ -100,7 +100,7 @@ procfs_doprocfpregs(PFS_FILL_ARGS) /* XXXKSE: */ td2 = FIRST_THREAD_IN_PROC(p); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (SV_CURPROC_FLAG(SV_ILP32)) { if ((td2->td_proc->p_sysent->sv_flags & SV_ILP32) == 0) { PROC_UNLOCK(p); Index: fs/procfs/procfs_regs.c =================================================================== --- fs/procfs/procfs_regs.c (revision 205451) +++ fs/procfs/procfs_regs.c (working copy) @@ -53,7 +53,7 @@ #include #include -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include @@ -83,7 +83,7 @@ procfs_doprocregs(PFS_FILL_ARGS) int error; struct reg r; struct thread *td2; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 struct reg32 r32; int wrap32 = 0; #endif @@ -100,7 +100,7 @@ procfs_doprocregs(PFS_FILL_ARGS) /* XXXKSE: */ td2 = FIRST_THREAD_IN_PROC(p); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (SV_CURPROC_FLAG(SV_ILP32)) { if ((td2->td_proc->p_sysent->sv_flags & SV_ILP32) == 0) { PROC_UNLOCK(p); Index: fs/procfs/procfs_dbregs.c =================================================================== --- fs/procfs/procfs_dbregs.c (revision 205451) +++ fs/procfs/procfs_dbregs.c (working copy) @@ -59,7 +59,7 @@ #include #include -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include @@ -89,7 +89,7 @@ procfs_doprocdbregs(PFS_FILL_ARGS) int error; struct dbreg r; struct thread *td2; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 struct dbreg32 r32; int wrap32 = 0; #endif @@ -105,7 +105,7 @@ procfs_doprocdbregs(PFS_FILL_ARGS) } td2 = FIRST_THREAD_IN_PROC(p); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (SV_CURPROC_FLAG(SV_ILP32)) { if ((td2->td_proc->p_sysent->sv_flags & SV_ILP32) == 0) { PROC_UNLOCK(p); Index: fs/procfs/procfs_ioctl.c =================================================================== --- fs/procfs/procfs_ioctl.c (revision 205451) +++ fs/procfs/procfs_ioctl.c (working copy) @@ -42,7 +42,7 @@ #include #include -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 struct procfs_status32 { int state; /* Running, stopped, something else? */ int flags; /* Any flags */ @@ -62,7 +62,7 @@ int procfs_ioctl(PFS_IOCTL_ARGS) { struct procfs_status *ps; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 struct procfs_status32 *ps32; #endif int error, flags, sig; @@ -142,7 +142,7 @@ procfs_ioctl(PFS_IOCTL_ARGS) ps->why = p->p_step ? p->p_stype : 0; ps->val = p->p_step ? p->p_xstat : 0; break; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 case PIOCWAIT32: while (p->p_step == 0 && (p->p_flag & P_WEXIT) == 0) { /* sleep until p stops */ Index: fs/procfs/procfs_map.c =================================================================== --- fs/procfs/procfs_map.c (revision 205451) +++ fs/procfs/procfs_map.c (working copy) @@ -47,7 +47,7 @@ #include #include #include -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #endif #include @@ -86,7 +86,7 @@ procfs_doprocmap(PFS_FILL_ARGS) struct uidinfo *uip; int error, vfslocked; unsigned int last_timestamp; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 int wrap32 = 0; #endif @@ -99,7 +99,7 @@ procfs_doprocmap(PFS_FILL_ARGS) if (uio->uio_rw != UIO_READ) return (EOPNOTSUPP); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (curproc->p_sysent->sv_flags & SV_ILP32) { if (!(p->p_sysent->sv_flags & SV_ILP32)) return (EOPNOTSUPP); @@ -209,7 +209,7 @@ procfs_doprocmap(PFS_FILL_ARGS) "0x%lx 0x%lx %d %d %p %s%s%s %d %d 0x%x %s %s %s %s %s %d\n", (u_long)e_start, (u_long)e_end, resident, privateresident, -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 wrap32 ? NULL : obj, /* Hide 64 bit value */ #else obj, Index: amd64/include/reg.h =================================================================== --- amd64/include/reg.h (revision 205451) +++ amd64/include/reg.h (working copy) @@ -120,7 +120,7 @@ struct dbreg { #define DBREG_DRX(d,x) ((d)->dr[(x)]) /* reference dr0 - dr15 by register number */ -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 #include #include #endif Index: amd64/linux32/linux32_sysvec.c =================================================================== --- amd64/linux32/linux32_sysvec.c (revision 205451) +++ amd64/linux32/linux32_sysvec.c (working copy) @@ -34,8 +34,8 @@ __FBSDID("$FreeBSD$"); #include "opt_compat.h" -#ifndef COMPAT_FREEBSD32 -#error "Unable to compile Linux-emulator due to missing COMPAT_FREEBSD32 option!" +#ifndef COMPAT_ARCH32 +#error "Unable to compile Linux-emulator due to missing COMPAT_ARCH32 option!" #endif #define __ELF_WORD_SIZE 32 Index: amd64/conf/XENHVM =================================================================== --- amd64/conf/XENHVM (revision 205451) +++ amd64/conf/XENHVM (working copy) @@ -45,7 +45,7 @@ options PROCFS # Process filesystem ( options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization -options COMPAT_FREEBSD32 # Compatible with i386 binaries +options COMPAT_ARCH32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 Index: amd64/conf/NOTES =================================================================== --- amd64/conf/NOTES (revision 205451) +++ amd64/conf/NOTES (working copy) @@ -483,7 +483,7 @@ options PMAP_SHPGPERPROC=201 #XXX these 32 bit binaries is added. # Enable 32-bit runtime support for FreeBSD/i386 binaries. -options COMPAT_FREEBSD32 +options COMPAT_ARCH32 # Enable iBCS2 runtime support for SCO and ISC binaries #XXX#options IBCS2 @@ -494,7 +494,7 @@ options COMPAT_FREEBSD32 # Enable Linux ABI emulation #XXX#options COMPAT_LINUX -# Enable 32-bit Linux ABI emulation (requires COMPAT_43 and COMPAT_FREEBSD32) +# Enable 32-bit Linux ABI emulation (requires COMPAT_43 and COMPAT_ARCH32) options COMPAT_LINUX32 # Enable the linux-like proc filesystem support (requires COMPAT_LINUX32 Index: amd64/conf/GENERIC =================================================================== --- amd64/conf/GENERIC (revision 205451) +++ amd64/conf/GENERIC (working copy) @@ -44,7 +44,7 @@ options PROCFS # Process filesystem ( options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization -options COMPAT_FREEBSD32 # Compatible with i386 binaries +options COMPAT_ARCH32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 Index: amd64/amd64/db_trace.c =================================================================== --- amd64/amd64/db_trace.c (revision 205451) +++ amd64/amd64/db_trace.c (working copy) @@ -319,7 +319,7 @@ db_nextframe(struct amd64_frame **fp, db frame_type = INTERRUPT; else if (strcmp(name, "Xfast_syscall") == 0) frame_type = SYSCALL; -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 else if (strcmp(name, "Xint0x80_syscall") == 0) frame_type = SYSCALL; #endif Index: amd64/amd64/vm_machdep.c =================================================================== --- amd64/amd64/vm_machdep.c (revision 205451) +++ amd64/amd64/vm_machdep.c (working copy) @@ -439,7 +439,7 @@ cpu_set_upcall_kse(struct thread *td, vo */ cpu_thread_clean(td); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (td->td_proc->p_sysent->sv_flags & SV_ILP32) { /* * Set the trap frame to point at the beginning of the uts @@ -490,7 +490,7 @@ cpu_set_user_tls(struct thread *td, void if ((u_int64_t)tls_base >= VM_MAXUSER_ADDRESS) return (EINVAL); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 if (td->td_proc->p_sysent->sv_flags & SV_ILP32) { td->td_pcb->pcb_gsbase = (register_t)tls_base; return (0); Index: amd64/amd64/exception.S =================================================================== --- amd64/amd64/exception.S (revision 205451) +++ amd64/amd64/exception.S (working copy) @@ -572,7 +572,7 @@ ENTRY(fork_trampoline) * included. */ -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 .data .p2align 4 .text Index: sys/ptrace.h =================================================================== --- sys/ptrace.h (revision 205451) +++ sys/ptrace.h (working copy) @@ -158,7 +158,7 @@ int proc_read_dbregs(struct thread *_td, int proc_write_dbregs(struct thread *_td, struct dbreg *_dbreg); int proc_sstep(struct thread *_td); int proc_rwmem(struct proc *_p, struct uio *_uio); -#ifdef COMPAT_FREEBSD32 +#ifdef COMPAT_ARCH32 struct reg32; struct fpreg32; struct dbreg32; From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 18: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 8E7CD1065670; Mon, 22 Mar 2010 18:27:09 +0000 (UTC) (envelope-from adrenalinup@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id E00EB8FC21; Mon, 22 Mar 2010 18:27:08 +0000 (UTC) Received: by fxm24 with SMTP id 24so48974fxm.3 for ; Mon, 22 Mar 2010 11:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=Bl5eoW3ht/6sl+teP9YZBZVATwzG77/urPg4brHvW8Y=; b=aQoMZpC0jlGrzQ/u/xZu1pVJ2DibQfDEDyIlQZ+sYloZFJfbSJ5mbrpjyLrLXEyIrL aZv1pFYo/mooWumdPKQr2Ux/vVxkeQ5/VQoMl2x0mRRP6QD/qMg5ejietJ0cX8uTp/c5 7E+ZOEUz+RwwlPs/pm5zrz6jDnziC1kxqx9Yg= 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; b=RVmdJEIOGdM6S8yMzAVuJkDnTS/G4uKEf3yu4TWBlnFFrg4FAHvLjaa2sokGBnO7tc cagC1j0b95IsABceCpX66YbfSIpfO3Tmexj35t5zkNqAtvIVDoc3Gt+gfwz/dyXcCpIP +Db3REe6j7F6KM8mh4koFW1K4uDdf80WeN610= MIME-Version: 1.0 Received: by 10.223.60.142 with SMTP id p14mr5206057fah.47.1269282427144; Mon, 22 Mar 2010 11:27:07 -0700 (PDT) In-Reply-To: References: <1242075474.72992.118.camel@hood.oook.cz> <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> <20090616073353.GZ33280@droso.net> <200906160812.04284.jhb@freebsd.org> <4A3E234F.6050403@FreeBSD.org> From: Adrenalin Date: Mon, 22 Mar 2010 19:26:47 +0100 Message-ID: To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: hang in rpccon from interrupting NFS operations (Re: pointyhat panic) 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, 22 Mar 2010 18:27:09 -0000 That's strange, after recompiling the lastest 8_0 that contain the patch ( http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/rpc/clnt_vc.c.diff?r1=1.8.2.2.2.1;r2=1.8.2.2.2.2) after 5 days it stuck again with same symptoms, I've also got some in the nfs state: FreeBSD .. 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Mar 16 22:56:51 EET 2010 ..@..:/usr/obj/usr/src/sys/MYGEN amd64 When attaching the debugger for an rpccon process, It stuck in here #0 0x000000080124051c in stat () from /lib/libc.so.7 http://img705.imageshack.us/img705/741/10032219218.png Can I do the online debug of the kernel, or how can I can help you to solve the problem ? From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 18:27: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 8E7CD1065670; Mon, 22 Mar 2010 18:27:09 +0000 (UTC) (envelope-from adrenalinup@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id E00EB8FC21; Mon, 22 Mar 2010 18:27:08 +0000 (UTC) Received: by fxm24 with SMTP id 24so48974fxm.3 for ; Mon, 22 Mar 2010 11:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=Bl5eoW3ht/6sl+teP9YZBZVATwzG77/urPg4brHvW8Y=; b=aQoMZpC0jlGrzQ/u/xZu1pVJ2DibQfDEDyIlQZ+sYloZFJfbSJ5mbrpjyLrLXEyIrL aZv1pFYo/mooWumdPKQr2Ux/vVxkeQ5/VQoMl2x0mRRP6QD/qMg5ejietJ0cX8uTp/c5 7E+ZOEUz+RwwlPs/pm5zrz6jDnziC1kxqx9Yg= 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; b=RVmdJEIOGdM6S8yMzAVuJkDnTS/G4uKEf3yu4TWBlnFFrg4FAHvLjaa2sokGBnO7tc cagC1j0b95IsABceCpX66YbfSIpfO3Tmexj35t5zkNqAtvIVDoc3Gt+gfwz/dyXcCpIP +Db3REe6j7F6KM8mh4koFW1K4uDdf80WeN610= MIME-Version: 1.0 Received: by 10.223.60.142 with SMTP id p14mr5206057fah.47.1269282427144; Mon, 22 Mar 2010 11:27:07 -0700 (PDT) In-Reply-To: References: <1242075474.72992.118.camel@hood.oook.cz> <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> <20090616073353.GZ33280@droso.net> <200906160812.04284.jhb@freebsd.org> <4A3E234F.6050403@FreeBSD.org> From: Adrenalin Date: Mon, 22 Mar 2010 19:26:47 +0100 Message-ID: To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: hang in rpccon from interrupting NFS operations (Re: pointyhat panic) 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, 22 Mar 2010 18:27:09 -0000 That's strange, after recompiling the lastest 8_0 that contain the patch ( http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/rpc/clnt_vc.c.diff?r1=1.8.2.2.2.1;r2=1.8.2.2.2.2) after 5 days it stuck again with same symptoms, I've also got some in the nfs state: FreeBSD .. 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Mar 16 22:56:51 EET 2010 ..@..:/usr/obj/usr/src/sys/MYGEN amd64 When attaching the debugger for an rpccon process, It stuck in here #0 0x000000080124051c in stat () from /lib/libc.so.7 http://img705.imageshack.us/img705/741/10032219218.png Can I do the online debug of the kernel, or how can I can help you to solve the problem ? From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 18:50:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32E5A106566B; Mon, 22 Mar 2010 18:50:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id C8DA68FC1C; Mon, 22 Mar 2010 18:50:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2MIj5Zf028027; Mon, 22 Mar 2010 12:45:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 22 Mar 2010 12:45:05 -0600 (MDT) Message-Id: <20100322.124505.787670930858384500.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: References: <1269134585.00231959.1269122405@10.7.7.3> <4BA6279E.3010201@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org, ivoras@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 18:50:41 -0000 In message: Scott Long writes: : I'd like to go in the opposite direction. The queue-dispatch-queue : model of GEOM is elegant and easy to extend, but very wasteful for : the simple case, where the simple case is one or two simple : partition transforms (mbr, bsdlabel) and/or a simple stripe/mirror : transform. None of these need a dedicated dispatch context in order : to operate. What I'd like to explore is compiling the GEOM stack at : creation time into a linear array of operations that happen without : a g_down/g_up context switch. As providers and consumers taste each : other and build a stack, that stack gets compiled into a graph, and : that graph gets executed directly from the calling context, both : from the dev_strategy() side on the top and the bio_done() on the : bottom. GEOM classes that need a detached context can mark : themselves as such, doing so will prevent a graph from being : created, and the current dispatch model will be retained. I have a few things to say on this. First, I've done similar things at past companies for systems that are similar to geom's queueing environment. It is possible to convert the queueing nodes in the graph to filtering nodes in the graph. Another way to look at this is to say you're implementing direct dispatch into geom's stack. This can be both good and bad, but should reduce latency a lot. One problem that I see is that you are calling into the driver from a different set of contexts. The queueing stuff was there to protect the driver from LoRs due to its routines being called from many different contexts, sometimes with other locks held (fact of life often in the kernel). So this certainly is something worth exploring, especially if we have optimized paths for up/down for certain geom classes while still allowing the current robust, but slow, paths for the more complicated nodes in the tree. It remains to be see if there's going to be issues around locking order, but we've hit that with both geom and ifnet in the past, so caution (eg, running with WITNESS turned on early and often) is advised. Warner From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 18:53: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 9DE33106566B; Mon, 22 Mar 2010 18:53:39 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 78CB68FC0A; Mon, 22 Mar 2010 18:53:39 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id o2MIrVMr088871; Mon, 22 Mar 2010 11:53:31 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id o2MIrVfM088870; Mon, 22 Mar 2010 11:53:31 -0700 (PDT) (envelope-from obrien) Date: Mon, 22 Mar 2010 11:53:31 -0700 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20100322185331.GA88847@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , yanefbsd@gmail.com, freebsd-current@freebsd.org, nwhitehorn@freebsd.org, swhetzel@gmail.com References: <7d6fde3d1003111720g7dccf93w1f51db88758a5c4d@mail.gmail.com> <20100311.192423.683591382013853731.imp@bsdimp.com> <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100312.125032.270969355930630649.imp@bsdimp.com> X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: yanefbsd@gmail.com, freebsd-current@freebsd.org, nwhitehorn@freebsd.org, swhetzel@gmail.com Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 18:53:39 -0000 On Fri, Mar 12, 2010 at 12:50:32PM -0700, M. Warner Losh wrote: > : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote: > So the issue isn't as cut and dried as you might think. There's > multiple different conventions used here in addition to your simple > example. I guess we'd have to take a poll to find out. Seems pretty cut and dried to me. COMPAT_FREEBSDn has an established context that does not match this new usage. That is - same bit'ness, compatibility with an older FreeBSD API for the same architecture. All the other COMPAT_* are for foreign ABI compatibility. COMPAT_LINUX32 possibly should have been "COMPAT_LINUX_X86_64". (or is it MI and is usable as-is for PowerPC and MIPS? I haven't looked that deeply at the code.) > Users of 64-bit systems that will be using COMPAT_FREEBSD32 > are likely to find this a natural extension of the COMPAT_LINUX32 that > they are likely already using. You know I am such a user - and I don't think it is so clear given the existence (and purpose) of "COMPAT_FREEBSDn" for the past many years. While it does match the directory name of 'sys/compat/freebsd32', it may be that "freebsd32" was a poor choice for that directory's name. But given the recent discussion in another thread - I won't even suggest we rename it. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 19:07:58 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 DDD4C106566B; Mon, 22 Mar 2010 19:07:57 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 976828FC1B; Mon, 22 Mar 2010 19:07:57 +0000 (UTC) Received: by pvc7 with SMTP id 7so1725188pvc.13 for ; Mon, 22 Mar 2010 12:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IAbwQDXKWD9NlEl/9OqmLYW9cBIGQ2VBgkLOBd+Tk4Y=; b=nhMIq7dphzai8YsLQY2aGid9Rt8VCoTK/veYPs7rDiu0MWDg1v4aNttBUygAelvpLb aPAaKk85PCqWL2aNBdNbVCy04T8PdvkB9kYXWYu6gpE0Ko3pWRS/WvH++XNuDSc0yVON mcMsvA0/pTu32F9rCm6OCnsdq2y0gA4rPNGJo= 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=QIyl9hwMBbqWg9rep6rl6Y4BrR6gG3k1vmhvrzJcBUUQB4CEpswh33WNWs5UO+2G/w 9URo3ZMrL5LmXt/IbFQ5ucHGbr/ouVIKs9CqoxaACn4XtlhH39Er7Kz1gqrC8de38dOO ou4ewQmsBFPrIKjg9ayOXpAccKERhk6KS+vmg= MIME-Version: 1.0 Received: by 10.115.103.40 with SMTP id f40mr1014095wam.38.1269284877017; Mon, 22 Mar 2010 12:07:57 -0700 (PDT) In-Reply-To: <20100322.124505.787670930858384500.imp@bsdimp.com> References: <1269134585.00231959.1269122405@10.7.7.3> <4BA6279E.3010201@FreeBSD.org> <20100322.124505.787670930858384500.imp@bsdimp.com> Date: Mon, 22 Mar 2010 15:07:56 -0400 Message-ID: <3c0b01821003221207p4e4eecabqb4f448813bf5a8a8@mail.gmail.com> From: Alexander Sack To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, mav@freebsd.org, ivoras@freebsd.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 19:07:58 -0000 On Mon, Mar 22, 2010 at 2:45 PM, M. Warner Losh wrote: > In message: > =A0 =A0 =A0 =A0 =A0 =A0Scott Long writes: > : I'd like to go in the opposite direction. =A0The queue-dispatch-queue > : model of GEOM is elegant and easy to extend, but very wasteful for > : the simple case, where the simple case is one or two simple > : partition transforms (mbr, bsdlabel) and/or a simple stripe/mirror > : transform. =A0None of these need a dedicated dispatch context in order > : to operate. =A0What I'd like to explore is compiling the GEOM stack at > : creation time into a linear array of operations that happen without > : a g_down/g_up context switch. =A0As providers and consumers taste each > : other and build a stack, that stack gets compiled into a graph, and > : that graph gets executed directly from the calling context, both > : from the dev_strategy() side on the top and the bio_done() on the > : bottom. =A0GEOM classes that need a detached context can mark > : themselves as such, doing so will prevent a graph from being > : created, and the current dispatch model will be retained. > > I have a few things to say on this. > > First, I've done similar things at past companies for systems that are > similar to geom's queueing environment. =A0It is possible to convert the > queueing nodes in the graph to filtering nodes in the graph. =A0Another > way to look at this is to say you're implementing direct dispatch into > geom's stack. =A0This can be both good and bad, but should reduce > latency a lot. > > One problem that I see is that you are calling into the driver from a > different set of contexts. =A0The queueing stuff was there to protect > the driver from LoRs due to its routines being called from many > different contexts, sometimes with other locks held (fact of life > often in the kernel). > > So this certainly is something worth exploring, especially if we have > optimized paths for up/down for certain geom classes while still > allowing the current robust, but slow, paths for the more complicated > nodes in the tree. =A0It remains to be see if there's going to be issues > around locking order, but we've hit that with both geom and ifnet in > the past, so caution (eg, running with WITNESS turned on early and > often) is advised. Am I going crazy or does this sound a lot like Sun/SVR's stream based network stack? (design and problems, stream stack locking was notoriously tricky for the exact issue mentioned above, different running contexts with different locking granularity/requirements). -aps From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 19:08: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 08250106566B; Mon, 22 Mar 2010 19:08:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id B8F5B8FC18; Mon, 22 Mar 2010 19:08:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2MJ1I2X028302; Mon, 22 Mar 2010 13:01:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 22 Mar 2010 13:01:18 -0600 (MDT) Message-Id: <20100322.130118.80747594461967718.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" In-Reply-To: <20100322185331.GA88847@dragon.NUXI.org> References: <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> <20100322185331.GA88847@dragon.NUXI.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: yanefbsd@gmail.com, freebsd-current@freebsd.org, nwhitehorn@freebsd.org, swhetzel@gmail.com Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 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, 22 Mar 2010 19:08:55 -0000 In message: <20100322185331.GA88847@dragon.NUXI.org> "David O'Brien" writes: : On Fri, Mar 12, 2010 at 12:50:32PM -0700, M. Warner Losh wrote: : > : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote: : > So the issue isn't as cut and dried as you might think. There's : > multiple different conventions used here in addition to your simple : > example. : : I guess we'd have to take a poll to find out. Seems pretty cut and dried : to me. COMPAT_FREEBSDn has an established context that does not match : this new usage. That is - same bit'ness, compatibility with an older : FreeBSD API for the same architecture. All the other COMPAT_* are for : foreign ABI compatibility. COMPAT_LINUX32 possibly should have been : "COMPAT_LINUX_X86_64". (or is it MI and is usable as-is for PowerPC : and MIPS? I haven't looked that deeply at the code.) no, COMPAT_LINUX32 is the right name. While we don't have PowerPC or MIPS linux emulation bits in the kernel, the code if for dealing with running 32-bit binaries on 64-bit machines. There may be a little leakage of x86 specific goo here, but not a lot. Warner From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 19:20: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 CA3581065675; Mon, 22 Mar 2010 19:20:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6D40E8FC13; Mon, 22 Mar 2010 19:20:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2MJ9dde028412; Mon, 22 Mar 2010 13:09:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 22 Mar 2010 13:09:39 -0600 (MDT) Message-Id: <20100322.130939.70320533309323962.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" In-Reply-To: <20100322185331.GA88847@dragon.NUXI.org> References: <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> <20100322185331.GA88847@dragon.NUXI.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: yanefbsd@gmail.com, freebsd-current@freebsd.org, nwhitehorn@freebsd.org, swhetzel@gmail.com Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 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, 22 Mar 2010 19:20:46 -0000 P.S. I think that there's much traction to the idea of moving from COMPAT_FREEBSDx to some other variable called, for example, COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries as old as FreeBSD x.0, and have all the other magic handled behind the scenes. This would render the inconsistency with COMPAT_FREEBSDx part of the debate completely moot. Warner From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 19:42: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 A3C3C106566B for ; Mon, 22 Mar 2010 19:42:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 623878FC24 for ; Mon, 22 Mar 2010 19:42:26 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o2MJgMPw014658; Mon, 22 Mar 2010 15:42:22 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Mon, 22 Mar 2010 15:42:22 -0400 (EDT) Date: Mon, 22 Mar 2010 15:42:22 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20100322.130939.70320533309323962.imp@bsdimp.com> Message-ID: References: <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> <20100322185331.GA88847@dragon.NUXI.org> <20100322.130939.70320533309323962.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 19:42:26 -0000 [ Some CC's stripped ] On Mon, 22 Mar 2010, M. Warner Losh wrote: > P.S. I think that there's much traction to the idea of moving from > COMPAT_FREEBSDx to some other variable called, for example, > COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries > as old as FreeBSD x.0, and have all the other magic handled behind the > scenes. This would render the inconsistency with COMPAT_FREEBSDx part > of the debate completely moot. Doesn't matter. We're still use to COMPAT_FREEBSDx since it's been here so long. So regardless if you rename them to COMPAT_FREEBSD_BACK_TO=x, it is still potentially confusing. COMPAT_ARCH32 and all other choices David mentions seem like much better names - even if there wasn't any existing COMPAT_FREEBSDx knobs. My $0.02. -- DE From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 20:42:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 018441065676; Mon, 22 Mar 2010 20:42:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B66208FC2B; Mon, 22 Mar 2010 20:42:40 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7E9D66440; Mon, 22 Mar 2010 20:42:39 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id o2MKgbeS034478; Mon, 22 Mar 2010 20:42:37 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Sack From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 22 Mar 2010 15:07:56 -0400." <3c0b01821003221207p4e4eecabqb4f448813bf5a8a8@mail.gmail.com> Date: Mon, 22 Mar 2010 20:42:37 +0000 Message-ID: <34477.1269290557@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: mav@freebsd.org, freebsd-current@freebsd.org, ivoras@freebsd.org, freebsd-arch@freebsd.org, "M. Warner Losh" Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 20:42:41 -0000 In message <3c0b01821003221207p4e4eecabqb4f448813bf5a8a8@mail.gmail.com>, Alexa nder Sack writes: >Am I going crazy or does this sound a lot like Sun/SVR's stream based >network stack? That is a good and pertinent observation. I did investigate a number of optimizations to the g_up/g_down scheme I eventually adopted, but found none that gained anything justifying the complexity they brought. In some cases, the optimizations used more CPU cycles than the straight g_up/g_down path, but obviously, the circumstances are vastly different with CPUs having 10 times higher clock, multiple cores and SSD disks, so a fresh look at this tradeoff is in order. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 20:48:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB92E106566C for ; Mon, 22 Mar 2010 20:48:23 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id A4D1C8FC08 for ; Mon, 22 Mar 2010 20:48:23 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZP00E05B4J7K60@asmtp026.mac.com>; Mon, 22 Mar 2010 13:48:20 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003220252 From: Marcel Moolenaar In-reply-to: <20100322175213.GA87475@dragon.NUXI.org> Date: Mon, 22 Mar 2010 13:48:19 -0700 Message-id: <18331E07-2DEA-43C7-A0BF-5B3A2E827FDB@mac.com> References: <4B9E332D.3090909@stillbilde.net> <4B9E5992.6020207@elischer.org> <20100322175213.GA87475@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] rename COMPAT_FREEBSD32 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, 22 Mar 2010 20:48:23 -0000 On Mar 22, 2010, at 10:52 AM, David O'Brien wrote: > On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote: >> I certainly agree.. can it be changed please? > > I've waited a while to see what other opinions would be expressed on this > topic. I believe there is sufficient support to rename COMPAT_FREEBSD32 > to something else based on responses in the mailing lists. > > I am sorry if some may wish to label this a "bikeshead". But we seem to > have many folks disliking "COMPAT_FREEBSD32". > > > Based on responses to the topic of COMPAT_FREEBSD32, the following > were the suggestions offered: > COMPAT_ARCH32, COMPAT_ARCH_32BIT, COMPAT_32BIT_ARCH, COMPAT_32BIT, > COMPAT_FREEBSD32BIT There's probably a bigger problem than just how we name it. The option really encodes 2 independent aspects: 1. Support for a 32-bit ABI (i.e. ILP32) 2. Support for a particular OS in ILP32. Of course 2 implies 1. For example: COMPAT_IA32 in sys/ia64/ia64/machdep.c enabled code to save and restore IA32 registers as part of cpu_switch(). In this context COMPAT_IA32 was perfectly named. It's now called COMPAT_FREEBSD32, which doesn't make a lot of sense because what if I only want to support Linux/ia32 and not FreeBSD/ia32 (or vice-versa if you club them under a single COMPAT_*32)? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 21:27: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 718501065675 for ; Mon, 22 Mar 2010 21:27:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1412A8FC25 for ; Mon, 22 Mar 2010 21:27:36 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 2AC0EA58BEE; Tue, 23 Mar 2010 05:27:35 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id s74SNh5T+HnH; Tue, 23 Mar 2010 05:27:28 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 2063BA58BBA; Tue, 23 Mar 2010 05:27:26 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=rf/+3BWuYnzBu0H2eV4Rv6scsSaE+hkYHmc6mDAIszkEmRJCym6LW64G6KjEgJMrp c128eoEC46zIRiyZKggxg== Message-ID: <4BA7E0B8.3080406@delphij.net> Date: Mon, 22 Mar 2010 14:27:20 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100304 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.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, 22 Mar 2010 21:27:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Just a heads-up that zlib in base system (libz) has been updated to 1.2.4. We tried to keep -HEAD as close as possible to the vendor version, but there is some changes in its internal data structure, and we did not use versioned symbols in the past, making shared library version bump unavoidable. A MFC of this update is planned, but we will have to make some rather aggressive changes against the library and more testing. Please make sure that you have at least libxml2-2.7.6_2 in your ports tree before even thinking about updating your ports tree. Older libxml2 uses some knowledge of zlib internals that has been changed in this update which is known to cause problem. - -------- Original Message -------- Subject: svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys Date: Mon, 22 Mar 2010 21:11:55 +0000 (UTC) From: Xin LI To: src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG Author: delphij Date: Mon Mar 22 21:11:55 2010 New Revision: 205471 URL: http://svn.freebsd.org/changeset/base/205471 Log: Update to zlib 1.2.4 and add versioned symbols to the library. Sponsored by: iXsystems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLp+C4AAoJEATO+BI/yjfBL8QH/12Mu9ihnH6JcySY7LiKukfl 448LMbxneP/JHwYuhFGhvbffd0N64HWzLKEF0Cp0HCH8ULuMIuoAjRsUjZSgF+et AaBXN0Su0Pw4kkcWIJ0Ruza5oDbVNVHB8XAHs/kIbWz0QS2v35FUCnFnvw1IVgIj 8NBe1Z+nR+dFWamc7ddFwxKnmSEIWzebykpvMrJoweAxzBKfcslNaCbZhfFe+j/D 1LrlRq97RM95SVUTnaFXPWr6zZCxFLhcFaGOOWxPV1g5TOgYaFO72fICXNgKgsWH TCwOzKV97vXfRx87yVWF/5CwOmlXiVAL5CmL1O3H6+PcOa2gWOZTZ48dorfol9w= =jrhi -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 23:36: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 DEF3B106564A; Mon, 22 Mar 2010 23:36:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2683F8FC0A; Mon, 22 Mar 2010 23:36:16 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B643045CD8; Tue, 23 Mar 2010 00:36:13 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 2A9F845CA0; Tue, 23 Mar 2010 00:36:08 +0100 (CET) Date: Tue, 23 Mar 2010 00:36:07 +0100 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20100322233607.GB1767@garage.freebsd.pl> References: <4BA633A0.2090108@icyb.net.ua> <5754.1269246223@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline In-Reply-To: <5754.1269246223@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Alexander Motin , freebsd-current@FreeBSD.org, Andriy Gapon , freebsd-arch@FreeBSD.org Subject: Re: Increasing MAXPHYS 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, 22 Mar 2010 23:36:18 -0000 --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 22, 2010 at 08:23:43AM +0000, Poul-Henning Kamp wrote: > In message <4BA633A0.2090108@icyb.net.ua>, Andriy Gapon writes: > >on 21/03/2010 16:05 Alexander Motin said the following: > >> Ivan Voras wrote: > >>> Hmm, it looks like it could be easy to spawn more g_* threads (and, > >>> barring specific class behaviour, it has a fair chance of working out= of > >>> the box) but the incoming queue will need to also be broken up for > >>> greater effect. > >>=20 > >> According to "notes", looks there is a good chance to obtain races, as > >> some places expect only one up and one down thread. > > > >I haven't given any deep thought to this issue, but I remember us discus= sing > >them over beer :-) >=20 > The easiest way to obtain more parallelism, is to divide the mesh into > multiple independent meshes. >=20 > This will do you no good if you have five disks in a RAID-5 config, but > if you have two disks each mounted on its own filesystem, you can run > a g_up & g_down for each of them. A class is suppose to interact with other classes only via GEOM, so I think it should be safe to choose g_up/g_down threads for each class individually, for example: /dev/ad0s1a (DEV) | g_up_0 + g_down_0 | ad0s1a (BSD) | g_up_1 + g_down_1 | ad0s1 (MBR) | g_up_2 + g_down_2 | ad0 (DISK) We could easly calculate g_down thread based on bio_to->geom->class and g_up thread based on bio_from->geom->class, so we know I/O requests for our class are always coming from the same threads. If we could make the same assumption for geoms it would allow for even better distribution. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --LpQ9ahxlCli8rRTG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkun/uYACgkQForvXbEpPzSKuwCguhkymDDx/xptSf8zaU8rQI/5 qmAAoIMNpThV3uN+larfBnQ/ZI3pqElZ =QCWg -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 00:05:26 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03C38106564A; Tue, 23 Mar 2010 00:05:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 96FA18FC08; Tue, 23 Mar 2010 00:05:25 +0000 (UTC) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o2N05MI0056853; Mon, 22 Mar 2010 18:05:22 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20100322233607.GB1767@garage.freebsd.pl> Date: Mon, 22 Mar 2010 18:05:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8D465FFB-0389-4321-84B9-E45292697D26@samsco.org> References: <4BA633A0.2090108@icyb.net.ua> <5754.1269246223@critter.freebsd.dk> <20100322233607.GB1767@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-arch@FreeBSD.org, Poul-Henning Kamp , freebsd-current@FreeBSD.org, Alexander Motin , Andriy Gapon Subject: Re: Increasing MAXPHYS 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, 23 Mar 2010 00:05:26 -0000 On Mar 22, 2010, at 5:36 PM, Pawel Jakub Dawidek wrote: > On Mon, Mar 22, 2010 at 08:23:43AM +0000, Poul-Henning Kamp wrote: >> In message <4BA633A0.2090108@icyb.net.ua>, Andriy Gapon writes: >>> on 21/03/2010 16:05 Alexander Motin said the following: >>>> Ivan Voras wrote: >>>>> Hmm, it looks like it could be easy to spawn more g_* threads = (and, >>>>> barring specific class behaviour, it has a fair chance of working = out of >>>>> the box) but the incoming queue will need to also be broken up for >>>>> greater effect. >>>>=20 >>>> According to "notes", looks there is a good chance to obtain races, = as >>>> some places expect only one up and one down thread. >>>=20 >>> I haven't given any deep thought to this issue, but I remember us = discussing >>> them over beer :-) >>=20 >> The easiest way to obtain more parallelism, is to divide the mesh = into >> multiple independent meshes. >>=20 >> This will do you no good if you have five disks in a RAID-5 config, = but >> if you have two disks each mounted on its own filesystem, you can run >> a g_up & g_down for each of them. >=20 > A class is suppose to interact with other classes only via GEOM, so I > think it should be safe to choose g_up/g_down threads for each class > individually, for example: >=20 > /dev/ad0s1a (DEV) > | > g_up_0 + g_down_0 > | > ad0s1a (BSD) > | > g_up_1 + g_down_1 > | > ad0s1 (MBR) > | > g_up_2 + g_down_2 > | > ad0 (DISK) >=20 > We could easly calculate g_down thread based on bio_to->geom->class = and > g_up thread based on bio_from->geom->class, so we know I/O requests = for > our class are always coming from the same threads. >=20 > If we could make the same assumption for geoms it would allow for even > better distribution. The whole point of the discussion, sans PHK's interlude, is to reduce = the context switches and indirection, not to increase it. But if you = can show decreased latency/higher-iops benefits of increasing it, more = power to you. I would think that the results of DFly's experiment with = parallelism-via-more-queues would serve as a good warning, though. Scott From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 00:33: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 C5B701065674; Tue, 23 Mar 2010 00:33:55 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB0D8FC27; Tue, 23 Mar 2010 00:33:54 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so242747eye.3 for ; Mon, 22 Mar 2010 17:33:53 -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 :content-type:content-transfer-encoding; bh=1Uo69i8YIN6B8Csn1RSX/w1aTfU+eevdLHR211XGyMo=; b=Dwtj/qalff3+JWVjtxkn/OrncJCZmKWeSbh5v8LcevTNUrtSBvdeeh4CCzt1SCe97O 3qORmcEXLRERa5GdphmErgaBbk3jhWzeAnLotyI3hBCnqSmsinAsZy509rZYDCYLVezs v59Owjy6wmKA0Z9ng2bQrDhHZ8gZDDLq98nN0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CUKFo5btO5fAcBkxKA8ltygcvdT8yAWIBpXxDo0QKBw0W78G+eVAqeIZeN+pTo8wdf ZyN53A6vbqsfAA4wn54XPCw9DEboF7rZyUeCw1voGig/ra7ohUjQzenEA5zzZmmN4g3r YLbd+VutfFyClTJRravICrGKspFX/kKjI9IJM= Received: by 10.213.99.135 with SMTP id u7mr427406ebn.36.1269304433778; Mon, 22 Mar 2010 17:33:53 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 14sm2427690ewy.10.2010.03.22.17.33.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 17:33:53 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BA80C6F.7050506@elischer.org> Date: Mon, 22 Mar 2010 17:33:51 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4BA633A0.2090108@icyb.net.ua> <5754.1269246223@critter.freebsd.dk> <20100322233607.GB1767@garage.freebsd.pl> In-Reply-To: <20100322233607.GB1767@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org, Poul-Henning Kamp , freebsd-current@FreeBSD.org, Alexander Motin , Andriy Gapon Subject: Re: Increasing MAXPHYS 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, 23 Mar 2010 00:33:56 -0000 Pawel Jakub Dawidek wrote: > On Mon, Mar 22, 2010 at 08:23:43AM +0000, Poul-Henning Kamp wrote: >> In message <4BA633A0.2090108@icyb.net.ua>, Andriy Gapon writes: >>> on 21/03/2010 16:05 Alexander Motin said the following: >>>> Ivan Voras wrote: >>>>> Hmm, it looks like it could be easy to spawn more g_* threads (and, >>>>> barring specific class behaviour, it has a fair chance of working out of >>>>> the box) but the incoming queue will need to also be broken up for >>>>> greater effect. >>>> According to "notes", looks there is a good chance to obtain races, as >>>> some places expect only one up and one down thread. >>> I haven't given any deep thought to this issue, but I remember us discussing >>> them over beer :-) >> The easiest way to obtain more parallelism, is to divide the mesh into >> multiple independent meshes. >> >> This will do you no good if you have five disks in a RAID-5 config, but >> if you have two disks each mounted on its own filesystem, you can run >> a g_up & g_down for each of them. > > A class is suppose to interact with other classes only via GEOM, so I > think it should be safe to choose g_up/g_down threads for each class > individually, for example: > > /dev/ad0s1a (DEV) > | > g_up_0 + g_down_0 > | > ad0s1a (BSD) > | > g_up_1 + g_down_1 > | > ad0s1 (MBR) > | > g_up_2 + g_down_2 > | > ad0 (DISK) > > We could easly calculate g_down thread based on bio_to->geom->class and > g_up thread based on bio_from->geom->class, so we know I/O requests for > our class are always coming from the same threads. > > If we could make the same assumption for geoms it would allow for even > better distribution. doesn't really help my problem however.. I just want to access the base provider directly with no geom thread involved. > From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 02:57: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 BB61A1065673 for ; Tue, 23 Mar 2010 02:57:59 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id 818F98FC1F for ; Tue, 23 Mar 2010 02:57:59 +0000 (UTC) Received: by iwn15 with SMTP id 15so1342940iwn.7 for ; Mon, 22 Mar 2010 19:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9Kn+guz0GB9BYd2OC4T0fHnbJLaWXbMRBzzR8/9DTYU=; b=EFc5pqupvNJDgzsuUR3eF0IBhB0hJ9+a0MtaCJSMaxSMjGBhDv24qUGqJzYnrxEnju J55mTs5n1aXo9EktJ0+Ymtlp7NDT+I2rJizVLgGy+xjypccxWEKlzcv4xrcSh3O0+lE1 w8Jvpmr5qqcLuzp/BwgVpqBbS3MSpMOIZ2CSU= 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=S3Lr1K8VT+Ox+c8/tV5BhTOmm8ZS4sRB03umr1mPQRLZRD0jqzkSN9299E6JCqgOso Soo0XLvUSa1LUGpLxQfo7GtraJqZgvesb33PcMJyNtpHPtNW+QtcVmubCz6QNt5AHVUl dvXTED/kDiT1kvhM0MdagjBPlA1PAEMtAHhUA= MIME-Version: 1.0 Received: by 10.231.153.141 with SMTP id k13mr1745389ibw.95.1269313078715; Mon, 22 Mar 2010 19:57:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Mar 2010 21:57:58 -0500 Message-ID: <790a9fff1003221957x6e2b001i3102302618d24051@mail.gmail.com> From: Scot Hetzel To: jhell Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Best , freebsd-current@freebsd.org, Garrett Cooper Subject: Re: build failures after stdlib update 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, 23 Mar 2010 02:57:59 -0000 On Sun, Mar 21, 2010 at 7:29 PM, jhell wrote: > Native is equal to CPUTYPE not being defined right ? > Built into GCC is the ability to auto-detect the CPUTYPE when -mtune=native, if you run this command GCC will tell ouput your processor type: gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//' > So if the above is true why would you set CPUTYPE to native in the first > place ? when you can just leave it unset and its equal to native. > Native allows one to build the sources to the current build machines cputype. There is one bug when setting the CPUTYPE to native, the FreeBSD build system fails to correctly set the MACHINE_CPU to the correct value. I had discovered this problem back in May 2007: http://www.freebsd.org/cgi/query-pr.cgi?pr=112997 Just apply the last patch to share/mk/bsd.cpu.mk and that will fix the problem. Scot From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 03:05:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D942E106564A for ; Tue, 23 Mar 2010 03:05:49 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id A45A88FC14 for ; Tue, 23 Mar 2010 03:05:49 +0000 (UTC) Received: by iwn15 with SMTP id 15so1350099iwn.7 for ; Mon, 22 Mar 2010 20:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=P9ACDzI3EDUenUZJQl8wLhk+FQG39vH7Keiyy+FANqk=; b=NaHuEN4RB3fq6da7/lfsil336xZM61p0TE4Mned0b55s9WCnbFzuEE1hi94zoHNZAU +oyTVUNJw9VGBZqTQdf9EUvMMVOnGaEoDzrGxufLjDXE5oIrz2nz25X5M6cCSTk2BlaQ yif+C4+QPNDG7fdc4XOihKvm5JYFEdLMMwx64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Iu/+UK+tyt4Ewur+oM0+Sr5cVmOsQjiYyc1NPefLKlYOQhiYTSf7rdUD1XXUA9/D9z rlq7SRYNCF+asL+4O3yKv2dHFtfMgQmBKKV8MFoHG4HGXvBdq712VWGIOlw1JIAsmvxA pMvQUHv0aCTWzvCT2xfPc7v91528lrlLZid3w= MIME-Version: 1.0 Received: by 10.231.159.207 with SMTP id k15mr1233928ibx.52.1269313548735; Mon, 22 Mar 2010 20:05:48 -0700 (PDT) Date: Mon, 22 Mar 2010 22:05:48 -0500 Message-ID: <790a9fff1003222005i10dada54u921ba58ed2ea1f7b@mail.gmail.com> From: Scot Hetzel To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Subject: MACHINE_CPU not being set correctly when CPUTYPE=native. 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, 23 Mar 2010 03:05:49 -0000 Could someone commit the last patch in PR 112997 to share/mk/bsd.cpu.mk, as it fixes the bug where MACHINE_CPU is not set correctly when CPUTYPE is set to 'native'. On Tue, Aug 28, 2007 at 1:54 AM, Scot Hetzel wrote: > Gcc 4.2 has a new cpu_type (native) for x86 and amd64 systems. This > cpu_type is to allow gcc to automatically detect the processor type > that gcc is running on. > > The problem is that setting CPUTYPE?=native in either src.conf or > make.conf will cause MACHINE_CPU to be set to the wrong value for the > native cpu. > > For example on a system where the processor is a k8, setting CPUTYPE > to k8, shows that MACHINE_CPU is set as follows: > > hp010# make -V MACHINE_CPU -DCPUTYPE=k8 > k8 3dnow amd64 sse2 sse mmx > > But setting CPUTYPE to native on a k8 system sets MACHINE_CPU to this value: > > hp010# make -V MACHINE_CPU -DCPUTYPE=native > unknown amd64 sse2 sse mmx > > After patching share/mk/bsd.cpu.mk (see attachment) or the last patch > to PR 112997: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=112997 > > setting CPUTYPE to native now works correctly when setting the value > for MACHINE_CPU: > > hp010# make -V MACHINE_CPU -V CPUTYPE -DCPUTYPE=native > k8 3dnow amd64 sse2 sse mmx > k8 > > Could this get committed before -CURRENT is branched. > > Thanks, > > Scot From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 08:25: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 A080D106566B; Tue, 23 Mar 2010 08:25:57 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 296FE8FC1A; Tue, 23 Mar 2010 08:25:57 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id o2N8Ps1p032955; Tue, 23 Mar 2010 01:25:56 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o2N8PsLY032954; Tue, 23 Mar 2010 01:25:54 -0700 (PDT) Date: Tue, 23 Mar 2010 01:25:54 -0700 (PDT) From: Matthew Dillon Message-Id: <201003230825.o2N8PsLY032954@apollo.backplane.com> To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org References: <4BA633A0.2090108@icyb.net.ua> <5754.1269246223@critter.freebsd.dk> <20100322233607.GB1767@garage.freebsd.pl> <8D465FFB-0389-4321-84B9-E45292697D26@samsco.org> Cc: Subject: Re: Increasing MAXPHYS 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, 23 Mar 2010 08:25:57 -0000 :The whole point of the discussion, sans PHK's interlude, is to reduce the context switches and indirection, not to increase it. But if you can show decreased latency/higher-iops benefits of increasing it, more power to you. I would think that the results of DFly's experiment with parallelism-via-more-queues would serve as a good warning, though. : :Scott Well, I'm not sure what experiment you are refering to but I'll assume its the network threading, which works quite well actually. The protocol threads can be matched against the toeplitz function and in that case the entire packet stream operates lockless. Even without the matching we still get good benefits from batching (e.g. via ether_input_chain()) which drops the IPI and per-packet switch overhead basically to zero. We have other issues but the protocol threads aren't one of them. In anycase, the lesson to learn with batching to a thread is that you don't want the thread to immediately preempt the sender (if it happens to be on the same cpu), or to generate an instant IPI (if going between cpus). This creates a degenerate case where you wind up with a thread switch on each message or an excessive messaging interrupt rate... THAT is what seriously screws up performance. The key is to be able to batch multiple messages per thread switch when under load and to be able to maintain a pipeline. A single user-process test case will always have a bit more latency and can wind up being inefficient for a variety of other reasons (e.g. whether the target thread is on the same cpu or not), but that becomes less relevant when the machine is under load so its a self-correcting problem for the most part. Once the machine is under load batching becomes highly efficient. That is, latency != cpu cycle cost under load. When the threads have enough work to do they can pick up the next message without the cost of entering a sleep state or needing a wakeup (or needing to generate an actual IPI interrupt, etc). Plus you can run lockless and you get excellent cache locality. So as long as you ensure these optimal operations become the norm under load you win. Getting the threads to pipeline properly and avoid unnecessary tsleeps and wakeups is the hard part. -- But with regard to geom, I'd have to agree with you. You don't want to pipeline a single N-stage request through N threads. One thread, sure... that can be batched to reduce overhead. N-stages through N-threads just creates unnecessary latency, complicates your ability to maintain a pipeline, and has a multiplicative effect on thread activity that negates the advantage of having multiple cpus (and destroys cache locality as well). You could possibly use a different trick at least for some of the simpler transformations, and that is to replicate the control structures on a per-cpu basis. If you replicate the control structures on a per-cpu basis then you can parallelize independent operations running through the same set of devices and remove the bottlenecks. The set of transformations for a single BIO would be able to run lockless within a single thread and the control system as a whole would have one thread per cpu. (Of course, a RAID layer would require some rendezvous to deal with contention/conflicts, but that's easily dealt with). That would be my suggestion. We use that trick for our route tables in DFly, and also for listen socket PCBs to remove choke points, and a few other things like statistics gathering. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 08:56:27 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66C791065672; Tue, 23 Mar 2010 08:56:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4338FC08; Tue, 23 Mar 2010 08:56:27 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 82E116434; Tue, 23 Mar 2010 08:56:25 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id o2N8uOPm036867; Tue, 23 Mar 2010 08:56:24 GMT (envelope-from phk@critter.freebsd.dk) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 23 Mar 2010 00:36:07 +0100." <20100322233607.GB1767@garage.freebsd.pl> Date: Tue, 23 Mar 2010 08:56:24 +0000 Message-ID: <36866.1269334584@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Alexander Motin , freebsd-current@FreeBSD.org, Andriy Gapon , freebsd-arch@FreeBSD.org Subject: Re: Increasing MAXPHYS 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, 23 Mar 2010 08:56:27 -0000 In message <20100322233607.GB1767@garage.freebsd.pl>, Pawel Jakub Dawidek write s: >A class is suppose to interact with other classes only via GEOM, so I >think it should be safe to choose g_up/g_down threads for each class >individually, for example: > > /dev/ad0s1a (DEV) > | > g_up_0 + g_down_0 > | > ad0s1a (BSD) > | > g_up_1 + g_down_1 > | > ad0s1 (MBR) > | > g_up_2 + g_down_2 > | > ad0 (DISK) Uhm, that way you get _more_ context switches than today, today g_down will typically push the requests all the way down through the stack without a context switch. (Similar for g_up) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 09:34: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 1172F1065670 for ; Tue, 23 Mar 2010 09:34:21 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay1.uni-muenster.de (ZIVM-RELAY1.UNI-MUENSTER.DE [128.176.192.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9DB8FC22 for ; Tue, 23 Mar 2010 09:34:20 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,294,1267398000"; d="scan'208";a="299887226" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 23 Mar 2010 10:34:18 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 659E91B0768; Tue, 23 Mar 2010 10:34:18 +0100 (CET) Date: Tue, 23 Mar 2010 10:34:17 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Scot Hetzel Subject: Re: build failures after stdlib update 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, 23 Mar 2010 09:34:21 -0000 i don't think conf/112997 and the issue where gcc segfaults are directly related to each other: 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=3Dn= ative /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=3D//'` to dete= rmine gcc's idea of the appropriate -mtune value. that command however segfaults= =2E so this doesn't really help. 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=3Dnative` examples. for me `make` prints the same no matter what CPUTYPE is set to: otaku% make -V MACHINE_CPU -DCPUTYPE=3Dnative amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=3Dnocona amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=3Di386 amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=3Dlalalala amd64 sse2 sse =2E.oh and of course i ran these commands with no CPUTYPE set in make.conf= =2E ;) --=20 Alexander Best From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 10:00: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 DDD861065676 for ; Tue, 23 Mar 2010 10:00:20 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id ADD3B8FC25 for ; Tue, 23 Mar 2010 10:00:20 +0000 (UTC) Received: from PortaPegIII (hydra.fletchermoorland.co.uk [78.33.209.59]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id o2NA0Dok076535 for ; Tue, 23 Mar 2010 10:00:15 GMT (envelope-from ken@mthelicon.com) From: "Pegasus Mc Cleaft" To: Date: Tue, 23 Mar 2010 10:00:13 -0000 Message-ID: <000101caca6f$a2d3ca90$e87b5fb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKbBYgMF7b9EMbSzOyJu5ENl8dJgAATC4wAACRunA= Content-Language: en-gb X-Spam-Status: No, score=4.3 required=5.0 tests=BAYES_50,DNS_FROM_OPENWHOIS, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hercules.mthelicon.com Subject: FW: build failures after stdlib update 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, 23 Mar 2010 10:00:21 -0000 -----Original Message----- From: Pegasus Mc Cleaft [mailto:ken@mthelicon.com] Sent: 23 March 2010 09:57 To: 'Alexander Best' Subject: RE: build failures after stdlib update -----Original Message----- >2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native` >examples. for me `make` prints the same no matter what CPUTYPE is set to: > >otaku% make -V MACHINE_CPU -DCPUTYPE=native >amd64 sse2 sse >otaku% make -V MACHINE_CPU -DCPUTYPE=nocona >amd64 sse2 sse >otaku% make -V MACHINE_CPU -DCPUTYPE=i386 >amd64 sse2 sse >otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala >amd64 sse2 sse > >..oh and of course i ran these commands with no CPUTYPE set in make.conf. ;) This is interesting. I tried the same thing on my computer (AMD64 - Core2 Quad) and I get the following (Without CPUTYPE?=native in /etc/make) feathers$ make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse (With CPUTYPE?=native) feathers$ make -V MACHINE_CPU -DCPUTYPE=native unknown amd64 sse2 sse mmx (For both) feathers$ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null -mtune=generic Peg From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 10:41: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 259BA1065674 for ; Tue, 23 Mar 2010 10:41:07 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id 93A2B8FC0A for ; Tue, 23 Mar 2010 10:41:06 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,294,1267398000"; d="txt'?scan'208";a="29114261" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 23 Mar 2010 11:41:04 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 9603F1B07C1; Tue, 23 Mar 2010 11:41:04 +0100 (CET) Date: Tue, 23 Mar 2010 11:40:50 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: <000001caca6f$2ce61fe0$86b25fa0$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-2010032310405080e26a0b00003cb9-a_best01+ Cc: Pegasus Mc Cleaft Subject: Re: build failures after stdlib update 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, 23 Mar 2010 10:41:07 -0000 This is a MIME encoded multipart message. --+permail-2010032310405080e26a0b00003cb9-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pegasus Mc Cleaft schrieb am 2010-03-23: > -----Original Message----- > >2. i wasn't able to reproduce your `make -V MACHINE_CPU > >-DCPUTYPE=native` > >examples. for me `make` prints the same no matter what CPUTYPE is > >set to: > >otaku% make -V MACHINE_CPU -DCPUTYPE=native > >amd64 sse2 sse > >otaku% make -V MACHINE_CPU -DCPUTYPE=nocona > >amd64 sse2 sse > >otaku% make -V MACHINE_CPU -DCPUTYPE=i386 > >amd64 sse2 sse > >otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala > >amd64 sse2 sse > >..oh and of course i ran these commands with no CPUTYPE set in > >make.conf. > ;) > This is interesting. I tried the same thing on my computer (AMD64 - > Core2 > Quad) and I get the following > (Without CPUTYPE?=native in /etc/make) > feathers$ make -V MACHINE_CPU -DCPUTYPE=native > amd64 sse2 sse > (With CPUTYPE?=native) > feathers$ make -V MACHINE_CPU -DCPUTYPE=native > unknown amd64 sse2 sse mmx > (For both) > feathers$ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | > grep > mtune > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null > -mtune=generic hmm...that's odd indeed. i finally was able to do some debugging. i've attached two files: running gcc -v -x c -E -mtune=native /dev/null and gcc -v -x c -E -mtune=nocona /dev/null > Peg -- Alexander Best --+permail-2010032310405080e26a0b00003cb9-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="debugging.native.txt" YGdkYiAtdiAteCBjIC1FIC1tdHVuZT1uYXRpdmUgL2Rldi9udWxsYDoKCkJyZWFrcG9pbnQgMjYs IHN0cmxlbiAoc3RyPTB4N2ZmZmZmZmZlZDZlICIvZGV2L251bGwiKSBhdCAvdXNyL3NyYy9saWIv bGliYy9zdHJpbmcvc3RybGVuLmM6OTkKOTkgICAgICAgICAgICAgIGxwID0gKGNvbnN0IHVuc2ln bmVkIGxvbmcgKikoKHVpbnRwdHJfdClzdHIgJiB+TE9OR1BUUl9NQVNLKTsKKGdkYikKQ29udGlu dWluZy4KCkJyZWFrcG9pbnQgMjYsIHN0cmxlbiAoc3RyPTB4N2ZmZmZmZmZlZDczICJudWxsIikg YXQgL3Vzci9zcmMvbGliL2xpYmMvc3RyaW5nL3N0cmxlbi5jOjk5Cjk5ICAgICAgICAgICAgICBs cCA9IChjb25zdCB1bnNpZ25lZCBsb25nICopKCh1aW50cHRyX3Qpc3RyICYgfkxPTkdQVFJfTUFT Syk7CihnZGIpCkNvbnRpbnVpbmcuCgpCcmVha3BvaW50IDI2LCBzdHJsZW4gKHN0cj0weDQzZTA0 YSAiaW5jbHVkZSIpIGF0IC91c3Ivc3JjL2xpYi9saWJjL3N0cmluZy9zdHJsZW4uYzo5OQo5OSAg ICAgICAgICAgICAgbHAgPSAoY29uc3QgdW5zaWduZWQgbG9uZyAqKSgodWludHB0cl90KXN0ciAm IH5MT05HUFRSX01BU0spOwooZ2RiKQpDb250aW51aW5nLgoKQnJlYWtwb2ludCAyNiwgc3RybGVu IChzdHI9MHg0NThhMzAgIiIpIGF0IC91c3Ivc3JjL2xpYi9saWJjL3N0cmluZy9zdHJsZW4uYzo5 OQo5OSAgICAgICAgICAgICAgbHAgPSAoY29uc3QgdW5zaWduZWQgbG9uZyAqKSgodWludHB0cl90 KXN0ciAmIH5MT05HUFRSX01BU0spOwooZ2RiKQpDb250aW51aW5nLgoKQnJlYWtwb2ludCAyNiwg c3RybGVuIChzdHI9MHg0NThhMzAgIiIpIGF0IC91c3Ivc3JjL2xpYi9saWJjL3N0cmluZy9zdHJs ZW4uYzo5OQo5OSAgICAgICAgICAgICAgbHAgPSAoY29uc3QgdW5zaWduZWQgbG9uZyAqKSgodWlu dHB0cl90KXN0ciAmIH5MT05HUFRSX01BU0spOwooZ2RiKQpDb250aW51aW5nLgoKQnJlYWtwb2lu dCAyNiwgc3RybGVuIChzdHI9MHg0M2U1ZWIgIi1tIikgYXQgL3Vzci9zcmMvbGliL2xpYmMvc3Ry aW5nL3N0cmxlbi5jOjk5Cjk5ICAgICAgICAgICAgICBscCA9IChjb25zdCB1bnNpZ25lZCBsb25n ICopKCh1aW50cHRyX3Qpc3RyICYgfkxPTkdQVFJfTUFTSyk7CihnZGIpCkNvbnRpbnVpbmcuCgpC cmVha3BvaW50IDI2LCBzdHJsZW4gKHN0cj0weDgwYTJkOCA8RXJyb3IgcmVhZGluZyBhZGRyZXNz IDB4ODBhMmQ4OiBCYWQgYWRkcmVzcz4pIGF0IC91c3Ivc3JjL2xpYi9saWJjL3N0cmluZy9zdHJs ZW4uYzo5OQo5OSAgICAgICAgICAgICAgbHAgPSAoY29uc3QgdW5zaWduZWQgbG9uZyAqKSgodWlu dHB0cl90KXN0ciAmIH5MT05HUFRSX01BU0spOwoK --+permail-2010032310405080e26a0b00003cb9-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="debugging.nocona.txt" YGdkYiAtdiAteCBjIC1FIC1tdHVuZT1ub2NvbmEgL2Rldi9udWxsYDoKCkJyZWFrcG9pbnQgMSwg c3RybGVuIChzdHI9MHg3ZmZmZmZmZmVkNzMgIm51bGwiKSBhdCAvdXNyL3NyYy9saWIvbGliYy9z dHJpbmcvc3RybGVuLmM6OTkKOTkgICAgICAgICAgICAgIGxwID0gKGNvbnN0IHVuc2lnbmVkIGxv bmcgKikoKHVpbnRwdHJfdClzdHIgJiB+TE9OR1BUUl9NQVNLKTsKKGdkYikKQ29udGludWluZy4K CkJyZWFrcG9pbnQgMSwgc3RybGVuIChzdHI9MHg0M2UwNGEgImluY2x1ZGUiKSBhdCAvdXNyL3Ny Yy9saWIvbGliYy9zdHJpbmcvc3RybGVuLmM6OTkKOTkgICAgICAgICAgICAgIGxwID0gKGNvbnN0 IHVuc2lnbmVkIGxvbmcgKikoKHVpbnRwdHJfdClzdHIgJiB+TE9OR1BUUl9NQVNLKTsKKGdkYikK Q29udGludWluZy4KCkJyZWFrcG9pbnQgMSwgc3RybGVuIChzdHI9MHg0NThhMzAgIiIpIGF0IC91 c3Ivc3JjL2xpYi9saWJjL3N0cmluZy9zdHJsZW4uYzo5OQo5OSAgICAgICAgICAgICAgbHAgPSAo Y29uc3QgdW5zaWduZWQgbG9uZyAqKSgodWludHB0cl90KXN0ciAmIH5MT05HUFRSX01BU0spOwoo Z2RiKQpDb250aW51aW5nLgoKQnJlYWtwb2ludCAxLCBzdHJsZW4gKHN0cj0weDQ1OGEzMCAiIikg YXQgL3Vzci9zcmMvbGliL2xpYmMvc3RyaW5nL3N0cmxlbi5jOjk5Cjk5ICAgICAgICAgICAgICBs cCA9IChjb25zdCB1bnNpZ25lZCBsb25nICopKCh1aW50cHRyX3Qpc3RyICYgfkxPTkdQVFJfTUFT Syk7CihnZGIpCkNvbnRpbnVpbmcuCgpCcmVha3BvaW50IDEsIHN0cmxlbiAoc3RyPTB4N2ZmZmZm ZmZlZDU2ICJ2IikgYXQgL3Vzci9zcmMvbGliL2xpYmMvc3RyaW5nL3N0cmxlbi5jOjk5Cjk5ICAg ICAgICAgICAgICBscCA9IChjb25zdCB1bnNpZ25lZCBsb25nICopKCh1aW50cHRyX3Qpc3RyICYg fkxPTkdQVFJfTUFTSyk7CihnZGIpCkNvbnRpbnVpbmcuCgpCcmVha3BvaW50IDEsIHN0cmxlbiAo c3RyPTB4N2ZmZmZmZmZlZDVlICJFIikgYXQgL3Vzci9zcmMvbGliL2xpYmMvc3RyaW5nL3N0cmxl bi5jOjk5Cjk5ICAgICAgICAgICAgICBscCA9IChjb25zdCB1bnNpZ25lZCBsb25nICopKCh1aW50 cHRyX3Qpc3RyICYgfkxPTkdQVFJfTUFTSyk7CihnZGIpCkNvbnRpbnVpbmcuCgpCcmVha3BvaW50 IDEsIHN0cmxlbiAoc3RyPTB4N2ZmZmZmZmZlZDYxICJtdHVuZT1ub2NvbmEiKSBhdCAvdXNyL3Ny Yy9saWIvbGliYy9zdHJpbmcvc3RybGVuLmM6OTkKOTkgICAgICAgICAgICAgIGxwID0gKGNvbnN0 IHVuc2lnbmVkIGxvbmcgKikoKHVpbnRwdHJfdClzdHIgJiB+TE9OR1BUUl9NQVNLKTsK --+permail-2010032310405080e26a0b00003cb9-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 14:05: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 4D6DE106566B for ; Tue, 23 Mar 2010 14:05:09 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 220CB8FC30 for ; Tue, 23 Mar 2010 14:05:08 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0KZQ00912N4KPQ00@smtpauth3.wiscmail.wisc.edu>; Tue, 23 Mar 2010 09:05:08 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.69.218]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0KZQ007HKN4HXU30@smtpauth3.wiscmail.wisc.edu>; Tue, 23 Mar 2010 09:05:06 -0500 (CDT) Date: Tue, 23 Mar 2010 09:05:04 -0500 From: Nathan Whitehorn To: FreeBSD-CURRENT Mailing List Message-id: <4BA8CA90.80208@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.69.218 X-Spam-PmxInfo: Server=avs-12, Version=5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2010.3.23.135427, SenderIP=76.210.69.218 User-Agent: Thunderbird 2.0.0.24 (X11/20100320) Cc: Marcel Moolenaar Subject: Re: [PATCH] rename COMPAT_FREEBSD32 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, 23 Mar 2010 14:05:09 -0000 > On Mar 22, 2010, at 10:52 AM, David O'Brien wrote: > >>/ On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote: />>>/ I certainly agree.. can it be changed please? />>/ />>/ I've waited a while to see what other opinions would be expressed on this />>/ topic. I believe there is sufficient support to rename COMPAT_FREEBSD32 />>/ to something else based on responses in the mailing lists. />>/ />>/ I am sorry if some may wish to label this a "bikeshead". But we seem to />>/ have many folks disliking "COMPAT_FREEBSD32". />>/ />>/ />>/ Based on responses to the topic of COMPAT_FREEBSD32, the following />>/ were the suggestions offered: />>/ COMPAT_ARCH32, COMPAT_ARCH_32BIT, COMPAT_32BIT_ARCH, COMPAT_32BIT, />>/ COMPAT_FREEBSD32BIT /> > There's probably a bigger problem than just how we name it. The option > really encodes 2 independent aspects: > 1. Support for a 32-bit ABI (i.e. ILP32) > 2. Support for a particular OS in ILP32. > > Of course 2 implies 1. > > For example: > COMPAT_IA32 in sys/ia64/ia64/machdep.c enabled code to save and restore > IA32 registers as part of cpu_switch(). In this context COMPAT_IA32 was > perfectly named. It's now called COMPAT_FREEBSD32, which doesn't make a > lot of sense because what if I only want to support Linux/ia32 and not > FreeBSD/ia32 (or vice-versa if you club them under a single COMPAT_*32)? The original version of my my patch had this split, with a COMPAT_FREEBSD32 and a COMPAT_[IA/PPC/MIPS]32. The problem is that the 32-bit FreeBSD compat is deeply intertwined with providing support for any 32-bit binaries at all (e.g., the 32-bit linuxolator depends on calling into it), so it isn't actually possible to support having COMPAT_LINUX32 without COMPAT_FREEBSD32 without a huge amount of work. So I scrapped that in favor of the unified name only, and we ended up with COMPAT_FREEBSD32. In any event, given the persistent interest and consolidation around COMPAT_ARCH32, I'm fine changing the name. -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 14:28: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 AD62C106579A; Tue, 23 Mar 2010 14:28:02 +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 5BCFB8FC0A; Tue, 23 Mar 2010 14:28:01 +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 06F0146B90; Tue, 23 Mar 2010 10:28:01 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2CBE98A021; Tue, 23 Mar 2010 10:28:00 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 23 Mar 2010 10:20:46 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100322175213.GA87475@dragon.NUXI.org> <18331E07-2DEA-43C7-A0BF-5B3A2E827FDB@mac.com> In-Reply-To: <18331E07-2DEA-43C7-A0BF-5B3A2E827FDB@mac.com> MIME-Version: 1.0 Message-Id: <201003231020.46887.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 23 Mar 2010 10:28:00 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 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: Marcel Moolenaar Subject: Re: [PATCH] rename COMPAT_FREEBSD32 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, 23 Mar 2010 14:28:02 -0000 On Monday 22 March 2010 4:48:19 pm Marcel Moolenaar wrote: > > On Mar 22, 2010, at 10:52 AM, David O'Brien wrote: > > > On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote: > >> I certainly agree.. can it be changed please? > > > > I've waited a while to see what other opinions would be expressed on this > > topic. I believe there is sufficient support to rename COMPAT_FREEBSD32 > > to something else based on responses in the mailing lists. > > > > I am sorry if some may wish to label this a "bikeshead". But we seem to > > have many folks disliking "COMPAT_FREEBSD32". > > > > > > Based on responses to the topic of COMPAT_FREEBSD32, the following > > were the suggestions offered: > > COMPAT_ARCH32, COMPAT_ARCH_32BIT, COMPAT_32BIT_ARCH, COMPAT_32BIT, > > COMPAT_FREEBSD32BIT > > There's probably a bigger problem than just how we name it. The option > really encodes 2 independent aspects: > 1. Support for a 32-bit ABI (i.e. ILP32) > 2. Support for a particular OS in ILP32. > > Of course 2 implies 1. > > For example: > COMPAT_IA32 in sys/ia64/ia64/machdep.c enabled code to save and restore > IA32 registers as part of cpu_switch(). In this context COMPAT_IA32 was > perfectly named. It's now called COMPAT_FREEBSD32, which doesn't make a > lot of sense because what if I only want to support Linux/ia32 and not > FreeBSD/ia32 (or vice-versa if you club them under a single COMPAT_*32)? For amd64 I think COMPAT_LINUX32 requires COMPAT_FREEBSD32 in practice for this reason. If you did make them independent, I would prefer that the code use things like '#if defined(COMPAT_FREEBSD32) || defined(COMPAT_LINUX32)' instead of requiring the user to specify both COMPAT_IA32 and COMPAT_(FREEBSD32|LINUX32). BTW, in that context COMPAT_FREEBSD32 looks far more consistent than other alternatives suggested. I think all of the names have various pros and cons and that changing it is more hassle than its worth. My one suggestion to Nathan was to move COMPAT_FREEBSD32 in GENERIC on amd64 so it is not immediately next to COMPAT_FREEBSD to reduce confusion. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 16:07: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 C1BAD106566B; Tue, 23 Mar 2010 16:07:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 73F488FC19; Tue, 23 Mar 2010 16:07:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZQ00C2MSRTL1A0@asmtp025.mac.com>; Tue, 23 Mar 2010 09:07:06 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003230139 From: Marcel Moolenaar In-reply-to: <4BA8CA90.80208@freebsd.org> Date: Tue, 23 Mar 2010 09:07:05 -0700 Message-id: <0D26A59A-6D21-4FE6-84EC-F8458DD5AF0F@mac.com> References: <4BA8CA90.80208@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1077) Cc: FreeBSD-CURRENT Mailing List Subject: Re: [PATCH] rename COMPAT_FREEBSD32 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, 23 Mar 2010 16:07:13 -0000 On Mar 23, 2010, at 7:05 AM, Nathan Whitehorn wrote: >> On Mar 22, 2010, at 10:52 AM, David O'Brien wrote: >> >>> / On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote: > />>>/ I certainly agree.. can it be changed please? > />>/ />>/ I've waited a while to see what other opinions would be expressed on this > />>/ topic. I believe there is sufficient support to rename COMPAT_FREEBSD32 > />>/ to something else based on responses in the mailing lists. > />>/ />>/ I am sorry if some may wish to label this a "bikeshead". But we seem to > />>/ have many folks disliking "COMPAT_FREEBSD32". > />>/ />>/ />>/ Based on responses to the topic of COMPAT_FREEBSD32, the following > />>/ were the suggestions offered: > />>/ COMPAT_ARCH32, COMPAT_ARCH_32BIT, COMPAT_32BIT_ARCH, COMPAT_32BIT, > />>/ COMPAT_FREEBSD32BIT > /> >> There's probably a bigger problem than just how we name it. The option >> really encodes 2 independent aspects: >> 1. Support for a 32-bit ABI (i.e. ILP32) >> 2. Support for a particular OS in ILP32. >> >> Of course 2 implies 1. >> >> For example: >> COMPAT_IA32 in sys/ia64/ia64/machdep.c enabled code to save and restore >> IA32 registers as part of cpu_switch(). In this context COMPAT_IA32 was >> perfectly named. It's now called COMPAT_FREEBSD32, which doesn't make a >> lot of sense because what if I only want to support Linux/ia32 and not >> FreeBSD/ia32 (or vice-versa if you club them under a single COMPAT_*32)? > > The original version of my my patch had this split, with a COMPAT_FREEBSD32 > and a COMPAT_[IA/PPC/MIPS]32. The problem is that the 32-bit FreeBSD compat is > deeply intertwined with providing support for any 32-bit binaries at all (e.g., > the 32-bit linuxolator depends on calling into it), so it isn't actually possible > to support having COMPAT_LINUX32 without COMPAT_FREEBSD32 without a huge amount > of work. So I scrapped that in favor of the unified name only, and we > ended up with COMPAT_FREEBSD32. I understand. I just wonder if it was wise to expose this dependency across the whole source base with COMPAT_FREEBSD32 rather than keep it local to the linuxulator. What if we remove the dependency at some later point in time? Then what we have left is COMPAT_FREEBSD32 for no reason other than hysterical raisins. Anyway... Just want to point out that it's probably not a good idea to have a single option for multiple features, even if the code has them intertwined. Code changes easily, but options typically don't. Maybe we should improve our config to include dependencies, so that one only has to add "options INVARIANTS" and config knows to include "options INVARIANT_SUPPORT". It's not uncommon for option/device X to need or depend on option/device Y... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 18:19: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 7163C1065670 for ; Tue, 23 Mar 2010 18:19:24 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 47B9F8FC18 for ; Tue, 23 Mar 2010 18:19:24 +0000 (UTC) Received: by pvc7 with SMTP id 7so2203268pvc.13 for ; Tue, 23 Mar 2010 11:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bxrE6G/sI8GjLDq97zbfHDkLbNkv0hozJf/jkUE0Gtk=; b=nkgOzjc3E4apVCihuz2vMcPdxA6gP42oU0G0GmkIAX1D+KWtI7dr2gUuKvOEFHcxbC 5gMelOPTzjLPxfhj+N4TJi5z/rlE83UvXemdbdOr4+kJBGGOdBHervgkB8l8SvSKH8PB R4RQQ3epwSmE+pRttD+zQF1Y/Uc+KixQ/EaK4= 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=g+p/qd/Dqix5wurOGgT8fKhdalDhMKZGlexVsdJ/1fc23oPXJAJsnETQ0HYntSRVuH bi9tslcdb29MBkhOSzwUyjdljwQJz9CgaFrt6MHrrLwjOIglPYXlhoPyVRTMPA8ayGQs Qwmp3M7uvsF7Ky/9ZhKuHeVLYCk1/WdC4nAa0= MIME-Version: 1.0 Received: by 10.142.75.17 with SMTP id x17mr4021002wfa.46.1269368363556; Tue, 23 Mar 2010 11:19:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Mar 2010 13:19:23 -0500 Message-ID: <790a9fff1003231119h5a91d9c6kdc5d50de7ec43eff@mail.gmail.com> From: Scot Hetzel To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 23 Mar 2010 18:19:24 -0000 On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best wrote: > i don't think conf/112997 and the issue where gcc segfaults are directly > related to each other: > > 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native > /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//'` to determine > gcc's idea of the appropriate -mtune value. that command however segfaults. so > this doesn't really help. The command runs correctly with a properly built gcc: # gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//' generic > > 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native` > examples. for me `make` prints the same no matter what CPUTYPE is set to: > > otaku% make -V MACHINE_CPU -DCPUTYPE=native > amd64 sse2 sse > otaku% make -V MACHINE_CPU -DCPUTYPE=nocona > amd64 sse2 sse > otaku% make -V MACHINE_CPU -DCPUTYPE=i386 > amd64 sse2 sse > otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala > amd64 sse2 sse > > ..oh and of course i ran these commands with no CPUTYPE set in make.conf. ;) > If I run the same commands as above, I get similar results: # make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=k8 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=lala amd64 sse2 sse But if I run the commands without the "-D", it shows the problem correctly: # make -V MACHINE_CPU CPUTYPE=native unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=k8 k8 3dnow amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=nocona sse3 amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=i386 unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=lalala unknown amd64 sse2 sse mmx # grep CPUTYPE /etc/make.conf /etc/src.conf grep: /etc/src.conf: No such file or directory This was run under a Feb 28th -CURRENT. Now here is something strange. Defining CPUTYPE in /etc/src.conf has no effect on the output of MACHING_CPU. /etc/src.conf: 1 lines, 11 characters. # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf amd64 sse2 sse /etc/src.conf:CPUTYPE=k8 # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf k8 3dnow amd64 sse2 sse mmx /etc/make.conf:CPUTYPE=k8 Scot From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 19:07:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36136106567A for ; Tue, 23 Mar 2010 19:07:30 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id D49628FC1C for ; Tue, 23 Mar 2010 19:07:29 +0000 (UTC) Received: by pxi12 with SMTP id 12so356987pxi.14 for ; Tue, 23 Mar 2010 12:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uiCZquKk+NnTA4fSohRvq4CqFR6ufkcsI+tO7dRGfZI=; b=do0+LhcE/NVIh9ZOaU9IXiYIHj6Vd1MdVWnmvixZsJG4NUY95PNaKV27w3sR43dE9I BPZQVOGB/if6NqxCO7jQqJFS53gWtptBExnSjII8GjLF+b9PaPzy6WOvyLdoQosapNAS BEpy5GPGhcsCD+z1/PnApxsf0HSou3RMspDu8= 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=YcD3/ljtKtKEBxLHcW5KH77WPNlzKWsmx9g4YGBmDOxzpO8YCd5+S/DkBsF/FpV2oQ q0lUo/iODc20JHhTKaDIRP2Pxy01Ymka10timjq5ywCpld0UIR8+pvucFjbH6JiKDTNG L9G/3zzIy4w3W1Kxunui5N3ImFguNNyklrUnQ= MIME-Version: 1.0 Received: by 10.114.87.9 with SMTP id k9mr7377287wab.222.1269371249315; Tue, 23 Mar 2010 12:07:29 -0700 (PDT) In-Reply-To: <790a9fff1003231119h5a91d9c6kdc5d50de7ec43eff@mail.gmail.com> References: <790a9fff1003231119h5a91d9c6kdc5d50de7ec43eff@mail.gmail.com> Date: Tue, 23 Mar 2010 12:07:29 -0700 Message-ID: <7d6fde3d1003231207v2b60002cl7ba49e22bb0b7559@mail.gmail.com> From: Garrett Cooper To: Scot Hetzel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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, 23 Mar 2010 19:07:30 -0000 On Tue, Mar 23, 2010 at 11:19 AM, Scot Hetzel wrote: > On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best wrote= : >> i don't think conf/112997 and the issue where gcc segfaults are directly >> related to each other: >> >> 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune= =3Dnative >> /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=3D//'` to d= etermine >> gcc's idea of the appropriate -mtune value. that command however segfaul= ts. so >> this doesn't really help. > > The command runs correctly with a properly built gcc: > > # gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 | grep > mtune | sed -e 's/.*mtune=3D//' > generic > >> >> 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=3Dnati= ve` >> examples. for me `make` prints the same no matter what CPUTYPE is set to= : >> >> otaku% make -V MACHINE_CPU -DCPUTYPE=3Dnative >> amd64 sse2 sse >> otaku% make -V MACHINE_CPU -DCPUTYPE=3Dnocona >> amd64 sse2 sse >> otaku% make -V MACHINE_CPU -DCPUTYPE=3Di386 >> amd64 sse2 sse >> otaku% make -V MACHINE_CPU -DCPUTYPE=3Dlalalala >> amd64 sse2 sse >> >> ..oh and of course i ran these commands with no CPUTYPE set in make.conf= . ;) >> > > If I run the same commands as above, I get similar results: > > # make -V MACHINE_CPU -DCPUTYPE=3Dnative > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=3Dk8 > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=3Dnocona > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=3Di386 > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=3Dlala > amd64 sse2 sse > > But if I run the commands without the "-D", it shows the problem correctl= y: > > # make -V MACHINE_CPU CPUTYPE=3Dnative > unknown amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=3Dk8 > k8 3dnow amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=3Dnocona > sse3 amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=3Di386 > unknown amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=3Dlalala > unknown amd64 sse2 sse mmx > # grep CPUTYPE /etc/make.conf /etc/src.conf > grep: /etc/src.conf: No such file or directory > > This was run under a Feb 28th -CURRENT. > > Now here is something strange. =A0Defining CPUTYPE in /etc/src.conf has > no effect on the output of MACHING_CPU. > > /etc/src.conf: 1 lines, 11 characters. > # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf > amd64 sse2 sse > /etc/src.conf:CPUTYPE=3Dk8 > > # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf > k8 3dnow amd64 sse2 sse mmx > /etc/make.conf:CPUTYPE=3Dk8 CPUTYPE can and should be defined in make.conf; it has been this way since the "beginning of time" (tongue in cheek). src.conf gets sourced in bsd.own.mk and make.conf gets sourced in sys.mk. I'll leave it to you to trace down which gets called first and in what order the logic gets evaluated, but I'm pretty sure it's doing the wrong thing when you put CPUTYPE in src.conf. The other thing to keep in mind is that -VCPUTYPE and -DCPUTYPE are evaluated differently: -D variable Define variable to be 1, in the global context. ... -V variable Print make's idea of the value of variable, in the global con- text. Do not build any targets. Multiple instances of this option may be specified; the variables will be printed one per line, with a blank line for each null or undefined variable. So I think that the example code is probably incorrect for -D ;). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 22:31:27 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FE231065677; Tue, 23 Mar 2010 22:31:27 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id EE73E8FC17; Tue, 23 Mar 2010 22:31:26 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 67A298C088; Tue, 23 Mar 2010 17:31:26 -0500 (CDT) Date: Tue, 23 Mar 2010 17:31:26 -0500 From: Mark Linimon To: FreeBSD portmgr secretary Message-ID: <20100323223126.GA3967@lonesome.com> References: <20100323201137.GA45259@goodking.goodking.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100323201137.GA45259@goodking.goodking.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org Subject: Re: Complete ports thaw 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, 23 Mar 2010 22:31:27 -0000 It probably bears repeating that the tree will be unstable for the next few days while a number of large commits hit the tree. These were held off during the release process to make life easier in case portmgr had to do tag-slips. Image processing libraries, xorg, kde, and gnome are scheduled to be updated, among others. mcl From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 22:36: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 ACEA51065670 for ; Tue, 23 Mar 2010 22:36:26 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay2.uni-muenster.de (ZIVM-RELAY2.UNI-MUENSTER.DE [128.176.192.13]) by mx1.freebsd.org (Postfix) with ESMTP id 37A288FC1F for ; Tue, 23 Mar 2010 22:36:25 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,297,1267398000"; d="scan'208";a="239888148" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 23 Mar 2010 23:36:24 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 4A7561B0768; Tue, 23 Mar 2010 23:36:24 +0100 (CET) Date: Tue, 23 Mar 2010 23:36:22 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: <790a9fff1003231119h5a91d9c6kdc5d50de7ec43eff@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: build failures after stdlib update 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, 23 Mar 2010 22:36:26 -0000 Scot Hetzel schrieb am 2010-03-23: > On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best > wrote: > > i don't think conf/112997 and the issue where gcc segfaults are > > directly > > related to each other: > > 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E > > -mtune=native > > /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//'` > > to determine > > gcc's idea of the appropriate -mtune value. that command however > > segfaults. so > > this doesn't really help. > The command runs correctly with a properly built gcc: > # gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep > mtune | sed -e 's/.*mtune=//' > generic i was finally able to solve this issue. it turns out the issue was caused by an option in my CLFAGS called "-fno-builtin". sys/conf/NOTES recommends using this switch for kernel builds, but it seems in a world environment the flag is harmful to gcc. a gcc built with "-fno-builtin" trips over strlen() for some reason. you should be able to reproduce this problem simply by adding "-O2 -fno-strict-aliasing -pipe -fno-builtin" to your CFLAGS. maybe "-O2 -fno-builtin" triggers it too, but "-fno-builtin" (without -O2) doesn't. thanks to everyone for all the help. :) cheers. alex > > 2. i wasn't able to reproduce your `make -V MACHINE_CPU > > -DCPUTYPE=native` > > examples. for me `make` prints the same no matter what CPUTYPE is > > set to: > > otaku% make -V MACHINE_CPU -DCPUTYPE=native > > amd64 sse2 sse > > otaku% make -V MACHINE_CPU -DCPUTYPE=nocona > > amd64 sse2 sse > > otaku% make -V MACHINE_CPU -DCPUTYPE=i386 > > amd64 sse2 sse > > otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala > > amd64 sse2 sse > > ..oh and of course i ran these commands with no CPUTYPE set in > > make.conf. ;) > If I run the same commands as above, I get similar results: > # make -V MACHINE_CPU -DCPUTYPE=native > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=k8 > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=nocona > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=i386 > amd64 sse2 sse > # make -V MACHINE_CPU -DCPUTYPE=lala > amd64 sse2 sse > But if I run the commands without the "-D", it shows the problem > correctly: > # make -V MACHINE_CPU CPUTYPE=native > unknown amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=k8 > k8 3dnow amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=nocona > sse3 amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=i386 > unknown amd64 sse2 sse mmx > # make -V MACHINE_CPU CPUTYPE=lalala > unknown amd64 sse2 sse mmx > # grep CPUTYPE /etc/make.conf /etc/src.conf > grep: /etc/src.conf: No such file or directory > This was run under a Feb 28th -CURRENT. > Now here is something strange. Defining CPUTYPE in /etc/src.conf has > no effect on the output of MACHING_CPU. > /etc/src.conf: 1 lines, 11 characters. > # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf > amd64 sse2 sse > /etc/src.conf:CPUTYPE=k8 > # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf > k8 3dnow amd64 sse2 sse mmx > /etc/make.conf:CPUTYPE=k8 > Scot -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 23:40: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 A1AF71065675 for ; Tue, 23 Mar 2010 23:40:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f185.google.com (mail-yx0-f185.google.com [209.85.210.185]) by mx1.freebsd.org (Postfix) with ESMTP id 4869B8FC21 for ; Tue, 23 Mar 2010 23:40:01 +0000 (UTC) Received: by yxe15 with SMTP id 15so3885991yxe.7 for ; Tue, 23 Mar 2010 16:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=lRhwueFClmX1qNcgJ5OCU1bETeuMSUtPzHjJ2mBfqB0=; b=m7jKlGmHAfWq6ytI2e8hZBhTrxsH0wRroOz2djOGZBM0uHB5HGU9r7O99SLSvFQaU0 h1RaNRCHvy2bvBa+0UiUCCszz34s4gfp5E1i+krGqT4CoBW8ww6PXFQYebGvy7oiiDkC 0RATOp+I4sp8mRg5Y97FQqvZ0LL2rY1AyYknE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=B/pgqnjIgonkm7Puiq5/Ljj1/csCQBDu4zSedsVa+ICWNnRFfsaUCdBcS3ICV8358Q v46/W6uM5YgR+1P7WKUfrcKSoiqUeepW2x3r5b/+f7TRUc4T+VQwjR0FFt60XsHz0Awg vqD/xpUkgILcDVWAFtaLqozJMZqOa+VWLqixM= Received: by 10.150.119.37 with SMTP id r37mr5001445ybc.17.1269387601336; Tue, 23 Mar 2010 16:40:01 -0700 (PDT) Received: from disbatch.dataix.local (adsl-99-109-124-168.dsl.klmzmi.sbcglobal.net [99.109.124.168]) by mx.google.com with ESMTPS id 22sm4896408iwn.8.2010.03.23.16.39.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 16:39:59 -0700 (PDT) Sender: "J. Hellenthal" Date: Tue, 23 Mar 2010 19:39:52 -0400 From: jhell To: Daniel Eischen In-Reply-To: Message-ID: References: <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> <20100322185331.GA88847@dragon.NUXI.org> <20100322.130939.70320533309323962.imp@bsdimp.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, "M. Warner Losh" Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 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, 23 Mar 2010 23:40:02 -0000 On Mon, 22 Mar 2010 15:42, deischen@ wrote: > [ Some CC's stripped ] > > On Mon, 22 Mar 2010, M. Warner Losh wrote: > >> P.S. I think that there's much traction to the idea of moving from >> COMPAT_FREEBSDx to some other variable called, for example, >> COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries >> as old as FreeBSD x.0, and have all the other magic handled behind the >> scenes. This would render the inconsistency with COMPAT_FREEBSDx part >> of the debate completely moot. > > Doesn't matter. We're still use to COMPAT_FREEBSDx since > it's been here so long. So regardless if you rename them > to COMPAT_FREEBSD_BACK_TO=x, it is still potentially confusing. > > COMPAT_ARCH32 and all other choices David mentions seem like > much better names - even if there wasn't any existing > COMPAT_FREEBSDx knobs. > > My $0.02. > > Ill say it again if I have to... COMPAT_ELF32 or possibly even ELF32_SUPPORT seems to me as a very likely possibility. Maybe even: SUPPORT_ELF32= # Support for 32 Bit ELF Binaries This would add its own name structure that is expandabe later-in-future when 128 Bit systems come out ;) Regards, -- jhell From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 23:49: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 C87D7106564A for ; Tue, 23 Mar 2010 23:49:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f185.google.com (mail-yx0-f185.google.com [209.85.210.185]) by mx1.freebsd.org (Postfix) with ESMTP id 70C508FC0A for ; Tue, 23 Mar 2010 23:49:02 +0000 (UTC) Received: by yxe15 with SMTP id 15so3889347yxe.7 for ; Tue, 23 Mar 2010 16:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=cPpTbP6zACoDS3gN0t/diBagR2cWiGEKVLzNA+JfvyA=; b=CUuZO+tL8m9XQ32t4nAiWdKX1dd01bf4l1dkCdYf14onTq4a73WbcNCAA2RhCGmHU5 3LBz+vqJo04Ay5gygTYirQ6eSH26EX4ZiKFGIKzCO3aXejwUViHHGnCsfQXaX/gLHg2S H9v7IKX/0RarfX/PoRXUmFFPThyZf6fSODwac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=lC0WOGgxHpeJdm4b4eaMYNJBaP5ZE+q1iQ21QnmnJH4kY0LaXx0EzuI92q1ahQ4qky 853bmKiZZecIiHVGYbrt4naWJtitzwq3mLMmc57a2b5DRFi33wLOPiJk/dmzxzV/byAf eR+U0rKwiRi+fBiRLdExUPZsjQPG8r4Kd0J68= Received: by 10.101.15.19 with SMTP id s19mr1083672ani.4.1269388141326; Tue, 23 Mar 2010 16:49:01 -0700 (PDT) Received: from disbatch.dataix.local (adsl-99-109-124-168.dsl.klmzmi.sbcglobal.net [99.109.124.168]) by mx.google.com with ESMTPS id 21sm5453437iwn.11.2010.03.23.16.48.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 16:48:59 -0700 (PDT) Sender: "J. Hellenthal" Date: Tue, 23 Mar 2010 19:48:56 -0400 From: jhell To: Alexander Best In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-current@freebsd.org, Pegasus Mc Cleaft Subject: Re: build failures after stdlib update 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, 23 Mar 2010 23:49:03 -0000 On Tue, 23 Mar 2010 06:40, alexbestms@ wrote: > Pegasus Mc Cleaft schrieb am 2010-03-23: >> -----Original Message----- >>> 2. i wasn't able to reproduce your `make -V MACHINE_CPU >>> -DCPUTYPE=native` >>> examples. for me `make` prints the same no matter what CPUTYPE is >>> set to: > >>> otaku% make -V MACHINE_CPU -DCPUTYPE=native >>> amd64 sse2 sse >>> otaku% make -V MACHINE_CPU -DCPUTYPE=nocona >>> amd64 sse2 sse >>> otaku% make -V MACHINE_CPU -DCPUTYPE=i386 >>> amd64 sse2 sse >>> otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala >>> amd64 sse2 sse > >>> ..oh and of course i ran these commands with no CPUTYPE set in >>> make.conf. >> ;) > >> This is interesting. I tried the same thing on my computer (AMD64 - >> Core2 >> Quad) and I get the following > >> (Without CPUTYPE?=native in /etc/make) >> feathers$ make -V MACHINE_CPU -DCPUTYPE=native >> amd64 sse2 sse > >> (With CPUTYPE?=native) >> feathers$ make -V MACHINE_CPU -DCPUTYPE=native >> unknown amd64 sse2 sse mmx > >> (For both) >> feathers$ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | >> grep >> mtune >> /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null >> -mtune=generic > > hmm...that's odd indeed. i finally was able to do some debugging. i've > attached two files: > > running gcc -v -x c -E -mtune=native /dev/null and gcc -v -x c -E > -mtune=nocona /dev/null > >> Peg > Both the commands that your showing the output of in the attached output are using gdb when the options that were presented are for gcc. `gdb -v -x c -E -mtune=native /dev/null` Should probably be: `gcc -v -x c -E -mtune=native /dev/null` Right ? Regards, -- jhell From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 00:06: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 44E26106564A for ; Wed, 24 Mar 2010 00:06:25 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id DFA548FC1E for ; Wed, 24 Mar 2010 00:06:24 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 8D8A9A59660; Wed, 24 Mar 2010 08:06:23 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id lkqGrAt0c7q0; Wed, 24 Mar 2010 08:06:17 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 2926AA5503F; Wed, 24 Mar 2010 08:06:15 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=ii+0AdGfa+r9S81YYRM6qyGlfhuKhzgLu3NvrNzcal/QjAcPGzdPDYqIk1Ljawgx+ bFXUZZSXTdc8f/pMg2Mfw== Message-ID: <4BA95774.8030005@delphij.net> Date: Tue, 23 Mar 2010 17:06:12 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100304 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Pegasus Mc Cleaft Subject: Re: build failures after stdlib update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 00:06:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It looks like the stack somehow mangled before entering strlen()? I'm somehow confused with this... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLqVdzAAoJEATO+BI/yjfBWCkH/074A9sBUlo8hBTCPM68fVo1 UNRJrqa3fuATryjSeoQnXtB9lL48v2qESQ083t8deOlX/dHlS8FNuZ5GUdw11R91 RrZkoIRUd4pqCfC55R7Kov/TVusV6iSm7rDQJljczYB/OAsy435kSURCP6ZmGnlp TPp8rMRIUryQ7vy98T0OQODsBZsc6I+5K1GhTD2/zEw3PtpHiV7nxAvHqmyXJp39 hvMt9ZqVpg+JlIXmnv5KXLRdZXeezKxB1oXWQ3KcUAXpi+CV5pnyd/GczfW+zAjl G0hv2BgEs6Vwy51OY2pPJR9QFk6F5H1srdryxHuXUpCgo7WM+V1aG65P4jXOADQ= =lx4U -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 00:49: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 ACD1E106566B for ; Wed, 24 Mar 2010 00:49:54 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id EB1588FC0C for ; Wed, 24 Mar 2010 00:49:53 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so1233327fga.13 for ; Tue, 23 Mar 2010 17:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LTwJIJvxnoHEcPDnUEeBPSEq8KV+liiFCIf6D02AGgs=; b=V0XAoIgbxLF+fhvYu0Gh7EIYIrqHAG222Mf//iuqPdJJ/HkXe9UIXiqbhwpE+3/hr0 mT1Nz1tXlBLwx6PnDn2+tnAKqaYSEUY/U1r0zn5Si7ApFNO1kRUCx9vSu+UvRgUnVgvA kuU0ZZpshnPh+XRBMwXTM1DVrxfm+LwD182i4= 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=tuKDR66i/M+4X8abgOjjWM2XPoaTjfJn0ijd/PJHbkclm31sXPoM88ye82fXhJ7p9/ HrnY4PpcOWuhpFHP9NCWodBxZSLeGxqdFdd0an+HBokM7/ZrlBU+Nk0KXl9pyDfmaluX MQNzN8vHBDyZaXkJ+xMmGP3QBmmda5/ptSODw= MIME-Version: 1.0 Received: by 10.239.152.130 with SMTP id v2mr2083744hbb.168.1269391789775; Tue, 23 Mar 2010 17:49:49 -0700 (PDT) In-Reply-To: References: <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> <20100322185331.GA88847@dragon.NUXI.org> <20100322.130939.70320533309323962.imp@bsdimp.com> Date: Tue, 23 Mar 2010 21:49:49 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Daniel Eischen , freebsd-current@freebsd.org, "M. Warner Losh" Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 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, 24 Mar 2010 00:49:54 -0000 On Tue, Mar 23, 2010 at 8:39 PM, jhell wrote: > > On Mon, 22 Mar 2010 15:42, deischen@ wrote: >> >> [ Some CC's stripped ] >> >> On Mon, 22 Mar 2010, M. Warner Losh wrote: >> >>> P.S. =A0I think that there's much traction to the idea of moving from >>> COMPAT_FREEBSDx to some other variable called, for example, >>> COMPAT_FREEBSD_BACK_TO=3Dx, which will give compatibility for binaries >>> as old as FreeBSD x.0, and have all the other magic handled behind the >>> scenes. =A0This would render the inconsistency with COMPAT_FREEBSDx par= t >>> of the debate completely moot. >> >> Doesn't matter. =A0We're still use to COMPAT_FREEBSDx since >> it's been here so long. =A0So regardless if you rename them >> to COMPAT_FREEBSD_BACK_TO=3Dx, it is still potentially confusing. >> >> COMPAT_ARCH32 and all other choices David mentions seem like >> much better names - even if there wasn't any existing >> COMPAT_FREEBSDx knobs. >> >> My $0.02. >> >> > > > Ill say it again if I have to... COMPAT_ELF32 or possibly even ELF32_SUPP= ORT > seems to me as a very likely possibility. > > Maybe even: > SUPPORT_ELF32=3D =A0 =A0 =A0 =A0 =A0# Support for 32 Bit ELF Binaries > > This would add its own name structure that is expandabe later-in-future w= hen > 128 Bit systems come out ;) ELF may go away sometime, just like a.out went to the holly pastures. --=20 Not so young, but still crying out Full of anger full of doubt From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 00:55: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 32509106566B for ; Wed, 24 Mar 2010 00:55:20 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (unknown [IPv6:2002:51af:3dc3:0:20c:29ff:fece:79f3]) by mx1.freebsd.org (Postfix) with ESMTP id B209B8FC17 for ; Wed, 24 Mar 2010 00:55:19 +0000 (UTC) Received: from [IPv6:2002:51af:3dc3:0:a0ca:c8c0:86b4:466e] (unknown [IPv6:2002:51af:3dc3:0:a0ca:c8c0:86b4:466e]) (Authenticated sender: svein-listmail) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id B38A27C for ; Wed, 24 Mar 2010 01:55:00 +0100 (CET) Message-ID: <4BA962DE.3000107@stillbilde.net> Date: Wed, 24 Mar 2010 01:54:54 +0100 From: "Svein Skogen (Listmail Account)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> <20100322185331.GA88847@dragon.NUXI.org> <20100322.130939.70320533309323962.imp@bsdimp.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 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, 24 Mar 2010 00:55:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24.03.2010 01:49, Carlos A. M. dos Santos wrote: > On Tue, Mar 23, 2010 at 8:39 PM, jhell wrote: >> >> On Mon, 22 Mar 2010 15:42, deischen@ wrote: >>> >>> [ Some CC's stripped ] >>> >>> On Mon, 22 Mar 2010, M. Warner Losh wrote: >>> >>>> P.S. I think that there's much traction to the idea of moving from >>>> COMPAT_FREEBSDx to some other variable called, for example, >>>> COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries >>>> as old as FreeBSD x.0, and have all the other magic handled behind the >>>> scenes. This would render the inconsistency with COMPAT_FREEBSDx part >>>> of the debate completely moot. >>> >>> Doesn't matter. We're still use to COMPAT_FREEBSDx since >>> it's been here so long. So regardless if you rename them >>> to COMPAT_FREEBSD_BACK_TO=x, it is still potentially confusing. >>> >>> COMPAT_ARCH32 and all other choices David mentions seem like >>> much better names - even if there wasn't any existing >>> COMPAT_FREEBSDx knobs. >>> >>> My $0.02. >>> >>> >> >> >> Ill say it again if I have to... COMPAT_ELF32 or possibly even ELF32_SUPPORT >> seems to me as a very likely possibility. >> >> Maybe even: >> SUPPORT_ELF32= # Support for 32 Bit ELF Binaries >> >> This would add its own name structure that is expandabe later-in-future when >> 128 Bit systems come out ;) > > ELF may go away sometime, just like a.out went to the holly pastures. It may. But having a confusing directive (the COMPAT_FREEBSD32 vs COMPAT_FREEBSD[4567]) is likely to stay with us for a long, long, long time. Just like the scarring after a bullet wound to the foot. //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg Řstli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkupYt4ACgkQODUnwSLUlKTWHQCePMfrdHKqTryA5DQ4T8aRlKfM jwUAnRmjdXdAwXB2gEvgNV8609ctqDY9 =q+B1 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 01:09: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 0C539106564A; Wed, 24 Mar 2010 01:09:09 +0000 (UTC) (envelope-from jhellenthal@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 8D2848FC08; Wed, 24 Mar 2010 01:09:08 +0000 (UTC) Received: by gyh3 with SMTP id 3so933424gyh.13 for ; Tue, 23 Mar 2010 18:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type:content-transfer-encoding; bh=LpRh7X7+9ex7zHDSFF5sKMTvxsUOkMnzm6D7Ti2umrA=; b=vRAbzPfkyZObfCJ4t3luqqEsGA2HcsKEkzfG6LkiW3buoFUgJX4+6y0ub6OTpH7d2q s+YXzMBZESFx4NsP6EszFpBNuAfoq7JrwxVg4A/ug6niVGFCRv1pjybbm6Y7BBgMJwVe fGKcgJFLXL4uQlHYGC4OtTu6DnwgKrQGDyjpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type:content-transfer-encoding; b=JpBJNI1EbQans5WQHuiEp3YbYSDJvYG8030fBljRxWdjxMXG2mVOX4ifjdB0TKuti0 /M35vIN6lFevUfvslCfUpQU3j5g/tr5XhP6lAoJuC/122bjiHdaaHICll73d043PjySz muIfhOfwvHegeTP3qbax4GsEFcy1LQE4DhNWU= Received: by 10.150.56.7 with SMTP id e7mr3658986yba.203.1269392947516; Tue, 23 Mar 2010 18:09:07 -0700 (PDT) Received: from centel.dataix.local (adsl-99-109-124-168.dsl.klmzmi.sbcglobal.net [99.109.124.168]) by mx.google.com with ESMTPS id 21sm5521235iwn.3.2010.03.23.18.09.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 18:09:06 -0700 (PDT) Sender: "J. Hellenthal" Date: Tue, 23 Mar 2010 21:08:59 -0400 From: jhell To: "Carlos A. M. dos Santos" In-Reply-To: Message-ID: References: <20100312171758.GB31089@dragon.NUXI.org> <20100312.125032.270969355930630649.imp@bsdimp.com> <20100322185331.GA88847@dragon.NUXI.org> <20100322.130939.70320533309323962.imp@bsdimp.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: Daniel Eischen , freebsd-current@freebsd.org, "M. Warner Losh" Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 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, 24 Mar 2010 01:09:09 -0000 On Tue, 23 Mar 2010 20:49, Carlos A. M. dos Santos wrote: In Message-Id: > On Tue, Mar 23, 2010 at 8:39 PM, jhell wrote: >> >> On Mon, 22 Mar 2010 15:42, deischen@ wrote: >>> >>> [ Some CC's stripped ] >>> >>> On Mon, 22 Mar 2010, M. Warner Losh wrote: >>> >>>> P.S.  I think that there's much traction to the idea of moving from >>>> COMPAT_FREEBSDx to some other variable called, for example, >>>> COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries >>>> as old as FreeBSD x.0, and have all the other magic handled behind the >>>> scenes.  This would render the inconsistency with COMPAT_FREEBSDx part >>>> of the debate completely moot. >>> >>> Doesn't matter.  We're still use to COMPAT_FREEBSDx since >>> it's been here so long.  So regardless if you rename them >>> to COMPAT_FREEBSD_BACK_TO=x, it is still potentially confusing. >>> >>> COMPAT_ARCH32 and all other choices David mentions seem like >>> much better names - even if there wasn't any existing >>> COMPAT_FREEBSDx knobs. >>> >>> My $0.02. >>> >>> >> >> >> Ill say it again if I have to... COMPAT_ELF32 or possibly even ELF32_SUPPORT >> seems to me as a very likely possibility. >> >> Maybe even: >> SUPPORT_ELF32=          # Support for 32 Bit ELF Binaries >> >> This would add its own name structure that is expandabe later-in-future when >> 128 Bit systems come out ;) > > ELF may go away sometime, just like a.out went to the holly pastures. > > Alright, that's like anything else in the world of computer sciences. But that still does not dismiss its purpose and right now ELF is in full swing and when the time comes... 10, 20, 30 years down the road then you simply add something else but by that point 32 bit computing will probably be history so there wont need to be any of this fuss for ELF or 32 bit support at that time. -- jhell From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 02:10: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 D6577106566B for ; Wed, 24 Mar 2010 02:10:09 +0000 (UTC) (envelope-from neshort@yahoo.com) Received: from web56508.mail.re3.yahoo.com (web56508.mail.re3.yahoo.com [66.196.97.37]) by mx1.freebsd.org (Postfix) with SMTP id 670518FC19 for ; Wed, 24 Mar 2010 02:10:09 +0000 (UTC) Received: (qmail 62761 invoked by uid 60001); 24 Mar 2010 01:43:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1269395007; bh=QkF4kVGYex8t2AuXjFDOo+QvjYDF+2DCItMpr0XQT6s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=XxeAdod+cChKcf6hcAZ7Tx2qvy6QfpXGXw1eI+VOiVrz8SdLXlbLrhCyHHQeGCGCoqQbt4uw++cZWb0SQQuAEjf3n6hOLbaDbf85NeysTkpmKKMtYvWZnmfVMPkgoxstLLGY1sZLF9TcUBuaKHPR8T/RJUzbolWCOBS7fGQEQnI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=uHjz1fm5WHm629JvXOgVLLSgQ38ngd76cQk5awiBNnkxvn6Fg+Ku2CVdu2WP9zSQYc3te6aEdQNylwV2JvOjDxzmVc27A7Wp6/I26XB5zsG7aQ8XousYa15QZI3hchTRg/sDKhIIs+GBxUdl1GFDAhUtjXpAC1AcG9uCGDMlxq4=; Message-ID: <56925.60969.qm@web56508.mail.re3.yahoo.com> X-YMail-OSG: mDw0.qoVM1lkXy9DVQOK.2avrNIlwrW2rBQyH5Jzzvu.sjz yqVUFt0NlzMJBtzdT2NbW8_A34m34Kx1ZiCWq58NEQtARTzJAiJfs08527QM Vea5dBy7_Od2GziYDAbm.c5jd0v1t2p5QtMpAotHjCEZsN9FXieQw84QYNUu CsrV0BRiOucpxqC6mX7XEbBaav2qRYtgRa2zM69IjegdCrWf66blc5Y8_i51 ZSvAgMhTSzAhAwmooei2RK0CIyz8C.9bdr3p_kSCJaISrD2FYVj_LGRP.dAj 6yBfO3cn6yLEzmcNkY3Bp7e2v7Q-- Received: from [174.18.51.36] by web56508.mail.re3.yahoo.com via HTTP; Tue, 23 Mar 2010 18:43:26 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Tue, 23 Mar 2010 18:43:26 -0700 (PDT) From: Neil Short To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: ath9k 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, 24 Mar 2010 02:10:09 -0000 Is anybody working on implementing the ath9k wireless driver? Just curious. I have reserved a huge chunk of my hard drive on my laptop - in anticipation of FreeBSD supporting that device. Using a linux distro in the mean time. ====== "What did you do?" the man holding the flashlight asked. "I put down a spider," he said, wondering why the man didn't see; in the beam of yellow light the spider bloated up larger than life. "So it could get away." From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 09:54:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF371065675 for ; Wed, 24 Mar 2010 09:54:27 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id BA21C8FC0C for ; Wed, 24 Mar 2010 09:54:26 +0000 (UTC) Received: by bwz8 with SMTP id 8so931976bwz.3 for ; Wed, 24 Mar 2010 02:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=j5y70T1clYVol4jJqh/P4tKMi0Vo6WjsFGpVOlq5Q8k=; b=rBHZsgCMAMHxe2YYnQFBp58zCwOtks/tOkNQ4R9qErPYwkA4GAhaJap6RG4Oc0Hf5q gXFbWCubUO/6BZB/z6X4b+JZ5IhLkAJp6lLKuxd2spwT+7+tGkBy9hf2gDNVPiozNWOO AY0ijFnxbgDi7Jgg/jynww8woEESmZWDnLSuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Sp48GZAuI0CfhMz/dQSEtstK2d5bk/NuKrVM5fZiCU2MEVbEZOJysLRHK4mTTNYeOj O3yf1BWI6nfxLdKV9//EKh1jsF32K3sb94Ky15lXCaQ03YHFe0uenmQmGGC3kmahSJot Rzq2wPMKCvv9CLTYf5WDVcdqsWbhsZw6vqLw0= Received: by 10.204.130.153 with SMTP id t25mr5681167bks.85.1269424465361; Wed, 24 Mar 2010 02:54:25 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 24sm34215631bkr.18.2010.03.24.02.54.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Mar 2010 02:54:23 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <56925.60969.qm@web56508.mail.re3.yahoo.com> Date: Wed, 24 Mar 2010 09:54:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56925.60969.qm@web56508.mail.re3.yahoo.com> To: Neil Short X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org Subject: Re: ath9k 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, 24 Mar 2010 09:54:27 -0000 On 24 Mar 2010, at 01:43, Neil Short wrote: > Is anybody working on implementing the ath9k wireless driver? >=20 > Just curious. I have reserved a huge chunk of my hard drive on my = laptop - in anticipation of FreeBSD supporting that device. Using a = linux distro in the mean time. Several chipsets support by the ath9k driver are supported on FreeBSD = with the ath(4) driver. Try FreeBSD HEAD or 8.0-STABLE. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 15:33: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 901771065672 for ; Wed, 24 Mar 2010 15:33:45 +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 CCE488FC18 for ; Wed, 24 Mar 2010 15:33:43 +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 RAA15927; Wed, 24 Mar 2010 17:33:32 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4BAA30CB.1070707@icyb.net.ua> Date: Wed, 24 Mar 2010 17:33:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Paul B Mahol , Fabian Keil References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> In-Reply-To: <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: newfs_msdos and DVD-RAM 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, 24 Mar 2010 15:33:45 -0000 on 19/03/2010 20:26 Paul B Mahol said the following: > On Fri, Mar 19, 2010 at 7:11 PM, Fabian Keil > wrote: >> Paul B Mahol wrote: >> >>> FreeBSD 9.0 CURRENT panics when mounting file system created via >>> newfs_msdos on DVD-RAM disc. >>> Something to do about divide by zero. >> I recently had a similar problem with a 16GB iPod. I still haven't >> managed to actually mount it, but the patch below at least works >> around the panic. >> >> Does it work for you, too? > > Obviously it will fix panic, but will not allow to mount. Zero value > should be handled > already much before. It looks the real bug is in newfs_msdos. > Looking at the code in mountmsdosfs(), it seems that SecPerClust can have zero value at the place of the crash only if pm_BlkPerSec is zero. See this line and the check above it: SecPerClust *= pmp->pm_BlkPerSec; But that is impossible because of the same if statement. In my opinion, the only possible explanation is an overflow of a SecPerClust value. Given that its type is u_int8_t, it seems plausible. It would be really nice if people who can reproduce this issue could either add a couple of printfs before the quoted above line or examined a crashdump to determine values of SecPerClust and pm_BlkPerSec before the multiplication. Could you guys please do it? Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 20:26: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 D6E2A106566B for ; Wed, 24 Mar 2010 20:26:13 +0000 (UTC) (envelope-from bofh@redwerk.com) Received: from redwerk.com (redwerk.com [89.105.196.9]) by mx1.freebsd.org (Postfix) with ESMTP id 75DF38FC0C for ; Wed, 24 Mar 2010 20:26:13 +0000 (UTC) Received: from [192.168.250.7] (helo=localhost) by redwerk.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1NuX9W-0003y3-Fw for freebsd-current@freebsd.org; Wed, 24 Mar 2010 21:26:11 +0100 Received: from bofh by localhost with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuX9z-0000sY-Qo for freebsd-current@freebsd.org; Wed, 24 Mar 2010 22:26:39 +0200 Date: Wed, 24 Mar 2010 22:26:39 +0200 From: Eugeny N Dzhurinsky To: freebsd-current@freebsd.org Message-ID: <20100324202639.GA3194@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue -> wpa_supplicant hangs 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, 24 Mar 2010 20:26:14 -0000 Hi! I am facing very strange issue - for some reason wpa_supplicant hands after associating connection with AP. It doesn't hang immediately - but after some time (amout a minute or so). I tried to run it as wpa_supplicant -ddd -i wlan1 -c /etc/wpa_supplicant.conf and in logs I don't see any errors: =============================================================================================== .... WPA: RX message 1 of Group Key Handshake from 00:1b:11:01:6b:f6 (ver=2) State: GROUP_HANDSHAKE -> GROUP_HANDSHAKE WPA: Group Key - hexdump(len=32): [REMOVED] WPA: Installing GTK to the driver (keyidx=2 tx=0 len=32). WPA: RSC - hexdump(len=6): 0e 00 00 00 00 00 wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=2 set_tx=0 seq_len=6 key_len=32 WPA: Sending EAPOL-Key 2/2 WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 03 22 00 20 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 91 13 79 11 04 55 fe 1e a3 12 f9 63 96 6b e8 b8 00 00 WPA: Key negotiation completed with 00:1b:11:01:6b:f6 [PTK=CCMP GTK=TKIP] Cancelling authentication timeout State: GROUP_HANDSHAKE -> COMPLETED CTRL-EVENT-CONNECTED - Connection to 00:1b:11:01:6b:f6 completed (auth) [id=0 id_str=] EAPOL: External notification - portValid=1 EAPOL: External notification - EAP success=1 EAPOL: SUPP_PAE entering state AUTHENTICATING EAPOL: SUPP_BE entering state SUCCESS EAP: EAP entering state DISABLED EAPOL: SUPP_PAE entering state AUTHENTICATED EAPOL: SUPP_BE entering state IDLE EAPOL authentication completed successfully EAPOL: startWhen --> 0 EAPOL: disable timer tick =============================================================================================== ifconfig looks like below: =============================================================================================== re0: flags=8802 metric 0 mtu 1500 options=389b ether 00:26:18:92:e4:16 media: Ethernet autoselect (10baseT/UTP ) status: no carrier lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 ath0: flags=8843 metric 0 mtu 2290 ether 00:25:d3:5c:f0:c8 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan1: flags=8843 metric 0 mtu 1500 ether 00:25:d3:5c:f0:c8 inet 192.168.10.3 netmask 0xffffff00 broadcast 192.168.10.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid freebsdap channel 10 (2457 MHz 11g) bssid 00:1b:11:01:6b:f6 regdomain NONE country UA indoor ecm authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpower 30 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL =============================================================================================== uname -a FreeBSD localhost 8.0-STABLE FreeBSD 8.0-STABLE #34: Mon Mar 22 23:31:30 EET 2010 root@localhost:/usr/obj/usr/src/sys/BOFH i386 atheros driver is loaded as module. What may be wrong there? Thank you in advance! -- Eugene N Dzhurinsky From owner-freebsd-current@FreeBSD.ORG Thu Mar 25 00:29: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 77C7D1065670 for ; Thu, 25 Mar 2010 00:29:55 +0000 (UTC) (envelope-from neshort@yahoo.com) Received: from web56506.mail.re3.yahoo.com (web56506.mail.re3.yahoo.com [66.196.97.35]) by mx1.freebsd.org (Postfix) with SMTP id 251428FC16 for ; Thu, 25 Mar 2010 00:29:54 +0000 (UTC) Received: (qmail 10828 invoked by uid 60001); 25 Mar 2010 00:29:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1269476994; bh=t5GsMzlsh21Kp4A5sDATyb7SYGnYmo19dYQCc45lHQs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P9oS+mwyDwJRv0UWalX9k6pwFrl0c+xSWGPBz6Ct/rUco4WzSQ83j9vMlUq1Txc8S8pArWfUXqw7W0zPbKH4M1QAe+eK3clft7+dvAoiYjSb0OVINN6rYG5JEUwy74Am01vrm7EsRIp/LKoZ3QNtbovIdbFI4VxnInbF7bWJ7n8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YWzcmHpoJXDGZvjsamGxWwcqONoDw2MbCtB8aS3EyMRxPWLP9G8BPbgtSB+9eNergI6pdHxVYDNU12Q3MjbSvoqaUqVf093GmBDOXsESjH3RNZBN2t9tBYE76zGAUPucDhJQp8dYTtMm9P3PewdKBjKdi5cpKZ1VPC1nsVDNORM=; Message-ID: <285300.10793.qm@web56506.mail.re3.yahoo.com> X-YMail-OSG: MYWulhwVM1k9o6LHqF0SLUApGhzm15nInXLM5giJwGbsiQj cwBmj_s5BjR3GlrRkkWTW70MQvayGTRoWBG64LdnT.cxNT6XeyUwG_hpFn1M 817ixg6FTD7k34OoTkGFV.FeLJSzXk4UI7bmzCNoHijEPcOo8FB_PULvWE.p CjIvI1VS4PbXj0KzfpEPxmBZlzt0aBiuKYZEkK428OuNM.3jNEklqokJtPy2 oi2VjJf.Cf6aXJFNvOrrFo1MQ8fq_O5nuQXAml98s0J5CG9c6kZSkLg3LkaU KLu1FrYB_e8oUCEdibCaHY.WypPjU78cSr7.duKR4EtpjuBdw11BRmDqD9Mq 44zv5_teoadw20ME_U8If0RI3oaRN Received: from [174.18.51.36] by web56506.mail.re3.yahoo.com via HTTP; Wed, 24 Mar 2010 17:29:53 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Wed, 24 Mar 2010 17:29:53 -0700 (PDT) From: Neil Short To: Rui Paulo , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: ath9k 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, 25 Mar 2010 00:29:55 -0000 =0A=0A--- On Wed, 3/24/10, Rui Paulo wrote:=0A=0A> Fro= m: Rui Paulo =0A> Subject: Re: ath9k=0A> To: "Neil Shor= t" =0A> Cc: freebsd-current@freebsd.org=0A> Date: Wednes= day, March 24, 2010, 3:54 AM=0A> On 24 Mar 2010, at 01:43, Neil Short=0A> w= rote:=0A> =0A> > Is anybody working on implementing the ath9k wireless=0A> = driver?=0A> > =0A> > Just curious. I have reserved a huge chunk of my hard= =0A> drive on my laptop - in anticipation of FreeBSD supporting=0A> that de= vice. Using a linux distro in the mean time.=0A> =0A> Several chipsets supp= ort by the ath9k driver are supported=0A> on FreeBSD with the ath(4) driver= . Try FreeBSD HEAD or=0A> 8.0-STABLE.=0A> =0A> --=0A> Rui Paulo=0A> =0A> = =0AIt looks like mine is=A0 Atheros AR9285 MAC/BB Rev:2 AR5133. FreeBSD see= ms to see it; but it fails to connect with it.=0A=0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Thu Mar 25 08:18: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 85621106566C for ; Thu, 25 Mar 2010 08:18:21 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 0CCA88FC0C for ; Thu, 25 Mar 2010 08:18:20 +0000 (UTC) Received: by fxm24 with SMTP id 24so2858335fxm.3 for ; Thu, 25 Mar 2010 01:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NzIjnTUD65Xd9CbvHhAyNlGdNIEwhxE4najl4Uq4wd4=; b=Gvn8So4jyLYMXJY2DVNrQDvrfaDQbrWfQw/Nc2qNFF2fVO6LBT/ZqdeYLMVYVXd7ym 9VtXSNhCoE/whZJZArgN55y0vouet5G0ihE4IBS9fL+tq+0xf81AVn8O7/SpTVC8TI24 AWLhWOEiSAffRMwSBLiZzVWYHqRgYkc5PmeIY= 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=UhpSZcFl5Lu9QzqUmohmizhzFajU5WFZ5zQTNE6+MgKUr5gLGOFUugJOWIOADmoX8H C527iD3+pQOpHtro5WLNczIjSOAlTSm//jS8b3XEb6Kz51mCsFLLFjsPCsh32ZXnyahE NO/0DTWRLcxnxeA5iFR5yGJUHAGUGrHw0R8FQ= MIME-Version: 1.0 Received: by 10.223.72.65 with SMTP id l1mr6440947faj.66.1269505099691; Thu, 25 Mar 2010 01:18:19 -0700 (PDT) In-Reply-To: <4e6cba831003131556t2cb787e0xc9e2d649320d6e59@mail.gmail.com> References: <7d6fde3d1003070207q621e69ado2cb64e431feacd76@mail.gmail.com> <7d6fde3d1003070224k3626a9b5y98c11a43eef1bed4@mail.gmail.com> <4e6cba831003101356i534341ffr2961b983854ab788@mail.gmail.com> <7dc40bd01003101407m605e41ey2d8ace0049cf5e61@mail.gmail.com> <7d6fde3d1003102158o7834ca67lce3eca23aa723fd1@mail.gmail.com> <7d6fde3d1003121933s4ba7b57fw6542628c16edf723@mail.gmail.com> <4e6cba831003131556t2cb787e0xc9e2d649320d6e59@mail.gmail.com> Date: Thu, 25 Mar 2010 09:18:19 +0100 Message-ID: <4e6cba831003250118q32b877c4rdef9f001d3715a84@mail.gmail.com> From: Giovanni Trematerra To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , Tom Couch Subject: Re: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)? 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, 25 Mar 2010 08:18:21 -0000 Sorry for top posting. I report just for the record the test that Garrett kindly did. On Wed, Mar 24, 2010 at 8:45 PM, Garrett Cooper wrote: > The patch looks good for commit. No performance regression at > boot, no functional regression when the keyboard's detached, and if > I'm not mistaken it appears that performance actually improves at > reboot (seems like the window between the final fs sync and the reboot > is more along the lines of what's expected for a system that doesn't > have the RAID card). > Thanks! > -Garrett On Sun, Mar 14, 2010 at 12:56 AM, Giovanni Trematerra wrote: > On Sat, Mar 13, 2010 at 4:33 AM, Garrett Cooper wrot= e: >> On Wed, Mar 10, 2010 at 9:58 PM, Garrett Cooper >>> > > if you don't mind could you try this patch? Less dirty but always quick := ) > > Thank you for your time. > > -- > Gianni > > > diff -r 69c84861a227 sys/dev/twa/tw_cl.h > --- a/sys/dev/twa/tw_cl.h =A0 =A0 =A0 Thu Mar 11 16:18:11 2010 -0500 > +++ b/sys/dev/twa/tw_cl.h =A0 =A0 =A0 Sat Mar 13 18:50:16 2010 -0500 > @@ -66,6 +66,8 @@ > =A0#define TW_CLI_CTLR_STATE_RESET_PHASE1_IN_PROGRESS =A0 =A0 (1<<5) > =A0/* G66 register write access bug needs to be worked around. */ > =A0#define TW_CLI_CTLR_STATE_G66_WORKAROUND_NEEDED =A0 =A0 =A0 =A0(1<<6) > +/* Controller is shutting down. */ > +#define TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS (1<<7) > > =A0/* Possible values of ctlr->ioctl_lock.lock. */ > =A0#define TW_CLI_LOCK_FREE =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x0 =A0 =A0 /* lo= ck is free */ > diff -r 69c84861a227 sys/dev/twa/tw_cl_init.c > --- a/sys/dev/twa/tw_cl_init.c =A0Thu Mar 11 16:18:11 2010 -0500 > +++ b/sys/dev/twa/tw_cl_init.c =A0Sat Mar 13 18:50:16 2010 -0500 > @@ -598,6 +598,7 @@ tw_cl_shutdown_ctlr(struct tw_cl_ctlr_ha > =A0 =A0 =A0 =A0 * and notify the controller that we are going down. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0ctlr->state &=3D ~TW_CLI_CTLR_STATE_ACTIVE; > + =A0 =A0 =A0 ctlr->state |=3D TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS; > > =A0 =A0 =A0 =A0tw_cli_disable_interrupts(ctlr); > > diff -r 69c84861a227 sys/dev/twa/tw_cl_intr.c > --- a/sys/dev/twa/tw_cl_intr.c =A0Thu Mar 11 16:18:11 2010 -0500 > +++ b/sys/dev/twa/tw_cl_intr.c =A0Sat Mar 13 18:50:16 2010 -0500 > @@ -75,9 +75,12 @@ tw_cl_interrupt(struct tw_cl_ctlr_handle > =A0 =A0 =A0 =A0if (ctlr =3D=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; > > - =A0 =A0 =A0 /* If we get an interrupt while resetting, it is a shared > - =A0 =A0 =A0 =A0 =A0one for another device, so just bail */ > - =A0 =A0 =A0 if (ctlr->state & TW_CLI_CTLR_STATE_RESET_IN_PROGRESS) > + =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0* If we get an interrupt while resetting or shutting dow= n, > + =A0 =A0 =A0 =A0* it is a shared one for another device, so just bail > + =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 if (ctlr->state & TW_CLI_CTLR_STATE_RESET_IN_PROGRESS || > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctlr->state & TW_CLI_CTLR_STATE_SHUTDOWN_IN= _PROGRESS) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; > > =A0 =A0 =A0 =A0/* > From owner-freebsd-current@FreeBSD.ORG Thu Mar 25 14:03:52 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 CC38F106564A; Thu, 25 Mar 2010 14:03:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 61A8C8FC28; Thu, 25 Mar 2010 14:03:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC8Kq0uDaFvK/2dsb2JhbACbJXO/GYR9BA X-IronPort-AV: E=Sophos;i="4.51,307,1267419600"; d="scan'208";a="70280373" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 25 Mar 2010 10:03:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 3C765109C2C8; Thu, 25 Mar 2010 10:03:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTuzWAPzgG6J; Thu, 25 Mar 2010 10:03:48 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 89F0A109C271; Thu, 25 Mar 2010 10:03:48 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o2PEGrp03342; Thu, 25 Mar 2010 10:16:53 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 25 Mar 2010 10:16:53 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Adrenalin In-Reply-To: Message-ID: References: <1242075474.72992.118.camel@hood.oook.cz> <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> <20090616073353.GZ33280@droso.net> <200906160812.04284.jhb@freebsd.org> <4A3E234F.6050403@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: hang in rpccon from interrupting NFS operations (Re: pointyhat panic) 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, 25 Mar 2010 14:03:53 -0000 On Mon, 22 Mar 2010, Adrenalin wrote: > That's strange, after recompiling the lastest 8_0 that contain the patch ( > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/rpc/clnt_vc.c.diff?r1=1.8.2.2.2.1;r2=1.8.2.2.2.2) > after 5 days it stuck again with same symptoms, I've also got some in the > nfs state: > > FreeBSD .. 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Mar 16 22:56:51 EET > 2010 ..@..:/usr/obj/usr/src/sys/MYGEN amd64 > > When attaching the debugger for an rpccon process, It stuck in here > #0 0x000000080124051c in stat () from /lib/libc.so.7 > > http://img705.imageshack.us/img705/741/10032219218.png > > Can I do the online debug of the kernel, or how can I can help you to solve > the problem ? > Well, sleeping in "rpccon" means that the TCP connect has failed after a soconnect() call. If you can get into a kernel debugger, there is a global structure with more error information in it. It is called: rpc_createerr - and it has 2 enums, followed by an int. The first enum should be 12 (RPC_SYSTEMERR), which is what gets it to tsleep(.."rpccon"..), the second enum doesn't apply to this case and the int after them should be the errno of the soconnect() failure. (The way the code is currently written, it could either be an error return from soconnect() or a value set in so_error after soconnect() returns, while it is in the process of connecting. So, if you can get to that 3rd field, the value there might help tell why the TCP connect is failing. Otherwise, all I can suggest is poking around and trying to figure out why TCP connects are failing. - wedged network interface - routing problem - network infrastructure problem ... (Btw, I was driven a little batty at UofG because the campus network switch I was on would decide to inject TCP RSTs into new connection attempts for some reason. I finally was able to determine this by looking at packet traces on both client and server and see the RSTs coming out of the network on the client end, but never sent on the server end. It was some Cisco related parameter/issue that was never resolved.) Hopefully others with more TCP expertise can make suggestions w.r.t. why the TCP connects are failing? Good luck with it, rick From owner-freebsd-current@FreeBSD.ORG Thu Mar 25 14:03: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 CC38F106564A; Thu, 25 Mar 2010 14:03:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 61A8C8FC28; Thu, 25 Mar 2010 14:03:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC8Kq0uDaFvK/2dsb2JhbACbJXO/GYR9BA X-IronPort-AV: E=Sophos;i="4.51,307,1267419600"; d="scan'208";a="70280373" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 25 Mar 2010 10:03:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 3C765109C2C8; Thu, 25 Mar 2010 10:03:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTuzWAPzgG6J; Thu, 25 Mar 2010 10:03:48 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 89F0A109C271; Thu, 25 Mar 2010 10:03:48 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o2PEGrp03342; Thu, 25 Mar 2010 10:16:53 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 25 Mar 2010 10:16:53 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Adrenalin In-Reply-To: Message-ID: References: <1242075474.72992.118.camel@hood.oook.cz> <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> <20090616073353.GZ33280@droso.net> <200906160812.04284.jhb@freebsd.org> <4A3E234F.6050403@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: hang in rpccon from interrupting NFS operations (Re: pointyhat panic) 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, 25 Mar 2010 14:03:53 -0000 On Mon, 22 Mar 2010, Adrenalin wrote: > That's strange, after recompiling the lastest 8_0 that contain the patch ( > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/rpc/clnt_vc.c.diff?r1=1.8.2.2.2.1;r2=1.8.2.2.2.2) > after 5 days it stuck again with same symptoms, I've also got some in the > nfs state: > > FreeBSD .. 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Mar 16 22:56:51 EET > 2010 ..@..:/usr/obj/usr/src/sys/MYGEN amd64 > > When attaching the debugger for an rpccon process, It stuck in here > #0 0x000000080124051c in stat () from /lib/libc.so.7 > > http://img705.imageshack.us/img705/741/10032219218.png > > Can I do the online debug of the kernel, or how can I can help you to solve > the problem ? > Well, sleeping in "rpccon" means that the TCP connect has failed after a soconnect() call. If you can get into a kernel debugger, there is a global structure with more error information in it. It is called: rpc_createerr - and it has 2 enums, followed by an int. The first enum should be 12 (RPC_SYSTEMERR), which is what gets it to tsleep(.."rpccon"..), the second enum doesn't apply to this case and the int after them should be the errno of the soconnect() failure. (The way the code is currently written, it could either be an error return from soconnect() or a value set in so_error after soconnect() returns, while it is in the process of connecting. So, if you can get to that 3rd field, the value there might help tell why the TCP connect is failing. Otherwise, all I can suggest is poking around and trying to figure out why TCP connects are failing. - wedged network interface - routing problem - network infrastructure problem ... (Btw, I was driven a little batty at UofG because the campus network switch I was on would decide to inject TCP RSTs into new connection attempts for some reason. I finally was able to determine this by looking at packet traces on both client and server and see the RSTs coming out of the network on the client end, but never sent on the server end. It was some Cisco related parameter/issue that was never resolved.) Hopefully others with more TCP expertise can make suggestions w.r.t. why the TCP connects are failing? Good luck with it, rick From owner-freebsd-current@FreeBSD.ORG Fri Mar 26 00:13:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BEB11065670; Fri, 26 Mar 2010 00:13:13 +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 E6B0C8FC14; Fri, 26 Mar 2010 00:13:12 +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 o2Q0DCSH018439; Thu, 25 Mar 2010 20:13:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2Q0DC6B018404; Fri, 26 Mar 2010 00:13:12 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 26 Mar 2010 00:13:12 GMT Message-Id: <201003260013.o2Q0DC6B018404@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 00:13:13 -0000 TB --- 2010-03-25 22:39:05 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-25 22:39:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-03-25 22:39:05 - cleaning the object tree TB --- 2010-03-25 22:39:22 - cvsupping the source tree TB --- 2010-03-25 22:39:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-03-25 22:39:51 - building world TB --- 2010-03-25 22:39:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-25 22:39:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-25 22:39:51 - TARGET=ia64 TB --- 2010-03-25 22:39:51 - TARGET_ARCH=ia64 TB --- 2010-03-25 22:39:51 - TZ=UTC TB --- 2010-03-25 22:39:51 - __MAKE_CONF=/dev/null TB --- 2010-03-25 22:39:51 - cd /src TB --- 2010-03-25 22:39:51 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 25 22:39:51 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 Mar 25 23:56:37 UTC 2010 TB --- 2010-03-25 23:56:37 - generating LINT kernel config TB --- 2010-03-25 23:56:37 - cd /src/sys/ia64/conf TB --- 2010-03-25 23:56:37 - /usr/bin/make -B LINT TB --- 2010-03-25 23:56:37 - building LINT kernel TB --- 2010-03-25 23:56:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-25 23:56:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-25 23:56:37 - TARGET=ia64 TB --- 2010-03-25 23:56:37 - TARGET_ARCH=ia64 TB --- 2010-03-25 23:56:37 - TZ=UTC TB --- 2010-03-25 23:56:37 - __MAKE_CONF=/dev/null TB --- 2010-03-25 23:56:37 - cd /src TB --- 2010-03-25 23:56:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 25 23:56:37 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/interrupt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/iodev_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/machdep.c /src/sys/ia64/ia64/machdep.c: In function 'exec_setregs': /src/sys/ia64/ia64/machdep.c:1384: error: 'ps_strings' undeclared (first use in this function) /src/sys/ia64/ia64/machdep.c:1384: error: (Each undeclared identifier is reported only once /src/sys/ia64/ia64/machdep.c:1384: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-26 00:13:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-26 00:13:11 - ERROR: failed to build lint kernel TB --- 2010-03-26 00:13:11 - 4533.33 user 629.84 system 5646.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 26 08:45: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 32310106564A for ; Fri, 26 Mar 2010 08:45:03 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id C4ED38FC14 for ; Fri, 26 Mar 2010 08:45:02 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2C1F3.dip.t-dialin.net [217.226.193.243]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 3D114844054; Fri, 26 Mar 2010 09:44:57 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 0F602510E; Fri, 26 Mar 2010 09:44:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1269593094; bh=Wes7DsIGo+c2u02N/HD80uGPkRvL8tPCr95Nq2V3oA0=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=xajhgrFJa3l6x71DfPm4yMXOPWc8PalEBPNZ3uEVLz8aA/HW7Mj84Ql4CUimpuf9I FkGfPoyDD1ruVfBsmz0BtwcExsFrtN3j5P/e1qSrBzvGTPmpRvUZMpBhqsLK8DiS7g CBRPm4q0m1JBUQ4MJ0aT58+H1t4JgQF9OhnUUwdBAbcvwLh7hxVp3Lx/azUrzH+nQA HTuYaerkB1gfkz3UuJKUMAuN+pi79nSkqmNNI2hUkuXc9DRh8lK0qdxMoDJRUKIOWZ Ru8vDJew18SyKrOV5p96ovAYb0+rhwPWzli2yNLoVx7jaIBCw0cX657GrihthYOnhL jxk7eg1Z+hdAw== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o2Q8ir8I094220; Fri, 26 Mar 2010 09:44:53 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 26 Mar 2010 09:44:53 +0100 Message-ID: <20100326094453.137454bh9bbbbkkc@webmail.leidinger.net> Date: Fri, 26 Mar 2010 09:44:53 +0100 From: Alexander Leidinger To: Hans Petter Selasky References: <201002180914.20287.hselasky@c2i.net> In-Reply-To: <201002180914.20287.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 3D114844054.49579 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1270197898.78708@mw94ML4DsQ9n+rP2mi5IIw X-EBL-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: FYI: v4l-linuxulator support in FreeBSD-current now [panic] 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, 26 Mar 2010 08:45:03 -0000 Quoting Hans Petter Selasky (from Thu, 18 Feb 2010 09:14:20 +0100): > On Tuesday 12 January 2010 18:49:48 Hans Petter Selasky wrote: > I tried to fix something, but it was apparently not enough. I committed something similar. Bye, Alexander. -- Corrupt, adj.: In politics, holding an office of trust or profit. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Mar 26 11:33:35 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 1C4FA1065701 for ; Fri, 26 Mar 2010 11:33:35 +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 EC0128FC19 for ; Fri, 26 Mar 2010 11:33:34 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 797F246B64; Fri, 26 Mar 2010 07:33:34 -0400 (EDT) Date: Fri, 26 Mar 2010 11:33:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: d@delphij.net In-Reply-To: <4BA7E0B8.3080406@delphij.net> Message-ID: References: <4BA7E0B8.3080406@delphij.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.ORG Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] 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, 26 Mar 2010 11:33:35 -0000 On Mon, 22 Mar 2010, Xin LI wrote: > A MFC of this update is planned, but we will have to make some rather > aggressive changes against the library and more testing. > > Please make sure that you have at least libxml2-2.7.6_2 in your ports tree > before even thinking about updating your ports tree. Older libxml2 uses > some knowledge of zlib internals that has been changed in this update which > is known to cause problem. While the update sounds like a good idea (as does moving to symbol verisoning for this library), I'm not yet convinced an MFC is a good idea given the compatibility issues you describe. Perhaps you could clarify a bit the failure mode: this affects only people who rebuild their ports using exactly the same ports versions, but after having done an upgrade that includes this update? It sounds like existing binaries will continue to work since they will reference the old library version? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Mar 26 17:24: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 7DD921065673 for ; Fri, 26 Mar 2010 17:24:46 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay2.uni-muenster.de (ZIVM-RELAY2.UNI-MUENSTER.DE [128.176.192.13]) by mx1.freebsd.org (Postfix) with ESMTP id 140278FC1B for ; Fri, 26 Mar 2010 17:24:44 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,315,1267398000"; d="scan'208";a="240163776" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 26 Mar 2010 18:24:43 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 1D2841B0750; Fri, 26 Mar 2010 18:24:43 +0100 (CET) Date: Fri, 26 Mar 2010 18:24:42 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: atheros card with lots of Ierrs in `netstat -i` 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, 26 Mar 2010 17:24:46 -0000 hi there, `netstat -i` reports: Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll ath0 2290 00:0f:b5:82:07:c8 6046435 691159 0 654080 0 0 lo0 16384 1280796 0 0 1280796 0 0 lo0 16384 your-net localhost.otaku 1280796 - - 1280796 - - wlan0 1500 00:0f:b5:82:07:c8 821650 0 0 635461 20 0 wlan0 1500 192.168.1.0 localhost.otaku 821223 - - 635140 - - are the Ierrs for ath0 normal or is this something to worry about? i'm running HEAD (r205561) on amd64. this is my card: ath0@pci0:5:1:0: class=0x020000 card=0x5a001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR2312)' class = network subclass = ethernet -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Fri Mar 26 17:52:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15DFC106566B for ; Fri, 26 Mar 2010 17:52:16 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE8688FC0C for ; Fri, 26 Mar 2010 17:52:15 +0000 (UTC) Received: by pvc7 with SMTP id 7so3691589pvc.13 for ; Fri, 26 Mar 2010 10:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type :content-transfer-encoding; bh=P3arIoi4+YENy0Pf6I95iulugz2XEvkOxjeYBbNaxg8=; b=q/eBgwQJfrVJGdy2ddApkkFqxDuA8hU+0M8FN1nWJjNM59LlrAyc3yJH/jWsSFetjY YyoG9xO1YapQ/1QnbiuA4Y5/Snilmwo6CVK9Fo5c3X4WvXAAey99UM5E9XQcIj40qh74 keo5sxgXXcT+nBjVtYWffCvGJMP1JzuzSU6d8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=itfl5lvPf+JGMWsoWvtbWPjRzJXuVf54Y1yd4eNhkRTcppKzeKcaSWP01W4sC+fyQd 5eRM35SdtfuRrAkaP1W3dFz4QlwPIUXUn4CRWy5DbbnVNzsGpWptLe/7NDYTnbmY9qPl yLUMeePx1PLQytELR9j09NitjqNZcL8WCHdRk= MIME-Version: 1.0 Received: by 10.150.139.3 with HTTP; Fri, 26 Mar 2010 10:52:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Mar 2010 12:52:05 -0500 Received: by 10.114.87.17 with SMTP id k17mr1664619wab.215.1269625925159; Fri, 26 Mar 2010 10:52:05 -0700 (PDT) Message-ID: <58c737d71003261052i77873d8cuf3eda9e4130c7a4a@mail.gmail.com> From: Chris Ruiz To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: atheros card with lots of Ierrs in `netstat -i` 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, 26 Mar 2010 17:52:16 -0000 On Fri, Mar 26, 2010 at 12:24 PM, Alexander Best wrote: > hi there, > > `netstat -i` reports: > > Name =A0 =A0Mtu Network =A0 =A0 =A0 Address =A0 =A0 =A0 =A0 =A0 =A0 =A0Ip= kts Ierrs Idrop =A0 =A0Opkts > Oerrs =A0Coll > ath0 =A0 2290 =A0 =A0 =A000:0f:b5:82:07:c8 =A06046435 691159 =A0= =A0 0 =A0 654080 > 0 =A0 =A0 0 > lo0 =A0 16384 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 12= 80796 =A0 =A0 0 =A0 =A0 0 =A01280796 > 0 =A0 =A0 0 > lo0 =A0 16384 your-net =A0 =A0 =A0localhost.otaku =A0 =A01280796 =A0 =A0 = - =A0 =A0 - =A01280796 > - =A0 =A0 - > wlan0 =A01500 =A0 =A0 =A000:0f:b5:82:07:c8 =A0 821650 =A0 =A0 0 = =A0 =A0 0 =A0 635461 > 20 =A0 =A0 0 > wlan0 =A01500 192.168.1.0 =A0 localhost.otaku =A0 =A0 821223 =A0 =A0 - = =A0 =A0 - =A0 635140 > - =A0 =A0 - ath0 2290 00:0f:b5:4f:9a:94 11057975 2376009 0 219466 0 0 > are the Ierrs for ath0 normal or is this something to worry about? i'm ru= nning > HEAD (r205561) on amd64. this is my card: > > ath0@pci0:5:1:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x5a001385 chip= =3D0x0013168c > rev=3D0x01 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Atheros Communications Inc.' > =A0 =A0device =A0 =A0 =3D '802.11a/b/g Wireless Adapter (AR2312)' > =A0 =A0class =A0 =A0 =A0=3D network > =A0 =A0subclass =A0 =3D ethernet ath0@pci0:6:0:0: class=3D0x020000 card=3D0x5a001385 chip=3D0x0013168= c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D '802.11a/b/g Wireless Adapter (AR5212)' class =3D network subclass =3D ethernet I've noticed that Ierrs never stay at 0 on ath0 for a while now and I haven't had any noticeable problems with my network. I run my card in hostap mode on r204812. -- Chris ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From owner-freebsd-current@FreeBSD.ORG Fri Mar 26 18:34: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 DF3911065674 for ; Fri, 26 Mar 2010 18:34:42 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-pz0-f199.google.com (mail-pz0-f199.google.com [209.85.222.199]) by mx1.freebsd.org (Postfix) with ESMTP id ADD8F8FC0C for ; Fri, 26 Mar 2010 18:34:42 +0000 (UTC) Received: by pzk37 with SMTP id 37so3037660pzk.7 for ; Fri, 26 Mar 2010 11:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=vBW+HzQIPwLveYga3MkT7eJQYhb1a6x2sp9XaEX8xRw=; b=piaGUzQAm19djcmu11jwZhletUsSI1QkFv4P+RFH+Op93mi7XqPR1hbkBqgL39II91 TW6a4TDLEtdsrjQt/gsivyciGS/9yQ7eTf2HpWD8BgJ1cpPwjBB0f5C1/YNVoWW4oinv qvBrUINtIf//dsfBWJv724QGEdEJ7+n1sm8mY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=GsYgapUmlmgVLkEVVk32Du6Q0m+TOlsbM0j00+jALuVNQP+Nk+deHtyoq77QU0Il2x PQ0MN4VkRjHyZja/O8On97IWmi8zddQp48v7EG3LvlVNSTxmbrVJBHUlMiwmiDye3kcI NPep5ip0uzsf8gEfiLpYCMLAo7t+LCuUM/sCM= Received: by 10.141.90.10 with SMTP id s10mr886187rvl.287.1269628482174; Fri, 26 Mar 2010 11:34:42 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id p1sm533722rvq.22.2010.03.26.11.34.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Mar 2010 11:34:39 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Fri, 26 Mar 2010 18:34:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alexander Best X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@FreeBSD.org Subject: Re: atheros card with lots of Ierrs in `netstat -i` 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, 26 Mar 2010 18:34:43 -0000 On 26 Mar 2010, at 17:24, Alexander Best wrote: > hi there, >=20 > `netstat -i` reports: >=20 > Name Mtu Network Address Ipkts Ierrs Idrop = Opkts > Oerrs Coll > ath0 2290 00:0f:b5:82:07:c8 6046435 691159 0 = 654080 > 0 0 > lo0 16384 1280796 0 0 = 1280796 > 0 0 > lo0 16384 your-net localhost.otaku 1280796 - - = 1280796 > - - > wlan0 1500 00:0f:b5:82:07:c8 821650 0 0 = 635461 > 20 0 > wlan0 1500 192.168.1.0 localhost.otaku 821223 - - = 635140 > - - >=20 > are the Ierrs for ath0 normal or is this something to worry about? i'm = running > HEAD (r205561) on amd64. this is my card: >=20 > ath0@pci0:5:1:0: class=3D0x020000 card=3D0x5a001385 = chip=3D0x0013168c > rev=3D0x01 hdr=3D0x00 > vendor =3D 'Atheros Communications Inc.' > device =3D '802.11a/b/g Wireless Adapter (AR2312)' > class =3D network > subclass =3D ethernet You have a 9% error rate, which can be common on some scenarios. If = you're not experiencing connection problems, there's no need to worry. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Mar 26 22:14:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7FA31065670; Fri, 26 Mar 2010 22:14:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C28098FC17; Fri, 26 Mar 2010 22:14:07 +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 o2QME72R001860; Fri, 26 Mar 2010 18:14:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2QME6qC001859; Fri, 26 Mar 2010 22:14:06 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 26 Mar 2010 22:14:06 GMT Message-Id: <201003262214.o2QME6qC001859@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: Fri, 26 Mar 2010 22:14:08 -0000 TB --- 2010-03-26 20:49:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-26 20:49:09 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-03-26 20:49:09 - cleaning the object tree TB --- 2010-03-26 20:49:27 - cvsupping the source tree TB --- 2010-03-26 20:49:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-03-26 20:49:57 - building world TB --- 2010-03-26 20:49:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-26 20:49:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-26 20:49:57 - TARGET=sparc64 TB --- 2010-03-26 20:49:57 - TARGET_ARCH=sparc64 TB --- 2010-03-26 20:49:57 - TZ=UTC TB --- 2010-03-26 20:49:57 - __MAKE_CONF=/dev/null TB --- 2010-03-26 20:49:57 - cd /src TB --- 2010-03-26 20:49:57 - /usr/bin/make -B buildworld >>> World build started on Fri Mar 26 20:49: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 Fri Mar 26 21:46:30 UTC 2010 TB --- 2010-03-26 21:46:30 - generating LINT kernel config TB --- 2010-03-26 21:46:30 - cd /src/sys/sparc64/conf TB --- 2010-03-26 21:46:30 - /usr/bin/make -B LINT TB --- 2010-03-26 21:46:30 - building LINT kernel TB --- 2010-03-26 21:46:30 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-26 21:46:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-26 21:46:30 - TARGET=sparc64 TB --- 2010-03-26 21:46:30 - TARGET_ARCH=sparc64 TB --- 2010-03-26 21:46:30 - TZ=UTC TB --- 2010-03-26 21:46:30 - __MAKE_CONF=/dev/null TB --- 2010-03-26 21:46:30 - cd /src TB --- 2010-03-26 21:46:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Mar 26 21:46:30 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Mar 26 22:06:42 UTC 2010 TB --- 2010-03-26 22:06:42 - building GENERIC kernel TB --- 2010-03-26 22:06:42 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-26 22:06:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-26 22:06:42 - TARGET=sparc64 TB --- 2010-03-26 22:06:42 - TARGET_ARCH=sparc64 TB --- 2010-03-26 22:06:42 - TZ=UTC TB --- 2010-03-26 22:06:42 - __MAKE_CONF=/dev/null TB --- 2010-03-26 22:06:42 - cd /src TB --- 2010-03-26 22:06:42 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Mar 26 22:06:43 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 [...] objcopy --strip-debug --add-gnu-debuglink=firmware.ko.symbols firmware.ko.debug firmware.ko ===> fxp (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/sparc64/src/sys/GENERIC -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/fxp/../../dev/fxp/if_fxp.c /src/sys/modules/fxp/../../dev/fxp/if_fxp.c: In function 'fxp_start_body': /src/sys/modules/fxp/../../dev/fxp/if_fxp.c:1321: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/sys/modules/fxp. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-26 22:14:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-26 22:14:06 - ERROR: failed to build GENERIC kernel TB --- 2010-03-26 22:14:06 - 4030.82 user 694.20 system 5097.63 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 09:12:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B9A0106564A for ; Sat, 27 Mar 2010 09:12:23 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51802.mail.re2.yahoo.com (web51802.mail.re2.yahoo.com [206.190.38.233]) by mx1.freebsd.org (Postfix) with SMTP id B59488FC08 for ; Sat, 27 Mar 2010 09:12:22 +0000 (UTC) Received: (qmail 90928 invoked by uid 60001); 27 Mar 2010 09:12:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1269681142; bh=e1IYe7hkInvDb6gbAzyRtsRMWsuxWlOXxqe7/wXfrvM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Vox2OZPdgn4eFBIFqpYpoWURQHZsaEwpZsrX1UQEF64b561XE9DfJv4JqA6YF8GdqxwDs29vptIO/4wsnq/GXjAhsVf8WQxaQpMB3W30JgE0bOdHH3exgft/lPauXcaZIJLuxQ8F//V2NFRE13AaE6sEg5EywWM/cI2tlNOCAdA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xk0y0O6ybmOKv7Dya5nRBSGqz26zM/w4sgRrXKpWcfpvPN7LdclDxhpFlRhNHEfHC/ocUJjVAHWnGvDT2ynRAvxrCuNZtxNLvgYwQ1RzELhtIArDfMuwoANxtBhh6V7sgFQr3It/zOarl4iwjeAEHf5nZ51VsPoL8aZ5EmdDHLo=; Message-ID: <989377.89740.qm@web51802.mail.re2.yahoo.com> X-YMail-OSG: 0YWSEIUVM1lvlSyVXHCSPdZ71aoFVe7bHi.3MTT9s0Opt9FW1ri12VLl8OedviHtXLg86YuIZBk.68iCkaHdj_hW89VecBPwj7O0ng0YrZLroIdti8Lgbt8F1pZ5JMvtnBSR2eE5heOgCbTRAse3h5USTuIpBb_POyfwqNUFggOJFH.WMFosHxWxBp2wk7u2SZNlwDZk7okZ_VpuqvxjGaaH29CdbYLSgqqKVBB_DROcigwrQ5i1tTiFgfF5OTGHxPRflr0ZHcPjFRi2kOjH1Cs4yjrNmAGck5XQ5c9RdfWqYnGiuvSlbkZmyN8xpMX5A2nSbRPQYUQXhbQdhqUEDskt.lArDDrARExdcqabLI9W34K6M.IM6uU- Received: from [173.183.132.20] by web51802.mail.re2.yahoo.com via HTTP; Sat, 27 Mar 2010 02:12:21 PDT X-Mailer: YahooMailRC/324.3 YahooMailWebService/0.8.100.260964 References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> Date: Sat, 27 Mar 2010 02:12:21 -0700 (PDT) From: PseudoCylon To: Ganbold In-Reply-To: <4BA38B26.6050208@micom.mng.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless 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, 27 Mar 2010 09:12:23 -0000 >> Same.=0A=0A>> =0A>> rspro# ifconfig wlan0 up =0A>>=0A>> rspro# Tra= p cause =3D 5 (address error (store) - kernel =0A> mode)=0A>> [ thread pid = 0 tid 100047 ]=0A>> Stopped at =0A> ieee80211_radiotap_vdetach+0x70: = =0A> sh v1,0(a0)=0A>> db> bt=0A>> Tracing pid 0 =0A> tid 100047 = td 0xc0f1f260=0A>> db_trace_thread+30 (?,?,?,?) ra 80071160 sp =0A> c7ec994= 8 sz 24=0A>> 80071044+11c (0,?,ffffffff,?) ra 80070b54 sp c7ec9960 =0A> sz = 32=0A>> 800707c0+394 (?,?,?,?) ra 80070ce4 sp c7ec9980 sz =0A> 168=0A>> db_= command_loop+78 (?,?,?,?) ra 800733b8 sp c7ec9a28 sz =0A> 24=0A>> 800732b0+= 108 (?,?,?,?) ra 801d8b1c sp c7ec9a40 sz 424=0A>> =0A> kdb_trap+10c (?,?,?,= ?) ra 803c2690 sp c7ec9be8 sz 32=0A>> trap+134c =0A> (?,?,?,?) ra 803b97c8 = sp c7ec9c08 sz 176=0A>> MipsKernGenException+10c =0A> (c0f6a637,c0f721c8,c7= ea7c04,e51) ra 802c95b8 sp=0A>> c7ec9cb8 sz =0A> 200=0A>> 802c95a8+10 (?,?,= ?,?) ra 0 sp c7ec9d80 sz 0=0A>> pid =0A> 0=0A>> db>=0A>> =0A>> Ganbold= =0A>>=0A=0AHi,=0A=0ACan you try this patch? (Patch is for if_run.c)=0A=0ABe= fore "ifconfig wlan0 up", please run=0Asysctl hw.usb.run.debug=3D1=0AThis w= ill give me more clues.=0A=0ADoes it panic right after wlan up, or are ther= e some seconds before panic?=0A=0ARegards,=0AAK=0A=0A-- begin patch --=0A= =0A*** old_if_run.c 2010-03-27 02:44:20.000000000 -0600=0A--- new_if_run= .c 2010-03-27 02:47:28.000000000 -0600=0A***************=0A*** 414,416 *= ***=0A static const struct {=0A! uint32_t reg;=0A uint32_t = val;=0A--- 414,416 ----=0A static const struct {=0A! uint16_t reg;= =0A uint32_t val;=0A***************=0A*** 1225,1227 ****=0A =0A! = *val =3D tmp & 0xff;=0A return 0;=0A--- 1225,1227 ----=0A =0A! = *val =3D (uint8_t)(tmp & 0xff);=0A return 0;=0A=0A=0A __________= ________________________________________________________=0AThe new Internet= Explorer=AE 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now f= or Free! at http://downloads.yahoo.com/ca/internetexplorer/ From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 10:58:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 794A6106564A for ; Sat, 27 Mar 2010 10:58:41 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4766E8FC0C for ; Sat, 27 Mar 2010 10:58:41 +0000 (UTC) Received: by pvc7 with SMTP id 7so4039085pvc.13 for ; Sat, 27 Mar 2010 03:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=BbicUT+3Qy6e8cdQYaFrEotjo/h3eIKjOAMqnVMNZ8c=; b=TNGpbwMtxT/lRbYzGsMzBIlpjeYsujuwey8IqhTyMcwfGHMNdoI/VHnHGFAXced8zT yQJRM4ig8Myn78PKiL+GXuKjeQKOMnOLXIQ+Wy22QnWtez2ekSNcEt4H+v3TclBnEog8 5DXjdAVQ5OtL1t6mFlgYl3nowljqDXkrexL9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.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=Sklytia1IS+qXp5EaefZyiQaugC8/i/tJ1bn+/9sOrc0ssFSD10AALn19A6NFsg6Av 60ppv1VsJ4vdyynyaPqRp/Z3QjjpgjR5ap/WgCybGb+VzJ0yjGmkuPXacuDvymDfpS8l tbKnKSgYI3rTGF9yiq1w61tg8egesOd4P+GOg= Received: by 10.115.66.33 with SMTP id t33mr678577wak.199.1269685990206; Sat, 27 Mar 2010 03:33:10 -0700 (PDT) Received: from beastie.micom.mng.net ([202.179.21.133]) by mx.google.com with ESMTPS id 22sm1636507pzk.5.2010.03.27.03.33.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Mar 2010 03:33:09 -0700 (PDT) Message-ID: <4BADDECF.1080802@gmail.com> Date: Sat, 27 Mar 2010 18:32:47 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.23 (X11/20091011) MIME-Version: 1.0 To: PseudoCylon References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> In-Reply-To: <989377.89740.qm@web51802.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless 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, 27 Mar 2010 10:58:41 -0000 PseudoCylon wrote: >>> Same. >>> > Hi, > > Can you try this patch? (Patch is for if_run.c) > > Before "ifconfig wlan0 up", please run > sysctl hw.usb.run.debug=1 > This will give me more clues. > > Does it panic right after wlan up, or are there some seconds before panic? > Same, it panics right after issuing wlan up. I used this patch and also if_runvar.h patch also. ... run0: flags=8802 metric 0 mtu 2290 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier wlan0: flags=8802 metric 0 mtu 1500 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid bsd channel 1 (2412 MHz 11b) country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 wme bintval 0 rspro# ifconfig wlan0 up run_stop: All Tx cleared run_newstate: INIT -> SCAN rspro# Trap cause = 5 (address error (store) - kernel mode) [ thread pid 0 tid 100047 ] Stopped at ieee80211_radiotap_vdetach+0x70: sh v1,0(a0) db> Ganbold > Regards, > AK > > -- begin patch -- > > *** old_if_run.c 2010-03-27 02:44:20.000000000 -0600 > --- new_if_run.c 2010-03-27 02:47:28.000000000 -0600 > *************** > *** 414,416 **** > static const struct { > ! uint32_t reg; > uint32_t val; > --- 414,416 ---- > static const struct { > ! uint16_t reg; > uint32_t val; > *************** > *** 1225,1227 **** > > ! *val = tmp & 0xff; > return 0; > --- 1225,1227 ---- > > ! *val = (uint8_t)(tmp & 0xff); > return 0; > > > __________________________________________________________________ > The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ > _______________________________________________ > 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" > > -- The worst cliques are those which consist of one man. -- George Bernard Shaw From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 12:20: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 E5365106566C for ; Sat, 27 Mar 2010 12:20:19 +0000 (UTC) (envelope-from bofh@redwerk.com) Received: from redwerk.com (redwerk.com [89.105.196.9]) by mx1.freebsd.org (Postfix) with ESMTP id A72A78FC0C for ; Sat, 27 Mar 2010 12:20:19 +0000 (UTC) Received: from [192.168.250.5] (helo=office.redwerk.com) by redwerk.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1NvUzx-0003p7-2k for freebsd-current@freebsd.org; Sat, 27 Mar 2010 13:20:17 +0100 Received: from bofh by office.redwerk.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvUzw-0008Bo-0P for freebsd-current@freebsd.org; Sat, 27 Mar 2010 14:20:16 +0200 Date: Sat, 27 Mar 2010 14:20:15 +0200 From: Eugene Dzhurinsky To: freebsd-current@freebsd.org Message-ID: <20100327122015.GA31437@office.redwerk.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20100324202639.GA3194@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20100324202639.GA3194@localhost> Subject: Re: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue -> wpa_supplicant hangs 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, 27 Mar 2010 12:20:20 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 24, 2010 at 10:26:39PM +0200, Eugeny N Dzhurinsky wrote: > Hi! >=20 > I am facing very strange issue - for some reason wpa_supplicant hands aft= er > associating connection with AP. It doesn't hang immediately - but after s= ome > time (amout a minute or so). I realized that it fails after group rekeying completes. If is set rekeying= to occur in 30 minutes on AP host - for 30 minutes I am not getting any issue. With my DLink WiFi USB stick powered by if_rum driver such problem does not appear. If I should provide some additional information to help someone understand = and fix this issue - please let me know :) P.S. Many thanks to Rui Paulo for porting AR9285 driver! --=20 Eugene N Dzhurinsky --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkut9/wACgkQy/i/DoZLbHwfHwCfUZ7XwXVxSzCv6pfrJLZCyY5m bFoAoLNsUsaeH50NoHlPi3AkOCAd/Egb =6n43 -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 13:01: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 7DDA7106566B for ; Sat, 27 Mar 2010 13:01:52 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-yx0-f175.google.com (mail-yx0-f175.google.com [209.85.210.175]) by mx1.freebsd.org (Postfix) with ESMTP id 31BA48FC08 for ; Sat, 27 Mar 2010 13:01:51 +0000 (UTC) Received: by yxe5 with SMTP id 5so301242yxe.3 for ; Sat, 27 Mar 2010 06:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=l5yAKAizzLXq7RDZR5/l3N/KWbJMoHCvjCbC59DId8c=; b=OaWDDHplLiifF7QvbTwYvpg/F9UWMgtaMAeE3a0EKGrj4bCqWXeUkjRukR0EZYXTHM v0D/kgRuO+7Hi54won+bX9aG/zGkJLQoRMVKHqCrYQ+7StK4AOr92jUJFJMUrfDY8euO DJsrTIgIUGk2R1CrtBwBiPxiDMlZ7XLdcPCpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.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=ZuU0fJ/x5R13ow+Z0HRTrd3guwOUkAiFPBf+8XW8V22QgAWs5SAvsY9QMBdetvvgJq Cj4tqdXghxYuElPNLKkOgu4UZpaIbtXhm4raIUT6iuEhLJjd8i4O6MJC36Hf07DeUbcU seOpAq0jqteoTCY7Hqb0cNiPf9AuTFwkWDIFo= Received: by 10.101.214.4 with SMTP id r4mr4284943anq.141.1269694911249; Sat, 27 Mar 2010 06:01:51 -0700 (PDT) Received: from beastie.micom.mng.net ([202.179.21.133]) by mx.google.com with ESMTPS id 22sm1800470iwn.8.2010.03.27.06.01.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Mar 2010 06:01:50 -0700 (PDT) Message-ID: <4BAE01AC.7000509@gmail.com> Date: Sat, 27 Mar 2010 21:01:32 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.23 (X11/20091011) MIME-Version: 1.0 To: PseudoCylon References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> In-Reply-To: <989377.89740.qm@web51802.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless 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, 27 Mar 2010 13:01:52 -0000 PseudoCylon wrote: >>> Same. >>> > > JFYI, I have just tested if_run and works fine on HEAD (i386). But on RouterStation Pro it still has problem with your patch. Ganbold >>> >>> rspro# ifconfig wlan0 up >>> >>> rspro# Trap cause = 5 (address error (store) - kernel >>> >> mode) >> >>> [ thread pid 0 tid 100047 ] >>> Stopped at >>> >> ieee80211_radiotap_vdetach+0x70: >> sh v1,0(a0) >> >>> db> bt >>> Tracing pid 0 >>> >> tid 100047 td 0xc0f1f260 >> >>> db_trace_thread+30 (?,?,?,?) ra 80071160 sp >>> >> c7ec9948 sz 24 >> >>> 80071044+11c (0,?,ffffffff,?) ra 80070b54 sp c7ec9960 >>> >> sz 32 >> >>> 800707c0+394 (?,?,?,?) ra 80070ce4 sp c7ec9980 sz >>> >> 168 >> >>> db_command_loop+78 (?,?,?,?) ra 800733b8 sp c7ec9a28 sz >>> >> 24 >> >>> 800732b0+108 (?,?,?,?) ra 801d8b1c sp c7ec9a40 sz 424 >>> >>> >> kdb_trap+10c (?,?,?,?) ra 803c2690 sp c7ec9be8 sz 32 >> >>> trap+134c >>> >> (?,?,?,?) ra 803b97c8 sp c7ec9c08 sz 176 >> >>> MipsKernGenException+10c >>> >> (c0f6a637,c0f721c8,c7ea7c04,e51) ra 802c95b8 sp >> >>> c7ec9cb8 sz >>> >> 200 >> >>> 802c95a8+10 (?,?,?,?) ra 0 sp c7ec9d80 sz 0 >>> pid >>> >> 0 >> >>> db> >>> >>> Ganbold >>> >>> > > Hi, > > Can you try this patch? (Patch is for if_run.c) > > Before "ifconfig wlan0 up", please run > sysctl hw.usb.run.debug=1 > This will give me more clues. > > Does it panic right after wlan up, or are there some seconds before panic? > > Regards, > AK > > -- begin patch -- > > *** old_if_run.c 2010-03-27 02:44:20.000000000 -0600 > --- new_if_run.c 2010-03-27 02:47:28.000000000 -0600 > *************** > *** 414,416 **** > static const struct { > ! uint32_t reg; > uint32_t val; > --- 414,416 ---- > static const struct { > ! uint16_t reg; > uint32_t val; > *************** > *** 1225,1227 **** > > ! *val = tmp & 0xff; > return 0; > --- 1225,1227 ---- > > ! *val = (uint8_t)(tmp & 0xff); > return 0; > > > __________________________________________________________________ > The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ > _______________________________________________ > 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" > > -- The Bible is not my Book and Christianity is not my religion. I could never give assent to the long complicated statements of Christian dogma. -- Abraham Lincoln From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 13:36:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1302F106566B for ; Sat, 27 Mar 2010 13:36:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BB9EE8FC18 for ; Sat, 27 Mar 2010 13:36:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABenrUuDaFvH/2dsb2JhbACbM3O+JIUBBA X-IronPort-AV: E=Sophos;i="4.51,319,1267419600"; d="scan'208";a="70171350" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 27 Mar 2010 09:36:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id E96751084483; Sat, 27 Mar 2010 09:36:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0ExLLTdFuWB; Sat, 27 Mar 2010 09:36:15 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 8A0D01084444; Sat, 27 Mar 2010 09:36:15 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o2RDnND14320; Sat, 27 Mar 2010 09:49:23 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sat, 27 Mar 2010 09:49:23 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Petr Lampa In-Reply-To: <20100326162406.GA43912@fit.vutbr.cz> Message-ID: References: <20100326162406.GA43912@fit.vutbr.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Possible error in nfs_nfsdserv.c? 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, 27 Mar 2010 13:36:18 -0000 On Fri, 26 Mar 2010, Petr Lampa wrote: > > I've got several "panic: nfsrelpath", see attached photo. I've found > one place where it could probably happen, please, can you look at this? > > First name buffer is initialized in nfsrvd_link() with: > NFSNAMEICNDSET(&named.ni_cnd, nd->nd_cred, CREATE, LOCKPARENT); > > Then: > nd->nd_repstat = nfsvno_namei(nd, &named, dp, 0, &tnes, > p, &dirp); > > and > nd->nd_repstat = nfsvno_link(&named, vp, nd->nd_cred, p, exp); > > is called. The nfsvno_link() calls nfsvno_relpathbuf() unconditionally, > this is the place where the panic happened. The only place where buffer can > be released in no error case is in the nfsvno_namei(). There is a call > > if ((cnp->cn_flags & (SAVENAME | SAVESTART)) == 0) > nfsvno_relpathbuf(ndp); > > there and no SAVENAME|SAVESTART is set in NFSNAMEICNDSET(). But if > buffer is alwyas released at this place, then link would be panicing also > always (and it isn't). So probably I'm missing something here. Other For ufs, ufs_lookup() sets SAVENAME for the CREATE case, which is why I don't see such a panic. I had thought that all file systems would do this for VOP_LOOKUP() for CREATE. It sounds like you've found a case where that isn't happening. Could you please tell us what file system type is being accessed when this panic occurs? I've cc'd freebsd-current, so that anyone conversant with the FreeBSD VFS can jump in here. Am I right to assume that VOP_LOOKUP() for CREATE will set SAVENAME when returning error == 0? > functions where nfsvno_namei() is called without SAVENAME|SAVESTART flags > also don't call nfsvno_relpathbuf(). Perhaps buffer should be initialized > with > > NFSNAMEICNDSET(&named.ni_cnd, nd->nd_cred, CREATE, LOCKPARENT | SAVENAME); > Yes, please try this. I think it will fix the problem, since my server code assumes that VOP_LOOKUP() will have set SAVENAME for the non-error case. (I don't think setting it is harmful and it will help isolate the problem further.) Please let us know how things go with SAVENAME set, as above. rick From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 15:59:18 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB9C91065673 for ; Sat, 27 Mar 2010 15:59:18 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 757FC8FC1A for ; Sat, 27 Mar 2010 15:59:18 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id A8EDC60E4; Sat, 27 Mar 2010 11:59:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1269705556; bh=uKaXjg2IMcIlbbF02LMabBLpNLxzCWWfi2C3HyZxrvE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=m0Gs6QjTKX/R5U+iNjo9ylg2g5Eg0tnsXbSlVE5GeSFjhNWZfmjjLGqaa/5IXBkBr naKTg3XG3pkYOkBIG8xAFDcrxmUtnMy2OWhGEKQIBZtyEZ5Z6JP5VG0exnKnRhb DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=iA3TWfUYyz/NZRL6oMOByqkALSRey0WZQy0w1QuFe4Q9i6hzV9sqnOFcBZTyLZxWx PNiyKdMSs0KdDRdiHBaDcXV5NpR3p5huRWh65m9Z5EhT57stH4oTm9b0SlDvf6p Message-ID: <4BAE2B4F.6060005@protected-networks.net> Date: Sat, 27 Mar 2010 11:59:11 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100303 Thunderbird/3.0.3 MIME-Version: 1.0 To: d@delphij.net References: <4BA7E0B8.3080406@delphij.net> In-Reply-To: <4BA7E0B8.3080406@delphij.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] 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, 27 Mar 2010 15:59:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/22/10 17:27, Xin LI wrote: > Just a heads-up that zlib in base system (libz) has been updated to > 1.2.4. We tried to keep -HEAD as close as possible to the vendor > version, but there is some changes in its internal data structure, and > we did not use versioned symbols in the past, making shared library > version bump unavoidable. This breaks most (if not all) of the QT4-dependent ports for the lack of a definition of "off64_t". Adding .. /* * This is hard-configured for FreeBSD. */ #include #define z_off_t off_t #define off64_t off_t <----- #ifndef _FILE_OFFSET_BITS #define _FILE_OFFSET_BITS 64 #endif .. to /usr/include/zconf.h seems to resolve this breakage, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuuK08ACgkQQv9rrgRC1JLsIwCeKKG6GT60PzaB1loO78R2S9Rr B10An3N/a8h6AZsHGQyoJQ5XBZgpFXP0 =9z9H -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 16:21: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 675F3106564A for ; Sat, 27 Mar 2010 16:21:36 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 26CDC8FC0C for ; Sat, 27 Mar 2010 16:21:35 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 38BB31FFC22; Sat, 27 Mar 2010 16:21:33 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id DC912844DA; Sat, 27 Mar 2010 17:21:31 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Michael Butler References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> Date: Sat, 27 Mar 2010 17:21:31 +0100 In-Reply-To: <4BAE2B4F.6060005@protected-networks.net> (Michael Butler's message of "Sat, 27 Mar 2010 11:59:11 -0400") Message-ID: <86y6hdka5w.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.ORG, d@delphij.net Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] 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, 27 Mar 2010 16:21:36 -0000 Michael Butler writes: > This breaks most (if not all) of the QT4-dependent ports for the lack of > a definition of "off64_t". They should not use off64_t. More importantly, they should not rely on zlib to provide it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 20:18: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 3999E1065672; Sat, 27 Mar 2010 20:18:29 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id E8D7E8FC1E; Sat, 27 Mar 2010 20:18:28 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 72FD91E000E3; Sat, 27 Mar 2010 21:18:27 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o2RK4csN080030; Sat, 27 Mar 2010 21:04:38 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o2RK4cFC080029; Sat, 27 Mar 2010 21:04:38 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Sat, 27 Mar 2010 21:04:38 +0100 To: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <20100327200438.GA79454@triton8.kn-bremen.de> 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: So I tried a Firefox alpha in the Linuxolator... (unix domain socket patches) 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, 27 Mar 2010 20:18:29 -0000 ...hoping that the out of process plugin code would help the java plugin hangs, but I only got flash working, java still is broken. :( (Java does seem to work in linux-opera so it can't be the Linuxolator's fault alone...) I did have to do some patches first tho because Firefox now uses SO_PASSCRED on unix domain SOCK_SEQPACKET sockets, the first patch is here, I've added some notes at the top that I'll quote: http://people.freebsd.org/~nox/linux-so_passcred.patch --------snip------ Looks like this part from dchagin's patch http://lists.freebsd.org/pipermail/freebsd-emulation/2008-September/005273.html didn't get applied, at least alpha versions of Linux Firefox 3.7 needs it http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ because of this code: http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/linux/crash_generation/crash_generation_server.cc#239 That Firefox also needs a small patch to allow setsockopt() with SOCK_SEQPACKET, I've put that here: http://people.freebsd.org/~nox/afunix_seqpacket_sockopt.patch ..and if you aren't running head you also need to merge this commit first: http://svn.freebsd.org/viewvc/base?view=revision&revision=197775 I'v put an 8-stable patch for that here: http://people.freebsd.org/~nox/afunix_seqpacket-8stable.patch (But the java plugin still doesn't work, only flash...) --------snip------ Oh and ff also attempts to use /proc/self/fd which is not yet in stable and the epoll_create syscall which I think isn't even in head yet, but it seems to have fallback code for those so they are not as important. Cheers, Juergen From owner-freebsd-current@FreeBSD.ORG Sat Mar 27 21:12: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 EC6921065678 for ; Sat, 27 Mar 2010 21:12:03 +0000 (UTC) (envelope-from bofh@redwerk.com) Received: from redwerk.com (redwerk.com [89.105.196.9]) by mx1.freebsd.org (Postfix) with ESMTP id 8439F8FC26 for ; Sat, 27 Mar 2010 21:12:03 +0000 (UTC) Received: from [192.168.250.5] (helo=office.redwerk.com) by redwerk.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1NvdIX-0007Wg-AB for freebsd-current@freebsd.org; Sat, 27 Mar 2010 22:12:01 +0100 Received: from bofh by office.redwerk.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvdIW-0009Pd-FD for freebsd-current@freebsd.org; Sat, 27 Mar 2010 23:12:00 +0200 Date: Sat, 27 Mar 2010 23:12:00 +0200 From: Eugene Dzhurinsky To: freebsd-current@freebsd.org Message-ID: <20100327211200.GA36060@office.redwerk.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20100324202639.GA3194@localhost> <20100327122015.GA31437@office.redwerk.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20100327122015.GA31437@office.redwerk.com> Subject: Re: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue -> wpa_supplicant hangs 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, 27 Mar 2010 21:12:04 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 27, 2010 at 02:20:15PM +0200, Eugene Dzhurinsky wrote: > On Wed, Mar 24, 2010 at 10:26:39PM +0200, Eugeny N Dzhurinsky wrote: >=20 > I realized that it fails after group rekeying completes. If is set rekeyi= ng to > occur in 30 minutes on AP host - for 30 minutes I am not getting any issu= e. >=20 > With my DLink WiFi USB stick powered by if_rum driver such problem does n= ot > appear. >=20 > If I should provide some additional information to help someone understan= d and > fix this issue - please let me know :) Finally I was able to find out the case which makes my wifi to stop working. The problem is easily reproducible if second laptop is associated with AP. My AP configuration (PC with FreeBSD 7.2) is listed below: interface=3Dral0 debug=3D2 ctrl_interface=3D/var/run/hostapd ctrl_interface_group=3Dwheel ssid=3Dfreebsdap wpa=3D1 wpa_passphrase=3D************* wpa_key_mgmt=3DWPA-PSK wpa_group_rekey=3D1800 wpa_pairwise=3DCCMP TKIP local wpa_supplicant.conf is like below: ctrl_interface=3D/var/run/wpa_supplicant ctrl_interface_group=3Dwheel fast_reauth=3D0 eapol_version=3D2 network=3D{ ssid=3D"freebsdap" key_mgmt=3DWPA-PSK auth_alg=3DOPEN psk=3D"*************" scan_ssid=3D1 } My primary laptop is ASUS K40IN with wifi card on AR9285 chipset, another laptop is ASUS K40IJ with wifi card on AR9285 chipset too. And once second laptop gets associated with AP - my one stops to recognize wifi connection. But it's still listed as associated in ifconfig output. An= d=20 wpa_cli reassociate doesn't solve the problem - I have to restart wpa_supplicant. Does this make any sense? Should I submit PR or there is some misconfiguration? --=20 Eugene N Dzhurinsky --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuudJwACgkQy/i/DoZLbHz98gCdHoXRomrf7MDWKemvElB827zL V8EAoKWuTJpHS/vlQAikxjBxP35v7uyW =ANn3 -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5--