From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 00:09:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D440516A420; Sun, 26 Aug 2007 00:09:51 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 44D2613C459; Sun, 26 Aug 2007 00:08:38 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from akima.flintsbach.schmalzbauer.de (akima.flintsbach.schmalzbauer.de [172.21.1.35]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l7Q08aT4086493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2007 02:08:37 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Sun, 26 Aug 2007 02:08:34 +0200 User-Agent: KMail/1.9.7 References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <200708260054.42892.h.schmalzbauer@omnisec.de> <46D0BEEF.1020601@FreeBSD.org> In-Reply-To: <46D0BEEF.1020601@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708260208.35700.h.schmalzbauer@omnisec.de> Cc: "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.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: Sun, 26 Aug 2007 00:09:51 -0000 Am Sonntag, 26. August 2007 01:44:47 schrieb Constantine A. Murenin: > On 25/08/2007 18:54, Harald Schmalzbauer wrote: > > Am Dienstag, 21. August 2007 22:54:22 schrieb Constantine A. Murenin: > >>http://p4web.freebsd.org/depot/projects/soc2007/cnst-sensors/cnst-sensors > >>.2 007-08-20.patch > > > > Thanks a lot for your hard work. > > I'd love to test it but the 08-20 patch doesn't cleanly apply to > > todays -current in coretemp. > > Can you supply a diff to that patch or reroll a new patch? > > Thanks for testing! > > The coretemp.c updated to contain the 2007-08-23 change from the CVS > (coretemp.c#rev1.2) can be downloaded directly from my perforce branch: > > http://p4web.freebsd.org/@sr=125633@//depot/projects/soc2007/cnst-sensors/s >ys.dev.coretemp/coretemp.c Great, but I have other problems too. Compiling world fails here: cc -O2 -fno-strict-aliasing -pipe -march=nocona -DINET6 -c /usr/src/usr.bin/systat/sensors.c In file included from /usr/src/usr.bin/systat/sensors.c:298: /usr/src/usr.bin/systat/systat.h:39: error: redefinition of 'struct cmdtab' /usr/src/usr.bin/systat/sensors.c:309: error: redefinition of 'opensensors' /usr/src/usr.bin/systat/sensors.c:47: error: previous definition of 'opensensors' was here /usr/src/usr.bin/systat/sensors.c:315: error: redefinition of 'closesensors' /usr/src/usr.bin/systat/sensors.c:53: error: previous definition of 'closesensors' was here /usr/src/usr.bin/systat/sensors.c:325: error: redefinition of 'labelsensors' /usr/src/usr.bin/systat/sensors.c:63: error: previous definition of 'labelsensors' was here /usr/src/usr.bin/systat/sensors.c:336: error: redefinition of 'fetchsensors' /usr/src/usr.bin/systat/sensors.c:74: error: previous definition of 'fetchsensors' was here /usr/src/usr.bin/systat/sensors.c:378: error: redefinition of 'drvstat' /usr/src/usr.bin/systat/sensors.c:116: error: previous definition of 'drvstat' was here /usr/src/usr.bin/systat/sensors.c:386: error: redefinition of 'showsensors' /usr/src/usr.bin/systat/sensors.c:124: error: previous definition of 'showsensors' was here /usr/src/usr.bin/systat/sensors.c:393: error: redefinition of 'initsensors' /usr/src/usr.bin/systat/sensors.c:131: error: previous definition of 'initsensors' was here /usr/src/usr.bin/systat/sensors.c:399: error: redefinition of 'printline' /usr/src/usr.bin/systat/sensors.c:137: error: previous definition of 'printline' was here /usr/src/usr.bin/systat/sensors.c:477: error: redefinition of 'fmttime' /usr/src/usr.bin/systat/sensors.c:215: error: previous definition of 'fmttime' was here *** Error code 1 Thanks, -Harry From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 00:16:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D00116A420; Sun, 26 Aug 2007 00:16:17 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id B04D813C465; Sun, 26 Aug 2007 00:16:16 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from akima.flintsbach.schmalzbauer.de (akima.flintsbach.schmalzbauer.de [172.21.1.35]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l7Q0GFIT086642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2007 02:16:15 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Sun, 26 Aug 2007 02:16:12 +0200 User-Agent: KMail/1.9.7 References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <46D0BEEF.1020601@FreeBSD.org> <200708260208.35700.h.schmalzbauer@omnisec.de> In-Reply-To: <200708260208.35700.h.schmalzbauer@omnisec.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708260216.14210.h.schmalzbauer@omnisec.de> Cc: "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.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: Sun, 26 Aug 2007 00:16:17 -0000 Am Sonntag, 26. August 2007 02:08:34 schrieb Harald Schmalzbauer: > > The coretemp.c updated to contain the 2007-08-23 change from the CVS > > (coretemp.c#rev1.2) can be downloaded directly from my perforce branch: > > > > http://p4web.freebsd.org/@sr=125633@//depot/projects/soc2007/cnst-sensors > >/s ys.dev.coretemp/coretemp.c > > Great, but I have other problems too. > Compiling world fails here: > cc -O2 -fno-strict-aliasing -pipe -march=nocona -DINET6 -c > /usr/src/usr.bin/systat/sensors.c In file included from > /usr/src/usr.bin/systat/sensors.c:298: > /usr/src/usr.bin/systat/systat.h:39: error: redefinition of 'struct cmdtab' > /usr/src/usr.bin/systat/sensors.c:309: error: redefinition of 'opensensors' > /usr/src/usr.bin/systat/sensors.c:47: error: previous definition > of 'opensensors' was here > /usr/src/usr.bin/systat/sensors.c:315: error: redefinition of > 'closesensors' /usr/src/usr.bin/systat/sensors.c:53: error: previous > definition > of 'closesensors' was here > /usr/src/usr.bin/systat/sensors.c:325: error: redefinition of > 'labelsensors' /usr/src/usr.bin/systat/sensors.c:63: error: previous > definition > of 'labelsensors' was here > /usr/src/usr.bin/systat/sensors.c:336: error: redefinition of > 'fetchsensors' /usr/src/usr.bin/systat/sensors.c:74: error: previous > definition > of 'fetchsensors' was here > /usr/src/usr.bin/systat/sensors.c:378: error: redefinition of 'drvstat' > /usr/src/usr.bin/systat/sensors.c:116: error: previous definition of > 'drvstat' was here > /usr/src/usr.bin/systat/sensors.c:386: error: redefinition of 'showsensors' > /usr/src/usr.bin/systat/sensors.c:124: error: previous definition > of 'showsensors' was here > /usr/src/usr.bin/systat/sensors.c:393: error: redefinition of 'initsensors' > /usr/src/usr.bin/systat/sensors.c:131: error: previous definition > of 'initsensors' was here > /usr/src/usr.bin/systat/sensors.c:399: error: redefinition of 'printline' > /usr/src/usr.bin/systat/sensors.c:137: error: previous definition > of 'printline' was here > /usr/src/usr.bin/systat/sensors.c:477: error: redefinition of 'fmttime' > /usr/src/usr.bin/systat/sensors.c:215: error: previous definition of > 'fmttime' was here > *** Error code 1 Another problem with building kernel: cc -O2 -fno-strict-aliasing -pipe -march=nocona -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/KORSO/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/KORSO -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c: In function 'coretemp_refresh': /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c:297: error: SSE register return with SSE disabled *** Error code 1 1 error Thanks for any help, -Harry From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 03:17:35 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E05616A418; Sun, 26 Aug 2007 03:17:35 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id BB45D13C461; Sun, 26 Aug 2007 03:17:34 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l7Q3HcLp003024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2007 07:17:41 +0400 Message-ID: <46D0F0C3.1000203@FreeBSD.org> Date: Sat, 25 Aug 2007 23:17:23 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Harald Schmalzbauer References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <200708260054.42892.h.schmalzbauer@omnisec.de> <46D0BEEF.1020601@FreeBSD.org> <200708260208.35700.h.schmalzbauer@omnisec.de> In-Reply-To: <200708260208.35700.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.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: Sun, 26 Aug 2007 03:17:35 -0000 On 25/08/2007 20:08, Harald Schmalzbauer wrote: > Am Sonntag, 26. August 2007 01:44:47 schrieb Constantine A. Murenin: > >>On 25/08/2007 18:54, Harald Schmalzbauer wrote: >> >>>Am Dienstag, 21. August 2007 22:54:22 schrieb Constantine A. Murenin: >>> >>>>http://p4web.freebsd.org/depot/projects/soc2007/cnst-sensors/cnst-sensors >>>>.2 007-08-20.patch >>> >>>Thanks a lot for your hard work. >>>I'd love to test it but the 08-20 patch doesn't cleanly apply to >>>todays -current in coretemp. >>>Can you supply a diff to that patch or reroll a new patch? >> >>Thanks for testing! >> >>The coretemp.c updated to contain the 2007-08-23 change from the CVS >>(coretemp.c#rev1.2) can be downloaded directly from my perforce branch: >> >>http://p4web.freebsd.org/@sr=125633@//depot/projects/soc2007/cnst-sensors/s >>ys.dev.coretemp/coretemp.c > > > Great, but I have other problems too. > Compiling world fails here: > cc -O2 -fno-strict-aliasing -pipe -march=nocona -DINET6 -c /usr/src/usr.bin/systat/sensors.c > In file included from /usr/src/usr.bin/systat/sensors.c:298: > /usr/src/usr.bin/systat/systat.h:39: error: redefinition of 'struct cmdtab' > /usr/src/usr.bin/systat/sensors.c:309: error: redefinition of 'opensensors' > /usr/src/usr.bin/systat/sensors.c:47: error: previous definition > of 'opensensors' was here > /usr/src/usr.bin/systat/sensors.c:315: error: redefinition of 'closesensors' > /usr/src/usr.bin/systat/sensors.c:53: error: previous definition > of 'closesensors' was here > /usr/src/usr.bin/systat/sensors.c:325: error: redefinition of 'labelsensors' > /usr/src/usr.bin/systat/sensors.c:63: error: previous definition > of 'labelsensors' was here > /usr/src/usr.bin/systat/sensors.c:336: error: redefinition of 'fetchsensors' > /usr/src/usr.bin/systat/sensors.c:74: error: previous definition > of 'fetchsensors' was here > /usr/src/usr.bin/systat/sensors.c:378: error: redefinition of 'drvstat' > /usr/src/usr.bin/systat/sensors.c:116: error: previous definition of 'drvstat' > was here > /usr/src/usr.bin/systat/sensors.c:386: error: redefinition of 'showsensors' > /usr/src/usr.bin/systat/sensors.c:124: error: previous definition > of 'showsensors' was here > /usr/src/usr.bin/systat/sensors.c:393: error: redefinition of 'initsensors' > /usr/src/usr.bin/systat/sensors.c:131: error: previous definition > of 'initsensors' was here > /usr/src/usr.bin/systat/sensors.c:399: error: redefinition of 'printline' > /usr/src/usr.bin/systat/sensors.c:137: error: previous definition > of 'printline' was here > /usr/src/usr.bin/systat/sensors.c:477: error: redefinition of 'fmttime' > /usr/src/usr.bin/systat/sensors.c:215: error: previous definition of 'fmttime' > was here > *** Error code 1 > > Thanks, > > -Harry You must have applied the patch twice. There are only 212 lines in systat/sensors.c, as is clearly evidenced in the patch: Index: usr.bin/systat/sensors.c =================================================================== RCS file: usr.bin/systat/sensors.c diff -N usr.bin/systat/sensors.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ usr.bin/systat/sensors.c 20 Aug 2007 23:30:32 -0000 @@ -0,0 +1,262 @@ C. From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 05:09:48 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AABE16A418; Sun, 26 Aug 2007 05:09:48 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id EB63313C46A; Sun, 26 Aug 2007 05:09:47 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l7Q59pVW005615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2007 09:09:54 +0400 Message-ID: <46D10B10.2060608@FreeBSD.org> Date: Sun, 26 Aug 2007 01:09:36 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Harald Schmalzbauer , freebsd-current@FreeBSD.org References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <46D0BEEF.1020601@FreeBSD.org> <200708260208.35700.h.schmalzbauer@omnisec.de> <200708260216.14210.h.schmalzbauer@omnisec.de> In-Reply-To: <200708260216.14210.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.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: Sun, 26 Aug 2007 05:09:48 -0000 On 25/08/2007 20:16, Harald Schmalzbauer wrote: >>>http://p4web.freebsd.org/@sr=125633@//depot/projects/soc2007/cnst-sensors/sys.dev.coretemp/coretemp.c ... > cc -O2 -fno-strict-aliasing -pipe -march=nocona -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/KORSO/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/KORSO -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c > /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c: In > function 'coretemp_refresh': > /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c:297: error: SSE > register return with SSE disabled > *** Error code 1 > 1 error I cannot reproduce this bug on i386 with gcc 4.2.0 20070514, so this sounds like a bug in the compiler, either for allowing me to compile the code that shouldn't compile (and run flawlessly -- coretemp is totally tested here), or for not allowing you to compile the code that should compile. (I'll recompile my compiler tomorrow to catch up on the updates to gcc 4.2.1 to see if that changes anything.) Could you please provide more details, e.g. platform (I guess it is amd64?), compiler version and any changes you've made to the tree? This is the code that seems to generate this error with your compiler: s->value = temp * 1e6 + 273.15e6; Where s->value is of type int64_t, and temp is of type int. Does anyone know if the e notation should not be used in this context? In the meantime, I assume that changing that line to: s->value = temp * 1000000 + 273150000; must solve the problem. C. From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 06:52:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D1316A41B; Sun, 26 Aug 2007 06:52:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A02C813C45E; Sun, 26 Aug 2007 06:52:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l7Q6pc8t077308; Sun, 26 Aug 2007 00:51:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 26 Aug 2007 00:51:44 -0600 (MDT) Message-Id: <20070826.005144.1120058851.imp@bsdimp.com> To: cnst@freebsd.org From: "M. Warner Losh" In-Reply-To: <46D10B10.2060608@FreeBSD.org> References: <200708260208.35700.h.schmalzbauer@omnisec.de> <200708260216.14210.h.schmalzbauer@omnisec.de> <46D10B10.2060608@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 26 Aug 2007 00:51:42 -0600 (MDT) Cc: kan@freebsd.org, freebsd-current@freebsd.org, h.schmalzbauer@omnisec.de Subject: Re: GSoC2007: cnst-sensors.2007-08-20.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: Sun, 26 Aug 2007 06:52:19 -0000 In message: <46D10B10.2060608@FreeBSD.org> "Constantine A. Murenin" writes: : On 25/08/2007 20:16, Harald Schmalzbauer wrote: : : >>>http://p4web.freebsd.org/@sr=125633@//depot/projects/soc2007/cnst-sensors/sys.dev.coretemp/coretemp.c : ... : > cc -O2 -fno-strict-aliasing -pipe -march=nocona -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/KORSO/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param : > inline-unit-growth=100 --param : > large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/KORSO -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c : > /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c: In : > function 'coretemp_refresh': : > /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c:297: error: SSE : > register return with SSE disabled : > *** Error code 1 : > 1 error : : I cannot reproduce this bug on i386 with gcc 4.2.0 20070514, so this : sounds like a bug in the compiler, either for allowing me to compile the : code that shouldn't compile (and run flawlessly -- coretemp is totally : tested here), or for not allowing you to compile the code that should : compile. (I'll recompile my compiler tomorrow to catch up on the updates : to gcc 4.2.1 to see if that changes anything.) : : Could you please provide more details, e.g. platform (I guess it is : amd64?), compiler version and any changes you've made to the tree? : : : This is the code that seems to generate this error with your compiler: : : s->value = temp * 1e6 + 273.15e6; : : Where s->value is of type int64_t, and temp is of type int. Does anyone : know if the e notation should not be used in this context? It should not. 1e6 is a floating point number, so the result of this operation is a floating point number that's then truncated into an int. It should be computed as a floating point number. Chances are good that the optimizer optimized out all the floating point before, but doesn't now (or does on i386 and not on amd64). On amd64, it appears that this results in attempting to use the SSE stuff, which results in the compiler error. Your solution is correct. Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 10:37:31 2007 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 74EBB16A417 for ; Sun, 26 Aug 2007 10:37:31 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3D80A13C458 for ; Sun, 26 Aug 2007 10:37:31 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by nz-out-0506.google.com with SMTP id l8so781703nzf for ; Sun, 26 Aug 2007 03:37:30 -0700 (PDT) Received: by 10.142.103.6 with SMTP id a6mr463242wfc.1188124649566; Sun, 26 Aug 2007 03:37:29 -0700 (PDT) Received: by 10.142.203.18 with HTTP; Sun, 26 Aug 2007 03:37:29 -0700 (PDT) Message-ID: <626eb4530708260337t28f0b434oce7b33560822f71f@mail.gmail.com> Date: Sun, 26 Aug 2007 19:37:29 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "KOT MATPOCKuH" In-Reply-To: <3979a4b0708240929p5f42b54ev412d5af16e9fb020@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3979a4b0707291120v4927a20cm357b845f6d1f3567@mail.gmail.com> <46BE1D6C.6040903@cran.org.uk> <626eb4530708221937h31c8f37fu9527e941ed4000b6@mail.gmail.com> <3979a4b0708240929p5f42b54ev412d5af16e9fb020@mail.gmail.com> X-Google-Sender-Auth: cd71dfa3af7a731f Cc: Bruce Cran , current@freebsd.org Subject: Re: console hangs after setting hostname X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 10:37:31 -0000 On 8/25/07, KOT MATPOCKuH wrote: > On 8/23/07, Hidetoshi Shimokawa wrote: > > > > It looks that the low level console is not locked though the high level > > console > > is locked by Giant. > > > > Could you try the attached patch? > > > Thanks you! Console doesn't hangs... Thank for the test. > ...and I'm too see corrupt messages in /var/run/dmesg.boot and on console: > > cd0: <_NEC DVD_RW ND-3540A 1.01> Removable CD-ROM SCSI-0 device > cdS0M:P :3 3A.P 0C0P0UM B#/s1 tLraaunnscfheerds! This is expected. If you concern interleaved meassges, could you try to add the following line to your kernel configuration file as sun4v? options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 11:23:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 435BA16A417; Sun, 26 Aug 2007 11:23:30 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from mta02.xtra.co.nz (mta02.xtra.co.nz [210.54.141.253]) by mx1.freebsd.org (Postfix) with ESMTP id 9796513C467; Sun, 26 Aug 2007 11:23:29 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fep04.xtra.co.nz ([172.23.12.41]) by mta02.xtra.co.nz with ESMTP id <20070826112328.QTUV27853.mta02.xtra.co.nz@fep04.xtra.co.nz>; Sun, 26 Aug 2007 23:23:28 +1200 Received: from serv.int.fubar.geek.nz ([219.89.91.5]) by fep04.xtra.co.nz with ESMTP id <20070826112327.TPEY15322.fep04.xtra.co.nz@serv.int.fubar.geek.nz>; Sun, 26 Aug 2007 23:23:27 +1200 Date: Sun, 26 Aug 2007 23:23:26 +1200 From: Andrew Turner To: "Kip Macy" Message-ID: <20070826232326.6e27eb49@hermies.int.fubar.geek.nz> In-Reply-To: References: <20070824181627.57bed401@hermies.int.fubar.geek.nz> <20070824132409.W3900@fledge.watson.org> <20070826000708.15fbb5bb@hermies.int.fubar.geek.nz> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: FreeBSD on xen hvm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 11:23:30 -0000 On Sat, 25 Aug 2007 10:41:09 -0700 "Kip Macy" wrote: > Have you tried gdbserver? > > -Kip I've got the Xen gdbserver running and I've patched kgdb to attach via tcp. I'm currently working on getting a copy of kgdb that can accept the amd64 registers gdbserver sends. My understanding id kgdb detects the architecture from the kernel file. In this case it will be wrong as the kernel is i386 but the arch is amd64. Andrew -- Andrew Turner http://fubar.geek.nz/blog/ From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 11:31:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF91F16A419; Sun, 26 Aug 2007 11:31:47 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5E2B813C461; Sun, 26 Aug 2007 11:31:47 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l7QBVeio095668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2007 13:31:45 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l7QBVeZX025354; Sun, 26 Aug 2007 13:31:40 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from localhost (localhost [[UNIX: localhost]]) by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l7QBWS0T001812; Sun, 26 Aug 2007 13:32:28 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to h.schmalzbauer@omnisec.de using -f From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Sun, 26 Aug 2007 13:32:28 +0200 User-Agent: KMail/1.9.7 References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <200708260208.35700.h.schmalzbauer@omnisec.de> <46D0F0C3.1000203@FreeBSD.org> In-Reply-To: <46D0F0C3.1000203@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708261332.28397.h.schmalzbauer@omnisec.de> Cc: "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.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: Sun, 26 Aug 2007 11:31:48 -0000 Am Sonntag, 26. August 2007 05:17:23 schrieb Constantine A. Murenin: [*SNIP*] > You must have applied the patch twice. There are only 212 lines in Right, that's a new file and I re-csuped and applied the patch again. I should have removed systat/sensors.c first. world compiled fine. Thanks, -Harry From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 11:37:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F30CD16A417; Sun, 26 Aug 2007 11:37:54 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 56BFD13C461; Sun, 26 Aug 2007 11:37:53 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l7QBblpI095776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2007 13:37:52 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l7QBblM9025402; Sun, 26 Aug 2007 13:37:47 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from localhost (localhost [[UNIX: localhost]]) by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l7QBcZET001881; Sun, 26 Aug 2007 13:38:35 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to h.schmalzbauer@omnisec.de using -f From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Sun, 26 Aug 2007 13:38:35 +0200 User-Agent: KMail/1.9.7 References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <200708260216.14210.h.schmalzbauer@omnisec.de> <46D10B10.2060608@FreeBSD.org> In-Reply-To: <46D10B10.2060608@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708261338.35874.h.schmalzbauer@omnisec.de> Cc: Alexander Kabaev , "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.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: Sun, 26 Aug 2007 11:37:55 -0000 Am Sonntag, 26. August 2007 07:09:36 schrieb Constantine A. Murenin: [...] > > /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c:297: error: > > SSE register return with SSE disabled > > *** Error code 1 > > 1 error > > I cannot reproduce this bug on i386 with gcc 4.2.0 20070514, so this > sounds like a bug in the compiler, either for allowing me to compile the > code that shouldn't compile (and run flawlessly -- coretemp is totally > tested here), or for not allowing you to compile the code that should > compile. (I'll recompile my compiler tomorrow to catch up on the updates > to gcc 4.2.1 to see if that changes anything.) > > Could you please provide more details, e.g. platform (I guess it is > amd64?), compiler version and any changes you've made to the tree? It's a core2 (E6420) machine, running amd64 -current from today (so gcc 4.2.1 with default -O2). In make.conf I have CPUTYPE?=core2, but removing the CPUTYPE doesn't make any difference, it fails exactly with the same error. Makeoption is -j5 as it's a ULE kernel but that's completely irrelevant I think. > This is the code that seems to generate this error with your compiler: > > s->value = temp * 1e6 + 273.15e6; > > Where s->value is of type int64_t, and temp is of type int. Does anyone > know if the e notation should not be used in this context? > > In the meantime, I assume that changing that line to: > > s->value = temp * 1000000 + 273150000; > > must solve the problem. Right, kernel compiles fine now. Thanks, -Harry From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 11:44:05 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02EEB16A420; Sun, 26 Aug 2007 11:44:05 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9B50A13C467; Sun, 26 Aug 2007 11:44:04 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 423D02083; Sun, 26 Aug 2007 13:43:57 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 312752082; Sun, 26 Aug 2007 13:43:57 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 2E18784468; Sun, 26 Aug 2007 13:43:57 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Constantine A. Murenin" References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <46D0BEEF.1020601@FreeBSD.org> <200708260208.35700.h.schmalzbauer@omnisec.de> <200708260216.14210.h.schmalzbauer@omnisec.de> <46D10B10.2060608@FreeBSD.org> Date: Sun, 26 Aug 2007 13:43:57 +0200 In-Reply-To: <46D10B10.2060608@FreeBSD.org> (Constantine A. Murenin's message of "Sun\, 26 Aug 2007 01\:09\:36 -0400") Message-ID: <86lkbyh66a.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Kabaev , freebsd-current@FreeBSD.org, Harald Schmalzbauer Subject: Re: GSoC2007: cnst-sensors.2007-08-20.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: Sun, 26 Aug 2007 11:44:05 -0000 "Constantine A. Murenin" writes: > This is the code that seems to generate this error with your compiler: > > s->value =3D temp * 1e6 + 273.15e6; You can't use floating point in the kernel. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 11:41:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5587216A418 for ; Sun, 26 Aug 2007 11:41:45 +0000 (UTC) (envelope-from joerg@net.t-labs.tu-berlin.de) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by mx1.freebsd.org (Postfix) with ESMTP id 1634D13C457 for ; Sun, 26 Aug 2007 11:41:45 +0000 (UTC) (envelope-from joerg@net.t-labs.tu-berlin.de) Received: from falcon.net.t-labs.tu-berlin.de (falcon.net.t-labs.tu-berlin.de [130.149.220.27]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 253697059788 for ; Sun, 26 Aug 2007 13:08:42 +0200 (CEST) Received: from falcon.net.t-labs.tu-berlin.de (localhost [127.0.0.1]) by falcon.net.t-labs.tu-berlin.de (8.13.8/8.13.8) with ESMTP id l7QB8fYa031313 for ; Sun, 26 Aug 2007 13:08:41 +0200 (CEST) (envelope-from joerg@net.t-labs.tu-berlin.de) Received: (from joerg@localhost) by falcon.net.t-labs.tu-berlin.de (8.13.8/8.13.8/Submit) id l7QB8fT2031312 for freebsd-current@freebsd.org; Sun, 26 Aug 2007 13:08:41 +0200 (CEST) (envelope-from joerg) Date: Sun, 26 Aug 2007 13:08:41 +0200 From: Joerg Wallerich To: freebsd-current@freebsd.org Message-ID: <20070826110841.GA31243@falcon.net.t-labs.tu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Sun, 26 Aug 2007 11:44:13 +0000 Subject: Network problems with sendto() syscall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 11:41:45 -0000 Hi all, since moving to 7-CURRENT I have a serious problem with the network stack when using the sendto() syscall. The problem appears as soon as I work with bootpd(8). As soon as bootpd tries to answer a BOOTP request, the sendto() call fails with EAFNOSUPPORT, I get kernel log messages like 'fxp0: can't handle af18' and then I can no longer access the IP address I sent the BOOTP request from. The call to sendto() in bootpd seems OK, so I doubt that the problem lies with bootpd. The NIC driver seems to be OK as well, as the problems appears with three different drivers (fxp, nfe, rl). I even get things like 'kernel: looutput: af=18 unexpected' in the logs when using bootptest on the local machine. This problem can be reproduced on my hardware using a vanilla installation of the latest snapshot of 7-CURRENT (200708). Does anyone see this behavior besides myself? Thanks, Joerg -- --------------------------------------------------------------- - Joerg Wallerich joerg@net.t-labs.tu-berlin.de - - Technische Universitaet Berlin - --------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 11:51:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E2B116A420 for ; Sun, 26 Aug 2007 11:51:33 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (dong.ci0.org [IPv6:2001:7a8:2066:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3B93413C45D for ; Sun, 26 Aug 2007 11:51:31 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l7QCPP10059984; Sun, 26 Aug 2007 14:25:25 +0200 (CEST) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.14.1/8.13.8/Submit) id l7QCPPP4059983; Sun, 26 Aug 2007 14:25:25 +0200 (CEST) (envelope-from mlfbsd) Date: Sun, 26 Aug 2007 14:25:25 +0200 From: Olivier Houchard To: Joerg Wallerich Message-ID: <20070826122525.GA59924@ci0.org> References: <20070826110841.GA31243@falcon.net.t-labs.tu-berlin.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <20070826110841.GA31243@falcon.net.t-labs.tu-berlin.de> User-Agent: Mutt/1.4.1i Cc: freebsd-current@freebsd.org Subject: Re: Network problems with sendto() syscall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 11:51:33 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Aug 26, 2007 at 01:08:41PM +0200, Joerg Wallerich wrote: > Hi all, > > since moving to 7-CURRENT I have a serious problem with > the network stack when using the sendto() syscall. > > The problem appears as soon as I work with bootpd(8). As > soon as bootpd tries to answer a BOOTP request, the > sendto() call fails with EAFNOSUPPORT, I get kernel log > messages like > > 'fxp0: can't handle af18' > > and then I can no longer access the IP address I sent the > BOOTP request from. > > The call to sendto() in bootpd seems OK, so I doubt that the > problem lies with bootpd. The NIC driver seems to be OK as > well, as the problems appears with three different drivers > (fxp, nfe, rl). I even get things like > > 'kernel: looutput: af=18 unexpected' > > in the logs when using bootptest on the local machine. > > This problem can be reproduced on my hardware using a > vanilla installation of the latest snapshot of 7-CURRENT (200708). > > > Does anyone see this behavior besides myself? > > Thanks, > Joerg > Hi Joerg, This is a known problem. Until the proper fix is committed, you can use the attached patch, it should make bootp usable again. Regards, Olivier --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rtsock.c.diff" Index: net/rtsock.c =================================================================== RCS file: /cognet/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.142 diff -u -p -r1.142 rtsock.c --- net/rtsock.c 27 Mar 2007 19:36:12 -0000 1.142 +++ net/rtsock.c 7 Aug 2007 20:41:52 -0000 @@ -528,7 +528,8 @@ route_output(struct mbuf *m, struct sock RT_UNLOCK(rt); senderr(error); } - rt->rt_flags |= RTF_GATEWAY; + if (!(rt->rt_flags & RTF_LLINFO)) + rt->rt_flags |= RTF_GATEWAY; } if (info.rti_ifa != NULL && info.rti_ifa != rt->rt_ifa) { --xHFwDpU9dbj6ez1V-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 15:05:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31BD716A419 for ; Sun, 26 Aug 2007 15:05:43 +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 AD4D213C45E for ; Sun, 26 Aug 2007 15:05:42 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IPJgL-0005Zz-Au for freebsd-current@freebsd.org; Sun, 26 Aug 2007 17:05:41 +0200 Received: from 78-1-97-234.adsl.net.t-com.hr ([78.1.97.234]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Aug 2007 17:05:41 +0200 Received: from ivoras by 78-1-97-234.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Aug 2007 17:05:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 26 Aug 2007 17:05:19 +0200 Lines: 42 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8E2721130A74390C9C83FD2E" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-97-234.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-Enigmail-Version: 0.95.3 Sender: news Subject: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 15:05:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E2721130A74390C9C83FD2E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Has anyone experienced frequent UFS panics on VMWare on fresh current? I've started seeing ufs_dirbad panics almost daily. For a while I could cause them simply by running make installworld to a freshly newfs-ed file system - the panic message points to the *new* file system. Unfortunately, kgdb cannot process the generated vmcores (though they are on a separate file system that has never crashed). The repeatable panics on new file systems have stopped when I rebuilt the kernel, but now they are happening again, this time on my /usr/ports. I don't think file system options have an influence - they first happened on a "normal" UFS (noasync), and now they are happening on gjournaled, aync mounted UFS. Any ideas on how to provide more information on this? The panics usually happen when I'm in X11, so I can't use the kernel debugger, but sometimes they will happen when I'm in console. I can, at least in theory, provide the VMWare machine for download, but it's 10 GB+. --------------enig8E2721130A74390C9C83FD2E 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 iD8DBQFG0Za1ldnAQVacBcgRAnzVAKDEUYYg1OO/f+8mWzDV3cwsuWVtUQCghzVP IHATZAc1Gk7EZ+p+yhcy5OQ= =ynm6 -----END PGP SIGNATURE----- --------------enig8E2721130A74390C9C83FD2E-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 15:52:30 2007 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 CF95F16A418 for ; Sun, 26 Aug 2007 15:52:30 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8077113C46A for ; Sun, 26 Aug 2007 15:52:30 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so767216wra for ; Sun, 26 Aug 2007 08:52:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZLyBMmHKbwN9nxrb2PXkEUrmBe1lUMw1jV9RUmFLEZabqZvQ4/hw1K6s93JL5sTRs+S+/vrybQvbbc0SZwRwz+jh4xyyDyrKDime5N0wEKnFDnb2AYcFq5ETX6PyIoN/7MB2JMO+DcOZP/c9G55C6vmGo0uI/vTP61xAYuDUw8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=sXAkAPs2AV/Jv0PnxG3VJ3XRJGKpYUsunv3Xkp5BDkmr63vkQiF6gLlzHn3D3L/4bI6K5eexfJeZ1paTwnNqnPZOc0f7DIEykewqaaP2ZSP589P9vLevwwGDPCioY7StWka1hQ0NfKjZTrN0rBJlceifgNVB2JTBX4G6ksNtJeI= Received: by 10.142.142.16 with SMTP id p16mr469524wfd.1188141986132; Sun, 26 Aug 2007 08:26:26 -0700 (PDT) Received: by 10.143.10.17 with HTTP; Sun, 26 Aug 2007 08:26:26 -0700 (PDT) Message-ID: <26ddd1750708260826q153a3425jf9bea3e8a8a82a70@mail.gmail.com> Date: Sun, 26 Aug 2007 11:26:26 -0400 From: "Maxim Khitrov" To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Error building openoffice.org-2: cannot compute object file suffix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 15:52:30 -0000 Hello, Have a bit of a problem and no idea on what is causing it... When I try to build openoffice.org I get the following error: "configure: error: cannot compute suffix of object files: cannot compile". The full output is below. This happens when building gcc-ooo. I looked in config.log, but see no relevant information there, maybe I'm looking in the wrong place. Here's my uname -a output: FreeBSD poseidon.mxwerx.net 7.0-CURRENT FreeBSD 7.0-CURRENT #16: Thu Aug 23 21:11:49 EDT 2007 max@poseidon.mxwerx.net:/usr/obj/usr/src/sys/POSEIDON i386 I've built this system with a bunch of WITHOUT_ knobs in src.conf, so maybe a required tool is not installed. However, I have no idea what is actually needed. Can someone who is familiar with this software please tell me what configure does at the "checking for suffix of object files" step? Maybe that will help me figure out where things go wrong. Thanks, Maxim Khitrov Output: gmake[2]: Leaving directory `/usr/ports/lang/gcc-ooo/work/build/gcc' Checking multilib configuration... multilib.out is unchanged Configuring in i386-portbld-freebsd7.0/libstdc++-v3 configure: loading cache ./config.cache checking build system type... i386-portbld-freebsd7.0 checking host system type... i386-portbld-freebsd7.0 checking target system type... i386-portbld-freebsd7.0 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... gawk checking whether gmake sets $(MAKE)... yes checking for i386-portbld-freebsd7.0-gcc... /usr/ports/lang/gcc-ooo/work/build/gcc/xgcc -B/usr/ports/lang/gcc-ooo/work/build/gcc/ -B/usr/local/i386-portbld-freebsd7.0/bin/ -B/usr/local/i386-portbld-freebsd7.0/lib/ -isystem /usr/local/i386-portbld-freebsd7.0/include -isystem /usr/local/i386-portbld-freebsd7.0/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libstdc++-v3] Error 1 gmake[1]: Leaving directory `/usr/ports/lang/gcc-ooo/work/build' gmake: *** [bootstrap-lean] Error 2 *** Error code 2 Stop in /usr/ports/lang/gcc-ooo. *** Error code 1 Stop in /usr/ports/editors/openoffice.org-2. From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 15:55:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C24416A41B; Sun, 26 Aug 2007 15:55:25 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from outcold.yadt.co.uk (outcold.yadt.co.uk [81.187.204.178]) by mx1.freebsd.org (Postfix) with ESMTP id D05B413C469; Sun, 26 Aug 2007 15:55:22 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from localhost (localhost [127.0.0.1]) by outcold.yadt.co.uk (Postfix) with ESMTP id 82A1D57478; Sun, 26 Aug 2007 16:55:19 +0100 (BST) X-Virus-Scanned: amavisd-new at yadt.co.uk Received: from outcold.yadt.co.uk ([127.0.0.1]) by localhost (outcold.yadt.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smv5eiWpnrs4; Sun, 26 Aug 2007 16:55:09 +0100 (BST) Received: by outcold.yadt.co.uk (Postfix, from userid 1001) id 346E4574FF; Sun, 26 Aug 2007 16:55:09 +0100 (BST) Date: Sun, 26 Aug 2007 16:55:09 +0100 From: David Taylor To: "Wojciech A. Koszek" , freebsd-current@freebsd.org Message-ID: <20070826155509.GA48611@outcold.yadt.co.uk> Mail-Followup-To: "Wojciech A. Koszek" , freebsd-current@freebsd.org References: <20070506164247.GA77786@FreeBSD.czest.pl> <20070719174847.GA5853@outcold.yadt.co.uk> <20070820000721.GA85364@FreeBSD.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20070820000721.GA85364@FreeBSD.czest.pl> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: INCLUDE_CONFIG_FILE patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2007 15:55:25 -0000 On Mon, 20 Aug 2007, Wojciech A. Koszek wrote: > On Thu, Jul 19, 2007 at 06:48:47PM +0100, David Taylor wrote: > > Here's the patch I prepared for you: > > http://people.freebsd.org/~wkoszek/patches/config-trigraph.patch > > Apply it within src/usr.sbin/config directory: > > cd src/usr.sbin/config && patch < config-trigraph.patch > > And rebuild config(8). Please let me know whether it works for you > correctly. I tested it very roughly both with and without -C flag > against GENERIC and LINT configurations tweaked a little bit to contain > trigraphs within comments and options containing value. > > Sorry for long delay in replying, > > Thanks for your report! For some reason that I don't understand, and don't have time to investigate right now, I can't reproduce the problem with the unpatched config, no matter how many trigraphs I add to my kernel configs I expect I'm doing something monumentally stupid. However, your patch didn't cause me any problems, and I expect if I could reproduce the original problem, it would solve that too. -- David Taylor From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 16:29:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CAEF16A475; Sun, 26 Aug 2007 16:29:47 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (unknown [IPv6:2002:8002:ce58::1]) by mx1.freebsd.org (Postfix) with ESMTP id C6D8413C468; Sun, 26 Aug 2007 16:29:46 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1IPKzf-0008DW-Hn; Sun, 26 Aug 2007 12:29:43 -0400 Date: Sun, 26 Aug 2007 12:29:43 -0400 From: Jan Harkes To: Nikolay Pavlov Message-ID: <20070826162943.GP28767@cs.cmu.edu> Mail-Followup-To: Nikolay Pavlov , freebsd-current@freebsd.org, rwatson@freebsd.org References: <200708202340.29678.qpadla@gmail.com> <20070824151927.GA11642@cs.cmu.edu> <200708251732.17394.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708251732.17394.qpadla@gmail.com> User-Agent: Mutt/1.5.16 (2007-06-11) Cc: freebsd-current@freebsd.org, rwatson@freebsd.org Subject: Re: And probably the final crash for today's current :) (panic: filesystem goof: vop_panic[vop_print]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 16:29:47 -0000 On Sat, Aug 25, 2007 at 05:32:13PM +0300, Nikolay Pavlov wrote: > On Friday 24 August 2007 18:19:27 Jan Harkes wrote: > > The following patch adds locking around VOP_ operations. I ran some > > tests and it seems like I got them all. For some reason I could only get > > the warnings to go away when using exclusive locks, but since the > > overhead in our case really is in userspace and we still hold the giant > > lock pretty much everywhere there shouldn't be a measurable difference. > > With your patch everything works fine, but only if i'am using UFS as a > cachedir, rvm and checkpointdir backend. > If i'am using ZFS as a backend a panic occur with "ls -l /coda" command. Probably because the Coda client writes out directory data to the container files in BSD (UFS) format and then uses VOP_READDIR to read them. But ZFS expects a different layout of the directory data and as such VOP_READDIR won't work. In Linux we never could rely on being able to call the underlying fs readdir implementation, so the kernel module there already does it's own parsing of the directory entries in the container files and them one by one back to the VFS. So it is possible, but for now Coda's venus.cache subtree (the container files) just have to be stored on an UFS formatted partition. Jan From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 16:47:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80B3A16A41A for ; Sun, 26 Aug 2007 16:47:42 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 35EAB13C428 for ; Sun, 26 Aug 2007 16:47:40 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1012105nfb for ; Sun, 26 Aug 2007 09:47:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=kNSinHyVXySkJO3CGIBGNS2/X8Bfk29Ra7hCqRHzNKpCjoiHR/s4gNHfsiFOcjlDk3c496Tp7BKtM1Y6shJmTYev9pHpVA/vZ/9DqgFIVtCkyyZC/ngSqBukFGXzNKkxHjFWIip7z1XmAFrOzJi/xoXVx4nZw9SCIFGTn8Hflv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=tQKeJsrKsQ3h0+aCTsI1rOShWtcxeuDS3Mqgjv0AgWFPHO5cbRfaJDZlWaNpHV+1Li0DQyVveira5AqJgFy3i0ydu6+M14SZ52fj+EmSlZk9f2jWsbUI1fGd0u1XQD90rlEKkH17xDijAldRcjOUdqOhfBRMyieylQ//cA/EM4M= Received: by 10.78.145.5 with SMTP id s5mr3140732hud.1188146859665; Sun, 26 Aug 2007 09:47:39 -0700 (PDT) Received: from 77-109-32-13.dynamic.peoplenet.ua ( [77.109.32.13]) by mx.google.com with ESMTPS id y1sm1865761hua.2007.08.26.09.47.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Aug 2007 09:47:38 -0700 (PDT) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Sun, 26 Aug 2007 19:48:01 +0300 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2037616.KYOB0c1B9t"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708261948.05750.qpadla@gmail.com> Cc: Ivan Voras Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@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: Sun, 26 Aug 2007 16:47:42 -0000 --nextPart2037616.KYOB0c1B9t Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 26 August 2007 18:05:19 Ivan Voras wrote: > Hi, > > Has anyone experienced frequent UFS panics on VMWare on fresh current? > I've started seeing ufs_dirbad panics almost daily. For a while I could > cause them simply by running make installworld to a freshly newfs-ed > file system - the panic message points to the *new* file system. > Unfortunately, kgdb cannot process the generated vmcores (though they > are on a separate file system that has never crashed). The repeatable > panics on new file systems have stopped when I rebuilt the kernel, but > now they are happening again, this time on my /usr/ports. I don't think > file system options have an influence - they first happened on a > "normal" UFS (noasync), and now they are happening on gjournaled, aync > mounted UFS. > > Any ideas on how to provide more information on this? The panics usually > happen when I'm in X11, so I can't use the kernel debugger, but > sometimes they will happen when I'm in console. > > I can, at least in theory, provide the VMWare machine for download, but > it's 10 GB+. Is this similar as this one? http://docs.freebsd.org/cgi/mid.cgi?200708202327.03951.qpadla =2D-=20 * Best regards, Nikolay Pavlov * --nextPart2037616.KYOB0c1B9t Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG0a7F/2R6KvEYGaIRAmiEAJ9IIRF3giYvG1kxM3hPUMhKdfFJEACfdFnT 5fZTrLQUVkBw+y6H/EbAWts= =MaOb -----END PGP SIGNATURE----- --nextPart2037616.KYOB0c1B9t-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 16:49:00 2007 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 32A6416A468 for ; Sun, 26 Aug 2007 16:49:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C6C0013C468 for ; Sun, 26 Aug 2007 16:48:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l7QGmfE5014364; Sun, 26 Aug 2007 12:48:41 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Sun, 26 Aug 2007 12:48:41 -0400 (EDT) Date: Sun, 26 Aug 2007 12:48:41 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Yar Tikhiy In-Reply-To: <20070826073535.GD21352@comp.chem.msu.su> Message-ID: References: <20070824.172212.74696955.imp@bsdimp.com> <20070825053302.GG99474@comp.chem.msu.su> <20070825.093925.43008968.imp@bsdimp.com> <1188071752.1853.44.camel@neo.cse.buffalo.edu> <20070826073535.GD21352@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ken Smith , current@freebsd.org, "M. Warner Losh" Subject: Symbol versioning conventions (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2007 16:49:00 -0000 On Sun, 26 Aug 2007, Yar Tikhiy wrote: > > But, anyway, there are at least three people in the project who > misundertood the intended role of symbol versioning. Besides yours > truly, a humble developer, there are a core team member and a release > engineer among them. This may be a sign that some decisions regarding > symbol versioning, which is a rather central feature for developers > and code contributors, haven't had enough exposure. Perhaps we've > just missed some important discussions on the lists, but symbol > versioning is a long-term feature and as such it deserves a document > describing in detail how to use it in our project. I've think I've stated in replies to commit mail that symbol versioning isn't meant as a crutch to aid -current developers, but that is neither written down or documented and was probably over a year ago. > The technical side of symbol versioning puts few limitations on how > one can use it, the rest being a matter of policy. Of course, the > choice of the policy is important and can have far-reaching > consequences, such as getting us into a complete mess or making us > technology champs like Linux and Sun. :-) Now all our symbols still > are at FBSD_1.0, and it isn't late yet to work out such a policy. > Again, it will make an excellent thread on -arch. Here it is on -current, feel free to redirect it to arch. I updated my notes on symbol versioning - see "Version naming conventions" on downwards at: http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt Feel free to cut&paste anything from it in replies. -- DE From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 17:31:44 2007 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 102AD16A417; Sun, 26 Aug 2007 17:31:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id C609B13C465; Sun, 26 Aug 2007 17:31:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l7QHUBHq087344; Sun, 26 Aug 2007 11:30:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 26 Aug 2007 11:30:17 -0600 (MDT) Message-Id: <20070826.113017.-126689373.imp@bsdimp.com> To: deischen@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20070826073535.GD21352@comp.chem.msu.su> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 26 Aug 2007 11:30:11 -0600 (MDT) Cc: yar@comp.chem.msu.su, kensmith@cse.Buffalo.EDU, current@freebsd.org Subject: Re: Symbol versioning conventions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 17:31:44 -0000 In message: Daniel Eischen writes: : On Sun, 26 Aug 2007, Yar Tikhiy wrote: : > : > But, anyway, there are at least three people in the project who : > misundertood the intended role of symbol versioning. Besides yours : > truly, a humble developer, there are a core team member and a release : > engineer among them. This may be a sign that some decisions regarding : > symbol versioning, which is a rather central feature for developers : > and code contributors, haven't had enough exposure. Perhaps we've : > just missed some important discussions on the lists, but symbol : > versioning is a long-term feature and as such it deserves a document : > describing in detail how to use it in our project. : : I've think I've stated in replies to commit mail that symbol versioning : isn't meant as a crutch to aid -current developers, but that is neither : written down or documented and was probably over a year ago. You never answered my point: The release engineer gets to decide when the ABI is frozen. Maybe it already is and this use isn't a crutch. Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 18:03:39 2007 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 ABBC916A417 for ; Sun, 26 Aug 2007 18:03:39 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5869813C459 for ; Sun, 26 Aug 2007 18:03:39 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l7QI3NlP015909; Sun, 26 Aug 2007 14:03:23 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Sun, 26 Aug 2007 14:03:23 -0400 (EDT) Date: Sun, 26 Aug 2007 14:03:23 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20070826.113017.-126689373.imp@bsdimp.com> Message-ID: References: <20070826073535.GD21352@comp.chem.msu.su> <20070826.113017.-126689373.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: yar@comp.chem.msu.su, kensmith@cse.Buffalo.EDU, current@freebsd.org Subject: Re: Symbol versioning conventions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2007 18:03:39 -0000 On Sun, 26 Aug 2007, M. Warner Losh wrote: > In message: > Daniel Eischen writes: > : On Sun, 26 Aug 2007, Yar Tikhiy wrote: > : > > : > But, anyway, there are at least three people in the project who > : > misundertood the intended role of symbol versioning. Besides yours > : > truly, a humble developer, there are a core team member and a release > : > engineer among them. This may be a sign that some decisions regarding > : > symbol versioning, which is a rather central feature for developers > : > and code contributors, haven't had enough exposure. Perhaps we've > : > just missed some important discussions on the lists, but symbol > : > versioning is a long-term feature and as such it deserves a document > : > describing in detail how to use it in our project. > : > : I've think I've stated in replies to commit mail that symbol versioning > : isn't meant as a crutch to aid -current developers, but that is neither > : written down or documented and was probably over a year ago. > > You never answered my point: The release engineer gets to decide when > the ABI is frozen. Maybe it already is and this use isn't a crutch. There can be only one ABI or version in a release. Having multiple _new_ versions between releases implies you are using the intermediate versions as a crutch ;-) In this case, it may be a little different because we haven't yet released anything with symbol versioning. The other thing to remember is that we did bump library versions, so any ABI changes are for free (excluding the upgrade pains typically felt by -current developers). If you keep the old FTS and compat functions, you are maintaining them and keeping the old files in the tree when they've never ever seen a release - there is no point in maintaining them _other_ than to aid -current developers. They certainly don't help applications built in 5.x or 6.x. -- DE From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 19:09:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C96C16A418 for ; Sun, 26 Aug 2007 19:09:42 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 465EE13C45B for ; Sun, 26 Aug 2007 19:09:42 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 82A3B261E0; Sun, 26 Aug 2007 15:09:41 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 26 Aug 2007 15:09:41 -0400 X-Sasl-enc: V4qxpam9TC5kjnSKbpFw+ItT5SuwH2L30SHuB2c6M0fK 1188155381 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 1E7FD1212; Sun, 26 Aug 2007 15:09:41 -0400 (EDT) Message-ID: <46D1CFF3.9060209@FreeBSD.org> Date: Sun, 26 Aug 2007 20:09:39 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Joerg Wallerich References: <20070826110841.GA31243@falcon.net.t-labs.tu-berlin.de> In-Reply-To: <20070826110841.GA31243@falcon.net.t-labs.tu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Network problems with sendto() syscall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 19:09:42 -0000 I strongly suspect this is related to an introduced bug in the RTM_CHANGE path. Please run 'route -nv monitor' in its own shell and monitor its output while you run bootpd. If the problem happens after RTM_CHANGE then it is probably the bug that cognet found, it has a very simple fix which just needs to be committed ie above line 531 in rtsock.c: if ((rt->rt_flags & RTF_LLINFO) == 0) regards, BMS From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 20:25:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32FD216A419 for ; Sun, 26 Aug 2007 20:25:34 +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 DEE4413C458 for ; Sun, 26 Aug 2007 20:25:33 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IPOfm-0003WA-NI for freebsd-current@freebsd.org; Sun, 26 Aug 2007 22:25:26 +0200 Received: from 78-1-97-234.adsl.net.t-com.hr ([78.1.97.234]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Aug 2007 22:25:26 +0200 Received: from ivoras by 78-1-97-234.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Aug 2007 22:25:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 26 Aug 2007 22:24:57 +0200 Lines: 36 Message-ID: References: <200708261948.05750.qpadla@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62CE327FDBF163601DB9A122" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-97-234.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <200708261948.05750.qpadla@gmail.com> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Aug 2007 20:25:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62CE327FDBF163601DB9A122 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nikolay Pavlov wrote: > Is this similar as this one? > http://docs.freebsd.org/cgi/mid.cgi?200708202327.03951.qpadla No: - it happens with and without gjournal - it happens during "regular" system usage during IO intensive periods It looks like a UFS corruption: as I said, I was able to provoke it regularly by doing heavy IO on a clean newfs-ed file system (I can't after an update to a newer kernel+world, now it seems to happen randomly)= =2E --------------enig62CE327FDBF163601DB9A122 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 iD8DBQFG0eGjldnAQVacBcgRAhxmAJ9EjkxXWMsN/aYaMK2HPaSSQLhVPwCdEPR2 2FxklQ+SuzEOcgY5nbcN3fQ= =Zm1a -----END PGP SIGNATURE----- --------------enig62CE327FDBF163601DB9A122-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 04:25:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1AD216A417 for ; Mon, 27 Aug 2007 04:25:44 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB0213C45D for ; Mon, 27 Aug 2007 04:25:44 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IPWAV-00049X-0m for freebsd-current@freebsd.org; Mon, 27 Aug 2007 13:25:39 +0900 Message-ID: <46D25242.10504@micom.mng.net> Date: Mon, 27 Aug 2007 12:25:38 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 04:25:44 -0000 Hi, I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS enabled kernel. daemon# uname -an FreeBSD daemon.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Thu Aug 23 17:59:17 ULAT 2007 tsgan@daemon.micom.mng.net:/usr/obj/usr/src/sys/GDAEMON i386 daemon# When compiling something (buildworld or making wine for example) inside from X/gnome my computer becomes very slow. top shows while compiling wine: last pid: 38660; load averages: 3.10, 2.24, 1.33 up 3+02:07:05 12:11:38 106 processes: 3 running, 102 sleeping, 1 zombie CPU states: 90.2% user, 0.0% nice, 9.8% system, 0.0% interrupt, 0.0% idle Mem: 704M Active, 63M Inact, 168M Wired, 39M Cache, 111M Buf, 21M Free Swap: 2048M Total, 195M Used, 1853M Free, 9% Inuse PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 902 tsgan 1 96 0 147M 134M RUN 929:41 3.96% Xorg 38659 root 1 96 0 15556K 12256K RUN 0:00 3.47% cc1 1206 tsgan 1 44 19 156M 36940K select 178:06 0.00% operapluginwrapper 978 tsgan 1 44 0 212M 173M select 103:26 0.00% opera 954 tsgan 1 44 0 35236K 18372K select 11:59 0.00% wnck-applet 975 tsgan 7 44 0 198M 159M ucond 8:53 0.00% thunderbird-bin 922 tsgan 1 44 0 4808K 1460K select 4:43 0.00% gam_server 956 tsgan 1 44 0 35324K 16328K select 4:36 0.00% mixer_applet2 962 tsgan 1 44 0 13736K 5936K select 1:57 0.00% gnome-screensaver 1224 tsgan 1 44 0 70232K 28900K select 1:33 0.00% pidgin 1591 tsgan 1 44 19 5520K 772K select 1:17 0.00% operapluginwrapper 772 root 1 44 0 4496K 928K select 1:03 0.00% hald-addon-storage 930 tsgan 1 44 0 16204K 8744K select 0:48 0.00% metacity 441 root 1 44 0 3276K 592K select 0:45 0.00% moused 765 haldaemon 1 44 0 6164K 2252K select 0:41 0.00% hald ... Is it due to SCHED_ULE makes a process CPU greedy and that is why my computer becomes slow? Or it is something else? What SCHED_ULE sysctl knobs should I test here? As I recall correctly I have never experienced such problems until recently. Maybe I'm wrong here. thanks, Ganbold -- X windows: Accept any substitute. If it's broke, don't fix it. If it ain't broke, fix it. Form follows malfunction. The Cutting Edge of Obsolescence. The trailing edge of software technology. Armageddon never looked so good. Japan's secret weapon. You'll envy the dead. Making the world safe for competing window systems. Let it get in YOUR way. The problem for your problem. If it starts working, we'll fix it. Pronto. It could be worse, but it'll take time. Simplicity made complex. The greatest productivity aid since typhoid. Flakey and built to stay that way. One thousand monkeys. One thousand MicroVAXes. One thousand years. X windows. From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 04:35:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F257716A417 for ; Mon, 27 Aug 2007 04:35:59 +0000 (UTC) (envelope-from SRS0=d1fe45abe319685a9442494ac1a0fc6804f994ad=439=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 BDE0E13C46A for ; Mon, 27 Aug 2007 04:35:57 +0000 (UTC) (envelope-from SRS0=d1fe45abe319685a9442494ac1a0fc6804f994ad=439=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 GMK80756; Sun, 26 Aug 2007 21:35:56 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 496A945048; Sun, 26 Aug 2007 21:35:56 -0700 (PDT) To: Ganbold In-Reply-To: Your message of "Mon, 27 Aug 2007 12:25:38 +0800." <46D25242.10504@micom.mng.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1188189356_93527P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 26 Aug 2007 21:35:56 -0700 From: "Kevin Oberman" Message-Id: <20070827043556.496A945048@ptavv.es.net> Cc: "freebsd-current@freebsd.org" Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 04:36:00 -0000 --==_Exmh_1188189356_93527P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Mon, 27 Aug 2007 12:25:38 +0800 > From: Ganbold > Sender: owner-freebsd-current@freebsd.org > > Hi, > > I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS > enabled kernel. > > daemon# uname -an > FreeBSD daemon.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Thu Aug > 23 17:59:17 ULAT 2007 > tsgan@daemon.micom.mng.net:/usr/obj/usr/src/sys/GDAEMON i386 > daemon# > > When compiling something (buildworld or making wine for example) inside > from X/gnome > my computer becomes very slow. > > top shows while compiling wine: > > last pid: 38660; load averages: 3.10, 2.24, > 1.33 > up 3+02:07:05 12:11:38 > 106 processes: 3 running, 102 sleeping, 1 zombie > CPU states: 90.2% user, 0.0% nice, 9.8% system, 0.0% interrupt, 0.0% > idle > Mem: 704M Active, 63M Inact, 168M Wired, 39M Cache, 111M Buf, 21M Free > Swap: 2048M Total, 195M Used, 1853M Free, 9% Inuse > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 902 tsgan 1 96 0 147M 134M RUN 929:41 3.96% Xorg > 38659 root 1 96 0 15556K 12256K RUN 0:00 3.47% cc1 > 1206 tsgan 1 44 19 156M 36940K select 178:06 0.00% > operapluginwrapper > 978 tsgan 1 44 0 212M 173M select 103:26 0.00% opera > 954 tsgan 1 44 0 35236K 18372K select 11:59 0.00% > wnck-applet > 975 tsgan 7 44 0 198M 159M ucond 8:53 0.00% > thunderbird-bin > 922 tsgan 1 44 0 4808K 1460K select 4:43 0.00% gam_server > 956 tsgan 1 44 0 35324K 16328K select 4:36 0.00% > mixer_applet2 > 962 tsgan 1 44 0 13736K 5936K select 1:57 0.00% > gnome-screensaver > 1224 tsgan 1 44 0 70232K 28900K select 1:33 0.00% pidgin > 1591 tsgan 1 44 19 5520K 772K select 1:17 0.00% > operapluginwrapper > 772 root 1 44 0 4496K 928K select 1:03 0.00% > hald-addon-storage > 930 tsgan 1 44 0 16204K 8744K select 0:48 0.00% metacity > 441 root 1 44 0 3276K 592K select 0:45 0.00% moused > 765 haldaemon 1 44 0 6164K 2252K select 0:41 0.00% hald > ... > > Is it due to SCHED_ULE makes a process CPU greedy and that is why my > computer becomes slow? > Or it is something else? What SCHED_ULE sysctl knobs should I test here? > As I recall correctly I have never experienced such problems until > recently. > Maybe I'm wrong here. I've seen it for a while. You are running out of RAM and I have found that once the swap use starts growing, things get VERY slow. I still think something is wrong, but memory is cheap and an extra 1/2 Gig can make a huge difference. I have not seen any difference between schedulers...about the same with 4BSD and ULE. -- 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_1188189356_93527P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG0lSskn3rs5h7N1ERAvRsAJ0bTjGmAfGZs7BSNJxDcfgkMmf40QCdGyrY sZ55Y/59kbMyyQWpuCcMy9g= =LXyY -----END PGP SIGNATURE----- --==_Exmh_1188189356_93527P-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 04:42:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE1D216A419 for ; Mon, 27 Aug 2007 04:42:30 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id EBCAF13C45A for ; Mon, 27 Aug 2007 04:42:27 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IPWQi-0004Ee-K2; Mon, 27 Aug 2007 13:42:24 +0900 Message-ID: <46D25630.1060506@micom.mng.net> Date: Mon, 27 Aug 2007 12:42:24 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: Kevin Oberman References: <20070827043556.496A945048@ptavv.es.net> In-Reply-To: <20070827043556.496A945048@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-current@freebsd.org" Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 04:42:30 -0000 Kevin Oberman wrote: >> Date: Mon, 27 Aug 2007 12:25:38 +0800 >> From: Ganbold >> Sender: owner-freebsd-current@freebsd.org >> >> Hi, >> >> I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS >> enabled kernel. >> >> daemon# uname -an >> FreeBSD daemon.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Thu Aug >> 23 17:59:17 ULAT 2007 >> tsgan@daemon.micom.mng.net:/usr/obj/usr/src/sys/GDAEMON i386 >> daemon# >> >> When compiling something (buildworld or making wine for example) inside >> from X/gnome >> my computer becomes very slow. >> >> top shows while compiling wine: >> >> last pid: 38660; load averages: 3.10, 2.24, >> 1.33 >> up 3+02:07:05 12:11:38 >> 106 processes: 3 running, 102 sleeping, 1 zombie >> CPU states: 90.2% user, 0.0% nice, 9.8% system, 0.0% interrupt, 0.0% >> idle >> Mem: 704M Active, 63M Inact, 168M Wired, 39M Cache, 111M Buf, 21M Free >> Swap: 2048M Total, 195M Used, 1853M Free, 9% Inuse >> >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >> 902 tsgan 1 96 0 147M 134M RUN 929:41 3.96% Xorg >> 38659 root 1 96 0 15556K 12256K RUN 0:00 3.47% cc1 >> 1206 tsgan 1 44 19 156M 36940K select 178:06 0.00% >> operapluginwrapper >> 978 tsgan 1 44 0 212M 173M select 103:26 0.00% opera >> 954 tsgan 1 44 0 35236K 18372K select 11:59 0.00% >> wnck-applet >> 975 tsgan 7 44 0 198M 159M ucond 8:53 0.00% >> thunderbird-bin >> 922 tsgan 1 44 0 4808K 1460K select 4:43 0.00% gam_server >> 956 tsgan 1 44 0 35324K 16328K select 4:36 0.00% >> mixer_applet2 >> 962 tsgan 1 44 0 13736K 5936K select 1:57 0.00% >> gnome-screensaver >> 1224 tsgan 1 44 0 70232K 28900K select 1:33 0.00% pidgin >> 1591 tsgan 1 44 19 5520K 772K select 1:17 0.00% >> operapluginwrapper >> 772 root 1 44 0 4496K 928K select 1:03 0.00% >> hald-addon-storage >> 930 tsgan 1 44 0 16204K 8744K select 0:48 0.00% metacity >> 441 root 1 44 0 3276K 592K select 0:45 0.00% moused >> 765 haldaemon 1 44 0 6164K 2252K select 0:41 0.00% hald >> ... >> >> Is it due to SCHED_ULE makes a process CPU greedy and that is why my >> computer becomes slow? >> Or it is something else? What SCHED_ULE sysctl knobs should I test here? >> As I recall correctly I have never experienced such problems until >> recently. >> Maybe I'm wrong here. >> > > I've seen it for a while. You are running out of RAM and I have found > that once the swap use starts growing, things get VERY slow. I still > think something is wrong, but memory is cheap and an extra 1/2 Gig can > make a huge difference. At first I thought about that. But I have 1GB memory and as I remember I hadn't such problems when I was running RELENG_6. Wine compile is still running and top shows: last pid: 46408; load averages: 1.90, 2.31, 2.11 up 3+02:31:42 12:36:15 107 processes: 3 running, 103 sleeping, 1 zombie CPU states: 94.7% user, 0.0% nice, 5.3% system, 0.0% interrupt, 0.0% idle Mem: 656M Active, 89M Inact, 183M Wired, 37M Cache, 111M Buf, 29M Free Swap: 2048M Total, 321M Used, 1727M Free, 15% Inuse PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 46406 root 1 110 0 122M 120M RUN 0:11 66.26% cc1 902 tsgan 1 47 0 139M 122M select 931:51 6.40% Xorg 962 tsgan 1 44 0 13736K 5780K select 1:59 0.59% gnome-screensaver 975 tsgan 8 44 0 186M 141M ucond 9:30 0.29% thunderbird-bin 954 tsgan 1 44 0 35236K 17328K select 12:02 0.10% wnck-applet 46408 root 1 44 0 3524K 1500K RUN 0:00 0.10% top 1206 tsgan 1 44 19 156M 8480K RUN 178:52 0.00% operapluginwrapper 978 tsgan 1 44 0 212M 144M select 104:21 0.00% opera 922 tsgan 1 44 0 4808K 1340K select 4:45 0.00% gam_server 956 tsgan 1 44 0 35324K 15128K select 4:38 0.00% mixer_applet2 1224 tsgan 1 44 0 70232K 24344K select 1:34 0.00% pidgin 1591 tsgan 1 44 19 5520K 740K select 1:17 0.00% operapluginwrapper 772 root 1 44 0 4496K 892K select 1:04 0.00% hald-addon-storage 1119 tsgan 2 -8 0 210M 172M piperd 0:57 0.00% gnome-terminal 930 tsgan 1 44 0 16204K 8376K select 0:51 0.00% metacity 441 root 1 44 0 3276K 584K select 0:48 0.00% moused ... > I have not seen any difference between > schedulers...about the same with 4BSD and ULE. > I see. thanks. Ganbold -- The USA is so enormous, and so numerous are its schools, colleges and religious seminaries, many devoted to special religious beliefs ranging from the unorthodox to the dotty, that we can hardly wonder at its yielding a more bounteous harvest of gobbledygook than the rest of the world put together. -- Sir Peter Medawar From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 04:44:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D337716A417 for ; Mon, 27 Aug 2007 04:44:40 +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 6BBC513C483 for ; Mon, 27 Aug 2007 04:44:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IPWSk-000Djn-Au for freebsd-current@freebsd.org; Mon, 27 Aug 2007 07:44:38 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7R4iQWa024674; Mon, 27 Aug 2007 07:44:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l7R4iQ2J024673; Mon, 27 Aug 2007 07:44:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 Aug 2007 07:44:23 +0300 From: Kostik Belousov To: Kevin Oberman Message-ID: <20070827044423.GM2332@deviant.kiev.zoral.com.ua> References: <46D25242.10504@micom.mng.net> <20070827043556.496A945048@ptavv.es.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Mh8CTEa8Ax54aLHp" Content-Disposition: inline In-Reply-To: <20070827043556.496A945048@ptavv.es.net> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 69ad68b945e79e087f1af101bf3fefec X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1404 [August 24 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Ganbold , "freebsd-current@freebsd.org" Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 04:44:41 -0000 --Mh8CTEa8Ax54aLHp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 26, 2007 at 09:35:56PM -0700, Kevin Oberman wrote: > > Date: Mon, 27 Aug 2007 12:25:38 +0800 > > From: Ganbold > > Sender: owner-freebsd-current@freebsd.org > >=20 > > Hi, > >=20 > > I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS=20 > > enabled kernel. > >=20 > > daemon# uname -an > > FreeBSD daemon.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Thu Au= g=20 > > 23 17:59:17 ULAT 2007 =20 > > tsgan@daemon.micom.mng.net:/usr/obj/usr/src/sys/GDAEMON i386 > > daemon# > >=20 > > When compiling something (buildworld or making wine for example) inside= =20 > > from X/gnome > > my computer becomes very slow. > >=20 > > top shows while compiling wine: > >=20 > > last pid: 38660; load averages: 3.10, 2.24, =20 > > 1.33 = =20 > > up 3+02:07:05 12:11:38 > > 106 processes: 3 running, 102 sleeping, 1 zombie > > CPU states: 90.2% user, 0.0% nice, 9.8% system, 0.0% interrupt, 0.0= %=20 > > idle > > Mem: 704M Active, 63M Inact, 168M Wired, 39M Cache, 111M Buf, 21M Free > > Swap: 2048M Total, 195M Used, 1853M Free, 9% Inuse > >=20 > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMA= ND > > 902 tsgan 1 96 0 147M 134M RUN 929:41 3.96% Xorg > > 38659 root 1 96 0 15556K 12256K RUN 0:00 3.47% cc1 > > 1206 tsgan 1 44 19 156M 36940K select 178:06 0.00%=20 > > operapluginwrapper > > 978 tsgan 1 44 0 212M 173M select 103:26 0.00% opera > > 954 tsgan 1 44 0 35236K 18372K select 11:59 0.00%=20 > > wnck-applet > > 975 tsgan 7 44 0 198M 159M ucond 8:53 0.00%=20 > > thunderbird-bin > > 922 tsgan 1 44 0 4808K 1460K select 4:43 0.00% gam_s= erver > > 956 tsgan 1 44 0 35324K 16328K select 4:36 0.00%=20 > > mixer_applet2 > > 962 tsgan 1 44 0 13736K 5936K select 1:57 0.00%=20 > > gnome-screensaver > > 1224 tsgan 1 44 0 70232K 28900K select 1:33 0.00% pidgin > > 1591 tsgan 1 44 19 5520K 772K select 1:17 0.00%=20 > > operapluginwrapper > > 772 root 1 44 0 4496K 928K select 1:03 0.00%=20 > > hald-addon-storage > > 930 tsgan 1 44 0 16204K 8744K select 0:48 0.00% metac= ity > > 441 root 1 44 0 3276K 592K select 0:45 0.00% moused > > 765 haldaemon 1 44 0 6164K 2252K select 0:41 0.00% hald > > ... > >=20 > > Is it due to SCHED_ULE makes a process CPU greedy and that is why my=20 > > computer becomes slow? > > Or it is something else? What SCHED_ULE sysctl knobs should I test here? > > As I recall correctly I have never experienced such problems until=20 > > recently. > > Maybe I'm wrong here. >=20 > I've seen it for a while. You are running out of RAM and I have found > that once the swap use starts growing, things get VERY slow. I still > think something is wrong, but memory is cheap and an extra 1/2 Gig can > make a huge difference. I have not seen any difference between > schedulers...about the same with 4BSD and ULE. No, this happens on the machine with a plenty of free RAM too, for instance Mem: 187M Active, 868M Inact, 162M Wired, 20M Cache, 112M Buf, 764M Free Swap: 8192M Total, 8192M Free SCHED_4BSD was almost unusable for me, SCHED_ULE gives somewhat better interactivity. It seems that fork() gives too high priority for the new process. --Mh8CTEa8Ax54aLHp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG0lanC3+MBN1Mb4gRAun2AKDx8rHQnBCUMKwaX9QCpoxVG3j7gQCgv70j 3cEn4ptKM1shRXgiFVd9Mvk= =quPz -----END PGP SIGNATURE----- --Mh8CTEa8Ax54aLHp-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 05:29:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB03616A418 for ; Mon, 27 Aug 2007 05:29:24 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.freebsd.org (Postfix) with ESMTP id A59A813C468 for ; Mon, 27 Aug 2007 05:29:24 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2007 22:29:25 -0700 X-IronPort-AV: i="4.19,310,1183359600"; d="scan'208"; a="394642455:sNHT44563162" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7R5TO90024261 for ; Sun, 26 Aug 2007 22:29:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7R5TOxl020767 for ; Mon, 27 Aug 2007 05:29:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Aug 2007 22:29:23 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Aug 2007 22:29:23 -0700 Message-ID: <46D2613D.8090707@cisco.com> Date: Mon, 27 Aug 2007 01:29:33 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: FreeBSD Current References: <46CE49F0.9070204@cisco.com> In-Reply-To: <46CE49F0.9070204@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 05:29:23.0682 (UTC) FILETIME=[3A130C20:01C7E86B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1117; t=1188192564; x=1189056564; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Crash=20when=20we=20wakeup=20from=20a=20sleep=20on=20 IBM=20T43 |Sender:=20; bh=GpbhCzZqHH2Hl7BPDHZ+iktuqj0ZHfFhNovkBX58HYw=; b=Dvb6usczy3fXDarsBj+sFeSfTAmoVQlNSWv3XtGNscqBJQKn9naBfj8eNi/WJXmbgTd9F83/ 6E1EFHa9d9oQqzicxDYAHomINHSVSh1J/p4C2F8bn8caOKLj81COfkyI; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Subject: Re: Crash when we wakeup from a sleep on IBM T43 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 05:29:25 -0000 Ok all.. Kip and I just figured it out :-D If you have WITNESS on this crash shows up.. if WITNESS is off.. it does not.. This mtx needs to be made recursive at least in the short term... R Randall Stewart wrote: > Hi all: > > Ok I can easily reproduce this.. and I have pinpointed at least > one of the culprits.. > > witness says its: > > recursed on non-recursive lock in OsdSync.c line 377 acpi subsystem... > > You can find here (thanks to fellow sctp-interop participants) jpegs > of the crash and a picture of a ddb> trace > > The crash: > http://www.sctp.org/sleep_crash1.jpg > > The trace: > > http://www.sctp.org/sleep_crash2.jpg > > Would someone who owns the acpi subsystem take a look > at this.. and if you need more info, it would be good to > hear from you.. I can do DDB commands if you want more info > and at the interop until tommorrow I have access to a D200 > to actually take photos of it... or of course there > is the manual transcribe :-0 > > R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 06:14:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3632016A418 for ; Mon, 27 Aug 2007 06:14:04 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate2.pacific.net.sg (smtpgate2.pacific.net.sg [203.120.90.32]) by mx1.freebsd.org (Postfix) with SMTP id 6302A13C442 for ; Mon, 27 Aug 2007 06:14:02 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: (qmail 22539 invoked from network); 27 Aug 2007 05:47:21 -0000 Received: from adsl223.dyn229.pacific.net.sg (HELO P2120.somewherefaraway.com) (oceanare@210.24.229.223) by smtpgate2.pacific.net.sg with ESMTPA; 27 Aug 2007 05:47:20 -0000 Message-ID: <46D26550.3030603@pacific.net.sg> Date: Mon, 27 Aug 2007 13:46:56 +0800 From: Erich Dollansky User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: Ganbold References: <20070827043556.496A945048@ptavv.es.net> <46D25630.1060506@micom.mng.net> In-Reply-To: <46D25630.1060506@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 06:14:04 -0000 Hi, Ganbold wrote: > Kevin Oberman wrote: >>> Date: Mon, 27 Aug 2007 12:25:38 +0800 >>> From: Ganbold >>> Sender: owner-freebsd-current@freebsd.org >>> >>> my computer becomes very slow. >>> >>> top shows while compiling wine: >>> >>> last pid: 38660; load averages: 3.10, 2.24, >>> 1.33 >>> up 3+02:07:05 12:11:38 >>> 106 processes: 3 running, 102 sleeping, 1 zombie >>> CPU states: 90.2% user, 0.0% nice, 9.8% system, 0.0% interrupt, >>> 0.0% idle >>> Mem: 704M Active, 63M Inact, 168M Wired, 39M Cache, 111M Buf, 21M Free >>> Swap: 2048M Total, 195M Used, 1853M Free, 9% Inuse >>> >>> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU >>> COMMAND >>> 902 tsgan 1 96 0 147M 134M RUN 929:41 3.96% Xorg You have an uuptime of some three days but Xorg took already 929 minutes of CPU time? Also, we a load average of three and more while 0% idle time, every machine must be slow. It also indicates that swapping is not the problem as swapping should not affect the CPU. As long as the load average is this high, the machine will feel slow. This is normal. You might find somebody who knows why Xorg does this strange thing. Erich From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 07:08:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 198B416A41B for ; Mon, 27 Aug 2007 07:08:03 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD0D13C465 for ; Mon, 27 Aug 2007 07:08:02 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1103039nfb for ; Mon, 27 Aug 2007 00:08:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=JW+QpKNwNMCrkO14nH0R6/l97eChYJscjb2HCs0z7mhjgV84ekHDJ/8sDqvA90PAKwHRLjtgIyquRlmNf7nhl6mmXLOdToF5IaSjk7fXZy5Ssm9gY0V9LhbuL4fL4AKpcLnzAlLO+tvwMAHj6i6TNpmvtet7mbk3tgNIH2rjJDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sV2+FONGUX0xRmLj03Thsa9otArNpGMbaYfdk/FWZWFlp+OYjGeETcX+lNWKrNBwDr4W2doGXl3dVyYtjK3j7HOrH2ojJtKE+1FJd3GLD0RXbJCqrN0yc1pcCHlewc6SqmFhqK1B7ovILYrS4PY3yw4Fuev2NRe+pbMky44n1oQ= Received: by 10.78.170.6 with SMTP id s6mr3606004hue.1188198480693; Mon, 27 Aug 2007 00:08:00 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Mon, 27 Aug 2007 00:08:00 -0700 (PDT) Message-ID: Date: Mon, 27 Aug 2007 00:08:00 -0700 From: "Kip Macy" To: "Andrew Turner" In-Reply-To: <20070826232326.6e27eb49@hermies.int.fubar.geek.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070824181627.57bed401@hermies.int.fubar.geek.nz> <20070824132409.W3900@fledge.watson.org> <20070826000708.15fbb5bb@hermies.int.fubar.geek.nz> <20070826232326.6e27eb49@hermies.int.fubar.geek.nz> Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: FreeBSD on xen hvm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 07:08:03 -0000 On 8/26/07, Andrew Turner wrote: > On Sat, 25 Aug 2007 10:41:09 -0700 > "Kip Macy" wrote: > > > Have you tried gdbserver? > > > > -Kip > I've got the Xen gdbserver running and I've patched kgdb to attach via > tcp. I'm currently working on getting a copy of kgdb that can accept > the amd64 registers gdbserver sends. My understanding id kgdb detects > the architecture from the kernel file. In this case it will be wrong as > the kernel is i386 but the arch is amd64. Regular GDB works and is easy enough to cross-build - I actually never used kgdb with gdbserver. The only thing that will go wrong is that it will not correctly parse trapframes. -Kip From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 08:21:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A160216A4DA for ; Mon, 27 Aug 2007 08:21:56 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 40BAC13C46A for ; Mon, 27 Aug 2007 08:21:55 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe06.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 591722129 for freebsd-current@freebsd.org; Mon, 27 Aug 2007 09:21:53 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 27 Aug 2007 09:22:05 +0200 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: <200708270922.06233.hselasky@c2i.net> Subject: Ports and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 08:21:56 -0000 Hi, When you install a port that has several sub-ports, is there way to run through all the configuration menus recursivly, so that the compilation does not stop all the time asking for user input? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 08:30:20 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0613E16A417 for ; Mon, 27 Aug 2007 08:30:20 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4F513C457 for ; Mon, 27 Aug 2007 08:30:19 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4C32B45E90; Mon, 27 Aug 2007 10:08:30 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1B6374569A; Mon, 27 Aug 2007 10:08:24 +0200 (CEST) Date: Mon, 27 Aug 2007 10:07:19 +0200 From: Pawel Jakub Dawidek To: Nikolay Pavlov Message-ID: <20070827080719.GA29854@garage.freebsd.pl> References: <200708202327.03951.qpadla@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <200708202327.03951.qpadla@gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: Crash in todays current (panic: bio_caller1 used by the provider ad0s4e) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 08:30:20 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 20, 2007 at 11:26:59PM +0300, Nikolay Pavlov wrote: > Another one panic caused by geom_journal journal initialization (sorry fo= r=20 > tautology) at the final stage of EVERY kernel booting process. >=20 > I am unable to get a full crashdump because my dump device is not ready a= t=20 > that moment. >=20 > I see the message: > panic: bio_caller1 used by the provider ad0s4e >=20 > And a backtrace like this one: > kdb_enter > panic > g_io_deliver > g_std_done > biodone > g_io_schedule_up > g_up_procbody > fork_exit > fork_trempoline >=20 > And the current thread is pid 3 "g_up" >=20 > The intresting thing is that i do not have this panic with GENERIC kernel. > My kernel is deffer from it by this lines: > #!commented! options WITNESS_SKIPSPIN > options DEBUG_LOCKS > options DEBUG_VFS_LOCKS > options DIAGNOSTIC=20 I know about this. The assertion I added some time ago is too strong in case of gjournal. Gjournal can modify bio_caller1 for in-flight bios from another thread, and the assertion doesn't and can't really take that into an account. The assertion should be removed, pity, because it's still useful for other GEOM classes. To make your system usable, remove DIAGNOSTIC from your kernel configuration. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG0oY3ForvXbEpPzQRAh0TAJ9VJIQqbtL8M+g1sD1LQR2la1zE3ACeLW3s nNrrBVKOnEZWg3MREHiih7c= =QaVe -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 09:01:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A7F16A418 for ; Mon, 27 Aug 2007 09:01:27 +0000 (UTC) (envelope-from john_m_cooper@yahoo.com) Received: from smtp103.biz.mail.mud.yahoo.com (smtp103.biz.mail.mud.yahoo.com [68.142.200.238]) by mx1.freebsd.org (Postfix) with SMTP id CFE5813C459 for ; Mon, 27 Aug 2007 09:01:26 +0000 (UTC) (envelope-from john_m_cooper@yahoo.com) Received: (qmail 57634 invoked from network); 27 Aug 2007 08:34:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:OpenPGP:Content-Type:Content-Transfer-Encoding; b=zpagnq2Cg+Av+gvEaXoqmOtLXjmD2qEf0UNCtSVjOUgAVAljfm1S0zfxOmgXd0qYeXwioecS9POLS7xi/p9QKNR+AMUr+SBz4dgQrc7HjhTGQeRAxTbTy3G8aTWI4XUZNVcCfJ92XJE30NB3ebnqCCvgrlvhb/oODshF3jutuiQ= ; Received: from unknown (HELO borgdemon2.resnet.wsu.edu) (j.m.cooper@borgsdemons.com@134.121.241.227 with login) by smtp103.biz.mail.mud.yahoo.com with SMTP; 27 Aug 2007 08:34:45 -0000 X-YMail-OSG: NzRkPIEVM1k8laCiCGmYIDuzzjGqeRoe0YhF3dEPznz9A9bKWmYPKZPhhFDteGmONtc_6MzdvxZmLIYpcDpLlqhl4AH2Ht.BzB2vdwzv7wtWbaELcCtZyNQmqMwOPg-- Received: from borgdemon2.resnet.wsu.edu (localhost [127.0.0.1]) by borgdemon2.resnet.wsu.edu (Postfix) with ESMTP id AF1F35C9B; Mon, 27 Aug 2007 01:34:42 -0700 (PDT) Message-ID: <46D28CA1.6010207@yahoo.com> Date: Mon, 27 Aug 2007 01:34:41 -0700 From: John Merryweather Cooper User-Agent: Thunderbird 2.0.0.4pre (X11/20070807) MIME-Version: 1.0 To: Hans Petter Selasky References: <200708270922.06233.hselasky@c2i.net> In-Reply-To: <200708270922.06233.hselasky@c2i.net> X-Enigmail-Version: 0.95.2 OpenPGP: id=DFEB4F48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Ports and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 09:01:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes. Install port-mgmt/portmaster and then run portmaster for the desired port. Any port or sub-port not already configured will have a 'make config' run on it before the build starts. jmc Hans Petter Selasky wrote: > Hi, > > When you install a port that has several sub-ports, is there way to run > through all the configuration menus recursivly, so that the compilation does > not stop all the time asking for user input? > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0oyhpwq+q9/rT0gRAnSJAJkBvgHiItR6zliD/OuqXsykjrXMYgCfT/Tf jz7JpLrg5swbD9jEGAktz64= =4vY0 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 10:47:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AF5D16A418 for ; Mon, 27 Aug 2007 10:47:40 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:0:206:5bff:fef8:267d]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB3D13C48A for ; Mon, 27 Aug 2007 10:47:40 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id 897C01CC51; Mon, 27 Aug 2007 12:47:38 +0200 (CEST) Date: Mon, 27 Aug 2007 12:47:38 +0200 From: Erwin Lansing To: Hans Petter Selasky Message-ID: <20070827104738.GX93965@droso.net> Mail-Followup-To: Hans Petter Selasky , freebsd-current@freebsd.org References: <200708270922.06233.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p5BJhDJf0owydRUK" Content-Disposition: inline In-Reply-To: <200708270922.06233.hselasky@c2i.net> X-Operating-System: FreeBSD/i386 6.2-STABLE User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: Ports and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 10:47:40 -0000 --p5BJhDJf0owydRUK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2007 at 09:22:05AM +0200, Hans Petter Selasky wrote: > Hi, >=20 > When you install a port that has several sub-ports, is there way to run= =20 > through all the configuration menus recursivly, so that the compilation d= oes=20 > not stop all the time asking for user input? >=20 There is a config-recursive target in ports, so a simple 'make config-recursive' in the master port should do the trick for you. Best, -erwin --=20 Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_/// erwin@FreeBSD.org And it makes you cry. <____) (____> erwin@aauug.dk --p5BJhDJf0owydRUK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG0qvKqy9aWxUlaZARAmiMAKDnjl68HvBXiVYZ62VqWE9bZn+U4gCggzhR KRSlIW5+Gd2QzigL+Rklj9M= =0c1O -----END PGP SIGNATURE----- --p5BJhDJf0owydRUK-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 10:48:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2001E16A41B for ; Mon, 27 Aug 2007 10:48:11 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id A6F4213C467 for ; Mon, 27 Aug 2007 10:48:10 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so2028794mue for ; Mon, 27 Aug 2007 03:48:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=fm/1xXOxnzxJfqFtw/9QURPRhLUX3HMA+KbGhbZ5BGMCecc23DFpP/jAMvt9yLcnKl7+46MGBHF/WWpEQoFV8xwog3KEH/VDCMTRNL91D0xcsG3JFyidQhk7AaLJspY2a44xjwXPPnQjVFlc9EFjC0XTOWOpunr07WbxlYRQQoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=BqX9wCvR6KNX6vaZKz6uFl6mZqInTZsZjdeJX6bF38UzllHfH8hDm+k2qFmrkl5/LJEcebxBo6BdmmI4gkgzVrCOfvfSwC4MoJpp9FUqQ4gDzArtPBOq0D637iKDKlk0W1rMcq28xt6VyHS/95LzV3iP6TdyCh3B6sNlIumi278= Received: by 10.86.57.9 with SMTP id f9mr4832570fga.1188211688858; Mon, 27 Aug 2007 03:48:08 -0700 (PDT) Received: from fairy.alashan.de ( [79.196.52.140]) by mx.google.com with ESMTPS id k29sm3900348fkk.2007.08.27.03.48.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Aug 2007 03:48:08 -0700 (PDT) Message-ID: <46D2C812.8090106@gmail.com> Date: Mon, 27 Aug 2007 12:48:18 +0000 From: Christian Walther User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Encrypted 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, 27 Aug 2007 10:48:11 -0000 Hello list, I'm currently using a zraid consisting of three drives. Lately I wonder what the best way would be to encrypt it. I read the chapter dealing with disk encryption in the handbook, and decided to use GELI. Is there anyone here on the list who has some experiences with ZFS on encrypted GELI devices? Are there some performance specs around? And what is even more important: What is the best of moving the zraid to encrypted devices? I can't remove one of the disks because they are in use. So I figure one way would be to buy another disk, set up encryption and add it to the pool. I could then remove one disk after the other, encrypt it, remove the (now broken one) from the zpool, and add the newly encrypted device. Since buying disks costs money I wonder how save it would be to follow this procedure without adding a new disk. From my point of view I'll loose redundancy as soon as I remove one of the three disks. But is there another problem or something dangerous I don't see her? Regards Christian From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 10:58:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 801BF16A419 for ; Mon, 27 Aug 2007 10:58:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC3513C46C for ; Mon, 27 Aug 2007 10:58:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1IPcIH-000Cya-0v for freebsd-current@freebsd.org; Mon, 27 Aug 2007 13:58:05 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Aug 2007 13:58:04 +0300 From: Danny Braniss Message-ID: Subject: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 10:58:06 -0000 Since noone is complaining, this must be an oversite on my part, but echo 'ABC'|sed 's/a/z/' results in zBC what did i miss? thanks, danny From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 11:11:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0903716A418 for ; Mon, 27 Aug 2007 11:11:02 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 9697E13C4CC for ; Mon, 27 Aug 2007 11:10:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A555D1.dip.t-dialin.net [84.165.85.209]) by redbull.bpaserver.net (Postfix) with ESMTP id 67DC62E133; Mon, 27 Aug 2007 13:10:48 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id D2FF95B4D81; Mon, 27 Aug 2007 13:10:45 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l7RBAjMN079598; Mon, 27 Aug 2007 13:10:45 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 27 Aug 2007 13:10:45 +0200 Message-ID: <20070827131045.6jv7qrdlw0wg0sos@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 27 Aug 2007 13:10:45 +0200 From: Alexander Leidinger To: Danny Braniss References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 11:11:02 -0000 Quoting Danny Braniss (from Mon, 27 Aug 2007 13:58:04 +0300): > Since noone is complaining, this must be an oversite on my part, but > echo 'ABC'|sed 's/a/z/' > results in > zBC > what did i miss? An update from an old -current to a recent -current (this was a temporary bug after a change to sed). Bye, Alexander. -- Among all savage beasts, none is found so harmful as woman. -- St. John Chrysostom, 304-407. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 11:11:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FD3B16A418 for ; Mon, 27 Aug 2007 11:11:55 +0000 (UTC) (envelope-from dan@danneh.org) Received: from aqua.bluespider.org (aqua.bluespider.org [69.46.20.18]) by mx1.freebsd.org (Postfix) with ESMTP id 201D313C4A7 for ; Mon, 27 Aug 2007 11:11:55 +0000 (UTC) (envelope-from dan@danneh.org) Received: from danneh1.demon.co.uk ([80.176.139.236] helo=shiver.bluespider.org) by aqua.bluespider.org with esmtpa (Exim 4.62) (envelope-from ) id 1IPcVa-000EFq-7z; Mon, 27 Aug 2007 12:11:50 +0100 Message-ID: <46D2B178.8030907@danneh.org> Date: Mon, 27 Aug 2007 12:11:52 +0100 From: Dan User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 11:11:55 -0000 echo 'ABC'|sed 's/a/z/p' the p flag at the end makes it case sensitive. so in this instance, the above will output "ABC". echo 'ABC'|sed 's/A/z/p' will output zBC. Dan Danny Braniss wrote: > Since noone is complaining, this must be an oversite on my part, but > echo 'ABC'|sed 's/a/z/' > results in > zBC > what did i miss? > > thanks, > danny > > > _______________________________________________ > 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 Aug 27 11:27:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D397916A41B for ; Mon, 27 Aug 2007 11:27:50 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.terrorteam.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2D213C46A for ; Mon, 27 Aug 2007 11:27:50 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.terrorteam.de (Postfix) with ESMTP id 3D8DFB0227; Mon, 27 Aug 2007 13:03:10 +0200 (CEST) MIME-Version: 1.0 Date: Mon, 27 Aug 2007 13:03:10 +0200 From: Marian Hettwer To: Danny Braniss In-Reply-To: References: Message-ID: <2568096f340ce58f5808c04bf0f11397@127.0.0.1> X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 11:27:50 -0000 Hi Danny, On Mon, 27 Aug 2007 13:58:04 +0300, Danny Braniss wrote: > Since noone is complaining, this must be an oversite on my part, but > echo 'ABC'|sed 's/a/z/' > results in > zBC That's odd. My sed isn't case insensitive: ([mhettwer@blowfish] <~> $ echo 'ABC' | sed 's/a/z/' ABC versus: ([mhettwer@blowfish] <~> $ echo 'ABC' | sed 's/A/z/' zBC Well, I'm not using current... so I don't know wether the sed version has changed... ([mhettwer@blowfish] <~> $ uname -a FreeBSD blowfish 6.2-STABLE FreeBSD 6.2-STABLE #3: Wed Jul 4 12:43:22 CEST 2007 root@blowfish:/usr/obj/usr/src/sys/BLOWFISH i386 regards, Marian From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 05:52:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08F5016A419 for ; Mon, 27 Aug 2007 05:52:29 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id E79BA13C46B for ; Mon, 27 Aug 2007 05:52:27 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 43711 invoked from network); 27 Aug 2007 05:25:29 -0000 Received: from midgard.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 27 Aug 2007 05:25:29 -0000 Received: (qmail 40004 invoked by uid 907); 27 Aug 2007 05:25:44 -0000 Received: from [192.168.1.51] (HELO janmxp) (192.168.1.51) by midgard.transactionware.com (qpsmtpd/0.32) with ESMTP; Mon, 27 Aug 2007 15:25:44 +1000 From: "Jan Mikkelsen" To: "'Ivan Voras'" , References: In-Reply-To: Date: Mon, 27 Aug 2007 15:25:44 +1000 Organization: Transactionware Message-ID: <004f01c7e86a$b78088a0$268199e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acfn8q8mfkoiZiFZQVe6z5J4YZorpAAdV7vQ Content-Language: en-au X-Mailman-Approved-At: Mon, 27 Aug 2007 11:29:23 +0000 Cc: Subject: RE: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 05:52:29 -0000 Ivan Voras wrote: > Has anyone experienced frequent UFS panics on VMWare on fresh > current? > I've started seeing ufs_dirbad panics almost daily. For a > while I could > cause them simply by running make installworld to a freshly > newfs-ed > file system - the panic message points to the *new* file > system. > Unfortunately, kgdb cannot process the generated vmcores > (though they > are on a separate file system that has never crashed). The > repeatable > panics on new file systems have stopped when I rebuilt the > kernel, but > now they are happening again, this time on my /usr/ports. I > don't think > file system options have an influence - they first happened on > a > "normal" UFS (noasync), and now they are happening on > gjournaled, aync > mounted UFS. Is this an SMP or uniprocessor virtual machine? I see frequent "signal 11" failures from gcc when putting an SMP virtual machine under load. The same load on a uniprocessor virtual machine works fine. This is 6.2-STABLE; I haven't tried -CURRENT. VMware Server 1.0.3, AMD-X2, ECC memory, Windows XP 64-bit host. Regards, Jan Mikkelsen From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 09:21:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC27616A417 for ; Mon, 27 Aug 2007 09:21:53 +0000 (UTC) (envelope-from joerg@net.t-labs.tu-berlin.de) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF5413C483 for ; Mon, 27 Aug 2007 09:21:53 +0000 (UTC) (envelope-from joerg@net.t-labs.tu-berlin.de) Received: from falcon.net.t-labs.tu-berlin.de (falcon.net.t-labs.tu-berlin.de [130.149.220.27]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 051B9702D0DC; Mon, 27 Aug 2007 11:21:50 +0200 (CEST) Received: from falcon.net.t-labs.tu-berlin.de (localhost [127.0.0.1]) by falcon.net.t-labs.tu-berlin.de (8.13.8/8.13.8) with ESMTP id l7R9LoIl034596; Mon, 27 Aug 2007 11:21:50 +0200 (CEST) (envelope-from joerg@net.t-labs.tu-berlin.de) Received: (from joerg@localhost) by falcon.net.t-labs.tu-berlin.de (8.13.8/8.13.8/Submit) id l7R9Lm9x034595; Mon, 27 Aug 2007 11:21:48 +0200 (CEST) (envelope-from joerg) Date: Mon, 27 Aug 2007 11:21:48 +0200 From: Joerg Wallerich To: Olivier Houchard Message-ID: <20070827092148.GA34582@falcon.net.t-labs.tu-berlin.de> References: <20070826110841.GA31243@falcon.net.t-labs.tu-berlin.de> <20070826122525.GA59924@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070826122525.GA59924@ci0.org> User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Mon, 27 Aug 2007 11:29:23 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Network problems with sendto() syscall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 09:21:54 -0000 On Sun, Aug 26, 2007 at 02:25:25PM +0200, Olivier Houchard wrote: > On Sun, Aug 26, 2007 at 01:08:41PM +0200, Joerg Wallerich wrote: > > Hi all, > > > > since moving to 7-CURRENT I have a serious problem with > > the network stack when using the sendto() syscall. > > > > The problem appears as soon as I work with bootpd(8). As > > soon as bootpd tries to answer a BOOTP request, the > > sendto() call fails with EAFNOSUPPORT, I get kernel log > > messages like > > > > 'fxp0: can't handle af18' > > > > and then I can no longer access the IP address I sent the > > BOOTP request from. > > > > The call to sendto() in bootpd seems OK, so I doubt that the > > problem lies with bootpd. The NIC driver seems to be OK as > > well, as the problems appears with three different drivers > > (fxp, nfe, rl). I even get things like > > > > 'kernel: looutput: af=18 unexpected' > > > > in the logs when using bootptest on the local machine. > > > > This problem can be reproduced on my hardware using a > > vanilla installation of the latest snapshot of 7-CURRENT (200708). > > > > > > Does anyone see this behavior besides myself? > > > > Thanks, > > Joerg > > > > Hi Joerg, > > This is a known problem. Until the proper fix is committed, you can use the > attached patch, it should make bootp usable again. > > Regards, > > Olivier Hi Olivier, thanks a bunch! Your patch seems to fix the problem. At least bootpd works again. Thanks, Joerg -- --------------------------------------------------------------- - Joerg Wallerich joerg@net.t-labs.tu-berlin.de - - Technische Universitaet Berlin Phone +49 30 8353 58377 - - Deutsche Telekom Laboratories - --------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 11:31:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05ED216A41A for ; Mon, 27 Aug 2007 11:31:57 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.freebsd.org (Postfix) with ESMTP id 7728613C459 for ; Mon, 27 Aug 2007 11:31:56 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A7A75.dip.t-dialin.net [84.154.122.117]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id l7RBCwFb008715; Mon, 27 Aug 2007 13:12:59 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id l7RBCq5h039464; Mon, 27 Aug 2007 13:12:53 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id l7RBCqfT054850; Mon, 27 Aug 2007 13:12:52 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200708271112.l7RBCqfT054850@fire.js.berklix.net> To: Danny Braniss From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich/Muenchen. User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Mon, 27 Aug 2007 13:58:04 +0300." Date: Mon, 27 Aug 2007 13:12:52 +0200 Sender: jhs@berklix.org Cc: freebsd-current@freebsd.org Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 11:31:57 -0000 Danny Braniss wrote: > Since noone is complaining, this must be an oversite on my part, but > echo 'ABC'|sed 's/a/z/' > results in > zBC > what did i miss? > > thanks, > danny OK, i recognise you posted current@, but here: uname -r 6.2-RELEASE echo 'ABC'|sed 's/a/z/' ABC Maybe you have an env. var. such as EXINIT or some ~/.* or /etc/* initialiser file that's doing the equivalent of vi :se ic ? I know you'r talking sed, not vi, but man vi FILES gives hints of places to look for similar thing such as eg /etc/vi.exrc $HOME/.nexrc $HOME/.exrc `pwd`/.nexrc `pwd`/.exrc -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch=mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 11:49:30 2007 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 EE30F16A417 for ; Mon, 27 Aug 2007 11:49:30 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 7594713C45A for ; Mon, 27 Aug 2007 11:49:30 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1151533nfb for ; Mon, 27 Aug 2007 04:49:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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:references; b=tIjARO7KaKc+H0f18Oy6Ic+Fzrj0Tqc9GE9iuFHsC8+hL9F8Hq5Vu5+RuSeWPQWHExJag7Bh2jdSCuROGPInaITWH/5g+fnCv5bpu+NEfM/lCPF2hGDossLZ5BAAw6IPl01A0pSb4JbUjI4FaQM8SyOhaTXaPhHbjUfz+C23fM0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=U/XAHdoypTg1FZOYC6u6ur5JEh8yaOz/pFmYDOQYm4uRr5k75YZNoTA1VgRCy5E8sf2vLedN2jb7bQUbJJa9+Lhcfpb7t1d8d9Ble6pRGR5tFVuISuolpBvRucKBwwRlF6XVhmyV5D6/fi0T1VZ89fsTVMPiiD5jtxSgFxnZeR0= Received: by 10.78.140.17 with SMTP id n17mr3850344hud.1188215368690; Mon, 27 Aug 2007 04:49:28 -0700 (PDT) Received: by 10.78.160.10 with HTTP; Mon, 27 Aug 2007 04:49:28 -0700 (PDT) Message-ID: <3979a4b0708270449y3a36a219o87b84ef18218e75@mail.gmail.com> Date: Mon, 27 Aug 2007 15:49:28 +0400 From: "KOT MATPOCKuH" To: "Hidetoshi Shimokawa" In-Reply-To: <626eb4530708260337t28f0b434oce7b33560822f71f@mail.gmail.com> MIME-Version: 1.0 References: <3979a4b0707291120v4927a20cm357b845f6d1f3567@mail.gmail.com> <46BE1D6C.6040903@cran.org.uk> <626eb4530708221937h31c8f37fu9527e941ed4000b6@mail.gmail.com> <3979a4b0708240929p5f42b54ev412d5af16e9fb020@mail.gmail.com> <626eb4530708260337t28f0b434oce7b33560822f71f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Bruce Cran , current@freebsd.org Subject: Re: console hangs after setting hostname X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 11:49:31 -0000 On 8/26/07, Hidetoshi Shimokawa wrote: > > > ...and I'm too see corrupt messages in /var/run/dmesg.boot and on > console: > > > > cd0: <_NEC DVD_RW ND-3540A 1.01> Removable CD-ROM SCSI-0 device > > cdS0M:P :3 3A.P 0C0P0UM B#/s1 tLraaunnscfheerds! > > This is expected. If you concern interleaved meassges, could you try to > add the following line to your kernel configuration file as sun4v? > > options PRINTF_BUFR_SIZE=128 # Prevent printf output being > interspersed. With this line in my kernel configuration file I have this in dmesg.boot: ... cd0 at ata1 bus 0 target 0 lun 0 cd0: <_NEC DVD_RW ND-3540A 1.01> Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfersSMP: AP CPU #1 Launched! cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s1a -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 12:04:47 2007 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 573F116A50B for ; Mon, 27 Aug 2007 12:04:47 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id E820113C594 for ; Mon, 27 Aug 2007 12:04:46 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: by muon.bluestop.org (Postfix, from userid 1000) id 7E3853000D; Mon, 27 Aug 2007 13:00:43 +0100 (BST) Date: Mon, 27 Aug 2007 13:00:43 +0100 From: Bruce Cran To: Hidetoshi Shimokawa Message-ID: <20070827120043.GA25078@muon.bluestop.org> References: <3979a4b0707291120v4927a20cm357b845f6d1f3567@mail.gmail.com> <46BE1D6C.6040903@cran.org.uk> <626eb4530708221937h31c8f37fu9527e941ed4000b6@mail.gmail.com> <3979a4b0708240929p5f42b54ev412d5af16e9fb020@mail.gmail.com> <626eb4530708260337t28f0b434oce7b33560822f71f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <626eb4530708260337t28f0b434oce7b33560822f71f@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: KOT MATPOCKuH , current@freebsd.org Subject: Re: console hangs after setting hostname X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 12:04:47 -0000 On Sun, Aug 26, 2007 at 07:37:29PM +0900, Hidetoshi Shimokawa wrote: > On 8/25/07, KOT MATPOCKuH wrote: > > On 8/23/07, Hidetoshi Shimokawa wrote: > > > > > > It looks that the low level console is not locked though the high level > > > console > > > is locked by Giant. > > > > > > Could you try the attached patch? > > > > > Thanks you! Console doesn't hangs... > > Thank for the test. > > > ...and I'm too see corrupt messages in /var/run/dmesg.boot and on console: > > > > cd0: <_NEC DVD_RW ND-3540A 1.01> Removable CD-ROM SCSI-0 device > > cdS0M:P :3 3A.P 0C0P0UM B#/s1 tLraaunnscfheerds! > > This is expected. If you concern interleaved meassges, could you try to > add the following line to your kernel configuration file as sun4v? > > options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. Is there a reason this can't be the default setting? It seems to make sense that any kernel messages should be displayed in such a way that they can't be interspersed with other messages. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 12:22:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE50D16A46B for ; Mon, 27 Aug 2007 12:22:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE0A13C465 for ; Mon, 27 Aug 2007 12:22:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1IPdbj-000DwB-8s; Mon, 27 Aug 2007 15:22:15 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Alexander Leidinger In-reply-to: <20070827131045.6jv7qrdlw0wg0sos@webmail.leidinger.net> References: <20070827131045.6jv7qrdlw0wg0sos@webmail.leidinger.net> Comments: In-reply-to Alexander Leidinger message dated "Mon, 27 Aug 2007 13:10:45 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Aug 2007 15:22:15 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 12:22:16 -0000 > Quoting Danny Braniss (from Mon, 27 Aug 2007 > 13:58:04 +0300): > > > Since noone is complaining, this must be an oversite on my part, but > > echo 'ABC'|sed 's/a/z/' > > results in > > zBC > > what did i miss? > > An update from an old -current to a recent -current (this was a > temporary bug after a change to sed). > > Bye, > Alexander. i guess in -current, Aug 19 is old :-) i'll try again, thanks. From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 12:31:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E42416A417 for ; Mon, 27 Aug 2007 12:31:33 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 330A513C48E for ; Mon, 27 Aug 2007 12:31:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 0FFD0EB3655; Mon, 27 Aug 2007 20:31:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 9Mxd7Say2E0s; Mon, 27 Aug 2007 20:31:22 +0800 (CST) Received: from charlie.delphij.net (unknown [61.49.108.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 20AECEB2D64; Mon, 27 Aug 2007 20:31:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=bHLGEmQegMMJpXwp6FVrP2FjSixEKUBXljXClL8G75DFvBg2mwuus3u4ummKb9MOn vvXk6WukIFTYLe4MMy1Ow== Message-ID: <46D2C417.5080809@delphij.net> Date: Mon, 27 Aug 2007 20:31:19 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: Danny Braniss References: <20070827131045.6jv7qrdlw0wg0sos@webmail.leidinger.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , freebsd-current@freebsd.org Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 12:31:33 -0000 Danny Braniss wrote: >> Quoting Danny Braniss (from Mon, 27 Aug 2007 >> 13:58:04 +0300): >> >>> Since noone is complaining, this must be an oversite on my part, but >>> echo 'ABC'|sed 's/a/z/' >>> results in >>> zBC >>> what did i miss? >> An update from an old -current to a recent -current (this was a >> temporary bug after a change to sed). >> >> Bye, >> Alexander. > > i guess in -current, Aug 19 is old :-) > > i'll try again, > thanks. Just a reminder, before doing that, please make sure that you have the following revision of file: compile.c:__FBSDID("$FreeBSD: src/usr.bin/sed/compile.c,v 1.30 2007/07/06 16:34:56 delphij Exp $"); Cheers, From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 12:42:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D14AD16A41A for ; Mon, 27 Aug 2007 12:42:45 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 5F41A13C46B for ; Mon, 27 Aug 2007 12:42:45 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.13.8/8.13.8) with ESMTP id l7RBI1n4020968; Mon, 27 Aug 2007 13:18:02 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 291EF882; Mon, 27 Aug 2007 13:18:01 +0200 (CEST) Date: Mon, 27 Aug 2007 13:18:01 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Christian Walther Message-Id: <20070827131801.bd081807.gerrit@pmp.uni-hannover.de> In-Reply-To: <46D2C812.8090106@gmail.com> References: <46D2C812.8090106@gmail.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.3 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146 Cc: freebsd-current@freebsd.org Subject: Re: Encrypted 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, 27 Aug 2007 12:42:45 -0000 On Mon, 27 Aug 2007 12:48:18 +0000 Christian Walther wrote about Encrypted zfs?: CW> I'm currently using a zraid consisting of three drives. Lately I CW> wonder what the best way would be to encrypt it. CW> I read the chapter dealing with disk encryption in the handbook, and CW> decided to use GELI. Is there anyone here on the list who has some CW> experiences with ZFS on encrypted GELI devices? Are there some CW> performance specs around? I'm using zraid on geli devices. Can't tell you anything about performance though, it just works for me. However, I still have problems getting this setup booted and mounted automatically. OTOH, I havn't looked into these problems for some weeks now, maybe they're solved meanwhile. cu Gerrit From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 13:29:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE6C16A419 for ; Mon, 27 Aug 2007 13:29:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 12CAA13C442 for ; Mon, 27 Aug 2007 13:29:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1IPeeY-000ErS-Ge; Mon, 27 Aug 2007 16:29:14 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Xin LI In-reply-to: <46D2C417.5080809@delphij.net> References: <20070827131045.6jv7qrdlw0wg0sos@webmail.leidinger.net> <46D2C417.5080809@delphij.net> Comments: In-reply-to Xin LI message dated "Mon, 27 Aug 2007 20:31:19 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Aug 2007 16:29:14 +0300 From: Danny Braniss Message-ID: Cc: Alexander Leidinger , freebsd-current@freebsd.org Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 13:29:16 -0000 > Danny Braniss wrote: > >> Quoting Danny Braniss (from Mon, 27 Aug 2007 > >> 13:58:04 +0300): > >> > >>> Since noone is complaining, this must be an oversite on my part, but > >>> echo 'ABC'|sed 's/a/z/' > >>> results in > >>> zBC > >>> what did i miss? > >> An update from an old -current to a recent -current (this was a > >> temporary bug after a change to sed). > >> > >> Bye, > >> Alexander. > > > > i guess in -current, Aug 19 is old :-) > > > > i'll try again, > > thanks. > > Just a reminder, before doing that, please make sure that you have the > following revision of file: > > compile.c:__FBSDID("$FreeBSD: src/usr.bin/sed/compile.c,v 1.30 > 2007/07/06 16:34:56 delphij Exp $"); > arghh, it seems that my updating script missed this one :-( > Cheers, From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 13:33:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B403D16A41A for ; Mon, 27 Aug 2007 13:33:51 +0000 (UTC) (envelope-from idiotbg@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id E352D13C478 for ; Mon, 27 Aug 2007 13:33:50 +0000 (UTC) (envelope-from idiotbg@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1175922nfb for ; Mon, 27 Aug 2007 06:33:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=bzl4VONY82mCLr73rvQOjZGC0QC/7wqF88STRdxR5EWGYrjyFFer72AsGU0Dl3eVrAq+AU3UePuFbcXKRtUArHuooOTuSj1XjdA4z/XJ278C9jEJnXVcfutxWTAHh6m77aGyzAohnTddgyGFiYAiGokR+yP63xqv1zhGIViA5qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=eenbDtWfHCU8J08cJZZXP9NByPIrPmt7Kup0yjh7anYHC7fh7CyP/Rtgez7lzGifF8Q2AYJaGlKgmMlkfgoWLoE4o6xFzU0TdO8TAvA5F9SJNL2ntbw4UqjkLsz7HkPSNBLkkZWv+rV7mM7Z0OybisIto3hk7EeAczUUozMtlyY= Received: by 10.86.23.17 with SMTP id 17mr4917393fgw.1188219963617; Mon, 27 Aug 2007 06:06:03 -0700 (PDT) Received: from 108-157-80-80.trakia.net ( [80.80.157.27]) by mx.google.com with ESMTPS id f19sm5967256fka.2007.08.27.06.06.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2007 06:06:02 -0700 (PDT) From: Momchil Ivanov To: freebsd-current@freebsd.org Date: Mon, 27 Aug 2007 15:05:57 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1355886.KPnNBAa3Eq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708271506.04291.idiotbg@gmail.com> Cc: Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 13:33:51 -0000 --nextPart1355886.KPnNBAa3Eq Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =D0=9D=D0=B0 Monday 27 August 2007 12:58:04 Danny Braniss =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0: > Since noone is complaining, this must be an oversite on my part, but > echo 'ABC'|sed 's/a/z/' > results in > zBC > what did i miss? > > thanks, > danny > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I updated my system from STABLE to CURRENT yesterday: FreeBSD 7.0-CURRENT #= 0:=20 Sun Aug 26 16:47:13 CEST 2007 and don`t see this behaviour: space@a144026 space$ echo 'ABC'|sed 's/a/z/' ABC =2D-=20 PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E =C2=A0158A E03D 56DA 3118 168B --nextPart1355886.KPnNBAa3Eq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG0sw14D1W2jEYFosRAnprAKCbe35LtaOAxLJt5qpT2w9Q0I2EcgCfVdyL buum96Q+DBif5So4fiu/gvI= =yrQD -----END PGP SIGNATURE----- --nextPart1355886.KPnNBAa3Eq-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 15:17:08 2007 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 164D916A469 for ; Mon, 27 Aug 2007 15:17:08 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3B213C45D for ; Mon, 27 Aug 2007 15:17:07 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so44075ugf for ; Mon, 27 Aug 2007 08:17:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=HPYgiLAV+szEIliTQkPcXtxCQ/dMU5TXqrsDq+SXTX0QK/s8ycc14D9JpfVVgqtfK2DNg7Kf+mFW4Hdh9BMJBrplnbPz2s+vzVacr5wnIcN01achLmZbX51NOZWMnQgoIDwBmYosR+dkrrCQp7k+LeJoTYSwMfyBHjt1eS5s4XM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p4xcaxwdBMuUclhatnnrUPs1ONdmskctxnJAplaKyL9C3/CZAD7eUymwj3jrh5XUM7Vq8jYI+GR37bgoc0lOxLS8IyHOIVKGg5v2Z+eaOiMvlJ4vWM76glhnw5Mkyj5rJ9vZ6ZBhlVgn27piTGyZbo+HnjHGnz/yuCEAxSgbAOw= Received: by 10.142.76.4 with SMTP id y4mr522278wfa.1188227824689; Mon, 27 Aug 2007 08:17:04 -0700 (PDT) Received: by 10.143.10.17 with HTTP; Mon, 27 Aug 2007 08:17:04 -0700 (PDT) Message-ID: <26ddd1750708270817l2e74001ey26bfc96a61498742@mail.gmail.com> Date: Mon, 27 Aug 2007 11:17:04 -0400 From: "Maxim Khitrov" To: "Stefan Esser" In-Reply-To: <46D2B750.5070302@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <26ddd1750708260826q153a3425jf9bea3e8a8a82a70@mail.gmail.com> <46D2B750.5070302@FreeBSD.org> Cc: current@freebsd.org Subject: Re: Error building openoffice.org-2: cannot compute object file suffix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 15:17:08 -0000 On 8/27/07, Stefan Esser wrote: > Maxim Khitrov schrieb: > > Hello, > > > > Have a bit of a problem and no idea on what is causing it... When I > > try to build openoffice.org I get the following error: "configure: > > error: cannot compute suffix of object files: cannot compile". The > > full output is below. This happens when building gcc-ooo. I looked in > > config.log, but see no relevant information there, maybe I'm looking > > in the wrong place. Here's my uname -a output: > > Do you by chance have -fno-tree-vrp in your CFLAGS? > > That switch ist not supported by older versions of gcc and I'm > quite sure that this (or some other switch that is not supported > by gcc-ooo) casues configure to bail out ... > > Regards, STefan You got my hopes up ;-) No, I don't have that flag, but I had my CPUTYPE set to "native." Thought that was the problem, but unfortunately that didn't fix it. I first set it back to pentium-m, and then commented both CPUTYPE and CFLAGS in my make.conf. Same exact thing. Cannot compute suffix of object files. Any other ideas? From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 15:48:30 2007 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 C026716A41A for ; Mon, 27 Aug 2007 15:48:30 +0000 (UTC) (envelope-from pawel.worach@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 1F01A13C45B for ; Mon, 27 Aug 2007 15:48:29 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so51146ugf for ; Mon, 27 Aug 2007 08:48:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=AxwdNwvJIs3dXMGHUzOvwXFN8mqTsO0XwFmHawWP35Iq44eUYyFyq1+EUcAs6UUaVpbahvv1bkMYJz8cT5xoYmFcpY8qNKYJKLLu9IoJeP1ozWMhTI+vRU9Q3TLbqtRNMQ8h+0nl3vHTd4wGoHWBX5r4aH9/8tKCa1LIU1PmkF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=dEpl11+wSvBCslxSTeXGmNxbFUTEyjLULy5udeyeCtGlVvWViz11IE5RduEzJOsX8ek1W3DRQBDJUc++MV7olXo9INr/yhByBohTrg1YA4gRdT5p14QMyTSlIFuNNrlb7xjcjG8XDpoBwZLLF3kqc8qfJ4Vf8HzovOWRNRAoGrg= Received: by 10.78.138.6 with SMTP id l6mr4049162hud.1188227985020; Mon, 27 Aug 2007 08:19:45 -0700 (PDT) Received: from ibm-se82151.se.ibm.com ( [195.212.29.163]) by mx.google.com with ESMTPS id b35sm5352049ugd.2007.08.27.08.19.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Aug 2007 08:19:44 -0700 (PDT) Message-ID: <46D2EB88.7020905@gmail.com> Date: Mon, 27 Aug 2007 17:19:36 +0200 From: Pawel Worach User-Agent: Thunderbird 2.0.0.7pre (X11/20070820) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: IPSec panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 15:48:30 -0000 Hi, While testing IPSec I got this panic on two different -CURRENT systems. I think they happened when racoon was updating the SAD. kernel.debug and vmcore is still available if more info needed. FreeBSD 7.0-CURRENT #0: Fri Aug 24 22:31:26 CEST 2007 Script started on Sun Aug 26 02:21:17 2007 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc059ba74 stack pointer = 0x28:0xe40be9f8 frame pointer = 0x28:0xe40bea04 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 32 (ath0 taskq) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c07d4c94,e40be8d8,c056b7da,c07d308a,c0849280,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07d308a,c0849280,c07c639b,e40be8e4,e40be8e4,...) at kdb_backtrace+0x29 panic(c07c639b,c07f1dac,c3bd9a28,1,1,...) at panic+0xaa trap_fatal(c07f1cae,c,0,14,c,...) at trap_fatal+0x353 trap(e40be9b8) at trap+0x10a calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc059ba74, esp = 0xe40be9f8, ebp = 0xe40bea04 --- turnstile_broadcast(0,0,18,c3fe72a0,e40beac8,...) at turnstile_broadcast+0x34 _mtx_unlock_sleep(c3fe7330,0,0,0,49c6,...) at _mtx_unlock_sleep+0x52 tcp_input(c3e6ae00,14,0,c3ea281a,800,...) at tcp_input+0xe29 ip_input(c3e6ae00,c3e6ae00,800,c3ba5c00,800,...) at ip_input+0x6ff netisr_dispatch(2,c3e6ae00,10,3,0,...) at netisr_dispatch+0x52 ether_demux(c3ba5c00,c3e6ae00,3,0,3,...) at ether_demux+0x1c1 ether_input(c3ba5c00,c3e6ae00,18,c055ca7a,c3fc4000,...) at ether_input+0x34f ieee80211_deliver_data(c3bda22c,c3fc4000,c3e6ae00,18,c05b9a42,...) at ieee80211_deliver_data+0x137 ieee80211_input(c3bda22c,c3e6ae00,c3fc4000,1d,ffffffa2,...) at ieee80211_input+0x10f6 ath_rx_proc(c3bda000,1,c07c96a3,0,0,...) at ath_rx_proc+0x3cd taskqueue_run(c3bb3700,c3bb371c,0,c07c96a3,0,...) at taskqueue_run+0x14f taskqueue_thread_loop(c3bdb65c,e40bed38,0,0,0,...) at taskqueue_thread_loop+0x98 fork_exit(c0599d70,c3bdb65c,e40bed38) at fork_exit+0xa1 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- Uptime: 16m47s Physical memory: 1014 MB Dumping 95 MB: 80 64 48 32 16 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc056b5e3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc056b81a in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07903b3 in trap_fatal (frame=0xe40be9b8, eva=24) at /usr/src/sys/i386/i386/trap.c:872 #4 0xc0790d5a in trap (frame=0xe40be9b8) at /usr/src/sys/i386/i386/trap.c:277 #5 0xc077f4cb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc059ba74 in turnstile_broadcast (ts=0x0, queue=0) at /usr/src/sys/kern/subr_turnstile.c:834 #7 0xc055f542 in _mtx_unlock_sleep (m=0xc3fe7330, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:593 #8 0xc069e9c9 in tcp_input (m=0xc3e6ae00, off0=20) at /usr/src/sys/netinet/tcp_input.c:854 #9 0xc0641c1f in ip_input (m=0xc3e6ae00) at /usr/src/sys/netinet/ip_input.c:663 #10 0xc06043a2 in netisr_dispatch (num=2, m=0xc3e6ae00) at /usr/src/sys/net/netisr.c:185 #11 0xc06030a1 in ether_demux (ifp=0xc3ba5c00, m=0xc3e6ae00) at /usr/src/sys/net/if_ethersubr.c:848 #12 0xc06034cf in ether_input (ifp=0xc3ba5c00, m=0xc3e6ae00) at /usr/src/sys/net/if_ethersubr.c:706 #13 0xc061ba57 in ieee80211_deliver_data (ic=0xc3bda22c, ni=0xc3fc4000, m=0xc3e6ae00) at /usr/src/sys/net80211/ieee80211_input.c:771 ---Type to continue, or q to quit--- #14 0xc0620df6 in ieee80211_input (ic=0xc3bda22c, m=0xc3e6ae00, ni=0xc3fc4000, rssi=29, noise=-94, rstamp=894) at /usr/src/sys/net80211/ieee80211_input.c:518 #15 0xc090fa7d in ?? () #16 0xc3bda22c in ?? () #17 0xc3e6ae00 in ?? () #18 0xc3fc4000 in ?? () #19 0x0000001d in ?? () #20 0xffffffa2 in ?? () #21 0x0000037e in ?? () #22 0xc3be3b98 in ?? () #23 0x014e22a0 in ?? () #24 0xc3bdb9dc in ?? () #25 0xc3bdb6b4 in ?? () #26 0xc3bda22c in ?? () #27 0xc3ba5c00 in ?? () #28 0xc3bde000 in ?? () #29 0xc3be3b98 in ?? () #30 0xc3fc4000 in ?? () #31 0x00000000 in ?? () #32 0xffffffa2 in ?? () #33 0xc0d303a7 in ?? () #34 0x000000de in ?? () ---Type to continue, or q to quit--- #35 0x000000cc in ?? () #36 0xc3bdb9ec in ?? () #37 0xc3bb3700 in ?? () #38 0x00000001 in ?? () #39 0xe40becd0 in ?? () #40 0xc0599c0f in taskqueue_run (queue=0xc3be3b7c) at /usr/src/sys/kern/subr_taskqueue.c:255 Previous frame identical to this frame (corrupt stack?) (kgdb) f 8 #8 0xc069e9c9 in tcp_input (m=0xc3e6ae00, off0=20) at /usr/src/sys/netinet/tcp_input.c:854 854 INP_UNLOCK(inp); (kgdb) list 849 tcp_dropwithreset(m, th, tp, tlen, rstreason); 850 m = NULL; /* mbuf chain got consumed. */ 851 dropunlock: 852 INP_INFO_WLOCK_ASSERT(&tcbinfo); 853 if (inp != NULL) 854 INP_UNLOCK(inp); 855 INP_INFO_WUNLOCK(&tcbinfo); 856 drop: 857 INP_INFO_UNLOCK_ASSERT(&tcbinfo); 858 if (s != NULL) (kgdb) p *inp $1 = {inp_hash = {le_next = 0x0, le_prev = 0xc3bfb654}, inp_list = { le_next = 0xc3fe7bd0, le_prev = 0xc3fe7200}, inp_flow = 0, inp_inc = { inc_flags = 0 '\0', inc_len = 0 '\0', inc_pad = 0, inc_ie = { ie_fport = 5632, ie_lport = 18886, ie_dependfaddr = {ie46_foreign = { ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 17475776}}, ie6_foreign = {__u6_addr = { __u6_addr8 = '\0' , "Àš\n\001", __u6_addr16 = { 0, 0, 0, 0, 0, 0, 43200, 266}, __u6_addr32 = {0, 0, 0, 17475776}}}}, ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 3356141760}}, ie6_local = { __u6_addr = {__u6_addr8 = '\0' , "Àš\nÈ", __u6_addr16 = {0, 0, 0, 0, 0, 0, 43200, 51210}, __u6_addr32 = {0, 0, 0, 3356141760}}}}}}, inp_ppcb = 0xc3fe9e10, inp_pcbinfo = 0xc0851e00, inp_socket = 0xc4b61c60, inp_label = 0x0, inp_flags = 8388672, inp_sp = 0xc44c5110, inp_vflag = 1 '\001', inp_ip_ttl = 64 '@', inp_ip_p = 0 '\0', inp_ip_minttl = 0 '\0', inp_depend4 = {inp4_ip_tos = 16 '\020', inp4_options = 0x0, inp4_moptions = 0x0}, inp_depend6 = {inp6_options = 0x0, inp6_outputopts = 0x0, inp6_moptions = 0x0, inp6_icmp6filt = 0x0, inp6_cksum = 0, inp6_hops = 0}, inp_portlist = {le_next = 0x0, le_prev = 0xc44c52c8}, inp_phd = 0xc44c52c0, inp_gencnt = 52, inp_mtx = { lock_object = {lo_name = 0xc07dedd3 "inp", lo_type = 0xc07e0b4d "tcpinp", lo_flags = 21692416, lo_witness_data = {lod_list = {stqe_next = 0x0}, ---Type to continue, or q to quit--- lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}} (kgdb) Script done on Sun Aug 26 02:21:46 2007 And the other: Script started on Sun Aug 26 02:23:40 2007 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc059ba74 stack pointer = 0x28:0xd4d86ac8 frame pointer = 0x28:0xd4d86ad4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 31 (em0 taskq) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c07d4c94,d4d869a8,c056b7da,c07d308a,c0849280,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07d308a,c0849280,c07c639b,d4d869b4,d4d869b4,...) at kdb_backtrace+0x29 panic(c07c639b,c07f1dac,c2a66cd4,1,1,...) at panic+0xaa trap_fatal(c07f1cae,c,14,14,c,...) at trap_fatal+0x353 trap(d4d86a88) at trap+0x10a calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc059ba74, esp = 0xd4d86ac8, ebp = 0xd4d86ad4 --- turnstile_broadcast(0,0,10,c2d7ba80,d4d86b98,...) at turnstile_broadcast+0x34 _mtx_unlock_sleep(c2d7bb10,0,0,0,1600,...) at _mtx_unlock_sleep+0x52 tcp_input(c2cfa300,14,c2a5c800,1,0,...) at tcp_input+0xe29 ip_input(c2cfa300,c2cfa300,800,c2a5c800,800,...) at ip_input+0x6ff netisr_dispatch(2,c2cfa300,10,3,0,...) at netisr_dispatch+0x52 ether_demux(c2a5c800,c2cfa300,3,0,3,...) at ether_demux+0x1c1 ether_input(c2a5c800,c2cfa300,c0570028,0,c2a62000,...) at ether_input+0x34f em_handle_rxtx(c29d7000,1,c0573862,c2a46b00,c2a46b1c,...) at em_handle_rxtx+0x43e taskqueue_run(c2a46b00,c2a46b1c,c07c96a3,0,d4d86cf4,...) at taskqueue_run+0x14f taskqueue_thread_loop(c29d72ec,d4d86d38,c0549050,c05489b0,c0548990,...) at taskqueue_thread_loop+0x98 fork_exit(c0599d70,c29d72ec,d4d86d38) at fork_exit+0xa1 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xd4d86d70, ebp = 0 --- Uptime: 9h39m42s Physical memory: 502 MB Dumping 46 MB: 31 15 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc056b5e3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc056b81a in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07903b3 in trap_fatal (frame=0xd4d86a88, eva=24) at /usr/src/sys/i386/i386/trap.c:872 #4 0xc0790d5a in trap (frame=0xd4d86a88) at /usr/src/sys/i386/i386/trap.c:277 #5 0xc077f4cb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc059ba74 in turnstile_broadcast (ts=0x0, queue=0) at /usr/src/sys/kern/subr_turnstile.c:834 #7 0xc055f542 in _mtx_unlock_sleep (m=0xc2d7bb10, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:593 #8 0xc069e9c9 in tcp_input (m=0xc2cfa300, off0=20) at /usr/src/sys/netinet/tcp_input.c:854 #9 0xc0641c1f in ip_input (m=0xc2cfa300) at /usr/src/sys/netinet/ip_input.c:663 #10 0xc06043a2 in netisr_dispatch (num=2, m=0xc2cfa300) at /usr/src/sys/net/netisr.c:185 #11 0xc06030a1 in ether_demux (ifp=0xc2a5c800, m=0xc2cfa300) at /usr/src/sys/net/if_ethersubr.c:848 #12 0xc06034cf in ether_input (ifp=0xc2a5c800, m=0xc2cfa300) at /usr/src/sys/net/if_ethersubr.c:706 #13 0xc04bc25e in em_handle_rxtx (context=0xc29d7000, pending=1) at /usr/src/sys/dev/em/if_em.c:4308 ---Type to continue, or q to quit--- #14 0xc0599c0f in taskqueue_run (queue=0xc2a46b00) at /usr/src/sys/kern/subr_taskqueue.c:255 #15 0xc0599e08 in taskqueue_thread_loop (arg=0xc29d72ec) at /usr/src/sys/kern/subr_taskqueue.c:374 #16 0xc054eae1 in fork_exit (callout=0xc0599d70 , arg=0xc29d72ec, frame=0xd4d86d38) at /usr/src/sys/kern/kern_fork.c:797 #17 0xc077f540 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) f 8 #8 0xc069e9c9 in tcp_input (m=0xc2cfa300, off0=20) at /usr/src/sys/netinet/tcp_input.c:854 854 INP_UNLOCK(inp); (kgdb) list 849 tcp_dropwithreset(m, th, tp, tlen, rstreason); 850 m = NULL; /* mbuf chain got consumed. */ 851 dropunlock: 852 INP_INFO_WLOCK_ASSERT(&tcbinfo); 853 if (inp != NULL) 854 INP_UNLOCK(inp); 855 INP_INFO_WUNLOCK(&tcbinfo); 856 drop: 857 INP_INFO_UNLOCK_ASSERT(&tcbinfo); 858 if (s != NULL) (kgdb) p *inp $1 = {inp_hash = {le_next = 0x0, le_prev = 0xc29d58bc}, inp_list = { le_next = 0xc2d7bd20, le_prev = 0xc2d7b9e0}, inp_flow = 0, inp_inc = { inc_flags = 0 '\0', inc_len = 0 '\0', inc_pad = 0, inc_ie = { ie_fport = 62440, ie_lport = 5632, ie_dependfaddr = {ie46_foreign = { ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 3356141760}}, ie6_foreign = {__u6_addr = { __u6_addr8 = '\0' , "Àš\nÈ", __u6_addr16 = {0, 0, 0, 0, 0, 0, 43200, 51210}, __u6_addr32 = {0, 0, 0, 3356141760}}}}, ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 17475776}}, ie6_local = { __u6_addr = {__u6_addr8 = '\0' , "Àš\n\001", __u6_addr16 = {0, 0, 0, 0, 0, 0, 43200, 266}, __u6_addr32 = {0, 0, 0, 17475776}}}}}}, inp_ppcb = 0xc2d7d5a0, inp_pcbinfo = 0xc0851e00, inp_socket = 0xc2d81948, inp_label = 0x0, inp_flags = 8388608, inp_sp = 0xc2aa8ca0, inp_vflag = 1 '\001', inp_ip_ttl = 64 '@', inp_ip_p = 0 '\0', inp_ip_minttl = 0 '\0', inp_depend4 = {inp4_ip_tos = 16 '\020', inp4_options = 0x0, inp4_moptions = 0x0}, inp_depend6 = {inp6_options = 0x0, inp6_outputopts = 0x0, inp6_moptions = 0x0, inp6_icmp6filt = 0x0, inp6_cksum = 0, inp6_hops = 0}, inp_portlist = {le_next = 0xc2d7bd20, le_prev = 0xc2a925f8}, inp_phd = 0xc2a925f0, inp_gencnt = 16, inp_mtx = { lock_object = {lo_name = 0xc07dedd3 "inp", lo_type = 0xc07e0b4d "tcpinp", lo_flags = 21692416, lo_witness_data = {lod_list = {stqe_next = 0x0}, ---Type to continue, or q to quit--- lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}} (kgdb) Script done on Sun Aug 26 02:24:15 2007 ipsec.conf: flush; spdflush; spdadd 192.168.10.200 192.168.10.1 any -P out ipsec esp/transport//require; spdadd 192.168.10.1 192.168.10.200 any -P in ipsec esp/transport//require; spdadd -6 ::/0 ::/0 icmp6 -P out none; spdadd -6 ::/0 ::/0 icmp6 -P in none; spdadd -6 1ce:c01d:c0ca:c01a:205:4eff:fe4b:7613 1ce:c01d:c0ca:c01a::1 any -P out ipsec esp/transport//require; spdadd -6 1ce:c01d:c0ca:c01a::1 1ce:c01d:c0ca:c01a:205:4eff:fe4b:7613 any -P in ipsec esp/transport//require; add -6 1ce:c01d:c0ca:c01a::1 1ce:c01d:c0ca:c01a:205:4eff:fe4b:7613 esp 0x1001 -m transport -E rijndael-cbc "01234567890123456789012345678901" -A hmac-sha2-256 "01234567890123456789012345678901"; add -6 1ce:c01d:c0ca:c01a:205:4eff:fe4b:7613 1ce:c01d:c0ca:c01a::1 esp 0x1002 -m transport -E rijndael-cbc "01234567890123456789012345678901" -A hmac-sha2-256 "01234567890123456789012345678901"; (IPv6 uses static keying because racoon fails to find the policy for some reason). racoon.conf is a pretty basic rsasig authentication setup. -- Pawel From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 15:51:30 2007 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 BABF816A41A for ; Mon, 27 Aug 2007 15:51:30 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 14F6A13C46C for ; Mon, 27 Aug 2007 15:51:29 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1214742nfb for ; Mon, 27 Aug 2007 08:51:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=dkIZOZs4xFgwzKpu2MvogXC+340/AOf8cUpLvOLB1mzChKzQNIDLL3jbhDo8A/2TSbvpRsf9nSGVMLG4MSMpidzQmavHf7VdjR4TjgPsJn1nqYKVQGvNXq+hGHvWDV0nGgLDMmcteG84xdbgc0kEje05HIYELQ6g28Lu7XOXbwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=H8Pmn+ggo0A5YOTRwVWWEY1lxjmd8WvVNK+bVaRFArX0q+yYiP22VKTYD55qETlY3VpLGIyTf0D5D3QOJ7DMGG7Hc/NS4s06NaYxUS2KeovU6rgkg7Poc0b5AjJMzsXgo1pjd2j+YM+koR3rRdyHAFWbWecNEPOsA3BevH6wHyI= Received: by 10.78.180.16 with SMTP id c16mr4052299huf.1188228142611; Mon, 27 Aug 2007 08:22:22 -0700 (PDT) Received: from ibm-se82151.se.ibm.com ( [195.212.29.179]) by mx.google.com with ESMTPS id 29sm2091010uga.2007.08.27.08.22.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Aug 2007 08:22:21 -0700 (PDT) Message-ID: <46D2EC26.3020005@gmail.com> Date: Mon, 27 Aug 2007 17:22:14 +0200 From: Pawel Worach User-Agent: Thunderbird 2.0.0.7pre (X11/20070820) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: IPSec/IPv6 panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 15:51:30 -0000 Hi, While testing IPSec and IPv6 I got this panic when sending ICMPv6 echo requests to the peer. kernel.debug and vmcore available if more info is needed. FreeBSD 7.0-CURRENT #0: Fri Aug 24 22:31:26 CEST 2007 Script started on Sun Aug 26 04:20:22 2007 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc078ea95 esp = 0xe25cc000 ebp = 0xe25cc060 panic: double fault KDB: stack backtrace: db_trace_self_wrapper(c07d4c94,c0861cc4,c056b7da,c07d308a,c0849280,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07d308a,c0849280,c07f1a71,c0861cd0,c0861cd0,...) at kdb_backtrace+0x29 panic(c07f1a71,e25cc060,e25cc060,0,0,...) at panic+0xaa dblfault_handler() at dblfault_handler+0x69 --- trap 0x17, eip = 0xc078ea95, esp = 0xe25cc000, ebp = 0xe25cc060 --- bcmp(c08521c0,e25cdb0c,0,c07b548c,0,...) at bcmp+0x1 udp6_ctlinput(6,e25cdb0c,e25cc0e8,e25cc0e8,e25cdb0c,...) at udp6_ctlinput+0x152 pfctlinput2(6,e25cdb0c,e25cc0e8,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc164,e25cc164,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc164,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc1e0,e25cc1e0,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc1e0,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc25c,e25cc25c,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc25c,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc2d8,e25cc2d8,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc2d8,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc354,e25cc354,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc354,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc3d0,e25cc3d0,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc3d0,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc44c,e25cc44c,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc44c,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc4c8,e25cc4c8,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc4c8,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc544,e25cc544,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc544,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc5c0,e25cc5c0,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc5c0,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc63c,e25cc63c,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc63c,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc6b8,e25cc6b8,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc6b8,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc734,e25cc734,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc734,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc7b0,e25cc7b0,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc7b0,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc82c,e25cc82c,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc82c,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc8a8,e25cc8a8,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc8a8,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc924,e25cc924,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc924,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cc9a0,e25cc9a0,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cc9a0,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cca1c,e25cca1c,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cca1c,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cca98,e25cca98,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cca98,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccb14,e25ccb14,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccb14,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccb90,e25ccb90,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccb90,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccc0c,e25ccc0c,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccc0c,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccc88,e25ccc88,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccc88,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccd04,e25ccd04,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccd04,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccd80,e25ccd80,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccd80,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccdfc,e25ccdfc,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccdfc,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cce78,e25cce78,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cce78,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccef4,e25ccef4,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccef4,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccf70,e25ccf70,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccf70,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25ccfec,e25ccfec,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25ccfec,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd068,e25cd068,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd068,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd0e4,e25cd0e4,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd0e4,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd160,e25cd160,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd160,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd1dc,e25cd1dc,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd1dc,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd258,e25cd258,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd258,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd2d4,e25cd2d4,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd2d4,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd350,e25cd350,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd350,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd3cc,e25cd3cc,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd3cc,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd448,e25cd448,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd448,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd4c4,e25cd4c4,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd4c4,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd540,e25cd540,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd540,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd5bc,e25cd5bc,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd5bc,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd638,e25cd638,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd638,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd6b4,e25cd6b4,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd6b4,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd730,e25cd730,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd730,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd7ac,e25cd7ac,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd7ac,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd828,e25cd828,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd828,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd8a4,e25cd8a4,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd8a4,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd920,e25cd920,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd920,0,0,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cd99c,e25cd99c,e25cdb0c,...) at esp6_ctlinput+0x73 pfctlinput2(6,e25cdb0c,e25cd99c,c3ba5c00,e25cdb30,...) at pfctlinput2+0x4a esp6_ctlinput(6,e25cdb0c,e25cdacc,84,c66a7400,...) at esp6_ctlinput+0x73 icmp6_input(e25cdc74,e25cdc5c,3a,1,0,...) at icmp6_input+0x25de ip6_input(c66a7400,c055f65d,c3a9ac30,c3ab1c00,0,...) at ip6_input+0xed9 netisr_processqueue(c08490d0,c3ab2000,0,0,0,...) at netisr_processqueue+0xdb swi_net(0,0,c07d0e15,46b,ffffffff,...) at swi_net+0xca ithread_loop(c3a78a80,e25cdd38,ffdfffff,ffffffff,ffefffff,...) at ithread_loop+0x1cb fork_exit(c05520a0,c3a78a80,e25cdd38) at fork_exit+0xa1 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe25cdd70, ebp = 0 --- Uptime: 1h59m52s Physical memory: 1014 MB Dumping 141 MB: 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc056b5e3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc056b81a in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0790059 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:901 #4 0x00000000 in ?? () (kgdb) l *pfctlinput2+0x4a 0xc05b64ca is in pfctlinput2 (/usr/src/sys/kern/uipc_domain.c:444). 439 * correct way. the following check is made just for safety. 440 */ 441 if (dp->dom_family != sa->sa_family) 442 continue; 443 444 for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++) 445 if (pr->pr_ctlinput) 446 (*pr->pr_ctlinput)(cmd, sa, ctlparam); 447 } 448 } (kgdb) l *esp6_ctlinput+0x73 0xc06d8ca3 is in esp6_ctlinput (/usr/src/sys/netipsec/ipsec_input.c:801). 796 * Then go to special cases that need ESP header information. 797 * XXX: We assume that when ip6 is non NULL, 798 * M and OFF are valid. 799 */ 800 801 if (cmd == PRC_MSGSIZE) { 802 struct secasvar *sav; 803 u_int32_t spi; 804 int valid; 805 (kgdb) Script done on Sun Aug 26 04:20:50 2007 -- Pawel From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 16:13:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3880B16A41B for ; Mon, 27 Aug 2007 16:13:44 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from hurl.ugcs.caltech.edu (hurl.ugcs.caltech.edu [131.215.176.101]) by mx1.freebsd.org (Postfix) with ESMTP id 248DA13C483 for ; Mon, 27 Aug 2007 16:13:44 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by hurl.ugcs.caltech.edu (Postfix, from userid 3640) id C26871C3C5C; Mon, 27 Aug 2007 08:47:26 -0700 (PDT) Date: Mon, 27 Aug 2007 08:47:26 -0700 From: Paul Allen To: Christian Walther Message-ID: <20070827154726.GA13200@hurl.ugcs.caltech.edu> References: <46D2C812.8090106@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D2C812.8090106@gmail.com> Sender: jd@ugcs.caltech.edu Cc: freebsd-current@freebsd.org Subject: Re: Encrypted 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, 27 Aug 2007 16:13:44 -0000 >From Christian Walther , Mon, Aug 27, 2007 at 12:48:18PM +0000: The real kicker is why this doesn't work: zraid -> geli -> zfs From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 16:44:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 691F316A41A for ; Mon, 27 Aug 2007 16:44:23 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id E15E813C458 for ; Mon, 27 Aug 2007 16:44:22 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l7RGiKDS024273; Mon, 27 Aug 2007 20:44:20 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 27 Aug 2007 20:44:20 +0400 (MSD) From: Dmitry Morozovsky To: Paul Allen In-Reply-To: <20070827154726.GA13200@hurl.ugcs.caltech.edu> Message-ID: <20070827204300.F26259@woozle.rinet.ru> References: <46D2C812.8090106@gmail.com> <20070827154726.GA13200@hurl.ugcs.caltech.edu> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Mon, 27 Aug 2007 20:44:21 +0400 (MSD) Cc: freebsd-current@freebsd.org, Christian Walther Subject: Re: Encrypted 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, 27 Aug 2007 16:44:23 -0000 On Mon, 27 Aug 2007, Paul Allen wrote: PA> >From Christian Walther , Mon, Aug 27, 2007 at 12:48:18PM +0000: PA> The real kicker is why this doesn't work: PA> PA> zraid -> geli -> zfs s/zraid/zpool/ ? I suppose nothing can slide between zpool and zfs because zfs needs zpool features directly for transactions. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 18:38:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA49716A417 for ; Mon, 27 Aug 2007 18:38:03 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 7356213C469 for ; Mon, 27 Aug 2007 18:38:03 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id l7RIc0Me032940 ; Mon, 27 Aug 2007 20:38:00 +0200 (CEST) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id l7RIbxCV001844 ; Mon, 27 Aug 2007 20:37:59 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id l7RIbvvv001841; Mon, 27 Aug 2007 20:37:57 +0200 (MEST) (envelope-from arno) To: Jeremie Le Hen References: <46BFE620.8070906@fusiongol.com> <20070813091802.GB3078@stud.ntnu.no> <20070823071056.GA50852@obiwan.tataz.chchile.org> <20070825082812.GE50852@obiwan.tataz.chchile.org> From: "Arno J. Klaassen" Date: 27 Aug 2007 20:37:57 +0200 In-Reply-To: <20070825082812.GE50852@obiwan.tataz.chchile.org> Message-ID: Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88.7/4076/Mon Aug 27 16:15:54 2007 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 46D31A08.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: Nathan Butcher , freebsd-current@freebsd.org Subject: Re: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 18:38:03 -0000 Jeremie Le Hen writes: > Nathan, > > On Thu, Aug 23, 2007 at 10:19:02PM +0200, Arno J. Klaassen wrote: > > I re-read the above email a bit more attentively (?) and noticed > > that, as Ulf, I use Adaptec SCSI (ahc or ahd) to boot from and > > have nothing on standard irq-14/15 IDE subsystem. > > > > Once again, I experience the problems on -STABLE-amd64, but can > > dig up a good-old (not so fast) SCSI-disk to test the (almost) same > > hardware setup under -CURRENT. > > Which arch are you running? amd64 or i386? Also do you use an > Adapter SCSI controller in the same time? just a quick 'state-of-the-art' : 1) I replaced TX4 (Promise PDC40718 SATA300) with some cheap Sil3114 (SATA 150) based 4-ports cards : -stable-amd64 (including last sys/vm MFC but rev. 1.268.2.4 for vm_pageout.c) is rock-solid while doing moderate heavy geom_raid5 testing of a 6-disk system including hot-swapping disk, continuous swap on an Adaptec 2940 (320 disk connected by 50->68 convertor) and continuous NFS. About 4000 irq/seconds and not the slightest problem for three days (including a lot of more or less brutal reboots) 2) same hardware with TX4 cards (-stable of a couple of days ago) crashes when only lookin at it. I switched SATA-cables, SCSI-cards, no difference 3) I just realised our main server has a TX2 (Promise PDC20378 SATA150) which is rock-stable bur running -stable-i386 of Aug 12th (and booting from IDE, no SCSI involved) voili-voila, not a clear picture, but amd64 versus i386, ATA-only versus SCSI+ATA, and/or SATA150 versus SATA300 seem credible suspects. Arno NB, /me votes in favour of including geom_raid5 in -current when code-freeze is over. IMHO this piece of code deserves wider audience and testing. From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 18:44:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72B2316A417 for ; Mon, 27 Aug 2007 18:44:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2EECC13C45A for ; Mon, 27 Aug 2007 18:44:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1IPja1-000IHl-6e for freebsd-current@freebsd.org; Mon, 27 Aug 2007 21:44:53 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Aug 2007 21:44:53 +0300 From: Danny Braniss Message-ID: Subject: -current cross compile for -stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 18:44:54 -0000 till now I used a stable box to cross compile for other arch/stable|current. today i decided to try out -current as a base to cross compile. does it work? since i get: export MAKEOBJDIRPREFIX=/r+d/obj/cs4 cd /r+d/6.2/src; make TARGET_ARCH=amd64 buildworld ... /r+d/6.2/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc -i386.h:451: error: array type has incomplete element type *** Error code 1 Stop in /r+d/6.2/src/gnu/usr.bin/binutils/as. From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 19:01:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A31E16A418 for ; Mon, 27 Aug 2007 19:01:55 +0000 (UTC) (envelope-from pphajek@lbl.gov) Received: from ironport1.lbl.gov (ironport1.lbl.gov [128.3.41.47]) by mx1.freebsd.org (Postfix) with ESMTP id 16A0913C459 for ; Mon, 27 Aug 2007 19:01:54 +0000 (UTC) (envelope-from pphajek@lbl.gov) X-Ironport-SBRS: None X-Brightmail-Tracker: AAAAAA== X-BrightmailFiltered: true X-IronPort-AV: E=Sophos;i="4.19,313,1183359600"; d="scan'208";a="52789488" Received: from eniac.jgi-psf.org ([198.129.89.82]) by ironport1.lbl.gov with ESMTP; 27 Aug 2007 11:48:12 -0700 Received: from eniac.jgi-psf.org (localhost [127.0.0.1]) by eniac.jgi-psf.org (8.12.9+Sun/8.12.9) with ESMTP id l7RIm6b9018007 for ; Mon, 27 Aug 2007 11:48:06 -0700 (PDT) Received: (from phajek@localhost) by eniac.jgi-psf.org (8.12.9+Sun/8.12.9/Submit) id l7RIm6PG018006 for freebsd-current@freebsd.org; Mon, 27 Aug 2007 11:48:06 -0700 (PDT) X-Authentication-Warning: eniac.jgi-psf.org: phajek set sender to pphajek@lbl.gov using -f Date: Mon, 27 Aug 2007 11:48:06 -0700 From: Patrick Hajek To: freebsd-current@freebsd.org Message-ID: <20070827184806.GQ2368@lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Recent changes in atapi-cam? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 19:01:55 -0000 I just upgrading my laptop to current i.e. FreeBSD noe 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Mon Aug 27 11:06:46 PDT 2007 root@noe:/usr/obj/usr/src/sys/NOE i386 The upgrade was successful with one exception: ad0: 95205MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 (cd0:ata1:0:0:0): READ TOC/PMA/ATIP {MMC Proposed}. CDB: 43 0 0 0 0 0 0 0 4 0 (cd0:ata1:0:0:0): CAM Status: SCSI Status Error (cd0:ata1:0:0:0): SCSI Status: Check Condition (cd0:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (cd0:ata1:0:0:0): Invalid field in CDB (cd0:ata1:0:0:0): Unretryable error Writing DVDs have been possible when I hosted FreeBSD 6.2 on the same laptop. After a bit of searching on the FreeBSD current lists, a previous mailing list poster suggested that the recent changes in atapi-cam.c might be the culprit. Any suggestions? Course of action on my part? Thanks -Patrick Here is my kernel config: # # generiC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check # first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.473 2007/07/01 21:47:45 njl # Exp $ cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GENERIC # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Transmission Control Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing ### Debugging for use in -current ##options KDB # Enable kernel debugger support. ##options DDB # Support DDB. ##options GDB # Support remote GDB. ##options INVARIANTS # Enable calls of extra sanity checking ##options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS ##options WITNESS # Enable checks to detect deadlocks and cycles ##options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control #device cpufreq # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives #device atapicam #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device rr232x # Highpoint RocketRAID 232x device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver #device drm # DRM core module required by DRM drivers #device radeondrm # ATI Radeon device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these # NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_scan_ap # 802.11 AP mode scanning device wlan_scan_sta # 802.11 STA mode scanning device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. device iwi # Intel 2200 driver #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device rum # Ralink Technology RT2501USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons -- DOE Joint Genome Institute \ / ASCII RIBBON CAMPAIGN Desk: 925.296.5762 X HELP CURE HTML MAIL Cell: 925.997.4826 / \ PGP Fingerprint 688E B579 3449 28B1 DB14 E15A 76BB C1CA A745 9DAB From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 19:19:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9657D16A418 for ; Mon, 27 Aug 2007 19:19:21 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id EE07213C46C for ; Mon, 27 Aug 2007 19:19:20 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id l7RJJJ2s014815 (8.13.4/1.4); Mon, 27 Aug 2007 21:19:19 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id l7RJJJcZ014812 (8.13.4/2.02); Mon, 27 Aug 2007 21:19:19 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Mon, 27 Aug 2007 21:19:19 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: kern/114155 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 19:19:21 -0000 Hi. Are there any takers for kern/114155 (ptrace interferes with ptrace'd process.) This looks to me like a serious problem. I believe there were also some other reports about ptrace oddities/weirdness. Would be nice to have this fixed before 7.0. I would look into this myself but I'm too busy/tired at the moment. Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 19:53:41 2007 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 C225316A468 for ; Mon, 27 Aug 2007 19:53:41 +0000 (UTC) (envelope-from mkhitrov@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 4847E13C480 for ; Mon, 27 Aug 2007 19:53:40 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so97257ugf for ; Mon, 27 Aug 2007 12:53:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=sTJXhnNm741eCG/RedxfmKf59Rrc7lNCj5Ir9Kbtwcjk3m180IDk5nHsw+B+CIMFdLnRAqsZCUD8foxrOyK7pLRHjDydGqoNu4rwKxU1QJjdARMq9mnd+IMTswaqyG2NGoGOwAoB6N1fYsYsLsD/CCswry9UVxJnKGr2FTdQwPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EEADGYr6XpEIJQ8tustLhfH9JHLsvCrkKd9Z0iOkwZ8+ihwCoDQapj/APeeGDi6vkI0P+h2aMeikiYYy7DM2iaNouSGm1p8BwPiluUgncWpngywt3Cje+XX5O0aJFPArLEaFAD3AzACCIEx3XDcvkFmnwSGeXg8Y2pK+Trc3wIA= Received: by 10.142.178.13 with SMTP id a13mr362634wff.1188244418420; Mon, 27 Aug 2007 12:53:38 -0700 (PDT) Received: by 10.143.10.17 with HTTP; Mon, 27 Aug 2007 12:53:38 -0700 (PDT) Message-ID: <26ddd1750708271253m1e8d9793r996daf103ed8613f@mail.gmail.com> Date: Mon, 27 Aug 2007 15:53:38 -0400 From: "Maxim Khitrov" To: "Stefan Esser" In-Reply-To: <46D31891.4040607@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <26ddd1750708260826q153a3425jf9bea3e8a8a82a70@mail.gmail.com> <46D2B750.5070302@FreeBSD.org> <26ddd1750708270817l2e74001ey26bfc96a61498742@mail.gmail.com> <46D31891.4040607@FreeBSD.org> Cc: current@freebsd.org Subject: Re: Error building openoffice.org-2: cannot compute object file suffix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 19:53:41 -0000 On 8/27/07, Stefan Esser wrote: > Maxim Khitrov wrote: > > > You got my hopes up ;-) No, I don't have that flag, but I had my > > CPUTYPE set to "native." Thought that was the problem, but > > unfortunately that didn't fix it. I first set it back to pentium-m, > > and then commented both CPUTYPE and CFLAGS in my make.conf. Same exact > > thing. Cannot compute suffix of object files. > > > > Any other ideas? > > > I had such a situation once before, and I'm quite sure, that it is > the compiler failing due to bad command line options. As a result > no output file is generated, configured can not determine the object > file name suffix and it terminates after printing the error message > you got. > > You can add an "echo $ac_compile" to just before the test that fails, > that way you should be able to see the command that is to be executed. > Then invoke the compiler (gcc-ooo !!!) just that same way (with any > C source file as additional parameter) and check the error message. > The error messages could in fact have been written to config.log, > but it was not in my failure case. > > Good luck, STefan Did as you suggested, put "echo $ac_compile" in configure, that printed out the compile command which was using $CFLAGS. I then had it run "echo $CFLAGS" and the arguments there contained -march=native. I guess this value was cached somewhere, and it was using it even though make.conf was changed. I didn't run make clean the first time since it takes a while to clean and rebuild everything up to that point. This time around I verified the settings in make.conf, then ran 'make clean install clean' for openoffice. Looks like it was able to build gcc-ooo with no problems. Right now it's building the actual openoffice installation. Thanks for the tip! From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 20:18:09 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 618) id 0367616A418; Mon, 27 Aug 2007 20:18:09 +0000 (UTC) To: freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Date: Mon, 27 Aug 2007 20:18:08 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070827201809.0367616A418@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: Subject: Bug in vr(4) driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 20:18:09 -0000 I recently started writing a driver for the Via Rhine family of chips for VxWorks (they turn up on various x86-based single board systems, and I figured it'd be nice to actually support them out of the box), and along the way, I noticed a subtle bug in the FreeBSD vr(4) driver. The vr_attach() routine unconditionally does this for all supported chips: /* * Windows may put the chip in suspend mode when it * shuts down. Be sure to kick it in the head to wake it * up again. */ VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); The problem is, the VR_STICKHW register is not valid on all Rhine devices. The VT86C100A chip, which is present on the D-Link DFE-530TX boards, doesn't support power management, and its register space is only 128 bytes wide. The VR_STICKHW register offset falls outside this range. This may go unnoticed in most scenarios, but if you happen to have another PCI device in your system which is assigned the register space immediately after that of the Rhine, the vr(4) driver will incorrectly stomp it. In my case, the BIOS on my test board decided to put the register space for my PRO/100 ethernet board right next to the Rhine, and the Rhine driver ended up clobbering the IMR register of the PRO/100 device. (Long story short: the board kept locking up on boot. Took me the better part of the morning suss out why.) The strictly correct thing to do would be to check the PCI config space to make sure the device supports the power management capability and only write to the VR_STICKHW register if it does. A less strictly correct but equally effective thing to do would be: /* * Windows may put the chips that support power management into * suspend mode when it shuts down. Be sure to kick it in the * head to wake it up again. */ if (pci_get_device(dev) != VIA_DEVICEID_RHINE) VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); This is basically the fix I put into my VxWorks driver. I suggest someone update the FreeBSD driver as well. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity got us into this, why can't it get us out?" - Mandy ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 20:48:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2595516A421 for ; Mon, 27 Aug 2007 20:48:35 +0000 (UTC) (envelope-from ss.alert@online.no) Received: from mail42.e.nsc.no (mail42.e.nsc.no [193.213.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8122813C458 for ; Mon, 27 Aug 2007 20:48:34 +0000 (UTC) (envelope-from ss.alert@online.no) Received: from [192.168.1.222] (ti0034a340-1340.bb.online.no [88.90.5.60]) by mail42.nsc.no (8.13.8/8.13.5) with ESMTP id l7RKmVWe021084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 27 Aug 2007 22:48:32 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <0987CEB4-4AD4-4B25-9CE4-68292A3253FC@online.no> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Sverre Svenningsen Date: Mon, 27 Aug 2007 22:48:26 +0200 X-Mailer: Apple Mail (2.752.3) Subject: anyone have experience with HighPoint RocketRaid 2340 + 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, 27 Aug 2007 20:48:35 -0000 All the trouble i've had with the promise Sata300 tx4 cards and zfs on -current is making me think of buying an upgrade, and this pci-e x8 sata raid card looks like it makes sense.. it has official driver support for freebsd 6.2, but it seems to only come as a precompiled kernel module.. will that work on a -current kernel? I'd love to hear from anyone using one of these cards - it's not that expensive especially for 16 ports, but i don't want to buy another dud card :) thanks! -Sverre From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 21:34:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9BD716A418 for ; Mon, 27 Aug 2007 21:34:26 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 5837713C461 for ; Mon, 27 Aug 2007 21:34:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 13158 invoked by uid 399); 27 Aug 2007 21:34:25 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 27 Aug 2007 21:34:25 -0000 X-Originating-IP: 127.0.0.1 Date: Mon, 27 Aug 2007 14:34:23 -0700 (PDT) From: Doug Barton To: Julian Stacey In-Reply-To: <200708271112.l7RBCqfT054850@fire.js.berklix.net> Message-ID: References: <200708271112.l7RBCqfT054850@fire.js.berklix.net> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 21:34:26 -0000 On Mon, 27 Aug 2007, Julian Stacey wrote: > OK, i recognise you posted current@, but here: > uname -r > 6.2-RELEASE Next time you might want to think twice before a response like this. It turns out that the problem actually was specific to -current during a specified time period. In general if you're not _sure_ you know the answer to a question, you're better off waiting at least a few hours, maybe even a day to see if someone else does. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 21:35:20 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B72F016A419 for ; Mon, 27 Aug 2007 21:35:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 541DF13C46B for ; Mon, 27 Aug 2007 21:35:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 14427 invoked by uid 399); 27 Aug 2007 21:35:19 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 27 Aug 2007 21:35:19 -0000 X-Originating-IP: 127.0.0.1 Date: Mon, 27 Aug 2007 14:35:17 -0700 (PDT) From: Doug Barton To: Danny Braniss In-Reply-To: Message-ID: References: <20070827131045.6jv7qrdlw0wg0sos@webmail.leidinger.net> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii Cc: Alexander Leidinger , freebsd-current@freebsd.org Subject: Re: sed misbehaving? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 21:35:20 -0000 On Mon, 27 Aug 2007, Danny Braniss wrote: > i guess in -current, Aug 19 is old :-) In the run-up to a new release (especially a .0) you're better off building up to the minute stuff before reporting a problem. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 21:37:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D3A116A418 for ; Mon, 27 Aug 2007 21:37:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 2A5F413C474 for ; Mon, 27 Aug 2007 21:37:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 16754 invoked by uid 399); 27 Aug 2007 21:37:09 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 27 Aug 2007 21:37:09 -0000 X-Originating-IP: 127.0.0.1 Date: Mon, 27 Aug 2007 14:37:07 -0700 (PDT) From: Doug Barton To: Erwin Lansing In-Reply-To: <20070827104738.GX93965@droso.net> Message-ID: References: <200708270922.06233.hselasky@c2i.net> <20070827104738.GX93965@droso.net> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: Ports and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 21:37:10 -0000 On Mon, 27 Aug 2007, Erwin Lansing wrote: > On Mon, Aug 27, 2007 at 09:22:05AM +0200, Hans Petter Selasky wrote: >> Hi, >> >> When you install a port that has several sub-ports, is there way to run >> through all the configuration menus recursivly, so that the compilation does >> not stop all the time asking for user input? >> > There is a config-recursive target in ports, so a simple 'make > config-recursive' in the master port should do the trick for you. That's true if the options you choose don't change the dependencies, but if they do, you're liable to miss something. What portmaster does is to run make config in the parent, then build the dependency list. Then it spawns a new child for each dependency that needs to be rebuilt, and repeats the process. That way you can be sure that you've updated everything before the build starts. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Aug 27 22:14:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57D8116A417 for ; Mon, 27 Aug 2007 22:14:59 +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 04CD213C467 for ; Mon, 27 Aug 2007 22:14:58 +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 6BD6E471D4; Mon, 27 Aug 2007 18:14:58 -0400 (EDT) Date: Mon, 27 Aug 2007 23:14:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ganbold In-Reply-To: <46D25242.10504@micom.mng.net> Message-ID: <20070827231419.H30469@fledge.watson.org> References: <46D25242.10504@micom.mng.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-current@freebsd.org" Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 22:14:59 -0000 On Mon, 27 Aug 2007, Ganbold wrote: > I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS enabled > kernel. Try the same thing again without INVARIANTS and WITNESS, both of which can consume a lot of CPU in kernel on a very active system, especially if lots of vnodes are being allocated and freed. Especially WITNESS. Robert N M Watson Computer Laboratory University of Cambridge > > daemon# uname -an > FreeBSD daemon.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Thu Aug 23 > 17:59:17 ULAT 2007 > tsgan@daemon.micom.mng.net:/usr/obj/usr/src/sys/GDAEMON i386 > daemon# > > When compiling something (buildworld or making wine for example) inside from > X/gnome > my computer becomes very slow. > > top shows while compiling wine: > > last pid: 38660; load averages: 3.10, 2.24, 1.33 > up 3+02:07:05 12:11:38 > 106 processes: 3 running, 102 sleeping, 1 zombie > CPU states: 90.2% user, 0.0% nice, 9.8% system, 0.0% interrupt, 0.0% idle > Mem: 704M Active, 63M Inact, 168M Wired, 39M Cache, 111M Buf, 21M Free > Swap: 2048M Total, 195M Used, 1853M Free, 9% Inuse > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 902 tsgan 1 96 0 147M 134M RUN 929:41 3.96% Xorg > 38659 root 1 96 0 15556K 12256K RUN 0:00 3.47% cc1 > 1206 tsgan 1 44 19 156M 36940K select 178:06 0.00% > operapluginwrapper > 978 tsgan 1 44 0 212M 173M select 103:26 0.00% opera > 954 tsgan 1 44 0 35236K 18372K select 11:59 0.00% wnck-applet > 975 tsgan 7 44 0 198M 159M ucond 8:53 0.00% > thunderbird-bin > 922 tsgan 1 44 0 4808K 1460K select 4:43 0.00% gam_server > 956 tsgan 1 44 0 35324K 16328K select 4:36 0.00% > mixer_applet2 > 962 tsgan 1 44 0 13736K 5936K select 1:57 0.00% > gnome-screensaver > 1224 tsgan 1 44 0 70232K 28900K select 1:33 0.00% pidgin > 1591 tsgan 1 44 19 5520K 772K select 1:17 0.00% > operapluginwrapper > 772 root 1 44 0 4496K 928K select 1:03 0.00% > hald-addon-storage > 930 tsgan 1 44 0 16204K 8744K select 0:48 0.00% metacity > 441 root 1 44 0 3276K 592K select 0:45 0.00% moused > 765 haldaemon 1 44 0 6164K 2252K select 0:41 0.00% hald > ... > > Is it due to SCHED_ULE makes a process CPU greedy and that is why my computer > becomes slow? > Or it is something else? What SCHED_ULE sysctl knobs should I test here? > As I recall correctly I have never experienced such problems until recently. > Maybe I'm wrong here. > > thanks, > > Ganbold > > > -- > X windows: Accept any substitute. If it's broke, don't fix it. If it ain't > broke, fix it. Form follows malfunction. The Cutting Edge of Obsolescence. > The trailing edge of software technology. Armageddon never looked so good. > Japan's secret weapon. You'll envy the dead. Making the world safe for > competing window systems. Let it get in YOUR way. The problem for your > problem. If it starts working, we'll fix it. Pronto. It could be worse, but > it'll take time. Simplicity made complex. The greatest productivity aid since > typhoid. Flakey and built to stay that way. One thousand monkeys. One > thousand MicroVAXes. One thousand years. X windows. > > _______________________________________________ > 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 Aug 27 22:59:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CAF16A418 for ; Mon, 27 Aug 2007 22:59:46 +0000 (UTC) (envelope-from boris@brooknet.com.au) Received: from pecan.exetel.com.au (pecan.exetel.com.au [220.233.0.17]) by mx1.freebsd.org (Postfix) with ESMTP id AFBC613C468 for ; Mon, 27 Aug 2007 22:59:46 +0000 (UTC) (envelope-from boris@brooknet.com.au) Received: from 28.201.233.220.exetel.com.au ([220.233.201.28] helo=[192.168.100.148]) by pecan.exetel.com.au with esmtp (Exim 4.63) (envelope-from ) id 1IPbXi-0005CO-9s; Mon, 27 Aug 2007 20:09:58 +1000 In-Reply-To: <46D28CA1.6010207@yahoo.com> References: <200708270922.06233.hselasky@c2i.net> <46D28CA1.6010207@yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3240569A-2DFC-4F07-BBF3-9996A899E196@brooknet.com.au> Content-Transfer-Encoding: 7bit From: Sam Lawrance Date: Mon, 27 Aug 2007 20:10:03 +1000 To: John Merryweather Cooper X-Mailer: Apple Mail (2.752.3) Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: Ports and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2007 22:59:47 -0000 Alternatively I believe there is a "config-recursive" target for ports. On 27/08/2007, at 6:34 PM, John Merryweather Cooper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yes. Install port-mgmt/portmaster and then run portmaster for the > desired port. Any port or sub-port not already configured will have a > 'make config' run on it before the build starts. > > jmc > > Hans Petter Selasky wrote: >> Hi, >> >> When you install a port that has several sub-ports, is there way >> to run >> through all the configuration menus recursivly, so that the >> compilation does >> not stop all the time asking for user input? >> >> --HPS >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFG0oyhpwq+q9/rT0gRAnSJAJkBvgHiItR6zliD/OuqXsykjrXMYgCfT/Tf > jz7JpLrg5swbD9jEGAktz64= > =4vY0 > -----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 Tue Aug 28 00:05:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7C1716A473 for ; Tue, 28 Aug 2007 00:05:31 +0000 (UTC) (envelope-from prvs=1759337cf1=killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 70B2213C46B for ; Tue, 28 Aug 2007 00:05:14 +0000 (UTC) (envelope-from prvs=1759337cf1=killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 ([212.135.219.182]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.6.0) with ESMTP id md50004147844.msg for ; Tue, 28 Aug 2007 00:48:05 +0100 Message-ID: <001101c7e904$a1bbd110$b6db87d4@multiplay.co.uk> From: "Steven Hartland" To: , "Sverre Svenningsen" References: <0987CEB4-4AD4-4B25-9CE4-68292A3253FC@online.no> Date: Tue, 28 Aug 2007 00:47:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-MDRemoteIP: 212.135.219.182 X-Return-Path: prvs=1759337cf1=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-Spam-Processed: multiplay.co.uk, Tue, 28 Aug 2007 00:48:05 +0100 X-MDAV-Processed: multiplay.co.uk, Tue, 28 Aug 2007 00:48:06 +0100 Cc: Subject: Re: anyone have experience with HighPoint RocketRaid 2340 + 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: Tue, 28 Aug 2007 00:05:31 -0000 If your looking for an SATA card with good FreeBSD support and good performance I can recommend the Areca ones. Not the cheapest on the market but good. I've used the Highpoint 1820a in the past and once the driver was fixed its proved reliable. That might have been a different story had it been a precompiled kernel module so I would personally stay clear of the any card with that. Regards Steve ----- Original Message ----- From: "Sverre Svenningsen" > All the trouble i've had with the promise Sata300 tx4 cards and zfs > on -current is making me think of buying an upgrade, and this pci-e > x8 sata raid card looks like it makes sense.. it has official driver > support for freebsd 6.2, but it seems to only come as a precompiled > kernel module.. will that work on a -current kernel? > > I'd love to hear from anyone using one of these cards - it's not that > expensive especially for 16 ports, but i don't want to buy another > dud card :) ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 00:19:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 598D716A418 for ; Tue, 28 Aug 2007 00:19:06 +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 26AEE13C4B6 for ; Tue, 28 Aug 2007 00:19:05 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 61DA917389; Mon, 27 Aug 2007 18:59:03 -0500 (CDT) Date: Mon, 27 Aug 2007 18:59:03 -0500 From: "Christian S.J. Peron" To: Yuri Pankov Message-ID: <20070827235903.GA1183@sub.vaned.net> References: <20070824081726.GC6571@darklight.org.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <20070824081726.GC6571@darklight.org.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: rtfree: 0xffffff00036fb1e0 has 1 refs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 00:19:07 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Based on some comments in rtfree, we should only be calling rtfree if we are sure we own the last reference to the route. I am not sure this is the case in the stf/gif cases... Please try the attached patch and let me know if there are any ill effects. On Fri, Aug 24, 2007 at 12:17:26PM +0400, Yuri Pankov wrote: > Hi, > > I've recently started using he.net's ipv6 tunnel and getting this message: > rtfree: 0xffffff00036fb1e0 has 1 refs > > I've added kdb_backtrace() in route.c as Gleb Smirnoff suggested before. Here's > backtrace: > rtfree: 0xffffff00036fb1e0 has 1 refs > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > rtfree() at rtfree+0xba > gif_encapcheck4() at gif_encapcheck4+0x118 > gif_encapcheck() at gif_encapcheck+0xfd > encap4_input() at encap4_input+0xcc > ip_input() at ip_input+0xc0 > tunwrite() at tunwrite+0x1d5 > giant_write() at giant_write+0x51 > devfs_write_f() at devfs_write_f+0x9c > dofilewrite() at dofilewrite+0x85 > kern_writev() at kern_writev+0x4c > write() at write+0x54 > syscall() at syscall+0x1ce > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (4, FreeBSD ELF64, write), rip = 0x80125c35c, rsp = 0x7fffffffda18, > rbp = 0x60 --- > > > ifconfig: > gif0: flags=8051 metric 0 mtu 1280 > tunnel inet 194.186.18.14 --> 64.71.128.83 > inet6 fe80::20f:eaff:fe7d:f320%gif0 prefixlen 64 scopeid 0x5 > inet6 2001:470:1f03:2d5::2 --> 2001:470:1f03:2d5::1 prefixlen 128 > inet6 2001:470:1f01:725::1 prefixlen 64 > tun0: flags=8051 metric 0 mtu 1500 > inet6 fe80::20f:eaff:fe7d:f320%tun0 prefixlen 64 scopeid 0x6 > inet 194.186.18.14 --> 194.186.18.2 netmask 0xffffff00 > Opened by PID 458 > > > Yuri > _______________________________________________ > 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" -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer --opJtzjQTFsWo+cga Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="rt.diff" Index: net/if_stf.c =================================================================== RCS file: /usr/ncvs/src/sys/net/if_stf.c,v retrieving revision 1.59 diff -u -r1.59 if_stf.c --- net/if_stf.c 22 Oct 2006 11:52:15 -0000 1.59 +++ net/if_stf.c 27 Aug 2007 23:51:19 -0000 @@ -607,10 +607,10 @@ (u_int32_t)ntohl(sin.sin_addr.s_addr)); #endif if (rt) - rtfree(rt); + RTFREE_LOCKED(rt); return -1; } - rtfree(rt); + RTFREE_LOCKED(rt); } return 0; Index: netinet/in_gif.c =================================================================== RCS file: /usr/ncvs/src/sys/netinet/in_gif.c,v retrieving revision 1.36 diff -u -r1.36 in_gif.c --- netinet/in_gif.c 10 May 2007 15:58:47 -0000 1.36 +++ netinet/in_gif.c 27 Aug 2007 23:48:04 -0000 @@ -374,10 +374,10 @@ (u_int32_t)ntohl(sin.sin_addr.s_addr)); #endif if (rt) - rtfree(rt); + RTFREE_LOCKED(rt); return 0; } - rtfree(rt); + RTFREE_LOCKED(rt); } return 32 * 2; --opJtzjQTFsWo+cga-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 01:03:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D774416A418 for ; Tue, 28 Aug 2007 01:03:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 8981413C465 for ; Tue, 28 Aug 2007 01:03:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2327986waf for ; Mon, 27 Aug 2007 18:03:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=lUFpwrIcYX1wSsYUxMdi7zqkaGOVrhLJmxBNx7jNvFQKsJBgmcuMjc315dT5gJ1VYVPGrHiLAkuvhRUSooTEwcI97taud4qqGMs/Tjeo4BpeQx06O7fX2OFltuyos7pHFh7w8QLI0d+JtQV/ZckWjOhVMWfJVKsYTwq1xEZKoDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=K5UV9g2t3fOd9CRv7lZKMfI6fpeo0iCRa4TbzdgMT+6fRXucnC76bSxamDVQrmPu0xwgs5+vXm9S5eAL0itm8YhU+jlFImzBFjML75zzicZJXA0qjrMr82uOuNSqaS7r8Qjfk+jerr6SlWL52iXZ1IsJIHrPm/LXzMVTiAh89FA= Received: by 10.115.90.1 with SMTP id s1mr3236427wal.1188263001696; Mon, 27 Aug 2007 18:03:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id v37sm9883040wah.2007.08.27.18.03.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2007 18:03:20 -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 l7S13AP6085766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2007 10:03:11 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l7S13AFG085765; Tue, 28 Aug 2007 10:03:10 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 28 Aug 2007 10:03:10 +0900 From: Pyun YongHyeon To: Bill Paul Message-ID: <20070828010310.GA85263@cdnetworks.co.kr> References: <20070827201809.0367616A418@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20070827201809.0367616A418@hub.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Bug in vr(4) driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 01:03:23 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 27, 2007 at 08:18:08PM +0000, Bill Paul wrote: > > I recently started writing a driver for the Via Rhine family of chips > for VxWorks (they turn up on various x86-based single board systems, > and I figured it'd be nice to actually support them out of the box), > and along the way, I noticed a subtle bug in the FreeBSD vr(4) driver. > > The vr_attach() routine unconditionally does this for all supported > chips: > > /* > * Windows may put the chip in suspend mode when it > * shuts down. Be sure to kick it in the head to wake it > * up again. > */ > VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); > > The problem is, the VR_STICKHW register is not valid on all Rhine > devices. The VT86C100A chip, which is present on the D-Link DFE-530TX > boards, doesn't support power management, and its register space is > only 128 bytes wide. The VR_STICKHW register offset falls outside this > range. This may go unnoticed in most scenarios, but if you happen to have > another PCI device in your system which is assigned the register > space immediately after that of the Rhine, the vr(4) driver will > incorrectly stomp it. In my case, the BIOS on my test board decided > to put the register space for my PRO/100 ethernet board right next > to the Rhine, and the Rhine driver ended up clobbering the IMR register > of the PRO/100 device. (Long story short: the board kept locking up on > boot. Took me the better part of the morning suss out why.) > > The strictly correct thing to do would be to check the PCI config space > to make sure the device supports the power management capability and only > write to the VR_STICKHW register if it does. A less strictly correct > but equally effective thing to do would be: > > /* > * Windows may put the chips that support power management into > * suspend mode when it shuts down. Be sure to kick it in the > * head to wake it up again. > */ > if (pci_get_device(dev) != VIA_DEVICEID_RHINE) > VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); > > This is basically the fix I put into my VxWorks driver. I suggest someone > update the FreeBSD driver as well. > Hi, I don't have vr(4) hardwares(if I had I would have converted vr(4) to use bus_dma(9)). Would you review/test the attached patch? -- Regards, Pyun YongHyeon --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vr.diff" Index: if_vr.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_vr.c,v retrieving revision 1.126 diff -u -r1.126 if_vr.c --- if_vr.c 23 Apr 2007 12:19:02 -0000 1.126 +++ if_vr.c 28 Aug 2007 01:00:34 -0000 @@ -90,6 +90,7 @@ #include +#include #include #define VR_USEIOSPACE @@ -513,6 +514,7 @@ struct ifnet *ifp; int error = 0, rid; struct vr_type *t; + int pmc; sc = device_get_softc(dev); sc->vr_dev = dev; @@ -591,7 +593,8 @@ * shuts down. Be sure to kick it in the head to wake it * up again. */ - VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); + if (pci_find_extcap(dev, PCIY_PMG, &pmc) == 0) + VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); /* Reset the adapter. */ vr_reset(sc); --9jxsPFA5p3P2qPhR-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 01:15:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3504916A419 for ; Tue, 28 Aug 2007 01:15:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id DBA7C13C457 for ; Tue, 28 Aug 2007 01:15:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id AC1DBEB80F5; Tue, 28 Aug 2007 09:15:34 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id iMMDRfMkTsNc; Tue, 28 Aug 2007 09:15:27 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id E65B1EB2979; Tue, 28 Aug 2007 09:15:26 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=qy01pESvUixfk3pjG9ieUe6prUNmV+twGH26eWv1RjhOzQyTw1ldbEzcobMANUhLc ZyN/xYArU1yM53w0kyHoQ== Message-ID: <46D37727.6010003@delphij.net> Date: Tue, 28 Aug 2007 09:15:19 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigEB072A04E80FD1B3556DBA7C" Cc: freebsd-current@freebsd.org Subject: Re: -current cross compile for -stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 01:15:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB072A04E80FD1B3556DBA7C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Danny Braniss wrote: > till now I used a stable box to cross compile for other arch/stable|cur= rent. > today i decided to try out -current as a base to cross compile. does i= t > work? since i get: >=20 > export MAKEOBJDIRPREFIX=3D/r+d/obj/cs4 > cd /r+d/6.2/src; make TARGET_ARCH=3Damd64 buildworld > ... > /r+d/6.2/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/c= onfig/tc > -i386.h:451: error: array type has incomplete element type > *** Error code 1 >=20 > Stop in /r+d/6.2/src/gnu/usr.bin/binutils/as. This won't work. In order to build -STABLE you have to install a chrooted RELENG_6 environment and chroot into it to make it work. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigEB072A04E80FD1B3556DBA7C 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.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG03cnOfuToMruuMARCuY2AJ9ufl1k3JMEyiC2rQ1cGUrj4X9gTACfQxS1 n6Y87HsL5ylIBEY6911oM68= =4tyE -----END PGP SIGNATURE----- --------------enigEB072A04E80FD1B3556DBA7C-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 02:10:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BDCC16A419 for ; Tue, 28 Aug 2007 02:10:56 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5E44613C442 for ; Tue, 28 Aug 2007 02:10:56 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IPqXe-0002vh-Qq for ; Tue, 28 Aug 2007 11:10:54 +0900 Message-ID: <46D3842E.5040002@fusiongol.com> Date: Tue, 28 Aug 2007 11:10:54 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: Re: Encrypted 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: Tue, 28 Aug 2007 02:10:56 -0000 CW> I'm currently using a zraid consisting of three drives. Lately I CW> wonder what the best way would be to encrypt it. CW> I read the chapter dealing with disk encryption in the handbook, and CW> decided to use GELI. Is there anyone here on the list who has some CW> experiences with ZFS on encrypted GELI devices? Are there some CW> performance specs around? At the moment, I have created a zvol on top of ZFS and then turned it into a GELI device. Then I have run newfs on that GELI device and mounted it as a volume. It's less than an ideal way of having encryption on ZFS (you get some of the benefits of ZFS, but the filesystem on top of GELI is still UFS), but it works anyway. On my 2.13Ghz Core2 Duo with 2GB of RAM under amd64-current, my system load doesn't break much of a sweat, reading to and from the GELI volume - and speeds are tolerable. Since I have the Promise card issue, I can only give bechmarks dated from the 200706 snapshot, and I'm sure zfs performance has improved since then. From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 03:29:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9087016A41A for ; Tue, 28 Aug 2007 03:29:19 +0000 (UTC) (envelope-from john@guildsoftware.com) Received: from ix.guildsoftware.com (ix.guildsoftware.com [216.136.125.5]) by mx1.freebsd.org (Postfix) with ESMTP id 73B5F13C442 for ; Tue, 28 Aug 2007 03:29:19 +0000 (UTC) (envelope-from john@guildsoftware.com) Received: from [172.17.172.7] (gargravarr.guildsoftware.com [216.136.125.2]) by ix.guildsoftware.com (Postfix) with ESMTP id A4AAFB8023 for ; Mon, 27 Aug 2007 22:13:43 -0500 (CDT) Message-ID: <46D3936B.5000401@guildsoftware.com> Date: Mon, 27 Aug 2007 22:15:55 -0500 From: John Bergman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: lock order reversal with pf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 03:29:19 -0000 Sorry if this has been previously reported, didn't see it in a quick search. Machine is SMP with ULE and 08/22 source, happens sporadically on bootup once I compiled in pf: WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/mirror/gm0s1a lock order reversal: 1st 0xc0a7636c pf task mtx (pf task mtx) @ contrib/pf/net/pf_ioctl.c:1304 2nd 0xc0af61ac ifnet (ifnet) @ net/if.c:1494 KDB: stack backtrace: db_trace_self_wrapper(c09ab14c,d5166a38,c06fd0a6,c09ad5ee,c0af61ac,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c09ad5ee,c0af61ac,c09b49e2,c09b49e2,c09b4848,...) at kdb_backtrace+0x29 witness_checkorder(c0af61ac,9,c09b483f,5d6,0,...) at witness_checkorder+0x6d6 _mtx_lock_flags(c0af61ac,0,c09b483f,5d6,c303e260,...) at _mtx_lock_flags+0xbc ifunit(c303e260,0,c0972988,518,c0af5790,...) at ifunit+0x2f pfioctl(c2fc9200,c0104414,c303e260,3,c2fcc440,...) at pfioctl+0x234f devfs_ioctl_f(c3057000,c0104414,c303e260,c2d75500,c2fcc440,...) at devfs_ioctl_f+0xd5 kern_ioctl(c2fcc440,3,c0104414,c303e260,1000000,...) at kern_ioctl+0x253 ioctl(c2fcc440,d5166cfc,c,c09d6159,c0a44c50,...) at ioctl+0x13f syscall(d5166d38) at syscall+0x2f3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281a6c43, esp = 0xbfbfde5c, ebp = 0xbfbfde88 --- bge0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 04:00:27 2007 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 E77CD16A469 for ; Tue, 28 Aug 2007 04:00:27 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 725DD13C458 for ; Tue, 28 Aug 2007 04:00:27 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 09EF61CC58; Tue, 28 Aug 2007 16:00:26 +1200 (NZST) Date: Tue, 28 Aug 2007 16:00:26 +1200 From: Andrew Thompson To: FreeBSD Current Message-ID: <20070828040026.GB42201@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: multicast packets from bpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 04:00:28 -0000 --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, At the moment packets injected via bpf do not get the M_BCAST or M_MCAST flags set. One consequence of this is that it messes up broadcasting from if_bridge which assumes these flags are correct, using dhcpd on a bridge interface is one way to trigger it. Attached is a patch (bpf_mcast.diff) that fixes this up. There is some concern about having bpf inspecting the protocol headers but i seems unavoidable in order to determine if its multicast. tap(4) was also thought to have this problem but it turned out not to since it passes the frames to ether_input. The other way is for the bridge to recheck for multicast destinations for locally generated packets (bridge_bpfmcast.diff), but this is less desirable. Andrew --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bpf_mcast.diff" Index: bpf.c =================================================================== RCS file: /home/ncvs/src/sys/net/bpf.c,v retrieving revision 1.180 diff -u -p -r1.180 bpf.c --- bpf.c 6 Aug 2007 14:26:00 -0000 1.180 +++ bpf.c 28 Aug 2007 01:34:27 -0000 @@ -599,6 +599,7 @@ bpfwrite(struct cdev *dev, struct uio *u struct ifnet *ifp; struct mbuf *m, *mc; struct sockaddr dst; + struct ether_header *eh; int error, hlen; if (d->bd_bif == NULL) @@ -620,6 +621,20 @@ bpfwrite(struct cdev *dev, struct uio *u if (error) return (error); + /* Check for multicast destination */ + switch (d->bd_bif->bif_dlt) { + case DLT_EN10MB: + eh = mtod(m, struct ether_header *); + if (ETHER_IS_MULTICAST(eh->ether_dhost)) { + if (bcmp(ifp->if_broadcastaddr, eh->ether_dhost, + ETHER_ADDR_LEN) == 0) + m->m_flags |= M_BCAST; + else + m->m_flags |= M_MCAST; + } + break; + } + if (d->bd_hdrcmplt) dst.sa_family = pseudo_AF_HDRCMPLT; --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bridge_bpfmcast.diff" Index: if_bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridge.c,v retrieving revision 1.102 diff -u -p -r1.102 if_bridge.c --- if_bridge.c 1 Aug 2007 00:33:52 -0000 1.102 +++ if_bridge.c 14 Aug 2007 02:11:16 -0000 @@ -1852,9 +1852,16 @@ bridge_start(struct ifnet *ifp) dst_if = NULL; BRIDGE_LOCK(sc); - if ((m->m_flags & (M_BCAST|M_MCAST)) == 0) { + if (ETHER_IS_MULTICAST(eh->ether_dhost)) + /* + * XXX bpf injected packets do not have M_MCAST or + * M_BCAST set, bridge_broadcast() makes assumptions + * based on this. + */ + if ((m->m_flags & (M_BCAST|M_MCAST)) == 0) + m->m_flags |= M_MCAST; + else dst_if = bridge_rtlookup(sc, eh->ether_dhost, 1); - } if (dst_if == NULL) bridge_broadcast(sc, ifp, m, 0); --QTprm0S8XgL7H0Dt-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 04:36:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DD2516A417 for ; Tue, 28 Aug 2007 04:36:18 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 046C013C48D for ; Tue, 28 Aug 2007 04:36:17 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1394672pyb for ; Mon, 27 Aug 2007 21:36:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=AmPcp62xXzh3atf4Ira9Svj1PlXnnm1gSqchAKT4of0Wvj2mOuHKJZmk7wn+5vMw2aqCNg9SQiuC05nR+/Yoz+1sFXb7XzxobOV7EhYLhVk9FVcb28V+fZH+2D6ed0FlU6BZ0A/r5h7DEKRr3rZER4bscEVeuCK8qyBpz196gyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r3yiiX9x+4EDfmg3UhEzVIYJVTCRBhgZXwakZqVZIyIptPG1ZICdKdaIjbVKk7MFJQrMSni7lGhBWpJNja8jlwNBQwo9umhJsgdmGWL+33VOQWPZAyp3JPGgnene9hIFGCcM11PNDE4MFseUvbroI9X/Iq6AnthVYJsWVFpHEKU= Received: by 10.65.119.14 with SMTP id w14mr12256236qbm.1188275776727; Mon, 27 Aug 2007 21:36:16 -0700 (PDT) Received: by 10.64.185.10 with HTTP; Mon, 27 Aug 2007 21:36:16 -0700 (PDT) Message-ID: <6eb82e0708272136m3511318egbbdb9d2114e5c0f7@mail.gmail.com> Date: Tue, 28 Aug 2007 12:36:16 +0800 From: "Rong-en Fan" To: d@delphij.net In-Reply-To: <46D37727.6010003@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46D37727.6010003@delphij.net> Cc: freebsd-current@freebsd.org Subject: Re: -current cross compile for -stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 04:36:18 -0000 On 8/28/07, LI Xin wrote: > Danny Braniss wrote: > > till now I used a stable box to cross compile for other arch/stable|current. > > today i decided to try out -current as a base to cross compile. does it > > work? since i get: > > > > export MAKEOBJDIRPREFIX=/r+d/obj/cs4 > > cd /r+d/6.2/src; make TARGET_ARCH=amd64 buildworld > > ... > > /r+d/6.2/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc > > -i386.h:451: error: array type has incomplete element type > > *** Error code 1 > > > > Stop in /r+d/6.2/src/gnu/usr.bin/binutils/as. > > This won't work. In order to build -STABLE you have to install a > chrooted RELENG_6 environment and chroot into it to make it work. I think there is a hack for ports' tinderbox, patch is at http://www.marcuscom.com/downloads/binutils.diff Not sure it appears in ports@ mailing or tinderbox's. Regards, Rong-En Fan > > Cheers, > -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > > > From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 04:41:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E7B716A420; Tue, 28 Aug 2007 04:41:46 +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 D7E4C13C468; Tue, 28 Aug 2007 04:41:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IPstU-000Ob5-MJ; Tue, 28 Aug 2007 07:41:45 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7S4fXY2034333; Tue, 28 Aug 2007 07:41:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l7S4fXZ3034332; Tue, 28 Aug 2007 07:41:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Aug 2007 07:41:33 +0300 From: Kostik Belousov To: Robert Watson Message-ID: <20070828044133.GR2332@deviant.kiev.zoral.com.ua> References: <46D25242.10504@micom.mng.net> <20070827231419.H30469@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HzaOE8X7KzPzAQEl" Content-Disposition: inline In-Reply-To: <20070827231419.H30469@fledge.watson.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 4204c266f86c3e9b1e0231505dd73b85 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1410 [August 27 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Ganbold , "freebsd-current@freebsd.org" Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 04:41:46 -0000 --HzaOE8X7KzPzAQEl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2007 at 11:14:58PM +0100, Robert Watson wrote: >=20 > On Mon, 27 Aug 2007, Ganbold wrote: >=20 > >I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS=20 > >enabled kernel. >=20 > Try the same thing again without INVARIANTS and WITNESS, both of which ca= n=20 > consume a lot of CPU in kernel on a very active system, especially if lot= s=20 > of vnodes are being allocated and freed. Especially WITNESS. It does happens on the kernels without debug options, in particular, WITNESS and INVARIANTS. It happens when a lot of short-lived processes are rapidly created. Compilation is a good example of such workload; running configure script is even better. --HzaOE8X7KzPzAQEl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG06d8C3+MBN1Mb4gRAqisAKDrMamxMNqS40/pe3ezT/xozB7bawCfSfrc 8QQz2WuOWQVqrtL0jyHFeRQ= =m33C -----END PGP SIGNATURE----- --HzaOE8X7KzPzAQEl-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 04:48:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A38C516A419 for ; Tue, 28 Aug 2007 04:48:24 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 9E40713C46C for ; Tue, 28 Aug 2007 04:48:23 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IPszt-000C1C-TY; Tue, 28 Aug 2007 13:48:14 +0900 Message-ID: <46D3A90D.8050703@micom.mng.net> Date: Tue, 28 Aug 2007 12:48:13 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: Kostik Belousov References: <46D25242.10504@micom.mng.net> <20070827231419.H30469@fledge.watson.org> <20070828044133.GR2332@deviant.kiev.zoral.com.ua> In-Reply-To: <20070828044133.GR2332@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-current@freebsd.org" , Robert Watson Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 04:48:24 -0000 Kostik Belousov wrote: > On Mon, Aug 27, 2007 at 11:14:58PM +0100, Robert Watson wrote: > >> On Mon, 27 Aug 2007, Ganbold wrote: >> >> >>> I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS >>> enabled kernel. >>> >> Try the same thing again without INVARIANTS and WITNESS, both of which can >> consume a lot of CPU in kernel on a very active system, especially if lots >> of vnodes are being allocated and freed. Especially WITNESS. >> > > It does happens on the kernels without debug options, in particular, > WITNESS and INVARIANTS. > > It happens when a lot of short-lived processes are rapidly created. > Compilation is a good example of such workload; running configure script > is even better. > What would be a solution to this kind of problems? thanks, Ganbold -- That's the thing about people who think they hate computers. What they really hate is lousy programmers. -- Larry Niven and Jerry Pournelle in "Oath of Fealty" From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 06:55:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA3E516A46B for ; Tue, 28 Aug 2007 06:55:00 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by mx1.freebsd.org (Postfix) with ESMTP id 636EA13C45E for ; Tue, 28 Aug 2007 06:55:00 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so2327998mue for ; Mon, 27 Aug 2007 23:54:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=IoB7AeGn6PQ2WSKrcjO931nvvdBnxtBDmF3PQt81oM+6RQoy75c99cIgjfFZi2Xw3AeXHY3Tzcz4M70v9xXcqMtvBgymcAAn8kwCmt+AH4jkP2/6HzFY/DWfnuDRvbg2eZ47XPa9Wn88smW8Mc8NAJEhbNp8zfTiI2r9qxhviPA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=hgoy4pm9kKUNrXXi5IWT6Dt9yLi+W/Y9u6zV9oSJ1ZaRmMWLsnK1YnKeM0nkj6dJke3t3F/8j0ijX3e3niEkECQHnkx9E8bB4VYxVvtxte8TLqvUuG7CLD45UeDS/JFr7+u13DaaNteEFfO/HjTcn6nFp9tlA3xv0MsRHmMXW3M= Received: by 10.86.77.5 with SMTP id z5mr5548751fga.1188284098380; Mon, 27 Aug 2007 23:54:58 -0700 (PDT) Received: by 10.86.59.6 with HTTP; Mon, 27 Aug 2007 23:54:58 -0700 (PDT) Message-ID: <790a9fff0708272354q31afca4fx1e787f9592a6a4e0@mail.gmail.com> Date: Tue, 28 Aug 2007 01:54:58 -0500 From: "Scot Hetzel" To: FreeBSD-CURRENT MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6201_15382802.1188284098363" Subject: Setting CPUTYPE=native, fails to set MACHINE_CPU correctly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 06:55:01 -0000 ------=_Part_6201_15382802.1188284098363 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Gcc 4.2 has a new cpu_type (native) for x86 and amd64 systems. This cpu_type is to allow gcc to automatically detect the processor type that gcc is running on. The problem is that setting CPUTYPE?=native in either src.conf or make.conf will cause MACHINE_CPU to be set to the wrong value for the native cpu. For example on a system where the processor is a k8, setting CPUTYPE to k8, shows that MACHINE_CPU is set as follows: hp010# make -V MACHINE_CPU -DCPUTYPE=k8 k8 3dnow amd64 sse2 sse mmx But setting CPUTYPE to native on a k8 system sets MACHINE_CPU to this value: hp010# make -V MACHINE_CPU -DCPUTYPE=native unknown amd64 sse2 sse mmx After patching share/mk/bsd.cpu.mk (see attachment) or the last patch to PR 112997: http://www.freebsd.org/cgi/query-pr.cgi?pr=112997 setting CPUTYPE to native now works correctly when setting the value for MACHINE_CPU: hp010# make -V MACHINE_CPU -V CPUTYPE -DCPUTYPE=native k8 3dnow amd64 sse2 sse mmx k8 Could this get committed before -CURRENT is branched. Thanks, Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ------=_Part_6201_15382802.1188284098363 Content-Type: text/plain; name=gcc_native.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_f5w1mjpl Content-Disposition: attachment; filename="gcc_native.txt" SW5kZXg6IHNoYXJlL21rL2JzZC5jcHUubWsKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2 cy9zcmMvc2hhcmUvbWsvYnNkLmNwdS5tayx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS42MgpkaWZm IC11IC1yMS42MiBic2QuY3B1Lm1rCi0tLSBzaGFyZS9tay9ic2QuY3B1Lm1rCTIxIE1heSAyMDA3 IDA4OjM5OjQ0IC0wMDAwCTEuNjIKKysrIHNoYXJlL21rL2JzZC5jcHUubWsJMjggQXVnIDIwMDcg MDU6NTA6MDkgLTAwMDAKQEAgLTE4LDYgKzE4LDE0IEBACiAuIGVuZGlmCiAuZWxzZQogCisjIEhh bmRsZSAnbmF0aXZlJyBieSBjb252ZXJ0aW5nIGl0IHRvIHRoZSBhcHByb3ByaWF0ZSBDUFVUWVBF CisKKy5pZiAke01BQ0hJTkVfQVJDSH0gPT0gImkzODYiIHx8ICR7TUFDSElORV9BUkNIfSA9PSAi YW1kNjQiCisuIGlmICR7Q1BVVFlQRX0gPT0gIm5hdGl2ZSIKK0NQVVRZUEUgIT0gZ2NjIC12IC14 IGMgLUUgLW10dW5lPW5hdGl2ZSAvZGV2L251bGwgLW8gL2Rldi9udWxsIDI+JjEgfCBncmVwIG10 dW5lIHwgc2VkIC1lICdzLy4qbXR1bmU9Ly8nCisuIGVuZGlmCisuZW5kaWYKKwogIyBIYW5kbGUg YWxpYXNlcyAobm90IGRvY3VtZW50ZWQgaW4gbWFrZS5jb25mIHRvIGF2b2lkIHVzZXIgY29uZnVz aW9uCiAjIGJldHdlZW4gZS5nLiBpNTg2IGFuZCBwZW50aXVtKQogCg== ------=_Part_6201_15382802.1188284098363-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 07:12:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDCBE16A473 for ; Tue, 28 Aug 2007 07:12:09 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 6019C13C461 for ; Tue, 28 Aug 2007 07:12:09 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.13.8/8.13.8) with ESMTP id l7S7C5vJ017090; Tue, 28 Aug 2007 09:12:07 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 1AE24852; Tue, 28 Aug 2007 09:12:05 +0200 (CEST) Date: Tue, 28 Aug 2007 09:12:05 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Nathan Butcher Message-Id: <20070828091205.9bd9bf79.gerrit@pmp.uni-hannover.de> In-Reply-To: <46D3842E.5040002@fusiongol.com> References: <46D3842E.5040002@fusiongol.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.3 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146 Cc: freebsd-current@freebsd.org Subject: Re: Encrypted 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: Tue, 28 Aug 2007 07:12:09 -0000 On Tue, 28 Aug 2007 11:10:54 +0900 Nathan Butcher wrote about Re: Encrypted zfs?: NB> It's less than an ideal way of having encryption on ZFS (you get some NB> of the benefits of ZFS, but the filesystem on top of GELI is still NB> UFS), but it works anyway. I'm doing it the other way: Create geli devices and run zpool on them. This way you can still use zfs as filesystem. cu Gerrit From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 07:26:12 2007 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 BAE8516A417; Tue, 28 Aug 2007 07:26:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 9277A13C46E; Tue, 28 Aug 2007 07:26:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 2013026FAF; Tue, 28 Aug 2007 03:08:37 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 28 Aug 2007 03:08:37 -0400 X-Sasl-enc: xYtP/J06CBDUDJzZiCMQb6s4bCUipJFwunujlvTRN+hi 1188284916 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 8A6721314; Tue, 28 Aug 2007 03:08:36 -0400 (EDT) Message-ID: <46D3C9F3.2010802@FreeBSD.org> Date: Tue, 28 Aug 2007 08:08:35 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Andrew Thompson References: <20070828040026.GB42201@heff.fud.org.nz> In-Reply-To: <20070828040026.GB42201@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: multicast packets from bpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 07:26:12 -0000 Seems reasonable, both patches are syntactically sane. There are arguments in favour of both changes. I favour the first approach, however, it may make more sense to put the logic into bpf_movein() as it already builds a sockaddr based on the header data provided to bpf during a write. For the first patch: I previously fixed tapwrite() to check injected frames in the same way, as this was causing a problem with my own use of if_bridge. There is no way that I see for bpf to be able to tell if a frame is link-layer multicast or not, and checking at that layer does introduce a little pollution. Ethernet is the most common case so it could be argued that's OK, as we have ethernet-specific fields in struct mbuf now. Your change is the parallel change in the bpfwrite path to what I have in the tapwrite path. The second patch: Conceptually similar to the loopback check in ip_output() for multicast. we wind up doing this check elsewhere, in particular netgraph. It is a relatively cheap check although it does involve changing the flags on a potentially read-only mbuf chain, which is bending the rules a bit (the stack often needs to change stuff in m_pkthdr even if the clusters are read-only). BTW this patch looks like it touches the paths which would need to be changed if IGMP snooping were to be implemented for if_bridge. regards, BMS From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 09:19:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C60A216A418 for ; Tue, 28 Aug 2007 09:19:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4CE13C459 for ; Tue, 28 Aug 2007 09:19:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1IPxEc-0001jJ-4f; Tue, 28 Aug 2007 12:19:42 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Rong-en Fan" In-reply-to: Your message of Tue, 28 Aug 2007 12:36:16 +0800 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Aug 2007 12:19:42 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org, LI Xin Subject: Re: -current cross compile for -stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 09:19:43 -0000 > On 8/28/07, LI Xin wrote: > > Danny Braniss wrote: > > > till now I used a stable box to cross compile for other arch/stable|current. > > > today i decided to try out -current as a base to cross compile. does it > > > work? since i get: > > > > > > export MAKEOBJDIRPREFIX=/r+d/obj/cs4 > > > cd /r+d/6.2/src; make TARGET_ARCH=amd64 buildworld > > > ... > > > /r+d/6.2/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc > > > -i386.h:451: error: array type has incomplete element type > > > *** Error code 1 > > > > > > Stop in /r+d/6.2/src/gnu/usr.bin/binutils/as. > > > > This won't work. In order to build -STABLE you have to install a > > chrooted RELENG_6 environment and chroot into it to make it work. > > I think there is a hack for ports' tinderbox, patch is at > > http://www.marcuscom.com/downloads/binutils.diff > > Not sure it appears in ports@ mailing or tinderbox's. > > Regards, > Rong-En Fan well, I can confirm that it works. 1)I'm now testing the result by using the result to make buildworld - goto 1 :-). so, if it works for tinderbox, and for me, can it be 'installed'? thanks, danny From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 09:35:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517E616A419 for ; Tue, 28 Aug 2007 09:35:30 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.freebsd.org (Postfix) with ESMTP id 108DC13C48E for ; Tue, 28 Aug 2007 09:35:29 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.104) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 46D3317A0001CC8A; Tue, 28 Aug 2007 10:25:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Aug 2007 10:21:17 +0200 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A17F7@royal64.emp.zapto.org> Content-class: urn:content-classes:message In-Reply-To: <0987CEB4-4AD4-4B25-9CE4-68292A3253FC@online.no> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 X-MS-TNEF-Correlator: Thread-Topic: anyone have experience with HighPoint RocketRaid 2340 + zfs? Thread-Index: Acfo7AAIsHFiWCbdR6a3QAS3aAxTQwAT/+Yw References: <0987CEB4-4AD4-4B25-9CE4-68292A3253FC@online.no> From: "Daniel Eriksson" To: Cc: Sverre Svenningsen Subject: RE: anyone have experience with HighPoint RocketRaid 2340 + 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: Tue, 28 Aug 2007 09:35:30 -0000 Sverre Svenningsen wrote: > All the trouble i've had with the promise Sata300 tx4 cards and zfs =20 > on -current is making me think of buying an upgrade, and this pci-e =20 > x8 sata raid card looks like it makes sense.. it has official driver =20 > support for freebsd 6.2, but it seems to only come as a precompiled =20 > kernel module.. will that work on a -current kernel? >=20 > I'd love to hear from anyone using one of these cards - it's=20 > not that =20 > expensive especially for 16 ports, but i don't want to buy another =20 > dud card :) I have both a 2320 and a 2340, and they seem to work as expected under 6-STABLE (i386) with the driver provided by HighPoint. I've only had one major problem so far, and I think the end result (lost data) was due to a combination of stupidity on my part (replacing the wrong drive) and a firmware bug relating to sector repair in RAID-5 that has now been fixed. Scott Long has said that he is working with HighPoint to get the 2340 driver into the tree (and the updated 2320 driver). /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 10:31:12 2007 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 ED1C716A419 for ; Tue, 28 Aug 2007 10:31:12 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 83FFB13C49D for ; Tue, 28 Aug 2007 10:31:12 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 997E81CC58; Tue, 28 Aug 2007 22:31:10 +1200 (NZST) Date: Tue, 28 Aug 2007 22:31:10 +1200 From: Andrew Thompson To: "Bruce M. Simpson" Message-ID: <20070828103110.GA43049@heff.fud.org.nz> References: <20070828040026.GB42201@heff.fud.org.nz> <46D3C9F3.2010802@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D3C9F3.2010802@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Current Subject: Re: multicast packets from bpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 10:31:13 -0000 On Tue, Aug 28, 2007 at 08:08:35AM +0100, Bruce M. Simpson wrote: > Seems reasonable, both patches are syntactically sane. There are > arguments in favour of both changes. > > I favour the first approach, however, it may make more sense to put the > logic into bpf_movein() as it already builds a sockaddr based on the > header data provided to bpf during a write. I had originally started to put it there but realised that I need a pointer to the ifnet to read if_broadcastaddr, I didnt think it was worth changing the function parameters when the check can also just go in bpfwrite. I dont mind moving it if its the more correct place to put it. > For the first patch: I previously fixed tapwrite() to check injected > frames in the same way, as this was causing a problem with my own use of > if_bridge. There is no way that I see for bpf to be able to tell if a > frame is link-layer multicast or not, and checking at that layer does > introduce a little pollution. Ethernet is the most common case so it > could be argued that's OK, as we have ethernet-specific fields in struct > mbuf now. Your change is the parallel change in the bpfwrite path to > what I have in the tapwrite path. Is the tapwrite patch still needed? The mbuf is passed to ether_input which should do the right thing. > The second patch: Conceptually similar to the loopback check in > ip_output() for multicast. we wind up doing this check elsewhere, in > particular netgraph. It is a relatively cheap check although it does > involve changing the flags on a potentially read-only mbuf chain, which > is bending the rules a bit (the stack often needs to change stuff in > m_pkthdr even if the clusters are read-only). I could go with this but it seems wrong to be passed a mbuf which has incorrect flags, there may be other places in the stack that look for M_*CAST that also have quirks. Andrew From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 10:47:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F287516A420 for ; Tue, 28 Aug 2007 10:47:37 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 5C18F13C46B for ; Tue, 28 Aug 2007 10:47:37 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0F80D456AB; Tue, 28 Aug 2007 12:47:35 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D3ADF45684; Tue, 28 Aug 2007 12:47:29 +0200 (CEST) Date: Tue, 28 Aug 2007 12:46:25 +0200 From: Pawel Jakub Dawidek To: Christian Walther Message-ID: <20070828104625.GB36596@garage.freebsd.pl> References: <46D2C812.8090106@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline In-Reply-To: <46D2C812.8090106@gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: Encrypted 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: Tue, 28 Aug 2007 10:47:38 -0000 --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2007 at 12:48:18PM +0000, Christian Walther wrote: > Hello list, >=20 > I'm currently using a zraid consisting of three drives. Lately I wonder= =20 > what the best way would be to encrypt it. > I read the chapter dealing with disk encryption in the handbook, and=20 > decided to use GELI. Is there anyone here on the list who has some=20 > experiences with ZFS on encrypted GELI devices? Are there some=20 > performance specs around? >=20 > And what is even more important: What is the best of moving the zraid to= =20 > encrypted devices? > I can't remove one of the disks because they are in use. So I figure one= =20 > way would be to buy another disk, set up encryption and add it to the=20 > pool. I could then remove one disk after the other, encrypt it, remove=20 > the (now broken one) from the zpool, and add the newly encrypted device. > Since buying disks costs money I wonder how save it would be to follow=20 > this procedure without adding a new disk. From my point of view I'll=20 > loose redundancy as soon as I remove one of the three disks. But is=20 > there another problem or something dangerous I don't see her? slayer:root:~# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT private 334G 64,6G 269G 19% ONLINE - tank 1,45T 607G 881G 40% ONLINE - slayer:root:~# zpool status pool: private state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM private ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad1s2.eli ONLINE 0 0 0 ad6.eli ONLINE 0 0 0 ad7s2.eli ONLINE 0 0 0 errors: No known data errors pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad3.eli ONLINE 0 0 0 ad4.eli ONLINE 0 0 0 ad5.eli ONLINE 0 0 0 ad8.eli ONLINE 0 0 0 ad9.eli ONLINE 0 0 0 errors: No known data errors --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG0/0BForvXbEpPzQRAlQHAJ4jOerKHHhDLOAXuTeA8r9EiSvzRQCeOrGe yTo+CK8aKlHZpe6Sg+FyoXw= =jnb+ -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 10:49:34 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1F2816A468; Tue, 28 Aug 2007 10:49:33 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (crsd-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2d5::2]) by mx1.freebsd.org (Postfix) with ESMTP id 96A2513C45B; Tue, 28 Aug 2007 10:49:32 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.1/8.14.1) with ESMTP id l7SAnFLZ001389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2007 14:49:15 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Received: (from yuri@localhost) by darklight.org.ru (8.14.1/8.14.1/Submit) id l7SAnFv4001388; Tue, 28 Aug 2007 14:49:15 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Date: Tue, 28 Aug 2007 14:49:15 +0400 From: Yuri Pankov To: "Christian S.J. Peron" Message-ID: <20070828104915.GA1338@darklight.org.ru> References: <20070824081726.GC6571@darklight.org.ru> <20070827235903.GA1183@sub.vaned.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070827235903.GA1183@sub.vaned.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@FreeBSD.org Subject: Re: rtfree: 0xffffff00036fb1e0 has 1 refs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 10:49:34 -0000 On Mon, Aug 27, 2007 at 06:59:03PM -0500, Christian S.J. Peron wrote: > Based on some comments in rtfree, we should only be calling rtfree if we > are sure we own the last reference to the route. I am not sure this is the > case in the stf/gif cases... Please try the attached patch and let me know > if there are any ill effects. > > On Fri, Aug 24, 2007 at 12:17:26PM +0400, Yuri Pankov wrote: > > Hi, > > > > I've recently started using he.net's ipv6 tunnel and getting this message: > > rtfree: 0xffffff00036fb1e0 has 1 refs > > > > I've added kdb_backtrace() in route.c as Gleb Smirnoff suggested before. Here's > > backtrace: > > rtfree: 0xffffff00036fb1e0 has 1 refs > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > rtfree() at rtfree+0xba > > gif_encapcheck4() at gif_encapcheck4+0x118 > > gif_encapcheck() at gif_encapcheck+0xfd > > encap4_input() at encap4_input+0xcc > > ip_input() at ip_input+0xc0 > > tunwrite() at tunwrite+0x1d5 > > giant_write() at giant_write+0x51 > > devfs_write_f() at devfs_write_f+0x9c > > dofilewrite() at dofilewrite+0x85 > > kern_writev() at kern_writev+0x4c > > write() at write+0x54 > > syscall() at syscall+0x1ce > > Xfast_syscall() at Xfast_syscall+0xab > > --- syscall (4, FreeBSD ELF64, write), rip = 0x80125c35c, rsp = 0x7fffffffda18, > > rbp = 0x60 --- > > > > > > ifconfig: > > gif0: flags=8051 metric 0 mtu 1280 > > tunnel inet 194.186.18.14 --> 64.71.128.83 > > inet6 fe80::20f:eaff:fe7d:f320%gif0 prefixlen 64 scopeid 0x5 > > inet6 2001:470:1f03:2d5::2 --> 2001:470:1f03:2d5::1 prefixlen 128 > > inet6 2001:470:1f01:725::1 prefixlen 64 > > tun0: flags=8051 metric 0 mtu 1500 > > inet6 fe80::20f:eaff:fe7d:f320%tun0 prefixlen 64 scopeid 0x6 > > inet 194.186.18.14 --> 194.186.18.2 netmask 0xffffff00 > > Opened by PID 458 > > > > > > Yuri > > _______________________________________________ > > 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" > > -- > Christian S.J. Peron > csjp@FreeBSD.ORG > FreeBSD Committer Thanks for reply. I've used your patch and reinstalled kernel. But I haven't found reliable way to reproduce this problem (sometimes it manifests right after establishing connection, sometimes after several ppp restarts, etc.). Anyway, I'll report back if I'll see it again. Thanks, Yuri From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 11:34:48 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E294816A419 for ; Tue, 28 Aug 2007 11:34:48 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.19.101.164]) by mx1.freebsd.org (Postfix) with ESMTP id BF9E213C459 for ; Tue, 28 Aug 2007 11:34:48 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from localhost (localhost [127.0.0.1]) by mail.barafranca.com (Postfix) with ESMTP id 41D2EC384C; Tue, 28 Aug 2007 12:17:31 +0000 (UTC) Received: from mail.barafranca.com ([67.19.101.164]) by localhost (mail.barafranca.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78368-05; Tue, 28 Aug 2007 12:16:52 +0000 (UTC) Received: from nexus.bsdlan.org (a213-22-26-22.cpe.netcabo.pt [213.22.26.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id 10ED5C3866; Tue, 28 Aug 2007 12:16:51 +0000 (UTC) Message-ID: <46D40833.2030007@barafranca.com> Date: Tue, 28 Aug 2007 12:34:11 +0100 From: Hugo Silva User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <46D2C812.8090106@gmail.com> <20070828104625.GB36596@garage.freebsd.pl> In-Reply-To: <20070828104625.GB36596@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at barafranca.com X-Spam-Status: No, score=0 tagged_above=-1 required=4 tests=[none] X-Spam-Score: 0 X-Spam-Level: Cc: freebsd-current@FreeBSD.ORG Subject: Re: Encrypted 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: Tue, 28 Aug 2007 11:34:49 -0000 Pawel Jakub Dawidek wrote: > On Mon, Aug 27, 2007 at 12:48:18PM +0000, Christian Walther wrote: > >> Hello list, >> >> I'm currently using a zraid consisting of three drives. Lately I wonder >> what the best way would be to encrypt it. >> I read the chapter dealing with disk encryption in the handbook, and >> decided to use GELI. Is there anyone here on the list who has some >> experiences with ZFS on encrypted GELI devices? Are there some >> performance specs around? >> >> And what is even more important: What is the best of moving the zraid to >> encrypted devices? >> I can't remove one of the disks because they are in use. So I figure one >> way would be to buy another disk, set up encryption and add it to the >> pool. I could then remove one disk after the other, encrypt it, remove >> the (now broken one) from the zpool, and add the newly encrypted device. >> Since buying disks costs money I wonder how save it would be to follow >> this procedure without adding a new disk. From my point of view I'll >> loose redundancy as soon as I remove one of the three disks. But is >> there another problem or something dangerous I don't see her? >> > > slayer:root:~# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > private 334G 64,6G 269G 19% ONLINE - > tank 1,45T 607G 881G 40% ONLINE - > > slayer:root:~# zpool status > pool: private > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > private ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad1s2.eli ONLINE 0 0 0 > ad6.eli ONLINE 0 0 0 > ad7s2.eli ONLINE 0 0 0 > > errors: No known data errors > > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad3.eli ONLINE 0 0 0 > ad4.eli ONLINE 0 0 0 > ad5.eli ONLINE 0 0 0 > ad8.eli ONLINE 0 0 0 > ad9.eli ONLINE 0 0 0 > > errors: No known data errors > > How's the performance on the geli-backed pool ? I've done this experiment myself, but with ggate and over the world, so couldn't measure any kind of useful data (when it comes to performance). Best regards, Hugo From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 12:51:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF0016A41A for ; Tue, 28 Aug 2007 12:51:54 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id F295013C46E for ; Tue, 28 Aug 2007 12:51:53 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7c98.q.ppp-pool.de [89.53.124.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 685D412883F for ; Tue, 28 Aug 2007 14:26:22 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 4E8603F43E; Tue, 28 Aug 2007 14:26:04 +0200 (CEST) Message-ID: <46D41466.5070705@vwsoft.com> Date: Tue, 28 Aug 2007 14:26:14 +0200 From: Volker User-Agent: Thunderbird 2.0.0.6 (X11/20070807) MIME-Version: 1.0 To: John Bergman References: <46D3936B.5000401@guildsoftware.com> In-Reply-To: <46D3936B.5000401@guildsoftware.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: freebsd-current@freebsd.org Subject: Re: lock order reversal with pf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 12:51:54 -0000 On 12/23/-58 20:59, John Bergman wrote: > Sorry if this has been previously reported, > didn't see it in a quick search. How about: http://www.freebsd.org/cgi/query-pr.cgi?pr=114567 Volker From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 12:53:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E00116A41A for ; Tue, 28 Aug 2007 12:53:34 +0000 (UTC) (envelope-from kockac@zuikaku.org) Received: from saratoga.zuikaku.org (unknown [IPv6:2001:1ba0::20a:e4ff:fe5a:25bb]) by mx1.freebsd.org (Postfix) with ESMTP id C114B13C465 for ; Tue, 28 Aug 2007 12:53:32 +0000 (UTC) (envelope-from kockac@zuikaku.org) Received: from saratoga.zuikaku.org (localhost [127.0.0.1]) by saratoga.zuikaku.org (8.13.8/8.13.8) with ESMTP id l7SCrXxW002284 for ; Tue, 28 Aug 2007 14:53:33 +0200 (CEST) (envelope-from kockac@zuikaku.org) Received: (from kockac@localhost) by saratoga.zuikaku.org (8.13.8/8.13.8/Submit) id l7SCrWig002283 for freebsd-current@freebsd.org; Tue, 28 Aug 2007 14:53:32 +0200 (CEST) (envelope-from kockac@zuikaku.org) X-Authentication-Warning: saratoga.zuikaku.org: kockac set sender to kockac@zuikaku.org using -f Date: Tue, 28 Aug 2007 14:53:31 +0200 From: "'Kockac' Matej Kubik" To: freebsd-current@freebsd.org Message-ID: <20070828125331.GA2132@saratoga.zuikaku.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: weird ufs corruption on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 12:53:34 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, recently I decided to install -current on one of my computers but I ran into a problem with reading files from UFS: - some of the files have a part of them replaced - when I try to read them in 6-stable, they are fine; /boot/loader is always able to load kernel too - only files greater than 64KB are affected - the part that is replaced seems to be always 64KB big but doesn't begin on 64KB boundary - the data is usually replaced by \000s but sometimes it seems like a part of another file - the corrupted file(s) do not change unless I reboot/remount the fs - I have tried writing but didn't test it thoroughly; it seems to work without any problems (the files are readable from -stable just fine) The system is an uniprocessor Tyan S3970 (Broadcomm chipset) with Opteron 2210, 2GB RAM and 3 250GB disks. It works under -stable from last week just fine (dmesg is attached as 6_2.boot). I tried installing -current according to instructions in src/UPDATING (onto a separate partition): env -i make buildworld buildkernel # KERNCONF=GENERIC env -i make installworld distribution installkernel DESTDIR=... # edit ${DESTDIR}/etc/fstab etc. and it worked but kldxref complained about unknown metdata record (see attached file installkernel.err) - I'm not using any modules though. I'm attaching the dmesg from -current too (curr_a.boot). I tried waiting a couple of days, cvsupping new -current and trying it out but it behaved the same. Any help would be greatly appreciated, if you need some information I did not provide, let me know how to get it please and I shall post it to the list. Matej Kubik PS: Sorry for my bad English, I'm not used to speaking it. ;-) Hope you can understand. --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="curr_a.boot" OK unload OK set currdev=disk1s1a: OK set vfs.root.mountfrom="ufs:/dev/ad6s1a" OK load /boot/kernel/kernel /boot/kernel/kernel text=0x7045e8 data=0xe68d0+0xf1430 syms=[0x8+0xae078+0x8+0x93b4b] OK boot -sv GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009d800 SMAP type=02 base=000000000009d800 len=0000000000002800 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000007fef0000 SMAP type=03 base=000000007fff0000 len=000000000000e000 SMAP type=04 base=000000007fffe000 len=0000000000002000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fec01000 len=0000000000001000 SMAP type=02 base=00000000fec02000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 Copyright (c) 1992-2007 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 7.0-CURRENT #0: Tue Aug 28 12:36:19 CEST 2007 root@akagi.dial.sk:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80c20000. ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193200 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1795509466 Hz CPU: Dual-Core AMD Opteron(tm) Processor 2210 (1795.51-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f12 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 2134294528 (2035 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000099fff, 626688 bytes (153 pages) 0x0000000000d1d000 - 0x000000007c39ffff, 2070425600 bytes (505475 pages) avail memory = 2059702272 (1964 MB) 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 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ACPI: RSDP @ 0x0xf7710/0x0024 (v 2 ACPIAM) ACPI: XSDT @ 0x0x7fff0100/0x0044 (v 1 A M I OEMXSDT 0x10000618 MSFT 0x00000097) ACPI: FACP @ 0x0x7fff0290/0x00F4 (v 3 A M I OEMFACP 0x10000618 MSFT 0x00000097) ACPI: DSDT @ 0x0x7fff0410/0x3005 (v 1 0AAAA 0AAAA000 0x00000000 INTL 0x02002026) ACPI: FACS @ 0x0x7fffe000/0x0040 ACPI: APIC @ 0x0x7fff0390/0x0080 (v 1 A M I OEMAPIC 0x10000618 MSFT 0x00000097) ACPI: OEMB @ 0x0x7fffe040/0x0056 (v 1 A M I AMI_OEM 0x10000618 MSFT 0x00000097) ACPI: SRAT @ 0x0x7fff3420/0x00A0 (v 1 AMD HAMMER 0x00000001 AMD 0x00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 3, Interrupt 16 at 0xfec01000 MADT: Found IO APIC ID 4, Interrupt 32 at 0xfec02000 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high MADT: Forcing active-low polarity and level trigger for SCI ioapic0: intpin 9 polarity: low ioapic0: intpin 9 trigger: level ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 wlan_amrr: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: null: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Aug 28 2007 12:36:10) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/4 0/3 0/4 1/2 -> 1 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 9 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 5 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link27: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link28: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link29: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link30: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link31: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 Validation 0 10 N 0 10 After Disable 0 255 N 0 10 pci_link32: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 11 Validation 0 11 N 0 11 After Disable 0 255 N 0 11 cpu0: on acpi0 cpu0: switching to generic Cx mode powernow0: on cpu0 powernow0: STATUS: 0x3108120a080a020a powernow0: STATUS: maxfid: 0x0a powernow0: STATUS: maxvid: 0x08 device_attach: powernow0 attach returned 6 cpu1: on acpi0 powernow1: on cpu1 powernow1: STATUS: 0x3108120a080a020a powernow1: STATUS: maxfid: 0x0a powernow1: STATUS: maxvid: 0x08 device_attach: powernow1 attach returned 6 pci_open(1): mode 1 addr port (0x0cf8) is 0x80017078 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 1 [class=060400] [hdr=01] is there (id=00361166) pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1166, dev=0x0036, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0205, revid=0x00 bus=0, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0214, revid=0x00 bus=0, slot=2, func=1 class=01-01-8a, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled found-> vendor=0x1166, dev=0x0234, revid=0x00 bus=0, slot=2, func=2 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0223, revid=0x01 bus=0, slot=3, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xff6b4000, size 12, enabled map[14]: type I/O Port, range 32, base 0xe000, size 8, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 10 ioapic0: Changing trigger for pin 10 to level ioapic0: Changing polarity for pin 10 to low found-> vendor=0x1166, dev=0x0223, revid=0x01 bus=0, slot=3, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xff6b5000, size 12, enabled map[14]: type I/O Port, range 32, base 0xe400, size 8, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 10 found-> vendor=0x1166, dev=0x0223, revid=0x01 bus=0, slot=3, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xff6b6000, size 12, enabled map[14]: type I/O Port, range 32, base 0xe800, size 8, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 10 found-> vendor=0x8086, dev=0x1076, revid=0x05 bus=0, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xff680000, size 17, enabled map[14]: type Memory, range 32, base 0xff660000, size 17, enabled map[18]: type I/O Port, range 32, base 0xdc00, size 6, enabled pcib0: matched entry for 0.4.INTA pcib0: slot 4 INTA hardwired to IRQ 24 found-> vendor=0x8086, dev=0x1076, revid=0x05 bus=0, slot=5, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xff620000, size 17, enabled map[14]: type Memory, range 32, base 0xff600000, size 17, enabled map[18]: type I/O Port, range 32, base 0xd880, size 6, enabled pcib0: matched entry for 0.5.INTA pcib0: slot 5 INTA hardwired to IRQ 25 found-> vendor=0x18ca, dev=0x0020, revid=0x00 bus=0, slot=6, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xf8000000, size 26, enabled map[14]: type Memory, range 32, base 0xff6c0000, size 18, enabled map[18]: type I/O Port, range 32, base 0xec00, size 7, enabled found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 2 pcib1: I/O decode 0xb000-0xcfff pcib1: memory decode 0xff300000-0xff3fffff pcib1: no prefetched decode pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1166, dev=0x0104, revid=0xc0 bus=1, slot=13, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0016, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x02 (500 ns) found-> vendor=0x1166, dev=0x024a, revid=0x00 bus=1, slot=14, func=0 class=01-04-05, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 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 I/O Port, range 32, base 0xc080, size 3, enabled pcib1: requested I/O range 0xc080-0xc087: in range map[14]: type I/O Port, range 32, base 0xc000, size 2, enabled pcib1: requested I/O range 0xc000-0xc003: in range map[18]: type I/O Port, range 32, base 0xbc00, size 3, enabled pcib1: requested I/O range 0xbc00-0xbc07: in range map[1c]: type I/O Port, range 32, base 0xb880, size 2, enabled pcib1: requested I/O range 0xb880-0xb883: in range map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib1: requested I/O range 0xb800-0xb81f: in range map[24]: type Memory, range 32, base 0xff3fe000, size 13, enabled pcib1: requested memory range 0xff3fe000-0xff3fffff: good pcib1: matched entry for 1.14.INTA pcib1: slot 14 INTA hardwired to IRQ 11 ioapic0: Changing trigger for pin 11 to level ioapic0: Changing polarity for pin 11 to low pcib2: at device 13.0 on pci1 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: physical bus=2 atapci0: port 0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb81f mem 0xff3fe000-0xff3fffff irq 11 at device 14.0 on pci1 atapci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 ioapic0: routing intpin 11 (ISA IRQ 11) to vector 49 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xff3fe000 ata2: on atapci0 ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: reset tp1 mask=01 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: reset tp1 mask=01 ostat0=50 ostat1=00 ata4: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: reset tp1 mask=01 ostat0=7f ostat1=00 ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: reset tp2 stat0=ff stat1=00 devices=0x0 ata5: [MPSAFE] ata5: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 2.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=02 ostat0=ff ostat1=50 ata0: stat1=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0x8 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 50 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: 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 51 ata1: [MPSAFE] ata1: [ITHREAD] isab0: at device 2.2 on pci0 isa0: on isab0 ohci0: port 0xe000-0xe0ff mem 0xff6b4000-0xff6b4fff irq 10 at device 3.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6b4000 ohci0: (New OHCI DeviceId=0x02231166) ioapic0: routing intpin 10 (ISA IRQ 10) to vector 52 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: port 0xe400-0xe4ff mem 0xff6b5000-0xff6b5fff irq 10 at device 3.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6b5000 ohci1: (New OHCI DeviceId=0x02231166) ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: port 0xe800-0xe8ff mem 0xff6b6000-0xff6b6fff irq 10 at device 3.2 on pci0 ehci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6b6000 ehci0: (New EHCI DeviceId=0x02231166) ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: <(0x1166) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2 uhub2: 4 ports with 4 removable, self powered em0: port 0xdc00-0xdc3f mem 0xff680000-0xff69ffff,0xff660000-0xff67ffff irq 24 at device 4.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xff680000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdc00 em0: bpf attached em0: Ethernet address: 00:e0:81:47:1d:5e ioapic1: routing intpin 8 (PCI IRQ 24) to vector 53 em0: [FILTER] em1: port 0xd880-0xd8bf mem 0xff620000-0xff63ffff,0xff600000-0xff61ffff irq 25 at device 5.0 on pci0 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xff620000 em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0xd880 em1: bpf attached em1: Ethernet address: 00:e0:81:47:1d:5f ioapic1: routing intpin 9 (PCI IRQ 25) to vector 54 em1: [FILTER] vgapci0: port 0xec00-0xec7f mem 0xf8000000-0xfbffffff,0xff6c0000-0xff6fffff at device 6.0 on pci0 acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: routing intpin 4 (ISA IRQ 4) to vector 55 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 56 sio1: [FILTER] ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed ex_isa_identify() sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it 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 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc9fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x1f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: 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 132571 -> 100000 procfs registered lapic: Divisor 2, Frequency 99750538 hz Timecounter "TSC" frequency 1795509466 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on HT1000 chip acd0: setting UDMA33 on HT1000 chip acd0: CDROM drive at ata0 as slave acd0: read 4134KB/s (4134KB/s), 256KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 238475MB at ata2-master SATA150 ad4: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 238475MB at ata3-master SATA150 ad6: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed GEOM: new disk ad6 ad6: FreeBSD check1 failed ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 238475MB at ata4-master SATA150 ad8: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LGEOMSI (v2) check1 failed : new disk ad8 ad8: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 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 3 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 10 to local APIC 0 ioapic0: Assigning ISA IRQ 11 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 1 ioapic1: Assigning PCI IRQ 24 to local APIC 0 ioapic1: Assigning PCI IRQ 25 to local APIC 1 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad6s1a start_init: trying /sbin/init Enter full pathname of shell or RETURN for /bin/sh: pid 45 (sh), uid 0: exited on signal 11 AEnter full pathname of shell or RETURN for /bin/sh: /bin/csh pid 46 (csh), uid 0: exited on signal 11 AEnter full pathname of shell or RETURN for /bin/sh: /rescue/sh # file /bin/sh /bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped # /bin/sh pid 49 (sh), uid 0: exited on signal 11 Segmentation fault # mount -r /dev/ad8s1a /mnt # diff -ru /mnt/usr/src /usr/src diff -ru /mnt/usr/src/contrib/bind9/doc/arm/Bv9ARM.pdf /usr/src/contrib/bind9/doc/arm/Bv9ARM.pdf --- /mnt/usr/src/contrib/bind9/doc/arm/Bv9ARM.pdf 2007-08-23 15:42:12.000000000 +0000 +++ /usr/src/contrib/bind9/doc/arm/Bv9ARM.pdf 2007-08-28 10:57:55.000000000 +0000 @@ -4421,5946 +4421,7 @@ --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="installkernel.err" kldxref /mnt/boot/kernel kldxref: file isn't dynamically-linked kldxref: unknown metdata record 0 in file aac.ko.symbols kldxref: unknown metdata record 0 in file aac.ko.symbols kldxref: unknown metdata record 0 in file aac.ko.symbols kldxref: unknown metdata record 0 in file aac.ko.symbols kldxref: unknown metdata record 0 in file aac.ko.symbols kldxref: unknown metdata record 0 in file aac.ko.symbols kldxref: unknown metdata record 0 in file accf_data.ko.symbols kldxref: unknown metdata record 0 in file accf_http.ko.symbols kldxref: unknown metdata record 0 in file acpi_aiboost.ko.symbols kldxref: unknown metdata record 0 in file acpi_aiboost.ko.symbols kldxref: unknown metdata record 0 in file acpi_asus.ko.symbols kldxref: unknown metdata record 0 in file acpi_asus.ko.symbols kldxref: unknown metdata record 0 in file acpi_fujitsu.ko.symbols kldxref: unknown metdata record 0 in file acpi_fujitsu.ko.symbols kldxref: unknown metdata record 0 in file acpi_fujitsu.ko.symbols kldxref: unknown metdata record 0 in file acpi_ibm.ko.symbols kldxref: unknown metdata record 0 in file acpi_ibm.ko.symbols kldxref: unknown metdata record 0 in file acpi_panasonic.ko.symbols kldxref: unknown metdata record 0 in file acpi_panasonic.ko.symbols kldxref: unknown metdata record 0 in file acpi_sony.ko.symbols kldxref: unknown metdata record 0 in file acpi_sony.ko.symbols kldxref: unknown metdata record 0 in file acpi_toshiba.ko.symbols kldxref: unknown metdata record 0 in file acpi_toshiba.ko.symbols kldxref: unknown metdata record 0 in file acpi_toshiba.ko.symbols kldxref: unknown metdata record 0 in file acpi_toshiba.ko.symbols kldxref: unknown metdata record 0 in file acpi_video.ko.symbols kldxref: unknown metdata record 0 in file acpi_video.ko.symbols kldxref: unknown metdata record 0 in file acpi_dock.ko.symbols kldxref: unknown metdata record 0 in file acpi_dock.ko.symbols kldxref: unknown metdata record 0 in file agp.ko.symbols kldxref: unknown metdata record 0 in file agp.ko.symbols kldxref: unknown metdata record 0 in file agp.ko.symbols kldxref: unknown metdata record 0 in file agp.ko.symbols kldxref: unknown metdata record 0 in file agp.ko.symbols kldxref: unknown metdata record 0 in file agp.ko.symbols kldxref: unknown metdata record 0 in file agp.ko.symbols kldxref: unknown metdata record 0 in file aha.ko.symbols kldxref: unknown metdata record 0 in file aha.ko.symbols kldxref: unknown metdata record 0 in file aha.ko.symbols kldxref: unknown metdata record 0 in file ahc.ko.symbols kldxref: unknown metdata record 0 in file ahc.ko.symbols kldxref: unknown metdata record 0 in file ahc.ko.symbols kldxref: unknown metdata record 0 in file ahc_eisa.ko.symbols kldxref: unknown metdata record 0 in file ahc_eisa.ko.symbols kldxref: unknown metdata record 0 in file ahc_eisa.ko.symbols kldxref: unknown metdata record 0 in file ahc_isa.ko.symbols kldxref: unknown metdata record 0 in file ahc_isa.ko.symbols kldxref: unknown metdata record 0 in file ahc_isa.ko.symbols kldxref: unknown metdata record 0 in file ahc_pci.ko.symbols kldxref: unknown metdata record 0 in file ahc_pci.ko.symbols kldxref: unknown metdata record 0 in file ahc_pci.ko.symbols kldxref: unknown metdata record 0 in file ahc_pci.ko.symbols kldxref: unknown metdata record 0 in file ahd.ko.symbols kldxref: unknown metdata record 0 in file ahd.ko.symbols kldxref: unknown metdata record 0 in file ahd.ko.symbols kldxref: unknown metdata record 0 in file ahd.ko.symbols kldxref: unknown metdata record 0 in file ahd.ko.symbols kldxref: unknown metdata record 0 in file ahd.ko.symbols kldxref: unknown metdata record 0 in file ahd.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file aio.ko.symbols kldxref: unknown metdata record 0 in file amr.ko.symbols kldxref: unknown metdata record 0 in file amr.ko.symbols kldxref: unknown metdata record 0 in file amr.ko.symbols kldxref: unknown metdata record 0 in file amr.ko.symbols kldxref: unknown metdata record 0 in file amr_linux.ko.symbols kldxref: unknown metdata record 0 in file amr_linux.ko.symbols kldxref: unknown metdata record 0 in file if_an.ko.symbols kldxref: unknown metdata record 0 in file if_an.ko.symbols kldxref: unknown metdata record 0 in file if_an.ko.symbols kldxref: unknown metdata record 0 in file if_an.ko.symbols kldxref: unknown metdata record 0 in file if_an.ko.symbols kldxref: unknown metdata record 0 in file if_an.ko.symbols kldxref: unknown metdata record 0 in file if_an.ko.symbols kldxref: unknown metdata record 0 in file if_an.ko.symbols kldxref: unknown metdata record 0 in file arcmsr.ko.symbols kldxref: unknown metdata record 0 in file arcmsr.ko.symbols kldxref: unknown metdata record 0 in file arcmsr.ko.symbols kldxref: unknown metdata record 0 in file ata.ko.symbols kldxref: unknown metdata record 0 in file ata.ko.symbols kldxref: unknown metdata record 0 in file atacard.ko.symbols kldxref: unknown metdata record 0 in file atacard.ko.symbols kldxref: unknown metdata record 0 in file ataisa.ko.symbols kldxref: unknown metdata record 0 in file ataisa.ko.symbols kldxref: unknown metdata record 0 in file atapci.ko.symbols kldxref: unknown metdata record 0 in file atapci.ko.symbols kldxref: unknown metdata record 0 in file atapci.ko.symbols kldxref: unknown metdata record 0 in file atapci.ko.symbols kldxref: unknown metdata record 0 in file atadisk.ko.symbols kldxref: unknown metdata record 0 in file atadisk.ko.symbols kldxref: unknown metdata record 0 in file atadisk.ko.symbols kldxref: unknown metdata record 0 in file atapicd.ko.symbols kldxref: unknown metdata record 0 in file atapicd.ko.symbols kldxref: unknown metdata record 0 in file atapicd.ko.symbols kldxref: unknown metdata record 0 in file atapifd.ko.symbols kldxref: unknown metdata record 0 in file atapifd.ko.symbols kldxref: unknown metdata record 0 in file atapifd.ko.symbols kldxref: unknown metdata record 0 in file atapist.ko.symbols kldxref: unknown metdata record 0 in file atapist.ko.symbols kldxref: unknown metdata record 0 in file atapist.ko.symbols kldxref: unknown metdata record 0 in file ataraid.ko.symbols kldxref: unknown metdata record 0 in file ataraid.ko.symbols kldxref: unknown metdata record 0 in file ataraid.ko.symbols kldxref: unknown metdata record 0 in file ataraid.ko.symbols kldxref: unknown metdata record 0 in file ataraid.ko.symbols kldxref: unknown metdata record 0 in file atapicam.ko.symbols kldxref: unknown metdata record 0 in file atapicam.ko.symbols kldxref: unknown metdata record 0 in file atapicam.ko.symbols kldxref: unknown metdata record 0 in file atapicam.ko.symbols kldxref: unknown metdata record 0 in file if_ath.ko.symbols kldxref: unknown metdata record 0 in file if_ath.ko.symbols kldxref: unknown metdata record 0 in file if_ath.ko.symbols kldxref: unknown metdata record 0 in file if_ath.ko.symbols kldxref: unknown metdata record 0 in file if_ath.ko.symbols kldxref: unknown metdata record 0 in file if_ath.ko.symbols kldxref: unknown metdata record 0 in file ath_hal.ko.symbols kldxref: unknown metdata record 0 in file ath_hal.ko.symbols kldxref: unknown metdata record 0 in file ath_rate.ko.symbols kldxref: unknown metdata record 0 in file ath_rate.ko.symbols kldxref: unknown metdata record 0 in file ath_rate.ko.symbols kldxref: unknown metdata record 0 in file ath_rate.ko.symbols kldxref: unknown metdata record 0 in file if_aue.ko.symbols kldxref: unknown metdata record 0 in file if_aue.ko.symbols kldxref: unknown metdata record 0 in file if_aue.ko.symbols kldxref: unknown metdata record 0 in file if_aue.ko.symbols kldxref: unknown metdata record 0 in file if_aue.ko.symbols kldxref: unknown metdata record 0 in file if_axe.ko.symbols kldxref: unknown metdata record 0 in file if_axe.ko.symbols kldxref: unknown metdata record 0 in file if_axe.ko.symbols kldxref: unknown metdata record 0 in file if_axe.ko.symbols kldxref: unknown metdata record 0 in file if_bce.ko.symbols kldxref: unknown metdata record 0 in file if_bce.ko.symbols kldxref: unknown metdata record 0 in file if_bce.ko.symbols kldxref: unknown metdata record 0 in file if_bce.ko.symbols kldxref: unknown metdata record 0 in file if_bce.ko.symbols kldxref: unknown metdata record 0 in file if_bfe.ko.symbols kldxref: unknown metdata record 0 in file if_bfe.ko.symbols kldxref: unknown metdata record 0 in file if_bfe.ko.symbols kldxref: unknown metdata record 0 in file if_bfe.ko.symbols kldxref: unknown metdata record 0 in file if_bfe.ko.symbols kldxref: unknown metdata record 0 in file if_bge.ko.symbols kldxref: unknown metdata record 0 in file if_bge.ko.symbols kldxref: unknown metdata record 0 in file if_bge.ko.symbols kldxref: unknown metdata record 0 in file if_bge.ko.symbols kldxref: unknown metdata record 0 in file if_bge.ko.symbols kldxref: unknown metdata record 0 in file bridgestp.ko.symbols kldxref: unknown metdata record 0 in file bridgestp.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cam.ko.symbols kldxref: unknown metdata record 0 in file cardbus.ko.symbols kldxref: unknown metdata record 0 in file cardbus.ko.symbols kldxref: unknown metdata record 0 in file cbb.ko.symbols kldxref: unknown metdata record 0 in file cbb.ko.symbols kldxref: unknown metdata record 0 in file cbb.ko.symbols kldxref: unknown metdata record 0 in file cbb.ko.symbols kldxref: unknown metdata record 0 in file cd9660.ko.symbols kldxref: unknown metdata record 0 in file cd9660.ko.symbols kldxref: unknown metdata record 0 in file cd9660_iconv.ko.symbols kldxref: unknown metdata record 0 in file cd9660_iconv.ko.symbols kldxref: unknown metdata record 0 in file cd9660_iconv.ko.symbols kldxref: unknown metdata record 0 in file cd9660_iconv.ko.symbols kldxref: unknown metdata record 0 in file if_cdce.ko.symbols kldxref: unknown metdata record 0 in file if_cdce.ko.symbols kldxref: unknown metdata record 0 in file if_cdce.ko.symbols kldxref: unknown metdata record 0 in file ciss.ko.symbols kldxref: unknown metdata record 0 in file ciss.ko.symbols kldxref: unknown metdata record 0 in file ciss.ko.symbols kldxref: unknown metdata record 0 in file coda.ko.symbols kldxref: unknown metdata record 0 in file coda.ko.symbols kldxref: unknown metdata record 0 in file coda5.ko.symbols kldxref: unknown metdata record 0 in file coda5.ko.symbols kldxref: unknown metdata record 0 in file coretemp.ko.symbols kldxref: unknown metdata record 0 in file cpufreq.ko.symbols kldxref: unknown metdata record 0 in file cpufreq.ko.symbols kldxref: unknown metdata record 0 in file cpufreq.ko.symbols kldxref: unknown metdata record 0 in file cpufreq.ko.symbols kldxref: unknown metdata record 0 in file cpufreq.ko.symbols kldxref: unknown metdata record 0 in file crypto.ko.symbols kldxref: unknown metdata record 0 in file crypto.ko.symbols kldxref: unknown metdata record 0 in file crypto.ko.symbols kldxref: unknown metdata record 0 in file crypto.ko.symbols kldxref: unknown metdata record 0 in file crypto.ko.symbols kldxref: unknown metdata record 0 in file cryptodev.ko.symbols kldxref: unknown metdata record 0 in file cryptodev.ko.symbols kldxref: unknown metdata record 0 in file cryptodev.ko.symbols kldxref: unknown metdata record 0 in file cryptodev.ko.symbols kldxref: unknown metdata record 0 in file if_cue.ko.symbols kldxref: unknown metdata record 0 in file if_cue.ko.symbols kldxref: unknown metdata record 0 in file if_cue.ko.symbols kldxref: unknown metdata record 0 in file if_cxgb.ko.symbols kldxref: unknown metdata record 0 in file if_cxgb.ko.symbols kldxref: unknown metdata record 0 in file if_cxgb.ko.symbols kldxref: unknown metdata record 0 in file if_cxgb.ko.symbols kldxref: unknown metdata record 0 in file if_cxgb.ko.symbols kldxref: unknown metdata record 0 in file if_dc.ko.symbols kldxref: unknown metdata record 0 in file if_dc.ko.symbols kldxref: unknown metdata record 0 in file if_dc.ko.symbols kldxref: unknown metdata record 0 in file if_dc.ko.symbols kldxref: unknown metdata record 0 in file if_dc.ko.symbols kldxref: unknown metdata record 0 in file if_dc.ko.symbols kldxref: unknown metdata record 0 in file if_dc.ko.symbols kldxref: unknown metdata record 0 in file if_dc.ko.symbols kldxref: unknown metdata record 0 in file dcons.ko.symbols kldxref: unknown metdata record 0 in file dcons.ko.symbols kldxref: unknown metdata record 0 in file dcons_crom.ko.symbols kldxref: unknown metdata record 0 in file dcons_crom.ko.symbols kldxref: unknown metdata record 0 in file dcons_crom.ko.symbols kldxref: unknown metdata record 0 in file dcons_crom.ko.symbols kldxref: unknown metdata record 0 in file if_de.ko.symbols kldxref: unknown metdata record 0 in file digi.ko.symbols kldxref: unknown metdata record 0 in file digi.ko.symbols kldxref: unknown metdata record 0 in file digi.ko.symbols kldxref: unknown metdata record 0 in file digi_CX.ko.symbols kldxref: unknown metdata record 0 in file digi_CX.ko.symbols kldxref: unknown metdata record 0 in file digi_CX_PCI.ko.symbols kldxref: unknown metdata record 0 in file digi_CX_PCI.ko.symbols kldxref: unknown metdata record 0 in file digi_EPCX.ko.symbols kldxref: unknown metdata record 0 in file digi_EPCX.ko.symbols kldxref: unknown metdata record 0 in file digi_EPCX_PCI.ko.symbols kldxref: unknown metdata record 0 in file digi_EPCX_PCI.ko.symbols kldxref: unknown metdata record 0 in file digi_Xe.ko.symbols kldxref: unknown metdata record 0 in file digi_Xe.ko.symbols kldxref: unknown metdata record 0 in file digi_Xem.ko.symbols kldxref: unknown metdata record 0 in file digi_Xem.ko.symbols kldxref: unknown metdata record 0 in file digi_Xr.ko.symbols kldxref: unknown metdata record 0 in file digi_Xr.ko.symbols kldxref: unknown metdata record 0 in file drm.ko.symbols kldxref: unknown metdata record 0 in file drm.ko.symbols kldxref: unknown metdata record 0 in file drm.ko.symbols kldxref: unknown metdata record 0 in file drm.ko.symbols kldxref: unknown metdata record 0 in file i915.ko.symbols kldxref: unknown metdata record 0 in file i915.ko.symbols kldxref: unknown metdata record 0 in file mach64.ko.symbols kldxref: unknown metdata record 0 in file mach64.ko.symbols kldxref: unknown metdata record 0 in file mga.ko.symbols kldxref: unknown metdata record 0 in file mga.ko.symbols kldxref: unknown metdata record 0 in file r128.ko.symbols kldxref: unknown metdata record 0 in file r128.ko.symbols kldxref: unknown metdata record 0 in file radeon.ko.symbols kldxref: unknown metdata record 0 in file radeon.ko.symbols kldxref: unknown metdata record 0 in file savage.ko.symbols kldxref: unknown metdata record 0 in file savage.ko.symbols kldxref: unknown metdata record 0 in file sis.ko.symbols kldxref: unknown metdata record 0 in file sis.ko.symbols kldxref: unknown metdata record 0 in file tdfx.ko.symbols kldxref: unknown metdata record 0 in file tdfx.ko.symbols kldxref: unknown metdata record 0 in file dummynet.ko.symbols kldxref: unknown metdata record 0 in file dummynet.ko.symbols kldxref: unknown metdata record 0 in file dummynet.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_ed.ko.symbols kldxref: unknown metdata record 0 in file if_em.ko.symbols kldxref: unknown metdata record 0 in file if_em.ko.symbols kldxref: unknown metdata record 0 in file if_em.ko.symbols kldxref: unknown metdata record 0 in file if_en.ko.symbols kldxref: unknown metdata record 0 in file if_en.ko.symbols kldxref: unknown metdata record 0 in file if_en.ko.symbols kldxref: unknown metdata record 0 in file if_en.ko.symbols kldxref: unknown metdata record 0 in file exca.ko.symbols kldxref: unknown metdata record 0 in file exca.ko.symbols kldxref: unknown metdata record 0 in file ext2fs.ko.symbols kldxref: unknown metdata record 0 in file if_fatm.ko.symbols kldxref: unknown metdata record 0 in file if_fatm.ko.symbols kldxref: unknown metdata record 0 in file fdc.ko.symbols kldxref: unknown metdata record 0 in file fdc.ko.symbols kldxref: unknown metdata record 0 in file fdc.ko.symbols kldxref: unknown metdata record 0 in file fdc.ko.symbols kldxref: unknown metdata record 0 in file fdescfs.ko.symbols kldxref: unknown metdata record 0 in file firewire.ko.symbols kldxref: unknown metdata record 0 in file firewire.ko.symbols kldxref: unknown metdata record 0 in file firewire.ko.symbols kldxref: unknown metdata record 0 in file firewire.ko.symbols kldxref: unknown metdata record 0 in file if_fwe.ko.symbols kldxref: unknown metdata record 0 in file if_fwe.ko.symbols kldxref: unknown metdata record 0 in file if_fwe.ko.symbols kldxref: unknown metdata record 0 in file if_fwip.ko.symbols kldxref: unknown metdata record 0 in file if_fwip.ko.symbols kldxref: unknown metdata record 0 in file if_fwip.ko.symbols kldxref: unknown metdata record 0 in file if_fwip.ko.symbols kldxref: unknown metdata record 0 in file if_fwip.ko.symbols kldxref: unknown metdata record 0 in file sbp.ko.symbols kldxref: unknown metdata record 0 in file sbp.ko.symbols kldxref: unknown metdata record 0 in file sbp.ko.symbols kldxref: unknown metdata record 0 in file sbp.ko.symbols kldxref: unknown metdata record 0 in file sbp_targ.ko.symbols kldxref: unknown metdata record 0 in file sbp_targ.ko.symbols kldxref: unknown metdata record 0 in file sbp_targ.ko.symbols kldxref: unknown metdata record 0 in file sbp_targ.ko.symbols kldxref: unknown metdata record 0 in file firmware.ko.symbols kldxref: unknown metdata record 0 in file firmware.ko.symbols kldxref: unknown metdata record 0 in file if_fxp.ko.symbols kldxref: unknown metdata record 0 in file if_fxp.ko.symbols kldxref: unknown metdata record 0 in file if_fxp.ko.symbols kldxref: unknown metdata record 0 in file if_fxp.ko.symbols kldxref: unknown metdata record 0 in file if_fxp.ko.symbols kldxref: unknown metdata record 0 in file if_fxp.ko.symbols kldxref: unknown metdata record 0 in file geom_bde.ko.symbols kldxref: unknown metdata record 0 in file geom_bsd.ko.symbols kldxref: unknown metdata record 0 in file geom_cache.ko.symbols kldxref: unknown metdata record 0 in file geom_ccd.ko.symbols kldxref: unknown metdata record 0 in file geom_concat.ko.symbols kldxref: unknown metdata record 0 in file geom_eli.ko.symbols kldxref: unknown metdata record 0 in file geom_eli.ko.symbols kldxref: unknown metdata record 0 in file geom_fox.ko.symbols kldxref: unknown metdata record 0 in file geom_gate.ko.symbols kldxref: unknown metdata record 0 in file geom_gate.ko.symbols kldxref: unknown metdata record 0 in file geom_journal.ko.symbols kldxref: unknown metdata record 0 in file geom_journal.ko.symbols kldxref: unknown metdata record 0 in file geom_label.ko.symbols kldxref: unknown metdata record 0 in file geom_mbr.ko.symbols kldxref: unknown metdata record 0 in file geom_mbr.ko.symbols kldxref: unknown metdata record 0 in file geom_mirror.ko.symbols kldxref: unknown metdata record 0 in file geom_multipath.ko.symbols kldxref: unknown metdata record 0 in file geom_nop.ko.symbols kldxref: unknown metdata record 0 in file geom_pc98.ko.symbols kldxref: unknown metdata record 0 in file geom_raid3.ko.symbols kldxref: unknown metdata record 0 in file geom_shsec.ko.symbols kldxref: unknown metdata record 0 in file geom_stripe.ko.symbols kldxref: unknown metdata record 0 in file geom_sunlabel.ko.symbols kldxref: unknown metdata record 0 in file geom_uzip.ko.symbols kldxref: unknown metdata record 0 in file geom_uzip.ko.symbols kldxref: unknown metdata record 0 in file geom_vinum.ko.symbols kldxref: unknown metdata record 0 in file geom_vinum.ko.symbols kldxref: unknown metdata record 0 in file geom_vinum.ko.symbols kldxref: unknown metdata record 0 in file geom_vinum.ko.symbols kldxref: unknown metdata record 0 in file geom_vol_ffs.ko.symbols kldxref: unknown metdata record 0 in file geom_zero.ko.symbols kldxref: unknown metdata record 0 in file if_hatm.ko.symbols kldxref: unknown metdata record 0 in file if_hatm.ko.symbols kldxref: unknown metdata record 0 in file if_hatm.ko.symbols kldxref: unknown metdata record 0 in file if_hatm.ko.symbols kldxref: unknown metdata record 0 in file hifn.ko.symbols kldxref: unknown metdata record 0 in file hifn.ko.symbols kldxref: unknown metdata record 0 in file if_hme.ko.symbols kldxref: unknown metdata record 0 in file if_hme.ko.symbols kldxref: unknown metdata record 0 in file if_hme.ko.symbols kldxref: unknown metdata record 0 in file if_hme.ko.symbols kldxref: unknown metdata record 0 in file if_hme.ko.symbols kldxref: unknown metdata record 0 in file hptiop.ko.symbols kldxref: unknown metdata record 0 in file hptmv.ko.symbols kldxref: unknown metdata record 0 in file hwpmc.ko.symbols kldxref: unknown metdata record 0 in file hwpmc.ko.symbols kldxref: unknown metdata record 0 in file alpm.ko.symbols kldxref: unknown metdata record 0 in file alpm.ko.symbols kldxref: unknown metdata record 0 in file alpm.ko.symbols kldxref: unknown metdata record 0 in file alpm.ko.symbols kldxref: unknown metdata record 0 in file alpm.ko.symbols kldxref: unknown metdata record 0 in file amdpm.ko.symbols kldxref: unknown metdata record 0 in file amdpm.ko.symbols kldxref: unknown metdata record 0 in file amdpm.ko.symbols kldxref: unknown metdata record 0 in file amdpm.ko.symbols kldxref: unknown metdata record 0 in file amdpm.ko.symbols kldxref: unknown metdata record 0 in file amdsmb.ko.symbols kldxref: unknown metdata record 0 in file amdsmb.ko.symbols kldxref: unknown metdata record 0 in file amdsmb.ko.symbols kldxref: unknown metdata record 0 in file amdsmb.ko.symbols kldxref: unknown metdata record 0 in file amdsmb.ko.symbols kldxref: unknown metdata record 0 in file ichsmb.ko.symbols kldxref: unknown metdata record 0 in file ichsmb.ko.symbols kldxref: unknown metdata record 0 in file ichsmb.ko.symbols kldxref: unknown metdata record 0 in file ichsmb.ko.symbols kldxref: unknown metdata record 0 in file ichsmb.ko.symbols kldxref: unknown metdata record 0 in file intpm.ko.symbols kldxref: unknown metdata record 0 in file intpm.ko.symbols kldxref: unknown metdata record 0 in file intpm.ko.symbols kldxref: unknown metdata record 0 in file intpm.ko.symbols kldxref: unknown metdata record 0 in file nfsmb.ko.symbols kldxref: unknown metdata record 0 in file nfsmb.ko.symbols kldxref: unknown metdata record 0 in file nfsmb.ko.symbols kldxref: unknown metdata record 0 in file nfsmb.ko.symbols kldxref: unknown metdata record 0 in file nfsmb.ko.symbols kldxref: unknown metdata record 0 in file nfsmb.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file viapm.ko.symbols kldxref: unknown metdata record 0 in file lpbb.ko.symbols kldxref: unknown metdata record 0 in file lpbb.ko.symbols kldxref: unknown metdata record 0 in file lpbb.ko.symbols kldxref: unknown metdata record 0 in file lpbb.ko.symbols kldxref: unknown metdata record 0 in file if_ic.ko.symbols kldxref: unknown metdata record 0 in file if_ic.ko.symbols kldxref: unknown metdata record 0 in file if_ic.ko.symbols kldxref: unknown metdata record 0 in file smbus.ko.symbols kldxref: unknown metdata record 0 in file iicbus.ko.symbols kldxref: unknown metdata record 0 in file iicbus.ko.symbols kldxref: unknown metdata record 0 in file iicbus.ko.symbols kldxref: unknown metdata record 0 in file iicbb.ko.symbols kldxref: unknown metdata record 0 in file iicbb.ko.symbols kldxref: unknown metdata record 0 in file iicbb.ko.symbols kldxref: unknown metdata record 0 in file iicbb.ko.symbols kldxref: unknown metdata record 0 in file iicbb.ko.symbols kldxref: unknown metdata record 0 in file iicbb.ko.symbols kldxref: unknown metdata record 0 in file iicbb.ko.symbols kldxref: unknown metdata record 0 in file iicbb.ko.symbols kldxref: unknown metdata record 0 in file iicsmb.ko.symbols kldxref: unknown metdata record 0 in file iicsmb.ko.symbols kldxref: unknown metdata record 0 in file iicsmb.ko.symbols kldxref: unknown metdata record 0 in file iicsmb.ko.symbols kldxref: unknown metdata record 0 in file iicsmb.ko.symbols kldxref: unknown metdata record 0 in file iic.ko.symbols kldxref: unknown metdata record 0 in file iic.ko.symbols kldxref: unknown metdata record 0 in file iic.ko.symbols kldxref: unknown metdata record 0 in file smb.ko.symbols kldxref: unknown metdata record 0 in file smb.ko.symbols kldxref: unknown metdata record 0 in file smb.ko.symbols kldxref: unknown metdata record 0 in file ichwd.ko.symbols kldxref: unknown metdata record 0 in file ida.ko.symbols kldxref: unknown metdata record 0 in file ida.ko.symbols kldxref: unknown metdata record 0 in file if_bridge.ko.symbols kldxref: unknown metdata record 0 in file if_bridge.ko.symbols kldxref: unknown metdata record 0 in file if_disc.ko.symbols kldxref: unknown metdata record 0 in file if_edsc.ko.symbols kldxref: unknown metdata record 0 in file if_ef.ko.symbols kldxref: unknown metdata record 0 in file if_faith.ko.symbols kldxref: unknown metdata record 0 in file if_faith.ko.symbols kldxref: unknown metdata record 0 in file if_gif.ko.symbols kldxref: unknown metdata record 0 in file if_gif.ko.symbols kldxref: unknown metdata record 0 in file if_gre.ko.symbols kldxref: unknown metdata record 0 in file if_gre.ko.symbols kldxref: unknown metdata record 0 in file if_lagg.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ndis.ko.symbols kldxref: unknown metdata record 0 in file if_ppp.ko.symbols kldxref: unknown metdata record 0 in file if_ppp.ko.symbols kldxref: unknown metdata record 0 in file if_sl.ko.symbols kldxref: unknown metdata record 0 in file if_stf.ko.symbols kldxref: unknown metdata record 0 in file if_tap.ko.symbols kldxref: unknown metdata record 0 in file if_tun.ko.symbols kldxref: unknown metdata record 0 in file if_vlan.ko.symbols kldxref: unknown metdata record 0 in file if_vlan.ko.symbols kldxref: unknown metdata record 0 in file if_vlan.ko.symbols kldxref: unknown metdata record 0 in file iir.ko.symbols kldxref: unknown metdata record 0 in file iir.ko.symbols kldxref: unknown metdata record 0 in file iir.ko.symbols kldxref: unknown metdata record 0 in file io.ko.symbols kldxref: unknown metdata record 0 in file io.ko.symbols kldxref: unknown metdata record 0 in file ipdivert.ko.symbols kldxref: unknown metdata record 0 in file ipdivert.ko.symbols kldxref: unknown metdata record 0 in file ipdivert.ko.symbols kldxref: unknown metdata record 0 in file ipl.ko.symbols kldxref: unknown metdata record 0 in file ipl.ko.symbols kldxref: unknown metdata record 0 in file ipfw.ko.symbols kldxref: unknown metdata record 0 in file ipfw.ko.symbols kldxref: unknown metdata record 0 in file ip_mroute.ko.symbols kldxref: unknown metdata record 0 in file ipmi.ko.symbols kldxref: unknown metdata record 0 in file ipmi.ko.symbols kldxref: unknown metdata record 0 in file ipmi.ko.symbols kldxref: unknown metdata record 0 in file ipmi.ko.symbols kldxref: unknown metdata record 0 in file ipmi.ko.symbols kldxref: unknown metdata record 0 in file ipmi.ko.symbols kldxref: unknown metdata record 0 in file ipmi.ko.symbols kldxref: unknown metdata record 0 in file ips.ko.symbols kldxref: unknown metdata record 0 in file ips.ko.symbols kldxref: unknown metdata record 0 in file if_ipw.ko.symbols kldxref: unknown metdata record 0 in file if_ipw.ko.symbols kldxref: unknown metdata record 0 in file if_ipw.ko.symbols kldxref: unknown metdata record 0 in file if_ipw.ko.symbols kldxref: unknown metdata record 0 in file ipw_bss.ko.symbols kldxref: unknown metdata record 0 in file ipw_bss.ko.symbols kldxref: unknown metdata record 0 in file ipw_bss.ko.symbols kldxref: unknown metdata record 0 in file ipw_ibss.ko.symbols kldxref: unknown metdata record 0 in file ipw_ibss.ko.symbols kldxref: unknown metdata record 0 in file ipw_ibss.ko.symbols kldxref: unknown metdata record 0 in file ipw_monitor.ko.symbols kldxref: unknown metdata record 0 in file ipw_monitor.ko.symbols kldxref: unknown metdata record 0 in file ipw_monitor.ko.symbols kldxref: unknown metdata record 0 in file iscsi_initiator.ko.symbols kldxref: unknown metdata record 0 in file isp.ko.symbols kldxref: unknown metdata record 0 in file isp.ko.symbols kldxref: unknown metdata record 0 in file isp.ko.symbols kldxref: unknown metdata record 0 in file ispfw.ko.symbols kldxref: unknown metdata record 0 in file isp_1040.ko.symbols kldxref: unknown metdata record 0 in file isp_1040_it.ko.symbols kldxref: unknown metdata record 0 in file isp_1080.ko.symbols kldxref: unknown metdata record 0 in file isp_1080_it.ko.symbols kldxref: unknown metdata record 0 in file isp_12160.ko.symbols kldxref: unknown metdata record 0 in file isp_12160_it.ko.symbols kldxref: unknown metdata record 0 in file isp_2100.ko.symbols kldxref: unknown metdata record 0 in file isp_2200.ko.symbols kldxref: unknown metdata record 0 in file isp_2300.ko.symbols kldxref: unknown metdata record 0 in file isp_2322.ko.symbols kldxref: unknown metdata record 0 in file isp_2400.ko.symbols kldxref: unknown metdata record 0 in file if_ixgb.ko.symbols kldxref: unknown metdata record 0 in file if_ixgb.ko.symbols kldxref: unknown metdata record 0 in file if_ixgb.ko.symbols kldxref: unknown metdata record 0 in file joy.ko.symbols kldxref: unknown metdata record 0 in file joy.ko.symbols kldxref: unknown metdata record 0 in file joy.ko.symbols kldxref: unknown metdata record 0 in file kbdmux.ko.symbols kldxref: unknown metdata record 0 in file if_kue.ko.symbols kldxref: unknown metdata record 0 in file if_kue.ko.symbols kldxref: unknown metdata record 0 in file if_kue.ko.symbols kldxref: unknown metdata record 0 in file if_le.ko.symbols kldxref: unknown metdata record 0 in file if_le.ko.symbols kldxref: unknown metdata record 0 in file if_lge.ko.symbols kldxref: unknown metdata record 0 in file if_lge.ko.symbols kldxref: unknown metdata record 0 in file if_lge.ko.symbols kldxref: unknown metdata record 0 in file if_lge.ko.symbols kldxref: unknown metdata record 0 in file if_lge.ko.symbols kldxref: unknown metdata record 0 in file libalias.ko.symbols kldxref: unknown metdata record 0 in file libalias.ko.symbols kldxref: unknown metdata record 0 in file alias_cuseeme.ko.symbols kldxref: unknown metdata record 0 in file alias_cuseeme.ko.symbols kldxref: unknown metdata record 0 in file alias_cuseeme.ko.symbols kldxref: unknown metdata record 0 in file alias_dummy.ko.symbols kldxref: unknown metdata record 0 in file alias_dummy.ko.symbols kldxref: unknown metdata record 0 in file alias_dummy.ko.symbols kldxref: unknown metdata record 0 in file alias_ftp.ko.symbols kldxref: unknown metdata record 0 in file alias_ftp.ko.symbols kldxref: unknown metdata record 0 in file alias_ftp.ko.symbols kldxref: unknown metdata record 0 in file alias_irc.ko.symbols kldxref: unknown metdata record 0 in file alias_irc.ko.symbols kldxref: unknown metdata record 0 in file alias_irc.ko.symbols kldxref: unknown metdata record 0 in file alias_nbt.ko.symbols kldxref: unknown metdata record 0 in file alias_nbt.ko.symbols kldxref: unknown metdata record 0 in file alias_nbt.ko.symbols kldxref: unknown metdata record 0 in file alias_pptp.ko.symbols kldxref: unknown metdata record 0 in file alias_pptp.ko.symbols kldxref: unknown metdata record 0 in file alias_pptp.ko.symbols kldxref: unknown metdata record 0 in file alias_skinny.ko.symbols kldxref: unknown metdata record 0 in file alias_skinny.ko.symbols kldxref: unknown metdata record 0 in file alias_skinny.ko.symbols kldxref: unknown metdata record 0 in file alias_smedia.ko.symbols kldxref: unknown metdata record 0 in file alias_smedia.ko.symbols kldxref: unknown metdata record 0 in file alias_smedia.ko.symbols kldxref: unknown metdata record 0 in file libiconv.ko.symbols kldxref: unknown metdata record 0 in file libiconv.ko.symbols kldxref: unknown metdata record 0 in file libiconv.ko.symbols kldxref: unknown metdata record 0 in file libiconv.ko.symbols kldxref: unknown metdata record 0 in file libiconv.ko.symbols kldxref: unknown metdata record 0 in file libiconv.ko.symbols kldxref: unknown metdata record 0 in file libmbpool.ko.symbols kldxref: unknown metdata record 0 in file libmchain.ko.symbols kldxref: unknown metdata record 0 in file linprocfs.ko.symbols kldxref: unknown metdata record 0 in file linprocfs.ko.symbols kldxref: unknown metdata record 0 in file linprocfs.ko.symbols kldxref: unknown metdata record 0 in file linprocfs.ko.symbols kldxref: unknown metdata record 0 in file linprocfs.ko.symbols kldxref: unknown metdata record 0 in file linprocfs.ko.symbols kldxref: unknown metdata record 0 in file linprocfs.ko.symbols kldxref: unknown metdata record 0 in file linsysfs.ko.symbols kldxref: unknown metdata record 0 in file linsysfs.ko.symbols kldxref: unknown metdata record 0 in file linsysfs.ko.symbols kldxref: unknown metdata record 0 in file linsysfs.ko.symbols kldxref: unknown metdata record 0 in file linux.ko.symbols kldxref: unknown metdata record 0 in file linux.ko.symbols kldxref: unknown metdata record 0 in file linux.ko.symbols kldxref: unknown metdata record 0 in file linux.ko.symbols kldxref: unknown metdata record 0 in file linux.ko.symbols kldxref: unknown metdata record 0 in file if_lmc.ko.symbols kldxref: unknown metdata record 0 in file if_lmc.ko.symbols kldxref: unknown metdata record 0 in file if_lmc.ko.symbols kldxref: unknown metdata record 0 in file if_lmc.ko.symbols kldxref: unknown metdata record 0 in file if_lmc.ko.symbols kldxref: unknown metdata record 0 in file lpt.ko.symbols kldxref: unknown metdata record 0 in file lpt.ko.symbols kldxref: unknown metdata record 0 in file mac_biba.ko.symbols kldxref: unknown metdata record 0 in file mac_biba.ko.symbols kldxref: unknown metdata record 0 in file mac_bsdextended.ko.symbols kldxref: unknown metdata record 0 in file mac_bsdextended.ko.symbols kldxref: unknown metdata record 0 in file mac_ifoff.ko.symbols kldxref: unknown metdata record 0 in file mac_ifoff.ko.symbols kldxref: unknown metdata record 0 in file mac_lomac.ko.symbols kldxref: unknown metdata record 0 in file mac_lomac.ko.symbols kldxref: unknown metdata record 0 in file mac_mls.ko.symbols kldxref: unknown metdata record 0 in file mac_mls.ko.symbols kldxref: unknown metdata record 0 in file mac_none.ko.symbols kldxref: unknown metdata record 0 in file mac_none.ko.symbols kldxref: unknown metdata record 0 in file mac_partition.ko.symbols kldxref: unknown metdata record 0 in file mac_partition.ko.symbols kldxref: unknown metdata record 0 in file mac_portacl.ko.symbols kldxref: unknown metdata record 0 in file mac_portacl.ko.symbols kldxref: unknown metdata record 0 in file mac_seeotheruids.ko.symbols kldxref: unknown metdata record 0 in file mac_seeotheruids.ko.symbols kldxref: unknown metdata record 0 in file mac_stub.ko.symbols kldxref: unknown metdata record 0 in file mac_stub.ko.symbols kldxref: unknown metdata record 0 in file mac_test.ko.symbols kldxref: unknown metdata record 0 in file mac_test.ko.symbols kldxref: unknown metdata record 0 in file mcd.ko.symbols kldxref: unknown metdata record 0 in file geom_md.ko.symbols kldxref: unknown metdata record 0 in file mem.ko.symbols kldxref: unknown metdata record 0 in file mem.ko.symbols kldxref: unknown metdata record 0 in file mfi.ko.symbols kldxref: unknown metdata record 0 in file mfi.ko.symbols kldxref: unknown metdata record 0 in file mfip.ko.symbols kldxref: unknown metdata record 0 in file mfip.ko.symbols kldxref: unknown metdata record 0 in file mfi_linux.ko.symbols kldxref: unknown metdata record 0 in file mfi_linux.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file miibus.ko.symbols kldxref: unknown metdata record 0 in file mlx.ko.symbols kldxref: unknown metdata record 0 in file mlx.ko.symbols kldxref: unknown metdata record 0 in file mly.ko.symbols kldxref: unknown metdata record 0 in file mly.ko.symbols kldxref: unknown metdata record 0 in file mly.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mpt.ko.symbols kldxref: unknown metdata record 0 in file mqueuefs.ko.symbols kldxref: unknown metdata record 0 in file mqueuefs.ko.symbols kldxref: unknown metdata record 0 in file mqueuefs.ko.symbols kldxref: unknown metdata record 0 in file mqueuefs.ko.symbols kldxref: unknown metdata record 0 in file mqueuefs.ko.symbols kldxref: unknown metdata record 0 in file mqueuefs.ko.symbols kldxref: unknown metdata record 0 in file mqueuefs.ko.symbols kldxref: unknown metdata record 0 in file mqueuefs.ko.symbols kldxref: unknown metdata record 0 in file msdosfs.ko.symbols kldxref: unknown metdata record 0 in file msdosfs.ko.symbols kldxref: unknown metdata record 0 in file msdosfs_iconv.ko.symbols kldxref: unknown metdata record 0 in file msdosfs_iconv.ko.symbols kldxref: unknown metdata record 0 in file msdosfs_iconv.ko.symbols kldxref: unknown metdata record 0 in file msdosfs_iconv.ko.symbols kldxref: unknown metdata record 0 in file if_msk.ko.symbols kldxref: unknown metdata record 0 in file if_msk.ko.symbols kldxref: unknown metdata record 0 in file if_msk.ko.symbols kldxref: unknown metdata record 0 in file if_msk.ko.symbols kldxref: unknown metdata record 0 in file if_msk.ko.symbols kldxref: unknown metdata record 0 in file if_msk.ko.symbols kldxref: unknown metdata record 0 in file if_mxge.ko.symbols kldxref: unknown metdata record 0 in file if_mxge.ko.symbols kldxref: unknown metdata record 0 in file if_mxge.ko.symbols kldxref: unknown metdata record 0 in file mxge_eth_z8e.ko.symbols kldxref: unknown metdata record 0 in file mxge_eth_z8e.ko.symbols kldxref: unknown metdata record 0 in file mxge_eth_z8e.ko.symbols kldxref: unknown metdata record 0 in file mxge_ethp_z8e.ko.symbols kldxref: unknown metdata record 0 in file mxge_ethp_z8e.ko.symbols kldxref: unknown metdata record 0 in file mxge_ethp_z8e.ko.symbols kldxref: unknown metdata record 0 in file if_my.ko.symbols kldxref: unknown metdata record 0 in file if_my.ko.symbols kldxref: unknown metdata record 0 in file if_my.ko.symbols kldxref: unknown metdata record 0 in file ndis.ko.symbols kldxref: unknown metdata record 0 in file ndis.ko.symbols kldxref: unknown metdata record 0 in file ng_async.ko.symbols kldxref: unknown metdata record 0 in file ng_async.ko.symbols kldxref: unknown metdata record 0 in file ng_atm.ko.symbols kldxref: unknown metdata record 0 in file ng_atm.ko.symbols kldxref: unknown metdata record 0 in file ngatmbase.ko.symbols kldxref: unknown metdata record 0 in file ngatmbase.ko.symbols kldxref: unknown metdata record 0 in file ng_ccatm.ko.symbols kldxref: unknown metdata record 0 in file ng_ccatm.ko.symbols kldxref: unknown metdata record 0 in file ng_ccatm.ko.symbols kldxref: unknown metdata record 0 in file ng_sscfu.ko.symbols kldxref: unknown metdata record 0 in file ng_sscfu.ko.symbols kldxref: unknown metdata record 0 in file ng_sscfu.ko.symbols kldxref: unknown metdata record 0 in file ng_sscop.ko.symbols kldxref: unknown metdata record 0 in file ng_sscop.ko.symbols kldxref: unknown metdata record 0 in file ng_sscop.ko.symbols kldxref: unknown metdata record 0 in file ng_uni.ko.symbols kldxref: unknown metdata record 0 in file ng_uni.ko.symbols kldxref: unknown metdata record 0 in file ng_uni.ko.symbols kldxref: unknown metdata record 0 in file ng_atmllc.ko.symbols kldxref: unknown metdata record 0 in file ng_atmllc.ko.symbols kldxref: unknown metdata record 0 in file ng_bluetooth.ko.symbols kldxref: unknown metdata record 0 in file ng_bluetooth.ko.symbols kldxref: unknown metdata record 0 in file ng_hci.ko.symbols kldxref: unknown metdata record 0 in file ng_hci.ko.symbols kldxref: unknown metdata record 0 in file ng_hci.ko.symbols kldxref: unknown metdata record 0 in file ng_hci.ko.symbols kldxref: unknown metdata record 0 in file ng_l2cap.ko.symbols kldxref: unknown metdata record 0 in file ng_l2cap.ko.symbols kldxref: unknown metdata record 0 in file ng_l2cap.ko.symbols kldxref: unknown metdata record 0 in file ng_l2cap.ko.symbols kldxref: unknown metdata record 0 in file ng_btsocket.ko.symbols kldxref: unknown metdata record 0 in file ng_btsocket.ko.symbols kldxref: unknown metdata record 0 in file ng_btsocket.ko.symbols kldxref: unknown metdata record 0 in file ng_btsocket.ko.symbols kldxref: unknown metdata record 0 in file ng_bt3c.ko.symbols kldxref: unknown metdata record 0 in file ng_bt3c.ko.symbols kldxref: unknown metdata record 0 in file ng_bt3c.ko.symbols kldxref: unknown metdata record 0 in file ng_h4.ko.symbols kldxref: unknown metdata record 0 in file ng_h4.ko.symbols kldxref: unknown metdata record 0 in file ng_h4.ko.symbols kldxref: unknown metdata record 0 in file ng_ubt.ko.symbols kldxref: unknown metdata record 0 in file ng_ubt.ko.symbols kldxref: unknown metdata record 0 in file ng_ubt.ko.symbols kldxref: unknown metdata record 0 in file ng_ubt.ko.symbols kldxref: unknown metdata record 0 in file ubtbcmfw.ko.symbols kldxref: unknown metdata record 0 in file ubtbcmfw.ko.symbols kldxref: unknown metdata record 0 in file ng_bpf.ko.symbols kldxref: unknown metdata record 0 in file ng_bpf.ko.symbols kldxref: unknown metdata record 0 in file ng_bridge.ko.symbols kldxref: unknown metdata record 0 in file ng_bridge.ko.symbols kldxref: unknown metdata record 0 in file ng_car.ko.symbols kldxref: unknown metdata record 0 in file ng_car.ko.symbols kldxref: unknown metdata record 0 in file ng_cisco.ko.symbols kldxref: unknown metdata record 0 in file ng_cisco.ko.symbols kldxref: unknown metdata record 0 in file ng_deflate.ko.symbols kldxref: unknown metdata record 0 in file ng_deflate.ko.symbols kldxref: unknown metdata record 0 in file ng_deflate.ko.symbols kldxref: unknown metdata record 0 in file ng_device.ko.symbols kldxref: unknown metdata record 0 in file ng_device.ko.symbols kldxref: unknown metdata record 0 in file ng_echo.ko.symbols kldxref: unknown metdata record 0 in file ng_echo.ko.symbols kldxref: unknown metdata record 0 in file ng_eiface.ko.symbols kldxref: unknown metdata record 0 in file ng_eiface.ko.symbols kldxref: unknown metdata record 0 in file ng_etf.ko.symbols kldxref: unknown metdata record 0 in file ng_etf.ko.symbols kldxref: unknown metdata record 0 in file ng_ether.ko.symbols kldxref: unknown metdata record 0 in file ng_ether.ko.symbols kldxref: unknown metdata record 0 in file ng_fec.ko.symbols kldxref: unknown metdata record 0 in file ng_fec.ko.symbols kldxref: unknown metdata record 0 in file ng_frame_relay.ko.symbols kldxref: unknown metdata record 0 in file ng_frame_relay.ko.symbols kldxref: unknown metdata record 0 in file ng_gif.ko.symbols kldxref: unknown metdata record 0 in file ng_gif.ko.symbols kldxref: unknown metdata record 0 in file ng_gif.ko.symbols kldxref: unknown metdata record 0 in file ng_gif_demux.ko.symbols kldxref: unknown metdata record 0 in file ng_gif_demux.ko.symbols kldxref: unknown metdata record 0 in file ng_hole.ko.symbols kldxref: unknown metdata record 0 in file ng_hole.ko.symbols kldxref: unknown metdata record 0 in file ng_hub.ko.symbols kldxref: unknown metdata record 0 in file ng_hub.ko.symbols kldxref: unknown metdata record 0 in file ng_iface.ko.symbols kldxref: unknown metdata record 0 in file ng_iface.ko.symbols kldxref: unknown metdata record 0 in file ng_ip_input.ko.symbols kldxref: unknown metdata record 0 in file ng_ip_input.ko.symbols kldxref: unknown metdata record 0 in file ng_ipfw.ko.symbols kldxref: unknown metdata record 0 in file ng_ipfw.ko.symbols kldxref: unknown metdata record 0 in file ng_ipfw.ko.symbols kldxref: unknown metdata record 0 in file ng_ksocket.ko.symbols kldxref: unknown metdata record 0 in file ng_ksocket.ko.symbols kldxref: unknown metdata record 0 in file ng_l2tp.ko.symbols kldxref: unknown metdata record 0 in file ng_l2tp.ko.symbols kldxref: unknown metdata record 0 in file ng_lmi.ko.symbols kldxref: unknown metdata record 0 in file ng_lmi.ko.symbols kldxref: unknown metdata record 0 in file ng_mppc.ko.symbols kldxref: unknown metdata record 0 in file ng_mppc.ko.symbols kldxref: unknown metdata record 0 in file ng_mppc.ko.symbols kldxref: unknown metdata record 0 in file ng_nat.ko.symbols kldxref: unknown metdata record 0 in file ng_nat.ko.symbols kldxref: unknown metdata record 0 in file ng_nat.ko.symbols kldxref: unknown metdata record 0 in file ng_netflow.ko.symbols kldxref: unknown metdata record 0 in file ng_netflow.ko.symbols kldxref: unknown metdata record 0 in file netgraph.ko.symbols kldxref: unknown metdata record 0 in file netgraph.ko.symbols kldxref: unknown metdata record 0 in file ng_one2many.ko.symbols kldxref: unknown metdata record 0 in file ng_one2many.ko.symbols kldxref: unknown metdata record 0 in file ng_ppp.ko.symbols kldxref: unknown metdata record 0 in file ng_ppp.ko.symbols kldxref: unknown metdata record 0 in file ng_pppoe.ko.symbols kldxref: unknown metdata record 0 in file ng_pppoe.ko.symbols kldxref: unknown metdata record 0 in file ng_pptpgre.ko.symbols kldxref: unknown metdata record 0 in file ng_pptpgre.ko.symbols kldxref: unknown metdata record 0 in file ng_pred1.ko.symbols kldxref: unknown metdata record 0 in file ng_pred1.ko.symbols kldxref: unknown metdata record 0 in file ng_rfc1490.ko.symbols kldxref: unknown metdata record 0 in file ng_rfc1490.ko.symbols kldxref: unknown metdata record 0 in file ng_socket.ko.symbols kldxref: unknown metdata record 0 in file ng_socket.ko.symbols kldxref: unknown metdata record 0 in file ng_source.ko.symbols kldxref: unknown metdata record 0 in file ng_source.ko.symbols kldxref: unknown metdata record 0 in file ng_split.ko.symbols kldxref: unknown metdata record 0 in file ng_split.ko.symbols kldxref: unknown metdata record 0 in file ng_sppp.ko.symbols kldxref: unknown metdata record 0 in file ng_sppp.ko.symbols kldxref: unknown metdata record 0 in file ng_sppp.ko.symbols kldxref: unknown metdata record 0 in file ng_tag.ko.symbols kldxref: unknown metdata record 0 in file ng_tag.ko.symbols kldxref: unknown metdata record 0 in file ng_tcpmss.ko.symbols kldxref: unknown metdata record 0 in file ng_tcpmss.ko.symbols kldxref: unknown metdata record 0 in file ng_tee.ko.symbols kldxref: unknown metdata record 0 in file ng_tee.ko.symbols kldxref: unknown metdata record 0 in file ng_tty.ko.symbols kldxref: unknown metdata record 0 in file ng_tty.ko.symbols kldxref: unknown metdata record 0 in file ng_UI.ko.symbols kldxref: unknown metdata record 0 in file ng_UI.ko.symbols kldxref: unknown metdata record 0 in file ng_vjc.ko.symbols kldxref: unknown metdata record 0 in file ng_vjc.ko.symbols kldxref: unknown metdata record 0 in file ng_vlan.ko.symbols kldxref: unknown metdata record 0 in file ng_vlan.ko.symbols kldxref: unknown metdata record 0 in file if_nfe.ko.symbols kldxref: unknown metdata record 0 in file if_nfe.ko.symbols kldxref: unknown metdata record 0 in file if_nfe.ko.symbols kldxref: unknown metdata record 0 in file if_nfe.ko.symbols kldxref: unknown metdata record 0 in file if_nfe.ko.symbols kldxref: unknown metdata record 0 in file nfsclient.ko.symbols kldxref: unknown metdata record 0 in file nfsclient.ko.symbols kldxref: unknown metdata record 0 in file nfsclient.ko.symbols kldxref: unknown metdata record 0 in file nfsclient.ko.symbols kldxref: unknown metdata record 0 in file nfsclient.ko.symbols kldxref: unknown metdata record 0 in file nfsclient.ko.symbols kldxref: unknown metdata record 0 in file nfsserver.ko.symbols kldxref: unknown metdata record 0 in file nfsserver.ko.symbols kldxref: unknown metdata record 0 in file if_nge.ko.symbols kldxref: unknown metdata record 0 in file if_nge.ko.symbols kldxref: unknown metdata record 0 in file if_nge.ko.symbols kldxref: unknown metdata record 0 in file if_nge.ko.symbols kldxref: unknown metdata record 0 in file if_nge.ko.symbols kldxref: unknown metdata record 0 in file nmdm.ko.symbols kldxref: unknown metdata record 0 in file ntfs.ko.symbols kldxref: unknown metdata record 0 in file ntfs.ko.symbols kldxref: unknown metdata record 0 in file ntfs_iconv.ko.symbols kldxref: unknown metdata record 0 in file ntfs_iconv.ko.symbols kldxref: unknown metdata record 0 in file ntfs_iconv.ko.symbols kldxref: unknown metdata record 0 in file ntfs_iconv.ko.symbols kldxref: unknown metdata record 0 in file if_nxge.ko.symbols kldxref: unknown metdata record 0 in file nullfs.ko.symbols kldxref: unknown metdata record 0 in file if_nve.ko.symbols kldxref: unknown metdata record 0 in file if_nve.ko.symbols kldxref: unknown metdata record 0 in file if_nve.ko.symbols kldxref: unknown metdata record 0 in file if_nve.ko.symbols kldxref: unknown metdata record 0 in file if_nve.ko.symbols kldxref: unknown metdata record 0 in file if_patm.ko.symbols kldxref: unknown metdata record 0 in file if_patm.ko.symbols kldxref: unknown metdata record 0 in file if_patm.ko.symbols kldxref: unknown metdata record 0 in file if_patm.ko.symbols kldxref: unknown metdata record 0 in file if_patm.ko.symbols kldxref: unknown metdata record 0 in file pccard.ko.symbols kldxref: unknown metdata record 0 in file pccard.ko.symbols kldxref: unknown metdata record 0 in file pccard.ko.symbols kldxref: unknown metdata record 0 in file if_pcn.ko.symbols kldxref: unknown metdata record 0 in file if_pcn.ko.symbols kldxref: unknown metdata record 0 in file if_pcn.ko.symbols kldxref: unknown metdata record 0 in file if_pcn.ko.symbols kldxref: unknown metdata record 0 in file if_pcn.ko.symbols kldxref: unknown metdata record 0 in file pf.ko.symbols kldxref: unknown metdata record 0 in file pf.ko.symbols kldxref: unknown metdata record 0 in file pflog.ko.symbols kldxref: unknown metdata record 0 in file pflog.ko.symbols kldxref: unknown metdata record 0 in file pflog.ko.symbols kldxref: unknown metdata record 0 in file plip.ko.symbols kldxref: unknown metdata record 0 in file plip.ko.symbols kldxref: unknown metdata record 0 in file portalfs.ko.symbols kldxref: unknown metdata record 0 in file ppbus.ko.symbols kldxref: unknown metdata record 0 in file ppbus.ko.symbols kldxref: unknown metdata record 0 in file ppc.ko.symbols kldxref: unknown metdata record 0 in file ppc.ko.symbols kldxref: unknown metdata record 0 in file ppc.ko.symbols kldxref: unknown metdata record 0 in file ppc.ko.symbols kldxref: unknown metdata record 0 in file ppc.ko.symbols kldxref: unknown metdata record 0 in file ppi.ko.symbols kldxref: unknown metdata record 0 in file ppi.ko.symbols kldxref: unknown metdata record 0 in file pps.ko.symbols kldxref: unknown metdata record 0 in file pps.ko.symbols kldxref: unknown metdata record 0 in file procfs.ko.symbols kldxref: unknown metdata record 0 in file procfs.ko.symbols kldxref: unknown metdata record 0 in file procfs.ko.symbols kldxref: unknown metdata record 0 in file pseudofs.ko.symbols kldxref: unknown metdata record 0 in file pseudofs.ko.symbols kldxref: unknown metdata record 0 in file puc.ko.symbols kldxref: unknown metdata record 0 in file puc.ko.symbols kldxref: unknown metdata record 0 in file puc.ko.symbols kldxref: unknown metdata record 0 in file if_ral.ko.symbols kldxref: unknown metdata record 0 in file if_ral.ko.symbols kldxref: unknown metdata record 0 in file if_ral.ko.symbols kldxref: unknown metdata record 0 in file if_ral.ko.symbols kldxref: unknown metdata record 0 in file random.ko.symbols kldxref: unknown metdata record 0 in file random.ko.symbols kldxref: unknown metdata record 0 in file rc.ko.symbols kldxref: unknown metdata record 0 in file rc4.ko.symbols kldxref: unknown metdata record 0 in file rc4.ko.symbols kldxref: unknown metdata record 0 in file if_re.ko.symbols kldxref: unknown metdata record 0 in file if_re.ko.symbols kldxref: unknown metdata record 0 in file if_re.ko.symbols kldxref: unknown metdata record 0 in file if_re.ko.symbols kldxref: unknown metdata record 0 in file if_re.ko.symbols kldxref: unknown metdata record 0 in file if_re.ko.symbols kldxref: unknown metdata record 0 in file reiserfs.ko.symbols kldxref: unknown metdata record 0 in file if_rl.ko.symbols kldxref: unknown metdata record 0 in file if_rl.ko.symbols kldxref: unknown metdata record 0 in file if_rl.ko.symbols kldxref: unknown metdata record 0 in file if_rl.ko.symbols kldxref: unknown metdata record 0 in file if_rl.ko.symbols kldxref: unknown metdata record 0 in file if_rl.ko.symbols kldxref: unknown metdata record 0 in file rp.ko.symbols kldxref: unknown metdata record 0 in file rr232x.ko.symbols kldxref: unknown metdata record 0 in file rr232x.ko.symbols kldxref: unknown metdata record 0 in file rr232x.ko.symbols kldxref: unknown metdata record 0 in file if_rue.ko.symbols kldxref: unknown metdata record 0 in file if_rue.ko.symbols kldxref: unknown metdata record 0 in file if_rue.ko.symbols kldxref: unknown metdata record 0 in file if_rue.ko.symbols kldxref: unknown metdata record 0 in file if_rue.ko.symbols kldxref: unknown metdata record 0 in file if_rum.ko.symbols kldxref: unknown metdata record 0 in file if_rum.ko.symbols kldxref: unknown metdata record 0 in file if_rum.ko.symbols kldxref: unknown metdata record 0 in file if_rum.ko.symbols kldxref: unknown metdata record 0 in file safe.ko.symbols kldxref: unknown metdata record 0 in file safe.ko.symbols kldxref: unknown metdata record 0 in file if_sbsh.ko.symbols kldxref: unknown metdata record 0 in file if_sbsh.ko.symbols kldxref: unknown metdata record 0 in file scd.ko.symbols kldxref: unknown metdata record 0 in file scsi_low.ko.symbols kldxref: unknown metdata record 0 in file scsi_low.ko.symbols kldxref: unknown metdata record 0 in file scsi_low.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file sem.ko.symbols kldxref: unknown metdata record 0 in file if_sf.ko.symbols kldxref: unknown metdata record 0 in file if_sf.ko.symbols kldxref: unknown metdata record 0 in file if_sf.ko.symbols kldxref: unknown metdata record 0 in file if_sf.ko.symbols kldxref: unknown metdata record 0 in file if_sf.ko.symbols kldxref: unknown metdata record 0 in file if_sis.ko.symbols kldxref: unknown metdata record 0 in file if_sis.ko.symbols kldxref: unknown metdata record 0 in file if_sis.ko.symbols kldxref: unknown metdata record 0 in file if_sis.ko.symbols kldxref: unknown metdata record 0 in file if_sis.ko.symbols kldxref: unknown metdata record 0 in file if_sk.ko.symbols kldxref: unknown metdata record 0 in file if_sk.ko.symbols kldxref: unknown metdata record 0 in file if_sk.ko.symbols kldxref: unknown metdata record 0 in file if_sk.ko.symbols kldxref: unknown metdata record 0 in file if_sk.ko.symbols kldxref: unknown metdata record 0 in file if_sk.ko.symbols kldxref: unknown metdata record 0 in file smbfs.ko.symbols kldxref: unknown metdata record 0 in file smbfs.ko.symbols kldxref: unknown metdata record 0 in file smbfs.ko.symbols kldxref: unknown metdata record 0 in file smbfs.ko.symbols kldxref: unknown metdata record 0 in file smbfs.ko.symbols kldxref: unknown metdata record 0 in file smbfs.ko.symbols kldxref: unknown metdata record 0 in file smbfs.ko.symbols kldxref: unknown metdata record 0 in file smbfs.ko.symbols kldxref: unknown metdata record 0 in file if_sn.ko.symbols kldxref: unknown metdata record 0 in file if_sn.ko.symbols kldxref: unknown metdata record 0 in file if_sn.ko.symbols kldxref: unknown metdata record 0 in file if_sn.ko.symbols kldxref: unknown metdata record 0 in file if_sn.ko.symbols kldxref: unknown metdata record 0 in file snp.ko.symbols kldxref: unknown metdata record 0 in file sound.ko.symbols kldxref: unknown metdata record 0 in file sound.ko.symbols kldxref: unknown metdata record 0 in file sound.ko.symbols kldxref: unknown metdata record 0 in file sound.ko.symbols kldxref: unknown metdata record 0 in file snd_ad1816.ko.symbols kldxref: unknown metdata record 0 in file snd_ad1816.ko.symbols kldxref: unknown metdata record 0 in file snd_ad1816.ko.symbols kldxref: unknown metdata record 0 in file snd_ad1816.ko.symbols kldxref: unknown metdata record 0 in file snd_als4000.ko.symbols kldxref: unknown metdata record 0 in file snd_als4000.ko.symbols kldxref: unknown metdata record 0 in file snd_als4000.ko.symbols kldxref: unknown metdata record 0 in file snd_atiixp.ko.symbols kldxref: unknown metdata record 0 in file snd_atiixp.ko.symbols kldxref: unknown metdata record 0 in file snd_atiixp.ko.symbols kldxref: unknown metdata record 0 in file snd_cmi.ko.symbols kldxref: unknown metdata record 0 in file snd_cmi.ko.symbols kldxref: unknown metdata record 0 in file snd_cmi.ko.symbols kldxref: unknown metdata record 0 in file snd_cmi.ko.symbols kldxref: unknown metdata record 0 in file snd_cs4281.ko.symbols kldxref: unknown metdata record 0 in file snd_cs4281.ko.symbols kldxref: unknown metdata record 0 in file snd_cs4281.ko.symbols kldxref: unknown metdata record 0 in file snd_csa.ko.symbols kldxref: unknown metdata record 0 in file snd_csa.ko.symbols kldxref: unknown metdata record 0 in file snd_csa.ko.symbols kldxref: unknown metdata record 0 in file snd_csa.ko.symbols kldxref: unknown metdata record 0 in file snd_csa.ko.symbols kldxref: unknown metdata record 0 in file snd_csa.ko.symbols kldxref: unknown metdata record 0 in file snd_csa.ko.symbols kldxref: unknown metdata record 0 in file snd_ds1.ko.symbols kldxref: unknown metdata record 0 in file snd_ds1.ko.symbols kldxref: unknown metdata record 0 in file snd_ds1.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10k1.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10k1.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10k1.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10k1.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10k1.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10k1.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_emu10kx.ko.symbols kldxref: unknown metdata record 0 in file snd_envy24.ko.symbols kldxref: unknown metdata record 0 in file snd_envy24.ko.symbols kldxref: unknown metdata record 0 in file snd_envy24.ko.symbols kldxref: unknown metdata record 0 in file snd_envy24.ko.symbols kldxref: unknown metdata record 0 in file snd_envy24ht.ko.symbols kldxref: unknown metdata record 0 in file snd_envy24ht.ko.symbols kldxref: unknown metdata record 0 in file snd_envy24ht.ko.symbols kldxref: unknown metdata record 0 in file snd_envy24ht.ko.symbols kldxref: unknown metdata record 0 in file snd_es137x.ko.symbols kldxref: unknown metdata record 0 in file snd_es137x.ko.symbols kldxref: unknown metdata record 0 in file snd_es137x.ko.symbols kldxref: unknown metdata record 0 in file snd_ess.ko.symbols kldxref: unknown metdata record 0 in file snd_ess.ko.symbols kldxref: unknown metdata record 0 in file snd_ess.ko.symbols kldxref: unknown metdata record 0 in file snd_ess.ko.symbols kldxref: unknown metdata record 0 in file snd_ess.ko.symbols kldxref: unknown metdata record 0 in file snd_ess.ko.symbols kldxref: unknown metdata record 0 in file snd_fm801.ko.symbols kldxref: unknown metdata record 0 in file snd_fm801.ko.symbols kldxref: unknown metdata record 0 in file snd_fm801.ko.symbols kldxref: unknown metdata record 0 in file snd_hda.ko.symbols kldxref: unknown metdata record 0 in file snd_hda.ko.symbols kldxref: unknown metdata record 0 in file snd_hda.ko.symbols kldxref: unknown metdata record 0 in file snd_ich.ko.symbols kldxref: unknown metdata record 0 in file snd_ich.ko.symbols kldxref: unknown metdata record 0 in file snd_ich.ko.symbols kldxref: unknown metdata record 0 in file snd_maestro.ko.symbols kldxref: unknown metdata record 0 in file snd_maestro.ko.symbols kldxref: unknown metdata record 0 in file snd_maestro.ko.symbols kldxref: unknown metdata record 0 in file snd_maestro3.ko.symbols kldxref: unknown metdata record 0 in file snd_maestro3.ko.symbols kldxref: unknown metdata record 0 in file snd_maestro3.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_mss.ko.symbols kldxref: unknown metdata record 0 in file snd_neomagic.ko.symbols kldxref: unknown metdata record 0 in file snd_neomagic.ko.symbols kldxref: unknown metdata record 0 in file snd_neomagic.ko.symbols kldxref: unknown metdata record 0 in file snd_sb16.ko.symbols kldxref: unknown metdata record 0 in file snd_sb16.ko.symbols kldxref: unknown metdata record 0 in file snd_sb16.ko.symbols kldxref: unknown metdata record 0 in file snd_sb16.ko.symbols kldxref: unknown metdata record 0 in file snd_sb8.ko.symbols kldxref: unknown metdata record 0 in file snd_sb8.ko.symbols kldxref: unknown metdata record 0 in file snd_sb8.ko.symbols kldxref: unknown metdata record 0 in file snd_sb8.ko.symbols kldxref: unknown metdata record 0 in file snd_sbc.ko.symbols kldxref: unknown metdata record 0 in file snd_sbc.ko.symbols kldxref: unknown metdata record 0 in file snd_sbc.ko.symbols kldxref: unknown metdata record 0 in file snd_sbc.ko.symbols kldxref: unknown metdata record 0 in file snd_solo.ko.symbols kldxref: unknown metdata record 0 in file snd_solo.ko.symbols kldxref: unknown metdata record 0 in file snd_solo.ko.symbols kldxref: unknown metdata record 0 in file snd_spicds.ko.symbols kldxref: unknown metdata record 0 in file snd_spicds.ko.symbols kldxref: unknown metdata record 0 in file snd_t4dwave.ko.symbols kldxref: unknown metdata record 0 in file snd_t4dwave.ko.symbols kldxref: unknown metdata record 0 in file snd_t4dwave.ko.symbols kldxref: unknown metdata record 0 in file snd_via8233.ko.symbols kldxref: unknown metdata record 0 in file snd_via8233.ko.symbols kldxref: unknown metdata record 0 in file snd_via8233.ko.symbols kldxref: unknown metdata record 0 in file snd_via82c686.ko.symbols kldxref: unknown metdata record 0 in file snd_via82c686.ko.symbols kldxref: unknown metdata record 0 in file snd_via82c686.ko.symbols kldxref: unknown metdata record 0 in file snd_vibes.ko.symbols kldxref: unknown metdata record 0 in file snd_vibes.ko.symbols kldxref: unknown metdata record 0 in file snd_vibes.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_driver.ko.symbols kldxref: unknown metdata record 0 in file snd_uaudio.ko.symbols kldxref: unknown metdata record 0 in file snd_uaudio.ko.symbols kldxref: unknown metdata record 0 in file snd_uaudio.ko.symbols kldxref: unknown metdata record 0 in file snd_uaudio.ko.symbols kldxref: unknown metdata record 0 in file snd_uaudio.ko.symbols kldxref: unknown metdata record 0 in file snd_uaudio.ko.symbols kldxref: unknown metdata record 0 in file snd_uaudio.ko.symbols kldxref: unknown metdata record 0 in file speaker.ko.symbols kldxref: unknown metdata record 0 in file speaker.ko.symbols kldxref: unknown metdata record 0 in file sppp.ko.symbols kldxref: unknown metdata record 0 in file sppp.ko.symbols kldxref: unknown metdata record 0 in file if_ste.ko.symbols kldxref: unknown metdata record 0 in file if_ste.ko.symbols kldxref: unknown metdata record 0 in file if_ste.ko.symbols kldxref: unknown metdata record 0 in file if_ste.ko.symbols kldxref: unknown metdata record 0 in file if_ste.ko.symbols kldxref: unknown metdata record 0 in file if_stge.ko.symbols kldxref: unknown metdata record 0 in file if_stge.ko.symbols kldxref: unknown metdata record 0 in file if_stge.ko.symbols kldxref: unknown metdata record 0 in file if_stge.ko.symbols kldxref: unknown metdata record 0 in file if_stge.ko.symbols kldxref: unknown metdata record 0 in file sym.ko.symbols kldxref: unknown metdata record 0 in file sym.ko.symbols kldxref: unknown metdata record 0 in file sym.ko.symbols kldxref: unknown metdata record 0 in file blank_saver.ko.symbols kldxref: unknown metdata record 0 in file blank_saver.ko.symbols kldxref: unknown metdata record 0 in file daemon_saver.ko.symbols kldxref: unknown metdata record 0 in file daemon_saver.ko.symbols kldxref: unknown metdata record 0 in file dragon_saver.ko.symbols kldxref: unknown metdata record 0 in file dragon_saver.ko.symbols kldxref: unknown metdata record 0 in file fade_saver.ko.symbols kldxref: unknown metdata record 0 in file fade_saver.ko.symbols kldxref: unknown metdata record 0 in file fire_saver.ko.symbols kldxref: unknown metdata record 0 in file fire_saver.ko.symbols kldxref: unknown metdata record 0 in file green_saver.ko.symbols kldxref: unknown metdata record 0 in file green_saver.ko.symbols kldxref: unknown metdata record 0 in file logo_saver.ko.symbols kldxref: unknown metdata record 0 in file logo_saver.ko.symbols kldxref: unknown metdata record 0 in file rain_saver.ko.symbols kldxref: unknown metdata record 0 in file rain_saver.ko.symbols kldxref: unknown metdata record 0 in file snake_saver.ko.symbols kldxref: unknown metdata record 0 in file snake_saver.ko.symbols kldxref: unknown metdata record 0 in file star_saver.ko.symbols kldxref: unknown metdata record 0 in file star_saver.ko.symbols kldxref: unknown metdata record 0 in file warp_saver.ko.symbols kldxref: unknown metdata record 0 in file warp_saver.ko.symbols kldxref: unknown metdata record 0 in file sysvmsg.ko.symbols kldxref: unknown metdata record 0 in file sysvmsg.ko.symbols kldxref: unknown metdata record 0 in file sysvmsg.ko.symbols kldxref: unknown metdata record 0 in file sysvmsg.ko.symbols kldxref: unknown metdata record 0 in file sysvmsg.ko.symbols kldxref: unknown metdata record 0 in file sysvmsg.ko.symbols kldxref: unknown metdata record 0 in file sysvmsg.ko.symbols kldxref: unknown metdata record 0 in file sysvsem.ko.symbols kldxref: unknown metdata record 0 in file sysvsem.ko.symbols kldxref: unknown metdata record 0 in file sysvsem.ko.symbols kldxref: unknown metdata record 0 in file sysvsem.ko.symbols kldxref: unknown metdata record 0 in file sysvsem.ko.symbols kldxref: unknown metdata record 0 in file sysvsem.ko.symbols kldxref: unknown metdata record 0 in file sysvshm.ko.symbols kldxref: unknown metdata record 0 in file sysvshm.ko.symbols kldxref: unknown metdata record 0 in file sysvshm.ko.symbols kldxref: unknown metdata record 0 in file sysvshm.ko.symbols kldxref: unknown metdata record 0 in file sysvshm.ko.symbols kldxref: unknown metdata record 0 in file sysvshm.ko.symbols kldxref: unknown metdata record 0 in file sysvshm.ko.symbols kldxref: unknown metdata record 0 in file if_ti.ko.symbols kldxref: unknown metdata record 0 in file if_ti.ko.symbols kldxref: unknown metdata record 0 in file if_ti.ko.symbols kldxref: unknown metdata record 0 in file if_tl.ko.symbols kldxref: unknown metdata record 0 in file if_tl.ko.symbols kldxref: unknown metdata record 0 in file if_tl.ko.symbols kldxref: unknown metdata record 0 in file if_tl.ko.symbols kldxref: unknown metdata record 0 in file if_tl.ko.symbols kldxref: unknown metdata record 0 in file tmpfs.ko.symbols kldxref: unknown metdata record 0 in file trm.ko.symbols kldxref: unknown metdata record 0 in file trm.ko.symbols kldxref: unknown metdata record 0 in file trm.ko.symbols kldxref: unknown metdata record 0 in file twa.ko.symbols kldxref: unknown metdata record 0 in file twa.ko.symbols kldxref: unknown metdata record 0 in file twa.ko.symbols kldxref: unknown metdata record 0 in file twe.ko.symbols kldxref: unknown metdata record 0 in file twe.ko.symbols kldxref: unknown metdata record 0 in file if_tx.ko.symbols kldxref: unknown metdata record 0 in file if_tx.ko.symbols kldxref: unknown metdata record 0 in file if_tx.ko.symbols kldxref: unknown metdata record 0 in file if_tx.ko.symbols kldxref: unknown metdata record 0 in file if_tx.ko.symbols kldxref: unknown metdata record 0 in file if_txp.ko.symbols kldxref: unknown metdata record 0 in file if_txp.ko.symbols kldxref: unknown metdata record 0 in file if_txp.ko.symbols kldxref: unknown metdata record 0 in file uark.ko.symbols kldxref: unknown metdata record 0 in file uark.ko.symbols kldxref: unknown metdata record 0 in file uark.ko.symbols kldxref: unknown metdata record 0 in file uart.ko.symbols kldxref: unknown metdata record 0 in file uart.ko.symbols kldxref: unknown metdata record 0 in file uart.ko.symbols kldxref: unknown metdata record 0 in file uart.ko.symbols kldxref: unknown metdata record 0 in file uart.ko.symbols kldxref: unknown metdata record 0 in file uart.ko.symbols kldxref: unknown metdata record 0 in file uart.ko.symbols kldxref: unknown metdata record 0 in file ubsa.ko.symbols kldxref: unknown metdata record 0 in file ubsa.ko.symbols kldxref: unknown metdata record 0 in file ubsa.ko.symbols kldxref: unknown metdata record 0 in file ubsa.ko.symbols kldxref: unknown metdata record 0 in file ubsec.ko.symbols kldxref: unknown metdata record 0 in file ubsec.ko.symbols kldxref: unknown metdata record 0 in file ubser.ko.symbols kldxref: unknown metdata record 0 in file ubser.ko.symbols kldxref: unknown metdata record 0 in file ucom.ko.symbols kldxref: unknown metdata record 0 in file ucom.ko.symbols kldxref: unknown metdata record 0 in file ucom.ko.symbols kldxref: unknown metdata record 0 in file ucycom.ko.symbols kldxref: unknown metdata record 0 in file ucycom.ko.symbols kldxref: unknown metdata record 0 in file ucycom.ko.symbols kldxref: unknown metdata record 0 in file if_udav.ko.symbols kldxref: unknown metdata record 0 in file if_udav.ko.symbols kldxref: unknown metdata record 0 in file if_udav.ko.symbols kldxref: unknown metdata record 0 in file if_udav.ko.symbols kldxref: unknown metdata record 0 in file if_udav.ko.symbols kldxref: unknown metdata record 0 in file udbp.ko.symbols kldxref: unknown metdata record 0 in file udbp.ko.symbols kldxref: unknown metdata record 0 in file udbp.ko.symbols kldxref: unknown metdata record 0 in file udf.ko.symbols kldxref: unknown metdata record 0 in file udf.ko.symbols kldxref: unknown metdata record 0 in file udf_iconv.ko.symbols kldxref: unknown metdata record 0 in file udf_iconv.ko.symbols kldxref: unknown metdata record 0 in file udf_iconv.ko.symbols kldxref: unknown metdata record 0 in file udf_iconv.ko.symbols kldxref: unknown metdata record 0 in file ufm.ko.symbols kldxref: unknown metdata record 0 in file ufm.ko.symbols kldxref: unknown metdata record 0 in file ufoma.ko.symbols kldxref: unknown metdata record 0 in file ufoma.ko.symbols kldxref: unknown metdata record 0 in file ufoma.ko.symbols kldxref: unknown metdata record 0 in file uftdi.ko.symbols kldxref: unknown metdata record 0 in file uftdi.ko.symbols kldxref: unknown metdata record 0 in file uftdi.ko.symbols kldxref: unknown metdata record 0 in file ugen.ko.symbols kldxref: unknown metdata record 0 in file ugen.ko.symbols kldxref: unknown metdata record 0 in file uhid.ko.symbols kldxref: unknown metdata record 0 in file uhid.ko.symbols kldxref: unknown metdata record 0 in file ukbd.ko.symbols kldxref: unknown metdata record 0 in file ukbd.ko.symbols kldxref: unknown metdata record 0 in file ulpt.ko.symbols kldxref: unknown metdata record 0 in file ulpt.ko.symbols kldxref: unknown metdata record 0 in file umass.ko.symbols kldxref: unknown metdata record 0 in file umass.ko.symbols kldxref: unknown metdata record 0 in file umass.ko.symbols kldxref: unknown metdata record 0 in file umct.ko.symbols kldxref: unknown metdata record 0 in file umct.ko.symbols kldxref: unknown metdata record 0 in file umct.ko.symbols kldxref: unknown metdata record 0 in file umct.ko.symbols kldxref: unknown metdata record 0 in file umodem.ko.symbols kldxref: unknown metdata record 0 in file umodem.ko.symbols kldxref: unknown metdata record 0 in file umodem.ko.symbols kldxref: unknown metdata record 0 in file umodem.ko.symbols kldxref: unknown metdata record 0 in file ums.ko.symbols kldxref: unknown metdata record 0 in file ums.ko.symbols kldxref: unknown metdata record 0 in file unionfs.ko.symbols kldxref: unknown metdata record 0 in file uplcom.ko.symbols kldxref: unknown metdata record 0 in file uplcom.ko.symbols kldxref: unknown metdata record 0 in file uplcom.ko.symbols kldxref: unknown metdata record 0 in file uplcom.ko.symbols kldxref: unknown metdata record 0 in file if_ural.ko.symbols kldxref: unknown metdata record 0 in file if_ural.ko.symbols kldxref: unknown metdata record 0 in file if_ural.ko.symbols kldxref: unknown metdata record 0 in file if_ural.ko.symbols kldxref: unknown metdata record 0 in file urio.ko.symbols kldxref: unknown metdata record 0 in file urio.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file usb.ko.symbols kldxref: unknown metdata record 0 in file uscanner.ko.symbols kldxref: unknown metdata record 0 in file uscanner.ko.symbols kldxref: unknown metdata record 0 in file utopia.ko.symbols kldxref: unknown metdata record 0 in file utopia.ko.symbols kldxref: unknown metdata record 0 in file uvisor.ko.symbols kldxref: unknown metdata record 0 in file uvisor.ko.symbols kldxref: unknown metdata record 0 in file uvisor.ko.symbols kldxref: unknown metdata record 0 in file uvisor.ko.symbols kldxref: unknown metdata record 0 in file uvscom.ko.symbols kldxref: unknown metdata record 0 in file uvscom.ko.symbols kldxref: unknown metdata record 0 in file uvscom.ko.symbols kldxref: unknown metdata record 0 in file uvscom.ko.symbols kldxref: unknown metdata record 0 in file if_vge.ko.symbols kldxref: unknown metdata record 0 in file if_vge.ko.symbols kldxref: unknown metdata record 0 in file if_vge.ko.symbols kldxref: unknown metdata record 0 in file if_vge.ko.symbols kldxref: unknown metdata record 0 in file if_vge.ko.symbols kldxref: unknown metdata record 0 in file if_vge.ko.symbols kldxref: unknown metdata record 0 in file vkbd.ko.symbols kldxref: unknown metdata record 0 in file vpo.ko.symbols kldxref: unknown metdata record 0 in file vpo.ko.symbols kldxref: unknown metdata record 0 in file vpo.ko.symbols kldxref: unknown metdata record 0 in file if_vr.ko.symbols kldxref: unknown metdata record 0 in file if_vr.ko.symbols kldxref: unknown metdata record 0 in file if_vr.ko.symbols kldxref: unknown metdata record 0 in file if_vr.ko.symbols kldxref: unknown metdata record 0 in file if_vr.ko.symbols kldxref: unknown metdata record 0 in file if_vx.ko.symbols kldxref: unknown metdata record 0 in file if_vx.ko.symbols kldxref: unknown metdata record 0 in file if_vx.ko.symbols kldxref: unknown metdata record 0 in file if_wb.ko.symbols kldxref: unknown metdata record 0 in file if_wb.ko.symbols kldxref: unknown metdata record 0 in file if_wb.ko.symbols kldxref: unknown metdata record 0 in file if_wb.ko.symbols kldxref: unknown metdata record 0 in file if_wb.ko.symbols kldxref: unknown metdata record 0 in file if_wi.ko.symbols kldxref: unknown metdata record 0 in file if_wi.ko.symbols kldxref: unknown metdata record 0 in file if_wi.ko.symbols kldxref: unknown metdata record 0 in file if_wi.ko.symbols kldxref: unknown metdata record 0 in file if_wi.ko.symbols kldxref: unknown metdata record 0 in file wlan.ko.symbols kldxref: unknown metdata record 0 in file wlan.ko.symbols kldxref: unknown metdata record 0 in file wlan.ko.symbols kldxref: unknown metdata record 0 in file wlan_scan_ap.ko.symbols kldxref: unknown metdata record 0 in file wlan_scan_ap.ko.symbols kldxref: unknown metdata record 0 in file wlan_scan_ap.ko.symbols kldxref: unknown metdata record 0 in file wlan_scan_sta.ko.symbols kldxref: unknown metdata record 0 in file wlan_scan_sta.ko.symbols kldxref: unknown metdata record 0 in file wlan_scan_sta.ko.symbols kldxref: unknown metdata record 0 in file wlan_acl.ko.symbols kldxref: unknown metdata record 0 in file wlan_acl.ko.symbols kldxref: unknown metdata record 0 in file wlan_acl.ko.symbols kldxref: unknown metdata record 0 in file wlan_amrr.ko.symbols kldxref: unknown metdata record 0 in file wlan_amrr.ko.symbols kldxref: unknown metdata record 0 in file wlan_amrr.ko.symbols kldxref: unknown metdata record 0 in file wlan_ccmp.ko.symbols kldxref: unknown metdata record 0 in file wlan_ccmp.ko.symbols kldxref: unknown metdata record 0 in file wlan_ccmp.ko.symbols kldxref: unknown metdata record 0 in file wlan_tkip.ko.symbols kldxref: unknown metdata record 0 in file wlan_tkip.ko.symbols kldxref: unknown metdata record 0 in file wlan_tkip.ko.symbols kldxref: unknown metdata record 0 in file wlan_wep.ko.symbols kldxref: unknown metdata record 0 in file wlan_wep.ko.symbols kldxref: unknown metdata record 0 in file wlan_wep.ko.symbols kldxref: unknown metdata record 0 in file wlan_xauth.ko.symbols kldxref: unknown metdata record 0 in file wlan_xauth.ko.symbols kldxref: unknown metdata record 0 in file wlan_xauth.ko.symbols kldxref: unknown metdata record 0 in file xfs.ko.symbols kldxref: unknown metdata record 0 in file if_xl.ko.symbols kldxref: unknown metdata record 0 in file if_xl.ko.symbols kldxref: unknown metdata record 0 in file if_xl.ko.symbols kldxref: unknown metdata record 0 in file if_xl.ko.symbols kldxref: unknown metdata record 0 in file if_xl.ko.symbols kldxref: unknown metdata record 0 in file if_xl.ko.symbols kldxref: unknown metdata record 0 in file zfs.ko.symbols kldxref: unknown metdata record 0 in file zfs.ko.symbols kldxref: unknown metdata record 0 in file zfs.ko.symbols kldxref: unknown metdata record 0 in file zfs.ko.symbols kldxref: unknown metdata record 0 in file zlib.ko.symbols kldxref: unknown metdata record 0 in file zlib.ko.symbols --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="6_2.boot" SMAP type=01 base=0000000000000000 len=000000000009d800 SMAP type=02 base=000000000009d800 len=0000000000002800 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000007fef0000 SMAP type=03 base=000000007fff0000 len=000000000000e000 SMAP type=04 base=000000007fffe000 len=0000000000002000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fec01000 len=0000000000001000 SMAP type=02 base=00000000fec02000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 Copyright (c) 1992-2007 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 6.2-STABLE #0: Thu Aug 23 17:21:30 CEST 2007 root@akagi.dial.sk:/usr/obj/usr/src/sys/SMP Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80ad9000. Calibrating clock(s) ... i8254 clock: 1191180 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1795513585 Hz CPU: Dual-Core AMD Opteron(tm) Processor 2210 (1795.51-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f12 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f HTT bit cleared - FreeBSD does not have licensing issues requiring it. Cores per package: 2 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 2147418112 (2047 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000099fff, 626688 bytes (153 pages) 0x0000000000bd6000 - 0x000000007c39ffff, 2071764992 bytes (505802 pages) avail memory = 2061611008 (1966 MB) INTR: Adding local APIC 0 as a target 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 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 3, Interrupt 16 at 0xfec01000 MADT: Found IO APIC ID 4, Interrupt 32 at 0xfec02000 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high MADT: Forcing active-low polarity and level trigger for SCI ioapic0: intpin 9 polarity: low ioapic0: intpin 9 trigger: level ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 ath_rate: version 1.2 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Aug 23 2007 17:21:17) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) ACPI timer: 1/2 0/3 0/2844 1/2 0/3 0/3 0/3 1/2 1/2 0/3 -> 4 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 9 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 5 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link27: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link28: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link29: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link30: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 9 11 12 14 15 pci_link31: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 Validation 0 10 N 0 10 After Disable 0 255 N 0 10 pci_link32: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 11 Validation 0 11 N 0 11 After Disable 0 255 N 0 11 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 pci_open(1): mode 1 addr port (0x0cf8) is 0x80017078 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 1 [class=060400] [hdr=01] is there (id=00361166) pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1166, dev=0x0036, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0205, revid=0x00 bus=0, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0214, revid=0x00 bus=0, slot=2, func=1 class=01-01-8a, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x1166, dev=0x0234, revid=0x00 bus=0, slot=2, func=2 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0223, revid=0x01 bus=0, slot=3, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff6b4000, size 12, enabled map[14]: type 4, range 32, base 0000e000, size 8, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 10 ioapic0: Changing trigger for pin 10 to level ioapic0: Changing polarity for pin 10 to low found-> vendor=0x1166, dev=0x0223, revid=0x01 bus=0, slot=3, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff6b5000, size 12, enabled map[14]: type 4, range 32, base 0000e400, size 8, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 10 found-> vendor=0x1166, dev=0x0223, revid=0x01 bus=0, slot=3, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base ff6b6000, size 12, enabled map[14]: type 4, range 32, base 0000e800, size 8, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 10 found-> vendor=0x8086, dev=0x1076, revid=0x05 bus=0, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff680000, size 17, enabled map[14]: type 1, range 32, base ff660000, size 17, enabled map[18]: type 4, range 32, base 0000dc00, size 6, enabled pcib0: matched entry for 0.4.INTA pcib0: slot 4 INTA hardwired to IRQ 24 found-> vendor=0x8086, dev=0x1076, revid=0x05 bus=0, slot=5, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff620000, size 17, enabled map[14]: type 1, range 32, base ff600000, size 17, enabled map[18]: type 4, range 32, base 0000d880, size 6, enabled pcib0: matched entry for 0.5.INTA pcib0: slot 5 INTA hardwired to IRQ 25 found-> vendor=0x18ca, dev=0x0020, revid=0x00 bus=0, slot=6, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base f8000000, size 26, enabled map[14]: type 1, range 32, base ff6c0000, size 18, enabled map[18]: type 4, range 32, base 0000ec00, size 7, enabled found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 2 pcib1: I/O decode 0xb000-0xcfff pcib1: memory decode 0xff300000-0xff3fffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1166, dev=0x0104, revid=0xc0 bus=1, slot=13, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0016, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x02 (500 ns) found-> vendor=0x1166, dev=0x024a, revid=0x00 bus=1, slot=14, func=0 class=01-04-05, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 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 4, range 32, base 0000c080, size 3, enabled pcib1: requested I/O range 0xc080-0xc087: in range map[14]: type 4, range 32, base 0000c000, size 2, enabled pcib1: requested I/O range 0xc000-0xc003: in range map[18]: type 4, range 32, base 0000bc00, size 3, enabled pcib1: requested I/O range 0xbc00-0xbc07: in range map[1c]: type 4, range 32, base 0000b880, size 2, enabled pcib1: requested I/O range 0xb880-0xb883: in range map[20]: type 4, range 32, base 0000b800, size 5, enabled pcib1: requested I/O range 0xb800-0xb81f: in range map[24]: type 1, range 32, base ff3fe000, size 13, enabled pcib1: requested memory range 0xff3fe000-0xff3fffff: good pcib1: matched entry for 1.14.INTA pcib1: slot 14 INTA hardwired to IRQ 11 ioapic0: Changing trigger for pin 11 to level ioapic0: Changing polarity for pin 11 to low pcib2: at device 13.0 on pci1 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff pci2: on pcib2 pci2: physical bus=2 atapci0: port 0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb81f mem 0xff3fe000-0xff3fffff irq 11 at device 14.0 on pci1 atapci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 ioapic0: routing intpin 11 (ISA IRQ 11) to vector 49 atapci0: [MPSAFE] atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xff3fe000 ata2: on atapci0 ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata3: on atapci0 ata3: reset tp1 mask=01 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] ata4: on atapci0 ata4: reset tp1 mask=01 ostat0=50 ostat1=00 ata4: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata4: [MPSAFE] ata5: on atapci0 ata5: reset tp1 mask=01 ostat0=7f ostat1=00 ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: reset tp2 stat0=ff stat1=00 devices=0x0 ata5: [MPSAFE] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 2.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=02 ostat0=ff ostat1=50 ata0: stat1=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0x8 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 50 ata0: [MPSAFE] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: 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 51 ata1: [MPSAFE] isab0: at device 2.2 on pci0 isa0: on isab0 ohci0: port 0xe000-0xe0ff mem 0xff6b4000-0xff6b4fff irq 10 at device 3.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6b4000 ohci0: (New OHCI DeviceId=0x02231166) ioapic0: routing intpin 10 (ISA IRQ 10) to vector 52 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1: port 0xe400-0xe4ff mem 0xff6b5000-0xff6b5fff irq 10 at device 3.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6b5000 ohci1: (New OHCI DeviceId=0x02231166) ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: port 0xe800-0xe8ff mem 0xff6b6000-0xff6b6fff irq 10 at device 3.2 on pci0 ehci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6b6000 ehci0: (New EHCI DeviceId=0x02231166) ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: (0x1166) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered em0: port 0xdc00-0xdc3f mem 0xff680000-0xff69ffff,0xff660000-0xff67ffff irq 24 at device 4.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xff680000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdc00 em0: bpf attached em0: Ethernet address: 00:e0:81:47:1d:5e ioapic1: routing intpin 8 (PCI IRQ 24) to vector 53 em0: [MPSAFE] em1: port 0xd880-0xd8bf mem 0xff620000-0xff63ffff,0xff600000-0xff61ffff irq 25 at device 5.0 on pci0 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xff620000 em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0xd880 em1: bpf attached em1: Ethernet address: 00:e0:81:47:1d:5f ioapic1: routing intpin 9 (PCI IRQ 25) to vector 54 em1: [MPSAFE] pci0: at device 6.0 (no driver attached) acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: routing intpin 4 (ISA IRQ 4) to vector 55 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 56 ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed ex_isa_identify() sio: sio0 already exists; skipping it sio: sio1 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 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc9fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x1f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: 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 132652 -> 100000 linprocfs registered procfs registered lapic: Divisor 2, Frequency 99750767 hz Timecounter "TSC" frequency 1795513em0: Link is up 1000 Mbps Full Duplex 585 Hz quality -100 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached rr232x: no controller detected. em0: link state changed to UP ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on HT1000 chip acd0: setting UDMA33 on HT1000 chip acd0: CDROM drive at ata0 as slave acd0: read 4134KB/s (4134KB/s), 256KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 238475MB at ata2-master SATA150 ad4: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 238475MB at ata3-master SATA150 ad6: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 238475MB at ata4-master SATA150 ad8: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad8 ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 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 3 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 10 to local APIC 0 ioapic0: Assigning ISA IRQ 11 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 1 ioapic1: Assigning PCI IRQ 24 to local APIC 0 ioapic1: Assigning PCI IRQ 25 to local APIC 1 Trying to mount root from ufs:/dev/ad4s1a start_init: trying /sbin/init Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/ad4s1b as swap device Starting file system checks: /dev/ad4s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad4s1a: clean, 2428558 free (39590 frags, 298621 blocks, 1.0% fragmentation) Mounting local file systems:. Setting hostname: akagi.dial.sk. net.inet6.ip6.auto_linklocal: 1 -> 0 em0: Link is Down em0: link state changed to DOWN em0: no link .....em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP got link DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 172.16.52.1 bound to 172.16.52.35 -- renewal in 21600 seconds. lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843 mtu 1500 options=b inet 172.16.52.35 netmask 0xffffff00 broadcast 172.16.52.255 ether 00:e0:81:47:1d:5e media: Ethernet autoselect (1000baseTX ) status: active Additional routing options:. Starting devd. hw.acpi.cpu.cx_lowest: C1 -> C1 Additional TCP options:. Mounting NFS file systems:. Creating and/or trimming log files:. Starting syslogd. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 32-bit compatibility ldconfig path: /usr/lib32 Initial amd64 initialization:. Additional ABI support:. Clearing /tmp (X related). Starting usbd. Starting local daemons:. Updating motd. Mounting late file systems:. Configuring syscons: blanktime. Starting sshd. Starting cron. Local package initialization:. Starting background file system checks in 60 seconds. Tue Aug 28 13:25:45 CEST 2007 FreeBSD/amd64 (akagi.dial.sk) (ttyd0) login: Aug 28 13:26:07 akagi su: kockac to root on /dev/ttyp1 --VS++wcV0S1rZb1Fb-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 13:05:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E492C16A41A for ; Tue, 28 Aug 2007 13:05:56 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id B6CCA13C45A for ; Tue, 28 Aug 2007 13:05:56 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l7SD5ofF086476; Tue, 28 Aug 2007 08:05:51 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46D41DAE.5010501@freebsd.org> Date: Tue, 28 Aug 2007 08:05:50 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ivan Voras References: <200708261948.05750.qpadla@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-current@freebsd.org Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 13:05:57 -0000 Ivan Voras wrote: > Nikolay Pavlov wrote: > >> Is this similar as this one? >> http://docs.freebsd.org/cgi/mid.cgi?200708202327.03951.qpadla > > No: > - it happens with and without gjournal > - it happens during "regular" system usage during IO intensive periods > > It looks like a UFS corruption: as I said, I was able to provoke it > regularly by doing heavy IO on a clean newfs-ed file system (I can't > after an update to a newer kernel+world, now it seems to happen randomly). > > By any chance, are there some oddly named directories? I found that UFS will panic with a ufs_dirbad if there are some strange chars in the dir name. My directories were copied with rsync, from one UFS partition to another. It could be the way rsync translated it or the way UFS sent it to rsync during read, I'm not certain. I still have the bad file system, corresponding core file, etc. I even ran fsdb on the fs to track down the offending directory, and I think I found it. Of course, I could rename it in fsdb, but that would remove my test case. I stopped debugging it when I got busy, but if there is an interested person willing to help be with some debug ideas, I can go back into it. Eric From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 13:34:15 2007 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 C596116A417 for ; Tue, 28 Aug 2007 13:34:15 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA0613C474 for ; Tue, 28 Aug 2007 13:34:15 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l7SDWANx081454; Tue, 28 Aug 2007 06:32:11 -0700 (PDT) Date: Tue, 28 Aug 2007 21:32:05 +0800 Message-ID: From: gnn@freebsd.org To: Pawel Worach In-Reply-To: <46D2EB88.7020905@gmail.com> References: <46D2EB88.7020905@gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org Subject: Re: IPSec panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 13:34:15 -0000 At Mon, 27 Aug 2007 17:19:36 +0200, Pawel Worach wrote: > > Hi, > > While testing IPSec I got this panic on two different -CURRENT systems. > I think they happened when racoon was updating the SAD. kernel.debug and > vmcore is still available if more info needed. > Given the backtraces you showed I didnt' see any IPsec related code being run. Did I miss something? Best, George From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 13:34:40 2007 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 34C8016A41A for ; Tue, 28 Aug 2007 13:34:40 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 0C11F13C474 for ; Tue, 28 Aug 2007 13:34:39 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l7SDXUHm081837; Tue, 28 Aug 2007 06:33:31 -0700 (PDT) Date: Tue, 28 Aug 2007 21:33:25 +0800 Message-ID: From: gnn@freebsd.org To: Pawel Worach In-Reply-To: <46D2EC26.3020005@gmail.com> References: <46D2EC26.3020005@gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org Subject: Re: IPSec/IPv6 panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 13:34:40 -0000 At Mon, 27 Aug 2007 17:22:14 +0200, Pawel Worach wrote: > > Hi, > > While testing IPSec and IPv6 I got this panic when sending ICMPv6 echo > requests to the peer. kernel.debug and vmcore available if more info is > needed. > That looks like an infinite loop in the code. How can I access the kernel debug and vmcore? Best, George From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 14:03:11 2007 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 8630316A419 for ; Tue, 28 Aug 2007 14:03:11 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.freebsd.org (Postfix) with ESMTP id 4548C13C46B for ; Tue, 28 Aug 2007 14:03:11 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1709271wxd for ; Tue, 28 Aug 2007 07:03:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=jv8jG/r1vQlszYYTkwxnyRRfPAkjAVhDLqTizcsUT8Cy/ixG00qIG3EgqNSv4N5XO18BX3q17ZWmzBzZNDMC8zpiuuTcWC/FZ7CyTOGokpwUdGpPzIttehjmuUyYw4pHDAdaE/pKr6vMAq0pYtRzGkHR6Dx8Q07nz/nKKvjWjoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NmjjVWwoP3g/zLP11Se24Zp8KEk5vzvoOrOuPFy3an/Km22Vkri3rKqh7spMEbMgBHs1ozUmoXcEhnv6I3FdIBk68n4UvDi6OWtQXnW+TGYCqLLdxskGf3yVxiDWX4GbvVIcxMniAoim/FqiDqvz9igevUvC8KxJcvLN/2dZ3fE= Received: by 10.90.68.15 with SMTP id q15mr647388aga.1188309789800; Tue, 28 Aug 2007 07:03:09 -0700 (PDT) Received: by 10.90.86.16 with HTTP; Tue, 28 Aug 2007 07:03:09 -0700 (PDT) Message-ID: Date: Tue, 28 Aug 2007 16:03:09 +0200 From: "Pawel Worach" To: "gnn@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: <46D2EB88.7020905@gmail.com> Cc: current@freebsd.org Subject: Re: IPSec panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 14:03:11 -0000 On 8/28/07, gnn@freebsd.org wrote: > At Mon, 27 Aug 2007 17:19:36 +0200, > Pawel Worach wrote: > > > > Hi, > > > > While testing IPSec I got this panic on two different -CURRENT systems. > > I think they happened when racoon was updating the SAD. kernel.debug and > > vmcore is still available if more info needed. > > > > Given the backtraces you showed I didnt' see any IPsec related code > being run. Did I miss something? > Come to think of it.. this case was that I had a ssh session to the peer when there was no policy loaded and the peer paniced when setkey -f ipsec.conf was executed so the existing connection now suddenly would require IPSec. Am I making any sense at all ? -- Pawel From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 14:34:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAD3716A417 for ; Tue, 28 Aug 2007 14:34:14 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0B313C45A for ; Tue, 28 Aug 2007 14:34:13 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so184933ugf for ; Tue, 28 Aug 2007 07:34:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=tv9e0R6bWrJenmtQNKgyfTUVi8i7vcYgIWvdu3nbzVZshzYt4riLkOa+TP746ZDU4VyY0QdjSp9sl6sWVJ5luBSWVDGihCVvKcLgdEq4Eg/8025Hj9heepViRgHuxO4dJUfj2lMDUqOZsfZVDrTzAcTvlWm0mOOLSR7nwekNpvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=k14d0Jdckne9g8Yhy6oT2swhY7pcUMepqMNwe/tex/iSnLePajmJOLkR9w5l02XD4Qg9M4y5Doebpl6x6VD7nFMSdOAAdOof332suXKeXLuCyHlm28XFuqZ8QORx4G7UXPMiMSvgxfMXMuIFpgzHQxeZZ0vN3Z4yQzUj/zll4jM= Received: by 10.142.201.3 with SMTP id y3mr573979wff.1188311649064; Tue, 28 Aug 2007 07:34:09 -0700 (PDT) Received: by 10.143.10.17 with HTTP; Tue, 28 Aug 2007 07:34:09 -0700 (PDT) Message-ID: <26ddd1750708280734p432d887ex3bf7ed7892e78a3f@mail.gmail.com> Date: Tue, 28 Aug 2007 10:34:09 -0400 From: "Maxim Khitrov" To: "Scot Hetzel" In-Reply-To: <790a9fff0708272354q31afca4fx1e787f9592a6a4e0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0708272354q31afca4fx1e787f9592a6a4e0@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Setting CPUTYPE=native, fails to set MACHINE_CPU correctly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 14:34:14 -0000 On 8/28/07, Scot Hetzel wrote: > Gcc 4.2 has a new cpu_type (native) for x86 and amd64 systems. This > cpu_type is to allow gcc to automatically detect the processor type > that gcc is running on. > > The problem is that setting CPUTYPE?=native in either src.conf or > make.conf will cause MACHINE_CPU to be set to the wrong value for the > native cpu. There is actually another problem with using CPUTYPE=native, as I found out yesterday. Certain ports may fail to build with it. For example, I was trying to build openoffice.org-2 and it was failing at gcc-ooo with the message "cannot compute suffix of object files." Since it was using the older compiler version, -march=native caused it to fail. There should probably be an additional note somewhere telling people to be careful with this setting. - Max From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 14:39:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED6BC16A419 for ; Tue, 28 Aug 2007 14:39: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 7C6DF13C469 for ; Tue, 28 Aug 2007 14:39:01 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IQ2DX-0007S3-UO for freebsd-current@freebsd.org; Tue, 28 Aug 2007 16:38:55 +0200 Received: from 84-51-160-73.pambow882.adsl.metronet.co.uk ([84.51.160.73]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 28 Aug 2007 16:38:55 +0200 Received: from robin-lists by 84-51-160-73.pambow882.adsl.metronet.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 28 Aug 2007 16:38:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Robin Bowes Date: Tue, 28 Aug 2007 15:38:45 +0100 Lines: 56 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 84-51-160-73.pambow882.adsl.metronet.co.uk User-Agent: Thunderbird 2.0.0.6 (X11/20070811) In-Reply-To: X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: BTX halted with 7.0-CURRENT-2007-06 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 14:39:02 -0000 Bump - anyone got any ideas on this? R. Robin Bowes wrote: > Hi, > > I'm trying to install 7.0-CURRENT on an Epox EP-D3VA motherboard with > dual PIII processors (1Ghz) and 1.5GB RAM > > The CDROM is a Plextor installed as Primary on IDE Channel 0 > > There are two Promise SATA150 TX4 controllers each with three 250GB > Maxtor SATA drives (6 drives in total). > > There is also a Highpoint HPT-370 controller on the mother board, which > cna't be disabled but is not being used. > > I am already running Fedora Core 6 and Windows XP from different > partitions on the first drive. > > When I boot from the FreeBSD 7.0-CURRENT disk (cd 1) I get this error: > > Boot from CD : CD Loader 1.2 > > Building the boot loader arguments > Looking up /BOOT/LOADER... Found > Relocating the loader and the BTX > Starting the BTX loader > > BTX Loader 1.00 BTX Version is 1.01 > Consoles: internal video/keyboard > BIOS CD is cd0 > > int=0000000d err=00004890 efl=00010046 eip=00009257 > eax=00000601 ebx=00000700 ecx=00000000 edf=0000184f > esi=0000000c edi=00000000 edp=00000000 esp=000017dc > cs=0008 ds=0010 es=0010 fs=0000 gs=0000 ss=0010 > cs:eip=07 1f 0f a1 0f a9 cf fc-6a 10 1f 60 89 e5 0f b7 > 7d 2c c1 e7 04 0b 75 28-01 fe 31 c9 b1 02 31 c0 > ss:eip=92 40 00 00 b0 48 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 > > BTX halted > > Can anyone help debug this? > > Thanks, > > R. > > _______________________________________________ > 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 Aug 28 14:39:14 2007 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 CE58316A419 for ; Tue, 28 Aug 2007 14:39:14 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 21BE013C45B for ; Tue, 28 Aug 2007 14:39:13 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l7SE3gGx002664; Tue, 28 Aug 2007 18:03:43 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l7SE3WIf002656; Tue, 28 Aug 2007 18:03:32 +0400 (MSD) (envelope-from yar) Date: Tue, 28 Aug 2007 18:03:32 +0400 From: Yar Tikhiy To: Daniel Eischen Message-ID: <20070828140331.GA598@comp.chem.msu.su> References: <20070824.172212.74696955.imp@bsdimp.com> <20070825053302.GG99474@comp.chem.msu.su> <20070825.093925.43008968.imp@bsdimp.com> <1188071752.1853.44.camel@neo.cse.buffalo.edu> <20070826073535.GD21352@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: Ken Smith , current@freebsd.org, "M. Warner Losh" Subject: Re: Symbol versioning conventions (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 14:39:14 -0000 On Sun, Aug 26, 2007 at 12:48:41PM -0400, Daniel Eischen wrote: > > Here it is on -current, feel free to redirect it to arch. > > I updated my notes on symbol versioning - see "Version naming conventions" > on downwards at: > > http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt > > Feel free to cut&paste anything from it in replies. It seems that we've failed to divert the main discussion from the cvs lists, so I'll comment on other sides of the symbol versioning issue. First, you wrote that a symbol having multiple versions needs to be listed in the symbol map file under each of its versions. I'm afraid that the GNU ld(1) documentation doesn't suggest that. I believe that it is correct to list each symbol in the symbol map only once, under its default version. Second, we need to decide how to handle SV consistently at source tree level. In a trivial case, cut'n'paste or a stub function will do, but in the more complex case of massive changes it can be hard to reproduce the old ABI using stubs, e.g., because the new implementation lost old bugs. In this case, CVS history should be preserved for the old version at file level. A uniform approach can be to repocopy the respective file(s) and add the version to their name(s), e.g.: fts.c -> fts_fbsd_1_0.c. Does it sound reasonable? -- Yar From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 14:39:45 2007 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 6DAAC16A418; Tue, 28 Aug 2007 14:39:45 +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 9FEC613C474; Tue, 28 Aug 2007 14:39:43 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 8FAE61738A; Tue, 28 Aug 2007 08:59:29 -0500 (CDT) Date: Tue, 28 Aug 2007 08:59:29 -0500 From: "Christian S.J. Peron" To: "Bruce M. Simpson" Message-ID: <20070828135929.GA2305@sub.vaned.net> References: <20070828040026.GB42201@heff.fud.org.nz> <46D3C9F3.2010802@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D3C9F3.2010802@FreeBSD.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Current , Andrew Thompson Subject: Re: multicast packets from bpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 14:39:45 -0000 On Tue, Aug 28, 2007 at 08:08:35AM +0100, Bruce M. Simpson wrote: [..] > > I favour the first approach, however, it may make more sense to put the > logic into bpf_movein() as it already builds a sockaddr based on the header > data provided to bpf during a write. > > For the first patch: I previously fixed tapwrite() to check injected frames > in the same way, as this was causing a problem with my own use of > if_bridge. There is no way that I see for bpf to be able to tell if a frame > is link-layer multicast or not, and checking at that layer does introduce a > little pollution. Ethernet is the most common case so it could be argued > that's OK, as we have ethernet-specific fields in struct mbuf now. Your > change is the parallel change in the bpfwrite path to what I have in the > tapwrite path. > I think that tap(4) is a bit different since the only kind of frames it handles are Ethernet. This is not the case for bpf(4). I wonder if it makes sense to add this check into ether_output()? IIRC bpf will call the network interface's output routine, in the Ethernet/bridge case it should be ether_output(). Thoughts? -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 14:55:00 2007 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 9234A16A468 for ; Tue, 28 Aug 2007 14:55:00 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB2713C458 for ; Tue, 28 Aug 2007 14:54:59 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so2367068fka for ; Tue, 28 Aug 2007 07:54:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=io+AVJOUKHGlW632NDxOyScVf+9iVXsWV/z3DO5W0mHYpKIEWGKcu5Jm7KeUpCVCd0NgxkGbD+nIss+Vbz5hVwHhi/bKeH+kyGIk099IhIP3wotk264VPA0lPUDlk9EPl/lhSFap954cLOP4QULXb7ZnEnAJrVHDlTT5v4G0E30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=VT+dH7sx40yv+6IM24SZnURU3SUEEq6dr5moM9KgTbLXce+KqXZ2O2YwgjmGUTe1ZGEx7anbnloszhL6MmMdq1yHwmvVoMRPe/d99Akqp5rDStk7Jcusrp4ffhDkNRR7qIkHkFLbPb1bqGmp7PEXA3tykBVEFk7uMh0PwS54gJM= Received: by 10.82.183.19 with SMTP id g19mr16784515buf.1188311245304; Tue, 28 Aug 2007 07:27:25 -0700 (PDT) Received: from ?192.168.2.2? ( [87.166.80.121]) by mx.google.com with ESMTPS id g12sm9213032nfb.2007.08.28.07.27.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Aug 2007 07:27:23 -0700 (PDT) From: Pascal Hofstee To: current@FreeBSD.org Content-Type: text/plain Date: Tue, 28 Aug 2007 16:27:22 +0200 Message-Id: <1188311242.1052.11.camel@trinity> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 14:55:00 -0000 Hi, For the last couple of weeks now I've occasionally been getting kernel panics through ZFS (usually during heavy disk-i/o on the ZFS volume) usually at the time this happened i was busy in X and therefore unable to get to the console and force a kernel-dump. Today though it seems i was lucky and actually managed to catch a kernel panic while in console mode. Below is the actual panic message, i tried looking at the actual backtrace but all the interesting frames are purely addresses without any symbol information. I'll assume this is because of zfs and friends being loaded as KLDs. Any information on how to provide a proper backtrace including all symbols involved would be appreciated. uname -a: FreeBSD trinity.zion 7.0-CURRENT FreeBSD 7.0-CURRENT #29: Sun Aug 26 20:19:12 CEST 2007 pascal@trinity.zion:/usr/obj/usr/src/sys/TRINITY i386 panic: ZFS: I/O failure (write on off 0: zio 0xc66a9cf0 [L0 ZFS plain file] 20000L/20000P DVA[0]=<0:a126e0000:20000> fletcher2 uncompressed LE contiguous birth=7004722 fill=1 cksum=2dc0c354bd8ccc27:85745b74c1352a7f:72188a8646f7f624:28d89f21264ed4f2): e^ cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 13h56m31s Physical memory: 2027 MB Dumping 292 MB: 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 15:01:13 2007 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 0CE1B16A468 for ; Tue, 28 Aug 2007 15:01:13 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 4162913C457 for ; Tue, 28 Aug 2007 15:01:11 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1493101nfb for ; Tue, 28 Aug 2007 08:01:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=Xiac0m78XIG95itz4vKeozFXjqU6BuFx1E8Ei1dodR14IXZ1av/DMzv6cuygdigc76j3HEx0RFhqLqXUFfcNsZS3CMS3ynCGDAU372N8bq8iT3hLRCFkghe/5Eqolcyjzv3cxjd5hcdIKcq3EM1NAL1iuOrOYdr7Do9Fx7Qkbk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=h7/0S2dGicAX9tVM+A/obwqrjOw4VG9w6Vstxg6s7HQRI/n54Z9Yw7DvRiqmO5PjhxrPGifGeB/HpHrm8XP9I2TBXllVhyBQt/7vGlOcLhn+QHnVhO7N2qeD9SVnn/vwhTGtNoty4HRETvCRjP/oG+275zK+Wxt+S9P7FQtTZdY= Received: by 10.78.132.2 with SMTP id f2mr4957262hud.1188313269912; Tue, 28 Aug 2007 08:01:09 -0700 (PDT) Received: from ?192.168.2.2? ( [87.166.80.121]) by mx.google.com with ESMTPS id u7sm2840459uge.2007.08.28.08.01.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Aug 2007 08:01:09 -0700 (PDT) From: Pascal Hofstee To: current@FreeBSD.org In-Reply-To: <1188311242.1052.11.camel@trinity> References: <1188311242.1052.11.camel@trinity> Content-Type: text/plain Date: Tue, 28 Aug 2007 17:01:07 +0200 Message-Id: <1188313267.1052.14.camel@trinity> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 15:01:13 -0000 On Tue, 2007-08-28 at 16:27 +0200, Pascal Hofstee wrote: > uname -a: > FreeBSD trinity.zion 7.0-CURRENT FreeBSD 7.0-CURRENT #29: Sun Aug 26 > 20:19:12 CEST 2007 pascal@trinity.zion:/usr/obj/usr/src/sys/TRINITY > i386 > > panic: ZFS: I/O failure (write on off 0: zio 0xc66a9cf0 [L0 > ZFS plain file] 20000L/20000P DVA[0]=<0:a126e0000:20000> fletcher2 > uncompressed LE contiguous birth=7004722 fill=1 > cksum=2dc0c354bd8ccc27:85745b74c1352a7f:72188a8646f7f624:28d89f21264ed4f2): e^ > cpuid = 0 > KDB: enter: panic > panic: from debugger > cpuid = 0 > Uptime: 13h56m31s > Physical memory: 2027 MB > Dumping 292 MB: 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 > 37 21 5 ok ... reading a bit further in the developer's handbook i was able to figure out how to make kgdb properly load the zfs.ko.symbol file and managed to get an actual backtrace. If additional information is required let me know and i'll see what i can do. (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc075e377 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc075e66e in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0495f67 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:433 #4 0xc04966c5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xc0498105 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xc07868b5 in kdb_trap (type=3, code=0, tf=0xe88deb4c) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xc0a25ecb in trap (frame=0xe88deb4c) at /usr/src/sys/i386/i386/trap.c:621 #8 0xc0a0b60b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #9 0xc0786a32 in kdb_enter (msg=0xc0ab4433 "panic") at cpufunc.h:60 #10 0xc075e654 in panic (fmt=0xc5ec1f94 "ZFS: %s (%s on %s off %llx: zio %p %s): error %d") at /usr/src/sys/kern/kern_shutdown.c:547 #11 0xc5ea124c in zfs_freebsd_setattr (ap=0xc66a9cf0) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2325 #12 0xc5ea1e43 in zvol_worker (arg=0xc66a9cf0) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zvol.c:322 #13 0xc5ea259b in zvol_create_cb (os=0x0, arg=0xe88dece0, tx=0xc66a9cf0) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zvol.c:408 #14 0xc5e48c40 in dmu_sendbackup (tosnap=0xc5ee50cc, fromsnap=0xe88ded38, fp=0x9) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:269 #15 0xc073de77 in fork_exit (callout=0xc5e48b00 , arg=0xc5ee50cc, frame=0xe88ded38) at /usr/src/sys/kern/kern_fork.c:797 #16 0xc0a0b680 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 15:01:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F07316A418 for ; Tue, 28 Aug 2007 15:01:24 +0000 (UTC) (envelope-from jovial_man@yahoo.com) Received: from web35214.mail.mud.yahoo.com (web35214.mail.mud.yahoo.com [66.163.179.93]) by mx1.freebsd.org (Postfix) with SMTP id BFA1E13C474 for ; Tue, 28 Aug 2007 15:01:23 +0000 (UTC) (envelope-from jovial_man@yahoo.com) Received: (qmail 2573 invoked by uid 60001); 28 Aug 2007 14:34:42 -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=BDeMlULyxb3Wy3y/bzAJhuOH8+jlolM8DKEEDDCcOmMmIpTY79/d9FrZs1fcd3ivVAOd7HGXKzRZ+VHnRTQGtS19jDmPY514/Ta9aE3rCLyM+iKTH0Vhg+ltfU8S3QvfcH9/JFQKJaGelYzXLigmO9nNMRhVqnZHCZ6D2NNxkSs=; X-YMail-OSG: Q5OTdvQVM1nPiFiF94Z99ncLVvEuVM0Xj2EikLCdu9GGfmkRCZgzMtiMrfvQpPl_kgl92TBtgpLdcXGUo1680p9ENvOiA.E2QIsCp76lI7muvLQVuZ8awdf68FBJWA-- Received: from [131.111.135.249] by web35214.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2007 07:34:42 PDT Date: Tue, 28 Aug 2007 07:34:42 -0700 (PDT) From: Shane Helms To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <601594.86521.qm@web35214.mail.mud.yahoo.com> Subject: Can I use FreeBSD-current?? (sony vaio hardware) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 15:01:24 -0000 Hi, I installed FreeBSD-6.2R several days ago soon to realize that my sound card is not supported :-( Now, I'd like to install FreeBSD-Current, but I thought I'd send a quick email for hardware checking before I jump into snapshots. Sadly, very little information about FreeBSD-7 can be found on the net. My hardware is Sony Vaio FJ170/B (FJ1S/W) laptop. Please let me know if you have experience with any of the following: 1. CPU frequency scaling for Intel(R) Pentium(R) M processor 1.73GHz (centrino). 2. Hibernate / Standby support for Intel Corporation Mobile 915GM chipset 3. Wireless with an Intel Corporation PRO/Wireless 2200BG card 4. Sony ACPI support for screen brightness adjustment Thanks, Shane ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 15:30:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49F4216A41A for ; Tue, 28 Aug 2007 15:30:28 +0000 (UTC) (envelope-from oleg@admin.opentransfer.com) Received: from admin.opentransfer.com (admin.opentransfer.com [71.18.255.169]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7D113C48E for ; Tue, 28 Aug 2007 15:30:27 +0000 (UTC) (envelope-from oleg@admin.opentransfer.com) Received: from admin.opentransfer.com (admin.opentransfer.com [127.0.0.1]) by admin.opentransfer.com (8.13.8/8.13.8) with ESMTP id l7SEaQgJ004165 for ; Tue, 28 Aug 2007 09:36:26 -0500 Received: (from oleg@localhost) by admin.opentransfer.com (8.13.8/8.13.8/Submit) id l7SEaQ8m004164 for freebsd-current@freebsd.org; Tue, 28 Aug 2007 09:36:26 -0500 Date: Tue, 28 Aug 2007 09:36:26 -0500 From: Oleg Nauman To: "freebsd-current@freebsd.org" Message-ID: <20070828143626.GA32611@admin.opentransfer.com> Mail-Followup-To: "freebsd-current@freebsd.org" References: <46D25242.10504@micom.mng.net> <20070827231419.H30469@fledge.watson.org> <20070828044133.GR2332@deviant.kiev.zoral.com.ua> <46D3A90D.8050703@micom.mng.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46D3A90D.8050703@micom.mng.net> User-Agent: Mutt/1.4.2.1i Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 15:30:28 -0000 On Tue, Aug 28, 2007 at 12:48:13PM +0800, Ganbold wrote: > Kostik Belousov wrote: > >On Mon, Aug 27, 2007 at 11:14:58PM +0100, Robert Watson wrote: > > > >>On Mon, 27 Aug 2007, Ganbold wrote: > >> > >> > >>>I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS > >>>enabled kernel. > >>> > >>Try the same thing again without INVARIANTS and WITNESS, both of which > >>can consume a lot of CPU in kernel on a very active system, especially if > >>lots of vnodes are being allocated and freed. Especially WITNESS. > >> > > > >It does happens on the kernels without debug options, in particular, > >WITNESS and INVARIANTS. > > > >It happens when a lot of short-lived processes are rapidly created. > >Compilation is a good example of such workload; running configure script > >is even better. > > > > What would be a solution to this kind of problems? From my point of view it exhibits some issues with standard SCHED_4BSD scheduler in the 7.0 (my laptop is mostly unusable during 'make buildworld' for example - keyboard exhibits lost event sometimes, sound is jerking etc etc). So I'm switched to SHED_ULE on my UP laptop; it was helpful. I'm running custom kernel without debug options though. > > thanks, > > Ganbold > > > -- > That's the thing about people who think they hate computers. What they > really hate is lousy programmers. -- Larry Niven and Jerry Pournelle in > "Oath of Fealty" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- The ultimate artifact may be found in the driven snow.. From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 15:48:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 490E416A417; Tue, 28 Aug 2007 15:48:48 +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 E4F6F13C494; Tue, 28 Aug 2007 15:48:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IQ3Iz-0008Kn-Ul; Tue, 28 Aug 2007 18:48:46 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7SFmbsq020095; Tue, 28 Aug 2007 18:48:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l7SFmbZl020094; Tue, 28 Aug 2007 18:48:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Aug 2007 18:48:37 +0300 From: Kostik Belousov To: "freebsd-current@freebsd.org" Message-ID: <20070828154837.GV2332@deviant.kiev.zoral.com.ua> References: <46D25242.10504@micom.mng.net> <20070827231419.H30469@fledge.watson.org> <20070828044133.GR2332@deviant.kiev.zoral.com.ua> <46D3A90D.8050703@micom.mng.net> <20070828143626.GA32611@admin.opentransfer.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AJu7IxIPovG6hMTN" Content-Disposition: inline In-Reply-To: <20070828143626.GA32611@admin.opentransfer.com> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 6dc4245230f22f3abb357b69a6da667e X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1415 [August 28 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {TO: suspicious real name} X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 35 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 15:48:48 -0000 --AJu7IxIPovG6hMTN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 09:36:26AM -0500, Oleg Nauman wrote: > On Tue, Aug 28, 2007 at 12:48:13PM +0800, Ganbold wrote: > > Kostik Belousov wrote: > > >On Mon, Aug 27, 2007 at 11:14:58PM +0100, Robert Watson wrote: > > > =20 > > >>On Mon, 27 Aug 2007, Ganbold wrote: > > >> > > >> =20 > > >>>I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS= =20 > > >>>enabled kernel. > > >>> =20 > > >>Try the same thing again without INVARIANTS and WITNESS, both of whic= h=20 > > >>can consume a lot of CPU in kernel on a very active system, especiall= y if=20 > > >>lots of vnodes are being allocated and freed. Especially WITNESS. > > >> =20 > > > > > >It does happens on the kernels without debug options, in particular, > > >WITNESS and INVARIANTS. > > > > > >It happens when a lot of short-lived processes are rapidly created. > > >Compilation is a good example of such workload; running configure scri= pt > > >is even better. > > > =20 > >=20 > > What would be a solution to this kind of problems? >=20 > From my point of view it exhibits some issues with standard SCHED_4BSD > scheduler in the 7.0 (my laptop is mostly unusable during 'make buildworl= d' > for example - keyboard exhibits lost event sometimes, sound is jerking et= c etc). > So I'm switched to SHED_ULE on my UP laptop; it was helpful. I'm running > custom kernel without debug options though. SCHED_ULE also exhibit the behaviour, but in lesser degree. Due to this, I suspect that the problem in the common code. Jeff, any suggestions ? --AJu7IxIPovG6hMTN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG1EPUC3+MBN1Mb4gRAkyuAKCcZLF/qNgBcDE81la+igrwhbhGFgCfQPdW afAU8yHvkr3cvJ6NK5QJ1+Q= =i78s -----END PGP SIGNATURE----- --AJu7IxIPovG6hMTN-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 16:53:13 2007 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 9F2E616A420 for ; Tue, 28 Aug 2007 16:53:13 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 34C3B13C478 for ; Tue, 28 Aug 2007 16:53:13 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l7SGqpGi023927; Tue, 28 Aug 2007 12:52:51 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Tue, 28 Aug 2007 12:52:51 -0400 (EDT) Date: Tue, 28 Aug 2007 12:52:51 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Yar Tikhiy In-Reply-To: <20070828140331.GA598@comp.chem.msu.su> Message-ID: References: <20070824.172212.74696955.imp@bsdimp.com> <20070825053302.GG99474@comp.chem.msu.su> <20070825.093925.43008968.imp@bsdimp.com> <1188071752.1853.44.camel@neo.cse.buffalo.edu> <20070826073535.GD21352@comp.chem.msu.su> <20070828140331.GA598@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ken Smith , current@freebsd.org, "M. Warner Losh" Subject: Re: Symbol versioning conventions (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 16:53:13 -0000 On Tue, 28 Aug 2007, Yar Tikhiy wrote: > On Sun, Aug 26, 2007 at 12:48:41PM -0400, Daniel Eischen wrote: >> >> Here it is on -current, feel free to redirect it to arch. >> >> I updated my notes on symbol versioning - see "Version naming conventions" >> on downwards at: >> >> http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt >> >> Feel free to cut&paste anything from it in replies. > > It seems that we've failed to divert the main discussion from the > cvs lists, so I'll comment on other sides of the symbol versioning > issue. > > First, you wrote that a symbol having multiple versions needs to > be listed in the symbol map file under each of its versions. I'm > afraid that the GNU ld(1) documentation doesn't suggest that. I > believe that it is correct to list each symbol in the symbol map > only once, under its default version. Ok, I'll update it. I think that part of my notes was written a long time ago. > Second, we need to decide how to handle SV consistently at source > tree level. In a trivial case, cut'n'paste or a stub function will > do, but in the more complex case of massive changes it can be hard > to reproduce the old ABI using stubs, e.g., because the new > implementation lost old bugs. In this case, CVS history should be > preserved for the old version at file level. A uniform approach > can be to repocopy the respective file(s) and add the version to > their name(s), e.g.: fts.c -> fts_fbsd_1_0.c. Does it sound > reasonable? Sure, I don't know if you have to use the version namespace in the filename, though. You could always put compat shim files into a separate directory too, but that might make building them a little more difficult if they rely on local headers. -- DE From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 16:54:45 2007 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 1CBB616A417 for ; Tue, 28 Aug 2007 16:54:45 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id AEF4D13C48A for ; Tue, 28 Aug 2007 16:54:44 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9304345E98; Tue, 28 Aug 2007 18:54:42 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3EE3A45E94; Tue, 28 Aug 2007 18:54:37 +0200 (CEST) Date: Tue, 28 Aug 2007 18:53:31 +0200 From: Pawel Jakub Dawidek To: Pascal Hofstee Message-ID: <20070828165331.GA39562@garage.freebsd.pl> References: <1188311242.1052.11.camel@trinity> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <1188311242.1052.11.camel@trinity> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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: current@FreeBSD.org Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 16:54:45 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 04:27:22PM +0200, Pascal Hofstee wrote: > Hi, >=20 > For the last couple of weeks now I've occasionally been getting kernel > panics through ZFS (usually during heavy disk-i/o on the ZFS volume) > usually at the time this happened i was busy in X and therefore unable > to get to the console and force a kernel-dump. Today though it seems i > was lucky and actually managed to catch a kernel panic while in console > mode. Below is the actual panic message, i tried looking at the actual > backtrace but all the interesting frames are purely addresses without > any symbol information. I'll assume this is because of zfs and friends > being loaded as KLDs. Any information on how to provide a proper > backtrace including all symbols involved would be appreciated. >=20 > uname -a: > FreeBSD trinity.zion 7.0-CURRENT FreeBSD 7.0-CURRENT #29: Sun Aug 26 > 20:19:12 CEST 2007 pascal@trinity.zion:/usr/obj/usr/src/sys/TRINITY > i386 >=20 > panic: ZFS: I/O failure (write on off 0: zio 0xc66a9cf0 [L0 > ZFS plain file] 20000L/20000P DVA[0]=3D<0:a126e0000:20000> fletcher2 > uncompressed LE contiguous birth=3D7004722 fill=3D1 > cksum=3D2dc0c354bd8ccc27:85745b74c1352a7f:72188a8646f7f624:28d89f21264ed4= f2): e^ When you don't use redundant configuration (no mirror, no raidz, no copies>1) then ZFS is going to panic on a write failure. It looks like ZFS found a bad block on your disk. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1FMLForvXbEpPzQRAuZKAJ9NTXMVgqEadiqtQ/IvRu9PQ5rUCgCeP9/G /eXtOE/dwyRZanCt2WegCyY= =KC3n -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:21:00 2007 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 CA88416A41A; Tue, 28 Aug 2007 17:21:00 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id A1B1013C4A3; Tue, 28 Aug 2007 17:21:00 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 1559F5B30; Tue, 28 Aug 2007 10:02:42 -0700 (PDT) To: Pawel Jakub Dawidek In-reply-to: Your message of "Tue, 28 Aug 2007 18:53:31 +0200." <20070828165331.GA39562@garage.freebsd.pl> Date: Tue, 28 Aug 2007 10:02:42 -0700 From: Bakul Shah Message-Id: <20070828170242.1559F5B30@mail.bitblocks.com> Cc: current@FreeBSD.org, Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:21:00 -0000 > When you don't use redundant configuration (no mirror, no raidz, no > copies>1) then ZFS is going to panic on a write failure. It looks like > ZFS found a bad block on your disk. Does SUN really say this about ZFS? Is this acceptable in a production environment? What if one of your mirrored disk fails and in the "degraded" environment (before you have had a chance to replace the bad disk) ZFS discovers that a write fails? Why can't it find an alternative block to write to? From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:25:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73ED616A418 for ; Tue, 28 Aug 2007 17:25:10 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id 352CD13C480 for ; Tue, 28 Aug 2007 17:25:10 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from maerlyn.bredbandsbolaget.se (213.114.133.105) by proxy2.bredband.net (7.3.127) id 46CDAD5C0014E541 for freebsd-current@freebsd.org; Tue, 28 Aug 2007 19:25:08 +0200 From: Daniel Tourde To: freebsd-current@freebsd.org Date: Tue, 28 Aug 2007 19:25:54 +0200 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: <200708281925.54536.daniel.tourde@spray.se> Subject: How to build 7.0-current without the WITNESS flags? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel.tourde@spray.se List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:25:10 -0000 Hello, I would like to build 7.0 without the WITNESS flags. How can I do that? Daniel From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:26:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BDEF16A418 for ; Tue, 28 Aug 2007 17:26:29 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5EA2F13C46E for ; Tue, 28 Aug 2007 17:26:28 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from maerlyn.bredbandsbolaget.se (213.114.133.105) by proxy3.bredband.net (7.3.127) id 46CDAD590014ACAF for freebsd-current@freebsd.org; Tue, 28 Aug 2007 19:26:27 +0200 From: Daniel Tourde To: freebsd-current@freebsd.org Date: Tue, 28 Aug 2007 19:27:13 +0200 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: <200708281927.13671.daniel.tourde@spray.se> Subject: gdb 6.1.1 on 7.0-current. Any update? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel.tourde@spray.se List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:26:29 -0000 Hello, gdb on the Aug 07 edition of 7.0 current is still 6.1.1. If I am not mistaken, the actual version of gdb is 6.6. Any plan to update this before the release of 7.0? Daniel From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:27:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A8016A41B for ; Tue, 28 Aug 2007 17:27:42 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4E013C428 for ; Tue, 28 Aug 2007 17:27:41 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from maerlyn.bredbandsbolaget.se (213.114.133.105) by proxy1.bredband.net (7.3.127) id 46CDAD4E001569B0 for freebsd-current@freebsd.org; Tue, 28 Aug 2007 19:27:40 +0200 From: Daniel Tourde To: freebsd-current@freebsd.org Date: Tue, 28 Aug 2007 19:28:26 +0200 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: <200708281928.26819.daniel.tourde@spray.se> Subject: gdb and gfortran in 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel.tourde@spray.se List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:27:42 -0000 Hello, I am trying 7.0-current and I am planning to use CVS. At the moment I have the snapshot of Aug 07 installed on my machine. I saw that by default, during bootstrap, gfortran and gdb aren't built. Do I simply need to comment the two NO_ flags in Makefile.incl to get gfortran and gdb or do I need to do anything else? Daniel From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:28:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94A2B16A417 for ; Tue, 28 Aug 2007 17:28:15 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.231]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1CF13C47E for ; Tue, 28 Aug 2007 17:28:14 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1322276nzf for ; Tue, 28 Aug 2007 10:28:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=ijjl4Ycrzmb1szwmuN6i9cHh0a+K9SRQ6sNcNlXyHwDGjpUf7IQBOozjfAtSSJ2z/CAt+d8xAi/1Viyjk2rLp34bI5dGpMfuqJQUJPyBsBSKjgBrD5w3uwsGGPCABB0Y4on/IjNsuswW9OLOKF4JWzWHWhgSW7z23pYOwL14auQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=irBUA63IPzOuWju6uYz5nCaXlaBjBd70F4DeZ9HMZxSAJWhKMfmFOs5ES9e13zOvDVPK5M4HV2s/nHxCrluxGlPe2A4a8KQVLtO+OqrRQxfDAdWFXm6S2dEtb7PIJS+rbh513jVjH36OTeODjEcEcRNZuRPr30u0fJ88IcYNUXc= Received: by 10.140.250.14 with SMTP id x14mr2431621rvh.1188322092987; Tue, 28 Aug 2007 10:28:12 -0700 (PDT) Received: by 10.141.51.8 with HTTP; Tue, 28 Aug 2007 10:28:12 -0700 (PDT) Message-ID: Date: Tue, 28 Aug 2007 13:28:12 -0400 From: "Scott Ullrich" To: daniel.tourde@spray.se In-Reply-To: <200708281925.54536.daniel.tourde@spray.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200708281925.54536.daniel.tourde@spray.se> Cc: freebsd-current@freebsd.org Subject: Re: How to build 7.0-current without the WITNESS flags? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 17:28:15 -0000 On 8/28/07, Daniel Tourde wrote: > Hello, > > I would like to build 7.0 without the WITNESS flags. How can I do that? The FreeBSD handbook goes over the procedures for this located here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html Scott From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:29:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B485C16A468; Tue, 28 Aug 2007 17:29:08 +0000 (UTC) Date: Tue, 28 Aug 2007 17:29:08 +0000 From: Kris Kennaway To: Daniel Tourde Message-ID: <20070828172908.GC77256@hub.freebsd.org> References: <200708281928.26819.daniel.tourde@spray.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708281928.26819.daniel.tourde@spray.se> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: gdb and gfortran in 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:29:08 -0000 On Tue, Aug 28, 2007 at 07:28:26PM +0200, Daniel Tourde wrote: > Hello, > > I am trying 7.0-current and I am planning to use CVS. At the moment I have the > snapshot of Aug 07 installed on my machine. > > I saw that by default, during bootstrap, gfortran and gdb aren't built. Do I > simply need to comment the two NO_ flags in Makefile.incl to get gfortran and > gdb or do I need to do anything else? gdb is included in 7.0 and should be built by default. gfortran is not included in 7.0 and you need to install the port if you want it. Kris From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:30:02 2007 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 A258816A468 for ; Tue, 28 Aug 2007 17:30:02 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 2066F13C48A for ; Tue, 28 Aug 2007 17:30:01 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1534674nfb for ; Tue, 28 Aug 2007 10:30:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=Web9zfkvQeQ3OhWMAcsaOlZ2eBcG61vuH0yZS23JpjqbBvyG7oyk2PKKm5KMHb+oPJSNB+qu9lJCLCwNnflPofvwQfAHdl1QDbzkkgAa2Npgbt4WpTkx1ZUpuxT5zELJqM2CkRu1++fQJm3fV+szrGUUpFfOI9ECT6AttS77Wgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=MW8ZQaOXXpai8u4Nzg6c+Mn5t+h/AOdmc4pU9E5fTsAPyqWLKDigs63O5dLzChRCRW/r3L986IiUUJYiLJTOyuwTHSAMO/nZ9bfdNi0LboeOrLzhljxVYRm46oX84pA28ItApNe/9crinM/5wT5z0ea+cIjqT+R9OfSkQUAoao4= Received: by 10.78.138.6 with SMTP id l6mr5065974hud.1188322200277; Tue, 28 Aug 2007 10:30:00 -0700 (PDT) Received: from ?192.168.2.2? ( [87.166.80.121]) by mx.google.com with ESMTPS id z40sm2893711ugc.2007.08.28.10.29.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Aug 2007 10:29:59 -0700 (PDT) From: Pascal Hofstee To: Pawel Jakub Dawidek In-Reply-To: <20070828165331.GA39562@garage.freebsd.pl> References: <1188311242.1052.11.camel@trinity> <20070828165331.GA39562@garage.freebsd.pl> Content-Type: text/plain Date: Tue, 28 Aug 2007 19:29:54 +0200 Message-Id: <1188322194.1033.3.camel@trinity> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:30:02 -0000 On Tue, 2007-08-28 at 18:53 +0200, Pawel Jakub Dawidek wrote: > When you don't use redundant configuration (no mirror, no raidz, no > copies>1) then ZFS is going to panic on a write failure. It looks like > ZFS found a bad block on your disk. Hmmm ... the disk in question is a Maxtor 300GB USB attached disk (using atausb instead of umass) which is barely half a year old ... i understand bad blocks Can happen though at anytime and i obviously hope this is not the case as i'll be having to find alternate storage for well over 200GB of data in that case pretty soon. -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:30:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id A4ABF16A420; Tue, 28 Aug 2007 17:30:36 +0000 (UTC) Date: Tue, 28 Aug 2007 17:30:36 +0000 From: Kris Kennaway To: Daniel Tourde Message-ID: <20070828173036.GD77256@hub.freebsd.org> References: <200708281927.13671.daniel.tourde@spray.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708281927.13671.daniel.tourde@spray.se> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: gdb 6.1.1 on 7.0-current. Any update? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:30:36 -0000 On Tue, Aug 28, 2007 at 07:27:13PM +0200, Daniel Tourde wrote: > Hello, > > gdb on the Aug 07 edition of 7.0 current is still 6.1.1. If I am not mistaken, > the actual version of gdb is 6.6. Any plan to update this before the release > of 7.0? AFAIK someone needs to integrate or reimplement the FreeBSD local changes into gdb 6.6, and this isn't likely to happen in time for 7.0. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:44:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F2C16A41B for ; Tue, 28 Aug 2007 17:44:03 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.175]) by mx1.freebsd.org (Postfix) with ESMTP id 358F013C4DA for ; Tue, 28 Aug 2007 17:44:03 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/smtpout05/MantshX 4.0) with ESMTP id l7SHSdJZ003889; Tue, 28 Aug 2007 10:28:39 -0700 (PDT) Received: from [172.24.104.78] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id l7SHScQm020482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Aug 2007 10:28:39 -0700 (PDT) In-Reply-To: <200708281927.13671.daniel.tourde@spray.se> References: <200708281927.13671.daniel.tourde@spray.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 28 Aug 2007 10:28:03 -0700 To: daniel.tourde@spray.se X-Mailer: Apple Mail (2.752.3) Cc: freebsd-current@freebsd.org Subject: Re: gdb 6.1.1 on 7.0-current. Any update? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:44:03 -0000 On Aug 28, 2007, at 10:27 AM, Daniel Tourde wrote: > Hello, > > gdb on the Aug 07 edition of 7.0 current is still 6.1.1. If I am > not mistaken, > the actual version of gdb is 6.6. Any plan to update this before > the release > of 7.0? No. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:44:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2456B16A420 for ; Tue, 28 Aug 2007 17:44:27 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id BF8D813C46B for ; Tue, 28 Aug 2007 17:44:26 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1228766wra for ; Tue, 28 Aug 2007 10:44:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=kfelKIr+GHfJ1RdFgbiT2xmMRL5OQdWD6KufKLuIjgWxcHJF44bGa1nSM+7LIgoO6jSTZrM4Gg8SXfK4eoR4yLvMj3va6ia9YB7swI22R6wDdGugdjVYv7f+qeCYn6ygq/8m628AjqEKmfDew9Rf/wMyAiVCcVrwoVhhsAM4SrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=gwWKhLRxdhTHOyD2WWnYdNyLAiqwCyDRtC4ULnKMejIYP8SCk7p7zHeO2TLxYLCwMcHl98/ccWdmqzjWNXTUladdDt9yFVqDo/LbCh6dV2nmbfUsD+gssmaKOJn235knFyOpXfSv1Ctn4qvKhqAYNu6IIU//HMvekG9WkHFQMdw= Received: by 10.100.178.7 with SMTP id a7mr3021705anf.1188321377333; Tue, 28 Aug 2007 10:16:17 -0700 (PDT) Received: by 10.100.92.13 with HTTP; Tue, 28 Aug 2007 10:16:17 -0700 (PDT) Message-ID: <8e10486b0708281016o320fa540qc24a5eb831de8538@mail.gmail.com> Date: Tue, 28 Aug 2007 14:16:17 -0300 From: "Alexandre Biancalana" 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-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: buildworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 17:44:27 -0000 Hi list, With fonts csup'ed today I'm getting the following buildworld error: cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -o gengtype gengtype.ogengtype-yacc+%DIKED.o gengtype-lex.o errors.o libiberty.a ./gengtype /libexec/ld-elf.so.1: /lib/libc.so.7: version FBSD_1.0 required by ./gengtype not defined *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. This is a known error ? Regards, Alexandre From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:48:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80D116A46C for ; Tue, 28 Aug 2007 17:48:42 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id 6792613C48D for ; Tue, 28 Aug 2007 17:48:42 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from maerlyn.bredbandsbolaget.se (213.114.133.105) by proxy1.bredband.net (7.3.127) id 46CDAD4E00157DED; Tue, 28 Aug 2007 19:48:41 +0200 From: Daniel Tourde To: Kris Kennaway Date: Tue, 28 Aug 2007 19:49:25 +0200 User-Agent: KMail/1.9.7 References: <200708281928.26819.daniel.tourde@spray.se> <20070828172908.GC77256@hub.freebsd.org> In-Reply-To: <20070828172908.GC77256@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708281949.26686.daniel.tourde@spray.se> Cc: freebsd-current@freebsd.org Subject: Re: gdb and gfortran in 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel.tourde@spray.se List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:48:42 -0000 Hello Kris, > > I am trying 7.0-current and I am planning to use CVS. At the moment I > > have the snapshot of Aug 07 installed on my machine. > > > > I saw that by default, during bootstrap, gfortran and gdb aren't built. > > Do I simply need to comment the two NO_ flags in Makefile.incl to get > > gfortran and gdb or do I need to do anything else? > > gdb is included in 7.0 and should be built by default. gfortran is > not included in 7.0 and you need to install the port if you want it. Thanks for your answer. Why isn't gfortran (coming from gcc 4.2.1) included in 7.0 when f77 (coming from gcc-3.4.6) is included in 6.2? Daniel From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:49:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C051116A417 for ; Tue, 28 Aug 2007 17:49:26 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4AC13C478 for ; Tue, 28 Aug 2007 17:49:26 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from maerlyn.bredbandsbolaget.se (213.114.133.105) by proxy1.bredband.net (7.3.127) id 46CDAD4E00157EBC; Tue, 28 Aug 2007 19:49:25 +0200 From: Daniel Tourde To: Kris Kennaway Date: Tue, 28 Aug 2007 19:50:10 +0200 User-Agent: KMail/1.9.7 References: <200708281927.13671.daniel.tourde@spray.se> <20070828173036.GD77256@hub.freebsd.org> In-Reply-To: <20070828173036.GD77256@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708281950.11793.daniel.tourde@spray.se> Cc: freebsd-current@freebsd.org Subject: Re: gdb 6.1.1 on 7.0-current. Any update? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel.tourde@spray.se List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:49:26 -0000 Hello Kris, > > gdb on the Aug 07 edition of 7.0 current is still 6.1.1. If I am not > > mistaken, the actual version of gdb is 6.6. Any plan to update this > > before the release of 7.0? > > AFAIK someone needs to integrate or reimplement the FreeBSD local > changes into gdb 6.6, and this isn't likely to happen in time for 7.0. OK. Any plan for 7.1 or 7.2? Daniel From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:54:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8169616A494 for ; Tue, 28 Aug 2007 17:54:47 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3F65313C457 for ; Tue, 28 Aug 2007 17:54:47 +0000 (UTC) (envelope-from daniel.tourde@spray.se) Received: from maerlyn.bredbandsbolaget.se (213.114.133.105) by proxy3.bredband.net (7.3.127) id 46CDAD590014C790; Tue, 28 Aug 2007 19:54:45 +0200 From: Daniel Tourde To: "Scott Ullrich" Date: Tue, 28 Aug 2007 19:55:30 +0200 User-Agent: KMail/1.9.7 References: <200708281925.54536.daniel.tourde@spray.se> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708281955.31031.daniel.tourde@spray.se> Cc: freebsd-current@freebsd.org Subject: Re: How to build 7.0-current without the WITNESS flags? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel.tourde@spray.se List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:54:47 -0000 Hello Scott, Thanks for your answer. I know how to rebuild a kernel (well, I did it a couple of times, not really an oldtimer but not really a newby anymore... ;) ) My question was regarding the WITNESS flags. I haven't seen any reference to it in the page you suggested. I suppose it is easy to switch it off, as long as it is done at the right place. My question was: How to switch it off cleanly? Daniel > > I would like to build 7.0 without the WITNESS flags. How can I do that? > > The FreeBSD handbook goes over the procedures for this located here: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-buil >ding.html > > Scott From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:55:17 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 666ED16A41A for ; Tue, 28 Aug 2007 17:55:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 9A75313C428 for ; Tue, 28 Aug 2007 17:55:14 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C6B0C4569A; Tue, 28 Aug 2007 19:55:12 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C9DFF45683; Tue, 28 Aug 2007 19:55:07 +0200 (CEST) Date: Tue, 28 Aug 2007 19:54:02 +0200 From: Pawel Jakub Dawidek To: Hugo Silva Message-ID: <20070828175402.GB39562@garage.freebsd.pl> References: <46D2C812.8090106@gmail.com> <20070828104625.GB36596@garage.freebsd.pl> <46D40833.2030007@barafranca.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline In-Reply-To: <46D40833.2030007@barafranca.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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: freebsd-current@FreeBSD.ORG Subject: Re: Encrypted 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: Tue, 28 Aug 2007 17:55:17 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 12:34:11PM +0100, Hugo Silva wrote: > How's the performance on the geli-backed pool ? It depends a lot on CPU speed, but you should be ready for visible performance drop. I'll give you two examples: 1. 3 ATA/SATA disks in RAIDZ1 configuration: CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.70-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs ad1: 476940MB at ata0-slave UDMA100 ad4: 476940MB at ata2-master SATA150 ad6: 476940MB at ata3-master SATA150 Performance of sequential write/read without encryption: # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 # dd if=3D/dev/zero of=3D/tank/zero bs=3D1m count=3D3000 96MB/s # zpool export tank && zpool import tank # dd if=3D/tank/zero of=3D/dev/null bs=3D1m 140MB/s Performance of sequential write/read with encryption: # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad1.eli ONLINE 0 0 0 ad4.eli ONLINE 0 0 0 ad6.eli ONLINE 0 0 0 # dd if=3D/dev/zero of=3D/tank/zero bs=3D1m count=3D3000 26MB/s # zpool export tank && zpool import tank # dd if=3D/tank/zero of=3D/dev/null bs=3D1m 38MB/s In other words the impact in this example is significant. You need to evaluate if you really need encryption. For my use it is totally acceptable and I need encryption anyway. 2. 14 SCSI disks in RAIDZ2 configuration: CPU: Intel(R) Xeon(R) CPU E5310 @ 1.60GHz (1597.65-MHz K8-class= CPU) FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs 14x daX at isp0 bus 0 target 12 lun 0 daX: Fixed Direct Access SCSI-3 device=20 daX: 200.000MB/s transfers WWNN 0x20000004cf9b0c63 WWPN 0x22000004cf9b0c63= PortID 0xd2 daX: Command Queueing Enabled daX: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) Unfortunately connected only through 2Gb FC. Performance of sequential write/read without encryption: # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 da10 ONLINE 0 0 0 da11 ONLINE 0 0 0 da12 ONLINE 0 0 0 da13 ONLINE 0 0 0 da14 ONLINE 0 0 0 # dd if=3D/dev/zero of=3D/tank/zero bs=3D1m count=3D3000 103MB/s # zpool export tank && zpool import tank # dd if=3D/tank/zero of=3D/dev/null bs=3D1m 125MB/s Performance of sequential write/read with encryption: # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 da0.eli ONLINE 0 0 0 da1.eli ONLINE 0 0 0 da3.eli ONLINE 0 0 0 da4.eli ONLINE 0 0 0 da5.eli ONLINE 0 0 0 da6.eli ONLINE 0 0 0 da7.eli ONLINE 0 0 0 da8.eli ONLINE 0 0 0 da9.eli ONLINE 0 0 0 da10.eli ONLINE 0 0 0 da11.eli ONLINE 0 0 0 da12.eli ONLINE 0 0 0 da13.eli ONLINE 0 0 0 da14.eli ONLINE 0 0 0 # dd if=3D/dev/zero of=3D/tank/zero bs=3D1m count=3D3000 91MB/s # zpool export tank && zpool import tank # dd if=3D/tank/zero of=3D/dev/null bs=3D1m 122MB/s The negative impact on performance is much smaller here. I'm quite sure impact is much less for random, parallel access. Sequential operations (write not as much as reads in ZFS case) are sensitive on higher latency. But don't you worry, when you must have encryption, you don't really care about performance. And when you decided not to use encryption, because it introduces too big overhead, it only means that you didn't need encryption in the first place:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1GE5ForvXbEpPzQRAhpMAKCUCC/Jlwea0/VcBI1shX3eTUOgkwCfcl+r NHEtNDe8jmrZE8lLpJn6X3c= =RZIV -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 18:01:57 2007 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 C461D16A419 for ; Tue, 28 Aug 2007 18:01:57 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 65ECD13C459 for ; Tue, 28 Aug 2007 18:01:57 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 830FB45E9D; Tue, 28 Aug 2007 20:01:56 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 59CD645684; Tue, 28 Aug 2007 20:01:51 +0200 (CEST) Date: Tue, 28 Aug 2007 20:00:45 +0200 From: Pawel Jakub Dawidek To: Pascal Hofstee Message-ID: <20070828180045.GC39562@garage.freebsd.pl> References: <1188311242.1052.11.camel@trinity> <20070828165331.GA39562@garage.freebsd.pl> <1188322194.1033.3.camel@trinity> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vOmOzSkFvhd7u8Ms" Content-Disposition: inline In-Reply-To: <1188322194.1033.3.camel@trinity> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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: current@FreeBSD.org Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 18:01:57 -0000 --vOmOzSkFvhd7u8Ms Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 07:29:54PM +0200, Pascal Hofstee wrote: > On Tue, 2007-08-28 at 18:53 +0200, Pawel Jakub Dawidek wrote: > > When you don't use redundant configuration (no mirror, no raidz, no > > copies>1) then ZFS is going to panic on a write failure. It looks like > > ZFS found a bad block on your disk. >=20 > Hmmm ... the disk in question is a Maxtor 300GB USB attached disk (using > atausb instead of umass) which is barely half a year old ... i > understand bad blocks Can happen though at anytime and i obviously hope > this is not the case as i'll be having to find alternate storage for > well over 200GB of data in that case pretty soon. Maybe this wasn't disk error, but cabel problem or something, although ZFS tries few times before panicing. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --vOmOzSkFvhd7u8Ms Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1GLNForvXbEpPzQRAlVFAKC0JXH3Gj0CklSlFF+l8m/6f9bQcACfSAmj YWlxMKbG5RDTP63TXQH3tik= =OAHN -----END PGP SIGNATURE----- --vOmOzSkFvhd7u8Ms-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 18:03:43 2007 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 69B2B16A46C for ; Tue, 28 Aug 2007 18:03:43 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 0956613C4D3 for ; Tue, 28 Aug 2007 18:03:42 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 17C4045E94; Tue, 28 Aug 2007 20:03:42 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id ACAB545683; Tue, 28 Aug 2007 20:03:34 +0200 (CEST) Date: Tue, 28 Aug 2007 20:02:28 +0200 From: Pawel Jakub Dawidek To: Bakul Shah Message-ID: <20070828180228.GD39562@garage.freebsd.pl> References: <20070828165331.GA39562@garage.freebsd.pl> <20070828170242.1559F5B30@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uxuisgdDHaNETlh8" Content-Disposition: inline In-Reply-To: <20070828170242.1559F5B30@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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: current@FreeBSD.org, Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 18:03:43 -0000 --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 10:02:42AM -0700, Bakul Shah wrote: > > When you don't use redundant configuration (no mirror, no raidz, no > > copies>1) then ZFS is going to panic on a write failure. It looks like > > ZFS found a bad block on your disk. >=20 > Does SUN really say this about ZFS? Is this acceptable in a > production environment? What if one of your mirrored disk > fails and in the "degraded" environment (before you have had > a chance to replace the bad disk) ZFS discovers that a write > fails? Why can't it find an alternative block to write to? There were many complains on zfs-discuss@, you may want to look into archive. The short version is that many users doesn't like that, and it should change in the future - because of COW model it should be quite easy to just mark block as bad and take next one, but it's not currently implemented. It's much less of a problem when one uses redundancy. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --uxuisgdDHaNETlh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1GM0ForvXbEpPzQRArAmAKCxNQTAPw5zym9a0TmqJpp3ucombACfSJA4 9nv40SueyQal5WcwMKfWubw= =5NnR -----END PGP SIGNATURE----- --uxuisgdDHaNETlh8-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 18:04:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F8FF16A41A for ; Tue, 28 Aug 2007 18:04:16 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id BFB0813C4B7 for ; Tue, 28 Aug 2007 18:04:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1543945nfb for ; Tue, 28 Aug 2007 11:04:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=dR9lyTSZtl8i16iLJLtSBWM9WolsewLnrzhTA40kdhOoxmyqyf8Hlqi2zJial75KpZom9zbQyGYQ5OuO0tiqtHp8C4PFsHMJN92RLHTc3hn/qZTLSUzgvc8Ty6TR+NOA2pLCgVK4ladIQ+2my2mLiloU8r7xcUmJOgMdFK1RHQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ib4jSk9px5REQHH7r8sE9LucNmDIlSZfwO4tApS8UBTSJRXu9/jiNk1vyJmCsQthJuKb4JwMn4SoYIdFiw22cDq/zIVXYPwrvaTdLsM3KXAeC2FKADoMr2G9hAECkamfclma8q+FC3Jw3NPrIg8oLRB39A5GtOE4PLqOweYxgC0= Received: by 10.86.81.8 with SMTP id e8mr5975602fgb.1188324254154; Tue, 28 Aug 2007 11:04:14 -0700 (PDT) Received: by 10.86.81.6 with HTTP; Tue, 28 Aug 2007 11:04:14 -0700 (PDT) Message-ID: <2a41acea0708281104i1fdc62a3w532a86b0105bd2d7@mail.gmail.com> Date: Tue, 28 Aug 2007 11:04:14 -0700 From: "Jack Vogel" To: daniel.tourde@spray.se In-Reply-To: <200708281955.31031.daniel.tourde@spray.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200708281925.54536.daniel.tourde@spray.se> <200708281955.31031.daniel.tourde@spray.se> Cc: freebsd-current@freebsd.org, Scott Ullrich Subject: Re: How to build 7.0-current without the WITNESS flags? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 18:04:16 -0000 On 8/28/07, Daniel Tourde wrote: > Hello Scott, > > Thanks for your answer. > I know how to rebuild a kernel (well, I did it a couple of times, not really > an oldtimer but not really a newby anymore... ;) ) > > My question was regarding the WITNESS flags. I haven't seen any reference to > it in the page you suggested. I suppose it is easy to switch it off, as long > as it is done at the right place. My question was: > How to switch it off cleanly? There are two WITNESS entries and two INVARIANTS in your config file, just remove them re-config and build. From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 18:12:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6507E16A419 for ; Tue, 28 Aug 2007 18:12:25 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from zmail.illuminati.org (mail.illuminati.org [70.42.141.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4B66E13C465 for ; Tue, 28 Aug 2007 18:12:25 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by zmail.illuminati.org (Postfix) with ESMTP id B638616C86DF for ; Tue, 28 Aug 2007 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from zmail.illuminati.org ([127.0.0.1]) by localhost (zmail.illuminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coSXScKezmgd for ; Tue, 28 Aug 2007 11:12:12 -0700 (PDT) Received: from zmail.illuminati.org (zmail.illuminati.org [10.32.1.33]) by zmail.illuminati.org (Postfix) with ESMTP id E7A0016C86DE for ; Tue, 28 Aug 2007 11:12:12 -0700 (PDT) Date: Tue, 28 Aug 2007 11:12:12 -0700 (PDT) From: Brooks Talley To: freebsd-current Message-ID: <16447218.32631188324732895.JavaMail.root@zmail.illuminati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [63.231.27.116] Subject: Tidbit for improving Samba 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: Tue, 28 Aug 2007 18:12:25 -0000 I've been fighting with a new 7.0-CURRENT install, trying to get decent Samba performance between the FreeBSD box and a Vista workstation on a gigabit network. Lots of stuff out there recommends setting Samba's SO_RCVBUF and SO_SNDBUF options to 8192. Bad idea! In lots of testing, what I've found is that performance is at its best when those options match net.inet.tcp.recvspace and net.inet.tcp.sendspace respectively. With a default install, I was seeing about 15MB/s transfer rates. Setting SO_RECVBUF and SO_SNDBUF to 8192 dropped me to about 11MB/s, which made me experiment a bit. Right now, with net.inet.tcp.recvspace and net.inet.tcp.sendspace both at 65536 and SO_RCVBUF and SO_SNDBUF also at 65536, I'm seeing about 60MB/s. Still not great, but a significant improvement. FWIW, going higher than 65536 causes the Vista workstation to lose its mapped drive all the time. And changing the MTU on both FreeBSD and Vista (to either 4088 or 9014) had no discernable benefit. This is on a 7.0-CURRENT compiled without all of the debugging stuff, and it's at 0.7 load and 73% idle when transferring 60MB/s, so I think there's still some headroom there for improvement. Anyways, thought I'd share with the group, since I haven't seen this mentioned in copious amounts of Googling. -b From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 18:38:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id C3CBD16A477; Tue, 28 Aug 2007 18:38:50 +0000 (UTC) Date: Tue, 28 Aug 2007 18:38:50 +0000 From: Kris Kennaway To: Daniel Tourde Message-ID: <20070828183850.GA85642@hub.freebsd.org> References: <200708281927.13671.daniel.tourde@spray.se> <20070828173036.GD77256@hub.freebsd.org> <200708281950.11793.daniel.tourde@spray.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708281950.11793.daniel.tourde@spray.se> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: gdb 6.1.1 on 7.0-current. Any update? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 18:38:50 -0000 On Tue, Aug 28, 2007 at 07:50:10PM +0200, Daniel Tourde wrote: > Hello Kris, > > > > > gdb on the Aug 07 edition of 7.0 current is still 6.1.1. If I am not > > > mistaken, the actual version of gdb is 6.6. Any plan to update this > > > before the release of 7.0? > > > > AFAIK someone needs to integrate or reimplement the FreeBSD local > > changes into gdb 6.6, and this isn't likely to happen in time for 7.0. > > OK. Any plan for 7.1 or 7.2? The answer is the same: only if someone does the work. Kris From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 18:39:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 3219216A420; Tue, 28 Aug 2007 18:39:35 +0000 (UTC) Date: Tue, 28 Aug 2007 18:39:35 +0000 From: Kris Kennaway To: Daniel Tourde Message-ID: <20070828183935.GB85642@hub.freebsd.org> References: <200708281928.26819.daniel.tourde@spray.se> <20070828172908.GC77256@hub.freebsd.org> <200708281949.26686.daniel.tourde@spray.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708281949.26686.daniel.tourde@spray.se> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: gdb and gfortran in 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 18:39:37 -0000 On Tue, Aug 28, 2007 at 07:49:25PM +0200, Daniel Tourde wrote: > Hello Kris, > > > > > I am trying 7.0-current and I am planning to use CVS. At the moment I > > > have the snapshot of Aug 07 installed on my machine. > > > > > > I saw that by default, during bootstrap, gfortran and gdb aren't built. > > > Do I simply need to comment the two NO_ flags in Makefile.incl to get > > > gfortran and gdb or do I need to do anything else? > > > > gdb is included in 7.0 and should be built by default. gfortran is > > not included in 7.0 and you need to install the port if you want it. > > Thanks for your answer. > Why isn't gfortran (coming from gcc 4.2.1) included in 7.0 when f77 (coming > from gcc-3.4.6) is included in 6.2? Nothing in the base system requires it, and fortran is a niche language (though popular in that niche). This is the very definition of what the ports collection is for. Kris From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 20:16:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F254716A41A for ; Tue, 28 Aug 2007 20:16:13 +0000 (UTC) (envelope-from william88@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by mx1.freebsd.org (Postfix) with ESMTP id 841B713C4A6 for ; Tue, 28 Aug 2007 20:16:13 +0000 (UTC) (envelope-from william88@gmail.com) Received: by el-out-1112.google.com with SMTP id s27so445625ele for ; Tue, 28 Aug 2007 13:16:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=oMClH12R/JRnzvDoP21qqBxUnxW+U4+PkY6d57nOT/qplVueN46jMqoUTY/5597NfWzS9NUjhlqbO2QpTIUFNAilhL/+jDhPlo8pWf2qZbKI0xIar2tJJg3WDpPFsf6cJCR7Ol3HvB/FiSgYErW1+lH7dbNWoJJjAvI2D2xMlUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=N4T6j0jU2RBPqjQ9fCgZe3ZkrFqWgwZtvcUfG6KZkZEz+XkfWFO/KQS0hH/rXpbGBqKI2+BkGGPzStXNbKOLekbAjAD0a4Xjg0qqGGxJ5wwLVuYMo3Oqufr17MUuz0mo1SbkEObxkYtW9o4s8SH9IXXTvZm/iwxfPOsfrcOjWiE= Received: by 10.115.22.1 with SMTP id z1mr1671887wai.1188332171283; Tue, 28 Aug 2007 13:16:11 -0700 (PDT) Received: by 10.114.111.4 with HTTP; Tue, 28 Aug 2007 13:15:56 -0700 (PDT) Message-ID: <632825b40708281315p7f0b059cu726ae13b89b38c6c@mail.gmail.com> Date: Tue, 28 Aug 2007 17:15:56 -0300 From: "William Grzybowski" 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-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: error building current kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 20:16:14 -0000 Hi, I am getting some errors about sctp while i build kernel from today... Could it be happening because i created a src.conf file disablind bind, ipv6, ipfilter, kerberos and sendmail ? (i dont think so, but it was the only thing which i modified...) uipc_syscalls.o(.text+0x341): In function `sctp_generic_recvmsg': /usr/src/sys/kern/uipc_syscalls.c:2600: undefined reference to `sctp_sorecvmsg' uipc_syscalls.o(.text+0x86c): In function `sctp_peeloff': /usr/src/sys/kern/uipc_syscalls.c:2238: undefined reference to `sctp_can_peel_of f' uipc_syscalls.o(.text+0xa7a):/usr/src/sys/kern/uipc_syscalls.c:2279: undefined r eference to `sctp_do_peeloff' uipc_syscalls.o(.text+0xdf0): In function `sctp_generic_sendmsg_iov': /usr/src/sys/kern/uipc_syscalls.c:2478: undefined reference to `sctp_lower_sosen d' uipc_syscalls.o(.text+0x109a): In function `sctp_generic_sendmsg': /usr/src/sys/kern/uipc_syscalls.c:2371: undefined reference to `sctp_lower_sosen d' rtsock.o(.text+0x123b): In function `rt_newaddrmsg': /usr/src/sys/net/rtsock.c:896: undefined reference to `sctp_addr_change' in_proto.o(.data+0xa8): undefined reference to `sctp_input' in_proto.o(.data+0xb0): undefined reference to `sctp_ctlinput' in_proto.o(.data+0xb4): undefined reference to `sctp_ctloutput' in_proto.o(.data+0xbc): undefined reference to `sctp_init' in_proto.o(.data+0xc8): undefined reference to `sctp_drain' in_proto.o(.data+0xcc): undefined reference to `sctp_usrreqs' in_proto.o(.data+0xdc): undefined reference to `sctp_input' in_proto.o(.data+0xe4): undefined reference to `sctp_ctlinput' in_proto.o(.data+0xe8): undefined reference to `sctp_ctloutput' in_proto.o(.data+0xfc): undefined reference to `sctp_drain' in_proto.o(.data+0x100): undefined reference to `sctp_usrreqs' in_proto.o(.data+0x110): undefined reference to `sctp_input' in_proto.o(.data+0x118): undefined reference to `sctp_ctlinput' in_proto.o(.data+0x11c): undefined reference to `sctp_ctloutput' in_proto.o(.data+0x130): undefined reference to `sctp_drain' in_proto.o(.data+0x134): undefined reference to `sctp_usrreqs' *** Error code 1 Bye. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR - Brazil From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 20:22:12 2007 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 EA43116A41A; Tue, 28 Aug 2007 20:22:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id BAF6213C428; Tue, 28 Aug 2007 20:22:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4089227271; Tue, 28 Aug 2007 16:22:12 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 28 Aug 2007 16:22:12 -0400 X-Sasl-enc: gDOl1TDpDenI3N0tEdobsOTyma1I7Oa0H1QJV8VqVEws 1188332531 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id BF2292330B; Tue, 28 Aug 2007 16:22:11 -0400 (EDT) Message-ID: <46D483F2.2040207@FreeBSD.org> Date: Tue, 28 Aug 2007 21:22:10 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Andrew Thompson References: <20070828040026.GB42201@heff.fud.org.nz> <46D3C9F3.2010802@FreeBSD.org> <20070828103110.GA43049@heff.fud.org.nz> In-Reply-To: <20070828103110.GA43049@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: multicast packets from bpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 20:22:13 -0000 Andrew Thompson wrote: > I had originally started to put it there but realised that I need a > pointer to the ifnet to read if_broadcastaddr, I didnt think it was > worth changing the function parameters when the check can also just go > in bpfwrite. I dont mind moving it if its the more correct place to put= > it. > =20 It's already got a switch..case breakout for the DLTs and knows how to=20 grok the 802.11 header format which can have up to 6 (yes, 6) 802.3=20 style MAC addresses, all of which mean different things depending on=20 whether you are STA, AP, Mesh Portal, Mesh AP... :-) So it seems like the right place. bpf_movein() is static and referenced=20 once within its translation unit, so it is a candidate for inlining; I=20 would change ifp-=BBif_mtu to ifp in the call. > Is the tapwrite patch still needed? The mbuf is passed to ether_input > which should do the right thing. > =20 Good point. A casual reading suggests it *may* no longer be needed since = my pass over ether_input(), but seeing as we're due to branch and all,=20 I'll leave garbage collecting the 10 lines in tapwrite() to someone=20 else. :-) > I could go with this but it seems wrong to be passed a mbuf which has > incorrect flags, there may be other places in the stack that look for > M_*CAST that also have quirks. > =20 Yup. Someone could potentially drive a netgraph stake between the=20 producer and the if_bridge consumer... Thank you for looking at this btw. regards, BMS From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 20:30:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CE9116A41A; Tue, 28 Aug 2007 20:30: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 B00EF13C45E; Tue, 28 Aug 2007 20:30:37 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l7SKUX3m053629 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2007 16:30:34 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 28 Aug 2007 13:32:55 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Kostik Belousov In-Reply-To: <20070828154837.GV2332@deviant.kiev.zoral.com.ua> Message-ID: <20070828132543.O568@10.0.0.1> References: <46D25242.10504@micom.mng.net> <20070827231419.H30469@fledge.watson.org> <20070828044133.GR2332@deviant.kiev.zoral.com.ua> <46D3A90D.8050703@micom.mng.net> <20070828143626.GA32611@admin.opentransfer.com> <20070828154837.GV2332@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-current@freebsd.org" Subject: Re: computer becomes slow when compiling something X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 20:30:38 -0000 On Tue, 28 Aug 2007, Kostik Belousov wrote: > On Tue, Aug 28, 2007 at 09:36:26AM -0500, Oleg Nauman wrote: >> On Tue, Aug 28, 2007 at 12:48:13PM +0800, Ganbold wrote: >>> Kostik Belousov wrote: >>>> On Mon, Aug 27, 2007 at 11:14:58PM +0100, Robert Watson wrote: >>>> >>>>> On Mon, 27 Aug 2007, Ganbold wrote: >>>>> >>>>> >>>>>> I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS >>>>>> enabled kernel. >>>>>> >>>>> Try the same thing again without INVARIANTS and WITNESS, both of which >>>>> can consume a lot of CPU in kernel on a very active system, especially if >>>>> lots of vnodes are being allocated and freed. Especially WITNESS. >>>>> >>>> >>>> It does happens on the kernels without debug options, in particular, >>>> WITNESS and INVARIANTS. >>>> >>>> It happens when a lot of short-lived processes are rapidly created. >>>> Compilation is a good example of such workload; running configure script >>>> is even better. >>>> >>> >>> What would be a solution to this kind of problems? >> >> From my point of view it exhibits some issues with standard SCHED_4BSD >> scheduler in the 7.0 (my laptop is mostly unusable during 'make buildworld' >> for example - keyboard exhibits lost event sometimes, sound is jerking etc etc). >> So I'm switched to SHED_ULE on my UP laptop; it was helpful. I'm running >> custom kernel without debug options though. > > SCHED_ULE also exhibit the behaviour, but in lesser degree. Due to this, > I suspect that the problem in the common code. make -j16 buildworld on my 1.6ghz Pentium M does not disturb firefox or other interactive tasks at all. ULE has specific heuristics that penalize forking parents and return childrens interactivity history to them. This seems to work fairly well in practice. Looking through the other parts of this thread I see a mention of this problem being new between 6.2 and 7-CURRENT. I wonder if it has anything to do with increasing costs of gcc? It is often perceived as system slowdown when we upgrade gcc. It likely consumes more memory than before as well. The other likely culprit is some leftover giant code, especially the sound subsystem is subject to this I believe. schedgraph (/usr/src/tools/sched/schedgraph.py) was created for exactly this purpose, although it only sometimes works on multiprocessor machines due to tsc synchronization issues. It's worth trying however. There are instructions at the top of the file for gathering traces. You may send them to me if you'd like me to look at them. Or you can do some digging and install py-tkinter yourself. Thanks, Jeff > > Jeff, any suggestions ? > From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 20:37:21 2007 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 0BE3516A419; Tue, 28 Aug 2007 20:37:21 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id C959B13C45B; Tue, 28 Aug 2007 20:37:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5ECC8272CE; Tue, 28 Aug 2007 16:37:20 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 28 Aug 2007 16:37:20 -0400 X-Sasl-enc: W8inoUS2m9vK1hJKPdmSt1P+YXqUEV908iQTEjbUQfyn 1188333440 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id BBC306BC1; Tue, 28 Aug 2007 16:37:19 -0400 (EDT) Message-ID: <46D4877E.700@FreeBSD.org> Date: Tue, 28 Aug 2007 21:37:18 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20070828040026.GB42201@heff.fud.org.nz> <46D3C9F3.2010802@FreeBSD.org> <20070828135929.GA2305@sub.vaned.net> In-Reply-To: <20070828135929.GA2305@sub.vaned.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Andrew Thompson Subject: Re: multicast packets from bpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 20:37:21 -0000 Christian S.J. Peron wrote: > I think that tap(4) is a bit different since the only kind of frames it > handles are Ethernet. As Andrew points out the tapwrite check probably isn't needed now. > This is not the case for bpf(4). I wonder if it > makes sense to add this check into ether_output()? IIRC bpf will call > the network interface's output routine, in the Ethernet/bridge case it > should be ether_output(). > This approach avoids touching the device-independent paths, and, providing the check resides in the AF_UNSPEC case (as ARP resolution should do the right thing) is reasonably neat. But it doesn't handle the case where there are link-layer netgraph nodes between bpf and if_bridge, something which the first change would deal with. regards BMS From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 20:48:35 2007 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 47B3916A498; Tue, 28 Aug 2007 20:48:35 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 2399013C45A; Tue, 28 Aug 2007 20:48:35 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 9A7F85B3B; Tue, 28 Aug 2007 13:48:34 -0700 (PDT) To: Pawel Jakub Dawidek In-reply-to: Your message of "Tue, 28 Aug 2007 20:02:28 +0200." <20070828180228.GD39562@garage.freebsd.pl> Date: Tue, 28 Aug 2007 13:48:34 -0700 From: Bakul Shah Message-Id: <20070828204834.9A7F85B3B@mail.bitblocks.com> Cc: current@FreeBSD.org, Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 20:48:35 -0000 Pawel Jakub Dawidek wrote: > On Tue, Aug 28, 2007 at 10:02:42AM -0700, Bakul Shah wrote: > > > When you don't use redundant configuration (no mirror, no raidz, no > > > copies>1) then ZFS is going to panic on a write failure. It looks like > > > ZFS found a bad block on your disk. > > > > Does SUN really say this about ZFS? Is this acceptable in a > > production environment? What if one of your mirrored disk > > fails and in the "degraded" environment (before you have had > > a chance to replace the bad disk) ZFS discovers that a write > > fails? Why can't it find an alternative block to write to? > > There were many complains on zfs-discuss@, you may want to look into > archive. The short version is that many users doesn't like that, and it > should change in the future - because of COW model it should be quite > easy to just mark block as bad and take next one, but it's not currently > implemented. It's much less of a problem when one uses redundancy. Good to know others are complaining too :-) My real concern is the panic. This situation may be rare if using redundancy + regular scrubbing, but it can definitely occur. And as long as non redundant ZFS is *allowed*, you pretty much have to deal with it without any panicking. Originally panic() was used to indicate that some *system invariant* has been violated. That either meant a hardware error or an unknown software error but in any case some data structure was likely corrupted and continuing can make matters worse. But that is not the case here (in general). zfs does not have the appropriate information to be able to decide whether the write error is fatal. The simplest thing to do in case of a write error is to simply ignore it. You *will* catch this problem when you try to read this block. One step better is to do what you suggest. What happens now when you do use redundancy and there is a write error while writing one of the copies? Does the system panic or is this error ignored? From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 20:57:09 2007 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 B4E8616A419 for ; Tue, 28 Aug 2007 20:57:09 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 1260D13C46A for ; Tue, 28 Aug 2007 20:57:08 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 05E2445E91; Tue, 28 Aug 2007 22:57:07 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4F17F45683; Tue, 28 Aug 2007 22:57:01 +0200 (CEST) Date: Tue, 28 Aug 2007 22:55:55 +0200 From: Pawel Jakub Dawidek To: Bakul Shah Message-ID: <20070828205554.GI39562@garage.freebsd.pl> References: <20070828180228.GD39562@garage.freebsd.pl> <20070828204834.9A7F85B3B@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jaoouwwPWoQSJZYp" Content-Disposition: inline In-Reply-To: <20070828204834.9A7F85B3B@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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: current@FreeBSD.org, Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 20:57:09 -0000 --jaoouwwPWoQSJZYp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 01:48:34PM -0700, Bakul Shah wrote: > Pawel Jakub Dawidek wrote: > > On Tue, Aug 28, 2007 at 10:02:42AM -0700, Bakul Shah wrote: > > > > When you don't use redundant configuration (no mirror, no raidz, no > > > > copies>1) then ZFS is going to panic on a write failure. It looks l= ike > > > > ZFS found a bad block on your disk. > > > > > > Does SUN really say this about ZFS? Is this acceptable in a > > > production environment? What if one of your mirrored disk > > > fails and in the "degraded" environment (before you have had > > > a chance to replace the bad disk) ZFS discovers that a write > > > fails? Why can't it find an alternative block to write to? > >=20 > > There were many complains on zfs-discuss@, you may want to look into > > archive. The short version is that many users doesn't like that, and it > > should change in the future - because of COW model it should be quite > > easy to just mark block as bad and take next one, but it's not currently > > implemented. It's much less of a problem when one uses redundancy. >=20 > Good to know others are complaining too :-) >=20 > My real concern is the panic. This situation may be rare if > using redundancy + regular scrubbing, but it can definitely > occur. And as long as non redundant ZFS is *allowed*, you > pretty much have to deal with it without any panicking. >=20 > Originally panic() was used to indicate that some *system > invariant* has been violated. That either meant a hardware > error or an unknown software error but in any case some data > structure was likely corrupted and continuing can make > matters worse. But that is not the case here (in general). > zfs does not have the appropriate information to be able to > decide whether the write error is fatal. >=20 > The simplest thing to do in case of a write error is to > simply ignore it. You *will* catch this problem when you try > to read this block. One step better is to do what you > suggest. You can't ignore write error, because application already assumed the write succeeded, which can lead to misbehaviour later. ZFS cannot yet handle write error, so it panics to preserve data consistency. This is the good reaction on ZFS side until skipping bad blocks is not implemented. > What happens now when you do use redundancy and there is a > write error while writing one of the copies? Does the system > panic or is this error ignored? Don't remember off hand, but component is probably marked as bad and vdev group goes to degraded state. You can simulate this easly with gnop(8). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --jaoouwwPWoQSJZYp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1IvaForvXbEpPzQRAi20AKD3Ag5xU8Sauqi5CWQM72UdzByhZACgoQLK mZkoeg+REgUuqBhakNAVz8w= =kA5l -----END PGP SIGNATURE----- --jaoouwwPWoQSJZYp-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 20:57:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66A3616A418 for ; Tue, 28 Aug 2007 20:57:57 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (crsd-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2d5::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0CF3113C474 for ; Tue, 28 Aug 2007 20:57:55 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.1/8.14.1) with ESMTP id l7SKvf0a027304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 00:57:41 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Received: (from yuri@localhost) by darklight.org.ru (8.14.1/8.14.1/Submit) id l7SKvdvu027303; Wed, 29 Aug 2007 00:57:39 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Date: Wed, 29 Aug 2007 00:57:39 +0400 From: Yuri Pankov To: William Grzybowski Message-ID: <20070828205739.GD1338@darklight.org.ru> References: <632825b40708281315p7f0b059cu726ae13b89b38c6c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <632825b40708281315p7f0b059cu726ae13b89b38c6c@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: error building current kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 20:57:57 -0000 On Tue, Aug 28, 2007 at 05:15:56PM -0300, William Grzybowski wrote: > Hi, > > I am getting some errors about sctp while i build kernel from today... > Could it be happening because i created a src.conf file disablind bind, > ipv6, ipfilter, kerberos and sendmail ? (i dont think so, but it was the > only thing which i modified...) > > uipc_syscalls.o(.text+0x341): In function `sctp_generic_recvmsg': > /usr/src/sys/kern/uipc_syscalls.c:2600: undefined reference to > `sctp_sorecvmsg' > uipc_syscalls.o(.text+0x86c): In function `sctp_peeloff': > /usr/src/sys/kern/uipc_syscalls.c:2238: undefined reference to > `sctp_can_peel_of > f' > uipc_syscalls.o(.text+0xa7a):/usr/src/sys/kern/uipc_syscalls.c:2279: > undefined r > eference to `sctp_do_peeloff' > uipc_syscalls.o(.text+0xdf0): In function `sctp_generic_sendmsg_iov': > /usr/src/sys/kern/uipc_syscalls.c:2478: undefined reference to > `sctp_lower_sosen > d' > uipc_syscalls.o(.text+0x109a): In function `sctp_generic_sendmsg': > /usr/src/sys/kern/uipc_syscalls.c:2371: undefined reference to > `sctp_lower_sosen > d' > rtsock.o(.text+0x123b): In function `rt_newaddrmsg': > /usr/src/sys/net/rtsock.c:896: undefined reference to `sctp_addr_change' > in_proto.o(.data+0xa8): undefined reference to `sctp_input' > in_proto.o(.data+0xb0): undefined reference to `sctp_ctlinput' > in_proto.o(.data+0xb4): undefined reference to `sctp_ctloutput' > in_proto.o(.data+0xbc): undefined reference to `sctp_init' > in_proto.o(.data+0xc8): undefined reference to `sctp_drain' > in_proto.o(.data+0xcc): undefined reference to `sctp_usrreqs' > in_proto.o(.data+0xdc): undefined reference to `sctp_input' > in_proto.o(.data+0xe4): undefined reference to `sctp_ctlinput' > in_proto.o(.data+0xe8): undefined reference to `sctp_ctloutput' > in_proto.o(.data+0xfc): undefined reference to `sctp_drain' > in_proto.o(.data+0x100): undefined reference to `sctp_usrreqs' > in_proto.o(.data+0x110): undefined reference to `sctp_input' > in_proto.o(.data+0x118): undefined reference to `sctp_ctlinput' > in_proto.o(.data+0x11c): undefined reference to `sctp_ctloutput' > in_proto.o(.data+0x130): undefined reference to `sctp_drain' > in_proto.o(.data+0x134): undefined reference to `sctp_usrreqs' > *** Error code 1 > > > Bye. > > > -- > William Grzybowski > ------------------------------------------ > Jabber: william88 at gmail dot com > Msn: william.grz at hotmail dot com > Curitiba/PR - Brazil As you haven't provided your kernel config, please check if this thread looks related: http://lists.freebsd.org/pipermail/freebsd-net/2007-June/014515.html HTH, Yuri From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 21:14:40 2007 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 D089916A419; Tue, 28 Aug 2007 21:14:40 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id B04D413C4B6; Tue, 28 Aug 2007 21:14:40 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 470805B3B; Tue, 28 Aug 2007 14:14:40 -0700 (PDT) To: Pawel Jakub Dawidek In-reply-to: Your message of "Tue, 28 Aug 2007 22:55:55 +0200." <20070828205554.GI39562@garage.freebsd.pl> Date: Tue, 28 Aug 2007 14:14:40 -0700 From: Bakul Shah Message-Id: <20070828211440.470805B3B@mail.bitblocks.com> Cc: current@FreeBSD.org, Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 21:14:40 -0000 > > The simplest thing to do in case of a write error is to > > simply ignore it. You *will* catch this problem when you try > > to read this block. One step better is to do what you > > suggest. > > You can't ignore write error, because application already assumed the > write succeeded, which can lead to misbehaviour later. ZFS cannot yet > handle write error, so it panics to preserve data consistency. This is > the good reaction on ZFS side until skipping bad blocks is not > implemented. If you ignore a write error, the effect is the same as if the disk block was good on writing but went bad before the first read. Seems to me this is better than panicing (but of course not as good as finding an alternate block). AFAIK ZFS already uses redundancy for metadata so the metadata consistency will be maintained. > > What happens now when you do use redundancy and there is a > > write error while writing one of the copies? Does the system > > panic or is this error ignored? > > Don't remember off hand, but component is probably marked as bad and > vdev group goes to degraded state. You can simulate this easly with > gnop(8). Thanks. It would be good to add some ioctl to allow failing specific blocks on reads and/or writes. From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 21:24:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6CA016A418; Tue, 28 Aug 2007 21:24:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 37DBA13C467; Tue, 28 Aug 2007 21:24:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from dslb-088-066-017-000.pools.arcor-ip.net [88.66.17.0] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1IQ8Xf0nBz-0001J0; Tue, 28 Aug 2007 23:24:10 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 28 Aug 2007 23:23:56 +0200 User-Agent: KMail/1.9.7 References: <20070828211440.470805B3B@mail.bitblocks.com> In-Reply-To: <20070828211440.470805B3B@mail.bitblocks.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3085233.neSCxyxR4m"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708282324.05834.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18TR6WW72n0rJSuVCUVlrOVTK4IWhwl28mnsaL Hr9zB1ci5k6C3VE+RHujObFZ/QNshHnO1NUcPF5djhuxJUfJ1i bzG6Tsoyfagj6J4AkzoCT4eIL0qQZq/V3KcBICgVxI= Cc: Pawel Jakub Dawidek , Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 21:24:15 -0000 --nextPart3085233.neSCxyxR4m Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 28 August 2007, Bakul Shah wrote: > > > The simplest thing to do in case of a write error is to > > > simply ignore it. You *will* catch this problem when you try > > > to read this block. One step better is to do what you > > > suggest. > > > > You can't ignore write error, because application already assumed the > > write succeeded, which can lead to misbehaviour later. ZFS cannot yet > > handle write error, so it panics to preserve data consistency. This > > is the good reaction on ZFS side until skipping bad blocks is not > > implemented. > > If you ignore a write error, the effect is the same as if the > disk block was good on writing but went bad before the first > read. Seems to me this is better than panicing (but of > course not as good as finding an alternate block). This is complete nonsense! As you pointed out earlier zfs doesn't know=20 anything about the nature of the error. There is only one sensible way=20 to deal with a disk error - unless it is transient - and that is stopping=20 all (write) access to the drive. As you can't easily move a mounted=20 drive with opened files into read-only mode, a panic is the only way to=20 make sure. > AFAIK ZFS already uses redundancy for metadata so the > metadata consistency will be maintained. > > > > What happens now when you do use redundancy and there is a > > > write error while writing one of the copies? Does the system > > > panic or is this error ignored? > > > > Don't remember off hand, but component is probably marked as bad and > > vdev group goes to degraded state. You can simulate this easly with > > gnop(8). > > Thanks. It would be good to add some ioctl to allow failing > specific blocks on reads and/or writes. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3085233.neSCxyxR4m Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG1JJ1XyyEoT62BG0RApDpAJ4rMr/fCBTJKVwACyZmoptRATPPOwCeMqDC 6JOLk+6u4/idt694tRaVepA= =uE5+ -----END PGP SIGNATURE----- --nextPart3085233.neSCxyxR4m-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 21:26:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFCF216A419 for ; Tue, 28 Aug 2007 21:26:11 +0000 (UTC) (envelope-from william88@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.179]) by mx1.freebsd.org (Postfix) with ESMTP id 6195E13C465 for ; Tue, 28 Aug 2007 21:26:11 +0000 (UTC) (envelope-from william88@gmail.com) Received: by el-out-1112.google.com with SMTP id s27so455900ele for ; Tue, 28 Aug 2007 14:26:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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:references; b=JIGKmZ5xMBNJ9TCjdkfHzGTX2yzi03/FYDMGvhyMh+8ITBPGaZg2s+TUuHioftvXbYgtcHUOpm3CFITUhAcwfo3MzQGPlXuJTqPE6dSMfCS6OHsW+bVVGbm7EodBJ6X8+yyWZDCkXEKQbXLbx164M10+uqCv+c8rp1mpiMDttA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gDH94HcM3f6BKqDw0hbyEBfTukZA1m0QIt/M0C0X/c1TeE2PulGuSaaH0rvDKIpJnaSYJhgLcdtkxq/VZzobA22I2CY3vRyu/mKwzpyBE7PsDcYgNFvG85Xgv6DpLZs85IzIp0MhU/dnI5tP29gq3rtLDsmHiNUnN07et2wAM8o= Received: by 10.114.136.1 with SMTP id j1mr1033003wad.1188336369792; Tue, 28 Aug 2007 14:26:09 -0700 (PDT) Received: by 10.114.111.4 with HTTP; Tue, 28 Aug 2007 14:25:59 -0700 (PDT) Message-ID: <632825b40708281425t332f2563q643a3eae21cd9835@mail.gmail.com> Date: Tue, 28 Aug 2007 18:25:59 -0300 From: "William Grzybowski" To: "Yuri Pankov" In-Reply-To: <20070828205739.GD1338@darklight.org.ru> MIME-Version: 1.0 References: <632825b40708281315p7f0b059cu726ae13b89b38c6c@mail.gmail.com> <20070828205739.GD1338@darklight.org.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: error building current kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 21:26:11 -0000 On 8/28/07, Yuri Pankov wrote: > > On Tue, Aug 28, 2007 at 05:15:56PM -0300, William Grzybowski wrote: > > Hi, > > > > I am getting some errors about sctp while i build kernel from today... > > Could it be happening because i created a src.conf file disablind bind, > > ipv6, ipfilter, kerberos and sendmail ? (i dont think so, but it was the > > only thing which i modified...) > > > > uipc_syscalls.o(.text+0x341): In function `sctp_generic_recvmsg': > > /usr/src/sys/kern/uipc_syscalls.c:2600: undefined reference to > > `sctp_sorecvmsg' > > uipc_syscalls.o(.text+0x86c): In function `sctp_peeloff': > > /usr/src/sys/kern/uipc_syscalls.c:2238: undefined reference to > > `sctp_can_peel_of > > f' > > uipc_syscalls.o(.text+0xa7a):/usr/src/sys/kern/uipc_syscalls.c:2279: > > undefined r > > eference to `sctp_do_peeloff' > > uipc_syscalls.o(.text+0xdf0): In function `sctp_generic_sendmsg_iov': > > /usr/src/sys/kern/uipc_syscalls.c:2478: undefined reference to > > `sctp_lower_sosen > > d' > > uipc_syscalls.o(.text+0x109a): In function `sctp_generic_sendmsg': > > /usr/src/sys/kern/uipc_syscalls.c:2371: undefined reference to > > `sctp_lower_sosen > > d' > > rtsock.o(.text+0x123b): In function `rt_newaddrmsg': > > /usr/src/sys/net/rtsock.c:896: undefined reference to `sctp_addr_change' > > in_proto.o(.data+0xa8): undefined reference to `sctp_input' > > in_proto.o(.data+0xb0): undefined reference to `sctp_ctlinput' > > in_proto.o(.data+0xb4): undefined reference to `sctp_ctloutput' > > in_proto.o(.data+0xbc): undefined reference to `sctp_init' > > in_proto.o(.data+0xc8): undefined reference to `sctp_drain' > > in_proto.o(.data+0xcc): undefined reference to `sctp_usrreqs' > > in_proto.o(.data+0xdc): undefined reference to `sctp_input' > > in_proto.o(.data+0xe4): undefined reference to `sctp_ctlinput' > > in_proto.o(.data+0xe8): undefined reference to `sctp_ctloutput' > > in_proto.o(.data+0xfc): undefined reference to `sctp_drain' > > in_proto.o(.data+0x100): undefined reference to `sctp_usrreqs' > > in_proto.o(.data+0x110): undefined reference to `sctp_input' > > in_proto.o(.data+0x118): undefined reference to `sctp_ctlinput' > > in_proto.o(.data+0x11c): undefined reference to `sctp_ctloutput' > > in_proto.o(.data+0x130): undefined reference to `sctp_drain' > > in_proto.o(.data+0x134): undefined reference to `sctp_usrreqs' > > *** Error code 1 > > > > > > Bye. > > > > > > -- > > William Grzybowski > > ------------------------------------------ > > Jabber: william88 at gmail dot com > > Msn: william.grz at hotmail dot com > > Curitiba/PR - Brazil > > As you haven't provided your kernel config, please check if this thread > looks > related: > http://lists.freebsd.org/pipermail/freebsd-net/2007-June/014515.html Sorry, i forgot to send my conf... The build error was my mistake, i forgot that sctp needs INET6, even if you dont will use V6... My apologize :) Thanks. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 21:29:27 2007 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 430F216A417; Tue, 28 Aug 2007 21:29:27 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 49B6613C457; Tue, 28 Aug 2007 21:29:26 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 2FC7A1CC58; Wed, 29 Aug 2007 09:29:24 +1200 (NZST) Date: Wed, 29 Aug 2007 09:29:24 +1200 From: Andrew Thompson To: "Bruce M. Simpson" Message-ID: <20070828212924.GB43049@heff.fud.org.nz> References: <20070828040026.GB42201@heff.fud.org.nz> <46D3C9F3.2010802@FreeBSD.org> <20070828103110.GA43049@heff.fud.org.nz> <46D483F2.2040207@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <46D483F2.2040207@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Current Subject: Re: multicast packets from bpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 21:29:27 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 28, 2007 at 09:22:10PM +0100, Bruce M. Simpson wrote: > Andrew Thompson wrote: > >I had originally started to put it there but realised that I need a > >pointer to the ifnet to read if_broadcastaddr, I didnt think it was > >worth changing the function parameters when the check can also just go > >in bpfwrite. I dont mind moving it if its the more correct place to put > >it. > > > > It's already got a switch..case breakout for the DLTs and knows how to > grok the 802.11 header format which can have up to 6 (yes, 6) 802.3 > style MAC addresses, all of which mean different things depending on > whether you are STA, AP, Mesh Portal, Mesh AP... :-) > > So it seems like the right place. bpf_movein() is static and referenced > once within its translation unit, so it is a candidate for inlining; I > would change ifp-?if_mtu to ifp in the call. The patch has been updated (attached). > >Is the tapwrite patch still needed? The mbuf is passed to ether_input > >which should do the right thing. > > > > Good point. A casual reading suggests it *may* no longer be needed since > my pass over ether_input(), but seeing as we're due to branch and all, > I'll leave garbage collecting the 10 lines in tapwrite() to someone > else. :-) I would leave it there for the moment. Andrew --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bpf_mcast2.diff" Index: bpf.c =================================================================== RCS file: /home/ncvs/src/sys/net/bpf.c,v retrieving revision 1.180 diff -u -p -r1.180 bpf.c --- bpf.c 6 Aug 2007 14:26:00 -0000 1.180 +++ bpf.c 28 Aug 2007 21:22:59 -0000 @@ -102,7 +102,7 @@ static void bpf_attachd(struct bpf_d *, static void bpf_detachd(struct bpf_d *); static void bpf_freed(struct bpf_d *); static void bpf_mcopy(const void *, void *, size_t); -static int bpf_movein(struct uio *, int, int, struct mbuf **, +static int bpf_movein(struct uio *, int, struct ifnet *, struct mbuf **, struct sockaddr *, int *, struct bpf_insn *); static int bpf_setif(struct bpf_d *, struct ifreq *); static void bpf_timed_out(void *); @@ -158,10 +158,11 @@ static struct filterops bpfread_filtops { 1, NULL, filt_bpfdetach, filt_bpfread }; static int -bpf_movein(struct uio *uio, int linktype, int mtu, struct mbuf **mp, +bpf_movein(struct uio *uio, int linktype, struct ifnet *ifp, struct mbuf **mp, struct sockaddr *sockp, int *hdrlen, struct bpf_insn *wfilter) { const struct ieee80211_bpf_params *p; + struct ether_header *eh; struct mbuf *m; int error; int len; @@ -241,7 +242,7 @@ bpf_movein(struct uio *uio, int linktype len = uio->uio_resid; - if (len - hlen > mtu) + if (len - hlen > ifp->if_mtu) return (EMSGSIZE); if ((unsigned)len > MCLBYTES) @@ -273,6 +274,20 @@ bpf_movein(struct uio *uio, int linktype goto bad; } + /* Check for multicast destination */ + switch (linktype) { + case DLT_EN10MB: + eh = mtod(m, struct ether_header *); + if (ETHER_IS_MULTICAST(eh->ether_dhost)) { + if (bcmp(ifp->if_broadcastaddr, eh->ether_dhost, + ETHER_ADDR_LEN) == 0) + m->m_flags |= M_BCAST; + else + m->m_flags |= M_MCAST; + } + break; + } + /* * Make room for link header, and copy it to sockaddr */ @@ -615,7 +630,7 @@ bpfwrite(struct cdev *dev, struct uio *u bzero(&dst, sizeof(dst)); m = NULL; hlen = 0; - error = bpf_movein(uio, (int)d->bd_bif->bif_dlt, ifp->if_mtu, + error = bpf_movein(uio, (int)d->bd_bif->bif_dlt, ifp, &m, &dst, &hlen, d->bd_wfilter); if (error) return (error); --G4iJoqBmSsgzjUCe-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 21:47:28 2007 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 99D8C16A417; Tue, 28 Aug 2007 21:47:28 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6704E13C478; Tue, 28 Aug 2007 21:47:28 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id DB14526280; Tue, 28 Aug 2007 17:47:27 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 28 Aug 2007 17:47:27 -0400 X-Sasl-enc: ujUunqaN5YKavH4Ti9WCEHcZ8g1GyLYkI8iI4g1ZhWFP 1188337647 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 5841E6C41; Tue, 28 Aug 2007 17:47:27 -0400 (EDT) Message-ID: <46D497EE.9070904@FreeBSD.org> Date: Tue, 28 Aug 2007 22:47:26 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Andrew Thompson References: <20070828040026.GB42201@heff.fud.org.nz> <46D3C9F3.2010802@FreeBSD.org> <20070828103110.GA43049@heff.fud.org.nz> <46D483F2.2040207@FreeBSD.org> <20070828212924.GB43049@heff.fud.org.nz> In-Reply-To: <20070828212924.GB43049@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: multicast packets from bpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 21:47:28 -0000 Andrew Thompson wrote: > The patch has been updated (attached). > > Looks good. I hope csjp looks also in case I missed anything, bpf internals are currently unfamiliar territory for me. regards, BMS From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 21:50:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2A5D16A419 for ; Tue, 28 Aug 2007 21:50:54 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6B013C46C for ; Tue, 28 Aug 2007 21:50:54 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7SLWmPF090341; Tue, 28 Aug 2007 14:32:48 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7SLWmcT090340; Tue, 28 Aug 2007 14:32:48 -0700 (PDT) (envelope-from obrien) Date: Tue, 28 Aug 2007 14:32:48 -0700 From: "David O'Brien" To: Hans Petter Selasky Message-ID: <20070828213248.GC89132@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Hans Petter Selasky References: <200708270922.06233.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708270922.06233.hselasky@c2i.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: Ports and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Tue, 28 Aug 2007 21:50:55 -0000 On Mon, Aug 27, 2007 at 09:22:05AM +0200, Hans Petter Selasky wrote: > When you install a port that has several sub-ports, is there way to run > through all the configuration menus recursivly, so that the compilation does > not stop all the time asking for user input? Hi, This is purely a ports question, it isn't freebsd-current specific. Please ask this type of question at freebsd-ports@freebsd.org. thanks, -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 21:51:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0558716A468 for ; Tue, 28 Aug 2007 21:51:37 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id D036513C4CA for ; Tue, 28 Aug 2007 21:51:36 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7SLUjJX090290; Tue, 28 Aug 2007 14:30:45 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7SLUiUW090289; Tue, 28 Aug 2007 14:30:44 -0700 (PDT) (envelope-from obrien) Date: Tue, 28 Aug 2007 14:30:44 -0700 From: "David O'Brien" To: Danny Braniss Message-ID: <20070828213044.GB89132@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Danny Braniss , Rong-en Fan , freebsd-current@freebsd.org, LI Xin References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: LI Xin , freebsd-current@freebsd.org, Rong-en Fan Subject: Re: -current cross compile for -stable 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: Tue, 28 Aug 2007 21:51:37 -0000 On Tue, Aug 28, 2007 at 12:19:42PM +0300, Danny Braniss wrote: > > On 8/28/07, LI Xin wrote: > > > Danny Braniss wrote: > > > > till now I used a stable box to cross compile for other > > > > arch/stable|current. today i decided to try out -current as a > > > > base to cross compile. does it work? since i get: > > > > > > > > export MAKEOBJDIRPREFIX=/r+d/obj/cs4 > > > > cd /r+d/6.2/src; make TARGET_ARCH=amd64 buildworld > > > > ... > > > This won't work. In order to build -STABLE you have to install a > > > chrooted RELENG_6 environment and chroot into it to make it work. > > > > I think there is a hack for ports' tinderbox, patch is at > > http://www.marcuscom.com/downloads/binutils.diff > > Not sure it appears in ports@ mailing or tinderbox's. > > well, I can confirm that it works. 1)I'm now testing the result > by using the result to make buildworld - goto 1 :-). > > so, if it works for tinderbox, and for me, can it be 'installed'? There's no reason to - if you want to build RELENG_6 on a 7.x box, you should have RELENG_6 chroot to do so. You'll just keep running into problems as we don't support builds the way you're trying. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 23:22:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9935116A417; Tue, 28 Aug 2007 23:22:52 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6C513C459; Tue, 28 Aug 2007 23:22:51 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls248.t-com.hr (ls248.t-com.hr [195.29.150.237]) by ls405.t-com.hr (Postfix) with ESMTP id ADAC1145CE9; Wed, 29 Aug 2007 01:01:31 +0200 (CEST) Received: from ls248.t-com.hr (localhost.localdomain [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id A9BC1D5004A; Wed, 29 Aug 2007 01:01:31 +0200 (CEST) Received: from ls248.t-com.hr (localhost.localdomain [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id 8E7D1D50047; Wed, 29 Aug 2007 01:01:31 +0200 (CEST) X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.100] (78-1-125-103.adsl.net.t-com.hr [78.1.125.103]) by ls248.t-com.hr (Qmali) with ESMTP id 489375E0039; Wed, 29 Aug 2007 01:01:31 +0200 (CEST) Message-ID: <46D4A944.5060300@fer.hr> Date: Wed, 29 Aug 2007 01:01:24 +0200 From: Ivan Voras User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Anderson References: <200708261948.05750.qpadla@gmail.com> <46D41DAE.5010501@freebsd.org> In-Reply-To: <46D41DAE.5010501@freebsd.org> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig415AB1BAA53F0FBC8C058D0D" Cc: freebsd-current@freebsd.org Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 23:22:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig415AB1BAA53F0FBC8C058D0D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eric Anderson wrote: > By any chance, are there some oddly named directories? I found that UF= S > will panic with a ufs_dirbad if there are some strange chars in the dir= > name. My directories were copied with rsync, from one UFS partition to= > another. It could be the way rsync translated it or the way UFS sent i= t > to rsync during read, I'm not certain. I still have the bad file I don't think so, except if make installworld generates such filenames, which I don't think it does. > system, corresponding core file, etc. I even ran fsdb on the fs to > track down the offending directory, and I think I found it. Of course,= > I could rename it in fsdb, but that would remove my test case. I > stopped debugging it when I got busy, but if there is an interested > person willing to help be with some debug ideas, I can go back into it.= On a tangent: has somebody found a way to debug panics from X11 - i.e. when I detect a panic with the telltale sign that everything including the mouse stops working, can I reset the video mode from the kernel debugger (typing blind) and proceed to use the debugger? --------------enig415AB1BAA53F0FBC8C058D0D 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 iD8DBQFG1KlKldnAQVacBcgRAkbxAJ4++2lqkRvm6o52uydnwrDhIT0PJACglbFh 2wzfr9v7XEg5li9YgcmK0E0= =/ShK -----END PGP SIGNATURE----- --------------enig415AB1BAA53F0FBC8C058D0D-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 00:06:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C84F216A468 for ; Wed, 29 Aug 2007 00:06:30 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from hurl.ugcs.caltech.edu (hurl.ugcs.caltech.edu [131.215.176.101]) by mx1.freebsd.org (Postfix) with ESMTP id 76B7113C461 for ; Wed, 29 Aug 2007 00:05:51 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by hurl.ugcs.caltech.edu (Postfix, from userid 3640) id 9A80A1C3C65; Tue, 28 Aug 2007 17:05:51 -0700 (PDT) Date: Tue, 28 Aug 2007 17:05:51 -0700 From: Paul Allen To: Max Laier Message-ID: <20070829000551.GC13200@hurl.ugcs.caltech.edu> References: <20070828211440.470805B3B@mail.bitblocks.com> <200708282324.05834.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708282324.05834.max@love2party.net> Sender: jd@ugcs.caltech.edu Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek , Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 00:06:30 -0000 >From Max Laier , Tue, Aug 28, 2007 at 11:23:56PM +0200: > drive with opened files into read-only mode, a panic is the only way to > make sure. No. The kernel may signal EIO to any subsequent operation. In addition even such aggressive action is not required, let alone a panic: UFS does not behave this way. Accesses to uncorrupted sections of a drive usually proceed normally. Please be careful with statements such as "the only way"--especially when the way you describe is demonstrably bad. From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 00:27:03 2007 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 5B6FA16A41A; Wed, 29 Aug 2007 00:27:03 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from hurl.ugcs.caltech.edu (hurl.ugcs.caltech.edu [131.215.176.101]) by mx1.freebsd.org (Postfix) with ESMTP id 3E2FD13C467; Wed, 29 Aug 2007 00:27:03 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by hurl.ugcs.caltech.edu (Postfix, from userid 3640) id 688DF1C3BB3; Tue, 28 Aug 2007 16:57:51 -0700 (PDT) Date: Tue, 28 Aug 2007 16:57:51 -0700 From: Paul Allen To: Pawel Jakub Dawidek Message-ID: <20070828235751.GB13200@hurl.ugcs.caltech.edu> References: <20070828180228.GD39562@garage.freebsd.pl> <20070828204834.9A7F85B3B@mail.bitblocks.com> <20070828205554.GI39562@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070828205554.GI39562@garage.freebsd.pl> Sender: jd@ugcs.caltech.edu Cc: current@freebsd.org, Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 00:27:03 -0000 >From Pawel Jakub Dawidek , Tue, Aug 28, 2007 at 10:55:55PM +0200: > You can't ignore write error, because application already assumed the > write succeeded, which can lead to misbehaviour later. ZFS cannot yet What !?! I suggest you man 2 fsync. fsync should return EIO if any write in the past has failed. No program should make assumptions based on a successful return of write(2). Granted, many do; but applications where it really matters properly do fsync(2). From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 01:03:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E9A216A417 for ; Wed, 29 Aug 2007 01:03:36 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp807.mail.ird.yahoo.com (smtp807.mail.ird.yahoo.com [217.146.188.67]) by mx1.freebsd.org (Postfix) with SMTP id A304513C428 for ; Wed, 29 Aug 2007 01:03:35 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 32795 invoked from network); 29 Aug 2007 01:03:34 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.140.28.215 with plain) by smtp807.mail.ird.yahoo.com with SMTP; 29 Aug 2007 01:03:34 -0000 X-YMail-OSG: et5D4g4VM1nFDBvxAlTI1UrhE8UpGth96BdTI3Ah8ztNgL30 Message-ID: <46D4D421.90602@tomjudge.com> Date: Wed, 29 Aug 2007 03:04:17 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Ivan Voras References: <200708261948.05750.qpadla@gmail.com> <46D41DAE.5010501@freebsd.org> <46D4A944.5060300@fer.hr> In-Reply-To: <46D4A944.5060300@fer.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 01:03:36 -0000 Ivan Voras wrote: > Eric Anderson wrote: > >> By any chance, are there some oddly named directories? I found that UFS >> will panic with a ufs_dirbad if there are some strange chars in the dir >> name. My directories were copied with rsync, from one UFS partition to >> another. It could be the way rsync translated it or the way UFS sent it >> to rsync during read, I'm not certain. I still have the bad file > > I don't think so, except if make installworld generates such filenames, > which I don't think it does. > >> system, corresponding core file, etc. I even ran fsdb on the fs to >> track down the offending directory, and I think I found it. Of course, >> I could rename it in fsdb, but that would remove my test case. I >> stopped debugging it when I got busy, but if there is an interested >> person willing to help be with some debug ideas, I can go back into it. > > On a tangent: has somebody found a way to debug panics from X11 - i.e. > when I detect a panic with the telltale sign that everything including > the mouse stops working, can I reset the video mode from the kernel > debugger (typing blind) and proceed to use the debugger? > > It would be easier to attach a serial console to the system, even if it is in the form of a second machine and null modem cable. The handbook will hold your had if you want to try setting it up. Tom From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 01:24:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60F0A16A417 for ; Wed, 29 Aug 2007 01:24:00 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id EB98C13C469 for ; Wed, 29 Aug 2007 01:23:59 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-93-75.lns10.adl6.internode.on.net [121.45.93.75]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l7T1NrHN056481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 10:53:54 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 29 Aug 2007 10:53:34 +0930 User-Agent: KMail/1.9.7 References: <46D4A944.5060300@fer.hr> <46D4D421.90602@tomjudge.com> In-Reply-To: <46D4D421.90602@tomjudge.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13060345.gq7MuVmtSM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708291053.43115.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: Tom Judge , Ivan Voras Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 01:24:00 -0000 --nextPart13060345.gq7MuVmtSM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 29 Aug 2007, Tom Judge wrote: > It would be easier to attach a serial console to the system, even if > it is in the form of a second machine and null modem cable. The > handbook will hold your had if you want to try setting it up. Or firewire.. can be more common than real serial ports on modern=20 systems :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart13060345.gq7MuVmtSM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG1Mqf5ZPcIHs/zowRAlQwAJ4rSICkQBAtZdn9Wnij3uQ4X+l6YQCfYkn9 h2yP7IhPVb6D9AwCFvX7pfA= =u3Bk -----END PGP SIGNATURE----- --nextPart13060345.gq7MuVmtSM-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 15:53:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47C5316A469 for ; Tue, 28 Aug 2007 15:53:09 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.de [194.25.134.80]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1CB13C491 for ; Tue, 28 Aug 2007 15:53:09 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from fwd26.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1IQ2nf-0004P7-02; Tue, 28 Aug 2007 17:16:15 +0200 Received: from localhost (VskOVMZbges0QCBkcumkXGaToB+IA4FCCoGkWuxLwk4lRKXK8HFFYs@[84.165.82.77]) by fwd26.t-online.de with esmtp id 1IQ2nQ-0jDieu0; Tue, 28 Aug 2007 17:16:00 +0200 Date: Tue, 28 Aug 2007 17:15:59 +0200 From: Oliver Herold To: freebsd-current@freebsd.org Message-ID: <20070828151559.GB58223@olymp.home> References: <601594.86521.qm@web35214.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <601594.86521.qm@web35214.mail.mud.yahoo.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-ID: VskOVMZbges0QCBkcumkXGaToB+IA4FCCoGkWuxLwk4lRKXK8HFFYs X-TOI-MSGID: 00dfd69d-6c7d-4847-accc-5326be664822 X-Mailman-Approved-At: Wed, 29 Aug 2007 01:58:03 +0000 Subject: Re: Can I use FreeBSD-current?? (sony vaio hardware) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 15:53:09 -0000 Hi using FreeBSD 6.2 stable would be a nice idea too. 1)no problem at all, I'm using a Core2Duo at my laptop 2)depends on ACPI in your bios 3)is possible with IWI driver http://www.freebsd.org/cgi/man.cgi?query=iwi&apropos=0&sektion=0&manpath=FreeBSD+6.2-stable&format=html 4)this depends on your bios, but there is a module called acpi_sony and acpi_video in /boot/kernel http://www.freebsd.org/cgi/man.cgi?query=acpi_sony&apropos=0&sektion=0&manpath=FreeBSD+6.2-stable&format=html Cheers, Oliver On Tue, Aug 28, 2007 at 07:34:42AM -0700, Shane Helms wrote: > Hi, > > I installed FreeBSD-6.2R several days ago soon to > realize that my sound card is not supported :-( > Now, I'd like to install FreeBSD-Current, but I > thought I'd send a quick email for hardware checking > before I jump into snapshots. > > Sadly, very little information about FreeBSD-7 can be > found on the net. My hardware is Sony Vaio FJ170/B > (FJ1S/W) laptop. Please let me know if you have > experience with any of the following: > > 1. CPU frequency scaling for Intel(R) Pentium(R) M > processor 1.73GHz (centrino). > > 2. Hibernate / Standby support for Intel Corporation > Mobile 915GM chipset > > 3. Wireless with an Intel Corporation PRO/Wireless > 2200BG card > > 4. Sony ACPI support for screen brightness adjustment > > Thanks, > Shane > > > ____________________________________________________________________________________ > Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. > http://autos.yahoo.com/green_center/ > _______________________________________________ > 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" > -- Many are called, few are chosen. Fewer still get to do the choosing. From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 22:22:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A186716A468 for ; Tue, 28 Aug 2007 22:22:26 +0000 (UTC) (envelope-from michel@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 350C013C46A for ; Tue, 28 Aug 2007 22:22:25 +0000 (UTC) (envelope-from michel@lpthe.jussieu.fr) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id l7SLX9Oa086410 for ; Tue, 28 Aug 2007 23:33:09 +0200 (CEST) X-Ids: 164 Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) by parthe.lpthe.jussieu.fr (Postfix) with ESMTP id 7DA07236FDA for ; Tue, 28 Aug 2007 23:33:08 +0200 (CEST) Received: by niobe.lpthe.jussieu.fr (Postfix, from userid 2005) id 569B680; Tue, 28 Aug 2007 23:33:08 +0200 (CEST) Date: Tue, 28 Aug 2007 23:33:08 +0200 From: Michel Talon To: freebsd-current@freebsd.org Message-ID: <20070828213308.GA18553@lpthe.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.164]); Tue, 28 Aug 2007 23:33:09 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.7/4089/Tue Aug 28 22:45:06 2007 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 46D49495.004 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Mailman-Approved-At: Wed, 29 Aug 2007 01:58:03 +0000 Subject: Re: Can I use FreeBSD-current?? (sony vaio hardware) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2007 22:22:26 -0000 > Sadly, very little information about FreeBSD-7 can be > found on the net. My hardware is Sony Vaio FJ170/B > (FJ1S/W) laptop. Please let me know if you have > experience with any of the following: > > 1. CPU frequency scaling for Intel(R) Pentium(R) M > processor 1.73GHz (centrino). > > 2. Hibernate / Standby support for Intel Corporation > Mobile 915GM chipset > > 3. Wireless with an Intel Corporation PRO/Wireless > 2200BG card > > 4. Sony ACPI support for screen brightness adjustment I have a recent Sony Vaio (VGN-C1) running under 6.2 RELEASE First note that sound works very well with the binary snd_hda from Ariff Abdullah. http://people.freebsd.org/~ariff/lowlatency/ 1) seems to work 2) doesn't work at all. Even halt -p hangs before shutting down the computer. I have tried a recent CURRENT, does the same. Once i got in the debugger, the machine apparently hanged while powering down the pccard controller. 3) works with Damien Bergamini driver 20070121-wpi-freebsd but maybe produces memory corruption (tolerable ...) 4) works with kernel module acpi_sony. Only needs to tweak a sysctl to adjust screen brightness, the keyboard key is not recognized. The worse problem is ACPI, it doesn't work OK with Ubuntu either. All in one, and despite memory corruption with Intel wireless the laptop works better with FreeBSD than Ubuntu for me. -- Michel TALON From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 02:46:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 342FB16A41B for ; Wed, 29 Aug 2007 02:46:29 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id DEADE13C467 for ; Wed, 29 Aug 2007 02:46:28 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 0394BEB31DF; Wed, 29 Aug 2007 10:46:28 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id HuxST4owUSqu; Wed, 29 Aug 2007 10:46:18 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 586B7EB0E44; Wed, 29 Aug 2007 10:46:18 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=edlZJVqx7YH/DxcOxW5daKeae4+rpmWQ8pbgt+gIG1pffJsNprtBEyY++3P6wTMdM /nxknP8EH/ymsoF/KCwUA== Message-ID: <46D4DDEF.8010401@delphij.net> Date: Wed, 29 Aug 2007 10:46:07 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Rong-en Fan References: <46D37727.6010003@delphij.net> <6eb82e0708272136m3511318egbbdb9d2114e5c0f7@mail.gmail.com> In-Reply-To: <6eb82e0708272136m3511318egbbdb9d2114e5c0f7@mail.gmail.com> X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigDE1458B22E58F649F483F50D" Cc: freebsd-current@freebsd.org, d@delphij.net Subject: Re: -current cross compile for -stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 02:46:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDE1458B22E58F649F483F50D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rong-en Fan wrote: [...] >> This won't work. In order to build -STABLE you have to install a >> chrooted RELENG_6 environment and chroot into it to make it work. >=20 > I think there is a hack for ports' tinderbox, patch is at >=20 > http://www.marcuscom.com/downloads/binutils.diff >=20 > Not sure it appears in ports@ mailing or tinderbox's. Well, I think the real problem is that our 'make buildworld' process is not very well self-contained. I hit this a lot of times, sed, kldxref, etc. and we add them to bootstrap tools :-) The binutils hack can work at this moment, but it is not guaranteed if one day we changed something else... Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigDE1458B22E58F649F483F50D 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.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1N3vOfuToMruuMARCpVZAJwNNagElAneRI3uQjsEPvuWZxaUNwCggq5v 4CjVitTadC6KClBbMbYRA38= =YwtG -----END PGP SIGNATURE----- --------------enigDE1458B22E58F649F483F50D-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 04:03:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF8E16A418 for ; Wed, 29 Aug 2007 04:03:15 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id B8F6F13C465 for ; Wed, 29 Aug 2007 04:03:15 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IQEls-0008Pn-9A for ; Wed, 29 Aug 2007 13:03:12 +0900 Message-ID: <46D4EFFF.5080807@fusiongol.com> Date: Wed, 29 Aug 2007 13:03:11 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: Re: Encrypted 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: Wed, 29 Aug 2007 04:03:15 -0000 Yep, using GELI the providers is much better. I decided to go one step further and run GLABEL on my drives so my ZFS pool will be immune from device enumeration issues (assuming I move the drives between systems, SATA raid cards, etc.) The only thing that sucks is that once I have attached all GELI providers, I have to manually kickstart zfs and mount the pool with the following commands:- # kldload zfs # zfs volinit # zfs mount -a pool: z state: ONLINE scrub: resilver completed with 0 errors on Wed Aug 29 12:23:52 2007 config: NAME STATE READ WRITE CKSUM z ONLINE 0 0 0 raidz1 ONLINE 0 0 0 label/0.eli ONLINE 0 0 0 label/1.eli ONLINE 0 0 0 label/2.eli ONLINE 0 0 0 label/3.eli ONLINE 0 0 0 errors: No known data errors One thing I also tried was replacing a drive with a much larger one using zpool replace. ZFS didn't notice the larger disk capacity of the new drive and subsequently didn't increase the pool size. What is the logic behind that? From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 04:18:29 2007 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 5A2E616A418 for ; Wed, 29 Aug 2007 04:18:29 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4D53013C465 for ; Wed, 29 Aug 2007 04:18:29 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l7T4HwAg008560; Tue, 28 Aug 2007 21:17:59 -0700 (PDT) Date: Wed, 29 Aug 2007 10:52:23 +0900 Message-ID: From: gnn@freebsd.org To: "Pawel Worach" In-Reply-To: References: <46D2EB88.7020905@gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org Subject: Re: IPSec panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 04:18:29 -0000 At Tue, 28 Aug 2007 16:03:09 +0200, Pawel Worach wrote: > > On 8/28/07, gnn@freebsd.org wrote: > > At Mon, 27 Aug 2007 17:19:36 +0200, > > Pawel Worach wrote: > > > > > > Hi, > > > > > > While testing IPSec I got this panic on two different -CURRENT systems. > > > I think they happened when racoon was updating the SAD. kernel.debug and > > > vmcore is still available if more info needed. > > > > > > > Given the backtraces you showed I didnt' see any IPsec related code > > being run. Did I miss something? > > > > Come to think of it.. this case was that I had a ssh session to the > peer when there was no policy loaded and the peer paniced when setkey > -f ipsec.conf was executed so the existing connection now suddenly > would require IPSec. Am I making any sense at all ? > Well, I think we need to tease the issues apart. I have your report of an infinite loop in esp6_ctlinput and I will look at that. I am hoping someone else will look at the first error you posted which seems to point to issues in other parts of the system. Best, George From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 05:14:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F4D16A46D for ; Wed, 29 Aug 2007 05:14:37 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id AE46413C459 for ; Wed, 29 Aug 2007 05:14:36 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l7R8UK3f028499; Mon, 27 Aug 2007 10:30:22 +0200 (MEST) Message-ID: <46D28858.80901@fer.hr> Date: Mon, 27 Aug 2007 10:16:24 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Jan Mikkelsen References: <004f01c7e86a$b78088a0$268199e0$@com> In-Reply-To: <004f01c7e86a$b78088a0$268199e0$@com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 05:14:37 -0000 Jan Mikkelsen wrote: > Is this an SMP or uniprocessor virtual machine? SMP kernel on a UP VM. > I see frequent "signal 11" failures from gcc when putting an SMP > virtual machine under load. The same load on a uniprocessor > virtual machine works fine. This is 6.2-STABLE; I haven't tried > -CURRENT. VMware Server 1.0.3, AMD-X2, ECC memory, Windows XP > 64-bit host. My configuration is "plain" - 32-bit guest on a 32-bit WinXP host. I'll add that I've been running 6.x in this way for a long time without problems (I think I even tried SMP VM one time with 6.x, but decided it was not worth it). From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 06:00:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF0A816A480 for ; Wed, 29 Aug 2007 06:00:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id AEA8713C45D for ; Wed, 29 Aug 2007 06:00:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1IQGbZ-000Eoo-Pm; Wed, 29 Aug 2007 09:00:41 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: obrien@freebsd.org In-reply-to: <20070828213044.GB89132@dragon.NUXI.org> References: <20070828213044.GB89132@dragon.NUXI.org> Comments: In-reply-to "David O'Brien" message dated "Tue, 28 Aug 2007 14:30:44 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Aug 2007 09:00:41 +0300 From: Danny Braniss Message-ID: Cc: LI Xin , freebsd-current@freebsd.org, Rong-en Fan Subject: Re: -current cross compile for -stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 06:00:45 -0000 > On Tue, Aug 28, 2007 at 12:19:42PM +0300, Danny Braniss wrote: > > > On 8/28/07, LI Xin wrote: > > > > Danny Braniss wrote: > > > > > till now I used a stable box to cross compile for other > > > > > arch/stable|current. today i decided to try out -current as a > > > > > base to cross compile. does it work? since i get: > > > > > > > > > > export MAKEOBJDIRPREFIX=/r+d/obj/cs4 > > > > > cd /r+d/6.2/src; make TARGET_ARCH=amd64 buildworld > > > > > ... > > > > This won't work. In order to build -STABLE you have to install a > > > > chrooted RELENG_6 environment and chroot into it to make it work. > > > > > > I think there is a hack for ports' tinderbox, patch is at > > > http://www.marcuscom.com/downloads/binutils.diff > > > Not sure it appears in ports@ mailing or tinderbox's. > > > > well, I can confirm that it works. 1)I'm now testing the result > > by using the result to make buildworld - goto 1 :-). > > > > so, if it works for tinderbox, and for me, can it be 'installed'? > > There's no reason to - if you want to build RELENG_6 on a 7.x box, you > should have RELENG_6 chroot to do so. You'll just keep running into > problems as we don't support builds the way you're trying. one of the things that attracted me to FreeBSD was the fact that I could cross-compile. I always, till now, used a RELENG as a base (solid? :-) to build CURRENT, but now, so close to releases, I decided to try the other way, just before upgrading. So now I have some questions: - Is documented != supported? - is building on a RELENG for CURRRENT ok? danny From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 06:17:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2EFA16A418 for ; Wed, 29 Aug 2007 06:17:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 8894F13C468 for ; Wed, 29 Aug 2007 06:17:20 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 54C45EB3281; Wed, 29 Aug 2007 14:17:19 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id PE-hhrcarcIM; Wed, 29 Aug 2007 14:17:11 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 8AE25EB30C0; Wed, 29 Aug 2007 14:17:11 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=skoM851wuVYD4jIqR102kRfpCJ6cTEDQ5mNZF9zsAZoF+N/9GfGV8yndDDm15+85I VCeNJA2M4eurUWadJpT2A== Message-ID: <46D50F5E.6010505@delphij.net> Date: Wed, 29 Aug 2007 14:17:02 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Danny Braniss References: <20070828213044.GB89132@dragon.NUXI.org> In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig48F6C2E304EEEC8358233324" Cc: freebsd-current@freebsd.org, Rong-en Fan Subject: Re: -current cross compile for -stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 06:17:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig48F6C2E304EEEC8358233324 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Danny Braniss wrote: >> On Tue, Aug 28, 2007 at 12:19:42PM +0300, Danny Braniss wrote: >>>> On 8/28/07, LI Xin wrote: >>>>> Danny Braniss wrote: >>>>>> till now I used a stable box to cross compile for other >>>>>> arch/stable|current. today i decided to try out -current as a >>>>>> base to cross compile. does it work? since i get: >>>>>> >>>>>> export MAKEOBJDIRPREFIX=3D/r+d/obj/cs4 >>>>>> cd /r+d/6.2/src; make TARGET_ARCH=3Damd64 buildworld >>>>>> ... >>>>> This won't work. In order to build -STABLE you have to install a >>>>> chrooted RELENG_6 environment and chroot into it to make it work. >>>> I think there is a hack for ports' tinderbox, patch is at >>>> http://www.marcuscom.com/downloads/binutils.diff >>>> Not sure it appears in ports@ mailing or tinderbox's. >>> well, I can confirm that it works. 1)I'm now testing the result >>> by using the result to make buildworld - goto 1 :-). >>> >>> so, if it works for tinderbox, and for me, can it be 'installed'? >> There's no reason to - if you want to build RELENG_6 on a 7.x box, you= >> should have RELENG_6 chroot to do so. You'll just keep running into >> problems as we don't support builds the way you're trying. >=20 > one of the things that attracted me to FreeBSD was the fact that I coul= d=20 > cross-compile. I always, till now, used a RELENG as a base (solid? :-) = to > build CURRENT, but now, so close to releases, I decided to try the othe= r way, > just before upgrading. >=20 > So now I have some questions: > - Is documented !=3D supported? > - is building on a RELENG for CURRRENT ok? I think there is some misunderstanding. The supported way is to "upgrade", means to compile -CURRENT for instance, from a RELENG base; the reverse, however, is not well "supported". The "official" way to cross compile older sources on a newer world is to create a chroot environment. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig48F6C2E304EEEC8358233324 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.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1Q9eOfuToMruuMARCnb5AJoDDcYp2jUkbWp69NIrsr2OxGUgjgCfSvSy Tx9ysfEGfg1Z5Z9LyaXtJ6w= =p1yH -----END PGP SIGNATURE----- --------------enig48F6C2E304EEEC8358233324-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 07:09:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3FA916A417; Wed, 29 Aug 2007 07:09:28 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id B1C1213C467; Wed, 29 Aug 2007 07:09:28 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1IQHfp-000FUu-KK; Wed, 29 Aug 2007 10:09:09 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: d@delphij.net In-reply-to: <46D50F5E.6010505@delphij.net> References: <20070828213044.GB89132@dragon.NUXI.org> <46D50F5E.6010505@delphij.net> Comments: In-reply-to LI Xin message dated "Wed, 29 Aug 2007 14:17:02 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Aug 2007 10:09:09 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org, Rong-en Fan Subject: Re: -current cross compile for -stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 07:09:29 -0000 > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig48F6C2E304EEEC8358233324 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Danny Braniss wrote: > >> On Tue, Aug 28, 2007 at 12:19:42PM +0300, Danny Braniss wrote: > >>>> On 8/28/07, LI Xin wrote: > >>>>> Danny Braniss wrote: > >>>>>> till now I used a stable box to cross compile for other > >>>>>> arch/stable|current. today i decided to try out -current as a > >>>>>> base to cross compile. does it work? since i get: > >>>>>> > >>>>>> export MAKEOBJDIRPREFIX=3D/r+d/obj/cs4 > >>>>>> cd /r+d/6.2/src; make TARGET_ARCH=3Damd64 buildworld > >>>>>> ... > >>>>> This won't work. In order to build -STABLE you have to install a > >>>>> chrooted RELENG_6 environment and chroot into it to make it work. > >>>> I think there is a hack for ports' tinderbox, patch is at > >>>> http://www.marcuscom.com/downloads/binutils.diff > >>>> Not sure it appears in ports@ mailing or tinderbox's. > >>> well, I can confirm that it works. 1)I'm now testing the result > >>> by using the result to make buildworld - goto 1 :-). > >>> > >>> so, if it works for tinderbox, and for me, can it be 'installed'? > >> There's no reason to - if you want to build RELENG_6 on a 7.x box, you= > > >> should have RELENG_6 chroot to do so. You'll just keep running into > >> problems as we don't support builds the way you're trying. > >=20 > > one of the things that attracted me to FreeBSD was the fact that I coul= > d=20 > > cross-compile. I always, till now, used a RELENG as a base (solid? :-) = > to > > build CURRENT, but now, so close to releases, I decided to try the othe= > r way, > > just before upgrading. > >=20 > > So now I have some questions: > > - Is documented !=3D supported? > > - is building on a RELENG for CURRRENT ok? > > I think there is some misunderstanding. The supported way is to > "upgrade", means to compile -CURRENT for instance, from a RELENG base; > the reverse, however, is not well "supported". The "official" way to > cross compile older sources on a newer world is to create a chroot > environment. (I think I also have to upgrade my MUA) ok, I'ts clearer now, and I understand the logic, one has to build the 1st floor before building the 2nd. etc, etc. but the other way, backward compatability, would have been nice too. in any case, it's solved - for the time being, for me. cheers, danny anyways, thanks. From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 07:35:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 319E316A41A; Wed, 29 Aug 2007 07:35:57 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id AC04813C45B; Wed, 29 Aug 2007 07:35:56 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l7T7ZouL037805; Wed, 29 Aug 2007 11:35:50 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 29 Aug 2007 11:35:50 +0400 (MSD) From: Dmitry Morozovsky To: Pawel Jakub Dawidek In-Reply-To: <20070828175402.GB39562@garage.freebsd.pl> Message-ID: <20070829113209.C1528@woozle.rinet.ru> References: <46D2C812.8090106@gmail.com> <20070828104625.GB36596@garage.freebsd.pl> <46D40833.2030007@barafranca.com> <20070828175402.GB39562@garage.freebsd.pl> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Wed, 29 Aug 2007 11:35:50 +0400 (MSD) Cc: freebsd-current@freebsd.org, Hugo Silva Subject: Re: Encrypted 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: Wed, 29 Aug 2007 07:35:57 -0000 On Tue, 28 Aug 2007, Pawel Jakub Dawidek wrote: PJD> On Tue, Aug 28, 2007 at 12:34:11PM +0100, Hugo Silva wrote: PJD> > How's the performance on the geli-backed pool ? PJD> PJD> It depends a lot on CPU speed, but you should be ready for visible PJD> performance drop. I'll give you two examples: [examples snipped] PJD> But don't you worry, when you must have encryption, you don't really PJD> care about performance. And when you decided not to use encryption, PJD> because it introduces too big overhead, it only means that you didn't PJD> need encryption in the first place:) Well, I suppose most usage patterns imply that only part of data really needs encryption (as only part really needs copies>1 or compression), hence it would be *extremely* useful if one can ``zfs set encryption=on tank/home/joe'' (could it be done via pluggable geom modules or something?) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 07:42:03 2007 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 D276316A418 for ; Wed, 29 Aug 2007 07:42:03 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 6493D13C45D for ; Wed, 29 Aug 2007 07:42:03 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6801445E90; Wed, 29 Aug 2007 09:42:01 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 71A6445B26; Wed, 29 Aug 2007 09:41:55 +0200 (CEST) Date: Wed, 29 Aug 2007 09:40:45 +0200 From: Pawel Jakub Dawidek To: Paul Allen Message-ID: <20070829074045.GA42667@garage.freebsd.pl> References: <20070828180228.GD39562@garage.freebsd.pl> <20070828204834.9A7F85B3B@mail.bitblocks.com> <20070828205554.GI39562@garage.freebsd.pl> <20070828235751.GB13200@hurl.ugcs.caltech.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <20070828235751.GB13200@hurl.ugcs.caltech.edu> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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: current@freebsd.org, Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 07:42:03 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 04:57:51PM -0700, Paul Allen wrote: > >From Pawel Jakub Dawidek , Tue, Aug 28, 2007 at 10:55:5= 5PM +0200: > > You can't ignore write error, because application already assumed the > > write succeeded, which can lead to misbehaviour later. ZFS cannot yet > What !?! I suggest you man 2 fsync. >=20 > fsync should return EIO if any write in the past has failed. Maybe we have different manual pages, but mine doesn't mention anything about writes in the past:) Anyway, I did a test, because I wasn't sure how UFS is going to handle this case: 1. Open a file, write 64kB of data and wait 35 seconds for SoftUpdates to flush cache to the disk. 2. Return an I/O error on this cache flush. 3. Write another 64kB. 4. Call fsync(2), flush next 64kB successfully. If UFS remembers I/O errors, fsync(2) should return EIO. And actually it does. I thought that when file system itself flushes the cache and there's an I/O error then, it won't affect future fsync(2)s. But yeah, UFS doesn't free failed buffers, but keeps them around. Interesting thing is that even after fsync(2) returned an error, so application was informed about the failure, UFS keeps trying to flush this buffer. IMHO it should just give up. Anyway, I still won't assume that fsync(2) will return EIO if a write in the past failed... POSIX doesn't tell anything about it. It just says "An I/O error occurred while reading from or writing to the file system." - if there are no reading nor writting to the file system, because buffers where flushed before (and failure occured then), I understand that fsync(2) can return success. > No program should make assumptions based on a successful return of write(= 2). > Granted, many do; but applications where it really matters properly do fs= ync(2). Agreed. In case of ZFS, there is probably no easy way currently to remember failed writes, that's why it does what it does. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1SL9ForvXbEpPzQRAvHMAKDaEiseQx954UFoQfkAbUHgqrf6RgCeOIFs Es0JrVq1syPQQjM3uLRyeuk= =b26E -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 07:45:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F364816A41B for ; Wed, 29 Aug 2007 07:45:57 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8AA13C46A for ; Wed, 29 Aug 2007 07:45:57 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.13.8/8.13.8) with ESMTP id l7T7jsKM012799; Wed, 29 Aug 2007 09:45:55 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 48B55851; Wed, 29 Aug 2007 09:45:54 +0200 (CEST) Date: Wed, 29 Aug 2007 09:45:54 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Dmitry Morozovsky Message-Id: <20070829094554.50175452.gerrit@pmp.uni-hannover.de> In-Reply-To: <20070829113209.C1528@woozle.rinet.ru> References: <46D2C812.8090106@gmail.com> <20070828104625.GB36596@garage.freebsd.pl> <46D40833.2030007@barafranca.com> <20070828175402.GB39562@garage.freebsd.pl> <20070829113209.C1528@woozle.rinet.ru> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.3 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146 Cc: freebsd-current@freebsd.org Subject: Re: Encrypted 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: Wed, 29 Aug 2007 07:45:58 -0000 On Wed, 29 Aug 2007 11:35:50 +0400 (MSD) Dmitry Morozovsky wrote about Re: Encrypted zfs?: DM> Well, I suppose most usage patterns imply that only part of data DM> really needs encryption (as only part really needs copies>1 or DM> compression), hence it would be *extremely* useful if one can ``zfs DM> set encryption=on tank/home/joe'' (could it be done via pluggable geom DM> modules or something?) I think I read somewhere that Sun is working on encryption features for zfs. Maybe it is a good idea to let them come up with their solution first. cu Gerrit From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 07:46:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F25CB16A41A for ; Wed, 29 Aug 2007 07:46:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 95F1013C457 for ; Wed, 29 Aug 2007 07:46:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3673645E91; Wed, 29 Aug 2007 09:46:01 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D00F845683; Wed, 29 Aug 2007 09:45:56 +0200 (CEST) Date: Wed, 29 Aug 2007 09:44:47 +0200 From: Pawel Jakub Dawidek To: Dmitry Morozovsky Message-ID: <20070829074447.GB42667@garage.freebsd.pl> References: <46D2C812.8090106@gmail.com> <20070828104625.GB36596@garage.freebsd.pl> <46D40833.2030007@barafranca.com> <20070828175402.GB39562@garage.freebsd.pl> <20070829113209.C1528@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline In-Reply-To: <20070829113209.C1528@woozle.rinet.ru> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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: freebsd-current@freebsd.org, Hugo Silva Subject: Re: Encrypted 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: Wed, 29 Aug 2007 07:46:05 -0000 --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 29, 2007 at 11:35:50AM +0400, Dmitry Morozovsky wrote: > On Tue, 28 Aug 2007, Pawel Jakub Dawidek wrote: >=20 > PJD> On Tue, Aug 28, 2007 at 12:34:11PM +0100, Hugo Silva wrote: > PJD> > How's the performance on the geli-backed pool ? > PJD>=20 > PJD> It depends a lot on CPU speed, but you should be ready for visible > PJD> performance drop. I'll give you two examples: >=20 > [examples snipped] >=20 > PJD> But don't you worry, when you must have encryption, you don't really > PJD> care about performance. And when you decided not to use encryption, > PJD> because it introduces too big overhead, it only means that you didn't > PJD> need encryption in the first place:) >=20 > Well, I suppose most usage patterns imply that only part of data really n= eeds=20 > encryption (as only part really needs copies>1 or compression), hence it = would=20 > be *extremely* useful if one can ``zfs set encryption=3Don tank/home/joe'' > (could it be done via pluggable geom modules or something?) No, it can't be done that way. You cannot put a GEOM module inside ZFS. The good news is that ZFS encryption support is in development. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1SPvForvXbEpPzQRApJCAKCnbhJlh0Iy5/Guj+Nx4pOmWVm5uwCg7fwZ H7Sll+Qq1NEwKhAFNmkmDdM= =1Wzm -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 07:54:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77D3416A417 for ; Wed, 29 Aug 2007 07:54:38 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by mx1.freebsd.org (Postfix) with ESMTP id 13F6713C481 for ; Wed, 29 Aug 2007 07:54:37 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [213.84.11.61]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id l7T7sZSd056621; Wed, 29 Aug 2007 09:54:35 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 29 Aug 2007 09:51:21 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB011180@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tidbit for improving Samba performance Thread-Index: Acfpn2R1aqeGx5iQTzyMYeshqU7Y2QAcf+FT References: <16447218.32631188324732895.JavaMail.root@zmail.illuminati.org> From: "Johan Hendriks" To: "Brooks Talley" X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: RE: Tidbit for improving Samba 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: Wed, 29 Aug 2007 07:54:38 -0000 Did you also tried to compile without the repdir_get* files mentioned = here: http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074600.html = =20 It is reported that that also increase speed. http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074601.html =20 I do not know if it is save to do, but they reported nothing is wrong = without the 2 files. =20 I really do not know what the status of that issue is at the moment! =20 regards, Johan =20 From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 08:04:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0E0216A418 for ; Wed, 29 Aug 2007 08:04:17 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.248]) by mx1.freebsd.org (Postfix) with ESMTP id A2F0213C442 for ; Wed, 29 Aug 2007 08:04:17 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ag-out-0708.google.com with SMTP id 35so123252aga for ; Wed, 29 Aug 2007 01:04:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=p21fdod+us72FIeRAXrn7We/vfijHLCl5oMurwaHrPcOvQagROQ4UOET5iLiHTLj+Fd11YCwqU4JAzRzR+nBd/H/AuJeDCgKQfUAnZDqfkA66oCp2pQzndZUFSQ9WWQ8zA7oSkEPxx2rw97eIpep1z066zk8hnZMQRPvr8enCeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AuJeCQKmCEENYeLaOjfVWMcdG0mqwN9Melp5+ySy+BABI0VtrPHpffWecIoDCUeRIbjLq877xj552+mF5UTuaCXzy5r5vWWyCkNdPsyXEcVktpMfYegCTHvhmj7tCdhBf5VahDPeB5JCcsD99oXUprrVXnEdgQ+r6BkXbE4Qbyw= Received: by 10.100.177.16 with SMTP id z16mr260455ane.1188374656814; Wed, 29 Aug 2007 01:04:16 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Wed, 29 Aug 2007 01:04:16 -0700 (PDT) Message-ID: <499c70c0708290104qc1ccf2fod05a3609cff5358e@mail.gmail.com> Date: Wed, 29 Aug 2007 11:04:16 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: daniel.tourde@spray.se In-Reply-To: <200708281950.11793.daniel.tourde@spray.se> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200708281927.13671.daniel.tourde@spray.se> <20070828173036.GD77256@hub.freebsd.org> <200708281950.11793.daniel.tourde@spray.se> Cc: freebsd-current@freebsd.org Subject: Re: gdb 6.1.1 on 7.0-current. Any update? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 08:04:18 -0000 On 8/28/07, Daniel Tourde wrote: > Hello Kris, > > > > > gdb on the Aug 07 edition of 7.0 current is still 6.1.1. If I am not > > > mistaken, the actual version of gdb is 6.6. Any plan to update this > > > before the release of 7.0? > > > > AFAIK someone needs to integrate or reimplement the FreeBSD local > > changes into gdb 6.6, and this isn't likely to happen in time for 7.0. > > OK. Any plan for 7.1 or 7.2? > > > Daniel If you need gdb 6.6 it's on the ports now. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 09:12:00 2007 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 7FFA116A41A for ; Wed, 29 Aug 2007 09:12:00 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 0607813C481 for ; Wed, 29 Aug 2007 09:11:59 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so99277nfb for ; Wed, 29 Aug 2007 02:11:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=PERG94hBevByBqe0IiZ7nNwm0AVun5zw2bCxNKvnwIY2H7DdIrqIRGcbdMIersdw9FMPGr/yGTcflm42PIS/alqNDLZKHkqaEkjnN6OKI8tQuyLPLk7rQ4tib6rLlmVQFHY/Vv4ptyqeY7yI3X8ySDwgclbSDyyUhHdXpsvHKNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=VWoqcYULVgVAhoSwOUBaFc5JC7olCwW3DdnGQial9a+4DzHi+9SfjBNq/M3vFm5xiyoocIcY+cLu/oRfMnKhaRKQl7m/9kcJQhZ+1B7sQYwN6YW/k065isj+3mrh8KQqVi4yV4cky6b0ka+9MUHKnLWZe1hemzZZik8Zq0LdRvw= Received: by 10.78.138.6 with SMTP id l6mr210097hud.1188377110110; Wed, 29 Aug 2007 01:45:10 -0700 (PDT) Received: from fairy.alashan.de ( [79.196.60.248]) by mx.google.com with ESMTPS id 38sm5601366hua.2007.08.29.01.45.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Aug 2007 01:45:09 -0700 (PDT) Message-ID: <46D54E3E.2040803@gmail.com> Date: Wed, 29 Aug 2007 10:45:18 +0000 From: Christian Walther User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Problems moving existing pool to encrypted devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 09:12:00 -0000 Hi, after my previous questions concerning the use of zfs on encrypted devices, I thought I give it a try. Here is what I did: tarmin# zpool export pool01 tarmin# dd if=/dev/urandom of=/dev/ad2 bs=1024k tarmin# zpool import pool01 tarmin# zpool status pool: pool01 state: ONLINE status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-4J scrub: resilver completed with 0 errors on Wed Aug 29 10:07:21 2007 config: NAME STATE READ WRITE CKSUM pool01 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 387148737669265642 UNAVAIL 0 0 0 was /dev/ad2 errors: No known data errors tarmin# geli init -K /root/ad2.key -s 4096 /dev/ad2 Enter new passphrase: Reenter new passphrase: geli: Cannot store metadata on /dev/ad2: Operation not permitted. tarmin# zpool export pool01 tarmin# geli init -K /root/ad2.key -s 4096 /dev/ad2 Enter new passphrase: Reenter new passphrase: tarmin# geli attach -k /root/ad2.key /dev/ad2 Enter passphrase: tarmin# ls /dev/ad2* /dev/ad2 /dev/ad2.eli tarmin# zpool import pool01 cannot import 'pool01': invalid vdev configuration tarmin# zpool status no pools available Summary: I can't break a ZFS vdev and encrypt it, because every time the pool is imported while a newly created /dev/ad2.eli is active, ZFS complains about a wrong vdev configuration, rendering the pool useless. The other way round doesn't work, too: ZFS seems to lock the device, making geli initialization impossible. From here my only possible way seems to be to buy another 400GB disk, so that I can set it up correctly and can do a replace against the old /dev/ad2. Afterwards I should be able to use /dev/ad2.eli as a replacement for one of the other disks. So finally I can either bring one of the disks back, or I have a spare disk. Or am I probably missing something here, and there's another way I didn't see? Regards, Christian From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 09:43:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52EFD16A418 for ; Wed, 29 Aug 2007 09:43:13 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id D988A13C46E for ; Wed, 29 Aug 2007 09:43:12 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l7T9v83f005692; Wed, 29 Aug 2007 11:57:08 +0200 (MEST) Message-ID: <46D53FA5.1000606@fer.hr> Date: Wed, 29 Aug 2007 11:43:01 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Tom Judge References: <200708261948.05750.qpadla@gmail.com> <46D41DAE.5010501@freebsd.org> <46D4A944.5060300@fer.hr> <46D4D421.90602@tomjudge.com> In-Reply-To: <46D4D421.90602@tomjudge.com> X-Enigmail-Version: 0.94.4.0 OpenPGP: id=569C05C8; url=http://ivoras.sharanet.org/ivoras@fer.hr_0x569C05C8_pub.asc Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig8C37CA7992C93FFB8B0C62ED" Cc: freebsd-current@freebsd.org Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 09:43:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8C37CA7992C93FFB8B0C62ED Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Tom Judge wrote: > It would be easier to attach a serial console to the system, even if it= =20 > is in the form of a second machine and null modem cable. The handbook = > will hold your had if you want to try setting it up. No need for that - I'm running it under VMWare so I can route serial=20 ports between VMs. The big problem is that most of the panics happen with cd9660 as the=20 root file system (LiveCD setup) and I'll have to see what I can do with=20 serial ports in this environment. But it's a good idea. --------------enig8C37CA7992C93FFB8B0C62ED 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.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG1T+rldnAQVacBcgRA1XrAJ9qqIeokIirREuZmyrdG6FZQZDsgACeN5HY IAqMpGYdvcA1KA/q0NCy6eI= =Guei -----END PGP SIGNATURE----- --------------enig8C37CA7992C93FFB8B0C62ED-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 10:10:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DED9C16A418 for ; Wed, 29 Aug 2007 10:10:38 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id A0F2813C457 for ; Wed, 29 Aug 2007 10:10:38 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 204972095; Wed, 29 Aug 2007 12:10:34 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 0CA142094; Wed, 29 Aug 2007 12:10:34 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id DF60D84464; Wed, 29 Aug 2007 12:10:33 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Butcher References: <46D4EFFF.5080807@fusiongol.com> Date: Wed, 29 Aug 2007 12:10:33 +0200 In-Reply-To: <46D4EFFF.5080807@fusiongol.com> (Nathan Butcher's message of "Wed\, 29 Aug 2007 13\:03\:11 +0900") Message-ID: <86ir6y3b3a.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Encrypted 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: Wed, 29 Aug 2007 10:10:39 -0000 Nathan Butcher writes: > The only thing that sucks is that once I have attached all GELI > providers, I have to manually kickstart zfs and mount the pool with the > following commands:- That shouldn't be necessary; geli starts before zfs in the rc order. > One thing I also tried was replacing a drive with a much larger one > using zpool replace. ZFS didn't notice the larger disk capacity of the > new drive and subsequently didn't increase the pool size. What is the > logic behind that? How do you expect ZFS to provide redundancy for the larger disk? Your pool will grow when all disks are replaced with larger ones. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 10:15:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E578D16A417 for ; Wed, 29 Aug 2007 10:15:51 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id A75EF13C442 for ; Wed, 29 Aug 2007 10:15:51 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id EAAA22095; Wed, 29 Aug 2007 12:15:44 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 759592094; Wed, 29 Aug 2007 12:15:44 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 63A7184427; Wed, 29 Aug 2007 12:15:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Christian Walther References: <46D2C812.8090106@gmail.com> Date: Wed, 29 Aug 2007 12:15:44 +0200 In-Reply-To: <46D2C812.8090106@gmail.com> (Christian Walther's message of "Mon\, 27 Aug 2007 12\:48\:18 +0000") Message-ID: <86ejhm3aun.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Encrypted 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: Wed, 29 Aug 2007 10:15:52 -0000 Christian Walther writes: > And what is even more important: What is the best of moving the zraid > to encrypted devices? I can't remove one of the disks because they > are in use. Sure you can. That's what raidz is for. Offline one of the disks and configure GELI on it, then add it back to the pool with 'zpool replace'. Wait for the resilvering to finish, then repeat with the next disk. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 10:19:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C430516A41A for ; Wed, 29 Aug 2007 10:19:04 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: from melamine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.freebsd.org (Postfix) with ESMTP id 8B57213C45B for ; Wed, 29 Aug 2007 10:19:04 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: by melamine.cuivre.fr.eu.org (Postfix, from userid 1000) id 9804C5C5B2; Wed, 29 Aug 2007 12:01:37 +0200 (CEST) Date: Wed, 29 Aug 2007 12:01:37 +0200 From: Thomas Quinot To: Patrick Hajek Message-ID: <20070829100137.GA21751@melamine.cuivre.fr.eu.org> References: <20070827184806.GQ2368@lbl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070827184806.GQ2368@lbl.gov> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: Recent changes in atapi-cam? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 10:19:04 -0000 * Patrick Hajek, 2007-08-27 : > The upgrade was successful with one exception: > ad0: 95205MB at ata0-master UDMA100 > acd0: DVDR at ata1-master UDMA33 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 > acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 atapicam is disabled in your kernel configuration, so I assume you are loading it as a module. Do you still get the errors above (on acd0) if you do *not* load the atapi-cam module? Thomas. From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 10:28:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C08D16A417; Wed, 29 Aug 2007 10:28:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE1513C483; Wed, 29 Aug 2007 10:28:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 435BA2095; Wed, 29 Aug 2007 12:27:58 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id AD8E62094; Wed, 29 Aug 2007 12:27:57 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 82BE084437; Wed, 29 Aug 2007 12:27:57 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Max Laier References: <20070828211440.470805B3B@mail.bitblocks.com> <200708282324.05834.max@love2party.net> Date: Wed, 29 Aug 2007 12:27:57 +0200 In-Reply-To: <200708282324.05834.max@love2party.net> (Max Laier's message of "Tue\, 28 Aug 2007 23\:23\:56 +0200") Message-ID: <86absa3aaa.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek , Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 10:28:03 -0000 Max Laier writes: > This is complete nonsense! As you pointed out earlier zfs doesn't > know anything about the nature of the error. There is only one > sensible way to deal with a disk error - unless it is transient - and > that is stopping all (write) access to the drive. As you can't easily > move a mounted drive with opened files into read-only mode, a panic is > the only way to make sure. Actually, remounting the disk read-only upon encountering a write error is standard behaviour in Linux. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 10:32:33 2007 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 98CD416A420 for ; Wed, 29 Aug 2007 10:32:33 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5A7CC13C459 for ; Wed, 29 Aug 2007 10:32:33 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id E0B222098; Wed, 29 Aug 2007 12:32:26 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id D349C2095; Wed, 29 Aug 2007 12:32:26 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 5F16C84437; Wed, 29 Aug 2007 12:32:26 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Christian Walther References: <46D54E3E.2040803@gmail.com> Date: Wed, 29 Aug 2007 12:32:26 +0200 In-Reply-To: <46D54E3E.2040803@gmail.com> (Christian Walther's message of "Wed\, 29 Aug 2007 10\:45\:18 +0000") Message-ID: <86642y3a2t.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Problems moving existing pool to encrypted devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 10:32:33 -0000 Christian Walther writes: > after my previous questions concerning the use of zfs on encrypted > devices, I thought I give it a try. > > Here is what I did: > > tarmin# zpool export pool01 > tarmin# dd if=3D/dev/urandom of=3D/dev/ad2 bs=3D1024k > tarmin# zpool import pool01 > [...] No! # zpool offline pool01 /dev/ad2 # geli init [...] /dev/ad2 # zpool replace pool01 /dev/ad2 /dev/ad2.eli DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 10:43:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E547F16A417 for ; Wed, 29 Aug 2007 10:43:22 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDC413C474 for ; Wed, 29 Aug 2007 10:43:21 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l7TAhJfW051834; Wed, 29 Aug 2007 12:43:19 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l7TAhEPU047100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 12:43:14 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l7TAhDmL050530; Wed, 29 Aug 2007 12:43:13 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l7TAhDXc050529; Wed, 29 Aug 2007 12:43:13 +0200 (CEST) (envelope-from ticso) Date: Wed, 29 Aug 2007 12:43:13 +0200 From: Bernd Walter To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20070829104312.GS45279@cicely12.cicely.de> References: <20070828211440.470805B3B@mail.bitblocks.com> <200708282324.05834.max@love2party.net> <86absa3aaa.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86absa3aaa.fsf@ds4.des.no> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: Max Laier , freebsd-current@freebsd.org, Pawel Jakub Dawidek , Pascal Hofstee Subject: Re: ZFS kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 10:43:23 -0000 On Wed, Aug 29, 2007 at 12:27:57PM +0200, Dag-Erling Smørgrav wrote: > Max Laier writes: > > This is complete nonsense! As you pointed out earlier zfs doesn't > > know anything about the nature of the error. There is only one > > sensible way to deal with a disk error - unless it is transient - and > > that is stopping all (write) access to the drive. As you can't easily > > move a mounted drive with opened files into read-only mode, a panic is > > the only way to make sure. > > Actually, remounting the disk read-only upon encountering a write error > is standard behaviour in Linux. And it didn't even tell, but that's another story. Anyway - I prefer the panic unless a better solution is available or possible, like fsync/write error or even better just switch to another block. In case of redundancy however it may be best if the disk is taken completely out of use, since many kind write errors produce highe latencies, which slows down the system. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 11:28:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D240E16A419 for ; Wed, 29 Aug 2007 11:28:48 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF6B13C467 for ; Wed, 29 Aug 2007 11:28:48 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe11.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 424673364 for freebsd-current@freebsd.org; Wed, 29 Aug 2007 12:28:45 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 29 Aug 2007 12:28:58 +0200 User-Agent: KMail/1.9.7 References: <200708270922.06233.hselasky@c2i.net> <20070828213248.GC89132@dragon.NUXI.org> In-Reply-To: <20070828213248.GC89132@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708291228.58596.hselasky@c2i.net> Subject: Re: Ports and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 11:28:48 -0000 On Tuesday 28 August 2007, David O'Brien wrote: > On Mon, Aug 27, 2007 at 09:22:05AM +0200, Hans Petter Selasky wrote: > > When you install a port that has several sub-ports, is there way to run > > through all the configuration menus recursivly, so that the compilation > > does not stop all the time asking for user input? > > Hi, > > This is purely a ports question, it isn't freebsd-current specific. > Please ask this type of question at freebsd-ports@freebsd.org. > > thanks, Thanks for your answers! --HPS From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 11:31:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D653416A420 for ; Wed, 29 Aug 2007 11:31:23 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id A5F6313C48A for ; Wed, 29 Aug 2007 11:31:23 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l7TBVBKd053097; Wed, 29 Aug 2007 06:31:11 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46D558FE.6050502@freebsd.org> Date: Wed, 29 Aug 2007 06:31:10 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ivan Voras References: <200708261948.05750.qpadla@gmail.com> <46D41DAE.5010501@freebsd.org> <46D4A944.5060300@fer.hr> <46D4D421.90602@tomjudge.com> <46D53FA5.1000606@fer.hr> In-Reply-To: <46D53FA5.1000606@fer.hr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: Tom Judge , freebsd-current@freebsd.org Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 11:31:23 -0000 Ivan Voras wrote: > Tom Judge wrote: > >> It would be easier to attach a serial console to the system, even if >> it is in the form of a second machine and null modem cable. The >> handbook will hold your had if you want to try setting it up. > > No need for that - I'm running it under VMWare so I can route serial > ports between VMs. > > The big problem is that most of the panics happen with cd9660 as the > root file system (LiveCD setup) and I'll have to see what I can do with > serial ports in this environment. But it's a good idea. > When I get a panic while in X, I can now (recently - this was not true 3 or 4 months ago) just type "call doadump [enter] reset [enter]" and I'll get a crash dump and the system will reboot. I then analyze the dump later. I can't see the text, but it actually *is* in the debugger (for me anyway). That's how I tracked this dirbad issue down when I saw it the first time. Eric From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 06:10:15 2007 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 F05BD16A419 for ; Wed, 29 Aug 2007 06:10:14 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id B8BBA13C46A for ; Wed, 29 Aug 2007 06:10:14 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from home.alpha-tierchen.de (port-212-202-42-154.dynamic.qsc.de [212.202.42.154]) by mail.liberty-hosting.de (Postfix) with ESMTP id C90FA3E9614 for ; Wed, 29 Aug 2007 07:48:07 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id E71D945067 for ; Wed, 29 Aug 2007 07:46:05 +0200 (CEST) Received: from 2001:6f8:101e:0:20e:cff:fe6d:6adb (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Wed, 29 Aug 2007 07:46:06 +0200 (CEST) Message-ID: <62415.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188366366.squirrel@webmail.alpha-tierchen.de> Date: Wed, 29 Aug 2007 07:46:06 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: current@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20070829074606_74887" X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Wed, 29 Aug 2007 11:38:59 +0000 Cc: Subject: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 06:10:15 -0000 ------=_20070829074606_74887 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hello, what do you think about adding the CPU types "k9" and "k10"? These processors have support for SSE3 and I noticed up to 15% faster execution of CPU-intensive programs (e.g. graphics/povray) that have been compiled using -march=athlon-mp -msse3. Regards Björn ------=_20070829074606_74887 Content-Type: application/octet-stream; name="bsd.cpu.mk.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bsd.cpu.mk.diff" LS0tIGJzZC5jcHUubWsub3JpZwlGcmkgSmFuIDEyIDA4OjQxOjE3IDIwMDcKKysrIGJzZC5jcHUu bWsJV2VkIEF1ZyAyOSAwNzozODowMSAyMDA3CkBAIC03MCw2ICs3MCw4IEBACiAuIGlmICR7TUFD SElORV9BUkNIfSA9PSAiaTM4NiIKIC4gIGlmICR7Q1BVVFlQRX0gPT0gImNydXNvZSIKIF9DUFVD RkxBR1MgPSAtbWFyY2g9aTY4NiAtZmFsaWduLWZ1bmN0aW9ucz0wIC1mYWxpZ24tanVtcHM9MCAt ZmFsaWduLWxvb3BzPTAKKy4gIGVsaWYgJHtDUFVUWVBFfSA9PSAiazkiIHx8ICR7Q1BVVFlQRX0g PT0gImsxMCIKK19DUFVDRkxBR1MgPSAtbWFyY2g9YXRobG9uLW1wIC1tc3NlMwogLiAgZWxpZiAk e0NQVVRZUEV9ID09ICJrNSIKIF9DUFVDRkxBR1MgPSAtbWFyY2g9cGVudGl1bQogLiAgZWxzZQpA QCAtMTIxLDYgKzEyMyw4IEBACiAuIGlmICR7TUFDSElORV9BUkNIfSA9PSAiaTM4NiIKIC4gIGlm ICR7Q1BVVFlQRX0gPT0gIm9wdGVyb24iIHx8ICR7Q1BVVFlQRX0gPT0gImF0aGxvbjY0IgogTUFD SElORV9DUFUgPSBhdGhsb24teHAgYXRobG9uIGs3IDNkbm93IHNzZTIgc3NlIG1teCBrNiBrNSBp NTg2IGk0ODYgaTM4NgorLiAgZWxpZiAke0NQVVRZUEV9ID09ICJrOSIgfHwgJHtDUFVUWVBFfSA9 PSAiazEwIgorTUFDSElORV9DUFUgPSBhdGhsb24teHAgYXRobG9uIGs3IDNkbm93IHNzZTMgc3Nl MiBzc2UgbW14IGs2IGs1IGk1ODYgaTQ4NiBpMzg2CiAuICBlbGlmICR7Q1BVVFlQRX0gPT0gImF0 aGxvbi1tcCIgfHwgJHtDUFVUWVBFfSA9PSAiYXRobG9uLXhwIiB8fCBcCiAgICAgJHtDUFVUWVBF fSA9PSAiYXRobG9uLTQiCiBNQUNISU5FX0NQVSA9IGF0aGxvbi14cCBhdGhsb24gazcgM2Rub3cg c3NlIG1teCBrNiBrNSBpNTg2IGk0ODYgaTM4Ngo= ------=_20070829074606_74887-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 12:02:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 697A216A4E9 for ; Wed, 29 Aug 2007 12:02:23 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id 812D813C543 for ; Wed, 29 Aug 2007 12:02:18 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l7TCG23f021043; Wed, 29 Aug 2007 14:16:03 +0200 (MEST) Message-ID: <46D56039.90805@fer.hr> Date: Wed, 29 Aug 2007 14:02:01 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Anderson References: <200708261948.05750.qpadla@gmail.com> <46D41DAE.5010501@freebsd.org> <46D4A944.5060300@fer.hr> <46D4D421.90602@tomjudge.com> <46D53FA5.1000606@fer.hr> <46D558FE.6050502@freebsd.org> In-Reply-To: <46D558FE.6050502@freebsd.org> X-Enigmail-Version: 0.94.4.0 OpenPGP: id=569C05C8; url=http://ivoras.sharanet.org/ivoras@fer.hr_0x569C05C8_pub.asc Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig2470FFEEFC36B875C882B4C3" Cc: freebsd-current@freebsd.org Subject: Re: Repeated UFS panics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 12:02:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2470FFEEFC36B875C882B4C3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Eric Anderson wrote: > When I get a panic while in X, I can now (recently - this was not true = 3=20 > or 4 months ago) just type "call doadump [enter] reset [enter]" and I'l= l=20 > get a crash dump and the system will reboot. I then analyze the dump=20 > later. I can't see the text, but it actually *is* in the debugger (for= =20 I know that, but while running a LiveCD I don't have a swap. --------------enig2470FFEEFC36B875C882B4C3 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.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG1WA6ldnAQVacBcgRA1Q5AKCsGJBOxPq9CKBzZtwhjpgDCON10ACg49Ac kxAugw6neQ8rCNwN+hC+PM0= =FMv9 -----END PGP SIGNATURE----- --------------enig2470FFEEFC36B875C882B4C3-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 12:59:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CB6F16A419 for ; Wed, 29 Aug 2007 12:59:28 +0000 (UTC) (envelope-from vanilla@fatpipi.com) Received: from mail.fatpipi.com (220-135-222-5.HINET-IP.hinet.net [220.135.222.5]) by mx1.freebsd.org (Postfix) with ESMTP id 15B7413C428 for ; Wed, 29 Aug 2007 12:59:28 +0000 (UTC) (envelope-from vanilla@fatpipi.com) Received: by mail.fatpipi.com (Postfix, from userid 1002) id C552A2E024; Wed, 29 Aug 2007 20:42:52 +0800 (CST) Date: Wed, 29 Aug 2007 20:42:52 +0800 From: "Vanilla I. Shu" To: freebsd-current@freebsd.org Message-ID: <20070829124252.GA32532@fatpipi.cirx.org> MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: patch for objc include file. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 12:59:28 -0000 Hi: could someone to review this patch and commit it? /usr/include/objc/objc-api.h need to include objc-decls.h but it will not install by current objc Makefile. thanks. -- this patch will resolve broken of ports/lang/ofc. From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 13:14:09 2007 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 26CE316A41B for ; Wed, 29 Aug 2007 13:14:09 +0000 (UTC) (envelope-from vanilla@fatpipi.com) Received: from mail.fatpipi.com (220-135-222-5.HINET-IP.hinet.net [220.135.222.5]) by mx1.freebsd.org (Postfix) with ESMTP id 9B15C13C458 for ; Wed, 29 Aug 2007 13:14:08 +0000 (UTC) (envelope-from vanilla@fatpipi.com) Received: by mail.fatpipi.com (Postfix, from userid 1002) id CC3F82E028; Wed, 29 Aug 2007 20:57:06 +0800 (CST) Date: Wed, 29 Aug 2007 20:57:06 +0800 From: "Vanilla I. Shu" To: current@freebsd.org Message-ID: <20070829125706.GA36689@fatpipi.cirx.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: patch for objc include files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 13:14:09 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=big5 Content-Disposition: inline Hi: could someone to review this patch and commit it? /usr/include/objc/objc-api.h need to include objc-decls.h but it will not install by current objc Makefile. thanks. -- this patch will resolve broken of ports/lang/ofc. --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=big5 Content-Disposition: attachment; filename="diff.objc" --- gnu/lib/libobjc/Makefile.orig 2007-08-29 20:35:38.780575573 +0800 +++ gnu/lib/libobjc/Makefile 2007-08-29 20:35:49.764902910 +0800 @@ -13,7 +13,7 @@ nil_method.c NXConstStr.m Object.m objects.c Protocol.m sarray.c \ selector.c sendmsg.c thr.c thr-objc.c exception.c -INCS= encoding.h hash.h objc-api.h objc-list.h objc.h runtime.h \ +INCS= encoding.h hash.h objc-api.h objc-decls.h objc-list.h objc.h runtime.h \ sarray.h thr.h typedstream.h NXConstStr.h Object.h Protocol.h INCSDIR=${INCLUDEDIR}/objc --3MwIy2ne0vdjdPXF-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 14:36:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51A0B16A468 for ; Wed, 29 Aug 2007 14:36:24 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from farris.bafirst.com (adsl-065-081-102-002.sip.jan.bellsouth.net [65.81.102.2]) by mx1.freebsd.org (Postfix) with ESMTP id D326B13C45B for ; Wed, 29 Aug 2007 14:36:23 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.129.12.64]) by farris.bafirst.com with esmtp; Wed, 29 Aug 2007 09:26:08 -0500 id 0006D415.46D58201.00015251 Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Wed, 29 Aug 2007 09:26:07 -0500 id 0004AC29.46D581FF.000125EA Received: from dsl-189-129-12-64.prod-infinitum.com.mx (dsl-189-129-12-64.prod-infinitum.com.mx [189.129.12.64]) by intranet.encontacto.net (Horde MIME library) with HTTP; Wed, 29 Aug 2007 09:26:07 -0500 Message-ID: <20070829092607.qb6nfkwuxw88sw80@intranet.encontacto.net> X-Priority: 3 (Normal) Date: Wed, 29 Aug 2007 09:26:07 -0500 From: eculp@encontacto.net To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs) X-Originating-IP: 189.129.12.64 Subject: make release problems with sysutils/mkisofs and sysutils/cdrtools distfile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 14:36:24 -0000 I've been trying to make release, a 7.0 snap on a new current box and yesterday made it to mkisofs that doesn't seem to be in ports any longer so I installed it but didn't ask about it yesterday and today I got to it not finding the dist file for cdrtools. Could there be a make problem in src/release or could I be doing something wrong? Thanks, ed From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 13:20:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C44C16A417; Wed, 29 Aug 2007 13:20:26 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from guardian.elvandar.org (evilcoder.xs4all.nl [195.64.94.120]) by mx1.freebsd.org (Postfix) with ESMTP id ED10A13C4A5; Wed, 29 Aug 2007 13:20:25 +0000 (UTC) (envelope-from remko@elvandar.org) Received: by guardian.elvandar.org (Postfix, from userid 1001) id A0E1C7EDD89; Wed, 29 Aug 2007 15:02:12 +0200 (CEST) Date: Wed, 29 Aug 2007 15:02:12 +0200 From: Remko Lodder To: "Vanilla I. Shu" Message-ID: <20070829130212.GC1164@elvandar.org> References: <20070829124252.GA32532@fatpipi.cirx.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070829124252.GA32532@fatpipi.cirx.org> User-Agent: Mutt/1.5.15 (2007-04-06) X-Mailman-Approved-At: Wed, 29 Aug 2007 14:39:42 +0000 Cc: freebsd-current@freebsd.org Subject: Re: patch for objc include file. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 13:20:26 -0000 On Wed, Aug 29, 2007 at 08:42:52PM +0800, Vanilla I. Shu wrote: > Hi: > > could someone to review this patch and commit it? > > /usr/include/objc/objc-api.h need to include objc-decls.h > > but it will not install by current objc Makefile. > > thanks. > What patch? ;-) -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 14:43:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83C4816A41A for ; Wed, 29 Aug 2007 14:43:10 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id 6058313C46C for ; Wed, 29 Aug 2007 14:43:10 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l7TEh8HR010588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2007 07:43:08 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l7TEh7Hl010955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Aug 2007 07:43:08 -0700 Message-ID: <46D58604.2090909@u.washington.edu> Date: Wed, 29 Aug 2007 07:43:16 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: eculp@encontacto.net References: <20070829092607.qb6nfkwuxw88sw80@intranet.encontacto.net> In-Reply-To: <20070829092607.qb6nfkwuxw88sw80@intranet.encontacto.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.29.71924 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: freebsd-current Subject: Re: make release problems with sysutils/mkisofs and sysutils/cdrtools distfile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 14:43:10 -0000 eculp@encontacto.net wrote: > I've been trying to make release, a 7.0 snap on a new current box and > yesterday made it to mkisofs that doesn't seem to be in ports any > longer so I installed it but didn't ask about it yesterday and today I > got to it not finding the dist file for cdrtools. Could there be a > make problem in src/release or could I be doing something wrong? > > Thanks, > > ed Memory serves me correctly you have to have sysutils/cdrtools in order to run make release (otherwise you can't make the ISO). I'd check the handbook though to make sure. -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 14:47:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E236716A420 for ; Wed, 29 Aug 2007 14:47:35 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id BF39F13C4CB for ; Wed, 29 Aug 2007 14:47:35 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l7TElXJL030950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2007 07:47:34 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l7TElX3a011389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Aug 2007 07:47:33 -0700 Message-ID: <46D5870E.2040302@u.washington.edu> Date: Wed, 29 Aug 2007 07:47:42 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: eculp@encontacto.net References: <20070829092607.qb6nfkwuxw88sw80@intranet.encontacto.net> <46D58604.2090909@u.washington.edu> In-Reply-To: <46D58604.2090909@u.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.29.72325 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: freebsd-current Subject: Re: make release problems with sysutils/mkisofs and sysutils/cdrtools distfile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 14:47:36 -0000 Garrett Cooper wrote: > eculp@encontacto.net wrote: >> I've been trying to make release, a 7.0 snap on a new current box and >> yesterday made it to mkisofs that doesn't seem to be in ports any >> longer so I installed it but didn't ask about it yesterday and today >> I got to it not finding the dist file for cdrtools. Could there be a >> make problem in src/release or could I be doing something wrong? >> >> Thanks, >> >> ed > > Memory serves me correctly you have to have sysutils/cdrtools in > order to run make release (otherwise you can't make the ISO). I'd > check the handbook though to make sure. > -Garrett Oh, it's still in the same spot for me though, and I can install cdrtools now. Did you maybe get an incomplete ports tree? -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 15:04:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CAC116A56C; Wed, 29 Aug 2007 15:04:29 +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 0ECFC13C459; Wed, 29 Aug 2007 15:04:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id l7TF1JCB031850; Wed, 29 Aug 2007 08:01:19 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id l7TF19QK031843; Wed, 29 Aug 2007 08:01:09 -0700 (PDT) (envelope-from sgk) Date: Wed, 29 Aug 2007 08:01:09 -0700 From: Steve Kargl To: Daniel Tourde Message-ID: <20070829150109.GA31652@troutmask.apl.washington.edu> References: <200708281928.26819.daniel.tourde@spray.se> <20070828172908.GC77256@hub.freebsd.org> <200708281949.26686.daniel.tourde@spray.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708281949.26686.daniel.tourde@spray.se> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: gdb and gfortran in 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 15:04:29 -0000 On Tue, Aug 28, 2007 at 07:49:25PM +0200, Daniel Tourde wrote: > Hello Kris, > > > > > I am trying 7.0-current and I am planning to use CVS. At the moment I > > > have the snapshot of Aug 07 installed on my machine. > > > > > > I saw that by default, during bootstrap, gfortran and gdb aren't built. > > > Do I simply need to comment the two NO_ flags in Makefile.incl to get > > > gfortran and gdb or do I need to do anything else? > > > > gdb is included in 7.0 and should be built by default. gfortran is > > not included in 7.0 and you need to install the port if you want it. > > Thanks for your answer. > Why isn't gfortran (coming from gcc 4.2.1) included in 7.0 when f77 (coming > from gcc-3.4.6) is included in 6.2? > gfortran requires GMP and MPFR. These libraries are not in the base system. However, if FreeBSD ever moves to gcc-4.3.0, it will needs the libraries. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 15:49:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC40616A418 for ; Wed, 29 Aug 2007 15:49:37 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from farris.bafirst.com (adsl-065-081-102-002.sip.jan.bellsouth.net [65.81.102.2]) by mx1.freebsd.org (Postfix) with ESMTP id 467FA13C46A for ; Wed, 29 Aug 2007 15:49:37 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.129.12.64]) by farris.bafirst.com with esmtp; Wed, 29 Aug 2007 10:49:34 -0500 id 0006D415.46D5958F.00015340 Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Wed, 29 Aug 2007 10:49:34 -0500 id 0004AC29.46D5958E.00013060 Received: from dsl-189-129-12-64.prod-infinitum.com.mx (dsl-189-129-12-64.prod-infinitum.com.mx [189.129.12.64]) by intranet.encontacto.net (Horde MIME library) with HTTP; Wed, 29 Aug 2007 10:49:33 -0500 Message-ID: <20070829104933.c7q7t8snqckok4g4@intranet.encontacto.net> X-Priority: 3 (Normal) Date: Wed, 29 Aug 2007 10:49:33 -0500 From: eculp@encontacto.net To: freebsd-current References: <20070829092607.qb6nfkwuxw88sw80@intranet.encontacto.net> <46D58604.2090909@u.washington.edu> <46D5870E.2040302@u.washington.edu> In-Reply-To: <46D5870E.2040302@u.washington.edu> 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 (4.2-cvs) X-Originating-IP: 189.129.12.64 Subject: Re: Re: make release problems with sysutils/mkisofs and sysutils/cdrtools distfile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 15:49:38 -0000 Quoting Garrett Cooper : > Garrett Cooper wrote: >> eculp@encontacto.net wrote: >>> I've been trying to make release, a 7.0 snap on a new current box =20 >>> and yesterday made it to mkisofs that doesn't seem to be in ports =20 >>> any longer so I installed it but didn't ask about it yesterday and =20 >>> today I got to it not finding the dist file for cdrtools. Could =20 >>> there be a make problem in src/release or could I be doing =20 >>> something wrong? >>> >>> Thanks, >>> >>> ed >> >> Memory serves me correctly you have to have sysutils/cdrtools in =20 >> order to run make release (otherwise you can't make the ISO). I'd =20 >> check the handbook though to make sure. Thanks Garrett. I know that sysutils/cdrtools is needed for a release =20 and the other older machines that I build releases on all have. This =20 machine has cvsuped from different hosts daily for about 10 days now =20 and still doesn't have it so I thought that it might have been removed =20 as a port.I had considered that I might be getting an incomplete tree =20 but I really don't know. I can copy it over from another box and it =20 works except for the distfile problem that I just copied the file from =20 another machine and am going through the process again. Thanks, again. ed >> -Garrett > > Oh, it's still in the same spot for me though, and I can install =20 > cdrtools now. Did you maybe get an incomplete ports tree? > -Garrett > From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 16:01:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82C1C16A417 for ; Wed, 29 Aug 2007 16:01:13 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 143FB13C465 for ; Wed, 29 Aug 2007 16:01:12 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so197474nfb for ; Wed, 29 Aug 2007 09:01:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Xnwx8aASipAd7bCpOMBFjhUu3jREtzX1RTIXT7UbRCvdMjaa0yxBbkEahUkAoXKGrHNUwUJy1xD3hfk3ltse13awQzM2itd0Fdn9TO4S3uuvFUlB0Z1dPzysgvCj3rK3qR38UCpiqpt4DK3r7Tc83ZRvAU0pPqGIRRfhJFmQhi8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=B5IRyop50/MDH4ibcIigAbyQLlU2AOOh54OiO5BdnrDcvj2D52iqUo9GwOCAZpRtnijGS67nb3n3LaeMd0qdria1y4HyWXbpGPH1gkUawFwagsuJj/By85c9fL3XG4mtSugSjLFvC6G+dt5ySyfAb1uOHdYfBPkYyPlx9p8Fuxs= Received: by 10.78.37.7 with SMTP id k7mr445893huk.1188403271491; Wed, 29 Aug 2007 09:01:11 -0700 (PDT) Received: from fairy.alashan.de ( [79.196.60.248]) by mx.google.com with ESMTPS id 35sm6246906huc.2007.08.29.09.01.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Aug 2007 09:01:09 -0700 (PDT) Message-ID: <46D5B46D.5010202@gmail.com> Date: Wed, 29 Aug 2007 18:01:17 +0000 From: Christian Walther User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: Nathan Butcher References: <46D4EFFF.5080807@fusiongol.com> In-Reply-To: <46D4EFFF.5080807@fusiongol.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Encrypted 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: Wed, 29 Aug 2007 16:01:13 -0000 Nathan Butcher wrote: > Yep, using GELI the providers is much better. > > I decided to go one step further and run GLABEL on my drives so my ZFS > pool will be immune from device enumeration issues (assuming I move the > drives between systems, SATA raid cards, etc.) > [...] AFAIK zfs is immune against device enumeration issues itself. There is a nice video on YouTube showing Sun engineers setting up a ZFS pool on a bunch of USB sticks. Afterwards they remove all of them, shuffle them, and put them back in. No problem. (It's in german and a translation is still missing. But the talk is stupid anyway, and the acting of the engineers, too.) This works on FreeBSD, too. I moved one of my disks to another controller. ZFS recognised it on reboot. Really nice. :-) From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 17:07:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA55E16A419 for ; Wed, 29 Aug 2007 17:07:50 +0000 (UTC) (envelope-from pphajek@lbl.gov) Received: from ironport1.lbl.gov (ironport1.lbl.gov [128.3.41.47]) by mx1.freebsd.org (Postfix) with ESMTP id 95FB513C46C for ; Wed, 29 Aug 2007 17:07:50 +0000 (UTC) (envelope-from pphajek@lbl.gov) X-Ironport-SBRS: None X-Brightmail-Tracker: AAAAAA== X-BrightmailFiltered: true X-IronPort-AV: E=Sophos;i="4.19,322,1183359600"; d="scan'208";a="53150062" Received: from eniac.jgi-psf.org ([198.129.89.82]) by ironport1.lbl.gov with ESMTP; 29 Aug 2007 10:07:49 -0700 Received: from eniac.jgi-psf.org (localhost [127.0.0.1]) by eniac.jgi-psf.org (8.12.9+Sun/8.12.9) with ESMTP id l7TH7nb9005475; Wed, 29 Aug 2007 10:07:49 -0700 (PDT) Received: (from phajek@localhost) by eniac.jgi-psf.org (8.12.9+Sun/8.12.9/Submit) id l7TH7nTk005474; Wed, 29 Aug 2007 10:07:49 -0700 (PDT) X-Authentication-Warning: eniac.jgi-psf.org: phajek set sender to pphajek@lbl.gov using -f Date: Wed, 29 Aug 2007 10:07:49 -0700 From: Patrick Hajek To: freebsd-current@freebsd.org Message-ID: <20070829170749.GA20549@lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Cc: Thomas Quinot Subject: Re: Recent changes in atapi-cam? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 17:07:50 -0000 >* Patrick Hajek, 2007-08-27 : >> The upgrade was successful with one exception: >> ad0: 95205MB at ata0-master UDMA100 >> acd0: DVDR at ata1-master UDMA33 >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 >> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 >atapicam is disabled in your kernel configuration, so I assume you are >loading it as a module. Do you still get the errors above (on acd0) if >you do *not* load the atapi-cam module? >Thomas. Correct. When I first encountered the error, the vaious components were compiled into the kernel. Taking a wild stab, I decided to see if loading it as a module would result the the same issue and yes, it did. i.e. noe# kldstat Id Refs Address Size Name 1 50 0xc0400000 89b3c4 kernel 2 1 0xc0c9c000 33e4 splash_bmp.ko 3 1 0xc0ca0000 5704 vesa.ko 4 3 0xc0ca6000 28678 linux.ko 5 2 0xc0ccf000 37ef4 pf.ko 6 1 0xc0d07000 ce30 if_wi.ko 7 1 0xc0d14000 6cc8 snd_ich.ko 8 2 0xc0d1b000 4a3a8 sound.ko 9 1 0xc0d66000 2c0c pflog.ko 10 1 0xc0d69000 d8f4 pccard.ko 11 1 0xc0d77000 b660 cpufreq.ko 12 1 0xc0d83000 1bdc wlan_xauth.ko 13 1 0xc0d85000 2ec0 wlan_acl.ko 14 1 0xc0d88000 30160 iwi_bss.ko 15 1 0xc0db9000 2f350 iwi_ibss.ko 16 1 0xc0de9000 2f4b0 iwi_monitor.ko 17 1 0xc0e19000 10e98 drm.ko 18 1 0xc0e2a000 4d60 atapicam.ko 19 1 0xc0e2f000 81e0 atapicd.ko 20 1 0xc0e38000 4e1134 nvidia.ko 21 1 0xc131a000 69068 acpi.ko 22 1 0xc36a9000 7000 linprocfs.ko 23 1 0xc38dc000 4000 logo_saver.ko Any suggestions? I would be happy to test any patches :-) Patrick -- Patrick Hajek /"\ DOE Joint Genome Institute \ / ASCII RIBBON CAMPAIGN Desk: 925.296.5762 X HELP CURE HTML MAIL Cell: 925.997.4826 / \ PGP Fingerprint 688E B579 3449 28B1 DB14 E15A 76BB C1CA A745 9DAB From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 19:03:32 2007 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 0F08B16A41B for ; Wed, 29 Aug 2007 19:03:32 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id C2B7713C457 for ; Wed, 29 Aug 2007 19:03:31 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so226481nzf for ; Wed, 29 Aug 2007 12:03:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=rUlNUHBiF00u94o7Ux+ztL4C2SiS9cW+6swT9YLR6aUaETR16gV4OeT8CIrej+2Dv7cYnFLRqUeCbcccXhgx9sOFlXqnwhbXqMQJWvomTb7LOcP56SsVs9bAym7I+ZS/J8ZHs2YdTBwnZlxXpLvNatox1jZaEafkOgpc3CQtgSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GoWZh6sY3pXrz//cjCMNln1YrBw1lthNCnv385UiAuH3KaonWMTr/ombJjLUex+HlJ49Q7ZLS44T7yFcrH3j2DquyERe2kVSW12Q9Ys/weMVGtcdw9mrWWHsuEJqxgSx3NtPuGjbUqaQrhbJrF11NmIy4f658a7hsqIZYvRTwN8= Received: by 10.141.171.6 with SMTP id y6mr513759rvo.1188414210270; Wed, 29 Aug 2007 12:03:30 -0700 (PDT) Received: by 10.141.69.3 with HTTP; Wed, 29 Aug 2007 12:03:30 -0700 (PDT) Message-ID: Date: Wed, 29 Aug 2007 23:03:30 +0400 From: pluknet To: "=?ISO-8859-1?Q?Bj=F6rn_K=F6nig?=" In-Reply-To: <-3502020561049594852@unknownmsgid> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <-3502020561049594852@unknownmsgid> Cc: current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 19:03:32 -0000 On 29/08/2007, Bj=F6rn K=F6nig wrote: > Hello, > > what do you think about adding the CPU types "k9" and "k10"? These > processors have support for SSE3 and I noticed up to 15% faster execution > of CPU-intensive programs (e.g. graphics/povray) that have been compiled > using -march=3Dathlon-mp -msse3. > > Regards > Bj=F6rn > there will be no k9. k10 (Barcelona) is successor of k8 and expected to launch late in Q4 of this year(2007). wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 19:06:36 2007 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 7DA7916A418 for ; Wed, 29 Aug 2007 19:06:36 +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 2459513C465 for ; Wed, 29 Aug 2007 19:06:35 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 0AE4B1CC4B; Wed, 29 Aug 2007 21:06:34 +0200 (CEST) Date: Wed, 29 Aug 2007 21:06:34 +0200 From: Ed Schouten To: pluknet Message-ID: <20070829190633.GD21190@hoeg.nl> References: <-3502020561049594852@unknownmsgid> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org, =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 19:06:36 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * pluknet wrote: > there will be no k9. I heard they stopped development, because it turned out to be dog slow. --=20 Ed Schouten WWW: http://g-rave.nl/ --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG1cO552SDGA2eCwURAqi1AJ9ee0DXjajegjn78JcGcKFPPEqsMACfZtec /7YQ9p0KaGpWvmOXnrq6aU0= =8aRw -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 19:13:18 2007 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 47F8B16A421 for ; Wed, 29 Aug 2007 19:13:18 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 0134413C46B for ; Wed, 29 Aug 2007 19:13:15 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 13E9F8C21B8; Wed, 29 Aug 2007 21:13:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an3k2tddvX0J; Wed, 29 Aug 2007 21:13:10 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D09E48C215B; Wed, 29 Aug 2007 21:13:10 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l7TJDA4t050918; Wed, 29 Aug 2007 21:13:10 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 29 Aug 2007 21:13:10 +0200 From: Roman Divacky To: pluknet Message-ID: <20070829191310.GA50909@freebsd.org> References: <-3502020561049594852@unknownmsgid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, Bj?rn K?nig Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 19:13:18 -0000 On Wed, Aug 29, 2007 at 11:03:30PM +0400, pluknet wrote: > On 29/08/2007, Bj?rn K?nig wrote: > > Hello, > > > > what do you think about adding the CPU types "k9" and "k10"? These > > processors have support for SSE3 and I noticed up to 15% faster execution > > of CPU-intensive programs (e.g. graphics/povray) that have been compiled > > using -march=athlon-mp -msse3. > > > > Regards > > Bj?rn > > > > there will be no k9. k10 (Barcelona) is successor of k8 and expected > to launch late in Q4 of this year(2007). I dont think the name matters THAT MUCH, the important thing is to support the newer CPUs with FreeBSD infrastructure... name it "blahblah" if you wish my 2 cents roman From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 19:15:42 2007 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 B756616A41A for ; Wed, 29 Aug 2007 19:15:42 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7004513C4D0 for ; Wed, 29 Aug 2007 19:15:42 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so229178nzf for ; Wed, 29 Aug 2007 12:15:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=ObGiew0NRM4PQIIk94d4t1IhLlEBiXPFcsmUQBi/WyTfIqGkKhYixOzFkuKxLRlyVDHRu3i/THfrazS27Iedk7dQpbZgD3IxI6cRlSqzkteoh8s5brUH4yUvYzFHmmSbpAUoG5VgBnt42t1QFeMVX4u2hh/jcSFYmIhTR0hvw6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZhZYIqPBS9W4cuvv/neNES9buzIMHOH9lMEEib/2A4wCZiHWGkyBSBl9VoVaMeWBrbzDu1qh5S/2qKDGjEARSUR1AsdH7jF0zatcp+3vnKx/vdTeqidBqzZvG+2Z4BLZNIuOLtDKLeuUalJPigwv/L4+hkQINqfjAwbcmQu8BpU= Received: by 10.140.249.20 with SMTP id w20mr522087rvh.1188414941028; Wed, 29 Aug 2007 12:15:41 -0700 (PDT) Received: by 10.141.69.3 with HTTP; Wed, 29 Aug 2007 12:15:40 -0700 (PDT) Message-ID: Date: Wed, 29 Aug 2007 23:15:40 +0400 From: pluknet To: "Ed Schouten" In-Reply-To: <20070829190633.GD21190@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <-3502020561049594852@unknownmsgid> <20070829190633.GD21190@hoeg.nl> Cc: current@freebsd.org, =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 19:15:42 -0000 On 29/08/2007, Ed Schouten wrote: > * pluknet wrote: > > there will be no k9. > > I heard they stopped development, because it turned out to be dog slow. > > -- > Ed Schouten > WWW: http://g-rave.nl/ > > yeap :). As Giuseppe Amato, AMD's Technical Director for EMEA, said that "There was a K9, but its performance was a bit of a dog" :) From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 19:49:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E0B916A419 for ; Wed, 29 Aug 2007 19:49:10 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: from brori.kgt.co.jp (brori.kgt.co.jp [210.141.246.67]) by mx1.freebsd.org (Postfix) with ESMTP id D519313C49D for ; Wed, 29 Aug 2007 19:49:09 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: from navgw.tt.kgt.co.jp (navgw.kgt.co.jp [210.141.246.71]) by brori.kgt.co.jp (Postfix) with ESMTP id 391E8FB1C4 for ; Thu, 30 Aug 2007 04:35:43 +0900 (JST) Received: from localhost (wbbrown.tt.kgt.co.jp [192.168.15.206]) by navgw.tt.kgt.co.jp (Postfix) with ESMTP id D8D9847711 for ; Thu, 30 Aug 2007 04:35:42 +0900 (JST) Date: Thu, 30 Aug 2007 04:35:19 +0900 (JST) Message-Id: <20070830.043519.109271629.haro@kgt.co.jp> To: freebsd-current@freebsd.org From: haro@kgt.co.jp X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Panic with iwi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 19:49:10 -0000 Hi all, I'm currently on travel and staying at Parc 55 Hotel in San Francisco. ;-) Anyway, whenevere I try to connect hotel's wifi network, I get the following panic with iwi, rev 1.55. Back traces where hand written down, so expcect typo. Panic: mutex iwi0 not owned at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:960 panic(..) _mtx_assert(c368f400,1,c0996e4a,3c0,c07aa498,...) at _mtx_assert+0x8d iwi_newstate(c368e004,2,c0,c3a82122,0,...) at iwi_newstate+0x40 ieee80211_sta_join1(c3a820000,c3a5,bb2e,c3a5bb3f,1) at ieee80211_sta_join1+0x1a9 ieee80211_sta_join(c368e004,c3a5bb00,c07e5c76,434,0,c086594000,c367e004,c396a600,e295d54,c391ee00) at ieee80211_sta_join+0x1d4 sta_age(c3655800,db312c84,c0645227,c368e004,db312c68,...) at sta_age+0x3ca ieee80211_scan_timeout(c368e004,db312c68,80246,c0863ee4,db312c84,...) at ieee80211_scan_timeout+0x1c ieee80211_node_timeout(c368e004,0,c07d6354,ef,0,...) at ieee80211_node_timeout+0x17 softclock(0,0,c07d1d8a,471,c356e064,...) at softclock+0x299 ithread_loop(c35704e0,db312d38,c07d1b08,315,c3571559,..) at ithread_loop+0xb5 fork_exit(c056de20, c35704e0, db312d38) at fork_exit+0xb8 fork_trampline() at fork_trampline+0x8 --- trap 0, eip = 0, esp = 0xdb312d70, ebp = 0 --- dmesg: iwi0: mem 0xcfeff000-0xcfefffff irq 11 at device 5.0 on pci1 iwi0: Ethernet address: 00:0e:35:c2:a2:7b iwi0: [ITHREAD] Thanks in advance, Haro =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Internet Solution Dept., KGT Inc. /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 19:58:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF11316A41B for ; Wed, 29 Aug 2007 19:58:11 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 90F1913C461 for ; Wed, 29 Aug 2007 19:58:11 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 6151E1CC58; Thu, 30 Aug 2007 07:58:09 +1200 (NZST) Date: Thu, 30 Aug 2007 07:58:09 +1200 From: Andrew Thompson To: haro@kgt.co.jp Message-ID: <20070829195809.GE43049@heff.fud.org.nz> References: <20070830.043519.109271629.haro@kgt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070830.043519.109271629.haro@kgt.co.jp> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: Panic with iwi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 19:58:12 -0000 On Thu, Aug 30, 2007 at 04:35:19AM +0900, haro@kgt.co.jp wrote: > Hi all, > > I'm currently on travel and staying at Parc 55 Hotel in San Francisco. ;-) > Anyway, whenevere I try to connect hotel's wifi network, I get the following > panic with iwi, rev 1.55. > Back traces where hand written down, so expcect typo. > > Panic: mutex iwi0 not owned at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:960 > > panic(..) > _mtx_assert(c368f400,1,c0996e4a,3c0,c07aa498,...) at _mtx_assert+0x8d > iwi_newstate(c368e004,2,c0,c3a82122,0,...) at iwi_newstate+0x40 > ieee80211_sta_join1(c3a820000,c3a5,bb2e,c3a5bb3f,1) at ieee80211_sta_join1+0x1a9 > ieee80211_sta_join(c368e004,c3a5bb00,c07e5c76,434,0,c086594000,c367e004,c396a600,e295d54,c391ee00) at ieee80211_sta_join+0x1d4 > sta_age(c3655800,db312c84,c0645227,c368e004,db312c68,...) at sta_age+0x3ca > ieee80211_scan_timeout(c368e004,db312c68,80246,c0863ee4,db312c84,...) at ieee80211_scan_timeout+0x1c > ieee80211_node_timeout(c368e004,0,c07d6354,ef,0,...) at ieee80211_node_timeout+0x17 > softclock(0,0,c07d1d8a,471,c356e064,...) at softclock+0x299 > ithread_loop(c35704e0,db312d38,c07d1b08,315,c3571559,..) at ithread_loop+0xb5 > fork_exit(c056de20, c35704e0, db312d38) at fork_exit+0xb8 > fork_trampline() at fork_trampline+0x8 > --- trap 0, eip = 0, esp = 0xdb312d70, ebp = 0 --- The IWI_LOCK_ASSERT() on line 960 is unnecessary and should be removed. Andrew From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 19:49:28 2007 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 7AC8816A496; Wed, 29 Aug 2007 19:49:28 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id 36BD913C457; Wed, 29 Aug 2007 19:49:28 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from home.alpha-tierchen.de (port-212-202-42-154.dynamic.qsc.de [212.202.42.154]) by mail.liberty-hosting.de (Postfix) with ESMTP id A9E383E9847; Wed, 29 Aug 2007 21:51:26 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id 8285545067; Wed, 29 Aug 2007 21:49:24 +0200 (CEST) Received: from 2001:6f8:101e:0:20e:cff:fe6d:6adb (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Wed, 29 Aug 2007 21:49:24 +0200 (CEST) Message-ID: <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <20070829191310.GA50909@freebsd.org> References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> Date: Wed, 29 Aug 2007 21:49:24 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: "Roman Divacky" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Wed, 29 Aug 2007 20:06:37 +0000 Cc: pluknet , current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 19:49:28 -0000 Roman Divacky wrote: > I dont think the name matters THAT MUCH, the important thing is > to support the newer CPUs with FreeBSD infrastructure... name > it "blahblah" if you wish I agree. Intel's first Pentium 4 with SSE3 is called "prescott". We could use "venice" analogously to represent SSE3-capable Athlon64 CPUs. Björn From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 20:23:31 2007 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 3AADE16A418 for ; Wed, 29 Aug 2007 20:23:31 +0000 (UTC) (envelope-from cb@severious.net) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 19DAB13C45B for ; Wed, 29 Aug 2007 20:23:30 +0000 (UTC) (envelope-from cb@severious.net) Received: by ion.gank.org (Postfix, from userid 1001) id 60C6510F40; Wed, 29 Aug 2007 15:08:06 -0500 (CDT) Date: Wed, 29 Aug 2007 15:08:05 -0500 From: Craig Boston To: Dag-Erling Sm??rgrav Message-ID: <20070829200751.GA896@nowhere> Mail-Followup-To: Craig Boston , Dag-Erling Sm??rgrav , Christian Walther , current@freebsd.org References: <46D54E3E.2040803@gmail.com> <86642y3a2t.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86642y3a2t.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i Cc: Christian Walther , current@freebsd.org Subject: Re: Problems moving existing pool to encrypted devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 20:23:31 -0000 On Wed, Aug 29, 2007 at 12:32:26PM +0200, Dag-Erling Sm??rgrav wrote: > # zpool offline pool01 /dev/ad2 > # geli init [...] /dev/ad2 > # zpool replace pool01 /dev/ad2 /dev/ad2.eli This actually may not work either, because the encrypted device is 1 sector smaller than the original... Craig From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 21:11:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAEC616A418 for ; Wed, 29 Aug 2007 21:11:42 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 5270213C478 for ; Wed, 29 Aug 2007 21:11:41 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: by py-out-1112.google.com with SMTP id u77so2556810pyb for ; Wed, 29 Aug 2007 14:11:41 -0700 (PDT) Received: by 10.35.14.18 with SMTP id r18mr1220595pyi.1188420192249; Wed, 29 Aug 2007 13:43:12 -0700 (PDT) Received: from ?10.10.10.47? ( [198.62.158.205]) by mx.google.com with ESMTPS id f77sm15523641pyh.2007.08.29.13.43.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Aug 2007 13:43:11 -0700 (PDT) Message-ID: <46D5D92F.4070608@bellanet.org> Date: Wed, 29 Aug 2007 16:38:07 -0400 From: Graham Todd User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> In-Reply-To: <46D5B46D.5010202@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Encrypted 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: Wed, 29 Aug 2007 21:11:42 -0000 Christian Walther wrote: > Nathan Butcher wrote: >> Yep, using GELI the providers is much better. >> I decided to go one step further and run GLABEL on my drives so my ZFS >> pool will be immune from device enumeration issues (assuming I move the >> drives between systems, SATA raid cards, etc.) [...] > > AFAIK zfs is immune against device enumeration issues itself. There is a > nice video on YouTube showing Sun engineers setting up a ZFS pool on a > bunch of USB sticks. Afterwards they remove all of them, shuffle them, > and put them back in. No problem. > (It's in german and a translation is still missing. But the talk is > stupid anyway, and the acting of the engineers, too.) > This works on FreeBSD, too. As long as you "umount" the filesystem before you pull that USB key? Presumably panicking when a filesystem disappears is a limitation of both UFS and ZFS on FreeBSD :-) > I moved one of my disks to another controller. > ZFS recognised it on reboot. Really nice. :-) Truly having ZFS on FreeBSD *is* really nice. It's amazing how many people are testing and using it at this relatively early stage - probably more on FreeBSD than on Solaris! Kudos and thanks to Pavel for this work. From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 21:20:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3124416A41B for ; Wed, 29 Aug 2007 21:20:50 +0000 (UTC) (envelope-from cb@severious.net) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 17C0913C459 for ; Wed, 29 Aug 2007 21:20:50 +0000 (UTC) (envelope-from cb@severious.net) Received: by ion.gank.org (Postfix, from userid 1001) id BBDF710F40; Wed, 29 Aug 2007 16:20:49 -0500 (CDT) Date: Wed, 29 Aug 2007 16:20:48 -0500 From: Craig Boston To: Christian Walther Message-ID: <20070829212048.GB896@nowhere> Mail-Followup-To: Craig Boston , Christian Walther , Nathan Butcher , freebsd-current@freebsd.org References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D5B46D.5010202@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Nathan Butcher , freebsd-current@freebsd.org Subject: Re: Encrypted 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: Wed, 29 Aug 2007 21:20:50 -0000 On Wed, Aug 29, 2007 at 06:01:17PM +0000, Christian Walther wrote: > AFAIK zfs is immune against device enumeration issues itself. There is a > nice video on YouTube showing Sun engineers setting up a ZFS pool on a > bunch of USB sticks. Afterwards they remove all of them, shuffle them, > and put them back in. No problem. So long as you re-import the pool, this works great. However, I've found that getting ZFS pools recognized on _boot_ can be really delicate. I have a USB stick with a FreeBSD install on it that uses ZFS for everything (gzip compression is great for this). I do use glabel with the hope that it will always be able to find the device the same way no matter if it's da0, da1, whatever. It seems to work fine so long as I'm really careful not to touch it using anything else. Doing a 'zpool import' (even with -R) from another host in order to pull some files off of it seems to be a surefire way to render it unbootable. Copying the zpool.cache file from a machine that has it imported doesn't help the situation either. So far the only way I've found to recover it is to boot a livecd, import the pool, copy zpool.cache to the boot partition, then immediately (without exporting the pool) power off and boot the USB stick on the same hardware. After doing that it's stable again and can boot on pretty much anything. Craig From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 21:52:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 171BA16A41A for ; Wed, 29 Aug 2007 21:52:51 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 7893413C469 for ; Wed, 29 Aug 2007 21:52:50 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 1FA231CC5D; Thu, 30 Aug 2007 09:52:49 +1200 (NZST) Date: Thu, 30 Aug 2007 09:52:49 +1200 From: Andrew Thompson To: haro@kgt.co.jp Message-ID: <20070829215249.GA54430@heff.fud.org.nz> References: <20070830.043519.109271629.haro@kgt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070830.043519.109271629.haro@kgt.co.jp> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: Panic with iwi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 21:52:51 -0000 On Thu, Aug 30, 2007 at 04:35:19AM +0900, haro@kgt.co.jp wrote: > Hi all, > > I'm currently on travel and staying at Parc 55 Hotel in San Francisco. ;-) > Anyway, whenevere I try to connect hotel's wifi network, I get the following > panic with iwi, rev 1.55. This has been fixed in rev 1.56, thanks for reporting the problem. cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 22:03:13 2007 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 334E416A41B for ; Wed, 29 Aug 2007 22:03:13 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id CFABC13C45B for ; Wed, 29 Aug 2007 22:03:12 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (dyn-62-56-112-132.dslaccess.co.uk [62.56.112.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 384043000D; Wed, 29 Aug 2007 22:59:08 +0100 (BST) Message-ID: <46D5ECD9.9020605@cran.org.uk> Date: Wed, 29 Aug 2007 23:02:01 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Roman Divacky , pluknet , current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 22:03:13 -0000 Björn König wrote: > Roman Divacky wrote: > > >> I dont think the name matters THAT MUCH, the important thing is >> to support the newer CPUs with FreeBSD infrastructure... name >> it "blahblah" if you wish >> > > I agree. > > Intel's first Pentium 4 with SSE3 is called "prescott". We could use > "venice" analogously to represent SSE3-capable Athlon64 CPUs. > Would it be possible to indicate whether SSE3 is supported during boot? I have a Turion 64 X2 which from what I've read supports SSE3 but while SSE and SSE2 are listed as CPU features during boot, there's no mention of SSE3. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 22:17:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E18916A41A for ; Wed, 29 Aug 2007 22:17:49 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (crsd-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2d5::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE3513C465 for ; Wed, 29 Aug 2007 22:17:47 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.1/8.14.1) with ESMTP id l7TMHbvx065041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Aug 2007 02:17:38 +0400 (MSD) (envelope-from yuri@darklight.org.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=darklight.org.ru; s=darklight; t=1188425858; bh=uiBIvW2v29LCM0uK/ZQLT8ieEJ1AXiqYUqbii JwNF8w=; h=Received:Date:From:To:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To:User-Agent; b=TPsZVSTuDw9bjx DBAmNAlO/qkD+MRQhlDB+ZaPCSoMlttRdYAHvSPpYWX52Z3JckxEKm/LiptflKMEvoA khtftqkff6fD0lVvx8md4ZGz2ETUVkmGZIR5UJ+32HhFbNnaHsisp3mXCiMauCvLgRl FP8Pvb2NhZ72rZ0wpUGhgTc= Received: (from yuri@localhost) by darklight.org.ru (8.14.1/8.14.1/Submit) id l7TMHb1g065040 for freebsd-current@freebsd.org; Thu, 30 Aug 2007 02:17:37 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Date: Thu, 30 Aug 2007 02:17:37 +0400 From: Yuri Pankov To: freebsd-current@freebsd.org Message-ID: <20070829221737.GD62274@darklight.org.ru> References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> <46D5ECD9.9020605@cran.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <46D5ECD9.9020605@cran.org.uk> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 22:17:49 -0000 On Wed, Aug 29, 2007 at 11:02:01PM +0100, Bruce Cran wrote: > Björn König wrote: >> Roman Divacky wrote: >> >> >>> I dont think the name matters THAT MUCH, the important thing is >>> to support the newer CPUs with FreeBSD infrastructure... name >>> it "blahblah" if you wish >>> >> >> I agree. >> >> Intel's first Pentium 4 with SSE3 is called "prescott". We could use >> "venice" analogously to represent SSE3-capable Athlon64 CPUs. >> > > Would it be possible to indicate whether SSE3 is supported during boot? > I have a Turion 64 X2 which from what I've read supports SSE3 but while SSE > and SSE2 are listed as CPU features during boot, there's no mention of > SSE3. > > -- > Bruce Cran FWIW: It's already indicated during boot for my fairly old Athlon64: CPU: AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20ff0 Stepping = 0 Features=0x78bfbff Features2=0x1 ^^^^^^^^^^^^^^^^^^^ AMD Features=0xe2500800 AMD Features2=0x1 Yuri From owner-freebsd-current@FreeBSD.ORG Wed Aug 29 22:23:05 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 882E016A41A for ; Wed, 29 Aug 2007 22:23:05 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4B46713C478 for ; Wed, 29 Aug 2007 22:23:05 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (dyn-62-56-112-132.dslaccess.co.uk [62.56.112.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 766B93000E; Wed, 29 Aug 2007 23:19:01 +0100 (BST) Message-ID: <46D5F183.4080704@cran.org.uk> Date: Wed, 29 Aug 2007 23:21:55 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: Yuri Pankov References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> <46D5ECD9.9020605@cran.org.uk> <20070829221737.GD62274@darklight.org.ru> In-Reply-To: <20070829221737.GD62274@darklight.org.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 22:23:05 -0000 Yuri Pankov wrote: > On Wed, Aug 29, 2007 at 11:02:01PM +0100, Bruce Cran wrote: > >> Björn König wrote: >> >>> Roman Divacky wrote: >>> >>> >>> >>>> I dont think the name matters THAT MUCH, the important thing is >>>> to support the newer CPUs with FreeBSD infrastructure... name >>>> it "blahblah" if you wish >>>> >>>> >>> I agree. >>> >>> Intel's first Pentium 4 with SSE3 is called "prescott". We could use >>> "venice" analogously to represent SSE3-capable Athlon64 CPUs. >>> >>> >> Would it be possible to indicate whether SSE3 is supported during boot? >> I have a Turion 64 X2 which from what I've read supports SSE3 but while SSE >> and SSE2 are listed as CPU features during boot, there's no mention of >> SSE3. >> >> -- >> Bruce Cran >> > > FWIW: > It's already indicated during boot for my fairly old Athlon64: > > CPU: AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x20ff0 Stepping = 0 > Features=0x78bfbff > Features2=0x1 > ^^^^^^^^^^^^^^^^^^^ > AMD Features=0xe2500800 > AMD Features2=0x1 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 BC37216A417 for ; Wed, 29 Aug 2007 23:37:09 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (penna-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 559F113C494 for ; Wed, 29 Aug 2007 23:37:09 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.1/8.14.1) with ESMTP id l7TNca6K088560 for ; Wed, 29 Aug 2007 19:38:36 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Current@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Q9M4Yz6ZCk0JHECVuSze" Organization: FreeBSD, Inc. Date: Wed, 29 Aug 2007 19:37:04 -0400 Message-Id: <1188430624.1077.21.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: Subject: VT_WAITACTIVE leads to unkillable processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2007 23:37:09 -0000 --=-Q9M4Yz6ZCk0JHECVuSze Content-Type: text/plain Content-Transfer-Encoding: quoted-printable flz and I are working on a port of ConsoleKit to FreeBSD. ConsoleKit is a framework for tracking local users (i.e. users sitting at a machine) and their sessions. =20 Since it tracks local users and their consoles, it makes generous use of consio. One of the things it does is get a list of the total number of available consoles (i.e. vtys) and starts a thread for each one to check when the console becomes active. To do this, each thread invokes the VT_WAITACTIVE ioctl, and sits in waitvt until its vty becomes active. This works quite well. Where things break down is when the ConsoleKit daemon is stopped. When the daemon receives a signal, it immediately jumps to 100% of the CPU and claims to be in waitvt. It will not die unless you reboot the machine, or get lucky with the debugger. Below is a link to a small sample program that will reproduce this behavior. Simply compile the program, and run it from a vty other than 3 (ttyv2). Then try a control+C, and the problem will appear instantly. I've been testing 7.0-CURRENT #104: Thu Aug 16 16:54:28 EDT 2007 with ULE, but I have a report from flz that the same loop is observed on -STABLE with 4BSD. When I ran the test on -STABLE, my box immediately panicked, but I did not have dumps setup. Yes, this is a, "doctor it hurts when I do this" kind of thing; however, since this does not happen on Linux, I'm wondering if the kernel portion of the VT_WAITACTIVE ioctl can be modified not to cause this tight loop (or panic)? WARNING: This running this program will either cause instance on mostly unstoppable CPU load on your machine or panic it. http://www.marcuscom.com/downloads/vty.c gcc -o vty vty.c (switch to ttyv0) ./vty=20 Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-Q9M4Yz6ZCk0JHECVuSze Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG1gMbb2iPiv4Uz4cRArBRAJ9/5NvqyTyactTbpun5pqxKHVk7WwCeLsiG Ne5JJBvOWupK8uHR169gGGc= =fYlu -----END PGP SIGNATURE----- --=-Q9M4Yz6ZCk0JHECVuSze-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 05:33:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4927716A41A for ; Thu, 30 Aug 2007 05:33:40 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: from brori.kgt.co.jp (brori.kgt.co.jp [210.141.246.67]) by mx1.freebsd.org (Postfix) with ESMTP id 113A813C465 for ; Thu, 30 Aug 2007 05:33:39 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: from navgw.tt.kgt.co.jp (navgw.kgt.co.jp [210.141.246.71]) by brori.kgt.co.jp (Postfix) with ESMTP id AE17CFB16F; Thu, 30 Aug 2007 14:33:38 +0900 (JST) Received: from localhost (wbbrown.tt.kgt.co.jp [192.168.15.206]) by navgw.tt.kgt.co.jp (Postfix) with ESMTP id 1F45247712; Thu, 30 Aug 2007 14:33:38 +0900 (JST) Date: Thu, 30 Aug 2007 14:33:35 +0900 (JST) Message-Id: <20070830.143335.89920717.haro@kgt.co.jp> To: thompsa@FreeBSD.org From: haro@kgt.co.jp In-Reply-To: <20070829215249.GA54430@heff.fud.org.nz> References: <20070830.043519.109271629.haro@kgt.co.jp> <20070829215249.GA54430@heff.fud.org.nz> X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Panic with iwi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 05:33:40 -0000 From: Andrew Thompson Date: Thu, 30 Aug 2007 09:52:49 +1200 ::On Thu, Aug 30, 2007 at 04:35:19AM +0900, haro@kgt.co.jp wrote: ::> Hi all, ::> ::> I'm currently on travel and staying at Parc 55 Hotel in San Francisco. ;-) ::> Anyway, whenevere I try to connect hotel's wifi network, I get the following ::> panic with iwi, rev 1.55. :: ::This has been fixed in rev 1.56, thanks for reporting the problem. Hi Andrew, Thank you for your quick responce. It's seems to be working perfectly, as I'm typing this email through the hotel wifi. Thank you, haro =----------------------------------------------------------------------- _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| KGT Inc. /|\ |_| |_|_| 2-8-8 Shinjuku, Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 06:52:46 2007 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 4094016A419; Thu, 30 Aug 2007 06:52:46 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id F0F9713C459; Thu, 30 Aug 2007 06:52:45 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from home.alpha-tierchen.de (port-212-202-42-154.dynamic.qsc.de [212.202.42.154]) by mail.liberty-hosting.de (Postfix) with ESMTP id AF6FF3E98A8; Thu, 30 Aug 2007 08:23:41 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id 4356345067; Thu, 30 Aug 2007 08:21:41 +0200 (CEST) Received: from 2001:6f8:101e:0:20e:cff:fe6d:6adb (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Thu, 30 Aug 2007 08:21:41 +0200 (CEST) Message-ID: <53056.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188454901.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <46D5ECD9.9020605@cran.org.uk> References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> <46D5ECD9.9020605@cran.org.uk> Date: Thu, 30 Aug 2007 08:21:41 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: "Bruce Cran" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Roman Divacky , pluknet , current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 06:52:46 -0000 Bruce Cran wrote: > Would it be possible to indicate whether SSE3 is supported during > boot? I have a Turion 64 X2 which from what I've read supports SSE3 > but while SSE and SSE2 are listed as CPU features during boot, there's > no mention of SSE3. It is shown in the feature list 2: > grep SSE3 /var/run/dmesg.boot Features2=0x1 Björn From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 06:56:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1064516A41B for ; Thu, 30 Aug 2007 06:56:53 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id D475A13C46B for ; Thu, 30 Aug 2007 06:56:52 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IQdxD-00034i-Od; Thu, 30 Aug 2007 15:56:35 +0900 Message-ID: <46D66A23.3060108@fusiongol.com> Date: Thu, 30 Aug 2007 15:56:35 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Walther References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> In-Reply-To: <46D5B46D.5010202@gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Abuse-Complaints: abuse@gol.com Cc: freebsd-current@freebsd.org Subject: Re: Encrypted 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: Thu, 30 Aug 2007 06:56:53 -0000 > AFAIK zfs is immune against device enumeration issues itself. There is a > nice video on YouTube showing Sun engineers setting up a ZFS pool on a > bunch of USB sticks. Afterwards they remove all of them, shuffle them, > and put them back in. No problem. You're correct,... only as long as the zpool is EXPORTED FIRST, and imported after the drives have been shuffled around. ZFS has no trouble piecing them back together wherever they are during an import, it seems. If you were to, say, forget to export the zpool, shutdown your system, shuffle the drives around, and THEN restart the system with the drives in the wrong places, zfs will consider the zpool unavailable. In this case, all the drives will be turn up as FAULTED due to "corrupted data"... when in reality, ZFS was set up to expect certain data to be on certain drives, and now it just can't find it thanks to the harddrive "hokey-pokey" done on it. I guess glabeling isn't really necessary, but it does prevent the above issue from ever occuring.... "An ounce of prevention" or something like that. From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 07:19:33 2007 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 626C416A41A for ; Thu, 30 Aug 2007 07:19:33 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 13B5C13C465 for ; Thu, 30 Aug 2007 07:19:33 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 9312D1B10F18; Thu, 30 Aug 2007 09:19:31 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 860311B10F14; Thu, 30 Aug 2007 09:19:31 +0200 (CEST) Message-ID: <46D66F83.2050208@moneybookers.com> Date: Thu, 30 Aug 2007 10:19:31 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.4pre (X11/20070711) MIME-Version: 1.0 To: Roman Divacky References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> In-Reply-To: <20070829191310.GA50909@freebsd.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: pluknet , current@freebsd.org, Bj?rn K?nig Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 07:19:33 -0000 Hi all, Roman Divacky wrote: > On Wed, Aug 29, 2007 at 11:03:30PM +0400, pluknet wrote: > >> On 29/08/2007, Bj?rn K?nig wrote: >> >>> Hello, >>> >>> what do you think about adding the CPU types "k9" and "k10"? These >>> processors have support for SSE3 and I noticed up to 15% faster execution >>> of CPU-intensive programs (e.g. graphics/povray) that have been compiled >>> using -march=athlon-mp -msse3. >>> >>> Regards >>> Bj?rn >>> >>> >> there will be no k9. k10 (Barcelona) is successor of k8 and expected >> to launch late in Q4 of this year(2007). >> > > I dont think the name matters THAT MUCH, the important thing is to support > the newer CPUs with FreeBSD infrastructure... name it "blahblah" if you wish > Why not to use the same name that GCC use for those processors. If we use different names then gcc, it will make things little more complicated, and I do not see why we have to do this. Also for processor names we have references to gcc manual. From /usr/share/mk/bsd.cpu.mk : ############################################################################### # Logic to set up correct gcc optimization flag. This must be included # after /etc/make.conf so it can react to the local value of CPUTYPE # defined therein. Consult: # http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html # http://gcc.gnu.org/onlinedocs/gcc/IA-64-Options.html # http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html # http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html # http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html And suggested by GCC the CPU types are: k8-sse3, opteron-sse3, athlon64-sse3 Improved versions of k8, opteron and athlon64 with SSE3 instruction set support. amdfam10, barcelona AMD Family 10h core based CPUs with x86-64 instruction set support. (This supersets MMX, SSE, SSE2, SSE3, SSE4A, 3dNOW!, enhanced 3dNOW!, ABM and 64-bit instruction set extensions.) P.S. The working link is - http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options Someone is willing to fill PR? :) > my 2 cents > roman > _______________________________________________ > 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" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 07:48:40 2007 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 2E63C16A418 for ; Thu, 30 Aug 2007 07:48:40 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id E1C9213C474 for ; Thu, 30 Aug 2007 07:48:39 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 52C392095; Thu, 30 Aug 2007 09:47:59 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id C5BAE2094; Thu, 30 Aug 2007 09:47:58 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 7F22184483; Thu, 30 Aug 2007 09:47:58 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Craig Boston References: <46D54E3E.2040803@gmail.com> <86642y3a2t.fsf@ds4.des.no> <20070829200751.GA896@nowhere> Date: Thu, 30 Aug 2007 09:47:58 +0200 In-Reply-To: <20070829200751.GA896@nowhere> (Craig Boston's message of "Wed\, 29 Aug 2007 15\:08\:05 -0500") Message-ID: <863ay11n0x.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Christian Walther , current@freebsd.org Subject: Re: Problems moving existing pool to encrypted devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 07:48:40 -0000 Craig Boston writes: > Dag-Erling Sm=C3=B8rgrav writes: > > # zpool offline pool01 /dev/ad2 > > # geli init [...] /dev/ad2 > > # zpool replace pool01 /dev/ad2 /dev/ad2.eli > This actually may not work either, because the encrypted device is 1 > sector smaller than the original... Ah, you're right. There is no other option than to either replace all disks, one by one, with larger ones, or to dump the data, rebuild the array from scratch and restore the data. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 11:58:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 808D116A419 for ; Thu, 30 Aug 2007 11:58:48 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from akis.salford.ac.uk (akis.salford.ac.uk [146.87.0.14]) by mx1.freebsd.org (Postfix) with SMTP id F3D7313C469 for ; Thu, 30 Aug 2007 11:58:47 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 35921 invoked by uid 98); 30 Aug 2007 12:58:07 +0100 Received: from 146.87.255.121 by akis.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.90/3843. spamassassin: 3.1.8. Clear:RC:1(146.87.255.121):. Processed in 0.042306 secs); 30 Aug 2007 11:58:07 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by akis.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 30 Aug 2007 12:58:07 +0100 Received: (qmail 58630 invoked by uid 1002); 30 Aug 2007 11:58:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Aug 2007 11:58:05 -0000 Date: Thu, 30 Aug 2007 12:58:05 +0100 (BST) From: "Mark Powell" To: Brooks Talley In-Reply-To: <16447218.32631188324732895.JavaMail.root@zmail.illuminati.org> Message-ID: <20070830124435.W58590@rust.salford.ac.uk> References: <16447218.32631188324732895.JavaMail.root@zmail.illuminati.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current Subject: Re: Tidbit for improving Samba 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: Thu, 30 Aug 2007 11:58:48 -0000 On Tue, 28 Aug 2007, Brooks Talley wrote: > Right now, with net.inet.tcp.recvspace and net.inet.tcp.sendspace both > at 65536 and SO_RCVBUF and SO_SNDBUF also at 65536, I'm seeing about > 60MB/s. Still not great, but a significant improvement. FWIW, going > higher than 65536 causes the Vista workstation to lose its mapped drive > all the time. And changing the MTU on both FreeBSD and Vista (to either > 4088 or 9014) had no discernable benefit. I've been doing the same. I must have tried so many combinations though. It really is a black art :( I agree that 65536 for all 4 options is probably about the best combination. Thanks. I'm seeing 54MB/s peak write from XP box to FBSD though and 40MB/s peak read. > This is on a 7.0-CURRENT compiled without all of the debugging stuff, > and it's at 0.7 load and 73% idle when transferring 60MB/s, so I think > there's still some headroom there for improvement. This is onto a ZFS RAIDZ1 onto 3x500GB drives which can achieve 120MB/s write and 160MB/s read under FBSD. This is between 2xPCI-X Intel PRO1000 server adapters 82545 in 32bit/33MHz PCI slots. They are the only active devices on the PCI bus, so I would expect more. Simple tests with dd when FBSD is on both boxes, can easily achieve 87-90MB/s. > Anyways, thought I'd share with the group, since I haven't seen this > mentioned in copious amounts of Googling. I too found a derth of information on this matter for FBSD. I'm current using the following in smb.conf: socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65536 SO_RCVBUF=65536 strict locking = no use sendfile = yes What do you have in there? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 13:11:06 2007 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 1B03916A418; Thu, 30 Aug 2007 13:11:06 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB0A13C45A; Thu, 30 Aug 2007 13:11:05 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7UBx0FN003992; Thu, 30 Aug 2007 08:59:00 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Thu, 30 Aug 2007 08:59:11 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> In-Reply-To: <20070829191310.GA50909@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708300859.13098.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Roman Divacky , pluknet , current@freebsd.org, bkoenig@cs.tu-berlin.de Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 13:11:06 -0000 On Wednesday 29 August 2007 16:13:10 Roman Divacky wrote: > On Wed, Aug 29, 2007 at 11:03:30PM +0400, pluknet wrote: > > On 29/08/2007, Bj?rn K?nig wrote: > > > Hello, > > > > > > what do you think about adding the CPU types "k9" and "k10"? These > > > processors have support for SSE3 and I noticed up to 15% faster > > > execution of CPU-intensive programs (e.g. graphics/povray) that have > > > been compiled using -march=3Dathlon-mp -msse3. > > > > > > Regards > > > Bj?rn > > > > there will be no k9. k10 (Barcelona) is successor of k8 and expected > > to launch late in Q4 of this year(2007). > > I dont think the name matters THAT MUCH, the important thing is to support > the newer CPUs with FreeBSD infrastructure... name it "blahblah" if you > wish > not so sure about this ... specially not *this* name you suggest :) but athlon64-x2 for S940 and athlon64-am2 for sse3 capable cpus would be ki= nd=20 of understandable for all I think all this cpus are revision E and higher and should understand SSE3 for opterons a note in make.conf might be usefull venice as said in another mail is not clear for all people and certainly it= =20 does not appear on the box or elsewhere =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 13:11:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B03916A418; Thu, 30 Aug 2007 13:11:06 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB0A13C45A; Thu, 30 Aug 2007 13:11:05 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7UBx0FN003992; Thu, 30 Aug 2007 08:59:00 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Thu, 30 Aug 2007 08:59:11 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> In-Reply-To: <20070829191310.GA50909@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708300859.13098.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Roman Divacky , pluknet , current@freebsd.org, bkoenig@cs.tu-berlin.de Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 13:11:06 -0000 On Wednesday 29 August 2007 16:13:10 Roman Divacky wrote: > On Wed, Aug 29, 2007 at 11:03:30PM +0400, pluknet wrote: > > On 29/08/2007, Bj?rn K?nig wrote: > > > Hello, > > > > > > what do you think about adding the CPU types "k9" and "k10"? These > > > processors have support for SSE3 and I noticed up to 15% faster > > > execution of CPU-intensive programs (e.g. graphics/povray) that have > > > been compiled using -march=3Dathlon-mp -msse3. > > > > > > Regards > > > Bj?rn > > > > there will be no k9. k10 (Barcelona) is successor of k8 and expected > > to launch late in Q4 of this year(2007). > > I dont think the name matters THAT MUCH, the important thing is to support > the newer CPUs with FreeBSD infrastructure... name it "blahblah" if you > wish > not so sure about this ... specially not *this* name you suggest :) but athlon64-x2 for S940 and athlon64-am2 for sse3 capable cpus would be ki= nd=20 of understandable for all I think all this cpus are revision E and higher and should understand SSE3 for opterons a note in make.conf might be usefull venice as said in another mail is not clear for all people and certainly it= =20 does not appear on the box or elsewhere =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 17:47:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CECE316A41B for ; Thu, 30 Aug 2007 17:47:29 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from abbe.salford.ac.uk (abbe.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id 4808613C45B for ; Thu, 30 Aug 2007 17:47:28 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 14016 invoked by uid 98); 30 Aug 2007 18:47:11 +0100 Received: from 146.87.255.121 by abbe.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.90/3838. spamassassin: 3.1.8. Clear:RC:1(146.87.255.121):. Processed in 0.044917 secs); 30 Aug 2007 17:47:11 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by abbe.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 30 Aug 2007 18:47:11 +0100 Received: (qmail 60919 invoked by uid 1002); 30 Aug 2007 17:47:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Aug 2007 17:47:09 -0000 Date: Thu, 30 Aug 2007 18:47:09 +0100 (BST) From: "Mark Powell" To: freebsd-current@freebsd.org Message-ID: <20070830183305.X60345@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Another ZFS kernel panic on same block on every drive in raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 17:47:29 -0000 Hi, I am testing a 3 drive raidz1 array which has been built with 3 new WD 500GB SATA drives /dev/ad1[468], bought from 2 different sources. I am being told that a dma error is occuring on the same block on all 3 drives at the same time: Aug 30 18:13:15 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 Aug 30 18:13:15 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 Aug 30 18:13:15 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad14: FAILURE - WRITE_DMA timed out LBA=268435340 Aug 30 18:13:46 echo kernel: ad16: FAILURE - WRITE_DMA timed out LBA=268435340 Aug 30 18:13:46 echo kernel: ad18: FAILURE - WRITE_DMA timed out LBA=268435340 Aug 30 18:13:46 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad18: FAILURE - WRITE_DMA timed out LBA=268435340 Aug 30 18:13:46 echo kernel: ad14: FAILURE - WRITE_DMA timed out LBA=268435340 Aug 30 18:13:46 echo kernel: ad16: FAILURE - WRITE_DMA timed out LBA=268435340 Aug 30 18:13:46 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 Aug 30 18:13:46 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 Aug 30 18:13:25 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad14s2 offset=132076011520 size=65536 error=5 Aug 30 18:13:25 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad16s2 offset=132076011520 size=65536 error=5 Aug 30 18:13:25 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad18s2 offset=132076011520 size=65536 error=5 Aug 30 18:13:41 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad18s2 offset=132076011520 size=65536 error=5 Aug 30 18:13:41 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad14s2 offset=132076011520 size=65536 error=5 Aug 30 18:13:41 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad16s2 offset=132076011520 size=65536 error=5 Aug 30 18:13:41 echo root: ZFS: vdev I/O failure, zpool=pool path= offset=396215451648 size=131072 error=5 And then the kernel panics: panic: ZFS: I/O failure (write on off 0: zio 0xffffff0013b0d000 [L0 ZFS plain file] 20000L/20000P DVA[0]=<5:5c40480000:30000> fletcher2 uncompressed LE contiguous birth=20167 fill=1 cksum=cfcfcfcfcfcfce00:cfcfcfcfcfcfce00:8a8a8a8a8a56e700:8a8a8a8a8a56e cpuid = 0 I think I saw someone else have a similar problem to this. There were told their hardware was probably flakey on to look for errors with geli. Just performing a scrub now to see what happens. Let me know if you need any further info. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 17:57:09 2007 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 8BEA916A417 for ; Thu, 30 Aug 2007 17:57:09 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1723413C46B for ; Thu, 30 Aug 2007 17:57:08 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so237143ugf for ; Thu, 30 Aug 2007 10:56:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=AO9o+hkbbNrShWazycm5Yt7Z8HI0SyMnx/Erkaw2QKJFuWJjdOSUnCvfgNQjj5gw1rPj4Ynps2tintpdU8tP2GDqhcB0BtxvG6jhtPXh9ue1iVbKdfwugQOWvY92S87xmghiLuzW0fEsDmhh1f+f/Tx8Q+y70gLLrCaRcqNXuR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=ti+UHG6Qv1XxQd+3F+E7yRmt4LJXL6QhPhVcdkFZRcFUKiPNhbJXwmpqcawuU+gAW/1lFIPQj1Ydvd9ccTBzK4Himq6aIIqwO3CFAAPlay8IFUu/8qAYluVxy0AAH+LT3Q8vwAxkMcawSERDIEs1N6uSHsk0rmTjRM63uVOX6hw= Received: by 10.78.130.6 with SMTP id c6mr551361hud.1188496612934; Thu, 30 Aug 2007 10:56:52 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.190.153]) by mx.google.com with ESMTPS id 37sm1017631hub.2007.08.30.10.56.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Aug 2007 10:56:52 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l7UHumjb002213 for ; Thu, 30 Aug 2007 19:56:48 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l7UHum0I002212 for current@freebsd.org; Thu, 30 Aug 2007 19:56:48 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Thu, 30 Aug 2007 19:56:48 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20070830175648.GA1453@roadrunner.spoerlein.net> Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: panic: geli vs. zfs scrubbing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 17:57:09 -0000 Hi -current, I found a reproducible panic with GELI's 'detach on close' feature interfering with 'zpool scrub' of an eli provider. root@roadrunner: ~# zpool status pool: tank state: ONLINE scrub: scrub completed with 0 errors on Thu Aug 30 19:35:14 2007 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 ad0s4d.eli ONLINE 0 0 0 Where /usr and /var are on tank (among others). This setup is working just fine (module buffer cache anomalies). Anyway, I issued a 'zpool scrub tank' just for kicks, here's the panic (hand transcribed): # zpool scrub tank GEOM_ELI: Detached ad0s4d.eli on last close. panic: function g_eli_orphan_spoil_assert() called for ad0s4d.eli panic() g_eli_orphan_spoil_assert() g_spoil_event() g_run_events() g_event_procbody() The workaround is to set geli_autodetach=NO in /etc/rc.conf. After that, scrubbing is doing its thing. Would be nice to have something like geli detach -l, which turns *off* the close-on-detach flag for an already attached provider. That way, you can use it as a one-shot workaround. 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 Aug 30 18:13:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EDC316A419 for ; Thu, 30 Aug 2007 18:13:48 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from akis.salford.ac.uk (akis.salford.ac.uk [146.87.0.14]) by mx1.freebsd.org (Postfix) with SMTP id BD39A13C442 for ; Thu, 30 Aug 2007 18:13:47 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 5657 invoked by uid 98); 30 Aug 2007 19:13:28 +0100 Received: from 146.87.255.121 by akis.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.90/3843. spamassassin: 3.1.8. Clear:RC:1(146.87.255.121):. Processed in 0.046144 secs); 30 Aug 2007 18:13:28 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by akis.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 30 Aug 2007 19:13:27 +0100 Received: (qmail 61170 invoked by uid 1002); 30 Aug 2007 18:13:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Aug 2007 18:13:25 -0000 Date: Thu, 30 Aug 2007 19:13:25 +0100 (BST) From: "Mark Powell" To: Mark Powell In-Reply-To: <20070830183305.X60345@rust.salford.ac.uk> Message-ID: <20070830190328.B60345@rust.salford.ac.uk> References: <20070830183305.X60345@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Another ZFS kernel panic on same block on every drive in raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 18:13:48 -0000 On Thu, 30 Aug 2007, Mark Powell wrote: > I am being told that a dma error is occuring on the same block on all 3 > drives at the same time: > > Just performing a scrub now to see what happens. The scrub performed fine. The panic is occuring under heavyish use; with 3 simultaneous rsync from an XP box over samba. Just recalled that it paniced earlier, but I was in X and couldn't see the message. Surprisingly it did log something: Aug 30 17:27:48 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435298 Aug 30 17:28:29 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435297 Aug 30 17:28:29 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435297 Aug 30 17:28:29 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435298 Aug 30 17:28:29 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435297 Aug 30 17:28:29 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435297 Aug 30 17:28:29 echo kernel: ad14: FAILURE - WRITE_DMA timed out LBA=268435298 Aug 30 17:28:29 echo kernel: ad18: FAILURE - WRITE_DMA timed out LBA=268435297 Aug 30 17:28:29 echo kernel: ad16: FAILURE - WRITE_DMA timed out LBA=268435297 Aug 30 17:28:29 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435297 Aug 30 17:28:29 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435298 Aug 30 17:28:29 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435297 Aug 30 17:28:29 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435297 Aug 30 17:28:29 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435298 Aug 30 17:28:29 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435297 Aug 30 17:28:29 echo kernel: ad18: FAILURE - WRITE_DMA timed out LBA=268435297 Aug 30 17:28:29 echo kernel: ad14: FAILURE - WRITE_DMA timed out LBA=268435298 Aug 30 17:28:29 echo kernel: ad16: FAILURE - WRITE_DMA timed out LBA=268435297 Aug 30 17:28:29 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435425 Aug 30 17:28:29 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435426 Aug 30 17:28:29 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435425 Aug 30 17:28:29 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435425 Aug 30 17:28:29 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435426 Aug 30 17:28:29 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435425 Aug 30 17:28:29 echo kernel: ad18: FAILURE - WRITE_DMA timed out LBA=268435425 Aug 30 17:28:29 echo kernel: ad14: FAILURE - WRITE_DMA timed out LBA=268435426 Here the blocks are different and 4 blocks overall are reported as having problems. In hex they all start FFFFFxx ? They are (including the one from the previous report): 268435297 fffff61 268435298 fffff62 268435340 fffff8c 268435425 fffffe1 268435426 fffffe2 Coincidence? This is on amd64 with all drives connected to the ICH9 ports on a Gigabyte Intel P35 based MB. Current is from 25/8/7. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 18:19:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D26EA16A418 for ; Thu, 30 Aug 2007 18:19:40 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from abbe.salford.ac.uk (abbe.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id 3322613C46A for ; Thu, 30 Aug 2007 18:19:39 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 27820 invoked by uid 98); 30 Aug 2007 19:19:20 +0100 Received: from 146.87.255.121 by abbe.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.90/3838. spamassassin: 3.1.8. Clear:RC:1(146.87.255.121):. Processed in 0.040928 secs); 30 Aug 2007 18:19:20 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by abbe.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 30 Aug 2007 19:19:20 +0100 Received: (qmail 61201 invoked by uid 1002); 30 Aug 2007 18:19:18 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Aug 2007 18:19:18 -0000 Date: Thu, 30 Aug 2007 19:19:18 +0100 (BST) From: "Mark Powell" To: freebsd-current@freebsd.org In-Reply-To: <20070830190328.B60345@rust.salford.ac.uk> Message-ID: <20070830191654.B60345@rust.salford.ac.uk> References: <20070830183305.X60345@rust.salford.ac.uk> <20070830190328.B60345@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: Another ZFS kernel panic on same block on every drive in raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 18:19:40 -0000 On Thu, 30 Aug 2007, Mark Powell wrote: > Current is from 25/8/7. Sorry that should be 25/7/7. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 19:28:34 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 052B416A41A; Thu, 30 Aug 2007 19:28:34 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id C036D13C46A; Thu, 30 Aug 2007 19:28:33 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from [192.168.1.211] (baba.farley.org [192.168.1.211] (may be forged)) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l7UJS8T1050310; Thu, 30 Aug 2007 14:28:08 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Thu, 30 Aug 2007 14:28:07 -0500 (CDT) From: "Sean C. Farley" To: freebsd-current@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.farley.org Cc: Wes Peters Subject: Multiple aliases with dhclient X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 19:28:34 -0000 Here is a simple patch[1] that protects existing IP's on an interface from being erased by the dhclient during the PREINIT stage. dhclient-script (the real culprit) replaces the first IP on an interface with this line: ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.255 up My solution is to have this be declared an alias, so existing IP's will stay even after the script replaces this entry with the obtained IP. This is needed, at least by me, to have multiple aliases on an interface that's primary IP is obtained by DHCP. Also, dhclient only supports having one alias on an interface via dhclient.conf. I heard no complaints from net@ [2] and one "sounds correct" from brooks@ (thank you), but I still wonder if there is something I am not considering that would cause problems for other people. Sean 1. http://www.farley.org/freebsd/tmp/dhclient-script.patch 2. http://lists.freebsd.org/pipermail/freebsd-net/2007-August/015155.html -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 19:38:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AD6616A421 for ; Thu, 30 Aug 2007 19:38:39 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id B225313C483 for ; Thu, 30 Aug 2007 19:38:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DD38245EBB; Thu, 30 Aug 2007 21:38:22 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 9DD3A45683; Thu, 30 Aug 2007 21:38:18 +0200 (CEST) Date: Thu, 30 Aug 2007 21:37:10 +0200 From: Pawel Jakub Dawidek To: Mark Powell Message-ID: <20070830193709.GG3047@garage.freebsd.pl> References: <20070830183305.X60345@rust.salford.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5dNcufZ4prhark0F" Content-Disposition: inline In-Reply-To: <20070830183305.X60345@rust.salford.ac.uk> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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: freebsd-current@freebsd.org Subject: Re: Another ZFS kernel panic on same block on every drive in raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 19:38:39 -0000 --5dNcufZ4prhark0F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 30, 2007 at 06:47:09PM +0100, Mark Powell wrote: > Hi, > I am testing a 3 drive raidz1 array which has been built with 3 new WD= =20 > 500GB SATA drives /dev/ad1[468], bought from 2 different sources. > I am being told that a dma error is occuring on the same block on all 3= =20 > drives at the same time: >=20 > Aug 30 18:13:15 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry= =20 > left) LBA=3D268435340 This looks like a bug in ATA described in kern/115572. Can you try the patch proposed by Soren there? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --5dNcufZ4prhark0F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1xxlForvXbEpPzQRAqSHAKC5iMD4WUQahyeNqs3ttJn+EcC8xQCgy9KB xnFCb9jg2wIGF+pUuEz1yBk= =UZk1 -----END PGP SIGNATURE----- --5dNcufZ4prhark0F-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 19:40:34 2007 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 EA04916A468 for ; Thu, 30 Aug 2007 19:40:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 89BFE13C46E for ; Thu, 30 Aug 2007 19:40:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3379845ED7; Thu, 30 Aug 2007 21:40:14 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A16D945EA7 for ; Thu, 30 Aug 2007 21:40:08 +0200 (CEST) Date: Thu, 30 Aug 2007 21:38:58 +0200 From: Pawel Jakub Dawidek To: current@freebsd.org Message-ID: <20070830193858.GH3047@garage.freebsd.pl> References: <20070830175648.GA1453@roadrunner.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m+jEI8cDoTn6Mu9E" Content-Disposition: inline In-Reply-To: <20070830175648.GA1453@roadrunner.spoerlein.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.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: Subject: Re: panic: geli vs. zfs scrubbing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 19:40:35 -0000 --m+jEI8cDoTn6Mu9E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 30, 2007 at 07:56:48PM +0200, Ulrich Spoerlein wrote: > Hi -current, >=20 > I found a reproducible panic with GELI's 'detach on close' feature > interfering with 'zpool scrub' of an eli provider. >=20 > root@roadrunner: ~# zpool status > pool: tank > state: ONLINE > scrub: scrub completed with 0 errors on Thu Aug 30 19:35:14 2007 > config: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > ad0s4d.eli ONLINE 0 0 0 >=20 > Where /usr and /var are on tank (among others). This setup is working > just fine (module buffer cache anomalies). Anyway, I issued a 'zpool > scrub tank' just for kicks, here's the panic (hand transcribed): >=20 > # zpool scrub tank > GEOM_ELI: Detached ad0s4d.eli on last close. > panic: function g_eli_orphan_spoil_assert() called for ad0s4d.eli > panic() > g_eli_orphan_spoil_assert() > g_spoil_event() > g_run_events() > g_event_procbody() Yes, ZFS doesn't open providers and keep them open, it just opens them as needed, so GELI detach-on-close feature is no good here. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --m+jEI8cDoTn6Mu9E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1xzSForvXbEpPzQRAloEAJsGgQ7KPkwe03Q2eJWXMaZocs9W6QCg+ko+ aoj7BSP79pPR1W6v1AOoKlI= =2WFI -----END PGP SIGNATURE----- --m+jEI8cDoTn6Mu9E-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 21:15:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE9D16A480 for ; Thu, 30 Aug 2007 21:15:12 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from abbe.salford.ac.uk (abbe.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id 296F613C46A for ; Thu, 30 Aug 2007 21:15:11 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 8895 invoked by uid 98); 30 Aug 2007 22:15:10 +0100 Received: from 146.87.255.121 by abbe.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.90/3838. spamassassin: 3.1.8. Clear:RC:1(146.87.255.121):. Processed in 0.043142 secs); 30 Aug 2007 21:15:10 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by abbe.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 30 Aug 2007 22:15:10 +0100 Received: (qmail 81656 invoked by uid 1002); 30 Aug 2007 21:15:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Aug 2007 21:15:08 -0000 Date: Thu, 30 Aug 2007 22:15:08 +0100 (BST) From: "Mark Powell" To: Pawel Jakub Dawidek In-Reply-To: <20070830193709.GG3047@garage.freebsd.pl> Message-ID: <20070830221332.U61366@rust.salford.ac.uk> References: <20070830183305.X60345@rust.salford.ac.uk> <20070830193709.GG3047@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Another ZFS kernel panic on same block on every drive in raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 21:15:12 -0000 On Thu, 30 Aug 2007, Pawel Jakub Dawidek wrote: > This looks like a bug in ATA described in kern/115572. Can you try the > patch proposed by Soren there? Works great. Thanks for spotting that Pawel. Cheers to Soren too for the patch. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 23:07:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E707F16A41B for ; Thu, 30 Aug 2007 23:07:32 +0000 (UTC) (envelope-from prvs=176275eba5=killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 54FD413C46A for ; Thu, 30 Aug 2007 23:07:31 +0000 (UTC) (envelope-from prvs=176275eba5=killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 ([212.135.219.182]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.6.0) with ESMTP id md50004157642.msg for ; Thu, 30 Aug 2007 23:49:27 +0100 Message-ID: <03b401c7eb57$ee714030$b6db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Mark Powell" , References: <20070830183305.X60345@rust.salford.ac.uk> Date: Thu, 30 Aug 2007 23:48:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-MDRemoteIP: 212.135.219.182 X-Return-Path: prvs=176275eba5=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-Spam-Processed: multiplay.co.uk, Thu, 30 Aug 2007 23:49:27 +0100 X-MDAV-Processed: multiplay.co.uk, Thu, 30 Aug 2007 23:49:27 +0100 Cc: Subject: Re: Another ZFS kernel panic on same block on every drive in raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2007 23:07:33 -0000 That sounds very much like an overflow error on the controller / drive. We had a very similar issue with the Highpoint 1820a drivers which turned out to be compatibility issue with the drive firmware and the controller. The controller was using standard LBA to access the drive up until the point where 48-bit LBA was required. This caused issues with, in this case Seagate drives, which would report an error when using this method after a specific point. The fix was for the controller to always use 48-bit addressing for the drives which supported it. Hope this helps. Regards Steve ----- Original Message ----- From: "Mark Powell" To: Sent: Thursday, August 30, 2007 6:47 PM Subject: Another ZFS kernel panic on same block on every drive in raidz > Hi, > I am testing a 3 drive raidz1 array which has been built with 3 new WD > 500GB SATA drives /dev/ad1[468], bought from 2 different sources. > I am being told that a dma error is occuring on the same block on all 3 > drives at the same time: > > Aug 30 18:13:15 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 > Aug 30 18:13:15 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 > Aug 30 18:13:15 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad14: FAILURE - WRITE_DMA timed out LBA=268435340 > Aug 30 18:13:46 echo kernel: ad16: FAILURE - WRITE_DMA timed out LBA=268435340 > Aug 30 18:13:46 echo kernel: ad18: FAILURE - WRITE_DMA timed out LBA=268435340 > Aug 30 18:13:46 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad18: FAILURE - WRITE_DMA timed out LBA=268435340 > Aug 30 18:13:46 echo kernel: ad14: FAILURE - WRITE_DMA timed out LBA=268435340 > Aug 30 18:13:46 echo kernel: ad16: FAILURE - WRITE_DMA timed out LBA=268435340 > Aug 30 18:13:46 echo kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad18: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 > Aug 30 18:13:46 echo kernel: ad16: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=268435340 > Aug 30 18:13:25 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad14s2 offset=132076011520 size=65536 error=5 > Aug 30 18:13:25 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad16s2 offset=132076011520 size=65536 error=5 > Aug 30 18:13:25 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad18s2 offset=132076011520 size=65536 error=5 > Aug 30 18:13:41 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad18s2 offset=132076011520 size=65536 error=5 > Aug 30 18:13:41 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad14s2 offset=132076011520 size=65536 error=5 > Aug 30 18:13:41 echo root: ZFS: vdev I/O failure, zpool=pool path=/dev/ad16s2 offset=132076011520 size=65536 error=5 > Aug 30 18:13:41 echo root: ZFS: vdev I/O failure, zpool=pool path= offset=396215451648 size=131072 error=5 > > And then the kernel panics: > > panic: ZFS: I/O failure (write on off 0: zio 0xffffff0013b0d000 > [L0 ZFS plain file] 20000L/20000P DVA[0]=<5:5c40480000:30000> fletcher2 > uncompressed LE contiguous birth=20167 fill=1 cksum=cfcfcfcfcfcfce00:cfcfcfcfcfcfce00:8a8a8a8a8a56e700:8a8a8a8a8a56e > cpuid = 0 > > I think I saw someone else have a similar problem to this. There were > told their hardware was probably flakey on to look for errors with geli. > Just performing a scrub now to see what happens. > Let me know if you need any further info. > Cheers. > > -- > Mark Powell - UNIX System Administrator - The University of Salford > Information Services Division, Clifford Whitworth Building, > Salford University, Manchester, M5 4WT, UK. > Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key > _______________________________________________ > 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" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 01:31:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07C7E16A417; Fri, 31 Aug 2007 01:31:23 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: from brori.kgt.co.jp (brori.kgt.co.jp [210.141.246.67]) by mx1.freebsd.org (Postfix) with ESMTP id AFA7413C469; Fri, 31 Aug 2007 01:31:22 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: from navgw.tt.kgt.co.jp (navgw.kgt.co.jp [210.141.246.71]) by brori.kgt.co.jp (Postfix) with ESMTP id 89472FB14B; Fri, 31 Aug 2007 10:31:00 +0900 (JST) Received: from localhost (wbbrown.tt.kgt.co.jp [192.168.15.206]) by navgw.tt.kgt.co.jp (Postfix) with ESMTP id 2F73B47711; Fri, 31 Aug 2007 10:31:00 +0900 (JST) Date: Fri, 31 Aug 2007 10:32:57 +0900 (JST) Message-Id: <20070831.103257.52837654.haro@kgt.co.jp> To: thompsa@FreeBSD.org From: haro@kgt.co.jp In-Reply-To: <20070830.143335.89920717.haro@kgt.co.jp> References: <20070830.043519.109271629.haro@kgt.co.jp> <20070829215249.GA54430@heff.fud.org.nz> <20070830.143335.89920717.haro@kgt.co.jp> X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: LOR with iwi (was Re: Panic with iwi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 01:31:23 -0000 Hi Andrew, FYI, I just got following LOR with iwi, at the hotel: lock order reversal: 1st 0xc368e00c ieee80211com (802.11 com lock) @ net80211/ieee80211_scan.c:523 2nd 0xc368f400 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1907 KDB: stack backtrace: db_trace_self_wrapper(c07d80aa,db312a4c,c05c1cce,c07da553,c368f400,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07da553,c368f400,c36771a0,c0997ade,c09974ca,...) at kdb_backtrace+0x29 witness_checkorder(c368f400,9,c09974ca,773,c057d71d,...) at witness_checkorder+0x6de _mtx_lock_flags(c368f400,0,c09974ca,773,c3572aa0,...) at _mtx_lock_flags+0xbc iwi_start(c3673400,c368f1b4,db312b88,c0648444,c3673400,...) at iwi_start+0xae if_start(c3673400,0,c07e50be,17e,db312b6c,...) at if_start+0x59 ieee80211_send_nulldata(c3a5f000,38,c07d9c38,6ce,c368e00c) at ieee80211_send_nulldata+0x1f4 ieee80211_sta_pwrsave(c368e004,1,20b,c3967e00,c3655800,...) at ieee80211_sta_pwrsave+0x212 scan_restart(c3655800,c368e004,c07e5bf7,20b,0,...) at scan_restart+0x96 ieee80211_bg_scan(c368e004,0,c07e5f2b,434,0,...) at ieee80211_bg_scan+0x10f sta_age(c3655800,db312c84,c06452f7,c368e004,db312c68,...) at sta_age+0x345 ieee80211_scan_timeout(c368e004,db312c68,80246,c08641e4,db312c84,...) at ieee80211_scan_timeout+0x1c ieee80211_node_timeout(c368e004,0,c07d65f4,ef,0,...) at ieee80211_node_timeout+0x17 softclock(0,0,c07d202a,471,c356e064,...) at softclock+0x299 ithread_loop(c35704e0,db312d38,c07d1da8,315,c3571558,...) at ithread_loop+0x1b5 fork_exit(c056ddd0,c35704e0,db312d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdb312d70, ebp = 0 --- Thanks, Haro =----------------------------------------------------------------------- _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| KGT Inc. /|\ |_| |_|_| 2-8-8 Shinjuku, Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 01:39:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B22D16A419 for ; Fri, 31 Aug 2007 01:39:06 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 068B113C46C for ; Fri, 31 Aug 2007 01:39:05 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 5D99D1CC58; Fri, 31 Aug 2007 13:38:47 +1200 (NZST) Date: Fri, 31 Aug 2007 13:38:47 +1200 From: Andrew Thompson To: haro@kgt.co.jp Message-ID: <20070831013847.GA5577@heff.fud.org.nz> References: <20070830.043519.109271629.haro@kgt.co.jp> <20070829215249.GA54430@heff.fud.org.nz> <20070830.143335.89920717.haro@kgt.co.jp> <20070831.103257.52837654.haro@kgt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070831.103257.52837654.haro@kgt.co.jp> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: LOR with iwi (was Re: Panic with iwi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 01:39:06 -0000 On Fri, Aug 31, 2007 at 10:32:57AM +0900, haro@kgt.co.jp wrote: > Hi Andrew, > > FYI, I just got following LOR with iwi, at the hotel: > > > lock order reversal: > 1st 0xc368e00c ieee80211com (802.11 com lock) @ net80211/ieee80211_scan.c:523 > 2nd 0xc368f400 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1907 > KDB: stack backtrace: > db_trace_self_wrapper(c07d80aa,db312a4c,c05c1cce,c07da553,c368f400,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(c07da553,c368f400,c36771a0,c0997ade,c09974ca,...) at kdb_backtrace+0x29 Thanks. This one is known and considered harmless, it will be fixed up after 7.0 is out and the tree unfrozen. Andrew From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 02:03:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EDE816A417 for ; Fri, 31 Aug 2007 02:03:31 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id DFCF513C48E for ; Fri, 31 Aug 2007 02:03:29 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so562968nfd for ; Thu, 30 Aug 2007 19:03:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=Ai0AE42Omm1ePUJpZg8f5uF7ZcNm2vsK5w4EsysDzc26Lq7mrgJQ0XOg4YDHYMHP+5YkWv7CaoVaPotYykXv8AIBlBDpRloabIP7Cv4peLeibcp4tow+h/T/IP9wy7naXWAwCeNNp0ZjbWT7lXGXWjiKOY/6abLJj3n1uz8r5rQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=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; b=ihGcZbTRUm9idbhP3vllY1p7Wx6PTC9/U5fP2Ab43GNrP2YydZ/aVO4o5FEq+XXyi0zQIjKfvILCbVdtZB7mcgsrOoYERoglM4+nU0EgWAdlIwvegbST3IPuc5OV9Y3k/1/mwWX0S60u0DKKsoOVlhpcMz8evP27DnpqYmfo/pE= Received: by 10.78.201.2 with SMTP id y2mr866366huf.1188525784620; Thu, 30 Aug 2007 19:03:04 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Thu, 30 Aug 2007 19:03:04 -0700 (PDT) Message-ID: <3bbf2fe10708301903lc190386o61c309db7dd9680b@mail.gmail.com> Date: Fri, 31 Aug 2007 04:03:04 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Andrew Thompson" In-Reply-To: <20070831013847.GA5577@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070830.043519.109271629.haro@kgt.co.jp> <20070829215249.GA54430@heff.fud.org.nz> <20070830.143335.89920717.haro@kgt.co.jp> <20070831.103257.52837654.haro@kgt.co.jp> <20070831013847.GA5577@heff.fud.org.nz> X-Google-Sender-Auth: da9f0f01216fbf3c Cc: freebsd-current@freebsd.org, haro@kgt.co.jp Subject: Re: LOR with iwi (was Re: Panic with iwi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 02:03:31 -0000 2007/8/31, Andrew Thompson : > On Fri, Aug 31, 2007 at 10:32:57AM +0900, haro@kgt.co.jp wrote: > > Hi Andrew, > > > > FYI, I just got following LOR with iwi, at the hotel: > > > > > > lock order reversal: > > 1st 0xc368e00c ieee80211com (802.11 com lock) @ net80211/ieee80211_scan.c:523 > > 2nd 0xc368f400 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1907 > > KDB: stack backtrace: > > db_trace_self_wrapper(c07d80aa,db312a4c,c05c1cce,c07da553,c368f400,...) at db_trace_self_wrapper+0x26 > > kdb_backtrace(c07da553,c368f400,c36771a0,c0997ade,c09974ca,...) at kdb_backtrace+0x29 > > Thanks. This one is known and considered harmless, it will be fixed up > after 7.0 is out and the tree unfrozen. if it is really a false positive, it is my idea it should be putted in the BLESSED list. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 02:41:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2634F16A418 for ; Fri, 31 Aug 2007 02:41:52 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id DCC6013C459 for ; Fri, 31 Aug 2007 02:41:51 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IQwRc-0004nA-SG for ; Fri, 31 Aug 2007 11:41:13 +0900 Message-ID: <46D77FC8.1050709@fusiongol.com> Date: Fri, 31 Aug 2007 11:41:12 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <46BFE620.8070906@fusiongol.com> <20070813091802.GB3078@stud.ntnu.no> <20070823071056.GA50852@obiwan.tataz.chchile.org> <20070825082812.GE50852@obiwan.tataz.chchile.org> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: Re: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 02:41:52 -0000 Two quick things to report, * I got my hands on a Promise SATA 150 TX4, and that has the same issue as the SATA 300 TX4. * I found a solution for the old SETFEATURES SET TRANSFER MODE issue from back in April. It seems that by setting the devices on the Promise card back to UDMA100 from UDMA133, the problem goes away. I haven't tried this myself - I just discovered it on a Japanese FreeBSD blog. e.g. # atacontrol mode ad6 UDMA100 From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 14:14:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FDAE16A468 for ; Thu, 30 Aug 2007 14:14:27 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (omval.tednet.nl [IPv6:2001:7b8:206:1:200:39ff:fe59:b187]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF9613C458 for ; Thu, 30 Aug 2007 14:14:26 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (localhost [127.0.0.1]) by omval.tednet.nl (8.14.1/8.14.1) with ESMTP id l7UEEMqW004167; Thu, 30 Aug 2007 16:14:22 +0200 (CEST) (envelope-from ted@omval.tednet.nl) Received: (from ted@localhost) by omval.tednet.nl (8.14.1/8.14.1/Submit) id l7UEEMSi004166; Thu, 30 Aug 2007 16:14:22 +0200 (CEST) (envelope-from ted) Message-Id: <200708301414.l7UEEMSi004166@omval.tednet.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Thu, 30 Aug 2007 16:14:22 +0200 In-Reply-To: "Ted Lindgreen's message as of Aug 11, 10:21" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: freebsd-current@freebsd.org X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,BAYES_20 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on omval.tednet.nl X-Mailman-Approved-At: Fri, 31 Aug 2007 03:15:08 +0000 Cc: Ted Lindgreen Subject: New if_zyd driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 14:14:27 -0000 Hi, I'd like to report success with new zyd driver, and to thank the author for his work. I had tried the diff that was published previously. With ifconfig, the device associated with the access-point, but no traffic was possible. With the files now included in CVS, the device works! However, the stick needs to be inserted after booting up. Then I can also remove the stick without ill effects (for logmessages see below). When the stick is present during boot, the log shows: Aug 30 15:25:17 lapje kernel: zyd0: on uhub4 Aug 30 15:25:17 lapje kernel: zyd0: setting config no failed and there are 2 problems: 1. "ifconfig -a" shows no zyd0 device. 2. when the stick is removed, the laptop panics (page fault) Perhaps useful, the logs after inserting the stick, thus when it gets to work fine (despite the "Unknown" message). Aug 30 15:27:36 lapje kernel: zyd0: on uhub4 Aug 30 15:27:36 lapje root: Unknown USB device: vendor 0x0ace product 0x1215 bus uhub4 Aug 30 15:27:36 lapje kernel: zyd0: HMAC ZD1211B, FW 47.25, RF AL2230, PA 0, address 00:02:72:57:48:76 Aug 30 15:27:36 lapje kernel: zyd0: Ethernet address: 00:02:72:57:48:76 Aug 30 15:27:39 lapje kernel: zyd0: link state changed to UP when removed: Aug 30 15:54:03 lapje kernel: zyd0: at uhub4 port 1 (addr 2) disconnected Aug 30 15:54:03 lapje kernel: zyd0: link state changed to DOWN Aug 30 15:54:03 lapje kernel: zyd0: could not transmit buffer: IOERROR Aug 30 15:54:04 lapje kernel: zyd0: zyd_read sleep timeout Aug 30 15:54:04 lapje kernel: zyd0: could not send command (error=IOERROR) Aug 30 15:54:04 lapje last message repeated 2 times Aug 30 15:54:05 lapje kernel: zyd0: zyd_read sleep timeout Aug 30 15:54:05 lapje kernel: zyd0: could not send command (error=IOERROR) Aug 30 15:54:05 lapje last message repeated 2 times Aug 30 15:54:05 lapje kernel: zyd0: detached and when reinserted: Aug 30 15:55:00 lapje kernel: zyd0: on uhub4 Aug 30 15:55:00 lapje root: Unknown USB device: vendor 0x0ace product 0x1215 bus uhub4 Aug 30 15:55:00 lapje kernel: zyd0: HMAC ZD1211B, FW 47.25, RF AL2230, PA 0, address 00:02:72:57:48:76 Aug 30 15:55:00 lapje kernel: zyd0: Ethernet address: 00:02:72:57:48:76 Aug 30 15:55:14 lapje kernel: zyd0: link state changed to UP regards, -- ted From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 05:39:47 2007 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 C976716A418; Fri, 31 Aug 2007 05:39:47 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id 866E613C45A; Fri, 31 Aug 2007 05:39:47 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from home.alpha-tierchen.de (port-212-202-42-154.dynamic.qsc.de [212.202.42.154]) by mail.liberty-hosting.de (Postfix) with ESMTP id 7C4EA3E9C55; Fri, 31 Aug 2007 07:40:51 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id 6A24F45068; Fri, 31 Aug 2007 07:38:52 +0200 (CEST) Received: from 192.168.1.2 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Fri, 31 Aug 2007 07:38:52 +0200 (CEST) Message-ID: <53349.192.168.1.2.1188538732.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <200708300859.13098.joao@matik.com.br> References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <200708300859.13098.joao@matik.com.br> Date: Fri, 31 Aug 2007 07:38:52 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: "JoaoBR" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Fri, 31 Aug 2007 11:58:22 +0000 Cc: Roman Divacky , freebsd-current@freebsd.org, bkoenig@cs.tu-berlin.de, pluknet , current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 05:39:47 -0000 JoaoBR wrote: > but athlon64-x2 for S940 and athlon64-am2 for sse3 capable cpus would be > kind of understandable for all > [...] > venice as said in another mail is not clear for all people and certainly it > does not appear on the box or elsewhere I think the names "athlon64-x2" and "athlon64-am2" would be most confusing and ambiguous, because the socket has nothing to do with the feature set of the CPU. Athlon64 X2 CPUs are not only available for socket 940, but also for AM2 and 939. There are SSE3 CPUs that fit into 940, AM2 and 939. Björn From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 05:59:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B15716A468 for ; Fri, 31 Aug 2007 05:59:49 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id 0045C13C45B for ; Fri, 31 Aug 2007 05:59:48 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from home.alpha-tierchen.de (port-212-202-42-154.dynamic.qsc.de [212.202.42.154]) by mail.liberty-hosting.de (Postfix) with ESMTP id 7C4EA3E9C55; Fri, 31 Aug 2007 07:40:51 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id 6A24F45068; Fri, 31 Aug 2007 07:38:52 +0200 (CEST) Received: from 192.168.1.2 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Fri, 31 Aug 2007 07:38:52 +0200 (CEST) Message-ID: <53349.192.168.1.2.1188538732.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <200708300859.13098.joao@matik.com.br> References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <200708300859.13098.joao@matik.com.br> Date: Fri, 31 Aug 2007 07:38:52 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: "JoaoBR" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Fri, 31 Aug 2007 11:58:22 +0000 Cc: Roman Divacky , freebsd-current@freebsd.org, bkoenig@cs.tu-berlin.de, pluknet , current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 05:59:49 -0000 JoaoBR wrote: > but athlon64-x2 for S940 and athlon64-am2 for sse3 capable cpus would be > kind of understandable for all > [...] > venice as said in another mail is not clear for all people and certainly it > does not appear on the box or elsewhere I think the names "athlon64-x2" and "athlon64-am2" would be most confusing and ambiguous, because the socket has nothing to do with the feature set of the CPU. Athlon64 X2 CPUs are not only available for socket 940, but also for AM2 and 939. There are SSE3 CPUs that fit into 940, AM2 and 939. Björn From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 14:13:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C09316A41B for ; Fri, 31 Aug 2007 14:13:32 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4B74313C46A for ; Fri, 31 Aug 2007 14:13:32 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7VECptX079439; Fri, 31 Aug 2007 07:12:51 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7VECpaa079438; Fri, 31 Aug 2007 07:12:51 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 07:12:51 -0700 From: "David O'Brien" To: =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= Message-ID: <20070831141251.GB79097@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= , freebsd-current@freebsd.org References: <62415.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188366366.squirrel@webmail.alpha-tierchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62415.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188366366.squirrel@webmail.alpha-tierchen.de> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk 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: Fri, 31 Aug 2007 14:13:32 -0000 On Wed, Aug 29, 2007 at 07:46:06AM +0200, Bjrn Knig wrote: > what do you think about adding the CPU types "k9" and "k10"? No. K10 does not exist. (nor does K9 either). -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 14:14:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ED2216A421 for ; Fri, 31 Aug 2007 14:14:37 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id E2DB813C45E for ; Fri, 31 Aug 2007 14:14:36 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7VEEDQR079462; Fri, 31 Aug 2007 07:14:13 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7VEEDiU079461; Fri, 31 Aug 2007 07:14:13 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 07:14:13 -0700 From: "David O'Brien" To: =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= Message-ID: <20070831141413.GC79097@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= , freebsd-current@freebsd.org References: <62415.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188366366.squirrel@webmail.alpha-tierchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62415.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188366366.squirrel@webmail.alpha-tierchen.de> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk 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: Fri, 31 Aug 2007 14:14:37 -0000 On Wed, Aug 29, 2007 at 07:46:06AM +0200, Bjrn Knig wrote: > what do you think about adding the CPU types "k9" and "k10"? Sorry, forgot to add - once these new AMD processors launch I'll add something that make since with the industry. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 14:21:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A76E16A41A for ; Fri, 31 Aug 2007 14:21:19 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 318C513C442 for ; Fri, 31 Aug 2007 14:21:19 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7VEKWaE079631; Fri, 31 Aug 2007 07:20:32 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7VEKWTp079630; Fri, 31 Aug 2007 07:20:32 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 07:20:32 -0700 From: "David O'Brien" To: =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= Message-ID: <20070831142032.GD79097@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= , Roman Divacky , pluknet , freebsd-current@freebsd.org References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: Roman Divacky , pluknet , freebsd-current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk 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: Fri, 31 Aug 2007 14:21:19 -0000 On Wed, Aug 29, 2007 at 09:49:24PM +0200, Bjrn Knig wrote: > Roman Divacky wrote: > > > I dont think the name matters THAT MUCH, the important thing is > > to support the newer CPUs with FreeBSD infrastructure... name > > it "blahblah" if you wish > > I agree. > > Intel's first Pentium 4 with SSE3 is called "prescott". We could use > "venice" analogously to represent SSE3-capable Athlon64 CPUs. No! NO! AMD core names does not mean the same as Intel ones. Look folks, there is a clear way for this - the CPUID family. K8 is Family 0Fh, the next major architecture is Family 10h. *THAT* is what is important to software optimization. All the various AMD K8 core names (Italy, Venice, San Diego, Manchester, ...)[*]. *Possibly* the "hammer" core names, could be very slightly useful, but I'm not convinced at that. [*] not even the AMD's own software optimization folks know or use these marketing dreamed up names. The differences between these "city" core names is important to the fab process folks, and the overclocking crowd. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 14:25:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24C816A419 for ; Fri, 31 Aug 2007 14:25:59 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4D713C48E for ; Fri, 31 Aug 2007 14:25:59 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7VEP4IV079751; Fri, 31 Aug 2007 07:25:04 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7VEOwKG079745; Fri, 31 Aug 2007 07:24:58 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 07:24:58 -0700 From: "David O'Brien" To: Stefan Lambrev Message-ID: <20070831142458.GE79097@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Stefan Lambrev , Roman Divacky , pluknet , freebsd-current@freebsd.org, Bj?rn K?nig References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <46D66F83.2050208@moneybookers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D66F83.2050208@moneybookers.com> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: Roman Divacky , pluknet , Bj?rn K?nig , freebsd-current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk 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: Fri, 31 Aug 2007 14:25:59 -0000 On Thu, Aug 30, 2007 at 10:19:31AM +0300, Stefan Lambrev wrote: > k8-sse3, opteron-sse3, athlon64-sse3 Yeah, I guess I should add those... though bsd.cpu.mk was architected with some amount of guessing of what might in the future be useful. Is there anything in /usr/src or /usr/ports that actually does anything with the information? . elif ${CPUTYPE} == "prescott" MACHINE_CPU = sse3 sse2 sse i686 mmx i586 i486 i386 . elif ${CPUTYPE} == "nocona" MACHINE_CPU = sse3 for instance. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 14:31:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B542016A41A; Fri, 31 Aug 2007 14:31:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0F313C458; Fri, 31 Aug 2007 14:31:40 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46D82649.20804@FreeBSD.org> Date: Fri, 31 Aug 2007 16:31:37 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: obrien@freebsd.org, Stefan Lambrev , Roman Divacky , pluknet , freebsd-current@freebsd.org, Bj?rn K?nig References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <46D66F83.2050208@moneybookers.com> <20070831142458.GE79097@dragon.NUXI.org> In-Reply-To: <20070831142458.GE79097@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 14:31:41 -0000 David O'Brien wrote: > On Thu, Aug 30, 2007 at 10:19:31AM +0300, Stefan Lambrev wrote: >> k8-sse3, opteron-sse3, athlon64-sse3 > > Yeah, I guess I should add those... though bsd.cpu.mk was architected > with some amount of guessing of what might in the future be useful. > > Is there anything in /usr/src or /usr/ports that actually does anything > with the information? > > . elif ${CPUTYPE} == "prescott" > MACHINE_CPU = sse3 sse2 sse i686 mmx i586 i486 i386 > > . elif ${CPUTYPE} == "nocona" > MACHINE_CPU = sse3 > > for instance. > MACHINE_CPU is supposed to be a complete list of relevant CPU features that ports can use to enable e.g. SSE2 asm optimizations if the CPUTYPE supports it. A number of them exist that do this. Kris From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 15:28:50 2007 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 A20EE16A41A for ; Fri, 31 Aug 2007 15:28:50 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 69A8013C459 for ; Fri, 31 Aug 2007 15:28:50 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from [10.0.10.13] (dyn-62-56-116-79.dslaccess.co.uk [62.56.116.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 0C7B73000D for ; Fri, 31 Aug 2007 16:24:29 +0100 (BST) Message-ID: <46D83351.9000407@cran.org.uk> Date: Fri, 31 Aug 2007 16:27:13 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: High interrupt load on VIA C3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 15:28:50 -0000 I recently upgraded to 7-CURRENT on my VIA EPIA router, and have found that there's a constant interrupt load of around 15%. My dmesg reports the CPU as: CPU: VIA C3 Nehemiah+RNG+AES (533.36-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x698 Stepping = 8 Features=0x381b93f real memory = 132055040 (125 MB) avail memory = 119701504 (114 MB) uname -a: FreeBSD router.draftnet 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Fri Aug 31 07:04:22 BST 2007 brucec@router.draftnet:/usr/obj/usr/src/sys/ROUTER i386 The first few lines of top -S are: last pid: 1394; load averages: 0.08, 0.12, 0.21 up 0+01:59:10 16:13:59 57 processes: 3 running, 39 sleeping, 15 waiting CPU states: 3.1% user, 0.0% nice, 4.8% system, 17.0% interrupt, 75.1% idle Mem: 7360K Active, 6116K Inact, 12M Wired, 48K Cache, 9504K Buf, 90M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 1 171 ki31 0K 8K RUN 100:01 81.98% idle 12 root 1 -32 - 0K 8K WAIT 12:31 7.96% swi4: clock sio 1394 brucec 1 46 0 3512K 1744K RUN 0:01 4.98% top 586 root 1 44 0 5016K 2516K RUN 2:39 0.00% ppp 1044 root 1 44 0 3176K 980K select 0:51 0.00% powerd 28 root 1 -68 - 0K 8K WAIT 0:45 0.00% irq11: vr0 dc3 30 root 1 -68 - 0K 8K WAIT 0:32 0.00% irq12: dc1 While there's a high interrupt load, vmstat -i doesn't show anything wrong: interrupt total rate irq0: clk 718003 99 irq4: sio0 897 0 irq5: dc0 31 0 irq8: rtc 919064 127 irq10: dc2 uhci0+ 31 0 irq11: vr0 dc3 63548 8 irq12: dc1 62120 8 irq14: ata0 1555 0 irq15: ata1 581 0 Total 1765830 245 I had thought of using hwpmc to find out what was happening, but unfortunately VIA CPUs aren't supported yet. Is there another way I can find out what's going on? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 15:44:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AFCD16A420 for ; Fri, 31 Aug 2007 15:44:25 +0000 (UTC) (envelope-from matej.kubik@dial.sk) Received: from saratoga.zuikaku.org (unknown [IPv6:2001:1ba0::20a:e4ff:fe5a:25bb]) by mx1.freebsd.org (Postfix) with ESMTP id 6292613C45D for ; Fri, 31 Aug 2007 15:44:23 +0000 (UTC) (envelope-from matej.kubik@dial.sk) Received: from saratoga.zuikaku.org (localhost [127.0.0.1]) by saratoga.zuikaku.org (8.13.8/8.13.8) with ESMTP id l7VFiLPg008817 for ; Fri, 31 Aug 2007 17:44:22 +0200 (CEST) (envelope-from matej.kubik@dial.sk) Received: (from kockac@localhost) by saratoga.zuikaku.org (8.13.8/8.13.8/Submit) id l7VFiKlC008816 for freebsd-current@freebsd.org; Fri, 31 Aug 2007 17:44:20 +0200 (CEST) (envelope-from matej.kubik@dial.sk) X-Authentication-Warning: saratoga.zuikaku.org: kockac set sender to matej.kubik@dial.sk using -f Date: Fri, 31 Aug 2007 17:44:19 +0200 From: "'Kockac' Matej Kubik" To: freebsd-current@freebsd.org Message-ID: <20070831154418.GA8474@saratoga.zuikaku.org> References: <20070828125331.GA2132@saratoga.zuikaku.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <20070828125331.GA2132@saratoga.zuikaku.org> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Fri, 31 Aug 2007 16:07:56 +0000 Subject: Re: weird ufs corruption on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 15:44:25 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello again, I've been adviced by one friend to try older version of -current and after couple of days recompiling and recompiling I think I've been able to pinpoint the cause... well maybe not really pinpoint but it's about 1500-lines of diff -u. At this moment I'm using -current cvsupped with date=2007.06.15.00.00.00 Kernel with date=2007.06.16.04.00.00 works, but 20070616050000 and all later do not. There have been some changes in src/sys/vm but nothing else. (I've attached the diff for convenience. It's the patch that caused the wrong behaviour.) Unfortunately I don't know how to debug this by myself but I'll be really thankful for any suggestions of what to do next or other help. Matej --5vNYLRcllDrimb99 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="badvm.patch" diff -ru /usr/src/sys/conf/NOTES /mnt/usr/src/sys/conf/NOTES --- /usr/src/sys/conf/NOTES Fri Aug 31 16:14:48 2007 +++ /mnt/usr/src/sys/conf/NOTES Fri Aug 31 16:06:28 2007 @@ -1,4 +1,4 @@ -# $FreeBSD: src/sys/conf/NOTES,v 1.1433 2007/06/15 02:29:19 rrs Exp $ +# $FreeBSD: src/sys/conf/NOTES,v 1.1434 2007/06/16 04:57:03 alc Exp $ # # NOTES -- Lines that can be cut/pasted into kernel and hints configs. # @@ -124,10 +124,6 @@ options DFLTPHYS=(64*1024) options MAXPHYS=(128*1024) - -# Options for the VM subsystem -# Deprecated options supported for backwards compatibility -#options PQ_NOOPT # No coloring # This allows you to actually store this configuration file into # the kernel binary itself, where it may be later read by saying: diff -ru /usr/src/sys/conf/files /mnt/usr/src/sys/conf/files --- /usr/src/sys/conf/files Fri Aug 31 16:14:48 2007 +++ /mnt/usr/src/sys/conf/files Fri Aug 31 16:06:28 2007 @@ -1,4 +1,4 @@ -# $FreeBSD: src/sys/conf/files,v 1.1221 2007/06/16 01:56:04 delphij Exp $ +# $FreeBSD: src/sys/conf/files,v 1.1222 2007/06/16 04:57:04 alc Exp $ # # The long compile-with and dependency lines are required because of # limitations in config: backslash-newline doesn't work in strings, and @@ -2078,6 +2078,7 @@ vm/vm_pageout.c standard vm/vm_pageq.c standard vm/vm_pager.c standard +vm/vm_phys.c standard vm/vm_unix.c standard vm/vm_zeroidle.c standard vm/vnode_pager.c standard diff -ru /usr/src/sys/conf/options /mnt/usr/src/sys/conf/options --- /usr/src/sys/conf/options Fri Aug 31 16:14:48 2007 +++ /mnt/usr/src/sys/conf/options Fri Aug 31 16:06:28 2007 @@ -1,4 +1,4 @@ -# $FreeBSD: src/sys/conf/options,v 1.595 2007/06/16 01:56:04 delphij Exp $ +# $FreeBSD: src/sys/conf/options,v 1.596 2007/06/16 04:57:04 alc Exp $ # # On the handling of kernel options # @@ -555,7 +555,6 @@ NO_SWAPPING opt_vm.h MALLOC_MAKE_FAILURES opt_vm.h MALLOC_PROFILE opt_vm.h -PQ_NOOPT opt_vmpage.h # The MemGuard replacement allocator used for tamper-after-free detection DEBUG_MEMGUARD opt_vm.h diff -ru /usr/src/sys/powerpc/include/vmparam.h /mnt/usr/src/sys/powerpc/include/vmparam.h --- /usr/src/sys/powerpc/include/vmparam.h Fri Aug 31 16:18:35 2007 +++ /mnt/usr/src/sys/powerpc/include/vmparam.h Fri Aug 31 16:06:52 2007 @@ -29,7 +29,7 @@ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * $NetBSD: vmparam.h,v 1.11 2000/02/11 19:25:16 thorpej Exp $ - * $FreeBSD: src/sys/powerpc/include/vmparam.h,v 1.8 2007/05/28 21:04:22 alc Exp $ + * $FreeBSD: src/sys/powerpc/include/vmparam.h,v 1.9 2007/06/16 04:57:05 alc Exp $ */ #ifndef _MACHINE_VMPARAM_H_ @@ -109,8 +109,26 @@ */ #define VM_PHYSSEG_DENSE +/* + * Create two free page pools: VM_FREEPOOL_DEFAULT is the default pool + * from which physical pages are allocated and VM_FREEPOOL_DIRECT is + * the pool from which physical pages for small UMA objects are + * allocated. + */ +#define VM_NFREEPOOL 2 +#define VM_FREEPOOL_DEFAULT 0 +#define VM_FREEPOOL_DIRECT 1 + +/* + * Create one free page list. + */ #define VM_NFREELIST 1 #define VM_FREELIST_DEFAULT 0 + +/* + * The largest allocation size is 4MB. + */ +#define VM_NFREEORDER 11 #ifndef VM_INITIAL_PAGEIN #define VM_INITIAL_PAGEIN 16 diff -ru /usr/src/sys/sun4v/sun4v/pmap.c /mnt/usr/src/sys/sun4v/sun4v/pmap.c --- /usr/src/sys/sun4v/sun4v/pmap.c Fri Aug 31 16:18:43 2007 +++ /mnt/usr/src/sys/sun4v/sun4v/pmap.c Fri Aug 31 16:06:48 2007 @@ -26,7 +26,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/sun4v/sun4v/pmap.c,v 1.38 2007/05/31 22:52:14 attilio Exp $"); +__FBSDID("$FreeBSD: src/sys/sun4v/sun4v/pmap.c,v 1.39 2007/06/16 04:57:05 alc Exp $"); #include "opt_kstack_pages.h" #include "opt_msgbuf.h" @@ -58,6 +58,7 @@ #include #include #include +#include #include #include @@ -1286,13 +1287,13 @@ m = NULL; while (m == NULL) { for (i = 0; phys_avail[i + 1] != 0; i += 2) { - m = vm_page_alloc_contig(npages, phys_avail[i], + m = vm_phys_alloc_contig(npages, phys_avail[i], phys_avail[i + 1], alignment, (1UL<<34)); if (m) goto found; } if (m == NULL) { - printf("vm_page_alloc_contig failed - waiting to retry\n"); + printf("vm_phys_alloc_contig failed - waiting to retry\n"); VM_WAIT; } } diff -ru /usr/src/sys/vm/vm_contig.c /mnt/usr/src/sys/vm/vm_contig.c --- /usr/src/sys/vm/vm_contig.c Fri Aug 31 16:18:50 2007 +++ /mnt/usr/src/sys/vm/vm_contig.c Fri Aug 31 16:06:25 2007 @@ -60,7 +60,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/vm/vm_contig.c,v 1.61 2007/06/11 03:20:16 alc Exp $"); +__FBSDID("$FreeBSD: src/sys/vm/vm_contig.c,v 1.62 2007/06/16 04:57:05 alc Exp $"); #include #include @@ -84,6 +84,7 @@ #include #include #include +#include #include static int @@ -165,191 +166,6 @@ return (FALSE); } -/* - * This interface is for merging with malloc() someday. - * Even if we never implement compaction so that contiguous allocation - * works after initialization time, malloc()'s data structures are good - * for statistics and for allocations of less than a page. - */ -static void * -contigmalloc1( - unsigned long size, /* should be size_t here and for malloc() */ - struct malloc_type *type, - int flags, - vm_paddr_t low, - vm_paddr_t high, - unsigned long alignment, - unsigned long boundary, - vm_map_t map) -{ - int i, start; - vm_paddr_t phys; - vm_object_t object; - vm_offset_t addr, tmp_addr; - int pass, pqtype; - int inactl, actl, inactmax, actmax; - vm_page_t pga = vm_page_array; - - size = round_page(size); - if (size == 0) - panic("contigmalloc1: size must not be 0"); - if ((alignment & (alignment - 1)) != 0) - panic("contigmalloc1: alignment must be a power of 2"); - if ((boundary & (boundary - 1)) != 0) - panic("contigmalloc1: boundary must be a power of 2"); - - start = 0; - for (pass = 2; pass >= 0; pass--) { - vm_page_lock_queues(); -again0: - mtx_lock(&vm_page_queue_free_mtx); -again: - /* - * Find first page in array that is free, within range, - * aligned, and such that the boundary won't be crossed. - */ - for (i = start; i < cnt.v_page_count; i++) { - phys = VM_PAGE_TO_PHYS(&pga[i]); - pqtype = pga[i].queue - pga[i].pc; - if (((pqtype == PQ_FREE) || (pqtype == PQ_CACHE)) && - (phys >= low) && (phys < high) && - ((phys & (alignment - 1)) == 0) && - (((phys ^ (phys + size - 1)) & ~(boundary - 1)) == 0)) - break; - } - - /* - * If the above failed or we will exceed the upper bound, fail. - */ - if ((i == cnt.v_page_count) || - ((VM_PAGE_TO_PHYS(&pga[i]) + size) > high)) { - mtx_unlock(&vm_page_queue_free_mtx); - /* - * Instead of racing to empty the inactive/active - * queues, give up, even with more left to free, - * if we try more than the initial amount of pages. - * - * There's no point attempting this on the last pass. - */ - if (pass > 0) { - inactl = actl = 0; - inactmax = vm_page_queues[PQ_INACTIVE].lcnt; - actmax = vm_page_queues[PQ_ACTIVE].lcnt; -again1: - if (inactl < inactmax && - vm_contig_launder(PQ_INACTIVE)) { - inactl++; - goto again1; - } - if (actl < actmax && - vm_contig_launder(PQ_ACTIVE)) { - actl++; - goto again1; - } - } - vm_page_unlock_queues(); - continue; - } - start = i; - - /* - * Check successive pages for contiguous and free. - */ - for (i = start + 1; i < (start + size / PAGE_SIZE); i++) { - pqtype = pga[i].queue - pga[i].pc; - if ((VM_PAGE_TO_PHYS(&pga[i]) != - (VM_PAGE_TO_PHYS(&pga[i - 1]) + PAGE_SIZE)) || - ((pqtype != PQ_FREE) && (pqtype != PQ_CACHE))) { - start++; - goto again; - } - } - mtx_unlock(&vm_page_queue_free_mtx); - for (i = start; i < (start + size / PAGE_SIZE); i++) { - vm_page_t m = &pga[i]; - - if (VM_PAGE_INQUEUE1(m, PQ_CACHE)) { - if (m->hold_count != 0) { - start++; - goto again0; - } - object = m->object; - if (!VM_OBJECT_TRYLOCK(object)) { - start++; - goto again0; - } - if ((m->oflags & VPO_BUSY) || m->busy != 0) { - VM_OBJECT_UNLOCK(object); - start++; - goto again0; - } - vm_page_free(m); - VM_OBJECT_UNLOCK(object); - } - } - mtx_lock(&vm_page_queue_free_mtx); - for (i = start; i < (start + size / PAGE_SIZE); i++) { - pqtype = pga[i].queue - pga[i].pc; - if (pqtype != PQ_FREE) { - start++; - goto again; - } - } - for (i = start; i < (start + size / PAGE_SIZE); i++) { - vm_page_t m = &pga[i]; - vm_pageq_remove_nowakeup(m); - m->valid = VM_PAGE_BITS_ALL; - if (m->flags & PG_ZERO) - vm_page_zero_count--; - /* Don't clear the PG_ZERO flag, we'll need it later. */ - m->flags = PG_UNMANAGED | (m->flags & PG_ZERO); - KASSERT(m->dirty == 0, - ("contigmalloc1: page %p was dirty", m)); - m->wire_count = 0; - m->busy = 0; - } - mtx_unlock(&vm_page_queue_free_mtx); - vm_page_unlock_queues(); - /* - * We've found a contiguous chunk that meets are requirements. - * Allocate kernel VM, unfree and assign the physical pages to - * it and return kernel VM pointer. - */ - vm_map_lock(map); - if (vm_map_findspace(map, vm_map_min(map), size, &addr) != - KERN_SUCCESS) { - /* - * XXX We almost never run out of kernel virtual - * space, so we don't make the allocated memory - * above available. - */ - vm_map_unlock(map); - return (NULL); - } - vm_object_reference(kernel_object); - vm_map_insert(map, kernel_object, addr - VM_MIN_KERNEL_ADDRESS, - addr, addr + size, VM_PROT_ALL, VM_PROT_ALL, 0); - vm_map_unlock(map); - - tmp_addr = addr; - VM_OBJECT_LOCK(kernel_object); - for (i = start; i < (start + size / PAGE_SIZE); i++) { - vm_page_t m = &pga[i]; - vm_page_insert(m, kernel_object, - OFF_TO_IDX(tmp_addr - VM_MIN_KERNEL_ADDRESS)); - if ((flags & M_ZERO) && !(m->flags & PG_ZERO)) - pmap_zero_page(m); - tmp_addr += PAGE_SIZE; - } - VM_OBJECT_UNLOCK(kernel_object); - vm_map_wire(map, addr, addr + size, - VM_MAP_WIRE_SYSTEM|VM_MAP_WIRE_NOHOLES); - - return ((void *)addr); - } - return (NULL); -} - static void vm_page_release_contigl(vm_page_t m, vm_pindex_t count) { @@ -367,173 +183,6 @@ vm_page_unlock_queues(); } -static int -vm_contig_unqueue_free(vm_page_t m) -{ - int error = 0; - - mtx_lock(&vm_page_queue_free_mtx); - if ((m->queue - m->pc) == PQ_FREE) - vm_pageq_remove_nowakeup(m); - else - error = EAGAIN; - mtx_unlock(&vm_page_queue_free_mtx); - if (error) - return (error); - m->valid = VM_PAGE_BITS_ALL; - if (m->flags & PG_ZERO) - vm_page_zero_count--; - /* Don't clear the PG_ZERO flag; we'll need it later. */ - m->flags = PG_UNMANAGED | (m->flags & PG_ZERO); - m->oflags = 0; - KASSERT(m->dirty == 0, - ("contigmalloc2: page %p was dirty", m)); - m->wire_count = 0; - m->busy = 0; - return (error); -} - -vm_page_t -vm_page_alloc_contig(vm_pindex_t npages, vm_paddr_t low, vm_paddr_t high, - vm_offset_t alignment, vm_offset_t boundary) -{ - vm_object_t object; - vm_offset_t size; - vm_paddr_t phys; - vm_page_t pga = vm_page_array; - static vm_pindex_t np = 0; - static vm_pindex_t start = 0; - vm_pindex_t startl = 0; - int i, pass, pqtype; - - size = npages << PAGE_SHIFT; - if (size == 0) - panic("vm_page_alloc_contig: size must not be 0"); - if ((alignment & (alignment - 1)) != 0) - panic("vm_page_alloc_contig: alignment must be a power of 2"); - if ((boundary & (boundary - 1)) != 0) - panic("vm_page_alloc_contig: boundary must be a power of 2"); - - /* - * Two simple optimizations. First, don't scan high ordered pages - * if they are outside of the requested address range. Second, cache - * the starting page index across calls and reuse it instead of - * restarting the scan from the top. This is conditional on the - * requested number of pages being the same or greater than the - * cached amount. - */ - for (pass = 0; pass < 2; pass++) { - vm_page_lock_queues(); - if ((np == 0) || (np > npages)) { - if (atop(high) < vm_page_array_size) - start = atop(high) - npages + 1; - else - start = vm_page_array_size - npages + 1; - } - np = 0; -retry: - start--; - /* - * Find last page in array that is free, within range, - * aligned, and such that the boundary won't be crossed. - */ - for (i = start; i >= 0; i--) { - phys = VM_PAGE_TO_PHYS(&pga[i]); - pqtype = pga[i].queue - pga[i].pc; - if (pass == 0) { - if (pqtype != PQ_FREE && pqtype != PQ_CACHE) - continue; - } else if (pqtype != PQ_FREE && pqtype != PQ_CACHE && - pga[i].queue != PQ_ACTIVE && - pga[i].queue != PQ_INACTIVE) - continue; - if (phys >= low && phys + size <= high && - ((phys & (alignment - 1)) == 0) && - ((phys ^ (phys + size - 1)) & ~(boundary - 1)) == 0) - break; - } - /* There are no candidates at all. */ - if (i < 0) { - vm_page_unlock_queues(); - continue; - } - start = i; - /* - * Check successive pages for contiguous and free. - */ - for (i = start + npages - 1; i > start; i--) { - pqtype = pga[i].queue - pga[i].pc; - if (VM_PAGE_TO_PHYS(&pga[i]) != - VM_PAGE_TO_PHYS(&pga[i - 1]) + PAGE_SIZE) { - start = i - npages + 1; - goto retry; - } - if (pass == 0) { - if (pqtype != PQ_FREE && pqtype != PQ_CACHE) { - start = i - npages + 1; - goto retry; - } - } else if (pqtype != PQ_FREE && pqtype != PQ_CACHE && - pga[i].queue != PQ_ACTIVE && - pga[i].queue != PQ_INACTIVE) { - start = i - npages + 1; - goto retry; - } - } - for (i = start + npages - 1; i >= start; i--) { - vm_page_t m = &pga[i]; - -retry_page: - pqtype = m->queue - m->pc; - if (pass != 0 && pqtype != PQ_FREE && - pqtype != PQ_CACHE) { - if (m->queue == PQ_ACTIVE || - m->queue == PQ_INACTIVE) { - if (vm_contig_launder_page(m) != 0) - goto cleanup_freed; - pqtype = m->queue - m->pc; - if (pqtype != PQ_FREE && - pqtype != PQ_CACHE) - goto cleanup_freed; - } else { -cleanup_freed: - vm_page_release_contigl(&pga[i + 1], - start + npages - 1 - i); - start = i - npages + 1; - goto retry; - } - } - if (pqtype == PQ_CACHE) { - if (m->hold_count != 0) - goto cleanup_freed; - object = m->object; - if (!VM_OBJECT_TRYLOCK(object)) - goto cleanup_freed; - if ((m->oflags & VPO_BUSY) || m->busy != 0) { - VM_OBJECT_UNLOCK(object); - goto cleanup_freed; - } - vm_page_free(m); - VM_OBJECT_UNLOCK(object); - } - /* - * There is no good API for freeing a page - * directly to PQ_NONE on our behalf, so spin. - */ - if (vm_contig_unqueue_free(m) != 0) - goto retry_page; - } - /* - * We've found a contiguous chunk that meets are requirements. - */ - np = npages; - startl = start; - vm_page_unlock_queues(); - return (&pga[startl]); - } - return (NULL); -} - static void * contigmalloc2(vm_page_t m, vm_pindex_t npages, int flags) { @@ -571,11 +220,6 @@ return ((void *)addr); } -static int vm_old_contigmalloc = 0; -SYSCTL_INT(_vm, OID_AUTO, old_contigmalloc, - CTLFLAG_RW, &vm_old_contigmalloc, 0, "Use the old contigmalloc algorithm"); -TUNABLE_INT("vm.old_contigmalloc", &vm_old_contigmalloc); - void * contigmalloc( unsigned long size, /* should be size_t here and for malloc() */ @@ -587,27 +231,51 @@ unsigned long boundary) { void * ret; - vm_page_t pages; - vm_pindex_t npgs; + vm_object_t object; + vm_page_t m, m_next, pages; + unsigned long npgs; + int actl, actmax, inactl, inactmax, tries; npgs = round_page(size) >> PAGE_SHIFT; - mtx_lock(&Giant); - if (vm_old_contigmalloc) { - ret = contigmalloc1(size, type, flags, low, high, alignment, - boundary, kernel_map); - } else { - pages = vm_page_alloc_contig(npgs, low, high, - alignment, boundary); - if (pages == NULL) { - ret = NULL; - } else { - ret = contigmalloc2(pages, npgs, flags); - if (ret == NULL) - vm_page_release_contig(pages, npgs); + tries = 0; +retry: + pages = vm_phys_alloc_contig(npgs, low, high, alignment, boundary); + if (pages == NULL) { + if (tries < ((flags & M_NOWAIT) != 0 ? 1 : 3)) { + vm_page_lock_queues(); + inactl = 0; + inactmax = tries < 1 ? 0 : cnt.v_inactive_count; + actl = 0; + actmax = tries < 2 ? 0 : cnt.v_active_count; +again: + if (inactl < inactmax && + vm_contig_launder(PQ_INACTIVE)) { + inactl++; + goto again; + } + if (actl < actmax && + vm_contig_launder(PQ_ACTIVE)) { + actl++; + goto again; + } + TAILQ_FOREACH_SAFE(m, &vm_page_queues[PQ_CACHE].pl, + pageq, m_next) { + if (m->hold_count == 0 && + VM_OBJECT_TRYLOCK(object = m->object)) { + vm_page_free(m); + VM_OBJECT_UNLOCK(object); + } + } + vm_page_unlock_queues(); + tries++; + goto retry; } - + ret = NULL; + } else { + ret = contigmalloc2(pages, npgs, flags); + if (ret == NULL) + vm_page_release_contig(pages, npgs); } - mtx_unlock(&Giant); malloc_type_allocated(type, ret == NULL ? 0 : npgs << PAGE_SHIFT); return (ret); } diff -ru /usr/src/sys/vm/vm_object.c /mnt/usr/src/sys/vm/vm_object.c --- /usr/src/sys/vm/vm_object.c Fri Aug 31 16:18:50 2007 +++ /mnt/usr/src/sys/vm/vm_object.c Fri Aug 31 16:06:25 2007 @@ -63,7 +63,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.381 2007/06/10 21:59:13 attilio Exp $"); +__FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.382 2007/06/16 04:57:05 alc Exp $"); #include #include @@ -154,15 +154,6 @@ SYSCTL_LONG(_vm_stats_object, OID_AUTO, bypasses, CTLFLAG_RD, &object_bypasses, 0, "VM object bypasses"); -/* - * next_index determines the page color that is assigned to the next - * allocated object. Accesses to next_index are not synchronized - * because the effects of two or more object allocations using - * next_index simultaneously are inconsequential. At any given time, - * numerous objects have the same page color. - */ -static int next_index; - static uma_zone_t obj_zone; static int vm_object_zinit(void *mem, int size, int flags); @@ -210,7 +201,6 @@ void _vm_object_allocate(objtype_t type, vm_pindex_t size, vm_object_t object) { - int incr; TAILQ_INIT(&object->memq); LIST_INIT(&object->shadow_head); @@ -223,11 +213,7 @@ object->flags = 0; if ((object->type == OBJT_DEFAULT) || (object->type == OBJT_SWAP)) object->flags = OBJ_ONEMAPPING; - incr = PQ_MAXLENGTH; - if (size <= incr) - incr = size; - object->pg_color = next_index; - next_index = (object->pg_color + incr) & PQ_COLORMASK; + object->pg_color = 0; object->handle = NULL; object->backing_object = NULL; object->backing_object_offset = (vm_ooffset_t) 0; @@ -1258,15 +1244,8 @@ LIST_INSERT_HEAD(&source->shadow_head, result, shadow_list); source->shadow_count++; source->generation++; - if (length < source->size) - length = source->size; - if (length > PQ_MAXLENGTH || source->generation > 1) - length = PQ_MAXLENGTH; - result->pg_color = (source->pg_color + - length * source->generation) & PQ_COLORMASK; result->flags |= source->flags & OBJ_NEEDGIANT; VM_OBJECT_UNLOCK(source); - next_index = (result->pg_color + PQ_MAXLENGTH) & PQ_COLORMASK; } @@ -2129,7 +2108,7 @@ TAILQ_FOREACH(object, &vm_object_list, object_list) { vm_pindex_t idx, fidx; vm_pindex_t osize; - vm_paddr_t pa = -1, padiff; + vm_paddr_t pa = -1; int rcount; vm_page_t m; @@ -2171,17 +2150,8 @@ continue; } if (rcount) { - padiff = pa + rcount * PAGE_SIZE - VM_PAGE_TO_PHYS(m); - padiff >>= PAGE_SHIFT; - padiff &= PQ_COLORMASK; - if (padiff == 0) { - pa = VM_PAGE_TO_PHYS(m) - rcount * PAGE_SIZE; - ++rcount; - continue; - } - db_printf(" index(%ld)run(%d)pa(0x%lx)", + db_printf(" index(%ld)run(%d)pa(0x%lx)\n", (long)fidx, rcount, (long)pa); - db_printf("pd(%ld)\n", (long)padiff); if (nl > 18) { c = cngetc(); if (c != ' ') diff -ru /usr/src/sys/vm/vm_page.c /mnt/usr/src/sys/vm/vm_page.c --- /usr/src/sys/vm/vm_page.c Fri Aug 31 16:18:50 2007 +++ /mnt/usr/src/sys/vm/vm_page.c Fri Aug 31 16:06:25 2007 @@ -97,7 +97,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/vm/vm_page.c,v 1.347 2007/06/10 21:59:13 attilio Exp $"); +__FBSDID("$FreeBSD: src/sys/vm/vm_page.c,v 1.348 2007/06/16 04:57:05 alc Exp $"); #include #include @@ -117,6 +117,7 @@ #include #include #include +#include #include #include #include @@ -339,6 +340,8 @@ * Clear all of the page structures */ bzero((caddr_t) vm_page_array, page_range * sizeof(struct vm_page)); + for (i = 0; i < page_range; i++) + vm_page_array[i].order = VM_NFREEORDER; vm_page_array_size = page_range; /* @@ -352,10 +355,13 @@ ("vm_page_startup: inconsistent page counts")); /* - * Construct the free queue(s) in descending order (by physical - * address) so that the first 16MB of physical memory is allocated - * last rather than first. On large-memory machines, this avoids - * the exhaustion of low physical memory before isa_dma_init has run. + * Initialize the physical memory allocator. + */ + vm_phys_init(); + + /* + * Add every available physical page that is not blacklisted to + * the free lists. */ cnt.v_page_count = 0; cnt.v_free_count = 0; @@ -369,7 +375,7 @@ printf("Skipping page with pa 0x%jx\n", (uintmax_t)pa); else - vm_pageq_add_new_page(pa); + vm_phys_add_page(pa); pa += PAGE_SIZE; } } @@ -543,7 +549,7 @@ { KASSERT(VM_PAGE_GETKNOWNQUEUE1(m) != PQ_CACHE, ("vm_page_dirty: page in cache!")); - KASSERT(VM_PAGE_GETKNOWNQUEUE1(m) != PQ_FREE, + KASSERT(!VM_PAGE_IS_FREE(m), ("vm_page_dirty: page is free!")); m->dirty = VM_PAGE_BITS_ALL; } @@ -799,14 +805,14 @@ * This routine may not block. */ vm_page_t -vm_page_select_cache(int color) +vm_page_select_cache(void) { vm_object_t object; vm_page_t m; boolean_t was_trylocked; mtx_assert(&vm_page_queue_mtx, MA_OWNED); - while ((m = vm_pageq_find(PQ_CACHE, color, FALSE)) != NULL) { + while ((m = TAILQ_FIRST(&vm_page_queues[PQ_CACHE].pl)) != NULL) { KASSERT(m->dirty == 0, ("Found dirty cache page %p", m)); KASSERT(!pmap_page_is_mapped(m), ("Found mapped cache page %p", m)); @@ -850,7 +856,7 @@ vm_page_alloc(vm_object_t object, vm_pindex_t pindex, int req) { vm_page_t m = NULL; - int color, flags, page_req; + int flags, page_req; page_req = req & VM_ALLOC_CLASS_MASK; KASSERT(curthread->td_intr_nesting_level == 0 || @@ -861,9 +867,7 @@ KASSERT(object != NULL, ("vm_page_alloc: NULL object.")); VM_OBJECT_LOCK_ASSERT(object, MA_OWNED); - color = (pindex + object->pg_color) & PQ_COLORMASK; - } else - color = pindex & PQ_COLORMASK; + } /* * The pager is allowed to eat deeper into the free page list. @@ -883,7 +887,8 @@ * Allocate from the free queue if the number of free pages * exceeds the minimum for the request class. */ - m = vm_pageq_find(PQ_FREE, color, (req & VM_ALLOC_ZERO) != 0); + m = vm_phys_alloc_pages_locked(object != NULL ? + VM_FREEPOOL_DEFAULT : VM_FREEPOOL_DIRECT, 0); } else if (page_req != VM_ALLOC_INTERRUPT) { mtx_unlock(&vm_page_queue_free_mtx); /* @@ -892,7 +897,7 @@ * cnt.v_*_free_min counters are replenished. */ vm_page_lock_queues(); - if ((m = vm_page_select_cache(color)) == NULL) { + if ((m = vm_page_select_cache()) == NULL) { KASSERT(cnt.v_cache_count == 0, ("vm_page_alloc: cache queue is missing %d pages", cnt.v_cache_count)); @@ -908,7 +913,8 @@ mtx_unlock(&vm_page_queue_free_mtx); return (NULL); } - m = vm_pageq_find(PQ_FREE, color, (req & VM_ALLOC_ZERO) != 0); + m = vm_phys_alloc_pages_locked(object != NULL ? + VM_FREEPOOL_DEFAULT : VM_FREEPOOL_DIRECT, 0); } else { vm_page_unlock_queues(); goto loop; @@ -931,11 +937,8 @@ m != NULL, ("vm_page_alloc(): missing page on free queue") ); - - /* - * Remove from free queue - */ - vm_pageq_remove_nowakeup(m); + KASSERT(VM_PAGE_IS_FREE(m), + ("vm_page_alloc: page %p is not free", m)); /* * Initialize structure. Only the PG_ZERO flag is inherited. @@ -1096,7 +1099,7 @@ /* * vm_page_free_toq: * - * Returns the given page to the PQ_FREE list, + * Returns the given page to the free list, * disassociating it with any VM object. * * Object and page must be locked prior to entry. @@ -1106,7 +1109,6 @@ void vm_page_free_toq(vm_page_t m) { - struct vpgqueues *pq; if (VM_PAGE_GETQUEUE(m) != PQ_NONE) mtx_assert(&vm_page_queue_mtx, MA_OWNED); @@ -1114,12 +1116,12 @@ ("vm_page_free_toq: freeing mapped page %p", m)); PCPU_INC(cnt.v_tfree); - if (m->busy || VM_PAGE_INQUEUE1(m, PQ_FREE)) { + if (m->busy || VM_PAGE_IS_FREE(m)) { printf( "vm_page_free: pindex(%lu), busy(%d), VPO_BUSY(%d), hold(%d)\n", (u_long)m->pindex, m->busy, (m->oflags & VPO_BUSY) ? 1 : 0, m->hold_count); - if (VM_PAGE_INQUEUE1(m, PQ_FREE)) + if (VM_PAGE_IS_FREE(m)) panic("vm_page_free: freeing free page"); else panic("vm_page_free: freeing busy page"); @@ -1155,27 +1157,19 @@ if (m->hold_count != 0) { m->flags &= ~PG_ZERO; vm_pageq_enqueue(PQ_HOLD, m); - return; - } - VM_PAGE_SETQUEUE1(m, PQ_FREE); - mtx_lock(&vm_page_queue_free_mtx); - pq = &vm_page_queues[VM_PAGE_GETQUEUE(m)]; - pq->lcnt++; - ++(*pq->cnt); - - /* - * Put zero'd pages on the end ( where we look for zero'd pages - * first ) and non-zerod pages at the head. - */ - if (m->flags & PG_ZERO) { - TAILQ_INSERT_TAIL(&pq->pl, m, pageq); - ++vm_page_zero_count; } else { - TAILQ_INSERT_HEAD(&pq->pl, m, pageq); - vm_page_zero_idle_wakeup(); + m->flags |= PG_FREE; + mtx_lock(&vm_page_queue_free_mtx); + if ((m->flags & PG_ZERO) != 0) { + vm_phys_free_pages_locked(m, 0); + ++vm_page_zero_count; + } else { + vm_phys_free_pages_locked(m, 0); + vm_page_zero_idle_wakeup(); + } + vm_page_free_wakeup(); + mtx_unlock(&vm_page_queue_free_mtx); } - vm_page_free_wakeup(); - mtx_unlock(&vm_page_queue_free_mtx); } /* @@ -1294,7 +1288,6 @@ else TAILQ_INSERT_TAIL(&vm_page_queues[PQ_INACTIVE].pl, m, pageq); VM_PAGE_SETQUEUE2(m, PQ_INACTIVE); - vm_page_queues[PQ_INACTIVE].lcnt++; cnt.v_inactive_count++; } } @@ -1382,7 +1375,7 @@ (long)m->pindex); } vm_pageq_remove_nowakeup(m); - vm_pageq_enqueue(PQ_CACHE + m->pc, m); + vm_pageq_enqueue(PQ_CACHE, m); mtx_lock(&vm_page_queue_free_mtx); vm_page_free_wakeup(); mtx_unlock(&vm_page_queue_free_mtx); @@ -1794,21 +1787,17 @@ DB_SHOW_COMMAND(pageq, vm_page_print_pageq_info) { - int i; + db_printf("PQ_FREE:"); - for (i = 0; i < PQ_NUMCOLORS; i++) { - db_printf(" %d", vm_page_queues[PQ_FREE + i].lcnt); - } + db_printf(" %d", cnt.v_free_count); db_printf("\n"); db_printf("PQ_CACHE:"); - for (i = 0; i < PQ_NUMCOLORS; i++) { - db_printf(" %d", vm_page_queues[PQ_CACHE + i].lcnt); - } + db_printf(" %d", *vm_page_queues[PQ_CACHE].cnt); db_printf("\n"); db_printf("PQ_ACTIVE: %d, PQ_INACTIVE: %d\n", - vm_page_queues[PQ_ACTIVE].lcnt, - vm_page_queues[PQ_INACTIVE].lcnt); + *vm_page_queues[PQ_ACTIVE].cnt, + *vm_page_queues[PQ_INACTIVE].cnt); } #endif /* DDB */ diff -ru /usr/src/sys/vm/vm_page.h /mnt/usr/src/sys/vm/vm_page.h --- /usr/src/sys/vm/vm_page.h Fri Aug 31 16:18:50 2007 +++ /mnt/usr/src/sys/vm/vm_page.h Fri Aug 31 16:06:25 2007 @@ -57,7 +57,7 @@ * any improvements or extensions that they make and grant Carnegie the * rights to redistribute these changes. * - * $FreeBSD: src/sys/vm/vm_page.h,v 1.148 2007/05/05 19:50:28 alc Exp $ + * $FreeBSD: src/sys/vm/vm_page.h,v 1.149 2007/06/16 04:57:05 alc Exp $ */ /* @@ -110,9 +110,11 @@ vm_pindex_t pindex; /* offset into object (O,P) */ vm_paddr_t phys_addr; /* physical address of page */ struct md_page md; /* machine dependant stuff */ - u_short queue; /* page queue index */ - u_short flags, /* see below */ - pc; /* page color */ + uint8_t queue; /* page queue index */ + int8_t segind; + u_short flags; /* see below */ + uint8_t order; /* index of the buddy queue */ + uint8_t pool; u_short wire_count; /* wired down maps refs (P) */ u_int cow; /* page cow mapping count */ short hold_count; /* page hold count */ @@ -155,62 +157,39 @@ #endif #endif -/* PQ_CACHE and PQ_FREE represents a PQ_NUMCOLORS consecutive queue. */ #define PQ_NONE 0 -#define PQ_FREE 1 -#define PQ_INACTIVE (page_queue_coloring.inactive) -#define PQ_ACTIVE (page_queue_coloring.active) -#define PQ_CACHE (page_queue_coloring.cache) -#define PQ_HOLD (page_queue_coloring.hold) -#define PQ_COUNT (page_queue_coloring.count) -#define PQ_MAXCOLORS 1024 -#define PQ_MAXCOUNT (4 + 2 * PQ_MAXCOLORS) -#define PQ_NUMCOLORS (page_queue_coloring.numcolors) -#define PQ_PRIME1 (page_queue_coloring.prime1) -#define PQ_PRIME2 (page_queue_coloring.prime2) -#define PQ_COLORMASK (page_queue_coloring.colormask) -#define PQ_MAXLENGTH (page_queue_coloring.maxlength) +#define PQ_INACTIVE 1 +#define PQ_ACTIVE 2 +#define PQ_CACHE 3 +#define PQ_HOLD 4 +#define PQ_COUNT 5 +#define PQ_MAXCOUNT 5 /* Returns the real queue a page is on. */ #define VM_PAGE_GETQUEUE(m) ((m)->queue) /* Returns the well known queue a page is on. */ -#define VM_PAGE_GETKNOWNQUEUE1(m) ((m)->queue - (m)->pc) +#define VM_PAGE_GETKNOWNQUEUE1(m) VM_PAGE_GETQUEUE(m) #define VM_PAGE_GETKNOWNQUEUE2(m) VM_PAGE_GETQUEUE(m) /* Given the real queue number and a page color return the well know queue. */ -#define VM_PAGE_RESOLVEQUEUE(m, q) ((q) - (m)->pc) +#define VM_PAGE_RESOLVEQUEUE(m, q) (q) /* Returns true if the page is in the named well known queue. */ #define VM_PAGE_INQUEUE1(m, q) (VM_PAGE_GETKNOWNQUEUE1(m) == (q)) #define VM_PAGE_INQUEUE2(m, q) (VM_PAGE_GETKNOWNQUEUE2(m) == (q)) /* Sets the queue a page is on. */ -#define VM_PAGE_SETQUEUE1(m, q) (VM_PAGE_GETQUEUE(m) = (q) + (m)->pc) +#define VM_PAGE_SETQUEUE1(m, q) (VM_PAGE_GETQUEUE(m) = (q)) #define VM_PAGE_SETQUEUE2(m, q) (VM_PAGE_GETQUEUE(m) = (q)) struct vpgqueues { struct pglist pl; int *cnt; - int lcnt; -}; - -struct pq_coloring { - int numcolors; - int colormask; - int prime1; - int prime2; - int inactive; - int active; - int cache; - int hold; - int count; - int maxlength; }; extern struct vpgqueues vm_page_queues[PQ_MAXCOUNT]; extern struct mtx vm_page_queue_free_mtx; -extern struct pq_coloring page_queue_coloring; /* * These are the flags defined for vm_page. @@ -222,6 +201,7 @@ * pte mappings, nor can they be removed from their objects via * the object, and such pages are also not on any PQ queue. */ +#define PG_FREE 0x0002 /* page is free */ #define PG_WINATCFLS 0x0004 /* flush dirty page on inactive q */ #define PG_FICTITIOUS 0x0008 /* physical page doesn't exist (O) */ #define PG_WRITEABLE 0x0010 /* page is mapped writeable */ @@ -276,19 +256,19 @@ extern int vm_page_array_size; /* number of vm_page_t's */ extern long first_page; /* first physical page number */ +#define VM_PAGE_IS_FREE(m) (((m)->flags & PG_FREE) != 0) + #define VM_PAGE_TO_PHYS(entry) ((entry)->phys_addr) +vm_page_t vm_phys_paddr_to_vm_page(vm_paddr_t pa); + static __inline vm_page_t PHYS_TO_VM_PAGE(vm_paddr_t pa); static __inline vm_page_t PHYS_TO_VM_PAGE(vm_paddr_t pa) { #ifdef VM_PHYSSEG_SPARSE - int i, j = 0; - - for (i = 0; phys_avail[i + 1] <= pa || phys_avail[i] > pa; i += 2) - j += atop(phys_avail[i + 1] - phys_avail[i]); - return (&vm_page_array[j + atop(pa - phys_avail[i])]); + return (vm_phys_paddr_to_vm_page(pa)); #elif defined(VM_PHYSSEG_DENSE) return (&vm_page_array[atop(pa) - first_page]); #else @@ -336,17 +316,13 @@ void vm_page_wakeup(vm_page_t m); void vm_pageq_init(void); -void vm_pageq_add_new_page(vm_paddr_t pa); void vm_pageq_enqueue(int queue, vm_page_t m); void vm_pageq_remove_nowakeup(vm_page_t m); void vm_pageq_remove(vm_page_t m); -vm_page_t vm_pageq_find(int basequeue, int index, boolean_t prefer_zero); void vm_pageq_requeue(vm_page_t m); void vm_page_activate (vm_page_t); vm_page_t vm_page_alloc (vm_object_t, vm_pindex_t, int); -vm_page_t vm_page_alloc_contig (vm_pindex_t, vm_paddr_t, vm_paddr_t, - vm_offset_t, vm_offset_t); vm_page_t vm_page_grab (vm_object_t, vm_pindex_t, int); void vm_page_cache (register vm_page_t); int vm_page_try_to_cache (vm_page_t); @@ -357,7 +333,7 @@ vm_page_t vm_page_lookup (vm_object_t, vm_pindex_t); void vm_page_remove (vm_page_t); void vm_page_rename (vm_page_t, vm_object_t, vm_pindex_t); -vm_page_t vm_page_select_cache(int); +vm_page_t vm_page_select_cache(void); void vm_page_sleep(vm_page_t m, const char *msg); vm_page_t vm_page_splay(vm_pindex_t, vm_page_t); vm_offset_t vm_page_startup(vm_offset_t vaddr); diff -ru /usr/src/sys/vm/vm_pageout.c /mnt/usr/src/sys/vm/vm_pageout.c --- /usr/src/sys/vm/vm_pageout.c Fri Aug 31 16:18:50 2007 +++ /mnt/usr/src/sys/vm/vm_pageout.c Fri Aug 31 16:06:25 2007 @@ -73,7 +73,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/vm/vm_pageout.c,v 1.285 2007/06/13 06:10:10 alc Exp $"); +__FBSDID("$FreeBSD: src/sys/vm/vm_pageout.c,v 1.286 2007/06/16 04:57:06 alc Exp $"); #include "opt_vm.h" #include @@ -682,8 +682,7 @@ struct thread *td; vm_offset_t size, bigsize; vm_object_t object; - int actcount, cache_cur, cache_first_failure; - static int cache_last_free; + int actcount; int vnodes_skipped = 0; int maxlaunder; @@ -1145,12 +1144,8 @@ * are considered basically 'free', moving pages from cache to free * does not effect other calculations. */ - cache_cur = cache_last_free; - cache_first_failure = -1; - while (cnt.v_free_count < cnt.v_free_reserved && (cache_cur = - (cache_cur + PQ_PRIME2) & PQ_COLORMASK) != cache_first_failure) { - TAILQ_FOREACH(m, &vm_page_queues[PQ_CACHE + cache_cur].pl, - pageq) { + while (cnt.v_free_count < cnt.v_free_reserved) { + TAILQ_FOREACH(m, &vm_page_queues[PQ_CACHE].pl, pageq) { KASSERT(m->dirty == 0, ("Found dirty cache page %p", m)); KASSERT(!pmap_page_is_mapped(m), @@ -1167,13 +1162,11 @@ vm_page_free(m); VM_OBJECT_UNLOCK(object); cnt.v_dfree++; - cache_last_free = cache_cur; - cache_first_failure = -1; break; } } - if (m == NULL && cache_first_failure == -1) - cache_first_failure = cache_cur; + if (m == NULL) + break; } vm_page_unlock_queues(); #if !defined(NO_SWAPPING) @@ -1425,7 +1418,7 @@ cnt.v_pageout_free_min = (2*MAXBSIZE)/PAGE_SIZE + cnt.v_interrupt_free_min; cnt.v_free_reserved = vm_pageout_page_count + - cnt.v_pageout_free_min + (cnt.v_page_count / 768) + PQ_NUMCOLORS; + cnt.v_pageout_free_min + (cnt.v_page_count / 768); cnt.v_free_severe = cnt.v_free_min / 2; cnt.v_free_min += cnt.v_free_reserved; cnt.v_free_severe += cnt.v_free_reserved; diff -ru /usr/src/sys/vm/vm_pageq.c /mnt/usr/src/sys/vm/vm_pageq.c --- /usr/src/sys/vm/vm_pageq.c Fri Aug 31 16:18:50 2007 +++ /mnt/usr/src/sys/vm/vm_pageq.c Fri Aug 31 16:06:25 2007 @@ -26,9 +26,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/vm/vm_pageq.c,v 1.33 2007/06/10 21:59:14 attilio Exp $"); - -#include "opt_vmpage.h" +__FBSDID("$FreeBSD: src/sys/vm/vm_pageq.c,v 1.34 2007/06/16 04:57:06 alc Exp $"); #include #include @@ -48,103 +46,17 @@ #include #include #include +#include #include -static void vm_coloring_init(void); -void setPQL2(int *const size, int *const ways); - struct vpgqueues vm_page_queues[PQ_MAXCOUNT]; -struct pq_coloring page_queue_coloring; - -static int pq_cachesize = 0; /* size of the cache in KB */ -static int pq_cachenways = 0; /* associativity of the cache */ - -SYSCTL_NODE(_vm_stats, OID_AUTO, pagequeue, CTLFLAG_RW, 0, "VM meter stats"); -SYSCTL_INT(_vm_stats_pagequeue, OID_AUTO, page_colors, CTLFLAG_RD, - &(PQ_NUMCOLORS), 0, "Number of colors in the page queue"); -SYSCTL_INT(_vm_stats_pagequeue, OID_AUTO, cachesize, CTLFLAG_RD, - &pq_cachesize, 0, "Size of the processor cache in KB"); -SYSCTL_INT(_vm_stats_pagequeue, OID_AUTO, cachenways, CTLFLAG_RD, - &pq_cachenways, 0, "Associativity of the processor cache"); -SYSCTL_INT(_vm_stats_pagequeue, OID_AUTO, prime1, CTLFLAG_RD, - &(PQ_PRIME1), 0, "Cache tuning value"); -SYSCTL_INT(_vm_stats_pagequeue, OID_AUTO, prime2, CTLFLAG_RD, - &(PQ_PRIME2), 0, "Cache tuning value"); - -static void -vm_coloring_init(void) -{ -#ifdef PQ_NOOPT - PQ_NUMCOLORS = PQ_PRIME1 = PQ_PRIME2 = 1; -#else - - setPQL2(&pq_cachesize, &pq_cachenways); - - CTASSERT(PAGE_SIZE/1024 > 0); - - if (pq_cachesize > 0 && pq_cachenways > 0) - PQ_NUMCOLORS = pq_cachesize / (PAGE_SIZE/1024) / \ - pq_cachenways; - else - PQ_NUMCOLORS = 32; - - if (PQ_MAXCOLORS < PQ_NUMCOLORS) { - printf("VM-PQ color limit (PQ_MAXCOLORS=%u) exceeded (%u), see vm_page.h", PQ_MAXCOLORS, PQ_NUMCOLORS); - PQ_NUMCOLORS = PQ_MAXCOLORS; - } - - if (PQ_NUMCOLORS >= 128) { - PQ_PRIME1 = 31; - PQ_PRIME2 = 23; - } else if (PQ_NUMCOLORS >= 64) { - PQ_PRIME1 = 13; - PQ_PRIME2 = 7; - } else if (PQ_NUMCOLORS >= 32) { - PQ_PRIME1 = 9; - PQ_PRIME2 = 5; - } else if (PQ_NUMCOLORS >= 16) { - PQ_PRIME1 = 5; - PQ_PRIME2 = 3; - } else - PQ_NUMCOLORS = PQ_PRIME1 = PQ_PRIME2 = 1; -#endif - - /* - * PQ_CACHE represents a - * PQ_NUMCOLORS consecutive queue. - */ - PQ_COLORMASK = PQ_NUMCOLORS - 1; - PQ_INACTIVE = 1 + PQ_NUMCOLORS; - PQ_ACTIVE = 2 + PQ_NUMCOLORS; - PQ_CACHE = 3 + PQ_NUMCOLORS; - PQ_HOLD = 3 + 2 * PQ_NUMCOLORS; - PQ_COUNT = 4 + 2 * PQ_NUMCOLORS; - PQ_MAXLENGTH = PQ_NUMCOLORS / 3 + PQ_PRIME1; - -#if 0 - /* XXX: is it possible to allocate vm_page_queues[PQ_COUNT] here? */ -#error XXX: vm_page_queues = malloc(PQ_COUNT * sizeof(struct vpgqueues)); -#endif - - if (bootverbose) - if (PQ_NUMCOLORS > 1) - printf("Using %d colors for the VM-PQ tuning (%d, %d)\n", - PQ_NUMCOLORS, pq_cachesize, pq_cachenways); -} void vm_pageq_init(void) { int i; - vm_coloring_init(); - - for (i = 0; i < PQ_NUMCOLORS; ++i) { - vm_page_queues[PQ_FREE+i].cnt = &cnt.v_free_count; - } - for (i = 0; i < PQ_NUMCOLORS; ++i) { - vm_page_queues[PQ_CACHE + i].cnt = &cnt.v_cache_count; - } + vm_page_queues[PQ_CACHE].cnt = &cnt.v_cache_count; vm_page_queues[PQ_INACTIVE].cnt = &cnt.v_inactive_count; vm_page_queues[PQ_ACTIVE].cnt = &cnt.v_active_count; vm_page_queues[PQ_HOLD].cnt = &cnt.v_active_count; @@ -179,28 +91,6 @@ VM_PAGE_SETQUEUE2(m, queue); TAILQ_INSERT_TAIL(&vpq->pl, m, pageq); ++*vpq->cnt; - ++vpq->lcnt; -} - -/* - * vm_add_new_page: - * - * Add a new page to the freelist for use by the system. - */ -void -vm_pageq_add_new_page(vm_paddr_t pa) -{ - vm_page_t m; - - cnt.v_page_count++; - m = PHYS_TO_VM_PAGE(pa); - m->phys_addr = pa; - m->flags = 0; - m->pc = (pa >> PAGE_SHIFT) & PQ_COLORMASK; - pmap_page_init(m); - mtx_lock(&vm_page_queue_free_mtx); - vm_pageq_enqueue(m->pc + PQ_FREE, m); - mtx_unlock(&vm_page_queue_free_mtx); } /* @@ -222,7 +112,6 @@ VM_PAGE_SETQUEUE2(m, PQ_NONE); TAILQ_REMOVE(&pq->pl, m, pageq); (*pq->cnt)--; - pq->lcnt--; } } @@ -245,86 +134,9 @@ pq = &vm_page_queues[queue]; TAILQ_REMOVE(&pq->pl, m, pageq); (*pq->cnt)--; - pq->lcnt--; if (VM_PAGE_RESOLVEQUEUE(m, queue) == PQ_CACHE) { if (vm_paging_needed()) pagedaemon_wakeup(); } } } - -#ifndef PQ_NOOPT - -/* - * vm_pageq_find: - * - * Find a page on the specified queue with color optimization. - * - * The page coloring optimization attempts to locate a page - * that does not overload other nearby pages in the object in - * the cpu's L2 cache. We need this optimization because cpu - * caches tend to be physical caches, while object spaces tend - * to be virtual. - * - * The specified queue must be locked. - * This routine may not block. - * - * This routine may only be called from the vm_pageq_find() - * function in this file. - */ -static inline vm_page_t -_vm_pageq_find(int basequeue, int index) -{ - int i; - vm_page_t m = NULL; - struct vpgqueues *pq; - - pq = &vm_page_queues[basequeue]; - - /* - * Note that for the first loop, index+i and index-i wind up at the - * same place. Even though this is not totally optimal, we've already - * blown it by missing the cache case so we do not care. - */ - for (i = PQ_NUMCOLORS / 2; i > 0; --i) { - if ((m = TAILQ_FIRST(&pq[(index + i) & PQ_COLORMASK].pl)) \ - != NULL) - break; - - if ((m = TAILQ_FIRST(&pq[(index - i) & PQ_COLORMASK].pl)) \ - != NULL) - break; - } - return (m); -} -#endif /* PQ_NOOPT */ - -vm_page_t -vm_pageq_find(int basequeue, int index, boolean_t prefer_zero) -{ - vm_page_t m; - -#ifndef PQ_NOOPT - if (PQ_NUMCOLORS > 1) { - if (prefer_zero) { - m = TAILQ_LAST(&vm_page_queues[basequeue+index].pl, \ - pglist); - } else { - m = TAILQ_FIRST(&vm_page_queues[basequeue+index].pl); - } - if (m == NULL) { - m = _vm_pageq_find(basequeue, index); - } - } else { -#endif - if (prefer_zero) { - m = TAILQ_LAST(&vm_page_queues[basequeue].pl, pglist); - } else { - m = TAILQ_FIRST(&vm_page_queues[basequeue].pl); - } -#ifndef PQ_NOOPT - } -#endif - return (m); -} - diff -ru /usr/src/sys/vm/vm_zeroidle.c /mnt/usr/src/sys/vm/vm_zeroidle.c --- /usr/src/sys/vm/vm_zeroidle.c Fri Aug 31 16:18:50 2007 +++ /mnt/usr/src/sys/vm/vm_zeroidle.c Fri Aug 31 16:06:25 2007 @@ -33,7 +33,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/vm/vm_zeroidle.c,v 1.47 2007/06/05 00:00:57 jeff Exp $"); +__FBSDID("$FreeBSD: src/sys/vm/vm_zeroidle.c,v 1.48 2007/06/16 04:57:06 alc Exp $"); #include @@ -51,12 +51,9 @@ #include #include +#include -static int cnt_prezero; -SYSCTL_INT(_vm_stats_misc, OID_AUTO, cnt_prezero, CTLFLAG_RD, - &cnt_prezero, 0, ""); - -static int idlezero_enable_default = 1; +static int idlezero_enable_default = 0; TUNABLE_INT("vm.idlezero_enable", &idlezero_enable_default); /* Defer setting the enable flag until the kthread is running. */ static int idlezero_enable = 0; @@ -100,25 +97,13 @@ static void vm_page_zero_idle(void) { - static int free_rover; - vm_page_t m; mtx_assert(&vm_page_queue_free_mtx, MA_OWNED); zero_state = 0; - m = vm_pageq_find(PQ_FREE, free_rover, FALSE); - if (m != NULL && (m->flags & PG_ZERO) == 0) { - vm_pageq_remove_nowakeup(m); - mtx_unlock(&vm_page_queue_free_mtx); - pmap_zero_page_idle(m); - mtx_lock(&vm_page_queue_free_mtx); - m->flags |= PG_ZERO; - vm_pageq_enqueue(PQ_FREE + m->pc, m); - ++vm_page_zero_count; - ++cnt_prezero; + if (vm_phys_zero_pages_idle()) { if (vm_page_zero_count >= ZIDLE_HI(cnt.v_free_count)) zero_state = 1; } - free_rover = (free_rover + PQ_PRIME2) & PQ_COLORMASK; } /* Called by vm_page_free to hint that a new page is available. */ --5vNYLRcllDrimb99-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 17:59:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FA6716A418 for ; Fri, 31 Aug 2007 17:59:11 +0000 (UTC) (envelope-from liouxbsd@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 9F74213C46B for ; Fri, 31 Aug 2007 17:59:10 +0000 (UTC) (envelope-from liouxbsd@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so218408anc for ; Fri, 31 Aug 2007 10:58:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=uCGbdqBFCKJZ8k4hrCSqXkjGP+uu42sSHQV6yaRonPwQJaL6OLbJN1aN0jqJF5/Gv8wVZVjCgyisUVn/qxTAD8PZrcXXp9Z4Q4tq4G7o6VZznO5zFpRmFI1QW4EBdz9zvZ1WtfXKvNljjXDuPMW/CkjuUj4UNU57bAjBWi/acnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=LYm5t7PipBH0z15JFLcZV9lgzvoxcFnL3DtBja/AwN2CyX5BWPfD+qFmFWIpJH/kXISndJ5Qdk/P980QclP0yMytyLM/DDR5dxdvXGbZga0VV1zIGz07okIcKkVes7zms1JNIQpb0Sjcw9qkjYvMgz8T10w5dpGu3SKkXI3WXgQ= Received: by 10.100.135.16 with SMTP id i16mr1943900and.1188583134559; Fri, 31 Aug 2007 10:58:54 -0700 (PDT) Received: by 10.100.91.14 with HTTP; Fri, 31 Aug 2007 10:58:54 -0700 (PDT) Message-ID: <683701cf0708311058l5e80198fr432abb06d8128924@mail.gmail.com> Date: Fri, 31 Aug 2007 14:58:54 -0300 From: "Mario Ferreira" To: freebsd-current@freebsd.org In-Reply-To: <683701cf0708310509l40c14a78te54e6608c2f7d9ed@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10924_26135791.1188583134351" References: <683701cf0708310509l40c14a78te54e6608c2f7d9ed@mail.gmail.com> Subject: nfe(4) not working on asus m2n32sli-deluxe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 17:59:11 -0000 ------=_Part_10924_26135791.1188583134351 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I tried installing FreeBSD 7.0-Current 200708 i386 snapshot on a asus m2n32sli-deluxe wifi edition but I had some issues: 1) on board wlan adapter RTL8187_Wireless not supported 2) on board lan adapter NForce 590 SLI MCP does not work The lack of support for RTL8187_Wireless is not a problem for now. However, the NForce 590 SLI MCP Gigabit adapter is an issue. The nfe(4) driver detects the network carrier but it never ever detects the media settings. I tried hand setting media/mediaopt but it did not help. media: Ethernet autoselect (none) status: active Any suggestions? Let me know if there is anything I can do to help. Regards, - Asus m2n32sli deluxe wifi edition http://www.asus.com/products4.aspx?modelmenu=1&model=1163&l1=3&l2=101&l3=0 -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." FreeBSD Committer | FreeBSD-KDE Core Team | C/C++/Java Developer Network Designer | Network Administrator Unix/Windows | Systems Integrator feature, n: a documented bug | bug, n: an undocumented feature ------=_Part_10924_26135791.1188583134351 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.txt"; filename="dmesg.txt"; filename="dmesg.txt"; filename="dmesg.txt"; filename="dmesg.txt" X-Attachment-Id: f_f60n3epl Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjAtQ1VSUkVOVC0yMDA3MDggIzA6IEZyaSBBdWcg MTcgMDc6NDc6MTggVVRDIDIwMDcKICAgIHJvb3RAbG9nYW4uY3NlLmJ1ZmZhbG8uZWR1Oi91c3Iv b2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwg ZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5 IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogQU1EIEF0aGxvbih0bSkgNjQgWDIgRHVhbCBDb3Jl IFByb2Nlc3NvciA0NjAwKyAoMjQxMC45OS1NSHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAi QXV0aGVudGljQU1EIiAgSWQgPSAweDQwZmIyICBTdGVwcGluZyA9IDIKICBGZWF0dXJlcz0weDE3 OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQ R0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPgogIEZl YXR1cmVzMj0weDIwMDE8U1NFMyxDWDE2PgogIEFNRCBGZWF0dXJlcz0weGVhNTAwODAwPFNZU0NB TEwsTlgsTU1YKyxGRlhTUixSRFRTQ1AsTE0sM0ROb3chKywzRE5vdyE+CiAgQU1EIEZlYXR1cmVz Mj0weDFmPExBSEYsQ01QLFNWTSxFeHRBUElDLENSOD4KICBDb3JlcyBwZXIgcGFja2FnZTogMgpy ZWFsIG1lbW9yeSAgPSAyMTQ2MzA0MDAwICgyMDQ2IE1CKQphdmFpbCBtZW1vcnkgPSAyMDg2NTY3 OTM2ICgxOTg5IE1CKQpBQ1BJIEFQSUMgVGFibGU6IDxOdmlkaWEgQVNVU0FDUEk+CkZyZWVCU0Qv U01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwogY3B1MCAoQlNQKTog QVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKaW9hcGljMDogQ2hhbmdpbmcgQVBJ QyBJRCB0byAyCmlvYXBpYzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQK a2JkMSBhdCBrYmRtdXgwCmF0aF9oYWw6IDAuOS4yMC4zIChBUjUyMTAsIEFSNTIxMSwgQVI1MjEy LCBSRjUxMTEsIFJGNTExMiwgUkYyNDEzLCBSRjU0MTMpCmFjcGkwOiA8TnZpZGlhIEFTVVNBQ1BJ PiBvbiBtb3RoZXJib2FyZAphY3BpMDogW0lUSFJFQURdCmFjcGlfaHBldDA6IDxIaWdoIFByZWNp c2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWZmZjAwMC0weGZlZmZmM2ZmIG9uIGFjcGkwClRp bWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMjUwMDAwMDAgSHogcXVhbGl0eSA5MDAKYWNwaTA6 IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmFjcGkwOiByZXNlcnZhdGlvbiBvZiBmZWZmZjAwMCwgMTAw MCAoMykgZmFpbGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAoMykgZmFpbGVkCmFj cGkwOiByZXNlcnZhdGlvbiBvZiAxMDAwMDAsIDdmZGUwMDAwICgzKSBmYWlsZWQKVGltZWNvdW50 ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGlt ZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24g YWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApwb3dlcm5vdzA6IDxQb3dlck5vdyEgSzg+ IG9uIGNwdTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApwb3dlcm5vdzE6IDxQb3dlck5vdyEg Szg+IG9uIGNwdTEKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMApwY2liMDog PEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAuMCAo bm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAwLjEgKG5v IGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC4yIChubyBk cml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAuMyAobm8gZHJp dmVyIGF0dGFjaGVkKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAwLjQgKG5vIGRyaXZl ciBhdHRhY2hlZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC41IChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAuNiAobm8gZHJpdmVyIGF0 dGFjaGVkKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAwLjcgKG5vIGRyaXZlciBhdHRh Y2hlZCkKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNC4wIG9uIHBjaTAK cGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRp c3BsYXk+IHBvcnQgMHg4YzAwLTB4OGM3ZiBtZW0gMHhmYTAwMDAwMC0weGZhZmZmZmZmLDB4YzAw MDAwMDAtMHhkZmZmZmZmZiwweGY4MDAwMDAwLTB4ZjlmZmZmZmYgaXJxIDE2IGF0IGRldmljZSAw LjAgb24gcGNpMQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSA4LjAgKG5vIGRyaXZlciBh dHRhY2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDkuMCBvbiBwY2kwCmlz YTA6IDxJU0EgYnVzPiBvbiBpc2FiMApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmlj ZSA5LjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2Ug OS4yIChubyBkcml2ZXIgYXR0YWNoZWQpCm9oY2kwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRy b2xsZXI+IG1lbSAweGZlMDJmMDAwLTB4ZmUwMmZmZmYgaXJxIDIxIGF0IGRldmljZSAxMC4wIG9u IHBjaTAKb2hjaTA6IFtHSUFOVC1MT0NLRURdCm9oY2kwOiBbSVRIUkVBRF0KdXNiMDogT0hDSSB2 ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNiMDogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJl c2V0dGluZwp1c2IwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCnVz YjA6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjA6IDxuVmlkaWEgT0hDSSByb290IGh1YiwgY2xhc3Mg OS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjAKdWh1YjA6IDEwIHBvcnRzIHdpdGgg MTAgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKZWhjaTA6IDxFSENJIChnZW5lcmljKSBVU0IgMi4w IGNvbnRyb2xsZXI+IG1lbSAweGZlMDJlMDAwLTB4ZmUwMmUwZmYgaXJxIDIyIGF0IGRldmljZSAx MC4xIG9uIHBjaTAKZWhjaTA6IFtHSUFOVC1MT0NLRURdCmVoY2kwOiBbSVRIUkVBRF0KdXNiMTog RUhDSSB2ZXJzaW9uIDEuMAp1c2IxOiBjb21wYW5pb24gY29udHJvbGxlciwgMTAgcG9ydHMgZWFj aDogdXNiMAp1c2IxOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNp MAp1c2IxOiBVU0IgcmV2aXNpb24gMi4wCnVodWIxOiA8blZpZGlhIEVIQ0kgcm9vdCBodWIsIGNs YXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IxCnVodWIxOiAxMCBwb3J0cyB3 aXRoIDEwIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW4wOiA8dmVuZG9yIDB4MGJkYSBSVEw4 MTg3X1dpcmVsZXNzLCBjbGFzcyAwLzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMj4gb24gdWh1YjEK YXRhcGNpMDogPG5WaWRpYSBuRm9yY2UgTUNQNTUgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4 MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4ZjQwMC0weGY0MGYgYXQgZGV2aWNl IDEyLjAgb24gcGNpMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGEwOiBbSVRI UkVBRF0KYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhMTogW0lUSFJFQURdCmF0 YXBjaTE6IDxuVmlkaWEgbkZvcmNlIE1DUDU1IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweDlm MC0weDlmNywweGJmMC0weGJmMywweDk3MC0weDk3NywweGI3MC0weGI3MywweGUwMDAtMHhlMDBm IG1lbSAweGZlMDJkMDAwLTB4ZmUwMmRmZmYgaXJxIDIzIGF0IGRldmljZSAxMy4wIG9uIHBjaTAK YXRhcGNpMTogW0lUSFJFQURdCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kxCmF0YTI6 IFtJVEhSRUFEXQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQphdGEzOiBbSVRIUkVB RF0KYXRhcGNpMjogPG5WaWRpYSBuRm9yY2UgTUNQNTUgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0 IDB4OWUwLTB4OWU3LDB4YmUwLTB4YmUzLDB4OTYwLTB4OTY3LDB4YjYwLTB4YjYzLDB4Y2MwMC0w eGNjMGYgbWVtIDB4ZmUwMmMwMDAtMHhmZTAyY2ZmZiBpcnEgMjAgYXQgZGV2aWNlIDEzLjEgb24g cGNpMAphdGFwY2kyOiBbSVRIUkVBRF0KYXRhNDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTIK YXRhNDogW0lUSFJFQURdCmF0YTU6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kyCmF0YTU6IFtJ VEhSRUFEXQphdGFwY2kzOiA8blZpZGlhIG5Gb3JjZSBNQ1A1NSBTQVRBMzAwIGNvbnRyb2xsZXI+ IHBvcnQgMHhjODAwLTB4YzgwNywweGM0MDAtMHhjNDAzLDB4YzAwMC0weGMwMDcsMHhiYzAwLTB4 YmMwMywweGI4MDAtMHhiODBmIG1lbSAweGZlMDJiMDAwLTB4ZmUwMmJmZmYgaXJxIDIxIGF0IGRl dmljZSAxMy4yIG9uIHBjaTAKYXRhcGNpMzogW0lUSFJFQURdCmF0YTY6IDxBVEEgY2hhbm5lbCAw PiBvbiBhdGFwY2kzCmF0YTY6IFtJVEhSRUFEXQphdGE3OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRh cGNpMwphdGE3OiBbSVRIUkVBRF0KcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMTQuMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCmF0YXBjaTQ6IDxI aWdoUG9pbnQgSFBUMzcwIFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweGFjMDAtMHhhYzA3LDB4 YTgwMC0weGE4MDMsMHhhNDAwLTB4YTQwNywweGEwMDAtMHhhMDAzLDB4OWMwMC0weDljZmYgaXJx IDE3IGF0IGRldmljZSA3LjAgb24gcGNpMgphdGFwY2k0OiBbSVRIUkVBRF0KYXRhODogPEFUQSBj aGFubmVsIDA+IG9uIGF0YXBjaTQKYXRhODogW0lUSFJFQURdCmF0YTk6IDxBVEEgY2hhbm5lbCAx PiBvbiBhdGFwY2k0CmF0YTk6IFtJVEhSRUFEXQpwY2kyOiA8bXVsdGltZWRpYSwgYXVkaW8+IGF0 IGRldmljZSA4LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMjogPGlucHV0IGRldmljZT4gYXQg ZGV2aWNlIDguMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpmd29oY2kwOiA8MTM5NCBPcGVuIEhvc3Qg Q29udHJvbGxlciBJbnRlcmZhY2U+IG1lbSAweGZkZmZmMDAwLTB4ZmRmZmY3ZmYsMHhmZGZmODAw MC0weGZkZmZiZmZmIGlycSAxOSBhdCBkZXZpY2UgOC4yIG9uIHBjaTIKZndvaGNpMDogW0ZJTFRF Ul0KZndvaGNpMDogT0hDSSB2ZXJzaW9uIDEuMTAgKFJPTT0wKQpmd29oY2kwOiBOby4gb2YgSXNv Y2hyb25vdXMgY2hhbm5lbHMgaXMgNC4KZndvaGNpMDogRVVJNjQgMDA6MDI6M2M6MDE6MDE6MDU6 NGI6NzEKZndvaGNpMDogUGh5IDEzOTRhIGF2YWlsYWJsZSBTNDAwLCAyIHBvcnRzLgpmd29oY2kw OiBMaW5rIFM0MDAsIG1heF9yZWMgMjA0OCBieXRlcy4KZmlyZXdpcmUwOiA8SUVFRTEzOTQoRmly ZVdpcmUpIGJ1cz4gb24gZndvaGNpMApmd2UwOiA8RXRoZXJuZXQgb3ZlciBGaXJlV2lyZT4gb24g ZmlyZXdpcmUwCmlmX2Z3ZTA6IEZha2UgRXRoZXJuZXQgYWRkcmVzczogMDI6MDI6M2M6MDU6NGI6 NzEKZndlMDogRXRoZXJuZXQgYWRkcmVzczogMDI6MDI6M2M6MDU6NGI6NzEKZndpcDA6IDxJUCBv dmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKZndpcDA6IEZpcmV3aXJlIGFkZHJlc3M6IDAwOjAy OjNjOjAxOjAxOjA1OjRiOjcxIEAgMHhmZmZlMDAwMDAwMDAsIFM0MDAsIG1heHJlYyAyMDQ4CnNi cDA6IDxTQlAtMi9TQ1NJIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApkY29uc19jcm9tMDog PGRjb25zIGNvbmZpZ3VyYXRpb24gUk9NPiBvbiBmaXJld2lyZTAKZGNvbnNfY3JvbTA6IGJ1c19h ZGRyIDB4N2Q4NzQwMDAKZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3b2hjaTA6IEJVUyBy ZXNldApmd29oY2kwOiBub2RlX2lkPTB4YzgwMGZmYzAsIGdlbj0xLCBDWUNMRU1BU1RFUiBtb2Rl CmZ3b2hjaTE6IDxUZXhhcyBJbnN0cnVtZW50cyBUU0I0M0FCMjIvQT4gbWVtIDB4ZmRmZmUwMDAt MHhmZGZmZTdmZiwweGZkZmY0MDAwLTB4ZmRmZjdmZmYgaXJxIDE2IGF0IGRldmljZSAxMS4wIG9u IHBjaTIKZndvaGNpMTogW0ZJTFRFUl0KZndvaGNpMTogT0hDSSB2ZXJzaW9uIDEuMTAgKFJPTT0x KQpmd29oY2kxOiBOby4gb2YgSXNvY2hyb25vdXMgY2hhbm5lbHMgaXMgNC4KZndvaGNpMTogRVVJ NjQgMDA6MTE6ZDg6MDA6MDE6NDc6NDQ6ZDkKZndvaGNpMTogUGh5IDEzOTRhIGF2YWlsYWJsZSBT NDAwLCAyIHBvcnRzLgpmd29oY2kxOiBMaW5rIFM0MDAsIG1heF9yZWMgMjA0OCBieXRlcy4KZmly ZXdpcmUxOiA8SUVFRTEzOTQoRmlyZVdpcmUpIGJ1cz4gb24gZndvaGNpMQpmd2UxOiA8RXRoZXJu ZXQgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUxCmlmX2Z3ZTE6IEZha2UgRXRoZXJuZXQgYWRk cmVzczogMDI6MTE6ZDg6NDc6NDQ6ZDkKZndlMTogRXRoZXJuZXQgYWRkcmVzczogMDI6MTE6ZDg6 NDc6NDQ6ZDkKZndpcDE6IDxJUCBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTEKZndpcDE6IEZp cmV3aXJlIGFkZHJlc3M6IDAwOjExOmQ4OjAwOjAxOjQ3OjQ0OmQ5IEAgMHhmZmZlMDAwMDAwMDAs IFM0MDAsIG1heHJlYyAyMDQ4CnNicDE6IDxTQlAtMi9TQ1NJIG92ZXIgRmlyZVdpcmU+IG9uIGZp cmV3aXJlMQpkY29uc19jcm9tMTogPGRjb25zIGNvbmZpZ3VyYXRpb24gUk9NPiBvbiBmaXJld2ly ZTEKZGNvbnNfY3JvbTE6IGJ1c19hZGRyIDB4N2Q4NzQwMDAKZGNvbnNfY3JvbTE6IGRjb25zX3Bh ZGRyIGlzIGFscmVhZHkgc2V0CmZ3b2hjaTE6IEluaXRpYXRlIGJ1cyByZXNldApmd29oY2kxOiBC VVMgcmVzZXQKZndvaGNpMTogbm9kZV9pZD0weGM4MDBmZmMwLCBnZW49MSwgQ1lDTEVNQVNURVIg bW9kZQpuZmUwOiA8TlZJRElBIG5Gb3JjZSBNQ1A1NSBOZXR3b3JraW5nIEFkYXB0ZXI+IHBvcnQg MHhiNDAwLTB4YjQwNyBtZW0gMHhmZTAyYTAwMC0weGZlMDJhZmZmLDB4ZmUwMjkwMDAtMHhmZTAy OTBmZiwweGZlMDI4MDAwLTB4ZmUwMjgwMGYgaXJxIDIyIGF0IGRldmljZSAxNi4wIG9uIHBjaTAK bWlpYnVzMDogPE1JSSBidXM+IG9uIG5mZTAKZTEwMDBwaHkwOiA8TWFydmVsbCA4OEUxMTE2IEdp Z2FiaXQgUEhZPiBQSFkgMSBvbiBtaWlidXMwCmUxMDAwcGh5MDogIDEwYmFzZVQsIDEwYmFzZVQt RkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVFgtRkRYLCBhdXRvCm5mZTA6 IEV0aGVybmV0IGFkZHJlc3M6IDAwOjFiOmZjOjM5OmZiOjIzCm5mZTA6IFtGSUxURVJdCm5mZTA6 IFtGSUxURVJdCm5mZTA6IFtGSUxURVJdCm5mZTA6IFtGSUxURVJdCm5mZTA6IFtGSUxURVJdCm5m ZTA6IFtGSUxURVJdCm5mZTA6IFtGSUxURVJdCm5mZTA6IFtGSUxURVJdCnBjaWIzOiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIyLjAgb24gcGNpMApwY2kzOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMwphdGFwY2k1OiA8U2lJIDMxMzIgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4 N2MwMC0weDdjN2YgbWVtIDB4ZmRlZmYwMDAtMHhmZGVmZjA3ZiwweGZkZWY4MDAwLTB4ZmRlZmJm ZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMwphdGFwY2k1OiBbSVRIUkVBRF0KYXRhMTA6 IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2k1CmF0YTEwOiBbSVRIUkVBRF0KYXRhMTE6IDxBVEEg Y2hhbm5lbCAxPiBvbiBhdGFwY2k1CmF0YTExOiBbSVRIUkVBRF0KYWNwaV90ejA6IDxUaGVybWFs IFpvbmU+IG9uIGFjcGkwCmZkYzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlcj4gcG9ydCAweDNm MC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMwOiBbRklMVEVSXQpmZDA6IDwx NDQwLUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMApzaW8wOiA8MTY1NTBBLWNvbXBhdGli bGUgQ09NIHBvcnQ+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApz aW8wOiB0eXBlIDE2NTUwQQpzaW8wOiBbRklMVEVSXQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJv bGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBL ZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1M T0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnBtdGltZXIwIG9uIGlzYTAKb3JtMDogPElTQSBPcHRp b24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGNjZmZmLDB4ZDAwMDAtMHhkNDdmZiBwbnBpZCBP Uk0wMDAwIG9uIGlzYTAKcHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuCnNjMDogPFN5c3Rl bSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNv bnNvbGVzLCBmbGFncz0weDMwMD4Kc2lvMTogY29uZmlndXJlZCBpcnEgMyBub3QgaW4gYml0bWFw IG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQKdmdhMDogPEdl bmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYg b24gaXNhMAp1bXMwOiA8TG9naXRlY2ggVVNCIFJlY2VpdmVyLCBjbGFzcyAwLzAsIHJldiAxLjEw LzE1LjAwLCBhZGRyIDI+IG9uIHVodWIwCnVtczA6IDggYnV0dG9ucyBhbmQgWiBkaXIuClRpbWVj b3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKZmlyZXdpcmUwOiAxIG5vZGVzLCBtYXhob3Ag PD0gMCwgY2FibGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCAobWUpCmZp cmV3aXJlMTogMSBub2RlcywgbWF4aG9wIDw9IDAsIGNhYmxlIElSTSA9IDAgKG1lKQpmaXJld2ly ZTE6IGJ1cyBtYW5hZ2VyIDAgKG1lKQptZDA6IFByZWxvYWRlZCBpbWFnZSA8L2Jvb3QvbWZzcm9v dD4gNDQyMzY4MCBieXRlcyBhdCAweGMwZDFiNTU4CmFjZDA6IERWRFIgPEhMLURULVNUIERWRFJB TSBHU0EtNDEyMEIvQTExNT4gYXQgYXRhMC1tYXN0ZXIgVURNQTMzCmFjZDE6IERWRFJPTSA8SEwt RFQtU1REVkQtUk9NIEdEUjgxNjNCLzBMMjM+IGF0IGF0YTAtc2xhdmUgVURNQTMzCmFkNDogNDc2 OTQwTUIgPFNlYWdhdGUgU1QzNTAwNjMwQVMgMy5BQUs+IGF0IGF0YTItbWFzdGVyIFNBVEExNTAK YWQ2OiAyODYxODhNQiA8TWF4dG9yIDZMMzAwUzAgQkFDRTFHMjA+IGF0IGF0YTMtbWFzdGVyIFNB VEExNTAKYWQxNjogNzYzMTlNQiA8U2VhZ2F0ZSBTVDM4MDAxMUEgMy4wNj4gYXQgYXRhOC1tYXN0 ZXIgVURNQTEwMAphZDE4OiA3NjMxOU1CIDxTZWFnYXRlIFNUMzgwMDExQSAzLjA2PiBhdCBhdGE5 LW1hc3RlciBVRE1BMTAwCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhY2QxIGlzIGlz bzk2NjAvRnJlZUJTRF9JbnN0YWxsLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ0 czUgaXMgbXNkb3Nmcy8gLgpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKV0FSTklORzogV0lUTkVT UyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClRyeWluZyB0byBt b3VudCByb290IGZyb20gdWZzOi9kZXYvbWQwCkdFT01fTEFCRUw6IExhYmVsIG1zZG9zZnMvICBy ZW1vdmVkLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ0czUgaXMgbXNkb3Nmcy8g LgpnX3Zmc19kb25lKCk6YWNkMFtSRUFEKG9mZnNldD0zMjc2OCwgbGVuZ3RoPTIwNDgpXWVycm9y ID0gNQpnX3Zmc19kb25lKCk6YWNkMFtSRUFEKG9mZnNldD0zMjc2OCwgbGVuZ3RoPTIwNDgpXWVy cm9yID0gNQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2bmxy dScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJv Y2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykg Zm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4KU3luY2luZyBkaXNrcywgdm5v ZGVzIHJlbWFpbmluZy4uLjIgMCAxIDAgMCAwIGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgpVcHRp bWU6IDMwbTQwcwpDb3B5cmlnaHQgKGMpIDE5OTItMjAwNyBUaGUgRnJlZUJTRCBQcm9qZWN0LgpD b3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5 OTIsIDE5OTMsIDE5OTQKCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3Ju aWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFy ayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNEIDcuMC1DVVJSRU5ULTIwMDcwOCAj MDogRnJpIEF1ZyAxNyAwNzo0NzoxOCBVVEMgMjAwNwogICAgcm9vdEBsb2dhbi5jc2UuYnVmZmFs by5lZHU6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQwpXQVJOSU5HOiBXSVRORVNTIG9wdGlv biBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KVGltZWNvdW50ZXIgImk4MjU0 IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBBTUQgQXRobG9uKHRtKSA2NCBY MiBEdWFsIENvcmUgUHJvY2Vzc29yIDQ2MDArICgyNDEwLjk5LU1IeiA2ODYtY2xhc3MgQ1BVKQog IE9yaWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4NDBmYjIgIFN0ZXBwaW5nID0gMgogIEZl YXR1cmVzPTB4MTc4YmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElD LFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxNTVgsRlhTUixTU0UsU1NF MixIVFQ+CiAgRmVhdHVyZXMyPTB4MjAwMTxTU0UzLENYMTY+CiAgQU1EIEZlYXR1cmVzPTB4ZWE1 MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLEZGWFNSLFJEVFNDUCxMTSwzRE5vdyErLDNETm93IT4KICBB TUQgRmVhdHVyZXMyPTB4MWY8TEFIRixDTVAsU1ZNLEV4dEFQSUMsQ1I4PgogIENvcmVzIHBlciBw YWNrYWdlOiAyCnJlYWwgbWVtb3J5ICA9IDIxNDYzMDQwMDAgKDIwNDYgTUIpCmF2YWlsIG1lbW9y eSA9IDIwOTA3NjYzMzYgKDE5OTMgTUIpCkFDUEkgQVBJQyBUYWJsZTogPE52aWRpYSBBU1VTQUNQ ST4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCiBj cHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQppb2FwaWMwOiBD aGFuZ2luZyBBUElDIElEIHRvIDIKaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBt b3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYXRoX2hhbDogMC45LjIwLjMgKEFSNTIxMCwgQVI1 MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1MTEyLCBSRjI0MTMsIFJGNTQxMykKYWNwaTA6IDxOdmlk aWEgQVNVU0FDUEk+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaV9ocGV0MDog PEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZmZmMDAwLTB4ZmVmZmYzZmYg b24gYWNwaTAKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAyNTAwMDAwMCBIeiBxdWFsaXR5 IDkwMAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHJlc2VydmF0aW9uIG9mIGZl ZmZmMDAwLCAxMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgz KSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgN2ZkZTAwMDAgKDMpIGZhaWxl ZApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEw MDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHgxMDA4 LTB4MTAwYiBvbiBhY3BpMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCnBvd2Vybm93MDogPFBv d2VyTm93ISBLOD4gb24gY3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCnBvd2Vybm93MTog PFBvd2VyTm93ISBLOD4gb24gY3B1MQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFj cGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNw aTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBk ZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2 aWNlIDAuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmlj ZSAwLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2Ug MC4zIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAu NCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAwLjUg KG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC42IChu byBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAuNyAobm8g ZHJpdmVyIGF0dGFjaGVkKQpwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA0 LjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQp2Z2FwY2kwOiA8VkdBLWNv bXBhdGlibGUgZGlzcGxheT4gcG9ydCAweDhjMDAtMHg4YzdmIG1lbSAweGZhMDAwMDAwLTB4ZmFm ZmZmZmYsMHhjMDAwMDAwMC0weGRmZmZmZmZmLDB4ZjgwMDAwMDAtMHhmOWZmZmZmZiBpcnEgMTYg YXQgZGV2aWNlIDAuMCBvbiBwY2kxCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDguMCAo bm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgOS4w IG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1 cz4gYXQgZGV2aWNlIDkuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8bWVtb3J5LCBSQU0+ IGF0IGRldmljZSA5LjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKb2hjaTA6IDxPSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZmUwMmYwMDAtMHhmZTAyZmZmZiBpcnEgMjEgYXQgZGV2 aWNlIDEwLjAgb24gcGNpMApvaGNpMDogW0dJQU5ULUxPQ0tFRF0Kb2hjaTA6IFtJVEhSRUFEXQp1 c2IwOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydAp1c2IwOiBTTU0gZG9lcyBub3Qg cmVzcG9uZCwgcmVzZXR0aW5nCnVzYjA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g b24gb2hjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDogPG5WaWRpYSBPSENJIHJvb3Qg aHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMAp1aHViMDogMTAg cG9ydHMgd2l0aCAxMCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPEVIQ0kgKGdlbmVy aWMpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZmUwMmUwMDAtMHhmZTAyZTBmZiBpcnEgMjIg YXQgZGV2aWNlIDEwLjEgb24gcGNpMAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KZWhjaTA6IFtJVEhS RUFEXQp1c2IxOiBFSENJIHZlcnNpb24gMS4wCnVzYjE6IGNvbXBhbmlvbiBjb250cm9sbGVyLCAx MCBwb3J0cyBlYWNoOiB1c2IwCnVzYjE6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xs ZXI+IG9uIGVoY2kwCnVzYjE6IFVTQiByZXZpc2lvbiAyLjAKdWh1YjE6IDxuVmlkaWEgRUhDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjEKdWh1YjE6 IDEwIHBvcnRzIHdpdGggMTAgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWdlbjA6IDx2ZW5kb3Ig MHgwYmRhIFJUTDgxODdfV2lyZWxlc3MsIGNsYXNzIDAvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAy PiBvbiB1aHViMQphdGFwY2kwOiA8blZpZGlhIG5Gb3JjZSBNQ1A1NSBVRE1BMTMzIGNvbnRyb2xs ZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmNDAwLTB4ZjQw ZiBhdCBkZXZpY2UgMTIuMCBvbiBwY2kwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kw CmF0YTA6IFtJVEhSRUFEXQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGExOiBb SVRIUkVBRF0KYXRhcGNpMTogPG5WaWRpYSBuRm9yY2UgTUNQNTUgU0FUQTMwMCBjb250cm9sbGVy PiBwb3J0IDB4OWYwLTB4OWY3LDB4YmYwLTB4YmYzLDB4OTcwLTB4OTc3LDB4YjcwLTB4YjczLDB4 ZTAwMC0weGUwMGYgbWVtIDB4ZmUwMmQwMDAtMHhmZTAyZGZmZiBpcnEgMjMgYXQgZGV2aWNlIDEz LjAgb24gcGNpMAphdGFwY2kxOiBbSVRIUkVBRF0KYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0 YXBjaTEKYXRhMjogW0lUSFJFQURdCmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCmF0 YTM6IFtJVEhSRUFEXQphdGFwY2kyOiA8blZpZGlhIG5Gb3JjZSBNQ1A1NSBTQVRBMzAwIGNvbnRy b2xsZXI+IHBvcnQgMHg5ZTAtMHg5ZTcsMHhiZTAtMHhiZTMsMHg5NjAtMHg5NjcsMHhiNjAtMHhi NjMsMHhjYzAwLTB4Y2MwZiBtZW0gMHhmZTAyYzAwMC0weGZlMDJjZmZmIGlycSAyMCBhdCBkZXZp Y2UgMTMuMSBvbiBwY2kwCmF0YXBjaTI6IFtJVEhSRUFEXQphdGE0OiA8QVRBIGNoYW5uZWwgMD4g b24gYXRhcGNpMgphdGE0OiBbSVRIUkVBRF0KYXRhNTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBj aTIKYXRhNTogW0lUSFJFQURdCmF0YXBjaTM6IDxuVmlkaWEgbkZvcmNlIE1DUDU1IFNBVEEzMDAg Y29udHJvbGxlcj4gcG9ydCAweGM4MDAtMHhjODA3LDB4YzQwMC0weGM0MDMsMHhjMDAwLTB4YzAw NywweGJjMDAtMHhiYzAzLDB4YjgwMC0weGI4MGYgbWVtIDB4ZmUwMmIwMDAtMHhmZTAyYmZmZiBp cnEgMjEgYXQgZGV2aWNlIDEzLjIgb24gcGNpMAphdGFwY2kzOiBbSVRIUkVBRF0KYXRhNjogPEFU QSBjaGFubmVsIDA+IG9uIGF0YXBjaTMKYXRhNjogW0lUSFJFQURdCmF0YTc6IDxBVEEgY2hhbm5l bCAxPiBvbiBhdGFwY2kzCmF0YTc6IFtJVEhSRUFEXQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAxNC4wIG9uIHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIK YXRhcGNpNDogPEhpZ2hQb2ludCBIUFQzNzAgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4YWMw MC0weGFjMDcsMHhhODAwLTB4YTgwMywweGE0MDAtMHhhNDA3LDB4YTAwMC0weGEwMDMsMHg5YzAw LTB4OWNmZiBpcnEgMTcgYXQgZGV2aWNlIDcuMCBvbiBwY2kyCmF0YXBjaTQ6IFtJVEhSRUFEXQph dGE4OiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpNAphdGE4OiBbSVRIUkVBRF0KYXRhOTogPEFU QSBjaGFubmVsIDE+IG9uIGF0YXBjaTQKYXRhOTogW0lUSFJFQURdCnBjaTI6IDxtdWx0aW1lZGlh LCBhdWRpbz4gYXQgZGV2aWNlIDguMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kyOiA8aW5wdXQg ZGV2aWNlPiBhdCBkZXZpY2UgOC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCmZ3b2hjaTA6IDwxMzk0 IE9wZW4gSG9zdCBDb250cm9sbGVyIEludGVyZmFjZT4gbWVtIDB4ZmRmZmYwMDAtMHhmZGZmZjdm ZiwweGZkZmY4MDAwLTB4ZmRmZmJmZmYgaXJxIDE5IGF0IGRldmljZSA4LjIgb24gcGNpMgpmd29o Y2kwOiBbRklMVEVSXQpmd29oY2kwOiBPSENJIHZlcnNpb24gMS4xMCAoUk9NPTApCmZ3b2hjaTA6 IE5vLiBvZiBJc29jaHJvbm91cyBjaGFubmVscyBpcyA0Lgpmd29oY2kwOiBFVUk2NCAwMDowMjoz YzowMTowMTowNTo0Yjo3MQpmd29oY2kwOiBQaHkgMTM5NGEgYXZhaWxhYmxlIFM0MDAsIDIgcG9y dHMuCmZ3b2hjaTA6IExpbmsgUzQwMCwgbWF4X3JlYyAyMDQ4IGJ5dGVzLgpmaXJld2lyZTA6IDxJ RUVFMTM5NChGaXJlV2lyZSkgYnVzPiBvbiBmd29oY2kwCmZ3ZTA6IDxFdGhlcm5ldCBvdmVyIEZp cmVXaXJlPiBvbiBmaXJld2lyZTAKaWZfZndlMDogRmFrZSBFdGhlcm5ldCBhZGRyZXNzOiAwMjow MjozYzowNTo0Yjo3MQpmd2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMjowMjozYzowNTo0Yjo3MQpm d2lwMDogPElQIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApmd2lwMDogRmlyZXdpcmUgYWRk cmVzczogMDA6MDI6M2M6MDE6MDE6MDU6NGI6NzEgQCAweGZmZmUwMDAwMDAwMCwgUzQwMCwgbWF4 cmVjIDIwNDgKc2JwMDogPFNCUC0yL1NDU0kgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwCmRj b25zX2Nyb20wOiA8ZGNvbnMgY29uZmlndXJhdGlvbiBST00+IG9uIGZpcmV3aXJlMApkY29uc19j cm9tMDogYnVzX2FkZHIgMHg3ZDg3NDAwMApmd29oY2kwOiBJbml0aWF0ZSBidXMgcmVzZXQKZndv aGNpMDogQlVTIHJlc2V0CmZ3b2hjaTA6IG5vZGVfaWQ9MHhjODAwZmZjMCwgZ2VuPTEsIENZQ0xF TUFTVEVSIG1vZGUKZndvaGNpMTogPFRleGFzIEluc3RydW1lbnRzIFRTQjQzQUIyMi9BPiBtZW0g MHhmZGZmZTAwMC0weGZkZmZlN2ZmLDB4ZmRmZjQwMDAtMHhmZGZmN2ZmZiBpcnEgMTYgYXQgZGV2 aWNlIDExLjAgb24gcGNpMgpmd29oY2kxOiBbRklMVEVSXQpmd29oY2kxOiBPSENJIHZlcnNpb24g MS4xMCAoUk9NPTEpCmZ3b2hjaTE6IE5vLiBvZiBJc29jaHJvbm91cyBjaGFubmVscyBpcyA0Lgpm d29oY2kxOiBFVUk2NCAwMDoxMTpkODowMDowMTo0Nzo0NDpkOQpmd29oY2kxOiBQaHkgMTM5NGEg YXZhaWxhYmxlIFM0MDAsIDIgcG9ydHMuCmZ3b2hjaTE6IExpbmsgUzQwMCwgbWF4X3JlYyAyMDQ4 IGJ5dGVzLgpmaXJld2lyZTE6IDxJRUVFMTM5NChGaXJlV2lyZSkgYnVzPiBvbiBmd29oY2kxCmZ3 ZTE6IDxFdGhlcm5ldCBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTEKaWZfZndlMTogRmFrZSBF dGhlcm5ldCBhZGRyZXNzOiAwMjoxMTpkODo0Nzo0NDpkOQpmd2UxOiBFdGhlcm5ldCBhZGRyZXNz OiAwMjoxMTpkODo0Nzo0NDpkOQpmd2lwMTogPElQIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJl MQpmd2lwMTogRmlyZXdpcmUgYWRkcmVzczogMDA6MTE6ZDg6MDA6MDE6NDc6NDQ6ZDkgQCAweGZm ZmUwMDAwMDAwMCwgUzQwMCwgbWF4cmVjIDIwNDgKc2JwMTogPFNCUC0yL1NDU0kgb3ZlciBGaXJl V2lyZT4gb24gZmlyZXdpcmUxCmRjb25zX2Nyb20xOiA8ZGNvbnMgY29uZmlndXJhdGlvbiBST00+ IG9uIGZpcmV3aXJlMQpkY29uc19jcm9tMTogYnVzX2FkZHIgMHg3ZDg3NDAwMApkY29uc19jcm9t MTogZGNvbnNfcGFkZHIgaXMgYWxyZWFkeSBzZXQKZndvaGNpMTogSW5pdGlhdGUgYnVzIHJlc2V0 CmZ3b2hjaTE6IEJVUyByZXNldApmd29oY2kxOiBub2RlX2lkPTB4YzgwMGZmYzAsIGdlbj0xLCBD WUNMRU1BU1RFUiBtb2RlCm5mZTA6IDxOVklESUEgbkZvcmNlIE1DUDU1IE5ldHdvcmtpbmcgQWRh cHRlcj4gcG9ydCAweGI0MDAtMHhiNDA3IG1lbSAweGZlMDJhMDAwLTB4ZmUwMmFmZmYsMHhmZTAy OTAwMC0weGZlMDI5MGZmLDB4ZmUwMjgwMDAtMHhmZTAyODAwZiBpcnEgMjIgYXQgZGV2aWNlIDE2 LjAgb24gcGNpMAptaWlidXMwOiA8TUlJIGJ1cz4gb24gbmZlMAplMTAwMHBoeTA6IDxNYXJ2ZWxs IDg4RTExMTYgR2lnYWJpdCBQSFk+IFBIWSAxIG9uIG1paWJ1czAKZTEwMDBwaHkwOiAgMTBiYXNl VCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VUWC1GRFgs IGF1dG8KbmZlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MWI6ZmM6Mzk6ZmI6MjMKbmZlMDogW0ZJ TFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDog W0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KcGNp YjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjIuMCBvbiBwY2kwCnBjaTM6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIzCmF0YXBjaTU6IDxTaUkgMzEzMiBTQVRBMzAwIGNvbnRyb2xs ZXI+IHBvcnQgMHg3YzAwLTB4N2M3ZiBtZW0gMHhmZGVmZjAwMC0weGZkZWZmMDdmLDB4ZmRlZjgw MDAtMHhmZGVmYmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kzCmF0YXBjaTU6IFtJVEhS RUFEXQphdGExMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTUKYXRhMTA6IFtJVEhSRUFEXQph dGExMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTUKYXRhMTE6IFtJVEhSRUFEXQphY3BpX3R6 MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVy PiBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IFtGSUxU RVJdCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCnNpbzA6IDwxNjU1 MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEw IG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1NTBBCnNpbzA6IFtGSUxURVJdCmF0a2JkYzA6IDxLZXli b2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0 a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2Jk MDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVBRF0KcG10aW1lcjAgb24gaXNhMApvcm0w OiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4Y2NmZmYsMHhkMDAwMC0weGQ0 N2ZmIHBucGlkIE9STTAwMDAgb24gaXNhMApwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4K c2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5v dCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxl ZAp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAw MDAtMHhiZmZmZiBvbiBpc2EwCnVtczA6IDxMb2dpdGVjaCBVU0IgUmVjZWl2ZXIsIGNsYXNzIDAv MCwgcmV2IDEuMTAvMTUuMDAsIGFkZHIgMj4gb24gdWh1YjAKdW1zMDogOCBidXR0b25zIGFuZCBa IGRpci4KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpmaXJld2lyZTA6IDEgbm9k ZXMsIG1heGhvcCA8PSAwLCBjYWJsZSBJUk0gPSAwIChtZSkKZmlyZXdpcmUwOiBidXMgbWFuYWdl ciAwIChtZSkKZmlyZXdpcmUxOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwgY2FibGUgSVJNID0gMCAo bWUpCmZpcmV3aXJlMTogYnVzIG1hbmFnZXIgMCAobWUpCmFjZDA6IERWRFIgPEhMLURULVNUIERW RFJBTSBHU0EtNDEyMEIvQTExNT4gYXQgYXRhMC1tYXN0ZXIgVURNQTMzCmFjZDE6IERWRFJPTSA8 SEwtRFQtU1REVkQtUk9NIEdEUjgxNjNCLzBMMjM+IGF0IGF0YTAtc2xhdmUgVURNQTMzCmFkNDog NDc2OTQwTUIgPFNlYWdhdGUgU1QzNTAwNjMwQVMgMy5BQUs+IGF0IGF0YTItbWFzdGVyIFNBVEEx NTAKYWQ2OiAyODYxODhNQiA8TWF4dG9yIDZMMzAwUzAgQkFDRTFHMjA+IGF0IGF0YTMtbWFzdGVy IFNBVEExNTAKYWQxNjogNzYzMTlNQiA8U2VhZ2F0ZSBTVDM4MDAxMUEgMy4wNj4gYXQgYXRhOC1t YXN0ZXIgVURNQTEwMAphZDE4OiA3NjMxOU1CIDxTZWFnYXRlIFNUMzgwMDExQSAzLjA2PiBhdCBh dGE5LW1hc3RlciBVRE1BMTAwCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDRzNSBp cyBtc2Rvc2ZzLyAuClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpXQVJOSU5HOiBXSVRORVNTIG9w dGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KVHJ5aW5nIHRvIG1vdW50 IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDRzM2EKbmZlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQ Cm5mZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dOCm5mZTA6IGxpbmsgc3RhdGUgY2hhbmdl ZCB0byBVUApuZmUwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgpuZmUwOiBsaW5rIHN0YXRl IGNoYW5nZWQgdG8gVVAKbmZlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KbmZlMDogbGlu ayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmdfdmZzX2RvbmUoKTphY2QwW1JFQUQob2Zmc2V0PTMyNzY4 LCBsZW5ndGg9MjA0OCldZXJyb3IgPSA1CmdfdmZzX2RvbmUoKTphY2QwW1JFQUQob2Zmc2V0PTMy NzY4LCBsZW5ndGg9MjA0OCldZXJyb3IgPSA1CmdfdmZzX2RvbmUoKTphY2QwW1JFQUQob2Zmc2V0 PTMyNzY4LCBsZW5ndGg9MjA0OCldZXJyb3IgPSA1CmdfdmZzX2RvbmUoKTphY2QwW1JFQUQob2Zm c2V0PTMyNzY4LCBsZW5ndGg9MjA0OCldZXJyb3IgPSA1CmdfdmZzX2RvbmUoKTphY2QwW1JFQUQo b2Zmc2V0PTMyNzY4LCBsZW5ndGg9MjA0OCldZXJyb3IgPSA1CmdfdmZzX2RvbmUoKTphY2QwW1JF QUQob2Zmc2V0PTMyNzY4LCBsZW5ndGg9MjA0OCldZXJyb3IgPSA1CmdfdmZzX2RvbmUoKTphY2Qw W1JFQUQob2Zmc2V0PTMyNzY4LCBsZW5ndGg9MjA0OCldZXJyb3IgPSA1CmdfdmZzX2RvbmUoKTph Y2QwW1JFQUQob2Zmc2V0PTMyNzY4LCBsZW5ndGg9MjA0OCldZXJyb3IgPSA1CkdFT01fTEFCRUw6 IExhYmVsIGZvciBwcm92aWRlciBhY2QxdDAxIGlzIGlzbzk2NjAvRnJlZUJTRF9JbnN0YWxsLgpX YWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2bmxydScgdG8gc3Rv cC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVm ZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3Rl bSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4KU3luY2luZyBkaXNrcywgdm5vZGVzIHJlbWFp bmluZy4uLjMgMSAwIDAgMCBkb25lCkFsbCBidWZmZXJzIHN5bmNlZC4KVXB0aW1lOiAxaDIxbTQw cwpDb3B5cmlnaHQgKGMpIDE5OTItMjAwNyBUaGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQg KGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMs IDE5OTQKCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBUaGUg RnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNEIDcuMC1DVVJSRU5ULTIwMDcwOCAjMzogRnJpIEF1 ZyAzMSAyMTozMzoyMCBCUlQgMjAwNwogICAgcm9vdEBleHhvZHVzLmZlZGF5a2luLmhlcmU6L3Vz ci9zcmMvc3lzL2kzODYvY29tcGlsZS9MSU9VWApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5j eSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IEFNRCBBdGhsb24odG0pIDY0IFgyIER1YWwgQ29y ZSBQcm9jZXNzb3IgNDYwMCsgKDI0MTAuOTktTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0g IkF1dGhlbnRpY0FNRCIgIElkID0gMHg0MGZiMiAgU3RlcHBpbmcgPSAyCiAgRmVhdHVyZXM9MHgx NzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIs UEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4KICBG ZWF0dXJlczI9MHgyMDAxPFNTRTMsQ1gxNj4KICBBTUQgRmVhdHVyZXM9MHhlYTUwMDgwMDxTWVND QUxMLE5YLE1NWCssRkZYU1IsUkRUU0NQLExNLDNETm93ISssM0ROb3chPgogIEFNRCBGZWF0dXJl czI9MHgxZjxMQUhGLENNUCxTVk0sRXh0QVBJQyxDUjg+CiAgQ29yZXMgcGVyIHBhY2thZ2U6IDIK cmVhbCBtZW1vcnkgID0gMjE0NjMwNDAwMCAoMjA0NiBNQikKYXZhaWwgbWVtb3J5ID0gMjA5NTAz ODQ2NCAoMTk5NyBNQikKQUNQSSBBUElDIFRhYmxlOiA8TnZpZGlhIEFTVVNBQ1BJPgpGcmVlQlNE L1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMKIGNwdTAgKEJTUCk6 IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxCmlvYXBpYzA6IENoYW5naW5nIEFQ SUMgSUQgdG8gMgppb2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJk CmtiZDEgYXQga2JkbXV4MAphY3BpMDogPE52aWRpYSBBU1VTQUNQST4gb24gbW90aGVyYm9hcmQK YWNwaTA6IFtJVEhSRUFEXQphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+ IGlvbWVtIDB4ZmVmZmYwMDAtMHhmZWZmZjNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBFVCIg ZnJlcXVlbmN5IDI1MDAwMDAwIEh6IHF1YWxpdHkgOTAwCmFjcGkwOiBQb3dlciBCdXR0b24gKGZp eGVkKQphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmVmZmYwMDAsIDEwMDAgKDMpIGZhaWxlZAphY3Bp MDogcmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24g b2YgMTAwMDAwLCA3ZmRlMDAwMCAoMykgZmFpbGVkClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZy ZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1l ciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDEwMDgtMHgxMDBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJ IENQVT4gb24gYWNwaTAKcG93ZXJub3cwOiA8UG93ZXJOb3chIEs4PiBvbiBjcHUwCmNwdTE6IDxB Q1BJIENQVT4gb24gYWNwaTAKcG93ZXJub3cxOiA8UG93ZXJOb3chIEs4PiBvbiBjcHUxCmFjcGlf YnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liMApwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hl ZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQp CnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQpw Y2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAwLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNp MDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC40IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6 IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAuNSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8 bWVtb3J5LCBSQU0+IGF0IGRldmljZSAwLjYgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG1l bW9yeSwgUkFNPiBhdCBkZXZpY2UgMC43IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWIxOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDQuMCBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWIxCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4OGMw MC0weDhjN2YgbWVtIDB4ZmEwMDAwMDAtMHhmYWZmZmZmZiwweGMwMDAwMDAwLTB4ZGZmZmZmZmYs MHhmODAwMDAwMC0weGY5ZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEKcGNpMDog PG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgOC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8 UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSA5LjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24g aXNhYjAKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgOS4xIChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDkuMiAobm8gZHJpdmVyIGF0 dGFjaGVkKQpvaGNpMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmZTAy ZjAwMC0weGZlMDJmZmZmIGlycSAyMSBhdCBkZXZpY2UgMTAuMCBvbiBwY2kwCm9oY2kwOiBbR0lB TlQtTE9DS0VEXQpvaGNpMDogW0lUSFJFQURdCnVzYjA6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2Fj eSBzdXBwb3J0CnVzYjA6IFNNTSBkb2VzIG5vdCByZXNwb25kLCByZXNldHRpbmcKdXNiMDogPE9I Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMAp1c2IwOiBVU0IgcmV2aXNpb24g MS4wCnVodWIwOiA8blZpZGlhIE9IQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4w MCwgYWRkciAxPiBvbiB1c2IwCnVodWIwOiAxMCBwb3J0cyB3aXRoIDEwIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCmVoY2kwOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0g MHhmZTAyZTAwMC0weGZlMDJlMGZmIGlycSAyMiBhdCBkZXZpY2UgMTAuMSBvbiBwY2kwCmVoY2kw OiBbR0lBTlQtTE9DS0VEXQplaGNpMDogW0lUSFJFQURdCnVzYjE6IEVIQ0kgdmVyc2lvbiAxLjAK dXNiMTogY29tcGFuaW9uIGNvbnRyb2xsZXIsIDEwIHBvcnRzIGVhY2g6IHVzYjAKdXNiMTogPEVI Q0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKdXNiMTogVVNCIHJldmlz aW9uIDIuMAp1aHViMTogPG5WaWRpYSBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNiMQp1aHViMTogMTAgcG9ydHMgd2l0aCAxMCByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAp1Z2VuMDogPHZlbmRvciAweDBiZGEgUlRMODE4N19XaXJlbGVzcywgY2xh c3MgMC8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDI+IG9uIHVodWIxCmF0YXBjaTA6IDxuVmlkaWEg bkZvcmNlIE1DUDU1IFVETUExMzMgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiww eDE3MC0weDE3NywweDM3NiwweGY0MDAtMHhmNDBmIGF0IGRldmljZSAxMi4wIG9uIHBjaTAKYXRh MDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhMDogW0lUSFJFQURdCmF0YTE6IDxBVEEg Y2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YTE6IFtJVEhSRUFEXQphdGFwY2kxOiA8blZpZGlhIG5G b3JjZSBNQ1A1NSBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHg5ZjAtMHg5ZjcsMHhiZjAtMHhi ZjMsMHg5NzAtMHg5NzcsMHhiNzAtMHhiNzMsMHhlMDAwLTB4ZTAwZiBtZW0gMHhmZTAyZDAwMC0w eGZlMDJkZmZmIGlycSAyMyBhdCBkZXZpY2UgMTMuMCBvbiBwY2kwCmF0YXBjaTE6IFtJVEhSRUFE XQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGEyOiBbSVRIUkVBRF0KYXRhMzog PEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTEKYXRhMzogW0lUSFJFQURdCmF0YXBjaTI6IDxuVmlk aWEgbkZvcmNlIE1DUDU1IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweDllMC0weDllNywweGJl MC0weGJlMywweDk2MC0weDk2NywweGI2MC0weGI2MywweGNjMDAtMHhjYzBmIG1lbSAweGZlMDJj MDAwLTB4ZmUwMmNmZmYgaXJxIDIwIGF0IGRldmljZSAxMy4xIG9uIHBjaTAKYXRhcGNpMjogW0lU SFJFQURdCmF0YTQ6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kyCmF0YTQ6IFtJVEhSRUFEXQph dGE1OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMgphdGE1OiBbSVRIUkVBRF0KYXRhcGNpMzog PG5WaWRpYSBuRm9yY2UgTUNQNTUgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4YzgwMC0weGM4 MDcsMHhjNDAwLTB4YzQwMywweGMwMDAtMHhjMDA3LDB4YmMwMC0weGJjMDMsMHhiODAwLTB4Yjgw ZiBtZW0gMHhmZTAyYjAwMC0weGZlMDJiZmZmIGlycSAyMSBhdCBkZXZpY2UgMTMuMiBvbiBwY2kw CmF0YXBjaTM6IFtJVEhSRUFEXQphdGE2OiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMwphdGE2 OiBbSVRIUkVBRF0KYXRhNzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTMKYXRhNzogW0lUSFJF QURdCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDE0LjAgb24gcGNpMApw Y2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgphdGFwY2k0OiA8SGlnaFBvaW50IEhQVDM3MCBV RE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHhhYzAwLTB4YWMwNywweGE4MDAtMHhhODAzLDB4YTQw MC0weGE0MDcsMHhhMDAwLTB4YTAwMywweDljMDAtMHg5Y2ZmIGlycSAxNyBhdCBkZXZpY2UgNy4w IG9uIHBjaTIKYXRhcGNpNDogW0lUSFJFQURdCmF0YTg6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFw Y2k0CmF0YTg6IFtJVEhSRUFEXQphdGE5OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpNAphdGE5 OiBbSVRIUkVBRF0KcGNpMjogPG11bHRpbWVkaWEsIGF1ZGlvPiBhdCBkZXZpY2UgOC4wIChubyBk cml2ZXIgYXR0YWNoZWQpCnBjaTI6IDxpbnB1dCBkZXZpY2U+IGF0IGRldmljZSA4LjEgKG5vIGRy aXZlciBhdHRhY2hlZCkKcGNpMjogPHNlcmlhbCBidXMsIEZpcmVXaXJlPiBhdCBkZXZpY2UgOC4y IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTI6IDxzZXJpYWwgYnVzLCBGaXJlV2lyZT4gYXQgZGV2 aWNlIDExLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKbmZlMDogPE5WSURJQSBuRm9yY2UgTUNQNTUg TmV0d29ya2luZyBBZGFwdGVyPiBwb3J0IDB4YjQwMC0weGI0MDcgbWVtIDB4ZmUwMmEwMDAtMHhm ZTAyYWZmZiwweGZlMDI5MDAwLTB4ZmUwMjkwZmYsMHhmZTAyODAwMC0weGZlMDI4MDBmIGlycSAy MiBhdCBkZXZpY2UgMTYuMCBvbiBwY2kwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBuZmUwCmUxMDAw cGh5MDogPE1hcnZlbGwgODhFMTExNiBHaWdhYml0IFBIWT4gUEhZIDEgb24gbWlpYnVzMAplMTAw MHBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAx MDAwYmFzZVRYLUZEWCwgYXV0bwpuZmUwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxYjpmYzozOTpm YjoyMwpuZmUwOiBbRklMVEVSXQpuZmUwOiBbRklMVEVSXQpuZmUwOiBbRklMVEVSXQpuZmUwOiBb RklMVEVSXQpuZmUwOiBbRklMVEVSXQpuZmUwOiBbRklMVEVSXQpuZmUwOiBbRklMVEVSXQpuZmUw OiBbRklMVEVSXQpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyMi4wIG9u IHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKYXRhcGNpNTogPFNpSSAzMTMyIFNB VEEzMDAgY29udHJvbGxlcj4gcG9ydCAweDdjMDAtMHg3YzdmIG1lbSAweGZkZWZmMDAwLTB4ZmRl ZmYwN2YsMHhmZGVmODAwMC0weGZkZWZiZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTMK YXRhcGNpNTogW0lUSFJFQURdCmF0YTEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpNQphdGEx MDogW0lUSFJFQURdCmF0YTExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpNQphdGExMTogW0lU SFJFQURdCmFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMApmZGMwOiA8ZmxvcHB5IGRy aXZlIGNvbnRyb2xsZXI+IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNw aTAKZmRjMDogW0ZJTFRFUl0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZl IDAKc2lvMDogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4LTB4M2ZmIGly cSA0IGZsYWdzIDB4MTAgb24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEKc2lvMDogW0ZJTFRFUl0K YXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJx IDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBh dCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwbXRpbWVy MCBvbiBpc2EwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjY2Zm ZiwweGQwMDAwLTB4ZDQ3ZmYgcG5waWQgT1JNMDAwMCBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25z b2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVz LCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNk ZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApzaW8xOiBjb25maWd1cmVkIGlycSAzIG5v dCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxl ZAp1bXMwOiA8TG9naXRlY2ggVVNCIFJlY2VpdmVyLCBjbGFzcyAwLzAsIHJldiAxLjEwLzE1LjAw LCBhZGRyIDI+IG9uIHVodWIwCnVtczA6IDggYnV0dG9ucyBhbmQgWiBkaXIuClRpbWVjb3VudGVy cyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKYWNkMDogRFZEUiA8SEwtRFQtU1QgRFZEUkFNIEdTQS00 MTIwQi9BMTE1PiBhdCBhdGEwLW1hc3RlciBVRE1BMzMKYWNkMTogRFZEUk9NIDxITC1EVC1TVERW RC1ST00gR0RSODE2M0IvMEwyMz4gYXQgYXRhMC1zbGF2ZSBVRE1BMzMKYWQ0OiA0NzY5NDBNQiA8 U2VhZ2F0ZSBTVDM1MDA2MzBBUyAzLkFBSz4gYXQgYXRhMi1tYXN0ZXIgU0FUQTE1MAphZDY6IDI4 NjE4OE1CIDxNYXh0b3IgNkwzMDBTMCBCQUNFMUcyMD4gYXQgYXRhMy1tYXN0ZXIgU0FUQTE1MAph ZDE2OiA3NjMxOU1CIDxTZWFnYXRlIFNUMzgwMDExQSAzLjA2PiBhdCBhdGE4LW1hc3RlciBVRE1B MTAwCmFkMTg6IDc2MzE5TUIgPFNlYWdhdGUgU1QzODAwMTFBIDMuMDY+IGF0IGF0YTktbWFzdGVy IFVETUExMDAKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhCkdFT01fTEFCRUw6IExhYmVsIGZvciBw cm92aWRlciBhZDRzNSBpcyBtc2Rvc2ZzLyAuClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZz Oi9kZXYvYWQ0czNhCm5mZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAo= ------=_Part_10924_26135791.1188583134351 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pciconf.txt"; filename="pciconf.txt"; filename="pciconf.txt"; filename="pciconf.txt"; filename="pciconf.txt" X-Attachment-Id: f_f60n3lkv bm9uZTBAcGNpMDowOjA6CWNsYXNzPTB4MDUwMDAwIGNhcmQ9MHgwMmY0MTBkZSBjaGlwPTB4MDJm NDEwZGUgcmV2PTB4YTIgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnTnZpZGlhIENvcnAnCiAg ICBkZXZpY2UgICAgID0gJ0M1MSBIb3N0IEJyaWRnZScKICAgIGNsYXNzICAgICAgPSBtZW1vcnkK ICAgIHN1YmNsYXNzICAgPSBSQU0Kbm9uZTFAcGNpMDowOjE6CWNsYXNzPTB4MDUwMDAwIGNhcmQ9 MHgwMmZhMTBkZSBjaGlwPTB4MDJmYTEwZGUgcmV2PTB4YTIgaGRyPTB4MDAKICAgIHZlbmRvciAg ICAgPSAnTnZpZGlhIENvcnAnCiAgICBkZXZpY2UgICAgID0gJ0M1MSBNZW1vcnkgQ29udHJvbGxl ciAwJwogICAgY2xhc3MgICAgICA9IG1lbW9yeQogICAgc3ViY2xhc3MgICA9IFJBTQpub25lMkBw Y2kwOjA6MjoJY2xhc3M9MHgwNTAwMDAgY2FyZD0weDAyZmUxMGRlIGNoaXA9MHgwMmZlMTBkZSBy ZXY9MHhhMiBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdOdmlkaWEgQ29ycCcKICAgIGRldmlj ZSAgICAgPSAnQzUxIE1lbW9yeSBDb250cm9sbGVyIDEnCiAgICBjbGFzcyAgICAgID0gbWVtb3J5 CiAgICBzdWJjbGFzcyAgID0gUkFNCm5vbmUzQHBjaTA6MDozOgljbGFzcz0weDA1MDAwMCBjYXJk PTB4MDJmODEwZGUgY2hpcD0weDAyZjgxMGRlIHJldj0weGEyIGhkcj0weDAwCiAgICB2ZW5kb3Ig ICAgID0gJ052aWRpYSBDb3JwJwogICAgZGV2aWNlICAgICA9ICdDNTEgTWVtb3J5IENvbnRyb2xs ZXIgNScKICAgIGNsYXNzICAgICAgPSBtZW1vcnkKICAgIHN1YmNsYXNzICAgPSBSQU0Kbm9uZTRA cGNpMDowOjQ6CWNsYXNzPTB4MDUwMDAwIGNhcmQ9MHgwMmY5MTBkZSBjaGlwPTB4MDJmOTEwZGUg cmV2PTB4YTIgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnTnZpZGlhIENvcnAnCiAgICBkZXZp Y2UgICAgID0gJ0M1MSBNZW1vcnkgQ29udHJvbGxlciA0JwogICAgY2xhc3MgICAgICA9IG1lbW9y eQogICAgc3ViY2xhc3MgICA9IFJBTQpub25lNUBwY2kwOjA6NToJY2xhc3M9MHgwNTAwMDAgY2Fy ZD0weDAyZmYxMGRlIGNoaXA9MHgwMmZmMTBkZSByZXY9MHhhMiBoZHI9MHgwMAogICAgdmVuZG9y ICAgICA9ICdOdmlkaWEgQ29ycCcKICAgIGRldmljZSAgICAgPSAnQzUxIEhvc3QgQnJpZGdlJwog ICAgY2xhc3MgICAgICA9IG1lbW9yeQogICAgc3ViY2xhc3MgICA9IFJBTQpub25lNkBwY2kwOjA6 NjoJY2xhc3M9MHgwNTAwMDAgY2FyZD0weDAyN2YxMGRlIGNoaXA9MHgwMjdmMTBkZSByZXY9MHhh MiBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdOdmlkaWEgQ29ycCcKICAgIGRldmljZSAgICAg PSAnQzUxIE1lbW9yeSBDb250cm9sbGVyIDMnCiAgICBjbGFzcyAgICAgID0gbWVtb3J5CiAgICBz dWJjbGFzcyAgID0gUkFNCm5vbmU3QHBjaTA6MDo3OgljbGFzcz0weDA1MDAwMCBjYXJkPTB4MDI3 ZTEwZGUgY2hpcD0weDAyN2UxMGRlIHJldj0weGEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0g J052aWRpYSBDb3JwJwogICAgZGV2aWNlICAgICA9ICdDNTEgTWVtb3J5IENvbnRyb2xsZXIgMicK ICAgIGNsYXNzICAgICAgPSBtZW1vcnkKICAgIHN1YmNsYXNzICAgPSBSQU0KcGNpYjFAcGNpMDo0 OjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMTBkZSBjaGlwPTB4MDJmYjEwZGUgcmV2PTB4 YTEgaGRyPTB4MDEKICAgIHZlbmRvciAgICAgPSAnTnZpZGlhIENvcnAnCiAgICBkZXZpY2UgICAg ID0gJ0M1MSBQQ0kgRXhwcmVzcyBCcmlkZ2UnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBz dWJjbGFzcyAgID0gUENJLVBDSQpub25lOEBwY2kwOjg6MDoJY2xhc3M9MHgwNTAwMDAgY2FyZD0w eGNiODQxMDQzIGNoaXA9MHgwMzY5MTBkZSByZXY9MHhhMSBoZHI9MHgwMAogICAgdmVuZG9yICAg ICA9ICdOdmlkaWEgQ29ycCcKICAgIGRldmljZSAgICAgPSAnTUNQNTUgTWVtb3J5IENvbnRyb2xs ZXInCiAgICBjbGFzcyAgICAgID0gbWVtb3J5CiAgICBzdWJjbGFzcyAgID0gUkFNCmlzYWIwQHBj aTA6OTowOgljbGFzcz0weDA2MDEwMCBjYXJkPTB4Y2I4NDEwNDMgY2hpcD0weDAzNjAxMGRlIHJl dj0weGEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ052aWRpYSBDb3JwJwogICAgZGV2aWNl ICAgICA9ICdNQ1A1NSBMUEMgQnJpZGdlJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3Vi Y2xhc3MgICA9IFBDSS1JU0EKbm9uZTlAcGNpMDo5OjE6CWNsYXNzPTB4MGMwNTAwIGNhcmQ9MHhj Yjg0MTA0MyBjaGlwPTB4MDM2ODEwZGUgcmV2PTB4YTIgaGRyPTB4MDAKICAgIHZlbmRvciAgICAg PSAnTnZpZGlhIENvcnAnCiAgICBkZXZpY2UgICAgID0gJ01DUDU1IFNNQnVzJwogICAgY2xhc3Mg ICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBTTUJ1cwpub25lMTBAcGNpMDo5OjI6 CWNsYXNzPTB4MDUwMDAwIGNhcmQ9MHhjYjg0MTA0MyBjaGlwPTB4MDM2YTEwZGUgcmV2PTB4YTIg aGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnTnZpZGlhIENvcnAnCiAgICBkZXZpY2UgICAgID0g J01DUDU1IE1lbW9yeSBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IG1lbW9yeQogICAgc3Vi Y2xhc3MgICA9IFJBTQpvaGNpMEBwY2kwOjEwOjA6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9MHhjYjg0 MTA0MyBjaGlwPTB4MDM2YzEwZGUgcmV2PTB4YTEgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAn TnZpZGlhIENvcnAnCiAgICBkZXZpY2UgICAgID0gJ01DUDU1IFVTQiBDb250cm9sbGVyJwogICAg Y2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKZWhjaTBAcGNpMDox MDoxOgljbGFzcz0weDBjMDMyMCBjYXJkPTB4Y2I4NDEwNDMgY2hpcD0weDAzNmQxMGRlIHJldj0w eGEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ052aWRpYSBDb3JwJwogICAgZGV2aWNlICAg ICA9ICdNQ1A1NSBVU0IgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAg ICBzdWJjbGFzcyAgID0gVVNCCmF0YXBjaTBAcGNpMDoxMjowOgljbGFzcz0weDAxMDE4YSBjYXJk PTB4Y2I4NDEwNDMgY2hpcD0weDAzNmUxMGRlIHJldj0weGExIGhkcj0weDAwCiAgICB2ZW5kb3Ig ICAgID0gJ052aWRpYSBDb3JwJwogICAgZGV2aWNlICAgICA9ICdNQ1A1NSBJREUnCiAgICBjbGFz cyAgICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gQVRBCmF0YXBjaTFAcGNpMDox MzowOgljbGFzcz0weDAxMDE4NSBjYXJkPTB4Y2I4NDEwNDMgY2hpcD0weDAzN2YxMGRlIHJldj0w eGEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ052aWRpYSBDb3JwJwogICAgZGV2aWNlICAg ICA9ICdNQ1A1NSBTQVRBIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdl CiAgICBzdWJjbGFzcyAgID0gQVRBCmF0YXBjaTJAcGNpMDoxMzoxOgljbGFzcz0weDAxMDE4NSBj YXJkPTB4Y2I4NDEwNDMgY2hpcD0weDAzN2YxMGRlIHJldj0weGEyIGhkcj0weDAwCiAgICB2ZW5k b3IgICAgID0gJ052aWRpYSBDb3JwJwogICAgZGV2aWNlICAgICA9ICdNQ1A1NSBTQVRBIENvbnRy b2xsZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gQVRB CmF0YXBjaTNAcGNpMDoxMzoyOgljbGFzcz0weDAxMDE4NSBjYXJkPTB4Y2I4NDEwNDMgY2hpcD0w eDAzN2YxMGRlIHJldj0weGEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ052aWRpYSBDb3Jw JwogICAgZGV2aWNlICAgICA9ICdNQ1A1NSBTQVRBIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAg ID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gQVRBCnBjaWIyQHBjaTA6MTQ6MDoJY2xh c3M9MHgwNjA0MDEgY2FyZD0weGNiODQxMGRlIGNoaXA9MHgwMzcwMTBkZSByZXY9MHhhMiBoZHI9 MHgwMQogICAgdmVuZG9yICAgICA9ICdOdmlkaWEgQ29ycCcKICAgIGRldmljZSAgICAgPSAnTUNQ NTUgUENJIGJyaWRnZScKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQ Q0ktUENJCm5mZTBAcGNpMDoxNjowOgljbGFzcz0weDA2ODAwMCBjYXJkPTB4Y2I4NDEwNDMgY2hp cD0weDAzNzMxMGRlIHJldj0weGEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ052aWRpYSBD b3JwJwogICAgZGV2aWNlICAgICA9ICdNQ1A1NSBFdGhlcm5ldCcKICAgIGNsYXNzICAgICAgPSBi cmlkZ2UKcGNpYjNAcGNpMDoyMjowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDEwZGUgY2hp cD0weDAzNzUxMGRlIHJldj0weGEyIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ052aWRpYSBD b3JwJwogICAgZGV2aWNlICAgICA9ICdNQ1A1NSBQQ0kgRXhwcmVzcyBicmlkZ2UnCiAgICBjbGFz cyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpob3N0YjBAcGNpMDoyNDow OgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDAxMDIyIHJldj0weDAw IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCkn CiAgICBkZXZpY2UgICAgID0gJ0F0aGxvbiA2NCAvIE9wdGVyb24gSHlwZXJUcmFuc3BvcnQgVGVj aG5vbG9neSBDb25maWd1cmF0aW9uJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xh c3MgICA9IEhPU1QtUENJCmhvc3RiMUBwY2kwOjI0OjE6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgw MDAwMDAwMCBjaGlwPTB4MTEwMTEwMjIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAg PSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScKICAgIGRldmljZSAgICAgPSAnQXRobG9u IDY0IC8gT3B0ZXJvbiBBZGRyZXNzIE1hcCcKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1 YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjJAcGNpMDoyNDoyOgljbGFzcz0weDA2MDAwMCBjYXJk PTB4MDAwMDAwMDAgY2hpcD0weDExMDIxMDIyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3Ig ICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknCiAgICBkZXZpY2UgICAgID0gJ0F0 aGxvbiA2NCAvIE9wdGVyb24gRFJBTSBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IGJyaWRn ZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiM0BwY2kwOjI0OjM6CWNsYXNzPTB4MDYw MDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMzEwMjIgcmV2PTB4MDAgaGRyPTB4MDAKICAg IHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScKICAgIGRldmljZSAg ICAgPSAnQXRobG9uIDY0IC8gT3B0ZXJvbiBNaXNjZWxsYW5lb3VzIENvbnRyb2wnCiAgICBjbGFz cyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKdmdhcGNpMEBwY2kxOjA6 MDoJY2xhc3M9MHgwMzAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgwNDAyMTBkZSByZXY9MHhh MSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdOdmlkaWEgQ29ycCcKICAgIGNsYXNzICAgICAg PSBkaXNwbGF5CiAgICBzdWJjbGFzcyAgID0gVkdBCmF0YXBjaTRAcGNpMjo3OjA6CWNsYXNzPTB4 MDE4MDAwIGNhcmQ9MHgwMDA1MTEwMyBjaGlwPTB4MDAwNDExMDMgcmV2PTB4MDMgaGRyPTB4MDAK ICAgIHZlbmRvciAgICAgPSAnVHJpb25lcyBUZWNobm9sb2dpZXMgSW5jLiAoSGlnaFBvaW50KScK ICAgIGRldmljZSAgICAgPSAnSFBUM3h4IFVETUE2Ni8xMDAvMTMzIEVJREUgQ29udHJvbGxlcicK ICAgIGNsYXNzICAgICAgPSBtYXNzIHN0b3JhZ2UKbm9uZTExQHBjaTI6ODowOgljbGFzcz0weDA0 MDEwMCBjYXJkPTB4MTAwNzExMDIgY2hpcD0weDAwMDQxMTAyIHJldj0weDA0IGhkcj0weDAwCiAg ICB2ZW5kb3IgICAgID0gJ0NyZWF0aXZlIExhYnMnCiAgICBkZXZpY2UgICAgID0gJ0NyZWF0aXZl IFNCIEF1ZGlneSAyIFpTIChXRE0pIEF1ZGlneSBBdWRpbyBQcm9jZXNzb3InCiAgICBjbGFzcyAg ICAgID0gbXVsdGltZWRpYQogICAgc3ViY2xhc3MgICA9IGF1ZGlvCm5vbmUxMkBwY2kyOjg6MToJ Y2xhc3M9MHgwOTgwMDAgY2FyZD0weDAwNDAxMTAyIGNoaXA9MHg3MDAzMTEwMiByZXY9MHgwNCBo ZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdDcmVhdGl2ZSBMYWJzJwogICAgZGV2aWNlICAgICA9 ICdFTVUxMEsyIENyZWF0aXZlIExhYnMgU0IgQXVkaWd5IE1JREkvR2FtZSBwb3J0JwogICAgY2xh c3MgICAgICA9IGlucHV0IGRldmljZQpub25lMTNAcGNpMjo4OjI6CWNsYXNzPTB4MGMwMDEwIGNh cmQ9MHgwMDEwMTEwMiBjaGlwPTB4NDAwMTExMDIgcmV2PTB4MDQgaGRyPTB4MDAKICAgIHZlbmRv ciAgICAgPSAnQ3JlYXRpdmUgTGFicycKICAgIGRldmljZSAgICAgPSAnRU1VMTBLMiBBdWRpZ3kg SUVFRTEzOTRhIEZpcmV3aXJlIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1 cwogICAgc3ViY2xhc3MgICA9IEZpcmVXaXJlCm5vbmUxNEBwY2kyOjExOjA6CWNsYXNzPTB4MGMw MDEwIGNhcmQ9MHg4MTViMTA0MyBjaGlwPTB4ODAyMzEwNGMgcmV2PTB4MDAgaGRyPTB4MDAKICAg IHZlbmRvciAgICAgPSAnVGV4YXMgSW5zdHJ1bWVudHMgKFRJKScKICAgIGRldmljZSAgICAgPSAn VFNCNDNBQjIxL0EgSUVFRTEzOTRhLTIwMDAgT0hDSSBQSFkvTGluay1MYXllciBDdHJscicKICAg IGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gRmlyZVdpcmUKYXRhcGNp NUBwY2kzOjA6MDoJY2xhc3M9MHgwMTgwMDAgY2FyZD0weDgxOWYxMDQzIGNoaXA9MHgzMTMyMTA5 NSByZXY9MHgwMSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdTaWxpY29uIEltYWdlIEluYyAo V2FzOiBDTUQgVGVjaG5vbG9neSBJbmMpJwogICAgZGV2aWNlICAgICA9ICdTaUkgMzEzMiBQQ0kg RXhwcmVzcyAoMXgpIHRvIDIgUG9ydCBTQVRBMzAwJwogICAgY2xhc3MgICAgICA9IG1hc3Mgc3Rv cmFnZQo= ------=_Part_10924_26135791.1188583134351 Content-Type: text/plain; name="sysctl.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sysctl.txt"; filename="sysctl.txt"; filename="sysctl.txt"; filename="sysctl.txt"; filename="sysctl.txt" X-Attachment-Id: f_f60n3qm3 a2Vybi5vc3R5cGU6IEZyZWVCU0QKa2Vybi5vc3JlbGVhc2U6IDcuMC1DVVJSRU5ULTIwMDcwOApr ZXJuLm9zcmV2aXNpb246IDE5OTUwNgprZXJuLnZlcnNpb246IEZyZWVCU0QgNy4wLUNVUlJFTlQt MjAwNzA4ICMzOiBGcmkgQXVnIDMxIDIxOjMzOjIwIEJSVCAyMDA3CiAgICByb290QGV4eG9kdXMu ZmVkYXlraW4uaGVyZTovdXNyL3NyYy9zeXMvaTM4Ni9jb21waWxlL0xJT1VYCgprZXJuLm1heHZu b2RlczogMTAwMDAwCmtlcm4ubWF4cHJvYzogNjE2NAprZXJuLm1heGZpbGVzOiAxMjMyOAprZXJu LmFyZ21heDogMjYyMTQ0Cmtlcm4uc2VjdXJlbGV2ZWw6IC0xCmtlcm4uaG9zdG5hbWU6IGV4eG9k dXMuZmVkYXlraW4uaGVyZQprZXJuLmhvc3RpZDogODE3MDk1MzM4Cmtlcm4uY2xvY2tyYXRlOiB7 IGh6ID0gMTAwMCwgdGljayA9IDEwMDAsIHByb2ZoeiA9IDY2Niwgc3RhdGh6ID0gMTMzIH0Ka2Vy bi5wb3NpeDF2ZXJzaW9uOiAyMDAxMTIKa2Vybi5uZ3JvdXBzOiAxNgprZXJuLmpvYl9jb250cm9s OiAxCmtlcm4uc2F2ZWRfaWRzOiAwCmtlcm4uYm9vdHRpbWU6IHsgc2VjID0gMTE4ODYwODc1MCwg dXNlYyA9IDE2NTg0MyB9IEZyaSBBdWcgMzEgMjI6MDU6NTAgMjAwNwprZXJuLmRvbWFpbm5hbWU6 IAprZXJuLm9zcmVsZGF0ZTogNzAwMDUyCmtlcm4uYm9vdGZpbGU6IC9ib290L2tlcm5lbC5vbGQv a2VybmVsCmtlcm4ubWF4ZmlsZXNwZXJwcm9jOiAxMTA5NQprZXJuLm1heHByb2NwZXJ1aWQ6IDU1 NDcKa2Vybi5pcGMubWF4c29ja2J1ZjogMjYyMTQ0Cmtlcm4uaXBjLnNvY2tidWZfd2FzdGVfZmFj dG9yOiA4Cmtlcm4uaXBjLnNvbWF4Y29ubjogMTI4Cmtlcm4uaXBjLm1heF9saW5raGRyOiAxNgpr ZXJuLmlwYy5tYXhfcHJvdG9oZHI6IDYwCmtlcm4uaXBjLm1heF9oZHI6IDc2Cmtlcm4uaXBjLm1h eF9kYXRhbGVuOiAxMjgKa2Vybi5pcGMubm1ianVtYm8xNjogMAprZXJuLmlwYy5ubWJqdW1ibzk6 IDAKa2Vybi5pcGMubm1ianVtYm9wOiAwCmtlcm4uaXBjLm5tYmNsdXN0ZXJzOiAyNTYwMAprZXJu LmlwYy5waXBlcmVzaXplYWxsb3dlZDogMQprZXJuLmlwYy5waXBlcmVzaXplZmFpbDogMAprZXJu LmlwYy5waXBlYWxsb2NmYWlsOiAwCmtlcm4uaXBjLnBpcGVmcmFncmV0cnk6IDAKa2Vybi5pcGMu cGlwZWt2YTogMAprZXJuLmlwYy5tYXhwaXBla3ZhOiAxNjc3NzIxNgprZXJuLmlwYy5tc2dzZWc6 IDIwNDgKa2Vybi5pcGMubXNnc3N6OiA4Cmtlcm4uaXBjLm1zZ3RxbDogNDAKa2Vybi5pcGMubXNn bW5iOiAyMDQ4Cmtlcm4uaXBjLm1zZ21uaTogNDAKa2Vybi5pcGMubXNnbWF4OiAxNjM4NAprZXJu LmlwYy5zZW1hZW06IDE2Mzg0Cmtlcm4uaXBjLnNlbXZteDogMzI3NjcKa2Vybi5pcGMuc2VtdXN6 OiA5MgprZXJuLmlwYy5zZW11bWU6IDEwCmtlcm4uaXBjLnNlbW9wbTogMTAwCmtlcm4uaXBjLnNl bW1zbDogNjAKa2Vybi5pcGMuc2VtbW51OiAzMAprZXJuLmlwYy5zZW1tbnM6IDYwCmtlcm4uaXBj LnNlbW1uaTogMTAKa2Vybi5pcGMuc2VtbWFwOiAzMAprZXJuLmlwYy5zaG1fYWxsb3dfcmVtb3Zl ZDogMAprZXJuLmlwYy5zaG1fdXNlX3BoeXM6IDAKa2Vybi5pcGMuc2htYWxsOiA4MTkyCmtlcm4u aXBjLnNobXNlZzogMTI4Cmtlcm4uaXBjLnNobW1uaTogMTkyCmtlcm4uaXBjLnNobW1pbjogMQpr ZXJuLmlwYy5zaG1tYXg6IDMzNTU0NDMyCmtlcm4uaXBjLm1heHNvY2tldHM6IDEyMzI4Cmtlcm4u aXBjLm51bW9wZW5zb2NrZXRzOiAxMAprZXJuLmlwYy5uc2ZidWZzdXNlZDogMAprZXJuLmlwYy5u c2ZidWZzcGVhazogNAprZXJuLmlwYy5uc2ZidWZzOiA2NjU2Cmtlcm4uZHVtbXk6IDAKa2Vybi5w c19zdHJpbmdzOiAzMjE3MDMxMTUyCmtlcm4udXNyc3RhY2s6IDMyMTcwMzExNjgKa2Vybi5sb2dz aWdleGl0OiAxCmtlcm4uaW92X21heDogMTAyNAprZXJuLmhvc3R1dWlkOiA4MDAwZjM3OS02ZTk5 LWRiMTEtOTI0Yi0wMDFiZmMzOWZiMjMKa2Vybi5hcmFuZG9tOiAyMDY5ODQ0MTYyCmtlcm4uY2Ft LmNhbV9zcmNoX2hpOiAwCmtlcm4uY2FtLnNjc2lfZGVsYXk6IDUwMDAKa2Vybi5jYW0uZGEuZGFf c2VuZF9vcmRlcmVkOiAxCmtlcm4uY2FtLmRhLmRlZmF1bHRfdGltZW91dDogNjAKa2Vybi5jYW0u ZGEucmV0cnlfY291bnQ6IDQKa2Vybi5jYW0uZGEuMC5taW5pbXVtX2NtZF9zaXplOiAxMAprZXJu LmRpc2tzOiBkYTAgYWQxOCBhZDE2IGFkNiBhZDQKa2Vybi5nZW9tLmNvbGxlY3RzdGF0czogMQpr ZXJuLmdlb20uZGVidWdmbGFnczogMAprZXJuLmdlb20ubGFiZWwuZGVidWc6IDAKa2Vybi5lbGYz Mi5mYWxsYmFja19icmFuZDogLTEKa2Vybi5pbml0X3NodXRkb3duX3RpbWVvdXQ6IDEyMAprZXJu LmluaXRfcGF0aDogL3NiaW4vaW5pdDovc2Jpbi9vaW5pdDovc2Jpbi9pbml0LmJhazovcmVzY3Vl L2luaXQ6L3N0YW5kL3N5c2luc3RhbGwKa2Vybi5hY2N0X3N1c3BlbmRlZDogMAprZXJuLmFjY3Rf Y29uZmlndXJlZDogMAprZXJuLmFjY3RfY2hrZnJlcTogMTUKa2Vybi5hY2N0X3Jlc3VtZTogNApr ZXJuLmFjY3Rfc3VzcGVuZDogMgprZXJuLmNwX3RpbWU6IDEyMDY4IDAgMzIzNiA4MSAxMTE4MzY4 Cmtlcm4ub3BlbmZpbGVzOiA0NQprZXJuLmtxX2NhbGxvdXRtYXg6IDQwOTYKa2Vybi5wc19hcmdf Y2FjaGVfbGltaXQ6IDI1NgprZXJuLnN0YWNrcHJvdDogNwprZXJuLnJhbmRvbXBpZDogMAprZXJu Lmxhc3RwaWQ6IDE2MzgzCmtlcm4ua3RyYWNlLnJlcXVlc3RfcG9vbDogMTAwCmtlcm4ua3RyYWNl LmdlbmlvX3NpemU6IDQwOTYKa2Vybi5tb2R1bGVfcGF0aDogL2Jvb3Qva2VybmVsOy9ib290L21v ZHVsZXMKa2Vybi5tYWxsb2NfY291bnQ6IDE4NwprZXJuLmZhbGxiYWNrX2VsZl9icmFuZDogLTEK a2Vybi5tYXh1c2VyczogMzg0Cmtlcm4uaWRlbnQ6IExJT1VYCmtlcm4ua3N0YWNrX3BhZ2VzOiAy Cmtlcm4uc2h1dGRvd24ua3Byb2Nfc2h1dGRvd25fd2FpdDogNjAKa2Vybi5zaHV0ZG93bi5wb3dl cm9mZl9kZWxheTogNTAwMAprZXJuLnN5bmNfb25fcGFuaWM6IDAKa2Vybi5jb3JlZmlsZTogJU4u Y29yZQprZXJuLm5vZHVtcF9jb3JlZHVtcDogMAprZXJuLmNvcmVkdW1wOiAxCmtlcm4uc3VnaWRf Y29yZWR1bXA6IDAKa2Vybi5zaWdxdWV1ZS5hbGxvY19mYWlsOiAwCmtlcm4uc2lncXVldWUub3Zl cmZsb3c6IDAKa2Vybi5zaWdxdWV1ZS5wcmVhbGxvY2F0ZTogMTAyNAprZXJuLnNpZ3F1ZXVlLm1h eF9wZW5kaW5nX3Blcl9wcm9jOiAxMjgKa2Vybi5mb3JjZXNpZ2V4aXQ6IDEKa2Vybi5mc2NhbGU6 IDIwNDgKa2Vybi50aW1lY291bnRlci50aWNrOiAxCmtlcm4udGltZWNvdW50ZXIuY2hvaWNlOiBU U0MoLTEwMCkgQUNQSS1mYXN0KDEwMDApIEhQRVQoOTAwKSBpODI1NCgwKSBkdW1teSgtMTAwMDAw MCkKa2Vybi50aW1lY291bnRlci5oYXJkd2FyZTogQUNQSS1mYXN0Cmtlcm4udGltZWNvdW50ZXIu bnNldGNsb2NrOiAzCmtlcm4udGltZWNvdW50ZXIubmdldG1pY3JvdGltZTogMTY0MTc2Cmtlcm4u dGltZWNvdW50ZXIubmdldG5hbm90aW1lOiAyMQprZXJuLnRpbWVjb3VudGVyLm5nZXRiaW50aW1l OiAwCmtlcm4udGltZWNvdW50ZXIubmdldG1pY3JvdXB0aW1lOiAxMTg2ODAKa2Vybi50aW1lY291 bnRlci5uZ2V0bmFub3VwdGltZTogMTk1Cmtlcm4udGltZWNvdW50ZXIubmdldGJpbnVwdGltZTog MTkxOTcKa2Vybi50aW1lY291bnRlci5ubWljcm90aW1lOiA4NDA1Cmtlcm4udGltZWNvdW50ZXIu bm5hbm90aW1lOiAxOQprZXJuLnRpbWVjb3VudGVyLm5iaW50aW1lOiA4NDI0Cmtlcm4udGltZWNv dW50ZXIubm1pY3JvdXB0aW1lOiAxNjQyNQprZXJuLnRpbWVjb3VudGVyLm5uYW5vdXB0aW1lOiAw Cmtlcm4udGltZWNvdW50ZXIubmJpbnVwdGltZTogMjc4MzM2Cmtlcm4udGltZWNvdW50ZXIuc3Rl cHdhcm5pbmdzOiAwCmtlcm4udGltZWNvdW50ZXIudGMuaTgyNTQubWFzazogNjU1MzUKa2Vybi50 aW1lY291bnRlci50Yy5pODI1NC5jb3VudGVyOiAxNTA5MgprZXJuLnRpbWVjb3VudGVyLnRjLmk4 MjU0LmZyZXF1ZW5jeTogMTE5MzE4MgprZXJuLnRpbWVjb3VudGVyLnRjLmk4MjU0LnF1YWxpdHk6 IDAKa2Vybi50aW1lY291bnRlci50Yy5IUEVULm1hc2s6IDQyOTQ5NjcyOTUKa2Vybi50aW1lY291 bnRlci50Yy5IUEVULmNvdW50ZXI6IDM5OTIxMDQzNTMKa2Vybi50aW1lY291bnRlci50Yy5IUEVU LmZyZXF1ZW5jeTogMjUwMDAwMDAKa2Vybi50aW1lY291bnRlci50Yy5IUEVULnF1YWxpdHk6IDkw MAprZXJuLnRpbWVjb3VudGVyLnRjLkFDUEktZmFzdC5tYXNrOiAxNjc3NzIxNQprZXJuLnRpbWVj b3VudGVyLnRjLkFDUEktZmFzdC5jb3VudGVyOiA4MTUxMTM2Cmtlcm4udGltZWNvdW50ZXIudGMu QUNQSS1mYXN0LmZyZXF1ZW5jeTogMzU3OTU0NQprZXJuLnRpbWVjb3VudGVyLnRjLkFDUEktZmFz dC5xdWFsaXR5OiAxMDAwCmtlcm4udGltZWNvdW50ZXIudGMuVFNDLm1hc2s6IDQyOTQ5NjcyOTUK a2Vybi50aW1lY291bnRlci50Yy5UU0MuY291bnRlcjogMzM2MDk1MTQyNgprZXJuLnRpbWVjb3Vu dGVyLnRjLlRTQy5mcmVxdWVuY3k6IDI0MTA5OTMyODgKa2Vybi50aW1lY291bnRlci50Yy5UU0Mu cXVhbGl0eTogLTEwMAprZXJuLnRpbWVjb3VudGVyLnNtcF90c2M6IDAKa2Vybi50aHJlYWRzLnZp cnR1YWxfY3B1OiAyCmtlcm4udGhyZWFkcy5tYXhfdGhyZWFkc19oaXRzOiAwCmtlcm4udGhyZWFk cy5tYXhfdGhyZWFkc19wZXJfcHJvYzogMTUwMAprZXJuLmNjcHU6IDE5NDgKa2Vybi5zY2hlZC5y dW5xX2Z1eno6IDEKa2Vybi5zY2hlZC5wcmVlbXB0aW9uOiAxCmtlcm4uc2NoZWQuaXBpd2FrZXVw Lmh0dDI6IDAKa2Vybi5zY2hlZC5pcGl3YWtldXAub25lY3B1OiAwCmtlcm4uc2NoZWQuaXBpd2Fr ZXVwLnVzZWxvb3A6IDAKa2Vybi5zY2hlZC5pcGl3YWtldXAudXNlbWFzazogMQprZXJuLnNjaGVk LmlwaXdha2V1cC5kZWxpdmVyZWQ6IDMwOTg4MwprZXJuLnNjaGVkLmlwaXdha2V1cC5yZXF1ZXN0 ZWQ6IDMwOTg4MwprZXJuLnNjaGVkLmlwaXdha2V1cC5lbmFibGVkOiAxCmtlcm4uc2NoZWQucXVh bnR1bTogMTAwMDAwCmtlcm4uc2NoZWQubmFtZTogNEJTRAprZXJuLmRldnN0YXQudmVyc2lvbjog NgprZXJuLmRldnN0YXQuZ2VuZXJhdGlvbjogNDIwCmtlcm4uZGV2c3RhdC5udW1kZXZzOiA2Cmtl cm4ua29ial9tZXRob2Rjb3VudDogMTEzCmtlcm4ubG9nX3dha2V1cHNfcGVyX3NlY29uZDogNQpr ZXJuLm1zZ2J1Zl9jbGVhcjogMAprZXJuLm1zZ2J1ZjogCmtlcm4uYWx3YXlzX2NvbnNvbGVfb3V0 cHV0OiAwCmtlcm4ubG9nX2NvbnNvbGVfb3V0cHV0OiAxCmtlcm4uc21wLmZvcndhcmRfcm91bmRy b2Jpbl9lbmFibGVkOiAxCmtlcm4uc21wLmZvcndhcmRfc2lnbmFsX2VuYWJsZWQ6IDEKa2Vybi5z bXAuY3B1czogMgprZXJuLnNtcC5kaXNhYmxlZDogMAprZXJuLnNtcC5hY3RpdmU6IDEKa2Vybi5z bXAubWF4Y3B1czogMTYKa2Vybi5uc2VsY29sbDogMAprZXJuLnR0eV9ub3V0OiA2ODI4OTkKa2Vy bi50dHlfbmluOiA3NzQKa2Vybi5kcmFpbndhaXQ6IDMwMAprZXJuLmNvbnN0dHlfd2FrZXVwc19w ZXJfc2Vjb25kOiA1Cmtlcm4uY29uc21zZ2J1Zl9zaXplOiA4MTkyCmtlcm4uY29uc211dGU6IDAK a2Vybi5jb25zb2xlOiBjb25zb2xlY3RsLC9jb25zb2xlY3RsLGdkYix0dHlkMCwKa2Vybi5wdHMu bWF4OiAxMDAwCmtlcm4ucHRzLmVuYWJsZTogMAprZXJuLm1pbnZub2RlczogMjUwMDAKa2Vybi5t ZXRhZGVsYXk6IDI4Cmtlcm4uZGlyZGVsYXk6IDI5Cmtlcm4uZmlsZWRlbGF5OiAzMAprZXJuLmNo cm9vdF9hbGxvd19vcGVuX2RpcmVjdG9yaWVzOiAxCmtlcm4ucmFuZG9tLnlhcnJvdy5nZW5nYXRl aW50ZXJ2YWw6IDEwCmtlcm4ucmFuZG9tLnlhcnJvdy5iaW5zOiAxMAprZXJuLnJhbmRvbS55YXJy b3cuZmFzdHRocmVzaDogMTkyCmtlcm4ucmFuZG9tLnlhcnJvdy5zbG93dGhyZXNoOiAyNTYKa2Vy bi5yYW5kb20ueWFycm93LnNsb3dvdmVydGhyZXNoOiAyCmtlcm4ucmFuZG9tLnN5cy5zZWVkZWQ6 IDEKa2Vybi5yYW5kb20uc3lzLmhhcnZlc3QuZXRoZXJuZXQ6IDEKa2Vybi5yYW5kb20uc3lzLmhh cnZlc3QucG9pbnRfdG9fcG9pbnQ6IDEKa2Vybi5yYW5kb20uc3lzLmhhcnZlc3QuaW50ZXJydXB0 OiAxCmtlcm4ucmFuZG9tLnN5cy5oYXJ2ZXN0LnN3aTogMAp2bS52bXRvdGFsOiAKU3lzdGVtIHdp ZGUgdG90YWxzIGNvbXB1dGVkIGV2ZXJ5IGZpdmUgc2Vjb25kczogKHZhbHVlcyBpbiBraWxvYnl0 ZXMpCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClByb2Nl c3NlczoJCShSVU5ROiAxIERpc2sgV2FpdDogMCBQYWdlIFdhaXQ6IDAgU2xlZXA6IDE2KQpWaXJ0 dWFsIE1lbW9yeToJCShUb3RhbDogMjE3OTMyNEssIEFjdGl2ZSA0NDkwNEspClJlYWwgTWVtb3J5 OgkJKFRvdGFsOiA0OTMyMEsgQWN0aXZlIDEwMTQ4SykKU2hhcmVkIFZpcnR1YWwgTWVtb3J5Ogko VG90YWw6IDQ0NDBLIEFjdGl2ZTogMzAyOEspClNoYXJlZCBSZWFsIE1lbW9yeToJKFRvdGFsOiAz OTQwSyBBY3RpdmU6IDI4OTZLKQpGcmVlIE1lbW9yeSBQYWdlczoJMTc4NDYxNksKCnZtLmxvYWRh dmc6IHsgMC4wMiAwLjE0IDAuMDggfQp2bS52X2ZyZWVfbWluOiAzMjc4CnZtLnZfZnJlZV90YXJn ZXQ6IDEzODI5CnZtLnZfZnJlZV9yZXNlcnZlZDogNzE3CnZtLnZfaW5hY3RpdmVfdGFyZ2V0OiAy MDc0Mwp2bS52X2NhY2hlX21pbjogMTM4MjkKdm0udl9jYWNoZV9tYXg6IDI3NjU4CnZtLnZfcGFn ZW91dF9mcmVlX21pbjogMzQKdm0ucGFnZW91dF9hbGdvcml0aG06IDAKdm0uc3dhcF9lbmFibGVk OiAxCnZtLmttZW1fc2l6ZV9zY2FsZTogMwp2bS5rbWVtX3NpemVfbWF4OiAzMzU1NDQzMjAKdm0u a21lbV9zaXplX21pbjogMAp2bS5rbWVtX3NpemU6IDMzNTU0NDMyMAp2bS5uc3dhcGRldjogMQp2 bS5kbW1heDogMzIKdm0uc3dhcF9hc3luY19tYXg6IDQKdm0uem9uZV9jb3VudDogNzkKdm0uc3dh cF9pZGxlX3RocmVzaG9sZDI6IDEwCnZtLnN3YXBfaWRsZV90aHJlc2hvbGQxOiAyCnZtLmV4ZWNf bWFwX2VudHJpZXM6IDE2CnZtLnN0YXRzLm1pc2MuemVyb19wYWdlX2NvdW50OiAxMTQKdm0uc3Rh dHMubWlzYy5jbnRfcHJlemVybzogMAp2bS5zdGF0cy52bS52X2t0aHJlYWRwYWdlczogMAp2bS5z dGF0cy52bS52X3Jmb3JrcGFnZXM6IDAKdm0uc3RhdHMudm0udl92Zm9ya3BhZ2VzOiAxMDg0Mjk0 CnZtLnN0YXRzLnZtLnZfZm9ya3BhZ2VzOiAxNjM4NDE1CnZtLnN0YXRzLnZtLnZfa3RocmVhZHM6 IDQ5CnZtLnN0YXRzLnZtLnZfcmZvcmtzOiAwCnZtLnN0YXRzLnZtLnZfdmZvcmtzOiA3NjY0CnZt LnN0YXRzLnZtLnZfZm9ya3M6IDg2NzAKdm0uc3RhdHMudm0udl9pbnRlcnJ1cHRfZnJlZV9taW46 IDIKdm0uc3RhdHMudm0udl9wYWdlb3V0X2ZyZWVfbWluOiAzNAp2bS5zdGF0cy52bS52X2NhY2hl X21heDogMjc2NTgKdm0uc3RhdHMudm0udl9jYWNoZV9taW46IDEzODI5CnZtLnN0YXRzLnZtLnZf Y2FjaGVfY291bnQ6IDMzCnZtLnN0YXRzLnZtLnZfaW5hY3RpdmVfY291bnQ6IDM3MzkwCnZtLnN0 YXRzLnZtLnZfaW5hY3RpdmVfdGFyZ2V0OiAyMDc0Mwp2bS5zdGF0cy52bS52X2FjdGl2ZV9jb3Vu dDogMjA3NAp2bS5zdGF0cy52bS52X3dpcmVfY291bnQ6IDI2Nzk2CnZtLnN0YXRzLnZtLnZfZnJl ZV9jb3VudDogNDQ2MTIxCnZtLnN0YXRzLnZtLnZfZnJlZV9taW46IDMyNzgKdm0uc3RhdHMudm0u dl9mcmVlX3RhcmdldDogMTM4MjkKdm0uc3RhdHMudm0udl9mcmVlX3Jlc2VydmVkOiA3MTcKdm0u c3RhdHMudm0udl9wYWdlX2NvdW50OiA1MTI1MjEKdm0uc3RhdHMudm0udl9wYWdlX3NpemU6IDQw OTYKdm0uc3RhdHMudm0udl90ZnJlZTogMjA4ODkwMgp2bS5zdGF0cy52bS52X3BmcmVlOiAxNjU0 MTYxCnZtLnN0YXRzLnZtLnZfZGZyZWU6IDAKdm0uc3RhdHMudm0udl90Y2FjaGVkOiAxNjQ2Ngp2 bS5zdGF0cy52bS52X3BkcGFnZXM6IDAKdm0uc3RhdHMudm0udl9wZHdha2V1cHM6IDAKdm0uc3Rh dHMudm0udl9yZWFjdGl2YXRlZDogODAKdm0uc3RhdHMudm0udl9pbnRyYW5zOiA3CnZtLnN0YXRz LnZtLnZfdm5vZGVwZ3NvdXQ6IDAKdm0uc3RhdHMudm0udl92bm9kZXBnc2luOiAyMjU0Mwp2bS5z dGF0cy52bS52X3Zub2Rlb3V0OiAwCnZtLnN0YXRzLnZtLnZfdm5vZGVpbjogMzI5Nwp2bS5zdGF0 cy52bS52X3N3YXBwZ3NvdXQ6IDAKdm0uc3RhdHMudm0udl9zd2FwcGdzaW46IDAKdm0uc3RhdHMu dm0udl9zd2Fwb3V0OiAwCnZtLnN0YXRzLnZtLnZfc3dhcGluOiAwCnZtLnN0YXRzLnZtLnZfb3pm b2Q6IDM2NjM2CnZtLnN0YXRzLnZtLnZfemZvZDogMTYzODI0Mgp2bS5zdGF0cy52bS52X2Nvd19v cHRpbTogMjUwCnZtLnN0YXRzLnZtLnZfY293X2ZhdWx0czogMjYyODM3CnZtLnN0YXRzLnZtLnZf dm1fZmF1bHRzOiAyMTMxODUzCnZtLnN0YXRzLnN5cy52X3NvZnQ6IDczMzE3Nwp2bS5zdGF0cy5z eXMudl9pbnRyOiAzNzYyMAp2bS5zdGF0cy5zeXMudl9zeXNjYWxsOiAzNDM3NDk1CnZtLnN0YXRz LnN5cy52X3RyYXA6IDIxNjA5NzgKdm0uc3RhdHMuc3lzLnZfc3d0Y2g6IDIwMTU3OTEKdm0uc3Rh dHMub2JqZWN0LmJ5cGFzc2VzOiAxMjI4CnZtLnN0YXRzLm9iamVjdC5jb2xsYXBzZXM6IDMzMzE4 CnZtLnZfZnJlZV9zZXZlcmU6IDE5OTcKdm0ubWF4X3Byb2NfbW1hcDogNDkzNDQKdm0ub2xkX21z eW5jOiAwCnZtLm1zeW5jX2ZsdXNoX2ZsYWdzOiAzCnZtLmJvb3RfcGFnZXM6IDQ4CnZtLnBhZ2Vv dXRfbG9ja19taXNzOiAwCnZtLmRpc2FibGVfc3dhcHNwYWNlX3BhZ2VvdXRzOiAwCnZtLmRlZmVy X3N3YXBzcGFjZV9wYWdlb3V0czogMAp2bS5zd2FwX2lkbGVfZW5hYmxlZDogMAp2bS5wYWdlb3V0 X3N0YXRzX2ludGVydmFsOiA1CnZtLnBhZ2VvdXRfZnVsbF9zdGF0c19pbnRlcnZhbDogMjAKdm0u cGFnZW91dF9zdGF0c19tYXg6IDEzODI5CnZtLm1heF9sYXVuZGVyOiAzMgp2bS5waHlzX3NlZ3M6 IApTRUdNRU5UIDA6CgpzdGFydDogICAgIDB4MTAwMAplbmQ6ICAgICAgIDB4OWQwMDAKZnJlZSBs aXN0OiAweGMwN2I4MzI0CgpTRUdNRU5UIDE6CgpzdGFydDogICAgIDB4MTAwMDAwCmVuZDogICAg ICAgMHg0MDAwMDAKZnJlZSBsaXN0OiAweGMwN2I4MzI0CgpTRUdNRU5UIDI6CgpzdGFydDogICAg IDB4YzI4MDAwCmVuZDogICAgICAgMHgxMDAwMDAwCmZyZWUgbGlzdDogMHhjMDdiODMyNAoKU0VH TUVOVCAzOgoKc3RhcnQ6ICAgICAweDEwMDAwMDAKZW5kOiAgICAgICAweDdkYTk1MDAwCmZyZWUg bGlzdDogMHhjMDdiODJhMAoKdm0ucGh5c19mcmVlOiAKRlJFRSBMSVNUIDA6CgogIE9SREVSIChT SVpFKSAgfCAgTlVNQkVSCiAgICAgICAgICAgICAgICB8ICBQT09MIDAKLS0gICAgICAgICAgICAt LSAtLSAgICAgIC0tCiAgMTAgKCAgNDA5NkspICB8ICAgICAzOTIKICAgOSAoICAyMDQ4SykgIHwg ICAgICAgMAogICA4ICggIDEwMjRLKSAgfCAgICAgICAwCiAgIDcgKCAgIDUxMkspICB8ICAgICAg IDYKICAgNiAoICAgMjU2SykgIHwgICAgICAxOAogICA1ICggICAxMjhLKSAgfCAgICAgIDY0CiAg IDQgKCAgICA2NEspICB8ICAgICAzMTEKICAgMyAoICAgIDMySykgIHwgICAgMTM3MAogICAyICgg ICAgMTZLKSAgfCAgICAyNTUxCiAgIDEgKCAgICAgOEspICB8ICAgIDQ0OTcKICAgMCAoICAgICA0 SykgIHwgICAgMzcxMwoKRlJFRSBMSVNUIDE6CgogIE9SREVSIChTSVpFKSAgfCAgTlVNQkVSCiAg ICAgICAgICAgICAgICB8ICBQT09MIDAKLS0gICAgICAgICAgICAtLSAtLSAgICAgIC0tCiAgMTAg KCAgNDA5NkspICB8ICAgICAgIDAKICAgOSAoICAyMDQ4SykgIHwgICAgICAgMgogICA4ICggIDEw MjRLKSAgfCAgICAgICAyCiAgIDcgKCAgIDUxMkspICB8ICAgICAgIDEKICAgNiAoICAgMjU2Sykg IHwgICAgICAgMgogICA1ICggICAxMjhLKSAgfCAgICAgICAxCiAgIDQgKCAgICA2NEspICB8ICAg ICAgIDIKICAgMyAoICAgIDMySykgIHwgICAgICAgMwogICAyICggICAgMTZLKSAgfCAgICAgICAz CiAgIDEgKCAgICAgOEspICB8ICAgICAgIDIKICAgMCAoICAgICA0SykgIHwgICAgICAgMQoKdm0u aWRsZXplcm9fZW5hYmxlOiAwCnZtLmt2bV9mcmVlOiAzOTg0NTQ3ODQKdm0ua3ZtX3NpemU6IDEw Njk1NDM0MjQKdm0ucG1hcC5wbWFwX2NvbGxlY3RfYWN0aXZlOiAwCnZtLnBtYXAucG1hcF9jb2xs ZWN0X2luYWN0aXZlOiAwCnZtLnBtYXAucHZfZW50cnlfc3BhcmU6IDIyMzgKdm0ucG1hcC5wdl9l bnRyeV9hbGxvY3M6IDgzMjQ3NDEKdm0ucG1hcC5wdl9lbnRyeV9mcmVlczogODMxODI0Mwp2bS5w bWFwLnBjX2NodW5rX3RyeWZhaWw6IDAKdm0ucG1hcC5wY19jaHVua19mcmVlczogNjIwMzUKdm0u cG1hcC5wY19jaHVua19hbGxvY3M6IDYyMDYxCnZtLnBtYXAucGNfY2h1bmtfY291bnQ6IDI2CnZt LnBtYXAucHZfZW50cnlfY291bnQ6IDY0OTgKdm0ucG1hcC5zaHBncGVycHJvYzogMjAwCnZtLnBt YXAucHZfZW50cnlfbWF4OiAxNzQ1NTIwCnZmcy51ZnMuZGlyaGFzaF9kb2NoZWNrOiAwCnZmcy51 ZnMuZGlyaGFzaF9tZW06IDE4MjY5MQp2ZnMudWZzLmRpcmhhc2hfbWF4bWVtOiAyMDk3MTUyCnZm cy51ZnMuZGlyaGFzaF9taW5zaXplOiAyNTYwCnZmcy5kZXZmcy5ydWxlX2RlcHRoOiAxCnZmcy5k ZXZmcy5nZW5lcmF0aW9uOiAxMTUKdmZzLnBmcy50cmFjZTogMAp2ZnMucGZzLnZuY2FjaGUubWlz c2VzOiAwCnZmcy5wZnMudm5jYWNoZS5oaXRzOiAwCnZmcy5wZnMudm5jYWNoZS5tYXhlbnRyaWVz OiAwCnZmcy5wZnMudm5jYWNoZS5lbnRyaWVzOiAwCnZmcy5mbHVzaHdpdGhkZXBzOiAwCnZmcy5n ZXRuZXdidWZyZXN0YXJ0czogMAp2ZnMuZ2V0bmV3YnVmY2FsbHM6IDMzMDM2CnZmcy5oaWZyZWVi dWZmZXJzOiA4MDgKdmZzLmxvZnJlZWJ1ZmZlcnM6IDQwNAp2ZnMubnVtZnJlZWJ1ZmZlcnM6IDcx ODkKdmZzLmRpcnR5YnVmdGhyZXNoOiAxNjM3CnZmcy5oaWRpcnR5YnVmZmVyczogMTgxOQp2ZnMu bG9kaXJ0eWJ1ZmZlcnM6IDkwOQp2ZnMubnVtZGlydHlidWZmZXJzOiA5CnZmcy5yZWN1cnNpdmVm bHVzaGVzOiAwCnZmcy5hbHRidWZmZXJmbHVzaGVzOiAwCnZmcy5iZHdyaXRlc2tpcDogMAp2ZnMu ZGlydHlidWZmZXJmbHVzaGVzOiAwCnZmcy5oaXJ1bm5pbmdzcGFjZTogMTA0ODU3Ngp2ZnMubG9y dW5uaW5nc3BhY2U6IDUyNDI4OAp2ZnMuYnVmZGVmcmFnY250OiAwCnZmcy5idWZmcmVla3ZhY250 OiAwCnZmcy5idWZyZXVzZWNudDogNzE1NAp2ZnMuaGlidWZzcGFjZTogMTE3Mjc2NjcyCnZmcy5s b2J1ZnNwYWNlOiAxMTcyMTExMzYKdmZzLm1heG1hbGxvY2J1ZnNwYWNlOiA1ODYzODMzCnZmcy5i dWZtYWxsb2NzcGFjZTogMzY4NjQKdmZzLm1heGJ1ZnNwYWNlOiAxMTc5MzIwMzIKdmZzLmJ1ZnNw YWNlOiAxMTcyMTExMzYKdmZzLnJ1bm5pbmdidWZzcGFjZTogMAp2ZnMudm1pb2RpcmVuYWJsZTog MQp2ZnMuY2FjaGUubnVtZnVsbHBhdGhmb3VuZDogOTkxOAp2ZnMuY2FjaGUubnVtZnVsbHBhdGhm YWlsNDogMAp2ZnMuY2FjaGUubnVtZnVsbHBhdGhmYWlsMjogMAp2ZnMuY2FjaGUubnVtZnVsbHBh dGhmYWlsMTogMAp2ZnMuY2FjaGUubnVtZnVsbHBhdGhjYWxsczogOTkxOAp2ZnMuY2FjaGUubmNo c3RhdHM6IDY1MjY2MjkgODY5MjgwIDEyNDg1IDAgMTUwNjgxIDAgNzg3IDI1OTMyCnZmcy5jYWNo ZS5udW1uZWdoaXRzOiA4NjkyODAKdmZzLmNhY2hlLm51bW5lZ3phcHM6IDI1ODcKdmZzLmNhY2hl Lm51bXBvc2hpdHM6IDY1MjY2MjkKdmZzLmNhY2hlLm51bXBvc3phcHM6IDk4OTgKdmZzLmNhY2hl Lm51bW1pc3N6YXA6IDc2CnZmcy5jYWNoZS5udW1taXNzOiAxNTA2MDUKdmZzLmNhY2hlLm51bWNo ZWNrczogNzcxMzEyNgp2ZnMuY2FjaGUuZG90ZG90aGl0czogOTE3NzYyCnZmcy5jYWNoZS5kb3Ro aXRzOiAxNTY5NjgKdmZzLmNhY2hlLm51bWNhbGxzOiA4NjMzODA1CnZmcy5jYWNoZS5udW1jYWNo ZTogOTcyMgp2ZnMuY2FjaGUubnVtbmVnOiA2MDcKdmZzLnJlYWRfbWF4OiA4CnZmcy53cml0ZV9i ZWhpbmQ6IDEKdmZzLmxvb2t1cF9zaGFyZWQ6IDAKdmZzLnVzZXJtb3VudDogMAp2ZnMud29ya2xp c3RfbGVuOiA0CnZmcy50aW1lc3RhbXBfcHJlY2lzaW9uOiAwCnZmcy5yZWFzc2lnbmJ1ZmNhbGxz OiA0NTY4OQp2ZnMuZnJlZXZub2RlczogMTM4MQp2ZnMud2FudGZyZWV2bm9kZXM6IDI1MDAwCnZm cy5udW12bm9kZXM6IDkyNDEKdmZzLmZmcy5kb3JlYWxsb2NibGtzOiAxCnZmcy5mZnMuZG9hc3lu Y2ZyZWU6IDEKdmZzLmZmcy5jb21wdXRlX3N1bW1hcnlfYXRfbW91bnQ6IDAKbmV0LmxvY2FsLnN0 cmVhbS5yZWN2c3BhY2U6IDgxOTIKbmV0LmxvY2FsLnN0cmVhbS5zZW5kc3BhY2U6IDgxOTIKbmV0 LmxvY2FsLmRncmFtLnJlY3ZzcGFjZTogNDA5NgpuZXQubG9jYWwuZGdyYW0ubWF4ZGdyYW06IDIw NDgKbmV0LmxvY2FsLnJlY3ljbGVkOiAwCm5ldC5sb2NhbC50YXNrY291bnQ6IDAKbmV0LmxvY2Fs LmluZmxpZ2h0OiAwCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5yYW5kb210aW1lOiA0NQpuZXQuaW5l dC5pcC5wb3J0cmFuZ2UucmFuZG9tY3BzOiAxMApuZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmFuZG9t aXplZDogMQpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmVzZXJ2ZWRsb3c6IDAKbmV0LmluZXQuaXAu cG9ydHJhbmdlLnJlc2VydmVkaGlnaDogMTAyMwpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UuaGlsYXN0 OiA2NTUzNQpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UuaGlmaXJzdDogNDkxNTIKbmV0LmluZXQuaXAu cG9ydHJhbmdlLmxhc3Q6IDY1NTM1Cm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5maXJzdDogNDkxNTIK bmV0LmluZXQuaXAucG9ydHJhbmdlLmxvd2xhc3Q6IDYwMApuZXQuaW5ldC5pcC5wb3J0cmFuZ2Uu bG93Zmlyc3Q6IDEwMjMKbmV0LmluZXQuaXAuZm9yd2FyZGluZzogMApuZXQuaW5ldC5pcC5yZWRp cmVjdDogMQpuZXQuaW5ldC5pcC50dGw6IDY0Cm5ldC5pbmV0LmlwLnJ0ZXhwaXJlOiAzNjAwCm5l dC5pbmV0LmlwLnJ0bWluZXhwaXJlOiAxMApuZXQuaW5ldC5pcC5ydG1heGNhY2hlOiAxMjgKbmV0 LmluZXQuaXAuc291cmNlcm91dGU6IDAKbmV0LmluZXQuaXAuaW50cl9xdWV1ZV9tYXhsZW46IDUw Cm5ldC5pbmV0LmlwLmludHJfcXVldWVfZHJvcHM6IDAKbmV0LmluZXQuaXAuYWNjZXB0X3NvdXJj ZXJvdXRlOiAwCm5ldC5pbmV0LmlwLmtlZXBmYWl0aDogMApuZXQuaW5ldC5pcC5zYW1lX3ByZWZp eF9jYXJwX29ubHk6IDAKbmV0LmluZXQuaXAuc3VibmV0c19hcmVfbG9jYWw6IDAKbmV0LmluZXQu aXAuZmFzdGZvcndhcmRpbmc6IDAKbmV0LmluZXQuaXAubWF4ZnJhZ3BhY2tldHM6IDgwMApuZXQu aW5ldC5pcC5tYXhmcmFnc3BlcnBhY2tldDogMTYKbmV0LmluZXQuaXAuZnJhZ3BhY2tldHM6IDAK bmV0LmluZXQuaXAuY2hlY2tfaW50ZXJmYWNlOiAwCm5ldC5pbmV0LmlwLnJhbmRvbV9pZDogMApu ZXQuaW5ldC5pcC5zZW5kc291cmNlcXVlbmNoOiAwCm5ldC5pbmV0LmlwLnByb2Nlc3Nfb3B0aW9u czogMQpuZXQuaW5ldC5pY21wLm1hc2tyZXBsOiAwCm5ldC5pbmV0LmljbXAuaWNtcGxpbTogMjAw Cm5ldC5pbmV0LmljbXAuYm1jYXN0ZWNobzogMApuZXQuaW5ldC5pY21wLnF1b3RlbGVuOiA4Cm5l dC5pbmV0LmljbXAucmVwbHlfZnJvbV9pbnRlcmZhY2U6IDAKbmV0LmluZXQuaWNtcC5yZXBseV9z cmM6IApuZXQuaW5ldC5pY21wLmljbXBsaW1fb3V0cHV0OiAxCm5ldC5pbmV0LmljbXAubG9nX3Jl ZGlyZWN0OiAwCm5ldC5pbmV0LmljbXAuZHJvcF9yZWRpcmVjdDogMApuZXQuaW5ldC5pY21wLm1h c2tmYWtlOiAwCm5ldC5pbmV0LnRjcC5yZmMxMzIzOiAxCm5ldC5pbmV0LnRjcC5tc3NkZmx0OiA1 MTIKbmV0LmluZXQudGNwLmtlZXBpZGxlOiA3MjAwMDAwCm5ldC5pbmV0LnRjcC5rZWVwaW50dmw6 IDc1MDAwCm5ldC5pbmV0LnRjcC5zZW5kc3BhY2U6IDMyNzY4Cm5ldC5pbmV0LnRjcC5yZWN2c3Bh Y2U6IDY1NTM2Cm5ldC5pbmV0LnRjcC5rZWVwaW5pdDogNzUwMDAKbmV0LmluZXQudGNwLmRlbGFj a3RpbWU6IDEwMApuZXQuaW5ldC50Y3AudjZtc3NkZmx0OiAxMDI0Cm5ldC5pbmV0LnRjcC5ob3N0 Y2FjaGUucHVyZ2U6IDAKbmV0LmluZXQudGNwLmhvc3RjYWNoZS5wcnVuZTogMzAwCm5ldC5pbmV0 LnRjcC5ob3N0Y2FjaGUuZXhwaXJlOiAzNjAwCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUuY291bnQ6 IDAKbmV0LmluZXQudGNwLmhvc3RjYWNoZS5idWNrZXRsaW1pdDogMzAKbmV0LmluZXQudGNwLmhv c3RjYWNoZS5oYXNoc2l6ZTogNTEyCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUuY2FjaGVsaW1pdDog MTUzNjAKbmV0LmluZXQudGNwLnJlY3ZidWZfbWF4OiAyNjIxNDQKbmV0LmluZXQudGNwLnJlY3Zi dWZfaW5jOiAxNjM4NApuZXQuaW5ldC50Y3AucmVjdmJ1Zl9hdXRvOiAxCm5ldC5pbmV0LnRjcC5p bnNlY3VyZV9yc3Q6IDAKbmV0LmluZXQudGNwLnJmYzMzOTA6IDEKbmV0LmluZXQudGNwLnJmYzMw NDI6IDEKbmV0LmluZXQudGNwLmRyb3Bfc3luZmluOiAwCm5ldC5pbmV0LnRjcC5kZWxheWVkX2Fj azogMQpuZXQuaW5ldC50Y3AuYmxhY2tob2xlOiAwCm5ldC5pbmV0LnRjcC5sb2dfaW5fdmFpbjog MApuZXQuaW5ldC50Y3Auc2VuZGJ1Zl9tYXg6IDI2MjE0NApuZXQuaW5ldC50Y3Auc2VuZGJ1Zl9p bmM6IDgxOTIKbmV0LmluZXQudGNwLnNlbmRidWZfYXV0bzogMQpuZXQuaW5ldC50Y3AudHNvOiAx Cm5ldC5pbmV0LnRjcC5uZXdyZW5vOiAxCm5ldC5pbmV0LnRjcC5sb2NhbF9zbG93c3RhcnRfZmxp Z2h0c2l6ZTogNApuZXQuaW5ldC50Y3Auc2xvd3N0YXJ0X2ZsaWdodHNpemU6IDEKbmV0LmluZXQu dGNwLnBhdGhfbXR1X2Rpc2NvdmVyeTogMQpuZXQuaW5ldC50Y3AucmVhc3Mub3ZlcmZsb3dzOiAw Cm5ldC5pbmV0LnRjcC5yZWFzcy5tYXhxbGVuOiA0OApuZXQuaW5ldC50Y3AucmVhc3MuY3Vyc2Vn bWVudHM6IDAKbmV0LmluZXQudGNwLnJlYXNzLm1heHNlZ21lbnRzOiAxNjAwCm5ldC5pbmV0LnRj cC5zYWNrLmdsb2JhbGhvbGVzOiAwCm5ldC5pbmV0LnRjcC5zYWNrLmdsb2JhbG1heGhvbGVzOiA2 NTUzNgpuZXQuaW5ldC50Y3Auc2Fjay5tYXhob2xlczogMTI4Cm5ldC5pbmV0LnRjcC5zYWNrLmVu YWJsZTogMQpuZXQuaW5ldC50Y3AuaW5mbGlnaHQuc3RhYjogMjAKbmV0LmluZXQudGNwLmluZmxp Z2h0Lm1heDogMTA3MzcyNTQ0MApuZXQuaW5ldC50Y3AuaW5mbGlnaHQubWluOiA2MTQ0Cm5ldC5p bmV0LnRjcC5pbmZsaWdodC5ydHR0aHJlc2g6IDEwCm5ldC5pbmV0LnRjcC5pbmZsaWdodC5kZWJ1 ZzogMApuZXQuaW5ldC50Y3AuaW5mbGlnaHQuZW5hYmxlOiAxCm5ldC5pbmV0LnRjcC5pc25fcmVz ZWVkX2ludGVydmFsOiAwCm5ldC5pbmV0LnRjcC5pY21wX21heV9yc3Q6IDEKbmV0LmluZXQudGNw LnBjYmNvdW50OiAxCm5ldC5pbmV0LnRjcC5kb190Y3BkcmFpbjogMQpuZXQuaW5ldC50Y3AudGNi aGFzaHNpemU6IDUxMgpuZXQuaW5ldC50Y3AubG9nX2RlYnVnOiAxCm5ldC5pbmV0LnRjcC5taW5t c3M6IDIxNgpuZXQuaW5ldC50Y3Auc3luY2FjaGUucnN0X29uX3NvY2tfZmFpbDogMQpuZXQuaW5l dC50Y3Auc3luY2FjaGUucmV4bXRsaW1pdDogMwpuZXQuaW5ldC50Y3Auc3luY2FjaGUuaGFzaHNp emU6IDUxMgpuZXQuaW5ldC50Y3Auc3luY2FjaGUuY291bnQ6IDAKbmV0LmluZXQudGNwLnN5bmNh Y2hlLmNhY2hlbGltaXQ6IDE1MzYwCm5ldC5pbmV0LnRjcC5zeW5jYWNoZS5idWNrZXRsaW1pdDog MzAKbmV0LmluZXQudGNwLnN5bmNvb2tpZXNfb25seTogMApuZXQuaW5ldC50Y3Auc3luY29va2ll czogMQpuZXQuaW5ldC50Y3AudGltZXJfcmFjZTogMApuZXQuaW5ldC50Y3AuZmlud2FpdDJfdGlt ZW91dDogNjAwMDAKbmV0LmluZXQudGNwLmZhc3RfZmlud2FpdDJfcmVjeWNsZTogMApuZXQuaW5l dC50Y3AuYWx3YXlzX2tlZXBhbGl2ZTogMQpuZXQuaW5ldC50Y3AucmV4bWl0X3Nsb3A6IDIwMApu ZXQuaW5ldC50Y3AucmV4bWl0X21pbjogMzAKbmV0LmluZXQudGNwLm1zbDogMzAwMDAKbmV0Lmlu ZXQudGNwLm5vbG9jYWx0aW1ld2FpdDogMApuZXQuaW5ldC50Y3AubWF4dGNwdHc6IDI0NjUKbmV0 LmluZXQudWRwLmNoZWNrc3VtOiAxCm5ldC5pbmV0LnVkcC5tYXhkZ3JhbTogOTIxNgpuZXQuaW5l dC51ZHAucmVjdnNwYWNlOiA0MjA4MApuZXQuaW5ldC51ZHAuYmxhY2tob2xlOiAwCm5ldC5pbmV0 LnVkcC5sb2dfaW5fdmFpbjogMApuZXQuaW5ldC5zY3RwLnNjdHBfbG9nZ2luZzogMApuZXQuaW5l dC5zY3RwLm1heF9yZXRyYW5fY2h1bms6IDMwCm5ldC5pbmV0LnNjdHAubWluX3Jlc2lkdWFsOiAx NDUyCm5ldC5pbmV0LnNjdHAuc3RyaWN0X2RhdGFfb3JkZXI6IDAKbmV0LmluZXQuc2N0cC5hYm9y dF9hdF9saW1pdDogMApuZXQuaW5ldC5zY3RwLmhiX21heF9idXJzdDogNApuZXQuaW5ldC5zY3Rw LmRvX3NjdHBfZHJhaW46IDEKbmV0LmluZXQuc2N0cC5jbXRfdXNlX2RhYzogMApuZXQuaW5ldC5z Y3RwLm1heF9jaGFpbmVkX21idWZzOiA1Cm5ldC5pbmV0LnNjdHAuYWJjX2xfdmFyOiAxCm5ldC5p bmV0LnNjdHAubmF0X2ZyaWVuZGx5OiAxCm5ldC5pbmV0LnNjdHAuYXV0aF9kaXNhYmxlOiAwCm5l dC5pbmV0LnNjdHAuYXNjb25mX2F1dGhfbm9jaGs6IDAKbmV0LmluZXQuc2N0cC5lYXJseV9mYXN0 X3JldHJhbl9tc2VjOiAyNTAKbmV0LmluZXQuc2N0cC5kZWFkbG9ja19kZXRlY3Q6IDAKbmV0Lmlu ZXQuc2N0cC5lYXJseV9mYXN0X3JldHJhbjogMApuZXQuaW5ldC5zY3RwLmN3bmRfbWF4YnVyc3Q6 IDEKbmV0LmluZXQuc2N0cC5kZWZhdWx0X2NjX21vZHVsZTogMApuZXQuaW5ldC5zY3RwLmNtdF9w ZjogMApuZXQuaW5ldC5zY3RwLmNtdF9vbl9vZmY6IDAKbmV0LmluZXQuc2N0cC5vdXRnb2luZ19z dHJlYW1zOiAxMApuZXQuaW5ldC5zY3RwLmFkZF9tb3JlX29uX291dHB1dDogMTQ1MgpuZXQuaW5l dC5zY3RwLnBhdGhfcnR4X21heDogNQpuZXQuaW5ldC5zY3RwLmFzc29jX3J0eF9tYXg6IDEwCm5l dC5pbmV0LnNjdHAuaW5pdF9ydHhfbWF4OiA4Cm5ldC5pbmV0LnNjdHAudmFsaWRfY29va2llX2xp ZmU6IDYwMDAwCm5ldC5pbmV0LnNjdHAuaW5pdF9ydG9fbWF4OiA2MDAwMApuZXQuaW5ldC5zY3Rw LnJ0b19pbml0aWFsOiAzMDAwCm5ldC5pbmV0LnNjdHAucnRvX21pbjogMTAwMApuZXQuaW5ldC5z Y3RwLnJ0b19tYXg6IDYwMDAwCm5ldC5pbmV0LnNjdHAuc2VjcmV0X2xpZmV0aW1lOiAzNjAwCm5l dC5pbmV0LnNjdHAuc2h1dGRvd25fZ3VhcmRfdGltZTogMTgwCm5ldC5pbmV0LnNjdHAucG10dV9y YWlzZV90aW1lOiA2MDAKbmV0LmluZXQuc2N0cC5oZWFydGJlYXRfaW50ZXJ2YWw6IDMwMDAwCm5l dC5pbmV0LnNjdHAuc2Fja19mcmVxOiAyCm5ldC5pbmV0LnNjdHAuZGVsYXllZF9zYWNrX3RpbWU6 IDIwMApuZXQuaW5ldC5zY3RwLmNodW5rc2NhbGU6IDEwCm5ldC5pbmV0LnNjdHAuYXNvY19yZXNv dXJjZTogMTAKbmV0LmluZXQuc2N0cC5zeXNfcmVzb3VyY2U6IDEwMDAKbmV0LmluZXQuc2N0cC5w Y2JoYXNoc2l6ZTogMjU2Cm5ldC5pbmV0LnNjdHAubWluX3NwbGl0X3BvaW50OiAyOTA0Cm5ldC5p bmV0LnNjdHAudGNiaGFzaHNpemU6IDEwMjQKbmV0LmluZXQuc2N0cC5tYXhjaHVua3M6IDMyMDAK bmV0LmluZXQuc2N0cC5tYXhidXJzdDogNApuZXQuaW5ldC5zY3RwLnBlZXJfY2hrb2g6IDI1Ngpu ZXQuaW5ldC5zY3RwLnN0cmljdF9pbml0OiAxCm5ldC5pbmV0LnNjdHAubG9vcGJhY2tfbm9jc3Vt OiAxCm5ldC5pbmV0LnNjdHAuc3RyaWN0X3NhY2tzOiAwCm5ldC5pbmV0LnNjdHAuZWNuX25vbmNl OiAwCm5ldC5pbmV0LnNjdHAuZWNuX2VuYWJsZTogMQpuZXQuaW5ldC5zY3RwLmF1dG9fYXNjb25m OiAxCm5ldC5pbmV0LnNjdHAucmVjdnNwYWNlOiAyMzMwMTYKbmV0LmluZXQuc2N0cC5zZW5kc3Bh Y2U6IDIzMzAxNgpuZXQuaW5ldC5yYXcucmVjdnNwYWNlOiA5MjE2Cm5ldC5pbmV0LnJhdy5tYXhk Z3JhbTogOTIxNgpuZXQuaW5ldC5hY2NmLnVubG9hZGFibGU6IDAKbmV0LmxpbmsuZ2VuZXJpYy5z eXN0ZW0uaWZjb3VudDogMgpuZXQubGluay5ldGhlci5pbmV0LmxvZ19hcnBfcGVybWFuZW50X21v ZGlmeTogMQpuZXQubGluay5ldGhlci5pbmV0LmxvZ19hcnBfbW92ZW1lbnRzOiAxCm5ldC5saW5r LmV0aGVyLmluZXQubG9nX2FycF93cm9uZ19pZmFjZTogMQpuZXQubGluay5ldGhlci5pbmV0LnBy b3h5YWxsOiAwCm5ldC5saW5rLmV0aGVyLmluZXQudXNlbG9vcGJhY2s6IDEKbmV0LmxpbmsuZXRo ZXIuaW5ldC5tYXh0cmllczogNQpuZXQubGluay5ldGhlci5pbmV0Lm1heF9hZ2U6IDEyMDAKbmV0 LmxpbmsuZXRoZXIuaXBmdzogMApuZXQubGluay5sb2dfbGlua19zdGF0ZV9jaGFuZ2U6IDEKbmV0 LmluZXQ2LmlwNi5mb3J3YXJkaW5nOiAwCm5ldC5pbmV0Ni5pcDYucmVkaXJlY3Q6IDEKbmV0Lmlu ZXQ2LmlwNi5obGltOiA2NApuZXQuaW5ldDYuaXA2Lm1heGZyYWdwYWNrZXRzOiA2NDAwCm5ldC5p bmV0Ni5pcDYuYWNjZXB0X3J0YWR2OiAwCm5ldC5pbmV0Ni5pcDYua2VlcGZhaXRoOiAwCm5ldC5p bmV0Ni5pcDYubG9nX2ludGVydmFsOiA1Cm5ldC5pbmV0Ni5pcDYuaGRybmVzdGxpbWl0OiAxNQpu ZXQuaW5ldDYuaXA2LmRhZF9jb3VudDogMQpuZXQuaW5ldDYuaXA2LmF1dG9fZmxvd2xhYmVsOiAx Cm5ldC5pbmV0Ni5pcDYuZGVmbWNhc3RobGltOiAxCm5ldC5pbmV0Ni5pcDYuZ2lmaGxpbTogMApu ZXQuaW5ldDYuaXA2LmthbWVfdmVyc2lvbjogRnJlZUJTRApuZXQuaW5ldDYuaXA2LnVzZV9kZXBy ZWNhdGVkOiAxCm5ldC5pbmV0Ni5pcDYucnJfcHJ1bmU6IDUKbmV0LmluZXQ2LmlwNi52Nm9ubHk6 IDEKbmV0LmluZXQ2LmlwNi5ydGV4cGlyZTogMzYwMApuZXQuaW5ldDYuaXA2LnJ0bWluZXhwaXJl OiAxMApuZXQuaW5ldDYuaXA2LnJ0bWF4Y2FjaGU6IDEyOApuZXQuaW5ldDYuaXA2LnVzZV90ZW1w YWRkcjogMApuZXQuaW5ldDYuaXA2LnRlbXBwbHRpbWU6IDg2NDAwCm5ldC5pbmV0Ni5pcDYudGVt cHZsdGltZTogNjA0ODAwCm5ldC5pbmV0Ni5pcDYuYXV0b19saW5rbG9jYWw6IDAKbmV0LmluZXQ2 LmlwNi5wcmVmZXJfdGVtcGFkZHI6IDAKbmV0LmluZXQ2LmlwNi51c2VfZGVmYXVsdHpvbmU6IDAK bmV0LmluZXQ2LmlwNi5tYXhmcmFnczogNjQwMApuZXQuaW5ldDYuaXA2Lm1jYXN0X3BtdHU6IDAK bmV0LmluZXQ2LmljbXA2LnJlZGlyYWNjZXB0OiAxCm5ldC5pbmV0Ni5pY21wNi5yZWRpcnRpbWVv dXQ6IDYwMApuZXQuaW5ldDYuaWNtcDYubmQ2X3BydW5lOiAxCm5ldC5pbmV0Ni5pY21wNi5uZDZf ZGVsYXk6IDUKbmV0LmluZXQ2LmljbXA2Lm5kNl91bWF4dHJpZXM6IDMKbmV0LmluZXQ2LmljbXA2 Lm5kNl9tbWF4dHJpZXM6IDMKbmV0LmluZXQ2LmljbXA2Lm5kNl91c2Vsb29wYmFjazogMQpuZXQu aW5ldDYuaWNtcDYubm9kZWluZm86IDMKbmV0LmluZXQ2LmljbXA2LmVycnBwc2xpbWl0OiAxMDAK bmV0LmluZXQ2LmljbXA2Lm5kNl9tYXhudWRoaW50OiAwCm5ldC5pbmV0Ni5pY21wNi5uZDZfZGVi dWc6IDAKbmV0LmluZXQ2LmljbXA2Lm5kNl9tYXhxdWV1ZWxlbjogMQpuZXQuYnBmLm1heGluc25z OiA1MTIKbmV0LmJwZi5tYXhidWZzaXplOiA1MjQyODgKbmV0LmJwZi5idWZzaXplOiA0MDk2Cm5l dC5pc3Iuc3dpX2NvdW50OiAyCm5ldC5pc3IuZHJvcDogMApuZXQuaXNyLnF1ZXVlZDogMgpuZXQu aXNyLmRlZmVycmVkOiAwCm5ldC5pc3IuZGlyZWN0ZWQ6IDQzNApuZXQuaXNyLmNvdW50OiA0MzQK bmV0Lmlzci5kaXJlY3Q6IDEKbmV0LnJvdXRlLm5ldGlzcl9tYXhxbGVuOiAyNTYKZGVidWcuZGRi X3VzZV9wcmludGY6IDAKZGVidWcubWRkZWJ1ZzogMApkZWJ1Zy5nZGJjb25zOiAwCmRlYnVnLmVs ZjMyX2xlZ2FjeV9jb3JlZHVtcDogMApkZWJ1Zy5lbGYzMl90cmFjZTogMApkZWJ1Zy5ib290dmVy Ym9zZTogMApkZWJ1Zy5ib290aG93dG86IC0yMTQ3NDgzNjQ4CmRlYnVnLmNwdWZyZXEudmVyYm9z ZTogMApkZWJ1Zy5jcHVmcmVxLmxvd2VzdDogMApkZWJ1Zy5zaXplb2YuY2Rldl9wcml2OiAyMzIK ZGVidWcuc2l6ZW9mLmNkZXY6IDE4NApkZWJ1Zy5zaXplb2YuZ19iaW9xOiAzNgpkZWJ1Zy5zaXpl b2YuZ19jb25zdW1lcjogNjAKZGVidWcuc2l6ZW9mLmdfcHJvdmlkZXI6IDg4CmRlYnVnLnNpemVv Zi5nX2dlb206IDY4CmRlYnVnLnNpemVvZi5nX2NsYXNzOiA2OApkZWJ1Zy5zaXplb2Yua2luZm9f cHJvYzogNzY4CmRlYnVnLnNpemVvZi5idWY6IDM1NgpkZWJ1Zy5zaXplb2YuYmlvOiAxMzIKZGVi dWcuc2l6ZW9mLnByb2M6IDY4NApkZWJ1Zy5zaXplb2Yudm5vZGU6IDI3MgpkZWJ1Zy5zaXplb2Yu ZGV2c3RhdDogMjQwCmRlYnVnLnNpemVvZi5uYW1lY2FjaGU6IDM2CmRlYnVnLnRyYWNlX29uX3Bh bmljOiAwCmRlYnVnLmRlYnVnZ2VyX29uX3BhbmljOiAxCmRlYnVnLnRvX2F2Z19tcGNhbGxzOiAx MTg1CmRlYnVnLnRvX2F2Z19tdHhjYWxsczogNwpkZWJ1Zy50b19hdmdfZ2NhbGxzOiAyNTAKZGVi dWcudG9fYXZnX2RlcHRoOiAxNTA5CmRlYnVnLnVtdHgudW10eF9waV9hbGxvY2F0ZWQ6IDAKZGVi dWcua2RiLnN0b3BfY3B1czogMQpkZWJ1Zy5rZGIudHJhcF9jb2RlOiAwCmRlYnVnLmtkYi50cmFw OiAwCmRlYnVnLmtkYi5wYW5pYzogMApkZWJ1Zy5rZGIuZW50ZXI6IDAKZGVidWcua2RiLmN1cnJl bnQ6IGRkYgpkZWJ1Zy5rZGIuYXZhaWxhYmxlOiBkZGIgCmRlYnVnLnJtYW5fZGVidWc6IDAKZGVi dWcudHR5ZGVidWc6IDAKZGVidWcuZGlzYWJsZWZ1bGxwYXRoOiAwCmRlYnVnLmRpc2FibGVjd2Q6 IDAKZGVidWcuaGFzaHN0YXQubmNoYXNoOiAxMzEwNzIgOTM2NSAzIDcxNApkZWJ1Zy52ZnNjYWNo ZTogMQpkZWJ1Zy5udW1jYWNoZWh2OiAxNTM2CmRlYnVnLm51bWNhY2hlOiA5NzIyCmRlYnVnLm51 bW5lZzogNjA3CmRlYnVnLm5jbmVnZmFjdG9yOiAxNgpkZWJ1Zy5uY2hhc2g6IDEzMTA3MQpkZWJ1 Zy52bmxydV9ub3doZXJlOiAwCmRlYnVnLnJ1c2hfcmVxdWVzdHM6IDAKZGVidWcubXBzYWZldmZz OiAxCmRlYnVnLmNvbGxlY3RzbmFwc3RhdHM6IDAKZGVidWcuc25hcGRlYnVnOiAwCmRlYnVnLmRv cGVyc2lzdGVuY2U6IDAKZGVidWcuZGlyX2VudHJ5OiA1MTcKZGVidWcuZGlyZWN0X2Jsa19wdHJz OiAyCmRlYnVnLmlub2RlX2JpdG1hcDogODkKZGVidWcuaW5kaXJfYmxrX3B0cnM6IDAKZGVidWcu c3luY19saW1pdF9oaXQ6IDAKZGVidWcuaW5vX2xpbWl0X2hpdDogMApkZWJ1Zy5ibGtfbGltaXRf aGl0OiAwCmRlYnVnLmlub19saW1pdF9wdXNoOiAwCmRlYnVnLmJsa19saW1pdF9wdXNoOiAwCmRl YnVnLndvcmtsaXN0X3B1c2g6IDAKZGVidWcubWF4aW5kaXJkZXBzOiA1MApkZWJ1Zy50aWNrZGVs YXk6IDIKZGVidWcubWF4X3NvZnRkZXBzOiA0MDAwMDAKZGVidWcuZG9ia2dyZHdyaXRlOiAxCmRl YnVnLmJpZ2NnczogMApkZWJ1Zy5kaXJjaGVjazogMApkZWJ1Zy5ub3NsZWVwd2l0aGxvY2tzOiAw CmRlYnVnLnBzbS5wa3RlcnJ0aHJlc2g6IDIKZGVidWcucHNtLnVzZWNzOiA1MDAwMDAKZGVidWcu cHNtLnNlY3M6IDAKZGVidWcucHNtLmVycnVzZWNzOiAwCmRlYnVnLnBzbS5lcnJzZWNzOiAyCmRl YnVnLnBzbS5oejogMjAKZGVidWcucHNtLmxvZ2xldmVsOiAwCmRlYnVnLmZkYy5zZXR0bGU6IDEy NQpkZWJ1Zy5mZGMuc3BlYzI6IDE2CmRlYnVnLmZkYy5zcGVjMTogMTc1CmRlYnVnLmZkYy5yZXRy aWVzOiAxMApkZWJ1Zy5mZGMuZGVidWdmbGFnczogMApkZWJ1Zy5mZGMuZmlmbzogOApkZWJ1Zy5t aW5pZHVtcDogMQpkZWJ1Zy5zdG9wX2NwdXNfd2l0aF9ubWk6IDEKZGVidWcuUE1BUDF1bmNoYW5n ZWQ6IDMwMDc1NTQKZGVidWcuUE1BUDFjaGFuZ2VkOiAyNTk2NgpkZWJ1Zy5QTUFQMWNoYW5nZWRj cHU6IDM1CmRlYnVnLmFjcGkuc3VzcGVuZF9ib3VuY2U6IDAKZGVidWcuYWNwaS5kb19wb3dlcnN0 YXRlOiAxCmRlYnVnLmFjcGkuYWNwaV9jYV92ZXJzaW9uOiAyMDA3MDMyMApkZWJ1Zy5hY3BpLmVj LnRpbWVvdXQ6IDUwMApkZWJ1Zy5hY3BpLmVjLnBvbGxfdGltZTogNTAwCmRlYnVnLmFjcGkuZWMu YnVyc3Q6IDAKZGVidWcuYWNwaS5zZW1hcGhvcmVfZGVidWc6IDAKZGVidWcuYWNwaS5yZXN1bWVf YmVlcDogMApody5tYWNoaW5lOiBpMzg2Cmh3Lm1vZGVsOiBBTUQgQXRobG9uKHRtKSA2NCBYMiBE dWFsIENvcmUgUHJvY2Vzc29yIDQ2MDArCmh3Lm5jcHU6IDIKaHcuYnl0ZW9yZGVyOiAxMjM0Cmh3 LnBoeXNtZW06IDIxMzczNDE5NTIKaHcudXNlcm1lbTogMjAyNzYzNDY4OApody5wYWdlc2l6ZTog NDA5Ngpody5mbG9hdGluZ3BvaW50OiAxCmh3Lm1hY2hpbmVfYXJjaDogaTM4Ngpody5yZWFsbWVt OiAyMTQ2MzA0MDAwCmh3LmF0YS53YzogMQpody5hdGEuYXRhcGlfZG1hOiAxCmh3LmF0YS5hdGFf ZG1hOiAxCmh3LnBjaS5ob25vcl9tc2lfYmxhY2tsaXN0OiAxCmh3LnBjaS5lbmFibGVfbXNpeDog MQpody5wY2kuZW5hYmxlX21zaTogMQpody5wY2kuZW5hYmxlX3ZwZDogMQpody5wY2kuZG9fcG93 ZXJfcmVzdW1lOiAxCmh3LnBjaS5kb19wb3dlcl9ub2RyaXZlcjogMApody5wY2kuZW5hYmxlX2lv X21vZGVzOiAxCmh3LnBjaS5ob3N0X21lbV9zdGFydDogMjE0NzQ4MzY0OApody5wY2kuaXJxX292 ZXJyaWRlX21hc2s6IDU3MDgwCmh3LnN5c2NvbnMua2JkX2RlYnVnOiAxCmh3LnN5c2NvbnMua2Jk X3JlYm9vdDogMQpody5zeXNjb25zLmJlbGw6IDEKaHcuc3lzY29ucy5zYXZlci5rZXlib25seTog MQpody5zeXNjb25zLnNjX25vX3N1c3BlbmRfdnRzd2l0Y2g6IDAKaHcuaW50cl9zdG9ybV90aHJl c2hvbGQ6IDEwMDAKaHcuYXZhaWxwYWdlczogNTIxODEyCmh3LmJ1cy5kZXZjdGxfZGlzYWJsZTog MApody5wc20udGFwX3RpbWVvdXQ6IDEyNTAwMApody5wc20udGFwX3RocmVzaG9sZDogMjUKaHcu a2JkLmtleW1hcF9yZXN0cmljdF9jaGFuZ2U6IDAKaHcuYnVzZG1hLnRvdGFsX2JwYWdlczogNzA0 Cmh3LmJ1c2RtYS56b25lMC50b3RhbF9icGFnZXM6IDE5Mgpody5idXNkbWEuem9uZTAuZnJlZV9i cGFnZXM6IDE5Mgpody5idXNkbWEuem9uZTAucmVzZXJ2ZWRfYnBhZ2VzOiAwCmh3LmJ1c2RtYS56 b25lMC5hY3RpdmVfYnBhZ2VzOiAwCmh3LmJ1c2RtYS56b25lMC50b3RhbF9ib3VuY2VkOiAwCmh3 LmJ1c2RtYS56b25lMC50b3RhbF9kZWZlcnJlZDogMApody5idXNkbWEuem9uZTAubG93YWRkcjog MHhmZmZmZmZmZgpody5idXNkbWEuem9uZTAuYWxpZ25tZW50OiAyCmh3LmJ1c2RtYS56b25lMC5i b3VuZGFyeTogNjU1MzYKaHcuYnVzZG1hLnpvbmUxLnRvdGFsX2JwYWdlczogNTEyCmh3LmJ1c2Rt YS56b25lMS5mcmVlX2JwYWdlczogNTEyCmh3LmJ1c2RtYS56b25lMS5yZXNlcnZlZF9icGFnZXM6 IDAKaHcuYnVzZG1hLnpvbmUxLmFjdGl2ZV9icGFnZXM6IDAKaHcuYnVzZG1hLnpvbmUxLnRvdGFs X2JvdW5jZWQ6IDAKaHcuYnVzZG1hLnpvbmUxLnRvdGFsX2RlZmVycmVkOiAwCmh3LmJ1c2RtYS56 b25lMS5sb3dhZGRyOiAweGZmZmZmZmZmCmh3LmJ1c2RtYS56b25lMS5hbGlnbm1lbnQ6IDQwOTYK aHcuYnVzZG1hLnpvbmUxLmJvdW5kYXJ5OiAwCmh3LmNsb2NrcmF0ZTogMjQxMApody52aWFfZmVh dHVyZV94Y3J5cHQ6IDAKaHcudmlhX2ZlYXR1cmVfcm5nOiAwCmh3Lmluc3RydWN0aW9uX3NzZTog MQpody5hcGljLmVuYWJsZV9leHRpbnQ6IDAKaHcuYWNwaS5zdXBwb3J0ZWRfc2xlZXBfc3RhdGU6 IFMzIFM0IFM1Cmh3LmFjcGkucG93ZXJfYnV0dG9uX3N0YXRlOiBTNQpody5hY3BpLnNsZWVwX2J1 dHRvbl9zdGF0ZTogUzMKaHcuYWNwaS5saWRfc3dpdGNoX3N0YXRlOiBOT05FCmh3LmFjcGkuc3Rh bmRieV9zdGF0ZTogUzEKaHcuYWNwaS5zdXNwZW5kX3N0YXRlOiBTMwpody5hY3BpLnNsZWVwX2Rl bGF5OiAxCmh3LmFjcGkuczRiaW9zOiAwCmh3LmFjcGkudmVyYm9zZTogMApody5hY3BpLmRpc2Fi bGVfb25fcmVib290OiAwCmh3LmFjcGkuaGFuZGxlX3JlYm9vdDogMApody5hY3BpLnJlc2V0X3Zp ZGVvOiAwCmh3LmFjcGkuY3B1LmN4X2xvd2VzdDogQzEKaHcuYWNwaS50aGVybWFsLm1pbl9ydW50 aW1lOiAwCmh3LmFjcGkudGhlcm1hbC5wb2xsaW5nX3JhdGU6IDEwCmh3LmFjcGkudGhlcm1hbC51 c2VyX292ZXJyaWRlOiAwCmh3LmFjcGkudGhlcm1hbC50ejAudGVtcGVyYXR1cmU6IDQwLjBDCmh3 LmFjcGkudGhlcm1hbC50ejAuYWN0aXZlOiAtMQpody5hY3BpLnRoZXJtYWwudHowLnBhc3NpdmVf Y29vbGluZzogMQpody5hY3BpLnRoZXJtYWwudHowLnRoZXJtYWxfZmxhZ3M6IDAKaHcuYWNwaS50 aGVybWFsLnR6MC5fUFNWOiA3My4wQwpody5hY3BpLnRoZXJtYWwudHowLl9IT1Q6IC0xCmh3LmFj cGkudGhlcm1hbC50ejAuX0NSVDogNzUuMEMKaHcuYWNwaS50aGVybWFsLnR6MC5fQUN4OiA3My4w QyAtMSAtMSAtMSAtMSAtMSAtMSAtMSAtMSAtMQptYWNoZGVwLmVuYWJsZV9wYW5pY19rZXk6IDAK bWFjaGRlcC5hZGprZXJudHo6IDEwODAwCm1hY2hkZXAud2FsbF9jbW9zX2Nsb2NrOiAxCm1hY2hk ZXAuZGlzYWJsZV9ydGNfc2V0OiAwCm1hY2hkZXAuY29uc3BlZWQ6IDk2MDAKbWFjaGRlcC5nZGJz cGVlZDogOTYwMAptYWNoZGVwLmNvbnJjbGs6IDE4NDMyMDAKbWFjaGRlcC5kaXNhYmxlX210cnJz OiAwCm1hY2hkZXAuZ3Vlc3NlZF9ib290ZGV2OiAyNjg4NTQ4ODY0Cm1hY2hkZXAuY3B1X2lkbGVf aGx0OiAxCm1hY2hkZXAuaGx0X2NwdXM6IDAKbWFjaGRlcC5wYW5pY19vbl9ubWk6IDEKbWFjaGRl cC5rZGJfb25fbm1pOiAxCm1hY2hkZXAudHNjX2ZyZXE6IDI0MTA5OTMyODgKbWFjaGRlcC5pODI1 NF9mcmVxOiAxMTkzMTgyCm1hY2hkZXAuYWNwaV90aW1lcl9mcmVxOiAzNTc5NTQ1Cm1hY2hkZXAu YWNwaV9yb290OiAxMDE0NzIwCnVzZXIuY3NfcGF0aDogL3Vzci9iaW46L2JpbjovdXNyL3NiaW46 L3NiaW46CnVzZXIuYmNfYmFzZV9tYXg6IDk5CnVzZXIuYmNfZGltX21heDogMjA0OAp1c2VyLmJj X3NjYWxlX21heDogOTkKdXNlci5iY19zdHJpbmdfbWF4OiAxMDAwCnVzZXIuY29sbF93ZWlnaHRz X21heDogMAp1c2VyLmV4cHJfbmVzdF9tYXg6IDMyCnVzZXIubGluZV9tYXg6IDIwNDgKdXNlci5y ZV9kdXBfbWF4OiAyNTUKdXNlci5wb3NpeDJfdmVyc2lvbjogMTk5MjEyCnVzZXIucG9zaXgyX2Nf YmluZDogMAp1c2VyLnBvc2l4Ml9jX2RldjogMAp1c2VyLnBvc2l4Ml9jaGFyX3Rlcm06IDAKdXNl ci5wb3NpeDJfZm9ydF9kZXY6IDAKdXNlci5wb3NpeDJfZm9ydF9ydW46IDAKdXNlci5wb3NpeDJf bG9jYWxlZGVmOiAwCnVzZXIucG9zaXgyX3N3X2RldjogMAp1c2VyLnBvc2l4Ml91cGU6IDAKdXNl ci5zdHJlYW1fbWF4OiAyMAp1c2VyLnR6bmFtZV9tYXg6IDI1NQpwMTAwM18xYi5hc3luY2hyb25v dXNfaW86IDAKcDEwMDNfMWIubWFwcGVkX2ZpbGVzOiAxCnAxMDAzXzFiLm1lbWxvY2s6IDAKcDEw MDNfMWIubWVtbG9ja19yYW5nZTogMApwMTAwM18xYi5tZW1vcnlfcHJvdGVjdGlvbjogMApwMTAw M18xYi5tZXNzYWdlX3Bhc3Npbmc6IDAKcDEwMDNfMWIucHJpb3JpdGl6ZWRfaW86IDAKcDEwMDNf MWIucHJpb3JpdHlfc2NoZWR1bGluZzogMQpwMTAwM18xYi5yZWFsdGltZV9zaWduYWxzOiAyMDAx MTIKcDEwMDNfMWIuc2VtYXBob3JlczogMApwMTAwM18xYi5mc3luYzogMApwMTAwM18xYi5zaGFy ZWRfbWVtb3J5X29iamVjdHM6IDEKcDEwMDNfMWIuc3luY2hyb25pemVkX2lvOiAwCnAxMDAzXzFi LnRpbWVyczogMjAwMTEyCnAxMDAzXzFiLmFpb19saXN0aW9fbWF4OiAtMQpwMTAwM18xYi5haW9f bWF4OiAtMQpwMTAwM18xYi5haW9fcHJpb19kZWx0YV9tYXg6IC0xCnAxMDAzXzFiLmRlbGF5dGlt ZXJfbWF4OiAyMTQ3NDgzNjQ3CnAxMDAzXzFiLm1xX29wZW5fbWF4OiAwCnAxMDAzXzFiLnBhZ2Vz aXplOiA0MDk2CnAxMDAzXzFiLnJ0c2lnX21heDogNjIKcDEwMDNfMWIuc2VtX25zZW1zX21heDog MApwMTAwM18xYi5zZW1fdmFsdWVfbWF4OiAwCnAxMDAzXzFiLnNpZ3F1ZXVlX21heDogMTI4CnAx MDAzXzFiLnRpbWVyX21heDogMzIKc2VjdXJpdHkuamFpbC5qYWlsZWQ6IDAKc2VjdXJpdHkuamFp bC5tb3VudF9hbGxvd2VkOiAwCnNlY3VyaXR5LmphaWwuY2hmbGFnc19hbGxvd2VkOiAwCnNlY3Vy aXR5LmphaWwuYWxsb3dfcmF3X3NvY2tldHM6IDAKc2VjdXJpdHkuamFpbC5lbmZvcmNlX3N0YXRm czogMgpzZWN1cml0eS5qYWlsLnN5c3ZpcGNfYWxsb3dlZDogMApzZWN1cml0eS5qYWlsLnNvY2tl dF91bml4aXByb3V0ZV9vbmx5OiAxCnNlY3VyaXR5LmphaWwuc2V0X2hvc3RuYW1lX2FsbG93ZWQ6 IDEKc2VjdXJpdHkuYnNkLnN1c2VyX2VuYWJsZWQ6IDEKc2VjdXJpdHkuYnNkLnVucHJpdmlsZWdl ZF9wcm9jX2RlYnVnOiAxCnNlY3VyaXR5LmJzZC5jb25zZXJ2YXRpdmVfc2lnbmFsczogMQpzZWN1 cml0eS5ic2Quc2VlX290aGVyX2dpZHM6IDEKc2VjdXJpdHkuYnNkLnNlZV9vdGhlcl91aWRzOiAx CnNlY3VyaXR5LmJzZC51bnByaXZpbGVnZWRfcmVhZF9tc2didWY6IDEKc2VjdXJpdHkuYnNkLmhh cmRsaW5rX2NoZWNrX2dpZDogMApzZWN1cml0eS5ic2QuaGFyZGxpbmtfY2hlY2tfdWlkOiAwCnNl Y3VyaXR5LmJzZC51bnByaXZpbGVnZWRfZ2V0X3F1b3RhOiAwCmRldi5uZXh1cy4wLiVkcml2ZXI6 IG5leHVzCmRldi5uZXh1cy4wLiVwYXJlbnQ6IHJvb3QwCmRldi5yYW0uMC4lZGVzYzogU3lzdGVt IFJBTQpkZXYucmFtLjAuJWRyaXZlcjogcmFtCmRldi5yYW0uMC4lcGFyZW50OiBuZXh1czAKZGV2 Lm5weC4wLiVkZXNjOiBtYXRoIHByb2Nlc3NvcgpkZXYubnB4LjAuJWRyaXZlcjogbnB4CmRldi5u cHguMC4lcGFyZW50OiBuZXh1czAKZGV2LmFjcGkuMC4lZGVzYzogTnZpZGlhIEFTVVNBQ1BJCmRl di5hY3BpLjAuJWRyaXZlcjogYWNwaQpkZXYuYWNwaS4wLiVwYXJlbnQ6IG5leHVzMApkZXYuYWNw aV9ocGV0LjAuJWRlc2M6IEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyCmRldi5hY3BpX2hwZXQu MC4lZHJpdmVyOiBhY3BpX2hwZXQKZGV2LmFjcGlfaHBldC4wLiVsb2NhdGlvbjogdW5rbm93bgpk ZXYuYWNwaV9ocGV0LjAuJXBucGluZm86IHVua25vd24KZGV2LmFjcGlfaHBldC4wLiVwYXJlbnQ6 IGFjcGkwCmRldi5hY3BpX3N5c3Jlc291cmNlLjAuJWRlc2M6IFN5c3RlbSBSZXNvdXJjZQpkZXYu YWNwaV9zeXNyZXNvdXJjZS4wLiVkcml2ZXI6IGFjcGlfc3lzcmVzb3VyY2UKZGV2LmFjcGlfc3lz cmVzb3VyY2UuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLk1CSU8KZGV2LmFjcGlfc3lz cmVzb3VyY2UuMC4lcG5waW5mbzogX0hJRD1QTlAwQzAyIF9VSUQ9NQpkZXYuYWNwaV9zeXNyZXNv dXJjZS4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX3N5c3Jlc291cmNlLjEuJWRlc2M6IFN5c3Rl bSBSZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS4xLiVkcml2ZXI6IGFjcGlfc3lzcmVzb3Vy Y2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMS4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLkxF RzAuU1lTUgpkZXYuYWNwaV9zeXNyZXNvdXJjZS4xLiVwbnBpbmZvOiBfSElEPVBOUDBDMDIgX1VJ RD0xCmRldi5hY3BpX3N5c3Jlc291cmNlLjEuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfc3lzcmVz b3VyY2UuMi4lZGVzYzogU3lzdGVtIFJlc291cmNlCmRldi5hY3BpX3N5c3Jlc291cmNlLjIuJWRy aXZlcjogYWNwaV9zeXNyZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS4yLiVsb2NhdGlvbjog aGFuZGxlPVxfU0JfLlBDSTAuRVhQTApkZXYuYWNwaV9zeXNyZXNvdXJjZS4yLiVwbnBpbmZvOiBf SElEPVBOUDBDMDIgX1VJRD00CmRldi5hY3BpX3N5c3Jlc291cmNlLjIuJXBhcmVudDogYWNwaTAK ZGV2LmFjcGlfc3lzcmVzb3VyY2UuMy4lZGVzYzogU3lzdGVtIFJlc291cmNlCmRldi5hY3BpX3N5 c3Jlc291cmNlLjMuJWRyaXZlcjogYWNwaV9zeXNyZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJj ZS4zLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLk1FTV8KZGV2LmFjcGlfc3lzcmVzb3VyY2UuMy4l cG5waW5mbzogX0hJRD1QTlAwQzAxIF9VSUQ9MApkZXYuYWNwaV9zeXNyZXNvdXJjZS4zLiVwYXJl bnQ6IGFjcGkwCmRldi5hY3BpX3RpbWVyLjAuJWRlc2M6IDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0 NU1IegpkZXYuYWNwaV90aW1lci4wLiVkcml2ZXI6IGFjcGlfdGltZXIKZGV2LmFjcGlfdGltZXIu MC4lbG9jYXRpb246IHVua25vd24KZGV2LmFjcGlfdGltZXIuMC4lcG5waW5mbzogdW5rbm93bgpk ZXYuYWNwaV90aW1lci4wLiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay4wLiVkZXNjOiBBQ1BJ IFBDSSBMaW5rIExOSzEKZGV2LnBjaV9saW5rLjAuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9s aW5rLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MTksxCmRldi5wY2lfbGluay4wLiVw bnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD0xCmRldi5wY2lfbGluay4wLiVwYXJlbnQ6IGFjcGkw CmRldi5wY2lfbGluay4xLiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOSzIKZGV2LnBjaV9saW5rLjEu JWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjEuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8u UENJMC5MTksyCmRldi5wY2lfbGluay4xLiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD0yCmRl di5wY2lfbGluay4xLiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay4yLiVkZXNjOiBBQ1BJIFBD SSBMaW5rIExOSzMKZGV2LnBjaV9saW5rLjIuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5r LjIuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MTkszCmRldi5wY2lfbGluay4yLiVwbnBp bmZvOiBfSElEPVBOUDBDMEYgX1VJRD0zCmRldi5wY2lfbGluay4yLiVwYXJlbnQ6IGFjcGkwCmRl di5wY2lfbGluay4zLiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOSzQKZGV2LnBjaV9saW5rLjMuJWRy aXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjMuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJ MC5MTks0CmRldi5wY2lfbGluay4zLiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD00CmRldi5w Y2lfbGluay4zLiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay40LiVkZXNjOiBBQ1BJIFBDSSBM aW5rIExOSzUKZGV2LnBjaV9saW5rLjQuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjQu JWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MTks1CmRldi5wY2lfbGluay40LiVwbnBpbmZv OiBfSElEPVBOUDBDMEYgX1VJRD01CmRldi5wY2lfbGluay40LiVwYXJlbnQ6IGFjcGkwCmRldi5w Y2lfbGluay41LiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOSzYKZGV2LnBjaV9saW5rLjUuJWRyaXZl cjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjUuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5M Tks2CmRldi5wY2lfbGluay41LiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD02CmRldi5wY2lf bGluay41LiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay42LiVkZXNjOiBBQ1BJIFBDSSBMaW5r IExOSzcKZGV2LnBjaV9saW5rLjYuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjYuJWxv Y2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MTks3CmRldi5wY2lfbGluay42LiVwbnBpbmZvOiBf SElEPVBOUDBDMEYgX1VJRD03CmRldi5wY2lfbGluay42LiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lf bGluay43LiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOSzgKZGV2LnBjaV9saW5rLjcuJWRyaXZlcjog cGNpX2xpbmsKZGV2LnBjaV9saW5rLjcuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MTks4 CmRldi5wY2lfbGluay43LiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD04CmRldi5wY2lfbGlu ay43LiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay44LiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExQ MlAKZGV2LnBjaV9saW5rLjguJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjguJWxvY2F0 aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MUDJQCmRldi5wY2lfbGluay44LiVwbnBpbmZvOiBfSElE PVBOUDBDMEYgX1VJRD05CmRldi5wY2lfbGluay44LiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGlu ay45LiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExVQkEKZGV2LnBjaV9saW5rLjkuJWRyaXZlcjogcGNp X2xpbmsKZGV2LnBjaV9saW5rLjkuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MVUJBCmRl di5wY2lfbGluay45LiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD0xMApkZXYucGNpX2xpbmsu OS4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMTAuJWRlc2M6IEFDUEkgUENJIExpbmsgTE1B QwpkZXYucGNpX2xpbmsuMTAuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjEwLiVsb2Nh dGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTE1BQwpkZXYucGNpX2xpbmsuMTAuJXBucGluZm86IF9I SUQ9UE5QMEMwRiBfVUlEPTExCmRldi5wY2lfbGluay4xMC4lcGFyZW50OiBhY3BpMApkZXYucGNp X2xpbmsuMTEuJWRlc2M6IEFDUEkgUENJIExpbmsgTE1DMQpkZXYucGNpX2xpbmsuMTEuJWRyaXZl cjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjExLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAu TE1DMQpkZXYucGNpX2xpbmsuMTEuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTEyCmRldi5w Y2lfbGluay4xMS4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMTIuJWRlc2M6IEFDUEkgUENJ IExpbmsgTEFaQQpkZXYucGNpX2xpbmsuMTIuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5r LjEyLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTEFaQQpkZXYucGNpX2xpbmsuMTIuJXBu cGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTEzCmRldi5wY2lfbGluay4xMi4lcGFyZW50OiBhY3Bp MApkZXYucGNpX2xpbmsuMTMuJWRlc2M6IEFDUEkgUENJIExpbmsgTFBNVQpkZXYucGNpX2xpbmsu MTMuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjEzLiVsb2NhdGlvbjogaGFuZGxlPVxf U0JfLlBDSTAuTFBNVQpkZXYucGNpX2xpbmsuMTMuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlE PTE0CmRldi5wY2lfbGluay4xMy4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMTQuJWRlc2M6 IEFDUEkgUENJIExpbmsgTFNNQgpkZXYucGNpX2xpbmsuMTQuJWRyaXZlcjogcGNpX2xpbmsKZGV2 LnBjaV9saW5rLjE0LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTFNNQgpkZXYucGNpX2xp bmsuMTQuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTE1CmRldi5wY2lfbGluay4xNC4lcGFy ZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMTUuJWRlc2M6IEFDUEkgUENJIExpbmsgTFVCMgpkZXYu cGNpX2xpbmsuMTUuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjE1LiVsb2NhdGlvbjog aGFuZGxlPVxfU0JfLlBDSTAuTFVCMgpkZXYucGNpX2xpbmsuMTUuJXBucGluZm86IF9ISUQ9UE5Q MEMwRiBfVUlEPTE2CmRldi5wY2lfbGluay4xNS4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsu MTYuJWRlc2M6IEFDUEkgUENJIExpbmsgTElERQpkZXYucGNpX2xpbmsuMTYuJWRyaXZlcjogcGNp X2xpbmsKZGV2LnBjaV9saW5rLjE2LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTElERQpk ZXYucGNpX2xpbmsuMTYuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTE3CmRldi5wY2lfbGlu ay4xNi4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMTcuJWRlc2M6IEFDUEkgUENJIExpbmsg TFNJRApkZXYucGNpX2xpbmsuMTcuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjE3LiVs b2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTFNJRApkZXYucGNpX2xpbmsuMTcuJXBucGluZm86 IF9ISUQ9UE5QMEMwRiBfVUlEPTE4CmRldi5wY2lfbGluay4xNy4lcGFyZW50OiBhY3BpMApkZXYu cGNpX2xpbmsuMTguJWRlc2M6IEFDUEkgUENJIExpbmsgTEZJRApkZXYucGNpX2xpbmsuMTguJWRy aXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjE4LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBD STAuTEZJRApkZXYucGNpX2xpbmsuMTguJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTE5CmRl di5wY2lfbGluay4xOC4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMTkuJWRlc2M6IEFDUEkg UENJIExpbmsgTFNBMgpkZXYucGNpX2xpbmsuMTkuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9s aW5rLjE5LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTFNBMgpkZXYucGNpX2xpbmsuMTku JXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTIwCmRldi5wY2lfbGluay4xOS4lcGFyZW50OiBh Y3BpMApkZXYucGNpX2xpbmsuMjAuJWRlc2M6IEFDUEkgUENJIExpbmsgQVBDMQpkZXYucGNpX2xp bmsuMjAuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjIwLiVsb2NhdGlvbjogaGFuZGxl PVxfU0JfLlBDSTAuQVBDMQpkZXYucGNpX2xpbmsuMjAuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBf VUlEPTIxCmRldi5wY2lfbGluay4yMC4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMjEuJWRl c2M6IEFDUEkgUENJIExpbmsgQVBDMgpkZXYucGNpX2xpbmsuMjEuJWRyaXZlcjogcGNpX2xpbmsK ZGV2LnBjaV9saW5rLjIxLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBDMgpkZXYucGNp X2xpbmsuMjEuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTIyCmRldi5wY2lfbGluay4yMS4l cGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMjIuJWRlc2M6IEFDUEkgUENJIExpbmsgQVBDMwpk ZXYucGNpX2xpbmsuMjIuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjIyLiVsb2NhdGlv bjogaGFuZGxlPVxfU0JfLlBDSTAuQVBDMwpkZXYucGNpX2xpbmsuMjIuJXBucGluZm86IF9ISUQ9 UE5QMEMwRiBfVUlEPTIzCmRldi5wY2lfbGluay4yMi4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xp bmsuMjMuJWRlc2M6IEFDUEkgUENJIExpbmsgQVBDNApkZXYucGNpX2xpbmsuMjMuJWRyaXZlcjog cGNpX2xpbmsKZGV2LnBjaV9saW5rLjIzLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBD NApkZXYucGNpX2xpbmsuMjMuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTI0CmRldi5wY2lf bGluay4yMy4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMjQuJWRlc2M6IEFDUEkgUENJIExp bmsgQVBDNQpkZXYucGNpX2xpbmsuMjQuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjI0 LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBDNQpkZXYucGNpX2xpbmsuMjQuJXBucGlu Zm86IF9ISUQ9UE5QMEMwRiBfVUlEPTI1CmRldi5wY2lfbGluay4yNC4lcGFyZW50OiBhY3BpMApk ZXYucGNpX2xpbmsuMjUuJWRlc2M6IEFDUEkgUENJIExpbmsgQVBDNgpkZXYucGNpX2xpbmsuMjUu JWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjI1LiVsb2NhdGlvbjogaGFuZGxlPVxfU0Jf LlBDSTAuQVBDNgpkZXYucGNpX2xpbmsuMjUuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTI2 CmRldi5wY2lfbGluay4yNS4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMjYuJWRlc2M6IEFD UEkgUENJIExpbmsgQVBDNwpkZXYucGNpX2xpbmsuMjYuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBj aV9saW5rLjI2LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBDNwpkZXYucGNpX2xpbmsu MjYuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTI3CmRldi5wY2lfbGluay4yNi4lcGFyZW50 OiBhY3BpMApkZXYucGNpX2xpbmsuMjcuJWRlc2M6IEFDUEkgUENJIExpbmsgQVBDOApkZXYucGNp X2xpbmsuMjcuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjI3LiVsb2NhdGlvbjogaGFu ZGxlPVxfU0JfLlBDSTAuQVBDOApkZXYucGNpX2xpbmsuMjcuJXBucGluZm86IF9ISUQ9UE5QMEMw RiBfVUlEPTI4CmRldi5wY2lfbGluay4yNy4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMjgu JWRlc2M6IEFDUEkgUENJIExpbmsgQVBDRgpkZXYucGNpX2xpbmsuMjguJWRyaXZlcjogcGNpX2xp bmsKZGV2LnBjaV9saW5rLjI4LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBDRgpkZXYu cGNpX2xpbmsuMjguJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTI5CmRldi5wY2lfbGluay4y OC4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMjkuJWRlc2M6IEFDUEkgUENJIExpbmsgQVBD SApkZXYucGNpX2xpbmsuMjkuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjI5LiVsb2Nh dGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBDSApkZXYucGNpX2xpbmsuMjkuJXBucGluZm86IF9I SUQ9UE5QMEMwRiBfVUlEPTMwCmRldi5wY2lfbGluay4yOS4lcGFyZW50OiBhY3BpMApkZXYucGNp X2xpbmsuMzAuJWRlc2M6IEFDUEkgUENJIExpbmsgQU1DMQpkZXYucGNpX2xpbmsuMzAuJWRyaXZl cjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjMwLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAu QU1DMQpkZXYucGNpX2xpbmsuMzAuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTMxCmRldi5w Y2lfbGluay4zMC4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMzEuJWRlc2M6IEFDUEkgUENJ IExpbmsgQVBNVQpkZXYucGNpX2xpbmsuMzEuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5r LjMxLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBNVQpkZXYucGNpX2xpbmsuMzEuJXBu cGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTMyCmRldi5wY2lfbGluay4zMS4lcGFyZW50OiBhY3Bp MApkZXYucGNpX2xpbmsuMzIuJWRlc2M6IEFDUEkgUENJIExpbmsgQUFaQQpkZXYucGNpX2xpbmsu MzIuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjMyLiVsb2NhdGlvbjogaGFuZGxlPVxf U0JfLlBDSTAuQUFaQQpkZXYucGNpX2xpbmsuMzIuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlE PTMzCmRldi5wY2lfbGluay4zMi4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMzMuJWRlc2M6 IEFDUEkgUENJIExpbmsgQVBDUwpkZXYucGNpX2xpbmsuMzMuJWRyaXZlcjogcGNpX2xpbmsKZGV2 LnBjaV9saW5rLjMzLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBDUwpkZXYucGNpX2xp bmsuMzMuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTM0CmRldi5wY2lfbGluay4zMy4lcGFy ZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMzQuJWRlc2M6IEFDUEkgUENJIExpbmsgQVBDTApkZXYu cGNpX2xpbmsuMzQuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjM0LiVsb2NhdGlvbjog aGFuZGxlPVxfU0JfLlBDSTAuQVBDTApkZXYucGNpX2xpbmsuMzQuJXBucGluZm86IF9ISUQ9UE5Q MEMwRiBfVUlEPTM1CmRldi5wY2lfbGluay4zNC4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsu MzUuJWRlc2M6IEFDUEkgUENJIExpbmsgQVBDTQpkZXYucGNpX2xpbmsuMzUuJWRyaXZlcjogcGNp X2xpbmsKZGV2LnBjaV9saW5rLjM1LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBDTQpk ZXYucGNpX2xpbmsuMzUuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTM2CmRldi5wY2lfbGlu ay4zNS4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMzYuJWRlc2M6IEFDUEkgUENJIExpbmsg QVBDWgpkZXYucGNpX2xpbmsuMzYuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjM2LiVs b2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBDWgpkZXYucGNpX2xpbmsuMzYuJXBucGluZm86 IF9ISUQ9UE5QMEMwRiBfVUlEPTM3CmRldi5wY2lfbGluay4zNi4lcGFyZW50OiBhY3BpMApkZXYu cGNpX2xpbmsuMzcuJWRlc2M6IEFDUEkgUENJIExpbmsgQVBTSQpkZXYucGNpX2xpbmsuMzcuJWRy aXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjM3LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBD STAuQVBTSQpkZXYucGNpX2xpbmsuMzcuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTM4CmRl di5wY2lfbGluay4zNy4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMzguJWRlc2M6IEFDUEkg UENJIExpbmsgQVBTSgpkZXYucGNpX2xpbmsuMzguJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9s aW5rLjM4LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQVBTSgpkZXYucGNpX2xpbmsuMzgu JXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTM5CmRldi5wY2lfbGluay4zOC4lcGFyZW50OiBh Y3BpMApkZXYucGNpX2xpbmsuMzkuJWRlc2M6IEFDUEkgUENJIExpbmsgQVNBMgpkZXYucGNpX2xp bmsuMzkuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjM5LiVsb2NhdGlvbjogaGFuZGxl PVxfU0JfLlBDSTAuQVNBMgpkZXYucGNpX2xpbmsuMzkuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBf VUlEPTQwCmRldi5wY2lfbGluay4zOS4lcGFyZW50OiBhY3BpMApkZXYuY3B1LjAuJWRlc2M6IEFD UEkgQ1BVCmRldi5jcHUuMC4lZHJpdmVyOiBjcHUKZGV2LmNwdS4wLiVsb2NhdGlvbjogaGFuZGxl PVxfUFJfLkNQVTAKZGV2LmNwdS4wLiVwbnBpbmZvOiBfSElEPW5vbmUgX1VJRD0wCmRldi5jcHUu MC4lcGFyZW50OiBhY3BpMApkZXYuY3B1LjAuZnJlcTogMjQwMApkZXYuY3B1LjAuZnJlcV9sZXZl bHM6IDI0MDAvODkwMDAgMjIwMC83NTY1MiAyMDAwLzYzNTg1IDE4MDAvNTI3NDAgMTAwMC8yNDYy MApkZXYuY3B1LjAuY3hfc3VwcG9ydGVkOiBDMS8wCmRldi5jcHUuMC5jeF9sb3dlc3Q6IEMxCmRl di5jcHUuMC5jeF91c2FnZTogMTAwLjAwJQpkZXYuY3B1LjEuJWRlc2M6IEFDUEkgQ1BVCmRldi5j cHUuMS4lZHJpdmVyOiBjcHUKZGV2LmNwdS4xLiVsb2NhdGlvbjogaGFuZGxlPVxfUFJfLkNQVTEK ZGV2LmNwdS4xLiVwbnBpbmZvOiBfSElEPW5vbmUgX1VJRD0wCmRldi5jcHUuMS4lcGFyZW50OiBh Y3BpMApkZXYuY3B1LjEuY3hfc3VwcG9ydGVkOiBDMS8wCmRldi5jcHUuMS5jeF9sb3dlc3Q6IEMx CmRldi5jcHUuMS5jeF91c2FnZTogMTAwLjAwJQpkZXYuYWNwaV9wZXJmLjAuJWRyaXZlcjogYWNw aV9wZXJmCmRldi5hY3BpX3BlcmYuMC4lcGFyZW50OiBjcHUwCmRldi5hY3BpX3BlcmYuMS4lZHJp dmVyOiBhY3BpX3BlcmYKZGV2LmFjcGlfcGVyZi4xLiVwYXJlbnQ6IGNwdTEKZGV2LnBvd2Vybm93 LjAuJWRlc2M6IFBvd2VyTm93ISBLOApkZXYucG93ZXJub3cuMC4lZHJpdmVyOiBwb3dlcm5vdwpk ZXYucG93ZXJub3cuMC4lcGFyZW50OiBjcHUwCmRldi5wb3dlcm5vdy4wLmZyZXFfc2V0dGluZ3M6 IDI0MDAvODkwMDAgMjIwMC83NTY1MiAyMDAwLzYzNTg1IDE4MDAvNTI3NDAgMTAwMC8yNDYyMApk ZXYucG93ZXJub3cuMS4lZGVzYzogUG93ZXJOb3chIEs4CmRldi5wb3dlcm5vdy4xLiVkcml2ZXI6 IHBvd2Vybm93CmRldi5wb3dlcm5vdy4xLiVwYXJlbnQ6IGNwdTEKZGV2LnBvd2Vybm93LjEuZnJl cV9zZXR0aW5nczogMjQwMC84OTAwMCAyMjAwLzc1NjUyIDIwMDAvNjM1ODUgMTgwMC81Mjc0MCAx MDAwLzI0NjIwCmRldi5jcHVmcmVxLjAuJWRyaXZlcjogY3B1ZnJlcQpkZXYuY3B1ZnJlcS4wLiVw YXJlbnQ6IGNwdTAKZGV2LmNwdWZyZXEuMS4lZHJpdmVyOiBjcHVmcmVxCmRldi5jcHVmcmVxLjEu JXBhcmVudDogY3B1MQpkZXYuYWNwaV9idXR0b24uMC4lZGVzYzogUG93ZXIgQnV0dG9uCmRldi5h Y3BpX2J1dHRvbi4wLiVkcml2ZXI6IGFjcGlfYnV0dG9uCmRldi5hY3BpX2J1dHRvbi4wLiVsb2Nh dGlvbjogaGFuZGxlPVxfU0JfLlBXUkIKZGV2LmFjcGlfYnV0dG9uLjAuJXBucGluZm86IF9ISUQ9 UE5QMEMwQyBfVUlEPTAKZGV2LmFjcGlfYnV0dG9uLjAuJXBhcmVudDogYWNwaTAKZGV2LnBjaWIu MC4lZGVzYzogQUNQSSBIb3N0LVBDSSBicmlkZ2UKZGV2LnBjaWIuMC4lZHJpdmVyOiBwY2liCmRl di5wY2liLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMApkZXYucGNpYi4wLiVwbnBpbmZv OiBfSElEPVBOUDBBMDggX1VJRD0xCmRldi5wY2liLjAuJXBhcmVudDogYWNwaTAKZGV2LnBjaWIu MS4lZGVzYzogQUNQSSBQQ0ktUENJIGJyaWRnZQpkZXYucGNpYi4xLiVkcml2ZXI6IHBjaWIKZGV2 LnBjaWIuMS4lbG9jYXRpb246IHNsb3Q9NCBmdW5jdGlvbj0wIGhhbmRsZT1cX1NCXy5QQ0kwLlhW UkEKZGV2LnBjaWIuMS4lcG5waW5mbzogdmVuZG9yPTB4MTBkZSBkZXZpY2U9MHgwMmZiIHN1YnZl bmRvcj0weDEwZGUgc3ViZGV2aWNlPTB4MDAwMCBjbGFzcz0weDA2MDQwMApkZXYucGNpYi4xLiVw YXJlbnQ6IHBjaTAKZGV2LnBjaWIuMS53YWtlOiAwCmRldi5wY2liLjIuJWRlc2M6IEFDUEkgUENJ LVBDSSBicmlkZ2UKZGV2LnBjaWIuMi4lZHJpdmVyOiBwY2liCmRldi5wY2liLjIuJWxvY2F0aW9u OiBzbG90PTE0IGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuSFVCMApkZXYucGNpYi4yLiVw bnBpbmZvOiB2ZW5kb3I9MHgxMGRlIGRldmljZT0weDAzNzAgc3VidmVuZG9yPTB4MTBkZSBzdWJk ZXZpY2U9MHhjYjg0IGNsYXNzPTB4MDYwNDAxCmRldi5wY2liLjIuJXBhcmVudDogcGNpMApkZXYu cGNpYi4yLndha2U6IDAKZGV2LnBjaWIuMy4lZGVzYzogQUNQSSBQQ0ktUENJIGJyaWRnZQpkZXYu cGNpYi4zLiVkcml2ZXI6IHBjaWIKZGV2LnBjaWIuMy4lbG9jYXRpb246IHNsb3Q9MjIgZnVuY3Rp b249MCBoYW5kbGU9XF9TQl8uUENJMC5YVlIxCmRldi5wY2liLjMuJXBucGluZm86IHZlbmRvcj0w eDEwZGUgZGV2aWNlPTB4MDM3NSBzdWJ2ZW5kb3I9MHgxMGRlIHN1YmRldmljZT0weDAwMDAgY2xh c3M9MHgwNjA0MDAKZGV2LnBjaWIuMy4lcGFyZW50OiBwY2kwCmRldi5wY2liLjMud2FrZTogMApk ZXYucGNpLjAuJWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjAuJWRyaXZlcjogcGNpCmRldi5w Y2kuMC4lcGFyZW50OiBwY2liMApkZXYucGNpLjEuJWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNp LjEuJWRyaXZlcjogcGNpCmRldi5wY2kuMS4lcGFyZW50OiBwY2liMQpkZXYucGNpLjEud2FrZTog MApkZXYucGNpLjIuJWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjIuJWRyaXZlcjogcGNpCmRl di5wY2kuMi4lcGFyZW50OiBwY2liMgpkZXYucGNpLjIud2FrZTogMApkZXYucGNpLjMuJWRlc2M6 IEFDUEkgUENJIGJ1cwpkZXYucGNpLjMuJWRyaXZlcjogcGNpCmRldi5wY2kuMy4lcGFyZW50OiBw Y2liMwpkZXYucGNpLjMud2FrZTogMApkZXYudmdhcGNpLjAuJWRlc2M6IFZHQS1jb21wYXRpYmxl IGRpc3BsYXkKZGV2LnZnYXBjaS4wLiVkcml2ZXI6IHZnYXBjaQpkZXYudmdhcGNpLjAuJWxvY2F0 aW9uOiBzbG90PTAgZnVuY3Rpb249MApkZXYudmdhcGNpLjAuJXBucGluZm86IHZlbmRvcj0weDEw ZGUgZGV2aWNlPTB4MDQwMiBzdWJ2ZW5kb3I9MHgwMDAwIHN1YmRldmljZT0weDAwMDAgY2xhc3M9 MHgwMzAwMDAKZGV2LnZnYXBjaS4wLiVwYXJlbnQ6IHBjaTEKZGV2LmlzYWIuMC4lZGVzYzogUENJ LUlTQSBicmlkZ2UKZGV2LmlzYWIuMC4lZHJpdmVyOiBpc2FiCmRldi5pc2FiLjAuJWxvY2F0aW9u OiBzbG90PTkgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5MRUcwCmRldi5pc2FiLjAuJXBu cGluZm86IHZlbmRvcj0weDEwZGUgZGV2aWNlPTB4MDM2MCBzdWJ2ZW5kb3I9MHgxMDQzIHN1YmRl dmljZT0weGNiODQgY2xhc3M9MHgwNjAxMDAKZGV2LmlzYWIuMC4lcGFyZW50OiBwY2kwCmRldi5p c2EuMC4lZGVzYzogSVNBIGJ1cwpkZXYuaXNhLjAuJWRyaXZlcjogaXNhCmRldi5pc2EuMC4lcGFy ZW50OiBpc2FiMApkZXYub2hjaS4wLiVkZXNjOiBPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxl cgpkZXYub2hjaS4wLiVkcml2ZXI6IG9oY2kKZGV2Lm9oY2kuMC4lbG9jYXRpb246IHNsb3Q9MTAg ZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5VU0IwCmRldi5vaGNpLjAuJXBucGluZm86IHZl bmRvcj0weDEwZGUgZGV2aWNlPTB4MDM2YyBzdWJ2ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weGNi ODQgY2xhc3M9MHgwYzAzMTAKZGV2Lm9oY2kuMC4lcGFyZW50OiBwY2kwCmRldi5vaGNpLjAud2Fr ZTogMApkZXYudXNiLjAuJWRlc2M6IE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyCmRldi51 c2IuMC4lZHJpdmVyOiB1c2IKZGV2LnVzYi4wLiVwYXJlbnQ6IG9oY2kwCmRldi51c2IuMS4lZGVz YzogRUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyCmRldi51c2IuMS4lZHJpdmVyOiB1 c2IKZGV2LnVzYi4xLiVwYXJlbnQ6IGVoY2kwCmRldi51aHViLjAuJWRlc2M6IG5WaWRpYSBPSENJ IHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQpkZXYudWh1Yi4wLiVk cml2ZXI6IHVodWIKZGV2LnVodWIuMC4lcGFyZW50OiB1c2IwCmRldi51aHViLjEuJWRlc2M6IG5W aWRpYSBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMQpkZXYu dWh1Yi4xLiVkcml2ZXI6IHVodWIKZGV2LnVodWIuMS4lcGFyZW50OiB1c2IxCmRldi5laGNpLjAu JWRlc2M6IEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcgpkZXYuZWhjaS4wLiVkcml2 ZXI6IGVoY2kKZGV2LmVoY2kuMC4lbG9jYXRpb246IHNsb3Q9MTAgZnVuY3Rpb249MSBoYW5kbGU9 XF9TQl8uUENJMC5VU0IyCmRldi5laGNpLjAuJXBucGluZm86IHZlbmRvcj0weDEwZGUgZGV2aWNl PTB4MDM2ZCBzdWJ2ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weGNiODQgY2xhc3M9MHgwYzAzMjAK ZGV2LmVoY2kuMC4lcGFyZW50OiBwY2kwCmRldi5laGNpLjAud2FrZTogMApkZXYudWdlbi4wLiVk ZXNjOiB2ZW5kb3IgMHgwYmRhIFJUTDgxODdfV2lyZWxlc3MsIGNsYXNzIDAvMCwgcmV2IDIuMDAv MS4wMCwgYWRkciAyCmRldi51Z2VuLjAuJWRyaXZlcjogdWdlbgpkZXYudWdlbi4wLiVsb2NhdGlv bjogcG9ydD04CmRldi51Z2VuLjAuJXBucGluZm86IHZlbmRvcj0weDBiZGEgcHJvZHVjdD0weDgx ODcgZGV2Y2xhc3M9MHgwMCBkZXZzdWJjbGFzcz0weDAwIHJlbGVhc2U9MHgwMTAwIHNlcm51bT0i MDAxNUFGMERFNTBEIgpkZXYudWdlbi4wLiVwYXJlbnQ6IHVodWIxCmRldi5hdGFwY2kuMC4lZGVz YzogblZpZGlhIG5Gb3JjZSBNQ1A1NSBVRE1BMTMzIGNvbnRyb2xsZXIKZGV2LmF0YXBjaS4wLiVk cml2ZXI6IGF0YXBjaQpkZXYuYXRhcGNpLjAuJWxvY2F0aW9uOiBzbG90PTEyIGZ1bmN0aW9uPTAg aGFuZGxlPVxfU0JfLlBDSTAuSURFMApkZXYuYXRhcGNpLjAuJXBucGluZm86IHZlbmRvcj0weDEw ZGUgZGV2aWNlPTB4MDM2ZSBzdWJ2ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weGNiODQgY2xhc3M9 MHgwMTAxOGEKZGV2LmF0YXBjaS4wLiVwYXJlbnQ6IHBjaTAKZGV2LmF0YXBjaS4xLiVkZXNjOiBu VmlkaWEgbkZvcmNlIE1DUDU1IFNBVEEzMDAgY29udHJvbGxlcgpkZXYuYXRhcGNpLjEuJWRyaXZl cjogYXRhcGNpCmRldi5hdGFwY2kuMS4lbG9jYXRpb246IHNsb3Q9MTMgZnVuY3Rpb249MCBoYW5k bGU9XF9TQl8uUENJMC5TQVQxCmRldi5hdGFwY2kuMS4lcG5waW5mbzogdmVuZG9yPTB4MTBkZSBk ZXZpY2U9MHgwMzdmIHN1YnZlbmRvcj0weDEwNDMgc3ViZGV2aWNlPTB4Y2I4NCBjbGFzcz0weDAx MDE4NQpkZXYuYXRhcGNpLjEuJXBhcmVudDogcGNpMApkZXYuYXRhcGNpLjIuJWRlc2M6IG5WaWRp YSBuRm9yY2UgTUNQNTUgU0FUQTMwMCBjb250cm9sbGVyCmRldi5hdGFwY2kuMi4lZHJpdmVyOiBh dGFwY2kKZGV2LmF0YXBjaS4yLiVsb2NhdGlvbjogc2xvdD0xMyBmdW5jdGlvbj0xIGhhbmRsZT1c X1NCXy5QQ0kwLlNBVDIKZGV2LmF0YXBjaS4yLiVwbnBpbmZvOiB2ZW5kb3I9MHgxMGRlIGRldmlj ZT0weDAzN2Ygc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZpY2U9MHhjYjg0IGNsYXNzPTB4MDEwMTg1 CmRldi5hdGFwY2kuMi4lcGFyZW50OiBwY2kwCmRldi5hdGFwY2kuMy4lZGVzYzogblZpZGlhIG5G b3JjZSBNQ1A1NSBTQVRBMzAwIGNvbnRyb2xsZXIKZGV2LmF0YXBjaS4zLiVkcml2ZXI6IGF0YXBj aQpkZXYuYXRhcGNpLjMuJWxvY2F0aW9uOiBzbG90PTEzIGZ1bmN0aW9uPTIgaGFuZGxlPVxfU0Jf LlBDSTAuU0FUMwpkZXYuYXRhcGNpLjMuJXBucGluZm86IHZlbmRvcj0weDEwZGUgZGV2aWNlPTB4 MDM3ZiBzdWJ2ZW5kb3I9MHgxMDQzIHN1YmRldmljZT0weGNiODQgY2xhc3M9MHgwMTAxODUKZGV2 LmF0YXBjaS4zLiVwYXJlbnQ6IHBjaTAKZGV2LmF0YXBjaS40LiVkZXNjOiBIaWdoUG9pbnQgSFBU MzcwIFVETUExMDAgY29udHJvbGxlcgpkZXYuYXRhcGNpLjQuJWRyaXZlcjogYXRhcGNpCmRldi5h dGFwY2kuNC4lbG9jYXRpb246IHNsb3Q9NyBmdW5jdGlvbj0wCmRldi5hdGFwY2kuNC4lcG5waW5m bzogdmVuZG9yPTB4MTEwMyBkZXZpY2U9MHgwMDA0IHN1YnZlbmRvcj0weDExMDMgc3ViZGV2aWNl PTB4MDAwNSBjbGFzcz0weDAxODAwMApkZXYuYXRhcGNpLjQuJXBhcmVudDogcGNpMgpkZXYuYXRh cGNpLjUuJWRlc2M6IFNpSSAzMTMyIFNBVEEzMDAgY29udHJvbGxlcgpkZXYuYXRhcGNpLjUuJWRy aXZlcjogYXRhcGNpCmRldi5hdGFwY2kuNS4lbG9jYXRpb246IHNsb3Q9MCBmdW5jdGlvbj0wCmRl di5hdGFwY2kuNS4lcG5waW5mbzogdmVuZG9yPTB4MTA5NSBkZXZpY2U9MHgzMTMyIHN1YnZlbmRv cj0weDEwNDMgc3ViZGV2aWNlPTB4ODE5ZiBjbGFzcz0weDAxODAwMApkZXYuYXRhcGNpLjUuJXBh cmVudDogcGNpMwpkZXYuYXRhLjAuJWRlc2M6IEFUQSBjaGFubmVsIDAKZGV2LmF0YS4wLiVkcml2 ZXI6IGF0YQpkZXYuYXRhLjAuJXBhcmVudDogYXRhcGNpMApkZXYuYXRhLjEuJWRlc2M6IEFUQSBj aGFubmVsIDEKZGV2LmF0YS4xLiVkcml2ZXI6IGF0YQpkZXYuYXRhLjEuJXBhcmVudDogYXRhcGNp MApkZXYuYXRhLjIuJWRlc2M6IEFUQSBjaGFubmVsIDAKZGV2LmF0YS4yLiVkcml2ZXI6IGF0YQpk ZXYuYXRhLjIuJXBhcmVudDogYXRhcGNpMQpkZXYuYXRhLjMuJWRlc2M6IEFUQSBjaGFubmVsIDEK ZGV2LmF0YS4zLiVkcml2ZXI6IGF0YQpkZXYuYXRhLjMuJXBhcmVudDogYXRhcGNpMQpkZXYuYXRh LjQuJWRlc2M6IEFUQSBjaGFubmVsIDAKZGV2LmF0YS40LiVkcml2ZXI6IGF0YQpkZXYuYXRhLjQu JXBhcmVudDogYXRhcGNpMgpkZXYuYXRhLjUuJWRlc2M6IEFUQSBjaGFubmVsIDEKZGV2LmF0YS41 LiVkcml2ZXI6IGF0YQpkZXYuYXRhLjUuJXBhcmVudDogYXRhcGNpMgpkZXYuYXRhLjYuJWRlc2M6 IEFUQSBjaGFubmVsIDAKZGV2LmF0YS42LiVkcml2ZXI6IGF0YQpkZXYuYXRhLjYuJXBhcmVudDog YXRhcGNpMwpkZXYuYXRhLjcuJWRlc2M6IEFUQSBjaGFubmVsIDEKZGV2LmF0YS43LiVkcml2ZXI6 IGF0YQpkZXYuYXRhLjcuJXBhcmVudDogYXRhcGNpMwpkZXYuYXRhLjguJWRlc2M6IEFUQSBjaGFu bmVsIDAKZGV2LmF0YS44LiVkcml2ZXI6IGF0YQpkZXYuYXRhLjguJXBhcmVudDogYXRhcGNpNApk ZXYuYXRhLjkuJWRlc2M6IEFUQSBjaGFubmVsIDEKZGV2LmF0YS45LiVkcml2ZXI6IGF0YQpkZXYu YXRhLjkuJXBhcmVudDogYXRhcGNpNApkZXYuYXRhLjEwLiVkZXNjOiBBVEEgY2hhbm5lbCAwCmRl di5hdGEuMTAuJWRyaXZlcjogYXRhCmRldi5hdGEuMTAuJXBhcmVudDogYXRhcGNpNQpkZXYuYXRh LjExLiVkZXNjOiBBVEEgY2hhbm5lbCAxCmRldi5hdGEuMTEuJWRyaXZlcjogYXRhCmRldi5hdGEu MTEuJXBhcmVudDogYXRhcGNpNQpkZXYubmZlLjAuJWRlc2M6IE5WSURJQSBuRm9yY2UgTUNQNTUg TmV0d29ya2luZyBBZGFwdGVyCmRldi5uZmUuMC4lZHJpdmVyOiBuZmUKZGV2Lm5mZS4wLiVsb2Nh dGlvbjogc2xvdD0xNiBmdW5jdGlvbj0wIGhhbmRsZT1cX1NCXy5QQ0kwLk1NQUMKZGV2Lm5mZS4w LiVwbnBpbmZvOiB2ZW5kb3I9MHgxMGRlIGRldmljZT0weDAzNzMgc3VidmVuZG9yPTB4MTA0MyBz dWJkZXZpY2U9MHhjYjg0IGNsYXNzPTB4MDY4MDAwCmRldi5uZmUuMC4lcGFyZW50OiBwY2kwCmRl di5uZmUuMC5wcm9jZXNzX2xpbWl0OiAxOTIKZGV2Lm5mZS4wLndha2U6IDAKZGV2Lm1paWJ1cy4w LiVkZXNjOiBNSUkgYnVzCmRldi5taWlidXMuMC4lZHJpdmVyOiBtaWlidXMKZGV2Lm1paWJ1cy4w LiVwYXJlbnQ6IG5mZTAKZGV2LmUxMDAwcGh5LjAuJWRlc2M6IE1hcnZlbGwgODhFMTExNiBHaWdh Yml0IFBIWQpkZXYuZTEwMDBwaHkuMC4lZHJpdmVyOiBlMTAwMHBoeQpkZXYuZTEwMDBwaHkuMC4l bG9jYXRpb246IHBoeW5vPTEKZGV2LmUxMDAwcGh5LjAuJXBucGluZm86IG91aT0weDUwNDMgbW9k ZWw9MHgyMSByZXY9MHgxCmRldi5lMTAwMHBoeS4wLiVwYXJlbnQ6IG1paWJ1czAKZGV2Lmhvc3Ri LjAuJWRlc2M6IEhvc3QgdG8gUENJIGJyaWRnZQpkZXYuaG9zdGIuMC4lZHJpdmVyOiBob3N0Ygpk ZXYuaG9zdGIuMC4lbG9jYXRpb246IHNsb3Q9MjQgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJ MC5LODAwCmRldi5ob3N0Yi4wLiVwbnBpbmZvOiB2ZW5kb3I9MHgxMDIyIGRldmljZT0weDExMDAg c3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwIGNsYXNzPTB4MDYwMDAwCmRldi5ob3N0 Yi4wLiVwYXJlbnQ6IHBjaTAKZGV2Lmhvc3RiLjEuJWRlc2M6IEhvc3QgdG8gUENJIGJyaWRnZQpk ZXYuaG9zdGIuMS4lZHJpdmVyOiBob3N0YgpkZXYuaG9zdGIuMS4lbG9jYXRpb246IHNsb3Q9MjQg ZnVuY3Rpb249MSBoYW5kbGU9XF9TQl8uUENJMC5LODAxCmRldi5ob3N0Yi4xLiVwbnBpbmZvOiB2 ZW5kb3I9MHgxMDIyIGRldmljZT0weDExMDEgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgw MDAwIGNsYXNzPTB4MDYwMDAwCmRldi5ob3N0Yi4xLiVwYXJlbnQ6IHBjaTAKZGV2Lmhvc3RiLjIu JWRlc2M6IEhvc3QgdG8gUENJIGJyaWRnZQpkZXYuaG9zdGIuMi4lZHJpdmVyOiBob3N0YgpkZXYu aG9zdGIuMi4lbG9jYXRpb246IHNsb3Q9MjQgZnVuY3Rpb249MiBoYW5kbGU9XF9TQl8uUENJMC5L ODAyCmRldi5ob3N0Yi4yLiVwbnBpbmZvOiB2ZW5kb3I9MHgxMDIyIGRldmljZT0weDExMDIgc3Vi dmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwIGNsYXNzPTB4MDYwMDAwCmRldi5ob3N0Yi4y LiVwYXJlbnQ6IHBjaTAKZGV2Lmhvc3RiLjMuJWRlc2M6IEhvc3QgdG8gUENJIGJyaWRnZQpkZXYu aG9zdGIuMy4lZHJpdmVyOiBob3N0YgpkZXYuaG9zdGIuMy4lbG9jYXRpb246IHNsb3Q9MjQgZnVu Y3Rpb249MwpkZXYuaG9zdGIuMy4lcG5waW5mbzogdmVuZG9yPTB4MTAyMiBkZXZpY2U9MHgxMTAz IHN1YnZlbmRvcj0weDAwMDAgc3ViZGV2aWNlPTB4MDAwMCBjbGFzcz0weDA2MDAwMApkZXYuaG9z dGIuMy4lcGFyZW50OiBwY2kwCmRldi5hY3BpX3R6LjAuJWRlc2M6IFRoZXJtYWwgWm9uZQpkZXYu YWNwaV90ei4wLiVkcml2ZXI6IGFjcGlfdHoKZGV2LmFjcGlfdHouMC4lbG9jYXRpb246IGhhbmRs ZT1cX1RaXy5USFJNCmRldi5hY3BpX3R6LjAuJXBucGluZm86IF9ISUQ9bm9uZSBfVUlEPTAKZGV2 LmFjcGlfdHouMC4lcGFyZW50OiBhY3BpMApkZXYuYXRwaWMuMC4lZGVzYzogQVQgaW50ZXJydXB0 IGNvbnRyb2xsZXIKZGV2LmF0cGljLjAuJWRyaXZlcjogYXRwaWMKZGV2LmF0cGljLjAuJWxvY2F0 aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MRUcwLlBJQ18KZGV2LmF0cGljLjAuJXBucGluZm86IF9I SUQ9UE5QMDAwMCBfVUlEPTAKZGV2LmF0cGljLjAuJXBhcmVudDogYWNwaTAKZGV2LmF0ZG1hLjAu JWRlc2M6IEFUIERNQSBjb250cm9sbGVyCmRldi5hdGRtYS4wLiVkcml2ZXI6IGF0ZG1hCmRldi5h dGRtYS4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTEVHMC5ETUExCmRldi5hdGRtYS4w LiVwbnBpbmZvOiBfSElEPVBOUDAyMDAgX1VJRD0wCmRldi5hdGRtYS4wLiVwYXJlbnQ6IGFjcGkw CmRldi5hdHRpbWVyLjAuJWRlc2M6IEFUIHRpbWVyCmRldi5hdHRpbWVyLjAuJWRyaXZlcjogYXR0 aW1lcgpkZXYuYXR0aW1lci4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuTEVHMC5UTVJf CmRldi5hdHRpbWVyLjAuJXBucGluZm86IF9ISUQ9UE5QMDEwMCBfVUlEPTAKZGV2LmF0dGltZXIu MC4lcGFyZW50OiBhY3BpMApkZXYuYXR0aW1lci4xLiVkZXNjOiBBVCByZWFsdGltZSBjbG9jawpk ZXYuYXR0aW1lci4xLiVkcml2ZXI6IGF0dGltZXIKZGV2LmF0dGltZXIuMS4lbG9jYXRpb246IGhh bmRsZT1cX1NCXy5QQ0kwLkxFRzAuUlRDXwpkZXYuYXR0aW1lci4xLiVwbnBpbmZvOiBfSElEPVBO UDBCMDAgX1VJRD0wCmRldi5hdHRpbWVyLjEuJXBhcmVudDogYWNwaTAKZGV2Lm5weGlzYS4wLiVk ZXNjOiBMZWdhY3kgSVNBIGNvcHJvY2Vzc29yIHN1cHBvcnQKZGV2Lm5weGlzYS4wLiVkcml2ZXI6 IG5weGlzYQpkZXYubnB4aXNhLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MRUcwLkNP UFIKZGV2Lm5weGlzYS4wLiVwbnBpbmZvOiBfSElEPVBOUDBDMDQgX1VJRD0wCmRldi5ucHhpc2Eu MC4lcGFyZW50OiBhY3BpMApkZXYuZmRjLjAuJWRlc2M6IEVuaGFuY2VkIGZsb3BweSBjb250cm9s bGVyCmRldi5mZGMuMC4lZHJpdmVyOiBmZGMKZGV2LmZkYy4wLiVsb2NhdGlvbjogaGFuZGxlPVxf U0JfLlBDSTAuTEVHMC5GREMwCmRldi5mZGMuMC4lcG5waW5mbzogX0hJRD1QTlAwNzAwIF9VSUQ9 MApkZXYuZmRjLjAuJXBhcmVudDogYWNwaTAKZGV2LmZkLjAuJWRlc2M6IDE0NDAtS0IgMy41IiBk cml2ZQpkZXYuZmQuMC4lZHJpdmVyOiBmZApkZXYuZmQuMC4lcGFyZW50OiBmZGMwCmRldi5zaW8u MC4lZGVzYzogMTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQKZGV2LnNpby4wLiVkcml2ZXI6IHNp bwpkZXYuc2lvLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5MRUcwLlVBUjEKZGV2LnNp by4wLiVwbnBpbmZvOiBfSElEPVBOUDA1MDEgX1VJRD0xCmRldi5zaW8uMC4lcGFyZW50OiBhY3Bp MApkZXYuc2lvLjAud2FrZTogMApkZXYuYXRrYmRjLjAuJWRlc2M6IEtleWJvYXJkIGNvbnRyb2xs ZXIgKGk4MDQyKQpkZXYuYXRrYmRjLjAuJWRyaXZlcjogYXRrYmRjCmRldi5hdGtiZGMuMC4lbG9j YXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLkxFRzAuUFMySwpkZXYuYXRrYmRjLjAuJXBucGluZm86 IF9ISUQ9UE5QMDMwMyBfVUlEPTAKZGV2LmF0a2JkYy4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hdGti ZGMuMC53YWtlOiAwCmRldi5hdGtiZC4wLiVkZXNjOiBBVCBLZXlib2FyZApkZXYuYXRrYmQuMC4l ZHJpdmVyOiBhdGtiZApkZXYuYXRrYmQuMC4lcGFyZW50OiBhdGtiZGMwCmRldi5hcGljLjAuJWRl c2M6IEFQSUMgcmVzb3VyY2VzCmRldi5hcGljLjAuJWRyaXZlcjogYXBpYwpkZXYuYXBpYy4wLiVw YXJlbnQ6IG5leHVzMApkZXYucG10aW1lci4wLiVkcml2ZXI6IHBtdGltZXIKZGV2LnBtdGltZXIu MC4lcGFyZW50OiBpc2EwCmRldi5vcm0uMC4lZGVzYzogSVNBIE9wdGlvbiBST01zCmRldi5vcm0u MC4lZHJpdmVyOiBvcm0KZGV2Lm9ybS4wLiVwbnBpbmZvOiBwbnBpZD1PUk0wMDAwCmRldi5vcm0u MC4lcGFyZW50OiBpc2EwCmRldi5zYy4wLiVkZXNjOiBTeXN0ZW0gY29uc29sZQpkZXYuc2MuMC4l ZHJpdmVyOiBzYwpkZXYuc2MuMC4lcGFyZW50OiBpc2EwCmRldi52Z2EuMC4lZGVzYzogR2VuZXJp YyBJU0EgVkdBCmRldi52Z2EuMC4lZHJpdmVyOiB2Z2EKZGV2LnZnYS4wLiVwYXJlbnQ6IGlzYTAK ZGV2LnVtcy4wLiVkZXNjOiBMb2dpdGVjaCBVU0IgUmVjZWl2ZXIsIGNsYXNzIDAvMCwgcmV2IDEu MTAvMTUuMDAsIGFkZHIgMgpkZXYudW1zLjAuJWRyaXZlcjogdW1zCmRldi51bXMuMC4lbG9jYXRp b246IHBvcnQ9MSBpbnRlcmZhY2U9MApkZXYudW1zLjAuJXBucGluZm86IHZlbmRvcj0weDA0NmQg cHJvZHVjdD0weGM1MDggZGV2Y2xhc3M9MHgwMCBkZXZzdWJjbGFzcz0weDAwIHJlbGVhc2U9MHgx NTAwIHNlcm51bT0iIiBpbnRjbGFzcz0weDAzIGludHN1YmNsYXNzPTB4MDEKZGV2LnVtcy4wLiVw YXJlbnQ6IHVodWIwCmRldi5hY2QuMC4lZGVzYzogSEwtRFQtU1QgRFZEUkFNIEdTQS00MTIwQi9B MTE1CmRldi5hY2QuMC4lZHJpdmVyOiBhY2QKZGV2LmFjZC4wLiVwYXJlbnQ6IGF0YTAKZGV2LmFj ZC4xLiVkZXNjOiBITC1EVC1TVERWRC1ST00gR0RSODE2M0IvMEwyMwpkZXYuYWNkLjEuJWRyaXZl cjogYWNkCmRldi5hY2QuMS4lcGFyZW50OiBhdGEwCmRldi5hZC40LiVkZXNjOiBTVDM1MDA2MzBB Uy8zLkFBSwpkZXYuYWQuNC4lZHJpdmVyOiBhZApkZXYuYWQuNC4lcGFyZW50OiBhdGEyCmRldi5h ZC42LiVkZXNjOiBNYXh0b3IgNkwzMDBTMC9CQUNFMUcyMApkZXYuYWQuNi4lZHJpdmVyOiBhZApk ZXYuYWQuNi4lcGFyZW50OiBhdGEzCmRldi5hZC4xNi4lZGVzYzogU1QzODAwMTFBLzMuMDYKZGV2 LmFkLjE2LiVkcml2ZXI6IGFkCmRldi5hZC4xNi4lcGFyZW50OiBhdGE4CmRldi5hZC4xOC4lZGVz YzogU1QzODAwMTFBLzMuMDYKZGV2LmFkLjE4LiVkcml2ZXI6IGFkCmRldi5hZC4xOC4lcGFyZW50 OiBhdGE5CmRldi51bWFzcy4wLiVkZXNjOiBLaW5nc3RvbiBEYXRhVHJhdmVsZXIgMi4wLCBjbGFz cyAwLzAsIHJldiAyLjAwLzEuMTAsIGFkZHIgMwpkZXYudW1hc3MuMC4lZHJpdmVyOiB1bWFzcwpk ZXYudW1hc3MuMC4lbG9jYXRpb246IHBvcnQ9MiBpbnRlcmZhY2U9MApkZXYudW1hc3MuMC4lcG5w aW5mbzogdmVuZG9yPTB4MTNmZSBwcm9kdWN0PTB4MWQwMCBkZXZjbGFzcz0weDAwIGRldnN1YmNs YXNzPTB4MDAgcmVsZWFzZT0weDAxMTAgc2VybnVtPSI1QjczMDhBRkM4REQiIGludGNsYXNzPTB4 MDggaW50c3ViY2xhc3M9MHgwNgpkZXYudW1hc3MuMC4lcGFyZW50OiB1aHViMQo= ------=_Part_10924_26135791.1188583134351 Content-Type: text/plain; name="uname.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="uname.txt"; filename="uname.txt"; filename="uname.txt"; filename="uname.txt"; filename="uname.txt" X-Attachment-Id: f_f60n3u8i RnJlZUJTRCBleHhvZHVzLmZlZGF5a2luLmhlcmUgNy4wLUNVUlJFTlQtMjAwNzA4IEZyZWVCU0Qg Ny4wLUNVUlJFTlQtMjAwNzA4ICMzOiBGcmkgQXVnIDMxIDIxOjMzOjIwIEJSVCAyMDA3ICAgICBy b290QGV4eG9kdXMuZmVkYXlraW4uaGVyZTovdXNyL3NyYy9zeXMvaTM4Ni9jb21waWxlL0xJT1VY ICBpMzg2Cg== ------=_Part_10924_26135791.1188583134351-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 18:30:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7747816A418 for ; Fri, 31 Aug 2007 18:30:48 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from alnrmhc15.comcast.net (alnrmhc15.comcast.net [204.127.225.95]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECDA13C4B6 for ; Fri, 31 Aug 2007 18:30:47 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from _hostname_ (c-66-31-37-31.hsd1.ma.comcast.net[66.31.37.31]) by comcast.net (alnrmhc15) with SMTP id <20070831183030b1500a3ovee>; Fri, 31 Aug 2007 18:30:30 +0000 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Fri, 31 Aug 2007 14:30:29 -0400 From: "Craig Rodrigues" Date: Fri, 31 Aug 2007 14:30:29 -0400 To: Mario Ferreira Message-ID: <20070831183029.GA18008@crodrigues.org> References: <683701cf0708310509l40c14a78te54e6608c2f7d9ed@mail.gmail.com> <683701cf0708311058l5e80198fr432abb06d8128924@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <683701cf0708311058l5e80198fr432abb06d8128924@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: nfe(4) not working on asus m2n32sli-deluxe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 18:30:48 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 31, 2007 at 02:58:54PM -0300, Mario Ferreira wrote: > asus m2n32sli-deluxe wifi edition but I had some issues: > > 1) on board wlan adapter RTL8187_Wireless not supported > 2) on board lan adapter NForce 590 SLI MCP does not work > > The lack of support for RTL8187_Wireless is not a problem for now. > However, the NForce 590 SLI MCP Gigabit adapter is an issue. Hi, I just bought the exact same motherboard as you, and it works great. I do not have any issues with the Gigabit adapter. nfe0@pci0:16:0: class=0x068000 card=0xcb841043 chip=0x037310de rev=0xa2 hdr=0x00 nfe0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1b:fc:62:b3:68 media: Ethernet autoselect (100baseTX ) status: active There are some BIOS settings related to "LAN Cable Status" that you might want to fiddle with. If you have further problems, you can follow up with me directly. -- Craig Rodrigues rodrigc@crodrigues.org --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot.txt" nfe0: port 0xb400-0xb407 mem 0xfe02a000-0xfe02afff,0xfe029000-0xfe0290ff,0xfe028000-0xfe02800f irq 23 at device 16.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 nfe0: Reserved 0x100 bytes for rid 0x18 type 3 at 0xfe029000 nfe0: Reserved 0x10 bytes for rid 0x1c type 3 at 0xfe028000 nfe0: attempting to allocate 8 MSI-X vectors (8 supported) nfe0: using IRQs 256-263 for MSI-X nfe0: Using 8 MSIX messages miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:1b:fc:62:b3:68 nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe0: [MPSAFE] nfe0: [FILTER] nfe1: port 0xb000-0xb007 mem 0xfe027000-0xfe027fff,0xfe026000-0xfe0260ff,0xfe025000-0xfe02500f irq 20 at device 17.0 on pci0 nfe1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe027000 nfe1: Reserved 0x100 bytes for rid 0x18 type 3 at 0xfe026000 nfe1: Reserved 0x10 bytes for rid 0x1c type 3 at 0xfe025000 nfe1: attempting to allocate 8 MSI-X vectors (8 supported) nfe1: using IRQs 264-271 for MSI-X nfe1: Using 8 MSIX messages miibus1: on nfe1 e1000phy1: PHY 1 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe1: bpf attached nfe1: Ethernet address: 00:1b:fc:62:be:56 nfe1: [MPSAFE] nfe1: [FILTER] nfe1: [MPSAFE] nfe1: [FILTER] nfe1: [MPSAFE] nfe1: [FILTER] nfe1: [MPSAFE] nfe1: [FILTER] nfe1: [MPSAFE] nfe1: [FILTER] nfe1: [MPSAFE] nfe1: [FILTER] nfe1: [MPSAFE] nfe1: [FILTER] nfe1: [MPSAFE] nfe1: [FILTER] --Kj7319i9nmIyA2yE-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 19:13:42 2007 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 995C216A417 for ; Fri, 31 Aug 2007 19:13:42 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (penna-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 5DFFD13C4A5 for ; Fri, 31 Aug 2007 19:13:42 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.1/8.14.1) with ESMTP id l7VJFF4k098879 for ; Fri, 31 Aug 2007 15:15:15 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Current@FreeBSD.org In-Reply-To: <1188430624.1077.21.camel@shumai.marcuscom.com> References: <1188430624.1077.21.camel@shumai.marcuscom.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eWrMAA/vYwkugKaQIHmt" Organization: FreeBSD, Inc. Date: Fri, 31 Aug 2007 15:13:36 -0400 Message-Id: <1188587616.11028.31.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: Subject: Re: VT_WAITACTIVE leads to unkillable processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 19:13:42 -0000 --=-eWrMAA/vYwkugKaQIHmt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-08-29 at 19:37 -0400, Joe Marcus Clarke wrote: > flz and I are working on a port of ConsoleKit to FreeBSD. ConsoleKit is > a framework for tracking local users (i.e. users sitting at a machine) > and their sessions. =20 >=20 > Since it tracks local users and their consoles, it makes generous use of > consio. One of the things it does is get a list of the total number of > available consoles (i.e. vtys) and starts a thread for each one to check > when the console becomes active. To do this, each thread invokes the > VT_WAITACTIVE ioctl, and sits in waitvt until its vty becomes active. > This works quite well. >=20 > Where things break down is when the ConsoleKit daemon is stopped. When > the daemon receives a signal, it immediately jumps to 100% of the CPU > and claims to be in waitvt. It will not die unless you reboot the > machine, or get lucky with the debugger. >=20 > Below is a link to a small sample program that will reproduce this > behavior. Simply compile the program, and run it from a vty other than > 3 (ttyv2). Then try a control+C, and the problem will appear instantly. >=20 > I've been testing 7.0-CURRENT #104: Thu Aug 16 16:54:28 EDT 2007 with > ULE, but I have a report from flz that the same loop is observed on > -STABLE with 4BSD. When I ran the test on -STABLE, my box immediately > panicked, but I did not have dumps setup. >=20 > Yes, this is a, "doctor it hurts when I do this" kind of thing; however, > since this does not happen on Linux, I'm wondering if the kernel portion > of the VT_WAITACTIVE ioctl can be modified not to cause this tight loop > (or panic)? >=20 > WARNING: This running this program will either cause instance on mostly > unstoppable CPU load on your machine or panic it. >=20 > http://www.marcuscom.com/downloads/vty.c >=20 > gcc -o vty vty.c > (switch to ttyv0) > ./vty=20 I did some more research into the kernel code, and I found I can interrupt and terminate the process if I register signal handlers (simple do-nothing signal handlers) because they populate ps_sigintr. When ps_sigintr contains the right signal, tsleep() will return EINTR instead of ERESTART. This seems to be working fine. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-eWrMAA/vYwkugKaQIHmt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG2Ghfb2iPiv4Uz4cRAui9AKCN7sxr44hAFSczBBDe8iA72LRWBgCgnzoV NEHODJDf5o+JXtdcLWnkUfs= =eUvE -----END PGP SIGNATURE----- --=-eWrMAA/vYwkugKaQIHmt-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 19:20:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B60316A418 for ; Fri, 31 Aug 2007 19:20:28 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 96B1D13C46B for ; Fri, 31 Aug 2007 19:20:27 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id l7VJK3vd044382 ; Fri, 31 Aug 2007 21:20:03 +0200 (CEST) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id l7VJK22O019068 ; Fri, 31 Aug 2007 21:20:02 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id l7VJK1Ap019063; Fri, 31 Aug 2007 21:20:01 +0200 (MEST) (envelope-from arno) To: freebsd-current@freebsd.org References: <46BFE620.8070906@fusiongol.com> <20070813091802.GB3078@stud.ntnu.no> <20070823071056.GA50852@obiwan.tataz.chchile.org> <20070825082812.GE50852@obiwan.tataz.chchile.org> <46D77FC8.1050709@fusiongol.com> From: "Arno J. Klaassen" Date: 31 Aug 2007 21:20:01 +0200 In-Reply-To: <46D77FC8.1050709@fusiongol.com> Message-ID: Lines: 39 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.166]); Fri, 31 Aug 2007 21:20:04 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.7/4111/Fri Aug 31 17:25:39 2007 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 46D869E3.007 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: Nathan Butcher Subject: Re: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 19:20:28 -0000 Hi, I changed motherboard : -SMP-kernel iso UP -bge netowork iso msk -same disks -same cables -same card - just one TX4 card (this is a Tyan with only 2 PCI-X slots (and since at delivery I discovered that the on-board Adaptec was missing ;((( I need one slot for a 29320 card)) Quickly testing with a 3-disk graid3 scratch and things seem far better : I only get occasionaly : ad16: FAILURE - out of memory in start ad16: FAILURE - out of memory in start ad14: FAILURE - out of memory in start ad18: FAILURE - out of memory in start ad18: FAILURE - out of memory in start ad18: FAILURE - out of memory in start but for now they seem harmless. There is a PR talking about interaction between the BIOS and the [s]ata-driver being problematic (wrt PCI-settings) ( http://www.freebsd.org/cgi/query-pr.cgi?pr=103435 ) And some kind of allocation seems problematic: on the former MB pci_alloc_map() gave an error, now it is an occassionaly failing ata_alloc_request(). Arno From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 19:26:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CCEA16A417; Fri, 31 Aug 2007 19:26:38 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id BE4C713C46C; Fri, 31 Aug 2007 19:26:37 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from home.alpha-tierchen.de (port-212-202-42-154.dynamic.qsc.de [212.202.42.154]) by mail.liberty-hosting.de (Postfix) with ESMTP id D4FFF3E942E; Fri, 31 Aug 2007 21:00:56 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id A290B45067; Fri, 31 Aug 2007 20:58:57 +0200 (CEST) Received: from 192.168.1.2 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Fri, 31 Aug 2007 20:58:57 +0200 (CEST) Message-ID: <53082.192.168.1.2.1188586737.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <20070831142032.GD79097@dragon.NUXI.org> References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> <20070831142032.GD79097@dragon.NUXI.org> Date: Fri, 31 Aug 2007 20:58:57 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: obrien@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 19:26:38 -0000 Björn König wrote: >> Intel's first Pentium 4 with SSE3 is called "prescott". We could use >> "venice" analogously to represent SSE3-capable Athlon64 CPUs. David O'Brien wrote: > No! NO! AMD core names does not mean the same as Intel ones. > Look folks, there is a clear way for this - the CPUID family. Pentium 4 processors before Prescott belong to family 15. Prescott and recent Pentium 4 processors still use 15 as family ID. If I understand you correctly then there should be no distinction between these processors because they have the same family ID, but there is one in bsd.cpu.mk because of SSE3. Björn From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 19:43:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AD1316A41B for ; Fri, 31 Aug 2007 19:43:15 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id EBBA513C48A for ; Fri, 31 Aug 2007 19:43:14 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7VJgjVH004801; Fri, 31 Aug 2007 12:42:45 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7VJgiHm004800; Fri, 31 Aug 2007 12:42:44 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 12:42:44 -0700 From: "David O'Brien" To: =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= Message-ID: <20070831194244.GA4565@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= , freebsd-current@freebsd.org References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <50152.2001:6f8:101e:0:20e:cff:fe6d:6adb.1188416964.squirrel@webmail.alpha-tierchen.de> <20070831142032.GD79097@dragon.NUXI.org> <53082.192.168.1.2.1188586737.squirrel@webmail.alpha-tierchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53082.192.168.1.2.1188586737.squirrel@webmail.alpha-tierchen.de> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: Adding k9 and k10 to bsd.cpu.mk 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: Fri, 31 Aug 2007 19:43:15 -0000 On Fri, Aug 31, 2007 at 08:58:57PM +0200, Bjrn Knig wrote: > Björn König wrote: > >> Intel's first Pentium 4 with SSE3 is called "prescott". We could use > >> "venice" analogously to represent SSE3-capable Athlon64 CPUs. > > David O'Brien wrote: > > No! NO! AMD core names does not mean the same as Intel ones. > > Look folks, there is a clear way for this - the CPUID family. > > Pentium 4 processors before Prescott belong to family 15. Prescott and > recent Pentium 4 processors still use 15 as family ID. If I understand you > correctly then there should be no distinction between these processors > because they have the same family ID, but there is one in bsd.cpu.mk > because of SSE3. Not quite. CPUID Family is vendor-specific. The Family value for Intel cannot be compared with the meaning of Family for AMD (or VIA). AMD bumps the CPUID Family value for each new major architecture generation. I have no idea what's the meaning of "Family" by Intel. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 19:44:01 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7836A16A420; Fri, 31 Aug 2007 19:44:01 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCA613C4CA; Fri, 31 Aug 2007 19:44:01 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l7VJhdMv004827; Fri, 31 Aug 2007 12:43:39 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l7VJhdHj004826; Fri, 31 Aug 2007 12:43:39 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 12:43:39 -0700 From: "David O'Brien" To: Kris Kennaway Message-ID: <20070831194338.GB4565@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Kris Kennaway , Stefan Lambrev , Roman Divacky , pluknet , freebsd-current@freebsd.org, Bj?rn K?nig References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <46D66F83.2050208@moneybookers.com> <20070831142458.GE79097@dragon.NUXI.org> <46D82649.20804@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D82649.20804@FreeBSD.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@FreeBSD.org, Roman Divacky , pluknet , Bj?rn K?nig , Stefan Lambrev Subject: Re: Adding k9 and k10 to bsd.cpu.mk 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: Fri, 31 Aug 2007 19:44:01 -0000 On Fri, Aug 31, 2007 at 04:31:37PM +0200, Kris Kennaway wrote: > David O'Brien wrote: > >On Thu, Aug 30, 2007 at 10:19:31AM +0300, Stefan Lambrev wrote: > >>k8-sse3, opteron-sse3, athlon64-sse3 > > > >Yeah, I guess I should add those... though bsd.cpu.mk was architected > >with some amount of guessing of what might in the future be useful. > > > >Is there anything in /usr/src or /usr/ports that actually does anything > >with the information? > > > > . elif ${CPUTYPE} == "prescott" > > MACHINE_CPU = sse3 sse2 sse i686 mmx i586 i486 i386 > > > > . elif ${CPUTYPE} == "nocona" > > MACHINE_CPU = sse3 > > > >for instance. > > MACHINE_CPU is supposed to be a complete list of relevant CPU features Yes I know. :-) > that ports can use to enable e.g. SSE2 asm optimizations if the CPUTYPE > supports it. A number of them exist that do this. I don't supose you know a few of them off the top of your head. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 19:54:52 2007 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 0704416A418 for ; Fri, 31 Aug 2007 19:54:52 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE8D13C45D for ; Fri, 31 Aug 2007 19:54:51 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (dyn-62-56-105-44.dslaccess.co.uk [62.56.105.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 986AA3000D for ; Fri, 31 Aug 2007 20:50:15 +0100 (BST) Message-ID: <46D8719A.1070109@cran.org.uk> Date: Fri, 31 Aug 2007 20:52:58 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: current@freebsd.org References: <46D83351.9000407@cran.org.uk> In-Reply-To: <46D83351.9000407@cran.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: High interrupt load on VIA C3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 19:54:52 -0000 Bruce Cran wrote: > I recently upgraded to 7-CURRENT on my VIA EPIA router, and have found > that there's a constant interrupt load of around 15%. My dmesg > reports the CPU as: > > CPU: VIA C3 Nehemiah+RNG+AES (533.36-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x698 Stepping = 8 > > Features=0x381b93f > > real memory = 132055040 (125 MB) > avail memory = 119701504 (114 MB) > > uname -a: > FreeBSD router.draftnet 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Fri Aug 31 > 07:04:22 BST 2007 > brucec@router.draftnet:/usr/obj/usr/src/sys/ROUTER i386 > > The first few lines of top -S are: > last pid: 1394; load averages: 0.08, 0.12, > 0.21 > up 0+01:59:10 16:13:59 > 57 processes: 3 running, 39 sleeping, 15 waiting > CPU states: 3.1% user, 0.0% nice, 4.8% system, 17.0% interrupt, > 75.1% idle > Mem: 7360K Active, 6116K Inact, 12M Wired, 48K Cache, 9504K Buf, 90M Free > Swap: 2048M Total, 2048M Free > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 11 root 1 171 ki31 0K 8K RUN 100:01 81.98% idle > 12 root 1 -32 - 0K 8K WAIT 12:31 7.96% swi4: > clock sio > 1394 brucec 1 46 0 3512K 1744K RUN 0:01 4.98% top > 586 root 1 44 0 5016K 2516K RUN 2:39 0.00% ppp > 1044 root 1 44 0 3176K 980K select 0:51 0.00% powerd > 28 root 1 -68 - 0K 8K WAIT 0:45 0.00% irq11: > vr0 dc3 > 30 root 1 -68 - 0K 8K WAIT 0:32 0.00% irq12: dc1 > > While there's a high interrupt load, vmstat -i doesn't show anything > wrong: > > interrupt total rate > irq0: clk 718003 99 > irq4: sio0 897 0 > irq5: dc0 31 0 > irq8: rtc 919064 127 > irq10: dc2 uhci0+ 31 0 > irq11: vr0 dc3 63548 8 > irq12: dc1 62120 8 > irq14: ata0 1555 0 > irq15: ata1 581 0 > Total 1765830 245 > > I had thought of using hwpmc to find out what was happening, but > unfortunately VIA CPUs aren't supported yet. Is there another way I > can find out what's going on? This appears to be an issue with powerd/cpufreq - disabling powerd reduces the interrupt load to a couple of percent at most, and the clock interrupt task now only accumulates CPU time very slowly (previously it was using 7% CPU all the time). -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 20:22:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CDEE16A419; Fri, 31 Aug 2007 20:22:02 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 9023213C458; Fri, 31 Aug 2007 20:22:00 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46D87866.4010109@FreeBSD.org> Date: Fri, 31 Aug 2007 22:21:58 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: obrien@freebsd.org, Kris Kennaway , Stefan Lambrev , Roman Divacky , pluknet , freebsd-current@freebsd.org, Bj?rn K?nig References: <-3502020561049594852@unknownmsgid> <20070829191310.GA50909@freebsd.org> <46D66F83.2050208@moneybookers.com> <20070831142458.GE79097@dragon.NUXI.org> <46D82649.20804@FreeBSD.org> <20070831194338.GB4565@dragon.NUXI.org> In-Reply-To: <20070831194338.GB4565@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 20:22:02 -0000 David O'Brien wrote: > On Fri, Aug 31, 2007 at 04:31:37PM +0200, Kris Kennaway wrote: >> David O'Brien wrote: >>> On Thu, Aug 30, 2007 at 10:19:31AM +0300, Stefan Lambrev wrote: >>>> k8-sse3, opteron-sse3, athlon64-sse3 >>> Yeah, I guess I should add those... though bsd.cpu.mk was architected >>> with some amount of guessing of what might in the future be useful. >>> >>> Is there anything in /usr/src or /usr/ports that actually does anything >>> with the information? >>> >>> . elif ${CPUTYPE} == "prescott" >>> MACHINE_CPU = sse3 sse2 sse i686 mmx i586 i486 i386 >>> >>> . elif ${CPUTYPE} == "nocona" >>> MACHINE_CPU = sse3 >>> >>> for instance. >> MACHINE_CPU is supposed to be a complete list of relevant CPU features > > Yes I know. :-) > >> that ports can use to enable e.g. SSE2 asm optimizations if the CPUTYPE >> supports it. A number of them exist that do this. > > I don't supose you know a few of them off the top of your head. > Sorry, no. grep for it in ports. Kris From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 21:56:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 683A516A41B for ; Fri, 31 Aug 2007 21:56:13 +0000 (UTC) (envelope-from mmathias@mmathias.com) Received: from mx-03.sil.at (mx-03.sil.at [86.59.22.50]) by mx1.freebsd.org (Postfix) with ESMTP id F397B13C46C for ; Fri, 31 Aug 2007 21:56:12 +0000 (UTC) (envelope-from mmathias@mmathias.com) Received: from vie-213-235-226-123.dsl.sil.at ([213.235.226.123] helo=[192.168.0.131]) by mx-03.sil.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IRE1Y-0004YY-Cq for freebsd-current@freebsd.org; Fri, 31 Aug 2007 23:27:28 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <46BFE620.8070906@fusiongol.com> <20070813091802.GB3078@stud.ntnu.no> <20070823071056.GA50852@obiwan.tataz.chchile.org> <20070825082812.GE50852@obiwan.tataz.chchile.org> <46D77FC8.1050709@fusiongol.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Mathias_M=FCller?= Date: Fri, 31 Aug 2007 23:26:01 +0200 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.2) X-Scan-Signature: 5968b2a4a2f2723c2e0ee577191d9dd9 Subject: Re: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 21:56:13 -0000 Am 31.08.2007 um 21:20 schrieb Arno J. Klaassen: > Hi, > > I changed motherboard : > > -SMP-kernel iso UP > -bge netowork iso msk > > -same disks > -same cables > -same card > > - just one TX4 card (this is a Tyan with only 2 PCI-X slots > (and since at delivery I discovered that the on-board Adaptec > was missing ;((( I need one slot for a 29320 card)) > > Quickly testing with a 3-disk graid3 scratch and things seem > far better : > > I only get occasionaly : > > ad16: FAILURE - out of memory in start > ad16: FAILURE - out of memory in start > ad14: FAILURE - out of memory in start > ad18: FAILURE - out of memory in start > ad18: FAILURE - out of memory in start > ad18: FAILURE - out of memory in start > > but for now they seem harmless. > > There is a PR talking about interaction between > the BIOS and the [s]ata-driver being problematic (wrt PCI-settings) > ( http://www.freebsd.org/cgi/query-pr.cgi?pr=3D103435 ) > > And some kind of allocation seems problematic: > on the former MB pci_alloc_map() gave an error, now it is > an occassionaly failing ata_alloc_request(). > > Arno > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-=20 > unsubscribe@freebsd.org" Hello, I'm writing this message because I think that I am experiencing =20 similar problems. I am running 200708-current but I had the same =20 problems with 200706-current. My hardware: * Elitegroup K7S5A v3.1 * Duron 800 * 4x Maxtor DiamondMax 10 SATA * Promise SATA 300 TX4 * 400W power supply * and a Netgear gigabit NIC I have the four Maxtor HDs plugged into the Promise TX4. When I boot =20 the system that last 2 lines in dmesg say something like Aug 30 00:22:58 ebichu kernel: subdisk4: detached Aug 30 00:22:58 ebichu kernel: ad4: detached but without any other error messages. The disappearing HD is always a different one, so I don't think that =20 the HDs have a problem. I also checked the HDs' S.M.A.R.T. status and =20= all 4 have no errors. Sometimes two HDs disappear. It is possible to =20 attach the HDs again by using "atacontrol detach ata4;atacontrol =20 attach ata4" but as soon as I try to access data on the drive (for =20 example mount it) it disappears again. I have already changed mainboard, SATA controller (I tried a SiI3112 =20 and a SiI3124 based controller), the SATA cables and even the power =20 supply. As far as the HDs are concerned, they seem to work fine when =20 used in an external USB2 case. I can send a complete dmesg if you want, but the system is currently =20 turned off. I believe that this might be an issue with the ata driver. If so, =20 please tell me if I can be of assistance in finding the bug. I could =20 try different releases, but I am afraid my time is pretty limited. :/ Thank you all, - Mathias M=FCller From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 23:32:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E64216A417; Fri, 31 Aug 2007 23:32:25 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 043F513C46C; Fri, 31 Aug 2007 23:32:24 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7VNWAEk090263; Fri, 31 Aug 2007 20:32:10 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Fri, 31 Aug 2007 20:32:20 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <200708300859.13098.joao@matik.com.br> <53349.192.168.1.2.1188538732.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <53349.192.168.1.2.1188538732.squirrel@webmail.alpha-tierchen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708312032.21574.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Roman Divacky , pluknet , current@freebsd.org, =?iso-8859-1?q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 23:32:25 -0000 On Friday 31 August 2007 02:38:52 Bj=F6rn K=F6nig wrote: > JoaoBR wrote: > > but athlon64-x2 for S940 and athlon64-am2 for sse3 capable cpus would be > > kind of understandable for all > > [...] > > venice as said in another mail is not clear for all people and certainly > > it does not appear on the box or elsewhere > > I think the names "athlon64-x2" and "athlon64-am2" would be most confusing > and ambiguous, because the socket has nothing to do with the feature set > of the CPU. Athlon64 X2 CPUs are not only available for socket 940, but > also for AM2 and 939. There are SSE3 CPUs that fit into 940, AM2 and 939. > well, the x2 thing I wasn't thinking it through and you are right, what I= =20 meant to say that so far as I know all S939-X2 are SSE3 capable and rev-E a= t=20 least as all am2 are so eventually, athlon64-E would be more appropriate (with proper man make.c= onf=20 explanation) opterons are not easy but it is already kind of advanced cpu so could be=20 expected more knowledge from the user and that he 'eventually'=20 read /usr/share/examples/etc/make.conf ... or not (if there were something= =20 about sse3) but in any case opteron and additional opteron-E also would do= =20 it ... =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 23:32:25 2007 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 7E64216A417; Fri, 31 Aug 2007 23:32:25 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 043F513C46C; Fri, 31 Aug 2007 23:32:24 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7VNWAEk090263; Fri, 31 Aug 2007 20:32:10 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Fri, 31 Aug 2007 20:32:20 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <200708300859.13098.joao@matik.com.br> <53349.192.168.1.2.1188538732.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <53349.192.168.1.2.1188538732.squirrel@webmail.alpha-tierchen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708312032.21574.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Roman Divacky , pluknet , current@freebsd.org, =?iso-8859-1?q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 23:32:25 -0000 On Friday 31 August 2007 02:38:52 Bj=F6rn K=F6nig wrote: > JoaoBR wrote: > > but athlon64-x2 for S940 and athlon64-am2 for sse3 capable cpus would be > > kind of understandable for all > > [...] > > venice as said in another mail is not clear for all people and certainly > > it does not appear on the box or elsewhere > > I think the names "athlon64-x2" and "athlon64-am2" would be most confusing > and ambiguous, because the socket has nothing to do with the feature set > of the CPU. Athlon64 X2 CPUs are not only available for socket 940, but > also for AM2 and 939. There are SSE3 CPUs that fit into 940, AM2 and 939. > well, the x2 thing I wasn't thinking it through and you are right, what I= =20 meant to say that so far as I know all S939-X2 are SSE3 capable and rev-E a= t=20 least as all am2 are so eventually, athlon64-E would be more appropriate (with proper man make.c= onf=20 explanation) opterons are not easy but it is already kind of advanced cpu so could be=20 expected more knowledge from the user and that he 'eventually'=20 read /usr/share/examples/etc/make.conf ... or not (if there were something= =20 about sse3) but in any case opteron and additional opteron-E also would do= =20 it ... =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 23:39:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE8BB16A418 for ; Fri, 31 Aug 2007 23:39:29 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6645F13C459 for ; Fri, 31 Aug 2007 23:39:29 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7VNdV9J090670; Fri, 31 Aug 2007 20:39:32 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Fri, 31 Aug 2007 20:39:41 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <20070831142458.GE79097@dragon.NUXI.org> <46D82649.20804@FreeBSD.org> In-Reply-To: <46D82649.20804@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708312039.43262.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Bj?rn K?nig , pluknet , Stefan Lambrev , Roman Divacky Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 23:39:30 -0000 On Friday 31 August 2007 11:31:37 Kris Kennaway wrote: > > > > for instance. > > MACHINE_CPU is supposed to be a complete list of relevant CPU features > that ports can use to enable e.g. SSE2 asm optimizations if the CPUTYPE > supports it. A number of them exist that do this. > Sorry but I have some difficulties to understand how a port could enable CP= U=20 features if they are not enabled/recognized by the kernel =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Fri Aug 31 23:58:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DA3016A421; Fri, 31 Aug 2007 23:58:04 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8A83813C46A; Fri, 31 Aug 2007 23:58:03 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7VNvoMF092046; Fri, 31 Aug 2007 20:57:50 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org, obrien@freebsd.org Date: Fri, 31 Aug 2007 20:58:01 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <53082.192.168.1.2.1188586737.squirrel@webmail.alpha-tierchen.de> <20070831194244.GA4565@dragon.NUXI.org> In-Reply-To: <20070831194244.GA4565@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708312058.01966.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: =?iso-8859-1?q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2007 23:58:04 -0000 On Friday 31 August 2007 16:42:44 David O'Brien wrote: > On Fri, Aug 31, 2007 at 08:58:57PM +0200, Bjrn Knig wrote: > > Bj=F6rn K=F6nig wrote: > > >> Intel's first Pentium 4 with SSE3 is called "prescott". We could use > > >> "venice" analogously to represent SSE3-capable Athlon64 CPUs. > > > > David O'Brien wrote: > > > No! NO! AMD core names does not mean the same as Intel ones. > > > Look folks, there is a clear way for this - the CPUID family. > > > > Pentium 4 processors before Prescott belong to family 15. Prescott and > > recent Pentium 4 processors still use 15 as family ID. If I understand > > you correctly then there should be no distinction between these > > processors because they have the same family ID, but there is one in > > bsd.cpu.mk because of SSE3. > > Not quite. CPUID Family is vendor-specific. The Family value for Intel > cannot be compared with the meaning of Family for AMD (or VIA). > > AMD bumps the CPUID Family value for each new major architecture > generation. I have no idea what's the meaning of "Family" by Intel. well ... people 'kind of familiarly' with reading manuals and specs are already havi= ng=20 difficulties here so imagin an average user (unkndefspec) who likes to=20 optimize his kernel (his cpu's kernel of course :) )=20 so as far as there are a cpu options for a freebsd kernel they should be=20 understandable so it might be worse thinking well before doing (=3Dless sup= port=20 =3D less questions =3D less problemas) =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 00:07:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8C2F16A419; Sat, 1 Sep 2007 00:07:26 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5E213C4E1; Sat, 1 Sep 2007 00:07:26 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l8107B8s025362; Fri, 31 Aug 2007 17:07:11 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l8107ATI025361; Fri, 31 Aug 2007 17:07:10 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 17:07:10 -0700 From: "David O'Brien" To: JoaoBR Message-ID: <20070901000710.GA12223@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, JoaoBR , freebsd-current@freebsd.org, Roman Divacky , pluknet , =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= References: <-3502020561049594852@unknownmsgid> <200708300859.13098.joao@matik.com.br> <53349.192.168.1.2.1188538732.squirrel@webmail.alpha-tierchen.de> <200708312032.21574.joao@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200708312032.21574.joao@matik.com.br> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: Roman Divacky , freebsd-current@freebsd.org, pluknet , =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk 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: Sat, 01 Sep 2007 00:07:26 -0000 On Fri, Aug 31, 2007 at 08:32:20PM -0300, JoaoBR wrote: > On Friday 31 August 2007 02:38:52 Björn König wrote: > > JoaoBR wrote: > > > but athlon64-x2 for S940 and athlon64-am2 for sse3 capable cpus would be > > > kind of understandable for all > > > [...] > > > venice as said in another mail is not clear for all people and certainly > > > it does not appear on the box or elsewhere > > > > I think the names "athlon64-x2" and "athlon64-am2" would be most confusing > > and ambiguous, because the socket has nothing to do with the feature set > > of the CPU. Athlon64 X2 CPUs are not only available for socket 940, but > > also for AM2 and 939. There are SSE3 CPUs that fit into 940, AM2 and 939. > > > > well, the x2 thing I wasn't thinking it through and you are right, > what I meant to say that so far as I know all S939-X2 are SSE3 capable > and rev-E at least as all am2 are > > so eventually, athlon64-E would be more appropriate (with proper man Why? athlon64-E should apply to athlon64 rev's F & G? k8-sse3 seems best - with aliases for athlon64-sse3 and opteron-sse3. > opterons are not easy but it is already kind of advanced cpu so could be Why are Opteron's any harder? -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 00:20:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A65116A418; Sat, 1 Sep 2007 00:20:28 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0C37F13C45E; Sat, 1 Sep 2007 00:20:27 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l810KKME093867; Fri, 31 Aug 2007 21:20:20 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org, obrien@freebsd.org Date: Fri, 31 Aug 2007 21:20:30 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <200708312032.21574.joao@matik.com.br> <20070901000710.GA12223@dragon.NUXI.org> In-Reply-To: <20070901000710.GA12223@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708312120.31912.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Roman Divacky , pluknet , =?iso-8859-1?q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 00:20:28 -0000 On Friday 31 August 2007 21:07:10 David O'Brien wrote: > > > > well, the x2 thing I wasn't thinking it through and you are right, > > what I meant to say that so far as I know all S939-X2 are SSE3 capable > > and rev-E at least as all am2 are > > > > so eventually, athlon64-E would be more appropriate (with proper man > > Why? athlon64-E should apply to athlon64 rev's F & G? k8-sse3 seems > best - with aliases for athlon64-sse3 and opteron-sse3. > ok right but it is harder for an average kernel compiler to find the SSE3=20 feature instead of the cpu's revision but certainly it would be easy to suggest to consult sort of grep -i feat /var/run/dmesg.boot to see if or not in `man make.conf` or somewhere, what then makes it ok as = far=20 as it is well explained=20 > > opterons are not easy but it is already kind of advanced cpu so could be > > Why are Opteron's any harder? because all of them are 64bit but some older ones are not SSE3 capable, < 2= 50=20 I guess now but 252 is but not 100% sure =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 01:26:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B6C116A419; Sat, 1 Sep 2007 01:26:40 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 504EB13C461; Sat, 1 Sep 2007 01:26:40 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l811QILx098582; Fri, 31 Aug 2007 22:26:18 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Fri, 31 Aug 2007 22:26:25 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <20070901000710.GA12223@dragon.NUXI.org> <200708312120.31912.joao@matik.com.br> In-Reply-To: <200708312120.31912.joao@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708312226.26977.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Roman Divacky , pluknet , =?iso-8859-1?q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 01:26:41 -0000 On Friday 31 August 2007 21:20:30 JoaoBR wrote: > > > opterons are not easy but it is already kind of advanced cpu so could > > > be > > > > Why are Opteron's any harder? > > because all of them are 64bit but some older ones are not SSE3 capable, < > 250 I guess now but 252 is but not 100% sure so just a thought, I have no not-sse3 capable anymore so I could check but= =20 asking the gcc guys here ... what if I try to compile with -msse3 and it is not available, does it go=20 through or do I get invalid compile option and if it go through what may it= =20 cost? =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 01:37:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE9D616A417; Sat, 1 Sep 2007 01:37: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 BFF1113C45B; Sat, 1 Sep 2007 01:37:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id l811bYlZ012561; Fri, 31 Aug 2007 18:37:34 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id l811bYA1012560; Fri, 31 Aug 2007 18:37:34 -0700 (PDT) (envelope-from sgk) Date: Fri, 31 Aug 2007 18:37:33 -0700 From: Steve Kargl To: JoaoBR Message-ID: <20070901013733.GA12544@troutmask.apl.washington.edu> References: <-3502020561049594852@unknownmsgid> <20070901000710.GA12223@dragon.NUXI.org> <200708312120.31912.joao@matik.com.br> <200708312226.26977.joao@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708312226.26977.joao@matik.com.br> User-Agent: Mutt/1.4.2.3i Cc: Roman Divacky , freebsd-current@freebsd.org, pluknet , Bj?rn K?nig Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 01:37:55 -0000 On Fri, Aug 31, 2007 at 10:26:25PM -0300, JoaoBR wrote: > On Friday 31 August 2007 21:20:30 JoaoBR wrote: > > > > opterons are not easy but it is already kind of advanced cpu so could > > > > be > > > > > > Why are Opteron's any harder? > > > > because all of them are 64bit but some older ones are not SSE3 capable, < > > 250 I guess now but 252 is but not 100% sure > > > so just a thought, I have no not-sse3 capable anymore so I could check but > asking the gcc guys here ... > > what if I try to compile with -msse3 and it is not available, does it go > through or do I get invalid compile option and if it go through what may it > cost? Yes, it will compile the code. The result will most likely not run if some code was translated to use a sse3 feature. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 01:43:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4692D16A418; Sat, 1 Sep 2007 01:43:48 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2CB13C467; Sat, 1 Sep 2007 01:43:48 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l811hNXg041790; Fri, 31 Aug 2007 18:43:27 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l811hN9O041788; Fri, 31 Aug 2007 18:43:23 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 18:43:23 -0700 From: "David O'Brien" To: JoaoBR Message-ID: <20070901014323.GA41683@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, JoaoBR , freebsd-current@freebsd.org, Roman Divacky , pluknet , =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= References: <-3502020561049594852@unknownmsgid> <200708312032.21574.joao@matik.com.br> <20070901000710.GA12223@dragon.NUXI.org> <200708312120.31912.joao@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708312120.31912.joao@matik.com.br> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: Roman Divacky , freebsd-current@freebsd.org, pluknet , =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk 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: Sat, 01 Sep 2007 01:43:48 -0000 On Fri, Aug 31, 2007 at 09:20:30PM -0300, JoaoBR wrote: > On Friday 31 August 2007 21:07:10 David O'Brien wrote: > > > opterons are not easy but it is already kind of advanced cpu so > > > could be > > > > Why are Opteron's any harder? > > because all of them are 64bit but some older ones are not SSE3 capable, < 250 > I guess now but 252 is but not 100% sure It's not Opteron model # specific - but silicon revision specific. There are rev C0 model 250's, along with rev CG, and rev E. Same for athlon64 - older ones don't support SSE3, newer ones do. > people 'kind of familiarly' with reading manuals and specs are already > having difficulties here so imagin an average user (unkndefspec) who > likes to optimize his kernel (his cpu's kernel of course :) ) > > so as far as there are a cpu options for a freebsd kernel they should > be understandable so it might be worse thinking well before doing > (=less support = less questions = less problemas) BTW, the AMD offically sanctioned spelling for GCC 'march' is "amdfam10" -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 01:45:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 751AA16A41A; Sat, 1 Sep 2007 01:45:23 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 51B4513C478; Sat, 1 Sep 2007 01:45:23 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l811j1Q8041900; Fri, 31 Aug 2007 18:45:01 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l811j1po041899; Fri, 31 Aug 2007 18:45:01 -0700 (PDT) (envelope-from obrien) Date: Fri, 31 Aug 2007 18:45:01 -0700 From: "David O'Brien" To: JoaoBR Message-ID: <20070901014501.GB41683@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, JoaoBR , freebsd-current@freebsd.org, Roman Divacky , pluknet , =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= References: <-3502020561049594852@unknownmsgid> <20070901000710.GA12223@dragon.NUXI.org> <200708312120.31912.joao@matik.com.br> <200708312226.26977.joao@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708312226.26977.joao@matik.com.br> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: Roman Divacky , freebsd-current@freebsd.org, pluknet , =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk 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: Sat, 01 Sep 2007 01:45:23 -0000 On Fri, Aug 31, 2007 at 10:26:25PM -0300, JoaoBR wrote: > what if I try to compile with -msse3 and it is not available, does it go > through or do I get invalid compile option and if it go through what may it > cost? You can compile specifying sse3 just fine - you could easily be targeting a different machine than what you are compiling on. The problem will be when you try to run the resulting binary. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 01:57:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC8A16A41B; Sat, 1 Sep 2007 01:57:00 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id B9B4D13C469; Sat, 1 Sep 2007 01:56:59 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l811unt7000913; Fri, 31 Aug 2007 22:56:49 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Fri, 31 Aug 2007 22:56:59 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <200708312226.26977.joao@matik.com.br> <20070901013733.GA12544@troutmask.apl.washington.edu> In-Reply-To: <20070901013733.GA12544@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708312257.00730.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Roman Divacky , pluknet , Steve Kargl , Bj?rn K?nig Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 01:57:00 -0000 On Friday 31 August 2007 22:37:33 Steve Kargl wrote: > On Fri, Aug 31, 2007 at 10:26:25PM -0300, JoaoBR wrote: > > On Friday 31 August 2007 21:20:30 JoaoBR wrote: > > > > > opterons are not easy but it is already kind of advanced cpu so > > > > > could be > > > > > > > > Why are Opteron's any harder? > > > > > > because all of them are 64bit but some older ones are not SSE3 capabl= e, > > > < 250 I guess now but 252 is but not 100% sure > > > > so just a thought, I have no not-sse3 capable anymore so I could check= =20 > > but asking the gcc guys here ... > > > > what if I try to compile with -msse3 and it is not available, does it go > > through or do I get invalid compile option and if it go through what may > > it cost? > > Yes, it will compile the code. The result will most likely not run > if some code was translated to use a sse3 feature. well,question is: will this kernel boot and/or will it crash because of thi= s=20 cmppile options -msse3 - or not? =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 02:08:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B2ED16A41B; Sat, 1 Sep 2007 02:08:23 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id E1BC013C465; Sat, 1 Sep 2007 02:08:22 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l8128DKg001633; Fri, 31 Aug 2007 23:08:13 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: obrien@freebsd.org, freebsd-current@freebsd.org, Roman Divacky , pluknet , =?iso-8859-1?q?Bj=F6rn_K=F6nig?= Date: Fri, 31 Aug 2007 23:08:24 -0300 User-Agent: KMail/1.9.7 References: <-3502020561049594852@unknownmsgid> <200708312120.31912.joao@matik.com.br> <20070901014323.GA41683@dragon.NUXI.org> In-Reply-To: <20070901014323.GA41683@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708312308.25372.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 02:08:23 -0000 On Friday 31 August 2007 22:43:23 David O'Brien wrote: > On Fri, Aug 31, 2007 at 09:20:30PM -0300, JoaoBR wrote: > > On Friday 31 August 2007 21:07:10 David O'Brien wrote: > > > > opterons are not easy but it is already kind of advanced cpu so > > > > could be > > > > > > Why are Opteron's any harder? > > > > because all of them are 64bit but some older ones are not SSE3 capable,= < > > 250 I guess now but 252 is but not 100% sure > > It's not Opteron model # specific - but silicon revision specific. > There are rev C0 model 250's, along with rev CG, and rev E. > less than rev.E support SEE3 ? Do you have a spec/link for that? > Same for athlon64 - older ones don't support SSE3, newer ones do. > like I said before 'older ones' is kind of lame def > > people 'kind of familiarly' with reading manuals and specs are already > > having difficulties here so imagin an average user (unkndefspec) who > > likes to optimize his kernel (his cpu's kernel of course :) ) > > > > so as far as there are a cpu options for a freebsd kernel they should > > be understandable so it might be worse thinking well before doing > > (=3Dless support =3D less questions =3D less problemas) > > BTW, the AMD offically sanctioned spelling for GCC 'march' is "amdfam10" I guess you agree without any objections that that this 'is 100% userfriend= ly'=20 and could by add as '100% userfriendly' and so then I agree as well ...=20 but ... will they print it on the box in order to see it ??? guess not ;) =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 03:19:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6C016A419 for ; Sat, 1 Sep 2007 03:19:46 +0000 (UTC) (envelope-from nsayer@kfu.com) Received: from quack.kfu.com (unknown [IPv6:2002:478d:4001::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7AFF413C465 for ; Sat, 1 Sep 2007 03:19:46 +0000 (UTC) (envelope-from nsayer@kfu.com) Received: from www.kfu.com (localhost [127.0.0.1]) by quack.kfu.com (8.13.8/8.13.8) with ESMTP id l813Jh0m004322 for ; Fri, 31 Aug 2007 20:19:45 -0700 (PDT) (envelope-from nsayer@kfu.com) Received: from 76.220.106.108 (SquirrelMail authenticated user nsayer) by www.kfu.com with HTTP; Fri, 31 Aug 2007 20:19:45 -0700 (PDT) Message-ID: <60538.76.220.106.108.1188616785.squirrel@www.kfu.com> Date: Fri, 31 Aug 2007 20:19:45 -0700 (PDT) From: "Nick Sayer" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-2.0.2 (quack.kfu.com [127.0.0.1]); Fri, 31 Aug 2007 20:19:46 -0700 (PDT) X-Filter-Version: 1.15 (quack.kfu.com) Subject: Problems building -current world: safe-ctype.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 03:19:47 -0000 Hi. I'm trying to build the world and it's failing during phase 2.3 trying to build libiberty. cc -c -I /usr/src/gnu/usr.bin/cc/cc_tools/../libiberty -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr. bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/us r/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/ cc_tools/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_tools/../.. /../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../co ntrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../cont rib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -I/usr/obj/usr/src /tmp/legacy/usr/include -o safe-ctype.o /usr/src/gnu/usr.bin/cc/cc_tools/../../. ./../contrib/gcclibs/libiberty/safe-ctype.c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libiberty/safe-ctyp e.c:161: error: `_sch_isnvsp' undeclared here (not in a function) /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libiberty/safe-ctyp e.c:161: error: `_sch_iscntrl' undeclared here (not in a function) /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libiberty/safe-ctyp e.c:161: error: initializer element is not constant And so on and so on. Anybody have any idea what's going wrong? The system currently is 6.2-RELEASE. I guess I'm going to try taking it to RELENG_6 before giving up for now, but I'm dubious that that's going to change anything significant. From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 04:03:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D68A16A420 for ; Sat, 1 Sep 2007 04:03:46 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB6713C45A for ; Sat, 1 Sep 2007 04:03:46 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 7983 invoked from network); 1 Sep 2007 03:36:59 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO asus.tddhome) ([64.81.173.150]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 1 Sep 2007 03:36:59 -0000 Received: from asus.tddhome (localhost.tddhome [127.0.0.1]) by asus.tddhome (8.13.8/8.13.8) with ESMTP id l813awsH034087; Fri, 31 Aug 2007 20:36:58 -0700 (PDT) (envelope-from tomdean@asus.tddhome) Received: (from tomdean@localhost) by asus.tddhome (8.13.8/8.13.8/Submit) id l813aw15034084; Fri, 31 Aug 2007 20:36:58 -0700 (PDT) (envelope-from tomdean) Date: Fri, 31 Aug 2007 20:36:58 -0700 (PDT) Message-Id: <200709010336.l813aw15034084@asus.tddhome> From: "Thomas D. Dean" To: nsayer@kfu.com In-reply-to: <60538.76.220.106.108.1188616785.squirrel@www.kfu.com> (nsayer@kfu.com) References: <60538.76.220.106.108.1188616785.squirrel@www.kfu.com> Cc: freebsd-current@freebsd.org Subject: Re: Problems building -current world: safe-ctype.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 04:03:46 -0000 I just built -current from 6.2 release, cvsup 8/30 9PM PDT, with no errors. I installed 6.2 release from the CD, minimal install. tomdean From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 05:35:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBECD16A686; Sat, 1 Sep 2007 05:35:24 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id 28C3013C501; Sat, 1 Sep 2007 05:35:14 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from home.alpha-tierchen.de (port-212-202-42-154.dynamic.qsc.de [212.202.42.154]) by mail.liberty-hosting.de (Postfix) with ESMTP id F18C23E9DAE; Sat, 1 Sep 2007 07:36:53 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id 0929D45067; Sat, 1 Sep 2007 07:34:56 +0200 (CEST) Received: from 192.168.1.2 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Sat, 1 Sep 2007 07:34:56 +0200 (CEST) Message-ID: <61510.192.168.1.2.1188624896.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <200708312257.00730.joao@matik.com.br> References: <-3502020561049594852@unknownmsgid> <200708312226.26977.joao@matik.com.br> <20070901013733.GA12544@troutmask.apl.washington.edu> <200708312257.00730.joao@matik.com.br> Date: Sat, 1 Sep 2007 07:34:56 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: "JoaoBR" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Roman Divacky , freebsd-current@freebsd.org, pluknet , Steve Kargl , Bj?rn K?nig Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 05:35:24 -0000 JoaoBr wrote: > well,question is: will this kernel boot and/or will it crash because of > this cmppile options -msse3 - or not? The kernel won't use SSE3 at all because "-mno-sse3" will be appended to the compiler flags. See also src/sys/conf/kern.mk. Regards Björn From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 08:53:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5EEA16A419; Sat, 1 Sep 2007 08:53:43 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 8053C13C45B; Sat, 1 Sep 2007 08:53:43 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 709171B10EA4; Sat, 1 Sep 2007 10:53:21 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 6CE261B10E0D; Sat, 1 Sep 2007 10:53:21 +0200 (CEST) Message-ID: <46D92881.4000004@moneybookers.com> Date: Sat, 01 Sep 2007 11:53:21 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.6 (X11/20070831) MIME-Version: 1.0 To: JoaoBR References: <-3502020561049594852@unknownmsgid> <200708312120.31912.joao@matik.com.br> <20070901014323.GA41683@dragon.NUXI.org> <200708312308.25372.joao@matik.com.br> In-Reply-To: <200708312308.25372.joao@matik.com.br> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: Roman Divacky , freebsd-current@freebsd.org, pluknet , =?UTF-8?B?QmrDtnJuIEvDtm5pZw==?= Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 08:53:43 -0000 Hello, JoaoBR wrote: > On Friday 31 August 2007 22:43:23 David O'Brien wrote: > >> On Fri, Aug 31, 2007 at 09:20:30PM -0300, JoaoBR wrote: >> >>> On Friday 31 August 2007 21:07:10 David O'Brien wrote: >>> >>>>> opterons are not easy but it is already kind of advanced cpu so >>>>> could be >>>>> >>>> Why are Opteron's any harder? >>>> >>> because all of them are 64bit but some older ones are not SSE3 capable, < >>> 250 I guess now but 252 is but not 100% sure >>> >> It's not Opteron model # specific - but silicon revision specific. >> There are rev C0 model 250's, along with rev CG, and rev E. >> >> > > less than rev.E support SEE3 ? Do you have a spec/link for that? > > >> Same for athlon64 - older ones don't support SSE3, newer ones do. >> >> > > like I said before 'older ones' is kind of lame def > > >>> people 'kind of familiarly' with reading manuals and specs are already >>> having difficulties here so imagin an average user (unkndefspec) who >>> likes to optimize his kernel (his cpu's kernel of course :) ) >>> >>> so as far as there are a cpu options for a freebsd kernel they should >>> be understandable so it might be worse thinking well before doing >>> (=less support = less questions = less problemas) >>> > > > > >> BTW, the AMD offically sanctioned spelling for GCC 'march' is "amdfam10" >> > > > I guess you agree without any objections that that this 'is 100% userfriendly' > and could by add as '100% userfriendly' and so then I agree as well ... > but ... will they print it on the box in order to see it ??? guess not ;) > > Sorry, but if GCC know the new amd processors as amdfam10 (with alias barcelona), but the FreeBSD alias for them is "athlon64-E" how this is more user friendly ? Same question to k8-sse3, opteron-sse3, athlon64-sse3. Please take a look at this link : http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options As it is may be not a problem to have more aliases (not listed in gcc manuals), it sounds really bad idea to not have the same names as GCC. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 09:02:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D8A16A420; Sat, 1 Sep 2007 09:02:58 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id D913413C465; Sat, 1 Sep 2007 09:02:57 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id CF27B1B10EE2; Sat, 1 Sep 2007 11:02:56 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id CB8E01B10EE0; Sat, 1 Sep 2007 11:02:56 +0200 (CEST) Message-ID: <46D92AC0.7070101@moneybookers.com> Date: Sat, 01 Sep 2007 12:02:56 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.6 (X11/20070831) MIME-Version: 1.0 To: JoaoBR References: <-3502020561049594852@unknownmsgid> <20070831142458.GE79097@dragon.NUXI.org> <46D82649.20804@FreeBSD.org> <200708312039.43262.joao@matik.com.br> In-Reply-To: <200708312039.43262.joao@matik.com.br> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: Roman Divacky , freebsd-current@freebsd.org, pluknet , Bj?rn K?nig Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 09:02:58 -0000 Hello, JoaoBR wrote: > On Friday 31 August 2007 11:31:37 Kris Kennaway wrote: > > >>> for instance. >>> >> MACHINE_CPU is supposed to be a complete list of relevant CPU features >> that ports can use to enable e.g. SSE2 asm optimizations if the CPUTYPE >> supports it. A number of them exist that do this. >> >> > > > Sorry but I have some difficulties to understand how a port could enable CPU > features if they are not enabled/recognized by the kernel > > > The freebsd kernel recognize without a problem SSE3 flag. The problem is that we do not have CPU alias name for amd processors that support SSE3, and those processors are already available on the market (?) So the ports cannot use sse3 feature if you have AMD (even if it support it) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 09:45:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D230816A418; Sat, 1 Sep 2007 09:45:25 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 845D313C469; Sat, 1 Sep 2007 09:45:25 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 4888F1B10EA4; Sat, 1 Sep 2007 11:39:05 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 3D24A1B10E0D; Sat, 1 Sep 2007 11:39:05 +0200 (CEST) Message-ID: <46D93339.7020701@moneybookers.com> Date: Sat, 01 Sep 2007 12:39:05 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.6 (X11/20070831) MIME-Version: 1.0 To: =?UTF-8?B?QmrDtnJuIEvDtm5pZw==?= References: <-3502020561049594852@unknownmsgid> <20070831142458.GE79097@dragon.NUXI.org> <46D82649.20804@FreeBSD.org> <200708312039.43262.joao@matik.com.br> <46D92AC0.7070101@moneybookers.com> <56150.192.168.1.2.1188637696.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <56150.192.168.1.2.1188637696.squirrel@webmail.alpha-tierchen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: Roman Divacky , freebsd-current@freebsd.org, pluknet , JoaoBR Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 09:45:25 -0000 Hello, Bj=C3=B6rn K=C3=B6nig wrote: > Stefan Lambrev wrote: > > =20 >> So the ports cannot use sse3 feature if you have AMD (even if it suppo= rt >> it) >> =20 > > Of course they can. Just add > > CFLAGS+=3D-msse3 > > to /etc/make.conf > > > =20 Sorry I didn't explain myself better enough. What I want to say is, that ports like=20 ports/astro/boinc-setiathome-enhanced will not compile as expected=20 without the right CPUTYPE (which we do not have for new amd processors). from ports/astro/boinc-setiathome-enhanced/Makefile: =2Eif ${MACHINE_CPU:Msse3} CFLAGS+=3D -msse3 --=20 Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 09:08:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB28F16A41A; Sat, 1 Sep 2007 09:08:48 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id 64E5513C461; Sat, 1 Sep 2007 09:08:48 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from home.alpha-tierchen.de (port-212-202-42-154.dynamic.qsc.de [212.202.42.154]) by mail.liberty-hosting.de (Postfix) with ESMTP id 81C9F3E9433; Sat, 1 Sep 2007 11:10:14 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id D3EDC45067; Sat, 1 Sep 2007 11:08:16 +0200 (CEST) Received: from 192.168.1.2 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Sat, 1 Sep 2007 11:08:16 +0200 (CEST) Message-ID: <56150.192.168.1.2.1188637696.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <46D92AC0.7070101@moneybookers.com> References: <-3502020561049594852@unknownmsgid> <20070831142458.GE79097@dragon.NUXI.org> <46D82649.20804@FreeBSD.org> <200708312039.43262.joao@matik.com.br> <46D92AC0.7070101@moneybookers.com> Date: Sat, 1 Sep 2007 11:08:16 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: "Stefan Lambrev" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Sat, 01 Sep 2007 11:22:47 +0000 Cc: Roman Divacky , freebsd-current@freebsd.org, pluknet , JoaoBR , Bj?rn K?nig Subject: Re: Adding k9 and k10 to bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 09:08:48 -0000 Stefan Lambrev wrote: > So the ports cannot use sse3 feature if you have AMD (even if it support > it) Of course they can. Just add CFLAGS+=-msse3 to /etc/make.conf From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 15:54:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 184B516A419 for ; Sat, 1 Sep 2007 15:54:44 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 39F1613C45A for ; Sat, 1 Sep 2007 15:54:43 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so862717nfd for ; Sat, 01 Sep 2007 08:54:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=LU0Kup69zjtpoDepMTVnXgupEgxLqrmGjxWQrIIHt7PtMTrcNrim+PGoSw1XYP82+e7ULSFtKbVoB9+9yQsw0mG7HK6HqOPdZ2jA5eEOQRd71w11LNvncSMcuN0RMGkkhIqX96okGEoA6216qy9PntR8ilhv7vqeGOcGrfNStUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=ImwdDXV+uODtcHL/rp8fZLDYJ/ciGzAVwAjRd+egEo+UNsZqcLLi6oxwUSbf63T/8PgGytVpkkvTgX+Fa6IC/IWvEEroHgUkNBREpAHDPIpMmORfwicr7Z5EdYOax2qK/59qCA2cr64M8yRvttpXj4dNk3jFfW/YGy7/rBYqJfo= Received: by 10.78.185.15 with SMTP id i15mr2216690huf.1188662066033; Sat, 01 Sep 2007 08:54:26 -0700 (PDT) Received: from 77-109-34-202.dynamic.peoplenet.ua ( [77.109.34.202]) by mx.google.com with ESMTPS id o22sm303624hub.2007.09.01.08.54.23 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Sep 2007 08:54:25 -0700 (PDT) From: Nikolay Pavlov To: Jan Harkes Date: Sat, 1 Sep 2007 18:54:57 +0300 User-Agent: KMail/1.9.7 References: <200708202340.29678.qpadla@gmail.com> <20070824151927.GA11642@cs.cmu.edu> In-Reply-To: <20070824151927.GA11642@cs.cmu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1720895.EeJdkiuC1f"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709011855.01370.qpadla@gmail.com> Cc: freebsd-current@freebsd.org, rwatson@freebsd.org Subject: Re: And probably the final crash for today's current :) (panic: filesystem goof: vop_panic[vop_print]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@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: Sat, 01 Sep 2007 15:54:44 -0000 --nextPart1720895.EeJdkiuC1f Content-Type: multipart/mixed; boundary="Boundary-01=_RtY2G+tOxxsAAZj" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_RtY2G+tOxxsAAZj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Jan. In attachment you can find another one coda-client panic triggered by the=20 "killall venus" command right after "ls -la /coda". --Boundary-01=_RtY2G+tOxxsAAZj Content-Type: text/plain; charset="iso-8859-1"; name="coda_panic.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="coda_panic.txt" panic: lockmgr: locking against myself cpuid = 0 KDB: enter: panic exclusive sleep mutex Giant r = 0 (0xc0bb1250) locked @ /usr/src/sys/kern/kern_conf.c:326 panic: from debugger cpuid = 0 Uptime: 9m5s Physical memory: 1003 MB Dumping 105 MB: 90 74 58 42 26 10 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc074ec6e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc074ef2b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc048c887 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:433 #4 0xc048d275 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xc048e9e5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xc0775c76 in kdb_trap (type=3, code=0, tf=0xe6a236c8) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xc0a02e6b in trap (frame=0xe6a236c8) at /usr/src/sys/i386/i386/trap.c:621 #8 0xc09e889b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #9 0xc0775df2 in kdb_enter (msg=0xc0a9bd83 "panic") at cpufunc.h:60 #10 0xc074ef14 in panic (fmt=0xc0a997b4 "lockmgr: locking against myself") at /usr/src/sys/kern/kern_shutdown.c:547 #11 0xc073ee97 in _lockmgr (lkp=0xc67f6058, flags=8194, interlkp=0xc67f60d4, td=0xc69a6000, file=0xc0aa7186 "/usr/src/sys/kern/vfs_subr.c", line=2130) at /usr/src/sys/kern/kern_lock.c:366 #12 0xc07bcb40 in vop_stdlock (ap=0xe6a23824) at /usr/src/sys/kern/vfs_default.c:266 #13 0xc0a19625 in VOP_LOCK1_APV (vop=0xc6972ba0, a=0xe6a23824) at vnode_if.c:1618 #14 0xc07d6a88 in _vn_lock (vp=0xc67f6000, flags=8194, td=0xc69a6000, file=0xc0aa7186 "/usr/src/sys/kern/vfs_subr.c", line=2130) at vnode_if.h:851 #15 0xc07cb09e in vrele (vp=0xc67f6000) at /usr/src/sys/kern/vfs_subr.c:2130 #16 0xc696e56e in ?? () #17 0xc67f6000 in ?? () #18 0xc69a6000 in ?? () #19 0xe6a238a8 in ?? () #20 0xc0a16475 in VOP_ISLOCKED_APV (vop=0xe6a23908, a=0x13) at vnode_if.c:49 #21 0xc0a17655 in VOP_CLOSE_APV (vop=0x1, a=0xc4d3cd00) at vnode_if.c:424 #22 0xc07ca857 in vgonel (vp=0xc67f6000) at vnode_if.h:228 #23 0xc07cb4f7 in vflush (mp=0xc42b02e8, rootrefs=0, flags=2, td=0xc69a6000) at /usr/src/sys/kern/vfs_subr.c:2380 #24 0xc696d2a6 in ?? () #25 0xc42b02e8 in ?? () #26 0x00000000 in ?? () #27 0x00000002 in ?? () #28 0xc69a6000 in ?? () #29 0x000000e9 in ?? () #30 0xc0b7fba0 in vop_lock1_desc () #31 0xc67f6000 in ?? () #32 0x00000000 in ?? () #33 0xc69a6000 in ?? () #34 0xc62bfd98 in ?? () #35 0x00000000 in ?? () #36 0xc69a6000 in ?? () #37 0xe6a23a6c in ?? () #38 0xc07c5ae6 in dounmount (mp=0xc42b02e8, flags=3, td=0xc42b02e8) at /usr/src/sys/kern/vfs_mount.c:1273 Previous frame identical to this frame (corrupt stack?) --Boundary-01=_RtY2G+tOxxsAAZj-- --nextPart1720895.EeJdkiuC1f Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG2YtV/2R6KvEYGaIRAnpVAJ9IW8vendLc7z7Kk/0Q5BxP/IGgWwCgw4M6 mED4+6dl5jD0ZRhaFYvTvQg= =yIs+ -----END PGP SIGNATURE----- --nextPart1720895.EeJdkiuC1f-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 17:18:52 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCB0716A420; Sat, 1 Sep 2007 17:18:52 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.freebsd.org (Postfix) with ESMTP id 8E56813C469; Sat, 1 Sep 2007 17:18:52 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by gwyn.kn-bremen.de (Postfix, from userid 10) id 0DA8F216FC1; Sat, 1 Sep 2007 19:00:27 +0200 (CEST) Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.8/8.13.6) with ESMTP id l81Gus5u039292; Sat, 1 Sep 2007 18:56:54 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.8/8.13.6/Submit) id l81GusgE039291; Sat, 1 Sep 2007 18:56:54 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 1 Sep 2007 18:56:53 +0200 To: freebsd-current@FreeBSD.org, freebsd-sparc64@FreeBSD.org Message-ID: <20070901165653.GA38448@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Sat, 01 Sep 2007 17:36:47 +0000 Cc: Subject: weird sparc64/-current issue!? (p7zip) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 17:18:52 -0000 Hi! alepulver made me aware of this, http://pointyhat.freebsd.org/errorlogs/sparc64-7-latest-logs/mame-extras-0.114.log -8624 CPU(s)? :) It works on 6, http://pointyhat.freebsd.org/errorlogs/sparc64-6-latest-logs/mame-extras-0.114.log altho that was using an earlier p7zip version... The code that gets the number of cpus seems to be in work/p7zip*/CPP/Windows/System.cpp in the /usr/ports/archivers/p7zip dir (after make patch): [...] UInt32 GetNumberOfProcessors() { int nbcpu = 1; size_t value; size_t len = sizeof(value); if (sysctlbyname("hw.ncpu", &value, &len, NULL, 0) == 0) nbcpu = value; return nbcpu; } [...] I don't have a sparc64 box, could this have something to do with 7z's use of shared libs, like sparc64 now needs -fPIC like amd64 and ia64 too? (just run 7z l and 7za l on some tarball, that should be enough to find out, 7za has its 7z libs linked statically.) If anyone has other insights/can debug this I'd be grateful too... Thanx, Juergen PS: I'm not subscribed on -sparc64 so please Cc me if you remove -current from the Cc. From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 21:26:20 2007 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 7A6DC16A41B for ; Sat, 1 Sep 2007 21:26:20 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD5913C46B for ; Sat, 1 Sep 2007 21:26:19 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l81KnlSr021850; Sun, 2 Sep 2007 06:49:47 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l81Knl60021849; Sun, 2 Sep 2007 06:49:47 +1000 (EST) (envelope-from peter) Date: Sun, 2 Sep 2007 06:49:47 +1000 From: Peter Jeremy To: Bruce Cran Message-ID: <20070901204947.GY1181@turion.vk2pj.dyndns.org> References: <46D83351.9000407@cran.org.uk> <46D8719A.1070109@cran.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: <46D8719A.1070109@cran.org.uk> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org Subject: Re: High interrupt load on VIA C3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 21:26:20 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Aug-31 20:52:58 +0100, Bruce Cran wrote: >This appears to be an issue with powerd/cpufreq - disabling powerd reduces= =20 >the interrupt load to a couple of percent at most, and the clock interrupt= =20 >task now only accumulates CPU time very slowly (previously it was using 7%= =20 >CPU all the time). I'm not familiar with the VIA CPUs but how slowly can powerd make the CPU run? The top extract you posted show the system was idle so its likely that powerd had wound the clock to a minimum. The amount of code executed by the interrupt handlers remains the same but will take longer at slower clock speeds so the percenatage is higher. You can experiment for yourself by enabling only cpufreq and using sysctl. dev.cpu.0.freq_levels lists all supported possible CPU rates and you can change the clock frequency by assigning dev.cpu.0.freq. --=20 Peter Jeremy --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG2dBr/opHv/APuIcRAhZGAJ99vbxkNlD+K8rT7e1sTfL+vmzecwCfSZ4I AOwdQ7a9lnMFYVYQwYI7cJU= =vK+Y -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 22:05:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23C2516A566 for ; Sat, 1 Sep 2007 22:05:21 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: from mail.integrity.hu (mail.integrity.hu [195.56.44.40]) by mx1.freebsd.org (Postfix) with SMTP id 9681313C442 for ; Sat, 1 Sep 2007 22:05:20 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: (qmail 27164 invoked by uid 89); 1 Sep 2007 23:58:38 +0200 Message-ID: <20070901215838.27162.qmail@mail.integrity.hu> From: "Zahemszky Gabor" To: freebsd-current@freebsd.org Date: Sat, 01 Sep 2007 23:58:38 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2"; format=flowed Content-Transfer-Encoding: 7bit X-Sender: gabor@zahemszky.hu X-Mailman-Approved-At: Sat, 01 Sep 2007 22:38:56 +0000 Subject: if_zyd panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 22:05:21 -0000 Hi! I tried the fresh new if_zyd driver in todays CURRENT. I've got a Lutec WLA-54L named, ZyDAS 1211b based USB wifi stick. I tried it, but on # ifconfig zyd0 up the system crashed. The error message is: Panic: Bad list head 0xc519a6bc first -> prev != head Any takers? Bye, Zahy < Gabor at Zahemszky dot HU > From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 22:20:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D259216A41B for ; Sat, 1 Sep 2007 22:20:39 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: from mail.integrity.hu (mail.integrity.hu [195.56.44.40]) by mx1.freebsd.org (Postfix) with SMTP id 69AA513C428 for ; Sat, 1 Sep 2007 22:20:38 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: (qmail 22136 invoked by uid 89); 1 Sep 2007 23:53:58 +0200 Message-ID: <20070901215358.22135.qmail@mail.integrity.hu> From: "Zahemszky Gabor" To: freebsd-current@freebsd.org Date: Sat, 01 Sep 2007 23:53:58 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2"; format=flowed Content-Transfer-Encoding: 7bit X-Sender: gabor@zahemszky.hu X-Mailman-Approved-At: Sat, 01 Sep 2007 22:38:56 +0000 Subject: Panic with if_rum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 22:20:39 -0000 Hi! Current of today, and a new USB Wifi-card. Edimax-EW-7318UG. The system knows it, I have a rum0 interface. I can: ifconfig rum0 up OK. But: ifconfig rum0 scan and some seconds later, kernel panic: panic: Bad link elm 0xc5ade458 prev -> next != elm Any takers? Zahy < Gabor at Zahemszky dot HU > From owner-freebsd-current@FreeBSD.ORG Sat Sep 1 22:57:54 2007 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 82B0116A419 for ; Sat, 1 Sep 2007 22:57:54 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6D213C45B for ; Sat, 1 Sep 2007 22:57:54 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (dyn-62-56-105-44.dslaccess.co.uk [62.56.105.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id B70DE3000D; Sat, 1 Sep 2007 23:53:48 +0100 (BST) Message-ID: <46D9EE1E.9030009@cran.org.uk> Date: Sat, 01 Sep 2007 23:56:30 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: Peter Jeremy References: <46D83351.9000407@cran.org.uk> <46D8719A.1070109@cran.org.uk> <20070901204947.GY1181@turion.vk2pj.dyndns.org> In-Reply-To: <20070901204947.GY1181@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: High interrupt load on VIA C3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2007 22:57:54 -0000 Peter Jeremy wrote: > On 2007-Aug-31 20:52:58 +0100, Bruce Cran wrote: > >> This appears to be an issue with powerd/cpufreq - disabling powerd reduces >> the interrupt load to a couple of percent at most, and the clock interrupt >> task now only accumulates CPU time very slowly (previously it was using 7% >> CPU all the time). >> > > I'm not familiar with the VIA CPUs but how slowly can powerd make the > CPU run? The top extract you posted show the system was idle so its > likely that powerd had wound the clock to a minimum. The amount of > code executed by the interrupt handlers remains the same but will take > longer at slower clock speeds so the percenatage is higher. > > You can experiment for yourself by enabling only cpufreq and using > sysctl. dev.cpu.0.freq_levels lists all supported possible CPU rates > and you can change the clock frequency by assigning dev.cpu.0.freq. > The VIA C3 supports 2 frequencies - 531 and 265 MHz. The high interrupt load only occurs when I set dev.cpu.0.freq to 265, which makes sense. -- Bruce Cran