From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 02:47:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DFD106566B for ; Sun, 16 Mar 2008 02:47:34 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 718CC8FC1A for ; Sun, 16 Mar 2008 02:47:34 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so349656uge.37 for ; Sat, 15 Mar 2008 19:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=uJ2RR6OD0pGhG7E+A0Ueft4xzCtQm0vvV23alBhX7f8=; b=ni1HO5kaZpcKagup/gs6EHEsXhxioD6NFpI12bAeN6ofBVkDMga2IqikSyZH5BeDt9byONAWpkQ28oVORqynSoOyKuY9FrGDLP9V1z9iwfdfz1+JpyOTBi1koiiR8Vj7NJLHHX9xYFeQz5Neawq0C0vLWVxfcSCC5IfMKX90Lm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=cEuxTyz1ch311bRg1e2sHnlyi2PsFlAkgrhdKpRjGPvnAG97vIXai4NIFot+XtpDvK3TAA6vqYF0rUtOy412r7AGvlGn0bbQXbH6da40chfhJr7ZIF93LGIxirGhKRW1/9luPlsr1khJp3Va1gGXWySis7FER0vKG9LGxUQtXtA= Received: by 10.67.119.15 with SMTP id w15mr1629970ugm.73.1205634083449; Sat, 15 Mar 2008 19:21:23 -0700 (PDT) Received: by 10.66.248.11 with HTTP; Sat, 15 Mar 2008 19:21:23 -0700 (PDT) Message-ID: Date: Sun, 16 Mar 2008 02:21:23 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 30c2bc5797d7eed5 Subject: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2008 02:47:34 -0000 Ok, so I've been trying to figure out (on my T43p) why my lapic frequency is being ~3x the difference between Release-7 CD and RELENG_7 cvs... I get, after verbose booting: lapic: Divisor 2, Frequency 66504853 hz with the ISO image; and lapic: Divisor 2, Frequency 188430051 hz consistently +/- small % variation... I'm compiling w/ GENERIC w/o CFLAGS/COPTFLAGS, etc... The response is sluggish as a result of that, and perl fails timing tests... I've run out of things to experiment with; has anything changed in the kernel wrt lapic? If not, HELP! Cheers, Igor :-) From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 05:05:55 2008 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 6E9B21065673 for ; Sun, 16 Mar 2008 05:05:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9D88FC1A for ; Sun, 16 Mar 2008 05:05:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so3129051rvb.43 for ; Sat, 15 Mar 2008 22:05:54 -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:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=iiZ9hvOCZb3lW3dtCufLDpNhHziEgPq+IB+4n4jaLlQ=; b=WvDx3KzUXgifluJgiWNnqMzYkiT0chBGNZMPczHs1HyWIc3tZyxUoBpSF2IKuNByhHXGyWwbc4g63qg9NDdAmI99q5IHvBa6GE4zXajhlyVZDl7IF4MExm87Ddql2c/UCmaNYk3eV6RG4YNKFR1ruOZ40jXZyBPscj61+KXovLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gbvT2lQc+XV4k1gH8eEXNHWuvhX4TeUFDSh4tZVy2Hn1VEG4JP9lieZzU/nlQuLoNgjqpb/r8TBf1PljZ9X/UlgrR2VomZKNq3IEyGBoABH9gMMpVR3RevOo3kvRIlu1G33xv3YaN3H4WtcdjqjZT/gDVN6UvnYUsBdtfD3j/14= Received: by 10.141.113.6 with SMTP id q6mr7116640rvm.249.1205643954843; Sat, 15 Mar 2008 22:05:54 -0700 (PDT) Received: by 10.140.143.14 with HTTP; Sat, 15 Mar 2008 22:05:54 -0700 (PDT) Message-ID: Date: Sun, 16 Mar 2008 14:05:54 +0900 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: jkoshy@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 6c86da32d5b43fc8 Cc: current@freebsd.org Subject: Re: issues with hwpmc and athlon XP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2008 05:05:55 -0000 On 10/03/2008, Adrian Chadd wrote: > Between my Athlon XP box giving me no useful pmc stats and my new Core > 2 duo box not even working with pmc, I decided to poke at the Athlon > XP support a bit to see if I could figure out what was going on. Here's an updated patch. It seems to be returning the system CPU usage I expect in my profile but I still don't get any useful usermode sampling. I'll dig deeper into that to try and figure out whats going on. It fixes a debugging output issue (which I'm happy to commit seperately) and it "sign-extends" the 48 value read back from the AMD counter to a 64 bit value to preserve the 2s compliment semantics that is used for the "count up to overflow NMI" trick. jkoshy, do you mind if I commit this and then MFC it to RELENG_7? Thanks, Adrian Index: hwpmc_amd.c =================================================================== RCS file: /share/FreeBSD/cvsrepo/src/sys/dev/hwpmc/hwpmc_amd.c,v retrieving revision 1.14 diff -u -r1.14 hwpmc_amd.c --- hwpmc_amd.c 7 Dec 2007 08:20:15 -0000 1.14 +++ hwpmc_amd.c 16 Mar 2008 05:02:38 -0000 @@ -302,12 +302,22 @@ #endif tmp = rdmsr(pd->pm_perfctr); /* RDMSR serializes */ - if (PMC_IS_SAMPLING_MODE(mode)) - *v = AMD_PERFCTR_VALUE_TO_RELOAD_COUNT(tmp); - else - *v = tmp; + PMCDBG(MDP,REA,2,"amd-read (pre-munge) id=%d -> %jd", ri, tmp); + if (PMC_IS_SAMPLING_MODE(mode)) { + /* + * The counters are 48 bit but we expect them to be 64 bit for + * 2s compliment "hack" done to allow the "count up" to overflow + * which triggers the sampling mode NMI. + * This code sign-extends the 48 bit number in case the returned + * value requires it. + */ + if (tmp & 0x0000800000000000) + tmp |= 0xffff000000000000; + tmp = AMD_PERFCTR_VALUE_TO_RELOAD_COUNT(tmp); + } + *v = tmp; - PMCDBG(MDP,REA,2,"amd-read id=%d -> %jd", ri, *v); + PMCDBG(MDP,REA,2,"amd-read (post-munge) id=%d -> %jd", ri, *v); return 0; } @@ -683,7 +693,7 @@ KASSERT(cpu >= 0 && cpu < mp_ncpus, ("[amd,%d] out of range CPU %d", __LINE__, cpu)); - PMCDBG(MDP,INT,1, "cpu=%d tf=0x%p um=%d", cpu, (void *) tf, + PMCDBG(MDP,INT,1, "cpu=%d tf=%p um=%d", cpu, (void *) tf, TRAPF_USERMODE(tf)); retval = 0; From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 06:47:00 2008 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 6BC7D106564A for ; Sun, 16 Mar 2008 06:47:00 +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 5EE878FC13 for ; Sun, 16 Mar 2008 06:47:00 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m2G6l0VL089055; Sat, 15 Mar 2008 23:47:00 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m2G6kxGe089054; Sat, 15 Mar 2008 23:46:59 -0700 (PDT) (envelope-from obrien) Date: Sat, 15 Mar 2008 23:46:59 -0700 From: "David O'Brien" To: Kostik Belousov Message-ID: <20080316064659.GA88744@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Kostik Belousov , "Bjoern A. Zeeb" , FreeBSD current mailing list References: <20080315084441.V50685@maildrop.int.zabbadoz.net> <20080315211305.GO10374@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080315211305.GO10374@deviant.kiev.zoral.com.ua> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: Why is linux.ko rebuild everytime? 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: Sun, 16 Mar 2008 06:47:00 -0000 On Sat, Mar 15, 2008 at 11:13:05PM +0200, Kostik Belousov wrote: > On Sat, Mar 15, 2008 at 08:46:50AM +0000, Bjoern A. Zeeb wrote: > > if I just do a make right after buildkernel finished successfully > > linux.ko is rebuild (even though nothing was touched). > > I have to admit I am doing make in obj/.../sys/KERNCONF/ but to > > my understanding that should not matter. We seem to have some dependancy or file generation issue. For me its the em module in addition to the linux module that always gets recompiled if doing back-to-back kernel compiles with no change in between. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 07:58:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C24106566B for ; Sun, 16 Mar 2008 07:58:08 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 433B58FC13 for ; Sun, 16 Mar 2008 07:58:08 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so3152169rvb.43 for ; Sun, 16 Mar 2008 00:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=QYDvRMr3AIJn4IoFM5qi13RuymsoESYLc3RNpuM9oEI=; b=luosl3GUfhq3CWH+Pj8CyzoiFAlI07cGTCdjTqiB4E4D0bR08a8pIpgrCkVVROaWcZ7NRT1f8Umy6wc8QVllgnjXryZ1JRZErPXVvsywzcyvi0KO8rOPNliZsXLU7bNyz3BYsgMv6Wt1ZT93Mp+Ey4gj2iJuJh4euxXvkikUOzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qB0MYJKDObT088pjXUq6m0zNJN6RkYMNU9W0vBxd1uTc4hgh+4tviAYN36lBSU42HSKEzRJMkfKufxAFARHcK+50ubCIOvX4VFnLXQXecpmMM8BZKIuXK+KMDol57BwIPCbBflUAYzpYuSeR1Qv7eVAfYvXrjHw42PIotR7AcyY= Received: by 10.140.164.1 with SMTP id m1mr7205214rve.69.1205654287834; Sun, 16 Mar 2008 00:58:07 -0700 (PDT) Received: by 10.141.41.8 with HTTP; Sun, 16 Mar 2008 00:58:07 -0700 (PDT) Message-ID: <3dd203290803160058t57d8591as941873368e0fca5f@mail.gmail.com> Date: Sun, 16 Mar 2008 07:58:07 +0000 From: "Brad Pitney" To: freebsd-current@freebsd.org In-Reply-To: <3dd203290803120751s6d688d58vbc5b0e67db45221e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3dd203290803120751s6d688d58vbc5b0e67db45221e@mail.gmail.com> X-Mailman-Approved-At: Sun, 16 Mar 2008 11:18:02 +0000 Subject: Re: ral Lock Order Reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2008 07:58:08 -0000 On Wed, Mar 12, 2008 at 2:51 PM, Brad Pitney wrote: > Hi, > > the box was running CURRENT until it was branched for RELENG_7 which > was running code from September 2007 fine until I updated to "todays" > code I get this: > > lock order reversal: > 1st 0xc45070e0 ral0 (802.11 node scangen) @ > /usr/src/sys/net80211/ieee80211_node.c:1462 > 2nd 0xc4507741 ral0 (network driver) @ /usr/src/sys/dev/ral/rt2560.c:2006 > > screenshot: http://picasaweb.google.com/pitney.brad/FreeBSDAlbum/photo#5176865196012647490 > > the box is dead after this happens, although I can switch consoles. > > I can easily reproduce this if I try to re-associate any client. > I'm now running 6.2 without any issues, I really would like to get back to running RELENG_7 -- Best regards, Brad From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 12:35:50 2008 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 50BF7106566B; Sun, 16 Mar 2008 12:35:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 26DEF8FC13; Sun, 16 Mar 2008 12:35:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2GCZnvw098723; Sun, 16 Mar 2008 08:35:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2GCZmMU038724; Sun, 16 Mar 2008 08:35:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 928B473039; Sun, 16 Mar 2008 07:35:48 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080316123548.928B473039@freebsd-current.sentex.ca> Date: Sun, 16 Mar 2008 07:35:48 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 16:43:31 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc 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, 16 Mar 2008 12:35:50 -0000 TB --- 2008-03-16 11:26:51 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-16 11:26:51 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-03-16 11:26:51 - cleaning the object tree TB --- 2008-03-16 11:27:17 - cvsupping the source tree TB --- 2008-03-16 11:27:17 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-03-16 11:27:27 - building world (CFLAGS=-O -pipe) TB --- 2008-03-16 11:27:27 - cd /src TB --- 2008-03-16 11:27:27 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 16 11:27:28 UTC 2008 >>> 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 16 12:31:04 UTC 2008 TB --- 2008-03-16 12:31:04 - generating LINT kernel config TB --- 2008-03-16 12:31:04 - cd /src/sys/powerpc/conf TB --- 2008-03-16 12:31:04 - /usr/bin/make -B LINT TB --- 2008-03-16 12:31:04 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-16 12:31:04 - cd /src TB --- 2008-03-16 12:31:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 16 12:31:04 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/fs/udf/udf_vfsops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/fs/udf/udf_vnops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/fs/unionfs/union_subr.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/fs/unionfs/union_vfsops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/fs/unionfs/union_vnops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/gdb/gdb_cons.c /src/sys/gdb/gdb_cons.c:131: error: expected ',' or ';' before 'static' /src/sys/gdb/gdb_cons.c:162: error: 'gdb_cnputc' undeclared here (not in a function) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-16 12:35:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-16 12:35:48 - ERROR: failed to build lint kernel TB --- 2008-03-16 12:35:48 - tinderbox aborted TB --- 3014.38 user 358.38 system 4136.45 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 13:26:03 2008 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 E7984106564A; Sun, 16 Mar 2008 13:26:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id BD7FE8FC16; Sun, 16 Mar 2008 13:26:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2GDQ2rj001237; Sun, 16 Mar 2008 09:26:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2GDQ2ba066327; Sun, 16 Mar 2008 09:26:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EB97273039; Sun, 16 Mar 2008 08:26:01 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080316132601.EB97273039@freebsd-current.sentex.ca> Date: Sun, 16 Mar 2008 08:26:01 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 16:43:31 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean 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: Sun, 16 Mar 2008 13:26:03 -0000 TB --- 2008-03-16 12:20:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-16 12:20:43 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-03-16 12:20:43 - cleaning the object tree TB --- 2008-03-16 12:21:13 - cvsupping the source tree TB --- 2008-03-16 12:21:13 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-03-16 12:21:23 - building world (CFLAGS=-O -pipe) TB --- 2008-03-16 12:21:23 - cd /src TB --- 2008-03-16 12:21:23 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 16 12:21:25 UTC 2008 >>> 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 16 13:20:59 UTC 2008 TB --- 2008-03-16 13:20:59 - generating LINT kernel config TB --- 2008-03-16 13:20:59 - cd /src/sys/sparc64/conf TB --- 2008-03-16 13:20:59 - /usr/bin/make -B LINT TB --- 2008-03-16 13:20:59 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-16 13:20:59 - cd /src TB --- 2008-03-16 13:20:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 16 13:20:59 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/udf/udf_vfsops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/udf/udf_vnops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/unionfs/union_subr.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/unionfs/union_vfsops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/unionfs/union_vnops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gdb/gdb_cons.c /src/sys/gdb/gdb_cons.c:131: error: expected ',' or ';' before 'static' /src/sys/gdb/gdb_cons.c:162: error: 'gdb_cnputc' undeclared here (not in a function) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-16 13:26:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-16 13:26:01 - ERROR: failed to build lint kernel TB --- 2008-03-16 13:26:01 - tinderbox aborted TB --- 2838.52 user 353.90 system 3918.83 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 13:28:33 2008 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 2A7471065682; Sun, 16 Mar 2008 13:28:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id F1B508FC52; Sun, 16 Mar 2008 13:28:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CB87346C2B; Sun, 16 Mar 2008 09:28:31 -0400 (EDT) Date: Sun, 16 Mar 2008 13:28:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: FreeBSD Tinderbox In-Reply-To: <20080316123548.928B473039@freebsd-current.sentex.ca> Message-ID: <20080316132701.P83063@fledge.watson.org> References: <20080316123548.928B473039@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: powerpc@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2008 13:28:33 -0000 On Sun, 16 Mar 2008, FreeBSD Tinderbox wrote: > /src/sys/gdb/gdb_cons.c:131: error: expected ',' or ';' before 'static' > /src/sys/gdb/gdb_cons.c:162: error: 'gdb_cnputc' undeclared here (not in a function) > *** Error code 1 Sorry about that! This should now be fixed -- in my attempt to not commit sys/kernel.h as part of the same patch as the ;-adding sweep, I accidentally left the gdb sub-directory off the list of directories and files I did want to commit on the cvs commit command line. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 13:37:44 2008 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 0907B106564A; Sun, 16 Mar 2008 13:37:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D141F8FC12; Sun, 16 Mar 2008 13:37:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2GDbhOh001656; Sun, 16 Mar 2008 09:37:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2GDbhdm000638; Sun, 16 Mar 2008 09:37:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E706B73039; Sun, 16 Mar 2008 08:37:42 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080316133742.E706B73039@freebsd-current.sentex.ca> Date: Sun, 16 Mar 2008 08:37:42 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 16:43:31 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2008 13:37:44 -0000 TB --- 2008-03-16 12:35:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-16 12:35:48 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-03-16 12:35:48 - cleaning the object tree TB --- 2008-03-16 12:36:12 - cvsupping the source tree TB --- 2008-03-16 12:36:12 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-03-16 12:36:20 - building world (CFLAGS=-O -pipe) TB --- 2008-03-16 12:36:20 - cd /src TB --- 2008-03-16 12:36:20 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 16 12:36:21 UTC 2008 >>> 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 16 13:33:45 UTC 2008 TB --- 2008-03-16 13:33:45 - generating LINT kernel config TB --- 2008-03-16 13:33:45 - cd /src/sys/sun4v/conf TB --- 2008-03-16 13:33:45 - /usr/bin/make -B LINT TB --- 2008-03-16 13:33:45 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-16 13:33:45 - cd /src TB --- 2008-03-16 13:33:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 16 13:33:45 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/udf/udf_vfsops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/udf/udf_vnops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/unionfs/union_subr.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/unionfs/union_vfsops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/fs/unionfs/union_vnops.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gdb/gdb_cons.c /src/sys/gdb/gdb_cons.c:131: error: expected ',' or ';' before 'static' /src/sys/gdb/gdb_cons.c:162: error: 'gdb_cnputc' undeclared here (not in a function) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-16 13:37:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-16 13:37:42 - ERROR: failed to build lint kernel TB --- 2008-03-16 13:37:42 - tinderbox aborted TB --- 2824.05 user 351.85 system 3714.27 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 19:36:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7391B1065676 for ; Sun, 16 Mar 2008 19:36:11 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9448FC2F for ; Sun, 16 Mar 2008 19:36:10 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JayeL-0003hU-Dg for freebsd-current@freebsd.org; Sun, 16 Mar 2008 19:36:05 +0000 Received: from 78-1-114-140.adsl.net.t-com.hr ([78.1.114.140]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Mar 2008 19:36:05 +0000 Received: from ivoras by 78-1-114-140.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Mar 2008 19:36:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 16 Mar 2008 20:35:42 +0100 Lines: 32 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0F5F680FCAB8FEAC15AFD341" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-114-140.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) X-Enigmail-Version: 0.95.6 Sender: news Subject: Panic of 8-CURRENT in VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2008 19:36:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F5F680FCAB8FEAC15AFD341 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I cannot boot a very recent build (minutes ago) of 8-CURRENT on VMWare=20 Server. Panic ("integer divide fault" - is this division by zero?) is in = sched_rr_interval(). More info here: http://ivoras.sharanet.org/stuff/panic/ It might be because I'm trying to run without WITNESS+INVARIANTS. --------------enig0F5F680FCAB8FEAC15AFD341 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3XaVldnAQVacBcgRAi7AAKCgNtLB1XKYNOGnGn4ax4CSfYSmDACeJxul DPkZ91PVB+Wn39zK11MpjoQ= =307R -----END PGP SIGNATURE----- --------------enig0F5F680FCAB8FEAC15AFD341-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 22:24:35 2008 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 09403106566B for ; Sun, 16 Mar 2008 22:24:35 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.freebsd.org (Postfix) with ESMTP id D76B38FC16 for ; Sun, 16 Mar 2008 22:24:34 +0000 (UTC) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 2912A731B4; Sun, 16 Mar 2008 22:24:34 +0000 (GMT) Date: Sun, 16 Mar 2008 22:24:34 +0000 From: John Birrell To: current@freebsd.org Message-ID: <20080316222433.GA20366@what-creek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: HEADSUP: DTrace support in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2008 22:24:35 -0000 This is an early headsup for DTrace support being committed to current. I plan to start committing stuff bit-by-bit starting a week from now, subject to review of the bits. As part of this work I will be moving the CDDL sources that ZFS uses into a separate CDDL-specific tree according to core@ instructions (resulting from their license review). There will also be minor changes to ZFS to build some things in an 'opensolaris' kernel module which are shared with DTrace. Both the zfs and dtrace kernel modules will depend on the opensolaris module. I am not planning to commit all of DTrace in one big blob. Instead I want to get the changes in without enabling them in the build right away. The DTrace support is optional, so I'll try not to break the build. (famous last words?) -- John Birrell From owner-freebsd-current@FreeBSD.ORG Sun Mar 16 22:33:20 2008 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 24BB11065671 for ; Sun, 16 Mar 2008 22:33:20 +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 8939A8FC1D for ; Sun, 16 Mar 2008 22:33:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id B671717104 for ; Sun, 16 Mar 2008 22:33:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m2GMXBVL001027 for ; Sun, 16 Mar 2008 22:33:11 GMT (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Sun, 16 Mar 2008 22:33:11 +0000 Message-ID: <1026.1205706791@critter.freebsd.dk> Sender: phk@critter.freebsd.dk X-Mailman-Approved-At: Sun, 16 Mar 2008 22:41:22 +0000 Cc: Subject: Enhanced SpeedStep hosed in -current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2008 22:33:20 -0000 It looks like my laptop runs full speed at all times, no matter what powerd or I may desire. Looks like the EST driver is (suddenly ?) not happy about the system. sysctl, dmesg & acpidump included. Poul-Henning PS: the pcib3 message in dmesg also looks bogus ? dev.est.0.%desc: Enhanced SpeedStep Frequency Control dev.est.0.%driver: est dev.est.0.%parent: cpu0 dev.est.0.freq_settings: 2000/31000 1667/25000 1000/13000 dev.est.1.%desc: Enhanced SpeedStep Frequency Control dev.est.1.%driver: est dev.est.1.%parent: cpu1 dev.est.1.freq_settings: 1667/25000 1000/13000 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 125 dev.cpu.0.freq_levels: 2000/31000 1750/27125 1667/25000 1458/21875 1250/18750 1041/15625 1000/13000 875/11375 750/9750 625/8125 500/6500 375/4875 250/3250 125/1625 dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 21.12% 78.87% dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/17 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 74.18% 25.81% Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #2: Sun Mar 16 19:26:33 UTC 2008 root@critter.freebsd.dk:/freebsd/src/sys/i386/compile/C5 Preloaded elf kernel "/boot/kx/kernel" at 0xc0910000. Preloaded elf module "/boot/kx/acpi.ko" at 0xc09101e0. Calibrating clock(s) ... i8254 clock: 1193198 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1995019896 Hz CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (1995.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 4096 kbytes, 16-way associative, 64 bytes/line real memory = 2137260032 (2038 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000007d418fff, 2088714240 bytes (509940 pages) avail memory = 2088230912 (1991 MB) Table 'FACP' at 0x7f64ff8c Table 'SSDT' at 0x7f64e7a4 Table 'MCFG' at 0x7f64ea09 Table 'SSDT' at 0x7f64ea45 Table 'SSDT' at 0x7f64f5f5 Table 'APIC' at 0x7f64fd4e MADT: Found table at 0x7f64fd4e APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f5720 bios32: Entry = 0xfdbf4 (c00fdbf4) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfdbe0+0x10 pnpbios: Found PnP BIOS data at 0xc00f57f0 pnpbios: Entry = f0000:b9ba Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP @ 0x0xf5770/0x0014 (v 0 FUJ ) ACPI: RSDT @ 0x0x7f6478d8/0x0048 (v 1 FSC PC 0x01300000 FUJ 0x00000100) ACPI: FACP @ 0x0x7f64ff8c/0x0074 (v 1 FSC PC 0x01300000 FUJ 0x00000100) ACPI: DSDT @ 0x0x7f647930/0x6E74 (v 1 FUJ FJNB1B5 0x01300000 MSFT 0x0100000E) ACPI: FACS @ 0x0x7f650fc0/0x0040 ACPI: SSDT @ 0x0x7f64e7a4/0x0265 (v 1 FUJ FJNB1B5 0x01300000 MSFT 0x0100000E) ACPI: MCFG @ 0x0x7f64ea09/0x003C (v 1 FUJ FJNB1B5 0x01300000 FUJ 0x00000100) ACPI: SSDT @ 0x0x7f64ea45/0x04DC (v 1 FUJ FJNB1B5 0x01300000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f64f5f5/0x0759 (v 1 FUJ FJNB1B5 0x01300000 INTL 0x20050624) ACPI: APIC @ 0x0x7f64fd4e/0x0068 (v 1 FUJ FJNB1B5 0x01300000 LTP 0x00000000) ACPI: HPET @ 0x0x7f64fdb6/0x0038 (v 1 FUJ FJNB1B5 0x01300000 FUJ 0x00000100) ACPI: BOOT @ 0x0x7f64fdee/0x0028 (v 1 FUJ FJNB1B5 0x01300000 FUJ 0x00000100) ACPI: SLIC @ 0x0x7f64fe16/0x0176 (v 1 FSC PC 0x01300000 FSC 0x00000100) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan_amrr: wlan: <802.11 Link Layer> ath_rate: version 1.2 io: null: VESA: information block 56 45 53 41 00 03 00 01 00 01 01 00 00 00 40 00 00 01 7b 00 00 01 43 01 00 01 55 01 00 01 89 01 00 01 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 VESA: 12 mode(s) found VESA: v3.0, 7872k memory, flags:0x1, mode table:0xc0802820 (1000040) VESA: Intel(r) 82945GM Chipset Family Graphics Chip Accelerated VGA BIOS VESA: Intel Corporation Intel(r) 82945GM Chipset Family Graphics Controller Hardware Version 0.0 kbd: new array size 4 kbd1 at kbdmux0 random: nfslock: pseudo-device mem: Pentium Pro MTRR support enabled ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: SSDT @ 0x0x7f6505c3/0x0893 (v 1 FUJ FJNB1B5 0x01300000 INTL 0x20050624) acpi0: Power Button (fixed) acpi0: wakeup code va 0xd8a71000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa20 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27a08086) pcibios: BIOS_PRESENT call failed AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/2 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x27a0, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27a2, revid=0x03 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xf0200000, size 19, enabled map[14]: type I/O Port, range 32, base 0x1800, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xe0000000, size 28, enabled map[1c]: type Memory, range 32, base 0xf0300000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27a6, revid=0x03 domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf0280000, size 19, enabled found-> vendor=0x8086, dev=0x27d8, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf0540000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27d0, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x27d2, revid=0x02 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x27d4, revid=0x02 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 20 found-> vendor=0x8086, dev=0x27c8, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x27ca, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x02 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf0544000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xe2 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b9, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x02 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0x1810, size 4, enabled found-> vendor=0x8086, dev=0x27c4, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x18d0, size 3, enabled map[14]: type I/O Port, range 32, base 0x18c4, size 2, enabled map[18]: type I/O Port, range 32, base 0x18c8, size 3, enabled map[1c]: type I/O Port, range 32, base 0x18c0, size 2, enabled map[20]: type I/O Port, range 32, base 0x18b0, size 4, enabled map[24]: type Memory, range 32, base 0xf0544400, size 10, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x18e0, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 vgapci0: port 0x1800-0x1807 mem 0xf0200000-0xf027ffff,0xe0000000-0xefffffff,0xf0300000-0xf033ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xf0200000 vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xf0300000 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xf0280000-0xf02fffff at device 2.1 on pci0 pci0: at device 27.0 (no driver attached) pcib1: irq 22 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xf0000000-0xf00fffff pcib1: no prefetched decode pci2: on pcib1 pci2: domain=0, physical bus=2 found-> vendor=0x11ab, dev=0x4363, revid=0x12 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf0000000, size 14, enabled pcib1: requested memory range 0xf0000000-0xf0003fff: good map[18]: type I/O Port, range 32, base 0x2000, size 8, enabled pcib1: requested I/O range 0x2000-0x20ff: in range pcib1: matched entry for 2.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 mskc0: port 0x2000-0x20ff mem 0xf0000000-0xf0003fff irq 16 at device 0.0 on pci2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xf0000000 mskc0: MSI count : 1 mskc0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 mskc0: using IRQ 256 for MSI mskc0: RAM buffer size : 128KB mskc0: Port 0 : Rx Queue 85KB(0x00000000:0x000153ff) mskc0: Port 0 : Tx Queue 43KB(0x00015400:0x0001ffff) msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:17:42:42:cd:7a miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [MPSAFE] mskc0: [FILTER] pcib2: irq 21 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 3 pcib2: subordinate bus 4 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci3: on pcib2 pci3: domain=0, physical bus=3 pcib3: irq 20 at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 5 pcib3: subordinate bus 5 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pci5: on pcib3 pci5: domain=0, physical bus=5 found-> vendor=0x8086, dev=0x4222, revid=0x02 domain=0, bus=5, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf0100000, size 12, enabled pcib3: requested unsupported memory range 0xf0100000-0xf0100fff (decoding 0-0, 0-0) pcib3: matched entry for 5.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 pci5: at device 0.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.3 (no driver attached) pci0: at device 29.7 (no driver attached) pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 8 pcib4: subordinate bus 9 pcib4: I/O decode 0xf000-0xfff pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci8: on pcib4 pci8: domain=0, physical bus=8 found-> vendor=0x1217, dev=0x7134, revid=0x21 domain=0, bus=8, slot=3, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0xc0 (48000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, enabled pcib4: matched entry for 8.3.INTA pcib4: slot 3 INTA hardwired to IRQ 16 cbb0: irq 16 at device 3.0 on pci8 pcib4: cbb0 requested memory range 0x0-0xffffffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 50 cbb0: [MPSAFE] cbb0: [ITHREAD] cbb0: PCI Configuration space: 0x00: 0x71341217 0x04100007 0x06070021 0x00824000 0x10: 0x80000000 0x020000a0 0x20090908 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffd 0x30: 0x00000001 0x0000fffd 0x00000001 0x04400110 0x40: 0x131e10cf 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000000 0x00000000 0x00000000 0x01001002 0x90: 0x00052406 0x00000000 0x00000000 0x00000000 0xa0: 0xfe020001 0x00c04000 0x00000000 0x0000001f 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x09006100 0x818203ea 0x00000000 0x00480018 0xe0: 0x00820000 0x000b101b 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1810 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 51 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 52 ata1: [MPSAFE] ata1: [ITHREAD] atapci1: port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xf0544400-0xf05447ff irq 19 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x18b0 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 atapci1: [MPSAFE] atapci1: [ITHREAD] pci0: child atapci1 requested type 4 for rid 0x24, but the BAR says it is an memio ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x18d0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x18c4 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x18c8 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x18c0 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) cpu0: on acpi0 ACPI: SSDT @ 0x0x7f64ef21/0x01E8 (v 1 FUJ FJNB1B5 0x01300000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f64f3a0/0x01D0 (v 1 FUJ FJNB1B5 0x01300000 INTL 0x20050624) est0: on cpu0 est0: Invalid id16 (set, cur) = (2067, 2587) est0: Invalid freq 1333, ignored. p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0x7f64f319/0x0087 (v 1 FUJ FJNB1B5 0x01300000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f64f570/0x0085 (v 1 FUJ FJNB1B5 0x01300000 INTL 0x20050624) est1: on cpu1 est1: Invalid id16 (set, cur) = (3106, 1570) est1: Invalid freq 2000, ignored. est1: Invalid id16 (set, cur) = (2067, 2587) est1: Invalid freq 1333, ignored. p4tcc1: on cpu1 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 54 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 55 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0 failed to probe at port 0x3f8 irq 4 on isa0 sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 133880 -> 100000 procfs registered lapic: Divisor 2, Frequency 83125841 hz Timecounter "TSC" frequency 1995019896 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached acpi_acad0: acline initialization start acpi_acad0: On Lineata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire acpi_acad0: acline initialization done, tried 1 timesacd0: setting PIO4 on ICH7 chip battery0: battery initialization start acd0: setting UDMA33 on ICH7 chip battery0: battery initialization done, tried 1 times battery1: battery initialization start acd0: DVDR drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ad4: 95396MB at ata2-master SATA150 ad4: 195371568 sectors [193821C/16H/63S] 16 sectors/interrupt 1 depth queue SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning ISA IRQ 15 to local APIC 0 ioapic0: Assigning PCI IRQ 16 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 msi: Assigning MSI IRQ 256 to local APIC 1 GEOM: new disk ad4 pcib4: requested memory range 0x88000000-0xffffffff: good cbb0: Opening memory: cbb0: Normal: 0x88000000-0x8800ffff unknown: Lazy allocation of 0x10000 bytes rid 0x10 type 3 at 0x88000000 cbb0: Opening memory: map[10]: type Memory, range 32, base 0, size 16, enabled pcib4: requested memory range 0x88000000-0xffffffff: good found-> vendor=0x168c, dev=0x0013, revid=0x01 domain=0, bus=9, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 ath0: mem 0x88000000-0x8800ffff irq 16 at device 0.0 on cardbus0 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x88000000 cbb0: Opening memory: cbb0: Normal: 0x88000000-0x8800ffff ath0: [MPSAFE] ath0: [ITHREAD] ath0: hal channel 2412/a0 -> 1 ath0: hal channel 2412/c0 -> 1 ath0: hal channel 2417/a0 -> 2 ath0: hal channel 2417/c0 -> 2 ath0: hal channel 2422/a0 -> 3 ath0: hal channel 2422/c0 -> 3 ath0: hal channel 2427/a0 -> 4 ath0: hal channel 2427/c0 -> 4 ath0: hal channel 2432/a0 -> 5 ath0: hal channel 2432/c0 -> 5 ath0: hal channel 2437/a0 -> 6 ath0: hal channel 2437/c0 -> 6 ath0: hal channel 2437/d0 -> 6 ath0: hal channel 2442/a0 -> 7 ath0: hal channel 2442/c0 -> 7 ath0: hal channel 2447/a0 -> 8 ath0: hal channel 2447/c0 -> 8 ath0: hal channel 2452/a0 -> 9 ath0: hal channel 2452/c0 -> 9 ath0: hal channel 2457/a0 -> 10 ath0: hal channel 2457/c0 -> 10 ath0: hal channel 2462/a0 -> 11 ath0: hal channel 2462/c0 -> 11 ath0: hal channel 5180/140 -> 36 ath0: hal channel 5200/140 -> 40 ath0: hal channel 5200/150 -> 40 ath0: hal channel 5210/2150 -> 42 ath0: hal channel 5220/140 -> 44 ath0: hal channel 5240/140 -> 48 ath0: hal channel 5240/150 -> 48 ath0: hal channel 5250/2150 -> 50 ath0: hal channel 5260/140 -> 52 ath0: hal channel 5280/140 -> 56 ath0: hal channel 5280/150 -> 56 ath0: hal channel 5290/2150 -> 58 ath0: hal channel 5300/140 -> 60 ath0: hal channel 5320/140 -> 64 ath0: hal channel 5745/140 -> 149 ath0: hal channel 5760/2150 -> 152 ath0: hal channel 5765/140 -> 153 ath0: hal channel 5765/150 -> 153 ath0: hal channel 5785/140 -> 157 ath0: hal channel 5800/2150 -> 160 ath0: hal channel 5805/140 -> 161 ath0: hal channel 5805/150 -> 161 ath0: hal channel 5825/140 -> 165 ath0: WARNING: using obsoleted if_watchdog interface ath0: bpf attached ath0: Ethernet address: 00:0f:b5:0c:30:30 ath0: bpf attached ath0: bpf attached ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: sturboA rates: ath0: mac 5.9 phy 4.3 radio 3.6 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons Trying to mount root from ufs:ad4s2a start_init: trying /sbin/init Linux ELF exec handler installed ath0: link state changed to UP /* RSD PTR: OEM=FUJ, ACPI_Rev=1.0x (0) RSDT=0x7f6478d8, cksum=105 */ /* RSDT: Length=72, Revision=1, Checksum=154, OEMID=FSC, OEM Table ID=PC, OEM Revision=0x1300000, Creator ID=FUJ, Creator Revision=0x100 Entries={ 0x7f64ff8c, 0x7f64e7a4, 0x7f64ea09, 0x7f64ea45, 0x7f64f5f5, 0x7f64fd4e, 0x7f64fdb6, 0x7f64fdee, 0x7f64fe16 } */ /* FACP: Length=116, Revision=1, Checksum=206, OEMID=FSC, OEM Table ID=PC, OEM Revision=0x1300000, Creator ID=FUJ, Creator Revision=0x100 FACS=0x7f650fc0, DSDT=0x7f647930 INT_MODEL=PIC Preferred_PM_Profile=Unspecified (0) SCI_INT=9 SMI_CMD=0xb2, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0 PSTATE_CNT=0x80 PM1a_EVT_BLK=0x1000-0x1003 PM1a_CNT_BLK=0x1004-0x1005 PM2_CNT_BLK=0x1020-0x1020 PM_TMR_BLK=0x1008-0x100b GPE0_BLK=0x1028-0x102f P_LVL2_LAT=1 us, P_LVL3_LAT=100 us FLUSH_SIZE=0, FLUSH_STRIDE=0 DUTY_OFFSET=0, DUTY_WIDTH=0 DAY_ALRM=13, MON_ALRM=0, CENTURY=50 IAPC_BOOT_ARCH= Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4,DCK_CAP} */ /* FACS: Length=64, HwSig=0x000016c9, Firm_Wake_Vec=0x00000000 Global_Lock= Flags= Version=0 */ /* DSDT: Length=28276, Revision=1, Checksum=94, OEMID=FUJ, OEM Table ID=FJNB1B5, OEM Revision=0x1300000, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=613, Revision=1, Checksum=137, OEMID=FUJ, OEM Table ID=FJNB1B5, OEM Revision=0x1300000, Creator ID=MSFT, Creator Revision=0x100000e */ /* MCFG: Length=60, Revision=1, Checksum=11, OEMID=FUJ, OEM Table ID=FJNB1B5, OEM Revision=0x1300000, Creator ID=FUJ, Creator Revision=0x100 Base Address= 0x00000000f8000000 Segment Group= 0x0000 Start Bus= 0 End Bus= 63 */ /* SSDT: Length=1244, Revision=1, Checksum=203, OEMID=FUJ, OEM Table ID=FJNB1B5, OEM Revision=0x1300000, Creator ID=INTL, Creator Revision=0x20050624 */ /* SSDT: Length=1881, Revision=1, Checksum=42, OEMID=FUJ, OEM Table ID=FJNB1B5, OEM Revision=0x1300000, Creator ID=INTL, Creator Revision=0x20050624 */ /* APIC: Length=104, Revision=1, Checksum=237, OEMID=FUJ, OEM Table ID=FJNB1B5, OEM Revision=0x1300000, Creator ID= LTP, Creator Revision=0x0 Local APIC ADDR=0xfee00000 Flags={PC-AT} Type=Local APIC ACPI CPU=0 Flags={ENABLED} APIC ID=0 Type=Local APIC ACPI CPU=1 Flags={ENABLED} APIC ID=1 Type=IO APIC APIC ID=2 INT BASE=0 ADDR=0x00000000fec00000 Type=Local NMI ACPI CPU=0 LINT Pin=1 Flags={Polarity=active-hi, Trigger=edge} Type=Local NMI ACPI CPU=1 LINT Pin=1 Flags={Polarity=active-hi, Trigger=edge} Type=INT Override BUS=0 IRQ=0 INTR=2 Flags={Polarity=active-hi, Trigger=edge} Type=INT Override BUS=0 IRQ=9 INTR=9 Flags={Polarity=active-hi, Trigger=level} */ /* HPET: Length=56, Revision=1, Checksum=187, OEMID=FUJ, OEM Table ID=FJNB1B5, OEM Revision=0x1300000, Creator ID=FUJ, Creator Revision=0x100 HPET Number=0 ADDR=0xfed00000:0[0] (Memory) HW Rev=0x1 Comparitors=2 Counter Size=1 Legacy IRQ routing capable={TRUE} PCI Vendor ID=0x8086 Minimal Tick=0 */ /* BOOT: Length=40, Revision=1, Checksum=8, OEMID=FUJ, OEM Table ID=FJNB1B5, OEM Revision=0x1300000, Creator ID=FUJ, Creator Revision=0x100 */ /* SLIC: Length=374, Revision=1, Checksum=185, OEMID=FSC, OEM Table ID=PC, OEM Revision=0x1300000, Creator ID=FSC, Creator Revision=0x100 */ /* * Intel ACPI Component Architecture * AML Disassembler version 20070320 * * Disassembly of /tmp/acpidump.n7c3Xb, Sun Mar 16 22:32:54 2008 * * * Original Table Header: * Signature "DSDT" * Length 0x00007CA2 (31906) * Revision 0x01 * OEM ID "FUJ " * OEM Table ID "FJNB1B5 " * OEM Revision 0x01300000 (19922944) * Creator ID "MSFT" * Creator Revision 0x0100000E (16777230) */ DefinitionBlock ("/tmp/acpidump.aml", "DSDT", 1, "FUJ ", "FJNB1B5 ", 0x01300000) { External (\_SB_.PCI0.GFX0.LCD_.BLNF, MethodObj) // 0 Arguments Name (BIDT, Buffer (0x10) { /* 0000 */ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, /* 0008 */ 0x08, 0x00, 0x00, 0x00, 0x09, 0x0A, 0x00, 0x0B }) Name (BMNT, Package (0x0C) { "CP279074", "CP293530", "CP293546", "CP293562", "CP293578", "CP293594", "CP293610", "CP293626", "CP293642", "CP245360", "CP186215 / CP186216", "CP144820 / CP144821" }) Name (BMST, Package (0x0C) { "CP279074", "CP293530", "CP293546", "CP293562", "CP293578", "CP293594", "CP293610", "CP293626", "CP293642", "CP245360", "CP245376", "CP245408" }) Scope (\_PR) { Processor (CPU0, 0x00, 0x00001010, 0x06) {} Processor (CPU1, 0x01, 0x00001010, 0x06) {} } Scope (\_SB) { Name (OSTB, Ones) OperationRegion (OSTY, SystemMemory, 0x7F650EF6, 0x00000001) Field (OSTY, AnyAcc, NoLock, Preserve) { TPOS, 8 } Method (OSTP, 0, NotSerialized) { If (LEqual (^OSTB, Ones)) { If (CondRefOf (\_OSI, Local0)) { If (\_OSI ("Windows 2006")) { Store (0x40, ^OSTB) Store (0x40, ^TPOS) } Else { If (\_OSI ("Windows 2001.1")) { Store (0x20, ^OSTB) Store (0x20, ^TPOS) } Else { If (\_OSI ("Windows 2001 SP1")) { Store (0x10, ^OSTB) Store (0x10, ^TPOS) } Else { If (\_OSI ("Windows 2001")) { Store (0x08, ^OSTB) Store (0x08, ^TPOS) } Else { Store (0x00, ^OSTB) Store (0x00, ^TPOS) } } } } } Else { If (CondRefOf (\_OS, Local0)) { If (^SEQL (\_OS, "Microsoft Windows")) { Store (0x01, ^OSTB) Store (0x01, ^TPOS) } Else { If (^SEQL (\_OS, "Microsoft WindowsME: Millennium Edition")) { Store (0x02, ^OSTB) Store (0x02, ^TPOS) } Else { If (^SEQL (\_OS, "Microsoft Windows NT")) { Store (0x04, ^OSTB) Store (0x04, ^TPOS) } Else { Store (0x00, ^OSTB) Store (0x00, ^TPOS) } } } } Else { Store (0x00, ^OSTB) Store (0x00, ^TPOS) } } } Return (^OSTB) } Method (SEQL, 2, Serialized) { Store (SizeOf (Arg0), Local0) Store (SizeOf (Arg1), Local1) If (LNotEqual (Local0, Local1)) { Return (Zero) } Name (BUF0, Buffer (Local0) {}) Store (Arg0, BUF0) Name (BUF1, Buffer (Local0) {}) Store (Arg1, BUF1) Store (Zero, Local2) While (LLess (Local2, Local0)) { Store (DerefOf (Index (BUF0, Local2)), Local3) Store (DerefOf (Index (BUF1, Local2)), Local4) If (LNotEqual (Local3, Local4)) { Return (Zero) } Increment (Local2) } Return (One) } } Name (FWSO, Zero) Name (RPEN, Zero) Name (RPDS, Zero) Name (BYIS, 0xFF) Name (EXIS, 0xFF) Name (PLWM, Zero) Name (PTAL, Zero) Name (LEDI, Zero) Name (BTNI, Zero) Name (NGTI, 0x06) Name (ECCI, 0x03) Name (GINT, Zero) Name (DPCI, One) Name (DPCS, Zero) Name (LIDS, Zero) Name (VSTH, Zero) Name (HDWA, Zero) Name (\GPIC, 0x00) Method (\_PIC, 1, NotSerialized) { Store (Arg0, GPIC) } Scope (\_SB) { OperationRegion (PSIO, SystemIO, 0x00000F40, 0x00000002) OperationRegion (PSBF, SystemMemory, 0x7F650E66, 0x00000090) OperationRegion (OEMT, SystemMemory, 0x7F650F9C, 0x00000020) OperationRegion (SYSC, SystemMemory, 0x7F650F92, 0x0000000A) OperationRegion (VDEX, SystemMemory, 0x7F650E56, 0x00000010) OperationRegion (THZN, SystemMemory, 0x7F650F82, 0x00000010) OperationRegion (BTNC, SystemMemory, 0x7F650F72, 0x00000010) OperationRegion (VIST, SystemMemory, 0x7F6505C3, 0x00000893) OperationRegion (QBC, SystemMemory, 0x7F650F66, 0x0000000C) OperationRegion (TCG1, SystemMemory, 0x7F6505BF, 0x00000004) OperationRegion (IO80, SystemIO, 0x80, 0x01) Scope (\) { Field (\_SB.PSIO, ByteAcc, NoLock, Preserve) { SSMI, 8 } Field (\_SB.PSBF, ByteAcc, NoLock, Preserve) { CMD, 8, DVID, 32, PSDT, 32 } Field (\_SB.PSBF, ByteAcc, NoLock, Preserve) { Offset (0x05), INF, 8 } Field (\_SB.PSBF, ByteAcc, NoLock, Preserve) { Offset (0x05), PIID, 320 } Field (\_SB.OEMT, ByteAcc, NoLock, Preserve) { SPAF, 2, SPBF, 2, PPF, 3, FDCF, 1, SIDF, 2, IMTF, 1, BLEN, 1, WLEN, 1, BTEX, 1, Offset (0x04), WAPB, 1, Offset (0x08), FWHM, 1, , 1, TPMF, 2, HWPM, 1, RRCP, 1, INTV, 1, FSCM, 1, , 1, CPBL, 1, AS34, 1, Offset (0x0A), BIFL, 8, DCLW, 7, Offset (0x10), FDS0, 4, FDS1, 4, Offset (0x18), UMST, 32, UMSZ, 32 } Field (\_SB.SYSC, ByteAcc, NoLock, Preserve) { BHKF, 1, , 2, MHKF, 1, Offset (0x01), BLLM, 8, BLLT, 64 } Field (\_SB.SYSC, ByteAcc, NoLock, Preserve) { AHKF, 8 } Field (\_SB.VDEX, ByteAcc, NoLock, Preserve) { ADOS, 3, CLCD, 1, ALCD, 1, CCRT, 1, ACRT, 1, CTV, 1, ATV, 1, CDVI, 1, ADVI, 1, DSWF, 2, BSWF, 2 } Field (\_SB.THZN, ByteAcc, NoLock, Preserve) { DTS1, 8, DTS2, 8, CRTT, 8, PSVT, 8, TC1V, 4, TC2V, 4, TSPV, 4, MPEN, 1, DTSE, 1 } Field (\_SB.BTNC, ByteAcc, NoLock, Preserve) { IRBF, 1, VLBF, 3, , 3, NGTF, 1, Offset (0x04), IRBC, 16 } Field (\_SB.QBC, ByteAcc, NoLock, Preserve) { QAG1, 32, QAG2, 32, QAG3, 32 } Field (\_SB.TCG1, AnyAcc, NoLock, Preserve) { PPRQ, 8, PPLO, 8, PPRP, 8, PPOR, 8 } Field (\_SB.IO80, ByteAcc, NoLock, Preserve) { PO80, 8 } } Method (_INI, 0, NotSerialized) { If (LGreaterEqual (\_SB.OSTP (), 0x40)) { Load (VIST, VSTH) } And (G3P1, 0xC0, Local0) If (LEqual (Local0, 0xC0)) { Store (Zero, LEDI) Store (Zero, BTNI) } Else { If (Local0) { Store (Zero, LEDI) Store (0x00FF0101, BTNI) } Else { Store (Zero, LEDI) Store (0x000F0001, BTNI) } } } Device (MCFG) { Name (_HID, EisaId ("PNP0C02")) Name (_CRS, ResourceTemplate () { DWordMemory (ResourceConsumer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Granularity 0xF8000000, // Range Minimum 0xFBFFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x04000000, // Length ,, , AddressRangeMemory, TypeStatic) }) } Device (PCI0) { Name (_HID, EisaId ("PNP0A08")) Name (_CID, 0x030AD041) Name (_ADR, 0x00) Name (_BBN, 0x00) OperationRegion (HBUS, PCI_Config, 0x40, 0xC0) Field (HBUS, DWordAcc, NoLock, Preserve) { Offset (0x50), , 4, PM0H, 2, Offset (0x51), PM1L, 2, , 2, PM1H, 2, Offset (0x52), PM2L, 2, , 2, PM2H, 2, Offset (0x53), PM3L, 2, , 2, PM3H, 2, Offset (0x54), PM4L, 2, , 2, PM4H, 2, Offset (0x55), PM5L, 2, , 2, PM5H, 2, Offset (0x56), PM6L, 2, , 2, PM6H, 2, Offset (0x57), , 7, HENA, 1, Offset (0x5C), , 3, TOUD, 5 } Name (BUF0, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0100, // Length ,, ) DWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000000, // Range Minimum 0x00000CF7, // Range Maximum 0x00000000, // Translation Offset 0x00000CF8, // Length ,, , TypeStatic) IO (Decode16, 0x0CF8, // Range Minimum 0x0CF8, // Range Maximum 0x01, // Alignment 0x08, // Length ) DWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000D00, // Range Minimum 0x0000FFFF, // Range Maximum 0x00000000, // Translation Offset 0x0000F300, // Length ,, , TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000A0000, // Range Minimum 0x000BFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00020000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000C0000, // Range Minimum 0x000C3FFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000C4000, // Range Minimum 0x000C7FFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000C8000, // Range Minimum 0x000CBFFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000CC000, // Range Minimum 0x000CFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000D0000, // Range Minimum 0x000D3FFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000D4000, // Range Minimum 0x000D7FFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000D8000, // Range Minimum 0x000DBFFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000DC000, // Range Minimum 0x000DFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000E0000, // Range Minimum 0x000E3FFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000E4000, // Range Minimum 0x000E7FFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000E8000, // Range Minimum 0x000EBFFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000EC000, // Range Minimum 0x000EFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000F0000, // Range Minimum 0x000FFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00010000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0xFEBFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00000000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0xFED40000, // Range Minimum 0xFED44FFF, // Range Maximum 0x00000000, // Translation Offset 0x00005000, // Length ,, , AddressRangeMemory, TypeStatic) }) Method (_CRS, 0, Serialized) { If (PM1L) { CreateDWordField (BUF0, 0x7C, C0LN) Store (Zero, C0LN) } If (LEqual (PM1L, 0x01)) { CreateBitField (BUF0, 0x0358, C0RW) Store (Zero, C0RW) } If (PM1H) { CreateDWordField (BUF0, 0x96, C4LN) Store (Zero, C4LN) } If (LEqual (PM1H, 0x01)) { CreateBitField (BUF0, 0x0428, C4RW) Store (Zero, C4RW) } If (PM2L) { CreateDWordField (BUF0, 0xB0, C8LN) Store (Zero, C8LN) } If (LEqual (PM2L, 0x01)) { CreateBitField (BUF0, 0x04F8, C8RW) Store (Zero, C8RW) } If (PM2H) { CreateDWordField (BUF0, 0xCA, CCLN) Store (Zero, CCLN) } If (LEqual (PM2H, 0x01)) { CreateBitField (BUF0, 0x05C8, CCRW) Store (Zero, CCRW) } If (PM3L) { CreateDWordField (BUF0, 0xE4, D0LN) Store (Zero, D0LN) } If (LEqual (PM3L, 0x01)) { CreateBitField (BUF0, 0x0698, D0RW) Store (Zero, D0RW) } If (PM3H) { CreateDWordField (BUF0, 0xFE, D4LN) Store (Zero, D4LN) } If (LEqual (PM3H, 0x01)) { CreateBitField (BUF0, 0x0768, D4RW) Store (Zero, D4RW) } If (PM4L) { CreateDWordField (BUF0, 0x0118, D8LN) Store (Zero, D8LN) } If (LEqual (PM4L, 0x01)) { CreateBitField (BUF0, 0x0838, D8RW) Store (Zero, D8RW) } If (PM4H) { CreateDWordField (BUF0, 0x0132, DCLN) Store (Zero, DCLN) } If (LEqual (PM4H, 0x01)) { CreateBitField (BUF0, 0x0908, DCRW) Store (Zero, DCRW) } If (PM5L) { CreateDWordField (BUF0, 0x014C, E0LN) Store (Zero, E0LN) } If (LEqual (PM5L, 0x01)) { CreateBitField (BUF0, 0x09D8, E0RW) Store (Zero, E0RW) } If (PM5H) { CreateDWordField (BUF0, 0x0166, E4LN) Store (Zero, E4LN) } If (LEqual (PM5H, 0x01)) { CreateBitField (BUF0, 0x0AA8, E4RW) Store (Zero, E4RW) } If (PM6L) { CreateDWordField (BUF0, 0x0180, E8LN) Store (Zero, E8LN) } If (LEqual (PM6L, 0x01)) { CreateBitField (BUF0, 0x0B78, E8RW) Store (Zero, E8RW) } If (PM6H) { CreateDWordField (BUF0, 0x019A, ECLN) Store (Zero, ECLN) } If (LEqual (PM6H, 0x01)) { CreateBitField (BUF0, 0x0C48, ECRW) Store (Zero, ECRW) } If (PM0H) { CreateDWordField (BUF0, 0x01B4, F0LN) Store (Zero, F0LN) } If (LEqual (PM0H, 0x01)) { CreateBitField (BUF0, 0x0D18, F0RW) Store (Zero, F0RW) } CreateDWordField (BUF0, 0x01C2, M1MN) CreateDWordField (BUF0, 0x01C6, M1MX) CreateDWordField (BUF0, 0x01CE, M1LN) ShiftLeft (TOUD, 0x1B, M1MN) Add (Subtract (M1MX, M1MN), 0x01, M1LN) CreateDWordField (BUF0, 0x01DC, TPMN) CreateDWordField (BUF0, 0x01E0, TPMX) CreateDWordField (BUF0, 0x01E8, TPML) If (LNotEqual (TPMF, 0x02)) { Store (Zero, TPMN) Store (Zero, TPMX) Store (Zero, TPML) } Return (BUF0) } Method (_PRT, 0, NotSerialized) { If (GPIC) { Return (Package (0x10) { Package (0x04) { 0x0001FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0007FFFF, 0x03, 0x00, 0x10 }, Package (0x04) { 0x001BFFFF, 0x00, 0x00, 0x11 }, Package (0x04) { 0x001CFFFF, 0x00, 0x00, 0x16 }, Package (0x04) { 0x001CFFFF, 0x01, 0x00, 0x15 }, Package (0x04) { 0x001CFFFF, 0x02, 0x00, 0x14 }, Package (0x04) { 0x001CFFFF, 0x03, 0x00, 0x13 }, Package (0x04) { 0x001DFFFF, 0x00, 0x00, 0x17 }, Package (0x04) { 0x001DFFFF, 0x01, 0x00, 0x14 }, Package (0x04) { 0x001DFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0x001DFFFF, 0x03, 0x00, 0x10 }, Package (0x04) { 0x001EFFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x001EFFFF, 0x01, 0x00, 0x11 }, Package (0x04) { 0x001FFFFF, 0x00, 0x00, 0x12 }, Package (0x04) { 0x001FFFFF, 0x01, 0x00, 0x13 } }) } Else { Return (Package (0x10) { Package (0x04) { 0x0001FFFF, 0x00, \_SB.PCI0.LPCB.LNKA, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, \_SB.PCI0.LPCB.LNKA, 0x00 }, Package (0x04) { 0x0007FFFF, 0x03, \_SB.PCI0.LPCB.LNKA, 0x00 }, Package (0x04) { 0x001BFFFF, 0x00, \_SB.PCI0.LPCB.LNKB, 0x00 }, Package (0x04) { 0x001CFFFF, 0x00, \_SB.PCI0.LPCB.LNKG, 0x00 }, Package (0x04) { 0x001CFFFF, 0x01, \_SB.PCI0.LPCB.LNKF, 0x00 }, Package (0x04) { 0x001CFFFF, 0x02, \_SB.PCI0.LPCB.LNKE, 0x00 }, Package (0x04) { 0x001CFFFF, 0x03, \_SB.PCI0.LPCB.LNKD, 0x00 }, Package (0x04) { 0x001DFFFF, 0x00, \_SB.PCI0.LPCB.LNKH, 0x00 }, Package (0x04) { 0x001DFFFF, 0x01, \_SB.PCI0.LPCB.LNKE, 0x00 }, Package (0x04) { 0x001DFFFF, 0x02, \_SB.PCI0.LPCB.LNKC, 0x00 }, Package (0x04) { 0x001DFFFF, 0x03, \_SB.PCI0.LPCB.LNKA, 0x00 }, Package (0x04) { 0x001EFFFF, 0x00, \_SB.PCI0.LPCB.LNKG, 0x00 }, Package (0x04) { 0x001EFFFF, 0x01, \_SB.PCI0.LPCB.LNKE, 0x00 }, Package (0x04) { 0x001FFFFF, 0x00, \_SB.PCI0.LPCB.LNKC, 0x00 }, Package (0x04) { 0x001FFFFF, 0x01, \_SB.PCI0.LPCB.LNKD, 0x00 } }) } } Device (MBIO) { Name (_HID, EisaId ("PNP0C02")) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0010, // Range Minimum 0x0010, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x0024, // Range Minimum 0x0024, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0028, // Range Minimum 0x0028, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x002C, // Range Minimum 0x002C, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x002E, // Range Minimum 0x002E, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0030, // Range Minimum 0x0030, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0034, // Range Minimum 0x0034, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0038, // Range Minimum 0x0038, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x003C, // Range Minimum 0x003C, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0050, // Range Minimum 0x0050, // Range Maximum 0x01, // Alignment 0x04, // Length ) IO (Decode16, 0x0072, // Range Minimum 0x0072, // Range Maximum 0x01, // Alignment 0x06, // Length ) IO (Decode16, 0x0080, // Range Minimum 0x0080, // Range Maximum 0x01, // Alignment 0x01, // Length ) IO (Decode16, 0x0090, // Range Minimum 0x0090, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x00A4, // Range Minimum 0x00A4, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00A8, // Range Minimum 0x00A8, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00AC, // Range Minimum 0x00AC, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00B0, // Range Minimum 0x00B0, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00B2, // Range Minimum 0x00B2, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00B4, // Range Minimum 0x00B4, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00B8, // Range Minimum 0x00B8, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00BC, // Range Minimum 0x00BC, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x04D0, // Range Minimum 0x04D0, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0800, // Range Minimum 0x0800, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x1000, // Range Minimum 0x1000, // Range Maximum 0x01, // Alignment 0x80, // Length ) IO (Decode16, 0x1080, // Range Minimum 0x1080, // Range Maximum 0x01, // Alignment 0x80, // Length ) IO (Decode16, 0x1100, // Range Minimum 0x1100, // Range Maximum 0x01, // Alignment 0x20, // Length ) IO (Decode16, 0x1180, // Range Minimum 0x1180, // Range Maximum 0x01, // Alignment 0x40, // Length ) IO (Decode16, 0xF800, // Range Minimum 0xF800, // Range Maximum 0x01, // Alignment 0x80, // Length ) IO (Decode16, 0xF880, // Range Minimum 0xF880, // Range Maximum 0x01, // Alignment 0x80, // Length ) IO (Decode16, 0xFC00, // Range Minimum 0xFC00, // Range Maximum 0x01, // Alignment 0x80, // Length ) IO (Decode16, 0xFC80, // Range Minimum 0xFC80, // Range Maximum 0x01, // Alignment 0x80, // Length ) IO (Decode16, 0xFD0C, // Range Minimum 0xFD0C, // Range Maximum 0x01, // Alignment 0x74, // Length ) IO (Decode16, 0xFE00, // Range Minimum 0xFE00, // Range Maximum 0x01, // Alignment 0x02, // Length ) Memory32Fixed (ReadWrite, 0xF8000000, // Address Base 0x04000000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED14000, // Address Base 0x00004000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED18000, // Address Base 0x00001000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED19000, // Address Base 0x00001000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED1C000, // Address Base 0x00004000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED20000, // Address Base 0x00020000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED45000, // Address Base 0x0004B000, // Address Length ) Memory32Fixed (ReadWrite, 0xFEC00000, // Address Base 0x00001000, // Address Length ) Memory32Fixed (ReadWrite, 0xFEE00000, // Address Base 0x00001000, // Address Length ) Memory32Fixed (ReadWrite, 0xFEF00000, // Address Base 0x00100000, // Address Length ) Memory32Fixed (ReadWrite, 0x000CF000, // Address Base 0x00001000, // Address Length ) Memory32Fixed (ReadWrite, 0xFFB00000, // Address Base 0x00100000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED40000, // Address Base 0x00005000, // Address Length ) }) Method (_CRS, 0, Serialized) { CreateDWordField (RSRC, 0x0184, MBBS) CreateDWordField (RSRC, 0x0188, MBLN) CreateDWordField (RSRC, 0x0190, FWBS) CreateDWordField (RSRC, 0x0194, FWLN) CreateDWordField (RSRC, 0x019C, TPMB) CreateDWordField (RSRC, 0x01A0, TPML) Store (UMST, MBBS) Store (UMSZ, MBLN) If (FWHM) { Store (Zero, FWBS) Store (Zero, FWLN) } If (LEqual (TPMF, 0x02)) { Store (Zero, TPMB) Store (Zero, TPML) } Return (RSRC) } } Device (GFX0) { Name (_ADR, 0x00020000) Method (XLCD, 0, NotSerialized) { Return (One) } Method (XCRT, 0, NotSerialized) { Return (One) } Method (XTV, 0, NotSerialized) { Return (XOr (SOUT, One)) } Method (XDVI, 0, NotSerialized) { Return (BY2O) } Scope (\) { Name (WLCD, Zero) Name (WCRT, Zero) Name (WTV, Zero) Name (WDVI, Zero) } Method (PHTK, 0, NotSerialized) { Store (Zero, DSWF) } Name (F10T, Package (0x0A) { 0x01, 0x02, 0x03, 0x04, 0x05, 0x01, 0x02, 0x03, 0x04, 0x05 }) Method (AHTK, 0, NotSerialized) { If (LAnd (LEqual (And (ADOS, 0x03), Zero), DSWF)) { UPDD () If (LEqual (DSWF, 0x01)) { Or (ShiftLeft (CDVI, 0x02), Or (ShiftLeft (CCRT, 0x01), CLCD), Local0) Or (ShiftLeft (ADVI, 0x02), Or (ShiftLeft (ACRT, 0x01), ALCD), Local1) Store (Zero, Local2) Store (0xFF, Local3) While (LAnd (LLess (Local2, 0x0A), LEqual (Local3, 0xFF))) { If (LEqual (DerefOf (Index (F10T, Local2)), Local0)) { If (LAnd (CTV, ATV)) { Store (Local2, Local3) } Else { Add (Local2, 0x01, Local3) } } Increment (Local2) } Store (0xFF, Local2) If (LNotEqual (Local3, 0xFF)) { While (LAnd (LLess (Local3, 0x0A), LEqual (Local2, 0xFF))) { If (LEqual (And (DerefOf (Index (F10T, Local3)), Local1), DerefOf (Index (F10T, Local3)))) { Store (DerefOf (Index (F10T, Local3)), Local2) } Increment (Local3) } } If (LEqual (Local2, 0xFF)) { If (ALCD) { Store (0x01, Local2) } Else { If (ACRT) { Store (0x02, Local2) } Else { If (ADVI) { Store (0x04, Local2) } Else { Store (0x02, Local2) } } } } And (Local2, 0x01, WLCD) ShiftRight (And (Local2, 0x02), 0x01, WCRT) ShiftRight (And (Local2, 0x04), 0x02, WDVI) Store (Zero, WTV) Notify (\_SB.PCI0.GFX0, 0x80) } Else { If (LEqual (DSWF, 0x02)) { And (CLCD, ALCD, WLCD) And (CCRT, ACRT, WCRT) And (CDVI, ADVI, WDVI) And (XOr (CTV, 0x01), ATV, WTV) If (LOr (LOr (WTV, WDVI), LOr (WCRT, WLCD))) { If (LAnd (LAnd (WLCD, WCRT), WTV)) { Store (Zero, WCRT) } If (LAnd (LAnd (WLCD, WDVI), WTV)) { Store (Zero, WDVI) } If (LAnd (LAnd (WCRT, WDVI), WTV)) { Store (Zero, WDVI) } Notify (\_SB.PCI0.GFX0, 0x80) } } } } } Method (UPDD, 0, NotSerialized) { If (LGreaterEqual (\_SB.OSTP (), 0x08)) { Notify (\_SB.PCI0, 0x00) } Else { Notify (\_SB.PCI0.GFX0, 0x00) } Sleep (0x02EE) Store (0xFF, DVID) Store (0x8E, CMD) Store (Zero, SSMI) } Method (_DOS, 1, NotSerialized) { And (Arg0, 0x07, ADOS) } Method (_DOD, 0, NotSerialized) { Return (Package (0x04) { 0x00010100, 0x00010400, 0x00010200, 0x00010300 }) } Device (CRT) { Method (_ADR, 0, NotSerialized) { Return (0x0100) } Method (_DCS, 0, NotSerialized) { If (XCRT ()) { UPDD () Return (Or (0x0D, Or (ShiftLeft (ACRT, 0x04), ShiftLeft (CCRT, 0x01)))) } Else { Return (Zero) } } Method (_DGS, 0, NotSerialized) { Return (WCRT) } Method (_DSS, 1, NotSerialized) { Noop } } Device (LCD) { Method (_ADR, 0, NotSerialized) { Return (0x0400) } Method (_DCS, 0, NotSerialized) { If (XLCD ()) { UPDD () Return (Or (0x0D, Or (ShiftLeft (ALCD, 0x04), ShiftLeft (CLCD, 0x01)))) } Else { Return (Zero) } } Method (_DGS, 0, NotSerialized) { Return (WLCD) } Method (_DSS, 1, NotSerialized) { Noop } } Device (TV) { Method (_ADR, 0, NotSerialized) { Return (0x0200) } Method (_DCS, 0, NotSerialized) { If (XTV ()) { UPDD () Return (Or (0x0D, Or (ShiftLeft (ATV, 0x04), ShiftLeft (CTV, 0x01)))) } Else { Return (Zero) } } Method (_DGS, 0, NotSerialized) { Return (WTV) } Method (_DSS, 1, NotSerialized) { Noop } } Device (DVI) { Method (_ADR, 0, NotSerialized) { Return (0x0300) } Method (_DCS, 0, NotSerialized) { If (XDVI ()) { UPDD () Return (Or (0x0D, Or (ShiftLeft (ADVI, 0x04), ShiftLeft (CDVI, 0x01)))) } Else { Return (Zero) } } Method (_DGS, 0, NotSerialized) { Return (WDVI) } Method (_DSS, 1, NotSerialized) { Noop } } Scope (LCD) { Method (_PS0, 0, NotSerialized) { Store (0x00, LIDS) } Method (_PS3, 0, NotSerialized) { Store (0x01, LIDS) } } } Device (PCIB) { Name (_ADR, 0x001E0000) Method (_PRT, 0, NotSerialized) { If (GPIC) { Return (Package (0x02) { Package (0x04) { 0x0003FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0006FFFF, 0x00, 0x00, 0x11 } }) } Else { Return (Package (0x02) { Package (0x04) { 0x0003FFFF, 0x00, \_SB.PCI0.LPCB.LNKA, 0x00 }, Package (0x04) { 0x0006FFFF, 0x00, \_SB.PCI0.LPCB.LNKB, 0x00 } }) } } Method (_INI, 0, NotSerialized) { } Name (_PRW, Package (0x02) { 0x0B, 0x04 }) } Device (LPCB) { Name (_ADR, 0x001F0000) OperationRegion (LPC0, PCI_Config, 0x40, 0xC0) Field (LPC0, AnyAcc, NoLock, Preserve) { Offset (0x20), PARC, 8, PBRC, 8, PCRC, 8, PDRC, 8, Offset (0x28), PERC, 8, PFRC, 8, PGRC, 8, PHRC, 8, Offset (0x40), IOD0, 8, IOD1, 8, Offset (0x60), , 2, CLKR, 1 } OperationRegion (SIO, SystemIO, 0x2E, 0x02) OperationRegion (FJIO, SystemIO, 0xFD60, 0x15) Scope (\) { Field (\_SB.PCI0.LPCB.FJIO, ByteAcc, NoLock, Preserve) { AIDC, 8, ADTC, 8, AIDB, 8, ADTB, 8, AIDA, 8, ADTA, 8, AIDD, 8, ADTD, 8, Offset (0x10), PMID, 8, Offset (0x14), PMDT, 8 } } OperationRegion (PMIO, SystemIO, 0x1000, 0x80) OperationRegion (OGIO, SystemIO, 0x1180, 0x3C) Scope (\) { Field (\_SB.PCI0.LPCB.PMIO, ByteAcc, NoLock, Preserve) { Offset (0x42), , 1, GPEC, 1 } Field (\_SB.PCI0.LPCB.OGIO, ByteAcc, NoLock, Preserve) { Offset (0x2C), Offset (0x2D), LPOL, 1, , 4, EXPL, 1, Offset (0x38), , 1, PXRS, 1, PXCL, 1 } } OperationRegion (OPIO, SystemIO, 0x1000, 0x67) Scope (\) { Field (\_SB.PCI0.LPCB.OPIO, ByteAcc, NoLock, Preserve) { Offset (0x10), Offset (0x11), FOCT, 1 } } Method (_INI, 0, NotSerialized) { \_SB.OSTP () \_SB.PCI0.LPCB.CMBT.SWCF () AINI () PRCF () If (RRCP) { Store (One, RPEN) Store (B2TC, RPDS) } } Scope (\) { IndexField (AIDA, ADTA, ByteAcc, NoLock, Preserve) { Offset (0x09), RI1M, 1, RI2M, 1, RI3M, 1, RI4M, 1, RI1, 1, RI2, 1, RI3, 1, RI4, 1, , 2, CVCL, 1, , 3, BLCT, 2, Offset (0x20), G5P0, 8, G5C0, 8, G3P0, 8, G3C0, 8, Offset (0x40), SSF0, 8, SSF1, 8, SSM0, 8, SSM1, 8, SSI0, 8, SSTM, 8, SSF2, 8, SSM2, 8, SSI1, 8, Offset (0x52), G3P1, 8, G3C1, 8, G3P2, 8, G3C2, 8, QSWC, 8, Offset (0x60), SSS0, 8, SSS1, 8 } IndexField (AIDB, ADTB, ByteAcc, NoLock, Preserve) { Offset (0x29), BRCL, 8, LCDB, 8, Offset (0x30), LCDC, 8 } IndexField (AIDC, ADTC, ByteAcc, NoLock, Preserve) { TASF, 1, TBSF, 1, B1SU, 1, B1SD, 1, B2SU, 1, B2SD, 1, Offset (0x02), , 4, VSTB, 1, Offset (0x05), , 6, ACPW, 1, Offset (0x20), BCTL, 8, Offset (0x23), TAF, 1, TASM, 1, , 2, TBF, 1, TBSM, 1, Offset (0x24), TIMA, 8, TIMB, 8, Offset (0x28), CDLP, 8, HDLP, 8, FDLP, 8, Offset (0x4E), B1UM, 1, B1DM, 1, , 1, B1TC, 1, B2UM, 1, B2DM, 1, , 1, B2TC, 1, BAPC, 6 } IndexField (AIDC, ADTC, ByteAcc, NoLock, Preserve) { STAE, 8 } IndexField (AIDD, ADTD, ByteAcc, NoLock, Preserve) { Offset (0x80), GIDI, 8, GIDC, 8, GIDO, 8, Offset (0x90), G3SI, 8, G3SC, 8, G3SO, 8, G3SM, 8, Offset (0xA0), WOXF, 8, WOXE, 8, WOXD, 8, WOXS, 8, Offset (0xB0), AMPV, 6 } } Scope (\) { IndexField (PMID, PMDT, ByteAcc, NoLock, Preserve) { Offset (0xA0), UPPR, 1, ERRO, 1, PASS, 1, PSOK, 1, PSNG, 1, TOUT, 1, SIRN, 1, STSC, 1, OVFL, 1, LWMD, 1, TALM, 1, EMGC, 1, OCNT, 4, TDTC, 1, , 4, AERR, 1, PERR, 1, ABSY, 1, Offset (0xA4), PDAT, 8, Offset (0xC0), Offset (0xC1), B1P, 1, B2P, 1, B1C, 1, B2C, 1, B1ER, 1, B2ER, 1, PKSH, 1, CMB, 1, B1CP, 8, B2CP, 8, BAVG, 8, B1VH, 8, B1VL, 8, B2VH, 8, B2VL, 8, B1TM, 8, B2TM, 8, B1CH, 8, B1CL, 8, B2CH, 8, B2CL, 8, BTMH, 8, BTML, 8, B1LH, 8, B1LL, 8, B2LH, 8, B2LL, 8, B1ID, 4, B1NO, 4, B2ID, 4, B2NO, 4, B1DV, 8, B2DV, 8, B1DH, 8, B1DL, 8, B2DH, 8, B2DL, 8, TBSI, 8, TBSH, 8, TBSL, 8, BHDD, 1, BOPT, 1, , 5, ABLC, 1, Offset (0xE8), TBCM, 8, TBMD, 8, TBIN, 8, DCOL, 7, S3EN, 1 } IndexField (PMID, PMDT, ByteAcc, NoLock, Preserve) { Offset (0xA2), TCST, 8 } } Scope (\) { IndexField (AIDA, ADTA, ByteAcc, NoLock, Preserve) { Offset (0x22), , 4, SOUT, 1, Offset (0x52), BRST, 1, , 1, BY1C, 2 } IndexField (AIDC, ADTC, ByteAcc, NoLock, Preserve) { Offset (0x4F), BY1O, 1, BY2O, 1 } IndexField (AIDD, ADTD, ByteAcc, NoLock, Preserve) { Offset (0x80), BY1I, 4 } } Method (AINI, 0, NotSerialized) { And (SSM1, 0xCF, SSM1) Store (Zero, TBSM) Store (LWMD, PLWM) Store (TALM, PTAL) Store (0x95, CMD) Or (PLWM, ShiftLeft (PTAL, 0x01), DVID) Store (Zero, SSMI) If (LAnd (TALM, LNot (ACPW))) { Store (One, FOCT) } Else { Store (Zero, FOCT) } If (LGreaterEqual (\_SB.OSTP (), 0x40)) { If (AS34) { Store (0x01, S3EN) } If (LEqual (DCLW, 0x7F)) { Store (0x08, DCOL) } Else { Store (DCLW, DCOL) } } } Device (TPM) { Name (_HID, EisaId ("IFX0102")) Name (_CID, 0x310CD041) Name (_UID, 0x01) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x004E, // Range Minimum 0x004E, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0xFD00, // Range Minimum 0xFD00, // Range Maximum 0x01, // Alignment 0x0C, // Length ) Memory32Fixed (ReadWrite, 0xFED40000, // Address Base 0x00005000, // Address Length ) }) Method (_STA, 0, NotSerialized) { If (TPMF) { If (LEqual (TPMF, 0x02)) { Return (0x0F) } Else { Return (0x00) } } Else { Return (0x00) } } } Name (RGSI, 0x19) Device (FJEX) { Name (_HID, "FUJ02B1") Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (RBLL, 0, NotSerialized) { Return (BLLM) } Scope (\) { Name (LBLL, 0x00) Name (LLCD, Ones) } Method (GBLL, 0, NotSerialized) { Store (LBLL, Local2) Store (LCDB, Local1) If (LNotEqual (LLCD, Local1)) { Store (Local1, LLCD) Name (BBCT, Buffer (BLLM) {}) Store (BLLT, BBCT) Store (BLLM, Local0) While (Local0) { Decrement (Local0) If (LEqual (GBUF (BBCT, Local0), Local1)) { Store (Local0, Local2) Store (Local0, LBLL) Store (Zero, Local0) } } } If (BHKF) { Store (Zero, BHKF) Or (Local2, 0x80000000, Local2) } Return (Local2) } Method (GBLS, 0, NotSerialized) { Store (LBLL, Local2) Store (LCDB, Local1) If (LNotEqual (LLCD, Local1)) { Store (Local1, LLCD) Name (BBCT, Buffer (BLLM) {}) Store (BLLT, BBCT) Store (BLLM, Local0) While (Local0) { Decrement (Local0) If (LEqual (GBUF (BBCT, Local0), Local1)) { Store (Local0, Local2) Store (Local0, LBLL) Store (Zero, Local0) } } } If (BHKF) { Or (Local2, 0x80000000, Local2) } Return (Local2) } Method (SBLL, 1, NotSerialized) { If (NGTF) { Store (Arg0, LSBL) Return (Zero) } If (LLess (Arg0, BLLM)) { Name (BBCT, Buffer (BLLM) {}) Store (BLLT, BBCT) CreateByteField (BBCT, Arg0, BLL0) Store (BLL0, LCDB) Store (Arg0, DVID) Store (0x82, CMD) Store (Zero, SSMI) } } Method (GBUF, 2, NotSerialized) { CreateByteField (Arg0, Arg1, BLL0) Return (BLL0) } Method (GMOU, 0, NotSerialized) { Store (0x02, DVID) Store (0x91, CMD) Store (Zero, SSMI) Store (DVID, Local0) If (MHKF) { Store (Zero, MHKF) Or (Local0, 0x80000000, Local0) } Return (Local0) } Method (SMOU, 1, NotSerialized) { If (LLessEqual (Arg0, One)) { Store (Arg0, DVID) Store (0x91, CMD) Store (Zero, SSMI) } } Method (GHKS, 0, NotSerialized) { If (INTV) { ShiftLeft (VLBF, 0x04, Local0) Store (Zero, VLBF) Return (Or (Local0, AHKF)) } Else { Return (AHKF) } } Method (GSIF, 0, NotSerialized) { If (IMTF) { Or (RGSI, 0x08, RGSI) } Else { And (RGSI, 0xFFFFFFF7, RGSI) } If (INTV) { And (RGSI, 0xFFFFFFD1, RGSI) Or (RGSI, 0x41, RGSI) } Return (RGSI) } } Name (BTF1, 0x9A) Name (BTF2, 0x98) Scope (\) { Name (BTBL, Zero) Name (BTST, Zero) IndexField (AIDA, ADTA, ByteAcc, NoLock, Preserve) { Offset (0x20), , 5, ABEX, 1, Offset (0x44), , 2, WLSW, 1 } IndexField (AIDD, ADTD, ByteAcc, NoLock, Preserve) { Offset (0x92), , 2, WLRF, 1, ABON, 1 } } Device (CMBT) { Name (_HID, "FUJ02E1") Method (_STA, 0, NotSerialized) { If (LGreaterEqual (\_SB.OSTP (), 0x40)) { Return (0x00) } Else { If (LNot (BTEX)) { Return (0x00) } Else { If (BLEN) { Return (0x0F) } Else { Return (0x0D) } } } } Method (_INI, 0, NotSerialized) { Store (Zero, BTBL) } Method (INFO, 0, NotSerialized) { If (LEqual (_STA (), 0x0F)) { Store (BTF1, Local0) } Else { Store (BTF2, Local0) } Or (Local0, 0x08, Local0) Return (Local0) } Method (STAT, 0, NotSerialized) { Store (0x00, Local0) If (ABON) { Or (Local0, 0x02, Local0) } If (WLRF) { Or (Local0, 0x08, Local0) } If (ABON) { Or (Local0, 0x10, Local0) } If (BTBL) { Or (Local0, 0x80, Local0) } Return (Local0) } Method (CNTL, 2, NotSerialized) { If (And (Arg0, 0x02)) { If (LEqual (_STA (), 0x0F)) { If (And (Arg1, 0x02)) { Store (One, ABON) } Else { Store (Zero, ABON) } } } If (LAnd (And (Arg0, 0x08), WLEN)) { ShiftRight (And (Arg1, 0x08), 0x03, WLRF) } If (And (Arg0, 0x80)) { ShiftRight (And (Arg1, 0x80), 0x07, BTBL) If (BTBL) { If (WLSW) { Notify (CMBT, 0x81) } Else { Notify (CMBT, 0x82) } } } } Method (SWCF, 0, NotSerialized) { If (BTBL) { If (WLSW) { Notify (CMBT, 0x81) } Else { Notify (CMBT, 0x82) } } Else { If (WLSW) { If (BLEN) { Store (One, ABON) Store (One, ABLC) If (WLEN) { Store (One, WLRF) } Else { Store (Zero, WLRF) } } Else { Store (Zero, ABON) If (WLEN) { Store (One, WLRF) Store (One, ABLC) } Else { Store (Zero, WLRF) Store (Zero, ABLC) } } } Else { Store (Zero, ABON) Store (Zero, WLRF) Store (Zero, ABLC) } } } Method (BPTS, 1, NotSerialized) { If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { Store (WLRF, BTST) Or (ShiftLeft (WLSW, 0x01), BTST, BTST) Or (ShiftLeft (ABON, 0x02), BTST, BTST) } Store (Zero, ABLC) Store (Zero, ABON) } Method (BWAK, 1, NotSerialized) { If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { Store (And (BTST, 0x01), WLRF) ShiftRight (And (BTST, 0x04), 0x02, ABON) If (LAnd (WLSW, LOr (WLRF, ABON))) { Store (One, ABLC) } If (LNotEqual (ShiftRight (And (BTST, 0x02), 0x01), WLSW)) { SWCF () } } } } Device (EC) { Name (_HID, EisaId ("PNP0C09")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0062, // Range Minimum 0x0062, // Range Maximum 0x01, // Alignment 0x01, // Length ) IO (Decode16, 0x0066, // Range Minimum 0x0066, // Range Maximum 0x01, // Alignment 0x01, // Length ) }) Name (_GPE, 0x17) Scope (\) { Name (ECOK, Zero) } Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x03)) { Store (Arg1, ECOK) } } OperationRegion (SMB, EmbeddedControl, 0x00, 0xFF) Scope (\) { Field (\_SB.PCI0.LPCB.EC.SMB, ByteAcc, Lock, Preserve) { Offset (0x04), ECCM, 8, ECD1, 8, ECD2, 8, ECD3, 8, Offset (0xF8), ECGM, 8, ECG1, 8, ECG2, 8, ECG3, 8 } } } Device (DMAC) { Name (_HID, EisaId ("PNP0200")) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x0081, // Range Minimum 0x0081, // Range Maximum 0x01, // Alignment 0x0F, // Length ) IO (Decode16, 0x00C0, // Range Minimum 0x00C0, // Range Maximum 0x01, // Alignment 0x20, // Length ) DMA (Compatibility, NotBusMaster, Transfer16, ) {4} }) } Device (TIME) { Name (_HID, EisaId ("PNP0100")) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {0} }) } Device (PIC) { Name (_HID, EisaId ("PNP0000")) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0020, // Range Minimum 0x0020, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00A0, // Range Minimum 0x00A0, // Range Maximum 0x01, // Alignment 0x02, // Length ) IRQNoFlags () {2} }) } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x01, // Alignment 0x02, // Length ) IRQNoFlags () {8} }) } Device (SPKR) { Name (_HID, EisaId ("PNP0800")) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0061, // Range Minimum 0x0061, // Range Maximum 0x01, // Alignment 0x01, // Length ) }) } Device (MATH) { Name (_HID, EisaId ("PNP0C04")) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x00F0, // Range Minimum 0x00F0, // Range Maximum 0x01, // Alignment 0x0F, // Length ) IRQNoFlags () {13} }) } Device (KBC) { Name (R101, 0x0303D041) Name (R106, 0x2003D041) Method (_HID, 0, NotSerialized) { If (SIDF) { Return (R101) } Else { Return (R106) } } Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, // Range Minimum 0x0060, // Range Maximum 0x01, // Alignment 0x01, // Length ) IO (Decode16, 0x0064, // Range Minimum 0x0064, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {1} }) } Device (PS2M) { Name (_HID, EisaId ("PNP0F13")) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (_CRS, ResourceTemplate () { IRQNoFlags () {12} }) } Device (FWH) { Name (_HID, EisaId ("INT0800")) Method (_STA, 0, NotSerialized) { If (FWHM) { Return (0x0F) } Else { Return (0x00) } } Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFFB00000, // Address Base 0x00100000, // Address Length ) }) } Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (_CID, 0x010CD041) Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x4000) Field (RCRB, DWordAcc, Lock, Preserve) { Offset (0x3404), HPAS, 2, , 5, HPAE, 1 } Method (_STA, 0, NotSerialized) { If (LGreaterEqual (\_SB.OSTP (), 0x08)) { If (HPAE) { Return (0x0F) } } Else { If (HPAE) { Return (0x0B) } } Return (0x00) } Method (_CRS, 0, Serialized) { If (HPAE) { CreateDWordField (BUF0, 0x04, HPT0) If (LEqual (HPAS, 0x01)) { Store (0xFED01000, HPT0) } If (LEqual (HPAS, 0x02)) { Store (0xFED02000, HPT0) } If (LEqual (HPAS, 0x03)) { Store (0xFED03000, HPT0) } } Return (BUF0) } } Scope (\_SB.PCI0.LPCB) { OperationRegion (LIOD, PCI_Config, 0x80, 0x0A) OperationRegion (MBAR, SystemMemory, 0xFED14000, 0x4000) Field (MBAR, DWordAcc, Lock, Preserve) { Offset (0xF08), , 4, C2SL, 1 } } Field (LIOD, AnyAcc, NoLock, Preserve) { CADR, 3, , 1, CBDR, 3, Offset (0x01), LPDR, 2, , 2, FDDR, 1, Offset (0x02), CALE, 1, CBLE, 1, LPLE, 1, FDLE, 1, Offset (0x08), GD2E, 1, , 3, GD2B, 12 } Name (TCOM, Package (0x08) { 0x03F8, 0x02F8, 0x0220, 0x0228, 0x0238, 0x02E8, 0x0338, 0x03E8 }) Name (TLPT, Package (0x03) { 0x0378, 0x0278, 0x03BC }) Name (TFDD, Package (0x02) { 0x03F0, 0x0370 }) Method (DENA, 3, Serialized) { If (LEqual (Arg0, 0x00)) { Store (Match (TCOM, MEQ, Arg1, MTR, 0x00, 0x00), Local0) If (LNotEqual (Local0, Ones)) { Store (Local0, CADR) Store (One, CALE) } } Else { If (LOr (LEqual (Arg0, 0x01), LEqual (Arg0, 0x02))) { Store (Match (TCOM, MEQ, Arg1, MTR, 0x00, 0x00), Local0) If (LNotEqual (Local0, Ones)) { Store (Local0, CBDR) Store (One, CBLE) } } Else { If (LEqual (Arg0, 0x03)) { Store (Match (TCOM, MEQ, Arg1, MTR, 0x00, 0x00), Local0) If (LNotEqual (Local0, Ones)) { Store (Local0, CBDR) Store (One, CBLE) ShiftRight (Arg2, 0x04, GD2B) Store (One, GD2E) } } Else { If (LOr (LEqual (Arg0, 0x04), LEqual (Arg0, 0x05))) { Store (Match (TLPT, MEQ, Arg1, MTR, 0x00, 0x00), Local0) If (LNotEqual (Local0, Ones)) { Store (Local0, LPDR) Store (One, LPLE) } } Else { If (LEqual (Arg0, 0x07)) { Store (Match (TFDD, MEQ, Arg1, MTR, 0x00, 0x00), Local0) If (LNotEqual (Local0, Ones)) { Store (Local0, FDDR) Store (One, FDLE) } } } } } } } Method (DDIS, 1, Serialized) { If (LEqual (Arg0, 0x00)) { Store (Zero, CALE) } Else { If (LOr (LEqual (Arg0, 0x01), LEqual (Arg0, 0x02))) { Store (Zero, CBLE) } Else { If (LEqual (Arg0, 0x03)) { Store (Zero, CBLE) Store (Zero, GD2E) } Else { If (LOr (LEqual (Arg0, 0x04), LEqual (Arg0, 0x05))) { Store (Zero, LPLE) } Else { If (LEqual (Arg0, 0x07)) { Store (Zero, FDLE) } } } } } } Field (SIO, ByteAcc, NoLock, Preserve) { SIID, 8, SIDT, 8 } IndexField (SIID, SIDT, ByteAcc, NoLock, Preserve) { , 3, FDCP, 1, Offset (0x01), , 2, PPP, 1, PPM, 1, Offset (0x02), , 3, U1P, 1, , 3, U2P, 1, Offset (0x04), PPEM, 2, Offset (0x0A), EFTM, 8, Offset (0x0C), U2MD, 6, Offset (0x20), FDA, 8, , 2, ETOS, 1, Offset (0x23), PPA, 8, U1A, 8, U2A, 8, PPD, 4, FDD, 4, PPI, 4, FDI, 4, U2I, 4, U1I, 4, Offset (0x2B), IRA, 8, IRD, 4 } Mutex (MTXS, 0x00) Method (ENTR, 0, NotSerialized) { Acquire (MTXS, 0xFFFF) Store (0x55, SIID) } Method (EXIT, 0, NotSerialized) { Store (0xAA, SIID) Release (MTXS) } Method (SETR, 5, NotSerialized) { ENTR () If (Arg3) { Subtract (FindSetRightBit (Arg3), One, Local0) } Else { Store (Zero, Local0) } If (Arg4) { Subtract (FindSetRightBit (Arg4), One, Local1) } Else { Store (0x0F, Local1) } If (LEqual (Arg0, 0x00)) { ShiftRight (Arg1, 0x02, U1A) Store (Local0, U1I) } Else { If (LEqual (Arg0, 0x01)) { ShiftRight (Arg1, 0x02, U2A) Store (Local0, U2I) } Else { If (LEqual (Arg0, 0x02)) { ShiftRight (Arg1, 0x02, U2A) Store (Local0, U2I) } Else { If (LEqual (Arg0, 0x03)) { ShiftRight (Arg1, 0x02, U2A) ShiftRight (Arg2, 0x03, IRA) Store (Local0, U2I) Store (Local1, IRD) } Else { If (LEqual (Arg0, 0x04)) { ShiftRight (Arg1, 0x02, PPA) Store (Local0, PPI) } Else { If (LEqual (Arg0, 0x05)) { ShiftRight (Arg1, 0x02, PPA) Store (Local0, PPI) Store (Local1, PPD) } Else { If (LEqual (Arg0, 0x07)) { ShiftRight (Arg1, 0x02, FDA) Store (Local0, FDI) Store (Local1, FDD) } } } } } } } EXIT () If (Arg1) { If (CondRefOf (DENA, Local0)) { DENA (Arg0, Arg1, Arg2) } SETM (Arg0) } Else { If (CondRefOf (DDIS, Local0)) { DDIS (Arg0) } } } Method (GETR, 5, NotSerialized) { ENTR () Store (Zero, Local0) Store (0x0F, Local1) If (LEqual (Arg0, 0x00)) { ShiftLeft (U1A, 0x02, Arg1) Store (U1I, Local0) } Else { If (LEqual (Arg0, 0x01)) { ShiftLeft (U2A, 0x02, Arg1) Store (U2I, Local0) } Else { If (LEqual (Arg0, 0x02)) { ShiftLeft (U2A, 0x02, Arg1) Store (U2I, Local0) } Else { If (LEqual (Arg0, 0x03)) { ShiftLeft (U2A, 0x02, Arg1) ShiftLeft (IRA, 0x03, Arg2) Store (U2I, Local0) Store (IRD, Local1) } Else { If (LEqual (Arg0, 0x04)) { ShiftLeft (PPA, 0x02, Arg1) Store (PPI, Local0) } Else { If (LEqual (Arg0, 0x05)) { ShiftLeft (PPA, 0x02, Arg1) Store (PPI, Local0) Store (PPD, Local1) } Else { If (LEqual (Arg0, 0x07)) { ShiftLeft (FDA, 0x02, Arg1) Store (FDI, Local0) Store (FDD, Local1) } } } } } } } If (Local0) { ShiftLeft (One, Local0, Arg3) } Else { Store (Zero, Arg3) } If (LNotEqual (Local1, 0x0F)) { ShiftLeft (One, Local1, Arg4) } Else { Store (Zero, Arg4) } EXIT () } Method (SETM, 1, NotSerialized) { ENTR () If (LEqual (Arg0, 0x00)) { Store (One, U1P) } Else { If (LEqual (Arg0, 0x01)) { Store (0x06, U2MD) Store (One, U2P) } Else { If (LEqual (Arg0, 0x02)) { Store (0x0E, U2MD) Store (One, U2P) } Else { If (LEqual (Arg0, 0x03)) { Store (0x0E, U2MD) Store (One, U2P) } Else { If (LEqual (Arg0, 0x04)) { If (LEqual (PPF, One)) { Store (One, PPM) } Else { Store (Zero, PPM) Store (Zero, PPEM) } Store (One, PPP) } Else { If (LEqual (Arg0, 0x05)) { Store (Zero, PPM) Store (0x02, PPEM) Store (One, PPP) } } } } } } EXIT () } Method (SETP, 2, NotSerialized) { ENTR () If (LEqual (Arg0, 0x00)) { Store (Arg1, U1P) } Else { If (LEqual (Arg0, 0x01)) { Store (Arg1, U2P) } Else { If (LEqual (Arg0, 0x02)) { Store (Arg1, U2P) } Else { If (LEqual (Arg0, 0x03)) { Store (Arg1, U2P) } Else { If (LEqual (Arg0, 0x04)) { Store (Arg1, PPP) } Else { If (LEqual (Arg0, 0x05)) { Store (Arg1, PPP) } } } } } } EXIT () } Method (GETP, 1, NotSerialized) { Store (Zero, Local0) ENTR () If (LEqual (Arg0, 0x00)) { Store (U1P, Local0) } Else { If (LEqual (Arg0, 0x01)) { Store (U2P, Local0) } Else { If (LEqual (Arg0, 0x02)) { Store (U2P, Local0) } Else { If (LEqual (Arg0, 0x03)) { Store (U2P, Local0) } Else { If (LEqual (Arg0, 0x04)) { Store (PPP, Local0) } Else { If (LEqual (Arg0, 0x05)) { Store (PPP, Local0) } } } } } } EXIT () Return (Local0) } Method (CHKM, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { If (SPAF) { Return (One) } } Else { If (LEqual (Arg0, 0x01)) { If (LEqual (SPBF, 0x03)) { Return (One) } } Else { If (LEqual (Arg0, 0x02)) { If (LEqual (SPBF, One)) { Return (One) } } Else { If (LEqual (Arg0, 0x03)) { If (LEqual (SPBF, 0x02)) { Return (One) } } Else { If (LEqual (Arg0, 0x04)) { If (LOr (LEqual (PPF, One), LEqual (PPF, 0x02))) { Return (One) } } Else { If (LEqual (Arg0, 0x05)) { If (LEqual (PPF, 0x03)) { Return (One) } } Else { If (LEqual (Arg0, 0x07)) { If (FDCF) { Return (One) } } } } } } } } Return (Zero) } Device (UAR1) { Name (_HID, EisaId ("PNP0501")) Name (_UID, 0x01) Name (RSRC, ResourceTemplate () { IO (Decode16, 0x03F8, // Range Minimum 0x03F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} }) Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x01) { IO (Decode16, 0x03F8, // Range Minimum 0x03F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, // Range Minimum 0x03E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, // Range Minimum 0x02E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} } EndDependentFn () }) Method (_STA, 0, NotSerialized) { If (CHKM (0x00)) { GETR (0x00, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) If (Local0) { Return (0x0F) } Else { Return (0x0D) } } Else { Return (0x00) } } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x02, IO11) CreateWordField (RSRC, 0x04, IO12) CreateWordField (RSRC, 0x09, IRQ1) GETR (0x00, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) Store (Local0, IO11) Store (Local0, IO12) Store (Local2, IRQ1) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x04, IO11) CreateWordField (Arg0, 0x09, IRQ1) SETR (0x00, IO11, Zero, IRQ1, Zero) } Method (_DIS, 0, NotSerialized) { SETR (0x00, Zero, Zero, Zero, Zero) } Method (_INI, 0, NotSerialized) { If (CHKM (0x00)) { SETM (0x00) } } } Device (UAR2) { Name (_HID, EisaId ("PNP0501")) Name (_UID, 0x02) Name (RSRC, ResourceTemplate () { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} }) Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x03F8, // Range Minimum 0x03F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} } StartDependentFn (0x00, 0x01) { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, // Range Minimum 0x03E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, // Range Minimum 0x02E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} } EndDependentFn () }) Method (_STA, 0, NotSerialized) { If (CHKM (0x01)) { GETR (0x01, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) If (Local0) { Return (0x0F) } Else { Return (0x0D) } } Else { Return (0x00) } } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x02, IO11) CreateWordField (RSRC, 0x04, IO12) CreateWordField (RSRC, 0x09, IRQ1) GETR (0x01, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) Store (Local0, IO11) Store (Local0, IO12) Store (Local2, IRQ1) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x04, IO11) CreateWordField (Arg0, 0x09, IRQ1) SETR (0x01, IO11, Zero, IRQ1, Zero) } Method (_DIS, 0, NotSerialized) { SETR (0x01, Zero, Zero, Zero, Zero) } Method (_INI, 0, NotSerialized) { If (CHKM (0x01)) { SETM (0x01) } } } Device (IRDA) { Name (_HID, EisaId ("PNP0510")) Name (RSRC, ResourceTemplate () { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} }) Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x03F8, // Range Minimum 0x03F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} } StartDependentFn (0x00, 0x01) { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, // Range Minimum 0x03E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, // Range Minimum 0x02E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} } EndDependentFn () }) Method (_STA, 0, NotSerialized) { If (CHKM (0x02)) { GETR (0x02, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) If (Local0) { Return (0x0F) } Else { Return (0x0D) } } Else { Return (0x00) } } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x02, IO11) CreateWordField (RSRC, 0x04, IO12) CreateWordField (RSRC, 0x09, IRQ1) GETR (0x02, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) Store (Local0, IO11) Store (Local0, IO12) Store (Local2, IRQ1) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x04, IO11) CreateWordField (Arg0, 0x09, IRQ1) SETR (0x02, IO11, Zero, IRQ1, Zero) } Method (_DIS, 0, NotSerialized) { SETR (0x02, Zero, Zero, Zero, Zero) } Method (_INI, 0, NotSerialized) { If (CHKM (0x02)) { SETM (0x02) } } Method (_PSC, 0, NotSerialized) { If (GETP (0x02)) { Return (Zero) } Else { Return (0x03) } } Method (_PS0, 0, NotSerialized) { SETP (0x02, One) } Method (_PS3, 0, NotSerialized) { SETR (0x02, Zero, Zero, Zero, Zero) SETP (0x02, Zero) } } Device (FIR) { Name (_HID, EisaId ("SMCF010")) Name (RSRC, ResourceTemplate () { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x06F8, // Range Minimum 0x06F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} DMA (Compatibility, NotBusMaster, Transfer8, ) {} }) Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x03F8, // Range Minimum 0x03F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x07F8, // Range Minimum 0x07F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} } StartDependentFn (0x00, 0x01) { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x06F8, // Range Minimum 0x06F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, // Range Minimum 0x03E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x07E8, // Range Minimum 0x07E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, // Range Minimum 0x02E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x06E8, // Range Minimum 0x06E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3} } EndDependentFn () DMA (Compatibility, NotBusMaster, Transfer8, ) {1,3} }) Method (_STA, 0, NotSerialized) { If (CHKM (0x03)) { GETR (0x03, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) If (Local0) { Return (0x0F) } Else { Return (0x0D) } } Else { Return (0x00) } } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x02, IO11) CreateWordField (RSRC, 0x04, IO12) CreateWordField (RSRC, 0x0A, IO21) CreateWordField (RSRC, 0x0C, IO22) CreateWordField (RSRC, 0x11, IRQ1) CreateByteField (RSRC, 0x14, DMA1) GETR (0x03, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) Store (Local0, IO11) Store (Local0, IO12) Store (Local1, IO21) Store (Local1, IO22) Store (Local2, IRQ1) Store (Local3, DMA1) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x04, IO11) CreateWordField (Arg0, 0x0C, IO21) CreateWordField (Arg0, 0x11, IRQ1) CreateByteField (Arg0, 0x14, DMA1) SETR (0x03, IO11, IO21, IRQ1, DMA1) } Method (_DIS, 0, NotSerialized) { SETR (0x03, Zero, Zero, Zero, Zero) } Method (_INI, 0, NotSerialized) { If (CHKM (0x03)) { SETM (0x03) } } Method (_PSC, 0, NotSerialized) { If (GETP (0x03)) { Return (Zero) } Else { Return (0x03) } } Method (_PS0, 0, NotSerialized) { SETP (0x03, One) } Method (_PS3, 0, NotSerialized) { SETR (0x03, Zero, Zero, Zero, Zero) SETP (0x03, Zero) } } Device (LPT) { Name (_HID, EisaId ("PNP0400")) Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0778, // Range Minimum 0x0778, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {7} }) Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x01) { IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0778, // Range Minimum 0x0778, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {7} } StartDependentFnNoPri () { IO (Decode16, 0x0278, // Range Minimum 0x0278, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0678, // Range Minimum 0x0678, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {7} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, // Range Minimum 0x03BC, // Range Maximum 0x01, // Alignment 0x04, // Length ) IO (Decode16, 0x07BC, // Range Minimum 0x07BC, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {7} } StartDependentFn (0x00, 0x01) { IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0778, // Range Minimum 0x0778, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {5} } StartDependentFnNoPri () { IO (Decode16, 0x0278, // Range Minimum 0x0278, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0678, // Range Minimum 0x0678, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {5} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, // Range Minimum 0x03BC, // Range Maximum 0x01, // Alignment 0x04, // Length ) IO (Decode16, 0x07BC, // Range Minimum 0x07BC, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {5} } EndDependentFn () }) Method (_STA, 0, NotSerialized) { If (CHKM (0x04)) { GETR (0x04, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) If (Local0) { Return (0x0F) } Else { Return (0x0D) } } Else { Return (0x00) } } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x02, IO11) CreateWordField (RSRC, 0x04, IO12) CreateByteField (RSRC, 0x07, IO1L) CreateWordField (RSRC, 0x0A, IO21) CreateWordField (RSRC, 0x0C, IO22) CreateWordField (RSRC, 0x11, IRQ1) GETR (0x04, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) Store (Local0, IO11) Store (Local0, IO12) If (LEqual (Local0, 0x03BC)) { Store (0x04, IO1L) } Else { Store (0x08, IO1L) } Add (Local0, 0x0400, IO21) Store (IO21, IO22) Store (Local2, IRQ1) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x04, IO11) CreateWordField (Arg0, 0x11, IRQ1) SETR (0x04, IO11, Zero, IRQ1, Zero) } Method (_DIS, 0, NotSerialized) { SETR (0x04, Zero, Zero, Zero, Zero) } Method (_INI, 0, NotSerialized) { If (CHKM (0x04)) { SETM (0x04) } } } Device (ECP) { Name (_HID, EisaId ("PNP0401")) Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0778, // Range Minimum 0x0778, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {7} DMA (Compatibility, NotBusMaster, Transfer8, ) {} }) Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x01) { IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0778, // Range Minimum 0x0778, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {7} } StartDependentFnNoPri () { IO (Decode16, 0x0278, // Range Minimum 0x0278, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0678, // Range Minimum 0x0678, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {7} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, // Range Minimum 0x03BC, // Range Maximum 0x01, // Alignment 0x04, // Length ) IO (Decode16, 0x07BC, // Range Minimum 0x07BC, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {7} } StartDependentFn (0x00, 0x01) { IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0778, // Range Minimum 0x0778, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {5} } StartDependentFnNoPri () { IO (Decode16, 0x0278, // Range Minimum 0x0278, // Range Maximum 0x01, // Alignment 0x08, // Length ) IO (Decode16, 0x0678, // Range Minimum 0x0678, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {5} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, // Range Minimum 0x03BC, // Range Maximum 0x01, // Alignment 0x04, // Length ) IO (Decode16, 0x07BC, // Range Minimum 0x07BC, // Range Maximum 0x01, // Alignment 0x04, // Length ) IRQNoFlags () {5} } EndDependentFn () DMA (Compatibility, NotBusMaster, Transfer8, ) {1,3} }) Method (_STA, 0, NotSerialized) { If (CHKM (0x05)) { GETR (0x05, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) If (Local0) { Return (0x0F) } Else { Return (0x0D) } } Else { Return (0x00) } } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x02, IO11) CreateWordField (RSRC, 0x04, IO12) CreateByteField (RSRC, 0x07, IO1L) CreateWordField (RSRC, 0x0A, IO21) CreateWordField (RSRC, 0x0C, IO22) CreateWordField (RSRC, 0x11, IRQ1) CreateByteField (RSRC, 0x14, DMA1) GETR (0x05, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) Store (Local0, IO11) Store (Local0, IO12) If (LEqual (Local0, 0x03BC)) { Store (0x04, IO1L) } Else { Store (0x08, IO1L) } Add (Local0, 0x0400, IO21) Store (IO21, IO22) Store (Local2, IRQ1) Store (Local3, DMA1) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x04, IO11) CreateWordField (Arg0, 0x11, IRQ1) CreateByteField (Arg0, 0x14, DMA1) SETR (0x05, IO11, Zero, IRQ1, DMA1) } Method (_DIS, 0, NotSerialized) { SETR (0x05, Zero, Zero, Zero, Zero) } Method (_INI, 0, NotSerialized) { If (CHKM (0x05)) { SETM (0x05) } } } Device (FDC) { Name (_HID, EisaId ("PNP0700")) Name (RSRC, ResourceTemplate () { IO (Decode16, 0x03F0, // Range Minimum 0x03F0, // Range Maximum 0x01, // Alignment 0x06, // Length ) IO (Decode16, 0x03F7, // Range Minimum 0x03F7, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8, ) {2} }) Name (_PRS, ResourceTemplate () { IO (Decode16, 0x03F0, // Range Minimum 0x03F0, // Range Maximum 0x01, // Alignment 0x06, // Length ) IO (Decode16, 0x03F7, // Range Minimum 0x03F7, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8, ) {2} }) Method (_STA, 0, NotSerialized) { If (CHKM (0x07)) { GETR (0x07, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) If (Local0) { Return (0x0F) } Else { Return (0x0D) } } Else { Return (0x00) } } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x02, IO11) CreateWordField (RSRC, 0x04, IO12) CreateWordField (RSRC, 0x0A, IO21) CreateWordField (RSRC, 0x0C, IO22) CreateWordField (RSRC, 0x11, IRQ1) CreateByteField (RSRC, 0x14, DMA1) GETR (0x07, RefOf (Local0), RefOf (Local1), RefOf (Local2), RefOf (Local3)) Store (Local0, IO11) Store (Local0, IO12) Add (Local0, 0x07, IO21) Store (IO21, IO22) Store (Local2, IRQ1) Store (Local3, DMA1) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x04, IO11) CreateWordField (Arg0, 0x11, IRQ1) CreateByteField (Arg0, 0x14, DMA1) SETR (0x07, IO11, Zero, IRQ1, DMA1) } Method (_DIS, 0, NotSerialized) { SETR (0x07, Zero, Zero, Zero, Zero) } Method (_FDE, 0, NotSerialized) { If (FDS0) { Store (0x01, Index (FDEB, 0x00)) } If (FDS1) { Store (0x01, Index (FDEB, 0x04)) } Return (FDEB) } Name (FDEB, Buffer (0x14) { /* 0000 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }) Device (DRV0) { Name (_ADR, 0x00) Method (_STA, 0, NotSerialized) { If (FDS0) { Store (0x0F, Local7) } Else { Store (0x00, Local7) } Return (Local7) } Method (_FDI, 0, NotSerialized) { If (LOr (FDS1, LNotEqual (FDS0, 0x04))) { MKFP (FDS0) } Return (FPPK) } } Device (DRV1) { Name (_ADR, 0x01) Method (_STA, 0, NotSerialized) { If (FDS1) { Store (0x0F, Local7) } Else { Store (0x00, Local7) } Return (Local7) } Method (_FDI, 0, NotSerialized) { MKFP (FDS1) Return (FPPK) } } Method (MKFP, 1, NotSerialized) { If (LEqual (Arg0, 0x01)) { Store (FP5D, FPBF) } Else { If (LEqual (Arg0, 0x02)) { Store (FP5H, FPBF) } Else { If (LEqual (Arg0, 0x03)) { Store (FP3D, FPBF) } Else { If (LEqual (Arg0, 0x04)) { Store (FP3H, FPBF) } Else { If (LEqual (Arg0, 0x06)) { Store (FP3E, FPBF) } } } } } If (FDS1) { Store (0x02, Index (FPBF, 0x00)) } Store (0x00, Local0) While (LGreater (0x10, Local0)) { Store (DerefOf (Index (FPBF, Local0)), Index (FPPK, Local0)) Increment (Local0) } } Name (FPPK, Package (0x10) { 0x01, 0x04, 0x4F, 0x12, 0x01, 0xDF, 0x02, 0x25, 0x02, 0x12, 0x1B, 0xFF, 0x6C, 0xF6, 0x0F, 0x05 }) Name (FPBF, Buffer (0x10) {}) Name (FP5D, Buffer (0x10) { /* 0000 */ 0x01, 0x01, 0x27, 0x09, 0x01, 0xDF, 0x02, 0x25, /* 0008 */ 0x02, 0x09, 0x2A, 0xFF, 0x50, 0xF6, 0x0F, 0x06 }) Name (FP5H, Buffer (0x10) { /* 0000 */ 0x01, 0x02, 0x4F, 0x0F, 0x01, 0xDF, 0x04, 0x25, /* 0008 */ 0x02, 0x0F, 0x1B, 0xFF, 0x54, 0xF6, 0x0F, 0x06 }) Name (FP3D, Buffer (0x10) { /* 0000 */ 0x01, 0x03, 0x4F, 0x09, 0x01, 0xEF, 0x02, 0x25, /* 0008 */ 0x02, 0x09, 0x1B, 0xFF, 0x50, 0xF6, 0x0F, 0x05 }) Name (FP3H, Buffer (0x10) { /* 0000 */ 0x01, 0x04, 0x4F, 0x12, 0x01, 0xDF, 0x02, 0x25, /* 0008 */ 0x02, 0x12, 0x1B, 0xFF, 0x6C, 0xF6, 0x0F, 0x05 }) Name (FP3E, Buffer (0x10) { /* 0000 */ 0x01, 0x06, 0x4F, 0x24, 0x01, 0xAA, 0x08, 0x25, /* 0008 */ 0x02, 0x24, 0x1B, 0xFF, 0x54, 0xF6, 0x0F, 0x05 }) } Scope (\_SB.PCI0.LPCB.UAR1) { Name (_PRW, Package (0x02) { 0x08, 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (Zero, RI1M) } Else { Store (One, RI1M) } } } Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x01) Method (_DIS, 0, Serialized) { Store (0x80, PARC) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {1,3,4,5,6,7,10,12,14,15} }) Method (_CRS, 0, Serialized) { Name (RTLA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {} }) CreateWordField (RTLA, 0x01, IRQ0) Store (Zero, IRQ0) ShiftLeft (0x01, And (PARC, 0x0F), IRQ0) Return (RTLA) } Method (_SRS, 1, Serialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Store (Local0, PARC) } Method (_STA, 0, Serialized) { If (And (PARC, 0x80)) { Return (0x09) } Else { Return (0x0B) } } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Method (_DIS, 0, Serialized) { Store (0x80, PBRC) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {1,3,4,5,6,7,11,12,14,15} }) Method (_CRS, 0, Serialized) { Name (RTLB, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {} }) CreateWordField (RTLB, 0x01, IRQ0) Store (Zero, IRQ0) ShiftLeft (0x01, And (PBRC, 0x0F), IRQ0) Return (RTLB) } Method (_SRS, 1, Serialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Store (Local0, PBRC) } Method (_STA, 0, Serialized) { If (And (PBRC, 0x80)) { Return (0x09) } Else { Return (0x0B) } } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Method (_DIS, 0, Serialized) { Store (0x80, PCRC) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {1,3,4,5,6,7,10,12,14,15} }) Method (_CRS, 0, Serialized) { Name (RTLC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {} }) CreateWordField (RTLC, 0x01, IRQ0) Store (Zero, IRQ0) ShiftLeft (0x01, And (PCRC, 0x0F), IRQ0) Return (RTLC) } Method (_SRS, 1, Serialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Store (Local0, PCRC) } Method (_STA, 0, Serialized) { If (And (PCRC, 0x80)) { Return (0x09) } Else { Return (0x0B) } } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Method (_DIS, 0, Serialized) { Store (0x80, PDRC) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {1,3,4,5,6,7,11,12,14,15} }) Method (_CRS, 0, Serialized) { Name (RTLD, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {} }) CreateWordField (RTLD, 0x01, IRQ0) Store (Zero, IRQ0) ShiftLeft (0x01, And (PDRC, 0x0F), IRQ0) Return (RTLD) } Method (_SRS, 1, Serialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Store (Local0, PDRC) } Method (_STA, 0, Serialized) { If (And (PDRC, 0x80)) { Return (0x09) } Else { Return (0x0B) } } } Device (LNKE) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Method (_DIS, 0, Serialized) { Store (0x80, PERC) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {1,3,4,5,6,7,10,12,14,15} }) Method (_CRS, 0, Serialized) { Name (RTLE, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {} }) CreateWordField (RTLE, 0x01, IRQ0) Store (Zero, IRQ0) ShiftLeft (0x01, And (PERC, 0x0F), IRQ0) Return (RTLE) } Method (_SRS, 1, Serialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Store (Local0, PERC) } Method (_STA, 0, Serialized) { If (And (PERC, 0x80)) { Return (0x09) } Else { Return (0x0B) } } } Device (LNKF) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x06) Method (_DIS, 0, Serialized) { Store (0x80, PFRC) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {1,3,4,5,6,7,11,12,14,15} }) Method (_CRS, 0, Serialized) { Name (RTLF, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {} }) CreateWordField (RTLF, 0x01, IRQ0) Store (Zero, IRQ0) ShiftLeft (0x01, And (PFRC, 0x0F), IRQ0) Return (RTLF) } Method (_SRS, 1, Serialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Store (Local0, PFRC) } Method (_STA, 0, Serialized) { If (And (PFRC, 0x80)) { Return (0x09) } Else { Return (0x0B) } } } Device (LNKG) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Method (_DIS, 0, Serialized) { Store (0x80, PGRC) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {1,3,4,5,6,7,10,12,14,15} }) Method (_CRS, 0, Serialized) { Name (RTLG, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {} }) CreateWordField (RTLG, 0x01, IRQ0) Store (Zero, IRQ0) ShiftLeft (0x01, And (PGRC, 0x0F), IRQ0) Return (RTLG) } Method (_SRS, 1, Serialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Store (Local0, PGRC) } Method (_STA, 0, Serialized) { If (And (PGRC, 0x80)) { Return (0x09) } Else { Return (0x0B) } } } Device (LNKH) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Method (_DIS, 0, Serialized) { Store (0x80, PHRC) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {3,4,5,6,7,11,12,14,15} }) Method (_CRS, 0, Serialized) { Name (RTLH, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {} }) CreateWordField (RTLH, 0x01, IRQ0) Store (Zero, IRQ0) ShiftLeft (0x01, And (PHRC, 0x0F), IRQ0) Return (RTLH) } Method (_SRS, 1, Serialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Store (Local0, PHRC) } Method (_STA, 0, Serialized) { If (And (PHRC, 0x80)) { Return (0x09) } Else { Return (0x0B) } } } Method (PRCF, 0, NotSerialized) { If (B2TC) { Store (One, BY2O) } Else { Store (Zero, BY2O) } } } Device (PATA) { Name (_ADR, 0x001F0001) Name (PMMN, Buffer (0x28) {}) Name (PSMN, Buffer (0x28) {}) OperationRegion (ATIO, SystemIO, 0x01F7, 0x01) Field (ATIO, ByteAcc, NoLock, Preserve) { STSR, 8 } OperationRegion (PCI, PCI_Config, 0x40, 0x18) Field (PCI, ByteAcc, NoLock, Preserve) { PTI0, 1, PIE0, 1, PPP0, 1, PDT0, 1, PTI1, 1, PIE1, 1, PPP1, 1, PDT1, 1, PRCT, 2, , 2, PISP, 2, PSIT, 1, PIDE, 1, Offset (0x04), PRC1, 2, PIS1, 2, Offset (0x08), PSD0, 1, PSD1, 1, Offset (0x0A), PCT0, 2, , 2, PCT1, 2, Offset (0x14), PCB0, 1, PCB1, 1, , 2, PMCC, 1, PSCC, 1, , 6, FPC0, 1, FPC1, 1, Offset (0x16), PSMD, 2 } Device (PRIM) { Name (_ADR, 0x00) Device (MAST) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Name (GTFB, Buffer (0x15) { /* 0000 */ 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x03, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0xA0, 0xF5 }) CreateByteField (GTFB, 0x01, SPIO) CreateByteField (GTFB, 0x08, SDMA) CreateByteField (GTFB, 0x14, SCMD) If (LNot (SSUP ())) { Store (0x00, SCMD) } If (LNot (PIE0)) { Store (0x01, SPIO) } Else { If (LOr (PDT0, LNot (PTI0))) { Store (0x08, SPIO) } Else { If (LLess (Add (PISP, PRCT), 0x03)) { Store (0x0A, SPIO) } Else { If (LLess (Add (PISP, PRCT), 0x05)) { Store (0x0B, SPIO) } Else { Store (0x0C, SPIO) } } } } If (PSD0) { If (And (FPC0, PMCC)) { Store (0x45, SDMA) } Else { If (And (PCB0, PMCC)) { If (LEqual (PCT0, 0x02)) { Store (0x44, SDMA) } Else { Store (0x43, SDMA) } } Else { If (LEqual (PCT0, 0x02)) { Store (0x42, SDMA) } Else { If (LEqual (PCT0, 0x01)) { Store (0x41, SDMA) } Else { Store (0x40, SDMA) } } } } } Else { If (LLess (Add (PISP, PRCT), 0x05)) { Store (0x21, SDMA) } Else { Store (0x22, SDMA) } } Return (GTFB) } } Device (SLAV) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Name (GTFB, Buffer (0x15) { /* 0000 */ 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF, 0x03, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0xB0, 0xF5 }) CreateByteField (GTFB, 0x01, SPIO) CreateByteField (GTFB, 0x08, SDMA) CreateByteField (GTFB, 0x14, SCMD) If (LNot (SSUP ())) { Store (0x00, SCMD) } If (LNot (PIE1)) { Store (0x01, SPIO) } Else { If (LOr (PDT1, LNot (PTI1))) { Store (0x08, SPIO) } Else { If (PSIT) { If (LLess (Add (PIS1, PRC1), 0x03)) { Store (0x0A, SPIO) } Else { If (LLess (Add (PIS1, PRC1), 0x05)) { Store (0x0B, SPIO) } Else { Store (0x0C, SPIO) } } } Else { If (LLess (Add (PISP, PRCT), 0x03)) { Store (0x0A, SPIO) } Else { If (LLess (Add (PISP, PRCT), 0x05)) { Store (0x0B, SPIO) } Else { Store (0x0C, SPIO) } } } } } If (PSD1) { If (And (FPC1, PSCC)) { Store (0x45, SDMA) } Else { If (And (PCB1, PSCC)) { If (LEqual (PCT1, 0x02)) { Store (0x44, SDMA) } Else { Store (0x43, SDMA) } } Else { If (LEqual (PCT1, 0x02)) { Store (0x42, SDMA) } Else { If (LEqual (PCT1, 0x01)) { Store (0x41, SDMA) } Else { Store (0x40, SDMA) } } } } } Else { If (PSIT) { If (LLess (Add (PIS1, PRC1), 0x05)) { Store (0x21, SDMA) } Else { Store (0x22, SDMA) } } Else { If (LLess (Add (PISP, PRCT), 0x05)) { Store (0x21, SDMA) } Else { Store (0x22, SDMA) } } } Return (GTFB) } } Method (_GTM, 0, NotSerialized) { Name (GTMB, Buffer (0x14) {}) CreateDWordField (GTMB, 0x00, PIO0) CreateDWordField (GTMB, 0x04, DMA0) CreateDWordField (GTMB, 0x08, PIO1) CreateDWordField (GTMB, 0x0C, DMA1) CreateDWordField (GTMB, 0x10, FLAG) Store (0x10, FLAG) Or (FLAG, Or (ShiftLeft (PIE1, 0x03), ShiftLeft (PIE0, 0x01 )), FLAG) If (LOr (PDT0, LNot (PTI0))) { Store (0x0384, PIO0) } Else { Multiply (Subtract (0x09, Add (PRCT, PISP)), 0x1E, PIO0) } If (LNot (PSD0)) { Store (PIO0, DMA0) } Else { Or (FLAG, 0x01, FLAG) If (And (FPC0, PMCC)) { Store (0x14, DMA0) } Else { If (And (PCB0, PMCC)) { Multiply (Subtract (0x04, PCT0), 0x0F, DMA0) } Else { Multiply (Subtract (0x04, PCT0), 0x1E, DMA0) } } } If (LOr (PDT1, LNot (PTI1))) { Store (0x0384, PIO1) } Else { If (LNot (PSIT)) { Store (PIO0, PIO1) } Else { Multiply (Subtract (0x09, Add (PRC1, PIS1)), 0x1E, PIO1) } } If (LNot (PSD1)) { Store (PIO1, DMA1) } Else { Or (FLAG, 0x04, FLAG) If (And (FPC1, PSCC)) { Store (0x14, DMA1) } Else { If (And (PCB1, PSCC)) { Multiply (Subtract (0x04, PCT1), 0x0F, DMA1) } Else { Multiply (Subtract (0x04, PCT1), 0x1E, DMA1) } } } Return (GTMB) } Method (_STM, 3, NotSerialized) { CreateDWordField (Arg0, 0x00, PIO0) CreateDWordField (Arg0, 0x04, DMA0) CreateDWordField (Arg0, 0x08, PIO1) CreateDWordField (Arg0, 0x0C, DMA1) CreateDWordField (Arg0, 0x10, FLAG) Store (0x00, PSIT) If (LAnd (MSMF (), LEqual (SizeOf (Arg1), 0x0200))) { CreateField (Arg1, 0x01B0, 0x0140, MBUF) Store (MBUF, PMMN) CreateWordField (Arg1, 0x62, W490) CreateWordField (Arg1, 0x66, W510) CreateWordField (Arg1, 0x6A, W530) CreateWordField (Arg1, 0x7C, W620) CreateWordField (Arg1, 0x7E, W630) CreateWordField (Arg1, 0x80, W640) CreateWordField (Arg1, 0xB0, W880) Store (0x00, PISP) Store (0x00, PRCT) Store (0x00, PDT0) Store (0x00, PIE0) Store (0x00, PTI0) Store (0x00, PSD0) Store (0x00, PCT0) Store (0x00, PCB0) Store (0x00, PMCC) Store (0x00, FPC0) If (LAnd (And (FLAG, 0x02), And (W490, 0x0800))) { Store (0x01, PIE0) } If (LAnd (LLessEqual (PIO0, 0x78), LAnd (And (W530, 0x02 ), And (W640, 0x02)))) { Store (0x02, PISP) Store (0x03, PRCT) Store (0x01, PTI0) } Else { If (LAnd (LLessEqual (PIO0, 0xB4), LAnd (And (W530, 0x02 ), And (W640, 0x01)))) { Store (0x02, PISP) Store (0x01, PRCT) Store (0x01, PTI0) } Else { If (LAnd (LLessEqual (PIO0, 0xF0), LGreaterEqual (W510, 0x0200))) { Store (0x01, PISP) Store (0x01, PTI0) } Else { Noop } } } If (LNotEqual (DMA0, 0xFFFFFFFF)) { If (LAnd (And (FLAG, 0x01), LAnd (And (W530, 0x04 ), And (W880, 0x3F)))) { Store (0x01, PSD0) If (LAnd (LLessEqual (DMA0, 0x14), And (W880, 0x20))) { Store (0x01, PCT0) Store (0x01, PMCC) Store (0x01, FPC0) } Else { If (LAnd (LLessEqual (DMA0, 0x1E), And (W880, 0x10))) { Store (0x02, PCT0) Store (0x01, PMCC) Store (0x01, PCB0) } Else { If (LAnd (LLessEqual (DMA0, 0x2D), And (W880, 0x08))) { Store (0x01, PCT0) Store (0x01, PMCC) Store (0x01, PCB0) } Else { If (LAnd (LLessEqual (DMA0, 0x3C), And (W880, 0x04))) { Store (0x02, PCT0) } Else { If (LAnd (LLessEqual (DMA0, 0x5A), And (W880, 0x02))) { Store (0x01, PCT0) } Else { Noop } } } } } } Else { If (LAnd (LLessEqual (DMA0, 0x78), And (W630, 0x04))) { Store (0x02, PISP) Store (0x03, PRCT) Store (0x01, PTI0) } Else { If (LAnd (LLessEqual (DMA0, 0xB4), And (W630, 0x02))) { Store (0x02, PISP) Store (0x01, PRCT) Store (0x01, PTI0) } Else { Noop } } } } } If (LAnd (SSMF (), LEqual (SizeOf (Arg2), 0x0200))) { CreateField (Arg2, 0x01B0, 0x0140, SBUF) Store (SBUF, PSMN) CreateWordField (Arg2, 0x62, W491) CreateWordField (Arg2, 0x66, W511) CreateWordField (Arg2, 0x6A, W531) CreateWordField (Arg2, 0x7C, W621) CreateWordField (Arg2, 0x7E, W631) CreateWordField (Arg2, 0x80, W641) CreateWordField (Arg2, 0xB0, W881) Store (0x00, PIS1) Store (0x00, PRC1) Store (0x00, PDT1) Store (0x00, PIE1) Store (0x00, PTI1) Store (0x00, PSD1) Store (0x00, PCT1) Store (0x00, PCB1) Store (0x00, PSCC) Store (0x00, FPC1) If (LAnd (And (FLAG, 0x08), And (W491, 0x0800))) { Store (0x01, PIE1) } If (LAnd (And (FLAG, 0x10), LAnd (LNotEqual (PIO1, 0xFFFFFFFF), LNotEqual (PIO1, PIO0)))) { Store (0x01, PSIT) If (LAnd (LLessEqual (PIO1, 0x78), LAnd (And (W531, 0x02 ), And (W641, 0x02)))) { Store (0x02, PIS1) Store (0x03, PRC1) Store (0x01, PTI1) } Else { If (LAnd (LLessEqual (PIO1, 0xB4), LAnd (And (W531, 0x02 ), And (W641, 0x01)))) { Store (0x02, PIS1) Store (0x01, PRC1) Store (0x01, PTI1) } Else { If (LAnd (LLessEqual (PIO1, 0xF0), LGreaterEqual (W511, 0x0200))) { Store (0x01, PIS1) Store (0x01, PTI1) } Else { Noop } } } } If (LNotEqual (DMA1, 0xFFFFFFFF)) { If (LAnd (And (FLAG, 0x04), LAnd (And (W531, 0x04 ), And (W881, 0x3F)))) { Store (0x01, PSD1) If (LAnd (LLessEqual (DMA1, 0x14), And (W881, 0x20))) { Store (0x01, PCT1) Store (0x01, PSCC) Store (0x01, FPC1) } Else { If (LAnd (LLessEqual (DMA1, 0x1E), And (W881, 0x10))) { Store (0x02, PCT1) Store (0x01, PSCC) Store (0x01, PCB1) } Else { If (LAnd (LLessEqual (DMA1, 0x2D), And (W881, 0x08))) { Store (0x01, PCT1) Store (0x01, PSCC) Store (0x01, PCB1) } Else { If (LAnd (LLessEqual (DMA1, 0x3C), And (W881, 0x04))) { Store (0x02, PCT1) } Else { If (LAnd (LLessEqual (DMA1, 0x5A), And (W881, 0x02))) { Store (0x01, PCT1) } Else { Noop } } } } } } Else { If (LAnd (And (FLAG, 0x10), LNotEqual (DMA1, DMA0))) { Store (0x01, PSIT) If (LAnd (LLessEqual (DMA1, 0x78), And (W631, 0x04))) { Store (0x02, PIS1) Store (0x03, PRC1) Store (0x01, PTI1) } Else { If (LAnd (LLessEqual (DMA1, 0xB4), And (W631, 0x02))) { Store (0x02, PIS1) Store (0x01, PRC1) Store (0x01, PTI1) } Else { Noop } } } } } } Store (0x01, PIDE) } } Scope (\_SB.PCI0.PATA.PRIM) { Method (_STA, 0, NotSerialized) { If (CPBL) { Return (0x00) } Else { Return (0x0F) } } Method (MSMF, 0, NotSerialized) { Return (\_SB.PCI0.PATA.PRIM.MAST._STA ()) } Method (SSMF, 0, NotSerialized) { Return (0x00) } } Scope (\_SB.PCI0.PATA.PRIM.MAST) { Method (_STA, 0, NotSerialized) { If (CPBL) { Return (0x00) } Else { If (LAnd (\_SB.PCI0.PATA.PRIM.MAST.BIDE (), LAnd (BRST, BY1O))) { Return (0x0F) } Else { Return (0x00) } } } Method (SSUP, 0, NotSerialized) { Return (LEqual (BY1I, 0x0A)) } Method (BIDE, 0, NotSerialized) { Store (BY1I, Local0) Store (LEqual (Local0, 0x08), Local1) Or (LEqual (Local0, 0x0A), Local1, Local1) Or (LEqual (Local0, 0x0B), Local1, Local1) Or (LEqual (Local0, 0x0D), Local1, Local1) Return (Local1) } Method (_EJ0, 1, NotSerialized) { BOFF () Return (Zero) } Method (BON, 0, NotSerialized) { Store (Zero, BRST) Store (Zero, PIE0) Store (0x02, PSMD) If (LEqual (BY1C, Zero)) { Sleep (0x64) Store (BY1I, Local0) If (LNotEqual (Local0, 0x01)) { Store (One, BY1O) If (LEqual (BY1I, 0x0A)) { Sleep (0x32) } Sleep (0x46) Store (Zero, PSMD) Store (0x01, PIDE) Store (0x01, PSD0) Store (0x01, PMCC) Store (0x01, FPC0) And (BOPT, 0xFE, BOPT) And (BHDD, 0xFE, BHDD) If (LEqual (Local0, 0x08)) { Or (BOPT, One, BOPT) } If (LEqual (Local0, 0x0A)) { Or (BHDD, One, BHDD) } If (LEqual (Local0, 0x0B)) { Or (BOPT, One, BOPT) } If (LEqual (Local0, 0x0D)) { Or (BOPT, One, BOPT) } Sleep (0x1E) Store (One, BRST) Sleep (0x64) Store (Zero, Local1) While (LAnd (LAnd (And (STSR, 0x80), B1TC), LLess (Local1, 0x015E))) { Sleep (0x64) Add (Local1, 0x01, Local1) } } } } Method (BOFF, 0, NotSerialized) { Store (Zero, BRST) And (BOPT, 0xFE, BOPT) And (BHDD, 0xFE, BHDD) Sleep (0x1E) TMCL () Store (0x02, PSMD) Sleep (0x46) Store (Zero, BY1O) Sleep (0x64) } Method (TMCL, 0, NotSerialized) { Store (0x00, PIDE) Store (0x00, PISP) Store (0x00, PRCT) Store (0x00, PDT0) Store (0x00, PIE0) Store (0x00, PTI0) Store (0x00, PSD0) Store (0x00, PCT0) Store (0x00, PCB0) Store (0x00, PMCC) Store (0x00, FPC0) Store (0x01, PIDE) } } Scope (\_SB.PCI0.PATA.PRIM.SLAV) { Method (_STA, 0, NotSerialized) { Return (0x00) } Method (SSUP, 0, NotSerialized) { Return (0x00) } } } Device (SATA) { Name (_ADR, 0x001F0002) } Device (USB1) { Name (_ADR, 0x001D0000) } Device (USB2) { Name (_ADR, 0x001D0001) } Device (USB3) { Name (_ADR, 0x001D0002) Device (HUB3) { Name (_ADR, 0x00) Device (PRT1) { Name (_EJD, "\\_SB.PCI0.RP02.PXS2") Name (_ADR, 0x01) } } } Device (USB4) { Name (_ADR, 0x001D0003) } Device (USB7) { Name (_ADR, 0x001D0007) Device (HUB7) { Name (_ADR, 0x00) Device (PRT5) { Name (_ADR, 0x05) Name (_EJD, "\\_SB.PCI0.RP02.PXS2") } } } Device (SBUS) { Name (_ADR, 0x001F0003) } Device (AUD0) { Name (_ADR, 0x001E0002) } Device (MODM) { Name (_ADR, 0x001E0003) Name (_PRW, Package (0x02) { 0x05, 0x03 }) } Device (HDEF) { Name (_ADR, 0x001B0000) Name (_PRW, Package (0x02) { 0x05, 0x03 }) Name (_PSC, 0x00) Method (_PS0, 0, NotSerialized) { Store (0x00, _PSC) If (LAnd (HDWA, LGreaterEqual (\_SB.OSTP (), 0x40))) { Store (Zero, HDWA) Sleep (0x01F4) } } Method (_PS3, 0, NotSerialized) { Store (0x03, _PSC) } } Device (RP01) { Name (_ADR, 0x001C0000) OperationRegion (P1CS, PCI_Config, 0x40, 0x0100) Field (P1CS, AnyAcc, NoLock, WriteAsZeros) { Offset (0x1A), ABP1, 1, , 2, PDC1, 1, , 2, PDS1, 1, Offset (0x20), Offset (0x22), PSP1, 1, Offset (0x9C), , 30, HPCS, 1, PMCS, 1 } Device (PXS1) { Name (_ADR, 0x00) } Method (_PRT, 0, NotSerialized) { If (\GPIC) { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x11 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x13 } }) } Else { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPCB.LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPCB.LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPCB.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPCB.LNKD, 0x00 } }) } } } Device (RP02) { Name (_ADR, 0x001C0001) OperationRegion (P2CS, PCI_Config, 0x40, 0x0100) Field (P2CS, AnyAcc, NoLock, WriteAsZeros) { Offset (0x1A), ABP2, 1, , 2, PDC2, 1, , 2, PDS2, 1, Offset (0x20), Offset (0x22), PSP2, 1, Offset (0x9C), , 30, HPCS, 1, PMCS, 1 } Device (PXS2) { Name (_ADR, 0x00) } Method (_PRT, 0, NotSerialized) { If (\GPIC) { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x11 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x13 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x10 } }) } Else { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPCB.LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPCB.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPCB.LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPCB.LNKA, 0x00 } }) } } } Device (RP03) { Name (_ADR, 0x001C0002) OperationRegion (P3CS, PCI_Config, 0x40, 0x0100) Field (P3CS, AnyAcc, NoLock, WriteAsZeros) { Offset (0x1A), ABP3, 1, , 2, PDC3, 1, , 2, PDS3, 1, Offset (0x20), Offset (0x22), PSP3, 1, Offset (0x9C), , 30, HPCS, 1, PMCS, 1 } Device (PXS3) { Name (_ADR, 0x00) } Method (_PRT, 0, NotSerialized) { If (\GPIC) { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x13 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x10 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x11 } }) } Else { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPCB.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPCB.LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPCB.LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPCB.LNKB, 0x00 } }) } } } Scope (\_SB.PCI0.RP01.PXS1) { Name (_PRW, Package (0x02) { 0x09, 0x04 }) } Scope (\_SB.PCI0.RP02.PXS2) { Name (_EJD, "\\_SB.PCI0.USB7.HUB7.PRT5") Method (_STA, 0, NotSerialized) { If (PXRS) { Return (0x0F) } Else { Return (0x00) } } Name (_PRW, Package (0x02) { 0x09, 0x04 }) Method (_RMV, 0, NotSerialized) { Return (One) } Method (EXIN, 0, NotSerialized) { Sleep (0x64) Store (Zero, PXCL) Sleep (0x01) Store (One, PXRS) Store (Zero, EXPL) } Method (EXRM, 0, NotSerialized) { Store (Zero, PXRS) Store (One, PXCL) Store (One, EXPL) } } } Scope (\) { Name (WBTN, Zero) Name (NGTM, Zero) Name (LSBL, Zero) Name (BNBF, Buffer (0x20) {}) Name (BNSP, Zero) Name (BNGP, Zero) Name (BNCT, Zero) } Device (FEXT) { Name (_HID, "FUJ02E3") Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_INI, 0, NotSerialized) { Store (Zero, BNSP) Store (Zero, BNGP) Store (Zero, BNCT) Store (Zero, IRBC) Store (Zero, IRBF) } Method (FUNC, 4, Serialized) { Store (0x80000000, Local0) If (LEqual (Arg0, 0x1001)) { Store (S001 (Arg1, Arg2, Arg3), Local0) } Else { If (LEqual (Arg0, 0x1002)) { Store (S002 (Arg1, Arg2, Arg3), Local0) } Else { If (LEqual (Arg0, 0x1004)) { Store (S004 (Arg1, Arg2, Arg3), Local0) } } } If (LEqual (Arg0, 0x1005)) { Store (S005 (Arg1, Arg2, Arg3), Local0) } If (LEqual (Arg0, 0x1006)) { Store (S006 (Arg1, Arg2, Arg3), Local0) } If (LEqual (Arg0, 0x1008)) { Store (S008 (Arg1, Arg2, Arg3), Local0) } Return (Local0) } Method (S001, 3, NotSerialized) { Store (0x80000000, Local0) If (LEqual (Arg0, Zero)) { Store (LEDI, Local0) } Else { If (LEqual (Arg0, One)) { And (Arg2, 0x03, Local1) If (LAnd (And (Arg1, LEDI), Local1)) { Store (0x9B, CMD) ShiftRight (And (Arg2, 0x00030000), 0x08, DVID) Store (Zero, SSMI) } Store (Zero, Local0) } Else { If (LEqual (Arg0, 0x02)) { If (And (Arg1, LEDI)) { Store (0x9B, CMD) Store (One, DVID) Store (Zero, SSMI) Or (ShiftLeft (DVID, 0x10), One, Local0) } Else { Store (Zero, Local0) } } } } Return (Local0) } Method (S002, 3, NotSerialized) { Store (0x80000000, Local0) If (LEqual (Arg0, Zero)) { Store (BTNI, Local0) } Else { If (LEqual (Arg0, One)) { Store (GIRB (), Local0) } Else { If (LEqual (Arg0, 0x02)) { Store (0x9B, CMD) Store (0x02, DVID) Store (Zero, SSMI) Store (DVID, Local0) } Else { If (LEqual (Arg0, 0x03)) { If (Arg1) { Not (Arg1, Local1) And (Arg2, Arg1, Local2) Or (And (WBTN, Local1), Local2, WBTN) Store (0x9B, CMD) Or (ShiftLeft (WBTN, 0x08), 0x03, DVID) Store (Zero, SSMI) } Store (WBTN, Local0) } } } } Return (Local0) } Method (SIRB, 1, NotSerialized) { If (LLess (BNCT, 0x10)) { CreateWordField (BNBF, BNSP, BNP1) Store (Arg0, BNP1) Increment (BNCT) Add (BNSP, 0x02, BNSP) If (LGreaterEqual (BNSP, 0x20)) { Store (Zero, BNSP) } } } Method (GIRB, 0, NotSerialized) { If (BNCT) { CreateWordField (BNBF, BNGP, BNP2) Store (BNP2, Local0) Or (Local0, 0x40000000, Local0) Decrement (BNCT) Add (BNGP, 0x02, BNGP) If (LGreaterEqual (BNGP, 0x20)) { Store (Zero, BNGP) } } Else { Store (Zero, Local0) } Return (Local0) } Method (S004, 3, NotSerialized) { Store (0x80000000, Local0) If (LEqual (Arg0, Zero)) { Store (NGTI, Local0) } Else { If (LEqual (Arg0, One)) { If (LAnd (LEqual (Arg1, 0x04), And (NGTI, 0x04))) { And (Arg2, 0x03, Local1) If (LOr (LEqual (Local1, 0x03), LEqual (Local1, 0x02))) { If (LNot (NGTF)) { SVBL () Store (One, NGTF) } SBLC (Local1) Store (Local1, NGTM) Store (Zero, Local0) } If (LNot (Local1)) { If (NGTF) { Store (Zero, NGTF) RSBL () SBLC (Zero) } Store (Zero, NGTM) Store (Zero, Local0) } } } Else { If (LEqual (Arg0, 0x02)) { If (LAnd (LEqual (Arg1, 0x04), And (NGTI, 0x04))) { Store (NGTM, Local0) } } } } Return (Local0) } Method (S008, 3, NotSerialized) { Store (0x80000000, Local0) If (LEqual (Arg0, 0x00)) { If (LAnd (LGreaterEqual (Arg1, 0x00), LLessEqual (Arg1, 0x05))) { If (LEqual (Arg1, Zero)) { Store (Zero, Local0) } Else { If (LEqual (Arg1, One)) { If (LGreaterEqual (\_SB.OSTP (), 0x40)) { Store (0x02, Local0) } Else { Store (Zero, Local0) } } Else { Store (0xA4, CMD) Store (Arg0, QAG1) Store (Arg1, QAG2) Store (Arg2, QAG3) Store (Zero, DVID) Store (Zero, SSMI) Store (DVID, Local0) } } } } Else { If (LEqual (Arg0, 0x01)) { If (LAnd (LGreaterEqual (Arg1, 0x00), LLessEqual (Arg1, 0x01))) { Store (0xA4, CMD) Store (Arg0, QAG1) Store (Arg1, QAG2) Store (Arg2, QAG3) Store (Zero, DVID) Store (Zero, SSMI) Store (DVID, Local0) } } Else { If (LEqual (Arg0, 0x02)) { If (LAnd (LGreaterEqual (Arg1, 0x00), LLessEqual (Arg1, 0x01))) { Store (0xA4, CMD) Store (Arg0, QAG1) Store (Arg1, QAG2) Store (Arg2, QAG3) Store (Zero, DVID) Store (Zero, SSMI) Store (DVID, Local0) } } Else { If (LEqual (Arg0, 0x03)) { If (LEqual (Arg1, 0x00)) { Store (0xA4, CMD) Store (Arg0, QAG1) Store (Arg1, QAG2) Store (Arg2, QAG3) Store (Zero, DVID) Store (Zero, SSMI) Store (DVID, Local0) } } Else { If (LEqual (Arg0, 0x04)) { If (LAnd (LGreaterEqual (Arg1, 0x00), LLessEqual (Arg1, 0x01))) { Store (0xA4, CMD) Store (Arg0, QAG1) Store (Arg1, QAG2) Store (Arg2, QAG3) Store (Zero, DVID) Store (Zero, SSMI) Store (DVID, Local0) } } } } } } Return (Local0) } } Scope (\_SB.FEXT) { Method (SBLC, 1, NotSerialized) { If (LNot (Arg0)) { Store (Zero, BLCT) } Else { If (LEqual (Arg0, 0x03)) { Store (One, BLCT) } Else { If (LEqual (Arg0, 0x02)) { Name (BBCT, Buffer (BLLM) {}) Store (BLLT, BBCT) CreateByteField (BBCT, Zero, BLL0) Store (BLL0, LCDB) Store (0x01000000, DVID) Or (DVID, BLL0, DVID) Store (0x82, CMD) Store (Zero, SSMI) Store (Zero, BLCT) } } } } Method (SVBL, 0, NotSerialized) { And (\_SB.PCI0.LPCB.FJEX.GBLL (), 0x7FFFFFFF, LSBL) } Method (RSBL, 0, NotSerialized) { \_SB.PCI0.LPCB.FJEX.SBLL (LSBL) } Method (S005, 3, NotSerialized) { Store (0x80000000, Local0) If (LEqual (Arg0, Zero)) { If (CPBL) { Store (And (DPCI, Not (One)), Local0) } Else { Store (DPCI, Local0) } } Else { If (LEqual (Arg0, One)) { If (And (Arg1, One)) { If (And (Arg2, One)) { If (\_SB.PCI0.PATA.PRIM.MAST.BIDE ()) { \_SB.PCI0.PATA.PRIM.MAST.BOFF () } Or (DPCS, One, DPCS) } Else { If (\_SB.PCI0.PATA.PRIM.MAST.BIDE ()) { \_SB.PCI0.PATA.PRIM.MAST.BON () } And (DPCS, 0xFFFFFFFE, DPCS) } Notify (\_SB.PCI0.PATA.PRIM.MAST, One) } And (DPCS, DPCI, Local0) } } Return (Local0) } Method (S006, 3, NotSerialized) { Store (0x80000000, Local0) If (ECOK) { If (LEqual (Arg0, Zero)) { Store (ECCI, Local0) } Else { If (LEqual (Arg0, 0x10)) { If (Arg1) { And (Arg1, 0xFF, ECG1) Store (0x23, ECGM) Store (Zero, Local1) While (LAnd (ECGM, LLess (Local1, 0x64))) { Sleep (0x01) Increment (Local1) } If (LGreaterEqual (Local1, 0x64)) { Store (0x80000001, Local0) } Else { Or (ShiftLeft (ECG2, 0x08), ECG3, Local0) } } Else { Store (0xFD70, Local0) } } Else { If (LEqual (Arg0, 0x11)) { And (Arg1, 0xFF, ECG1) ShiftRight (And (Arg2, 0xFF00), 0x08, ECG2) And (Arg2, 0xFF, ECG3) Store (0x22, ECGM) Store (Zero, Local1) While (LAnd (ECGM, LLess (Local1, 0x64))) { Sleep (0x01) Increment (Local1) } If (LGreaterEqual (Local1, 0x64)) { Store (0x80000001, Local0) } Else { Store (Zero, Local0) } } Else { If (LEqual (Arg0, 0x12)) { Store (GINT, Local0) Store (Zero, GINT) } Else { If (LEqual (Arg0, 0x20)) { ShiftRight (And (Arg1, 0xFF000000), 0x18, ECD3) ShiftRight (And (Arg1, 0x00FF0000), 0x10, ECD2) ShiftRight (And (Arg1, 0xFF00), 0x08, ECD1) And (Arg1, 0xFF, ECCM) Store (Zero, Local1) While (LAnd (ECCM, LLess (Local1, 0x64))) { Sleep (0x01) Increment (Local1) } If (LGreaterEqual (Local1, 0x64)) { Store (0x80000001, Local0) } Else { Or (Or (ShiftLeft (ECD3, 0x10), ShiftLeft (ECD2, 0x08) ), ECD1, Local0) } } } } } } } Return (Local0) } } Device (LID) { Name (_HID, EisaId ("PNP0C0D")) Method (_LID, 0, NotSerialized) { If (CVCL) { Return (Zero) } Else { Return (One) } } Name (_PRW, Package (0x02) { 0x18, 0x04 }) Method (_PSW, 1, NotSerialized) { Noop } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) Method (_STA, 0, NotSerialized) { Return (0x0F) } } Device (AC) { Name (_HID, "ACPI0003") Scope (\) { Name (ACPS, Ones) } Method (_INI, 0, NotSerialized) { Store (ACPW, ACPS) } Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_PSR, 0, NotSerialized) { _INI () If (ACPW) { Return (One) } Else { Return (Zero) } } Name (_PCL, Package (0x01) { \_SB }) Method (ACHK, 0, NotSerialized) { Store (ACPW, Local0) If (LNotEqual (Local0, ACPS)) { Sleep (0x28) Notify (\_SB.AC, 0x80) Store (Zero, DVID) Store (0x8D, CMD) Store (Zero, SSMI) Notify (\_PR.CPU0, 0x80) Store (Local0, ACPS) } } } Device (CMB1) { Name (_HID, EisaId ("PNP0C0A")) Name (_UID, One) Name (_PCL, Package (0x01) { \_SB }) Scope (\) { Name (B1PS, Ones) Name (B1RS, Ones) Name (B1CS, Ones) Name (B1LS, Ones) Name (BIF1, Package (0x0D) { 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01, "", "1", "LION", "Fujitsu" }) Name (BST1, Package (0x04) {}) } Method (MKWD, 2, NotSerialized) { If (And (Arg1, 0x80)) { Or (0xFFFF0000, Arg0, Local0) Or (Local0, ShiftLeft (Arg1, 0x08), Local0) Subtract (Zero, Local0, Local0) } Else { Store (Arg0, Local0) Or (Local0, ShiftLeft (Arg1, 0x08), Local0) } Return (Local0) } Method (_INI, 0, NotSerialized) { Store (B1P, B1PS) Store (B1CP, B1RS) Store (B1C, B1CS) Store (MKWD (B1LL, B1LH), B1LS) } Method (_BIF, 0, NotSerialized) { Name (BUFF, Buffer (0x0C) {}) Store (B1NO, Local5) CreateByteField (BIDT, B1ID, B1IX) Store (MKWD (B1DL, B1DH), Index (BIF1, 0x01)) Store (MKWD (B1LL, B1LH), Index (BIF1, 0x02)) Store (Multiply (Add (And (B1DV, 0xEF), 0x02), 0x0E10 ), Index (BIF1, 0x04)) If (LGreaterEqual (\_SB.OSTP (), 0x40)) { Divide (Multiply (Add (Multiply (0x0C, 0x0A), 0x04), DerefOf ( Index (BIF1, 0x01))), 0x03E8, Local0, Index (BIF1, 0x05)) } If (LGreaterEqual (\_SB.OSTP (), 0x40)) { If (LEqual (BIFL, 0xFF)) { Store (0x0A, Local1) } Else { Store (BIFL, Local1) } Divide (Multiply (Add (Multiply (Local1, 0x0A), 0x04), DerefOf ( Index (BIF1, 0x01))), 0x03E8, Local0, Index (BIF1, 0x06)) } If (Local5) { Store (DerefOf (Index (BMST, B1IX)), BUFF) Store (0x07, Local0) Store (Local5, Local2) While (LAnd (Local2, LGreaterEqual (Local0, 0x02))) { Store (Subtract (DerefOf (Index (BUFF, Local0)), 0x30), Local1) Divide (Add (Local1, Local2), 0x0A, Local1, Local2) Store (Add (Local1, 0x30), Index (BUFF, Local0)) Decrement (Local0) } Store (BUFF, Index (BIF1, 0x09)) } Else { Store (DerefOf (Index (BMNT, B1IX)), Index (BIF1, 0x09)) } Return (BIF1) } Method (_BST, 0, NotSerialized) { _INI () Store (Zero, Local0) If (B1P) { If (B1C) { Or (Local0, 0x02, Local0) } Else { If (LNot (ACPS)) { Or (Local0, One, Local0) } } If (LLessEqual (B1CP, One)) { Or (Local0, 0x04, Local0) } } Store (MKWD (B1CL, B1CH), Local1) Divide (Multiply (B1CP, MKWD (B1LL, B1LH)), 0x03E8, Local4, Local2) If (Local4) { Increment (Local2) } Multiply (Local2, 0x0A, Local2) Store (MKWD (B1VL, B1VH), Local3) Store (Local0, Index (BST1, Zero)) Store (Local1, Index (BST1, One)) Store (Local2, Index (BST1, 0x02)) Store (Local3, Index (BST1, 0x03)) Return (BST1) } Method (_STA, 0, NotSerialized) { If (B1P) { Return (0x1F) } Return (0x0F) } Method (BCHK, 0, NotSerialized) { If (LNotEqual (B1P, B1PS)) { Notify (\_SB.CMB1, 0x81) Store (B1P, B1PS) } If (B1PS) { Store (MKWD (B1LL, B1LH), Local0) If (LNotEqual (Local0, B1LS)) { Notify (\_SB.CMB1, 0x81) } If (LOr (LNotEqual (B1C, B1CS), LNotEqual (B1CP, B1RS))) { Notify (\_SB.CMB1, 0x80) } Store (Local0, B1LS) Store (B1C, B1CS) Store (B1CP, B1RS) } } } Device (CMB2) { Name (_HID, EisaId ("PNP0C0A")) Name (_UID, 0x02) Name (_PCL, Package (0x01) { \_SB }) Scope (\) { Name (B2PS, Ones) Name (B2RS, Ones) Name (B2CS, Ones) Name (B2LS, Ones) Name (BIF2, Package (0x0D) { 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01, "", "2", "LION", "Fujitsu" }) Name (BST2, Package (0x04) {}) } Method (MKWD, 2, NotSerialized) { If (And (Arg1, 0x80)) { Or (0xFFFF0000, Arg0, Local0) Or (Local0, ShiftLeft (Arg1, 0x08), Local0) Subtract (Zero, Local0, Local0) } Else { Store (Arg0, Local0) Or (Local0, ShiftLeft (Arg1, 0x08), Local0) } Return (Local0) } Method (_INI, 0, NotSerialized) { Store (B2P, B2PS) Store (B2CP, B2RS) Store (B2C, B2CS) Store (MKWD (B2LL, B2LH), B2LS) } Method (_BIF, 0, NotSerialized) { Name (BUFF, Buffer (0x0C) {}) Store (B2NO, Local5) CreateByteField (BIDT, B2ID, B2IX) Store (MKWD (B2DL, B2DH), Index (BIF2, 0x01)) Store (MKWD (B2LL, B2LH), Index (BIF2, 0x02)) Store (Multiply (Add (And (B2DV, 0xEF), 0x02), 0x0E10 ), Index (BIF2, 0x04)) If (LGreaterEqual (\_SB.OSTP (), 0x40)) { Divide (Multiply (Add (Multiply (0x0C, 0x0A), 0x04), DerefOf ( Index (BIF2, 0x01))), 0x03E8, Local0, Index (BIF2, 0x05)) } If (LGreaterEqual (\_SB.OSTP (), 0x40)) { If (LEqual (BIFL, 0xFF)) { Store (0x0A, Local1) } Else { Store (BIFL, Local1) } Divide (Multiply (Add (Multiply (Local1, 0x0A), 0x04), DerefOf ( Index (BIF2, 0x01))), 0x03E8, Local0, Index (BIF2, 0x06)) } If (Local5) { Store (DerefOf (Index (BMST, B2IX)), BUFF) Store (0x07, Local0) Store (Local5, Local2) While (LAnd (Local2, LGreaterEqual (Local0, 0x02))) { Store (Subtract (DerefOf (Index (BUFF, Local0)), 0x30), Local1) Divide (Add (Local1, Local2), 0x0A, Local1, Local2) Store (Add (Local1, 0x30), Index (BUFF, Local0)) Decrement (Local0) } Store (BUFF, Index (BIF2, 0x09)) } Else { Store (DerefOf (Index (BMNT, B2IX)), Index (BIF2, 0x09)) } Return (BIF2) } Method (_BST, 0, NotSerialized) { _INI () Store (Zero, Local0) If (B2P) { If (B2C) { Or (Local0, 0x02, Local0) } Else { If (LNot (ACPS)) { Or (Local0, One, Local0) } } If (LLessEqual (B2CP, One)) { Or (Local0, 0x04, Local0) } } Store (MKWD (B2CL, B2CH), Local1) Divide (Multiply (B2CP, MKWD (B2LL, B2LH)), 0x03E8, Local4, Local2) If (Local4) { Increment (Local2) } Multiply (Local2, 0x0A, Local2) Store (MKWD (B2VL, B2VH), Local3) Store (Local0, Index (BST2, Zero)) Store (Local1, Index (BST2, One)) Store (Local2, Index (BST2, 0x02)) Store (Local3, Index (BST2, 0x03)) Return (BST2) } Method (_STA, 0, NotSerialized) { If (B2P) { Return (0x1F) } Return (0x0F) } Method (BCHK, 0, NotSerialized) { If (LNotEqual (B2P, B2PS)) { Notify (\_SB.CMB2, 0x81) Store (B2P, B2PS) } If (B2PS) { Store (MKWD (B2LL, B2LH), Local0) If (LNotEqual (Local0, B2LS)) { Notify (\_SB.CMB2, 0x81) } If (LOr (LNotEqual (B2C, B2CS), LNotEqual (B2CP, B2RS))) { Notify (\_SB.CMB2, 0x80) } Store (Local0, B2LS) Store (B2C, B2CS) Store (B2CP, B2RS) } } } Device (SLPB) { Name (_HID, EisaId ("PNP0C0E")) Method (_STA, 0, NotSerialized) { If (FSCM) { Return (0x0F) } Else { Return (0x00) } } } } Scope (_TZ) { ThermalZone (TZ00) { Method (_CRT, 0, Serialized) { Return (Add (0x0AAC, Multiply (CRTT, 0x0A))) } Method (_TMP, 0, Serialized) { If (DTSE) { Store (0x9C, CMD) Store (0x00, DVID) Store (Zero, SSMI) Return (Add (0x0AAC, Multiply (DTS1, 0x0A))) } Else { Return (0x0BB8) } } Method (_PSL, 0, Serialized) { If (MPEN) { Return (Package (0x02) { \_PR.CPU0, \_PR.CPU1 }) } Else { Return (Package (0x01) { \_PR.CPU0 }) } } Method (_PSV, 0, Serialized) { Return (Add (0x0AAC, Multiply (PSVT, 0x0A))) } Method (_TC1, 0, Serialized) { Return (TC1V) } Method (_TC2, 0, Serialized) { Return (TC2V) } Method (_TSP, 0, Serialized) { Return (TSPV) } } ThermalZone (TZ01) { Method (_CRT, 0, Serialized) { Return (Add (0x0AAC, Multiply (CRTT, 0x0A))) } Method (_TMP, 0, Serialized) { If (DTSE) { Store (0x9C, CMD) Store (0x01, DVID) Store (Zero, SSMI) Return (Add (0x0AAC, Multiply (DTS2, 0x0A))) } Else { Return (0x0BB8) } } Method (_PSL, 0, Serialized) { If (MPEN) { Return (Package (0x02) { \_PR.CPU0, \_PR.CPU1 }) } Else { Return (Package (0x01) { \_PR.CPU0 }) } } Method (_PSV, 0, Serialized) { Return (Add (0x0AAC, Multiply (PSVT, 0x0A))) } Method (_TC1, 0, Serialized) { Return (TC1V) } Method (_TC2, 0, Serialized) { Return (TC2V) } Method (_TSP, 0, Serialized) { Return (TSPV) } } } Scope (\) { Method (TZSM, 1, NotSerialized) { Store (0x9C, CMD) Store (Arg0, DVID) Store (Zero, SSMI) } } Scope (\_GPE) { Method (_L02, 0, NotSerialized) { Store (0x00, GPEC) Notify (\_TZ.TZ00, 0x80) Notify (\_TZ.TZ01, 0x80) } Method (_L05, 0, NotSerialized) { Notify (\_SB.PCI0.HDEF, 0x02) } Method (_L08, 0, NotSerialized) { } Method (_L09, 0, NotSerialized) { If (\_SB.PCI0.RP01.PSP1) { Store (0x01, \_SB.PCI0.RP01.PSP1) Store (0x01, \_SB.PCI0.RP01.PMCS) Notify (\_SB.PCI0.RP01, 0x02) } If (\_SB.PCI0.RP02.PSP2) { Store (0x01, \_SB.PCI0.RP02.PSP2) Store (0x01, \_SB.PCI0.RP02.PMCS) Notify (\_SB.PCI0.RP02, 0x02) } If (\_SB.PCI0.RP03.PSP3) { Store (0x01, \_SB.PCI0.RP03.PSP3) Store (0x01, \_SB.PCI0.RP03.PMCS) Notify (\_SB.PCI0.RP03, 0x02) } } Method (_L0B, 0, NotSerialized) { Notify (\_SB.PCI0.PCIB, 0x02) } Method (_L18, 0, NotSerialized) { Sleep (0xFA) If (LNot (LIDS)) { Store (0x97, CMD) Store (Zero, SSMI) } Not (LPOL, LPOL) Notify (\_SB.LID, 0x80) } Method (_L19, 0, NotSerialized) { Store (SSF0, Local0) Store (Local0, SSF0) And (Local0, Not (SSM0), Local0) Store (SSF1, Local1) Store (Local1, SSF1) And (Local1, Not (SSM1), Local1) Store (SSF2, Local2) Store (Local2, SSF2) And (Local2, Not (SSM2), Local2) If (And (Local2, 0x10)) { \_SB.AC.ACHK () \_SB.CMB1.BCHK () \_SB.CMB2.BCHK () If (LOr (LNotEqual (LWMD, PLWM), LNotEqual (TALM, PTAL))) { Store (LWMD, PLWM) Store (TALM, PTAL) Store (0x95, CMD) Or (PLWM, ShiftLeft (PTAL, 0x01), DVID) Store (Zero, SSMI) } If (LAnd (TALM, LNot (ACPW))) { Store (One, FOCT) } Else { Store (Zero, FOCT) } } If (And (Local0, 0x01)) { \_SB.PCI0.GFX0.PHTK () Store (0x80, CMD) Store (Zero, SSMI) \_SB.PCI0.GFX0.AHTK () If (BSWF) { If (LGreaterEqual (\_SB.OSTP (), 0x40)) { \_SB.PCI0.GFX0.LCD.BLNF () } } If (LOr (AHKF, VLBF)) { Notify (\_SB.PCI0.LPCB.FJEX, 0x80) } If (IRBF) { If (LEqual (IRBC, 0xFD00)) { Store (One, GINT) } Else { \_SB.FEXT.SIRB (IRBC) } Notify (\_SB.FEXT, 0x80) Store (Zero, IRBF) } } If (And (Local1, 0x30)) { \_SB.PCI0.LPCB.CMBT.SWCF () } If (And (Local2, 0x08)) { Store (B1SU, Local3) Store (B1SD, Local4) Store (TBSF, Local5) Store (B2SU, Local6) Store (B2SD, Local7) Store (Zero, STAE) If (LAnd (Local3, LNot (B1TC))) { If (LNot (CPBL)) { \_SB.PCI0.PATA.PRIM.MAST.BOFF () Notify (\_SB.PCI0.PATA.PRIM.MAST, One) } } If (Local5) { Store (0x00, TBSM) } If (LOr (LAnd (Local4, B1TC), Local5)) { If (LEqual (BY1I, 0x0C)) { Store (One, BY1O) } Else { If (LNot (Or (DPCS, CPBL))) { \_SB.PCI0.PATA.PRIM.MAST.BON () If (LAnd (LAnd (BRST, BY1O), B1TC)) { Notify (\_SB.PCI0.PATA.PRIM.MAST, One) } } } } If (LOr (Local6, Local7)) { Sleep (0x03E8) Store (Zero, B2SU) Store (Zero, B2SD) \_SB.PCI0.LPCB.PRCF () If (RPEN) { If (LNotEqual (B2TC, RPDS)) { Store (B2TC, RPDS) If (RPDS) { Notify (\_SB.REPL, Zero) } Else { Sleep (0x0FA0) Notify (\_SB.REPL, One) } } } } } } Method (_L1D, 0, NotSerialized) { If (EXPL) { \_SB.PCI0.RP02.PXS2.EXIN () } Else { \_SB.PCI0.RP02.PXS2.EXRM () } Sleep (0x64) Notify (\_SB.PCI0.RP02, Zero) } } Name (_S0, Package (0x04) { 0x00, 0x00, 0x00, 0x00 }) Name (_S3, Package (0x04) { 0x05, 0x05, 0x00, 0x00 }) Name (_S4, Package (0x04) { 0x06, 0x06, 0x00, 0x00 }) Name (_S5, Package (0x04) { 0x07, 0x07, 0x00, 0x00 }) Method (_PTS, 1, NotSerialized) { Add (0xDD, Arg0, PO80) If (LAnd (LGreaterEqual (Arg0, One), LLessEqual (Arg0, 0x04))) { If (LNot (CPBL)) { If (\_SB.PCI0.PATA.PRIM.MAST._STA ()) { Store (Zero, BYIS) } Else { Store (0xFF, BYIS) } } If (RPEN) { Store (RPDS, DC1S) } If (\_SB.PCI0.RP02.PXS2._STA ()) { Store (Zero, EXIS) } Else { Store (0xFF, EXIS) } } \_SB.PCI0.LPCB.CMBT.BPTS (Arg0) Store (Zero, WAPB) Store (One, HDWA) Add (0xE0, Arg0, PO80) } Method (_WAK, 1, NotSerialized) { Add (0xEE, Arg0, PO80) \_SB.PCI0.LPCB.AINI () \_SB.PCI0.PCIB._INI () \_SB.FEXT._INI () If (LEqual (Arg0, 0x03)) { Store (0xA3, CMD) Store (0x00, INF) Store (Zero, SSMI) } If (LEqual (Arg0, 0x03)) { Store (0x9B, CMD) Store (0x04, DVID) Store (Zero, SSMI) } If (WAPB) { Notify (\_SB.PWRB, 0x02) } If (LEqual (Arg0, 0x04)) { \_SB.FEXT.FUNC (0x1002, 0x03, Ones, WBTN) } \_SB.PCI0.LPCB.CMBT.BWAK (Arg0) If (LAnd (LGreaterEqual (Arg0, One), LLessEqual (Arg0, 0x04))) { If (LNot (CPBL)) { If (LEqual (BYIS, 0xFF)) { If (\_SB.PCI0.PATA.PRIM.MAST.BIDE ()) { If (DPCS) { \_SB.PCI0.PATA.PRIM.MAST.BOFF () } Else { If (LNot (\_SB.PCI0.PATA.PRIM.MAST._STA ())) { \_SB.PCI0.PATA.PRIM.MAST.BON () } If (LAnd (LAnd (BRST, BY1O), B1TC)) { Notify (\_SB.PCI0.PATA.PRIM.MAST, One) } } } } Else { If (LNot (\_SB.PCI0.PATA.PRIM.MAST._STA ())) { \_SB.PCI0.PATA.PRIM.MAST.TMCL () Notify (\_SB.PCI0.PATA.PRIM.MAST, One) } Else { If (LEqual (Arg0, 0x04)) { Store (0x87, CMD) Store (Zero, DVID) Store (Zero, SSMI) Name (BFMN, Buffer (0x28) {}) Store (PIID, BFMN) Store (Zero, Local0) Store (Zero, Local1) While (LAnd (LNot (Local0), LLess (Local1, 0x28))) { If (LEqual (DerefOf (Index (\_SB.PCI0.PATA.PMMN, Local1)), DerefOf (Index (BFMN, Local1)))) { Increment (Local1) } Else { Store (0x01, Local0) } } If (Local0) { \_SB.PCI0.PATA.PRIM.MAST.BOFF () Notify (\_SB.PCI0.PATA.PRIM.MAST, One) } } } If (LAnd (\_SB.PCI0.PATA.PRIM.MAST.BIDE (), LNot (\_SB.PCI0.PATA.PRIM.MAST._STA ()))) { Store (0x01, TBSM) Store (0x00, TBSF) Store (0x1E, TIMB) } } } \_SB.PCI0.LPCB.PRCF () If (RPEN) { If (LNotEqual (B2TC, DC1S)) { Store (B2TC, RPDS) If (RPDS) { Notify (\_SB.REPL, Zero) } Else { Notify (\_SB.REPL, One) } } } If (\_SB.PCI0.RP02.PXS2._STA ()) { If (EXIS) { Notify (\_SB.PCI0.RP02, Zero) } } Else { If (LNot (EXIS)) { Notify (\_SB.PCI0.RP02, Zero) } } If (NGTM) { \_SB.FEXT.FUNC (0x1004, 0x01, 0x04, 0x00) } } Add (0xF0, Arg0, PO80) Return (Zero) } Name (DC1S, Zero) Scope (_SB) { Device (REPL) { Name (_HID, EisaId ("PNP0C15")) Name (_BDN, 0x01) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { If (RPDS) { Return (0x0F) } Else { Return (0x00) } } Method (_DCK, 1, NotSerialized) { Return (One) } Method (_EJ0, 1, NotSerialized) { Store (Zero, Local0) While (LAnd (RPDS, LLess (Local0, 0x012C))) { Sleep (0x64) Add (Local0, 0x01, Local0) } } } } Scope (\_SB.PCI0.USB1) { Device (HUB1) { Name (_ADR, 0x00) Device (PRT1) { Name (_ADR, 0x01) } Device (PRT2) { Name (_ADR, 0x02) } } } Scope (\_SB.PCI0.USB2) { Device (HUB2) { Name (_ADR, 0x00) Device (PRT1) { Name (_ADR, 0x01) } Device (PRT2) { Name (_ADR, 0x02) Name (_EJD, "_SB.REPL") } } } Scope (\_SB.PCI0.USB3.HUB3) { Device (PRT2) { Name (_ADR, 0x02) } } Scope (\_SB.PCI0.USB4) { Device (HUB4) { Name (_ADR, 0x00) Device (PRT1) { Name (_ADR, 0x01) } Device (PRT2) { Name (_ADR, 0x02) } } } Scope (\_SB.PCI0.USB7.HUB7) { Device (PRT1) { Name (_ADR, 0x01) } Device (PRT2) { Name (_ADR, 0x02) } Device (PRT3) { Name (_ADR, 0x03) } Device (PRT4) { Name (_ADR, 0x04) Name (_EJD, "_SB.REPL") } Device (PRT6) { Name (_ADR, 0x06) } Device (PRT7) { Name (_ADR, 0x07) } Device (PRT8) { Name (_ADR, 0x08) } } Scope (\_SB.PCI0.LPCB.UAR1) { Name (_EJD, "_SB.REPL") } Scope (\_SB.PCI0.LPCB.LPT) { Name (_EJD, "_SB.REPL") } Scope (\_SB.PCI0.LPCB.ECP) { Name (_EJD, "_SB.REPL") } Scope (\) { Name (SSDT, Package (0x0C) { "CPU0IST ", 0x7F64EF21, 0x000001E8, "CPU1IST ", 0x7F64F319, 0x00000087, "CPU0CST ", 0x7F64F3A0, 0x000001D0, "CPU1CST ", 0x7F64F570, 0x00000085 }) Name (CFGD, 0x011B6971) Name (\PDC0, 0x80000000) Name (\PDC1, 0x80000000) Name (\SDTL, 0x00) } Scope (\_PR.CPU0) { Name (HI0, 0x00) Name (HC0, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS0, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS0, TEMP, Local2) _OSC (Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS0) CreateDWordField (Arg3, 0x04, CAP0) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID0, Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID0, 0x00, EID0) CreateDWordField (UID0, 0x04, EID1) CreateDWordField (UID0, 0x08, EID2) CreateDWordField (UID0, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS0, 0x00)) Return (Arg3) } If (LNotEqual (Arg1, 0x01)) { Store (0x0A, Index (STS0, 0x00)) Return (Arg3) } Or (And (PDC0, 0x7FFFFFFF), CAP0, PDC0) If (And (CFGD, 0x01)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (PDC0, 0x09), 0x09)), LNot (And (SDTL, 0x01)))) { Or (SDTL, 0x01, SDTL) OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02 ))) Load (IST0, HI0) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC0, 0x18 )), LNot (And (SDTL, 0x02)))) { Or (SDTL, 0x02, SDTL) OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08 ))) Load (CST0, HC0) } } Return (Arg3) } } Scope (\_PR.CPU1) { Name (HI1, 0x00) Name (HC1, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x00, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS1, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS1, TEMP, Local2) _OSC (Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, 0x00, STS1) CreateDWordField (Arg3, 0x04, CAP1) CreateDWordField (Arg0, 0x00, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID1, Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID1, 0x00, EID0) CreateDWordField (UID1, 0x04, EID1) CreateDWordField (UID1, 0x08, EID2) CreateDWordField (UID1, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS1, 0x00)) Return (Arg3) } If (LNotEqual (Arg1, 0x01)) { Store (0x0A, Index (STS1, 0x00)) Return (Arg3) } Or (And (PDC1, 0x7FFFFFFF), CAP1, PDC1) If (And (CFGD, 0x01)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (PDC1, 0x09), 0x09)), LNot (And (SDTL, 0x10)))) { Or (SDTL, 0x10, SDTL) OperationRegion (IST1, SystemMemory, DerefOf (Index (SSDT, 0x04)), DerefOf (Index (SSDT, 0x05 ))) Load (IST1, HI1) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC1, 0x18 )), LNot (And (SDTL, 0x20)))) { Or (SDTL, 0x20, SDTL) OperationRegion (CST1, SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B ))) Load (CST1, HC1) } } Return (Arg3) } } Scope (\_SB.PCI0.SATA) { Name (PMMN, Buffer (0x28) {}) OperationRegion (PCI, PCI_Config, 0x40, 0x18) Field (PCI, ByteAcc, NoLock, Preserve) { PTI0, 1, PIE0, 1, PPP0, 1, PDT0, 1, PTI1, 1, PIE1, 1, PPP1, 1, PDT1, 1, PRCT, 2, , 2, PISP, 2, PSIT, 1, PIDE, 1, Offset (0x04), PRC1, 2, PIS1, 2, Offset (0x08), PSD0, 1, PSD1, 1, Offset (0x0A), PCT0, 2, , 2, PCT1, 2, Offset (0x14), PCB0, 1, PCB1, 1, , 2, PMCC, 1, PSCC, 1, , 6, FPC0, 1, FPC1, 1, Offset (0x16), PSMD, 2 } Device (PRID) { Name (_ADR, 0x00) Device (P_D0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Name (GTFB, Buffer (0x15) { /* 0000 */ 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x03, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0xA0, 0xF5 }) CreateByteField (GTFB, 0x01, SPIO) CreateByteField (GTFB, 0x08, SDMA) If (LNot (PIE0)) { Store (0x01, SPIO) } Else { If (LOr (PDT0, LNot (PTI0))) { Store (0x08, SPIO) } Else { If (LLess (Add (PISP, PRCT), 0x03)) { Store (0x0A, SPIO) } Else { If (LLess (Add (PISP, PRCT), 0x05)) { Store (0x0B, SPIO) } Else { Store (0x0C, SPIO) } } } } If (PSD0) { If (And (FPC0, PMCC)) { Store (0x45, SDMA) } Else { If (And (PCB0, PMCC)) { If (LEqual (PCT0, 0x02)) { Store (0x44, SDMA) } Else { Store (0x43, SDMA) } } Else { If (LEqual (PCT0, 0x02)) { Store (0x42, SDMA) } Else { If (LEqual (PCT0, 0x01)) { Store (0x41, SDMA) } Else { Store (0x40, SDMA) } } } } } Else { If (LLess (Add (PISP, PRCT), 0x05)) { Store (0x21, SDMA) } Else { Store (0x22, SDMA) } } Return (GTFB) } Name (_PSC, 0x00) Method (_PS0, 0, NotSerialized) { Store (_PSC, Local0) Store (0x00, _PSC) If (LEqual (Local0, 0x03)) { Store (0x01, INF) While (INF) { Store (0x20, CMD) Store (Zero, SSMI) If (LAnd (LEqual (INF, 0x01), LGreaterEqual (\_SB.OSTP (), 0x04))) { Sleep (0x01F4) } } } } Method (_PS3, 0, NotSerialized) { Store (0x03, _PSC) } } Device (P_D1) { Name (_ADR, 0x01) Name (_GTF, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xF5 }) } Method (_GTM, 0, NotSerialized) { Name (GTMB, Buffer (0x14) {}) CreateDWordField (GTMB, 0x00, PIO0) CreateDWordField (GTMB, 0x04, DMA0) CreateDWordField (GTMB, 0x08, PIO1) CreateDWordField (GTMB, 0x0C, DMA1) CreateDWordField (GTMB, 0x10, FLAG) Store (0x10, FLAG) Or (FLAG, Or (ShiftLeft (PIE1, 0x03), ShiftLeft (PIE0, 0x01 )), FLAG) If (LOr (PDT0, LNot (PTI0))) { Store (0x0384, PIO0) } Else { Multiply (Subtract (0x09, Add (PRCT, PISP)), 0x1E, PIO0) } If (LNot (PSD0)) { Store (PIO0, DMA0) } Else { Or (FLAG, 0x01, FLAG) If (And (FPC0, PMCC)) { Store (0x14, DMA0) } Else { If (And (PCB0, PMCC)) { Multiply (Subtract (0x04, PCT0), 0x0F, DMA0) } Else { Multiply (Subtract (0x04, PCT0), 0x1E, DMA0) } } } If (LOr (PDT1, LNot (PTI1))) { Store (0x0384, PIO1) } Else { If (LNot (PSIT)) { Store (PIO0, PIO1) } Else { Multiply (Subtract (0x09, Add (PRC1, PIS1)), 0x1E, PIO1) } } If (LNot (PSD1)) { Store (PIO1, DMA1) } Else { Or (FLAG, 0x04, FLAG) If (And (FPC1, PSCC)) { Store (0x14, DMA1) } Else { If (And (PCB1, PSCC)) { Multiply (Subtract (0x04, PCT1), 0x0F, DMA1) } Else { Multiply (Subtract (0x04, PCT1), 0x1E, DMA1) } } } Return (GTMB) } Method (_STM, 3, NotSerialized) { CreateDWordField (Arg0, 0x00, PIO0) CreateDWordField (Arg0, 0x04, DMA0) CreateDWordField (Arg0, 0x08, PIO1) CreateDWordField (Arg0, 0x0C, DMA1) CreateDWordField (Arg0, 0x10, FLAG) Store (0x00, PSIT) If (LEqual (SizeOf (Arg1), 0x0200)) { CreateField (Arg1, 0x01B0, 0x0140, MBUF) Store (MBUF, PMMN) CreateWordField (Arg1, 0x62, W490) CreateWordField (Arg1, 0x66, W510) CreateWordField (Arg1, 0x6A, W530) CreateWordField (Arg1, 0x7C, W620) CreateWordField (Arg1, 0x7E, W630) CreateWordField (Arg1, 0x80, W640) CreateWordField (Arg1, 0xB0, W880) Store (0x00, PISP) Store (0x00, PRCT) Store (0x00, PDT0) Store (0x00, PIE0) Store (0x00, PTI0) Store (0x00, PSD0) Store (0x00, PCT0) Store (0x00, PCB0) Store (0x00, PMCC) Store (0x00, FPC0) If (LAnd (And (FLAG, 0x02), And (W490, 0x0800))) { Store (0x01, PIE0) } If (LAnd (LLessEqual (PIO0, 0x78), LAnd (And (W530, 0x02 ), And (W640, 0x02)))) { Store (0x02, PISP) Store (0x03, PRCT) Store (0x01, PTI0) } Else { If (LAnd (LLessEqual (PIO0, 0xB4), LAnd (And (W530, 0x02 ), And (W640, 0x01)))) { Store (0x02, PISP) Store (0x01, PRCT) Store (0x01, PTI0) } Else { If (LAnd (LLessEqual (PIO0, 0xF0), LGreaterEqual (W510, 0x0200))) { Store (0x01, PISP) Store (0x01, PTI0) } Else { Noop } } } If (LNotEqual (DMA0, 0xFFFFFFFF)) { If (LAnd (And (FLAG, 0x01), LAnd (And (W530, 0x04 ), And (W880, 0x3F)))) { Store (0x01, PSD0) If (LAnd (LLessEqual (DMA0, 0x14), And (W880, 0x20))) { Store (0x01, PCT0) Store (0x01, PMCC) Store (0x01, FPC0) } Else { If (LAnd (LLessEqual (DMA0, 0x1E), And (W880, 0x10))) { Store (0x02, PCT0) Store (0x01, PMCC) Store (0x01, PCB0) } Else { If (LAnd (LLessEqual (DMA0, 0x2D), And (W880, 0x08))) { Store (0x01, PCT0) Store (0x01, PMCC) Store (0x01, PCB0) } Else { If (LAnd (LLessEqual (DMA0, 0x3C), And (W880, 0x04))) { Store (0x02, PCT0) } Else { If (LAnd (LLessEqual (DMA0, 0x5A), And (W880, 0x02))) { Store (0x01, PCT0) } Else { Noop } } } } } } Else { If (LAnd (LLessEqual (DMA0, 0x78), And (W630, 0x04))) { Store (0x02, PISP) Store (0x03, PRCT) Store (0x01, PTI0) } Else { If (LAnd (LLessEqual (DMA0, 0xB4), And (W630, 0x02))) { Store (0x02, PISP) Store (0x01, PRCT) Store (0x01, PTI0) } Else { Noop } } } } } Store (0x01, PIDE) } } Device (SECD) { Name (_ADR, 0x01) Device (S_D0) { Name (_ADR, 0x00) Name (_GTF, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xF5 }) } Device (S_D1) { Name (_ADR, 0x01) Name (_GTF, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xF5 }) } } } } -- 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 17 03:11:03 2008 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 3F52A106564A for ; Mon, 17 Mar 2008 03:11:03 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id D1E798FC12 for ; Mon, 17 Mar 2008 03:11:02 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so539555uge.37 for ; Sun, 16 Mar 2008 20:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=fIshU0y/7erueRhgGvr3+EKv9Z08f5Wi86Rzw7aJAlQ=; b=S0vC9T/wdeh2mkF4Ls+z+FK8/1YxSYLIESy5iLT8VCCbLuKcrpP7TWtnjcp9a4cAVoMrSvBxJkIgCgztegeXNHrSuykFOBC6M2pBGyOdjjdeP4NnFMn5pVgxioeKVrFrTJhMpyVaPoyp2GU0zGnBRs7IBZv5Q+qy3pQAHkmYyLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=XM5eR/H3ZIt36Goa8erMv4AvmgV4jYGVzWLfykdmM1S+RAiNfe2TKMy6oUurRw6GccBBHOzQxFi8yhh04UOKRpXfev1z/HMrGmxfRR44u8xGgHcOJyOnKx1SU8HVA+TpLpLjpm9N5q0x9IZwLR1IIKDROeY7C43zD8dL+LuZrl8= Received: by 10.67.26.7 with SMTP id d7mr2519256ugj.23.1205721799181; Sun, 16 Mar 2008 19:43:19 -0700 (PDT) Received: by 10.66.248.11 with HTTP; Sun, 16 Mar 2008 19:43:19 -0700 (PDT) Message-ID: Date: Mon, 17 Mar 2008 02:43:19 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <1026.1205706791@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1026.1205706791@critter.freebsd.dk> X-Google-Sender-Auth: 57151884647f24dc Cc: current@freebsd.org Subject: Re: Enhanced SpeedStep hosed in -current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 03:11:03 -0000 On 16/03/2008, Poul-Henning Kamp wrote: > > It looks like my laptop runs full speed at all times, no matter what > powerd or I may desire. > > Looks like the EST driver is (suddenly ?) not happy about the system. I thought that this could've been related to the lapic frequency madness I was seeing in RELENG_7 on my T43p, so I axed cpufreq from kernel config, and the problem's gone... So, it does seem like something is not quite in cpufreq > RELENG_7_0... Cheers, Igor From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 03:34:16 2008 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 95F8D1065671 for ; Mon, 17 Mar 2008 03:34:16 +0000 (UTC) (envelope-from SRS0=7fd01c6525ccca9e668006a87f9fa01604bf0b5d=642=es.net=oberman@es.net) Received: from postal1.es.net (postal3.es.net [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id F40658FC16 for ; Mon, 17 Mar 2008 03:34:15 +0000 (UTC) (envelope-from SRS0=7fd01c6525ccca9e668006a87f9fa01604bf0b5d=642=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id XGZ78013; Sun, 16 Mar 2008 20:34:13 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8180C4500F; Sun, 16 Mar 2008 20:34:13 -0700 (PDT) To: "Igor Mozolevsky" In-Reply-To: Your message of "Mon, 17 Mar 2008 02:43:19 -0000." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1205724853_77245P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 16 Mar 2008 20:34:13 -0700 From: "Kevin Oberman" Message-Id: <20080317033413.8180C4500F@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Igor Mozolevsky X-To_Domain: hybrid-lab.co.uk X-To: "Igor Mozolevsky" X-To_Email: igor@hybrid-lab.co.uk X-To_Alias: igor Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Enhanced SpeedStep hosed in -current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 03:34:16 -0000 --==_Exmh_1205724853_77245P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Mon, 17 Mar 2008 02:43:19 +0000 > From: "Igor Mozolevsky" > Sender: owner-freebsd-current@freebsd.org > > On 16/03/2008, Poul-Henning Kamp wrote: > > > > It looks like my laptop runs full speed at all times, no matter what > > powerd or I may desire. > > > > Looks like the EST driver is (suddenly ?) not happy about the system. > > I thought that this could've been related to the lapic frequency > madness I was seeing in RELENG_7 on my T43p, so I axed cpufreq from > kernel config, and the problem's gone... So, it does seem like > something is not quite in cpufreq > RELENG_7_0... My experience with my T43 (not T43p) is that it does not play well with cpufreq. This is not new to 7-Stable. I have been seeing it since the system was new, just over 2 years ago. I always build my kernel without it. Aside from the sort of thing you saw, I also saw misbehavior in switching between battery and AC and powerd did odd things. Without cpufreq, it runs well in all respects. dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2000 dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725 dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1205724853_77245P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFH3ea1kn3rs5h7N1ERAk/HAJ40u1QhgHMixIVmFaxE1UJQWNgoWACcCvsD I+azx7H4jvJ1HTxE/Wlq4GM= =F9wC -----END PGP SIGNATURE----- --==_Exmh_1205724853_77245P-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 03:55:06 2008 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 8A3721065677 for ; Mon, 17 Mar 2008 03:55:06 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 28CD88FC19 for ; Mon, 17 Mar 2008 03:55:05 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so544131uge.37 for ; Sun, 16 Mar 2008 20:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=ptyz57uGsbqjS9/he95YQxZy/qIy7U8IyBvsdiD6D5E=; b=uuDKTi0r5n6Y4L1QX+aD9r1epaR+OQhWkJ4JtjTOTE97arwPSc36X3o3jzwj9pA89kx9K4QTeeSxkF3OXD/4NCTHKxp9Y7kECTyMLy+BVAn9EWBuwDjQmnXYWESRYGXMm61qNL4r93AxB1GCwZcKcG1tnC8VwRLIMs18B4QDt18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JeRNZenc5fODJ3+kIMcOrVSSECD4BBctfsuQ/til4SCE/ua91tKZ/J0bou6CAPQA+KB9/dllMh9zdgl2+iWIwLsiMGxrZ//yw/vEekpw0OVPZAaPzEK+5GIbdRk9FgGroimFygMQCgW4/BqMqrSehXO6RBo3Y10QXXe3/wZZQMU= Received: by 10.66.239.16 with SMTP id m16mr2549488ugh.58.1205726104778; Sun, 16 Mar 2008 20:55:04 -0700 (PDT) Received: by 10.66.248.11 with HTTP; Sun, 16 Mar 2008 20:55:04 -0700 (PDT) Message-ID: Date: Mon, 17 Mar 2008 03:55:04 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Kevin Oberman" In-Reply-To: <20080317033413.8180C4500F@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080317033413.8180C4500F@ptavv.es.net> X-Google-Sender-Auth: 070c480e93ed6337 Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Enhanced SpeedStep hosed in -current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 03:55:06 -0000 On 17/03/2008, Kevin Oberman wrote: > > Date: Mon, 17 Mar 2008 02:43:19 +0000 > > From: "Igor Mozolevsky" > > Sender: owner-freebsd-current@freebsd.org > > > > > On 16/03/2008, Poul-Henning Kamp wrote: > > > > > > It looks like my laptop runs full speed at all times, no matter what > > > powerd or I may desire. > > > > > > Looks like the EST driver is (suddenly ?) not happy about the system. > > > > I thought that this could've been related to the lapic frequency > > madness I was seeing in RELENG_7 on my T43p, so I axed cpufreq from > > kernel config, and the problem's gone... So, it does seem like > > something is not quite in cpufreq > RELENG_7_0... > > > My experience with my T43 (not T43p) is that it does not play well with > cpufreq. This is not new to 7-Stable. I have been seeing it since the > system was new, just over 2 years ago. I always build my kernel without > it. I'm not having lapic issues (or any others, AFAIKT) on my T43p w/ RELENG_7_0 but RELENG_7 makes it really sluggish w/ cpufreq compiled in (perl timing tests fail as well)... Cheers, Igor From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 04:13:03 2008 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 887C4106564A for ; Mon, 17 Mar 2008 04:13:03 +0000 (UTC) (envelope-from jkoshy.freebsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 256E98FC17 for ; Mon, 17 Mar 2008 04:13:02 +0000 (UTC) (envelope-from jkoshy.freebsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so4541738fgg.35 for ; Sun, 16 Mar 2008 21:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:from:date:sender; bh=34pKYJg0NLHfGWN/4N4v3OxI3PR43uGKrfjcEl8Hlws=; b=WGlbHrW3p9s6f2LcrdoNbZLhO5VJxVJp5+stMuePpRNHW1zzSh9eWxRZ0+tivfWAjm13xCMlfprYDEFBsiLkTWGD0UVKBh2mmF2ahWpfb2pqIK7O/TYmJ9CJn7zholGkdxh62kdhv8NdwuXtzfwKuyi0u0fW+NK2dpkFUvP2tlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:from:date:sender; b=HyO/cLWGKbSp/1uYZbANYjWv5gR0hlRAie1cDJd5yI136EquhL49Ay+gt+PrxKeAK/i6xsF3e+TsBwtmj+6yTS/PpvvljGsMh3TCXrigAY58fAKu/7KvS0sRaRYF23hnC8y9nW8fXT1I6WJJeN+NghFk6FtDuOhI8/LF3NetJTk= Received: by 10.82.118.2 with SMTP id q2mr35240772buc.27.1205725733563; Sun, 16 Mar 2008 20:48:53 -0700 (PDT) Received: from moria.unixconsulting.co.in ( [203.145.156.9]) by mx.google.com with ESMTPS id b17sm9029255fka.4.2008.03.16.20.47.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Mar 2008 20:48:52 -0700 (PDT) Message-ID: <867ig2pr5j.wl%koshy@unixconsulting.co.in> To: "Adrian Chadd" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/21.3 (amd64--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII From: Joseph Koshy Date: Mon, 17 Mar 2008 03:38:35 -0000 Sender: Joseph Koshy Cc: jkoshy@freebsd.org, current@freebsd.org Subject: Re: issues with hwpmc and athlon XP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 04:13:03 -0000 > It seems that at least my revision of the Athlon XP has 48 bit > performance counters (AMD Athlon Processor x86 Code Optimisation > Guide, page 235 (Performance-Monitoring Counters: Overview) and the > top 16 bits read back 0x0000. Good catch. > Since the code is taking the 2's compliment of the stored PMC value > (which is so the value is incremented to 0xffffffffffffffff and wraps > over, generating an NMI - mentioned on page 240), negating the value > gives humerous results: Thank you for the bug report and for the analysis in kern/121660. It so happens that the Athlon XP machine I purchased had one of those BIOSes that do not enable the local APIC. So I couldn't get those PMCs to deliver an interrupt and wasn't able to test sampling on this processor. That was frustrating, especially since Linux 2.4 and later can override the BIOS and use the LAPIC; we can't. Onto debugging this bug: my first question is: does system sampling (i.e.. pmcstat -S) work OK on this CPU? > (Oh and whilst I'm at it; maybe some documentation relating to your > pmc debugging features would be nice. :) Uhhh. Well, its just scaffolding around printf(9) and is fairly commented in hwpmc_mod.c. You've already figured out most of the stuff anyhow :). Ask me in private mail if you want any more detail. I don't know where else to document it; surely its not something worth adding to the hwpmc.4 manual page :). Regards, Koshy From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 04:23:22 2008 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 3D37C106566C for ; Mon, 17 Mar 2008 04:23:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4658FC16 for ; Mon, 17 Mar 2008 04:23:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so3410817rvb.43 for ; Sun, 16 Mar 2008 21:23:20 -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:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=JiqcakbRwU3aTJ8o9O1rfakbnOww6NZxzWkHEfGw2Jk=; b=OuDo5VJn763NFqO/XU668TNbGPcEblpGSnPu3G7MSrPsA37Fly5RWj55liQe+vX/7v1iCWyJQu/3xzqJCsGmrOkgAw+PsMSZQlSoRqkTGbcojTpPuugrzBQrf1vp4QhW3IMC+bk94j/ztombWft0oo8BV2t9jE6IQyjZJAawCA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=psHS4vkxaKJUjt9p7b76hbj673F5DTkS0enc7lzhj6Pr7TWlR30isBgqq7DbUdJgXNk/k9xbIRyMx81eYuBFCGpo0/GYog8P55BvwoPtBuDzoXMi26wiGWENLwBY2/vHh6wo4oKbWv9BLbCVQbG6lc6BSqdj59UPMGsgnhOYTIk= Received: by 10.140.165.21 with SMTP id n21mr7296298rve.289.1205727800968; Sun, 16 Mar 2008 21:23:20 -0700 (PDT) Received: by 10.140.143.14 with HTTP; Sun, 16 Mar 2008 21:23:20 -0700 (PDT) Message-ID: Date: Mon, 17 Mar 2008 13:23:20 +0900 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Joseph Koshy" In-Reply-To: <867ig2pr5j.wl%koshy@unixconsulting.co.in> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <867ig2pr5j.wl%koshy@unixconsulting.co.in> X-Google-Sender-Auth: 9030f0874759cf9e Cc: current@freebsd.org Subject: Re: issues with hwpmc and athlon XP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 04:23:22 -0000 On 17/03/2008, Joseph Koshy wrote: > It so happens that the Athlon XP machine I purchased had one of those > BIOSes that do not enable the local APIC. So I couldn't get those > PMCs to deliver an interrupt and wasn't able to test sampling on this > processor. That was frustrating, especially since Linux 2.4 and later > can override the BIOS and use the LAPIC; we can't. Hm, why can they but we can't? > Onto debugging this bug: my first question is: does system sampling > (i.e.. pmcstat -S) work OK on this CPU? It returned results. I don't know how valid the results were. In fact, I'm still not getting user-space info from pmcstat -P but that partially may be user error. I'm seeing NMI's which are logged against a user trapframe but nothing shows up in my profiling output.. it could be attributing it to the library/libraries instead of the process. Adrian -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 05:12:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 646C71065670 for ; Mon, 17 Mar 2008 05:12:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1C88FC14 for ; Mon, 17 Mar 2008 05:12:14 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so5701390wxd.7 for ; Sun, 16 Mar 2008 22:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=542C+u8BBVmJ2nKHNP8UU4RAXCaemphjCj0Ta7fPn60=; b=UNe3vd9poX9ecf84RUMsGvTi942OXC89Vu9lghUOPk4kzWuUP5nfAUQifIJVuPfbajjlQRse75biIaPK0VYK0YsQL1qguVkB7x0u/ehCj2XYBXTexXzyZeMaSEYjNzDVZTPLd98cbMJblWnkl5crAJ33D07vc2c/CVgVK2ugDPA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=JRAHpxenw07AOpxKErMn/0BVfbE+gw7KfSQ5a5NeqX/+gSfQI7CkzE9eOZBqYQegmHyhTKAxLuqkiiaB03LTIJX98YYy7uKLmgzOwN2MicA122ie21dxuqDCLTU5U6TCcsCWTSjWrJKVcEesG1j9eSSMiMC2FXwo0U1a5UnuGNk= Received: by 10.100.4.1 with SMTP id 1mr31458009and.81.1205730733955; Sun, 16 Mar 2008 22:12:13 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 3sm30878056wrs.22.2008.03.16.22.12.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Mar 2008 22:12:12 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m2H5C58E002693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 14:12:05 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m2H5C3Fi002692; Mon, 17 Mar 2008 14:12:03 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 17 Mar 2008 14:12:03 +0900 From: Pyun YongHyeon To: Ian FREISLICH Message-ID: <20080317051203.GC2503@cdnetworks.co.kr> References: <20080222042700.GB30497@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 05:12:15 -0000 On Fri, Feb 22, 2008 at 10:43:22AM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > On Thu, Feb 21, 2008 at 01:18:18PM +0200, Ian FREISLICH wrote: > > > Pyun YongHyeon wrote: > > > > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > > > > > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon wr > ote: > > > > > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > > > > > > > I am experiencing roughly 15% packet corruption on the re inter > face > > > on > > > > > > > my freebsd 7/amd64 box. > > > > > > > > > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEA > SE #8 > > > : > > > > > > > Tue Feb 5 09:49:55 EST 2008 > > > > > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > > > > > > > > > Just to make troubleshooting difficult, this problem only shows > up > > > > > > > after the system has been up for roughly 36 hours, depending on > the > > > > > > > amount of traffic. > > > > > > > > > > > > > > > > > > > I didn't take a look attached tcpdump files but I guess the > > > > > > instability issue was fixed in HEAD. It's not yet MFCed but > > > > > > I'll handle it in a week. > > > > > > > > > > > > Would you try re(4) in HEAD? > > > > > > > > > > > > > > > > OK, I'll do that. What is the best way to do that? csupping to "." se > ems a > > > > > bit drastic, and I don't do much with cvs proper. I take it that I sh > ould > > > use > > > > > anon-cvs to grab the directory, but I don't quite know how. > > > > > > > > > > > > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > > > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > > > > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > > > > This doesn't solve the problem that I'm seeing on re(4) interfaces. > > > It basically shows up as quagga establishing OSPF neighours as > > > "Exchange/DR" when VLAN hardware tagging is enabled. I'm running > > > OSPF over 802.1Q vlans. Neighbours are correctly negotiated once > > > VLAN hardware tagging is disabled on the interface. > > > > > > I'll do more debugging. > > > > > > > Hmm. That sounds like different issue to me. I guess I din't change > > any semantics in VLAN H/W tagging. Do you still the same VLAN H/W > > tagging related issues on RELENG_7? > > > > To narrow down the issue it would be even better to know which parts > > of H/W assistance was broken. For example, > > - Disable checksum offload for VLAN interface first and check > > whether quagga works. > > You can only disable offload on the parent interface. > > > - Disable checksum offload for parent interface and check again. > > If you can post tcpdump output for broken conntection it may help a > > lot to diagnose the issue. > > The only flag affecting this behaviour is vlanhwtag. Various > permutations of the interface flags make no difference to this > behaviour as long as hardware tagging is enabled. > > It seems like it's corrupting large packets on transmit when vlanhwtag > is enabled. From the tcpdump output it looks like a padding or > packet length issue. > > Here's what tcpdump on the re(4) device thinks it's transmitting: > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > Here's what was actually recieved by the em(4) device on the > neighbour. Note the absense of the 801.1Q header: > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype IPv4 (0x0800), length 1506: 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > When vlanhwtagging is disabled, the re(4) device transmits: > > 00:90:fb:0c:89:7d > 00:08:a1:3c:32:9c, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.89 > 196.22.138.92: OSPFv2, Database Description, length: 1472 > > and the em(4) device recieves: > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > Let me know if you need more detailed tcpdump output than I've provided. > I guess I've found a VLAN hardware tagging bug in re(4). Please try this one and let me know the result. http://people.freebsd.org/~yongari/re/if_re.c http://people.freebsd.org/~yongari/re/if_rlreg.h > Ian > > -- > Ian Freislich > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 06:16:19 2008 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 1E5A9106566B; Mon, 17 Mar 2008 06:16:19 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Received: from gir.gshapiro.net (gir.gshapiro.net [209.246.26.16]) by mx1.freebsd.org (Postfix) with ESMTP id 09FA08FC16; Mon, 17 Mar 2008 06:16:18 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Received: from monkeyboy.local (c-67-164-3-230.hsd1.ca.comcast.net [67.164.3.230]) (authenticated bits=128) by gir.gshapiro.net (8.14.3.Alpha1/8.14.2) with ESMTP id m2H6G3Va004079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Mar 2008 23:16:13 -0700 (PDT) (envelope-from gshapiro@freebsd.org) Date: Sun, 16 Mar 2008 23:15:58 -0700 From: Gregory Shapiro To: Mike Telahun Makonnen Message-ID: <20080317061558.GA1220@monkeyboy.local> References: <20080202012707.GA1800@kobe.laptop> <1204809780.885.3.camel@sol> <20080306201905.GA11317@kobe.laptop> <20080311025333.GF2422@monkeyboy.local> <584bfc3f0803122336r96f4033pc0e25a7324fb0486@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <584bfc3f0803122336r96f4033pc0e25a7324fb0486@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Giorgos Keramidas , current@freebsd.org Subject: Re: latest rc.subr breaks etc/rc.d/sendmail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 06:16:19 -0000 > Can you take a look at the following patch please? The patch looks good, I just found some minor issues: 1. In /etc/rc.d/sendmail, rename sendmail_precmd to sendmail_prestart for consistency? 2. /etc/rc.d/sendmail-msp-queue doesn't need to set start_precmd or define a sendmail_prestart() function as the MSP queue runner doesn't use the aliases file (yes, this was a bug in the old /etc/rc.d/sendmail). 3. Both /etc/rc.d/sendmail-outbound and /etc/rc.d/sendmail-submit are missing: required_files="/etc/mail/sendmail.cf" (yes, this was also a bug in the old /etc/rc.d/sendmail). 4. Putting sendmail.subr in /etc/mail/ seems a bit odd. /etc/mail/ is meant for MTA configuration, not startup subroutines. Perhaps /etc/rc.sendmail.subr or /etc/sendmail.subr for consistency with /etc/network.subr? 5. This line in /etc/defaults/rc.conf: # Settings for /etc/rc.sendmail and /etc/rc.d/sendmail: should be updated to: # Settings for /etc/rc.sendmail and /etc/rc.d/sendmail*: From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 09:29:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C90751065671 for ; Mon, 17 Mar 2008 09:29:27 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 76AF28FC24 for ; Mon, 17 Mar 2008 09:29:27 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbBek-0003rG-0b for freebsd-current@freebsd.org; Mon, 17 Mar 2008 09:29:22 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Mar 2008 09:29:22 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Mar 2008 09:29:22 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Vadim Goncharov Date: Mon, 17 Mar 2008 09:29:14 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 33 Message-ID: References: <20080315012451.674530f4.ota@j.email.ne.jp> <200803150904.m2F94emj014374@lurza.secnetix.de> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Oliver Fromme User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 09:29:28 -0000 Hi Oliver Fromme! On Sat, 15 Mar 2008 10:04:40 +0100 (CET); Oliver Fromme wrote about 'Re: RELEASE discs & ISO images (for future)': >>> 224655360 7.0-RELEASE-i386-livefs.iso >>> 94493696 7.0-RELEASE-i386-livefs.iso.uzip (16k cluster) >>> 110188032 7.0-RELEASE-i386-livefs.iso.uzip (2K cluster) >>> >>> So the difference is 124 MB for 16K cluster size, and >>> 109 MB for 2K cluster size (which is noticably faster >>> during access). Actually the space savings will be a >>> bit less, because the /boot directory (about 30 MB) >>> won't be compressed. So the real gain is probably a >>> little less than 100 MB in the 2K case. >> >> By the way, the maxmum cluster size is 127k or 130048 with uzip, >> if you want to maximize the compression ratio. > That would make the live FS painfully slow, and it wouldn't > make a big difference from the default (16K). > It is already noticeably slow with the default cluster size > of 16K on my test machine (a 1 GHz VIA C3), so would rather > prefer to use 2K cluster size, even though compression will > be not quite as good. (2K is the minimum, less than that > doesn't make sense for CD9660 media because the physical > sector size is 2K.) How much is slowdown from 2K to 16K ? I think it's not worth to loose in compression ratio in 16K -> 2K, in opposit to 127K which will really gain nothing, yes. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 09:49:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A88D1065670 for ; Mon, 17 Mar 2008 09:49:22 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 05D118FC25 for ; Mon, 17 Mar 2008 09:49:21 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbBy4-0004i4-CT for freebsd-current@freebsd.org; Mon, 17 Mar 2008 09:49:20 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Mar 2008 09:49:20 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Mar 2008 09:49:20 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Vadim Goncharov Date: Mon, 17 Mar 2008 09:49:11 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 205 Message-ID: References: <200803141508.m2EF86Jl068931@lurza.secnetix.de> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Oliver Fromme User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 09:49:22 -0000 Hi Oliver Fromme! On Fri, 14 Mar 2008 16:08:06 +0100 (CET); Oliver Fromme wrote about 'Re: RELEASE discs & ISO images (for future)': >>> The xorg packages on disc1 occupy 54 MB. Not really all >>> that much, I think. The linux base, perl and python occupy >>> another 50 MB together. The rest are small utility things >>> and dependencies (only a few MB). >> But that is still valuable if geom_ugz is in use. > Have you actually tried it? Providing hard numbers is > more useful than just talking about it. :-) I've used Frenzy LiveCD many times (http://frenzy.org.ua), a Portable SysAdmin Tool. It is 200Mb minicd with MANY useful packages. It has X Window and many graphical and console utilities (about 600MB uncompressed). It proved to be stable and not-so-slow. > Here are some numbers: > 224655360 7.0-RELEASE-i386-livefs.iso > 94493696 7.0-RELEASE-i386-livefs.iso.uzip (16k cluster) > 110188032 7.0-RELEASE-i386-livefs.iso.uzip (2K cluster) > So the difference is 124 MB for 16K cluster size, and > 109 MB for 2K cluster size (which is noticably faster > during access). Actually the space savings will be a > bit less, because the /boot directory (about 30 MB) > won't be compressed. So the real gain is probably a > little less than 100 MB in the 2K case. The less for /boot should be compensated by 16K cluster size. But those numbers are for utilities - are there any docs on ISO ? >>> Also keep in mind that a new installer is in the works >>> and will be usable "really soon", as far as I know. >>> I'm sure the authors are aware of the problem of >>> installing packages from changeable media, and that >>> there will be a better solution. >> >> This will surely not be finished before 8.0, > I'm not so sure. May be. But it definitely won't be bug-free and default installer before 8.0. >>> Right, but I didn't read them either upon my first install >>> 15 years ago. :-) The first thing I did when I received >>> the Walnut Creek CDs was to go to www.freebsd.org and look >>> for docs. >> >> Tempora mutantur. Users nowadays rarely go for docs in first place. They >> need understandable guide exactly in process. > Users who refuse to read docs will also refused to read > docs that are directly available on the CD. > Users unwilling to read docs cannot be cured by technical > measures. It's a user problem, not a FreeBSD problem. When you say so, you lose a number of users. A number which is impatient to read too many docs about _unfamiliar_ system before, but will use help if it is available. >>> I guess almost everyone has internet access somehow (at >>> home, at the office, at a friend, or elsewhere). >> >> No, that doesn't matter. If user have only one computer online with >> Internet, and during install previous operating system is of course >> unavailable, then Internet (and docs on www!) is also unavailable. > Uhm, I assume that a new FreeBSD user skims through the > "Installation" chapter of the Handbook _before_ he starts > the installation. Of course it's useful to be able to > look up things in the Handbook again during installation > if the need arises. It's _surely_ a must. Because novice user can't learn those chapters by heart, so access to docs in the actual process will be needed. >> So where would you browse the docs in the process except the installer >> itself and first disk? > Last time I used sysinstall, there was a menu entry that > enabled you to read Handbook and FAQ. I'm pretty sure > it's still there. That's the menu^ x x X Exit Exit this menu (returning to previous) x x x x 1 README A general description of FreeBSD. Read this! x x x x 2 Errata Late-breaking, post-release news. x x x x 3 Hardware The FreeBSD survival guide for PC hardware. x x x x 4 Install A step-by-step guide to installing FreeBSD. x x x x 5 Copyright The FreeBSD Copyright notices. x x x x 6 Release The release notes for this version of FreeBSD. x x x x 7 Shortcuts Creating shortcuts to sysinstall. x x x x 8 HTML Docs Go to the HTML documentation menu (post-install). x x It is access to the release accompanying files only. And HTML docs are available after install only, as you can see. > Note that you cannot use that menu entry once the actual > installation has started, though. You can only abort the > installation, then go back to the menu, read the docs, > and then begin a new installation. That's a pain, too. > Of course, once the installation has progressed so far > that the docs have been installed on the harddisk, you > can read them on the shell that's opened on Alt-F4. That's a drawback. I think there should be another sysinstall's console on which docs are always available. > Still, it's best to read the Installation chapter in > advance, or even better, have a printed copy on paper. It is not ethical to require users to print docs before. >>> That's what the DVD is good for that you can buy (or you >>> can easily make one yourself). On the DVD there is enough >>> space for everything. >> Agreed, but CDs still will be an option for a long time. And care must be taken >> for those users who don't need packages and don't want to download DVD. > Personally I think most computers that are equipped with > an optical drive can read DVDs. Only very few are left > with a CD-ROM drive that's not DVD-capable. > Therefore, my opinion is that we should publish a DVD > image in the future that contains everything we have > today on disc{1,2,3} docs and livefs CD. The size of > such an DVD would be 1.95 GB for 7.0-RELEASE/i386. > For those who don't want or need packages and docs, > a smaller CD image with just the install bits (and maybe > the fixit FS) could be provided, and of course the small > "bootonly" image, but nothing else. Providing five or > more CD images is rather last century like, in my opinion. Yes, but DVD is still in the future. >> You again forget about advocacy, new users coming from other OSes and >> possibly comparing with some Linux distros. > Such comparisons are bogus anyway. I've installed SuSE > linux before, and I think the graphical installer is > terribly annoying. It's worse than Windows. It took > me a lot longer to get a usable system installed, and > even then it installed different sets than the ones I > selected (I have no idea why). In my opinion, FreeBSD's > installation wins big time. I've not said anything about graphics installer - but features/functional only. >> Imagine a review like this: >> "That SuSe or Debian are wonderful with great number of software instantly >> available and with this FreeBSD I must wait for download and then compile?! >> Such shit! Don't use it, if they can't do this, they can't do other usable >> things!" > Such a review is worthless and shouldn't be taken serious. > I really don't worry about that. You don't, but a number of users can be lost. Advocacy, again. >>>> Yes, but: livefs and disc1 have many things in common, >>> No, they dont. The only thing they have in common is the >>> /boot directory, which is relatively small (about 30 MB). >> And what about at least shell and some other tools? > A shell and a few tools (very few, admittedly) are included > in the MFS image in the /boot directory. > And there's also the shell opened on Alt-F4 once the > installation has started. For anything else there is > the "fixit" live FS. That's shells are almost useless because even "ls" don't work. >> This _can_ be combined, as previous releases have proven. > Previous releases were a lot smaller. :-) > The point is, disc1 and livefs have _nothing_ in common > except for the 30 MB /boot directory, so you only save > those 30 MB when combining them. No more. Look at the > ISOs if you don't believe me. I can cureently look to 6.2 ISOs only - 7.0 is too big to download "to just see" :-) >>>> Really? Have benchmarks? If it is really hust a few percent, then it is not >>>> worth, of course. >>> I can't find the article right now, I'm afraid. :-( >>> When I have some time at the weekend, I might make a >>> little benchmark myself. >> Would be godd, I'll wait :) > Why haven't you done it yourself? It's not difficult. > If you want to get something done, the best way is to do > it yourself, instead just talking about it. That's why > FreeBSD is what it is today. ;-) > OK, here are the results of 7.0-RELEASE/i386: > 348 MB gzip'ed (default) > 297 MB bzip2'ed > So the space saving is 51 MB (14.7%). It took 45 minutes > on my machine to create the bzip2-compressed files. Here > are the decompression times: > 0:57 for the gzip'ed sets > 7:20 for the bzip2'ed sets > So it takes almost 8 times as long to decompress. The > machine was otherwise idle, and the times were reproducible > with good accuracy. OK, agreed. But bzip2 can be left as option to the future for some system prts not in default install, if sizes will grow... -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 06:17:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C3F41065673 for ; Mon, 17 Mar 2008 06:17:08 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id E961F8FC1A for ; Mon, 17 Mar 2008 06:17:07 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so3433741rvb.43 for ; Sun, 16 Mar 2008 23:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=qQsIJF4+pqJWksE/Q6hamCUBXtatgkH2sEo4wAyX+/A=; b=IpZOmHCu+qQni6hzFmDGOKYHVQBdmtqkDqZOysk4j/5mBkeE2HKRQeSecG2YzFDbyYzyWRN/qqNJw62XIKMb1Dk8l/Ki7QCv566eINS3CT+7SPILjGOLc1Ko/9YT74zCiuJXVyuS7Kmv4ZTX8B8cISejUz+b7vLWrgLhuv0i1M4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=T/sZ0hKzBbw02/TRaBQzjJUYvGbnuL5WP+q6M9DZP81uQXbe+Y+sjTFcrdPckr/fNfYwPCiwtsjWiPRXSDM2bUVurNl3PVIJ2mdXwad3/NwI9WvaRyVDIGDjnl1TefE7Y56D6AqxZNXJ7jFdLi/UHsL2v0oQgAAC3tMM2+dTk64= Received: by 10.141.44.13 with SMTP id w13mr7370168rvj.13.1205734627024; Sun, 16 Mar 2008 23:17:07 -0700 (PDT) Received: by 10.141.41.8 with HTTP; Sun, 16 Mar 2008 23:17:06 -0700 (PDT) Message-ID: <3dd203290803162317u69b76bf2t203be7d863db3831@mail.gmail.com> Date: Mon, 17 Mar 2008 06:17:06 +0000 From: "Brad Pitney" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 17 Mar 2008 11:12:47 +0000 Subject: Another Lock Order Reversal -- sysctl? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 06:17:08 -0000 Hi, this one is different, I also had debugging on and I got more details (I hope) lock order reversal: 1st 0xc474281c process slock (process slock) @ /usr/src/sys/kern/kern_proc.c:710 2nd 0xc07bf5d0 scrlock (scrlock) @ /usr/src/sys/dev/syscons/syscons.c:2526 KDB: stack backtrace: db_trace_self_wrapper(c0746b40,e6fdd3ec,c057644e,c0748ee1,c07bf5d0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0748ee1,c07bf5d0,c073a70f,c073a70f,c073a69b,...) at kdb_backtrace+0x29 witness_checkorder(c07bf5d0,9,c073a69b,9de,c07bf5d0,...) at witness_checkorder+0x6de _mtx_lock_spin_flags(c07bf5d0,0,c073a69b,9de,c07bf4c0,...) at _mtx_lock_spin_flags+0xc2 sc_puts(c07bf4c0,e6fdd447,1,6380c3a0,c077c9e0,...) at sc_puts+0x7e sc_cnputc(c077c9e0,63,e6fdd5fc,1,a,...) at sc_cnputc+0xc3 cnputc(63,0,c074b14e,28e,e6fdd6fc,...) at cnputc+0x5f cnputs(e6fdd5fc,e6fdd6fc,e6fdd4bc,c05696f1,a,...) at cnputs+0x58 putcons(a,0,1fdd593,c4742a2c,c07439b3,...) at putcons+0x67 putchar(a,e6fdd6fc,0,6,c4742a2c,...) at putchar+0x61 kvprintf(c074396a,c0569690,e6fdd6fc,a,e6fdd744,...) at kvprintf+0x75 printf(c074396a,1ef,0,1b6,0,...) at printf+0x6c calcru1(e6fdda30,4,c0743806,345,c07432db,2c6) at calcru1+0x25e calcru(c4742804,e6fdda28,e6fdda30,2c6,c4864aa8,...) at calcru+0x12d fill_kinfo_proc_only(c4742894,4,c07432db,38a,0,...) at fill_kinfo_proc_only+0x3b7 sysctl_out_proc(c4a35420,c4742804,c07432db,401,0,...) at sysctl_out_proc+0x68 sysctl_kern_proc(c07863e0,0,0,e6fddba8,e6fddba8,...) at sysctl_kern_proc+0x4fd sysctl_root(e6fddba8,0,c0744bd6,574,c4a35420,...) at sysctl_root+0x137 userland_sysctl(c4a35420,e6fddc18,3,0,bfbfe744,...) at userland_sysctl+0x115 __sysctl(c4a35420,e6fddcfc,18,c0749bc1,c07807d0,...) at __sysctl+0xbc syscall(e6fddd38) at syscall+0x253 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x281bc823, esp = 0xbfbfe66c, ebp = 0xbfbfe698 --- KDB: enter: witness_checkorder db> show pcpu cpuid = 0 curthread = 0xc4a35420: pid 5757 "top" curpcb = 0xe6fddd90 fpcurthread = 0xc4a35420: pid 5757 "top" idlethread = 0xc43e3c60: pid 10 "idle" APIC ID = 0 currentldt = 0x50 spin locks held: exclusive spin mutex process slock r = 0 (0xc474281c) locked @ /usr/src/sys/kern/kern_proc.c:710 db> show alllocks Process 5757 (top) thread 0xc4a35420 (100074) exclusive sleep mutex process lock r = 0 (0xc4742894) locked @ /usr/src/sys/kern/kern_proc.c:1025 shared sx allproc r = 0 (0xc07c16fc) locked @ /usr/src/sys/kern/kern_proc.c:238 exclusive sx sysctl lock r = 0 (0xc07c1bf4) locked @ /usr/src/sys/kern/kern_sysctl.c:1396 exclusive sleep mutex Giant r = 0 (0xc07c11f0) locked @ /usr/src/sys/kern/kern_sysctl.c:1334 exclusive spin mutex process slock r = 0 (0xc474281c) locked @ /usr/src/sys/kern/kern_proc.c:710 exclusive sx so_rcv_sx r = 0 (0xc4b2ab60) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 the actual top command was: top -SCats1 -- Best regards, Brad From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 06:28:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57D60106566B for ; Mon, 17 Mar 2008 06:28:35 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id 2ED488FC15 for ; Mon, 17 Mar 2008 06:28:34 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so3435904rvb.43 for ; Sun, 16 Mar 2008 23:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=pD2LaV6ubJC3DyJJ1YKm65D2pVXAaLBi213MTDcVLXM=; b=pQ8IoXLSm49t5t4IZFEyoZwjHIwlKHairl2CLq4CiJluXgumzStitoMH023/TiFfi7dqcFgs73xdF5T/Wy8FX0LF0eXGsupRRrJBFtoKI4SSDgU/5LloTBThGfOJdrxKDVyZH98sJnms21o/F73L8nEPjTmBRgCMYQjuDu1uPiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mDNgpnI/su8X/Yp5JW5hSsTuP562pAxaLPPOYQ0BXiEtjdhFY+9YWN6aqTzT9ik6O8vpnj3ugoAVU8jpBaZyec7lsLeDgHHLcuwyEZrT8sxNOIxd/SayLZvIbcbf+LuaMo+JcQHy/7U1C53ve3W+sZZWUOUWkvsGKnvIbcayjXU= Received: by 10.140.164.1 with SMTP id m1mr7331116rve.266.1205735314503; Sun, 16 Mar 2008 23:28:34 -0700 (PDT) Received: by 10.141.41.8 with HTTP; Sun, 16 Mar 2008 23:28:34 -0700 (PDT) Message-ID: <3dd203290803162328x4503d034o569a9ce5d72ad08a@mail.gmail.com> Date: Mon, 17 Mar 2008 06:28:34 +0000 From: "Brad Pitney" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 17 Mar 2008 11:18:36 +0000 Subject: Another Lock Order Reversal -- sysctl? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 06:28:35 -0000 Hi, this one is different, I also had debugging on and I got more details (I hope) lock order reversal: 1st 0xc474281c process slock (process slock) @ /usr/src/sys/kern/kern_proc.c:710 2nd 0xc07bf5d0 scrlock (scrlock) @ /usr/src/sys/dev/syscons/syscons.c:2526 KDB: stack backtrace: db_trace_self_wrapper(c0746b40,e6fdd3ec,c057644e,c0748ee1,c07bf5d0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0748ee1,c07bf5d0,c073a70f,c073a70f,c073a69b,...) at kdb_backtrace+0x29 witness_checkorder(c07bf5d0,9,c073a69b,9de,c07bf5d0,...) at witness_checkorder+0x6de _mtx_lock_spin_flags(c07bf5d0,0,c073a69b,9de,c07bf4c0,...) at _mtx_lock_spin_flags+0xc2 sc_puts(c07bf4c0,e6fdd447,1,6380c3a0,c077c9e0,...) at sc_puts+0x7e sc_cnputc(c077c9e0,63,e6fdd5fc,1,a,...) at sc_cnputc+0xc3 cnputc(63,0,c074b14e,28e,e6fdd6fc,...) at cnputc+0x5f cnputs(e6fdd5fc,e6fdd6fc,e6fdd4bc,c05696f1,a,...) at cnputs+0x58 putcons(a,0,1fdd593,c4742a2c,c07439b3,...) at putcons+0x67 putchar(a,e6fdd6fc,0,6,c4742a2c,...) at putchar+0x61 kvprintf(c074396a,c0569690,e6fdd6fc,a,e6fdd744,...) at kvprintf+0x75 printf(c074396a,1ef,0,1b6,0,...) at printf+0x6c calcru1(e6fdda30,4,c0743806,345,c07432db,2c6) at calcru1+0x25e calcru(c4742804,e6fdda28,e6fdda30,2c6,c4864aa8,...) at calcru+0x12d fill_kinfo_proc_only(c4742894,4,c07432db,38a,0,...) at fill_kinfo_proc_only+0x3b7 sysctl_out_proc(c4a35420,c4742804,c07432db,401,0,...) at sysctl_out_proc+0x68 sysctl_kern_proc(c07863e0,0,0,e6fddba8,e6fddba8,...) at sysctl_kern_proc+0x4fd sysctl_root(e6fddba8,0,c0744bd6,574,c4a35420,...) at sysctl_root+0x137 userland_sysctl(c4a35420,e6fddc18,3,0,bfbfe744,...) at userland_sysctl+0x115 __sysctl(c4a35420,e6fddcfc,18,c0749bc1,c07807d0,...) at __sysctl+0xbc syscall(e6fddd38) at syscall+0x253 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x281bc823, esp = 0xbfbfe66c, ebp = 0xbfbfe698 --- KDB: enter: witness_checkorder db> show pcpu cpuid = 0 curthread = 0xc4a35420: pid 5757 "top" curpcb = 0xe6fddd90 fpcurthread = 0xc4a35420: pid 5757 "top" idlethread = 0xc43e3c60: pid 10 "idle" APIC ID = 0 currentldt = 0x50 spin locks held: exclusive spin mutex process slock r = 0 (0xc474281c) locked @ /usr/src/sys/kern/kern_proc.c:710 db> show alllocks Process 5757 (top) thread 0xc4a35420 (100074) exclusive sleep mutex process lock r = 0 (0xc4742894) locked @ /usr/src/sys/kern/kern_proc.c:1025 shared sx allproc r = 0 (0xc07c16fc) locked @ /usr/src/sys/kern/kern_proc.c:238 exclusive sx sysctl lock r = 0 (0xc07c1bf4) locked @ /usr/src/sys/kern/kern_sysctl.c:1396 exclusive sleep mutex Giant r = 0 (0xc07c11f0) locked @ /usr/src/sys/kern/kern_sysctl.c:1334 exclusive spin mutex process slock r = 0 (0xc474281c) locked @ /usr/src/sys/kern/kern_proc.c:710 exclusive sx so_rcv_sx r = 0 (0xc4b2ab60) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 the actual top command was: top -SCats1 -- Best regards, Brad From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 11:33:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0F091065677 for ; Mon, 17 Mar 2008 11:33:19 +0000 (UTC) (envelope-from hans@lambermont.dyndns.org) Received: from lambermont.dyndns.org (lambermont.dyndns.org [82.95.221.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9F1D48FC1C for ; Mon, 17 Mar 2008 11:33:19 +0000 (UTC) (envelope-from hans@lambermont.dyndns.org) Received: by lambermont.dyndns.org (Postfix, from userid 1001) id CB7D322DDF0; Mon, 17 Mar 2008 12:17:41 +0100 (CET) Date: Mon, 17 Mar 2008 12:17:41 +0100 To: Vadim Goncharov Message-ID: <20080317111741.GB6353@leia.lambermont.dyndns.org> References: <200803141508.m2EF86Jl068931@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i From: hans@lambermont.dyndns.org (Hans Lambermont) Cc: freebsd-current@freebsd.org Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 11:33:20 -0000 Vadim Goncharov wrote: >> Therefore, my opinion is that we should publish a DVD image in the >> future that contains everything we have today on disc{1,2,3} docs >> and livefs CD. The size of such an DVD would be 1.95 GB for >> 7.0-RELEASE/i386. >> >> For those who don't want or need packages and docs, a smaller CD >> image with just the install bits (and maybe the fixit FS) could be >> provided, and of course the small "bootonly" image, but nothing >> else. Providing five or more CD images is rather last century like, >> in my opinion. > > Yes, but DVD is still in the future. Why ? I've used Dru's nice blog at http://blogs.ittoolbox.com/unix/bsd/archives/creating-your-own-freebsd-70-dvd-22791 (slightly adapted, using mdconfig -d -u /dev/md0) to create my own bootable dvd (of disc[1-3].iso and docs.iso) in only a few minutes time. regards, Hans Lambermont From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 13:00:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF0D21065675; Mon, 17 Mar 2008 13:00:48 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 64C028FC1D; Mon, 17 Mar 2008 13:00:48 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from hub.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 2311C51EBE; Mon, 17 Mar 2008 22:00:40 +0900 (JST) Received: from nest.bbnest.net (nest.bbnest.net [10.0.0.249]) by hub.bbnest.net (8.14.2/8.14.1) with ESMTP id m2HD0djD046527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Mar 2008 22:00:39 +0900 (JST) (envelope-from bland@bbnest.net) Message-Id: <641CAF57-F235-4F0D-A120-2B58F0B13861@bbnest.net> From: Alexander Nedotsukov To: Kostik Belousov In-Reply-To: <20080222172930.GZ57756@deviant.kiev.zoral.com.ua> Content-Type: multipart/mixed; boundary=Apple-Mail-92--181507418 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 22:02:39 +0900 References: <4796356D.9080809@gmail.com> <20080123051648.GV57756@deviant.kiev.zoral.com.ua> <479796E1.4000500@gmail.com> <1201118159.38742.17.camel@shumai.marcuscom.com> <20080123211149.GA57756@deviant.kiev.zoral.com.ua> <1201123933.62127.9.camel@shumai.marcuscom.com> <20080124124213.GD57756@deviant.kiev.zoral.com.ua> <72E58ECA-D743-4D5E-9222-7129104E4BAC@bbnest.net> <20080221154714.GS57756@deviant.kiev.zoral.com.ua> <20CD87E3-27BC-4789-A51F-BBFDB3258B47@bbnest.net> <20080222172930.GZ57756@deviant.kiev.zoral.com.ua> X-Mailer: Apple Mail (2.919.2) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on hub.bbnest.net X-Mailman-Approved-At: Mon, 17 Mar 2008 13:06:27 +0000 Cc: yokota@freebsd.org, FreeBSD Current , Joe Marcus Marcus Clarke Subject: Re: page fault panic in scioctl and console-kit-daemon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 13:00:48 -0000 --Apple-Mail-92--181507418 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Better late than never :-) I am back. I understand your concerns and can assure that use-mode code will do right. I changed wchan address from system wide cdev pointer to syscons private address. What else need to be done to get this checked in and/or will you do that or I can proceed myself? --Apple-Mail-92--181507418 Content-Disposition: attachment; filename=sys_dev_syscons.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="sys_dev_syscons.patch" Content-Transfer-Encoding: 7bit Index: syscons.c =================================================================== RCS file: /home/ncvs/src/sys/dev/syscons/syscons.c,v retrieving revision 1.457 diff -u -r1.457 syscons.c --- syscons.c 24 Jan 2008 15:37:48 -0000 1.457 +++ syscons.c 17 Mar 2008 12:43:55 -0000 @@ -160,6 +160,7 @@ #define SC_CONSOLECTL 255 +#define VTY_WCHAN(sc, vty) (&SC_DEV(sc, vty)) #define VIRTUAL_TTY(sc, x) (SC_DEV((sc), (x)) != NULL ? \ SC_DEV((sc), (x))->si_tty : NULL) #define ISTTYOPEN(tp) ((tp) && ((tp)->t_state & TS_ISOPEN)) @@ -1065,17 +1066,9 @@ i = (*(int *)data == 0) ? scp->index : (*(int *)data - 1); if ((i < sc->first_vty) || (i >= sc->first_vty + sc->vtys)) return EINVAL; - s = spltty(); - error = sc_clean_up(sc->cur_scp); - splx(s); - if (error) - return error; - scp = sc_get_stat(SC_DEV(sc, i)); - if (scp == NULL) - return (ENXIO); - if (scp == scp->sc->cur_scp) + if (i == sc->cur_scp->index) return 0; - error = tsleep(&scp->smode, PZERO | PCATCH, "waitvt", 0); + error = tsleep(VTY_WCHAN(sc, i), PZERO | PCATCH, "waitvt", 0); return error; case VT_GETACTIVE: /* get active vty # */ @@ -2335,7 +2328,7 @@ * be invoked at splhigh(). */ if (debugger == 0) - wakeup(&sc->new_scp->smode); + wakeup(VTY_WCHAN(sc,next_scr)); splx(s); DPRINTF(5, ("switch done (new == old)\n")); return 0; @@ -2358,7 +2351,7 @@ /* wake up processes waiting for this vty */ if (debugger == 0) - wakeup(&sc->cur_scp->smode); + wakeup(VTY_WCHAN(sc,next_scr)); /* wait for the controlling process to acknowledge, if necessary */ if (signal_vt_acq(sc->cur_scp)) { @@ -2384,7 +2377,7 @@ exchange_scr(sc); s = spltty(); /* sc->cur_scp == sc->new_scp */ - wakeup(&sc->cur_scp->smode); + wakeup(VTY_WCHAN(sc,sc->cur_scp->index)); /* wait for the controlling process to acknowledge, if necessary */ if (!signal_vt_acq(sc->cur_scp)) { --Apple-Mail-92--181507418 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks, Alexander. On 23.02.2008, at 2:29, Kostik Belousov wrote: > On Sat, Feb 23, 2008 at 01:01:59AM +0900, Alexander Nedotsukov wrote: >> >> On 22.02.2008, at 0:47, Kostik Belousov wrote: >> >>> On Thu, Feb 21, 2008 at 09:26:16AM +0900, Alexander Nedotsukov >>> wrote: >>>> Hi, >>>> >>>> May I ask to revisit this issue? To me ENXIO is not semantically >>>> correct in this particular case. It also turns out that doing >>>> workaround in userspace may not be that good as we used to think. I >>>> propose is to fix VT_WAITACTIVE so it simply wait for bound device >>>> activation. For my understanding this change should not have any >>>> impact on existing code. I also removed really strange console >>>> cleanup >>>> bit sticked in a long time ago (see ioctl() part). >>>> It will be nice to see this patch >>> >>> >>>> (successfully tested by our affected users) committed to all >>>> branches. >>>> >>>> Thanks, >>>> Alexander. >>> >>> I mostly agree with the patch, given it is tested. >>> >>> The first (not important) note is that change of the wait channel >>> from >>> the address of the private structure to the address of the cdev >>> could >>> cause more spurious wakeups then before. I expect you usermode >>> code to >>> deal with it properly. >> Do you know any potential wakeup()s around the kernel? I did not see >> any spurious wakeups myself nor user reported it so far. However they >> are not welcome so if it considered to be unsafe we can use address >> of >> cdev pointer (&SC_DEV()) which is private to syscons. > Nothing prevents any code in the the kernel from performing wakeup on > any wait channel. Due to tradition, wait channel is usually an address > of some data structure that is owned by the code performing wakeup. > I do not know of any other code that uses cdev address as wait > channel, > > The issue of spurious wakeup is not very important per se. I think > more > essential for the correct operation is the fact that when the user- > mode > code is executed, console may already be inactive (again). This is > quite > similar to the unintended wakeups. > > Does the code handle this ? If yes, I think it shall handle the > wakeups too without any additional actions. > > I underline that this is not an objection against the patch. --Apple-Mail-92--181507418-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 13:19:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01B661065671; Mon, 17 Mar 2008 13:19:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2C98FC18; Mon, 17 Mar 2008 13:19:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JbFFB-0001qf-DN; Mon, 17 Mar 2008 15:19:19 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m2HDJDUD055893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 15:19:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m2HDJ0fB030277; Mon, 17 Mar 2008 15:19:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m2HDIwYk030276; Mon, 17 Mar 2008 15:18:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 17 Mar 2008 15:18:58 +0200 From: Kostik Belousov To: Alexander Nedotsukov Message-ID: <20080317131858.GV10374@deviant.kiev.zoral.com.ua> References: <479796E1.4000500@gmail.com> <1201118159.38742.17.camel@shumai.marcuscom.com> <20080123211149.GA57756@deviant.kiev.zoral.com.ua> <1201123933.62127.9.camel@shumai.marcuscom.com> <20080124124213.GD57756@deviant.kiev.zoral.com.ua> <72E58ECA-D743-4D5E-9222-7129104E4BAC@bbnest.net> <20080221154714.GS57756@deviant.kiev.zoral.com.ua> <20CD87E3-27BC-4789-A51F-BBFDB3258B47@bbnest.net> <20080222172930.GZ57756@deviant.kiev.zoral.com.ua> <641CAF57-F235-4F0D-A120-2B58F0B13861@bbnest.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ucW7QTJbHsz5ya91" Content-Disposition: inline In-Reply-To: <641CAF57-F235-4F0D-A120-2B58F0B13861@bbnest.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 2d4f5d33491be47a8e8639414ad67c6d X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2424 [Mar 17 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: yokota@freebsd.org, FreeBSD Current , Joe Marcus Marcus Clarke Subject: Re: page fault panic in scioctl and console-kit-daemon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 13:19:22 -0000 --ucW7QTJbHsz5ya91 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 17, 2008 at 10:02:39PM +0900, Alexander Nedotsukov wrote: > Better late than never :-) I am back. I understand your concerns and =20 > can assure that use-mode code will do right. I changed wchan address =20 > from system wide cdev pointer to syscons private address. What else =20 > need to be done to get this checked in and/or will you do that or I =20 > can proceed myself? Just commit it. If needed, add Approved by: kib. >=20 >=20 >=20 > Thanks, > Alexander. >=20 > On 23.02.2008, at 2:29, Kostik Belousov wrote: >=20 > >On Sat, Feb 23, 2008 at 01:01:59AM +0900, Alexander Nedotsukov wrote: > >> > >>On 22.02.2008, at 0:47, Kostik Belousov wrote: > >> > >>>On Thu, Feb 21, 2008 at 09:26:16AM +0900, Alexander Nedotsukov =20 > >>>wrote: > >>>>Hi, > >>>> > >>>>May I ask to revisit this issue? To me ENXIO is not semantically > >>>>correct in this particular case. It also turns out that doing > >>>>workaround in userspace may not be that good as we used to think. I > >>>>propose is to fix VT_WAITACTIVE so it simply wait for bound device > >>>>activation. For my understanding this change should not have any > >>>>impact on existing code. I also removed really strange console > >>>>cleanup > >>>>bit sticked in a long time ago (see ioctl() part). > >>>>It will be nice to see this patch > >>> > >>> > >>>>(successfully tested by our affected users) committed to all > >>>>branches. > >>>> > >>>>Thanks, > >>>>Alexander. > >>> > >>>I mostly agree with the patch, given it is tested. > >>> > >>>The first (not important) note is that change of the wait channel =20 > >>>from > >>>the address of the private structure to the address of the cdev =20 > >>>could > >>>cause more spurious wakeups then before. I expect you usermode =20 > >>>code to > >>>deal with it properly. > >>Do you know any potential wakeup()s around the kernel? I did not see > >>any spurious wakeups myself nor user reported it so far. However they > >>are not welcome so if it considered to be unsafe we can use address =20 > >>of > >>cdev pointer (&SC_DEV()) which is private to syscons. > >Nothing prevents any code in the the kernel from performing wakeup on > >any wait channel. Due to tradition, wait channel is usually an address > >of some data structure that is owned by the code performing wakeup. > >I do not know of any other code that uses cdev address as wait =20 > >channel, > > > >The issue of spurious wakeup is not very important per se. I think =20 > >more > >essential for the correct operation is the fact that when the user-=20 > >mode > >code is executed, console may already be inactive (again). This is =20 > >quite > >similar to the unintended wakeups. > > > >Does the code handle this ? If yes, I think it shall handle the > >wakeups too without any additional actions. > > > >I underline that this is not an objection against the patch. >=20 --ucW7QTJbHsz5ya91 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfeb8EACgkQC3+MBN1Mb4h/ngCfUIjHwg5LNzCMagSL88Wfp/TS VTEAoJecqpMnByY/2sC9YhCQ3R9aWFp8 =BCIp -----END PGP SIGNATURE----- --ucW7QTJbHsz5ya91-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 13:46:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB69106564A; Mon, 17 Mar 2008 13:46:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF4E8FC24; Mon, 17 Mar 2008 13:46:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0F18E46C7D; Mon, 17 Mar 2008 09:46:01 -0400 (EDT) Date: Mon, 17 Mar 2008 13:46:00 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Christian S.J. Peron" In-Reply-To: <20080317133029.GA19369@sub.vaned.net> Message-ID: <20080317134335.A3253@fledge.watson.org> References: <20080317133029.GA19369@sub.vaned.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, freebsd-current@freebsd.org Subject: Re: HEADS UP: zerocopy bpf commits impending X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 13:46:01 -0000 On Mon, 17 Mar 2008, Christian S.J. Peron wrote: > Just wanted to give a heads up that I plan to start merging the work located > in the zerocopy bpf perforce branch. We have been working on this project > for about a year now and feel that it is ready to come into the tree. > > I will begin to merge hopefully today [assuming nobody has any concerns] or > tommorow. Zerocopy bpf will be disabled by default, and can be enabled > globally though the use of a sysctl variable. Once the kernel bits are in > and we sort out a couple minor nits in libpcap+tcpdump, we will be be > looking at getting our libpcap patches committed upstream. I will post a > patch for people to experiment with in the meantime after the kernel commits > are complete. > > We do not anticipate this will have any effect on existing bpf consumers > like libpcap, tcpdump etc... so if something breaks, it shouldn't have and > we need to know about :) We were pretty careful about preserving the ABI. > The only exception to this is, netstat will need a recompile because the > size of it's bpf stats structure changed. > > So if there are any objections or concerns, now is the time to raise them. Per previous posts, interested parties can find the slides on the design from the BSDCan 2008 developer summit here: http://www.watson.org/~robert/freebsd/2007bsdcan/20070517-devsummit-zerocopybpf.pdf Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 13:49:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4313C106566C for ; Mon, 17 Mar 2008 13:49:25 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id 158F78FC1E for ; Mon, 17 Mar 2008 13:49:24 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 350A72E1; Mon, 17 Mar 2008 08:30:29 -0500 (CDT) Date: Mon, 17 Mar 2008 08:30:29 -0500 From: "Christian S.J. Peron" To: freebsd-current@freebsd.org Message-ID: <20080317133029.GA19369@sub.vaned.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: HEADS UP: zerocopy bpf commits impending X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 13:49:25 -0000 All, Just wanted to give a heads up that I plan to start merging the work located in the zerocopy bpf perforce branch. We have been working on this project for about a year now and feel that it is ready to come into the tree. I will begin to merge hopefully today [assuming nobody has any concerns] or tommorow. Zerocopy bpf will be disabled by default, and can be enabled globally though the use of a sysctl variable. Once the kernel bits are in and we sort out a couple minor nits in libpcap+tcpdump, we will be be looking at getting our libpcap patches committed upstream. I will post a patch for people to experiment with in the meantime after the kernel commits are complete. We do not anticipate this will have any effect on existing bpf consumers like libpcap, tcpdump etc... so if something breaks, it shouldn't have and we need to know about :) We were pretty careful about preserving the ABI. The only exception to this is, netstat will need a recompile because the size of it's bpf stats structure changed. So if there are any objections or concerns, now is the time to raise them. Thanks From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 14:46:30 2008 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 E7352106567A; Mon, 17 Mar 2008 14:46:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 63C708FC41; Mon, 17 Mar 2008 14:46:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 07A2145F9C; Sat, 15 Mar 2008 15:19:35 +0100 (CET) Received: from localhost (chello087206046210.chello.pl [87.206.46.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F169245F89; Sat, 15 Mar 2008 15:19:29 +0100 (CET) Date: Sat, 15 Mar 2008 15:18:43 +0100 From: Pawel Jakub Dawidek To: Kris Kennaway Message-ID: <20080315141843.GB1958@garage.freebsd.pl> References: <9DA6FFCD-11DB-4580-9314-52B0885351D8@lexasoft.ru> <50186FCD-F67F-4144-BDF1-FB9A7F9AAB64@lexasoft.ru> <47B0AFE6.6070503@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Clx92ZfkiYIKRjnr" Content-Disposition: inline In-Reply-To: <47B0AFE6.6070503@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.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=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Alexey Tarasov , current@freebsd.org Subject: Re: Disappointing speed with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 14:46:31 -0000 --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2008 at 09:28:22PM +0100, Kris Kennaway wrote: > Alexey Tarasov wrote: > >I've done similar tests on the other machine, and all looks fine. > > > >But why on this machine ZFS works slower than UFS? When I make UFS file= =20 > >system on the same disk, rtorrent hashing works 10 times faster. And=20 > >while hashing, HDD is used three times intensively with ZFS (noticed by= =20 > >flashing LED). > > > >I have an amd64 Core2Duo processor, 4 Gb of RAM, what is not enough for= =20 > >ZFS? > > > >What kernel tuning can help me? >=20 > I'd guess this is just related to the ZFS design. As Ivan says, it=20 > prefers to do all writes sequentially. This means that reads (as with=20 > reading of hashes) may be very fragmented and require lots of drive=20 > seeking, which will reduce performance a lot. ZFS does do aggressive=20 > prefetching of data to try and offset this problem, but if your disk=20 > bandwidth is low (e.g. you are not using a fast disk array) then it may= =20 > not help much (and can also introduce big I/O latency for other operation= s). >=20 > As for what can be done about this, I don't know, but you should look=20 > into the general ZFS literature (ZFS support mailing lists, etc). It may also be because ZFS send FLUSH requests to the disk quite often. If disk or controller handles those requests slowly, it may case performance drop when comparing to UFS, which doesn't send FLUSH requests at all. To verify this, one should try disable FLUSH requests sending by adding: vfs.zfs.cache_flush_disable=3D1 to /boot/loader.conf. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Clx92ZfkiYIKRjnr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFH29rDForvXbEpPzQRAuRFAJ9X3uxztqKGmcofOxm5+7VaST0MgACgw5pb bI3u0XVgPM4S786UOjTyAA8= =sGas -----END PGP SIGNATURE----- --Clx92ZfkiYIKRjnr-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 15:55:40 2008 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 ECE66106566C for ; Mon, 17 Mar 2008 15:55:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id AF13D8FC14 for ; Mon, 17 Mar 2008 15:55:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id m2HFteZx042696 for ; Mon, 17 Mar 2008 08:55:40 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id m2HFtesh042695 for current@freebsd.org; Mon, 17 Mar 2008 08:55:40 -0700 (PDT) (envelope-from david) Date: Mon, 17 Mar 2008 08:55:39 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20080317155539.GC53010@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N4K9zxasQOfRkoaJ" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: panic: lock (uidinfo hash) rw does not match earlier (sleep mutex) lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 15:55:41 -0000 --N4K9zxasQOfRkoaJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is with HEAD built today; sources updated from cvsup4.freebsd.org as of about 0330 hrs. US/Pacific. It occurred on the first boot after building/installing CURRENT, and it happens right away -- both on my laptop & my build machine (both i386; build machine is 2x850MHz PIII; laptop is 1x2.4GHz P4); the following is from the build machine: /boot/kernel/acpi.ko text=3D0x540f8 data=3D0x2640+0x186c syms=3D[0x4+0x8b40= +0x4+0xbdcd] GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #72: Mon Mar 17 07:59:39 PDT 2008 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/FREEBEAST WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (846.32-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x683 Stepping =3D 3 Features=3D0x387fbff real memory =3D 2147418112 (2047 MB) avail memory =3D 2093940736 (1996 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 panic: lock (uidinfo hash) rw does not match earlier (sleep mutex) lock cpuid =3D 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt cing pid 0 tid 0 td 0xc0c11470 kdb_enter(c0af1957,c0af1957,c0af64de,c1020c94,0,...) at kdb_enter+0x3a panic(c0af64de,c0af1159,c0afccb7,c0b13b15,c0c12c8c,...) at panic+0x12c enroll(c1020cd8,c075ce2a,c146d5a0,0,c0af1159,...) at enroll+0xe1 witness_init(c0c12c8c,c0bca2cc,c1020cf0) at witness_init+0x109 lock_init(c0c12c8c,c0baf888,c0af1159,0,2a0000) at lock_init+0x89 rw_init_flags(c0c12c8c,c0af1159,0,c1020d44,c0763a15,...) at rw_init_flags+0= xaf uihashinit(c0af0c88,290,c0763bd0,c0763d00,c0763a20,...) at uihashinit+0x51 procinit(c0c12b30,4,c0aec794,176,1,...) at procinit+0x125 proc0_init(0,101ec00,101ec00,101e000,1025000,...) at proc0_init+0x46 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> ps pid ppid pgrp uid state wmesg wchan cmd 0 0 0 0 db> show locks exclusive sleep mutex Giant r =3D 0 (0xc0c12b30) locked @ /usr/src/sys/kern= /kern_linker.c:295 db>=20 (Laptop's results look the same as the above at first blush. Note that the build machine runs headless -- it has neither a monitor nor a keyboard connected now, and these are only connected during unusual circumstances.) As usual, I'm willing to try patches or circumventions. I have serial console access to both the laptop & the build machine, and each has a local private mirror of the FreeBSD CVS repository. Peace, david --=20 David H. Wolfskill david@catwhisker.org I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --N4K9zxasQOfRkoaJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkfelHsACgkQmprOCmdXAD2WtACeKTFzgRTdi89M09Ymh8LhdN7a ORMAn0SUXvEkAII2eA+2YKjcaphD/adr =P4H+ -----END PGP SIGNATURE----- --N4K9zxasQOfRkoaJ-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 16:05:57 2008 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 EE3B41065672 for ; Mon, 17 Mar 2008 16:05:57 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFFA8FC17 for ; Mon, 17 Mar 2008 16:05:57 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id m2HG5v5v042751 for ; Mon, 17 Mar 2008 09:05:57 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id m2HG5vQv042750 for current@freebsd.org; Mon, 17 Mar 2008 09:05:57 -0700 (PDT) (envelope-from david) Date: Mon, 17 Mar 2008 09:05:57 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20080317160557.GD53010@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20080317155539.GC53010@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rSajjWT08XXIcVzz" Content-Disposition: inline In-Reply-To: <20080317155539.GC53010@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: panic: lock (uidinfo hash) rw does not match earlier (sleep mutex) lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 16:05:58 -0000 --rSajjWT08XXIcVzz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Oops -- I should have included the output from "show witness," I think: db> show witness Sleep locks: 0 kernel linker -- last acquired @ /usr/src/sys/kern/kern_linker.c:687 3 UMA zone -- last acquired @ /usr/src/sys/vm/uma_core.c:1830 0 module subsystem sx lock -- last acquired @ /usr/src/sys/kern/kern_module= .c:143 3 UMA zone -- (already displayed) 1 system map -- last acquired @ /usr/src/sys/vm/vm_kern.c:296 3 vm page queue mutex -- last acquired @ /usr/src/sys/i386/i386/pmap.c:23= 13 4 vnode interlock -- last acquired @ order list:0 5 cdev -- last acquired @ order list:0 4 pmap -- last acquired @ /usr/src/sys/i386/i386/pmap.c:2314 2 kmem object -- last acquired @ /usr/src/sys/vm/vm_kern.c:410 3 vm page queue free mutex -- last acquired @ /usr/src/sys/vm/vm_page.c:= 1029 3 vm page queue mutex -- (already displayed) 3 SYSMAPS -- last acquired @ /usr/src/sys/i386/i386/pmap.c:2880 2 KMAP ENTRY -- last acquired @ /usr/src/sys/vm/uma_core.c:2257 3 UMA zone -- (already displayed) 3 UMA zone -- (already displayed) 2 kernel object -- last acquired @ /usr/src/sys/vm/vm_object.c:460 3 vm page queue mutex -- (already displayed) 3 vm page queue free mutex -- (already displayed) 3 SYSMAPS -- (already displayed) 3 vm page queue free mutex -- (already displayed) 3 SYSMAPS -- (already displayed) 2 UMA boot pages -- last acquired @ /usr/src/sys/vm/uma_core.c:916 0 user map -- last acquired @ /usr/src/sys/vm/vm_map.c:1429 3 UMA zone -- (already displayed) 2 UMA boot pages -- (already displayed) 0 kqueue -- last acquired @ order list:0 1 struct mount mtx -- last acquired @ order list:0 4 vnode interlock -- (already displayed) 0 ng_node -- last acquired @ order list:0 1 ng_worklist -- last acquired @ order list:0 0 network driver -- last acquired @ order list:0 0 802.11 com lock -- last acquired @ order list:0 0 nfsd_mtx -- last acquired @ order list:0 2 so_snd -- last acquired @ order list:0 3 so_rcv -- last acquired @ order list:0 4 sellck -- last acquired @ order list:0 4 radix node head -- last acquired @ order list:0 5 rtentry -- last acquired @ order list:0 6 ifaddr -- last acquired @ order list:0 0 bpf global lock -- last acquired @ order list:0 1 bpf interface lock -- last acquired @ order list:0 2 bpf cdev lock -- last acquired @ order list:0 0 ddp_list_mtx -- last acquired @ order list:0 1 ddp_mtx -- last acquired @ order list:0 0 slip_mtx -- last acquired @ order list:0 1 slip sc_mtx -- last acquired @ order list:0 0 tcp -- last acquired @ order list:0 1 tcpinp -- last acquired @ order list:0 2 so_snd -- (already displayed) 0 udp -- last acquired @ order list:0 1 udpinp -- last acquired @ order list:0 2 in_multi_mtx -- last acquired @ order list:0 3 igmp_mtx -- last acquired @ order list:0 4 if_addr_mtx -- last acquired @ order list:0 2 so_snd -- (already displayed) 0 unp -- last acquired @ order list:0 2 so_snd -- (already displayed) 0 accept -- last acquired @ order list:0 2 so_snd -- (already displayed) 0 Giant -- last acquired @ /usr/src/sys/kern/subr_witness.c:565 1 pipe mutex -- last acquired @ order list:0 2 sigio lock -- last acquired @ order list:0 3 process group -- last acquired @ order list:0 4 process lock -- last acquired @ order list:0 5 session -- last acquired @ order list:0 6 uidinfo hash -- last acquired @ order list:0 7 uidinfo struct -- last acquired @ order list:0 3 UMA zone -- (already displayed) 1 system map -- (already displayed) 1 UMA lock -- last acquired @ /usr/src/sys/vm/uma_core.c:1314 1 eventhandler -- last acquired @ /usr/src/sys/kern/subr_eventhandler.c:97 1 eventhandler list -- last acquired @ /usr/src/sys/kern/subr_eventhandler= .c:132 2 UMA boot pages -- (already displayed) 1 kobj -- last acquired @ /usr/src/sys/kern/subr_kobj.c:307 1 kernel environment -- last acquired @ /usr/src/sys/kern/kern_environment= .c:301 1 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:655 3 vm page queue free mutex -- (already displayed) 2 kernel object -- (already displayed) 0 proctree -- last acquired @ order list:0 1 allproc -- last acquired @ order list:0 2 allprison -- last acquired @ order list:0 Spin locks: Locks which were never acquired: p_peers pbuf mutex bufwait bpin lock bdone lock buffer daemon lock needsbuffer lock runningbufspace lock buf queue lock ACPI lid ACPI HPET support ACPI embedded controller ACPI root bus ACPI PCI bus methods ACPI power resources ACPI CPU ACPI PCI power methods ACPI cmbat ACPI generic battery ACPI AC adapter ACPI thermal zone ACPI Smart Battery ACPI PCI link umtxql fdesc bounce pages lock arc4_mtx db_capture_sx encapmtx MSDOSFS fileno mountlist DEVFS ruleset lock kqueue order ip_id_mtx firmware table /dev/mem lock Name Cache net80211 instances securelevel mutex lock rtsock route_cb lock rawcb Softdep Lock pfil_head_list lock protect sysfilt_ops knlist lock for lockless objects acct_sx so_glabel fifo mutex unit# allocation devfs interlock domain list vm daemon accept_filter_mtx intr config clone events drain lock UUID generator mutex lock db_script_mtx ttylist sleep mtxpool sysctl lock phys_pager list dev_pager list swapdev swap_pager list vm map sleep mutex vm object_list PMAP2 vm86 lock db> =20 Peace, david --=20 David H. Wolfskill david@catwhisker.org I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --rSajjWT08XXIcVzz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkfeluQACgkQmprOCmdXAD20uQCeMeFpndzUrsFPQntv/l6QLoQy EeYAn1eakGmkKOXGkQt5WyrXMrYnM+Ao =COZh -----END PGP SIGNATURE----- --rSajjWT08XXIcVzz-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 16:26:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DEA7106566B for ; Mon, 17 Mar 2008 16:26:50 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7B78FC1E for ; Mon, 17 Mar 2008 16:26:50 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from doc175-eva98.evard.ch ([213.142.175.98] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JbIAj-0004hE-8n for freebsd-current@freebsd.org; Mon, 17 Mar 2008 17:26:49 +0100 Message-ID: <47DE9BC7.7040108@FreeBSD.org> Date: Mon, 17 Mar 2008 17:26:47 +0100 From: Pietro Cerutti Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080311) MIME-Version: 1.0 To: freebsd-current X-Enigmail-Version: 0.95.6 OpenPGP: id=9571F78E; url=http://gahr.ch/pgp/ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Subject: [patch] include_once in make X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 16:26:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear list, I have a patch which implements the include_once and sinclude_once keywords in make. I think it would be useful in cases where a double include would mess things up (i.e., ports). http://people.freebsd.org/~gahr/make.diff Any comment is welcome! Regards, - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEAREKAAYFAkfem8cACgkQwMJqmJVx945ZmgCg2XqCpiXfS6heU0z5cMzFiT/5 FvMAoOFYrXQfkQZHGBLXWCAxEha0v7T7 =zOEo -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 17:14:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D28D4106564A for ; Mon, 17 Mar 2008 17:14:52 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4FB8FC19 for ; Mon, 17 Mar 2008 17:14:52 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from doc175-eva98.evard.ch ([213.142.175.98] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JbIvD-0006IO-9C; Mon, 17 Mar 2008 18:14:51 +0100 Message-ID: <47DEA708.8070509@FreeBSD.org> Date: Mon, 17 Mar 2008 18:14:48 +0100 From: Pietro Cerutti Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080311) MIME-Version: 1.0 To: Harti Brandt , freebsd-current References: <47DE9BC7.7040108@FreeBSD.org> <20080317173110.O42984@knop-beagle.kn.op.dlr.de> In-Reply-To: <20080317173110.O42984@knop-beagle.kn.op.dlr.de> X-Enigmail-Version: 0.95.6 OpenPGP: id=9571F78E; url=http://gahr.ch/pgp/ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: Re: [patch] include_once in make X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 17:14:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Harti Brandt wrote: | On Mon, 17 Mar 2008, Pietro Cerutti wrote: | | PC>I have a patch which implements the include_once and sinclude_once | PC>keywords in make. I think it would be useful in cases where a double | PC>include would mess things up (i.e., ports). | PC> | PC>http://people.freebsd.org/~gahr/make.diff | PC> | PC>Any comment is welcome! | | I think your patch silently removes the recently added feature that | Makefiles are only remade when .MAKEFILEDEPS is defined as a target. Uhm.. why should it? | | Style: | | - in Main_AddSourceMakefile you should use the macros and functions from | lst.h instead of rolling your own loop The functions in lst.h don't implement looking for an element comparing lexicographically equal to a given one. It's a specialization of "equals". Better to implement it in lst.c? | - paranthesis missing in return 1. Thanks, fixed | | For the semantics: | | If it's needed, then, well. Given that a Makefile should be declarative | not procedural it looks not strongly necessary, but I may be wrong. It | introduces subtle semantic differences if the included makefile has | procedural elements (.if or .for): | | .include_once Makefile.inc | FOO = 1 | .include_once Makefile.inc | | If Makefile.inc does different things depending on the setting of FOO, bug | hunting will get though, especially if the first .include_once is in and | included file and not easily visible. | | If you're going to commit this, make sure to also document it. | | harti - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEAREKAAYFAkfepwgACgkQwMJqmJVx945BoQCgti30Bsa3OE3P95GwdC3MvOQS Jo0An1s5Druln+5n7QiLJHcMJ75veLe/ =ki7a -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 17:45:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D621106566C for ; Mon, 17 Mar 2008 17:45:13 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 027D38FC26 for ; Mon, 17 Mar 2008 17:45:12 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from doc175-eva98.evard.ch ([213.142.175.98] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JbJOa-0004L6-0N for freebsd-current@freebsd.org; Mon, 17 Mar 2008 18:45:12 +0100 Message-ID: <47DEAE25.8070600@FreeBSD.org> Date: Mon, 17 Mar 2008 18:45:09 +0100 From: Pietro Cerutti Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080311) MIME-Version: 1.0 To: freebsd-current References: <47DE9BC7.7040108@FreeBSD.org> In-Reply-To: <47DE9BC7.7040108@FreeBSD.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=9571F78E; url=http://gahr.ch/pgp/ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [patch] include_once in make X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 17:45:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear all, The updated patch implements the list traversal using the macros in lst.h (thanks Harti Brandt). http://people.freebsd.org/~gahr/make.diff Greetings, Pietro Cerutti wrote: | Dear list, | | I have a patch which implements the include_once and sinclude_once | keywords in make. I think it would be useful in cases where a double | include would mess things up (i.e., ports). | | http://people.freebsd.org/~gahr/make.diff | | Any comment is welcome! | | Regards, | _______________________________________________ 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" - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEAREKAAYFAkferiUACgkQwMJqmJVx946+CgCaA7rKXYY6Vo+3/N5AW2ItnSEY 0coAn1y2jgpmJfw1QX/uvIRVUiL1hcDm =zP7A -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 18:27:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44184106567B for ; Mon, 17 Mar 2008 18:27:29 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id F1E148FC16 for ; Mon, 17 Mar 2008 18:27:28 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbK3R-000666-PN for freebsd-current@freebsd.org; Mon, 17 Mar 2008 18:27:25 +0000 Received: from 89-172-59-221.adsl.net.t-com.hr ([89.172.59.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Mar 2008 18:27:25 +0000 Received: from ivoras by 89-172-59-221.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Mar 2008 18:27:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 17 Mar 2008 19:27:09 +0100 Lines: 29 Message-ID: References: <20080316222433.GA20366@what-creek.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig519D91188B8B31403C3E053C" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-59-221.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: <20080316222433.GA20366@what-creek.com> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: HEADSUP: DTrace support in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 18:27:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig519D91188B8B31403C3E053C Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable John Birrell wrote: > This is an early headsup for DTrace support being committed > to current. I plan to start committing stuff bit-by-bit > starting a week from now, subject to review of the bits. Great news! Could you perhaps update the information on=20 http://dtrace.what-creek.com/ ? --------------enig519D91188B8B31403C3E053C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3rf9ldnAQVacBcgRAgZGAKD1gNOCtV3om3yKKsN161U6rnbNUgCfY0n0 h0WxlkYJY3JR7Zva6LJnMUQ= =CzLu -----END PGP SIGNATURE----- --------------enig519D91188B8B31403C3E053C-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 18:29:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B641065670 for ; Mon, 17 Mar 2008 18:29:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outP.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 408778FC13 for ; Mon, 17 Mar 2008 18:29:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 17 Mar 2008 11:19:21 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 45C582D6018; Mon, 17 Mar 2008 11:19:20 -0700 (PDT) Message-ID: <47DEB62A.4030301@elischer.org> Date: Mon, 17 Mar 2008 11:19:22 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Robert Watson References: <20080317133029.GA19369@sub.vaned.net> <20080317134335.A3253@fledge.watson.org> In-Reply-To: <20080317134335.A3253@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, freebsd-current@freebsd.org, "Christian S.J. Peron" Subject: Re: HEADS UP: zerocopy bpf commits impending X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 18:29:51 -0000 Robert Watson wrote: > On Mon, 17 Mar 2008, Christian S.J. Peron wrote: > >> Just wanted to give a heads up that I plan to start merging the work >> located in the zerocopy bpf perforce branch. We have been working on >> this project for about a year now and feel that it is ready to come >> into the tree. >> >> I will begin to merge hopefully today [assuming nobody has any >> concerns] or tommorow. Zerocopy bpf will be disabled by default, and >> can be enabled globally though the use of a sysctl variable. Once the >> kernel bits are in and we sort out a couple minor nits in >> libpcap+tcpdump, we will be be looking at getting our libpcap patches >> committed upstream. I will post a patch for people to experiment with >> in the meantime after the kernel commits are complete. >> >> We do not anticipate this will have any effect on existing bpf >> consumers like libpcap, tcpdump etc... so if something breaks, it >> shouldn't have and we need to know about :) We were pretty careful >> about preserving the ABI. The only exception to this is, netstat will >> need a recompile because the size of it's bpf stats structure changed. >> >> So if there are any objections or concerns, now is the time to raise >> them. > > Per previous posts, interested parties can find the slides on the design > from the BSDCan 2008 developer summit here: > > > http://www.watson.org/~robert/freebsd/2007bsdcan/20070517-devsummit-zerocopybpf.pdf with the video of the talk at: http://www.freebsd.org/~julian/BSDCan-2007/rwatson_bpf.mov > > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 18:41:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F0B1065670 for ; Mon, 17 Mar 2008 18:41:34 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from atlas57.myplace.ru (atlas57.myplace.ru [80.66.68.57]) by mx1.freebsd.org (Postfix) with ESMTP id A81948FC28 for ; Mon, 17 Mar 2008 18:41:33 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: (qmail 31362 invoked from network); 17 Mar 2008 23:57:03 +0600 Received: from gw.nsib.ru (HELO husky.fjoe.local) (217.117.80.2) by atlas57.myplace.ru with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2008 23:57:03 +0600 Message-ID: <47DEB51B.4040606@samodelkin.net> Date: Tue, 18 Mar 2008 00:14:51 +0600 From: Max Khon User-Agent: Thunderbird 2.0.0.6 (X11/20071028) MIME-Version: 1.0 To: Pietro Cerutti References: <47DE9BC7.7040108@FreeBSD.org> <47DEAE25.8070600@FreeBSD.org> In-Reply-To: <47DEAE25.8070600@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: [patch] include_once in make X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 18:41:34 -0000 Pietro Cerutti wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Dear all, > > The updated patch implements the list traversal using the macros in > lst.h (thanks Harti Brandt). > > http://people.freebsd.org/~gahr/make.diff Looks good 1) Unnecessary junk --- make.orig/Makefile 2008-03-14 22:17:10.000000000 +0100 +++ make/Makefile 2008-03-17 14:54:38.000000000 +0100 @@ -3,7 +3,7 @@ # $FreeBSD: src/usr.bin/make/Makefile,v 1.66 2008/03/04 22:32:58 obrien Exp $ PROG= make -CFLAGS+=-I${.CURDIR} +CFLAGS+=-I${.CURDIR} -ggdb SRCS= arch.c buf.c cond.c dir.c for.c hash.c hash_tables.c job.c \ 2) obey style(9): + LstNode *lNode; + if(once) + LST_FOREACH(lNode, &source_makefiles) + if (!strcmp((char *)Lst_Datum(lNode), name)) + return (1); You should have empty line after lNode declaration. You should have space after "if" statement. You'd better enclose if-statement (and if-statement in LST_FOREACH) into curly braces because they are more than one line long 3) again, missing space after "if" + if(!add_ret) + ParsePushInput(fullname, NULL, NULL, 0); I'd also give "add_ret" other name (more descriptive). > Greetings, > > Pietro Cerutti wrote: > | Dear list, > | > | I have a patch which implements the include_once and sinclude_once > | keywords in make. I think it would be useful in cases where a double > | include would mess things up (i.e., ports). > | > | http://people.freebsd.org/~gahr/make.diff > | > | Any comment is welcome! > | > | Regards, > | > _______________________________________________ > 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" > > - -- > Pietro Cerutti > gahr@FreeBSD.org > > PGP Public Key: > http://gahr.ch/pgp > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (FreeBSD) > > iEYEAREKAAYFAkferiUACgkQwMJqmJVx946+CgCaA7rKXYY6Vo+3/N5AW2ItnSEY > 0coAn1y2jgpmJfw1QX/uvIRVUiL1hcDm > =zP7A > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 18:45:10 2008 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 A2C4B1065681 for ; Mon, 17 Mar 2008 18:45:10 +0000 (UTC) (envelope-from SRS0=a410464dd65c0c447551906f028ffb90325b1994=643=es.net=oberman@es.net) Received: from postal1.es.net (postoffice3.tagpma.org [198.128.3.207]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5EA8FC13 for ; Mon, 17 Mar 2008 18:45:10 +0000 (UTC) (envelope-from SRS0=a410464dd65c0c447551906f028ffb90325b1994=643=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id XUV81426; Mon, 17 Mar 2008 10:30:26 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 9A6F44500F; Mon, 17 Mar 2008 10:30:26 -0700 (PDT) To: "Igor Mozolevsky" In-Reply-To: Your message of "Mon, 17 Mar 2008 03:55:04 -0000." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1205775026_74408P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 17 Mar 2008 10:30:26 -0700 From: "Kevin Oberman" Message-Id: <20080317173026.9A6F44500F@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Igor Mozolevsky X-To_Domain: hybrid-lab.co.uk X-To: "Igor Mozolevsky" X-To_Email: igor@hybrid-lab.co.uk X-To_Alias: igor Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Enhanced SpeedStep hosed in -current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 18:45:10 -0000 --==_Exmh_1205775026_74408P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Mon, 17 Mar 2008 03:55:04 +0000 > From: "Igor Mozolevsky" > Sender: mozolevsky@gmail.com > > On 17/03/2008, Kevin Oberman wrote: > > > Date: Mon, 17 Mar 2008 02:43:19 +0000 > > > From: "Igor Mozolevsky" > > > Sender: owner-freebsd-current@freebsd.org > > > > > > > > On 16/03/2008, Poul-Henning Kamp wrote: > > > > > > > > It looks like my laptop runs full speed at all times, no matter what > > > > powerd or I may desire. > > > > > > > > Looks like the EST driver is (suddenly ?) not happy about the system. > > > > > > I thought that this could've been related to the lapic frequency > > > madness I was seeing in RELENG_7 on my T43p, so I axed cpufreq from > > > kernel config, and the problem's gone... So, it does seem like > > > something is not quite in cpufreq > RELENG_7_0... > > > > > > My experience with my T43 (not T43p) is that it does not play well with > > cpufreq. This is not new to 7-Stable. I have been seeing it since the > > system was new, just over 2 years ago. I always build my kernel without > > it. > > I'm not having lapic issues (or any others, AFAIKT) on my T43p w/ > RELENG_7_0 but RELENG_7 makes it really sluggish w/ cpufreq compiled > in (perl timing tests fail as well)... I have not had any lapic problems to date. I am still running a kernel from Feb. 14, so I have not yeat updated to the on that gave you problems. In addition, sine I always run without cpufreq, I hope to not see it today. I was just reporting that the T43 ran fine without cpufreq including providing the fill array of CPU speeds and resetting the top speed to 800 MHz when on battery. Powerd works just fine in this configuration as does the Gnome Frequency Scaling Monitor and the x86info monitor plug-in for gkrellm. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1205775026_74408P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFH3qqykn3rs5h7N1ERAofKAKCdJ+6OWbCF1LbXI7SRY1dKs3ui/ACfeM6H TiuzzFzdVenWLT2b+zlm+wI= =yxsv -----END PGP SIGNATURE----- --==_Exmh_1205775026_74408P-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 18:45:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFFA4106566B; Mon, 17 Mar 2008 18:45:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6C28FC13; Mon, 17 Mar 2008 18:45:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1F98B46C79; Mon, 17 Mar 2008 14:45:52 -0400 (EDT) Date: Mon, 17 Mar 2008 18:45:52 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <47DEB62A.4030301@elischer.org> Message-ID: <20080317183024.I80049@fledge.watson.org> References: <20080317133029.GA19369@sub.vaned.net> <20080317134335.A3253@fledge.watson.org> <47DEB62A.4030301@elischer.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-2070634317-1205779552=:80049" Cc: arch@freebsd.org, freebsd-current@freebsd.org, "Christian S.J. Peron" Subject: Re: HEADS UP: zerocopy bpf commits impending X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 18:45:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-2070634317-1205779552=:80049 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 17 Mar 2008, Julian Elischer wrote: >> Per previous posts, interested parties can find the slides on the design= =20 >> from the BSDCan 2008 developer summit here: >> >>=20 >> http://www.watson.org/~robert/freebsd/2007bsdcan/20070517-devsummit-zero= copybpf.pdf > > with the video of the talk at: > > http://www.freebsd.org/~julian/BSDCan-2007/rwatson_bpf.mov The primary design change since that time is that we've eliminated the=20 ioctl-driven monitoring and ACKing of shared memory buffers from userspace.= =20 All shared memory consumers must use the shared memory ACK model, and our= =20 libpcap changes do that. This removes redundancy (and complexity) from the= =20 set of ioctls we've added. I've attached the (new) text from bpf.4 below,= =20 which I think captures the changes best. Robert N M Watson Computer Laboratory University of Cambridge BUFFER MODES bpf devices deliver packet data to the application via memory buffers provided by the application. The buffer mode is set using the BIOCSETBUFMODE ioctl, and read using the BIOCGETBUFMODE ioctl. Buffered read mode By default, bpf devices operate in the BPF_BUFMODE_BUFFER mode, in wh= ich packet data is copied explicitly from the kernel to user memory using= the read(2) system call. The user process will declare a fixed buffer si= ze that will be used both for sizing internal buffers and for all read(2= ) operations on the file. This size is queried using the BIOCGBLEN ioc= tl, and is set using the BIOCSBLEN ioctl. Note that an individual packet larger than the buffer size is necessarily truncated. Zero=E2=80=90copy buffer mode bpf devices may also operate in the BPF_BUFMODE_ZEROCOPY mode, in whi= ch packet data is written directly into user memory buffers by the kerne= l, avoiding both system call and copying overhead. Buffers are of fixed (and equal) size, page=E2=80=90aligned, and an even multiple of the p= age size. The maximum zero=E2=80=90copy buffer size is returned by the BIOCGETZ= MAX ioctl. Note that an individual packet larger than the buffer size is necessa= rily truncated. The user process registers two memory buffers using the BIOCSETZBUF ioctl, which accepts a struct bpf_zbuf pointer as an argument: struct bpf_zbuf { void *bz_bufa; void *bz_bufb; size_t bz_buflen; }; bz_bufa is a pointer to the userspace address of the first buffer tha= t will be filled, and bz_bufb is a pointer to the second buffer. bpf w= ill then cycle between the two buffers starting with bz_bufa. Each buffer begins with a fixed=E2=80=90length header to hold synchro= nization=20 and data length information for the buffer: struct bpf_zbuf_header { volatile u_int bzh_kernel_gen; /* Kernel generation number. = */ volatile u_int bzh_kernel_len; /* Length of data in the buff= er.=20 */ volatile u_int bzh_user_gen; /* User generation number. */ /* ...padding for future use... */ }; The header structure of each buffer, including all padding, should be zeroed before it is passed to the ioctl. Remaining space in the buff= er will be used by the kernel to store packet data, laid out in the same format as with buffered read mode. The kernel and the user process follow a simple acknowledgement proto= col via the buffer header to synchronize access to the buffer: when the header generation numbers, bzh_kernel_gen and bzh_user_gen, hold the = same value, the kernel owns the buffer, and when they differ, userspace ow= ns the buffer. While the kernel owns the buffer, the contents are unstable and may change asynchronously; while the user process owns the buffer, its co= n=E2=80=90 tents are stable and will not be changed until the buffer has been acknowledged. Initializing the buffer headers to all 0=E2=80=99s before registering= the=20 buffer has the effect of assigning initial ownership of both buffers to the= =20 ker=E2=80=90 nel. The kernel signals that a buffer has been assigned to userspace= by modifying bzh_kernel_gen, and userspace acknowledges the buffer and returns it to the kernel by setting the value of bzh_user_gen to the value of bzh_kernel_gen. In order to avoid caching and memory re=E2=80=90ordering effects, the= user process must use atomic operations and memory barriers when checking = for and acknowledging buffers: #include /* * Return ownership of a buffer to the kernel for reuse. */ static void buffer_acknowledge(struct bpf_zbuf_header *bzh) { atomic_store_rel_int(&bzh=E2=80=90>bzh_user_gen,=20 bzh=E2=80=90>bzh_kernel_gen); } /* * Check whether a buffer has been assigned to userspace by the kerne= l. * Return true if userspace owns the buffer, and false otherwise. */ static int buffer_check(struct bpf_zbuf_header *bzh) { return (bzh=E2=80=90>bzh_user_gen !=3D atomic_load_acq_int(&bzh=E2=80=90>bzh_kernel_gen)); } The user process may force the assignment of the next buffer, if any = data is pending, to userspace using the BIOCROTZBUF ioctl. This allows th= e user process to retrieve data in a partially filled buffer before the buffer is full, such as following a timeout; the process must check f= or buffer ownership using the header generation numbers, as the buffer w= ill not be assigned if no data was present. As in the buffered read mode, kqueue(2), poll(2), and select(2) may b= e used to sleep awaiting the availbility of a completed buffer. They w= ill return a readable file descriptor when ownership of the next buffer i= s assigned to user space. In the current implementation, the kernel will assign ownership of at most one buffer at a time to the user process. The user processes mu= st acknowledge the current buffer in order to be notified that the next buffer is ready for processing. Programs should not rely on this as = an invariant, as it may change in future versions. --621616949-2070634317-1205779552=:80049-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 18:52:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59195106566B for ; Mon, 17 Mar 2008 18:52:02 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 1AF838FC26 for ; Mon, 17 Mar 2008 18:52:01 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from doc175-eva98.evard.ch ([213.142.175.98] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JbKRE-0002Ot-RP; Mon, 17 Mar 2008 19:52:00 +0100 Message-ID: <47DEBDCD.8000701@FreeBSD.org> Date: Mon, 17 Mar 2008 19:51:57 +0100 From: Pietro Cerutti Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080311) MIME-Version: 1.0 To: Max Khon References: <47DE9BC7.7040108@FreeBSD.org> <47DEAE25.8070600@FreeBSD.org> <47DEB51B.4040606@samodelkin.net> In-Reply-To: <47DEB51B.4040606@samodelkin.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=9571F78E; url=http://gahr.ch/pgp/ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current Subject: Re: [patch] include_once in make X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 18:52:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Max Khon wrote: | Looks good | | 1) Unnecessary junk | 2) obey style(9): | 3) again, missing space after "if" Great, tnx for your comments! http://people.freebsd.org/~gahr/make.diff contains an updated version. - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEAREKAAYFAkfevc0ACgkQwMJqmJVx947VdgCg2RXh+2Dd7oBiNhqN8Qdd7yQO eBUAoM+6UWIuMzbK0V+O2Y4D/7s1KS2m =XH4R -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 19:04:03 2008 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 002CB1065674 for ; Mon, 17 Mar 2008 19:04:02 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 802618FC1F for ; Mon, 17 Mar 2008 19:04:02 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so732043uge.37 for ; Mon, 17 Mar 2008 12:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Ct10I4ifuInGVvIE7wO6ytiRvUM+nXmfo1msEQV/81Q=; b=jD+NM9iKdiy6w/w7fgS6daMfGgptCDjECrJMqGXfnVBTMklPwKAV8Hy7ondPPh3lVhAUArb3JdL3fYB//kIdYa8XYCkUX7QfxnEmQoGgDJqa1tgNaIVVJh6e9aQLuJaS3OFC60moUcPL+3dGHCkRsyKEwCTMduN8JBdLNC9wESE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=s/a+IXq0A5pCbKG9HUs5SIYe5BAPWSMc0RSvZPaOK7eX09usU2ArT3kcR4hneJkdpd+fxyHWcFO3yYnZiC5IJs+VXFJs3Nd+PNyown7VqqByZv+DPQiUy/jKNrxqTtNxcy2up0zZeIR56rClgs/NXA7PqcNtUlSf2tTBXMoxllQ= Received: by 10.67.20.3 with SMTP id x3mr3099135ugi.3.1205780640871; Mon, 17 Mar 2008 12:04:00 -0700 (PDT) Received: by 10.66.248.11 with HTTP; Mon, 17 Mar 2008 12:04:00 -0700 (PDT) Message-ID: Date: Mon, 17 Mar 2008 19:04:00 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Kevin Oberman" In-Reply-To: <20080317173026.9A6F44500F@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080317173026.9A6F44500F@ptavv.es.net> X-Google-Sender-Auth: 5af56e27f63a9544 Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Enhanced SpeedStep hosed in -current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 19:04:03 -0000 On 17/03/2008, Kevin Oberman wrote: > > Date: Mon, 17 Mar 2008 03:55:04 +0000 > > > From: "Igor Mozolevsky" > > > Sender: mozolevsky@gmail.com > > > > > On 17/03/2008, Kevin Oberman wrote: > > > > Date: Mon, 17 Mar 2008 02:43:19 +0000 > > > > From: "Igor Mozolevsky" > > > > Sender: owner-freebsd-current@freebsd.org > > > > > > > > > > > On 16/03/2008, Poul-Henning Kamp wrote: > > > > > > > > > > It looks like my laptop runs full speed at all times, no matter what > > > > > powerd or I may desire. > > > > > > > > > > Looks like the EST driver is (suddenly ?) not happy about the system. > > > > > > > > I thought that this could've been related to the lapic frequency > > > > madness I was seeing in RELENG_7 on my T43p, so I axed cpufreq from > > > > kernel config, and the problem's gone... So, it does seem like > > > > something is not quite in cpufreq > RELENG_7_0... > > > > > > > > > My experience with my T43 (not T43p) is that it does not play well with > > > cpufreq. This is not new to 7-Stable. I have been seeing it since the > > > system was new, just over 2 years ago. I always build my kernel without > > > it. > > > > I'm not having lapic issues (or any others, AFAIKT) on my T43p w/ > > RELENG_7_0 but RELENG_7 makes it really sluggish w/ cpufreq compiled > > in (perl timing tests fail as well)... > > > I have not had any lapic problems to date. I am still running a kernel > from Feb. 14, so I have not yeat updated to the on that gave you > problems. In addition, sine I always run without cpufreq, I hope to not > see it today. > > I was just reporting that the T43 ran fine without cpufreq including > providing the fill array of CPU speeds and resetting the top speed to > 800 MHz when on battery. Powerd works just fine in this configuration as > does the Gnome Frequency Scaling Monitor and the x86info monitor plug-in > for gkrellm. I'll try a full build (as opposed to booting up and checking for lapic problems) with my script w/o cpufreq and see how that goes... Cheers, Igor :-) From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 19:09:26 2008 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 E9FA3106564A for ; Mon, 17 Mar 2008 19:09:26 +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 B34998FC35 for ; Mon, 17 Mar 2008 19:09:26 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id 719F017107; Mon, 17 Mar 2008 19:09:25 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m2HJ9Oau005416; Mon, 17 Mar 2008 19:09:24 GMT (envelope-from phk@critter.freebsd.dk) To: "Igor Mozolevsky" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 17 Mar 2008 19:04:00 GMT." Date: Mon, 17 Mar 2008 19:09:24 +0000 Message-ID: <5415.1205780964@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@freebsd.org Subject: Re: Enhanced SpeedStep hosed in -current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 19:09:27 -0000 In message , "Igor Mozolevsky" writes: >I'll try a full build (as opposed to booting up and checking for lapic >problems) with my script w/o cpufreq and see how that goes... Actually, try instead with the changes I committed to est.c today, that solved the issue for me. -- 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 17 19:53:24 2008 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 D9375106566C for ; Mon, 17 Mar 2008 19:53:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id AE34C8FC27 for ; Mon, 17 Mar 2008 19:53:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id m2HJrO4V043469 for ; Mon, 17 Mar 2008 12:53:24 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id m2HJrOOq043468 for current@freebsd.org; Mon, 17 Mar 2008 12:53:24 -0700 (PDT) (envelope-from david) Date: Mon, 17 Mar 2008 12:53:24 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20080317195324.GF53010@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20080317155539.GC53010@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WU/admihzwO5tdDH" Content-Disposition: inline In-Reply-To: <20080317155539.GC53010@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: panic: lock (uidinfo hash) rw does not match earlier (sleep mutex) lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 19:53:24 -0000 --WU/admihzwO5tdDH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 17, 2008 at 08:55:39AM -0700, David Wolfskill wrote: > This is with HEAD built today; sources updated from cvsup4.freebsd.org > as of about 0330 hrs. US/Pacific. >... rwatson@ suggested that a recent commit by pjd@ may have fixed this issue. I (hand-)applied the fix -- it's for 1.243 of sys/kern/subr_witness.c, and may be seen at -- and each of my laptop and build machine now boot to multi-user mode: localhost(8.0-C)[1] uname -a FreeBSD localhost 8.0-CURRENT FreeBSD 8.0-CURRENT #717: Mon Mar 17 12:42:36= PDT 2008 root@localhost:/common/S4/obj/usr/src/sys/CANARY i386 localhost(8.0-C)[2]=20 freebeast(8.0-C)[1] uname -a FreeBSD freebeast.catwhisker.org 8.0-CURRENT FreeBSD 8.0-CURRENT #73: Mon M= ar 17 12:47:45 PDT 2008 root@freebeast.catwhisker.org:/common/S4/obj/us= r/src/sys/FREEBEAST i386 freebeast(8.0-C)[2]=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --WU/admihzwO5tdDH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkfezDMACgkQmprOCmdXAD0iywCfSQrBRkZLxwHz0Ym/pDv4E9Cc gBsAn0ceQjMUgj+Tp9MJJ0nxPUhxqZ2B =J7qC -----END PGP SIGNATURE----- --WU/admihzwO5tdDH-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 21:42:27 2008 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 79D98106566C; Mon, 17 Mar 2008 21:42:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DCAC88FC1B; Mon, 17 Mar 2008 21:42:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2HLgQMH058507; Mon, 17 Mar 2008 17:42:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2HLgQIx085248; Mon, 17 Mar 2008 17:42:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9650C73039; Mon, 17 Mar 2008 16:42:25 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080317214225.9650C73039@freebsd-current.sentex.ca> Date: Mon, 17 Mar 2008 16:42:25 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 16:43:31 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm 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, 17 Mar 2008 21:42:27 -0000 TB --- 2008-03-17 20:50:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-17 20:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-03-17 20:50:00 - cleaning the object tree TB --- 2008-03-17 20:50:27 - cvsupping the source tree TB --- 2008-03-17 20:50:27 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-03-17 20:50:34 - building world (CFLAGS=-O -pipe) TB --- 2008-03-17 20:50:34 - cd /src TB --- 2008-03-17 20:50:34 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 17 20:50:36 UTC 2008 >>> 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 [...] /src/usr.bin/fstat/zfs/zfs.c:111: warning: implicit declaration of function 'getvnodemount' /src/usr.bin/fstat/zfs/zfs.c:111: warning: nested extern declaration of 'getvnodemount' /src/usr.bin/fstat/zfs/zfs.c:111: warning: assignment makes pointer from integer without a cast /src/usr.bin/fstat/zfs/zfs.c:118: error: dereferencing pointer to incomplete type /src/usr.bin/fstat/zfs/zfs.c:119: error: dereferencing pointer to incomplete type /src/usr.bin/fstat/zfs/zfs.c:125: error: dereferencing pointer to incomplete type /src/usr.bin/fstat/zfs/zfs.c:126: error: dereferencing pointer to incomplete type /src/usr.bin/fstat/zfs/zfs.c:127: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-17 21:42:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-17 21:42:25 - ERROR: failed to build world TB --- 2008-03-17 21:42:25 - tinderbox aborted TB --- 2418.07 user 300.42 system 3144.77 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 17 23:11:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30C79106566B for ; Mon, 17 Mar 2008 23:11:01 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id CF8858FC14 for ; Mon, 17 Mar 2008 23:11:00 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbOTm-0004lx-PF for freebsd-current@freebsd.org; Mon, 17 Mar 2008 23:10:54 +0000 Received: from 89-172-59-221.adsl.net.t-com.hr ([89.172.59.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Mar 2008 23:10:54 +0000 Received: from ivoras by 89-172-59-221.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Mar 2008 23:10:54 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 18 Mar 2008 00:10:42 +0100 Lines: 37 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9AA0AE1463653C0BD44C1CEF" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-59-221.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Panic of 8-CURRENT in VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2008 23:11:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9AA0AE1463653C0BD44C1CEF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > Hi, > I cannot boot a very recent build (minutes ago) of 8-CURRENT on VMWare = > Server. Panic ("integer divide fault" - is this division by zero?) is i= n=20 > sched_rr_interval(). >=20 > More info here: > http://ivoras.sharanet.org/stuff/panic/ >=20 > It might be because I'm trying to run without WITNESS+INVARIANTS. No, building a GENERIC kernel doesn't change anything. It's also not a=20 cvsup glitch - todays sources panic in exactly the same way. --------------enig9AA0AE1463653C0BD44C1CEF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3vpyldnAQVacBcgRAtp1AKDa08cX0R7z6pUMpYHkF9pCndM+LwCgle4i Uq2vmqdEXkYXFFSs99LEdwU= =Enkh -----END PGP SIGNATURE----- --------------enig9AA0AE1463653C0BD44C1CEF-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 00:04:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DF7A1065675 for ; Tue, 18 Mar 2008 00:04:48 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id DDA108FC1C for ; Tue, 18 Mar 2008 00:04:47 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id 2Jr91Z00F0b6N64A10Mv00; Mon, 17 Mar 2008 23:47:52 +0000 Received: from daland.home ([24.61.21.4]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id 2Pol1Z00J05H7zL8P00000; Mon, 17 Mar 2008 23:48:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=rITDv7nW5hcA:10 a=hERRta8RPrzINDqgD-IA:9 a=c6j2NUJ1bn-ayD6sM6wA:7 a=M5MCj7NHZgIFpDi0x38If-sB_9gA:4 a=si9q_4b84H0A:10 a=e0fhMjvlNPMA:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JbP4P-0000hU-L3 for freebsd-current@freebsd.org; Mon, 17 Mar 2008 19:48:45 -0400 From: Alex Goncharov To: freebsd-current@freebsd.org Message-Id: Sender: Alex Goncharov Date: Mon, 17 Mar 2008 19:48:45 -0400 X-Mailman-Approved-At: Tue, 18 Mar 2008 02:15:07 +0000 Subject: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 00:04:48 -0000 [ Sorry if this is old news or not useful ] I am trying to source-upgrade one of my 7.0 systems to 8.0-CURRENT. In the following, when I say "build", it means "csup and build right away". The very first 8.0 build (this morning) gave me the kernel that didn't boot. Built it again, finishing about 15 minutes ago. This one booted all right but I see this in `/var/log/messages': ================================================================================ WARNING: WITNESS option enabled, expect reduced performance. lock order reversal: 1st 0xc4093e28 devfs (devfs) @ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064 2nd 0xc4172b54 devfsmount (devfsmount) @ /mnt/wdx/freebsd/8.0/usr/src/sys/fs/devfs/devfs_vnops.c:201 KDB: stack backtrace: db_trace_self_wrapper(c0af5d71,e2888bbc,c07a70de,c0af8353,c4172b54,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0af8353,c4172b54,c0ae90df,c0ae90df,c0ae9120,...) at kdb_backtrace+0x29 witness_checkorder(c4172b54,9,c0ae9120,c9,c7,...) at witness_checkorder+0x6de _sx_xlock(c4172b54,0,c0ae9120,c9,c4172b54,...) at _sx_xlock+0x7d devfs_allocv(c415db80,c4174000,e2888c28,c3e1ecc0,c0afe288,...) at devfs_allocv+0x144 devfs_root(c4174000,2,c0c67378,c3e1ecc0,ca,...) at devfs_root+0x51 set_rootvnode(c0c67360,0,c0afe288,5f4,c07e4aa0,...) at set_rootvnode+0x2b vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x356 start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65 fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 --- Trying to mount root from ufs:/dev/ad4s1a lock order reversal: 1st 0xc40939e8 ufs (ufs) @ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064 2nd 0xc4174000 vfslock (vfslock) @ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c0af5d71,e28889d8,c07a70de,c0af8353,c4174000,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0af8353,c4174000,c0afe39a,c0afe39a,c0afe937,...) at kdb_backtrace+0x29 witness_checkorder(c4174000,1,c0afe937,16c,e2888a18,...) at witness_checkorder+0x6de _lockmgr_args(c4174000,20001,c4174030,0,ffffffff,...) at _lockmgr_args+0x1d5 vfs_busy(c4174000,0,0,c3e1ecc0,e2888b58,...) at vfs_busy+0x1b0 lookup(e2888b44,c0afe022,c6,bf,c3dee22c,...) at lookup+0x7bf namei(e2888b44,c4174030,1c1,c0afe288,e2888b54,...) at namei+0x34b kern_unlink(c3e1ecc0,c0afe6d9,1,62f,0,...) at kern_unlink+0x40 vfs_mountroot_try(c0afe893,c0aec557,c0ae4ade,1,c07e4aa0,...) at vfs_mountroot_try+0x470 vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x418 start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65 fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 --- lock order reversal: 1st 0xc3e22044 user map (user map) @ /mnt/wdx/freebsd/8.0/usr/src/sys/vm/vm_map.c:3111 2nd 0xc40937c8 ufs (ufs) @ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064 KDB: stack backtrace: db_trace_self_wrapper(c0af5d71,e28889c4,c07a70de,c0af8353,c40937c8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0af8353,c40937c8,c0aece96,c0aece96,c0afe937,...) at kdb_backtrace+0x29 witness_checkorder(c40937c8,1,c0afe937,810,e28889e8,...) at witness_checkorder+0x6de _lockmgr_args(c40937c8,30041,c40937f8,0,ffffffff,...) at _lockmgr_args+0x1d5 ffs_lock(e2888a78,c075fc3d,c0c20554,30041,c4093770,...) at ffs_lock+0xa3 VOP_LOCK1_APV(c0bcbec0,e2888a78,c0aec555,3,c40937f8,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4093770,30041,c0afe937,810,0,...) at _vn_lock+0xf7 vget(c4093770,30041,c3e1ecc0,4a9,c1460600,...) at vget+0x10b vnode_pager_lock(c1460480,0,c0b157d5,127,e2888be8,...) at vnode_pager_lock+0x1ad vm_fault(c3e22000,80cf000,2,8,80cf340,...) at vm_fault+0x1df trap_pfault(5,0,c0b23bd2,2c4,c3e1ccd0,...) at trap_pfault+0x118 trap(e2888d38) at trap+0x259 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- --------------------------------------------------------------------------------= Is this information of any use? I've seen a fair number of messages about LOR on some freebsd lists but was not paying attention -- maybe what I see has already been covered. But in case the above is useful, I can try to provide more information. Thanks, -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 01:21:19 2008 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 82E7B1065672 for ; Tue, 18 Mar 2008 01:21:19 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id CCB448FC26 for ; Tue, 18 Mar 2008 01:21:17 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so836955uge.37 for ; Mon, 17 Mar 2008 18:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=P+fN2uV6wObtsCyg3+fDfd2R4Me+1eNZKN3gfXsB0Uk=; b=niBWEB9Gy6QRkvAuKHJbnfahQjpHP6G2cTHA0KTF7mgUTW1bB0isaR6yXQhOmck/v9KlDjh1yjSxV41Q8/7hZk5gGk10JJM5sVoVxso/J++sRFp0pTqNvaZs2LfHQqJkRJPILqV06H+sumHPf6K05TjscjSTGHYFkBQwi8d3JYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=TSXFdeAv2WobSUp3VLGYBNVLCTlbky8d3MMl4XbhHDE8o4mdksLQHxQciJ8XMOQx7fUR8PBccnJIJUHdpZSm8E0DcB3YJDFn0AdYUqPbFhSLfOdkIsy7AwS15eXaXlkkpsl67Q3hMj8dzZvqFp7XW72sPS/lEIXQVME77GAYxqo= Received: by 10.66.249.8 with SMTP id w8mr3280127ugh.75.1205803276764; Mon, 17 Mar 2008 18:21:16 -0700 (PDT) Received: by 10.66.248.11 with HTTP; Mon, 17 Mar 2008 18:21:16 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 01:21:16 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <5415.1205780964@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_56_30755184.1205803276757" References: <5415.1205780964@critter.freebsd.dk> X-Google-Sender-Auth: a349bf83798a62b7 X-Mailman-Approved-At: Tue, 18 Mar 2008 02:15:21 +0000 Cc: current@freebsd.org Subject: Re: Enhanced SpeedStep hosed in -current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 01:21:19 -0000 ------=_Part_56_30755184.1205803276757 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 17/03/2008, Poul-Henning Kamp wrote: > Actually, try instead with the changes I committed to est.c today, > that solved the issue for me. Ok, so good news and bad news... Good news - lapic frequency madness was not caused by the changes in EST that affected phk@, bad news - it's still happening after phk's changes, see attached. The only way to fix it is by excluding cpufreq from the kernel... Cheers, Igor :-) ------=_Part_56_30755184.1205803276757 Content-Type: application/octet-stream; name=dmesg-RELENG_7-CVS.log Content-Transfer-Encoding: base64 X-Attachment-Id: f_fdxorlz7 Content-Disposition: attachment; filename=dmesg-RELENG_7-CVS.log Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjAtU1RBQkxFICMwOiBNb24gTWFyIDE3IDIxOjIx OjA3IFVUQyAyMDA4CiAgICByb290QGJ1aWxkLWNkOi90bXAvb2JqL3Vzci9zcmMvc3lzL1NFS0hN RVQKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4YzBhZDMw MDAuCkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9jazogMTE5MzE5OCBIegpDTEtf VVNFX0k4MjU0X0NBTElCUkFUSU9OIG5vdCBzcGVjaWZpZWQgLSB1c2luZyBkZWZhdWx0IGZyZXF1 ZW5jeQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApD YWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMjI2MTE2Mzc4MyBIegpDUFU6IElu dGVsKFIpIFBlbnRpdW0oUikgTSBwcm9jZXNzb3IgMi4yNkdIeiAoMjI2MS4xNi1NSHogNjg2LWNs YXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDZkOCAgU3RlcHBpbmcg PSA4CiAgRmVhdHVyZXM9MHhhZmU5ZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0Us Q1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxDTEZMVVNILERUUyxBQ1BJLE1NWCxG WFNSLFNTRSxTU0UyLFNTLFRNLFBCRT4KICBGZWF0dXJlczI9MHgxODA8RVNULFRNMj4KICBBTUQg RmVhdHVyZXM9MHgxMDAwMDA8Tlg+CgpJbnN0cnVjdGlvbiBUTEI6IDQgS0IgUGFnZXMsIDQtd2F5 IHNldCBhc3NvY2lhdGl2ZSwgMTI4IGVudHJpZXMKRGF0YSBUTEI6IDQgS0IgUGFnZXMsIDQtd2F5 IHNldCBhc3NvY2lhdGl2ZSwgMTI4IGVudHJpZXMKSW5zdHJ1Y3Rpb24gVExCOiA0IE1CIHBhZ2Vz LCBmdWxseSBhc3NvY2lhdGl2ZSwgMiBlbnRyaWVzCjJuZC1sZXZlbCBjYWNoZTogMi1NQiwgOC13 YXkgc2V0IGFzc29jaWF0aXZlLCA2NC1ieXRlIGxpbmUgc2l6ZQoxc3QtbGV2ZWwgaW5zdHJ1Y3Rp b24gY2FjaGU6IDMyIEtCLCA4LXdheSBzZXQgYXNzb2NpYXRpdmUsIDY0IGJ5dGUgbGluZSBzaXpl CkRhdGEgVExCOiA0IE1CIFBhZ2VzLCA0LXdheSBzZXQgYXNzb2NpYXRpdmUsIDggZW50cmllcwox c3QtbGV2ZWwgZGF0YSBjYWNoZTogMzIgS0IsIDgtd2F5IHNldCBhc3NvY2lhdGl2ZSwgNjQgYnl0 ZSBsaW5lIHNpemUKTDIgY2FjaGU6IDIwNDgga2J5dGVzLCA4LXdheSBhc3NvY2lhdGl2ZSwgNjQg Ynl0ZXMvbGluZQpyZWFsIG1lbW9yeSAgPSAyMTQ2MjM4NDY0ICgyMDQ2IE1CKQpQaHlzaWNhbCBt ZW1vcnkgY2h1bmsocyk6CjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5ZGZmZiwg NjQzMDcyIGJ5dGVzICgxNTcgcGFnZXMpCjB4MDAwMDAwMDAwMDEwMDAwMCAtIDB4MDAwMDAwMDAw MDNmZmZmZiwgMzE0NTcyOCBieXRlcyAoNzY4IHBhZ2VzKQoweDAwMDAwMDAwMDBjMjgwMDAgLSAw eDAwMDAwMDAwN2RhODRmZmYsIDIwOTU0MzU3NzYgYnl0ZXMgKDUxMTU4MSBwYWdlcykKYXZhaWwg bWVtb3J5ID0gMjA5NDkzMTk2OCAoMTk5NyBNQikKVGFibGUgJ0ZBQ1AnIGF0IDB4N2ZlZDcxMDAK VGFibGUgJ1NTRFQnIGF0IDB4N2ZlZDcyYjQKVGFibGUgJ0VDRFQnIGF0IDB4N2ZlZTRkZmMKVGFi bGUgJ1RDUEEnIGF0IDB4N2ZlZTRlNGUKVGFibGUgJ0FQSUMnIGF0IDB4N2ZlZTRlODAKTUFEVDog Rm91bmQgdGFibGUgYXQgMHg3ZmVlNGU4MApBUElDOiBVc2luZyB0aGUgTUFEVCBlbnVtZXJhdG9y LgpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAwIEFDUEkgSUQgMTogZW5hYmxlZApTTVA6IEFkZGVk IENQVSAwIChBUCkKQUNQSSBBUElDIFRhYmxlOiA8SUJNICAgIFRQLTFZICAgPgpiaW9zMzI6IEZv dW5kIEJJT1MzMiBTZXJ2aWNlIERpcmVjdG9yeSBoZWFkZXIgYXQgMHhjMDBmNmJiMApiaW9zMzI6 IEVudHJ5ID0gMHhmZDc2MCAoYzAwZmQ3NjApICBSZXYgPSAwICBMZW4gPSAxCnBjaWJpb3M6IFBD SSBCSU9TIGVudHJ5IGF0IDB4ZmQ2ZjArMHgyMDcKcG5wYmlvczogRm91bmQgUG5QIEJJT1MgZGF0 YSBhdCAweGMwMGY2YzMwCnBucGJpb3M6IEVudHJ5ID0gZjAwMDA6YjU5NiAgUmV2ID0gMS4wCnBu cGJpb3M6IEV2ZW50IGZsYWcgYXQgNGI0Ck90aGVyIEJJT1Mgc2lnbmF0dXJlcyBmb3VuZDoKQVBJ QzogQ1BVIDAgaGFzIEFDUEkgSUQgMQpVTEU6IHNldHVwIGNwdSBncm91cCAwClVMRTogc2V0dXAg Y3B1IDAKVUxFOiBhZGRpbmcgY3B1IDAgdG8gZ3JvdXAgMDogY3B1cyAxIG1hc2sgMHgxCkFDUEk6 IFJTRFAgQCAweDB4ZjZjMDAvMHgwMDI0ICh2ICAyIElCTSAgICkKQUNQSTogWFNEVCBAIDB4MHg3 ZmVkNmZlNy8weDAwNUMgKHYgIDEgSUJNICAgIFRQLTFZICAgIDB4MDAwMDEyOTAgIExUUCAweDAw MDAwMDAwKQpBQ1BJOiBGQUNQIEAgMHgweDdmZWQ3MTAwLzB4MDBGNCAodiAgMyBJQk0gICAgVFAt MVkgICAgMHgwMDAwMTI5MCBJQk0gIDB4MDAwMDAwMDEpCkFDUEkgV2FybmluZyAodGJmYWR0LTA1 MDUpOiBPcHRpb25hbCBmaWVsZCAiR3BlMUJsb2NrIiBoYXMgemVybyBhZGRyZXNzIG9yIGxlbmd0 aDogICAgICAgIDAgICAgMTAyQy8wIFsyMDA3MDMyMF0KQUNQSTogRFNEVCBAIDB4MHg3ZmVkNzJl Ny8weERCMTUgKHYgIDEgSUJNICAgIFRQLTFZICAgIDB4MDAwMDEyOTAgTVNGVCAweDAxMDAwMDBF KQpBQ1BJOiBGQUNTIEAgMHgweDdmZWY2MDAwLzB4MDA0MApBQ1BJOiBTU0RUIEAgMHgweDdmZWQ3 MmI0LzB4MDAzMyAodiAgMSBJQk0gICAgVFAtMVkgICAgMHgwMDAwMTI5MCBNU0ZUIDB4MDEwMDAw MEUpCkFDUEk6IEVDRFQgQCAweDB4N2ZlZTRkZmMvMHgwMDUyICh2ICAxIElCTSAgICBUUC0xWSAg ICAweDAwMDAxMjkwIElCTSAgMHgwMDAwMDAwMSkKQUNQSTogVENQQSBAIDB4MHg3ZmVlNGU0ZS8w eDAwMzIgKHYgIDEgSUJNICAgIFRQLTFZICAgIDB4MDAwMDEyOTAgUFRMICAweDAwMDAwMDAxKQpB Q1BJOiBBUElDIEAgMHgweDdmZWU0ZTgwLzB4MDA1QSAodiAgMSBJQk0gICAgVFAtMVkgICAgMHgw MDAwMTI5MCBJQk0gIDB4MDAwMDAwMDEpCkFDUEk6IE1DRkcgQCAweDB4N2ZlZTRlZGEvMHgwMDND ICh2ICAxIElCTSAgICBUUC0xWSAgICAweDAwMDAxMjkwIElCTSAgMHgwMDAwMDAwMSkKQUNQSTog Qk9PVCBAIDB4MHg3ZmVlNGZkOC8weDAwMjggKHYgIDEgSUJNICAgIFRQLTFZICAgIDB4MDAwMDEy OTAgIExUUCAweDAwMDAwMDAxKQpNQURUOiBGb3VuZCBJTyBBUElDIElEIDEsIEludGVycnVwdCAw IGF0IDB4ZmVjMDAwMDAKaW9hcGljMDogQ2hhbmdpbmcgQVBJQyBJRCB0byAxCmlvYXBpYzA6IFJv dXRpbmcgZXh0ZXJuYWwgODI1OUEncyAtPiBpbnRwaW4gMApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJp ZGU6IHNvdXJjZSAwLCBpcnEgMgppb2FwaWMwOiBSb3V0aW5nIElSUSAwIC0+IGludHBpbiAyCk1B RFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDksIGlycSA5CmlvYXBpYzA6IGludHBpbiA5 IHRyaWdnZXI6IGxldmVsCmxhcGljMDogUm91dGluZyBOTUkgLT4gTElOVDEKbGFwaWMwOiBMSU5U MSB0cmlnZ2VyOiBlZGdlCmxhcGljMDogTElOVDEgcG9sYXJpdHk6IGhpZ2gKaW9hcGljMCA8VmVy c2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApjcHUwIEJTUDoKICAgICBJRDogMHgw MDAwMDAwMCAgIFZFUjogMHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZm CiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNW UjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjog MHgwMDAxMDAwMCBwY206IDB4MDAwMTAwMDAKc25kX3VuaXRfaW5pdCgpIHU9MHgwMGZmODAwMCBb NTEyXSBkPTB4MDAwMDdjMDAgWzMyXSBjPTB4MDAwMDAzZmYgWzEwMjRdCmZlZWRlcl9yZWdpc3Rl cjogc25kX3VuaXQ9LTEgc25kX21heGF1dG92Y2hhbnM9MTYgbGF0ZW5jeT01IGZlZWRlcl9idWZm ZXJzaXplPTE2Mzg0IGZlZWRlcl9yYXRlX21pbj0xIGZlZWRlcl9yYXRlX21heD0yMDE2MDAwIGZl ZWRlcl9yYXRlX3JvdW5kPTI1CndsYW5fYW1ycjogPEFNUlIgVHJhbnNtaXQgUmF0ZSBDb250cm9s IEFsZ29yaXRobT4Kd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPgphdGhfcmF0ZTogdmVyc2lvbiAx LjIgPFNhbXBsZVJhdGUgYml0LXJhdGUgc2VsZWN0aW9uIGFsZ29yaXRobT4KcmFuZG9tOiA8ZW50 cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKY3J5 cHRvOiA8Y3J5cHRvIGNvcmU+CmtiZDogbmV3IGFycmF5IHNpemUgNAprYmQxIGF0IGtiZG11eDAK bWVtOiA8bWVtb3J5PgpQZW50aXVtIFBybyBNVFJSIHN1cHBvcnQgZW5hYmxlZAppY2h3ZCBtb2R1 bGUgbG9hZGVkCmlvOiA8SS9PPgpudWxsOiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgphdGhf aGFsOiAwLjkuMjAuMyAoQVI1MjEwLCBBUjUyMTEsIEFSNTIxMiwgUkY1MTExLCBSRjUxMTIsIFJG MjQxMywgUkY1NDEzKQpucHgwOiBJTlQgMTYgaW50ZXJmYWNlCmFjcGkwOiA8SUJNIFRQLTFZPiBv biBtb3RoZXJib2FyZAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkpIHRvIHZl Y3RvciA0OAphY3BpMDogW01QU0FGRV0KYWNwaTA6IFtJVEhSRUFEXQphY3BpX2VjMDogPEVtYmVk ZGVkIENvbnRyb2xsZXI6IEdQRSAweDFjLCBFQ0RUPiBwb3J0IDB4NjIsMHg2NiBvbiBhY3BpMApw Y2lfb3BlbigxKToJbW9kZSAxIGFkZHIgcG9ydCAoMHgwY2Y4KSBpcyAweDgwMDBmYTA0CnBjaV9v cGVuKDFhKToJbW9kZTFyZXM9MHg4MDAwMDAwMCAoMHg4MDAwMDAwMCkKcGNpX2NmZ2NoZWNrOglk ZXZpY2UgMCBbY2xhc3M9MDYwMDAwXSBbaGRyPTAwXSBpcyB0aGVyZSAoaWQ9MjU5MDgwODYpCnBj aWJpb3M6IEJJT1MgdmVyc2lvbiAyLjEwCkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5N SENTIC0+IGJ1cyAwIGRldiAwIGZ1bmMgMApBY3BpT3NEZXJpdmVQY2lJZDogXFxfU0JfLlBDSTAu VVNCNy5VN0NTIC0+IGJ1cyAwIGRldiAyOSBmdW5jIDcKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4 ZWQpCmFjcGkwOiB3YWtldXAgY29kZSB2YSAweGQ4Yzk1MDAwIHBhIDB4MTAwMApBY3BpT3NEZXJp dmVQY2lJZDogXFxfU0JfLlBDSTAuTFBDXy5MUENTIC0+IGJ1cyAwIGRldiAzMSBmdW5jIDAKYWNw aTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9u IG9mIDEwMDAwMCwgN2ZmMDAwMDAgKDMpIGZhaWxlZApBQ1BJIHRpbWVyOiAxLzIgMS8yIDEvMiAx LzEgMS8xIDEvMSAxLzEgMS8xIDEvMiAxLzEgLT4gMTAKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIg ZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRp bWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24gYWNwaTAKcGNpX2xpbmsw OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAg IDAgICAxMCAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCiAgVmFsaWRhdGlvbiAgICAgICAg ICAwICAgMTAgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIEFmdGVyIERpc2FibGUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKcGNpX2xpbmsxOiAgICAgICAg SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAgMyAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgIDMg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKcGNpX2xpbmsyOiAgICAgICAgSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAg IDMgNCA1IDYgNyA5IDEwIDExCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNiA3IDkgMTAgMTEKcGNpX2xpbmszOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYg NyA5IDEwIDExCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2 IDcgOSAxMCAxMQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUg NiA3IDkgMTAgMTEKcGNpX2xpbms0OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDEx CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAx MQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAg MTEKcGNpX2xpbms1OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFs IFByb2JlICAgICAgIDAgICAgNiAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCiAgVmFsaWRh dGlvbiAgICAgICAgICAwICAgIDYgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIEFmdGVy IERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKcGNpX2xp bms2OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAg ICAgIDAgICAgNSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCiAgVmFsaWRhdGlvbiAgICAg ICAgICAwICAgIDUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIEFmdGVyIERpc2FibGUg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKcGNpX2xpbms3OiAgICAg ICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAx MSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAg MTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIEFmdGVyIERpc2FibGUgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3Bp MAplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwCmVz dDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDMxMDQsIDM2MjEpCmVzdDA6IEludmFsaWQg ZnJlcSAxNjAwLCBpZ25vcmVkLgplc3QwOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgyMDcx LCAyNTg4KQplc3QwOiBJbnZhbGlkIGZyZXEgMTA2NiwgaWdub3JlZC4KcDR0Y2MwOiA8Q1BVIEZy ZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRo b2QgTGlkIFN3aXRjaD4gb24gYWNwaTAKYWNwaV9idXR0b24wOiA8U2xlZXAgQnV0dG9uPiBvbiBh Y3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFj cGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6IGRvbWFpbj0wLCBwaHlzaWNh bCBidXM9MApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI1OTAsIHJldmlkPTB4MDMKCWRv bWFpbj0wLCBidXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgyMDkwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjU5MSwgcmV2aWQ9MHgw MwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5 cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MGMgKDMwMDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQpwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC4xLklOVEEKcGNpYjA6IHNsb3QgMSBJTlRBIGhhcmR3aXJlZCB0byBJ UlEgMTYKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNjYwLCByZXZpZD0weDAzCglkb21h aW49MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgw MSwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej04IChk d29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBE MCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQpwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4yOC5JTlRBCnBjaWIwOiBzbG90IDI4IElOVEEgaGFyZHdpcmVkIHRvIElSUSAy MApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI2NjQsIHJldmlkPTB4MDMKCWRvbWFpbj0w LCBidXM9MCwgc2xvdD0yOCwgZnVuYz0yCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBt ZmRldj0xCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTggKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJaW50cGluPWMsIGlycT01Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMg IGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKcGNpYjA6IG1hdGNoZWQgZW50cnkg Zm9yIDAuMjguSU5UQwpwY2liMDogc2xvdCAyOCBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMjIKZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNjU4LCByZXZpZD0weDAzCglkb21haW49MCwgYnVz PTAsIHNsb3Q9MjksIGZ1bmM9MAoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1hLCBpcnE9MTAKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBi YXNlIDB4MTgwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4y OS5JTlRBCnBjaWIwOiBzbG90IDI5IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgpmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDI2NTksIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD0yOSwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy ZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50 cGluPWIsIGlycT0zCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDE4 MjAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQgpw Y2liMDogc2xvdCAyOSBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTcKZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgyNjVhLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1 bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw NSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBp cnE9MTEKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTg0MCwgc2l6 ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRDCnBjaWIwOiBz bG90IDI5IElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDI2NWIsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0zCglj bGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0 cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWQsIGlycT0xMQoJ bWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxODYwLCBzaXplICA1LCBl bmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEQKcGNpYjA6IHNsb3QgMjkg SU5URCBoYXJkd2lyZWQgdG8gSVJRIDE5CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjY1 YywgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTcKCWNsYXNzPTBj LTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgw MjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49ZCwgaXJxPTExCglwb3dlcnNw ZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCBy YW5nZSAzMiwgYmFzZSAweGIwMDAwMDAwLCBzaXplIDEwLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjI5LklOVEQKcGNpYjA6IHNsb3QgMjkgSU5URCBoYXJkd2lyZWQgdG8gSVJR IDE5CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjQ0OCwgcmV2aWQ9MHhkMwoJZG9tYWlu PTAsIGJ1cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAxLCBoZHJ0eXBlPTB4MDEs IG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjY2ZSwgcmV2aWQ9MHgw MwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMwLCBmdW5jPTIKCWNsYXNzPTA0LTAxLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJh c2UgMHgxYzAwLCBzaXplICA4LCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweDE4ODAsIHNpemUgIDYsIGVuYWJsZWQKCW1hcFsxOF06IHR5cGUgTWVtb3J5 LCByYW5nZSAzMiwgYmFzZSAweGIwMDAwODAwLCBzaXplICA5LCBlbmFibGVkCgltYXBbMWNdOiB0 eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhiMDAwMDQwMCwgc2l6ZSAgOCwgZW5hYmxlZApw Y2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4zMC5JTlRBCnBjaWIwOiBzbG90IDMwIElOVEEgaGFy ZHdpcmVkIHRvIElSUSAyMgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI2NmQsIHJldmlk PTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMCwgZnVuYz0zCgljbGFzcz0wNy0wMy0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1 cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweDI0MDAsIHNpemUgIDgsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgSS9PIFBvcnQs IHJhbmdlIDMyLCBiYXNlIDB4MjAwMCwgc2l6ZSAgNywgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4zMC5JTlRCCnBjaWIwOiBzbG90IDMwIElOVEIgaGFyZHdpcmVkIHRvIElSUSAy Mwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI2NDEsIHJldmlkPTB4MDMKCWRvbWFpbj0w LCBidXM9MCwgc2xvdD0zMSwgZnVuYz0wCgljbGFzcz0wNi0wMS0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDIwMCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI2NTMsIHJldmlkPTB4MDMKCWRv bWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0yCgljbGFzcz0wMS0wMS04MCwgaGRydHlwZT0w eDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglt YXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDE4YzAsIHNpemUgIDQsIGVu YWJsZWQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNjZhLCByZXZpZD0weDAzCglkb21h aW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MwoJY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwMSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChk d29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJh bmdlIDMyLCBiYXNlIDB4MThlMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRy eSBmb3IgMC4zMS5JTlRBCnBjaWIwOiBzbG90IDMxIElOVEEgaGFyZHdpcmVkIHRvIElSUSAyMwpw Y2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAK cGNpYjE6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAx CnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAg MHgzMDAwLTB4M2ZmZgpwY2liMTogICBtZW1vcnkgZGVjb2RlICAgICAweGIwMTAwMDAwLTB4YjAx ZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhjMDAwMDAwMC0weGM3ZmZmZmZmCnBj aTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9 MQpmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRldj0weDMxNTQsIHJldmlkPTB4ODAKCWRvbWFpbj0w LCBidXM9MSwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1m ZGV2PTAKCWNtZHJlZz0weDAxMDMsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9OCAoZHdvcmRz KQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIg RDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEwXTog dHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGMwMDAwMDAwLCBzaXpl IDI3LCBlbmFibGVkCnBjaWIxOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4YzAwMDAwMDAtMHhj N2ZmZmZmZjogZ29vZAoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgz MDAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIxOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MzAwMC0w eDMwZmY6IGluIHJhbmdlCgltYXBbMThdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhi MDEwMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liMTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAw eGIwMTAwMDAwLTB4YjAxMGZmZmY6IGdvb2QKcGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDEuMC5J TlRBCnBjaWIxOiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CnZnYXBjaTA6IDxWR0Et Y29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4MzAwMC0weDMwZmYgbWVtIDB4YzAwMDAwMDAtMHhj N2ZmZmZmZiwweGIwMTAwMDAwLTB4YjAxMGZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNp MQpkcm0wOiA8QVRJIEZpcmVHTCBNMjQgR0w+IG9uIHZnYXBjaTAKaW5mbzogW2RybV0gSW5pdGlh bGl6ZWQgcmFkZW9uIDEuMjUuMCAyMDA2MDUyNApwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGlycSAyMCBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaWIyOiAgIGRvbWFpbiAgICAgICAgICAg IDAKcGNpYjI6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRpbmF0ZSBidXMg ICAyCnBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZgpwY2liMjogICBtZW1v cnkgZGVjb2RlICAgICAweGIwMjAwMDAwLTB4YjAyZmZmZmYKcGNpYjI6ICAgbm8gcHJlZmV0Y2hl ZCBkZWNvZGUKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpMjogZG9tYWluPTAsIHBo eXNpY2FsIGJ1cz0yCmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4MTY3ZCwgcmV2aWQ9MHgx MQoJZG9tYWluPTAsIGJ1cz0yLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwMiwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDggbWVzc2FnZXMsIDY0IGJpdAoJbWFw WzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4YjAyMDAwMDAsIHNpemUgMTYsIGVu YWJsZWQKcGNpYjI6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhiMDIwMDAwMC0weGIwMjBmZmZm OiBnb29kCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjAuSU5UQQpwY2liMjogc2xvdCAwIElO VEEgaGFyZHdpcmVkIHRvIElSUSAxNgpwY2kwOjI6MDowOiBiYWQgVlBEIGNrc3VtLCByZW1haW4g MTQKYmdlMDogPEJyb2FkY29tIE5ldFh0cmVtZSBHaWdhYml0IEV0aGVybmV0IENvbnRyb2xsZXIs IEFTSUMgcmV2LiAweDQxMDE+IG1lbSAweGIwMjAwMDAwLTB4YjAyMGZmZmYgaXJxIDE2IGF0IGRl dmljZSAwLjAgb24gcGNpMgpiZ2UwOiBSZXNlcnZlZCAweDEwMDAwIGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDMgYXQgMHhiMDIwMDAwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmdlMApicmdwaHkw OiA8QkNNNTc1MCAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1paWJ1czAKYnJncGh5 MDogT1VJIDB4MDAwODE4LCBtb2RlbCAweDAwMTgsIHJldi4gMApicmdwaHkwOiAgMTBiYXNlVCwg MTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFz ZVQtRkRYLCBhdXRvCmJnZTA6IGJwZiBhdHRhY2hlZApiZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAw MDoxNjo0MTo1MzpmZDpiMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNiAoUENJIElSUSAxNikg dG8gdmVjdG9yIDQ5CmJnZTA6IFtNUFNBRkVdCmJnZTA6IFtJVEhSRUFEXQpwY2liMzogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGlycSAyMiBhdCBkZXZpY2UgMjguMiBvbiBwY2kwCnBjaWIzOiAgIGRv bWFpbiAgICAgICAgICAgIDAKcGNpYjM6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMwpwY2liMzogICBz dWJvcmRpbmF0ZSBidXMgICAxMApwY2liMzogICBJL08gZGVjb2RlICAgICAgICAweDQwMDAtMHg0 ZmZmCnBjaWIzOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4YjIwMDAwMDAtMHhiM2ZmZmZmZgpwY2li MzogICBwcmVmZXRjaGVkIGRlY29kZSAweGM4MDAwMDAwLTB4YzgwZmZmZmYKcGNpMzogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjMKcGNpMzogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0zCnVoY2kwOiA8 SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0 IDB4MTgwMC0weDE4MWYgaXJxIDE2IGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdWhjaTA6IFJlc2Vy dmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDE4MDAKdWhjaTA6IFtHSUFO VC1MT0NLRURdCnVoY2kwOiBbSVRIUkVBRF0KdXNiMDogPEludGVsIDgyODAxRkIvRlIvRlcvRlJX IChJQ0g2KSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9u IDEuMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4w MCwgYWRkciAxPiBvbiB1c2IwCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAp1aGNpMTogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJv bGxlciBVU0ItQj4gcG9ydCAweDE4MjAtMHgxODNmIGlycSAxNyBhdCBkZXZpY2UgMjkuMSBvbiBw Y2kwCnVoY2kxOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHgx ODIwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE3IChQQ0kgSVJRIDE3KSB0byB2ZWN0b3IgNTAK dWhjaTE6IFtHSUFOVC1MT0NLRURdCnVoY2kxOiBbSVRIUkVBRF0KdXNiMTogPEludGVsIDgyODAx RkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBVU0ItQj4gb24gdWhjaTEKdXNiMTog VVNCIHJldmlzaW9uIDEuMAp1aHViMTogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwg cmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IxCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMjogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2 KSBVU0IgY29udHJvbGxlciBVU0ItQz4gcG9ydCAweDE4NDAtMHgxODVmIGlycSAxOCBhdCBkZXZp Y2UgMjkuMiBvbiBwY2kwCnVoY2kyOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0 eXBlIDQgYXQgMHgxODQwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE4IChQQ0kgSVJRIDE4KSB0 byB2ZWN0b3IgNTEKdWhjaTI6IFtHSUFOVC1MT0NLRURdCnVoY2kyOiBbSVRIUkVBRF0KdXNiMjog PEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBVU0ItQz4gb24g dWhjaTIKdXNiMjogVVNCIHJldmlzaW9uIDEuMAp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBodWIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IyCnVodWIyOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMzogPEludGVsIDgyODAxRkIvRlIv RlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBVU0ItRD4gcG9ydCAweDE4NjAtMHgxODdmIGly cSAxOSBhdCBkZXZpY2UgMjkuMyBvbiBwY2kwCnVoY2kzOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZv ciByaWQgMHgyMCB0eXBlIDQgYXQgMHgxODYwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE5IChQ Q0kgSVJRIDE5KSB0byB2ZWN0b3IgNTIKdWhjaTM6IFtHSUFOVC1MT0NLRURdCnVoY2kzOiBbSVRI UkVBRF0KdXNiMzogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxl ciBVU0ItRD4gb24gdWhjaTMKdXNiMzogVVNCIHJldmlzaW9uIDEuMAp1aHViMzogPEludGVsIFVI Q0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IzCnVo dWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPEludGVs IDgyODAxRkIgKElDSDYpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4YjAwMDAwMDAtMHhiMDAw MDNmZiBpcnEgMTkgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNpMDogUmVzZXJ2ZWQgMHg0MDAg Ynl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGIwMDAwMDAwCmVoY2kwOiBbR0lBTlQtTE9D S0VEXQplaGNpMDogW0lUSFJFQURdCnVzYjQ6IEVIQ0kgdmVyc2lvbiAxLjAKdXNiNDogY29tcGFu aW9uIGNvbnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjAgdXNiMSB1c2IyIHVzYjMKdXNiNDog PEludGVsIDgyODAxRkIgKElDSDYpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKdXNiNDog VVNCIHJldmlzaW9uIDIuMAp1aHViNDogPEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwg cmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2I0CnVodWI0OiA4IHBvcnRzIHdpdGggOCByZW1v dmFibGUsIHNlbGYgcG93ZXJlZApwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAzMC4wIG9uIHBjaTAKcGNpYjQ6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNDogICBzZWNv bmRhcnkgYnVzICAgICAxMQpwY2liNDogICBzdWJvcmRpbmF0ZSBidXMgICAxNApwY2liNDogICBJ L08gZGVjb2RlICAgICAgICAweDUwMDAtMHg4ZmZmCnBjaWI0OiAgIG1lbW9yeSBkZWNvZGUgICAg IDB4YjQwMDAwMDAtMHhiZmZmZmZmZgpwY2liNDogICBwcmVmZXRjaGVkIGRlY29kZSAweGQwMDAw MDAwLTB4ZDdmZmZmZmYKcGNpYjQ6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVkIGJyaWRnZS4KcGNp MTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnBjaTExOiBkb21haW49MCwgcGh5c2ljYWwgYnVz PTExCmZvdW5kLT4JdmVuZG9yPTB4MTE4MCwgZGV2PTB4MDQ3NiwgcmV2aWQ9MHg4ZAoJZG9tYWlu PTAsIGJ1cz0xMSwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTA3LTAwLCBoZHJ0eXBlPTB4MDIs IG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDgwICgzMjAwMCBucyksIG1h eGxhdD0weDA3ICgxNzUwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2Ug MzIsIGJhc2UgMHhiNDAxMDAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liNDogcmVxdWVzdGVkIG1l bW9yeSByYW5nZSAweGI0MDEwMDAwLTB4YjQwMTBmZmY6IGdvb2QKcGNpYjQ6IG1hdGNoZWQgZW50 cnkgZm9yIDExLjAuSU5UQQpwY2liNDogc2xvdCAwIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgpm b3VuZC0+CXZlbmRvcj0weDE2OGMsIGRldj0weDEwMTQsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBi dXM9MTEsIHNsb3Q9MiwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wCgljbWRyZWc9MHgwMzE2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTggKGR3b3JkcykK CWxhdHRpbWVyPTB4NTAgKDI0MDAgbnMpLCBtaW5nbnQ9MHgwYSAoMjUwMCBucyksIG1heGxhdD0w eDFjICg3MDAwIG5zKQoJaW50cGluPWEsIGlycT02Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGI0 MDAwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWI0OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4 YjQwMDAwMDAtMHhiNDAwZmZmZjogZ29vZApwY2liNDogbWF0Y2hlZCBlbnRyeSBmb3IgMTEuMi5J TlRBCnBjaWI0OiBzbG90IDIgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIxCmNiYjA6IDxSRjVDNDc2 IFBDSS1DYXJkQnVzIEJyaWRnZT4gbWVtIDB4YjQwMTAwMDAtMHhiNDAxMGZmZiBpcnEgMTYgYXQg ZGV2aWNlIDAuMCBvbiBwY2kxMQpjYmIwOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAw eDEwIHR5cGUgMyBhdCAweGI0MDEwMDAwCmNhcmRidXMwOiA8Q2FyZEJ1cyBidXM+IG9uIGNiYjAK cGNjYXJkMDogPDE2LWJpdCBQQ0NhcmQgYnVzPiBvbiBjYmIwCmNiYjA6IFtNUFNBRkVdCmNiYjA6 IFtJVEhSRUFEXQpjYmIwOiBQQ0kgQ29uZmlndXJhdGlvbiBzcGFjZToKICAweDAwOiAweDA0NzYx MTgwIDB4MDIxMDAxMDcgMHgwNjA3MDA4ZCAweDAwODI0MDAwIAogIDB4MTA6IDB4YjQwMTAwMDAg MHgwMjAwMDBkYyAweGIwMGUwYzBiIDB4ZmZmZmYwMDAgCiAgMHgyMDogMHgwMDAwMDAwMCAweGZm ZmZmMDAwIDB4MDAwMDAwMDAgMHhmZmZmZmZmYyAKICAweDMwOiAweDAwMDAwMDAwIDB4ZmZmZmZm ZmMgMHgwMDAwMDAwMCAweDA3MDAwMTEwIAogIDB4NDA6IDB4MDU2YzEwMTQgMHgwMDAwMDAwMSAw eDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg1MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAw MDAwMDAgMHgwMDAwMDAwMCAKICAweDYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAw MCAweDAwMDAwMDAwIAogIDB4NzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4 MDAwMDAwMDAgCiAgMHg4MDogMHgwNDgwMDAwMSAweDAwMDAwMDAwIDB4MDQ2MzA0NjQgMHgwMDAw MDAwMCAKICAweDkwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAw IAogIDB4YTA6IDB4MDAwYTAwMDAgMHgwMDAwMDAwMCAweDAwZjAwMDAwIDB4MDAwMDAwMDAgCiAg MHhiMDogMHgwMDAwMDAwMCAweGZlMDAwMDAwIDB4MDAwMDM4MDAgMHgwMDAwMDAwMCAKICAweGMw OiAweDA1NmMxMDE0IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4ZDA6IDB4 MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4ZmUwYTAwMDEgCiAgMHhlMDogMHgyNGMw NDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGYwOiAweDAwMDAwMDAw IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAphdGgwOiA8QXRoZXJvcyA1MjEyPiBt ZW0gMHhiNDAwMDAwMC0weGI0MDBmZmZmIGlycSAyMSBhdCBkZXZpY2UgMi4wIG9uIHBjaTExCmF0 aDA6IFJlc2VydmVkIDB4MTAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGI0MDAw MDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQQ0kgSVJRIDIxKSB0byB2ZWN0b3IgNTMK YXRoMDogW01QU0FGRV0KYXRoMDogW0lUSFJFQURdCmF0aDA6IGhhbCBjaGFubmVsIDI0MTIvYTAg LT4gMQphdGgwOiBoYWwgY2hhbm5lbCAyNDEyL2MwIC0+IDEKYXRoMDogaGFsIGNoYW5uZWwgMjQx Ny9hMCAtPiAyCmF0aDA6IGhhbCBjaGFubmVsIDI0MTcvYzAgLT4gMgphdGgwOiBoYWwgY2hhbm5l bCAyNDIyL2EwIC0+IDMKYXRoMDogaGFsIGNoYW5uZWwgMjQyMi9jMCAtPiAzCmF0aDA6IGhhbCBj aGFubmVsIDI0MjcvYTAgLT4gNAphdGgwOiBoYWwgY2hhbm5lbCAyNDI3L2MwIC0+IDQKYXRoMDog aGFsIGNoYW5uZWwgMjQzMi9hMCAtPiA1CmF0aDA6IGhhbCBjaGFubmVsIDI0MzIvYzAgLT4gNQph dGgwOiBoYWwgY2hhbm5lbCAyNDM3L2EwIC0+IDYKYXRoMDogaGFsIGNoYW5uZWwgMjQzNy9jMCAt PiA2CmF0aDA6IGhhbCBjaGFubmVsIDI0NDIvYTAgLT4gNwphdGgwOiBoYWwgY2hhbm5lbCAyNDQy L2MwIC0+IDcKYXRoMDogaGFsIGNoYW5uZWwgMjQ0Ny9hMCAtPiA4CmF0aDA6IGhhbCBjaGFubmVs IDI0NDcvYzAgLT4gOAphdGgwOiBoYWwgY2hhbm5lbCAyNDUyL2EwIC0+IDkKYXRoMDogaGFsIGNo YW5uZWwgMjQ1Mi9jMCAtPiA5CmF0aDA6IGhhbCBjaGFubmVsIDI0NTcvYTAgLT4gMTAKYXRoMDog aGFsIGNoYW5uZWwgMjQ1Ny9jMCAtPiAxMAphdGgwOiBoYWwgY2hhbm5lbCAyNDYyL2EwIC0+IDEx CmF0aDA6IGhhbCBjaGFubmVsIDI0NjIvYzAgLT4gMTEKYXRoMDogaGFsIGNoYW5uZWwgNTE3MC8z NDAgLT4gMzQKYXRoMDogaGFsIGNoYW5uZWwgNTE4MC8zNDAgLT4gMzYKYXRoMDogaGFsIGNoYW5u ZWwgNTE5MC8zNDAgLT4gMzgKYXRoMDogaGFsIGNoYW5uZWwgNTIwMC8zNDAgLT4gNDAKYXRoMDog aGFsIGNoYW5uZWwgNTIxMC8zNDAgLT4gNDIKYXRoMDogaGFsIGNoYW5uZWwgNTIyMC8zNDAgLT4g NDQKYXRoMDogaGFsIGNoYW5uZWwgNTIzMC8zNDAgLT4gNDYKYXRoMDogaGFsIGNoYW5uZWwgNTI0 MC8zNDAgLT4gNDgKYXRoMDogaGFsIGNoYW5uZWwgNTI2MC8zNDAgLT4gNTIKYXRoMDogaGFsIGNo YW5uZWwgNTI4MC8zNDAgLT4gNTYKYXRoMDogaGFsIGNoYW5uZWwgNTMwMC8zNDAgLT4gNjAKYXRo MDogaGFsIGNoYW5uZWwgNTMyMC8zNDAgLT4gNjQKYXRoMDogaGFsIGNoYW5uZWwgNTUwMC8zNDAg LT4gMTAwCmF0aDA6IGhhbCBjaGFubmVsIDU1MjAvMzQwIC0+IDEwNAphdGgwOiBoYWwgY2hhbm5l bCA1NTQwLzM0MCAtPiAxMDgKYXRoMDogaGFsIGNoYW5uZWwgNTU2MC8zNDAgLT4gMTEyCmF0aDA6 IGhhbCBjaGFubmVsIDU1ODAvMzQwIC0+IDExNgphdGgwOiBoYWwgY2hhbm5lbCA1NjAwLzM0MCAt PiAxMjAKYXRoMDogaGFsIGNoYW5uZWwgNTYyMC8zNDAgLT4gMTI0CmF0aDA6IGhhbCBjaGFubmVs IDU2NDAvMzQwIC0+IDEyOAphdGgwOiBoYWwgY2hhbm5lbCA1NjYwLzM0MCAtPiAxMzIKYXRoMDog aGFsIGNoYW5uZWwgNTY4MC8zNDAgLT4gMTM2CmF0aDA6IGhhbCBjaGFubmVsIDU3MDAvMzQwIC0+ IDE0MAphdGgwOiBoYWwgY2hhbm5lbCA1NzQ1LzM0MCAtPiAxNDkKYXRoMDogaGFsIGNoYW5uZWwg NTc2NS8zNDAgLT4gMTUzCmF0aDA6IGhhbCBjaGFubmVsIDU3ODUvMzQwIC0+IDE1NwphdGgwOiBo YWwgY2hhbm5lbCA1ODA1LzM0MCAtPiAxNjEKYXRoMDogaGFsIGNoYW5uZWwgNTgyNS8zNDAgLT4g MTY1CmF0aDA6IHVzaW5nIG9ic29sZXRlZCBpZl93YXRjaGRvZyBpbnRlcmZhY2UKYXRoMDogYnBm IGF0dGFjaGVkCmF0aDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE5OjdlOjA2OjAyOmRjCmF0aDA6 IGJwZiBhdHRhY2hlZAphdGgwOiBicGYgYXR0YWNoZWQKYXRoMDogMTFhIHJhdGVzOiA2TWJwcyA5 TWJwcyAxMk1icHMgMThNYnBzIDI0TWJwcyAzNk1icHMgNDhNYnBzIDU0TWJwcwphdGgwOiAxMWIg cmF0ZXM6IDFNYnBzIDJNYnBzIDUuNU1icHMgMTFNYnBzCmF0aDA6IDExZyByYXRlczogMU1icHMg Mk1icHMgNS41TWJwcyAxMU1icHMgNk1icHMgOU1icHMgMTJNYnBzIDE4TWJwcyAyNE1icHMgMzZN YnBzIDQ4TWJwcyA1NE1icHMKYXRoMDogbWFjIDUuOSBwaHkgNC4zIHJhZGlvIDMuNgphdGgwOiBV c2UgaHcgcXVldWUgMSBmb3IgV01FX0FDX0JFIHRyYWZmaWMKYXRoMDogVXNlIGh3IHF1ZXVlIDAg Zm9yIFdNRV9BQ19CSyB0cmFmZmljCmF0aDA6IFVzZSBodyBxdWV1ZSAyIGZvciBXTUVfQUNfVkkg dHJhZmZpYwphdGgwOiBVc2UgaHcgcXVldWUgMyBmb3IgV01FX0FDX1ZPIHRyYWZmaWMKYXRoMDog VXNlIGh3IHF1ZXVlIDggZm9yIENBQiB0cmFmZmljCmF0aDA6IFVzZSBodyBxdWV1ZSA5IGZvciBi ZWFjb25zCnBjbTA6IDxJbnRlbCBJQ0g2ICg4MjgwMUZCKT4gcG9ydCAweDFjMDAtMHgxY2ZmLDB4 MTg4MC0weDE4YmYgbWVtIDB4YjAwMDA4MDAtMHhiMDAwMDlmZiwweGIwMDAwNDAwLTB4YjAwMDA0 ZmYgaXJxIDIyIGF0IGRldmljZSAzMC4yIG9uIHBjaTAKcGNtMDogUmVzZXJ2ZWQgMHgyMDAgYnl0 ZXMgZm9yIHJpZCAweDE4IHR5cGUgMyBhdCAweGIwMDAwODAwCnBjbTA6IFJlc2VydmVkIDB4MTAw IGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDMgYXQgMHhiMDAwMDQwMAppb2FwaWMwOiByb3V0aW5n IGludHBpbiAyMiAoUENJIElSUSAyMikgdG8gdmVjdG9yIDU0CnBjbTA6IFtNUFNBRkVdCnBjbTA6 IFtJVEhSRUFEXQpwY20wOiA8QW5hbG9nIERldmljZXMgQUQxOTgxQiBBQzk3IENvZGVjIChpZCA9 IDB4NDE0NDUzNzQpPgpwY20wOiBDb2RlYyBmZWF0dXJlcyBoZWFkcGhvbmUsIDIwIGJpdCBEQUMs IDUgYml0IG1hc3RlciB2b2x1bWUsIG5vIDNEIFN0ZXJlbyBFbmhhbmNlbWVudApwY20wOiBQcmlt YXJ5IGNvZGVjIGV4dGVuZGVkIGZlYXR1cmVzIHZhcmlhYmxlIHJhdGUgUENNLCBBTUFQLCByZXNl cnZlZCA0CnBjbTA6IGFjOTcgY29kZWMgZGFjIHJlYWR5IGNvdW50OiAwCnBjbTA6IE1peGVyICJ2 b2wiOgpwY20wOiBNaXhlciAicGNtIjoKcGNtMDogTWl4ZXIgImxpbmUiOgpwY20wOiBNaXhlciAi bWljIjoKcGNtMDogTWl4ZXIgImNkIjoKcGNtMDogTWl4ZXIgInJlYyI6CnBjbTA6IE1peGVyICJp Z2FpbiI6CnBjbTA6IE1peGVyICJvZ2FpbiI6CnBjbTA6IE1peGVyICJsaW5lMSI6CnBjbTA6IE1p eGVyICJwaGluIjoKcGNtMDogTWl4ZXIgInBob3V0IjoKcGNtMDogY2xvbmUgbWFuYWdlcjogZGVh ZGxpbmU9NzUwbXMgZmxhZ3M9MHg4MDAwMDAxZQpwY20wOiBzbmRidWZfc2V0bWFwIDEzY2MwMDAs IDQwMDA7IDB4ZTUzNmUwMDAgLT4gMTNjYzAwMApwY20wOiBzbmRidWZfc2V0bWFwIDEzZDQwMDAs IDQwMDA7IDB4ZTUzNzIwMDAgLT4gMTNkNDAwMApwY2kwOiA8c2ltcGxlIGNvbW1zLCBnZW5lcmlj IG1vZGVtPiBhdCBkZXZpY2UgMzAuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1J U0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2Fi MAphdGFwY2kwOiA8SW50ZWwgSUNINk0gU0FUQTE1MCBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4 MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4MThjMC0weDE4Y2YgYXQgZGV2aWNlIDMxLjIg b24gcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQg YXQgMHgxOGMwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2Vy dmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MWYwCmF0YXBjaTA6IFJlc2Vy dmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4M2Y2CmF0YTA6IHJlc2V0IHRw MSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMDogc3RhdDA9MHg1MCBlcnI9MHgwMSBs c2I9MHgwMCBtc2I9MHgwMAphdGEwOiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDAwIG1zYj0w eDAwCmF0YTA6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFT VEVSPgppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNCAoSVNBIElSUSAxNCkgdG8gdmVjdG9yIDU1 CmF0YTA6IFtNUFNBRkVdCmF0YTA6IFtJVEhSRUFEXQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24g YXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBh dCAweDE3MAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBh dCAweDM3NgphdGExOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTE6 IHN0YXQwPTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMTogc3RhdDE9MHgwMCBl cnI9MHgwMCBsc2I9MHgwMCBtc2I9MHgwMAphdGExOiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9 MDAgZGV2aWNlcz0weDQ8QVRBUElfTUFTVEVSPgppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNSAo SVNBIElSUSAxNSkgdG8gdmVjdG9yIDU2CmF0YTE6IFtNUFNBRkVdCmF0YTE6IFtJVEhSRUFEXQpp Y2hzbWIwOiA8SW50ZWwgODI4MDFGQiAoSUNINikgU01CdXMgY29udHJvbGxlcj4gcG9ydCAweDE4 ZTAtMHgxOGZmIGlycSAyMyBhdCBkZXZpY2UgMzEuMyBvbiBwY2kwCmljaHNtYjA6IFJlc2VydmVk IDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDE4ZTAKaW9hcGljMDogcm91dGlu ZyBpbnRwaW4gMjMgKFBDSSBJUlEgMjMpIHRvIHZlY3RvciA1NwppY2hzbWIwOiBbR0lBTlQtTE9D S0VEXQppY2hzbWIwOiBbSVRIUkVBRF0Kc21idXMwOiA8U3lzdGVtIE1hbmFnZW1lbnQgQnVzPiBv biBpY2hzbWIwCnNtYjA6IDxTTUJ1cyBnZW5lcmljIEkvTz4gb24gc21idXMwCmFjcGlfdHowOiA8 VGhlcm1hbCBab25lPiBvbiBhY3BpMApzcGVha2VyMDogPFBDIHNwZWFrZXI+IHBvcnQgMHg2MSBv biBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAs MHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRj MAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAwNDcKYXRr YmQ6IGtleWJvYXJkIElEIDB4NTRhYiAoMikKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQwLCBB VCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKaW9hcGljMDogcm91dGlu ZyBpbnRwaW4gMSAoSVNBIElSUSAxKSB0byB2ZWN0b3IgNTgKYXRrYmQwOiBbR0lBTlQtTE9DS0VE XQphdGtiZDA6IFtJVEhSRUFEXQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRCnBzbWNwbnAw OiA8UFMvMiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAKcHNtMDogY3VycmVudCBjb21tYW5k IGJ5dGU6MDA0Nwpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKaW9hcGljMDog cm91dGluZyBpbnRwaW4gMTIgKElTQSBJUlEgMTIpIHRvIHZlY3RvciA1OQpwc20wOiBbR0lBTlQt TE9DS0VEXQpwc20wOiBbSVRIUkVBRF0KcHNtMDogbW9kZWwgU3luYXB0aWNzIFRvdWNocGFkLCBk ZXZpY2UgSUQgMC0wMCwgMyBidXR0b25zCnBzbTA6IGNvbmZpZzowMDAwNjAwMCwgZmxhZ3M6MDAw MDAwMDgsIHBhY2tldCBzaXplOjYKcHNtMDogc3luY21hc2s6YzAsIHN5bmNiaXRzOjAwCnNpbzA6 IGlycSBtYXBzOiAweDhlNjkgMHg4ZTc5IDB4OGU2OSAweDhlNjkKc2lvMDogaXJxIG1hcHM6IDB4 OGU2OSAweDhlNzkgMHg4ZTY5IDB4OGU2OQpzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBv cnQ+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBl IDE2NTUwQQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA0IChJU0EgSVJRIDQpIHRvIHZlY3RvciA2 MApzaW8wOiBbRklMVEVSXQpwcGMwOiB1c2luZyBleHRlbmRlZCBJL08gcG9ydCByYW5nZQpQQzg3 M3h4IHByb2JlIGF0IDB4MmUgZ290IHVua25vd24gSUQgMHgwCnBwYzA6IEVDUCBTUFAgRUNQK0VQ UCBTUFAKcHBjMDogPFBhcmFsbGVsIHBvcnQ+IHBvcnQgMHgzNzgtMHgzN2YsMHg3NzgtMHg3N2Yg aXJxIDcgZHJxIDMgb24gYWNwaTAKcHBjMDogU01DLWxpa2UgY2hpcHNldCAoRUNQL0VQUC9QUzIv TklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMDogRklGTyB3aXRoIDE2LzE2LzggYnl0ZXMg dGhyZXNob2xkCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMwCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDcgKElTQSBJUlEgNykgdG8gdmVjdG9yIDYxCnBwYnVzMDogW01QU0FGRV0K cHBidXMwOiBbSVRIUkVBRF0KbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1 cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMwCnBwYzA6IFtHSUFO VC1MT0NLRURdCnBwYzA6IFtJVEhSRUFEXQpiYXR0ZXJ5MDogPEFDUEkgQ29udHJvbCBNZXRob2Qg QmF0dGVyeT4gb24gYWNwaTAKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmFjcGlf aWJtMDogPElCTSBUaGlua1BhZCBBQ1BJIEV4dHJhcz4gb24gYWNwaTAKY3J5cHRvc29mdDA6IDxz b2Z0d2FyZSBjcnlwdG8+IG9uIG1vdGhlcmJvYXJkCmNyeXB0bzogYXNzaWduIGNyeXB0b3NvZnQw IGRyaXZlciBpZCAwLCBmbGFncyAxMDA2NjMyOTYKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3Rl cnMgYWxnIDEgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJz IGFsZyAyIGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBh bGcgMyBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxn IDQgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyA1 IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTYg ZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyA2IGZs YWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgNyBmbGFn cyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDE4IGZsYWdz IDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTkgZmxhZ3Mg MCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAyMCBmbGFncyAw IG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDggZmxhZ3MgMCBt YXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxNSBmbGFncyAwIG1h eG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDkgZmxhZ3MgMCBtYXhv cGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxMCBmbGFncyAwIG1heG9w bGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDEzIGZsYWdzIDAgbWF4b3Bs ZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTQgZmxhZ3MgMCBtYXhvcGxl biAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxMSBmbGFncyAwIG1heG9wbGVu IDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDIxIGZsYWdzIDAgbWF4b3BsZW4g MApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTcgZmxhZ3MgMCBtYXhvcGxlbiAw CmlzYWIwOiBmb3VuZCBJQ0g2IG9yIGVxdWl2YWxlbnQgY2hpcHNldDogSW50ZWwgSUNINk0gd2F0 Y2hkb2cgdGltZXIKYXRhOiBhdGEwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphdGE6IGF0 YTEgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0a2JkYzogYXRrYmRjMCBhbHJlYWR5IGV4 aXN0czsgc2tpcHBpbmcgaXQKcHBjOiBwcGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApz aW86IHNpbzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnBucF9pZGVudGlmeTogVHJ5aW5n IFJlYWRfUG9ydCBhdCAyMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0Mwpw bnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjgzCnBucF9pZGVudGlmeTogVHJ5aW5n IFJlYWRfUG9ydCBhdCAyYzMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDMwMwpw bnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzQzCnBucF9pZGVudGlmeTogVHJ5aW5n IFJlYWRfUG9ydCBhdCAzODMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDNjMwpQ TlAgSWRlbnRpZnkgY29tcGxldGUKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQK dmdhOiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJvYmVfY2hpbGRyZW46 IGRpc2FibGluZyBQblAgZGV2aWNlcwppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcgbm9uLVBu UCBkZXZpY2VzCmljaHdkMDogPEludGVsIElDSDZNIHdhdGNoZG9nIHRpbWVyPiBvbiBpc2EwCmlz YWIwOiBmb3VuZCBJQ0g2IG9yIGVxdWl2YWxlbnQgY2hpcHNldDogSW50ZWwgSUNINk0gd2F0Y2hk b2cgdGltZXIKaWNod2QwOiBJbnRlbCBJQ0g2TSB3YXRjaGRvZyB0aW1lciAoSUNINiBvciBlcXVp dmFsZW50KQppY2h3ZDA6IHRpbWVyIGRpc2FibGVkCnBtdGltZXIwIG9uIGlzYTAKb3JtMDogPElT QSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGNmZmZmLDB4ZDE4MDAtMHhkMjdmZiww eGUwMDAwLTB4ZWZmZmYgcG5waWQgT1JNMDAwMCBvbiBpc2EwCmFkdjA6IG5vdCBwcm9iZWQgKGRp c2FibGVkKQphaGEwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKYWljMDogbm90IHByb2JlZCAoZGlz YWJsZWQpCmJ0MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmNzMDogbm90IHByb2JlZCAoZGlzYWJs ZWQpCmVkMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmZkYzAgZmFpbGVkIHRvIHByb2JlIGF0IHBv cnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNhMApmZTA6IG5vdCBwcm9iZWQg KGRpc2FibGVkKQppZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpsZTA6IG5vdCBwcm9iZWQgKGRp c2FibGVkKQpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6 IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNjMDogZmIwLCBrYmQxLCB0 ZXJtaW5hbCBlbXVsYXRvcjogc2MgKHN5c2NvbnMgdGVybWluYWwpCnNpbzE6IGNvbmZpZ3VyZWQg aXJxIDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzE6IHBvcnQgbWF5IG5vdCBi ZSBlbmFibGVkCnNpbzE6IGlycSBtYXBzOiAweDhlZTkgMHg4ZWU5IDB4OGVlOSAweDhlZTkKc2lv MTogcHJvYmUgZmFpbGVkIHRlc3Qocyk6IDAgMSAyIDQgNiA3IDkKc2lvMSBmYWlsZWQgdG8gcHJv YmUgYXQgcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2EwCnNpbzI6IG5vdCBwcm9iZWQgKGRp c2FibGVkKQpzaW8zOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc24wOiBub3QgcHJvYmVkIChkaXNh YmxlZCkKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAw eGEwMDAwLTB4YmZmZmYgb24gaXNhMAp2dDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQppc2FfcHJv YmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKdWdlbjA6IDxTVE1pY3JvZWxlY3Ryb25p Y3MgQmlvbWV0cmljIENvcHJvY2Vzc29yLCBjbGFzcyAwLzAsIHJldiAxLjAwLzAuMDEsIGFkZHIg Mj4gb24gdWh1YjIKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuClJlZHVjaW5nIGtlcm4u bWF4dm5vZGVzIDEzNDI5MCAtPiAxMDAwMDAKcHJvY2ZzIHJlZ2lzdGVyZWQKbGFwaWM6IERpdmlz b3IgMiwgRnJlcXVlbmN5IDE4ODQzMDMxOSBoegpUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kg MjI2MTE2Mzc4MyBIeiBxdWFsaXR5IDgwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBt c2VjCnZsYW46IGluaXRpYWxpemVkLCB1c2luZyBoYXNoIHRhYmxlcyB3aXRoIGNoYWluaW5nCkZh c3QgSVBzZWM6IEluaXRpYWxpemVkIFNlY3VyaXR5IEFzc29jaWF0aW9uIFByb2Nlc3NpbmcuCmVu YzA6IGJwZiBhdHRhY2hlZApsbzA6IGJwZiBhdHRhY2hlZApwZmxvZzA6IGJwZiBhdHRhY2hlZAph dGEwLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2FibGU9ODAgd2ly ZQpiYXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBzdGFydAphY3BpX2FjYWQwOiBhY2xp bmUgaW5pdGlhbGl6YXRpb24gc3RhcnQKYWQwOiA5NTM5Nk1CIDxTZWFnYXRlIFNUOTEwMDIxQSAz LjA0PiBhdCBhdGEwLW1hc3RlciBVRE1BMTAwCmFkMDogMTk1MzcxNTY4IHNlY3RvcnMgWzE5Mzgy MUMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpHRU9NOiBuZXcg ZGlzayBhZDAKYXRhMS1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMzMgY2Fi bGU9ODAgd2lyZQphY2QwOiA8TUFUU0hJVEFEVkQtUkFNIFVKLTg1Mi9SQjAxPiBEVkRSIGRyaXZl IGF0IGF0YTEgYXMgbWFzdGVyCmFjZDA6IHJlYWQgNDEzNEtCL3MgKDQxMzRLQi9zKSB3cml0ZSA0 MTM0S0IvcyAoNDEzNEtCL3MpLCAyMDQ4S0IgYnVmZmVyLCBVRE1BMzMKYWNkMDogUmVhZHM6IENE UiwgQ0RSVywgQ0REQSBzdHJlYW0sIERWRFJPTSwgRFZEUiwgRFZEUkFNLCBwYWNrZXQKYWNkMDog V3JpdGVzOiBDRFIsIENEUlcsIERWRFIsIERWRFJBTSwgdGVzdCB3cml0ZSwgYnVybnByb29mCmFj ZDA6IEF1ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206IGVqZWN0 YWJsZSB0cmF5LCB1bmxvY2tlZAphY2QwOiBNZWRpdW06IG5vL2JsYW5rIGRpc2MKYmF0dGVyeTA6 IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1lcwphY3BpX2FjYWQwOiBP biBMaW5lCmFjcGlfYWNhZDA6IGFjbGluZSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAxIHRp bWVzCnBjbTA6IG1lYXN1cmVkIGFjOTcgbGluayByYXRlIGF0IDQ3OTk5IEh6LCB3aWxsIHVzZSA0 ODAwMCBIegpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkMGEKc3RhcnRfaW5p dDogdHJ5aW5nIC9zYmluL2luaXQKYmdlMDogbGluayBVUAo= ------=_Part_56_30755184.1205803276757 Content-Type: application/octet-stream; name=dmesg-RELENG_7_0-ISO.log Content-Transfer-Encoding: base64 X-Attachment-Id: f_fdxorrak Content-Disposition: attachment; filename=dmesg-RELENG_7_0-ISO.log Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjAtUkVMRUFTRSAjMDogU3VuIEZlYiAyNCAxOTo1 OTo1MiBVVEMgMjAwOAogICAgcm9vdEBsb2dhbi5jc2UuYnVmZmFsby5lZHU6L3Vzci9vYmovdXNy L3NyYy9zeXMvR0VORVJJQwpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5l bCIgYXQgMHhjMGRkZDAwMC4KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9pY2hz bWIua28iIGF0IDB4YzBkZGQyMzQuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwv c21idXMua28iIGF0IDB4YzBkZGQyZTAuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJu ZWwvc25kX2ljaC5rbyIgYXQgMHhjMGRkZDM4Yy4KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290 L2tlcm5lbC9zb3VuZC5rbyIgYXQgMHhjMGRkZDQzOC4KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9i b290L2tlcm5lbC9pbnRwbS5rbyIgYXQgMHhjMGRkZDRlNC4KUHJlbG9hZGVkIGVsZiBtb2R1bGUg Ii9ib290L2tlcm5lbC9jcHVmcmVxLmtvIiBhdCAweGMwZGRkNTkwLgpQcmVsb2FkZWQgZWxmIG1v ZHVsZSAiL2Jvb3Qva2VybmVsL2FjcGkua28iIGF0IDB4YzBkZGQ2M2MuCm1vZHVsZV9yZWdpc3Rl cjogbW9kdWxlIHBjaS9pY2hzc19wY2kgYWxyZWFkeSBleGlzdHMhCk1vZHVsZSBwY2kvaWNoc3Nf cGNpIGZhaWxlZCB0byByZWdpc3RlcjogMTcKbW9kdWxlX3JlZ2lzdGVyOiBtb2R1bGUgY3B1L2lj aHNzIGFscmVhZHkgZXhpc3RzIQpNb2R1bGUgY3B1L2ljaHNzIGZhaWxlZCB0byByZWdpc3Rlcjog MTcKbW9kdWxlX3JlZ2lzdGVyOiBtb2R1bGUgY3B1L2VzdCBhbHJlYWR5IGV4aXN0cyEKTW9kdWxl IGNwdS9lc3QgZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNwptb2R1bGVfcmVnaXN0ZXI6IG1vZHVsZSBj cHUvcDR0Y2MgYWxyZWFkeSBleGlzdHMhCk1vZHVsZSBjcHUvcDR0Y2MgZmFpbGVkIHRvIHJlZ2lz dGVyOiAxNwptb2R1bGVfcmVnaXN0ZXI6IG1vZHVsZSBjcHUvcG93ZXJub3cgYWxyZWFkeSBleGlz dHMhCk1vZHVsZSBjcHUvcG93ZXJub3cgZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNwptb2R1bGVfcmVn aXN0ZXI6IG1vZHVsZSBjcHUvc21pc3QgYWxyZWFkeSBleGlzdHMhCk1vZHVsZSBjcHUvc21pc3Qg ZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNwpDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gaTgyNTQgY2xv Y2s6IDExOTMxODggSHoKQ0xLX1VTRV9JODI1NF9DQUxJQlJBVElPTiBub3Qgc3BlY2lmaWVkIC0g dXNpbmcgZGVmYXVsdCBmcmVxdWVuY3kKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5 MzE4MiBIeiBxdWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDIy NjExNTk2MjcgSHoKQ1BVOiBJbnRlbChSKSBQZW50aXVtKFIpIE0gcHJvY2Vzc29yIDIuMjZHSHog KDIyNjEuMTYtTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElk ID0gMHg2ZDggIFN0ZXBwaW5nID0gOAogIEZlYXR1cmVzPTB4YWZlOWZiZmY8RlBVLFZNRSxERSxQ U0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsQ0xG TFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4 MTgwPEVTVCxUTTI+CiAgQU1EIEZlYXR1cmVzPTB4MTAwMDAwPE5YPgoKSW5zdHJ1Y3Rpb24gVExC OiA0IEtCIFBhZ2VzLCA0LXdheSBzZXQgYXNzb2NpYXRpdmUsIDEyOCBlbnRyaWVzCkRhdGEgVExC OiA0IEtCIFBhZ2VzLCA0LXdheSBzZXQgYXNzb2NpYXRpdmUsIDEyOCBlbnRyaWVzCkluc3RydWN0 aW9uIFRMQjogNCBNQiBwYWdlcywgZnVsbHkgYXNzb2NpYXRpdmUsIDIgZW50cmllcwoybmQtbGV2 ZWwgY2FjaGU6IDItTUIsIDgtd2F5IHNldCBhc3NvY2lhdGl2ZSwgNjQtYnl0ZSBsaW5lIHNpemUK MXN0LWxldmVsIGluc3RydWN0aW9uIGNhY2hlOiAzMiBLQiwgOC13YXkgc2V0IGFzc29jaWF0aXZl LCA2NCBieXRlIGxpbmUgc2l6ZQpEYXRhIFRMQjogNCBNQiBQYWdlcywgNC13YXkgc2V0IGFzc29j aWF0aXZlLCA4IGVudHJpZXMKMXN0LWxldmVsIGRhdGEgY2FjaGU6IDMyIEtCLCA4LXdheSBzZXQg YXNzb2NpYXRpdmUsIDY0IGJ5dGUgbGluZSBzaXplCkwyIGNhY2hlOiAyMDQ4IGtieXRlcywgOC13 YXkgYXNzb2NpYXRpdmUsIDY0IGJ5dGVzL2xpbmUKcmVhbCBtZW1vcnkgID0gMjE0NjIzODQ2NCAo MjA0NiBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMDAwMDEwMDAgLSAw eDAwMDAwMDAwMDAwOWRmZmYsIDY0MzA3MiBieXRlcyAoMTU3IHBhZ2VzKQoweDAwMDAwMDAwMDAx MDAwMDAgLSAweDAwMDAwMDAwMDAzZmZmZmYsIDMxNDU3MjggYnl0ZXMgKDc2OCBwYWdlcykKMHgw MDAwMDAwMDAxMDI4MDAwIC0gMHgwMDAwMDAwMDdkYTg0ZmZmLCAyMDkxMjQxNDcyIGJ5dGVzICg1 MTA1NTcgcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDIwOTA2NzIxMjggKDE5OTMgTUIpClRhYmxlICdG QUNQJyBhdCAweDdmZWQ3MTAwClRhYmxlICdTU0RUJyBhdCAweDdmZWQ3MmI0ClRhYmxlICdFQ0RU JyBhdCAweDdmZWU0ZGZjClRhYmxlICdUQ1BBJyBhdCAweDdmZWU0ZTRlClRhYmxlICdBUElDJyBh dCAweDdmZWU0ZTgwCk1BRFQ6IEZvdW5kIHRhYmxlIGF0IDB4N2ZlZTRlODAKQVBJQzogVXNpbmcg dGhlIE1BRFQgZW51bWVyYXRvci4KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBBQ1BJIElEIDE6 IGVuYWJsZWQKU01QOiBBZGRlZCBDUFUgMCAoQVApCkFDUEkgQVBJQyBUYWJsZTogPElCTSAgICBU UC0xWSAgID4KYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJlY3RvcnkgaGVhZGVyIGF0 IDB4YzAwZjZiYjAKYmlvczMyOiBFbnRyeSA9IDB4ZmQ3NjAgKGMwMGZkNzYwKSAgUmV2ID0gMCAg TGVuID0gMQpwY2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGZkNmYwKzB4MjA3CnBucGJpb3M6 IEZvdW5kIFBuUCBCSU9TIGRhdGEgYXQgMHhjMDBmNmMzMApwbnBiaW9zOiBFbnRyeSA9IGYwMDAw OmI1OTYgIFJldiA9IDEuMApwbnBiaW9zOiBFdmVudCBmbGFnIGF0IDRiNApPdGhlciBCSU9TIHNp Z25hdHVyZXMgZm91bmQ6CkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDEKQUNQSTogUlNEUCBAIDB4 MHhmNmMwMC8weDAwMjQgKHYgIDIgSUJNICAgKQpBQ1BJOiBYU0RUIEAgMHgweDdmZWQ2ZmU3LzB4 MDA1QyAodiAgMSBJQk0gICAgVFAtMVkgICAgMHgwMDAwMTI5MCAgTFRQIDB4MDAwMDAwMDApCkFD UEk6IEZBQ1AgQCAweDB4N2ZlZDcxMDAvMHgwMEY0ICh2ICAzIElCTSAgICBUUC0xWSAgICAweDAw MDAxMjkwIElCTSAgMHgwMDAwMDAwMSkKQUNQSSBXYXJuaW5nICh0YmZhZHQtMDUwNSk6IE9wdGlv bmFsIGZpZWxkICJHcGUxQmxvY2siIGhhcyB6ZXJvIGFkZHJlc3Mgb3IgbGVuZ3RoOiAgICAgICAg MCAgICAxMDJDLzAgWzIwMDcwMzIwXQpBQ1BJOiBEU0RUIEAgMHgweDdmZWQ3MmU3LzB4REIxNSAo diAgMSBJQk0gICAgVFAtMVkgICAgMHgwMDAwMTI5MCBNU0ZUIDB4MDEwMDAwMEUpCkFDUEk6IEZB Q1MgQCAweDB4N2ZlZjYwMDAvMHgwMDQwCkFDUEk6IFNTRFQgQCAweDB4N2ZlZDcyYjQvMHgwMDMz ICh2ICAxIElCTSAgICBUUC0xWSAgICAweDAwMDAxMjkwIE1TRlQgMHgwMTAwMDAwRSkKQUNQSTog RUNEVCBAIDB4MHg3ZmVlNGRmYy8weDAwNTIgKHYgIDEgSUJNICAgIFRQLTFZICAgIDB4MDAwMDEy OTAgSUJNICAweDAwMDAwMDAxKQpBQ1BJOiBUQ1BBIEAgMHgweDdmZWU0ZTRlLzB4MDAzMiAodiAg MSBJQk0gICAgVFAtMVkgICAgMHgwMDAwMTI5MCBQVEwgIDB4MDAwMDAwMDEpCkFDUEk6IEFQSUMg QCAweDB4N2ZlZTRlODAvMHgwMDVBICh2ICAxIElCTSAgICBUUC0xWSAgICAweDAwMDAxMjkwIElC TSAgMHgwMDAwMDAwMSkKQUNQSTogTUNGRyBAIDB4MHg3ZmVlNGVkYS8weDAwM0MgKHYgIDEgSUJN ICAgIFRQLTFZICAgIDB4MDAwMDEyOTAgSUJNICAweDAwMDAwMDAxKQpBQ1BJOiBCT09UIEAgMHgw eDdmZWU0ZmQ4LzB4MDAyOCAodiAgMSBJQk0gICAgVFAtMVkgICAgMHgwMDAwMTI5MCAgTFRQIDB4 MDAwMDAwMDEpCk1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgMSwgSW50ZXJydXB0IDAgYXQgMHhmZWMw MDAwMAppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElEIHRvIDEKaW9hcGljMDogUm91dGluZyBleHRl cm5hbCA4MjU5QSdzIC0+IGludHBpbiAwCk1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNl IDAsIGlycSAyCmlvYXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDIKTUFEVDogSW50ZXJy dXB0IG92ZXJyaWRlOiBzb3VyY2UgOSwgaXJxIDkKaW9hcGljMDogaW50cGluIDkgdHJpZ2dlcjog bGV2ZWwKbGFwaWMwOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBpYzA6IExJTlQxIHRyaWdnZXI6 IGVkZ2UKbGFwaWMwOiBMSU5UMSBwb2xhcml0eTogaGlnaAppb2FwaWMwIDxWZXJzaW9uIDIuMD4g aXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCmNwdTAgQlNQOgogICAgIElEOiAweDAwMDAwMDAwICAg VkVSOiAweDAwMDUwMDE0IExEUjogMHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDog MHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAw MWZmCiAgdGltZXI6IDB4MDAwMTAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAw IHBjbTogMHgwMDAxMDAwMAp3bGFuX2FtcnI6IDxBTVJSIFRyYW5zbWl0IFJhdGUgQ29udHJvbCBB bGdvcml0aG0+CndsYW46IDw4MDIuMTEgTGluayBMYXllcj4Kc25kX3VuaXRfaW5pdCgpIHU9MHgw MGZmODAwMCBbNTEyXSBkPTB4MDAwMDdjMDAgWzMyXSBjPTB4MDAwMDAzZmYgWzEwMjRdCmZlZWRl cl9yZWdpc3Rlcjogc25kX3VuaXQ9LTEgc25kX21heGF1dG92Y2hhbnM9MTYgbGF0ZW5jeT01IGZl ZWRlcl9idWZmZXJzaXplPTE2Mzg0IGZlZWRlcl9yYXRlX21pbj0xIGZlZWRlcl9yYXRlX21heD0y MDE2MDAwIGZlZWRlcl9yYXRlX3JvdW5kPTI1CmF0aF9yYXRlOiB2ZXJzaW9uIDEuMiA8U2FtcGxl UmF0ZSBiaXQtcmF0ZSBzZWxlY3Rpb24gYWxnb3JpdGhtPgpuZnNsb2NrOiBwc2V1ZG8tZGV2aWNl CmtiZDogbmV3IGFycmF5IHNpemUgNAprYmQxIGF0IGtiZG11eDAKaW86IDxJL08+Cm1lbTogPG1l bW9yeT4KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKbnVsbDogPG51bGwgZGV2aWNl LCB6ZXJvIGRldmljZT4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+ CmF0aF9oYWw6IDAuOS4yMC4zIChBUjUyMTAsIEFSNTIxMSwgQVI1MjEyLCBSRjUxMTEsIFJGNTEx MiwgUkYyNDEzLCBSRjU0MTMpCmhwdHJyOiBIUFQgUm9ja2V0UkFJRCBjb250cm9sbGVyIGRyaXZl ciB2MS4xIChGZWIgMjQgMjAwOCAxOTo1OToyNykKbnB4MDogSU5UIDE2IGludGVyZmFjZQphY3Bp MDogPElCTSBUUC0xWT4gb24gbW90aGVyYm9hcmQKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAo SVNBIElSUSA5KSB0byB2ZWN0b3IgNDgKYWNwaTA6IFtNUFNBRkVdCmFjcGkwOiBbSVRIUkVBRF0K YWNwaV9lYzA6IDxFbWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxYywgRUNEVD4gcG9ydCAweDYy LDB4NjYgb24gYWNwaTAKcGNpX29wZW4oMSk6CW1vZGUgMSBhZGRyIHBvcnQgKDB4MGNmOCkgaXMg MHg4MDAwZmEwNApwY2lfb3BlbigxYSk6CW1vZGUxcmVzPTB4ODAwMDAwMDAgKDB4ODAwMDAwMDAp CnBjaV9jZmdjaGVjazoJZGV2aWNlIDAgW2NsYXNzPTA2MDAwMF0gW2hkcj0wMF0gaXMgdGhlcmUg KGlkPTI1OTA4MDg2KQpwY2liaW9zOiBCSU9TIHZlcnNpb24gMi4xMApBY3BpT3NEZXJpdmVQY2lJ ZDogXFxfU0JfLlBDSTAuTUhDUyAtPiBidXMgMCBkZXYgMCBmdW5jIDAKQWNwaU9zRGVyaXZlUGNp SWQ6IFxcX1NCXy5QQ0kwLlVTQjcuVTdDUyAtPiBidXMgMCBkZXYgMjkgZnVuYyA3CmFjcGkwOiBQ b3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogd2FrZXVwIGNvZGUgdmEgMHhkOTA5NTAwMCBwYSAw eDEwMDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLkxQQ18uTFBDUyAtPiBidXMgMCBk ZXYgMzEgZnVuYyAwCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAoMykgZmFpbGVkCmFj cGkwOiByZXNlcnZhdGlvbiBvZiAxMDAwMDAsIDdmZjAwMDAwICgzKSBmYWlsZWQKQUNQSSB0aW1l cjogMS8xIDEvMSAxLzIgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIC0+IDEwClRpbWVjb3Vu dGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3Rp bWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDEwMDgtMHgxMDBiIG9u IGFjcGkwCnBjaV9saW5rMDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5p dGlhbCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIFZh bGlkYXRpb24gICAgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKICBB ZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCnBj aV9saW5rMTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAgIDMgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIFZhbGlkYXRpb24g ICAgICAgICAgMCAgICAzICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCnBjaV9saW5rMjog ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAw ICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIFZhbGlkYXRpb24gICAgICAgICAg MCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKICBBZnRlciBEaXNhYmxlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCnBjaV9saW5rMzogICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCnBjaV9saW5rNDogICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAz IDQgNSA2IDcgOSAxMCAxMQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAgMCAg MyA0IDUgNiA3IDkgMTAgMTEKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDYgNyA5IDEwIDExCnBjaV9saW5rNTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgIDYgICBOICAgICAwICAzIDQgNSA2IDcg OSAxMCAxMQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgICA2ICAgTiAgICAgMCAgMyA0IDUgNiA3 IDkgMTAgMTEKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYg NyA5IDEwIDExCnBjaV9saW5rNjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg SW5pdGlhbCBQcm9iZSAgICAgICAwICAgIDUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQog IFZhbGlkYXRpb24gICAgICAgICAgMCAgICA1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEK ICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDEx CnBjaV9saW5rNzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQ cm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQogIFZhbGlkYXRp b24gICAgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEKICBBZnRlciBE aXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExCmNwdTA6IDxB Q1BJIENQVT4gb24gYWNwaTAKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24g Y3B1MAphY3BpX2xpZDA6IDxDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMAphY3Bp X2J1dHRvbjA6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBi cmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjAKcGNpMDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MjU5MCwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1bmM9 MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwg c3RhdHJlZz0weDIwOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHgyNTkxLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MSwg ZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgw MTA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwYyAoMzAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGlu PWEsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kg c3VwcG9ydHMgMSBtZXNzYWdlCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjEuSU5UQQpwY2li MDogc2xvdCAxIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI2NjAsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOCwgZnVuYz0w CgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMTA3LCBz dGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGly cT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9y dHMgMSBtZXNzYWdlCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI4LklOVEEKcGNpYjA6IHNs b3QgMjggSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIwCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4MjY2NCwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI4LCBmdW5jPTIKCWNs YXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRy ZWc9MHgwMDEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTUK CXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEg bWVzc2FnZQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOC5JTlRDCnBjaWIwOiBzbG90IDI4 IElOVEMgaGFyZHdpcmVkIHRvIElSUSAyMgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI2 NTgsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0wCgljbGFzcz0w Yy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4 MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJbWFwWzIw XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxODAwLCBzaXplICA1LCBlbmFibGVk CnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEEKcGNpYjA6IHNsb3QgMjkgSU5UQSBo YXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjY1OSwgcmV2 aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTEKCWNsYXNzPTBjLTAzLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjgwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTMKCW1hcFsyMF06IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTgyMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDog bWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRCCnBjaWIwOiBzbG90IDI5IElOVEIgaGFyZHdpcmVk IHRvIElSUSAxNwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI2NWEsIHJldmlkPTB4MDMK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0yCgljbGFzcz0wYy0wMy0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08gUG9y dCwgcmFuZ2UgMzIsIGJhc2UgMHgxODQwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjI5LklOVEMKcGNpYjA6IHNsb3QgMjkgSU5UQyBoYXJkd2lyZWQgdG8gSVJR IDE4CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjY1YiwgcmV2aWQ9MHgwMwoJZG9tYWlu PTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTMKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCglpbnRwaW49ZCwgaXJxPTExCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweDE4NjAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkg Zm9yIDAuMjkuSU5URApwY2liMDogc2xvdCAyOSBJTlREIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNjVjLCByZXZpZD0weDAzCglkb21haW49MCwgYnVz PTAsIHNsb3Q9MjksIGZ1bmM9NwoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1kLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVu dCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4YjAwMDAwMDAsIHNp emUgMTAsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5URApwY2liMDog c2xvdCAyOSBJTlREIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyNDQ4LCByZXZpZD0weGQzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzAsIGZ1bmM9MAoJ Y2xhc3M9MDYtMDQtMDEsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3Rh dHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHgyNjZlLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzAs IGZ1bmM9MgoJY2xhc3M9MDQtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4 MDAwNywgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1h LCBpcnE9NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDFjMDAsIHNpemUgIDgsIGVuYWJsZWQK CW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTg4MCwgc2l6ZSAgNiwg ZW5hYmxlZAoJbWFwWzE4XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4YjAwMDA4MDAs IHNpemUgIDksIGVuYWJsZWQKCW1hcFsxY106IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAw eGIwMDAwNDAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMw LklOVEEKcGNpYjA6IHNsb3QgMzAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIyCmZvdW5kLT4JdmVu ZG9yPTB4ODA4NiwgZGV2PTB4MjY2ZCwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTMwLCBmdW5jPTMKCWNsYXNzPTA3LTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJl Zz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRw aW49YiwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1h cFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MjQwMCwgc2l6ZSAgOCwgZW5h YmxlZAoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgyMDAwLCBzaXpl ICA3LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMwLklOVEIKcGNpYjA6IHNs b3QgMzAgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDIzCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4MjY0MSwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTAKCWNs YXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRy ZWc9MHgwMjAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MjY1MywgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5j PTIKCWNsYXNzPTAxLTAxLTgwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUs IHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMiAg c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdl IDMyLCBiYXNlIDB4MThjMCwgc2l6ZSAgNCwgZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI2NmEsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0z CgljbGFzcz0wYy0wNS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTAxLCBz dGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0x MQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxOGUwLCBzaXplICA1 LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEEKcGNpYjA6IHNsb3Qg MzEgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIzCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g aXJxIDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2liMTogICBkb21haW4gICAgICAgICAgICAw CnBjaWIxOiAgIHNlY29uZGFyeSBidXMgICAgIDEKcGNpYjE6ICAgc3Vib3JkaW5hdGUgYnVzICAg MQpwY2liMTogICBJL08gZGVjb2RlICAgICAgICAweDMwMDAtMHgzZmZmCnBjaWIxOiAgIG1lbW9y eSBkZWNvZGUgICAgIDB4YjAxMDAwMDAtMHhiMDFmZmZmZgpwY2liMTogICBwcmVmZXRjaGVkIGRl Y29kZSAweGMwMDAwMDAwLTB4YzdmZmZmZmYKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEK cGNpMTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0xCmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2 PTB4MzE1NCwgcmV2aWQ9MHg4MAoJZG9tYWluPTAsIGJ1cz0xLCBzbG90PTAsIGZ1bmM9MAoJY2xh c3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwMywgc3RhdHJl Zz0weDAwMTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRz IDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIFByZWZldGNoYWJsZSBNZW1vcnksIHJh bmdlIDMyLCBiYXNlIDB4YzAwMDAwMDAsIHNpemUgMjcsIGVuYWJsZWQKcGNpYjE6IHJlcXVlc3Rl ZCBtZW1vcnkgcmFuZ2UgMHhjMDAwMDAwMC0weGM3ZmZmZmZmOiBnb29kCgltYXBbMTRdOiB0eXBl IEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDMwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjE6 IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgzMDAwLTB4MzBmZjogaW4gcmFuZ2UKCW1hcFsxOF06IHR5 cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGIwMTAwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBj aWIxOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4YjAxMDAwMDAtMHhiMDEwZmZmZjogZ29vZApw Y2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgMS4wLklOVEEKcGNpYjE6IHNsb3QgMCBJTlRBIGhhcmR3 aXJlZCB0byBJUlEgMTYKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHgz MDAwLTB4MzBmZiBtZW0gMHhjMDAwMDAwMC0weGM3ZmZmZmZmLDB4YjAxMDAwMDAtMHhiMDEwZmZm ZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRn ZT4gaXJxIDIwIGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNpYjI6ICAgZG9tYWluICAgICAgICAg ICAgMApwY2liMjogICBzZWNvbmRhcnkgYnVzICAgICAyCnBjaWIyOiAgIHN1Ym9yZGluYXRlIGJ1 cyAgIDIKcGNpYjI6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWIyOiAgIG1l bW9yeSBkZWNvZGUgICAgIDB4YjAyMDAwMDAtMHhiMDJmZmZmZgpwY2liMjogICBubyBwcmVmZXRj aGVkIGRlY29kZQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiBkb21haW49MCwg cGh5c2ljYWwgYnVzPTIKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjdkLCByZXZpZD0w eDExCglkb21haW49MCwgYnVzPTIsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTAyLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVs bnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgOCBtZXNzYWdlcywgNjQgYml0Cglt YXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhiMDIwMDAwMCwgc2l6ZSAxNiwg ZW5hYmxlZApwY2liMjogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGIwMjAwMDAwLTB4YjAyMGZm ZmY6IGdvb2QKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMC5JTlRBCnBjaWIyOiBzbG90IDAg SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CnBjaTA6MjowOjA6IGJhZCBWUEQgY2tzdW0sIHJlbWFp biAxNApiZ2UwOiA8QnJvYWRjb20gTmV0WHRyZW1lIEdpZ2FiaXQgRXRoZXJuZXQgQ29udHJvbGxl ciwgQVNJQyByZXYuIDB4NDEwMT4gbWVtIDB4YjAyMDAwMDAtMHhiMDIwZmZmZiBpcnEgMTYgYXQg ZGV2aWNlIDAuMCBvbiBwY2kyCmJnZTA6IFJlc2VydmVkIDB4MTAwMDAgYnl0ZXMgZm9yIHJpZCAw eDEwIHR5cGUgMyBhdCAweGIwMjAwMDAwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBiZ2UwCmJyZ3Bo eTA6IDxCQ001NzUwIDEwLzEwMC8xMDAwYmFzZVRYIFBIWT4gUEhZIDEgb24gbWlpYnVzMApicmdw aHkwOiBPVUkgMHgwMDA4MTgsIG1vZGVsIDB4MDAxOCwgcmV2LiAwCmJyZ3BoeTA6ICAxMGJhc2VU LCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBi YXNlVC1GRFgsIGF1dG8KYmdlMDogYnBmIGF0dGFjaGVkCmJnZTA6IEV0aGVybmV0IGFkZHJlc3M6 IDAwOjE2OjQxOjUzOmZkOmIwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJRIDE2 KSB0byB2ZWN0b3IgNDkKYmdlMDogW01QU0FGRV0KYmdlMDogW0lUSFJFQURdCnBjaWIzOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gaXJxIDIyIGF0IGRldmljZSAyOC4yIG9uIHBjaTAKcGNpYjM6ICAg ZG9tYWluICAgICAgICAgICAgMApwY2liMzogICBzZWNvbmRhcnkgYnVzICAgICAzCnBjaWIzOiAg IHN1Ym9yZGluYXRlIGJ1cyAgIDEwCnBjaWIzOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4NDAwMC0w eDRmZmYKcGNpYjM6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhiMjAwMDAwMC0weGIzZmZmZmZmCnBj aWIzOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4YzgwMDAwMDAtMHhjODBmZmZmZgpwY2kzOiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMwpwY2kzOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTMKdWhjaTA6 IDxJbnRlbCA4MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IHBv cnQgMHgxODAwLTB4MTgxZiBpcnEgMTYgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNpMDogUmVz ZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4MTgwMAp1aGNpMDogW0dJ QU5ULUxPQ0tFRF0KdWhjaTA6IFtJVEhSRUFEXQp1c2IwOiA8SW50ZWwgODI4MDFGQi9GUi9GVy9G UlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBvbiB1aGNpMAp1c2IwOiBVU0IgcmV2aXNp b24gMS4wCnVodWIwOiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8x LjAwLCBhZGRyIDE+IG9uIHVzYjAKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVoY2kxOiA8SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250 cm9sbGVyIFVTQi1CPiBwb3J0IDB4MTgyMC0weDE4M2YgaXJxIDE3IGF0IGRldmljZSAyOS4xIG9u IHBjaTAKdWhjaTE6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAw eDE4MjAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTcgKFBDSSBJUlEgMTcpIHRvIHZlY3RvciA1 MAp1aGNpMTogW0dJQU5ULUxPQ0tFRF0KdWhjaTE6IFtJVEhSRUFEXQp1c2IxOiA8SW50ZWwgODI4 MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQp1c2Ix OiBVU0IgcmV2aXNpb24gMS4wCnVodWIxOiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjEKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kyOiA8SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElD SDYpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBwb3J0IDB4MTg0MC0weDE4NWYgaXJxIDE4IGF0IGRl dmljZSAyOS4yIG9uIHBjaTAKdWhjaTI6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIw IHR5cGUgNCBhdCAweDE4NDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgp IHRvIHZlY3RvciA1MQp1aGNpMjogW0dJQU5ULUxPQ0tFRF0KdWhjaTI6IFtJVEhSRUFEXQp1c2Iy OiA8SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBv biB1aGNpMgp1c2IyOiBVU0IgcmV2aXNpb24gMS4wCnVodWIyOiA8SW50ZWwgVUhDSSByb290IGh1 YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjIKdWh1YjI6IDIgcG9y dHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kzOiA8SW50ZWwgODI4MDFGQi9G Ui9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1EPiBwb3J0IDB4MTg2MC0weDE4N2Yg aXJxIDE5IGF0IGRldmljZSAyOS4zIG9uIHBjaTAKdWhjaTM6IFJlc2VydmVkIDB4MjAgYnl0ZXMg Zm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDE4NjAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTkg KFBDSSBJUlEgMTkpIHRvIHZlY3RvciA1Mgp1aGNpMzogW0dJQU5ULUxPQ0tFRF0KdWhjaTM6IFtJ VEhSRUFEXQp1c2IzOiA8SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9s bGVyIFVTQi1EPiBvbiB1aGNpMwp1c2IzOiBVU0IgcmV2aXNpb24gMS4wCnVodWIzOiA8SW50ZWwg VUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjMK dWh1YjM6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kwOiA8SW50 ZWwgODI4MDFGQiAoSUNINikgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhiMDAwMDAwMC0weGIw MDAwM2ZmIGlycSAxOSBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCmVoY2kwOiBSZXNlcnZlZCAweDQw MCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4YjAwMDAwMDAKZWhjaTA6IFtHSUFOVC1M T0NLRURdCmVoY2kwOiBbSVRIUkVBRF0KdXNiNDogRUhDSSB2ZXJzaW9uIDEuMAp1c2I0OiBjb21w YW5pb24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1c2IxIHVzYjIgdXNiMwp1c2I0 OiA8SW50ZWwgODI4MDFGQiAoSUNINikgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMAp1c2I0 OiBVU0IgcmV2aXNpb24gMi4wCnVodWI0OiA8SW50ZWwgRUhDSSByb290IGh1YiwgY2xhc3MgOS8w LCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjQKdWh1YjQ6IDggcG9ydHMgd2l0aCA4IHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDMwLjAgb24gcGNpMApwY2liNDogICBkb21haW4gICAgICAgICAgICAwCnBjaWI0OiAgIHNl Y29uZGFyeSBidXMgICAgIDExCnBjaWI0OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDE0CnBjaWI0OiAg IEkvTyBkZWNvZGUgICAgICAgIDB4NTAwMC0weDhmZmYKcGNpYjQ6ICAgbWVtb3J5IGRlY29kZSAg ICAgMHhiNDAwMDAwMC0weGJmZmZmZmZmCnBjaWI0OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZDAw MDAwMDAtMHhkN2ZmZmZmZgpwY2liNDogICBTdWJ0cmFjdGl2ZWx5IGRlY29kZWQgYnJpZGdlLgpw Y2kxMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKcGNpMTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBi dXM9MTEKZm91bmQtPgl2ZW5kb3I9MHgxMTgwLCBkZXY9MHgwNDc2LCByZXZpZD0weDhkCglkb21h aW49MCwgYnVzPTExLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYtMDctMDAsIGhkcnR5cGU9MHgw MiwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej0wIChk d29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4ODAgKDMyMDAwIG5zKSwg bWF4bGF0PTB4MDcgKDE3NTAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5n ZSAzMiwgYmFzZSAweGI0MDEwMDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWI0OiByZXF1ZXN0ZWQg bWVtb3J5IHJhbmdlIDB4YjQwMTAwMDAtMHhiNDAxMGZmZjogZ29vZApwY2liNDogbWF0Y2hlZCBl bnRyeSBmb3IgMTEuMC5JTlRBCnBjaWI0OiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2 CmZvdW5kLT4JdmVuZG9yPTB4MTY4YywgZGV2PTB4MTAxNCwgcmV2aWQ9MHgwMQoJZG9tYWluPTAs IGJ1cz0xMSwgc2xvdD0yLCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1m ZGV2PTAKCWNtZHJlZz0weDAzMTYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9OCAoZHdvcmRz KQoJbGF0dGltZXI9MHg1MCAoMjQwMCBucyksIG1pbmdudD0weDBhICgyNTAwIG5zKSwgbWF4bGF0 PTB4MWMgKDcwMDAgbnMpCglpbnRwaW49YSwgaXJxPTYKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBE MCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4 YjQwMDAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjQ6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2Ug MHhiNDAwMDAwMC0weGI0MDBmZmZmOiBnb29kCnBjaWI0OiBtYXRjaGVkIGVudHJ5IGZvciAxMS4y LklOVEEKcGNpYjQ6IHNsb3QgMiBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjEKY2JiMDogPFJGNUM0 NzYgUENJLUNhcmRCdXMgQnJpZGdlPiBtZW0gMHhiNDAxMDAwMC0weGI0MDEwZmZmIGlycSAxNiBh dCBkZXZpY2UgMC4wIG9uIHBjaTExCmNiYjA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3Igcmlk IDB4MTAgdHlwZSAzIGF0IDB4YjQwMTAwMDAKY2FyZGJ1czA6IDxDYXJkQnVzIGJ1cz4gb24gY2Ji MApwY2NhcmQwOiA8MTYtYml0IFBDQ2FyZCBidXM+IG9uIGNiYjAKY2JiMDogW01QU0FGRV0KY2Ji MDogW0lUSFJFQURdCmNiYjA6IFBDSSBDb25maWd1cmF0aW9uIHNwYWNlOgogIDB4MDA6IDB4MDQ3 NjExODAgMHgwMjEwMDEwNyAweDA2MDcwMDhkIDB4MDA4MjQwMDAgCiAgMHgxMDogMHhiNDAxMDAw MCAweDAyMDAwMGRjIDB4YjAwZTBjMGIgMHhmZmZmZjAwMCAKICAweDIwOiAweDAwMDAwMDAwIDB4 ZmZmZmYwMDAgMHgwMDAwMDAwMCAweGZmZmZmZmZjIAogIDB4MzA6IDB4MDAwMDAwMDAgMHhmZmZm ZmZmYyAweDAwMDAwMDAwIDB4MDcwMDAxMTAgCiAgMHg0MDogMHgwNTZjMTAxNCAweDAwMDAwMDAx IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDUwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAw MDAwIDB4MDAwMDAwMDAgCiAgMHg3MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAg MHgwMDAwMDAwMCAKICAweDgwOiAweDA0ODAwMDAxIDB4MDAwMDAwMDAgMHgwNDYzMDQ2NCAweDAw MDAwMDAwIAogIDB4OTA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAw MDAgCiAgMHhhMDogMHgwMDBhMDAwMCAweDAwMDAwMDAwIDB4MDBmMDAwMDAgMHgwMDAwMDAwMCAK ICAweGIwOiAweDAwMDAwMDAwIDB4ZmUwMDAwMDAgMHgwMDAwMzgwMCAweDAwMDAwMDAwIAogIDB4 YzA6IDB4MDU2YzEwMTQgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhkMDog MHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHhmZTBhMDAwMSAKICAweGUwOiAweDI0 YzA0MDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4ZjA6IDB4MDAwMDAw MDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCmF0aDA6IDxBdGhlcm9zIDUyMTI+ IG1lbSAweGI0MDAwMDAwLTB4YjQwMGZmZmYgaXJxIDIxIGF0IGRldmljZSAyLjAgb24gcGNpMTEK YXRoMDogUmVzZXJ2ZWQgMHgxMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4YjQw MDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjEgKFBDSSBJUlEgMjEpIHRvIHZlY3RvciA1 MwphdGgwOiBbTVBTQUZFXQphdGgwOiBbSVRIUkVBRF0KYXRoMDogaGFsIGNoYW5uZWwgMjQxMi9h MCAtPiAxCmF0aDA6IGhhbCBjaGFubmVsIDI0MTIvYzAgLT4gMQphdGgwOiBoYWwgY2hhbm5lbCAy NDE3L2EwIC0+IDIKYXRoMDogaGFsIGNoYW5uZWwgMjQxNy9jMCAtPiAyCmF0aDA6IGhhbCBjaGFu bmVsIDI0MjIvYTAgLT4gMwphdGgwOiBoYWwgY2hhbm5lbCAyNDIyL2MwIC0+IDMKYXRoMDogaGFs IGNoYW5uZWwgMjQyNy9hMCAtPiA0CmF0aDA6IGhhbCBjaGFubmVsIDI0MjcvYzAgLT4gNAphdGgw OiBoYWwgY2hhbm5lbCAyNDMyL2EwIC0+IDUKYXRoMDogaGFsIGNoYW5uZWwgMjQzMi9jMCAtPiA1 CmF0aDA6IGhhbCBjaGFubmVsIDI0MzcvYTAgLT4gNgphdGgwOiBoYWwgY2hhbm5lbCAyNDM3L2Mw IC0+IDYKYXRoMDogaGFsIGNoYW5uZWwgMjQ0Mi9hMCAtPiA3CmF0aDA6IGhhbCBjaGFubmVsIDI0 NDIvYzAgLT4gNwphdGgwOiBoYWwgY2hhbm5lbCAyNDQ3L2EwIC0+IDgKYXRoMDogaGFsIGNoYW5u ZWwgMjQ0Ny9jMCAtPiA4CmF0aDA6IGhhbCBjaGFubmVsIDI0NTIvYTAgLT4gOQphdGgwOiBoYWwg Y2hhbm5lbCAyNDUyL2MwIC0+IDkKYXRoMDogaGFsIGNoYW5uZWwgMjQ1Ny9hMCAtPiAxMAphdGgw OiBoYWwgY2hhbm5lbCAyNDU3L2MwIC0+IDEwCmF0aDA6IGhhbCBjaGFubmVsIDI0NjIvYTAgLT4g MTEKYXRoMDogaGFsIGNoYW5uZWwgMjQ2Mi9jMCAtPiAxMQphdGgwOiBoYWwgY2hhbm5lbCA1MTcw LzM0MCAtPiAzNAphdGgwOiBoYWwgY2hhbm5lbCA1MTgwLzM0MCAtPiAzNgphdGgwOiBoYWwgY2hh bm5lbCA1MTkwLzM0MCAtPiAzOAphdGgwOiBoYWwgY2hhbm5lbCA1MjAwLzM0MCAtPiA0MAphdGgw OiBoYWwgY2hhbm5lbCA1MjEwLzM0MCAtPiA0MgphdGgwOiBoYWwgY2hhbm5lbCA1MjIwLzM0MCAt PiA0NAphdGgwOiBoYWwgY2hhbm5lbCA1MjMwLzM0MCAtPiA0NgphdGgwOiBoYWwgY2hhbm5lbCA1 MjQwLzM0MCAtPiA0OAphdGgwOiBoYWwgY2hhbm5lbCA1MjYwLzM0MCAtPiA1MgphdGgwOiBoYWwg Y2hhbm5lbCA1MjgwLzM0MCAtPiA1NgphdGgwOiBoYWwgY2hhbm5lbCA1MzAwLzM0MCAtPiA2MAph dGgwOiBoYWwgY2hhbm5lbCA1MzIwLzM0MCAtPiA2NAphdGgwOiBoYWwgY2hhbm5lbCA1NTAwLzM0 MCAtPiAxMDAKYXRoMDogaGFsIGNoYW5uZWwgNTUyMC8zNDAgLT4gMTA0CmF0aDA6IGhhbCBjaGFu bmVsIDU1NDAvMzQwIC0+IDEwOAphdGgwOiBoYWwgY2hhbm5lbCA1NTYwLzM0MCAtPiAxMTIKYXRo MDogaGFsIGNoYW5uZWwgNTU4MC8zNDAgLT4gMTE2CmF0aDA6IGhhbCBjaGFubmVsIDU2MDAvMzQw IC0+IDEyMAphdGgwOiBoYWwgY2hhbm5lbCA1NjIwLzM0MCAtPiAxMjQKYXRoMDogaGFsIGNoYW5u ZWwgNTY0MC8zNDAgLT4gMTI4CmF0aDA6IGhhbCBjaGFubmVsIDU2NjAvMzQwIC0+IDEzMgphdGgw OiBoYWwgY2hhbm5lbCA1NjgwLzM0MCAtPiAxMzYKYXRoMDogaGFsIGNoYW5uZWwgNTcwMC8zNDAg LT4gMTQwCmF0aDA6IGhhbCBjaGFubmVsIDU3NDUvMzQwIC0+IDE0OQphdGgwOiBoYWwgY2hhbm5l bCA1NzY1LzM0MCAtPiAxNTMKYXRoMDogaGFsIGNoYW5uZWwgNTc4NS8zNDAgLT4gMTU3CmF0aDA6 IGhhbCBjaGFubmVsIDU4MDUvMzQwIC0+IDE2MQphdGgwOiBoYWwgY2hhbm5lbCA1ODI1LzM0MCAt PiAxNjUKYXRoMDogdXNpbmcgb2Jzb2xldGVkIGlmX3dhdGNoZG9nIGludGVyZmFjZQphdGgwOiBi cGYgYXR0YWNoZWQKYXRoMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTk6N2U6MDY6MDI6ZGMKYXRo MDogYnBmIGF0dGFjaGVkCmF0aDA6IGJwZiBhdHRhY2hlZAphdGgwOiAxMWEgcmF0ZXM6IDZNYnBz IDlNYnBzIDEyTWJwcyAxOE1icHMgMjRNYnBzIDM2TWJwcyA0OE1icHMgNTRNYnBzCmF0aDA6IDEx YiByYXRlczogMU1icHMgMk1icHMgNS41TWJwcyAxMU1icHMKYXRoMDogMTFnIHJhdGVzOiAxTWJw cyAyTWJwcyA1LjVNYnBzIDExTWJwcyA2TWJwcyA5TWJwcyAxMk1icHMgMThNYnBzIDI0TWJwcyAz Nk1icHMgNDhNYnBzIDU0TWJwcwphdGgwOiBtYWMgNS45IHBoeSA0LjMgcmFkaW8gMy42CmF0aDA6 IFVzZSBodyBxdWV1ZSAxIGZvciBXTUVfQUNfQkUgdHJhZmZpYwphdGgwOiBVc2UgaHcgcXVldWUg MCBmb3IgV01FX0FDX0JLIHRyYWZmaWMKYXRoMDogVXNlIGh3IHF1ZXVlIDIgZm9yIFdNRV9BQ19W SSB0cmFmZmljCmF0aDA6IFVzZSBodyBxdWV1ZSAzIGZvciBXTUVfQUNfVk8gdHJhZmZpYwphdGgw OiBVc2UgaHcgcXVldWUgOCBmb3IgQ0FCIHRyYWZmaWMKYXRoMDogVXNlIGh3IHF1ZXVlIDkgZm9y IGJlYWNvbnMKcGNtMDogPEludGVsIElDSDYgKDgyODAxRkIpPiBwb3J0IDB4MWMwMC0weDFjZmYs MHgxODgwLTB4MThiZiBtZW0gMHhiMDAwMDgwMC0weGIwMDAwOWZmLDB4YjAwMDA0MDAtMHhiMDAw MDRmZiBpcnEgMjIgYXQgZGV2aWNlIDMwLjIgb24gcGNpMApwY20wOiBSZXNlcnZlZCAweDIwMCBi eXRlcyBmb3IgcmlkIDB4MTggdHlwZSAzIGF0IDB4YjAwMDA4MDAKcGNtMDogUmVzZXJ2ZWQgMHgx MDAgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgMyBhdCAweGIwMDAwNDAwCmlvYXBpYzA6IHJvdXRp bmcgaW50cGluIDIyIChQQ0kgSVJRIDIyKSB0byB2ZWN0b3IgNTQKcGNtMDogW01QU0FGRV0KcGNt MDogW0lUSFJFQURdCnBjbTA6IDxBbmFsb2cgRGV2aWNlcyBBRDE5ODFCIEFDOTcgQ29kZWMgKGlk ID0gMHg0MTQ0NTM3NCk+CnBjbTA6IENvZGVjIGZlYXR1cmVzIGhlYWRwaG9uZSwgMjAgYml0IERB QywgNSBiaXQgbWFzdGVyIHZvbHVtZSwgbm8gM0QgU3RlcmVvIEVuaGFuY2VtZW50CnBjbTA6IFBy aW1hcnkgY29kZWMgZXh0ZW5kZWQgZmVhdHVyZXMgdmFyaWFibGUgcmF0ZSBQQ00sIEFNQVAsIHJl c2VydmVkIDQKcGNtMDogYWM5NyBjb2RlYyBkYWMgcmVhZHkgY291bnQ6IDAKcGNtMDogTWl4ZXIg InZvbCI6CnBjbTA6IE1peGVyICJwY20iOgpwY20wOiBNaXhlciAibGluZSI6CnBjbTA6IE1peGVy ICJtaWMiOgpwY20wOiBNaXhlciAiY2QiOgpwY20wOiBNaXhlciAicmVjIjoKcGNtMDogTWl4ZXIg ImlnYWluIjoKcGNtMDogTWl4ZXIgIm9nYWluIjoKcGNtMDogTWl4ZXIgImxpbmUxIjoKcGNtMDog TWl4ZXIgInBoaW4iOgpwY20wOiBNaXhlciAicGhvdXQiOgpwY20wOiBjbG9uZSBtYW5hZ2VyOiBk ZWFkbGluZT03NTBtcyBmbGFncz0weDgwMDAwMDFlCnBjbTA6IHNuZGJ1Zl9zZXRtYXAgMjA0MDAw MCwgNDAwMDsgMHhlNTc2ZjAwMCAtPiAyMDQwMDAwCnBjbTA6IHNuZGJ1Zl9zZXRtYXAgMjA0ODAw MCwgNDAwMDsgMHhlNTc3MzAwMCAtPiAyMDQ4MDAwCnBjaTA6IDxzaW1wbGUgY29tbXMsIGdlbmVy aWMgbW9kZW0+IGF0IGRldmljZSAzMC4zIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJ LUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlz YWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0g2TSBTQVRBMTUwIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAt MHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHgxOGMwLTB4MThjZiBhdCBkZXZpY2UgMzEu MiBvbiBwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUg NCBhdCAweDE4YzAKYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVz ZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHgxZjAKYXRhcGNpMDogUmVz ZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHgzZjYKYXRhMDogcmVzZXQg dHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0MT0wMAphdGEwOiBzdGF0MD0weDUwIGVycj0weDAx IGxzYj0weDAwIG1zYj0weDAwCmF0YTA6IHN0YXQxPTB4MDAgZXJyPTB4MDEgbHNiPTB4MDAgbXNi PTB4MDAKYXRhMDogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRldmljZXM9MHgxPEFUQV9N QVNURVI+CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE0IChJU0EgSVJRIDE0KSB0byB2ZWN0b3Ig NTUKYXRhMDogW01QU0FGRV0KYXRhMDogW0lUSFJFQURdCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBv biBhdGFwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0 IGF0IDB4MTcwCmF0YXBjaTA6IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0 IGF0IDB4Mzc2CmF0YTE6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRh MTogc3RhdDA9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGExOiBzdGF0MT0weDAw IGVycj0weDAwIGxzYj0weDAwIG1zYj0weDAwCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0wMCBzdGF0 MT0wMCBkZXZpY2VzPTB4NDxBVEFQSV9NQVNURVI+CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE1 IChJU0EgSVJRIDE1KSB0byB2ZWN0b3IgNTYKYXRhMTogW01QU0FGRV0KYXRhMTogW0lUSFJFQURd CmljaHNtYjA6IDxJbnRlbCA4MjgwMUZCIChJQ0g2KSBTTUJ1cyBjb250cm9sbGVyPiBwb3J0IDB4 MThlMC0weDE4ZmYgaXJxIDIzIGF0IGRldmljZSAzMS4zIG9uIHBjaTAKaWNoc21iMDogUmVzZXJ2 ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4MThlMAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAyMyAoUENJIElSUSAyMykgdG8gdmVjdG9yIDU3CmljaHNtYjA6IFtHSUFOVC1M T0NLRURdCmljaHNtYjA6IFtJVEhSRUFEXQpzbWJ1czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBCdXM+ IG9uIGljaHNtYjAKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmF0a2JkYzA6IDxL ZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkw CmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUgY3VycmVu dCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUgMDA0NwphdGtiZDoga2V5Ym9hcmQgSUQgMHg1 NGFiICgyKQprYmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIpLCBjb25m aWc6MHgwLCBmbGFnczoweDNkMDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxIChJU0EgSVJR IDEpIHRvIHZlY3RvciA1OAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURd CnBzbTA6IHVuYWJsZSB0byBhbGxvY2F0ZSBJUlEKcHNtY3BucDA6IDxQUy8yIG1vdXNlIHBvcnQ+ IGlycSAxMiBvbiBhY3BpMApwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDQ3CnBzbTA6IDxQ Uy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxMiAo SVNBIElSUSAxMikgdG8gdmVjdG9yIDU5CnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IFtJVEhS RUFEXQpwc20wOiBtb2RlbCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwLTAwLCAyIGJ1 dHRvbnMKcHNtMDogY29uZmlnOjAwMDAwMDAwLCBmbGFnczowMDAwMDAwOCwgcGFja2V0IHNpemU6 Mwpwc20wOiBzeW5jbWFzazpjMCwgc3luY2JpdHM6MDAKc2lvMDogaXJxIG1hcHM6IDB4OGU2OSAw eDhlNzkgMHg4ZTY5IDB4OGU2OQpzaW8wOiBpcnEgbWFwczogMHg4ZTY5IDB4OGU3OSAweDhlNjkg MHg4ZTY5CnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNm ZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1NTBBCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDQgKElTQSBJUlEgNCkgdG8gdmVjdG9yIDYwCnNpbzA6IFtGSUxURVJdCmJh dHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2FjYWQw OiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBm Zgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyByZWcg dGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3du OiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWls ZWQgZmYKZXhfaXNhX2lkZW50aWZ5KCkKYWhjX2lzYV9wcm9iZSAxOiBpb3BvcnQgMHgxYzAwIGFs bG9jIGZhaWxlZAphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0YTogYXRh MSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRrYmRjOiBhdGtiZGMwIGFscmVhZHkgZXhp c3RzOyBza2lwcGluZyBpdApzaW86IHNpbzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnBu cF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcg UmVhZF9Qb3J0IGF0IDI0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjgzCnBu cF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMKcG5wX2lkZW50aWZ5OiBUcnlpbmcg UmVhZF9Qb3J0IGF0IDMwMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzQzCnBu cF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzODMKcG5wX2lkZW50aWZ5OiBUcnlpbmcg UmVhZF9Qb3J0IGF0IDNjMwpQTlAgSWRlbnRpZnkgY29tcGxldGUKc2M6IHNjMCBhbHJlYWR5IGV4 aXN0czsgc2tpcHBpbmcgaXQKdmdhOiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApp c2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwppc2FfcHJvYmVfY2hpbGRy ZW46IHByb2Jpbmcgbm9uLVBuUCBkZXZpY2VzCnBtdGltZXIwIG9uIGlzYTAKb3JtMDogPElTQSBP cHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGNmZmZmLDB4ZDE4MDAtMHhkMjdmZiwweGUw MDAwLTB4ZWZmZmYgcG5waWQgT1JNMDAwMCBvbiBpc2EwCmFkdjA6IG5vdCBwcm9iZWQgKGRpc2Fi bGVkKQphaGEwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKYWljMDogbm90IHByb2JlZCAoZGlzYWJs ZWQpCmJ0MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmNzMDogbm90IHByb2JlZCAoZGlzYWJsZWQp CmVkMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmZkYzAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQg MHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNhMApmZTA6IG5vdCBwcm9iZWQgKGRp c2FibGVkKQppZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpsZTA6IG5vdCBwcm9iZWQgKGRpc2Fi bGVkKQpwcGMwOiBwYXJhbGxlbCBwb3J0IGZvdW5kIGF0IDB4Mzc4CnBwYzA6IHVzaW5nIGV4dGVu ZGVkIEkvTyBwb3J0IHJhbmdlCnBwYzA6IEVDUCBTUFAgRUNQK0VQUCBTUFAKcHBjMDogPFBhcmFs bGVsIHBvcnQ+IGF0IHBvcnQgMHgzNzgtMHgzN2YgaXJxIDcgb24gaXNhMApwcGMwOiBTTUMtbGlr ZSBjaGlwc2V0IChFQ1AvRVBQL1BTMi9OSUJCTEUpIGluIENPTVBBVElCTEUgbW9kZQpwcGMwOiBG SUZPIHdpdGggMTYvMTYvOCBieXRlcyB0aHJlc2hvbGQKcHBidXMwOiA8UGFyYWxsZWwgcG9ydCBi dXM+IG9uIHBwYzAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gNyAoSVNBIElSUSA3KSB0byB2ZWN0 b3IgNjEKcHBidXMwOiBbTVBTQUZFXQpwcGJ1czA6IFtJVEhSRUFEXQpwbGlwMDogPFBMSVAgbmV0 d29yayBpbnRlcmZhY2U+IG9uIHBwYnVzMApwbGlwMDogYnBmIGF0dGFjaGVkCmxwdDA6IDxQcmlu dGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxl bCBJL08+IG9uIHBwYnVzMApwcGMwOiBbR0lBTlQtTE9DS0VEXQpwcGMwOiBbSVRIUkVBRF0Kc2Mw OiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZp cnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzYzA6IGZiMCwga2JkMSwgdGVybWluYWwgZW11 bGF0b3I6IHNjIChzeXNjb25zIHRlcm1pbmFsKQpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBp biBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApz aW8xOiBpcnEgbWFwczogMHg4ZWU5IDB4OGVlOSAweDhlZTkgMHg4ZWU5CnNpbzE6IHByb2JlIGZh aWxlZCB0ZXN0KHMpOiAwIDEgMiA0IDYgNyA5CnNpbzEgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQg MHgyZjgtMHgyZmYgaXJxIDMgb24gaXNhMApzaW8yOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc2lv Mzogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNuMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCnZnYTA6 IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJm ZmZmIG9uIGlzYTAKdnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKaXNhX3Byb2JlX2NoaWxkcmVu OiBwcm9iaW5nIFBuUCBkZXZpY2VzCnVnZW4wOiA8U1RNaWNyb2VsZWN0cm9uaWNzIEJpb21ldHJp YyBDb3Byb2Nlc3NvciwgY2xhc3MgMC8wLCByZXYgMS4wMC8wLjAxLCBhZGRyIDI+IG9uIHVodWIy CkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpSZWR1Y2luZyBrZXJuLm1heHZub2RlcyAx MzQwMzQgLT4gMTAwMDAwCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1 ZW5jeSA2NjUwNDY5NiBoegpUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMjI2MTE1OTYyNyBI eiBxdWFsaXR5IDgwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmxvMDogYnBm IGF0dGFjaGVkCmhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVkLgpiYXR0ZXJ5MDogYmF0dGVy eSBpbml0aWFsaXphdGlvbiBzdGFydAphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24g c3RhcnQKYXRhMC1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTAwIGNhYmxl PTgwIHdpcmUKYWQwOiA5NTM5Nk1CIDxTZWFnYXRlIFNUOTEwMDIxQSAzLjA0PiBhdCBhdGEwLW1h c3RlciBVRE1BMTAwCmFkMDogMTk1MzcxNTY4IHNlY3RvcnMgWzE5MzgyMUMvMTZILzYzU10gMTYg c2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpHRU9NOiBuZXcgZGlzayBhZDAKYmF0dGVy eTA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1lcwphY3BpX2FjYWQw OiBPbiBMaW5lCmFjcGlfYWNhZDA6IGFjbGluZSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAx IHRpbWVzCmFkMDogSW50ZWwgY2hlY2sxIGZhaWxlZAphZDA6IEFkYXB0ZWMgY2hlY2sxIGZhaWxl ZAphZDA6IExTSSAodjMpIGNoZWNrMSBmYWlsZWQKYWQwOiBMU0kgKHYyKSBjaGVjazEgZmFpbGVk CmFkMDogRnJlZUJTRCBjaGVjazEgZmFpbGVkCmF0YTEtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdE TUEyIHVkbWE9VURNQTMzIGNhYmxlPTgwIHdpcmUKYWNkMDogPE1BVFNISVRBRFZELVJBTSBVSi04 NTIvUkIwMT4gRFZEUiBkcml2ZSBhdCBhdGExIGFzIG1hc3RlcgphY2QwOiByZWFkIDQxMzRLQi9z ICg0MTM0S0Ivcykgd3JpdGUgNDEzNEtCL3MgKDQxMzRLQi9zKSwgMjA0OEtCIGJ1ZmZlciwgVURN QTMzCmFjZDA6IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBEVkRST00sIERWRFIsIERW RFJBTSwgcGFja2V0CmFjZDA6IFdyaXRlczogQ0RSLCBDRFJXLCBEVkRSLCBEVkRSQU0sIHRlc3Qg d3JpdGUsIGJ1cm5wcm9vZgphY2QwOiBBdWRpbzogcGxheSwgMjU2IHZvbHVtZSBsZXZlbHMKYWNk MDogTWVjaGFuaXNtOiBlamVjdGFibGUgdHJheSwgdW5sb2NrZWQKYWNkMDogTWVkaXVtOiBuby9i bGFuayBkaXNjCnBjbTA6IG1lYXN1cmVkIGFjOTcgbGluayByYXRlIGF0IDQ4MDE0IEh6LCB3aWxs IHVzZSA0ODAwMCBIegpBVEEgUHNldWRvUkFJRCBsb2FkZWQKVHJ5aW5nIHRvIG1vdW50IHJvb3Qg ZnJvbSB1ZnM6L2Rldi9hZDBzMWEKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKYmdlMDog bGluayBVUAp1bWFzczA6IDx2ZW5kb3IgMHgwZDdkIFVTQiBESVNLIDI1WCwgY2xhc3MgMC8wLCBy ZXYgMi4wMC8xLjAwLCBhZGRyIDI+IG9uIHVodWI0CnVtYXNzMDowOjA6LTE6IEF0dGFjaGVkIHRv IHNjYnVzMAoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBEb3duIHJldmluZyBQcm90b2NvbCBW ZXJzaW9uIGZyb20gMiB0byAwPwpwYXNzMCBhdCB1bWFzcy1zaW0wIGJ1cyAwIHRhcmdldCAwIGx1 biAwCnBhc3MwOiA8IFVTQiBESVNLIDI1WCBQTUFQPiBSZW1vdmFibGUgRGlyZWN0IEFjY2VzcyBT Q1NJLTAgZGV2aWNlIApwYXNzMDogU2VyaWFsIE51bWJlciBcXl8KcGFzczA6IDQwLjAwME1CL3Mg dHJhbnNmZXJzCkdFT006IG5ldyBkaXNrIGRhMApkYTAgYXQgdW1hc3Mtc2ltMCBidXMgMCB0YXJn ZXQgMCBsdW4gMApkYTA6IDwgVVNCIERJU0sgMjVYIFBNQVA+IFJlbW92YWJsZSBEaXJlY3QgQWNj ZXNzIFNDU0ktMCBkZXZpY2UgCmRhMDogU2VyaWFsIE51bWJlciBcXl8KZGEwOiA0MC4wMDBNQi9z IHRyYW5zZmVycwpkYTA6IDk2Mk1CICgxOTcwMTc2IDUxMiBieXRlIHNlY3RvcnM6IDY0SCAzMlMv VCA5NjJDKQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgZGEwczEgaXMgbXNkb3Nmcy9V TkkgV09SSy4KR0VPTV9MQUJFTDogTGFiZWwgbXNkb3Nmcy9VTkkgV09SSyByZW1vdmVkLgo= ------=_Part_56_30755184.1205803276757 Content-Type: application/octet-stream; name=sysctl-a-RELENG_7-CVS.log Content-Transfer-Encoding: base64 X-Attachment-Id: f_fdxorums Content-Disposition: attachment; filename=sysctl-a-RELENG_7-CVS.log a2Vybi5vc3R5cGU6IEZyZWVCU0QKa2Vybi5vc3JlbGVhc2U6IDcuMC1TVEFCTEUKa2Vybi5vc3Jl dmlzaW9uOiAxOTk1MDYKa2Vybi52ZXJzaW9uOiBGcmVlQlNEIDcuMC1TVEFCTEUgIzA6IE1vbiBN YXIgMTcgMjE6MjE6MDcgVVRDIDIwMDgKICAgIHJvb3RAYnVpbGQtY2Q6L3RtcC9vYmovdXNyL3Ny Yy9zeXMvU0VLSE1FVAoKa2Vybi5tYXh2bm9kZXM6IDEwMDAwMAprZXJuLm1heHByb2M6IDYxNjQK a2Vybi5tYXhmaWxlczogMTIzMjgKa2Vybi5hcmdtYXg6IDI2MjE0NAprZXJuLnNlY3VyZWxldmVs OiAtMQprZXJuLmhvc3RuYW1lOiBzZWtobWV0Lmh5YnJpZC1sYWIubmV0Cmtlcm4uaG9zdGlkOiAy NTk0MjEwNDgwCmtlcm4uY2xvY2tyYXRlOiB7IGh6ID0gMTAwMCwgdGljayA9IDEwMDAsIHByb2Zo eiA9IDY2Niwgc3RhdGh6ID0gMTMzIH0Ka2Vybi5wb3NpeDF2ZXJzaW9uOiAyMDAxMTIKa2Vybi5u Z3JvdXBzOiAxNgprZXJuLmpvYl9jb250cm9sOiAxCmtlcm4uc2F2ZWRfaWRzOiAwCmtlcm4uYm9v dHRpbWU6IHsgc2VjID0gMTIwNTc5NTM3MSwgdXNlYyA9IDI0NjMzOCB9IE1vbiBNYXIgMTcgMjM6 MDk6MzEgMjAwOAprZXJuLmRvbWFpbm5hbWU6IAprZXJuLm9zcmVsZGF0ZTogNzAwMTAxCmtlcm4u Ym9vdGZpbGU6IC9ib290L2tlcm5lbC9rZXJuZWwKa2Vybi5tYXhmaWxlc3BlcnByb2M6IDExMDk1 Cmtlcm4ubWF4cHJvY3BlcnVpZDogNTU0NwprZXJuLmlwYy5tYXhzb2NrYnVmOiAyNjIxNDQKa2Vy bi5pcGMuc29ja2J1Zl93YXN0ZV9mYWN0b3I6IDgKa2Vybi5pcGMuc29tYXhjb25uOiAxMjgKa2Vy bi5pcGMubWF4X2xpbmtoZHI6IDQwCmtlcm4uaXBjLm1heF9wcm90b2hkcjogNjAKa2Vybi5pcGMu bWF4X2hkcjogMTAwCmtlcm4uaXBjLm1heF9kYXRhbGVuOiAxMDQKa2Vybi5pcGMubm1ianVtYm8x NjogMzIwMAprZXJuLmlwYy5ubWJqdW1ibzk6IDY0MDAKa2Vybi5pcGMubm1ianVtYm9wOiAxMjgw MAprZXJuLmlwYy5ubWJjbHVzdGVyczogMjU2MDAKa2Vybi5pcGMucGlwZXJlc2l6ZWFsbG93ZWQ6 IDEKa2Vybi5pcGMucGlwZXJlc2l6ZWZhaWw6IDAKa2Vybi5pcGMucGlwZWFsbG9jZmFpbDogMApr ZXJuLmlwYy5waXBlZnJhZ3JldHJ5OiAwCmtlcm4uaXBjLnBpcGVrdmE6IDQwOTYKa2Vybi5pcGMu bWF4cGlwZWt2YTogMTY3NzcyMTYKa2Vybi5pcGMubXNnc2VnOiAyMDQ4Cmtlcm4uaXBjLm1zZ3Nz ejogOAprZXJuLmlwYy5tc2d0cWw6IDQwCmtlcm4uaXBjLm1zZ21uYjogMjA0OAprZXJuLmlwYy5t c2dtbmk6IDQwCmtlcm4uaXBjLm1zZ21heDogMTYzODQKa2Vybi5pcGMuc2VtYWVtOiAxNjM4NApr ZXJuLmlwYy5zZW12bXg6IDMyNzY3Cmtlcm4uaXBjLnNlbXVzejogOTIKa2Vybi5pcGMuc2VtdW1l OiAxMAprZXJuLmlwYy5zZW1vcG06IDEwMAprZXJuLmlwYy5zZW1tc2w6IDYwCmtlcm4uaXBjLnNl bW1udTogMzAKa2Vybi5pcGMuc2VtbW5zOiA2MAprZXJuLmlwYy5zZW1tbmk6IDEwCmtlcm4uaXBj LnNlbW1hcDogMzAKa2Vybi5pcGMuc2htX2FsbG93X3JlbW92ZWQ6IDAKa2Vybi5pcGMuc2htX3Vz ZV9waHlzOiAwCmtlcm4uaXBjLnNobWFsbDogODE5MgprZXJuLmlwYy5zaG1zZWc6IDEyOAprZXJu LmlwYy5zaG1tbmk6IDE5MgprZXJuLmlwYy5zaG1taW46IDEKa2Vybi5pcGMuc2htbWF4OiAzMzU1 NDQzMgprZXJuLmlwYy5tYXhzb2NrZXRzOiAxMjMyOAprZXJuLmlwYy56ZXJvX2NvcHkuc2VuZDog MQprZXJuLmlwYy56ZXJvX2NvcHkucmVjZWl2ZTogMQprZXJuLmlwYy5udW1vcGVuc29ja2V0czog MTAKa2Vybi5pcGMubnNmYnVmc3VzZWQ6IDAKa2Vybi5pcGMubnNmYnVmc3BlYWs6IDMKa2Vybi5p cGMubnNmYnVmczogNjY1NgprZXJuLmR1bW15OiAwCmtlcm4ucHNfc3RyaW5nczogMzIxNzAzMTE1 MgprZXJuLnVzcnN0YWNrOiAzMjE3MDMxMTY4Cmtlcm4ubG9nc2lnZXhpdDogMQprZXJuLmlvdl9t YXg6IDEwMjQKa2Vybi5ob3N0dXVpZDogZGRlMjkwMDEtNDg5OS0xMWNiLWI4MTgtODM2OGFmNDRi MTAxCmtlcm4uYXJhbmRvbTogMTQzNDQ0ODM5MwprZXJuLmNhbS5jYW1fc3JjaF9oaTogMAprZXJu LmNhbS5zY3NpX2RlbGF5OiA1MDAwCmtlcm4uY2FtLmRhLmRhX3NlbmRfb3JkZXJlZDogMQprZXJu LmNhbS5kYS5kZWZhdWx0X3RpbWVvdXQ6IDYwCmtlcm4uY2FtLmRhLnJldHJ5X2NvdW50OiA0Cmtl cm4uY2FtLmRhLjAubWluaW11bV9jbWRfc2l6ZTogMTAKa2Vybi5kaXNrczogZGEwIGFkMAprZXJu Lmdlb20uZWxpLmJhdGNoOiAwCmtlcm4uZ2VvbS5lbGkudGhyZWFkczogMAprZXJuLmdlb20uZWxp Lm92ZXJ3cml0ZXM6IDUKa2Vybi5nZW9tLmVsaS52aXNpYmxlX3Bhc3NwaHJhc2U6IDAKa2Vybi5n ZW9tLmVsaS50cmllczogMwprZXJuLmdlb20uZWxpLmRlYnVnOiAwCmtlcm4uZ2VvbS5jb2xsZWN0 c3RhdHM6IDEKa2Vybi5nZW9tLmRlYnVnZmxhZ3M6IDAKa2Vybi5nZW9tLmxhYmVsLmRlYnVnOiAw Cmtlcm4uZWxmMzIuZmFsbGJhY2tfYnJhbmQ6IC0xCmtlcm4uaW5pdF9zaHV0ZG93bl90aW1lb3V0 OiAxMjAKa2Vybi5pbml0X3BhdGg6IC9zYmluL2luaXQ6L3NiaW4vb2luaXQ6L3NiaW4vaW5pdC5i YWs6L3Jlc2N1ZS9pbml0Oi9zdGFuZC9zeXNpbnN0YWxsCmtlcm4uYWNjdF9zdXNwZW5kZWQ6IDAK a2Vybi5hY2N0X2NvbmZpZ3VyZWQ6IDAKa2Vybi5hY2N0X2Noa2ZyZXE6IDE1Cmtlcm4uYWNjdF9y ZXN1bWU6IDQKa2Vybi5hY2N0X3N1c3BlbmQ6IDIKa2Vybi5jcF90aW1lOiAxMzcgMCAxNDcgMTEg MjkwMzMKa2Vybi5vcGVuZmlsZXM6IDQ0Cmtlcm4ua3FfY2FsbG91dG1heDogNDA5NgprZXJuLnBz X2FyZ19jYWNoZV9saW1pdDogMjU2Cmtlcm4uc3RhY2twcm90OiA3Cmtlcm4ucmFuZG9tcGlkOiAw Cmtlcm4ubGFzdHBpZDogODcyCmtlcm4ua3RyYWNlLnJlcXVlc3RfcG9vbDogMTAwCmtlcm4ua3Ry YWNlLmdlbmlvX3NpemU6IDQwOTYKa2Vybi5tb2R1bGVfcGF0aDogL2Jvb3Qva2VybmVsOy9ib290 L21vZHVsZXMKa2Vybi5tYWxsb2NfY291bnQ6IDIyOAprZXJuLmZhbGxiYWNrX2VsZl9icmFuZDog LTEKa2Vybi5tYXh1c2VyczogMzg0Cmtlcm4uaWRlbnQ6IFNFS0hNRVQ6VDQzcAprZXJuLmtzdGFj a19wYWdlczogMgprZXJuLnNodXRkb3duLmtwcm9jX3NodXRkb3duX3dhaXQ6IDYwCmtlcm4uc2h1 dGRvd24ucG93ZXJvZmZfZGVsYXk6IDUwMDAKa2Vybi5zeW5jX29uX3BhbmljOiAwCmtlcm4uY29y ZWZpbGU6ICVOLmNvcmUKa2Vybi5ub2R1bXBfY29yZWR1bXA6IDAKa2Vybi5jb3JlZHVtcDogMQpr ZXJuLnN1Z2lkX2NvcmVkdW1wOiAwCmtlcm4uc2lncXVldWUuYWxsb2NfZmFpbDogMAprZXJuLnNp Z3F1ZXVlLm92ZXJmbG93OiAwCmtlcm4uc2lncXVldWUucHJlYWxsb2NhdGU6IDEwMjQKa2Vybi5z aWdxdWV1ZS5tYXhfcGVuZGluZ19wZXJfcHJvYzogMTI4Cmtlcm4uZm9yY2VzaWdleGl0OiAxCmtl cm4uZnNjYWxlOiAyMDQ4Cmtlcm4udGltZWNvdW50ZXIudGljazogMQprZXJuLnRpbWVjb3VudGVy LmNob2ljZTogVFNDKDgwMCkgQUNQSS1mYXN0KDEwMDApIGk4MjU0KDApIGR1bW15KC0xMDAwMDAw KQprZXJuLnRpbWVjb3VudGVyLmhhcmR3YXJlOiBBQ1BJLWZhc3QKa2Vybi50aW1lY291bnRlci5u c2V0Y2xvY2s6IDIKa2Vybi50aW1lY291bnRlci5uZ2V0bWljcm90aW1lOiAyNDk2OAprZXJuLnRp bWVjb3VudGVyLm5nZXRuYW5vdGltZTogMjYKa2Vybi50aW1lY291bnRlci5uZ2V0YmludGltZTog MAprZXJuLnRpbWVjb3VudGVyLm5nZXRtaWNyb3VwdGltZTogMTU0MTEKa2Vybi50aW1lY291bnRl ci5uZ2V0bmFub3VwdGltZTogNDQKa2Vybi50aW1lY291bnRlci5uZ2V0YmludXB0aW1lOiA0MTYK a2Vybi50aW1lY291bnRlci5ubWljcm90aW1lOiAyMDk4MgprZXJuLnRpbWVjb3VudGVyLm5uYW5v dGltZTogMTEKa2Vybi50aW1lY291bnRlci5uYmludGltZTogMjA5OTMKa2Vybi50aW1lY291bnRl ci5ubWljcm91cHRpbWU6IDkyMAprZXJuLnRpbWVjb3VudGVyLm5uYW5vdXB0aW1lOiA0Cmtlcm4u dGltZWNvdW50ZXIubmJpbnVwdGltZTogMzIwNDgKa2Vybi50aW1lY291bnRlci5zdGVwd2Fybmlu Z3M6IDAKa2Vybi50aW1lY291bnRlci50Yy5pODI1NC5tYXNrOiA2NTUzNQprZXJuLnRpbWVjb3Vu dGVyLnRjLmk4MjU0LmNvdW50ZXI6IDEwNTg5Cmtlcm4udGltZWNvdW50ZXIudGMuaTgyNTQuZnJl cXVlbmN5OiAxMTkzMTgyCmtlcm4udGltZWNvdW50ZXIudGMuaTgyNTQucXVhbGl0eTogMAprZXJu LnRpbWVjb3VudGVyLnRjLkFDUEktZmFzdC5tYXNrOiAxNjc3NzIxNQprZXJuLnRpbWVjb3VudGVy LnRjLkFDUEktZmFzdC5jb3VudGVyOiAxMzM1ODgxNwprZXJuLnRpbWVjb3VudGVyLnRjLkFDUEkt ZmFzdC5mcmVxdWVuY3k6IDM1Nzk1NDUKa2Vybi50aW1lY291bnRlci50Yy5BQ1BJLWZhc3QucXVh bGl0eTogMTAwMAprZXJuLnRpbWVjb3VudGVyLnRjLlRTQy5tYXNrOiA0Mjk0OTY3Mjk1Cmtlcm4u dGltZWNvdW50ZXIudGMuVFNDLmNvdW50ZXI6IDY4NjE1Njg2MQprZXJuLnRpbWVjb3VudGVyLnRj LlRTQy5mcmVxdWVuY3k6IDEwMDAwMDAwMAprZXJuLnRpbWVjb3VudGVyLnRjLlRTQy5xdWFsaXR5 OiA4MDAKa2Vybi50aW1lY291bnRlci5zbXBfdHNjOiAwCmtlcm4udGhyZWFkcy52aXJ0dWFsX2Nw dTogMQprZXJuLnRocmVhZHMubWF4X3RocmVhZHNfaGl0czogMAprZXJuLnRocmVhZHMubWF4X3Ro cmVhZHNfcGVyX3Byb2M6IDE1MDAKa2Vybi5jY3B1OiAwCmtlcm4uc2NoZWQucHJlZW1wdGlvbjog MQprZXJuLnNjaGVkLnRvcG9sb2d5OiAwCmtlcm4uc2NoZWQuc3RlYWxfdGhyZXNoOiAwCmtlcm4u c2NoZWQuc3RlYWxfaWRsZTogMQprZXJuLnNjaGVkLnN0ZWFsX2h0dDogMQprZXJuLnNjaGVkLmJh bGFuY2VfaW50ZXJ2YWw6IDEzMwprZXJuLnNjaGVkLmJhbGFuY2U6IDEKa2Vybi5zY2hlZC50cnlz ZWxmOiAxCmtlcm4uc2NoZWQuYWZmaW5pdHk6IDMKa2Vybi5zY2hlZC5waWNrX3ByaTogMQprZXJu LnNjaGVkLnByZWVtcHRfdGhyZXNoOiA2NAprZXJuLnNjaGVkLmludGVyYWN0OiAzMAprZXJuLnNj aGVkLnNsaWNlOiAxMwprZXJuLnNjaGVkLm5hbWU6IFVMRQprZXJuLmRldnN0YXQudmVyc2lvbjog NgprZXJuLmRldnN0YXQuZ2VuZXJhdGlvbjogMzg0Cmtlcm4uZGV2c3RhdC5udW1kZXZzOiAyCmtl cm4ua29ial9tZXRob2Rjb3VudDogMTY4Cmtlcm4ubG9nX3dha2V1cHNfcGVyX3NlY29uZDogNQpr ZXJuLm1zZ2J1Zl9jbGVhcjogMAprZXJuLm1zZ2J1ZjogCmtlcm4uYWx3YXlzX2NvbnNvbGVfb3V0 cHV0OiAwCmtlcm4ubG9nX2NvbnNvbGVfb3V0cHV0OiAxCmtlcm4uc21wLmZvcndhcmRfcm91bmRy b2Jpbl9lbmFibGVkOiAxCmtlcm4uc21wLmZvcndhcmRfc2lnbmFsX2VuYWJsZWQ6IDEKa2Vybi5z bXAuY3B1czogMQprZXJuLnNtcC5kaXNhYmxlZDogMAprZXJuLnNtcC5hY3RpdmU6IDAKa2Vybi5z bXAubWF4Y3B1czogMTYKa2Vybi5uc2VsY29sbDogMAprZXJuLnR0eV9ub3V0OiA2MDc4NTQKa2Vy bi50dHlfbmluOiAxNTMyCmtlcm4uZHJhaW53YWl0OiAzMDAKa2Vybi5jb25zdHR5X3dha2V1cHNf cGVyX3NlY29uZDogNQprZXJuLmNvbnNtc2didWZfc2l6ZTogODE5MgprZXJuLmNvbnNtdXRlOiAw Cmtlcm4uY29uc29sZTogY29uc29sZWN0bCwvY29uc29sZWN0bCx0dHlkMCwKa2Vybi5taW52bm9k ZXM6IDI1MDAwCmtlcm4ubWV0YWRlbGF5OiAyOAprZXJuLmRpcmRlbGF5OiAyOQprZXJuLmZpbGVk ZWxheTogMzAKa2Vybi5jaHJvb3RfYWxsb3dfb3Blbl9kaXJlY3RvcmllczogMQprZXJuLmNyeXB0 b2RldmFsbG93c29mdDogMAprZXJuLnVzZXJhc3ltY3J5cHRvOiAxCmtlcm4ucnBjLmludmFsaWQ6 IDAKa2Vybi5ycGMudW5leHBlY3RlZDogMAprZXJuLnJwYy50aW1lb3V0czogMAprZXJuLnJwYy5y ZXF1ZXN0OiAwCmtlcm4ucnBjLnJldHJpZXM6IDAKa2Vybi5yYW5kb20ueWFycm93LmdlbmdhdGVp bnRlcnZhbDogMTAKa2Vybi5yYW5kb20ueWFycm93LmJpbnM6IDEwCmtlcm4ucmFuZG9tLnlhcnJv dy5mYXN0dGhyZXNoOiAxOTIKa2Vybi5yYW5kb20ueWFycm93LnNsb3d0aHJlc2g6IDI1NgprZXJu LnJhbmRvbS55YXJyb3cuc2xvd292ZXJ0aHJlc2g6IDIKa2Vybi5yYW5kb20uc3lzLnNlZWRlZDog MQprZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5ldGhlcm5ldDogMQprZXJuLnJhbmRvbS5zeXMuaGFy dmVzdC5wb2ludF90b19wb2ludDogMQprZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5pbnRlcnJ1cHQ6 IDEKa2Vybi5yYW5kb20uc3lzLmhhcnZlc3Quc3dpOiAwCnZtLnZtdG90YWw6IApTeXN0ZW0gd2lk ZSB0b3RhbHMgY29tcHV0ZWQgZXZlcnkgZml2ZSBzZWNvbmRzOiAodmFsdWVzIGluIGtpbG9ieXRl cykKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUHJvY2Vz c2VzOgkJKFJVTlE6IDIgRGlzayBXYWl0OiAwIFBhZ2UgV2FpdDogMCBTbGVlcDogMTMpClZpcnR1 YWwgTWVtb3J5OgkJKFRvdGFsOiAyMjk2NzQwSywgQWN0aXZlIDMzMDk2SykKUmVhbCBNZW1vcnk6 CQkoVG90YWw6IDE5ODA4SyBBY3RpdmUgNzA4OEspClNoYXJlZCBWaXJ0dWFsIE1lbW9yeToJKFRv dGFsOiAxNTA0SyBBY3RpdmU6IDE0NjhLKQpTaGFyZWQgUmVhbCBNZW1vcnk6CShUb3RhbDogMTM5 MksgQWN0aXZlOiAxMzU2SykKRnJlZSBNZW1vcnkgUGFnZXM6CTIwMTgwNDhLCgp2bS5sb2FkYXZn OiB7IDAuMDcgMC4yMiAwLjEyIH0Kdm0udl9mcmVlX21pbjogMzI3OAp2bS52X2ZyZWVfdGFyZ2V0 OiAxMzgyOQp2bS52X2ZyZWVfcmVzZXJ2ZWQ6IDcxNwp2bS52X2luYWN0aXZlX3RhcmdldDogMjA3 NDMKdm0udl9jYWNoZV9taW46IDEzODI5CnZtLnZfY2FjaGVfbWF4OiAyNzY1OAp2bS52X3BhZ2Vv dXRfZnJlZV9taW46IDM0CnZtLnBhZ2VvdXRfYWxnb3JpdGhtOiAwCnZtLnN3YXBfZW5hYmxlZDog MQp2bS5rbWVtX3NpemVfc2NhbGU6IDMKdm0ua21lbV9zaXplX21heDogMzM1NTQ0MzIwCnZtLmtt ZW1fc2l6ZV9taW46IDAKdm0ua21lbV9zaXplOiAzMzU1NDQzMjAKdm0ubnN3YXBkZXY6IDEKdm0u ZG1tYXg6IDMyCnZtLnN3YXBfYXN5bmNfbWF4OiA0CnZtLnpvbmVfY291bnQ6IDkzCnZtLnN3YXBf aWRsZV90aHJlc2hvbGQyOiAxMAp2bS5zd2FwX2lkbGVfdGhyZXNob2xkMTogMgp2bS5leGVjX21h cF9lbnRyaWVzOiAxNgp2bS5zdGF0cy5taXNjLnplcm9fcGFnZV9jb3VudDogMAp2bS5zdGF0cy5t aXNjLmNudF9wcmV6ZXJvOiAwCnZtLnN0YXRzLnZtLnZfa3RocmVhZHBhZ2VzOiAwCnZtLnN0YXRz LnZtLnZfcmZvcmtwYWdlczogMAp2bS5zdGF0cy52bS52X3Zmb3JrcGFnZXM6IDE2NzQxCnZtLnN0 YXRzLnZtLnZfZm9ya3BhZ2VzOiAyNjEyNDcKdm0uc3RhdHMudm0udl9rdGhyZWFkczogNTUKdm0u c3RhdHMudm0udl9yZm9ya3M6IDAKdm0uc3RhdHMudm0udl92Zm9ya3M6IDM1CnZtLnN0YXRzLnZt LnZfZm9ya3M6IDc4Mgp2bS5zdGF0cy52bS52X2ludGVycnVwdF9mcmVlX21pbjogMgp2bS5zdGF0 cy52bS52X3BhZ2VvdXRfZnJlZV9taW46IDM0CnZtLnN0YXRzLnZtLnZfY2FjaGVfbWF4OiAyNzY1 OAp2bS5zdGF0cy52bS52X2NhY2hlX21pbjogMTM4MjkKdm0uc3RhdHMudm0udl9jYWNoZV9jb3Vu dDogMTIxCnZtLnN0YXRzLnZtLnZfaW5hY3RpdmVfY291bnQ6IDIxMDIKdm0uc3RhdHMudm0udl9p bmFjdGl2ZV90YXJnZXQ6IDIwNzQzCnZtLnN0YXRzLnZtLnZfYWN0aXZlX2NvdW50OiAxNTQ5CnZt LnN0YXRzLnZtLnZfd2lyZV9jb3VudDogNDI0MQp2bS5zdGF0cy52bS52X2ZyZWVfY291bnQ6IDUw NDM5MQp2bS5zdGF0cy52bS52X2ZyZWVfbWluOiAzMjc4CnZtLnN0YXRzLnZtLnZfZnJlZV90YXJn ZXQ6IDEzODI5CnZtLnN0YXRzLnZtLnZfZnJlZV9yZXNlcnZlZDogNzE3CnZtLnN0YXRzLnZtLnZf cGFnZV9jb3VudDogNTEyNTA2CnZtLnN0YXRzLnZtLnZfcGFnZV9zaXplOiA0MDk2CnZtLnN0YXRz LnZtLnZfdGZyZWU6IDk2MzkwCnZtLnN0YXRzLnZtLnZfcGZyZWU6IDIxNTg5CnZtLnN0YXRzLnZt LnZfZGZyZWU6IDAKdm0uc3RhdHMudm0udl90Y2FjaGVkOiAzMzcKdm0uc3RhdHMudm0udl9wZHBh Z2VzOiAwCnZtLnN0YXRzLnZtLnZfcGR3YWtldXBzOiAwCnZtLnN0YXRzLnZtLnZfcmVhY3RpdmF0 ZWQ6IDIwMwp2bS5zdGF0cy52bS52X2ludHJhbnM6IDIKdm0uc3RhdHMudm0udl92bm9kZXBnc291 dDogMAp2bS5zdGF0cy52bS52X3Zub2RlcGdzaW46IDI4NDkKdm0uc3RhdHMudm0udl92bm9kZW91 dDogMAp2bS5zdGF0cy52bS52X3Zub2RlaW46IDQwNAp2bS5zdGF0cy52bS52X3N3YXBwZ3NvdXQ6 IDAKdm0uc3RhdHMudm0udl9zd2FwcGdzaW46IDAKdm0uc3RhdHMudm0udl9zd2Fwb3V0OiAwCnZt LnN0YXRzLnZtLnZfc3dhcGluOiAwCnZtLnN0YXRzLnZtLnZfb3pmb2Q6IDQzNgp2bS5zdGF0cy52 bS52X3pmb2Q6IDExODQzCnZtLnN0YXRzLnZtLnZfY293X29wdGltOiAyOQp2bS5zdGF0cy52bS52 X2Nvd19mYXVsdHM6IDE3Njk3CnZtLnN0YXRzLnZtLnZfdm1fZmF1bHRzOiAzODcyNgp2bS5zdGF0 cy5zeXMudl9zb2Z0OiAzNDA0MAp2bS5zdGF0cy5zeXMudl9pbnRyOiA0NDUxCnZtLnN0YXRzLnN5 cy52X3N5c2NhbGw6IDI2NDY0Mwp2bS5zdGF0cy5zeXMudl90cmFwOiA0NDQyNwp2bS5zdGF0cy5z eXMudl9zd3RjaDogMTA3ODk4CnZtLnN0YXRzLm9iamVjdC5ieXBhc3NlczogMjU4CnZtLnN0YXRz Lm9iamVjdC5jb2xsYXBzZXM6IDI2NjkKdm0udl9mcmVlX3NldmVyZTogMTk5Nwp2bS5tYXhfcHJv Y19tbWFwOiA0OTM0NAp2bS5vbGRfbXN5bmM6IDAKdm0ubXN5bmNfZmx1c2hfZmxhZ3M6IDMKdm0u Ym9vdF9wYWdlczogNDgKdm0ucGFnZW91dF9sb2NrX21pc3M6IDAKdm0uZGlzYWJsZV9zd2Fwc3Bh Y2VfcGFnZW91dHM6IDAKdm0uZGVmZXJfc3dhcHNwYWNlX3BhZ2VvdXRzOiAwCnZtLnN3YXBfaWRs ZV9lbmFibGVkOiAwCnZtLnBhZ2VvdXRfc3RhdHNfaW50ZXJ2YWw6IDUKdm0ucGFnZW91dF9mdWxs X3N0YXRzX2ludGVydmFsOiAyMAp2bS5wYWdlb3V0X3N0YXRzX21heDogMTM4MjkKdm0ubWF4X2xh dW5kZXI6IDMyCnZtLnBoeXNfc2VnczogClNFR01FTlQgMDoKCnN0YXJ0OiAgICAgMHgxMDAwCmVu ZDogICAgICAgMHg5ZTAwMApmcmVlIGxpc3Q6IDB4YzA5ZGYwNjgKClNFR01FTlQgMToKCnN0YXJ0 OiAgICAgMHgxMDAwMDAKZW5kOiAgICAgICAweDQwMDAwMApmcmVlIGxpc3Q6IDB4YzA5ZGYwNjgK ClNFR01FTlQgMjoKCnN0YXJ0OiAgICAgMHhjMjgwMDAKZW5kOiAgICAgICAweDEwMDAwMDAKZnJl ZSBsaXN0OiAweGMwOWRmMDY4CgpTRUdNRU5UIDM6CgpzdGFydDogICAgIDB4MTAwMDAwMAplbmQ6 ICAgICAgIDB4N2RhODUwMDAKZnJlZSBsaXN0OiAweGMwOWRlZjYwCgp2bS5waHlzX2ZyZWU6IApG UkVFIExJU1QgMDoKCiAgT1JERVIgKFNJWkUpICB8ICBOVU1CRVIKICAgICAgICAgICAgICAgIHwg IFBPT0wgMCAgfCAgUE9PTCAxCi0tICAgICAgICAgICAgLS0gLS0gICAgICAtLSAtLSAgICAgIC0t CiAgMTAgKCAgNDA5NkspICB8ICAgICA0OTAgIHwgICAgICAgMAogICA5ICggIDIwNDhLKSAgfCAg ICAgICAxICB8ICAgICAgIDAKICAgOCAoICAxMDI0SykgIHwgICAgICAgMCAgfCAgICAgICAwCiAg IDcgKCAgIDUxMkspICB8ICAgICAgIDEgIHwgICAgICAgMAogICA2ICggICAyNTZLKSAgfCAgICAg ICAxICB8ICAgICAgIDAKICAgNSAoICAgMTI4SykgIHwgICAgICAgMCAgfCAgICAgICAwCiAgIDQg KCAgICA2NEspICB8ICAgICAgIDEgIHwgICAgICAgMAogICAzICggICAgMzJLKSAgfCAgICAgICAw ICB8ICAgICAgIDAKICAgMiAoICAgIDE2SykgIHwgICAgICAgMCAgfCAgICAgICA5CiAgIDEgKCAg ICAgOEspICB8ICAgICAgIDEgIHwgICAgICAyMgogICAwICggICAgIDRLKSAgfCAgICAgICAxICB8 ICAgICAgNDEKCkZSRUUgTElTVCAxOgoKICBPUkRFUiAoU0laRSkgIHwgIE5VTUJFUgogICAgICAg ICAgICAgICAgfCAgUE9PTCAwICB8ICBQT09MIDEKLS0gICAgICAgICAgICAtLSAtLSAgICAgIC0t IC0tICAgICAgLS0KICAxMCAoICA0MDk2SykgIHwgICAgICAgMCAgfCAgICAgICAwCiAgIDkgKCAg MjA0OEspICB8ICAgICAgIDIgIHwgICAgICAgMAogICA4ICggIDEwMjRLKSAgfCAgICAgICAyICB8 ICAgICAgIDAKICAgNyAoICAgNTEySykgIHwgICAgICAgMSAgfCAgICAgICAwCiAgIDYgKCAgIDI1 NkspICB8ICAgICAgIDIgIHwgICAgICAgMAogICA1ICggICAxMjhLKSAgfCAgICAgICAxICB8ICAg ICAgIDAKICAgNCAoICAgIDY0SykgIHwgICAgICAgMyAgfCAgICAgICAwCiAgIDMgKCAgICAzMksp ICB8ICAgICAgIDMgIHwgICAgICAgMAogICAyICggICAgMTZLKSAgfCAgICAgICAyICB8ICAgICAg IDAKICAgMSAoICAgICA4SykgIHwgICAgICAgMSAgfCAgICAgICAwCiAgIDAgKCAgICAgNEspICB8 ICAgICAgIDEgIHwgICAgICAgMAoKdm0uaWRsZXplcm9fZW5hYmxlOiAwCnZtLmt2bV9mcmVlOiA0 MDY4NDMzOTIKdm0ua3ZtX3NpemU6IDEwNjk1NDM0MjQKdm0ucG1hcC5wbWFwX2NvbGxlY3RfYWN0 aXZlOiAwCnZtLnBtYXAucG1hcF9jb2xsZWN0X2luYWN0aXZlOiAwCnZtLnBtYXAucHZfZW50cnlf c3BhcmU6IDI1NTcKdm0ucG1hcC5wdl9lbnRyeV9hbGxvY3M6IDIwODcxOAp2bS5wbWFwLnB2X2Vu dHJ5X2ZyZWVzOiAyMDQ4OTEKdm0ucG1hcC5wY19jaHVua190cnlmYWlsOiAwCnZtLnBtYXAucGNf Y2h1bmtfZnJlZXM6IDE1ODcKdm0ucG1hcC5wY19jaHVua19hbGxvY3M6IDE2MDYKdm0ucG1hcC5w Y19jaHVua19jb3VudDogMTkKdm0ucG1hcC5wdl9lbnRyeV9jb3VudDogMzgyNwp2bS5wbWFwLnNo cGdwZXJwcm9jOiAyMDAKdm0ucG1hcC5wdl9lbnRyeV9tYXg6IDE3NDU1MjAKdmZzLm5mczQuYWNj ZXNzX2NhY2hlX3RpbWVvdXQ6IDYwCnZmcy51ZnMuZGlyaGFzaF9kb2NoZWNrOiAwCnZmcy51ZnMu ZGlyaGFzaF9tZW06IDI0MTMzCnZmcy51ZnMuZGlyaGFzaF9tYXhtZW06IDIwOTcxNTIKdmZzLnVm cy5kaXJoYXNoX21pbnNpemU6IDI1NjAKdmZzLm5mcy5kb3duZGVsYXlpbml0aWFsOiAxMgp2ZnMu bmZzLmRvd25kZWxheWludGVydmFsOiAzMAp2ZnMubmZzLnNraXBfd2NjX2RhdGFfb25lcnI6IDEK dmZzLm5mcy5uZnMzX2p1a2Vib3hfZGVsYXk6IDEwCnZmcy5uZnMucmVjb25uZWN0czogMAp2ZnMu bmZzLmJ1ZnBhY2tldHM6IDQKdmZzLm5mcy5yZWFsaWduX2NvdW50OiAwCnZmcy5uZnMucmVhbGln bl90ZXN0OiAwCnZmcy5uZnMuZGVmZWN0OiAwCnZmcy5uZnMuaW9kbWF4OiAyMAp2ZnMubmZzLmlv ZG1pbjogMAp2ZnMubmZzLmlvZG1heGlkbGU6IDEyMAp2ZnMubmZzLmRpc2tsZXNzX3Jvb3RwYXRo OiAKdmZzLm5mcy5kaXNrbGVzc192YWxpZDogMAp2ZnMubmZzLm5mc19pcF9wYXJhbm9pYTogMQp2 ZnMubmZzLm5mc19kaXJlY3Rpb19hbGxvd19tbWFwOiAxCnZmcy5uZnMubmZzX2RpcmVjdGlvX2Vu YWJsZTogMAp2ZnMubmZzLmNsZWFuX3BhZ2VzX29uX2Nsb3NlOiAxCnZmcy5uZnMubmZzdjNfY29t bWl0X29uX2Nsb3NlOiAwCnZmcy5uZnMuYWNjZXNzX2NhY2hlX3RpbWVvdXQ6IDYwCnZmcy5kZXZm cy5ydWxlX2RlcHRoOiAxCnZmcy5kZXZmcy5nZW5lcmF0aW9uOiAxMTMKdmZzLnBmcy50cmFjZTog MAp2ZnMucGZzLnZuY2FjaGUubWlzc2VzOiAwCnZmcy5wZnMudm5jYWNoZS5oaXRzOiAwCnZmcy5w ZnMudm5jYWNoZS5tYXhlbnRyaWVzOiAwCnZmcy5wZnMudm5jYWNoZS5lbnRyaWVzOiAwCnZmcy5m bHVzaHdpdGhkZXBzOiAwCnZmcy5nZXRuZXdidWZyZXN0YXJ0czogMAp2ZnMuZ2V0bmV3YnVmY2Fs bHM6IDU3Ngp2ZnMuaGlmcmVlYnVmZmVyczogODA4CnZmcy5sb2ZyZWVidWZmZXJzOiA0MDQKdmZz Lm51bWZyZWVidWZmZXJzOiA3MTg2CnZmcy5kaXJ0eWJ1ZnRocmVzaDogMTYzNwp2ZnMuaGlkaXJ0 eWJ1ZmZlcnM6IDE4MTkKdmZzLmxvZGlydHlidWZmZXJzOiA5MDkKdmZzLm51bWRpcnR5YnVmZmVy czogMTIKdmZzLnJlY3Vyc2l2ZWZsdXNoZXM6IDAKdmZzLmFsdGJ1ZmZlcmZsdXNoZXM6IDAKdmZz LmJkd3JpdGVza2lwOiAwCnZmcy5kaXJ0eWJ1ZmZlcmZsdXNoZXM6IDAKdmZzLmhpcnVubmluZ3Nw YWNlOiAxMDQ4NTc2CnZmcy5sb3J1bm5pbmdzcGFjZTogNTI0Mjg4CnZmcy5idWZkZWZyYWdjbnQ6 IDAKdmZzLmJ1ZmZyZWVrdmFjbnQ6IDAKdmZzLmJ1ZnJldXNlY250OiA0OTcKdmZzLmhpYnVmc3Bh Y2U6IDExNzI3NjY3Mgp2ZnMubG9idWZzcGFjZTogMTE3MjExMTM2CnZmcy5tYXhtYWxsb2NidWZz cGFjZTogNTg2MzgzMwp2ZnMuYnVmbWFsbG9jc3BhY2U6IDcxNjgwCnZmcy5tYXhidWZzcGFjZTog MTE3OTMyMDMyCnZmcy5idWZzcGFjZTogODE0Mjg0OAp2ZnMucnVubmluZ2J1ZnNwYWNlOiAwCnZm cy52bWlvZGlyZW5hYmxlOiAxCnZmcy5jYWNoZS5udW1mdWxscGF0aGZvdW5kOiAzOQp2ZnMuY2Fj aGUubnVtZnVsbHBhdGhmYWlsNDogMAp2ZnMuY2FjaGUubnVtZnVsbHBhdGhmYWlsMjogMAp2ZnMu Y2FjaGUubnVtZnVsbHBhdGhmYWlsMTogMAp2ZnMuY2FjaGUubnVtZnVsbHBhdGhjYWxsczogMzkK dmZzLmNhY2hlLm5jaHN0YXRzOiA3ODE1IDgzNCA0OSAwIDgwNSAwIDE1IDEwMgp2ZnMuY2FjaGUu bnVtbmVnaGl0czogODM0CnZmcy5jYWNoZS5udW1uZWd6YXBzOiAyMAp2ZnMuY2FjaGUubnVtcG9z aGl0czogNzgxNQp2ZnMuY2FjaGUubnVtcG9zemFwczogMjkKdmZzLmNhY2hlLm51bW1pc3N6YXA6 IDE5CnZmcy5jYWNoZS5udW1taXNzOiA3ODYKdmZzLmNhY2hlLm51bWNoZWNrczogODcwMAp2ZnMu Y2FjaGUuZG90ZG90aGl0czogMTMKdmZzLmNhY2hlLmRvdGhpdHM6IDYyCnZmcy5jYWNoZS5udW1j YWxsczogOTU3OAp2ZnMuY2FjaGUubnVtY2FjaGU6IDM3Nwp2ZnMuY2FjaGUubnVtbmVnOiAyMwp2 ZnMucmVhZF9tYXg6IDgKdmZzLndyaXRlX2JlaGluZDogMQp2ZnMubG9va3VwX3NoYXJlZDogMAp2 ZnMudXNlcm1vdW50OiAwCnZmcy53b3JrbGlzdF9sZW46IDYKdmZzLnRpbWVzdGFtcF9wcmVjaXNp b246IDAKdmZzLnJlYXNzaWduYnVmY2FsbHM6IDM5Mgp2ZnMuZnJlZXZub2RlczogMTYKdmZzLndh bnRmcmVldm5vZGVzOiAyNTAwMAp2ZnMubnVtdm5vZGVzOiA0MTEKdmZzLmZmcy5kb3JlYWxsb2Ni bGtzOiAxCnZmcy5mZnMuZG9hc3luY2ZyZWU6IDEKdmZzLmZmcy5jb21wdXRlX3N1bW1hcnlfYXRf bW91bnQ6IDAKbmV0LmxvY2FsLnN0cmVhbS5yZWN2c3BhY2U6IDgxOTIKbmV0LmxvY2FsLnN0cmVh bS5zZW5kc3BhY2U6IDgxOTIKbmV0LmxvY2FsLmRncmFtLnJlY3ZzcGFjZTogNDA5NgpuZXQubG9j YWwuZGdyYW0ubWF4ZGdyYW06IDIwNDgKbmV0LmxvY2FsLnJlY3ljbGVkOiAwCm5ldC5sb2NhbC50 YXNrY291bnQ6IDAKbmV0LmxvY2FsLmluZmxpZ2h0OiAwCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5y YW5kb210aW1lOiA0NQpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmFuZG9tY3BzOiAxMApuZXQuaW5l dC5pcC5wb3J0cmFuZ2UucmFuZG9taXplZDogMQpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmVzZXJ2 ZWRsb3c6IDAKbmV0LmluZXQuaXAucG9ydHJhbmdlLnJlc2VydmVkaGlnaDogMTAyMwpuZXQuaW5l dC5pcC5wb3J0cmFuZ2UuaGlsYXN0OiA2NTUzNQpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UuaGlmaXJz dDogNDkxNTIKbmV0LmluZXQuaXAucG9ydHJhbmdlLmxhc3Q6IDY1NTM1Cm5ldC5pbmV0LmlwLnBv cnRyYW5nZS5maXJzdDogNDkxNTIKbmV0LmluZXQuaXAucG9ydHJhbmdlLmxvd2xhc3Q6IDYwMApu ZXQuaW5ldC5pcC5wb3J0cmFuZ2UubG93Zmlyc3Q6IDEwMjMKbmV0LmluZXQuaXAuZm9yd2FyZGlu ZzogMApuZXQuaW5ldC5pcC5yZWRpcmVjdDogMQpuZXQuaW5ldC5pcC50dGw6IDY0Cm5ldC5pbmV0 LmlwLnJ0ZXhwaXJlOiAzNjAwCm5ldC5pbmV0LmlwLnJ0bWluZXhwaXJlOiAxMApuZXQuaW5ldC5p cC5ydG1heGNhY2hlOiAxMjgKbmV0LmluZXQuaXAuc291cmNlcm91dGU6IDAKbmV0LmluZXQuaXAu aW50cl9xdWV1ZV9tYXhsZW46IDUwCm5ldC5pbmV0LmlwLmludHJfcXVldWVfZHJvcHM6IDAKbmV0 LmluZXQuaXAuYWNjZXB0X3NvdXJjZXJvdXRlOiAwCm5ldC5pbmV0LmlwLmtlZXBmYWl0aDogMApu ZXQuaW5ldC5pcC5zYW1lX3ByZWZpeF9jYXJwX29ubHk6IDAKbmV0LmluZXQuaXAuc3VibmV0c19h cmVfbG9jYWw6IDAKbmV0LmluZXQuaXAuZmFzdGZvcndhcmRpbmc6IDAKbmV0LmluZXQuaXAubWF4 ZnJhZ3BhY2tldHM6IDgwMApuZXQuaW5ldC5pcC5tYXhmcmFnc3BlcnBhY2tldDogMTYKbmV0Lmlu ZXQuaXAuZnJhZ3BhY2tldHM6IDAKbmV0LmluZXQuaXAuY2hlY2tfaW50ZXJmYWNlOiAwCm5ldC5p bmV0LmlwLnJhbmRvbV9pZDogMQpuZXQuaW5ldC5pcC5zZW5kc291cmNlcXVlbmNoOiAwCm5ldC5p bmV0LmlwLnByb2Nlc3Nfb3B0aW9uczogMQpuZXQuaW5ldC5pY21wLm1hc2tyZXBsOiAwCm5ldC5p bmV0LmljbXAuaWNtcGxpbTogMjAwCm5ldC5pbmV0LmljbXAuYm1jYXN0ZWNobzogMApuZXQuaW5l dC5pY21wLnF1b3RlbGVuOiA4Cm5ldC5pbmV0LmljbXAucmVwbHlfZnJvbV9pbnRlcmZhY2U6IDAK bmV0LmluZXQuaWNtcC5yZXBseV9zcmM6IApuZXQuaW5ldC5pY21wLmljbXBsaW1fb3V0cHV0OiAx Cm5ldC5pbmV0LmljbXAubG9nX3JlZGlyZWN0OiAxCm5ldC5pbmV0LmljbXAuZHJvcF9yZWRpcmVj dDogMQpuZXQuaW5ldC5pY21wLm1hc2tmYWtlOiAwCm5ldC5pbmV0LmlwaXAuaXBpcF9hbGxvdzog MApuZXQuaW5ldC50Y3AucmZjMTMyMzogMQpuZXQuaW5ldC50Y3AubXNzZGZsdDogNTEyCm5ldC5p bmV0LnRjcC5rZWVwaWRsZTogNzIwMDAwMApuZXQuaW5ldC50Y3Aua2VlcGludHZsOiA3NTAwMApu ZXQuaW5ldC50Y3Auc2VuZHNwYWNlOiAzMjc2OApuZXQuaW5ldC50Y3AucmVjdnNwYWNlOiA2NTUz NgpuZXQuaW5ldC50Y3Aua2VlcGluaXQ6IDc1MDAwCm5ldC5pbmV0LnRjcC5kZWxhY2t0aW1lOiAx MDAKbmV0LmluZXQudGNwLnY2bXNzZGZsdDogMTAyNApuZXQuaW5ldC50Y3AuaG9zdGNhY2hlLnB1 cmdlOiAwCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUucHJ1bmU6IDMwMApuZXQuaW5ldC50Y3AuaG9z dGNhY2hlLmV4cGlyZTogMzYwMApuZXQuaW5ldC50Y3AuaG9zdGNhY2hlLmNvdW50OiAwCm5ldC5p bmV0LnRjcC5ob3N0Y2FjaGUuYnVja2V0bGltaXQ6IDMwCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUu aGFzaHNpemU6IDUxMgpuZXQuaW5ldC50Y3AuaG9zdGNhY2hlLmNhY2hlbGltaXQ6IDE1MzYwCm5l dC5pbmV0LnRjcC5yZWN2YnVmX21heDogMjYyMTQ0Cm5ldC5pbmV0LnRjcC5yZWN2YnVmX2luYzog MTYzODQKbmV0LmluZXQudGNwLnJlY3ZidWZfYXV0bzogMQpuZXQuaW5ldC50Y3AuaW5zZWN1cmVf cnN0OiAwCm5ldC5pbmV0LnRjcC5yZmMzMzkwOiAxCm5ldC5pbmV0LnRjcC5yZmMzMDQyOiAxCm5l dC5pbmV0LnRjcC5kcm9wX3N5bmZpbjogMQpuZXQuaW5ldC50Y3AuZGVsYXllZF9hY2s6IDEKbmV0 LmluZXQudGNwLmJsYWNraG9sZTogMApuZXQuaW5ldC50Y3AubG9nX2luX3ZhaW46IDEKbmV0Lmlu ZXQudGNwLnNlbmRidWZfbWF4OiAyNjIxNDQKbmV0LmluZXQudGNwLnNlbmRidWZfaW5jOiA4MTky Cm5ldC5pbmV0LnRjcC5zZW5kYnVmX2F1dG86IDEKbmV0LmluZXQudGNwLnRzbzogMQpuZXQuaW5l dC50Y3AubmV3cmVubzogMQpuZXQuaW5ldC50Y3AubG9jYWxfc2xvd3N0YXJ0X2ZsaWdodHNpemU6 IDQKbmV0LmluZXQudGNwLnNsb3dzdGFydF9mbGlnaHRzaXplOiAxCm5ldC5pbmV0LnRjcC5wYXRo X210dV9kaXNjb3Zlcnk6IDEKbmV0LmluZXQudGNwLnJlYXNzLm92ZXJmbG93czogMApuZXQuaW5l dC50Y3AucmVhc3MubWF4cWxlbjogNDgKbmV0LmluZXQudGNwLnJlYXNzLmN1cnNlZ21lbnRzOiAw Cm5ldC5pbmV0LnRjcC5yZWFzcy5tYXhzZWdtZW50czogMTYwMApuZXQuaW5ldC50Y3Auc2Fjay5n bG9iYWxob2xlczogMApuZXQuaW5ldC50Y3Auc2Fjay5nbG9iYWxtYXhob2xlczogNjU1MzYKbmV0 LmluZXQudGNwLnNhY2subWF4aG9sZXM6IDEyOApuZXQuaW5ldC50Y3Auc2Fjay5lbmFibGU6IDEK bmV0LmluZXQudGNwLmluZmxpZ2h0LnN0YWI6IDIwCm5ldC5pbmV0LnRjcC5pbmZsaWdodC5tYXg6 IDEwNzM3MjU0NDAKbmV0LmluZXQudGNwLmluZmxpZ2h0Lm1pbjogNjE0NApuZXQuaW5ldC50Y3Au aW5mbGlnaHQucnR0dGhyZXNoOiAxMApuZXQuaW5ldC50Y3AuaW5mbGlnaHQuZGVidWc6IDAKbmV0 LmluZXQudGNwLmluZmxpZ2h0LmVuYWJsZTogMQpuZXQuaW5ldC50Y3AuaXNuX3Jlc2VlZF9pbnRl cnZhbDogMApuZXQuaW5ldC50Y3AuaWNtcF9tYXlfcnN0OiAxCm5ldC5pbmV0LnRjcC5wY2Jjb3Vu dDogMApuZXQuaW5ldC50Y3AuZG9fdGNwZHJhaW46IDEKbmV0LmluZXQudGNwLnRjYmhhc2hzaXpl OiA1MTIKbmV0LmluZXQudGNwLmxvZ19kZWJ1ZzogMApuZXQuaW5ldC50Y3AubWlubXNzOiAyMTYK bmV0LmluZXQudGNwLnN5bmNhY2hlLnJzdF9vbl9zb2NrX2ZhaWw6IDEKbmV0LmluZXQudGNwLnN5 bmNhY2hlLnJleG10bGltaXQ6IDMKbmV0LmluZXQudGNwLnN5bmNhY2hlLmhhc2hzaXplOiA1MTIK bmV0LmluZXQudGNwLnN5bmNhY2hlLmNvdW50OiAwCm5ldC5pbmV0LnRjcC5zeW5jYWNoZS5jYWNo ZWxpbWl0OiAxNTM2MApuZXQuaW5ldC50Y3Auc3luY2FjaGUuYnVja2V0bGltaXQ6IDMwCm5ldC5p bmV0LnRjcC5zeW5jb29raWVzX29ubHk6IDAKbmV0LmluZXQudGNwLnN5bmNvb2tpZXM6IDEKbmV0 LmluZXQudGNwLnRpbWVyX3JhY2U6IDAKbmV0LmluZXQudGNwLmZpbndhaXQyX3RpbWVvdXQ6IDYw MDAwCm5ldC5pbmV0LnRjcC5mYXN0X2ZpbndhaXQyX3JlY3ljbGU6IDAKbmV0LmluZXQudGNwLmFs d2F5c19rZWVwYWxpdmU6IDEKbmV0LmluZXQudGNwLnJleG1pdF9zbG9wOiAyMDAKbmV0LmluZXQu dGNwLnJleG1pdF9taW46IDMwCm5ldC5pbmV0LnRjcC5tc2w6IDMwMDAwCm5ldC5pbmV0LnRjcC5u b2xvY2FsdGltZXdhaXQ6IDAKbmV0LmluZXQudGNwLm1heHRjcHR3OiAyNDY1Cm5ldC5pbmV0LnVk cC5jaGVja3N1bTogMQpuZXQuaW5ldC51ZHAubWF4ZGdyYW06IDkyMTYKbmV0LmluZXQudWRwLnJl Y3ZzcGFjZTogNDIwODAKbmV0LmluZXQudWRwLmJsYWNraG9sZTogMApuZXQuaW5ldC51ZHAubG9n X2luX3ZhaW46IDEKbmV0LmluZXQuZXNwLmVzcF9lbmFibGU6IDEKbmV0LmluZXQuYWguYWhfY2xl YXJ0b3M6IDEKbmV0LmluZXQuYWguYWhfZW5hYmxlOiAxCm5ldC5pbmV0LmlwY29tcC5pcGNvbXBf ZW5hYmxlOiAwCm5ldC5pbmV0Lmlwc2VjLmRlZl9wb2xpY3k6IDEKbmV0LmluZXQuaXBzZWMuZXNw X3RyYW5zX2RlZmxldjogMQpuZXQuaW5ldC5pcHNlYy5lc3BfbmV0X2RlZmxldjogMQpuZXQuaW5l dC5pcHNlYy5haF90cmFuc19kZWZsZXY6IDEKbmV0LmluZXQuaXBzZWMuYWhfbmV0X2RlZmxldjog MQpuZXQuaW5ldC5pcHNlYy5haF9jbGVhcnRvczogMQpuZXQuaW5ldC5pcHNlYy5haF9vZmZzZXRt YXNrOiAwCm5ldC5pbmV0Lmlwc2VjLmRmYml0OiAwCm5ldC5pbmV0Lmlwc2VjLmVjbjogMApuZXQu aW5ldC5pcHNlYy5kZWJ1ZzogMApuZXQuaW5ldC5pcHNlYy5lc3BfcmFuZHBhZDogLTEKbmV0Lmlu ZXQuaXBzZWMuY3J5cHRvX3N1cHBvcnQ6IDUwMzMxNjQ4Cm5ldC5pbmV0LnJhdy5yZWN2c3BhY2U6 IDkyMTYKbmV0LmluZXQucmF3Lm1heGRncmFtOiA5MjE2Cm5ldC5pbmV0LmFjY2YudW5sb2FkYWJs ZTogMApuZXQubGluay5nZW5lcmljLnN5c3RlbS5pZmNvdW50OiA1Cm5ldC5saW5rLmV0aGVyLmlu ZXQubG9nX2FycF9wZXJtYW5lbnRfbW9kaWZ5OiAxCm5ldC5saW5rLmV0aGVyLmluZXQubG9nX2Fy cF9tb3ZlbWVudHM6IDEKbmV0LmxpbmsuZXRoZXIuaW5ldC5sb2dfYXJwX3dyb25nX2lmYWNlOiAx Cm5ldC5saW5rLmV0aGVyLmluZXQucHJveHlhbGw6IDAKbmV0LmxpbmsuZXRoZXIuaW5ldC51c2Vs b29wYmFjazogMQpuZXQubGluay5ldGhlci5pbmV0Lm1heHRyaWVzOiA1Cm5ldC5saW5rLmV0aGVy LmluZXQubWF4X2FnZTogMTIwMApuZXQubGluay5ldGhlci5pcGZ3OiAwCm5ldC5saW5rLmdyZS5t YXhfbmVzdGluZzogMQpuZXQubGluay52bGFuLnNvZnRfcGFkOiAwCm5ldC5saW5rLmJyaWRnZS5p cGZ3OiAwCm5ldC5saW5rLmJyaWRnZS5sb2dfc3RwOiAwCm5ldC5saW5rLmJyaWRnZS5wZmlsX2xv Y2FsX3BoeXM6IDAKbmV0LmxpbmsuYnJpZGdlLnBmaWxfbWVtYmVyOiAxCm5ldC5saW5rLmJyaWRn ZS5wZmlsX2JyaWRnZTogMQpuZXQubGluay5icmlkZ2UuaXBmd19hcnA6IDAKbmV0LmxpbmsuYnJp ZGdlLnBmaWxfb25seWlwOiAxCm5ldC5saW5rLmxvZ19saW5rX3N0YXRlX2NoYW5nZTogMQpuZXQu bGluay50dW4uZGV2ZnNfY2xvbmluZzogMQpuZXQua2V5LmRlYnVnOiAwCm5ldC5rZXkuc3BpX3Ry eWNudDogMTAwMApuZXQua2V5LnNwaV9taW52YWw6IDI1NgpuZXQua2V5LnNwaV9tYXh2YWw6IDI2 ODQzNTQ1NQpuZXQua2V5LmludF9yYW5kb206IDYwCm5ldC5rZXkubGFydmFsX2xpZmV0aW1lOiAz MApuZXQua2V5LmJsb2NrYWNxX2NvdW50OiAxMApuZXQua2V5LmJsb2NrYWNxX2xpZmV0aW1lOiAy MApuZXQua2V5LmVzcF9rZXltaW46IDI1NgpuZXQua2V5LmVzcF9hdXRoOiAwCm5ldC5rZXkuYWhf a2V5bWluOiAxMjgKbmV0LmtleS5wcmVmZXJyZWRfb2xkc2E6IDEKbmV0LmluZXQ2LmlwNi5mb3J3 YXJkaW5nOiAwCm5ldC5pbmV0Ni5pcDYucmVkaXJlY3Q6IDEKbmV0LmluZXQ2LmlwNi5obGltOiA2 NApuZXQuaW5ldDYuaXA2Lm1heGZyYWdwYWNrZXRzOiA2NDAwCm5ldC5pbmV0Ni5pcDYuYWNjZXB0 X3J0YWR2OiAwCm5ldC5pbmV0Ni5pcDYua2VlcGZhaXRoOiAwCm5ldC5pbmV0Ni5pcDYubG9nX2lu dGVydmFsOiA1Cm5ldC5pbmV0Ni5pcDYuaGRybmVzdGxpbWl0OiAxNQpuZXQuaW5ldDYuaXA2LmRh ZF9jb3VudDogMQpuZXQuaW5ldDYuaXA2LmF1dG9fZmxvd2xhYmVsOiAxCm5ldC5pbmV0Ni5pcDYu ZGVmbWNhc3RobGltOiAxCm5ldC5pbmV0Ni5pcDYuZ2lmaGxpbTogMApuZXQuaW5ldDYuaXA2Lmth bWVfdmVyc2lvbjogRnJlZUJTRApuZXQuaW5ldDYuaXA2LnVzZV9kZXByZWNhdGVkOiAxCm5ldC5p bmV0Ni5pcDYucnJfcHJ1bmU6IDUKbmV0LmluZXQ2LmlwNi52Nm9ubHk6IDEKbmV0LmluZXQ2Lmlw Ni5ydGV4cGlyZTogMzYwMApuZXQuaW5ldDYuaXA2LnJ0bWluZXhwaXJlOiAxMApuZXQuaW5ldDYu aXA2LnJ0bWF4Y2FjaGU6IDEyOApuZXQuaW5ldDYuaXA2LnVzZV90ZW1wYWRkcjogMApuZXQuaW5l dDYuaXA2LnRlbXBwbHRpbWU6IDg2NDAwCm5ldC5pbmV0Ni5pcDYudGVtcHZsdGltZTogNjA0ODAw Cm5ldC5pbmV0Ni5pcDYuYXV0b19saW5rbG9jYWw6IDAKbmV0LmluZXQ2LmlwNi5wcmVmZXJfdGVt cGFkZHI6IDAKbmV0LmluZXQ2LmlwNi51c2VfZGVmYXVsdHpvbmU6IDAKbmV0LmluZXQ2LmlwNi5t YXhmcmFnczogNjQwMApuZXQuaW5ldDYuaXA2Lm1jYXN0X3BtdHU6IDAKbmV0LmluZXQ2Lmlwc2Vj Ni5kZWZfcG9saWN5OiAxCm5ldC5pbmV0Ni5pcHNlYzYuZXNwX3RyYW5zX2RlZmxldjogMQpuZXQu aW5ldDYuaXBzZWM2LmVzcF9uZXRfZGVmbGV2OiAxCm5ldC5pbmV0Ni5pcHNlYzYuYWhfdHJhbnNf ZGVmbGV2OiAxCm5ldC5pbmV0Ni5pcHNlYzYuYWhfbmV0X2RlZmxldjogMQpuZXQuaW5ldDYuaXBz ZWM2LmVjbjogMApuZXQuaW5ldDYuaXBzZWM2LmRlYnVnOiAwCm5ldC5pbmV0Ni5pcHNlYzYuZXNw X3JhbmRwYWQ6IC0xCm5ldC5pbmV0Ni5pY21wNi5yZWRpcmFjY2VwdDogMQpuZXQuaW5ldDYuaWNt cDYucmVkaXJ0aW1lb3V0OiA2MDAKbmV0LmluZXQ2LmljbXA2Lm5kNl9wcnVuZTogMQpuZXQuaW5l dDYuaWNtcDYubmQ2X2RlbGF5OiA1Cm5ldC5pbmV0Ni5pY21wNi5uZDZfdW1heHRyaWVzOiAzCm5l dC5pbmV0Ni5pY21wNi5uZDZfbW1heHRyaWVzOiAzCm5ldC5pbmV0Ni5pY21wNi5uZDZfdXNlbG9v cGJhY2s6IDEKbmV0LmluZXQ2LmljbXA2Lm5vZGVpbmZvOiAzCm5ldC5pbmV0Ni5pY21wNi5lcnJw cHNsaW1pdDogMTAwCm5ldC5pbmV0Ni5pY21wNi5uZDZfbWF4bnVkaGludDogMApuZXQuaW5ldDYu aWNtcDYubmQ2X2RlYnVnOiAwCm5ldC5pbmV0Ni5pY21wNi5uZDZfbWF4cXVldWVsZW46IDEKbmV0 LmJwZi5tYXhpbnNuczogNTEyCm5ldC5icGYubWF4YnVmc2l6ZTogNTI0Mjg4Cm5ldC5icGYuYnVm c2l6ZTogNDA5NgpuZXQuaXNyLnN3aV9jb3VudDogOApuZXQuaXNyLmRyb3A6IDAKbmV0Lmlzci5x dWV1ZWQ6IDgKbmV0Lmlzci5kZWZlcnJlZDogMApuZXQuaXNyLmRpcmVjdGVkOiA0Cm5ldC5pc3Iu Y291bnQ6IDQKbmV0Lmlzci5kaXJlY3Q6IDEKbmV0LnJvdXRlLm5ldGlzcl9tYXhxbGVuOiAyNTYK bmV0LndsYW4ucmVjdl9iYXI6IDEKbmV0LndsYW4uZGVidWc6IDAKbmV0LndsYW4uMC4lcGFyZW50 OiBhdGgwCm5ldC53bGFuLjAuZGVidWc6IDAKbmV0LndsYW4uMC5pbmFjdF9ydW46IDMwMApuZXQu d2xhbi4wLmluYWN0X3Byb2JlOiAzMApuZXQud2xhbi4wLmluYWN0X2F1dGg6IDE4MApuZXQud2xh bi4wLmluYWN0X2luaXQ6IDMwCm5ldC53bGFuLjAuZHJpdmVyX2NhcHM6IDE3MzY2OTkyMTUKbmV0 LndsYW4uMC5ibWlzc19tYXg6IDIKbmV0LmJsdWV0b290aC5yZmNvbW0uc29ja2V0cy5zdHJlYW0u dGltZW91dDogNjAKbmV0LmJsdWV0b290aC5yZmNvbW0uc29ja2V0cy5zdHJlYW0uZGVidWdfbGV2 ZWw6IDMKbmV0LmJsdWV0b290aC5sMmNhcC5lcnR4X3RpbWVvdXQ6IDMwMApuZXQuYmx1ZXRvb3Ro LmwyY2FwLnJ0eF90aW1lb3V0OiA2MApuZXQuYmx1ZXRvb3RoLmwyY2FwLnNvY2tldHMuc2VxLnF1 ZXVlX2Ryb3BzOiAwCm5ldC5ibHVldG9vdGgubDJjYXAuc29ja2V0cy5zZXEucXVldWVfbWF4bGVu OiA1MApuZXQuYmx1ZXRvb3RoLmwyY2FwLnNvY2tldHMuc2VxLnF1ZXVlX2xlbjogMApuZXQuYmx1 ZXRvb3RoLmwyY2FwLnNvY2tldHMuc2VxLmRlYnVnX2xldmVsOiAzCm5ldC5ibHVldG9vdGgubDJj YXAuc29ja2V0cy5yYXcucXVldWVfZHJvcHM6IDAKbmV0LmJsdWV0b290aC5sMmNhcC5zb2NrZXRz LnJhdy5xdWV1ZV9tYXhsZW46IDUwCm5ldC5ibHVldG9vdGgubDJjYXAuc29ja2V0cy5yYXcucXVl dWVfbGVuOiAwCm5ldC5ibHVldG9vdGgubDJjYXAuc29ja2V0cy5yYXcuaW9jdGxfdGltZW91dDog NQpuZXQuYmx1ZXRvb3RoLmwyY2FwLnNvY2tldHMucmF3LmRlYnVnX2xldmVsOiAzCm5ldC5ibHVl dG9vdGguaGNpLm1heF9uZWlnaGJvcl9hZ2U6IDYwMApuZXQuYmx1ZXRvb3RoLmhjaS5jb25uZWN0 aW9uX3RpbWVvdXQ6IDYwCm5ldC5ibHVldG9vdGguaGNpLmNvbW1hbmRfdGltZW91dDogNQpuZXQu Ymx1ZXRvb3RoLmhjaS5zb2NrZXRzLnJhdy5xdWV1ZV9kcm9wczogMApuZXQuYmx1ZXRvb3RoLmhj aS5zb2NrZXRzLnJhdy5xdWV1ZV9tYXhsZW46IDUwCm5ldC5ibHVldG9vdGguaGNpLnNvY2tldHMu cmF3LnF1ZXVlX2xlbjogMApuZXQuYmx1ZXRvb3RoLmhjaS5zb2NrZXRzLnJhdy5pb2N0bF90aW1l b3V0OiA1Cm5ldC5ibHVldG9vdGguaGNpLnNvY2tldHMucmF3LmRlYnVnX2xldmVsOiAzCm5ldC5i bHVldG9vdGgudmVyc2lvbjogMQpuZXQuZ3JhcGgubXNnX3ZlcnNpb246IDgKbmV0LmdyYXBoLmFi aV92ZXJzaW9uOiAxMQpuZXQuZ3JhcGgubWF4ZGF0YTogNTEyCm5ldC5ncmFwaC5tYXhhbGxvYzog NDA5NgpkZWJ1Zy5wZnVnaWRoYWNrOiAwCmRlYnVnLmFjcGkuc2VtYXBob3JlX2RlYnVnOiAwCmRl YnVnLmFjcGkuc3VzcGVuZF9ib3VuY2U6IDAKZGVidWcuYWNwaS5kb19wb3dlcnN0YXRlOiAxCmRl YnVnLmFjcGkuYWNwaV9jYV92ZXJzaW9uOiAyMDA3MDMyMApkZWJ1Zy5hY3BpLmVjLnRpbWVvdXQ6 IDc1MApkZWJ1Zy5hY3BpLmVjLnBvbGxlZDogMApkZWJ1Zy5hY3BpLmVjLmJ1cnN0OiAwCmRlYnVn LmFjcGkucmVzdW1lX2JlZXA6IDAKZGVidWcuZmlyZXdpcmVfZGVidWc6IDAKZGVidWcuZndtZW1f ZGVidWc6IDAKZGVidWcuaWZfZndpcF9kZWJ1ZzogMApkZWJ1Zy5zYnBfZGVidWc6IDAKZGVidWcu c2JwX3RhcmdfZGVidWc6IDAKZGVidWcubWRkZWJ1ZzogMApkZWJ1Zy5nYmRlX25jYWNoZTogMApk ZWJ1Zy5nYmRlX25zZWN0OiAwCmRlYnVnLmdiZGVfbndvcms6IDAKZGVidWcuZWxmMzJfbGVnYWN5 X2NvcmVkdW1wOiAwCmRlYnVnLmVsZjMyX3RyYWNlOiAwCmRlYnVnLmJvb3R2ZXJib3NlOiAxCmRl YnVnLmJvb3Rob3d0bzogLTIxNDc0ODE2MDAKZGVidWcuY3B1ZnJlcS52ZXJib3NlOiAwCmRlYnVn LmNwdWZyZXEubG93ZXN0OiAwCmRlYnVnLnNpemVvZi5jZGV2X3ByaXY6IDIzMgpkZWJ1Zy5zaXpl b2YuY2RldjogMTg0CmRlYnVnLnNpemVvZi5nX2Jpb3E6IDM2CmRlYnVnLnNpemVvZi5nX2NvbnN1 bWVyOiA2MApkZWJ1Zy5zaXplb2YuZ19wcm92aWRlcjogODgKZGVidWcuc2l6ZW9mLmdfZ2VvbTog NjgKZGVidWcuc2l6ZW9mLmdfY2xhc3M6IDY4CmRlYnVnLnNpemVvZi5raW5mb19wcm9jOiA3NjgK ZGVidWcuc2l6ZW9mLmJ1ZjogMzU2CmRlYnVnLnNpemVvZi5iaW86IDEzMgpkZWJ1Zy5zaXplb2Yu cHJvYzogNjg0CmRlYnVnLnNpemVvZi52bm9kZTogMjcyCmRlYnVnLnNpemVvZi5kZXZzdGF0OiAy NDAKZGVidWcuc2l6ZW9mLm5hbWVjYWNoZTogMzYKZGVidWcudG9fYXZnX21wY2FsbHM6IDk5MApk ZWJ1Zy50b19hdmdfbXR4Y2FsbHM6IDAKZGVidWcudG9fYXZnX2djYWxsczogMjU1CmRlYnVnLnRv X2F2Z19kZXB0aDogMTI1OApkZWJ1Zy51bXR4LnVtdHhfcGlfYWxsb2NhdGVkOiAwCmRlYnVnLmtk Yi5zdG9wX2NwdXM6IDEKZGVidWcua2RiLnRyYXBfY29kZTogMApkZWJ1Zy5rZGIudHJhcDogMApk ZWJ1Zy5rZGIucGFuaWM6IDAKZGVidWcua2RiLmVudGVyOiAwCmRlYnVnLmtkYi5jdXJyZW50OiAK ZGVidWcua2RiLmF2YWlsYWJsZTogCmRlYnVnLnJtYW5fZGVidWc6IDAKZGVidWcuZGlzYWJsZWZ1 bGxwYXRoOiAwCmRlYnVnLmRpc2FibGVjd2Q6IDAKZGVidWcuaGFzaHN0YXQubmNoYXNoOiAxMzEw NzIgMzc2IDIgMjgKZGVidWcudmZzY2FjaGU6IDEKZGVidWcubnVtY2FjaGVodjogMzMKZGVidWcu bnVtY2FjaGU6IDM3NwpkZWJ1Zy5udW1uZWc6IDIzCmRlYnVnLm5jbmVnZmFjdG9yOiAxNgpkZWJ1 Zy5uY2hhc2g6IDEzMTA3MQpkZWJ1Zy52bmxydV9ub3doZXJlOiAwCmRlYnVnLnJ1c2hfcmVxdWVz dHM6IDAKZGVidWcubXBzYWZldmZzOiAxCmRlYnVnLmlmX3R1bl9kZWJ1ZzogMApkZWJ1Zy5jcnlw dG9fdGltaW5nOiAwCmRlYnVnLmNvbGxlY3RzbmFwc3RhdHM6IDAKZGVidWcuc25hcGRlYnVnOiAw CmRlYnVnLmRvcGVyc2lzdGVuY2U6IDAKZGVidWcuZGlyX2VudHJ5OiAwCmRlYnVnLmRpcmVjdF9i bGtfcHRyczogMApkZWJ1Zy5pbm9kZV9iaXRtYXA6IDAKZGVidWcuaW5kaXJfYmxrX3B0cnM6IDAK ZGVidWcuc3luY19saW1pdF9oaXQ6IDAKZGVidWcuaW5vX2xpbWl0X2hpdDogMApkZWJ1Zy5ibGtf bGltaXRfaGl0OiAwCmRlYnVnLmlub19saW1pdF9wdXNoOiAwCmRlYnVnLmJsa19saW1pdF9wdXNo OiAwCmRlYnVnLndvcmtsaXN0X3B1c2g6IDAKZGVidWcubWF4aW5kaXJkZXBzOiA1MApkZWJ1Zy50 aWNrZGVsYXk6IDIKZGVidWcubWF4X3NvZnRkZXBzOiA0MDAwMDAKZGVidWcuZG9ia2dyZHdyaXRl OiAxCmRlYnVnLmJpZ2NnczogMApkZWJ1Zy51ZnNfZXh0YXR0cl9zeW5jOiAwCmRlYnVnLmRpcmNo ZWNrOiAwCmRlYnVnLm5vc2xlZXB3aXRobG9ja3M6IDAKZGVidWcucHNtLnBrdGVycnRocmVzaDog MgpkZWJ1Zy5wc20udXNlY3M6IDUwMDAwMApkZWJ1Zy5wc20uc2VjczogMApkZWJ1Zy5wc20uZXJy dXNlY3M6IDAKZGVidWcucHNtLmVycnNlY3M6IDIKZGVidWcucHNtLmh6OiAyMApkZWJ1Zy5wc20u bG9nbGV2ZWw6IDAKZGVidWcuZmRjLnNldHRsZTogMApkZWJ1Zy5mZGMuc3BlYzI6IDE2CmRlYnVn LmZkYy5zcGVjMTogMTc1CmRlYnVnLmZkYy5yZXRyaWVzOiAxMApkZWJ1Zy5mZGMuZGVidWdmbGFn czogMApkZWJ1Zy5mZGMuZmlmbzogOApkZWJ1Zy5taW5pZHVtcDogMQpkZWJ1Zy5zdG9wX2NwdXNf d2l0aF9ubWk6IDEKZGVidWcuUE1BUDF1bmNoYW5nZWQ6IDE0ODk5MgpkZWJ1Zy5QTUFQMWNoYW5n ZWQ6IDE1MDgKZGVidWcuUE1BUDFjaGFuZ2VkY3B1OiAwCmh3Lm1hY2hpbmU6IGkzODYKaHcubW9k ZWw6IEludGVsKFIpIFBlbnRpdW0oUikgTSBwcm9jZXNzb3IgMi4yNkdIegpody5uY3B1OiAxCmh3 LmJ5dGVvcmRlcjogMTIzNApody5waHlzbWVtOiAyMTM3MjgwNTEyCmh3LnVzZXJtZW06IDIxMTk4 OTI5OTIKaHcucGFnZXNpemU6IDQwOTYKaHcuZmxvYXRpbmdwb2ludDogMQpody5tYWNoaW5lX2Fy Y2g6IGkzODYKaHcucmVhbG1lbTogMjE0NjIzODQ2NApody5hdGEud2M6IDEKaHcuYXRhLmF0YXBp X2RtYTogMQpody5hdGEuYXRhX2RtYTogMQpody5hdGguaGFsLnN3YmFfYmFja29mZjogMApody5h dGguaGFsLnN3X2JydDogMTAKaHcuYXRoLmhhbC5kbWFfYnJ0OiAyCmh3LmF0aC5oYWwudmVyc2lv bjogMC45LjIwLjMKaHcuYXRoLnR4YnVmOiAyMDAKaHcuYXRoLnJ4YnVmOiA0MApody5hdGgucmVn ZG9tYWluOiAwCmh3LmF0aC5jb3VudHJ5Y29kZTogMApody5hdGgueGNoYW5tb2RlOiAxCmh3LmF0 aC5vdXRkb29yOiAxCmh3LmF0aC5jYWxpYnJhdGU6IDMwCmh3LmJnZS5hbGxvd19hc2Y6IDAKaHcu Y2FyZGJ1cy5jaXNfZGVidWc6IDAKaHcuY2FyZGJ1cy5kZWJ1ZzogMApody5maXJld2lyZS5ob2xk X2NvdW50OiAzCmh3LmZpcmV3aXJlLnRyeV9ibXI6IDEKaHcuZmlyZXdpcmUuZndtZW0uc3BlZWQ6 IDIKaHcuZmlyZXdpcmUuZndtZW0uZXVpNjRfbG86IDAKaHcuZmlyZXdpcmUuZndtZW0uZXVpNjRf aGk6IDAKaHcuZmlyZXdpcmUucGh5ZG1hX2VuYWJsZTogMQpody5maXJld2lyZS5ub2N5Y2xlbWFz dGVyOiAwCmh3LmZpcmV3aXJlLmZ3aXAucnhfcXVldWVfbGVuOiAxMjgKaHcuZmlyZXdpcmUuc2Jw LnRhZ3M6IDAKaHcuZmlyZXdpcmUuc2JwLnVzZV9kb29yYmVsbDogMApody5maXJld2lyZS5zYnAu c2Nhbl9kZWxheTogNTAwCmh3LmZpcmV3aXJlLnNicC5sb2dpbl9kZWxheTogMTAwMApody5maXJl d2lyZS5zYnAuZXhjbHVzaXZlX2xvZ2luOiAxCmh3LmZpcmV3aXJlLnNicC5tYXhfc3BlZWQ6IC0x Cmh3LmZpcmV3aXJlLnNicC5hdXRvX2xvZ2luOiAxCmh3LnBjY2FyZC5jaXNfZGVidWc6IDAKaHcu cGNjYXJkLmRlYnVnOiAwCmh3LmNiYi5kZWJ1ZzogMApody5jYmIuc3RhcnRfMzJfaW86IDQwOTYK aHcuY2JiLnN0YXJ0XzE2X2lvOiAyNTYKaHcuY2JiLnN0YXJ0X21lbW9yeTogMjI4MTcwMTM3Ngpo dy5wY2ljLnBkNjcyMl92c2Vuc2U6IDEKaHcucGNpYy5pbnRyX21hc2s6IDU3MDE2Cmh3LnBjaS5o b25vcl9tc2lfYmxhY2tsaXN0OiAxCmh3LnBjaS5lbmFibGVfbXNpeDogMQpody5wY2kuZW5hYmxl X21zaTogMQpody5wY2kuZG9fcG93ZXJfcmVzdW1lOiAxCmh3LnBjaS5kb19wb3dlcl9ub2RyaXZl cjogMApody5wY2kuZW5hYmxlX2lvX21vZGVzOiAxCmh3LnBjaS5ob3N0X21lbV9zdGFydDogMjE0 NzQ4MzY0OApody5wY2kuaXJxX292ZXJyaWRlX21hc2s6IDU3MDgwCmh3LnNuZC5sYXRlbmN5X3By b2ZpbGU6IDEKaHcuc25kLmxhdGVuY3k6IDUKaHcuc25kLnJlcG9ydF9zb2Z0X2Zvcm1hdHM6IDEK aHcuc25kLmNvbXBhdF9saW51eF9tbWFwOiAwCmh3LnNuZC5mZWVkZXJfYnVmZmVyc2l6ZTogMTYz ODQKaHcuc25kLmZlZWRlcl9yYXRlX3JvdW5kOiAyNQpody5zbmQuZmVlZGVyX3JhdGVfbWF4OiAy MDE2MDAwCmh3LnNuZC5mZWVkZXJfcmF0ZV9taW46IDEKaHcuc25kLnZlcmJvc2U6IDEKaHcuc25k Lm1heGF1dG92Y2hhbnM6IDE2Cmh3LnNuZC5kZWZhdWx0X3VuaXQ6IDAKaHcuc25kLnZlcnNpb246 IDIwMDcwNjE2MDAvaTM4Ngpody5zbmQuZGVmYXVsdF9hdXRvOiAwCmh3Lm1pZGkuaW5zdHJvZmY6 IDAKaHcubWlkaS5kdW1wcmF3OiAwCmh3Lm1pZGkuZGVidWc6IDAKaHcubWlkaS5zdGF0LnZlcmJv c2U6IDAKaHcubWlkaS5zZXEuZGVidWc6IDAKaHcuc3lzY29ucy5rYmRfZGVidWc6IDEKaHcuc3lz Y29ucy5rYmRfcmVib290OiAxCmh3LnN5c2NvbnMuYmVsbDogMQpody5zeXNjb25zLnNhdmVyLmtl eWJvbmx5OiAxCmh3LnN5c2NvbnMuc2Nfbm9fc3VzcGVuZF92dHN3aXRjaDogMApody5pbnRyX3N0 b3JtX3RocmVzaG9sZDogMTAwMApody5hdmFpbHBhZ2VzOiA1MjE3OTcKaHcuYnVzLmRldmN0bF9k aXNhYmxlOiAwCmh3LnBzbS50YXBfdGltZW91dDogMTI1MDAwCmh3LnBzbS50YXBfdGhyZXNob2xk OiAyNQpody5wc20uc3luYXB0aWNzLmRpcmVjdGlvbmFsX3Njcm9sbHM6IDEKaHcucHNtLnN5bmFw dGljcy5sb3dfc3BlZWRfdGhyZXNob2xkOiAyMApody5wc20uc3luYXB0aWNzLm1pbl9tb3ZlbWVu dDogMgpody5wc20uc3luYXB0aWNzLnNxdWVsY2hfbGV2ZWw6IDMKaHcua2JkLmtleW1hcF9yZXN0 cmljdF9jaGFuZ2U6IDAKaHcuYnVzZG1hLnRvdGFsX2JwYWdlczogNDcKaHcuYnVzZG1hLnpvbmUw LnRvdGFsX2JwYWdlczogMTUKaHcuYnVzZG1hLnpvbmUwLmZyZWVfYnBhZ2VzOiAxNQpody5idXNk bWEuem9uZTAucmVzZXJ2ZWRfYnBhZ2VzOiAwCmh3LmJ1c2RtYS56b25lMC5hY3RpdmVfYnBhZ2Vz OiAwCmh3LmJ1c2RtYS56b25lMC50b3RhbF9ib3VuY2VkOiAwCmh3LmJ1c2RtYS56b25lMC50b3Rh bF9kZWZlcnJlZDogMApody5idXNkbWEuem9uZTAubG93YWRkcjogMHhmZmZmZmZmZgpody5idXNk bWEuem9uZTAuYWxpZ25tZW50OiA0MDk2Cmh3LmJ1c2RtYS56b25lMC5ib3VuZGFyeTogMApody5i dXNkbWEuem9uZTEudG90YWxfYnBhZ2VzOiAzMgpody5idXNkbWEuem9uZTEuZnJlZV9icGFnZXM6 IDMyCmh3LmJ1c2RtYS56b25lMS5yZXNlcnZlZF9icGFnZXM6IDAKaHcuYnVzZG1hLnpvbmUxLmFj dGl2ZV9icGFnZXM6IDAKaHcuYnVzZG1hLnpvbmUxLnRvdGFsX2JvdW5jZWQ6IDAKaHcuYnVzZG1h LnpvbmUxLnRvdGFsX2RlZmVycmVkOiAwCmh3LmJ1c2RtYS56b25lMS5sb3dhZGRyOiAweGZmZmZm ZmZmCmh3LmJ1c2RtYS56b25lMS5hbGlnbm1lbnQ6IDIKaHcuYnVzZG1hLnpvbmUxLmJvdW5kYXJ5 OiA2NTUzNgpody5jbG9ja3JhdGU6IDMwMApody52aWFfZmVhdHVyZV94Y3J5cHQ6IDAKaHcudmlh X2ZlYXR1cmVfcm5nOiAwCmh3Lmluc3RydWN0aW9uX3NzZTogMQpody5hcGljLmVuYWJsZV9leHRp bnQ6IDAKaHcuYWNwaS5zdXBwb3J0ZWRfc2xlZXBfc3RhdGU6IFMzIFM0IFM1Cmh3LmFjcGkucG93 ZXJfYnV0dG9uX3N0YXRlOiBTNQpody5hY3BpLnNsZWVwX2J1dHRvbl9zdGF0ZTogUzMKaHcuYWNw aS5saWRfc3dpdGNoX3N0YXRlOiBOT05FCmh3LmFjcGkuc3RhbmRieV9zdGF0ZTogUzEKaHcuYWNw aS5zdXNwZW5kX3N0YXRlOiBTMwpody5hY3BpLnNsZWVwX2RlbGF5OiAxCmh3LmFjcGkuczRiaW9z OiAwCmh3LmFjcGkudmVyYm9zZTogMQpody5hY3BpLmRpc2FibGVfb25fcmVib290OiAwCmh3LmFj cGkuaGFuZGxlX3JlYm9vdDogMQpody5hY3BpLnJlc2V0X3ZpZGVvOiAxCmh3LmFjcGkuY3B1LmN4 X2xvd2VzdDogQzMKaHcuYWNwaS50aGVybWFsLm1pbl9ydW50aW1lOiAwCmh3LmFjcGkudGhlcm1h bC5wb2xsaW5nX3JhdGU6IDEwCmh3LmFjcGkudGhlcm1hbC51c2VyX292ZXJyaWRlOiAwCmh3LmFj cGkudGhlcm1hbC50ejAudGVtcGVyYXR1cmU6IDQ2LjBDCmh3LmFjcGkudGhlcm1hbC50ejAuYWN0 aXZlOiAtMQpody5hY3BpLnRoZXJtYWwudHowLnBhc3NpdmVfY29vbGluZzogMQpody5hY3BpLnRo ZXJtYWwudHowLnRoZXJtYWxfZmxhZ3M6IDAKaHcuYWNwaS50aGVybWFsLnR6MC5fUFNWOiA5NC41 Qwpody5hY3BpLnRoZXJtYWwudHowLl9IT1Q6IC0xCmh3LmFjcGkudGhlcm1hbC50ejAuX0NSVDog OTkuMEMKaHcuYWNwaS50aGVybWFsLnR6MC5fQUN4OiAtMSAtMSAtMSAtMSAtMSAtMSAtMSAtMSAt MSAtMQpody5hY3BpLnRoZXJtYWwudHowLl9UQzE6IDUKaHcuYWNwaS50aGVybWFsLnR6MC5fVEMy OiA0Cmh3LmFjcGkudGhlcm1hbC50ejAuX1RTUDogNjAwCmh3LmFjcGkuYmF0dGVyeS5saWZlOiA5 Ngpody5hY3BpLmJhdHRlcnkudGltZTogLTEKaHcuYWNwaS5iYXR0ZXJ5LnN0YXRlOiAwCmh3LmFj cGkuYmF0dGVyeS51bml0czogMQpody5hY3BpLmJhdHRlcnkuaW5mb19leHBpcmU6IDUKaHcuYWNw aS5hY2xpbmU6IDEKaHcuZHJpLjAubmFtZTogcmFkZW9uIDB4MjAKaHcuZHJpLjAudm06IApzbG90 CSBvZmZzZXQJICAgICAgc2l6ZSB0eXBlIGZsYWdzCSBhZGRyZXNzIG10cnIKCmh3LmRyaS4wLmNs aWVudHM6IAphIGRldglwaWQgICAgdWlkCW1hZ2ljCSAgaW9jdGxzCgpody5kcmkuMC5kZWJ1Zzog MAptYWNoZGVwLmFjcGlfdGltZXJfZnJlcTogMzU3OTU0NQptYWNoZGVwLmVuYWJsZV9wYW5pY19r ZXk6IDAKbWFjaGRlcC5hZGprZXJudHo6IDAKbWFjaGRlcC53YWxsX2Ntb3NfY2xvY2s6IDAKbWFj aGRlcC5kaXNhYmxlX3J0Y19zZXQ6IDAKbWFjaGRlcC5jb25zcGVlZDogOTYwMAptYWNoZGVwLmdk YnNwZWVkOiA5NjAwCm1hY2hkZXAuY29ucmNsazogMTg0MzIwMAptYWNoZGVwLmFjcGlfcm9vdDog MTAxMDY4OAptYWNoZGVwLmRpc2FibGVfbXRycnM6IDAKbWFjaGRlcC5ndWVzc2VkX2Jvb3RkZXY6 IDI2ODk1OTc0NDAKbWFjaGRlcC5jcHVfaWRsZV9obHQ6IDEKbWFjaGRlcC5obHRfY3B1czogMApt YWNoZGVwLnByb3RfZmF1bHRfdHJhbnNsYXRpb246IDAKbWFjaGRlcC5wYW5pY19vbl9ubWk6IDEK bWFjaGRlcC50c2NfZnJlcTogMzAwMDAwMDAwCm1hY2hkZXAuaTgyNTRfZnJlcTogMTE5MzE4Mgp1 c2VyLmNzX3BhdGg6IC91c3IvYmluOi9iaW46L3Vzci9zYmluOi9zYmluOgp1c2VyLmJjX2Jhc2Vf bWF4OiA5OQp1c2VyLmJjX2RpbV9tYXg6IDIwNDgKdXNlci5iY19zY2FsZV9tYXg6IDk5CnVzZXIu YmNfc3RyaW5nX21heDogMTAwMAp1c2VyLmNvbGxfd2VpZ2h0c19tYXg6IDAKdXNlci5leHByX25l c3RfbWF4OiAzMgp1c2VyLmxpbmVfbWF4OiAyMDQ4CnVzZXIucmVfZHVwX21heDogMjU1CnVzZXIu cG9zaXgyX3ZlcnNpb246IDE5OTIxMgp1c2VyLnBvc2l4Ml9jX2JpbmQ6IDAKdXNlci5wb3NpeDJf Y19kZXY6IDAKdXNlci5wb3NpeDJfY2hhcl90ZXJtOiAwCnVzZXIucG9zaXgyX2ZvcnRfZGV2OiAw CnVzZXIucG9zaXgyX2ZvcnRfcnVuOiAwCnVzZXIucG9zaXgyX2xvY2FsZWRlZjogMAp1c2VyLnBv c2l4Ml9zd19kZXY6IDAKdXNlci5wb3NpeDJfdXBlOiAwCnVzZXIuc3RyZWFtX21heDogMjAKdXNl ci50em5hbWVfbWF4OiAyNTUKcDEwMDNfMWIuYXN5bmNocm9ub3VzX2lvOiAwCnAxMDAzXzFiLm1h cHBlZF9maWxlczogMQpwMTAwM18xYi5tZW1sb2NrOiAwCnAxMDAzXzFiLm1lbWxvY2tfcmFuZ2U6 IDAKcDEwMDNfMWIubWVtb3J5X3Byb3RlY3Rpb246IDAKcDEwMDNfMWIubWVzc2FnZV9wYXNzaW5n OiAwCnAxMDAzXzFiLnByaW9yaXRpemVkX2lvOiAwCnAxMDAzXzFiLnByaW9yaXR5X3NjaGVkdWxp bmc6IDEKcDEwMDNfMWIucmVhbHRpbWVfc2lnbmFsczogMjAwMTEyCnAxMDAzXzFiLnNlbWFwaG9y ZXM6IDAKcDEwMDNfMWIuZnN5bmM6IDAKcDEwMDNfMWIuc2hhcmVkX21lbW9yeV9vYmplY3RzOiAx CnAxMDAzXzFiLnN5bmNocm9uaXplZF9pbzogMApwMTAwM18xYi50aW1lcnM6IDIwMDExMgpwMTAw M18xYi5haW9fbGlzdGlvX21heDogLTEKcDEwMDNfMWIuYWlvX21heDogLTEKcDEwMDNfMWIuYWlv X3ByaW9fZGVsdGFfbWF4OiAtMQpwMTAwM18xYi5kZWxheXRpbWVyX21heDogMjE0NzQ4MzY0Nwpw MTAwM18xYi5tcV9vcGVuX21heDogMApwMTAwM18xYi5wYWdlc2l6ZTogNDA5NgpwMTAwM18xYi5y dHNpZ19tYXg6IDYyCnAxMDAzXzFiLnNlbV9uc2Vtc19tYXg6IDAKcDEwMDNfMWIuc2VtX3ZhbHVl X21heDogMApwMTAwM18xYi5zaWdxdWV1ZV9tYXg6IDEyOApwMTAwM18xYi50aW1lcl9tYXg6IDMy CnNlY3VyaXR5LmphaWwuamFpbGVkOiAwCnNlY3VyaXR5LmphaWwubW91bnRfYWxsb3dlZDogMApz ZWN1cml0eS5qYWlsLmNoZmxhZ3NfYWxsb3dlZDogMApzZWN1cml0eS5qYWlsLmFsbG93X3Jhd19z b2NrZXRzOiAwCnNlY3VyaXR5LmphaWwuZW5mb3JjZV9zdGF0ZnM6IDIKc2VjdXJpdHkuamFpbC5z eXN2aXBjX2FsbG93ZWQ6IDAKc2VjdXJpdHkuamFpbC5zb2NrZXRfdW5peGlwcm91dGVfb25seTog MQpzZWN1cml0eS5qYWlsLnNldF9ob3N0bmFtZV9hbGxvd2VkOiAxCnNlY3VyaXR5LmJzZC5zdXNl cl9lbmFibGVkOiAxCnNlY3VyaXR5LmJzZC51bnByaXZpbGVnZWRfcHJvY19kZWJ1ZzogMQpzZWN1 cml0eS5ic2QuY29uc2VydmF0aXZlX3NpZ25hbHM6IDEKc2VjdXJpdHkuYnNkLnNlZV9vdGhlcl9n aWRzOiAxCnNlY3VyaXR5LmJzZC5zZWVfb3RoZXJfdWlkczogMApzZWN1cml0eS5ic2QudW5wcml2 aWxlZ2VkX3JlYWRfbXNnYnVmOiAxCnNlY3VyaXR5LmJzZC5oYXJkbGlua19jaGVja19naWQ6IDAK c2VjdXJpdHkuYnNkLmhhcmRsaW5rX2NoZWNrX3VpZDogMApzZWN1cml0eS5ic2QudW5wcml2aWxl Z2VkX2dldF9xdW90YTogMApkZXYubmV4dXMuMC4lZHJpdmVyOiBuZXh1cwpkZXYubmV4dXMuMC4l cGFyZW50OiByb290MApkZXYucmFtLjAuJWRlc2M6IFN5c3RlbSBSQU0KZGV2LnJhbS4wLiVkcml2 ZXI6IHJhbQpkZXYucmFtLjAuJXBhcmVudDogbmV4dXMwCmRldi5ucHguMC4lZGVzYzogbWF0aCBw cm9jZXNzb3IKZGV2Lm5weC4wLiVkcml2ZXI6IG5weApkZXYubnB4LjAuJXBhcmVudDogbmV4dXMw CmRldi5hY3BpLjAuJWRlc2M6IElCTSBUUC0xWQpkZXYuYWNwaS4wLiVkcml2ZXI6IGFjcGkKZGV2 LmFjcGkuMC4lcGFyZW50OiBuZXh1czAKZGV2LmFjcGlfZWMuMC4lZGVzYzogRW1iZWRkZWQgQ29u dHJvbGxlcjogR1BFIDB4MWMsIEVDRFQKZGV2LmFjcGlfZWMuMC4lZHJpdmVyOiBhY3BpX2VjCmRl di5hY3BpX2VjLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MUENfLkVDX18KZGV2LmFj cGlfZWMuMC4lcG5waW5mbzogX0hJRD1QTlAwQzA5IF9VSUQ9MApkZXYuYWNwaV9lYy4wLiVwYXJl bnQ6IGFjcGkwCmRldi5hY3BpX3N5c3Jlc291cmNlLjAuJWRlc2M6IFN5c3RlbSBSZXNvdXJjZQpk ZXYuYWNwaV9zeXNyZXNvdXJjZS4wLiVkcml2ZXI6IGFjcGlfc3lzcmVzb3VyY2UKZGV2LmFjcGlf c3lzcmVzb3VyY2UuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5NRU1fCmRldi5hY3BpX3N5c3Jl c291cmNlLjAuJXBucGluZm86IF9ISUQ9UE5QMEMwMSBfVUlEPTAKZGV2LmFjcGlfc3lzcmVzb3Vy Y2UuMC4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9zeXNyZXNvdXJjZS4xLiVkZXNjOiBTeXN0ZW0g UmVzb3VyY2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMS4lZHJpdmVyOiBhY3BpX3N5c3Jlc291cmNl CmRldi5hY3BpX3N5c3Jlc291cmNlLjEuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MUENf LlNJT18KZGV2LmFjcGlfc3lzcmVzb3VyY2UuMS4lcG5waW5mbzogX0hJRD1QTlAwQzAyIF9VSUQ9 MApkZXYuYWNwaV9zeXNyZXNvdXJjZS4xLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX3RpbWVyLjAu JWRlc2M6IDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1IegpkZXYuYWNwaV90aW1lci4wLiVkcml2 ZXI6IGFjcGlfdGltZXIKZGV2LmFjcGlfdGltZXIuMC4lbG9jYXRpb246IHVua25vd24KZGV2LmFj cGlfdGltZXIuMC4lcG5waW5mbzogdW5rbm93bgpkZXYuYWNwaV90aW1lci4wLiVwYXJlbnQ6IGFj cGkwCmRldi5wY2lfbGluay4wLiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0EKZGV2LnBjaV9saW5r LjAuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9T Ql8uTE5LQQpkZXYucGNpX2xpbmsuMC4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9VSUQ9MQpkZXYu cGNpX2xpbmsuMC4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMS4lZGVzYzogQUNQSSBQQ0kg TGluayBMTktCCmRldi5wY2lfbGluay4xLiVkcml2ZXI6IHBjaV9saW5rCmRldi5wY2lfbGluay4x LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLkxOS0IKZGV2LnBjaV9saW5rLjEuJXBucGluZm86IF9I SUQ9UE5QMEMwRiBfVUlEPTIKZGV2LnBjaV9saW5rLjEuJXBhcmVudDogYWNwaTAKZGV2LnBjaV9s aW5rLjIuJWRlc2M6IEFDUEkgUENJIExpbmsgTE5LQwpkZXYucGNpX2xpbmsuMi4lZHJpdmVyOiBw Y2lfbGluawpkZXYucGNpX2xpbmsuMi4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktDCmRldi5w Y2lfbGluay4yLiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD0zCmRldi5wY2lfbGluay4yLiVw YXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay4zLiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0QKZGV2 LnBjaV9saW5rLjMuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjMuJWxvY2F0aW9uOiBo YW5kbGU9XF9TQl8uTE5LRApkZXYucGNpX2xpbmsuMy4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9V SUQ9NApkZXYucGNpX2xpbmsuMy4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuNC4lZGVzYzog QUNQSSBQQ0kgTGluayBMTktFCmRldi5wY2lfbGluay40LiVkcml2ZXI6IHBjaV9saW5rCmRldi5w Y2lfbGluay40LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLkxOS0UKZGV2LnBjaV9saW5rLjQuJXBu cGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTUKZGV2LnBjaV9saW5rLjQuJXBhcmVudDogYWNwaTAK ZGV2LnBjaV9saW5rLjUuJWRlc2M6IEFDUEkgUENJIExpbmsgTE5LRgpkZXYucGNpX2xpbmsuNS4l ZHJpdmVyOiBwY2lfbGluawpkZXYucGNpX2xpbmsuNS4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5M TktGCmRldi5wY2lfbGluay41LiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD02CmRldi5wY2lf bGluay41LiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay42LiVkZXNjOiBBQ1BJIFBDSSBMaW5r IExOS0cKZGV2LnBjaV9saW5rLjYuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjYuJWxv Y2F0aW9uOiBoYW5kbGU9XF9TQl8uTE5LRwpkZXYucGNpX2xpbmsuNi4lcG5waW5mbzogX0hJRD1Q TlAwQzBGIF9VSUQ9NwpkZXYucGNpX2xpbmsuNi4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsu Ny4lZGVzYzogQUNQSSBQQ0kgTGluayBMTktICmRldi5wY2lfbGluay43LiVkcml2ZXI6IHBjaV9s aW5rCmRldi5wY2lfbGluay43LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLkxOS0gKZGV2LnBjaV9s aW5rLjcuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTgKZGV2LnBjaV9saW5rLjcuJXBhcmVu dDogYWNwaTAKZGV2LmNwdS4wLiVkZXNjOiBBQ1BJIENQVQpkZXYuY3B1LjAuJWRyaXZlcjogY3B1 CmRldi5jcHUuMC4lbG9jYXRpb246IGhhbmRsZT1cX1BSXy5DUFVfCmRldi5jcHUuMC4lcG5waW5m bzogX0hJRD1ub25lIF9VSUQ9MApkZXYuY3B1LjAuJXBhcmVudDogYWNwaTAKZGV2LmNwdS4wLmZy ZXE6IDMwMApkZXYuY3B1LjAuZnJlcV9sZXZlbHM6IDIyNjYvMjcwMDAgMTk4Mi8yMzYyNSAxODY2 LzIzNDAwIDE2MzIvMjA0NzUgMTM5OS8xNzU1MCAxMzMzLzE4NjAwIDExNjYvMTYyNzUgOTk5LzEz OTUwIDgzMy8xMTYyNSA4MDAvMTM4MDAgNzAwLzEyMDc1IDYwMC8xMDM1MCA1MDAvODYyNSA0MDAv NjkwMCAzMDAvNTE3NSAyMDAvMzQ1MCAxMDAvMTcyNQpkZXYuY3B1LjAuY3hfc3VwcG9ydGVkOiBD MS8xIEMyLzEgQzMvODUKZGV2LmNwdS4wLmN4X2xvd2VzdDogQzMKZGV2LmNwdS4wLmN4X3VzYWdl OiAwLjAwJSA5OS45OSUgMC4wMCUKZGV2LmFjcGlfcGVyZi4wLiVkcml2ZXI6IGFjcGlfcGVyZgpk ZXYuYWNwaV9wZXJmLjAuJXBhcmVudDogY3B1MApkZXYuZXN0LjAuJWRlc2M6IEVuaGFuY2VkIFNw ZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbApkZXYuZXN0LjAuJWRyaXZlcjogZXN0CmRldi5lc3Qu MC4lcGFyZW50OiBjcHUwCmRldi5lc3QuMC5mcmVxX3NldHRpbmdzOiAyMjY2LzI3MDAwIDE4NjYv MjM0MDAgMTMzMy8xODYwMCA4MDAvMTM4MDAKZGV2LmNwdWZyZXEuMC4lZHJpdmVyOiBjcHVmcmVx CmRldi5jcHVmcmVxLjAuJXBhcmVudDogY3B1MApkZXYucDR0Y2MuMC4lZGVzYzogQ1BVIEZyZXF1 ZW5jeSBUaGVybWFsIENvbnRyb2wKZGV2LnA0dGNjLjAuJWRyaXZlcjogcDR0Y2MKZGV2LnA0dGNj LjAuJXBhcmVudDogY3B1MApkZXYucDR0Y2MuMC5mcmVxX3NldHRpbmdzOiAxMDAwMC8tMSA4NzUw Ly0xIDc1MDAvLTEgNjI1MC8tMSA1MDAwLy0xIDM3NTAvLTEgMjUwMC8tMSAxMjUwLy0xCmRldi5h Y3BpX2xpZC4wLiVkZXNjOiBDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNoCmRldi5hY3BpX2xpZC4w LiVkcml2ZXI6IGFjcGlfbGlkCmRldi5hY3BpX2xpZC4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0Jf LkxJRF8KZGV2LmFjcGlfbGlkLjAuJXBucGluZm86IF9ISUQ9UE5QMEMwRCBfVUlEPTAKZGV2LmFj cGlfbGlkLjAuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfbGlkLjAud2FrZTogMQpkZXYuYWNwaV9i dXR0b24uMC4lZGVzYzogU2xlZXAgQnV0dG9uCmRldi5hY3BpX2J1dHRvbi4wLiVkcml2ZXI6IGFj cGlfYnV0dG9uCmRldi5hY3BpX2J1dHRvbi4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlNMUEIK ZGV2LmFjcGlfYnV0dG9uLjAuJXBucGluZm86IF9ISUQ9UE5QMEMwRSBfVUlEPTAKZGV2LmFjcGlf YnV0dG9uLjAuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfYnV0dG9uLjAud2FrZTogMQpkZXYucGNp Yi4wLiVkZXNjOiBBQ1BJIEhvc3QtUENJIGJyaWRnZQpkZXYucGNpYi4wLiVkcml2ZXI6IHBjaWIK ZGV2LnBjaWIuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwCmRldi5wY2liLjAuJXBucGlu Zm86IF9ISUQ9UE5QMEEwOCBfVUlEPTAKZGV2LnBjaWIuMC4lcGFyZW50OiBhY3BpMApkZXYucGNp Yi4xLiVkZXNjOiBBQ1BJIFBDSS1QQ0kgYnJpZGdlCmRldi5wY2liLjEuJWRyaXZlcjogcGNpYgpk ZXYucGNpYi4xLiVsb2NhdGlvbjogc2xvdD0xIGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAu QUdQXwpkZXYucGNpYi4xLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI1OTEgc3Vi dmVuZG9yPTB4MTAxNCBzdWJkZXZpY2U9MHgwNTc4IGNsYXNzPTB4MDYwNDAwCmRldi5wY2liLjEu JXBhcmVudDogcGNpMApkZXYucGNpYi4yLiVkZXNjOiBBQ1BJIFBDSS1QQ0kgYnJpZGdlCmRldi5w Y2liLjIuJWRyaXZlcjogcGNpYgpkZXYucGNpYi4yLiVsb2NhdGlvbjogc2xvdD0yOCBmdW5jdGlv bj0wIGhhbmRsZT1cX1NCXy5QQ0kwLkVYUDAKZGV2LnBjaWIuMi4lcG5waW5mbzogdmVuZG9yPTB4 ODA4NiBkZXZpY2U9MHgyNjYwIHN1YnZlbmRvcj0weDAwMDAgc3ViZGV2aWNlPTB4MDAwMCBjbGFz cz0weDA2MDQwMApkZXYucGNpYi4yLiVwYXJlbnQ6IHBjaTAKZGV2LnBjaWIuMi53YWtlOiAwCmRl di5wY2liLjMuJWRlc2M6IEFDUEkgUENJLVBDSSBicmlkZ2UKZGV2LnBjaWIuMy4lZHJpdmVyOiBw Y2liCmRldi5wY2liLjMuJWxvY2F0aW9uOiBzbG90PTI4IGZ1bmN0aW9uPTIgaGFuZGxlPVxfU0Jf LlBDSTAuRVhQMgpkZXYucGNpYi4zLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI2 NjQgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwIGNsYXNzPTB4MDYwNDAwCmRldi5w Y2liLjMuJXBhcmVudDogcGNpMApkZXYucGNpYi4zLndha2U6IDAKZGV2LnBjaWIuNC4lZGVzYzog QUNQSSBQQ0ktUENJIGJyaWRnZQpkZXYucGNpYi40LiVkcml2ZXI6IHBjaWIKZGV2LnBjaWIuNC4l bG9jYXRpb246IHNsb3Q9MzAgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5QQ0kxCmRldi5w Y2liLjQuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjQ0OCBzdWJ2ZW5kb3I9MHgw MDAwIHN1YmRldmljZT0weDAwMDAgY2xhc3M9MHgwNjA0MDEKZGV2LnBjaWIuNC4lcGFyZW50OiBw Y2kwCmRldi5wY2liLjQud2FrZTogMApkZXYucGNpLjAuJWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYu cGNpLjAuJWRyaXZlcjogcGNpCmRldi5wY2kuMC4lcGFyZW50OiBwY2liMApkZXYucGNpLjEuJWRl c2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjEuJWRyaXZlcjogcGNpCmRldi5wY2kuMS4lcGFyZW50 OiBwY2liMQpkZXYucGNpLjIuJWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjIuJWRyaXZlcjog cGNpCmRldi5wY2kuMi4lcGFyZW50OiBwY2liMgpkZXYucGNpLjIud2FrZTogMApkZXYucGNpLjMu JWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjMuJWRyaXZlcjogcGNpCmRldi5wY2kuMy4lcGFy ZW50OiBwY2liMwpkZXYucGNpLjMud2FrZTogMApkZXYucGNpLjExLiVkZXNjOiBBQ1BJIFBDSSBi dXMKZGV2LnBjaS4xMS4lZHJpdmVyOiBwY2kKZGV2LnBjaS4xMS4lcGFyZW50OiBwY2liNApkZXYu cGNpLjExLndha2U6IDAKZGV2Lmhvc3RiLjAuJWRlc2M6IEhvc3QgdG8gUENJIGJyaWRnZQpkZXYu aG9zdGIuMC4lZHJpdmVyOiBob3N0YgpkZXYuaG9zdGIuMC4lbG9jYXRpb246IHNsb3Q9MCBmdW5j dGlvbj0wCmRldi5ob3N0Yi4wLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI1OTAg c3VidmVuZG9yPTB4MTAxNCBzdWJkZXZpY2U9MHgwNTc1IGNsYXNzPTB4MDYwMDAwCmRldi5ob3N0 Yi4wLiVwYXJlbnQ6IHBjaTAKZGV2LnZnYXBjaS4wLiVkZXNjOiBWR0EtY29tcGF0aWJsZSBkaXNw bGF5CmRldi52Z2FwY2kuMC4lZHJpdmVyOiB2Z2FwY2kKZGV2LnZnYXBjaS4wLiVsb2NhdGlvbjog c2xvdD0wIGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuQUdQXy5WSURfCmRldi52Z2FwY2ku MC4lcG5waW5mbzogdmVuZG9yPTB4MTAwMiBkZXZpY2U9MHgzMTU0IHN1YnZlbmRvcj0weDEwMTQg c3ViZGV2aWNlPTB4MDU3MCBjbGFzcz0weDAzMDAwMApkZXYudmdhcGNpLjAuJXBhcmVudDogcGNp MQpkZXYuZHJtLjAuJWRlc2M6IEFUSSBGaXJlR0wgTTI0IEdMCmRldi5kcm0uMC4lZHJpdmVyOiBk cm0KZGV2LmRybS4wLiVwYXJlbnQ6IHZnYXBjaTAKZGV2LmJnZS4wLiVkZXNjOiBCcm9hZGNvbSBO ZXRYdHJlbWUgR2lnYWJpdCBFdGhlcm5ldCBDb250cm9sbGVyLCBBU0lDIHJldi4gMHg0MTAxCmRl di5iZ2UuMC4lZHJpdmVyOiBiZ2UKZGV2LmJnZS4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAKZGV2LmJnZS4wLiVwbnBpbmZvOiB2ZW5kb3I9MHgxNGU0IGRldmljZT0weDE2N2Qgc3VidmVu ZG9yPTB4MTAxNCBzdWJkZXZpY2U9MHgwNTc3IGNsYXNzPTB4MDIwMDAwCmRldi5iZ2UuMC4lcGFy ZW50OiBwY2kyCmRldi5taWlidXMuMC4lZGVzYzogTUlJIGJ1cwpkZXYubWlpYnVzLjAuJWRyaXZl cjogbWlpYnVzCmRldi5taWlidXMuMC4lcGFyZW50OiBiZ2UwCmRldi5icmdwaHkuMC4lZGVzYzog QkNNNTc1MCAxMC8xMDAvMTAwMGJhc2VUWCBQSFkKZGV2LmJyZ3BoeS4wLiVkcml2ZXI6IGJyZ3Bo eQpkZXYuYnJncGh5LjAuJWxvY2F0aW9uOiBwaHlubz0xCmRldi5icmdwaHkuMC4lcG5waW5mbzog b3VpPTB4ODE4IG1vZGVsPTB4MTggcmV2PTB4MApkZXYuYnJncGh5LjAuJXBhcmVudDogbWlpYnVz MApkZXYudWhjaS4wLiVkZXNjOiBJbnRlbCA4MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNv bnRyb2xsZXIgVVNCLUEKZGV2LnVoY2kuMC4lZHJpdmVyOiB1aGNpCmRldi51aGNpLjAuJWxvY2F0 aW9uOiBzbG90PTI5IGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuVVNCMApkZXYudWhjaS4w LiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI2NTggc3VidmVuZG9yPTB4MTAxNCBz dWJkZXZpY2U9MHgwNTY1IGNsYXNzPTB4MGMwMzAwCmRldi51aGNpLjAuJXBhcmVudDogcGNpMApk ZXYudWhjaS4wLndha2U6IDAKZGV2LnVoY2kuMS4lZGVzYzogSW50ZWwgODI4MDFGQi9GUi9GVy9G UlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1CCmRldi51aGNpLjEuJWRyaXZlcjogdWhjaQpk ZXYudWhjaS4xLiVsb2NhdGlvbjogc2xvdD0yOSBmdW5jdGlvbj0xIGhhbmRsZT1cX1NCXy5QQ0kw LlVTQjEKZGV2LnVoY2kuMS4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyNjU5IHN1 YnZlbmRvcj0weDEwMTQgc3ViZGV2aWNlPTB4MDU2NSBjbGFzcz0weDBjMDMwMApkZXYudWhjaS4x LiVwYXJlbnQ6IHBjaTAKZGV2LnVoY2kuMS53YWtlOiAwCmRldi51aGNpLjIuJWRlc2M6IEludGVs IDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBVU0ItQwpkZXYudWhjaS4y LiVkcml2ZXI6IHVoY2kKZGV2LnVoY2kuMi4lbG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249MiBo YW5kbGU9XF9TQl8uUENJMC5VU0IyCmRldi51aGNpLjIuJXBucGluZm86IHZlbmRvcj0weDgwODYg ZGV2aWNlPTB4MjY1YSBzdWJ2ZW5kb3I9MHgxMDE0IHN1YmRldmljZT0weDA1NjUgY2xhc3M9MHgw YzAzMDAKZGV2LnVoY2kuMi4lcGFyZW50OiBwY2kwCmRldi51aGNpLjMuJWRlc2M6IEludGVsIDgy ODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBVU0ItRApkZXYudWhjaS4zLiVk cml2ZXI6IHVoY2kKZGV2LnVoY2kuMy4lbG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249MyBoYW5k bGU9XF9TQl8uUENJMC5VU0IzCmRldi51aGNpLjMuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2 aWNlPTB4MjY1YiBzdWJ2ZW5kb3I9MHgxMDE0IHN1YmRldmljZT0weDA1NjUgY2xhc3M9MHgwYzAz MDAKZGV2LnVoY2kuMy4lcGFyZW50OiBwY2kwCmRldi51aGNpLjMud2FrZTogMApkZXYudXNiLjAu JWRlc2M6IEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBVU0It QQpkZXYudXNiLjAuJWRyaXZlcjogdXNiCmRldi51c2IuMC4lcGFyZW50OiB1aGNpMApkZXYudXNi LjEuJWRlc2M6IEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBV U0ItQgpkZXYudXNiLjEuJWRyaXZlcjogdXNiCmRldi51c2IuMS4lcGFyZW50OiB1aGNpMQpkZXYu dXNiLjIuJWRlc2M6IEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxl ciBVU0ItQwpkZXYudXNiLjIuJWRyaXZlcjogdXNiCmRldi51c2IuMi4lcGFyZW50OiB1aGNpMgpk ZXYudXNiLjMuJWRlc2M6IEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJv bGxlciBVU0ItRApkZXYudXNiLjMuJWRyaXZlcjogdXNiCmRldi51c2IuMy4lcGFyZW50OiB1aGNp MwpkZXYudXNiLjQuJWRlc2M6IEludGVsIDgyODAxRkIgKElDSDYpIFVTQiAyLjAgY29udHJvbGxl cgpkZXYudXNiLjQuJWRyaXZlcjogdXNiCmRldi51c2IuNC4lcGFyZW50OiBlaGNpMApkZXYudWh1 Yi4wLiVkZXNjOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMQpkZXYudWh1Yi4wLiVkcml2ZXI6IHVodWIKZGV2LnVodWIuMC4lcGFyZW50OiB1c2Iw CmRldi51aHViLjEuJWRlc2M6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEu MDAvMS4wMCwgYWRkciAxCmRldi51aHViLjEuJWRyaXZlcjogdWh1YgpkZXYudWh1Yi4xLiVwYXJl bnQ6IHVzYjEKZGV2LnVodWIuMi4lZGVzYzogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKZGV2LnVodWIuMi4lZHJpdmVyOiB1aHViCmRldi51aHVi LjIuJXBhcmVudDogdXNiMgpkZXYudWh1Yi4zLiVkZXNjOiBJbnRlbCBVSENJIHJvb3QgaHViLCBj bGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQpkZXYudWh1Yi4zLiVkcml2ZXI6IHVodWIK ZGV2LnVodWIuMy4lcGFyZW50OiB1c2IzCmRldi51aHViLjQuJWRlc2M6IEludGVsIEVIQ0kgcm9v dCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxCmRldi51aHViLjQuJWRyaXZl cjogdWh1YgpkZXYudWh1Yi40LiVwYXJlbnQ6IHVzYjQKZGV2LmVoY2kuMC4lZGVzYzogSW50ZWwg ODI4MDFGQiAoSUNINikgVVNCIDIuMCBjb250cm9sbGVyCmRldi5laGNpLjAuJWRyaXZlcjogZWhj aQpkZXYuZWhjaS4wLiVsb2NhdGlvbjogc2xvdD0yOSBmdW5jdGlvbj03IGhhbmRsZT1cX1NCXy5Q Q0kwLlVTQjcKZGV2LmVoY2kuMC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyNjVj IHN1YnZlbmRvcj0weDEwMTQgc3ViZGV2aWNlPTB4MDU2NiBjbGFzcz0weDBjMDMyMApkZXYuZWhj aS4wLiVwYXJlbnQ6IHBjaTAKZGV2LmVoY2kuMC53YWtlOiAwCmRldi5jYmIuMC4lZGVzYzogUkY1 QzQ3NiBQQ0ktQ2FyZEJ1cyBCcmlkZ2UKZGV2LmNiYi4wLiVkcml2ZXI6IGNiYgpkZXYuY2JiLjAu JWxvY2F0aW9uOiBzbG90PTAgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5QQ0kxLkNEQlMK ZGV2LmNiYi4wLiVwbnBpbmZvOiB2ZW5kb3I9MHgxMTgwIGRldmljZT0weDA0NzYgc3VidmVuZG9y PTB4MTAxNCBzdWJkZXZpY2U9MHgwNTZjIGNsYXNzPTB4MDYwNzAwCmRldi5jYmIuMC4lcGFyZW50 OiBwY2kxMQpkZXYuY2JiLjAuZG9tYWluOiAwCmRldi5jYmIuMC5wcmlidXM6IDExCmRldi5jYmIu MC5zZWNidXM6IDEyCmRldi5jYmIuMC5zdWJidXM6IDE0CmRldi5jYXJkYnVzLiVwYXJlbnQ6IHBj aQpkZXYuY2FyZGJ1cy4wLiVkZXNjOiBDYXJkQnVzIGJ1cwpkZXYuY2FyZGJ1cy4wLiVkcml2ZXI6 IGNhcmRidXMKZGV2LmNhcmRidXMuMC4lcGFyZW50OiBjYmIwCmRldi5wY2NhcmQuMC4lZGVzYzog MTYtYml0IFBDQ2FyZCBidXMKZGV2LnBjY2FyZC4wLiVkcml2ZXI6IHBjY2FyZApkZXYucGNjYXJk LjAuJXBhcmVudDogY2JiMApkZXYuYXRoLjAuJWRlc2M6IEF0aGVyb3MgNTIxMgpkZXYuYXRoLjAu JWRyaXZlcjogYXRoCmRldi5hdGguMC4lbG9jYXRpb246IHNsb3Q9MiBmdW5jdGlvbj0wCmRldi5h dGguMC4lcG5waW5mbzogdmVuZG9yPTB4MTY4YyBkZXZpY2U9MHgxMDE0IHN1YnZlbmRvcj0weDEw MTQgc3ViZGV2aWNlPTB4MDU3ZSBjbGFzcz0weDAyMDAwMApkZXYuYXRoLjAuJXBhcmVudDogcGNp MTEKZGV2LmF0aC4wLnNtb290aGluZ19yYXRlOiA5NQpkZXYuYXRoLjAuc2FtcGxlX3JhdGU6IDEw CmRldi5hdGguMC5jb3VudHJ5Y29kZTogMApkZXYuYXRoLjAucmVnZG9tYWluOiAxMDIKZGV2LmF0 aC4wLnNsb3R0aW1lOiA5CmRldi5hdGguMC5hY2t0aW1lb3V0OiA2NTEKZGV2LmF0aC4wLmN0c3Rp bWVvdXQ6IDY5MgpkZXYuYXRoLjAuc29mdGxlZDogMQpkZXYuYXRoLjAubGVkcGluOiAwCmRldi5h dGguMC5sZWRvbjogMApkZXYuYXRoLjAubGVkaWRsZTogMjcwMApkZXYuYXRoLjAudHhhbnRlbm5h OiAwCmRldi5hdGguMC5yeGFudGVubmE6IDAKZGV2LmF0aC4wLmRpdmVyc2l0eTogMQpkZXYuYXRo LjAudHhpbnRycGVyaW9kOiA1CmRldi5hdGguMC5kaWFnOiAwCmRldi5hdGguMC50cHNjYWxlOiAw CmRldi5hdGguMC50cGM6IDAKZGV2LmF0aC4wLnRwYWNrOiA2MwpkZXYuYXRoLjAudHBjdHM6IDYz CmRldi5hdGguMC5mZnR4cW1pbjogMgpkZXYuYXRoLjAuZmZ0eHFtYXg6IDUwCmRldi5hdGguMC5y ZnNpbGVudDogOQpkZXYuYXRoLjAucmZraWxsOiAxCmRldi5hdGguMC5tb25wYXNzOiAyNApkZXYu cGNtLjAuJWRlc2M6IEludGVsIElDSDYgKDgyODAxRkIpCmRldi5wY20uMC4lZHJpdmVyOiBwY20K ZGV2LnBjbS4wLiVsb2NhdGlvbjogc2xvdD0zMCBmdW5jdGlvbj0yIGhhbmRsZT1cX1NCXy5QQ0kw LkFDOUEKZGV2LnBjbS4wLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI2NmUgc3Vi dmVuZG9yPTB4MTAxNCBzdWJkZXZpY2U9MHgwNTY3IGNsYXNzPTB4MDQwMTAwCmRldi5wY20uMC4l cGFyZW50OiBwY2kwCmRldi5wY20uMC5lYXBkOiAxCmRldi5wY20uMC5wbGF5LnZjaGFuczogMQpk ZXYucGNtLjAucGxheS52Y2hhbnJhdGU6IDQ4MDAwCmRldi5wY20uMC5wbGF5LnZjaGFuZm9ybWF0 OiBzMTZsZQpkZXYucGNtLjAucmVjLnZjaGFuczogMQpkZXYucGNtLjAucmVjLnZjaGFucmF0ZTog NDgwMDAKZGV2LnBjbS4wLnJlYy52Y2hhbmZvcm1hdDogczE2bGUKZGV2LnBjbS4wLmJ1ZmZlcnNp emU6IDE2Mzg0CmRldi5wY20uMC5hYzk3cmF0ZTogNDgwMDAKZGV2LmlzYWIuMC4lZGVzYzogUENJ LUlTQSBicmlkZ2UKZGV2LmlzYWIuMC4lZHJpdmVyOiBpc2FiCmRldi5pc2FiLjAuJWxvY2F0aW9u OiBzbG90PTMxIGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuTFBDXwpkZXYuaXNhYi4wLiVw bnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI2NDEgc3VidmVuZG9yPTB4MTAxNCBzdWJk ZXZpY2U9MHgwNTY4IGNsYXNzPTB4MDYwMTAwCmRldi5pc2FiLjAuJXBhcmVudDogcGNpMApkZXYu aXNhLjAuJWRlc2M6IElTQSBidXMKZGV2LmlzYS4wLiVkcml2ZXI6IGlzYQpkZXYuaXNhLjAuJXBh cmVudDogaXNhYjAKZGV2LmF0YXBjaS4wLiVkZXNjOiBJbnRlbCBJQ0g2TSBTQVRBMTUwIGNvbnRy b2xsZXIKZGV2LmF0YXBjaS4wLiVkcml2ZXI6IGF0YXBjaQpkZXYuYXRhcGNpLjAuJWxvY2F0aW9u OiBzbG90PTMxIGZ1bmN0aW9uPTIgaGFuZGxlPVxfU0JfLlBDSTAuSURFMApkZXYuYXRhcGNpLjAu JXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjY1MyBzdWJ2ZW5kb3I9MHgxMDE0IHN1 YmRldmljZT0weDA1NmEgY2xhc3M9MHgwMTAxODAKZGV2LmF0YXBjaS4wLiVwYXJlbnQ6IHBjaTAK ZGV2LmF0YS4wLiVkZXNjOiBBVEEgY2hhbm5lbCAwCmRldi5hdGEuMC4lZHJpdmVyOiBhdGEKZGV2 LmF0YS4wLiVwYXJlbnQ6IGF0YXBjaTAKZGV2LmF0YS4xLiVkZXNjOiBBVEEgY2hhbm5lbCAxCmRl di5hdGEuMS4lZHJpdmVyOiBhdGEKZGV2LmF0YS4xLiVwYXJlbnQ6IGF0YXBjaTAKZGV2LmljaHNt Yi4wLiVkZXNjOiBJbnRlbCA4MjgwMUZCIChJQ0g2KSBTTUJ1cyBjb250cm9sbGVyCmRldi5pY2hz bWIuMC4lZHJpdmVyOiBpY2hzbWIKZGV2LmljaHNtYi4wLiVsb2NhdGlvbjogc2xvdD0zMSBmdW5j dGlvbj0zIGhhbmRsZT1cX1NCXy5QQ0kwLlNNQlUKZGV2LmljaHNtYi4wLiVwbnBpbmZvOiB2ZW5k b3I9MHg4MDg2IGRldmljZT0weDI2NmEgc3VidmVuZG9yPTB4MTAxNCBzdWJkZXZpY2U9MHgwNTZi IGNsYXNzPTB4MGMwNTAwCmRldi5pY2hzbWIuMC4lcGFyZW50OiBwY2kwCmRldi5zbWJ1cy4wLiVk ZXNjOiBTeXN0ZW0gTWFuYWdlbWVudCBCdXMKZGV2LnNtYnVzLjAuJWRyaXZlcjogc21idXMKZGV2 LnNtYnVzLjAuJXBhcmVudDogaWNoc21iMApkZXYuc21iLjAuJWRlc2M6IFNNQnVzIGdlbmVyaWMg SS9PCmRldi5zbWIuMC4lZHJpdmVyOiBzbWIKZGV2LnNtYi4wLiVwYXJlbnQ6IHNtYnVzMApkZXYu YWNwaV90ei4wLiVkZXNjOiBUaGVybWFsIFpvbmUKZGV2LmFjcGlfdHouMC4lZHJpdmVyOiBhY3Bp X3R6CmRldi5hY3BpX3R6LjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9UWl8uVEhNMApkZXYuYWNwaV90 ei4wLiVwbnBpbmZvOiBfSElEPW5vbmUgX1VJRD0wCmRldi5hY3BpX3R6LjAuJXBhcmVudDogYWNw aTAKZGV2LmF0cGljLjAuJWRlc2M6IEFUIGludGVycnVwdCBjb250cm9sbGVyCmRldi5hdHBpYy4w LiVkcml2ZXI6IGF0cGljCmRldi5hdHBpYy4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAu TFBDXy5QSUNfCmRldi5hdHBpYy4wLiVwbnBpbmZvOiBfSElEPVBOUDAwMDAgX1VJRD0wCmRldi5h dHBpYy4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hdHRpbWVyLjAuJWRlc2M6IEFUIHRpbWVyCmRldi5h dHRpbWVyLjAuJWRyaXZlcjogYXR0aW1lcgpkZXYuYXR0aW1lci4wLiVsb2NhdGlvbjogaGFuZGxl PVxfU0JfLlBDSTAuTFBDXy5USU1SCmRldi5hdHRpbWVyLjAuJXBucGluZm86IF9ISUQ9UE5QMDEw MCBfVUlEPTAKZGV2LmF0dGltZXIuMC4lcGFyZW50OiBhY3BpMApkZXYuYXR0aW1lci4xLiVkZXNj OiBBVCByZWFsdGltZSBjbG9jawpkZXYuYXR0aW1lci4xLiVkcml2ZXI6IGF0dGltZXIKZGV2LmF0 dGltZXIuMS4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLkxQQ18uUlRDXwpkZXYuYXR0aW1l ci4xLiVwbnBpbmZvOiBfSElEPVBOUDBCMDAgX1VJRD0wCmRldi5hdHRpbWVyLjEuJXBhcmVudDog YWNwaTAKZGV2LmF0ZG1hLjAuJWRlc2M6IEFUIERNQSBjb250cm9sbGVyCmRldi5hdGRtYS4wLiVk cml2ZXI6IGF0ZG1hCmRldi5hdGRtYS4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTFBD Xy5ETUFDCmRldi5hdGRtYS4wLiVwbnBpbmZvOiBfSElEPVBOUDAyMDAgX1VJRD0wCmRldi5hdGRt YS4wLiVwYXJlbnQ6IGFjcGkwCmRldi5zcGVha2VyLjAuJWRlc2M6IFBDIHNwZWFrZXIKZGV2LnNw ZWFrZXIuMC4lZHJpdmVyOiBzcGVha2VyCmRldi5zcGVha2VyLjAuJWxvY2F0aW9uOiBoYW5kbGU9 XF9TQl8uUENJMC5MUENfLlNQS1IKZGV2LnNwZWFrZXIuMC4lcG5waW5mbzogX0hJRD1QTlAwODAw IF9VSUQ9MApkZXYuc3BlYWtlci4wLiVwYXJlbnQ6IGFjcGkwCmRldi5ucHhpc2EuMC4lZGVzYzog TGVnYWN5IElTQSBjb3Byb2Nlc3NvciBzdXBwb3J0CmRldi5ucHhpc2EuMC4lZHJpdmVyOiBucHhp c2EKZGV2Lm5weGlzYS4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTFBDXy5GUFVfCmRl di5ucHhpc2EuMC4lcG5waW5mbzogX0hJRD1QTlAwQzA0IF9VSUQ9MApkZXYubnB4aXNhLjAuJXBh cmVudDogYWNwaTAKZGV2LmF0a2JkYy4wLiVkZXNjOiBLZXlib2FyZCBjb250cm9sbGVyIChpODA0 MikKZGV2LmF0a2JkYy4wLiVkcml2ZXI6IGF0a2JkYwpkZXYuYXRrYmRjLjAuJWxvY2F0aW9uOiBo YW5kbGU9XF9TQl8uUENJMC5MUENfLktCRF8KZGV2LmF0a2JkYy4wLiVwbnBpbmZvOiBfSElEPVBO UDAzMDMgX1VJRD0wCmRldi5hdGtiZGMuMC4lcGFyZW50OiBhY3BpMApkZXYuYXRrYmQuMC4lZGVz YzogQVQgS2V5Ym9hcmQKZGV2LmF0a2JkLjAuJWRyaXZlcjogYXRrYmQKZGV2LmF0a2JkLjAuJXBh cmVudDogYXRrYmRjMApkZXYucHNtY3BucC4wLiVkZXNjOiBQUy8yIG1vdXNlIHBvcnQKZGV2LnBz bWNwbnAuMC4lZHJpdmVyOiBwc21jcG5wCmRldi5wc21jcG5wLjAuJWxvY2F0aW9uOiBoYW5kbGU9 XF9TQl8uUENJMC5MUENfLk1PVV8KZGV2LnBzbWNwbnAuMC4lcG5waW5mbzogX0hJRD1JQk0wMDU3 IF9VSUQ9MApkZXYucHNtY3BucC4wLiVwYXJlbnQ6IGFjcGkwCmRldi5wc20uMC4lZGVzYzogUFMv MiBNb3VzZQpkZXYucHNtLjAuJWRyaXZlcjogcHNtCmRldi5wc20uMC4lcGFyZW50OiBhdGtiZGMw CmRldi5zaW8uMC4lZGVzYzogMTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQKZGV2LnNpby4wLiVk cml2ZXI6IHNpbwpkZXYuc2lvLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MUENfLlVB UlQKZGV2LnNpby4wLiVwbnBpbmZvOiBfSElEPVBOUDA1MDEgX1VJRD0wCmRldi5zaW8uMC4lcGFy ZW50OiBhY3BpMApkZXYuc2lvLjAud2FrZTogMApkZXYucHBjLjAuJWRlc2M6IFBhcmFsbGVsIHBv cnQKZGV2LnBwYy4wLiVkcml2ZXI6IHBwYwpkZXYucHBjLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9T Ql8uUENJMC5MUENfLkVDUF8KZGV2LnBwYy4wLiVwbnBpbmZvOiBfSElEPVBOUDA0MDEgX1VJRD0w CmRldi5wcGMuMC4lcGFyZW50OiBhY3BpMApkZXYucHBidXMuMC4lZGVzYzogUGFyYWxsZWwgcG9y dCBidXMKZGV2LnBwYnVzLjAuJWRyaXZlcjogcHBidXMKZGV2LnBwYnVzLjAuJXBhcmVudDogcHBj MApkZXYubHB0LjAuJWRlc2M6IFByaW50ZXIKZGV2LmxwdC4wLiVkcml2ZXI6IGxwdApkZXYubHB0 LjAuJXBhcmVudDogcHBidXMwCmRldi5wcGkuMC4lZGVzYzogUGFyYWxsZWwgSS9PCmRldi5wcGku MC4lZHJpdmVyOiBwcGkKZGV2LnBwaS4wLiVwYXJlbnQ6IHBwYnVzMApkZXYuYmF0dGVyeS4wLiVk ZXNjOiBBQ1BJIENvbnRyb2wgTWV0aG9kIEJhdHRlcnkKZGV2LmJhdHRlcnkuMC4lZHJpdmVyOiBi YXR0ZXJ5CmRldi5iYXR0ZXJ5LjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MUENfLkVD X18uQkFUMApkZXYuYmF0dGVyeS4wLiVwbnBpbmZvOiBfSElEPVBOUDBDMEEgX1VJRD0wCmRldi5i YXR0ZXJ5LjAuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfYWNhZC4wLiVkZXNjOiBBQyBBZGFwdGVy CmRldi5hY3BpX2FjYWQuMC4lZHJpdmVyOiBhY3BpX2FjYWQKZGV2LmFjcGlfYWNhZC4wLiVsb2Nh dGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTFBDXy5FQ19fLkFDX18KZGV2LmFjcGlfYWNhZC4wLiVw bnBpbmZvOiBfSElEPUFDUEkwMDAzIF9VSUQ9MApkZXYuYWNwaV9hY2FkLjAuJXBhcmVudDogYWNw aTAKZGV2LmFjcGlfaWJtLjAuJWRlc2M6IElCTSBUaGlua1BhZCBBQ1BJIEV4dHJhcwpkZXYuYWNw aV9pYm0uMC4lZHJpdmVyOiBhY3BpX2libQpkZXYuYWNwaV9pYm0uMC4lbG9jYXRpb246IGhhbmRs ZT1cX1NCXy5QQ0kwLkxQQ18uRUNfXy5IS0VZCmRldi5hY3BpX2libS4wLiVwbnBpbmZvOiBfSElE PUlCTTAwNjggX1VJRD0wCmRldi5hY3BpX2libS4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX2li bS4wLmluaXRpYWxtYXNrOiAyMDYwCmRldi5hY3BpX2libS4wLmF2YWlsbWFzazogMTY3NzcyMTUK ZGV2LmFjcGlfaWJtLjAuZXZlbnRzOiAwCmRldi5hY3BpX2libS4wLmV2ZW50bWFzazogMjA2MApk ZXYuYWNwaV9pYm0uMC5ob3RrZXk6IDIzMjIKZGV2LmFjcGlfaWJtLjAubGNkX2JyaWdodG5lc3M6 IDAKZGV2LmFjcGlfaWJtLjAudm9sdW1lOiAxMApkZXYuYWNwaV9pYm0uMC5tdXRlOiAxCmRldi5h Y3BpX2libS4wLnRoaW5rbGlnaHQ6IDAKZGV2LmFjcGlfaWJtLjAuYmx1ZXRvb3RoOiAwCmRldi5h Y3BpX2libS4wLndsYW46IDEKZGV2LmFjcGlfaWJtLjAuZmFuX3NwZWVkOiAzOTYxCmRldi5hY3Bp X2libS4wLmZhbl9sZXZlbDogNwpkZXYuYWNwaV9pYm0uMC5mYW46IDAKZGV2LmFjcGlfaWJtLjAu dGhlcm1hbDogNDYgNDUgMzQgNTEgMzYgLTEgMzEgLTEKZGV2LmNyeXB0b3NvZnQuMC4lZGVzYzog c29mdHdhcmUgY3J5cHRvCmRldi5jcnlwdG9zb2Z0LjAuJWRyaXZlcjogY3J5cHRvc29mdApkZXYu Y3J5cHRvc29mdC4wLiVwYXJlbnQ6IG5leHVzMApkZXYuYXBpYy4wLiVkZXNjOiBBUElDIHJlc291 cmNlcwpkZXYuYXBpYy4wLiVkcml2ZXI6IGFwaWMKZGV2LmFwaWMuMC4lcGFyZW50OiBuZXh1czAK ZGV2LmljaHdkLjAuJWRlc2M6IEludGVsIElDSDZNIHdhdGNoZG9nIHRpbWVyCmRldi5pY2h3ZC4w LiVkcml2ZXI6IGljaHdkCmRldi5pY2h3ZC4wLiVwYXJlbnQ6IGlzYTAKZGV2LnBtdGltZXIuMC4l ZHJpdmVyOiBwbXRpbWVyCmRldi5wbXRpbWVyLjAuJXBhcmVudDogaXNhMApkZXYub3JtLjAuJWRl c2M6IElTQSBPcHRpb24gUk9NcwpkZXYub3JtLjAuJWRyaXZlcjogb3JtCmRldi5vcm0uMC4lcG5w aW5mbzogcG5waWQ9T1JNMDAwMApkZXYub3JtLjAuJXBhcmVudDogaXNhMApkZXYuc2MuMC4lZGVz YzogU3lzdGVtIGNvbnNvbGUKZGV2LnNjLjAuJWRyaXZlcjogc2MKZGV2LnNjLjAuJXBhcmVudDog aXNhMApkZXYudmdhLjAuJWRlc2M6IEdlbmVyaWMgSVNBIFZHQQpkZXYudmdhLjAuJWRyaXZlcjog dmdhCmRldi52Z2EuMC4lcGFyZW50OiBpc2EwCmRldi51Z2VuLjAuJWRlc2M6IFNUTWljcm9lbGVj dHJvbmljcyBCaW9tZXRyaWMgQ29wcm9jZXNzb3IsIGNsYXNzIDAvMCwgcmV2IDEuMDAvMC4wMSwg YWRkciAyCmRldi51Z2VuLjAuJWRyaXZlcjogdWdlbgpkZXYudWdlbi4wLiVsb2NhdGlvbjogcG9y dD0xCmRldi51Z2VuLjAuJXBucGluZm86IHZlbmRvcj0weDA0ODMgcHJvZHVjdD0weDIwMTYgZGV2 Y2xhc3M9MHgwMCBkZXZzdWJjbGFzcz0weDAwIHJlbGVhc2U9MHgwMDAxIHNlcm51bT0iIgpkZXYu dWdlbi4wLiVwYXJlbnQ6IHVodWIyCmRldi5hZC4wLiVkZXNjOiBTVDkxMDAyMUEvMy4wNApkZXYu YWQuMC4lZHJpdmVyOiBhZApkZXYuYWQuMC4lcGFyZW50OiBhdGEwCmRldi5hY2QuMC4lZGVzYzog TUFUU0hJVEFEVkQtUkFNIFVKLTg1Mi9SQjAxCmRldi5hY2QuMC4lZHJpdmVyOiBhY2QKZGV2LmFj ZC4wLiVwYXJlbnQ6IGF0YTEKZGV2LnVtYXNzLjAuJWRlc2M6IHZlbmRvciAweDBkN2QgVVNCIERJ U0sgMjVYLCBjbGFzcyAwLzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMgpkZXYudW1hc3MuMC4lZHJp dmVyOiB1bWFzcwpkZXYudW1hc3MuMC4lbG9jYXRpb246IHBvcnQ9MiBpbnRlcmZhY2U9MApkZXYu dW1hc3MuMC4lcG5waW5mbzogdmVuZG9yPTB4MGQ3ZCBwcm9kdWN0PTB4MTkwMCBkZXZjbGFzcz0w eDAwIGRldnN1YmNsYXNzPTB4MDAgcmVsZWFzZT0weDAxMDAgc2VybnVtPSIwNzU0MTE5MTMxQkQi IGludGNsYXNzPTB4MDggaW50c3ViY2xhc3M9MHgwNgpkZXYudW1hc3MuMC4lcGFyZW50OiB1aHVi NAo= ------=_Part_56_30755184.1205803276757 Content-Type: application/octet-stream; name=sysctl-a-RELENG_7_0-ISO.log Content-Transfer-Encoding: base64 X-Attachment-Id: f_fdxos1nh Content-Disposition: attachment; filename=sysctl-a-RELENG_7_0-ISO.log a2Vybi5vc3R5cGU6IEZyZWVCU0QKa2Vybi5vc3JlbGVhc2U6IDcuMC1SRUxFQVNFCmtlcm4ub3Ny ZXZpc2lvbjogMTk5NTA2Cmtlcm4udmVyc2lvbjogRnJlZUJTRCA3LjAtUkVMRUFTRSAjMDogU3Vu IEZlYiAyNCAxOTo1OTo1MiBVVEMgMjAwOAogICAgcm9vdEBsb2dhbi5jc2UuYnVmZmFsby5lZHU6 L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQwoKa2Vybi5tYXh2bm9kZXM6IDEwMDAwMAprZXJu Lm1heHByb2M6IDYxNjQKa2Vybi5tYXhmaWxlczogMTIzMjgKa2Vybi5hcmdtYXg6IDI2MjE0NApr ZXJuLnNlY3VyZWxldmVsOiAtMQprZXJuLmhvc3RuYW1lOiBzZWtobWV0Lmh5YnJpZC1sYWIubmV0 Cmtlcm4uaG9zdGlkOiAyNTk0MjEwNDgwCmtlcm4uY2xvY2tyYXRlOiB7IGh6ID0gMTAwMCwgdGlj ayA9IDEwMDAsIHByb2ZoeiA9IDY2Niwgc3RhdGh6ID0gMTMzIH0Ka2Vybi5wb3NpeDF2ZXJzaW9u OiAyMDAxMTIKa2Vybi5uZ3JvdXBzOiAxNgprZXJuLmpvYl9jb250cm9sOiAxCmtlcm4uc2F2ZWRf aWRzOiAwCmtlcm4uYm9vdHRpbWU6IHsgc2VjID0gMTIwNTc5NzMyMywgdXNlYyA9IDIxOTYwNSB9 IE1vbiBNYXIgMTcgMjM6NDI6MDMgMjAwOAprZXJuLmRvbWFpbm5hbWU6IAprZXJuLm9zcmVsZGF0 ZTogNzAwMDU1Cmtlcm4uYm9vdGZpbGU6IC9ib290L2tlcm5lbC9rZXJuZWwKa2Vybi5tYXhmaWxl c3BlcnByb2M6IDExMDk1Cmtlcm4ubWF4cHJvY3BlcnVpZDogNTU0NwprZXJuLmlwYy5tYXhzb2Nr YnVmOiAyNjIxNDQKa2Vybi5pcGMuc29ja2J1Zl93YXN0ZV9mYWN0b3I6IDgKa2Vybi5pcGMuc29t YXhjb25uOiAxMjgKa2Vybi5pcGMubWF4X2xpbmtoZHI6IDQwCmtlcm4uaXBjLm1heF9wcm90b2hk cjogNjAKa2Vybi5pcGMubWF4X2hkcjogMTAwCmtlcm4uaXBjLm1heF9kYXRhbGVuOiAxMDQKa2Vy bi5pcGMubm1ianVtYm8xNjogMzIwMAprZXJuLmlwYy5ubWJqdW1ibzk6IDY0MDAKa2Vybi5pcGMu bm1ianVtYm9wOiAxMjgwMAprZXJuLmlwYy5ubWJjbHVzdGVyczogMjU2MDAKa2Vybi5pcGMucGlw ZXJlc2l6ZWFsbG93ZWQ6IDEKa2Vybi5pcGMucGlwZXJlc2l6ZWZhaWw6IDAKa2Vybi5pcGMucGlw ZWFsbG9jZmFpbDogMAprZXJuLmlwYy5waXBlZnJhZ3JldHJ5OiAwCmtlcm4uaXBjLnBpcGVrdmE6 IDIwNDgwCmtlcm4uaXBjLm1heHBpcGVrdmE6IDE2Nzc3MjE2Cmtlcm4uaXBjLm1zZ3NlZzogMjA0 OAprZXJuLmlwYy5tc2dzc3o6IDgKa2Vybi5pcGMubXNndHFsOiA0MAprZXJuLmlwYy5tc2dtbmI6 IDIwNDgKa2Vybi5pcGMubXNnbW5pOiA0MAprZXJuLmlwYy5tc2dtYXg6IDE2Mzg0Cmtlcm4uaXBj LnNlbWFlbTogMTYzODQKa2Vybi5pcGMuc2Vtdm14OiAzMjc2NwprZXJuLmlwYy5zZW11c3o6IDky Cmtlcm4uaXBjLnNlbXVtZTogMTAKa2Vybi5pcGMuc2Vtb3BtOiAxMDAKa2Vybi5pcGMuc2VtbXNs OiA2MAprZXJuLmlwYy5zZW1tbnU6IDMwCmtlcm4uaXBjLnNlbW1uczogNjAKa2Vybi5pcGMuc2Vt bW5pOiAxMAprZXJuLmlwYy5zZW1tYXA6IDMwCmtlcm4uaXBjLnNobV9hbGxvd19yZW1vdmVkOiAw Cmtlcm4uaXBjLnNobV91c2VfcGh5czogMAprZXJuLmlwYy5zaG1hbGw6IDgxOTIKa2Vybi5pcGMu c2htc2VnOiAxMjgKa2Vybi5pcGMuc2htbW5pOiAxOTIKa2Vybi5pcGMuc2htbWluOiAxCmtlcm4u aXBjLnNobW1heDogMzM1NTQ0MzIKa2Vybi5pcGMubWF4c29ja2V0czogMTIzMjgKa2Vybi5pcGMu bnVtb3BlbnNvY2tldHM6IDEwCmtlcm4uaXBjLm5zZmJ1ZnN1c2VkOiAwCmtlcm4uaXBjLm5zZmJ1 ZnNwZWFrOiAzCmtlcm4uaXBjLm5zZmJ1ZnM6IDY2NTYKa2Vybi5kdW1teTogMAprZXJuLnBzX3N0 cmluZ3M6IDMyMTcwMzExNTIKa2Vybi51c3JzdGFjazogMzIxNzAzMTE2OAprZXJuLmxvZ3NpZ2V4 aXQ6IDEKa2Vybi5pb3ZfbWF4OiAxMDI0Cmtlcm4uaG9zdHV1aWQ6IGRkZTI5MDAxLTQ4OTktMTFj Yi1iODE4LTgzNjhhZjQ0YjEwMQprZXJuLmFyYW5kb206IC0yMTM0Njg4OTM2Cmtlcm4uY2FtLmNh bV9zcmNoX2hpOiAwCmtlcm4uY2FtLnNjc2lfZGVsYXk6IDUwMDAKa2Vybi5jYW0uY2QuY2hhbmdl ci5tYXhfYnVzeV9zZWNvbmRzOiAxNQprZXJuLmNhbS5jZC5jaGFuZ2VyLm1pbl9idXN5X3NlY29u ZHM6IDUKa2Vybi5jYW0uZGEuZGFfc2VuZF9vcmRlcmVkOiAxCmtlcm4uY2FtLmRhLmRlZmF1bHRf dGltZW91dDogNjAKa2Vybi5jYW0uZGEucmV0cnlfY291bnQ6IDQKa2Vybi5jYW0uZGEuMC5taW5p bXVtX2NtZF9zaXplOiAxMAprZXJuLmRjb25zLnBvbGxfaHo6IDEwMAprZXJuLmRpc2tzOiBkYTAg YWQwCmtlcm4uZ2VvbS5jb2xsZWN0c3RhdHM6IDEKa2Vybi5nZW9tLmRlYnVnZmxhZ3M6IDAKa2Vy bi5nZW9tLmxhYmVsLmRlYnVnOiAwCmtlcm4uZWxmMzIuZmFsbGJhY2tfYnJhbmQ6IC0xCmtlcm4u aW5pdF9zaHV0ZG93bl90aW1lb3V0OiAxMjAKa2Vybi5pbml0X3BhdGg6IC9zYmluL2luaXQ6L3Ni aW4vb2luaXQ6L3NiaW4vaW5pdC5iYWs6L3Jlc2N1ZS9pbml0Oi9zdGFuZC9zeXNpbnN0YWxsCmtl cm4uYWNjdF9zdXNwZW5kZWQ6IDAKa2Vybi5hY2N0X2NvbmZpZ3VyZWQ6IDAKa2Vybi5hY2N0X2No a2ZyZXE6IDE1Cmtlcm4uYWNjdF9yZXN1bWU6IDQKa2Vybi5hY2N0X3N1c3BlbmQ6IDIKa2Vybi5j cF90aW1lOiA1MCAwIDEyMSA1IDI1NDkzCmtlcm4ub3BlbmZpbGVzOiA0OQprZXJuLmtxX2NhbGxv dXRtYXg6IDQwOTYKa2Vybi5wc19hcmdfY2FjaGVfbGltaXQ6IDI1NgprZXJuLnN0YWNrcHJvdDog NwprZXJuLnJhbmRvbXBpZDogMAprZXJuLmxhc3RwaWQ6IDkwNQprZXJuLmt0cmFjZS5yZXF1ZXN0 X3Bvb2w6IDEwMAprZXJuLmt0cmFjZS5nZW5pb19zaXplOiA0MDk2Cmtlcm4ubW9kdWxlX3BhdGg6 IC9ib290L2tlcm5lbDsvYm9vdC9tb2R1bGVzCmtlcm4ubWFsbG9jX2NvdW50OiAyNDIKa2Vybi5m YWxsYmFja19lbGZfYnJhbmQ6IC0xCmtlcm4ubWF4dXNlcnM6IDM4NAprZXJuLmlkZW50OiBHRU5F UklDCmtlcm4ua3N0YWNrX3BhZ2VzOiAyCmtlcm4uc2h1dGRvd24ua3Byb2Nfc2h1dGRvd25fd2Fp dDogNjAKa2Vybi5zaHV0ZG93bi5wb3dlcm9mZl9kZWxheTogNTAwMAprZXJuLnN5bmNfb25fcGFu aWM6IDAKa2Vybi5jb3JlZmlsZTogJU4uY29yZQprZXJuLm5vZHVtcF9jb3JlZHVtcDogMAprZXJu LmNvcmVkdW1wOiAxCmtlcm4uc3VnaWRfY29yZWR1bXA6IDAKa2Vybi5zaWdxdWV1ZS5hbGxvY19m YWlsOiAwCmtlcm4uc2lncXVldWUub3ZlcmZsb3c6IDAKa2Vybi5zaWdxdWV1ZS5wcmVhbGxvY2F0 ZTogMTAyNAprZXJuLnNpZ3F1ZXVlLm1heF9wZW5kaW5nX3Blcl9wcm9jOiAxMjgKa2Vybi5mb3Jj ZXNpZ2V4aXQ6IDEKa2Vybi5mc2NhbGU6IDIwNDgKa2Vybi50aW1lY291bnRlci50aWNrOiAxCmtl cm4udGltZWNvdW50ZXIuY2hvaWNlOiBUU0MoODAwKSBBQ1BJLWZhc3QoMTAwMCkgaTgyNTQoMCkg ZHVtbXkoLTEwMDAwMDApCmtlcm4udGltZWNvdW50ZXIuaGFyZHdhcmU6IEFDUEktZmFzdAprZXJu LnRpbWVjb3VudGVyLm5zZXRjbG9jazogMgprZXJuLnRpbWVjb3VudGVyLm5nZXRtaWNyb3RpbWU6 IDMzODMwCmtlcm4udGltZWNvdW50ZXIubmdldG5hbm90aW1lOiAxMAprZXJuLnRpbWVjb3VudGVy Lm5nZXRiaW50aW1lOiAwCmtlcm4udGltZWNvdW50ZXIubmdldG1pY3JvdXB0aW1lOiA1NTA2Cmtl cm4udGltZWNvdW50ZXIubmdldG5hbm91cHRpbWU6IDM4Cmtlcm4udGltZWNvdW50ZXIubmdldGJp bnVwdGltZTogNDAyCmtlcm4udGltZWNvdW50ZXIubm1pY3JvdGltZTogMjEyMTkKa2Vybi50aW1l Y291bnRlci5ubmFub3RpbWU6IDIyCmtlcm4udGltZWNvdW50ZXIubmJpbnRpbWU6IDIxMjQxCmtl cm4udGltZWNvdW50ZXIubm1pY3JvdXB0aW1lOiA5NTIKa2Vybi50aW1lY291bnRlci5ubmFub3Vw dGltZTogMgprZXJuLnRpbWVjb3VudGVyLm5iaW51cHRpbWU6IDMzODQwCmtlcm4udGltZWNvdW50 ZXIuc3RlcHdhcm5pbmdzOiAwCmtlcm4udGltZWNvdW50ZXIudGMuaTgyNTQubWFzazogNjU1MzUK a2Vybi50aW1lY291bnRlci50Yy5pODI1NC5jb3VudGVyOiA0MjYwCmtlcm4udGltZWNvdW50ZXIu dGMuaTgyNTQuZnJlcXVlbmN5OiAxMTkzMTgyCmtlcm4udGltZWNvdW50ZXIudGMuaTgyNTQucXVh bGl0eTogMAprZXJuLnRpbWVjb3VudGVyLnRjLkFDUEktZmFzdC5tYXNrOiAxNjc3NzIxNQprZXJu LnRpbWVjb3VudGVyLnRjLkFDUEktZmFzdC5jb3VudGVyOiA0ODgzNzkyCmtlcm4udGltZWNvdW50 ZXIudGMuQUNQSS1mYXN0LmZyZXF1ZW5jeTogMzU3OTU0NQprZXJuLnRpbWVjb3VudGVyLnRjLkFD UEktZmFzdC5xdWFsaXR5OiAxMDAwCmtlcm4udGltZWNvdW50ZXIudGMuVFNDLm1hc2s6IDQyOTQ5 NjcyOTUKa2Vybi50aW1lY291bnRlci50Yy5UU0MuY291bnRlcjogNzczNDg4MjY3Cmtlcm4udGlt ZWNvdW50ZXIudGMuVFNDLmZyZXF1ZW5jeTogMjI2MTE1OTYyNwprZXJuLnRpbWVjb3VudGVyLnRj LlRTQy5xdWFsaXR5OiA4MDAKa2Vybi50aW1lY291bnRlci5zbXBfdHNjOiAwCmtlcm4udGhyZWFk cy52aXJ0dWFsX2NwdTogMQprZXJuLnRocmVhZHMubWF4X3RocmVhZHNfaGl0czogMAprZXJuLnRo cmVhZHMubWF4X3RocmVhZHNfcGVyX3Byb2M6IDE1MDAKa2Vybi5jY3B1OiAxOTQ4Cmtlcm4uc2No ZWQucnVucV9mdXp6OiAxCmtlcm4uc2NoZWQucHJlZW1wdGlvbjogMQprZXJuLnNjaGVkLmlwaXdh a2V1cC5odHQyOiAwCmtlcm4uc2NoZWQuaXBpd2FrZXVwLm9uZWNwdTogMAprZXJuLnNjaGVkLmlw aXdha2V1cC51c2Vsb29wOiAwCmtlcm4uc2NoZWQuaXBpd2FrZXVwLnVzZW1hc2s6IDEKa2Vybi5z Y2hlZC5pcGl3YWtldXAuZGVsaXZlcmVkOiAwCmtlcm4uc2NoZWQuaXBpd2FrZXVwLnJlcXVlc3Rl ZDogMAprZXJuLnNjaGVkLmlwaXdha2V1cC5lbmFibGVkOiAxCmtlcm4uc2NoZWQucXVhbnR1bTog MTAwMDAwCmtlcm4uc2NoZWQubmFtZTogNEJTRAprZXJuLmRldnN0YXQudmVyc2lvbjogNgprZXJu LmRldnN0YXQuZ2VuZXJhdGlvbjogMzUzCmtlcm4uZGV2c3RhdC5udW1kZXZzOiAzCmtlcm4ua29i al9tZXRob2Rjb3VudDogMTYzCmtlcm4ubG9nX3dha2V1cHNfcGVyX3NlY29uZDogNQprZXJuLm1z Z2J1Zl9jbGVhcjogMAprZXJuLm1zZ2J1ZjogCmtlcm4uYWx3YXlzX2NvbnNvbGVfb3V0cHV0OiAw Cmtlcm4ubG9nX2NvbnNvbGVfb3V0cHV0OiAxCmtlcm4uc21wLmZvcndhcmRfcm91bmRyb2Jpbl9l bmFibGVkOiAxCmtlcm4uc21wLmZvcndhcmRfc2lnbmFsX2VuYWJsZWQ6IDEKa2Vybi5zbXAuY3B1 czogMQprZXJuLnNtcC5kaXNhYmxlZDogMAprZXJuLnNtcC5hY3RpdmU6IDAKa2Vybi5zbXAubWF4 Y3B1czogMTYKa2Vybi5uc2VsY29sbDogMAprZXJuLnR0eV9ub3V0OiAyMDIxMAprZXJuLnR0eV9u aW46IDM2OQprZXJuLmRyYWlud2FpdDogMzAwCmtlcm4uY29uc3R0eV93YWtldXBzX3Blcl9zZWNv bmQ6IDUKa2Vybi5jb25zbXNnYnVmX3NpemU6IDgxOTIKa2Vybi5jb25zbXV0ZTogMAprZXJuLmNv bnNvbGU6IGNvbnNvbGVjdGwsZGNvbnMsL2Rjb25zLGNvbnNvbGVjdGwsdHR5ZDAsCmtlcm4ubWlu dm5vZGVzOiAyNTAwMAprZXJuLm1ldGFkZWxheTogMjgKa2Vybi5kaXJkZWxheTogMjkKa2Vybi5m aWxlZGVsYXk6IDMwCmtlcm4uY2hyb290X2FsbG93X29wZW5fZGlyZWN0b3JpZXM6IDEKa2Vybi5y cGMuaW52YWxpZDogMAprZXJuLnJwYy51bmV4cGVjdGVkOiAwCmtlcm4ucnBjLnRpbWVvdXRzOiAw Cmtlcm4ucnBjLnJlcXVlc3Q6IDAKa2Vybi5ycGMucmV0cmllczogMAprZXJuLnJhbmRvbS55YXJy b3cuZ2VuZ2F0ZWludGVydmFsOiAxMAprZXJuLnJhbmRvbS55YXJyb3cuYmluczogMTAKa2Vybi5y YW5kb20ueWFycm93LmZhc3R0aHJlc2g6IDE5MgprZXJuLnJhbmRvbS55YXJyb3cuc2xvd3RocmVz aDogMjU2Cmtlcm4ucmFuZG9tLnlhcnJvdy5zbG93b3ZlcnRocmVzaDogMgprZXJuLnJhbmRvbS5z eXMuc2VlZGVkOiAxCmtlcm4ucmFuZG9tLnN5cy5oYXJ2ZXN0LmV0aGVybmV0OiAxCmtlcm4ucmFu ZG9tLnN5cy5oYXJ2ZXN0LnBvaW50X3RvX3BvaW50OiAxCmtlcm4ucmFuZG9tLnN5cy5oYXJ2ZXN0 LmludGVycnVwdDogMQprZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5zd2k6IDAKdm0udm10b3RhbDog ClN5c3RlbSB3aWRlIHRvdGFscyBjb21wdXRlZCBldmVyeSBmaXZlIHNlY29uZHM6ICh2YWx1ZXMg aW4ga2lsb2J5dGVzKQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQpQcm9jZXNzZXM6CQkoUlVOUTogMSBEaXNrIFdhaXQ6IDAgUGFnZSBXYWl0OiAwIFNsZWVw OiAxNikKVmlydHVhbCBNZW1vcnk6CQkoVG90YWw6IDIxODE2NzZLLCBBY3RpdmUgNDU3MjhLKQpS ZWFsIE1lbW9yeToJCShUb3RhbDogMjI4NjBLIEFjdGl2ZSA5MDA4SykKU2hhcmVkIFZpcnR1YWwg TWVtb3J5OgkoVG90YWw6IDU5NzJLIEFjdGl2ZTogMjc5MkspClNoYXJlZCBSZWFsIE1lbW9yeToJ KFRvdGFsOiAzOTI4SyBBY3RpdmU6IDI2MzZLKQpGcmVlIE1lbW9yeSBQYWdlczoJMjAxNzY3NksK CnZtLmxvYWRhdmc6IHsgMC4wOSAwLjI0IDAuMTMgfQp2bS52X2ZyZWVfbWluOiAzMjcxCnZtLnZf ZnJlZV90YXJnZXQ6IDEzNzk5CnZtLnZfZnJlZV9yZXNlcnZlZDogNzE1CnZtLnZfaW5hY3RpdmVf dGFyZ2V0OiAyMDY5OAp2bS52X2NhY2hlX21pbjogMTM3OTkKdm0udl9jYWNoZV9tYXg6IDI3NTk4 CnZtLnZfcGFnZW91dF9mcmVlX21pbjogMzQKdm0ucGFnZW91dF9hbGdvcml0aG06IDAKdm0uc3dh cF9lbmFibGVkOiAxCnZtLmttZW1fc2l6ZV9zY2FsZTogMwp2bS5rbWVtX3NpemVfbWF4OiAzMzU1 NDQzMjAKdm0ua21lbV9zaXplX21pbjogMAp2bS5rbWVtX3NpemU6IDMzNTU0NDMyMAp2bS5uc3dh cGRldjogMQp2bS5kbW1heDogMzIKdm0uc3dhcF9hc3luY19tYXg6IDQKdm0uem9uZV9jb3VudDog ODIKdm0uc3dhcF9pZGxlX3RocmVzaG9sZDI6IDEwCnZtLnN3YXBfaWRsZV90aHJlc2hvbGQxOiAy CnZtLmV4ZWNfbWFwX2VudHJpZXM6IDE2CnZtLnN0YXRzLm1pc2MuemVyb19wYWdlX2NvdW50OiAw CnZtLnN0YXRzLm1pc2MuY250X3ByZXplcm86IDAKdm0uc3RhdHMudm0udl9rdGhyZWFkcGFnZXM6 IDAKdm0uc3RhdHMudm0udl9yZm9ya3BhZ2VzOiAwCnZtLnN0YXRzLnZtLnZfdmZvcmtwYWdlczog NDEwOAp2bS5zdGF0cy52bS52X2ZvcmtwYWdlczogMTU1ODEyCnZtLnN0YXRzLnZtLnZfa3RocmVh ZHM6IDU0CnZtLnN0YXRzLnZtLnZfcmZvcmtzOiAwCnZtLnN0YXRzLnZtLnZfdmZvcmtzOiAyMgp2 bS5zdGF0cy52bS52X2ZvcmtzOiA4MjkKdm0uc3RhdHMudm0udl9pbnRlcnJ1cHRfZnJlZV9taW46 IDIKdm0uc3RhdHMudm0udl9wYWdlb3V0X2ZyZWVfbWluOiAzNAp2bS5zdGF0cy52bS52X2NhY2hl X21heDogMjc1OTgKdm0uc3RhdHMudm0udl9jYWNoZV9taW46IDEzNzk5CnZtLnN0YXRzLnZtLnZf Y2FjaGVfY291bnQ6IDEKdm0uc3RhdHMudm0udl9pbmFjdGl2ZV9jb3VudDogMTE5Nwp2bS5zdGF0 cy52bS52X2luYWN0aXZlX3RhcmdldDogMjA2OTgKdm0uc3RhdHMudm0udl9hY3RpdmVfY291bnQ6 IDE1MzYKdm0uc3RhdHMudm0udl93aXJlX2NvdW50OiA0MjUyCnZtLnN0YXRzLnZtLnZfZnJlZV9j b3VudDogNTA0NDE3CnZtLnN0YXRzLnZtLnZfZnJlZV9taW46IDMyNzEKdm0uc3RhdHMudm0udl9m cmVlX3RhcmdldDogMTM3OTkKdm0uc3RhdHMudm0udl9mcmVlX3Jlc2VydmVkOiA3MTUKdm0uc3Rh dHMudm0udl9wYWdlX2NvdW50OiA1MTE0ODIKdm0uc3RhdHMudm0udl9wYWdlX3NpemU6IDQwOTYK dm0uc3RhdHMudm0udl90ZnJlZTogNDQ2MDcKdm0uc3RhdHMudm0udl9wZnJlZTogMjY1NzcKdm0u c3RhdHMudm0udl9kZnJlZTogMAp2bS5zdGF0cy52bS52X3RjYWNoZWQ6IDIxCnZtLnN0YXRzLnZt LnZfcGRwYWdlczogMAp2bS5zdGF0cy52bS52X3Bkd2FrZXVwczogMAp2bS5zdGF0cy52bS52X3Jl YWN0aXZhdGVkOiAyMAp2bS5zdGF0cy52bS52X2ludHJhbnM6IDMKdm0uc3RhdHMudm0udl92bm9k ZXBnc291dDogMAp2bS5zdGF0cy52bS52X3Zub2RlcGdzaW46IDEzMzQKdm0uc3RhdHMudm0udl92 bm9kZW91dDogMAp2bS5zdGF0cy52bS52X3Zub2RlaW46IDIxNAp2bS5zdGF0cy52bS52X3N3YXBw Z3NvdXQ6IDAKdm0uc3RhdHMudm0udl9zd2FwcGdzaW46IDAKdm0uc3RhdHMudm0udl9zd2Fwb3V0 OiAwCnZtLnN0YXRzLnZtLnZfc3dhcGluOiAwCnZtLnN0YXRzLnZtLnZfb3pmb2Q6IDY4Mwp2bS5z dGF0cy52bS52X3pmb2Q6IDE1OTQ4CnZtLnN0YXRzLnZtLnZfY293X29wdGltOiAxNzkKdm0uc3Rh dHMudm0udl9jb3dfZmF1bHRzOiAyMTg5Mgp2bS5zdGF0cy52bS52X3ZtX2ZhdWx0czogNTA3MDkK dm0uc3RhdHMuc3lzLnZfc29mdDogMjg1MzQKdm0uc3RhdHMuc3lzLnZfaW50cjogMjY3Mgp2bS5z dGF0cy5zeXMudl9zeXNjYWxsOiA5NzI0NAp2bS5zdGF0cy5zeXMudl90cmFwOiA1NjM1MQp2bS5z dGF0cy5zeXMudl9zd3RjaDogODcxNTYKdm0uc3RhdHMub2JqZWN0LmJ5cGFzc2VzOiAyODEKdm0u c3RhdHMub2JqZWN0LmNvbGxhcHNlczogMjQ3MAp2bS52X2ZyZWVfc2V2ZXJlOiAxOTkzCnZtLm1h eF9wcm9jX21tYXA6IDQ5MzQ0CnZtLm9sZF9tc3luYzogMAp2bS5tc3luY19mbHVzaF9mbGFnczog Mwp2bS5ib290X3BhZ2VzOiA0OAp2bS5wYWdlb3V0X2xvY2tfbWlzczogMAp2bS5kaXNhYmxlX3N3 YXBzcGFjZV9wYWdlb3V0czogMAp2bS5kZWZlcl9zd2Fwc3BhY2VfcGFnZW91dHM6IDAKdm0uc3dh cF9pZGxlX2VuYWJsZWQ6IDAKdm0ucGFnZW91dF9zdGF0c19pbnRlcnZhbDogNQp2bS5wYWdlb3V0 X2Z1bGxfc3RhdHNfaW50ZXJ2YWw6IDIwCnZtLnBhZ2VvdXRfc3RhdHNfbWF4OiAxMzc5OQp2bS5t YXhfbGF1bmRlcjogMzIKdm0ucGh5c19zZWdzOiAKU0VHTUVOVCAwOgoKc3RhcnQ6ICAgICAweDEw MDAKZW5kOiAgICAgICAweDllMDAwCmZyZWUgbGlzdDogMHhjMGJlZGM0OAoKU0VHTUVOVCAxOgoK c3RhcnQ6ICAgICAweDEwMDAwMAplbmQ6ICAgICAgIDB4NDAwMDAwCmZyZWUgbGlzdDogMHhjMGJl ZGM0OAoKU0VHTUVOVCAyOgoKc3RhcnQ6ICAgICAweDEwMjgwMDAKZW5kOiAgICAgICAweDdkYTg1 MDAwCmZyZWUgbGlzdDogMHhjMGJlZGI0MAoKdm0ucGh5c19mcmVlOiAKRlJFRSBMSVNUIDA6Cgog IE9SREVSIChTSVpFKSAgfCAgTlVNQkVSCiAgICAgICAgICAgICAgICB8ICBQT09MIDAgIHwgIFBP T0wgMQotLSAgICAgICAgICAgIC0tIC0tICAgICAgLS0gLS0gICAgICAtLQogIDEwICggIDQwOTZL KSAgfCAgICAgNDkxICB8ICAgICAgIDAKICAgOSAoICAyMDQ4SykgIHwgICAgICAgMSAgfCAgICAg ICAwCiAgIDggKCAgMTAyNEspICB8ICAgICAgIDAgIHwgICAgICAgMAogICA3ICggICA1MTJLKSAg fCAgICAgICAxICB8ICAgICAgIDAKICAgNiAoICAgMjU2SykgIHwgICAgICAgMCAgfCAgICAgICAw CiAgIDUgKCAgIDEyOEspICB8ICAgICAgIDEgIHwgICAgICAgMAogICA0ICggICAgNjRLKSAgfCAg ICAgICAyICB8ICAgICAgIDAKICAgMyAoICAgIDMySykgIHwgICAgICAgMCAgfCAgICAgICAwCiAg IDIgKCAgICAxNkspICB8ICAgICAgIDEgIHwgICAgICAgMAogICAxICggICAgIDhLKSAgfCAgICAg ICAwICB8ICAgICAgIDAKICAgMCAoICAgICA0SykgIHwgICAgICAgMCAgfCAgICAgICAxCgpGUkVF IExJU1QgMToKCiAgT1JERVIgKFNJWkUpICB8ICBOVU1CRVIKICAgICAgICAgICAgICAgIHwgIFBP T0wgMCAgfCAgUE9PTCAxCi0tICAgICAgICAgICAgLS0gLS0gICAgICAtLSAtLSAgICAgIC0tCiAg MTAgKCAgNDA5NkspICB8ICAgICAgIDAgIHwgICAgICAgMAogICA5ICggIDIwNDhLKSAgfCAgICAg ICAxICB8ICAgICAgIDAKICAgOCAoICAxMDI0SykgIHwgICAgICAgMSAgfCAgICAgICAwCiAgIDcg KCAgIDUxMkspICB8ICAgICAgIDAgIHwgICAgICAgMAogICA2ICggICAyNTZLKSAgfCAgICAgICAx ICB8ICAgICAgIDAKICAgNSAoICAgMTI4SykgIHwgICAgICAgMSAgfCAgICAgICAwCiAgIDQgKCAg ICA2NEspICB8ICAgICAgIDIgIHwgICAgICAgMAogICAzICggICAgMzJLKSAgfCAgICAgICAyICB8 ICAgICAgIDAKICAgMiAoICAgIDE2SykgIHwgICAgICAgMiAgfCAgICAgICAwCiAgIDEgKCAgICAg OEspICB8ICAgICAgIDIgIHwgICAgICAgMAogICAwICggICAgIDRLKSAgfCAgICAgICAwICB8ICAg ICAgIDAKCnZtLmlkbGV6ZXJvX2VuYWJsZTogMAp2bS5rdm1fZnJlZTogNDAyNjQ5MDg4CnZtLmt2 bV9zaXplOiAxMDY5NTQzNDI0CnZtLnBtYXAucG1hcF9jb2xsZWN0X2FjdGl2ZTogMAp2bS5wbWFw LnBtYXBfY29sbGVjdF9pbmFjdGl2ZTogMAp2bS5wbWFwLnB2X2VudHJ5X3NwYXJlOiAyNTg4CnZt LnBtYXAucHZfZW50cnlfYWxsb2NzOiA0MDY4NDAKdm0ucG1hcC5wdl9lbnRyeV9mcmVlczogNDAw NjkyCnZtLnBtYXAucGNfY2h1bmtfdHJ5ZmFpbDogMAp2bS5wbWFwLnBjX2NodW5rX2ZyZWVzOiAy MDk4CnZtLnBtYXAucGNfY2h1bmtfYWxsb2NzOiAyMTI0CnZtLnBtYXAucGNfY2h1bmtfY291bnQ6 IDI2CnZtLnBtYXAucHZfZW50cnlfY291bnQ6IDYxNDgKdm0ucG1hcC5zaHBncGVycHJvYzogMjAw CnZtLnBtYXAucHZfZW50cnlfbWF4OiAxNzQ0NTEyCnZmcy5uZnMuZG93bmRlbGF5aW5pdGlhbDog MTIKdmZzLm5mcy5kb3duZGVsYXlpbnRlcnZhbDogMzAKdmZzLm5mcy5za2lwX3djY19kYXRhX29u ZXJyOiAxCnZmcy5uZnMubmZzM19qdWtlYm94X2RlbGF5OiAxMAp2ZnMubmZzLnJlY29ubmVjdHM6 IDAKdmZzLm5mcy5idWZwYWNrZXRzOiA0CnZmcy5uZnMucmVhbGlnbl9jb3VudDogMAp2ZnMubmZz LnJlYWxpZ25fdGVzdDogMAp2ZnMubmZzLmRlZmVjdDogMAp2ZnMubmZzLmlvZG1heDogMjAKdmZz Lm5mcy5pb2RtaW46IDAKdmZzLm5mcy5pb2RtYXhpZGxlOiAxMjAKdmZzLm5mcy5kaXNrbGVzc19y b290cGF0aDogCnZmcy5uZnMuZGlza2xlc3NfdmFsaWQ6IDAKdmZzLm5mcy5uZnNfaXBfcGFyYW5v aWE6IDEKdmZzLm5mcy5uZnNfZGlyZWN0aW9fYWxsb3dfbW1hcDogMQp2ZnMubmZzLm5mc19kaXJl Y3Rpb19lbmFibGU6IDAKdmZzLm5mcy5jbGVhbl9wYWdlc19vbl9jbG9zZTogMQp2ZnMubmZzLm5m c3YzX2NvbW1pdF9vbl9jbG9zZTogMAp2ZnMubmZzLmFjY2Vzc19jYWNoZV90aW1lb3V0OiA2MAp2 ZnMuZGV2ZnMucnVsZV9kZXB0aDogMQp2ZnMuZGV2ZnMuZ2VuZXJhdGlvbjogMTM0CnZmcy51ZnMu ZGlyaGFzaF9kb2NoZWNrOiAwCnZmcy51ZnMuZGlyaGFzaF9tZW06IDM1ODUwCnZmcy51ZnMuZGly aGFzaF9tYXhtZW06IDIwOTcxNTIKdmZzLnVmcy5kaXJoYXNoX21pbnNpemU6IDI1NjAKdmZzLm5m czQuYWNjZXNzX2NhY2hlX3RpbWVvdXQ6IDYwCnZmcy5wZnMudHJhY2U6IDAKdmZzLnBmcy52bmNh Y2hlLm1pc3NlczogMAp2ZnMucGZzLnZuY2FjaGUuaGl0czogMAp2ZnMucGZzLnZuY2FjaGUubWF4 ZW50cmllczogMAp2ZnMucGZzLnZuY2FjaGUuZW50cmllczogMAp2ZnMuZmx1c2h3aXRoZGVwczog MAp2ZnMuZ2V0bmV3YnVmcmVzdGFydHM6IDAKdmZzLmdldG5ld2J1ZmNhbGxzOiA1MzAKdmZzLmhp ZnJlZWJ1ZmZlcnM6IDgwOAp2ZnMubG9mcmVlYnVmZmVyczogNDA0CnZmcy5udW1mcmVlYnVmZmVy czogNzE4Mgp2ZnMuZGlydHlidWZ0aHJlc2g6IDE2MzcKdmZzLmhpZGlydHlidWZmZXJzOiAxODE5 CnZmcy5sb2RpcnR5YnVmZmVyczogOTA5CnZmcy5udW1kaXJ0eWJ1ZmZlcnM6IDE2CnZmcy5yZWN1 cnNpdmVmbHVzaGVzOiAwCnZmcy5hbHRidWZmZXJmbHVzaGVzOiAwCnZmcy5iZHdyaXRlc2tpcDog MAp2ZnMuZGlydHlidWZmZXJmbHVzaGVzOiAwCnZmcy5oaXJ1bm5pbmdzcGFjZTogMTA0ODU3Ngp2 ZnMubG9ydW5uaW5nc3BhY2U6IDUyNDI4OAp2ZnMuYnVmZGVmcmFnY250OiAwCnZmcy5idWZmcmVl a3ZhY250OiAwCnZmcy5idWZyZXVzZWNudDogNDk3CnZmcy5oaWJ1ZnNwYWNlOiAxMTcyNzY2NzIK dmZzLmxvYnVmc3BhY2U6IDExNzIxMTEzNgp2ZnMubWF4bWFsbG9jYnVmc3BhY2U6IDU4NjM4MzMK dmZzLmJ1Zm1hbGxvY3NwYWNlOiA4Mzk2OAp2ZnMubWF4YnVmc3BhY2U6IDExNzkzMjAzMgp2ZnMu YnVmc3BhY2U6IDgxNDI4NDgKdmZzLnJ1bm5pbmdidWZzcGFjZTogMAp2ZnMudm1pb2RpcmVuYWJs ZTogMQp2ZnMuY2FjaGUubnVtZnVsbHBhdGhmb3VuZDogMzcKdmZzLmNhY2hlLm51bWZ1bGxwYXRo ZmFpbDQ6IDAKdmZzLmNhY2hlLm51bWZ1bGxwYXRoZmFpbDI6IDAKdmZzLmNhY2hlLm51bWZ1bGxw YXRoZmFpbDE6IDAKdmZzLmNhY2hlLm51bWZ1bGxwYXRoY2FsbHM6IDM3CnZmcy5jYWNoZS5uY2hz dGF0czogMTA2NTIgMTE0MyA0OSAwIDg4OCAwIDE0IDEyNAp2ZnMuY2FjaGUubnVtbmVnaGl0czog MTE0Mwp2ZnMuY2FjaGUubnVtbmVnemFwczogMjIKdmZzLmNhY2hlLm51bXBvc2hpdHM6IDEwNjUy CnZmcy5jYWNoZS5udW1wb3N6YXBzOiAyNwp2ZnMuY2FjaGUubnVtbWlzc3phcDogMjMKdmZzLmNh Y2hlLm51bW1pc3M6IDg2NQp2ZnMuY2FjaGUubnVtY2hlY2tzOiAxMTg0NAp2ZnMuY2FjaGUuZG90 ZG90aGl0czogMTMKdmZzLmNhY2hlLmRvdGhpdHM6IDY1CnZmcy5jYWNoZS5udW1jYWxsczogMTI4 MTAKdmZzLmNhY2hlLm51bWNhY2hlOiAzOTIKdmZzLmNhY2hlLm51bW5lZzogMjQKdmZzLnJlYWRf bWF4OiA4CnZmcy53cml0ZV9iZWhpbmQ6IDEKdmZzLmxvb2t1cF9zaGFyZWQ6IDAKdmZzLnVzZXJt b3VudDogMAp2ZnMud29ya2xpc3RfbGVuOiA2CnZmcy50aW1lc3RhbXBfcHJlY2lzaW9uOiAwCnZm cy5yZWFzc2lnbmJ1ZmNhbGxzOiAzNzYKdmZzLmZyZWV2bm9kZXM6IDE3CnZmcy53YW50ZnJlZXZu b2RlczogMjUwMDAKdmZzLm51bXZub2RlczogNDE5CnZmcy5uZnNydi5uZnNfcHJpdnBvcnQ6IDAK dmZzLm5mc3J2LmNvbW1pdF9taXNzOiAwCnZmcy5uZnNydi5jb21taXRfYmxrczogMAp2ZnMubmZz cnYuYXN5bmM6IDAKdmZzLm5mc3J2LnJlYWxpZ25fY291bnQ6IDAKdmZzLm5mc3J2LnJlYWxpZ25f dGVzdDogMAp2ZnMubmZzcnYuZ2F0aGVyZGVsYXlfdjM6IDAKdmZzLm5mc3J2LmdhdGhlcmRlbGF5 OiAxMDAwMAp2ZnMuZmZzLmRvcmVhbGxvY2Jsa3M6IDEKdmZzLmZmcy5kb2FzeW5jZnJlZTogMQp2 ZnMuZmZzLmNvbXB1dGVfc3VtbWFyeV9hdF9tb3VudDogMApuZXQubG9jYWwuc3RyZWFtLnJlY3Zz cGFjZTogODE5MgpuZXQubG9jYWwuc3RyZWFtLnNlbmRzcGFjZTogODE5MgpuZXQubG9jYWwuZGdy YW0ucmVjdnNwYWNlOiA0MDk2Cm5ldC5sb2NhbC5kZ3JhbS5tYXhkZ3JhbTogMjA0OApuZXQubG9j YWwucmVjeWNsZWQ6IDAKbmV0LmxvY2FsLnRhc2tjb3VudDogMApuZXQubG9jYWwuaW5mbGlnaHQ6 IDAKbmV0LmluZXQuaXAucG9ydHJhbmdlLnJhbmRvbXRpbWU6IDQ1Cm5ldC5pbmV0LmlwLnBvcnRy YW5nZS5yYW5kb21jcHM6IDEwCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5yYW5kb21pemVkOiAxCm5l dC5pbmV0LmlwLnBvcnRyYW5nZS5yZXNlcnZlZGxvdzogMApuZXQuaW5ldC5pcC5wb3J0cmFuZ2Uu cmVzZXJ2ZWRoaWdoOiAxMDIzCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5oaWxhc3Q6IDY1NTM1Cm5l dC5pbmV0LmlwLnBvcnRyYW5nZS5oaWZpcnN0OiA0OTE1MgpuZXQuaW5ldC5pcC5wb3J0cmFuZ2Uu bGFzdDogNjU1MzUKbmV0LmluZXQuaXAucG9ydHJhbmdlLmZpcnN0OiA0OTE1MgpuZXQuaW5ldC5p cC5wb3J0cmFuZ2UubG93bGFzdDogNjAwCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5sb3dmaXJzdDog MTAyMwpuZXQuaW5ldC5pcC5mb3J3YXJkaW5nOiAwCm5ldC5pbmV0LmlwLnJlZGlyZWN0OiAxCm5l dC5pbmV0LmlwLnR0bDogNjQKbmV0LmluZXQuaXAucnRleHBpcmU6IDM2MDAKbmV0LmluZXQuaXAu cnRtaW5leHBpcmU6IDEwCm5ldC5pbmV0LmlwLnJ0bWF4Y2FjaGU6IDEyOApuZXQuaW5ldC5pcC5z b3VyY2Vyb3V0ZTogMApuZXQuaW5ldC5pcC5pbnRyX3F1ZXVlX21heGxlbjogNTAKbmV0LmluZXQu aXAuaW50cl9xdWV1ZV9kcm9wczogMApuZXQuaW5ldC5pcC5hY2NlcHRfc291cmNlcm91dGU6IDAK bmV0LmluZXQuaXAua2VlcGZhaXRoOiAwCm5ldC5pbmV0LmlwLmdpZnR0bDogMzAKbmV0LmluZXQu aXAuc2FtZV9wcmVmaXhfY2FycF9vbmx5OiAwCm5ldC5pbmV0LmlwLnN1Ym5ldHNfYXJlX2xvY2Fs OiAwCm5ldC5pbmV0LmlwLmZhc3Rmb3J3YXJkaW5nOiAwCm5ldC5pbmV0LmlwLm1heGZyYWdwYWNr ZXRzOiA4MDAKbmV0LmluZXQuaXAubWF4ZnJhZ3NwZXJwYWNrZXQ6IDE2Cm5ldC5pbmV0LmlwLmZy YWdwYWNrZXRzOiAwCm5ldC5pbmV0LmlwLmNoZWNrX2ludGVyZmFjZTogMApuZXQuaW5ldC5pcC5y YW5kb21faWQ6IDAKbmV0LmluZXQuaXAuc2VuZHNvdXJjZXF1ZW5jaDogMApuZXQuaW5ldC5pcC5w cm9jZXNzX29wdGlvbnM6IDEKbmV0LmluZXQuaWNtcC5tYXNrcmVwbDogMApuZXQuaW5ldC5pY21w LmljbXBsaW06IDIwMApuZXQuaW5ldC5pY21wLmJtY2FzdGVjaG86IDAKbmV0LmluZXQuaWNtcC5x dW90ZWxlbjogOApuZXQuaW5ldC5pY21wLnJlcGx5X2Zyb21faW50ZXJmYWNlOiAwCm5ldC5pbmV0 LmljbXAucmVwbHlfc3JjOiAKbmV0LmluZXQuaWNtcC5pY21wbGltX291dHB1dDogMQpuZXQuaW5l dC5pY21wLmxvZ19yZWRpcmVjdDogMApuZXQuaW5ldC5pY21wLmRyb3BfcmVkaXJlY3Q6IDAKbmV0 LmluZXQuaWNtcC5tYXNrZmFrZTogMApuZXQuaW5ldC50Y3AucmZjMTMyMzogMQpuZXQuaW5ldC50 Y3AubXNzZGZsdDogNTEyCm5ldC5pbmV0LnRjcC5rZWVwaWRsZTogNzIwMDAwMApuZXQuaW5ldC50 Y3Aua2VlcGludHZsOiA3NTAwMApuZXQuaW5ldC50Y3Auc2VuZHNwYWNlOiAzMjc2OApuZXQuaW5l dC50Y3AucmVjdnNwYWNlOiA2NTUzNgpuZXQuaW5ldC50Y3Aua2VlcGluaXQ6IDc1MDAwCm5ldC5p bmV0LnRjcC5kZWxhY2t0aW1lOiAxMDAKbmV0LmluZXQudGNwLnY2bXNzZGZsdDogMTAyNApuZXQu aW5ldC50Y3AuaG9zdGNhY2hlLnB1cmdlOiAwCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUucHJ1bmU6 IDMwMApuZXQuaW5ldC50Y3AuaG9zdGNhY2hlLmV4cGlyZTogMzYwMApuZXQuaW5ldC50Y3AuaG9z dGNhY2hlLmNvdW50OiAwCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUuYnVja2V0bGltaXQ6IDMwCm5l dC5pbmV0LnRjcC5ob3N0Y2FjaGUuaGFzaHNpemU6IDUxMgpuZXQuaW5ldC50Y3AuaG9zdGNhY2hl LmNhY2hlbGltaXQ6IDE1MzYwCm5ldC5pbmV0LnRjcC5yZWN2YnVmX21heDogMjYyMTQ0Cm5ldC5p bmV0LnRjcC5yZWN2YnVmX2luYzogMTYzODQKbmV0LmluZXQudGNwLnJlY3ZidWZfYXV0bzogMQpu ZXQuaW5ldC50Y3AuaW5zZWN1cmVfcnN0OiAwCm5ldC5pbmV0LnRjcC5yZmMzMzkwOiAxCm5ldC5p bmV0LnRjcC5yZmMzMDQyOiAxCm5ldC5pbmV0LnRjcC5kcm9wX3N5bmZpbjogMApuZXQuaW5ldC50 Y3AuZGVsYXllZF9hY2s6IDEKbmV0LmluZXQudGNwLmJsYWNraG9sZTogMApuZXQuaW5ldC50Y3Au bG9nX2luX3ZhaW46IDAKbmV0LmluZXQudGNwLnNlbmRidWZfbWF4OiAyNjIxNDQKbmV0LmluZXQu dGNwLnNlbmRidWZfaW5jOiA4MTkyCm5ldC5pbmV0LnRjcC5zZW5kYnVmX2F1dG86IDEKbmV0Lmlu ZXQudGNwLnRzbzogMQpuZXQuaW5ldC50Y3AubmV3cmVubzogMQpuZXQuaW5ldC50Y3AubG9jYWxf c2xvd3N0YXJ0X2ZsaWdodHNpemU6IDQKbmV0LmluZXQudGNwLnNsb3dzdGFydF9mbGlnaHRzaXpl OiAxCm5ldC5pbmV0LnRjcC5wYXRoX210dV9kaXNjb3Zlcnk6IDEKbmV0LmluZXQudGNwLnJlYXNz Lm92ZXJmbG93czogMApuZXQuaW5ldC50Y3AucmVhc3MubWF4cWxlbjogNDgKbmV0LmluZXQudGNw LnJlYXNzLmN1cnNlZ21lbnRzOiAwCm5ldC5pbmV0LnRjcC5yZWFzcy5tYXhzZWdtZW50czogMTYw MApuZXQuaW5ldC50Y3Auc2Fjay5nbG9iYWxob2xlczogMApuZXQuaW5ldC50Y3Auc2Fjay5nbG9i YWxtYXhob2xlczogNjU1MzYKbmV0LmluZXQudGNwLnNhY2subWF4aG9sZXM6IDEyOApuZXQuaW5l dC50Y3Auc2Fjay5lbmFibGU6IDEKbmV0LmluZXQudGNwLmluZmxpZ2h0LnN0YWI6IDIwCm5ldC5p bmV0LnRjcC5pbmZsaWdodC5tYXg6IDEwNzM3MjU0NDAKbmV0LmluZXQudGNwLmluZmxpZ2h0Lm1p bjogNjE0NApuZXQuaW5ldC50Y3AuaW5mbGlnaHQucnR0dGhyZXNoOiAxMApuZXQuaW5ldC50Y3Au aW5mbGlnaHQuZGVidWc6IDAKbmV0LmluZXQudGNwLmluZmxpZ2h0LmVuYWJsZTogMQpuZXQuaW5l dC50Y3AuaXNuX3Jlc2VlZF9pbnRlcnZhbDogMApuZXQuaW5ldC50Y3AuaWNtcF9tYXlfcnN0OiAx Cm5ldC5pbmV0LnRjcC5wY2Jjb3VudDogMQpuZXQuaW5ldC50Y3AuZG9fdGNwZHJhaW46IDEKbmV0 LmluZXQudGNwLnRjYmhhc2hzaXplOiA1MTIKbmV0LmluZXQudGNwLmxvZ19kZWJ1ZzogMApuZXQu aW5ldC50Y3AubWlubXNzOiAyMTYKbmV0LmluZXQudGNwLnN5bmNhY2hlLnJzdF9vbl9zb2NrX2Zh aWw6IDEKbmV0LmluZXQudGNwLnN5bmNhY2hlLnJleG10bGltaXQ6IDMKbmV0LmluZXQudGNwLnN5 bmNhY2hlLmhhc2hzaXplOiA1MTIKbmV0LmluZXQudGNwLnN5bmNhY2hlLmNvdW50OiAwCm5ldC5p bmV0LnRjcC5zeW5jYWNoZS5jYWNoZWxpbWl0OiAxNTM2MApuZXQuaW5ldC50Y3Auc3luY2FjaGUu YnVja2V0bGltaXQ6IDMwCm5ldC5pbmV0LnRjcC5zeW5jb29raWVzX29ubHk6IDAKbmV0LmluZXQu dGNwLnN5bmNvb2tpZXM6IDEKbmV0LmluZXQudGNwLnRpbWVyX3JhY2U6IDAKbmV0LmluZXQudGNw LmZpbndhaXQyX3RpbWVvdXQ6IDYwMDAwCm5ldC5pbmV0LnRjcC5mYXN0X2ZpbndhaXQyX3JlY3lj bGU6IDAKbmV0LmluZXQudGNwLmFsd2F5c19rZWVwYWxpdmU6IDEKbmV0LmluZXQudGNwLnJleG1p dF9zbG9wOiAyMDAKbmV0LmluZXQudGNwLnJleG1pdF9taW46IDMwCm5ldC5pbmV0LnRjcC5tc2w6 IDMwMDAwCm5ldC5pbmV0LnRjcC5ub2xvY2FsdGltZXdhaXQ6IDAKbmV0LmluZXQudGNwLm1heHRj cHR3OiAyNDY1Cm5ldC5pbmV0LnVkcC5jaGVja3N1bTogMQpuZXQuaW5ldC51ZHAubWF4ZGdyYW06 IDkyMTYKbmV0LmluZXQudWRwLnJlY3ZzcGFjZTogNDIwODAKbmV0LmluZXQudWRwLmJsYWNraG9s ZTogMApuZXQuaW5ldC51ZHAubG9nX2luX3ZhaW46IDAKbmV0LmluZXQuc2N0cC5tb2JpbGl0eV9m YXN0aGFuZG9mZjogMApuZXQuaW5ldC5zY3RwLm1vYmlsaXR5X2Jhc2U6IDAKbmV0LmluZXQuc2N0 cC5kZWZhdWx0X2ZyYWdfaW50ZXJsZWF2ZTogMQpuZXQuaW5ldC5zY3RwLmRlZmF1bHRfY2NfbW9k dWxlOiAwCm5ldC5pbmV0LnNjdHAubG9nX2xldmVsOiAwCm5ldC5pbmV0LnNjdHAubWF4X3JldHJh bl9jaHVuazogMzAKbmV0LmluZXQuc2N0cC5taW5fcmVzaWR1YWw6IDE0NTIKbmV0LmluZXQuc2N0 cC5zdHJpY3RfZGF0YV9vcmRlcjogMApuZXQuaW5ldC5zY3RwLmFib3J0X2F0X2xpbWl0OiAwCm5l dC5pbmV0LnNjdHAuaGJfbWF4X2J1cnN0OiA0Cm5ldC5pbmV0LnNjdHAuZG9fc2N0cF9kcmFpbjog MQpuZXQuaW5ldC5zY3RwLm1heF9jaGFpbmVkX21idWZzOiA1Cm5ldC5pbmV0LnNjdHAuYWJjX2xf dmFyOiAxCm5ldC5pbmV0LnNjdHAubmF0X2ZyaWVuZGx5OiAxCm5ldC5pbmV0LnNjdHAuYXV0aF9k aXNhYmxlOiAwCm5ldC5pbmV0LnNjdHAuYXNjb25mX2F1dGhfbm9jaGs6IDAKbmV0LmluZXQuc2N0 cC5lYXJseV9mYXN0X3JldHJhbl9tc2VjOiAyNTAKbmV0LmluZXQuc2N0cC5lYXJseV9mYXN0X3Jl dHJhbjogMApuZXQuaW5ldC5zY3RwLmN3bmRfbWF4YnVyc3Q6IDEKbmV0LmluZXQuc2N0cC5jbXRf cGY6IDAKbmV0LmluZXQuc2N0cC5jbXRfdXNlX2RhYzogMApuZXQuaW5ldC5zY3RwLmNtdF9vbl9v ZmY6IDAKbmV0LmluZXQuc2N0cC5vdXRnb2luZ19zdHJlYW1zOiAxMApuZXQuaW5ldC5zY3RwLmFk ZF9tb3JlX29uX291dHB1dDogMTQ1MgpuZXQuaW5ldC5zY3RwLnBhdGhfcnR4X21heDogNQpuZXQu aW5ldC5zY3RwLmFzc29jX3J0eF9tYXg6IDEwCm5ldC5pbmV0LnNjdHAuaW5pdF9ydHhfbWF4OiA4 Cm5ldC5pbmV0LnNjdHAudmFsaWRfY29va2llX2xpZmU6IDYwMDAwCm5ldC5pbmV0LnNjdHAuaW5p dF9ydG9fbWF4OiA2MDAwMApuZXQuaW5ldC5zY3RwLnJ0b19pbml0aWFsOiAzMDAwCm5ldC5pbmV0 LnNjdHAucnRvX21pbjogMTAwMApuZXQuaW5ldC5zY3RwLnJ0b19tYXg6IDYwMDAwCm5ldC5pbmV0 LnNjdHAuc2VjcmV0X2xpZmV0aW1lOiAzNjAwCm5ldC5pbmV0LnNjdHAuc2h1dGRvd25fZ3VhcmRf dGltZTogMTgwCm5ldC5pbmV0LnNjdHAucG10dV9yYWlzZV90aW1lOiA2MDAKbmV0LmluZXQuc2N0 cC5oZWFydGJlYXRfaW50ZXJ2YWw6IDMwMDAwCm5ldC5pbmV0LnNjdHAuYXNvY19yZXNvdXJjZTog MTAKbmV0LmluZXQuc2N0cC5zeXNfcmVzb3VyY2U6IDEwMDAKbmV0LmluZXQuc2N0cC5zYWNrX2Zy ZXE6IDIKbmV0LmluZXQuc2N0cC5kZWxheWVkX3NhY2tfdGltZTogMjAwCm5ldC5pbmV0LnNjdHAu Y2h1bmtzY2FsZTogMTAKbmV0LmluZXQuc2N0cC5taW5fc3BsaXRfcG9pbnQ6IDI5MDQKbmV0Lmlu ZXQuc2N0cC5wY2JoYXNoc2l6ZTogMjU2Cm5ldC5pbmV0LnNjdHAudGNiaGFzaHNpemU6IDEwMjQK bmV0LmluZXQuc2N0cC5tYXhjaHVua3M6IDMyMDAKbmV0LmluZXQuc2N0cC5tYXhidXJzdDogNApu ZXQuaW5ldC5zY3RwLnBlZXJfY2hrb2g6IDI1NgpuZXQuaW5ldC5zY3RwLnN0cmljdF9pbml0OiAx Cm5ldC5pbmV0LnNjdHAubG9vcGJhY2tfbm9jc3VtOiAxCm5ldC5pbmV0LnNjdHAuc3RyaWN0X3Nh Y2tzOiAwCm5ldC5pbmV0LnNjdHAuZWNuX25vbmNlOiAwCm5ldC5pbmV0LnNjdHAuZWNuX2VuYWJs ZTogMQpuZXQuaW5ldC5zY3RwLmF1dG9fYXNjb25mOiAxCm5ldC5pbmV0LnNjdHAucmVjdnNwYWNl OiAyMzMwMTYKbmV0LmluZXQuc2N0cC5zZW5kc3BhY2U6IDIzMzAxNgpuZXQuaW5ldC5yYXcucmVj dnNwYWNlOiA5MjE2Cm5ldC5pbmV0LnJhdy5tYXhkZ3JhbTogOTIxNgpuZXQuaW5ldC5hY2NmLnVu bG9hZGFibGU6IDAKbmV0LmxpbmsuZ2VuZXJpYy5zeXN0ZW0uaWZjb3VudDogNApuZXQubGluay5l dGhlci5pbmV0LmxvZ19hcnBfcGVybWFuZW50X21vZGlmeTogMQpuZXQubGluay5ldGhlci5pbmV0 LmxvZ19hcnBfbW92ZW1lbnRzOiAxCm5ldC5saW5rLmV0aGVyLmluZXQubG9nX2FycF93cm9uZ19p ZmFjZTogMQpuZXQubGluay5ldGhlci5pbmV0LnByb3h5YWxsOiAwCm5ldC5saW5rLmV0aGVyLmlu ZXQudXNlbG9vcGJhY2s6IDEKbmV0LmxpbmsuZXRoZXIuaW5ldC5tYXh0cmllczogNQpuZXQubGlu ay5ldGhlci5pbmV0Lm1heF9hZ2U6IDEyMDAKbmV0LmxpbmsuZXRoZXIuaXBmdzogMApuZXQubGlu ay5naWYucGFyYWxsZWxfdHVubmVsczogMApuZXQubGluay5naWYubWF4X25lc3Rpbmc6IDEKbmV0 LmxpbmsubG9nX2xpbmtfc3RhdGVfY2hhbmdlOiAxCm5ldC5saW5rLnR1bi5kZXZmc19jbG9uaW5n OiAxCm5ldC5pbmV0Ni5pcDYuZm9yd2FyZGluZzogMApuZXQuaW5ldDYuaXA2LnJlZGlyZWN0OiAx Cm5ldC5pbmV0Ni5pcDYuaGxpbTogNjQKbmV0LmluZXQ2LmlwNi5tYXhmcmFncGFja2V0czogNjQw MApuZXQuaW5ldDYuaXA2LmFjY2VwdF9ydGFkdjogMApuZXQuaW5ldDYuaXA2LmtlZXBmYWl0aDog MApuZXQuaW5ldDYuaXA2LmxvZ19pbnRlcnZhbDogNQpuZXQuaW5ldDYuaXA2Lmhkcm5lc3RsaW1p dDogMTUKbmV0LmluZXQ2LmlwNi5kYWRfY291bnQ6IDEKbmV0LmluZXQ2LmlwNi5hdXRvX2Zsb3ds YWJlbDogMQpuZXQuaW5ldDYuaXA2LmRlZm1jYXN0aGxpbTogMQpuZXQuaW5ldDYuaXA2LmdpZmhs aW06IDMwCm5ldC5pbmV0Ni5pcDYua2FtZV92ZXJzaW9uOiBGcmVlQlNECm5ldC5pbmV0Ni5pcDYu dXNlX2RlcHJlY2F0ZWQ6IDEKbmV0LmluZXQ2LmlwNi5ycl9wcnVuZTogNQpuZXQuaW5ldDYuaXA2 LnY2b25seTogMQpuZXQuaW5ldDYuaXA2LnJ0ZXhwaXJlOiAzNjAwCm5ldC5pbmV0Ni5pcDYucnRt aW5leHBpcmU6IDEwCm5ldC5pbmV0Ni5pcDYucnRtYXhjYWNoZTogMTI4Cm5ldC5pbmV0Ni5pcDYu dXNlX3RlbXBhZGRyOiAwCm5ldC5pbmV0Ni5pcDYudGVtcHBsdGltZTogODY0MDAKbmV0LmluZXQ2 LmlwNi50ZW1wdmx0aW1lOiA2MDQ4MDAKbmV0LmluZXQ2LmlwNi5hdXRvX2xpbmtsb2NhbDogMApu ZXQuaW5ldDYuaXA2LnByZWZlcl90ZW1wYWRkcjogMApuZXQuaW5ldDYuaXA2LnVzZV9kZWZhdWx0 em9uZTogMApuZXQuaW5ldDYuaXA2Lm1heGZyYWdzOiA2NDAwCm5ldC5pbmV0Ni5pcDYubWNhc3Rf cG10dTogMApuZXQuaW5ldDYuaWNtcDYucmVkaXJhY2NlcHQ6IDEKbmV0LmluZXQ2LmljbXA2LnJl ZGlydGltZW91dDogNjAwCm5ldC5pbmV0Ni5pY21wNi5uZDZfcHJ1bmU6IDEKbmV0LmluZXQ2Lmlj bXA2Lm5kNl9kZWxheTogNQpuZXQuaW5ldDYuaWNtcDYubmQ2X3VtYXh0cmllczogMwpuZXQuaW5l dDYuaWNtcDYubmQ2X21tYXh0cmllczogMwpuZXQuaW5ldDYuaWNtcDYubmQ2X3VzZWxvb3BiYWNr OiAxCm5ldC5pbmV0Ni5pY21wNi5ub2RlaW5mbzogMwpuZXQuaW5ldDYuaWNtcDYuZXJycHBzbGlt aXQ6IDEwMApuZXQuaW5ldDYuaWNtcDYubmQ2X21heG51ZGhpbnQ6IDAKbmV0LmluZXQ2LmljbXA2 Lm5kNl9kZWJ1ZzogMApuZXQuaW5ldDYuaWNtcDYubmQ2X21heHF1ZXVlbGVuOiAxCm5ldC5icGYu bWF4aW5zbnM6IDUxMgpuZXQuYnBmLm1heGJ1ZnNpemU6IDUyNDI4OApuZXQuYnBmLmJ1ZnNpemU6 IDQwOTYKbmV0Lmlzci5zd2lfY291bnQ6IDcKbmV0Lmlzci5kcm9wOiAwCm5ldC5pc3IucXVldWVk OiA3Cm5ldC5pc3IuZGVmZXJyZWQ6IDAKbmV0Lmlzci5kaXJlY3RlZDogMTUKbmV0Lmlzci5jb3Vu dDogMTUKbmV0Lmlzci5kaXJlY3Q6IDEKbmV0LnJvdXRlLm5ldGlzcl9tYXhxbGVuOiAyNTYKbmV0 LndsYW4ucmVjdl9iYXI6IDEKbmV0LndsYW4uZGVidWc6IDAKbmV0LndsYW4uMC4lcGFyZW50OiBh dGgwCm5ldC53bGFuLjAuZGVidWc6IDAKbmV0LndsYW4uMC5pbmFjdF9ydW46IDMwMApuZXQud2xh bi4wLmluYWN0X3Byb2JlOiAzMApuZXQud2xhbi4wLmluYWN0X2F1dGg6IDE4MApuZXQud2xhbi4w LmluYWN0X2luaXQ6IDMwCm5ldC53bGFuLjAuZHJpdmVyX2NhcHM6IDE3MzY2OTkyMTUKbmV0Lnds YW4uMC5ibWlzc19tYXg6IDIKZGVidWcuZmlyZXdpcmVfZGVidWc6IDAKZGVidWcuZndtZW1fZGVi dWc6IDAKZGVidWcuaWZfZndlX2RlYnVnOiAwCmRlYnVnLmlmX2Z3aXBfZGVidWc6IDAKZGVidWcu c2JwX2RlYnVnOiAwCmRlYnVnLm1kZGVidWc6IDAKZGVidWcuZWxmMzJfbGVnYWN5X2NvcmVkdW1w OiAwCmRlYnVnLmVsZjMyX3RyYWNlOiAwCmRlYnVnLmJvb3R2ZXJib3NlOiAxCmRlYnVnLmJvb3Ro b3d0bzogLTIxNDc0ODE2MDAKZGVidWcuY3B1ZnJlcS52ZXJib3NlOiAwCmRlYnVnLmNwdWZyZXEu bG93ZXN0OiAwCmRlYnVnLnNpemVvZi5jZGV2X3ByaXY6IDIzMgpkZWJ1Zy5zaXplb2YuY2Rldjog MTg0CmRlYnVnLnNpemVvZi5nX2Jpb3E6IDM2CmRlYnVnLnNpemVvZi5nX2NvbnN1bWVyOiA2MApk ZWJ1Zy5zaXplb2YuZ19wcm92aWRlcjogODgKZGVidWcuc2l6ZW9mLmdfZ2VvbTogNjgKZGVidWcu c2l6ZW9mLmdfY2xhc3M6IDY4CmRlYnVnLnNpemVvZi5raW5mb19wcm9jOiA3NjgKZGVidWcuc2l6 ZW9mLmJ1ZjogMzU2CmRlYnVnLnNpemVvZi5iaW86IDEzMgpkZWJ1Zy5zaXplb2YucHJvYzogNjg0 CmRlYnVnLnNpemVvZi52bm9kZTogMjcyCmRlYnVnLnNpemVvZi5kZXZzdGF0OiAyNDAKZGVidWcu c2l6ZW9mLm5hbWVjYWNoZTogMzYKZGVidWcudG9fYXZnX21wY2FsbHM6IDE3NTMKZGVidWcudG9f YXZnX210eGNhbGxzOiAwCmRlYnVnLnRvX2F2Z19nY2FsbHM6IDEwMDQKZGVidWcudG9fYXZnX2Rl cHRoOiAyOTUxCmRlYnVnLnVtdHgudW10eF9waV9hbGxvY2F0ZWQ6IDAKZGVidWcua2RiLnN0b3Bf Y3B1czogMQpkZWJ1Zy5rZGIudHJhcF9jb2RlOiAwCmRlYnVnLmtkYi50cmFwOiAwCmRlYnVnLmtk Yi5wYW5pYzogMApkZWJ1Zy5rZGIuZW50ZXI6IDAKZGVidWcua2RiLmN1cnJlbnQ6IApkZWJ1Zy5r ZGIuYXZhaWxhYmxlOiAKZGVidWcucm1hbl9kZWJ1ZzogMApkZWJ1Zy50dHlkZWJ1ZzogMApkZWJ1 Zy5kaXNhYmxlZnVsbHBhdGg6IDAKZGVidWcuZGlzYWJsZWN3ZDogMApkZWJ1Zy5oYXNoc3RhdC5u Y2hhc2g6IDEzMTA3MiAzOTIgMSAyOQpkZWJ1Zy52ZnNjYWNoZTogMQpkZWJ1Zy5udW1jYWNoZWh2 OiAzNgpkZWJ1Zy5udW1jYWNoZTogMzkyCmRlYnVnLm51bW5lZzogMjQKZGVidWcubmNuZWdmYWN0 b3I6IDE2CmRlYnVnLm5jaGFzaDogMTMxMDcxCmRlYnVnLnZubHJ1X25vd2hlcmU6IDAKZGVidWcu cnVzaF9yZXF1ZXN0czogMApkZWJ1Zy5tcHNhZmV2ZnM6IDEKZGVidWcuaWZfdHVuX2RlYnVnOiAw CmRlYnVnLmNvbGxlY3RzbmFwc3RhdHM6IDAKZGVidWcuc25hcGRlYnVnOiAwCmRlYnVnLmRvcGVy c2lzdGVuY2U6IDAKZGVidWcuZGlyX2VudHJ5OiA3CmRlYnVnLmRpcmVjdF9ibGtfcHRyczogMwpk ZWJ1Zy5pbm9kZV9iaXRtYXA6IDEwCmRlYnVnLmluZGlyX2Jsa19wdHJzOiAwCmRlYnVnLnN5bmNf bGltaXRfaGl0OiAwCmRlYnVnLmlub19saW1pdF9oaXQ6IDAKZGVidWcuYmxrX2xpbWl0X2hpdDog MApkZWJ1Zy5pbm9fbGltaXRfcHVzaDogMApkZWJ1Zy5ibGtfbGltaXRfcHVzaDogMApkZWJ1Zy53 b3JrbGlzdF9wdXNoOiAwCmRlYnVnLm1heGluZGlyZGVwczogNTAKZGVidWcudGlja2RlbGF5OiAy CmRlYnVnLm1heF9zb2Z0ZGVwczogNDAwMDAwCmRlYnVnLmRvYmtncmR3cml0ZTogMQpkZWJ1Zy5i aWdjZ3M6IDAKZGVidWcuZGlyY2hlY2s6IDAKZGVidWcubm9zbGVlcHdpdGhsb2NrczogMApkZWJ1 Zy5wc20ucGt0ZXJydGhyZXNoOiAyCmRlYnVnLnBzbS51c2VjczogNTAwMDAwCmRlYnVnLnBzbS5z ZWNzOiAwCmRlYnVnLnBzbS5lcnJ1c2VjczogMApkZWJ1Zy5wc20uZXJyc2VjczogMgpkZWJ1Zy5w c20uaHo6IDIwCmRlYnVnLnBzbS5sb2dsZXZlbDogMApkZWJ1Zy5mZGMuc2V0dGxlOiAwCmRlYnVn LmZkYy5zcGVjMjogMTYKZGVidWcuZmRjLnNwZWMxOiAxNzUKZGVidWcuZmRjLnJldHJpZXM6IDEw CmRlYnVnLmZkYy5kZWJ1Z2ZsYWdzOiAwCmRlYnVnLmZkYy5maWZvOiA4CmRlYnVnLm1pbmlkdW1w OiAxCmRlYnVnLnN0b3BfY3B1c193aXRoX25taTogMQpkZWJ1Zy5QTUFQMXVuY2hhbmdlZDogMzA5 MDAwCmRlYnVnLlBNQVAxY2hhbmdlZDogMjQ1MgpkZWJ1Zy5QTUFQMWNoYW5nZWRjcHU6IDAKZGVi dWcuYWNwaS5zdXNwZW5kX2JvdW5jZTogMApkZWJ1Zy5hY3BpLmRvX3Bvd2Vyc3RhdGU6IDEKZGVi dWcuYWNwaS5hY3BpX2NhX3ZlcnNpb246IDIwMDcwMzIwCmRlYnVnLmFjcGkuZWMudGltZW91dDog NzUwCmRlYnVnLmFjcGkuZWMucG9sbGVkOiAwCmRlYnVnLmFjcGkuZWMuYnVyc3Q6IDAKZGVidWcu YWNwaS5zZW1hcGhvcmVfZGVidWc6IDAKZGVidWcuYWNwaS5yZXN1bWVfYmVlcDogMApody5tYWNo aW5lOiBpMzg2Cmh3Lm1vZGVsOiBJbnRlbChSKSBQZW50aXVtKFIpIE0gcHJvY2Vzc29yIDIuMjZH SHoKaHcubmNwdTogMQpody5ieXRlb3JkZXI6IDEyMzQKaHcucGh5c21lbTogMjEzMzA4NjIwOApo dy51c2VybWVtOiAyMTE1NjUzNjMyCmh3LnBhZ2VzaXplOiA0MDk2Cmh3LmZsb2F0aW5ncG9pbnQ6 IDEKaHcubWFjaGluZV9hcmNoOiBpMzg2Cmh3LnJlYWxtZW06IDIxNDYyMzg0NjQKaHcuYWFjLmlv c2l6ZV9tYXg6IDY1NTM2Cmh3LmFtci5mb3JjZV9zZzMyOiAwCmh3LmFuLmFuX2NhY2hlX2lwb25s eTogMQpody5hbi5hbl9jYWNoZV9tY2FzdG9ubHk6IDAKaHcuYW4uYW5fY2FjaGVfbW9kZTogZGJt Cmh3LmFuLmFuX2R1bXA6IG9mZgpody5hdGEud2M6IDEKaHcuYXRhLmF0YXBpX2RtYTogMQpody5h dGEuYXRhX2RtYTogMQpody5hdGguaGFsLnN3YmFfYmFja29mZjogMApody5hdGguaGFsLnN3X2Jy dDogMTAKaHcuYXRoLmhhbC5kbWFfYnJ0OiAyCmh3LmF0aC5oYWwudmVyc2lvbjogMC45LjIwLjMK aHcuYXRoLnR4YnVmOiAyMDAKaHcuYXRoLnJ4YnVmOiA0MApody5hdGgucmVnZG9tYWluOiAwCmh3 LmF0aC5jb3VudHJ5Y29kZTogMApody5hdGgueGNoYW5tb2RlOiAxCmh3LmF0aC5vdXRkb29yOiAx Cmh3LmF0aC5jYWxpYnJhdGU6IDMwCmh3LmJjZS5tc2lfZW5hYmxlOiAxCmh3LmJjZS50c29fZW5h YmxlOiAxCmh3LmJnZS5hbGxvd19hc2Y6IDAKaHcuY2FyZGJ1cy5jaXNfZGVidWc6IDAKaHcuY2Fy ZGJ1cy5kZWJ1ZzogMApody5jcy5yZWN2X2RlbGF5OiA1NzAKaHcuY3MuaWdub3JlX2NoZWNrc3Vt X2ZhaWx1cmU6IDAKaHcuY3MuZGVidWc6IDAKaHcuZmlyZXdpcmUuaG9sZF9jb3VudDogMwpody5m aXJld2lyZS50cnlfYm1yOiAxCmh3LmZpcmV3aXJlLmZ3bWVtLnNwZWVkOiAyCmh3LmZpcmV3aXJl LmZ3bWVtLmV1aTY0X2xvOiAwCmh3LmZpcmV3aXJlLmZ3bWVtLmV1aTY0X2hpOiAwCmh3LmZpcmV3 aXJlLnBoeWRtYV9lbmFibGU6IDEKaHcuZmlyZXdpcmUubm9jeWNsZW1hc3RlcjogMApody5maXJl d2lyZS5md2UucnhfcXVldWVfbGVuOiAxMjgKaHcuZmlyZXdpcmUuZndlLnR4X3NwZWVkOiAyCmh3 LmZpcmV3aXJlLmZ3ZS5zdHJlYW1fY2g6IDEKaHcuZmlyZXdpcmUuZndpcC5yeF9xdWV1ZV9sZW46 IDEyOApody5maXJld2lyZS5zYnAudGFnczogMApody5maXJld2lyZS5zYnAudXNlX2Rvb3JiZWxs OiAwCmh3LmZpcmV3aXJlLnNicC5zY2FuX2RlbGF5OiA1MDAKaHcuZmlyZXdpcmUuc2JwLmxvZ2lu X2RlbGF5OiAxMDAwCmh3LmZpcmV3aXJlLnNicC5leGNsdXNpdmVfbG9naW46IDEKaHcuZmlyZXdp cmUuc2JwLm1heF9zcGVlZDogLTEKaHcuZmlyZXdpcmUuc2JwLmF1dG9fbG9naW46IDEKaHcubWZp LmV2ZW50X2NsYXNzOiAwCmh3Lm1maS5ldmVudF9sb2NhbGU6IDY1NTM1Cmh3LnBjY2FyZC5jaXNf ZGVidWc6IDAKaHcucGNjYXJkLmRlYnVnOiAwCmh3LmNiYi5kZWJ1ZzogMApody5jYmIuc3RhcnRf MzJfaW86IDQwOTYKaHcuY2JiLnN0YXJ0XzE2X2lvOiAyNTYKaHcuY2JiLnN0YXJ0X21lbW9yeTog MjI4MTcwMTM3Ngpody5wY2ljLnBkNjcyMl92c2Vuc2U6IDEKaHcucGNpYy5pbnRyX21hc2s6IDU3 MDE2Cmh3LnBjaS5ob25vcl9tc2lfYmxhY2tsaXN0OiAxCmh3LnBjaS5lbmFibGVfbXNpeDogMQpo dy5wY2kuZW5hYmxlX21zaTogMQpody5wY2kuZG9fcG93ZXJfcmVzdW1lOiAxCmh3LnBjaS5kb19w b3dlcl9ub2RyaXZlcjogMApody5wY2kuZW5hYmxlX2lvX21vZGVzOiAxCmh3LnBjaS5ob3N0X21l bV9zdGFydDogMjE0NzQ4MzY0OApody5wY2kuaXJxX292ZXJyaWRlX21hc2s6IDU3MDgwCmh3LnN5 c2NvbnMua2JkX2RlYnVnOiAxCmh3LnN5c2NvbnMua2JkX3JlYm9vdDogMQpody5zeXNjb25zLmJl bGw6IDEKaHcuc3lzY29ucy5zYXZlci5rZXlib25seTogMQpody5zeXNjb25zLnNjX25vX3N1c3Bl bmRfdnRzd2l0Y2g6IDAKaHcud2kuZGVidWc6IDAKaHcud2kudHhlcmF0ZTogMApody54ZS5kZWJ1 ZzogMApody5pbnRyX3N0b3JtX3RocmVzaG9sZDogMTAwMApody5hdmFpbHBhZ2VzOiA1MjA3NzMK aHcuYnVzLmRldmN0bF9kaXNhYmxlOiAwCmh3LnN0ZS5yeHN5bmNzOiAwCmh3LnBzbS50YXBfdGlt ZW91dDogMTI1MDAwCmh3LnBzbS50YXBfdGhyZXNob2xkOiAyNQpody5rYmQua2V5bWFwX3Jlc3Ry aWN0X2NoYW5nZTogMApody5idXNkbWEudG90YWxfYnBhZ2VzOiA0Nwpody5idXNkbWEuem9uZTAu dG90YWxfYnBhZ2VzOiAxNQpody5idXNkbWEuem9uZTAuZnJlZV9icGFnZXM6IDE1Cmh3LmJ1c2Rt YS56b25lMC5yZXNlcnZlZF9icGFnZXM6IDAKaHcuYnVzZG1hLnpvbmUwLmFjdGl2ZV9icGFnZXM6 IDAKaHcuYnVzZG1hLnpvbmUwLnRvdGFsX2JvdW5jZWQ6IDAKaHcuYnVzZG1hLnpvbmUwLnRvdGFs X2RlZmVycmVkOiAwCmh3LmJ1c2RtYS56b25lMC5sb3dhZGRyOiAweGZmZmZmZmZmCmh3LmJ1c2Rt YS56b25lMC5hbGlnbm1lbnQ6IDQwOTYKaHcuYnVzZG1hLnpvbmUwLmJvdW5kYXJ5OiAwCmh3LmJ1 c2RtYS56b25lMS50b3RhbF9icGFnZXM6IDMyCmh3LmJ1c2RtYS56b25lMS5mcmVlX2JwYWdlczog MzIKaHcuYnVzZG1hLnpvbmUxLnJlc2VydmVkX2JwYWdlczogMApody5idXNkbWEuem9uZTEuYWN0 aXZlX2JwYWdlczogMApody5idXNkbWEuem9uZTEudG90YWxfYm91bmNlZDogMApody5idXNkbWEu em9uZTEudG90YWxfZGVmZXJyZWQ6IDAKaHcuYnVzZG1hLnpvbmUxLmxvd2FkZHI6IDB4ZmZmZmZm ZmYKaHcuYnVzZG1hLnpvbmUxLmFsaWdubWVudDogMgpody5idXNkbWEuem9uZTEuYm91bmRhcnk6 IDY1NTM2Cmh3LmNsb2NrcmF0ZTogMjI2MQpody52aWFfZmVhdHVyZV94Y3J5cHQ6IDAKaHcudmlh X2ZlYXR1cmVfcm5nOiAwCmh3Lmluc3RydWN0aW9uX3NzZTogMQpody5hcGljLmVuYWJsZV9leHRp bnQ6IDAKaHcuc25kLmxhdGVuY3lfcHJvZmlsZTogMQpody5zbmQubGF0ZW5jeTogNQpody5zbmQu cmVwb3J0X3NvZnRfZm9ybWF0czogMQpody5zbmQuY29tcGF0X2xpbnV4X21tYXA6IDAKaHcuc25k LmZlZWRlcl9idWZmZXJzaXplOiAxNjM4NApody5zbmQuZmVlZGVyX3JhdGVfcm91bmQ6IDI1Cmh3 LnNuZC5mZWVkZXJfcmF0ZV9tYXg6IDIwMTYwMDAKaHcuc25kLmZlZWRlcl9yYXRlX21pbjogMQpo dy5zbmQudmVyYm9zZTogMQpody5zbmQubWF4YXV0b3ZjaGFuczogMTYKaHcuc25kLmRlZmF1bHRf dW5pdDogMApody5zbmQudmVyc2lvbjogMjAwNzA2MTYwMC9pMzg2Cmh3LnNuZC5kZWZhdWx0X2F1 dG86IDAKaHcubWlkaS5pbnN0cm9mZjogMApody5taWRpLmR1bXByYXc6IDAKaHcubWlkaS5kZWJ1 ZzogMApody5taWRpLnN0YXQudmVyYm9zZTogMApody5taWRpLnNlcS5kZWJ1ZzogMApody5hY3Bp LnN1cHBvcnRlZF9zbGVlcF9zdGF0ZTogUzMgUzQgUzUKaHcuYWNwaS5wb3dlcl9idXR0b25fc3Rh dGU6IFM1Cmh3LmFjcGkuc2xlZXBfYnV0dG9uX3N0YXRlOiBTMwpody5hY3BpLmxpZF9zd2l0Y2hf c3RhdGU6IE5PTkUKaHcuYWNwaS5zdGFuZGJ5X3N0YXRlOiBTMQpody5hY3BpLnN1c3BlbmRfc3Rh dGU6IFMzCmh3LmFjcGkuc2xlZXBfZGVsYXk6IDEKaHcuYWNwaS5zNGJpb3M6IDAKaHcuYWNwaS52 ZXJib3NlOiAxCmh3LmFjcGkuZGlzYWJsZV9vbl9yZWJvb3Q6IDAKaHcuYWNwaS5oYW5kbGVfcmVi b290OiAwCmh3LmFjcGkucmVzZXRfdmlkZW86IDAKaHcuYWNwaS5jcHUuY3hfbG93ZXN0OiBDMQpo dy5hY3BpLnRoZXJtYWwubWluX3J1bnRpbWU6IDAKaHcuYWNwaS50aGVybWFsLnBvbGxpbmdfcmF0 ZTogMTAKaHcuYWNwaS50aGVybWFsLnVzZXJfb3ZlcnJpZGU6IDAKaHcuYWNwaS50aGVybWFsLnR6 MC50ZW1wZXJhdHVyZTogNTkuMEMKaHcuYWNwaS50aGVybWFsLnR6MC5hY3RpdmU6IC0xCmh3LmFj cGkudGhlcm1hbC50ejAucGFzc2l2ZV9jb29saW5nOiAxCmh3LmFjcGkudGhlcm1hbC50ejAudGhl cm1hbF9mbGFnczogMApody5hY3BpLnRoZXJtYWwudHowLl9QU1Y6IDk0LjVDCmh3LmFjcGkudGhl cm1hbC50ejAuX0hPVDogLTEKaHcuYWNwaS50aGVybWFsLnR6MC5fQ1JUOiA5OS4wQwpody5hY3Bp LnRoZXJtYWwudHowLl9BQ3g6IC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xCmh3LmFjcGku YmF0dGVyeS5saWZlOiA5Ngpody5hY3BpLmJhdHRlcnkudGltZTogLTEKaHcuYWNwaS5iYXR0ZXJ5 LnN0YXRlOiAwCmh3LmFjcGkuYmF0dGVyeS51bml0czogMQpody5hY3BpLmJhdHRlcnkuaW5mb19l eHBpcmU6IDUKaHcuYWNwaS5hY2xpbmU6IDEKbWFjaGRlcC5lbmFibGVfcGFuaWNfa2V5OiAwCm1h Y2hkZXAuYWRqa2VybnR6OiAwCm1hY2hkZXAud2FsbF9jbW9zX2Nsb2NrOiAwCm1hY2hkZXAuZGlz YWJsZV9ydGNfc2V0OiAwCm1hY2hkZXAuY29uc3BlZWQ6IDk2MDAKbWFjaGRlcC5nZGJzcGVlZDog OTYwMAptYWNoZGVwLmNvbnJjbGs6IDE4NDMyMDAKbWFjaGRlcC5kaXNhYmxlX210cnJzOiAwCm1h Y2hkZXAuZ3Vlc3NlZF9ib290ZGV2OiAyNjg2NDUxNzEyCm1hY2hkZXAuY3B1X2lkbGVfaGx0OiAx Cm1hY2hkZXAuaGx0X2NwdXM6IDAKbWFjaGRlcC5wcm90X2ZhdWx0X3RyYW5zbGF0aW9uOiAwCm1h Y2hkZXAucGFuaWNfb25fbm1pOiAxCm1hY2hkZXAudHNjX2ZyZXE6IDIyNjExNTk2MjcKbWFjaGRl cC5pODI1NF9mcmVxOiAxMTkzMTgyCm1hY2hkZXAuYWNwaV90aW1lcl9mcmVxOiAzNTc5NTQ1Cm1h Y2hkZXAuYWNwaV9yb290OiAxMDEwNjg4CnVzZXIuY3NfcGF0aDogL3Vzci9iaW46L2JpbjovdXNy L3NiaW46L3NiaW46CnVzZXIuYmNfYmFzZV9tYXg6IDk5CnVzZXIuYmNfZGltX21heDogMjA0OAp1 c2VyLmJjX3NjYWxlX21heDogOTkKdXNlci5iY19zdHJpbmdfbWF4OiAxMDAwCnVzZXIuY29sbF93 ZWlnaHRzX21heDogMAp1c2VyLmV4cHJfbmVzdF9tYXg6IDMyCnVzZXIubGluZV9tYXg6IDIwNDgK dXNlci5yZV9kdXBfbWF4OiAyNTUKdXNlci5wb3NpeDJfdmVyc2lvbjogMTk5MjEyCnVzZXIucG9z aXgyX2NfYmluZDogMAp1c2VyLnBvc2l4Ml9jX2RldjogMAp1c2VyLnBvc2l4Ml9jaGFyX3Rlcm06 IDAKdXNlci5wb3NpeDJfZm9ydF9kZXY6IDAKdXNlci5wb3NpeDJfZm9ydF9ydW46IDAKdXNlci5w b3NpeDJfbG9jYWxlZGVmOiAwCnVzZXIucG9zaXgyX3N3X2RldjogMAp1c2VyLnBvc2l4Ml91cGU6 IDAKdXNlci5zdHJlYW1fbWF4OiAyMAp1c2VyLnR6bmFtZV9tYXg6IDI1NQpwMTAwM18xYi5hc3lu Y2hyb25vdXNfaW86IDAKcDEwMDNfMWIubWFwcGVkX2ZpbGVzOiAxCnAxMDAzXzFiLm1lbWxvY2s6 IDAKcDEwMDNfMWIubWVtbG9ja19yYW5nZTogMApwMTAwM18xYi5tZW1vcnlfcHJvdGVjdGlvbjog MApwMTAwM18xYi5tZXNzYWdlX3Bhc3Npbmc6IDAKcDEwMDNfMWIucHJpb3JpdGl6ZWRfaW86IDAK cDEwMDNfMWIucHJpb3JpdHlfc2NoZWR1bGluZzogMQpwMTAwM18xYi5yZWFsdGltZV9zaWduYWxz OiAyMDAxMTIKcDEwMDNfMWIuc2VtYXBob3JlczogMApwMTAwM18xYi5mc3luYzogMApwMTAwM18x Yi5zaGFyZWRfbWVtb3J5X29iamVjdHM6IDEKcDEwMDNfMWIuc3luY2hyb25pemVkX2lvOiAwCnAx MDAzXzFiLnRpbWVyczogMjAwMTEyCnAxMDAzXzFiLmFpb19saXN0aW9fbWF4OiAtMQpwMTAwM18x Yi5haW9fbWF4OiAtMQpwMTAwM18xYi5haW9fcHJpb19kZWx0YV9tYXg6IC0xCnAxMDAzXzFiLmRl bGF5dGltZXJfbWF4OiAyMTQ3NDgzNjQ3CnAxMDAzXzFiLm1xX29wZW5fbWF4OiAwCnAxMDAzXzFi LnBhZ2VzaXplOiA0MDk2CnAxMDAzXzFiLnJ0c2lnX21heDogNjIKcDEwMDNfMWIuc2VtX25zZW1z X21heDogMApwMTAwM18xYi5zZW1fdmFsdWVfbWF4OiAwCnAxMDAzXzFiLnNpZ3F1ZXVlX21heDog MTI4CnAxMDAzXzFiLnRpbWVyX21heDogMzIKc2VjdXJpdHkuamFpbC5qYWlsZWQ6IDAKc2VjdXJp dHkuamFpbC5tb3VudF9hbGxvd2VkOiAwCnNlY3VyaXR5LmphaWwuY2hmbGFnc19hbGxvd2VkOiAw CnNlY3VyaXR5LmphaWwuYWxsb3dfcmF3X3NvY2tldHM6IDAKc2VjdXJpdHkuamFpbC5lbmZvcmNl X3N0YXRmczogMgpzZWN1cml0eS5qYWlsLnN5c3ZpcGNfYWxsb3dlZDogMApzZWN1cml0eS5qYWls LnNvY2tldF91bml4aXByb3V0ZV9vbmx5OiAxCnNlY3VyaXR5LmphaWwuc2V0X2hvc3RuYW1lX2Fs bG93ZWQ6IDEKc2VjdXJpdHkuYnNkLnN1c2VyX2VuYWJsZWQ6IDEKc2VjdXJpdHkuYnNkLnVucHJp dmlsZWdlZF9wcm9jX2RlYnVnOiAxCnNlY3VyaXR5LmJzZC5jb25zZXJ2YXRpdmVfc2lnbmFsczog MQpzZWN1cml0eS5ic2Quc2VlX290aGVyX2dpZHM6IDEKc2VjdXJpdHkuYnNkLnNlZV9vdGhlcl91 aWRzOiAxCnNlY3VyaXR5LmJzZC51bnByaXZpbGVnZWRfcmVhZF9tc2didWY6IDEKc2VjdXJpdHku YnNkLmhhcmRsaW5rX2NoZWNrX2dpZDogMApzZWN1cml0eS5ic2QuaGFyZGxpbmtfY2hlY2tfdWlk OiAwCnNlY3VyaXR5LmJzZC51bnByaXZpbGVnZWRfZ2V0X3F1b3RhOiAwCmRldi5uZXh1cy4wLiVk cml2ZXI6IG5leHVzCmRldi5uZXh1cy4wLiVwYXJlbnQ6IHJvb3QwCmRldi5yYW0uMC4lZGVzYzog U3lzdGVtIFJBTQpkZXYucmFtLjAuJWRyaXZlcjogcmFtCmRldi5yYW0uMC4lcGFyZW50OiBuZXh1 czAKZGV2Lm5weC4wLiVkZXNjOiBtYXRoIHByb2Nlc3NvcgpkZXYubnB4LjAuJWRyaXZlcjogbnB4 CmRldi5ucHguMC4lcGFyZW50OiBuZXh1czAKZGV2LmFjcGkuMC4lZGVzYzogSUJNIFRQLTFZCmRl di5hY3BpLjAuJWRyaXZlcjogYWNwaQpkZXYuYWNwaS4wLiVwYXJlbnQ6IG5leHVzMApkZXYuYWNw aV9lYy4wLiVkZXNjOiBFbWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxYywgRUNEVApkZXYuYWNw aV9lYy4wLiVkcml2ZXI6IGFjcGlfZWMKZGV2LmFjcGlfZWMuMC4lbG9jYXRpb246IGhhbmRsZT1c X1NCXy5QQ0kwLkxQQ18uRUNfXwpkZXYuYWNwaV9lYy4wLiVwbnBpbmZvOiBfSElEPVBOUDBDMDkg X1VJRD0wCmRldi5hY3BpX2VjLjAuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfc3lzcmVzb3VyY2Uu MC4lZGVzYzogU3lzdGVtIFJlc291cmNlCmRldi5hY3BpX3N5c3Jlc291cmNlLjAuJWRyaXZlcjog YWNwaV9zeXNyZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS4wLiVsb2NhdGlvbjogaGFuZGxl PVxfU0JfLk1FTV8KZGV2LmFjcGlfc3lzcmVzb3VyY2UuMC4lcG5waW5mbzogX0hJRD1QTlAwQzAx IF9VSUQ9MApkZXYuYWNwaV9zeXNyZXNvdXJjZS4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX3N5 c3Jlc291cmNlLjEuJWRlc2M6IFN5c3RlbSBSZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS4x LiVkcml2ZXI6IGFjcGlfc3lzcmVzb3VyY2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMS4lbG9jYXRp b246IGhhbmRsZT1cX1NCXy5QQ0kwLkxQQ18uU0lPXwpkZXYuYWNwaV9zeXNyZXNvdXJjZS4xLiVw bnBpbmZvOiBfSElEPVBOUDBDMDIgX1VJRD0wCmRldi5hY3BpX3N5c3Jlc291cmNlLjEuJXBhcmVu dDogYWNwaTAKZGV2LmFjcGlfdGltZXIuMC4lZGVzYzogMjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1 TUh6CmRldi5hY3BpX3RpbWVyLjAuJWRyaXZlcjogYWNwaV90aW1lcgpkZXYuYWNwaV90aW1lci4w LiVsb2NhdGlvbjogdW5rbm93bgpkZXYuYWNwaV90aW1lci4wLiVwbnBpbmZvOiB1bmtub3duCmRl di5hY3BpX3RpbWVyLjAuJXBhcmVudDogYWNwaTAKZGV2LnBjaV9saW5rLjAuJWRlc2M6IEFDUEkg UENJIExpbmsgTE5LQQpkZXYucGNpX2xpbmsuMC4lZHJpdmVyOiBwY2lfbGluawpkZXYucGNpX2xp bmsuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktBCmRldi5wY2lfbGluay4wLiVwbnBpbmZv OiBfSElEPVBOUDBDMEYgX1VJRD0xCmRldi5wY2lfbGluay4wLiVwYXJlbnQ6IGFjcGkwCmRldi5w Y2lfbGluay4xLiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0IKZGV2LnBjaV9saW5rLjEuJWRyaXZl cjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjEuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uTE5LQgpk ZXYucGNpX2xpbmsuMS4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9VSUQ9MgpkZXYucGNpX2xpbmsu MS4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMi4lZGVzYzogQUNQSSBQQ0kgTGluayBMTktD CmRldi5wY2lfbGluay4yLiVkcml2ZXI6IHBjaV9saW5rCmRldi5wY2lfbGluay4yLiVsb2NhdGlv bjogaGFuZGxlPVxfU0JfLkxOS0MKZGV2LnBjaV9saW5rLjIuJXBucGluZm86IF9ISUQ9UE5QMEMw RiBfVUlEPTMKZGV2LnBjaV9saW5rLjIuJXBhcmVudDogYWNwaTAKZGV2LnBjaV9saW5rLjMuJWRl c2M6IEFDUEkgUENJIExpbmsgTE5LRApkZXYucGNpX2xpbmsuMy4lZHJpdmVyOiBwY2lfbGluawpk ZXYucGNpX2xpbmsuMy4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktECmRldi5wY2lfbGluay4z LiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD00CmRldi5wY2lfbGluay4zLiVwYXJlbnQ6IGFj cGkwCmRldi5wY2lfbGluay40LiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0UKZGV2LnBjaV9saW5r LjQuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjQuJWxvY2F0aW9uOiBoYW5kbGU9XF9T Ql8uTE5LRQpkZXYucGNpX2xpbmsuNC4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9VSUQ9NQpkZXYu cGNpX2xpbmsuNC4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuNS4lZGVzYzogQUNQSSBQQ0kg TGluayBMTktGCmRldi5wY2lfbGluay41LiVkcml2ZXI6IHBjaV9saW5rCmRldi5wY2lfbGluay41 LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLkxOS0YKZGV2LnBjaV9saW5rLjUuJXBucGluZm86IF9I SUQ9UE5QMEMwRiBfVUlEPTYKZGV2LnBjaV9saW5rLjUuJXBhcmVudDogYWNwaTAKZGV2LnBjaV9s aW5rLjYuJWRlc2M6IEFDUEkgUENJIExpbmsgTE5LRwpkZXYucGNpX2xpbmsuNi4lZHJpdmVyOiBw Y2lfbGluawpkZXYucGNpX2xpbmsuNi4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktHCmRldi5w Y2lfbGluay42LiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD03CmRldi5wY2lfbGluay42LiVw YXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay43LiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0gKZGV2 LnBjaV9saW5rLjcuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjcuJWxvY2F0aW9uOiBo YW5kbGU9XF9TQl8uTE5LSApkZXYucGNpX2xpbmsuNy4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9V SUQ9OApkZXYucGNpX2xpbmsuNy4lcGFyZW50OiBhY3BpMApkZXYuY3B1LjAuJWRlc2M6IEFDUEkg Q1BVCmRldi5jcHUuMC4lZHJpdmVyOiBjcHUKZGV2LmNwdS4wLiVsb2NhdGlvbjogaGFuZGxlPVxf UFJfLkNQVV8KZGV2LmNwdS4wLiVwbnBpbmZvOiBfSElEPW5vbmUgX1VJRD0wCmRldi5jcHUuMC4l cGFyZW50OiBhY3BpMApkZXYuY3B1LjAuZnJlcTogMjI2NgpkZXYuY3B1LjAuZnJlcV9sZXZlbHM6 IDIyNjYvMjcwMDAgMTk4Mi8yMzYyNSAxODY2LzIzNDAwIDE2MzIvMjA0NzUgMTYwMC8yMTAwMCAx NDAwLzE4Mzc1IDEzMzMvMTg2MDAgMTE2Ni8xNjI3NSAxMDY2LzE2MjAwIDkzMi8xNDE3NSA4MDAv MTM4MDAgNzAwLzEyMDc1IDYwMC8xMDM1MCA1MDAvODYyNSA0MDAvNjkwMCAzMDAvNTE3NSAyMDAv MzQ1MCAxMDAvMTcyNQpkZXYuY3B1LjAuY3hfc3VwcG9ydGVkOiBDMS8xIEMyLzEgQzMvODUKZGV2 LmNwdS4wLmN4X2xvd2VzdDogQzEKZGV2LmNwdS4wLmN4X3VzYWdlOiAxMDAuMDAlIDAuMDAlIDAu MDAlCmRldi5hY3BpX3BlcmYuMC4lZHJpdmVyOiBhY3BpX3BlcmYKZGV2LmFjcGlfcGVyZi4wLiVw YXJlbnQ6IGNwdTAKZGV2LmVzdC4wLiVkZXNjOiBFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5 IENvbnRyb2wKZGV2LmVzdC4wLiVkcml2ZXI6IGVzdApkZXYuZXN0LjAuJXBhcmVudDogY3B1MApk ZXYuZXN0LjAuZnJlcV9zZXR0aW5nczogMjI2Ni8yNzAwMCAxODY2LzIzNDAwIDE2MDAvMjEwMDAg MTMzMy8xODYwMCAxMDY2LzE2MjAwIDgwMC8xMzgwMApkZXYuY3B1ZnJlcS4wLiVkcml2ZXI6IGNw dWZyZXEKZGV2LmNwdWZyZXEuMC4lcGFyZW50OiBjcHUwCmRldi5wNHRjYy4wLiVkZXNjOiBDUFUg RnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbApkZXYucDR0Y2MuMC4lZHJpdmVyOiBwNHRjYwpkZXYu cDR0Y2MuMC4lcGFyZW50OiBjcHUwCmRldi5wNHRjYy4wLmZyZXFfc2V0dGluZ3M6IDEwMDAwLy0x IDg3NTAvLTEgNzUwMC8tMSA2MjUwLy0xIDUwMDAvLTEgMzc1MC8tMSAyNTAwLy0xIDEyNTAvLTEK ZGV2LmFjcGlfbGlkLjAuJWRlc2M6IENvbnRyb2wgTWV0aG9kIExpZCBTd2l0Y2gKZGV2LmFjcGlf bGlkLjAuJWRyaXZlcjogYWNwaV9saWQKZGV2LmFjcGlfbGlkLjAuJWxvY2F0aW9uOiBoYW5kbGU9 XF9TQl8uTElEXwpkZXYuYWNwaV9saWQuMC4lcG5waW5mbzogX0hJRD1QTlAwQzBEIF9VSUQ9MApk ZXYuYWNwaV9saWQuMC4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9saWQuMC53YWtlOiAxCmRldi5h Y3BpX2J1dHRvbi4wLiVkZXNjOiBTbGVlcCBCdXR0b24KZGV2LmFjcGlfYnV0dG9uLjAuJWRyaXZl cjogYWNwaV9idXR0b24KZGV2LmFjcGlfYnV0dG9uLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8u U0xQQgpkZXYuYWNwaV9idXR0b24uMC4lcG5waW5mbzogX0hJRD1QTlAwQzBFIF9VSUQ9MApkZXYu YWNwaV9idXR0b24uMC4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9idXR0b24uMC53YWtlOiAxCmRl di5wY2liLjAuJWRlc2M6IEFDUEkgSG9zdC1QQ0kgYnJpZGdlCmRldi5wY2liLjAuJWRyaXZlcjog cGNpYgpkZXYucGNpYi4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAKZGV2LnBjaWIuMC4l cG5waW5mbzogX0hJRD1QTlAwQTA4IF9VSUQ9MApkZXYucGNpYi4wLiVwYXJlbnQ6IGFjcGkwCmRl di5wY2liLjEuJWRlc2M6IEFDUEkgUENJLVBDSSBicmlkZ2UKZGV2LnBjaWIuMS4lZHJpdmVyOiBw Y2liCmRldi5wY2liLjEuJWxvY2F0aW9uOiBzbG90PTEgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8u UENJMC5BR1BfCmRldi5wY2liLjEuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjU5 MSBzdWJ2ZW5kb3I9MHgxMDE0IHN1YmRldmljZT0weDA1NzggY2xhc3M9MHgwNjA0MDAKZGV2LnBj aWIuMS4lcGFyZW50OiBwY2kwCmRldi5wY2liLjIuJWRlc2M6IEFDUEkgUENJLVBDSSBicmlkZ2UK ZGV2LnBjaWIuMi4lZHJpdmVyOiBwY2liCmRldi5wY2liLjIuJWxvY2F0aW9uOiBzbG90PTI4IGZ1 bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuRVhQMApkZXYucGNpYi4yLiVwbnBpbmZvOiB2ZW5k b3I9MHg4MDg2IGRldmljZT0weDI2NjAgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAw IGNsYXNzPTB4MDYwNDAwCmRldi5wY2liLjIuJXBhcmVudDogcGNpMApkZXYucGNpYi4yLndha2U6 IDAKZGV2LnBjaWIuMy4lZGVzYzogQUNQSSBQQ0ktUENJIGJyaWRnZQpkZXYucGNpYi4zLiVkcml2 ZXI6IHBjaWIKZGV2LnBjaWIuMy4lbG9jYXRpb246IHNsb3Q9MjggZnVuY3Rpb249MiBoYW5kbGU9 XF9TQl8uUENJMC5FWFAyCmRldi5wY2liLjMuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNl PTB4MjY2NCBzdWJ2ZW5kb3I9MHgwMDAwIHN1YmRldmljZT0weDAwMDAgY2xhc3M9MHgwNjA0MDAK ZGV2LnBjaWIuMy4lcGFyZW50OiBwY2kwCmRldi5wY2liLjMud2FrZTogMApkZXYucGNpYi40LiVk ZXNjOiBBQ1BJIFBDSS1QQ0kgYnJpZGdlCmRldi5wY2liLjQuJWRyaXZlcjogcGNpYgpkZXYucGNp Yi40LiVsb2NhdGlvbjogc2xvdD0zMCBmdW5jdGlvbj0wIGhhbmRsZT1cX1NCXy5QQ0kwLlBDSTEK ZGV2LnBjaWIuNC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyNDQ4IHN1YnZlbmRv cj0weDAwMDAgc3ViZGV2aWNlPTB4MDAwMCBjbGFzcz0weDA2MDQwMQpkZXYucGNpYi40LiVwYXJl bnQ6IHBjaTAKZGV2LnBjaWIuNC53YWtlOiAwCmRldi5wY2kuMC4lZGVzYzogQUNQSSBQQ0kgYnVz CmRldi5wY2kuMC4lZHJpdmVyOiBwY2kKZGV2LnBjaS4wLiVwYXJlbnQ6IHBjaWIwCmRldi5wY2ku MS4lZGVzYzogQUNQSSBQQ0kgYnVzCmRldi5wY2kuMS4lZHJpdmVyOiBwY2kKZGV2LnBjaS4xLiVw YXJlbnQ6IHBjaWIxCmRldi5wY2kuMi4lZGVzYzogQUNQSSBQQ0kgYnVzCmRldi5wY2kuMi4lZHJp dmVyOiBwY2kKZGV2LnBjaS4yLiVwYXJlbnQ6IHBjaWIyCmRldi5wY2kuMi53YWtlOiAwCmRldi5w Y2kuMy4lZGVzYzogQUNQSSBQQ0kgYnVzCmRldi5wY2kuMy4lZHJpdmVyOiBwY2kKZGV2LnBjaS4z LiVwYXJlbnQ6IHBjaWIzCmRldi5wY2kuMy53YWtlOiAwCmRldi5wY2kuMTEuJWRlc2M6IEFDUEkg UENJIGJ1cwpkZXYucGNpLjExLiVkcml2ZXI6IHBjaQpkZXYucGNpLjExLiVwYXJlbnQ6IHBjaWI0 CmRldi5wY2kuMTEud2FrZTogMApkZXYuaG9zdGIuMC4lZGVzYzogSG9zdCB0byBQQ0kgYnJpZGdl CmRldi5ob3N0Yi4wLiVkcml2ZXI6IGhvc3RiCmRldi5ob3N0Yi4wLiVsb2NhdGlvbjogc2xvdD0w IGZ1bmN0aW9uPTAKZGV2Lmhvc3RiLjAuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4 MjU5MCBzdWJ2ZW5kb3I9MHgxMDE0IHN1YmRldmljZT0weDA1NzUgY2xhc3M9MHgwNjAwMDAKZGV2 Lmhvc3RiLjAuJXBhcmVudDogcGNpMApkZXYudmdhcGNpLjAuJWRlc2M6IFZHQS1jb21wYXRpYmxl IGRpc3BsYXkKZGV2LnZnYXBjaS4wLiVkcml2ZXI6IHZnYXBjaQpkZXYudmdhcGNpLjAuJWxvY2F0 aW9uOiBzbG90PTAgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5BR1BfLlZJRF8KZGV2LnZn YXBjaS4wLiVwbnBpbmZvOiB2ZW5kb3I9MHgxMDAyIGRldmljZT0weDMxNTQgc3VidmVuZG9yPTB4 MTAxNCBzdWJkZXZpY2U9MHgwNTcwIGNsYXNzPTB4MDMwMDAwCmRldi52Z2FwY2kuMC4lcGFyZW50 OiBwY2kxCmRldi5iZ2UuMC4lZGVzYzogQnJvYWRjb20gTmV0WHRyZW1lIEdpZ2FiaXQgRXRoZXJu ZXQgQ29udHJvbGxlciwgQVNJQyByZXYuIDB4NDEwMQpkZXYuYmdlLjAuJWRyaXZlcjogYmdlCmRl di5iZ2UuMC4lbG9jYXRpb246IHNsb3Q9MCBmdW5jdGlvbj0wCmRldi5iZ2UuMC4lcG5waW5mbzog dmVuZG9yPTB4MTRlNCBkZXZpY2U9MHgxNjdkIHN1YnZlbmRvcj0weDEwMTQgc3ViZGV2aWNlPTB4 MDU3NyBjbGFzcz0weDAyMDAwMApkZXYuYmdlLjAuJXBhcmVudDogcGNpMgpkZXYubWlpYnVzLjAu JWRlc2M6IE1JSSBidXMKZGV2Lm1paWJ1cy4wLiVkcml2ZXI6IG1paWJ1cwpkZXYubWlpYnVzLjAu JXBhcmVudDogYmdlMApkZXYuYnJncGh5LjAuJWRlc2M6IEJDTTU3NTAgMTAvMTAwLzEwMDBiYXNl VFggUEhZCmRldi5icmdwaHkuMC4lZHJpdmVyOiBicmdwaHkKZGV2LmJyZ3BoeS4wLiVsb2NhdGlv bjogcGh5bm89MQpkZXYuYnJncGh5LjAuJXBucGluZm86IG91aT0weDgxOCBtb2RlbD0weDE4IHJl dj0weDAKZGV2LmJyZ3BoeS4wLiVwYXJlbnQ6IG1paWJ1czAKZGV2LnVoY2kuMC4lZGVzYzogSW50 ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1BCmRldi51aGNp LjAuJWRyaXZlcjogdWhjaQpkZXYudWhjaS4wLiVsb2NhdGlvbjogc2xvdD0yOSBmdW5jdGlvbj0w IGhhbmRsZT1cX1NCXy5QQ0kwLlVTQjAKZGV2LnVoY2kuMC4lcG5waW5mbzogdmVuZG9yPTB4ODA4 NiBkZXZpY2U9MHgyNjU4IHN1YnZlbmRvcj0weDEwMTQgc3ViZGV2aWNlPTB4MDU2NSBjbGFzcz0w eDBjMDMwMApkZXYudWhjaS4wLiVwYXJlbnQ6IHBjaTAKZGV2LnVoY2kuMC53YWtlOiAwCmRldi51 aGNpLjEuJWRlc2M6IEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxl ciBVU0ItQgpkZXYudWhjaS4xLiVkcml2ZXI6IHVoY2kKZGV2LnVoY2kuMS4lbG9jYXRpb246IHNs b3Q9MjkgZnVuY3Rpb249MSBoYW5kbGU9XF9TQl8uUENJMC5VU0IxCmRldi51aGNpLjEuJXBucGlu Zm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjY1OSBzdWJ2ZW5kb3I9MHgxMDE0IHN1YmRldmlj ZT0weDA1NjUgY2xhc3M9MHgwYzAzMDAKZGV2LnVoY2kuMS4lcGFyZW50OiBwY2kwCmRldi51aGNp LjEud2FrZTogMApkZXYudWhjaS4yLiVkZXNjOiBJbnRlbCA4MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNI NikgVVNCIGNvbnRyb2xsZXIgVVNCLUMKZGV2LnVoY2kuMi4lZHJpdmVyOiB1aGNpCmRldi51aGNp LjIuJWxvY2F0aW9uOiBzbG90PTI5IGZ1bmN0aW9uPTIgaGFuZGxlPVxfU0JfLlBDSTAuVVNCMgpk ZXYudWhjaS4yLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI2NWEgc3VidmVuZG9y PTB4MTAxNCBzdWJkZXZpY2U9MHgwNTY1IGNsYXNzPTB4MGMwMzAwCmRldi51aGNpLjIuJXBhcmVu dDogcGNpMApkZXYudWhjaS4zLiVkZXNjOiBJbnRlbCA4MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNINikg VVNCIGNvbnRyb2xsZXIgVVNCLUQKZGV2LnVoY2kuMy4lZHJpdmVyOiB1aGNpCmRldi51aGNpLjMu JWxvY2F0aW9uOiBzbG90PTI5IGZ1bmN0aW9uPTMgaGFuZGxlPVxfU0JfLlBDSTAuVVNCMwpkZXYu dWhjaS4zLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI2NWIgc3VidmVuZG9yPTB4 MTAxNCBzdWJkZXZpY2U9MHgwNTY1IGNsYXNzPTB4MGMwMzAwCmRldi51aGNpLjMuJXBhcmVudDog cGNpMApkZXYudWhjaS4zLndha2U6IDAKZGV2LnVzYi4wLiVkZXNjOiBJbnRlbCA4MjgwMUZCL0ZS L0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUEKZGV2LnVzYi4wLiVkcml2ZXI6IHVz YgpkZXYudXNiLjAuJXBhcmVudDogdWhjaTAKZGV2LnVzYi4xLiVkZXNjOiBJbnRlbCA4MjgwMUZC L0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUIKZGV2LnVzYi4xLiVkcml2ZXI6 IHVzYgpkZXYudXNiLjEuJXBhcmVudDogdWhjaTEKZGV2LnVzYi4yLiVkZXNjOiBJbnRlbCA4Mjgw MUZCL0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUMKZGV2LnVzYi4yLiVkcml2 ZXI6IHVzYgpkZXYudXNiLjIuJXBhcmVudDogdWhjaTIKZGV2LnVzYi4zLiVkZXNjOiBJbnRlbCA4 MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUQKZGV2LnVzYi4zLiVk cml2ZXI6IHVzYgpkZXYudXNiLjMuJXBhcmVudDogdWhjaTMKZGV2LnVzYi40LiVkZXNjOiBJbnRl bCA4MjgwMUZCIChJQ0g2KSBVU0IgMi4wIGNvbnRyb2xsZXIKZGV2LnVzYi40LiVkcml2ZXI6IHVz YgpkZXYudXNiLjQuJXBhcmVudDogZWhjaTAKZGV2LnVodWIuMC4lZGVzYzogSW50ZWwgVUhDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKZGV2LnVodWIuMC4lZHJp dmVyOiB1aHViCmRldi51aHViLjAuJXBhcmVudDogdXNiMApkZXYudWh1Yi4xLiVkZXNjOiBJbnRl bCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQpkZXYudWh1 Yi4xLiVkcml2ZXI6IHVodWIKZGV2LnVodWIuMS4lcGFyZW50OiB1c2IxCmRldi51aHViLjIuJWRl c2M6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx CmRldi51aHViLjIuJWRyaXZlcjogdWh1YgpkZXYudWh1Yi4yLiVwYXJlbnQ6IHVzYjIKZGV2LnVo dWIuMy4lZGVzYzogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAw LCBhZGRyIDEKZGV2LnVodWIuMy4lZHJpdmVyOiB1aHViCmRldi51aHViLjMuJXBhcmVudDogdXNi MwpkZXYudWh1Yi40LiVkZXNjOiBJbnRlbCBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAy LjAwLzEuMDAsIGFkZHIgMQpkZXYudWh1Yi40LiVkcml2ZXI6IHVodWIKZGV2LnVodWIuNC4lcGFy ZW50OiB1c2I0CmRldi5laGNpLjAuJWRlc2M6IEludGVsIDgyODAxRkIgKElDSDYpIFVTQiAyLjAg Y29udHJvbGxlcgpkZXYuZWhjaS4wLiVkcml2ZXI6IGVoY2kKZGV2LmVoY2kuMC4lbG9jYXRpb246 IHNsb3Q9MjkgZnVuY3Rpb249NyBoYW5kbGU9XF9TQl8uUENJMC5VU0I3CmRldi5laGNpLjAuJXBu cGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjY1YyBzdWJ2ZW5kb3I9MHgxMDE0IHN1YmRl dmljZT0weDA1NjYgY2xhc3M9MHgwYzAzMjAKZGV2LmVoY2kuMC4lcGFyZW50OiBwY2kwCmRldi5l aGNpLjAud2FrZTogMApkZXYuY2JiLjAuJWRlc2M6IFJGNUM0NzYgUENJLUNhcmRCdXMgQnJpZGdl CmRldi5jYmIuMC4lZHJpdmVyOiBjYmIKZGV2LmNiYi4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0 aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuUENJMS5DREJTCmRldi5jYmIuMC4lcG5waW5mbzogdmVu ZG9yPTB4MTE4MCBkZXZpY2U9MHgwNDc2IHN1YnZlbmRvcj0weDEwMTQgc3ViZGV2aWNlPTB4MDU2 YyBjbGFzcz0weDA2MDcwMApkZXYuY2JiLjAuJXBhcmVudDogcGNpMTEKZGV2LmNiYi4wLmRvbWFp bjogMApkZXYuY2JiLjAucHJpYnVzOiAxMQpkZXYuY2JiLjAuc2VjYnVzOiAxMgpkZXYuY2JiLjAu c3ViYnVzOiAxNApkZXYuY2FyZGJ1cy4lcGFyZW50OiBwY2kKZGV2LmNhcmRidXMuMC4lZGVzYzog Q2FyZEJ1cyBidXMKZGV2LmNhcmRidXMuMC4lZHJpdmVyOiBjYXJkYnVzCmRldi5jYXJkYnVzLjAu JXBhcmVudDogY2JiMApkZXYucGNjYXJkLjAuJWRlc2M6IDE2LWJpdCBQQ0NhcmQgYnVzCmRldi5w Y2NhcmQuMC4lZHJpdmVyOiBwY2NhcmQKZGV2LnBjY2FyZC4wLiVwYXJlbnQ6IGNiYjAKZGV2LmF0 aC4wLiVkZXNjOiBBdGhlcm9zIDUyMTIKZGV2LmF0aC4wLiVkcml2ZXI6IGF0aApkZXYuYXRoLjAu JWxvY2F0aW9uOiBzbG90PTIgZnVuY3Rpb249MApkZXYuYXRoLjAuJXBucGluZm86IHZlbmRvcj0w eDE2OGMgZGV2aWNlPTB4MTAxNCBzdWJ2ZW5kb3I9MHgxMDE0IHN1YmRldmljZT0weDA1N2UgY2xh c3M9MHgwMjAwMDAKZGV2LmF0aC4wLiVwYXJlbnQ6IHBjaTExCmRldi5hdGguMC5zbW9vdGhpbmdf cmF0ZTogOTUKZGV2LmF0aC4wLnNhbXBsZV9yYXRlOiAxMApkZXYuYXRoLjAuY291bnRyeWNvZGU6 IDAKZGV2LmF0aC4wLnJlZ2RvbWFpbjogMTAyCmRldi5hdGguMC5zbG90dGltZTogOQpkZXYuYXRo LjAuYWNrdGltZW91dDogNjUxCmRldi5hdGguMC5jdHN0aW1lb3V0OiA2OTgKZGV2LmF0aC4wLnNv ZnRsZWQ6IDEKZGV2LmF0aC4wLmxlZHBpbjogMApkZXYuYXRoLjAubGVkb246IDAKZGV2LmF0aC4w LmxlZGlkbGU6IDI3MDAKZGV2LmF0aC4wLnR4YW50ZW5uYTogMApkZXYuYXRoLjAucnhhbnRlbm5h OiAwCmRldi5hdGguMC5kaXZlcnNpdHk6IDEKZGV2LmF0aC4wLnR4aW50cnBlcmlvZDogNQpkZXYu YXRoLjAuZGlhZzogMApkZXYuYXRoLjAudHBzY2FsZTogMApkZXYuYXRoLjAudHBjOiAwCmRldi5h dGguMC50cGFjazogNjMKZGV2LmF0aC4wLnRwY3RzOiA2MwpkZXYuYXRoLjAuZmZ0eHFtaW46IDIK ZGV2LmF0aC4wLmZmdHhxbWF4OiA1MApkZXYuYXRoLjAucmZzaWxlbnQ6IDkKZGV2LmF0aC4wLnJm a2lsbDogMQpkZXYuYXRoLjAubW9ucGFzczogMjQKZGV2LnBjbS4wLiVkZXNjOiBJbnRlbCBJQ0g2 ICg4MjgwMUZCKQpkZXYucGNtLjAuJWRyaXZlcjogcGNtCmRldi5wY20uMC4lbG9jYXRpb246IHNs b3Q9MzAgZnVuY3Rpb249MiBoYW5kbGU9XF9TQl8uUENJMC5BQzlBCmRldi5wY20uMC4lcG5waW5m bzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyNjZlIHN1YnZlbmRvcj0weDEwMTQgc3ViZGV2aWNl PTB4MDU2NyBjbGFzcz0weDA0MDEwMApkZXYucGNtLjAuJXBhcmVudDogcGNpMApkZXYucGNtLjAu ZWFwZDogMQpkZXYucGNtLjAucGxheS52Y2hhbnM6IDEKZGV2LnBjbS4wLnBsYXkudmNoYW5yYXRl OiA0ODAwMApkZXYucGNtLjAucGxheS52Y2hhbmZvcm1hdDogczE2bGUKZGV2LnBjbS4wLnJlYy52 Y2hhbnM6IDEKZGV2LnBjbS4wLnJlYy52Y2hhbnJhdGU6IDQ4MDAwCmRldi5wY20uMC5yZWMudmNo YW5mb3JtYXQ6IHMxNmxlCmRldi5wY20uMC5idWZmZXJzaXplOiAxNjM4NApkZXYucGNtLjAuYWM5 N3JhdGU6IDQ4MDAwCmRldi5pc2FiLjAuJWRlc2M6IFBDSS1JU0EgYnJpZGdlCmRldi5pc2FiLjAu JWRyaXZlcjogaXNhYgpkZXYuaXNhYi4wLiVsb2NhdGlvbjogc2xvdD0zMSBmdW5jdGlvbj0wIGhh bmRsZT1cX1NCXy5QQ0kwLkxQQ18KZGV2LmlzYWIuMC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBk ZXZpY2U9MHgyNjQxIHN1YnZlbmRvcj0weDEwMTQgc3ViZGV2aWNlPTB4MDU2OCBjbGFzcz0weDA2 MDEwMApkZXYuaXNhYi4wLiVwYXJlbnQ6IHBjaTAKZGV2LmlzYS4wLiVkZXNjOiBJU0EgYnVzCmRl di5pc2EuMC4lZHJpdmVyOiBpc2EKZGV2LmlzYS4wLiVwYXJlbnQ6IGlzYWIwCmRldi5hdGFwY2ku MC4lZGVzYzogSW50ZWwgSUNINk0gU0FUQTE1MCBjb250cm9sbGVyCmRldi5hdGFwY2kuMC4lZHJp dmVyOiBhdGFwY2kKZGV2LmF0YXBjaS4wLiVsb2NhdGlvbjogc2xvdD0zMSBmdW5jdGlvbj0yIGhh bmRsZT1cX1NCXy5QQ0kwLklERTAKZGV2LmF0YXBjaS4wLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2 IGRldmljZT0weDI2NTMgc3VidmVuZG9yPTB4MTAxNCBzdWJkZXZpY2U9MHgwNTZhIGNsYXNzPTB4 MDEwMTgwCmRldi5hdGFwY2kuMC4lcGFyZW50OiBwY2kwCmRldi5hdGEuMC4lZGVzYzogQVRBIGNo YW5uZWwgMApkZXYuYXRhLjAuJWRyaXZlcjogYXRhCmRldi5hdGEuMC4lcGFyZW50OiBhdGFwY2kw CmRldi5hdGEuMS4lZGVzYzogQVRBIGNoYW5uZWwgMQpkZXYuYXRhLjEuJWRyaXZlcjogYXRhCmRl di5hdGEuMS4lcGFyZW50OiBhdGFwY2kwCmRldi5pY2hzbWIuMC4lZGVzYzogSW50ZWwgODI4MDFG QiAoSUNINikgU01CdXMgY29udHJvbGxlcgpkZXYuaWNoc21iLjAuJWRyaXZlcjogaWNoc21iCmRl di5pY2hzbWIuMC4lbG9jYXRpb246IHNsb3Q9MzEgZnVuY3Rpb249MyBoYW5kbGU9XF9TQl8uUENJ MC5TTUJVCmRldi5pY2hzbWIuMC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyNjZh IHN1YnZlbmRvcj0weDEwMTQgc3ViZGV2aWNlPTB4MDU2YiBjbGFzcz0weDBjMDUwMApkZXYuaWNo c21iLjAuJXBhcmVudDogcGNpMApkZXYuc21idXMuMC4lZGVzYzogU3lzdGVtIE1hbmFnZW1lbnQg QnVzCmRldi5zbWJ1cy4wLiVkcml2ZXI6IHNtYnVzCmRldi5zbWJ1cy4wLiVwYXJlbnQ6IGljaHNt YjAKZGV2LmFjcGlfdHouMC4lZGVzYzogVGhlcm1hbCBab25lCmRldi5hY3BpX3R6LjAuJWRyaXZl cjogYWNwaV90egpkZXYuYWNwaV90ei4wLiVsb2NhdGlvbjogaGFuZGxlPVxfVFpfLlRITTAKZGV2 LmFjcGlfdHouMC4lcG5waW5mbzogX0hJRD1ub25lIF9VSUQ9MApkZXYuYWNwaV90ei4wLiVwYXJl bnQ6IGFjcGkwCmRldi5hdHBpYy4wLiVkZXNjOiBBVCBpbnRlcnJ1cHQgY29udHJvbGxlcgpkZXYu YXRwaWMuMC4lZHJpdmVyOiBhdHBpYwpkZXYuYXRwaWMuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NC Xy5QQ0kwLkxQQ18uUElDXwpkZXYuYXRwaWMuMC4lcG5waW5mbzogX0hJRD1QTlAwMDAwIF9VSUQ9 MApkZXYuYXRwaWMuMC4lcGFyZW50OiBhY3BpMApkZXYuYXR0aW1lci4wLiVkZXNjOiBBVCB0aW1l cgpkZXYuYXR0aW1lci4wLiVkcml2ZXI6IGF0dGltZXIKZGV2LmF0dGltZXIuMC4lbG9jYXRpb246 IGhhbmRsZT1cX1NCXy5QQ0kwLkxQQ18uVElNUgpkZXYuYXR0aW1lci4wLiVwbnBpbmZvOiBfSElE PVBOUDAxMDAgX1VJRD0wCmRldi5hdHRpbWVyLjAuJXBhcmVudDogYWNwaTAKZGV2LmF0dGltZXIu MS4lZGVzYzogQVQgcmVhbHRpbWUgY2xvY2sKZGV2LmF0dGltZXIuMS4lZHJpdmVyOiBhdHRpbWVy CmRldi5hdHRpbWVyLjEuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MUENfLlJUQ18KZGV2 LmF0dGltZXIuMS4lcG5waW5mbzogX0hJRD1QTlAwQjAwIF9VSUQ9MApkZXYuYXR0aW1lci4xLiVw YXJlbnQ6IGFjcGkwCmRldi5hdGRtYS4wLiVkZXNjOiBBVCBETUEgY29udHJvbGxlcgpkZXYuYXRk bWEuMC4lZHJpdmVyOiBhdGRtYQpkZXYuYXRkbWEuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5Q Q0kwLkxQQ18uRE1BQwpkZXYuYXRkbWEuMC4lcG5waW5mbzogX0hJRD1QTlAwMjAwIF9VSUQ9MApk ZXYuYXRkbWEuMC4lcGFyZW50OiBhY3BpMApkZXYubnB4aXNhLjAuJWRlc2M6IExlZ2FjeSBJU0Eg Y29wcm9jZXNzb3Igc3VwcG9ydApkZXYubnB4aXNhLjAuJWRyaXZlcjogbnB4aXNhCmRldi5ucHhp c2EuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLkxQQ18uRlBVXwpkZXYubnB4aXNhLjAu JXBucGluZm86IF9ISUQ9UE5QMEMwNCBfVUlEPTAKZGV2Lm5weGlzYS4wLiVwYXJlbnQ6IGFjcGkw CmRldi5hdGtiZGMuMC4lZGVzYzogS2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpCmRldi5hdGti ZGMuMC4lZHJpdmVyOiBhdGtiZGMKZGV2LmF0a2JkYy4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0Jf LlBDSTAuTFBDXy5LQkRfCmRldi5hdGtiZGMuMC4lcG5waW5mbzogX0hJRD1QTlAwMzAzIF9VSUQ9 MApkZXYuYXRrYmRjLjAuJXBhcmVudDogYWNwaTAKZGV2LmF0a2JkLjAuJWRlc2M6IEFUIEtleWJv YXJkCmRldi5hdGtiZC4wLiVkcml2ZXI6IGF0a2JkCmRldi5hdGtiZC4wLiVwYXJlbnQ6IGF0a2Jk YzAKZGV2LnBzbWNwbnAuMC4lZGVzYzogUFMvMiBtb3VzZSBwb3J0CmRldi5wc21jcG5wLjAuJWRy aXZlcjogcHNtY3BucApkZXYucHNtY3BucC4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAu TFBDXy5NT1VfCmRldi5wc21jcG5wLjAuJXBucGluZm86IF9ISUQ9SUJNMDA1NyBfVUlEPTAKZGV2 LnBzbWNwbnAuMC4lcGFyZW50OiBhY3BpMApkZXYucHNtLjAuJWRlc2M6IFBTLzIgTW91c2UKZGV2 LnBzbS4wLiVkcml2ZXI6IHBzbQpkZXYucHNtLjAuJXBhcmVudDogYXRrYmRjMApkZXYuc2lvLjAu JWRlc2M6IDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0CmRldi5zaW8uMC4lZHJpdmVyOiBzaW8K ZGV2LnNpby4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTFBDXy5VQVJUCmRldi5zaW8u MC4lcG5waW5mbzogX0hJRD1QTlAwNTAxIF9VSUQ9MApkZXYuc2lvLjAuJXBhcmVudDogYWNwaTAK ZGV2LnNpby4wLndha2U6IDAKZGV2LmJhdHRlcnkuMC4lZGVzYzogQUNQSSBDb250cm9sIE1ldGhv ZCBCYXR0ZXJ5CmRldi5iYXR0ZXJ5LjAuJWRyaXZlcjogYmF0dGVyeQpkZXYuYmF0dGVyeS4wLiVs b2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTFBDXy5FQ19fLkJBVDAKZGV2LmJhdHRlcnkuMC4l cG5waW5mbzogX0hJRD1QTlAwQzBBIF9VSUQ9MApkZXYuYmF0dGVyeS4wLiVwYXJlbnQ6IGFjcGkw CmRldi5hY3BpX2FjYWQuMC4lZGVzYzogQUMgQWRhcHRlcgpkZXYuYWNwaV9hY2FkLjAuJWRyaXZl cjogYWNwaV9hY2FkCmRldi5hY3BpX2FjYWQuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kw LkxQQ18uRUNfXy5BQ19fCmRldi5hY3BpX2FjYWQuMC4lcG5waW5mbzogX0hJRD1BQ1BJMDAwMyBf VUlEPTAKZGV2LmFjcGlfYWNhZC4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hcGljLjAuJWRlc2M6IEFQ SUMgcmVzb3VyY2VzCmRldi5hcGljLjAuJWRyaXZlcjogYXBpYwpkZXYuYXBpYy4wLiVwYXJlbnQ6 IG5leHVzMApkZXYucG10aW1lci4wLiVkcml2ZXI6IHBtdGltZXIKZGV2LnBtdGltZXIuMC4lcGFy ZW50OiBpc2EwCmRldi5vcm0uMC4lZGVzYzogSVNBIE9wdGlvbiBST01zCmRldi5vcm0uMC4lZHJp dmVyOiBvcm0KZGV2Lm9ybS4wLiVwbnBpbmZvOiBwbnBpZD1PUk0wMDAwCmRldi5vcm0uMC4lcGFy ZW50OiBpc2EwCmRldi5wcGMuMC4lZGVzYzogUGFyYWxsZWwgcG9ydApkZXYucHBjLjAuJWRyaXZl cjogcHBjCmRldi5wcGMuMC4lcGFyZW50OiBpc2EwCmRldi5wcGJ1cy4wLiVkZXNjOiBQYXJhbGxl bCBwb3J0IGJ1cwpkZXYucHBidXMuMC4lZHJpdmVyOiBwcGJ1cwpkZXYucHBidXMuMC4lcGFyZW50 OiBwcGMwCmRldi5wbGlwLjAuJWRlc2M6IFBMSVAgbmV0d29yayBpbnRlcmZhY2UKZGV2LnBsaXAu MC4lZHJpdmVyOiBwbGlwCmRldi5wbGlwLjAuJXBhcmVudDogcHBidXMwCmRldi5scHQuMC4lZGVz YzogUHJpbnRlcgpkZXYubHB0LjAuJWRyaXZlcjogbHB0CmRldi5scHQuMC4lcGFyZW50OiBwcGJ1 czAKZGV2LnBwaS4wLiVkZXNjOiBQYXJhbGxlbCBJL08KZGV2LnBwaS4wLiVkcml2ZXI6IHBwaQpk ZXYucHBpLjAuJXBhcmVudDogcHBidXMwCmRldi5zYy4wLiVkZXNjOiBTeXN0ZW0gY29uc29sZQpk ZXYuc2MuMC4lZHJpdmVyOiBzYwpkZXYuc2MuMC4lcGFyZW50OiBpc2EwCmRldi52Z2EuMC4lZGVz YzogR2VuZXJpYyBJU0EgVkdBCmRldi52Z2EuMC4lZHJpdmVyOiB2Z2EKZGV2LnZnYS4wLiVwYXJl bnQ6IGlzYTAKZGV2LnVnZW4uMC4lZGVzYzogU1RNaWNyb2VsZWN0cm9uaWNzIEJpb21ldHJpYyBD b3Byb2Nlc3NvciwgY2xhc3MgMC8wLCByZXYgMS4wMC8wLjAxLCBhZGRyIDIKZGV2LnVnZW4uMC4l ZHJpdmVyOiB1Z2VuCmRldi51Z2VuLjAuJWxvY2F0aW9uOiBwb3J0PTEKZGV2LnVnZW4uMC4lcG5w aW5mbzogdmVuZG9yPTB4MDQ4MyBwcm9kdWN0PTB4MjAxNiBkZXZjbGFzcz0weDAwIGRldnN1YmNs YXNzPTB4MDAgcmVsZWFzZT0weDAwMDEgc2VybnVtPSIiCmRldi51Z2VuLjAuJXBhcmVudDogdWh1 YjIKZGV2LmFkLjAuJWRlc2M6IFNUOTEwMDIxQS8zLjA0CmRldi5hZC4wLiVkcml2ZXI6IGFkCmRl di5hZC4wLiVwYXJlbnQ6IGF0YTAKZGV2LnN1YmRpc2suMC4lZHJpdmVyOiBzdWJkaXNrCmRldi5z dWJkaXNrLjAuJXBhcmVudDogYWQwCmRldi5hY2QuMC4lZGVzYzogTUFUU0hJVEFEVkQtUkFNIFVK LTg1Mi9SQjAxCmRldi5hY2QuMC4lZHJpdmVyOiBhY2QKZGV2LmFjZC4wLiVwYXJlbnQ6IGF0YTEK ZGV2LnVtYXNzLjAuJWRlc2M6IHZlbmRvciAweDBkN2QgVVNCIERJU0sgMjVYLCBjbGFzcyAwLzAs IHJldiAyLjAwLzEuMDAsIGFkZHIgMgpkZXYudW1hc3MuMC4lZHJpdmVyOiB1bWFzcwpkZXYudW1h c3MuMC4lbG9jYXRpb246IHBvcnQ9MyBpbnRlcmZhY2U9MApkZXYudW1hc3MuMC4lcG5waW5mbzog dmVuZG9yPTB4MGQ3ZCBwcm9kdWN0PTB4MTkwMCBkZXZjbGFzcz0weDAwIGRldnN1YmNsYXNzPTB4 MDAgcmVsZWFzZT0weDAxMDAgc2VybnVtPSIwNzU0MTE5MTMxQkQiIGludGNsYXNzPTB4MDggaW50 c3ViY2xhc3M9MHgwNgpkZXYudW1hc3MuMC4lcGFyZW50OiB1aHViNApocHRtdi5zdGF0dXM6IFJv Y2tldFJBSUQgMTgyeCBTQVRBIENvbnRyb2xsZXIgZHJpdmVyIFZlcnNpb24gdjEuMTIKCg== ------=_Part_56_30755184.1205803276757-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 02:49:04 2008 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 F0C47106564A; Tue, 18 Mar 2008 02:49:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B12498FC12; Tue, 18 Mar 2008 02:49:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2I2n48u075798; Mon, 17 Mar 2008 22:49:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2I2n3k8044748; Mon, 17 Mar 2008 22:49:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9EE4873039; Mon, 17 Mar 2008 21:49:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080318024903.9EE4873039@freebsd-current.sentex.ca> Date: Mon, 17 Mar 2008 21:49:03 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 02:49:05 -0000 TB --- 2008-03-18 01:47:05 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-18 01:47:05 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-03-18 01:47:05 - cleaning the object tree TB --- 2008-03-18 01:47:26 - cvsupping the source tree TB --- 2008-03-18 01:47:26 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-03-18 01:47:32 - building world (CFLAGS=-O -pipe) TB --- 2008-03-18 01:47:32 - cd /src TB --- 2008-03-18 01:47:32 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 18 01:47:35 UTC 2008 >>> 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 Tue Mar 18 02:43:01 UTC 2008 TB --- 2008-03-18 02:43:01 - generating LINT kernel config TB --- 2008-03-18 02:43:01 - cd /src/sys/sun4v/conf TB --- 2008-03-18 02:43:01 - /usr/bin/make -B LINT TB --- 2008-03-18 02:43:01 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-18 02:43:01 - cd /src TB --- 2008-03-18 02:43:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 18 02:43:01 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc1: warnings being treated as errors /src/sys/sun4v/sun4v/intr_machdep.c: In function 'inthand_add': /src/sys/sun4v/sun4v/intr_machdep.c:362: warning: passing argument 6 of 'intr_event_create' from incompatible pointer type /src/sys/sun4v/sun4v/intr_machdep.c:362: warning: passing argument 7 of 'intr_event_create' makes pointer from integer without a cast /src/sys/sun4v/sun4v/intr_machdep.c:362: error: too few arguments to function 'intr_event_create' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-18 02:49:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-18 02:49:03 - ERROR: failed to build lint kernel TB --- 2008-03-18 02:49:03 - tinderbox aborted TB --- 2924.42 user 352.65 system 3718.43 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 03:00:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF2C01065671 for ; Tue, 18 Mar 2008 03:00:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0C98FC14 for ; Tue, 18 Mar 2008 03:00:00 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so7172711fka.11 for ; Mon, 17 Mar 2008 20:00:00 -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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MeFTz1Km6IgI95vTIKSmqucmsK6QtlzOFWQpzHthotc=; b=edvOwkJ1xnvIeazcG6P5s13qouYYnjLn6wRxP2fgy6XBRqSxxXDe4FvvkQCIzBGCkTjgiqaxTwtNFrhAWRc09ci7WngtUgP6cIt8mR4tKitjJZqPvClbT8pTRM3SSZZmA/tCB7ZyZS6+O83RXNIsLoBuN3ionj+dbjF9Uup0TAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hbCZpn2ezvTPIVl8oKNXJYhYQSpHyvhuSVx+FJX01atxXJSiGVHXhNYHTpFNypoD3xzxalWb339ZdaoX2RXveWu19gG7AiM/NUdRqOuOw2uYCgVfRRXoNkhiCTZLHBBHR6kEt3EVE5XE3tuAwMmrNO8jRtOypxTSthYWfNAMj+w= Received: by 10.78.122.16 with SMTP id u16mr995082huc.11.1205809199856; Mon, 17 Mar 2008 19:59:59 -0700 (PDT) Received: by 10.78.16.10 with HTTP; Mon, 17 Mar 2008 19:59:59 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 05:59:59 +0300 From: pluknet To: "Alex Goncharov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 03:00:02 -0000 On 18/03/2008, Alex Goncharov wrote: > [ Sorry if this is old news or not useful ] > > I am trying to source-upgrade one of my 7.0 systems to 8.0-CURRENT. > > In the following, when I say "build", it means "csup and build right > away". > > The very first 8.0 build (this morning) gave me the kernel that didn't > boot. Built it again, finishing about 15 minutes ago. This one > booted all right but I see this in `/var/log/messages': > [there was stripped LORs] It's due to recent WITNESS lockmgr support that unhides existing LORs. Thought taking that into account I could obtain a new one yesterday. I didn't see this before. Mar 17 03:17:14 pl sudo: pluknet : TTY=ttyv1 ; PWD=/usr/home/pluknet ; USER=root ; COMMAND=/usr/libexec/getty 3wire.9600 ttyd0 Mar 17 03:17:14 pl kernel: lock order reversal: Mar 17 03:17:14 pl kernel: 1st 0xc07e9274 proctree (proctree) @ /usr/src/sys/kern/kern_exit.c:291 Mar 17 03:17:14 pl kernel: 2nd 0xc2fc49e8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 08:53:41 2008 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 59D411065671; Tue, 18 Mar 2008 08:53:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 297DA8FC22; Tue, 18 Mar 2008 08:53:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2I8reuw095504; Tue, 18 Mar 2008 04:53:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2I8rcBx033043; Tue, 18 Mar 2008 04:53:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 001D873039; Tue, 18 Mar 2008 03:53:37 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080318085338.001D873039@freebsd-current.sentex.ca> Date: Tue, 18 Mar 2008 03:53:37 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 16:43:31 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 08:53:41 -0000 TB --- 2008-03-18 07:45:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-18 07:45:53 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-03-18 07:45:53 - cleaning the object tree TB --- 2008-03-18 07:46:18 - cvsupping the source tree TB --- 2008-03-18 07:46:18 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-03-18 07:46:25 - building world (CFLAGS=-O -pipe) TB --- 2008-03-18 07:46:25 - cd /src TB --- 2008-03-18 07:46:25 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 18 07:46:27 UTC 2008 >>> 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 Tue Mar 18 08:47:35 UTC 2008 TB --- 2008-03-18 08:47:35 - generating LINT kernel config TB --- 2008-03-18 08:47:35 - cd /src/sys/sun4v/conf TB --- 2008-03-18 08:47:35 - /usr/bin/make -B LINT TB --- 2008-03-18 08:47:35 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-18 08:47:35 - cd /src TB --- 2008-03-18 08:47:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 18 08:47:35 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc1: warnings being treated as errors /src/sys/sun4v/sun4v/intr_machdep.c: In function 'inthand_add': /src/sys/sun4v/sun4v/intr_machdep.c:362: warning: passing argument 6 of 'intr_event_create' from incompatible pointer type /src/sys/sun4v/sun4v/intr_machdep.c:362: warning: passing argument 7 of 'intr_event_create' makes pointer from integer without a cast /src/sys/sun4v/sun4v/intr_machdep.c:362: error: too few arguments to function 'intr_event_create' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-18 08:53:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-18 08:53:37 - ERROR: failed to build lint kernel TB --- 2008-03-18 08:53:37 - tinderbox aborted TB --- 2926.39 user 357.96 system 4063.97 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 09:15:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42104106566C for ; Tue, 18 Mar 2008 09:15:11 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id EEA558FC13 for ; Tue, 18 Mar 2008 09:15:10 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbXuU-0003Pv-Jl for freebsd-current@freebsd.org; Tue, 18 Mar 2008 09:15:06 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Mar 2008 09:15:06 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Mar 2008 09:15:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Vadim Goncharov Date: Tue, 18 Mar 2008 09:14:54 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 27 Message-ID: References: <200803141508.m2EF86Jl068931@lurza.secnetix.de> <20080317111741.GB6353@leia.lambermont.dyndns.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Hans Lambermont User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 09:15:11 -0000 Hi Hans Lambermont! On Mon, 17 Mar 2008 12:17:41 +0100; Hans Lambermont wrote about 'Re: RELEASE discs & ISO images (for future)': >>> Therefore, my opinion is that we should publish a DVD image in the >>> future that contains everything we have today on disc{1,2,3} docs >>> and livefs CD. The size of such an DVD would be 1.95 GB for >>> 7.0-RELEASE/i386. >>> >>> For those who don't want or need packages and docs, a smaller CD >>> image with just the install bits (and maybe the fixit FS) could be >>> provided, and of course the small "bootonly" image, but nothing >>> else. Providing five or more CD images is rather last century like, >>> in my opinion. >> >> Yes, but DVD is still in the future. > Why ? I've used Dru's nice blog at > http://blogs.ittoolbox.com/unix/bsd/archives/creating-your-own-freebsd-70-dvd-22791 > (slightly adapted, using mdconfig -d -u /dev/md0) to create my own > bootable dvd (of disc[1-3].iso and docs.iso) in only a few minutes time. Yours own, but not official. I've heard of custom-made DVDs from early 5.x, but that's not an option for novice user. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 09:30:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E65A106569C for ; Tue, 18 Mar 2008 09:30:48 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id DA4C98FC6D for ; Tue, 18 Mar 2008 09:30:47 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by an-out-0708.google.com with SMTP id c16so1534830ana.7 for ; Tue, 18 Mar 2008 02:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=CuFafXvOEZ67aJiahuNsutcnPdXrhYyGvq3u8mujIRQ=; b=FM/lyDFLjX/yGwBe81V9U4DZDBtCEKsmyKmg8JT8ysM14ploGWub+hbamG5aJ7VMxSkvlzb8MnV7inrxlQOC1sKJnWpYX6K7qNBx941IfmrYNzumrUz8fb6hkml6t/snqMWN9wMqxKyKEl5niD89rt5jHFifHV5QImoxJcuUu1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=ENYXN6HYZblkdycAs8LeJYDy47CQ/85QQdS0ivEim8uBQxVlNN6+45y3hL8g54g5fWygXUsqrwJdou0jt77T5KeTD0nwJk+qbkW3E+poRsAIGEOEZ8oM6F5c+6Y2cbua9+zEZTKnpOlrTsen1dg26mpX8lixyHFwxTPGhxsdnLU= Received: by 10.100.122.8 with SMTP id u8mr1167226anc.46.1205832646669; Tue, 18 Mar 2008 02:30:46 -0700 (PDT) Received: from ?192.168.10.43? ( [99.139.48.67]) by mx.google.com with ESMTPS id i27sm2662160elf.14.2008.03.18.02.30.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 02:30:45 -0700 (PDT) Message-Id: <0A4EDB60-F18F-4964-B151-F2DD8D674C69@gmail.com> From: Garrett Cooper To: Ivan Voras In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 18 Mar 2008 02:30:42 -0700 References: <20080316222433.GA20366@what-creek.com> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: DTrace support in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 09:30:48 -0000 On Mar 17, 2008, at 11:27 AM, Ivan Voras wrote: > John Birrell wrote: >> This is an early headsup for DTrace support being committed >> to current. I plan to start committing stuff bit-by-bit >> starting a week from now, subject to review of the bits. > > Great news! Could you perhaps update the information on http://dtrace.what-creek.com/ > ? +1 to that. Thank you very much for all of your work over the past couple months John :). -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 11:44:39 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88CE0106566C for ; Tue, 18 Mar 2008 11:44:39 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 08FE58FC26 for ; Tue, 18 Mar 2008 11:44:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m2IBiYo9012405; Tue, 18 Mar 2008 12:44:37 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m2IBiWRb012404; Tue, 18 Mar 2008 12:44:32 +0100 (CET) (envelope-from olli) Date: Tue, 18 Mar 2008 12:44:32 +0100 (CET) Message-Id: <200803181144.m2IBiWRb012404@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, vadim_nuclight@mail.ru In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 18 Mar 2008 12:44:37 +0100 (CET) Cc: Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 11:44:39 -0000 Vadim Goncharov wrote: > Hans Lambermont wrote: > > [...] > > > > Therefore, my opinion is that we should publish a DVD image in the > > > > future that contains everything we have today on disc{1,2,3} docs > > > > and livefs CD. The size of such an DVD would be 1.95 GB for > > > > 7.0-RELEASE/i386. > > > > > > > > For those who don't want or need packages and docs, a smaller CD > > > > image with just the install bits (and maybe the fixit FS) could be > > > > provided, and of course the small "bootonly" image, but nothing > > > > else. Providing five or more CD images is rather last century like, > > > > in my opinion. > > > > > > Yes, but DVD is still in the future. > > Why ? I've used Dru's nice blog at > > http://blogs.ittoolbox.com/unix/bsd/archives/creating-your-own-freebsd-70-dvd-22791 > > (slightly adapted, using mdconfig -d -u /dev/md0) to create my own > > bootable dvd (of disc[1-3].iso and docs.iso) in only a few minutes time. > > Yours own, but not official. What is the practical difference? It's quite easy do create such a DVD, even for FreeBSD novice users. I've also mentioned several times (and you have ignored it several times) that you can buy an official DVD. Some vendors also offer FreeBSD DVDs for very low prices, e.g. the FreeBSD 7.0 DVD (double layer, i.e. 8 GB) from the German Lehmanns bookshop is 10 Euro, that's $6.50. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "When your hammer is C++, everything begins to look like a thumb." -- Steve Haflich, in comp.lang.c++ From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 12:21:22 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ACED106564A for ; Tue, 18 Mar 2008 12:21:22 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.freebsd.org (Postfix) with ESMTP id E889B8FC21 for ; Tue, 18 Mar 2008 12:21:21 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (qmail 25904 invoked by uid 89); 18 Mar 2008 12:20:05 -0000 Received: by simscan 1.1.0 ppid: 25861, pid: 25863, t: 5.0219s scanners: attach: 1.1.0 clamav: 0.88.7/m:44/d:4673 spam: 3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bsd.ultra-secure.de X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from unknown (HELO ?212.71.117.70?) (rainer@ultra-secure.de@212.71.117.70) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Mar 2008 12:20:00 -0000 Message-ID: <47DFB3BA.9070008@ultra-secure.de> Date: Tue, 18 Mar 2008 13:21:14 +0100 From: Rainer Duffner User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG References: <200803181144.m2IBiWRb012404@lurza.secnetix.de> In-Reply-To: <200803181144.m2IBiWRb012404@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 12:21:22 -0000 Oliver Fromme schrieb: > Vadim Goncharov wrote: > > Hans Lambermont wrote: > > > [...] > > > > > Therefore, my opinion is that we should publish a DVD image in the > > > > > future that contains everything we have today on disc{1,2,3} docs > > > > > and livefs CD. The size of such an DVD would be 1.95 GB for > > > > > 7.0-RELEASE/i386. > > > > > > > > > > For those who don't want or need packages and docs, a smaller CD > > > > > image with just the install bits (and maybe the fixit FS) could be > > > > > provided, and of course the small "bootonly" image, but nothing > > > > > else. Providing five or more CD images is rather last century like, > > > > > in my opinion. > > > > > > > > Yes, but DVD is still in the future. > > > Why ? I've used Dru's nice blog at > > > http://blogs.ittoolbox.com/unix/bsd/archives/creating-your-own-freebsd-70-dvd-22791 > > > (slightly adapted, using mdconfig -d -u /dev/md0) to create my own > > > bootable dvd (of disc[1-3].iso and docs.iso) in only a few minutes time. > > > > Yours own, but not official. > > What is the practical difference? It's quite easy do > create such a DVD, even for FreeBSD novice users. > > I've also mentioned several times (and you have ignored > it several times) that you can buy an official DVD. Yeah, but he wants an official, rubber-stamp kind-of, Daemon-branded, ISO. ;-) Must order one of these DVDs myself, though. cheers, Rainer From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 12:36:20 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33FB1065670 for ; Tue, 18 Mar 2008 12:36:20 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3BBDF8FC21 for ; Tue, 18 Mar 2008 12:36:20 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m2ICaIiA014653; Tue, 18 Mar 2008 13:36:18 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m2ICaI4P014652; Tue, 18 Mar 2008 13:36:18 +0100 (CET) (envelope-from olli) Date: Tue, 18 Mar 2008 13:36:18 +0100 (CET) Message-Id: <200803181236.m2ICaI4P014652@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, vadim_nuclight@mail.ru In-Reply-To: <200803181144.m2IBiWRb012404@lurza.secnetix.de> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 18 Mar 2008 13:36:19 +0100 (CET) Cc: Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 12:36:20 -0000 Oliver Fromme wrote: > Some vendors also offer FreeBSD DVDs for very low prices, > e.g. the FreeBSD 7.0 DVD (double layer, i.e. 8 GB) from > the German Lehmanns bookshop is 10 Euro, that's $6.50. I'm very sorry I got the exchange rate wrong. 10 Euro is rather more like $15 US. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible." -- John William Chambless From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 13:59:59 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8350106566B for ; Tue, 18 Mar 2008 13:59:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC0B8FC13 for ; Tue, 18 Mar 2008 13:59:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m2IDxqTs017639; Tue, 18 Mar 2008 14:59:57 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m2IDxpdW017638; Tue, 18 Mar 2008 14:59:51 +0100 (CET) (envelope-from olli) Date: Tue, 18 Mar 2008 14:59:51 +0100 (CET) Message-Id: <200803181359.m2IDxpdW017638@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, vadim_nuclight@mail.ru In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 18 Mar 2008 14:59:58 +0100 (CET) Cc: Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 13:59:59 -0000 Vadim Goncharov wrote: > Oliver Fromme wrote: > > [...] > > > > 224655360 7.0-RELEASE-i386-livefs.iso > > > > 94493696 7.0-RELEASE-i386-livefs.iso.uzip (16k cluster) > > > > 110188032 7.0-RELEASE-i386-livefs.iso.uzip (2K cluster) > > > > > > > > So the difference is 124 MB for 16K cluster size, and > > > > 109 MB for 2K cluster size (which is noticably faster > > > > during access). Actually the space savings will be a > > > > bit less, because the /boot directory (about 30 MB) > > > > won't be compressed. So the real gain is probably a > > > > little less than 100 MB in the 2K case. > > > > > > By the way, the maxmum cluster size is 127k or 130048 with uzip, > > > if you want to maximize the compression ratio. > > That would make the live FS painfully slow, and it wouldn't > > make a big difference from the default (16K). > > It is already noticeably slow with the default cluster size > > of 16K on my test machine (a 1 GHz VIA C3), so would rather > > prefer to use 2K cluster size, even though compression will > > be not quite as good. (2K is the minimum, less than that > > doesn't make sense for CD9660 media because the physical > > sector size is 2K.) > > How much is slowdown from 2K to 16K ? It's very noticeable. I haven't done benchmarks, but you can clearly feel the difference. A find(1) takes more time. Also man(1) takes longer until the page comes up. Any kind of random access is slower, unless all data is already cached. Interestingly there doesn't seem to be a difference between 2K and 4K, and the difference to 8K is only very small. But there is a noticeable difference between 8K and 16K. I don't know why, maybe it's related to FreeBSD's handling of FS buffers. So maybe the "optimal" cluster size for an acceptable performance/compression ratio would be 8K. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing." -- Dick Brandon From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 14:29:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1BC106566C for ; Tue, 18 Mar 2008 14:29:13 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id A026D8FC1E for ; Tue, 18 Mar 2008 14:29:12 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 18 Mar 2008 10:00:54 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.8.6-GA) with ESMTP id JUH02254; Tue, 18 Mar 2008 10:00:53 -0400 (EDT) Received: from 209-6-22-188.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.188]) by smtp01.lnh.mail.rcn.net with ESMTP; 18 Mar 2008 10:01:33 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18399.51985.110882.166457@jerusalem.litteratus.org> Date: Tue, 18 Mar 2008 10:00:49 -0400 To: Alex Goncharov In-Reply-To: References: X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Cc: freebsd-current@freebsd.org Subject: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 14:29:13 -0000 Alex Goncharov writes: > I am trying to source-upgrade one of my 7.0 systems to 8.0-CURRENT. I updated on Friday. > The very first 8.0 build (this morning) gave me the kernel that didn't > boot. Built it again, finishing about 15 minutes ago. This one > booted all right but I see this in `/var/log/messages': > > ================================================================================ > WARNING: WITNESS option enabled, expect reduced performance. > lock order reversal: > 1st 0xc4093e28 devfs (devfs) @ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064 > 2nd 0xc4172b54 devfsmount (devfsmount) @ /mnt/wdx/freebsd/8.0/usr/src/sys/fs/devfs/devfs_vnops.c:201 > KDB: stack backtrace: > db_trace_self_wrapper(c0af5d71,e2888bbc,c07a70de,c0af8353,c4172b54,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(c0af8353,c4172b54,c0ae90df,c0ae90df,c0ae9120,...) at kdb_backtrace+0x29 > witness_checkorder(c4172b54,9,c0ae9120,c9,c7,...) at witness_checkorder+0x6de > _sx_xlock(c4172b54,0,c0ae9120,c9,c4172b54,...) at _sx_xlock+0x7d > devfs_allocv(c415db80,c4174000,e2888c28,c3e1ecc0,c0afe288,...) at devfs_allocv+0x144 > devfs_root(c4174000,2,c0c67378,c3e1ecc0,ca,...) at devfs_root+0x51 > set_rootvnode(c0c67360,0,c0afe288,5f4,c07e4aa0,...) at set_rootvnode+0x2b > vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x356 > start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65 > fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 --- > Trying to mount root from ufs:/dev/ad4s1a > lock order reversal: > 1st 0xc40939e8 ufs (ufs) @ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064 > 2nd 0xc4174000 vfslock (vfslock) @ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:364 > KDB: stack backtrace: > db_trace_self_wrapper(c0af5d71,e28889d8,c07a70de,c0af8353,c4174000,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(c0af8353,c4174000,c0afe39a,c0afe39a,c0afe937,...) at kdb_backtrace+0x29 > witness_checkorder(c4174000,1,c0afe937,16c,e2888a18,...) at witness_checkorder+0x6de > _lockmgr_args(c4174000,20001,c4174030,0,ffffffff,...) at _lockmgr_args+0x1d5 > vfs_busy(c4174000,0,0,c3e1ecc0,e2888b58,...) at vfs_busy+0x1b0 > lookup(e2888b44,c0afe022,c6,bf,c3dee22c,...) at lookup+0x7bf > namei(e2888b44,c4174030,1c1,c0afe288,e2888b54,...) at namei+0x34b > kern_unlink(c3e1ecc0,c0afe6d9,1,62f,0,...) at kern_unlink+0x40 > vfs_mountroot_try(c0afe893,c0aec557,c0ae4ade,1,c07e4aa0,...) at vfs_mountroot_try+0x470 > vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x418 > start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65 > fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 --- > lock order reversal: > 1st 0xc3e22044 user map (user map) @ /mnt/wdx/freebsd/8.0/usr/src/sys/vm/vm_map.c:3111 > 2nd 0xc40937c8 ufs (ufs) @ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064 > KDB: stack backtrace: > db_trace_self_wrapper(c0af5d71,e28889c4,c07a70de,c0af8353,c40937c8,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(c0af8353,c40937c8,c0aece96,c0aece96,c0afe937,...) at kdb_backtrace+0x29 > witness_checkorder(c40937c8,1,c0afe937,810,e28889e8,...) at witness_checkorder+0x6de > _lockmgr_args(c40937c8,30041,c40937f8,0,ffffffff,...) at _lockmgr_args+0x1d5 > ffs_lock(e2888a78,c075fc3d,c0c20554,30041,c4093770,...) at ffs_lock+0xa3 > VOP_LOCK1_APV(c0bcbec0,e2888a78,c0aec555,3,c40937f8,...) at VOP_LOCK1_APV+0xa5 > _vn_lock(c4093770,30041,c0afe937,810,0,...) at _vn_lock+0xf7 > vget(c4093770,30041,c3e1ecc0,4a9,c1460600,...) at vget+0x10b > vnode_pager_lock(c1460480,0,c0b157d5,127,e2888be8,...) at vnode_pager_lock+0x1ad > vm_fault(c3e22000,80cf000,2,8,80cf340,...) at vm_fault+0x1df > trap_pfault(5,0,c0b23bd2,2c4,c3e1ccd0,...) at trap_pfault+0x118 > trap(e2888d38) at trap+0x259 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- I'm gettig both of these as well. It doesn't stop the system from booting, or _seem_ to affect operation ... but it would be nice if they would go away. Robert Huff From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 14:33:46 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C143B106566C for ; Tue, 18 Mar 2008 14:33:46 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 262888FC23 for ; Tue, 18 Mar 2008 14:33:45 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m2IEXiLo019100; Tue, 18 Mar 2008 15:33:44 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m2IEXiFk019099; Tue, 18 Mar 2008 15:33:44 +0100 (CET) (envelope-from olli) Date: Tue, 18 Mar 2008 15:33:44 +0100 (CET) Message-Id: <200803181433.m2IEXiFk019099@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, vadim_nuclight@mail.ru In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 18 Mar 2008 15:33:45 +0100 (CET) Cc: Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 14:33:47 -0000 Vadim Goncharov wrote: > Oliver Fromme wrote: > > [...] > > > > The xorg packages on disc1 occupy 54 MB. Not really all > > > > that much, I think. The linux base, perl and python occupy > > > > another 50 MB together. The rest are small utility things > > > > and dependencies (only a few MB). > > > But that is still valuable if geom_ugz is in use. > > Have you actually tried it? Providing hard numbers is > > more useful than just talking about it. :-) > > I've used Frenzy LiveCD many times (http://frenzy.org.ua), a > Portable SysAdmin Tool. It is 200Mb minicd with MANY useful > packages. It has X Window and many graphical and console > utilities (about 600MB uncompressed). It proved to be stable > and not-so-slow. Nice. Looks very interesting and useful. Maybe there should be a link to it somewhere on freebsd.org. :-) Would be interesting to know how it performs on rather slow and resource-limited machines, i.e. slow processor and low RAM. It's important to keep in mind that many novices who want to give FreeBSD a try will install it on an older spare machine. So the installer and live FS should run well on older hardware. It's for the advocacy reasons that you mentioned. ;-) > The less for /boot should be compensated by 16K cluster size. But those > numbers are for utilities - are there any docs on ISO ? My numbers were only for the "fixit" live FS. It doesn't contain any docs except manpages and info files. > > > [the new installer] > > > This will surely not be finished before 8.0, > > I'm not so sure. > > May be. But it definitely won't be bug-free and default installer > before 8.0. True, that's unlikely. > > Users who refuse to read docs will also refused to read > > docs that are directly available on the CD. > > Users unwilling to read docs cannot be cured by technical > > measures. It's a user problem, not a FreeBSD problem. > > When you say so, you lose a number of users. I'm not afraid of losing users who refuse to read docs. > > Note that you cannot use that menu entry once the actual > > installation has started, though. You can only abort the > > installation, then go back to the menu, read the docs, > > and then begin a new installation. That's a pain, too. > > Of course, once the installation has progressed so far > > that the docs have been installed on the harddisk, you > > can read them on the shell that's opened on Alt-F4. > > That's a drawback. True. > I think there should be another sysinstall's console on > which docs are always available. I completely agree that sysinstall could need a few improvements regarding docs, packages and other things. Unfortunately, patches don't come from thin air. Someone has to write them. :-) > > Still, it's best to read the Installation chapter in > > advance, or even better, have a printed copy on paper. > > It is not ethical to require users to print docs before. I don't mean it should be a requirement. But it's not a bad idea to do it. Or have the online copy open on a second machine. Or even buy the printed Handbook. (Some vendors offer a bundle of the Handbook + DVD.) > Yes, but DVD is still in the future. I don't quite understand. Most PCs have a DVD drive. You can buy DVD-ROM drives for $20. Sure, there are old boxes that still have CD drives only. I'm not saying that FreeBSD should stop making CD ISO images. But it doesn't have to be the main focus anymore. The majority of people do have DVD drives, so the focus should move to providing a DVD ISO image, getting rid of various problems (space constraints, CD shuffling annoyance). "Legacy" CD ISO images could still be provided, but it's lower priority. > > Such comparisons are bogus anyway. I've installed SuSE > > linux before, and I think the graphical installer is > > terribly annoying. It's worse than Windows. It took > > me a lot longer to get a usable system installed, and > > even then it installed different sets than the ones I > > selected (I have no idea why). In my opinion, FreeBSD's > > installation wins big time. > > I've not said anything about graphics installer - but features/functional > only. Yes, my point was about features and functionality. I don't care if the installer runs in text mode or graphics mode, as long as it still supports text mode e.g. for installation via serial console, and as long as the design of the graphical installer does not interfere with usage. For example, when the animated files images that fly from the CD icon on the left to the harddisk icon on the right during installation take 75% CPU time on a slow machine, doubling the installation time, then something is clearly wrong. > > > Imagine a review like this: > > > "That SuSe or Debian are wonderful with great number of software instantly > > > available and with this FreeBSD I must wait for download and then compile?! > > > Such shit! Don't use it, if they can't do this, they can't do other usable > > > things!" > > Such a review is worthless and shouldn't be taken serious. > > I really don't worry about that. > > You don't, but a number of users can be lost. Advocacy, again. You cannot do anything against clueless reviews. There will always be reviews from people who don't get the facts right and draw wrong conclusions. And from people who are opposed to FreeBSD in the first place. ("So, lets see if the FreeBSD dumbheads did it any better this time, but I really doubt it. Nothing beats Dubian Linux anyway.") > > > And what about at least shell and some other tools? > > A shell and a few tools (very few, admittedly) are included > > in the MFS image in the /boot directory. > > And there's also the shell opened on Alt-F4 once the > > installation has started. For anything else there is > > the "fixit" live FS. > > That's shells are almost useless because even "ls" don't work. echo * > > OK, here are the results of 7.0-RELEASE/i386: > > 348 MB gzip'ed (default) > > 297 MB bzip2'ed > > So the space saving is 51 MB (14.7%). It took 45 minutes > > on my machine to create the bzip2-compressed files. Here > > are the decompression times: > > 0:57 for the gzip'ed sets > > 7:20 for the bzip2'ed sets > > So it takes almost 8 times as long to decompress. The > > machine was otherwise idle, and the times were reproducible > > with good accuracy. > > OK, agreed. But bzip2 can be left as option to the future for some system prts > not in default install, if sizes will grow... Yes, I agree, that option might be explored in the future, especially for other architectures, for example ona md64 bzip2 isn't as bad as on i386. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 14:40:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A93106566C for ; Tue, 18 Mar 2008 14:40:29 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (72-12-2-19.static.networktel.net [72.12.2.19]) by mx1.freebsd.org (Postfix) with ESMTP id 924F68FC1A for ; Tue, 18 Mar 2008 14:40:29 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.129.17.152]) by ns2.bafirst.com with esmtp; Tue, 18 Mar 2008 09:30:11 -0500 id 000D4C4D.47DFD1F3.0000FA16 Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Tue, 18 Mar 2008 08:30:05 -0600 id 0004AC27.47DFD1ED.0000318F Received: from 172.16.0.2 ([172.16.0.2]) by intranet.encontacto.net (Horde Framework) with HTTP; Tue, 18 Mar 2008 09:30:05 -0500 Message-ID: <20080318093005.11604iu8p3blvvgg@intranet.encontacto.net> Date: Tue, 18 Mar 2008 09:30:05 -0500 From: eculp To: freebsd-current@freebsd.org References: <200803141508.m2EF86Jl068931@lurza.secnetix.de> <20080317111741.GB6353@leia.lambermont.dyndns.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 14:40:29 -0000 Quoting Vadim Goncharov : > Hi Hans Lambermont! > > On Mon, 17 Mar 2008 12:17:41 +0100; Hans Lambermont wrote about 'Re: =20 > RELEASE discs & ISO images (for future)': > >>>> Therefore, my opinion is that we should publish a DVD image in the >>>> future that contains everything we have today on disc{1,2,3} docs >>>> and livefs CD. The size of such an DVD would be 1.95 GB for >>>> 7.0-RELEASE/i386. >>>> >>>> For those who don't want or need packages and docs, a smaller CD >>>> image with just the install bits (and maybe the fixit FS) could be >>>> provided, and of course the small "bootonly" image, but nothing >>>> else. Providing five or more CD images is rather last century like, >>>> in my opinion. >>> >>> Yes, but DVD is still in the future. >> Why ? I've used Dru's nice blog at >> http://blogs.ittoolbox.com/unix/bsd/archives/creating-your-own-freebsd-70= -dvd-22791 >> (slightly adapted, using mdconfig -d -u /dev/md0) to create my own >> bootable dvd (of disc[1-3].iso and docs.iso) in only a few minutes time. I'm somewhat confused as to what the DVD should include and in what =20 order. When I make a release and include docs which I normally =20 don't, I end up with 5 cdrom images that I can't directly relate to =20 Dru's article. The rest seems to be straight forward. I see that the snapshots are the same: 8.0-CURRENT-200803-i386-bootonly.iso=09ISO=0936320 KB=0903/12/08 8.0-CURRENT-200803-i386-disc1.iso=09ISO=09408378 KB=0903/12/08 8.0-CURRENT-200803-i386-disc2.iso=09ISO=09364 KB=0903/12/08 8.0-CURRENT-200803-i386-docs.iso=09ISO=09252906 KB=0903/12/08 8.0-CURRENT-200803-i386-livefs.iso=09ISO=09223078 KB=0903/12/08 My question is which of these would be recommended to include in the =20 DVD and in what order? Dru doesn't mention the livefs or bootonly and =20 has a disc3. I guess I could download the 7.0 release, mount and =20 compare.. . . . . but there must be other clueless folks that wonder =20 about this also. Thanks, ed From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 15:17:24 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9973106566B for ; Tue, 18 Mar 2008 15:17:24 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8988FC1A for ; Tue, 18 Mar 2008 15:17:24 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m2IFHAvi020885; Tue, 18 Mar 2008 16:17:10 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m2IFHABC020884; Tue, 18 Mar 2008 16:17:10 +0100 (CET) (envelope-from olli) Date: Tue, 18 Mar 2008 16:17:10 +0100 (CET) Message-Id: <200803181517.m2IFHABC020884@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, eculp@encontacto.net In-Reply-To: <20080318093005.11604iu8p3blvvgg@intranet.encontacto.net> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 18 Mar 2008 16:17:10 +0100 (CET) Cc: Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, eculp@encontacto.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 15:17:25 -0000 eculp wrote: > Hans Lambermont wrote: > > I've used Dru's nice blog at > > http://blogs.ittoolbox.com/unix/bsd/archives/creating-your-own-freebsd-70-dvd-22791 > > (slightly adapted, using mdconfig -d -u /dev/md0) to create my own > > bootable dvd (of disc[1-3].iso and docs.iso) in only a few minutes time. > > I'm somewhat confused as to what the DVD should include and in what > order. When I make a release and include docs which I normally > don't, I end up with 5 cdrom images that I can't directly relate to > Dru's article. The rest seems to be straight forward. > > I see that the snapshots are the same: > > 8.0-CURRENT-200803-i386-bootonly.iso ISO 36320 KB 03/12/08 > 8.0-CURRENT-200803-i386-disc1.iso ISO 408378 KB 03/12/08 > 8.0-CURRENT-200803-i386-disc2.iso ISO 364 KB 03/12/08 > 8.0-CURRENT-200803-i386-docs.iso ISO 252906 KB 03/12/08 > 8.0-CURRENT-200803-i386-livefs.iso ISO 223078 KB 03/12/08 > > My question is which of these would be recommended to include in the > DVD and in what order? Dru doesn't mention the livefs or bootonly and > has a disc3. The snapshots don't contain the full set of packages, so there is no disc3 (and disc2 is almost empty). The "bootonly" disc isn't required at all, it contains only sysinstall, but nothing else. It's for people who only need something to boot, but without actual install data. You don't need it to build the DVD. (All of this is explained in the README on the FTP servers.) If you want to include the livefs, just copy it into the directory from which you create the DVD ISO image. You don't have to do anything special. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "It combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript." -- Jamie Zawinski, when asked: "What's wrong with perl?" From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 15:41:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FCF8106564A for ; Tue, 18 Mar 2008 15:41:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 712AD8FC28 for ; Tue, 18 Mar 2008 15:41:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 967FB1A4D7C; Tue, 18 Mar 2008 08:39:57 -0700 (PDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 18 Mar 2008 11:34:59 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803181134.59757.jhb@freebsd.org> Cc: Igor Mozolevsky Subject: Re: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 15:41:16 -0000 On Saturday 15 March 2008 10:21:23 pm Igor Mozolevsky wrote: > Ok, > so I've been trying to figure out (on my T43p) why my lapic frequency > is being ~3x the difference between Release-7 CD and RELENG_7 cvs... I > get, after verbose booting: > > lapic: Divisor 2, Frequency 66504853 hz > > with the ISO image; and > > lapic: Divisor 2, Frequency 188430051 hz > > consistently +/- small % variation... > > I'm compiling w/ GENERIC w/o CFLAGS/COPTFLAGS, etc... The response is > sluggish as a result of that, and perl fails timing tests... I've run > out of things to experiment with; has anything changed in the kernel > wrt lapic? If not, HELP! First, which one is broken? Have you tried a RELENG_7_0 kernel and does it do the same as a release CD kernel? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 15:49:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B2FF1065670 for ; Tue, 18 Mar 2008 15:49:46 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 88A5B8FC12 for ; Tue, 18 Mar 2008 15:49:33 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1031744uge.37 for ; Tue, 18 Mar 2008 08:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=XybBEALRYEtfvhOiGRzLSRA6xW6EoT+MmkTarlwaezE=; b=Tb6skvgP5EgDaSw9JpI6XGaJPnVa2dOsst5N/O3uLOgK/FLhsDZkw1lZo0cXhxtHuuR7kHxxR0MRT3syWozR5kAfAv6vWHNZIqDsmXAe9f2G3WkTwbnbZDEXxsxkyWwK4hi176po5NceNDVxhlT+VCZFGTKu0Mo9O/cHvgKUeKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=smXV5GihDlxl6bbgXiSZPZeLYiKG5EPQTFJOB9t2d1eaylLiywtnAktPxHKS8EHoJxGGFCg1zxOnpVbScR3rR4g9XUQzjD/5FeDV2elkR8Pnne2Ov+5JkQa2XldxpYQzE9QWkoxk0Q3f5BiKKTvUfcXTZa1va7y1tNKsZiNqqqU= Received: by 10.67.116.15 with SMTP id t15mr3798284ugm.21.1205855369488; Tue, 18 Mar 2008 08:49:29 -0700 (PDT) Received: by 10.66.248.11 with HTTP; Tue, 18 Mar 2008 08:49:29 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 15:49:29 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "John Baldwin" In-Reply-To: <200803181134.59757.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200803181134.59757.jhb@freebsd.org> X-Google-Sender-Auth: 3d005b54834019f7 Cc: freebsd-current@freebsd.org Subject: Re: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 15:49:46 -0000 On 18/03/2008, John Baldwin wrote: > First, which one is broken? Have you tried a RELENG_7_0 kernel and does it do > the same as a release CD kernel? Tried both ISO image and RELENG_7_0, they both work ok, but RELENG_7 doesn't... Cheers, Igor From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 16:27:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA5D1065670 for ; Tue, 18 Mar 2008 16:27:34 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 00E2A8FC20 for ; Tue, 18 Mar 2008 16:27:33 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so6905776waf.3 for ; Tue, 18 Mar 2008 09:27:33 -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:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=EKgv/MlOHou3msGZvuN0CQ3U90iYn6A29FkH6QengFc=; b=Cwr2dGJbLAw/t44NzY1VNojjjbNzNLlQhVi/ofHSkI3Erf3fQv3+XumakvuqK+9FT7U3g3Y4TgE5J42f1AobAPz96dMCOlo1CuFb9UE0rDEOWgKfnlXqTaGyLeJVVKJPAOwGBWLE+QHSM/jdsGqxUedWMNU1BZ0SXZG0/XIhEQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dFC6e5B8zMhIgpnLJvqznENhQD04GhNheYoH+cQqJhG7lMzGSkzVEXpl2bJA0PdMWtvPPksaf7H91GWjBlRVSEcedB0W9KkpveO5nAEkRwLvlsDvW4Z4nAGEEqwhyfi8LJk0gTGwHfdih4LvRLRIKS9RV5KknUNj7IYE6xfuKj0= Received: by 10.114.168.1 with SMTP id q1mr1901799wae.74.1205856149656; Tue, 18 Mar 2008 09:02:29 -0700 (PDT) Received: by 10.115.22.10 with HTTP; Tue, 18 Mar 2008 09:02:29 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 09:02:29 -0700 From: "Kip Macy" To: "Robert Huff" , "Alex Goncharov" , freebsd-current@freebsd.org In-Reply-To: <18399.51985.110882.166457@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18399.51985.110882.166457@jerusalem.litteratus.org> Cc: Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 16:27:34 -0000 See archives / UPDATING for an explanation. On 3/18/08, Robert Huff wrote: > > Alex Goncharov writes: > > > I am trying to source-upgrade one of my 7.0 systems to 8.0-CURRENT. > > I updated on Friday. > > > > The very first 8.0 build (this morning) gave me the kernel that didn't > > boot. Built it again, finishing about 15 minutes ago. This one > > booted all right but I see this in `/var/log/messages': > > > > > ================================================================================ > > WARNING: WITNESS option enabled, expect reduced performance. > > lock order reversal: > > 1st 0xc4093e28 devfs (devfs) @ > /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064 > > 2nd 0xc4172b54 devfsmount (devfsmount) @ > /mnt/wdx/freebsd/8.0/usr/src/sys/fs/devfs/devfs_vnops.c:201 > > KDB: stack backtrace: > > db_trace_self_wrapper(c0af5d71,e2888bbc,c07a70de,c0af8353,c4172b54,...) > at db_trace_self_wrapper+0x26 > > kdb_backtrace(c0af8353,c4172b54,c0ae90df,c0ae90df,c0ae9120,...) at > kdb_backtrace+0x29 > > witness_checkorder(c4172b54,9,c0ae9120,c9,c7,...) at > witness_checkorder+0x6de > > _sx_xlock(c4172b54,0,c0ae9120,c9,c4172b54,...) at _sx_xlock+0x7d > > devfs_allocv(c415db80,c4174000,e2888c28,c3e1ecc0,c0afe288,...) at > devfs_allocv+0x144 > > devfs_root(c4174000,2,c0c67378,c3e1ecc0,ca,...) at devfs_root+0x51 > > set_rootvnode(c0c67360,0,c0afe288,5f4,c07e4aa0,...) at set_rootvnode+0x2b > > vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x356 > > start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65 > > fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 --- > > Trying to mount root from ufs:/dev/ad4s1a > > lock order reversal: > > 1st 0xc40939e8 ufs (ufs) @ > /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064 > > 2nd 0xc4174000 vfslock (vfslock) @ > /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:364 > > KDB: stack backtrace: > > db_trace_self_wrapper(c0af5d71,e28889d8,c07a70de,c0af8353,c4174000,...) > at db_trace_self_wrapper+0x26 > > kdb_backtrace(c0af8353,c4174000,c0afe39a,c0afe39a,c0afe937,...) at > kdb_backtrace+0x29 > > witness_checkorder(c4174000,1,c0afe937,16c,e2888a18,...) at > witness_checkorder+0x6de > > _lockmgr_args(c4174000,20001,c4174030,0,ffffffff,...) at > _lockmgr_args+0x1d5 > > vfs_busy(c4174000,0,0,c3e1ecc0,e2888b58,...) at vfs_busy+0x1b0 > > lookup(e2888b44,c0afe022,c6,bf,c3dee22c,...) at lookup+0x7bf > > namei(e2888b44,c4174030,1c1,c0afe288,e2888b54,...) at namei+0x34b > > kern_unlink(c3e1ecc0,c0afe6d9,1,62f,0,...) at kern_unlink+0x40 > > vfs_mountroot_try(c0afe893,c0aec557,c0ae4ade,1,c07e4aa0,...) at > vfs_mountroot_try+0x470 > > vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x418 > > start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65 > > fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 --- > > lock order reversal: > > 1st 0xc3e22044 user map (user map) @ > /mnt/wdx/freebsd/8.0/usr/src/sys/vm/vm_map.c:3111 > > 2nd 0xc40937c8 ufs (ufs) @ > /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064 > > KDB: stack backtrace: > > db_trace_self_wrapper(c0af5d71,e28889c4,c07a70de,c0af8353,c40937c8,...) > at db_trace_self_wrapper+0x26 > > kdb_backtrace(c0af8353,c40937c8,c0aece96,c0aece96,c0afe937,...) at > kdb_backtrace+0x29 > > witness_checkorder(c40937c8,1,c0afe937,810,e28889e8,...) at > witness_checkorder+0x6de > > _lockmgr_args(c40937c8,30041,c40937f8,0,ffffffff,...) at > _lockmgr_args+0x1d5 > > ffs_lock(e2888a78,c075fc3d,c0c20554,30041,c4093770,...) at ffs_lock+0xa3 > > VOP_LOCK1_APV(c0bcbec0,e2888a78,c0aec555,3,c40937f8,...) at > VOP_LOCK1_APV+0xa5 > > _vn_lock(c4093770,30041,c0afe937,810,0,...) at _vn_lock+0xf7 > > vget(c4093770,30041,c3e1ecc0,4a9,c1460600,...) at vget+0x10b > > vnode_pager_lock(c1460480,0,c0b157d5,127,e2888be8,...) at > vnode_pager_lock+0x1ad > > vm_fault(c3e22000,80cf000,2,8,80cf340,...) at vm_fault+0x1df > > trap_pfault(5,0,c0b23bd2,2c4,c3e1ccd0,...) at trap_pfault+0x118 > > trap(e2888d38) at trap+0x259 > > calltrap() at calltrap+0x6 > > --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- > > I'm gettig both of these as well. It doesn't stop the system > from booting, or _seem_ to affect operation ... but it would be nice > if they would go away. > > > > Robert Huff > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 17:40:34 2008 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 8CD371065675 for ; Tue, 18 Mar 2008 17:40:34 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: from web33708.mail.mud.yahoo.com (web33708.mail.mud.yahoo.com [68.142.201.205]) by mx1.freebsd.org (Postfix) with SMTP id 47E898FC30 for ; Tue, 18 Mar 2008 17:40:34 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: (qmail 30678 invoked by uid 60001); 18 Mar 2008 17:40:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=iA3zWfiswsoxPfiaOEuPrXOXU28MqY0k6GynIQX66TvsyElQK8PPEfFaGjJeWRDuTCfxIxpz0KF4JG6NyapXgGvJOBiymtFOn+ZtkpAD/SnFekuvZ0tCJk6QKuHgBYCcLY9Y+ubznkGA6pcbPCbQFR2Mnj5+pbTIyTa+ogL9L3s=; X-YMail-OSG: J1BsmRYVM1m2rtPvdwi55nDDwm0WtPFifOuFae.kf0neW_GkOBW.lz_Xa3qRLcq_2uWGqhOkuEeIVy1v6Thd1KeY5SH3gU_lM.iJvimyEF074RlBIOQ- Received: from [89.211.4.3] by web33708.mail.mud.yahoo.com via HTTP; Tue, 18 Mar 2008 10:40:33 PDT X-Mailer: YahooMailRC/902.38 YahooMailWebService/0.7.162 Date: Tue, 18 Mar 2008 10:40:33 -0700 (PDT) From: Abdullah Ibn Hamad Al-Marri To: FreeBSD Current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <694675.30163.qm@web33708.mail.mud.yahoo.com> Cc: Subject: Speed Step and powerd for servers status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 17:40:34 -0000 Hey, I would like to use powerd and speed step for my servers, and make sure it will use the MAX CPU if needed then go to idle mode to save the power. Any recommendation? Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 17:45:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B91B106567A for ; Tue, 18 Mar 2008 17:45:33 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (72-12-2-19.static.networktel.net [72.12.2.19]) by mx1.freebsd.org (Postfix) with ESMTP id 2523D8FC2E for ; Tue, 18 Mar 2008 17:45:32 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.129.17.152]) by ns2.bafirst.com with esmtp; Tue, 18 Mar 2008 12:45:26 -0500 id 000D4C4D.47DFFFB6.00010015 Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Tue, 18 Mar 2008 11:45:20 -0600 id 0004AC1A.47DFFFB0.0000515A Received: from 172.16.0.2 ([172.16.0.2]) by intranet.encontacto.net (Horde Framework) with HTTP; Tue, 18 Mar 2008 12:45:20 -0500 Message-ID: <20080318124520.124711t3ic2vn834@intranet.encontacto.net> Date: Tue, 18 Mar 2008 12:45:20 -0500 From: eculp To: freebsd-current@FreeBSD.ORG, eculp@encontacto.net, Oliver Fromme References: <200803181517.m2IFHABC020884@lurza.secnetix.de> In-Reply-To: <200803181517.m2IFHABC020884@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) Cc: Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 17:45:33 -0000 Quoting Oliver Fromme : > eculp wrote: > > Hans Lambermont wrote: > > > I've used Dru's nice blog at > > > =20 > http://blogs.ittoolbox.com/unix/bsd/archives/creating-your-own-freebsd-70-= dvd-22791 > > > (slightly adapted, using mdconfig -d -u /dev/md0) to create my own > > > bootable dvd (of disc[1-3].iso and docs.iso) in only a few minutes ti= me. > > > > I'm somewhat confused as to what the DVD should include and in what > > order. When I make a release and include docs which I normally > > don't, I end up with 5 cdrom images that I can't directly relate to > > Dru's article. The rest seems to be straight forward. > > > > I see that the snapshots are the same: > > > > 8.0-CURRENT-200803-i386-bootonly.iso ISO 36320 KB 03/12/0= 8 > > 8.0-CURRENT-200803-i386-disc1.iso ISO 408378 KB 03/12/0= 8 > > 8.0-CURRENT-200803-i386-disc2.iso ISO 364 KB 03/12/08 > > 8.0-CURRENT-200803-i386-docs.iso ISO 252906 KB 03/12/0= 8 > > 8.0-CURRENT-200803-i386-livefs.iso ISO 223078 KB 03/12/0= 8 > > > > My question is which of these would be recommended to include in the > > DVD and in what order? Dru doesn't mention the livefs or bootonly and > > has a disc3. Hi Oliver. Thanks for the suggestions. > The snapshots don't contain the full set of packages, so > there is no disc3 (and disc2 is almost empty). > > The "bootonly" disc isn't required at all, it contains > only sysinstall, but nothing else. It's for people who > only need something to boot, but without actual install > data. You don't need it to build the DVD. (All of this > is explained in the README on the FTP servers.) I had thought that the README's had the ISO's information but was =20 unable to find it, assuming that it is still there. I may have =20 choosen the wrong ftp server or looked in the wrong subdirectory. I =20 think it would be very helpful if it still explained what each iso =20 contained. Just in case anyone would like to know I checked the following two =20 README's where I expected to find the ISO info: ftp://ftp7.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/README.TXT ftp://ftp7.freebsd.org/pub/FreeBSD/snapshots/README.TXT Thanks again, ed > > If you want to include the livefs, just copy it into > the directory from which you create the DVD ISO image. > You don't have to do anything special. > > Best regards > Oliver > From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 17:49:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D35B8106566B for ; Tue, 18 Mar 2008 17:49:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 683F78FC25 for ; Tue, 18 Mar 2008 17:49:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 235925695-1834499 for multiple; Tue, 18 Mar 2008 13:49:07 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m2IHn17f091730; Tue, 18 Mar 2008 13:49:02 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Igor Mozolevsky" Date: Tue, 18 Mar 2008 13:24:50 -0400 User-Agent: KMail/1.9.7 References: <200803181134.59757.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803181324.51136.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 18 Mar 2008 13:49:02 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/6288/Tue Mar 18 06:43:22 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 17:49:15 -0000 On Tuesday 18 March 2008 11:49:29 am Igor Mozolevsky wrote: > On 18/03/2008, John Baldwin wrote: > > > First, which one is broken? Have you tried a RELENG_7_0 kernel and does it do > > the same as a release CD kernel? > > Tried both ISO image and RELENG_7_0, they both work ok, but RELENG_7 doesn't... Ok, and it is cpufreq related? Which cpufreq drivers are attaching to your CPU? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 18:45:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A7C106566B for ; Tue, 18 Mar 2008 18:45:49 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 10DDE8FC34 for ; Tue, 18 Mar 2008 18:45:48 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so37891fka.11 for ; Tue, 18 Mar 2008 11:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=45OfsIeSyWP65DikMWqxY2OooneSMeW0Et7gOhcGei0=; b=idUfNaMEgDqiVv5uNfXnXEEjESenpndSwDlEkC9Vr50o8bg8hkKye1Sqt4MMSXCa1ZtZtVl0IiYUA29hrPM7+g4XmeFlOnyPxu3QxwdUfJ/ucznvtnwfEaju3KqnJJJGy4FF0At6vE9sFw8yQCpE0jsOD0O4+v+DYS/4OAfX+Mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=hm81MVsfLkzEeTQg/vNbO8nF871Ln5SesbaSZeaQwqXVCgmgoyiiGPV2wXOiMEz+EsyGTHFEinXrxM7f0lxYaGVWol7y7pd+x2C4fvRN3hydbstc6z2rFlKqCojXjF7/ASCEr8u4g0694eF8zpZofFX5Opv9m0Uag7mCnyMhaGg= Received: by 10.82.116.15 with SMTP id o15mr3621155buc.11.1205865945528; Tue, 18 Mar 2008 11:45:45 -0700 (PDT) Received: by 10.86.30.17 with HTTP; Tue, 18 Mar 2008 11:45:45 -0700 (PDT) Message-ID: <3bbf2fe10803181145m79e89955re785e1b5048cafd7@mail.gmail.com> Date: Tue, 18 Mar 2008 19:45:45 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: pluknet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 5c6fffa2384500dd Cc: freebsd-current@freebsd.org, Alex Goncharov Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 18:45:49 -0000 2008/3/18, pluknet : > On 18/03/2008, Alex Goncharov wrote: > > [ Sorry if this is old news or not useful ] > > > > I am trying to source-upgrade one of my 7.0 systems to 8.0-CURRENT. > > > > In the following, when I say "build", it means "csup and build right > > away". > > > > The very first 8.0 build (this morning) gave me the kernel that didn't > > boot. Built it again, finishing about 15 minutes ago. This one > > booted all right but I see this in `/var/log/messages': > > > > [there was stripped LORs] > > It's due to recent WITNESS lockmgr support that unhides existing LORs. > > Thought taking that into account I could obtain a new one yesterday. I > didn't see this before. > > Mar 17 03:17:14 pl sudo: pluknet : TTY=ttyv1 ; PWD=/usr/home/pluknet > ; USER=root ; COMMAND=/usr/libexec/getty 3wire.9600 ttyd0 > Mar 17 03:17:14 pl kernel: lock order reversal: > Mar 17 03:17:14 pl kernel: 1st 0xc07e9274 proctree (proctree) @ > /usr/src/sys/kern/kern_exit.c:291 > Mar 17 03:17:14 pl kernel: 2nd 0xc2fc49e8 devfs (devfs) @ > /usr/src/sys/kern/vfs_subr.c:2158 This one seems interesting. Next time you experience it can you please drop in DDB and print-out the correct order revealed by WITNESS? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 19:11:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42E2D106564A for ; Tue, 18 Mar 2008 19:11:14 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id D7E6F8FC13 for ; Tue, 18 Mar 2008 19:11:13 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1101261uge.37 for ; Tue, 18 Mar 2008 12:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=4pRhIAJNmNPgISkcOMC1TIi6p4RnbzN4fDk31LKotCg=; b=m+wkFrKG24YsTP46PpcJzQmKhYEAaQ/L/GAeUSTz+2d/+PmxPszkQ1uVJ7UgN2yEj5wPXeAW6gOIbmpG5yWXciqdZImi2GRazKv/GhIzcyrnjb3cuQB0svB8cX2Eppuamdm2qXHGP6+dl83Gl0RJtP8zDw+KqEByaRWNQozWqxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aPbna2EQZkXinF7wjZvmKk2gbf8aoCt8b+Kqy21u1NVE2H7xMNcKZbDhfrWk8n6Y+Cd/3cVZeOq4/0NRfgRtulTSP6fw9Ay/a4QaOBNpJaWGegBvTrV/quJoKcld/wUS3Uy2hdw/ualLF5FH4k2wGf0dp9wNwiwL19/5gs78+F8= Received: by 10.78.155.4 with SMTP id c4mr2965236hue.73.1205867469599; Tue, 18 Mar 2008 12:11:09 -0700 (PDT) Received: by 10.78.16.10 with HTTP; Tue, 18 Mar 2008 12:11:09 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 22:11:09 +0300 From: pluknet To: "Attilio Rao" In-Reply-To: <3bbf2fe10803181145m79e89955re785e1b5048cafd7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10803181145m79e89955re785e1b5048cafd7@mail.gmail.com> Cc: freebsd-current@freebsd.org, Alex Goncharov Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 19:11:14 -0000 On 18/03/2008, Attilio Rao wrote: > 2008/3/18, pluknet : > > > > Thought taking that into account I could obtain a new one yesterday. I > > didn't see this before. > > > > Mar 17 03:17:14 pl sudo: pluknet : TTY=ttyv1 ; PWD=/usr/home/pluknet > > ; USER=root ; COMMAND=/usr/libexec/getty 3wire.9600 ttyd0 > > Mar 17 03:17:14 pl kernel: lock order reversal: > > Mar 17 03:17:14 pl kernel: 1st 0xc07e9274 proctree (proctree) @ > > /usr/src/sys/kern/kern_exit.c:291 > > Mar 17 03:17:14 pl kernel: 2nd 0xc2fc49e8 devfs (devfs) @ > > /usr/src/sys/kern/vfs_subr.c:2158 > > > This one seems interesting. > Next time you experience it can you please drop in DDB and print-out > the correct order revealed by WITNESS? > Fortunately I could reproduce it. lock order reversal: 1st 0xc07e9274 proctree (proctree) @ /usr/src/sys/kern/kern_exit.c:291 2nd 0xc3c18278 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 KDB: stack backtrace: db_trace_self_wrapper(c07682d0,d6078b24,c0573236,c076a615,c3c18278,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c076a615,c3c18278,c075bcfb,c075bcfb,c0770a8c,...) at kdb_backtrace+0x29 witness_checkorder(c3c18278,9,c0770a8c,86e,c07edcd4,...) at witness_checkorder+0x6d6 _lockmgr_args(c3c18278,20002,c3c182a8,0,ffffffff,...) at _lockmgr_args+0x519 vop_stdlock(d6078bc4,d6078bbc,c0572a1c,20002,c3c182a8,...) at vop_stdlock+0x51 VOP_LOCK1_APV(c07a07e0,d6078bc4,851,d6078be4,c3c182a8,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c3c18220,20002,c0770a8c,86e,4,...) at _vn_lock+0xf2 vrele(c3c18220,0,c07619a2,14e,ffffffff,...) at vrele+0x142 exit1(c2fdd690,0,d6078d2c,c0729ed3,c2fdd690,...) at exit1+0x8a1 sys_exit(c2fdd690,d6078cfc,4,c07625a5,c07a3d38,...) at sys_exit+0x1d syscall(d6078d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2811964f, esp = 0xbfbfeacc, ebp = 0xbfbfead8 --- Something else? wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 19:16:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91B75106566B for ; Tue, 18 Mar 2008 19:16:33 +0000 (UTC) (envelope-from asmrookie@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 1CED48FC1B for ; Tue, 18 Mar 2008 19:16:32 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so33525fgg.35 for ; Tue, 18 Mar 2008 12:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=C0+BpVG0U3Oai+2Xn9IUuPWAuhcLLXS/xMBBQg+3zhs=; b=JNDEPuGqIXomZSRNXRBDyDZpNcJ2oYhl9DppUeDu8F/l3CJ8In2qVNx++LH0oj/vseaua8lp+fPDWHOoNdl/joRxhhfSr8xBwhkfkb/F9gZcDt8DjbXgTwqObY9GC30hTjLYONQ+gHKDeMDJ6L8lZ03W7zxiW9xUgeXDpyRoiTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=rXoEs1kSd3chZMS8twNVQqqK0hH2f/trApKFie+mjXmO47wQOwEk8LzHZoVQv9KIsT7mKvc/71UsX3I7WjUwzvz45HgaJFuxlpVENcevbL+fzveFYUMkWAcREHxOBiisDVhfnlDZKc7bHTLDCIBectHEW30VnmHmGp/CIaNfm2I= Received: by 10.82.115.8 with SMTP id n8mr3609704buc.10.1205867789082; Tue, 18 Mar 2008 12:16:29 -0700 (PDT) Received: by 10.86.30.17 with HTTP; Tue, 18 Mar 2008 12:16:28 -0700 (PDT) Message-ID: <3bbf2fe10803181216l7a1f7a5fp382b03a74d84161f@mail.gmail.com> Date: Tue, 18 Mar 2008 20:16:28 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: pluknet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10803181145m79e89955re785e1b5048cafd7@mail.gmail.com> X-Google-Sender-Auth: 78dd00dff1c22fcd Cc: freebsd-current@freebsd.org, Alex Goncharov Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 19:16:33 -0000 2008/3/18, pluknet : > On 18/03/2008, Attilio Rao wrote: > > 2008/3/18, pluknet : > > > > > > > Thought taking that into account I could obtain a new one yesterday. I > > > didn't see this before. > > > > > > Mar 17 03:17:14 pl sudo: pluknet : TTY=ttyv1 ; PWD=/usr/home/pluknet > > > ; USER=root ; COMMAND=/usr/libexec/getty 3wire.9600 ttyd0 > > > Mar 17 03:17:14 pl kernel: lock order reversal: > > > Mar 17 03:17:14 pl kernel: 1st 0xc07e9274 proctree (proctree) @ > > > /usr/src/sys/kern/kern_exit.c:291 > > > Mar 17 03:17:14 pl kernel: 2nd 0xc2fc49e8 devfs (devfs) @ > > > /usr/src/sys/kern/vfs_subr.c:2158 > > > > > > This one seems interesting. > > Next time you experience it can you please drop in DDB and print-out > > the correct order revealed by WITNESS? > > > > > Fortunately I could reproduce it. > > lock order reversal: > > 1st 0xc07e9274 proctree (proctree) @ /usr/src/sys/kern/kern_exit.c:291 > > 2nd 0xc3c18278 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 > KDB: stack backtrace: > db_trace_self_wrapper(c07682d0,d6078b24,c0573236,c076a615,c3c18278,...) > > at db_trace_self_wrapper+0x26 > > kdb_backtrace(c076a615,c3c18278,c075bcfb,c075bcfb,c0770a8c,...) at > kdb_backtrace+0x29 > witness_checkorder(c3c18278,9,c0770a8c,86e,c07edcd4,...) at > witness_checkorder+0x6d6 > _lockmgr_args(c3c18278,20002,c3c182a8,0,ffffffff,...) at _lockmgr_args+0x519 > vop_stdlock(d6078bc4,d6078bbc,c0572a1c,20002,c3c182a8,...) at vop_stdlock+0x51 > VOP_LOCK1_APV(c07a07e0,d6078bc4,851,d6078be4,c3c182a8,...) at VOP_LOCK1_APV+0xa5 > _vn_lock(c3c18220,20002,c0770a8c,86e,4,...) at _vn_lock+0xf2 > vrele(c3c18220,0,c07619a2,14e,ffffffff,...) at vrele+0x142 > exit1(c2fdd690,0,d6078d2c,c0729ed3,c2fdd690,...) at exit1+0x8a1 > sys_exit(c2fdd690,d6078cfc,4,c07625a5,c07a3d38,...) at sys_exit+0x1d > syscall(d6078d38) at syscall+0x2b3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2811964f, esp = > 0xbfbfeacc, ebp = 0xbfbfead8 --- > > Something else? This is the "2nd order". It would be nice to get where these locks are acquired and what is the "1st order". In order to get it, it is enough to break in DDB and do: show witness at DDB prompt. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 19:25:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 437CF1065672 for ; Tue, 18 Mar 2008 19:25:02 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB1A8FC3B for ; Tue, 18 Mar 2008 19:25:01 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by rn-out-0910.google.com with SMTP id e11so44013rng.7 for ; Tue, 18 Mar 2008 12:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=v0LCj4h7NlwTZh8v5MOuR2uLIZqLqgXvaLGNArijzYs=; b=tZzSnBqLNGt5Lj549+BLeywTdQLSepY2gRUxm43S0hcVTX72ESKIS0kL4Qow+Y1MlC7qN2uCEPt3w0S0l/e5vb8yR74xmxobJ+oEWf5Dd1/CLKX1tkWXh64k2GUYLGrxrVnq6MjriGHGMYhUBO1oxQsk9gBTtpit1VEmqSoloTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UguiZH2MNpICaL36mA7mAaTe6y2UwpKh9GNwN84idBpjPj80v6xVYgJrdH6B1DpUxmNku3iWGd4T1gEvowtJJyC1/PmCAlgTRHLj0bQw0amS4BEJz08oUKVSNQ1Jvrhj/ICUXa20umUGn9pRv6AOBj5b7pmelmzB5Q7oLKBgUCM= Received: by 10.142.171.6 with SMTP id t6mr1406392wfe.12.1205868300586; Tue, 18 Mar 2008 12:25:00 -0700 (PDT) Received: by 10.66.248.11 with HTTP; Tue, 18 Mar 2008 12:25:00 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 19:25:00 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "John Baldwin" In-Reply-To: <200803181324.51136.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200803181134.59757.jhb@freebsd.org> <200803181324.51136.jhb@freebsd.org> X-Google-Sender-Auth: 940d499d7274f1bd Cc: freebsd-current@freebsd.org Subject: Re: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 19:25:02 -0000 On 18/03/2008, John Baldwin wrote: > On Tuesday 18 March 2008 11:49:29 am Igor Mozolevsky wrote: > > On 18/03/2008, John Baldwin wrote: > > > > > First, which one is broken? Have you tried a RELENG_7_0 kernel and does > it do > > > the same as a release CD kernel? > > > > Tried both ISO image and RELENG_7_0, they both work ok, but RELENG_7 > doesn't... > > > Ok, and it is cpufreq related? Which cpufreq drivers are attaching to your > CPU? Well, I wouldn't say I'm sure it's 100% cpufreq related, but removing it from the kernel fixes the problem... It's also possible that cpufreq is interfering with something else... Anyhow, I've got both est and p4tcc attaching. Cheers, Igor :-) From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 19:49:33 2008 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 C467C106564A for ; Tue, 18 Mar 2008 19:49:33 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2998FC1A for ; Tue, 18 Mar 2008 19:49:33 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.36] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m2IJnVHN048951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 12:49:32 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <47E01CC9.9040504@FreeBSD.org> Date: Tue, 18 Mar 2008 12:49:29 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Abdullah Ibn Hamad Al-Marri References: <694675.30163.qm@web33708.mail.mud.yahoo.com> In-Reply-To: <694675.30163.qm@web33708.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Speed Step and powerd for servers status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 19:49:33 -0000 Abdullah Ibn Hamad Al-Marri wrote: > Hey, > > > I would like to use powerd and speed step for my servers, and make sure it will use the MAX CPU if needed then go to idle mode to save the power. > > Any recommendation? It's questionable whether or not it will have positive effect on the server: The combination of processor-frequency scaling and idle-power states provides a somewhat surprising result. On almost all modern hardware, if there is code to run, then it is more power efficient to run the processor at full speed. This "race to idle" concept stems from the power consumption of an idle processor being much lower than an active processor, even if running at a lower speed. The overall power consumption will be less if the processor spends a short time at full speed and then falls back to idle, rather than spending twice as long being active at a lower frequency. Full text is here: http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=513 -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 20:13:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E1C0106564A; Tue, 18 Mar 2008 20:13:34 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 976868FC1A; Tue, 18 Mar 2008 20:13:33 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id C14231CCCC; Tue, 18 Mar 2008 21:13:32 +0100 (CET) Date: Tue, 18 Mar 2008 21:13:32 +0100 From: Ed Schouten To: pluknet Message-ID: <20080318201332.GO80576@hoeg.nl> References: <3bbf2fe10803181145m79e89955re785e1b5048cafd7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UEgmpZn7Z/frN9Sq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Attilio Rao , FreeBSD Current , Alex Goncharov Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 20:13:34 -0000 --UEgmpZn7Z/frN9Sq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * pluknet wrote: > Fortunately I could reproduce it. >=20 > lock order reversal: > 1st 0xc07e9274 proctree (proctree) @ /usr/src/sys/kern/kern_exit.c:291 > 2nd 0xc3c18278 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 > KDB: stack backtrace: > db_trace_self_wrapper(c07682d0,d6078b24,c0573236,c076a615,c3c18278,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c076a615,c3c18278,c075bcfb,c075bcfb,c0770a8c,...) at > kdb_backtrace+0x29 > witness_checkorder(c3c18278,9,c0770a8c,86e,c07edcd4,...) at > witness_checkorder+0x6d6 > _lockmgr_args(c3c18278,20002,c3c182a8,0,ffffffff,...) at _lockmgr_args+0x= 519 > vop_stdlock(d6078bc4,d6078bbc,c0572a1c,20002,c3c182a8,...) at vop_stdlock= +0x51 > VOP_LOCK1_APV(c07a07e0,d6078bc4,851,d6078be4,c3c182a8,...) at VOP_LOCK1_A= PV+0xa5 > _vn_lock(c3c18220,20002,c0770a8c,86e,4,...) at _vn_lock+0xf2 > vrele(c3c18220,0,c07619a2,14e,ffffffff,...) at vrele+0x142 > exit1(c2fdd690,0,d6078d2c,c0729ed3,c2fdd690,...) at exit1+0x8a1 > sys_exit(c2fdd690,d6078cfc,4,c07625a5,c07a3d38,...) at sys_exit+0x1d > syscall(d6078d38) at syscall+0x2b3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (1, FreeBSD ELF32, sys_exit), eip =3D 0x2811964f, esp =3D > 0xbfbfeacc, ebp =3D 0xbfbfead8 --- >=20 > Something else? I also saw this LOR inside my mpsafetty branch in Perforce - it can easily be fixed by just calling vrele() after the proctree_lock has been unlocked. I don't have a patch at hand, because I've entirely rewritten that code. --=20 Ed Schouten WWW: http://g-rave.nl/ --UEgmpZn7Z/frN9Sq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfgImwACgkQ52SDGA2eCwWwzQCaA1enEBTrX3wNhz1bwZYf37CB RPYAn2lfclD84nyoSQG+4SHCpehOzyrn =mEg/ -----END PGP SIGNATURE----- --UEgmpZn7Z/frN9Sq-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 20:37:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70205106564A for ; Tue, 18 Mar 2008 20:37:09 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5502B8FC18 for ; Tue, 18 Mar 2008 20:37:09 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2IKOXQ3092780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 13:24:37 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <47E02501.9050303@freebsd.org> Date: Tue, 18 Mar 2008 13:24:33 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Igor Mozolevsky References: <200803181134.59757.jhb@freebsd.org> <200803181324.51136.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 20:37:09 -0000 Igor Mozolevsky wrote: > On 18/03/2008, John Baldwin wrote: > >> On Tuesday 18 March 2008 11:49:29 am Igor Mozolevsky wrote: >> > On 18/03/2008, John Baldwin wrote: >> > >> > > First, which one is broken? Have you tried a RELENG_7_0 kernel and does >> it do >> > > the same as a release CD kernel? >> > >> > Tried both ISO image and RELENG_7_0, they both work ok, but RELENG_7 >> doesn't... >> >> >> Ok, and it is cpufreq related? Which cpufreq drivers are attaching to your >> CPU? >> > > Well, I wouldn't say I'm sure it's 100% cpufreq related, but removing > it from the kernel fixes the problem... It's also possible that > cpufreq is interfering with something else... Anyhow, I've got both > est and p4tcc attaching. > > I'm having lots of problems with cpu freq throttling on t4x laptops. The system gets very sluggish and when I check the frequency it's been throttled down. This happens even on ac (haven't checked what powerd is doing then). Sam From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 21:03:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC5F91065679 for ; Tue, 18 Mar 2008 21:03:12 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 0D80C8FC27 for ; Tue, 18 Mar 2008 21:03:11 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so99739fka.11 for ; Tue, 18 Mar 2008 14:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9gFImt5SVfNaIG+s2DqEd5j+jbAPRKJTSQL7BaUQBG8=; b=uGzC4YV+g7s1S8jwK5s8JyCFzAcTliliZfEcGrHp+J0jrpRqACvRWf2QcertEq1oQ78cX53064XW1R0sYZ4TJsZBWZWcP78VGD+l3IpeA17tkJZeaROxzGVZwINlfNmVj72yfupddtyd3Rff8HSTLQ5KjtPRDv2r4os1m7hmyQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lIf8wRo/6y8CNaHAAcYmhfuDhrxyKbUXXUPkbmXOizKdEHhwM75yH41tRYBRoFLtyWX/FktzH8a/FOvy2Zy/X38f6bTk2CxStnEsuksIVTVx1DpxTGRM92OKo6nzYMk1aQUEAxdII2iBJwGdz1CpUSrMn3XWQCjGsXUoJyapNl4= Received: by 10.78.131.8 with SMTP id e8mr3427213hud.41.1205874189643; Tue, 18 Mar 2008 14:03:09 -0700 (PDT) Received: by 10.78.16.10 with HTTP; Tue, 18 Mar 2008 14:03:09 -0700 (PDT) Message-ID: Date: Wed, 19 Mar 2008 00:03:09 +0300 From: pluknet To: "Attilio Rao" In-Reply-To: <3bbf2fe10803181216l7a1f7a5fp382b03a74d84161f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10803181145m79e89955re785e1b5048cafd7@mail.gmail.com> <3bbf2fe10803181216l7a1f7a5fp382b03a74d84161f@mail.gmail.com> Cc: freebsd-current@freebsd.org, Alex Goncharov Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 21:03:13 -0000 On 18/03/2008, Attilio Rao wrote: > 2008/3/18, pluknet : > > On 18/03/2008, Attilio Rao wrote: > > > 2008/3/18, pluknet : > > > > > > > > > > Thought taking that into account I could obtain a new one yesterday. I > > > > didn't see this before. > > > > > > > > Mar 17 03:17:14 pl sudo: pluknet : TTY=ttyv1 ; PWD=/usr/home/pluknet > > > > ; USER=root ; COMMAND=/usr/libexec/getty 3wire.9600 ttyd0 > > > > Mar 17 03:17:14 pl kernel: lock order reversal: > > > > Mar 17 03:17:14 pl kernel: 1st 0xc07e9274 proctree (proctree) @ > > > > /usr/src/sys/kern/kern_exit.c:291 > > > > Mar 17 03:17:14 pl kernel: 2nd 0xc2fc49e8 devfs (devfs) @ > > > > /usr/src/sys/kern/vfs_subr.c:2158 > > > > > > > > > This one seems interesting. > > > Next time you experience it can you please drop in DDB and print-out > > > the correct order revealed by WITNESS? > > > > > > > > > Fortunately I could reproduce it. > > > > lock order reversal: > > > > 1st 0xc07e9274 proctree (proctree) @ /usr/src/sys/kern/kern_exit.c:291 > > > > 2nd 0xc3c18278 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 > > KDB: stack backtrace: > > db_trace_self_wrapper(c07682d0,d6078b24,c0573236,c076a615,c3c18278,...) > > > > at db_trace_self_wrapper+0x26 > > > > kdb_backtrace(c076a615,c3c18278,c075bcfb,c075bcfb,c0770a8c,...) at > > kdb_backtrace+0x29 > > witness_checkorder(c3c18278,9,c0770a8c,86e,c07edcd4,...) at > > witness_checkorder+0x6d6 > > _lockmgr_args(c3c18278,20002,c3c182a8,0,ffffffff,...) at _lockmgr_args+0x519 > > vop_stdlock(d6078bc4,d6078bbc,c0572a1c,20002,c3c182a8,...) at vop_stdlock+0x51 > > VOP_LOCK1_APV(c07a07e0,d6078bc4,851,d6078be4,c3c182a8,...) at VOP_LOCK1_APV+0xa5 > > _vn_lock(c3c18220,20002,c0770a8c,86e,4,...) at _vn_lock+0xf2 > > vrele(c3c18220,0,c07619a2,14e,ffffffff,...) at vrele+0x142 > > exit1(c2fdd690,0,d6078d2c,c0729ed3,c2fdd690,...) at exit1+0x8a1 > > sys_exit(c2fdd690,d6078cfc,4,c07625a5,c07a3d38,...) at sys_exit+0x1d > > syscall(d6078d38) at syscall+0x2b3 > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2811964f, esp = > > 0xbfbfeacc, ebp = 0xbfbfead8 --- > > > > Something else? > > > This is the "2nd order". > It would be nice to get where these locks are acquired and what is the > "1st order". > In order to get it, it is enough to break in DDB and do: show witness > at DDB prompt. > [Couldn't connect via serial line, smth is broken in my hw :/ Nevertheless here it is, thanks to rwatson] wbr, pluknet debug.ddb.capture.data: db> show witness Sleep locks: 0 so_rcv_sx -- last acquired @ /usr/src/sys/kern/uipc_sockbuf.c:148 14 so_rcv -- last acquired @ /usr/src/sys/kern/uipc_socket.c:2475 19 sellck -- last acquired @ /usr/src/sys/kern/sys_generic.c:1406 15 radix node head -- last acquired @ /usr/src/sys/net/route.c:147 16 rtentry -- last acquired @ /usr/src/sys/net/route.c:196 17 ifaddr -- last acquired @ /usr/src/sys/net/route.c:821 18 UMA zone -- last acquired @ /usr/src/sys/vm/uma_core.c:2257 17 sctp-addr -- last acquired @ /usr/src/sys/netinet/sctp_pcb.c:649 17 system map -- last acquired @ /usr/src/sys/vm/vm_map.c:3111 19 vm page queue mutex -- last acquired @ /usr/src/sys/vm/vm_pageout.c:1480 20 vnode interlock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:3846 21 cdev -- last acquired @ /usr/src/sys/kern/kern_conf.c:69 21 vnode_free_list -- last acquired @ /usr/src/sys/kern/vfs_subr.c:730 21 Syncer mtx -- last acquired @ /usr/src/sys/kern/vfs_subr.c:1682 20 pmap -- last acquired @ /usr/src/sys/i386/i386/pmap.c:3180 21 vm page queue free mutex -- last acquired @ /usr/src/sys/vm/vm_pageout.c:1448 21 SYSMAPS -- last acquired @ /usr/src/sys/i386/i386/pmap.c:2880 21 vm page queue free mutex -- (already displayed) 21 SYSMAPS -- (already displayed) 18 kmem object -- last acquired @ /usr/src/sys/vm/vm_object.c:460 21 vm page queue free mutex -- (already displayed) 19 vm page queue mutex -- (already displayed) 21 SYSMAPS -- (already displayed) 18 KMAP ENTRY -- last acquired @ /usr/src/sys/vm/uma_core.c:414 18 kernel object -- last acquired @ /usr/src/sys/kern/vfs_bio.c:3675 19 vm page queue mutex -- (already displayed) 21 vm page queue free mutex -- (already displayed) 21 SYSMAPS -- (already displayed) 21 vm page queue free mutex -- (already displayed) 21 SYSMAPS -- (already displayed) 20 pmap -- (already displayed) 17 sctp_it_wq -- last acquired @ /usr/src/sys/netinet/sctputil.c:1345 17 eventhandler -- last acquired @ /usr/src/sys/kern/subr_eventhandler.c:212 18 eventhandler list -- last acquired @ /usr/src/sys/kern/kern_exit.c:227 16 ifnet -- last acquired @ /usr/src/sys/net/if.c:1477 18 UMA zone -- (already displayed) 17 eventhandler -- (already displayed) 17 if_addr_mtx -- last acquired @ /usr/src/sys/netinet/ip_input.c:573 18 UMA zone -- (already displayed) 17 pf task mtx -- last acquired @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:980 18 UMA zone -- (already displayed) 18 eventhandler list -- (already displayed) 18 UMA zone -- (already displayed) 16 UMA boot pages -- last acquired @ /usr/src/sys/vm/uma_core.c:916 17 system map -- (already displayed) 15 process lock -- last acquired @ /usr/src/sys/kern/kern_kthread.c:201 16 session -- last acquired @ /usr/src/sys/kern/kern_proc.c:587 17 uidinfo hash -- last acquired @ /usr/src/sys/kern/kern_resource.c:1213 18 uidinfo struct -- last acquired @ order list:0 18 sleep mtxpool -- last acquired @ /usr/src/sys/kern/sys_generic.c:1316 19 sellck -- (already displayed) 17 tty -- last acquired @ /usr/src/sys/kern/kern_event.c:1666 20 vnode interlock -- (already displayed) 16 sigacts -- last acquired @ /usr/src/sys/kern/subr_sleepqueue.c:392 16 ktrace -- last acquired @ /usr/src/sys/kern/kern_fork.c:607 18 sleep mtxpool -- (already displayed) 16 fdesc -- last acquired @ /usr/src/sys/kern/kern_descrip.c:1467 18 sleep mtxpool -- (already displayed) 18 UMA zone -- (already displayed) 17 eventhandler -- (already displayed) 15 kqueue -- last acquired @ /usr/src/sys/kern/kern_event.c:1442 16 struct mount mtx -- last acquired @ /usr/src/sys/kern/vfs_mount.c:447 20 vnode interlock -- (already displayed) 18 UMA zone -- (already displayed) 11 unp_mtx -- last acquired @ /usr/src/sys/kern/uipc_usrreq.c:558 14 so_rcv -- (already displayed) 12 accept -- last acquired @ /usr/src/sys/kern/uipc_socket.c:685 13 so_snd -- last acquired @ /usr/src/sys/netinet/tcp_output.c:270 14 so_rcv -- (already displayed) 18 sleep mtxpool -- (already displayed) 18 UMA zone -- (already displayed) 15 radix node head -- (already displayed) 16 rtentry -- (already displayed) 14 tcp_hc_entry -- last acquired @ /usr/src/sys/netinet/tcp_hostcache.c:668 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 14 so_rcv -- (already displayed) 13 so_snd -- (already displayed) 18 UMA zone -- (already displayed) 15 process lock -- (already displayed) 7 user map -- last acquired @ /usr/src/sys/vm/vm_map.c:3111 18 UMA zone -- (already displayed) 16 UMA boot pages -- (already displayed) 17 system map -- (already displayed) 21 vm page queue free mutex -- (already displayed) 12 vm object_list -- last acquired @ /usr/src/sys/vm/vm_object.c:693 11 standard object -- last acquired @ /usr/src/sys/kern/vfs_bio.c:3208 21 vm page queue free mutex -- (already displayed) 20 vnode interlock -- (already displayed) 19 vm page queue mutex -- (already displayed) 21 SYSMAPS -- (already displayed) 12 vm object_list -- (already displayed) 18 UMA zone -- (already displayed) 12 swap_pager swhash -- last acquired @ /usr/src/sys/vm/swap_pager.c:1888 19 vm page queue mutex -- (already displayed) 20 pmap -- (already displayed) 20 vnode interlock -- (already displayed) 8 tmpfs -- last acquired @ /usr/src/sys/kern/vfs_subr.c:2063 16 struct mount mtx -- (already displayed) 9 tmpfs node interlock -- last acquired @ /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:419 20 vnode interlock -- (already displayed) 20 vnode interlock -- (already displayed) 18 UMA zone -- (already displayed) 11 Name Cache -- last acquired @ /usr/src/sys/kern/vfs_cache.c:325 20 vnode interlock -- (already displayed) 18 UMA zone -- (already displayed) 9 filedesc structure -- last acquired @ /usr/src/sys/kern/sys_generic.c:959 20 vnode interlock -- (already displayed) 15 process lock -- (already displayed) 11 Name Cache -- (already displayed) 16 fdesc -- (already displayed) 18 UMA zone -- (already displayed) 16 UMA boot pages -- (already displayed) 17 system map -- (already displayed) 13 so_snd -- (already displayed) 21 cdev -- (already displayed) 10 Giant -- last acquired @ /usr/src/sys/kern/kern_intr.c:1033 11 pipe mutex -- last acquired @ /usr/src/sys/kern/sys_pipe.c:1336 12 sigio lock -- last acquired @ /usr/src/sys/kern/kern_descrip.c:783 13 process group -- last acquired @ /usr/src/sys/kern/kern_proc.c:276 15 process lock -- (already displayed) 16 session -- (already displayed) 18 UMA zone -- (already displayed) 14 ttylist -- last acquired @ /usr/src/sys/kern/tty.c:2855 17 tty -- (already displayed) 18 sleep mtxpool -- (already displayed) 19 vm page queue mutex -- (already displayed) 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 11 UMA lock -- last acquired @ /usr/src/sys/vm/uma_core.c:1492 18 UMA zone -- (already displayed) 18 KMAP ENTRY -- (already displayed) 17 eventhandler -- (already displayed) 16 UMA boot pages -- (already displayed) 18 eventhandler list -- (already displayed) 12 kobj -- last acquired @ /usr/src/sys/kern/subr_kobj.c:307 12 kernel environment -- last acquired @ /usr/src/sys/kern/kern_environment.c:301 11 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:655 21 vm page queue free mutex -- (already displayed) 18 kernel object -- (already displayed) 12 vm object_list -- (already displayed) 18 KMAP ENTRY -- (already displayed) 17 uidinfo hash -- (already displayed) 15 process lock -- (already displayed) 18 sleep mtxpool -- (already displayed) 11 evclass_mtx -- last acquired @ /usr/src/sys/security/audit/audit_bsm_klib.c:112 11 TID lock -- last acquired @ /usr/src/sys/kern/subr_unit.c:623 11 standard object -- (already displayed) 11 intr event -- last acquired @ /usr/src/sys/kern/kern_intr.c:423 21 cdev -- (already displayed) 11 GEOM orphanage -- last acquired @ /usr/src/sys/geom/geom_event.c:201 11 vm86 lock -- last acquired @ /usr/src/sys/i386/i386/vm86.c:569 11 sndstat lock -- last acquired @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/sndstat.c:290 14 ttylist -- (already displayed) 11 taskqueue list -- last acquired @ /usr/src/sys/kern/subr_taskqueue.c:125 11 XPT lock -- last acquired @ /usr/src/sys/cam/cam_xpt.c:2646 18 UMA zone -- (already displayed) 12 XPT topology lock -- last acquired @ /usr/src/sys/cam/cam_xpt.c:7192 12 kernel environment -- (already displayed) 12 taskqueue -- last acquired @ /usr/src/sys/kern/subr_taskqueue.c:73 11 intr config -- last acquired @ /usr/src/sys/kern/subr_autoconf.c:72 11 rman head -- last acquired @ /usr/src/sys/kern/subr_rman.c:152 11 rman -- last acquired @ /usr/src/sys/kern/subr_rman.c:539 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 11 devd -- last acquired @ /usr/src/sys/kern/subr_bus.c:499 18 sleep mtxpool -- (already displayed) 11 ACPI semaphore -- last acquired @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:303 11 acpi subsystem HW lock -- last acquired @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:377 11 acpi subsystem GPE lock -- last acquired @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:377 11 ACPI global lock -- last acquired @ /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_machdep.c:270 12 taskqueue -- (already displayed) 16 ifnet -- (already displayed) 11 bpf global lock -- last acquired @ /usr/src/sys/net/bpf.c:1606 12 bpf interface lock -- last acquired @ order list:0 13 bpf cdev lock -- last acquired @ order list:0 13 pcm0:spicds0 -- last acquired @ /usr/src/sys/modules/sound/driver/spicds/../../../../dev/sound/pci/spicds.c:270 11 pcm0:spicds1 -- last acquired @ /usr/src/sys/modules/sound/driver/spicds/../../../../dev/sound/pci/spicds.c:179 11 pcm0:spicds2 -- last acquired @ /usr/src/sys/modules/sound/driver/spicds/../../../../dev/sound/pci/spicds.c:179 12 snd_envy24ht softc -- last acquired @ /usr/src/sys/modules/sound/driver/envy24ht/../../../../dev/sound/pci/envy24ht.c:1910 13 pcm0:spicds0 -- (already displayed) 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 11 sound cdev -- last acquired @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/mixer.c:997 11 pcm fake channel -- last acquired @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/channel.c:1108 18 UMA zone -- (already displayed) 12 kobj -- (already displayed) 11 pcm play channel -- last acquired @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/mixer.c:171 18 UMA zone -- (already displayed) 12 kobj -- (already displayed) 12 snd_envy24ht softc -- (already displayed) 11 pcm record channel -- last acquired @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/mixer.c:171 18 UMA zone -- (already displayed) 12 kobj -- (already displayed) 12 snd_envy24ht softc -- (already displayed) 11 pcm virtual play channel -- last acquired @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/mixer.c:171 18 UMA zone -- (already displayed) 12 kobj -- (already displayed) 11 primary pcm mixer -- last acquired @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/mixer.c:970 11 pcm virtual record channel -- last acquired @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/mixer.c:171 18 UMA zone -- (already displayed) 12 kobj -- (already displayed) 11 bounce pages lock -- last acquired @ /usr/src/sys/i386/i386/busdma_machdep.c:1083 11 ACPI thermal zone -- last acquired @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_thermal.c:941 11 unit# allocation -- last acquired @ /usr/src/sys/kern/subr_unit.c:623 21 vnode_free_list -- (already displayed) 11 pfs_node -- last acquired @ /usr/src/sys/fs/pseudofs/pseudofs_internal.h:103 11 pfs_fileno -- last acquired @ /usr/src/sys/kern/subr_unit.c:623 11 if_clone lock -- last acquired @ /usr/src/sys/net/if_clone.c:164 11 if_cloners lock -- last acquired @ /usr/src/sys/net/if_clone.c:252 11 domain list -- last acquired @ /usr/src/sys/kern/uipc_domain.c:228 12 pfil_head_list lock -- last acquired @ /usr/src/sys/net/pfil.c:115 11 PFil hook read/write mutex -- last acquired @ /usr/src/sys/net/pfil.c:109 12 pfil_head_list lock -- (already displayed) 12 random reseed -- last acquired @ /usr/src/sys/dev/random/yarrow.c:191 12 arc4_mtx -- last acquired @ /usr/src/sys/libkern/arc4random.c:137 11 isn_mtx -- last acquired @ /usr/src/sys/netinet/tcp_subr.c:1433 12 random reseed -- (already displayed) 12 arc4_mtx -- (already displayed) 15 radix node head -- (already displayed) 17 pf task mtx -- (already displayed) 12 XPT topology lock -- (already displayed) 11 ATA queue lock -- last acquired @ /usr/src/sys/dev/ata/ata-queue.c:177 12 ATA state lock -- last acquired @ /usr/src/sys/dev/ata/ata-all.c:316 11 devstat -- last acquired @ /usr/src/sys/kern/subr_devstat.c:83 11 ATAPICAM lock -- last acquired @ /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:642 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 12 kernel environment -- (already displayed) 12 XPT topology lock -- (already displayed) 12 CAM SIMQ lock -- last acquired @ /usr/src/sys/cam/cam_xpt.c:7207 12 taskqueue -- (already displayed) 12 bdone lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:2999 12 g_disk_done -- last acquired @ /usr/src/sys/geom/geom_disk.c:199 18 UMA zone -- (already displayed) 13 bio queue -- last acquired @ /usr/src/sys/geom/geom_io.c:68 11 mountlist -- last acquired @ /usr/src/sys/ufs/ffs/ffs_softdep.c:763 16 struct mount mtx -- (already displayed) 16 struct mount mtx -- (already displayed) 20 vnode interlock -- (already displayed) 11 buf queue lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:1466 20 vnode interlock -- (already displayed) 12 bdone lock -- (already displayed) 11 needsbuffer lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:321 11 FFS Lock -- last acquired @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1150 12 arc4_mtx -- (already displayed) 11 Name Cache -- (already displayed) 11 vfs hash -- last acquired @ /usr/src/sys/kern/vfs_hash.c:71 20 vnode interlock -- (already displayed) 11 dirhash list -- last acquired @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:349 12 dirhash -- last acquired @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:350 12 dirhash -- (already displayed) 11 pbuf mutex -- last acquired @ /usr/src/sys/vm/vm_pager.c:413 11 sf_buf -- last acquired @ /usr/src/sys/i386/i386/vm_machdep.c:820 19 vm page queue mutex -- (already displayed) 13 process group -- (already displayed) 17 tty -- (already displayed) 16 session -- (already displayed) 13 bio queue -- (already displayed) 11 Softdep Lock -- last acquired @ /usr/src/sys/ufs/ffs/ffs_softdep.c:770 18 UMA zone -- (already displayed) 20 vnode interlock -- (already displayed) 12 buffer daemon lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:2106 17 system map -- (already displayed) 11 if_afdata -- last acquired @ /usr/src/sys/netinet6/scope6.c:408 12 scope6_lock -- last acquired @ /usr/src/sys/netinet6/scope6.c:437 17 if_addr_mtx -- (already displayed) 12 if send queue -- last acquired @ /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:2517 11 network driver -- last acquired @ /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:1527 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 16 UMA boot pages -- (already displayed) 17 if_addr_mtx -- (already displayed) 12 taskqueue -- (already displayed) 12 if send queue -- (already displayed) 17 ifaddr -- (already displayed) 12 sigio lock -- (already displayed) 11 nfsd_mtx -- last acquired @ /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_srvsock.c:796 13 so_snd -- (already displayed) 14 so_rcv -- (already displayed) 11 devfs interlock -- last acquired @ /usr/src/sys/fs/devfs/devfs_vnops.c:194 20 vnode interlock -- (already displayed) 21 cdev -- (already displayed) 11 ip6_inq -- last acquired @ /usr/src/sys/net/netisr.c:140 12 ATA state lock -- (already displayed) 18 sleep mtxpool -- (already displayed) 11 pipe mutex -- (already displayed) 15 kqueue -- (already displayed) 10 unp_global_rwlock -- last acquired @ /usr/src/sys/kern/uipc_usrreq.c:557 11 unp_mtx -- (already displayed) 12 accept -- (already displayed) 18 UMA zone -- (already displayed) 11 so_glabel -- last acquired @ /usr/src/sys/kern/uipc_socket.c:299 13 so_snd -- (already displayed) 9 tmpfs allnode lock -- last acquired @ /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:238 17 system map -- (already displayed) 21 vnode_free_list -- (already displayed) 21 cdev -- (already displayed) 12 vm object_list -- (already displayed) 11 standard object -- (already displayed) 15 process lock -- (already displayed) 11 sf_buf -- (already displayed) 4 tcpinp -- last acquired @ /usr/src/sys/netinet/tcp_input.c:479 13 so_snd -- (already displayed) 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 14 so_rcv -- (already displayed) 16 ifnet -- (already displayed) 5 tcp_sc_head -- last acquired @ /usr/src/sys/kern/kern_mutex.c:137 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 12 arc4_mtx -- (already displayed) 15 radix node head -- (already displayed) 16 rtentry -- (already displayed) 14 tcp_hc_entry -- (already displayed) 12 accept -- (already displayed) 11 so_glabel -- (already displayed) 15 radix node head -- (already displayed) 16 rtentry -- (already displayed) 14 tcp_hc_entry -- (already displayed) 5 ip_id_mtx -- last acquired @ /usr/src/sys/netinet/ip_id.c:176 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 12 arc4_mtx -- (already displayed) 12 random reseed -- (already displayed) 12 if send queue -- (already displayed) 11 network driver -- (already displayed) 12 arc4_mtx -- (already displayed) 11 isn_mtx -- (already displayed) 9 filedesc structure -- (already displayed) 0 so_snd_sx -- last acquired @ /usr/src/sys/kern/uipc_sockbuf.c:148 13 so_snd -- (already displayed) 18 UMA zone -- (already displayed) 10 unp_global_rwlock -- (already displayed) 4 tcpinp -- (already displayed) 9 filedesc structure -- (already displayed) 4 rawinp -- last acquired @ /usr/src/sys/netinet/raw_ip.c:639 18 UMA zone -- (already displayed) 11 if_afdata -- (already displayed) 5 addrsel_lock -- last acquired @ /usr/src/sys/netinet6/in6_src.c:860 17 if_addr_mtx -- (already displayed) 12 if send queue -- (already displayed) 11 network driver -- (already displayed) 5 ip_id_mtx -- (already displayed) 15 radix node head -- (already displayed) 16 rtentry -- (already displayed) 14 so_rcv -- (already displayed) 17 system map -- (already displayed) 0 syncer -- last acquired @ /usr/src/sys/kern/vfs_subr.c:1666 20 vnode interlock -- (already displayed) 11 mountlist -- (already displayed) 1 vfslock -- last acquired @ /usr/src/sys/kern/vfs_subr.c:364 18 UMA zone -- (already displayed) 18 sleep mtxpool -- (already displayed) 12 arc4_mtx -- (already displayed) 11 unit# allocation -- (already displayed) 16 struct mount mtx -- (already displayed) 2 mntid -- last acquired @ /usr/src/sys/kern/vfs_subr.c:460 11 mountlist -- (already displayed) 2 devfsmount -- last acquired @ /usr/src/sys/fs/devfs/devfs_vnops.c:201 11 devfs interlock -- (already displayed) 21 vnode_free_list -- (already displayed) 18 UMA zone -- (already displayed) 20 vnode interlock -- (already displayed) 3 devfs -- last acquired @ /usr/src/sys/kern/vfs_vnops.c:673 11 devfs interlock -- (already displayed) 16 struct mount mtx -- (already displayed) 20 vnode interlock -- (already displayed) 9 filedesc structure -- (already displayed) 5 clone events drain lock -- last acquired @ /usr/src/sys/kern/tty_tty.c:70 17 eventhandler -- (already displayed) 18 eventhandler list -- (already displayed) 21 cdev -- (already displayed) 18 UMA zone -- (already displayed) 18 UMA zone -- (already displayed) 21 cdev -- (already displayed) 4 GEOM topology -- last acquired @ /usr/src/sys/geom/geom_event.c:233 11 GEOM orphanage -- (already displayed) 18 UMA zone -- (already displayed) 11 devstat -- (already displayed) 11 unit# allocation -- (already displayed) 21 cdev -- (already displayed) 13 bio queue -- (already displayed) 12 bdone lock -- (already displayed) 17 system map -- (already displayed) 11 ATA queue lock -- (already displayed) 12 vm object_list -- (already displayed) 20 vnode interlock -- (already displayed) 11 standard object -- (already displayed) 12 XPT topology lock -- (already displayed) 11 ATAPICAM lock -- (already displayed) 15 process lock -- (already displayed) 5 swapdev -- last acquired @ /usr/src/sys/vm/swap_pager.c:2235 10 Giant -- (already displayed) 11 Name Cache -- (already displayed) 11 mountlist -- (already displayed) 5 knlist lock for lockless objects -- last acquired @ /usr/src/sys/kern/kern_event.c:1666 11 vfs hash -- (already displayed) 17 system map -- (already displayed) 21 vnode_free_list -- (already displayed) 4 ufs -- last acquired @ /usr/src/sys/kern/vfs_subr.c:2063 16 struct mount mtx -- (already displayed) 11 vfs hash -- (already displayed) 20 vnode interlock -- (already displayed) 11 buf queue lock -- (already displayed) 9 filedesc structure -- (already displayed) 11 Name Cache -- (already displayed) 6 bufwait -- last acquired @ /usr/src/sys/sys/buf.h:300 17 system map -- (already displayed) 20 vnode interlock -- (already displayed) 11 standard object -- (already displayed) 18 UMA zone -- (already displayed) 13 bio queue -- (already displayed) 12 bdone lock -- (already displayed) 10 Giant -- (already displayed) 11 buf queue lock -- (already displayed) 11 needsbuffer lock -- (already displayed) 18 kernel object -- (already displayed) 15 process lock -- (already displayed) 7 user map -- (already displayed) 11 pbuf mutex -- (already displayed) 12 dirhash -- (already displayed) 19 vm page queue mutex -- (already displayed) 21 cdev -- (already displayed) 12 buffer daemon lock -- (already displayed) 11 Softdep Lock -- (already displayed) 11 FFS Lock -- (already displayed) 11 vfs hash -- (already displayed) 16 UMA boot pages -- (already displayed) 7 runningbufspace lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:340 18 UMA zone -- (already displayed) 21 vnode_free_list -- (already displayed) 11 standard object -- (already displayed) 7 user map -- (already displayed) 15 process lock -- (already displayed) 18 sleep mtxpool -- (already displayed) 11 sf_buf -- (already displayed) 19 vm page queue mutex -- (already displayed) 11 pbuf mutex -- (already displayed) 11 dirhash list -- (already displayed) 12 dirhash -- (already displayed) 20 pmap -- (already displayed) 21 cdev -- (already displayed) 16 UMA boot pages -- (already displayed) 12 vm object_list -- (already displayed) 17 system map -- (already displayed) 17 uidinfo hash -- (already displayed) 12 buffer daemon lock -- (already displayed) 11 mountlist -- (already displayed) 5 knlist lock for lockless objects -- (already displayed) 10 Giant -- (already displayed) 9 tmpfs node interlock -- (already displayed) 8 tmpfs -- (already displayed) 12 kobj -- (already displayed) 5 module subsystem sx lock -- last acquired @ /usr/src/sys/kern/kern_module.c:407 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 5 msdosfs -- last acquired @ /usr/src/sys/kern/vfs_subr.c:2063 16 struct mount mtx -- (already displayed) 11 vfs hash -- (already displayed) 20 vnode interlock -- (already displayed) 6 bufwait -- (already displayed) 18 UMA zone -- (already displayed) 11 FFS Lock -- (already displayed) 11 Softdep Lock -- (already displayed) 13 bio queue -- (already displayed) 10 unp_global_rwlock -- (already displayed) 7 runningbufspace lock -- (already displayed) 12 bdone lock -- (already displayed) 11 needsbuffer lock -- (already displayed) 4 proctree -- last acquired @ /usr/src/sys/kern/tty.c:2080 5 allproc -- last acquired @ /usr/src/sys/kern/kern_exit.c:793 6 allprison -- last acquired @ /usr/src/sys/kern/kern_jail.c:952 18 sleep mtxpool -- (already displayed) 15 process lock -- (already displayed) 16 fdesc -- (already displayed) 9 filedesc structure -- (already displayed) 20 vnode interlock -- (already displayed) 7 user map -- (already displayed) 13 process group -- (already displayed) 10 Giant -- (already displayed) 15 process lock -- (already displayed) 16 session -- (already displayed) 12 sigio lock -- (already displayed) 5 clone events drain lock -- (already displayed) 20 vnode interlock -- (already displayed) 18 UMA zone -- (already displayed) 11 GEOM orphanage -- (already displayed) 13 bio queue -- (already displayed) 7 runningbufspace lock -- (already displayed) 15 process lock -- (already displayed) 11 Softdep Lock -- (already displayed) 21 cdev -- (already displayed) 17 system map -- (already displayed) 3 DEVFS ruleset lock -- last acquired @ /usr/src/sys/fs/devfs/devfs_rule.c:177 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 11 mountlist -- (already displayed) 3 devfs -- (already displayed) 17 system map -- (already displayed) 9 filedesc structure -- (already displayed) 20 vnode interlock -- (already displayed) 12 kernel environment -- (already displayed) 11 UMA lock -- (already displayed) 11 FFS Lock -- (already displayed) 4 GEOM topology -- (already displayed) 10 Giant -- (already displayed) 11 Softdep Lock -- (already displayed) 4 ufs -- (already displayed) 2 sysctl lock -- last acquired @ /usr/src/sys/kern/kern_sysctl.c:1415 12 arc4_mtx -- (already displayed) 18 UMA zone -- (already displayed) 5 allproc -- (already displayed) 15 process lock -- (already displayed) 7 user map -- (already displayed) 21 cdev -- (already displayed) 9 filedesc structure -- (already displayed) 16 fdesc -- (already displayed) 3 kernel linker -- last acquired @ /usr/src/sys/kern/kern_linker.c:415 18 UMA zone -- (already displayed) 9 filedesc structure -- (already displayed) 20 vnode interlock -- (already displayed) 4 ufs -- (already displayed) 16 struct mount mtx -- (already displayed) 17 system map -- (already displayed) 6 bufwait -- (already displayed) 5 module subsystem sx lock -- (already displayed) 11 GEOM orphanage -- (already displayed) 10 Giant -- (already displayed) 16 ktrace -- (already displayed) 11 malloc -- (already displayed) 17 system map -- (already displayed) 11 devstat -- (already displayed) 14 ttylist -- (already displayed) 12 vm object_list -- (already displayed) 11 UMA lock -- (already displayed) 21 Syncer mtx -- (already displayed) 10 unp_global_rwlock -- (already displayed) 3 tcp -- last acquired @ /usr/src/sys/netinet/tcp_timer.c:128 4 tcpinp -- (already displayed) 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 12 accept -- (already displayed) 18 sleep mtxpool -- (already displayed) 11 so_glabel -- (already displayed) 5 ip_id_mtx -- (already displayed) 15 radix node head -- (already displayed) 16 rtentry -- (already displayed) 12 if send queue -- (already displayed) 11 network driver -- (already displayed) 5 tcp_sc_head -- (already displayed) 3 udp -- last acquired @ /usr/src/sys/netinet/udp_usrreq.c:385 4 udpinp -- last acquired @ /usr/src/sys/netinet/udp_usrreq.c:1100 5 in_multi_mtx -- last acquired @ /usr/src/sys/netinet/ip_input.c:572 6 igmp_mtx -- last acquired @ /usr/src/sys/netinet/igmp.c:446 17 if_addr_mtx -- (already displayed) 17 if_addr_mtx -- (already displayed) 18 UMA zone -- (already displayed) 11 network driver -- (already displayed) 13 so_snd -- (already displayed) 18 UMA zone -- (already displayed) 16 ifnet -- (already displayed) 12 arc4_mtx -- (already displayed) 15 radix node head -- (already displayed) 16 rtentry -- (already displayed) 12 accept -- (already displayed) 14 so_rcv -- (already displayed) 5 ip_id_mtx -- (already displayed) 5 ip_inq -- last acquired @ /usr/src/sys/net/netisr.c:140 12 if send queue -- (already displayed) 11 network driver -- (already displayed) 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 3 sctp-info -- last acquired @ /usr/src/sys/netinet/sctp_pcb.c:6138 3 rip -- last acquired @ /usr/src/sys/netinet/raw_ip.c:208 18 UMA zone -- (already displayed) 17 system map -- (already displayed) 4 rawinp -- (already displayed) 3 addrsel_sxlock -- last acquired @ /usr/src/sys/netinet6/in6_src.c:1025 5 addrsel_lock -- (already displayed) 3 db_capture_sx -- last acquired @ /usr/src/sys/ddb/db_capture.c:181 3 db_script_mtx -- last acquired @ /usr/src/sys/ddb/db_script.c:526 11 ACPI semaphore -- (already displayed) 6 allprison -- (already displayed) 11 sound cdev -- (already displayed) 11 pcm play channel -- (already displayed) 11 pcm virtual play channel -- (already displayed) 11 pcm record channel -- (already displayed) 11 pcm virtual record channel -- (already displayed) 5 swapdev -- (already displayed) 16 ifnet -- (already displayed) 12 random reseed -- (already displayed) 9 tmpfs allnode lock -- (already displayed) 21 vnode_free_list -- (already displayed) 11 vfs hash -- (already displayed) 6 bufwait -- (already displayed) 13 bio queue -- (already displayed) 9 tmpfs node interlock -- (already displayed) 8 tmpfs -- (already displayed) 7 runningbufspace lock -- (already displayed) 12 buffer daemon lock -- (already displayed) 5 msdosfs -- (already displayed) 12 kobj -- (already displayed) 15 radix node head -- (already displayed) 11 buf queue lock -- (already displayed) 16 struct mount mtx -- (already displayed) 0 rts_inq -- last acquired @ /usr/src/sys/net/netisr.c:140 0 iterator -- last acquired @ /usr/src/sys/netinet/sctputil.c:1209 0 ipqlock -- last acquired @ /usr/src/sys/netinet/ip_input.c:1086 0 ip6qlock -- last acquired @ /usr/src/sys/netinet6/frag6.c:690 0 sem -- last acquired @ /usr/src/sys/kern/sysv_sem.c:1288 0 polling -- last acquired @ /usr/src/sys/kern/kern_poll.c:367 11 network driver -- (already displayed) 15 radix node head -- (already displayed) 18 UMA zone -- (already displayed) 3 udp -- (already displayed) 5 in_multi_mtx -- (already displayed) 3 rip -- (already displayed) 11 ip6_inq -- (already displayed) 12 if send queue -- (already displayed) 3 tcp -- (already displayed) 5 tcp_sc_head -- (already displayed) 16 rtentry -- (already displayed) 14 tcp_hc_entry -- (already displayed) 5 ip_id_mtx -- (already displayed) 0 crossmp -- last acquired @ /usr/src/sys/kern/vfs_lookup.c:686 20 vnode interlock -- (already displayed) 18 UMA zone -- (already displayed) 0 intr sources -- last acquired @ /usr/src/sys/i386/i386/intr_machdep.c:179 0 audit_mtx -- last acquired @ /usr/src/sys/security/audit/audit_worker.c:395 0 uma object -- last acquired @ /usr/src/sys/vm/vm_meter.c:115 0 p_peers -- last acquired @ /usr/src/sys/kern/kern_exit.c:278 0 ACPI root bus -- last acquired @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:1022 11 rman -- (already displayed) 18 UMA zone -- (already displayed) 11 ACPI semaphore -- (already displayed) 0 ACPI PCI bus methods -- last acquired @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pcib.c:221 18 UMA zone -- (already displayed) 11 ACPI semaphore -- (already displayed) 12 kernel environment -- (already displayed) 1 ACPI PCI link -- last acquired @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci_link.c:1046 18 UMA zone -- (already displayed) 11 ACPI semaphore -- (already displayed) 17 system map -- (already displayed) 12 kernel environment -- (already displayed) 0 pf_statetbl_lock -- last acquired @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:979 17 pf task mtx -- (already displayed) 0 umtxql -- last acquired @ /usr/src/sys/kern/kern_umtx.c:326 0 accept_filter_mtx -- last acquired @ /usr/src/sys/kern/uipc_accf.c:116 0 protect sysfilt_ops -- last acquired @ /usr/src/sys/kern/kern_event.c:771 0 vm daemon -- last acquired @ /usr/src/sys/vm/vm_pageout.c:1533 0 rtsock route_cb lock -- last acquired @ /usr/src/sys/net/rtsock.c:236 0 rawcb -- last acquired @ /usr/src/sys/net/raw_cb.c:104 14 so_rcv -- (already displayed) 18 UMA zone -- (already displayed) 0 ng_node -- last acquired @ order list:0 1 ng_worklist -- last acquired @ order list:0 0 802.11 com lock -- last acquired @ order list:0 0 ddp_list_mtx -- last acquired @ order list:0 1 ddp_mtx -- last acquired @ order list:0 0 slip_mtx -- last acquired @ order list:0 1 slip sc_mtx -- last acquired @ order list:0 0 unp -- last acquired @ order list:0 13 so_snd -- (already displayed) Spin locks: Locks which were never acquired: SCSI CD Changer List MD config lock arp_inq pfs_vncache ppp_softc_list_mtx tunmtx msq semid shm dictionary shm timestamps ehcidb agp lock LED sx LED mtx midistat lock audit_pipe_mtx pt_mtx msi audit_worker_sx audit_trigger_mtx ktrace_sx bpin lock ACPI embedded controller ACPI power resources PCM channel sync group lock ACPI CPU ACPI cmbat ACPI generic battery ACPI AC adapter ACPI PCI power methods ACPI Smart Battery ACPI lid ACPI HPET support MSDOSFS fileno UUID generator mutex lock /dev/mem lock fifo mutex kqueue order securelevel mutex lock encapmtx acct_sx phys_pager list dev_pager list swap_pager list vm map sleep mutex PMAP2 db> c From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 21:04:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E7D1106564A; Tue, 18 Mar 2008 21:04:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 0EAAD8FC29; Tue, 18 Mar 2008 21:04:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jbiyf-0000mM-Fv; Tue, 18 Mar 2008 23:04:17 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m2IL46lr015734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 23:04:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m2IL3rAd041640; Tue, 18 Mar 2008 23:03:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m2IL3reh041639; Tue, 18 Mar 2008 23:03:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 Mar 2008 23:03:53 +0200 From: Kostik Belousov To: Attilio Rao Message-ID: <20080318210353.GE10374@deviant.kiev.zoral.com.ua> References: <3bbf2fe10803181145m79e89955re785e1b5048cafd7@mail.gmail.com> <3bbf2fe10803181216l7a1f7a5fp382b03a74d84161f@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X/KOvfZbhhxWSrMq" Content-Disposition: inline In-Reply-To: <3bbf2fe10803181216l7a1f7a5fp382b03a74d84161f@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 81fdb9d644701462f7849401ec726e21 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2438 [Mar 18 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {TO: local part of email appears in body} X-SpamTest-Method: none X-SpamTest-Rate: 9 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: Alex Goncharov , pluknet , freebsd-current@freebsd.org Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 21:04:19 -0000 --X/KOvfZbhhxWSrMq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2008 at 08:16:28PM +0100, Attilio Rao wrote: > 2008/3/18, pluknet : > > On 18/03/2008, Attilio Rao wrote: > > > 2008/3/18, pluknet : > > > > > > > > > > Thought taking that into account I could obtain a new one yesterd= ay. I > > > > didn't see this before. > > > > > > > > Mar 17 03:17:14 pl sudo: pluknet : TTY=3Dttyv1 ; PWD=3D/usr/hom= e/pluknet > > > > ; USER=3Droot ; COMMAND=3D/usr/libexec/getty 3wire.9600 ttyd0 > > > > Mar 17 03:17:14 pl kernel: lock order reversal: > > > > Mar 17 03:17:14 pl kernel: 1st 0xc07e9274 proctree (proctree) @ > > > > /usr/src/sys/kern/kern_exit.c:291 > > > > Mar 17 03:17:14 pl kernel: 2nd 0xc2fc49e8 devfs (devfs) @ > > > > /usr/src/sys/kern/vfs_subr.c:2158 > > > > > > > > > This one seems interesting. > > > Next time you experience it can you please drop in DDB and print-out > > > the correct order revealed by WITNESS? > > > > > > > > > Fortunately I could reproduce it. > > > > lock order reversal: > > > > 1st 0xc07e9274 proctree (proctree) @ /usr/src/sys/kern/kern_exit.c:291 > > > > 2nd 0xc3c18278 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 > > KDB: stack backtrace: > > db_trace_self_wrapper(c07682d0,d6078b24,c0573236,c076a615,c3c18278,...) > > > > at db_trace_self_wrapper+0x26 > > > > kdb_backtrace(c076a615,c3c18278,c075bcfb,c075bcfb,c0770a8c,...) at > > kdb_backtrace+0x29 > > witness_checkorder(c3c18278,9,c0770a8c,86e,c07edcd4,...) at > > witness_checkorder+0x6d6 > > _lockmgr_args(c3c18278,20002,c3c182a8,0,ffffffff,...) at _lockmgr_args= +0x519 > > vop_stdlock(d6078bc4,d6078bbc,c0572a1c,20002,c3c182a8,...) at vop_stdl= ock+0x51 > > VOP_LOCK1_APV(c07a07e0,d6078bc4,851,d6078be4,c3c182a8,...) at VOP_LOCK= 1_APV+0xa5 > > _vn_lock(c3c18220,20002,c0770a8c,86e,4,...) at _vn_lock+0xf2 > > vrele(c3c18220,0,c07619a2,14e,ffffffff,...) at vrele+0x142 > > exit1(c2fdd690,0,d6078d2c,c0729ed3,c2fdd690,...) at exit1+0x8a1 > > sys_exit(c2fdd690,d6078cfc,4,c07625a5,c07a3d38,...) at sys_exit+0x1d > > syscall(d6078d38) at syscall+0x2b3 > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (1, FreeBSD ELF32, sys_exit), eip =3D 0x2811964f, esp =3D > > 0xbfbfeacc, ebp =3D 0xbfbfead8 --- > > > > Something else? >=20 > This is the "2nd order". > It would be nice to get where these locks are acquired and what is the > "1st order". > In order to get it, it is enough to break in DDB and do: show witness > at DDB prompt. >=20 > Thanks, > Attilio The other order comes from the devfs_close. Look at the handling of the controlling terminal at the start of the function. --X/KOvfZbhhxWSrMq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfgLjgACgkQC3+MBN1Mb4gtswCfbmP7MlGlOPWfD96eDY8bfsqe zXgAoMbAdvf2CL/+qpA12fHHP2fE593S =zkvW -----END PGP SIGNATURE----- --X/KOvfZbhhxWSrMq-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 21:18:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C0FA106566B for ; Tue, 18 Mar 2008 21:18:43 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from cenn-smtp.mc.mpls.visi.com (cenn.mc.mpls.visi.com [208.42.156.9]) by mx1.freebsd.org (Postfix) with ESMTP id 60BF38FC26 for ; Tue, 18 Mar 2008 21:18:43 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from mail.tcbug.org (mail.tcbug.org [208.42.70.163]) by cenn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id 180448128; Tue, 18 Mar 2008 16:18:42 -0500 (CDT) Received: from build64.tcbug.org (unknown [208.42.70.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcbug.org (Postfix) with ESMTPSA id 24DAE6DA21E; Tue, 18 Mar 2008 16:18:41 -0500 (CDT) From: Josh Paetzel To: freebsd-current@freebsd.org, vadim_nuclight@mail.ru Date: Tue, 18 Mar 2008 16:18:22 -0500 User-Agent: KMail/1.9.7 References: <200803181433.m2IEXiFk019099@lurza.secnetix.de> In-Reply-To: <200803181433.m2IEXiFk019099@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart35473249.a5uaWbBn1H"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200803181618.27706.josh@tcbug.org> Cc: Oliver Fromme Subject: Re: RELEASE discs & ISO images (for future) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 21:18:43 -0000 --nextPart35473249.a5uaWbBn1H Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 18 March 2008 09:33:44 am Oliver Fromme wrote: > > > Yes, but DVD is still in the future. > > I don't quite understand. Most PCs have a DVD drive. > You can buy DVD-ROM drives for $20. > > Sure, there are old boxes that still have CD drives > only. I'm not saying that FreeBSD should stop making > CD ISO images. But it doesn't have to be the main > focus anymore. The majority of people do have DVD > drives, so the focus should move to providing a DVD > ISO image, getting rid of various problems (space > constraints, CD shuffling annoyance). "Legacy" CD ISO > images could still be provided, but it's lower priority. > The real constraint is that there is pressure from the ftp mirror maintaine= rs=20 to keep what they have to mirror as small as possible. Due to the nature o= f=20 dvds and cds you can provide everything via cd for a user and he/she can=20 trivially create a dvd image from them, or you can provide a dvd image and= =20 either eliminate the cd image and the users who depend on cd images or lose= =20 the ftp mirror sites that refuse to carry the significantly larger FreeBSD= =20 site. =2D-=20 Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB --nextPart35473249.a5uaWbBn1H Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEABECAAYFAkfgMaMACgkQJvkB8Sevrstt8ACdFYuGwr62IUSAnUhEzAoikO1o urQAnRNq/tvFKYmP/TRdRQHEsvyAwo/+ =QfSU -----END PGP SIGNATURE----- --nextPart35473249.a5uaWbBn1H-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 21:47:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A2A1065673; Tue, 18 Mar 2008 21:47:50 +0000 (UTC) (envelope-from SRS0=e70a9b93b4b0ad0d6c100e9a693e4568a743718a=644=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 44E758FC39; Tue, 18 Mar 2008 21:47:50 +0000 (UTC) (envelope-from SRS0=e70a9b93b4b0ad0d6c100e9a693e4568a743718a=644=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id YYN86448; Tue, 18 Mar 2008 14:47:48 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BCDA145019; Tue, 18 Mar 2008 14:47:48 -0700 (PDT) To: Sam Leffler In-Reply-To: Your message of "Tue, 18 Mar 2008 13:24:33 PDT." <47E02501.9050303@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1205876868_31213P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 18 Mar 2008 14:47:48 -0700 From: "Kevin Oberman" Message-Id: <20080318214748.BCDA145019@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Sam Leffler X-To_Domain: freebsd.org X-To: Sam Leffler X-To_Email: sam@freebsd.org X-To_Alias: sam Cc: freebsd-current@freebsd.org, Igor Mozolevsky Subject: Re: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 21:47:51 -0000 --==_Exmh_1205876868_31213P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Tue, 18 Mar 2008 13:24:33 -0700 > From: Sam Leffler > Sender: owner-freebsd-current@freebsd.org > > Igor Mozolevsky wrote: > > On 18/03/2008, John Baldwin wrote: > > > >> On Tuesday 18 March 2008 11:49:29 am Igor Mozolevsky wrote: > >> > On 18/03/2008, John Baldwin wrote: > >> > > >> > > First, which one is broken? Have you tried a RELENG_7_0 kernel and does > >> it do > >> > > the same as a release CD kernel? > >> > > >> > Tried both ISO image and RELENG_7_0, they both work ok, but RELENG_7 > >> doesn't... > >> > >> > >> Ok, and it is cpufreq related? Which cpufreq drivers are attaching to your > >> CPU? > >> > > > > Well, I wouldn't say I'm sure it's 100% cpufreq related, but removing > > it from the kernel fixes the problem... It's also possible that > > cpufreq is interfering with something else... Anyhow, I've got both > > est and p4tcc attaching. > > > > > I'm having lots of problems with cpu freq throttling on t4x laptops. > The system gets very sluggish and when I check the frequency it's been > throttled down. This happens even on ac (haven't checked what powerd is > doing then). Sam, As I have reported, cpufreq does not play well with the T43. I saw the same thing you saw. Pulled cpufreq from my kernel and it's working fine without it. This includes powerd doing its thing and a normal list of speed/energy values from 'sysctl dev.cpu.0'. dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725 -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1205876868_31213P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFH4DiEkn3rs5h7N1ERAkzTAJ0Sv+2iO7+89esfnDMCW3b7x4d1RACfX1j7 1oKf1wiFbhUFQH+UdC/57cU= =9zgN -----END PGP SIGNATURE----- --==_Exmh_1205876868_31213P-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 22:40:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C7B1065683; Tue, 18 Mar 2008 22:40:02 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id C7B8D8FC13; Tue, 18 Mar 2008 22:40:01 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m2IMdqbs094622; Tue, 18 Mar 2008 18:39:57 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 18 Mar 2008 12:40:41 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ivan Voras In-Reply-To: Message-ID: <20080318124019.O910@desktop> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Panic of 8-CURRENT in VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 22:40:02 -0000 On Tue, 18 Mar 2008, Ivan Voras wrote: > Ivan Voras wrote: >> Hi, >> I cannot boot a very recent build (minutes ago) of 8-CURRENT on VMWare >> Server. Panic ("integer divide fault" - is this division by zero?) is in >> sched_rr_interval(). >> >> More info here: >> http://ivoras.sharanet.org/stuff/panic/ >> >> It might be because I'm trying to run without WITNESS+INVARIANTS. > > No, building a GENERIC kernel doesn't change anything. It's also not a cvsup > glitch - todays sources panic in exactly the same way. > > Can you tell me what the values of: sysctl kern.sched.slice and sysctl kern.clockrate are? Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Tue Mar 18 23:08:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A74C7106564A for ; Tue, 18 Mar 2008 23:08:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7238FC1A for ; Tue, 18 Mar 2008 23:08:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jbkua-0003pw-3s for freebsd-current@freebsd.org; Tue, 18 Mar 2008 23:08:04 +0000 Received: from 78-1-99-185.adsl.net.t-com.hr ([78.1.99.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Mar 2008 23:08:04 +0000 Received: from ivoras by 78-1-99-185.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Mar 2008 23:08:04 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 19 Mar 2008 00:07:54 +0100 Lines: 70 Message-ID: References: <20080318124019.O910@desktop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig208DCAEF9C34C47EC19185EC" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-99-185.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: <20080318124019.O910@desktop> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Panic of 8-CURRENT in VMWare X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Mar 2008 23:08:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig208DCAEF9C34C47EC19185EC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Jeff Roberson wrote: >=20 > On Tue, 18 Mar 2008, Ivan Voras wrote: >=20 >> Ivan Voras wrote: >>> Hi, >>> I cannot boot a very recent build (minutes ago) of 8-CURRENT on=20 >>> VMWare Server. Panic ("integer divide fault" - is this division by=20 >>> zero?) is in sched_rr_interval(). >>> >>> More info here: >>> http://ivoras.sharanet.org/stuff/panic/ >>> >>> It might be because I'm trying to run without WITNESS+INVARIANTS. >> >> No, building a GENERIC kernel doesn't change anything. It's also not a= =20 >> cvsup glitch - todays sources panic in exactly the same way. >> >> > Can you tell me what the values of: >=20 > sysctl kern.sched.slice >=20 > and >=20 > sysctl kern.clockrate >=20 > are? The machine doesn't finish booting the kernel (i.e. init isn't executed) = and fetching sysctls apparently isn't supported by the kernel debugger=20 (though it would be nice if it did work, at least for simple variables). The only old kernel I have is 7.0RC1, and in it I can only access=20 kern.clockrate, which is { hz=3D50, tick=3D20000, profhz=3D33, stathz=3D6= }. Since you brought up the issue of clocks, I removed the tuning of=20 kern.hz (it was present there practically forever) and the panic's gone. = I use low values for kern.hz in VMWare to (noticably) reduce problems=20 with clock drift and context switches, so it would be nice to not have=20 the kernel panic with it :) Apparently lowering kern.hz works upto about 75 - anything lower=20 triggers the integer divide fault. --------------enig208DCAEF9C34C47EC19185EC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4EtLldnAQVacBcgRAqR8AKDbbHRU5R1RvDjA6Ei/01hoxLMJUgCg5d1A FhrBbesPw4XIFdAR8E6upaE= =G0pZ -----END PGP SIGNATURE----- --------------enig208DCAEF9C34C47EC19185EC-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 19 02:22:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A74951065673 for ; Wed, 19 Mar 2008 02:22:09 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 095808FC1A for ; Wed, 19 Mar 2008 02:22:08 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 18 Mar 2008 22:22:08 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.8.6-GA) with ESMTP id JUH16348; Tue, 18 Mar 2008 22:22:07 -0400 (EDT) Received: from 209-6-22-188.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.188]) by smtp01.lnh.mail.rcn.net with ESMTP; 18 Mar 2008 22:23:02 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18400.30930.430744.931475@jerusalem.litteratus.org> Date: Tue, 18 Mar 2008 22:22:10 -0400 To: "Kip Macy" In-Reply-To: References: <18399.51985.110882.166457@jerusalem.litteratus.org> X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Cc: Robert Huff , freebsd-current@freebsd.org, Alex Goncharov Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Mar 2008 02:22:09 -0000 Kip Macy writes: > > I'm gettig both of these as well. It doesn't stop the system > > from booting, or _seem_ to affect operation ... but it would be nice > > if they would go away. < > See archives / UPDATING for an explanation. 1) Am I correct in thinking you mean this: 20080301: The layout of struct vmspace has changed. This affects libkvm and any executables that link against libkvm and use the kvm_getprocs() function. In particular, but not exclusively, it affects ps(1), fstat(1), pkill(1), systat(1), top(1) and w(1). The effects are minimal, but it's advisable to upgrade world nonetheless. 2) I updated/rebuilt/installed world today. Still getting the LORs; see appended. Robert Huff Mar 18 22:10:04 jerusalem kernel: Copyright (c) 1992-2008 The FreeBSD Project. Mar 18 22:10:04 jerusalem kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 18 22:10:04 jerusalem kernel: The Regents of the University of California. All rights reserved. Mar 18 22:10:04 jerusalem kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Mar 18 22:10:04 jerusalem kernel: FreeBSD 8.0-CURRENT #0: Tue Mar 18 20:52:53 EDT 2008 Mar 18 22:10:04 jerusalem kernel: huff@jerusalem.litteratus.org:/usr/obj/usr/src/sys/JERUSALEM Mar 18 22:10:04 jerusalem kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 18 22:10:04 jerusalem kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 18 22:10:04 jerusalem kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz (2266.76-MHz 686-class CPU) Mar 18 22:10:04 jerusalem kernel: Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Mar 18 22:10:04 jerusalem kernel: Features=0x3febfbff Mar 18 22:10:04 jerusalem kernel: real memory = 536854528 (511 MB) Mar 18 22:10:04 jerusalem kernel: avail memory = 516349952 (492 MB) Mar 18 22:10:04 jerusalem kernel: acpi0: on motherboard Mar 18 22:10:04 jerusalem kernel: acpi0: [ITHREAD] Mar 18 22:10:04 jerusalem kernel: acpi0: Power Button (fixed) Mar 18 22:10:04 jerusalem kernel: acpi0: reservation of 0, a0000 (3) failed Mar 18 22:10:04 jerusalem kernel: acpi0: reservation of 100000, 1ff00000 (3) failed Mar 18 22:10:04 jerusalem kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 Mar 18 22:10:04 jerusalem kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 Mar 18 22:10:04 jerusalem kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 18 22:10:04 jerusalem kernel: pci0: on pcib0 Mar 18 22:10:04 jerusalem kernel: agp0: on hostb0 Mar 18 22:10:04 jerusalem kernel: pcib1: at device 1.0 on pci0 Mar 18 22:10:04 jerusalem kernel: pci1: on pcib1 Mar 18 22:10:04 jerusalem kernel: vgapci0: mem 0xfc000000-0xfdffffff,0xf3800000-0xf3803fff,0xf3000000-0xf37fffff irq 11 at device 0.0 on pci1 Mar 18 22:10:04 jerusalem kernel: drm0: on vgapci0 Mar 18 22:10:04 jerusalem kernel: info: [drm] AGP at 0xf4000000 64MB Mar 18 22:10:04 jerusalem kernel: info: [drm] Initialized mga 3.2.2 20060319 Mar 18 22:10:04 jerusalem kernel: isab0: at device 2.0 on pci0 Mar 18 22:10:04 jerusalem kernel: isa0: on isab0 Mar 18 22:10:04 jerusalem kernel: ohci0: mem 0xf2800000-0xf2800fff irq 5 at device 2.2 on pci0 Mar 18 22:10:04 jerusalem kernel: ohci0: [GIANT-LOCKED] Mar 18 22:10:04 jerusalem kernel: ohci0: [ITHREAD] Mar 18 22:10:04 jerusalem kernel: usb0: OHCI version 1.0, legacy support Mar 18 22:10:04 jerusalem kernel: usb0: SMM does not respond, resetting Mar 18 22:10:04 jerusalem kernel: usb0: on ohci0 Mar 18 22:10:04 jerusalem kernel: usb0: USB revision 1.0 Mar 18 22:10:04 jerusalem kernel: uhub0: on usb0 Mar 18 22:10:04 jerusalem kernel: uhub0: 3 ports with 3 removable, self powered Mar 18 22:10:04 jerusalem kernel: ohci1: mem 0xf2000000-0xf2000fff irq 9 at device 2.3 on pci0 Mar 18 22:10:04 jerusalem kernel: ohci1: [GIANT-LOCKED] Mar 18 22:10:04 jerusalem kernel: ohci1: [ITHREAD] Mar 18 22:10:04 jerusalem kernel: usb1: OHCI version 1.0, legacy support Mar 18 22:10:04 jerusalem kernel: usb1: SMM does not respond, resetting Mar 18 22:10:04 jerusalem kernel: usb1: on ohci1 Mar 18 22:10:04 jerusalem kernel: usb1: USB revision 1.0 Mar 18 22:10:04 jerusalem kernel: uhub1: on usb1 Mar 18 22:10:04 jerusalem kernel: uhub1: 3 ports with 3 removable, self powered Mar 18 22:10:04 jerusalem kernel: pci0: at device 2.5 (no driver attached) Mar 18 22:10:04 jerusalem kernel: pcm0: port 0xa800-0xa8ff irq 10 at device 5.0 on pci0 Mar 18 22:10:04 jerusalem kernel: pcm0: [ITHREAD] Mar 18 22:10:04 jerusalem kernel: ahc0: port 0xa400-0xa4ff mem 0xf1000000-0xf1000fff irq 11 at device 8.0 on pci0 Mar 18 22:10:04 jerusalem kernel: ahc0: [ITHREAD] Mar 18 22:10:04 jerusalem kernel: aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs Mar 18 22:10:04 jerusalem kernel: ohci2: mem 0xf0800000-0xf0800fff irq 14 at device 10.0 on pci0 Mar 18 22:10:04 jerusalem kernel: ohci2: [GIANT-LOCKED] Mar 18 22:10:04 jerusalem kernel: ohci2: [ITHREAD] Mar 18 22:10:04 jerusalem kernel: usb2: OHCI version 1.0, legacy support Mar 18 22:10:04 jerusalem kernel: usb2: on ohci2 Mar 18 22:10:04 jerusalem kernel: usb2: USB revision 1.0 Mar 18 22:10:04 jerusalem kernel: uhub2: on usb2 Mar 18 22:10:04 jerusalem kernel: uhub2: 2 ports with 2 removable, self powered Mar 18 22:10:04 jerusalem kernel: ehci0: mem 0xf0000000-0xf00000ff irq 15 at device 10.3 on pci0 Mar 18 22:10:04 jerusalem kernel: ehci0: [GIANT-LOCKED] Mar 18 22:10:04 jerusalem kernel: ehci0: [ITHREAD] Mar 18 22:10:04 jerusalem kernel: usb3: EHCI version 1.0 Mar 18 22:10:04 jerusalem kernel: usb3: companion controller, 2 ports each: usb2 Mar 18 22:10:04 jerusalem kernel: usb3: on ehci0 Mar 18 22:10:04 jerusalem kernel: usb3: USB revision 2.0 Mar 18 22:10:04 jerusalem kernel: uhub3: on usb3 Mar 18 22:10:04 jerusalem kernel: uhub3: 6 ports with 6 removable, self powered Mar 18 22:10:04 jerusalem kernel: umass0: on uhub3 Mar 18 22:10:04 jerusalem kernel: em0: port 0xa000-0xa03f mem 0xef800000-0xef81ffff,0xef000000-0xef03ffff irq 11 at device 12.0 on pci0 Mar 18 22:10:04 jerusalem kernel: em0: [FILTER] Mar 18 22:10:04 jerusalem kernel: em0: Ethernet address: 00:0e:0c:a8:a7:e8 Mar 18 22:10:04 jerusalem kernel: em1: port 0x9800-0x983f mem 0xee800000-0xee81ffff irq 10 at device 12.1 on pci0 Mar 18 22:10:04 jerusalem kernel: em1: [FILTER] Mar 18 22:10:04 jerusalem kernel: em1: Ethernet address: 00:0e:0c:a8:a7:e9 Mar 18 22:10:04 jerusalem kernel: cpu0: on acpi0 Mar 18 22:10:04 jerusalem kernel: acpi_throttle0: on cpu0 Mar 18 22:10:04 jerusalem kernel: acpi_button0: on acpi0 Mar 18 22:10:04 jerusalem kernel: fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Mar 18 22:10:04 jerusalem kernel: fdc0: [FILTER] Mar 18 22:10:04 jerusalem kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Mar 18 22:10:04 jerusalem kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 18 22:10:04 jerusalem kernel: sio0: type 16550A Mar 18 22:10:04 jerusalem kernel: sio0: [FILTER] Mar 18 22:10:04 jerusalem kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 Mar 18 22:10:04 jerusalem kernel: sio1: type 16550A Mar 18 22:10:04 jerusalem kernel: sio1: [FILTER] Mar 18 22:10:04 jerusalem kernel: orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xcc000-0xd17ff,0xd4000-0xd4fff pnpid ORM0000 on isa0 Mar 18 22:10:04 jerusalem kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 Mar 18 22:10:04 jerusalem kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Mar 18 22:10:04 jerusalem kernel: ppc0: FIFO with 16/16/16 bytes threshold Mar 18 22:10:04 jerusalem kernel: ppbus0: on ppc0 Mar 18 22:10:04 jerusalem kernel: ppbus0: [ITHREAD] Mar 18 22:10:04 jerusalem kernel: lpt0: on ppbus0 Mar 18 22:10:04 jerusalem kernel: lpt0: Interrupt-driven port Mar 18 22:10:04 jerusalem kernel: ppi0: on ppbus0 Mar 18 22:10:04 jerusalem kernel: ppc0: [GIANT-LOCKED] Mar 18 22:10:04 jerusalem kernel: ppc0: [ITHREAD] Mar 18 22:10:04 jerusalem kernel: sc0: at flags 0x100 on isa0 Mar 18 22:10:04 jerusalem kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 18 22:10:04 jerusalem kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 18 22:10:04 jerusalem kernel: uhub4: on uhub0 Mar 18 22:10:04 jerusalem kernel: uhub4: 4 ports with 4 removable, bus powered Mar 18 22:10:04 jerusalem kernel: ums0: on uhub4 Mar 18 22:10:04 jerusalem kernel: ums0: 8 buttons and Z dir. Mar 18 22:10:04 jerusalem kernel: ukbd0: on uhub4 Mar 18 22:10:04 jerusalem kernel: kbd0 at ukbd0 Mar 18 22:10:04 jerusalem kernel: ugen0: on uhub0 Mar 18 22:10:04 jerusalem kernel: ugen1: on uhub2 Mar 18 22:10:04 jerusalem kernel: Timecounter "TSC" frequency 2266762208 Hz quality 800 Mar 18 22:10:04 jerusalem kernel: Timecounters tick every 1.000 msec Mar 18 22:10:04 jerusalem kernel: ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based forwarding disabled, default to deny, logging limited to 100 packets/entry by default Mar 18 22:10:04 jerusalem kernel: da0 at ahc0 bus 0 target 0 lun 0 Mar 18 22:10:04 jerusalem kernel: da0: Fixed Direct Access SCSI-2 device Mar 18 22:10:04 jerusalem kernel: da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit) Mar 18 22:10:04 jerusalem kernel: da0: Command Queueing Enabled Mar 18 22:10:04 jerusalem kernel: da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) Mar 18 22:10:04 jerusalem kernel: da1 at ahc0 bus 0 target 1 lun 0 Mar 18 22:10:04 jerusalem kernel: da1: Fixed Direct Access SCSI-2 device Mar 18 22:10:04 jerusalem kernel: da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit) Mar 18 22:10:04 jerusalem kernel: da1: Command Queueing Enabled Mar 18 22:10:04 jerusalem kernel: da1: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) Mar 18 22:10:04 jerusalem kernel: da2 at ahc0 bus 0 target 2 lun 0 Mar 18 22:10:04 jerusalem kernel: da2: Fixed Direct Access SCSI-2 device Mar 18 22:10:04 jerusalem kernel: da2: 10.000MB/s transfers (10.000MHz, offset 15) Mar 18 22:10:04 jerusalem kernel: da2: Command Queueing Enabled Mar 18 22:10:04 jerusalem kernel: da2: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) Mar 18 22:10:04 jerusalem kernel: da3 at umass-sim0 bus 0 target 0 lun 0 Mar 18 22:10:04 jerusalem kernel: da3: Fixed Direct Access SCSI-0 device Mar 18 22:10:04 jerusalem kernel: da3: 40.000MB/s transfers Mar 18 22:10:04 jerusalem kernel: da3: 95611MB (195813072 512 byte sectors: 255H 63S/T 12188C) Mar 18 22:10:04 jerusalem kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 18 22:10:04 jerusalem kernel: cd0 at ahc0 bus 0 target 3 lun 0 Mar 18 22:10:04 jerusalem kernel: cd0: Removable CD-ROM SCSI-2 device Mar 18 22:10:04 jerusalem kernel: cd0: 3.300MB/s transfers Mar 18 22:10:04 jerusalem kernel: cd0: cd present [331717 x 2048 byte records] Mar 18 22:10:04 jerusalem kernel: lock order reversal: Mar 18 22:10:04 jerusalem kernel: 1st 0xc2aa1e28 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2064 Mar 18 22:10:04 jerusalem kernel: 2nd 0xc2b60194 devfsmount (devfsmount) @ /usr/src/sys/fs/devfs/devfs_vnops.c:201 Mar 18 22:10:04 jerusalem kernel: KDB: stack backtrace: Mar 18 22:10:04 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d3ac8bbc,c058c09d,c070e5f6,c2b60194,...) at db_trace_self_wrapper+0x26 Mar 18 22:10:04 jerusalem kernel: kdb_backtrace(c070e5f6,c2b60194,c0700b2f,c0700b2f,c0700b70,...) at kdb_backtrace+0x29 Mar 18 22:10:04 jerusalem kernel: witness_checkorder(c2b60194,9,c0700b70,c9,c7,...) at witness_checkorder+0x6af Mar 18 22:10:04 jerusalem kernel: _sx_xlock(c2b60194,0,c0700b70,c9,c2b60194,...) at _sx_xlock+0x77 Mar 18 22:10:04 jerusalem kernel: devfs_allocv(c2b62180,c2b64000,d3ac8c28,c28ea000,c0714353,...) at devfs_allocv+0x13e Mar 18 22:10:04 jerusalem kernel: devfs_root(c2b64000,2,c07d7ad8,c28ea000,ca,...) at devfs_root+0x51 Mar 18 22:10:04 jerusalem kernel: set_rootvnode(c07d7ac0,0,c0714353,5f4,c05c52da,...) at set_rootvnode+0x2b Mar 18 22:10:04 jerusalem kernel: vfs_mountroot(c078c830,4,c07047a9,264,c058611f,...) at vfs_mountroot+0x334 Mar 18 22:10:04 jerusalem kernel: start_init(0,d3ac8d38,c0706143,30c,c28e7000,...) at start_init+0x65 Mar 18 22:10:04 jerusalem kernel: fork_exit(c0526dcd,0,d3ac8d38) at fork_exit+0xb8 Mar 18 22:10:04 jerusalem kernel: fork_trampoline() at fork_trampoline+0x8 Mar 18 22:10:04 jerusalem kernel: --- trap 0, eip = 0, esp = 0xd3ac8d70, ebp = 0 --- Mar 18 22:10:04 jerusalem kernel: Trying to mount root from ufs:/dev/da0s1a Mar 18 22:10:04 jerusalem kernel: lock order reversal: Mar 18 22:10:04 jerusalem kernel: 1st 0xc2aa19e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2064 Mar 18 22:10:04 jerusalem kernel: 2nd 0xc2b64000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 Mar 18 22:10:04 jerusalem kernel: KDB: stack backtrace: Mar 18 22:10:04 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d3ac89dc,c058c09d,c070e5f6,c2b64000,...) at db_trace_self_wrapper+0x26 Mar 18 22:10:04 jerusalem kernel: kdb_backtrace(c070e5f6,c2b64000,c0714456,c0714456,c07149ee,...) at kdb_backtrace+0x29 Mar 18 22:10:04 jerusalem kernel: witness_checkorder(c2b64000,1,c07149ee,16c,d3ac8a1c,...) at witness_checkorder+0x6af Mar 18 22:10:04 jerusalem kernel: _lockmgr_args(c2b64000,20001,c2b64030,0,ffffffff,...) at _lockmgr_args+0x1c9 Mar 18 22:10:04 jerusalem kernel: vfs_busy(c2b64000,0,0,c28ea000,d3ac8b58,...) at vfs_busy+0x19f Mar 18 22:10:04 jerusalem kernel: lookup(d3ac8b44,c071411b,c6,bf,c28cdb2c,...) at lookup+0x735 Mar 18 22:10:04 jerusalem kernel: namei(d3ac8b44,c2b64030,1c1,c0714353,d3ac8b54,...) at namei+0x25e Mar 18 22:10:04 jerusalem kernel: kern_unlink(c28ea000,c0714790,1,62f,0,...) at kern_unlink+0x39 Mar 18 22:10:04 jerusalem kernel: vfs_mountroot_try(c071494a,c070dfd0,c06fecf9,1,c05c52da,...) at vfs_mountroot_try+0x466 Mar 18 22:10:04 jerusalem kernel: vfs_mountroot(c078c830,4,c07047a9,264,c058611f,...) at vfs_mountroot+0x3f2 Mar 18 22:10:04 jerusalem kernel: start_init(0,d3ac8d38,c0706143,30c,c28e7000,...) at start_init+0x65 Mar 18 22:10:04 jerusalem kernel: fork_exit(c0526dcd,0,d3ac8d38) at fork_exit+0xb8 Mar 18 22:10:04 jerusalem kernel: fork_trampoline() at fork_trampoline+0x8 Mar 18 22:10:04 jerusalem kernel: --- trap 0, eip = 0, esp = 0xd3ac8d70, ebp = 0 --- Mar 18 22:10:04 jerusalem kernel: lock order reversal: Mar 18 22:10:04 jerusalem kernel: 1st 0xc28ec044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3111 Mar 18 22:10:04 jerusalem kernel: 2nd 0xc2aa17c8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2064 Mar 18 22:10:04 jerusalem kernel: KDB: stack backtrace: Mar 18 22:10:04 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d3ac89c0,c058c09d,c070e5f6,c2aa17c8,...) at db_trace_self_wrapper+0x26 Mar 18 22:10:04 jerusalem kernel: kdb_backtrace(c070e5f6,c2aa17c8,c0703ec1,c0703ec1,c07149ee,...) at kdb_backtrace+0x29 Mar 18 22:10:04 jerusalem kernel: witness_checkorder(c2aa17c8,1,c07149ee,810,d3ac89e4,...) at witness_checkorder+0x6af Mar 18 22:10:04 jerusalem kernel: _lockmgr_args(c2aa17c8,30041,c2aa17f8,0,ffffffff,...) at _lockmgr_args+0x1c9 Mar 18 22:10:04 jerusalem kernel: ffs_lock(d3ac8a74,c054b23c,c0791354,30041,c2aa1770,...) at ffs_lock+0xa1 Mar 18 22:10:04 jerusalem kernel: VOP_LOCK1_APV(c0767d60,d3ac8a74,c070dfce,3,c2aa17f8,...) at VOP_LOCK1_APV+0xab Mar 18 22:10:04 jerusalem kernel: _vn_lock(c2aa1770,30041,c07149ee,810,0,...) at _vn_lock+0xed Mar 18 22:10:04 jerusalem kernel: vget(c2aa1770,30041,c28ea000,4a9,c1046780,...) at vget+0x101 Mar 18 22:10:04 jerusalem kernel: vnode_pager_lock(c1046600,0,c0722bee,127,d3ac8be8,...) at vnode_pager_lock+0x1a5 Mar 18 22:10:04 jerusalem kernel: vm_fault(c28ec000,80b4000,2,8,80b4000,...) at vm_fault+0x1dc Mar 18 22:10:04 jerusalem kernel: trap_pfault(5,0,c072b9a2,2c4,c,...) at trap_pfault+0xf9 Mar 18 22:10:04 jerusalem kernel: trap(d3ac8d38) at trap+0x230 Mar 18 22:10:04 jerusalem kernel: calltrap() at calltrap+0x6 Mar 18 22:10:04 jerusalem kernel: --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfef10, ebp = 0xbfbfef30 --- Mar 18 22:10:05 jerusalem savecore: no dumps found Mar 18 22:10:06 jerusalem kernel: lock order reversal: Mar 18 22:10:06 jerusalem kernel: 1st 0xc2bfdaf8 isofs (isofs) @ /usr/src/sys/kern/vfs_subr.c:2064 Mar 18 22:10:06 jerusalem kernel: 2nd 0xc2b63538 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 Mar 18 22:10:06 jerusalem kernel: KDB: stack backtrace: Mar 18 22:10:06 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d5f5ba18,c058c09d,c070e5f6,c2b63538,...) at db_trace_self_wrapper+0x26 Mar 18 22:10:06 jerusalem kernel: kdb_backtrace(c070e5f6,c2b63538,c0714456,c0714456,c07149ee,...) at kdb_backtrace+0x29 Mar 18 22:10:06 jerusalem kernel: witness_checkorder(c2b63538,1,c07149ee,16c,d5f5ba58,...) at witness_checkorder+0x6af Mar 18 22:10:06 jerusalem kernel: _lockmgr_args(c2b63538,20001,c2b63568,0,ffffffff,...) at _lockmgr_args+0x1c9 Mar 18 22:10:06 jerusalem kernel: vfs_busy(c2b63538,10,0,c2b9b220,0,...) at vfs_busy+0x19f Mar 18 22:10:06 jerusalem kernel: vfs_donmount(810e080,c,d5f5bc74,c2dc3600,0,...) at vfs_donmount+0xdc8 Mar 18 22:10:06 jerusalem kernel: nmount(c2b9b220,d5f5bcfc,c,c070f2c4,c0751e10,...) at nmount+0x8e Mar 18 22:10:06 jerusalem kernel: syscall(d5f5bd38) at syscall+0x237 Mar 18 22:10:06 jerusalem kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Mar 18 22:10:06 jerusalem kernel: --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480dafcf, esp = 0xbfbfe97c, ebp = 0xbfbfedd8 --- Mar 18 22:10:06 jerusalem kernel: lock order reversal: Mar 18 22:10:06 jerusalem kernel: 1st 0xc2bfd278 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_subr.c:2064 Mar 18 22:10:06 jerusalem kernel: 2nd 0xc2b6329c vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 Mar 18 22:10:06 jerusalem kernel: KDB: stack backtrace: Mar 18 22:10:06 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d5f5ba18,c058c09d,c070e5f6,c2b6329c,...) at db_trace_self_wrapper+0x26 Mar 18 22:10:06 jerusalem kernel: kdb_backtrace(c070e5f6,c2b6329c,c0714456,c0714456,c07149ee,...) at kdb_backtrace+0x29 Mar 18 22:10:06 jerusalem kernel: witness_checkorder(c2b6329c,1,c07149ee,16c,d5f5ba58,...) at witness_checkorder+0x6af Mar 18 22:10:06 jerusalem kernel: _lockmgr_args(c2b6329c,20001,c2b632cc,0,ffffffff,...) at _lockmgr_args+0x1c9 Mar 18 22:10:06 jerusalem kernel: vfs_busy(c2b6329c,10,0,c2b9b220,0,...) at vfs_busy+0x19f Mar 18 22:10:06 jerusalem kernel: vfs_donmount(810e080,c,d5f5bc74,c2dc3680,0,...) at vfs_donmount+0xdc8 Mar 18 22:10:06 jerusalem kernel: nmount(c2b9b220,d5f5bcfc,c,c070f2c4,c0751e10,...) at nmount+0x8e Mar 18 22:10:06 jerusalem kernel: syscall(d5f5bd38) at syscall+0x237 Mar 18 22:10:06 jerusalem kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Mar 18 22:10:06 jerusalem kernel: --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480dafcf, esp = 0xbfbfe97c, ebp = 0xbfbfedd8 --- From owner-freebsd-current@FreeBSD.ORG Wed Mar 19 02:25:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C27221065672 for ; Wed, 19 Mar 2008 02:25:11 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 90E138FC1B for ; Wed, 19 Mar 2008 02:25:11 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so191026waf.3 for ; Tue, 18 Mar 2008 19:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8Con8OOjGCXODleeoyao6JjM21BXc52/qqmdNgr4QPU=; b=ABpLDHTbxic7CrReHjpN2Nl2V0Hppd9AFE700nC36fKl9L6EqGYxHOGAv7sFEG3fYFuJoZADa2+1wZyo68QBSAX5WGt5Eq8F9Ukx+R8H1jzmKvQzmV8zKUdti04ifc5SmDO7pgszqElSkQqAIbKmJXivqWq7rOts9ZmUb/6Gvwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ARpOiIta3aL0M+KpL+DvwBn8to7Ka/UFUE2v/RQKWx/WZS2w3GPNf20LNld4Hs1C3WwOxLsXCdOrC/8fixRV2416RXxPDLeBGwJcZuLw0IDF1KTvBFAWvWQmz/XQvesrzHpz7Wtkt3p++1qeAWcMIK02ZClkpPpm/Jly0RlRGgE= Received: by 10.114.132.5 with SMTP id f5mr393658wad.50.1205893511181; Tue, 18 Mar 2008 19:25:11 -0700 (PDT) Received: by 10.115.22.10 with HTTP; Tue, 18 Mar 2008 19:25:11 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 19:25:11 -0700 From: "Kip Macy" To: "Robert Huff" In-Reply-To: <18400.30930.430744.931475@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18399.51985.110882.166457@jerusalem.litteratus.org> <18400.30930.430744.931475@jerusalem.litteratus.org> Cc: freebsd-current@freebsd.org, Alex Goncharov Subject: Re: Seeing lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Mar 2008 02:25:12 -0000 On Tue, Mar 18, 2008 at 7:22 PM, Robert Huff wrote: > Kip Macy writes: > > > > I'm gettig both of these as well. It doesn't stop the system > > > from booting, or _seem_ to affect operation ... but it would be nice > > > if they would go away. > < > > > See archives / UPDATING for an explanation. > WITNESS support was recently added for lockmgr - the locking primitive used by FreeBSD's file systems. If that fact is not in UPDATING it *should be* (this means you Attilio). Most of the VFS LORs you are seeing are likely pre-exisiting because but were kept hidden by lack of WITNESS support and only manifested themselves as periodic deadlocks. -Kip > 1) Am I correct in thinking you mean this: > > 20080301: > The layout of struct vmspace has changed. This affects libkvm > and any executables that link against libkvm and use the > kvm_getprocs() function. In particular, but not exclusively, > it affects ps(1), fstat(1), pkill(1), systat(1), top(1) and w(1). > The effects are minimal, but it's advisable to upgrade world > nonetheless. > > > 2) I updated/rebuilt/installed world today. Still getting the > LORs; see appended. > > > Robert Huff > > > Mar 18 22:10:04 jerusalem kernel: Copyright (c) 1992-2008 The FreeBSD Project. > Mar 18 22:10:04 jerusalem kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > Mar 18 22:10:04 jerusalem kernel: The Regents of the University of California. All rights reserved. > Mar 18 22:10:04 jerusalem kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. > Mar 18 22:10:04 jerusalem kernel: FreeBSD 8.0-CURRENT #0: Tue Mar 18 20:52:53 EDT 2008 > Mar 18 22:10:04 jerusalem kernel: huff@jerusalem.litteratus.org:/usr/obj/usr/src/sys/JERUSALEM > Mar 18 22:10:04 jerusalem kernel: WARNING: WITNESS option enabled, expect reduced performance. > Mar 18 22:10:04 jerusalem kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 > Mar 18 22:10:04 jerusalem kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz (2266.76-MHz 686-class CPU) > Mar 18 22:10:04 jerusalem kernel: Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 > Mar 18 22:10:04 jerusalem kernel: Features=0x3febfbff > Mar 18 22:10:04 jerusalem kernel: real memory = 536854528 (511 MB) > Mar 18 22:10:04 jerusalem kernel: avail memory = 516349952 (492 MB) > Mar 18 22:10:04 jerusalem kernel: acpi0: on motherboard > Mar 18 22:10:04 jerusalem kernel: acpi0: [ITHREAD] > Mar 18 22:10:04 jerusalem kernel: acpi0: Power Button (fixed) > Mar 18 22:10:04 jerusalem kernel: acpi0: reservation of 0, a0000 (3) failed > Mar 18 22:10:04 jerusalem kernel: acpi0: reservation of 100000, 1ff00000 (3) failed > Mar 18 22:10:04 jerusalem kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > Mar 18 22:10:04 jerusalem kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 > Mar 18 22:10:04 jerusalem kernel: pcib0: port 0xcf8-0xcff on acpi0 > Mar 18 22:10:04 jerusalem kernel: pci0: on pcib0 > Mar 18 22:10:04 jerusalem kernel: agp0: on hostb0 > Mar 18 22:10:04 jerusalem kernel: pcib1: at device 1.0 on pci0 > Mar 18 22:10:04 jerusalem kernel: pci1: on pcib1 > Mar 18 22:10:04 jerusalem kernel: vgapci0: mem 0xfc000000-0xfdffffff,0xf3800000-0xf3803fff,0xf3000000-0xf37fffff irq 11 at device 0.0 on pci1 > Mar 18 22:10:04 jerusalem kernel: drm0: on vgapci0 > Mar 18 22:10:04 jerusalem kernel: info: [drm] AGP at 0xf4000000 64MB > Mar 18 22:10:04 jerusalem kernel: info: [drm] Initialized mga 3.2.2 20060319 > Mar 18 22:10:04 jerusalem kernel: isab0: at device 2.0 on pci0 > Mar 18 22:10:04 jerusalem kernel: isa0: on isab0 > Mar 18 22:10:04 jerusalem kernel: ohci0: mem 0xf2800000-0xf2800fff irq 5 at device 2.2 on pci0 > Mar 18 22:10:04 jerusalem kernel: ohci0: [GIANT-LOCKED] > Mar 18 22:10:04 jerusalem kernel: ohci0: [ITHREAD] > Mar 18 22:10:04 jerusalem kernel: usb0: OHCI version 1.0, legacy support > Mar 18 22:10:04 jerusalem kernel: usb0: SMM does not respond, resetting > Mar 18 22:10:04 jerusalem kernel: usb0: on ohci0 > Mar 18 22:10:04 jerusalem kernel: usb0: USB revision 1.0 > Mar 18 22:10:04 jerusalem kernel: uhub0: on usb0 > Mar 18 22:10:04 jerusalem kernel: uhub0: 3 ports with 3 removable, self powered > Mar 18 22:10:04 jerusalem kernel: ohci1: mem 0xf2000000-0xf2000fff irq 9 at device 2.3 on pci0 > Mar 18 22:10:04 jerusalem kernel: ohci1: [GIANT-LOCKED] > Mar 18 22:10:04 jerusalem kernel: ohci1: [ITHREAD] > Mar 18 22:10:04 jerusalem kernel: usb1: OHCI version 1.0, legacy support > Mar 18 22:10:04 jerusalem kernel: usb1: SMM does not respond, resetting > Mar 18 22:10:04 jerusalem kernel: usb1: on ohci1 > Mar 18 22:10:04 jerusalem kernel: usb1: USB revision 1.0 > Mar 18 22:10:04 jerusalem kernel: uhub1: on usb1 > Mar 18 22:10:04 jerusalem kernel: uhub1: 3 ports with 3 removable, self powered > Mar 18 22:10:04 jerusalem kernel: pci0: at device 2.5 (no driver attached) > Mar 18 22:10:04 jerusalem kernel: pcm0: port 0xa800-0xa8ff irq 10 at device 5.0 on pci0 > Mar 18 22:10:04 jerusalem kernel: pcm0: [ITHREAD] > Mar 18 22:10:04 jerusalem kernel: ahc0: port 0xa400-0xa4ff mem 0xf1000000-0xf1000fff irq 11 at device 8.0 on pci0 > Mar 18 22:10:04 jerusalem kernel: ahc0: [ITHREAD] > Mar 18 22:10:04 jerusalem kernel: aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs > Mar 18 22:10:04 jerusalem kernel: ohci2: mem 0xf0800000-0xf0800fff irq 14 at device 10.0 on pci0 > Mar 18 22:10:04 jerusalem kernel: ohci2: [GIANT-LOCKED] > Mar 18 22:10:04 jerusalem kernel: ohci2: [ITHREAD] > Mar 18 22:10:04 jerusalem kernel: usb2: OHCI version 1.0, legacy support > Mar 18 22:10:04 jerusalem kernel: usb2: on ohci2 > Mar 18 22:10:04 jerusalem kernel: usb2: USB revision 1.0 > Mar 18 22:10:04 jerusalem kernel: uhub2: on usb2 > Mar 18 22:10:04 jerusalem kernel: uhub2: 2 ports with 2 removable, self powered > Mar 18 22:10:04 jerusalem kernel: ehci0: mem 0xf0000000-0xf00000ff irq 15 at device 10.3 on pci0 > Mar 18 22:10:04 jerusalem kernel: ehci0: [GIANT-LOCKED] > Mar 18 22:10:04 jerusalem kernel: ehci0: [ITHREAD] > Mar 18 22:10:04 jerusalem kernel: usb3: EHCI version 1.0 > Mar 18 22:10:04 jerusalem kernel: usb3: companion controller, 2 ports each: usb2 > Mar 18 22:10:04 jerusalem kernel: usb3: on ehci0 > Mar 18 22:10:04 jerusalem kernel: usb3: USB revision 2.0 > Mar 18 22:10:04 jerusalem kernel: uhub3: on usb3 > Mar 18 22:10:04 jerusalem kernel: uhub3: 6 ports with 6 removable, self powered > Mar 18 22:10:04 jerusalem kernel: umass0: on uhub3 > Mar 18 22:10:04 jerusalem kernel: em0: port 0xa000-0xa03f mem 0xef800000-0xef81ffff,0xef000000-0xef03ffff irq 11 at device 12.0 on pci0 > Mar 18 22:10:04 jerusalem kernel: em0: [FILTER] > Mar 18 22:10:04 jerusalem kernel: em0: Ethernet address: 00:0e:0c:a8:a7:e8 > Mar 18 22:10:04 jerusalem kernel: em1: port 0x9800-0x983f mem 0xee800000-0xee81ffff irq 10 at device 12.1 on pci0 > Mar 18 22:10:04 jerusalem kernel: em1: [FILTER] > Mar 18 22:10:04 jerusalem kernel: em1: Ethernet address: 00:0e:0c:a8:a7:e9 > Mar 18 22:10:04 jerusalem kernel: cpu0: on acpi0 > Mar 18 22:10:04 jerusalem kernel: acpi_throttle0: on cpu0 > Mar 18 22:10:04 jerusalem kernel: acpi_button0: on acpi0 > Mar 18 22:10:04 jerusalem kernel: fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > Mar 18 22:10:04 jerusalem kernel: fdc0: [FILTER] > Mar 18 22:10:04 jerusalem kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > Mar 18 22:10:04 jerusalem kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > Mar 18 22:10:04 jerusalem kernel: sio0: type 16550A > Mar 18 22:10:04 jerusalem kernel: sio0: [FILTER] > Mar 18 22:10:04 jerusalem kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > Mar 18 22:10:04 jerusalem kernel: sio1: type 16550A > Mar 18 22:10:04 jerusalem kernel: sio1: [FILTER] > Mar 18 22:10:04 jerusalem kernel: orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xcc000-0xd17ff,0xd4000-0xd4fff pnpid ORM0000 on isa0 > Mar 18 22:10:04 jerusalem kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 > Mar 18 22:10:04 jerusalem kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > Mar 18 22:10:04 jerusalem kernel: ppc0: FIFO with 16/16/16 bytes threshold > Mar 18 22:10:04 jerusalem kernel: ppbus0: on ppc0 > Mar 18 22:10:04 jerusalem kernel: ppbus0: [ITHREAD] > Mar 18 22:10:04 jerusalem kernel: lpt0: on ppbus0 > Mar 18 22:10:04 jerusalem kernel: lpt0: Interrupt-driven port > Mar 18 22:10:04 jerusalem kernel: ppi0: on ppbus0 > Mar 18 22:10:04 jerusalem kernel: ppc0: [GIANT-LOCKED] > Mar 18 22:10:04 jerusalem kernel: ppc0: [ITHREAD] > Mar 18 22:10:04 jerusalem kernel: sc0: at flags 0x100 on isa0 > Mar 18 22:10:04 jerusalem kernel: sc0: VGA <16 virtual consoles, flags=0x300> > Mar 18 22:10:04 jerusalem kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Mar 18 22:10:04 jerusalem kernel: uhub4: on uhub0 > Mar 18 22:10:04 jerusalem kernel: uhub4: 4 ports with 4 removable, bus powered > Mar 18 22:10:04 jerusalem kernel: ums0: on uhub4 > Mar 18 22:10:04 jerusalem kernel: ums0: 8 buttons and Z dir. > Mar 18 22:10:04 jerusalem kernel: ukbd0: on uhub4 > Mar 18 22:10:04 jerusalem kernel: kbd0 at ukbd0 > Mar 18 22:10:04 jerusalem kernel: ugen0: on uhub0 > Mar 18 22:10:04 jerusalem kernel: ugen1: on uhub2 > Mar 18 22:10:04 jerusalem kernel: Timecounter "TSC" frequency 2266762208 Hz quality 800 > Mar 18 22:10:04 jerusalem kernel: Timecounters tick every 1.000 msec > Mar 18 22:10:04 jerusalem kernel: ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based forwarding disabled, default to deny, logging limited to 100 packets/entry by default > Mar 18 22:10:04 jerusalem kernel: da0 at ahc0 bus 0 target 0 lun 0 > Mar 18 22:10:04 jerusalem kernel: da0: Fixed Direct Access SCSI-2 device > Mar 18 22:10:04 jerusalem kernel: da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit) > Mar 18 22:10:04 jerusalem kernel: da0: Command Queueing Enabled > Mar 18 22:10:04 jerusalem kernel: da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) > Mar 18 22:10:04 jerusalem kernel: da1 at ahc0 bus 0 target 1 lun 0 > Mar 18 22:10:04 jerusalem kernel: da1: Fixed Direct Access SCSI-2 device > Mar 18 22:10:04 jerusalem kernel: da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit) > Mar 18 22:10:04 jerusalem kernel: da1: Command Queueing Enabled > Mar 18 22:10:04 jerusalem kernel: da1: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) > Mar 18 22:10:04 jerusalem kernel: da2 at ahc0 bus 0 target 2 lun 0 > Mar 18 22:10:04 jerusalem kernel: da2: Fixed Direct Access SCSI-2 device > Mar 18 22:10:04 jerusalem kernel: da2: 10.000MB/s transfers (10.000MHz, offset 15) > Mar 18 22:10:04 jerusalem kernel: da2: Command Queueing Enabled > Mar 18 22:10:04 jerusalem kernel: da2: 47702MB (97693755 512 byte sectors: 255H 63S/T 6081C) > Mar 18 22:10:04 jerusalem kernel: da3 at umass-sim0 bus 0 target 0 lun 0 > Mar 18 22:10:04 jerusalem kernel: da3: Fixed Direct Access SCSI-0 device > Mar 18 22:10:04 jerusalem kernel: da3: 40.000MB/s transfers > Mar 18 22:10:04 jerusalem kernel: da3: 95611MB (195813072 512 byte sectors: 255H 63S/T 12188C) > Mar 18 22:10:04 jerusalem kernel: WARNING: WITNESS option enabled, expect reduced performance. > Mar 18 22:10:04 jerusalem kernel: cd0 at ahc0 bus 0 target 3 lun 0 > Mar 18 22:10:04 jerusalem kernel: cd0: Removable CD-ROM SCSI-2 device > Mar 18 22:10:04 jerusalem kernel: cd0: 3.300MB/s transfers > Mar 18 22:10:04 jerusalem kernel: cd0: cd present [331717 x 2048 byte records] > Mar 18 22:10:04 jerusalem kernel: lock order reversal: > Mar 18 22:10:04 jerusalem kernel: 1st 0xc2aa1e28 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2064 > Mar 18 22:10:04 jerusalem kernel: 2nd 0xc2b60194 devfsmount (devfsmount) @ /usr/src/sys/fs/devfs/devfs_vnops.c:201 > Mar 18 22:10:04 jerusalem kernel: KDB: stack backtrace: > Mar 18 22:10:04 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d3ac8bbc,c058c09d,c070e5f6,c2b60194,...) at db_trace_self_wrapper+0x26 > Mar 18 22:10:04 jerusalem kernel: kdb_backtrace(c070e5f6,c2b60194,c0700b2f,c0700b2f,c0700b70,...) at kdb_backtrace+0x29 > Mar 18 22:10:04 jerusalem kernel: witness_checkorder(c2b60194,9,c0700b70,c9,c7,...) at witness_checkorder+0x6af > Mar 18 22:10:04 jerusalem kernel: _sx_xlock(c2b60194,0,c0700b70,c9,c2b60194,...) at _sx_xlock+0x77 > Mar 18 22:10:04 jerusalem kernel: devfs_allocv(c2b62180,c2b64000,d3ac8c28,c28ea000,c0714353,...) at devfs_allocv+0x13e > Mar 18 22:10:04 jerusalem kernel: devfs_root(c2b64000,2,c07d7ad8,c28ea000,ca,...) at devfs_root+0x51 > Mar 18 22:10:04 jerusalem kernel: set_rootvnode(c07d7ac0,0,c0714353,5f4,c05c52da,...) at set_rootvnode+0x2b > Mar 18 22:10:04 jerusalem kernel: vfs_mountroot(c078c830,4,c07047a9,264,c058611f,...) at vfs_mountroot+0x334 > Mar 18 22:10:04 jerusalem kernel: start_init(0,d3ac8d38,c0706143,30c,c28e7000,...) at start_init+0x65 > Mar 18 22:10:04 jerusalem kernel: fork_exit(c0526dcd,0,d3ac8d38) at fork_exit+0xb8 > Mar 18 22:10:04 jerusalem kernel: fork_trampoline() at fork_trampoline+0x8 > Mar 18 22:10:04 jerusalem kernel: --- trap 0, eip = 0, esp = 0xd3ac8d70, ebp = 0 --- > Mar 18 22:10:04 jerusalem kernel: Trying to mount root from ufs:/dev/da0s1a > Mar 18 22:10:04 jerusalem kernel: lock order reversal: > Mar 18 22:10:04 jerusalem kernel: 1st 0xc2aa19e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2064 > Mar 18 22:10:04 jerusalem kernel: 2nd 0xc2b64000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 > Mar 18 22:10:04 jerusalem kernel: KDB: stack backtrace: > Mar 18 22:10:04 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d3ac89dc,c058c09d,c070e5f6,c2b64000,...) at db_trace_self_wrapper+0x26 > Mar 18 22:10:04 jerusalem kernel: kdb_backtrace(c070e5f6,c2b64000,c0714456,c0714456,c07149ee,...) at kdb_backtrace+0x29 > Mar 18 22:10:04 jerusalem kernel: witness_checkorder(c2b64000,1,c07149ee,16c,d3ac8a1c,...) at witness_checkorder+0x6af > Mar 18 22:10:04 jerusalem kernel: _lockmgr_args(c2b64000,20001,c2b64030,0,ffffffff,...) at _lockmgr_args+0x1c9 > Mar 18 22:10:04 jerusalem kernel: vfs_busy(c2b64000,0,0,c28ea000,d3ac8b58,...) at vfs_busy+0x19f > Mar 18 22:10:04 jerusalem kernel: lookup(d3ac8b44,c071411b,c6,bf,c28cdb2c,...) at lookup+0x735 > Mar 18 22:10:04 jerusalem kernel: namei(d3ac8b44,c2b64030,1c1,c0714353,d3ac8b54,...) at namei+0x25e > Mar 18 22:10:04 jerusalem kernel: kern_unlink(c28ea000,c0714790,1,62f,0,...) at kern_unlink+0x39 > Mar 18 22:10:04 jerusalem kernel: vfs_mountroot_try(c071494a,c070dfd0,c06fecf9,1,c05c52da,...) at vfs_mountroot_try+0x466 > Mar 18 22:10:04 jerusalem kernel: vfs_mountroot(c078c830,4,c07047a9,264,c058611f,...) at vfs_mountroot+0x3f2 > Mar 18 22:10:04 jerusalem kernel: start_init(0,d3ac8d38,c0706143,30c,c28e7000,...) at start_init+0x65 > Mar 18 22:10:04 jerusalem kernel: fork_exit(c0526dcd,0,d3ac8d38) at fork_exit+0xb8 > Mar 18 22:10:04 jerusalem kernel: fork_trampoline() at fork_trampoline+0x8 > Mar 18 22:10:04 jerusalem kernel: --- trap 0, eip = 0, esp = 0xd3ac8d70, ebp = 0 --- > Mar 18 22:10:04 jerusalem kernel: lock order reversal: > Mar 18 22:10:04 jerusalem kernel: 1st 0xc28ec044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3111 > Mar 18 22:10:04 jerusalem kernel: 2nd 0xc2aa17c8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2064 > Mar 18 22:10:04 jerusalem kernel: KDB: stack backtrace: > Mar 18 22:10:04 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d3ac89c0,c058c09d,c070e5f6,c2aa17c8,...) at db_trace_self_wrapper+0x26 > Mar 18 22:10:04 jerusalem kernel: kdb_backtrace(c070e5f6,c2aa17c8,c0703ec1,c0703ec1,c07149ee,...) at kdb_backtrace+0x29 > Mar 18 22:10:04 jerusalem kernel: witness_checkorder(c2aa17c8,1,c07149ee,810,d3ac89e4,...) at witness_checkorder+0x6af > Mar 18 22:10:04 jerusalem kernel: _lockmgr_args(c2aa17c8,30041,c2aa17f8,0,ffffffff,...) at _lockmgr_args+0x1c9 > Mar 18 22:10:04 jerusalem kernel: ffs_lock(d3ac8a74,c054b23c,c0791354,30041,c2aa1770,...) at ffs_lock+0xa1 > Mar 18 22:10:04 jerusalem kernel: VOP_LOCK1_APV(c0767d60,d3ac8a74,c070dfce,3,c2aa17f8,...) at VOP_LOCK1_APV+0xab > Mar 18 22:10:04 jerusalem kernel: _vn_lock(c2aa1770,30041,c07149ee,810,0,...) at _vn_lock+0xed > Mar 18 22:10:04 jerusalem kernel: vget(c2aa1770,30041,c28ea000,4a9,c1046780,...) at vget+0x101 > Mar 18 22:10:04 jerusalem kernel: vnode_pager_lock(c1046600,0,c0722bee,127,d3ac8be8,...) at vnode_pager_lock+0x1a5 > Mar 18 22:10:04 jerusalem kernel: vm_fault(c28ec000,80b4000,2,8,80b4000,...) at vm_fault+0x1dc > Mar 18 22:10:04 jerusalem kernel: trap_pfault(5,0,c072b9a2,2c4,c,...) at trap_pfault+0xf9 > Mar 18 22:10:04 jerusalem kernel: trap(d3ac8d38) at trap+0x230 > Mar 18 22:10:04 jerusalem kernel: calltrap() at calltrap+0x6 > Mar 18 22:10:04 jerusalem kernel: --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfef10, ebp = 0xbfbfef30 --- > Mar 18 22:10:05 jerusalem savecore: no dumps found > Mar 18 22:10:06 jerusalem kernel: lock order reversal: > Mar 18 22:10:06 jerusalem kernel: 1st 0xc2bfdaf8 isofs (isofs) @ /usr/src/sys/kern/vfs_subr.c:2064 > Mar 18 22:10:06 jerusalem kernel: 2nd 0xc2b63538 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 > Mar 18 22:10:06 jerusalem kernel: KDB: stack backtrace: > Mar 18 22:10:06 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d5f5ba18,c058c09d,c070e5f6,c2b63538,...) at db_trace_self_wrapper+0x26 > Mar 18 22:10:06 jerusalem kernel: kdb_backtrace(c070e5f6,c2b63538,c0714456,c0714456,c07149ee,...) at kdb_backtrace+0x29 > Mar 18 22:10:06 jerusalem kernel: witness_checkorder(c2b63538,1,c07149ee,16c,d5f5ba58,...) at witness_checkorder+0x6af > Mar 18 22:10:06 jerusalem kernel: _lockmgr_args(c2b63538,20001,c2b63568,0,ffffffff,...) at _lockmgr_args+0x1c9 > Mar 18 22:10:06 jerusalem kernel: vfs_busy(c2b63538,10,0,c2b9b220,0,...) at vfs_busy+0x19f > Mar 18 22:10:06 jerusalem kernel: vfs_donmount(810e080,c,d5f5bc74,c2dc3600,0,...) at vfs_donmount+0xdc8 > Mar 18 22:10:06 jerusalem kernel: nmount(c2b9b220,d5f5bcfc,c,c070f2c4,c0751e10,...) at nmount+0x8e > Mar 18 22:10:06 jerusalem kernel: syscall(d5f5bd38) at syscall+0x237 > Mar 18 22:10:06 jerusalem kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 > Mar 18 22:10:06 jerusalem kernel: --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480dafcf, esp = 0xbfbfe97c, ebp = 0xbfbfedd8 --- > Mar 18 22:10:06 jerusalem kernel: lock order reversal: > Mar 18 22:10:06 jerusalem kernel: 1st 0xc2bfd278 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_subr.c:2064 > Mar 18 22:10:06 jerusalem kernel: 2nd 0xc2b6329c vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 > Mar 18 22:10:06 jerusalem kernel: KDB: stack backtrace: > Mar 18 22:10:06 jerusalem kernel: db_trace_self_wrapper(c070c2d9,d5f5ba18,c058c09d,c070e5f6,c2b6329c,...) at db_trace_self_wrapper+0x26 > Mar 18 22:10:06 jerusalem kernel: kdb_backtrace(c070e5f6,c2b6329c,c0714456,c0714456,c07149ee,...) at kdb_backtrace+0x29 > Mar 18 22:10:06 jerusalem kernel: witness_checkorder(c2b6329c,1,c07149ee,16c,d5f5ba58,...) at witness_checkorder+0x6af > Mar 18 22:10:06 jerusalem kernel: _lockmgr_args(c2b6329c,20001,c2b632cc,0,ffffffff,...) at _lockmgr_args+0x1c9 > Mar 18 22:10:06 jerusalem kernel: vfs_busy(c2b6329c,10,0,c2b9b220,0,...) at vfs_busy+0x19f > Mar 18 22:10:06 jerusalem kernel: vfs_donmount(810e080,c,d5f5bc74,c2dc3680,0,...) at vfs_donmount+0xdc8 > Mar 18 22:10:06 jerusalem kernel: nmount(c2b9b220,d5f5bcfc,c,c070f2c4,c0751e10,...) at nmount+0x8e > Mar 18 22:10:06 jerusalem kernel: syscall(d5f5bd38) at syscall+0x237 > Mar 18 22:10:06 jerusalem kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 > Mar 18 22:10:06 jerusalem kernel: --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480dafcf, esp = 0xbfbfe97c, ebp = 0xbfbfedd8 --- > From owner-freebsd-current@FreeBSD.ORG Wed Mar 19 13:24:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 331BD106566B; Wed, 19 Mar 2008 13:24:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 232698FC23; Wed, 19 Mar 2008 13:24:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 2483C1A4D7C; Wed, 19 Mar 2008 06:23:34 -0700 (PDT) From: John Baldwin To: Sam Leffler Date: Wed, 19 Mar 2008 09:19:59 -0400 User-Agent: KMail/1.9.7 References: <47E02501.9050303@freebsd.org> In-Reply-To: <47E02501.9050303@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803190919.59783.jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Igor Mozolevsky Subject: Re: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Mar 2008 13:24:57 -0000 On Tuesday 18 March 2008 04:24:33 pm Sam Leffler wrote: > Igor Mozolevsky wrote: > > On 18/03/2008, John Baldwin wrote: > >> On Tuesday 18 March 2008 11:49:29 am Igor Mozolevsky wrote: > >> > On 18/03/2008, John Baldwin wrote: > >> > > First, which one is broken? Have you tried a RELENG_7_0 kernel and > >> > > does > >> > >> it do > >> > >> > > the same as a release CD kernel? > >> > > >> > Tried both ISO image and RELENG_7_0, they both work ok, but RELENG_7 > >> > >> doesn't... > >> > >> > >> Ok, and it is cpufreq related? Which cpufreq drivers are attaching to > >> your CPU? > > > > Well, I wouldn't say I'm sure it's 100% cpufreq related, but removing > > it from the kernel fixes the problem... It's also possible that > > cpufreq is interfering with something else... Anyhow, I've got both > > est and p4tcc attaching. > > I'm having lots of problems with cpu freq throttling on t4x laptops. > The system gets very sluggish and when I check the frequency it's been > throttled down. This happens even on ac (haven't checked what powerd is > doing then). My laptop actually wigs out if it throttles the CPU down too slow. What happens to me is that an ACPI GPE triggers and it takes a long time to execute at 100Mhz and I actually end up with a sort of GPE storm where the CPU spends all its time handling the GPE interrupts. :-/ I worked around it by using the 'debug.cpufreq.lowest' (or whatever it's called, it's something like that) tunable to prevent the CPU from going slower than about 400 Mhz and since then CPU throttling has worked fine on my laptop w/o issues. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Mar 19 13:24:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E101C106566C for ; Wed, 19 Mar 2008 13:24:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D23DE8FC1A for ; Wed, 19 Mar 2008 13:24:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id D93D61A4D86; Wed, 19 Mar 2008 06:23:34 -0700 (PDT) From: John Baldwin To: "Igor Mozolevsky" Date: Wed, 19 Mar 2008 09:20:28 -0400 User-Agent: KMail/1.9.7 References: <200803181324.51136.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803190920.28633.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Mar 2008 13:24:58 -0000 On Tuesday 18 March 2008 03:25:00 pm Igor Mozolevsky wrote: > On 18/03/2008, John Baldwin wrote: > > On Tuesday 18 March 2008 11:49:29 am Igor Mozolevsky wrote: > > > On 18/03/2008, John Baldwin wrote: > > > > First, which one is broken? Have you tried a RELENG_7_0 kernel and > > > > does > > > > it do > > > > > > the same as a release CD kernel? > > > > > > Tried both ISO image and RELENG_7_0, they both work ok, but RELENG_7 > > > > doesn't... > > > > > > Ok, and it is cpufreq related? Which cpufreq drivers are attaching to > > your CPU? > > Well, I wouldn't say I'm sure it's 100% cpufreq related, but removing > it from the kernel fixes the problem... It's also possible that > cpufreq is interfering with something else... Anyhow, I've got both > est and p4tcc attaching. Can you try disabling one or the other to see if it's limited to one driver? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Mar 19 16:49:27 2008 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 58473106566C; Wed, 19 Mar 2008 16:49:27 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE958FC13; Wed, 19 Mar 2008 16:49:26 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (vpn-cl-160-76.rz.uni-karlsruhe.de [141.3.160.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 7DCDC405BFF; Wed, 19 Mar 2008 17:49:25 +0100 (CET) Message-ID: <47E14414.9050105@bsdforen.de> Date: Wed, 19 Mar 2008 17:49:24 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.12 (X11/20080310) MIME-Version: 1.0 To: Andrew Thompson References: <20080306000919.GA11073@heff.fud.org.nz> In-Reply-To: <20080306000919.GA11073@heff.fud.org.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Intel 3945 (wpi) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 16:49:27 -0000 Andrew Thompson wrote: > Hi, > > > Here is a patch for wpi(4) which should help with the stability of the > driver. If you have been having problems then please give it a try and > report back. Some people have reported problems getting wpa_supplicant > to authenticate which may not be fixed, give it a try anyway. > > http://people.freebsd.org/~thompsa/wpi_head.diff > http://people.freebsd.org/~thompsa/wpi_releng7.diff > > This includes work by Sam Leffler and Benjamin Close. > > > cheers, > Andrew I am running the patched driver for two weeks and it appears to be very stable. The connection persists even with very bad signal quality. If the signal is interrupted only once in my university, I have to wait for half an hour before I'm allowed to reconnect into the VPN. This has not happened during the last couple of hours, even though the connection quality is 5:0 at the moment. Which is /very/, /very/ bad. From owner-freebsd-current@FreeBSD.ORG Wed Mar 19 19:38:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 721A4106566C; Wed, 19 Mar 2008 19:38:13 +0000 (UTC) (envelope-from SRS0=82bd9a9dc5ee18472562a69703b501f1b629bf1d=645=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 9E0158FC1E; Wed, 19 Mar 2008 19:38:12 +0000 (UTC) (envelope-from SRS0=82bd9a9dc5ee18472562a69703b501f1b629bf1d=645=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id ZWF67110; Wed, 19 Mar 2008 12:38:10 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BE81145019; Wed, 19 Mar 2008 12:38:10 -0700 (PDT) To: John Baldwin In-Reply-To: Your message of "Wed, 19 Mar 2008 09:19:59 EDT." <200803190919.59783.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1205955490_93241P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 19 Mar 2008 12:38:10 -0700 From: "Kevin Oberman" Message-Id: <20080319193810.BE81145019@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; X-Sender: X-To_Name: John Baldwin X-To_Domain: freebsd.org X-To: John Baldwin X-To_Email: jhb@freebsd.org X-To_Alias: jhb Cc: Sam Leffler , Igor Mozolevsky , freebsd-current@freebsd.org Subject: Re: Compiling 6.3->7: lapic frequency madness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Mar 2008 19:38:13 -0000 --==_Exmh_1205955490_93241P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > From: John Baldwin > Date: Wed, 19 Mar 2008 09:19:59 -0400 > Sender: owner-freebsd-current@freebsd.org > > On Tuesday 18 March 2008 04:24:33 pm Sam Leffler wrote: > > Igor Mozolevsky wrote: > > > On 18/03/2008, John Baldwin wrote: > > >> On Tuesday 18 March 2008 11:49:29 am Igor Mozolevsky wrote: > > >> > On 18/03/2008, John Baldwin wrote: > > >> > > First, which one is broken? Have you tried a RELENG_7_0 kernel and > > >> > > does > > >> > > >> it do > > >> > > >> > > the same as a release CD kernel? > > >> > > > >> > Tried both ISO image and RELENG_7_0, they both work ok, but RELENG_7 > > >> > > >> doesn't... > > >> > > >> > > >> Ok, and it is cpufreq related? Which cpufreq drivers are attaching to > > >> your CPU? > > > > > > Well, I wouldn't say I'm sure it's 100% cpufreq related, but removing > > > it from the kernel fixes the problem... It's also possible that > > > cpufreq is interfering with something else... Anyhow, I've got both > > > est and p4tcc attaching. > > > > I'm having lots of problems with cpu freq throttling on t4x laptops. > > The system gets very sluggish and when I check the frequency it's been > > throttled down. This happens even on ac (haven't checked what powerd is > > doing then). > > My laptop actually wigs out if it throttles the CPU down too slow. What > happens to me is that an ACPI GPE triggers and it takes a long time to > execute at 100Mhz and I actually end up with a sort of GPE storm where the > CPU spends all its time handling the GPE interrupts. :-/ I worked around it > by using the 'debug.cpufreq.lowest' (or whatever it's called, it's something > like that) tunable to prevent the CPU from going slower than about 400 Mhz > and since then CPU throttling has worked fine on my laptop w/o issues. I can run the CPU all the way down to 100 MHz without problems. I disable P4TCC in loader.conf. EST seems to handle low speeds just fine. I really don't see the advantage of manual setting of the TCC when EST is available. My loader.conf contains these items I consider T43 specific: hint.apic.0.disabled=1 hint.psm.0.flags="0x2000" hint.p4tcc.0.disabled="1" hw.ata.atapi.dma="1" hw.pci.do_power_nodriver="2" hw.psm.synaptics_support="1" acpi_ibm_load="YES" snd_ich_load="YES" -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1205955490_93241P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFH4Wuikn3rs5h7N1ERAmRPAJ0VuRz9ofXVv2eC2RWYNK7xAU2tjQCdFi0/ LAJ3+wBC5pEpnspaUmG8NB0= =1oFO -----END PGP SIGNATURE----- --==_Exmh_1205955490_93241P-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 03:09:36 2008 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 3DF051065672; Thu, 20 Mar 2008 03:09:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id CF2AF8FC20; Thu, 20 Mar 2008 03:09:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2K39YQl087515; Wed, 19 Mar 2008 23:09:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2K39YOa051813; Wed, 19 Mar 2008 23:09:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E7FD173039; Wed, 19 Mar 2008 22:09:33 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320030933.E7FD173039@freebsd-current.sentex.ca> Date: Wed, 19 Mar 2008 22:09:33 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 03:09:36 -0000 TB --- 2008-03-20 02:56:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 02:56:08 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-03-20 02:56:08 - cleaning the object tree TB --- 2008-03-20 02:56:35 - cvsupping the source tree TB --- 2008-03-20 02:56:35 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-03-20 02:56:41 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 02:56:41 - cd /src TB --- 2008-03-20 02:56:41 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 02:56:43 UTC 2008 >>> 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 [...] ===> lib/libbz2 (obj,depend,all,install) rm -f .depend mkdep -f .depend -a -I/src/lib/libbz2/../../contrib/bzip2 /src/lib/libbz2/../../contrib/bzip2/bzlib.c /src/lib/libbz2/../../contrib/bzip2/blocksort.c /src/lib/libbz2/../../contrib/bzip2/compress.c /src/lib/libbz2/../../contrib/bzip2/crctable.c /src/lib/libbz2/../../contrib/bzip2/decompress.c /src/lib/libbz2/../../contrib/bzip2/huffman.c /src/lib/libbz2/../../contrib/bzip2/randtable.c cc -O -pipe -I/src/lib/libbz2/../../contrib/bzip2 -c /src/lib/libbz2/../../contrib/bzip2/bzlib.c /src/lib/libbz2/../../contrib/bzip2/bzlib.c: In function 'unRLE_obuf_to_output_FAST': /src/lib/libbz2/../../contrib/bzip2/bzlib.c:647: error: 'ro_blockSize100k' undeclared (first use in this function) /src/lib/libbz2/../../contrib/bzip2/bzlib.c:647: error: (Each undeclared identifier is reported only once /src/lib/libbz2/../../contrib/bzip2/bzlib.c:647: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libbz2. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 03:09:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 03:09:33 - ERROR: failed to build world TB --- 2008-03-20 03:09:33 - tinderbox aborted TB --- 572.00 user 77.24 system 805.55 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 08:39:37 2008 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 41973106566B for ; Thu, 20 Mar 2008 08:39:37 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (unknown [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id B52C58FC13 for ; Thu, 20 Mar 2008 08:39:36 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180159152.adsl.alicedsl.de [85.180.159.152]) by acme.spoerlein.net (8.14.2/8.14.2) with ESMTP id m2K8dWOI039806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Mar 2008 09:39:33 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.2/8.14.2) with ESMTP id m2K8dTsg039594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Mar 2008 09:39:30 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.2/8.14.2/Submit) id m2K8dSlc039561; Thu, 20 Mar 2008 09:39:28 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Thu, 20 Mar 2008 09:39:28 +0100 From: Ulrich Spoerlein To: bzeeb+freebsd+lor@zabbadoz.net Message-ID: <20080320083928.GA14618@roadrunner.spoerlein.net> Mail-Followup-To: bzeeb+freebsd+lor@zabbadoz.net, current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org Subject: LORs: msdosfs and pseudofs vs vfslock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Mar 2008 08:39:37 -0000 Hi, I rebuild current yesterday and got this LOR upon boot: Starting mountd. lock order reversal: 1st 0xc21d0058 msdosfs (msdosfs) @ /vol/src/sys/kern/vfs_subr.c:2064 2nd 0xc21db5d0 vfslock (vfslock) @ /vol/src/sys/kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c07ae216,cf2a79cc,c057cb36,c07b0614,c21db5d0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07b0614,c21db5d0,c07b64d0,c07b64d0,c07b6a6d,...) at kdb_backtrace+0x29 witness_checkorder(c21db5d0,1,c07b6a6d,16c,c087d054,...) at witness_checkorder+0x6d6 _lockmgr_args(c21db5d0,20001,c21db64c,0,ffffffff,...) at _lockmgr_args+0x205 vfs_busy(c21db5d0,10,0,c207ecc0,8,...) at vfs_busy+0x1c4 vfs_donmount(810f080,c,cf2a7c70,c2176e00,810bc90,...) at vfs_donmount+0xdea nmount(c207ecc0,cf2a7cfc,c,c07b12cb,c07eded0,...) at nmount+0xb3 syscall(cf2a7d38) at syscall+0x2e3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280df127, esp = 0xbfbfe96c, ebp = 0xbfbfedb8 --- lock order reversal: 1st 0xc220bb38 pseudofs (pseudofs) @ /vol/src/sys/kern/vfs_subr.c:2064 2nd 0xc21db2e8 vfslock (vfslock) @ /vol/src/sys/kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c07ae216,cf2a79cc,c057cb36,c07b0614,c21db2e8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07b0614,c21db2e8,c07b64d0,c07b64d0,c07b6a6d,...) at kdb_backtrace+0x29 witness_checkorder(c21db2e8,1,c07b6a6d,16c,c087d0fc,...) at witness_checkorder+0x6d6 _lockmgr_args(c21db2e8,20001,c21db364,0,ffffffff,...) at _lockmgr_args+0x205 vfs_busy(c21db2e8,10,0,c207ecc0,8,...) at vfs_busy+0x1c4 vfs_donmount(810f080,c,cf2a7c70,c2176880,810be68,...) at vfs_donmount+0xdea nmount(c207ecc0,cf2a7cfc,c,c07b12cb,c07eded0,...) at nmount+0xb3 syscall(cf2a7d38) at syscall+0x2e3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280df127, esp = 0xbfbfe96c, ebp = 0xbfbfedb8 --- Starting nfsd. My /etc/exports only exports one UFS filesystem, but a FAT32 fs is mounted upon boot via /etc/fstab. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 13:54:18 2008 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 1F1A0106566C; Thu, 20 Mar 2008 13:54:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F05598FC29; Thu, 20 Mar 2008 13:54:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KDsHL5028917; Thu, 20 Mar 2008 09:54:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KDsGJi043055; Thu, 20 Mar 2008 09:54:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B982973039; Thu, 20 Mar 2008 08:54:16 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320135416.B982973039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 08:54:16 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean 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: Thu, 20 Mar 2008 13:54:18 -0000 TB --- 2008-03-20 12:39:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 12:39:23 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-03-20 12:39:23 - cleaning the object tree TB --- 2008-03-20 12:39:52 - cvsupping the source tree TB --- 2008-03-20 12:39:52 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-03-20 12:39:59 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 12:39:59 - cd /src TB --- 2008-03-20 12:39:59 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 12:40:00 UTC 2008 >>> 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 20 13:50:01 UTC 2008 TB --- 2008-03-20 13:50:01 - generating LINT kernel config TB --- 2008-03-20 13:50:01 - cd /src/sys/ia64/conf TB --- 2008-03-20 13:50:01 - /usr/bin/make -B LINT TB --- 2008-03-20 13:50:01 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 13:50:01 - cd /src TB --- 2008-03-20 13:50:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 13:50:01 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 13:54:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 13:54:16 - ERROR: failed to build lint kernel TB --- 2008-03-20 13:54:16 - tinderbox aborted TB --- 3381.65 user 360.41 system 4492.81 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 14:36:09 2008 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 F2D071065674; Thu, 20 Mar 2008 14:36:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id CFD668FC16; Thu, 20 Mar 2008 14:36:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KEa71v035504; Thu, 20 Mar 2008 10:36:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KEa7qi016488; Thu, 20 Mar 2008 10:36:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 729CF73039; Thu, 20 Mar 2008 09:36:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320143607.729CF73039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 09:36:07 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6305/Wed Mar 19 03:32:53 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 14:36:09 -0000 TB --- 2008-03-20 13:31:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 13:31:39 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-03-20 13:31:39 - cleaning the object tree TB --- 2008-03-20 13:32:04 - cvsupping the source tree TB --- 2008-03-20 13:32:04 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-03-20 13:32:10 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 13:32:10 - cd /src TB --- 2008-03-20 13:32:10 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 13:32:12 UTC 2008 >>> 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 20 14:32:59 UTC 2008 TB --- 2008-03-20 14:32:59 - generating LINT kernel config TB --- 2008-03-20 14:32:59 - cd /src/sys/powerpc/conf TB --- 2008-03-20 14:32:59 - /usr/bin/make -B LINT TB --- 2008-03-20 14:32:59 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 14:32:59 - cd /src TB --- 2008-03-20 14:32:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 14:32:59 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 14:36:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 14:36:07 - ERROR: failed to build lint kernel TB --- 2008-03-20 14:36:07 - tinderbox aborted TB --- 2932.77 user 346.66 system 3868.16 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 14:56:23 2008 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 385F1106566B; Thu, 20 Mar 2008 14:56:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 14D008FC17; Thu, 20 Mar 2008 14:56:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KEuMII039095; Thu, 20 Mar 2008 10:56:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KEuM0h073989; Thu, 20 Mar 2008 10:56:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2F57773039; Thu, 20 Mar 2008 09:56:22 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320145622.2F57773039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 09:56:22 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6305/Wed Mar 19 03:32:53 2008 clamav-milter version 0.92.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 14:56:23 -0000 TB --- 2008-03-20 13:54:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 13:54:16 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-03-20 13:54:16 - cleaning the object tree TB --- 2008-03-20 13:54:41 - cvsupping the source tree TB --- 2008-03-20 13:54:41 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-03-20 13:54:47 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 13:54:47 - cd /src TB --- 2008-03-20 13:54:47 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 13:54:48 UTC 2008 >>> 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 20 14:53:02 UTC 2008 TB --- 2008-03-20 14:53:02 - generating LINT kernel config TB --- 2008-03-20 14:53:02 - cd /src/sys/sparc64/conf TB --- 2008-03-20 14:53:02 - /usr/bin/make -B LINT TB --- 2008-03-20 14:53:02 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 14:53:02 - cd /src TB --- 2008-03-20 14:53:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 14:53:02 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 14:56:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 14:56:22 - ERROR: failed to build lint kernel TB --- 2008-03-20 14:56:22 - tinderbox aborted TB --- 2747.04 user 343.72 system 3725.30 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 15:32:36 2008 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 A2071106566B; Thu, 20 Mar 2008 15:32:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7FAB48FC1A; Thu, 20 Mar 2008 15:32:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KFWZ1P045833; Thu, 20 Mar 2008 11:32:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KFWZe0078809; Thu, 20 Mar 2008 11:32:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4214B73039; Thu, 20 Mar 2008 10:32:35 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320153235.4214B73039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 10:32:35 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 15:32:36 -0000 TB --- 2008-03-20 14:36:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 14:36:07 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-03-20 14:36:07 - cleaning the object tree TB --- 2008-03-20 14:36:30 - cvsupping the source tree TB --- 2008-03-20 14:36:30 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-03-20 14:36:38 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 14:36:38 - cd /src TB --- 2008-03-20 14:36:38 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 14:36:40 UTC 2008 >>> 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 20 15:29:56 UTC 2008 TB --- 2008-03-20 15:29:56 - generating LINT kernel config TB --- 2008-03-20 15:29:56 - cd /src/sys/sun4v/conf TB --- 2008-03-20 15:29:56 - /usr/bin/make -B LINT TB --- 2008-03-20 15:29:56 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 15:29:56 - cd /src TB --- 2008-03-20 15:29:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 15:29:56 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 15:32:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 15:32:35 - ERROR: failed to build lint kernel TB --- 2008-03-20 15:32:35 - tinderbox aborted TB --- 2744.70 user 337.55 system 3387.67 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 17:07:18 2008 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 7F5DF106566B; Thu, 20 Mar 2008 17:07:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 586D88FC1F; Thu, 20 Mar 2008 17:07:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KH7HN4063120; Thu, 20 Mar 2008 13:07:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KH7HSA042532; Thu, 20 Mar 2008 13:07:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 306D573039; Thu, 20 Mar 2008 12:07:17 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320170717.306D573039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 12:07:17 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6305/Wed Mar 19 03:32:53 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 17:07:18 -0000 TB --- 2008-03-20 15:35:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 15:35:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-03-20 15:35:01 - cleaning the object tree TB --- 2008-03-20 15:35:54 - cvsupping the source tree TB --- 2008-03-20 15:35:54 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-03-20 15:36:01 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 15:36:01 - cd /src TB --- 2008-03-20 15:36:01 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 15:36:03 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Mar 20 17:02:35 UTC 2008 TB --- 2008-03-20 17:02:35 - generating LINT kernel config TB --- 2008-03-20 17:02:35 - cd /src/sys/amd64/conf TB --- 2008-03-20 17:02:35 - /usr/bin/make -B LINT TB --- 2008-03-20 17:02:35 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 17:02:35 - cd /src TB --- 2008-03-20 17:02:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 17:02:35 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 17:07:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 17:07:17 - ERROR: failed to build lint kernel TB --- 2008-03-20 17:07:17 - tinderbox aborted TB --- 4099.67 user 520.65 system 5535.99 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 17:39:45 2008 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 F2F05106567B; Thu, 20 Mar 2008 17:39:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B13C88FC16; Thu, 20 Mar 2008 17:39:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KHdiBQ068530; Thu, 20 Mar 2008 13:39:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KHdhkx043452; Thu, 20 Mar 2008 13:39:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A615C73039; Thu, 20 Mar 2008 12:39:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320173943.A615C73039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 12:39:43 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6305/Wed Mar 19 03:32:53 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean 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: Thu, 20 Mar 2008 17:39:45 -0000 TB --- 2008-03-20 16:33:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 16:33:27 - starting HEAD tinderbox run for i386/i386 TB --- 2008-03-20 16:33:27 - cleaning the object tree TB --- 2008-03-20 16:33:59 - cvsupping the source tree TB --- 2008-03-20 16:33:59 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-03-20 16:34:05 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 16:34:05 - cd /src TB --- 2008-03-20 16:34:05 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 16:34:08 UTC 2008 >>> 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 20 17:34:50 UTC 2008 TB --- 2008-03-20 17:34:50 - generating LINT kernel config TB --- 2008-03-20 17:34:50 - cd /src/sys/i386/conf TB --- 2008-03-20 17:34:50 - /usr/bin/make -B LINT TB --- 2008-03-20 17:34:50 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 17:34:50 - cd /src TB --- 2008-03-20 17:34:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 17:34:50 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 17:39:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 17:39:43 - ERROR: failed to build lint kernel TB --- 2008-03-20 17:39:43 - tinderbox aborted TB --- 2979.02 user 365.84 system 3976.03 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 18:17:23 2008 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 53763106566C; Thu, 20 Mar 2008 18:17:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 29DE18FC13; Thu, 20 Mar 2008 18:17:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KIHMPb075119; Thu, 20 Mar 2008 14:17:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KIHMFf005863; Thu, 20 Mar 2008 14:17:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0A53A73039; Thu, 20 Mar 2008 13:17:21 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320181722.0A53A73039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 13:17:21 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 18:17:23 -0000 TB --- 2008-03-20 17:07:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 17:07:17 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-03-20 17:07:17 - cleaning the object tree TB --- 2008-03-20 17:07:43 - cvsupping the source tree TB --- 2008-03-20 17:07:43 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-03-20 17:07:49 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 17:07:49 - cd /src TB --- 2008-03-20 17:07:49 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 17:07:50 UTC 2008 >>> 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 20 18:08:23 UTC 2008 TB --- 2008-03-20 18:08:23 - generating LINT kernel config TB --- 2008-03-20 18:08:23 - cd /src/sys/pc98/conf TB --- 2008-03-20 18:08:23 - /usr/bin/make -B LINT TB --- 2008-03-20 18:08:23 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 18:08:23 - cd /src TB --- 2008-03-20 18:08:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 18:08:23 UTC 2008 >>> 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 atapist.ko ===> ata/ataraid (all) cc -O -pipe -DPC98 -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/ata/ataraid/../../../dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/modules/ata/ataraid/../../../dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/modules/ata/ataraid/../../../dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/modules/ata/ataraid/../../../dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/modules/ata/ataraid/../../../dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /src/sys/modules/ata/ataraid. *** Error code 1 Stop in /src/sys/modules/ata. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 18:17:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 18:17:21 - ERROR: failed to build lint kernel TB --- 2008-03-20 18:17:21 - tinderbox aborted TB --- 3153.55 user 387.96 system 4204.60 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 18:53:54 2008 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 54DAB106564A; Thu, 20 Mar 2008 18:53:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2863C8FC1B; Thu, 20 Mar 2008 18:53:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KIrr8G081712; Thu, 20 Mar 2008 14:53:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KIrqCa053278; Thu, 20 Mar 2008 14:53:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AB1F273039; Thu, 20 Mar 2008 13:53:52 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320185352.AB1F273039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 13:53:52 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean 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: Thu, 20 Mar 2008 18:53:54 -0000 TB --- 2008-03-20 17:39:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 17:39:43 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-03-20 17:39:43 - cleaning the object tree TB --- 2008-03-20 17:40:07 - cvsupping the source tree TB --- 2008-03-20 17:40:07 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-03-20 17:40:13 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 17:40:13 - cd /src TB --- 2008-03-20 17:40:13 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 17:40:14 UTC 2008 >>> 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 20 18:49:23 UTC 2008 TB --- 2008-03-20 18:49:23 - generating LINT kernel config TB --- 2008-03-20 18:49:23 - cd /src/sys/ia64/conf TB --- 2008-03-20 18:49:23 - /usr/bin/make -B LINT TB --- 2008-03-20 18:49:23 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 18:49:23 - cd /src TB --- 2008-03-20 18:49:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 18:49:23 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 18:53:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 18:53:52 - ERROR: failed to build lint kernel TB --- 2008-03-20 18:53:52 - tinderbox aborted TB --- 3380.80 user 364.45 system 4448.63 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 19:22:25 2008 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 087DD1065670; Thu, 20 Mar 2008 19:22:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B4CF38FC21; Thu, 20 Mar 2008 19:22:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KJMOEL086399; Thu, 20 Mar 2008 15:22:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KJMNQY095447; Thu, 20 Mar 2008 15:22:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B33CE73039; Thu, 20 Mar 2008 14:22:23 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320192223.B33CE73039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 14:22:23 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 19:22:25 -0000 TB --- 2008-03-20 18:17:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 18:17:22 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-03-20 18:17:22 - cleaning the object tree TB --- 2008-03-20 18:17:52 - cvsupping the source tree TB --- 2008-03-20 18:17:52 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-03-20 18:17:58 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 18:17:58 - cd /src TB --- 2008-03-20 18:17:58 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 18:18:00 UTC 2008 >>> 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 20 19:19:16 UTC 2008 TB --- 2008-03-20 19:19:16 - generating LINT kernel config TB --- 2008-03-20 19:19:16 - cd /src/sys/powerpc/conf TB --- 2008-03-20 19:19:16 - /usr/bin/make -B LINT TB --- 2008-03-20 19:19:16 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 19:19:16 - cd /src TB --- 2008-03-20 19:19:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 19:19:16 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 19:22:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 19:22:23 - ERROR: failed to build lint kernel TB --- 2008-03-20 19:22:23 - tinderbox aborted TB --- 2931.70 user 344.62 system 3901.43 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 19:56:00 2008 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 E8F12106564A; Thu, 20 Mar 2008 19:56:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B972F8FC12; Thu, 20 Mar 2008 19:56:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KJu0L9092554; Thu, 20 Mar 2008 15:56:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KJu0uZ031268; Thu, 20 Mar 2008 15:56:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E2EA073039; Thu, 20 Mar 2008 14:55:59 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320195559.E2EA073039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 14:55:59 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6305/Wed Mar 19 03:32:53 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 19:56:01 -0000 TB --- 2008-03-20 18:53:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 18:53:52 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-03-20 18:53:52 - cleaning the object tree TB --- 2008-03-20 18:54:11 - cvsupping the source tree TB --- 2008-03-20 18:54:11 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-03-20 18:54:18 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 18:54:18 - cd /src TB --- 2008-03-20 18:54:18 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 18:54:20 UTC 2008 >>> 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 20 19:52:33 UTC 2008 TB --- 2008-03-20 19:52:33 - generating LINT kernel config TB --- 2008-03-20 19:52:33 - cd /src/sys/sparc64/conf TB --- 2008-03-20 19:52:33 - /usr/bin/make -B LINT TB --- 2008-03-20 19:52:33 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 19:52:33 - cd /src TB --- 2008-03-20 19:52:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 19:52:33 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 19:55:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 19:55:59 - ERROR: failed to build lint kernel TB --- 2008-03-20 19:55:59 - tinderbox aborted TB --- 2747.55 user 342.27 system 3727.08 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 20:20:51 2008 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 63F2A1065678; Thu, 20 Mar 2008 20:20:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 340218FC21; Thu, 20 Mar 2008 20:20:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KKKo2G096414; Thu, 20 Mar 2008 16:20:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KKKomC098243; Thu, 20 Mar 2008 16:20:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 246D873039; Thu, 20 Mar 2008 15:20:50 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320202050.246D873039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 15:20:50 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6305/Wed Mar 19 03:32:53 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 20:20:51 -0000 TB --- 2008-03-20 19:22:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 19:22:23 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-03-20 19:22:23 - cleaning the object tree TB --- 2008-03-20 19:22:51 - cvsupping the source tree TB --- 2008-03-20 19:22:51 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-03-20 19:22:57 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 19:22:57 - cd /src TB --- 2008-03-20 19:22:57 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 19:22:58 UTC 2008 >>> 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 20 20:18:11 UTC 2008 TB --- 2008-03-20 20:18:11 - generating LINT kernel config TB --- 2008-03-20 20:18:11 - cd /src/sys/sun4v/conf TB --- 2008-03-20 20:18:11 - /usr/bin/make -B LINT TB --- 2008-03-20 20:18:11 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 20:18:11 - cd /src TB --- 2008-03-20 20:18:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 20:18:11 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 20:20:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 20:20:50 - ERROR: failed to build lint kernel TB --- 2008-03-20 20:20:50 - tinderbox aborted TB --- 2747.97 user 336.98 system 3506.17 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 20:32:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D3161065670 for ; Thu, 20 Mar 2008 20:32:30 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD278FC19 for ; Thu, 20 Mar 2008 20:32:29 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 9A0EF3F85D1; Thu, 20 Mar 2008 21:20:36 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id AB0CE3F64C8; Thu, 20 Mar 2008 20:51:18 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 3790F9BF12; Thu, 20 Mar 2008 19:50:12 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 1FA93405D; Thu, 20 Mar 2008 20:50:12 +0100 (CET) Date: Thu, 20 Mar 2008 20:50:12 +0100 From: Jeremie Le Hen To: Unga Message-ID: <20080320195012.GA66530@obiwan.tataz.chchile.org> References: <945136.92642.qm@web57010.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <945136.92642.qm@web57010.mail.re3.yahoo.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-chat@freebsd.org Subject: Re: The Design and Implementation of the FreeBSD Operating System X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 20:32:30 -0000 Hi, On Fri, Mar 14, 2008 at 07:41:30AM -0700, Unga wrote: > Is the following book still relevant to FreeBSD 7.X > and upcoming FreeBSD 8.X? Is there a 2nd edition > coming soon? > > The Design and Implementation of the FreeBSD Operating > System > By Marshall Kirk McKusick, George V. Neville-Neil > Published Aug 2, 2004 by Addison Wesley Professional. > 1st. Edition > ISBN-10: 0-201-70245-2 > http://www.informit.com/title/0201702452 FWIW there has been rumours about the next edition of this book covering a recenter version. That's all I know :). Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 21:57:05 2008 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 4172A1065670; Thu, 20 Mar 2008 21:57:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id EABA38FC35; Thu, 20 Mar 2008 21:57:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KLv4k1006015; Thu, 20 Mar 2008 17:57:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KLv3DW056970; Thu, 20 Mar 2008 17:57:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AA97E73039; Thu, 20 Mar 2008 16:57:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320215703.AA97E73039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 16:57:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6305/Wed Mar 19 03:32:53 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 21:57:05 -0000 TB --- 2008-03-20 20:25:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 20:25:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-03-20 20:25:00 - cleaning the object tree TB --- 2008-03-20 20:25:44 - cvsupping the source tree TB --- 2008-03-20 20:25:44 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-03-20 20:25:49 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 20:25:49 - cd /src TB --- 2008-03-20 20:25:49 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 20:25:51 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Mar 20 21:52:20 UTC 2008 TB --- 2008-03-20 21:52:20 - generating LINT kernel config TB --- 2008-03-20 21:52:20 - cd /src/sys/amd64/conf TB --- 2008-03-20 21:52:20 - /usr/bin/make -B LINT TB --- 2008-03-20 21:52:20 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 21:52:20 - cd /src TB --- 2008-03-20 21:52:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 21:52:20 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 21:57:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 21:57:03 - ERROR: failed to build lint kernel TB --- 2008-03-20 21:57:03 - tinderbox aborted TB --- 4100.85 user 517.06 system 5522.76 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 22:30:09 2008 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 0D2EE1065670; Thu, 20 Mar 2008 22:30:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id CFA2C8FC1B; Thu, 20 Mar 2008 22:30:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KMU8mK089684; Thu, 20 Mar 2008 18:30:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2KMU7Y2002396; Thu, 20 Mar 2008 18:30:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A4A7E73039; Thu, 20 Mar 2008 17:30:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080320223007.A4A7E73039@freebsd-current.sentex.ca> Date: Thu, 20 Mar 2008 17:30:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean 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: Thu, 20 Mar 2008 22:30:09 -0000 TB --- 2008-03-20 21:23:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-20 21:23:26 - starting HEAD tinderbox run for i386/i386 TB --- 2008-03-20 21:23:26 - cleaning the object tree TB --- 2008-03-20 21:23:50 - cvsupping the source tree TB --- 2008-03-20 21:23:50 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-03-20 21:23:56 - building world (CFLAGS=-O -pipe) TB --- 2008-03-20 21:23:56 - cd /src TB --- 2008-03-20 21:23:56 - /usr/bin/make -B buildworld >>> World build started on Thu Mar 20 21:23:58 UTC 2008 >>> 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 20 22:25:03 UTC 2008 TB --- 2008-03-20 22:25:03 - generating LINT kernel config TB --- 2008-03-20 22:25:03 - cd /src/sys/i386/conf TB --- 2008-03-20 22:25:03 - /usr/bin/make -B LINT TB --- 2008-03-20 22:25:03 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-20 22:25:03 - cd /src TB --- 2008-03-20 22:25:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Mar 20 22:25:03 UTC 2008 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-pci.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-queue.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /src/sys/dev/ata/ata-raid.c: In function 'ata_raid_attach': /src/sys/dev/ata/ata-raid.c:202: warning: implicit declaration of function 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:202: warning: nested extern declaration of 'ata_unit2str' /src/sys/dev/ata/ata-raid.c:203: warning: format '%s' expects type 'char *', but argument 4 has type 'int' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-20 22:30:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-20 22:30:07 - ERROR: failed to build lint kernel TB --- 2008-03-20 22:30:07 - tinderbox aborted TB --- 2979.04 user 363.44 system 4000.20 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Mar 20 23:08:23 2008 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 55E3A1065671 for ; Thu, 20 Mar 2008 23:08:23 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id C5C108FC1F for ; Thu, 20 Mar 2008 23:08:22 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 95091471 for current@freebsd.org; Fri, 21 Mar 2008 00:08:20 +0200 Message-ID: <47E2E050.4010705@FreeBSD.org> Date: Fri, 21 Mar 2008 00:08:16 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: HEAD crashed at ioctl() / in_control() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Mar 2008 23:08:23 -0000 Hi. While doing active user connect/disconnect mpd stress testing my system with HEAD of first days of march crashed with such symptoms: #11 0xc0a4421b in calltrap () at /usr/src/sys/i386/i386/exception.s:146 #12 0xc083b36d in in_control (so=0xc33bca9c, cmd=2149607705, data=0xc45a7aa0 "ng408", ifp=0xc458e000, td=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/sys/netinet/in.c:494 #13 0xc07ffe83 in ifioctl (so=0xc33bca9c, cmd=2149607705, data=0xc45a7aa0 "ng408", td=0xc33ba220) at /usr/src/sys/net/if.c:1888 #14 0xc07a9e24 in soo_ioctl (fp=0xc2fab444, cmd=2149607705, data=0xc45a7aa0, active_cred=0xc2cf5500, td=0xc33ba220) at /usr/src/sys/kern/sys_socket.c:200 #15 0xc07a40a8 in kern_ioctl (td=0xc33ba220, fd=3, com=2149607705, data=0xc45a7aa0 "ng408") at file.h:254 #16 0xc07a4214 in ioctl (td=0xc33ba220, uap=0xd62cdcfc) at /usr/src/sys/kern/sys_generic.c:677 #17 0xc0a5dfb3 in syscall (frame=0xd62cdd38) at /usr/src/sys/i386/i386/trap.c:1034 #18 0xc0a44280 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:203 #19 0x00000033 in ?? () (kgdb) frame 12 #12 0xc083b36d in in_control (so=0xc33bca9c, cmd=2149607705, data=0xc45a7aa0 "ng408", ifp=0xc458e000, td=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/sys/netinet/in.c:494 494 TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); (kgdb) l 489 /* 490 * Protect from ipintr() traversing address list while we're modifying 491 * it. 492 */ 493 s = splnet(); 494 TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); 495 TAILQ_REMOVE(&in_ifaddrhead, ia, ia_link); 496 if (ia->ia_addr.sin_family == AF_INET) { 497 LIST_REMOVE(ia, ia_hash); 498 /* (kgdb) p ifp->if_addrhead $1 = {tqh_first = 0xdeadc0de, tqh_last = 0xdeadc0de} (kgdb) p ifp $2 = (struct ifnet *) 0xc458e000 This test assumes active, possibly concurrent interface creation/destruction and address adding/deleting. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 02:57:57 2008 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 55122106566C for ; Fri, 21 Mar 2008 02:57:57 +0000 (UTC) (envelope-from randy@psg.com) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by mx1.freebsd.org (Postfix) with ESMTP id 346688FC1B for ; Fri, 21 Mar 2008 02:57:57 +0000 (UTC) (envelope-from randy@psg.com) Received: from [202.214.86.185] (helo=rmac.psg.com) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JcXS7-0002LS-FD for current@freebsd.org; Fri, 21 Mar 2008 02:57:56 +0000 Message-ID: <47E32432.8060309@psg.com> Date: Fri, 21 Mar 2008 11:57:54 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -102.4 (---------------------------------------------------) Cc: Subject: installworld - touch: not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 02:57:57 -0000 i have memories of this in the past. but, like most of my memory, it got more holes than the current adminstration's excuses. today's current i386 soekris ===> gnu/usr.bin/texinfo/doc (install) install-info --quiet --defsection=Miscellaneous --defentry= info.info /usr/sh are/info/dir install-info --quiet --defsection=Miscellaneous --defentry= info-stnd.info /u sr/share/info/dir install-info --quiet --defsection=Miscellaneous --defentry= texinfo.info /usr/share/info/dir install -o root -g wheel -m 444 info.info.gz info-stnd.info.gz texinfo.info.gz /usr/share/info ===> include (install) creating osreldate.h from newvers.sh touch: not found *** Error code 127 i blew away /usr/obj and did a full rebuild. did a fresh cvsup. about to use chicken entrails, but wife objects to smell. randy From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 03:03:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 060B7106564A for ; Fri, 21 Mar 2008 03:03:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id D775A8FC20 for ; Fri, 21 Mar 2008 03:03:53 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.2/8.14.2) with ESMTP id m2L32tVl098604 for ; Thu, 20 Mar 2008 20:02:55 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.2/8.14.2/Submit) id m2L32sCW098603 for freebsd-current@freebsd.org; Thu, 20 Mar 2008 20:02:54 -0700 (PDT) (envelope-from sgk) Date: Thu, 20 Mar 2008 20:02:54 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20080321030254.GA98444@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Extremely slooooow __sys_ftruncate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 03:03:54 -0000 In the process of helping to debug a problem with gcc-4.4.0 (actually a gfortran problem), I run gprof on the executable. The profile shows that __sys_ftruncate is extremely slow. % cumulative self self total time seconds seconds calls ms/call ms/call name 85.6 6.05 6.05 51830 0.12 0.12 __sys_ftruncate [2] 5.6 6.44 0.40 0 100.00% .mcount (101) 1.7 6.56 0.12 51872 0.00 0.00 _lseek [5] 1.6 6.67 0.11 52055 0.00 0.00 sigprocmask [6] 0.8 6.73 0.06 103687 0.00 0.00 memset [14] 0.4 6.76 0.03 488 0.06 0.06 __sys_write [18] 0.4 6.79 0.03 0 100.00% formatted_transfer_scalar time ./z 184.21 real 0.98 user 6.57 sys This program should finish well under 184 seconds. The same program and exact same gcc/gfortran source on linux shows real 0m0.555s user 0m0.103s sys 0m0.452s Is __sys_ftruncate known to have performance problems? -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 03:19:28 2008 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 A9B061065670 for ; Fri, 21 Mar 2008 03:19:28 +0000 (UTC) (envelope-from scottro@nyc.rr.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE2E8FC1A for ; Fri, 21 Mar 2008 03:19:28 +0000 (UTC) (envelope-from scottro@nyc.rr.com) Received: from localhost ([69.203.87.53]) by hrndva-omta05.mail.rr.com with ESMTP id <20080321030424.OYZQ7571.hrndva-omta05.mail.rr.com@localhost> for ; Fri, 21 Mar 2008 03:04:24 +0000 Date: Thu, 20 Mar 2008 23:04:24 -0400 From: Scott Robbins To: current@freebsd.org Message-ID: <20080321030424.GA77047@mail.scottro.net> Mail-Followup-To: current@freebsd.org References: <47E32432.8060309@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <47E32432.8060309@psg.com> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Subject: Re: installworld - touch: not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 03:19:28 -0000 On Fri, Mar 21, 2008 at 11:57:54AM +0900, Randy Bush wrote: > i have memories of this in the past. but, like most of my memory, it > got more holes than the current adminstration's excuses. > To make you feel worse, it's actually in the FAQ. :) http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#TOUCH-NOT-FOUND (Today, a friend told me that if I worked on a suicide hotline, I'd program Van Halen's "Go Ahead and Jump" as the hold music.) Encouragingly yours, -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Xander: The band, yeah. They're great. They march. Willow: Like an army. Except with music, instead of bullets, and usually no one dies. From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 03:46:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1339106566C for ; Fri, 21 Mar 2008 03:46:15 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 71E928FC15 for ; Fri, 21 Mar 2008 03:46:15 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.2/8.14.2) with ESMTP id m2L3jG1x098837 for ; Thu, 20 Mar 2008 20:45:16 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.2/8.14.2/Submit) id m2L3jGps098836 for freebsd-current@freebsd.org; Thu, 20 Mar 2008 20:45:16 -0700 (PDT) (envelope-from sgk) Date: Thu, 20 Mar 2008 20:45:16 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20080321034516.GA98780@troutmask.apl.washington.edu> References: <20080321030254.GA98444@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080321030254.GA98444@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Subject: Re: Extremely slooooow __sys_ftruncate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 03:46:15 -0000 On Thu, Mar 20, 2008 at 08:02:54PM -0700, Steve Kargl wrote: > In the process of helping to debug a problem with gcc-4.4.0 > (actually a gfortran problem), I run gprof on the executable. > The profile shows that __sys_ftruncate is extremely slow. > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 85.6 6.05 6.05 51830 0.12 0.12 __sys_ftruncate [2] > 5.6 6.44 0.40 0 100.00% .mcount (101) > 1.7 6.56 0.12 51872 0.00 0.00 _lseek [5] > 1.6 6.67 0.11 52055 0.00 0.00 sigprocmask [6] > 0.8 6.73 0.06 103687 0.00 0.00 memset [14] > 0.4 6.76 0.03 488 0.06 0.06 __sys_write [18] > 0.4 6.79 0.03 0 100.00% formatted_transfer_scalar > > time ./z > 184.21 real 0.98 user 6.57 sys > > This program should finish well under 184 seconds. The same program > and exact same gcc/gfortran source on linux shows > real 0m0.555s user 0m0.103s sys 0m0.452s > > Is __sys_ftruncate known to have performance problems? > Well, I tried to kludge together a C example based on the the Fortran test code and gfortran runtime library. cc -o z -O -pg -static a.c time ./z 239.96 real 0.08 user 8.12 sys % cumulative self self total time seconds seconds calls ms/call ms/call name 81.4 6.58 6.58 51830 0.13 0.13 _ftruncate [3] 17.1 7.96 1.38 52056 0.03 0.03 _write [4] 0.7 8.01 0.05 0 100.00% .mcount (46) 0.6 8.05 0.05 51830 0.00 0.00 __sys_lseek [5] 0.1 8.06 0.01 1 7.51 7.51 fstat [9] 0.1 8.07 0.01 1 7.51 8027.03 main [1] 0.1 8.07 0.00 51830 0.00 0.00 lseek [13] Hmmm, ftruncate() mapped to _ftruncate :-/ Here's the program #include #include #include #include int main(void) { int fd, off, i, j; fd = open("junk", O_RDWR | O_CREAT, S_IRUSR | S_IWUSR); off = 0; for (i = 0; i < 5183; i++) { if (i%23 == 0) printf("i = %d\n", i); for (j = 0; j < 10; j++) { write(fd, &off, sizeof(off)); off++; lseek(fd, off, SEEK_SET); ftruncate(fd, off); } } return 0; } -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 03:48:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ED4B1065675 for ; Fri, 21 Mar 2008 03:48:19 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id D45838FC14 for ; Fri, 21 Mar 2008 03:48:18 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1350872waf.3 for ; Thu, 20 Mar 2008 20:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fa5EUjdsiV+b9a/Nraq2qc5LlKVijigc8HxqgpRmXSY=; b=tl8yYOQFH+mPcLzAMWGkonyIGNSNQo6CHukIYlpEooVqI0hRkFP+DHyXNes8faeCiWeJkvXzD1frf0NWdSo2jF143iEhPiuY8vZYPpLAGjP66WMBolCIq3HKKM2I7kXr3rrlgBjBLuhyVJSWg8WfwtCWiyiWiacjXEoXMCl6xPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GbVGjKh1e4BRh0wv8CCQVp+tVsXWGYcAHlQCbaBqqPNYPiQDfo22aMhqv1ORC5CuPLTiNnjvPzhEN5kWWD2FJQs/t445YcpRMp8Cqy1E9NYfkSScamcn7LMmnnhGCBgJYt589chtlUFGRfDZA1Ij1PrJNxkieCWLHC6qRSv+2Dg= Received: by 10.114.193.1 with SMTP id q1mr4791006waf.75.1206071298081; Thu, 20 Mar 2008 20:48:18 -0700 (PDT) Received: by 10.115.22.10 with HTTP; Thu, 20 Mar 2008 20:48:17 -0700 (PDT) Message-ID: Date: Thu, 20 Mar 2008 20:48:17 -0700 From: "Kip Macy" To: "Steve Kargl" In-Reply-To: <20080321030254.GA98444@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080321030254.GA98444@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: Extremely slooooow __sys_ftruncate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 03:48:19 -0000 "truncate" may be synchronous on FreeBSD - almost nothing is on Linux. -Kip On Thu, Mar 20, 2008 at 8:02 PM, Steve Kargl wrote: > In the process of helping to debug a problem with gcc-4.4.0 > (actually a gfortran problem), I run gprof on the executable. > The profile shows that __sys_ftruncate is extremely slow. > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 85.6 6.05 6.05 51830 0.12 0.12 __sys_ftruncate [2] > 5.6 6.44 0.40 0 100.00% .mcount (101) > 1.7 6.56 0.12 51872 0.00 0.00 _lseek [5] > 1.6 6.67 0.11 52055 0.00 0.00 sigprocmask [6] > 0.8 6.73 0.06 103687 0.00 0.00 memset [14] > 0.4 6.76 0.03 488 0.06 0.06 __sys_write [18] > 0.4 6.79 0.03 0 100.00% formatted_transfer_scalar > > time ./z > 184.21 real 0.98 user 6.57 sys > > This program should finish well under 184 seconds. The same program > and exact same gcc/gfortran source on linux shows > real 0m0.555s user 0m0.103s sys 0m0.452s > > Is __sys_ftruncate known to have performance problems? > > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 04:59:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E9EF1065671 for ; Fri, 21 Mar 2008 04:59:38 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id C80B48FC13 for ; Fri, 21 Mar 2008 04:59:37 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m2L4xZwe025319; Fri, 21 Mar 2008 00:59:36 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Thu, 20 Mar 2008 19:00:37 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Steve Kargl In-Reply-To: <20080321034516.GA98780@troutmask.apl.washington.edu> Message-ID: <20080320185743.L910@desktop> References: <20080321030254.GA98444@troutmask.apl.washington.edu> <20080321034516.GA98780@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Extremely slooooow __sys_ftruncate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 04:59:38 -0000 On Thu, 20 Mar 2008, Steve Kargl wrote: > On Thu, Mar 20, 2008 at 08:02:54PM -0700, Steve Kargl wrote: >> In the process of helping to debug a problem with gcc-4.4.0 >> (actually a gfortran problem), I run gprof on the executable. >> The profile shows that __sys_ftruncate is extremely slow. >> >> % cumulative self self total >> time seconds seconds calls ms/call ms/call name >> 85.6 6.05 6.05 51830 0.12 0.12 __sys_ftruncate [2] >> 5.6 6.44 0.40 0 100.00% .mcount (101) >> 1.7 6.56 0.12 51872 0.00 0.00 _lseek [5] >> 1.6 6.67 0.11 52055 0.00 0.00 sigprocmask [6] >> 0.8 6.73 0.06 103687 0.00 0.00 memset [14] >> 0.4 6.76 0.03 488 0.06 0.06 __sys_write [18] >> 0.4 6.79 0.03 0 100.00% formatted_transfer_scalar >> >> time ./z >> 184.21 real 0.98 user 6.57 sys >> >> This program should finish well under 184 seconds. The same program >> and exact same gcc/gfortran source on linux shows >> real 0m0.555s user 0m0.103s sys 0m0.452s >> >> Is __sys_ftruncate known to have performance problems? >> > > Well, I tried to kludge together a C example based on the > the Fortran test code and gfortran runtime library. Thanks for the test code. truncate is only handled by softupdates when it's a truncate to 0. Otherwise it's synchronous. :/ I would argue that the program is doing something terrible. However, we also shouldn't be so slow. I'm confused by your example however. For each iteration we're writing 4 bytes and then truncating 3 of them off? Is that right? Is that what the compiler is actually doing? Thanks, Jeff > > cc -o z -O -pg -static a.c > time ./z > 239.96 real 0.08 user 8.12 sys > > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 81.4 6.58 6.58 51830 0.13 0.13 _ftruncate [3] > 17.1 7.96 1.38 52056 0.03 0.03 _write [4] > 0.7 8.01 0.05 0 100.00% .mcount (46) > 0.6 8.05 0.05 51830 0.00 0.00 __sys_lseek [5] > 0.1 8.06 0.01 1 7.51 7.51 fstat [9] > 0.1 8.07 0.01 1 7.51 8027.03 main [1] > 0.1 8.07 0.00 51830 0.00 0.00 lseek [13] > > Hmmm, ftruncate() mapped to _ftruncate :-/ > > Here's the program > > #include > #include > #include > #include > > > int > main(void) { > > int fd, off, i, j; > > fd = open("junk", O_RDWR | O_CREAT, S_IRUSR | S_IWUSR); > off = 0; > for (i = 0; i < 5183; i++) { > if (i%23 == 0) printf("i = %d\n", i); > for (j = 0; j < 10; j++) { > write(fd, &off, sizeof(off)); > off++; > lseek(fd, off, SEEK_SET); > ftruncate(fd, off); > } > } > return 0; > } > > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 05:06:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35CF4106566C for ; Fri, 21 Mar 2008 05:06:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id C3B308FC22 for ; Fri, 21 Mar 2008 05:06:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JcZSm-000L1e-05 for freebsd-current@freebsd.org; Fri, 21 Mar 2008 07:06:48 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m2L56gfR014601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 07:06:42 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m2L56TUu096259; Fri, 21 Mar 2008 07:06:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m2L56TRE096258; Fri, 21 Mar 2008 07:06:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Mar 2008 07:06:29 +0200 From: Kostik Belousov To: Kip Macy Message-ID: <20080321050629.GS10374@deviant.kiev.zoral.com.ua> References: <20080321030254.GA98444@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XhDIt1ZqED2V8RHq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 362d5034abbfed611c52a2913ea5ff69 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2450 [Mar 20 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: Extremely slooooow __sys_ftruncate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 05:06:50 -0000 --XhDIt1ZqED2V8RHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 20, 2008 at 08:48:17PM -0700, Kip Macy wrote: > "truncate" may be synchronous on FreeBSD - almost nothing is on Linux. Partial truncate is synchronous for UFS mounts. Full truncate (to 0 lenght) also may become synchronous under high i/o pressure. >=20 > -Kip >=20 > On Thu, Mar 20, 2008 at 8:02 PM, Steve Kargl > wrote: > > In the process of helping to debug a problem with gcc-4.4.0 > > (actually a gfortran problem), I run gprof on the executable. > > The profile shows that __sys_ftruncate is extremely slow. > > > > % cumulative self self total > > time seconds seconds calls ms/call ms/call name > > 85.6 6.05 6.05 51830 0.12 0.12 __sys_ftruncate = [2] > > 5.6 6.44 0.40 0 100.00% .mcount (101) > > 1.7 6.56 0.12 51872 0.00 0.00 _lseek [5] > > 1.6 6.67 0.11 52055 0.00 0.00 sigprocmask [6] > > 0.8 6.73 0.06 103687 0.00 0.00 memset [14] > > 0.4 6.76 0.03 488 0.06 0.06 __sys_write [18] > > 0.4 6.79 0.03 0 100.00% formatted_transfe= r_scalar > > > > time ./z > > 184.21 real 0.98 user 6.57 sys > > > > This program should finish well under 184 seconds. The same program > > and exact same gcc/gfortran source on linux shows > > real 0m0.555s user 0m0.103s sys 0m0.452s > > > > Is __sys_ftruncate known to have performance problems? --XhDIt1ZqED2V8RHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfjQlQACgkQC3+MBN1Mb4hdtwCfYMtBdsqyFgSONLhtnhOY044I pMYAn0G9FLvgyqaoY2Rhbnq8p94Dco71 =DIQM -----END PGP SIGNATURE----- --XhDIt1ZqED2V8RHq-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 10:34:37 2008 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 0533D1065670 for ; Fri, 21 Mar 2008 10:34:37 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by mx1.freebsd.org (Postfix) with ESMTP id 901C68FC3D for ; Fri, 21 Mar 2008 10:34:36 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from router.rabson.org ([80.177.232.241] helo=itchy.rabson.org) by anchor-post-36.mail.demon.net with esmtp (Exim 4.67) id 1Jcea2-000Ci1-Ld for current@freebsd.org; Fri, 21 Mar 2008 10:34:34 +0000 Received: from macbook.rabson.org (macbook.rabson.org [IPv6:2002:50b1:e8f2:1:21e:52ff:fe73:8011]) by itchy.rabson.org (Postfix) with ESMTP id CFC6A3F90 for ; Fri, 21 Mar 2008 10:27:08 +0000 (GMT) Message-Id: From: Doug Rabson To: current@freebsd.org Content-Type: multipart/signed; boundary=Apple-Mail-70-154762100; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 21 Mar 2008 10:27:08 +0000 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV 0.92/6314/Fri Mar 21 08:47:35 2008 on itchy.rabson.org X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: CFR: New NFS Lock Manager X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 10:34:37 -0000 --Apple-Mail-70-154762100 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit As I mentioned previously, I have been working on a brand new NFS Lock Manager which runs in kernel mode and uses the normal local locking infrastructure for its state. I'm currently trying to tie up the last few loose ends before committing this work to current. You can find a snapshot of this code at http://people.freebsd.org/~dfr/lockd-RC1-20032008.diff . To try it out, take a recent current (I last merged with current on 20th March) and apply the patch. Build a kernel with the NFSLOCKD option and add '-k' to 'rpc_lockd_flags' in rc.conf. You will need to build and install at least a new libc and rpc.lockd. At this point, it would be useful to get some extra eyes to look over my changes. In particular the following: 1. Choice of syscall number - I found one spare next to the NFS syscall and took that. The new syscall is listed in the FBSD_1.1 namespace, possibly it should be somewhere else. 2. ABI compatibility - I extended the flock structure by one member (adding l_sysid). I have added new operations to fcntl to support the new extended structure, leaving the old operations in place to work on the old structure. The kernel translates old to new and vice versa. No attempt is made to allow a new userland to work with an old kernel. 3. The local lock manager has had a complete rewrite to support required features. The new local lock manager supports a more flexible model of lock ownership (which can support remote lock owners). I have replaced the inadequate deadlock detection code with a new (and fast) graph based system. Using the deadlock graph, I was able to avoid the 'thundering herd' issues the old lock code had when many processes were contending for the same locked region. Given the extent of the changes, wider testing and review would be extremely welcome. 4. The NFS lock manager itself is brand new code and as such ought to be reviewed. I have also ported the userland sunrpc code to run in the kernel environment which may prove useful in future. Highlights include: * Thread-safe kernel RPC client - many threads can use the same RPC client handle safely with replies being de-multiplexed at the socket upcall (typically driven directly by the NIC interrupt) and handed off to whichever thread matches the reply. For UDP sockets, many RPC clients can share the same socket. This allows the use of a single privileged UDP port number to talk to an arbitrary number of remote hosts. * Single-threaded kernel RPC server. Adding support for multi-threaded server would be relatively straightforward and would follow approximately the Solaris KPI. A single thread should be sufficient for the NLM since it should rarely block in normal operation. * Kernel mode NLM server supporting cancel requests and granted callbacks. I've tested the NLM server reasonably extensively - it passes both my own tests and the NFS Connectathon locking tests running on Solaris, Mac OS X and Ubuntu Linux. * Userland NLM client supported. While the NLM server doesn't have support for the local NFS client's locking needs, it does have to field async replies and granted callbacks from remote NLMs that the local client has contacted. We relay these replies to the userland rpc.lockd over a local domain RPC socket. * IPv6 should be supported but has not been tested since I've been unable to get IPv6 to work properly with the Parallels virtual machines that I've been using for development. * Robust deadlock detection for the local lock manager. In particular it will detect deadlocks caused by a lock request that covers more than one blocking request. As required by the NLM protocol, all deadlock detection happens synchronously - a user is guaranteed that if a lock request isn't rejected immediately, the lock will eventually be granted. The old system allowed for a 'deferred deadlock' condition where a blocked lock request could wake up and find that some other deadlock-causing lock owner had beaten them to the lock. * Since both local and remote locks are managed by the same kernel locking code, local and remote processes can safely use file locks for mutual exclusion. Local processes have no fairness advantage compared to remote processes when contending to lock a region that has just been unlocked - the local lock manager enforces a strict first-come first-served model for both local and remote lockers. --Apple-Mail-70-154762100-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 13:33:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B1BC106566C for ; Fri, 21 Mar 2008 13:33:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 3862A8FC13 for ; Fri, 21 Mar 2008 13:33:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.2/8.14.2) with ESMTP id m2LDWnbT009779; Fri, 21 Mar 2008 06:32:49 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.2/8.14.2/Submit) id m2LDWnhi009778; Fri, 21 Mar 2008 06:32:49 -0700 (PDT) (envelope-from sgk) Date: Fri, 21 Mar 2008 06:32:49 -0700 From: Steve Kargl To: Jeff Roberson Message-ID: <20080321133249.GA8586@troutmask.apl.washington.edu> References: <20080321030254.GA98444@troutmask.apl.washington.edu> <20080321034516.GA98780@troutmask.apl.washington.edu> <20080320185743.L910@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080320185743.L910@desktop> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Extremely slooooow __sys_ftruncate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 13:33:56 -0000 On Thu, Mar 20, 2008 at 07:00:37PM -1000, Jeff Roberson wrote: > On Thu, 20 Mar 2008, Steve Kargl wrote: > > >On Thu, Mar 20, 2008 at 08:02:54PM -0700, Steve Kargl wrote: > >>In the process of helping to debug a problem with gcc-4.4.0 > >>(actually a gfortran problem), I run gprof on the executable. > >>The profile shows that __sys_ftruncate is extremely slow. > >> > >> % cumulative self self total > >> time seconds seconds calls ms/call ms/call name > >> 85.6 6.05 6.05 51830 0.12 0.12 __sys_ftruncate [2] > >> 5.6 6.44 0.40 0 100.00% .mcount (101) > >> 1.7 6.56 0.12 51872 0.00 0.00 _lseek [5] > >> 1.6 6.67 0.11 52055 0.00 0.00 sigprocmask [6] > >> 0.8 6.73 0.06 103687 0.00 0.00 memset [14] > >> 0.4 6.76 0.03 488 0.06 0.06 __sys_write [18] > >> 0.4 6.79 0.03 0 100.00% > >> formatted_transfer_scalar > >> > >>time ./z > >> 184.21 real 0.98 user 6.57 sys > >> > >>This program should finish well under 184 seconds. The same program > >>and exact same gcc/gfortran source on linux shows > >> real 0m0.555s user 0m0.103s sys 0m0.452s > >> > >>Is __sys_ftruncate known to have performance problems? > >> > > > >Well, I tried to kludge together a C example based on the > >the Fortran test code and gfortran runtime library. > > Thanks for the test code. truncate is only handled by softupdates when > it's a truncate to 0. Otherwise it's synchronous. :/ Oh. :( > I would argue that the program is doing something terrible. However, we > also shouldn't be so slow. > > I'm confused by your example however. For each iteration we're writing 4 > bytes and then truncating 3 of them off? Is that right? Is that what the > compiler is actually doing? This problem is associated with how gfortran has implemented the Fortran 2003 Stream I/O feature. gfortran uses essentially a double-buffering scheme within its IO system to accommodate all of the supported operating systems. Because of this scheme it has been difficult for me to trace through the code. I tried to write as short as possible example C program that touches write, lseek, and ftruncate to see the problem in one particular code path. Now that I know ftruncate is so slow, I may be able to work around its use in gfortran's runtime library. PS: Thanks for all of your recent changes in ULE and cpu affinity. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 14:52:21 2008 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 CF779106566C for ; Fri, 21 Mar 2008 14:52:21 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: from web33702.mail.mud.yahoo.com (web33702.mail.mud.yahoo.com [68.142.201.199]) by mx1.freebsd.org (Postfix) with SMTP id 9B9088FC16 for ; Fri, 21 Mar 2008 14:52:21 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: (qmail 62375 invoked by uid 60001); 21 Mar 2008 14:52:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=az5F/wWSZz9xcA2iD4YIDhvsChockjBUY4PK1I3VLp3GwgbwduIffs96dLTLHCPhvkBxbHz8KtKSX8m8dB17+6oiq6ukH7Qc4iwcBMEftmQxPLtZCkykQCET04V0hfKmAV270jraWOjoDs6ipu1Zc1ZSlVYlMJMN8DSswbqAm10=; X-YMail-OSG: EaWPBOQVM1lwbCBgnjI8z8kOyWitWffzIZDanb5hCQqt.kIA0jF8nv2H1YKhtcJIAIsEqpI2NixU6ZM.LJduNb0zjljDvEZHev5nwRCddREXjO0z8Gak_9Z6IhWg.mVYGbIF_ZBs7Q-- Received: from [86.62.225.3] by web33702.mail.mud.yahoo.com via HTTP; Fri, 21 Mar 2008 07:52:20 PDT X-Mailer: YahooMailRC/902.38 YahooMailWebService/0.7.162 Date: Fri, 21 Mar 2008 07:52:20 -0700 (PDT) From: Abdullah Ibn Hamad Al-Marri To: Maxim Sobolev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <994010.61982.qm@web33702.mail.mud.yahoo.com> Cc: FreeBSD Current Subject: Re: Speed Step and powerd for servers status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 14:52:21 -0000 ----- Original Message ---- > From: Maxim Sobolev > To: Abdullah Ibn Hamad Al-Marri > Cc: FreeBSD Current > Sent: Tuesday, March 18, 2008 10:49:29 PM > Subject: Re: Speed Step and powerd for servers status? > > Abdullah Ibn Hamad Al-Marri wrote: > > Hey, > > > > > > I would like to use powerd and speed step for my servers, and make sure it > will use the MAX CPU if needed then go to idle mode to save the power. > > > > Any recommendation? > > It's questionable whether or not it will have positive effect on the server: > > > The combination of processor-frequency scaling and idle-power states > provides a somewhat surprising result. On almost all modern hardware, if > there is code to run, then it is more power efficient to run the > processor at full speed. This "race to idle" concept stems from the > power consumption of an idle processor being much lower than an active > processor, even if running at a lower speed. The overall power > consumption will be less if the processor spends a short time at full > speed and then falls back to idle, rather than spending twice as long > being active at a lower frequency. > > > Full text is here: > > http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=513 > > -Maxim > Helli Maixm, Did you try it with mysql bench or ubench? Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 15:15:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 262681065676 for ; Fri, 21 Mar 2008 15:15:15 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from mx2.confluenttech.com (mx2.confluentasp.com [216.26.153.14]) by mx1.freebsd.org (Postfix) with ESMTP id E5D128FC23 for ; Fri, 21 Mar 2008 15:15:14 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from calvin.pai.local ([10.0.6.33]) by mx2.confluenttech.com (8.14.1/8.12.9) with ESMTP id m2LFEsGi049038 for ; Fri, 21 Mar 2008 11:14:54 -0400 (EDT) (envelope-from mikej@paymentallianceintl.com) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Fri, 21 Mar 2008 11:15:08 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expensive timeout(9) function: 0x80558680(0x84fe4000) 0.011257544 s thread-index: AciLZlmNdGxq5NB3QcGT8u3aVxgh1A== Importance: normal Priority: normal From: "Michael Jung" To: Subject: Expensive timeout(9) function: 0x80558680(0x84fe4000) 0.011257544 s X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 15:15:15 -0000 FreeBSD charon.confluentasp.com 7.0-STABLE FreeBSD 7.0-STABLE #14: Thu Mar 13 08:52:33 EDT 2008 mikej@charon.confluentasp.com:/tank/usr/obj/tank/usr/src/sys/CHARON i386 Stock GENERIC plus: options WITNESS options DIAGNOSTIC options KDB options DDB options KVA_PAGES=512 Along with this patch which my system requires. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/119984 No panics but I have been seeing a few of these: Expensive timeout(9) function: 0x80558680(0x84fe4000) 0.011257544 s (root@charon) /usr/src# addr2line -e /boot/kernel/kernel.symbols 0x80558680 /tank/usr/src/sys/sys/linedisc.h:122 (root@charon) /usr/src# --mikej CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 17:37:06 2008 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 DDF10106567F for ; Fri, 21 Mar 2008 17:37:06 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63913.mail.re1.yahoo.com (web63913.mail.re1.yahoo.com [69.147.97.128]) by mx1.freebsd.org (Postfix) with SMTP id 738648FC4C for ; Fri, 21 Mar 2008 17:37:05 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 886 invoked by uid 60001); 21 Mar 2008 17:37:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=fntMZT+G8OXATLzyvl2NVn+iO1CutvIn1aRKuVWkELMdcz1MsG3LfzDgLFQRwZgwVN/nhw8AsZ/oLnBd6fT+xKnEDKm8SDmZoJG2sdGrM0BN19h9PmZWL+BgQC5tdE7/KHE8IMLZr0LEN1eNG6b97MRLUZBv/QOvLsWzf75ur7c=; X-YMail-OSG: Za92ocoVM1nWyDJKjvmuK4um0ankzAV0eHqwVX_Dm3pMLpSr_G4ZPA.aAwcWjPUyA62NcsL2RUhFp3TkbLuInFDXFCQIQsdz3NLZizk9Inwxh7V.CUirg.VBQ4pJ3w-- Received: from [24.45.195.185] by web63913.mail.re1.yahoo.com via HTTP; Fri, 21 Mar 2008 10:37:04 PDT Date: Fri, 21 Mar 2008 10:37:04 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <454731.813.qm@web63913.mail.re1.yahoo.com> Cc: Subject: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 17:37:07 -0000 I have an app which reads stats from the kernel periodically, and there can be a lot of iterations, sometimes 20,000 or more. I'm thinking of converting from an ioctl method to kvm_read(). KVM is certainly simpler, but its not clear what overhead is involved, since kvm_read() likely has to call the kernel also. Does anyone have a handle on the difference in overhead, assuming that the ioctl call is to a module which does nothing more than copy the data and return? Thanks, barney ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 18:42:30 2008 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 97087106566C for ; Fri, 21 Mar 2008 18:42:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outJ.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9A28FC13 for ; Fri, 21 Mar 2008 18:42:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 21 Mar 2008 11:42:38 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 4B76D2D6018; Fri, 21 Mar 2008 11:42:29 -0700 (PDT) Message-ID: <47E40196.6060703@elischer.org> Date: Fri, 21 Mar 2008 11:42:30 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Barney Cordoba References: <454731.813.qm@web63913.mail.re1.yahoo.com> In-Reply-To: <454731.813.qm@web63913.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 18:42:30 -0000 Barney Cordoba wrote: > I have an app which reads stats from the kernel > periodically, and there can be a lot of iterations, > sometimes 20,000 or more. I'm thinking of converting > from an ioctl method to kvm_read(). KVM is certainly > simpler, but its not clear what overhead is involved, > since kvm_read() likely has to call the kernel also. > > Does anyone have a handle on the difference in > overhead, assuming that the ioctl call is to a module > which does nothing more than copy the data and return? tried a shared memory page? > > Thanks, > > barney > > > ____________________________________________________________________________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > _______________________________________________ > 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 Fri Mar 21 18:51:15 2008 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 20D56106566C for ; Fri, 21 Mar 2008 18:51:15 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id E03AC8FC1F for ; Fri, 21 Mar 2008 18:51:14 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1713775waf.3 for ; Fri, 21 Mar 2008 11:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=yQ8ueTDNWgG8Qnq54K/eCGQvgaUIyA21knXRIT+ubto=; b=rg4mpHr4iUsWWfEIwR5zD9s1+U87AYthZjKo9dz3PEVDrYNylcIbhkqQfAJPLm86ImEqu6Ol6SpO3vyChyWPDx3LGitPz4Ptk2cyfiUExhf7DM3M9QBPITI8WhEdum53sFbuNXUUouoyU1U+Uca5mH2bCEr81IWvBmNedkJYET0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MEcyuimFiQPgeZtWrQrHfzcAa1aK6XNmYzbBfWxe1duReCFkNRt/p5oPFFMis3hvzcXZ15yrr+DGok0Qed0VEzf05a5ACUiNTsnX31G18fMtqtePM7B8RjI3gW8sr9/6ocJmVPYIAuA84fh/EXSxa+BXUNYtkCfE/+Oh+r298N4= Received: by 10.115.109.1 with SMTP id l1mr6446254wam.90.1206125473869; Fri, 21 Mar 2008 11:51:13 -0700 (PDT) Received: by 10.115.22.10 with HTTP; Fri, 21 Mar 2008 11:51:13 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 11:51:13 -0700 From: "Kip Macy" To: "Doug Rabson" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: current@freebsd.org Subject: Re: CFR: New NFS Lock Manager X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 18:51:15 -0000 I think that for most of us this is the "nuclear reactor" in phk's bikeshed story :) I had a tested and re-factored tcp_output which got essentially no comments. -Kip On Fri, Mar 21, 2008 at 3:27 AM, Doug Rabson wrote: > As I mentioned previously, I have been working on a brand new NFS Lock > Manager which runs in kernel mode and uses the normal local locking > infrastructure for its state. I'm currently trying to tie up the last > few loose ends before committing this work to current. You can find a > snapshot of this code at http://people.freebsd.org/~dfr/lockd-RC1-20032008.diff > . > > To try it out, take a recent current (I last merged with current on > 20th March) and apply the patch. Build a kernel with the NFSLOCKD > option and add '-k' to 'rpc_lockd_flags' in rc.conf. You will need to > build and install at least a new libc and rpc.lockd. > > At this point, it would be useful to get some extra eyes to look over > my changes. In particular the following: > > 1. Choice of syscall number - I found one spare next to the NFS > syscall and took that. The new syscall is listed in the FBSD_1.1 > namespace, possibly it should be somewhere else. > > 2. ABI compatibility - I extended the flock structure by one member > (adding l_sysid). I have added new operations to fcntl to support the > new extended structure, leaving the old operations in place to work on > the old structure. The kernel translates old to new and vice versa. No > attempt is made to allow a new userland to work with an old kernel. > > 3. The local lock manager has had a complete rewrite to support > required features. The new local lock manager supports a more flexible > model of lock ownership (which can support remote lock owners). I have > replaced the inadequate deadlock detection code with a new (and fast) > graph based system. Using the deadlock graph, I was able to avoid the > 'thundering herd' issues the old lock code had when many processes > were contending for the same locked region. Given the extent of the > changes, wider testing and review would be extremely welcome. > > 4. The NFS lock manager itself is brand new code and as such ought to > be reviewed. I have also ported the userland sunrpc code to run in the > kernel environment which may prove useful in future. > > Highlights include: > > * Thread-safe kernel RPC client - many threads can use the same RPC > client handle safely with replies being de-multiplexed at the socket > upcall (typically driven directly by the NIC interrupt) and handed off > to whichever thread matches the reply. For UDP sockets, many RPC > clients can share the same socket. This allows the use of a single > privileged UDP port number to talk to an arbitrary number of remote > hosts. > > * Single-threaded kernel RPC server. Adding support for multi-threaded > server would be relatively straightforward and would follow > approximately the Solaris KPI. A single thread should be sufficient > for the NLM since it should rarely block in normal operation. > > * Kernel mode NLM server supporting cancel requests and granted > callbacks. I've tested the NLM server reasonably extensively - it > passes both my own tests and the NFS Connectathon locking tests > running on Solaris, Mac OS X and Ubuntu Linux. > > * Userland NLM client supported. While the NLM server doesn't have > support for the local NFS client's locking needs, it does have to > field async replies and granted callbacks from remote NLMs that the > local client has contacted. We relay these replies to the userland > rpc.lockd over a local domain RPC socket. > > * IPv6 should be supported but has not been tested since I've been > unable to get IPv6 to work properly with the Parallels virtual > machines that I've been using for development. > > * Robust deadlock detection for the local lock manager. In particular > it will detect deadlocks caused by a lock request that covers more > than one blocking request. As required by the NLM protocol, all > deadlock detection happens synchronously - a user is guaranteed that > if a lock request isn't rejected immediately, the lock will eventually > be granted. The old system allowed for a 'deferred deadlock' condition > where a blocked lock request could wake up and find that some other > deadlock-causing lock owner had beaten them to the lock. > > * Since both local and remote locks are managed by the same kernel > locking code, local and remote processes can safely use file locks for > mutual exclusion. Local processes have no fairness advantage compared > to remote processes when contending to lock a region that has just > been unlocked - the local lock manager enforces a strict first-come > first-served model for both local and remote lockers. From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 19:07:26 2008 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 70A571065672 for ; Fri, 21 Mar 2008 19:07:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outC.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1F68FC22 for ; Fri, 21 Mar 2008 19:07:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 21 Mar 2008 12:07:36 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id F02852D6015; Fri, 21 Mar 2008 12:07:24 -0700 (PDT) Message-ID: <47E4076D.7080701@elischer.org> Date: Fri, 21 Mar 2008 12:07:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Kip Macy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: CFR: New NFS Lock Manager X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 19:07:26 -0000 Kip Macy wrote: > I think that for most of us this is the "nuclear reactor" in phk's > bikeshed story :) The Nuclear reactor is from the SVN guys talk on "poisonous personalities in open software projects" I think. where they declared it to be the logically opposite corollary of the Bikeshed. Doug, As a long term developer with a good track record, most of us are just going to say "probably works fine and I have no idea about that stuff" and leave it at that. Who do you think has any idea about this stuff? > > > I had a tested and re-factored tcp_output which got essentially no comments. > > -Kip > > On Fri, Mar 21, 2008 at 3:27 AM, Doug Rabson wrote: >> As I mentioned previously, I have been working on a brand new NFS Lock >> Manager which runs in kernel mode and uses the normal local locking >> infrastructure for its state. I'm currently trying to tie up the last >> few loose ends before committing this work to current. You can find a >> snapshot of this code at http://people.freebsd.org/~dfr/lockd-RC1-20032008.diff >> . >> >> To try it out, take a recent current (I last merged with current on >> 20th March) and apply the patch. Build a kernel with the NFSLOCKD >> option and add '-k' to 'rpc_lockd_flags' in rc.conf. You will need to >> build and install at least a new libc and rpc.lockd. >> >> At this point, it would be useful to get some extra eyes to look over >> my changes. In particular the following: >> >> 1. Choice of syscall number - I found one spare next to the NFS >> syscall and took that. The new syscall is listed in the FBSD_1.1 >> namespace, possibly it should be somewhere else. >> >> 2. ABI compatibility - I extended the flock structure by one member >> (adding l_sysid). I have added new operations to fcntl to support the >> new extended structure, leaving the old operations in place to work on >> the old structure. The kernel translates old to new and vice versa. No >> attempt is made to allow a new userland to work with an old kernel. >> >> 3. The local lock manager has had a complete rewrite to support >> required features. The new local lock manager supports a more flexible >> model of lock ownership (which can support remote lock owners). I have >> replaced the inadequate deadlock detection code with a new (and fast) >> graph based system. Using the deadlock graph, I was able to avoid the >> 'thundering herd' issues the old lock code had when many processes >> were contending for the same locked region. Given the extent of the >> changes, wider testing and review would be extremely welcome. >> >> 4. The NFS lock manager itself is brand new code and as such ought to >> be reviewed. I have also ported the userland sunrpc code to run in the >> kernel environment which may prove useful in future. >> >> Highlights include: >> >> * Thread-safe kernel RPC client - many threads can use the same RPC >> client handle safely with replies being de-multiplexed at the socket >> upcall (typically driven directly by the NIC interrupt) and handed off >> to whichever thread matches the reply. For UDP sockets, many RPC >> clients can share the same socket. This allows the use of a single >> privileged UDP port number to talk to an arbitrary number of remote >> hosts. >> >> * Single-threaded kernel RPC server. Adding support for multi-threaded >> server would be relatively straightforward and would follow >> approximately the Solaris KPI. A single thread should be sufficient >> for the NLM since it should rarely block in normal operation. >> >> * Kernel mode NLM server supporting cancel requests and granted >> callbacks. I've tested the NLM server reasonably extensively - it >> passes both my own tests and the NFS Connectathon locking tests >> running on Solaris, Mac OS X and Ubuntu Linux. >> >> * Userland NLM client supported. While the NLM server doesn't have >> support for the local NFS client's locking needs, it does have to >> field async replies and granted callbacks from remote NLMs that the >> local client has contacted. We relay these replies to the userland >> rpc.lockd over a local domain RPC socket. >> >> * IPv6 should be supported but has not been tested since I've been >> unable to get IPv6 to work properly with the Parallels virtual >> machines that I've been using for development. >> >> * Robust deadlock detection for the local lock manager. In particular >> it will detect deadlocks caused by a lock request that covers more >> than one blocking request. As required by the NLM protocol, all >> deadlock detection happens synchronously - a user is guaranteed that >> if a lock request isn't rejected immediately, the lock will eventually >> be granted. The old system allowed for a 'deferred deadlock' condition >> where a blocked lock request could wake up and find that some other >> deadlock-causing lock owner had beaten them to the lock. >> >> * Since both local and remote locks are managed by the same kernel >> locking code, local and remote processes can safely use file locks for >> mutual exclusion. Local processes have no fairness advantage compared >> to remote processes when contending to lock a region that has just >> been unlocked - the local lock manager enforces a strict first-come >> first-served model for both local and remote lockers. > _______________________________________________ > 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 Fri Mar 21 19:07:45 2008 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 4FD4A1065768 for ; Fri, 21 Mar 2008 19:07:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3CA8FC1C for ; Fri, 21 Mar 2008 19:07:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 21 Mar 2008 12:07:55 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id ADDD12D6017; Fri, 21 Mar 2008 12:07:43 -0700 (PDT) Message-ID: <47E40780.2000207@elischer.org> Date: Fri, 21 Mar 2008 12:07:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Kip Macy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: CFR: New NFS Lock Manager X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 19:07:45 -0000 Kip Macy wrote: > I think that for most of us this is the "nuclear reactor" in phk's > bikeshed story :) The Nuclear reactor is from the SVN guys talk on "poisonous personalities in open software projects" I think. where they declared it to be the logically opposite corollary of the Bikeshed. Doug, As a long term developer with a good track record, most of us are just going to say "probably works fine and I have no idea about that stuff" and leave it at that. Who do you think has any idea about this stuff? > > > I had a tested and re-factored tcp_output which got essentially no comments. > > -Kip > > On Fri, Mar 21, 2008 at 3:27 AM, Doug Rabson wrote: >> As I mentioned previously, I have been working on a brand new NFS Lock >> Manager which runs in kernel mode and uses the normal local locking >> infrastructure for its state. I'm currently trying to tie up the last >> few loose ends before committing this work to current. You can find a >> snapshot of this code at http://people.freebsd.org/~dfr/lockd-RC1-20032008.diff >> . >> >> To try it out, take a recent current (I last merged with current on >> 20th March) and apply the patch. Build a kernel with the NFSLOCKD >> option and add '-k' to 'rpc_lockd_flags' in rc.conf. You will need to >> build and install at least a new libc and rpc.lockd. >> >> At this point, it would be useful to get some extra eyes to look over >> my changes. In particular the following: >> >> 1. Choice of syscall number - I found one spare next to the NFS >> syscall and took that. The new syscall is listed in the FBSD_1.1 >> namespace, possibly it should be somewhere else. >> >> 2. ABI compatibility - I extended the flock structure by one member >> (adding l_sysid). I have added new operations to fcntl to support the >> new extended structure, leaving the old operations in place to work on >> the old structure. The kernel translates old to new and vice versa. No >> attempt is made to allow a new userland to work with an old kernel. >> >> 3. The local lock manager has had a complete rewrite to support >> required features. The new local lock manager supports a more flexible >> model of lock ownership (which can support remote lock owners). I have >> replaced the inadequate deadlock detection code with a new (and fast) >> graph based system. Using the deadlock graph, I was able to avoid the >> 'thundering herd' issues the old lock code had when many processes >> were contending for the same locked region. Given the extent of the >> changes, wider testing and review would be extremely welcome. >> >> 4. The NFS lock manager itself is brand new code and as such ought to >> be reviewed. I have also ported the userland sunrpc code to run in the >> kernel environment which may prove useful in future. >> >> Highlights include: >> >> * Thread-safe kernel RPC client - many threads can use the same RPC >> client handle safely with replies being de-multiplexed at the socket >> upcall (typically driven directly by the NIC interrupt) and handed off >> to whichever thread matches the reply. For UDP sockets, many RPC >> clients can share the same socket. This allows the use of a single >> privileged UDP port number to talk to an arbitrary number of remote >> hosts. >> >> * Single-threaded kernel RPC server. Adding support for multi-threaded >> server would be relatively straightforward and would follow >> approximately the Solaris KPI. A single thread should be sufficient >> for the NLM since it should rarely block in normal operation. >> >> * Kernel mode NLM server supporting cancel requests and granted >> callbacks. I've tested the NLM server reasonably extensively - it >> passes both my own tests and the NFS Connectathon locking tests >> running on Solaris, Mac OS X and Ubuntu Linux. >> >> * Userland NLM client supported. While the NLM server doesn't have >> support for the local NFS client's locking needs, it does have to >> field async replies and granted callbacks from remote NLMs that the >> local client has contacted. We relay these replies to the userland >> rpc.lockd over a local domain RPC socket. >> >> * IPv6 should be supported but has not been tested since I've been >> unable to get IPv6 to work properly with the Parallels virtual >> machines that I've been using for development. >> >> * Robust deadlock detection for the local lock manager. In particular >> it will detect deadlocks caused by a lock request that covers more >> than one blocking request. As required by the NLM protocol, all >> deadlock detection happens synchronously - a user is guaranteed that >> if a lock request isn't rejected immediately, the lock will eventually >> be granted. The old system allowed for a 'deferred deadlock' condition >> where a blocked lock request could wake up and find that some other >> deadlock-causing lock owner had beaten them to the lock. >> >> * Since both local and remote locks are managed by the same kernel >> locking code, local and remote processes can safely use file locks for >> mutual exclusion. Local processes have no fairness advantage compared >> to remote processes when contending to lock a region that has just >> been unlocked - the local lock manager enforces a strict first-come >> first-served model for both local and remote lockers. > _______________________________________________ > 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 Fri Mar 21 19:39:46 2008 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 35A621065671 for ; Fri, 21 Mar 2008 19:39:46 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by mx1.freebsd.org (Postfix) with ESMTP id CEC1B8FC12 for ; Fri, 21 Mar 2008 19:39:45 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from router.rabson.org ([80.177.232.241] helo=itchy.rabson.org) by anchor-post-36.mail.demon.net with esmtp (Exim 4.67) id 1Jcn5c-000G88-L2; Fri, 21 Mar 2008 19:39:44 +0000 Received: from macbook.rabson.org (macbook.rabson.org [IPv6:2002:50b1:e8f2:1:21e:52ff:fe73:8011]) by itchy.rabson.org (Postfix) with ESMTP id 2990E3FB0; Fri, 21 Mar 2008 19:29:09 +0000 (GMT) Message-Id: From: Doug Rabson To: Julian Elischer In-Reply-To: <47E40780.2000207@elischer.org> Content-Type: multipart/signed; boundary=Apple-Mail-86-187282280; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 21 Mar 2008 19:29:08 +0000 References: <47E40780.2000207@elischer.org> X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV 0.92/6317/Fri Mar 21 17:33:40 2008 on itchy.rabson.org X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kip Macy , current@freebsd.org Subject: Re: CFR: New NFS Lock Manager X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 19:39:46 -0000 --Apple-Mail-86-187282280 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 21 Mar 2008, at 19:07, Julian Elischer wrote: > Kip Macy wrote: >> I think that for most of us this is the "nuclear reactor" in phk's >> bikeshed story :) > > The Nuclear reactor is from the SVN guys talk on "poisonous > personalities in open software projects" I think. where > they declared it to be the logically opposite corollary of the > Bikeshed. Hey, I like that. It made me smile anyways. > > > Doug, As a long term developer with a good track record, > most of us are just going to say "probably works fine and I > have no idea about that stuff" and leave it at that. > > Who do you think has any idea about this stuff? Perhaps no-one but there are probably several people who might look at parts of it or even just test it a bit. Until today, I've only run the machine in a Parallels virtual machine. I put a RELENG_7 version on a real machine today and one of my regression tests triggered an INVARIANTS panic :(. --Apple-Mail-86-187282280-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 19:54:14 2008 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 A93991065670 for ; Fri, 21 Mar 2008 19:54:14 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id C422B8FC13 for ; Fri, 21 Mar 2008 19:54:08 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-25-183.bredband.comhem.se ([83.253.25.183]:62662 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Jcn4y-0006St-9S for current@freebsd.org; Fri, 21 Mar 2008 20:39:05 +0100 Received: (qmail 19676 invoked by uid 1001); 21 Mar 2008 20:39:01 +0100 Date: Fri, 21 Mar 2008 20:39:01 +0100 From: Erik Trulsson To: Julian Elischer Message-ID: <20080321193901.GA19650@falcon.midgard.homeip.net> Mail-Followup-To: Julian Elischer , Kip Macy , current@freebsd.org References: <47E4076D.7080701@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47E4076D.7080701@elischer.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Originating-IP: 83.253.25.183 X-Scan-Result: No virus found in message 1Jcn4y-0006St-9S. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Jcn4y-0006St-9S 5047127316755d888d595bc9299b2133 Cc: Kip Macy , current@freebsd.org Subject: Re: CFR: New NFS Lock Manager X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 19:54:14 -0000 On Fri, Mar 21, 2008 at 12:07:25PM -0700, Julian Elischer wrote: > Kip Macy wrote: >> I think that for most of us this is the "nuclear reactor" in phk's >> bikeshed story :) > > The Nuclear reactor is from the SVN guys talk on "poisonous personalities > in open software projects" I think. where > they declared it to be the logically opposite corollary of the > Bikeshed. No, it is much older than that, but is indeed the opposite of a bikeshed. See the FreeBSD FAQ at http://www.freebsd.org/./doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING for the whole story. > > Doug, As a long term developer with a good track record, > most of us are just going to say "probably works fine and I > have no idea about that stuff" and leave it at that. Yup. "nuclear reactor", indeed. > > Who do you think has any idea about this stuff? > > >> >> >> I had a tested and re-factored tcp_output which got essentially no comments. >> >> -Kip >> >> On Fri, Mar 21, 2008 at 3:27 AM, Doug Rabson wrote: >>> As I mentioned previously, I have been working on a brand new NFS Lock >>> Manager which runs in kernel mode and uses the normal local locking >>> infrastructure for its state. I'm currently trying to tie up the last >>> few loose ends before committing this work to current. You can find a >>> snapshot of this code at http://people.freebsd.org/~dfr/lockd-RC1-20032008.diff >>> . >>> >>> To try it out, take a recent current (I last merged with current on >>> 20th March) and apply the patch. Build a kernel with the NFSLOCKD >>> option and add '-k' to 'rpc_lockd_flags' in rc.conf. You will need to >>> build and install at least a new libc and rpc.lockd. >>> >>> At this point, it would be useful to get some extra eyes to look over >>> my changes. In particular the following: >>> >>> 1. Choice of syscall number - I found one spare next to the NFS >>> syscall and took that. The new syscall is listed in the FBSD_1.1 >>> namespace, possibly it should be somewhere else. >>> >>> 2. ABI compatibility - I extended the flock structure by one member >>> (adding l_sysid). I have added new operations to fcntl to support the >>> new extended structure, leaving the old operations in place to work on >>> the old structure. The kernel translates old to new and vice versa. No >>> attempt is made to allow a new userland to work with an old kernel. >>> >>> 3. The local lock manager has had a complete rewrite to support >>> required features. The new local lock manager supports a more flexible >>> model of lock ownership (which can support remote lock owners). I have >>> replaced the inadequate deadlock detection code with a new (and fast) >>> graph based system. Using the deadlock graph, I was able to avoid the >>> 'thundering herd' issues the old lock code had when many processes >>> were contending for the same locked region. Given the extent of the >>> changes, wider testing and review would be extremely welcome. >>> >>> 4. The NFS lock manager itself is brand new code and as such ought to >>> be reviewed. I have also ported the userland sunrpc code to run in the >>> kernel environment which may prove useful in future. >>> >>> Highlights include: >>> >>> * Thread-safe kernel RPC client - many threads can use the same RPC >>> client handle safely with replies being de-multiplexed at the socket >>> upcall (typically driven directly by the NIC interrupt) and handed off >>> to whichever thread matches the reply. For UDP sockets, many RPC >>> clients can share the same socket. This allows the use of a single >>> privileged UDP port number to talk to an arbitrary number of remote >>> hosts. >>> >>> * Single-threaded kernel RPC server. Adding support for multi-threaded >>> server would be relatively straightforward and would follow >>> approximately the Solaris KPI. A single thread should be sufficient >>> for the NLM since it should rarely block in normal operation. >>> >>> * Kernel mode NLM server supporting cancel requests and granted >>> callbacks. I've tested the NLM server reasonably extensively - it >>> passes both my own tests and the NFS Connectathon locking tests >>> running on Solaris, Mac OS X and Ubuntu Linux. >>> >>> * Userland NLM client supported. While the NLM server doesn't have >>> support for the local NFS client's locking needs, it does have to >>> field async replies and granted callbacks from remote NLMs that the >>> local client has contacted. We relay these replies to the userland >>> rpc.lockd over a local domain RPC socket. >>> >>> * IPv6 should be supported but has not been tested since I've been >>> unable to get IPv6 to work properly with the Parallels virtual >>> machines that I've been using for development. >>> >>> * Robust deadlock detection for the local lock manager. In particular >>> it will detect deadlocks caused by a lock request that covers more >>> than one blocking request. As required by the NLM protocol, all >>> deadlock detection happens synchronously - a user is guaranteed that >>> if a lock request isn't rejected immediately, the lock will eventually >>> be granted. The old system allowed for a 'deferred deadlock' condition >>> where a blocked lock request could wake up and find that some other >>> deadlock-causing lock owner had beaten them to the lock. >>> >>> * Since both local and remote locks are managed by the same kernel >>> locking code, local and remote processes can safely use file locks for >>> mutual exclusion. Local processes have no fairness advantage compared >>> to remote processes when contending to lock a region that has just >>> been unlocked - the local lock manager enforces a strict first-come >>> first-served model for both local and remote lockers. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 20:03:41 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 780A7106566B for ; Fri, 21 Mar 2008 20:03:41 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id F05E58FC12 for ; Fri, 21 Mar 2008 20:03:40 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m2LJcPBp059068; Fri, 21 Mar 2008 15:38:25 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m2LJcOTr059067; Fri, 21 Mar 2008 15:38:24 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 21 Mar 2008 15:38:24 -0400 From: David Schultz To: Jeff Roberson Message-ID: <20080321193824.GA58996@zim.MIT.EDU> Mail-Followup-To: Jeff Roberson , Steve Kargl , freebsd-current@FreeBSD.ORG References: <20080321030254.GA98444@troutmask.apl.washington.edu> <20080321034516.GA98780@troutmask.apl.washington.edu> <20080320185743.L910@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080320185743.L910@desktop> Cc: freebsd-current@FreeBSD.ORG, Steve Kargl Subject: Re: Extremely slooooow __sys_ftruncate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 20:03:41 -0000 On Thu, Mar 20, 2008, Jeff Roberson wrote: > On Thu, 20 Mar 2008, Steve Kargl wrote: > > >On Thu, Mar 20, 2008 at 08:02:54PM -0700, Steve Kargl wrote: > >>In the process of helping to debug a problem with gcc-4.4.0 > >>(actually a gfortran problem), I run gprof on the executable. > >>The profile shows that __sys_ftruncate is extremely slow. > >> > >> % cumulative self self total > >> time seconds seconds calls ms/call ms/call name > >> 85.6 6.05 6.05 51830 0.12 0.12 __sys_ftruncate [2] > >> 5.6 6.44 0.40 0 100.00% .mcount (101) > >> 1.7 6.56 0.12 51872 0.00 0.00 _lseek [5] > >> 1.6 6.67 0.11 52055 0.00 0.00 sigprocmask [6] > >> 0.8 6.73 0.06 103687 0.00 0.00 memset [14] > >> 0.4 6.76 0.03 488 0.06 0.06 __sys_write [18] > >> 0.4 6.79 0.03 0 100.00% > >> formatted_transfer_scalar > >> > >>time ./z > >> 184.21 real 0.98 user 6.57 sys > >> > >>This program should finish well under 184 seconds. The same program > >>and exact same gcc/gfortran source on linux shows > >> real 0m0.555s user 0m0.103s sys 0m0.452s > >> > >>Is __sys_ftruncate known to have performance problems? > >> > > > >Well, I tried to kludge together a C example based on the > >the Fortran test code and gfortran runtime library. > > Thanks for the test code. truncate is only handled by softupdates when > it's a truncate to 0. Otherwise it's synchronous. :/ There was a bug that was fixed several years ago in which repeatedly writing to a file and then truncating it could cause thousands of update dependencies on indirect blocks to accumulate, leading to an immediate panic. The fix was to fsync the file every 50 truncates, which means that truncate(2) can get "charged" for a lot of deferred softupdates work. By the way, the tunable debug.maxindirdeps determines the number of truncates that can occur before the fsync happens. From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 21:52:31 2008 Return-Path: Delivered-To: FreeBSD-Current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BCC9106566C for ; Fri, 21 Mar 2008 21:52:31 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from VM01.Vitsch.net (vm01.vitsch.net [85.17.51.140]) by mx1.freebsd.org (Postfix) with ESMTP id D09148FC2E for ; Fri, 21 Mar 2008 21:52:30 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from [192.168.72.251] (81-171-30-78.dsl.fiberworld.nl [81.171.30.78] (may be forged)) (authenticated bits=0) by VM01.Vitsch.net (8.13.8/8.13.8) with ESMTP id m2LLNK5d062210 for ; Fri, 21 Mar 2008 22:23:20 +0100 (CET) (envelope-from Danovitsch@vitsch.net) From: "Daan Vreeken [PA4DAN]" Organization: Vitsch Electronics To: FreeBSD-Current@FreeBSD.org Date: Fri, 21 Mar 2008 22:23:03 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803212223.03388.Danovitsch@vitsch.net> Cc: Subject: Crash during boot on Asus P5N-MX MB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 21:52:31 -0000 Hi All, I'm having trouble booting FreeBSD (-current or 6.1) on a new PC using an Asus P5N-MX mother board equipped with a Intel E6750 Core 2 Duo processor. After adding some printf()'s I've found out that the kernel crashes in vm/vm_page.c - vm_page_startup() around the line : bzero((void *)mapped, end - new_end); This is the output of a verbose boot with VERBOSE_SYSINIT and custom printf()'s : GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009f000 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000fec00000 len=0000000001400000 SMAP type=02 base=00000000f0000000 len=0000000002000000 SMAP type=03 base=000000007fef3000 len=000000000000d000 SMAP type=04 base=000000007fef0000 len=0000000000003000 SMAP type=02 base=000000000009f000 len=0000000000001000 SMAP type=01 base=0000000000100000 len=000000007fdf0000 SMAP type=02 base=0000000077000000 len=0000000008000000 SMAP type=01 base=000000007f000000 len=0000000000df0000 Overlapping or non-monotonic memory region, ignoring second region Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #15: Fri Mar 21 22:06:26 CET 2008 root@Racebeest.Vitsch.LAN:/home/src-tijdelijk-current/src/sys/i386/compile/GENERIC WARNING: WITNESS option enabled, expect reduced performance. subsystem 900000 mtx_pool_setup_static(0)... done. subsystem 1000000 vm_mem_init(0)... 1 2 vm_page_startup() 1 vm_page_startup() before-1st-for phys_avail[0]=0x1000 phys_avail[1]=0x9e000 vm_page_startup() before-1st-for phys_avail[2]=0x100000 phys_avail[3]=0x400000 vm_page_startup() before-1st-for phys_avail[4]=0x1025000 phys_avail[5]=0x7fdf0000 vm_page_startup() before-1st-for phys_avail[6]=0x7f000000 phys_avail[7]=0x7fde0000 vm_page_startup() before-2nd-for phys_avail[0]=0x1000 phys_avail[1]=0x9e000 vm_page_startup() before-2nd-for phys_avail[2]=0x100000 phys_avail[3]=0x400000 vm_page_startup() before-2nd-for phys_avail[4]=0x1025000 phys_avail[5]=0x7fdf0000 vm_page_startup() before-2nd-for phys_avail[6]=0x7f000000 phys_avail[7]=0x7fde0000 vm_page_startup() 2 vm_page_startup() after-2nd-for phys_avail[0]=0x1000 phys_avail[1]=0x9e000 vm_page_startup() after-2nd-for phys_avail[2]=0x100000 phys_avail[3]=0x400000 vm_page_startup() after-2nd-for phys_avail[4]=0x1025000 phys_avail[5]=0x7fdf0000 vm_page_startup() after-2nd-for phys_avail[6]=0x7f000000 phys_avail[7]=0x7fde0000 vm_page_startup() 3 vm_page_startup() 4 vm_page_startup() 5 vm_page_startup() 6 vm_page_startup() 7 going to call bzero() with end=0x7fdf0000 new_end=0x7fdc0000 v kkkkkkkkkkkkkkk ---- system reboots here ---- After printing "... goin to call bzero()..." the system halts for a couple of seconds. Then it prints the first letter of the printf() I've added directly after the call to bzero(), followed by a number of line feeds, followed by a row of k's and then the system reboots without entering the debugger. Has anyone ever seen this, or can someone help debug this problem? Thanks, -- Daan From owner-freebsd-current@FreeBSD.ORG Fri Mar 21 22:36:26 2008 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 423CB1065670 for ; Fri, 21 Mar 2008 22:36:26 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63911.mail.re1.yahoo.com (web63911.mail.re1.yahoo.com [69.147.97.126]) by mx1.freebsd.org (Postfix) with SMTP id BC2298FC15 for ; Fri, 21 Mar 2008 22:36:25 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 8207 invoked by uid 60001); 21 Mar 2008 22:36:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=b24EfCTpJ6BZCh75aVLCHk6leOG1Vm71vdSS/FbVLP7SCVO/k2jbzkijB0BRrN0GKZD6BrwZMtwGENiZqwjpfLaSDExfaRPlZpWWRGZnCuCEpC/jtj0rXfi2HAbvPFeRDHme7fIA9sSYKK8FQBlgsDkadoyzX2gArRKXnvsoo+Y=; X-YMail-OSG: SSb__NYVM1k1i4VrjLTbUbh4yE9IGc1EWNeegSgiW_N1SNtEOiIxL3mSAzUUJGmiaBC_Mh_IZ_qY62_tCF8.daZF37.gAQupUd9b2gjbzMvEJkuK.xGe0h7iqnoeGDx46fjfdDOp.L90e98- Received: from [24.45.195.185] by web63911.mail.re1.yahoo.com via HTTP; Fri, 21 Mar 2008 15:36:24 PDT Date: Fri, 21 Mar 2008 15:36:24 -0700 (PDT) From: Barney Cordoba To: Julian Elischer In-Reply-To: <47E40196.6060703@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <817070.5892.qm@web63911.mail.re1.yahoo.com> Cc: current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Mar 2008 22:36:26 -0000 --- Julian Elischer wrote: > Barney Cordoba wrote: > > I have an app which reads stats from the kernel > > periodically, and there can be a lot of > iterations, > > sometimes 20,000 or more. I'm thinking of > converting > > from an ioctl method to kvm_read(). KVM is > certainly > > simpler, but its not clear what overhead is > involved, > > since kvm_read() likely has to call the kernel > also. > > > > Does anyone have a handle on the difference in > > overhead, assuming that the ioctl call is to a > module > > which does nothing more than copy the data and > return? > > tried a shared memory page? No, but I built a test and kvm_read is 70 times faster, in case anyone is interested. Barney ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 01:53:07 2008 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 7EED2106564A for ; Sat, 22 Mar 2008 01:53:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outS.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9DB8FC17 for ; Sat, 22 Mar 2008 01:53:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 21 Mar 2008 18:54:08 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 971772D6004; Fri, 21 Mar 2008 18:53:06 -0700 (PDT) Message-ID: <47E46682.4020403@elischer.org> Date: Fri, 21 Mar 2008 18:53:06 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Barney Cordoba References: <817070.5892.qm@web63911.mail.re1.yahoo.com> In-Reply-To: <817070.5892.qm@web63911.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 01:53:07 -0000 Barney Cordoba wrote: > --- Julian Elischer wrote: > >> Barney Cordoba wrote: >>> I have an app which reads stats from the kernel >>> periodically, and there can be a lot of >> iterations, >>> sometimes 20,000 or more. I'm thinking of >> converting >>> from an ioctl method to kvm_read(). KVM is >> certainly >>> simpler, but its not clear what overhead is >> involved, >>> since kvm_read() likely has to call the kernel >> also. >>> Does anyone have a handle on the difference in >>> overhead, assuming that the ioctl call is to a >> module >>> which does nothing more than copy the data and >> return? >> >> tried a shared memory page? > > No, but I built a test and kvm_read is 70 times > faster, in > case anyone is interested. cool.. the only downside is that we are trying to get away from kvm direct access. (which is why a shared page might give the same result with a stable API which is not libkvm... BTW on an SMP machine you have no way to ensure that your stats are coherent if you use libkvm. > > Barney > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 02:59:51 2008 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 C4D0D106564A for ; Sat, 22 Mar 2008 02:59:51 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 6901F8FC1B for ; Sat, 22 Mar 2008 02:59:51 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 96096 invoked by uid 60001); 22 Mar 2008 02:59:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=DZRraApf0bpacbqpNUqDkkoHvSWuRzMA6ei9tIXrD6nLqp8FrV0SgHbsPfy0s8JUfny8vUhqKAWfflFRlKB01UfdjdIhmMgLCCXUaguAoxZUTlvzekMg1eKn8dxPOmV8WSFjb+yYvoE7SrygKeDu7jyGgV1GGqueBaPVIsk0xHE=; X-YMail-OSG: 8jwbsZ0VM1k_BnMaT6Y8H.FzTDTBjMa8GMc9NiupiHDoMp_rlO5yUcWihG1LJcZ7_9imlzicXa.IdTMDDormesupWrhYi4AQ5fIDMiOnmRB1tLpUKZU- Received: from [24.45.195.185] by web63906.mail.re1.yahoo.com via HTTP; Fri, 21 Mar 2008 19:59:50 PDT Date: Fri, 21 Mar 2008 19:59:50 -0700 (PDT) From: Barney Cordoba To: Julian Elischer In-Reply-To: <47E46682.4020403@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <494618.95957.qm@web63906.mail.re1.yahoo.com> Cc: current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 02:59:51 -0000 --- Julian Elischer wrote: > Barney Cordoba wrote: > > --- Julian Elischer wrote: > > > >> Barney Cordoba wrote: > >>> I have an app which reads stats from the kernel > >>> periodically, and there can be a lot of > >> iterations, > >>> sometimes 20,000 or more. I'm thinking of > >> converting > >>> from an ioctl method to kvm_read(). KVM is > >> certainly > >>> simpler, but its not clear what overhead is > >> involved, > >>> since kvm_read() likely has to call the kernel > >> also. > >>> Does anyone have a handle on the difference in > >>> overhead, assuming that the ioctl call is to a > >> module > >>> which does nothing more than copy the data and > >> return? > >> > >> tried a shared memory page? > > > > No, but I built a test and kvm_read is 70 times > > faster, in > > case anyone is interested. > > cool.. > the only downside is that we are trying to get away > from kvm direct > access. (which is why a shared page might give the > same result with a > stable API which is not libkvm... BTW on an SMP > machine you have > no way to ensure that your stats are coherent if you > use libkvm. The app is portable, and I'd prefer not to have different methods for LINUX and FreeBSD. When you say "coherent", what exactly do you mean? Barney ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 04:21:44 2008 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 97E47106566B for ; Sat, 22 Mar 2008 04:21:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF028FC1C for ; Sat, 22 Mar 2008 04:21:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 21 Mar 2008 21:23:10 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id E1D102D6011; Fri, 21 Mar 2008 21:21:43 -0700 (PDT) Message-ID: <47E48957.7040903@elischer.org> Date: Fri, 21 Mar 2008 21:21:43 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Barney Cordoba References: <494618.95957.qm@web63906.mail.re1.yahoo.com> In-Reply-To: <494618.95957.qm@web63906.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 04:21:44 -0000 Barney Cordoba wrote: > --- Julian Elischer wrote: > >> Barney Cordoba wrote: >>> --- Julian Elischer wrote: >>> >>>> Barney Cordoba wrote: >>>>> I have an app which reads stats from the kernel >>>>> periodically, and there can be a lot of >>>> iterations, >>>>> sometimes 20,000 or more. I'm thinking of >>>> converting >>>>> from an ioctl method to kvm_read(). KVM is >>>> certainly >>>>> simpler, but its not clear what overhead is >>>> involved, >>>>> since kvm_read() likely has to call the kernel >>>> also. >>>>> Does anyone have a handle on the difference in >>>>> overhead, assuming that the ioctl call is to a >>>> module >>>>> which does nothing more than copy the data and >>>> return? >>>> >>>> tried a shared memory page? >>> No, but I built a test and kvm_read is 70 times >>> faster, in >>> case anyone is interested. >> cool.. >> the only downside is that we are trying to get away >> from kvm direct >> access. (which is why a shared page might give the >> same result with a >> stable API which is not libkvm... BTW on an SMP >> machine you have >> no way to ensure that your stats are coherent if you >> use libkvm. > > The app is portable, and I'd prefer not to have > different methods for LINUX and FreeBSD. When you say > "coherent", what exactly do you mean? there is no synchronisation between your app and the device. I dont know what sized structure you are reading but how do you know that the device isn't half way through writing it? A mmapped page would be more portable, for example done in the way that a video frame buffer is done. All systems support that sort of semantic the same. Then you can use memory semaphores to make sure that the stuff is consistent, because you can write back. > > Barney > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 07:31:51 2008 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 D2C23106566C for ; Sat, 22 Mar 2008 07:31:51 +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 B2BFD8FC13 for ; Sat, 22 Mar 2008 07:31:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id E77D817104; Sat, 22 Mar 2008 07:31:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m2M7VmcE009429; Sat, 22 Mar 2008 07:31:48 GMT (envelope-from phk@critter.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 21 Mar 2008 18:53:06 MST." <47E46682.4020403@elischer.org> Date: Sat, 22 Mar 2008 07:31:47 +0000 Message-ID: <9428.1206171107@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Barney Cordoba , current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 07:31:51 -0000 In message <47E46682.4020403@elischer.org>, Julian Elischer writes: >>> tried a shared memory page? >> >> No, but I built a test and kvm_read is 70 times >> faster, in >> case anyone is interested. The shared memory approach is much better than that, you should go that way. Look at the adlink driver for an example. -- 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 Sat Mar 22 11:51:42 2008 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 5F3201065670 for ; Sat, 22 Mar 2008 11:51:42 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from anchor-post-37.mail.demon.net (anchor-post-37.mail.demon.net [194.217.242.87]) by mx1.freebsd.org (Postfix) with ESMTP id 15CDD8FC22 for ; Sat, 22 Mar 2008 11:51:42 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from router.rabson.org ([80.177.232.241] helo=itchy.rabson.org) by anchor-post-37.mail.demon.net with esmtp (Exim 4.68) id 1Jd2GC-0001S9-Ow for current@freebsd.org; Sat, 22 Mar 2008 11:51:40 +0000 Received: from macbook.rabson.org (macbook.rabson.org [IPv6:2002:50b1:e8f2:1:21e:52ff:fe73:8011]) by itchy.rabson.org (Postfix) with ESMTP id F20713FB0; Sat, 22 Mar 2008 11:51:39 +0000 (GMT) Message-Id: From: Doug Rabson To: Doug Rabson In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-106-246233165; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 22 Mar 2008 11:51:39 +0000 References: X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV 0.92/6328/Sat Mar 22 07:49:51 2008 on itchy.rabson.org X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: CFR: New NFS Lock Manager X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 11:51:42 -0000 --Apple-Mail-106-246233165 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I've just uploaded a new patch at http://people.freebsd.org/~dfr/lockd-RC2-22032008.diff . This fixes a serious problem on kernels not compiled with the LOCKF_DEBUG option (I misplaced a #endif). It also includes minor fixes to support 64bit architectures and RELENG_7 (the patch does not apply cleanly to RELENG_7 but does work when you work around the patch rejects manually). On 21 Mar 2008, at 10:27, Doug Rabson wrote: > As I mentioned previously, I have been working on a brand new NFS > Lock Manager which runs in kernel mode and uses the normal local > locking infrastructure for its state. I'm currently trying to tie up > the last few loose ends before committing this work to current. You > can find a snapshot of this code at http://people.freebsd.org/~dfr/lockd-RC1-20032008.diff > . > > To try it out, take a recent current (I last merged with current on > 20th March) and apply the patch. Build a kernel with the NFSLOCKD > option and add '-k' to 'rpc_lockd_flags' in rc.conf. You will need > to build and install at least a new libc and rpc.lockd. > > At this point, it would be useful to get some extra eyes to look > over my changes. In particular the following: > > 1. Choice of syscall number - I found one spare next to the NFS > syscall and took that. The new syscall is listed in the FBSD_1.1 > namespace, possibly it should be somewhere else. > > 2. ABI compatibility - I extended the flock structure by one member > (adding l_sysid). I have added new operations to fcntl to support > the new extended structure, leaving the old operations in place to > work on the old structure. The kernel translates old to new and vice > versa. No attempt is made to allow a new userland to work with an > old kernel. > > 3. The local lock manager has had a complete rewrite to support > required features. The new local lock manager supports a more > flexible model of lock ownership (which can support remote lock > owners). I have replaced the inadequate deadlock detection code with > a new (and fast) graph based system. Using the deadlock graph, I was > able to avoid the 'thundering herd' issues the old lock code had > when many processes were contending for the same locked region. > Given the extent of the changes, wider testing and review would be > extremely welcome. > > 4. The NFS lock manager itself is brand new code and as such ought > to be reviewed. I have also ported the userland sunrpc code to run > in the kernel environment which may prove useful in future. > > Highlights include: > > * Thread-safe kernel RPC client - many threads can use the same RPC > client handle safely with replies being de-multiplexed at the socket > upcall (typically driven directly by the NIC interrupt) and handed > off to whichever thread matches the reply. For UDP sockets, many RPC > clients can share the same socket. This allows the use of a single > privileged UDP port number to talk to an arbitrary number of remote > hosts. > > * Single-threaded kernel RPC server. Adding support for multi- > threaded server would be relatively straightforward and would follow > approximately the Solaris KPI. A single thread should be sufficient > for the NLM since it should rarely block in normal operation. > > * Kernel mode NLM server supporting cancel requests and granted > callbacks. I've tested the NLM server reasonably extensively - it > passes both my own tests and the NFS Connectathon locking tests > running on Solaris, Mac OS X and Ubuntu Linux. > > * Userland NLM client supported. While the NLM server doesn't have > support for the local NFS client's locking needs, it does have to > field async replies and granted callbacks from remote NLMs that the > local client has contacted. We relay these replies to the userland > rpc.lockd over a local domain RPC socket. > > * IPv6 should be supported but has not been tested since I've been > unable to get IPv6 to work properly with the Parallels virtual > machines that I've been using for development. > > * Robust deadlock detection for the local lock manager. In > particular it will detect deadlocks caused by a lock request that > covers more than one blocking request. As required by the NLM > protocol, all deadlock detection happens synchronously - a user is > guaranteed that if a lock request isn't rejected immediately, the > lock will eventually be granted. The old system allowed for a > 'deferred deadlock' condition where a blocked lock request could > wake up and find that some other deadlock-causing lock owner had > beaten them to the lock. > > * Since both local and remote locks are managed by the same kernel > locking code, local and remote processes can safely use file locks > for mutual exclusion. Local processes have no fairness advantage > compared to remote processes when contending to lock a region that > has just been unlocked - the local lock manager enforces a strict > first-come first-served model for both local and remote lockers. --Apple-Mail-106-246233165-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 12:58:18 2008 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 C83AA106566C for ; Sat, 22 Mar 2008 12:58:18 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63914.mail.re1.yahoo.com (web63914.mail.re1.yahoo.com [69.147.97.129]) by mx1.freebsd.org (Postfix) with SMTP id 777548FC1B for ; Sat, 22 Mar 2008 12:58:18 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 92504 invoked by uid 60001); 22 Mar 2008 12:58:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=jNfqaaQJuepJ8Xr5PTYPBywB+juuUrM3bXZkvKmeVourATx71kKFNdj0sQ5174ELLnc8tEKQnqAoQgH6sS1KLBskNHoK+W8KlDdg3cZgfDr3SLfPvC6steux0sPEjK1EPTTFohAEZ7BLY399gA6nJHckvfQ+DGToj6HaUVpjJ94=; X-YMail-OSG: L0QG_lUVM1m_OEvsmClCqoRXfuGj1S4qqj4f6CPE1vAyMJRoe83Lv4ntaQZuFX9QfZWieHu7INBJkPVeV9yoGxX0GjQBZAAVqY07BWSBz15afYRdWEyKzF3k0TjRJeztc3vmDN.LqMHEyxQ- Received: from [24.45.195.185] by web63914.mail.re1.yahoo.com via HTTP; Sat, 22 Mar 2008 05:58:17 PDT Date: Sat, 22 Mar 2008 05:58:17 -0700 (PDT) From: Barney Cordoba To: Julian Elischer In-Reply-To: <47E48957.7040903@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <523743.91444.qm@web63914.mail.re1.yahoo.com> Cc: current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 12:58:18 -0000 --- Julian Elischer wrote: > Barney Cordoba wrote: > > --- Julian Elischer wrote: > > > >> Barney Cordoba wrote: > >>> --- Julian Elischer wrote: > >>> > >>>> Barney Cordoba wrote: > >>>>> I have an app which reads stats from the > kernel > >>>>> periodically, and there can be a lot of > >>>> iterations, > >>>>> sometimes 20,000 or more. I'm thinking of > >>>> converting > >>>>> from an ioctl method to kvm_read(). KVM is > >>>> certainly > >>>>> simpler, but its not clear what overhead is > >>>> involved, > >>>>> since kvm_read() likely has to call the kernel > >>>> also. > >>>>> Does anyone have a handle on the difference in > >>>>> overhead, assuming that the ioctl call is to a > >>>> module > >>>>> which does nothing more than copy the data and > >>>> return? > >>>> > >>>> tried a shared memory page? > >>> No, but I built a test and kvm_read is 70 times > >>> faster, in > >>> case anyone is interested. > >> cool.. > >> the only downside is that we are trying to get > away > >> from kvm direct > >> access. (which is why a shared page might give > the > >> same result with a > >> stable API which is not libkvm... BTW on an SMP > >> machine you have > >> no way to ensure that your stats are coherent if > you > >> use libkvm. > > > > The app is portable, and I'd prefer not to have > > different methods for LINUX and FreeBSD. When you > say > > "coherent", what exactly do you mean? > > there is no synchronisation between your app and the > device. > I dont know what sized structure you are reading but > how do you know > that the device isn't half way through writing it? > > A mmapped page would be more portable, > for example done in the way that a video frame > buffer is done. > All systems support that sort of semantic the same. > Then you can use memory semaphores to make sure that > the stuff is > consistent, because you can write back. Is this a page of memory, or some other "page" concept? As I mentioned, there are n structures, and there could be 20K or more of them. The structures are 72 bytes. Its also read-only, and not dreadfully important that the stats are exactly tied to a precise moment in time. Its similar to netstat. The stats are continuously being written. When we need to sync them, we can issue a "snapshot" ioctl that locks and copies the current stats to a static variable and then the variables are read. Barney ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 13:02:04 2008 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 7014C106566C for ; Sat, 22 Mar 2008 13:02:04 +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 3A7D78FC13 for ; Sat, 22 Mar 2008 13:02:03 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id D609B17104; Sat, 22 Mar 2008 13:02:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m2MD20Yt010925; Sat, 22 Mar 2008 13:02:00 GMT (envelope-from phk@critter.freebsd.dk) To: Barney Cordoba From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 22 Mar 2008 05:58:17 MST." <523743.91444.qm@web63914.mail.re1.yahoo.com> Date: Sat, 22 Mar 2008 13:02:00 +0000 Message-ID: <10924.1206190920@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Julian Elischer , current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 13:02:04 -0000 In message <523743.91444.qm@web63914.mail.re1.yahoo.com>, Barney Cordoba writes : >Is this a page of memory, or some other "page" Yes, chunks of 4K (usually). >concept? As I mentioned, there are n structures, and >there could be 20K or more of them. The structures are >72 bytes. Its also read-only, and not dreadfully >important that the stats are exactly tied to a precise >moment in time. The point about shared memory is that there are no system calls involved, so they are for all pratical points of view free. -- 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 Sat Mar 22 13:26:47 2008 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 E4522106566B for ; Sat, 22 Mar 2008 13:26:47 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63914.mail.re1.yahoo.com (web63914.mail.re1.yahoo.com [69.147.97.129]) by mx1.freebsd.org (Postfix) with SMTP id 7FB688FC15 for ; Sat, 22 Mar 2008 13:26:47 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 19155 invoked by uid 60001); 22 Mar 2008 13:26:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=dkYGTkcddA2PfME20s164eYwjbm7+YEo9dXtYAQth6E5GrhplTK3cXwlgknsdZeQmIPtKzHI7dzO9k0/5VvG3vbywMPstFsV7xGNFYcn0t2xC/rdbXni72ihS+mpFmLJMXjcrjV6d4F/112ucP2OvX5kNtdBPogFYoPAssVg5iU=; X-YMail-OSG: PgcuaMoVM1ny5W3rfPAB2Epl3DvRfy7ribcdSoTO Received: from [24.45.195.185] by web63914.mail.re1.yahoo.com via HTTP; Sat, 22 Mar 2008 06:26:46 PDT Date: Sat, 22 Mar 2008 06:26:46 -0700 (PDT) From: Barney Cordoba To: Poul-Henning Kamp , Julian Elischer In-Reply-To: <9428.1206171107@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <416202.18656.qm@web63914.mail.re1.yahoo.com> Cc: current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 13:26:48 -0000 --- Poul-Henning Kamp wrote: > In message <47E46682.4020403@elischer.org>, Julian > Elischer writes: > > >>> tried a shared memory page? > >> > >> No, but I built a test and kvm_read is 70 times > >> faster, in > >> case anyone is interested. > > The shared memory approach is much better than that, > you should > go that way. > > Look at the adlink driver for an example. I can't easily follow this driver, given the superior comments :) I don't see this in the handbook. Is there a document which describes both kernel and userland implementation? My concern is this: stats may be updated in iterations of 100K+ times per second, while stats are only gathered once every few seconds. Even a tiny addition to the kernel cpu cycles can make it a "cut off your head to stop a nosebleed" scenario. I don't want to lose cpu cycles for the sake of saving a fraction of a ms every few minutes. Barney ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 13:32:23 2008 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 87C5F106564A for ; Sat, 22 Mar 2008 13:32:23 +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 5341A8FC24 for ; Sat, 22 Mar 2008 13:32:23 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9D81E17107; Sat, 22 Mar 2008 13:32:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m2MDWLi6011009; Sat, 22 Mar 2008 13:32:21 GMT (envelope-from phk@critter.freebsd.dk) To: Barney Cordoba From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 22 Mar 2008 06:26:46 MST." <416202.18656.qm@web63914.mail.re1.yahoo.com> Date: Sat, 22 Mar 2008 13:32:21 +0000 Message-ID: <11008.1206192741@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Julian Elischer , current@freebsd.org Subject: Re: kvm_read() vs ioctl performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 13:32:23 -0000 In message <416202.18656.qm@web63914.mail.re1.yahoo.com>, Barney Cordoba writes : >I can't easily follow this driver, given the superior >comments :) Look at the mmap() function. >My concern is this: stats may be updated in iterations >of 100K+ times per second, while stats are only >gathered once every few seconds. Even a tiny addition >to the kernel cpu cycles can make it a "cut off your >head to stop a nosebleed" scenario. I don't want to >lose cpu cycles for the sake of saving a fraction of a >ms every few minutes. The point about using shared memory, is that it is just that: shared memory. The memory the kernel writes to, is the same memory the userland reads from. There is _no_ overhead anywhere. -- 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 Sat Mar 22 16:45:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D77E3106566C for ; Sat, 22 Mar 2008 16:45:25 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8148F8FC12 for ; Sat, 22 Mar 2008 16:45:25 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2MGjOFl024888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 22 Mar 2008 09:45:24 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <47E537A4.702@freebsd.org> Date: Sat, 22 Mar 2008 09:45:24 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------080403060301020701070207" X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Subject: [Fwd: call for help w/ vap support scripts] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 16:45:26 -0000 This is a multi-part message in MIME format. --------------080403060301020701070207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------080403060301020701070207 Content-Type: message/rfc822; name="call for help w/ vap support scripts.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="call for help w/ vap support scripts.eml" Return-Path: Received: from ebb.errno.com ([unix socket]) (authenticated user=sam bits=0) by ebb.errno.com (Cyrus v2.2.2-BETA) with LMTP; Fri, 21 Mar 2008 14:08:38 -0700 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2LL7H5L019181 for ; Fri, 21 Mar 2008 14:08:38 -0700 (PDT) (envelope-from owner-freebsd-rc@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 20F9D15051B; Fri, 21 Mar 2008 21:07:16 +0000 (UTC) (envelope-from owner-freebsd-rc@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B0F541065676; Fri, 21 Mar 2008 21:07:16 +0000 (UTC) (envelope-from owner-freebsd-rc@freebsd.org) Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 425231065672 for ; Fri, 21 Mar 2008 21:07:12 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 154398FC1E for ; Fri, 21 Mar 2008 21:07:12 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2LKbeCw018990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Mar 2008 13:37:41 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <47E41C94.6080304@errno.com> Date: Fri, 21 Mar 2008 13:37:40 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: freebsd-rc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Subject: call for help w/ vap support scripts X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-rc@freebsd.org Errors-To: owner-freebsd-rc@freebsd.org I'm preparing the multi-bss/vap wireless code for commit to HEAD but need help w/ the rc scripts (and devd glue) to make this happen. With vaps the underlying device is no longer used directly; instead you must clone a vap ifnet before you can do things like associate to an ap. For example, ifconfig wlan create wlandev ath0 wlanmode sta will create a wlanX device that operates in station mode. This doesn't work with the existing rc support so we need changes. If you're interested in working on this please contact me directly. Note I am not interested in suggestions of the sort "why don't you auto-create wlanX's for each device". I've been down that road (the vap code is nearly 4 years old) and that's a disaster. Sam _______________________________________________ freebsd-rc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" --------------080403060301020701070207-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 19:26:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 190FB1065677 for ; Sat, 22 Mar 2008 19:26:34 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id 024A78FC24 for ; Sat, 22 Mar 2008 19:26:33 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 10262 invoked from network); 22 Mar 2008 19:26:33 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Mar 2008 19:26:33 -0000 Message-ID: <47E55BD0.2000101@chuckr.org> Date: Sat, 22 Mar 2008 15:19:44 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: patching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 19:26:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I finally get to the point that I can do some useful coding on some usb stuff, I make up a patch, update current so that I can compile against it, and find that someone has broken current. Naughty, naughty. Here's the part of kdump where it broke: ===> usr.bin/kdump (all) cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.bin/kdump/../ktrace - -I/usr/src/usr.bin/kdump -I/usr/src/usr.bin/kdump/../.. -c /usr/src/usr.bin/kdump/kdump.c cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.bin/kdump/../ktrace - -I/usr/src/usr.bin/kdump -I/usr/src/usr.bin/kdump/../.. -c ioctl.c In file included from ioctl.c:127: /usr/obj/usr/src/tmp/usr/include/sys/tablet.h:93: error: redefinition of 'struct synapticshw' *** Error code 1 Hope that's of some help. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5VvQz62J6PPcoOkRAgBnAJ4jNmThoQmqDyJ/wlv+vqra/5YI/ACffkSo 0aN3Hxq0Rwn5HjTDb651Pv0= =GLzQ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 20:03:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0D231065672 for ; Sat, 22 Mar 2008 20:03:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A2E1F8FC1D for ; Sat, 22 Mar 2008 20:03:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4C08646B45; Sat, 22 Mar 2008 16:03:34 -0400 (EDT) Date: Sat, 22 Mar 2008 20:03:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Chuck Robey In-Reply-To: <47E55BD0.2000101@chuckr.org> Message-ID: <20080322200225.C32322@fledge.watson.org> References: <47E55BD0.2000101@chuckr.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: patching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 20:03:34 -0000 On Sat, 22 Mar 2008, Chuck Robey wrote: > I finally get to the point that I can do some useful coding on some usb > stuff, I make up a patch, update current so that I can compile against it, > and find that someone has broken current. Naughty, naughty. Here's the part > of kdump where it broke: Since we don't have a sys/tablet, I'm wondering if it's perhaps your fault :-). Does your include file have appropriate #ifndef/#define/#endif guards around it to protect you from syntax errors in the event of multiple (possibly nested) include? Robert N M Watson Computer Laboratory University of Cambridge > > ===> usr.bin/kdump (all) > cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.bin/kdump/../ktrace > - -I/usr/src/usr.bin/kdump -I/usr/src/usr.bin/kdump/../.. -c > /usr/src/usr.bin/kdump/kdump.c > cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.bin/kdump/../ktrace > - -I/usr/src/usr.bin/kdump -I/usr/src/usr.bin/kdump/../.. -c ioctl.c > In file included from ioctl.c:127: > /usr/obj/usr/src/tmp/usr/include/sys/tablet.h:93: error: redefinition of 'struct > synapticshw' > *** Error code 1 > > Hope that's of some help. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFH5VvQz62J6PPcoOkRAgBnAJ4jNmThoQmqDyJ/wlv+vqra/5YI/ACffkSo > 0aN3Hxq0Rwn5HjTDb651Pv0= > =GLzQ > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Sat Mar 22 21:22:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A344E106566B for ; Sat, 22 Mar 2008 21:22:56 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 89B388FC22 for ; Sat, 22 Mar 2008 21:22:56 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 749 invoked from network); 22 Mar 2008 21:22:55 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Mar 2008 21:22:55 -0000 Message-ID: <47E57717.5060404@chuckr.org> Date: Sat, 22 Mar 2008 17:16:07 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Robert Watson References: <47E55BD0.2000101@chuckr.org> <20080322200225.C32322@fledge.watson.org> In-Reply-To: <20080322200225.C32322@fledge.watson.org> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: patching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 21:22:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Watson wrote: > On Sat, 22 Mar 2008, Chuck Robey wrote: > >> I finally get to the point that I can do some useful coding on some >> usb stuff, I make up a patch, update current so that I can compile >> against it, and find that someone has broken current. Naughty, >> naughty. Here's the part of kdump where it broke: > > Since we don't have a sys/tablet, I'm wondering if it's perhaps your > fault :-). Does your include file have appropriate > #ifndef/#define/#endif guards around it to protect you from syntax > errors in the event of multiple (possibly nested) include? Oh, I didn;'t include my patches in what broke, I was trying to get the new kernel buoilt and booted first, so whjat broke is 100% just what walked out of the archive (I cvsup the cvs archive, not just a checked out image). Soon as this doesn't break on build, I will try my fix to Kai's krepdump USB HID dumping module. After that, I finish my in process changes to the Xorg's xf86-input-evdev module so give me one I call xf86-input-uclogic, then I begin (I haven't even started this part) the uta.c, which is a USB driver for my UC Logic WP8060 Graphic Tablet. I've done one hell of a lot of research on the HID spec (enough to strongly suspect that the folks who wrote it were under the influence of recreational pharmaceuticals). > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> ===> usr.bin/kdump (all) >> cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.bin/kdump/../ktrace >> - -I/usr/src/usr.bin/kdump -I/usr/src/usr.bin/kdump/../.. -c >> /usr/src/usr.bin/kdump/kdump.c >> cc -O2 -fno-strict-aliasing -pipe -I/usr/src/usr.bin/kdump/../ktrace >> - -I/usr/src/usr.bin/kdump -I/usr/src/usr.bin/kdump/../.. -c ioctl.c >> In file included from ioctl.c:127: >> /usr/obj/usr/src/tmp/usr/include/sys/tablet.h:93: error: redefinition >> of 'struct >> synapticshw' >> *** Error code 1 >> >> Hope that's of some help. >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.4 (FreeBSD) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFH5VvQz62J6PPcoOkRAgBnAJ4jNmThoQmqDyJ/wlv+vqra/5YI/ACffkSo >> 0aN3Hxq0Rwn5HjTDb651Pv0= >> =GLzQ >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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" >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5XcXz62J6PPcoOkRAgInAJ9N+Rjo402nwHFDSn5fZ0Ql1CSMNwCgiWFR BYLavTQo9f6S9zm8fro/8bw= =jesb -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Mar 22 23:37:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B4A1065673; Sat, 22 Mar 2008 23:37:13 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ABB748FC1A; Sat, 22 Mar 2008 23:37:12 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47E5982C.5040702@FreeBSD.org> Date: Sun, 23 Mar 2008 00:37:16 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Chuck Robey References: <47E55BD0.2000101@chuckr.org> <20080322200225.C32322@fledge.watson.org> <47E57717.5060404@chuckr.org> In-Reply-To: <47E57717.5060404@chuckr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: patching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Mar 2008 23:37:13 -0000 Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Robert Watson wrote: >> On Sat, 22 Mar 2008, Chuck Robey wrote: >> >>> I finally get to the point that I can do some useful coding on some >>> usb stuff, I make up a patch, update current so that I can compile >>> against it, and find that someone has broken current. Naughty, >>> naughty. Here's the part of kdump where it broke: >> Since we don't have a sys/tablet, I'm wondering if it's perhaps your >> fault :-). Does your include file have appropriate >> #ifndef/#define/#endif guards around it to protect you from syntax >> errors in the event of multiple (possibly nested) include? > > Oh, I didn;'t include my patches in what broke, I was trying to get the new > kernel buoilt and booted first, so whjat broke is 100% just what walked out of > the archive (I cvsup the cvs archive, not just a checked out image). Soon as > this doesn't break on build, I will try my fix to Kai's krepdump USB HID dumping > module. was removed from FreeBSD 8 years ago. Something is seriously out of date on your system. Kris