From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 02:17:23 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DBEF16A402; Sun, 24 Feb 2008 02:17:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 74BE013C4EA; Sun, 24 Feb 2008 02:17:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1O2HMBV032539; Sat, 23 Feb 2008 21:17:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1O2HLnE059766; Sat, 23 Feb 2008 21:17:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7D24973039; Sat, 23 Feb 2008 21:17:21 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080224021721.7D24973039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 21:17:21 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 02:17:23 -0000 TB --- 2008-02-24 01:06:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-24 01:06:35 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-02-24 01:06:35 - cleaning the object tree TB --- 2008-02-24 01:06:55 - cvsupping the source tree TB --- 2008-02-24 01:06:55 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-02-24 01:07:01 - building world (CFLAGS=-O -pipe) TB --- 2008-02-24 01:07:01 - cd /src TB --- 2008-02-24 01:07:01 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 24 01:07:02 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 24 02:10:31 UTC 2008 TB --- 2008-02-24 02:10:31 - generating LINT kernel config TB --- 2008-02-24 02:10:31 - cd /src/sys/powerpc/conf TB --- 2008-02-24 02:10:31 - /usr/bin/make -B LINT TB --- 2008-02-24 02:10:31 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-24 02:10:31 - cd /src TB --- 2008-02-24 02:10:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 24 02:10:32 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/powerpc/fpu/fpu_extern.h:75: warning: redundant redeclaration of 'fpu_mul' /src/sys/powerpc/fpu/fpu_emu.h:156: warning: previous declaration of 'fpu_mul' was here /src/sys/powerpc/fpu/fpu_extern.h:78: warning: redundant redeclaration of 'fpu_sqrt' /src/sys/powerpc/fpu/fpu_emu.h:158: warning: previous declaration of 'fpu_sqrt' was here /src/sys/powerpc/fpu/fpu_extern.h:81: warning: redundant redeclaration of 'fpu_shr' /src/sys/powerpc/fpu/fpu_emu.h:175: warning: previous declaration of 'fpu_shr' was here /src/sys/powerpc/fpu/fpu_extern.h:83: warning: redundant redeclaration of 'fpu_newnan' /src/sys/powerpc/fpu/fpu_emu.h:168: warning: previous declaration of 'fpu_newnan' was here *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-24 02:17:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-24 02:17:21 - ERROR: failed to build lint kernel TB --- 2008-02-24 02:17:21 - tinderbox aborted TB --- 3120.02 user 369.44 system 4245.26 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 03:25:43 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDE2616A402; Sun, 24 Feb 2008 03:25:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id CD5C113C448; Sun, 24 Feb 2008 03:25:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1O3Pf5I035497; Sat, 23 Feb 2008 22:25:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1O3PfNZ062723; Sat, 23 Feb 2008 22:25:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 766B373039; Sat, 23 Feb 2008 22:25:41 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080224032541.766B373039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 22:25:41 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 03:25:43 -0000 TB --- 2008-02-24 02:17:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-24 02:17:21 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-02-24 02:17:21 - cleaning the object tree TB --- 2008-02-24 02:18:07 - cvsupping the source tree TB --- 2008-02-24 02:18:07 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-02-24 02:18:12 - building world (CFLAGS=-O -pipe) TB --- 2008-02-24 02:18:12 - cd /src TB --- 2008-02-24 02:18:12 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 24 02:18:14 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 24 03:17:03 UTC 2008 TB --- 2008-02-24 03:17:03 - generating LINT kernel config TB --- 2008-02-24 03:17:03 - cd /src/sys/sun4v/conf TB --- 2008-02-24 03:17:03 - /usr/bin/make -B LINT TB --- 2008-02-24 03:17:03 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-24 03:17:03 - cd /src TB --- 2008-02-24 03:17:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 24 03:17:03 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_cpl_io.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom_sysctl.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_cpl_socket.c In file included from /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_cpl_socket.c:79: @/dev/cxgb/cxgb_offload.h:262:1: error: "UNIMPLEMENTED" redefined In file included from /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_cpl_socket.c:52: ./machine/cpu.h:89:1: error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-24 03:25:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-24 03:25:41 - ERROR: failed to build lint kernel TB --- 2008-02-24 03:25:41 - tinderbox aborted TB --- 3002.81 user 371.27 system 4099.75 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 08:36:18 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4AFC16A403; Sun, 24 Feb 2008 08:36:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C268713C4D9; Sun, 24 Feb 2008 08:36:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1O8aHBi092802; Sun, 24 Feb 2008 03:36:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1O8aHK2052216; Sun, 24 Feb 2008 03:36:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 68C0F73039; Sun, 24 Feb 2008 03:36:17 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080224083617.68C0F73039@freebsd-current.sentex.ca> Date: Sun, 24 Feb 2008 03:36:17 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 08:36:19 -0000 TB --- 2008-02-24 07:09:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-24 07:09:37 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-02-24 07:09:37 - cleaning the object tree TB --- 2008-02-24 07:09:56 - cvsupping the source tree TB --- 2008-02-24 07:09:56 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-02-24 07:15:21 - building world (CFLAGS=-O -pipe) TB --- 2008-02-24 07:15:21 - cd /src TB --- 2008-02-24 07:15:21 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 24 07:15:22 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 24 08:29:15 UTC 2008 TB --- 2008-02-24 08:29:15 - generating LINT kernel config TB --- 2008-02-24 08:29:15 - cd /src/sys/powerpc/conf TB --- 2008-02-24 08:29:15 - /usr/bin/make -B LINT TB --- 2008-02-24 08:29:15 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-24 08:29:15 - cd /src TB --- 2008-02-24 08:29:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 24 08:29:16 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/aim/vm_machdep.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/fpu/fpu_add.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/fpu/fpu_compare.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/fpu/fpu_div.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/fpu/fpu_emu.c /src/sys/powerpc/fpu/fpu_emu.c:83:1: error: "DEBUG" redefined In file included from :0: ./opt_global.h:26:1: error: this is the location of the previous definition *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-24 08:36:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-24 08:36:17 - ERROR: failed to build lint kernel TB --- 2008-02-24 08:36:17 - tinderbox aborted TB --- 3130.72 user 371.23 system 5199.80 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 09:29:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E736F16A407 for ; Sun, 24 Feb 2008 09:29:52 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 832E813C4E7 for ; Sun, 24 Feb 2008 09:29:52 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sun, 24 Feb 2008 10:25:51 +0100 id 0002E00F.47C1381F.0000CBDC From: Milan Obuch To: freebsd-current@freebsd.org, pyunyh@gmail.com Date: Sun, 24 Feb 2008 10:29:31 +0100 User-Agent: KMail/1.9.7 References: <20080204022334.GC27999@cdnetworks.co.kr> <20080218081801.GB14601@cdnetworks.co.kr> <20080222054356.GE30497@cdnetworks.co.kr> In-Reply-To: <20080222054356.GE30497@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802241029.32962.freebsd-current@dino.sk> Cc: Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 09:29:53 -0000 On Friday 22 February 2008, Pyun YongHyeon wrote: [ snip ] > > > > I've put up a new version under the old URL. > > It's not tested in sparc64 but it seems to work on i386. > > Would you give it spin? > > Any progress here? Does the updated one works on your box? Well, I arranged a test today and the result is no change. After some time box hard locks. It occurs only with if_vr kldload'ed and after some traffic occured. No ability to enter debugger though. So while it seems related to vr ethernet card, I can't prove it, I can't dig any usefull data from the box. Still, if there is some debug possibility built into driver you can point me at, I will try. But now I have no idea what's wrong here. Regards, Milan -- Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead. From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 10:46:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4E9B16A403 for ; Sun, 24 Feb 2008 10:46:47 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0EAC513C457; Sun, 24 Feb 2008 10:46:42 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C14B0F.8050403@FreeBSD.org> Date: Sun, 24 Feb 2008 11:46:39 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Barney Cordoba References: <274346.34322.qm@web63914.mail.re1.yahoo.com> In-Reply-To: <274346.34322.qm@web63914.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: splimp() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 10:46:48 -0000 Barney Cordoba wrote: > I'm porting some older software to 7.0 and I see that > many of the 7.0 drivers use both locks and splimps() > to protect code, particularly the firewire driver. > What cases would an splimp() be required? spl*() are NOPs that are only left behind in some code as a reminder of what mutual exclusion protections used to apply, mostly in cases where there has not been fine-grained locking applied to the code in question. In some (most?) cases they serve no useful annotation purpose and should just be removed. For newly written code they should be added. Kris From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 11:04:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1369616A403 for ; Sun, 24 Feb 2008 11:04:25 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout3-sn2.hy.skanova.net (pne-smtpout3-sn2.hy.skanova.net [81.228.8.111]) by mx1.freebsd.org (Postfix) with ESMTP id D0AF313C442 for ; Sun, 24 Feb 2008 11:04:24 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from [80.221.12.61] (80.221.12.61) by pne-smtpout3-sn2.hy.skanova.net (7.3.129) (authenticated as tansmi-f) id 478BDB9600220D89; Sun, 24 Feb 2008 10:54:55 +0100 From: Mikael Ikivesi To: Alexandre Sunny Kovalenko , Svein Skogen , des@des.no, freebsd-current In-Reply-To: <47C00F20.2090700@d80.iso100.no> References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> <86zlttqmc9.fsf@ds4.des.no> <1203686245.63435.12.camel@RabbitsDen> <86oda9oxxe.fsf@ds4.des.no> <1203692492.63435.16.camel@RabbitsDen> <86ablsabd0.fsf@ds4.des.no> <47C00F20.2090700@d80.iso100.no> Content-Type: text/plain; charset=utf8 Date: Sun, 24 Feb 2008 11:54:37 +0200 Message-Id: <1203846877.7104.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: 2 core dumps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 11:04:25 -0000 > Dag-Erling Smørgrav wrote: > > You told us yourself that parts of your laptop have been deformed and > > discolored by heat. On Sat, 2008-02-23 at 13:18 +0100, Svein Skogen wrote: > Those deformed parts necessarily changes the airflow, and as such > reduces the laptops chances of cooling itself. > Regards, > > Svein Skogen > > p.s. I've done my share of trying to deny the truth of hardware being > defective. It didn't work, the hardware was just as dead as before I > denied it being dead. And at this point I would like to point out that no one in this threat has complained about deformed and discolored laptop! I understand that you might be having hundreds of mail per day and having problems of carefully reading everything thru. But when answering to people please read their mail first. Alex Kovalenko kindly ASKED IF MY DEFINITION OF OVERHEATING WAS DISCOLORED LAPTOP OR SOMETHING ELSE. I tried to point out repeatedly that this laptop did not overheat while crashing, neither became a grilled plastic heap before that. It stays cool and quiet as it should. And under linux it still is fully operational. And with FreeBSD it compiled freebsd world and ports again last night without a crash (or overheating). This thread was about getting more information about crashes and their possible reasons. I am not saying that it is entirely impossible that these are somehow caused by crappy laptop, but at least they are not because of overheating. -Mikael From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 11:11:05 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E44216A40A; Sun, 24 Feb 2008 11:11:05 +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 3E9F413C46E; Sun, 24 Feb 2008 11:11:05 +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 CCE2746B3D; Sun, 24 Feb 2008 06:11:04 -0500 (EST) Date: Sun, 24 Feb 2008 11:11:04 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kris Kennaway In-Reply-To: <47C14B0F.8050403@FreeBSD.org> Message-ID: <20080224110902.K25292@fledge.watson.org> References: <274346.34322.qm@web63914.mail.re1.yahoo.com> <47C14B0F.8050403@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Barney Cordoba , current@freebsd.org Subject: Re: splimp() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 11:11:05 -0000 On Sun, 24 Feb 2008, Kris Kennaway wrote: > Barney Cordoba wrote: >> I'm porting some older software to 7.0 and I see that many of the 7.0 >> drivers use both locks and splimps() to protect code, particularly the >> firewire driver. What cases would an splimp() be required? > > spl*() are NOPs that are only left behind in some code as a reminder of what > mutual exclusion protections used to apply, mostly in cases where there has > not been fine-grained locking applied to the code in question. In some > (most?) cases they serve no useful annotation purpose and should just be > removed. For newly written code they should be added. I'm pretty sure you meant "should not be added" :-). There are places in the tree where spl*() references persist due to inadequate synchronization, in which case they should be left in order to continue to provide an annoying reminder of that requirement. Ideally, files that retrained spl's would increasingly be annotated with comments indicating why they remain. The other argument for retaining spl's was to make maintaining a single driver/whatever source across FreeBSD 4.x and forwards; this is presumably also decreasingly a requirement over time. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 11:34:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ACBF16A402; Sun, 24 Feb 2008 11:34:11 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4420E13C455; Sun, 24 Feb 2008 11:34:10 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C15631.5020002@FreeBSD.org> Date: Sun, 24 Feb 2008 12:34:09 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Robert Watson References: <274346.34322.qm@web63914.mail.re1.yahoo.com> <47C14B0F.8050403@FreeBSD.org> <20080224110902.K25292@fledge.watson.org> In-Reply-To: <20080224110902.K25292@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barney Cordoba , current@freebsd.org Subject: Re: splimp() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 11:34:11 -0000 Robert Watson wrote: > On Sun, 24 Feb 2008, Kris Kennaway wrote: > >> Barney Cordoba wrote: >>> I'm porting some older software to 7.0 and I see that many of the 7.0 >>> drivers use both locks and splimps() to protect code, particularly >>> the firewire driver. What cases would an splimp() be required? >> >> spl*() are NOPs that are only left behind in some code as a reminder >> of what mutual exclusion protections used to apply, mostly in cases >> where there has not been fine-grained locking applied to the code in >> question. In some (most?) cases they serve no useful annotation >> purpose and should just be removed. For newly written code they >> should be added. > > I'm pretty sure you meant "should not be added" :-). Er yes ;) Kris From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 11:51:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 890DA16A40A for ; Sun, 24 Feb 2008 11:51:33 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9FD13C478 for ; Sun, 24 Feb 2008 11:51:33 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-a816e555.03-51-73746f3.cust.bredbandsbolaget.se (c-a816e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.168]) by smtp.infidyne.com (Postfix) with ESMTP id BBE683073A; Sun, 24 Feb 2008 12:51:31 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Sun, 24 Feb 2008 12:52:43 +0100 User-Agent: KMail/1.9.7 References: <20080215231507.EAB7D641@mx2.synetsystems.com> In-Reply-To: <20080215231507.EAB7D641@mx2.synetsystems.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1690081.MCEkRg8Dft"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802241252.52176.peter.schuller@infidyne.com> Cc: Richard Todd Subject: Re: ZFS: data sometimes not getting correctly flushed to disk (possible mmap/write issue)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 11:51:33 -0000 --nextPart1690081.MCEkRg8Dft Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 3) ktracing gen2.py shows that the py-mutagen library seems to do both > write()s and read/write mmap()s to the file to update the file. =46WIW, ever since a dovecot installation of mine was moved onto ZFS one ge= ts=20 sporadic 'internel errors' from dovecot. Dovecot logs that index files are= =20 corrupt, and marked broken. Recovery involves re-selecting the IMAP mailbox. In response to your post, I recently turned OFF use of mmap in dovecot=20 (mmap_disable =3D yes), and the problem seems to have gone away immediately. If it should show up again in spite of mmap being disabled I will post a=20 follow-up, but it's been long enough that I believe the problem to be gone. =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart1690081.MCEkRg8Dft 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) iD8DBQBHwVqUDNor2+l1i30RAiwVAJ9ZdinVw5QSkIlY7F1hihnchjisEQCcCXgj bzaUUOPrbhQDObzWz6tL/Dw= =kOf+ -----END PGP SIGNATURE----- --nextPart1690081.MCEkRg8Dft-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 13:23:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E4AA16A400 for ; Sun, 24 Feb 2008 13:23:05 +0000 (UTC) (envelope-from adrian.chadd@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 C0E0013C442 for ; Sun, 24 Feb 2008 13:23:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so558932nfb.33 for ; Sun, 24 Feb 2008 05:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=/8XnCLBnY3r34hR+Yw8NjUXaRaPuKi3l5DijueQpJFo=; b=wQlHJjvoL9UWVp6dds2JkDF6mO5LCD5XL+KHr2VeyFyDIvmI0urq6zjBkUMjH4NYLq8VsMTy/sLDPvXAuqJIqTNND7FtB3oxA/Z2+5AeK2+/5ZUiABju4ffhHDpgHKXvHq8NSFMRsTc7soOQyE5Dnxt8SdfI18hgI6zYXdZa2fQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=PYOkNfHLNlYbH+WzMRH7tWsWaaUH3HuWGiAW/Q6CrU3tpOmzSnIh3+mksP5WeNQiNDC8u1T2AOfFM94uKzVMv5JSATSBhlQVlTIWVFHK4uIKaZzCn6z4J49k8iVNM0CgoRpNumTP85lyo5i4ADcAAZgNkghLD7HJeESwXtZ/5OU= Received: by 10.142.163.14 with SMTP id l14mr1099432wfe.73.1203857708371; Sun, 24 Feb 2008 04:55:08 -0800 (PST) Received: by 10.143.125.7 with HTTP; Sun, 24 Feb 2008 04:55:08 -0800 (PST) Message-ID: Date: Sun, 24 Feb 2008 21:55:08 +0900 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Mikael Ikivesi" In-Reply-To: <1203846877.7104.17.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> <86zlttqmc9.fsf@ds4.des.no> <1203686245.63435.12.camel@RabbitsDen> <86oda9oxxe.fsf@ds4.des.no> <1203692492.63435.16.camel@RabbitsDen> <86ablsabd0.fsf@ds4.des.no> <47C00F20.2090700@d80.iso100.no> <1203846877.7104.17.camel@localhost> X-Google-Sender-Auth: e81992dbd8ea9c91 Cc: freebsd-current Subject: Re: 2 core dumps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 13:23:05 -0000 I'd suggest that you graph the whatever temperatures your laptop can report under both FreeBSD and Linux. Laptops do get warm - especially if people do dumb things like restrict airflow to where its needed - but if its getting too warm to use then something's amiss. Powerd and friends job isn't to prevent the CPU from overheating, its to step the CPU down a notch when its not being asked to do intensive tasks. If your laptop can't sustain intensive tasks without crashing then there's a fault in the laptop, either the design or your specific unit. Graph the temperatures and see if the laptop runs noticably warmer under FreeBSD than Linux. You might just find that "more work" is being done under FreeBSD and its causing your hardware to fail. The backtraces are useless if your hardware is at fault. Discount the hardware being at fault first. 2c, adrian (Who gave up trying to make this crap work on PCs and just bought an iBook.= .) On 24/02/2008, Mikael Ikivesi wrote: > > > Dag-Erling Sm=F8rgrav wrote: > > > You told us yourself that parts of your laptop have been deformed an= d > > > discolored by heat. > > > On Sat, 2008-02-23 at 13:18 +0100, Svein Skogen wrote: > > > Those deformed parts necessarily changes the airflow, and as such > > reduces the laptops chances of cooling itself. > > > > > Regards, > > > > Svein Skogen > > > > p.s. I've done my share of trying to deny the truth of hardware being > > defective. It didn't work, the hardware was just as dead as before I > > denied it being dead. > > > > And at this point I would like to point out that no one in this threat > has complained about deformed and discolored laptop! > > I understand that you might be having hundreds of mail per day and > having problems of carefully reading everything thru. But when answering > to people please read their mail first. > > Alex Kovalenko kindly ASKED IF MY DEFINITION OF OVERHEATING WAS > DISCOLORED LAPTOP OR SOMETHING ELSE. > > I tried to point out repeatedly that this laptop did not overheat while > crashing, neither became a grilled plastic heap before that. > > It stays cool and quiet as it should. And under linux it still is fully > operational. And with FreeBSD it compiled freebsd world and ports again > last night without a crash (or overheating). > > This thread was about getting more information about crashes and their > possible reasons. I am not saying that it is entirely impossible that > these are somehow caused by crappy laptop, but at least they are not > because of overheating. > > > -Mikael > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > --=20 Adrian Chadd - adrian@freebsd.org From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 14:25:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B889616A402 for ; Sun, 24 Feb 2008 14:25:04 +0000 (UTC) (envelope-from bbiskebo@Princeton.EDU) Received: from Princeton.EDU (postoffice03.Princeton.EDU [128.112.131.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6954113C4F0 for ; Sun, 24 Feb 2008 14:25:04 +0000 (UTC) (envelope-from bbiskebo@Princeton.EDU) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by Princeton.EDU (8.13.8/8.13.8) with ESMTP id m1OEOqJm025094; Sun, 24 Feb 2008 09:24:58 -0500 (EST) Received: from [140.180.177.201] (formula.Princeton.EDU [140.180.177.201]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id m1OEOkrU024851 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 24 Feb 2008 09:24:46 -0500 (EST) Message-ID: <47C17E2C.5040606@princeton.edu> Date: Sun, 24 Feb 2008 09:24:44 -0500 From: Brian Biskeborn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Peter Schuller References: <20080215231507.EAB7D641@mx2.synetsystems.com> <200802241252.52176.peter.schuller@infidyne.com> In-Reply-To: <200802241252.52176.peter.schuller@infidyne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Richard Todd Subject: Re: ZFS: data sometimes not getting correctly flushed to disk (possible mmap/write issue)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 14:25:04 -0000 This has been happening to me for a week or so (same setup - Dovecot on ZFS). I'll disable mmap and see whether it persists. Brian Peter Schuller wrote: >> 3) ktracing gen2.py shows that the py-mutagen library seems to do both >> write()s and read/write mmap()s to the file to update the file. > > FWIW, ever since a dovecot installation of mine was moved onto ZFS one gets > sporadic 'internel errors' from dovecot. Dovecot logs that index files are > corrupt, and marked broken. Recovery involves re-selecting the IMAP mailbox. > > In response to your post, I recently turned OFF use of mmap in dovecot > (mmap_disable = yes), and the problem seems to have gone away immediately. > > If it should show up again in spite of mmap being disabled I will post a > follow-up, but it's been long enough that I believe the problem to be gone. > From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 15:03:44 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57BBC16A400; Sun, 24 Feb 2008 15:03:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1AA6713C457; Sun, 24 Feb 2008 15:03:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1OF3hV3009749; Sun, 24 Feb 2008 10:03:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1OF3h08004242; Sun, 24 Feb 2008 10:03:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 24CA373039; Sun, 24 Feb 2008 10:03:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080224150343.24CA373039@freebsd-current.sentex.ca> Date: Sun, 24 Feb 2008 10:03:43 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 15:03:44 -0000 TB --- 2008-02-24 13:52:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-24 13:52:53 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-02-24 13:52:53 - cleaning the object tree TB --- 2008-02-24 13:53:14 - cvsupping the source tree TB --- 2008-02-24 13:53:14 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-02-24 13:53:20 - building world (CFLAGS=-O -pipe) TB --- 2008-02-24 13:53:20 - cd /src TB --- 2008-02-24 13:53:20 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 24 13:53:22 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 24 14:57:00 UTC 2008 TB --- 2008-02-24 14:57:00 - generating LINT kernel config TB --- 2008-02-24 14:57:00 - cd /src/sys/powerpc/conf TB --- 2008-02-24 14:57:00 - /usr/bin/make -B LINT TB --- 2008-02-24 14:57:00 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-24 14:57:00 - cd /src TB --- 2008-02-24 14:57:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 24 14:57:00 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/aim/vm_machdep.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/fpu/fpu_add.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/fpu/fpu_compare.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/fpu/fpu_div.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/powerpc/fpu/fpu_emu.c /src/sys/powerpc/fpu/fpu_emu.c:83:1: error: "DEBUG" redefined In file included from :0: ./opt_global.h:26:1: error: this is the location of the previous definition *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-24 15:03:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-24 15:03:42 - ERROR: failed to build lint kernel TB --- 2008-02-24 15:03:42 - tinderbox aborted TB --- 3121.74 user 367.02 system 4249.56 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 15:52:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AB8F16A401 for ; Sun, 24 Feb 2008 15:52:38 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id D623113C455 for ; Sun, 24 Feb 2008 15:52:37 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from chen-int.kitchenlab.org (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id m1OFqbfK012966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Feb 2008 07:52:37 -0800 Message-ID: <47C192C4.4080109@freebsd.org> Date: Sun, 24 Feb 2008 07:52:36 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Garrett Cooper References: <511FC3E9-937C-475C-8F1B-39BA5347DBE0@gmail.com> In-Reply-To: <511FC3E9-937C-475C-8F1B-39BA5347DBE0@gmail.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig34FD272CFC4F104F007F73F9" Cc: current@freebsd.org Subject: Re: Gathering a list of showstoppers for RELENG_7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 15:52:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig34FD272CFC4F104F007F73F9 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable If memory serves me right, Garrett Cooper wrote: > As part of the new Cisco FreeBSD ramp-up, I've noted that there's =20 > been some concern about showstoppers for RELENG_7 as of late. So, I =20 > was just wondering what the current showstoppers are for 7.x and =20 > possibly how I can help triage issues in the next couple weeks, etc, =20 > to accelerate the release a bit. > I may not have access to a PC at all times nor a FreeBSD machine, but = =20 > I should be able to assign bugs or CC owners, or help debug some more = > common items. I'll also try getting VMware fusion in the upcoming week = =20 > to work from my laptop and help out in some way shape or form in person= =2E The release builds for 7.0 are underway now. What oftentimes happens very late in the release cycle (and this was=20 true for 7.0) is that we find some issues that crop up that need to be=20 fixed. They're usually assigned pretty quickly to "owners" (in fact the = owners are oftentimes the ones that report these problems), so many=20 times there isn't a lot for other people to do, and these issues don't=20 even make it into the PR database. I admit that we could (and should) do better in communicating status to=20 other developers and the community at large. This is mostly helpful in=20 the early and middle stages of the release cycle. This is clearly *not* to say that FreeBSD doesn't need help with=20 testing, bug management, and so forth, in fact quite the opposite is=20 true. I mean only to say that 7.0 doesn't have anything blocking it. Thanks! Bruce. --------------enig34FD272CFC4F104F007F73F9 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 iD8DBQFHwZLF2MoxcVugUsMRAgXKAJ9aKBpYOpHd1ivj+ahyVqveJJjhYQCeIqrr Ts/19Tl3soZk+BScZ+vnIuA= =gYBA -----END PGP SIGNATURE----- --------------enig34FD272CFC4F104F007F73F9-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 16:22:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93A9116A404 for ; Sun, 24 Feb 2008 16:22:06 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 522BF13C465 for ; Sun, 24 Feb 2008 16:22:06 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so713667wfa.7 for ; Sun, 24 Feb 2008 08:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=XQ6MT6gGiNaomYQjZX6/kZLtz4JECzmuCDakwZ0FR6Y=; b=pIMjMHVGBrgrwXCq9mvyQMMAcgytt4fEA0JlgsJVodf8kQyZbTxfZqaFKZpYev/c01kC8GdsK123bQtatULYOh4oTMx4OWeZG3ofBuGCw9V0tg/FwvYxPw3Y3X2aKVdyXpzYi1mAfFQ0YW/vPQAMKTdnegQnp856TDf070AS6LE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=p2xnsJGEAY2zh1i3buNcVkj3fpt/G95zlW88Vz3Ekt3k7ISVxUS5Jl4qKj5CK4ELlcFgFpH+s8fsWntqviASUwHoEmRCJexCA/0WZXzxJZ0oM+LZWK61tOQ/mYiL45hyGdKG5EhUcrzp7iTGKrP1AQEK7P/O/5yrRxQiJ4ISY1I= Received: by 10.142.216.9 with SMTP id o9mr1248744wfg.226.1203868503658; Sun, 24 Feb 2008 07:55:03 -0800 (PST) Received: from ?10.2.0.131? ( [67.96.45.122]) by mx.google.com with ESMTPS id 20sm6949913wfi.14.2008.02.24.07.55.01 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Feb 2008 07:55:02 -0800 (PST) Message-Id: <73945518-70B0-415C-87B4-F014F1309DF6@gmail.com> From: Garrett Cooper To: Adrian Chadd In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 24 Feb 2008 07:56:12 -0800 References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> <86zlttqmc9.fsf@ds4.des.no> <1203686245.63435.12.camel@RabbitsDen> <86oda9oxxe.fsf@ds4.des.no> <1203692492.63435.16.camel@RabbitsDen> <86ablsabd0.fsf@ds4.des.no> <47C00F20.2090700@d80.iso100.no> <1203846877.7104.17.camel@localhost> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-current , Mikael Ikivesi Subject: Re: 2 core dumps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 16:22:06 -0000 On Feb 24, 2008, at 4:55 AM, Adrian Chadd wrote: > I'd suggest that you graph the whatever temperatures your laptop can > report under both FreeBSD and Linux. > > Laptops do get warm - especially if people do dumb things like > restrict airflow to where its needed - but if its getting too warm to > use then something's amiss. > > Powerd and friends job isn't to prevent the CPU from overheating, its > to step the CPU down a notch when its not being asked to do intensive > tasks. If your laptop can't sustain intensive tasks without crashing > then there's a fault in the laptop, either the design or your specific > unit. > > Graph the temperatures and see if the laptop runs noticably warmer > under FreeBSD than Linux. You might just find that "more work" is > being done under FreeBSD and its causing your hardware to fail. > > The backtraces are useless if your hardware is at fault. Discount the > hardware being at fault first. > > 2c, > > > adrian > (Who gave up trying to make this crap work on PCs and just bought an > iBook..) Yeah, well the thing is too that many OS'es will work your hardware differently. Solaris for example will work your hardware a lot more than Linux / FreeBSD. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 16:27:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1758E16A408 for ; Sun, 24 Feb 2008 16:27:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 86A2B13C448 for ; Sun, 24 Feb 2008 16:27:34 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so929638fgg.35 for ; Sun, 24 Feb 2008 08:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=CUtSSvzszt5jWIS2PLrEbFPN5UXi6BaeuQcx/sjwcYs=; b=VWkw7qHHN90och1/ULBK5ygUreTvDwLpQ4m2vSlG5Q3+SOchC0mEFbirVZn0yE6jHj/4OhQVHLF2Og5gavAogttUU70LLBL/0a118DvEkaFpH3oCTkrrzvGWippv3OwfU82ISeqDelGWTDcKvcY6tkjNXIcYQYHrGtWpjx6j0sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Y/TdMNWw48DTLEIl2G7UYzIfKUYrwBMtShznV4Sbf3gGZEm8r9wL0wSXkf6XRJAgGQSejI/VnCtwUVuCDJEb7+tM6gzYqkYhyfy8Z/C7AWwNBkFwSE0zuw23p62MRrvk8FgxaLDjZ36vJ7kQuVJ7YSPStmcHs3c3ZNBXN5oWI68= Received: by 10.86.99.9 with SMTP id w9mr1789200fgb.58.1203870453294; Sun, 24 Feb 2008 08:27:33 -0800 (PST) Received: by 10.86.30.17 with HTTP; Sun, 24 Feb 2008 08:27:33 -0800 (PST) Message-ID: <3bbf2fe10802240827l5a92c27cq82a39ccb4b8cb964@mail.gmail.com> Date: Sun, 24 Feb 2008 17:27:33 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Bryan Venteicher" In-Reply-To: <330977318.1351203756607522.JavaMail.root@zimbra> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <330977318.1351203756607522.JavaMail.root@zimbra> X-Google-Sender-Auth: 50a36e0a57b9afe0 Cc: freebsd-current@freebsd.org Subject: Re: panic: lock (smbsm) lockmgr does not match earlier (sleep mutex) lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 16:27:35 -0000 2008/2/23, Bryan Venteicher : > Hi, > > I receive the following panic "lock (smbsm) lockmgr does not match earlier (sleep mutex) lock" when loading the smbfs module on a recent current. > > Kernel dumps weren't configured on the particular machine. Here's the abbreviated relevant portions of the stack: > ... > nsmb_dev_load > smb_sm_init > smb_co_init > ... > enroll > panic > > In smb_co_init(), the same description/name is used to initialize both cp->co_interlock and cp->co_lock. Hello Bryan, could you please cvsup your sources and see if the problem is gone? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 17:11:56 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EBC116A403 for ; Sun, 24 Feb 2008 17:11:56 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63913.mail.re1.yahoo.com (web63913.mail.re1.yahoo.com [69.147.97.128]) by mx1.freebsd.org (Postfix) with SMTP id DA97B13C461 for ; Sun, 24 Feb 2008 17:11:55 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 99432 invoked by uid 60001); 24 Feb 2008 17:11:55 -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=fQbgl5yIpcIBng2JjMqQai06TaRRsEbxKsr4Vsxc/JBv/8Q9zkzV65LbTcmmieeTj8pptuQttr++arJZeHeRaI9DkhSxc7hLLXduyL5rpwZ6TDPUaWn/j3ZHfAzblqjm+Q3sAXvPywlrZwnX74IfhrbrhITHF9/bQgqaIEDM+sg=; X-YMail-OSG: mSq6JRgVM1miyuZvBSWeH1YVIZwAvxWj192idXEsmmoHrm3avRX5FnlGzVLNjlejOZ4oIk67M8R24oRdaB9yOL1zm1lMaXDFGJym_X8yer05JhU8uU4- Received: from [98.203.28.38] by web63913.mail.re1.yahoo.com via HTTP; Sun, 24 Feb 2008 09:11:55 PST Date: Sun, 24 Feb 2008 09:11:55 -0800 (PST) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <36288.99187.qm@web63913.mail.re1.yahoo.com> Cc: Subject: Error when Bridging - Synchronization problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 17:11:56 -0000 I have a 7.0 system set up as a bridge and I'm passing a lot of traffic through it. Occasionally I get messages like: rtfree: 0xc50b8e10 has 1 refs Clearly someone left this trace code in for a reason. Is there a problem with the bridge? Is this an error code? I'm both passing traffic through the bridge bge0 <--> bge1 and also into the machine's IP stack via bge0 via a telnet loop. Barney ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 16:55:39 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E8E616A403 for ; Sun, 24 Feb 2008 16:55:39 +0000 (UTC) (envelope-from will.froning@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 625D413C45A for ; Sun, 24 Feb 2008 16:55:39 +0000 (UTC) (envelope-from will.froning@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1380111waf.3 for ; Sun, 24 Feb 2008 08:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=u081kssguaKCZQwoOiSSacjffllctDZn8Hm4zH/FDRE=; b=lR4nmT/8BrT1VFgBK7yFAalpfFVkK7nIki9eVuaByemChK3mwp+Vp4WA8Yf9gclxJ7jSTq3FR0O32cQq4gpGi9DNZeDw7/ssKYW0qEgA6CXhO7YFAsEEjoMO9AYLHA4RcgZ8xQWCtMsNZjG6GLUkaBrNXLQVpS7lrtWdjYu52zw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dRUfPxPMwA0KKjskSmR+FoVZxCx6MOXvt3hBiAWx8FWOeC06iIr+yLXtbbQzuVy6izrNbbJtR6Ib+Wc5oWmOEqQnfSTUWQZaPEyork2U22gfsYuuVFgEG2FPyrdUeXQBPnuPVgIfnl54SYAZNCSuaSPiwmZelcmm96AamGOJp1o= Received: by 10.114.124.1 with SMTP id w1mr2124439wac.114.1203870580171; Sun, 24 Feb 2008 08:29:40 -0800 (PST) Received: by 10.114.193.17 with HTTP; Sun, 24 Feb 2008 08:29:40 -0800 (PST) Message-ID: Date: Sun, 24 Feb 2008 20:29:40 +0400 From: "Will Froning" To: "Bruce A. Mah" In-Reply-To: <47C192C4.4080109@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <511FC3E9-937C-475C-8F1B-39BA5347DBE0@gmail.com> <47C192C4.4080109@freebsd.org> X-Mailman-Approved-At: Sun, 24 Feb 2008 17:18:46 +0000 Cc: Garrett Cooper , current@freebsd.org Subject: Re: Gathering a list of showstoppers for RELENG_7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 16:55:39 -0000 Hello All, On Sun, Feb 24, 2008 at 7:52 PM, Bruce A. Mah wrote: > If memory serves me right, Garrett Cooper wrote: > > > As part of the new Cisco FreeBSD ramp-up, I've noted that there's > > been some concern about showstoppers for RELENG_7 as of late. So, I > > was just wondering what the current showstoppers are for 7.x and > > possibly how I can help triage issues in the next couple weeks, etc, > > to accelerate the release a bit. > > I may not have access to a PC at all times nor a FreeBSD machine, but > > I should be able to assign bugs or CC owners, or help debug some more > > common items. I'll also try getting VMware fusion in the upcoming week > > to work from my laptop and help out in some way shape or form in person. > > The release builds for 7.0 are underway now. > > What oftentimes happens very late in the release cycle (and this was > true for 7.0) is that we find some issues that crop up that need to be > fixed. They're usually assigned pretty quickly to "owners" (in fact the > owners are oftentimes the ones that report these problems), so many > times there isn't a lot for other people to do, and these issues don't > even make it into the PR database. > > I admit that we could (and should) do better in communicating status to > other developers and the community at large. This is mostly helpful in > the early and middle stages of the release cycle. > > This is clearly *not* to say that FreeBSD doesn't need help with > testing, bug management, and so forth, in fact quite the opposite is > true. I mean only to say that 7.0 doesn't have anything blocking it. Does that mean is outdated? /me is sooooo looking forward to a killer release! Thanks, Will > > Thanks! > > Bruce. > > -- Will Froning Unix SysAdmin Will.Froning@GMail.com MSN: wfroning@angui.sh YIM: will_froning AIM: willfroning From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 18:04:37 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9475E16A400; Sun, 24 Feb 2008 18:04:37 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5171513C44B; Sun, 24 Feb 2008 18:04:37 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1OI4XCb022648; Sun, 24 Feb 2008 10:04:33 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1OI4XL1022647; Sun, 24 Feb 2008 10:04:33 -0800 (PST) (envelope-from obrien) Date: Sun, 24 Feb 2008 10:04:33 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080224180433.GA21162@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy , current@FreeBSD.org References: <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080223201808.GB65540@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Dag-Erling Sm??rgrav , current@FreeBSD.org, Kai Wang , Joseph Koshy Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 18:04:37 -0000 On Sat, Feb 23, 2008 at 11:18:08PM +0300, Ruslan Ermilov wrote: > now bootstrap BSD ar on systems >700044, and that we call > GNU ar/ranlib with the "g" prefix instead of "gnu-". Why are you going against my preferences for "gnu-" - if I liked "g" I would have done it that way in my patch. Its seems those that have expressed an opinion want to switch to the new 'ar' ASAP. So why not this patch? (BTW, what is the sort order in Makefile.inc1? BOOTSTRAPPING date and alphabetical?) Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.593 diff -u -p -r1.593 Makefile.inc1 --- Makefile.inc1 21 Jan 2008 18:44:54 -0000 1.593 +++ Makefile.inc1 24 Feb 2008 18:03:35 -0000 @@ -876,8 +876,13 @@ _gensnmptree= usr.sbin/bsnmpd/gensnmptre _crunchgen= usr.sbin/crunch/crunchgen .endif +.if ${BOOTSTRAPPING} >= 700044 +_ar= usr.bin/ar +.endif + bootstrap-tools: .for _tool in \ + ${_ar} \ ${_strfile} \ ${_gperf} \ ${_groff} \ Index: usr.bin/ar/Makefile =================================================================== RCS file: /home/ncvs/src/usr.bin/ar/Makefile,v retrieving revision 1.19 diff -u -p -r1.19 Makefile --- usr.bin/ar/Makefile 22 Feb 2008 06:53:52 -0000 1.19 +++ usr.bin/ar/Makefile 24 Feb 2008 17:53:29 -0000 @@ -1,10 +1,6 @@ # $FreeBSD: src/usr.bin/ar/Makefile,v 1.19 2008/02/22 06:53:52 obrien Exp $ -.if defined(WITH_BSDAR) PROG= ar -.else -PROG= bsdar -.endif SRCS= ar.c read.c util.c write.c WARNS?= 5 @@ -12,17 +8,8 @@ WARNS?= 5 DPADD= ${LIBARCHIVE} ${LIBBZ2} ${LIBZ} ${LIBELF} LDADD= -larchive -lbz2 -lz -lelf -.if defined(WITH_BSDAR) NO_SHARED?= yes LINKS= ${BINDIR}/ar ${BINDIR}/ranlib -MLINKS= ar ranlib -.else -LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib -MLINKS= bsdar.1 bsdranlib.1 - -CLEANFILES+= bsdar.1 -bsdar.1: ar.1 - ln -sf ${.ALLSRC} ${.TARGET} -.endif +MLINKS= ar.1 ranlib.1 .include Index: gnu/usr.bin/binutils/ar/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ar/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- gnu/usr.bin/binutils/ar/Makefile 21 Feb 2008 16:59:02 -0000 1.16 +++ gnu/usr.bin/binutils/ar/Makefile 24 Feb 2008 17:55:19 -0000 @@ -4,12 +4,7 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) PROG= gnu-ar -#MAN= gnu-ar.1 -.else -PROG= ar -.endif SRCS= ar.c not-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils @@ -21,4 +16,8 @@ DPADD+= ${RELTOP}/libbfd/libbfd.a DPADD+= ${RELTOP}/libiberty/libiberty.a LDADD= ${DPADD} +CLEANFILES+= gnu-ar.1 +gnu-ar.1: ar.1 + ln -sf ${.ALLSRC} ${.TARGET} + .include Index: gnu/usr.bin/binutils/ranlib/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ranlib/Makefile,v retrieving revision 1.17 diff -u -p -r1.17 Makefile --- gnu/usr.bin/binutils/ranlib/Makefile 21 Feb 2008 16:59:02 -0000 1.17 +++ gnu/usr.bin/binutils/ranlib/Makefile 24 Feb 2008 17:56:21 -0000 @@ -4,12 +4,7 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) PROG= gnu-ranlib -#MAN= gnu-ranlib.1 -.else -PROG= ranlib -.endif SRCS= ar.c is-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils @@ -21,4 +16,8 @@ DPADD+= ${RELTOP}/libbfd/libbfd.a DPADD+= ${RELTOP}/libiberty/libiberty.a LDADD= ${DPADD} +CLEANFILES+= gnu-ranlib.1 +gnu-ranlib.1: ar.1 + ln -sf ${.ALLSRC} ${.TARGET} + .include From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 18:10:05 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B78716A41B; Sun, 24 Feb 2008 18:10:05 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id D1BF413C4EA; Sun, 24 Feb 2008 18:10:04 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1OIA4TE022935; Sun, 24 Feb 2008 10:10:04 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1OIA4d7022934; Sun, 24 Feb 2008 10:10:04 -0800 (PST) (envelope-from obrien) Date: Sun, 24 Feb 2008 10:10:04 -0800 From: "David O'Brien" To: Ruslan Ermilov , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org Message-ID: <20080224181004.GC21162@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org References: <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> <20080222105413.GD94607@team.vega.ru> <20080222170007.GA2622@plan0.kaiwan.csbnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080222170007.GA2622@plan0.kaiwan.csbnet.se> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 18:10:05 -0000 On Fri, Feb 22, 2008 at 06:00:07PM +0100, Kai Wang wrote: > Would it be better if we call them gar and granlib? Solaris did > that. Also if I remember correctly, some ports probes gar. We also > call GNU make as gmake... Why do we want I don't like "gar" as that is pronounceable to the point I could easily see that being the real name of an existing program. Also, why do we want ports using gnu-ar specifically vs. what ever is our native 'ar'? If our native 'ar' isn't up to the task, we shouldn't be doing this endeavor at all. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 18:35:00 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 593CF16A403 for ; Sun, 24 Feb 2008 18:35:00 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 293BB13C455 for ; Sun, 24 Feb 2008 18:35:00 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from chen-int.kitchenlab.org (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id m1OIYwIu024815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Feb 2008 10:34:58 -0800 Message-ID: <47C1B8CE.9060507@freebsd.org> Date: Sun, 24 Feb 2008 10:34:54 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Will Froning References: <511FC3E9-937C-475C-8F1B-39BA5347DBE0@gmail.com> <47C192C4.4080109@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig526BC3BACB475ADBF7DB842B" Cc: Garrett Cooper , current@freebsd.org Subject: Re: Gathering a list of showstoppers for RELENG_7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 18:35:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig526BC3BACB475ADBF7DB842B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable If memory serves me right, Will Froning wrote: > Hello All, >=20 > On Sun, Feb 24, 2008 at 7:52 PM, Bruce A. Mah wrote:= >> If memory serves me right, Garrett Cooper wrote: >> >> > As part of the new Cisco FreeBSD ramp-up, I've noted that the= re's >> > been some concern about showstoppers for RELENG_7 as of late. So, I= >> > was just wondering what the current showstoppers are for 7.x and >> > possibly how I can help triage issues in the next couple weeks, etc= , >> > to accelerate the release a bit. >> > I may not have access to a PC at all times nor a FreeBSD mach= ine, but >> > I should be able to assign bugs or CC owners, or help debug some mo= re >> > common items. I'll also try getting VMware fusion in the upcoming w= eek >> > to work from my laptop and help out in some way shape or form in pe= rson. >> >> The release builds for 7.0 are underway now. >> >> What oftentimes happens very late in the release cycle (and this was >> true for 7.0) is that we find some issues that crop up that need to b= e >> fixed. They're usually assigned pretty quickly to "owners" (in fact = the >> owners are oftentimes the ones that report these problems), so many >> times there isn't a lot for other people to do, and these issues don'= t >> even make it into the PR database. >> >> I admit that we could (and should) do better in communicating status = to >> other developers and the community at large. This is mostly helpful = in >> the early and middle stages of the release cycle. >> >> This is clearly *not* to say that FreeBSD doesn't need help with >> testing, bug management, and so forth, in fact quite the opposite is >> true. I mean only to say that 7.0 doesn't have anything blocking it.= >=20 > Does that mean is outd= ated? The libkse item was fixed in early February, but we didn't note it here. = I just updated it...thanks for pointing that out! > /me is sooooo looking forward to a killer release! /me too! There *are* some outstanding issues in 7.0, for which we're=20 contemplating some errata notices (and hence patches for RELENG_7_0).=20 I'm being deliberately vague here because I don't want to commit us to=20 anything yet, but two *possible* items are some if_re fixes and a change = in TCP options handling. For errata items, we need to wait for the=20 actual release to wrap up (duh) and also give the fixes some "soak time" = in HEAD and RELENG_7. Cheers, Bruce. --------------enig526BC3BACB475ADBF7DB842B 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 iD8DBQFHwbjS2MoxcVugUsMRAn/5AJ9bRstJzLljJ0uRiWOXlyz0qIMVswCgtrOb g00HulEk+K4bDjZimZg/tOw= =ydzi -----END PGP SIGNATURE----- --------------enig526BC3BACB475ADBF7DB842B-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 18:44:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7275A16A401 for ; Sun, 24 Feb 2008 18:44:20 +0000 (UTC) (envelope-from antonfb@hesiod.org) Received: from paris.hesiod.org (unknown [IPv6:2001:470:1f04:d1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4FB0013C455 for ; Sun, 24 Feb 2008 18:44:19 +0000 (UTC) (envelope-from antonfb@hesiod.org) Received: from atlas.hesiod.org (atlas.hesiod.org [192.168.1.9]) by paris.hesiod.org (8.14.2/8.14.2) with ESMTP id m1OIiGUC040408 for ; Sun, 24 Feb 2008 10:44:18 -0800 (PST) (envelope-from antonfb@hesiod.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hesiod.org; s=dec07; t=1203878659; bh=hF3/yjy8lp9PoAbVF9cEsp9biPy7avtRv8anbgEZhHU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject; b=y3XKJe JPGUyadF1Wk208lIhmgWLwKUaYOZpPweNc6FSWDFfXjYDprzw1muObumTGBW6pMBYzY pd8BznS6J4TI5RAQuj4/Ztg+M/aJJTQqFKYgSOyaGURCxV7EjWeFsc90R9J2SZzAqEj 39kxUxuQwmHjxebhsZwx+e3T6Fl8dfc= DomainKey-Signature: a=rsa-sha1; s=dec07; d=hesiod.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject; b=Kxn1qt6kC+icTzFgSg4ofm/N8BeSabyUwuq4dHpCQsCBeul+b2hX0VedGHlh30xym JGDiaF6LesdVqW6XfWh+j8xwPEpHqam/6d3MOTa6dYynG4v3bxIY+i5o7JB5cZJhgrF UqoE3Yl8QIzMfUZvGAcDk0lMcxLSOVBcdlurbGU= Message-ID: <47C1BB00.7030506@hesiod.org> Date: Sun, 24 Feb 2008 10:44:16 -0800 From: Jeff Anton User-Agent: Thunderbird 2.0.0.9 (X11/20080124) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------050701060202070407080402" Subject: lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 18:44:20 -0000 This is a multi-part message in MIME format. --------------050701060202070407080402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, FYI: I just built a new kernel and I'm getting a bunch of lock order reversal reports. No apparent ill effects, but disconcerting. I built my last kernel, which did not complain, on Feb 3rd. Jeff Anton --------------050701060202070407080402 Content-Type: text/plain; name="lockorder.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lockorder.txt" Feb 24 09:07:45 atlas login: ROOT LOGIN (root) ON ttyv0 Feb 24 09:08:43 atlas reboot: rebooted by root Feb 24 09:08:44 atlas syslogd: exiting on signal 15 Feb 24 09:17:23 atlas syslogd: kernel boot file is /boot/kernel/kernel Feb 24 09:17:23 atlas kernel: Copyright (c) 1992-2008 The FreeBSD Project. Feb 24 09:17:23 atlas kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Feb 24 09:17:23 atlas kernel: The Regents of the University of California. All rights reserved. Feb 24 09:17:23 atlas kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Feb 24 09:17:23 atlas kernel: FreeBSD 8.0-CURRENT #0: Sun Feb 24 00:18:09 PST 2008 Feb 24 09:17:23 atlas kernel: anton@atlas.hesiod.org:/usr/src/sys/i386/compile/ATLAS Feb 24 09:17:23 atlas kernel: WARNING: WITNESS option enabled, expect reduced performance. Feb 24 09:17:23 atlas kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Feb 24 09:17:23 atlas kernel: CPU: Dual Core AMD Opteron(tm) Processor 165 (1808.34-MHz 686-class CPU) Feb 24 09:17:23 atlas kernel: Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Feb 24 09:17:23 atlas kernel: Features=0x178bfbff Feb 24 09:17:23 atlas kernel: Features2=0x1 Feb 24 09:17:23 atlas kernel: AMD Features=0xe2500800 Feb 24 09:17:23 atlas kernel: AMD Features2=0x3 Feb 24 09:17:23 atlas kernel: Cores per package: 2 Feb 24 09:17:23 atlas kernel: real memory = 2146304000 (2046 MB) Feb 24 09:17:23 atlas kernel: avail memory = 2097061888 (1999 MB) Feb 24 09:17:23 atlas kernel: ACPI APIC Table: Feb 24 09:17:23 atlas kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Feb 24 09:17:23 atlas kernel: cpu0 (BSP): APIC ID: 0 Feb 24 09:17:23 atlas kernel: cpu1 (AP): APIC ID: 1 Feb 24 09:17:23 atlas kernel: ioapic0: Changing APIC ID to 2 Feb 24 09:17:23 atlas kernel: ioapic0 irqs 0-23 on motherboard Feb 24 09:17:23 atlas kernel: kbd1 at kbdmux0 Feb 24 09:17:23 atlas kernel: acpi0: on motherboard Feb 24 09:17:23 atlas kernel: acpi0: [ITHREAD] Feb 24 09:17:23 atlas kernel: acpi0: Power Button (fixed) Feb 24 09:17:23 atlas kernel: acpi0: reservation of 0, a0000 (3) failed Feb 24 09:17:23 atlas kernel: acpi0: reservation of 100000, 7fde0000 (3) failed Feb 24 09:17:23 atlas kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Feb 24 09:17:23 atlas kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Feb 24 09:17:23 atlas kernel: cpu0: on acpi0 Feb 24 09:17:23 atlas kernel: powernow0: on cpu0 Feb 24 09:17:23 atlas kernel: cpu1: on acpi0 Feb 24 09:17:23 atlas kernel: powernow1: on cpu1 Feb 24 09:17:23 atlas kernel: acpi_button0: on acpi0 Feb 24 09:17:23 atlas kernel: pcib0: port 0xcf8-0xcff on acpi0 Feb 24 09:17:23 atlas kernel: pci0: on pcib0 Feb 24 09:17:23 atlas kernel: pci0: at device 0.0 (no driver attached) Feb 24 09:17:23 atlas kernel: isab0: at device 1.0 on pci0 Feb 24 09:17:23 atlas kernel: isa0: on isab0 Feb 24 09:17:23 atlas kernel: pci0: at device 1.1 (no driver attached) Feb 24 09:17:23 atlas kernel: ohci0: mem 0xfebff000-0xfebfffff irq 21 at device 2.0 on pci0 Feb 24 09:17:23 atlas kernel: ohci0: [GIANT-LOCKED] Feb 24 09:17:23 atlas kernel: ohci0: [ITHREAD] Feb 24 09:17:23 atlas kernel: usb0: OHCI version 1.0, legacy support Feb 24 09:17:23 atlas kernel: usb0: on ohci0 Feb 24 09:17:23 atlas kernel: usb0: USB revision 1.0 Feb 24 09:17:23 atlas kernel: uhub0: on usb0 Feb 24 09:17:23 atlas kernel: uhub0: 8 ports with 8 removable, self powered Feb 24 09:17:23 atlas kernel: ehci0: mem 0xfeb00000-0xfeb000ff irq 22 at device 2.1 on pci0 Feb 24 09:17:23 atlas kernel: ehci0: [GIANT-LOCKED] Feb 24 09:17:23 atlas kernel: ehci0: [ITHREAD] Feb 24 09:17:23 atlas kernel: usb1: waiting for BIOS to give up control Feb 24 09:17:23 atlas kernel: usb1: timed out waiting for BIOS Feb 24 09:17:23 atlas kernel: usb1: EHCI version 1.0 Feb 24 09:17:23 atlas kernel: usb1: companion controller, 4 ports each: usb0 Feb 24 09:17:23 atlas kernel: usb1: on ehci0 Feb 24 09:17:23 atlas kernel: usb1: USB revision 2.0 Feb 24 09:17:23 atlas kernel: uhub1: on usb1 Feb 24 09:17:23 atlas kernel: uhub1: 8 ports with 8 removable, self powered Feb 24 09:17:23 atlas kernel: pci0: at device 4.0 (no driver attached) Feb 24 09:17:23 atlas kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 6.0 on pci0 Feb 24 09:17:23 atlas kernel: ata0: on atapci0 Feb 24 09:17:23 atlas kernel: ata0: [ITHREAD] Feb 24 09:17:23 atlas kernel: ata1: on atapci0 Feb 24 09:17:23 atlas kernel: ata1: [ITHREAD] Feb 24 09:17:23 atlas kernel: atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xcc00-0xcc0f mem 0xfebfb000-0xfebfbfff irq 21 at device 7.0 on pci0 Feb 24 09:17:23 atlas kernel: atapci1: [ITHREAD] Feb 24 09:17:23 atlas kernel: ata2: on atapci1 Feb 24 09:17:23 atlas kernel: ata2: [ITHREAD] Feb 24 09:17:23 atlas kernel: ata3: on atapci1 Feb 24 09:17:23 atlas kernel: ata3: [ITHREAD] Feb 24 09:17:23 atlas kernel: atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xb800-0xb80f mem 0xfebfa000-0xfebfafff irq 22 at device 8.0 on pci0 Feb 24 09:17:23 atlas kernel: atapci2: [ITHREAD] Feb 24 09:17:23 atlas kernel: ata4: on atapci2 Feb 24 09:17:23 atlas kernel: ata4: [ITHREAD] Feb 24 09:17:23 atlas kernel: ata5: on atapci2 Feb 24 09:17:23 atlas kernel: ata5: [ITHREAD] Feb 24 09:17:23 atlas kernel: pcib1: at device 9.0 on pci0 Feb 24 09:17:23 atlas kernel: pci1: on pcib1 Feb 24 09:17:23 atlas kernel: vgapci0: port 0xac00-0xacff mem 0xfa000000-0xfaffffff,0xfdfff000-0xfdffffff irq 19 at device 5.0 on pci1 Feb 24 09:17:23 atlas kernel: fwohci0: port 0xa800-0xa87f mem 0xfdffe000-0xfdffe7ff irq 18 at device 6.0 on pci1 Feb 24 09:17:23 atlas kernel: fwohci0: [FILTER] Feb 24 09:17:23 atlas kernel: fwohci0: OHCI version 1.10 (ROM=1) Feb 24 09:17:23 atlas kernel: fwohci0: No. of Isochronous channels is 4. Feb 24 09:17:23 atlas kernel: fwohci0: EUI64 00:e0:81:00:00:23:9b:90 Feb 24 09:17:23 atlas kernel: fwohci0: Phy 1394a available S400, 2 ports. Feb 24 09:17:23 atlas kernel: fwohci0: Link S400, max_rec 2048 bytes. Feb 24 09:17:23 atlas kernel: firewire0: on fwohci0 Feb 24 09:17:23 atlas kernel: sbp0: on firewire0 Feb 24 09:17:23 atlas kernel: dcons_crom0: on firewire0 Feb 24 09:17:23 atlas kernel: dcons_crom0: bus_addr 0x142c000 Feb 24 09:17:23 atlas kernel: fwe0: on firewire0 Feb 24 09:17:23 atlas kernel: if_fwe0: Fake Ethernet address: 02:e0:81:23:9b:90 Feb 24 09:17:23 atlas kernel: fwe0: Ethernet address: 02:e0:81:23:9b:90 Feb 24 09:17:23 atlas kernel: fwip0: on firewire0 Feb 24 09:17:23 atlas kernel: fwip0: Firewire address: 00:e0:81:00:00:23:9b:90 @ 0xfffe00000000, S400, maxrec 2048 Feb 24 09:17:23 atlas kernel: fwohci0: Initiate bus reset Feb 24 09:17:23 atlas kernel: fwohci0: BUS reset Feb 24 09:17:23 atlas kernel: fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode Feb 24 09:17:23 atlas kernel: pci1: at device 9.0 (no driver attached) Feb 24 09:17:23 atlas kernel: pci1: at device 9.2 (no driver attached) Feb 24 09:17:23 atlas kernel: nfe0: port 0xb400-0xb407 mem 0xfebf9000-0xfebf9fff irq 23 at device 10.0 on pci0 Feb 24 09:17:23 atlas kernel: miibus0: on nfe0 Feb 24 09:17:23 atlas kernel: e1000phy0: PHY 1 on miibus0 Feb 24 09:17:23 atlas kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto Feb 24 09:17:23 atlas kernel: nfe0: Ethernet address: 00:e0:81:55:11:4c Feb 24 09:17:23 atlas kernel: nfe0: [FILTER] Feb 24 09:17:23 atlas kernel: pcib2: at device 11.0 on pci0 Feb 24 09:17:23 atlas kernel: pci2: on pcib2 Feb 24 09:17:23 atlas kernel: pcib3: at device 12.0 on pci0 Feb 24 09:17:23 atlas kernel: pci3: on pcib3 Feb 24 09:17:23 atlas kernel: pcib4: at device 13.0 on pci0 Feb 24 09:17:23 atlas kernel: pci4: on pcib4 Feb 24 09:17:23 atlas kernel: bge0: mem 0xfe5f0000-0xfe5fffff irq 19 at device 0.0 on pci4 Feb 24 09:17:23 atlas kernel: miibus1: on bge0 Feb 24 09:17:23 atlas kernel: brgphy0: PHY 1 on miibus1 Feb 24 09:17:23 atlas kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Feb 24 09:17:23 atlas kernel: bge0: Ethernet address: 00:e0:81:55:11:4b Feb 24 09:17:23 atlas kernel: bge0: [ITHREAD] Feb 24 09:17:23 atlas kernel: pcib5: at device 14.0 on pci0 Feb 24 09:17:23 atlas kernel: pci5: on pcib5 Feb 24 09:17:23 atlas kernel: vgapci1: mem 0xf7000000-0xf7ffffff,0xd8000000-0xdfffffff,0xf8000000-0xf8ffffff irq 18 at device 0.0 on pci5 Feb 24 09:17:23 atlas kernel: acpi_tz0: on acpi0 Feb 24 09:17:23 atlas kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Feb 24 09:17:23 atlas kernel: sio0: type 16550A Feb 24 09:17:23 atlas kernel: sio0: [FILTER] Feb 24 09:17:23 atlas kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 Feb 24 09:17:23 atlas kernel: sio1: type 16550A Feb 24 09:17:23 atlas kernel: sio1: [FILTER] Feb 24 09:17:23 atlas kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Feb 24 09:17:23 atlas kernel: atkbd0: irq 1 on atkbdc0 Feb 24 09:17:23 atlas kernel: kbd0 at atkbd0 Feb 24 09:17:23 atlas kernel: atkbd0: [GIANT-LOCKED] Feb 24 09:17:23 atlas kernel: atkbd0: [ITHREAD] Feb 24 09:17:23 atlas kernel: psm0: irq 12 on atkbdc0 Feb 24 09:17:23 atlas kernel: psm0: [GIANT-LOCKED] Feb 24 09:17:23 atlas kernel: psm0: [ITHREAD] Feb 24 09:17:23 atlas kernel: psm0: model Generic PS/2 mouse, device ID 0 Feb 24 09:17:23 atlas kernel: cryptosoft0: on motherboard Feb 24 09:17:23 atlas kernel: pmtimer0 on isa0 Feb 24 09:17:23 atlas kernel: orm0: at iomem 0xd0000-0xd3fff,0xd4000-0xd57ff pnpid ORM0000 on isa0 Feb 24 09:17:23 atlas kernel: sc0: at flags 0x100 on isa0 Feb 24 09:17:23 atlas kernel: sc0: VGA <16 virtual consoles, flags=0x300> Feb 24 09:17:23 atlas kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Feb 24 09:17:23 atlas kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 Feb 24 09:17:23 atlas kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Feb 24 09:17:23 atlas kernel: ppc0: FIFO with 16/16/8 bytes threshold Feb 24 09:17:23 atlas kernel: ppbus0: on ppc0 Feb 24 09:17:23 atlas kernel: ppbus0: [ITHREAD] Feb 24 09:17:23 atlas kernel: plip0: on ppbus0 Feb 24 09:17:23 atlas kernel: lpt0: on ppbus0 Feb 24 09:17:23 atlas kernel: lpt0: Interrupt-driven port Feb 24 09:17:23 atlas kernel: ppi0: on ppbus0 Feb 24 09:17:23 atlas kernel: ppc0: [GIANT-LOCKED] Feb 24 09:17:23 atlas kernel: ppc0: [ITHREAD] Feb 24 09:17:23 atlas kernel: Timecounters tick every 1.000 msec Feb 24 09:17:23 atlas kernel: Fast IPsec: Initialized Security Association Processing. Feb 24 09:17:23 atlas kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Feb 24 09:17:23 atlas kernel: firewire0: bus manager 0 (me) Feb 24 09:17:23 atlas kernel: ad0: 238475MB at ata0-master UDMA133 Feb 24 09:17:23 atlas kernel: ad1: 476940MB at ata0-slave UDMA100 Feb 24 09:17:23 atlas kernel: acd0: DVDR at ata1-slave UDMA66 Feb 24 09:17:23 atlas kernel: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 Feb 24 09:17:23 atlas kernel: cd0 at ata1 bus 0 target 1 lun 0 Feb 24 09:17:23 atlas kernel: cd0: Removable CD-ROM SCSI-0 device Feb 24 09:17:23 atlas kernel: cd0: 66.000MB/s transfers Feb 24 09:17:23 atlas kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present Feb 24 09:17:23 atlas kernel: SMP: AP CPU #1 Launched! Feb 24 09:17:23 atlas kernel: WARNING: WITNESS option enabled, expect reduced performance. Feb 24 09:17:23 atlas kernel: lock order reversal: Feb 24 09:17:23 atlas kernel: 1st 0xc4dc8e28 devfs (devfs) @ kern/vfs_subr.c:2061 Feb 24 09:17:23 atlas kernel: 2nd 0xc4f140d4 devfsmount (devfsmount) @ fs/devfs/devfs_vnops.c:201 Feb 24 09:17:23 atlas kernel: KDB: stack backtrace: Feb 24 09:17:23 atlas kernel: db_trace_self_wrapper(c082dec3,e36fabbc,c05c2a0e,c08302e2,c4f140d4,...) at db_trace_self_wrapper+0x26 Feb 24 09:17:23 atlas kernel: kdb_backtrace(c08302e2,c4f140d4,c0821a30,c0821a30,c0821a7a,...) at kdb_backtrace+0x29 Feb 24 09:17:23 atlas kernel: witness_checkorder(c4f140d4,9,c0821a71,c9,c7,...) at witness_checkorder+0x6de Feb 24 09:17:23 atlas kernel: _sx_xlock(c4f140d4,0,c0821a71,c9,c4f140d4,...) at _sx_xlock+0x7d Feb 24 09:17:23 atlas kernel: devfs_allocv(c4f23200,c4f4c000,e36fac28,c4b19cc0,c0835fdf,...) at devfs_allocv+0x144 Feb 24 09:17:23 atlas kernel: devfs_root(c4f4c000,2,c0917218,c4b19cc0,ca,...) at devfs_root+0x51 Feb 24 09:17:23 atlas kernel: set_rootvnode(c0917200,0,c0835fd6,5f4,c0600210,...) at set_rootvnode+0x2b Feb 24 09:17:23 atlas kernel: vfs_mountroot(c08c4e30,4,c0825e57,260,0,...) at vfs_mountroot+0x356 Feb 24 09:17:23 atlas kernel: start_init(0,e36fad38,c0827746,30c,c4b17ab0,...) at start_init+0x65 Feb 24 09:17:23 atlas kernel: fork_exit(c0552070,0,e36fad38) at fork_exit+0xb8 Feb 24 09:17:23 atlas kernel: fork_trampoline() at fork_trampoline+0x8 Feb 24 09:17:23 atlas kernel: --- trap 0, eip = 0, esp = 0xe36fad70, ebp = 0 --- Feb 24 09:17:23 atlas kernel: Trying to mount root from ufs:/dev/ad0s1a Feb 24 09:17:23 atlas kernel: lock order reversal: Feb 24 09:17:23 atlas kernel: 1st 0xc4f6f168 ufs (ufs) @ kern/vfs_subr.c:2061 Feb 24 09:17:23 atlas kernel: 2nd 0xc4f4c000 vfslock (vfslock) @ kern/vfs_subr.c:364 Feb 24 09:17:23 atlas kernel: KDB: stack backtrace: Feb 24 09:17:23 atlas kernel: db_trace_self_wrapper(c082dec3,e36fa9d8,c05c2a0e,c08302e2,c4f4c000,...) at db_trace_self_wrapper+0x26 Feb 24 09:17:23 atlas kernel: kdb_backtrace(c08302e2,c4f4c000,c08360d0,c08360d0,c0836676,...) at kdb_backtrace+0x29 Feb 24 09:17:23 atlas kernel: witness_checkorder(c4f4c000,1,c083666d,16c,e36faa18,...) at witness_checkorder+0x6de Feb 24 09:17:23 atlas kernel: _lockmgr_args(c4f4c000,2001,c4f4c030,0,ffffffff,...) at _lockmgr_args+0x1d5 Feb 24 09:17:23 atlas kernel: vfs_busy(c4f4c000,0,0,c4b19cc0,e36fab58,...) at vfs_busy+0x1b0 Feb 24 09:17:23 atlas kernel: lookup(e36fab44,c0835d88,c6,bf,c4aee42c,...) at lookup+0x7b4 Feb 24 09:17:23 atlas kernel: namei(e36fab44,c4f4c030,1c1,c0835fd6,e36fab54,...) at namei+0x34b Feb 24 09:17:23 atlas kernel: kern_unlink(c4b19cc0,c083640f,1,62f,0,...) at kern_unlink+0x40 Feb 24 09:17:23 atlas kernel: vfs_mountroot_try(c08365c9,c0824b90,c081f8fa,1,c0600210,...) at vfs_mountroot_try+0x470 Feb 24 09:17:23 atlas kernel: vfs_mountroot(c08c4e30,4,c0825e57,260,0,...) at vfs_mountroot+0x418 Feb 24 09:17:23 atlas kernel: start_init(0,e36fad38,c0827746,30c,c4b17ab0,...) at start_init+0x65 Feb 24 09:17:23 atlas kernel: fork_exit(c0552070,0,e36fad38) at fork_exit+0xb8 Feb 24 09:17:23 atlas kernel: fork_trampoline() at fork_trampoline+0x8 Feb 24 09:17:23 atlas kernel: --- trap 0, eip = 0, esp = 0xe36fad70, ebp = 0 --- Feb 24 09:17:23 atlas kernel: lock order reversal: Feb 24 09:17:23 atlas kernel: 1st 0xc4b1d044 user map (user map) @ vm/vm_map.c:3111 Feb 24 09:17:23 atlas kernel: 2nd 0xc4dc9e28 ufs (ufs) @ kern/vfs_subr.c:2061 Feb 24 09:17:23 atlas kernel: KDB: stack backtrace: Feb 24 09:17:23 atlas kernel: db_trace_self_wrapper(c082dec3,e36fa9c4,c05c2a0e,c08302e2,c4dc9e28,...) at db_trace_self_wrapper+0x26 Feb 24 09:17:23 atlas kernel: kdb_backtrace(c08302e2,c4dc9e28,c082542c,c082542c,c0836676,...) at kdb_backtrace+0x29 Feb 24 09:17:23 atlas kernel: witness_checkorder(c4dc9e28,1,c083666d,80d,e36fa9e8,...) at witness_checkorder+0x6de Feb 24 09:17:23 atlas kernel: _lockmgr_args(c4dc9e28,3041,c4dc9e58,0,ffffffff,...) at _lockmgr_args+0x1d5 Feb 24 09:17:23 atlas kernel: ffs_lock(e36faa78,c057b5dd,c08d03f4,3041,c4dc9dd0,...) at ffs_lock+0xa2 Feb 24 09:17:23 atlas kernel: VOP_LOCK1_APV(c0896fa0,e36faa78,c0824b8e,3,c4dc9e58,...) at VOP_LOCK1_APV+0xa5 Feb 24 09:17:23 atlas kernel: _vn_lock(c4dc9dd0,3041,c083666d,80d,0,...) at _vn_lock+0xf2 Feb 24 09:17:23 atlas kernel: vget(c4dc9dd0,3041,c4b19cc0,4a9,c104b180,...) at vget+0x109 Feb 24 09:17:23 atlas kernel: vnode_pager_lock(c104b000,0,c084b62d,127,e36fabe8,...) at vnode_pager_lock+0x1ad Feb 24 09:17:23 atlas kernel: vm_fault(c4b1d000,80d3000,2,8,80d3800,...) at vm_fault+0x1df Feb 24 09:17:23 atlas kernel: trap_pfault(5,0,c08577b8,2c8,c4b17ab0,...) at trap_pfault+0x118 Feb 24 09:17:23 atlas kernel: trap(e36fad38) at trap+0x267 Feb 24 09:17:23 atlas kernel: calltrap() at calltrap+0x6 Feb 24 09:17:23 atlas kernel: --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfef10, ebp = 0xbfbfef30 --- Feb 24 09:17:23 atlas savecore: no dumps found Feb 24 09:17:23 atlas kernel: lock order reversal: Feb 24 09:17:23 atlas kernel: 1st 0xc50486b8 pseudofs (pseudofs) @ kern/vfs_subr.c:2061 Feb 24 09:17:23 atlas kernel: 2nd 0xc4f4b29c vfslock (vfslock) @ kern/vfs_subr.c:364 Feb 24 09:17:23 atlas kernel: KDB: stack backtrace: Feb 24 09:17:23 atlas kernel: db_trace_self_wrapper(c082dec3,e79faa18,c05c2a0e,c08302e2,c4f4b29c,...) at db_trace_self_wrapper+0x26 Feb 24 09:17:23 atlas kernel: kdb_backtrace(c08302e2,c4f4b29c,c08360d0,c08360d0,c0836676,...) at kdb_backtrace+0x29 Feb 24 09:17:23 atlas kernel: witness_checkorder(c4f4b29c,1,c083666d,16c,e79faa58,...) at witness_checkorder+0x6de Feb 24 09:17:23 atlas kernel: _lockmgr_args(c4f4b29c,2001,c4f4b2cc,0,ffffffff,...) at _lockmgr_args+0x1d5 Feb 24 09:17:23 atlas kernel: vfs_busy(c4f4b29c,10,0,c5085000,8,...) at vfs_busy+0x1b0 Feb 24 09:17:23 atlas kernel: vfs_donmount(810e080,c,e79fac70,c51be380,810bc28,...) at vfs_donmount+0xdb5 Feb 24 09:17:23 atlas kernel: nmount(c5085000,e79facfc,c,c0830f96,c0877950,...) at nmount+0xb2 Feb 24 09:17:23 atlas kernel: syscall(e79fad38) at syscall+0x2b3 Feb 24 09:17:23 atlas kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Feb 24 09:17:23 atlas kernel: --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280d6f1b, esp = 0xbfbfe97c, ebp = 0xbfbfedd8 --- Feb 24 09:17:24 atlas ntpd[1074]: ntpd 4.2.0-a Sun Feb 24 00:05:25 PST 2008 (1) Feb 24 09:17:30 atlas login: ROOT LOGIN (root) ON ttyv0 Feb 24 09:18:26 atlas halt: halted by root Feb 24 09:18:26 atlas syslogd: exiting on signal 15 --------------050701060202070407080402 Content-Type: text/plain; name="ATLAS" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ATLAS" # # ATLAS -- 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.481 2008/02/03 07:07:30 scottl Exp $ cpu I486_CPU cpu I586_CPU cpu I686_CPU ident ATLAS # 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_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission 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 COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) 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 STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options IPSEC # 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 device crypto # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapicam # ATAPI CDROM drives #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 hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #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 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 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 zyd # ZyDAS zb1211/zb1211b wireless NICs #device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Serial devices device ucom # Generic com ttys #device uark # Technologies ARK3116 based serial adapters #device ubsa # Belkin F5U103 and compatible serial adapters #device ubser # BWCT console serial adapters #device uftdi # For FTDI usb serial adapters #device uipaq # Some WinCE based devices #device uplcom # Prolific PL-2303 serial adapters device uvisor # Visor and Palm devices #device uvscom # USB serial support for DDI pocket's PHS # 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 #device udav # Davicom DM9601E USB # 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 --------------050701060202070407080402-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 18:56:06 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA52416A408 for ; Sun, 24 Feb 2008 18:56:06 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id EDF1213C455 for ; Sun, 24 Feb 2008 18:56:05 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so1623804fka.11 for ; Sun, 24 Feb 2008 10:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=l1p1Prjw2ktWmhkFgoILOMILqGrewKnCPYnRyrI8cJg=; b=cDh4i0KQ9XzeyU0T0L2dygSmemoVP2+Pn88HthGR+nOzf9LpBquWRuBsWzxxiPz0SVQwoQffPgH4YTRy8oEmYXdoT6d6oQSblWaEFkPJzxRQwB8kLesc6bkK7QakoRLk6F/z6kuG0bm4ZIHBpvA5FASUZxJbIoG3ZNI8gSs8btc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=qHzJRMrRXyJEbTtj1RJ5WiPPIE9Q5j4kKHXJPFTuHat46IUNmXr5oJ/AJ0GDsdLlP24AIsjsw8Kff9AOsY5SJkgGNClkB/xJRq6HnQWOSAFCalwN8Dg1LT3/1UwhbItcuDEah1eN6kdaEFj6NPeKkgoAjlJUsdrhbTvslqKmChQ= Received: by 10.82.161.19 with SMTP id j19mr3802862bue.0.1203879364570; Sun, 24 Feb 2008 10:56:04 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id q9sm3400777gve.10.2008.02.24.10.56.02 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Feb 2008 10:56:03 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JTM11-0003uh-5N; Sun, 24 Feb 2008 19:55:59 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1OItx0v015046; Sun, 24 Feb 2008 19:55:59 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Sun, 24 Feb 2008 19:55:59 +0100 From: Kai Wang To: obrien@freebsd.org, Ruslan Ermilov , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org Message-ID: <20080224185559.GA15015@plan0.kaiwan.csbnet.se> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org References: <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> <20080222105413.GD94607@team.vega.ru> <20080222170007.GA2622@plan0.kaiwan.csbnet.se> <20080224181004.GC21162@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080224181004.GC21162@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 18:56:06 -0000 On Sun, Feb 24, 2008 at 10:10:04AM -0800, David O'Brien wrote: > On Fri, Feb 22, 2008 at 06:00:07PM +0100, Kai Wang wrote: > > Would it be better if we call them gar and granlib? Solaris did > > that. Also if I remember correctly, some ports probes gar. We also > > call GNU make as gmake... > > Why do we want > > I don't like "gar" as that is pronounceable to the point I could easily > see that being the real name of an existing program. Yes, you've got a good point. Actually I'm fine with either way... > Also, why do we want ports using gnu-ar specifically vs. what ever is our > native 'ar'? If our native 'ar' isn't up to the task, we shouldn't be > doing this endeavor at all. From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:06:43 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 756E316A400; Sun, 24 Feb 2008 19:06:43 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1075F13C448; Sun, 24 Feb 2008 19:06:43 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=62188 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTMBL-000Aw7-U9; Sun, 24 Feb 2008 19:06:39 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1OJ6bVv049525; Sun, 24 Feb 2008 22:06:37 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1OJ6bns049524; Sun, 24 Feb 2008 22:06:37 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Sun, 24 Feb 2008 22:06:37 +0300 From: Ruslan Ermilov To: obrien@freebsd.org, Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy , current@freebsd.org Message-ID: <20080224190637.GB18096@team.vega.ru> References: <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080224180433.GA21162@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 19:06:43 -0000 On Sun, Feb 24, 2008 at 10:04:33AM -0800, David O'Brien wrote: > On Sat, Feb 23, 2008 at 11:18:08PM +0300, Ruslan Ermilov wrote: > > now bootstrap BSD ar on systems >700044, and that we call > > GNU ar/ranlib with the "g" prefix instead of "gnu-". > > Why are you going against my preferences for "gnu-" - if I liked "g" > I would have done it that way in my patch. > The reasoning for the "g" prefix sounded sane to me. Anyway, I don't want to argue about this point, and will leave it to you to decide (I've reverted to the "gnu-" prefix). > Its seems those that have expressed an opinion want to switch to the new > 'ar' ASAP. So why not this patch? > Because your patch won't allow to cross-build on systems predating 700044. > (BTW, what is the sort order in Makefile.inc1? BOOTSTRAPPING date and > alphabetical?) > The intended order was by a pathname. It's missorted now. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:32:43 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A82B716A403; Sun, 24 Feb 2008 19:32:43 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 67CCB13C469; Sun, 24 Feb 2008 19:32:43 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1OJWalE025640; Sun, 24 Feb 2008 11:32:36 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1OJWLeQ025637; Sun, 24 Feb 2008 11:32:21 -0800 (PST) (envelope-from obrien) Date: Sun, 24 Feb 2008 11:32:21 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080224193221.GA25526@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy , current@freebsd.org References: <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080224190637.GB18096@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org, Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 19:32:43 -0000 On Sun, Feb 24, 2008 at 10:06:37PM +0300, Ruslan Ermilov wrote: > On Sun, Feb 24, 2008 at 10:04:33AM -0800, David O'Brien wrote: > > Its seems those that have expressed an opinion want to switch to the new > > 'ar' ASAP. So why not this patch? > > Because your patch won't allow to cross-build on > systems predating 700044. Why not? If ${BOOTSTRAPPING} >= 700044 we add usr.bin/ar to the list. What is your patch to just get rid of the WITH_GNUAR/WITH_BSDAR similar to mine? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:39:24 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F5A116A404; Sun, 24 Feb 2008 19:39:24 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id C017A13C4E7; Sun, 24 Feb 2008 19:39:23 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (p54A7E18A.dip.t-dialin.net [84.167.225.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 9B74540548E; Sun, 24 Feb 2008 20:11:32 +0100 (CET) Message-ID: <47C1C161.10107@bsdforen.de> Date: Sun, 24 Feb 2008 20:11:29 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Ruslan Ermilov References: <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> In-Reply-To: <20080224190637.GB18096@team.vega.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 19:39:24 -0000 Ruslan Ermilov wrote: > On Sun, Feb 24, 2008 at 10:04:33AM -0800, David O'Brien wrote: >> On Sat, Feb 23, 2008 at 11:18:08PM +0300, Ruslan Ermilov wrote: >>> now bootstrap BSD ar on systems >700044, and that we call >>> GNU ar/ranlib with the "g" prefix instead of "gnu-". >> Why are you going against my preferences for "gnu-" - if I liked "g" >> I would have done it that way in my patch. >> > The reasoning for the "g" prefix sounded sane to me. > Anyway, I don't want to argue about this point, and > will leave it to you to decide (I've reverted to the > "gnu-" prefix). I'd prefer the g-prefix. It's commonly used, just thing gmake, gawk and similar stuff. From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:44:03 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58E0316A403; Sun, 24 Feb 2008 19:44:03 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id CFB1613C458; Sun, 24 Feb 2008 19:44:02 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=62166 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTMlV-000D4M-6k; Sun, 24 Feb 2008 19:44:01 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1OJhwgK052253; Sun, 24 Feb 2008 22:43:58 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1OJhwuD052252; Sun, 24 Feb 2008 22:43:58 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Sun, 24 Feb 2008 22:43:58 +0300 From: Ruslan Ermilov To: obrien@freebsd.org, Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy , current@freebsd.org Message-ID: <20080224194358.GC18096@team.vega.ru> References: <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <20080224193221.GA25526@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 19:44:03 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 24, 2008 at 11:32:21AM -0800, David O'Brien wrote: > On Sun, Feb 24, 2008 at 10:06:37PM +0300, Ruslan Ermilov wrote: > > On Sun, Feb 24, 2008 at 10:04:33AM -0800, David O'Brien wrote: > > > Its seems those that have expressed an opinion want to switch to the new > > > 'ar' ASAP. So why not this patch? > > > > Because your patch won't allow to cross-build on > > systems predating 700044. > > Why not? If ${BOOTSTRAPPING} >= 700044 we add usr.bin/ar to the list. > I said predating 700044. > What is your patch to just get rid of the WITH_GNUAR/WITH_BSDAR similar > to mine? > ENOPARSE. How's the attached patch? The commit log would be: : Make again BSD ar(1) the default system ar(1), now properly handling : source upgrades by falling back to GNU ar(1) as necessary. Option : WITH_BSDAR is gone. Option _WITH_GNUAR to aid in upgrades is NOT : supposed to be set by the user. Stop bootstrapping BSD ar(1) on the : next __FreeBSD_version bump, as there are no known bugs in it. Bump : __FreeBSD_version to anticipate this and to flag the switch to BSD : ar(1), should it be needed for something. : : Input from: obrien, des, kaiw Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: sys/sys/param.h =================================================================== RCS file: /home/ncvs/src/sys/sys/param.h,v retrieving revision 1.337 diff -u -p -r1.337 param.h --- sys/sys/param.h 21 Feb 2008 16:12:46 -0000 1.337 +++ sys/sys/param.h 24 Feb 2008 19:23:42 -0000 @@ -57,7 +57,7 @@ * is created, otherwise 1. */ #undef __FreeBSD_version -#define __FreeBSD_version 800021 /* Master, propagated to newvers */ +#define __FreeBSD_version 800022 /* Master, propagated to newvers */ #ifndef LOCORE #include Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.598 diff -u -p -r1.598 Makefile.inc1 --- Makefile.inc1 5 Feb 2008 15:41:58 -0000 1.598 +++ Makefile.inc1 24 Feb 2008 19:24:00 -0000 @@ -872,6 +872,10 @@ _groff= gnu/usr.bin/groff/tmac .endif .endif +.if ${BOOTSTRAPPING} >= 700044 && ${BOOTSTRAPPING} < 800022 +_ar= usr.bin/ar +.endif + .if ${BOOTSTRAPPING} < 700018 _gensnmptree= usr.sbin/bsnmpd/gensnmptree .endif @@ -891,6 +895,7 @@ bootstrap-tools: ${_strfile} \ ${_gperf} \ ${_groff} \ + ${_ar} \ usr.bin/lorder \ usr.bin/makewhatis \ usr.bin/rpcgen \ @@ -967,6 +972,10 @@ _kgzip= usr.sbin/kgzip .endif .endif +.if make(cross-tools) && ${BOOTSTRAPPING} < 700044 +.MAKEFLAGS+= -D_WITH_GNUAR +.endif + cross-tools: .for _tool in \ gnu/usr.bin/binutils \ Index: gnu/usr.bin/binutils/ar/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ar/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- gnu/usr.bin/binutils/ar/Makefile 21 Feb 2008 16:59:02 -0000 1.16 +++ gnu/usr.bin/binutils/ar/Makefile 24 Feb 2008 19:09:37 -0000 @@ -4,12 +4,15 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) -PROG= gnu-ar -#MAN= gnu-ar.1 -.else -PROG= ar +.if !defined(_WITH_GNUAR) +PROGNAME= gnu-ar +MAN= gnu-ar.1 +gnu-ar.1: ar.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= gnu-ar.1 .endif + +PROG= ar SRCS= ar.c not-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils Index: gnu/usr.bin/binutils/ranlib/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ranlib/Makefile,v retrieving revision 1.17 diff -u -p -r1.17 Makefile --- gnu/usr.bin/binutils/ranlib/Makefile 21 Feb 2008 16:59:02 -0000 1.17 +++ gnu/usr.bin/binutils/ranlib/Makefile 24 Feb 2008 19:09:49 -0000 @@ -4,12 +4,15 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) -PROG= gnu-ranlib -#MAN= gnu-ranlib.1 -.else -PROG= ranlib +.if !defined(_WITH_GNUAR) +PROGNAME= gnu-ranlib +MAN= gnu-ranlib.1 +gnu-ranlib.1: ranlib.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= gnu-ranlib.1 .endif + +PROG= ranlib SRCS= ar.c is-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils Index: usr.bin/ar/Makefile =================================================================== RCS file: /home/ncvs/src/usr.bin/ar/Makefile,v retrieving revision 1.19 diff -u -p -r1.19 Makefile --- usr.bin/ar/Makefile 22 Feb 2008 06:53:52 -0000 1.19 +++ usr.bin/ar/Makefile 24 Feb 2008 19:12:50 -0000 @@ -1,28 +1,12 @@ # $FreeBSD: src/usr.bin/ar/Makefile,v 1.19 2008/02/22 06:53:52 obrien Exp $ -.if defined(WITH_BSDAR) PROG= ar -.else -PROG= bsdar -.endif +LINKS= ${BINDIR}/ar ${BINDIR}/ranlib +MLINKS= ar.1 ranlib.1 SRCS= ar.c read.c util.c write.c - WARNS?= 5 - +NO_SHARED?= yes DPADD= ${LIBARCHIVE} ${LIBBZ2} ${LIBZ} ${LIBELF} LDADD= -larchive -lbz2 -lz -lelf -.if defined(WITH_BSDAR) -NO_SHARED?= yes -LINKS= ${BINDIR}/ar ${BINDIR}/ranlib -MLINKS= ar ranlib -.else -LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib -MLINKS= bsdar.1 bsdranlib.1 - -CLEANFILES+= bsdar.1 -bsdar.1: ar.1 - ln -sf ${.ALLSRC} ${.TARGET} -.endif - .include --qMm9M+Fa2AknHoGS-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 20:48:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B83B16A400; Sun, 24 Feb 2008 20:48:40 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id BAAF813C448; Sun, 24 Feb 2008 20:48:39 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1OKmXe5027980; Sun, 24 Feb 2008 12:48:33 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1OKmWjc027978; Sun, 24 Feb 2008 12:48:32 -0800 (PST) (envelope-from obrien) Date: Sun, 24 Feb 2008 12:48:32 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080224204832.GA27938@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy , current@freebsd.org References: <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080224194358.GC18096@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org, Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 20:48:40 -0000 On Sun, Feb 24, 2008 at 10:43:58PM +0300, Ruslan Ermilov wrote: > On Sun, Feb 24, 2008 at 11:32:21AM -0800, David O'Brien wrote: > > On Sun, Feb 24, 2008 at 10:06:37PM +0300, Ruslan Ermilov wrote: > > > On Sun, Feb 24, 2008 at 10:04:33AM -0800, David O'Brien wrote: > > > > Its seems those that have expressed an opinion want to switch to the new > > > > 'ar' ASAP. So why not this patch? > > > > > > Because your patch won't allow to cross-build on > > > systems predating 700044. > > > > Why not? If ${BOOTSTRAPPING} >= 700044 we add usr.bin/ar to the list. > > > I said predating 700044. *sigh* what's 700044 - it would be nice if you'd say what that date represents so one doens't have to dig around www.freebsd.org to figure it out. > > What is your patch to just get rid of the WITH_GNUAR/WITH_BSDAR similar > > to mine? > > > ENOPARSE. > > How's the attached patch? The commit log would be: I don't think you answered me - why do we need the WITH_* stuff at all. Just install GNU ar as gnu-ar from now on and have the build system handle it. From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 20:51:25 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 114AC16A407; Sun, 24 Feb 2008 20:51:25 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id A1D5B13C478; Sun, 24 Feb 2008 20:51:24 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1OKpL9F028087; Sun, 24 Feb 2008 12:51:21 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1OKpLPF028086; Sun, 24 Feb 2008 12:51:21 -0800 (PST) (envelope-from obrien) Date: Sun, 24 Feb 2008 12:51:21 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080224205121.GB27938@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy , current@freebsd.org References: <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080224194358.GC18096@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org, Dag-Erling Sm??rgrav , Kai Wang , Joseph Koshy Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 20:51:25 -0000 On Sun, Feb 24, 2008 at 10:43:58PM +0300, Ruslan Ermilov wrote: > On Sun, Feb 24, 2008 at 11:32:21AM -0800, David O'Brien wrote: > > On Sun, Feb 24, 2008 at 10:06:37PM +0300, Ruslan Ermilov wrote: > > > On Sun, Feb 24, 2008 at 10:04:33AM -0800, David O'Brien wrote: > > > > Its seems those that have expressed an opinion want to switch to the new > > > > 'ar' ASAP. So why not this patch? > > > > > > Because your patch won't allow to cross-build on > > > systems predating 700044. > > > > Why not? If ${BOOTSTRAPPING} >= 700044 we add usr.bin/ar to the list. > > > I said predating 700044. What is the thing you're checking the value 700044 for? http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html 700044 7.0-CURRENT after changing the argument for vn_open()/VOP_OPEN() from filedescriptor index to the struct file *. 700045 7.0-CURRENT after changing pam_nologin(8) to provide an account management function instead of an authentication function to the PAM framework. From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 20:54:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B647F16A404 for ; Sun, 24 Feb 2008 20:54:29 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5629F13C455 for ; Sun, 24 Feb 2008 20:54:29 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JTNrf-0004H1-Gu for freebsd-current@freebsd.org; Sun, 24 Feb 2008 20:54:27 +0000 Received: from 78-1-110-139.adsl.net.t-com.hr ([78.1.110.139]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Feb 2008 20:54:27 +0000 Received: from ivoras by 78-1-110-139.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Feb 2008 20:54:27 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 24 Feb 2008 21:54:17 +0100 Lines: 31 Message-ID: References: <20080213113321.GA52329@eos.sc1.parodius.com> <20080213133156.GA5645@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig42F0163F64C622B863C856A4" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-110-139.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <20080213133156.GA5645@eos.sc1.parodius.com> X-Enigmail-Version: 0.95.6 Sender: news Cc: freebsd-fs@freebsd.org Subject: Re: ZFS lockup in "zfs" state X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 20:54:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig42F0163F64C622B863C856A4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable > On Wed, Feb 13, 2008 at 12:53:31PM +0100, Ivan Voras wrote: >>>> A machine just wedged its ZFS file systems (UFS file systems were st= ill >>>> running), all unresponsive processes were in "zfs" state. This is >>>> 7.0-RC1 on i386 with 2 GB RAM. It has happened at least once before.= +1; happened again, same symptoms. --------------enig42F0163F64C622B863C856A4 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 iD8DBQFHwdl5ldnAQVacBcgRAmVOAKCscEh6qOGRAE58rb3kkKP2EpuxeACfQd+Y K8amEdT3ifsAzYPjnWD2Wio= =dIpM -----END PGP SIGNATURE----- --------------enig42F0163F64C622B863C856A4-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 21:00:36 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACB3B16A400 for ; Sun, 24 Feb 2008 21:00:36 +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 1DC4D13C4DB for ; Sun, 24 Feb 2008 21:00:36 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JTNxZ-0004Vi-K4 for freebsd-current@freebsd.org; Sun, 24 Feb 2008 21:00:33 +0000 Received: from 78-1-110-139.adsl.net.t-com.hr ([78.1.110.139]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Feb 2008 21:00:33 +0000 Received: from ivoras by 78-1-110-139.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Feb 2008 21:00:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 24 Feb 2008 22:00:22 +0100 Lines: 51 Message-ID: References: <845250.18624.qm@web63909.mail.re1.yahoo.com> <47BF5702.3020204@FreeBSD.org> <47BF8EB7.9090007@barafranca.com> <47BFB70F.5080402@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig428267FAEEBB4BE0C2EDE6C0" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-110-139.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <47BFB70F.5080402@FreeBSD.org> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: cpu usage 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: Sun, 24 Feb 2008 21:00:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig428267FAEEBB4BE0C2EDE6C0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > Hugo Silva wrote: >> Kris Kennaway wrote: >>> Barney Cordoba wrote: >>>> I have a dual core system running 7.0 and I can't get >>>> top to show more than 100% usage no matter how I >>>> hammer it. My MAC shows over 100% often, but its not >>>> clear if top is averaging the 2 cpus or just not going >>>> over 100, or just showing 1 of the cpus. >>> >>> 100% in FreeBSD means "all of your CPUs are completely active". It=20 >>> is hard to exceed this amount :-) >> >> You should see my production mysql going over 458% on service startup,= =20 >> on a quad core server :-) >=20 > That is a multithreaded process using multiple CPUs, not the total CPU = > statistics (first line of top(1)). So how does a multithreaded process get 458% CPU on a quad-core machine? = :) (Really, I want to know; I thought thread CPU accounting was fixed in = 7.x. Unless I'm mistaken, 4 CPU-intensive threads in a single process=20 should account as 4 CPU-intensive single-thread processes; i.e. each=20 could only take up to 100% of a core/CPU, accounting for NCPU*100% total)= =2E --------------enig428267FAEEBB4BE0C2EDE6C0 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 iD8DBQFHwdrmldnAQVacBcgRAkc7AKCfpM90c6jEnMgNqdDxAOGwkiThIgCfXiXv V5YimNwvkPTleMkxAfTTwLM= =vAhL -----END PGP SIGNATURE----- --------------enig428267FAEEBB4BE0C2EDE6C0-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 21:26:52 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0332616A406 for ; Sun, 24 Feb 2008 21:26:52 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD6113C46A for ; Sun, 24 Feb 2008 21:26:51 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so2153551pyb.10 for ; Sun, 24 Feb 2008 13:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=otsX5LK9V6BKZCXY+0k7U515l30I5YQwKOzrvnQfOjY=; b=ofzfOQG9e5zsnCi2afUncvZMA7h1b2posSRVsSOLpGvMNdZeyzam27TeWkEp66aN83BCAdq3MC1vHKpzrljkSeLNtEoOo3j2O20+tcvZC97FGRQJAaEMKCe8PjOcZyAekXutnT9+bX76/ll4IJLkItzr1hfJ3Pxg/dgF7Ws+acA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=QUErxSnC8AVVdMiGMijrvt1rsBcPHSvPPpRfVlZgkOYrSrna4dI59y2aX83lYQun8JuQcuZQw6gshwLVYv59JPbY3HeZe4wcF0cZNYu3FPH/g9DAumzl0UyW37g8LVrZinekY3jnKzAf7Vo+Rp4fzk3S4CJJsZP1I1JU3rAkVxg= Received: by 10.65.252.13 with SMTP id e13mr4656922qbs.26.1203888408802; Sun, 24 Feb 2008 13:26:48 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id c25sm7215812ika.9.2008.02.24.13.26.46 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Feb 2008 13:26:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JTOMs-00044a-TD; Sun, 24 Feb 2008 22:26:43 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1OLQg00015659; Sun, 24 Feb 2008 22:26:42 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Sun, 24 Feb 2008 22:26:42 +0100 From: Kai Wang To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm??rgrav , Joseph Koshy , current@freebsd.org Message-ID: <20080224212642.GA15362@plan0.kaiwan.csbnet.se> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm??rgrav , Joseph Koshy , current@freebsd.org References: <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080224205121.GB27938@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Feb 2008 21:26:52 -0000 On Sun, Feb 24, 2008 at 12:51:21PM -0800, David O'Brien wrote: > What is the thing you're checking the value 700044 for? > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html > 700044 > 7.0-CURRENT after changing the argument for vn_open()/VOP_OPEN() > from filedescriptor index to the struct file *. > 700045 > 7.0-CURRENT after changing pam_nologin(8) to provide an account > management function instead of an authentication function to the > PAM framework. > I guess, probably des@ meant that: libarchive 2.2.3 (committed at May 29 2007) included the last major fix to the 'ar' support, and 700044 (though not specific to this) bumped at Jun 7 2007 is closest to that day? Kai From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 21:34:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74BAB16A406; Sun, 24 Feb 2008 21:34:38 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 39C9613C4D1; Sun, 24 Feb 2008 21:34:38 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1OLYYvY029121; Sun, 24 Feb 2008 13:34:34 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1OLYYnG029120; Sun, 24 Feb 2008 13:34:34 -0800 (PST) (envelope-from obrien) Date: Sun, 24 Feb 2008 13:34:34 -0800 From: "David O'Brien" To: Ruslan Ermilov , Dag-Erling Sm??rgrav , Joseph Koshy , current@freebsd.org Message-ID: <20080224213434.GA29077@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm??rgrav , Joseph Koshy , current@freebsd.org References: <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> <20080224212642.GA15362@plan0.kaiwan.csbnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080224212642.GA15362@plan0.kaiwan.csbnet.se> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 21:34:38 -0000 On Sun, Feb 24, 2008 at 10:26:42PM +0100, Kai Wang wrote: > On Sun, Feb 24, 2008 at 12:51:21PM -0800, David O'Brien wrote: > > What is the thing you're checking the value 700044 for? > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html > > 700044 > > 7.0-CURRENT after changing the argument for vn_open()/VOP_OPEN() > > from filedescriptor index to the struct file *. > > 700045 > > 7.0-CURRENT after changing pam_nologin(8) to provide an account > > management function instead of an authentication function to the > > PAM framework. > > I guess, probably des@ meant that: libarchive 2.2.3 (committed > at May 29 2007) included the last major fix to the 'ar' support, > and 700044 (though not specific to this) bumped at Jun 7 2007 > is closest to that day? If that is the case - this web page should be updated with that information. It is find to go back after the fact and note that a particular version number represents more than one thing. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 22:46:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C997616A401; Sun, 24 Feb 2008 22:46:11 +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 866CA13C45B; Sun, 24 Feb 2008 22:46:11 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1OMk7rt096574; Sun, 24 Feb 2008 17:46:10 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 24 Feb 2008 12:47:39 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ivan Voras In-Reply-To: Message-ID: <20080224124342.E920@desktop> References: <845250.18624.qm@web63909.mail.re1.yahoo.com> <47BF5702.3020204@FreeBSD.org> <47BF8EB7.9090007@barafranca.com> <47BFB70F.5080402@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: cpu usage 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: Sun, 24 Feb 2008 22:46:11 -0000 On Sun, 24 Feb 2008, Ivan Voras wrote: > Kris Kennaway wrote: >> Hugo Silva wrote: >>> Kris Kennaway wrote: >>>> Barney Cordoba wrote: >>>>> I have a dual core system running 7.0 and I can't get >>>>> top to show more than 100% usage no matter how I >>>>> hammer it. My MAC shows over 100% often, but its not >>>>> clear if top is averaging the 2 cpus or just not going >>>>> over 100, or just showing 1 of the cpus. >>>> >>>> 100% in FreeBSD means "all of your CPUs are completely active". It is >>>> hard to exceed this amount :-) >>> >>> You should see my production mysql going over 458% on service startup, on >>> a quad core server :-) >> >> That is a multithreaded process using multiple CPUs, not the total CPU >> statistics (first line of top(1)). > > So how does a multithreaded process get 458% CPU on a quad-core machine? :) > (Really, I want to know; I thought thread CPU accounting was fixed in 7.x. > Unless I'm mistaken, 4 CPU-intensive threads in a single process should > account as 4 CPU-intensive single-thread processes; i.e. each could only take > up to 100% of a core/CPU, accounting for NCPU*100% total). > > It is possible for the sum of all threads in the system to exceed 100% cpu. This is because the decay function is not precise. 15% over is a bit more than I would expect but I suppose it's possible. We also inhert pcpu information from the parent on fork/thread creation so the child isn't created with a priority as if it had been idle. So for a moment the utilization is duplicated. Penalizing the child for an expensive parent is an important optimization that prevents batch jobs from overwhelming the system under load. Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 23:07:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54D1D16A404 for ; Sun, 24 Feb 2008 23:07:54 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9922413C442; Sun, 24 Feb 2008 23:07:53 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C1F8C9.6020200@FreeBSD.org> Date: Mon, 25 Feb 2008 00:07:53 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jeff Anton References: <47C1BB00.7030506@hesiod.org> In-Reply-To: <47C1BB00.7030506@hesiod.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 23:07:54 -0000 Jeff Anton wrote: > Hi, > FYI: I just built a new kernel and I'm getting a bunch of > lock order reversal reports. No apparent ill effects, but > disconcerting. I built my last kernel, which did not complain, > on Feb 3rd. See previous discussions. Summary: they have always been there but were unnoticed until recent enhancements. Kris From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 00:15:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B43616A401 for ; Mon, 25 Feb 2008 00:15:20 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 865E213C45B for ; Mon, 25 Feb 2008 00:15:20 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from morimoto.kitchenlab.org (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id m1P0FGcB013931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Feb 2008 16:15:19 -0800 Message-ID: <47C2088D.2090602@freebsd.org> Date: Sun, 24 Feb 2008 16:15:09 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Brian Biskeborn References: <20080215231507.EAB7D641@mx2.synetsystems.com> <200802241252.52176.peter.schuller@infidyne.com> <47C17E2C.5040606@princeton.edu> In-Reply-To: <47C17E2C.5040606@princeton.edu> X-Enigmail-Version: 0.95.6 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig366B56F50DCC1DD3771BA3BE" Cc: freebsd-current@freebsd.org, Peter Schuller , Richard Todd Subject: Re: ZFS: data sometimes not getting correctly flushed to disk (possible mmap/write issue)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 00:15:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig366B56F50DCC1DD3771BA3BE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable If memory serves me right, Brian Biskeborn wrote: > This has been happening to me for a week or so (same setup - Dovecot on= =20 > ZFS). I'll disable mmap and see whether it persists. Me too. I'll give this a shot as well. (FreeBSD 7.0-PRERELEASE/amd64 from about a week ago, but I've been=20 seeing this off and on for awhile. dovecot-1.0.10 from Ports.) Bruce. > Peter Schuller wrote: >>> 3) ktracing gen2.py shows that the py-mutagen library seems to do bot= h >>> write()s and read/write mmap()s to the file to update the file. >> FWIW, ever since a dovecot installation of mine was moved onto ZFS one= gets=20 >> sporadic 'internel errors' from dovecot. Dovecot logs that index files= are=20 >> corrupt, and marked broken. Recovery involves re-selecting the IMAP ma= ilbox. >> >> In response to your post, I recently turned OFF use of mmap in dovecot= =20 >> (mmap_disable =3D yes), and the problem seems to have gone away immedi= ately. >> >> If it should show up again in spite of mmap being disabled I will post= a=20 >> follow-up, but it's been long enough that I believe the problem to be = gone. >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 --------------enig366B56F50DCC1DD3771BA3BE 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 iD8DBQFHwgiT2MoxcVugUsMRAi6nAJ0e9xqLa2WG4EA2op4EhJUzj8lBMgCg3KwC R/pjHF5xmoDqsVobEyiJno4= =qksH -----END PGP SIGNATURE----- --------------enig366B56F50DCC1DD3771BA3BE-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 02:15:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 695FF16A401 for ; Mon, 25 Feb 2008 02:15:16 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx2.synetsystems.com (mx2.synetsystems.com [76.10.206.15]) by mx1.freebsd.org (Postfix) with ESMTP id 06DFB13C447 for ; Mon, 25 Feb 2008 02:15:15 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx2.synetsystems.com (Postfix, from userid 66) id 3AF70676; Sun, 24 Feb 2008 21:15:15 -0500 (EST) Received: from rmtodd by servalan.servalan.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTShs-000NzX-2i; Sun, 24 Feb 2008 20:04:40 -0600 To: freebsd-current@freebsd.org References: <20080215231507.EAB7D641@mx2.synetsystems.com> <1203359855.43782.60.camel@buffy.york.ac.uk> From: Richard Todd Date: Sun, 24 Feb 2008 20:04:40 -0600 In-Reply-To: (Richard Todd's message of "Thu, 21 Feb 2008 19:33:08 -0600") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: ZFS: data sometimes not getting correctly flushed to disk (possible mmap/write issue)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 02:15:16 -0000 Further notes on the "data not getting correctly flushed to disk" issue with mmap and ZFS: I've managed to construct a simpler test case, one that doesn't require py-mutagen or any other ports installed. See the attached shar file for details; it contains a C++ program "gen4.cpp" and a shell script "test4.sh". gen4.cpp creates a file, writes a little bit of data to it, and does some mmap()ing to shuffle data about (see the "insert_bytes" and "delete_bytes" functions, which are basically C reimplementations of the Python functions of the same name from the py-mutagen package.) Test4.sh is a shell script which basically does as my shell script in my previous posting did: 1) Run the "gen4" test program, creating a file on a ZFS partition 2) MD5 that file 3) Copy that file somewhere on a UFS filesystem, call the copy "before". 4) Unmount the ZFS filesystem and remount it. 5) Re-MD5 the test file and copy that file to the UFS filesystem as a file "after" 6) Compare the "before" and "after" files and list which bytes differ. The script has 4 configurable parameters which you can edit if you want to try and run this test yourself: ZFSFS name of your ZFS filesystem to test (in my case, "u1") ZFSMP mount point of your ZFS filesystem to test (in my case, "/u1") ZFSDIR a writable dir somewhere under ZFSMP (in my case, "/u1/tmp") UFSDIR a writable dir somewhere on a UFS filesystem (in my case, "/var/tmp"). The script takes one parameter, which I call S1, which is the number of bytes the gen4 program tries to insert in the test file with the "insert_bytes" function. Only certain values of this parameter trigger the bug, basically values of the form n*4096+3074+i (n integer, i in [0,510]) Also note that when the mmap bug hits, the data that doesn't get correctly to disk is *always* the last part of the file, and always is at most 1 sector's worth (512 bytes) and always starts at a page boundary (multiple of 4K). Script started on Sun Feb 24 19:26:23 2008 1 blo-rakane ~/bug[ 7:26PM] Z% ./test4.sh 3073 MD5 (/u1/tmp/foo1) = fe750b17b666653e22e2a9bb240e6bd7 -rw-r--r-- 1 rmtodd wheel 4096 Feb 24 19:26 /u1/tmp/foo1 MD5 (/u1/tmp/foo1) = fe750b17b666653e22e2a9bb240e6bd7 -rw-r--r-- 1 rmtodd wheel 4096 Feb 24 19:26 /u1/tmp/foo1 2 blo-rakane ~/bug[ 7:26PM] Z% ./test4.sh 3074 MD5 (/u1/tmp/foo1) = 7ab56c42278ddcffd0269523fe7667a0 -rw-r--r-- 1 rmtodd wheel 4097 Feb 24 19:26 /u1/tmp/foo1 MD5 (/u1/tmp/foo1) = ad5e2ab0f485db6c3737b5b1bbc7c9a0 -rw-r--r-- 1 rmtodd wheel 4097 Feb 24 19:26 /u1/tmp/foo1 4097 377 0 3 blo-rakane ~/bug[ 7:26PM] Z% ./test4.sh 3075 MD5 (/u1/tmp/foo1) = 6dc1c3b940601a4af75780fda4ab1395 -rw-r--r-- 1 rmtodd wheel 4098 Feb 24 19:26 /u1/tmp/foo1 MD5 (/u1/tmp/foo1) = ebf119d60033e99ff911d29faceef6f4 -rw-r--r-- 1 rmtodd wheel 4098 Feb 24 19:26 /u1/tmp/foo1 4097 376 0 4098 377 0 4 blo-rakane ~/bug[ 7:26PM] Z% ./test4.sh 3584 MD5 (/u1/tmp/foo1) = 6348eaa9cdb8e7ed99a6e81b378a5f2a -rw-r--r-- 1 rmtodd wheel 4607 Feb 24 19:26 /u1/tmp/foo1 MD5 (/u1/tmp/foo1) = c1a464f57d68c903c6bacb0f8652c35c -rw-r--r-- 1 rmtodd wheel 4607 Feb 24 19:26 /u1/tmp/foo1 4097 1 0 4098 2 0 4099 3 0 [... intermediate lines deleted, you see the pattern ...] 4607 377 0 5 blo-rakane ~/bug[ 7:26PM] Z% ./test4.sh 4 3585 MD5 (/u1/tmp/foo1) = 53ece827167e437de736eceb10106cdb -rw-r--r-- 1 rmtodd wheel 4608 Feb 24 19:26 /u1/tmp/foo1 MD5 (/u1/tmp/foo1) = 53ece827167e437de736eceb10106cdb -rw-r--r-- 1 rmtodd wheel 4608 Feb 24 19:27 /u1/tmp/foo1 6 blo-rakane ~/bug[ 7:27PM] Z% ./test4.sh 7170 MD5 (/u1/tmp/foo1) = 9c18df094aab90b5c0bb2fa89de0dc54 -rw-r--r-- 1 rmtodd wheel 8193 Feb 24 19:27 /u1/tmp/foo1 MD5 (/u1/tmp/foo1) = d353963ef7edf672fd6a75159fa513b9 -rw-r--r-- 1 rmtodd wheel 8193 Feb 24 19:27 /u1/tmp/foo1 8193 377 0 7 blo-rakane ~/bug[ 7:27PM] Z% ./test4.sh 7171 MD5 (/u1/tmp/foo1) = 928b747af654170711e24c6eeb042cd5 -rw-r--r-- 1 rmtodd wheel 8194 Feb 24 19:27 /u1/tmp/foo1 MD5 (/u1/tmp/foo1) = 845114ca58a19f850a3e7b9797e4c637 -rw-r--r-- 1 rmtodd wheel 8194 Feb 24 19:27 /u1/tmp/foo1 8193 376 0 8194 377 0 8 blo-rakane ~/bug[ 7:27PM] Z% exit Script done on Sun Feb 24 19:27:45 2008 Also, the ZFS panic (with possible FS corruption) I mentioned last time doesn't actually seem to be connected with this mmap() bug, but is apparently a different (unrelated) bug. I say this because, while I can trigger the panic by repeatedly calling the "test4.sh" script a few hundred times, repeatedly creating files and unmounting and remounting the fs, the panic happens even if I pick a value of the parameter that *doesn't* trigger the mmap consistency issue. So it looks like the panic issue is unrelated, and only came up accidentally when developing my test case for the mmap issue. (Must be my lucky day.) So anyway, that's what I've got so far. I may try to put some debugging printfs to see if I can figure out what's going on with the mmap issue. (I'm not sure I follow this code at all, but it seems to me that mappedwrite() in zfs_vnops.c is a likely place to start looking.) # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # gen4.cpp # test4.sh # echo x - gen4.cpp sed 's/^X//' >gen4.cpp << 'END-of-gen4.cpp' X/* X** Program to create a file of data and do some mmap()ing writes to it. X*/ X X#include X#include X#include X#include X#include X#include X#include X#include X X/* Insert size bytes (zeros) into file at offset */ Xvoid Xinsert_bytes(int fd, unsigned int size, unsigned int offset) X{ X unsigned int filesize = lseek(fd, (off_t)0, SEEK_END); X unsigned int movesize = filesize - offset; X X char *buf = new char[size]; X for (unsigned int i = 0 ; i < size ; ++i) { X buf[i] = '\0'; X } X write(fd, buf, size); X X char *addr = (char *) mmap((void *)NULL, filesize+size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset); X memmove(addr+size, addr, movesize); X if (munmap(addr, filesize+size)) { X perror("munmap"); X } X} X X/* Delete size bytes (zeros) from file at offset */ Xvoid Xdelete_bytes(int fd, unsigned int size, unsigned int offset) X{ X unsigned int filesize = lseek(fd, (off_t)0, SEEK_END); X unsigned int movesize = filesize - offset - size; X X char *addr = (char *) mmap((void *)NULL, filesize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset); X memmove(addr, addr+size, movesize); X if (munmap(addr, filesize)) { X perror("munmap"); X } X ftruncate(fd, filesize - size); X} X X X X/* Usage: gen1 filename number-of-seconds */ Xint Xmain(int argc, char **argv) X{ X char *fname = argv[1]; X FILE *f = fopen(fname, "w"); X X unsigned int size = 1024; X X for (unsigned int i = 0 ; i < size ; ++i) { X char c = i & 0xff; X fwrite((void *)&c, 1, 1, f); X } X X fclose(f); X X int fd = open(fname, O_RDWR); X X unsigned int S1 = atoi(argv[2]); X#define O1 0 X insert_bytes(fd, S1, O1); X X (void) lseek(fd, (off_t) O1, SEEK_SET); X X#define S2 1 X#define O2 (O1+S1) X X delete_bytes(fd, S2, O2); X X exit(0); X} END-of-gen4.cpp echo x - test4.sh sed 's/^X//' >test4.sh << 'END-of-test4.sh' X#!/bin/sh X# Set the following variables appropriately X# ZFSFS name of your ZFS filesystem to test X# ZFSMP mount point of your ZFS filesystem to test X# ZFSDIR a writable dir somewhere under ZFSMP X# UFSDIR a writable dir somewhere on a UFS filesystem X# Script takes one argument, S1, a number of bytes. X XZFSFS=u1 XZFSMP=/u1 XZFSDIR=/u1/tmp XUFSDIR=/var/tmp X XNAME=$ZFSDIR/foo1 XS1=$1 Xrm $NAME X./gen4 $NAME $S1 Xmd5 $NAME Xcp $NAME $UFSDIR/before Xls -l $NAME Xsudo umount $ZFSMP Xsudo mount -t zfs $ZFSFS $ZFSMP Xmd5 $NAME Xls -l $NAME Xcp $NAME $UFSDIR/after Xcmp -l $UFSDIR/before $UFSDIR/after END-of-test4.sh exit From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 02:41:58 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEF4516A402; Mon, 25 Feb 2008 02:41:58 +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 7CD7413C457; Mon, 25 Feb 2008 02:41:58 +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 D57722084; Mon, 25 Feb 2008 03:41:46 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id AA96A207F; Mon, 25 Feb 2008 03:41:45 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> <20080222105413.GD94607@team.vega.ru> <20080222170007.GA2622@plan0.kaiwan.csbnet.se> <20080224181004.GC21162@dragon.NUXI.org> Date: Mon, 25 Feb 2008 03:41:45 +0100 In-Reply-To: <20080224181004.GC21162@dragon.NUXI.org> (David O'Brien's message of "Sun\, 24 Feb 2008 10\:10\:04 -0800") Message-ID: <86ve4dzriu.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joseph Koshy , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 02:41:58 -0000 "David O'Brien" writes: > I don't like "gar" as that is pronounceable to the point I could easily > see that being the real name of an existing program. I've told you already that there is no such program in ports. In addition, no project by that name is registered in SourceForge, cia.vc or ohloh.net. I don't see the point of being inconsistent just because you can pronounce "gar". (BTW, I can pronounce "groff". Should we rename it to gnu-roff?) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 03:06:05 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2032E16A400; Mon, 25 Feb 2008 03:06: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 E65E013C448; Mon, 25 Feb 2008 03:06: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 A134F2088; Mon, 25 Feb 2008 04:06:01 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 19C7C2085; Mon, 25 Feb 2008 04:05:59 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> <20080222105413.GD94607@team.vega.ru> <20080222170007.GA2622@plan0.kaiwan.csbnet.se> <20080224181004.GC21162@dragon.NUXI.org> <86ve4dzriu.fsf@ds4.des.no> Date: Mon, 25 Feb 2008 04:05:59 +0100 In-Reply-To: <86ve4dzriu.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon\, 25 Feb 2008 03\:41\:45 +0100") Message-ID: <86bq65zqeg.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joseph Koshy , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 03:06:05 -0000 Dag-Erling Sm=C3=B8rgrav writes: > (BTW, I can pronounce "groff". Should we rename it to gnu-roff?) not to mention gawk... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 03:37:10 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 167D516A401 for ; Mon, 25 Feb 2008 03:37:10 +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 CC4C313C46E for ; Mon, 25 Feb 2008 03:37:09 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1P3b56a046523 for ; Sun, 24 Feb 2008 22:37:08 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 24 Feb 2008 17:38:37 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: current@freebsd.org Message-ID: <20080224173229.I920@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: cpuset and affinity implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 03:37:10 -0000 Hello, I have implemented a new api similar to processors sets on solaris. This allows you to assign processes to sets of cpus and dynamically change those sets. This is useful for provisioning purposes to add and remove cpu resources for a particular process or group of processes. This new facility also supports binding secific threads to specific cpus which some applications may want to do. At some point in the future this will be integrated with jail so you can restrict the cpus any jail is allowed to use. This api should not be considered final and the 'cpuset' tool is quite rough. This also only works with ULE and is unfortunately intertwined with a big ULE patch I've been working on. The set management code is generic but 4BSD doesn't contain the hooks to actually constrain threads. Please see: http://people.freebsd.org/~jeff/cpuset.diff here's a couple of neat things to do with cpuset: cpuset -l 0-4 /bin/sh This creates a new group with a list (-l) of cpus 0-4 inclusive and runs sh in it. cpuset -g -p This will get (-g) the mask of cpus pid (-p) is allowed to run on. cpuset -l 0,2 -p This will restrict sh to running on cpus 0, 2 while its group is still allowed 0-4. cpuset -l 0,2 -c -p This will modify the cpuset (-c) that the sh belongs to. cpuset -l 0-3 -s 1 This will modify the set (-s) that all threads are in by default to contain the first 4 cpus leaving the rest idled. cpuset -g -i -p This will print the id of the set sh is in. cpuset -s -p This will move pid into the specified set so it may be managed with other pids in that set. Feedback is appreciated. Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 03:56:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E50C316A405 for ; Mon, 25 Feb 2008 03:56:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3E02E13C467 for ; Mon, 25 Feb 2008 03:56:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so2076225wri.3 for ; Sun, 24 Feb 2008 19:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=reo1vhMGKz3fcwm9F0P32StddEszjb6G2S3Bgbmcy40=; b=sEGUMEb72gPMbipybCXdaj0ZanhoznCUII6AXLaiaxkUvr/NmvUYdBySoztCXcBieeCca4Lam2fXQgHkYmmYpGCzq5PD7pdlknEdf2xkINyKby5vEs2/hmouWHb/O3L4TruqwaK4u2WRb2/mW1UbcoOaMnXSmey/RU3B+3gfNW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=W/dKV1QDzXcWosPrqXWIWb/UhvivmcP4ecSanOwRACvPeocSrVuaRjsFF5RLZNc7KbpD/Xr9br81Ya7sYpseJq9sf2zJ4KhRwduwMDajyNzIsbwCVwH3o1uldADunfGf2Bd5URrDHv6/NwBxWalcwEtpK2IAo3Ab96LUtKDs1X8= Received: by 10.143.37.20 with SMTP id p20mr1752427wfj.236.1203911786760; Sun, 24 Feb 2008 19:56:26 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 30sm8137038wfd.19.2008.02.24.19.56.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Feb 2008 19:56:25 -0800 (PST) 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 m1P3uJjG044219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2008 12:56:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1P3uHJP044218; Mon, 25 Feb 2008 12:56:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 25 Feb 2008 12:56:17 +0900 From: Pyun YongHyeon To: Sam Leffler Message-ID: <20080225035617.GF42733@cdnetworks.co.kr> References: <20080222042700.GB30497@cdnetworks.co.kr> <20080222094742.GF30497@cdnetworks.co.kr> <47C0678D.20905@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C0678D.20905@errno.com> User-Agent: Mutt/1.4.2.1i Cc: Ian FREISLICH , Robert Backhaus , FreeBSD Current Subject: Re: Packet corruption in re0 [checksum offloading] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 03:56:30 -0000 On Sat, Feb 23, 2008 at 10:35:57AM -0800, Sam Leffler wrote: > Pyun YongHyeon wrote: > >On Fri, Feb 22, 2008 at 10:43:22AM +0200, Ian FREISLICH wrote: > > > Pyun YongHyeon wrote: > > > > On Thu, Feb 21, 2008 at 01:18:18PM +0200, Ian FREISLICH wrote: > > > > > Pyun YongHyeon wrote: > > > > > > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > > > > > > > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon > > wr > > > ote: > > > > > > > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus > > wrote: > > > > > > > > > I am experiencing roughly 15% packet corruption on the > > re inter > > > face > > > > > on > > > > > > > > > my freebsd 7/amd64 box. > > > > > > > > > > > > > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD > > 7.0-PRERELEA > > > SE #8 > > > > > : > > > > > > > > > Tue Feb 5 09:49:55 EST 2008 > > > > > > > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > > > > > > > > > > > > > Just to make troubleshooting difficult, this problem > > only shows > > > up > > > > > > > > > after the system has been up for roughly 36 hours, > > depending on > > > the > > > > > > > > > amount of traffic. > > > > > > > > > > > > > > > > > > > > > > > > > I didn't take a look attached tcpdump files but I guess the > > > > > > > > instability issue was fixed in HEAD. It's not yet MFCed but > > > > > > > > I'll handle it in a week. > > > > > > > > > > > > > > > > Would you try re(4) in HEAD? > > > > > > > > > > > > > > > > > > > > > > OK, I'll do that. What is the best way to do that? csupping > > to "." se > > > ems a > > > > > > > bit drastic, and I don't do much with cvs proper. I take it > > that I sh > > > ould > > > > > use > > > > > > > anon-cvs to grab the directory, but I don't quite know how. > > > > > > > > > > > > > > > > > > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > > > > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to > > add > > > > > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c > > on > > > > > > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > > > > > > > > This doesn't solve the problem that I'm seeing on re(4) interfaces. > > > > > It basically shows up as quagga establishing OSPF neighours as > > > > > "Exchange/DR" when VLAN hardware tagging is enabled. I'm running > > > > > OSPF over 802.1Q vlans. Neighbours are correctly negotiated once > > > > > VLAN hardware tagging is disabled on the interface. > > > > > > > > > > I'll do more debugging. > > > > > > > > > > > > > Hmm. That sounds like different issue to me. I guess I din't change > > > > any semantics in VLAN H/W tagging. Do you still the same VLAN H/W > > > > tagging related issues on RELENG_7? > > > > > > > > To narrow down the issue it would be even better to know which parts > > > > of H/W assistance was broken. For example, > > > > - Disable checksum offload for VLAN interface first and check > > > > whether quagga works. > > > > > > You can only disable offload on the parent interface. > > > > > > >Hmm... I thought it should work. > >I have no idea why ioctl handler of vlan(4) rejects checksum > >offload configutation. I guess vlan(4) should be teached to handle > >this. If parent interface have IFCAP_VLAN_HWCSUM capability and > >IFCAP_VLAN_HWTAGGING, ifconfig(4) should be able to control checksum > >offload for vlan(4) interface. CCed to yar to get his opinions on > >controlling checksum offload on vlan(4). > > > > > > - Disable checksum offload for parent interface and check again. > > > > If you can post tcpdump output for broken conntection it may help a > > > > lot to diagnose the issue. > > > > > > The only flag affecting this behaviour is vlanhwtag. Various > > > permutations of the interface flags make no difference to this > > > behaviour as long as hardware tagging is enabled. > > > > > > >Disabling VLAN HW tagging also turns off checksum offload on vlan(4) > >interface. > > > > > > This reminds me that there are several places in the system where h/w > checksum offload needs to be specially handled but instead is disabled > as a WAR. In particular I'm thinking of the bridge where txcsum is > muted on devices while they are plumbed. But this can be a big loss and > the better approach (IMO) is to fill in the missing capability in s/w. > Agreed. > Not sure what components there are besides bridge and vlan; maybe lagg? > netgraph? > I'm not familiar with lagg(4) and netgraph(4). But lagg(4) should disable Tx checksum offload if one of interface is not capable of hardware checksum offload. > Note there are other capabilities besides checksum offload, TSO can be > done in s/w with good effect. > AFAIK bridge(4) blindly disables Tx checksum offload for all members of a bridge. If all members of a bridge can do checksum offload/TSO with hardware assistance I guess there is no reason to disable these capabilities in bridge environments. The same apply to lagg(4) too. S/W checksum offload/TSO emulation for intefaces without these hardware capabilities would greatly enhance Tx performance when other member of interface of a bridage can make use of hardware offload capability. > Sam > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 04:09:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8729F16A402 for ; Mon, 25 Feb 2008 04:09:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.177]) by mx1.freebsd.org (Postfix) with ESMTP id 9007613C457 for ; Mon, 25 Feb 2008 04:09:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by el-out-1112.google.com with SMTP id r27so1153873ele.3 for ; Sun, 24 Feb 2008 20:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=V/gF3cVex/ADAh0QbpPGX5S3vExWT67SIa3lUIi4G6k=; b=OVybE37WvX/7d3G3oN75Yqy02+iQpZOxePm8dQIQ4U/wtAHc+qfSMn2jD9SjU93LbBjVUf/ngKEl4gB4CwvYruWaLu8IUXCC9Ei1CBiJWORckKQ7QTp4H2JjE7KWKnsFNgAlZRSnYj9vSAanH/7fvtlWj2lg5PfiaPIS88IWpb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=cSWILbt9mHgV4YKGn4PZrwQqE6HlV1CjQJtkxj+fg2x6qhdu/T8Wk+xSXtJBvTM3BjlaNMT2OWhVgmrteoKTJ/BbgFcBKAZcFA2W9O+3x55Qlx1G01xt+xfso1bccfhPXnwG3NhQRwm+h+Gth1u4oM9duHHdEkylehbOv9VFzgQ= Received: by 10.142.215.5 with SMTP id n5mr1765710wfg.11.1203912588168; Sun, 24 Feb 2008 20:09:48 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 30sm8167304wff.11.2008.02.24.20.09.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Feb 2008 20:09:46 -0800 (PST) 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 m1P49eIt044258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2008 13:09:40 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1P49a3t044257; Mon, 25 Feb 2008 13:09:36 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 25 Feb 2008 13:09:36 +0900 From: Pyun YongHyeon To: Raul Message-ID: <20080225040936.GG42733@cdnetworks.co.kr> References: <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> <20080222041715.GA30497@cdnetworks.co.kr> <20080222054103.GD30497@cdnetworks.co.kr> <47BF6455.2020603@pop.isdefe.es> <20080223023142.GA35336@cdnetworks.co.kr> <47C01818.2090704@pop.isdefe.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C01818.2090704@pop.isdefe.es> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 04:09:50 -0000 On Sat, Feb 23, 2008 at 01:56:56PM +0100, Raul wrote: > Pyun YongHyeon escribi?: > > [....] > > > >Download if_re.c and if_rlreg.h in the following URL and rebuild the > > > >driver. > > > >http://people.freebsd.org/~yongari/re/7.0R/if_re.c > > > >http://people.freebsd.org/~yongari/re/7.0R/if_rlreg.h > > > > > > I've tested it against my 'netcat | tar' and it improves as it takes > > > four iterations (instead of one) to fall down (nearly unusable). I've > > > not run it so many times in a row on CURRENT. Must I try it again?. > > > That's what pciconf says about my re0: > > > > > > re0@pci0:2:15:0: class=0x020000 card=0xe0001458 chip=0x816710ec > > > rev=0x10 hdr=0x00 > > > > > > >How about disabling checksum offload on re0 side? > > After 6 iterations everything looked good so I started to do other > things while the netcat was running (build ports). Shortly after > (seconds), the problems appear again. Now, I'm not sure how reliable the > testing procedure is and there are other issues with the chipset (AMD > 690G), usb support problems, the sata subsystem is not well recognized > ... I've seen also problems on this box while using em0 so too complex > environment to isolate the possible re0 problem. While I'll be glad to > test whatever you ask me for, too loose ends on this box nowadays. > Sorry, no clue yet. I guess seeing smiliar issues on other network interfaces would indicate the problem is in other area. If you can isolate re(4) issues please let me know asap. > Regards, > Raul -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 04:31:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 422A716A400 for ; Mon, 25 Feb 2008 04:31:31 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0439C13C4CE for ; Mon, 25 Feb 2008 04:31:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from Macintosh-2.local ([10.0.0.196]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m1P4VO6X094091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Feb 2008 20:31:24 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47C2449C.2060906@errno.com> Date: Sun, 24 Feb 2008 20:31:24 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20080222042700.GB30497@cdnetworks.co.kr> <20080222094742.GF30497@cdnetworks.co.kr> <47C0678D.20905@errno.com> <20080225035617.GF42733@cdnetworks.co.kr> In-Reply-To: <20080225035617.GF42733@cdnetworks.co.kr> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: Ian FREISLICH , Robert Backhaus , FreeBSD Current Subject: Re: Packet corruption in re0 [checksum offloading] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 04:31:31 -0000 Pyun YongHyeon wrote: > On Sat, Feb 23, 2008 at 10:35:57AM -0800, Sam Leffler wrote: > > Pyun YongHyeon wrote: > > >On Fri, Feb 22, 2008 at 10:43:22AM +0200, Ian FREISLICH wrote: > > > > Pyun YongHyeon wrote: > > > > > On Thu, Feb 21, 2008 at 01:18:18PM +0200, Ian FREISLICH wrote: > > > > > > Pyun YongHyeon wrote: > > > > > > > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > > > > > > > > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon > > > wr > > > > ote: > > > > > > > > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus > > > wrote: > > > > > > > > > > I am experiencing roughly 15% packet corruption on the > > > re inter > > > > face > > > > > > on > > > > > > > > > > my freebsd 7/amd64 box. > > > > > > > > > > > > > > > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD > > > 7.0-PRERELEA > > > > SE #8 > > > > > > : > > > > > > > > > > Tue Feb 5 09:49:55 EST 2008 > > > > > > > > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > > > > > > > > > > > > > > > Just to make troubleshooting difficult, this problem > > > only shows > > > > up > > > > > > > > > > after the system has been up for roughly 36 hours, > > > depending on > > > > the > > > > > > > > > > amount of traffic. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I didn't take a look attached tcpdump files but I guess the > > > > > > > > > instability issue was fixed in HEAD. It's not yet MFCed but > > > > > > > > > I'll handle it in a week. > > > > > > > > > > > > > > > > > > Would you try re(4) in HEAD? > > > > > > > > > > > > > > > > > > > > > > > > > OK, I'll do that. What is the best way to do that? csupping > > > to "." se > > > > ems a > > > > > > > > bit drastic, and I don't do much with cvs proper. I take it > > > that I sh > > > > ould > > > > > > use > > > > > > > > anon-cvs to grab the directory, but I don't quite know how. > > > > > > > > > > > > > > > > > > > > > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > > > > > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to > > > add > > > > > > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c > > > on > > > > > > > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > > > > > > > > > > This doesn't solve the problem that I'm seeing on re(4) interfaces. > > > > > > It basically shows up as quagga establishing OSPF neighours as > > > > > > "Exchange/DR" when VLAN hardware tagging is enabled. I'm running > > > > > > OSPF over 802.1Q vlans. Neighbours are correctly negotiated once > > > > > > VLAN hardware tagging is disabled on the interface. > > > > > > > > > > > > I'll do more debugging. > > > > > > > > > > > > > > > > Hmm. That sounds like different issue to me. I guess I din't change > > > > > any semantics in VLAN H/W tagging. Do you still the same VLAN H/W > > > > > tagging related issues on RELENG_7? > > > > > > > > > > To narrow down the issue it would be even better to know which parts > > > > > of H/W assistance was broken. For example, > > > > > - Disable checksum offload for VLAN interface first and check > > > > > whether quagga works. > > > > > > > > You can only disable offload on the parent interface. > > > > > > > > > >Hmm... I thought it should work. > > >I have no idea why ioctl handler of vlan(4) rejects checksum > > >offload configutation. I guess vlan(4) should be teached to handle > > >this. If parent interface have IFCAP_VLAN_HWCSUM capability and > > >IFCAP_VLAN_HWTAGGING, ifconfig(4) should be able to control checksum > > >offload for vlan(4) interface. CCed to yar to get his opinions on > > >controlling checksum offload on vlan(4). > > > > > > > > - Disable checksum offload for parent interface and check again. > > > > > If you can post tcpdump output for broken conntection it may help a > > > > > lot to diagnose the issue. > > > > > > > > The only flag affecting this behaviour is vlanhwtag. Various > > > > permutations of the interface flags make no difference to this > > > > behaviour as long as hardware tagging is enabled. > > > > > > > > > >Disabling VLAN HW tagging also turns off checksum offload on vlan(4) > > >interface. > > > > > > > > > > This reminds me that there are several places in the system where h/w > > checksum offload needs to be specially handled but instead is disabled > > as a WAR. In particular I'm thinking of the bridge where txcsum is > > muted on devices while they are plumbed. But this can be a big loss and > > the better approach (IMO) is to fill in the missing capability in s/w. > > > > Agreed. > > > Not sure what components there are besides bridge and vlan; maybe lagg? > > netgraph? > > > > I'm not familiar with lagg(4) and netgraph(4). But lagg(4) should > disable Tx checksum offload if one of interface is not capable of > hardware checksum offload. Nope, don't disable; provide s/w support for the interface. > > > Note there are other capabilities besides checksum offload, TSO can be > > done in s/w with good effect. > > > > AFAIK bridge(4) blindly disables Tx checksum offload for all > members of a bridge. If all members of a bridge can do checksum > offload/TSO with hardware assistance I guess there is no reason to > disable these capabilities in bridge environments. The same apply > to lagg(4) too. > S/W checksum offload/TSO emulation for intefaces without these > hardware capabilities would greatly enhance Tx performance when > other member of interface of a bridage can make use of hardware > offload capability. TSO over 802.11n networks is important even when done in software. But the point here is that we're losing mucho performance by blindly disabling features instead of providing host replacements so members of the bridge (or other aggregate) operate w/ full functionality. Sam From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 04:34:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0750D16A401 for ; Mon, 25 Feb 2008 04:34:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.freebsd.org (Postfix) with ESMTP id 919CC13C43E for ; Mon, 25 Feb 2008 04:34:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so2099340wri.3 for ; Sun, 24 Feb 2008 20:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=obQonLCG4EmFckpFpqHsc059YFF0Ot/uSuC1TCO97hg=; b=ef214BCToKeUH4m5wk6kEgUo4uf9kb56nYPQocc01PoJzQ7Rq4lziLPRpMMpQSOg00rpe+4sQtoA63REPwuXBq1KhY5BXKtzCbihBF0ZnqcUq0TtlXdCqf9iecwKF97tIrliZ4gHUEqNfm/qGjFemhLE8VI0jIfp0nITBRKo6hA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=fI5bcyNFs//ilO8ogt0ZkIhDkLCTw0xrgt9xdVTJI9/0WW5CD5NFPh7gKzOMMFaoheyTzYEVFuZsxNbI0U8s9HB0Xc2cAHsOfHnS3YKHpBZOZge3e4hx78Qs2tnuRxhLlpiK7/jOW9TIxQ94VzbyouutMl/CFeQn5ePFKk2GwbU= Received: by 10.142.187.2 with SMTP id k2mr1775054wff.25.1203914070186; Sun, 24 Feb 2008 20:34:30 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 32sm8180596wfa.13.2008.02.24.20.34.26 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Feb 2008 20:34:27 -0800 (PST) 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 m1P4YJ7Q044335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2008 13:34:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1P4YHYv044334; Mon, 25 Feb 2008 13:34:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 25 Feb 2008 13:34:17 +0900 From: Pyun YongHyeon To: Milan Obuch Message-ID: <20080225043417.GH42733@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <20080218081801.GB14601@cdnetworks.co.kr> <20080222054356.GE30497@cdnetworks.co.kr> <200802241029.32962.freebsd-current@dino.sk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <200802241029.32962.freebsd-current@dino.sk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 04:34:32 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 24, 2008 at 10:29:31AM +0100, Milan Obuch wrote: > On Friday 22 February 2008, Pyun YongHyeon wrote: > > [ snip ] > > > > > > > I've put up a new version under the old URL. > > > It's not tested in sparc64 but it seems to work on i386. > > > Would you give it spin? > > > > Any progress here? Does the updated one works on your box? > > Well, I arranged a test today and the result is no change. > After some time box hard locks. It occurs only with if_vr kldload'ed and after > some traffic occured. No ability to enter debugger though. So while it seems > related to vr ethernet card, I can't prove it, I can't dig any usefull data > from the box. > Still, if there is some debug possibility built into driver you can point me > at, I will try. But now I have no idea what's wrong here. Hmm, this really make me mad. :-( Please apply attached patch and let me know how it goes. > Regards, > Milan > -- Regards, Pyun YongHyeon --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vr.align.patch" --- if_vr.c.orig 2008-02-18 10:46:10.000000000 +0900 +++ if_vr.c 2008-02-25 13:30:56.000000000 +0900 @@ -638,6 +638,10 @@ pci_enable_busmaster(dev); sc->vr_revid = pci_get_revid(dev); device_printf(dev, "Revision: 0x%x\n", sc->vr_revid); +#if 1 + if (sc->vr_revid == 0x96) + sc->vr_quirks |= VR_Q_NEEDALIGN; +#endif /* * Prefer memory-mapped register accesses over IO-mapped one. --qMm9M+Fa2AknHoGS-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 07:18:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40F5716A402; Mon, 25 Feb 2008 07:18:31 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id E227613C44B; Mon, 25 Feb 2008 07:18:30 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=57052 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTXbY-000C9j-HM; Mon, 25 Feb 2008 07:18:28 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1P7IQ5B044291; Mon, 25 Feb 2008 10:18:26 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1P7IPCo044290; Mon, 25 Feb 2008 10:18:25 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Mon, 25 Feb 2008 10:18:25 +0300 From: Ruslan Ermilov To: obrien@freebsd.org, Dag-Erling Sm??rgrav , Joseph Koshy , current@freebsd.org Message-ID: <20080225071825.GE18096@team.vega.ru> References: <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> <20080224212642.GA15362@plan0.kaiwan.csbnet.se> <20080224213434.GA29077@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080224213434.GA29077@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 07:18:31 -0000 On Sun, Feb 24, 2008 at 01:34:34PM -0800, David O'Brien wrote: > On Sun, Feb 24, 2008 at 10:26:42PM +0100, Kai Wang wrote: > > On Sun, Feb 24, 2008 at 12:51:21PM -0800, David O'Brien wrote: > > > What is the thing you're checking the value 700044 for? > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html > > > 700044 > > > 7.0-CURRENT after changing the argument for vn_open()/VOP_OPEN() > > > from filedescriptor index to the struct file *. > > > 700045 > > > 7.0-CURRENT after changing pam_nologin(8) to provide an account > > > management function instead of an authentication function to the > > > PAM framework. > > > > I guess, probably des@ meant that: libarchive 2.2.3 (committed > > at May 29 2007) included the last major fix to the 'ar' support, > > and 700044 (though not specific to this) bumped at Jun 7 2007 > > is closest to that day? > > If that is the case - this web page should be updated with that > information. It is find to go back after the fact and note that a > particular version number represents more than one thing. > We've been traditionally (ab)using __FreeBSD_version to bootstrap things in this way, without necessarily bumping __FreeBSD_version. There are two reasons: 1) we often don't know if a particular bug or change affects bootstrapping, so we don't always bump it. For example, a change in libc may cause some utility to be put to the list of bootstrap-tools, and we don't discover it until the version is bumped for another reason. 2) there's no harm in bootstrapping more than necessary. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 08:33:08 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94A4016A401; Mon, 25 Feb 2008 08:33:08 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 06E6213C45D; Mon, 25 Feb 2008 08:33:07 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1P8X3xs040479; Mon, 25 Feb 2008 00:33:03 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1P8Wtvc040460; Mon, 25 Feb 2008 00:32:55 -0800 (PST) (envelope-from obrien) Date: Mon, 25 Feb 2008 00:32:55 -0800 From: "David O'Brien" To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= Message-ID: <20080225083255.GA40376@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , Ruslan Ermilov , Joseph Koshy , current@freebsd.org References: <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> <20080222105413.GD94607@team.vega.ru> <20080222170007.GA2622@plan0.kaiwan.csbnet.se> <20080224181004.GC21162@dragon.NUXI.org> <86ve4dzriu.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ve4dzriu.fsf@ds4.des.no> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Joseph Koshy , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 08:33:08 -0000 On Mon, Feb 25, 2008 at 03:41:45AM +0100, Dag-Erling Smrgrav wrote: > "David O'Brien" writes: > > I don't like "gar" as that is pronounceable to the point I could easily > > see that being the real name of an existing program. > > I've told you already that there is no such program in ports. In > addition, no project by that name is registered in SourceForge, cia.vc > or ohloh.net. Did you look in every ~/bin and /usr/local/bin? > I don't see the point of being inconsistent just because > you can pronounce "gar". DES - why do you care?? Are you planning on invoking it directly? Additionally from what's been said, various autoconf configs may even explicity look for gar and use it instead of /usr/bin/ar. Given your desire to replace GNU ar with this new ar, why would you not want to use it everywhere? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 08:35:58 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 452E416A405; Mon, 25 Feb 2008 08:35:58 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 177C013C461; Mon, 25 Feb 2008 08:35:58 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1P8ZtJ4040531; Mon, 25 Feb 2008 00:35:55 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1P8ZtIQ040530; Mon, 25 Feb 2008 00:35:55 -0800 (PST) (envelope-from obrien) Date: Mon, 25 Feb 2008 00:35:55 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080225083555.GB40376@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm??rgrav , Joseph Koshy , current@freebsd.org References: <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> <20080224212642.GA15362@plan0.kaiwan.csbnet.se> <20080224213434.GA29077@dragon.NUXI.org> <20080225071825.GE18096@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080225071825.GE18096@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Dag-Erling Sm??rgrav , current@freebsd.org, Joseph Koshy Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 08:35:58 -0000 On Mon, Feb 25, 2008 at 10:18:25AM +0300, Ruslan Ermilov wrote: > We've been traditionally (ab)using __FreeBSD_version to bootstrap > things in this way, without necessarily bumping __FreeBSD_version. > There are two reasons: 1) we often don't know if a particular bug > or change affects bootstrapping, so we don't always bump it. For > example, a change in libc may cause some utility to be put to the > list of bootstrap-tools, and we don't discover it until the > version is bumped for another reason. Right, but once you've attached added significance to a particular __FreeBSD_version (after the fact) it really should be documented in the Porter's Handbook. At least I used to go add to a particular __FreeBSD_version entry once I started using that value for something other than the original bumping reason. > 2) there's no harm in bootstrapping more than necessary. Duplicated effort, and long build world times. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 08:40:06 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF7616A405; Mon, 25 Feb 2008 08:40:06 +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 F287C13C457; Mon, 25 Feb 2008 08:40:05 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1P8e3eV071926; Mon, 25 Feb 2008 03:40:04 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 24 Feb 2008 22:41:37 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Daniel Gerzo In-Reply-To: <1172441424.20080225092945@rulez.sk> Message-ID: <20080224223903.Q920@desktop> References: <845250.18624.qm@web63909.mail.re1.yahoo.com> <47BF5702.3020204@FreeBSD.org> <47BF8EB7.9090007@barafranca.com> <47BFB70F.5080402@FreeBSD.org> <20080224124342.E920@desktop> <1172441424.20080225092945@rulez.sk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, Ivan Voras Subject: Re[2]: cpu usage 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: Mon, 25 Feb 2008 08:40:06 -0000 On Mon, 25 Feb 2008, Daniel Gerzo wrote: > Hello Jeff, > > Sunday, February 24, 2008, 11:47:39 PM, you wrote: > >>> So how does a multithreaded process get 458% CPU on a quad-core machine? :) >>> (Really, I want to know; I thought thread CPU accounting was fixed in 7.x. >>> Unless I'm mistaken, 4 CPU-intensive threads in a single process should >>> account as 4 CPU-intensive single-thread processes; i.e. each could only take >>> up to 100% of a core/CPU, accounting for NCPU*100% total). >>> >>> > >> It is possible for the sum of all threads in the system to exceed 100% >> cpu. This is because the decay function is not precise. 15% over is a >> bit more than I would expect but I suppose it's possible. We also inhert >> pcpu information from the parent on fork/thread creation so the child >> isn't created with a priority as if it had been idle. So for a moment the >> utilization is duplicated. > > I have a box running mysqld, which sometimes exeeds 130%, what about > this? ;) > > Also the mysqld is alsmost all the time in the "ucond" state, what > does it mean? I've been told that it is probably waiting for I/O, but > then, I have another box which is currently completely idle, but > running mysql shows that it is "ucond" as well. You should switch top to display threads. 'H' is the key to do it. Otherwise you only get the wait channel for one of the threads. Others may be busy doing things. 'ucond' means the thread is waiting on a userland condition variable. This is a type of synchronization point in userland accessed via the pthread_cond_*(3) api. It may indicate a thread that is waiting for work but other threads may be busy. Do you only have one CPU? If you're seeing 130% on a single cpu system we may need to take some steps to improve the reporting. > > -- > Best regards, > Daniel mailto:danger@FreeBSD.org > From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 08:45:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 001A516A404; Mon, 25 Feb 2008 08:45:32 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.freebsd.org (Postfix) with ESMTP id A8E8E13C467; Mon, 25 Feb 2008 08:45:32 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id 24CDB10E74F; Mon, 25 Feb 2008 09:26:42 +0100 (CET) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ3uCMin9IRQ; Mon, 25 Feb 2008 09:26:40 +0100 (CET) Received: from DANGER-PC (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id A7FD010E731; Mon, 25 Feb 2008 09:26:40 +0100 (CET) Date: Mon, 25 Feb 2008 09:29:45 +0100 From: Daniel Gerzo X-Mailer: The Bat! (v3.99.3) Professional Organization: The FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1172441424.20080225092945@rulez.sk> To: Jeff Roberson In-Reply-To: <20080224124342.E920@desktop> References: <845250.18624.qm@web63909.mail.re1.yahoo.com> <47BF5702.3020204@FreeBSD.org> <47BF8EB7.9090007@barafranca.com> <47BFB70F.5080402@FreeBSD.org> <20080224124342.E920@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re[2]: cpu usage in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 08:45:33 -0000 Hello Jeff, Sunday, February 24, 2008, 11:47:39 PM, you wrote: >> So how does a multithreaded process get 458% CPU on a quad-core machine? :) >> (Really, I want to know; I thought thread CPU accounting was fixed in 7.x. >> Unless I'm mistaken, 4 CPU-intensive threads in a single process should >> account as 4 CPU-intensive single-thread processes; i.e. each could only take >> up to 100% of a core/CPU, accounting for NCPU*100% total). >> >> > It is possible for the sum of all threads in the system to exceed 100% > cpu. This is because the decay function is not precise. 15% over is a > bit more than I would expect but I suppose it's possible. We also inhert > pcpu information from the parent on fork/thread creation so the child > isn't created with a priority as if it had been idle. So for a moment the > utilization is duplicated. I have a box running mysqld, which sometimes exeeds 130%, what about this? ;) Also the mysqld is alsmost all the time in the "ucond" state, what does it mean? I've been told that it is probably waiting for I/O, but then, I have another box which is currently completely idle, but running mysql shows that it is "ucond" as well. -- Best regards, Daniel mailto:danger@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 09:15:12 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C973616A401 for ; Mon, 25 Feb 2008 09:15:12 +0000 (UTC) (envelope-from astrodog@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 8354513C46B for ; Mon, 25 Feb 2008 09:15:12 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so2254526wri.3 for ; Mon, 25 Feb 2008 01:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ozEiN6vqChrDouHL+VDmB1pjZ2R2+MjmLIPaW/ePbDM=; b=mevxzsOWAKWv93wid41M80eiTlWOR3++63clOzrflLA+8PFpSSn98HZllZcthpR1fI5owL2CFx0orQ/JFrkO5Ym6qF/3oWWQq0lN/HhR8VHVEsvaU35A/d/rUwyDXUMe7BHfE7tTCFG6ETHNrSxfK5DTJKuVsWvjBD/c6f7SgPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z/iFjLl1cEADfVicqWAEBoWuuRGk89xgyQmJUI1H1EWVpFeRgnik3d7PsN1pCOg8KarCr+4FTFqszB3mKwdMWh920Z1AkpcLSwubLeBlzaVXC2vsxatRAF8lnnNuD8LciSzGgx921H2PJeee/0mBHXesWsY8BzGn305wwx0IU9I= Received: by 10.141.69.1 with SMTP id w1mr1835995rvk.147.1203929168626; Mon, 25 Feb 2008 00:46:08 -0800 (PST) Received: by 10.141.68.21 with HTTP; Mon, 25 Feb 2008 00:46:08 -0800 (PST) Message-ID: <2fd864e0802250046v49ed9833q390d7b214481a2a9@mail.gmail.com> Date: Mon, 25 Feb 2008 16:46:08 +0800 From: Astrodog To: current@freebsd.org In-Reply-To: <20080225083555.GB40376@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86wsoxp2ob.fsf@ds4.des.no> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> <20080224212642.GA15362@plan0.kaiwan.csbnet.se> <20080224213434.GA29077@dragon.NUXI.org> <20080225071825.GE18096@team.vega.ru> <20080225083555.GB40376@dragon.NUXI.org> Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 09:15:12 -0000 In as far as gnu-ar vs gar goes... I want mine blue, thanks. I think being able to decide which "ar" one uses could be fairly important. I'm not entirely confident that now, and forever more, they will have identical functionality. --- Harrison From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 10:16:39 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1320716A401; Mon, 25 Feb 2008 10:16:39 +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 BD93813C459; Mon, 25 Feb 2008 10:16: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 83E22208C; Mon, 25 Feb 2008 11:16:35 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 5485E2084; Mon, 25 Feb 2008 11:16:34 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> <20080224212642.GA15362@plan0.kaiwan.csbnet.se> <20080224213434.GA29077@dragon.NUXI.org> <20080225071825.GE18096@team.vega.ru> <20080225083555.GB40376@dragon.NUXI.org> Date: Mon, 25 Feb 2008 11:16:32 +0100 In-Reply-To: <20080225083555.GB40376@dragon.NUXI.org> (David O'Brien's message of "Mon\, 25 Feb 2008 00\:35\:55 -0800") Message-ID: <86y799ibnj.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joseph Koshy , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 10:16:39 -0000 "David O'Brien" writes: > Ruslan Ermilov writes: > > 2) there's no harm in bootstrapping more than necessary. > Duplicated effort, and long build world times. Uh, David, it's only a few days, and it only adds a couple of minutes at most for those upgrading in the window between the libarchive fix and 7000044. You're splitting hairs - although I agree about documenting it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 10:20:57 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9246C16A40D; Mon, 25 Feb 2008 10:20:57 +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 40FEF13C468; Mon, 25 Feb 2008 10:20:57 +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 26D632094; Mon, 25 Feb 2008 11:20:54 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 6852B2092; Mon, 25 Feb 2008 11:20:53 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> <20080222105413.GD94607@team.vega.ru> <20080222170007.GA2622@plan0.kaiwan.csbnet.se> <20080224181004.GC21162@dragon.NUXI.org> <86ve4dzriu.fsf@ds4.des.no> <20080225083255.GA40376@dragon.NUXI.org> Date: Mon, 25 Feb 2008 11:20:52 +0100 In-Reply-To: <20080225083255.GA40376@dragon.NUXI.org> (David O'Brien's message of "Mon\, 25 Feb 2008 00\:32\:55 -0800") Message-ID: <86tzjxibgb.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joseph Koshy , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 10:20:57 -0000 "David O'Brien" writes: > Additionally from what's been said, various autoconf configs may even > explicity look for gar and use it instead of /usr/bin/ar. Given your > desire to replace GNU ar with this new ar, why would you not want to use > it everywhere? 1) I doubt it 2) bsd.ports.mk already addresses this for gmake by explicitly setting MAKE=3Dgmake, it is trivial to extend this with AR=3D/usr/bin/ar and RANLIB=3D/usr/bin/ranlib if you're so worried. This is getting really counter-productive... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 11:39:57 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DF8516A403; Mon, 25 Feb 2008 11:39:57 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id AE78513C474; Mon, 25 Feb 2008 11:39:56 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=52157 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTbgY-000AkL-1m; Mon, 25 Feb 2008 11:39:54 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1PBdpSw075988; Mon, 25 Feb 2008 14:39:51 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1PBdpYc075987; Mon, 25 Feb 2008 14:39:51 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Mon, 25 Feb 2008 14:39:51 +0300 From: Ruslan Ermilov To: obrien@freebsd.org, Dag-Erling Sm??rgrav , Joseph Koshy , current@freebsd.org Message-ID: <20080225113950.GF18096@team.vega.ru> References: <20080223201808.GB65540@team.vega.ru> <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> <20080224212642.GA15362@plan0.kaiwan.csbnet.se> <20080224213434.GA29077@dragon.NUXI.org> <20080225071825.GE18096@team.vega.ru> <20080225083555.GB40376@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080225083555.GB40376@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 11:39:57 -0000 On Mon, Feb 25, 2008 at 12:35:55AM -0800, David O'Brien wrote: > > 2) there's no harm in bootstrapping more than necessary. > > Duplicated effort, and long build world times. > Ahem. It's less than two seconds in wall clock time on a modern hardware. :-) Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 13:00:09 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71FA016A403 for ; Mon, 25 Feb 2008 13:00:09 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 4048413C459 for ; Mon, 25 Feb 2008 13:00:09 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:Subject:From:X-Attribution:Date:Message-Id; b=QH+h0ou5LafFsRBS8eAhIBGXwXS2tQuMYaoDLq18HBjh+rRS5AN4hlRl7ay/Yzt7ZZSQJUl8v7Xm8phPj6TWsSHSwaFtHIz5Lezv6oXW1yITQU2BuvrUufsZOIvonqn/EbOz6hNNzySFvMkKSYQDVXBDKQKfbhY+S+FWpFdwL3IvTdGKjeYb1TnDJwFu59IZ8veFKSZ0FZfprOkCf/QFsxRRgCiN+UvlIRNMunMSo5Rl9LeVOavoAxVZE92bXB4y; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1JTcwC-0006mC-FL for current@freebsd.org; Mon, 25 Feb 2008 13:00:08 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JTcvm-0000W0-5V for current@freebsd.org; Mon, 25 Feb 2008 12:59:42 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JTcvl-0001cp-08 for current@freebsd.org; Mon, 25 Feb 2008 14:59:41 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Mon, 25 Feb 2008 14:59:40 +0200 Message-Id: Cc: Subject: spamassassin/network/SYN 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: Mon, 25 Feb 2008 13:00:09 -0000 Hi I'm trying Spamassassin on that 16 way AMD box I mentioned earlier and I'm running into problems loading the server. I'm using 5 servers each opening up to 60 concurrent connections to spamd to generate the scanning load, but I'm getting this message: Feb 25 14:08:15 amd64 kernel: Limiting open port RST response from 2979 to 200 packets/sec Which strangely seems to be controlled by net.inet.icmp.icmplim. There the comes a time when the system thinks it's being SYN-attacked or the listen backlog is exhausted and starts rejecting incoming connections with the above message. The fastest It's able to process messages is about 1400 per minute. This figure is about 500 messages a minute less than Debian can process on the same hardware with the same spamd configuration, without rejecting any inbound connections at connect time. Any ideas how to improve things? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 13:03:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3402B16A401; Mon, 25 Feb 2008 13:03:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id DC12913C459; Mon, 25 Feb 2008 13:03:57 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id C25D043CFE3; Mon, 25 Feb 2008 15:03:56 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nXdsVkY3tw2; Mon, 25 Feb 2008 15:03:56 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 63C5C43CDA0; Mon, 25 Feb 2008 15:03:56 +0200 (EET) Message-ID: <47C2BCBA.6090901@icyb.net.ua> Date: Mon, 25 Feb 2008 15:03:54 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org, freebsd-current@freebsd.org References: <4799D78F.6000405@icyb.net.ua> <47A097FA.3090303@icyb.net.ua> <20080130164508.GC6257@suse.cz> <47A2E7E5.1040307@icyb.net.ua> <20080201093806.GA4632@suse.cz> <47A738AE.5070900@icyb.net.ua> <47AB29D4.1040409@icyb.net.ua> In-Reply-To: <47AB29D4.1040409@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: ps/2 mouse patch [intellimouse explorer detection] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 13:03:58 -0000 This is an annoying reminder :-) that FreeBSD psm driver still incorrectly probes mice for MS Intellimouse Explorer protocol. http://www.microsoft.com/whdc/device/input/5b_wheel.mspx http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118578 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 13:38:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C53D16A402 for ; Mon, 25 Feb 2008 13:38:45 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from mx1.rink.nu (alastor.rink.nu [213.34.49.5]) by mx1.freebsd.org (Postfix) with ESMTP id 3653413C45B for ; Mon, 25 Feb 2008 13:38:44 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from localhost (alastor.rink.nu [213.34.49.5]) by mx1.rink.nu (Postfix) with ESMTP id CC6F3BFECAB; Mon, 25 Feb 2008 13:38:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.5]) by localhost (alastor.rink.nu [213.34.49.5]) (amavisd-new, port 10024) with ESMTP id obWYbuxmLEWe; Mon, 25 Feb 2008 13:38:30 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id D0703BFEB8E; Mon, 25 Feb 2008 13:38:30 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) by tragedy.rink.nu (8.13.8/8.13.8) with ESMTP id m1PDcUSG098406; Mon, 25 Feb 2008 14:38:30 +0100 (CET) (envelope-from rink@tragedy.rink.nu) Received: (from rink@localhost) by tragedy.rink.nu (8.13.8/8.13.8/Submit) id m1PDcTNR098405; Mon, 25 Feb 2008 14:38:29 +0100 (CET) (envelope-from rink) Date: Mon, 25 Feb 2008 14:38:29 +0100 From: Rink Springer To: Andriy Gapon Message-ID: <20080225133829.GE23743@rink.nu> References: <4799D78F.6000405@icyb.net.ua> <47A097FA.3090303@icyb.net.ua> <20080130164508.GC6257@suse.cz> <47A2E7E5.1040307@icyb.net.ua> <20080201093806.GA4632@suse.cz> <47A738AE.5070900@icyb.net.ua> <47AB29D4.1040409@icyb.net.ua> <47C2BCBA.6090901@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C2BCBA.6090901@icyb.net.ua> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: ps/2 mouse patch [intellimouse explorer detection] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 13:38:45 -0000 On Mon, Feb 25, 2008 at 03:03:54PM +0200, Andriy Gapon wrote: > This is an annoying reminder :-) > that FreeBSD psm driver still incorrectly probes mice for MS > Intellimouse Explorer protocol. I think the patch is correct - I'll commit it in a few hours. Thank you for your persistance! -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 14:13:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7CE016A404; Mon, 25 Feb 2008 14:13:23 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7BDFD13C46A; Mon, 25 Feb 2008 14:13:23 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 5A20643E0B6; Mon, 25 Feb 2008 16:13:21 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM0IqLGuAplq; Mon, 25 Feb 2008 16:13:21 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id DDD0143DD27; Mon, 25 Feb 2008 16:13:20 +0200 (EET) Message-ID: <47C2CCFF.8030709@icyb.net.ua> Date: Mon, 25 Feb 2008 16:13:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Rink Springer References: <4799D78F.6000405@icyb.net.ua> <47A097FA.3090303@icyb.net.ua> <20080130164508.GC6257@suse.cz> <47A2E7E5.1040307@icyb.net.ua> <20080201093806.GA4632@suse.cz> <47A738AE.5070900@icyb.net.ua> <47AB29D4.1040409@icyb.net.ua> <47C2BCBA.6090901@icyb.net.ua> <20080225133829.GE23743@rink.nu> In-Reply-To: <20080225133829.GE23743@rink.nu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: ps/2 mouse patch [intellimouse explorer detection] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 14:13:23 -0000 on 25/02/2008 15:38 Rink Springer said the following: > On Mon, Feb 25, 2008 at 03:03:54PM +0200, Andriy Gapon wrote: >> This is an annoying reminder :-) >> that FreeBSD psm driver still incorrectly probes mice for MS >> Intellimouse Explorer protocol. > > I think the patch is correct - I'll commit it in a few hours. > > Thank you for your persistance! Thank you very much! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 15:49:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA30D16A401 for ; Mon, 25 Feb 2008 15:49:14 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout3-sn1.fre.skanova.net (pne-smtpout3-sn1.fre.skanova.net [81.228.11.120]) by mx1.freebsd.org (Postfix) with ESMTP id 956D113C45A for ; Mon, 25 Feb 2008 15:49:14 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from chaos.nox (80.221.12.61) by pne-smtpout3-sn1.fre.skanova.net (7.3.129) (authenticated as tansmi-f) id 47A78857001195AB; Mon, 25 Feb 2008 16:49:13 +0100 Date: Mon, 25 Feb 2008 17:48:53 +0200 From: Mikael Ikivesi Message-ID: <20080225174853.13967927@chaos.nox> X-Mailer: Claws Mail 3.3.0 (GTK+ 2.12.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; X-Mailman-Approved-At: Mon, 25 Feb 2008 15:54:01 +0000 Subject: it was usb problem (was 2 core dumps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 15:49:15 -0000 It seems that those two core dumps I reported are somehow connected to libusb and kernel usb. As I have libusb installed (came to my system because of hplip/sane stuff) I now can crash this system with everytime I plug in usb-stick. I think what happened with my previous reboots was that somehow hald or something poked something from usb (printer/usb-stick/nothing) and caused those crashes. I can use usb-sticks without panicing if I dont dont run hplip&hald&cups at startup time. Or if the usb-key has been inserted before these services get started (But I am quite sure that these crashes can happen after successful boot after awhile like I had it happen in the first place) It crashes differently almost everytime and reboots the machine. And please note that if I dont use that libusb/hplip stuff my usb works! So it is not about failing hardware. (And yes! I have chechked for possiblity of broken memory....And I have rebuild world and kernel and ports....) So could anyone tell me where this should be reported: freebsd-usb? freebsd-ports? or is it considered as kernel bug as a port can crash whole system? -Mikael 2 examples of coredumps are here: --------------- First something more solveable --------------- 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:0xc060029b stack pointer = 0x28:0xe30a8ad8 frame pointer = 0x28:0xe30a8ae4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 881 (hald-probe-storage) trap number = 12 panic: page fault Uptime: 10m33s Physical memory: 886 MB Dumping 53 MB: 38 22 6 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc05cd21c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc05cd624 in panic (fmt=0xc09512dd "%s") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc091127d in trap_fatal (frame=0xe30a8a98, eva=24) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0912032 in trap (frame=0xe30a8a98) at /usr/src/sys/i386/i386/trap.c:280 #5 0xc08faf6b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc060029b in turnstile_broadcast (ts=0x0, queue=0) at /usr/src/sys/kern/subr_turnstile.c:834 #7 0xc05bfc72 in _mtx_unlock_sleep (m=0xc09fbef0, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:605 #8 0xc05bff43 in unlock_mtx (lock=0xc09fbef0) at /usr/src/sys/kern/kern_mutex.c:158 #9 0xc05d5f25 in _sleep (ident=0x0, lock=0xc09fbef0, priority=256, wmesg=0xc0952db6 "sgread", timo=0) at /usr/src/sys/kern/kern_synch.c:187 #10 0xc0479535 in sgread (dev=0xc3e4e100, uio=0xe30a8c54, ioflag=0) at /usr/src/sys/cam/scsi/scsi_sg.c:798 #11 0xc0598013 in giant_read (dev=0xc3e4e100, uio=0xe30a8c54, ioflag=0) at /usr/src/sys/kern/kern_conf.c:361 #12 0xc0535ecd in devfs_read_f (fp=0xc3ce6bd0, uio=0xe30a8c54, cred=0xc385ce00, flags=0, td=0xc3b3b420) at /usr/src/sys/fs/devfs/devfs_vnops.c:880 #13 0xc06025a0 in dofileread (td=0xc3b3b420, fd=4, fp=0xc3ce6bd0, auio=0xe30a8c54, offset=-1, flags=0) at file.h:242 #14 0xc0602948 in kern_readv (td=0xc3b3b420, fd=4, auio=0xe30a8c54) at /usr/src/sys/kern/sys_generic.c:192 #15 0xc0602a30 in read (td=0xc3b3b420, uap=0xe30a8cf8) at /usr/src/sys/kern/sys_generic.c:108 #16 0xc0911834 in syscall (frame=0xe30a8d38) at /usr/src/sys/i386/i386/trap.c:1035 #17 0xc08fafd0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #18 0x00000033 in ?? () --------------- Then something harder :) --------------- 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". (kgdb) bt #0 0x00000000 in ?? () And debugger just complains that it cannot access memory address 0x0 From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 15:56:26 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9077616A40B for ; Mon, 25 Feb 2008 15:56:26 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: from web33708.mail.mud.yahoo.com (web33708.mail.mud.yahoo.com [68.142.201.205]) by mx1.freebsd.org (Postfix) with SMTP id 579E413C510 for ; Mon, 25 Feb 2008 15:56:26 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: (qmail 97154 invoked by uid 60001); 25 Feb 2008 15:29:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=g047ibCrF4J25IsoLvEL974it6lYM/o+Q+t95+8DvolfaBIf4u9HRcUNL/QAFE+zZ8ZHlGsHWZLdEqiWOjhv7cKNpFjoQVIvXiGuXXZgEktJmuya5REPT7NdizY3poYd1co5F9MBuCsv/TQvJVrL/ljzTfopKExzaqc/Sbqhek8=; Received: from [82.148.96.69] by web33708.mail.mud.yahoo.com via HTTP; Mon, 25 Feb 2008 07:29:44 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Mon, 25 Feb 2008 07:29:44 -0800 (PST) From: Abdullah Ibn Hamad Al-Marri To: Jeff Roberson , current@freebsd.org MIME-Version: 1.0 Message-ID: <316530.95933.qm@web33708.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: cpuset and affinity implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 15:56:26 -0000 Jeff this is great! Would it hit RELENG_7 in the future? Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal ----- Original Message ---- From: Jeff Roberson To: current@freebsd.org Sent: Monday, February 25, 2008 6:38:37 AM Subject: cpuset and affinity implementation Hello, I have implemented a new api similar to processors sets on solaris. This allows you to assign processes to sets of cpus and dynamically change those sets. This is useful for provisioning purposes to add and remove cpu resources for a particular process or group of processes. This new facility also supports binding secific threads to specific cpus which some applications may want to do. At some point in the future this will be integrated with jail so you can restrict the cpus any jail is allowed to use. This api should not be considered final and the 'cpuset' tool is quite rough. This also only works with ULE and is unfortunately intertwined with a big ULE patch I've been working on. The set management code is generic but 4BSD doesn't contain the hooks to actually constrain threads. Please see: http://people.freebsd.org/~jeff/cpuset.diff here's a couple of neat things to do with cpuset: cpuset -l 0-4 /bin/sh This creates a new group with a list (-l) of cpus 0-4 inclusive and runs sh in it. cpuset -g -p This will get (-g) the mask of cpus pid (-p) is allowed to run on. cpuset -l 0,2 -p This will restrict sh to running on cpus 0, 2 while its group is still allowed 0-4. cpuset -l 0,2 -c -p This will modify the cpuset (-c) that the sh belongs to. cpuset -l 0-3 -s 1 This will modify the set (-s) that all threads are in by default to contain the first 4 cpus leaving the rest idled. cpuset -g -i -p This will print the id of the set sh is in. cpuset -s -p This will move pid into the specified set so it may be managed with other pids in that set. Feedback is appreciated. Thanks, Jeff _______________________________________________ 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" ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 15:56:54 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5CFB16A403; Mon, 25 Feb 2008 15:56:54 +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 688E413C4FB; Mon, 25 Feb 2008 15:56:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5414A.dip.t-dialin.net [84.165.65.74]) by redbull.bpaserver.net (Postfix) with ESMTP id F3C372E0D2; Mon, 25 Feb 2008 16:56:43 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 626AF7DDC6; Mon, 25 Feb 2008 16:56:39 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m1PFucZC086014; Mon, 25 Feb 2008 16:56:38 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 25 Feb 2008 16:56:37 +0100 Message-ID: <20080225165637.d3qolb0z4o0k4w8s@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 25 Feb 2008 16:56:37 +0100 From: Alexander Leidinger To: "Bruce A. Mah" References: <511FC3E9-937C-475C-8F1B-39BA5347DBE0@gmail.com> <47C192C4.4080109@freebsd.org> <47C1B8CE.9060507@freebsd.org> In-Reply-To: <47C1B8CE.9060507@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) / FreeBSD-8.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 6, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: current@freebsd.org, jkim@freebsd.org Subject: Re: Gathering a list of showstoppers for RELENG_7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 15:56:54 -0000 Quoting "Bruce A. Mah" (from Sun, 24 Feb 2008 10:34:54 -0800): > There *are* some outstanding issues in 7.0, for which we're > contemplating some errata notices (and hence patches for RELENG_7_0). > I'm being deliberately vague here because I don't want to commit us to > anything yet, but two *possible* items are some if_re fixes and a > change in TCP options handling. For errata items, we need to wait for > the actual release to wrap up (duh) and also give the fixes some "soak > time" in HEAD and RELENG_7. There's also an linuxulator item which jkim@ fixed in -current, RELENG_7 and RELENG_6 which needs to be noted in the errata of 7.0 and 6.3. Bye, Alexander. -- Arbitrary systems, pl.n.: Systems about which nothing general can be said, save "nothing general can be said." 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 Feb 25 17:16:37 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6559816A407; Mon, 25 Feb 2008 17:16:37 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 47C2C13C46B; Mon, 25 Feb 2008 17:16:37 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1PHGYlg081004; Mon, 25 Feb 2008 09:16:34 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1PHGUgQ081003; Mon, 25 Feb 2008 09:16:30 -0800 (PST) (envelope-from obrien) Date: Mon, 25 Feb 2008 09:16:30 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080225171630.GA80931@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm??rgrav , Joseph Koshy , current@freebsd.org References: <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> <20080224212642.GA15362@plan0.kaiwan.csbnet.se> <20080224213434.GA29077@dragon.NUXI.org> <20080225071825.GE18096@team.vega.ru> <20080225083555.GB40376@dragon.NUXI.org> <20080225113950.GF18096@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080225113950.GF18096@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Dag-Erling Sm??rgrav , current@freebsd.org, Joseph Koshy Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 17:16:37 -0000 On Mon, Feb 25, 2008 at 02:39:51PM +0300, Ruslan Ermilov wrote: > On Mon, Feb 25, 2008 at 12:35:55AM -0800, David O'Brien wrote: > > > 2) there's no harm in bootstrapping more than necessary. > > > > Duplicated effort, and long build world times. > > Ahem. It's less than two seconds in wall clock time on a > modern hardware. :-) Unless we build everything as a bootstrap tool (related to Marcel's comment in this thread). Do you have a new diff that doesn't use any of the WITH_* stuff and just converts to using the new 'ar'? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 17:18:56 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CE8516A419; Mon, 25 Feb 2008 17:18:56 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id F3BA713C45A; Mon, 25 Feb 2008 17:18:55 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1PHIrtQ081085; Mon, 25 Feb 2008 09:18:53 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1PHIrx3081084; Mon, 25 Feb 2008 09:18:53 -0800 (PST) (envelope-from obrien) Date: Mon, 25 Feb 2008 09:18:53 -0800 From: "David O'Brien" To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= Message-ID: <20080225171853.GB80931@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , Ruslan Ermilov , Joseph Koshy , current@freebsd.org References: <20080224180433.GA21162@dragon.NUXI.org> <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> <20080224212642.GA15362@plan0.kaiwan.csbnet.se> <20080224213434.GA29077@dragon.NUXI.org> <20080225071825.GE18096@team.vega.ru> <20080225083555.GB40376@dragon.NUXI.org> <86y799ibnj.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86y799ibnj.fsf@ds4.des.no> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Joseph Koshy , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 17:18:56 -0000 On Mon, Feb 25, 2008 at 11:16:32AM +0100, Dag-Erling Smrgrav wrote: > "David O'Brien" writes: > > Ruslan Ermilov writes: > > > 2) there's no harm in bootstrapping more than necessary. > > Duplicated effort, and long build world times. > > Uh, David, it's only a few days, and it only adds a couple of minutes at > most for those upgrading in the window between the libarchive fix and > 7000044. You're splitting hairs - although I agree about documenting it. No - you're misunderstanding me. ALL I'm saying is when one uses a particular __FreeBSD_version they should document the significance of that version in the Porter's Handbook. One should be able to look up why that particular number was used. I am not in the lest bit complaining that the value 7000044 isn't the exact second the event ru is testing for occurred. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 17:30:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82FE616A404 for ; Mon, 25 Feb 2008 17:30:35 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout4-sn1.fre.skanova.net (pne-smtpout4-sn1.fre.skanova.net [81.228.11.168]) by mx1.freebsd.org (Postfix) with ESMTP id 5195A13C478 for ; Mon, 25 Feb 2008 17:30:35 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from chaos.nox (80.221.12.61) by pne-smtpout4-sn1.fre.skanova.net (7.3.129) (authenticated as tansmi-f) id 47A7970A0011BAB1 for freebsd-current@freebsd.org; Mon, 25 Feb 2008 18:30:33 +0100 Date: Mon, 25 Feb 2008 19:30:14 +0200 From: Mikael Ikivesi To: freebsd-current Message-ID: <20080225193014.36f52193@chaos.nox> X-Mailer: Claws Mail 3.3.0 (GTK+ 2.12.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: it was usb problem (was 2 core dumps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 17:30:35 -0000 Sorry, but I forgot to add version numbers of the ports concerned: libusb-0.1.12_1 hplip-2.7.12 And I am running FreeBSD RELENG_7 (cvsupped and rebuild within 48hrs) -Mikael From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 17:48:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D4816A402 for ; Mon, 25 Feb 2008 17:48:33 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id D844413C442 for ; Mon, 25 Feb 2008 17:48:32 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-a916e555.03-51-73746f3.cust.bredbandsbolaget.se (c-a916e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.169]) by smtp.infidyne.com (Postfix) with ESMTP id 8DD6E34385; Mon, 25 Feb 2008 18:48:30 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Mon, 25 Feb 2008 18:49:44 +0100 User-Agent: KMail/1.9.7 References: <20080213133156.GA5645@eos.sc1.parodius.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4959269.Z3h79Qx1Hk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802251849.53370.peter.schuller@infidyne.com> Cc: freebsd-fs@freebsd.org, Ivan Voras Subject: Re: ZFS lockup in "zfs" state X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 17:48:33 -0000 --nextPart4959269.Z3h79Qx1Hk Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > >>>> A machine just wedged its ZFS file systems (UFS file systems were > >>>> still running), all unresponsive processes were in "zfs" state. This > >>>> is 7.0-RC1 on i386 with 2 GB RAM. It has happened at least once > >>>> before. > > +1; happened again, same symptoms. I also saw this a couple of days ago (first time for me) on 1 7.0-RCX (not= =20 sure if it was RC1 or RC2, and I can't log in to the machine right now). Th= is=20 was recently after upgrading it from an older CURRENT from september. The machine is amd64, 4 GB of RAM, with a single three-way mirror pool. =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart4959269.Z3h79Qx1Hk 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) iD8DBQBHwv/BDNor2+l1i30RArpaAKCbJb7zQx/vp5NUhwULyFRQ9yfOdACeJyI1 8eUmrH+lWYbLw1cBjPeMzcM= =5ozS -----END PGP SIGNATURE----- --nextPart4959269.Z3h79Qx1Hk-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 17:56:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8536616A40B for ; Mon, 25 Feb 2008 17:56:43 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id 4778913C458 for ; Mon, 25 Feb 2008 17:56:43 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-a916e555.03-51-73746f3.cust.bredbandsbolaget.se (c-a916e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.169]) by smtp.infidyne.com (Postfix) with ESMTP id 4EBAF343B9 for ; Mon, 25 Feb 2008 18:56:42 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Mon, 25 Feb 2008 18:58:05 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5677405.VBiEmWhc7q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802251858.05767.peter.schuller@infidyne.com> Subject: Recommended virtualization technique for debugging/developing FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 17:56:43 -0000 --nextPart5677405.VBiEmWhc7q Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I was wondering what people use, in the abscense of suitable actual hardwar= e,=20 to debug/develop FreeBSD (the kernel in particular). I'm willing to resort = to=20 almost any host, including Windows, as long as I have something reliable. I haven't had much luck with qemu (crashes), nor virtualbox (crashes). I wa= s=20 going to go for vmware on Windows, but while it ran FreeBSD pretty well,=20 before I had even percolated the disk layout enough to trigger the bug=20 (required root-on-zfs) I was hoping to trigger, the vmware configuration to= ol=20 crapped out on me and produced a configuration it could not itself read. What do all you regular kernel developers use, if not physical hardware? =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart5677405.VBiEmWhc7q 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) iD8DBQBHwwGtDNor2+l1i30RAvboAKDDj4LK9hoywdaCh6PasZug280lfgCgp5SQ sXZ7jjHrTncVQv+hgEIT1NY= =/4fU -----END PGP SIGNATURE----- --nextPart5677405.VBiEmWhc7q-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 17:57:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 816E716A414 for ; Mon, 25 Feb 2008 17:57:42 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE5913C4D1 for ; Mon, 25 Feb 2008 17:57:42 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-a916e555.03-51-73746f3.cust.bredbandsbolaget.se (c-a916e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.169]) by smtp.infidyne.com (Postfix) with ESMTP id 573C3343C0; Mon, 25 Feb 2008 18:57:41 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Mon, 25 Feb 2008 18:59:04 +0100 User-Agent: KMail/1.9.7 References: <200802251849.53370.peter.schuller@infidyne.com> In-Reply-To: <200802251849.53370.peter.schuller@infidyne.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1249783.BsGrgAAx70"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802251859.05045.peter.schuller@infidyne.com> Cc: freebsd-fs@freebsd.org, Ivan Voras Subject: Re: ZFS lockup in "zfs" state X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 17:57:42 -0000 --nextPart1249783.BsGrgAAx70 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > I also saw this a couple of days ago (first time for me) on 1 7.0-RCX (not > sure if it was RC1 or RC2, and I can't log in to the machine right now). > This was recently after upgrading it from an older CURRENT from september. > > The machine is amd64, 4 GB of RAM, with a single three-way mirror pool. With prefetch disabled, arc size upped to 800 megs, and kmem size upped to = 1.2=20 gb (IIRC). =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart1249783.BsGrgAAx70 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) iD8DBQBHwwHpDNor2+l1i30RAgnKAKCbcuaCtXIv4jmyFJkqdTPoAzf4vACgtg3D Xi6QSLZYc1iVrJBZ/mHxDew= =R/UB -----END PGP SIGNATURE----- --nextPart1249783.BsGrgAAx70-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 18:52:13 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B229B16A401; Mon, 25 Feb 2008 18:52:13 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.freebsd.org (Postfix) with ESMTP id 6F61713C45D; Mon, 25 Feb 2008 18:52:13 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id 4359910E6BC; Mon, 25 Feb 2008 19:51:03 +0100 (CET) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YGGnEHoYAag; Mon, 25 Feb 2008 19:51:01 +0100 (CET) Received: from DANGER-PC (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id C35B910E629; Mon, 25 Feb 2008 19:51:01 +0100 (CET) Date: Mon, 25 Feb 2008 19:54:08 +0100 From: Daniel Gerzo X-Mailer: The Bat! (v3.99.3) Professional Organization: The FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1855464401.20080225195408@rulez.sk> To: Jeff Roberson In-Reply-To: <20080224223903.Q920@desktop> References: <845250.18624.qm@web63909.mail.re1.yahoo.com> <47BF5702.3020204@FreeBSD.org> <47BF8EB7.9090007@barafranca.com> <47BFB70F.5080402@FreeBSD.org> <20080224124342.E920@desktop> <1172441424.20080225092945@rulez.sk> <20080224223903.Q920@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Daniel Gerzo , freebsd-current@FreeBSD.org, Ivan Voras Subject: Re[3]: cpu usage in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 18:52:13 -0000 Hello Jeff, Monday, February 25, 2008, 9:41:37 AM, you wrote: >> I have a box running mysqld, which sometimes exeeds 130%, what about >> this? ;) >> >> Also the mysqld is alsmost all the time in the "ucond" state, what >> does it mean? I've been told that it is probably waiting for I/O, but >> then, I have another box which is currently completely idle, but >> running mysql shows that it is "ucond" as well. > You should switch top to display threads. 'H' is the key to do it. > Otherwise you only get the wait channel for one of the threads. Others > may be busy doing things. This is correct. > 'ucond' means the thread is waiting on a userland condition variable. > This is a type of synchronization point in userland accessed via the > pthread_cond_*(3) api. It may indicate a thread that is waiting for work > but other threads may be busy. OK, thank you for the explanation. > Do you only have one CPU? If you're seeing 130% on a single cpu system we > may need to take some steps to improve the reporting. No, actually this is AMD Athlon64 X2, so dualcore, so may I assume 130% is OK for dualcore? -- Best regards, Daniel mailto:danger@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 19:03:01 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A0816A401; Mon, 25 Feb 2008 19:03:01 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 496F813C45B; Mon, 25 Feb 2008 19:03:00 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=58040 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTibJ-0002Yn-Pz; Mon, 25 Feb 2008 19:02:57 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1PJ2sWW038525; Mon, 25 Feb 2008 22:02:54 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1PJ2sLE038524; Mon, 25 Feb 2008 22:02:54 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Mon, 25 Feb 2008 22:02:54 +0300 From: Ruslan Ermilov To: obrien@freebsd.org, Dag-Erling Sm??rgrav , Joseph Koshy , current@freebsd.org Message-ID: <20080225190254.GA38367@team.vega.ru> References: <20080224190637.GB18096@team.vega.ru> <20080224193221.GA25526@dragon.NUXI.org> <20080224194358.GC18096@team.vega.ru> <20080224205121.GB27938@dragon.NUXI.org> <20080224212642.GA15362@plan0.kaiwan.csbnet.se> <20080224213434.GA29077@dragon.NUXI.org> <20080225071825.GE18096@team.vega.ru> <20080225083555.GB40376@dragon.NUXI.org> <20080225113950.GF18096@team.vega.ru> <20080225171630.GA80931@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080225171630.GA80931@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 19:03:01 -0000 On Mon, Feb 25, 2008 at 09:16:30AM -0800, David O'Brien wrote: > On Mon, Feb 25, 2008 at 02:39:51PM +0300, Ruslan Ermilov wrote: > > On Mon, Feb 25, 2008 at 12:35:55AM -0800, David O'Brien wrote: > > > > 2) there's no harm in bootstrapping more than necessary. > > > > > > Duplicated effort, and long build world times. > > > > Ahem. It's less than two seconds in wall clock time on a > > modern hardware. :-) > > Unless we build everything as a bootstrap tool (related to Marcel's > comment in this thread). > > Do you have a new diff that doesn't use any of the WITH_* stuff and just > converts to using the new 'ar'? > I think I showed my last patch. I thought we discussed everything, so it's now in CVS. I preserved _WITH_GNUAR, for the purposes of being able to upgrade (read: cross-build for a different arch) on earlier systems where bootstrapping BSD ar(1) is not supported -- it's only set by Makefile.inc1, and is not supposed to be set by a human being. I hope you'll like it. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 19:08:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A67116A402 for ; Mon, 25 Feb 2008 19:08:09 +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 D8F1813C457 for ; Mon, 25 Feb 2008 19:08:08 +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 m1PJ87vY002844 (8.13.4/1.4); Mon, 25 Feb 2008 20:08:07 +0100 (MET) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id m1PJ86fu002841 (8.13.4/2.02); Mon, 25 Feb 2008 20:08:06 +0100 (MET) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Mon, 25 Feb 2008 20:08:06 +0100 (MET) From: Michiel Boland To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: panic upon starting X in recent -CURRENTs (intel 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, 25 Feb 2008 19:08:09 -0000 > Hi. After recent upgrade (from 21 dec to today's src) the kernel crashes when > starting X with > > panic: pmap_remove_all: page 0xc56e07f8 is fictitious For the record, this has now been fixed with rev 1.391 of src/sys/vm/vm_object.c Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 21:19:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 046E916A40D for ; Mon, 25 Feb 2008 21:19:23 +0000 (UTC) (envelope-from brix@FreeBSD.org) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id C132E13C4D5 for ; Mon, 25 Feb 2008 21:19:22 +0000 (UTC) (envelope-from brix@FreeBSD.org) Received: from tirith.brixandersen.dk (0x55534f5f.adsl.cybercity.dk [85.83.79.95]) by solow.pil.dk (Postfix) with ESMTP id 004A31CC0C4 for ; Mon, 25 Feb 2008 22:19:21 +0100 (CET) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id 2018411436; Mon, 25 Feb 2008 22:19:20 +0100 (CET) Date: Mon, 25 Feb 2008 22:19:19 +0100 From: Henrik Brix Andersen To: freebsd-current@freebsd.org Message-ID: <20080225211919.GA71164@tirith.brixandersen.dk> Mail-Followup-To: freebsd-current@freebsd.org References: <681a18e40802111347i3c23c34cve3c1d08b2eaeff0f@mail.gmail.com> <200802131153.04293.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <200802131153.04293.jhb@freebsd.org> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: Small patch to add -a to cp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 21:19:23 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2008 at 11:53:04AM -0500, John Baldwin wrote: > On Monday 11 February 2008 04:47:44 pm David Frascone wrote: > > This small patch adds the -a (archive) flag to cp. Personally, I use c= p -a > > all the time, and I miss it on BSD. This makes cp share the common -a = flag > > with rsync and other file manipulation utilities. > >=20 > > Comments, flames, etc welcome. >=20 > I have this patch from the last time this came up. It maps -a to -RpP ra= ther > than -rpP though. Since -r won't preserve symlinks but copy their conten= ts, I > think -RpP is probably the better default. =2E.. Looks good to me, yes. Does anybody have any objections to this option being added to cp(1) in -current? Brix --=20 Henrik Brix Andersen --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: GnuPG signed iEYEARECAAYFAkfDMNcACgkQv+Q4flTiePitMACfRvoASudXxfWrDOILp7Rt3RUt qSkAn28n28Ey7XF2CcwuWUhzL0zXlGsR =jlk6 -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 22:06:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7D816A40D for ; Mon, 25 Feb 2008 22:06:48 +0000 (UTC) (envelope-from fmarc@enginet.com) Received: from enginet.com (enginet.com [65.102.60.170]) by mx1.freebsd.org (Postfix) with ESMTP id 383FC13C461 for ; Mon, 25 Feb 2008 22:06:48 +0000 (UTC) (envelope-from fmarc@enginet.com) Received: from enginet.com (fmarc@enginet.com) by enginet.com (8.14.2/8.13.8) with ESMTP id m1PM6lsr095153 for ; Mon, 25 Feb 2008 14:06:47 -0800 (PST) Message-Id: <200802252206.m1PM6lsr095153@enginet.com> To: freebsd-current@freebsd.org From: fmarc@enginet.com Date: Mon, 25 Feb 2008 14:06:47 -0800 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (enginet.com [127.0.0.1]); Mon, 25 Feb 2008 14:06:47 -0800 (PST) Subject: Boot hang with 7.0-RC3 on Intel DG965WH, when SATA is 'Native' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 22:06:48 -0000 Team: Congrats on the upcoming FreeBSD 7.0 release. I've been a long-time user of FreeBSD (since 1.0). It's great to see how far FreeBSD has advanced. When I boot FreeBSD 7.0-RC2 and 7.0-RC3 (disc1 or livefs) on my Intel DG965WH motherboard (Core2Duo 2.4GHz, 2GB RAM, SATA disk & cdrom), I see it hang after the probe, apparently when trying to mount the cd. I have booted 6.0-RELEASE, 6.1-RELEASE, 6.2-RELEASE, and 6.3-RELEASE on the same system configured the same way, and this problem does not happen with any 6.x CDs. The end of the probe is roughly: [...] acd0: DVDR at ata4-slave SATA150 ad6: 381554 MB at ata5-master SATA150 SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install. acd0: TIMEOUT - READ_BIG retrying (1 retry left) acd0: TIMEOUT - READ_BIG retrying (0 retries left) acd0: TIMEOUT - READ_BIG timed out [...] and then the last 3 messages repeat themselves for several minutes before I gave up and hit the reset button. I apologize for the sparse probe details -- I had to hand-copy / hand-type the above. If I configure my motherboard BIOS so that SATA is configured as 'Legacy' mode (the only other choice besides 'Native'), then I do not experience the boot hang. The motherboard uses the Intel 965 chip-set, there are 6 total SATA ports. I even tried plugging in my CD/DVD drive into a lower-numbered port, that did not effect the problem. While I know how to work-around the problem, I am posting about this for 2 reasons: 1) Any other users who experience the same boot hang problem can hopefully use this knowledge to work-around the problem. 2) It took me some time to troubleshoot this and figure out how to get past the problem -- I hope this can be fixed before the 7.0 release because it makes 7.0 appear not to work/boot on these motherboards. My work-around is not a good permanent solution because that BIOS setting completely changes the BIOS numbering of all devices, and that causes problems for any other OS's already installed in other partitions. If I may provide any other info or assistance with regards to troubleshooting this, please let me know. -Marc From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 22:43:36 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F188416A401 for ; Mon, 25 Feb 2008 22:43:36 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 76C5A13C4CE for ; Mon, 25 Feb 2008 22:43:36 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 81380557; Mon, 25 Feb 2008 23:38:06 +0200 Message-ID: <47C33539.4080803@FreeBSD.org> Date: Mon, 25 Feb 2008 23:38:01 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Peter Schuller References: <1203974586.00031036.1203962402@10.7.7.3> In-Reply-To: <1203974586.00031036.1203962402@10.7.7.3> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Recommended virtualization technique for debugging/developing FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 22:43:37 -0000 Peter Schuller ïèøåò: > What do all you regular kernel developers use, if not physical hardware? I have successfully used free VMWare Server 1.0.4 for Windows for debugging. It has some timer issues and some hardware configuration cases, but until I have got spare server with serial console it have helped me much. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 23:33:25 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CE0216A401 for ; Mon, 25 Feb 2008 23:33:25 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id D6BEC13C4DB for ; Mon, 25 Feb 2008 23:33:24 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1PNXFp8062975; Mon, 25 Feb 2008 17:33:15 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1PNXFrO062974; Mon, 25 Feb 2008 17:33:15 -0600 (CST) (envelope-from brooks) Date: Mon, 25 Feb 2008 17:33:15 -0600 From: Brooks Davis To: Jeff Roberson Message-ID: <20080225233315.GA59569@lor.one-eyed-alien.net> References: <20080224173229.I920@desktop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20080224173229.I920@desktop> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 25 Feb 2008 17:33:16 -0600 (CST) Cc: current@freebsd.org Subject: Re: cpuset and affinity implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 23:33:25 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 24, 2008 at 05:38:37PM -1000, Jeff Roberson wrote: > Hello, >=20 > I have implemented a new api similar to processors sets on solaris. This= =20 > allows you to assign processes to sets of cpus and dynamically change tho= se=20 > sets. This is useful for provisioning purposes to add and remove cpu=20 > resources for a particular process or group of processes. This new=20 > facility also supports binding secific threads to specific cpus which som= e=20 > applications may want to do. At some point in the future this will be=20 > integrated with jail so you can restrict the cpus any jail is allowed to= =20 > use. >=20 > This api should not be considered final and the 'cpuset' tool is quite=20 > rough. This also only works with ULE and is unfortunately intertwined wi= th=20 > a big ULE patch I've been working on. The set management code is generic= =20 > but 4BSD doesn't contain the hooks to actually constrain threads. I took a look at the patch this morning. The API looks like it's capable of doing what I need, at least at a first pass. It looks like I should be able to implement the semantics currently employed by the Sun Grid Engine scheduler on Irix systems. The one thing I noticed that I found worrying was the recursion in cpuset_(test)update(). It wasn't immediately clear to me there there is anything to would prevent an arbitrarily deep hierarchy from being created and blowing the kernel stack. I'm I missing something? -- Brooks --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHw1A6XY6L6fI4GtQRAt7RAJ9EXhkn7LZ2Lm7hKowce3NqNiv02ACg1aZf Tauye9p9tvkOzlAnM35sk0Y= =wuVu -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 23:37:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D004F16A404 for ; Mon, 25 Feb 2008 23:37:58 +0000 (UTC) (envelope-from mouss@netoyen.net) Received: from balou.adapsec.com (balou.adapsec.com [91.121.103.130]) by mx1.freebsd.org (Postfix) with ESMTP id 9C09B13C45D for ; Mon, 25 Feb 2008 23:37:58 +0000 (UTC) (envelope-from mouss@netoyen.net) Received: from [192.168.1.65] (ouzoud.netoyen.net [82.239.111.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mouss@netoyen.net) by balou.adapsec.com (Postfix) with ESMTPSA id 1DA523ACDC6D for ; Tue, 26 Feb 2008 00:21:43 +0100 (CET) Message-ID: <47C34D7E.1010305@netoyen.net> Date: Tue, 26 Feb 2008 00:21:34 +0100 From: mouss User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ssh_exchange_identification: Connection closed by remote host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Feb 2008 23:37:58 -0000 Hi, I am having an ssh issue to a freebsd 6.2 (error in subject). this happened after a power outage at the client side (client was connected before that), and this is the second time. Ican still connect to netbsd, centos and debian systems from the same client. Is there a problem with the ssh shipped with 6.2? (BTW the system is running pf). if so, what's the recommended way to fix this? any other ideas? From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 00:04:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9056F16A404 for ; Tue, 26 Feb 2008 00:04:08 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from betty.computinginnovations.com (mail.computinginnovations.com [64.81.227.250]) by mx1.freebsd.org (Postfix) with ESMTP id 3045313C465 for ; Tue, 26 Feb 2008 00:04:07 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from p28.computinginnovations.com (dhcp-10-20-30-100.computinginnovations.com [10.20.30.100]) (authenticated bits=0) by betty.computinginnovations.com (8.14.2/8.13.8) with ESMTP id m1Q03vsU053426; Mon, 25 Feb 2008 18:03:58 -0600 (CST) (envelope-from derek@computinginnovations.com) Message-Id: <6.0.0.22.2.20080225180357.025db140@mail.computinginnovations.com> X-Sender: derek@mail.computinginnovations.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 25 Feb 2008 18:05:46 -0600 To: mouss , freebsd-current@freebsd.org From: Derek Ragona In-Reply-To: <47C34D7E.1010305@netoyen.net> References: <47C34D7E.1010305@netoyen.net> Mime-Version: 1.0 X-ComputingInnovations-MailScanner-Information: Please contact the ISP for more information X-ComputingInnovations-MailScanner: Found to be clean X-ComputingInnovations-MailScanner-From: derek@computinginnovations.com X-Spam-Status: No Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: ssh_exchange_identification: Connection closed by remote host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 00:04:08 -0000 At 05:21 PM 2/25/2008, mouss wrote: >Hi, > >I am having an ssh issue to a freebsd 6.2 (error in subject). this >happened after a power outage at the client side (client was connected >before that), and this is the second time. Ican still connect to netbsd, >centos and debian systems from the same client. > >Is there a problem with the ssh shipped with 6.2? (BTW the system is >running pf). if so, what's the recommended way to fix this? any other ideas? > sshd has to be running on the system. Also you may need to delete any cached keys. You don't say in your post what client you are using. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 00:12:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C79C16A405 for ; Tue, 26 Feb 2008 00:12:20 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from outbound.icp-qv1-irony-out4.iinet.net.au (outbound.icp-qv1-irony-out4.iinet.net.au [203.59.1.150]) by mx1.freebsd.org (Postfix) with ESMTP id 8478A13C478 for ; Tue, 26 Feb 2008 00:12:19 +0000 (UTC) (envelope-from lstewart@freebsd.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI/hwkfSVCQt/2dsb2JhbACrfw X-IronPort-AV: E=Sophos;i="4.25,404,1199631600"; d="scan'208";a="185099614" Received: from unknown (HELO newbox.caia.swin.edu.au) ([210.84.36.45]) by outbound.icp-qv1-irony-out4.iinet.net.au with ESMTP; 26 Feb 2008 08:42:48 +0900 Message-ID: <47C35277.7000700@freebsd.org> Date: Tue, 26 Feb 2008 10:42:47 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.4 (X11/20070625) MIME-Version: 1.0 To: Peter Schuller References: <200802251858.05767.peter.schuller@infidyne.com> In-Reply-To: <200802251858.05767.peter.schuller@infidyne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Recommended virtualization technique for debugging/developing FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 00:12:20 -0000 Hi Peter, Peter Schuller wrote: > Hello, > > I was wondering what people use, in the abscense of suitable actual hardware, > to debug/develop FreeBSD (the kernel in particular). I'm willing to resort to > almost any host, including Windows, as long as I have something reliable. > > I haven't had much luck with qemu (crashes), nor virtualbox (crashes). I was > going to go for vmware on Windows, but while it ran FreeBSD pretty well, > before I had even percolated the disk layout enough to trigger the bug > (required root-on-zfs) I was hoping to trigger, the vmware configuration tool > crapped out on me and produced a configuration it could not itself read. > > What do all you regular kernel developers use, if not physical hardware? > Not trying to discount your experiences, but I've had nothing but success using Vmware under linux as a FreeBSD development platform. The vmware tools take some coercing to work on FreeBSD 7/8, but I've done it and they work fine so far. One thing I will note is that Vmware really messes with the kernel's timing and so time dependent behaviour will often manifest itself differently in vmware than on real hardware. Race conditions, locking problems, etc. are all less likely to show up in Vmware than on real hardware in my experience. Definitely not a show stopper, but something to be aware of when using it as a dev platform. I have a step by step build guide which I created when setting up my home vmware dev server which I'd be more than happy to share with you if you're interested. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 00:26:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7AC016A400 for ; Tue, 26 Feb 2008 00:26:58 +0000 (UTC) (envelope-from mouss@netoyen.net) Received: from balou.adapsec.com (balou.adapsec.com [91.121.103.130]) by mx1.freebsd.org (Postfix) with ESMTP id 8F25C13C458 for ; Tue, 26 Feb 2008 00:26:58 +0000 (UTC) (envelope-from mouss@netoyen.net) Received: from [192.168.1.65] (ouzoud.netoyen.net [82.239.111.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mouss@netoyen.net) by balou.adapsec.com (Postfix) with ESMTPSA id 99FBA3ACDC6D; Tue, 26 Feb 2008 01:27:05 +0100 (CET) Message-ID: <47C35CCC.9090300@netoyen.net> Date: Tue, 26 Feb 2008 01:26:52 +0100 From: mouss User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Derek Ragona References: <47C34D7E.1010305@netoyen.net> <6.0.0.22.2.20080225180357.025db140@mail.computinginnovations.com> In-Reply-To: <6.0.0.22.2.20080225180357.025db140@mail.computinginnovations.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ssh_exchange_identification: Connection closed by remote host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 00:26:58 -0000 Derek Ragona wrote: > At 05:21 PM 2/25/2008, mouss wrote: >> Hi, >> >> I am having an ssh issue to a freebsd 6.2 (error in subject). this >> happened after a power outage at the client side (client was >> connected before that), and this is the second time. Ican still >> connect to netbsd, centos and debian systems from the same client. >> >> Is there a problem with the ssh shipped with 6.2? (BTW the system is >> running pf). if so, what's the recommended way to fix this? any other >> ideas? >> > > sshd has to be running on the system. thanks for the quick reply. I guess it is still as it barfs! > Also you may need to delete any cached keys. You don't say in your > post what client you are using. > I tried with secureCRT and with openssh from a netbsd, debian and centos boxes. same error. I googled for the error, and it seems popular! - I don't think it's an /etc/host* issue, as I was connected to the box multiple times (and I tried from multiple IPs). - I tried from a vmware hosts with no keys, just to make sure it's not a key issue. could this be a dns issue? the host is running a "caching" bind. I would prefer not to disable dns lookup, but if this causes trouble... From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 01:02:35 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B4416A401 for ; Tue, 26 Feb 2008 01:02:35 +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 1715A13C44B for ; Tue, 26 Feb 2008 01:02:34 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1Q12SVX092544; Mon, 25 Feb 2008 20:02:33 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Mon, 25 Feb 2008 15:04:06 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Abdullah Ibn Hamad Al-Marri In-Reply-To: <316530.95933.qm@web33708.mail.mud.yahoo.com> Message-ID: <20080225150323.P920@desktop> References: <316530.95933.qm@web33708.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: cpuset and affinity implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 01:02:35 -0000 On Mon, 25 Feb 2008, Abdullah Ibn Hamad Al-Marri wrote: > Jeff this is great! Thanks! > > Would it hit RELENG_7 in the future? It sounds like there is a lot of interest in that. If people feel good about the api being stable then I will merge it. Jeff > > Regards, > -Abdullah Ibn Hamad Al-Marri > Arab Portal > > > ----- Original Message ---- > From: Jeff Roberson > To: current@freebsd.org > Sent: Monday, February 25, 2008 6:38:37 AM > Subject: cpuset and affinity implementation > > > Hello, > > I > have > implemented > a > new > api > similar > to > processors > sets > on > solaris. > This > allows > you > to > assign > processes > to > sets > of > cpus > and > dynamically > change > those > sets. > This > is > useful > for > provisioning > purposes > to > add > and > remove > cpu > resources > for > a > particular > process > or > group > of > processes. > This > new > facility > also > supports > binding > secific > threads > to > specific > cpus > which > some > applications > may > want > to > do. > At > some > point > in > the > future > this > will > be > integrated > with > jail > so > you > can > restrict > the > cpus > any > jail > is > allowed > to > use. > > This > api > should > not > be > considered > final > and > the > 'cpuset' > tool > is > quite > rough. > This > also > only > works > with > ULE > and > is > unfortunately > intertwined > with > a > big > ULE > patch > I've > been > working > on. > The > set > management > code > is > generic > but > 4BSD > doesn't > contain > the > hooks > to > actually > constrain > threads. > > Please > see: > http://people.freebsd.org/~jeff/cpuset.diff > > here's > a > couple > of > neat > things > to > do > with > cpuset: > > cpuset > -l > 0-4 > /bin/sh > > This > creates > a > new > group > with > a > list > (-l) > of > cpus > 0-4 > inclusive > and > runs > sh > in > it. > > cpuset > -g > -p > pid> > > This > will > get > (-g) > the > mask > of > cpus > pid > (-p) > is > allowed > to > run > on. > > cpuset > -l > 0,2 > -p > pid> > > This > will > restrict > sh > to > running > on > cpus > 0, > 2 > while > its > group > is > still > allowed > 0-4. > > cpuset > -l > 0,2 > -c > -p > pid> > > This > will > modify > the > cpuset > (-c) > that > the > sh > belongs > to. > > cpuset > -l > 0-3 > -s > 1 > > This > will > modify > the > set > (-s) > that > all > threads > are > in > by > default > to > contain > the > first > 4 > cpus > leaving > the > rest > idled. > > cpuset > -g > -i > -p > pid> > > This > will > print > the > id > of > the > set > sh > is > in. > > cpuset > -s > id> > -p > > > This > will > move > pid > into > the > specified > set > so > it > may > be > managed > with > other > pids > in > that > set. > > Feedback > is > appreciated. > > Thanks, > Jeff > _______________________________________________ > 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" > > > > > > > > ____________________________________________________________________________________ > Looking for last minute shopping deals? > Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping > _______________________________________________ > 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 Feb 26 01:10:26 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66B9E16A400; Tue, 26 Feb 2008 01:10:26 +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 1549913C44B; Tue, 26 Feb 2008 01:10:26 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1Q1AMdb094101; Mon, 25 Feb 2008 20:10:25 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Mon, 25 Feb 2008 15:12:00 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Brooks Davis In-Reply-To: <20080225233315.GA59569@lor.one-eyed-alien.net> Message-ID: <20080225150551.O920@desktop> References: <20080224173229.I920@desktop> <20080225233315.GA59569@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: cpuset and affinity implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 01:10:26 -0000 On Mon, 25 Feb 2008, Brooks Davis wrote: > On Sun, Feb 24, 2008 at 05:38:37PM -1000, Jeff Roberson wrote: >> Hello, >> >> I have implemented a new api similar to processors sets on solaris. This >> allows you to assign processes to sets of cpus and dynamically change those >> sets. This is useful for provisioning purposes to add and remove cpu >> resources for a particular process or group of processes. This new >> facility also supports binding secific threads to specific cpus which some >> applications may want to do. At some point in the future this will be >> integrated with jail so you can restrict the cpus any jail is allowed to >> use. >> >> This api should not be considered final and the 'cpuset' tool is quite >> rough. This also only works with ULE and is unfortunately intertwined with >> a big ULE patch I've been working on. The set management code is generic >> but 4BSD doesn't contain the hooks to actually constrain threads. > > I took a look at the patch this morning. The API looks like it's > capable of doing what I need, at least at a first pass. It looks like I > should be able to implement the semantics currently employed by the Sun > Grid Engine scheduler on Irix systems. > > The one thing I noticed that I found worrying was the recursion in > cpuset_(test)update(). It wasn't immediately clear to me there there > is anything to would prevent an arbitrarily deep hierarchy from being > created and blowing the kernel stack. I'm I missing something? Yes, presently it can never be more than 3 levels deep. Once we have jails the max would be 6 levels, unless you can make jails within jails. There is presently now way for the user to create a cpuset that is a subset of another set. So the three cpu sets are: 1) Root set - immutable, all cpus, may be root of jail in which case root outside of the jail can change the set. 2) cpuset - the set this process is a member of. 3) mask - the anonymous set that is applied to an individual thread. Did you look at the userland tool at all? I think this needs the most improvement. I basically just made something that would allow me to pass every possible parameter to the api. Not exactly engineered for usability. > > -- Brooks > From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 01:50:35 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F11FB16A401; Tue, 26 Feb 2008 01:50:34 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 833CE13C461; Tue, 26 Feb 2008 01:50:34 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1Q1oPW6063951; Mon, 25 Feb 2008 19:50:25 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1Q1oPSE063950; Mon, 25 Feb 2008 19:50:25 -0600 (CST) (envelope-from brooks) Date: Mon, 25 Feb 2008 19:50:25 -0600 From: Brooks Davis To: Jeff Roberson Message-ID: <20080226015025.GA63847@lor.one-eyed-alien.net> References: <20080224173229.I920@desktop> <20080225233315.GA59569@lor.one-eyed-alien.net> <20080225150551.O920@desktop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <20080225150551.O920@desktop> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 25 Feb 2008 19:50:25 -0600 (CST) Cc: Brooks Davis , current@freebsd.org Subject: Re: cpuset and affinity implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 01:50:35 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 25, 2008 at 03:12:00PM -1000, Jeff Roberson wrote: >=20 > On Mon, 25 Feb 2008, Brooks Davis wrote: >=20 >> On Sun, Feb 24, 2008 at 05:38:37PM -1000, Jeff Roberson wrote: >>> Hello, >>>=20 >>> I have implemented a new api similar to processors sets on solaris. Th= is >>> allows you to assign processes to sets of cpus and dynamically change= =20 >>> those >>> sets. This is useful for provisioning purposes to add and remove cpu >>> resources for a particular process or group of processes. This new >>> facility also supports binding secific threads to specific cpus which= =20 >>> some >>> applications may want to do. At some point in the future this will be >>> integrated with jail so you can restrict the cpus any jail is allowed to >>> use. >>>=20 >>> This api should not be considered final and the 'cpuset' tool is quite >>> rough. This also only works with ULE and is unfortunately intertwined= =20 >>> with >>> a big ULE patch I've been working on. The set management code is gener= ic >>> but 4BSD doesn't contain the hooks to actually constrain threads. >>=20 >> I took a look at the patch this morning. The API looks like it's >> capable of doing what I need, at least at a first pass. It looks like I >> should be able to implement the semantics currently employed by the Sun >> Grid Engine scheduler on Irix systems. >>=20 >> The one thing I noticed that I found worrying was the recursion in >> cpuset_(test)update(). It wasn't immediately clear to me there there >> is anything to would prevent an arbitrarily deep hierarchy from being >> created and blowing the kernel stack. I'm I missing something? >=20 > Yes, presently it can never be more than 3 levels deep. Once we have jai= ls=20 > the max would be 6 levels, unless you can make jails within jails. >=20 > There is presently now way for the user to create a cpuset that is a subs= et=20 > of another set. So the three cpu sets are: >=20 > 1) Root set - immutable, all cpus, may be root of jail in which case roo= t=20 > outside of the jail can change the set. > 2) cpuset - the set this process is a member of. > 3) mask - the anonymous set that is applied to an individual thread. OK. That makes sense. It would be useful from my perspective if creating a root set (or an otherwise inescapable set) was not explicitly tied to jails. I could see doing this either by extending the syscalls or by introducing a more fine grained light weight virtualization as was discussed in Milan. This would probably want to be a privileged operation regardless. > Did you look at the userland tool at all? I think this needs the most=20 > improvement. I basically just made something that would allow me to pass= =20 > every possible parameter to the api. Not exactly engineered for usabilit= y. I glanced at it, but haven't really thought about what should/shouldn't be there much. I'll try to do that in the next day or so. -- Brooks --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHw3BgXY6L6fI4GtQRAok6AKCQclvEFaJKg0kd4t+GSXqnootnBACdH01o AR7AOMrCynBkEviJleiqRlc= =qeHr -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 02:21:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D33C316A401 for ; Tue, 26 Feb 2008 02:21:46 +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 9B34A13C447 for ; Tue, 26 Feb 2008 02:21:46 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1Q2LihK009816 for ; Mon, 25 Feb 2008 21:21:45 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Mon, 25 Feb 2008 16:23:22 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: current@freebsd.org Message-ID: <20080225161855.M920@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Topology aware scheduling algorithm. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 02:21:46 -0000 Also in the cpuset.diff at: http://people.freebsd.org/~jeff/cpuset.diff There is support for cpu topology aware scheduling. This allows the scheduler to know which cores are colocated on packages and what the cache arrangement between them is. We have seen big improvements in some workloads and some reduction in other workloads. However, I believe this should finally close the gap on the few benchmarks where ULE could trail 4BSD. Please prove me wrong if you can so I can continue to make ULE better. Right now the MD code is slightly lagging behind what the scheduler can utilize. If you have an interest in digging through processor documentation to write code to detect more information about the caches please contact me. I'd love some help. This code and the cpusets will likely be committed to 8.0 by the end of the week and then we'll discuss MFCs after some time to settle there. Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 02:41:38 2008 Return-Path: Delivered-To: current@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CCCD16A401 for ; Tue, 26 Feb 2008 02:41:38 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1AF13C448; Tue, 26 Feb 2008 02:41:38 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1Q2fZZs088961; Tue, 26 Feb 2008 02:41:37 GMT (envelope-from davidxu@freebsd.org) Message-ID: <47C37CAC.90806@freebsd.org> Date: Tue, 26 Feb 2008 10:42:52 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Jeff Roberson References: <20080225161855.M920@desktop> In-Reply-To: <20080225161855.M920@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Topology aware scheduling algorithm. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 02:41:38 -0000 Jeff Roberson wrote: > Also in the cpuset.diff at: > > http://people.freebsd.org/~jeff/cpuset.diff > > There is support for cpu topology aware scheduling. This allows the > scheduler to know which cores are colocated on packages and what the > cache arrangement between them is. > > We have seen big improvements in some workloads and some reduction in > other workloads. However, I believe this should finally close the gap > on the few benchmarks where ULE could trail 4BSD. Please prove me wrong > if you can so I can continue to make ULE better. > > Right now the MD code is slightly lagging behind what the scheduler can > utilize. If you have an interest in digging through processor > documentation to write code to detect more information about the caches > please contact me. I'd love some help. > > This code and the cpusets will likely be committed to 8.0 by the end of > the week and then we'll discuss MFCs after some time to settle there. > > Thanks, > Jeff FYI, sometimes ago, I have written some code to collect cpu topology information according to vendor's specifications, it is only for x86. each cpu just calls cpu_topology_update() at startup time, and the information will be collected. http://people.freebsd.org/~davidxu/sched/ note that these code have not been updated for AMD's 4-core package yet, I have not this cpu. Regards, David Xu From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 04:44:44 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAFAE16A401 for ; Tue, 26 Feb 2008 04:44:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id C35F613C4E1 for ; Tue, 26 Feb 2008 04:44:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 25 Feb 2008 20:44:43 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 34924127362; Mon, 25 Feb 2008 20:44:42 -0800 (PST) Message-ID: <47C39948.3080907@elischer.org> Date: Mon, 25 Feb 2008 20:44:56 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: FreeBSD Current , Marko Zec , Marko Zec , Marko Zec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 04:44:44 -0000 At some stage in the next few weeks I will be trying to commit Marco Zec's vimage code to -current. (only 'trying' not for technical reasons, but political). I'm making this announcement because this is sure to be a controversial move. For those of you who do NOT know what it is, please go to the following website: http://imunes.tel.fer.hr/virtnet/ This project has been going for a whle and has been in production in its earlier versions in several places. The current version referred to in the code is implemented in a manner that allows it to be COMPILED OUT. so that those who do not want the risk or teh performance gain/loss (yes it surprisingly seems to actually speed up some things) can compile it out and have a system that for all intents and purposes, is as it is now. what do we gain? Jail on steroids A framework that can be extended to other virtualisation avenues. The ability to have full virtual machines on almost any layout of physical hardware. Why now? The code is in a shape where teh compiled out version of hte system is stable. In the compiled in version, it is functional enough to provide nearly all of what people want. It needs people with other interests to adapt it to their purposes and use it so that it can become a solid product for future releases. Solaris and Linux have seen what BSD can do with jails and have upped the ante. it's time for FreeBSD to tak our jails to teh next logical step. As it will be committed it does have some missing parts to the jigsaw, but it is complete enough that a system compiled in this manner can be fully functional and fully backwards compatible. Basically no userland changes need be made to get the full effect. I expect the usual nay-sayers no matter what is proposed, but I hope we can have a decent discussion about this.. Julian From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 05:03:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B145C16A400 for ; Tue, 26 Feb 2008 05:03:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 744E513C43E for ; Tue, 26 Feb 2008 05:03:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1Q53JS3001397; Tue, 26 Feb 2008 00:03:19 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m1Q53Jm3050738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 00:03:19 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200802260503.m1Q53Jm3050738@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Feb 2008 00:03:29 -0500 To: pyunyh@gmail.com From: Mike Tancsa In-Reply-To: <20080222054356.GE30497@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <20080217112104.X80805@fledge.watson.org> <200802171458.26951.freebsd-current@dino.sk> <200802171517.26965.freebsd-current@dino.sk> <20080218081801.GB14601@cdnetworks.co.kr> <20080222054356.GE30497@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 05:03:20 -0000 At 12:43 AM 2/22/2008, Pyun YongHyeon wrote: > > > > I've put up a new version under the old URL. > > It's not tested in sparc64 but it seems to work on i386. > > Would you give it spin? > > > >Any progress here? Does the updated one works on your box? So far so good on my Soekris hardware. I will try some vlan tests tomorrow. pci0: at device 1.2 (no driver attached) vr0: port 0xe100-0xe1ff mem 0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0 vr0: Quirks: 0x6 vr0: Revision: 0x96 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:00:24:c9:34:88 vr0: [ITHREAD] vr1: port 0xe200-0xe2ff mem 0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0 vr1: Quirks: 0x6 vr1: Revision: 0x96 miibus1: on vr1 ukphy1: PHY 1 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: Ethernet address: 00:00:24:c9:34:89 vr1: [ITHREAD] vr2: port 0xe300-0xe3ff mem 0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0 vr2: Quirks: 0x6 vr2: Revision: 0x96 miibus2: on vr2 ukphy2: PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr2: Ethernet address: 00:00:24:c9:34:8a vr2: [ITHREAD] vr3: port 0xe400-0xe4ff mem 0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0 vr3: Quirks: 0x6 vr3: Revision: 0x96 miibus3: on vr3 ukphy3: PHY 1 on miibus3 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr3: Ethernet address: 00:00:24:c9:34:8b vr3: [ITHREAD] This is 7.0-PRERELEASE #0: Mon Feb 25 11:25:31 EST 2008 ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 05:10:42 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D97516A402 for ; Tue, 26 Feb 2008 05:10:42 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 753E013C465 for ; Tue, 26 Feb 2008 05:10:42 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.204] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id m1Q5AbMa016485; Mon, 25 Feb 2008 21:10:37 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <47C39F4D.2000604@freebsd.org> Date: Mon, 25 Feb 2008 21:10:37 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <47C39948.3080907@elischer.org> In-Reply-To: <47C39948.3080907@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 05:10:42 -0000 Julian Elischer wrote: > At some stage in the next few weeks I will be trying to commit > Marco Zec's vimage code to -current. > > For those of you who do NOT know what it is, please go to > the following website: > > http://imunes.tel.fer.hr/virtnet/ > > This project has been going for a whle and has been in production > in its earlier versions in several places. This sounds fabulous. I've recently noticed that the two features FreeBSD is really recognized for seem to be ZFS and jails. I think ZFS in 7.0 will be a real selling point, and vimage could become just as much of a release-defining feature for 8.0. It also sounds like something that will need a lot of baking-in before it's completely ready, so now is definitely the time to get it into the tree for 8.0. Good luck! Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 05:13:51 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 403CF16A403; Tue, 26 Feb 2008 05:13:51 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id B545713C4E9; Tue, 26 Feb 2008 05:13:50 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1Q5DlS6065648; Mon, 25 Feb 2008 23:13:47 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1Q5Dkf2065647; Mon, 25 Feb 2008 23:13:46 -0600 (CST) (envelope-from brooks) Date: Mon, 25 Feb 2008 23:13:46 -0600 From: Brooks Davis To: Julian Elischer Message-ID: <20080226051346.GA65258@lor.one-eyed-alien.net> References: <47C39948.3080907@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <47C39948.3080907@elischer.org> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 25 Feb 2008 23:13:47 -0600 (CST) Cc: Marko Zec , Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 05:13:51 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: > At some stage in the next few weeks I will be trying to commit > Marco Zec's vimage code to -current. (only 'trying' not > for technical reasons, but political). >=20 > I'm making this announcement because this is sure to be a controversial= =20 > move. >=20 > For those of you who do NOT know what it is, please go to > the following website: >=20 > http://imunes.tel.fer.hr/virtnet/ >=20 > This project has been going for a whle and has been in production > in its earlier versions in several places. >=20 > The current version referred to in the code is implemented in > a manner that allows it to be COMPILED OUT. so that those who > do not want the risk or teh performance gain/loss (yes it > surprisingly seems to actually speed up some things) can > compile it out and have a system that for all intents and > purposes, is as it is now. Is this true to the level of checksums of .o files? > what do we gain? > Jail on steroids > A framework that can be extended to other virtualisation avenues. > The ability to have full virtual machines on almost any layout > of physical hardware. >=20 > Why now? > The code is in a shape where teh compiled out version of hte system is= =20 > stable. In the compiled in version, it is functional > enough to provide nearly all of what people want. It needs people with=20 > other interests to adapt it to their purposes and use it so that it can= =20 > become a solid product for future releases. The website has a snapshot with a date over a month old and many comments about unstable interfaces. I've seen zero reports of substantial testing... > Solaris and Linux have seen what BSD can do with jails and have upped > the ante. it's time for FreeBSD to tak our jails to teh next logical > step. >=20 > As it will be committed it does have some missing parts to the jigsaw, bu= t=20 > it is complete enough that a system compiled in this manner can > be fully functional and fully backwards compatible. >=20 > Basically no userland changes need be made to get the full effect. >=20 > I expect the usual nay-sayers no matter what is proposed, but > I hope we can have a decent discussion about this.. =46rom purely procedural perspective, the "next few weeks" seems rushed and poorly motivated. We're still finding and fixing bugs from the last major round of network changes. We should at least get the first batch of 7.0 errata out the door before making changes that will certain make merging non-trivial network stack changes more difficult. We also need credible, qualitative reports verifying that it works and what it's impacts are. Don't get me wrong. I think this is interesting work and that it could be a major asset to FreeBSD. I also recognize that it should go in in the next 6-9 months (12 at the outside) if it's not going to cause problems with 8.0. I simply don't see any valid motivation for doing it with undue haste. -- Brooks --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHw6AJXY6L6fI4GtQRApBVAKDgQCyz5vq0uIPyPjacn+fmFxhPJACfTxlg 1avYmgR1Qa9CZDDmBopOStg= =4/Kr -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 05:31:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDC3116A406 for ; Tue, 26 Feb 2008 05:31:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outP.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id BF43613C4E3 for ; Tue, 26 Feb 2008 05:31:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 25 Feb 2008 21:31:27 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3C3C812741B; Mon, 25 Feb 2008 21:31:26 -0800 (PST) Message-ID: <47C3A43C.7090308@elischer.org> Date: Mon, 25 Feb 2008 21:31:40 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Brooks Davis References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> In-Reply-To: <20080226051346.GA65258@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 05:31:27 -0000 Brooks Davis wrote: > On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: >> At some stage in the next few weeks I will be trying to commit >> Marco Zec's vimage code to -current. (only 'trying' not >> for technical reasons, but political). >> >> I'm making this announcement because this is sure to be a controversial >> move. >> >> For those of you who do NOT know what it is, please go to >> the following website: >> >> http://imunes.tel.fer.hr/virtnet/ >> >> This project has been going for a whle and has been in production >> in its earlier versions in several places. >> >> The current version referred to in the code is implemented in >> a manner that allows it to be COMPILED OUT. so that those who >> do not want the risk or teh performance gain/loss (yes it >> surprisingly seems to actually speed up some things) can >> compile it out and have a system that for all intents and >> purposes, is as it is now. > > Is this true to the level of checksums of .o files? No. There are some minor reorganisations of where some variables are, and some minor changes but they are pretty easy to confirm as being "functionally equivalent". Macros are used to do a lot but there are some places where it was not possible to hide it behind a macro, so small re-orgs were required.. they really are small in comparison to the whole work though, and as I said. quite "provable". > >> what do we gain? >> Jail on steroids >> A framework that can be extended to other virtualisation avenues. >> The ability to have full virtual machines on almost any layout >> of physical hardware. >> >> Why now? >> The code is in a shape where teh compiled out version of hte system is >> stable. In the compiled in version, it is functional >> enough to provide nearly all of what people want. It needs people with >> other interests to adapt it to their purposes and use it so that it can >> become a solid product for future releases. > > The website has a snapshot with a date over a month old and many > comments about unstable interfaces. I've seen zero reports of > substantial testing... I and others have run it but there are obviously things to still do. there is of course a limited amount of testing that a couple of people can do. having said that I feel comfortable with it now or I wouldn't have sugested this. As I said teh compiled out version is much easier to verify, and this would give a much larger testing population. > >> Solaris and Linux have seen what BSD can do with jails and have upped >> the ante. it's time for FreeBSD to tak our jails to teh next logical >> step. >> >> As it will be committed it does have some missing parts to the jigsaw, but >> it is complete enough that a system compiled in this manner can >> be fully functional and fully backwards compatible. >> >> Basically no userland changes need be made to get the full effect. >> >> I expect the usual nay-sayers no matter what is proposed, but >> I hope we can have a decent discussion about this.. > > From purely procedural perspective, the "next few weeks" seems rushed and > poorly motivated. We're still finding and fixing bugs from the last > major round of network changes. We should at least get the first batch > of 7.0 errata out the door before making changes that will certain make > merging non-trivial network stack changes more difficult. We also need > credible, qualitative reports verifying that it works and what it's > impacts are. I say the next few weeks because we need it to happen NOW and not "just before 8.0" It's been tested and run for over a year. how much more do you want? No-one is talking about puting it in 7.0 yet, but I don't want to make the same mistake we made when we didn't put it in -current when 6.x was done. (slight hyperbole there... :-) > > Don't get me wrong. I think this is interesting work and that it could > be a major asset to FreeBSD. I also recognize that it should go in > in the next 6-9 months (12 at the outside) if it's not going to cause > problems with 8.0. I simply don't see any valid motivation for doing it > with undue haste. This is not haste.. this has been waiting in the wings fo rover a year. I'd like to see it in -current at most 2 months after 7.0 hits the streets. We need to give it soak time and get people up to speed on how to extend it and other virtual facilities, and probably for feedback to resolt in design fixes so that wen 8.0 gets out the door we have something that we can really be proud of. > > -- Brooks From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 05:34:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB66216A409 for ; Tue, 26 Feb 2008 05:34:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id A8E6213C4E5 for ; Tue, 26 Feb 2008 05:34:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so1272462wfa.7 for ; Mon, 25 Feb 2008 21:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=K9pf/sgJDCnDsTb/gXi3iOvaPrJxIhrvFBLnOshO200=; b=acN0jQO34qvEZlw2nHwncULnT+ScfcN70suz5gronCICiyINUE3FD2eN6j6mKz6pMH/nRCJhwegrzKY6lA82TaynSi34B2eec6ilxkYicDnqH2JPYDHT9mdKEwCzKNXIJSDHQhmo/IWxuXjdp+7DJyMz1SCz/IlvPeeYwKRxHm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=xdZEXnOrPlMZdJKCoJCEDmMQ9p+fmIyXCdxm3Bia4dxowcRWjykUW6FluNUn94k7lzGV1iGBm6Z3mOMERo/y42jPkmjXYjKLVS536zhuDOE+xU6KZ+zJOpQH2njatL/gAnvf0A7UUCXRfsphjUNtgQM6/RTKhoZcecTHGS6KJyU= Received: by 10.142.114.15 with SMTP id m15mr3227710wfc.235.1204004070239; Mon, 25 Feb 2008 21:34:30 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 30sm10836051wfd.19.2008.02.25.21.34.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Feb 2008 21:34:29 -0800 (PST) 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 m1Q5YNAp048759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 14:34:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1Q5YNmN048758; Tue, 26 Feb 2008 14:34:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 26 Feb 2008 14:34:23 +0900 From: Pyun YongHyeon To: Mike Tancsa Message-ID: <20080226053423.GB47750@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <20080217112104.X80805@fledge.watson.org> <200802171458.26951.freebsd-current@dino.sk> <200802171517.26965.freebsd-current@dino.sk> <20080218081801.GB14601@cdnetworks.co.kr> <20080222054356.GE30497@cdnetworks.co.kr> <200802260503.m1Q53Jm3050738@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802260503.m1Q53Jm3050738@lava.sentex.ca> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) 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, 26 Feb 2008 05:34:30 -0000 On Tue, Feb 26, 2008 at 12:03:29AM -0500, Mike Tancsa wrote: > At 12:43 AM 2/22/2008, Pyun YongHyeon wrote: > > > > > > I've put up a new version under the old URL. > > > It's not tested in sparc64 but it seems to work on i386. > > > Would you give it spin? > > > > > > >Any progress here? Does the updated one works on your box? > > > So far so good on my Soekris hardware. I will try some vlan tests tomorrow. > > pci0: at device 1.2 (no > driver attached) > vr0: port 0xe100-0xe1ff mem > 0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0 > vr0: Quirks: 0x6 > vr0: Revision: 0x96 > miibus0: on vr0 > ukphy0: PHY 1 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > vr0: Ethernet address: 00:00:24:c9:34:88 > vr0: [ITHREAD] > vr1: port 0xe200-0xe2ff mem > 0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0 > vr1: Quirks: 0x6 > vr1: Revision: 0x96 > miibus1: on vr1 > ukphy1: PHY 1 on miibus1 > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > vr1: Ethernet address: 00:00:24:c9:34:89 > vr1: [ITHREAD] > vr2: port 0xe300-0xe3ff mem > 0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0 > vr2: Quirks: 0x6 > vr2: Revision: 0x96 > miibus2: on vr2 > ukphy2: PHY 1 on miibus2 > ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > vr2: Ethernet address: 00:00:24:c9:34:8a > vr2: [ITHREAD] > vr3: port 0xe400-0xe4ff mem > 0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0 > vr3: Quirks: 0x6 > vr3: Revision: 0x96 > miibus3: on vr3 > ukphy3: PHY 1 on miibus3 > ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > vr3: Ethernet address: 00:00:24:c9:34:8b > vr3: [ITHREAD] > > This is 7.0-PRERELEASE #0: Mon Feb 25 11:25:31 EST 2008 > > ---Mike > Thanks again for your testing! An unresolved issue for Milan Obuch's router board still prevent me from committing the overhauled one. Unfortunately I still have no clue why his hardware does not work even though it has the same hardware revision(0x96). -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 05:53:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 652A816A400; Tue, 26 Feb 2008 05:53:27 +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 2BFC713C469; Tue, 26 Feb 2008 05:53:27 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1Q5rO5w042073; Tue, 26 Feb 2008 00:53:26 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Mon, 25 Feb 2008 19:55:04 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: David Xu In-Reply-To: <47C37CAC.90806@freebsd.org> Message-ID: <20080225195402.M920@desktop> References: <20080225161855.M920@desktop> <47C37CAC.90806@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Topology aware scheduling algorithm. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 05:53:27 -0000 On Tue, 26 Feb 2008, David Xu wrote: > Jeff Roberson wrote: >> Also in the cpuset.diff at: >> >> http://people.freebsd.org/~jeff/cpuset.diff >> >> There is support for cpu topology aware scheduling. This allows the >> scheduler to know which cores are colocated on packages and what the cache >> arrangement between them is. >> >> We have seen big improvements in some workloads and some reduction in other >> workloads. However, I believe this should finally close the gap on the few >> benchmarks where ULE could trail 4BSD. Please prove me wrong if you can so >> I can continue to make ULE better. >> >> Right now the MD code is slightly lagging behind what the scheduler can >> utilize. If you have an interest in digging through processor >> documentation to write code to detect more information about the caches >> please contact me. I'd love some help. >> >> This code and the cpusets will likely be committed to 8.0 by the end of the >> week and then we'll discuss MFCs after some time to settle there. >> >> Thanks, >> Jeff > > FYI, sometimes ago, I have written some code to collect cpu topology > information according to vendor's specifications, it is only for x86. > each cpu just calls cpu_topology_update() at startup time, and the > information will be collected. > > http://people.freebsd.org/~davidxu/sched/ > > note that these code have not been updated for AMD's 4-core > package yet, I have not this cpu. Thanks David, I think our identcpu.c already detects this information. That's what I'm using. Although I assume that all cpus are identical and fall back on a flat topology if this isn't the case. I'd like to start including more cache information though. Jeff > > Regards, > David Xu > > _______________________________________________ > 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 Feb 26 06:52:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D7B716A401 for ; Tue, 26 Feb 2008 06:52:28 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id E5B6113C447 for ; Tue, 26 Feb 2008 06:52:27 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Tue, 26 Feb 2008 07:48:15 +0100 id 0002E00A.47C3B62F.00012D5D From: Milan Obuch To: freebsd-current@freebsd.org Date: Tue, 26 Feb 2008 07:52:01 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C3A43C.7090308@elischer.org> In-Reply-To: <47C3A43C.7090308@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802260752.02448.freebsd-current@dino.sk> Cc: Brooks Davis , FreeBSD Current , Marko Zec , Marko Zec , Marko Zec , Julian Elischer Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 06:52:28 -0000 On Tuesday 26 February 2008, Julian Elischer wrote: > Brooks Davis wrote: > > On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: > >> At some stage in the next few weeks I will be trying to commit > >> Marco Zec's vimage code to -current. (only 'trying' not > >> for technical reasons, but political). > >> I am one giving my full mental support to this one. Current status with only some snapshots available for testing is not good for me. I have a box in production using vimages and this will give me much easier method of testing things than it is now. [ snip ] > >> what do we gain? > >> Jail on steroids > >> A framework that can be extended to other virtualisation avenues. > >> The ability to have full virtual machines on almost any layout > >> of physical hardware. > >> > >> Why now? > >> The code is in a shape where teh compiled out version of hte system is > >> stable. In the compiled in version, it is functional > >> enough to provide nearly all of what people want. It needs people with > >> other interests to adapt it to their purposes and use it so that it can > >> become a solid product for future releases. > > > > The website has a snapshot with a date over a month old and many > > comments about unstable interfaces. I've seen zero reports of > > substantial testing... > > I and others have run it but there are obviously things to still do. > there is of course a limited amount of testing that a couple of people > can do. having said that I feel comfortable with it now or I wouldn't > have sugested this. As I said teh compiled out version is much easier > to verify, and this would give a much larger testing population. > I am running an older snapshot for couple of months now with no problem and only one small issue - some spurious messages in syslog, which does not bother me enough yet to hunt the real reason for it. I did run a similar system based on older 4-X releases patches with great success too, so I am just waiting for this move in order to be able to test better and more what new we can do in this area. [ snip ] > I say the next few weeks because we need it to happen NOW and > not "just before 8.0" It's been tested and run for over a year. > how much more do you want? No-one is talking about puting it in 7.0 > yet, but I don't want to make the same mistake we made when we didn't > put it in -current when 6.x was done. (slight hyperbole there... :-) > I think so too. This is good time for this move, so the whole picture will be clear before 8.0 (and I would like it to be long before 8.0) so the dust will be long ago settled in that timeframe. I will surely try my best with this when available. In my eyes, necessary amount of conservativism in this area is already taken and we should take a move. > > Don't get me wrong. I think this is interesting work and that it could > > be a major asset to FreeBSD. I also recognize that it should go in > > in the next 6-9 months (12 at the outside) if it's not going to cause > > problems with 8.0. I simply don't see any valid motivation for doing it > > with undue haste. > > This is not haste.. this has been waiting in the wings fo rover a > year. I'd like to see it in -current at most 2 months after 7.0 hits > the streets. We need to give it soak time and get people up to speed > on how to extend it and other virtual facilities, and probably > for feedback to resolt in design fixes so that wen 8.0 gets out the > door we have something that we can really be proud of. > For me, even 6-9 weeks is somewhat too long, but acceptable. The goal should be to gain stable state in -current ASAP in the true sense of this abbreviation. And this needs some work, but the gain is tremendous in my eyes. That being said, I can help only with testing and maybe some feature refining if some needs will be, but as I have current usage for this framework and some more in future (maybe, now just as an ideas), I am really interested in this move to happen. -- Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead. From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 07:00:10 2008 Return-Path: Delivered-To: current@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACA1816A404 for ; Tue, 26 Feb 2008 07:00:10 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8976313C45D; Tue, 26 Feb 2008 07:00:10 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1Q706Yj061222; Tue, 26 Feb 2008 07:00:08 GMT (envelope-from davidxu@freebsd.org) Message-ID: <47C3B943.8020407@freebsd.org> Date: Tue, 26 Feb 2008 15:01:23 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Jeff Roberson References: <20080225161855.M920@desktop> <47C37CAC.90806@freebsd.org> <20080225195402.M920@desktop> In-Reply-To: <20080225195402.M920@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Topology aware scheduling algorithm. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 07:00:10 -0000 Jeff Roberson wrote: > I think our identcpu.c already detects this information. That's what > I'm using. Although I assume that all cpus are identical and fall back > on a flat topology if this isn't the case. I'd like to start including > more cache information though. > > Jeff The patch does not assume all cpus are identical, in theory, one can have a machine with one cpu is 4-core and another is 2-core cpu. only one place needs to be fixed in the patch,the global variable cpu_feature, which is easy to fix for the patch. David Xu From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 07:02:33 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C5CC16A400; Tue, 26 Feb 2008 07:02:33 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 3628213C447; Tue, 26 Feb 2008 07:02:32 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Tue, 26 Feb 2008 07:48:15 +0100 id 0002E00A.47C3B62F.00012D5D From: Milan Obuch To: freebsd-current@freebsd.org Date: Tue, 26 Feb 2008 07:52:01 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C3A43C.7090308@elischer.org> In-Reply-To: <47C3A43C.7090308@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802260752.02448.freebsd-current@dino.sk> Cc: Brooks Davis , FreeBSD Current , Marko Zec , Marko Zec , Marko Zec , Julian Elischer Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 07:02:33 -0000 On Tuesday 26 February 2008, Julian Elischer wrote: > Brooks Davis wrote: > > On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: > >> At some stage in the next few weeks I will be trying to commit > >> Marco Zec's vimage code to -current. (only 'trying' not > >> for technical reasons, but political). > >> I am one giving my full mental support to this one. Current status with only some snapshots available for testing is not good for me. I have a box in production using vimages and this will give me much easier method of testing things than it is now. [ snip ] > >> what do we gain? > >> Jail on steroids > >> A framework that can be extended to other virtualisation avenues. > >> The ability to have full virtual machines on almost any layout > >> of physical hardware. > >> > >> Why now? > >> The code is in a shape where teh compiled out version of hte system is > >> stable. In the compiled in version, it is functional > >> enough to provide nearly all of what people want. It needs people with > >> other interests to adapt it to their purposes and use it so that it can > >> become a solid product for future releases. > > > > The website has a snapshot with a date over a month old and many > > comments about unstable interfaces. I've seen zero reports of > > substantial testing... > > I and others have run it but there are obviously things to still do. > there is of course a limited amount of testing that a couple of people > can do. having said that I feel comfortable with it now or I wouldn't > have sugested this. As I said teh compiled out version is much easier > to verify, and this would give a much larger testing population. > I am running an older snapshot for couple of months now with no problem and only one small issue - some spurious messages in syslog, which does not bother me enough yet to hunt the real reason for it. I did run a similar system based on older 4-X releases patches with great success too, so I am just waiting for this move in order to be able to test better and more what new we can do in this area. [ snip ] > I say the next few weeks because we need it to happen NOW and > not "just before 8.0" It's been tested and run for over a year. > how much more do you want? No-one is talking about puting it in 7.0 > yet, but I don't want to make the same mistake we made when we didn't > put it in -current when 6.x was done. (slight hyperbole there... :-) > I think so too. This is good time for this move, so the whole picture will be clear before 8.0 (and I would like it to be long before 8.0) so the dust will be long ago settled in that timeframe. I will surely try my best with this when available. In my eyes, necessary amount of conservativism in this area is already taken and we should take a move. > > Don't get me wrong. I think this is interesting work and that it could > > be a major asset to FreeBSD. I also recognize that it should go in > > in the next 6-9 months (12 at the outside) if it's not going to cause > > problems with 8.0. I simply don't see any valid motivation for doing it > > with undue haste. > > This is not haste.. this has been waiting in the wings fo rover a > year. I'd like to see it in -current at most 2 months after 7.0 hits > the streets. We need to give it soak time and get people up to speed > on how to extend it and other virtual facilities, and probably > for feedback to resolt in design fixes so that wen 8.0 gets out the > door we have something that we can really be proud of. > For me, even 6-9 weeks is somewhat too long, but acceptable. The goal should be to gain stable state in -current ASAP in the true sense of this abbreviation. And this needs some work, but the gain is tremendous in my eyes. That being said, I can help only with testing and maybe some feature refining if some needs will be, but as I have current usage for this framework and some more in future (maybe, now just as an ideas), I am really interested in this move to happen. -- Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead. From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 07:49:24 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C87D16A401; Tue, 26 Feb 2008 07:49:24 +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 62E6713C448; Tue, 26 Feb 2008 07:49:24 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1Q7nM3G050182; Tue, 26 Feb 2008 02:49:23 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Mon, 25 Feb 2008 21:51:01 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: David Xu In-Reply-To: <47C3B943.8020407@freebsd.org> Message-ID: <20080225215035.Q920@desktop> References: <20080225161855.M920@desktop> <47C37CAC.90806@freebsd.org> <20080225195402.M920@desktop> <47C3B943.8020407@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Topology aware scheduling algorithm. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 07:49:24 -0000 On Tue, 26 Feb 2008, David Xu wrote: > Jeff Roberson wrote: > >> I think our identcpu.c already detects this information. That's what I'm >> using. Although I assume that all cpus are identical and fall back on a >> flat topology if this isn't the case. I'd like to start including more >> cache information though. >> >> Jeff > > The patch does not assume all cpus are identical, in theory, one can have a > machine with one cpu is 4-core and another is 2-core cpu. > only one place needs to be fixed in the patch,the global variable > cpu_feature, which is easy to fix for the patch. cpuid_count(4, cache_level, regs); if ((regs[0] & 0x1f) == 0) break; threads_per_cache = ((regs[0] & 0x3ffc000) >> 14) + 1; Does this work on all intel/amd cpus? Thanks, Jeff > > David Xu > > _______________________________________________ > 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 Feb 26 11:47:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698421065755 for ; Tue, 26 Feb 2008 11:47:18 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id B8111143B10 for ; Tue, 26 Feb 2008 11:07:21 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 20076 invoked from network); 26 Feb 2008 11:07:19 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 26 Feb 2008 11:07:19 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id B051C10316; Tue, 26 Feb 2008 11:07:17 +0000 (UTC) Date: Tue, 26 Feb 2008 11:07:17 +0000 From: ttw+bsd@cobbled.net To: mouss Message-ID: <20080226110717.GA26403@holyman.cobbled.net> Mail-Followup-To: mouss , Derek Ragona , freebsd-current@freebsd.org References: <47C34D7E.1010305@netoyen.net> <6.0.0.22.2.20080225180357.025db140@mail.computinginnovations.com> <47C35CCC.9090300@netoyen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C35CCC.9090300@netoyen.net> Cc: freebsd-current@freebsd.org, Derek Ragona Subject: Re: ssh_exchange_identification: Connection closed by remote host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 11:47:21 -0000 On 26.02-01:26, mouss wrote: [ ... ] > >>Is there a problem with the ssh shipped with 6.2? (BTW the system is > >>running pf). if so, what's the recommended way to fix this? any other > >>ideas? no problems with mine but i've seen this error loads. most elusive is usually tcpwrap configuration (/etc/hosts.allow). From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 11:51:23 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E90E2106585E; Tue, 26 Feb 2008 11:51:22 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CC11C13E695; Tue, 26 Feb 2008 09:47:32 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.100] (c-76-21-32-5.hsd1.ca.comcast.net [76.21.32.5]) by elvis.mu.org (Postfix) with ESMTP id 8DE9E1A3C1A; Tue, 26 Feb 2008 01:47:32 -0800 (PST) In-Reply-To: <20080225215035.Q920@desktop> References: <20080225161855.M920@desktop> <47C37CAC.90806@freebsd.org> <20080225195402.M920@desktop> <47C3B943.8020407@freebsd.org> <20080225215035.Q920@desktop> 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: Suleiman Souhlal Date: Tue, 26 Feb 2008 01:47:21 -0800 To: Jeff Roberson X-Mailer: Apple Mail (2.752.3) Cc: David Xu , current@freebsd.org Subject: Re: Topology aware scheduling algorithm. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 11:51:24 -0000 On Feb 25, 2008, at 11:51 PM, Jeff Roberson wrote: > > On Tue, 26 Feb 2008, David Xu wrote: > >> Jeff Roberson wrote: >> >>> I think our identcpu.c already detects this information. That's >>> what I'm using. Although I assume that all cpus are identical >>> and fall back on a flat topology if this isn't the case. I'd >>> like to start including more cache information though. >>> Jeff >> >> The patch does not assume all cpus are identical, in theory, one >> can have a machine with one cpu is 4-core and another is 2-core cpu. >> only one place needs to be fixed in the patch,the global variable >> cpu_feature, which is easy to fix for the patch. > > cpuid_count(4, cache_level, regs); > if ((regs[0] & 0x1f) == 0) > break; > threads_per_cache = ((regs[0] & 0x3ffc000) >> 14) + 1; > > Does this work on all intel/amd cpus? That won't work on AMD, as they don't support cpuid 4, as far as I know. -- Suleiman From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 11:52:12 2008 Return-Path: Delivered-To: current@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F251065BD3 for ; Tue, 26 Feb 2008 11:52:11 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE5B13D893; Tue, 26 Feb 2008 09:00:00 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1Q8xvWU072896; Tue, 26 Feb 2008 08:59:59 GMT (envelope-from davidxu@freebsd.org) Message-ID: <47C3D55A.10905@freebsd.org> Date: Tue, 26 Feb 2008 17:01:14 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Jeff Roberson References: <20080225161855.M920@desktop> <47C37CAC.90806@freebsd.org> <20080225195402.M920@desktop> <47C3B943.8020407@freebsd.org> <20080225215035.Q920@desktop> In-Reply-To: <20080225215035.Q920@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Topology aware scheduling algorithm. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 11:52:13 -0000 Jeff Roberson wrote: > > On Tue, 26 Feb 2008, David Xu wrote: > >> Jeff Roberson wrote: >> >>> I think our identcpu.c already detects this information. That's what >>> I'm using. Although I assume that all cpus are identical and fall >>> back on a flat topology if this isn't the case. I'd like to start >>> including more cache information though. >>> >>> Jeff >> >> The patch does not assume all cpus are identical, in theory, one can >> have a machine with one cpu is 4-core and another is 2-core cpu. >> only one place needs to be fixed in the patch,the global variable >> cpu_feature, which is easy to fix for the patch. > > cpuid_count(4, cache_level, regs); > if ((regs[0] & 0x1f) == 0) > break; > threads_per_cache = ((regs[0] & 0x3ffc000) >> 14) + 1; > > Does this work on all intel/amd cpus? > I can not find similar functions in amd's document. http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf however they seems to have updated the document for their new cpu which sharing L3. The extended function 0x80000006 now reports L3 information in register %edx. They have never shared L2, so you can assume when the %edx is nonzero, it is now a cache-shared cpu, otherwise cpus on same package just use crossbar to communicate with each other, it is still better than old front-bus, scheduler may think about this performance improvement. > Thanks, > Jeff From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 11:52:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2653C1065678 for ; Tue, 26 Feb 2008 11:52:53 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57003.mail.re3.yahoo.com (web57003.mail.re3.yahoo.com [66.196.97.107]) by mx1.freebsd.org (Postfix) with SMTP id E744E13D797 for ; Tue, 26 Feb 2008 09:57:54 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 15444 invoked by uid 60001); 26 Feb 2008 09:57:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MuZIP+T1nr3E1dGHJnzHq2Tqvu+vqbMTFTc50dN+aHZLBa83FnW5Taa8pCanZQV+QhXqc7UweKgyw1fbB0RHsOvIRC69CfChjiSE2ThS5yQEMmRErEjNvcUDRkKFASALJxm+kfhWsT4HMoDll28HAAQ8FCV5lEE+NG2W79zBCnc=; X-YMail-OSG: AEVKWuEVM1nnFXzUwGuUVaXb8eRLwvOjsWdLSBNS8vR3xNV50SnjeKf.d09EbMOc8Q-- Received: from [165.21.155.73] by web57003.mail.re3.yahoo.com via HTTP; Tue, 26 Feb 2008 01:57:53 PST Date: Tue, 26 Feb 2008 01:57:53 -0800 (PST) From: Unga To: freebsd-current@freebsd.org In-Reply-To: <20080220112911.W44565@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <840364.15353.qm@web57003.mail.re3.yahoo.com> Cc: mux@FreeBSD.org, rwatson@FreeBSD.org Subject: Re: Frequent network access freeze (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, 26 Feb 2008 11:52:57 -0000 --- Robert Watson wrote: > > On Wed, 20 Feb 2008, Unga wrote: > > > I'm running 7.0-PRERELEASE (RC2, dated > 15/02/2008), compiled from sources on > > i386 machine (512MB RAM, 3.0GHz, tx0: EtherPower II 10/100>). > > > > Network access freezes very frequently. Cannot > ping to any ip address. The > > only way to get networking working again is > reboot. > > > > I'm having this problem on 7.0 ever since I tried > it from BETA4. I have > > reported also to this list before but sadly nobody > was interested on it. > > > > If somebody is interested to look into this > problem, I could furnish with > > more detail and participate in testing. > > This sort of problem frequently turns out to be a > bug in a device driver or a > problem with interrupt probing/configuration, so my > first guess would be a > problem with the if_tx driver. The usual starting > diagnostics when ping fails > are to try to use tcpdump to determine whether it's > receive or transmit > failing (or both). Quiet the network between two > endpoints as much as you can > so you can avoid noise from making the dumps more > complex, and dump arp and > icmp at both endpoints. Now try to ping from each > end point to the other. > One potential source of confusion is that ping > requires ARP to work, and ARP > can be a slightly confusing protocol as it usually > resolves actively (query, > response) but sometimes it receives passive updates > or extends existing > entries. > > What you want to look for is a packet sent by one > side that isn't received by > the other. You might find, for example, that your > host receives packets fine, > but the packets it transmits are never received. > This would be indicative of a > driver bug in which it fails to properly handle (for > example) transmit queues > filling, and might only trigger under very high > load. Or, you might find that > your host never receives anything the other side > transmits, but can send fine. > This might be indicative of a driver bug involving > the receive code, or a > problem with how interrupts are being handled more > generally. > > It looks like the last non-routine maintenance to > the driver was done by > Maxime in about 2003; the more recent changes have > all been updates to > newbus/busdma infrastructure, ifnet changes, locking > changes, etc. I've CC'd > him as it sounds like he may have hardware... My > advice would be to do the > above tests and see if you can narrow down whether > it's transmit, receive, or > both failing. > Here are the detail when net access is working and when not working: When net access working ----------------------- $ ifconfig tx0: flags=108843 metric 0 mtu 1500 options=8 ether 00:e1:20:34:bb:36 inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (10baseT/UTP) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 1090 tx0 localhost localhost UH 0 186 lo0 192.168.1.0 link#1 UC 0 0 tx0 192.168.1.1 00:91:d2:4c:54:f8 UHLW 2 0 tx0 892 Internet6: Destination Gateway Flags Netif Expire localhost localhost UHL lo0 fe80::%lo0 fe80::1%lo0 U lo0 fe80::1%lo0 link#3 UHL lo0 ff01:3:: fe80::1%lo0 UC lo0 ff02::%lo0 fe80::1%lo0 UC lo0 When net access NOT working --------------------------- $ ifconfig tx0: flags=108843 metric 0 mtu 1500 options=8 ether 00:e1:20:34:bb:36 inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (10baseT/UTP) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 3338 tx0 localhost localhost UH 0 204 lo0 192.168.1.0 link#1 UC 0 0 tx0 192.168.1.1 00:91:d2:4c:54:f8 UHLW 2 28 tx0 997 192.168.1.2 link#1 UHLW 1 1 tx0 Internet6: Destination Gateway Flags Netif Expire localhost localhost UHL lo0 fe80::%lo0 fe80::1%lo0 U lo0 fe80::1%lo0 link#3 UHL lo0 ff01:3:: fe80::1%lo0 UC lo0 ff02::%lo0 fe80::1%lo0 UC lo0 tcpdump -i tx0 -v NOTE: When ping to 192.168.1.1, no tcpdump output. ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes ^C --- 192.168.1.1 ping statistics --- 58 packets transmitted, 0 packets received, 100.0% packet loss /var/log/messages: Feb 26 15:26:14 blacktower kernel: tx0: ERROR! Can't stop Rx DMA Feb 26 15:26:14 blacktower kernel: tx0: promiscuous mode enabled Note: These two messages keep on repeat on /var/log/messages. /var/log/messages at the time of send this email: Feb 26 17:32:17 blacktower kernel: tx0: link state changed to DOWN Feb 26 17:36:25 blacktower kernel: tx0: link state changed to UP Feb 26 17:36:30 blacktower kernel: tx0: link state changed to DOWN Feb 26 17:37:07 blacktower kernel: tx0: link state changed to UP Feb 26 17:37:14 blacktower kernel: tx0: link state changed to DOWN Feb 26 17:37:22 blacktower kernel: tx0: link state changed to UP When reboot, net access start working again. Please let me know what other information is required. Kind regards Unga ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 11:55:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 152F31065F34 for ; Tue, 26 Feb 2008 11:55:14 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57010.mail.re3.yahoo.com (web57010.mail.re3.yahoo.com [66.196.97.114]) by mx1.freebsd.org (Postfix) with SMTP id 90AA914093E for ; Tue, 26 Feb 2008 10:06:55 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 37959 invoked by uid 60001); 26 Feb 2008 10:06:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=AtVB0RvDDEEDAn5gEuJXm4Aq/jOYNu1wi3VvcOdqYbPiCAnuq/M7nr+m20aH0804DbNhd6gPYEe5mkKYkBHvgQ/d3O+HDdYcsLG0szsNdI83Fkt1JTmGYvZ9CtCxSEgnA7spVDFpG0PjB3eI0xDkKIpFWbc8oQiJjms4ZZs3Ytg=; X-YMail-OSG: Dl.ILTsVM1m.zbUl8Kk6hbDo1ICqf2QrUH.5emqwuYFJguJsdShXc1TuGwJzEgTVOxAY5kD7obcax6JJSRO4UFB_fwrf_6aXaAeBMKx_EoUCrT8UXyc- Received: from [165.21.155.74] by web57010.mail.re3.yahoo.com via HTTP; Tue, 26 Feb 2008 02:06:54 PST Date: Tue, 26 Feb 2008 02:06:54 -0800 (PST) From: Unga To: freebsd-current@freebsd.org In-Reply-To: <20080220112911.W44565@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <770498.37662.qm@web57010.mail.re3.yahoo.com> Cc: mux@FreeBSD.org, rwatson@FreeBSD.org Subject: Re: Frequent network access freeze (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, 26 Feb 2008 11:55:17 -0000 --- Robert Watson wrote: > > On Wed, 20 Feb 2008, Unga wrote: > > > I'm running 7.0-PRERELEASE (RC2, dated > 15/02/2008), compiled from sources on > > i386 machine (512MB RAM, 3.0GHz, tx0: EtherPower II 10/100>). > > > > Network access freezes very frequently. Cannot > ping to any ip address. The > > only way to get networking working again is > reboot. > > > > I'm having this problem on 7.0 ever since I tried > it from BETA4. I have > > reported also to this list before but sadly nobody > was interested on it. > > > > If somebody is interested to look into this > problem, I could furnish with > > more detail and participate in testing. > > This sort of problem frequently turns out to be a > bug in a device driver or a > problem with interrupt probing/configuration, so my > first guess would be a > problem with the if_tx driver. The usual starting > diagnostics when ping fails > are to try to use tcpdump to determine whether it's > receive or transmit > failing (or both). Quiet the network between two > endpoints as much as you can > so you can avoid noise from making the dumps more > complex, and dump arp and > icmp at both endpoints. Now try to ping from each > end point to the other. > One potential source of confusion is that ping > requires ARP to work, and ARP > can be a slightly confusing protocol as it usually > resolves actively (query, > response) but sometimes it receives passive updates > or extends existing > entries. > > What you want to look for is a packet sent by one > side that isn't received by > the other. You might find, for example, that your > host receives packets fine, > but the packets it transmits are never received. > This would be indicative of a > driver bug in which it fails to properly handle (for > example) transmit queues > filling, and might only trigger under very high > load. Or, you might find that > your host never receives anything the other side > transmits, but can send fine. > This might be indicative of a driver bug involving > the receive code, or a > problem with how interrupts are being handled more > generally. > > It looks like the last non-routine maintenance to > the driver was done by > Maxime in about 2003; the more recent changes have > all been updates to > newbus/busdma infrastructure, ifnet changes, locking > changes, etc. I've CC'd > him as it sounds like he may have hardware... My > advice would be to do the > above tests and see if you can narrow down whether > it's transmit, receive, or > both failing. > Here are the detail when net access is working and when not working: When net access working ----------------------- $ ifconfig tx0: flags=108843 metric 0 mtu 1500 options=8 ether 00:e1:20:34:bb:36 inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (10baseT/UTP) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 1090 tx0 localhost localhost UH 0 186 lo0 192.168.1.0 link#1 UC 0 0 tx0 192.168.1.1 00:91:d2:4c:54:f8 UHLW 2 0 tx0 892 Internet6: Destination Gateway Flags Netif Expire localhost localhost UHL lo0 fe80::%lo0 fe80::1%lo0 U lo0 fe80::1%lo0 link#3 UHL lo0 ff01:3:: fe80::1%lo0 UC lo0 ff02::%lo0 fe80::1%lo0 UC lo0 When net access NOT working --------------------------- $ ifconfig tx0: flags=108843 metric 0 mtu 1500 options=8 ether 00:e1:20:34:bb:36 inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (10baseT/UTP) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 3338 tx0 localhost localhost UH 0 204 lo0 192.168.1.0 link#1 UC 0 0 tx0 192.168.1.1 00:91:d2:4c:54:f8 UHLW 2 28 tx0 997 192.168.1.2 link#1 UHLW 1 1 tx0 Internet6: Destination Gateway Flags Netif Expire localhost localhost UHL lo0 fe80::%lo0 fe80::1%lo0 U lo0 fe80::1%lo0 link#3 UHL lo0 ff01:3:: fe80::1%lo0 UC lo0 ff02::%lo0 fe80::1%lo0 UC lo0 tcpdump -i tx0 -v NOTE: When ping to 192.168.1.1, no tcpdump output. ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes ^C --- 192.168.1.1 ping statistics --- 58 packets transmitted, 0 packets received, 100.0% packet loss /var/log/messages: Feb 26 15:26:14 blacktower kernel: tx0: ERROR! Can't stop Rx DMA Feb 26 15:26:14 blacktower kernel: tx0: promiscuous mode enabled Note: These two messages keep on repeat on /var/log/messages. /var/log/messages at the time of send this email: Feb 26 17:32:17 blacktower kernel: tx0: link state changed to DOWN Feb 26 17:36:25 blacktower kernel: tx0: link state changed to UP Feb 26 17:36:30 blacktower kernel: tx0: link state changed to DOWN Feb 26 17:37:07 blacktower kernel: tx0: link state changed to UP Feb 26 17:37:14 blacktower kernel: tx0: link state changed to DOWN Feb 26 17:37:22 blacktower kernel: tx0: link state changed to UP Note: This link state UP/DOWN behaviour noted only now and does not show in my logs. When reboot, net access start working again. Please let me know what other information is required. Kind regards Unga ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 12:18:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5D4106566C for ; Tue, 26 Feb 2008 12:18:38 +0000 (UTC) (envelope-from mouss@netoyen.net) Received: from balou.adapsec.com (balou.adapsec.com [91.121.103.130]) by mx1.freebsd.org (Postfix) with ESMTP id D176713C4F2 for ; Tue, 26 Feb 2008 12:18:37 +0000 (UTC) (envelope-from mouss@netoyen.net) Received: from [192.168.1.65] (ouzoud.netoyen.net [82.239.111.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mouss@netoyen.net) by balou.adapsec.com (Postfix) with ESMTPSA id B9E4A3ACD828; Tue, 26 Feb 2008 13:18:35 +0100 (CET) Message-ID: <47C4039A.3060907@netoyen.net> Date: Tue, 26 Feb 2008 13:18:34 +0100 From: mouss User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Juraj Lutter References: <47C34D7E.1010305@netoyen.net> <6.0.0.22.2.20080225180357.025db140@mail.computinginnovations.com> <47C35CCC.9090300@netoyen.net> <47C3DDCF.6070109@gmail.com> In-Reply-To: <47C3DDCF.6070109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Derek Ragona Subject: Re: ssh_exchange_identification: Connection closed by remote host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 12:18:38 -0000 Juraj Lutter wrote: > mouss wrote: >> >> I tried with secureCRT and with openssh from a netbsd, debian and >> centos boxes. same error. >> I googled for the error, and it seems popular! >> - I don't think it's an /etc/host* issue, as I was connected to the >> box multiple times (and I tried from multiple IPs). >> - I tried from a vmware hosts with no keys, just to make sure it's >> not a key issue. >> >> could this be a dns issue? the host is running a "caching" bind. I >> would prefer not to disable dns lookup, but if this causes trouble... > > > This seems to be more a /etc/hosts.allow issue. > I found the problem: fatal: /var/empty must be owned by root and not group or world-writable. I have created an account and set the home to /var/empty, but this changed the owner of /var/empty. sigh. I should have found http://www.darkknight.demon.co.uk/prdb/unix/ssh.html sooner ;-p thanks to all who responded. From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 11:33:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7016B1065871 for ; Tue, 26 Feb 2008 11:33:09 +0000 (UTC) (envelope-from wilbuy@gmail.com) Received: from mailhub.ltc.sk (mailhub.ltc.sk [81.89.56.20]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8E413F506 for ; Tue, 26 Feb 2008 09:37:17 +0000 (UTC) (envelope-from wilbuy@gmail.com) Received: from [127.0.0.1] (remedy.wilbury.sk [217.73.27.10]) by mailhub.ltc.sk (Postfix) with ESMTP id 6C4CD173600; Tue, 26 Feb 2008 10:37:16 +0100 (CET) Message-ID: <47C3DDCF.6070109@gmail.com> Date: Tue, 26 Feb 2008 10:37:19 +0100 From: Juraj Lutter User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: mouss References: <47C34D7E.1010305@netoyen.net> <6.0.0.22.2.20080225180357.025db140@mail.computinginnovations.com> <47C35CCC.9090300@netoyen.net> In-Reply-To: <47C35CCC.9090300@netoyen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 26 Feb 2008 12:32:19 +0000 Cc: freebsd-current@freebsd.org, Derek Ragona Subject: Re: ssh_exchange_identification: Connection closed by remote host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 11:33:11 -0000 mouss wrote: > > I tried with secureCRT and with openssh from a netbsd, debian and > centos boxes. same error. > I googled for the error, and it seems popular! > - I don't think it's an /etc/host* issue, as I was connected to the > box multiple times (and I tried from multiple IPs). > - I tried from a vmware hosts with no keys, just to make sure it's not > a key issue. > > could this be a dns issue? the host is running a "caching" bind. I > would prefer not to disable dns lookup, but if this causes trouble... This seems to be more a /etc/hosts.allow issue. From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 12:53:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 619A1106566B for ; Tue, 26 Feb 2008 12:53:51 +0000 (UTC) (envelope-from hosting@hosting.lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 336E313C4D1 for ; Tue, 26 Feb 2008 12:53:51 +0000 (UTC) (envelope-from hosting@hosting.lissyara.su) Received: from hosting by hosting.lissyara.su with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JTyvP-000JYh-DT; Tue, 26 Feb 2008 15:28:47 +0300 To: Unga X-PHP-Script: hosting.lissyara.su/roundcube/index.php for 213.234.218.67 MIME-Version: 1.0 Date: Tue, 26 Feb 2008 15:28:47 +0300 From: In-Reply-To: <840364.15353.qm@web57003.mail.re3.yahoo.com> References: <840364.15353.qm@web57003.mail.re3.yahoo.com> Message-ID: <318482e6609d6237ee011cc60e1f57c1@lissyara.su> X-Sender: admin@lissyara.su Received: from lina.fors.com [213.234.218.67] with HTTP/1.0 (POST); Tue, 26 Feb 2008 15:28:47 +0300 User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: Hosting User X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current@freebsd.org Subject: Re: Frequent network access freeze (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, 26 Feb 2008 12:53:51 -0000 On Tue, 26 Feb 2008 01:57:53 -0800 (PST), Unga wrote: > --- Robert Watson wrote: > >> >> On Wed, 20 Feb 2008, Unga wrote: >> >> > I'm running 7.0-PRERELEASE (RC2, dated >> 15/02/2008), compiled from sources on >> > i386 machine (512MB RAM, 3.0GHz, tx0: > EtherPower II 10/100>). >> > >> > Network access freezes very frequently. Cannot >> ping to any ip address. The >> > only way to get networking working again is >> reboot. >> > >> > I'm having this problem on 7.0 ever since I tried >> it from BETA4. I have >> > reported also to this list before but sadly nobody >> was interested on it. >> > >> > If somebody is interested to look into this >> problem, I could furnish with >> > more detail and participate in testing. >> >> This sort of problem frequently turns out to be a >> bug in a device driver or a >> problem with interrupt probing/configuration, so my >> first guess would be a >> problem with the if_tx driver. The usual starting >> diagnostics when ping fails >> are to try to use tcpdump to determine whether it's >> receive or transmit >> failing (or both). Quiet the network between two >> endpoints as much as you can >> so you can avoid noise from making the dumps more >> complex, and dump arp and >> icmp at both endpoints. Now try to ping from each >> end point to the other. >> One potential source of confusion is that ping >> requires ARP to work, and ARP >> can be a slightly confusing protocol as it usually >> resolves actively (query, >> response) but sometimes it receives passive updates >> or extends existing >> entries. >> >> What you want to look for is a packet sent by one >> side that isn't received by >> the other. You might find, for example, that your >> host receives packets fine, >> but the packets it transmits are never received. >> This would be indicative of a >> driver bug in which it fails to properly handle (for >> example) transmit queues >> filling, and might only trigger under very high >> load. Or, you might find that >> your host never receives anything the other side >> transmits, but can send fine. >> This might be indicative of a driver bug involving >> the receive code, or a >> problem with how interrupts are being handled more >> generally. >> >> It looks like the last non-routine maintenance to >> the driver was done by >> Maxime in about 2003; the more recent changes have >> all been updates to >> newbus/busdma infrastructure, ifnet changes, locking >> changes, etc. I've CC'd >> him as it sounds like he may have hardware... My >> advice would be to do the >> above tests and see if you can narrow down whether >> it's transmit, receive, or >> both failing. >> > I have some problem with 7-rc2 interface - rl0, some time it work correct - (5 hour (minimum) - 3 day (maximum)), then, short period (30-50 min.) packet loss up from 0% to 25%. up/down, network restart - cannot help. Only reboot... more than 25% - i not see. It up to 25% and freese on this number. ======== 2 day ago i change interface to fxp0... i stay - today - 3 day from change.... From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 16:53:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA0621065675 for ; Tue, 26 Feb 2008 16:53:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id D654B13C4EE for ; Tue, 26 Feb 2008 16:53:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 26 Feb 2008 08:53:38 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C3D12127354 for ; Tue, 26 Feb 2008 08:53:37 -0800 (PST) Message-ID: <47C44420.6050009@elischer.org> Date: Tue, 26 Feb 2008 08:53:52 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: why vimage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 16:53:39 -0000 some people have asked me why I would want vimage.. The answer is because it allows you to do lots of things easily that are hard to do normally. I can give a very simple example of something you can do trivially on vimage: Make three virtual machines on yhour laptop: The base machine and two others. Have the first 'other' machine be assigned an IP address on your HOME LAN. have the second virtual machine have an IP adddress on your WORK LAN. use the base machine to run encrypted tunnels from where-ever you happen to be to your work and home.. when you put the laptop to sleep (assuming the tcp sessions are quiescent (no keepalives)) then when you wake it up say an hour later.. as soon as the base machine has an IP address.. viola, your session on the virtual machines are still alive. there are SO MANY things you can do with this.. and the framework allows us to proceed with more virtualisation including separate PID spaces or processor quotas etc. BUT the framework will never get the mindshare needed unless people start playing with it. From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 17:23:33 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ED7F10656C8 for ; Tue, 26 Feb 2008 17:23:33 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from svr03-temp.btshosting.co.uk (svr03-temp.btshosting.co.uk [87.117.208.48]) by mx1.freebsd.org (Postfix) with ESMTP id E5DA513C478 for ; Tue, 26 Feb 2008 17:23:32 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from [192.168.1.65] (host86-139-98-128.range86-139.btcentralplus.com [86.139.98.128]) (authenticated bits=0) by svr03-temp.btshosting.co.uk (8.14.1/8.14.1) with ESMTP id m1QH8Db8006408; Tue, 26 Feb 2008 17:08:14 GMT (envelope-from bazerka@beardz.net) Message-ID: <47C44777.6060404@beardz.net> Date: Tue, 26 Feb 2008 17:08:07 +0000 From: Jase Thew User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julian Elischer References: <47C44420.6050009@elischer.org> In-Reply-To: <47C44420.6050009@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on 87.117.208.49 X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: why vimage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bazerka@beardz.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, 26 Feb 2008 17:23:33 -0000 Julian Elischer wrote: > some people have asked me why I would want vimage.. > The answer is because it allows you to do lots of things easily > that are hard to do normally. > > I can give a very simple example of something you can do trivially on > vimage: > > Make three virtual machines on yhour laptop: > The base machine and two others. > Have the first 'other' machine be assigned an IP address on > your HOME LAN. > have the second virtual machine have an IP adddress on > your WORK LAN. > use the base machine to run encrypted tunnels from where-ever > you happen to be to your work and home.. when you put the laptop to > sleep (assuming the tcp sessions are quiescent (no keepalives)) > then when you wake it up say an hour later.. as soon as the base > machine has an IP address.. viola, your session on the virtual > machines are still alive. > > there are SO MANY things you can do with this.. and the framework > allows us to proceed with more virtualisation including > separate PID spaces or processor quotas etc. > > BUT the framework will never get the mindshare needed unless people > start playing with it. > vimage will be a boon for replacing full system jails. I think the more important question is: why people *wouldn't* want vimage incorporated into the tree? The benefits it offers are pretty vast and from what I can see, there are hardly any disadvantages ( although I'm willing to be enlightened if there are any major gotchas ). Jase. From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 18:25:30 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 500311065673 for ; Tue, 26 Feb 2008 18:25:30 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63911.mail.re1.yahoo.com (web63911.mail.re1.yahoo.com [69.147.97.126]) by mx1.freebsd.org (Postfix) with SMTP id F188213C457 for ; Tue, 26 Feb 2008 18:25:29 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 85367 invoked by uid 60001); 26 Feb 2008 18:25:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6PHSlkfKhcCMA2xtBvE7CiS1RN+VYdXZVJdCVAggbsHuZbIxSYjhGZPbI9nhJa/HUY9LFJYKKse4netgOfroIA3qET0/Jh/P5TEIXDRm+tIEeTlllXTWExeaeB645yYZw2gtc3upEKxeoxsmGAstirPBwJSa9JiOP/3rpj17RVw=; X-YMail-OSG: 972DLdkVM1kaFey3XbwIA_JIqVxsxPCXy_7TC_4NYL40pdI1GdivnG7JtMhRCDN7O5vwCurVTJv.IwjqyMpFamuJTMkoeG6tUFQ8QZCZORwGCrp6BsU- Received: from [98.203.28.38] by web63911.mail.re1.yahoo.com via HTTP; Tue, 26 Feb 2008 10:25:28 PST Date: Tue, 26 Feb 2008 10:25:28 -0800 (PST) From: Barney Cordoba To: current@freebsd.org In-Reply-To: <20080224223903.Q920@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <119186.84635.qm@web63911.mail.re1.yahoo.com> Cc: Subject: Re: Re[2]: cpu usage 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, 26 Feb 2008 18:25:30 -0000 --- Jeff Roberson wrote: > On Mon, 25 Feb 2008, Daniel Gerzo wrote: > > > Hello Jeff, > > > > Sunday, February 24, 2008, 11:47:39 PM, you wrote: > > > >>> So how does a multithreaded process get 458% CPU > on a quad-core machine? :) > >>> (Really, I want to know; I thought thread CPU > accounting was fixed in 7.x. > >>> Unless I'm mistaken, 4 CPU-intensive threads in > a single process should > >>> account as 4 CPU-intensive single-thread > processes; i.e. each could only take > >>> up to 100% of a core/CPU, accounting for > NCPU*100% total). > >>> > >>> > > > >> It is possible for the sum of all threads in the > system to exceed 100% > >> cpu. This is because the decay function is not > precise. 15% over is a > >> bit more than I would expect but I suppose it's > possible. We also inhert > >> pcpu information from the parent on fork/thread > creation so the child > >> isn't created with a priority as if it had been > idle. So for a moment the > >> utilization is duplicated. > > > > I have a box running mysqld, which sometimes > exeeds 130%, what about > > this? ;) > > > > Also the mysqld is alsmost all the time in the > "ucond" state, what > > does it mean? I've been told that it is probably > waiting for I/O, but > > then, I have another box which is currently > completely idle, but > > running mysql shows that it is "ucond" as well. > > You should switch top to display threads. 'H' is > the key to do it. > Otherwise you only get the wait channel for one of > the threads. Others > may be busy doing things. > > 'ucond' means the thread is waiting on a userland > condition variable. > This is a type of synchronization point in userland > accessed via the > pthread_cond_*(3) api. It may indicate a thread > that is waiting for work > but other threads may be busy. > > Do you only have one CPU? If you're seeing 130% on > a single cpu system we > may need to take some steps to improve the > reporting. > > > > > > -- > > Best regards, > > Daniel > mailto:danger@FreeBSD.org I'd like to note that I find it confusing and inconsistent to have Top average the cpu usage as the main usage figure, but use a different formula for the processes themselves. Barney ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 18:39:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 743601065672 for ; Tue, 26 Feb 2008 18:39:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outM.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 45D0913C4D5 for ; Tue, 26 Feb 2008 18:39:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 26 Feb 2008 10:39:46 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 44A1212734C; Tue, 26 Feb 2008 10:39:44 -0800 (PST) Message-ID: <47C45CFE.9030006@elischer.org> Date: Tue, 26 Feb 2008 10:39:58 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Andre Oppermann References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> In-Reply-To: <47C458E9.5090400@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , Brooks Davis , Marko Zec , FreeBSD Current , Marko Zec Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 18:39:47 -0000 Andre Oppermann wrote: > Brooks Davis wrote: >> On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: >> >>> At some stage in the next few weeks I will be trying to commit >>> Marco Zec's vimage code to -current. (only 'trying' not >>> for technical reasons, but political). > ... >>> Why now? >>> The code is in a shape where teh compiled out version of hte system >>> is stable. In the compiled in version, it is functional >>> enough to provide nearly all of what people want. It needs people >>> with other interests to adapt it to their purposes and use it so that >>> it can become a solid product for future releases. >> >> The website has a snapshot with a date over a month old and many >> comments about unstable interfaces. I've seen zero reports of >> substantial testing... > > What about locking and SMP scalability? Any new choke points? not that I've seen. > > Having a patch set to glance over would be helpful as well. It's all in p4 //depot/projects/vimage/src > >>> Solaris and Linux have seen what BSD can do with jails and have upped >>> the ante. it's time for FreeBSD to tak our jails to teh next logical >>> step. >>> >>> As it will be committed it does have some missing parts to the >>> jigsaw, but it is complete enough that a system compiled in this >>> manner can >>> be fully functional and fully backwards compatible. >>> >>> Basically no userland changes need be made to get the full effect. >>> >>> I expect the usual nay-sayers no matter what is proposed, but >>> I hope we can have a decent discussion about this.. >> >> From purely procedural perspective, the "next few weeks" seems rushed and >> poorly motivated. We're still finding and fixing bugs from the last >> major round of network changes. We should at least get the first batch >> of 7.0 errata out the door before making changes that will certain make >> merging non-trivial network stack changes more difficult. We also need >> credible, qualitative reports verifying that it works and what it's >> impacts are. > > Seconded. Waiting until 7.0 has left the barn and got some exposure would > be preferrable. > >> Don't get me wrong. I think this is interesting work and that it could >> be a major asset to FreeBSD. I also recognize that it should go in >> in the next 6-9 months (12 at the outside) if it's not going to cause >> problems with 8.0. I simply don't see any valid motivation for doing it >> with undue haste. > > We also need detailed briefing on how to work with virtualization. What > have we to be careful about? How are kld's and network drivers affected? > New network related kernel structures? And so on. Make sure you read the paper(s) too.. There is some documentation required on "how to do it", especially with the new macros. How and when to use them, and how a kernel module needs to be made aware of the framwork. I think Marco told me once that he was going to do such documentation, so your reminder will probably produce some sort of "developer's notes" I hope. I'm sure that when it gets into the system a lot of people will want to play with it. I have only virtualised one module (divert sockets) and I still have a question about one thing so I understand the need for notes on how to develope for vimage. > From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 18:46:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B6A61065670 for ; Tue, 26 Feb 2008 18:46:11 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from mail.potentialtech.com (internet.potentialtech.com [66.167.251.6]) by mx1.freebsd.org (Postfix) with ESMTP id E947113C45D for ; Tue, 26 Feb 2008 18:46:10 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.potentialtech.com (Postfix) with ESMTP id 4F3F6EBC08; Tue, 26 Feb 2008 13:30:08 -0500 (EST) Date: Tue, 26 Feb 2008 13:30:07 -0500 From: Bill Moran To: Peter Schuller Message-Id: <20080226133007.87340fd2.wmoran@potentialtech.com> In-Reply-To: <200802251858.05767.peter.schuller@infidyne.com> References: <200802251858.05767.peter.schuller@infidyne.com> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.8; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Recommended virtualization technique for debugging/developing FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 18:46:11 -0000 In response to Peter Schuller : > Hello, > > I was wondering what people use, in the abscense of suitable actual hardware, > to debug/develop FreeBSD (the kernel in particular). I'm willing to resort to > almost any host, including Windows, as long as I have something reliable. > > I haven't had much luck with qemu (crashes), nor virtualbox (crashes). I was > going to go for vmware on Windows, but while it ran FreeBSD pretty well, > before I had even percolated the disk layout enough to trigger the bug > (required root-on-zfs) I was hoping to trigger, the vmware configuration tool > crapped out on me and produced a configuration it could not itself read. > > What do all you regular kernel developers use, if not physical hardware? I know that bochs was used during some of the initial development of the amd64 port, because bochs can emulate amd64 on i386 hardware. You're not going to see anything like impressive performance with bochs, but it will allow you to see _everything_ the kernel is doing, i.e., you can track each CPU instruction if you so desire. -- Bill Moran http://www.potentialtech.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 18:49:15 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 497D6106566B for ; Tue, 26 Feb 2008 18:49:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A33C813C45B for ; Tue, 26 Feb 2008 18:49:13 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 62994 invoked from network); 26 Feb 2008 17:37:36 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Feb 2008 17:37:36 -0000 Message-ID: <47C458E9.5090400@freebsd.org> Date: Tue, 26 Feb 2008 19:22:33 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Brooks Davis References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> In-Reply-To: <20080226051346.GA65258@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , Marko Zec , Marko Zec , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 18:49:15 -0000 Brooks Davis wrote: > On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: > >>At some stage in the next few weeks I will be trying to commit >>Marco Zec's vimage code to -current. (only 'trying' not >>for technical reasons, but political). ... >>Why now? >> The code is in a shape where teh compiled out version of hte system is >>stable. In the compiled in version, it is functional >>enough to provide nearly all of what people want. It needs people with >>other interests to adapt it to their purposes and use it so that it can >>become a solid product for future releases. > > The website has a snapshot with a date over a month old and many > comments about unstable interfaces. I've seen zero reports of > substantial testing... What about locking and SMP scalability? Any new choke points? Having a patch set to glance over would be helpful as well. >>Solaris and Linux have seen what BSD can do with jails and have upped >>the ante. it's time for FreeBSD to tak our jails to teh next logical >>step. >> >>As it will be committed it does have some missing parts to the jigsaw, but >>it is complete enough that a system compiled in this manner can >>be fully functional and fully backwards compatible. >> >>Basically no userland changes need be made to get the full effect. >> >>I expect the usual nay-sayers no matter what is proposed, but >>I hope we can have a decent discussion about this.. > > From purely procedural perspective, the "next few weeks" seems rushed and > poorly motivated. We're still finding and fixing bugs from the last > major round of network changes. We should at least get the first batch > of 7.0 errata out the door before making changes that will certain make > merging non-trivial network stack changes more difficult. We also need > credible, qualitative reports verifying that it works and what it's > impacts are. Seconded. Waiting until 7.0 has left the barn and got some exposure would be preferrable. > Don't get me wrong. I think this is interesting work and that it could > be a major asset to FreeBSD. I also recognize that it should go in > in the next 6-9 months (12 at the outside) if it's not going to cause > problems with 8.0. I simply don't see any valid motivation for doing it > with undue haste. We also need detailed briefing on how to work with virtualization. What have we to be careful about? How are kld's and network drivers affected? New network related kernel structures? And so on. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 19:00:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 466431065671 for ; Tue, 26 Feb 2008 19:00:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id C013413C448 for ; Tue, 26 Feb 2008 19:00:10 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1QJ03CI000437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 06:00:04 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1QJ03jm073857; Wed, 27 Feb 2008 06:00:03 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1QJ02Eh073856; Wed, 27 Feb 2008 06:00:02 +1100 (EST) (envelope-from peter) Date: Wed, 27 Feb 2008 06:00:02 +1100 From: Peter Jeremy To: Julian Elischer Message-ID: <20080226190002.GT83599@server.vk2pj.dyndns.org> References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C3A43C.7090308@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5oH/S/bF6lOfqCQb" Content-Disposition: inline In-Reply-To: <47C3A43C.7090308@elischer.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Marko Zec , Brooks Davis , Marko Zec , FreeBSD Current , Marko Zec Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 19:00:11 -0000 --5oH/S/bF6lOfqCQb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Overall, vimage sounds very useful. Are there changes to public kernel interfaces? (ie could it potentially be MFCd) On Mon, Feb 25, 2008 at 09:31:40PM -0800, Julian Elischer wrote: >>> The current version referred to in the code is implemented in >>> a manner that allows it to be COMPILED OUT. Since even things like INET and INET6 are "compiled in" rather than "compiled out" on request, why is vimage defaulting to "compiled in" by default? >No. There are some minor reorganisations of where some variables are, and= =20 >some minor changes but they are pretty easy to confirm as being=20 >"functionally equivalent". Macros are used to do a lot but there are some= =20 >places where it was not possible to hide it behind a macro, so small=20 >re-orgs were required.. they really are small in comparison to >the whole work though, and as I said. quite "provable". How much will impact on the ease with which networking stack changes can be MFCd back to 7.x? >I say the next few weeks because we need it to happen NOW and >not "just before 8.0" Agreed but I can understand Brook's reluctance to have yet another roto-tilling of the network stack whilst there still appear to be a few issues remaining from the last roto-tilling. IMHO, it would be reasonable to get input from re@ as to whether they would like the stack left alone for a while to simplify the resolution of any issues that may crop up once 7.0 is released. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --5oH/S/bF6lOfqCQb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHxGGy/opHv/APuIcRAiuoAJ0Z6oSV0x3OtFKyg/E0prd0OPHHdQCfb4n9 lR4OIMCip4GDxccG9hxZoWQ= =drMP -----END PGP SIGNATURE----- --5oH/S/bF6lOfqCQb-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 19:13:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D6FB1065672 for ; Tue, 26 Feb 2008 19:13:56 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id 4BF7813C455 for ; Tue, 26 Feb 2008 19:13:56 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-a916e555.03-51-73746f3.cust.bredbandsbolaget.se (c-a916e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.169]) by smtp.infidyne.com (Postfix) with ESMTP id D580D37C36; Tue, 26 Feb 2008 20:13:54 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Tue, 26 Feb 2008 20:15:12 +0100 User-Agent: KMail/1.9.7 References: <47C44420.6050009@elischer.org> In-Reply-To: <47C44420.6050009@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1454992.IdXg8izbK8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802262015.19683.peter.schuller@infidyne.com> Cc: Julian Elischer Subject: Re: why vimage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 19:13:56 -0000 --nextPart1454992.IdXg8izbK8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > some people have asked me why I would want vimage.. > The answer is because it allows you to do lots of things easily > that are hard to do normally. I find it strange that people would ask this. To me, this is the type of=20 killer feature that I want to see in my favorite operating system, from a=20 user/syadmin perspective. There are several reasons why jails are preferabl= e=20 to xen/vmware/etc. There are also several reasons why they are not. This=20 project eliminates a good chunk of those latter reasons. ipv6 support is long-awaited for me personally. The ability to provide more= =20 complete VPS functionality (including firewall rules) is most definitely=20 desired. Arbitrary setups like the one you descripted are also useful (I ha= ve=20 an actual use-case for this at home where I have not yet bothered connectin= g=20 some equipment due to the complexity of doing it - vimage would help a lot). I cannot comment on the commit policies or internal technical reasons for n= ot=20 including it yet, but you definitely have my "I want it" vote from the=20 user/sysadmin perspective. =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart1454992.IdXg8izbK8 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) iD8DBQBHxGVHDNor2+l1i30RAlLcAKDu/fE8KMSb/V5JmZFhfkTGPQ3CFQCfZoz3 mKXCorZDTxtAMrx6YkvjNzo= =FkO2 -----END PGP SIGNATURE----- --nextPart1454992.IdXg8izbK8-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 19:29:52 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0804E1065681; Tue, 26 Feb 2008 19:29:52 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1F68713C4E5; Tue, 26 Feb 2008 19:29:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C468AE.7060603@FreeBSD.org> Date: Tue, 26 Feb 2008 20:29:50 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Julian Elischer References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> <47C45CFE.9030006@elischer.org> In-Reply-To: <47C45CFE.9030006@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , Andre Oppermann , FreeBSD Current , Marko Zec , Marko Zec , Marko Zec Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 19:29:52 -0000 Julian Elischer wrote: > Andre Oppermann wrote: >> Brooks Davis wrote: >>> On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: >>> >>>> At some stage in the next few weeks I will be trying to commit >>>> Marco Zec's vimage code to -current. (only 'trying' not >>>> for technical reasons, but political). >> ... >>>> Why now? >>>> The code is in a shape where teh compiled out version of hte system >>>> is stable. In the compiled in version, it is functional >>>> enough to provide nearly all of what people want. It needs people >>>> with other interests to adapt it to their purposes and use it so >>>> that it can become a solid product for future releases. >>> >>> The website has a snapshot with a date over a month old and many >>> comments about unstable interfaces. I've seen zero reports of >>> substantial testing... >> >> What about locking and SMP scalability? Any new choke points? > > not that I've seen. That's a less than resounding endorsement :) Kris From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 22:35:05 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C6521065672 for ; Tue, 26 Feb 2008 22:35:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outP.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6D313C469 for ; Tue, 26 Feb 2008 22:35:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 26 Feb 2008 14:35:04 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id E8377127366; Tue, 26 Feb 2008 14:35:03 -0800 (PST) Message-ID: <47C49426.7090104@elischer.org> Date: Tue, 26 Feb 2008 14:35:18 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Peter Jeremy References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C3A43C.7090308@elischer.org> <20080226190002.GT83599@server.vk2pj.dyndns.org> In-Reply-To: <20080226190002.GT83599@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , Brooks Davis , Marko Zec , FreeBSD Current , Marko Zec Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 22:35:05 -0000 Peter Jeremy wrote: > Overall, vimage sounds very useful. Are there changes to public > kernel interfaces? (ie could it potentially be MFCd) potentially it could.. in the "compiled out" mode (i.e. you decide to not compile vimage in your kernel) the public kernel interfaces are unchanged. At least that is the aim. > > On Mon, Feb 25, 2008 at 09:31:40PM -0800, Julian Elischer wrote: >>>> The current version referred to in the code is implemented in >>>> a manner that allows it to be COMPILED OUT. > > Since even things like INET and INET6 are "compiled in" rather than > "compiled out" on request, why is vimage defaulting to "compiled in" > by default? eh? After importing, it would be compiled out by default. as in, you'd only get it if you ask for it.. > >> No. There are some minor reorganisations of where some variables are, and >> some minor changes but they are pretty easy to confirm as being >> "functionally equivalent". Macros are used to do a lot but there are some >> places where it was not possible to hide it behind a macro, so small >> re-orgs were required.. they really are small in comparison to >> the whole work though, and as I said. quite "provable". > > How much will impact on the ease with which networking stack changes > can be MFCd back to 7.x? minimal change.. In the worst case we could define the vimage macros in 7.0 and make then do the right thing. (if you needed no diffs at all). > >> I say the next few weeks because we need it to happen NOW and >> not "just before 8.0" > > Agreed but I can understand Brook's reluctance to have yet another > roto-tilling of the network stack whilst there still appear to be > a few issues remaining from the last roto-tilling. IMHO, it would > be reasonable to get input from re@ as to whether they would like > the stack left alone for a while to simplify the resolution of any > issues that may crop up once 7.0 is released. I agree that we need to wait for 7.0 but 7 and 8 are already diverging, and the whole point of the 7 branch is to isolate 7 from -current. > From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 22:37:28 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D4E7106567F for ; Tue, 26 Feb 2008 22:37:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outS.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA8313C469 for ; Tue, 26 Feb 2008 22:37:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 26 Feb 2008 14:37:27 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id ADA2F127353; Tue, 26 Feb 2008 14:37:26 -0800 (PST) Message-ID: <47C494B5.2040306@elischer.org> Date: Tue, 26 Feb 2008 14:37:41 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kris Kennaway References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> <47C45CFE.9030006@elischer.org> <47C468AE.7060603@FreeBSD.org> In-Reply-To: <47C468AE.7060603@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , Andre Oppermann , FreeBSD Current , Marko Zec , Marko Zec , Marko Zec Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 22:37:28 -0000 Kris Kennaway wrote: > Julian Elischer wrote: >> Andre Oppermann wrote: >>> Brooks Davis wrote: >>>> On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: >>>> >>>>> At some stage in the next few weeks I will be trying to commit >>>>> Marco Zec's vimage code to -current. (only 'trying' not >>>>> for technical reasons, but political). >>> ... >>>>> Why now? >>>>> The code is in a shape where teh compiled out version of hte >>>>> system is stable. In the compiled in version, it is functional >>>>> enough to provide nearly all of what people want. It needs people >>>>> with other interests to adapt it to their purposes and use it so >>>>> that it can become a solid product for future releases. >>>> >>>> The website has a snapshot with a date over a month old and many >>>> comments about unstable interfaces. I've seen zero reports of >>>> substantial testing... >>> >>> What about locking and SMP scalability? Any new choke points? >> >> not that I've seen. > > That's a less than resounding endorsement :) do the 10Gb ethernet adapters have any major problems? are you willing to answer "no"? should we then rip them from the tree? I'm saying "this is work in progress" It seems stable and useful. until we can get more than 6 people running it we won't know more. > > Kris > _______________________________________________ > 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 Feb 26 23:02:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FEC5106567F for ; Tue, 26 Feb 2008 23:02:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id CD67613C500 for ; Tue, 26 Feb 2008 23:02:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2710410waf.3 for ; Tue, 26 Feb 2008 15:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=7o9DawIei0EgPWaxX25eESI0Vmsk+s+UzYYGv7dzDjU=; b=PriaS+oiyUppOqPliQI9yzk9OOXty9+I2GFpfPN6kT5hnK4ttWpmGqzNtZRK+0cPYXh28KL/7d8gCegMSYVDSiJ2zuE7rRuYh9q/kLUgAQYY4bXaIJl3h++gtGIE+mFMYLGtWrX901O/IBErhpWJ9YqJNl8B1KttOx40NEtNDl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wnfnKbZ/vGhuLMIOMucCHHxiLH4W3AX6juGJsjOtHE/IGY4T5F1ORwBJcfKgTc68EmKsJEMQudgGKoX95WN+SaqL4opSF/D/YM+4/uQblOXhyuGl9cNwkYNeS6yZw4qmdSyr97W4uZ4CbrQ2mdbAFKD7BYZYIQz/wfeO30Sxd5M= Received: by 10.115.90.1 with SMTP id s1mr6303878wal.50.1204066966347; Tue, 26 Feb 2008 15:02:46 -0800 (PST) Received: by 10.114.255.16 with HTTP; Tue, 26 Feb 2008 15:02:46 -0800 (PST) Message-ID: Date: Tue, 26 Feb 2008 15:02:46 -0800 From: "Kip Macy" To: "Julian Elischer" In-Reply-To: <47C494B5.2040306@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> <47C45CFE.9030006@elischer.org> <47C468AE.7060603@FreeBSD.org> <47C494B5.2040306@elischer.org> Cc: Brooks Davis , Andre Oppermann , FreeBSD Current , Marko Zec , Marko Zec , Marko Zec Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 23:02:47 -0000 On Tue, Feb 26, 2008 at 2:37 PM, Julian Elischer wrote: > Kris Kennaway wrote: > > Julian Elischer wrote: > >> Andre Oppermann wrote: > >>> Brooks Davis wrote: > >>>> On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: > >>>> > >>>>> At some stage in the next few weeks I will be trying to commit > >>>>> Marco Zec's vimage code to -current. (only 'trying' not > >>>>> for technical reasons, but political). > >>> ... > >>>>> Why now? > >>>>> The code is in a shape where teh compiled out version of hte > >>>>> system is stable. In the compiled in version, it is functional > >>>>> enough to provide nearly all of what people want. It needs people > >>>>> with other interests to adapt it to their purposes and use it so > >>>>> that it can become a solid product for future releases. > >>>> > >>>> The website has a snapshot with a date over a month old and many > >>>> comments about unstable interfaces. I've seen zero reports of > >>>> substantial testing... > >>> > >>> What about locking and SMP scalability? Any new choke points? > >> > >> not that I've seen. > > > > That's a less than resounding endorsement :) > > do the 10Gb ethernet adapters have any major problems? > are you willing to answer "no"? > should we then rip them from the tree? > > I'm saying "this is work in progress" It seems stable and useful. > until we can get more than 6 people running it we won't know more. > Given how long it has been since RELENG_7 branched - if its really a no-op when disabled, I personally don't see it any issues with it. -Kip From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 23:24:28 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09DD41065672; Tue, 26 Feb 2008 23:24:28 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1AF13C458; Tue, 26 Feb 2008 23:24:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C49FAA.1020605@FreeBSD.org> Date: Wed, 27 Feb 2008 00:24:26 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Julian Elischer References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> <47C45CFE.9030006@elischer.org> <47C468AE.7060603@FreeBSD.org> <47C494B5.2040306@elischer.org> In-Reply-To: <47C494B5.2040306@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , Andre Oppermann , FreeBSD Current , Marko Zec , Marko Zec , Marko Zec Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 23:24:28 -0000 Julian Elischer wrote: > Kris Kennaway wrote: >> Julian Elischer wrote: >>> Andre Oppermann wrote: >>>> Brooks Davis wrote: >>>>> On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: >>>>> >>>>>> At some stage in the next few weeks I will be trying to commit >>>>>> Marco Zec's vimage code to -current. (only 'trying' not >>>>>> for technical reasons, but political). >>>> ... >>>>>> Why now? >>>>>> The code is in a shape where teh compiled out version of hte >>>>>> system is stable. In the compiled in version, it is functional >>>>>> enough to provide nearly all of what people want. It needs people >>>>>> with other interests to adapt it to their purposes and use it so >>>>>> that it can become a solid product for future releases. >>>>> >>>>> The website has a snapshot with a date over a month old and many >>>>> comments about unstable interfaces. I've seen zero reports of >>>>> substantial testing... >>>> >>>> What about locking and SMP scalability? Any new choke points? >>> >>> not that I've seen. >> >> That's a less than resounding endorsement :) > > do the 10Gb ethernet adapters have any major problems? > are you willing to answer "no"? > should we then rip them from the tree? Those are small, isolated components, so hardly the same thing as a major architectural change that touches every part of the protocol stack. But if someone came along and said "I am going to replace the 10ge drivers, but I dunno how well they perform" I'd say precisely the same thing. Presumably someone (if not you, then Marko) has enough of a grasp of the architectural changes being proposed to comment about what changes (if any) were made to synchronisation models, and whether there are new sources of performance overhead introduced. That person can answer Andre's question. Kris From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 23:46:10 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88284106568A; Tue, 26 Feb 2008 23:46:10 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 3470013C51E; Tue, 26 Feb 2008 23:46:09 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.3] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m1QNk1MP069570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 15:46:02 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <47C4A446.1000701@FreeBSD.org> Date: Tue, 26 Feb 2008 15:44:06 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kris Kennaway References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> <47C45CFE.9030006@elischer.org> <47C468AE.7060603@FreeBSD.org> <47C494B5.2040306@elischer.org> <47C49FAA.1020605@FreeBSD.org> In-Reply-To: <47C49FAA.1020605@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , Andre Oppermann , FreeBSD Current , Marko Zec , Marko Zec , Marko Zec , Julian Elischer Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Feb 2008 23:46:10 -0000 Kris Kennaway wrote: >> do the 10Gb ethernet adapters have any major problems? >> are you willing to answer "no"? >> should we then rip them from the tree? > > Those are small, isolated components, so hardly the same thing as a > major architectural change that touches every part of the protocol stack. > > But if someone came along and said "I am going to replace the 10ge > drivers, but I dunno how well they perform" I'd say precisely the same > thing. > > Presumably someone (if not you, then Marko) has enough of a grasp of the > architectural changes being proposed to comment about what changes (if > any) were made to synchronisation models, and whether there are new > sources of performance overhead introduced. > > That person can answer Andre's question. Another interesting issue is whether or not we are going to have a developer on board committed to investigating and fixing any issues that unavoidably will pop up after initial import. Marko seems to be the ideal person for this, is anybody considering sponsoring him for a commit bit? -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 00:02:37 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0DA01065674; Wed, 27 Feb 2008 00:02:37 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id F2A6C13C461; Wed, 27 Feb 2008 00:02:36 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [192.168.1.101] (cpe-74-77-179-53.buffalo.res.rr.com [74.77.179.53]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id m1QNYPgo036181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 18:34:34 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Julian Elischer In-Reply-To: <47C49426.7090104@elischer.org> References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C3A43C.7090308@elischer.org> <20080226190002.GT83599@server.vk2pj.dyndns.org> <47C49426.7090104@elischer.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EVuFCXxNPfrqNHlfh5my" Date: Tue, 26 Feb 2008 18:33:57 -0500 Message-Id: <1204068837.73925.10.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1335; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=0.6 required=5.0 tests=RCVD_IN_PBL,RDNS_DYNAMIC autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: Marko Zec , Brooks Davis , FreeBSD Current , Peter Jeremy , Marko Zec , Marko Zec Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 00:02:38 -0000 --=-EVuFCXxNPfrqNHlfh5my Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-02-26 at 14:35 -0800, Julian Elischer wrote: > Peter Jeremy wrote: > > IMHO, it would > > be reasonable to get input from re@ as to whether they would like > > the stack left alone for a while to simplify the resolution of any > > issues that may crop up once 7.0 is released. >=20 > I agree that we need to wait for 7.0 but 7 and 8 are already=20 > diverging, and the whole point of the 7 branch is to isolate 7 from=20 > -current. =46rom the re@ point of view I'd like to see this go in about a month from now. You are exactly right that it would be good to get it in early on in what becomes the 8.0 release cycle. But it's in Perforce so it's visible to interested parties who want to look it over and have a chance to kibitz before it gets into CVS, and now that you've given the heads-up (thanks!!!!) people who think they might have a stake in this know to go do that. I know the 7.0 release cycle dragged on way way too long (and I've apologized for that as much as I can...) but there is a period of time after the release that we appreciate people not doing stuff that's too drastic to ease any potential "emergency work" needed as people start using the release. That's the point of the week grace period after the release that re@ holds on to ownership of the branch before turning it over to sec-team@. And we know for a fact we've got some stuff already surfacing that's likely to need Errata Notices. You've pointed out 7 and 8 are already diverging and given how long the release cycle took I can't get too mad at people who have already made significant changes but I'd still prefer it if they hadn't happened quite yet. If you think the month thing is too long I really can't stop you, but this summarizes the feelings as re@... It's a balance between not disturbing things too much in case "stuff comes up" related to 7.0 and getting some major and promising work into the tree early in the release cycle for 8.0. Hopefully having it in Perforce between now and then doesn't cause too much inconvenience. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-EVuFCXxNPfrqNHlfh5my Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkfEod4ACgkQ/G14VSmup/YDWACeLJ8DrxWqYXPKunmRxkpJbH+S DMgAmQG9eZFv+CCPN2TM1DBuQFTSrSfr =fJzz -----END PGP SIGNATURE----- --=-EVuFCXxNPfrqNHlfh5my-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 01:44:52 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C0D106566C for ; Wed, 27 Feb 2008 01:44:52 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id B8A7913C461 for ; Wed, 27 Feb 2008 01:44:51 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id C4297388C41 for ; Wed, 27 Feb 2008 02:09:45 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3AF29380048 for ; Tue, 26 Feb 2008 23:57:05 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 270159BF12 for ; Tue, 26 Feb 2008 22:56:52 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 1A738405B; Tue, 26 Feb 2008 23:56:52 +0100 (CET) Date: Tue, 26 Feb 2008 23:56:52 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20080226225652.GE56090@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Subject: Wireless adapter associated, rx ok, tx ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 01:44:52 -0000 Hi list, I'm running -CURRENT from 2007/02/22. I'm currently on holidays. There is a wireless network protected with WEP. I can successfully associate to the AP, but dhclient(8) won't succeed in getting an IP address. I also tried to configure an IP address manually and ping another computer on the network without success. Nonetheless, I can see the traffic from other computers with tcpdump(8). This behaviour occurs with if_ral and if_wi. I tried with a Linux live CD (from which I'm writing this e-mail), and it works. Please feel free to ask for more informations, I will try to send them back ASAP. Any help will be welcome. Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 01:41:23 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D831106566C; Wed, 27 Feb 2008 01:41:23 +0000 (UTC) (envelope-from bms@icir.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3A99113C478; Wed, 27 Feb 2008 01:41:23 +0000 (UTC) (envelope-from bms@icir.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 421A7A1CE6; Tue, 26 Feb 2008 20:23:37 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 26 Feb 2008 20:23:37 -0500 X-Sasl-enc: q2fqJ46SXrBocLgAt+bdGafQdc0yfgdf3S39zjFjbhBV 1204075416 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 ESMTPSA id BC9A023455; Tue, 26 Feb 2008 20:23:35 -0500 (EST) Message-ID: <47C4BB96.80804@icir.org> Date: Wed, 27 Feb 2008 01:23:34 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: Julian Elischer References: <47C39948.3080907@elischer.org> In-Reply-To: <47C39948.3080907@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 27 Feb 2008 02:15:50 +0000 Cc: Marko Zec , Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 01:41:23 -0000 Julian Elischer wrote: > > what do we gain? > Jail on steroids > A framework that can be extended to other virtualisation avenues. > The ability to have full virtual machines on almost any layout > of physical hardware. I'm confused by the above statements. Also somewhat bemused by them, given that our track record for regression testing and documentation ain't always that great either -- and when bold new ideas are proposed, due diligence often saves the day. * Do you mean to say that IMUNES/vimage has expanded beyond merely wrapping the network stack and virtualizing that? If this is the case (it introduces some new virtualization technique on par with the functionality of e.g. Xen) then I outright DISAGREE with its introduction into the source tree on the grounds that it's too experimental. * Also, do the changes which you intend to introduce, allow for code which is currently under development, and which is not aware of vimage/IMUNES in any way, to continue to compile and be usable without additional developer time? I am continually sidetracked from FreeBSD infrastructural work because it just doesn't pay the bills. As a result I have to defer work for up to a year at a time. If there were community funding available this would help, but as it is, I have to keep the plates spinning somehow. I usually try to keep my p4 development branches merged and in sync at a minimum, so I can always diff against HEAD. [Julian, you're not about to give people a real headache with this, are you?] * If the objective of the exercise is to expose people to vimage, would it not be wiser to implement vimage as a fork in a more accessible repository format than Perforce? e.g. Mercurial or Git? I am opposed to trial-by-fire. I am just as frustrated with the lack of progress which is visible to people on the outside of the development cabal as anybody else (just try to get people to test code in Perforce when they aren't committers, and you'll see EXACTLY what I mean), but I really don't like the idea of experimental work going into CVS. Whilst CVS is a proven tool, its use in the project, to my mind, seems more geared to delivering production code and tracking changes in production branches, rather than managing fast-moving new development. * Does the vimage code have a full set of regression tests which prove that its introduction does not cause the system to behave in an unexpected way? These are very real concerns and they do need to be addressed, otherwise I speculate this is going to be messy, and I don't want to see a repeat of FreeBSD 5.x. Don't get me wrong, there is excellent reasoning and art behind the work in vimage, but the very real economic difficulties involved in its integration just cannot be ignored as they affect everyone involved with the project. best regards, BMS From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 02:26:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE8A81065672 for ; Wed, 27 Feb 2008 02:26:47 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id 9DD9313C459 for ; Wed, 27 Feb 2008 02:26:47 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 26 Feb 2008 18:16:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.25,410,1199692800"; d="scan'208,217";a="383927897" Received: from orsmsx334.amr.corp.intel.com (HELO orsmsx334.jf.intel.com) ([10.22.226.45]) by azsmga001.ch.intel.com with ESMTP; 26 Feb 2008 18:04:50 -0800 Received: from orsmsx416.amr.corp.intel.com ([10.22.226.46]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 18:04:49 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 26 Feb 2008 18:04:45 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scheduler questions thread-index: Ach45R+az9oAiVuZRJapk0FfdCrTBg== From: "Murty, Ravi" To: X-OriginalArrivalTime: 27 Feb 2008 02:04:49.0855 (UTC) FILETIME=[224FACF0:01C878E5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Scheduler questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 02:26:47 -0000 Hello Everyone, =20 I've been looking at the scheduler to understand some finer details and have a couple of questions I am hoping someone can answer pretty easily. =20 1. critnest: It appears that the whole point of critical_enter and critical_exit is to prevent preemption in the kernel by using these functions. I can see this being useful when kernel preemption is defined, but I can't seem to figure out why this would matter if kernel preemption is not defined. I can think of a case - e.g. thread enters kernel and is in critical section, timer interrupt fires and tries to preempt thread because it's time quantum expired. But I can't seem to find how this works. Also, why would critnest be equal to 2 or more? 2. Again, time quantum related question. When the scheduler (e.g. ULE) decides (in sched_clock) that it's time to switch a thread out because its time slice is 0, it sets the NEEDRESCHED flag and expects the ast() routine (as part of the return from the timer interrupt handler) to call mi_switch(). Why not call mi_switch right there in sched_clock()? =20 Thanks Ravi Murty From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 02:41:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0994C1065673 for ; Wed, 27 Feb 2008 02:41:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id C293013C45E for ; Wed, 27 Feb 2008 02:41:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 26 Feb 2008 18:41:29 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 151B5127343; Tue, 26 Feb 2008 18:41:28 -0800 (PST) Message-ID: <47C4CDE6.6040509@elischer.org> Date: Tue, 26 Feb 2008 18:41:42 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kris Kennaway References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> <47C45CFE.9030006@elischer.org> <47C468AE.7060603@FreeBSD.org> <47C494B5.2040306@elischer.org> <47C49FAA.1020605@FreeBSD.org> In-Reply-To: <47C49FAA.1020605@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , Andre Oppermann , FreeBSD Current , Marko Zec , Marko Zec , Marko Zec Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 02:41:34 -0000 Kris Kennaway wrote: > Julian Elischer wrote: >> Kris Kennaway wrote: >>> Julian Elischer wrote: >>>> Andre Oppermann wrote: >>>>> Brooks Davis wrote: >>>>>> On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: >>>>>> >>>>>>> At some stage in the next few weeks I will be trying to commit >>>>>>> Marco Zec's vimage code to -current. (only 'trying' not >>>>>>> for technical reasons, but political). >>>>> ... >>>>>>> Why now? >>>>>>> The code is in a shape where teh compiled out version of hte >>>>>>> system is stable. In the compiled in version, it is functional >>>>>>> enough to provide nearly all of what people want. It needs people >>>>>>> with other interests to adapt it to their purposes and use it so >>>>>>> that it can become a solid product for future releases. >>>>>> >>>>>> The website has a snapshot with a date over a month old and many >>>>>> comments about unstable interfaces. I've seen zero reports of >>>>>> substantial testing... >>>>> >>>>> What about locking and SMP scalability? Any new choke points? >>>> >>>> not that I've seen. >>> >>> That's a less than resounding endorsement :) >> >> do the 10Gb ethernet adapters have any major problems? >> are you willing to answer "no"? >> should we then rip them from the tree? > > Those are small, isolated components, so hardly the same thing as a > major architectural change that touches every part of the protocol stack. > > But if someone came along and said "I am going to replace the 10ge > drivers, but I dunno how well they perform" I'd say precisely the same > thing. > > Presumably someone (if not you, then Marko) has enough of a grasp of the > architectural changes being proposed to comment about what changes (if > any) were made to synchronisation models, and whether there are new > sources of performance overhead introduced. > > That person can answer Andre's question. no changes were made to the general synchronisatrion strategies. Each instance of the stack runs independently and has the same locks as the current stack. It's just that there are multiple of them. they never cross paths (except to get mbufs) and that works with multiple clients so doesn't need to be changed. The only elements that cross over are netgraph and some virtual interfaces. > > Kris From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 04:34:55 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 280FC1065674 for ; Wed, 27 Feb 2008 04:34:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outP.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 0255813C4EA for ; Wed, 27 Feb 2008 04:34:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 26 Feb 2008 20:34:53 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 208DF127365; Tue, 26 Feb 2008 20:34:53 -0800 (PST) Message-ID: <47C4E87B.8010403@elischer.org> Date: Tue, 26 Feb 2008 20:35:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> In-Reply-To: <47C4BB96.80804@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 04:34:55 -0000 Bruce M. Simpson wrote: > Julian Elischer wrote: >> >> what do we gain? >> Jail on steroids >> A framework that can be extended to other virtualisation avenues. >> The ability to have full virtual machines on almost any layout >> of physical hardware. > > I'm confused by the above statements. > > Also somewhat bemused by them, given that our track record for > regression testing and documentation ain't always that great either -- > and when bold new ideas are proposed, due diligence often saves the day. > > * Do you mean to say that IMUNES/vimage has expanded beyond merely > wrapping the network stack and virtualizing that? It includes enough of a framework to allow it to cope with loadable kernel modules and to integrate with jails. Two important requirements for its job. This means that this framework is avialable for other virtualisation work to use as well. > > If this is the case (it introduces some new virtualization technique on > par with the functionality of e.g. Xen) then I outright DISAGREE with > its introduction into the source tree on the grounds that it's too > experimental. no it doesn't do machine virtualisation. > > * Also, do the changes which you intend to introduce, allow for code > which is currently under development, and which is not aware of > vimage/IMUNES in any way, to continue to compile and be usable without > additional developer time? Code not aware of vimage just appears in all virtual machines, just as it would appear in all jails. I uses and expands on the jail infrastructure. > > I am continually sidetracked from FreeBSD infrastructural work because > it just doesn't pay the bills. As a result I have to defer work for up > to a year at a time. If there were community funding available this > would help, but as it is, I have to keep the plates spinning somehow. > > I usually try to keep my p4 development branches merged and in sync at a > minimum, so I can always diff against HEAD. Marco does a reasonable job of keeping up with head. he syncs it up every few weeks. I just committed some scripts that should help him do that too. > > [Julian, you're not about to give people a real headache with this, are > you?] > > * If the objective of the exercise is to expose people to vimage, would > it not be wiser to implement vimage as a fork in a more accessible > repository format than Perforce? e.g. Mercurial or Git? no the aim is to integrate it into FreeBSD. > > I am opposed to trial-by-fire. This is not trial by fire any more than any other code. However there must be SOME amount of trial by fire in every project.. > > I am just as frustrated with the lack of progress which is visible to > people on the outside of the development cabal as anybody else (just try > to get people to test code in Perforce when they aren't committers, and > you'll see EXACTLY what I mean), but I really don't like the idea of > experimental work going into CVS. And there we differ. I think the time for this has come. I'd say about 6 years is long enough. That is how long people have had to play with this and find problems. Anybody who has had anything to do with it has only sung its praises. > > Whilst CVS is a proven tool, its use in the project, to my mind, seems > more geared to delivering production code and tracking changes in > production branches, rather than managing fast-moving new development. Things have to get into it at some stage.. > > * Does the vimage code have a full set of regression tests which prove > that its introduction does not cause the system to behave in an > unexpected way? no. it has tests for its own functionality. No other piece of code in the system EVER has had regeression tests for whole system. Loading this burden on vimage is not a fair requirement. The aim of vimage is for you to not be able to tell, so any deviation form normal behaviour in any part of the system would be a regression. > > These are very real concerns and they do need to be addressed, otherwise > I speculate this is going to be messy, and I don't want to see a repeat > of FreeBSD 5.x. it is not going to be that.. Please read the code and the papers. > > Don't get me wrong, there is excellent reasoning and art behind the work > in vimage, but the very real economic difficulties involved in its > integration just cannot be ignored as they affect everyone involved with > the project. I' am cerainly not ignoring it.. That's why it is being pushed NOW and not 5 years ago in 4.6 when it could have been pushed in. > > best regards, > BMS From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 07:21:42 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AB5D1065674; Wed, 27 Feb 2008 07:21:42 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 02C0913C46E; Wed, 27 Feb 2008 07:21:41 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Wed, 27 Feb 2008 08:17:22 +0100 id 0002E00A.47C50E82.00016ADA From: Milan Obuch To: freebsd-current@freebsd.org Date: Wed, 27 Feb 2008 08:20:25 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> In-Reply-To: <47C4BB96.80804@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802270820.52816.freebsd-current@dino.sk> Cc: FreeBSD Current , Marko Zec , Marko Zec , Marko Zec , Julian Elischer , "Bruce M. Simpson" Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 07:21:42 -0000 On Wednesday 27 February 2008, Bruce M. Simpson wrote: I am not going to comment on all aspects, just some small notes... > Julian Elischer wrote: > > what do we gain? > > Jail on steroids > > A framework that can be extended to other virtualisation avenues. > > The ability to have full virtual machines on almost any layout > > of physical hardware. > > I'm confused by the above statements. > > Also somewhat bemused by them, given that our track record for > regression testing and documentation ain't always that great either -- > and when bold new ideas are proposed, due diligence often saves the day. > > * Do you mean to say that IMUNES/vimage has expanded beyond merely > wrapping the network stack and virtualizing that? > > If this is the case (it introduces some new virtualization technique on > par with the functionality of e.g. Xen) then I outright DISAGREE with > its introduction into the source tree on the grounds that it's too > experimental. > Did you check some papers on vimage? It's purpose is virtualise network sta= ck=20 by extending jails into virtual image... From my experience it has no other= =20 impact, just enable creation of 'extended jails' with full network stack. I= =20 may be wrong on this, but this is what my reading and experience show me... > * Also, do the changes which you intend to introduce, allow for code > which is currently under development, and which is not aware of > vimage/IMUNES in any way, to continue to compile and be usable without > additional developer time? > > I am continually sidetracked from FreeBSD infrastructural work because > it just doesn't pay the bills. As a result I have to defer work for up > to a year at a time. If there were community funding available this > would help, but as it is, I have to keep the plates spinning somehow. > > I usually try to keep my p4 development branches merged and in sync at a > minimum, so I can always diff against HEAD. > =46rom my, not kernel developer oriented perspective, there is no change at= all,=20 just bunch of new possibilities. Naturally, there are some changes in kerne= l,=20 but as far as I can see it, they are well defined and isolated in macros, s= o=20 this mostly means almost no change, but I am not the right one to comment o= n=20 this. > [Julian, you're not about to give people a real headache with this, are > you?] > > * If the objective of the exercise is to expose people to vimage, would > it not be wiser to implement vimage as a fork in a more accessible > repository format than Perforce? e.g. Mercurial or Git? > > I am opposed to trial-by-fire. > > I am just as frustrated with the lack of progress which is visible to > people on the outside of the development cabal as anybody else (just try > to get people to test code in Perforce when they aren't committers, and > you'll see EXACTLY what I mean), but I really don't like the idea of > experimental work going into CVS. > This work is experimental for more than five years. I am not testing it=20 continually, but as already stated, not only by me, it is really well=20 designed framework and really well coded. I do not remember any flaw or bug= =20 in my work with it. In my eyes, it is already stable and settled enough to = be=20 introduced into main tree. > Whilst CVS is a proven tool, its use in the project, to my mind, seems > more geared to delivering production code and tracking changes in > production branches, rather than managing fast-moving new development. > > * Does the vimage code have a full set of regression tests which prove > that its introduction does not cause the system to behave in an > unexpected way? > > These are very real concerns and they do need to be addressed, otherwise > I speculate this is going to be messy, and I don't want to see a repeat > of FreeBSD 5.x. > > Don't get me wrong, there is excellent reasoning and art behind the work > in vimage, but the very real economic difficulties involved in its > integration just cannot be ignored as they affect everyone involved with > the project. > Well, I am working with FreeBSD long enough to say there are periods when e= ven=20 stable or legacy branch breaks. They are rare, to be honest, but still can = be=20 disturbing. After branching 7.0, this is the right time to introduce anythi= ng=20 new which can be considered major change, not when preparing 8.0. Regards, Milan =2D-=20 Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead. From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 07:21:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AB5D1065674; Wed, 27 Feb 2008 07:21:42 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 02C0913C46E; Wed, 27 Feb 2008 07:21:41 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Wed, 27 Feb 2008 08:17:22 +0100 id 0002E00A.47C50E82.00016ADA From: Milan Obuch To: freebsd-current@freebsd.org Date: Wed, 27 Feb 2008 08:20:25 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> In-Reply-To: <47C4BB96.80804@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802270820.52816.freebsd-current@dino.sk> Cc: FreeBSD Current , Marko Zec , Marko Zec , Marko Zec , Julian Elischer , "Bruce M. Simpson" Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 07:21:42 -0000 On Wednesday 27 February 2008, Bruce M. Simpson wrote: I am not going to comment on all aspects, just some small notes... > Julian Elischer wrote: > > what do we gain? > > Jail on steroids > > A framework that can be extended to other virtualisation avenues. > > The ability to have full virtual machines on almost any layout > > of physical hardware. > > I'm confused by the above statements. > > Also somewhat bemused by them, given that our track record for > regression testing and documentation ain't always that great either -- > and when bold new ideas are proposed, due diligence often saves the day. > > * Do you mean to say that IMUNES/vimage has expanded beyond merely > wrapping the network stack and virtualizing that? > > If this is the case (it introduces some new virtualization technique on > par with the functionality of e.g. Xen) then I outright DISAGREE with > its introduction into the source tree on the grounds that it's too > experimental. > Did you check some papers on vimage? It's purpose is virtualise network sta= ck=20 by extending jails into virtual image... From my experience it has no other= =20 impact, just enable creation of 'extended jails' with full network stack. I= =20 may be wrong on this, but this is what my reading and experience show me... > * Also, do the changes which you intend to introduce, allow for code > which is currently under development, and which is not aware of > vimage/IMUNES in any way, to continue to compile and be usable without > additional developer time? > > I am continually sidetracked from FreeBSD infrastructural work because > it just doesn't pay the bills. As a result I have to defer work for up > to a year at a time. If there were community funding available this > would help, but as it is, I have to keep the plates spinning somehow. > > I usually try to keep my p4 development branches merged and in sync at a > minimum, so I can always diff against HEAD. > =46rom my, not kernel developer oriented perspective, there is no change at= all,=20 just bunch of new possibilities. Naturally, there are some changes in kerne= l,=20 but as far as I can see it, they are well defined and isolated in macros, s= o=20 this mostly means almost no change, but I am not the right one to comment o= n=20 this. > [Julian, you're not about to give people a real headache with this, are > you?] > > * If the objective of the exercise is to expose people to vimage, would > it not be wiser to implement vimage as a fork in a more accessible > repository format than Perforce? e.g. Mercurial or Git? > > I am opposed to trial-by-fire. > > I am just as frustrated with the lack of progress which is visible to > people on the outside of the development cabal as anybody else (just try > to get people to test code in Perforce when they aren't committers, and > you'll see EXACTLY what I mean), but I really don't like the idea of > experimental work going into CVS. > This work is experimental for more than five years. I am not testing it=20 continually, but as already stated, not only by me, it is really well=20 designed framework and really well coded. I do not remember any flaw or bug= =20 in my work with it. In my eyes, it is already stable and settled enough to = be=20 introduced into main tree. > Whilst CVS is a proven tool, its use in the project, to my mind, seems > more geared to delivering production code and tracking changes in > production branches, rather than managing fast-moving new development. > > * Does the vimage code have a full set of regression tests which prove > that its introduction does not cause the system to behave in an > unexpected way? > > These are very real concerns and they do need to be addressed, otherwise > I speculate this is going to be messy, and I don't want to see a repeat > of FreeBSD 5.x. > > Don't get me wrong, there is excellent reasoning and art behind the work > in vimage, but the very real economic difficulties involved in its > integration just cannot be ignored as they affect everyone involved with > the project. > Well, I am working with FreeBSD long enough to say there are periods when e= ven=20 stable or legacy branch breaks. They are rare, to be honest, but still can = be=20 disturbing. After branching 7.0, this is the right time to introduce anythi= ng=20 new which can be considered major change, not when preparing 8.0. Regards, Milan =2D-=20 Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead. From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 07:52:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FB2D1065671 for ; Wed, 27 Feb 2008 07:52:34 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id B24B513C4DB for ; Wed, 27 Feb 2008 07:52:33 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 08:52:30 +0100 Date: Wed, 27 Feb 2008 08:52:30 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Kip Macy In-Reply-To: Message-ID: <20080227085154.O69960@knop-beagle.kn.op.dlr.de> References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> <47C45CFE.9030006@elischer.org> <47C468AE.7060603@FreeBSD.org> <47C494B5.2040306@elischer.org> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 27 Feb 2008 07:52:31.0209 (UTC) FILETIME=[B4A5AD90:01C87915] Cc: Brooks Davis , Andre Oppermann , FreeBSD Current , Marko Zec , Marko Zec , Marko Zec , Julian Elischer Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 07:52:34 -0000 On Tue, 26 Feb 2008, Kip Macy wrote: KM>On Tue, Feb 26, 2008 at 2:37 PM, Julian Elischer wrote: KM>> Kris Kennaway wrote: KM>> > Julian Elischer wrote: KM>> >> Andre Oppermann wrote: KM>> >>> Brooks Davis wrote: KM>> >>>> On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: KM>> >>>> KM>> >>>>> At some stage in the next few weeks I will be trying to commit KM>> >>>>> Marco Zec's vimage code to -current. (only 'trying' not KM>> >>>>> for technical reasons, but political). KM>> >>> ... KM>> >>>>> Why now? KM>> >>>>> The code is in a shape where teh compiled out version of hte KM>> >>>>> system is stable. In the compiled in version, it is functional KM>> >>>>> enough to provide nearly all of what people want. It needs people KM>> >>>>> with other interests to adapt it to their purposes and use it so KM>> >>>>> that it can become a solid product for future releases. KM>> >>>> KM>> >>>> The website has a snapshot with a date over a month old and many KM>> >>>> comments about unstable interfaces. I've seen zero reports of KM>> >>>> substantial testing... KM>> >>> KM>> >>> What about locking and SMP scalability? Any new choke points? KM>> >> KM>> >> not that I've seen. KM>> > KM>> > That's a less than resounding endorsement :) KM>> KM>> do the 10Gb ethernet adapters have any major problems? KM>> are you willing to answer "no"? KM>> should we then rip them from the tree? KM>> KM>> I'm saying "this is work in progress" It seems stable and useful. KM>> until we can get more than 6 people running it we won't know more. KM>> KM> KM> KM> KM>Given how long it has been since RELENG_7 branched - if its really a KM>no-op when disabled, I personally don't see it any issues with it. yes++; harti From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 09:44:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DA64106566B; Wed, 27 Feb 2008 09:44:02 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id C76DE13C442; Wed, 27 Feb 2008 09:44:01 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id DFF5041C75B; Wed, 27 Feb 2008 10:35:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id GivT1+J22Olf; Wed, 27 Feb 2008 10:35:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 9252641C75A; Wed, 27 Feb 2008 10:35:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id E1C7E444885; Wed, 27 Feb 2008 09:30:50 +0000 (UTC) Date: Wed, 27 Feb 2008 09:30:50 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <47C4CDE6.6040509@elischer.org> Message-ID: <20080227092902.Q94494@maildrop.int.zabbadoz.net> References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> <47C45CFE.9030006@elischer.org> <47C468AE.7060603@FreeBSD.org> <47C494B5.2040306@elischer.org> <47C49FAA.1020605@FreeBSD.org> <47C4CDE6.6040509@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Brooks Davis , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 09:44:02 -0000 On Tue, 26 Feb 2008, Julian Elischer wrote: replying to a random mail: so could you provide a patch somewhere to fetch (better not post it as I expect it to be huge) of the vimage branch to todays HEAD so that everyone could see the changes w/o having to have p4 access? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 09:49:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D762D106566B; Wed, 27 Feb 2008 09:49:02 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9158613C4DD; Wed, 27 Feb 2008 09:49:02 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F249741C798; Wed, 27 Feb 2008 10:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 6DMjh8i2nEEf; Wed, 27 Feb 2008 10:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id A5B0441C76D; Wed, 27 Feb 2008 10:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 2B223444885; Wed, 27 Feb 2008 09:28:52 +0000 (UTC) Date: Wed, 27 Feb 2008 09:28:52 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <47C4E87B.8010403@elischer.org> Message-ID: <20080227092653.J94494@maildrop.int.zabbadoz.net> References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> <47C4E87B.8010403@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 09:49:02 -0000 On Tue, 26 Feb 2008, Julian Elischer wrote: Hi, > would appear in all jails. I uses and expands on the jail infrastructure. wait a sec, does that mean that it expands jails and jails will then be called "vimages"? Or will it still be possible to have jails inside a virtual instance? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 10:16:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFED31065698; Wed, 27 Feb 2008 10:16:48 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6B913C4F3; Wed, 27 Feb 2008 10:16:48 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Wed, 27 Feb 2008 11:12:18 +0100 id 0002E00B.47C53782.00017077 From: Milan Obuch To: freebsd-current@freebsd.org Date: Wed, 27 Feb 2008 11:16:23 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <47C4CDE6.6040509@elischer.org> <20080227092902.Q94494@maildrop.int.zabbadoz.net> In-Reply-To: <20080227092902.Q94494@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802271116.24530.freebsd-current@dino.sk> Cc: "Bjoern A. Zeeb" , Brooks Davis , Marko Zec , Julian Elischer Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 10:16:48 -0000 On Wednesday 27 February 2008, Bjoern A. Zeeb wrote: > On Tue, 26 Feb 2008, Julian Elischer wrote: > > replying to a random mail: > > so could you provide a patch somewhere to fetch (better not post it > as I expect it to be huge) of the vimage branch to todays HEAD so that > everyone could see the changes w/o having to have p4 access? Some time ago there was cvsup-/csup-accessible 'clone' of p4 vimage branch. It stopped working at some stage and now I have no idea on its state. If it could be put into working state again, testing would be much easier than today,at least for me :) Milan -- Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead. From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 10:28:07 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC3F01065673 for ; Wed, 27 Feb 2008 10:28:07 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5DC0913C428 for ; Wed, 27 Feb 2008 10:28:07 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so3895620qbd.7 for ; Wed, 27 Feb 2008 02:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=zjr5onQ27pCEjtiTaewTGqfJu/cr4cVaDVpBKJWCr7Y=; b=mJ6EHZCO7oZtnKreWLOrRNR2xtZO9ervZC+2B1OZ4ITuITXihEz3lCve2UdFnixBJ+b7BCp7u0jkxJF+xU2Ft6E0io4r7+M5G+GTIJ2DVj8qAk+st7YwAXTMX0YpT5gao6sS1Ok3aVDevimWSL1Pjb5+C3zECFGh4GyLmPDXkG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IW7c7mzjhC8DVNbPV8k54+zQkvCOkNH9/wM6RR/QuzgWwZoyrj3q1M169QdUSsRGh9nA2+GyQ2cIs6sGrlec/mgk0YHAvQ8yLCgm+k7VVdNUGOQxBzBwDevZGkIlnwnaMHXY/glQ3ZY2S0fhhGJMa7b1BVWaBtrFVFTqyHYB4ag= Received: by 10.110.3.15 with SMTP id 15mr5631400tic.51.1204107160154; Wed, 27 Feb 2008 02:12:40 -0800 (PST) Received: by 10.110.5.3 with HTTP; Wed, 27 Feb 2008 02:12:40 -0800 (PST) Message-ID: <5635aa0d0802270212l680bb40dr38d8dbfb91e89257@mail.gmail.com> Date: Wed, 27 Feb 2008 05:12:40 -0500 From: "Outback Dingo" To: "Bjoern A. Zeeb" In-Reply-To: <20080227092902.Q94494@maildrop.int.zabbadoz.net> MIME-Version: 1.0 References: <47C39948.3080907@elischer.org> <20080226051346.GA65258@lor.one-eyed-alien.net> <47C458E9.5090400@freebsd.org> <47C45CFE.9030006@elischer.org> <47C468AE.7060603@FreeBSD.org> <47C494B5.2040306@elischer.org> <47C49FAA.1020605@FreeBSD.org> <47C4CDE6.6040509@elischer.org> <20080227092902.Q94494@maildrop.int.zabbadoz.net> 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: Brooks Davis , Marko Zec , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 10:28:07 -0000 Yeah Ill agree here... a patch of the differences would be nice to have Itll allow us to patch running systems and test, then backout if neccesary Id like to see how mature it is. On Wed, Feb 27, 2008 at 4:30 AM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On Tue, 26 Feb 2008, Julian Elischer wrote: > > replying to a random mail: > > so could you provide a patch somewhere to fetch (better not post it > as I expect it to be huge) of the vimage branch to todays HEAD so that > everyone could see the changes w/o having to have p4 access? > > -- > Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT > Software is harder than hardware so better get it right the first time. > _______________________________________________ > 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 Wed Feb 27 14:33:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD5B3106566C for ; Wed, 27 Feb 2008 14:33:19 +0000 (UTC) (envelope-from zilla@antik.sk) Received: from mailserver.antik.sk (mailserver.antik.sk [88.212.10.6]) by mx1.freebsd.org (Postfix) with ESMTP id 2974A8FC2C for ; Wed, 27 Feb 2008 14:33:13 +0000 (UTC) (envelope-from zilla@antik.sk) Received: (qmail 13110 invoked from network); 27 Feb 2008 15:06:30 +0100 Received: by simscan 1.4.0 ppid: 13105, pid: 13107, t: 0.0124s scanners: regex: 1.4.0 attach: 1.4.0 clamav: 0.91.2/m:45/d:6004 Received: from unknown (HELO ?10.252.4.243?) (zilla@antik.sk@10.252.4.243) by mailserver.antik.sk with AES256-SHA encrypted SMTP; 27 Feb 2008 15:06:30 +0100 Message-ID: <47C56E67.9000402@antik.sk> Date: Wed, 27 Feb 2008 15:06:31 +0100 From: Matus Zilla User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 27 Feb 2008 14:41:54 +0000 Subject: FreeBSD 7.0 Beta,RC,RELEASE (amd64) freezes with dummynet enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 14:33:20 -0000 I have posted before that i have a stability issue with the 7.0 branch on my servers. Tested on BETA2,BETA4,RC1,RC2,RELEASE The original thread and my post with details is at: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-12/msg00674.html I was waiting for the 7.0-RELEASE, updated the whole servers, and enabled dummynet again, but it always freezes after some minutes, 100% reproducible. I tested it also on a HP 140 G3 1U server, where 6.3 has absolutely no problems, but the 7.0 branch keeps freezing. Again, if it helps to solve this bug, i can rebuild the kernel with debug symbols a take some screenshots :) From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 15:02:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BAB31065671 for ; Wed, 27 Feb 2008 15:02:21 +0000 (UTC) (envelope-from matthew@matthew.sk) Received: from mailserver.antik.sk (mailserver.antik.sk [88.212.10.6]) by mx1.freebsd.org (Postfix) with ESMTP id 6F4F18FC2D for ; Wed, 27 Feb 2008 15:02:20 +0000 (UTC) (envelope-from matthew@matthew.sk) Received: (qmail 11715 invoked from network); 27 Feb 2008 15:35:37 +0100 Received: by simscan 1.4.0 ppid: 11704, pid: 11712, t: 0.0078s scanners: regex: 1.4.0 attach: 1.4.0 clamav: 0.91.2/m:45/d:6004 Received: from unknown (HELO ?10.252.4.243?) (matthew@matthew.sk@10.252.4.243) by mailserver.antik.sk with AES256-SHA encrypted SMTP; 27 Feb 2008 15:35:37 +0100 Message-ID: <47C5753A.8010806@matthew.sk> Date: Wed, 27 Feb 2008 15:35:38 +0100 From: matthew User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 7.0 Beta,RC,RELEASE (amd64) freezes with dummynet enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 15:02:21 -0000 I have posted before that i have a stability issue with the 7.0 branch on my servers. Tested on BETA2,BETA4,RC1,RC2,RELEASE The original thread and my post with details is at: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-12/msg00674.html I was waiting for the 7.0-RELEASE, updated the whole servers, and enabled dummynet again, but it always freezes after some minutes, 100% reproducible. I tested it also on a HP 140 G3 1U server, where 6.3 has absolutely no problems, but the 7.0 branch keeps freezing. Again, if it helps to solve this bug, i can rebuild the kernel with debug symbols a take some screenshots :) From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 15:08:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CCFE1065678 for ; Wed, 27 Feb 2008 15:08:51 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E42518FC30; Wed, 27 Feb 2008 15:08:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C57D01.8070007@FreeBSD.org> Date: Wed, 27 Feb 2008 16:08:49 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: matthew References: <47C5753A.8010806@matthew.sk> In-Reply-To: <47C5753A.8010806@matthew.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0 Beta, RC, RELEASE (amd64) freezes with dummynet enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 15:08:51 -0000 matthew wrote: > I have posted before that i have a stability issue with the 7.0 branch > on my servers. Tested on BETA2,BETA4,RC1,RC2,RELEASE > > The original thread and my post with details is at: > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-12/msg00674.html > > > I was waiting for the 7.0-RELEASE, updated the whole servers, and > enabled dummynet again, but it always freezes after some minutes, 100% > reproducible. > > I tested it also on a HP 140 G3 1U server, where 6.3 has absolutely no > problems, but the 7.0 branch keeps freezing. > > Again, if it helps to solve this bug, i can rebuild the kernel with > debug symbols a take some screenshots :) > > _______________________________________________ > 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" > > Please follow the steps at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html Kris From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 17:12:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 276C21065671 for ; Wed, 27 Feb 2008 17:12:08 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 06E1B8FC2A for ; Wed, 27 Feb 2008 17:12:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RHC7Rv022623; Wed, 27 Feb 2008 12:12:07 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m1RHC6Rx060293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 12:12:06 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200802271712.m1RHC6Rx060293@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 12:09:42 -0500 To: pyunyh@gmail.com From: Mike Tancsa In-Reply-To: <20080226053423.GB47750@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <20080217112104.X80805@fledge.watson.org> <200802171458.26951.freebsd-current@dino.sk> <200802171517.26965.freebsd-current@dino.sk> <20080218081801.GB14601@cdnetworks.co.kr> <20080222054356.GE30497@cdnetworks.co.kr> <200802260503.m1Q53Jm3050738@lava.sentex.ca> <20080226053423.GB47750@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 17:12:08 -0000 At 12:34 AM 2/26/2008, Pyun YongHyeon wrote: > > > >Thanks again for your testing! >An unresolved issue for Milan Obuch's router board still prevent me >from committing the overhauled one. Unfortunately I still have no >clue why his hardware does not work even though it has the same >hardware revision(0x96). I found another bug that your version of the driver fixes. Its fairly easy for me to reproduce now and other people seem to run into it as well. I hooked up 2 boxes with the NICs to a cisco switch with the 2 interfaces on the same vlan. I then start a continuous ping either from the other box, or on the box itself. boxA# ping boxB PING 192.168.7.23 (192.168.7.23): 56 data bytes 64 bytes from 192.168.7.23: icmp_seq=0 ttl=64 time=0.974 ms 64 bytes from 192.168.7.23: icmp_seq=1 ttl=64 time=0.420 ms 64 bytes from 192.168.7.23: icmp_seq=2 ttl=64 time=0.427 ms 64 bytes from 192.168.7.23: icmp_seq=3 ttl=64 time=0.416 ms 64 bytes from 192.168.7.23: icmp_seq=4 ttl=64 time=0.455 ms 64 bytes from 192.168.7.23: icmp_seq=5 ttl=64 time=0.405 ms 64 bytes from 192.168.7.23: icmp_seq=6 ttl=64 time=0.423 ms 64 bytes from 192.168.7.23: icmp_seq=7 ttl=64 time=0.422 ms ^C --- 192.168.7.23 ping statistics --- 66 packets transmitted, 20 packets received, 69.7% packet loss round-trip min/avg/max/stddev = 0.396/0.476/0.974/0.132 ms While in the middle of the ping, I change the media speed of the port of the box that is doing the pinging to 10 and then back to auto boxA# ifconfig vr2 vr2: flags=8843 metric 0 mtu 1500 options=b ether 00:00:24:c9:34:8a inet 192.168.7.21 netmask 0xffffff00 broadcast 192.168.7.255 media: Ethernet autoselect (100baseTX ) status: active The nic is now wedged on boxA. I then have to do a ifconfig vr2 down and ifconfig vr2 up to un wedge it, and in the logs I see the forced reset vr2: link state changed to DOWN vr2: link state changed to UP vr2: link state changed to DOWN vr2: link state changed to UP vr2: Using force reset command. ..... HOWEVER, using the updated drivers on your web page, the box survives this exercise. There is the occasional "shutdown error", but I guess thats to be expected as the physical layer is bouncing up and down. But the main thing is that the box recovers on its own. vr2: link state changed to DOWN vr2: link state changed to UP vr2: link state changed to DOWN vr2: link state changed to UP vr2: link state changed to DOWN vr2: link state changed to UP vr2: vr_link_task: Tx/Rx shutdown error -- resetting vr2: link state changed to DOWN vr2: restarting vr2: vr_stop: Rx shutdown error vr2: Using force reset command. vr2: link state changed to UP ---Mike From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 17:28:26 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D4041065672; Wed, 27 Feb 2008 17:28:26 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [212.17.241.230]) by mx1.freebsd.org (Postfix) with ESMTP id A98EA8FC27; Wed, 27 Feb 2008 17:28:25 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1RH8Iwj012698; Wed, 27 Feb 2008 18:08:18 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1RH8Eqv012697; Wed, 27 Feb 2008 18:08:14 +0100 (CET) (envelope-from olli) Date: Wed, 27 Feb 2008 18:08:14 +0100 (CET) Message-Id: <200802271708.m1RH8Eqv012697@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, julian@elischer.org, Marko Zec , Marko Zec , Marko Zec In-Reply-To: <47C39948.3080907@elischer.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 27 Feb 2008 18:08:19 +0100 (CET) Cc: Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 17:28:26 -0000 Julian Elischer wrote: > At some stage in the next few weeks I will be trying to commit > Marco Zec's vimage code to -current. (only 'trying' not > for technical reasons, but political). I think the vimage code is very exciting and useful, in particular because it enables using multiple IP addresses and IPv6 in jails. In fact that's long overdue. Pointing people to the p4 branch is not very helpful, I think. There seems to be lots of interest, but p4 is a closed user group. Unfortunately the public cvsup server that mirrored the p4 repository doesn't exist anymore. How about putting a tarball of the current code (against HEAD) online on some webserver? So many more people would be able to test it, and I bet many are eager to do so. If feedback is good and nothing breaks horribly, you will certainly see less objections against committing it. PJD did the same with ZFS, i.e. providing tarballs for public consumption, and when the feedback was good enough, it finally hit the tree. I'm sure vimage will be a huge success as well. Just my 2 cents. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 17:41:22 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6B7C1065670; Wed, 27 Feb 2008 17:41:22 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0598FC13; Wed, 27 Feb 2008 17:41:22 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id AF160A25A6; Wed, 27 Feb 2008 12:26:15 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 27 Feb 2008 12:26:15 -0500 X-Sasl-enc: 6uV9aEgfl+N6jJ8HUrArvTg6N2mSuULLibXjnbCWryR8 1204133175 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 ESMTPSA id 9EE2C313D4; Wed, 27 Feb 2008 12:26:14 -0500 (EST) Message-ID: <47C59D35.2060801@incunabulum.net> Date: Wed, 27 Feb 2008 17:26:13 +0000 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: Julian Elischer References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> <47C4E87B.8010403@elischer.org> In-Reply-To: <47C4E87B.8010403@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 17:41:22 -0000 Just to give everone some background: I shared an office in Berkeley with Marko for nearly a month 3 years ago, working on the same project. I bear him no ill will whatsoever, I'm impressed by the work he's done, especially so given he's started a family. But I do need to wear a black hat in this argument, because there's more to FreeBSD than the server space, and the future beckons. We need to balance the risk of the new feature against its effect on current and future development. I still see loose ends which need to be tied up before I'm 90% happy. I will never be 100% happy with anything in life ever. Julian Elischer wrote: > It includes enough of a framework to allow it to cope with loadable > kernel modules and to integrate with jails. Two important requirements > for its job. This means that this framework is avialable for other > virtualisation work to use as well. > > no it doesn't do machine virtualisation. > OK, so the agenda for vimage hasn't fundamentally changed. Thanks for clarifying this. I got the impression from your message that the agenda had gotten bigger. >> >> * Also, do the changes which you intend to introduce, allow for code >> which is currently under development, and which is not aware of >> vimage/IMUNES in any way, to continue to compile and be usable >> without additional developer time? > > Code not aware of vimage just appears in all virtual machines, just as > it would appear in all jails. I uses and expands on the jail > infrastructure. > OK. The presence of jail generally doesn't interfere with things I've been looking at. I don't really have a problem with this as long as it defaults to "off" for at least a first release. I speculate the majority of the user base don't actually need vimage. I speculate it isn't an interesting feature in the near future for embedded platforms. They may not know they want it (or I for that matter) yet. It's a bit like trying to get a child to eat more green vegetables. Of course if vimage touches network interfaces, and can present virtual NICs to the stack, then things get more complicated. This of course is the KitchenSinkBSD issue, how can something be all things to all people and yet stay focused and be tight? > And there we differ. I think the time for this has come. I'd say about > 6 years is long enough. That is how long people have had to play with > this and find problems. Anybody who has had anything to do with it > has only sung its praises. > I know -- 6 years -- blimey, tell me about it. But the point I am making is that a lot of that drag could have been avoided. It's not the first time that I've introduced code to the tree, having given people plenty of warning (3-6 months), and then experience my stress levels surge off the scale as my inbox, and lists, are bombarded with messages from people going "WTF?" And this set of changes wasn't even on the scale of vimage. It is reminiscent of the opening chapters of Douglas Adams' "Hitchhiker's Guide to the Galaxy", where notice of the change, to their mind, was posted in a basement filing cabinet behind a locked door with a sign saying "Beware of the leopard". I see problems because people come to expect a higher level of polish from FreeBSD as they do from its alternatives, which is why I mention regression testing. In many ways there is no real substitute for a commercially oriented development model, however as we know that has its cons as well as its pros. Granted, there's infinite demand for free goods and services. Unfortunately this is more economically involved than simply saying to the world, "Look everyone, I made some cookies. Want some?" -- unless it's done on a small scale and the effort is tightly focused. I imagine most of us know that real life development of anything is an iterative process. Of course finding people who are willing to be committed to test and roll-out is made infinitely easier, if there are other things in it for them, and quite often, that boils down to money... Which leads to a head on collision with the ideological battleground that open source sometimes ends up being. >> >> Whilst CVS is a proven tool, its use in the project, to my mind, >> seems more geared to delivering production code and tracking changes >> in production branches, rather than managing fast-moving new >> development. > > Things have to get into it at some stage.. Again, I'm trying to underline a point about CVS, p4 and their use within the project. Perforce doesn't really cut it for opening up code to the public at large, as we have seen, and has real limitations, both in these terms and in terms of its resource use. > > no. it has tests for its own functionality. > No other piece of code in the system EVER has had regeression > tests for whole system. Loading this burden on vimage is not a > fair requirement. The aim of vimage is for you to not be able to tell, > so any deviation form normal behaviour in any part of the > system would be a regression. Of course it's not fair -- I'm playing daemon's advocate here. ;^) I would be happier to see vimage go in when I see stronger answers to the questions which Andre and Kris raise re synchronization overhead. Again, I'm making the point that more formal software development practice wouldn't go amiss, particularly when introducing something with wide impact such as vimage. I'm on an interesting chapter of Douglas Hofstader's "G*del, Escher, Bach" which discusses just such interdependence just now. I'm happy that things aren't specced down to the microsecond in FreeBSD, otherwise we'd never get anything done. Folks just have to remember to perform appropriate system tuning on their own expectations. ;-) cheers BMS From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 18:24:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D79C106567E; Wed, 27 Feb 2008 18:24:40 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id B9B9C8FC13; Wed, 27 Feb 2008 18:24:33 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1RIOKQc004014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 05:24:21 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1RIOK0p064987; Thu, 28 Feb 2008 05:24:20 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1RIOJRB064969; Thu, 28 Feb 2008 05:24:19 +1100 (EST) (envelope-from peter) Date: Thu, 28 Feb 2008 05:24:19 +1100 From: Peter Jeremy To: Bruce M Simpson Message-ID: <20080227182419.GD83599@server.vk2pj.dyndns.org> References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> <47C4E87B.8010403@elischer.org> <47C59D35.2060801@incunabulum.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pe+tqlI1iYzVj1X/" Content-Disposition: inline In-Reply-To: <47C59D35.2060801@incunabulum.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Marko Zec , Marko Zec , Marko Zec , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 18:24:40 -0000 --pe+tqlI1iYzVj1X/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2008 at 05:26:13PM +0000, Bruce M Simpson wrote: >I speculate the majority of the user base don't actually need vimage. You could probably say that about lots of base features. Julian has confirmed that it can be compiled out so I don't see this as a problem. >It is reminiscent of the opening chapters of Douglas Adams' "Hitchhiker's= =20 >Guide to the Galaxy", where notice of the change, to their mind, was poste= d=20 >in a basement filing cabinet behind a locked door with a sign saying=20 >"Beware of the leopard". Hence this thread. Anyone who is likely to be affected is supposed to be reading this mailing list. It's not clear what else Julian should do to warn/inform people. >Perforce doesn't really cut it for opening up code to the public at large,= =20 >as we have seen, and has real limitations, both in these terms and in term= s=20 >of its resource use. The alternative is to put the code in CVS. And from what I've read in this thread, the code sounds like it's ready. (Though making a patch set generally available in the interim would probably be useful). --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --pe+tqlI1iYzVj1X/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHxarS/opHv/APuIcRAvQYAJ43xMjTsdWnoaIok5j1FXIN7RGicACcD45S PXYlShHjbOOIU5RW66Ppn4E= =QNha -----END PGP SIGNATURE----- --pe+tqlI1iYzVj1X/-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 18:34:29 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 954761065678 for ; Wed, 27 Feb 2008 18:34:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA488FC2E for ; Wed, 27 Feb 2008 18:34:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 27 Feb 2008 10:34:28 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 1097C12738B; Wed, 27 Feb 2008 10:34:28 -0800 (PST) Message-ID: <47C5AD44.6040907@elischer.org> Date: Wed, 27 Feb 2008 10:34:44 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Bruce M Simpson References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> <47C4E87B.8010403@elischer.org> <47C59D35.2060801@incunabulum.net> In-Reply-To: <47C59D35.2060801@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 18:34:29 -0000 Bruce M Simpson wrote: > Just to give everone some background: > I shared an office in Berkeley with Marko for nearly a month 3 years > ago, working on the same project. I bear him no ill will whatsoever, I'm > impressed by the work he's done, especially so given he's started a family. > > But I do need to wear a black hat in this argument, because there's more > to FreeBSD than the server space, and the future beckons. > > We need to balance the risk of the new feature against its effect on > current and future development. I still see loose ends which need to be > tied up before I'm 90% happy. I will never be 100% happy with anything > in life ever. I personally want it for my laptop, and embedded devices. Of course there are loose ends but because it can be compiled out, they do not need to affect other users when we commit it. They will only affect those who elect to be affected. > > Julian Elischer wrote: >> It includes enough of a framework to allow it to cope with loadable >> kernel modules and to integrate with jails. Two important requirements >> for its job. This means that this framework is avialable for other >> virtualisation work to use as well. >> >> no it doesn't do machine virtualisation. >> > > OK, so the agenda for vimage hasn't fundamentally changed. Thanks for > clarifying this. I got the impression from your message that the agenda > had gotten bigger. No, but we would like to get it integrated with other virtual machine work that is underway. In the same way it integrates in with jails at the moment. > > >>> >>> * Also, do the changes which you intend to introduce, allow for code >>> which is currently under development, and which is not aware of >>> vimage/IMUNES in any way, to continue to compile and be usable >>> without additional developer time? >> >> Code not aware of vimage just appears in all virtual machines, just as >> it would appear in all jails. I uses and expands on the jail >> infrastructure. >> > > OK. The presence of jail generally doesn't interfere with things I've > been looking at. > > I don't really have a problem with this as long as it defaults to "off" > for at least a first release. > > I speculate the majority of the user base don't actually need vimage. I > speculate it isn't an interesting feature in the near future for > embedded platforms. They may not know they want it (or I for that > matter) yet. It's a bit like trying to get a child to eat more green > vegetables. I am pushing this for embedded platform use.. That's what I do. consider.. I have module A and module B that do function X on a network segment. Now I can make a machine with 4 interfaces and have function X performed on 4 network segments without fear of them interacting and producing problems. WITHOUT CHANGING MY CODE. I can make a compbined device that has module A and module B both on the same segment, with no fear that they'll screw each other up WITHOUT CHANGING MY CODE. (just some little examples) > > Of course if vimage touches network interfaces, and can present virtual > NICs to the stack, then things get more complicated. it can if you want it to.. but you mis-spoke. You said "the stack". There is no one special stack. There are many and each virtual interface could be feeding to a different stack. > > This of course is the KitchenSinkBSD issue, how can something be all > things to all people and yet stay focused and be tight? > >> And there we differ. I think the time for this has come. I'd say about >> 6 years is long enough. That is how long people have had to play with >> this and find problems. Anybody who has had anything to do with it >> has only sung its praises. >> > I know -- 6 years -- blimey, tell me about it. > > But the point I am making is that a lot of that drag could have been > avoided. how? "sticks in the mud can be very stubborn". > > It's not the first time that I've introduced code to the tree, having > given people plenty of warning (3-6 months), and then experience my > stress levels surge off the scale as my inbox, and lists, are bombarded > with messages from people going "WTF?" > > And this set of changes wasn't even on the scale of vimage. yes but you can compile it out and it will be so by default. I've done quite a few "large" introductions over the years. Sometimes not because I really wanted to, but because "some-one has to do this". (e.g. threading) This is probably the least dangerous of them all. > > It is reminiscent of the opening chapters of Douglas Adams' > "Hitchhiker's Guide to the Galaxy", where notice of the change, to their > mind, was posted in a basement filing cabinet behind a locked door with > a sign saying "Beware of the leopard". Oh do come on, this has been presented at several conferences and Marco and I have brought it up whenever possible. > > I see problems because people come to expect a higher level of polish > from FreeBSD as they do from its alternatives, which is why I mention > regression testing. In many ways there is no real substitute for a > commercially oriented development model, however as we know that has its > cons as well as its pros. well, turn it off if you want to avoid the risk.. but it will NEVER get the polish you want of it if we do not put it in after 7.0 is out. > > Granted, there's infinite demand for free goods and services. > Unfortunately this is more economically involved than simply saying to > the world, "Look everyone, I made some cookies. Want some?" -- unless > it's done on a small scale and the effort is tightly focused. I imagine > most of us know that real life development of anything is an iterative > process. > > Of course finding people who are willing to be committed to test and > roll-out is made infinitely easier, if there are other things in it for > them, and quite often, that boils down to money... > > Which leads to a head on collision with the ideological battleground > that open source sometimes ends up being. > >>> >>> Whilst CVS is a proven tool, its use in the project, to my mind, >>> seems more geared to delivering production code and tracking changes >>> in production branches, rather than managing fast-moving new >>> development. >> >> Things have to get into it at some stage.. > > Again, I'm trying to underline a point about CVS, p4 and their use > within the project. P4 is not a suitable place for code to get polish. That's all there is to it. We do not make releases from P4. > > Perforce doesn't really cut it for opening up code to the public at > large, as we have seen, and has real limitations, both in these terms > and in terms of its resource use. exactly. This has gone about as far as it can in perforce. it's time for the next step. > > >> >> no. it has tests for its own functionality. >> No other piece of code in the system EVER has had regeression >> tests for whole system. Loading this burden on vimage is not a >> fair requirement. The aim of vimage is for you to not be able to tell, >> so any deviation form normal behaviour in any part of the >> system would be a regression. > > Of course it's not fair -- I'm playing daemon's advocate here. ;^) > > I would be happier to see vimage go in when I see stronger answers to > the questions which Andre and Kris raise re synchronization overhead. there is less synchronisation overhead when you have multiple vimages than when you have the same number of multiple jails. (because different interfaces lead to different IP stacks with different locks, so the load is spread over several locks so the collision probability is reduced). When you have one vimage it has the same overhead as the curtent code, and when you compile it out you effectively HAVE the current code. Does that make it easier for you? > > Again, I'm making the point that more formal software development > practice wouldn't go amiss, particularly when introducing something with > wide impact such as vimage. > > I'm on an interesting chapter of Douglas Hofstader's "G*del, Escher, > Bach" which discusses just such interdependence just now. > > I'm happy that things aren't specced down to the microsecond in FreeBSD, > otherwise we'd never get anything done. Folks just have to remember to > perform appropriate system tuning on their own expectations. ;-) > > cheers > BMS From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 18:41:23 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EB7E1065674 for ; Wed, 27 Feb 2008 18:41:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outA.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 4D19C8FC20 for ; Wed, 27 Feb 2008 18:41:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 27 Feb 2008 10:41:22 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C0134125E65; Wed, 27 Feb 2008 10:41:21 -0800 (PST) Message-ID: <47C5AEE2.9040708@elischer.org> Date: Wed, 27 Feb 2008 10:41:38 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> <47C4E87B.8010403@elischer.org> <20080227092653.J94494@maildrop.int.zabbadoz.net> In-Reply-To: <20080227092653.J94494@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 18:41:23 -0000 Bjoern A. Zeeb wrote: > On Tue, 26 Feb 2008, Julian Elischer wrote: > > Hi, > >> would appear in all jails. I uses and expands on the jail infrastructure. > > wait a sec, does that mean that it expands jails and jails will then > be called "vimages"? Or will it still be possible to have jails inside > a virtual instance? > hmm i haven't actually tried a jail in a vimage, but it Should work I think. I just rebooted my vimage machine for some other work and need it for a while so I can't test it now.. just as there is an effective default jail for the base system, hter eis an effective 'default jail' for a vimage, there canbe others as well. Note that vimages a nesteable, and you can assign subsets of stuff between them in a nested manner as you would expect. So a jail in a vimage would have to select one of the addressed assigned to that vimage for it to be able to work.. of course you can assigne the same address to many vimages if they are on separate disjoint unconnected networks. Something you can not do with jails alone. (for example). From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 18:50:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 323C5106566C for ; Wed, 27 Feb 2008 18:50:25 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id EA9418FC17 for ; Wed, 27 Feb 2008 18:50:24 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from [81.104.123.28] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1JURMD-000God-JN; Wed, 27 Feb 2008 18:50:21 +0000 Received: from freaky by voi.aagh.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JURMD-000CYJ-A9; Wed, 27 Feb 2008 18:50:21 +0000 Date: Wed, 27 Feb 2008 18:50:21 +0000 From: Thomas Hurst To: Milan Obuch Message-ID: <20080227185021.GA34043@voi.aagh.net> Mail-Followup-To: Milan Obuch , freebsd-current@freebsd.org, "Bjoern A. Zeeb" , Brooks Davis , Marko Zec , Julian Elischer References: <47C39948.3080907@elischer.org> <47C4CDE6.6040509@elischer.org> <20080227092902.Q94494@maildrop.int.zabbadoz.net> <200802271116.24530.freebsd-current@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802271116.24530.freebsd-current@dino.sk> Organization: Not much. User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Thomas Hurst Cc: Marko Zec , "Bjoern A. Zeeb" , freebsd-current@freebsd.org, Brooks Davis , Julian Elischer Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 18:50:25 -0000 * Milan Obuch (freebsd-current@dino.sk) wrote: > Some time ago there was cvsup-/csup-accessible 'clone' of p4 vimage > branch. It stopped working at some stage and now I have no idea on its > state. If it could be put into working state again, testing would be > much easier than today,at least for me :) devel/git has a git-p4 command for interfacing with perforce; anyone with p4 access could clone the repository and make it available with just a webserver. Maybe easier to do than sorting out a functioning bridge with cvsup again. -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 20:41:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E610106566B; Wed, 27 Feb 2008 20:41:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 62E8C8FC12; Wed, 27 Feb 2008 20:41:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RKfdtD082822; Wed, 27 Feb 2008 15:41:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RKggxj011219; Wed, 27 Feb 2008 15:42:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8A22273039; Wed, 27 Feb 2008 15:41:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227204139.8A22273039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 15:41:39 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 20:41:40 -0000 TB --- 2008-02-27 20:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 20:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-02-27 20:30:00 - cleaning the object tree TB --- 2008-02-27 20:30:14 - cvsupping the source tree TB --- 2008-02-27 20:30:14 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-02-27 20:30:21 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 20:30:21 - cd /src TB --- 2008-02-27 20:30:21 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 20:30:23 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 20:41:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 20:41:39 - ERROR: failed to build world TB --- 2008-02-27 20:41:39 - tinderbox aborted TB --- 479.40 user 61.71 system 698.82 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 20:44:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C66B01065671; Wed, 27 Feb 2008 20:44:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id AC3BA8FC31; Wed, 27 Feb 2008 20:44:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RKiHp1083291; Wed, 27 Feb 2008 15:44:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RKjJa6014537; Wed, 27 Feb 2008 15:45:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E1C7673039; Wed, 27 Feb 2008 15:44:16 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227204416.E1C7673039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 15:44:16 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 20:44:17 -0000 TB --- 2008-02-27 20:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 20:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-02-27 20:30:00 - cleaning the object tree TB --- 2008-02-27 20:30:32 - cvsupping the source tree TB --- 2008-02-27 20:30:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-02-27 20:30:38 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 20:30:38 - cd /src TB --- 2008-02-27 20:30:38 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 20:30:40 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 20:44:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 20:44:16 - ERROR: failed to build world TB --- 2008-02-27 20:44:16 - tinderbox aborted TB --- 583.42 user 74.08 system 856.27 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 20:55:09 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C1A8106567B; Wed, 27 Feb 2008 20:55:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5BD008FC18; Wed, 27 Feb 2008 20:55:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RKt8O9084770; Wed, 27 Feb 2008 15:55:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RKuBKm052399; Wed, 27 Feb 2008 15:56:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 85F7F73039; Wed, 27 Feb 2008 15:55:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227205508.85F7F73039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 15:55:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 20:55:09 -0000 TB --- 2008-02-27 20:41:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 20:41:39 - starting HEAD tinderbox run for i386/i386 TB --- 2008-02-27 20:41:39 - cleaning the object tree TB --- 2008-02-27 20:42:19 - cvsupping the source tree TB --- 2008-02-27 20:42:19 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-02-27 20:42:25 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 20:42:25 - cd /src TB --- 2008-02-27 20:42:25 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 20:42:29 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 20:55:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 20:55:08 - ERROR: failed to build world TB --- 2008-02-27 20:55:08 - tinderbox aborted TB --- 537.71 user 63.91 system 808.89 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 20:57:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 502D11065670; Wed, 27 Feb 2008 20:57:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2AC8FC19; Wed, 27 Feb 2008 20:57:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RKvkQL085111; Wed, 27 Feb 2008 15:57:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RKwnOb059917; Wed, 27 Feb 2008 15:58:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7358473039; Wed, 27 Feb 2008 15:57:46 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227205746.7358473039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 15:57:46 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 20:57:47 -0000 TB --- 2008-02-27 20:44:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 20:44:17 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-02-27 20:44:17 - cleaning the object tree TB --- 2008-02-27 20:44:48 - cvsupping the source tree TB --- 2008-02-27 20:44:48 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-02-27 20:44:54 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 20:44:54 - cd /src TB --- 2008-02-27 20:44:54 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 20:44:56 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 20:57:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 20:57:46 - ERROR: failed to build world TB --- 2008-02-27 20:57:46 - tinderbox aborted TB --- 539.16 user 62.82 system 809.34 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 21:09:23 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11F3C106566C; Wed, 27 Feb 2008 21:09:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E01498FC19; Wed, 27 Feb 2008 21:09:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RL9MNN086573; Wed, 27 Feb 2008 16:09:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RL99Wp091485; Wed, 27 Feb 2008 16:09:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2136373039; Wed, 27 Feb 2008 16:08:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227210807.2136373039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 16:08:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 21:09:23 -0000 TB --- 2008-02-27 20:55:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 20:55:08 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-02-27 20:55:08 - cleaning the object tree TB --- 2008-02-27 20:55:45 - cvsupping the source tree TB --- 2008-02-27 20:55:45 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-02-27 20:55:51 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 20:55:51 - cd /src TB --- 2008-02-27 20:55:51 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 20:55:54 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 21:08:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 21:08:07 - ERROR: failed to build world TB --- 2008-02-27 21:08:07 - tinderbox aborted TB --- 528.57 user 61.90 system 778.50 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 21:11:03 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE0E0106566B; Wed, 27 Feb 2008 21:11:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B7D308FC20; Wed, 27 Feb 2008 21:11:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLB3R4086805; Wed, 27 Feb 2008 16:11:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLC5AC004517; Wed, 27 Feb 2008 16:12:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 26B9B73039; Wed, 27 Feb 2008 16:11:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227211103.26B9B73039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 16:11:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 21:11:04 -0000 TB --- 2008-02-27 20:57:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 20:57:46 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-02-27 20:57:46 - cleaning the object tree TB --- 2008-02-27 20:58:14 - cvsupping the source tree TB --- 2008-02-27 20:58:14 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-02-27 20:58:19 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 20:58:19 - cd /src TB --- 2008-02-27 20:58:19 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 20:58:21 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 21:11:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 21:11:03 - ERROR: failed to build world TB --- 2008-02-27 21:11:03 - tinderbox aborted TB --- 550.14 user 62.16 system 796.41 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 21:20:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A941B1065675; Wed, 27 Feb 2008 21:20:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 80C9C8FC1C; Wed, 27 Feb 2008 21:20:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLKGUw088119; Wed, 27 Feb 2008 16:20:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLLJJ3031405; Wed, 27 Feb 2008 16:21:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 88E9373039; Wed, 27 Feb 2008 16:20:16 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227212016.88E9373039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 16:20:16 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 21:20:17 -0000 TB --- 2008-02-27 21:08:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 21:08:07 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-02-27 21:08:07 - cleaning the object tree TB --- 2008-02-27 21:08:42 - cvsupping the source tree TB --- 2008-02-27 21:08:42 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-02-27 21:08:49 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 21:08:49 - cd /src TB --- 2008-02-27 21:08:49 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 21:08:51 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 21:20:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 21:20:16 - ERROR: failed to build world TB --- 2008-02-27 21:20:16 - tinderbox aborted TB --- 468.95 user 61.07 system 729.22 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 21:22:20 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D231065678; Wed, 27 Feb 2008 21:22:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id CB3D68FC12; Wed, 27 Feb 2008 21:22:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLMJQq088354; Wed, 27 Feb 2008 16:22:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLMJfL009722; Wed, 27 Feb 2008 16:22:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2397873039; Wed, 27 Feb 2008 16:22:19 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227212219.2397873039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 16:22:19 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 21:22:20 -0000 TB --- 2008-02-27 21:11:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 21:11:03 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-02-27 21:11:03 - cleaning the object tree TB --- 2008-02-27 21:11:34 - cvsupping the source tree TB --- 2008-02-27 21:11:34 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-02-27 21:11:40 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 21:11:40 - cd /src TB --- 2008-02-27 21:11:40 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 21:11:41 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 21:22:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 21:22:19 - ERROR: failed to build world TB --- 2008-02-27 21:22:19 - tinderbox aborted TB --- 466.49 user 61.53 system 675.84 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 21:36:15 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C43106567F; Wed, 27 Feb 2008 21:36:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 37F068FC12; Wed, 27 Feb 2008 21:36:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLaElo090034; Wed, 27 Feb 2008 16:36:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLaEiB032522; Wed, 27 Feb 2008 16:36:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 893FE73039; Wed, 27 Feb 2008 16:36:14 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227213614.893FE73039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 16:36:14 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 21:36:15 -0000 TB --- 2008-02-27 21:25:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 21:25:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-02-27 21:25:00 - cleaning the object tree TB --- 2008-02-27 21:25:06 - cvsupping the source tree TB --- 2008-02-27 21:25:06 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-02-27 21:25:11 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 21:25:11 - cd /src TB --- 2008-02-27 21:25:11 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 21:25:12 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 21:36:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 21:36:14 - ERROR: failed to build world TB --- 2008-02-27 21:36:14 - tinderbox aborted TB --- 479.60 user 59.62 system 673.64 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 21:38:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA7A6106566C; Wed, 27 Feb 2008 21:38:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC808FC14; Wed, 27 Feb 2008 21:38:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLcRmQ090301; Wed, 27 Feb 2008 16:38:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLcRlp035788; Wed, 27 Feb 2008 16:38:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 04E1473039; Wed, 27 Feb 2008 16:38:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227213827.04E1473039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 16:38:26 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 21:38:28 -0000 TB --- 2008-02-27 21:25:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 21:25:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-02-27 21:25:00 - cleaning the object tree TB --- 2008-02-27 21:25:06 - cvsupping the source tree TB --- 2008-02-27 21:25:06 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-02-27 21:25:12 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 21:25:12 - cd /src TB --- 2008-02-27 21:25:12 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 21:25:13 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 21:38:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 21:38:26 - ERROR: failed to build world TB --- 2008-02-27 21:38:26 - tinderbox aborted TB --- 584.80 user 68.28 system 806.05 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 21:49:10 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21FCD1065673; Wed, 27 Feb 2008 21:49:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id EA2AD8FC14; Wed, 27 Feb 2008 21:49:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLn9L0091333; Wed, 27 Feb 2008 16:49:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLoC2K013896; Wed, 27 Feb 2008 16:50:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 213CE73039; Wed, 27 Feb 2008 16:49:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227214909.213CE73039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 16:49:09 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 21:49:10 -0000 TB --- 2008-02-27 21:36:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 21:36:14 - starting HEAD tinderbox run for i386/i386 TB --- 2008-02-27 21:36:14 - cleaning the object tree TB --- 2008-02-27 21:36:23 - cvsupping the source tree TB --- 2008-02-27 21:36:23 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-02-27 21:36:28 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 21:36:28 - cd /src TB --- 2008-02-27 21:36:28 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 21:36:29 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 21:49:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 21:49:09 - ERROR: failed to build world TB --- 2008-02-27 21:49:09 - tinderbox aborted TB --- 537.60 user 60.27 system 774.41 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 21:51:30 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22C42106567D; Wed, 27 Feb 2008 21:51:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E834C8FC1B; Wed, 27 Feb 2008 21:51:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLpTju056794; Wed, 27 Feb 2008 16:51:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RLpT1W053898; Wed, 27 Feb 2008 16:51:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D9A7473039; Wed, 27 Feb 2008 16:51:28 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080227215128.D9A7473039@freebsd-current.sentex.ca> Date: Wed, 27 Feb 2008 16:51:28 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 21:51:30 -0000 TB --- 2008-02-27 21:38:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-27 21:38:27 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-02-27 21:38:27 - cleaning the object tree TB --- 2008-02-27 21:38:36 - cvsupping the source tree TB --- 2008-02-27 21:38:36 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-02-27 21:38:44 - building world (CFLAGS=-O -pipe) TB --- 2008-02-27 21:38:44 - cd /src TB --- 2008-02-27 21:38:44 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 27 21:38:45 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/clrerr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fclose.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fcloseall.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/fdopen.c: In function 'fdopen': /src/lib/libc/stdio/fdopen.c:67: error: 'SHRT_MAX' undeclared (first use in this function) /src/lib/libc/stdio/fdopen.c:67: error: (Each undeclared identifier is reported only once /src/lib/libc/stdio/fdopen.c:67: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-27 21:51:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-27 21:51:28 - ERROR: failed to build world TB --- 2008-02-27 21:51:28 - tinderbox aborted TB --- 537.79 user 60.41 system 781.72 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 22:33:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3B82106566C; Wed, 27 Feb 2008 22:33:34 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 599EF8FC29; Wed, 27 Feb 2008 22:33:33 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [192.168.1.101] (cpe-74-77-179-53.buffalo.res.rr.com [74.77.179.53]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id m1RMXM5L045340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 17:33:26 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-stable , freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BrJ9kCmS1J0O8tSNg0KO" Date: Wed, 27 Feb 2008 17:32:55 -0500 Message-Id: <1204151575.84335.3.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1335; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=0.6 required=5.0 tests=RCVD_IN_PBL,RDNS_DYNAMIC autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: Subject: FreeBSD 7.0-RELEASE Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 22:33:35 -0000 --=-BrJ9kCmS1J0O8tSNg0KO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just in case some interested parties are not subscribed to the freebsd-announce mailing list... FreeBSD 7.0-RELEASE has been formally released. If you would like to see the release announcement it's here: http://www.freebsd.org/releases/7.0R/announce.html On behalf of the FreeBSD Project thanks for your interest in FreeBSD. We hope you enjoy the new release. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-BrJ9kCmS1J0O8tSNg0KO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkfF5Q0ACgkQ/G14VSmup/ZweACfbBo3dWz1a35SC5GgHijOTC6V eNQAn3zl6bBey/PYE4m9ahNXIILtFpWa =RJtB -----END PGP SIGNATURE----- --=-BrJ9kCmS1J0O8tSNg0KO-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 22:44:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71FDA106566C for ; Wed, 27 Feb 2008 22:44:50 +0000 (UTC) (envelope-from arne@rfc2549.org) Received: from mail.blinkt.de (mail.blinkt.de [88.198.169.219]) by mx1.freebsd.org (Postfix) with ESMTP id 2FA3A8FC19 for ; Wed, 27 Feb 2008 22:44:50 +0000 (UTC) (envelope-from arne@rfc2549.org) Received: from dslb-084-062-195-098.pools.arcor-ip.net ([84.62.195.98] helo=styx.local) by mail.blinkt.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUUcv-000E7z-60 for freebsd-current@freebsd.org; Wed, 27 Feb 2008 23:19:49 +0100 Message-ID: <47C5E204.9080003@rfc2549.org> Date: Wed, 27 Feb 2008 23:19:48 +0100 From: Arne Schwabe User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Specific Swap Usage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 22:44:50 -0000 Hi, is there any way to look what programs are swapped out and how much memory they use? Looking at SIZE in top is just a wild guess. One server here grows in swap usage and panics eventuelly when all swap is usage. Swap usage is growing slowly (100 MB /week ) but it is growing and see no way to get what really uses swap :( (Read man ps three times already :/) Arne From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 23:13:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A781065EA6 for ; Wed, 27 Feb 2008 23:13:55 +0000 (UTC) (envelope-from dirkarlt@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id C47088FC17 for ; Wed, 27 Feb 2008 23:13:54 +0000 (UTC) (envelope-from dirkarlt@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2306711fgg.35 for ; Wed, 27 Feb 2008 15:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references:from:date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=lMaCiudWR82/w1aXC6YrMsS8hPZGvCLsMDyokZiXHWs=; b=sYcmE8TVPGpHH+Qn8BxP9QXyz6H2oGkDYG+xktv812IzoXOwSV3BK41tkHa+aXWjaas1kMs1rDry8TchW5WWwEB2MWIFd4UM0hVf+FtRX+qo7PAtHiD6Lo4apIl0qAw+swbEd/8HSo0/jKvgPm86kfs9WmhYVJWpLE0fqMAd4Q8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:from:date:in-reply-to:message-id:user-agent:mime-version:content-type; b=HBnPBjBVm5Occw1fPmc0Yk5RADJ37k5LUwSNwjQnxdvnxrZmSLLaOq0Ei2MDv1pqwnulfPVhWgixeUG3Tt/CwR6sG2OMar8W9nVybh9RKBGcUFXTamP8Y33t4AfqmGUH36MaSkdMvOxFWK/ysW5pwMMQJHVaq16RVPtMQYB3kmc= Received: by 10.86.87.5 with SMTP id k5mr6782882fgb.51.1204152579216; Wed, 27 Feb 2008 14:49:39 -0800 (PST) Received: from tm4000.mjhp.net.mjhp.net ( [82.82.186.253]) by mx.google.com with ESMTPS id j9sm15321176mue.6.2008.02.27.14.49.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Feb 2008 14:49:38 -0800 (PST) To: Ken Smith References: <1204151575.84335.3.camel@neo.cse.buffalo.edu> From: Dirk Arlt Date: Wed, 27 Feb 2008 23:50:37 +0100 In-Reply-To: <1204151575.84335.3.camel@neo.cse.buffalo.edu> (Ken Smith's message of "Wed\, 27 Feb 2008 17\:32\:55 -0500") Message-ID: <86ve4a2ev6.fsf@tm4000.mjhp.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 7.0-RELEASE Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Feb 2008 23:13:55 -0000 Ken Smith writes: [...] > http://www.freebsd.org/releases/7.0R/announce.html > > On behalf of the FreeBSD Project thanks for your interest in FreeBSD. > We hope you enjoy the new release. > Thanks for all your work (done and to be done). Dirk From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:23:49 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25359106567B for ; Thu, 28 Feb 2008 00:23:49 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id B36318FC15 for ; Thu, 28 Feb 2008 00:23:47 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id E975B3F89E1 for ; Thu, 28 Feb 2008 01:05:00 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 779B8381F36 for ; Wed, 27 Feb 2008 22:31:52 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 67D0F9BF12 for ; Wed, 27 Feb 2008 21:31:37 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 59CEA405B; Wed, 27 Feb 2008 22:31:37 +0100 (CET) Date: Wed, 27 Feb 2008 22:31:37 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20080227213137.GG56090@obiwan.tataz.chchile.org> References: <20080226225652.GE56090@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <20080226225652.GE56090@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Subject: Re: Wireless adapter associated, rx ok, tx ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 00:23:49 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 26, 2008 at 11:56:52PM +0100, Jeremie Le Hen wrote: > Hi list, > > I'm running -CURRENT from 2007/02/22. > > I'm currently on holidays. There is a wireless network protected with > WEP. I can successfully associate to the AP, but dhclient(8) won't > succeed in getting an IP address. I also tried to configure an IP > address manually and ping another computer on the network without > success. Nonetheless, I can see the traffic from other computers with > tcpdump(8). > > This behaviour occurs with if_ral and if_wi. > I tried with a Linux live CD (from which I'm writing this e-mail), and > it works. More information coming. You will find my dmesg attached (not verbose). Note there are a couple of LOR, especially one related to ral0. Here are the modules I loaded (either from loader(8) or manually): % Id Refs Address Size Name % 1 78 0xc0400000 4eddd8 kernel (/boot/kernel/kernel) % 2 1 0xc08f5000 6d434 acpi.ko (/boot/kernel/acpi.ko) % 3 1 0xc0963000 6780 cardbus.ko (/boot/kernel/cardbus.ko) % 4 3 0xc096a000 2b40 exca.ko (/boot/kernel/exca.ko) % 5 1 0xc096d000 dd6c cbb.ko (/boot/kernel/cbb.ko) % 6 8 0xc097b000 2e7d8 wlan.ko (/boot/kernel/wlan.ko) % 7 1 0xc09aa000 5838 wlan_scan_sta.ko (/boot/kernel/wlan_scan_sta.ko) % 8 1 0xc09b0000 495c wlan_tkip.ko (/boot/kernel/wlan_tkip.ko) % 9 1 0xc09b5000 3204 wlan_wep.ko (/boot/kernel/wlan_wep.ko) % 10 1 0xc3d46000 24000 linux.ko (/boot/kernel/linux.ko) % 11 1 0xc3f83000 8000 umass.ko (/boot/kernel/umass.ko) % 12 1 0xc3f8b000 22000 usb.ko (/boot/kernel/usb.ko) % 13 1 0xc4046000 19000 if_ral.ko (/boot/kernel/if_ral.ko) % 14 1 0xc4076000 f000 if_iwi.ko (/boot/kernel/if_iwi.ko) % 15 1 0xc4085000 30000 iwi_bss.ko (/boot/kernel/iwi_bss.ko) % 16 1 0xc40b5000 1d000 if_wi.ko (/boot/kernel/if_wi.ko) % 17 1 0xc40d2000 d000 pccard.ko (/boot/kernel/pccard.ko) I attached a "screenshot" when dhclient(8) is run for wi0, with net.wlan.0.debug=0xffffffff. Likewise, there is the debug output for ral0. Although the outcome is the same -- no packet seems to be sent -- debug messages are very different. Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=wi0_debug jarjarbinks:~:140# ifconfig wi0 wi0: flags=8843 metric 0 mtu 1500 ether 00:02:2d:4b:b9:20 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: associated ssid XXXXXXXXXX channel 10 (2457 Mhz 11b) bssid XX:XX:XX:XX:XX:XX stationname "FreeBSD WaveLAN/IEEE node" authmode OPEN privacy MIXED deftxkey UNDEF wepkey 1:104-bit bmiss 7 scanvalid 60 bintval 0 jarjarbinks:~:141# sysctl net.wlan.0.debug=0xffffffff net.wlan.0.debug: 0 -> 2147483647 jarjarbinks:~:142# jarjarbinks:~:142# jarjarbinks:~:142# dhclient wi0 wi0: ieee80211_newstate: RUN -> INIT wi0: ieee80211_ref_node (ieee80211_send_mgmt:1574) 0xc4b28000 refcnt 3 wi0: [XX:XX:XX:XX:XX:XX] send station disassociate (reason 8) [XX:XX:XX:XX:XX:XX] send disassoc on channel 10 wi0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 wi0: ieee80211_node_table_reset station table wi0: ieee80211_free_allnodes_locked: free all nodes in station table wi0: node_reclaim: remove 0xc4b28000 from station table, refc nt 1 wi0: ieee80211_setup_node 0xc4bb9000<00:02:2d:4b:b9:20> in station table wi0: _ieee80211_free_node 0xc4b28000 in table wi0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 5 wi0: ieee80211_newstate: INIT -> RUN wi0: ieee80211_newstate: invalid transition wi0: [ff:ff:ff:ff:ff:ff] no default transmit key (ieee80211_encap) deftxkey 65535 DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 11 wi0: [ff:ff:ff:ff:ff:ff] no default transmit key (ieee80211_encap) deftxkey 65535 DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 12 wi0: [ff:ff:ff:ff:ff:ff] no default transmit key (ieee80211_encap) deftxkey 65535 (Note that setting deftxkey for wi0, does not change anything.) --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=ral0_debug ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: sta_roam_check: currssi 47 currate 2 roamrssi 14 roamrate 10 ral0: macaddr bssid chan rssi rate flag wep essid + XX:XX:XX:XX:XX:XX XX:XX:XX:XX:XX:XX 10 47 54M ess wep "XXXXXXXXXXXX" ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 49 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 49 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 49 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: [ff:ff:ff:ff:ff:ff] no default transmit key (ieee80211_encap) deftxkey 65535 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: [ff:ff:ff:ff:ff:ff] no default transmit key (ieee80211_encap) deftxkey 65535 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 44 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: sta_roam_check: currssi 46 currate 2 roamrssi 14 roamrate 10 ral0: macaddr bssid chan rssi rate flag wep essid + XX:XX:XX:XX:XX:XX XX:XX:XX:XX:XX:XX 10 46 54M ess wep "XXXXXXXXXXXX" ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 45 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 46 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 48 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 ral0: received beacon from XX:XX:XX:XX:XX:XX rssi 47 [ral0:XX:XX:XX:XX:XX:XX] discard unhandled information element, id 47, len 1 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=dmesg Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #22: Fri Feb 22 14:08:23 CET 2008 root@jarjarbinks.octobre.int:/usr/obj/usr/src/sys/JARJARBINKS WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.73GHz (1729.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff Features2=0x180 AMD Features=0x100000 real memory = 1072168960 (1022 MB) avail memory = 1041059840 (992 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) unknown: I/O range not supported Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0-0x3ff on acpi0 device_attach: acpi_hpet0 attach returned 12 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xd0000000-0xd7ffffff,0xc8100000-0xc810ffff irq 16 at device 0.0 on pci1 pcib2: irq 17 at device 28.0 on pci0 pci9: on pcib2 pcib3: irq 16 at device 28.1 on pci0 pci10: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci2: on pcib4 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.3 (no driver attached) pci0: at device 29.7 (no driver attached) pcib5: at device 30.0 on pci0 pci6: on pcib5 cbb0: mem 0xc8216000-0xc8216fff irq 18 at device 1.0 on pci6 cardbus0: on cbb0 cbb0: [ITHREAD] pci6: at device 1.2 (no driver attached) pci6: at device 1.3 (no driver attached) pci6: at device 3.0 (no driver attached) pci6: at device 8.0 (no driver attached) pci0: at device 30.2 (no driver attached) pci0: at device 30.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: flags 0x400 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 250 acpi_hpet0: iomem 0-0x3ff on acpi0 device_attach: acpi_hpet0 attach returned 12 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcdfff,0xce000-0xcf7ff,0xe0000-0xe17ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1729014723 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept, logging unlimited ad0: DMA limited to UDMA33, controller found non-ATA66 cable ad0: 114473MB at ata0-master UDMA33 acd0: DVDR at ata0-slave UDMA33 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. ral0: mem 0xc821a000-0xc821bfff irq 18 at device 0.0 on cardbus0 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 ral0: Ethernet address: 00:17:31:45:d2:d6 ral0: [ITHREAD] ral0: link state changed to UP ral0: promiscuous mode enabled iwi0: mem 0xc8218000-0xc8218fff irq 17 at device 3.0 on pci6 iwi0: Ethernet address: 00:12:f0:2c:f3:6e iwi0: [ITHREAD] iwi0: link state changed to UP iwi0: radio turned off iwi0: link state changed to DOWN iwi0: link state changed to UP iwi0: radio turned off iwi0: link state changed to DOWN pccard0: <16-bit PCCard bus> on cbb0 wi0: at port 0x100-0x13f irq 18 function 0 config 1 on pccard0 wi0: [ITHREAD] wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (7.52.1) wi0: Ethernet address: 00:02:2d:4b:b9:20 lock order reversal: 1st 0xc3b1ee28 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2061 2nd 0xc3c65394 devfsmount (devfsmount) @ /usr/src/sys/fs/devfs/devfs_vnops.c:201 KDB: stack backtrace: db_trace_self_wrapper(c0772c00,e249fbbc,c0572066,c0774fe6,c3c65394,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0774fe6,c3c65394,c0766f33,c0766f33,c0766f74,...) at kdb_backtrace+0x29 witness_checkorder(c3c65394,9,c0766f74,c9,c7,...) at witness_checkorder+0x6d6 _sx_xlock(c3c65394,0,c0766f74,c9,c3c65394,...) at _sx_xlock+0x7d devfs_allocv(c3c53680,c3c73000,e249fc28,c39bccc0,c077ad0d,...) at devfs_allocv+0x14e devfs_root(c3c73000,2,c0839ad8,c39bccc0,ca,...) at devfs_root+0x51 set_rootvnode(c0839ac0,0,c077ad0d,5f4,c05afc90,...) at set_rootvnode+0x2b vfs_mountroot(c07ee410,4,c076ac3d,260,10000900,...) at vfs_mountroot+0x356 start_init(0,e249fd38,c076c59c,30c,c39b9ab0,...) at start_init+0x65 fork_exit(c0501110,0,e249fd38) at fork_exit+0xc5 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe249fd70, ebp = 0 --- Trying to mount root from ufs:/dev/ad0s1a lock order reversal: 1st 0xc3b1e9e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2061 2nd 0xc3c73000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c0772c00,e249f9d4,c0572066,c0774fe6,c3c73000,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0774fe6,c3c73000,c077ae0b,c077ae0b,c077b3a8,...) at kdb_backtrace+0x29 witness_checkorder(c3c73000,1,c077b3a8,16c,e249fa14,...) at witness_checkorder+0x6d6 _lockmgr_args(c3c73000,2001,c3c73030,0,ffffffff,...) at _lockmgr_args+0x1e5 vfs_busy(c3c73000,0,0,c39bccc0,e249fb40,...) at vfs_busy+0x1b4 lookup(e249fb2c,c077aabb,c6,bf,c399b82c,...) at lookup+0x7df namei(e249fb2c,c3c73030,1c1,c077ad0d,c077b14a,...) at namei+0x368 kern_unlink(c39bccc0,c077b14a,1,62f,0,...) at kern_unlink+0x40 vfs_mountroot_try(c077b304,c0760a2b,c077b14f,1,c05afc90,...) at vfs_mountroot_try+0x480 vfs_mountroot(c07ee410,4,c076ac3d,260,10000900,...) at vfs_mountroot+0x412 start_init(0,e249fd38,c076c59c,30c,c39b9ab0,...) at start_init+0x65 fork_exit(c0501110,0,e249fd38) at fork_exit+0xc5 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe249fd70, ebp = 0 --- lock order reversal: 1st 0xc39bf044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3111 2nd 0xc3b1e7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2061 KDB: stack backtrace: db_trace_self_wrapper(c0772c00,e249f9cc,c0572066,c0774fe6,c3b1e7c8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0774fe6,c3b1e7c8,c076a5ce,c076a5ce,c077b3a8,...) at kdb_backtrace+0x29 witness_checkorder(c3b1e7c8,1,c077b3a8,80d,e249f9f0,...) at witness_checkorder+0x6d6 _lockmgr_args(c3b1e7c8,3041,c3b1e7f8,0,ffffffff,...) at _lockmgr_args+0x1e5 ffs_lock(e249fa80,c052b044,c07f3354,3041,c3b1e770,...) at ffs_lock+0xa2 VOP_LOCK1_APV(c07c5920,e249fa80,c0760a29,3,c3b1e7f8,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c3b1e770,3041,c077b3a8,80d,0,...) at _vn_lock+0xf7 vget(c3b1e770,3041,c39bccc0,4a9,c1045b00,...) at vget+0x10b vnode_pager_lock(c1045980,0,c078a1ab,127,e249fc18,...) at vnode_pager_lock+0x1ad vm_fault(c39bf000,80d7000,2,8,80d7480,...) at vm_fault+0x1e9 trap_pfault(5,0,c079549c,2c8,c,...) at trap_pfault+0xf5 trap(e249fd38) at trap+0x24d calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfaed0, ebp = 0xbfbfaef0 --- lock order reversal: 1st 0xc406400c ieee80211com (802.11 com lock) @ /usr/src/sys/modules/wlan/../../net80211/ieee80211_scan.c:524 2nd 0xc406541c ral0 (network driver) @ /usr/src/sys/modules/ral/../../dev/ral/rt2560.c:2017 KDB: stack backtrace: db_trace_self_wrapper(c0772c00,e3eaaabc,c0572066,c0774fe6,c406541c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0774fe6,c406541c,c401fb80,c405ccdc,c405caf3,...) at kdb_backtrace+0x29 witness_checkorder(c406541c,9,c405caf3,7e1,e3eaab0c,...) at witness_checkorder+0x6d6 _mtx_lock_flags(c406541c,0,c405caf3,7e1,c07f3354,...) at _mtx_lock_flags+0xbc rt2560_start(c3aa5800,c4064004,e3eaabcc,c0995179,c3aa5800,...) at rt2560_start+0x41 if_start(c3aa5800,0,c09a2065,184,c09a2b47,...) at if_start+0x59 ieee80211_send_nulldata(c406d000,1,20c,c403f400,c3fb7800,...) at ieee80211_send_nulldata+0x1e9 scan_restart(c3fb7800,c4064004,c09a2b47,20c,c3be971c,...) at scan_restart+0xb2 ieee80211_bg_scan(c4064004,b,0,dd313180,4af,...) at ieee80211_bg_scan+0x10c ieee80211_node_timeout(c4064004,0,c077121a,f4,c0556178,...) at ieee80211_node_timeout+0x19 softclock(0,0,c076c81f,46f,c39f7164,...) at softclock+0x269 ithread_loop(c3974a60,e3eaad38,c076c59c,30c,c39b9558,...) at ithread_loop+0x1b5 fork_exit(c051a100,c3974a60,e3eaad38) at fork_exit+0xc5 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe3eaad70, ebp = 0 --- --h31gzZEtNLTqOjlF-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:30:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B22E1065670 for ; Thu, 28 Feb 2008 00:30:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id 1BACE8FC19 for ; Thu, 28 Feb 2008 00:30:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so2719649wfa.7 for ; Wed, 27 Feb 2008 16:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=H5kTFzqcGnLF0hASRr/UI2HfzBaBjiSbg4ACZG6vM08=; b=OSgaC295mPDGFCtbfaIi83D3JExy3iSsAjYRfZI+0Fza+w+BbmdOjyauM0id8H//+n3wRGLL2CD2W3Ewl3KsJj4GJnTNIqIwCHd+8jy+DjnNUDtFOVITq6+m+P4gjtew+EBv13FofIXxvBbARojmjKQBm0FWuQuB8h1F1cA3SSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=GxZq5WCUBYiLNMYrL/t0rMZ9eJMmrI9ryGrKksTNJ/Wwjj2xAy4Qd05PIt9hCIE3ovpQOpFhYg0L3E9Y3qHbHxULTXjKeFs2mRbWAXEW89QudcCqPW6pziuiXgqFEEGUFCYcSeWeoQCRmKp81zV8pMyj87C94I8ztb7tiaz8XyA= Received: by 10.142.52.9 with SMTP id z9mr5924238wfz.201.1204158634729; Wed, 27 Feb 2008 16:30:34 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 24sm15762405wfc.18.2008.02.27.16.30.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Feb 2008 16:30:33 -0800 (PST) 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 m1S0USCj056651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 09:30:28 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1S0URp5056650; Thu, 28 Feb 2008 09:30:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 28 Feb 2008 09:30:27 +0900 From: Pyun YongHyeon To: Mike Tancsa Message-ID: <20080228003027.GA56411@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <20080217112104.X80805@fledge.watson.org> <200802171458.26951.freebsd-current@dino.sk> <200802171517.26965.freebsd-current@dino.sk> <20080218081801.GB14601@cdnetworks.co.kr> <20080222054356.GE30497@cdnetworks.co.kr> <200802260503.m1Q53Jm3050738@lava.sentex.ca> <20080226053423.GB47750@cdnetworks.co.kr> <200802271712.m1RHC6Rx060293@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802271712.m1RHC6Rx060293@lava.sentex.ca> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) 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: Thu, 28 Feb 2008 00:30:35 -0000 On Wed, Feb 27, 2008 at 12:09:42PM -0500, Mike Tancsa wrote: > At 12:34 AM 2/26/2008, Pyun YongHyeon wrote: > > > > > > >Thanks again for your testing! > >An unresolved issue for Milan Obuch's router board still prevent me > >from committing the overhauled one. Unfortunately I still have no > >clue why his hardware does not work even though it has the same > >hardware revision(0x96). > > I found another bug that your version of the driver fixes. Its > fairly easy for me to reproduce now and other people seem to run into > it as well. > > I hooked up 2 boxes with the NICs to a cisco switch with the 2 > interfaces on the same vlan. I then start a continuous ping either > from the other box, or on the box itself. > > boxA# ping boxB > PING 192.168.7.23 (192.168.7.23): 56 data bytes > 64 bytes from 192.168.7.23: icmp_seq=0 ttl=64 time=0.974 ms > 64 bytes from 192.168.7.23: icmp_seq=1 ttl=64 time=0.420 ms > 64 bytes from 192.168.7.23: icmp_seq=2 ttl=64 time=0.427 ms > 64 bytes from 192.168.7.23: icmp_seq=3 ttl=64 time=0.416 ms > 64 bytes from 192.168.7.23: icmp_seq=4 ttl=64 time=0.455 ms > 64 bytes from 192.168.7.23: icmp_seq=5 ttl=64 time=0.405 ms > 64 bytes from 192.168.7.23: icmp_seq=6 ttl=64 time=0.423 ms > 64 bytes from 192.168.7.23: icmp_seq=7 ttl=64 time=0.422 ms > > > ^C > --- 192.168.7.23 ping statistics --- > 66 packets transmitted, 20 packets received, 69.7% packet loss > round-trip min/avg/max/stddev = 0.396/0.476/0.974/0.132 ms > > > While in the middle of the ping, I change the media speed of the port > of the box that is doing the pinging to 10 and then back to auto > boxA# ifconfig vr2 > vr2: flags=8843 metric 0 mtu 1500 > options=b > ether 00:00:24:c9:34:8a > inet 192.168.7.21 netmask 0xffffff00 broadcast 192.168.7.255 > media: Ethernet autoselect (100baseTX ) > status: active > > The nic is now wedged on boxA. I then have to do a ifconfig vr2 down > and ifconfig vr2 up to un wedge it, and in the logs I see the forced reset > > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: Using force reset command. > > ..... HOWEVER, using the updated drivers on your web page, the box > survives this exercise. > > There is the occasional "shutdown error", but I guess thats to be > expected as the physical layer is bouncing up and down. But the main > thing is that the box recovers on its own. > > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: vr_link_task: Tx/Rx shutdown error -- resetting > vr2: link state changed to DOWN > vr2: restarting > vr2: vr_stop: Rx shutdown error > vr2: Using force reset command. > vr2: link state changed to UP > I never thought this kind of testing. It's good to hear vr(4) recovers from the abrupt link change events. I guess this also indicates the overhauled vr(4) can close lots of PR for vr(4). Thanks again. > ---Mike > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:34:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E528F106567C for ; Thu, 28 Feb 2008 00:34:00 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 29BA48FC16; Thu, 28 Feb 2008 00:33:59 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C60177.3050300@FreeBSD.org> Date: Thu, 28 Feb 2008 01:33:59 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Arne Schwabe References: <47C5E204.9080003@rfc2549.org> In-Reply-To: <47C5E204.9080003@rfc2549.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Specific Swap Usage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 00:34:01 -0000 Arne Schwabe wrote: > Hi, > > is there any way to look what programs are swapped out and how much > memory they use? Looking at SIZE in top is just a wild guess. One server > here grows in swap usage and panics eventuelly when all swap is usage. > Swap usage is growing slowly (100 MB /week ) but it is growing and see > no way to get what really uses swap :( (Read man ps three times already :/) > > Arne > _______________________________________________ > 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" > > It shouldn't panic when it runs out of swap, it should just kill the runaway process(es). Kris From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:47:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 679F0106566C for ; Thu, 28 Feb 2008 00:47:50 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by mx1.freebsd.org (Postfix) with ESMTP id 05C2E8FC22 for ; Thu, 28 Feb 2008 00:47:49 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so4682980wri.3 for ; Wed, 27 Feb 2008 16:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=l7FVy/3xrlzXjTI/nmDi2/sdi/MhxSvVFufPyY8eNJM=; b=qwhRtT7+c35VgZTNSqlLtBZVZCfx+1SyJpFozXvi83tNCxlZrtmUZPCNTYt4qET2ugYcOc3npYo001jxAHXpaBjDgVY+ZnLO6zhDtMGFZxVLWNh0PiHg2m1GRt2mOF55QvRlKamNIHR3+PW/yCcXT6vgH2bC0QAVfbdstaNB0X4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pBQMQpXWQa7uMAZPBVxEN0jotRuMR1ubqum81hVCvMkR/7MFri9GaZH9qTcve7pF5mNgVsFKXIJJyEID7ZOy7Yvov6h6/Xgk4U7aL7YTs/UAT3TZtVISjndOo5yhDJwuZYRbAGYcjoO+dZLWEYNg1lVHkI1QtPrzfSDIU7FdI/E= Received: by 10.65.218.15 with SMTP id v15mr12943452qbq.32.1204159667693; Wed, 27 Feb 2008 16:47:47 -0800 (PST) Received: by 10.64.149.8 with HTTP; Wed, 27 Feb 2008 16:47:47 -0800 (PST) Message-ID: <5f67a8c40802271647t6c51078fucd1a6906159a7fec@mail.gmail.com> Date: Thu, 28 Feb 2008 00:47:47 +0000 From: "Zaphod Beeblebrox" To: "Kris Kennaway" In-Reply-To: <47C60177.3050300@FreeBSD.org> MIME-Version: 1.0 References: <47C5E204.9080003@rfc2549.org> <47C60177.3050300@FreeBSD.org> 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: Arne Schwabe , FreeBSD Current Subject: Re: Specific Swap Usage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 00:47:50 -0000 On Thu, Feb 28, 2008 at 12:33 AM, Kris Kennaway wrote: > > It shouldn't panic when it runs out of swap, it should just kill the > runaway process(es). I thought it killed the next process to allocate memory --- which is somewhat random. What happens if the kernel is the next entity to allocate memory? From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:58:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54E4A106566C for ; Thu, 28 Feb 2008 00:58:13 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 04B828FC16 for ; Thu, 28 Feb 2008 00:58:12 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m1S0w9AJ021581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 16:58:12 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47C60721.9090609@errno.com> Date: Wed, 27 Feb 2008 16:58:09 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Jeremie Le Hen References: <20080226225652.GE56090@obiwan.tataz.chchile.org> <20080227213137.GG56090@obiwan.tataz.chchile.org> In-Reply-To: <20080227213137.GG56090@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-SIHOPE-DCC-3-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: Wireless adapter associated, rx ok, tx ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 00:58:13 -0000 Jeremie Le Hen wrote: > On Tue, Feb 26, 2008 at 11:56:52PM +0100, Jeremie Le Hen wrote: > >> Hi list, >> >> I'm running -CURRENT from 2007/02/22. >> >> I'm currently on holidays. There is a wireless network protected with >> WEP. I can successfully associate to the AP, but dhclient(8) won't >> succeed in getting an IP address. I also tried to configure an IP >> address manually and ping another computer on the network without >> success. Nonetheless, I can see the traffic from other computers with >> tcpdump(8). >> >> This behaviour occurs with if_ral and if_wi. >> I tried with a Linux live CD (from which I'm writing this e-mail), and >> it works. >> > > More information coming. You will find my dmesg attached (not verbose). > Note there are a couple of LOR, especially one related to ral0. > > Here are the modules I loaded (either from loader(8) or manually): > % Id Refs Address Size Name > % 1 78 0xc0400000 4eddd8 kernel (/boot/kernel/kernel) > % 2 1 0xc08f5000 6d434 acpi.ko (/boot/kernel/acpi.ko) > % 3 1 0xc0963000 6780 cardbus.ko (/boot/kernel/cardbus.ko) > % 4 3 0xc096a000 2b40 exca.ko (/boot/kernel/exca.ko) > % 5 1 0xc096d000 dd6c cbb.ko (/boot/kernel/cbb.ko) > % 6 8 0xc097b000 2e7d8 wlan.ko (/boot/kernel/wlan.ko) > % 7 1 0xc09aa000 5838 wlan_scan_sta.ko (/boot/kernel/wlan_scan_sta.ko) > % 8 1 0xc09b0000 495c wlan_tkip.ko (/boot/kernel/wlan_tkip.ko) > % 9 1 0xc09b5000 3204 wlan_wep.ko (/boot/kernel/wlan_wep.ko) > % 10 1 0xc3d46000 24000 linux.ko (/boot/kernel/linux.ko) > % 11 1 0xc3f83000 8000 umass.ko (/boot/kernel/umass.ko) > % 12 1 0xc3f8b000 22000 usb.ko (/boot/kernel/usb.ko) > % 13 1 0xc4046000 19000 if_ral.ko (/boot/kernel/if_ral.ko) > % 14 1 0xc4076000 f000 if_iwi.ko (/boot/kernel/if_iwi.ko) > % 15 1 0xc4085000 30000 iwi_bss.ko (/boot/kernel/iwi_bss.ko) > % 16 1 0xc40b5000 1d000 if_wi.ko (/boot/kernel/if_wi.ko) > % 17 1 0xc40d2000 d000 pccard.ko (/boot/kernel/pccard.ko) > > I attached a "screenshot" when dhclient(8) is run for wi0, with > net.wlan.0.debug=0xffffffff. > > Likewise, there is the debug output for ral0. Although the outcome is > the same -- no packet seems to be sent -- debug messages are very > different. > > > jarjarbinks:~:140# ifconfig wi0 > wi0: flags=8843 metric 0 mtu 1500 > ether 00:02:2d:4b:b9:20 > media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) > status: associated > ssid XXXXXXXXXX channel 10 (2457 Mhz 11b) bssid XX:XX:XX:XX:XX:XX > stationname "FreeBSD WaveLAN/IEEE node" > authmode OPEN privacy MIXED deftxkey UNDEF wepkey 1:104-bit bmiss 7 > scanvalid 60 bintval 0 > jarjarbinks:~:141# sysctl net.wlan.0.debug=0xffffffff > net.wlan.0.debug: 0 -> 2147483647 > jarjarbinks:~:142# > jarjarbinks:~:142# > jarjarbinks:~:142# dhclient wi0 > wi0: ieee80211_newstate: RUN -> INIT > wi0: ieee80211_ref_node (ieee80211_send_mgmt:1574) 0xc4b28000 refcnt 3 > wi0: [XX:XX:XX:XX:XX:XX] send station disassociate (reason 8) > [XX:XX:XX:XX:XX:XX] send disassoc on channel 10 > wi0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 > wi0: ieee80211_node_table_reset station table > wi0: ieee80211_free_allnodes_locked: free all nodes in station table > wi0: node_reclaim: remove 0xc4b28000 from station table, refc > nt 1 > wi0: ieee80211_setup_node 0xc4bb9000<00:02:2d:4b:b9:20> in station table > wi0: _ieee80211_free_node 0xc4b28000 in table > wi0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 > DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 5 > wi0: ieee80211_newstate: INIT -> RUN > wi0: ieee80211_newstate: invalid transition > wi0: [ff:ff:ff:ff:ff:ff] no default transmit key (ieee80211_encap) deftxkey 65535 > DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 11 > wi0: [ff:ff:ff:ff:ff:ff] no default transmit key (ieee80211_encap) deftxkey 65535 > DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 12 > wi0: [ff:ff:ff:ff:ff:ff] no default transmit key (ieee80211_encap) deftxkey 65535 > > > (Note that setting deftxkey for wi0, does not change anything.) I don't believe you that setting the key doesn't change anything. Your outbound traffic is being dropped because there is no tx keyid specified. I note the ral log likewise says you have no deftxkey setup. wlanstats will show you how many frames are being dropped because the system doesn't know what key to use to encrypt traffic. Sam From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 01:20:36 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D996106566B for ; Thu, 28 Feb 2008 01:20:36 +0000 (UTC) (envelope-from arne@rfc2549.org) Received: from mail.blinkt.de (mail.blinkt.de [88.198.169.219]) by mx1.freebsd.org (Postfix) with ESMTP id 53FE78FC15 for ; Thu, 28 Feb 2008 01:20:36 +0000 (UTC) (envelope-from arne@rfc2549.org) Received: from dslb-084-062-195-098.pools.arcor-ip.net ([84.62.195.98] helo=styx.local) by mail.blinkt.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUXRq-000GxC-SX; Thu, 28 Feb 2008 02:20:34 +0100 Message-ID: <47C60C62.9090901@rfc2549.org> Date: Thu, 28 Feb 2008 02:20:34 +0100 From: Arne Schwabe User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Zaphod Beeblebrox References: <47C5E204.9080003@rfc2549.org> <47C60177.3050300@FreeBSD.org> <5f67a8c40802271647t6c51078fucd1a6906159a7fec@mail.gmail.com> In-Reply-To: <5f67a8c40802271647t6c51078fucd1a6906159a7fec@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Specific Swap Usage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 01:20:36 -0000 Zaphod Beeblebrox schrieb: > > > On Thu, Feb 28, 2008 at 12:33 AM, Kris Kennaway > wrote: > > > It shouldn't panic when it runs out of swap, it should just kill the > runaway process(es). > > > I thought it killed the next process to allocate memory --- which is > somewhat random. What happens if the kernel is the next entity to > allocate memory? Well swap is on a encrypted geli parition. It does not really recall the exact message but googling suggested a bad hard disk. But the disks (gmirror pair) are fine. The machine question was a 6.3-box. I made the mistake to from boot from a 7.0 livedisk that updated my gmirror labels I were forced to upgrade to 7.0. If there is currently no ways to see which processes allocates how much swap space are there any pointers where to look to implement such a feature? Arne From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 01:27:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C10CA1065670 for ; Thu, 28 Feb 2008 01:27:01 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from mail1.webmaster.com (mail1.webmaster.com [216.152.64.169]) by mx1.freebsd.org (Postfix) with ESMTP id A08C48FC1F for ; Thu, 28 Feb 2008 01:27:01 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from however by webmaster.com (MDaemon.PRO.v8.1.3.R) with ESMTP id md50001914782.msg for ; Wed, 27 Feb 2008 17:18:04 -0800 From: "David Schwartz" To: "FreeBSD Current" Date: Wed, 27 Feb 2008 17:16:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <47C5E204.9080003@rfc2549.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Authenticated-Sender: joelkatz@webmaster.com X-Spam-Processed: mail1.webmaster.com, Wed, 27 Feb 2008 17:18:04 -0800 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 206.171.168.138 X-Return-Path: davids@webmaster.com X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mail1.webmaster.com, Wed, 27 Feb 2008 17:18:06 -0800 Subject: RE: Specific Swap Usage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davids@webmaster.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 01:27:01 -0000 > is there any way to look what programs are swapped out and how much > memory they use? Looking at SIZE in top is just a wild guess. There are really only two reasons SIZE might not do what you want, and it's quite possible neither applies. In which case, you should use SIZE. 1) A process may have mappings that don't use nearly as much physical memory or swap space as the mapping might suggest. Programs that 'mmap' large files or use weird sparse arrays may do this. If you know a program doesn't do this, this isn't a problem. 2) SIZE doesn't distinguish between physical memory and swap. But there's really no logical reason you should care. The OS can always put something in swap in physical memory and something in physical memory in swap. What you are really running out of is swap plus physical memory anyway. (For example, if a program relinquished 16MB of physical memory, that would help you at least as much as it relinquishing 16MB of swap.) > One server > here grows in swap usage and panics eventuelly when all swap is usage. > Swap usage is growing slowly (100 MB /week ) but it is growing and see > no way to get what really uses swap :( (Read man ps three times > already :/) Is SIZE rising for this process too? Odds are it is, and you should try to figure out why. If it turns out to be something harmless, that's fine. But odds are very high this will point the way to your problem. If all else fails, you can parse /proc//map to figure out what mappings the process has and what type they are. This will allow you to subtract mmap'ed files that use vm space but not swap+physmem. DS From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 03:08:33 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4AB71065672; Thu, 28 Feb 2008 03:08:33 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5BD6C8FC15; Thu, 28 Feb 2008 03:08:33 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id A7C389B742; Thu, 28 Feb 2008 03:44:05 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.110] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 372899B649; Thu, 28 Feb 2008 03:44:02 +0100 (CET) From: Marko Zec To: Kris Kennaway Date: Thu, 28 Feb 2008 03:43:57 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <47C494B5.2040306@elischer.org> <47C49FAA.1020605@FreeBSD.org> In-Reply-To: <47C49FAA.1020605@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802280343.57576.zec@icir.org> Cc: Marko Zec , Brooks Davis , Andre Oppermann , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 03:08:34 -0000 On Wednesday 27 February 2008 00:24:26 Kris Kennaway wrote: > Julian Elischer wrote: > > Kris Kennaway wrote: > >> Julian Elischer wrote: > >>> Andre Oppermann wrote: > >>>> Brooks Davis wrote: > >>>>> On Mon, Feb 25, 2008 at 08:44:56PM -0800, Julian Elischer wrote: > >>>>>> At some stage in the next few weeks I will be trying to commit > >>>>>> Marco Zec's vimage code to -current. (only 'trying' not > >>>>>> for technical reasons, but political). > >>>> > >>>> ... > >>>> > >>>>>> Why now? > >>>>>> The code is in a shape where teh compiled out version of hte > >>>>>> system is stable. In the compiled in version, it is functional > >>>>>> enough to provide nearly all of what people want. It needs > >>>>>> people with other interests to adapt it to their purposes and > >>>>>> use it so that it can become a solid product for future > >>>>>> releases. > >>>>> > >>>>> The website has a snapshot with a date over a month old and > >>>>> many comments about unstable interfaces. I've seen zero > >>>>> reports of substantial testing... > >>>> > >>>> What about locking and SMP scalability? Any new choke points? > >>> > >>> not that I've seen. > >> > >> That's a less than resounding endorsement :) > > > > do the 10Gb ethernet adapters have any major problems? > > are you willing to answer "no"? > > should we then rip them from the tree? > > Those are small, isolated components, so hardly the same thing as a > major architectural change that touches every part of the protocol > stack. > > But if someone came along and said "I am going to replace the 10ge > drivers, but I dunno how well they perform" I'd say precisely the > same thing. > > Presumably someone (if not you, then Marko) has enough of a grasp of > the architectural changes being proposed to comment about what > changes (if any) were made to synchronisation models, and whether > there are new sources of performance overhead introduced. > > That person can answer Andre's question. OK first my appologies to everybody for being late in jumping into this thread... I'll attempt to address a few questions rised so far in a random order, but SMP scalability definitely tops the list... I think it's safe to assume that network stack instances / vimages will have lifetime frequencies similar to those of jails, i.e. once they get instantiated, in typical applications vimages would remain static over extended periods of time, rather than created and teared off thousands of times per second like TCP sessions or sockets in general. Hence, synchronizing access to global vimage or vnet lists can be probably accomplished using rmlocks which are essentially free for read-only consumers. The current code in p4 still uses a handcrafted shared / exclusive refcounted locking scheme with refcounts protected by a spinlock, since in 7.0 we don't have rmlocks yet, but I'll try converting those to rmlocks in the "official" p4 vimage branch which is tracking HEAD. Another thing to note is that the frequency of read-only iterations over vnets is also quite low - mostly this needs to be done only in slowtimo(), fasttimo() and drain() networking handlers, i.e. only a couple of times per second. All iteration points are easy to fgrep for in the code given that they are always implemented using VNET_ITERLOOP macros, which simply vanish away when the kernel is compiled without options VIMAGE. But most importantly on the performance critical datapaths (i.e. socket - TCP - IP - link layer - device drivers, and vice versa) no additional synchronization points / bottlenecks were introduced. In fact, the framework opens up the possibility to replicate some of the existing choked locks over multiple vnets, potentially reducing contention in cases where load would be evenly spread over multiple vimages / vnets. Other people have asked about vimages and jails: yes it is possible to run multiple jails inside a vimage / vnet, with the original semantics of jails completely preserved. Non-developers accessing the code: after freebsd.org's p4 to anoncvs autosyncer died last summer I've tried posting source tarballs every few weeks on the project's somewhat obscure web site (that Julian has advertised every now and then on this list): http://imunes.net/virtnet/ I've just dumped a diff against -HEAD there, and will post new tarballs in a few minutes as well. Impact of the changes on device drivers: in general no changes were needed at the device driver layer, as drivers do not need to be aware that they are running on a virtualized kernel. Each NICs is logically attached to one and only one network stack instance at a time, and it receives data from upper layers and feeds the upper layers with mbufs in exactly the same manner as it does on the standard kernel. It is the link layer that demultiplexes the incoming traffic to the appropriate stack instance... Overall, there's a lot of cleanup and possibly restructuring work left to be done on the vimage code in p4, with documenting the new interfaces probably being the top priority. I'm glad to see such a considerable amount of (sudden) interest for pushing this code into the main tree, so now being smoked out of my rathole I'll be happy to work with Julian and other folks to bring the vimage code closer to CVS and help maintaining it one way or another once it hopefully gets there, be it weeks or months until we reach that point - the sooner the better of course... Cheers, Marko From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 03:48:33 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EABD61065671; Thu, 28 Feb 2008 03:48:33 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 96D258FC21; Thu, 28 Feb 2008 03:48:33 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 1C6179B64F; Thu, 28 Feb 2008 04:48:32 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.110] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 6C4349B649; Thu, 28 Feb 2008 04:48:31 +0100 (CET) From: Marko Zec To: "Bjoern A. Zeeb" Date: Thu, 28 Feb 2008 04:48:26 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <47C4CDE6.6040509@elischer.org> <20080227092902.Q94494@maildrop.int.zabbadoz.net> In-Reply-To: <20080227092902.Q94494@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802280448.26440.zec@icir.org> Cc: Brooks Davis , Marko Zec , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 03:48:34 -0000 On Wednesday 27 February 2008 10:30:50 Bjoern A. Zeeb wrote: > On Tue, 26 Feb 2008, Julian Elischer wrote: > > replying to a random mail: > > so could you provide a patch somewhere to fetch (better not post it > as I expect it to be huge) of the vimage branch to todays HEAD so > that everyone could see the changes w/o having to have p4 access? http://imunes.net/virtnet/head_vimage_20080226.diff Marko From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 04:47:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3EFA106566C for ; Thu, 28 Feb 2008 04:47:00 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57003.mail.re3.yahoo.com (web57003.mail.re3.yahoo.com [66.196.97.107]) by mx1.freebsd.org (Postfix) with SMTP id 312528FC13 for ; Thu, 28 Feb 2008 04:47:00 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 85593 invoked by uid 60001); 28 Feb 2008 04:46:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=m+cr8gOjyen9ZCTyMXMXJHC7QtrJtmKW/n3jM/h2V8cZrafwbrln9UMJNlMpl3fetTJ89H4cg+nXnj1XL0J7IV9DOiCSOto3ssKmXH4GJo2uudhWItXDjrg4FzovS4YgXRmbmMVeXa6PhANukKYbV5FEADquuaKN7PLOfSDxXbg=; X-YMail-OSG: o4._S.8VM1ly5IYmgZP3MVBrs1OmH1DCenXzPGJU3cy2VpIxQq2yhlA4nseCBkrg5F5DiTu2z_17X6_yjiCBhn.S9SiUluiesJDpRkkkQmALRtrMbHabGQ-- Received: from [165.21.154.14] by web57003.mail.re3.yahoo.com via HTTP; Wed, 27 Feb 2008 20:46:59 PST Date: Wed, 27 Feb 2008 20:46:59 -0800 (PST) From: Unga To: freebsd-current@freebsd.org In-Reply-To: <1204151575.84335.3.camel@neo.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <376506.84980.qm@web57003.mail.re3.yahoo.com> Subject: Re: FreeBSD 7.0-RELEASE Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 04:47:00 -0000 Congratulations. A star is born. Thanks for everybody who tirelessly worked on FreeBSD to realize the dream. You guys/gals will never imaging how FreeBSD 7.X is going to revolutionize the world. Good luck to FreeBSD. Best Regards Unga --- Ken Smith wrote: > > Just in case some interested parties are not > subscribed to the > freebsd-announce mailing list... FreeBSD > 7.0-RELEASE has been formally > released. If you would like to see the release > announcement it's here: > > http://www.freebsd.org/releases/7.0R/announce.html > > On behalf of the FreeBSD Project thanks for your > interest in FreeBSD. > We hope you enjoy the new release. > > -- > Ken > Smith > - From there to here, from here to | > kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | > ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 06:05:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FC80106566B for ; Thu, 28 Feb 2008 06:05:05 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5A88FC18 for ; Thu, 28 Feb 2008 06:05:04 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-72-86-144.dsl.telstraclear.net [121.72.86.144]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0JWX004YNQ8E1A00@smtp5.clear.net.nz>; Thu, 28 Feb 2008 19:05:03 +1300 (NZDT) Date: Thu, 28 Feb 2008 19:04:56 +1300 From: Mark Kirkwood In-reply-to: <1204151575.84335.3.camel@neo.cse.buffalo.edu> To: Ken Smith Message-id: <47C64F08.5030005@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <1204151575.84335.3.camel@neo.cse.buffalo.edu> User-Agent: Thunderbird 2.0.0.9 (X11/20071203) Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 7.0-RELEASE Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 06:05:05 -0000 Ken Smith wrote: > Just in case some interested parties are not subscribed to the > freebsd-announce mailing list... FreeBSD 7.0-RELEASE has been formally > released. If you would like to see the release announcement it's here: > > http://www.freebsd.org/releases/7.0R/announce.html > > On behalf of the FreeBSD Project thanks for your interest in FreeBSD. > We hope you enjoy the new release. > > Thanks guys - much appreciated by those of us that use it as our everyday os! ... upgrading from 6.3 stable as we speak... regards Mark From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 11:19:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 759141065670 for ; Thu, 28 Feb 2008 11:19:43 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: from web33701.mail.mud.yahoo.com (web33701.mail.mud.yahoo.com [68.142.201.198]) by mx1.freebsd.org (Postfix) with SMTP id 203248FC1A for ; Thu, 28 Feb 2008 11:19:43 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: (qmail 58822 invoked by uid 60001); 28 Feb 2008 11:19:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=X/0q11mADXuXQRCJZtg+G5B6JvW4IIVZUCnDV31xRUOvuBhfu5Bj58Yt17sBGvkD2nLfG2im4lu24ufo8Oa9CFXmzl5r+bJtiLka1eNRO2qWf1qDdK3YL0HKErMx1As7vdT+x3B2peKqfeA2yaMVlhUlJ/q6HmqQSnj2nwoDDQw=; X-YMail-OSG: Wn7HHesVM1nPQWJXyAo7p3CShyE0MOZM1kh0PKU3ilamUR0iFpEwT95ICs5Q97d5QywXpu6h0c69H_57zG_8Pn872q_CG.BIreLF6BnHekWG4H4QiRg- Received: from [212.77.203.38] by web33701.mail.mud.yahoo.com via HTTP; Thu, 28 Feb 2008 03:19:42 PST X-Mailer: YahooMailRC/902.35 YahooMailWebService/0.7.162 Date: Thu, 28 Feb 2008 03:19:42 -0800 (PST) From: Abdullah Ibn Hamad Al-Marri To: Ken Smith , freebsd-stable , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <585244.58283.qm@web33701.mail.mud.yahoo.com> Cc: Subject: Re: FreeBSD 7.0-RELEASE Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 11:19:43 -0000 Thank you all and Congrats! :) Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ----- Original Message ---- > From: Ken Smith > To: freebsd-stable ; freebsd-current@freebsd.org > Sent: Thursday, February 28, 2008 1:32:55 AM > Subject: FreeBSD 7.0-RELEASE Available > > > Just in case some interested parties are not subscribed to the > freebsd-announce mailing list... FreeBSD 7.0-RELEASE has been formally > released. If you would like to see the release announcement it's here: > > http://www.freebsd.org/releases/7.0R/announce.html > > On behalf of the FreeBSD Project thanks for your interest in FreeBSD. > We hope you enjoy the new release. > > -- > Ken Smith > - From there to here, from here to | kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 11:23:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8FA61065677 for ; Thu, 28 Feb 2008 11:23:47 +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 A2CE98FC1E for ; Thu, 28 Feb 2008 11:23:47 +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 4CCAC2088; Thu, 28 Feb 2008 12:23:44 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2C92B2049; Thu, 28 Feb 2008 12:23:43 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: mouss References: <47C34D7E.1010305@netoyen.net> <6.0.0.22.2.20080225180357.025db140@mail.computinginnovations.com> <47C35CCC.9090300@netoyen.net> <47C3DDCF.6070109@gmail.com> <47C4039A.3060907@netoyen.net> Date: Thu, 28 Feb 2008 12:23:42 +0100 In-Reply-To: <47C4039A.3060907@netoyen.net> (mouss@netoyen.net's message of "Tue\, 26 Feb 2008 13\:18\:34 +0100") Message-ID: <86lk552ukh.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Derek Ragona , Juraj Lutter Subject: Re: ssh_exchange_identification: Connection closed by remote host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 11:23:48 -0000 mouss writes: > I found the problem: > fatal: /var/empty must be owned by root and not group or world-writabl= e. > I have created an account and set the home to /var/empty, but this > changed the owner of /var/empty. sigh. There is no need to create an account. Also, 'cd /usr/src; make hierarchy' would have fixed it for you. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 11:25:53 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 380EA106566C for ; Thu, 28 Feb 2008 11:25:53 +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 E156E8FC22 for ; Thu, 28 Feb 2008 11:25:52 +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 D1DB82092; Thu, 28 Feb 2008 12:25:49 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 997FC2087; Thu, 28 Feb 2008 12:25:48 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Julian Elischer References: <47C39948.3080907@elischer.org> Date: Thu, 28 Feb 2008 12:25:48 +0100 In-Reply-To: <47C39948.3080907@elischer.org> (Julian Elischer's message of "Mon\, 25 Feb 2008 20\:44\:56 -0800") Message-ID: <86hcft2ugz.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Marko Zec , Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 11:25:53 -0000 Julian Elischer writes: > At some stage in the next few weeks I will be trying to commit Marco > Zec's vimage code to -current. (only 'trying' not for technical > reasons, but political). > > I'm making this announcement because this is sure to be a > controversial move. The best way to make sure that it will be controversial is to announce in advance that it is. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 11:35:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC4DC1065679 for ; Thu, 28 Feb 2008 11:35:27 +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 948A68FC17 for ; Thu, 28 Feb 2008 11:35:27 +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 8DC2A20A4; Thu, 28 Feb 2008 12:35:21 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 98E4F20A3; Thu, 28 Feb 2008 12:35:20 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Bruce M. Simpson" References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> Date: Thu, 28 Feb 2008 12:35:20 +0100 In-Reply-To: <47C4BB96.80804@icir.org> (Bruce M. Simpson's message of "Wed\, 27 Feb 2008 01\:23\:34 +0000") Message-ID: <86d4qh2u13.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Marko Zec , Marko Zec , Marko Zec , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 11:35:28 -0000 "Bruce M. Simpson" writes: > * Do you mean to say that IMUNES/vimage has expanded beyond merely > wrapping the network stack and virtualizing that? > > If this is the case (it introduces some new virtualization technique > on par with the functionality of e.g. Xen) then I outright DISAGREE > with its introduction into the source tree on the grounds that it's > too experimental. Well, it's only been discussed and developed and presented at every single BSD conference for the last, oh, three years or so, so yes, it's obviously highly immature and experimental code. I'll have my virtual bikeshed blue, if you please. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 11:40:23 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D0C31065671; Thu, 28 Feb 2008 11:40:23 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5346B8FC18; Thu, 28 Feb 2008 11:40:21 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C69DA4.5000209@FreeBSD.org> Date: Thu, 28 Feb 2008 12:40:20 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Marko Zec References: <47C39948.3080907@elischer.org> <47C494B5.2040306@elischer.org> <47C49FAA.1020605@FreeBSD.org> <200802280343.57576.zec@icir.org> In-Reply-To: <200802280343.57576.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Zec , Brooks Davis , Andre Oppermann , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 11:40:23 -0000 Marko Zec wrote: > OK first my appologies to everybody for being late in jumping into this > thread... I'll attempt to address a few questions rised so far in a > random order, but SMP scalability definitely tops the list... Thanks, very informative! Kris From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 12:28:59 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9D66106566C for ; Thu, 28 Feb 2008 12:28:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 607808FC29 for ; Thu, 28 Feb 2008 12:28:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1SCSvF3063845; Thu, 28 Feb 2008 13:28:57 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1SCSv03063844; Thu, 28 Feb 2008 13:28:57 +0100 (CET) (envelope-from olli) Date: Thu, 28 Feb 2008 13:28:57 +0100 (CET) Message-Id: <200802281228.m1SCSv03063844@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, arne@rfc2549.org In-Reply-To: <47C60C62.9090901@rfc2549.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 28 Feb 2008 13:28:58 +0100 (CET) Cc: Subject: Re: Specific Swap Usage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, arne@rfc2549.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 12:29:00 -0000 Arne Schwabe wrote: > If there is currently no ways to see which processes allocates how much > swap space are there any pointers where to look to implement such a feature? The problem is that there is no one-to-one relationship between memory pages (including those paged out to swap) and processes. Some pages belong to multiple processes, i.e. they're shared (e.g. libraries, IPC shared memory). Therefore it is very non-trivial to specify exactly the amount of memory (or swap space) allocated to a process. Part of the problem is that different people often mean different things when talking about "memory" or "swap". Also note that swapping and paging are different things. If your goal is to find out which process is causing the exhaustion of swap, the best way is to record the SIZE ("RSS" in ps) of all processes in order to see which one keeps growing. Usually it's rather easy to find. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 13:17:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC6501065676; Thu, 28 Feb 2008 13:17:11 +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 94E7D8FC16; Thu, 28 Feb 2008 13:17:11 +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 698E82085; Thu, 28 Feb 2008 14:17:06 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 458302084; Thu, 28 Feb 2008 14:17:05 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Marko Zec References: <47C39948.3080907@elischer.org> <47C494B5.2040306@elischer.org> <47C49FAA.1020605@FreeBSD.org> <200802280343.57576.zec@icir.org> Date: Thu, 28 Feb 2008 14:17:04 +0100 In-Reply-To: <200802280343.57576.zec@icir.org> (Marko Zec's message of "Thu\, 28 Feb 2008 03\:43\:57 +0100") Message-ID: <86tzjt1ar3.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Marko Zec , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 13:17:12 -0000 Marko Zec writes: > [about vimage] One thing you haven't mentioned is sysctl. I've always been of the opinion that if we virtualize one part of the system, we should also virtualize the sysctl tree. This does not mean that each vimage should have its own copy of the entire tree, but rather that it should be possible to mark some sysctl nodes as virtualized. For instance, it would be useful on amd64 to be able to create an i386 vimage, where hw.machine and hw.machine_arch would be "i386". For PROC nodes, of course, this is easily done (as you already do) with INIT_VPROCG(TD_TO_VPROGC(curthread)), but the basic node types (int, long, string etc.) are a little trickier, and don't seem to be handled in your patch. (I probably just lost every shred of credibility by revealing that I have actually read parts of the patch, but hey, them's the breaks...) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 13:43:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81F6B1065671 for ; Thu, 28 Feb 2008 13:43:07 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3A33F8FC19 for ; Thu, 28 Feb 2008 13:43:06 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 2230F19E027; Thu, 28 Feb 2008 14:43:05 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id 53E0819E019; Thu, 28 Feb 2008 14:42:58 +0100 (CET) Message-ID: <47C6BA70.5070509@quip.cz> Date: Thu, 28 Feb 2008 14:43:12 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Arne Schwabe References: <47C5E204.9080003@rfc2549.org> In-Reply-To: <47C5E204.9080003@rfc2549.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Specific Swap Usage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 13:43:07 -0000 Arne Schwabe wrote: > Hi, > > is there any way to look what programs are swapped out and how much > memory they use? Looking at SIZE in top is just a wild guess. One server > here grows in swap usage and panics eventuelly when all swap is usage. > Swap usage is growing slowly (100 MB /week ) but it is growing and see > no way to get what really uses swap :( (Read man ps three times already :/) AFAIK swapped processes in top are shown in lt + gt signs (braces): 1382 root 1 5 0 1380K 0K ttyin 0:00 0.00% from `man top` COMMAND is the name of the command that the process is currently running (if the process is swapped out, this column is marked ""). In `ps` output in column state: W - The process is swapped out. You can get a list of swapped processes by this command: ps auxwww | awk '$8 ~ /.W.*/ { print $0}' (tested on FreeBSD 6.2 & FreeBSD 7.0) Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 14:31:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A68E106566B for ; Thu, 28 Feb 2008 14:31:38 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id A1CE58FC18 for ; Thu, 28 Feb 2008 14:31:37 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id A2BBA9B75E; Thu, 28 Feb 2008 15:31:36 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.102] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 5529A9B65B; Thu, 28 Feb 2008 15:31:35 +0100 (CET) From: Marko Zec To: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= Date: Thu, 28 Feb 2008 15:31:27 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <200802280343.57576.zec@icir.org> <86tzjt1ar3.fsf@ds4.des.no> In-Reply-To: <86tzjt1ar3.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802281531.28052.zec@icir.org> Cc: Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 14:31:38 -0000 On Thursday 28 February 2008 14:17:04 Dag-Erling Sm=C3=B8rgrav wrote: > Marko Zec writes: > > [about vimage] > > One thing you haven't mentioned is sysctl. I've always been of the > opinion that if we virtualize one part of the system, we should also > virtualize the sysctl tree. This does not mean that each vimage > should have its own copy of the entire tree, but rather that it > should be possible to mark some sysctl nodes as virtualized. For > instance, it would be useful on amd64 to be able to create an i386 > vimage, where hw.machine and hw.machine_arch would be "i386". > > For PROC nodes, of course, this is easily done (as you already do) > with INIT_VPROCG(TD_TO_VPROGC(curthread)), but the basic node types > (int, long, string etc.) are a little trickier, and don't seem to be > handled in your patch. Actually the patch provides certain level of support for virtualizing=20 leaf sysctl nodes. So far I have only introduced macros for methods /=20 data types that I've found necessary to virtualize, such as=20 SYSCTL_V_OID, SYSCTL_V_STRING, SYSCTL_V_INT, and SYSCTL_V_PROC. =20 Instead of embedding a "pointer" to the variable that a sysctl needs to=20 control into the linker set that standard SYSCTL macros create, the=20 SYSCTL_V macros embed an ID of the virtualization container / strucrure=20 where the data has to be resolved, and an offset inside such a=20 structure. Here's a randomly picked example from a recent diff: +#ifndef VIMAGE struct icmpstat icmpstat; =2DSYSCTL_STRUCT(_net_inet_icmp, ICMPCTL_STATS, stats, CTLFLAG_RW, =2D &icmpstat, icmpstat, ""); +#endif +SYSCTL_V_STRUCT(V_NET, vnet_inet, _net_inet_icmp, ICMPCTL_STATS, stats, + CTLFLAG_RW, icmpstat, icmpstat, ""); So the latter macro will embedd an offsetof(struct vnet_inet, _icmpstat)=20 somewhere in the resulting linker set structure, with V_NET telling us=20 that we are resolving a networking symbol, and vnet_inet will also be=20 translated to an ID determining in which networking submodule to=20 resolve the address. The above sysctl will be handled by the sysctl_handle_v_int() function: #ifdef VIMAGE int sysctl_handle_v_int(SYSCTL_HANDLER_V_ARGS) { int tmpout, error =3D 0; SYSCTL_RESOLVE_V_ARG1(); /* * Attempt to get a coherent snapshot by making a copy of the=20 data. */ tmpout =3D *(int *)arg1; error =3D SYSCTL_OUT(req, &tmpout, sizeof(int)); if (error || !req->newptr) return (error); if (!arg1) error =3D EPERM; else error =3D SYSCTL_IN(req, arg1, sizeof(int)); return (error); } #endif Observe the SYSCTL_RESOLVE_V_ARG1() macro above which does the actual=20 magic of computing the address of the target variable: /* * Resolve void *arg1 in a proper virtualization container. */ #ifdef VIMAGE #define SYSCTL_RESOLVE_V_ARG1() do { char *cp; switch (subs) { case V_NET: cp =3D (char *) TD_TO_VNET(curthread)->mod_data[mod]; break; case V_PROCG: cp =3D (char *) TD_TO_VPROCG(curthread); break; case V_CPU: cp =3D (char *) TD_TO_VCPU(curthread); break; default: panic("unsupported module id %d", subs); } arg1 =3D cp + (size_t) arg1; } while (0) #endif Hmm probably I should make subs and mod the arguments of the above=20 macro... Anyhow if the kernel is compiled without "options VIMAGE" the SYSCTL_V=20 macros fall back to standard SYSCTL macros of course. Hope this clarifies the picture to some extent... Marko From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 14:37:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 486C71065671 for ; Thu, 28 Feb 2008 14:37:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id D28858FC18 for ; Thu, 28 Feb 2008 14:37:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JUjtJ-0006rI-Fs for freebsd-current@freebsd.org; Thu, 28 Feb 2008 16:37:52 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m1SEbu6u089437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 16:37:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m1SEbeAR079180; Thu, 28 Feb 2008 16:37:40 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1SEbeJO079179; Thu, 28 Feb 2008 16:37:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Feb 2008 16:37:40 +0200 From: Kostik Belousov To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20080228143740.GY57756@deviant.kiev.zoral.com.ua> References: <47C5E204.9080003@rfc2549.org> <47C6BA70.5070509@quip.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ymtaOUW2lKqK7has" Content-Disposition: inline In-Reply-To: <47C6BA70.5070509@quip.cz> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: f2683d8df775da069012ccac6e6e6321 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2339 [Feb 28 2008] 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: Arne Schwabe , FreeBSD Current Subject: Re: Specific Swap Usage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 14:37:53 -0000 --ymtaOUW2lKqK7has Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 28, 2008 at 02:43:12PM +0100, Miroslav Lachman wrote: > Arne Schwabe wrote: > >Hi, > > > >is there any way to look what programs are swapped out and how much=20 > >memory they use? Looking at SIZE in top is just a wild guess. One server= =20 > >here grows in swap usage and panics eventuelly when all swap is usage.= =20 > >Swap usage is growing slowly (100 MB /week ) but it is growing and see= =20 > >no way to get what really uses swap :( (Read man ps three times already = :/) >=20 > AFAIK swapped processes in top are shown in lt + gt signs (braces): > 1382 root 1 5 0 1380K 0K ttyin 0:00 0.00% >=20 > from `man top` > COMMAND is the name of the command that the process is currently=20 > running (if the process is swapped out, this column is marked ""= ). >=20 > In `ps` output in column state: W - The process is swapped out. >=20 > You can get a list of swapped processes by this command: > ps auxwww | awk '$8 ~ /.W.*/ { print $0}' >=20 > (tested on FreeBSD 6.2 & FreeBSD 7.0) Swapped process very much means swapped out kernel stack only. --ymtaOUW2lKqK7has Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfGxzMACgkQC3+MBN1Mb4hh+gCg6Q+qNdmNdm2ArlbfFcEjSlhG tNgAoJomDSOLJwGqFbeh7RvRutRhSDA3 =rU2I -----END PGP SIGNATURE----- --ymtaOUW2lKqK7has-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 15:27:49 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68707106570A for ; Thu, 28 Feb 2008 15:27:49 +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 1D0EC8FC16 for ; Thu, 28 Feb 2008 15:27:49 +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 8FDF22088; Thu, 28 Feb 2008 16:27:42 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 93F1E2049; Thu, 28 Feb 2008 16:27:41 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Marko Zec References: <47C39948.3080907@elischer.org> <200802280343.57576.zec@icir.org> <86tzjt1ar3.fsf@ds4.des.no> <200802281531.28052.zec@icir.org> Date: Thu, 28 Feb 2008 16:27:41 +0100 In-Reply-To: <200802281531.28052.zec@icir.org> (Marko Zec's message of "Thu\, 28 Feb 2008 15\:31\:27 +0100") Message-ID: <86zltlyuc2.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 15:27:49 -0000 Marko Zec writes: > Actually the patch provides certain level of support for virtualizing > leaf sysctl nodes. So far I have only introduced macros for methods / > data types that I've found necessary to virtualize, such as > SYSCTL_V_OID, SYSCTL_V_STRING, SYSCTL_V_INT, and SYSCTL_V_PROC. [...] Thanks, this is exactly what I was looking for. Now all we need is a way to start a vimage with hw.machine and hw.machine_arch set to a vimage-specific value... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 15:46:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A67D51065673 for ; Thu, 28 Feb 2008 15:46:40 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3C38D8FC12; Thu, 28 Feb 2008 15:46:39 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C6D75E.206@FreeBSD.org> Date: Thu, 28 Feb 2008 16:46:38 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <47C39948.3080907@elischer.org> <200802280343.57576.zec@icir.org> <86tzjt1ar3.fsf@ds4.des.no> <200802281531.28052.zec@icir.org> <86zltlyuc2.fsf@ds4.des.no> In-Reply-To: <86zltlyuc2.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Marko Zec , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 15:46:40 -0000 Dag-Erling Smørgrav wrote: > Marko Zec writes: >> Actually the patch provides certain level of support for virtualizing >> leaf sysctl nodes. So far I have only introduced macros for methods / >> data types that I've found necessary to virtualize, such as >> SYSCTL_V_OID, SYSCTL_V_STRING, SYSCTL_V_INT, and SYSCTL_V_PROC. [...] > > Thanks, this is exactly what I was looking for. Now all we need is a > way to start a vimage with hw.machine and hw.machine_arch set to a > vimage-specific value... also kern.osrelease and kern.osreldate please :) Kris From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 15:54:23 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00B921065672 for ; Thu, 28 Feb 2008 15:54:23 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id A71EA8FC27 for ; Thu, 28 Feb 2008 15:54:22 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 55DD49B651; Thu, 28 Feb 2008 16:54:21 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.102] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 65C539B64F; Thu, 28 Feb 2008 16:54:20 +0100 (CET) From: Marko Zec To: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= Date: Thu, 28 Feb 2008 16:54:14 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <200802281531.28052.zec@icir.org> <86zltlyuc2.fsf@ds4.des.no> In-Reply-To: <86zltlyuc2.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802281654.14726.zec@icir.org> Cc: Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 15:54:23 -0000 On Thursday 28 February 2008 16:27:41 Dag-Erling Sm=C3=B8rgrav wrote: > Marko Zec writes: > > Actually the patch provides certain level of support for > > virtualizing leaf sysctl nodes. So far I have only introduced > > macros for methods / data types that I've found necessary to > > virtualize, such as SYSCTL_V_OID, SYSCTL_V_STRING, SYSCTL_V_INT, > > and SYSCTL_V_PROC. [...] > > Thanks, this is exactly what I was looking for. Now all we need is a > way to start a vimage with hw.machine and hw.machine_arch set to a > vimage-specific value... So your question opens up a pandora's box... Obviously it's trivial to=20 virtualize a sysctl, but I still don't have a clear idea on what would=20 be the most convenient way of specifying start-up constraints or=20 parameters when instatiating a new vimage. At the moment each=20 virtualized variable is initialized to some system-wide compiled in=20 constant - we need to come up with a much more flexible / configurable=20 model... Marko From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 18:31:05 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B7B11065670 for ; Thu, 28 Feb 2008 18:31:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 36E338FC1F for ; Thu, 28 Feb 2008 18:31:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 28 Feb 2008 10:31:04 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id BC5512D6035; Thu, 28 Feb 2008 10:31:03 -0800 (PST) Message-ID: <47C6FDF8.2040600@elischer.org> Date: Thu, 28 Feb 2008 10:31:20 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <47C39948.3080907@elischer.org> <47C494B5.2040306@elischer.org> <47C49FAA.1020605@FreeBSD.org> <200802280343.57576.zec@icir.org> <86tzjt1ar3.fsf@ds4.des.no> In-Reply-To: <86tzjt1ar3.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 18:31:05 -0000 Dag-Erling Smørgrav wrote: > Marko Zec writes: >> [about vimage] > > One thing you haven't mentioned is sysctl. I've always been of the > opinion that if we virtualize one part of the system, we should also > virtualize the sysctl tree. This does not mean that each vimage should > have its own copy of the entire tree, but rather that it should be > possible to mark some sysctl nodes as virtualized. For instance, it > would be useful on amd64 to be able to create an i386 vimage, where > hw.machine and hw.machine_arch would be "i386". > > For PROC nodes, of course, this is easily done (as you already do) with > INIT_VPROCG(TD_TO_VPROGC(curthread)), but the basic node types (int, > long, string etc.) are a little trickier, and don't seem to be handled > in your patch. > > (I probably just lost every shred of credibility by revealing that I > have actually read parts of the patch, but hey, them's the breaks...) Yes the sysctl tree has had some virtualisation support added to it (!) I was impressed, even if there is more to do. It's only used at this time to show the correct sysctls relevant to your network stack due to the scope if the vimage project but could be used for other virtualised things now the framework is there. Of course that is outside the vimage scope but others could do that.. > > DES From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 18:37:21 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA9991065672 for ; Thu, 28 Feb 2008 18:37:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outX.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id C69948FC29 for ; Thu, 28 Feb 2008 18:37:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 28 Feb 2008 10:37:20 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 93F682D67A0; Thu, 28 Feb 2008 10:37:19 -0800 (PST) Message-ID: <47C6FF70.9020005@elischer.org> Date: Thu, 28 Feb 2008 10:37:36 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Marko Zec References: <47C39948.3080907@elischer.org> <200802281531.28052.zec@icir.org> <86zltlyuc2.fsf@ds4.des.no> <200802281654.14726.zec@icir.org> In-Reply-To: <200802281654.14726.zec@icir.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 18:37:22 -0000 Marko Zec wrote: > On Thursday 28 February 2008 16:27:41 Dag-Erling Smørgrav wrote: >> Marko Zec writes: >>> Actually the patch provides certain level of support for >>> virtualizing leaf sysctl nodes. So far I have only introduced >>> macros for methods / data types that I've found necessary to >>> virtualize, such as SYSCTL_V_OID, SYSCTL_V_STRING, SYSCTL_V_INT, >>> and SYSCTL_V_PROC. [...] >> Thanks, this is exactly what I was looking for. Now all we need is a >> way to start a vimage with hw.machine and hw.machine_arch set to a >> vimage-specific value... > > So your question opens up a pandora's box... Obviously it's trivial to > virtualize a sysctl, but I still don't have a clear idea on what would > be the most convenient way of specifying start-up constraints or > parameters when instatiating a new vimage. At the moment each > virtualized variable is initialized to some system-wide compiled in > constant - we need to come up with a much more flexible / configurable > model... > Whooooa there! Before we widen the scope of the vimage project to complete virtualisation of everything. How about we get what we have now into the tree? :-) BTW Marco, you might want to add some comments in vimage.h about how you see the current framework growing to encompas such things as dynamically assigned module numbers for kld modules and such so that when we commit it, there is some sort of architetural guide for the "thousands of people" who will want to improve it and extend it to other views of virtualisation. From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 19:24:07 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BCDD1065675 for ; Thu, 28 Feb 2008 19:24:07 +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 4ECFB8FC27 for ; Thu, 28 Feb 2008 19:24:07 +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 167972084; Thu, 28 Feb 2008 20:24:04 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 85C1B207E; Thu, 28 Feb 2008 20:24:03 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Julian Elischer References: <47C39948.3080907@elischer.org> <200802281531.28052.zec@icir.org> <86zltlyuc2.fsf@ds4.des.no> <200802281654.14726.zec@icir.org> <47C6FF70.9020005@elischer.org> Date: Thu, 28 Feb 2008 20:24:02 +0100 In-Reply-To: <47C6FF70.9020005@elischer.org> (Julian Elischer's message of "Thu\, 28 Feb 2008 10\:37\:36 -0800") Message-ID: <86ve4828bx.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 19:24:07 -0000 Julian Elischer writes: > Whooooa there! > > Before we widen the scope of the vimage project to complete > virtualisation of everything. How about we get what we have now into > the tree? :-) Absolutely, we can worry about my sysctls later :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 19:57:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89C42106566C for ; Thu, 28 Feb 2008 19:57:30 +0000 (UTC) (envelope-from bazzoola@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by mx1.freebsd.org (Postfix) with ESMTP id 093658FC1D for ; Thu, 28 Feb 2008 19:57:29 +0000 (UTC) (envelope-from bazzoola@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so3167171tid.3 for ; Thu, 28 Feb 2008 11:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=JjqcQPYFALz6GwYCFEyCxszfS3srhaGaeWKSxSP915s=; b=fYpPJT60ZBA2+tKNNYLVogxIsuMem1lMrYF41YJvZF9CjHy4ZMpyDZP7x2k1j+PVehuVNiFYAWhKw57fww+r/ZPKHt71cj4k6I8PWUzdy7kXaKYa9yyioRr1TpZXVcPRy8UzdsVd9o5OGzLqBJGEtQVJ+X5ERciXS3tngSgQ5x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=Ksp5Bh9scCPx2K+tn/Uss/QIEokWAz2FYYHVv1hwPY/VUx83P6GoLvAkJS1Ss70yhsqDrF+Jkhxd6zqIya9JbQMtYK+p/gCHv7/KwfIJWvBCnhHCzfmINF7Qq682sYULks6zqrUmTnxDpprqcc1BRjohWxbh4cBfuccsN12N6ec= Received: by 10.151.26.12 with SMTP id d12mr2950018ybj.45.1204228647075; Thu, 28 Feb 2008 11:57:27 -0800 (PST) Received: from macbookpro.dhcp.egr.msu.edu ( [35.9.42.15]) by mx.google.com with ESMTPS id f77sm25048692pyh.32.2008.02.28.11.57.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Feb 2008 11:57:25 -0800 (PST) Message-Id: From: bazzoola To: Ken Smith In-Reply-To: <1204151575.84335.3.camel@neo.cse.buffalo.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 14:57:21 -0500 References: <1204151575.84335.3.camel@neo.cse.buffalo.edu> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 7.0-RELEASE Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 19:57:30 -0000 Terrific job! Thanks for anyone contributed to this fine release :) On Feb 27, 2008, at 5:32 PM, Ken Smith wrote: > > Just in case some interested parties are not subscribed to the > freebsd-announce mailing list... FreeBSD 7.0-RELEASE has been > formally > released. If you would like to see the release announcement it's > here: > > http://www.freebsd.org/releases/7.0R/announce.html > > On behalf of the FreeBSD Project thanks for your interest in FreeBSD. > We hope you enjoy the new release. > > -- > Ken Smith > - From there to here, from here to | kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 20:30:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787C01065681 for ; Thu, 28 Feb 2008 20:30:28 +0000 (UTC) (envelope-from tim1timau@yahoo.com) Received: from web50308.mail.re2.yahoo.com (web50308.mail.re2.yahoo.com [206.190.38.62]) by mx1.freebsd.org (Postfix) with SMTP id ECD308FC28 for ; Thu, 28 Feb 2008 20:30:27 +0000 (UTC) (envelope-from tim1timau@yahoo.com) Received: (qmail 78189 invoked by uid 60001); 28 Feb 2008 20:30:27 -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=sPrw3ZFsrDhvYquFLqOh0li6LQzrJAyf/fKZehLRZZoouDK/acTuD0w0WNfkQoC1QIkoYrIgoQo8ornTwwYqVCgDVEQxq4RtftfpyniBxsE2LsiUOJscA3fxkCkkrH3+oueiJsFBAq0lxqpXA/TYL8GFuvfDxIDolY8WDmj2lj4=; X-YMail-OSG: eFwWv_sVM1mKnPkxYlfg6_QzHkaPa0vlhwKkweYpM4i1mVw1uSZh_7wfkUekvFaGCfSxK.vchei8I3kl9qG7yOsYnD0sTcNBZas5uqOSm4B5QzwDehEAsaKGkyvQJ399kJpJRktEbbZQphk- Received: from [210.215.149.194] by web50308.mail.re2.yahoo.com via HTTP; Thu, 28 Feb 2008 12:30:26 PST Date: Thu, 28 Feb 2008 12:30:26 -0800 (PST) From: Tim Clewlow To: freebsd-current@freebsd.org, hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <114098.31819.qm@web50308.mail.re2.yahoo.com> Cc: Subject: PXE on 7.0 problem and solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 20:30:28 -0000 Hi there, Installing 7.0 via PXE has a slight problem that is easily worked around. The file /boot/mfsroot.gz on the installation media needs to be unzipped to make PXE boot via tftp/nfs work. Otherwise the loader ultimately complains that it cant find the device to boot from. For example, if you have the installation media living at /usr/pxe/nfs/ on the PXE server, then do: gzip -d /usr/pxe/nfs/boot/mfsroot.gz After doing this it now loads the kernel and starts the installation procedure as expected. Someone more knowledgeable than me might want to let whoever needs to know about this. Apart from that, it looks great, the work is appreciated, thanks for the new release :-) Cheers, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/ ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 20:52:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5141065684; Thu, 28 Feb 2008 20:52:13 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from mx2.itu.dk (unknown [130.226.142.29]) by mx1.freebsd.org (Postfix) with ESMTP id D99E08FC2F; Thu, 28 Feb 2008 20:52:12 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from wimac.littlebit.dk (unknown [85.233.238.191]) by mx2.itu.dk (Postfix) with ESMTP id 8A6A7F48072; Thu, 28 Feb 2008 21:52:11 +0100 (CET) Message-ID: <47C71EC1.3010500@cederstrand.dk> Date: Thu, 28 Feb 2008 21:51:13 +0100 From: Erik Cederstrand User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Tim Clewlow References: <114098.31819.qm@web50308.mail.re2.yahoo.com> In-Reply-To: <114098.31819.qm@web50308.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: PXE on 7.0 problem and solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 20:52:13 -0000 Tim Clewlow wrote: > Hi there, > > Installing 7.0 via PXE has a slight problem that is easily worked around. The > file /boot/mfsroot.gz on the installation media needs to be unzipped to make > PXE boot via tftp/nfs work. Otherwise the loader ultimately complains that it > cant find the device to boot from. For example, if you have the installation > media living at /usr/pxe/nfs/ on the PXE server, then do: > > gzip -d /usr/pxe/nfs/boot/mfsroot.gz > > After doing this it now loads the kernel and starts the installation procedure > as expected. Someone more knowledgeable than me might want to let whoever needs > to know about this. > > Apart from that, it looks great, the work is appreciated, thanks for the new > release :-) I've had problems with other files fetched over NFS in the past. In theory (at least that's what a tcpdump says), it should be possible to provide all files gzipped, and even split the files in smaller chunks. Files are tried in this order: boot/loader.rc.split boot/loader.rc.gz.split boot/loader.rc.gz boot/loader.rc However, I only got the plain files to work reliably. Erik From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 21:40:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A2D106566B for ; Thu, 28 Feb 2008 21:40:58 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id BD8F58FC1A for ; Thu, 28 Feb 2008 21:40:58 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 9815 invoked from network); 28 Feb 2008 21:40:57 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 28 Feb 2008 21:40:57 -0000 Message-ID: <47C728F1.9030102@chuckr.org> Date: Thu, 28 Feb 2008 16:34:41 -0500 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: ldconfig problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 21:40:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have had a small horde of little problems crop up, right after I finished getting my raid disk fixed. I announced most of them on hackers, but this one seems to me to be rather more likley to be at least partially the fault that I run FreeBSD-current, so I am bringing it up here. Just before I go multiuser I get the normal annoucement from ldconfig, announcing the addition of several different paths, Well, I see that, and it looks fine, but right afterwards, i see several hundred extra lines, all looking pretty much on the same way as these 5 example lines: ldconfig: ®: No such file or directory ldconfig: ÿÿÿÿÿÿÿÿø°: No such file or directory ldconfig: ÿÿÿÿ@³: No such file or directory ldconfig: ´: No such file or directory ldconfig: ÿÿÿÿÿÿÿÿW¶: No such file or directory I spent about an hour hunting for problems, but I can't spot what this is, anybody else feel like hazarding a guess? I appreciate even wacky ideas, because it's those wacky ones that usually prod me into figuring it out myself, so don't feel bashful about helping, I won't jump down your throat for the sillliest answers, I promise. Thanks, guys. BTW, I didn't announce ALL my problems, I hit two on to hackers, and one here, but I have an audio one at the same time, and I figure the chances are too high that it's a secondary problem to one of the 3 I have shown you guys, so I'm going to hold my breath on that one, but I want to restart seeing my dvd's again, that's for sure. I'm hoping, hoping, hoping ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxyjxz62J6PPcoOkRAo8lAKCYfCxPeU8TSdjQRXybzK4VSGK2oQCglUWY Nf5wfeykAPfcE/DszPLuZMk= =lHX7 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 22:18:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 381A61065674 for ; Thu, 28 Feb 2008 22:18:47 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63907.mail.re1.yahoo.com (web63907.mail.re1.yahoo.com [69.147.97.122]) by mx1.freebsd.org (Postfix) with SMTP id AF0C88FC1A for ; Thu, 28 Feb 2008 22:18:46 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 4099 invoked by uid 60001); 28 Feb 2008 22:18:45 -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=HphJ7Dl7XeKEXNC7ZpJmjdUx6zRELvguoG7JkihYssDVXrLiBnO+ruSGBtPuXqxWJQZM7kSVZcSA9AQyOc6XNahegl/Zcmy4fGB+9RwWz47i3uDcaQOQBT2HHUN3bM+rdPR0OQzLsM4b+4mzs0m1NaFid/7YUoVoHaW1Z+CCiig=; X-YMail-OSG: m11qh5UVM1nSz5KpCuwKHgr_Ueq8_3eNLikDfN4lyvWhKEqhzK49sxaSUSCK1B2ELQ-- Received: from [98.203.28.38] by web63907.mail.re1.yahoo.com via HTTP; Thu, 28 Feb 2008 14:18:45 PST Date: Thu, 28 Feb 2008 14:18:45 -0800 (PST) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <819366.3388.qm@web63907.mail.re1.yahoo.com> Cc: Subject: netstat output issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 22:18:47 -0000 When using bridging, netstat apparently can only display 5 characters, so "bridge" is shown as the route. If you have multiple bridges defined, you'd have no way of knowing which bridge was being specified. Barney ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 22:46:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 137F2106566B; Thu, 28 Feb 2008 22:46:55 +0000 (UTC) (envelope-from bazzoola@gmail.com) Received: from h4.valero.com (h4.valero.com [209.99.19.59]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6678FC1B; Thu, 28 Feb 2008 22:46:54 +0000 (UTC) (envelope-from bazzoola@gmail.com) Received: from mssais17.valero.com ([192.168.250.15]) by h4.valero.com (Switch-3.2.5/Sentrion-1.5.5) with ESMTP id m1SMECQ9031354; Thu, 28 Feb 2008 16:14:12 -0600 Delivered-To: matt.moulder@valero.com X-VirusChecked: Checked X-Env-Sender: owner-freebsd-stable@freebsd.org X-Msg-Ref: server-3.tower-191.messagelabs.com!1204230272!23578091!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [69.147.83.53] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP Delivered-To: freebsd-stable@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=JjqcQPYFALz6GwYCFEyCxszfS3srhaGaeWKSxSP915s=; b=fYpPJT60ZBA2+tKNNYLVogxIsuMem1lMrYF41YJvZF9CjHy4ZMpyDZP7x2k1j+PVehuVNiFYAWhKw57fww+r/ZPKHt71cj4k6I8PWUzdy7kXaKYa9yyioRr1TpZXVcPRy8UzdsVd9o5OGzLqBJGEtQVJ+X5ERciXS3tngSgQ5x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=Ksp5Bh9scCPx2K+tn/Uss/QIEokWAz2FYYHVv1hwPY/VUx83P6GoLvAkJS1Ss70yhsqDrF+Jkhxd6zqIya9JbQMtYK+p/gCHv7/KwfIJWvBCnhHCzfmINF7Qq682sYULks6zqrUmTnxDpprqcc1BRjohWxbh4cBfuccsN12N6ec= Message-Id: From: bazzoola To: Ken Smith In-Reply-To: <1204151575.84335.3.camel@neo.cse.buffalo.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 14:57:21 -0500 References: <1204151575.84335.3.camel@neo.cse.buffalo.edu> X-Mailer: Apple Mail (2.919.2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org X-VLO_ORIGIP: 216.82.241.83 X-OriginalArrivalTime: 28 Feb 2008 20:24:36.0041 (UTC) FILETIME=[EF8E5B90:01C87A47] Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 7.0-RELEASE Available X-BeenThere: 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: Thu, 28 Feb 2008 22:46:55 -0000 Terrific job! Thanks for anyone contributed to this fine release :) On Feb 27, 2008, at 5:32 PM, Ken Smith wrote: > > Just in case some interested parties are not subscribed to the > freebsd-announce mailing list... FreeBSD 7.0-RELEASE has been > formally > released. If you would like to see the release announcement it's > here: > > http://www.freebsd.org/releases/7.0R/announce.html > > On behalf of the FreeBSD Project thanks for your interest in FreeBSD. > We hope you enjoy the new release. > > -- > Ken Smith > - From there to here, from here to | kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 23:51:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 647CD1065670 for ; Thu, 28 Feb 2008 23:51:46 +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 1244D8FC1C for ; Thu, 28 Feb 2008 23:51:45 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 5560E75C8; Fri, 29 Feb 2008 12:51:44 +1300 (NZDT) Date: Fri, 29 Feb 2008 12:51:44 +1300 From: Andrew Thompson To: Barney Cordoba Message-ID: <20080228235144.GA35957@heff.fud.org.nz> References: <819366.3388.qm@web63907.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <819366.3388.qm@web63907.mail.re1.yahoo.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org Subject: Re: netstat output issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Feb 2008 23:51:46 -0000 On Thu, Feb 28, 2008 at 02:18:45PM -0800, Barney Cordoba wrote: > When using bridging, netstat apparently can only > display 5 characters, so "bridge" is shown as the > route. If you have multiple bridges defined, you'd > have no way of knowing which bridge was being > specified. A workaround is to rename your interfaces, ifconfig bridge0 name b0 ifconfig bridge1 name b1 ... It would be nice to fix netstat too. Andrew From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 00:16:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F3E31065672 for ; Fri, 29 Feb 2008 00:16:30 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 991038FC2D for ; Fri, 29 Feb 2008 00:16:29 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2790930fgg.35 for ; Thu, 28 Feb 2008 16:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pU1poE9CnYV3zzSkcW6h6CcDPTN7h80fsp/6FpNT1ng=; b=asVU7YA9iNagWtrz1nvm918DK7RZJ92XXj7NVcc6o6b0YADOkbTkbQneoCUGaTTvf3UgdLz4ObYOezlFF7dNYbZvrBMaPTI8KZltVp40cJZNSELnap7oUPBJqKz5YfkgDJ1ImeHgKn909Rw1ePURorS6SzFCXVe0cbR8imoGFBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MnTwazrLcVOmXXWp9EU2ZAigKgbv/WyY3mo9xvdyl9gNJE/hA9aeyukwYzL1ru6J530JZqNC5AQvevpq85RaIwgh0yIv4EyCVnrAj53Y/We5PLoYYwadhkEbmjIBUFtb1GMgivNM/uG1AP314+mmwPmmFY+79BkjjyCQ+pfKLTM= Received: by 10.86.62.3 with SMTP id k3mr9241713fga.71.1204244188299; Thu, 28 Feb 2008 16:16:28 -0800 (PST) Received: by 10.86.99.17 with HTTP; Thu, 28 Feb 2008 16:16:28 -0800 (PST) Message-ID: <790a9fff0802281616o16b96256oad9de4b9d639f460@mail.gmail.com> Date: Thu, 28 Feb 2008 18:16:28 -0600 From: "Scot Hetzel" To: "Chuck Robey" In-Reply-To: <47C728F1.9030102@chuckr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <47C728F1.9030102@chuckr.org> Cc: freebsd-current@freebsd.org Subject: Re: ldconfig problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 00:16:30 -0000 On Thu, Feb 28, 2008 at 3:34 PM, Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have had a small horde of little problems crop up, right after I finish= ed > getting my raid disk fixed. I announced most of them on hackers, but thi= s > one seems to me to be rather more likley to be at least partially the fau= lt > that I run FreeBSD-current, so I am bringing it up here. > > Just before I go multiuser I get the normal annoucement from ldconfig, > announcing the addition of several different paths, Well, I see that, an= d > it looks fine, but right afterwards, i see several hundred extra lines, a= ll > looking pretty much on the same way as these 5 example lines: > > ldconfig: (R): No such file or directory > ldconfig: =FF=FF=FF=FF=FF=FF=FF=FF=F8=B0: No such file or directory > ldconfig: =FF=FF=FF=FF@=B3: No such file or directory > ldconfig: =B4: No such file or directory > ldconfig: =FF=FF=FF=FF=FF=FF=FF=FFW=B6: No such file or directory > Check the files in: /usr/local/libdata/ldconfig/ and /usr/local/libdata/ldconfig32/ One of these might be corrupt. Scot. From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 01:08:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC72C1065674 for ; Fri, 29 Feb 2008 01:08:24 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4825F8FC22 for ; Fri, 29 Feb 2008 01:08:23 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 685CE38102C; Fri, 29 Feb 2008 01:56:23 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 0A8283F9082; Thu, 28 Feb 2008 23:40:36 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 3C1E39BF12; Thu, 28 Feb 2008 22:40:19 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 281BD405B; Thu, 28 Feb 2008 23:40:19 +0100 (CET) Date: Thu, 28 Feb 2008 23:40:19 +0100 From: Jeremie Le Hen To: Sam Leffler Message-ID: <20080228224019.GA94339@obiwan.tataz.chchile.org> References: <20080226225652.GE56090@obiwan.tataz.chchile.org> <20080227213137.GG56090@obiwan.tataz.chchile.org> <47C60721.9090609@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C60721.9090609@errno.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org Subject: Re: Wireless adapter associated, rx ok, tx ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 01:08:24 -0000 Sam, On Wed, Feb 27, 2008 at 04:58:09PM -0800, Sam Leffler wrote: > Jeremie Le Hen wrote: > > (Note that setting deftxkey for wi0, does not change anything.) > > I don't believe you that setting the key doesn't change anything. Your > outbound traffic is being dropped because there is no tx keyid specified. > > I note the ral log likewise says you have no deftxkey setup. Thanks for your reply. You are right indeed. It was not obvious to me that I should set a tx keyid manually, partly because when setting the WEP key, ifconfig(8) assumes key 1 if no index is specified. Would it be correct to set the default tx keyid to 1? On the contrary, I will provide an update to the manpage stating setting the default tx keyid is mandatory. Note that if_ral works now, but I still can't use if_wi. I suppose this is a bug in the driver. % jarjarbinks:~:127# sysctl net.wlan.0.debug=0xffffffff % net.wlan.0.debug: 0 -> 2147483647 % jarjarbinks:~:128# dhclient wi0 % wi0: ieee80211_newstate: RUN -> INIT % wi0: ieee80211_ref_node (ieee80211_send_mgmt:1574) 0xc4b68000 refcnt 3 % wi0: [XX:XX:XX:XX:XX:XX] send station disassociate (reason 8) % [XX:XX:XX:XX:XX:XX] send disassoc on channel 10 % wi0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 % wi0: ieee80211_node_table_reset station table % wi0: ieee80211_free_allnodes_locked: free all nodes in station table % wi0: node_reclaim: remove 0xc4b68000 from station table, refcnt 1 % wi0: ieee80211_setup_node 0xc4b6d000<00:02:2d:4b:b9:20> in station table % wi0: _ieee80211_free_node 0xc4b68000 in table % wi0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 % DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 6 % wi0: ieee80211_newstate: INIT -> RUN % wi0: ieee80211_newstate: invalid transition % DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 12 % DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 17 As a side note, I can't use wlanstats with wi(4): % jarjarbinks:~:113# ifconfig wi0 % wi0: flags=8843 metric 0 mtu 1500 % ether 00:02:2d:4b:b9:20 % inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 % media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) % status: associated % ssid XXXXXXXXXXXX channel 10 (2457 Mhz 11b) bssid XX:XX:XX:XX:XX:XX % stationname "FreeBSD WaveLAN/IEEE node" % authmode OPEN privacy MIXED deftxkey 1 wepkey 1:104-bit bmiss 7 % scanvalid 60 % jarjarbinks:~:114# wlanstats -ai wi0 % wlanstats: wi0 (IEEE80211_IOC_STA_INFO): Invalid argument % % Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 01:16:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B05411065670 for ; Fri, 29 Feb 2008 01:16:09 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id 84DD78FC17 for ; Fri, 29 Feb 2008 01:16:09 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 10268 invoked from network); 29 Feb 2008 01:16:09 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 29 Feb 2008 01:16:08 -0000 Message-ID: <47C75B55.5020103@chuckr.org> Date: Thu, 28 Feb 2008 20:09:41 -0500 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Scot Hetzel References: <47C728F1.9030102@chuckr.org> <790a9fff0802281616o16b96256oad9de4b9d639f460@mail.gmail.com> In-Reply-To: <790a9fff0802281616o16b96256oad9de4b9d639f460@mail.gmail.com> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: ldconfig problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 01:16:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scot Hetzel wrote: > On Thu, Feb 28, 2008 at 3:34 PM, Chuck Robey wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I have had a small horde of little problems crop up, right after I finished >> getting my raid disk fixed. I announced most of them on hackers, but this >> one seems to me to be rather more likley to be at least partially the fault >> that I run FreeBSD-current, so I am bringing it up here. >> >> Just before I go multiuser I get the normal annoucement from ldconfig, >> announcing the addition of several different paths, Well, I see that, and >> it looks fine, but right afterwards, i see several hundred extra lines, all >> looking pretty much on the same way as these 5 example lines: >> >> ldconfig: (R): No such file or directory >> ldconfig: ÿÿÿÿÿÿÿÿø°: No such file or directory >> ldconfig: ÿÿÿÿ@³: No such file or directory >> ldconfig: ´: No such file or directory >> ldconfig: ÿÿÿÿÿÿÿÿW¶: No such file or directory >> > Check the files in: > Sounded like such a great idea, I was really disappointed to find there wasn't any corruption. I can say, I have determined that it's being generated during the running of thje ldconfig script in /etc/rc.d, there's a loop in there that's printing it all, but I'm not all that good at troubleshooting sh. Well, I'll get to it, I guess, and my best thanks for the fine try. > /usr/local/libdata/ldconfig/ > > and > > /usr/local/libdata/ldconfig32/ > > One of these might be corrupt. > > Scot. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHx1tVz62J6PPcoOkRAkqJAJ9VCJWvOESXRh3TB300Nz2EtB37fwCcCXyQ vpwwykWPr+YPG2WvmK9ze9A= =Fqy8 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 03:16:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51D0B1065672 for ; Fri, 29 Feb 2008 03:16:39 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 12BFD8FC16 for ; Fri, 29 Feb 2008 03:16:38 +0000 (UTC) (envelope-from sam@errno.com) Received: from Macintosh-2.local ([10.0.0.196]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m1T3GbBq031612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 19:16:38 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47C77915.7050804@errno.com> Date: Thu, 28 Feb 2008 19:16:37 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jeremie Le Hen References: <20080226225652.GE56090@obiwan.tataz.chchile.org> <20080227213137.GG56090@obiwan.tataz.chchile.org> <47C60721.9090609@errno.com> <20080228224019.GA94339@obiwan.tataz.chchile.org> In-Reply-To: <20080228224019.GA94339@obiwan.tataz.chchile.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: Wireless adapter associated, rx ok, tx ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 03:16:39 -0000 Jeremie Le Hen wrote: > Sam, > > On Wed, Feb 27, 2008 at 04:58:09PM -0800, Sam Leffler wrote: >> Jeremie Le Hen wrote: >>> (Note that setting deftxkey for wi0, does not change anything.) >> I don't believe you that setting the key doesn't change anything. Your >> outbound traffic is being dropped because there is no tx keyid specified. >> >> I note the ral log likewise says you have no deftxkey setup. > > Thanks for your reply. You are right indeed. It was not obvious to me > that I should set a tx keyid manually, partly because when setting the > WEP key, ifconfig(8) assumes key 1 if no index is specified. > > Would it be correct to set the default tx keyid to 1? On the contrary, > I will provide an update to the manpage stating setting the default tx > keyid is mandatory. Yes, it seems the man page doesn't call out that you need to setup a deftxkey in order for outbound traffic to be encrypted when using WEP. If you use wpa_supplicant it will do that for you. Please send me something for ifconfig(8). > > > Note that if_ral works now, but I still can't use if_wi. I suppose this > is a bug in the driver. It should work but noone has cared about wi for years so it's entirely possible it is broken. > > % jarjarbinks:~:127# sysctl net.wlan.0.debug=0xffffffff > % net.wlan.0.debug: 0 -> 2147483647 > % jarjarbinks:~:128# dhclient wi0 > % wi0: ieee80211_newstate: RUN -> INIT > % wi0: ieee80211_ref_node (ieee80211_send_mgmt:1574) 0xc4b68000 refcnt 3 > % wi0: [XX:XX:XX:XX:XX:XX] send station disassociate (reason 8) > % [XX:XX:XX:XX:XX:XX] send disassoc on channel 10 > % wi0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 > % wi0: ieee80211_node_table_reset station table > % wi0: ieee80211_free_allnodes_locked: free all nodes in station table > % wi0: node_reclaim: remove 0xc4b68000 from station table, refcnt 1 > % wi0: ieee80211_setup_node 0xc4b6d000<00:02:2d:4b:b9:20> in station table > % wi0: _ieee80211_free_node 0xc4b68000 in table > % wi0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 > % DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 6 > % wi0: ieee80211_newstate: INIT -> RUN > % wi0: ieee80211_newstate: invalid transition > % DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 12 > % DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 17 > > As a side note, I can't use wlanstats with wi(4): > % jarjarbinks:~:113# ifconfig wi0 > % wi0: flags=8843 metric 0 mtu 1500 > % ether 00:02:2d:4b:b9:20 > % inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > % media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > % status: associated > % ssid XXXXXXXXXXXX channel 10 (2457 Mhz 11b) bssid XX:XX:XX:XX:XX:XX > % stationname "FreeBSD WaveLAN/IEEE node" > % authmode OPEN privacy MIXED deftxkey 1 wepkey 1:104-bit bmiss 7 > % scanvalid 60 > % jarjarbinks:~:114# wlanstats -ai wi0 > % wlanstats: wi0 (IEEE80211_IOC_STA_INFO): Invalid argument This is a bug in wi; it is not properly integrated with net80211. > % > % > > Thanks. > Regards, From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 06:58:39 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 029071065673 for ; Fri, 29 Feb 2008 06:58:39 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3E38FC2F for ; Fri, 29 Feb 2008 06:58:38 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1T6wakj021054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 17:58:36 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1T6wZAv062472; Fri, 29 Feb 2008 17:58:35 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1T6wZpQ062471; Fri, 29 Feb 2008 17:58:35 +1100 (EST) (envelope-from peter) Date: Fri, 29 Feb 2008 17:58:35 +1100 From: Peter Jeremy To: Barney Cordoba Message-ID: <20080229065835.GR83599@server.vk2pj.dyndns.org> References: <819366.3388.qm@web63907.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IjNIXuzrMEaOuFwn" Content-Disposition: inline In-Reply-To: <819366.3388.qm@web63907.mail.re1.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org Subject: Re: netstat output issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 06:58:39 -0000 --IjNIXuzrMEaOuFwn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 28, 2008 at 02:18:45PM -0800, Barney Cordoba wrote: >When using bridging, netstat apparently can only >display 5 characters, so "bridge" is shown as the >route. If you're talking about 'netstat -i', try 'netstat -iW'. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --IjNIXuzrMEaOuFwn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHx60b/opHv/APuIcRAgAYAJ4ynnhShtpznC+eDbmtFBnmIJwbvgCfcSRv V86VYM1pohmFtoCxvKpT/v4= =IOv/ -----END PGP SIGNATURE----- --IjNIXuzrMEaOuFwn-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 12:37:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 362E41065678 for ; Fri, 29 Feb 2008 12:37:32 +0000 (UTC) (envelope-from matthew@matthew.sk) Received: from mailserver.antik.sk (mailserver.antik.sk [88.212.10.6]) by mx1.freebsd.org (Postfix) with ESMTP id 64BAB8FC1A for ; Fri, 29 Feb 2008 12:37:31 +0000 (UTC) (envelope-from matthew@matthew.sk) Received: (qmail 30633 invoked from network); 29 Feb 2008 13:37:29 +0100 Received: by simscan 1.4.0 ppid: 30626, pid: 30630, t: 0.0162s scanners: regex: 1.4.0 attach: 1.4.0 clamav: 0.91.2/m:45/d:6030 Received: from unknown (HELO ?10.252.4.243?) (matthew@matthew.sk@10.252.4.243) by mailserver.antik.sk with AES256-SHA encrypted SMTP; 29 Feb 2008 13:37:29 +0100 Message-ID: <47C7FC8A.4050906@matthew.sk> Date: Fri, 29 Feb 2008 13:37:30 +0100 From: matthew User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: Kris Kennaway References: <47C5753A.8010806@matthew.sk> <47C57D01.8070007@FreeBSD.org> In-Reply-To: <47C57D01.8070007@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0 Beta, RC, RELEASE (amd64) freezes with dummynet enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 12:37:32 -0000 Kris Kennaway wrote: > matthew wrote: >> I have posted before that i have a stability issue with the 7.0 branch >> on my servers. Tested on BETA2,BETA4,RC1,RC2,RELEASE >> >> The original thread and my post with details is at: >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-12/msg00674.html >> >> >> I was waiting for the 7.0-RELEASE, updated the whole servers, and >> enabled dummynet again, but it always freezes after some minutes, 100% >> reproducible. >> >> I tested it also on a HP 140 G3 1U server, where 6.3 has absolutely no >> problems, but the 7.0 branch keeps freezing. >> >> Again, if it helps to solve this bug, i can rebuild the kernel with >> debug symbols a take some screenshots :) >> >> _______________________________________________ >> 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" >> >> > > Please follow the steps at > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > > > Kris > _______________________________________________ > 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 have some screenshots from debug console after the freeze, i hade to replace the keyboard with a working ESC key to launch the ctrl+alt+esc:) You can find it on http://dummynetcrash.matthew.sk/ Sorry for the bad quality of some pictures. I have also a dump, after running panic in the debug console: (gdb) root@hanka:/usr/src/sys/amd64/compile/HANKA-debug# kgdb kernel.debug /var/crash/vmcore.1 [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 "amd64-marcel-freebsd". Unread portion of the kernel message buffer: KDB: enter: manual escape to debugger panic: from debugger cpuid = 0 Uptime: 19h35m58s Physical memory: 993 MB Dumping 392 MB: 377 361 345 329 313 297 281 265 249 233 217 201 185 169 153 137 121 105 89 73 57 41 25 9 #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:194 #1 0xffffffff80480f05 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xffffffff804813a7 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:563 #3 0xffffffff801bad37 in db_panic (addr=Variable "addr" is not available. ) at ../../../ddb/db_command.c:433 #4 0xffffffff801bb61c in db_command_loop () at ../../../ddb/db_command.c:401 #5 0xffffffff801bd07f in db_trap (type=Variable "type" is not available. ) at ../../../ddb/db_main.c:222 #6 0xffffffff804a89c5 in kdb_trap (type=3, code=0, tf=0xffffffff9ff2a9e0) at ../../../kern/subr_kdb.c:502 #7 0xffffffff8073c4c5 in trap (frame=0xffffffff9ff2a9e0) at ../../../amd64/amd64/trap.c:499 #8 0xffffffff80721dfe in calltrap () at ../../../amd64/amd64/exception.S:169 #9 0xffffffff804a8b91 in kdb_enter (msg=0xffffffff80e20fe0 "") at cpufunc.h:63 #10 0xffffffff803ae691 in scgetc (sc=0xffffffff80b3c5a0, flags=Variable "flags" is not available. ) at ../../../dev/syscons/syscons.c:3378 #11 0xffffffff803b17e4 in sckbdevent (thiskbd=0xffffff0001154a00, event=Variable "event" is not available. ) at ../../../dev/syscons/syscons.c:627 #12 0xffffffff8031be23 in kbdmux_intr (kbd=0xffffff0001154a00, arg=Variable "arg" is not available. ) at ../../../dev/kbdmux/kbdmux.c:549 #13 0xffffffff8031c3a0 in kbdmux_kbd_intr (xkbd=Variable "xkbd" is not available. ) at ../../../dev/kbdmux/kbdmux.c:200 #14 0xffffffff804b2844 in taskqueue_run (queue=0xffffff000117a300) at ../../../kern/subr_taskqueue.c:255 #15 0xffffffff80465c9a in ithread_loop (arg=0xffffff0001104180) at ../../../kern/kern_intr.c:1036 #16 0xffffffff8046348a in fork_exit (callout=0xffffffff80465bc0 , arg=0xffffff0001104180, frame=0xffffffff9ff2ac80) at ../../../kern/kern_fork.c:781 #17 0xffffffff807221ce in fork_trampoline () at ../../../amd64/amd64/exception.S:415 #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000001 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000d7f000 in ?? () #43 0xffffff00011c18d0 in ?? () #44 0xffffffff80a846e0 in facility_initialized () #45 0xffffff00011c18d0 in ?? () #46 0xffffff0001084340 in ?? () #47 0xffffffff9ff2ab70 in ?? () #48 0xffffffff9ff2ab38 in ?? () #49 0xffffff00011bc000 in ?? () #50 0xffffffff8049e826 in sched_switch (td=0xffffff0001104180, newtd=0xffffffff80465bc0, flags=Variable "flags" is not available. ) at ../../../kern/sched_4bsd.c:905 Previous frame inner to this frame (corrupt stack?) On http://dummynetcrash.matthew.sk you can also find the kernel.debug and tha crash files, for more debugging. From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 12:43:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C861065670 for ; Fri, 29 Feb 2008 12:43:28 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 26E408FC13 for ; Fri, 29 Feb 2008 12:43:28 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 174EF3F6189; Fri, 29 Feb 2008 13:43:27 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id C90A63F616D; Fri, 29 Feb 2008 13:43:26 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id B9B169BF12; Fri, 29 Feb 2008 12:43:07 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id B412B405B; Fri, 29 Feb 2008 13:43:07 +0100 (CET) Date: Fri, 29 Feb 2008 13:43:07 +0100 From: Jeremie Le Hen To: Sam Leffler Message-ID: <20080229124307.GC94339@obiwan.tataz.chchile.org> References: <20080226225652.GE56090@obiwan.tataz.chchile.org> <20080227213137.GG56090@obiwan.tataz.chchile.org> <47C60721.9090609@errno.com> <20080228224019.GA94339@obiwan.tataz.chchile.org> <47C77915.7050804@errno.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <47C77915.7050804@errno.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org Subject: Re: Wireless adapter associated, rx ok, tx ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 12:43:28 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sam, On Thu, Feb 28, 2008 at 07:16:37PM -0800, Sam Leffler wrote: > Jeremie Le Hen wrote: > > Thanks for your reply. You are right indeed. It was not obvious to me > > that I should set a tx keyid manually, partly because when setting the > > WEP key, ifconfig(8) assumes key 1 if no index is specified. > > Would it be correct to set the default tx keyid to 1? On the contrary, > > I will provide an update to the manpage stating setting the default tx > > keyid is mandatory. > > Yes, it seems the man page doesn't call out that you need to setup a > deftxkey in order for outbound traffic to be encrypted when using WEP. If > you use wpa_supplicant it will do that for you. > > Please send me something for ifconfig(8). You will find a diff against the ifconfig(8) manpage attached. Feel free to reword what you feel necessary, as I'm not a native english speaker. Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --tThc/1wpZn/ma/RB Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mandatory_deftxkey.diff" Index: sbin/ifconfig/ifconfig.8 =================================================================== RCS file: /mnt/space/freebsd-cvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.145 diff -u -r1.145 ifconfig.8 --- sbin/ifconfig/ifconfig.8 10 Dec 2007 02:31:00 -0000 1.145 +++ sbin/ifconfig/ifconfig.8 29 Feb 2008 12:40:31 -0000 @@ -777,7 +777,8 @@ To disable 802.11h use .Fl doth . .It Cm deftxkey Ar index -Set the default key to use for transmission. +Set the default key to use for transmission, which is mandatory +for full duplex operation. Typically this is only set when using WEP encryption. The .Cm weptxkey @@ -1236,11 +1237,15 @@ .Cm mixed . Modes are case insensitive. .It Cm weptxkey Ar index -Set the WEP key to be used for transmission. +Set the WEP key to be used for transmission, which is mandatory +for full duplex operation. This is the same as setting the default transmission key with .Cm deftxkey . .It Cm wepkey Ar key Ns | Ns Ar index : Ns Ar key Set the selected WEP key. +Yet using +.Cm deftxkey +is required for full duplex operation. If an .Ar index is not given, key 1 is set. --tThc/1wpZn/ma/RB-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 15:35:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF3C21065671; Fri, 29 Feb 2008 15:35:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9E56A8FC1D; Fri, 29 Feb 2008 15:35:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 93FF41CC038; Fri, 29 Feb 2008 07:35:44 -0800 (PST) Date: Fri, 29 Feb 2008 07:35:44 -0800 From: Jeremy Chadwick To: Tim Clewlow Message-ID: <20080229153544.GA94345@eos.sc1.parodius.com> References: <114098.31819.qm@web50308.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <114098.31819.qm@web50308.mail.re2.yahoo.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: PXE on 7.0 problem and solution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 15:35:44 -0000 On Thu, Feb 28, 2008 at 12:30:26PM -0800, Tim Clewlow wrote: > Hi there, > > Installing 7.0 via PXE has a slight problem that is easily worked around. The > file /boot/mfsroot.gz on the installation media needs to be unzipped to make > PXE boot via tftp/nfs work. Otherwise the loader ultimately complains that it > cant find the device to boot from. For example, if you have the installation > media living at /usr/pxe/nfs/ on the PXE server, then do: I documented this in my "how to get FreeBSD to install via PXE and serial console" document: http://jdc.parodius.com/freebsd/pxeboot_serial_install.html I opened a PR at the time of this discovery as well: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120127 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 15:48:56 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8B281065674 for ; Fri, 29 Feb 2008 15:48:56 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 6B72C8FC2B for ; Fri, 29 Feb 2008 15:48:56 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix2-g20.free.fr (Postfix) with ESMTP id 534B423F1EBE for ; Fri, 29 Feb 2008 14:25:29 +0100 (CET) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 142FB3F61AB; Fri, 29 Feb 2008 16:26:02 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id B93903F61EF; Fri, 29 Feb 2008 16:26:01 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 4EDF29BF12; Fri, 29 Feb 2008 15:25:42 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 3FD64405B; Fri, 29 Feb 2008 16:25:42 +0100 (CET) Date: Fri, 29 Feb 2008 16:25:42 +0100 From: Jeremie Le Hen To: Julian Elischer Message-ID: <20080229152542.GD94339@obiwan.tataz.chchile.org> References: <47C44420.6050009@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C44420.6050009@elischer.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: FreeBSD Current Subject: Re: why vimage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 15:48:56 -0000 Hi Julian, On Tue, Feb 26, 2008 at 08:53:52AM -0800, Julian Elischer wrote: > I can give a very simple example of something you can do trivially on > vimage: > > Make three virtual machines on yhour laptop: > The base machine and two others. > Have the first 'other' machine be assigned an IP address on > your HOME LAN. > have the second virtual machine have an IP adddress on > your WORK LAN. > use the base machine to run encrypted tunnels from where-ever > you happen to be to your work and home.. when you put the laptop to sleep > (assuming the tcp sessions are quiescent (no keepalives)) > then when you wake it up say an hour later.. as soon as the base machine has > an IP address.. viola, your session on the virtual > machines are still alive. On this post [1], Marko states: % Each NICs is logically attached to one and only one network stack % instance at a time, and it receives data from upper layers and feeds % the upper layers with mbufs in exactly the same manner as it does on % the standard kernel. It is the link layer that demultiplexes the % incoming traffic to the appropriate stack instance... As I understand it, there is only one vimage per interface. I'm surely wrong or the setup you described wouldn't be possible. Any explanation will be welcome :). Thanks, [1] http://lists.freebsd.org/pipermail/freebsd-current/2008-February/083908.html Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 16:09:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDA821065670 for ; Fri, 29 Feb 2008 16:09:53 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63903.mail.re1.yahoo.com (web63903.mail.re1.yahoo.com [69.147.97.118]) by mx1.freebsd.org (Postfix) with SMTP id 994568FC12 for ; Fri, 29 Feb 2008 16:09:53 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 94275 invoked by uid 60001); 29 Feb 2008 15:43:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SNHmNjeJ4NlAkz+DRSI+OC3oSQSCn+uS1BdbGZ6kr7BpcG19q1wJ6dLwqk2hdVRwM6sC62TGJwYAU6N/Y1LUf/3fx3S2dqmeF091CA3JfIdTHhiPxqPqo288K6NUlTSMonyaJiRUoYg7okJT9AxHoquEtHJNNayT9hIMOq/JsVQ=; X-YMail-OSG: aplDZqUVM1mxbizdHCFHLDiso6nbuokq7DKu6I.I04otahI6AVcDyId0BDNp8VGl5A-- Received: from [98.203.28.38] by web63903.mail.re1.yahoo.com via HTTP; Fri, 29 Feb 2008 07:43:12 PST Date: Fri, 29 Feb 2008 07:43:12 -0800 (PST) From: Barney Cordoba To: matthew In-Reply-To: <47C7FC8A.4050906@matthew.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <506309.93775.qm@web63903.mail.re1.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0 Beta, RC, RELEASE (amd64) freezes with dummynet enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 16:09:54 -0000 --- matthew wrote: > Kris Kennaway wrote: > > > matthew wrote: > >> I have posted before that i have a stability > issue with the 7.0 branch > >> on my servers. Tested on > BETA2,BETA4,RC1,RC2,RELEASE > >> > >> The original thread and my post with details is > at: > >> > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-12/msg00674.html > > >> > >> > >> I was waiting for the 7.0-RELEASE, updated the > whole servers, and > >> enabled dummynet again, but it always freezes > after some minutes, 100% > >> reproducible. > >> > >> I tested it also on a HP 140 G3 1U server, where > 6.3 has absolutely no > >> problems, but the 7.0 branch keeps freezing. > >> > >> Again, if it helps to solve this bug, i can > rebuild the kernel with > >> debug symbols a take some screenshots :) > >> > >> _______________________________________________ > >> 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" > >> > >> > > > > Please follow the steps at > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > > > > > > > Kris > > _______________________________________________ > > 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 have some screenshots from debug console after the > freeze, i hade to > replace the keyboard with a working ESC key to > launch the ctrl+alt+esc:) > > You can find it on http://dummynetcrash.matthew.sk/ > > Sorry for the bad quality of some pictures. > > I have also a dump, after running panic in the debug > console: > > (gdb) > root@hanka:/usr/src/sys/amd64/compile/HANKA-debug# > kgdb > kernel.debug /var/crash/vmcore.1 > [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 "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > KDB: enter: manual escape to debugger > panic: from debugger > cpuid = 0 > Uptime: 19h35m58s > Physical memory: 993 MB > Dumping 392 MB: 377 361 345 329 313 297 281 265 249 > 233 217 201 185 169 > 153 137 121 105 89 73 57 41 25 9 > > #0 doadump () at pcpu.h:194 > 194 __asm __volatile("movq %%gs:0,%0" : > "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:194 > #1 0xffffffff80480f05 in boot (howto=260) at > ../../../kern/kern_shutdown.c:409 > #2 0xffffffff804813a7 in panic (fmt=Variable "fmt" > is not available. > ) at ../../../kern/kern_shutdown.c:563 > #3 0xffffffff801bad37 in db_panic (addr=Variable > "addr" is not available. > ) at ../../../ddb/db_command.c:433 > #4 0xffffffff801bb61c in db_command_loop () at > ../../../ddb/db_command.c:401 > #5 0xffffffff801bd07f in db_trap (type=Variable > "type" is not available. > ) at ../../../ddb/db_main.c:222 > #6 0xffffffff804a89c5 in kdb_trap (type=3, code=0, > tf=0xffffffff9ff2a9e0) at > ../../../kern/subr_kdb.c:502 > #7 0xffffffff8073c4c5 in trap > (frame=0xffffffff9ff2a9e0) at > ../../../amd64/amd64/trap.c:499 > #8 0xffffffff80721dfe in calltrap () at > ../../../amd64/amd64/exception.S:169 > #9 0xffffffff804a8b91 in kdb_enter > (msg=0xffffffff80e20fe0 "") at > cpufunc.h:63 > #10 0xffffffff803ae691 in scgetc > (sc=0xffffffff80b3c5a0, flags=Variable > "flags" is not available. > ) at ../../../dev/syscons/syscons.c:3378 > #11 0xffffffff803b17e4 in sckbdevent > (thiskbd=0xffffff0001154a00, > event=Variable "event" is not available. > ) at ../../../dev/syscons/syscons.c:627 > #12 0xffffffff8031be23 in kbdmux_intr > (kbd=0xffffff0001154a00, > arg=Variable "arg" is not available. > ) at ../../../dev/kbdmux/kbdmux.c:549 > #13 0xffffffff8031c3a0 in kbdmux_kbd_intr > (xkbd=Variable "xkbd" is not > available. > ) at ../../../dev/kbdmux/kbdmux.c:200 > #14 0xffffffff804b2844 in taskqueue_run > (queue=0xffffff000117a300) at > ../../../kern/subr_taskqueue.c:255 > #15 0xffffffff80465c9a in ithread_loop > (arg=0xffffff0001104180) at > ../../../kern/kern_intr.c:1036 > #16 0xffffffff8046348a in fork_exit > (callout=0xffffffff80465bc0 > , arg=0xffffff0001104180, > frame=0xffffffff9ff2ac80) > at ../../../kern/kern_fork.c:781 > #17 0xffffffff807221ce in fork_trampoline () at > ../../../amd64/amd64/exception.S:415 > #18 0x0000000000000000 in ?? () > #19 0x0000000000000000 in ?? () > #20 0x0000000000000001 in ?? () > #21 0x0000000000000000 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000000000 in ?? () > #40 0x0000000000000000 in ?? () > #41 0x0000000000000000 in ?? () > #42 0x0000000000d7f000 in ?? () > #43 0xffffff00011c18d0 in ?? () > #44 0xffffffff80a846e0 in facility_initialized () > #45 0xffffff00011c18d0 in ?? () > #46 0xffffff0001084340 in ?? () > #47 0xffffffff9ff2ab70 in ?? () > #48 0xffffffff9ff2ab38 in ?? () > #49 0xffffff00011bc000 in ?? () > #50 0xffffffff8049e826 in sched_switch > (td=0xffffff0001104180, > newtd=0xffffffff80465bc0, flags=Variable "flags" is > not available. > ) at ../../../kern/sched_4bsd.c:905 > Previous frame inner to this frame (corrupt stack?) > > On http://dummynetcrash.matthew.sk you can also find > the kernel.debug > and tha crash files, for more debugging. Have you tried your setup without polling? It really doesn't make any sense to poll when using controllers that have interrupt hold offs that can be precisely programmed like the em controllers. But it will certain give insight to your problem if one works and the other doesn't. I'd also try it on a 32bit compile. Otherwise you have too many variables. Barney ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 17:44:30 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B67E91065670 for ; Fri, 29 Feb 2008 17:44:30 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from mail.blinkt.de (mail.blinkt.de [88.198.169.219]) by mx1.freebsd.org (Postfix) with ESMTP id 767D88FC12 for ; Fri, 29 Feb 2008 17:44:30 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from dslb-084-061-146-006.pools.arcor-ip.net ([84.61.146.6] helo=styx.local) by mail.blinkt.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV8lN-0001Aw-Sb; Fri, 29 Feb 2008 18:11:13 +0100 Message-ID: <47C83CB1.6000902@uni-paderborn.de> Date: Fri, 29 Feb 2008 18:11:13 +0100 From: Arne Schwabe User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Jeremie Le Hen References: <47C44420.6050009@elischer.org> <20080229152542.GD94339@obiwan.tataz.chchile.org> In-Reply-To: <20080229152542.GD94339@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , FreeBSD Current Subject: Re: why vimage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 17:44:30 -0000 Jeremie Le Hen schrieb: > Hi Julian, > > On Tue, Feb 26, 2008 at 08:53:52AM -0800, Julian Elischer wrote: > >> I can give a very simple example of something you can do trivially on >> vimage: >> >> Make three virtual machines on yhour laptop: >> The base machine and two others. >> Have the first 'other' machine be assigned an IP address on >> your HOME LAN. >> have the second virtual machine have an IP adddress on >> your WORK LAN. >> use the base machine to run encrypted tunnels from where-ever >> you happen to be to your work and home.. when you put the laptop to sleep >> (assuming the tcp sessions are quiescent (no keepalives)) >> then when you wake it up say an hour later.. as soon as the base machine has >> an IP address.. viola, your session on the virtual >> machines are still alive. >> > > On this post [1], Marko states: > > % Each NICs is logically attached to one and only one network stack > % instance at a time, and it receives data from upper layers and feeds > % the upper layers with mbufs in exactly the same manner as it does on > % the standard kernel. It is the link layer that demultiplexes the > % incoming traffic to the appropriate stack instance... > > As I understand it, there is only one vimage per interface. I'm surely > wrong or the setup you described wouldn't be possible. > > Any explanation will be welcome :). > Thanks, > I am sure you can use the bridge interface for this. Arne From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 19:12:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47E1C106568B; Fri, 29 Feb 2008 19:12:27 +0000 (UTC) (envelope-from gregoryd.freebsd@free.fr) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id C810D8FC23; Fri, 29 Feb 2008 19:12:26 +0000 (UTC) (envelope-from gregoryd.freebsd@free.fr) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by postfix1-g20.free.fr (Postfix) with ESMTP id 29AAE2355E2F; Fri, 29 Feb 2008 19:49:52 +0100 (CET) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 83DF217F56F; Fri, 29 Feb 2008 19:49:50 +0100 (CET) Received: from imp6-g19.free.fr (imp6-g19.free.fr [212.27.42.6]) by smtp8-g19.free.fr (Postfix) with ESMTP id 5546817F534; Fri, 29 Feb 2008 19:49:49 +0100 (CET) Received: by imp6-g19.free.fr (Postfix, from userid 33) id A05954384; Fri, 29 Feb 2008 19:49:43 +0100 (CET) Received: from mar44-4-88-161-154-223.fbx.proxad.net (mar44-4-88-161-154-223.fbx.proxad.net [88.161.154.223]) by imp.free.fr (IMP) with HTTP for ; Fri, 29 Feb 2008 19:49:43 +0100 Message-ID: <1204310983.47c853c70577d@imp.free.fr> Date: Fri, 29 Feb 2008 19:49:43 +0100 From: gregoryd.freebsd@free.fr To: Ken Smith References: <1204151575.84335.3.camel@neo.cse.buffalo.edu> In-Reply-To: <1204151575.84335.3.camel@neo.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-Originating-IP: 88.161.154.223 X-Mailman-Approved-At: Fri, 29 Feb 2008 19:30:09 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: FreeBSD 7.0-RELEASE Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 19:12:27 -0000 Quoting Ken Smith : Hi ! > On behalf of the FreeBSD Project thanks for your interest in FreeBSD. > We hope you enjoy the new release. I've just spent the whole morning installing it on my office desktop. It was an awful experience: installing packages from the three CDs kept making me switch from one CD to the other then to the previous one before the next one again... All in all about twenty-times !!! (sometimes just for ONE package, for Christ's sake !) It was particularly annoying, especially with those Linux guys around sneering when comparing it to their smooth install. I really think we should do something about it. Either group the packages with dependencies together on a same CD, or let the installer mark packages belonging to another CD as "dirty" and make it try to install them later in a second pass... I don't know... I guess a DVD release would more than help: all the packages would be on a single disc (plus, we might add some more). Then again, that wouldn't solve the problem of people needing to install it from CDs, though. (I'm aware scripts exist on the web to group iso's together and make a DVD, but I'm talking of a properly released one) I hadn't been aware of that until today, since at home I upgrade with the usual source compiling steps. But in my office there is no internet connection available for that kind of operations, so I had to recourse to the CDs... That didn't help me convince the GNU/Linux users (although some really were interested, because they enjoy our documentation...). But I especially find it regrettable that a minor annoyances such as these "spoil", in a way, all the good work that's done for the OS itself :-( Even more so when keeping in mind people coming from other OS backgrounds and wanting to use it as a desktop OS: more thant the appearance of the installer (which I keep thinking is definitely efficacious, however spartan) it is that problem with CD-toasting just to install packages that might prove a deterrent :-( That said, I'm all too willing to give a hand to people in charge with this issue. And yes, thank you all again *very much* for bringing 7.0 ! gregory From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 21:32:36 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65F891065680 for ; Fri, 29 Feb 2008 21:32:36 +0000 (UTC) (envelope-from matthew@matthew.sk) Received: from mailserver.antik.sk (mailserver.antik.sk [88.212.10.6]) by mx1.freebsd.org (Postfix) with ESMTP id 958CE8FC13 for ; Fri, 29 Feb 2008 21:32:35 +0000 (UTC) (envelope-from matthew@matthew.sk) Received: (qmail 5265 invoked from network); 29 Feb 2008 22:32:33 +0100 Received: by simscan 1.4.0 ppid: 5258, pid: 5262, t: 0.0361s scanners: regex: 1.4.0 attach: 1.4.0 clamav: 0.91.2/m:45/d:6030 Received: from unknown (HELO ?172.16.121.190?) (matthew@matthew.sk@172.16.121.190) by mailserver.antik.sk with AES256-SHA encrypted SMTP; 29 Feb 2008 22:32:33 +0100 Message-ID: <47C879F1.6000407@matthew.sk> Date: Fri, 29 Feb 2008 22:32:33 +0100 From: matthew User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: Barney Cordoba References: <506309.93775.qm@web63903.mail.re1.yahoo.com> In-Reply-To: <506309.93775.qm@web63903.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0 Beta, RC, RELEASE (amd64) freezes with dummynet enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 21:32:36 -0000 Barney Cordoba wrote: > --- matthew wrote: > > >> Kris Kennaway wrote: >> >> >>> matthew wrote: >>> >>>> I have posted before that i have a stability >>>> >> issue with the 7.0 branch >> >>>> on my servers. Tested on >>>> >> BETA2,BETA4,RC1,RC2,RELEASE >> >>>> The original thread and my post with details is >>>> >> at: >> > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-12/msg00674.html > >>>> I was waiting for the 7.0-RELEASE, updated the >>>> >> whole servers, and >> >>>> enabled dummynet again, but it always freezes >>>> >> after some minutes, 100% >> >>>> reproducible. >>>> >>>> I tested it also on a HP 140 G3 1U server, where >>>> >> 6.3 has absolutely no >> >>>> problems, but the 7.0 branch keeps freezing. >>>> >>>> Again, if it helps to solve this bug, i can >>>> >> rebuild the kernel with >> >>>> debug symbols a take some screenshots :) >>>> >>>> _______________________________________________ >>>> 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" >>>> >>>> >>>> >>> Please follow the steps at >>> >>> >>> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > >>> Kris >>> _______________________________________________ >>> 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 have some screenshots from debug console after the >> freeze, i hade to >> replace the keyboard with a working ESC key to >> launch the ctrl+alt+esc:) >> >> You can find it on http://dummynetcrash.matthew.sk/ >> >> Sorry for the bad quality of some pictures. >> >> I have also a dump, after running panic in the debug >> console: >> >> (gdb) >> root@hanka:/usr/src/sys/amd64/compile/HANKA-debug# >> kgdb >> kernel.debug /var/crash/vmcore.1 >> [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 "amd64-marcel-freebsd". >> >> Unread portion of the kernel message buffer: >> KDB: enter: manual escape to debugger >> panic: from debugger >> cpuid = 0 >> Uptime: 19h35m58s >> Physical memory: 993 MB >> Dumping 392 MB: 377 361 345 329 313 297 281 265 249 >> 233 217 201 185 169 >> 153 137 121 105 89 73 57 41 25 9 >> >> #0 doadump () at pcpu.h:194 >> 194 __asm __volatile("movq %%gs:0,%0" : >> "=r" (td)); >> (kgdb) backtrace >> #0 doadump () at pcpu.h:194 >> #1 0xffffffff80480f05 in boot (howto=260) at >> ../../../kern/kern_shutdown.c:409 >> #2 0xffffffff804813a7 in panic (fmt=Variable "fmt" >> is not available. >> ) at ../../../kern/kern_shutdown.c:563 >> #3 0xffffffff801bad37 in db_panic (addr=Variable >> "addr" is not available. >> ) at ../../../ddb/db_command.c:433 >> #4 0xffffffff801bb61c in db_command_loop () at >> ../../../ddb/db_command.c:401 >> #5 0xffffffff801bd07f in db_trap (type=Variable >> "type" is not available. >> ) at ../../../ddb/db_main.c:222 >> #6 0xffffffff804a89c5 in kdb_trap (type=3, code=0, >> tf=0xffffffff9ff2a9e0) at >> ../../../kern/subr_kdb.c:502 >> #7 0xffffffff8073c4c5 in trap >> (frame=0xffffffff9ff2a9e0) at >> ../../../amd64/amd64/trap.c:499 >> #8 0xffffffff80721dfe in calltrap () at >> ../../../amd64/amd64/exception.S:169 >> #9 0xffffffff804a8b91 in kdb_enter >> (msg=0xffffffff80e20fe0 "") at >> cpufunc.h:63 >> #10 0xffffffff803ae691 in scgetc >> (sc=0xffffffff80b3c5a0, flags=Variable >> "flags" is not available. >> ) at ../../../dev/syscons/syscons.c:3378 >> #11 0xffffffff803b17e4 in sckbdevent >> (thiskbd=0xffffff0001154a00, >> event=Variable "event" is not available. >> ) at ../../../dev/syscons/syscons.c:627 >> #12 0xffffffff8031be23 in kbdmux_intr >> (kbd=0xffffff0001154a00, >> arg=Variable "arg" is not available. >> ) at ../../../dev/kbdmux/kbdmux.c:549 >> #13 0xffffffff8031c3a0 in kbdmux_kbd_intr >> (xkbd=Variable "xkbd" is not >> available. >> ) at ../../../dev/kbdmux/kbdmux.c:200 >> #14 0xffffffff804b2844 in taskqueue_run >> (queue=0xffffff000117a300) at >> ../../../kern/subr_taskqueue.c:255 >> #15 0xffffffff80465c9a in ithread_loop >> (arg=0xffffff0001104180) at >> ../../../kern/kern_intr.c:1036 >> #16 0xffffffff8046348a in fork_exit >> (callout=0xffffffff80465bc0 >> , arg=0xffffff0001104180, >> frame=0xffffffff9ff2ac80) >> at ../../../kern/kern_fork.c:781 >> #17 0xffffffff807221ce in fork_trampoline () at >> ../../../amd64/amd64/exception.S:415 >> #18 0x0000000000000000 in ?? () >> #19 0x0000000000000000 in ?? () >> #20 0x0000000000000001 in ?? () >> #21 0x0000000000000000 in ?? () >> #22 0x0000000000000000 in ?? () >> #23 0x0000000000000000 in ?? () >> #24 0x0000000000000000 in ?? () >> #25 0x0000000000000000 in ?? () >> #26 0x0000000000000000 in ?? () >> #27 0x0000000000000000 in ?? () >> #28 0x0000000000000000 in ?? () >> #29 0x0000000000000000 in ?? () >> #30 0x0000000000000000 in ?? () >> #31 0x0000000000000000 in ?? () >> #32 0x0000000000000000 in ?? () >> #33 0x0000000000000000 in ?? () >> #34 0x0000000000000000 in ?? () >> #35 0x0000000000000000 in ?? () >> #36 0x0000000000000000 in ?? () >> #37 0x0000000000000000 in ?? () >> #38 0x0000000000000000 in ?? () >> #39 0x0000000000000000 in ?? () >> #40 0x0000000000000000 in ?? () >> #41 0x0000000000000000 in ?? () >> #42 0x0000000000d7f000 in ?? () >> #43 0xffffff00011c18d0 in ?? () >> #44 0xffffffff80a846e0 in facility_initialized () >> #45 0xffffff00011c18d0 in ?? () >> #46 0xffffff0001084340 in ?? () >> #47 0xffffffff9ff2ab70 in ?? () >> #48 0xffffffff9ff2ab38 in ?? () >> #49 0xffffff00011bc000 in ?? () >> #50 0xffffffff8049e826 in sched_switch >> (td=0xffffff0001104180, >> newtd=0xffffffff80465bc0, flags=Variable "flags" is >> not available. >> ) at ../../../kern/sched_4bsd.c:905 >> Previous frame inner to this frame (corrupt stack?) >> >> On http://dummynetcrash.matthew.sk you can also find >> the kernel.debug >> and tha crash files, for more debugging. >> > > Have you tried your setup without polling? It really > doesn't make any sense to poll when using controllers > that have interrupt hold offs that can be precisely > programmed like the em controllers. But it will > certain give insight to your problem if one works and > the other doesn't. > > I'd also try it on a 32bit compile. Otherwise you have > too many variables. > > Barney > > > ____________________________________________________________________________________ > Looking for last minute shopping deals? > Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping > _______________________________________________ > 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 disabled the polling, for my suprise, the server didn`t crashed after some minutes, but after 1 hour, but crushed, maybe only a coincidence, but maybe not. The resukt is the same, it crashed. It also crashed on the HP 140 G3 server with bge NIC without polling enabled on the RC2 release. From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 23:27:00 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 402DB106566C; Fri, 29 Feb 2008 23:27:00 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 16F4E8FC16; Fri, 29 Feb 2008 23:27:00 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id BF4A4AA2D2; Fri, 29 Feb 2008 18:26:59 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 29 Feb 2008 18:26:59 -0500 X-Sasl-enc: 5wUlb+40ea9chUBcM5KUGGnvzrqy2D9gSNivkPFusxXn 1204327619 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 ESMTPSA id D8A5123B1D; Fri, 29 Feb 2008 18:26:58 -0500 (EST) Message-ID: <47C894C2.6020104@incunabulum.net> Date: Fri, 29 Feb 2008 23:26:58 +0000 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> <86d4qh2u13.fsf@ds4.des.no> In-Reply-To: <86d4qh2u13.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Marko Zec , Marko Zec , Marko Zec , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 23:27:00 -0000 Dag-Erling Sm=F8rgrav wrote: > "Bruce M. Simpson" writes: > =20 >> * Do you mean to say that IMUNES/vimage has expanded beyond merely >> wrapping the network stack and virtualizing that? >> >> If this is the case (it introduces some new virtualization technique >> on par with the functionality of e.g. Xen) then I outright DISAGREE >> with its introduction into the source tree on the grounds that it's >> too experimental. >> =20 > > Well, it's only been discussed and developed and presented at every > single BSD conference for the last, oh, three years or so, so yes, it's= > obviously highly immature and experimental code. > =20 My point above was referring to the ambiguity present in Julian's message to the list, which seemed to suggest the remit of vimage had increased beyond network virtualization. How often a given topic is discussed is not analogous to in-depth testing. Surely someone as experienced as yourself is aware of this. Are you sure you read my message fully before responding to this thread? > I'll have my virtual bikeshed blue, if you please. > =20 I observe that your definition of the term bikeshed seems very subjective= =2E Nothing wrong with "Are you sure Y/N", to my mind, and if one further re-reads this thread, one will see that there are issues around vimage which have had to be teased out from others, and addressed, which Marko has already responded to. regards, BMS From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 23:36:32 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79A321065683; Fri, 29 Feb 2008 23:36:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 36EFA8FC19; Fri, 29 Feb 2008 23:36:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1TNaUTc000721; Fri, 29 Feb 2008 18:36:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1TNaUZs066216; Fri, 29 Feb 2008 18:36:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4A9FC73039; Fri, 29 Feb 2008 18:36:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080229233630.4A9FC73039@freebsd-current.sentex.ca> Date: Fri, 29 Feb 2008 18:36:30 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 23:36:32 -0000 TB --- 2008-02-29 22:20:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-29 22:20:30 - starting HEAD tinderbox run for i386/i386 TB --- 2008-02-29 22:20:30 - cleaning the object tree TB --- 2008-02-29 22:21:01 - cvsupping the source tree TB --- 2008-02-29 22:21:01 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-02-29 22:21:08 - building world (CFLAGS=-O -pipe) TB --- 2008-02-29 22:21:08 - cd /src TB --- 2008-02-29 22:21:08 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 29 22:21:10 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Feb 29 23:24:04 UTC 2008 TB --- 2008-02-29 23:24:04 - generating LINT kernel config TB --- 2008-02-29 23:24:04 - cd /src/sys/i386/conf TB --- 2008-02-29 23:24:04 - /usr/bin/make -B LINT TB --- 2008-02-29 23:24:05 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-29 23:24:05 - cd /src TB --- 2008-02-29 23:24:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 29 23:24:05 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/em/../../dev/em/if_em.c:2693: error: 'em_handle_rx' undeclared (first use in this function) /src/sys/modules/em/../../dev/em/if_em.c:2693: error: (Each undeclared identifier is reported only once /src/sys/modules/em/../../dev/em/if_em.c:2693: error: for each function it appears in.) /src/sys/modules/em/../../dev/em/if_em.c:2694: error: 'em_handle_tx' undeclared (first use in this function) /src/sys/modules/em/../../dev/em/if_em.c:2695: error: 'em_handle_link' undeclared (first use in this function) /src/sys/modules/em/../../dev/em/if_em.c:2707: error: 'em_rx_fast' undeclared (first use in this function) /src/sys/modules/em/../../dev/em/if_em.c:2715: error: 'em_tx_fast' undeclared (first use in this function) /src/sys/modules/em/../../dev/em/if_em.c:2723: error: 'em_link_fast' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/modules/em. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-29 23:36:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-29 23:36:30 - ERROR: failed to build lint kernel TB --- 2008-02-29 23:36:30 - tinderbox aborted TB --- 3352.52 user 400.12 system 4560.02 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 29 23:25:12 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05F051065673; Fri, 29 Feb 2008 23:25:12 +0000 (UTC) (envelope-from bms@icir.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id D14718FC19; Fri, 29 Feb 2008 23:25:11 +0000 (UTC) (envelope-from bms@icir.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 18392AA19B; Fri, 29 Feb 2008 18:25:11 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 29 Feb 2008 18:25:11 -0500 X-Sasl-enc: OCOV0YHJst2endcUas7HBmBCINyZGEUQiEHnQ13zZiiO 1204327510 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 ESMTPSA id 20B9F23F47; Fri, 29 Feb 2008 18:25:10 -0500 (EST) Message-ID: <47C89455.1060203@icir.org> Date: Fri, 29 Feb 2008 23:25:09 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> <86d4qh2u13.fsf@ds4.des.no> In-Reply-To: <86d4qh2u13.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 29 Feb 2008 23:50:23 +0000 Cc: Marko Zec , Marko Zec , Marko Zec , Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Feb 2008 23:25:12 -0000 Dag-Erling Sm=F8rgrav wrote: > "Bruce M. Simpson" writes: > =20 >> * Do you mean to say that IMUNES/vimage has expanded beyond merely >> wrapping the network stack and virtualizing that? >> >> If this is the case (it introduces some new virtualization technique >> on par with the functionality of e.g. Xen) then I outright DISAGREE >> with its introduction into the source tree on the grounds that it's >> too experimental. >> =20 > > Well, it's only been discussed and developed and presented at every > single BSD conference for the last, oh, three years or so, so yes, it's= > obviously highly immature and experimental code. > =20 My point above was referring to the ambiguity present in Julian's=20 message to the list, which seemed to suggest the remit of vimage had=20 increased beyond network virtualization. How often a given topic is discussed is not analogous to in-depth=20 testing. Surely someone as experienced as yourself is aware of this. Are = you sure you read my message fully before responding to this thread? > I'll have my virtual bikeshed blue, if you please. > =20 I observe that your definition of the term bikeshed seems very subjective= =2E Nothing wrong with "Are you sure Y/N", to my mind, and if one further=20 re-reads this thread, one will see that there are issues around vimage=20 which have had to be teased out from others, and addressed, which Marko=20 has already responded to. regards, BMS From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 00:37:00 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04E601065674; Sat, 1 Mar 2008 00:37:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B42DE8FC1A; Sat, 1 Mar 2008 00:36:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m210aw6Y057657; Fri, 29 Feb 2008 19:36:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m210awcm016652; Fri, 29 Feb 2008 19:36:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7F29973039; Fri, 29 Feb 2008 19:36:58 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301003658.7F29973039@freebsd-current.sentex.ca> Date: Fri, 29 Feb 2008 19:36:58 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 00:37:00 -0000 TB --- 2008-02-29 23:22:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-29 23:22:59 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-02-29 23:22:59 - cleaning the object tree TB --- 2008-02-29 23:23:22 - cvsupping the source tree TB --- 2008-02-29 23:23:22 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-02-29 23:23:33 - building world (CFLAGS=-O -pipe) TB --- 2008-02-29 23:23:33 - cd /src TB --- 2008-02-29 23:23:33 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 29 23:23:34 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 1 00:25:35 UTC 2008 TB --- 2008-03-01 00:25:35 - generating LINT kernel config TB --- 2008-03-01 00:25:35 - cd /src/sys/pc98/conf TB --- 2008-03-01 00:25:35 - /usr/bin/make -B LINT TB --- 2008-03-01 00:25:35 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-01 00:25:35 - cd /src TB --- 2008-03-01 00:25:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 1 00:25:35 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/modules/igb/../../dev/igb/if_igb.c: In function 'igb_print_debug_info': /src/sys/modules/igb/../../dev/igb/if_igb.c:4210: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4212: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4214: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4222: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4224: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4226: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' *** Error code 1 Stop in /src/sys/modules/igb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 00:36:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 00:36:58 - ERROR: failed to build lint kernel TB --- 2008-03-01 00:36:58 - tinderbox aborted TB --- 3281.20 user 407.21 system 4439.25 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 01:01:20 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E76A41065678; Sat, 1 Mar 2008 01:01:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3BC8FC1D; Sat, 1 Mar 2008 01:01:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2111I2h059147; Fri, 29 Feb 2008 20:01:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2111IQC019742; Fri, 29 Feb 2008 20:01:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B91FA73039; Fri, 29 Feb 2008 20:01:18 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301010118.B91FA73039@freebsd-current.sentex.ca> Date: Fri, 29 Feb 2008 20:01:18 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 01:01:20 -0000 TB --- 2008-02-29 23:36:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-29 23:36:30 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-02-29 23:36:30 - cleaning the object tree TB --- 2008-02-29 23:36:53 - cvsupping the source tree TB --- 2008-02-29 23:36:53 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-02-29 23:37:00 - building world (CFLAGS=-O -pipe) TB --- 2008-02-29 23:37:00 - cd /src TB --- 2008-02-29 23:37:00 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 29 23:37:01 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 1 00:48:17 UTC 2008 TB --- 2008-03-01 00:48:17 - generating LINT kernel config TB --- 2008-03-01 00:48:17 - cd /src/sys/ia64/conf TB --- 2008-03-01 00:48:17 - /usr/bin/make -B LINT TB --- 2008-03-01 00:48:17 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-01 00:48:17 - cd /src TB --- 2008-03-01 00:48:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 1 00:48:17 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> export_syms awk -f /src/sys/modules/if_vlan/../../conf/kmod_syms.awk if_vlan.kld export_syms | xargs -J% objcopy % if_vlan.kld ld -Bshareable -d -warn-common -o if_vlan.ko if_vlan.kld objcopy --strip-debug if_vlan.ko ===> igb (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/igb/../../dev/igb -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/ia64/src/sys/LINT -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/igb/../../dev/igb/if_igb.c /src/sys/modules/igb/../../dev/igb/if_igb.c: In function 'igb_fixup_rx': /src/sys/modules/igb/../../dev/igb/if_igb.c:3794: error: 'struct adapter' has no member named 'fmp' *** Error code 1 Stop in /src/sys/modules/igb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 01:01:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 01:01:18 - ERROR: failed to build lint kernel TB --- 2008-03-01 01:01:18 - tinderbox aborted TB --- 3822.29 user 401.30 system 5088.28 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 01:41:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40B4E106566B for ; Sat, 1 Mar 2008 01:41:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outD.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 2A11C8FC1C for ; Sat, 1 Mar 2008 01:41:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 29 Feb 2008 17:41:10 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 9138F2D6014; Fri, 29 Feb 2008 17:41:09 -0800 (PST) Message-ID: <47C8B448.7050005@elischer.org> Date: Fri, 29 Feb 2008 17:41:28 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jeremie Le Hen References: <47C44420.6050009@elischer.org> <20080229152542.GD94339@obiwan.tataz.chchile.org> In-Reply-To: <20080229152542.GD94339@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: why vimage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 01:41:11 -0000 Jeremie Le Hen wrote: > Hi Julian, > > On Tue, Feb 26, 2008 at 08:53:52AM -0800, Julian Elischer wrote: >> I can give a very simple example of something you can do trivially on >> vimage: >> >> Make three virtual machines on yhour laptop: >> The base machine and two others. >> Have the first 'other' machine be assigned an IP address on >> your HOME LAN. >> have the second virtual machine have an IP adddress on >> your WORK LAN. >> use the base machine to run encrypted tunnels from where-ever >> you happen to be to your work and home.. when you put the laptop to sleep >> (assuming the tcp sessions are quiescent (no keepalives)) >> then when you wake it up say an hour later.. as soon as the base machine has >> an IP address.. viola, your session on the virtual >> machines are still alive. > > On this post [1], Marko states: > > % Each NICs is logically attached to one and only one network stack > % instance at a time, and it receives data from upper layers and feeds > % the upper layers with mbufs in exactly the same manner as it does on > % the standard kernel. It is the link layer that demultiplexes the > % incoming traffic to the appropriate stack instance... > > As I understand it, there is only one vimage per interface. I'm surely > wrong or the setup you described wouldn't be possible. > physical interfaces can be forked out to several virtual interfaces which can be in different virtual machines.. Or the virtual interfaces could be connected to tunnels. > Any explanation will be welcome :). > Thanks, > > [1] http://lists.freebsd.org/pipermail/freebsd-current/2008-February/083908.html > > Regards, From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 01:42:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88F4A1065673; Sat, 1 Mar 2008 01:42:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2F36C8FC2A; Sat, 1 Mar 2008 01:42:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m211gAJe061718; Fri, 29 Feb 2008 20:42:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m211gAJn069490; Fri, 29 Feb 2008 20:42:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 41C3173039; Fri, 29 Feb 2008 20:42:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301014210.41C3173039@freebsd-current.sentex.ca> Date: Fri, 29 Feb 2008 20:42:10 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 01:42:11 -0000 TB --- 2008-03-01 00:36:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 00:36:58 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-03-01 00:36:58 - cleaning the object tree TB --- 2008-03-01 00:37:19 - cvsupping the source tree TB --- 2008-03-01 00:37:19 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-03-01 00:37:28 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 00:37:28 - cd /src TB --- 2008-03-01 00:37:28 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 00:37:30 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 1 01:40:31 UTC 2008 TB --- 2008-03-01 01:40:31 - generating LINT kernel config TB --- 2008-03-01 01:40:31 - cd /src/sys/powerpc/conf TB --- 2008-03-01 01:40:31 - /usr/bin/make -B LINT TB --- 2008-03-01 01:40:32 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-01 01:40:32 - cd /src TB --- 2008-03-01 01:40:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 1 01:40:32 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] "Makefile", line 2596: warning: duplicate script for target "e1000_manage.ln" ignored "Makefile", line 2599: warning: duplicate script for target "e1000_manage.o" ignored "Makefile", line 2602: warning: duplicate script for target "e1000_nvm.ln" ignored "Makefile", line 2605: warning: duplicate script for target "e1000_nvm.o" ignored "Makefile", line 2608: warning: duplicate script for target "e1000_phy.ln" ignored "Makefile", line 2611: warning: duplicate script for target "e1000_phy.o" ignored cc: /src/sys/dev/em/e1000_82575.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 01:42:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 01:42:10 - ERROR: failed to build lint kernel TB --- 2008-03-01 01:42:10 - tinderbox aborted TB --- 2891.13 user 342.13 system 3911.52 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 02:03:51 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C01F21065672; Sat, 1 Mar 2008 02:03:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 651C58FC17; Sat, 1 Mar 2008 02:03:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2123ohv062699; Fri, 29 Feb 2008 21:03:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2123oTB065907; Fri, 29 Feb 2008 21:03:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0BB6173039; Fri, 29 Feb 2008 21:03:50 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301020350.0BB6173039@freebsd-current.sentex.ca> Date: Fri, 29 Feb 2008 21:03:50 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 02:03:51 -0000 TB --- 2008-03-01 01:01:18 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 01:01:18 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-03-01 01:01:18 - cleaning the object tree TB --- 2008-03-01 01:01:48 - cvsupping the source tree TB --- 2008-03-01 01:01:48 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-03-01 01:01:55 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 01:01:55 - cd /src TB --- 2008-03-01 01:01:55 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 01:01:56 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 1 02:02:05 UTC 2008 TB --- 2008-03-01 02:02:05 - generating LINT kernel config TB --- 2008-03-01 02:02:05 - cd /src/sys/sparc64/conf TB --- 2008-03-01 02:02:05 - /usr/bin/make -B LINT TB --- 2008-03-01 02:02:05 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-01 02:02:05 - cd /src TB --- 2008-03-01 02:02:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 1 02:02:05 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] "Makefile", line 2580: warning: duplicate script for target "e1000_manage.ln" ignored "Makefile", line 2583: warning: duplicate script for target "e1000_manage.o" ignored "Makefile", line 2586: warning: duplicate script for target "e1000_nvm.ln" ignored "Makefile", line 2589: warning: duplicate script for target "e1000_nvm.o" ignored "Makefile", line 2592: warning: duplicate script for target "e1000_phy.ln" ignored "Makefile", line 2595: warning: duplicate script for target "e1000_phy.o" ignored cc: /src/sys/dev/em/e1000_82575.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 02:03:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 02:03:49 - ERROR: failed to build lint kernel TB --- 2008-03-01 02:03:49 - tinderbox aborted TB --- 2701.44 user 335.31 system 3751.16 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 02:15:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 020FF1065673 for ; Sat, 1 Mar 2008 02:15:14 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from mx2.confluenttech.com (mx2.confluentasp.com [216.26.153.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6A18FC19 for ; Sat, 1 Mar 2008 02:15:13 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from calvin.pai.local ([10.0.6.33]) by mx2.confluenttech.com (8.14.1/8.12.9) with ESMTP id m1TMlirQ099069 for ; Fri, 29 Feb 2008 17:47:54 -0500 (EST) (envelope-from mikej@paymentallianceintl.com) x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4133 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Fri, 29 Feb 2008 17:46:33 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: Two (2) Lock Order Reversion - tracking RELENG_7 Thread-Index: Ach7JO7dw9ulb29vQi+QyBdD7pUg2g== From: "Michael Jung" To: Subject: Two (2) Lock Order Reversion - tracking RELENG_7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 02:15:14 -0000 Hello everyone: Please see complete dmesg output for two LOR's I'm tracking: *default release=cvs tag=RELENG_7 For now, this is a spare box that can be subjected to any type of testing - you only need to ask. I'm an avid advocate of FreeBSD but make no claims in understanding internals from anything but a 7956 foot level - and that varies ;-) FreeBSD zega.mikej.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Sun Feb 24 12:44:54 UTC 2008 mikej@zega.mikej.com:/usr/obj/usr/src/sys/ZEGA i386 GENERIC kernel other than: options KVA_PAGES=512 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. AND: /boot/loader.conf kern.sync_on_panic=0 console="comconsole vidconsole" vfs.zfs.prefetch_disable="1" zfs_load="YES" vfs.zfs.arc_max="320M" vm.kmem_size_max="1500M" vm.kmem_size="1500M" Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-PRERELEASE #0: Sun Feb 24 12:44:54 UTC 2008 mikej@zega.mikej.com:/usr/obj/usr/src/sys/ZEGA WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz (2660.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 2146697216 (2047 MB) avail memory = 2087800832 (1991 MB) ACPI APIC Table: WITNESS: spin lock intrcnt not in order list ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 12:41:19) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xac00-0xac7f mem 0xe0000000-0xefffffff,0xfd9c0000-0xfd9fffff irq 16 at device 0.0 on pci1 uhci0: port 0xe000-0xe01f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe800-0xe81f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xec00-0xec1f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfebffc00-0xfebfffff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 em0: port 0xbc00-0xbc3f mem 0xfeae0000-0xfeafffff,0xfeac0000-0xfeadffff irq 18 at device 0.0 on pci2 em0: Ethernet address: 00:1b:21:10:1d:55 em0: [FILTER] twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xb800-0xb80f mem 0xfea9fc00-0xfea9fc0f,0xfe000000-0xfe7fffff irq 19 at device 1.0 on pci2 twe0: [GIANT-LOCKED] twe0: [ITHREAD] twe0: 4 ports, Firmware FE7X 1.05.00.068, BIOS BE7X 1.08.00.048 rl0: port 0xb400-0xb4ff mem 0xfea9f800-0xfea9f8ff irq 22 at device 5.0 on pci2 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:2c:a4:f7:b3 rl0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.5 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xd2800-0xd37ff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounter "TSC" frequency 2660018636 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. ZFS filesystem version 6 ZFS storage pool version 6 ad0: 194479MB at ata0-master UDMA100 ad1: 194481MB at ata0-slave UDMA100 ad2: 194481MB at ata1-master UDMA100 ad3: 194481MB at ata1-slave UDMA100 twed0: on twe0 twed0: 715422MB (1465185024 sectors) WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Trying to mount root from ufs:/dev/twed0s1a em0: link state changed to UP lock order reversal: 1st 0x80ba3c20 sched lock (sched lock) @ /usr/src/sys/kern/subr_trap.c:86 2nd 0x80c081c8 sio (sio) @ /usr/src/sys/dev/sio/sio.c:2556 KDB: stack backtrace: db_trace_self_wrapper(80a964f8,fae2aae0,8076f525,80a978e6,80c081c8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(80a978e6,80c081c8,80b649c0,80b649c0,80ab5543,...) at kdb_backtrace+0x29 witness_checkorder(80c081c8,9,80ab5543,9fc,fae2ab10,...) at witness_checkorder+0x5e5 _mtx_lock_spin_flags(80c081c8,0,80ab5543,9fc,fae2ab2c,...) at _mtx_lock_spin_flags+0x32 sio_cnputc(80b649e0,66,fae2acc0,5,66,...) at sio_cnputc+0x86 cnputc(66,fae2acc0,fae2ab80,80765a61,3c6,...) at cnputc+0x5f putcons(3c6,80a94f2d,15c3804,885c8000,80a971d1,...) at putcons+0x17 putchar(66,fae2acc0,80ba3cc0,893fdc34,0,...) at putchar+0x61 kvprintf(80a971d0,80765a00,fae2acc0,a,fae2acec,...) at kvprintf+0x75 printf(80a971d0,0,80a971b2,56,885c3894,...) at printf+0x4e userret(885c8000,fae2ad38,80a971b2,fc,1020804) at userret+0xab ast(fae2ad38) at ast+0x34b doreti_ast() at doreti_ast+0x17 failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() failed to set signal flags properly for ast() lock order reversal: 1st 0x85e07ac8 process slock (process slock) @ /usr/src/sys/kern/kern_resource.c:1066 2nd 0x80c081c8 sio (sio) @ /usr/src/sys/dev/sio/sio.c:2556 KDB: stack backtrace: db_trace_self_wrapper(80a964f8,fad3a93c,8076f525,80a978e6,80c081c8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(80a978e6,80c081c8,80b649c0,80b649c0,80ab5543,...) at kdb_backtrace+0x29 witness_checkorder(80c081c8,9,80ab5543,9fc,85e12630,...) at witness_checkorder+0x5e5 _mtx_lock_spin_flags(80c081c8,0,80ab5543,9fc,80ba8738,...) at _mtx_lock_spin_flags+0x32 sio_cnputc(80b649e0,63,fad3ab1c,5,63,...) at sio_cnputc+0x86 cnputc(63,fad3ab1c,fad3a9dc,80765a61,0,...) at cnputc+0x5f putcons(0,80beeba8,1e126c8,c36,80a94179,...) at putcons+0x17 putchar(63,fad3ab1c,200246,0,fad3aa10,...) at putchar+0x61 kvprintf(80a94178,80765a00,fad3ab1c,a,fad3ab48,...) at kvprintf+0x75 printf(80a94178,4291db58,1f,6cf6ce72,1d,...) at printf+0x4e calcru1(fad3ac38,8073b690,fad3ac30,85e126ec,8a15032a,15aa0) at calcru1+0x25e calcru(85e07ab0,fad3ac30,fad3ac38,42a,85e07ab0,...) at calcru+0xdd rufetchcalc(85e07ab0,fad3ac30,fad3ac30,fad3ac38,fad3acfc,...) at rufetchcalc+0x53 kern_getrusage(85e12630,0,fad3ac30,0,0,...) at kern_getrusage+0x61 getrusage(85e12630,fad3acfc,8,80a97500,80b39598,...) at getrusage+0x27 syscall(fad3ad38) at syscall+0x2d3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (117, FreeBSD ELF32, getrusage), eip = 0x809ed83, esp = 0x7fbfe88c, ebp = 0x8148000 --- calcru: runtime went backwards from 134260841304 usec to 126382165618 usec for pid 827 (dnetc) calcru: runtime went backwards from 4534 usec to 4267 usec for pid 919 (getty) calcru: runtime went backwards from 4652 usec to 4378 usec for pid 904 (getty) calcru: runtime went backwards from 4572 usec to 4303 usec for pid 903 (getty) calcru: runtime went backwards from 4610 usec to 4339 usec for pid 902 (getty) calcru: runtime went backwards from 4495 usec to 4230 usec for pid 901 (getty) calcru: runtime went backwards from 4648 usec to 4375 usec for pid 900 (getty) calcru: runtime went backwards from 4420 usec to 4160 usec for pid 899 (getty) calcru: runtime went backwards from 4481 usec to 4218 usec for pid 898 (getty) calcru: runtime went backwards from 53281990 usec to 51509780 usec for pid 855 (cron) calcru: runtime went backwards from 7674352130 usec to 7224054531 usec for pid 839 (sshd) calcru: runtime went backwards from 43225 usec to 40688 usec for pid 745 (nfsd) calcru: runtime went backwards from 7988 usec to 7519 usec for pid 743 (mountd) calcru: runtime went backwards from 3613 usec to 3401 usec for pid 592 (devd) calcru: runtime went backwards from 28022 usec to 26242 usec for pid 592 (devd) calcru: runtime went backwards from 83141 usec to 79411 usec for pid 128 (spa_zio_intr_1) calcru: runtime went backwards from 18948528 usec to 18427925 usec for pid 50 (softdepflush) calcru: runtime went backwards from 1551354 usec to 1528787 usec for pid 47 (bufdaemon) calcru: runtime went backwards from 8955 usec to 8430 usec for pid 40 (irq1: atkbd0) calcru: runtime went backwards from 8022203 usec to 7770714 usec for pid 27 (irq19: uhci1 twe0) calcru: runtime went backwards from 22096 usec to 20692 usec for pid 20 (swi5: +) calcru: runtime went backwards from 277929 usec to 260275 usec for pid 17 (swi6: task queue) calcru: runtime went backwards from 2438 usec to 2295 usec for pid 12 (swi1: net) calcru: runtime went backwards from 89469281 usec to 84551522 usec for pid 11 (idle: cpu0) calcru: runtime went backwards from 1088731 usec to 1024840 usec for pid 1 (init) calcru: runtime went backwards from 49829588 usec to 46905404 usec for pid 1 (init) calcru: runtime went backwards from 146817 usec to 137491 usec for pid 0 (swapper) #ps -ax PID TT STAT TIME COMMAND 0 ?? WLs 0:00.14 [swapper] 1 ?? ILs 0:01.04 /sbin/init -- 2 ?? DL 0:10.63 [g_event] 3 ?? DL 0:21.83 [g_up] 4 ?? DL 0:16.37 [g_down] 5 ?? DL 0:00.00 [system_taskq] 6 ?? DL 0:00.00 [kqueue taskq] 7 ?? DL 0:00.00 [acpi_task_0] 8 ?? DL 0:00.00 [acpi_task_1] 9 ?? DL 0:00.00 [acpi_task_2] 10 ?? DL 0:00.00 [audit] 11 ?? RL 1:43.84 [idle: cpu0] 12 ?? WL 0:00.00 [swi1: net] 13 ?? WL 6:41.69 [swi4: clock sio] 14 ?? WL 0:00.00 [swi3: vm] 15 ?? DL 0:07.92 [yarrow] 16 ?? WL 0:00.30 [swi6: Giant taskq] 17 ?? WL 0:00.26 [swi6: task queue] 18 ?? DL 0:00.00 [xpt_thrd] 19 ?? WL 0:00.00 [swi2: cambio] 20 ?? WL 0:00.02 [swi5: +] 21 ?? DL 0:00.00 [thread taskq] 22 ?? WL 0:00.00 [irq9: acpi0] 23 ?? WL 0:00.00 [irq16: uhci0 uhci3] 24 ?? DL 0:00.01 [usb0] 25 ?? DL 0:00.00 [usbtask-hc] 26 ?? DL 0:00.00 [usbtask-dr] 27 ?? WL 0:09.38 [irq19: uhci1 twe0] 28 ?? DL 0:00.01 [usb1] 29 ?? WL 0:02.81 [irq18: em0 uhci2] 30 ?? DL 0:00.01 [usb2] 31 ?? DL 0:00.01 [usb3] 32 ?? WL 0:00.00 [irq23: ehci0] 33 ?? DL 0:00.02 [usb4] 34 ?? DL 0:10.49 [em0 taskq] 35 ?? WL 0:00.00 [irq22: rl0] 36 ?? WL 0:00.22 [irq14: ata0] 37 ?? WL 0:00.23 [irq15: ata1] 38 ?? WL 0:00.00 [swi0: sio] 39 ?? DL 0:00.79 [fdc0] 40 ?? WL 0:00.01 [irq1: atkbd0] 41 ?? WL 0:00.00 [irq7: ppbus0 ppc0] 42 ?? DL 0:00.00 [sctp_iterator] 43 ?? DL 0:00.99 [arc_reclaim_thread] 44 ?? DL 0:00.22 [pagedaemon] 45 ?? DL 0:00.00 [vmdaemon] 46 ?? DL 0:00.00 [pagezero] 47 ?? DL 0:01.74 [bufdaemon] 48 ?? DL 9:47.21 [syncer] 49 ?? DL 0:01.94 [vnlru] 50 ?? DL 0:21.50 [softdepflush] 51 ?? DL 0:22.08 [schedcpu] 125 ?? DL 0:00.00 [spa_zio_issue_0] 126 ?? DL 0:00.00 [spa_zio_intr_0] 127 ?? DL 0:00.00 [spa_zio_issue_1] 128 ?? DL 0:00.08 [spa_zio_intr_1] 129 ?? DL 0:00.03 [spa_zio_issue_2] 130 ?? DL 0:02.80 [spa_zio_intr_2] 131 ?? DL 0:00.00 [spa_zio_issue_3] 132 ?? DL 0:00.00 [spa_zio_intr_3] 133 ?? DL 0:00.00 [spa_zio_issue_4] 134 ?? DL 0:00.00 [spa_zio_intr_4] 135 ?? DL 0:00.00 [spa_zio_issue_5] 136 ?? DL 0:00.00 [spa_zio_intr_5] 137 ?? DL 0:00.03 [vdev:worker ad0] 138 ?? DL 0:00.03 [vdev:worker ad1] 139 ?? DL 0:00.03 [vdev:worker ad2] 140 ?? DL 0:00.03 [vdev:worker ad3] 141 ?? DL 0:00.40 [txg_thread_enter] 142 ?? DL 0:03.00 [txg_thread_enter] 143 ?? DL 0:00.40 [txg_thread_enter] 144 ?? DL 0:00.00 [zil_clean] 145 ?? DL 0:00.01 [zil_clean] 592 ?? Is 0:00.00 /sbin/devd 646 ?? Is 0:00.45 /usr/sbin/syslogd -s 722 ?? Ss 0:00.25 /usr/sbin/rpcbind 743 ?? Is 0:00.01 /usr/sbin/mountd -r 745 ?? Is 0:00.04 nfsd: master (nfsd) 747 ?? I 0:19.35 nfsd: server (nfsd) 748 ?? I 0:00.24 nfsd: server (nfsd) 749 ?? I 0:00.02 nfsd: server (nfsd) 750 ?? I 0:00.01 nfsd: server (nfsd) 801 ?? Ss 0:07.91 /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift 827 ?? RNs 2585:41.13 /usr/local/distributed.net/dnetc -quiet 839 ?? Is 0:00.01 /usr/sbin/sshd 845 ?? Ss 0:03.38 sendmail: accepting connections (sendmail) 849 ?? Is 0:00.08 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) 855 ?? Is 0:00.60 /usr/sbin/cron -s 45427 ?? Is 0:00.08 sshd: mikej [priv] (sshd) 45431 ?? S 0:04.18 sshd: mikej@ttyp0 (sshd) 919 v0 Is+ 0:00.00 /usr/libexec/getty Pc ttyv0 898 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 899 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 900 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 901 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 902 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 903 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 904 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 10793 p0 R+ 0:00.00 ps -ax 10794 p0 R+ 0:00.00 su (bash) 45433 p0 Is 0:00.03 -bash (bash) 45453 p0 I 0:00.01 su 45454 p0 S 0:00.20 su (bash) DUMB? QUESTION: Why did the LOR not trigger a kernel TRAP? - At 46 I'm still trying to learn. These errors did not occur at boot, but sometime I'm estimating 1+days after the system was up and running CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 02:44:57 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9289F106566C; Sat, 1 Mar 2008 02:44:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA3E8FC12; Sat, 1 Mar 2008 02:44:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m212iupu009048; Fri, 29 Feb 2008 21:44:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m212iuHi015023; Fri, 29 Feb 2008 21:44:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2276E73039; Fri, 29 Feb 2008 21:44:56 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301024456.2276E73039@freebsd-current.sentex.ca> Date: Fri, 29 Feb 2008 21:44:56 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 02:44:57 -0000 TB --- 2008-03-01 01:42:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 01:42:10 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-03-01 01:42:10 - cleaning the object tree TB --- 2008-03-01 01:42:38 - cvsupping the source tree TB --- 2008-03-01 01:42:38 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-03-01 01:42:46 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 01:42:46 - cd /src TB --- 2008-03-01 01:42:46 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 01:42:47 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 1 02:36:48 UTC 2008 TB --- 2008-03-01 02:36:48 - generating LINT kernel config TB --- 2008-03-01 02:36:48 - cd /src/sys/sun4v/conf TB --- 2008-03-01 02:36:48 - /usr/bin/make -B LINT TB --- 2008-03-01 02:36:49 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-01 02:36:49 - cd /src TB --- 2008-03-01 02:36:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 1 02:36:49 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> export_syms awk -f /src/sys/modules/if_vlan/../../conf/kmod_syms.awk if_vlan.kld export_syms | xargs -J% objcopy % if_vlan.kld ld -Bshareable -d -warn-common -o if_vlan.ko if_vlan.kld objcopy --strip-debug if_vlan.ko ===> igb (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/igb/../../dev/igb -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/igb/../../dev/igb/if_igb.c /src/sys/modules/igb/../../dev/igb/if_igb.c: In function 'igb_fixup_rx': /src/sys/modules/igb/../../dev/igb/if_igb.c:3794: error: 'struct adapter' has no member named 'fmp' *** Error code 1 Stop in /src/sys/modules/igb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 02:44:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 02:44:56 - ERROR: failed to build lint kernel TB --- 2008-03-01 02:44:56 - tinderbox aborted TB --- 3039.52 user 366.41 system 3765.67 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 04:26:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E3F1065670; Sat, 1 Mar 2008 04:26:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id A7C908FC28; Sat, 1 Mar 2008 04:26:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m214QdEO012904; Fri, 29 Feb 2008 23:26:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m214Qdiv084818; Fri, 29 Feb 2008 23:26:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 70F4073039; Fri, 29 Feb 2008 23:26:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301042639.70F4073039@freebsd-current.sentex.ca> Date: Fri, 29 Feb 2008 23:26:39 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 04:26:41 -0000 TB --- 2008-03-01 02:45:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 02:45:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-03-01 02:45:01 - cleaning the object tree TB --- 2008-03-01 02:45:54 - cvsupping the source tree TB --- 2008-03-01 02:45:54 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-03-01 02:46:01 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 02:46:01 - cd /src TB --- 2008-03-01 02:46:01 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 02:46:03 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Mar 1 04:14:42 UTC 2008 TB --- 2008-03-01 04:14:42 - generating LINT kernel config TB --- 2008-03-01 04:14:42 - cd /src/sys/amd64/conf TB --- 2008-03-01 04:14:42 - /usr/bin/make -B LINT TB --- 2008-03-01 04:14:42 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-01 04:14:42 - cd /src TB --- 2008-03-01 04:14:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 1 04:14:43 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ld -d -warn-common -r -d -o if_vlan.ko if_vlan.o :> export_syms awk -f /src/sys/modules/if_vlan/../../conf/kmod_syms.awk if_vlan.ko export_syms | xargs -J% objcopy % if_vlan.ko objcopy --strip-debug if_vlan.ko ===> igb (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/igb/../../dev/igb -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -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 /src/sys/modules/igb/../../dev/igb/if_igb.c /src/sys/modules/igb/../../dev/igb/if_igb.c: In function 'igb_poll': /src/sys/modules/igb/../../dev/igb/if_igb.c:1146: error: too few arguments to function 'igb_start_locked' *** Error code 1 Stop in /src/sys/modules/igb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 04:26:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 04:26:39 - ERROR: failed to build lint kernel TB --- 2008-03-01 04:26:39 - tinderbox aborted TB --- 4486.80 user 557.32 system 6098.17 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 05:02:10 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECF781065B8F; Sat, 1 Mar 2008 05:02:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 23B738FC1E; Sat, 1 Mar 2008 05:02:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m215285I070946; Sat, 1 Mar 2008 00:02:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m21528FQ076187; Sat, 1 Mar 2008 00:02:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1961573039; Sat, 1 Mar 2008 00:02:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301050208.1961573039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 00:02:08 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 05:02:10 -0000 TB --- 2008-03-01 03:45:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 03:45:22 - starting HEAD tinderbox run for i386/i386 TB --- 2008-03-01 03:45:22 - cleaning the object tree TB --- 2008-03-01 03:45:43 - cvsupping the source tree TB --- 2008-03-01 03:45:43 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-03-01 03:45:50 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 03:45:50 - cd /src TB --- 2008-03-01 03:45:50 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 03:45:52 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 1 04:48:39 UTC 2008 TB --- 2008-03-01 04:48:39 - generating LINT kernel config TB --- 2008-03-01 04:48:39 - cd /src/sys/i386/conf TB --- 2008-03-01 04:48:39 - /usr/bin/make -B LINT TB --- 2008-03-01 04:48:40 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-01 04:48:40 - cd /src TB --- 2008-03-01 04:48:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 1 04:48:40 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/modules/igb/../../dev/igb/if_igb.c: In function 'igb_print_debug_info': /src/sys/modules/igb/../../dev/igb/if_igb.c:4210: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4212: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4214: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4222: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4224: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4226: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' *** Error code 1 Stop in /src/sys/modules/igb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 05:02:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 05:02:07 - ERROR: failed to build lint kernel TB --- 2008-03-01 05:02:07 - tinderbox aborted TB --- 3407.88 user 406.17 system 4605.32 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 05:40:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5D5B1065775; Sat, 1 Mar 2008 05:40:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7D14C8FC28; Sat, 1 Mar 2008 05:40:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m215eemM072381; Sat, 1 Mar 2008 00:40:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m215ee5K058031; Sat, 1 Mar 2008 00:40:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C302573039; Sat, 1 Mar 2008 00:40:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301054039.C302573039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 00:40:39 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 05:40:41 -0000 TB --- 2008-03-01 04:26:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 04:26:39 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-03-01 04:26:39 - cleaning the object tree TB --- 2008-03-01 04:26:52 - cvsupping the source tree TB --- 2008-03-01 04:26:52 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-03-01 04:26:57 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 04:26:57 - cd /src TB --- 2008-03-01 04:26:57 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 04:26:59 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 1 05:29:27 UTC 2008 TB --- 2008-03-01 05:29:27 - generating LINT kernel config TB --- 2008-03-01 05:29:27 - cd /src/sys/pc98/conf TB --- 2008-03-01 05:29:27 - /usr/bin/make -B LINT TB --- 2008-03-01 05:29:28 - building LINT kernel (COPTFLAGS=) TB --- 2008-03-01 05:29:28 - cd /src TB --- 2008-03-01 05:29:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 1 05:29:28 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/modules/igb/../../dev/igb/if_igb.c: In function 'igb_print_debug_info': /src/sys/modules/igb/../../dev/igb/if_igb.c:4210: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4212: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4214: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4222: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4224: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' /src/sys/modules/igb/../../dev/igb/if_igb.c:4226: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'u64' *** Error code 1 Stop in /src/sys/modules/igb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 05:40:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 05:40:39 - ERROR: failed to build lint kernel TB --- 2008-03-01 05:40:39 - tinderbox aborted TB --- 3280.82 user 405.66 system 4440.20 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 09:51:19 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A523B106566C for ; Sat, 1 Mar 2008 09:51:19 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231]) by mx1.freebsd.org (Postfix) with ESMTP id 51F2B8FC19 for ; Sat, 1 Mar 2008 09:51:19 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so6216413qbd.7 for ; Sat, 01 Mar 2008 01:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=jbQws6DIVNORTyCdHYce21uoHAvDppwWCFthszjIarg=; b=EdqBmVrDmZFjlQnlDeU76qaMGwbjTQy4KaDsZKVumo37Fd5/yJM1WbArZ2ju2Htu85tQFMLEi6MCB4HqEPTPyoQpPE2I1PKBTjiUkOhDvLXXO8jpzPcc315FU6vAHtqEj76HBJ1X/oh0kAJpKdxDH+eGFbz072/6+94MEZ7Bt9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BNBZDnV0+m+dwAE/DmqHBI2WXYA4ANDhyZc/ktww9G7vn825nGHvAo/qdZqBDPeKEveqtkd7GE2JIKundHFyxPxQoWFlhBcuyX/wB+84zGi8F4QvrmYE/mwbnpK4PqMl03s9FxMsJn541xBnXoTsqSdkiV82yrbbLhzNBb4deGA= Received: by 10.110.31.5 with SMTP id e5mr7218285tie.35.1204365077396; Sat, 01 Mar 2008 01:51:17 -0800 (PST) Received: by 10.110.5.3 with HTTP; Sat, 1 Mar 2008 01:51:17 -0800 (PST) Message-ID: <5635aa0d0803010151sa6f3a6fy70f3793df5425b1b@mail.gmail.com> Date: Sat, 1 Mar 2008 04:51:17 -0500 From: "Outback Dingo" To: "Julian Elischer" In-Reply-To: <47C8B448.7050005@elischer.org> MIME-Version: 1.0 References: <47C44420.6050009@elischer.org> <20080229152542.GD94339@obiwan.tataz.chchile.org> <47C8B448.7050005@elischer.org> 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: Jeremie Le Hen , FreeBSD Current Subject: Re: why vimage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 09:51:19 -0000 I think there needs to be some decent howto or documentation established though, i compiled and installed a kernel and the binary read the man page... searched google... but cant for the life of me conceptualize how to get network interfaces up inside the vimage i see the standard rl0 interface in the main i can dhcp and address but dont see how one clones or creates an interface inside the other vimages i found a doc that read Virtual images in a simple bridged environment, written in 2002 and the command ifconfig create ve0.... doesnt work so i think, i for one and many others might appreciate vimages power a bit more if there was a fast howto quick and dirty on how to accomplish a working configuration and discover the power of this code.... I could see a use for it.. thats if i can foigure out how to get networking and chrooted images..... just my thoughts so far.... On Fri, Feb 29, 2008 at 8:41 PM, Julian Elischer wrote: > Jeremie Le Hen wrote: > > Hi Julian, > > > > On Tue, Feb 26, 2008 at 08:53:52AM -0800, Julian Elischer wrote: > >> I can give a very simple example of something you can do trivially on > >> vimage: > >> > >> Make three virtual machines on yhour laptop: > >> The base machine and two others. > >> Have the first 'other' machine be assigned an IP address on > >> your HOME LAN. > >> have the second virtual machine have an IP adddress on > >> your WORK LAN. > >> use the base machine to run encrypted tunnels from where-ever > >> you happen to be to your work and home.. when you put the laptop to > sleep > >> (assuming the tcp sessions are quiescent (no keepalives)) > >> then when you wake it up say an hour later.. as soon as the base > machine has > >> an IP address.. viola, your session on the virtual > >> machines are still alive. > > > > On this post [1], Marko states: > > > > % Each NICs is logically attached to one and only one network stack > > % instance at a time, and it receives data from upper layers and feeds > > % the upper layers with mbufs in exactly the same manner as it does on > > % the standard kernel. It is the link layer that demultiplexes the > > % incoming traffic to the appropriate stack instance... > > > > As I understand it, there is only one vimage per interface. I'm surely > > wrong or the setup you described wouldn't be possible. > > > > physical interfaces can be forked out to several virtual interfaces > which can be in different virtual machines.. > Or the virtual interfaces could be connected to tunnels. > > > Any explanation will be welcome :). > > Thanks, > > > > [1] > http://lists.freebsd.org/pipermail/freebsd-current/2008-February/083908.html > > > > Regards, > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 13:06:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF4301065678 for ; Sat, 1 Mar 2008 13:06:23 +0000 (UTC) (envelope-from molla5@yahoo.com) Received: from web30702.mail.mud.yahoo.com (web30702.mail.mud.yahoo.com [68.142.200.135]) by mx1.freebsd.org (Postfix) with SMTP id 592EB8FC1B for ; Sat, 1 Mar 2008 13:06:23 +0000 (UTC) (envelope-from molla5@yahoo.com) Received: (qmail 49579 invoked by uid 60001); 1 Mar 2008 12:39: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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=uCX02Da0CS2J036OU8Y7HEO1VLSyMYAS5qoGO0GeNn3xscTOYvnf49W/iqKnapg28dH+epyGFUaacIOZElQQjv4fYtspr9YEtuLCm3Zc9fkFGYSgwFpl5ZCVDLxIXN+usEVsc1eZtMm5HBU4jErlpSYvXla8+ipBmyYlKUD9v0o=; X-YMail-OSG: ZFNGaVcVM1nQgZzYtw7te2KvCth8o0qUKH8wkoO.488Ezqd4DacU2rIqiIOXPfbiZdpwP.PrlMHxVHtVB0wh4ICIE0iNdYq274CPfzYSNdG9zwO7foU6QtusXS8rZA-- Received: from [88.255.56.37] by web30702.mail.mud.yahoo.com via HTTP; Sat, 01 Mar 2008 04:39:42 PST Date: Sat, 1 Mar 2008 04:39:42 -0800 (PST) From: Ayhan Molla To: freebsd-current@freebsd.org In-Reply-To: <20080301120012.625A4106569A@hub.freebsd.org> MIME-Version: 1.0 Message-ID: <277664.49213.qm@web30702.mail.mud.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Broadcom Netlink BCM5906M X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 13:06:23 -0000 Hi, I am having trouble applying the patch for the BCM5906. The patch is supposed to work for 7.0-RC1. I have installed 7.0-Release and patch didn't work for me. if_bge.c file has changed since RC1 and therefore I wasn't able to manually apply the patch. Has someone tried to apply the patch for 7.0-Release? --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 14:08:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 419D01065706 for ; Sat, 1 Mar 2008 14:08:58 +0000 (UTC) (envelope-from thn@saeab.se) Received: from ture.saeab.se (ture.saeab.se [213.80.3.133]) by mx1.freebsd.org (Postfix) with ESMTP id 3346E8FC18 for ; Sat, 1 Mar 2008 14:08:56 +0000 (UTC) (envelope-from thn@saeab.se) Received: from scatcat.thn.saeab.se (vpn-thn.int.saeab.se [10.0.4.43]) by ture.saeab.se (8.13.8/8.13.8) with ESMTP id m21E8oEw090241; Sat, 1 Mar 2008 15:08:50 +0100 (CET) (envelope-from thn@saeab.se) Received: from [10.1.0.1] (home [10.1.0.1]) by scatcat.thn.saeab.se (8.14.2/8.14.2) with ESMTP id m21E8o4K047865; Sat, 1 Mar 2008 15:08:50 +0100 (CET) (envelope-from thn@saeab.se) Message-ID: <47C963F0.3000707@saeab.se> Date: Sat, 01 Mar 2008 15:10:56 +0100 From: =?ISO-8859-1?Q?Thomas_Nystr=F6m?= Organization: Svensk Aktuell Elektronik AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ayhan Molla References: <277664.49213.qm@web30702.mail.mud.yahoo.com> In-Reply-To: <277664.49213.qm@web30702.mail.mud.yahoo.com> Content-Type: multipart/mixed; boundary="------------060408000507000803020503" X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ture.saeab.se X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ture.saeab.se [10.0.1.133]); Sat, 01 Mar 2008 15:08:55 +0100 (CET) Cc: freebsd-current@freebsd.org Subject: Re: Broadcom Netlink BCM5906M X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 14:08:58 -0000 This is a multi-part message in MIME format. --------------060408000507000803020503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Ayhan Molla wrote: > Hi, > I am having trouble applying the patch for the BCM5906. The patch is > supposed to work for 7.0-RC1. I have installed 7.0-Release and patch > didn't work for me. > if_bge.c file has changed since RC1 and therefore I wasn't able to > manually apply the patch. > > Has someone tried to apply the patch for 7.0-Release? Try the new attached (untested) patch! /Thomas -- --------------------------------------------------------------- Svensk Aktuell Elektronik AB Thomas Nyström Box 10 Phone: +46 73 069 69 30 S-191 21 Sollentuna Fax: +46 8 35 92 89 Sweden Email: thn@saeab.se --------------------------------------------------------------- --------------060408000507000803020503 Content-Type: text/plain; name="broadcom5906-70.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="broadcom5906-70.diff" --- ./sys/dev/bge/if_bge.c.70 2008-03-01 15:03:15.000000000 +0100 +++ ./sys/dev/bge/if_bge.c 2008-03-01 15:00:22.000000000 +0100 @@ -195,6 +195,8 @@ { BCOM_VENDORID, BCOM_DEVICEID_BCM5901 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5901A2 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5903M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5906 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5906M }, { SK_VENDORID, SK_DEVICEID_ALTIMA }, @@ -271,6 +273,8 @@ { BGE_CHIPID_BCM5787_A0, "BCM5754/5787 A0" }, { BGE_CHIPID_BCM5787_A1, "BCM5754/5787 A1" }, { BGE_CHIPID_BCM5787_A2, "BCM5754/5787 A2" }, + { BGE_CHIPID_BCM5906_A1, "BCM5906 A1" }, + { BGE_CHIPID_BCM5906_A2, "BCM5906 A2" }, { 0, NULL } }; @@ -293,6 +297,7 @@ { BGE_ASICREV_BCM5755, "unknown BCM5755" }, /* 5754 and 5787 share the same ASIC ID */ { BGE_ASICREV_BCM5787, "unknown BCM5754/5787" }, + { BGE_ASICREV_BCM5906, "unknown BCM5906" }, { 0, NULL } }; @@ -305,6 +310,9 @@ const struct bge_revision * bge_lookup_rev(uint32_t); const struct bge_vendor * bge_lookup_vendor(uint16_t); + +typedef int (*bge_eaddr_fcn_t)(struct bge_softc *, uint8_t[]); + static int bge_probe(device_t); static int bge_attach(device_t); static int bge_detach(device_t); @@ -315,6 +323,11 @@ static int bge_dma_alloc(device_t); static void bge_dma_free(struct bge_softc *); +static int bge_get_eaddr_mem(struct bge_softc *, uint8_t[]); +static int bge_get_eaddr_nvram(struct bge_softc *, uint8_t[]); +static int bge_get_eaddr_eeprom(struct bge_softc *, uint8_t[]); +static int bge_get_eaddr(struct bge_softc *, uint8_t[]); + static void bge_txeof(struct bge_softc *); static void bge_rxeof(struct bge_softc *); @@ -337,6 +350,9 @@ static int bge_ifmedia_upd(struct ifnet *); static void bge_ifmedia_sts(struct ifnet *, struct ifmediareq *); +static uint8_t bge_nvram_getbyte(struct bge_softc *, int, uint8_t *); +static int bge_read_nvram(struct bge_softc *, caddr_t, int, int); + static uint8_t bge_eeprom_getbyte(struct bge_softc *, int, uint8_t *); static int bge_read_eeprom(struct bge_softc *, caddr_t, int, int); @@ -359,6 +375,7 @@ static int bge_has_eeprom(struct bge_softc *); static uint32_t bge_readmem_ind(struct bge_softc *, int); static void bge_writemem_ind(struct bge_softc *, int, int); +static void bge_writembx(struct bge_softc *, int, int); #ifdef notdef static uint32_t bge_readreg_ind(struct bge_softc *, int); #endif @@ -474,6 +491,10 @@ return (0); } #endif + + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) + return (0); + return (1); } @@ -533,6 +554,15 @@ CSR_WRITE_4(sc, off, val); } +static void +bge_writembx(struct bge_softc *sc, int off, int val) +{ + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) + off += BGE_LPMBX_IRQ0_HI - BGE_MBX_IRQ0_HI; + + CSR_WRITE_4(sc, off, val); +} + /* * Map a single buffer address. */ @@ -555,6 +585,78 @@ ctx->bge_busaddr = segs->ds_addr; } +static uint8_t +bge_nvram_getbyte(struct bge_softc *sc, int addr, uint8_t *dest) +{ + uint32_t access, byte = 0; + int i; + + /* Lock. */ + CSR_WRITE_4(sc, BGE_NVRAM_SWARB, BGE_NVRAMSWARB_SET1); + for (i = 0; i < 8000; i++) { + if (CSR_READ_4(sc, BGE_NVRAM_SWARB) & BGE_NVRAMSWARB_GNT1) + break; + DELAY(20); + } + if (i == 8000) + return (1); + + /* Enable access. */ + access = CSR_READ_4(sc, BGE_NVRAM_ACCESS); + CSR_WRITE_4(sc, BGE_NVRAM_ACCESS, access | BGE_NVRAMACC_ENABLE); + + CSR_WRITE_4(sc, BGE_NVRAM_ADDR, addr & 0xfffffffc); + CSR_WRITE_4(sc, BGE_NVRAM_CMD, BGE_NVRAM_READCMD); + for (i = 0; i < BGE_TIMEOUT * 10; i++) { + DELAY(10); + if (CSR_READ_4(sc, BGE_NVRAM_CMD) & BGE_NVRAMCMD_DONE) { + DELAY(10); + break; + } + } + + if (i == BGE_TIMEOUT * 10) { + if_printf(sc->bge_ifp, "nvram read timed out\n"); + return (1); + } + + /* Get result. */ + byte = CSR_READ_4(sc, BGE_NVRAM_RDDATA); + + *dest = (bswap32(byte) >> ((addr % 4) * 8)) & 0xFF; + + /* Disable access. */ + CSR_WRITE_4(sc, BGE_NVRAM_ACCESS, access); + + /* Unlock. */ + CSR_WRITE_4(sc, BGE_NVRAM_SWARB, BGE_NVRAMSWARB_CLR1); + CSR_READ_4(sc, BGE_NVRAM_SWARB); + + return (0); +} + +/* + * Read a sequence of bytes from NVRAM. + */ +static int +bge_read_nvram(struct bge_softc *sc, caddr_t dest, int off, int cnt) +{ + int err = 0, i; + uint8_t byte = 0; + + if (sc->bge_asicrev != BGE_ASICREV_BCM5906) + return (1); + + for (i = 0; i < cnt; i++) { + err = bge_nvram_getbyte(sc, off + i, &byte); + if (err) + break; + *(dest + i) = byte; + } + + return (err ? 1 : 0); +} + /* * Read a byte of data stored in the EEPROM at address 'addr.' The * BCM570x supports both the traditional bitbang interface and an @@ -659,11 +761,13 @@ } if (i == BGE_TIMEOUT) { - device_printf(sc->bge_dev, "PHY read timed out\n"); + device_printf(sc->bge_dev, "PHY read timed out " + "(phy %d, reg %d, val 0x%08x)\n", phy, reg, val); val = 0; goto done; } + DELAY(5); val = CSR_READ_4(sc, BGE_MI_COMM); done: @@ -687,6 +791,10 @@ sc = device_get_softc(dev); + if (sc->bge_asicrev == BGE_ASICREV_BCM5906 && + (reg == BRGPHY_MII_1000CTL || reg == BRGPHY_MII_AUXCTL)) + return(0); + /* Reading with autopolling on may trigger PCI errors */ autopoll = CSR_READ_4(sc, BGE_MI_MODE); if (autopoll & BGE_MIMODE_AUTOPOLL) { @@ -699,12 +807,17 @@ for (i = 0; i < BGE_TIMEOUT; i++) { DELAY(10); - if (!(CSR_READ_4(sc, BGE_MI_COMM) & BGE_MICOMM_BUSY)) + if (!(CSR_READ_4(sc, BGE_MI_COMM) & BGE_MICOMM_BUSY)) { + DELAY(5); + CSR_READ_4(sc, BGE_MI_COMM); /* dummy read */ break; + } } if (i == BGE_TIMEOUT) { - device_printf(sc->bge_dev, "PHY write timed out\n"); + device_printf(sc->bge_dev, + "PHY write timed out (phy %d, reg %d, val %d)\n", + phy, reg, val); return (0); } @@ -887,7 +1000,7 @@ BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); sc->bge_std = i - 1; - CSR_WRITE_4(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std); + bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std); return (0); } @@ -934,7 +1047,7 @@ BGE_RCB_FLAG_USE_EXT_RX_BD); CSR_WRITE_4(sc, BGE_RX_JUMBO_RCB_MAXLEN_FLAGS, rcb->bge_maxlen_flags); - CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); + bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); return (0); } @@ -990,17 +1103,17 @@ /* Initialize transmit producer index for host-memory send ring. */ sc->bge_tx_prodidx = 0; - CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx); + bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx); /* 5700 b2 errata */ if (sc->bge_chiprev == BGE_CHIPREV_5700_BX) - CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx); + bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx); /* NIC-memory send ring not used; initialize to zero. */ - CSR_WRITE_4(sc, BGE_MBX_TX_NIC_PROD0_LO, 0); + bge_writembx(sc, BGE_MBX_TX_NIC_PROD0_LO, 0); /* 5700 b2 errata */ if (sc->bge_chiprev == BGE_CHIPREV_5700_BX) - CSR_WRITE_4(sc, BGE_MBX_TX_NIC_PROD0_LO, 0); + bge_writembx(sc, BGE_MBX_TX_NIC_PROD0_LO, 0); return (0); } @@ -1271,6 +1384,15 @@ /* Set the timer prescaler (always 66Mhz) */ CSR_WRITE_4(sc, BGE_MISC_CFG, BGE_32BITTIME_66MHZ); + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + DELAY(40); /* XXX */ + + /* Put PHY into ready state */ + BGE_CLRBIT(sc, BGE_MISC_CFG, BGE_MISCCFG_EPHY_IDDQ); + CSR_READ_4(sc, BGE_MISC_CFG); /* Flush */ + DELAY(40); + } + return (0); } @@ -1307,15 +1429,21 @@ CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_LEN, 0x2000); } + /* Configure mbuf pool watermarks */ - if (BGE_IS_5705_PLUS(sc)) { - CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0); - CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10); - } else { + if (!BGE_IS_5705_PLUS(sc)) { CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x50); CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x20); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60); + } else if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x04); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x10); + } else { + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60); } - CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60); /* Configure DMA resource watermarks */ CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_LOWAT, 5); @@ -1462,15 +1590,15 @@ BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, BGE_RCB_FLAG_RING_DISABLED)); RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); - CSR_WRITE_4(sc, BGE_MBX_RX_CONS0_LO + + bge_writembx(sc, BGE_MBX_RX_CONS0_LO + (i * (sizeof(uint64_t))), 0); vrcb += sizeof(struct bge_rcb); } /* Initialize RX ring indexes */ - CSR_WRITE_4(sc, BGE_MBX_RX_STD_PROD_LO, 0); - CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, 0); - CSR_WRITE_4(sc, BGE_MBX_RX_MINI_PROD_LO, 0); + bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, 0); + bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, 0); + bge_writembx(sc, BGE_MBX_RX_MINI_PROD_LO, 0); /* * Set up RX return ring 0 @@ -2230,7 +2358,6 @@ struct ifnet *ifp; struct bge_softc *sc; uint32_t hwcfg = 0; - uint32_t mac_tmp = 0; u_char eaddr[ETHER_ADDR_LEN]; int error, reg, rid, trys; @@ -2283,6 +2410,7 @@ case BGE_ASICREV_BCM5752: case BGE_ASICREV_BCM5755: case BGE_ASICREV_BCM5787: + case BGE_ASICREV_BCM5906: sc->bge_flags |= BGE_FLAG_575X_PLUS; /* FALLTHRU */ case BGE_ASICREV_BCM5705: @@ -2304,7 +2432,7 @@ if (sc->bge_asicrev == BGE_ASICREV_BCM5755 || sc->bge_asicrev == BGE_ASICREV_BCM5787) sc->bge_flags |= BGE_FLAG_JITTER_BUG; - else + else if (sc->bge_asicrev != BGE_ASICREV_BCM5906) sc->bge_flags |= BGE_FLAG_BER_BUG; } @@ -2415,22 +2543,14 @@ } #ifdef __sparc64__ - if ((sc->bge_flags & BGE_FLAG_EEPROM) == 0) + if (((sc->bge_flags & BGE_FLAG_EEPROM) == 0) && + (sc->bge_asicrev != BGE_ASICREV_BCM5906)) OF_getetheraddr(dev, eaddr); else #endif { - mac_tmp = bge_readmem_ind(sc, 0x0C14); - if ((mac_tmp >> 16) == 0x484B) { - eaddr[0] = (u_char)(mac_tmp >> 8); - eaddr[1] = (u_char)mac_tmp; - mac_tmp = bge_readmem_ind(sc, 0x0C18); - eaddr[2] = (u_char)(mac_tmp >> 24); - eaddr[3] = (u_char)(mac_tmp >> 16); - eaddr[4] = (u_char)(mac_tmp >> 8); - eaddr[5] = (u_char)mac_tmp; - } else if (bge_read_eeprom(sc, eaddr, - BGE_EE_MAC_OFFSET + 2, ETHER_ADDR_LEN)) { + error = bge_get_eaddr(sc, eaddr); + if (error) { device_printf(sc->bge_dev, "failed to read station address\n"); error = ENXIO; @@ -2688,7 +2808,8 @@ dev = sc->bge_dev; - if (BGE_IS_575X_PLUS(sc) && !BGE_IS_5714_FAMILY(sc)) { + if (BGE_IS_575X_PLUS(sc) && !BGE_IS_5714_FAMILY(sc) && + (sc->bge_asicrev != BGE_ASICREV_BCM5906)) { if (sc->bge_flags & BGE_FLAG_PCIE) write_op = bge_writemem_direct; else @@ -2744,6 +2865,17 @@ /* Issue global reset */ write_op(sc, BGE_MISC_CFG, reset); + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + uint32_t status, ctrl; + + status = CSR_READ_4(sc, BGE_VCPU_STATUS); + CSR_WRITE_4(sc, BGE_VCPU_STATUS, + status | BGE_VCPU_STATUS_DRV_RESET); + ctrl = CSR_READ_4(sc, BGE_VCPU_EXT_CTRL); + CSR_WRITE_4(sc, BGE_VCPU_EXT_CTRL, + ctrl & ~BGE_VCPU_EXT_CTRL_HALT_CPU); + } + DELAY(1000); /* XXX: Broadcom Linux driver. */ @@ -2788,21 +2920,34 @@ } else CSR_WRITE_4(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE); - /* - * Poll until we see the 1's complement of the magic number. - * This indicates that the firmware initialization is complete. - * We expect this to fail if no EEPROM is fitted though. - */ - for (i = 0; i < BGE_TIMEOUT; i++) { - DELAY(10); - val = bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM); - if (val == ~BGE_MAGIC_NUMBER) - break; - } + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + for (i = 0; i < BGE_TIMEOUT; i++) { + val = CSR_READ_4(sc, BGE_VCPU_STATUS); + if (val & BGE_VCPU_STATUS_INIT_DONE) + break; + DELAY(100); + } + if (i == BGE_TIMEOUT) { + device_printf(sc->bge_dev, "reset timed out\n"); + return (1); + } + } else { + /* + * Poll until we see the 1's complement of the magic number. + * This indicates that the firmware initialization is complete. + * We expect this to fail if no EEPROM is fitted though. + */ + for (i = 0; i < BGE_TIMEOUT; i++) { + DELAY(10); + val = bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM); + if (val == ~BGE_MAGIC_NUMBER) + break; + } - if ((sc->bge_flags & BGE_FLAG_EEPROM) && i == BGE_TIMEOUT) - device_printf(sc->bge_dev, "firmware handshake timed out, " - "found 0x%08x\n", val); + if ((sc->bge_flags & BGE_FLAG_EEPROM) && i == BGE_TIMEOUT) + device_printf(sc->bge_dev, "firmware handshake timed out, " + "found 0x%08x\n", val); + } /* * XXX Wait for the value of the PCISTATE register to @@ -3022,11 +3167,11 @@ bus_dmamap_sync(sc->bge_cdata.bge_rx_jumbo_ring_tag, sc->bge_cdata.bge_rx_jumbo_ring_map, BUS_DMASYNC_PREWRITE); - CSR_WRITE_4(sc, BGE_MBX_RX_CONS0_LO, sc->bge_rx_saved_considx); + bge_writembx(sc, BGE_MBX_RX_CONS0_LO, sc->bge_rx_saved_considx); if (stdcnt) - CSR_WRITE_4(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std); + bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std); if (jumbocnt) - CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); + bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); #ifdef notyet /* * This register wraps very quickly under heavy packet drops. @@ -3168,7 +3313,7 @@ * the status check). So toggling would probably be a pessimization * even with MSI. It would only be needed for using a task queue. */ - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 0); /* * Do the mandatory PCI flush as well as get the link status. @@ -3545,10 +3690,10 @@ return; /* Transmit. */ - CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx); + bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx); /* 5700 b2 errata */ if (sc->bge_chiprev == BGE_CHIPREV_5700_BX) - CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx); + bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx); sc->bge_tx_prodidx = prodidx; @@ -3675,7 +3820,7 @@ if (ifp->if_capenable & IFCAP_POLLING) { BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); } else #endif @@ -3683,7 +3828,7 @@ { BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_CLEAR_INTA); BGE_CLRBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 0); } bge_ifmedia_upd_locked(ifp); @@ -3906,7 +4051,7 @@ BGE_LOCK(sc); BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); ifp->if_capenable |= IFCAP_POLLING; BGE_UNLOCK(sc); } else { @@ -3915,7 +4060,7 @@ BGE_LOCK(sc); BGE_CLRBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 0); ifp->if_capenable &= ~IFCAP_POLLING; BGE_UNLOCK(sc); } @@ -4040,7 +4185,7 @@ /* Disable host interrupts. */ BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); /* * Tell firmware we're shutting down. @@ -4536,3 +4681,64 @@ return (error); } #endif + +static int +bge_get_eaddr_mem(struct bge_softc *sc, uint8_t ether_addr[]) +{ + uint32_t mac_addr; + int ret = 1; + + mac_addr = bge_readmem_ind(sc, 0x0c14); + if ((mac_addr >> 16) == 0x484b) { + ether_addr[0] = (uint8_t)(mac_addr >> 8); + ether_addr[1] = (uint8_t)mac_addr; + mac_addr = bge_readmem_ind(sc, 0x0c18); + ether_addr[2] = (uint8_t)(mac_addr >> 24); + ether_addr[3] = (uint8_t)(mac_addr >> 16); + ether_addr[4] = (uint8_t)(mac_addr >> 8); + ether_addr[5] = (uint8_t)mac_addr; + ret = 0; + } + return ret; +} + +static int +bge_get_eaddr_nvram(struct bge_softc *sc, uint8_t ether_addr[]) +{ + int mac_offset = BGE_EE_MAC_OFFSET; + + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) + mac_offset = BGE_EE_MAC_OFFSET_5906; + + return bge_read_nvram(sc, ether_addr, mac_offset + 2, ETHER_ADDR_LEN); +} + +static int +bge_get_eaddr_eeprom(struct bge_softc *sc, uint8_t ether_addr[]) +{ + if (!(sc->bge_flags & BGE_FLAG_EEPROM)) + return 1; + + return bge_read_eeprom(sc, ether_addr, BGE_EE_MAC_OFFSET + 2, + ETHER_ADDR_LEN); +} + +static int +bge_get_eaddr(struct bge_softc *sc, uint8_t eaddr[]) +{ + static const bge_eaddr_fcn_t bge_eaddr_funcs[] = { + /* NOTE: Order is critical */ + bge_get_eaddr_mem, + bge_get_eaddr_nvram, + bge_get_eaddr_eeprom, + NULL + }; + const bge_eaddr_fcn_t *func; + + for (func = bge_eaddr_funcs; *func != NULL; ++func) { + if ((*func)(sc, eaddr) == 0) + break; + } + return (*func == NULL ? ENXIO : 0); +} + --- ./sys/dev/bge/if_bgereg.h.orig 2007-05-22 21:22:58.000000000 +0200 +++ ./sys/dev/bge/if_bgereg.h 2008-03-01 14:55:49.000000000 +0100 @@ -283,6 +283,8 @@ #define BGE_CHIPID_BCM5787_A0 0xb0000000 #define BGE_CHIPID_BCM5787_A1 0xb0010000 #define BGE_CHIPID_BCM5787_A2 0xb0020000 +#define BGE_CHIPID_BCM5906_A1 0xc0010000 +#define BGE_CHIPID_BCM5906_A2 0xc0020000 /* shorthand one */ #define BGE_ASICREV(x) ((x) >> 28) @@ -299,6 +301,7 @@ #define BGE_ASICREV_BCM5755 0x0a #define BGE_ASICREV_BCM5754 0x0b #define BGE_ASICREV_BCM5787 0x0b +#define BGE_ASICREV_BCM5906 0x0c /* chip revisions */ #define BGE_CHIPREV(x) ((x) >> 24) @@ -1438,6 +1441,17 @@ #define BGE_RXCPUSTAT_MA_REQ_FIFOOFLOW 0x40000000 #define BGE_RXCPUSTAT_BLOCKING_READ 0x80000000 +/* + * V? CPU registers + */ +#define BGE_VCPU_STATUS 0x5100 +#define BGE_VCPU_EXT_CTRL 0x6890 + +#define BGE_VCPU_STATUS_INIT_DONE 0x04000000 +#define BGE_VCPU_STATUS_DRV_RESET 0x08000000 + +#define BGE_VCPU_EXT_CTRL_HALT_CPU 0x00400000 +#define BGE_VCPU_EXT_CTRL_DISABLE_WOL 0x20000000 /* * TX CPU registers @@ -1683,6 +1697,55 @@ #define BGE_MDI_CTL 0x6844 #define BGE_EE_DELAY 0x6848 #define BGE_FASTBOOT_PC 0x6894 +/* + * NVRAM Control registers + */ +#define BGE_NVRAM_CMD 0x7000 +#define BGE_NVRAM_STAT 0x7004 +#define BGE_NVRAM_WRDATA 0x7008 +#define BGE_NVRAM_ADDR 0x700c +#define BGE_NVRAM_RDDATA 0x7010 +#define BGE_NVRAM_CFG1 0x7014 +#define BGE_NVRAM_CFG2 0x7018 +#define BGE_NVRAM_CFG3 0x701c +#define BGE_NVRAM_SWARB 0x7020 +#define BGE_NVRAM_ACCESS 0x7024 +#define BGE_NVRAM_WRITE1 0x7028 + +#define BGE_NVRAMCMD_RESET 0x00000001 +#define BGE_NVRAMCMD_DONE 0x00000008 +#define BGE_NVRAMCMD_START 0x00000010 +#define BGE_NVRAMCMD_WR 0x00000020 /* 1 = wr, 0 = rd */ +#define BGE_NVRAMCMD_ERASE 0x00000040 +#define BGE_NVRAMCMD_FIRST 0x00000080 +#define BGE_NVRAMCMD_LAST 0x00000100 + +#define BGE_NVRAM_READCMD \ + (BGE_NVRAMCMD_FIRST|BGE_NVRAMCMD_LAST| \ + BGE_NVRAMCMD_START|BGE_NVRAMCMD_DONE) +#define BGE_NVRAM_WRITECMD \ + (BGE_NVRAMCMD_FIRST|BGE_NVRAMCMD_LAST| \ + BGE_NVRAMCMD_START|BGE_NVRAMCMD_DONE|BGE_NVRAMCMD_WR) + +#define BGE_NVRAMSWARB_SET0 0x00000001 +#define BGE_NVRAMSWARB_SET1 0x00000002 +#define BGE_NVRAMSWARB_SET2 0x00000003 +#define BGE_NVRAMSWARB_SET3 0x00000004 +#define BGE_NVRAMSWARB_CLR0 0x00000010 +#define BGE_NVRAMSWARB_CLR1 0x00000020 +#define BGE_NVRAMSWARB_CLR2 0x00000040 +#define BGE_NVRAMSWARB_CLR3 0x00000080 +#define BGE_NVRAMSWARB_GNT0 0x00000100 +#define BGE_NVRAMSWARB_GNT1 0x00000200 +#define BGE_NVRAMSWARB_GNT2 0x00000400 +#define BGE_NVRAMSWARB_GNT3 0x00000800 +#define BGE_NVRAMSWARB_REQ0 0x00001000 +#define BGE_NVRAMSWARB_REQ1 0x00002000 +#define BGE_NVRAMSWARB_REQ2 0x00004000 +#define BGE_NVRAMSWARB_REQ3 0x00008000 + +#define BGE_NVRAMACC_ENABLE 0x00000001 +#define BGE_NVRAMACC_WRENABLE 0x00000002 /* Mode control register */ #define BGE_MODECTL_INT_SNDCOAL_ONLY 0x00000001 @@ -1711,6 +1774,7 @@ /* Misc. config register */ #define BGE_MISCCFG_RESET_CORE_CLOCKS 0x00000001 #define BGE_MISCCFG_TIMER_PRESCALER 0x000000FE +#define BGE_MISCCFG_EPHY_IDDQ 0x00200000 #define BGE_32BITTIME_66MHZ (0x41 << 1) @@ -2037,6 +2101,8 @@ #define BCOM_DEVICEID_BCM5901 0x170D #define BCOM_DEVICEID_BCM5901A2 0x170E #define BCOM_DEVICEID_BCM5903M 0x16FF +#define BCOM_DEVICEID_BCM5906 0x1712 +#define BCOM_DEVICEID_BCM5906M 0x1713 /* * Alteon AceNIC PCI vendor/device ID. @@ -2090,6 +2156,7 @@ * Offset of MAC address inside EEPROM. */ #define BGE_EE_MAC_OFFSET 0x7C +#define BGE_EE_MAC_OFFSET_5906 0x10 #define BGE_EE_HWCFG_OFFSET 0xC8 #define BGE_HWCFG_VOLTAGE 0x00000003 @@ -2474,6 +2541,7 @@ #define BGE_FLAG_BER_BUG 0x02000000 #define BGE_FLAG_ADJUST_TRIM 0x04000000 #define BGE_FLAG_CRC_BUG 0x08000000 +#define BGE_FLAG_NO_EEPROM 0x10000000 uint32_t bge_chipid; uint8_t bge_asicrev; uint8_t bge_chiprev; --- ./sys/dev/mii/brgphy.c.70 2008-03-01 14:54:58.000000000 +0100 +++ ./sys/dev/mii/brgphy.c 2008-03-01 14:55:49.000000000 +0100 @@ -131,6 +131,7 @@ MII_PHY_DESC(xxBROADCOM_ALT1, BCM5755), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5787), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5708S), + MII_PHY_DESC(BROADCOM2, BCM5906), MII_PHY_END }; @@ -186,6 +187,7 @@ /* Handle any special cases based on the PHY ID */ switch (bsc->mii_oui) { case MII_OUI_BROADCOM: + case MII_OUI_BROADCOM2: break; case MII_OUI_xxBROADCOM: switch (bsc->mii_model) { @@ -226,12 +228,14 @@ bce_sc = ifp->if_softc; } - /* Todo: Need to add additional controllers such as 5906 & 5787F */ + /* Todo: Need to add additional controllers such as 5787F */ /* The 590x chips are 10/100 only. */ if (bge_sc && pci_get_vendor(bge_sc->bge_dev) == BCOM_VENDORID && (pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5901 || - pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5901A2)) { + pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5901A2 || + pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5906 || + pci_get_device(bge_sc->bge_dev) == BCOM_DEVICEID_BCM5906M)) { fast_ether = 1; sc->mii_anegticks = MII_ANEGTICKS; } @@ -930,6 +934,11 @@ PHY_READ(sc, BRGPHY_MII_PHY_EXTCTL) & ~BRGPHY_PHY_EXTCTL_3_LED); } + + /* Adjust output voltage (From Linux driver) */ + if (bge_sc->bge_asicrev == BGE_ASICREV_BCM5906) + PHY_WRITE(sc, BRGPHY_MII_EPHY_PTEST, 0x12); + /* Handle any bce (NetXtreme II) workarounds. */ } else if (bce_sc) { --- ./sys/dev/mii/brgphyreg.h.70 2008-03-01 14:55:05.000000000 +0100 +++ ./sys/dev/mii/brgphyreg.h 2008-03-01 14:55:49.000000000 +0100 @@ -161,6 +161,7 @@ #define BRGPHY_MII_DSP_RW_PORT 0x15 /* DSP coefficient r/w port */ #define BRGPHY_MII_DSP_ADDR_REG 0x17 /* DSP coefficient addr register */ +#define BRGPHY_MII_EPHY_PTEST 0x17 /* 5906 PHY register */ #define BRGPHY_DSP_TAP_NUMBER_MASK 0x00 #define BRGPHY_DSP_AGC_A 0x00 --------------060408000507000803020503-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 14:23:23 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A599D1065672 for ; Sat, 1 Mar 2008 14:23:23 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63909.mail.re1.yahoo.com (web63909.mail.re1.yahoo.com [69.147.97.124]) by mx1.freebsd.org (Postfix) with SMTP id 6F9338FC23 for ; Sat, 1 Mar 2008 14:23:23 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 38412 invoked by uid 60001); 1 Mar 2008 14:23:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=LnciiZfbx9aVmTbr7P0i4yOpm/8j48HgneUFPQDQX47bGwFbjER79LejvLEvniyUnl20BIkBFz1YiEMQIUhGQJ3gF0h/qrpV/gwp8cLZSCn+gB3HNCiOo6Li7LRvH6JeziCyUj3Z3WH+zSsM5XNu7XW1Qh7m1dpzY0EjH6bOVMw=; X-YMail-OSG: 50YQ4W4VM1m.Pd7Svqo2Fsq8QEXm9O9raadNCadWmSZkUpK6r88fMHzh15nK36YAL.cBQX405lYH6Le2LFlNvRCM9a97NPq_6mmQrNpZ6Wxn3lxcGKoZRFXOmx3qhQ-- Received: from [98.203.28.38] by web63909.mail.re1.yahoo.com via HTTP; Sat, 01 Mar 2008 06:23:22 PST Date: Sat, 1 Mar 2008 06:23:22 -0800 (PST) From: Barney Cordoba To: current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <424760.37304.qm@web63909.mail.re1.yahoo.com> Cc: Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 14:23:23 -0000 --- Ingo Flaschberger wrote: > > >> I have a 1.2Ghz Pentium-M appliance, with 4x > 32bit, 33MHz pci intel e1000 > >> cards. > >> With maximum tuning I can "route" ~400mbps with > big packets and ~80mbps > >> with 64byte packets. > >> around 100kpps, whats not bad for a pci > architecture. > >> > >> To reach higher bandwiths, better busses are > needed. > >> pci-express cards are currently the best choice. > >> one dedicated pci-express lane (1.25gbps) has > more bandwith than a whole > >> 32bit, 33mhz pci-bus. > > > > Like you say routing 400 Mb/s is close to the max > of the PCI bus, which > > has a theoretical max of 33*4*8 ~ 1Gbps. Now > routing is 500Mb/s in, 500Mb/s > > out. So you are within 80% of the bus-max, not > counting memory-access and > > others. > > yes. > > > PCI express will give you a bus per PCI-E device > into a central hub, thus > > upping the limit to the speed of the FrontSideBus > in Intel architectures. > > Which at the moment is a lot higher than what a > single PCI bus does. > > Thats why my next router will be based at this box: > http://www.axiomtek.com/products/ViewProduct.asp?view=429 > > Hopefully there will be direct memory bus connected > nic's in future. > (HyperTransport connected nic's) > > > What it does not explain is why you can only get > 80Mb/s with 64byte packets, > > which would suggest other bottlenecks than just > the bus. To clarify this, you seem to leave out PCI-X, which is an 8Mb/s bus, which is certainly able to route or bridge a gigabit of traffic. PCIe 4x has an unencoded data rate of 16Gb/s and PCIe 8x is 64Gb/s, which is more than enough to do gigabit and 10gig. PCI can BURST to 1Gb/s and PCI-X can BURST to 8Gb/s, but bursts are limited, so its not possible to achieve full bandwidth. The more devices on the bus, the less throughput you'll get due to contention. A more limiting factor for routing is packets/second, not the actual throughput. Its foolhardy to use a NIC that doesn't have enough bandwidth, so "usually", the limiting factor is the CPUs ability to process the packets regardless of their size. We bridged 1 million PPS on a FreeBSD 4.x machine with a 2.8Ghz opteron and PCI-x intel cards. A 7.0 system can do about 20% less (of course you don't lose the keyboard on a 7.0 system as you do on the 4.x system!). So I'd assume a 3Ghz xeon could likely do close to 1 million pps on a 7.0 system. Routing will be a bit slower. Also be advised that implementation is an issue with bus througput. I've tested systems with both PCIe and PCIx and the PCIx gave higher thoughput even though the PCIe is theoretically faster. MB/chipset design is a factor in the utilization capability of the bus. Barney ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 15:07:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0BD71065679 for ; Sat, 1 Mar 2008 15:07:31 +0000 (UTC) (envelope-from cgiordano@cox.net) Received: from eastrmmtai102.cox.net (eastrmmtai102.cox.net [68.230.240.21]) by mx1.freebsd.org (Postfix) with ESMTP id 25ABD8FC1B for ; Sat, 1 Mar 2008 15:07:30 +0000 (UTC) (envelope-from cgiordano@cox.net) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080301145544.SLPC25565.eastrmmtao103.cox.net@eastrmimpo01.cox.net> for ; Sat, 1 Mar 2008 09:55:44 -0500 Received: from [192.168.0.11] ([68.230.134.223]) by eastrmimpo01.cox.net with bizsmtp id vqvP1Y0024pMr5g02qvP2t; Sat, 01 Mar 2008 09:55:23 -0500 Message-ID: <47C96E82.9090304@cox.net> Date: Sat, 01 Mar 2008 09:56:02 -0500 From: "Christopher M. Giordano" User-Agent: Thunderbird 2.0.0.6 (X11/20070902) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 01 Mar 2008 15:20:01 +0000 Subject: kernel build error in dev/igb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 15:07:31 -0000 Kernel cvsup'ed around 3 AM today. Build dies in src/sys/dev/igb due to a printf format specifier conflict between %lu and u64 args. My patch to workaround is below. Index: if_igb.c =================================================================== RCS file: /opt/FreeBSD/cvs/src/sys/dev/igb/if_igb.c,v retrieving revision 1.4 diff -u -r1.4 if_igb.c --- if_igb.c 1 Mar 2008 04:36:24 -0000 1.4 +++ if_igb.c 1 Mar 2008 14:44:18 -0000 @@ -4207,11 +4207,11 @@ device_printf(dev, "Queue(%d) tdh = %d, tdt = %d\n", i, E1000_READ_REG(&adapter->hw, E1000_TDH(i)), E1000_READ_REG(&adapter->hw, E1000_TDT(i))); - device_printf(dev, "no descriptors avail event = %lu\n", + device_printf(dev, "no descriptors avail event = %llu\n", txr->no_desc_avail); - device_printf(dev, "TX(%d) IRQ Handled = %lu\n", txr->me, + device_printf(dev, "TX(%d) IRQ Handled = %llu\n", txr->me, txr->tx_irq); - device_printf(dev, "TX(%d) Packets sent = %lu\n", txr->me, + device_printf(dev, "TX(%d) Packets sent = %llu\n", txr->me, txr->tx_packets); } @@ -4219,11 +4219,11 @@ device_printf(dev, "Queue(%d) rdh = %d, rdt = %d\n", i, E1000_READ_REG(&adapter->hw, E1000_RDH(i)), E1000_READ_REG(&adapter->hw, E1000_RDT(i))); - device_printf(dev, "RX(%d) Packets received = %lu\n", rxr->me, + device_printf(dev, "RX(%d) Packets received = %llu\n", rxr->me, rxr->rx_packets); - device_printf(dev, "RX(%d) Byte count = %lu\n", rxr->me, + device_printf(dev, "RX(%d) Byte count = %llu\n", rxr->me, rxr->rx_bytes); - device_printf(dev, "RX(%d) IRQ Handled = %lu\n", rxr->me, + device_printf(dev, "RX(%d) IRQ Handled = %llu\n", rxr->me, rxr->rx_irq); } device_printf(dev, "LINK IRQ Handled = %u\n", adapter->link_irq); From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 16:55:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67357106566C for ; Sat, 1 Mar 2008 16:55:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 245AE8FC13 for ; Sat, 1 Mar 2008 16:55:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21GtdiP002184; Sat, 1 Mar 2008 11:55:39 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m21GtcMU078673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 11:55:39 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200803011655.m21GtcMU078673@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 01 Mar 2008 11:53:41 -0500 To: pyunyh@gmail.com From: Mike Tancsa In-Reply-To: <20080228003027.GA56411@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <20080217112104.X80805@fledge.watson.org> <200802171458.26951.freebsd-current@dino.sk> <200802171517.26965.freebsd-current@dino.sk> <20080218081801.GB14601@cdnetworks.co.kr> <20080222054356.GE30497@cdnetworks.co.kr> <200802260503.m1Q53Jm3050738@lava.sentex.ca> <20080226053423.GB47750@cdnetworks.co.kr> <200802271712.m1RHC6Rx060293@lava.sentex.ca> <20080228003027.GA56411@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 16:55:40 -0000 At 07:30 PM 2/27/2008, Pyun YongHyeon wrote: >I never thought this kind of testing. It's good to hear vr(4) >recovers from the abrupt link change events. I guess this also >indicates the overhauled vr(4) can close lots of PR for vr(4). BTW, any chance of these fixes being backported to RELENG_7 and RELENG_6 ? Its not just media speed changes that causes the nic to wedge, and up/down transition (eg. a device via xover cable that reboots) will do the same thing :( ---Mike From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 17:46:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E43FF1065675 for ; Sat, 1 Mar 2008 17:46:00 +0000 (UTC) (envelope-from molla5@yahoo.com) Received: from web30706.mail.mud.yahoo.com (web30706.mail.mud.yahoo.com [68.142.200.139]) by mx1.freebsd.org (Postfix) with SMTP id 79FA48FC23 for ; Sat, 1 Mar 2008 17:46:00 +0000 (UTC) (envelope-from molla5@yahoo.com) Received: (qmail 70284 invoked by uid 60001); 1 Mar 2008 17:45:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=llOpZzFEQJdxuFHHyAiMKX/Ey7c8mFUeMlYB6Yfv/8+hGXP8+Gh6V9LRXVHwW6+pfYKVf3QqmfIPnVM+jau1CtD9uUQwZmF1do5yxgPVzLI1TpacQ9uEj05mDqa12MTmECBCAha9IpZt0We0IjFkm6zJSAmJFZ5+j1akJQUQkYM=; X-YMail-OSG: k_2n7BsVM1nUbEbMK3vPI9HTna0b3g2UCLSRV8l2lqFNbY8j1imXszdERcXFjGEn4A-- Received: from [88.255.56.37] by web30706.mail.mud.yahoo.com via HTTP; Sat, 01 Mar 2008 09:45:59 PST Date: Sat, 1 Mar 2008 09:45:59 -0800 (PST) From: Ayhan Molla To: Thomas "Nyström" In-Reply-To: <47C963F0.3000707@saeab.se> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1973998415-1204393559=:69488" Content-Transfer-Encoding: 8bit Message-ID: <795686.69488.qm@web30706.mail.mud.yahoo.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Broadcom Netlink BCM5906M X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 17:46:01 -0000 --0-1973998415-1204393559=:69488 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Thank you very much, it works beautifully now. However I also needed to add the follwing lines to the /usr/src/sys/dev/mii/miidevs file, I copied them from dragonflyBSD source. oui BROADCOM2 0x000af7 Broadcom2 Corporation oui xxBROADCOM2 0x000af7 Broadcom Corporation model BROADCOM2 BCM5906 0x0004 BCM5906 10/100/1000baseTX PHY model xxBROADCOM2 BCM5906 0x0004 BCM5906 10/100/1000baseTX PHY Thank you very much again. Thomas Nyström wrote: Ayhan Molla wrote: > Hi, > I am having trouble applying the patch for the BCM5906. The patch is > supposed to work for 7.0-RC1. I have installed 7.0-Release and patch > didn't work for me. > if_bge.c file has changed since RC1 and therefore I wasn't able to > manually apply the patch. > > Has someone tried to apply the patch for 7.0-Release? Try the new attached (untested) patch! /Thomas -- --------------------------------------------------------------- Svensk Aktuell Elektronik AB Thomas Nyström Box 10 Phone: +46 73 069 69 30 S-191 21 Sollentuna Fax: +46 8 35 92 89 Sweden Email: thn@saeab.se --------------------------------------------------------------- --- ./sys/dev/bge/if_bge.c.70 2008-03-01 15:03:15.000000000 +0100 +++ ./sys/dev/bge/if_bge.c 2008-03-01 15:00:22.000000000 +0100 @@ -195,6 +195,8 @@ { BCOM_VENDORID, BCOM_DEVICEID_BCM5901 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5901A2 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5903M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5906 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5906M }, { SK_VENDORID, SK_DEVICEID_ALTIMA }, @@ -271,6 +273,8 @@ { BGE_CHIPID_BCM5787_A0, "BCM5754/5787 A0" }, { BGE_CHIPID_BCM5787_A1, "BCM5754/5787 A1" }, { BGE_CHIPID_BCM5787_A2, "BCM5754/5787 A2" }, + { BGE_CHIPID_BCM5906_A1, "BCM5906 A1" }, + { BGE_CHIPID_BCM5906_A2, "BCM5906 A2" }, { 0, NULL } }; @@ -293,6 +297,7 @@ { BGE_ASICREV_BCM5755, "unknown BCM5755" }, /* 5754 and 5787 share the same ASIC ID */ { BGE_ASICREV_BCM5787, "unknown BCM5754/5787" }, + { BGE_ASICREV_BCM5906, "unknown BCM5906" }, { 0, NULL } }; @@ -305,6 +310,9 @@ const struct bge_revision * bge_lookup_rev(uint32_t); const struct bge_vendor * bge_lookup_vendor(uint16_t); + +typedef int (*bge_eaddr_fcn_t)(struct bge_softc *, uint8_t[]); + static int bge_probe(device_t); static int bge_attach(device_t); static int bge_detach(device_t); @@ -315,6 +323,11 @@ static int bge_dma_alloc(device_t); static void bge_dma_free(struct bge_softc *); +static int bge_get_eaddr_mem(struct bge_softc *, uint8_t[]); +static int bge_get_eaddr_nvram(struct bge_softc *, uint8_t[]); +static int bge_get_eaddr_eeprom(struct bge_softc *, uint8_t[]); +static int bge_get_eaddr(struct bge_softc *, uint8_t[]); + static void bge_txeof(struct bge_softc *); static void bge_rxeof(struct bge_softc *); @@ -337,6 +350,9 @@ static int bge_ifmedia_upd(struct ifnet *); static void bge_ifmedia_sts(struct ifnet *, struct ifmediareq *); +static uint8_t bge_nvram_getbyte(struct bge_softc *, int, uint8_t *); +static int bge_read_nvram(struct bge_softc *, caddr_t, int, int); + static uint8_t bge_eeprom_getbyte(struct bge_softc *, int, uint8_t *); static int bge_read_eeprom(struct bge_softc *, caddr_t, int, int); @@ -359,6 +375,7 @@ static int bge_has_eeprom(struct bge_softc *); static uint32_t bge_readmem_ind(struct bge_softc *, int); static void bge_writemem_ind(struct bge_softc *, int, int); +static void bge_writembx(struct bge_softc *, int, int); #ifdef notdef static uint32_t bge_readreg_ind(struct bge_softc *, int); #endif @@ -474,6 +491,10 @@ return (0); } #endif + + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) + return (0); + return (1); } @@ -533,6 +554,15 @@ CSR_WRITE_4(sc, off, val); } +static void +bge_writembx(struct bge_softc *sc, int off, int val) +{ + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) + off += BGE_LPMBX_IRQ0_HI - BGE_MBX_IRQ0_HI; + + CSR_WRITE_4(sc, off, val); +} + /* * Map a single buffer address. */ @@ -555,6 +585,78 @@ ctx->bge_busaddr = segs->ds_addr; } +static uint8_t +bge_nvram_getbyte(struct bge_softc *sc, int addr, uint8_t *dest) +{ + uint32_t access, byte = 0; + int i; + + /* Lock. */ + CSR_WRITE_4(sc, BGE_NVRAM_SWARB, BGE_NVRAMSWARB_SET1); + for (i = 0; i < 8000; i++) { + if (CSR_READ_4(sc, BGE_NVRAM_SWARB) & BGE_NVRAMSWARB_GNT1) + break; + DELAY(20); + } + if (i == 8000) + return (1); + + /* Enable access. */ + access = CSR_READ_4(sc, BGE_NVRAM_ACCESS); + CSR_WRITE_4(sc, BGE_NVRAM_ACCESS, access | BGE_NVRAMACC_ENABLE); + + CSR_WRITE_4(sc, BGE_NVRAM_ADDR, addr & 0xfffffffc); + CSR_WRITE_4(sc, BGE_NVRAM_CMD, BGE_NVRAM_READCMD); + for (i = 0; i < BGE_TIMEOUT * 10; i++) { + DELAY(10); + if (CSR_READ_4(sc, BGE_NVRAM_CMD) & BGE_NVRAMCMD_DONE) { + DELAY(10); + break; + } + } + + if (i == BGE_TIMEOUT * 10) { + if_printf(sc->bge_ifp, "nvram read timed out\n"); + return (1); + } + + /* Get result. */ + byte = CSR_READ_4(sc, BGE_NVRAM_RDDATA); + + *dest = (bswap32(byte) >> ((addr % 4) * 8)) & 0xFF; + + /* Disable access. */ + CSR_WRITE_4(sc, BGE_NVRAM_ACCESS, access); + + /* Unlock. */ + CSR_WRITE_4(sc, BGE_NVRAM_SWARB, BGE_NVRAMSWARB_CLR1); + CSR_READ_4(sc, BGE_NVRAM_SWARB); + + return (0); +} + +/* + * Read a sequence of bytes from NVRAM. + */ +static int +bge_read_nvram(struct bge_softc *sc, caddr_t dest, int off, int cnt) +{ + int err = 0, i; + uint8_t byte = 0; + + if (sc->bge_asicrev != BGE_ASICREV_BCM5906) + return (1); + + for (i = 0; i < cnt; i++) { + err = bge_nvram_getbyte(sc, off + i, &byte); + if (err) + break; + *(dest + i) = byte; + } + + return (err ? 1 : 0); +} + /* * Read a byte of data stored in the EEPROM at address 'addr.' The * BCM570x supports both the traditional bitbang interface and an @@ -659,11 +761,13 @@ } if (i == BGE_TIMEOUT) { - device_printf(sc->bge_dev, "PHY read timed out\n"); + device_printf(sc->bge_dev, "PHY read timed out " + "(phy %d, reg %d, val 0x%08x)\n", phy, reg, val); val = 0; goto done; } + DELAY(5); val = CSR_READ_4(sc, BGE_MI_COMM); done: @@ -687,6 +791,10 @@ sc = device_get_softc(dev); + if (sc->bge_asicrev == BGE_ASICREV_BCM5906 && + (reg == BRGPHY_MII_1000CTL || reg == BRGPHY_MII_AUXCTL)) + return(0); + /* Reading with autopolling on may trigger PCI errors */ autopoll = CSR_READ_4(sc, BGE_MI_MODE); if (autopoll & BGE_MIMODE_AUTOPOLL) { @@ -699,12 +807,17 @@ for (i = 0; i < BGE_TIMEOUT; i++) { DELAY(10); - if (!(CSR_READ_4(sc, BGE_MI_COMM) & BGE_MICOMM_BUSY)) + if (!(CSR_READ_4(sc, BGE_MI_COMM) & BGE_MICOMM_BUSY)) { + DELAY(5); + CSR_READ_4(sc, BGE_MI_COMM); /* dummy read */ break; + } } if (i == BGE_TIMEOUT) { - device_printf(sc->bge_dev, "PHY write timed out\n"); + device_printf(sc->bge_dev, + "PHY write timed out (phy %d, reg %d, val %d)\n", + phy, reg, val); return (0); } @@ -887,7 +1000,7 @@ BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); sc->bge_std = i - 1; - CSR_WRITE_4(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std); + bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std); return (0); } @@ -934,7 +1047,7 @@ BGE_RCB_FLAG_USE_EXT_RX_BD); CSR_WRITE_4(sc, BGE_RX_JUMBO_RCB_MAXLEN_FLAGS, rcb->bge_maxlen_flags); - CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); + bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); return (0); } @@ -990,17 +1103,17 @@ /* Initialize transmit producer index for host-memory send ring. */ sc->bge_tx_prodidx = 0; - CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx); + bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx); /* 5700 b2 errata */ if (sc->bge_chiprev == BGE_CHIPREV_5700_BX) - CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx); + bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, sc->bge_tx_prodidx); /* NIC-memory send ring not used; initialize to zero. */ - CSR_WRITE_4(sc, BGE_MBX_TX_NIC_PROD0_LO, 0); + bge_writembx(sc, BGE_MBX_TX_NIC_PROD0_LO, 0); /* 5700 b2 errata */ if (sc->bge_chiprev == BGE_CHIPREV_5700_BX) - CSR_WRITE_4(sc, BGE_MBX_TX_NIC_PROD0_LO, 0); + bge_writembx(sc, BGE_MBX_TX_NIC_PROD0_LO, 0); return (0); } @@ -1271,6 +1384,15 @@ /* Set the timer prescaler (always 66Mhz) */ CSR_WRITE_4(sc, BGE_MISC_CFG, BGE_32BITTIME_66MHZ); + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + DELAY(40); /* XXX */ + + /* Put PHY into ready state */ + BGE_CLRBIT(sc, BGE_MISC_CFG, BGE_MISCCFG_EPHY_IDDQ); + CSR_READ_4(sc, BGE_MISC_CFG); /* Flush */ + DELAY(40); + } + return (0); } @@ -1307,15 +1429,21 @@ CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_LEN, 0x2000); } + /* Configure mbuf pool watermarks */ - if (BGE_IS_5705_PLUS(sc)) { - CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0); - CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10); - } else { + if (!BGE_IS_5705_PLUS(sc)) { CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x50); CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x20); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60); + } else if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x04); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x10); + } else { + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10); + CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60); } - CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60); /* Configure DMA resource watermarks */ CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_LOWAT, 5); @@ -1462,15 +1590,15 @@ BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, BGE_RCB_FLAG_RING_DISABLED)); RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); - CSR_WRITE_4(sc, BGE_MBX_RX_CONS0_LO + + bge_writembx(sc, BGE_MBX_RX_CONS0_LO + (i * (sizeof(uint64_t))), 0); vrcb += sizeof(struct bge_rcb); } /* Initialize RX ring indexes */ - CSR_WRITE_4(sc, BGE_MBX_RX_STD_PROD_LO, 0); - CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, 0); - CSR_WRITE_4(sc, BGE_MBX_RX_MINI_PROD_LO, 0); + bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, 0); + bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, 0); + bge_writembx(sc, BGE_MBX_RX_MINI_PROD_LO, 0); /* * Set up RX return ring 0 @@ -2230,7 +2358,6 @@ struct ifnet *ifp; struct bge_softc *sc; uint32_t hwcfg = 0; - uint32_t mac_tmp = 0; u_char eaddr[ETHER_ADDR_LEN]; int error, reg, rid, trys; @@ -2283,6 +2410,7 @@ case BGE_ASICREV_BCM5752: case BGE_ASICREV_BCM5755: case BGE_ASICREV_BCM5787: + case BGE_ASICREV_BCM5906: sc->bge_flags |= BGE_FLAG_575X_PLUS; /* FALLTHRU */ case BGE_ASICREV_BCM5705: @@ -2304,7 +2432,7 @@ if (sc->bge_asicrev == BGE_ASICREV_BCM5755 || sc->bge_asicrev == BGE_ASICREV_BCM5787) sc->bge_flags |= BGE_FLAG_JITTER_BUG; - else + else if (sc->bge_asicrev != BGE_ASICREV_BCM5906) sc->bge_flags |= BGE_FLAG_BER_BUG; } @@ -2415,22 +2543,14 @@ } #ifdef __sparc64__ - if ((sc->bge_flags & BGE_FLAG_EEPROM) == 0) + if (((sc->bge_flags & BGE_FLAG_EEPROM) == 0) && + (sc->bge_asicrev != BGE_ASICREV_BCM5906)) OF_getetheraddr(dev, eaddr); else #endif { - mac_tmp = bge_readmem_ind(sc, 0x0C14); - if ((mac_tmp >> 16) == 0x484B) { - eaddr[0] = (u_char)(mac_tmp >> 8); - eaddr[1] = (u_char)mac_tmp; - mac_tmp = bge_readmem_ind(sc, 0x0C18); - eaddr[2] = (u_char)(mac_tmp >> 24); - eaddr[3] = (u_char)(mac_tmp >> 16); - eaddr[4] = (u_char)(mac_tmp >> 8); - eaddr[5] = (u_char)mac_tmp; - } else if (bge_read_eeprom(sc, eaddr, - BGE_EE_MAC_OFFSET + 2, ETHER_ADDR_LEN)) { + error = bge_get_eaddr(sc, eaddr); + if (error) { device_printf(sc->bge_dev, "failed to read station address\n"); error = ENXIO; @@ -2688,7 +2808,8 @@ dev = sc->bge_dev; - if (BGE_IS_575X_PLUS(sc) && !BGE_IS_5714_FAMILY(sc)) { + if (BGE_IS_575X_PLUS(sc) && !BGE_IS_5714_FAMILY(sc) && + (sc->bge_asicrev != BGE_ASICREV_BCM5906)) { if (sc->bge_flags & BGE_FLAG_PCIE) write_op = bge_writemem_direct; else @@ -2744,6 +2865,17 @@ /* Issue global reset */ write_op(sc, BGE_MISC_CFG, reset); + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + uint32_t status, ctrl; + + status = CSR_READ_4(sc, BGE_VCPU_STATUS); + CSR_WRITE_4(sc, BGE_VCPU_STATUS, + status | BGE_VCPU_STATUS_DRV_RESET); + ctrl = CSR_READ_4(sc, BGE_VCPU_EXT_CTRL); + CSR_WRITE_4(sc, BGE_VCPU_EXT_CTRL, + ctrl & ~BGE_VCPU_EXT_CTRL_HALT_CPU); + } + DELAY(1000); /* XXX: Broadcom Linux driver. */ @@ -2788,21 +2920,34 @@ } else CSR_WRITE_4(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE); - /* - * Poll until we see the 1's complement of the magic number. - * This indicates that the firmware initialization is complete. - * We expect this to fail if no EEPROM is fitted though. - */ - for (i = 0; i < BGE_TIMEOUT; i++) { - DELAY(10); - val = bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM); - if (val == ~BGE_MAGIC_NUMBER) - break; - } + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) { + for (i = 0; i < BGE_TIMEOUT; i++) { + val = CSR_READ_4(sc, BGE_VCPU_STATUS); + if (val & BGE_VCPU_STATUS_INIT_DONE) + break; + DELAY(100); + } + if (i == BGE_TIMEOUT) { + device_printf(sc->bge_dev, "reset timed out\n"); + return (1); + } + } else { + /* + * Poll until we see the 1's complement of the magic number. + * This indicates that the firmware initialization is complete. + * We expect this to fail if no EEPROM is fitted though. + */ + for (i = 0; i < BGE_TIMEOUT; i++) { + DELAY(10); + val = bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM); + if (val == ~BGE_MAGIC_NUMBER) + break; + } - if ((sc->bge_flags & BGE_FLAG_EEPROM) && i == BGE_TIMEOUT) - device_printf(sc->bge_dev, "firmware handshake timed out, " - "found 0x%08x\n", val); + if ((sc->bge_flags & BGE_FLAG_EEPROM) && i == BGE_TIMEOUT) + device_printf(sc->bge_dev, "firmware handshake timed out, " + "found 0x%08x\n", val); + } /* * XXX Wait for the value of the PCISTATE register to @@ -3022,11 +3167,11 @@ bus_dmamap_sync(sc->bge_cdata.bge_rx_jumbo_ring_tag, sc->bge_cdata.bge_rx_jumbo_ring_map, BUS_DMASYNC_PREWRITE); - CSR_WRITE_4(sc, BGE_MBX_RX_CONS0_LO, sc->bge_rx_saved_considx); + bge_writembx(sc, BGE_MBX_RX_CONS0_LO, sc->bge_rx_saved_considx); if (stdcnt) - CSR_WRITE_4(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std); + bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std); if (jumbocnt) - CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); + bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); #ifdef notyet /* * This register wraps very quickly under heavy packet drops. @@ -3168,7 +3313,7 @@ * the status check). So toggling would probably be a pessimization * even with MSI. It would only be needed for using a task queue. */ - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 0); /* * Do the mandatory PCI flush as well as get the link status. @@ -3545,10 +3690,10 @@ return; /* Transmit. */ - CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx); + bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx); /* 5700 b2 errata */ if (sc->bge_chiprev == BGE_CHIPREV_5700_BX) - CSR_WRITE_4(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx); + bge_writembx(sc, BGE_MBX_TX_HOST_PROD0_LO, prodidx); sc->bge_tx_prodidx = prodidx; @@ -3675,7 +3820,7 @@ if (ifp->if_capenable & IFCAP_POLLING) { BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); } else #endif @@ -3683,7 +3828,7 @@ { BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_CLEAR_INTA); BGE_CLRBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 0); } bge_ifmedia_upd_locked(ifp); @@ -3906,7 +4051,7 @@ BGE_LOCK(sc); BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); ifp->if_capenable |= IFCAP_POLLING; BGE_UNLOCK(sc); } else { @@ -3915,7 +4060,7 @@ BGE_LOCK(sc); BGE_CLRBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 0); ifp->if_capenable &= ~IFCAP_POLLING; BGE_UNLOCK(sc); } @@ -4040,7 +4185,7 @@ /* Disable host interrupts. */ BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); /* * Tell firmware we're shutting down. @@ -4536,3 +4681,64 @@ return (error); } #endif + +static int +bge_get_eaddr_mem(struct bge_softc *sc, uint8_t ether_addr[]) +{ + uint32_t mac_addr; + int ret = 1; + + mac_addr = bge_readmem_ind(sc, 0x0c14); + if ((mac_addr >> 16) == 0x484b) { + ether_addr[0] = (uint8_t)(mac_addr >> 8); + ether_addr[1] = (uint8_t)mac_addr; + mac_addr = bge_readmem_ind(sc, 0x0c18); + ether_addr[2] = (uint8_t)(mac_addr >> 24); + ether_addr[3] = (uint8_t)(mac_addr >> 16); + ether_addr[4] = (uint8_t)(mac_addr >> 8); + ether_addr[5] = (uint8_t)mac_addr; + ret = 0; + } + return ret; +} + +static int +bge_get_eaddr_nvram(struct bge_softc *sc, uint8_t ether_addr[]) +{ + int mac_offset = BGE_EE_MAC_OFFSET; + + if (sc->bge_asicrev == BGE_ASICREV_BCM5906) + mac_offset = BGE_EE_MAC_OFFSET_5906; + + return bge_read_nvram(sc, ether_addr, mac_offset + 2, ETHER_ADDR_LEN); +} + +static int +bge_get_eaddr_eeprom(struct bge_softc *sc, uint8_t ether_addr[]) +{ + if (!(sc->bge_flags & BGE_FLAG_EEPROM)) + return 1; + + return bge_read_eeprom(sc, ether_addr, BGE_EE_MAC_OFFSET + 2, + ETHER_ADDR_LEN); +} + +static int +bge_get_eaddr(struct bge_softc *sc, uint8_t eaddr[]) +{ + static const bge_eaddr_fcn_t bge_eaddr_funcs[] = { + /* NOTE: Order is critical */ + bge_get_eaddr_mem, + bge_get_eaddr_nvram, + bge_get_eaddr_eeprom, + NULL + }; + const bge_eaddr_fcn_t *func; + + for (func = bge_eaddr_funcs; *func != NULL; ++func) { + if ((*func)(sc, eaddr) == 0) + break; + } + return (*func == NULL ? ENXIO : 0); +} + --- ./sys/dev/bge/if_bgereg.h.orig 2007-05-22 21:22:58.000000000 +0200 +++ ./sys/dev/bge/if_bgereg.h 2008-03-01 14:55:49.000000000 +0100 @@ -283,6 +283,8 @@ #define BGE_CHIPID_BCM5787_A0 0xb0000000 #define BGE_CHIPID_BCM5787_A1 0xb0010000 #define BGE_CHIPID_BCM5787_A2 0xb0020000 +#define BGE_CHIPID_BCM5906_A1 0xc0010000 +#define BGE_CHIPID_BCM5906_A2 0xc0020000 /* shorthand one */ #define BGE_ASICREV(x) ((x) >> 28) @@ -299,6 +301,7 @@ #define BGE_ASICREV_BCM5755 0x0a #define BGE_ASICREV_BCM5754 0x0b #define BGE_ASICREV_BCM5787 0x0b +#define BGE_ASICREV_BCM5906 0x0c /* chip revisions */ #define BGE_CHIPREV(x) ((x) >> 24) @@ -1438,6 +1441,17 @@ #define BGE_RXCPUSTAT_MA_REQ_FIFOOFLOW 0x40000000 #define BGE_RXCPUSTAT_BLOCKING_READ 0x80000000 +/* + * V? CPU registers + */ +#define BGE_VCPU_STATUS 0x5100 +#define BGE_VCPU_EXT_CTRL 0x6890 + +#define BGE_VCPU_STATUS_INIT_DONE 0x04000000 +#define BGE_VCPU_STATUS_DRV_RESET 0x08000000 + +#define BGE_VCPU_EXT_CTRL_HALT_CPU 0x00400000 +#define BGE_VCPU_EXT_CTRL_DISABLE_WOL 0x20000000 /* * TX CPU registers @@ -1683,6 +1697,55 @@ #define BGE_MDI_CTL 0x6844 #define BGE_EE_DELAY 0x6848 #define BGE_FASTBOOT_PC 0x6894 +/* + * NVRAM Control registers + */ +#define BGE_NVRAM_CMD 0x7000 +#define BGE_NVRAM_STAT 0x7004 +#define BGE_NVRAM_WRDATA 0x7008 +#define BGE_NVRAM_ADDR 0x700c +#define BGE_NVRAM_RDDATA 0x7010 +#define BGE_NVRAM_CFG1 0x7014 +#define BGE_NVRAM_CFG2 0x7018 +#define BGE_NVRAM_CFG3 0x701c +#define BGE_NVRAM_SWARB 0x7020 +#define BGE_NVRAM_ACCESS 0x7024 +#define BGE_NVRAM_WRITE1 0x7028 + +#define BGE_NVRAMCMD_RESET 0x00000001 +#define BGE_NVRAMCMD_DONE 0x00000008 +#define BGE_NVRAMCMD_START 0x00000010 +#define BGE_NVRAMCMD_WR 0x00000020 /* 1 = wr, 0 = rd */ +#define BGE_NVRAMCMD_ERASE 0x00000040 +#define BGE_NVRAMCMD_FIRST 0x00000080 +#define BGE_NVRAMCMD_LAST 0x00000100 + +#define BGE_NVRAM_READCMD \ + (BGE_NVRAMCMD_FIRST|BGE_NVRAMCMD_LAST| \ + BGE_NVRAMCMD_START|BGE_NVRAMCMD_DONE) +#define BGE_NVRAM_WRITECMD \ + (BGE_NVRAMCMD_FIRST|BGE_NVRAMCMD_LAST| \ + BGE_NVRAMCMD_START|BGE_NVRAMCMD_DONE|BGE_NVRAMCMD_WR) + +#define BGE_NVRAMSWARB_SET0 0x00000001 +#define BGE_NVRAMSWARB_SET1 0x00000002 +#define BGE_NVRAMSWARB_SET2 0x00000003 +#define BGE_NVRAMSWARB_SET3 0x00000004 +#define BGE_NVRAMSWARB_CLR0 0x00000010 +#define BGE_NVRAMSWARB_CLR1 0x00000020 +#define BGE_NVRAMSWARB_CLR2 0x00000040 +#define BGE_NVRAMSWARB_CLR3 0x00000080 +#define BGE_NVRAMSWARB_GNT0 0x00000100 +#define BGE_NVRAMSWARB_GNT1 0x00000200 +#define BGE_NVRAMSWARB_GNT2 0x00000400 +#define BGE_NVRAMSWARB_GNT3 0x00000800 +#define BGE_NVRAMSWARB_REQ0 0x00001000 +#define BGE_NVRAMSWARB_REQ1 0x00002000 +#define BGE_NVRAMSWARB_REQ2 0x00004000 +#define BGE_NVRAMSWARB_REQ3 0x00008000 + +#define BGE_NVRAMACC_ENABLE 0x00000001 +#define BGE_NVRAMACC_WRENABLE 0x00000002 /* Mode control register */ #define BGE_MODECTL_INT_SNDCOAL_ONLY 0x00000001 @@ -1711,6 +1774,7 @@ /* Misc. config register */ #define BGE_MISCCFG_RESET_CORE_CLOCKS 0x00000001 #define BGE_MISCCFG_TIMER_PRESCALER 0x000000FE +#define BGE_MISCCFG_EPHY_IDDQ 0x00200000 #define BGE_32BITTIME_66MHZ (0x41 << 1) @@ -2037,6 +2101,8 @@ #define BCOM_DEVICEID_BCM5901 0x170D #define BCOM_DEVICEID_BCM5901A2 0x170E #define BCOM_DEVICEID_BCM5903M 0x16FF +#define BCOM_DEVICEID_BCM5906 0x1712 +#define BCOM_DEVICEID_BCM5906M 0x1713 /* * Alteon AceNIC PCI vendor/device ID. === message truncated === --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-1973998415-1204393559=:69488 Content-Type: text/plain; name="bge_miidev.txt" Content-Description: 3843043294-bge_miidev.txt Content-Disposition: inline; filename="bge_miidev.txt" --- /usr/src/sys/dev/mii/miidevs 2007-11-05 01:42:02.000000000 +0000 +++ /usr/src/sys/dev/mii/miidevs 2008-02-29 19:31:15.000000000 +0000 @@ -52,6 +52,7 @@ oui ALTIMA 0x0010a9 Altima Communications oui AMD 0x00001a Advanced Micro Devices oui BROADCOM 0x001018 Broadcom Corporation +oui BROADCOM2 0x000af7 Broadcom2 Corporation oui CICADA 0x0003F1 Cicada Semiconductor oui DAVICOM 0x00606e Davicom Semiconductor oui ICPLUS 0x0090c3 IC Plus Corp. @@ -80,6 +81,7 @@ /* some vendors have the bits swapped within bytes (ie, ordered as on the wire) */ oui xxALTIMA 0x000895 Altima Communications +oui xxBROADCOM2 0x000af7 Broadcom Corporation oui xxBROADCOM 0x000818 Broadcom Corporation oui xxBROADCOM_ALT1 0x0050ef Broadcom Corporation oui xxICS 0x00057d Integrated Circuit Systems @@ -136,6 +138,8 @@ model xxBROADCOM_ALT1 BCM5787 0x000e BCM5787 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5708S 0x0015 BCM5708S 1000/2500BaseSX PHY +model BROADCOM2 BCM5906 0x0004 BCM5906 10/100/1000baseTX PHY +model xxBROADCOM2 BCM5906 0x0004 BCM5906 10/100/1000baseTX PHY /* Cicada Semiconductor PHYs (now owned by Vitesse?) */ model CICADA CS8201 0x0001 Cicada CS8201 10/100/1000TX PHY model CICADA CS8201A 0x0020 Cicada CS8201 10/100/1000TX PHY --0-1973998415-1204393559=:69488-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 18:26:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0E36106566B for ; Sat, 1 Mar 2008 18:26:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236]) by mx1.freebsd.org (Postfix) with ESMTP id 69E4D8FC18 for ; Sat, 1 Mar 2008 18:26:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so6452136qbd.7 for ; Sat, 01 Mar 2008 10:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wRDCdL081z0d5SHbskteBn/GIcETP2XOMNfA4BY5WNQ=; b=LPWY2MAumCY4EuwE1pa8c/uXkgOu+i9Gr1MY/ukkLMnqxf/c25WbU8fIIGkkIvLh71TUGMuVE40/9seGc4dej+xdcb4oGG4Lm5AmGhUDb16/WtoICzgnA3Lrk821ZH4zUEpmImud/PWIimvM79fJFMyDCn8qqsZkKT9+2bOQW5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tf9l0ovLVklO/VpFiVaWxheqnZooLy1QGVybDaSZdmyGNxuNOOGaw20jfr/fSh10feb2G2oDQBf5lpbvgcL5kwWYU8Dy3NfUlyBHzo8R4ZZsoHMr8ohHf5ck9hZrP0I5yr9Ao1O8VMEuk0WKbP2kn0RjG/aI6J42q2/jtg/XJjU= Received: by 10.114.132.5 with SMTP id f5mr2652297wad.50.1204395187371; Sat, 01 Mar 2008 10:13:07 -0800 (PST) Received: by 10.114.177.4 with HTTP; Sat, 1 Mar 2008 10:13:07 -0800 (PST) Message-ID: <2a41acea0803011013r27d5202geeb212c984137cef@mail.gmail.com> Date: Sat, 1 Mar 2008 10:13:07 -0800 From: "Jack Vogel" To: "Christopher M. Giordano" In-Reply-To: <47C96E82.9090304@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47C96E82.9090304@cox.net> Cc: freebsd-current@freebsd.org Subject: Re: kernel build error in dev/igb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 18:26:45 -0000 cvsup, its already fixed. On Sat, Mar 1, 2008 at 6:56 AM, Christopher M. Giordano wrote: > Kernel cvsup'ed around 3 AM today. > Build dies in src/sys/dev/igb due to a printf format specifier > conflict between %lu and u64 args. My patch to workaround > is below. > > > Index: if_igb.c > =================================================================== > RCS file: /opt/FreeBSD/cvs/src/sys/dev/igb/if_igb.c,v > retrieving revision 1.4 > diff -u -r1.4 if_igb.c > --- if_igb.c 1 Mar 2008 04:36:24 -0000 1.4 > +++ if_igb.c 1 Mar 2008 14:44:18 -0000 > @@ -4207,11 +4207,11 @@ > device_printf(dev, "Queue(%d) tdh = %d, tdt = %d\n", i, > E1000_READ_REG(&adapter->hw, E1000_TDH(i)), > E1000_READ_REG(&adapter->hw, E1000_TDT(i))); > - device_printf(dev, "no descriptors avail event = %lu\n", > + device_printf(dev, "no descriptors avail event = %llu\n", > txr->no_desc_avail); > - device_printf(dev, "TX(%d) IRQ Handled = %lu\n", txr->me, > + device_printf(dev, "TX(%d) IRQ Handled = %llu\n", txr->me, > txr->tx_irq); > - device_printf(dev, "TX(%d) Packets sent = %lu\n", txr->me, > + device_printf(dev, "TX(%d) Packets sent = %llu\n", txr->me, > txr->tx_packets); > } > > @@ -4219,11 +4219,11 @@ > device_printf(dev, "Queue(%d) rdh = %d, rdt = %d\n", i, > E1000_READ_REG(&adapter->hw, E1000_RDH(i)), > E1000_READ_REG(&adapter->hw, E1000_RDT(i))); > - device_printf(dev, "RX(%d) Packets received = %lu\n", rxr->me, > + device_printf(dev, "RX(%d) Packets received = %llu\n", rxr->me, > rxr->rx_packets); > - device_printf(dev, "RX(%d) Byte count = %lu\n", rxr->me, > + device_printf(dev, "RX(%d) Byte count = %llu\n", rxr->me, > rxr->rx_bytes); > - device_printf(dev, "RX(%d) IRQ Handled = %lu\n", rxr->me, > + device_printf(dev, "RX(%d) IRQ Handled = %llu\n", rxr->me, > rxr->rx_irq); > } > device_printf(dev, "LINK IRQ Handled = %u\n", adapter->link_irq); > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 19:35:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53625106566B for ; Sat, 1 Mar 2008 19:35:35 +0000 (UTC) (envelope-from thn@saeab.se) Received: from ture.saeab.se (ture.saeab.se [213.80.3.133]) by mx1.freebsd.org (Postfix) with ESMTP id C22A08FC14 for ; Sat, 1 Mar 2008 19:35:34 +0000 (UTC) (envelope-from thn@saeab.se) Received: from scatcat.thn.saeab.se (vpn-thn.int.saeab.se [10.0.4.43]) by ture.saeab.se (8.13.8/8.13.8) with ESMTP id m21JZUBj092417; Sat, 1 Mar 2008 20:35:30 +0100 (CET) (envelope-from thn@saeab.se) Received: from [10.1.0.1] (home [10.1.0.1]) by scatcat.thn.saeab.se (8.14.2/8.14.2) with ESMTP id m21JZUVr048595; Sat, 1 Mar 2008 20:35:30 +0100 (CET) (envelope-from thn@saeab.se) Message-ID: <47C9B080.4010206@saeab.se> Date: Sat, 01 Mar 2008 20:37:36 +0100 From: =?ISO-8859-1?Q?Thomas_Nystr=F6m?= Organization: Svensk Aktuell Elektronik AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ayhan Molla References: <795686.69488.qm@web30706.mail.mud.yahoo.com> In-Reply-To: <795686.69488.qm@web30706.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ture.saeab.se X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ture.saeab.se [10.0.1.133]); Sat, 01 Mar 2008 20:35:33 +0100 (CET) Cc: freebsd-current@freebsd.org Subject: Re: Broadcom Netlink BCM5906M X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 19:35:35 -0000 Ayhan Molla wrote: > Thank you very much, it works beautifully now. However I also needed to > add the follwing lines to the > /usr/src/sys/dev/mii/miidevs > file, I copied them from dragonflyBSD source. > > oui BROADCOM2 0x000af7 Broadcom2 Corporation > oui xxBROADCOM2 0x000af7 Broadcom Corporation > > model BROADCOM2 BCM5906 0x0004 BCM5906 10/100/1000baseTX PHY > model xxBROADCOM2 BCM5906 0x0004 BCM5906 10/100/1000baseTX PHY > > Thank you very much again. > Ah... Sorry, I forgot that file when I updated the patch. I have submitted a new patch for 7.0 to my original PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=118975 /Thomas -- --------------------------------------------------------------- Svensk Aktuell Elektronik AB Thomas Nyström Box 10 Phone: +46 73 069 69 30 S-191 21 Sollentuna Fax: +46 8 35 92 89 Sweden Email: thn@saeab.se --------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 21:39:28 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A0201065679; Sat, 1 Mar 2008 21:39:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B15428FC1F; Sat, 1 Mar 2008 21:39:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21LdRBa016001; Sat, 1 Mar 2008 16:39:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m21LdRsF027570; Sat, 1 Mar 2008 16:39:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D8FEB73039; Sat, 1 Mar 2008 16:39:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301213926.D8FEB73039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 16:39:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 21:39:28 -0000 TB --- 2008-03-01 21:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 21:15:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-03-01 21:15:00 - cleaning the object tree TB --- 2008-03-01 21:15:26 - cvsupping the source tree TB --- 2008-03-01 21:15:28 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-03-01 21:15:37 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 21:15:37 - cd /src TB --- 2008-03-01 21:15:37 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 21:15:40 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /obj/arm/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/sblock.c:36: /obj/arm/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " In file included from /obj/arm/src/tmp/usr/include/sys/buf.h:44, from /obj/arm/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/type.c:36: /obj/arm/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " mkdep: compile failed *** Error code 1 Stop in /src/lib/libufs. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 21:39:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 21:39:26 - ERROR: failed to build world TB --- 2008-03-01 21:39:26 - tinderbox aborted TB --- 1070.66 user 144.05 system 1466.15 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 21:42:10 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 490E9106566C; Sat, 1 Mar 2008 21:42:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 076478FC15; Sat, 1 Mar 2008 21:42:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21Lg9Sx016050; Sat, 1 Mar 2008 16:42:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21Lg9Wv031924; Sat, 1 Mar 2008 16:42:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6977E73039; Sat, 1 Mar 2008 16:42:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301214209.6977E73039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 16:42:09 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 21:42:10 -0000 TB --- 2008-03-01 21:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 21:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-03-01 21:15:00 - cleaning the object tree TB --- 2008-03-01 21:15:48 - cvsupping the source tree TB --- 2008-03-01 21:15:48 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-03-01 21:15:54 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 21:15:54 - cd /src TB --- 2008-03-01 21:15:54 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 21:15:55 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /obj/amd64/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/sblock.c:36: /obj/amd64/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " In file included from /obj/amd64/src/tmp/usr/include/sys/buf.h:44, from /obj/amd64/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/type.c:36: /obj/amd64/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " mkdep: compile failed *** Error code 1 Stop in /src/lib/libufs. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 21:42:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 21:42:09 - ERROR: failed to build world TB --- 2008-03-01 21:42:09 - tinderbox aborted TB --- 1164.92 user 153.21 system 1628.77 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 22:05:04 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0B9C1065670; Sat, 1 Mar 2008 22:05:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 84BF18FC12; Sat, 1 Mar 2008 22:05:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21M53gU016910; Sat, 1 Mar 2008 17:05:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21M53Pl052301; Sat, 1 Mar 2008 17:05:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A336173039; Sat, 1 Mar 2008 17:05:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301220503.A336173039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 17:05:03 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 22:05:05 -0000 TB --- 2008-03-01 21:39:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 21:39:26 - starting HEAD tinderbox run for i386/i386 TB --- 2008-03-01 21:39:26 - cleaning the object tree TB --- 2008-03-01 21:39:51 - cvsupping the source tree TB --- 2008-03-01 21:39:51 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-03-01 21:39:57 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 21:39:57 - cd /src TB --- 2008-03-01 21:39:57 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 21:39:58 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /obj/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/sblock.c:36: /obj/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " In file included from /obj/src/tmp/usr/include/sys/buf.h:44, from /obj/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/type.c:36: /obj/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " mkdep: compile failed *** Error code 1 Stop in /src/lib/libufs. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 22:05:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 22:05:03 - ERROR: failed to build world TB --- 2008-03-01 22:05:03 - tinderbox aborted TB --- 1106.75 user 142.84 system 1536.62 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 22:07:50 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 480ED1065671; Sat, 1 Mar 2008 22:07:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DFAB68FC17; Sat, 1 Mar 2008 22:07:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21M7ncp016992; Sat, 1 Mar 2008 17:07:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m21M7nXs001375; Sat, 1 Mar 2008 17:07:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4486B73039; Sat, 1 Mar 2008 17:07:49 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301220749.4486B73039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 17:07:49 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 22:07:50 -0000 TB --- 2008-03-01 21:42:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 21:42:09 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-03-01 21:42:09 - cleaning the object tree TB --- 2008-03-01 21:42:40 - cvsupping the source tree TB --- 2008-03-01 21:42:40 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-03-01 21:42:46 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 21:42:46 - cd /src TB --- 2008-03-01 21:42:46 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 21:42:48 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /obj/pc98/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/sblock.c:36: /obj/pc98/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " In file included from /obj/pc98/src/tmp/usr/include/sys/buf.h:44, from /obj/pc98/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/type.c:36: /obj/pc98/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " mkdep: compile failed *** Error code 1 Stop in /src/lib/libufs. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 22:07:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 22:07:49 - ERROR: failed to build world TB --- 2008-03-01 22:07:49 - tinderbox aborted TB --- 1109.13 user 147.04 system 1539.70 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 22:32:08 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BE1C106566C; Sat, 1 Mar 2008 22:32:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E54938FC25; Sat, 1 Mar 2008 22:32:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m21MW6cO060646; Sat, 1 Mar 2008 17:32:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21MW6s8084672; Sat, 1 Mar 2008 17:32:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B721573039; Sat, 1 Mar 2008 17:32:06 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301223206.B721573039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 17:32:06 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 22:32:08 -0000 TB --- 2008-03-01 22:05:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 22:05:03 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-03-01 22:05:03 - cleaning the object tree TB --- 2008-03-01 22:05:28 - cvsupping the source tree TB --- 2008-03-01 22:05:28 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-03-01 22:05:36 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 22:05:36 - cd /src TB --- 2008-03-01 22:05:36 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 22:05:37 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /obj/ia64/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/sblock.c:36: /obj/ia64/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " In file included from /obj/ia64/src/tmp/usr/include/sys/buf.h:44, from /obj/ia64/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/type.c:36: /obj/ia64/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " mkdep: compile failed *** Error code 1 Stop in /src/lib/libufs. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 22:32:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 22:32:06 - ERROR: failed to build world TB --- 2008-03-01 22:32:06 - tinderbox aborted TB --- 1192.94 user 146.45 system 1622.96 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 22:33:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6E4D1065679; Sat, 1 Mar 2008 22:33:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 44C718FC2C; Sat, 1 Mar 2008 22:33:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21MXjec017958; Sat, 1 Mar 2008 17:33:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21MXi0e086802; Sat, 1 Mar 2008 17:33:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D306C73039; Sat, 1 Mar 2008 17:33:44 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301223344.D306C73039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 17:33:44 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 22:33:53 -0000 TB --- 2008-03-01 22:07:49 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 22:07:49 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-03-01 22:07:49 - cleaning the object tree TB --- 2008-03-01 22:08:15 - cvsupping the source tree TB --- 2008-03-01 22:08:15 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-03-01 22:08:20 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 22:08:20 - cd /src TB --- 2008-03-01 22:08:20 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 22:08:22 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /obj/powerpc/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/sblock.c:36: /obj/powerpc/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " In file included from /obj/powerpc/src/tmp/usr/include/sys/buf.h:44, from /obj/powerpc/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/type.c:36: /obj/powerpc/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " mkdep: compile failed *** Error code 1 Stop in /src/lib/libufs. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 22:33:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 22:33:44 - ERROR: failed to build world TB --- 2008-03-01 22:33:44 - tinderbox aborted TB --- 1128.70 user 143.77 system 1555.30 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 22:50:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0E961065670 for ; Sat, 1 Mar 2008 22:50:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 6A96B8FC21 for ; Sat, 1 Mar 2008 22:50:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so3711900fgg.35 for ; Sat, 01 Mar 2008 14:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=DZPP8aRjw6rk1Dy2GNZhMW+oP5DPyWS4+NKtdvwt9YE=; b=nNeJE9IUmlqQpuZ/YBIoeoFl/vcVzaSOh0ueiRFK70rYKet/eNFW61ETmMVVn40LqlsjY4iqPs/1O6VnX0GmdvxL3Q7CWtpQaaiLmOTZiNfKRIcYTNZ238NYQyXDSDS1tx/J+Birv9Zz5WUSgasPfheR1FfKKamAPu/h82aLYF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=eqyW6drr3OedHopadqMWXQfJC54emSBSiwgUSSXLcQlHB/PjCCkV3gYuP+LpzjXViCc8UV1zZJJDpH9C68h8gImtA8+Boknr8IfS9PiZZM9XUlgKsDaCmoLCE+GZiQT3dgDprkpB66iH/KrvUTiPCPHfjChC2tPS4iJDnWTQz28= Received: by 10.82.188.15 with SMTP id l15mr14760347buf.15.1204411842694; Sat, 01 Mar 2008 14:50:42 -0800 (PST) Received: by 10.86.30.17 with HTTP; Sat, 1 Mar 2008 14:50:42 -0800 (PST) Message-ID: <3bbf2fe10803011450l2dadf71fp939759b8c023f1c5@mail.gmail.com> Date: Sat, 1 Mar 2008 23:50:42 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "FreeBSD Current" , freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: d7027d212304d661 Cc: Subject: [FOLLOW UP] lockmgr rewriting -- round 1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Mar 2008 22:50:45 -0000 Starting from the end of december, a serie of commits hit the tree in order to prepare current CVS stock kernel to be ready for an eventual newly implemented lockmgr locking primitive inclusion. The commits included various fixes to lockmgr(9) consumers, mostly the VFS locks and buffer cache objects locks. A detailed, tecnical, list of all modifies provided will be released soon, in order to maintain interested developers up-to-date, but it worths mentioning that for any commit modifying KPI, manpages and __FreeBSD_version bumping happened very closely. Due to the vfs and buffer cache involvement, modifies propagated to a lot of different filesystems, and some bugs show up: all the known one have been alredy fixed, with the exception of LORs reported by WITNESS, which hopefully will be analyzed and solved soon. The "consumers" are now in a good shape in order to accept the new, optimized, implementation, so we can consider an ideal "round 1" as closed. The new implementation should follow in a few of weeks, just in time to find any eventual bug and tweak exiting work in order to be in sync with the new KPI. If any user is experiencing any strange behaviour and he thinks VFS can be involved, please let me know as it is likely bugs can show up in this time-frame and it is better to solve them before the new implementation cames in. As last step let me thank people which deserved many thanks during this "round 1": - Konstantin Belousov submitted code and found time for reviewing almost all the relevant patches, as long as finding time for discussing approaches to follow - Kris Kennaway, Peter Holm, Matteo Riondato and Andrea Barberio tested, together, almost all patches before to be committed - Jeff Roberson, Stephan Uphoff and John Baldwin offered time for revisions and discussions - Yar Tikhiy, Doug Barton, Scot Hetzel and Bryan Venteicher found time to help in resolving specific filesystems bugs - Christian Brueffer and Gabor Kovesdan helped in updating manpages and docs/ bits Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 22:57:03 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F35D010656F8; Sat, 1 Mar 2008 22:57:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id AFD7D8FC20; Sat, 1 Mar 2008 22:57:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21Mv241018669; Sat, 1 Mar 2008 17:57:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m21Mv1dD039278; Sat, 1 Mar 2008 17:57:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 190CE73039; Sat, 1 Mar 2008 17:57:01 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301225701.190CE73039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 17:57:01 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6012/Wed Feb 27 13:48:06 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 22:57:03 -0000 TB --- 2008-03-01 22:32:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 22:32:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-03-01 22:32:06 - cleaning the object tree TB --- 2008-03-01 22:32:39 - cvsupping the source tree TB --- 2008-03-01 22:32:39 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-03-01 22:32:46 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 22:32:46 - cd /src TB --- 2008-03-01 22:32:46 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 22:32:47 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /obj/sparc64/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/sblock.c:36: /obj/sparc64/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " In file included from /obj/sparc64/src/tmp/usr/include/sys/buf.h:44, from /obj/sparc64/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/type.c:36: /obj/sparc64/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " mkdep: compile failed *** Error code 1 Stop in /src/lib/libufs. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 22:57:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 22:57:01 - ERROR: failed to build world TB --- 2008-03-01 22:57:01 - tinderbox aborted TB --- 1034.45 user 142.13 system 1494.16 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 1 22:57:43 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37B10106566C; Sat, 1 Mar 2008 22:57:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id D10628FC12; Sat, 1 Mar 2008 22:57:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m21MvgcJ061946; Sat, 1 Mar 2008 17:57:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m21MvfvK015942; Sat, 1 Mar 2008 17:57:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C27BB73039; Sat, 1 Mar 2008 17:57:41 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080301225741.C27BB73039@freebsd-current.sentex.ca> Date: Sat, 1 Mar 2008 17:57:41 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 22:57:43 -0000 TB --- 2008-03-01 22:33:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-01 22:33:45 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-03-01 22:33:45 - cleaning the object tree TB --- 2008-03-01 22:34:17 - cvsupping the source tree TB --- 2008-03-01 22:34:17 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-03-01 22:34:22 - building world (CFLAGS=-O -pipe) TB --- 2008-03-01 22:34:22 - cd /src TB --- 2008-03-01 22:34:22 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 1 22:34:23 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /obj/sun4v/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/sblock.c:36: /obj/sun4v/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " In file included from /obj/sun4v/src/tmp/usr/include/sys/buf.h:44, from /obj/sun4v/src/tmp/usr/include/ufs/ufs/ufsmount.h:36, from /src/lib/libufs/type.c:36: /obj/sun4v/src/tmp/usr/include/sys/lockmgr.h:159:2: error: #error "LOCK_FILE not defined, include before " mkdep: compile failed *** Error code 1 Stop in /src/lib/libufs. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-01 22:57:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-01 22:57:41 - ERROR: failed to build world TB --- 2008-03-01 22:57:41 - tinderbox aborted TB --- 1032.22 user 142.70 system 1436.79 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full