From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 02:52:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D707228 for ; Mon, 29 Oct 2012 02:52:52 +0000 (UTC) (envelope-from chinalightsourcea@aliyun.com) Received: from smtpcm9-317.freemail.mail.aliyun.com (smtpcm9-317.freemail.mail.aliyun.com [110.75.46.17]) by mx1.freebsd.org (Postfix) with ESMTP id 821678FC14 for ; Mon, 29 Oct 2012 02:52:51 +0000 (UTC) Received: from WS-web by localhost(127.0.0.1) at Mon, 29 Oct 2012 10:36:06 +0800 Date: Mon, 29 Oct 2012 10:36:03 +0800 From: To: Message-ID: <50f987fd-e1d5-4a14-bfec-48de80537601@aliyun.com> Subject: =?UTF-8?B?TEVEIHJvcGUgbGlnaHRzIA==?= X-Priority: 3 X-Mailer: Alimail-Mailagent MIME-Version: 1.0 X-Priority: 3 X-Mailer: Alimail-Mailagent revision 494994 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 02:52:52 -0000 =0aHello,=0a=c2=a0=0aWe are glad you are on the market for led lightings.=0a=c2= =a0=0aLight Source Industrial Limited =c2=a0here,main products are LED spots L= amp, and Bulbs,Tube Light, LED panel light, LED tree light, LED Christmas ligh= ts, and LED down light,LED acrylic motif lights, =c2=a0Please visit our compan= y website: www.cn-lightsource.com; if any item you are interested in, please c= ontact us at any time. =0a=c2=a0=0aI look forward to hearing from you! =0aBest= regards, =0aAlison zhang=0aLight Source Industrial Limited=c2=a0=0aTel: 0086 = 7525536816=0a=c2=a0=c2=a0=c2=a0=c2=a0=c2=a0 0086 75533696626=0aMobile: 0086153= 47451788=0aEmail: alisonzhangcn@163.com=0aHotmail: chinalightsource@hotmail.co= m=0awww.cn-lightsource.com=0askype: alisonzhangcn1=0a=c2=a0=0a=c2=a0=0a=c2=a0=0a= =c2=a0=0a=c2=a0=0a=c2=a0=0a=c2=a0=0a=c2=a0=0a=c2=a0=0a=0a=c2=a0 From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 04:48:32 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FCA4C0A; Mon, 29 Oct 2012 04:48:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id BFC2F8FC0C; Mon, 29 Oct 2012 04:48:31 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T4mUfw093820; Mon, 29 Oct 2012 04:48:30 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T4mU8r093816; Mon, 29 Oct 2012 04:48:30 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 04:48:30 GMT Message-Id: <201210290448.q9T4mU8r093816@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 04:48:32 -0000 TB --- 2012-10-29 03:58:58 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 03:58:58 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 03:58:58 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2012-10-29 03:58:58 - cleaning the object tree TB --- 2012-10-29 03:58:58 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 03:58:58 - cd /tinderbox/RELENG_8/powerpc/powerpc TB --- 2012-10-29 03:58:58 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 03:59:05 - /usr/local/bin/svn update /src TB --- 2012-10-29 03:59:11 - At svn revision 242284 TB --- 2012-10-29 03:59:12 - building world TB --- 2012-10-29 03:59:12 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 03:59:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 03:59:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 03:59:12 - SRCCONF=/dev/null TB --- 2012-10-29 03:59:12 - TARGET=powerpc TB --- 2012-10-29 03:59:12 - TARGET_ARCH=powerpc TB --- 2012-10-29 03:59:12 - TZ=UTC TB --- 2012-10-29 03:59:12 - __MAKE_CONF=/dev/null TB --- 2012-10-29 03:59:12 - cd /src TB --- 2012-10-29 03:59:12 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 03:59:13 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 29 04:43:41 UTC 2012 TB --- 2012-10-29 04:43:41 - generating LINT kernel config TB --- 2012-10-29 04:43:41 - cd /src/sys/powerpc/conf TB --- 2012-10-29 04:43:41 - /usr/bin/make -B LINT TB --- 2012-10-29 04:43:41 - cd /src/sys/powerpc/conf TB --- 2012-10-29 04:43:41 - /usr/sbin/config -m LINT TB --- 2012-10-29 04:43:41 - building LINT kernel TB --- 2012-10-29 04:43:41 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 04:43:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 04:43:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 04:43:41 - SRCCONF=/dev/null TB --- 2012-10-29 04:43:41 - TARGET=powerpc TB --- 2012-10-29 04:43:41 - TARGET_ARCH=powerpc TB --- 2012-10-29 04:43:41 - TZ=UTC TB --- 2012-10-29 04:43:41 - __MAKE_CONF=/dev/null TB --- 2012-10-29 04:43:41 - cd /src TB --- 2012-10-29 04:43:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 29 04:43:41 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/misc/ufm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/misc/udbp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/input/uep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/input/uhid.c /src/sys/dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 04:48:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 04:48:30 - ERROR: failed to build LINT kernel TB --- 2012-10-29 04:48:30 - 2466.05 user 428.63 system 2972.78 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 04:52:35 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD5D4307; Mon, 29 Oct 2012 04:52:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 77BBF8FC19; Mon, 29 Oct 2012 04:52:35 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T4qZ0q017422; Mon, 29 Oct 2012 04:52:35 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T4qZ57017421; Mon, 29 Oct 2012 04:52:35 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 04:52:35 GMT Message-Id: <201210290452.q9T4qZ57017421@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 04:52:35 -0000 TB --- 2012-10-29 04:06:31 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 04:06:31 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 04:06:31 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2012-10-29 04:06:31 - cleaning the object tree TB --- 2012-10-29 04:06:31 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 04:06:31 - cd /tinderbox/RELENG_8/sparc64/sparc64 TB --- 2012-10-29 04:06:31 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 04:06:43 - /usr/local/bin/svn update /src TB --- 2012-10-29 04:06:48 - At svn revision 242284 TB --- 2012-10-29 04:06:49 - building world TB --- 2012-10-29 04:06:49 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 04:06:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 04:06:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 04:06:49 - SRCCONF=/dev/null TB --- 2012-10-29 04:06:49 - TARGET=sparc64 TB --- 2012-10-29 04:06:49 - TARGET_ARCH=sparc64 TB --- 2012-10-29 04:06:49 - TZ=UTC TB --- 2012-10-29 04:06:49 - __MAKE_CONF=/dev/null TB --- 2012-10-29 04:06:49 - cd /src TB --- 2012-10-29 04:06:49 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 04:06:50 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 29 04:47:59 UTC 2012 TB --- 2012-10-29 04:47:59 - generating LINT kernel config TB --- 2012-10-29 04:47:59 - cd /src/sys/sparc64/conf TB --- 2012-10-29 04:47:59 - /usr/bin/make -B LINT TB --- 2012-10-29 04:47:59 - cd /src/sys/sparc64/conf TB --- 2012-10-29 04:47:59 - /usr/sbin/config -m LINT TB --- 2012-10-29 04:47:59 - building LINT kernel TB --- 2012-10-29 04:47:59 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 04:47:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 04:47:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 04:47:59 - SRCCONF=/dev/null TB --- 2012-10-29 04:47:59 - TARGET=sparc64 TB --- 2012-10-29 04:47:59 - TARGET_ARCH=sparc64 TB --- 2012-10-29 04:47:59 - TZ=UTC TB --- 2012-10-29 04:47:59 - __MAKE_CONF=/dev/null TB --- 2012-10-29 04:47:59 - cd /src TB --- 2012-10-29 04:47:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 29 04:47:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/misc/ufm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/misc/udbp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/input/uep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/input/uhid.c /src/sys/dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 04:52:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 04:52:35 - ERROR: failed to build LINT kernel TB --- 2012-10-29 04:52:35 - 2313.70 user 409.69 system 2763.39 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 07:29:07 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D70E81A7; Mon, 29 Oct 2012 07:29:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDF08FC0A; Mon, 29 Oct 2012 07:29:07 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T7T6l9008660; Mon, 29 Oct 2012 07:29:06 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T7T67c008651; Mon, 29 Oct 2012 07:29:06 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 07:29:06 GMT Message-Id: <201210290729.q9T7T67c008651@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 07:29:08 -0000 TB --- 2012-10-29 06:36:49 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 06:36:49 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 06:36:49 - starting RELENG_8 tinderbox run for arm/arm TB --- 2012-10-29 06:36:49 - cleaning the object tree TB --- 2012-10-29 06:36:49 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 06:36:49 - cd /tinderbox/RELENG_8/arm/arm TB --- 2012-10-29 06:36:49 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 06:36:59 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:37:05 - At svn revision 242301 TB --- 2012-10-29 06:37:06 - building world TB --- 2012-10-29 06:37:06 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 06:37:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 06:37:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 06:37:06 - SRCCONF=/dev/null TB --- 2012-10-29 06:37:06 - TARGET=arm TB --- 2012-10-29 06:37:06 - TARGET_ARCH=arm TB --- 2012-10-29 06:37:06 - TZ=UTC TB --- 2012-10-29 06:37:06 - __MAKE_CONF=/dev/null TB --- 2012-10-29 06:37:06 - cd /src TB --- 2012-10-29 06:37:06 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 06:37:07 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 29 07:12:18 UTC 2012 TB --- 2012-10-29 07:12:18 - cd /src/sys/arm/conf TB --- 2012-10-29 07:12:18 - /usr/sbin/config -m AVILA TB --- 2012-10-29 07:12:18 - building AVILA kernel TB --- 2012-10-29 07:12:18 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:12:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:12:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:12:18 - SRCCONF=/dev/null TB --- 2012-10-29 07:12:18 - TARGET=arm TB --- 2012-10-29 07:12:18 - TARGET_ARCH=arm TB --- 2012-10-29 07:12:18 - TZ=UTC TB --- 2012-10-29 07:12:18 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:12:18 - cd /src TB --- 2012-10-29 07:12:18 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Mon Oct 29 07:12:18 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AVILA completed on Mon Oct 29 07:14:16 UTC 2012 TB --- 2012-10-29 07:14:16 - cd /src/sys/arm/conf TB --- 2012-10-29 07:14:16 - /usr/sbin/config -m BWCT TB --- 2012-10-29 07:14:16 - building BWCT kernel TB --- 2012-10-29 07:14:16 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:14:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:14:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:14:16 - SRCCONF=/dev/null TB --- 2012-10-29 07:14:16 - TARGET=arm TB --- 2012-10-29 07:14:16 - TARGET_ARCH=arm TB --- 2012-10-29 07:14:16 - TZ=UTC TB --- 2012-10-29 07:14:16 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:14:16 - cd /src TB --- 2012-10-29 07:14:16 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Mon Oct 29 07:14:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Mon Oct 29 07:15:42 UTC 2012 TB --- 2012-10-29 07:15:42 - cd /src/sys/arm/conf TB --- 2012-10-29 07:15:42 - /usr/sbin/config -m CAMBRIA TB --- 2012-10-29 07:15:42 - building CAMBRIA kernel TB --- 2012-10-29 07:15:42 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:15:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:15:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:15:42 - SRCCONF=/dev/null TB --- 2012-10-29 07:15:42 - TARGET=arm TB --- 2012-10-29 07:15:42 - TARGET_ARCH=arm TB --- 2012-10-29 07:15:42 - TZ=UTC TB --- 2012-10-29 07:15:42 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:15:42 - cd /src TB --- 2012-10-29 07:15:42 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Mon Oct 29 07:15:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CAMBRIA completed on Mon Oct 29 07:17:35 UTC 2012 TB --- 2012-10-29 07:17:35 - cd /src/sys/arm/conf TB --- 2012-10-29 07:17:35 - /usr/sbin/config -m CRB TB --- 2012-10-29 07:17:35 - building CRB kernel TB --- 2012-10-29 07:17:35 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:17:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:17:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:17:35 - SRCCONF=/dev/null TB --- 2012-10-29 07:17:35 - TARGET=arm TB --- 2012-10-29 07:17:35 - TARGET_ARCH=arm TB --- 2012-10-29 07:17:35 - TZ=UTC TB --- 2012-10-29 07:17:35 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:17:35 - cd /src TB --- 2012-10-29 07:17:35 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Mon Oct 29 07:17:35 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CRB completed on Mon Oct 29 07:19:46 UTC 2012 TB --- 2012-10-29 07:19:46 - cd /src/sys/arm/conf TB --- 2012-10-29 07:19:46 - /usr/sbin/config -m DB-78XXX TB --- 2012-10-29 07:19:46 - building DB-78XXX kernel TB --- 2012-10-29 07:19:46 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:19:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:19:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:19:46 - SRCCONF=/dev/null TB --- 2012-10-29 07:19:46 - TARGET=arm TB --- 2012-10-29 07:19:46 - TARGET_ARCH=arm TB --- 2012-10-29 07:19:46 - TZ=UTC TB --- 2012-10-29 07:19:46 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:19:46 - cd /src TB --- 2012-10-29 07:19:46 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Mon Oct 29 07:19:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Mon Oct 29 07:21:36 UTC 2012 TB --- 2012-10-29 07:21:36 - cd /src/sys/arm/conf TB --- 2012-10-29 07:21:36 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-10-29 07:21:36 - building DB-88F5XXX kernel TB --- 2012-10-29 07:21:36 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:21:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:21:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:21:36 - SRCCONF=/dev/null TB --- 2012-10-29 07:21:36 - TARGET=arm TB --- 2012-10-29 07:21:36 - TARGET_ARCH=arm TB --- 2012-10-29 07:21:36 - TZ=UTC TB --- 2012-10-29 07:21:36 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:21:36 - cd /src TB --- 2012-10-29 07:21:36 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Mon Oct 29 07:21:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Mon Oct 29 07:23:25 UTC 2012 TB --- 2012-10-29 07:23:25 - cd /src/sys/arm/conf TB --- 2012-10-29 07:23:25 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-10-29 07:23:25 - building DB-88F6XXX kernel TB --- 2012-10-29 07:23:25 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:23:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:23:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:23:25 - SRCCONF=/dev/null TB --- 2012-10-29 07:23:25 - TARGET=arm TB --- 2012-10-29 07:23:25 - TARGET_ARCH=arm TB --- 2012-10-29 07:23:25 - TZ=UTC TB --- 2012-10-29 07:23:25 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:23:25 - cd /src TB --- 2012-10-29 07:23:25 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Mon Oct 29 07:23:25 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Mon Oct 29 07:25:13 UTC 2012 TB --- 2012-10-29 07:25:13 - cd /src/sys/arm/conf TB --- 2012-10-29 07:25:13 - /usr/sbin/config -m EP80219 TB --- 2012-10-29 07:25:13 - building EP80219 kernel TB --- 2012-10-29 07:25:13 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:25:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:25:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:25:13 - SRCCONF=/dev/null TB --- 2012-10-29 07:25:13 - TARGET=arm TB --- 2012-10-29 07:25:13 - TARGET_ARCH=arm TB --- 2012-10-29 07:25:13 - TZ=UTC TB --- 2012-10-29 07:25:13 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:25:13 - cd /src TB --- 2012-10-29 07:25:13 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Mon Oct 29 07:25:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EP80219 completed on Mon Oct 29 07:27:03 UTC 2012 TB --- 2012-10-29 07:27:03 - cd /src/sys/arm/conf TB --- 2012-10-29 07:27:03 - /usr/sbin/config -m GUMSTIX TB --- 2012-10-29 07:27:03 - building GUMSTIX kernel TB --- 2012-10-29 07:27:03 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:27:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:27:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:27:03 - SRCCONF=/dev/null TB --- 2012-10-29 07:27:03 - TARGET=arm TB --- 2012-10-29 07:27:03 - TARGET_ARCH=arm TB --- 2012-10-29 07:27:03 - TZ=UTC TB --- 2012-10-29 07:27:03 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:27:03 - cd /src TB --- 2012-10-29 07:27:03 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Mon Oct 29 07:27:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GUMSTIX completed on Mon Oct 29 07:28:32 UTC 2012 TB --- 2012-10-29 07:28:32 - cd /src/sys/arm/conf TB --- 2012-10-29 07:28:32 - /usr/sbin/config -m HL200 TB --- 2012-10-29 07:28:32 - building HL200 kernel TB --- 2012-10-29 07:28:32 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:28:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:28:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:28:32 - SRCCONF=/dev/null TB --- 2012-10-29 07:28:32 - TARGET=arm TB --- 2012-10-29 07:28:32 - TARGET_ARCH=arm TB --- 2012-10-29 07:28:32 - TZ=UTC TB --- 2012-10-29 07:28:32 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:28:32 - cd /src TB --- 2012-10-29 07:28:32 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Mon Oct 29 07:28:32 UTC 2012 >>> 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 -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/usb/serial/uvisor.c cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/usb/serial/uvscom.c cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/usb/serial/usb_serial.c cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/usb/input/uhid.c /src/sys/dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/arm/src/sys/HL200. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 07:29:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 07:29:06 - ERROR: failed to build HL200 kernel TB --- 2012-10-29 07:29:06 - 2493.19 user 533.52 system 3137.57 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 07:29:58 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E41CB2E6; Mon, 29 Oct 2012 07:29:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 97F858FC0A; Mon, 29 Oct 2012 07:29:58 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T7TwCY018761; Mon, 29 Oct 2012 07:29:58 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T7TwCO018737; Mon, 29 Oct 2012 07:29:58 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 07:29:58 GMT Message-Id: <201210290729.q9T7TwCO018737@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 07:29:59 -0000 TB --- 2012-10-29 06:36:49 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 06:36:49 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 06:36:49 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-10-29 06:36:49 - cleaning the object tree TB --- 2012-10-29 06:36:49 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 06:36:49 - cd /tinderbox/RELENG_8/mips/mips TB --- 2012-10-29 06:36:49 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 06:36:59 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:42:53 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-10-29 06:42:53 - WARNING: sleeping 30 s and retrying... TB --- 2012-10-29 06:43:23 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:43:29 - At svn revision 242301 TB --- 2012-10-29 06:43:30 - building world TB --- 2012-10-29 06:43:30 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 06:43:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 06:43:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 06:43:30 - SRCCONF=/dev/null TB --- 2012-10-29 06:43:30 - TARGET=mips TB --- 2012-10-29 06:43:30 - TARGET_ARCH=mips TB --- 2012-10-29 06:43:30 - TZ=UTC TB --- 2012-10-29 06:43:30 - __MAKE_CONF=/dev/null TB --- 2012-10-29 06:43:30 - cd /src TB --- 2012-10-29 06:43:30 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 06:43:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 29 07:20:31 UTC 2012 TB --- 2012-10-29 07:20:31 - cd /src/sys/mips/conf TB --- 2012-10-29 07:20:31 - /usr/sbin/config -m ADM5120 TB --- 2012-10-29 07:20:31 - building ADM5120 kernel TB --- 2012-10-29 07:20:31 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:20:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:20:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:20:31 - SRCCONF=/dev/null TB --- 2012-10-29 07:20:31 - TARGET=mips TB --- 2012-10-29 07:20:31 - TARGET_ARCH=mips TB --- 2012-10-29 07:20:31 - TZ=UTC TB --- 2012-10-29 07:20:31 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:20:31 - cd /src TB --- 2012-10-29 07:20:31 - /usr/bin/make -B buildkernel KERNCONF=ADM5120 >>> Kernel build for ADM5120 started on Mon Oct 29 07:20:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ADM5120 completed on Mon Oct 29 07:21:46 UTC 2012 TB --- 2012-10-29 07:21:46 - cd /src/sys/mips/conf TB --- 2012-10-29 07:21:46 - /usr/sbin/config -m ALCHEMY TB --- 2012-10-29 07:21:46 - building ALCHEMY kernel TB --- 2012-10-29 07:21:46 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:21:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:21:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:21:46 - SRCCONF=/dev/null TB --- 2012-10-29 07:21:46 - TARGET=mips TB --- 2012-10-29 07:21:46 - TARGET_ARCH=mips TB --- 2012-10-29 07:21:46 - TZ=UTC TB --- 2012-10-29 07:21:46 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:21:46 - cd /src TB --- 2012-10-29 07:21:46 - /usr/bin/make -B buildkernel KERNCONF=ALCHEMY >>> Kernel build for ALCHEMY started on Mon Oct 29 07:21:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ALCHEMY completed on Mon Oct 29 07:22:59 UTC 2012 TB --- 2012-10-29 07:22:59 - cd /src/sys/mips/conf TB --- 2012-10-29 07:22:59 - /usr/sbin/config -m AR71XX TB --- 2012-10-29 07:22:59 - building AR71XX kernel TB --- 2012-10-29 07:22:59 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:22:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:22:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:22:59 - SRCCONF=/dev/null TB --- 2012-10-29 07:22:59 - TARGET=mips TB --- 2012-10-29 07:22:59 - TARGET_ARCH=mips TB --- 2012-10-29 07:22:59 - TZ=UTC TB --- 2012-10-29 07:22:59 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:22:59 - cd /src TB --- 2012-10-29 07:22:59 - /usr/bin/make -B buildkernel KERNCONF=AR71XX >>> Kernel build for AR71XX started on Mon Oct 29 07:22:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] objcopy --only-keep-debug atp.ko.debug atp.ko.symbols objcopy --strip-debug --add-gnu-debuglink=atp.ko.symbols atp.ko.debug atp.ko ===> usb/uhid (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips/src/sys/AR71XX/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips/src/sys/AR71XX -msoft-float -mno-dsp -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb/uhid/../../../dev/usb/input/uhid.c /src/sys/modules/usb/uhid/../../../dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/modules/usb/uhid/../../../dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/modules/usb/uhid/../../../dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/modules/usb/uhid/../../../dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/usb/uhid. *** Error code 1 Stop in /src/sys/modules/usb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/mips/src/sys/AR71XX. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 07:29:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 07:29:58 - ERROR: failed to build AR71XX kernel TB --- 2012-10-29 07:29:58 - 2133.29 user 466.29 system 3188.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 07:36:02 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB5FB470; Mon, 29 Oct 2012 07:36:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 62EBB8FC08; Mon, 29 Oct 2012 07:36:02 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T7a1RE039664; Mon, 29 Oct 2012 07:36:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T7a1ZB039663; Mon, 29 Oct 2012 07:36:01 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 07:36:01 GMT Message-Id: <201210290736.q9T7a1ZB039663@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 07:36:02 -0000 TB --- 2012-10-29 06:36:49 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 06:36:49 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 06:36:49 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2012-10-29 06:36:49 - cleaning the object tree TB --- 2012-10-29 06:36:49 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 06:36:49 - cd /tinderbox/RELENG_8/i386/pc98 TB --- 2012-10-29 06:36:49 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 06:36:59 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:42:52 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-10-29 06:42:52 - WARNING: sleeping 30 s and retrying... TB --- 2012-10-29 06:43:22 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:43:28 - At svn revision 242301 TB --- 2012-10-29 06:43:29 - building world TB --- 2012-10-29 06:43:29 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 06:43:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 06:43:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 06:43:29 - SRCCONF=/dev/null TB --- 2012-10-29 06:43:29 - TARGET=pc98 TB --- 2012-10-29 06:43:29 - TARGET_ARCH=i386 TB --- 2012-10-29 06:43:29 - TZ=UTC TB --- 2012-10-29 06:43:29 - __MAKE_CONF=/dev/null TB --- 2012-10-29 06:43:29 - cd /src TB --- 2012-10-29 06:43:29 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 06:43:29 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 29 07:30:04 UTC 2012 TB --- 2012-10-29 07:30:04 - generating LINT kernel config TB --- 2012-10-29 07:30:04 - cd /src/sys/pc98/conf TB --- 2012-10-29 07:30:04 - /usr/bin/make -B LINT TB --- 2012-10-29 07:30:04 - cd /src/sys/pc98/conf TB --- 2012-10-29 07:30:04 - /usr/sbin/config -m LINT TB --- 2012-10-29 07:30:04 - building LINT kernel TB --- 2012-10-29 07:30:04 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:30:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:30:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:30:04 - SRCCONF=/dev/null TB --- 2012-10-29 07:30:04 - TARGET=pc98 TB --- 2012-10-29 07:30:04 - TARGET_ARCH=i386 TB --- 2012-10-29 07:30:04 - TZ=UTC TB --- 2012-10-29 07:30:04 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:30:04 - cd /src TB --- 2012-10-29 07:30:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 29 07:30:04 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/misc/ufm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/misc/udbp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/input/uep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/input/uhid.c /src/sys/dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 07:36:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 07:36:01 - ERROR: failed to build LINT kernel TB --- 2012-10-29 07:36:01 - 2464.77 user 490.17 system 3552.73 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 07:37:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB3FB5A7; Mon, 29 Oct 2012 07:37:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id A4B118FC08; Mon, 29 Oct 2012 07:37:55 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T7btVg077434; Mon, 29 Oct 2012 07:37:55 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T7bt7G077433; Mon, 29 Oct 2012 07:37:55 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 07:37:55 GMT Message-Id: <201210290737.q9T7bt7G077433@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 07:37:56 -0000 TB --- 2012-10-29 06:36:49 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 06:36:49 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 06:36:49 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2012-10-29 06:36:49 - cleaning the object tree TB --- 2012-10-29 06:36:49 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 06:36:49 - cd /tinderbox/RELENG_8/i386/i386 TB --- 2012-10-29 06:36:49 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 06:36:59 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:42:55 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-10-29 06:42:55 - WARNING: sleeping 30 s and retrying... TB --- 2012-10-29 06:43:25 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:43:31 - At svn revision 242301 TB --- 2012-10-29 06:43:32 - building world TB --- 2012-10-29 06:43:32 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 06:43:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 06:43:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 06:43:32 - SRCCONF=/dev/null TB --- 2012-10-29 06:43:32 - TARGET=i386 TB --- 2012-10-29 06:43:32 - TARGET_ARCH=i386 TB --- 2012-10-29 06:43:32 - TZ=UTC TB --- 2012-10-29 06:43:32 - __MAKE_CONF=/dev/null TB --- 2012-10-29 06:43:32 - cd /src TB --- 2012-10-29 06:43:32 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 06:43:32 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 29 07:30:34 UTC 2012 TB --- 2012-10-29 07:30:34 - generating LINT kernel config TB --- 2012-10-29 07:30:34 - cd /src/sys/i386/conf TB --- 2012-10-29 07:30:34 - /usr/bin/make -B LINT TB --- 2012-10-29 07:30:34 - cd /src/sys/i386/conf TB --- 2012-10-29 07:30:34 - /usr/sbin/config -m LINT TB --- 2012-10-29 07:30:34 - building LINT kernel TB --- 2012-10-29 07:30:34 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:30:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:30:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:30:34 - SRCCONF=/dev/null TB --- 2012-10-29 07:30:34 - TARGET=i386 TB --- 2012-10-29 07:30:34 - TARGET_ARCH=i386 TB --- 2012-10-29 07:30:34 - TZ=UTC TB --- 2012-10-29 07:30:34 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:30:34 - cd /src TB --- 2012-10-29 07:30:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 29 07:30:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/misc/ufm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/misc/udbp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/input/uep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/input/uhid.c /src/sys/dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 07:37:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 07:37:55 - ERROR: failed to build LINT kernel TB --- 2012-10-29 07:37:55 - 2553.05 user 501.81 system 3665.98 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 07:50:04 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 120FC827; Mon, 29 Oct 2012 07:50:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id BCB958FC0A; Mon, 29 Oct 2012 07:50:03 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T7o39N024654; Mon, 29 Oct 2012 07:50:03 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T7o3oM024651; Mon, 29 Oct 2012 07:50:03 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 07:50:03 GMT Message-Id: <201210290750.q9T7o3oM024651@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 07:50:04 -0000 TB --- 2012-10-29 06:36:49 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 06:36:49 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 06:36:49 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2012-10-29 06:36:49 - cleaning the object tree TB --- 2012-10-29 06:36:49 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 06:36:49 - cd /tinderbox/RELENG_8/ia64/ia64 TB --- 2012-10-29 06:36:49 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 06:36:59 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:42:55 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-10-29 06:42:55 - WARNING: sleeping 30 s and retrying... TB --- 2012-10-29 06:43:25 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:43:31 - At svn revision 242301 TB --- 2012-10-29 06:43:32 - building world TB --- 2012-10-29 06:43:32 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 06:43:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 06:43:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 06:43:32 - SRCCONF=/dev/null TB --- 2012-10-29 06:43:32 - TARGET=ia64 TB --- 2012-10-29 06:43:32 - TARGET_ARCH=ia64 TB --- 2012-10-29 06:43:32 - TZ=UTC TB --- 2012-10-29 06:43:32 - __MAKE_CONF=/dev/null TB --- 2012-10-29 06:43:32 - cd /src TB --- 2012-10-29 06:43:32 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 06:43:32 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 29 07:43:10 UTC 2012 TB --- 2012-10-29 07:43:10 - generating LINT kernel config TB --- 2012-10-29 07:43:10 - cd /src/sys/ia64/conf TB --- 2012-10-29 07:43:10 - /usr/bin/make -B LINT TB --- 2012-10-29 07:43:10 - cd /src/sys/ia64/conf TB --- 2012-10-29 07:43:10 - /usr/sbin/config -m LINT TB --- 2012-10-29 07:43:10 - building LINT kernel TB --- 2012-10-29 07:43:10 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:43:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:43:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:43:10 - SRCCONF=/dev/null TB --- 2012-10-29 07:43:10 - TARGET=ia64 TB --- 2012-10-29 07:43:10 - TARGET_ARCH=ia64 TB --- 2012-10-29 07:43:10 - TZ=UTC TB --- 2012-10-29 07:43:10 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:43:10 - cd /src TB --- 2012-10-29 07:43:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 29 07:43:10 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/usb/misc/ufm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/usb/misc/udbp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/usb/input/uep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/usb/input/uhid.c /src/sys/dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 07:50:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 07:50:03 - ERROR: failed to build LINT kernel TB --- 2012-10-29 07:50:03 - 3333.66 user 518.05 system 4394.09 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 07:56:21 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7219FB70; Mon, 29 Oct 2012 07:56:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 2411E8FC12; Mon, 29 Oct 2012 07:56:21 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T7uK8J013380; Mon, 29 Oct 2012 07:56:20 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T7uKRH013379; Mon, 29 Oct 2012 07:56:20 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 07:56:20 GMT Message-Id: <201210290756.q9T7uKRH013379@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 07:56:21 -0000 TB --- 2012-10-29 06:36:49 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 06:36:49 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 06:36:49 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2012-10-29 06:36:49 - cleaning the object tree TB --- 2012-10-29 06:36:49 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 06:36:49 - cd /tinderbox/RELENG_8/amd64/amd64 TB --- 2012-10-29 06:36:49 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 06:36:59 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:42:53 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-10-29 06:42:53 - WARNING: sleeping 30 s and retrying... TB --- 2012-10-29 06:43:23 - /usr/local/bin/svn update /src TB --- 2012-10-29 06:43:29 - At svn revision 242301 TB --- 2012-10-29 06:43:30 - building world TB --- 2012-10-29 06:43:30 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 06:43:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 06:43:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 06:43:30 - SRCCONF=/dev/null TB --- 2012-10-29 06:43:30 - TARGET=amd64 TB --- 2012-10-29 06:43:30 - TARGET_ARCH=amd64 TB --- 2012-10-29 06:43:30 - TZ=UTC TB --- 2012-10-29 06:43:30 - __MAKE_CONF=/dev/null TB --- 2012-10-29 06:43:30 - cd /src TB --- 2012-10-29 06:43:30 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 06:43:30 UTC 2012 >>> 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 Mon Oct 29 07:50:31 UTC 2012 TB --- 2012-10-29 07:50:31 - generating LINT kernel config TB --- 2012-10-29 07:50:31 - cd /src/sys/amd64/conf TB --- 2012-10-29 07:50:31 - /usr/bin/make -B LINT TB --- 2012-10-29 07:50:31 - cd /src/sys/amd64/conf TB --- 2012-10-29 07:50:31 - /usr/sbin/config -m LINT TB --- 2012-10-29 07:50:31 - building LINT kernel TB --- 2012-10-29 07:50:31 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:50:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:50:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:50:31 - SRCCONF=/dev/null TB --- 2012-10-29 07:50:31 - TARGET=amd64 TB --- 2012-10-29 07:50:31 - TARGET_ARCH=amd64 TB --- 2012-10-29 07:50:31 - TZ=UTC TB --- 2012-10-29 07:50:31 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:50:31 - cd /src TB --- 2012-10-29 07:50:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 29 07:50:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/misc/ufm.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/misc/udbp.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/input/uep.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/input/uhid.c /src/sys/dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 07:56:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 07:56:20 - ERROR: failed to build LINT kernel TB --- 2012-10-29 07:56:20 - 3461.20 user 699.04 system 4771.47 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 08:13:21 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EB3926D; Mon, 29 Oct 2012 08:13:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 36A078FC16; Mon, 29 Oct 2012 08:13:21 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T8DKQM017171; Mon, 29 Oct 2012 08:13:20 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T8DKmw017170; Mon, 29 Oct 2012 08:13:20 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 08:13:20 GMT Message-Id: <201210290813.q9T8DKmw017170@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 08:13:21 -0000 TB --- 2012-10-29 07:29:58 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 07:29:58 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 07:29:58 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2012-10-29 07:29:58 - cleaning the object tree TB --- 2012-10-29 07:30:16 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 07:30:16 - cd /tinderbox/RELENG_8/sparc64/sparc64 TB --- 2012-10-29 07:30:16 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 07:30:23 - /usr/local/bin/svn update /src TB --- 2012-10-29 07:30:27 - At svn revision 242302 TB --- 2012-10-29 07:30:28 - building world TB --- 2012-10-29 07:30:28 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:30:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:30:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:30:28 - SRCCONF=/dev/null TB --- 2012-10-29 07:30:28 - TARGET=sparc64 TB --- 2012-10-29 07:30:28 - TARGET_ARCH=sparc64 TB --- 2012-10-29 07:30:28 - TZ=UTC TB --- 2012-10-29 07:30:28 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:30:28 - cd /src TB --- 2012-10-29 07:30:28 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 07:30:29 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 29 08:08:54 UTC 2012 TB --- 2012-10-29 08:08:54 - generating LINT kernel config TB --- 2012-10-29 08:08:54 - cd /src/sys/sparc64/conf TB --- 2012-10-29 08:08:54 - /usr/bin/make -B LINT TB --- 2012-10-29 08:08:54 - cd /src/sys/sparc64/conf TB --- 2012-10-29 08:08:54 - /usr/sbin/config -m LINT TB --- 2012-10-29 08:08:54 - building LINT kernel TB --- 2012-10-29 08:08:54 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 08:08:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 08:08:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 08:08:54 - SRCCONF=/dev/null TB --- 2012-10-29 08:08:54 - TARGET=sparc64 TB --- 2012-10-29 08:08:54 - TARGET_ARCH=sparc64 TB --- 2012-10-29 08:08:54 - TZ=UTC TB --- 2012-10-29 08:08:54 - __MAKE_CONF=/dev/null TB --- 2012-10-29 08:08:54 - cd /src TB --- 2012-10-29 08:08:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 29 08:08:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/misc/ufm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/misc/udbp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/input/uep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/input/uhid.c /src/sys/dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 08:13:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 08:13:20 - ERROR: failed to build LINT kernel TB --- 2012-10-29 08:13:20 - 2187.38 user 393.48 system 2602.36 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 08:14:27 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E35483A4; Mon, 29 Oct 2012 08:14:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA2D8FC17; Mon, 29 Oct 2012 08:14:27 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q9T8ER9V018432; Mon, 29 Oct 2012 08:14:27 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q9T8ERNM018431; Mon, 29 Oct 2012 08:14:27 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Oct 2012 08:14:27 GMT Message-Id: <201210290814.q9T8ERNM018431@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 08:14:28 -0000 TB --- 2012-10-29 07:29:06 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-10-29 07:29:06 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-29 07:29:06 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2012-10-29 07:29:06 - cleaning the object tree TB --- 2012-10-29 07:29:24 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-10-29 07:29:24 - cd /tinderbox/RELENG_8/powerpc/powerpc TB --- 2012-10-29 07:29:24 - /usr/local/bin/svn cleanup /src TB --- 2012-10-29 07:29:31 - /usr/local/bin/svn update /src TB --- 2012-10-29 07:29:36 - At svn revision 242302 TB --- 2012-10-29 07:29:37 - building world TB --- 2012-10-29 07:29:37 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 07:29:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 07:29:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 07:29:37 - SRCCONF=/dev/null TB --- 2012-10-29 07:29:37 - TARGET=powerpc TB --- 2012-10-29 07:29:37 - TARGET_ARCH=powerpc TB --- 2012-10-29 07:29:37 - TZ=UTC TB --- 2012-10-29 07:29:37 - __MAKE_CONF=/dev/null TB --- 2012-10-29 07:29:37 - cd /src TB --- 2012-10-29 07:29:37 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 29 07:29:38 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 29 08:10:17 UTC 2012 TB --- 2012-10-29 08:10:17 - generating LINT kernel config TB --- 2012-10-29 08:10:17 - cd /src/sys/powerpc/conf TB --- 2012-10-29 08:10:17 - /usr/bin/make -B LINT TB --- 2012-10-29 08:10:17 - cd /src/sys/powerpc/conf TB --- 2012-10-29 08:10:17 - /usr/sbin/config -m LINT TB --- 2012-10-29 08:10:17 - building LINT kernel TB --- 2012-10-29 08:10:17 - CROSS_BUILD_TESTING=YES TB --- 2012-10-29 08:10:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-29 08:10:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-29 08:10:17 - SRCCONF=/dev/null TB --- 2012-10-29 08:10:17 - TARGET=powerpc TB --- 2012-10-29 08:10:17 - TARGET_ARCH=powerpc TB --- 2012-10-29 08:10:17 - TZ=UTC TB --- 2012-10-29 08:10:17 - __MAKE_CONF=/dev/null TB --- 2012-10-29 08:10:17 - cd /src TB --- 2012-10-29 08:10:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 29 08:10:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/misc/ufm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/misc/udbp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/input/uep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/usb/input/uhid.c /src/sys/dev/usb/input/uhid.c: In function 'uhid_probe': /src/sys/dev/usb/input/uhid.c:697: error: 'UQ_UMS_IGNORE' undeclared (first use in this function) /src/sys/dev/usb/input/uhid.c:697: error: (Each undeclared identifier is reported only once /src/sys/dev/usb/input/uhid.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-29 08:14:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-29 08:14:27 - ERROR: failed to build LINT kernel TB --- 2012-10-29 08:14:27 - 2298.22 user 402.91 system 2720.18 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 19:38:25 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA9ABF66; Mon, 29 Oct 2012 19:38:25 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0594D8FC15; Mon, 29 Oct 2012 19:38:24 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9TJdpNq006408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Oct 2012 20:39:51 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <508EDB2F.3010608@omnilan.de> Date: Mon, 29 Oct 2012 20:38:23 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: stable@FreeBSD.org Subject: Re: lock violation in unionfs (9.0-STABLE r230270) References: <5022840B.3060708@omnilan.de> <5048C6D1.8020007@omnilan.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCBE037511D23FEEE1D7B9120" Cc: daichi@FreeBSD.org, Pavel Polyakov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 19:38:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCBE037511D23FEEE1D7B9120 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Attilio Rao am 27.10.2012 23:07 (localtime): > On Sat, Oct 27, 2012 at 9:46 PM, Attilio Rao wrot= e: >> On Sat, Sep 8, 2012 at 12:48 AM, Attilio Rao wro= te: >>> On Thu, Sep 6, 2012 at 4:52 PM, Harald Schmalzbauer >>> wrote: >>>> schrieb Attilio Rao am 09.08.2012 20:26 (localtime): >>>>> On 8/8/12, Harald Schmalzbauer wrote: >>>>>> schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime): >>>>>>>>> mount -t unionfs -o noatime /usr /mnt >>>>>>>>> >>>>>>>>> insmntque: mp-safe fs and non-locked vp: 0xfffffe01d96704f0 is = not >>>>>>>>> exclusive locked but should be >>>>>>>>> KDB: enter: lock violation >>>>>>>> Pavel, >>>>>>>> can you give a spin to this patch?: >>>>>>>> http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.p= atch >>>>>>>> >>>>>>>> I think that the unlocking is due at that point as the vnode loc= k can >>>>>>>> be switch later on. >>>>>>>> >>>>>>>> Let me know what you think about it and what the test does. >>>>>>> Thanks! >>>>>>> This patch fixes the problem with lock violation. Sorry I've test= ed it so >>>>>>> late. >>>>>> Hello, >>>>>> >>>>>> this patch still applies cleanly to RELENG_9_1. Was there another = fix >>>>>> for the issue or has it just not been PR-sent and thus forgotten? >>>>> Can you and Pavel try the attached patch? Unfortunately I had no ti= me >>>>> to test it, I just made in 5 free mins from a non-FreeBSD workstati= on, >>>> Sorry, couldn't test earlier, but now I did: >>>> With this patch applied the machine hangs without debug kernel and t= he >>>> latter gives the following panic: >>>> System call nmount returning with the following locks held: >>>> exclusive lockmgr ufs (ufs) r =3D 0 (0xc5438278) locked @ >>>> src/sys/fs/unionfs/union_vnops.c:1938 >>>> panic: witness_warn >>>> cpuid =3D 0 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper(c0a04f7f,c0c112c4,d1de3bb4,c097aa8c,fc,...) at= >>>> db_trace_self_wrapper+0x26 >>>> kdb_backtrace(c0a4965f,0,c09c2ede3c1c,0,...) at kdb_backtrace+0x2a >>>> witness_warn(2,0,c0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >>>> syscall(d1de3d08) ar syscall+0x415 >>>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>>> --- syscall (0, FreeBSD ELF32, nosys), eip =3D 0x280b883f,esp =3D >>>> 0xbfbfe46c, ebp =3D 0xbfbfede8 --- >>>> KDB: enter: panic >>>> [ thread pid 86 tid 100054 ] >>>> Stopped ad kdb_enter+0x3a: movl $0,kdb_why >>>> db> bt >>>> Tracing pid 86 tid 100054 td 0xc541b000 >>>> kdb_enter(c0a00d16,c0a09130,0,0,0,...) at panix+0x190 >>>> witness_warn(2,0,x0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >>>> syscall(d1de3d08) at syscall+0x415 >>>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>>> >>>> Hmm, I guess I forgot to install kernel debug symbols... >>>> Coming back if I have more >>> Unfortunately unionfs does very wrong things with the insmntque() loc= king. >>> It basically expects the vnode to return locked in the same way >>> requested by the precedent namei() (when that happens) but when you d= o >>> insmntque() you can only have an LK_EXCLUSIVE lock on the vnode. >> Hello, >> the following patch should workout the issues around unionfs_nodeget()= a bit: >> http://www.freebsd.org/~attilio/unionfs_nodeget2.patch >> >> Unfortunately unionfs code is rather messy in the lookup path about >> locking requirements so follow what it needs to be done there is a bit= >> difficult. >> I have no way to test this patch, so it is just test-compiled at the >> moment, but I would need that you also test lookup path (so directory >> "ls", find(1) on the whole unionfs volume, etc.) to validate it >> someway. > On a second thought, I think that locking in lookup (and also other > operations) is so fragile and difficult to follow that it makes all > vnops real locking landmines. > I think that the following patch fixes the insmntque insertion and > follows the old approach well enough to be committed separately: > http://www.freebsd.org/~attilio/unionfs_nodeget3.patch > Unfortunately I have no idea about all those locking strategies and implementations. Applying unionfs_nodeget3.patch results in: sys/fs/unionfs/union_subr.c: In function 'unionfs_nodeget': sys/fs/unionfs/union_subr.c:332: error: expected statement before ')' token *** [union_subr.o] Error code 1 I guess there is a typo in this chunk: @@ -317,11 +328,11 @@ unionfs_nodeget(struct mount *mp, struct vnode *up vref(vp); } else *vpp =3D vp; - -unionfs_nodeget_out: - if (lkflags & LK_TYPE_MASK) - vn_lock(vp, lkflags | LK_RETRY); - + if (lkflags & LK_TYPE_MASK) { + if (lkflags =3D=3D LK_SHARED)) ---------------------------------------- ^ + vn_lock(vp, LK_DOWNGRADE | LK_RETRY); + } else + VOP_UNLOCK(vp, LK_RELEASE); return (0); } After removing the second right parenthesis kernel compiles. But it still crashes: panic: Lock (lockmgr) ufs not locked @ sys/kern/vfs_default.c:512 cpuid =3D 1 KDB: stack backtrace: =2E.. If you can use the bt info I'll transcribe - no serial console available = :-( Am I right that I should only apply _one_ unionfs-patchX.patch (unionfs_nodeget3.patch in that case)? Thanks, -Harry --------------enigCBE037511D23FEEE1D7B9120 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCO2y8ACgkQLDqVQ9VXb8g20gCeINqbhpiC7Vd3Z+F/e6qf2YGF dZMAn2qTC9ze0+UQpBk0h5w9FlULovr/ =/2Lm -----END PGP SIGNATURE----- --------------enigCBE037511D23FEEE1D7B9120-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 00:05:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B93D1F40 for ; Tue, 30 Oct 2012 00:05:57 +0000 (UTC) (envelope-from bounce-izgybmvmgvcwnyzbhwfggdznmyqkcqbmbmpnzfkmtqkkhdnhfr@todayonthirdage.com) Received: from mail2.todayonthirdage.com (mail2.todayonthirdage.com [96.46.136.10]) by mx1.freebsd.org (Postfix) with ESMTP id 87AC88FC17 for ; Tue, 30 Oct 2012 00:05:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=default; d=todayonthirdage.com; h=From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:list-unsubscribe:Date; i=newsletters@todayonthirdage.com; bh=14OwpqAyYE4cXEyFrvkQPeaLh98=; b=1BWHJ/gP6Yfmorl8CajSuVw2jxOi3abFDXj0hGl+FtbQhHgw6lDvGV831im6qvPWZTyJZbXRqicZ Bw+NJXD2jA== DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=default; d=todayonthirdage.com; b=B5QdjycBIUn9D0COWU8pYvHneakzydUWVTsv06hyn+1G4EY8j74OhYbFjiMD5z6Ay7Dq5tNpz6dW 0vhiPlTrjQ==; Received: by mail2.todayonthirdage.com id hhscua0j9jsh for ; Mon, 29 Oct 2012 18:57:05 -0500 (envelope-from ) From: ThirdAge To: "friend" Message-ID: <1950605329.4932063.1351555024654.JavaMail.root@todayonthirdage.com> Subject: Is Your Computer Safe? Get StrongHold Computer Backup Today! X-THAG: zssfwbdzszdbkrmrkmwfdzrpbm tzzldwsrqjfqbsbsvwdtjsgqjjmlwmtckrbspszpfkwrdbm rmsblzlbml X-PVIQ: 000317-000671- Date: Mon, 29 Oct 2012 18:57:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ThirdAge List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 00:05:57 -0000 [bGl2ZWNvbmNsaWVudElEPTQ2Mjk5NzU5MDcxNzImQ3JlYXRpdmVJRD1GMDA2ODc1MS1DR DlDLTQ1NDUtQjc4Ri1ENUFDREQyNjcyRkUtNzE4NDImUGxhY2VtZW50SUQ9MiZFdmVudFR5 cGU9SW1wcmVzc2lvbiZyYW5kPTMzVmw.jpeg] [1][img_top.png] [NFB-AwardColor.jpg] [info.jpg] Get Stronghold today and let our comprehensive, easy-to-use system do the work of managing and protecting your digital assets. You can even try Stronghold FREE* for 30-days. We're confident that once you've used our product, you'll feel more secure than ever about your online activity. Plus, you'll enjoy easy access to your data and total control over how you want to share any file, big or small. [about.png] Stronghold is a pioneer and technology leader in online backup - dedicated to service consumers, small and medium businesses and IT/managed service providers. Stronghold Online Backup delivers a simple yet powerful online backup service that has become the industry's top award winner, including Laptop Magazine's Editor's Choice and PC Magazine's Editor's Choice Award since 2006. At Stronghold, we believe your backup should be set up once, and then work automatically. Our product works seamlessly so you never have to remember to back up. You can recover your files from our servers with just a few clicks. [about_checks.png] [couple.jpg] [2][start_now.png] [i.ashx?a=1&c=1&s1=SUB_ID] References 1. http://click1.todayonthirdage.com/rckqjjvwtgcpbflbpkgkgpytwqpfghbffrvtrqskwtgvcn_umfhgnwnywc.html 2. http://click1.todayonthirdage.com/wdvyffszngdbmqjmbwgwgbknzybqgtmqqlsnlyhwzngsdw_umfhgnwnywc.html From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 01:33:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 883DFB7F for ; Tue, 30 Oct 2012 01:33:46 +0000 (UTC) (envelope-from steven_nikkel@ertyu.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 569088FC0A for ; Tue, 30 Oct 2012 01:33:46 +0000 (UTC) Received: from pd3ml2so-ssvc.prod.shaw.ca ([10.0.141.138]) by pd4mo1so-svcs.prod.shaw.ca with ESMTP; 29 Oct 2012 19:33:45 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=3f4U5fHrZLLPCzJ96ldNbjtja1zQ0ih230F6vdsLr5s= c=1 sm=1 a=1fWRePjM8PAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=gn0rv3KfuWpWgkKhuBHlTQ==:17 a=56-MFJoclcFlsGwsFqcA:9 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO ertyu.org) ([24.79.195.167]) by pd3ml2so-dmz.prod.shaw.ca with ESMTP; 29 Oct 2012 19:33:45 -0600 Date: Mon, 29 Oct 2012 20:33:44 -0500 (CDT) From: Steven Nikkel To: freebsd-stable@freebsd.org Subject: CPU Competition Issue Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 01:33:46 -0000 I'm running a long duration CPU-centric process that will gobble up all available CPU time. I have it set to run at nice +20. While it's running I've noticed other processes have a hard time getting CPU time and run their activites very slowly. The processes I've noticed issues with are IO involved, but they don't appear to be IO blocked as they run dramatically faster and use much more CPU time when the CPU intensive process is not running. I haven't noticed issues with other processes, but I haven't been looking. If I push my CPU intensive process into idle priority 1, all the other processes return to their normal behaviour as if it's not running. This seems to be a specific behaviour on this one machine running 9.0-RELEASE-p4 on an Atom 330 dual core. I've tried with and without hyperthreading enabled with no noticeable change in behaviour. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 02:06:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3C9755A for ; Tue, 30 Oct 2012 02:06:11 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 87B778FC08 for ; Tue, 30 Oct 2012 02:06:11 +0000 (UTC) Received: by mail-gg0-f182.google.com with SMTP id l1so1103592ggn.13 for ; Mon, 29 Oct 2012 19:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gyMdV+8Ch4JWrfJ9dmuAwTB7OrS7GlPHmG+Cu2UnQCU=; b=NXwOUBQLIshQS11xxiRB6zYZLr/qRnu9pd0SB4RXST9+miSunlNLngP39jvCh37yyJ eDwlcl21Jw1G7rl1QCQi8ZtBgIt9o9lwBf+36ZnQM8tUxkl1KU2gm0KT/LiGrwL+aXEG BGbk5760AtZ5+bYsOIghGdxN05pwOC9OfBO9xWgubpYbbav8Kx/aF15qhi6b3fn8dwe5 pYdjzscHsn1ldcR2ruNjsHHydxnazPYJUiASbMwaLfklbiZlBfJPQaq1xPSSgLRZzC5k HVOAJ0z4EvVYPz4Vi72d+EywJTQUe45Hth/CHjW1ogjJwKiCWmIDzP9LvavAEymdZR0V /8uw== Received: by 10.236.76.132 with SMTP id b4mr31112101yhe.106.1351562765191; Mon, 29 Oct 2012 19:06:05 -0700 (PDT) Received: from [192.168.1.187] (173-17-34-224.client.mchsi.com. [173.17.34.224]) by mx.google.com with ESMTPS id u12sm10274536ank.18.2012.10.29.19.06.04 (version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 19:06:04 -0700 (PDT) Message-ID: <508F3608.3000301@gmail.com> Date: Mon, 29 Oct 2012 21:06:00 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: CPU Competition Issue References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 02:06:11 -0000 On 10/29/2012 08:33 PM, Steven Nikkel wrote: > I'm running a long duration CPU-centric process that will gobble up all > available CPU time. I have it set to run at nice +20. While it's running > I've noticed other processes have a hard time getting CPU time and run > their activites very slowly. The processes I've noticed issues with are > IO involved, but they don't appear to be IO blocked as they run > dramatically faster and use much more CPU time when the CPU intensive > process is not running. I haven't noticed issues with other processes, > but I haven't been looking. If I push my CPU intensive process into idle > priority 1, all the other processes return to their normal behaviour as > if it's not running. > > This seems to be a specific behaviour on this one machine running > 9.0-RELEASE-p4 on an Atom 330 dual core. I've tried with and without > hyperthreading enabled with no noticeable change in behaviour. > > _______________________________________________ > 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" I will likely irritate some people, but you could try the 4BSD scheduler, see if that gives you better results. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 08:57:32 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 360C1AAE for ; Tue, 30 Oct 2012 08:57:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 78D0C8FC14 for ; Tue, 30 Oct 2012 08:57:30 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA24884; Tue, 30 Oct 2012 10:57:22 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TT7dS-0004en-8D; Tue, 30 Oct 2012 10:57:22 +0200 Message-ID: <508F9671.3060501@FreeBSD.org> Date: Tue, 30 Oct 2012 10:57:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Steven Nikkel Subject: Re: CPU Competition Issue References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 08:57:32 -0000 on 30/10/2012 03:33 Steven Nikkel said the following: > I'm running a long duration CPU-centric process that will gobble up all > available CPU time. I have it set to run at nice +20. While it's running I've > noticed other processes have a hard time getting CPU time and run their > activites very slowly. The processes I've noticed issues with are IO involved, > but they don't appear to be IO blocked as they run dramatically faster and use > much more CPU time when the CPU intensive process is not running. I haven't > noticed issues with other processes, but I haven't been looking. If I push my > CPU intensive process into idle priority 1, all the other processes return to > their normal behaviour as if it's not running. > > This seems to be a specific behaviour on this one machine running 9.0-RELEASE-p4 > on an Atom 330 dual core. I've tried with and without hyperthreading enabled > with no noticeable change in behaviour. Can you try with lower nice value, like +10? You want a fix from r228718. AFAIR, it is not in 9.0. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 09:37:27 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7647D422; Tue, 30 Oct 2012 09:37:27 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 41A038FC17; Tue, 30 Oct 2012 09:37:27 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id 95B2C1A3C61; Tue, 30 Oct 2012 02:37:21 -0700 (PDT) Message-ID: <508FA008.2040503@mu.org> Date: Tue, 30 Oct 2012 02:38:16 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: stable@freebsd.org, jh@freebsd.org, kevlo@freebsd.org, re@freebsd.org Subject: tmpfs nfs exports? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 09:37:27 -0000 Hey folks, any reason why not to include the following patch in 9.1? It would be nice to have tmpfs be exportable. I'm good to commit it, I can also wait until post 9.1. $ svn diff Index: . =================================================================== --- . (revision 242331) +++ . (working copy) Property changes on: . ___________________________________________________________________ Modified: svn:mergeinfo Merged /head:r234346 Index: sys =================================================================== --- sys (revision 242331) +++ sys (working copy) Property changes on: sys ___________________________________________________________________ Modified: svn:mergeinfo Merged /head/sys:r234346 Index: sys/fs =================================================================== --- sys/fs (revision 242331) +++ sys/fs (working copy) Property changes on: sys/fs ___________________________________________________________________ Modified: svn:mergeinfo Merged /head/sys/fs:r234346 Index: sys/fs/tmpfs/tmpfs.h =================================================================== --- sys/fs/tmpfs/tmpfs.h (revision 242331) +++ sys/fs/tmpfs/tmpfs.h (working copy) @@ -387,6 +387,9 @@ * tmpfs_pool.c. */ uma_zone_t tm_dirent_pool; uma_zone_t tm_node_pool; + + /* Read-only status. */ + int tm_ronly; }; #define TMPFS_LOCK(tm) mtx_lock(&(tm)->allnode_lock) #define TMPFS_UNLOCK(tm) mtx_unlock(&(tm)->allnode_lock) Index: sys/fs/tmpfs/tmpfs_vfsops.c =================================================================== --- sys/fs/tmpfs/tmpfs_vfsops.c (revision 242331) +++ sys/fs/tmpfs/tmpfs_vfsops.c (working copy) @@ -82,6 +82,10 @@ NULL }; +static const char *tmpfs_updateopts[] = { + "from", "export", NULL +}; + /* --------------------------------------------------------------------- */ static int @@ -193,10 +197,13 @@ return (EINVAL); if (mp->mnt_flag & MNT_UPDATE) { - /* XXX: There is no support yet to update file system - * settings. Should be added. */ - - return EOPNOTSUPP; + /* Only support update mounts for certain options. */ + if (vfs_filteropt(mp->mnt_optnew, tmpfs_updateopts) != 0) + return (EOPNOTSUPP); + if (vfs_flagopt(mp->mnt_optnew, "ro", NULL, 0) != + ((struct tmpfs_mount *)mp->mnt_data)->tm_ronly) + return (EOPNOTSUPP); + return (0); } vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY); @@ -269,6 +276,7 @@ tmpfs_node_ctor, tmpfs_node_dtor, tmpfs_node_init, tmpfs_node_fini, UMA_ALIGN_PTR, 0); + tmp->tm_ronly = (mp->mnt_flag & MNT_RDONLY) != 0; /* Allocate the root node. */ error = tmpfs_alloc_node(tmp, VDIR, root_uid, From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 10:10:55 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48398AF7; Tue, 30 Oct 2012 10:10:55 +0000 (UTC) (envelope-from kevlo@FreeBSD.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id BE6498FC1B; Tue, 30 Oct 2012 10:10:54 +0000 (UTC) Received: from srg.kevlo.org (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id q9UAAgg3013344; Tue, 30 Oct 2012 18:10:42 +0800 (CST) (envelope-from kevlo@FreeBSD.org) Message-ID: <508FA7A5.6060102@FreeBSD.org> Date: Tue, 30 Oct 2012 18:10:45 +0800 From: Kevin Lo User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121009 Thunderbird/15.0.1 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: tmpfs nfs exports? References: <508FA008.2040503@mu.org> In-Reply-To: <508FA008.2040503@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jh@FreeBSD.org, stable@FreeBSD.org, re@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 10:10:55 -0000 On 2012/10/30 17:38, Alfred Perlstein wrote: > Hey folks, any reason why not to include the following patch in 9.1? > It would be nice to have tmpfs be exportable. Ah, sorry. I forgot to MFC it. > > I'm good to commit it, I can also wait until post 9.1. Please commit it, thanks. Kevin From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 12:00:31 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA1FE6DD; Tue, 30 Oct 2012 12:00:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kostikbel-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:13d6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 646D98FC18; Tue, 30 Oct 2012 12:00:29 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id q9UC0JE7068677; Tue, 30 Oct 2012 14:00:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id q9UC0J2a068675; Tue, 30 Oct 2012 14:00:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 30 Oct 2012 14:00:19 +0200 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: tmpfs nfs exports? Message-ID: <20121030120019.GU73505@kib.kiev.ua> References: <508FA008.2040503@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wiiWofWi8Et/oezL" Content-Disposition: inline In-Reply-To: <508FA008.2040503@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: jh@freebsd.org, stable@freebsd.org, re@freebsd.org, kevlo@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:00:31 -0000 --wiiWofWi8Et/oezL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 30, 2012 at 02:38:16AM -0700, Alfred Perlstein wrote: > Hey folks, any reason why not to include the following patch in 9.1? It= =20 > would be nice to have tmpfs be exportable. >=20 > I'm good to commit it, I can also wait until post 9.1. It is too late for 9.1. Patch is fine for stable/9, but you merged at the wrong point. Merge at sys/, not at the root of the sources. >=20 > $ svn diff > Index: . > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- . (revision 242331) > +++ . (working copy) >=20 > Property changes on: . > ___________________________________________________________________ > Modified: svn:mergeinfo > Merged /head:r234346 > Index: sys > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys (revision 242331) > +++ sys (working copy) >=20 > Property changes on: sys > ___________________________________________________________________ > Modified: svn:mergeinfo > Merged /head/sys:r234346 > Index: sys/fs > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/fs (revision 242331) > +++ sys/fs (working copy) >=20 > Property changes on: sys/fs > ___________________________________________________________________ > Modified: svn:mergeinfo > Merged /head/sys/fs:r234346 > Index: sys/fs/tmpfs/tmpfs.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/fs/tmpfs/tmpfs.h (revision 242331) > +++ sys/fs/tmpfs/tmpfs.h (working copy) > @@ -387,6 +387,9 @@ > * tmpfs_pool.c. */ > uma_zone_t tm_dirent_pool; > uma_zone_t tm_node_pool; > + > + /* Read-only status. */ > + int tm_ronly; > }; > #define TMPFS_LOCK(tm) mtx_lock(&(tm)->allnode_lock) > #define TMPFS_UNLOCK(tm) mtx_unlock(&(tm)->allnode_lock) > Index: sys/fs/tmpfs/tmpfs_vfsops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/fs/tmpfs/tmpfs_vfsops.c (revision 242331) > +++ sys/fs/tmpfs/tmpfs_vfsops.c (working copy) > @@ -82,6 +82,10 @@ > NULL > }; >=20 > +static const char *tmpfs_updateopts[] =3D { > + "from", "export", NULL > +}; > + > /*=20 > --------------------------------------------------------------------- */ >=20 > static int > @@ -193,10 +197,13 @@ > return (EINVAL); >=20 > if (mp->mnt_flag & MNT_UPDATE) { > - /* XXX: There is no support yet to update file system > - * settings. Should be added. */ > - > - return EOPNOTSUPP; > + /* Only support update mounts for certain options. */ > + if (vfs_filteropt(mp->mnt_optnew, tmpfs_updateopts) !=3D 0) > + return (EOPNOTSUPP); > + if (vfs_flagopt(mp->mnt_optnew, "ro", NULL, 0) !=3D > + ((struct tmpfs_mount *)mp->mnt_data)->tm_ronly) > + return (EOPNOTSUPP); > + return (0); > } >=20 > vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY); > @@ -269,6 +276,7 @@ > tmpfs_node_ctor, tmpfs_node_dtor, > tmpfs_node_init, tmpfs_node_fini, > UMA_ALIGN_PTR, 0); > + tmp->tm_ronly =3D (mp->mnt_flag & MNT_RDONLY) !=3D 0; >=20 > /* Allocate the root node. */ > error =3D tmpfs_alloc_node(tmp, VDIR, root_uid, --wiiWofWi8Et/oezL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCPwVIACgkQC3+MBN1Mb4j4EACgvIQuCVV1Z/RdC80Wjxp7D9oy Dd4AoLyLcnlA2P5sBtg3wYhNn8BuiAsy =Ao3T -----END PGP SIGNATURE----- --wiiWofWi8Et/oezL-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 12:19:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B059E140; Tue, 30 Oct 2012 12:19:40 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by mx1.freebsd.org (Postfix) with ESMTP id C2A6F8FC0A; Tue, 30 Oct 2012 12:19:39 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0IAE/Fj1DLevdH/2dsb2JhbABEv22CRASCCIIeAQEFOEEQCw4KCRMDDwkDAgECAUUGDQEHAQGIAaxJkDaLdWGFfAOmNoMC Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail05.adl6.internode.on.net with ESMTP; 30 Oct 2012 22:49:38 +1030 Message-ID: <508FC3D8.8030800@ShaneWare.Biz> Date: Tue, 30 Oct 2012 22:41:04 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: CPU Competition Issue References: <508F9671.3060501@FreeBSD.org> In-Reply-To: <508F9671.3060501@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steven Nikkel , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:19:40 -0000 On 30/10/2012 19:27, Andriy Gapon wrote: > on 30/10/2012 03:33 Steven Nikkel said the following: >> I'm running a long duration CPU-centric process that will gobble up all >> available CPU time. I have it set to run at nice +20. While it's running I've >> noticed other processes have a hard time getting CPU time and run their >> activites very slowly. The processes I've noticed issues with are IO involved, >> but they don't appear to be IO blocked as they run dramatically faster and use >> much more CPU time when the CPU intensive process is not running. I haven't >> noticed issues with other processes, but I haven't been looking. If I push my >> CPU intensive process into idle priority 1, all the other processes return to >> their normal behaviour as if it's not running. >> >> This seems to be a specific behaviour on this one machine running 9.0-RELEASE-p4 >> on an Atom 330 dual core. I've tried with and without hyperthreading enabled >> with no noticeable change in behaviour. > > Can you try with lower nice value, like +10? > You want a fix from r228718. AFAIR, it is not in 9.0. > Could it be cache based? The atom's smaller cache causing more cache misses. Would you be running zfs? From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 13:29:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E3CDB5A for ; Tue, 30 Oct 2012 13:29:52 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 41E768FC20 for ; Tue, 30 Oct 2012 13:29:51 +0000 (UTC) Received: from [192.168.15.220] (gw.digitalspark.net [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 81B9CB9F24 for ; Tue, 30 Oct 2012 09:21:50 -0400 (EDT) Message-ID: <508FD46D.3040608@ateamsystems.com> Date: Tue, 30 Oct 2012 20:21:49 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: FreeBSD-Stable ML Subject: No buffer space available / tcp_inpcb value Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 13:29:52 -0000 Hey -STABLE, I've got a client who we've setup a FreeBSD cluster for with about a dozens servers, all behind two front end proxies/LBs/firewalls which also act as NAT gateways for the internal servers. On the active front end proxy we've started seeing "fatal: socket: No buffer space available" errors during high-peak times. I can see in vmstat -z that this is what is getting denied: ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP tcp_inpcb: 392, 32770, 19398, 13372,1449734621,6312858, 0 We've got a lot of the other values bumped, and it appears to be this input limit that is getting hit. There are no other non-zero FAILed counters except 64 and 128 buckets which I believe are normal. I cannot seem to find the sysctl (or equiv) that controls this limit though, or even what it is. Anyone know? I'm obviously in need of this specific answer, but overall is there a codex of vmstat -z's items that explains this that I have just not found in my searches? This isn't the first time I've had to dig into a value like this to increase it's limit, but this time I'm not turning anything up. Any thoughts/ideas appreciated! -- Adam Strohl http://www.ateamsystems.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 13:59:12 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77A8A6F8; Tue, 30 Oct 2012 13:59:12 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 428158FC08; Tue, 30 Oct 2012 13:59:12 +0000 (UTC) Received: from [10.252.136.148] (85.sub-174-234-88.myvzw.com [174.234.88.85]) by elvis.mu.org (Postfix) with ESMTPSA id A31501A3D77; Tue, 30 Oct 2012 06:59:11 -0700 (PDT) References: <508FA008.2040503@mu.org> <20121030120019.GU73505@kib.kiev.ua> In-Reply-To: <20121030120019.GU73505@kib.kiev.ua> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Alfred Perlstein Subject: Re: tmpfs nfs exports? Date: Tue, 30 Oct 2012 06:59:08 -0700 To: Konstantin Belousov Cc: "jh@freebsd.org" , "stable@freebsd.org" , "re@freebsd.org" , "kevlo@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 13:59:12 -0000 Thanks all. I will fix up the merge step and commit. Sent from my iPhone On Oct 30, 2012, at 5:00 AM, Konstantin Belousov wrote: > On Tue, Oct 30, 2012 at 02:38:16AM -0700, Alfred Perlstein wrote: >> Hey folks, any reason why not to include the following patch in 9.1? It >> would be nice to have tmpfs be exportable. >> >> I'm good to commit it, I can also wait until post 9.1. > It is too late for 9.1. Patch is fine for stable/9, but you merged at > the wrong point. Merge at sys/, not at the root of the sources. > >> >> $ svn diff >> Index: . >> =================================================================== >> --- . (revision 242331) >> +++ . (working copy) >> >> Property changes on: . >> ___________________________________________________________________ >> Modified: svn:mergeinfo >> Merged /head:r234346 >> Index: sys >> =================================================================== >> --- sys (revision 242331) >> +++ sys (working copy) >> >> Property changes on: sys >> ___________________________________________________________________ >> Modified: svn:mergeinfo >> Merged /head/sys:r234346 >> Index: sys/fs >> =================================================================== >> --- sys/fs (revision 242331) >> +++ sys/fs (working copy) >> >> Property changes on: sys/fs >> ___________________________________________________________________ >> Modified: svn:mergeinfo >> Merged /head/sys/fs:r234346 >> Index: sys/fs/tmpfs/tmpfs.h >> =================================================================== >> --- sys/fs/tmpfs/tmpfs.h (revision 242331) >> +++ sys/fs/tmpfs/tmpfs.h (working copy) >> @@ -387,6 +387,9 @@ >> * tmpfs_pool.c. */ >> uma_zone_t tm_dirent_pool; >> uma_zone_t tm_node_pool; >> + >> + /* Read-only status. */ >> + int tm_ronly; >> }; >> #define TMPFS_LOCK(tm) mtx_lock(&(tm)->allnode_lock) >> #define TMPFS_UNLOCK(tm) mtx_unlock(&(tm)->allnode_lock) >> Index: sys/fs/tmpfs/tmpfs_vfsops.c >> =================================================================== >> --- sys/fs/tmpfs/tmpfs_vfsops.c (revision 242331) >> +++ sys/fs/tmpfs/tmpfs_vfsops.c (working copy) >> @@ -82,6 +82,10 @@ >> NULL >> }; >> >> +static const char *tmpfs_updateopts[] = { >> + "from", "export", NULL >> +}; >> + >> /* >> --------------------------------------------------------------------- */ >> >> static int >> @@ -193,10 +197,13 @@ >> return (EINVAL); >> >> if (mp->mnt_flag & MNT_UPDATE) { >> - /* XXX: There is no support yet to update file system >> - * settings. Should be added. */ >> - >> - return EOPNOTSUPP; >> + /* Only support update mounts for certain options. */ >> + if (vfs_filteropt(mp->mnt_optnew, tmpfs_updateopts) != 0) >> + return (EOPNOTSUPP); >> + if (vfs_flagopt(mp->mnt_optnew, "ro", NULL, 0) != >> + ((struct tmpfs_mount *)mp->mnt_data)->tm_ronly) >> + return (EOPNOTSUPP); >> + return (0); >> } >> >> vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY); >> @@ -269,6 +276,7 @@ >> tmpfs_node_ctor, tmpfs_node_dtor, >> tmpfs_node_init, tmpfs_node_fini, >> UMA_ALIGN_PTR, 0); >> + tmp->tm_ronly = (mp->mnt_flag & MNT_RDONLY) != 0; >> >> /* Allocate the root node. */ >> error = tmpfs_alloc_node(tmp, VDIR, root_uid, From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 14:42:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A925D74D for ; Tue, 30 Oct 2012 14:42:17 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 57F068FC0A for ; Tue, 30 Oct 2012 14:42:15 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TTD1C-0006tF-2y for freebsd-stable@freebsd.org; Tue, 30 Oct 2012 15:42:16 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Oct 2012 15:42:14 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Oct 2012 15:42:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: tmpfs nfs exports? Date: Tue, 30 Oct 2012 14:41:54 +0000 (UTC) Lines: 20 Message-ID: References: <508FA008.2040503@mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:42:17 -0000 Alfred Perlstein mu.org> writes: > > Hey folks, any reason why not to include the following patch in 9.1? It > would be nice to have tmpfs be exportable. > > I'm good to commit it, I can also wait until post 9.1. > ... How do you identify tmpfs ? With fsid ? Since nfs server is stateless, are these exports identical ? export /tmp, reboot, export /tmp What about /tmp on tmpfs ? export /tmp, reboot, export /tmp jb From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 15:32:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A781E67 for ; Tue, 30 Oct 2012 15:32:46 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id F211C8FC08 for ; Tue, 30 Oct 2012 15:32:45 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [172.17.17.101]) by email1.allantgroup.com (8.14.5/8.14.5) with ESMTP id q9UFVgI4033118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 10:31:42 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id q9UFVg8c072159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 10:31:42 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id q9UFVgbs072157; Tue, 30 Oct 2012 10:31:42 -0500 (CDT) (envelope-from dan) Date: Tue, 30 Oct 2012 10:31:42 -0500 From: Dan Nelson To: jb Subject: Re: tmpfs nfs exports? Message-ID: <20121030153142.GA21003@dan.emsphone.com> References: <508FA008.2040503@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.3-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at email1-new.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (email1.allantgroup.com [172.17.19.78]); Tue, 30 Oct 2012 10:31:42 -0500 (CDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on email1.allantgroup.com X-Scanned-By: MIMEDefang 2.73 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:32:46 -0000 In the last episode (Oct 30), jb said: > Alfred Perlstein mu.org> writes: > > Hey folks, any reason why not to include the following patch in 9.1? It > > would be nice to have tmpfs be exportable. > > > > I'm good to commit it, I can also wait until post 9.1. > > ... > > How do you identify tmpfs ? With fsid ? > > Since nfs server is stateless, are these exports identical ? > export /tmp, reboot, export /tmp > > What about /tmp on tmpfs ? > export /tmp, reboot, export /tmp I wanted to do the exact same thing a few years ago. I patched mdmfs and the startup scripts to allow for an fsid value to be passed to mdmfs on every reboot. That works for the filesystem itself, but then you have to contend with the random NFS generation number on every inode. I decided it wasn't worth the trouble at that point. If you really want an exportable /tmp, just live with the fact that you'll get ESTALE errors on all clients when you reboot the server. Maybe giving the root inode a constant generation number is all that's needed, since I suppose most clients that have mounted the server don't actually have any open filehandles. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 15:45:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82C92202 for ; Tue, 30 Oct 2012 15:45:43 +0000 (UTC) (envelope-from steven_nikkel@ertyu.org) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 48DF28FC12 for ; Tue, 30 Oct 2012 15:45:42 +0000 (UTC) Received: from lb7f8hsrpno-svcs.dcs.int.inet (HELO pd5ml2no-ssvc.prod.shaw.ca) ([10.0.144.222]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 30 Oct 2012 09:45:42 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=+lz5uX4xiInwtrymCIFxsZpC13k2qgqBCqxhxbRs02Y= c=1 sm=1 a=UGu_2VojXwwA:10 a=1fWRePjM8PAA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=gn0rv3KfuWpWgkKhuBHlTQ==:17 a=QASXUrwb0TYg6-wgdpoA:9 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO ertyu.org) ([24.79.195.167]) by pd5ml2no-dmz.prod.shaw.ca with ESMTP; 30 Oct 2012 09:45:42 -0600 Message-ID: <52c0ed4c284d09009a886a09321f477b.squirrel@www2.ertyu.org> In-Reply-To: <508FC3D8.8030800@ShaneWare.Biz> References: <508F9671.3060501@FreeBSD.org> <508FC3D8.8030800@ShaneWare.Biz> Date: Tue, 30 Oct 2012 10:45:41 -0500 Subject: Re: CPU Competition Issue From: steven_nikkel@ertyu.org To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:45:43 -0000 > On 30/10/2012 19:27, Andriy Gapon wrote: >> on 30/10/2012 03:33 Steven Nikkel said the following: >>> I'm running a long duration CPU-centric process that will gobble up all >>> available CPU time. I have it set to run at nice +20. While it's >>> running I've >>> noticed other processes have a hard time getting CPU time and run their >>> activites very slowly. The processes I've noticed issues with are IO >>> involved, >>> but they don't appear to be IO blocked as they run dramatically faster >>> and use >>> much more CPU time when the CPU intensive process is not running. I >>> haven't >>> noticed issues with other processes, but I haven't been looking. If I >>> push my >>> CPU intensive process into idle priority 1, all the other processes >>> return to >>> their normal behaviour as if it's not running. >>> >>> This seems to be a specific behaviour on this one machine running >>> 9.0-RELEASE-p4 >>> on an Atom 330 dual core. I've tried with and without hyperthreading >>> enabled >>> with no noticeable change in behaviour. >> >> Can you try with lower nice value, like +10? >> You want a fix from r228718. AFAIR, it is not in 9.0. >> > > Could it be cache based? The atom's smaller cache causing more cache > misses. > > Would you be running zfs? I am running ZFS. I've tried with doing the I/O on a UFS volume instead of ZFS and the behaviour is the same. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 15:58:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21F5D701 for ; Tue, 30 Oct 2012 15:58:53 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id D56D98FC12 for ; Tue, 30 Oct 2012 15:58:52 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so539188oag.13 for ; Tue, 30 Oct 2012 08:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6XqJ4qqeorFnGOQp9Ui8yq2MmfBmBlkkwf9ALQ+7PI8=; b=seOJ0v4/D44fa03puLEOGTbUX3Zti0Eokee6Ot4z1FTxQYGLBdJTgyMLByQ5+wER9X zNzl5Ko0YJB/SJEqKsR+SlOCtX0t5rlo39HMLFcTEAsu4RfSU2E6o5VaGb/Ra1PR6R1b SWnb9vPSfTwEZJE9qNIuf+Nm0TOmM/BSDXo2MTahKZ/FyrappkwnEJ+GOk13PV2ITDsy i8jV9wYW33BO0nfiBhBjr1hgnA3JepKVIAkMpEt5kE4sDitzJcCk37i2XiARif+H2ioT M2i9i6RDTYXO+VIZHDJjJYiGbLEypG/0OmQK4HRi4HTpjmoUWmhLHqd/o6POY03xFlXF +ppg== MIME-Version: 1.0 Received: by 10.182.218.37 with SMTP id pd5mr28100283obc.24.1351612732245; Tue, 30 Oct 2012 08:58:52 -0700 (PDT) Received: by 10.76.170.36 with HTTP; Tue, 30 Oct 2012 08:58:52 -0700 (PDT) Date: Tue, 30 Oct 2012 16:58:52 +0100 Message-ID: Subject: make release fails on find From: Andreas Nilsson To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:58:53 -0000 I'm trying to build some images for 9-stable ( r242349 ) and 9.1-RC3, but using the release tools doesn't really work. 9.1-RC3 fails with: ... cd /tank/cvs/9.1/src/libexec/rtld-elf; make install -DNO_SUBDIR DESTDIR=3D/tmp/newdist/lib32 SHARED=3Dcopies install -s -o root -g wheel -m 555 -C -b -fschg -S ld-elf32.so.1 /tmp/newdist/lib32/libexec /tmp/newdist/lib32/usr/libexec/ld-elf32.so.1 -> /libexec/ld-elf32.so.1 cd /tank/cvs/9.1/src/usr.bin/ldd; PROG=3Dldd32 MACHINE=3Di386 MACHINE_ARCH= =3Di386 MACHINE_CPU=3D"i686 mmx sse sse2" LD=3D"ld -m elf_i386_fbsd -Y P,/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32" AS=3D"as --32" MAKEOBJDIRPREFIX=3D/usr/obj/lib32 _SHLIBDIRPREFIX=3D/usr/obj/tank/cvs/9.1/src/lib32 VERSION=3D"FreeBSD 9.1-PRERELEASE amd64 901501" PATH=3D/usr/obj/tank/cvs/9.1/src/tmp/legacy/usr/sbin:/usr/obj/tank/cvs/9.1/= src/tmp/legacy/usr/bin:/usr/obj/tank/cvs/9.1/src/tmp/legacy/usr/games:/usr/= obj/tank/cvs/9.1/src/tmp/usr/sbin:/usr/obj/tank/cvs/9.1/src/tmp/usr/bin:/us= r/obj/tank/cvs/9.1/src/tmp/usr/games:/usr/obj/tank/cvs/9.1/src/tmp/legacy/u= sr/sbin:/usr/obj/tank/cvs/9.1/src/tmp/legacy/usr/bin:/usr/obj/tank/cvs/9.1/= src/tmp/legacy/usr/games:/usr/obj/tank/cvs/9.1/src/tmp/usr/sbin:/usr/obj/ta= nk/cvs/9.1/src/tmp/usr/bin:/usr/obj/tank/cvs/9.1/src/tmp/usr/games:/tmp/ins= tall.SgiYOaRS CC=3D"cc -m32 -march=3Dcore2 -DCOMPAT_32BIT -isystem /usr/obj/tank/cvs/9.1/src/lib32/usr/include/ -L/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32 -B/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32" CXX=3D"c++ -m32 -march=3Dcore= 2 -DCOMPAT_32BIT -isystem /usr/obj/tank/cvs/9.1/src/lib32/usr/include/ -L/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32 -B/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32" LIBDIR=3D/usr/lib32 SHLIBDIR=3D/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -ECXX -EAS -ELD -DNO_INCS distribute cd /tank/cvs/9.1/src/usr.bin/ldd; make install -DNO_SUBDIR DESTDIR=3D/tmp/newdist/lib32 SHARED=3Dcopies install -s -o root -g wheel -m 555 ldd32 /tmp/newdist/lib32/usr/bin find //tmp/newdist/doc -empty -delete find //tmp/newdist/games -empty -delete find: -delete: //tmp/newdist/games: relative path potentially not safe *** [distributeworld] Error code 1 Stop in /tank/cvs/9.1/src. *** [distributeworld] Error code 1 And 9-stable ends up recursing when generating tarballs. The sources have already been added to a tarball. The tarballs themselfs are also included. Is anyone having the same problems? Build machine is amd64 9.1-PRERELASE. Source trees are in separate zfs datasets (tank/cvs/9/src and tank/cvs/9.1/src). Regards Andreas From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 16:05:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE79A91B for ; Tue, 30 Oct 2012 16:05:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1B58FC08 for ; Tue, 30 Oct 2012 16:05:34 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so195828dad.13 for ; Tue, 30 Oct 2012 09:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dur03HZb/VDxzJdumhoWM2wDpLXDbAuZB4isHMdNf7U=; b=xXg8nCCV70BQ9Yaea41d713uSZ3ItlngOqXeC3jioy4smc0vh7ELGE2N73vBUGAVrg MdKCQ+Z43rh8QVw3swUv0DEbUTpG58p9RTwRmlf6L/GmjGmuXy0Z5CsIQSIcwm2S8+Ce 4L3vqpitfJrGqQ9INySv/+qE5l0uWe2vyN1CF+v3neatVynF6iMMhIVAnYkLDsiTZGn8 TTjq7pUkfiPug+ec+aj5jihyXk03gWqAD8l3xOMu/h42a3EE3I6yPYbipWgB5/Ip6nGh 1/8B2wMNbQiE8qG7ieQ4nmx2s+VlP9wvLlkYfsK6dYM9nqNSypOb3r1G5PzhMjW+t22i l/tQ== MIME-Version: 1.0 Received: by 10.66.80.133 with SMTP id r5mr94223745pax.24.1351613134332; Tue, 30 Oct 2012 09:05:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Tue, 30 Oct 2012 09:05:34 -0700 (PDT) In-Reply-To: <508FD46D.3040608@ateamsystems.com> References: <508FD46D.3040608@ateamsystems.com> Date: Tue, 30 Oct 2012 09:05:34 -0700 X-Google-Sender-Auth: novXZYIbE72yJWVGi88rsthFfxo Message-ID: Subject: Re: No buffer space available / tcp_inpcb value From: Adrian Chadd To: Adam Strohl Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-Stable ML X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:05:35 -0000 Check the output of 'netstat -mb', maybe you're also running out of mbufs? Adrian On 30 October 2012 06:21, Adam Strohl wrote: > Hey -STABLE, > > I've got a client who we've setup a FreeBSD cluster for with about a dozens > servers, all behind two front end proxies/LBs/firewalls which also act as > NAT gateways for the internal servers. > > On the active front end proxy we've started seeing "fatal: socket: No buffer > space available" errors during high-peak times. I can see in vmstat -z > that this is what is getting denied: > > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > tcp_inpcb: 392, 32770, 19398, 13372,1449734621,6312858, 0 > > We've got a lot of the other values bumped, and it appears to be this input > limit that is getting hit. There are no other non-zero FAILed counters > except 64 and 128 buckets which I believe are normal. > > I cannot seem to find the sysctl (or equiv) that controls this limit though, > or even what it is. Anyone know? > > I'm obviously in need of this specific answer, but overall is there a codex > of vmstat -z's items that explains this that I have just not found in my > searches? This isn't the first time I've had to dig into a value like this > to increase it's limit, but this time I'm not turning anything up. > > Any thoughts/ideas appreciated! > > -- > Adam Strohl > http://www.ateamsystems.com/ > > _______________________________________________ > 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-stable@FreeBSD.ORG Tue Oct 30 16:08:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9799A89; Tue, 30 Oct 2012 16:08:10 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 8C00C8FC0C; Tue, 30 Oct 2012 16:08:10 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 37BCC23F645; Tue, 30 Oct 2012 12:08:07 -0400 (EDT) Date: Tue, 30 Oct 2012 12:08:04 -0400 From: Glen Barber To: Andreas Nilsson Subject: Re: make release fails on find Message-ID: <20121030160804.GB1371@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:08:11 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 30, 2012 at 04:58:52PM +0100, Andreas Nilsson wrote: > I'm trying to build some images for 9-stable ( r242349 ) and 9.1-RC3, but > using the release tools doesn't really work. >=20 > 9.1-RC3 fails with: > ... > cd /tank/cvs/9.1/src/libexec/rtld-elf; make install -DNO_SUBDIR > DESTDIR=3D/tmp/newdist/lib32 SHARED=3Dcopies > install -s -o root -g wheel -m 555 -C -b -fschg -S ld-elf32.so.1 > /tmp/newdist/lib32/libexec > /tmp/newdist/lib32/usr/libexec/ld-elf32.so.1 -> /libexec/ld-elf32.so.1 > cd /tank/cvs/9.1/src/usr.bin/ldd; PROG=3Dldd32 MACHINE=3Di386 MACHINE_ARC= H=3Di386 > MACHINE_CPU=3D"i686 mmx sse sse2" LD=3D"ld -m elf_i386_fbsd -Y > P,/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32" AS=3D"as --32" > MAKEOBJDIRPREFIX=3D/usr/obj/lib32 > _SHLIBDIRPREFIX=3D/usr/obj/tank/cvs/9.1/src/lib32 VERSION=3D"FreeBSD > 9.1-PRERELEASE amd64 901501" > PATH=3D/usr/obj/tank/cvs/9.1/src/tmp/legacy/usr/sbin:/usr/obj/tank/cvs/9.= 1/src/tmp/legacy/usr/bin:/usr/obj/tank/cvs/9.1/src/tmp/legacy/usr/games:/us= r/obj/tank/cvs/9.1/src/tmp/usr/sbin:/usr/obj/tank/cvs/9.1/src/tmp/usr/bin:/= usr/obj/tank/cvs/9.1/src/tmp/usr/games:/usr/obj/tank/cvs/9.1/src/tmp/legacy= /usr/sbin:/usr/obj/tank/cvs/9.1/src/tmp/legacy/usr/bin:/usr/obj/tank/cvs/9.= 1/src/tmp/legacy/usr/games:/usr/obj/tank/cvs/9.1/src/tmp/usr/sbin:/usr/obj/= tank/cvs/9.1/src/tmp/usr/bin:/usr/obj/tank/cvs/9.1/src/tmp/usr/games:/tmp/i= nstall.SgiYOaRS > CC=3D"cc -m32 -march=3Dcore2 -DCOMPAT_32BIT -isystem > /usr/obj/tank/cvs/9.1/src/lib32/usr/include/ > -L/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32 > -B/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32" CXX=3D"c++ -m32 -march=3Dco= re2 > -DCOMPAT_32BIT -isystem /usr/obj/tank/cvs/9.1/src/lib32/usr/include/ > -L/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32 > -B/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32" LIBDIR=3D/usr/lib32 > SHLIBDIR=3D/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIND > -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -ECXX > -EAS -ELD -DNO_INCS distribute > cd /tank/cvs/9.1/src/usr.bin/ldd; make install -DNO_SUBDIR > DESTDIR=3D/tmp/newdist/lib32 SHARED=3Dcopies > install -s -o root -g wheel -m 555 ldd32 /tmp/newdist/lib32/usr/bin > find //tmp/newdist/doc -empty -delete > find //tmp/newdist/games -empty -delete > find: -delete: //tmp/newdist/games: relative path potentially not safe > *** [distributeworld] Error code 1 >=20 > Stop in /tank/cvs/9.1/src. > *** [distributeworld] Error code 1 >=20 Are you defining WITH*_GAMES in src.conf or make.conf? If this looks like what I think it looks like, I fixed this a few months ago. > And 9-stable ends up recursing when generating tarballs. The sources have > already been added to a tarball. The tarballs themselfs are also included. >=20 I have seen many reports on this, and cannot reproduce it. How exactly are you running the release build? What specific make(1) targets are you using, and what is your make.conf/src.conf contents? Glen --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQj/tkAAoJEFJPDDeguUajDIsIAJqPrjOHVT1GSqswEWRal4hs 4Rckmgmif57HqEteXnm1eQ3VWcSWC+SQpt690fHC75ubo+9c3TdO8bTkeGZwJqqo tXvT46III60/uD5I97HzEcTA09o/Ka/dDfy7FQk0rQgiMFVX8XXg132yRTfKl68C am1Z+XjfHhunSgD/ELuzTX6liDEP5TZ9w5lx7mKiQSVUzV0zvdnF6p7xTGvhVLYw VNJibRh4RsZzR+By/KOqWCjX5ytr4GdyVDNH58SFDMoxobpDG3klD/bTAwbuEBZ1 onGJTi1EsTAHxNqPRDIbx+xzyRcxUgGN62rLxWH4VbhddoB2QvKsm7VUHpjhSIo= =YgTS -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 16:09:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63FCEBD3; Tue, 30 Oct 2012 16:09:14 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 43D7D8FC0C; Tue, 30 Oct 2012 16:09:13 +0000 (UTC) Received: from [192.168.15.220] (gw.digitalspark.net [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id E1379BCEC5; Tue, 30 Oct 2012 12:09:09 -0400 (EDT) Message-ID: <508FFBA5.5000600@ateamsystems.com> Date: Tue, 30 Oct 2012 23:09:09 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: No buffer space available / tcp_inpcb value References: <508FD46D.3040608@ateamsystems.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Stable ML X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:09:14 -0000 On 10/30/2012 23:05, Adrian Chadd wrote: > Check the output of 'netstat -mb', maybe you're also running out of mbufs? There was nothing denied there that I can see: 35696/4039/39735 mbufs in use (current/cache/total) 2069/3797/5866/32768 mbuf clusters in use (current/cache/total/max) 2069/2077 mbuf+clusters out of packet secondary zone in use (current/cache) 4/3283/3287/16384 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/8192 9k jumbo clusters in use (current/cache/total/max) 0/0/0/4096 16k jumbo clusters in use (current/cache/total/max) 13078K/21735K/34813K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines > > Adrian > > > On 30 October 2012 06:21, Adam Strohl wrote: >> Hey -STABLE, >> >> I've got a client who we've setup a FreeBSD cluster for with about a dozens >> servers, all behind two front end proxies/LBs/firewalls which also act as >> NAT gateways for the internal servers. >> >> On the active front end proxy we've started seeing "fatal: socket: No buffer >> space available" errors during high-peak times. I can see in vmstat -z >> that this is what is getting denied: >> >> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP >> tcp_inpcb: 392, 32770, 19398, 13372,1449734621,6312858, 0 >> >> We've got a lot of the other values bumped, and it appears to be this input >> limit that is getting hit. There are no other non-zero FAILed counters >> except 64 and 128 buckets which I believe are normal. >> >> I cannot seem to find the sysctl (or equiv) that controls this limit though, >> or even what it is. Anyone know? >> >> I'm obviously in need of this specific answer, but overall is there a codex >> of vmstat -z's items that explains this that I have just not found in my >> searches? This isn't the first time I've had to dig into a value like this >> to increase it's limit, but this time I'm not turning anything up. >> >> Any thoughts/ideas appreciated! >> >> -- >> Adam Strohl >> http://www.ateamsystems.com/ >> >> _______________________________________________ >> 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" -- Adam Strohl http://www.ateamsystems.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 16:32:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D57D4452; Tue, 30 Oct 2012 16:32:20 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 80CAD8FC0C; Tue, 30 Oct 2012 16:32:20 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so586025oag.13 for ; Tue, 30 Oct 2012 09:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2w8QlAmK5b45KpTj1SG8DFbC6fRVm+GCNyXtPtTNyfo=; b=YqWq3wZYV6EVbCwrDfQ5LMiwTvCV1kxwf1D1vAJJyxnmq9wVE/wc4DTnVATJjCZt0x n5hzwCZUGyKuEx9b6s7eUiHirPgsJr7zZN1BWBo3myMAl0khGJlzfRKdgmktQ8hpHbAC fbV27Ec6Ga6Cfu0jg3iI9erc7hitlwDxMqtGOyfjGbDHwj13LK5qwcIFitrw+p735vMA LpPXrWJimGGZQTsVCPkY0Obt33qK0Pvl5dwS0Nsn+xzbBFvIxA+V67GASKoUGaBEtvBF jYH31Jc1G8de6pyI+xEFKueJVl3SkMlH8XjfWQu8gI44acEcP5NhLj71R7nqqcgwS367 6ljg== MIME-Version: 1.0 Received: by 10.60.172.171 with SMTP id bd11mr30254011oec.4.1351614740127; Tue, 30 Oct 2012 09:32:20 -0700 (PDT) Received: by 10.76.170.36 with HTTP; Tue, 30 Oct 2012 09:32:20 -0700 (PDT) In-Reply-To: <20121030160804.GB1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> Date: Tue, 30 Oct 2012 17:32:20 +0100 Message-ID: Subject: Re: make release fails on find From: Andreas Nilsson To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:32:20 -0000 On Tue, Oct 30, 2012 at 5:08 PM, Glen Barber wrote: > On Tue, Oct 30, 2012 at 04:58:52PM +0100, Andreas Nilsson wrote: > > I'm trying to build some images for 9-stable ( r242349 ) and 9.1-RC3, b= ut > > using the release tools doesn't really work. > > > > 9.1-RC3 fails with: > > ... > > cd /tank/cvs/9.1/src/libexec/rtld-elf; make install -DNO_SUBDIR > > DESTDIR=3D/tmp/newdist/lib32 SHARED=3Dcopies > > install -s -o root -g wheel -m 555 -C -b -fschg -S ld-elf32.so.1 > > /tmp/newdist/lib32/libexec > > /tmp/newdist/lib32/usr/libexec/ld-elf32.so.1 -> /libexec/ld-elf32.so.1 > > cd /tank/cvs/9.1/src/usr.bin/ldd; PROG=3Dldd32 MACHINE=3Di386 > MACHINE_ARCH=3Di386 > > MACHINE_CPU=3D"i686 mmx sse sse2" LD=3D"ld -m elf_i386_fbsd -Y > > P,/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32" AS=3D"as --32" > > MAKEOBJDIRPREFIX=3D/usr/obj/lib32 > > _SHLIBDIRPREFIX=3D/usr/obj/tank/cvs/9.1/src/lib32 VERSION=3D"FreeBSD > > 9.1-PRERELEASE amd64 901501" > > > PATH=3D/usr/obj/tank/cvs/9.1/src/tmp/legacy/usr/sbin:/usr/obj/tank/cvs/9.= 1/src/tmp/legacy/usr/bin:/usr/obj/tank/cvs/9.1/src/tmp/legacy/usr/games:/us= r/obj/tank/cvs/9.1/src/tmp/usr/sbin:/usr/obj/tank/cvs/9.1/src/tmp/usr/bin:/= usr/obj/tank/cvs/9.1/src/tmp/usr/games:/usr/obj/tank/cvs/9.1/src/tmp/legacy= /usr/sbin:/usr/obj/tank/cvs/9.1/src/tmp/legacy/usr/bin:/usr/obj/tank/cvs/9.= 1/src/tmp/legacy/usr/games:/usr/obj/tank/cvs/9.1/src/tmp/usr/sbin:/usr/obj/= tank/cvs/9.1/src/tmp/usr/bin:/usr/obj/tank/cvs/9.1/src/tmp/usr/games:/tmp/i= nstall.SgiYOaRS > > CC=3D"cc -m32 -march=3Dcore2 -DCOMPAT_32BIT -isystem > > /usr/obj/tank/cvs/9.1/src/lib32/usr/include/ > > -L/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32 > > -B/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32" CXX=3D"c++ -m32 -march=3D= core2 > > -DCOMPAT_32BIT -isystem /usr/obj/tank/cvs/9.1/src/lib32/usr/include/ > > -L/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32 > > -B/usr/obj/tank/cvs/9.1/src/lib32/usr/lib32" LIBDIR=3D/usr/lib32 > > SHLIBDIR=3D/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIN= D > > -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -EC= XX > > -EAS -ELD -DNO_INCS distribute > > cd /tank/cvs/9.1/src/usr.bin/ldd; make install -DNO_SUBDIR > > DESTDIR=3D/tmp/newdist/lib32 SHARED=3Dcopies > > install -s -o root -g wheel -m 555 ldd32 /tmp/newdist/lib32/usr/bin > > find //tmp/newdist/doc -empty -delete > > find //tmp/newdist/games -empty -delete > > find: -delete: //tmp/newdist/games: relative path potentially not safe > > *** [distributeworld] Error code 1 > > > > Stop in /tank/cvs/9.1/src. > > *** [distributeworld] Error code 1 > > > > Are you defining WITH*_GAMES in src.conf or make.conf? If this looks > like what I think it looks like, I fixed this a few months ago. > Used same command for building both, see below. And yes, WITHOUT_GAMES is set in src.conf > > And 9-stable ends up recursing when generating tarballs. The sources ha= ve > > already been added to a tarball. The tarballs themselfs are also > included. > > > > I have seen many reports on this, and cannot reproduce it. How exactly > are you running the release build? What specific make(1) targets are > you using, and what is your make.conf/src.conf contents? > > Glen > > I did the following steps: zfs create tank/cvs/9 zfs create tank/cvs/9/src zfs create tank/cvs/9.1 zfs create tank/cvs/9.1/src cd /tank/cvs/9/src ; sudo svn co http://svn0.us-east.freebsd.org/base/releng/9 . cd /tank/cvs/9.1/src ; sudo svn co http://svn0.us-east.freebsd.org/base/releng/9.1 . cd /tank/cvs/9/src ; sudo make SRCCONF=3D/relng/files/src.conf buildworld buildkernel -sj16 cd /tank/cvs/9.1/src ; sudo make SRCCONF=3D/relng/files/src.conf buildworld buildkernel -sj16 cd /tank/cvs/9/src ; sudo make SRCCONF=3D/relng/files/src.conf -C release cdrom cd /tank/cvs/9.1/src ; sudo make SRCCONF=3D/relng/files/src.conf -C release cdrom /relng/files/src.conf contains: $ cat /relng/files/src.conf WITHOUT_X11=3Dtrue WITHOUT_BLUETOOTH=3Dtrue WITHOUT_CLANG=3Dtrue WITHOUT_ATM=3Dtrue WITHOUT_CTM=3Dtrue WITHOUT_CDDL=3Dtrue WITHOUT_DICT=3Dtrue WITHOUT_HTML=3Dtrue WITHOUT_IPFILTER=3Dtrue WITHOUT_IPX=3Dtrue WITHOUT_IPX_SUPPORT=3Dtrue WITHOUT_LOCALES=3Dtrue WITHOUT_LPR=3Dtrue WITHOUT_NCP=3Dtrue WITHOUT_NIS=3Dtrue WITHOUT_OBJC=3Dtrue WITHOUT_RCMDS=3Dtrue WITHOUT_RCS=3Dtrue WITHOUT_SENDMAIL=3Dtrue WITHOUT_SSP=3Dtrue WITHOUT_ZFS=3Dtrue WITHOUT_BIND_DNSSEC=3Dtrue WITHOUT_GAMES=3Dtrue WITHOUT_IPX=3Dtrue WITHOUT_NIS=3Dtrue WITHOUT_PF=3Dtrue WITHOUT_SENDMAIL=3Dtrue WITHOUT_WIRELESS=3Dtrue make.conf contains: $ cat /etc/make.conf CPUTYPE?=3Dcore2 CFLAGS=3D-pipe -O2 BUILD_JOBS=3D"8" WITHOUT_SENDMAIL=3Dtrue WITHOUT_X11=3Dtrue DISTDIR=3D/tank/distfiles WRKDIRPREFIX?=3D/tmp/ports PACKAGES?=3D/tmp/ports/packages # WITH_KMS=3Dyes WITH_NEW_XORG=3Dyes # added by use.perl 2012-10-15 17:24:41 PERL_VERSION=3D5.14.2 Some of the stuff there could be removed I guess... Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 17:05:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9B231CA for ; Tue, 30 Oct 2012 17:05:33 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8585D8FC12 for ; Tue, 30 Oct 2012 17:05:32 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so357397pbb.13 for ; Tue, 30 Oct 2012 10:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4123lskdGGv5NMNNDqOqyfpDRBXQCae95+uP5Lf7EVI=; b=K0OnOpnitM19lSas49VX9Lte/60UgJm9JLpaDyNJjy/9TgQTb0ueC7RY1hkeDvXb0j bSIS+JP+LD53C23wermtI9zSx3Rm37udnXUqYh/jPsLH4GFajMo7EhyMwwNs350wsltk eXXTtjC3sFAsOLFI97sWd6hLt3r2oqYMN2LUUnSg28Y2oEFUyxs2PnNZkiUvKqZkyXC6 cmVAryXG/uNYjRUeCKMC104gHdEDJziT/274b1uugQxXxO9Rw6PTpb9HpqW+DmPLDCwM 18/IDDsNOIIYgxPaRuzYIqD6r152CP297/rNp+j7jc6YTMD2AlsY6tw1EMrZZM8cC4/P AgjA== Received: by 10.68.221.225 with SMTP id qh1mr104650603pbc.50.1351616732169; Tue, 30 Oct 2012 10:05:32 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id kv9sm812177pbc.34.2012.10.30.10.05.30 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 10:05:30 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <509008D9.2090006@FreeBSD.org> Date: Tue, 30 Oct 2012 10:05:29 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121012 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adam Strohl Subject: Re: No buffer space available / tcp_inpcb value References: <508FD46D.3040608@ateamsystems.com> In-Reply-To: <508FD46D.3040608@ateamsystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Stable ML X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:05:33 -0000 On 10/30/12 06:21, Adam Strohl wrote: > Hey -STABLE, > > I've got a client who we've setup a FreeBSD cluster for with about a > dozens servers, all behind two front end proxies/LBs/firewalls which > also act as NAT gateways for the internal servers. > > On the active front end proxy we've started seeing "fatal: socket: No > buffer space available" errors during high-peak times. I can see in > vmstat -z that this is what is getting denied: > > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > tcp_inpcb: 392, 32770, 19398, 13372,1449734621,6312858, 0 > > We've got a lot of the other values bumped, and it appears to be this > input limit that is getting hit. There are no other non-zero FAILed > counters except 64 and 128 buckets which I believe are normal. > > I cannot seem to find the sysctl (or equiv) that controls this limit > though, or even what it is. Anyone know? kern.ipc.maxsockets controls this limit. See in_pcbinfo_init() for details. Regards, Navdeep From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 17:07:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2E045B2 for ; Tue, 30 Oct 2012 17:07:00 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C5C4E8FC16 for ; Tue, 30 Oct 2012 17:07:00 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id 3A2131A3C20 for ; Tue, 30 Oct 2012 10:06:59 -0700 (PDT) Message-ID: <5090096B.5070405@mu.org> Date: Tue, 30 Oct 2012 10:07:55 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: tmpfs nfs exports? References: <508FA008.2040503@mu.org> <20121030153142.GA21003@dan.emsphone.com> In-Reply-To: <20121030153142.GA21003@dan.emsphone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:07:01 -0000 On 10/30/12 8:31 AM, Dan Nelson wrote: > In the last episode (Oct 30), jb said: >> Alfred Perlstein mu.org> writes: >>> Hey folks, any reason why not to include the following patch in 9.1? It >>> would be nice to have tmpfs be exportable. >>> >>> I'm good to commit it, I can also wait until post 9.1. >>> ... >> How do you identify tmpfs ? With fsid ? >> >> Since nfs server is stateless, are these exports identical ? >> export /tmp, reboot, export /tmp >> >> What about /tmp on tmpfs ? >> export /tmp, reboot, export /tmp > I wanted to do the exact same thing a few years ago. I patched mdmfs and > the startup scripts to allow for an fsid value to be passed to mdmfs on > every reboot. That works for the filesystem itself, but then you have to > contend with the random NFS generation number on every inode. I decided it > wasn't worth the trouble at that point. > > If you really want an exportable /tmp, just live with the fact that you'll > get ESTALE errors on all clients when you reboot the server. Maybe giving > the root inode a constant generation number is all that's needed, since I > suppose most clients that have mounted the server don't actually have any > open filehandles. > Ah, that is troublesome. This fix is really just for benchmarking nfs without hitting disk and other very temporary measures. It would be nice to make root inode predictable in some manner. -Alfred From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 17:09:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7716D799; Tue, 30 Oct 2012 17:09:22 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 4710C8FC0A; Tue, 30 Oct 2012 17:09:22 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 3690723F645; Tue, 30 Oct 2012 13:09:19 -0400 (EDT) Date: Tue, 30 Oct 2012 13:09:16 -0400 From: Glen Barber To: Andreas Nilsson Subject: Re: make release fails on find Message-ID: <20121030170916.GD1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9UV9rz0O2dU/yYYn" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:09:22 -0000 --9UV9rz0O2dU/yYYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 30, 2012 at 05:32:20PM +0100, Andreas Nilsson wrote: > > Are you defining WITH*_GAMES in src.conf or make.conf? If this looks > > like what I think it looks like, I fixed this a few months ago. > > >=20 > Used same command for building both, see below. And yes, WITHOUT_GAMES is > set in src.conf >=20 >=20 > > > And 9-stable ends up recursing when generating tarballs. The sources = have > > > already been added to a tarball. The tarballs themselfs are also > > included. > > > > > > > I have seen many reports on this, and cannot reproduce it. How exactly > > are you running the release build? What specific make(1) targets are > > you using, and what is your make.conf/src.conf contents? > > > > Glen > > > > > I did the following steps: > zfs create tank/cvs/9 > zfs create tank/cvs/9/src > zfs create tank/cvs/9.1 > zfs create tank/cvs/9.1/src > cd /tank/cvs/9/src ; sudo svn co > http://svn0.us-east.freebsd.org/base/releng/9 . > cd /tank/cvs/9.1/src ; sudo svn co > http://svn0.us-east.freebsd.org/base/releng/9.1 . > cd /tank/cvs/9/src ; sudo make SRCCONF=3D/relng/files/src.conf buildworld > buildkernel -sj16 > cd /tank/cvs/9.1/src ; sudo make SRCCONF=3D/relng/files/src.conf buildwor= ld > buildkernel -sj16 > cd /tank/cvs/9/src ; sudo make SRCCONF=3D/relng/files/src.conf -C release > cdrom > cd /tank/cvs/9.1/src ; sudo make SRCCONF=3D/relng/files/src.conf -C relea= se > cdrom >=20 > /relng/files/src.conf contains: > $ cat /relng/files/src.conf > WITHOUT_X11=3Dtrue > WITHOUT_BLUETOOTH=3Dtrue > WITHOUT_CLANG=3Dtrue > WITHOUT_ATM=3Dtrue > WITHOUT_CTM=3Dtrue > WITHOUT_CDDL=3Dtrue > WITHOUT_DICT=3Dtrue > WITHOUT_HTML=3Dtrue > WITHOUT_IPFILTER=3Dtrue > WITHOUT_IPX=3Dtrue > WITHOUT_IPX_SUPPORT=3Dtrue > WITHOUT_LOCALES=3Dtrue > WITHOUT_LPR=3Dtrue > WITHOUT_NCP=3Dtrue > WITHOUT_NIS=3Dtrue > WITHOUT_OBJC=3Dtrue > WITHOUT_RCMDS=3Dtrue > WITHOUT_RCS=3Dtrue > WITHOUT_SENDMAIL=3Dtrue > WITHOUT_SSP=3Dtrue > WITHOUT_ZFS=3Dtrue > WITHOUT_BIND_DNSSEC=3Dtrue > WITHOUT_GAMES=3Dtrue > WITHOUT_IPX=3Dtrue > WITHOUT_NIS=3Dtrue > WITHOUT_PF=3Dtrue > WITHOUT_SENDMAIL=3Dtrue > WITHOUT_WIRELESS=3Dtrue >=20 > make.conf contains: > $ cat /etc/make.conf > CPUTYPE?=3Dcore2 > CFLAGS=3D-pipe -O2 > BUILD_JOBS=3D"8" > WITHOUT_SENDMAIL=3Dtrue > WITHOUT_X11=3Dtrue > DISTDIR=3D/tank/distfiles > WRKDIRPREFIX?=3D/tmp/ports > PACKAGES?=3D/tmp/ports/packages > # > WITH_KMS=3Dyes > WITH_NEW_XORG=3Dyes > # added by use.perl 2012-10-15 17:24:41 > PERL_VERSION=3D5.14.2 >=20 I don't really see any reason this should not work. However, I have not tested with sudo. Maybe that is the piece of the puzzle I am missing... Glen --9UV9rz0O2dU/yYYn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQkAm8AAoJEFJPDDeguUajtcsH/07HADmIGljZ1VqF4hXQsfuL jH4E80oDBD2t1559WVkI5xY7GECoAhK7sUisVw3Y2ujjNphMlefMLoGsVLtGbSX9 OES0iQO3TwN9l8KuRgcZCAJyfYXOKUzNPiSmBn1MJ84+9fiNsvklJaW0Jl5GIBjW aTXsXNahWn0NiY/ZIWX3uw2fVZnqmD15qTCoF3yJCGKPT8+NJnS4ClKAcLyw7L/+ U0Mfo+9J2P7QikW0BIm8DHLFZMFfzT3+4+aaNIWodY9ILZ3+VoXSrTldbp1D2/lj 3ifopz5o4QJXs/uGxy0StoU9yqsogPd0VnJxlB9hfhf6zVBDUUUU8RArScAZZAQ= =KJAj -----END PGP SIGNATURE----- --9UV9rz0O2dU/yYYn-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 17:44:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D984FB0; Tue, 30 Oct 2012 17:44:40 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6508FC08; Tue, 30 Oct 2012 17:44:39 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id D3D651A3C1C; Tue, 30 Oct 2012 10:44:38 -0700 (PDT) Message-ID: <5090123F.90105@mu.org> Date: Tue, 30 Oct 2012 10:45:35 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Navdeep Parhar Subject: Re: No buffer space available / tcp_inpcb value References: <508FD46D.3040608@ateamsystems.com> <509008D9.2090006@FreeBSD.org> In-Reply-To: <509008D9.2090006@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Stable ML , Adam Strohl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:44:40 -0000 How much memory is in this machine? maxsockets is in turn clipped by "nmbclusters" which is in turn clipped by "maxusers" which is limited to 384 MAXIMUM unless you're running -CURRENT. On 10/30/12 10:05 AM, Navdeep Parhar wrote: > On 10/30/12 06:21, Adam Strohl wrote: >> Hey -STABLE, >> >> I've got a client who we've setup a FreeBSD cluster for with about a >> dozens servers, all behind two front end proxies/LBs/firewalls which >> also act as NAT gateways for the internal servers. >> >> On the active front end proxy we've started seeing "fatal: socket: No >> buffer space available" errors during high-peak times. I can see in >> vmstat -z that this is what is getting denied: >> >> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP >> tcp_inpcb: 392, 32770, 19398, >> 13372,1449734621,6312858, 0 >> >> We've got a lot of the other values bumped, and it appears to be this >> input limit that is getting hit. There are no other non-zero FAILed >> counters except 64 and 128 buckets which I believe are normal. >> >> I cannot seem to find the sysctl (or equiv) that controls this limit >> though, or even what it is. Anyone know? > > kern.ipc.maxsockets controls this limit. See in_pcbinfo_init() for > details. > > Regards, > Navdeep > _______________________________________________ > 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-stable@FreeBSD.ORG Tue Oct 30 19:39:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8361FAF for ; Tue, 30 Oct 2012 19:39:27 +0000 (UTC) (envelope-from 538c.21f827a0@vmail17.mynewsletterbuilder.com) Received: from vmail17.mynewsletterbuilder.com (vmail17.mynewsletterbuilder.com [208.83.141.25]) by mx1.freebsd.org (Postfix) with ESMTP id 503848FC16 for ; Tue, 30 Oct 2012 19:39:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mynewsletterbuilder.com; s=dknewsletter; t=1351625966; bh=h+nzQpr5tVc9DLuUGI/cVAIJUtk=; h=Date:From:Reply-To:To:Subject:Message-ID:List-Unsubscribe: Content-Type:MIME-Version; b=t2Nz8nzEq+n875qhvnO1gS5AGjFGkwggKy19K9BgeutcEUeZ2T/ni6cdVD0xxInf2 TjZONqadnyIag5Nk7zpEqfitNFevwh1TIM1Dx/3Yl1OyWSPc8CvPnHjK5EPCfQ9BSt myUXube9ZIAdS4qNTJKQGDJLJs2V6vUYSa8UbJXg= Date: Tue, 30 Oct 2012 15:39:26 -0400 From: "Dave George" To: Subject: Halloween Weekend Sale Get 15% Off this Weekend Message-ID: <538c.21f827a0.35c2e1e5@vmail17.mynewsletterbuilder.com> X-MNB-TRACKING: YmVhdHNmb3JyYXBwZXJzIDogZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmcgOiA4MTMwNTg2NTMy X-MNB-SENDID: 8130586532 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Dave George List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:39:27 -0000 Halloween Sale - GET 15% OFF USE COUPON CODE "HALL"=C2=A0Brand New | You Asked for it You Got it ! | 100= % Targetted Followers =C2=A0FaceBook Likes | YouTube Views | Twitter Followers : http://promogoons.com/?product=3Dnew-100-targeted-followers 100% Targeted= Followers : http://promogoons.com/?product=3Dnew-100-targeted-followers Ge= t 100% Laser-Targeted Followers . Packages from 1000 to 4000 targeted Follo= wers per month , read more... : http://promogoons.com/?product=3Dnew-100-ta= rgeted-followers : http://promogoons.com/?product=3Dtwitter 10,000 Followe= rs $20 : http://promogoons.com/?product=3Dtwitter Get 10,000 Untargeted Fol= lowers for just $50 . We can help you jumpstart your twitter account , read= more ... : http://promogoons.com/?product=3Dtwitter : http://promogoons.com/?product=3Dyoutube Real Youtube Views : http://prom= ogoons.com/?product=3Dyoutube Need Youtube Views to catch that A&R's eye ? = We have 100% Real Views and are Partner Safe, =C2=A0=C2=A0read more... : ht= tp://promogoons.com/?product=3Dyoutube : http://promogoons.com/?product=3D= facebook FaceBook Likes : http://promogoons.com/?product=3Dfacebook Lets fa= ce it , who doesnt need more facebook likes ? We have what you need , read more ... : http://promogoons.com/?product=3Dfacebook : http://promogoons.com/?product=3Dsoundcloud SoundCloud Plays : http://pro= mogoons.com/?product=3Dsoundcloud Fast , Economical and Fun, Let Us Help yo= u get more Soundcloud plays , read more... : http://promogoons.com/?product= =3Dsoundcloud : http://promogoons.com/?product=3Ddatpiff-plays DatPiff Str= eams : http://promogoons.com/?product=3Ddatpiff-plays Got A Hot Mixtape on = DatPiff ? ? Cant Seem to cut through the wack tapes on the front page ? rea= d more... : http://promogoons.com/?product=3Ddatpiff-plays REPEAT CLIENTS GET 15% OFF |=C2=A0USE COUPON CODE "HALL" ON CHECKOUT Promogoons.com : http://promogoons.com | The Major Label's Dirty Little Se= cret Dave George - 678 508 2941 - sales@promogoons.com : mailto:sales@promogoons= .com=20 Skype | Yahoo | AIM : Promogoons United Promotions - po box 1526 - atlanta - GA - 30316 Subscribe to this newsletter: https://www.mynewsletterbuilder.com/tools/subscription.php?username=3Dbeats= forrappers&send_id=3D8130586532&l=3Ds&newsletter_id=3D1411516624 Unsubscribe freebsd-stable@freebsd.org: https://www.mynewsletterbuilder.com/tools/subscription.php?username=3Dbeats= forrappers&send_id=3D8130586532&l=3Du&email=3Dfreebsd-stable@freebsd.org Change your preferences: https://www.mynewsletterbuilder.com/tools/subscription.php?username=3Dbeats= forrappers&send_id=3D8130586532&l=3Dp&email=3Dfreebsd-stable@freebsd.org Forward to a friend: https://www.mynewsletterbuilder.com/tools/forward.php?username=3Dbeatsforra= ppers&newsletter_id=3D1411516624&send_id=3D8130586532 Report this email as spam: https://www.mynewsletterbuilder.com/tools/abuse_report.php?username=3Dbeats= forrappers&send_id=3D8130586532&email=3Dfreebsd-stable@freebsd.org This email was sent using MyNewsletterBuilder.com. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 22:26:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96C83C65 for ; Tue, 30 Oct 2012 22:26:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 45BE98FC0C for ; Tue, 30 Oct 2012 22:26:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EALdSkFCDaFvO/2dsb2JhbAA6CoYXvleCHgEBAQQBAQEgKyALGw4KAgINGQIpAQkmBggHBAEcBIdlC6ligjuQKYEgimcKhTCBEwOTSIItgRqPKIMLgUg1 X-IronPort-AV: E=Sophos;i="4.80,683,1344225600"; d="scan'208";a="188790917" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 30 Oct 2012 18:26:18 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 56A55B40BC; Tue, 30 Oct 2012 18:26:18 -0400 (EDT) Date: Tue, 30 Oct 2012 18:26:18 -0400 (EDT) From: Rick Macklem To: Dan Nelson Message-ID: <549462524.3083029.1351635978335.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20121030153142.GA21003@dan.emsphone.com> Subject: Re: tmpfs nfs exports? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: jb , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 22:26:20 -0000 Dan Nelson wrote: > In the last episode (Oct 30), jb said: > > Alfred Perlstein mu.org> writes: > > > Hey folks, any reason why not to include the following patch in > > > 9.1? It > > > would be nice to have tmpfs be exportable. > > > > > > I'm good to commit it, I can also wait until post 9.1. > > > ... > > > > How do you identify tmpfs ? With fsid ? > > > > Since nfs server is stateless, are these exports identical ? > > export /tmp, reboot, export /tmp > > > > What about /tmp on tmpfs ? > > export /tmp, reboot, export /tmp > > I wanted to do the exact same thing a few years ago. I patched mdmfs > and > the startup scripts to allow for an fsid value to be passed to mdmfs > on > every reboot. That works for the filesystem itself, but then you have > to > contend with the random NFS generation number on every inode. I > decided it > wasn't worth the trouble at that point. > > If you really want an exportable /tmp, just live with the fact that > you'll > get ESTALE errors on all clients when you reboot the server. Maybe > giving > the root inode a constant generation number is all that's needed, > since I > suppose most clients that have mounted the server don't actually have > any > open filehandles. > Files don't have to be opened, since file handles are in cached NFS vnodes. Basically, when the server reboots, the client mounts will have to be re-done. I think it would be nice if this behaviour of an exported tmpfs was documented, so people don't try and use it for anything other than testing. rick > -- > Dan Nelson > dnelson@allantgroup.com > _______________________________________________ > 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-stable@FreeBSD.ORG Tue Oct 30 22:29:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2A11FC9; Tue, 30 Oct 2012 22:29:26 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5078C8FC08; Tue, 30 Oct 2012 22:29:25 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so701348qcs.13 for ; Tue, 30 Oct 2012 15:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jNzy0mKHUwLnL1qlJiWCC/FGt494eD1SV7ixlnthxC0=; b=hu0Y5D3H2bqiP0reyUedxqv76oFVAmtKylmCTBZAtOIOGdYXkiUPy5WCxUTpHYDHHO IUfEuSOyx8X+/0nxhlZR8ipwILXhDUL46EuIETlN5V4mXrMKIH1Nd61JSTLDAaGs8HzI dxlYeWosI+hU3XN1js1er6qSTbpa76MeZxj6kQb5n+VPuMy+GtDB7CiP4ZCEQ+4cjxf8 XHmZLZL5UDzwGXcu/wj27hmG1aMc8E0FSF+VosasryVAErISNbfM3XTSE+NLIYJf3Hgl h2ORAD5k7E1N6HO6a8BEhJlJxj6WFjvg+QdUdWEylQFv8/chLKxJLe9Fniu6u3RFmt1M 28dw== MIME-Version: 1.0 Received: by 10.229.106.95 with SMTP id w31mr1733486qco.40.1351636165168; Tue, 30 Oct 2012 15:29:25 -0700 (PDT) Received: by 10.229.87.67 with HTTP; Tue, 30 Oct 2012 15:29:25 -0700 (PDT) In-Reply-To: <20121030170916.GD1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> Date: Tue, 30 Oct 2012 23:29:25 +0100 Message-ID: Subject: Re: make release fails on find From: Andreas Nilsson To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 22:29:26 -0000 On Tue, Oct 30, 2012 at 6:09 PM, Glen Barber wrote: > On Tue, Oct 30, 2012 at 05:32:20PM +0100, Andreas Nilsson wrote: > > > Are you defining WITH*_GAMES in src.conf or make.conf? If this looks > > > like what I think it looks like, I fixed this a few months ago. > > > > > > > Used same command for building both, see below. And yes, WITHOUT_GAMES is > > set in src.conf > > > > > > > > And 9-stable ends up recursing when generating tarballs. The sources > have > > > > already been added to a tarball. The tarballs themselfs are also > > > included. > > > > > > > > > > I have seen many reports on this, and cannot reproduce it. How exactly > > > are you running the release build? What specific make(1) targets are > > > you using, and what is your make.conf/src.conf contents? > > > > > > Glen > > > > > > > > I did the following steps: > > zfs create tank/cvs/9 > > zfs create tank/cvs/9/src > > zfs create tank/cvs/9.1 > > zfs create tank/cvs/9.1/src > > cd /tank/cvs/9/src ; sudo svn co > > http://svn0.us-east.freebsd.org/base/releng/9 . > > cd /tank/cvs/9.1/src ; sudo svn co > > http://svn0.us-east.freebsd.org/base/releng/9.1 . > > cd /tank/cvs/9/src ; sudo make SRCCONF=/relng/files/src.conf buildworld > > buildkernel -sj16 > > cd /tank/cvs/9.1/src ; sudo make SRCCONF=/relng/files/src.conf buildworld > > buildkernel -sj16 > > cd /tank/cvs/9/src ; sudo make SRCCONF=/relng/files/src.conf -C release > > cdrom > > cd /tank/cvs/9.1/src ; sudo make SRCCONF=/relng/files/src.conf -C release > > cdrom > > > > /relng/files/src.conf contains: > > $ cat /relng/files/src.conf > > WITHOUT_X11=true > > WITHOUT_BLUETOOTH=true > > WITHOUT_CLANG=true > > WITHOUT_ATM=true > > WITHOUT_CTM=true > > WITHOUT_CDDL=true > > WITHOUT_DICT=true > > WITHOUT_HTML=true > > WITHOUT_IPFILTER=true > > WITHOUT_IPX=true > > WITHOUT_IPX_SUPPORT=true > > WITHOUT_LOCALES=true > > WITHOUT_LPR=true > > WITHOUT_NCP=true > > WITHOUT_NIS=true > > WITHOUT_OBJC=true > > WITHOUT_RCMDS=true > > WITHOUT_RCS=true > > WITHOUT_SENDMAIL=true > > WITHOUT_SSP=true > > WITHOUT_ZFS=true > > WITHOUT_BIND_DNSSEC=true > > WITHOUT_GAMES=true > > WITHOUT_IPX=true > > WITHOUT_NIS=true > > WITHOUT_PF=true > > WITHOUT_SENDMAIL=true > > WITHOUT_WIRELESS=true > > > > make.conf contains: > > $ cat /etc/make.conf > > CPUTYPE?=core2 > > CFLAGS=-pipe -O2 > > BUILD_JOBS="8" > > WITHOUT_SENDMAIL=true > > WITHOUT_X11=true > > DISTDIR=/tank/distfiles > > WRKDIRPREFIX?=/tmp/ports > > PACKAGES?=/tmp/ports/packages > > # > > WITH_KMS=yes > > WITH_NEW_XORG=yes > > # added by use.perl 2012-10-15 17:24:41 > > PERL_VERSION=5.14.2 > > > > I don't really see any reason this should not work. However, I have not > tested with sudo. Maybe that is the piece of the puzzle I am missing... > > Glen > > Hmm, interesting idea, would be pretty bad if sudo caused that. I gave it run without direct sudo call ( ie sudo bash, then make ... ) and no go. Doing just su - and cd'ing to proper dir and the make ... is still not working. Overnight I'll try to build world and kernel without src.conf ( ie SRCCONF=/dev/null ) and same for make release. I'll posts results in the morning. Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 23:11:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9115D9B9; Tue, 30 Oct 2012 23:11:23 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2C87A8FC0A; Tue, 30 Oct 2012 23:11:22 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so726298qcs.13 for ; Tue, 30 Oct 2012 16:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U0c7II7FWy4NDnaQoG2rizV8Os7dcl4f7Sbg7A4jFBo=; b=WHCYFt5oVfCyVkOOJRsjmQaENw7fSFTOq6CJ5y2+5TNOjZbf82VUMyyhFSm0zSho/E dqLlOK7QtEpgVcwi+RQ6JYfrgGWxa1j2lxzjsql8fz5CCCT95Mr3/Eh+umYD9djYZkVX JDr7ytjZhP5V0Ee94prleUo6Xm206Qy7FyZ+dqNfRP18uf6w3ZSBE3LQwTB9/yJkhF60 JFqlWfaK8pVKT/qLwoSSOFcArhQ/0RYnW8ioXHYEBrkOJly6TkX8/LxRjQGpy87vuZTS Xvm7VcCHqMCK8HwrXqyCxpyg3vE6sFGEOYmL43XQN+ykjwtR+R67zc3Ovld5ovi/hV7W uzSg== MIME-Version: 1.0 Received: by 10.49.87.230 with SMTP id bb6mr27186307qeb.18.1351638682258; Tue, 30 Oct 2012 16:11:22 -0700 (PDT) Received: by 10.229.87.67 with HTTP; Tue, 30 Oct 2012 16:11:22 -0700 (PDT) In-Reply-To: References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> Date: Wed, 31 Oct 2012 00:11:22 +0100 Message-ID: Subject: Re: make release fails on find From: Andreas Nilsson To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 23:11:23 -0000 On Tue, Oct 30, 2012 at 11:29 PM, Andreas Nilsson wrote: > > > On Tue, Oct 30, 2012 at 6:09 PM, Glen Barber wrote: > >> On Tue, Oct 30, 2012 at 05:32:20PM +0100, Andreas Nilsson wrote: >> > > Are you defining WITH*_GAMES in src.conf or make.conf? If this looks >> > > like what I think it looks like, I fixed this a few months ago. >> > > >> > >> > Used same command for building both, see below. And yes, WITHOUT_GAMES >> is >> > set in src.conf >> > >> > >> > > > And 9-stable ends up recursing when generating tarballs. The >> sources have >> > > > already been added to a tarball. The tarballs themselfs are also >> > > included. >> > > > >> > > >> > > I have seen many reports on this, and cannot reproduce it. How >> exactly >> > > are you running the release build? What specific make(1) targets are >> > > you using, and what is your make.conf/src.conf contents? >> > > >> > > Glen >> > > >> > > >> > I did the following steps: >> > zfs create tank/cvs/9 >> > zfs create tank/cvs/9/src >> > zfs create tank/cvs/9.1 >> > zfs create tank/cvs/9.1/src >> > cd /tank/cvs/9/src ; sudo svn co >> > http://svn0.us-east.freebsd.org/base/releng/9 . >> > cd /tank/cvs/9.1/src ; sudo svn co >> > http://svn0.us-east.freebsd.org/base/releng/9.1 . >> > cd /tank/cvs/9/src ; sudo make SRCCONF=/relng/files/src.conf buildworld >> > buildkernel -sj16 >> > cd /tank/cvs/9.1/src ; sudo make SRCCONF=/relng/files/src.conf >> buildworld >> > buildkernel -sj16 >> > cd /tank/cvs/9/src ; sudo make SRCCONF=/relng/files/src.conf -C release >> > cdrom >> > cd /tank/cvs/9.1/src ; sudo make SRCCONF=/relng/files/src.conf -C >> release >> > cdrom >> > >> > /relng/files/src.conf contains: >> > $ cat /relng/files/src.conf >> > WITHOUT_X11=true >> > WITHOUT_BLUETOOTH=true >> > WITHOUT_CLANG=true >> > WITHOUT_ATM=true >> > WITHOUT_CTM=true >> > WITHOUT_CDDL=true >> > WITHOUT_DICT=true >> > WITHOUT_HTML=true >> > WITHOUT_IPFILTER=true >> > WITHOUT_IPX=true >> > WITHOUT_IPX_SUPPORT=true >> > WITHOUT_LOCALES=true >> > WITHOUT_LPR=true >> > WITHOUT_NCP=true >> > WITHOUT_NIS=true >> > WITHOUT_OBJC=true >> > WITHOUT_RCMDS=true >> > WITHOUT_RCS=true >> > WITHOUT_SENDMAIL=true >> > WITHOUT_SSP=true >> > WITHOUT_ZFS=true >> > WITHOUT_BIND_DNSSEC=true >> > WITHOUT_GAMES=true >> > WITHOUT_IPX=true >> > WITHOUT_NIS=true >> > WITHOUT_PF=true >> > WITHOUT_SENDMAIL=true >> > WITHOUT_WIRELESS=true >> > >> > make.conf contains: >> > $ cat /etc/make.conf >> > CPUTYPE?=core2 >> > CFLAGS=-pipe -O2 >> > BUILD_JOBS="8" >> > WITHOUT_SENDMAIL=true >> > WITHOUT_X11=true >> > DISTDIR=/tank/distfiles >> > WRKDIRPREFIX?=/tmp/ports >> > PACKAGES?=/tmp/ports/packages >> > # >> > WITH_KMS=yes >> > WITH_NEW_XORG=yes >> > # added by use.perl 2012-10-15 17:24:41 >> > PERL_VERSION=5.14.2 >> > >> >> I don't really see any reason this should not work. However, I have not >> tested with sudo. Maybe that is the piece of the puzzle I am missing... >> >> Glen >> >> > Hmm, > > interesting idea, would be pretty bad if sudo caused that. > > I gave it run without direct sudo call ( ie sudo bash, then make ... ) and > no go. > > Doing just su - and cd'ing to proper dir and the make ... is still not > working. > > Overnight I'll try to build world and kernel without src.conf ( ie > SRCCONF=/dev/null ) and same for make release. I'll posts results in the > morning. > > Best regards > Andreas > Just a quick update; running a new buildworld+buildkernel and then make release from su - does not work :( Regards Andreas From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 23:14:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9038CADA; Tue, 30 Oct 2012 23:14:19 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 537F98FC0C; Tue, 30 Oct 2012 23:14:19 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 4C0DA23F645; Tue, 30 Oct 2012 19:14:15 -0400 (EDT) Date: Tue, 30 Oct 2012 19:14:12 -0400 From: Glen Barber To: Andreas Nilsson Subject: Re: make release fails on find Message-ID: <20121030231412.GE1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M/SuVGWktc5uNpra" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 23:14:19 -0000 --M/SuVGWktc5uNpra Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 12:11:22AM +0100, Andreas Nilsson wrote: > > interesting idea, would be pretty bad if sudo caused that. > > Indeed, but sudo only keeps certain environment variables, so it's not entirely unexpected if this is the case. > > I gave it run without direct sudo call ( ie sudo bash, then make ... ) = and > > no go. > > > > Doing just su - and cd'ing to proper dir and the make ... is still not > > working. > > > > Overnight I'll try to build world and kernel without src.conf ( ie > > SRCCONF=3D/dev/null ) and same for make release. I'll posts results in = the > > morning. > > > > Best regards > > Andreas > > >=20 > Just a quick update; running a new buildworld+buildkernel and then make > release from su - does not work :( >=20 You've said 'does not work' twice. Can you elaborate more? What specifically isn't working? Same behavior as before, or...? Glen --M/SuVGWktc5uNpra Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQkF9EAAoJEFJPDDeguUajG64H/3iAYRFRaivAKErsIbsIcSWw IM+j8yz4ZfSonoDiR04I3lW3nOITA0nwDdUCxExXXw2dLKh0SKlksgGKm4qkzsBt l/0pA/G3jOnyWwcdjHSgwlX5vc2wJM7vZtZkFu5GxWgwMTk5zH+hQA9eF8RdC6rI FciE7kXc6jV+IxCUGi0bKbeyC0e3vChmPnYhEcp+zYvj4jB2QNXyp1VZvUn1RTJw 4IHyuSsNqDCRUaGJwR7xpIQoPSWBZKLeQBoReKwSzESIcC7eoWMfiUs5o+cAN41h vQ9przmobt/ZCaQq/f0MvM7uk/rWz3EADlCbHVIKHpo7k1HUCH6kor3cX4dTiCs= =Lw/f -----END PGP SIGNATURE----- --M/SuVGWktc5uNpra-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 30 23:33:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE924D2E; Tue, 30 Oct 2012 23:33:34 +0000 (UTC) (envelope-from steven_nikkel@ertyu.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4588FC08; Tue, 30 Oct 2012 23:33:34 +0000 (UTC) Received: from pd2ml3so-ssvc.prod.shaw.ca ([10.0.141.148]) by pd3mo1so-svcs.prod.shaw.ca with ESMTP; 30 Oct 2012 17:33:28 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=SNukfclIDc7GjKe+LHtSoPUBJt/gHPuqMk7EpfoOdzs= c=1 sm=1 a=1fWRePjM8PAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=gn0rv3KfuWpWgkKhuBHlTQ==:17 a=Egj1SV_zNB3GBmTDU5UA:9 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO ertyu.org) ([24.79.195.167]) by pd2ml3so-dmz.prod.shaw.ca with ESMTP; 30 Oct 2012 17:33:28 -0600 Date: Tue, 30 Oct 2012 18:33:27 -0500 (CDT) From: Steven Nikkel To: Andriy Gapon Subject: Re: CPU Competition Issue In-Reply-To: <508F9671.3060501@FreeBSD.org> Message-ID: References: <508F9671.3060501@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 23:33:34 -0000 On Tue, 30 Oct 2012, Andriy Gapon wrote: >> I'm running a long duration CPU-centric process that will gobble up all >> available CPU time. I have it set to run at nice +20. While it's running I've >> noticed other processes have a hard time getting CPU time and run their >> activites very slowly. The processes I've noticed issues with are IO involved, >> but they don't appear to be IO blocked as they run dramatically faster and use >> much more CPU time when the CPU intensive process is not running. I haven't >> noticed issues with other processes, but I haven't been looking. If I push my >> CPU intensive process into idle priority 1, all the other processes return to >> their normal behaviour as if it's not running. >> >> This seems to be a specific behaviour on this one machine running 9.0-RELEASE-p4 >> on an Atom 330 dual core. I've tried with and without hyperthreading enabled >> with no noticeable change in behaviour. > > Can you try with lower nice value, like +10? > You want a fix from r228718. AFAIR, it is not in 9.0. > They seem to share in a much more reasonable manor after assigning the process to +10 instead of +20, which sounds like the fix you mentioned. The process hits priorities in the 120s when its competing. I think I'll continue with idle priority as that obtains the sharing behaviour I'm after. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 00:08:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D66E346; Wed, 31 Oct 2012 00:08:15 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id EC32F8FC12; Wed, 31 Oct 2012 00:08:14 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so757248qcs.13 for ; Tue, 30 Oct 2012 17:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HnENvdQFp3zZDbWTF9g9BgSvzlEpTvCm264WKE3CqVE=; b=rpXSUNcGjrWIN3ndFF8ANEp7XTNW+J8KkcEwro4pJaP8YAZFh5skcroQ0HlyQUCWV3 e3wLdjdVwkz7xjNBZDkI+l0fQKF9EWLP1U3mh29XdVgxSmzZpmKozDLZZFJ9uP1B//nM xTfCuBBbeo11xxlyhZ7P7FaGdBL+y3YoCNuAEanzdEs3maXNgrpQCOHLZjw8rOzODqWP 8NXSHnRaiGkeng4AD7RHbvYmF6W51137PgTL7BiLLx2J/gAA5vchyi/YJwQcyYU7eBgI jOVfreRWOac9vE2O8u35go/zQOFtBSEo2WkdN2H6iTv3AIkns/sp/5okM8A/a5g/1NAV yGVw== MIME-Version: 1.0 Received: by 10.224.174.70 with SMTP id s6mr18836841qaz.60.1351642093952; Tue, 30 Oct 2012 17:08:13 -0700 (PDT) Received: by 10.229.87.67 with HTTP; Tue, 30 Oct 2012 17:08:13 -0700 (PDT) In-Reply-To: <20121030231412.GE1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> Date: Wed, 31 Oct 2012 01:08:13 +0100 Message-ID: Subject: Re: make release fails on find From: Andreas Nilsson To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 00:08:15 -0000 On Wed, Oct 31, 2012 at 12:14 AM, Glen Barber wrote: > On Wed, Oct 31, 2012 at 12:11:22AM +0100, Andreas Nilsson wrote: > > > interesting idea, would be pretty bad if sudo caused that. > > > > > Indeed, but sudo only keeps certain environment variables, so it's not > entirely unexpected if this is the case. > > > > I gave it run without direct sudo call ( ie sudo bash, then make ... ) > and > > > no go. > > > > > > Doing just su - and cd'ing to proper dir and the make ... is still not > > > working. > > > > > > Overnight I'll try to build world and kernel without src.conf ( ie > > > SRCCONF=/dev/null ) and same for make release. I'll posts results in > the > > > morning. > > > > > > Best regards > > > Andreas > > > > > > > Just a quick update; running a new buildworld+buildkernel and then make > > release from su - does not work :( > > > > You've said 'does not work' twice. Can you elaborate more? What > specifically isn't working? Same behavior as before, or...? > > Glen > > Oops, my bad. Yes exact same behavior; make -C release cdrom fails with ... find //tank/cvs/9.1/src/release/dist/doc -empty -delete find //tank/cvs/9.1/src/release/dist/games -empty -delete find: -delete: //tank/cvs/9.1/src/release/dist/games: relative path potentially not safe *** [distributeworld] Error code 1 on 9.1-RC3. I can try with 9-stable as well (tomorrow). Regards Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 00:11:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 189B3480; Wed, 31 Oct 2012 00:11:19 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id CE3648FC12; Wed, 31 Oct 2012 00:11:18 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id BCB1B23F645; Tue, 30 Oct 2012 20:11:17 -0400 (EDT) Date: Tue, 30 Oct 2012 20:11:15 -0400 From: Glen Barber To: Andreas Nilsson Subject: Re: make release fails on find Message-ID: <20121031001115.GF1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="w3uUfsyyY1Pqa/ej" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 00:11:19 -0000 --w3uUfsyyY1Pqa/ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 01:08:13AM +0100, Andreas Nilsson wrote: > On Wed, Oct 31, 2012 at 12:14 AM, Glen Barber wrote: >=20 > > On Wed, Oct 31, 2012 at 12:11:22AM +0100, Andreas Nilsson wrote: > > > > interesting idea, would be pretty bad if sudo caused that. > > > > > > > > Indeed, but sudo only keeps certain environment variables, so it's not > > entirely unexpected if this is the case. > > > > > > I gave it run without direct sudo call ( ie sudo bash, then make ..= =2E ) > > and > > > > no go. > > > > > > > > Doing just su - and cd'ing to proper dir and the make ... is still = not > > > > working. > > > > > > > > Overnight I'll try to build world and kernel without src.conf ( ie > > > > SRCCONF=3D/dev/null ) and same for make release. I'll posts results= in > > the > > > > morning. > > > > > > > > Best regards > > > > Andreas > > > > > > > > > > Just a quick update; running a new buildworld+buildkernel and then ma= ke > > > release from su - does not work :( > > > > > > > You've said 'does not work' twice. Can you elaborate more? What > > specifically isn't working? Same behavior as before, or...? > > > > Glen > > > > Oops, my bad. Yes exact same behavior; make -C release cdrom fails with > ... > find //tank/cvs/9.1/src/release/dist/doc -empty -delete > find //tank/cvs/9.1/src/release/dist/games -empty -delete > find: -delete: //tank/cvs/9.1/src/release/dist/games: relative path > potentially not safe > *** [distributeworld] Error code 1 > on 9.1-RC3. I can try with 9-stable as well (tomorrow). >=20 Ok, thanks. I do not want to assume anything more at this point. I am still waiting for my build machine to finish a few queued things. Once it frees up, I will roll a release using sudo (just for my own sanity), and without sudo, with your src.conf and make.conf. Anyway, thanks for all of the details you have provided. It is all helpful, and hopefully this will finally be tracked down. Glen --w3uUfsyyY1Pqa/ej Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQkGyjAAoJEFJPDDeguUaj07oIAKIbAxR04D8Y22mJitDZl5ja 4q8z8B2zkBERqHE2AP9MFEirtDJnxP7B3KG4PE0KgW+0s1QHWc+mrUT41tV9bGl+ F/uuoX5leSOqkZwl1UKWzGrgYbKzGlkK4MAcb+XM7IWOI3x7KHuLTD9ZEkrEJUhx sRzy8yTQNPCF57C68H6rSOwZxf7wG7neXY7aYhO//flKxw0JrTyAAMPIW2KFMYfb Q/khWYHo0b33dIFnVebUhXNU8ftbM6XuwdWbh0gbk3RT8vFXc3DkRIfc8eh+u0jL eAmwGAeLfBptKT++Fy7/Iz9Rq7uXcWAu3FJNr/KVstkCWwdhlvbWc0fcoXk5Up4= =8X6f -----END PGP SIGNATURE----- --w3uUfsyyY1Pqa/ej-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 03:07:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C46E6E64; Wed, 31 Oct 2012 03:07:29 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 836398FC0C; Wed, 31 Oct 2012 03:07:29 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id DFD4923F645; Tue, 30 Oct 2012 23:07:26 -0400 (EDT) Date: Tue, 30 Oct 2012 23:07:24 -0400 From: Glen Barber To: Andreas Nilsson Subject: Re: make release fails on find Message-ID: <20121031030724.GG1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> <20121031001115.GF1371@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Qf1oXS95uex85X0R" Content-Disposition: inline In-Reply-To: <20121031001115.GF1371@glenbarber.us> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 03:07:29 -0000 --Qf1oXS95uex85X0R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 30, 2012 at 08:11:15PM -0400, Glen Barber wrote: > > Oops, my bad. Yes exact same behavior; make -C release cdrom fails with > > ... > > find //tank/cvs/9.1/src/release/dist/doc -empty -delete > > find //tank/cvs/9.1/src/release/dist/games -empty -delete > > find: -delete: //tank/cvs/9.1/src/release/dist/games: relative path > > potentially not safe > > *** [distributeworld] Error code 1 > > on 9.1-RC3. I can try with 9-stable as well (tomorrow). > >=20 >=20 > Ok, thanks. I do not want to assume anything more at this point. >=20 > I am still waiting for my build machine to finish a few queued things. > Once it frees up, I will roll a release using sudo (just for my own > sanity), and without sudo, with your src.conf and make.conf. >=20 > Anyway, thanks for all of the details you have provided. It is all > helpful, and hopefully this will finally be tracked down. >=20 Ugh... Ok, so this is my fault. I do not remember why, specifically, but the change in question was not merged to the releng/9.1 branch. Please try the following, in the top-level directory of your releng/9.1 source checkout: svn merge -c240077 ^/head/Makefile.inc1 Makefile.inc1 It worked for me fine. Unfortunately, it is far too late in the release cycle for that change to make it into 9.1-RELEASE. Unfortunately, this does not have anything to do with the recursing in the usr/src tarball. Please let me know if you continue to see that happen, as this is the _single_ most reported issue that I have had zero luck reproducing... Thanks. Glen PS: Sorry about being the cause of your release build failure... --Qf1oXS95uex85X0R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQkJXsAAoJEFJPDDeguUaj8M8IAIGqd8BSfCLblk95yEpLlOUl 9+QkzGUNLySu8/GesA/tpFBhBRuoEG/H4Z7gkiHYXm99AwalCvXOgELrOU5REM7O ig2SmkCsiDpTMvqLfpS7NfvIUtWU/OwkHDgt4YpJX6EvXSPau84WX6wrkke+bUF8 kFZLmbtLuCbSJBAzCGOp6Zm47JV9TjHU9rrTnNag6TPg3hBbq0JjIqWcvmi6l4Le OqUxzhT8D+2ptot7xcQtq1M72iBjIl0nB2diZ+LkY0sfW7ExUQ3d27gK/Dwgm59l hLbknuUNPaOhWVM+JRFOo7USpJYnpHfB19juht2K9dPWCWHe4qhk+Xwe9GOuW+k= =fuXO -----END PGP SIGNATURE----- --Qf1oXS95uex85X0R-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 03:19:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED96AA3; Wed, 31 Oct 2012 03:19:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id B48798FC14; Wed, 31 Oct 2012 03:19:16 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id A7C1923F645; Tue, 30 Oct 2012 23:19:15 -0400 (EDT) Date: Tue, 30 Oct 2012 23:19:12 -0400 From: Glen Barber To: Andreas Nilsson Subject: Re: make release fails on find Message-ID: <20121031031912.GH1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> <20121031001115.GF1371@glenbarber.us> <20121031030724.GG1371@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y9PDtDHaFrXNoMPU" Content-Disposition: inline In-Reply-To: <20121031030724.GG1371@glenbarber.us> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 03:19:17 -0000 --y9PDtDHaFrXNoMPU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 30, 2012 at 11:07:24PM -0400, Glen Barber wrote: > I do not remember why, specifically, but the change in question was not > merged to the releng/9.1 branch. >=20 > Please try the following, in the top-level directory of your releng/9.1 > source checkout: >=20 > svn merge -c240077 ^/head/Makefile.inc1 Makefile.inc1 >=20 > It worked for me fine. Unfortunately, it is far too late in the release > cycle for that change to make it into 9.1-RELEASE. >=20 To be clear, I mean the release build worked. > Unfortunately, this does not have anything to do with the recursing in > the usr/src tarball. Please let me know if you continue to see that > happen, as this is the _single_ most reported issue that I have had zero > luck reproducing... >=20 And, look at that. I'm finally able to reproduce this recursion problem. Looks that that, too, was fixed in head, but not merged. So, please also do: svn merge -c241451 ^/head/release release At that point, things _should_ work as you expect. Please let me know how this works out for you. Glen --y9PDtDHaFrXNoMPU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQkJiwAAoJEFJPDDeguUajJgwH/RgHHtY7ugRFNvKhzWdGj9Do OXeOaw8RDiT4Vo2HYWglSQ5dMbL2kFJfNvEUL/NvHh18wAZdUK+aZUicJWObC/AY 9BsOkeyHW5n+D6tOBQPKOO+s8kAJ3VaReF3WCwhcppRJYxDoq/elqVEbgPeXMqZb VjhXwxOusGIMnAME3vUlLSxnJVqKYLtxhduxmRC5L/9tHDK6Tk+TMlVcxK6QMNQ9 5laDmzzpjuntG6LI9Y/8Ox78OwrOYdc7ah/+uE1Jy1KGWEn64st41e35m5UQdgKE D7Jep5kWjQJIP2fH4Zux8c7tmkPnVPa0zIpZvNCnEzkEgZKXDBDuCAO+G11jM3c= =no9D -----END PGP SIGNATURE----- --y9PDtDHaFrXNoMPU-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 03:35:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1540D5C9; Wed, 31 Oct 2012 03:35:23 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id D8D008FC08; Wed, 31 Oct 2012 03:35:22 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id D263523F645; Tue, 30 Oct 2012 23:35:21 -0400 (EDT) Date: Tue, 30 Oct 2012 23:35:19 -0400 From: Glen Barber To: Andreas Nilsson Subject: Re: make release fails on find Message-ID: <20121031033519.GI1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> <20121031001115.GF1371@glenbarber.us> <20121031030724.GG1371@glenbarber.us> <20121031031912.GH1371@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="81JctsDUVPekGcy+" Content-Disposition: inline In-Reply-To: <20121031031912.GH1371@glenbarber.us> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 03:35:23 -0000 --81JctsDUVPekGcy+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 30, 2012 at 11:19:12PM -0400, Glen Barber wrote: > So, please also do: >=20 > svn merge -c241451 ^/head/release release >=20 You'll want to merge one more revision: svn merge -c241596 ^/head/release release Same as before - I _think_ this should work. :-) Glen --81JctsDUVPekGcy+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQkJx3AAoJEFJPDDeguUajKtQIAI0Hs4iWHSGwA6vxCHY8Qjyn vDYa+EMVE11nYkiS36QwYiE5EkyYT27SvsDmYhOnwgnXchB+w8JPXw5vTRQ+QYEu Fg7/BhRMehdOYio8D3JBvFvTgjCqw5MeAlZN3F+R7utE/D4WwkaaiQbe5hA/eeuV qMWPSiGINZ1Y8U5YwFpfkF7q2qCHFH2D64DvqIlARFCOMNm7PYn2WI2vjPuv17rx Ag8Vqgs6JKiNQowyyizHAuOEs4kZtinGzaiUVlNR5pP1zmAE3LvsrXWk+pM9u/dW MxjC6O2sVmfzDP+dTOdUsnPMtscDQIXiy4pRga9PeInw+gHE0WWdcHIe7MSyZAw= =aKhm -----END PGP SIGNATURE----- --81JctsDUVPekGcy+-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 07:30:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E7E1D37; Wed, 31 Oct 2012 07:30:01 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 1723D8FC08; Wed, 31 Oct 2012 07:30:00 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id i29so3169103qaf.13 for ; Wed, 31 Oct 2012 00:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FF+AY7ONorsrMPirD1PeaZ/y8YIqfrGTVMGge+L0Kx0=; b=X/CR5wadXtSRboseMfCOjfyViwxFmEGU3PAOe87xozOtwgAgCVN7Q8voAMmbCAonpn Mpm7ssLfU/fJ7/L2XhAlI52A/M/Lz6U3RqSNsW4Vg+7uPSFzi2LiV8DGYx3cez8kXZEY UMMy1W9a0Q8EX0kGPS99UJ9TFpamSXS26zuMpY0By1rNTdmrsMg1kpG/5n3WO96/JUd9 k/fCGeZshfg3UyfrNIkSxqp2oYLepP4mng3DWmdDxWi4KFD+ym6AZH2PjGfzkXHdZqzL HRjLx6Tw/510tE940OW539eA/Jp79ozfRIMa46TuNofEFC8zvG/v6UqZTo2PEUmW0LhU +3/g== MIME-Version: 1.0 Received: by 10.224.72.202 with SMTP id n10mr22759681qaj.94.1351668600117; Wed, 31 Oct 2012 00:30:00 -0700 (PDT) Received: by 10.229.87.67 with HTTP; Wed, 31 Oct 2012 00:29:59 -0700 (PDT) In-Reply-To: <20121031030724.GG1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> <20121031001115.GF1371@glenbarber.us> <20121031030724.GG1371@glenbarber.us> Date: Wed, 31 Oct 2012 08:29:59 +0100 Message-ID: Subject: Re: make release fails on find From: Andreas Nilsson To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 07:30:01 -0000 On Wed, Oct 31, 2012 at 4:07 AM, Glen Barber wrote: > On Tue, Oct 30, 2012 at 08:11:15PM -0400, Glen Barber wrote: > > > Oops, my bad. Yes exact same behavior; make -C release cdrom fails > with > > > ... > > > find //tank/cvs/9.1/src/release/dist/doc -empty -delete > > > find //tank/cvs/9.1/src/release/dist/games -empty -delete > > > find: -delete: //tank/cvs/9.1/src/release/dist/games: relative path > > > potentially not safe > > > *** [distributeworld] Error code 1 > > > on 9.1-RC3. I can try with 9-stable as well (tomorrow). > > > > > > > Ok, thanks. I do not want to assume anything more at this point. > > > > I am still waiting for my build machine to finish a few queued things. > > Once it frees up, I will roll a release using sudo (just for my own > > sanity), and without sudo, with your src.conf and make.conf. > > > > Anyway, thanks for all of the details you have provided. It is all > > helpful, and hopefully this will finally be tracked down. > > > > Ugh... Ok, so this is my fault. > > I do not remember why, specifically, but the change in question was not > merged to the releng/9.1 branch. > > Please try the following, in the top-level directory of your releng/9.1 > source checkout: > > svn merge -c240077 ^/head/Makefile.inc1 Makefile.inc1 > > It worked for me fine. Unfortunately, it is far too late in the release > cycle for that change to make it into 9.1-RELEASE. > Great that you found the bug! > > Unfortunately, this does not have anything to do with the recursing in > the usr/src tarball. Please let me know if you continue to see that > happen, as this is the _single_ most reported issue that I have had zero > luck reproducing... > > With just the merge above now 9.1-RC3 ends up recursing. ( Just tried them one at a time ). > Thanks. > > Glen > > PS: Sorry about being the cause of your release build failure... > > No problem really :) Thanks for hunting this down now. /A From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 07:30:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73052E36; Wed, 31 Oct 2012 07:30:30 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C1EAA8FC15; Wed, 31 Oct 2012 07:30:29 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so944915qcs.13 for ; Wed, 31 Oct 2012 00:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4ty6yrw5QiKtK8R7Fh0J7Ih5zpxqxpSpY2ekwu8vtW4=; b=acwpUk5m543S9o1i8Hks6NAara8wFIhslrZrbCIOtfdPFl3qLcW4VXoFKlhW0ToTa9 U80sUWkVvJT8ZvOVt3wy4tevL8i0gRrXNccxMecN4kkqrovpWlrMoDwd3ZEfNPi9PvHw kLOzHtebZWpquTqfHJQhiTMCrVOiimx8X50gNbEL0uu8mO9YLLNOoIoO1x6x/buFkT2e eRAyraugkxXEud6N/BluBMyvaXN9havf7syVuIXBBB2NXAlCUu/FXqU2/fS1H97Ulf8b sMpD+PcBaGYNmaaudDikZ78IxRDrltITJdhpbcqGw3h0gfh7hVbaVexCVeDhUkoWGKGf JAnA== MIME-Version: 1.0 Received: by 10.224.200.134 with SMTP id ew6mr23340518qab.54.1351668629594; Wed, 31 Oct 2012 00:30:29 -0700 (PDT) Received: by 10.229.87.67 with HTTP; Wed, 31 Oct 2012 00:30:29 -0700 (PDT) In-Reply-To: <20121031033519.GI1371@glenbarber.us> References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> <20121031001115.GF1371@glenbarber.us> <20121031030724.GG1371@glenbarber.us> <20121031031912.GH1371@glenbarber.us> <20121031033519.GI1371@glenbarber.us> Date: Wed, 31 Oct 2012 08:30:29 +0100 Message-ID: Subject: Re: make release fails on find From: Andreas Nilsson To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 07:30:30 -0000 On Wed, Oct 31, 2012 at 4:35 AM, Glen Barber wrote: > On Tue, Oct 30, 2012 at 11:19:12PM -0400, Glen Barber wrote: > > So, please also do: > > > > svn merge -c241451 ^/head/release release > > > > You'll want to merge one more revision: > > svn merge -c241596 ^/head/release release > > Same as before - I _think_ this should work. :-) > > Glen Excelent :) That did the trick, ie no recursion :) Thank you very much for finding the bugs. Will this be merge to 9-stable? On a more whislist topic: I'd really appreciate if .zfs dirs would be excluded from the tarballs. Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 10:14:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A9F7894 for ; Wed, 31 Oct 2012 10:14:10 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by mx1.freebsd.org (Postfix) with ESMTP id 37A6C8FC12 for ; Wed, 31 Oct 2012 10:14:09 +0000 (UTC) Received: from mail277-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 10:14:08 +0000 Received: from mail277-tx2 (localhost [127.0.0.1]) by mail277-tx2-R.bigfish.com (Postfix) with ESMTP id 485641EA01F9 for ; Wed, 31 Oct 2012 10:14:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:195.159.75.198; KIP:(null); UIP:(null); IPV:NLI; H:nomtaout01.proact.no; RD:nomtaout01.proact.no; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzd6eah55dI4015Izz1d18h1202h1d1ah1d2ahz31izz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail277-tx2 (localhost.localdomain [127.0.0.1]) by mail277-tx2 (MessageSwitch) id 1351678443708203_29351; Wed, 31 Oct 2012 10:14:03 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.246]) by mail277-tx2.bigfish.com (Postfix) with ESMTP id AAE5C1540045 for ; Wed, 31 Oct 2012 10:14:03 +0000 (UTC) Received: from nomtaout01.proact.no (195.159.75.198) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 10:14:03 +0000 Received: from Semail04.proact.local (outside.proact.se [212.214.215.3]) by nomtaout01.proact.no (Postfix) with ESMTP id 7DE785DD81 for ; Wed, 31 Oct 2012 11:14:02 +0100 (MET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 11:14:02 +0100 From: Tom Lislegaard To: "'freebsd-stable@freebsd.org'" Subject: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Topic: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Index: Ac23UHFrRe/nHcv4QJaCSOXSiMVayQ== Date: Wed, 31 Oct 2012 10:14:01 +0000 Message-ID: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 10:14:10 -0000 Hi I'm running FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29 16:11= :35 CET 2012 tl@stingray:/usr/obj/usr/src/sys/stingray amd64 on a new Dell laptop and keep getting these panics (typically once or twice= per day) (kgdb) set pagination off (kgdb) bt #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:229 #1 0xffffffff80425e64 in kern_reboot (howto=3D260) at /usr/src/sys/kern/ke= rn_shutdown.c:448 #2 0xffffffff8042634c in panic (fmt=3D0x1
) at = /usr/src/sys/kern/kern_shutdown.c:636 #3 0xffffffff8045773e in resource_list_unreserve (rl=3DVariable "rl" is no= t available. ) at /usr/src/sys/kern/subr_bus.c:3338 #4 0xffffffff802c3ee4 in acpi_delete_resource (bus=3D0xfffffe00052c1100, c= hild=3D0xfffffe00052c1500, type=3D4, rid=3D3323) at /usr/src/sys/dev/acpica= /acpi.c:1405 #5 0xffffffff802c62bc in acpi_bus_alloc_gas (dev=3D0xfffffe00052c1500, typ= e=3D0xfffffe00052b786c, rid=3D0xfffffe00052b7978, gas=3DVariable "gas" is n= ot available. ) at /usr/src/sys/dev/acpica/acpi.c:1450 #6 0xffffffff802d1663 in acpi_PkgGas (dev=3D0xfffffe00052c1500, res=3DVari= able "res" is not available. ) at /usr/src/sys/dev/acpica/acpi_package.c:120 #7 0xffffffff802cbf6b in acpi_cpu_cx_cst (sc=3D0xfffffe00052b7800) at /usr= /src/sys/dev/acpica/acpi_cpu.c:782 #8 0xffffffff802cc3a4 in acpi_cpu_notify (h=3DVariable "h" is not availabl= e. ) at /usr/src/sys/dev/acpica/acpi_cpu.c:1050 #9 0xffffffff802a3fca in AcpiEvNotifyDispatch (Context=3D0x0) at /usr/src/= sys/contrib/dev/acpica/events/evmisc.c:283 #10 0xffffffff802c26c3 in acpi_task_execute (context=3D0xfffffe00051d6800, = pending=3DVariable "pending" is not available. ) at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:134 #11 0xffffffff804683c4 in taskqueue_run_locked (queue=3D0xfffffe00052bc100)= at /usr/src/sys/kern/subr_taskqueue.c:308 #12 0xffffffff80469366 in taskqueue_thread_loop (arg=3DVariable "arg" is no= t available. ) at /usr/src/sys/kern/subr_taskqueue.c:497 #13 0xffffffff803f762f in fork_exit (callout=3D0xffffffff80469320 , arg=3D0xffffffff80a20cc8, frame=3D0xffffff80002cdb00) at /u= sr/src/sys/kern/kern_fork.c:992 #14 0xffffffff806be6be in fork_trampoline () at /usr/src/sys/amd64/amd64/ex= ception.S:602 #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 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 0xffffffff00ffffff in ?? () #40 0x0000000000000000 in ?? () #41 0xfffffe00051e5920 in ?? () #42 0xfffffe00051e5920 in ?? () #43 0xffffff80002cd740 in ?? () #44 0xffffff80002cd6e8 in ?? () #45 0xfffffe00051c1490 in ?? () #46 0xffffffff8044e9b9 in sched_switch (td=3D0xffffffff80469320, newtd=3D0x= ffffffff80a20cc8, flags=3DVariable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1913 Previous frame inner to this frame (corrupt stack?) Hardware details are as follows Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-PRERELEASE #3: Mon Oct 29 16:11:35 CET 2012 tl@stingray:/usr/obj/usr/src/sys/stingray amd64 CPU: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz (2591.64-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x306a9 Family =3D 0x6 Model =3D 0x3a= Stepping =3D 9 Features=3D0xbfebfbff Features2=3D0x7fbae3ff AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 8589934592 (8192 MB) avail memory =3D 8166604800 (7788 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x930,0x934 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xf5000000-0xf5fff= fff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff irq 16 at device 0.0 on pci= 1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xf6080000-0xf6083fff irq 17 at de= vice 0.1 on pci1 pci0: at device 20.0 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.3 (no driver attached) em0: port 0xf040-0xf05f mem 0x= f7700000-0xf771ffff,0xf7739000-0xf7739fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: d4:be:d9:68:18:1e ehci0: mem 0xf7738000-0xf77383ff i= rq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac1: mem 0xf7730000-0xf7733fff irq 2= 2 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 iwn0: mem 0xf7600000-0xf7601fff irq 17 at = device 0.0 on pci3 pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 pcib5: irq 19 at device 28.3 on pci0 pci8: on pcib5 pcib6: irq 17 at device 28.5 on pci0 pci12: on pcib6 pci12: at device 0.0 (no driver attac= hed) ehci1: mem 0xf7737000-0xf77373ff i= rq 21 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf090-0xf097,0xf080= -0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem 0xf7736000-0xf77367ff= irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 battery2: 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] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 orm0: at iomem 0xce800-0xcf7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 est4: on cpu4 p4tcc4: on cpu4 est5: on cpu5 p4tcc5: on cpu5 est6: on cpu6 p4tcc6: on cpu6 est7: on cpu7 p4tcc7: on cpu7 Timecounters tick every 1.000 msec vboxdrv: fAsync=3D0 offMin=3D0x52c offMax=3D0x8b4 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 5 on hdaa0 hdacc1: at cad 1 on hdac0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 5 on hdaa1 hdacc2: at cad 2 on hdac0 hdaa2: at nid 1 on hdacc2 pcm2: at nid 5 on hdaa2 hdacc3: at cad 3 on hdac0 hdaa3: at nid 1 on hdacc3 pcm3: at nid 5 on hdaa3 hdacc4: at cad 0 on hdac1 hdaa4: at nid 1 on hdacc4 pcm4: at nid 13,11 and 10,15 on hdaa4 pcm5: at nid 14 and 17 on hdaa4 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed SMP: AP CPU #2 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #7 Launched! Timecounter "TSC-low" frequency 10123588 Hz quality 1000 Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 usbus0 uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered ugen0.2: at usbus0 uhub2: on = usbus0 ugen1.2: at usbus1 uhub3: on = usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered Root mount waiting for: usbus1 usbus0 uhub3: 8 ports with 8 removable, self powered ugen0.3: at usbus0 ugen1.3: at usbus1 Root mount waiting for: usbus1 usbus0 ugen0.4: at usbus0 ugen1.4: at usbus1 uhub4: on= usbus1 uhub4: MTT enabled uhub4: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 ugen1.5: at usbus1 uhub5: on= usbus1 uhub5: MTT enabled uhub5: 3 ports with 3 removable, self powered Trying to mount root from ufs:/dev/ada0s1a [rw]... WARNING: / was not properly dismounted wlan0: Ethernet address: d4:be:d9:68:18:1e ukbd0: on usbus1 kbd2 at ukbd0 ums0: on usbus1 ums0: 5 buttons and [XYZT] coordinates ID=3D26 ums0: 0 buttons and [T] coordinates ID=3D0 uhid0: on usbus1 wlan0: link state changed to UP NVRM: GPU at 0000:01:00: GPU-dda3aa62-5479-8020-d264-81b556e58aa7 ugen1.3: at usbus1 (disconnected) ukbd0: at uhub3, port 1, addr 3 (disconnected) ums0: at uhub3, port 1, addr 3 (disconnected) uhid0: at uhub3, port 1, addr 3 (disconnected) ugen1.3: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ums0: on usbus1 ums0: 5 buttons and [XYZT] coordinates ID=3D26 ums0: 0 buttons and [T] coordinates ID=3D0 uhid0: on usbus1 vboxnet0: Ethernet address: 0a:00:27:00:00:00 wlan0: promiscuous mode enabled em0: promiscuous mode enabled lagg0: promiscuous mode enabled Any ideas? Thanks, -tom From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 11:11:22 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2A0C8E4; Wed, 31 Oct 2012 11:11:22 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 148F78FC12; Wed, 31 Oct 2012 11:11:21 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9VBCgrN050759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 12:12:43 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <50910751.9030303@omnilan.de> Date: Wed, 31 Oct 2012 12:11:13 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: stable@FreeBSD.org Subject: Re: lock violation in unionfs (9.0-STABLE r230270) References: <5022840B.3060708@omnilan.de> <5048C6D1.8020007@omnilan.de> <508EDB2F.3010608@omnilan.de> In-Reply-To: <508EDB2F.3010608@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62ECCE36897048D96B1EE1BC" Cc: daichi@FreeBSD.org, Pavel Polyakov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 11:11:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62ECCE36897048D96B1EE1BC Content-Type: multipart/mixed; boundary="------------080309090903020506070608" This is a multi-part message in MIME format. --------------080309090903020506070608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Attilio Rao am 29.10.2012 23:02 (localtime): > On Mon, Oct 29, 2012 at 7:37 PM, Harald Schmalzbauer > wrote: >> schrieb Attilio Rao am 27.10.2012 23:07 (localtime): >>> On Sat, Oct 27, 2012 at 9:46 PM, Attilio Rao wr= ote: >>>> On Sat, Sep 8, 2012 at 12:48 AM, Attilio Rao w= rote: >>>>> On Thu, Sep 6, 2012 at 4:52 PM, Harald Schmalzbauer >>>>> wrote: >>>>>> schrieb Attilio Rao am 09.08.2012 20:26 (localtime): >>>>>>> On 8/8/12, Harald Schmalzbauer wrote:= >>>>>>>> schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime): >>>>>>>>>>> mount -t unionfs -o noatime /usr /mnt >>>>>>>>>>> >>>>>>>>>>> insmntque: mp-safe fs and non-locked vp: 0xfffffe01d96704f0 i= s not >>>>>>>>>>> exclusive locked but should be >>>>>>>>>>> KDB: enter: lock violation >>>>>>>>>> Pavel, >>>>>>>>>> can you give a spin to this patch?: >>>>>>>>>> http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock= =2Epatch >>>>>>>>>> >>>>>>>>>> I think that the unlocking is due at that point as the vnode l= ock can >>>>>>>>>> be switch later on. >>>>>>>>>> >>>>>>>>>> Let me know what you think about it and what the test does. >>>>>>>>> Thanks! >>>>>>>>> This patch fixes the problem with lock violation. Sorry I've te= sted it so >>>>>>>>> late. >>>>>>>> Hello, >>>>>>>> >>>>>>>> this patch still applies cleanly to RELENG_9_1. Was there anothe= r fix >>>>>>>> for the issue or has it just not been PR-sent and thus forgotten= ? >>>>>>> Can you and Pavel try the attached patch? Unfortunately I had no = time >>>>>>> to test it, I just made in 5 free mins from a non-FreeBSD worksta= tion, >>>>>> Sorry, couldn't test earlier, but now I did: >>>>>> With this patch applied the machine hangs without debug kernel and= the >>>>>> latter gives the following panic: >>>>>> System call nmount returning with the following locks held: >>>>>> exclusive lockmgr ufs (ufs) r =3D 0 (0xc5438278) locked @ >>>>>> src/sys/fs/unionfs/union_vnops.c:1938 >>>>>> panic: witness_warn >>>>>> cpuid =3D 0 >>>>>> KDB: stack backtrace: >>>>>> db_trace_self_wrapper(c0a04f7f,c0c112c4,d1de3bb4,c097aa8c,fc,...) = at >>>>>> db_trace_self_wrapper+0x26 >>>>>> kdb_backtrace(c0a4965f,0,c09c2ede3c1c,0,...) at kdb_backtrace+0x2a= >>>>>> witness_warn(2,0,c0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >>>>>> syscall(d1de3d08) ar syscall+0x415 >>>>>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>>>>> --- syscall (0, FreeBSD ELF32, nosys), eip =3D 0x280b883f,esp =3D >>>>>> 0xbfbfe46c, ebp =3D 0xbfbfede8 --- >>>>>> KDB: enter: panic >>>>>> [ thread pid 86 tid 100054 ] >>>>>> Stopped ad kdb_enter+0x3a: movl $0,kdb_why >>>>>> db> bt >>>>>> Tracing pid 86 tid 100054 td 0xc541b000 >>>>>> kdb_enter(c0a00d16,c0a09130,0,0,0,...) at panix+0x190 >>>>>> witness_warn(2,0,x0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >>>>>> syscall(d1de3d08) at syscall+0x415 >>>>>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>>>>> >>>>>> Hmm, I guess I forgot to install kernel debug symbols... >>>>>> Coming back if I have more >>>>> Unfortunately unionfs does very wrong things with the insmntque() l= ocking. >>>>> It basically expects the vnode to return locked in the same way >>>>> requested by the precedent namei() (when that happens) but when you= do >>>>> insmntque() you can only have an LK_EXCLUSIVE lock on the vnode. >>>> Hello, >>>> the following patch should workout the issues around unionfs_nodeget= () a bit: >>>> http://www.freebsd.org/~attilio/unionfs_nodeget2.patch >>>> >>>> Unfortunately unionfs code is rather messy in the lookup path about >>>> locking requirements so follow what it needs to be done there is a b= it >>>> difficult. >>>> I have no way to test this patch, so it is just test-compiled at the= >>>> moment, but I would need that you also test lookup path (so director= y >>>> "ls", find(1) on the whole unionfs volume, etc.) to validate it >>>> someway. >>> On a second thought, I think that locking in lookup (and also other >>> operations) is so fragile and difficult to follow that it makes all >>> vnops real locking landmines. >>> I think that the following patch fixes the insmntque insertion and >>> follows the old approach well enough to be committed separately: >>> http://www.freebsd.org/~attilio/unionfs_nodeget3.patch >>> >> Unfortunately I have no idea about all those locking strategies and >> implementations. >> Applying unionfs_nodeget3.patch results in: >> sys/fs/unionfs/union_subr.c: In function 'unionfs_nodeget': >> sys/fs/unionfs/union_subr.c:332: error: expected statement >> before ')' token >> *** [union_subr.o] Error code 1 >> >> I guess there is a typo in this chunk: >> @@ -317,11 +328,11 @@ unionfs_nodeget(struct mount *mp, struct vnode *= up >> >> vref(vp); >> } else >> *vpp =3D vp; >> - >> -unionfs_nodeget_out: >> - if (lkflags & LK_TYPE_MASK) >> - vn_lock(vp, lkflags | LK_RETRY); >> - >> + if (lkflags & LK_TYPE_MASK) { >> + if (lkflags =3D=3D LK_SHARED)) >> ---------------------------------------- ^ >> + vn_lock(vp, LK_DOWNGRADE | LK_RETRY); >> + } else >> + VOP_UNLOCK(vp, LK_RELEASE); >> return (0); >> } >> >> After removing the second right parenthesis kernel compiles. >> But it still crashes: >> panic: Lock (lockmgr) ufs not locked @ sys/kern/vfs_default.c:512 >> cpuid =3D 1 >> KDB: stack backtrace: >> ... >> If you can use the bt info I'll transcribe - no serial console availab= le :-( >> >> Am I right that I should only apply _one_ unionfs-patchX.patch >> (unionfs_nodeget3.patch in that case)? > Yes, only that one. > Can you please do "bt" from DDB and take a picture of you screen with a= camera? Ok, now I had a reason to take some time finding out how ESXi handles serial ports ;-) It's quiet easy and very flexible, so no problem setting up a debug console. Please find attached the backtrace. Do I have to load any symbols? It's not very informative what I see, righ= t? Thanks, -Harry --------------080309090903020506070608 Content-Type: text/plain; name="unionfs-nodeget3_backtrace.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="unionfs-nodeget3_backtrace.txt" panic: Lock (lockmgr) ufs not locked @ /usr/local/share/deploy-tools/RELE= NG_9_1/src/sys/kern/vfs_default.c:512. cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1cd witness_assert() at witness_assert+0x225 __lockmgr_args() at __lockmgr_args+0xb65 vop_stdunlock() at vop_stdunlock+0x43 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x9b unionfs_unlock() at unionfs_unlock+0xe1 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x9b unionfs_nodeget() at unionfs_nodeget+0x5a9 unionfs_domount() at unionfs_domount+0x4ab vfs_donmount() at vfs_donmount+0x960 sys_nmount() at sys_nmount+0x66 amd64_syscall() at amd64_syscall+0x2fa Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x80087798c, rsp =3D= 0x7fffffffd328, rbp =3D 0x7fffffffd750 --- KDB: enter: panic [ thread pid 72 tid 100072 ] Stopped at kdb_enter+0x3b: movq $0,0x64cd52(%rip) db> bt Tracing pid 72 tid 100072 td 0xfffffe0007344470 kdb_enter() at kdb_enter+0x3b panic() at panic+0x1c6 witness_assert() at witness_assert+0x225 __lockmgr_args() at __lockmgr_args+0xb65 vop_stdunlock() at vop_stdunlock+0x43 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x9b unionfs_unlock() at unionfs_unlock+0xe1 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x9b unionfs_nodeget() at unionfs_nodeget+0x5a9 unionfs_domount() at unionfs_domount+0x4ab vfs_donmount() at vfs_donmount+0x960 sys_nmount() at sys_nmount+0x66 amd64_syscall() at amd64_syscall+0x2fa Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x80087798c, rsp =3D= 0x7fffffffd328, rbp =3D 0x7fffffffd750 --- db> --------------080309090903020506070608-- --------------enig62ECCE36897048D96B1EE1BC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCRB1EACgkQLDqVQ9VXb8iCBgCfRexfEVFPISILVforSldh6mKe VsYAnAmR4qxAWOBVr7RnVDYmeXeZu2Ok =lxam -----END PGP SIGNATURE----- --------------enig62ECCE36897048D96B1EE1BC-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 13:07:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57E73C28; Wed, 31 Oct 2012 13:07:58 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E7AEE8FC16; Wed, 31 Oct 2012 13:07:57 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so1158139qcs.13 for ; Wed, 31 Oct 2012 06:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8FAiYE5Wp82tiGUeXLj+uvYGvp64wPlTfEWXRcXAVGk=; b=DQuh3L+6k8Ox2SzHvdzkZXysyDzCeBAXiL+fAeAS9hS6LmPS0qg5+kOHrqr0+b+lTN HDPi+NYx//N4k1s5J3GK2aRNXwYGTBC5h7V/ur5MNfqPIHUOFEL9OTgibxfZ+AmqlA1V xyt3eNpSl1+dU4vyXKkNJBElfeRsnMQogH5UzOG5LhVWFEuQr8k9adZOSzDmyhxyiIPN DWIWeKyNfYyFnRlCDOodTI2mY0wLfgPnDyx7rWWlWyFbjddJQeLo9hHi2mgFNJgSAqA3 4su72dk0m7E10H0KHKKdWhJPNaLpTAKy3jDfNCULIh4zJDZtUJRHCzfCaLZoDw6FdB+q iF0w== MIME-Version: 1.0 Received: by 10.224.72.202 with SMTP id n10mr23482849qaj.94.1351688876926; Wed, 31 Oct 2012 06:07:56 -0700 (PDT) Received: by 10.229.87.67 with HTTP; Wed, 31 Oct 2012 06:07:56 -0700 (PDT) In-Reply-To: References: <20121030160804.GB1371@glenbarber.us> <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> <20121031001115.GF1371@glenbarber.us> <20121031030724.GG1371@glenbarber.us> <20121031031912.GH1371@glenbarber.us> <20121031033519.GI1371@glenbarber.us> Date: Wed, 31 Oct 2012 14:07:56 +0100 Message-ID: Subject: Re: make release fails on find From: Andreas Nilsson To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 13:07:58 -0000 First, late me state status more clearly: solved :) Big thanks for fixing it. On a side note, how has re-team not run into this? Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 13:24:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44BF1205; Wed, 31 Oct 2012 13:24:05 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 05A2E8FC16; Wed, 31 Oct 2012 13:24:05 +0000 (UTC) Received: from glenbarber.us (75-146-225-65-Philadelphia.hfc.comcastbusiness.net [75.146.225.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 4B80723F645; Wed, 31 Oct 2012 09:24:04 -0400 (EDT) Date: Wed, 31 Oct 2012 09:24:02 -0400 From: Glen Barber To: Andreas Nilsson Subject: Re: make release fails on find Message-ID: <20121031132402.GA1542@glenbarber.us> References: <20121030231412.GE1371@glenbarber.us> <20121031001115.GF1371@glenbarber.us> <20121031030724.GG1371@glenbarber.us> <20121031031912.GH1371@glenbarber.us> <20121031033519.GI1371@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 13:24:05 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 02:07:56PM +0100, Andreas Nilsson wrote: > First, late me state status more clearly: solved :) Big thanks for fixing > it. >=20 Glad to help. To answer one of your previous questions, I've already merged this to stable/9. > On a side note, how has re-team not run into this? >=20 No, the releases are built within a chroot, and this issue is specific to a few edge-cases outside of that environment. Glen --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQkSZyAAoJEFJPDDeguUaj/g8IAIJOG2t2q/NwXoq1pUEzMelQ L4rmd5kSTqJoi9/Y+u56RvrJIMeltqUNa+WPERwt8acpCzgthC+7BZUjT/BdQuat 6PfW1N3ZnP5yUTJR5wRMX98B6ZWN4uce+8Fnk0dYPrDU6URWZYOwB1k/uLnKijJz jbw9tVNJCbl1gebpUwEhSeDgWUye/TSNXCcpngzO7p7OExvjzqMriY7pQZBfEjNJ kjy7Io12S4N3/Ym3qADiqQFuGymiYG+7QTpimoCqrCQH7pbKKAQNKOL2BNXri6mf ZfaOXos0auG59Jb4Cgh0Xpb7PQHPXK1zEmUuPhJgGQUVZMzAKr5HiWA0wOCx8K4= =jQem -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 14:12:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B03E338; Wed, 31 Oct 2012 14:12:12 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id DE09B8FC0C; Wed, 31 Oct 2012 14:12:11 +0000 (UTC) Received: from glenbarber.us (75-146-225-65-Philadelphia.hfc.comcastbusiness.net [75.146.225.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 32D7C23F645; Wed, 31 Oct 2012 10:12:11 -0400 (EDT) Date: Wed, 31 Oct 2012 10:12:09 -0400 From: Glen Barber To: Andreas Nilsson Subject: Re: make release fails on find Message-ID: <20121031141209.GB1542@glenbarber.us> References: <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> <20121031001115.GF1371@glenbarber.us> <20121031030724.GG1371@glenbarber.us> <20121031031912.GH1371@glenbarber.us> <20121031033519.GI1371@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U+BazGySraz5kW0T" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 14:12:12 -0000 --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 08:30:29AM +0100, Andreas Nilsson wrote: > On a more whislist topic: I'd really appreciate if .zfs dirs would be > excluded from the tarballs. >=20 Hmm, I didn't realize this was happening. So I can verify my change works for all environments, are you using any local zfs dataset properties, specifically unhiding the snapshot directory? Glen --U+BazGySraz5kW0T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQkTG5AAoJEFJPDDeguUajJZwIAK6ioMLELBEoK7m8YTE6XwiT x0mKA7zFbXtN61wI0Im6IUzvjHR/kNUuFH++Jw7IArcEDCHZ0p4FMVWFBBFd8Xij T18+txvdSpk9rVwZLP+S4EqeObd05De1IBGUdRl1pMWykMRetJ/G45wFeXCsFfrL I92Degz9EWFY7jdyWoLd6gD+Vp1OAdPS0aeKniACB+IX5JfqfVm5W3AIkMwv1cC0 Jub0Wee0IEyg1cvuGP8uFhziYq5faWg570l30KBGQWlYTmL+cTnOYDtGi2tdugS7 rlIrX4IFDI3oljRA8v33v94t0vP53c9ezNxUBXrpwb221RcKH2Y/2uKSAsX4dTY= =ozyY -----END PGP SIGNATURE----- --U+BazGySraz5kW0T-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 16:32:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 370E959B for ; Wed, 31 Oct 2012 16:32:32 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id E22508FC14 for ; Wed, 31 Oct 2012 16:32:31 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id EA2D628422 for ; Wed, 31 Oct 2012 17:26:47 +0100 (CET) Received: from [192.168.1.2] (unknown [89.177.49.255]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 24CCF28424 for ; Wed, 31 Oct 2012 17:26:47 +0100 (CET) Message-ID: <50915144.2030006@quip.cz> Date: Wed, 31 Oct 2012 17:26:44 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: ACPI Error: No handler for Region [POWS] (0xffffff000994f380) [IPMI] on Cisco UCS C200 M2 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:32:32 -0000 Hi, I am getting the following error on server Cisco UCS C200 M2 running FreeBSD 8.3 amd64 Oct 31 02:15:22 ucs200 kernel: ACPI Error: No handler for Region [POWS] (0xffffff000994f380) [IPMI] (20101013/evregion-487) Oct 31 02:15:22 ucs200 kernel: ACPI Error: Region IPMI(0x7) has no handler (20101013/exfldio-382) Oct 31 02:15:22 ucs200 kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPC0.P111._PSR] (Node 0xffffff0009934080), AE_NOT_EXIST (20101013/psparse-633) Oct 31 02:15:23 ucs200 kernel: ACPI Error: No handler for Region [POWS] (0xffffff000994f380) [IPMI] (20101013/evregion-487) Oct 31 02:15:23 ucs200 kernel: ACPI Error: Region IPMI(0x7) has no handler (20101013/exfldio-382) Oct 31 02:15:23 ucs200 kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPC0.P111._PSR] (Node 0xffffff0009934080), AE_NOT_EXIST (20101013/psparse-633) Oct 31 02:15:23 ucs200 kernel: ACPI Error: No handler for Region [POWS] (0xffffff000994f380) [IPMI] (20101013/evregion-487) Oct 31 02:15:23 ucs200 kernel: ACPI Error: Region IPMI(0x7) has no handler (20101013/exfldio-382) Oct 31 02:15:23 ucs200 kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPC0.P111._PSR] (Node 0xffffff0009934080), AE_NOT_EXIST (20101013/psparse-633) # uname -srmi FreeBSD 8.3-RELEASE amd64 GENERIC I don't know what it means. Should I be worried about it or should I ignore it? Is there something that I can tune to turn this message off or is there something which need to be fixed on FreeBSD side? We are planing to push this machine in to a production in one or two weeks, but until this time I can test patches etc. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 17:55:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B590AFAD; Wed, 31 Oct 2012 17:55:46 +0000 (UTC) (envelope-from prvs=1651f70f45=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 180338FC14; Wed, 31 Oct 2012 17:55:45 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000898021.msg; Wed, 31 Oct 2012 17:55:43 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 31 Oct 2012 17:55:43 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1651f70f45=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: , References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> Subject: Re: ZFS corruption due to lack of space? Date: Wed, 31 Oct 2012 17:55:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:55:46 -0000 Other info: zpool list tank2 NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank2 19T 18.7T 304G 98% 1.00x ONLINE - zfs list tank2 NAME USED AVAIL REFER MOUNTPOINT tank2 13.3T 0 13.3T /tank2 Running: 8.3-RELEASE-p4, zpool: v28, zfs: v5 ----- Original Message ----- From: "Steven Hartland" To: ; Sent: Wednesday, October 31, 2012 5:25 PM Subject: ZFS corruption due to lack of space? > Been running some tests on new hardware here to verify all > is good. One of the tests was to fill the zfs array which > seems like its totally corrupted the tank. > > The HW is 7 x 3TB disks in RAIDZ2 with dual 13GB ZIL > partitions and dual 100GB L2ARC on Enterprise SSD's. > > All disks are connected to an LSI 2208 RAID controller > run by mfi driver. HD's via a SAS2X28 backplane and > SSD's via a passive blackplane backplane. > > The file system has 31 test files most random data from > /dev/random and one blank from /dev/zero. > > The test running was multiple ~20 dd's under screen with > all but one from /dev/random and to final one from /dev/zero > > e.g. dd if=/dev/random bs=1m of=/tank2/random10 > > No hardware errors have raised, so no disk timeouts etc. > > On completion each dd reported no space as you would expect > e.g. dd if=/dev/random bs=1m of=/tank2/random13 > dd: /tank2/random13: No space left on device > 503478+0 records in > 503477+0 records out > 527933898752 bytes transferred in 126718.731762 secs (4166187 bytes/sec) > You have new mail. > > At that point with the test seemingly successful I went > to delete test files which resulted in:- > rm random* > rm: random1: Unknown error: 122 > rm: random10: Unknown error: 122 > rm: random11: Unknown error: 122 > rm: random12: Unknown error: 122 > rm: random13: Unknown error: 122 > rm: random14: Unknown error: 122 > rm: random18: Unknown error: 122 > rm: random2: Unknown error: 122 > rm: random3: Unknown error: 122 > rm: random4: Unknown error: 122 > rm: random5: Unknown error: 122 > rm: random6: Unknown error: 122 > rm: random7: Unknown error: 122 > rm: random9: Unknown error: 122 > > Error 122 I assume is ECKSUM > > At this point the pool was showing checksum errors > zpool status > pool: tank > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gptid/41fb7e5c-21cf-11e2-92a3-002590881138 ONLINE 0 0 0 > gptid/42a1b53c-21cf-11e2-92a3-002590881138 ONLINE 0 0 0 > > errors: No known data errors > > pool: tank2 > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > tank2 ONLINE 0 0 4.22K > raidz2-0 ONLINE 0 0 16.9K > mfisyspd0 ONLINE 0 0 0 > mfisyspd1 ONLINE 0 0 0 > mfisyspd2 ONLINE 0 0 0 > mfisyspd3 ONLINE 0 0 0 > mfisyspd4 ONLINE 0 0 0 > mfisyspd5 ONLINE 0 0 0 > mfisyspd6 ONLINE 0 0 0 > logs > mfisyspd7p3 ONLINE 0 0 0 > mfisyspd8p3 ONLINE 0 0 0 > cache > mfisyspd9 ONLINE 0 0 0 > mfisyspd10 ONLINE 0 0 0 > > errors: Permanent errors have been detected in the following files: > > tank2:<0x3> > tank2:<0x8> > tank2:<0x9> > tank2:<0xa> > tank2:<0xb> > tank2:<0xf> > tank2:<0x10> > tank2:<0x11> > tank2:<0x12> > tank2:<0x13> > tank2:<0x14> > tank2:<0x15> > > So I tried a scrub, which looks like its going to > take 5 days to complete and is reporting many many more > errors:- > > pool: tank2 > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scan: scrub in progress since Wed Oct 31 16:13:53 2012 > 118G scanned out of 18.7T at 42.2M/s, 128h19m to go > 49.0M repaired, 0.62% done > config: > > NAME STATE READ WRITE CKSUM > tank2 ONLINE 0 0 596K > raidz2-0 ONLINE 0 0 1.20M > mfisyspd0 ONLINE 0 0 0 (repairing) > mfisyspd1 ONLINE 0 0 0 (repairing) > mfisyspd2 ONLINE 0 0 0 (repairing) > mfisyspd3 ONLINE 0 0 2 (repairing) > mfisyspd4 ONLINE 0 0 1 (repairing) > mfisyspd5 ONLINE 0 0 0 (repairing) > mfisyspd6 ONLINE 0 0 1 (repairing) > logs > mfisyspd7p3 ONLINE 0 0 0 > mfisyspd8p3 ONLINE 0 0 0 > cache > mfisyspd9 ONLINE 0 0 0 > mfisyspd10 ONLINE 0 0 0 > > errors: 596965 data errors, use '-v' for a list > > > At this point I decided to cancel the scrub but no joy on that > > zpool scrub -s tank2 > cannot cancel scrubbing tank2: out of space > > So questions:- > > 1. Given the information it seems like the multiple writes filling > the disk may have caused metadata corruption? > 2. Is there anyway to stop the scrub? > 3. Surely low space should never prevent stopping a scrub? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 18:25:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EE7840C for ; Wed, 31 Oct 2012 18:25:17 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from ecbiz102.inmotionhosting.com (ecbiz102.inmotionhosting.com [70.39.235.94]) by mx1.freebsd.org (Postfix) with ESMTP id 513378FC0C for ; Wed, 31 Oct 2012 18:25:17 +0000 (UTC) Received: from c-24-218-93-106.hsd1.nh.comcast.net ([24.218.93.106]:61964 helo=jack.bspruce.com) by ecbiz102.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TTbcg-0006Ge-Qg; Wed, 31 Oct 2012 12:58:34 -0400 Message-ID: <509158BC.7090901@greatbaysoftware.com> Date: Wed, 31 Oct 2012 12:58:36 -0400 From: Charles Owens Organization: Great Bay Software User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, Steve McCoy , Jack Vogel , jdc@parodius.com Subject: Panic during kernel boot, igb-init related? (8.3-RELEASE) X-Priority: 2 (High) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz102.inmotionhosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - greatbaysoftware.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:25:17 -0000 Hello, We're seeing boot-time panics in about 4% of cases when upgrading from FreeBSD 8.1 to 8.3-RELEASE (i386). This problem is subtle enough that it escaped detection during our regular testing cycle... now with over 100 systems upgraded we're convinced there's a real issue. Our kernel config is essentially PAE (ie. static modules ... with a few drivers added/removed). The hardware is Intel Server System SR1625UR. This appears to match a finding discussed in these threads, having to do with timing of initialization of the igb(4)-based NICs (if I'm understanding it properly): http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/062596.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062949.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063867.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html These threads include some potential patches and possibility of commit/MFC... but it isn't clear that there was ever final resolution (and MFC to 8-stable). I've cc'd a few folks from back then. A real challenge here is the frequency of occurrence. As mentioned, it only hit's a fraction of our systems. When it _does_ hit, the system may enter a reboot loop for days and then mysteriously break out of it... and thereafter seem to work fine. I'd be very grateful for any help. Some questions: * Was there ever a final "blessed" patch? o if so, will it apply to RELENG_8_3? * Is there anything that could be said that might help us with reproducing-the-problem / testing / validating-a-fix? Panic message is -- panic: m_getzone: m_getjcl: invalid cluster type cpuid = 0 KDB: stack backtrace: #0 0xc059c717 at kdb_backtrace+0x47 #1 0xc056caf7 at panic+0x117 #2 0xc03c979e at igb_refresh_mbufs+0x25e #3 0xc03c9f98 at igb_rxeof+0x638 #4 0xc03ca135 at igb_msix_que+0x105 #5 0xc0541e2b at intr_event_execute_handlers+0x13b #6 0xc05434eb at ithread_loop+0x6b #7 0xc053efb7 at fork_exit+0x97 #8 0xc0806744 at fork_trampoline+0x8 Thanks very much, Charles -- Charles Owens Great Bay Software, Inc. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 18:50:37 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 878E2C40 for ; Wed, 31 Oct 2012 18:50:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D1E9E8FC0C for ; Wed, 31 Oct 2012 18:50:36 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA12074; Wed, 31 Oct 2012 20:50:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <509172F6.2040400@FreeBSD.org> Date: Wed, 31 Oct 2012 20:50:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'freebsd-stable@freebsd.org'" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:50:37 -0000 on 31/10/2012 12:14 Tom Lislegaard said the following: > Hi > > I'm running > FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29 16:11:35 CET 2012 tl@stingray:/usr/obj/usr/src/sys/stingray amd64 > on a new Dell laptop and keep getting these panics (typically once or twice per day) > > (kgdb) set pagination off > (kgdb) bt > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:229 > #1 0xffffffff80425e64 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff8042634c in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:636 > #3 0xffffffff8045773e in resource_list_unreserve (rl=Variable "rl" is not available. > ) at /usr/src/sys/kern/subr_bus.c:3338 > #4 0xffffffff802c3ee4 in acpi_delete_resource (bus=0xfffffe00052c1100, child=0xfffffe00052c1500, type=4, rid=3323) at /usr/src/sys/dev/acpica/acpi.c:1405 > #5 0xffffffff802c62bc in acpi_bus_alloc_gas (dev=0xfffffe00052c1500, type=0xfffffe00052b786c, rid=0xfffffe00052b7978, gas=Variable "gas" is not available. > ) at /usr/src/sys/dev/acpica/acpi.c:1450 > #6 0xffffffff802d1663 in acpi_PkgGas (dev=0xfffffe00052c1500, res=Variable "res" is not available. > ) at /usr/src/sys/dev/acpica/acpi_package.c:120 > #7 0xffffffff802cbf6b in acpi_cpu_cx_cst (sc=0xfffffe00052b7800) at /usr/src/sys/dev/acpica/acpi_cpu.c:782 > #8 0xffffffff802cc3a4 in acpi_cpu_notify (h=Variable "h" is not available. > ) at /usr/src/sys/dev/acpica/acpi_cpu.c:1050 > #9 0xffffffff802a3fca in AcpiEvNotifyDispatch (Context=0x0) at /usr/src/sys/contrib/dev/acpica/events/evmisc.c:283 > #10 0xffffffff802c26c3 in acpi_task_execute (context=0xfffffe00051d6800, pending=Variable "pending" is not available. > ) at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:134 > #11 0xffffffff804683c4 in taskqueue_run_locked (queue=0xfffffe00052bc100) at /usr/src/sys/kern/subr_taskqueue.c:308 > #12 0xffffffff80469366 in taskqueue_thread_loop (arg=Variable "arg" is not available. > ) at /usr/src/sys/kern/subr_taskqueue.c:497 > #13 0xffffffff803f762f in fork_exit (callout=0xffffffff80469320 , arg=0xffffffff80a20cc8, frame=0xffffff80002cdb00) at /usr/src/sys/kern/kern_fork.c:992 > #14 0xffffffff806be6be in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 Could you please provide *sc from frame 7? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 20:48:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89CF57FD; Wed, 31 Oct 2012 20:48:21 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id D23388FC14; Wed, 31 Oct 2012 20:48:20 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so1737766lag.13 for ; Wed, 31 Oct 2012 13:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ktu6RtoKL5Q+g7H5K7CQOJ9ljDL+ED865hmblXtv+6o=; b=qb02R/da5H6TDOhjYsgPDRfobKg5Nvu5hhg6XZaN6K99vOjZxdIqJaBPa68ZjnwQZk ZXbWWQ1NOwXWC9jxvlp0TkHLFykbCQmx5BJOBos8URbopnliU/Pnd2S8MmpsDagKk+Y5 hNkG/X1/uh4qTxFo2iUoExw4QSDg4Y9iBNWYnW0pt3MNAxuEvj+/5zVfgaOWr9+s/RpB 5T/RCc9Ux+WL1Bk4Ix2CQ8Ytc44NWxEcthehBp9706ipBHhywtSY5GOyaWuhc2MB4JO7 JmGCzYojvIC22E3xy26mzeixP7jBnnvP54Si6Co0YlCSX7ksuQ8RGkSuWIUXwuyndiFj ajOQ== MIME-Version: 1.0 Received: by 10.112.37.138 with SMTP id y10mr3753593lbj.121.1351716499843; Wed, 31 Oct 2012 13:48:19 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.112.80.103 with HTTP; Wed, 31 Oct 2012 13:48:19 -0700 (PDT) In-Reply-To: References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> Date: Wed, 31 Oct 2012 13:48:19 -0700 X-Google-Sender-Auth: MhwlRgIxjzGvohr-bO9q9AaqRbk Message-ID: Subject: Re: ZFS corruption due to lack of space? From: Artem Belevich To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:48:21 -0000 On Wed, Oct 31, 2012 at 10:55 AM, Steven Hartland wrote: > At that point with the test seemingly successful I went > to delete test files which resulted in:- > rm random* > rm: random1: Unknown error: 122 ZFS is a logging filesystem. Even removing a file apparently requires some space to write a new record saying that the file is not referenced any more. One way out of this jam is to try truncating some large file in place. Make sure that file is not part of any snapshot. Something like this may do the trick: #dd if=/dev/null of=existing_large_file Or, perhaps even something as simple as 'echo -n > large_file' may work. Good luck, --Artem From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 21:23:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9660FE12; Wed, 31 Oct 2012 21:23:55 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 092A28FC16; Wed, 31 Oct 2012 21:23:53 +0000 (UTC) Received: from server.rulingia.com (c220-239-241-202.belrs5.nsw.optusnet.com.au [220.239.241.202]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q9VLNqO2037647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Nov 2012 08:23:52 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q9VLNkcA040212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2012 08:23:46 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q9VLNk2i040211; Thu, 1 Nov 2012 08:23:46 +1100 (EST) (envelope-from peter) Date: Thu, 1 Nov 2012 08:23:46 +1100 From: Peter Jeremy To: Steven Hartland Subject: Re: ZFS corruption due to lack of space? Message-ID: <20121031212346.GL3309@server.rulingia.com> References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IMjqdzrDRly81ofr" Content-Disposition: inline In-Reply-To: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 21:23:55 -0000 --IMjqdzrDRly81ofr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Oct-31 17:25:09 -0000, Steven Hartland wro= te: >Been running some tests on new hardware here to verify all >is good. One of the tests was to fill the zfs array which >seems like its totally corrupted the tank. I've accidently "filled" a pool, and had multiple processes try to write to the full pool, without either emptying the free space reserve (so I could still delete the offending files) or corrupting the pool. Had you tried to read/write the raw disks before you tried the ZFS testing? Do you have compression and/or dedupe enabled on the pool? >1. Given the information it seems like the multiple writes filling >the disk may have caused metadata corruption? I don't recall seeing this reported before. >2. Is there anyway to stop the scrub? Other than freeing up some space, I don't think so. If this is a test pool that you don't need, you could try destroying it and re-creating it - that may be quicker and easier than recovering the existing pool. >3. Surely low space should never prevent stopping a scrub? As Artem noted, ZFS is a copy-on-write filesystem. It is supposed to reserve some free space to allow metadata updates (stop scrubs, delete files, etc) even when it is "full" but I have seen reports of this not working correctly in the past. A truncate-in-place may work. You could also try asking on zfs-discuss@opensolaris.org=20 --=20 Peter Jeremy --IMjqdzrDRly81ofr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCRluIACgkQ/opHv/APuIf5XwCePbniJH+FqKmFdUYvRlHobjbE U74AoIBMqgc6dVkhg9Znx5K9IVh4Spa2 =1SD/ -----END PGP SIGNATURE----- --IMjqdzrDRly81ofr-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 31 21:31:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CB246B3; Wed, 31 Oct 2012 21:31:55 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id BC51A8FC08; Wed, 31 Oct 2012 21:31:54 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so2677243vcb.13 for ; Wed, 31 Oct 2012 14:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pqae7FdZL9WSNEyXswPexnAL8jbV6Tbp5y/vgv0k7p4=; b=uw5ULVVR846/dl4pIqKwM5SPxaIIxz3vsVK/OVrn2vI67Lt84m5cuIlZaFZNQcHgOV TpXY/d5rDZily61UxCFtIgTb5XKaddPQqOEHItmFGFfIv1lBPnUBxLNSFgMH26zDNFSv O6TOiol/Fh6wysY6ggzKhS1kaTmb9wlVg/Yp4K9WgPI22Hh/hd0qzpWjwuEz8Eg0MLnd S/n6geoiP/EQdytOMjhW5Q14O6WlTgOOEnQNzv5hPXKPg9PlFOfysh0GUTNJVJR1uetB Ac1GOW4x9Us0K2Yu0o2J90GIh8j6oM6klRatvlHrIyhC8kum3uVLmU/+pVEx530Bm5Fc +2dA== MIME-Version: 1.0 Received: by 10.52.155.199 with SMTP id vy7mr50194247vdb.54.1351719113870; Wed, 31 Oct 2012 14:31:53 -0700 (PDT) Received: by 10.58.207.114 with HTTP; Wed, 31 Oct 2012 14:31:53 -0700 (PDT) In-Reply-To: References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> Date: Wed, 31 Oct 2012 17:31:53 -0400 Message-ID: Subject: Re: ZFS corruption due to lack of space? From: Ryan Stone To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Steven Hartland X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 21:31:55 -0000 On Wed, Oct 31, 2012 at 4:48 PM, Artem Belevich wrote: > One way out of this jam is to try truncating some large file in place. > Make sure that file is not part of any snapshot. > Something like this may do the trick: > #dd if=/dev/null of=existing_large_file > > Or, perhaps even something as simple as 'echo -n > large_file' may work. truncate -s 0? From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 00:09:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC21CDF4; Thu, 1 Nov 2012 00:09:36 +0000 (UTC) (envelope-from prvs=1652892d21=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 14E948FC0C; Thu, 1 Nov 2012 00:09:35 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000903327.msg; Thu, 01 Nov 2012 00:09:33 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 01 Nov 2012 00:09:33 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1652892d21=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Peter Jeremy" References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> <20121031212346.GL3309@server.rulingia.com> Subject: Re: ZFS corruption due to lack of space? Date: Thu, 1 Nov 2012 00:09:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 00:09:36 -0000 On 2012-Oct-31 17:25:09 -0000, Steven Hartland wrote: >>Been running some tests on new hardware here to verify all >>is good. One of the tests was to fill the zfs array which >>seems like its totally corrupted the tank. > >I've accidently "filled" a pool, and had multiple processes try to >write to the full pool, without either emptying the free space reserve >(so I could still delete the offending files) or corrupting the pool. Same here but its the first time I've had ZIL in place at the time so wondering if that may be playing a factor. > Had you tried to read/write the raw disks before you tried the > ZFS testing? Yes, didn't see any issues but then it wasn't checksuming so tbh I wouldn't have noticed if it was silently corrupting data. >Do you have compression and/or dedupe enabled on the pool? Nope bog standard raidz2 no additional settings >>1. Given the information it seems like the multiple writes filling >>the disk may have caused metadata corruption? > > I don't recall seeing this reported before. Nore me and we've been using ZFS for years, but never filled a pool with such known simultanious access + ZIL before >>2. Is there anyway to stop the scrub? > >Other than freeing up some space, I don't think so. If this is a test >pool that you don't need, you could try destroying it and re-creating >it - that may be quicker and easier than recovering the existing pool. Artems trick of cat /dev/null > /tank2/ worked and I've now managed to stop the scrub :) >>3. Surely low space should never prevent stopping a scrub? > > As Artem noted, ZFS is a copy-on-write filesystem. It is supposed to > reserve some free space to allow metadata updates (stop scrubs, delete > files, etc) even when it is "full" but I have seen reports of this not > working correctly in the past. A truncate-in-place may work. Yes it did thanks, but as you said if this metadata update was failing due to out of space lends credability to the fact that the same lack of space and hence failure to update metadata could have also caused the corruption in the first place. Its interesting to note that the zpool is reporting pleanty of free space even when the root zfs volume was showing 0, so you would expect there to be pleanty of space for it be able to stop the scrub but it appears not which is definitely interesting and could point to the underlying cause? zpool list tank2 NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank2 19T 18.7T 304G 98% 1.00x ONLINE - zfs list tank2 NAME USED AVAIL REFER MOUNTPOINT tank2 13.3T 0 13.3T /tank2 Current state is:- scan: scrub in progress since Wed Oct 31 16:13:53 2012 1.64T scanned out of 18.7T at 62.8M/s, 79h12m to go 280M repaired, 8.76% done Something else that was interesting is while the scrub was running devd was using a good amount of CPU 40% of a 3.3Ghz core, which I've never seen before. Any ideas why its usage would be so high? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 00:19:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6C67FEA; Thu, 1 Nov 2012 00:19:45 +0000 (UTC) (envelope-from prvs=1652892d21=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 805E88FC08; Thu, 1 Nov 2012 00:19:43 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000903417.msg; Thu, 01 Nov 2012 00:19:42 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 01 Nov 2012 00:19:42 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1652892d21=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Peter Jeremy" References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> <20121031212346.GL3309@server.rulingia.com> Subject: Re: ZFS corruption due to lack of space? Date: Thu, 1 Nov 2012 00:19:38 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 00:19:46 -0000 ----- Original Message ----- From: "Steven Hartland" To: "Peter Jeremy" Cc: ; Sent: Thursday, November 01, 2012 12:09 AM Subject: Re: ZFS corruption due to lack of space? > On 2012-Oct-31 17:25:09 -0000, Steven Hartland wrote: >>>Been running some tests on new hardware here to verify all >>>is good. One of the tests was to fill the zfs array which >>>seems like its totally corrupted the tank. >> >>I've accidently "filled" a pool, and had multiple processes try to >>write to the full pool, without either emptying the free space reserve >>(so I could still delete the offending files) or corrupting the pool. > > Same here but its the first time I've had ZIL in place at the time so > wondering if that may be playing a factor. > >> Had you tried to read/write the raw disks before you tried the >> ZFS testing? > > Yes, didn't see any issues but then it wasn't checksuming so tbh I > wouldn't have noticed if it was silently corrupting data. > >>Do you have compression and/or dedupe enabled on the pool? > > Nope bog standard raidz2 no additional settings > >>>1. Given the information it seems like the multiple writes filling >>>the disk may have caused metadata corruption? >> >> I don't recall seeing this reported before. > > Nore me and we've been using ZFS for years, but never filled a pool > with such known simultanious access + ZIL before > >>>2. Is there anyway to stop the scrub? >> >>Other than freeing up some space, I don't think so. If this is a test >>pool that you don't need, you could try destroying it and re-creating >>it - that may be quicker and easier than recovering the existing pool. > > Artems trick of cat /dev/null > /tank2/ worked and I've now > managed to stop the scrub :) > >>>3. Surely low space should never prevent stopping a scrub? >> >> As Artem noted, ZFS is a copy-on-write filesystem. It is supposed to >> reserve some free space to allow metadata updates (stop scrubs, delete >> files, etc) even when it is "full" but I have seen reports of this not >> working correctly in the past. A truncate-in-place may work. > > Yes it did thanks, but as you said if this metadata update was failing > due to out of space lends credability to the fact that the same lack of > space and hence failure to update metadata could have also caused the > corruption in the first place. > > Its interesting to note that the zpool is reporting pleanty of free space > even when the root zfs volume was showing 0, so you would expect there > to be pleanty of space for it be able to stop the scrub but it appears > not which is definitely interesting and could point to the underlying > cause? > > zpool list tank2 > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > tank2 19T 18.7T 304G 98% 1.00x ONLINE - > > zfs list tank2 > NAME USED AVAIL REFER MOUNTPOINT > tank2 13.3T 0 13.3T /tank2 > > Current state is:- > scan: scrub in progress since Wed Oct 31 16:13:53 2012 > 1.64T scanned out of 18.7T at 62.8M/s, 79h12m to go > 280M repaired, 8.76% done > > Something else that was interesting is while the scrub was running > devd was using a good amount of CPU 40% of a 3.3Ghz core, which I've > never seen before. Any ideas why its usage would be so high? In case its useful here's the output from a zdb tank2 so far:- zdb tank2 Cached configuration: version: 28 name: 'tank2' state: 0 txg: 39502 pool_guid: 15779146362913479443 hostid: 1751781486 vdev_children: 3 vdev_tree: type: 'root' id: 0 guid: 15779146362913479443 create_txg: 4 children[0]: type: 'raidz' id: 0 guid: 8518972900227438019 nparity: 2 metaslab_array: 33 metaslab_shift: 37 ashift: 9 asize: 21004116295680 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 15577380450172137060 path: '/dev/mfisyspd0' phys_path: '/dev/mfisyspd0' whole_disk: 1 DTL: 236 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 16940350228793267704 path: '/dev/mfisyspd1' phys_path: '/dev/mfisyspd1' whole_disk: 1 DTL: 235 create_txg: 4 children[2]: type: 'disk' id: 2 guid: 9264743178245473794 path: '/dev/mfisyspd2' phys_path: '/dev/mfisyspd2' whole_disk: 1 DTL: 234 create_txg: 4 children[3]: type: 'disk' id: 3 guid: 432716341673487166 path: '/dev/mfisyspd3' phys_path: '/dev/mfisyspd3' whole_disk: 1 DTL: 233 create_txg: 4 children[4]: type: 'disk' id: 4 guid: 18217760646550913544 path: '/dev/mfisyspd4' phys_path: '/dev/mfisyspd4' whole_disk: 1 DTL: 232 create_txg: 4 children[5]: type: 'disk' id: 5 guid: 6964614355298004256 path: '/dev/mfisyspd5' phys_path: '/dev/mfisyspd5' whole_disk: 1 DTL: 231 create_txg: 4 children[6]: type: 'disk' id: 6 guid: 4397961270160308034 path: '/dev/mfisyspd6' phys_path: '/dev/mfisyspd6' whole_disk: 1 DTL: 230 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 13757670211012452260 path: '/dev/mfisyspd7p3' phys_path: '/dev/mfisyspd7p3' whole_disk: 1 metaslab_array: 32 metaslab_shift: 27 ashift: 9 asize: 14125891584 is_log: 1 DTL: 237 create_txg: 4 children[2]: type: 'disk' id: 2 guid: 7315839509249482920 path: '/dev/mfisyspd8p3' phys_path: '/dev/mfisyspd8p3' whole_disk: 1 metaslab_array: 31 metaslab_shift: 27 ashift: 9 asize: 14125891584 is_log: 1 DTL: 229 create_txg: 4 MOS Configuration: version: 28 name: 'tank2' state: 0 txg: 39502 pool_guid: 15779146362913479443 hostid: 1751781486 vdev_children: 3 vdev_tree: type: 'root' id: 0 guid: 15779146362913479443 create_txg: 4 children[0]: type: 'raidz' id: 0 guid: 8518972900227438019 nparity: 2 metaslab_array: 33 metaslab_shift: 37 ashift: 9 asize: 21004116295680 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 15577380450172137060 path: '/dev/mfisyspd0' phys_path: '/dev/mfisyspd0' whole_disk: 1 DTL: 236 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 16940350228793267704 path: '/dev/mfisyspd1' phys_path: '/dev/mfisyspd1' whole_disk: 1 DTL: 235 create_txg: 4 children[2]: type: 'disk' id: 2 guid: 9264743178245473794 path: '/dev/mfisyspd2' phys_path: '/dev/mfisyspd2' whole_disk: 1 DTL: 234 create_txg: 4 children[3]: type: 'disk' id: 3 guid: 432716341673487166 path: '/dev/mfisyspd3' phys_path: '/dev/mfisyspd3' whole_disk: 1 DTL: 233 create_txg: 4 children[4]: type: 'disk' id: 4 guid: 18217760646550913544 path: '/dev/mfisyspd4' phys_path: '/dev/mfisyspd4' whole_disk: 1 DTL: 232 create_txg: 4 children[5]: type: 'disk' id: 5 guid: 6964614355298004256 path: '/dev/mfisyspd5' phys_path: '/dev/mfisyspd5' whole_disk: 1 DTL: 231 create_txg: 4 children[6]: type: 'disk' id: 6 guid: 4397961270160308034 path: '/dev/mfisyspd6' phys_path: '/dev/mfisyspd6' whole_disk: 1 DTL: 230 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 13757670211012452260 path: '/dev/mfisyspd7p3' phys_path: '/dev/mfisyspd7p3' whole_disk: 1 metaslab_array: 32 metaslab_shift: 27 ashift: 9 asize: 14125891584 is_log: 1 DTL: 237 create_txg: 4 children[2]: type: 'disk' id: 2 guid: 7315839509249482920 path: '/dev/mfisyspd8p3' phys_path: '/dev/mfisyspd8p3' whole_disk: 1 metaslab_array: 31 metaslab_shift: 27 ashift: 9 asize: 14125891584 is_log: 1 DTL: 229 create_txg: 4 Uberblock: magic = 0000000000bab10c version = 28 txg = 39547 guid_sum = 6486691012039134504 timestamp = 1351727718 UTC = Wed Oct 31 23:55:18 2012 All DDTs are empty Metaslabs: vdev 0 metaslabs 152 offset spacemap free --------------- ------------------- --------------- ------------- metaslab 0 offset 0 spacemap 36 free 1.41G segments 4170 maxsize 1.38G freepct 1% metaslab 1 offset 2000000000 spacemap 65 free 1.45G segments 4508 maxsize 1.40G freepct 1% metaslab 2 offset 4000000000 spacemap 70 free 1.44G segments 5723 maxsize 1.39G freepct 1% metaslab 3 offset 6000000000 spacemap 77 free 1.41G segments 6635 maxsize 1.35G freepct 1% metaslab 4 offset 8000000000 spacemap 80 free 1.46G segments 6408 maxsize 1.40G freepct 1% metaslab 5 offset a000000000 spacemap 81 free 1.47G segments 6480 maxsize 1.42G freepct 1% metaslab 6 offset c000000000 spacemap 82 free 1.48G segments 6684 maxsize 1.42G freepct 1% metaslab 7 offset e000000000 spacemap 83 free 1.48G segments 6873 maxsize 1.42G freepct 1% metaslab 8 offset 10000000000 spacemap 84 free 1.48G segments 7298 maxsize 1.42G freepct 1% metaslab 9 offset 12000000000 spacemap 85 free 1.43G segments 6699 maxsize 1.37G freepct 1% metaslab 10 offset 14000000000 spacemap 88 free 1.50G segments 6781 maxsize 1.44G freepct 1% metaslab 11 offset 16000000000 spacemap 89 free 1.50G segments 6434 maxsize 1.44G freepct 1% metaslab 12 offset 18000000000 spacemap 90 free 1.51G segments 7188 maxsize 1.44G freepct 1% metaslab 13 offset 1a000000000 spacemap 91 free 1.49G segments 6712 maxsize 1.42G freepct 1% metaslab 14 offset 1c000000000 spacemap 92 free 1.52G segments 6810 maxsize 1.46G freepct 1% metaslab 15 offset 1e000000000 spacemap 93 free 1.52G segments 8306 maxsize 1.41G freepct 1% metaslab 16 offset 20000000000 spacemap 94 free 1.49G segments 21881 maxsize 660M freepct 1% metaslab 17 offset 22000000000 spacemap 97 free 1.50G segments 9590 maxsize 1.32G freepct 1% metaslab 18 offset 24000000000 spacemap 98 free 1.53G segments 6921 maxsize 1.47G freepct 1% metaslab 19 offset 26000000000 spacemap 99 free 1.53G segments 7982 maxsize 1.46G freepct 1% metaslab 20 offset 28000000000 spacemap 100 free 1.55G segments 7943 maxsize 1.48G freepct 1% metaslab 21 offset 2a000000000 spacemap 101 free 1.54G segments 8049 maxsize 1.47G freepct 1% metaslab 22 offset 2c000000000 spacemap 102 free 1.54G segments 8205 maxsize 1.46G freepct 1% metaslab 23 offset 2e000000000 spacemap 103 free 1.53G segments 11339 maxsize 1.37G freepct 1% metaslab 24 offset 30000000000 spacemap 104 free 1.55G segments 11536 maxsize 1.38G freepct 1% metaslab 25 offset 32000000000 spacemap 105 free 1.58G segments 7281 maxsize 1.50G freepct 1% metaslab 26 offset 34000000000 spacemap 108 free 1.57G segments 7917 maxsize 1.49G freepct 1% metaslab 27 offset 36000000000 spacemap 109 free 1.59G segments 8446 maxsize 1.51G freepct 1% metaslab 28 offset 38000000000 spacemap 110 free 1.59G segments 8437 maxsize 1.51G freepct 1% metaslab 29 offset 3a000000000 spacemap 35 free 1.60G segments 22991 maxsize 1.21G freepct 1% metaslab 30 offset 3c000000000 spacemap 111 free 1.57G segments 8358 maxsize 1.49G freepct 1% metaslab 31 offset 3e000000000 spacemap 112 free 1.62G segments 7724 maxsize 1.53G freepct 1% metaslab 32 offset 40000000000 spacemap 113 free 1.62G segments 8314 maxsize 1.53G freepct 1% metaslab 33 offset 42000000000 spacemap 114 free 1.61G segments 8294 maxsize 1.52G freepct 1% metaslab 34 offset 44000000000 spacemap 115 free 1.63G segments 8422 maxsize 1.54G freepct 1% metaslab 35 offset 46000000000 spacemap 116 free 1.60G segments 8125 maxsize 1.51G freepct 1% metaslab 36 offset 48000000000 spacemap 117 free 1.62G segments 8048 maxsize 1.53G freepct 1% metaslab 37 offset 4a000000000 spacemap 118 free 1.60G segments 8648 maxsize 1.51G freepct 1% metaslab 38 offset 4c000000000 spacemap 119 free 1.66G segments 8316 maxsize 1.57G freepct 1% metaslab 39 offset 4e000000000 spacemap 87 free 1.62G segments 27153 maxsize 1.05G freepct 1% metaslab 40 offset 50000000000 spacemap 121 free 1.66G segments 9314 maxsize 1.56G freepct 1% metaslab 41 offset 52000000000 spacemap 122 free 1.64G segments 9334 maxsize 1.56G freepct 1% metaslab 42 offset 54000000000 spacemap 123 free 1.67G segments 10391 maxsize 1.51G freepct 1% metaslab 43 offset 56000000000 spacemap 126 free 1.65G segments 12514 maxsize 1.49G freepct 1% metaslab 44 offset 58000000000 spacemap 127 free 1.67G segments 13441 maxsize 1.50G freepct 1% metaslab 45 offset 5a000000000 spacemap 129 free 1.70G segments 13288 maxsize 1.54G freepct 1% metaslab 46 offset 5c000000000 spacemap 96 free 1.71G segments 27184 maxsize 1.07G freepct 1% metaslab 47 offset 5e000000000 spacemap 130 free 1.69G segments 10019 maxsize 1.61G freepct 1% metaslab 48 offset 60000000000 spacemap 133 free 1.69G segments 13025 maxsize 1.53G freepct 1% metaslab 49 offset 62000000000 spacemap 135 free 1.71G segments 10562 maxsize 1.63G freepct 1% metaslab 50 offset 64000000000 spacemap 136 free 1.74G segments 9827 maxsize 1.66G freepct 1% metaslab 51 offset 66000000000 spacemap 137 free 1.73G segments 10206 maxsize 1.65G freepct 1% metaslab 52 offset 68000000000 spacemap 138 free 1.75G segments 9747 maxsize 1.67G freepct 1% metaslab 53 offset 6a000000000 spacemap 139 free 1.76G segments 14248 maxsize 1.57G freepct 1% metaslab 54 offset 6c000000000 spacemap 107 free 1.76G segments 29803 maxsize 987M freepct 1% metaslab 55 offset 6e000000000 spacemap 142 free 1.76G segments 9068 maxsize 1.68G freepct 1% metaslab 56 offset 70000000000 spacemap 143 free 1.76G segments 10561 maxsize 1.68G freepct 1% metaslab 57 offset 72000000000 spacemap 144 free 1.78G segments 10234 maxsize 1.70G freepct 1% metaslab 58 offset 74000000000 spacemap 34 free 1.79G segments 12737 maxsize 1.49G freepct 1% metaslab 59 offset 76000000000 spacemap 145 free 1.80G segments 10211 maxsize 1.71G freepct 1% metaslab 60 offset 78000000000 spacemap 146 free 1.77G segments 10696 maxsize 1.68G freepct 1% metaslab 61 offset 7a000000000 spacemap 147 free 1.81G segments 10934 maxsize 1.71G freepct 1% metaslab 62 offset 7c000000000 spacemap 148 free 1.81G segments 8698 maxsize 1.73G freepct 1% metaslab 63 offset 7e000000000 spacemap 149 free 1.82G segments 9165 maxsize 1.74G freepct 1% metaslab 64 offset 80000000000 spacemap 152 free 1.83G segments 9388 maxsize 1.74G freepct 1% metaslab 65 offset 82000000000 spacemap 154 free 1.84G segments 11321 maxsize 1.74G freepct 1% metaslab 66 offset 84000000000 spacemap 155 free 1.85G segments 10040 maxsize 1.76G freepct 1% metaslab 67 offset 86000000000 spacemap 156 free 1.86G segments 10531 maxsize 1.77G freepct 1% metaslab 68 offset 88000000000 spacemap 86 free 1.84G segments 8518 maxsize 1.73G freepct 1% metaslab 69 offset 8a000000000 spacemap 120 free 1.87G segments 18100 maxsize 1.51G freepct 1% metaslab 70 offset 8c000000000 spacemap 157 free 1.88G segments 12773 maxsize 1.70G freepct 1% metaslab 71 offset 8e000000000 spacemap 159 free 1.89G segments 11443 maxsize 1.79G freepct 1% metaslab 72 offset 90000000000 spacemap 125 free 1.90G segments 13633 maxsize 1.72G freepct 1% metaslab 73 offset 92000000000 spacemap 160 free 1.91G segments 10724 maxsize 1.81G freepct 1% metaslab 74 offset 94000000000 spacemap 161 free 1.92G segments 10550 maxsize 1.77G freepct 1% metaslab 75 offset 96000000000 spacemap 162 free 1.92G segments 10027 maxsize 1.83G freepct 1% metaslab 76 offset 98000000000 spacemap 132 free 1.93G segments 16007 maxsize 1.69G freepct 1% metaslab 77 offset 9a000000000 spacemap 164 free 1.94G segments 9721 maxsize 1.84G freepct 1% metaslab 78 offset 9c000000000 spacemap 134 free 1.95G segments 26262 maxsize 1.35G freepct 1% metaslab 79 offset 9e000000000 spacemap 165 free 1.95G segments 7968 maxsize 1.88G freepct 1% metaslab 80 offset a0000000000 spacemap 166 free 1.97G segments 7757 maxsize 1.89G freepct 1% metaslab 81 offset a2000000000 spacemap 167 free 1.97G segments 9206 maxsize 1.89G freepct 1% metaslab 82 offset a4000000000 spacemap 168 free 1.98G segments 9225 maxsize 1.89G freepct 1% metaslab 83 offset a6000000000 spacemap 106 free 1.99G segments 24197 maxsize 1.43G freepct 1% metaslab 84 offset a8000000000 spacemap 169 free 2.00G segments 9637 maxsize 1.91G freepct 1% metaslab 85 offset aa000000000 spacemap 170 free 2.01G segments 10167 maxsize 1.92G freepct 1% metaslab 86 offset ac000000000 spacemap 171 free 2.02G segments 12180 maxsize 1.85G freepct 1% metaslab 87 offset ae000000000 spacemap 174 free 2.02G segments 9716 maxsize 1.93G freepct 1% metaslab 88 offset b0000000000 spacemap 175 free 2.04G segments 10583 maxsize 1.94G freepct 1% metaslab 89 offset b2000000000 spacemap 176 free 2.05G segments 9935 maxsize 1.95G freepct 1% metaslab 90 offset b4000000000 spacemap 177 free 2.06G segments 10459 maxsize 1.96G freepct 1% metaslab 91 offset b6000000000 spacemap 178 free 2.07G segments 9396 maxsize 1.98G freepct 1% metaslab 92 offset b8000000000 spacemap 179 free 2.07G segments 8301 maxsize 1.96G freepct 1% metaslab 93 offset ba000000000 spacemap 151 free 2.08G segments 17800 maxsize 1.52G freepct 1% metaslab 94 offset bc000000000 spacemap 181 free 2.10G segments 10951 maxsize 2.00G freepct 1% metaslab 95 offset be000000000 spacemap 182 free 2.11G segments 11002 maxsize 2.01G freepct 1% metaslab 96 offset c0000000000 spacemap 183 free 2.12G segments 10855 maxsize 2.01G freepct 1% metaslab 97 offset c2000000000 spacemap 95 free 2.13G segments 13168 maxsize 1.96G freepct 1% metaslab 98 offset c4000000000 spacemap 184 free 2.13G segments 9408 maxsize 2.04G freepct 1% metaslab 99 offset c6000000000 spacemap 185 free 2.15G segments 10694 maxsize 2.04G freepct 1% metaslab 100 offset c8000000000 spacemap 186 free 2.16G segments 10563 maxsize 2.05G freepct 1% metaslab 101 offset ca000000000 spacemap 187 free 2.17G segments 11059 maxsize 2.06G freepct 1% metaslab 102 offset cc000000000 spacemap 188 free 2.18G segments 11516 maxsize 2.07G freepct 1% metaslab 103 offset ce000000000 spacemap 189 free 2.19G segments 10700 maxsize 2.08G freepct 1% metaslab 104 offset d0000000000 spacemap 163 free 2.20G segments 7869 maxsize 1.77G freepct 1% metaslab 105 offset d2000000000 spacemap 131 free 2.22G segments 11941 maxsize 2.08G freepct 1% metaslab 106 offset d4000000000 spacemap 190 free 9.24G segments 11407 maxsize 2.11G freepct 7% metaslab 107 offset d6000000000 spacemap 141 free 2.24G segments 13038 maxsize 2.00G freepct 1% metaslab 108 offset d8000000000 spacemap 192 free 9.7G segments 10472 maxsize 2.13G freepct 7% metaslab 109 offset da000000000 spacemap 193 free 8.61G segments 11389 maxsize 2.14G freepct 6% metaslab 110 offset dc000000000 spacemap 194 free 6.34G segments 10513 maxsize 2.16G freepct 4% metaslab 111 offset de000000000 spacemap 195 free 7.58G segments 10168 maxsize 2.17G freepct 5% metaslab 112 offset e0000000000 spacemap 197 free 7.14G segments 6922 maxsize 2.22G freepct 5% metaslab 113 offset e2000000000 spacemap 198 free 2.30G segments 6757 maxsize 2.24G freepct 1% metaslab 114 offset e4000000000 spacemap 199 free 2.32G segments 7008 maxsize 2.26G freepct 1% metaslab 115 offset e6000000000 spacemap 200 free 2.33G segments 6518 maxsize 2.27G freepct 1% metaslab 116 offset e8000000000 spacemap 173 free 2.35G segments 13857 maxsize 1.92G freepct 1% metaslab 117 offset ea000000000 spacemap 201 free 2.36G segments 7124 maxsize 2.30G freepct 1% metaslab 118 offset ec000000000 spacemap 202 free 2.37G segments 6936 maxsize 2.31G freepct 1% metaslab 119 offset ee000000000 spacemap 203 free 2.38G segments 6679 maxsize 2.32G freepct 1% metaslab 120 offset f0000000000 spacemap 204 free 2.39G segments 6818 maxsize 2.34G freepct 1% metaslab 121 offset f2000000000 spacemap 205 free 2.41G segments 7423 maxsize 2.34G freepct 1% metaslab 122 offset f4000000000 spacemap 150 free 2.42G segments 15678 maxsize 2.14G freepct 1% metaslab 123 offset f6000000000 spacemap 158 free 2.43G segments 9980 maxsize 2.28G freepct 1% metaslab 124 offset f8000000000 spacemap 180 free 2.45G segments 11702 maxsize 1.71G freepct 1% metaslab 125 offset fa000000000 spacemap 206 free 2.46G segments 7070 maxsize 2.40G freepct 1% metaslab 126 offset fc000000000 spacemap 124 free 2.47G segments 11485 maxsize 2.31G freepct 1% metaslab 127 offset fe000000000 spacemap 128 free 2.49G segments 2051 maxsize 2.42G freepct 1% metaslab 128 offset 100000000000 spacemap 207 free 2.50G segments 7309 maxsize 2.44G freepct 1% metaslab 129 offset 102000000000 spacemap 208 free 2.52G segments 7151 maxsize 2.46G freepct 1% metaslab 130 offset 104000000000 spacemap 209 free 2.52G segments 6041 maxsize 2.47G freepct 1% metaslab 131 offset 106000000000 spacemap 210 free 2.54G segments 6910 maxsize 2.47G freepct 1% metaslab 132 offset 108000000000 spacemap 211 free 2.56G segments 6816 maxsize 2.50G freepct 1% metaslab 133 offset 10a000000000 spacemap 212 free 2.57G segments 6182 maxsize 2.51G freepct 2% metaslab 134 offset 10c000000000 spacemap 213 free 2.59G segments 7541 maxsize 2.52G freepct 2% metaslab 135 offset 10e000000000 spacemap 214 free 2.61G segments 7810 maxsize 2.53G freepct 2% metaslab 136 offset 110000000000 spacemap 215 free 2.62G segments 6822 maxsize 2.56G freepct 2% metaslab 137 offset 112000000000 spacemap 191 free 9.39G segments 10891 maxsize 2.28G freepct 7% metaslab 138 offset 114000000000 spacemap 216 free 2.65G segments 7295 maxsize 2.58G freepct 2% metaslab 139 offset 116000000000 spacemap 217 free 2.67G segments 7435 maxsize 2.60G freepct 2% metaslab 140 offset 118000000000 spacemap 218 free 2.68G segments 6952 maxsize 2.62G freepct 2% metaslab 141 offset 11a000000000 spacemap 196 free 2.70G segments 5975 maxsize 2.37G freepct 2% metaslab 142 offset 11c000000000 spacemap 219 free 2.72G segments 7547 maxsize 2.65G freepct 2% metaslab 143 offset 11e000000000 spacemap 220 free 2.74G segments 7570 maxsize 2.67G freepct 2% metaslab 144 offset 120000000000 spacemap 221 free 2.75G segments 7321 maxsize 2.69G freepct 2% metaslab 145 offset 122000000000 spacemap 172 free 2.77G segments 3490 maxsize 2.68G freepct 2% metaslab 146 offset 124000000000 spacemap 222 free 2.79G segments 7448 maxsize 2.72G freepct 2% metaslab 147 offset 126000000000 spacemap 223 free 2.81G segments 7309 maxsize 2.74G freepct 2% metaslab 148 offset 128000000000 spacemap 224 free 2.82G segments 7367 maxsize 2.75G freepct 2% metaslab 149 offset 12a000000000 spacemap 225 free 2.84G segments 7249 maxsize 2.77G freepct 2% metaslab 150 offset 12c000000000 spacemap 226 free 2.86G segments 8091 maxsize 2.78G freepct 2% metaslab 151 offset 12e000000000 spacemap 153 free 2.88G segments 2771 maxsize 2.74G freepct 2% vdev 1 metaslabs 105 offset spacemap free --------------- ------------------- --------------- ------------- metaslab 0 offset 0 spacemap 38 free 128M segments 1 maxsize 128M freepct 99% metaslab 1 offset 8000000 spacemap 39 free 128M segments 1 maxsize 128M freepct 100% metaslab 2 offset 10000000 spacemap 42 free 128M segments 1 maxsize 128M freepct 100% metaslab 3 offset 18000000 spacemap 41 free 128M segments 1 maxsize 128M freepct 100% metaslab 4 offset 20000000 spacemap 51 free 128M segments 1 maxsize 128M freepct 100% metaslab 5 offset 28000000 spacemap 50 free 128M segments 1 maxsize 128M freepct 100% metaslab 6 offset 30000000 spacemap 49 free 128M segments 1 maxsize 128M freepct 100% metaslab 7 offset 38000000 spacemap 48 free 128M segments 1 maxsize 128M freepct 100% metaslab 8 offset 40000000 spacemap 47 free 128M segments 1 maxsize 128M freepct 100% metaslab 9 offset 48000000 spacemap 46 free 128M segments 1 maxsize 128M freepct 100% metaslab 10 offset 50000000 spacemap 45 free 128M segments 1 maxsize 128M freepct 100% metaslab 11 offset 58000000 spacemap 59 free 128M segments 1 maxsize 128M freepct 100% metaslab 12 offset 60000000 spacemap 62 free 128M segments 1 maxsize 128M freepct 100% metaslab 13 offset 68000000 spacemap 61 free 128M segments 1 maxsize 128M freepct 100% metaslab 14 offset 70000000 spacemap 67 free 128M segments 1 maxsize 128M freepct 100% metaslab 15 offset 78000000 spacemap 66 free 128M segments 1 maxsize 128M freepct 100% metaslab 16 offset 80000000 spacemap 74 free 128M segments 1 maxsize 128M freepct 100% metaslab 17 offset 88000000 spacemap 73 free 128M segments 1 maxsize 128M freepct 100% metaslab 18 offset 90000000 spacemap 75 free 128M segments 1 maxsize 128M freepct 100% metaslab 19 offset 98000000 spacemap 78 free 128M segments 1 maxsize 128M freepct 100% metaslab 20 offset a0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 21 offset a8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 22 offset b0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 23 offset b8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 24 offset c0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 25 offset c8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 26 offset d0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 27 offset d8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 28 offset e0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 29 offset e8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 30 offset f0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 31 offset f8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 32 offset 100000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 33 offset 108000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 34 offset 110000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 35 offset 118000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 36 offset 120000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 37 offset 128000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 38 offset 130000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 39 offset 138000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 40 offset 140000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 41 offset 148000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 42 offset 150000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 43 offset 158000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 44 offset 160000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 45 offset 168000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 46 offset 170000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 47 offset 178000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 48 offset 180000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 49 offset 188000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 50 offset 190000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 51 offset 198000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 52 offset 1a0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 53 offset 1a8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 54 offset 1b0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 55 offset 1b8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 56 offset 1c0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 57 offset 1c8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 58 offset 1d0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 59 offset 1d8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 60 offset 1e0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 61 offset 1e8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 62 offset 1f0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 63 offset 1f8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 64 offset 200000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 65 offset 208000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 66 offset 210000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 67 offset 218000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 68 offset 220000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 69 offset 228000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 70 offset 230000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 71 offset 238000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 72 offset 240000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 73 offset 248000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 74 offset 250000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 75 offset 258000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 76 offset 260000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 77 offset 268000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 78 offset 270000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 79 offset 278000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 80 offset 280000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 81 offset 288000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 82 offset 290000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 83 offset 298000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 84 offset 2a0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 85 offset 2a8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 86 offset 2b0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 87 offset 2b8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 88 offset 2c0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 89 offset 2c8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 90 offset 2d0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 91 offset 2d8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 92 offset 2e0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 93 offset 2e8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 94 offset 2f0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 95 offset 2f8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 96 offset 300000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 97 offset 308000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 98 offset 310000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 99 offset 318000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 100 offset 320000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 101 offset 328000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 102 offset 330000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 103 offset 338000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 104 offset 340000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% vdev 2 metaslabs 105 offset spacemap free --------------- ------------------- --------------- ------------- metaslab 0 offset 0 spacemap 37 free 128M segments 1 maxsize 128M freepct 100% metaslab 1 offset 8000000 spacemap 40 free 128M segments 1 maxsize 128M freepct 100% metaslab 2 offset 10000000 spacemap 44 free 128M segments 1 maxsize 128M freepct 100% metaslab 3 offset 18000000 spacemap 43 free 128M segments 1 maxsize 128M freepct 100% metaslab 4 offset 20000000 spacemap 58 free 128M segments 1 maxsize 128M freepct 100% metaslab 5 offset 28000000 spacemap 57 free 128M segments 1 maxsize 128M freepct 100% metaslab 6 offset 30000000 spacemap 56 free 128M segments 1 maxsize 128M freepct 100% metaslab 7 offset 38000000 spacemap 55 free 128M segments 1 maxsize 128M freepct 100% metaslab 8 offset 40000000 spacemap 54 free 128M segments 1 maxsize 128M freepct 100% metaslab 9 offset 48000000 spacemap 53 free 128M segments 1 maxsize 128M freepct 100% metaslab 10 offset 50000000 spacemap 52 free 128M segments 1 maxsize 128M freepct 100% metaslab 11 offset 58000000 spacemap 60 free 128M segments 1 maxsize 128M freepct 100% metaslab 12 offset 60000000 spacemap 64 free 128M segments 1 maxsize 128M freepct 100% metaslab 13 offset 68000000 spacemap 63 free 128M segments 1 maxsize 128M freepct 100% metaslab 14 offset 70000000 spacemap 69 free 128M segments 1 maxsize 128M freepct 100% metaslab 15 offset 78000000 spacemap 68 free 128M segments 1 maxsize 128M freepct 100% metaslab 16 offset 80000000 spacemap 72 free 128M segments 1 maxsize 128M freepct 100% metaslab 17 offset 88000000 spacemap 71 free 128M segments 1 maxsize 128M freepct 100% metaslab 18 offset 90000000 spacemap 76 free 128M segments 1 maxsize 128M freepct 100% metaslab 19 offset 98000000 spacemap 79 free 128M segments 1 maxsize 128M freepct 100% metaslab 20 offset a0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 21 offset a8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 22 offset b0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 23 offset b8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 24 offset c0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 25 offset c8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 26 offset d0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 27 offset d8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 28 offset e0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 29 offset e8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 30 offset f0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 31 offset f8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 32 offset 100000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 33 offset 108000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 34 offset 110000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 35 offset 118000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 36 offset 120000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 37 offset 128000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 38 offset 130000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 39 offset 138000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 40 offset 140000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 41 offset 148000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 42 offset 150000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 43 offset 158000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 44 offset 160000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 45 offset 168000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 46 offset 170000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 47 offset 178000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 48 offset 180000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 49 offset 188000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 50 offset 190000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 51 offset 198000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 52 offset 1a0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 53 offset 1a8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 54 offset 1b0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 55 offset 1b8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 56 offset 1c0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 57 offset 1c8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 58 offset 1d0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 59 offset 1d8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 60 offset 1e0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 61 offset 1e8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 62 offset 1f0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 63 offset 1f8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 64 offset 200000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 65 offset 208000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 66 offset 210000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 67 offset 218000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 68 offset 220000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 69 offset 228000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 70 offset 230000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 71 offset 238000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 72 offset 240000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 73 offset 248000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 74 offset 250000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 75 offset 258000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 76 offset 260000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 77 offset 268000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 78 offset 270000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 79 offset 278000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 80 offset 280000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 81 offset 288000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 82 offset 290000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 83 offset 298000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 84 offset 2a0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 85 offset 2a8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 86 offset 2b0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 87 offset 2b8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 88 offset 2c0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 89 offset 2c8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 90 offset 2d0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 91 offset 2d8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 92 offset 2e0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 93 offset 2e8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 94 offset 2f0000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 95 offset 2f8000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 96 offset 300000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 97 offset 308000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 98 offset 310000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 99 offset 318000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 100 offset 320000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 101 offset 328000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 102 offset 330000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 103 offset 338000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% metaslab 104 offset 340000000 spacemap 0 free 128M segments 1 maxsize 128M freepct 100% Dataset mos [META], ID 0, cr_txg 4, 459M, 235 objects Object lvl iblk dblk dsize lsize %full type 0 2 16K 16K 256K 128K 91.80 DMU dnode 1 1 16K 16K 19.0K 32K 100.00 object directory 2 1 16K 512 0 512 0.00 DSL directory 3 1 16K 512 3.00K 512 100.00 DSL props 4 1 16K 512 3.00K 512 100.00 DSL directory child map 5 1 16K 512 0 512 0.00 DSL directory 6 1 16K 512 3.00K 512 100.00 DSL props 7 1 16K 512 3.00K 512 100.00 DSL directory child map 8 1 16K 512 0 512 0.00 DSL directory 9 1 16K 512 3.00K 512 100.00 DSL props 10 1 16K 512 3.00K 512 100.00 DSL directory child map 11 1 16K 128K 0 128K 0.00 bpobj 12 1 16K 512 0 512 0.00 DSL directory 13 1 16K 512 3.00K 512 100.00 DSL props 14 1 16K 512 3.00K 512 100.00 DSL directory child map 15 1 16K 512 0 512 0.00 DSL dataset 16 1 16K 512 3.00K 512 100.00 DSL dataset snap map 17 1 16K 512 3.00K 512 100.00 DSL deadlist map 18 1 16K 512 0 512 0.00 DSL dataset 19 1 16K 512 3.00K 512 100.00 DSL deadlist map 20 1 16K 128K 0 128K 0.00 bpobj 21 1 16K 512 0 512 0.00 DSL dataset 22 1 16K 512 3.00K 512 100.00 DSL dataset snap map 23 1 16K 512 3.00K 512 100.00 DSL deadlist map 24 1 16K 128K 0 128K 0.00 bpobj 25 1 16K 512 3.00K 512 100.00 DSL dataset next clones 26 1 16K 512 3.00K 512 100.00 DSL dir clones 27 1 16K 16K 51.0K 16K 100.00 packed nvlist 28 1 16K 16K 51.0K 16K 100.00 bpobj (Z=uncompressed) 29 1 16K 128K 16K 128K 100.00 SPA history 30 1 16K 16K 6.50K 16K 100.00 packed nvlist 31 1 16K 512 3.00K 512 100.00 object array 32 1 16K 512 3.00K 512 100.00 object array 33 1 16K 512 9.5K 1.50K 100.00 object array 34 2 16K 4K 467K 176K 100.00 SPA space map 35 2 16K 4K 851K 296K 100.00 SPA space map 36 2 16K 4K 275K 88.0K 100.00 SPA space map 37 1 16K 4K 0 4K 0.00 SPA space map 38 1 16K 4K 3.00K 4K 100.00 SPA space map 39 1 16K 4K 0 4K 0.00 SPA space map 40 1 16K 4K 0 4K 0.00 SPA space map 41 1 16K 4K 0 4K 0.00 SPA space map 42 1 16K 4K 0 4K 0.00 SPA space map 43 1 16K 4K 0 4K 0.00 SPA space map 44 1 16K 4K 0 4K 0.00 SPA space map 45 1 16K 4K 0 4K 0.00 SPA space map 46 1 16K 4K 0 4K 0.00 SPA space map 47 1 16K 4K 3.00K 4K 100.00 SPA space map 48 1 16K 4K 0 4K 0.00 SPA space map 49 1 16K 4K 0 4K 0.00 SPA space map 50 1 16K 4K 0 4K 0.00 SPA space map 51 1 16K 4K 0 4K 0.00 SPA space map 52 1 16K 4K 0 4K 0.00 SPA space map 53 1 16K 4K 0 4K 0.00 SPA space map 54 1 16K 4K 3.00K 4K 100.00 SPA space map 55 1 16K 4K 0 4K 0.00 SPA space map 56 1 16K 4K 0 4K 0.00 SPA space map 57 1 16K 4K 0 4K 0.00 SPA space map 58 1 16K 4K 0 4K 0.00 SPA space map 59 1 16K 4K 0 4K 0.00 SPA space map 60 1 16K 4K 0 4K 0.00 SPA space map 61 1 16K 4K 0 4K 0.00 SPA space map 62 1 16K 4K 0 4K 0.00 SPA space map 63 1 16K 4K 0 4K 0.00 SPA space map 64 1 16K 4K 0 4K 0.00 SPA space map 65 2 16K 4K 291K 92.0K 100.00 SPA space map 66 1 16K 4K 0 4K 0.00 SPA space map 67 1 16K 4K 0 4K 0.00 SPA space map 68 1 16K 4K 0 4K 0.00 SPA space map 69 1 16K 4K 0 4K 0.00 SPA space map 70 2 16K 4K 311K 100K 100.00 SPA space map 71 1 16K 4K 0 4K 0.00 SPA space map 72 1 16K 4K 0 4K 0.00 SPA space map 73 1 16K 4K 0 4K 0.00 SPA space map 74 1 16K 4K 0 4K 0.00 SPA space map 75 1 16K 4K 0 4K 0.00 SPA space map 76 1 16K 4K 0 4K 0.00 SPA space map 77 2 16K 4K 336K 104K 100.00 SPA space map 78 1 16K 4K 0 4K 0.00 SPA space map 79 1 16K 4K 0 4K 0.00 SPA space map 80 2 16K 4K 330K 104K 100.00 SPA space map 81 2 16K 4K 333K 104K 100.00 SPA space map 82 2 16K 4K 339K 108K 100.00 SPA space map 83 2 16K 4K 343K 108K 100.00 SPA space map 84 2 16K 4K 368K 116K 100.00 SPA space map 85 2 16K 4K 339K 108K 100.00 SPA space map 86 2 16K 4K 384K 120K 100.00 SPA space map 87 2 16K 4K 1.15M 368K 100.00 SPA space map 88 2 16K 4K 346K 108K 100.00 SPA space map 89 2 16K 4K 339K 108K 100.00 SPA space map 90 2 16K 4K 349K 108K 100.00 SPA space map 91 2 16K 4K 339K 108K 100.00 SPA space map 92 2 16K 4K 365K 116K 100.00 SPA space map 93 2 16K 4K 391K 120K 100.00 SPA space map 94 2 16K 4K 867K 268K 100.00 SPA space map 95 2 16K 4K 506K 156K 100.00 SPA space map 96 2 16K 4K 858K 268K 100.00 SPA space map 97 2 16K 4K 490K 152K 100.00 SPA space map 98 2 16K 4K 346K 112K 100.00 SPA space map 99 2 16K 4K 371K 116K 100.00 SPA space map 100 2 16K 4K 362K 112K 100.00 SPA space map 101 2 16K 4K 384K 120K 100.00 SPA space map 102 2 16K 4K 400K 124K 100.00 SPA space map 103 2 16K 4K 522K 160K 100.00 SPA space map 104 2 16K 4K 477K 148K 100.00 SPA space map 105 2 16K 4K 346K 112K 100.00 SPA space map 106 2 16K 4K 774K 240K 100.00 SPA space map 107 2 16K 4K 906K 312K 100.00 SPA space map 108 2 16K 4K 359K 112K 100.00 SPA space map 109 2 16K 4K 387K 120K 100.00 SPA space map 110 2 16K 4K 387K 120K 100.00 SPA space map 111 2 16K 4K 413K 128K 100.00 SPA space map 112 2 16K 4K 375K 120K 100.00 SPA space map 113 2 16K 4K 378K 116K 100.00 SPA space map 114 2 16K 4K 410K 128K 100.00 SPA space map 115 2 16K 4K 400K 124K 100.00 SPA space map 116 2 16K 4K 381K 116K 100.00 SPA space map 117 2 16K 4K 387K 120K 100.00 SPA space map 118 2 16K 4K 397K 124K 100.00 SPA space map 119 2 16K 4K 394K 120K 100.00 SPA space map 120 2 16K 4K 826K 256K 100.00 SPA space map 121 2 16K 4K 407K 124K 100.00 SPA space map 122 2 16K 4K 429K 132K 100.00 SPA space map 123 2 16K 4K 451K 140K 100.00 SPA space map 124 2 16K 4K 461K 144K 100.00 SPA space map 125 2 16K 4K 519K 160K 100.00 SPA space map 126 2 16K 4K 477K 148K 100.00 SPA space map 127 2 16K 4K 605K 188K 100.00 SPA space map 128 2 16K 4K 227K 100K 100.00 SPA space map 129 2 16K 4K 528K 164K 100.00 SPA space map 130 2 16K 4K 426K 132K 100.00 SPA space map 131 2 16K 4K 528K 164K 100.00 SPA space map 132 2 16K 4K 589K 184K 100.00 SPA space map 133 2 16K 4K 605K 188K 100.00 SPA space map 134 2 16K 4K 790K 276K 100.00 SPA space map 135 2 16K 4K 439K 136K 100.00 SPA space map 136 2 16K 4K 423K 132K 100.00 SPA space map 137 2 16K 4K 455K 140K 100.00 SPA space map 138 2 16K 4K 410K 128K 100.00 SPA space map 139 2 16K 4K 528K 164K 100.00 SPA space map 141 2 16K 4K 531K 164K 100.00 SPA space map 142 2 16K 4K 397K 124K 100.00 SPA space map 143 2 16K 4K 439K 136K 100.00 SPA space map 144 2 16K 4K 423K 132K 100.00 SPA space map 145 2 16K 4K 419K 132K 100.00 SPA space map 146 2 16K 4K 477K 148K 100.00 SPA space map 147 2 16K 4K 461K 144K 100.00 SPA space map 148 2 16K 4K 384K 120K 100.00 SPA space map 149 2 16K 4K 403K 124K 100.00 SPA space map 150 2 16K 4K 560K 172K 100.00 SPA space map 151 2 16K 4K 586K 212K 100.00 SPA space map 152 2 16K 4K 407K 128K 100.00 SPA space map 153 2 16K 4K 183K 88.0K 100.00 SPA space map 154 2 16K 4K 506K 156K 100.00 SPA space map 155 2 16K 4K 506K 156K 100.00 SPA space map 156 2 16K 4K 432K 136K 100.00 SPA space map 157 2 16K 4K 499K 156K 100.00 SPA space map 158 2 16K 4K 442K 140K 100.00 SPA space map 159 2 16K 4K 448K 140K 100.00 SPA space map 160 2 16K 4K 435K 136K 100.00 SPA space map 161 2 16K 4K 471K 148K 100.00 SPA space map 162 2 16K 4K 435K 140K 100.00 SPA space map 163 2 16K 4K 343K 136K 100.00 SPA space map 164 2 16K 4K 426K 132K 100.00 SPA space map 165 2 16K 4K 365K 124K 100.00 SPA space map 166 2 16K 4K 371K 120K 100.00 SPA space map 167 2 16K 4K 416K 136K 100.00 SPA space map 168 2 16K 4K 426K 132K 100.00 SPA space map 169 2 16K 4K 419K 132K 100.00 SPA space map 170 2 16K 4K 461K 144K 100.00 SPA space map 171 2 16K 4K 541K 156K 100.00 SPA space map 172 2 16K 4K 237K 100K 100.00 SPA space map 173 2 16K 4K 531K 176K 100.00 SPA space map 174 2 16K 4K 426K 136K 100.00 SPA space map 175 2 16K 4K 445K 140K 100.00 SPA space map 176 2 16K 4K 426K 136K 100.00 SPA space map 177 2 16K 4K 451K 140K 100.00 SPA space map 178 2 16K 4K 423K 136K 100.00 SPA space map 179 2 16K 4K 413K 136K 100.00 SPA space map 180 2 16K 4K 439K 164K 100.00 SPA space map 181 2 16K 4K 471K 148K 100.00 SPA space map 182 2 16K 4K 458K 144K 100.00 SPA space map 183 2 16K 4K 471K 148K 100.00 SPA space map 184 2 16K 4K 419K 132K 100.00 SPA space map 185 2 16K 4K 490K 152K 100.00 SPA space map 186 2 16K 4K 445K 140K 100.00 SPA space map 187 2 16K 4K 464K 144K 100.00 SPA space map 188 2 16K 4K 467K 148K 100.00 SPA space map 189 2 16K 4K 451K 140K 100.00 SPA space map 190 2 16K 4K 522K 164K 100.00 SPA space map 191 2 16K 4K 503K 144K 100.00 SPA space map 192 2 16K 4K 544K 156K 100.00 SPA space map 193 2 16K 4K 535K 168K 100.00 SPA space map 194 2 16K 4K 487K 152K 100.00 SPA space map 195 2 16K 4K 429K 136K 100.00 SPA space map 196 2 16K 4K 291K 120K 100.00 SPA space map 197 2 16K 4K 339K 112K 100.00 SPA space map 198 2 16K 4K 359K 124K 100.00 SPA space map 199 2 16K 4K 311K 120K 100.00 SPA space map 200 2 16K 4K 314K 116K 100.00 SPA space map 201 2 16K 4K 336K 128K 100.00 SPA space map 202 2 16K 4K 317K 120K 100.00 SPA space map 203 2 16K 4K 327K 120K 100.00 SPA space map 204 2 16K 4K 346K 124K 100.00 SPA space map 205 2 16K 4K 323K 124K 100.00 SPA space map 206 2 16K 4K 339K 116K 100.00 SPA space map 207 2 16K 4K 349K 124K 100.00 SPA space map 208 2 16K 4K 333K 124K 100.00 SPA space map 209 2 16K 4K 291K 112K 100.00 SPA space map 210 2 16K 4K 336K 120K 100.00 SPA space map 211 2 16K 4K 320K 120K 100.00 SPA space map 212 2 16K 4K 291K 112K 100.00 SPA space map 213 2 16K 4K 349K 128K 100.00 SPA space map 214 2 16K 4K 397K 132K 100.00 SPA space map 215 2 16K 4K 330K 116K 100.00 SPA space map 216 2 16K 4K 320K 120K 100.00 SPA space map 217 2 16K 4K 394K 132K 100.00 SPA space map 218 2 16K 4K 336K 120K 100.00 SPA space map 219 2 16K 4K 327K 124K 100.00 SPA space map 220 2 16K 4K 349K 128K 100.00 SPA space map 221 2 16K 4K 391K 128K 100.00 SPA space map 222 2 16K 4K 339K 124K 100.00 SPA space map 223 2 16K 4K 339K 124K 100.00 SPA space map 224 2 16K 4K 365K 124K 100.00 SPA space map 225 2 16K 4K 346K 124K 100.00 SPA space map 226 2 16K 4K 400K 136K 100.00 SPA space map 228 3 16K 16K 395M 433M 99.95 persistent error log 229 1 16K 4K 0 4K 0.00 SPA space map 230 1 16K 4K 0 4K 0.00 SPA space map 231 1 16K 4K 0 4K 0.00 SPA space map 232 1 16K 4K 0 4K 0.00 SPA space map 233 1 16K 4K 0 4K 0.00 SPA space map 234 1 16K 4K 0 4K 0.00 SPA space map 235 1 16K 4K 0 4K 0.00 SPA space map 236 1 16K 4K 0 4K 0.00 SPA space map 237 1 16K 4K 0 4K 0.00 SPA space map Dataset tank2 [ZPL], ID 21, cr_txg 1, 13.3T, 37 objects ZIL header: claim_txg 0, claim_blk_seq 0, claim_lr_seq 0 replay_seq 0, flags 0x0 Object lvl iblk dblk dsize lsize %full type 0 7 16K 16K 40.5K 32K 57.81 DMU dnode -1 1 16K 512 2K 512 100.00 ZFS user/group used -2 1 16K 512 2K 512 100.00 ZFS user/group used 1 1 16K 512 2K 512 100.00 ZFS master node 2 1 16K 512 2K 512 100.00 SA master node 3 1 16K 512 2K 512 100.00 ZFS delete queue 4 1 16K 1.50K 2K 1.50K 100.00 ZFS directory 5 1 16K 1.50K 2K 1.50K 100.00 SA attr registration 6 1 16K 16K 10.5K 32K 100.00 SA attr layouts 7 1 16K 512 2K 512 100.00 ZFS directory 8 5 16K 128K 510G 510G 100.00 ZFS plain file 9 5 16K 128K 476G 476G 100.00 ZFS plain file 10 5 16K 128K 473G 473G 100.00 ZFS plain file 11 5 16K 128K 467G 467G 100.00 ZFS plain file 12 5 16K 128K 428G 428G 100.00 ZFS plain file 13 5 16K 128K 455G 455G 100.00 ZFS plain file 14 5 16K 128K 478G 478G 100.00 ZFS plain file 15 5 16K 128K 517G 517G 100.00 ZFS plain file 16 5 16K 128K 487G 487G 100.00 ZFS plain file 17 5 16K 128K 513G 513G 100.00 ZFS plain file 18 5 16K 128K 489G 489G 100.00 ZFS plain file 19 5 16K 128K 494G 493G 100.00 ZFS plain file 20 5 16K 128K 492G 492G 100.00 ZFS plain file 21 5 16K 128K 488G 487G 100.00 ZFS plain file 22 1 16K 1K 2K 1K 100.00 ZFS directory 23 4 16K 128K 107G 107G 100.00 ZFS plain file 24 4 16K 128K 92.4G 92.4G 100.00 ZFS plain file 25 4 16K 128K 97.2G 97.2G 100.00 ZFS plain file 26 4 16K 128K 0 128K 0.00 ZFS plain file 27 4 16K 128K 149G 149G 100.00 ZFS plain file 28 4 16K 128K 221G 221G 100.00 ZFS plain file 29 4 16K 128K 93.8G 93.8G 100.00 ZFS plain file 30 4 16K 128K 66.0G 66.0G 100.00 ZFS plain file 31 5 16K 128K 5.74T 5.74T 100.00 ZFS plain file 32 4 16K 128K 48.0G 48.0G 100.00 ZFS plain file 33 4 16K 128K 12.0G 12.0G 100.00 ZFS plain file 34 4 16K 128K 11.5G 11.5G 100.00 ZFS plain file 35 4 16K 128K 11.6G 11.5G 100.00 ZFS plain file 36 4 16K 128K 29.9G 29.8G 100.00 ZFS plain file 37 1 16K 512 0 512 0.00 ZFS plain file ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 02:56:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9240596; Thu, 1 Nov 2012 02:56:19 +0000 (UTC) (envelope-from prvs=1652892d21=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3598FC08; Thu, 1 Nov 2012 02:56:16 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000904511.msg; Thu, 01 Nov 2012 02:56:14 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 01 Nov 2012 02:56:14 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1652892d21=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <9DB937FEA7634C4BAC49EF5823F93CA3@multiplay.co.uk> From: "Steven Hartland" To: "Steven Hartland" , "Peter Jeremy" References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> <20121031212346.GL3309@server.rulingia.com> Subject: Re: ZFS corruption due to lack of space? Date: Thu, 1 Nov 2012 02:56:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 02:56:20 -0000 ----- Original Message ----- From: "Steven Hartland" To: "Peter Jeremy" Cc: ; Sent: Thursday, November 01, 2012 12:19 AM Subject: Re: ZFS corruption due to lack of space? > > ----- Original Message ----- > From: "Steven Hartland" > To: "Peter Jeremy" > Cc: ; > Sent: Thursday, November 01, 2012 12:09 AM > Subject: Re: ZFS corruption due to lack of space? > > >> On 2012-Oct-31 17:25:09 -0000, Steven Hartland wrote: >>>>Been running some tests on new hardware here to verify all >>>>is good. One of the tests was to fill the zfs array which >>>>seems like its totally corrupted the tank. >>> >>>I've accidently "filled" a pool, and had multiple processes try to >>>write to the full pool, without either emptying the free space reserve >>>(so I could still delete the offending files) or corrupting the pool. >> >> Same here but its the first time I've had ZIL in place at the time so >> wondering if that may be playing a factor. >> >>> Had you tried to read/write the raw disks before you tried the >>> ZFS testing? >> >> Yes, didn't see any issues but then it wasn't checksuming so tbh I >> wouldn't have noticed if it was silently corrupting data. >> >>>Do you have compression and/or dedupe enabled on the pool? >> >> Nope bog standard raidz2 no additional settings >> >>>>1. Given the information it seems like the multiple writes filling >>>>the disk may have caused metadata corruption? >>> >>> I don't recall seeing this reported before. >> >> Nore me and we've been using ZFS for years, but never filled a pool >> with such known simultanious access + ZIL before >> >>>>2. Is there anyway to stop the scrub? >>> >>>Other than freeing up some space, I don't think so. If this is a test >>>pool that you don't need, you could try destroying it and re-creating >>>it - that may be quicker and easier than recovering the existing pool. >> >> Artems trick of cat /dev/null > /tank2/ worked and I've now >> managed to stop the scrub :) >> >>>>3. Surely low space should never prevent stopping a scrub? >>> >>> As Artem noted, ZFS is a copy-on-write filesystem. It is supposed to >>> reserve some free space to allow metadata updates (stop scrubs, delete >>> files, etc) even when it is "full" but I have seen reports of this not >>> working correctly in the past. A truncate-in-place may work. >> >> Yes it did thanks, but as you said if this metadata update was failing >> due to out of space lends credability to the fact that the same lack of >> space and hence failure to update metadata could have also caused the >> corruption in the first place. >> >> Its interesting to note that the zpool is reporting pleanty of free space >> even when the root zfs volume was showing 0, so you would expect there >> to be pleanty of space for it be able to stop the scrub but it appears >> not which is definitely interesting and could point to the underlying >> cause? >> >> zpool list tank2 >> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >> tank2 19T 18.7T 304G 98% 1.00x ONLINE - >> >> zfs list tank2 >> NAME USED AVAIL REFER MOUNTPOINT >> tank2 13.3T 0 13.3T /tank2 >> >> Current state is:- >> scan: scrub in progress since Wed Oct 31 16:13:53 2012 >> 1.64T scanned out of 18.7T at 62.8M/s, 79h12m to go >> 280M repaired, 8.76% done >> >> Something else that was interesting is while the scrub was running >> devd was using a good amount of CPU 40% of a 3.3Ghz core, which I've >> never seen before. Any ideas why its usage would be so high? > > > In case its useful here's the output from a zdb tank2 so far:- > zdb tank2 > > Cached configuration: > version: 28 > name: 'tank2' > state: 0 > txg: 39502 > pool_guid: 15779146362913479443 > hostid: 1751781486 > vdev_children: 3 > vdev_tree: > type: 'root' > id: 0 > guid: 15779146362913479443 > create_txg: 4 > children[0]: > type: 'raidz' > id: 0 > guid: 8518972900227438019 > nparity: 2 > metaslab_array: 33 > metaslab_shift: 37 > ashift: 9 > asize: 21004116295680 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 15577380450172137060 > path: '/dev/mfisyspd0' > phys_path: '/dev/mfisyspd0' > whole_disk: 1 > DTL: 236 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 16940350228793267704 > path: '/dev/mfisyspd1' > phys_path: '/dev/mfisyspd1' > whole_disk: 1 > DTL: 235 > create_txg: 4 > children[2]: > type: 'disk' > id: 2 > guid: 9264743178245473794 > path: '/dev/mfisyspd2' > phys_path: '/dev/mfisyspd2' > whole_disk: 1 > DTL: 234 > create_txg: 4 > children[3]: > type: 'disk' > id: 3 > guid: 432716341673487166 > path: '/dev/mfisyspd3' > phys_path: '/dev/mfisyspd3' > whole_disk: 1 > DTL: 233 > create_txg: 4 > children[4]: > type: 'disk' > id: 4 > guid: 18217760646550913544 > path: '/dev/mfisyspd4' > phys_path: '/dev/mfisyspd4' > whole_disk: 1 > DTL: 232 > create_txg: 4 > children[5]: > type: 'disk' > id: 5 > guid: 6964614355298004256 > path: '/dev/mfisyspd5' > phys_path: '/dev/mfisyspd5' > whole_disk: 1 > DTL: 231 > create_txg: 4 > children[6]: > type: 'disk' > id: 6 > guid: 4397961270160308034 > path: '/dev/mfisyspd6' > phys_path: '/dev/mfisyspd6' > whole_disk: 1 > DTL: 230 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 13757670211012452260 > path: '/dev/mfisyspd7p3' > phys_path: '/dev/mfisyspd7p3' > whole_disk: 1 > metaslab_array: 32 > metaslab_shift: 27 > ashift: 9 > asize: 14125891584 > is_log: 1 > DTL: 237 > create_txg: 4 > children[2]: > type: 'disk' > id: 2 > guid: 7315839509249482920 > path: '/dev/mfisyspd8p3' > phys_path: '/dev/mfisyspd8p3' > whole_disk: 1 > metaslab_array: 31 > metaslab_shift: 27 > ashift: 9 > asize: 14125891584 > is_log: 1 > DTL: 229 > create_txg: 4 > > MOS Configuration: > version: 28 > name: 'tank2' > state: 0 > txg: 39502 > pool_guid: 15779146362913479443 > hostid: 1751781486 > vdev_children: 3 > vdev_tree: > type: 'root' > id: 0 > guid: 15779146362913479443 > create_txg: 4 > children[0]: > type: 'raidz' > id: 0 > guid: 8518972900227438019 > nparity: 2 > metaslab_array: 33 > metaslab_shift: 37 > ashift: 9 > asize: 21004116295680 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 15577380450172137060 > path: '/dev/mfisyspd0' > phys_path: '/dev/mfisyspd0' > whole_disk: 1 > DTL: 236 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 16940350228793267704 > path: '/dev/mfisyspd1' > phys_path: '/dev/mfisyspd1' > whole_disk: 1 > DTL: 235 > create_txg: 4 > children[2]: > type: 'disk' > id: 2 > guid: 9264743178245473794 > path: '/dev/mfisyspd2' > phys_path: '/dev/mfisyspd2' > whole_disk: 1 > DTL: 234 > create_txg: 4 > children[3]: > type: 'disk' > id: 3 > guid: 432716341673487166 > path: '/dev/mfisyspd3' > phys_path: '/dev/mfisyspd3' > whole_disk: 1 > DTL: 233 > create_txg: 4 > children[4]: > type: 'disk' > id: 4 > guid: 18217760646550913544 > path: '/dev/mfisyspd4' > phys_path: '/dev/mfisyspd4' > whole_disk: 1 > DTL: 232 > create_txg: 4 > children[5]: > type: 'disk' > id: 5 > guid: 6964614355298004256 > path: '/dev/mfisyspd5' > phys_path: '/dev/mfisyspd5' > whole_disk: 1 > DTL: 231 > create_txg: 4 > children[6]: > type: 'disk' > id: 6 > guid: 4397961270160308034 > path: '/dev/mfisyspd6' > phys_path: '/dev/mfisyspd6' > whole_disk: 1 > DTL: 230 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 13757670211012452260 > path: '/dev/mfisyspd7p3' > phys_path: '/dev/mfisyspd7p3' > whole_disk: 1 > metaslab_array: 32 > metaslab_shift: 27 > ashift: 9 > asize: 14125891584 > is_log: 1 > DTL: 237 > create_txg: 4 > children[2]: > type: 'disk' > id: 2 > guid: 7315839509249482920 > path: '/dev/mfisyspd8p3' > phys_path: '/dev/mfisyspd8p3' > whole_disk: 1 > metaslab_array: 31 > metaslab_shift: 27 > ashift: 9 > asize: 14125891584 > is_log: 1 > DTL: 229 > create_txg: 4 > > Uberblock: > magic = 0000000000bab10c > version = 28 > txg = 39547 > guid_sum = 6486691012039134504 > timestamp = 1351727718 UTC = Wed Oct 31 23:55:18 2012 > > All DDTs are empty > > Metaslabs: > vdev 0 > metaslabs 152 offset spacemap > free --------------- ------------------- --------------- ------------- > metaslab 0 offset 0 spacemap 36 free 1.41G > segments 4170 maxsize 1.38G freepct 1% > metaslab 1 offset 2000000000 spacemap 65 free 1.45G > segments 4508 maxsize 1.40G freepct 1% > metaslab 2 offset 4000000000 spacemap 70 free 1.44G > segments 5723 maxsize 1.39G freepct 1% > metaslab 3 offset 6000000000 spacemap 77 free 1.41G > segments 6635 maxsize 1.35G freepct 1% > metaslab 4 offset 8000000000 spacemap 80 free 1.46G > segments 6408 maxsize 1.40G freepct 1% > metaslab 5 offset a000000000 spacemap 81 free 1.47G > segments 6480 maxsize 1.42G freepct 1% > metaslab 6 offset c000000000 spacemap 82 free 1.48G > segments 6684 maxsize 1.42G freepct 1% > metaslab 7 offset e000000000 spacemap 83 free 1.48G > segments 6873 maxsize 1.42G freepct 1% > metaslab 8 offset 10000000000 spacemap 84 free 1.48G > segments 7298 maxsize 1.42G freepct 1% > metaslab 9 offset 12000000000 spacemap 85 free 1.43G > segments 6699 maxsize 1.37G freepct 1% > metaslab 10 offset 14000000000 spacemap 88 free 1.50G > segments 6781 maxsize 1.44G freepct 1% > metaslab 11 offset 16000000000 spacemap 89 free 1.50G > segments 6434 maxsize 1.44G freepct 1% > metaslab 12 offset 18000000000 spacemap 90 free 1.51G > segments 7188 maxsize 1.44G freepct 1% > metaslab 13 offset 1a000000000 spacemap 91 free 1.49G > segments 6712 maxsize 1.42G freepct 1% > metaslab 14 offset 1c000000000 spacemap 92 free 1.52G > segments 6810 maxsize 1.46G freepct 1% > metaslab 15 offset 1e000000000 spacemap 93 free 1.52G > segments 8306 maxsize 1.41G freepct 1% > metaslab 16 offset 20000000000 spacemap 94 free 1.49G > segments 21881 maxsize 660M freepct 1% > metaslab 17 offset 22000000000 spacemap 97 free 1.50G > segments 9590 maxsize 1.32G freepct 1% > metaslab 18 offset 24000000000 spacemap 98 free 1.53G > segments 6921 maxsize 1.47G freepct 1% > metaslab 19 offset 26000000000 spacemap 99 free 1.53G > segments 7982 maxsize 1.46G freepct 1% > metaslab 20 offset 28000000000 spacemap 100 free 1.55G > segments 7943 maxsize 1.48G freepct 1% > metaslab 21 offset 2a000000000 spacemap 101 free 1.54G > segments 8049 maxsize 1.47G freepct 1% > metaslab 22 offset 2c000000000 spacemap 102 free 1.54G > segments 8205 maxsize 1.46G freepct 1% > metaslab 23 offset 2e000000000 spacemap 103 free 1.53G > segments 11339 maxsize 1.37G freepct 1% > metaslab 24 offset 30000000000 spacemap 104 free 1.55G > segments 11536 maxsize 1.38G freepct 1% > metaslab 25 offset 32000000000 spacemap 105 free 1.58G > segments 7281 maxsize 1.50G freepct 1% > metaslab 26 offset 34000000000 spacemap 108 free 1.57G > segments 7917 maxsize 1.49G freepct 1% > metaslab 27 offset 36000000000 spacemap 109 free 1.59G > segments 8446 maxsize 1.51G freepct 1% > metaslab 28 offset 38000000000 spacemap 110 free 1.59G > segments 8437 maxsize 1.51G freepct 1% > metaslab 29 offset 3a000000000 spacemap 35 free 1.60G > segments 22991 maxsize 1.21G freepct 1% > metaslab 30 offset 3c000000000 spacemap 111 free 1.57G > segments 8358 maxsize 1.49G freepct 1% > metaslab 31 offset 3e000000000 spacemap 112 free 1.62G > segments 7724 maxsize 1.53G freepct 1% > metaslab 32 offset 40000000000 spacemap 113 free 1.62G > segments 8314 maxsize 1.53G freepct 1% > metaslab 33 offset 42000000000 spacemap 114 free 1.61G > segments 8294 maxsize 1.52G freepct 1% > metaslab 34 offset 44000000000 spacemap 115 free 1.63G > segments 8422 maxsize 1.54G freepct 1% > metaslab 35 offset 46000000000 spacemap 116 free 1.60G > segments 8125 maxsize 1.51G freepct 1% > metaslab 36 offset 48000000000 spacemap 117 free 1.62G > segments 8048 maxsize 1.53G freepct 1% > metaslab 37 offset 4a000000000 spacemap 118 free 1.60G > segments 8648 maxsize 1.51G freepct 1% > metaslab 38 offset 4c000000000 spacemap 119 free 1.66G > segments 8316 maxsize 1.57G freepct 1% > metaslab 39 offset 4e000000000 spacemap 87 free 1.62G > segments 27153 maxsize 1.05G freepct 1% > metaslab 40 offset 50000000000 spacemap 121 free 1.66G > segments 9314 maxsize 1.56G freepct 1% > metaslab 41 offset 52000000000 spacemap 122 free 1.64G > segments 9334 maxsize 1.56G freepct 1% > metaslab 42 offset 54000000000 spacemap 123 free 1.67G > segments 10391 maxsize 1.51G freepct 1% > metaslab 43 offset 56000000000 spacemap 126 free 1.65G > segments 12514 maxsize 1.49G freepct 1% > metaslab 44 offset 58000000000 spacemap 127 free 1.67G > segments 13441 maxsize 1.50G freepct 1% > metaslab 45 offset 5a000000000 spacemap 129 free 1.70G > segments 13288 maxsize 1.54G freepct 1% > metaslab 46 offset 5c000000000 spacemap 96 free 1.71G > segments 27184 maxsize 1.07G freepct 1% > metaslab 47 offset 5e000000000 spacemap 130 free 1.69G > segments 10019 maxsize 1.61G freepct 1% > metaslab 48 offset 60000000000 spacemap 133 free 1.69G > segments 13025 maxsize 1.53G freepct 1% > metaslab 49 offset 62000000000 spacemap 135 free 1.71G > segments 10562 maxsize 1.63G freepct 1% > metaslab 50 offset 64000000000 spacemap 136 free 1.74G > segments 9827 maxsize 1.66G freepct 1% > metaslab 51 offset 66000000000 spacemap 137 free 1.73G > segments 10206 maxsize 1.65G freepct 1% > metaslab 52 offset 68000000000 spacemap 138 free 1.75G > segments 9747 maxsize 1.67G freepct 1% > metaslab 53 offset 6a000000000 spacemap 139 free 1.76G > segments 14248 maxsize 1.57G freepct 1% > metaslab 54 offset 6c000000000 spacemap 107 free 1.76G > segments 29803 maxsize 987M freepct 1% > metaslab 55 offset 6e000000000 spacemap 142 free 1.76G > segments 9068 maxsize 1.68G freepct 1% > metaslab 56 offset 70000000000 spacemap 143 free 1.76G > segments 10561 maxsize 1.68G freepct 1% > metaslab 57 offset 72000000000 spacemap 144 free 1.78G > segments 10234 maxsize 1.70G freepct 1% > metaslab 58 offset 74000000000 spacemap 34 free 1.79G > segments 12737 maxsize 1.49G freepct 1% > metaslab 59 offset 76000000000 spacemap 145 free 1.80G > segments 10211 maxsize 1.71G freepct 1% > metaslab 60 offset 78000000000 spacemap 146 free 1.77G > segments 10696 maxsize 1.68G freepct 1% > metaslab 61 offset 7a000000000 spacemap 147 free 1.81G > segments 10934 maxsize 1.71G freepct 1% > metaslab 62 offset 7c000000000 spacemap 148 free 1.81G > segments 8698 maxsize 1.73G freepct 1% > metaslab 63 offset 7e000000000 spacemap 149 free 1.82G > segments 9165 maxsize 1.74G freepct 1% > metaslab 64 offset 80000000000 spacemap 152 free 1.83G > segments 9388 maxsize 1.74G freepct 1% > metaslab 65 offset 82000000000 spacemap 154 free 1.84G > segments 11321 maxsize 1.74G freepct 1% > metaslab 66 offset 84000000000 spacemap 155 free 1.85G > segments 10040 maxsize 1.76G freepct 1% > metaslab 67 offset 86000000000 spacemap 156 free 1.86G > segments 10531 maxsize 1.77G freepct 1% > metaslab 68 offset 88000000000 spacemap 86 free 1.84G > segments 8518 maxsize 1.73G freepct 1% > metaslab 69 offset 8a000000000 spacemap 120 free 1.87G > segments 18100 maxsize 1.51G freepct 1% > metaslab 70 offset 8c000000000 spacemap 157 free 1.88G > segments 12773 maxsize 1.70G freepct 1% > metaslab 71 offset 8e000000000 spacemap 159 free 1.89G > segments 11443 maxsize 1.79G freepct 1% > metaslab 72 offset 90000000000 spacemap 125 free 1.90G > segments 13633 maxsize 1.72G freepct 1% > metaslab 73 offset 92000000000 spacemap 160 free 1.91G > segments 10724 maxsize 1.81G freepct 1% > metaslab 74 offset 94000000000 spacemap 161 free 1.92G > segments 10550 maxsize 1.77G freepct 1% > metaslab 75 offset 96000000000 spacemap 162 free 1.92G > segments 10027 maxsize 1.83G freepct 1% > metaslab 76 offset 98000000000 spacemap 132 free 1.93G > segments 16007 maxsize 1.69G freepct 1% > metaslab 77 offset 9a000000000 spacemap 164 free 1.94G > segments 9721 maxsize 1.84G freepct 1% > metaslab 78 offset 9c000000000 spacemap 134 free 1.95G > segments 26262 maxsize 1.35G freepct 1% > metaslab 79 offset 9e000000000 spacemap 165 free 1.95G > segments 7968 maxsize 1.88G freepct 1% > metaslab 80 offset a0000000000 spacemap 166 free 1.97G > segments 7757 maxsize 1.89G freepct 1% > metaslab 81 offset a2000000000 spacemap 167 free 1.97G > segments 9206 maxsize 1.89G freepct 1% > metaslab 82 offset a4000000000 spacemap 168 free 1.98G > segments 9225 maxsize 1.89G freepct 1% > metaslab 83 offset a6000000000 spacemap 106 free 1.99G > segments 24197 maxsize 1.43G freepct 1% > metaslab 84 offset a8000000000 spacemap 169 free 2.00G > segments 9637 maxsize 1.91G freepct 1% > metaslab 85 offset aa000000000 spacemap 170 free 2.01G > segments 10167 maxsize 1.92G freepct 1% > metaslab 86 offset ac000000000 spacemap 171 free 2.02G > segments 12180 maxsize 1.85G freepct 1% > metaslab 87 offset ae000000000 spacemap 174 free 2.02G > segments 9716 maxsize 1.93G freepct 1% > metaslab 88 offset b0000000000 spacemap 175 free 2.04G > segments 10583 maxsize 1.94G freepct 1% > metaslab 89 offset b2000000000 spacemap 176 free 2.05G > segments 9935 maxsize 1.95G freepct 1% > metaslab 90 offset b4000000000 spacemap 177 free 2.06G > segments 10459 maxsize 1.96G freepct 1% > metaslab 91 offset b6000000000 spacemap 178 free 2.07G > segments 9396 maxsize 1.98G freepct 1% > metaslab 92 offset b8000000000 spacemap 179 free 2.07G > segments 8301 maxsize 1.96G freepct 1% > metaslab 93 offset ba000000000 spacemap 151 free 2.08G > segments 17800 maxsize 1.52G freepct 1% > metaslab 94 offset bc000000000 spacemap 181 free 2.10G > segments 10951 maxsize 2.00G freepct 1% > metaslab 95 offset be000000000 spacemap 182 free 2.11G > segments 11002 maxsize 2.01G freepct 1% > metaslab 96 offset c0000000000 spacemap 183 free 2.12G > segments 10855 maxsize 2.01G freepct 1% > metaslab 97 offset c2000000000 spacemap 95 free 2.13G > segments 13168 maxsize 1.96G freepct 1% > metaslab 98 offset c4000000000 spacemap 184 free 2.13G > segments 9408 maxsize 2.04G freepct 1% > metaslab 99 offset c6000000000 spacemap 185 free 2.15G > segments 10694 maxsize 2.04G freepct 1% > metaslab 100 offset c8000000000 spacemap 186 free 2.16G > segments 10563 maxsize 2.05G freepct 1% > metaslab 101 offset ca000000000 spacemap 187 free 2.17G > segments 11059 maxsize 2.06G freepct 1% > metaslab 102 offset cc000000000 spacemap 188 free 2.18G > segments 11516 maxsize 2.07G freepct 1% > metaslab 103 offset ce000000000 spacemap 189 free 2.19G > segments 10700 maxsize 2.08G freepct 1% > metaslab 104 offset d0000000000 spacemap 163 free 2.20G > segments 7869 maxsize 1.77G freepct 1% > metaslab 105 offset d2000000000 spacemap 131 free 2.22G > segments 11941 maxsize 2.08G freepct 1% > metaslab 106 offset d4000000000 spacemap 190 free 9.24G > segments 11407 maxsize 2.11G freepct 7% > metaslab 107 offset d6000000000 spacemap 141 free 2.24G > segments 13038 maxsize 2.00G freepct 1% > metaslab 108 offset d8000000000 spacemap 192 free 9.7G > segments 10472 maxsize 2.13G freepct 7% > metaslab 109 offset da000000000 spacemap 193 free 8.61G > segments 11389 maxsize 2.14G freepct 6% > metaslab 110 offset dc000000000 spacemap 194 free 6.34G > segments 10513 maxsize 2.16G freepct 4% > metaslab 111 offset de000000000 spacemap 195 free 7.58G > segments 10168 maxsize 2.17G freepct 5% > metaslab 112 offset e0000000000 spacemap 197 free 7.14G > segments 6922 maxsize 2.22G freepct 5% > metaslab 113 offset e2000000000 spacemap 198 free 2.30G > segments 6757 maxsize 2.24G freepct 1% > metaslab 114 offset e4000000000 spacemap 199 free 2.32G > segments 7008 maxsize 2.26G freepct 1% > metaslab 115 offset e6000000000 spacemap 200 free 2.33G > segments 6518 maxsize 2.27G freepct 1% > metaslab 116 offset e8000000000 spacemap 173 free 2.35G > segments 13857 maxsize 1.92G freepct 1% > metaslab 117 offset ea000000000 spacemap 201 free 2.36G > segments 7124 maxsize 2.30G freepct 1% > metaslab 118 offset ec000000000 spacemap 202 free 2.37G > segments 6936 maxsize 2.31G freepct 1% > metaslab 119 offset ee000000000 spacemap 203 free 2.38G > segments 6679 maxsize 2.32G freepct 1% > metaslab 120 offset f0000000000 spacemap 204 free 2.39G > segments 6818 maxsize 2.34G freepct 1% > metaslab 121 offset f2000000000 spacemap 205 free 2.41G > segments 7423 maxsize 2.34G freepct 1% > metaslab 122 offset f4000000000 spacemap 150 free 2.42G > segments 15678 maxsize 2.14G freepct 1% > metaslab 123 offset f6000000000 spacemap 158 free 2.43G > segments 9980 maxsize 2.28G freepct 1% > metaslab 124 offset f8000000000 spacemap 180 free 2.45G > segments 11702 maxsize 1.71G freepct 1% > metaslab 125 offset fa000000000 spacemap 206 free 2.46G > segments 7070 maxsize 2.40G freepct 1% > metaslab 126 offset fc000000000 spacemap 124 free 2.47G > segments 11485 maxsize 2.31G freepct 1% > metaslab 127 offset fe000000000 spacemap 128 free 2.49G > segments 2051 maxsize 2.42G freepct 1% > metaslab 128 offset 100000000000 spacemap 207 free 2.50G > segments 7309 maxsize 2.44G freepct 1% > metaslab 129 offset 102000000000 spacemap 208 free 2.52G > segments 7151 maxsize 2.46G freepct 1% > metaslab 130 offset 104000000000 spacemap 209 free 2.52G > segments 6041 maxsize 2.47G freepct 1% > metaslab 131 offset 106000000000 spacemap 210 free 2.54G > segments 6910 maxsize 2.47G freepct 1% > metaslab 132 offset 108000000000 spacemap 211 free 2.56G > segments 6816 maxsize 2.50G freepct 1% > metaslab 133 offset 10a000000000 spacemap 212 free 2.57G > segments 6182 maxsize 2.51G freepct 2% > metaslab 134 offset 10c000000000 spacemap 213 free 2.59G > segments 7541 maxsize 2.52G freepct 2% > metaslab 135 offset 10e000000000 spacemap 214 free 2.61G > segments 7810 maxsize 2.53G freepct 2% > metaslab 136 offset 110000000000 spacemap 215 free 2.62G > segments 6822 maxsize 2.56G freepct 2% > metaslab 137 offset 112000000000 spacemap 191 free 9.39G > segments 10891 maxsize 2.28G freepct 7% > metaslab 138 offset 114000000000 spacemap 216 free 2.65G > segments 7295 maxsize 2.58G freepct 2% > metaslab 139 offset 116000000000 spacemap 217 free 2.67G > segments 7435 maxsize 2.60G freepct 2% > metaslab 140 offset 118000000000 spacemap 218 free 2.68G > segments 6952 maxsize 2.62G freepct 2% > metaslab 141 offset 11a000000000 spacemap 196 free 2.70G > segments 5975 maxsize 2.37G freepct 2% > metaslab 142 offset 11c000000000 spacemap 219 free 2.72G > segments 7547 maxsize 2.65G freepct 2% > metaslab 143 offset 11e000000000 spacemap 220 free 2.74G > segments 7570 maxsize 2.67G freepct 2% > metaslab 144 offset 120000000000 spacemap 221 free 2.75G > segments 7321 maxsize 2.69G freepct 2% > metaslab 145 offset 122000000000 spacemap 172 free 2.77G > segments 3490 maxsize 2.68G freepct 2% > metaslab 146 offset 124000000000 spacemap 222 free 2.79G > segments 7448 maxsize 2.72G freepct 2% > metaslab 147 offset 126000000000 spacemap 223 free 2.81G > segments 7309 maxsize 2.74G freepct 2% > metaslab 148 offset 128000000000 spacemap 224 free 2.82G > segments 7367 maxsize 2.75G freepct 2% > metaslab 149 offset 12a000000000 spacemap 225 free 2.84G > segments 7249 maxsize 2.77G freepct 2% > metaslab 150 offset 12c000000000 spacemap 226 free 2.86G > segments 8091 maxsize 2.78G freepct 2% > metaslab 151 offset 12e000000000 spacemap 153 free 2.88G > segments 2771 maxsize 2.74G freepct 2% > > vdev 1 > metaslabs 105 offset spacemap > free --------------- ------------------- --------------- ------------- > metaslab 0 offset 0 spacemap 38 free 128M > segments 1 maxsize 128M freepct 99% > metaslab 1 offset 8000000 spacemap 39 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 2 offset 10000000 spacemap 42 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 3 offset 18000000 spacemap 41 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 4 offset 20000000 spacemap 51 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 5 offset 28000000 spacemap 50 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 6 offset 30000000 spacemap 49 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 7 offset 38000000 spacemap 48 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 8 offset 40000000 spacemap 47 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 9 offset 48000000 spacemap 46 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 10 offset 50000000 spacemap 45 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 11 offset 58000000 spacemap 59 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 12 offset 60000000 spacemap 62 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 13 offset 68000000 spacemap 61 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 14 offset 70000000 spacemap 67 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 15 offset 78000000 spacemap 66 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 16 offset 80000000 spacemap 74 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 17 offset 88000000 spacemap 73 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 18 offset 90000000 spacemap 75 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 19 offset 98000000 spacemap 78 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 20 offset a0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 21 offset a8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 22 offset b0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 23 offset b8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 24 offset c0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 25 offset c8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 26 offset d0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 27 offset d8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 28 offset e0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 29 offset e8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 30 offset f0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 31 offset f8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 32 offset 100000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 33 offset 108000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 34 offset 110000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 35 offset 118000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 36 offset 120000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 37 offset 128000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 38 offset 130000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 39 offset 138000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 40 offset 140000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 41 offset 148000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 42 offset 150000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 43 offset 158000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 44 offset 160000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 45 offset 168000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 46 offset 170000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 47 offset 178000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 48 offset 180000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 49 offset 188000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 50 offset 190000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 51 offset 198000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 52 offset 1a0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 53 offset 1a8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 54 offset 1b0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 55 offset 1b8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 56 offset 1c0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 57 offset 1c8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 58 offset 1d0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 59 offset 1d8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 60 offset 1e0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 61 offset 1e8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 62 offset 1f0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 63 offset 1f8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 64 offset 200000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 65 offset 208000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 66 offset 210000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 67 offset 218000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 68 offset 220000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 69 offset 228000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 70 offset 230000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 71 offset 238000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 72 offset 240000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 73 offset 248000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 74 offset 250000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 75 offset 258000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 76 offset 260000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 77 offset 268000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 78 offset 270000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 79 offset 278000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 80 offset 280000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 81 offset 288000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 82 offset 290000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 83 offset 298000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 84 offset 2a0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 85 offset 2a8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 86 offset 2b0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 87 offset 2b8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 88 offset 2c0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 89 offset 2c8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 90 offset 2d0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 91 offset 2d8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 92 offset 2e0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 93 offset 2e8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 94 offset 2f0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 95 offset 2f8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 96 offset 300000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 97 offset 308000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 98 offset 310000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 99 offset 318000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 100 offset 320000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 101 offset 328000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 102 offset 330000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 103 offset 338000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 104 offset 340000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > > vdev 2 > metaslabs 105 offset spacemap > free --------------- ------------------- --------------- ------------- > metaslab 0 offset 0 spacemap 37 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 1 offset 8000000 spacemap 40 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 2 offset 10000000 spacemap 44 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 3 offset 18000000 spacemap 43 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 4 offset 20000000 spacemap 58 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 5 offset 28000000 spacemap 57 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 6 offset 30000000 spacemap 56 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 7 offset 38000000 spacemap 55 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 8 offset 40000000 spacemap 54 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 9 offset 48000000 spacemap 53 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 10 offset 50000000 spacemap 52 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 11 offset 58000000 spacemap 60 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 12 offset 60000000 spacemap 64 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 13 offset 68000000 spacemap 63 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 14 offset 70000000 spacemap 69 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 15 offset 78000000 spacemap 68 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 16 offset 80000000 spacemap 72 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 17 offset 88000000 spacemap 71 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 18 offset 90000000 spacemap 76 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 19 offset 98000000 spacemap 79 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 20 offset a0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 21 offset a8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 22 offset b0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 23 offset b8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 24 offset c0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 25 offset c8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 26 offset d0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 27 offset d8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 28 offset e0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 29 offset e8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 30 offset f0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 31 offset f8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 32 offset 100000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 33 offset 108000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 34 offset 110000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 35 offset 118000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 36 offset 120000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 37 offset 128000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 38 offset 130000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 39 offset 138000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 40 offset 140000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 41 offset 148000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 42 offset 150000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 43 offset 158000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 44 offset 160000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 45 offset 168000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 46 offset 170000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 47 offset 178000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 48 offset 180000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 49 offset 188000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 50 offset 190000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 51 offset 198000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 52 offset 1a0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 53 offset 1a8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 54 offset 1b0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 55 offset 1b8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 56 offset 1c0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 57 offset 1c8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 58 offset 1d0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 59 offset 1d8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 60 offset 1e0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 61 offset 1e8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 62 offset 1f0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 63 offset 1f8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 64 offset 200000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 65 offset 208000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 66 offset 210000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 67 offset 218000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 68 offset 220000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 69 offset 228000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 70 offset 230000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 71 offset 238000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 72 offset 240000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 73 offset 248000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 74 offset 250000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 75 offset 258000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 76 offset 260000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 77 offset 268000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 78 offset 270000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 79 offset 278000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 80 offset 280000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 81 offset 288000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 82 offset 290000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 83 offset 298000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 84 offset 2a0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 85 offset 2a8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 86 offset 2b0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 87 offset 2b8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 88 offset 2c0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 89 offset 2c8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 90 offset 2d0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 91 offset 2d8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 92 offset 2e0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 93 offset 2e8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 94 offset 2f0000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 95 offset 2f8000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 96 offset 300000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 97 offset 308000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 98 offset 310000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 99 offset 318000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 100 offset 320000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 101 offset 328000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 102 offset 330000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 103 offset 338000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > metaslab 104 offset 340000000 spacemap 0 free 128M > segments 1 maxsize 128M freepct 100% > > Dataset mos [META], ID 0, cr_txg 4, 459M, 235 objects > > Object lvl iblk dblk dsize lsize %full type > 0 2 16K 16K 256K 128K 91.80 DMU dnode > 1 1 16K 16K 19.0K 32K 100.00 object directory > 2 1 16K 512 0 512 0.00 DSL directory > 3 1 16K 512 3.00K 512 100.00 DSL props > 4 1 16K 512 3.00K 512 100.00 DSL directory child map > 5 1 16K 512 0 512 0.00 DSL directory > 6 1 16K 512 3.00K 512 100.00 DSL props > 7 1 16K 512 3.00K 512 100.00 DSL directory child map > 8 1 16K 512 0 512 0.00 DSL directory > 9 1 16K 512 3.00K 512 100.00 DSL props > 10 1 16K 512 3.00K 512 100.00 DSL directory child map > 11 1 16K 128K 0 128K 0.00 bpobj > 12 1 16K 512 0 512 0.00 DSL directory > 13 1 16K 512 3.00K 512 100.00 DSL props > 14 1 16K 512 3.00K 512 100.00 DSL directory child map > 15 1 16K 512 0 512 0.00 DSL dataset > 16 1 16K 512 3.00K 512 100.00 DSL dataset snap map > 17 1 16K 512 3.00K 512 100.00 DSL deadlist map > 18 1 16K 512 0 512 0.00 DSL dataset > 19 1 16K 512 3.00K 512 100.00 DSL deadlist map > 20 1 16K 128K 0 128K 0.00 bpobj > 21 1 16K 512 0 512 0.00 DSL dataset > 22 1 16K 512 3.00K 512 100.00 DSL dataset snap map > 23 1 16K 512 3.00K 512 100.00 DSL deadlist map > 24 1 16K 128K 0 128K 0.00 bpobj > 25 1 16K 512 3.00K 512 100.00 DSL dataset next clones > 26 1 16K 512 3.00K 512 100.00 DSL dir clones > 27 1 16K 16K 51.0K 16K 100.00 packed nvlist > 28 1 16K 16K 51.0K 16K 100.00 bpobj (Z=uncompressed) > 29 1 16K 128K 16K 128K 100.00 SPA history > 30 1 16K 16K 6.50K 16K 100.00 packed nvlist > 31 1 16K 512 3.00K 512 100.00 object array > 32 1 16K 512 3.00K 512 100.00 object array > 33 1 16K 512 9.5K 1.50K 100.00 object array > 34 2 16K 4K 467K 176K 100.00 SPA space map > 35 2 16K 4K 851K 296K 100.00 SPA space map > 36 2 16K 4K 275K 88.0K 100.00 SPA space map > 37 1 16K 4K 0 4K 0.00 SPA space map > 38 1 16K 4K 3.00K 4K 100.00 SPA space map > 39 1 16K 4K 0 4K 0.00 SPA space map > 40 1 16K 4K 0 4K 0.00 SPA space map > 41 1 16K 4K 0 4K 0.00 SPA space map > 42 1 16K 4K 0 4K 0.00 SPA space map > 43 1 16K 4K 0 4K 0.00 SPA space map > 44 1 16K 4K 0 4K 0.00 SPA space map > 45 1 16K 4K 0 4K 0.00 SPA space map > 46 1 16K 4K 0 4K 0.00 SPA space map > 47 1 16K 4K 3.00K 4K 100.00 SPA space map > 48 1 16K 4K 0 4K 0.00 SPA space map > 49 1 16K 4K 0 4K 0.00 SPA space map > 50 1 16K 4K 0 4K 0.00 SPA space map > 51 1 16K 4K 0 4K 0.00 SPA space map > 52 1 16K 4K 0 4K 0.00 SPA space map > 53 1 16K 4K 0 4K 0.00 SPA space map > 54 1 16K 4K 3.00K 4K 100.00 SPA space map > 55 1 16K 4K 0 4K 0.00 SPA space map > 56 1 16K 4K 0 4K 0.00 SPA space map > 57 1 16K 4K 0 4K 0.00 SPA space map > 58 1 16K 4K 0 4K 0.00 SPA space map > 59 1 16K 4K 0 4K 0.00 SPA space map > 60 1 16K 4K 0 4K 0.00 SPA space map > 61 1 16K 4K 0 4K 0.00 SPA space map > 62 1 16K 4K 0 4K 0.00 SPA space map > 63 1 16K 4K 0 4K 0.00 SPA space map > 64 1 16K 4K 0 4K 0.00 SPA space map > 65 2 16K 4K 291K 92.0K 100.00 SPA space map > 66 1 16K 4K 0 4K 0.00 SPA space map > 67 1 16K 4K 0 4K 0.00 SPA space map > 68 1 16K 4K 0 4K 0.00 SPA space map > 69 1 16K 4K 0 4K 0.00 SPA space map > 70 2 16K 4K 311K 100K 100.00 SPA space map > 71 1 16K 4K 0 4K 0.00 SPA space map > 72 1 16K 4K 0 4K 0.00 SPA space map > 73 1 16K 4K 0 4K 0.00 SPA space map > 74 1 16K 4K 0 4K 0.00 SPA space map > 75 1 16K 4K 0 4K 0.00 SPA space map > 76 1 16K 4K 0 4K 0.00 SPA space map > 77 2 16K 4K 336K 104K 100.00 SPA space map > 78 1 16K 4K 0 4K 0.00 SPA space map > 79 1 16K 4K 0 4K 0.00 SPA space map > 80 2 16K 4K 330K 104K 100.00 SPA space map > 81 2 16K 4K 333K 104K 100.00 SPA space map > 82 2 16K 4K 339K 108K 100.00 SPA space map > 83 2 16K 4K 343K 108K 100.00 SPA space map > 84 2 16K 4K 368K 116K 100.00 SPA space map > 85 2 16K 4K 339K 108K 100.00 SPA space map > 86 2 16K 4K 384K 120K 100.00 SPA space map > 87 2 16K 4K 1.15M 368K 100.00 SPA space map > 88 2 16K 4K 346K 108K 100.00 SPA space map > 89 2 16K 4K 339K 108K 100.00 SPA space map > 90 2 16K 4K 349K 108K 100.00 SPA space map > 91 2 16K 4K 339K 108K 100.00 SPA space map > 92 2 16K 4K 365K 116K 100.00 SPA space map > 93 2 16K 4K 391K 120K 100.00 SPA space map > 94 2 16K 4K 867K 268K 100.00 SPA space map > 95 2 16K 4K 506K 156K 100.00 SPA space map > 96 2 16K 4K 858K 268K 100.00 SPA space map > 97 2 16K 4K 490K 152K 100.00 SPA space map > 98 2 16K 4K 346K 112K 100.00 SPA space map > 99 2 16K 4K 371K 116K 100.00 SPA space map > 100 2 16K 4K 362K 112K 100.00 SPA space map > 101 2 16K 4K 384K 120K 100.00 SPA space map > 102 2 16K 4K 400K 124K 100.00 SPA space map > 103 2 16K 4K 522K 160K 100.00 SPA space map > 104 2 16K 4K 477K 148K 100.00 SPA space map > 105 2 16K 4K 346K 112K 100.00 SPA space map > 106 2 16K 4K 774K 240K 100.00 SPA space map > 107 2 16K 4K 906K 312K 100.00 SPA space map > 108 2 16K 4K 359K 112K 100.00 SPA space map > 109 2 16K 4K 387K 120K 100.00 SPA space map > 110 2 16K 4K 387K 120K 100.00 SPA space map > 111 2 16K 4K 413K 128K 100.00 SPA space map > 112 2 16K 4K 375K 120K 100.00 SPA space map > 113 2 16K 4K 378K 116K 100.00 SPA space map > 114 2 16K 4K 410K 128K 100.00 SPA space map > 115 2 16K 4K 400K 124K 100.00 SPA space map > 116 2 16K 4K 381K 116K 100.00 SPA space map > 117 2 16K 4K 387K 120K 100.00 SPA space map > 118 2 16K 4K 397K 124K 100.00 SPA space map > 119 2 16K 4K 394K 120K 100.00 SPA space map > 120 2 16K 4K 826K 256K 100.00 SPA space map > 121 2 16K 4K 407K 124K 100.00 SPA space map > 122 2 16K 4K 429K 132K 100.00 SPA space map > 123 2 16K 4K 451K 140K 100.00 SPA space map > 124 2 16K 4K 461K 144K 100.00 SPA space map > 125 2 16K 4K 519K 160K 100.00 SPA space map > 126 2 16K 4K 477K 148K 100.00 SPA space map > 127 2 16K 4K 605K 188K 100.00 SPA space map > 128 2 16K 4K 227K 100K 100.00 SPA space map > 129 2 16K 4K 528K 164K 100.00 SPA space map > 130 2 16K 4K 426K 132K 100.00 SPA space map > 131 2 16K 4K 528K 164K 100.00 SPA space map > 132 2 16K 4K 589K 184K 100.00 SPA space map > 133 2 16K 4K 605K 188K 100.00 SPA space map > 134 2 16K 4K 790K 276K 100.00 SPA space map > 135 2 16K 4K 439K 136K 100.00 SPA space map > 136 2 16K 4K 423K 132K 100.00 SPA space map > 137 2 16K 4K 455K 140K 100.00 SPA space map > 138 2 16K 4K 410K 128K 100.00 SPA space map > 139 2 16K 4K 528K 164K 100.00 SPA space map > 141 2 16K 4K 531K 164K 100.00 SPA space map > 142 2 16K 4K 397K 124K 100.00 SPA space map > 143 2 16K 4K 439K 136K 100.00 SPA space map > 144 2 16K 4K 423K 132K 100.00 SPA space map > 145 2 16K 4K 419K 132K 100.00 SPA space map > 146 2 16K 4K 477K 148K 100.00 SPA space map > 147 2 16K 4K 461K 144K 100.00 SPA space map > 148 2 16K 4K 384K 120K 100.00 SPA space map > 149 2 16K 4K 403K 124K 100.00 SPA space map > 150 2 16K 4K 560K 172K 100.00 SPA space map > 151 2 16K 4K 586K 212K 100.00 SPA space map > 152 2 16K 4K 407K 128K 100.00 SPA space map > 153 2 16K 4K 183K 88.0K 100.00 SPA space map > 154 2 16K 4K 506K 156K 100.00 SPA space map > 155 2 16K 4K 506K 156K 100.00 SPA space map > 156 2 16K 4K 432K 136K 100.00 SPA space map > 157 2 16K 4K 499K 156K 100.00 SPA space map > 158 2 16K 4K 442K 140K 100.00 SPA space map > 159 2 16K 4K 448K 140K 100.00 SPA space map > 160 2 16K 4K 435K 136K 100.00 SPA space map > 161 2 16K 4K 471K 148K 100.00 SPA space map > 162 2 16K 4K 435K 140K 100.00 SPA space map > 163 2 16K 4K 343K 136K 100.00 SPA space map > 164 2 16K 4K 426K 132K 100.00 SPA space map > 165 2 16K 4K 365K 124K 100.00 SPA space map > 166 2 16K 4K 371K 120K 100.00 SPA space map > 167 2 16K 4K 416K 136K 100.00 SPA space map > 168 2 16K 4K 426K 132K 100.00 SPA space map > 169 2 16K 4K 419K 132K 100.00 SPA space map > 170 2 16K 4K 461K 144K 100.00 SPA space map > 171 2 16K 4K 541K 156K 100.00 SPA space map > 172 2 16K 4K 237K 100K 100.00 SPA space map > 173 2 16K 4K 531K 176K 100.00 SPA space map > 174 2 16K 4K 426K 136K 100.00 SPA space map > 175 2 16K 4K 445K 140K 100.00 SPA space map > 176 2 16K 4K 426K 136K 100.00 SPA space map > 177 2 16K 4K 451K 140K 100.00 SPA space map > 178 2 16K 4K 423K 136K 100.00 SPA space map > 179 2 16K 4K 413K 136K 100.00 SPA space map > 180 2 16K 4K 439K 164K 100.00 SPA space map > 181 2 16K 4K 471K 148K 100.00 SPA space map > 182 2 16K 4K 458K 144K 100.00 SPA space map > 183 2 16K 4K 471K 148K 100.00 SPA space map > 184 2 16K 4K 419K 132K 100.00 SPA space map > 185 2 16K 4K 490K 152K 100.00 SPA space map > 186 2 16K 4K 445K 140K 100.00 SPA space map > 187 2 16K 4K 464K 144K 100.00 SPA space map > 188 2 16K 4K 467K 148K 100.00 SPA space map > 189 2 16K 4K 451K 140K 100.00 SPA space map > 190 2 16K 4K 522K 164K 100.00 SPA space map > 191 2 16K 4K 503K 144K 100.00 SPA space map > 192 2 16K 4K 544K 156K 100.00 SPA space map > 193 2 16K 4K 535K 168K 100.00 SPA space map > 194 2 16K 4K 487K 152K 100.00 SPA space map > 195 2 16K 4K 429K 136K 100.00 SPA space map > 196 2 16K 4K 291K 120K 100.00 SPA space map > 197 2 16K 4K 339K 112K 100.00 SPA space map > 198 2 16K 4K 359K 124K 100.00 SPA space map > 199 2 16K 4K 311K 120K 100.00 SPA space map > 200 2 16K 4K 314K 116K 100.00 SPA space map > 201 2 16K 4K 336K 128K 100.00 SPA space map > 202 2 16K 4K 317K 120K 100.00 SPA space map > 203 2 16K 4K 327K 120K 100.00 SPA space map > 204 2 16K 4K 346K 124K 100.00 SPA space map > 205 2 16K 4K 323K 124K 100.00 SPA space map > 206 2 16K 4K 339K 116K 100.00 SPA space map > 207 2 16K 4K 349K 124K 100.00 SPA space map > 208 2 16K 4K 333K 124K 100.00 SPA space map > 209 2 16K 4K 291K 112K 100.00 SPA space map > 210 2 16K 4K 336K 120K 100.00 SPA space map > 211 2 16K 4K 320K 120K 100.00 SPA space map > 212 2 16K 4K 291K 112K 100.00 SPA space map > 213 2 16K 4K 349K 128K 100.00 SPA space map > 214 2 16K 4K 397K 132K 100.00 SPA space map > 215 2 16K 4K 330K 116K 100.00 SPA space map > 216 2 16K 4K 320K 120K 100.00 SPA space map > 217 2 16K 4K 394K 132K 100.00 SPA space map > 218 2 16K 4K 336K 120K 100.00 SPA space map > 219 2 16K 4K 327K 124K 100.00 SPA space map > 220 2 16K 4K 349K 128K 100.00 SPA space map > 221 2 16K 4K 391K 128K 100.00 SPA space map > 222 2 16K 4K 339K 124K 100.00 SPA space map > 223 2 16K 4K 339K 124K 100.00 SPA space map > 224 2 16K 4K 365K 124K 100.00 SPA space map > 225 2 16K 4K 346K 124K 100.00 SPA space map > 226 2 16K 4K 400K 136K 100.00 SPA space map > 228 3 16K 16K 395M 433M 99.95 persistent error log > 229 1 16K 4K 0 4K 0.00 SPA space map > 230 1 16K 4K 0 4K 0.00 SPA space map > 231 1 16K 4K 0 4K 0.00 SPA space map > 232 1 16K 4K 0 4K 0.00 SPA space map > 233 1 16K 4K 0 4K 0.00 SPA space map > 234 1 16K 4K 0 4K 0.00 SPA space map > 235 1 16K 4K 0 4K 0.00 SPA space map > 236 1 16K 4K 0 4K 0.00 SPA space map > 237 1 16K 4K 0 4K 0.00 SPA space map > > Dataset tank2 [ZPL], ID 21, cr_txg 1, 13.3T, 37 objects > > ZIL header: claim_txg 0, claim_blk_seq 0, claim_lr_seq 0 replay_seq 0, flags 0x0 > > > Object lvl iblk dblk dsize lsize %full type > 0 7 16K 16K 40.5K 32K 57.81 DMU dnode > -1 1 16K 512 2K 512 100.00 ZFS user/group used > -2 1 16K 512 2K 512 100.00 ZFS user/group used > 1 1 16K 512 2K 512 100.00 ZFS master node > 2 1 16K 512 2K 512 100.00 SA master node > 3 1 16K 512 2K 512 100.00 ZFS delete queue > 4 1 16K 1.50K 2K 1.50K 100.00 ZFS directory > 5 1 16K 1.50K 2K 1.50K 100.00 SA attr registration > 6 1 16K 16K 10.5K 32K 100.00 SA attr layouts > 7 1 16K 512 2K 512 100.00 ZFS directory > 8 5 16K 128K 510G 510G 100.00 ZFS plain file > 9 5 16K 128K 476G 476G 100.00 ZFS plain file > 10 5 16K 128K 473G 473G 100.00 ZFS plain file > 11 5 16K 128K 467G 467G 100.00 ZFS plain file > 12 5 16K 128K 428G 428G 100.00 ZFS plain file > 13 5 16K 128K 455G 455G 100.00 ZFS plain file > 14 5 16K 128K 478G 478G 100.00 ZFS plain file > 15 5 16K 128K 517G 517G 100.00 ZFS plain file > 16 5 16K 128K 487G 487G 100.00 ZFS plain file > 17 5 16K 128K 513G 513G 100.00 ZFS plain file > 18 5 16K 128K 489G 489G 100.00 ZFS plain file > 19 5 16K 128K 494G 493G 100.00 ZFS plain file > 20 5 16K 128K 492G 492G 100.00 ZFS plain file > 21 5 16K 128K 488G 487G 100.00 ZFS plain file > 22 1 16K 1K 2K 1K 100.00 ZFS directory > 23 4 16K 128K 107G 107G 100.00 ZFS plain file > 24 4 16K 128K 92.4G 92.4G 100.00 ZFS plain file > 25 4 16K 128K 97.2G 97.2G 100.00 ZFS plain file > 26 4 16K 128K 0 128K 0.00 ZFS plain file > 27 4 16K 128K 149G 149G 100.00 ZFS plain file > 28 4 16K 128K 221G 221G 100.00 ZFS plain file > 29 4 16K 128K 93.8G 93.8G 100.00 ZFS plain file > 30 4 16K 128K 66.0G 66.0G 100.00 ZFS plain file > 31 5 16K 128K 5.74T 5.74T 100.00 ZFS plain file > 32 4 16K 128K 48.0G 48.0G 100.00 ZFS plain file > 33 4 16K 128K 12.0G 12.0G 100.00 ZFS plain file > 34 4 16K 128K 11.5G 11.5G 100.00 ZFS plain file > 35 4 16K 128K 11.6G 11.5G 100.00 ZFS plain file > 36 4 16K 128K 29.9G 29.8G 100.00 ZFS plain file > 37 1 16K 512 0 512 0.00 ZFS plain file After a long time waiting zdb started spaffing lots and lots of :- zdb_blkptr_cb: Got error 122 reading <21, 8, 0, ea072> DVA[0]=<0:23c1e196400:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE contiguous unique single size=20000L/20000P birth=4507L/4507P fill=1 cksum=3f98d68a2453:fe4561392aca231:c327b800ff4c8ad5:25a834a4ff84cf0e -- skipping zdb_blkptr_cb: Got error 122 reading <21, 8, 0, ea073> DVA[0]=<0:23c1e169400:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE contiguous unique single size=20000L/20000P birth=4507L/4507P fill=1 cksum=3ff53073c410:ff578ea3d9add37:56c79527f899fddd:c0f9a2751d3d4fe1 -- skipping zdb_blkptr_cb: Got error 122 reading <21, 8, 0, ea074> DVA[0]=<0:23c1e1c3400:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE contiguous unique single size=20000L/20000P birth=4507L/4507P fill=1 cksum=403f20ed2647:100a131a2349650e:76e7f9a70f6d0b24:7329de5d1dfbd68b -- skipping zdb_blkptr_cb: Got error 122 reading <21, 8, 0, ea075> DVA[0]=<0:23c1e1f0400:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE contiguous unique single size=20000L/20000P birth=4507L/4507P fill=1 cksum=3fa72784b6f2:fee8a882bc6849b:e90a52ef28fe1baa:8c84eb7b51c6d0ad -- skipping zdb_blkptr_cb: Got error 122 reading <21, 8, 0, ea076> DVA[0]=<0:23c1e21d400:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE contiguous unique single size=20000L/20000P birth=4507L/4507P fill=1 cksum=4043be27b6cd:101d869585000e3c:52d438d1f3f14883:1f3e84a837d38701 -- skipping zdb_blkptr_cb: Got error 122 reading <21, 8, 0, ea077> DVA[0]=<0:23c1e24a400:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE contiguous unique single size=20000L/20000P birth=4507L/4507P fill=1 cksum=402ba31a743e:10055a4e82d009fc:a6e97a0ebbaf4c80:6e60c0e410cf15e7 -- skipping Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 06:25:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C7F74D0 for ; Thu, 1 Nov 2012 06:25:54 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2178FC0C for ; Thu, 1 Nov 2012 06:25:52 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id qA16PlZT064505; Thu, 1 Nov 2012 13:25:48 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <509215E6.5040306@rdtc.ru> Date: Thu, 01 Nov 2012 13:25:42 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Charles Owens Subject: Re: Panic during kernel boot, igb-init related? (8.3-RELEASE) References: <509158BC.7090901@greatbaysoftware.com> In-Reply-To: <509158BC.7090901@greatbaysoftware.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, Jack Vogel , Steve McCoy , jdc@parodius.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 06:25:54 -0000 31.10.2012 23:58, Charles Owens ÐÉÛÅÔ: > Hello, > > We're seeing boot-time panics in about 4% of cases when upgrading from > FreeBSD 8.1 to 8.3-RELEASE (i386). This problem is subtle enough that > it escaped detection during our regular testing cycle... now with over > 100 systems upgraded we're convinced there's a real issue. Our kernel > config is essentially PAE (ie. static modules ... with a few drivers > added/removed). The hardware is Intel Server System SR1625UR. > > This appears to match a finding discussed in these threads, having to do > with timing of initialization of the igb(4)-based NICs (if I'm > understanding it properly): > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/062596.html > http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062949.html > http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063867.html > http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html > > > These threads include some potential patches and possibility of > commit/MFC... but it isn't clear that there was ever final resolution > (and MFC to 8-stable). I've cc'd a few folks from back then. > > A real challenge here is the frequency of occurrence. As mentioned, it > only hit's a fraction of our systems. When it _does_ hit, the system > may enter a reboot loop for days and then mysteriously break out of > it... and thereafter seem to work fine. > > I'd be very grateful for any help. Some questions: > > * Was there ever a final "blessed" patch? > o if so, will it apply to RELENG_8_3? > * Is there anything that could be said that might help us with > reproducing-the-problem / testing / validating-a-fix? > > > Panic message is -- > > panic: m_getzone: m_getjcl: invalid cluster type > cpuid = 0 > KDB: stack backtrace: > #0 0xc059c717 at kdb_backtrace+0x47 > #1 0xc056caf7 at panic+0x117 > #2 0xc03c979e at igb_refresh_mbufs+0x25e > #3 0xc03c9f98 at igb_rxeof+0x638 > #4 0xc03ca135 at igb_msix_que+0x105 > #5 0xc0541e2b at intr_event_execute_handlers+0x13b > #6 0xc05434eb at ithread_loop+0x6b > #7 0xc053efb7 at fork_exit+0x97 > #8 0xc0806744 at fork_trampoline+0x8 > > Thanks very much, > > Charles Take a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113 that contains simple workaround in followup message not involving any patching, and the fix. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 09:46:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 515C0915; Thu, 1 Nov 2012 09:46:08 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by mx1.freebsd.org (Postfix) with ESMTP id D5B628FC0C; Thu, 1 Nov 2012 09:46:07 +0000 (UTC) Received: from mail85-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 09:46:01 +0000 Received: from mail85-va3 (localhost [127.0.0.1]) by mail85-va3-R.bigfish.com (Postfix) with ESMTP id EF7E03201BB; Thu, 1 Nov 2012 09:46:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:195.159.75.198; KIP:(null); UIP:(null); IPV:NLI; H:nomtaout01.proact.no; RD:nomtaout01.proact.no; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zzbb2dI542M1432Izz1d18h1202h1d1ah1d2ahzz8275dhz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail85-va3 (localhost.localdomain [127.0.0.1]) by mail85-va3 (MessageSwitch) id 1351763158262391_5992; Thu, 1 Nov 2012 09:45:58 +0000 (UTC) Received: from VA3EHSMHS046.bigfish.com (unknown [10.7.14.239]) by mail85-va3.bigfish.com (Postfix) with ESMTP id 3C27D220046; Thu, 1 Nov 2012 09:45:58 +0000 (UTC) Received: from nomtaout01.proact.no (195.159.75.198) by VA3EHSMHS046.bigfish.com (10.7.99.56) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 09:45:58 +0000 Received: from Semail04.proact.local (outside.proact.se [212.214.215.3]) by nomtaout01.proact.no (Postfix) with ESMTP id 855845DD81; Thu, 1 Nov 2012 10:45:57 +0100 (MET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 10:45:56 +0100 From: Tom Lislegaard To: 'Andriy Gapon' Subject: RE: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Topic: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Index: Ac23UHFrRe/nHcv4QJaCSOXSiMVayQAP8Y0AACFOYqA= Date: Thu, 1 Nov 2012 09:45:56 +0000 Message-ID: References: <509172F6.2040400@FreeBSD.org> In-Reply-To: <509172F6.2040400@FreeBSD.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no Cc: "'freebsd-stable@freebsd.org'" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 09:46:08 -0000 > -----Original Message----- > From: Andriy Gapon [mailto:avg@FreeBSD.org] > Sent: 31. oktober 2012 19:51 > To: Tom Lislegaard > Cc: 'freebsd-stable@freebsd.org' > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >=20 > on 31/10/2012 12:14 Tom Lislegaard said the following: > > Hi > > > > I'm running > > FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29 1= 6:11:35 CET 2012 > tl@stingray:/usr/obj/usr/src/sys/stingray amd64 > > on a new Dell laptop and keep getting these panics (typically once or t= wice per day) > > > > (kgdb) set pagination off > > (kgdb) bt > > #0 doadump (textdump=3DVariable "textdump" is not available. > > ) at pcpu.h:229 > > #1 0xffffffff80425e64 in kern_reboot (howto=3D260) at /usr/src/sys/ker= n/kern_shutdown.c:448 > > #2 0xffffffff8042634c in panic (fmt=3D0x1
)= at > /usr/src/sys/kern/kern_shutdown.c:636 > > #3 0xffffffff8045773e in resource_list_unreserve (rl=3DVariable "rl" i= s not available. > > ) at /usr/src/sys/kern/subr_bus.c:3338 > > #4 0xffffffff802c3ee4 in acpi_delete_resource (bus=3D0xfffffe00052c110= 0, child=3D0xfffffe00052c1500, > type=3D4, rid=3D3323) at /usr/src/sys/dev/acpica/acpi.c:1405 > > #5 0xffffffff802c62bc in acpi_bus_alloc_gas (dev=3D0xfffffe00052c1500,= type=3D0xfffffe00052b786c, > rid=3D0xfffffe00052b7978, gas=3DVariable "gas" is not available. > > ) at /usr/src/sys/dev/acpica/acpi.c:1450 > > #6 0xffffffff802d1663 in acpi_PkgGas (dev=3D0xfffffe00052c1500, res=3D= Variable "res" is not available. > > ) at /usr/src/sys/dev/acpica/acpi_package.c:120 > > #7 0xffffffff802cbf6b in acpi_cpu_cx_cst (sc=3D0xfffffe00052b7800) at > /usr/src/sys/dev/acpica/acpi_cpu.c:782 > > #8 0xffffffff802cc3a4 in acpi_cpu_notify (h=3DVariable "h" is not avai= lable. > > ) at /usr/src/sys/dev/acpica/acpi_cpu.c:1050 > > #9 0xffffffff802a3fca in AcpiEvNotifyDispatch (Context=3D0x0) at > /usr/src/sys/contrib/dev/acpica/events/evmisc.c:283 > > #10 0xffffffff802c26c3 in acpi_task_execute (context=3D0xfffffe00051d68= 00, pending=3DVariable "pending" > is not available. > > ) at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:134 > > #11 0xffffffff804683c4 in taskqueue_run_locked (queue=3D0xfffffe00052bc= 100) at > /usr/src/sys/kern/subr_taskqueue.c:308 > > #12 0xffffffff80469366 in taskqueue_thread_loop (arg=3DVariable "arg" i= s not available. > > ) at /usr/src/sys/kern/subr_taskqueue.c:497 > > #13 0xffffffff803f762f in fork_exit (callout=3D0xffffffff80469320 , > arg=3D0xffffffff80a20cc8, frame=3D0xffffff80002cdb00) at /usr/src/sys/ker= n/kern_fork.c:992 > > #14 0xffffffff806be6be in fork_trampoline () at /usr/src/sys/amd64/amd6= 4/exception.S:602 >=20 > Could you please provide *sc from frame 7? >=20 > -- > Andriy Gapon (kgdb) up 7 #7 0xffffffff802cbf6b in acpi_cpu_cx_cst (sc=3D0xfffffe00052b7800) at /usr= /src/sys/dev/acpica/acpi_cpu.c:782 782 acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type, &sc->cpu_rid, (kgdb) print *sc $1 =3D {cpu_dev =3D 0xfffffe00052c1500, cpu_handle =3D 0xfffffe00052e7a80, = cpu_pcpu =3D 0xffffffff80aa6a80, cpu_acpi_id =3D 1, cpu_p_blk =3D 1040, cpu= _p_blk_len =3D 6, cpu_cx_states =3D {{p_lvlx =3D 0xfffffe0196f0e380, type = =3D 1, trans_lat =3D 1, power =3D 1000, res_type =3D 4}, {p_lvlx =3D 0x0, t= ype =3D 3, trans_lat =3D 87, power =3D 200, res_type =3D 4}, {p_lvlx =3D 0x= 0, type =3D 3, trans_lat =3D 87, power =3D 200, res_type =3D 4}, {p_lvlx = =3D 0x0, type =3D 0, trans_lat =3D 0, power =3D 0, res_type =3D 0}, {p_lvlx= =3D 0x0, type =3D 0, trans_lat =3D 0, power =3D 0, res_type =3D 0}, {p_lvl= x =3D 0x0, type =3D 0, trans_lat =3D 0, power =3D 0, res_type =3D 0}, {p_lv= lx =3D 0x0, type =3D 0, trans_lat =3D 0, power =3D 0, res_type =3D 0}, {p_l= vlx =3D 0x0, type =3D 0, trans_lat =3D 0, power =3D 0, res_type =3D 0}}, cp= u_cx_count =3D 2, cpu_prev_sleep =3D 619, cpu_features =3D 31, cpu_non_c3 = =3D 1, cpu_cx_stats =3D {390, 0, 0, 0, 0, 0, 0, 0}, cpu_sysctl_ctx =3D {tqh= _first =3D 0xfffffe00088931a0, tqh_last =3D 0xfffffe0008893228}, cpu_sysctl= _tree =3D 0x0, cpu_cx_lowest =3D 0, cpu_cx_lowest_lim =3D 0, cpu_cx_support= ed =3D "C1/1 C2/59 C3/87", '\0' , cpu_rid =3D 3323} -tom From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 09:48:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9BB3969; Thu, 1 Nov 2012 09:48:39 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 47F598FC0C; Thu, 1 Nov 2012 09:48:38 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so2003096qcs.13 for ; Thu, 01 Nov 2012 02:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qM3AYuIhwu7bNcx1mCAl7IsKkKqomVh+lOxi+vW2Z2w=; b=Vfycn7eaMj1euGBXTbd+OUPMep/trndH1He9OVNaeiZJ6e7/rYIGbeQJL5P52S5lK/ a/kBse4j1xGGegFCu0v3Y8Q/g+Yr389k0tU24csfqkhoO1xVNPRrwbCNGnCAbvixFt2I aEmif7VPwih+jQ8nEw3W16PpHgr5l9dT8uYHc/GI9yYp2HWTKbFFCNTz7G9nPpRfebQ3 jG0q9k4BGwQ1/d24sHvrx0ECIt0k5f8x46n2Q5paLNcnNqQw0ZrZk0x/IUH7F9QSZqOr 8j3Q20EApl7+d0WzgwpQuuajx4oLT4Jv+ciIuSSGiEOx7zxk8nu0KPT6UoYI3lU+kt65 UttA== MIME-Version: 1.0 Received: by 10.224.31.20 with SMTP id w20mr23279565qac.3.1351763312038; Thu, 01 Nov 2012 02:48:32 -0700 (PDT) Received: by 10.229.87.67 with HTTP; Thu, 1 Nov 2012 02:48:31 -0700 (PDT) In-Reply-To: <20121031141209.GB1542@glenbarber.us> References: <20121030170916.GD1371@glenbarber.us> <20121030231412.GE1371@glenbarber.us> <20121031001115.GF1371@glenbarber.us> <20121031030724.GG1371@glenbarber.us> <20121031031912.GH1371@glenbarber.us> <20121031033519.GI1371@glenbarber.us> <20121031141209.GB1542@glenbarber.us> Date: Thu, 1 Nov 2012 10:48:31 +0100 Message-ID: Subject: Re: make release fails on find From: Andreas Nilsson To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 09:48:39 -0000 On Wed, Oct 31, 2012 at 3:12 PM, Glen Barber wrote: > On Wed, Oct 31, 2012 at 08:30:29AM +0100, Andreas Nilsson wrote: > > On a more whislist topic: I'd really appreciate if .zfs dirs would be > > excluded from the tarballs. > > > > Hmm, I didn't realize this was happening. > > So I can verify my change works for all environments, are you using any > local zfs dataset properties, specifically unhiding the snapshot > directory? > > Glen > > Yes, I have the following: tank/cvs/9.1/src snapdir visible inherited from tank/cvs Andreas From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 13:29:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3903E4B9; Thu, 1 Nov 2012 13:29:41 +0000 (UTC) (envelope-from prvs=1652892d21=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 950578FC16; Thu, 1 Nov 2012 13:29:40 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000910332.msg; Thu, 01 Nov 2012 13:29:36 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 01 Nov 2012 13:29:36 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1652892d21=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Steven Hartland" , "Peter Jeremy" References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> <20121031212346.GL3309@server.rulingia.com> <9DB937FEA7634C4BAC49EF5823F93CA3@multiplay.co.uk> Subject: Re: ZFS corruption due to lack of space? Date: Thu, 1 Nov 2012 13:29:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:29:41 -0000 After destroying and re-creating the pool and then writing zeros to the disk in multiple files without filling the fs I've manged to reproduce the corruption again so we can rule out full disk as the cause. I'm now testing different senarios to try and identify the culprit, first test is removing the SSD ZIL and cache disks. Suspects: HW issues (memory, cables, MB, disks), driver issue (not used mfi on tbolt 2208 based cards before). Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 17:37:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B68672D for ; Thu, 1 Nov 2012 17:37:37 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 193438FC08 for ; Thu, 1 Nov 2012 17:37:36 +0000 (UTC) Received: (from brett@localhost) by lariat.net (8.9.3/8.9.3) id LAA24002 for freebsd-stable@freebsd.org; Thu, 1 Nov 2012 11:27:06 -0600 (MDT) Date: Thu, 1 Nov 2012 11:27:06 -0600 (MDT) From: Brett Glass Message-Id: <201211011727.LAA24002@lariat.net> To: freebsd-stable@freebsd.org Subject: 9.1 stability/robustness? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:37:37 -0000 I need to build up a few servers and routers, and am wondering how FreeBSD 9.1 is shaping up. Will it be likely to be more stable and robust than 9.0-RELEASE? Are there issues that will have to wait until 9.2-RELEASE to be fixed? Opinions welcome. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 22:05:13 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 136113BE; Thu, 1 Nov 2012 22:05:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2455F8FC14; Thu, 1 Nov 2012 22:05:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA26667; Fri, 02 Nov 2012 00:05:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TU2sn-000Dku-3s; Fri, 02 Nov 2012 00:05:01 +0200 Message-ID: <5092F209.7090803@FreeBSD.org> Date: Fri, 02 Nov 2012 00:04:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: <509172F6.2040400@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 22:05:13 -0000 on 01/11/2012 11:45 Tom Lislegaard said the following: > > >> -----Original Message----- >> From: Andriy Gapon [mailto:avg@FreeBSD.org] >> Sent: 31. oktober 2012 19:51 >> To: Tom Lislegaard >> Cc: 'freebsd-stable@freebsd.org' >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >> >> on 31/10/2012 12:14 Tom Lislegaard said the following: >>> Hi >>> >>> I'm running >>> FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29 16:11:35 CET 2012 >> tl@stingray:/usr/obj/usr/src/sys/stingray amd64 >>> on a new Dell laptop and keep getting these panics (typically once or twice per day) >>> >>> (kgdb) set pagination off >>> (kgdb) bt >>> #0 doadump (textdump=Variable "textdump" is not available. >>> ) at pcpu.h:229 >>> #1 0xffffffff80425e64 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 >>> #2 0xffffffff8042634c in panic (fmt=0x1
) at >> /usr/src/sys/kern/kern_shutdown.c:636 >>> #3 0xffffffff8045773e in resource_list_unreserve (rl=Variable "rl" is not available. >>> ) at /usr/src/sys/kern/subr_bus.c:3338 >>> #4 0xffffffff802c3ee4 in acpi_delete_resource (bus=0xfffffe00052c1100, child=0xfffffe00052c1500, >> type=4, rid=3323) at /usr/src/sys/dev/acpica/acpi.c:1405 >>> #5 0xffffffff802c62bc in acpi_bus_alloc_gas (dev=0xfffffe00052c1500, type=0xfffffe00052b786c, >> rid=0xfffffe00052b7978, gas=Variable "gas" is not available. >>> ) at /usr/src/sys/dev/acpica/acpi.c:1450 >>> #6 0xffffffff802d1663 in acpi_PkgGas (dev=0xfffffe00052c1500, res=Variable "res" is not available. >>> ) at /usr/src/sys/dev/acpica/acpi_package.c:120 >>> #7 0xffffffff802cbf6b in acpi_cpu_cx_cst (sc=0xfffffe00052b7800) at >> /usr/src/sys/dev/acpica/acpi_cpu.c:782 >>> #8 0xffffffff802cc3a4 in acpi_cpu_notify (h=Variable "h" is not available. >>> ) at /usr/src/sys/dev/acpica/acpi_cpu.c:1050 >>> #9 0xffffffff802a3fca in AcpiEvNotifyDispatch (Context=0x0) at >> /usr/src/sys/contrib/dev/acpica/events/evmisc.c:283 >>> #10 0xffffffff802c26c3 in acpi_task_execute (context=0xfffffe00051d6800, pending=Variable "pending" >> is not available. >>> ) at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:134 >>> #11 0xffffffff804683c4 in taskqueue_run_locked (queue=0xfffffe00052bc100) at >> /usr/src/sys/kern/subr_taskqueue.c:308 >>> #12 0xffffffff80469366 in taskqueue_thread_loop (arg=Variable "arg" is not available. >>> ) at /usr/src/sys/kern/subr_taskqueue.c:497 >>> #13 0xffffffff803f762f in fork_exit (callout=0xffffffff80469320 , >> arg=0xffffffff80a20cc8, frame=0xffffff80002cdb00) at /usr/src/sys/kern/kern_fork.c:992 >>> #14 0xffffffff806be6be in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 >> >> Could you please provide *sc from frame 7? > > (kgdb) up 7 > #7 0xffffffff802cbf6b in acpi_cpu_cx_cst (sc=0xfffffe00052b7800) at /usr/src/sys/dev/acpica/acpi_cpu.c:782 > 782 acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type, &sc->cpu_rid, > (kgdb) print *sc > $1 = {cpu_dev = 0xfffffe00052c1500, cpu_handle = 0xfffffe00052e7a80, cpu_pcpu = 0xffffffff80aa6a80, cpu_acpi_id = 1, cpu_p_blk = 1040, cpu_p_blk_len = 6, cpu_cx_states = {{p_lvlx = 0xfffffe0196f0e380, type = 1, trans_lat = 1, power = 1000, res_type = 4}, {p_lvlx = 0x0, type = 3, trans_lat = 87, power = 200, res_type = 4}, {p_lvlx = 0x0, type = 3, trans_lat = 87, power = 200, res_type = 4}, {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}}, cpu_cx_count = 2, cpu_prev_sleep = 619, cpu_features = 31, cpu_non_c3 = 1, cpu_cx_stats = {390, 0, 0, 0, 0, 0, 0, 0}, cpu_sysctl_ctx = {tqh_first = 0xfffffe00088931a0, tqh_last = 0xfffffe0008893228}, cpu_sysctl_tree = 0x0, cpu_cx_lowest = 0, cpu_cx_lowest_lim = 0, ! cpu_cx_s upported = "C1/1 C2/59 C3/87", '\0' , cpu_rid = 3323} Thank you. Did this crash occur at the time when you plugged or unplugged AC line? Do you plug and unplug the line often? Do you think that the line could have any problems like flaky contacts or some such? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 22:44:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35E398EB; Thu, 1 Nov 2012 22:44:12 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3508FC15; Thu, 1 Nov 2012 22:44:10 +0000 (UTC) Received: from server.rulingia.com (c220-239-241-202.belrs5.nsw.optusnet.com.au [220.239.241.202]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id qA1Mi2lf050486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Nov 2012 09:44:03 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id qA1MhuRW012570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 09:43:56 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id qA1MhtUi012569; Fri, 2 Nov 2012 09:43:55 +1100 (EST) (envelope-from peter) Date: Fri, 2 Nov 2012 09:43:55 +1100 From: Peter Jeremy To: Steven Hartland Subject: Re: ZFS corruption due to lack of space? Message-ID: <20121101224355.GS3309@server.rulingia.com> References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> <20121031212346.GL3309@server.rulingia.com> <9DB937FEA7634C4BAC49EF5823F93CA3@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nO3oAMapP4dBpMZi" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 22:44:12 -0000 --nO3oAMapP4dBpMZi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Nov-01 13:29:34 -0000, Steven Hartland wr= ote: >After destroying and re-creating the pool and then writing >zeros to the disk in multiple files without filling the fs >I've manged to reproduce the corruption again so we can >rule out full disk as the cause. Many years ago, I wrote a simple utility that fills a raw disk with a pseudo-random sequence and then verifies it. This sort of tool can be useful for detecting the presence of silent data corruption (or disk address wraparound). >Suspects: HW issues (memory, cables, MB, disks), driver issue >(not used mfi on tbolt 2208 based cards before). There has been a recent thread about various strange behaviours from LSI controllers and it has been stated that (at least for the 2008) the card firmware _must_ match the FreeBSD driver version. See http://lists.freebsd.org/pipermail/freebsd-stable/2012-August/069205.html --=20 Peter Jeremy --nO3oAMapP4dBpMZi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCS+ysACgkQ/opHv/APuIcMYQCgrirpHq1OO7Sc3kXoK2/MSk1x nWsAoKHR3EhxBVgFcYUBJa6v13sKOok0 =CVoP -----END PGP SIGNATURE----- --nO3oAMapP4dBpMZi-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 1 23:36:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB89318E; Thu, 1 Nov 2012 23:36:13 +0000 (UTC) (envelope-from prvs=1652892d21=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7078FC0A; Thu, 1 Nov 2012 23:36:12 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000920148.msg; Thu, 01 Nov 2012 23:36:11 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 01 Nov 2012 23:36:11 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1652892d21=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <5846347C20554E549FA512C1D59F6427@multiplay.co.uk> From: "Steven Hartland" To: , , "Peter Jeremy" References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> <20121031212346.GL3309@server.rulingia.com> <9DB937FEA7634C4BAC49EF5823F93CA3@multiplay.co.uk> Subject: Re: mfi corrupts JBOD disks >2TB due to LBA overflow (was: ZFS corruption due to lack of space?) Date: Thu, 1 Nov 2012 23:36:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 23:36:14 -0000 Ok after revisiting all the facts and spotting that the corruption only seemed to happen after my zpool was nearly full I came up with a wild idea, could the corruption be being caused by writes after 2TB? A few command lines latter and this was confirmed writes to the 3TB disks under mfi are wrapping at 2TB!!! Steps to prove:- 1. zero out block 1 on the disk dd if=/dev/zero bs=512 count=1 of=/dev/mfisyspd0 1+0 records in 1+0 records out 512 bytes transferred in 0.000728 secs (703171 bytes/sec) 2. confirm the first block is zeros dd if=/dev/mfisyspd0 bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.000250 secs (2047172 bytes/sec) 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 3. write 1 block random after the 2TB boundary dd if=/dev/random bs=512 count=1 of=/dev/mfisyspd0 oseek=4294967296 1+0 records in 1+0 records out 512 bytes transferred in 0.000717 secs (714162 bytes/sec) 4. first block of the disk now contains random data dd if=/dev/mfisyspd0 bs=512 count=8 | hexdump -C 00000000 9c d1 d2 1d 9f 2c fc 30 ab 09 7a f7 64 16 2a 58 |.....,.0..z.d.*X| 00000010 18 27 9d 1f ae 4d 27 53 1a 50 e7 c1 b1 3a 9b e4 |.'...M'S.P...:..| 00000020 c3 7c d0 25 83 e2 bd 85 33 f2 33 8e 71 55 70 7c |.|.%....3.3.qUp|| 00000030 8c 15 af 55 f6 88 8d 6e 40 1c f3 1a 5c e7 80 4b |...U...n@...\..K| ... Looking at the driver code the problem is that IO on syspd disks aka JBOD is always done using 10 byte CDB commands in mfi_build_syspdio. This is clearly a serious problem as it results in total corruption on disks > 2^32 sectors when sectors above 2^32 are accessed. The fix doesn't seem too hard and I think I've already got a basic version working, just needs more testing need. The bug also effects kernel mfi_dump_blocks but thats less likely to trigger due to how its used. Will create PR when I've finished testing and am happy with the patch, but wanted to let others know in the mean time given how serious the bug is. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 02:14:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B905FA4 for ; Fri, 2 Nov 2012 02:14:56 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id E4BF98FC0A for ; Fri, 2 Nov 2012 02:14:55 +0000 (UTC) Received: (from brett@localhost) by lariat.net (8.9.3/8.9.3) id UAA29489 for stable@freebsd.org; Thu, 1 Nov 2012 20:14:51 -0600 (MDT) Date: Thu, 1 Nov 2012 20:14:51 -0600 (MDT) From: Brett Glass Message-Id: <201211020214.UAA29489@lariat.net> To: stable@freebsd.org Subject: FreeBSD 9.1 stability/robustness? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 02:14:56 -0000 I need to build up a few servers and routers, and am wondering how FreeBSD 9.1 is shaping up. Will it be likely to be more stable and robust than 9.0-RELEASE? Are there issues that will have to wait until 9.2-RELEASE to be fixed? Opinions welcome. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 05:57:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7416F387 for ; Fri, 2 Nov 2012 05:57:06 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id 4397C8FC0A for ; Fri, 2 Nov 2012 05:57:05 +0000 (UTC) Received: from [192.168.1.3] ([108.211.168.178]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id qA25RfEH057445; Thu, 1 Nov 2012 22:27:41 -0700 (PDT) (envelope-from bc979@lafn.org) Subject: Re: FreeBSD 9.1 stability/robustness? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Doug Hardie In-Reply-To: <201211020214.UAA29489@lariat.net> Date: Thu, 1 Nov 2012 22:27:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <040B042A-EDD1-4639-BD21-CCB97A410C21@lafn.org> References: <201211020214.UAA29489@lariat.net> To: Brett Glass X-Mailer: Apple Mail (2.1283) X-Virus-Scanned: clamav-milter 0.97 at zoom.lafn.org X-Virus-Status: Clean Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 05:57:06 -0000 On 1 November 2012, at 19:14, Brett Glass wrote: > I need to build up a few servers and routers, and am wondering how > FreeBSD 9.1 is shaping up. Will it be likely to be more stable and > robust than 9.0-RELEASE? It appears to be for me. I had problems with 9.0 not reading CDs and = rebooting with no error messages frequently. I have upgraded to 9.1-RC2 = and it now reads CDs just fine, and has not rebooted. However, the = uptimes with 9.0 ranged from about 2 hours to 30 days. I have only had = 9.1-RC2 running for a couple weeks so have not declared victory yet. I = has been running for more than most of the uptimes already. > Are there issues that will have to wait > until 9.2-RELEASE to be fixed? Opinions welcome. I have no information on this. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 08:10:33 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10A05A72 for ; Fri, 2 Nov 2012 08:10:33 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 475518FC0C for ; Fri, 2 Nov 2012 08:10:30 +0000 (UTC) Received: (qmail 72684 invoked by uid 89); 2 Nov 2012 08:10:22 -0000 Received: by simscan 1.4.0 ppid: 72679, pid: 72681, t: 0.1350s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15530 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 2 Nov 2012 08:10:22 -0000 Date: Fri, 2 Nov 2012 09:10:21 +0100 From: Rainer Duffner To: Brett Glass Subject: Re: FreeBSD 9.1 stability/robustness? Message-ID: <20121102091021.23cf9af0@suse3> In-Reply-To: <201211020214.UAA29489@lariat.net> References: <201211020214.UAA29489@lariat.net> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:10:33 -0000 Am Thu, 1 Nov 2012 20:14:51 -0600 (MDT) schrieb Brett Glass : > I need to build up a few servers and routers, and am wondering how > FreeBSD 9.1 is shaping up. Will it be likely to be more stable and > robust than 9.0-RELEASE? Are there issues that will have to wait > until 9.2-RELEASE to be fixed? Opinions welcome. If I'm not mistaken, the bge-stuff that makes the default NICs ins HP G8 servers (360+380) actually run will not make it back into 9.1. Intel cards work much better anyway... From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 09:30:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D2F7DF4; Fri, 2 Nov 2012 09:30:07 +0000 (UTC) (envelope-from prvs=1653c05a59=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id B92F98FC08; Fri, 2 Nov 2012 09:30:06 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000924482.msg; Fri, 02 Nov 2012 09:30:03 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 02 Nov 2012 09:30:03 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1653c05a59=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Peter Jeremy" References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> <20121031212346.GL3309@server.rulingia.com> <9DB937FEA7634C4BAC49EF5823F93CA3@multiplay.co.uk> <20121101224355.GS3309@server.rulingia.com> Subject: Re: ZFS corruption due to lack of space? Date: Fri, 2 Nov 2012 09:30:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 09:30:07 -0000 ----- Original Message ----- From: "Peter Jeremy" On 2012-Nov-01 13:29:34 -0000, Steven Hartland wrote: >After destroying and re-creating the pool and then writing >zeros to the disk in multiple files without filling the fs >I've manged to reproduce the corruption again so we can >rule out full disk as the cause. > Many years ago, I wrote a simple utility that fills a raw disk with > a pseudo-random sequence and then verifies it. This sort of tool > can be useful for detecting the presence of silent data corruption > (or disk address wraparound). Sounds useful, got a link? >Suspects: HW issues (memory, cables, MB, disks), driver issue >(not used mfi on tbolt 2208 based cards before). > There has been a recent thread about various strange behaviours from > LSI controllers and it has been stated that (at least for the 2008) > the card firmware _must_ match the FreeBSD driver version. See > http://lists.freebsd.org/pipermail/freebsd-stable/2012-August/069205.html Yer thats for mps, not aware of a corrilation for mfi unfortunately :( Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 09:43:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9531D1BB for ; Fri, 2 Nov 2012 09:43:04 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp.insight.synacor.com [208.47.185.22]) by mx1.freebsd.org (Postfix) with ESMTP id 54EB18FC0A for ; Fri, 2 Nov 2012 09:43:03 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=ZYCfx7pA c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=IRk-SjDkvbIA:10 a=jLN7EqiLvroA:10 a=9YQ-1ebCAAAA:8 a=VimVDTNTFdYA:10 a=6-qdQMbhQodBWdZmb_kA:9 a=Dm9TOXL4taQ+Gy1KovpL+A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Authentication-Results: smtp02.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Received-SPF: softfail (smtp02.insight.synacor.com: transitional domain insightbb.com does not designate 74.130.198.7 as permitted sender) Received: from [74.130.198.7] ([74.130.198.7:43059] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 9E/C6-23131-1A593905; Fri, 02 Nov 2012 05:42:57 -0400 Date: Fri, 02 Nov 2012 05:42:57 -0400 Message-ID: <9E.C6.23131.1A593905@smtp02.insight.synacor.com> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1 stability/robustness? Cc: Brett Glass X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 09:43:04 -0000 On 1 November 2012, at 19:14, Brett Glass wrote: > I need to build up a few servers and routers, and am wondering how > FreeBSD 9.1 is shaping up. Will it be likely to be more stable and > robust than 9.0-RELEASE? Doug Hardie responded: > It appears to be for me. I had problems with 9.0 not reading CDs and rebooting with no error messages frequently. I have upgraded to 9.1-RC2 and it now > reads CDs just fine, and has not rebooted. However, the uptimes with 9.0 ranged from about 2 hours to 30 days. I have only had 9.1-RC2 running for a > couple weeks so have not declared victory yet. I has been running for more than most of the uptimes already. I too had problems with 9.0 spontaneously rebooting after a day or two uptime. One was a freeze after a cvs update of NetBSD pkgsrc. The second time was a spontaneous reboot during a time of idleness; I was in the same room and heard the computer sounds. No more such problem after I updated, building from source, to RELENG_9 (STABLE). I haven't updated yet to 9.1 prerelease, bogged down with ports-upgrading snags and cross-compiling NetBSD. Tom From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 09:56:29 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1788D4A0; Fri, 2 Nov 2012 09:56:29 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by mx1.freebsd.org (Postfix) with ESMTP id C49238FC14; Fri, 2 Nov 2012 09:56:28 +0000 (UTC) Received: from mail100-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 09:56:21 +0000 Received: from mail100-co1 (localhost [127.0.0.1]) by mail100-co1-R.bigfish.com (Postfix) with ESMTP id C52355401C5; Fri, 2 Nov 2012 09:56:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:212.214.215.133; KIP:(null); UIP:(null); IPV:NLI; H:semtaout01.proact.se; RD:semtaout01.proact.se; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zzbb2dI542M1432Izz1de0h1d18h1202h1d1ah1d2ahzz8275dhz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail100-co1 (localhost.localdomain [127.0.0.1]) by mail100-co1 (MessageSwitch) id 1351850178833372_24694; Fri, 2 Nov 2012 09:56:18 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.244]) by mail100-co1.bigfish.com (Postfix) with ESMTP id C711A1C006B; Fri, 2 Nov 2012 09:56:18 +0000 (UTC) Received: from semtaout01.proact.se (212.214.215.133) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 09:56:17 +0000 Received: from Semail04.proact.local (unknown [10.7.1.58]) by semtaout01.proact.se (Postfix) with ESMTP id 82AFD5727C; Fri, 2 Nov 2012 10:56:16 +0100 (CET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 10:56:16 +0100 From: Tom Lislegaard To: 'Andriy Gapon' Subject: RE: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Topic: 9-Stable panic: resource_list_unreserve: can't find resource Thread-Index: Ac23UHFrRe/nHcv4QJaCSOXSiMVayQAP8Y0AACFOYqAAF8a9gAAYYgXw Date: Fri, 2 Nov 2012 09:56:15 +0000 Message-ID: References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> In-Reply-To: <5092F209.7090803@FreeBSD.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no Cc: "freebsd-acpi@FreeBSD.org" , "freebsd-stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 09:56:29 -0000 > -----Original Message----- > From: Andriy Gapon [mailto:avg@FreeBSD.org] > Sent: 1. november 2012 23:05 > To: Tom Lislegaard > Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >=20 > on 01/11/2012 11:45 Tom Lislegaard said the following: > > > > > >> -----Original Message----- > >> From: Andriy Gapon [mailto:avg@FreeBSD.org] > >> Sent: 31. oktober 2012 19:51 > >> To: Tom Lislegaard > >> Cc: 'freebsd-stable@freebsd.org' > >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resou= rce > >> > >> on 31/10/2012 12:14 Tom Lislegaard said the following: > >>> Hi > >>> > >>> I'm running > >>> FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29= 16:11:35 CET 2012 > >> tl@stingray:/usr/obj/usr/src/sys/stingray amd64 > >>> on a new Dell laptop and keep getting these panics (typically once or= twice per day) > >>> > >>> (kgdb) set pagination off > >>> (kgdb) bt > >>> #0 doadump (textdump=3DVariable "textdump" is not available. > >>> ) at pcpu.h:229 > >>> #1 0xffffffff80425e64 in kern_reboot (howto=3D260) at /usr/src/sys/k= ern/kern_shutdown.c:448 > >>> #2 0xffffffff8042634c in panic (fmt=3D0x1
) at > >> /usr/src/sys/kern/kern_shutdown.c:636 > >>> #3 0xffffffff8045773e in resource_list_unreserve (rl=3DVariable "rl"= is not available. > >>> ) at /usr/src/sys/kern/subr_bus.c:3338 > >>> #4 0xffffffff802c3ee4 in acpi_delete_resource (bus=3D0xfffffe00052c1= 100, child=3D0xfffffe00052c1500, > >> type=3D4, rid=3D3323) at /usr/src/sys/dev/acpica/acpi.c:1405 > >>> #5 0xffffffff802c62bc in acpi_bus_alloc_gas (dev=3D0xfffffe00052c150= 0, type=3D0xfffffe00052b786c, > >> rid=3D0xfffffe00052b7978, gas=3DVariable "gas" is not available. > >>> ) at /usr/src/sys/dev/acpica/acpi.c:1450 > >>> #6 0xffffffff802d1663 in acpi_PkgGas (dev=3D0xfffffe00052c1500, res= =3DVariable "res" is not > available. > >>> ) at /usr/src/sys/dev/acpica/acpi_package.c:120 > >>> #7 0xffffffff802cbf6b in acpi_cpu_cx_cst (sc=3D0xfffffe00052b7800) a= t > >> /usr/src/sys/dev/acpica/acpi_cpu.c:782 > >>> #8 0xffffffff802cc3a4 in acpi_cpu_notify (h=3DVariable "h" is not av= ailable. > >>> ) at /usr/src/sys/dev/acpica/acpi_cpu.c:1050 > >>> #9 0xffffffff802a3fca in AcpiEvNotifyDispatch (Context=3D0x0) at > >> /usr/src/sys/contrib/dev/acpica/events/evmisc.c:283 > >>> #10 0xffffffff802c26c3 in acpi_task_execute (context=3D0xfffffe00051d= 6800, pending=3DVariable > "pending" > >> is not available. > >>> ) at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:134 > >>> #11 0xffffffff804683c4 in taskqueue_run_locked (queue=3D0xfffffe00052= bc100) at > >> /usr/src/sys/kern/subr_taskqueue.c:308 > >>> #12 0xffffffff80469366 in taskqueue_thread_loop (arg=3DVariable "arg"= is not available. > >>> ) at /usr/src/sys/kern/subr_taskqueue.c:497 > >>> #13 0xffffffff803f762f in fork_exit (callout=3D0xffffffff80469320 , > >> arg=3D0xffffffff80a20cc8, frame=3D0xffffff80002cdb00) at /usr/src/sys/= kern/kern_fork.c:992 > >>> #14 0xffffffff806be6be in fork_trampoline () at /usr/src/sys/amd64/am= d64/exception.S:602 > >> > >> Could you please provide *sc from frame 7? > > > > (kgdb) up 7 > > #7 0xffffffff802cbf6b in acpi_cpu_cx_cst (sc=3D0xfffffe00052b7800) at > /usr/src/sys/dev/acpica/acpi_cpu.c:782 > > 782 acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type, &sc->cpu_rid, > > (kgdb) print *sc > > $1 =3D {cpu_dev =3D 0xfffffe00052c1500, cpu_handle =3D 0xfffffe00052e7a= 80, cpu_pcpu =3D 0xffffffff80aa6a80, > cpu_acpi_id =3D 1, cpu_p_blk =3D 1040, cpu_p_blk_len =3D 6, cpu_cx_states= =3D {{p_lvlx =3D 0xfffffe0196f0e380, > type =3D 1, trans_lat =3D 1, power =3D 1000, res_type =3D 4}, {p_lvlx =3D= 0x0, type =3D 3, trans_lat =3D 87, power =3D > 200, res_type =3D 4}, {p_lvlx =3D 0x0, type =3D 3, trans_lat =3D 87, powe= r =3D 200, res_type =3D 4}, {p_lvlx =3D > 0x0, type =3D 0, trans_lat =3D 0, power =3D 0, res_type =3D 0}, {p_lvlx = =3D 0x0, type =3D 0, trans_lat =3D 0, power > =3D 0, res_type =3D 0}, {p_lvlx =3D 0x0, type =3D 0, trans_lat =3D 0, pow= er =3D 0, res_type =3D 0}, {p_lvlx =3D 0x0, > type =3D 0, trans_lat =3D 0, power =3D 0, res_type =3D 0}, {p_lvlx =3D 0x= 0, type =3D 0, trans_lat =3D 0, power =3D 0, > res_type =3D 0}}, cpu_cx_count =3D 2, cpu_prev_sleep =3D 619, cpu_feature= s =3D 31, cpu_non_c3 =3D 1, > cpu_cx_stats =3D {390, 0, 0, 0, 0, 0, 0, 0}, cpu_sysctl_ctx =3D {tqh_firs= t =3D 0xfffffe00088931a0, tqh_last > =3D 0xfffffe0008893228}, cpu_sysctl_tree =3D 0x0, cpu_cx_lowest =3D 0, cp= u_cx_lowest_lim =3D 0, > ! > cpu_cx_s > upported =3D "C1/1 C2/59 C3/87", '\0' , cpu_rid =3D 332= 3} >=20 > Thank you. > Did this crash occur at the time when you plugged or unplugged AC line? > Do you plug and unplug the line often? > Do you think that the line could have any problems like flaky contacts or= some such? >=20 >=20 > -- > Andriy Gapon The machine is usually connected to a docking station and I believe the pow= er is very stable. I sometimes take it home and connect it to a different p= owersupply and sees the same behavior with panics there. Panics can occur w= hile I'm at the machine working, or if I leave the machine idle for some ti= me I find it has paniced/rebooted when I come back. The time of panic seems totally random and I can't correlate this to any pa= rticular activity like cronjobs, etc. -tom From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 10:33:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E79DE9F; Fri, 2 Nov 2012 10:33:00 +0000 (UTC) (envelope-from prvs=1653c05a59=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id AA8118FC0C; Fri, 2 Nov 2012 10:32:59 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000924892.msg; Fri, 02 Nov 2012 10:32:56 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 02 Nov 2012 10:32:56 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1653c05a59=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <1A4A7E2C4EDD4BAC8F21275BA647782A@multiplay.co.uk> From: "Steven Hartland" To: , , References: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk> <20121031212346.GL3309@server.rulingia.com> <9DB937FEA7634C4BAC49EF5823F93CA3@multiplay.co.uk> <5846347C20554E549FA512C1D59F6427@multiplay.co.uk> Subject: Re: mfi corrupts JBOD disks >2TB due to LBA overflow (was: ZFS corruption due to lack of space?) Date: Fri, 2 Nov 2012 10:32:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 10:33:00 -0000 Copying in freebsd-scsi@ for visability. ----- Original Message ----- From: "Steven Hartland" > Ok after revisiting all the facts and spotting that > the corruption only seemed to happen after my zpool > was nearly full I came up with a wild idea, could > the corruption be being caused by writes after 2TB? > > A few command lines latter and this was confirmed > writes to the 3TB disks under mfi are wrapping at > 2TB!!! > > Steps to prove:- > 1. zero out block 1 on the disk > dd if=/dev/zero bs=512 count=1 of=/dev/mfisyspd0 > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.000728 secs (703171 bytes/sec) > > 2. confirm the first block is zeros > dd if=/dev/mfisyspd0 bs=512 count=1 | hexdump -C > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.000250 secs (2047172 bytes/sec) > 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > * > 00000200 > > 3. write 1 block random after the 2TB boundary > dd if=/dev/random bs=512 count=1 of=/dev/mfisyspd0 oseek=4294967296 > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.000717 secs (714162 bytes/sec) > > 4. first block of the disk now contains random data > dd if=/dev/mfisyspd0 bs=512 count=8 | hexdump -C > 00000000 9c d1 d2 1d 9f 2c fc 30 ab 09 7a f7 64 16 2a 58 |.....,.0..z.d.*X| > 00000010 18 27 9d 1f ae 4d 27 53 1a 50 e7 c1 b1 3a 9b e4 |.'...M'S.P...:..| > 00000020 c3 7c d0 25 83 e2 bd 85 33 f2 33 8e 71 55 70 7c |.|.%....3.3.qUp|| > 00000030 8c 15 af 55 f6 88 8d 6e 40 1c f3 1a 5c e7 80 4b |...U...n@...\..K| > ... > > Looking at the driver code the problem is that IO on syspd > disks aka JBOD is always done using 10 byte CDB commands > in mfi_build_syspdio. This is clearly a serious problem as > it results in total corruption on disks > 2^32 sectors > when sectors above 2^32 are accessed. > > The fix doesn't seem too hard and I think I've already > got a basic version working, just needs more testing need. > > The bug also effects kernel mfi_dump_blocks but thats > less likely to trigger due to how its used. > > Will create PR when I've finished testing and am happy > with the patch, but wanted to let others know in the > mean time given how serious the bug is. PR which includes a patch which fixes this issue is:- http://www.freebsd.org/cgi/query-pr.cgi?pr=173291 Given its critical nature I would strongly advise this gets MFC'ed to all branches ASAP. While someone is looking at this would be good to get the following mfi related PR's I've submitted could also be committed as well ;-) Add deviceid to mfi disk startup output http://www.freebsd.org/cgi/query-pr.cgi?pr=173290 Improvements to mfi support including foreign disks / configs in mfiutil http://www.freebsd.org/cgi/query-pr.cgi?pr=172091 Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 11:04:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A85E840 for ; Fri, 2 Nov 2012 11:04:01 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 127688FC0A for ; Fri, 2 Nov 2012 11:04:00 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qA2B3sbj053111 for ; Fri, 2 Nov 2012 07:03:59 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5093A89A.6040005@m5p.com> Date: Fri, 02 Nov 2012 07:03:54 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120923 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1 stability/robustness? References: <201211020214.UAA29489@lariat.net> In-Reply-To: <201211020214.UAA29489@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Fri, 02 Nov 2012 07:04:00 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 11:04:01 -0000 On 11/01/12 22:14, Brett Glass wrote: > I need to build up a few servers and routers, and am wondering how > FreeBSD 9.1 is shaping up. Will it be likely to be more stable and > robust than 9.0-RELEASE? Are there issues that will have to wait > until 9.2-RELEASE to be fixed? Opinions welcome. > > --Brett Glass > _______________________________________________ > 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" > Personally I don't have a warm, fuzzy feeling about 9.x yet. I'm sticking with 8.3 with 4BSD scheduler for now. -- George Mitchell From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 12:38:43 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C0B3694; Fri, 2 Nov 2012 12:38:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 26EE18FC17; Fri, 2 Nov 2012 12:38:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA02684; Fri, 02 Nov 2012 14:38:36 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5093BECC.1030709@FreeBSD.org> Date: Fri, 02 Nov 2012 14:38:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:38:43 -0000 on 02/11/2012 11:56 Tom Lislegaard said the following: > The machine is usually connected to a docking station and I believe the power is very stable. I sometimes take it home and connect it to a different powersupply and sees the same behavior with panics there. Panics can occur while I'm at the machine working, or if I leave the machine idle for some time I find it has paniced/rebooted when I come back. > The time of panic seems totally random and I can't correlate this to any particular activity like cronjobs, etc. I see. Could you please try setting debug.acpi.max_threads=1 in /boot/loader.conf, reboot and see if that makes any difference? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 14:21:19 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0C8E329; Fri, 2 Nov 2012 14:21:19 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 31AB88FC12; Fri, 2 Nov 2012 14:21:18 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so3363390lbd.13 for ; Fri, 02 Nov 2012 07:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2Akeu1u5HuYUbGfSqwbhL60RXjlEMrRX92hT1xyoK78=; b=mlc5Hb7kSuDcvGoqrR/M+a5XePSlRSkZUXgBjdnJIBvVeAaEYXef/5ff6qln/uSYpl ilW8h2686kgzDGuWXz6cARJz69UIAn0uBMOrLL5DeV2+9Tbf0bjPWjChUo8ZPhmZm2Jp d7ki+ZGVvIbytcf+J934MWCMteRDZMabwA7iB0gstQAcqxsTKS31yH2Kexk+gT2fUrmf 2fzkpjb6BRxmAXoSjGPTIDDjFfyCsugHuGsEiU9DbSefHwX8+53T/NWytCWRTmfNASoX FJ9nnv0B8eYxD5JX+AnUTJLsYy9FmBphzPK0rnpde1O0B1v55p8DFcoGZYRyAZdR5OOT iVUw== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr1828414lab.15.1351866078077; Fri, 02 Nov 2012 07:21:18 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Fri, 2 Nov 2012 07:21:18 -0700 (PDT) In-Reply-To: <50910751.9030303@omnilan.de> References: <5022840B.3060708@omnilan.de> <5048C6D1.8020007@omnilan.de> <508EDB2F.3010608@omnilan.de> <50910751.9030303@omnilan.de> Date: Fri, 2 Nov 2012 14:21:18 +0000 X-Google-Sender-Auth: HhNSXDZsjHAOX5F6VQTvwyjVl58 Message-ID: Subject: Re: lock violation in unionfs (9.0-STABLE r230270) From: Attilio Rao To: Harald Schmalzbauer Content-Type: text/plain; charset=UTF-8 Cc: stable@freebsd.org, daichi@freebsd.org, Pavel Polyakov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:21:20 -0000 On Wed, Oct 31, 2012 at 11:11 AM, Harald Schmalzbauer wrote: > schrieb Attilio Rao am 29.10.2012 23:02 (localtime): >> On Mon, Oct 29, 2012 at 7:37 PM, Harald Schmalzbauer >> wrote: >>> schrieb Attilio Rao am 27.10.2012 23:07 (localtime): >>>> On Sat, Oct 27, 2012 at 9:46 PM, Attilio Rao wrote: >>>>> On Sat, Sep 8, 2012 at 12:48 AM, Attilio Rao wrote: >>>>>> On Thu, Sep 6, 2012 at 4:52 PM, Harald Schmalzbauer >>>>>> wrote: >>>>>>> schrieb Attilio Rao am 09.08.2012 20:26 (localtime): >>>>>>>> On 8/8/12, Harald Schmalzbauer wrote: >>>>>>>>> schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime): >>>>>>>>>>>> mount -t unionfs -o noatime /usr /mnt >>>>>>>>>>>> >>>>>>>>>>>> insmntque: mp-safe fs and non-locked vp: 0xfffffe01d96704f0 is not >>>>>>>>>>>> exclusive locked but should be >>>>>>>>>>>> KDB: enter: lock violation >>>>>>>>>>> Pavel, >>>>>>>>>>> can you give a spin to this patch?: >>>>>>>>>>> http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch >>>>>>>>>>> >>>>>>>>>>> I think that the unlocking is due at that point as the vnode lock can >>>>>>>>>>> be switch later on. >>>>>>>>>>> >>>>>>>>>>> Let me know what you think about it and what the test does. >>>>>>>>>> Thanks! >>>>>>>>>> This patch fixes the problem with lock violation. Sorry I've tested it so >>>>>>>>>> late. >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> this patch still applies cleanly to RELENG_9_1. Was there another fix >>>>>>>>> for the issue or has it just not been PR-sent and thus forgotten? >>>>>>>> Can you and Pavel try the attached patch? Unfortunately I had no time >>>>>>>> to test it, I just made in 5 free mins from a non-FreeBSD workstation, >>>>>>> Sorry, couldn't test earlier, but now I did: >>>>>>> With this patch applied the machine hangs without debug kernel and the >>>>>>> latter gives the following panic: >>>>>>> System call nmount returning with the following locks held: >>>>>>> exclusive lockmgr ufs (ufs) r = 0 (0xc5438278) locked @ >>>>>>> src/sys/fs/unionfs/union_vnops.c:1938 >>>>>>> panic: witness_warn >>>>>>> cpuid = 0 >>>>>>> KDB: stack backtrace: >>>>>>> db_trace_self_wrapper(c0a04f7f,c0c112c4,d1de3bb4,c097aa8c,fc,...) at >>>>>>> db_trace_self_wrapper+0x26 >>>>>>> kdb_backtrace(c0a4965f,0,c09c2ede3c1c,0,...) at kdb_backtrace+0x2a >>>>>>> witness_warn(2,0,c0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >>>>>>> syscall(d1de3d08) ar syscall+0x415 >>>>>>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>>>>>> --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280b883f,esp = >>>>>>> 0xbfbfe46c, ebp = 0xbfbfede8 --- >>>>>>> KDB: enter: panic >>>>>>> [ thread pid 86 tid 100054 ] >>>>>>> Stopped ad kdb_enter+0x3a: movl $0,kdb_why >>>>>>> db> bt >>>>>>> Tracing pid 86 tid 100054 td 0xc541b000 >>>>>>> kdb_enter(c0a00d16,c0a09130,0,0,0,...) at panix+0x190 >>>>>>> witness_warn(2,0,x0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >>>>>>> syscall(d1de3d08) at syscall+0x415 >>>>>>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>>>>>> >>>>>>> Hmm, I guess I forgot to install kernel debug symbols... >>>>>>> Coming back if I have more >>>>>> Unfortunately unionfs does very wrong things with the insmntque() locking. >>>>>> It basically expects the vnode to return locked in the same way >>>>>> requested by the precedent namei() (when that happens) but when you do >>>>>> insmntque() you can only have an LK_EXCLUSIVE lock on the vnode. >>>>> Hello, >>>>> the following patch should workout the issues around unionfs_nodeget() a bit: >>>>> http://www.freebsd.org/~attilio/unionfs_nodeget2.patch >>>>> >>>>> Unfortunately unionfs code is rather messy in the lookup path about >>>>> locking requirements so follow what it needs to be done there is a bit >>>>> difficult. >>>>> I have no way to test this patch, so it is just test-compiled at the >>>>> moment, but I would need that you also test lookup path (so directory >>>>> "ls", find(1) on the whole unionfs volume, etc.) to validate it >>>>> someway. >>>> On a second thought, I think that locking in lookup (and also other >>>> operations) is so fragile and difficult to follow that it makes all >>>> vnops real locking landmines. >>>> I think that the following patch fixes the insmntque insertion and >>>> follows the old approach well enough to be committed separately: >>>> http://www.freebsd.org/~attilio/unionfs_nodeget3.patch >>>> >>> Unfortunately I have no idea about all those locking strategies and >>> implementations. >>> Applying unionfs_nodeget3.patch results in: >>> sys/fs/unionfs/union_subr.c: In function 'unionfs_nodeget': >>> sys/fs/unionfs/union_subr.c:332: error: expected statement >>> before ')' token >>> *** [union_subr.o] Error code 1 >>> >>> I guess there is a typo in this chunk: >>> @@ -317,11 +328,11 @@ unionfs_nodeget(struct mount *mp, struct vnode *up >>> >>> vref(vp); >>> } else >>> *vpp = vp; >>> - >>> -unionfs_nodeget_out: >>> - if (lkflags & LK_TYPE_MASK) >>> - vn_lock(vp, lkflags | LK_RETRY); >>> - >>> + if (lkflags & LK_TYPE_MASK) { >>> + if (lkflags == LK_SHARED)) >>> ---------------------------------------- ^ >>> + vn_lock(vp, LK_DOWNGRADE | LK_RETRY); >>> + } else >>> + VOP_UNLOCK(vp, LK_RELEASE); >>> return (0); >>> } >>> >>> After removing the second right parenthesis kernel compiles. >>> But it still crashes: >>> panic: Lock (lockmgr) ufs not locked @ sys/kern/vfs_default.c:512 >>> cpuid = 1 >>> KDB: stack backtrace: >>> ... >>> If you can use the bt info I'll transcribe - no serial console available :-( >>> >>> Am I right that I should only apply _one_ unionfs-patchX.patch >>> (unionfs_nodeget3.patch in that case)? >> Yes, only that one. >> Can you please do "bt" from DDB and take a picture of you screen with a camera? > > Ok, now I had a reason to take some time finding out how ESXi handles > serial ports ;-) It's quiet easy and very flexible, so no problem > setting up a debug console. > Please find attached the backtrace. > Do I have to load any symbols? It's not very informative what I see, right? Hi Harry, well done. Can you please backout the prior patch and try this one instead?: http://www.freebsd.org/~attilio/unionfs_nodeget4.patch Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 14:25:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26CD47DB for ; Fri, 2 Nov 2012 14:25:23 +0000 (UTC) (envelope-from pulley@dabus.com) Received: from aegir.dabus.com (aegir.dabus.com [173.14.229.218]) by mx1.freebsd.org (Postfix) with ESMTP id F16288FC08 for ; Fri, 2 Nov 2012 14:25:22 +0000 (UTC) Received: from aegir.dabus.com (localhost [127.0.0.1]) by aegir.dabus.com (Processor) with ESMTP id 1B6EA5F312 for ; Fri, 2 Nov 2012 08:11:34 -0600 (MDT) DomainKey-Signature: a=rsa-sha1; b=paEuEOGYLx2J8O9mp2nwVhkVEKKVDOPvZz1nx/3i0VL0F8b14IoQ1TqzwmgMxHUmT3VfIV9rOGKOTorj7cxdd9EMJz+7fzsP8tWmlX9yp9RQM1STJF3Yvlg9NtcXOICRLJbAQW4e10NDTRR7XrnrCHybYEacS1KCYpFUahtjdTA=; c=nofws; d=dabus.com; q=dns; s=aegir1 Received: from webmail.dabus.com (aegir.dabus.com [173.14.229.218]) by aegir.dabus.com (Dabus) with ESMTPA id EEE635F300 for ; Fri, 2 Nov 2012 08:11:33 -0600 (MDT) Received: from 131.77.1.84 (SquirrelMail authenticated user pulley) by webmail.dabus.com with HTTP; Fri, 2 Nov 2012 08:11:33 -0600 Message-ID: Date: Fri, 2 Nov 2012 08:11:33 -0600 Subject: Re: 9.1 stability/robustness? From: pulley@dabus.com To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:25:23 -0000 > I need to build up a few servers and routers, and am wondering how > FreeBSD 9.1 is shaping up. Will it be likely to be more stable and > robust than 9.0-RELEASE? Are there issues that will have to wait > until 9.2-RELEASE to be fixed? Opinions welcome. > > --Brett Glass I've got 9.1-RC2 running on 2 amd64 boxes both using ZFS root builds and 2 i386 platforms one desktop and one netbook. The amd64 boxes are one file server (NFS/SMB) and one KDE4 photography work-flow desktop/proofing station. Moving large files/video streaming over lagg0 (LACP) gig-E lines no worries so far (knock knock). Both many core large ram systems. The 2 i386's are just screw-around desktops (web email etc..) but no problems there either. As for routers I always use OpenBSD there just out of old habit more than any technical reason and 5.2 is working great there...for the past 22 hours at least :) looking forward to RC3 or release -- Eric S Pulley From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 16:57:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3CA8FC2 for ; Fri, 2 Nov 2012 16:57:57 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 351BF8FC16 for ; Fri, 2 Nov 2012 16:57:56 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Fri, 2 Nov 2012 17:47:48 +0100 Message-ID: <5093F934.7050306@ose.nl> Date: Fri, 02 Nov 2012 17:47:48 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: SU+J on 9.1-RC2 ISO Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:57:57 -0000 Hi Why are journaled soft updates the default when installing a new system=20= from a 9=2E1-RC2 ISO=3F I admit I did not pay too much attention when installing a new system=20 from an 9=2E1-RC2 ISO and found out when taking a snapshot with dump =28dum= p=20 -0Lauf=29 to clone the system=2E Other systems =289-STABLE=2C 9=2E1-RC2 and= =20 9=2E1-RC3=29 have been upgraded from 8=2EX-RELEASE and earlier=2C so there= are=20 no journaled soft updates enabled=2C just soft updates=2C and well there=20= dump with snapshot works just fine=2E Can SU+J be disabled for the 9=2E1-RELEASE or do you think this is not=20= going to be a problem for users of FreeBSD=3F I will have to boot these=20= two systems single user now to disable the soft updates journal=2C because= =20 I use dump + restore on live systems=2C not a problem for me=2C it is just= =20 an inconvenience=2E Cheers Bas This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 17:05:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45EA235E for ; Fri, 2 Nov 2012 17:05:07 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 138A78FC0A for ; Fri, 2 Nov 2012 17:05:06 +0000 (UTC) Received: from [192.168.15.220] (gw.digitalspark.net [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 4F505BBAAC; Fri, 2 Nov 2012 13:04:59 -0400 (EDT) Message-ID: <5093FD3D.3080201@ateamsystems.com> Date: Sat, 03 Nov 2012 00:05:01 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Bas Smeelen Subject: Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> In-Reply-To: <5093F934.7050306@ose.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:05:07 -0000 On 11/2/2012 23:47, Bas Smeelen wrote: > Hi > > Why are journaled soft updates the default when installing a new system > from a 9.1-RC2 ISO? > > I admit I did not pay too much attention when installing a new system > from an 9.1-RC2 ISO and found out when taking a snapshot with dump (dump > -0Lauf) to clone the system. Other systems (9-STABLE, 9.1-RC2 and > 9.1-RC3) have been upgraded from 8.X-RELEASE and earlier, so there are > no journaled soft updates enabled, just soft updates, and well there > dump with snapshot works just fine. > > Can SU+J be disabled for the 9.1-RELEASE or do you think this is not > going to be a problem for users of FreeBSD? I will have to boot these > two systems single user now to disable the soft updates journal, because > I use dump + restore on live systems, not a problem for me, it is just > an inconvenience. I have to second this sentiment. Unless the dump/snapshot issue has been resolved they journal should be turned off by default. It's a really nasty bug that causes an instant panic which is awful if the server is in production. The fact that it happens when you're trying to exercise due diligence (ie; backups) is even worse. -- my .02 From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 17:13:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F045E76B for ; Fri, 2 Nov 2012 17:13:11 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id BE5F88FC0C for ; Fri, 2 Nov 2012 17:13:11 +0000 (UTC) Received: from [172.16.10.200] (unknown [172.16.10.200]) by mail.intertainservices.com (Postfix) with ESMTPSA id E1E2A5647D; Fri, 2 Nov 2012 13:13:01 -0400 (EDT) Message-ID: <1351876381.2657.1.camel@mjakubik.localdomain> Subject: Re: SU+J on 9.1-RC2 ISO From: Mike Jakubik To: Adam Strohl Date: Fri, 02 Nov 2012 13:13:01 -0400 In-Reply-To: <5093FD3D.3080201@ateamsystems.com> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: E1E2A5647D.A0D85 X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Cc: Bas Smeelen , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:13:12 -0000 On Sat, 2012-11-03 at 00:05 +0700, Adam Strohl wrote: > On 11/2/2012 23:47, Bas Smeelen wrote: > > Hi > > > > Why are journaled soft updates the default when installing a new system > > from a 9.1-RC2 ISO? > > Can SU+J be disabled for the 9.1-RELEASE or do you think this is not > > going to be a problem for users of FreeBSD? I will have to boot these > > two systems single user now to disable the soft updates journal, because > > I use dump + restore on live systems, not a problem for me, it is just > > an inconvenience. > > > I have to second this sentiment. Unless the dump/snapshot issue has > been resolved they journal should be turned off by default. > > It's a really nasty bug that causes an instant panic which is awful if > the server is in production. The fact that it happens when you're > trying to exercise due diligence (ie; backups) is even worse. You can disable SU+J after installing, though it would be nice if the installer gave you a choice. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 17:24:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB6C6C28 for ; Fri, 2 Nov 2012 17:24:11 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 34B1C8FC08 for ; Fri, 2 Nov 2012 17:24:10 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so3484737lag.13 for ; Fri, 02 Nov 2012 10:24:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=k5wwfOT9FH+M/zXrEx+zyWiag/n9T4OK1aMsX/RrkD8=; b=VBEOuH16NyU9x7iGjoHDFawZvXVN1tt73WhTOzrX0Zp9FHpLzHi0jp7eHB8DVbPZli RGDoYQrLn9xODQbEODxJmmsss2J/EUPeA2ly1OOaCmMPeSiHSunVcp/pTXVo6UOnlMmZ FQz+MY6nevTdpWYWED+f+dlLG+C1FzjSm1NAN3QEz3if/hT3mzzfGXMnh/FR2bwPTMvZ zxTNQkrR1of2C+H/OAFksxvNrOpErhkI+AnSxR1MDQGRP1DYPcGm6IEr750RM0Rmv6sx nhZ4Tbfw1CQU/RPdblF4dwJAZ7IUPbAyZsm77zd+2ecWlJpSmsugIJ6vKf0yS21jdwjZ G2qQ== Received: by 10.152.103.243 with SMTP id fz19mr2277211lab.27.1351877043771; Fri, 02 Nov 2012 10:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.25.2 with HTTP; Fri, 2 Nov 2012 10:23:33 -0700 (PDT) In-Reply-To: <1351876381.2657.1.camel@mjakubik.localdomain> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> From: Maxim Khitrov Date: Fri, 2 Nov 2012 13:23:33 -0400 Message-ID: Subject: Re: SU+J on 9.1-RC2 ISO To: Mike Jakubik Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnwVvqD5ynVPhqasGBQ2VplFSdntRwZO3kTNOwb3QGafzid922ohTKqr6GzVmhM92Tlpnof Cc: Bas Smeelen , freebsd-stable@freebsd.org, Adam Strohl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:24:12 -0000 On Fri, Nov 2, 2012 at 1:13 PM, Mike Jakubik wrote: > On Sat, 2012-11-03 at 00:05 +0700, Adam Strohl wrote: >> On 11/2/2012 23:47, Bas Smeelen wrote: >> > Hi >> > >> > Why are journaled soft updates the default when installing a new system >> > from a 9.1-RC2 ISO? > >> > Can SU+J be disabled for the 9.1-RELEASE or do you think this is not >> > going to be a problem for users of FreeBSD? I will have to boot these >> > two systems single user now to disable the soft updates journal, because >> > I use dump + restore on live systems, not a problem for me, it is just >> > an inconvenience. >> >> >> I have to second this sentiment. Unless the dump/snapshot issue has >> been resolved they journal should be turned off by default. >> >> It's a really nasty bug that causes an instant panic which is awful if >> the server is in production. The fact that it happens when you're >> trying to exercise due diligence (ie; backups) is even worse. > > > You can disable SU+J after installing, though it would be nice if the > installer gave you a choice. I don't think SU+J should even be an option in the installer as long as this bug persists. If you don't use dump, go ahead and enable journaling after the installation, but it's not a decision that new users should be asked to make. This should not have been the default in 9.0-RELEASE and I'm surprised to see that it's still not fixed in 9.1. - Max From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 17:27:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B6A7D48 for ; Fri, 2 Nov 2012 17:27:17 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 451348FC0A for ; Fri, 2 Nov 2012 17:27:16 +0000 (UTC) Received: from [192.168.15.220] (gw.digitalspark.net [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 64EBDB9F24; Fri, 2 Nov 2012 13:27:15 -0400 (EDT) Message-ID: <50940276.5030306@ateamsystems.com> Date: Sat, 03 Nov 2012 00:27:18 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mike Jakubik Subject: Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> In-Reply-To: <1351876381.2657.1.camel@mjakubik.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bas Smeelen , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:27:17 -0000 On 11/3/2012 0:13, Mike Jakubik wrote: > You can disable SU+J after installing, though it would be nice if the > installer gave you a choice. This assumes that you know about this flaw, which most people do not. I didn't until I discovered it by panic-ing a perfectly fine running server. Getting burned by a known bug like this shouldn't be "SOP" for users of FreeBSD. If anything it should be turned off by default, and people can turn it on if they want given the landmine it plants. If they know how to turn it on they're much more likely to be aware of the issue. -- Adam Strohl http://www.ateamsystems.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 17:28:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE6ABE4A for ; Fri, 2 Nov 2012 17:28:10 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 793898FC08 for ; Fri, 2 Nov 2012 17:28:10 +0000 (UTC) Received: from [172.16.10.200] (unknown [172.16.10.200]) by mail.intertainservices.com (Postfix) with ESMTPSA id 34F7F564E0; Fri, 2 Nov 2012 13:28:09 -0400 (EDT) Message-ID: <1351877289.2657.3.camel@mjakubik.localdomain> Subject: Re: SU+J on 9.1-RC2 ISO From: Mike Jakubik To: Maxim Khitrov Date: Fri, 02 Nov 2012 13:28:09 -0400 In-Reply-To: References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: 34F7F564E0.AFEDA X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Cc: Bas Smeelen , freebsd-stable@freebsd.org, Adam Strohl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:28:10 -0000 On Fri, 2012-11-02 at 13:23 -0400, Maxim Khitrov wrote: > I don't think SU+J should even be an option in the installer as long > as this bug persists. If you don't use dump, go ahead and enable > journaling after the installation, but it's not a decision that new > users should be asked to make. This should not have been the default > in 9.0-RELEASE and I'm surprised to see that it's still not fixed in > 9.1. True, that would be in accordance with the FreeBSD POLA. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 17:31:00 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7520617B for ; Fri, 2 Nov 2012 17:31:00 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 249DD8FC19 for ; Fri, 2 Nov 2012 17:30:59 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so5287736vcb.13 for ; Fri, 02 Nov 2012 10:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JNXWAM5DA6Ruo1j+Zmr+t5e+1t7TLcmRy+xgxzpHOC4=; b=G3AFQ62zFZpSmLxrAPWb/Bfk5T2ihTFEHNPMiD9Zz29d+0wWl1Cm2zK5xSZoWsvcz1 PFnJMaJIUnPl43HUsPk650SNmDgtEryDG0Nlm0F2Ju3NLTA0VolIYbcIW1t3HuMwCgbr gJN1u2LOBtVOFKR45CRA9plVutHqjUpFsGEp8yonVwzCJW5gJCoXBpPnjb2dZL25QJXY vfSPkDRiI+PUI0TnjsJbRYUJSyIs8qDoNKaAsoPxdkHtidoO7SXuNJSLwrjujvesDn9K Th/d+dZrDVctNbPWzPAHLr+EcOv2/9SwXZDIo2QK4VVJFbVPxTiMBrWJE+acQiwYWnOE Q7yg== MIME-Version: 1.0 Received: by 10.52.89.146 with SMTP id bo18mr2156602vdb.33.1351877459231; Fri, 02 Nov 2012 10:30:59 -0700 (PDT) Received: by 10.58.203.4 with HTTP; Fri, 2 Nov 2012 10:30:59 -0700 (PDT) In-Reply-To: <201211020214.UAA29489@lariat.net> References: <201211020214.UAA29489@lariat.net> Date: Fri, 2 Nov 2012 10:30:59 -0700 Message-ID: Subject: Re: FreeBSD 9.1 stability/robustness? From: pete wright To: Brett Glass Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:31:00 -0000 On Thu, Nov 1, 2012 at 7:14 PM, Brett Glass wrote: > I need to build up a few servers and routers, and am wondering how > FreeBSD 9.1 is shaping up. Will it be likely to be more stable and > robust than 9.0-RELEASE? Are there issues that will have to wait > until 9.2-RELEASE to be fixed? Opinions welcome. > Just another data point: running 9.1-RC1 as well as 9.1-RC2 since they have become available on my primary workstation/build server (for pkgng pkg's), in addition to my mail/web/shell servers. I have managed all my updates via freebsd-update, so no custom bits compiled for the kernel or userland. have had no lockups, and performance is great on my workstation/build server. On all systems I've been using a combination of ufs and zfs w/o issues as well. Hope this helps. -pete -- pete wright www.nycbug.org @nomadlogicLA From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 17:34:25 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 470063C0 for ; Fri, 2 Nov 2012 17:34:25 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E87358FC0A for ; Fri, 2 Nov 2012 17:34:24 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so5292220vcb.13 for ; Fri, 02 Nov 2012 10:34:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version :x-gm-message-state; bh=zxVgSQFZqRq5b30c+W0Z4G7+5uiSNMvQ9hU6J9odu0E=; b=TifjXlxLRbGlylcNiGXC28B4NLEuSE+lhkHYEOqLzIRvEGJ31RWf2U/oAhXvhePU0s 4kGcukprXSDtg17yWcUCJClDvjLbl9iUu/DIyFJnCKdFSECf9ZysBLH1+m9TRqK2SKw6 FIGxiCiz3V5BYbV37Lan7FIGYScdLMFG/PRsMo9OpxVVgz3cHtuMx64kGz53ZWrz09WB et2hZqEGxpiUtMG1NKCOsDpf0S1xP2Snlx29cGo0PXkh2fzZRaIEcso6JSBFqSJ6P3wG 98D4k8CT2x5asVOrx7her5XXpiSVzPlIb+ZSVBJ4uOvtPbrLBIbvJYgp4cl+qx94KP1E Xb6Q== Received: by 10.220.115.138 with SMTP id i10mr2495360vcq.37.1351877664033; Fri, 02 Nov 2012 10:34:24 -0700 (PDT) Received: from [192.168.11.202] (ool-182c8567.dyn.optonline.net. [24.44.133.103]) by mx.google.com with ESMTPS id f10sm5848289vdk.5.2012.11.02.10.34.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 10:34:22 -0700 (PDT) Subject: Re: FreeBSD 9.1 stability/robustness? References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> From: Mark Saad Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) In-Reply-To: <20121102091021.23cf9af0@suse3> Message-Id: Date: Fri, 2 Nov 2012 13:34:20 -0400 To: "stable@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQkZrNyCXLdultz4uAmVhWx+Pr4/Cn9LkcSZuoe4cTbqfU67lk5gYww91H+KfgIqjAZ+TmfL X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:34:25 -0000 On Nov 2, 2012, at 4:10 AM, Rainer Duffner wrote: > Am Thu, 1 Nov 2012 20:14:51 -0600 (MDT) > schrieb Brett Glass : >=20 >> I need to build up a few servers and routers, and am wondering how >> FreeBSD 9.1 is shaping up. Will it be likely to be more stable and >> robust than 9.0-RELEASE? Are there issues that will have to wait >> until 9.2-RELEASE to be fixed? Opinions welcome. >=20 >=20 > If I'm not mistaken, the bge-stuff that makes the default NICs ins HP > G8 servers (360+380) actually run will not make it back into 9.1. > Intel cards work much better anyway... >=20 Did you swap out the bge nic daughter card in the g8 servers for an intel on= e or , do you mean in general the intel nic support is better ?=20 > _______________________________________________ > 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-stable@FreeBSD.ORG Fri Nov 2 18:05:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56C9CF45 for ; Fri, 2 Nov 2012 18:05:57 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id D94758FC1C for ; Fri, 2 Nov 2012 18:05:56 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Fri, 2 Nov 2012 19:05:54 +0100 Message-ID: <50940B81.4010904@ose.nl> Date: Fri, 02 Nov 2012 19:05:53 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: [patch proposal] Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> In-Reply-To: <50940276.5030306@ateamsystems.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:05:57 -0000 On 11/02/2012 06=3A27 PM=2C Adam Strohl wrote=3A =3E On 11/3/2012 0=3A13=2C Mike Jakubik wrote=3A =3E=3E You can disable SU+J after installing=2C though it would be nice if= the =3E=3E installer gave you a choice=2E =3E =3E This assumes that you know about this flaw=2C which most people do not= =2E =3E =3E I didn=27t until I discovered it by panic-ing a perfectly fine running= =20 =3E server=2E Getting burned by a known bug like this shouldn=27t be =22SO= P=22=20 =3E for users of FreeBSD=2E =3E =3E If anything it should be turned off by default=2C and people can turn i= t=20 =3E on if they want given the landmine it plants=2E If they know how to=20= =3E turn it on they=27re much more likely to be aware of the issue=2E =3E =3E Hi all I am not sure if this is the right place=2C but would like to propose this= =20 patch root=40sys=3A/usr/src/usr=2Esbin/bsdinstall/partedit =23 diff -p gpart=5Fop= s=2Ec=20 gpart=5Fops=2Ecnew *** gpart=5Fops=2Ec Mon Aug 6 01=3A54=3A33 2012 --- gpart=5Fops=2Ecnew Fri Nov 2 19=3A02=3A43 2012 *************** newfs=5Fcommand=28const char *fstype=2C char * *** 90=2C97 **** =7B=22SU=22=2C =22Softupdates=22=2C =22Enable softupdates =28default=29=22=2C 1 =7D=2C =7B=22SUJ=22=2C =22Softupdates journaling=22=2C ! =22Enable file system journaling =28default - =22 ! =22turn off for SSDs=29=22=2C 1 =7D=2C =7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =22Enable TRIM support=2C useful on solid-state drives= =22=2C 0 =7D=2C --- 90=2C97 ---- =7B=22SU=22=2C =22Softupdates=22=2C =22Enable softupdates =28default=29=22=2C 1 =7D=2C =7B=22SUJ=22=2C =22Softupdates journaling=22=2C ! =22Disble file system journaling =28default - =22 ! =22turn on for adventurish admins=29=22=2C 0 =7D=2C =7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =22Enable TRIM support=2C useful on solid-state drives= =22=2C 0 =7D=2C If OK I will file a PR Cheers Bas This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 18:08:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78BCD21D for ; Fri, 2 Nov 2012 18:08:35 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 0694A8FC19 for ; Fri, 2 Nov 2012 18:08:34 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Fri, 2 Nov 2012 19:08:32 +0100 Message-ID: <50940C20.3090409@ose.nl> Date: Fri, 02 Nov 2012 19:08:32 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: [patch proposal typo corrected] Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> In-Reply-To: <50940276.5030306@ateamsystems.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:08:35 -0000 On 11/02/2012 06=3A27 PM=2C Adam Strohl wrote=3A =3E On 11/3/2012 0=3A13=2C Mike Jakubik wrote=3A =3E=3E You can disable SU+J after installing=2C though it would be nice if= the =3E=3E installer gave you a choice=2E =3E =3E This assumes that you know about this flaw=2C which most people do not= =2E =3E =3E I didn=27t until I discovered it by panic-ing a perfectly fine running= =3E server=2E Getting burned by a known bug like this shouldn=27t be =22SO= P=22 =3E for users of FreeBSD=2E =3E =3E If anything it should be turned off by default=2C and people can turn i= t =3E on if they want given the landmine it plants=2E If they know how to =3E turn it on they=27re much more likely to be aware of the issue=2E =3E =3E Hi all I am not sure if this is the right place=2C but would like to propose this= =20 patch root=40sys=3A/usr/src/usr=2Esbin/bsdinstall/partedit =23 diff -p gpart=5Fop= s=2Ec=20 gpart=5Fops=2Ecnew *** gpart=5Fops=2Ec Mon Aug 6 01=3A54=3A33 2012 --- gpart=5Fops=2Ecnew Fri Nov 2 19=3A02=3A43 2012 *************** newfs=5Fcommand=28const char *fstype=2C char * *** 90=2C97 **** =7B=22SU=22=2C =22Softupdates=22=2C =22Enable softupdates =28default=29=22=2C 1 =7D=2C =7B=22SUJ=22=2C =22Softupdates journaling=22=2C ! =22Enable file system journaling =28default - =22 ! =22turn off for SSDs=29=22=2C 1 =7D=2C =7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =22Enable TRIM support=2C useful on solid-state drives= =22=2C 0 =7D=2C --- 90=2C97 ---- =7B=22SU=22=2C =22Softupdates=22=2C =22Enable softupdates =28default=29=22=2C 1 =7D=2C =7B=22SUJ=22=2C =22Softupdates journaling=22=2C ! =22Disable file system journaling =28default - =22 ! =22turn on for adventurish admins=29=22=2C 0 =7D=2C =7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =22Enable TRIM support=2C useful on solid-state drives= =22=2C 0 =7D=2C If OK I will file a PR Cheers Bas This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 18:17:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABCCD725 for ; Fri, 2 Nov 2012 18:17:39 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 08B838FC14 for ; Fri, 2 Nov 2012 18:17:38 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Fri, 2 Nov 2012 19:17:37 +0100 Message-ID: <50940E40.3090709@ose.nl> Date: Fri, 02 Nov 2012 19:17:36 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: [patch proposal typo corrected] Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <50940C20.3090409@ose.nl> In-Reply-To: <50940C20.3090409@ose.nl> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:17:39 -0000 On 11/02/2012 07=3A08 PM=2C Bas Smeelen wrote=3A =3E On 11/02/2012 06=3A27 PM=2C Adam Strohl wrote=3A =3E=3E On 11/3/2012 0=3A13=2C Mike Jakubik wrote=3A =3E=3E=3E You can disable SU+J after installing=2C though it would be nice= if the =3E=3E=3E installer gave you a choice=2E =3E=3E This assumes that you know about this flaw=2C which most people do n= ot=2E =3E=3E =3E=3E I didn=27t until I discovered it by panic-ing a perfectly fine runni= ng =3E=3E server=2E Getting burned by a known bug like this shouldn=27t be=20= =22SOP=22 =3E=3E for users of FreeBSD=2E =3E=3E =3E=3E If anything it should be turned off by default=2C and people can tur= n it =3E=3E on if they want given the landmine it plants=2E If they know how to= =3E=3E turn it on they=27re much more likely to be aware of the issue=2E =3E=3E =3E=3E Sorry for the spam=2E Also since newer systems will be installing more and more on SSD it is=20= better to default SU+J to off as I understand from the original source=2E= Cheers =3E Hi all =3E =3E I am not sure if this is the right place=2C but would like to propose t= his =3E patch =3E root=40sys=3A/usr/src/usr=2Esbin/bsdinstall/partedit =23 diff -p gpart= =5Fops=2Ec =3E gpart=5Fops=2Ecnew =3E *** gpart=5Fops=2Ec Mon Aug 6 01=3A54=3A33 2012 =3E --- gpart=5Fops=2Ecnew Fri Nov 2 19=3A02=3A43 2012 =3E *************** newfs=5Fcommand=28const char *fstype=2C char * =3E *** 90=2C97 **** =3E =7B=22SU=22=2C =22Softupdates=22=2C =3E =22Enable softupdates =28default=29=22=2C 1 =7D=2C= =3E =7B=22SUJ=22=2C =22Softupdates journaling=22=2C =3E ! =22Enable file system journaling =28default - =22 =3E ! =22turn off for SSDs=29=22=2C 1 =7D=2C =3E =7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =3E =22Enable TRIM support=2C useful on solid-state dri= ves=22=2C =3E 0 =7D=2C =3E --- 90=2C97 ---- =3E =7B=22SU=22=2C =22Softupdates=22=2C =3E =22Enable softupdates =28default=29=22=2C 1 =7D=2C= =3E =7B=22SUJ=22=2C =22Softupdates journaling=22=2C =3E ! =22Disable file system journaling =28default - =22 =3E ! =22turn on for adventurish admins=29=22=2C 0 =7D=2C= =3E =7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =3E =22Enable TRIM support=2C useful on solid-state dri= ves=22=2C =3E 0 =7D=2C =3E =3E If OK I will file a PR =3E Cheers =3E Bas =3E =3E =3E =3E This e-mail message=2C including any attachment=28s=29=2C is intended s= olely for the addressee or addressees=2E Any views or opinions presented he= rein are solely those of the author and do not necessarily represent those= of OSE=2E =3E =3E If you are not the intended recipient of this communication please retu= rn this e-mail message and the attachment=28s=29 to the sender and delete a= nd destroy all copies=2E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E freebsd-stable=40freebsd=2Eorg mailing list =3E http=3A//lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-stable =3E To unsubscribe=2C send any mail to =22freebsd-stable-unsubscribe=40free= bsd=2Eorg=22 This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 18:30:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AACD6C44 for ; Fri, 2 Nov 2012 18:30:07 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4078FC0A for ; Fri, 2 Nov 2012 18:30:07 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-stable@freebsd.org; Fri, 2 Nov 2012 19:30:05 +0100 Message-ID: <5094112C.2070102@ose.nl> Date: Fri, 02 Nov 2012 19:30:04 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: [patch] Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <50940C20.3090409@ose.nl> <50940E40.3090709@ose.nl> In-Reply-To: <50940E40.3090709@ose.nl> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:30:07 -0000 On 11/02/2012 07=3A17 PM=2C Bas Smeelen wrote=3A =3E On 11/02/2012 07=3A08 PM=2C Bas Smeelen wrote=3A =3E=3E On 11/02/2012 06=3A27 PM=2C Adam Strohl wrote=3A =3E=3E=3E On 11/3/2012 0=3A13=2C Mike Jakubik wrote=3A =3E=3E=3E=3E You can disable SU+J after installing=2C though it would be ni= ce if the =3E=3E=3E=3E installer gave you a choice=2E =3E=3E=3E This assumes that you know about this flaw=2C which most people d= o not=2E =3E=3E=3E =3E=3E=3E I didn=27t until I discovered it by panic-ing a perfectly fine ru= nning =3E=3E=3E server=2E Getting burned by a known bug like this shouldn=27t be= =22SOP=22 =3E=3E=3E for users of FreeBSD=2E =3E=3E=3E =3E=3E=3E If anything it should be turned off by default=2C and people can= turn it =3E=3E=3E on if they want given the landmine it plants=2E If they know how= to =3E=3E=3E turn it on they=27re much more likely to be aware of the issue=2E= =3E=3E=3E =3E=3E=3E =3E=3E=3E To sum it up SU+J should be turned off by default because of 1=2E It does not work with dumping a live system e=2Eg=2E snapshot 2=2E it is not recommended for SSD installs 3=2E =22Smart=22 admins can turn it on if they want root=40sys=3A/usr/src/usr=2Esbin/bsdinstall/partedit =23 diff -u gpart=5Fop= s=2Ec=20 gpart=5Fops=2Ecnew --- gpart=5Fops=2Ec 2012-08-06 01=3A54=3A33=2E000000000 +0200 +++ gpart=5Fops=2Ecnew 2012-11-02 19=3A07=3A45=2E000000000 +0100 =40=40 -90=2C8 +90=2C8 =40=40 =7B=22SU=22=2C =22Softupdates=22=2C =22Enable softupdates =28default=29=22=2C 1 =7D=2C =7B=22SUJ=22=2C =22Softupdates journaling=22=2C - =22Enable file system journaling =28default - =22 - =22turn off for SSDs=29=22=2C 1 =7D=2C + =22Disable file system journaling =28default - =22 + =22turn on for adventurish admins=29=22=2C 0 =7D=2C =7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =22Enable TRIM support=2C useful on solid-state drives=22= =2C 0 =7D=2C Please comment=2C then I can file a PR or not Cheers Bas This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 18:31:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1623D57 for ; Fri, 2 Nov 2012 18:31:34 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 450A98FC08 for ; Fri, 2 Nov 2012 18:31:33 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x43so2149191wey.13 for ; Fri, 02 Nov 2012 11:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=BnIuo/D/Buht6H0f7kXkZznLxWcIEVDwGTtu27oEH+c=; b=y8rdqmuj9x8XbfGPvtBlTqD8I626waqV8aWiy2IpIBB0nfpfI9gH3GeFBSlmFogG7r BezNg9isp8agkVRzcLTN6j/6MtbgTsYbo/CNFfY6tULEA8TNlRrIV2Rhh6uVWRx8Qnv2 Ux4P4MwXvUwa9rgqkgwQt/dF0fQPaaV4mw3YMsoCkScFCFqGgoNZMiuDBWeCBLOJEvB0 BLWEVze/xdX5M85zagpbeZPJH3XjBFQauSvL5Lo1K5V88YX++MabGpXEMqVF7g2c15S1 Uot4E4xkzoV1AU/doQT31b6525RgZ6e7JpWTqnZiP/xno+JMMoy+W8JdbS//GdimzUWb OTog== Received: by 10.180.7.197 with SMTP id l5mr3970781wia.13.1351881092865; Fri, 02 Nov 2012 11:31:32 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id dt9sm3345227wib.1.2012.11.02.11.31.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 11:31:32 -0700 (PDT) Date: Fri, 2 Nov 2012 19:31:24 +0100 From: Mateusz Guzik To: Adam Strohl Subject: Re: SU+J on 9.1-RC2 ISO Message-ID: <20121102183123.GA22755@dft-labs.eu> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <50940276.5030306@ateamsystems.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Bas Smeelen , Mike Jakubik , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:31:34 -0000 On Sat, Nov 03, 2012 at 12:27:18AM +0700, Adam Strohl wrote: > On 11/3/2012 0:13, Mike Jakubik wrote: > >You can disable SU+J after installing, though it would be nice if the > >installer gave you a choice. > > This assumes that you know about this flaw, which most people do not. > > I didn't until I discovered it by panic-ing a perfectly fine running > server. Getting burned by a known bug like this shouldn't be "SOP" > for users of FreeBSD. > Currently when you try to take a snapshot, the kernel checks whether SUJ is enabled on specified mount-point, and if yes it returns EOPNOTSUPP. See this commit (MFCed as r230725): http://svnweb.freebsd.org/base?view=revision&revision=230250 So it's not that bad. > If anything it should be turned off by default, and people can turn > it on if they want given the landmine it plants. If they know how > to turn it on they're much more likely to be aware of the issue. > That being said, sure, you may run into another bugs, but if SUJ was enabled by default I guess it was felt that it works well enough (and in case of known bugs like problems with snapshots just bails out early). -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 18:35:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C43A4EA9 for ; Fri, 2 Nov 2012 18:35:49 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 50B298FC08 for ; Fri, 2 Nov 2012 18:35:49 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Fri, 2 Nov 2012 19:35:46 +0100 Message-ID: <50941282.6010901@ose.nl> Date: Fri, 02 Nov 2012 19:35:46 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <20121102183123.GA22755@dft-labs.eu> In-Reply-To: <20121102183123.GA22755@dft-labs.eu> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Mateusz Guzik X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:35:50 -0000 On 11/02/2012 07=3A31 PM=2C Mateusz Guzik wrote=3A =3E On Sat=2C Nov 03=2C 2012 at 12=3A27=3A18AM +0700=2C Adam Strohl wrote= =3A =3E=3E On 11/3/2012 0=3A13=2C Mike Jakubik wrote=3A =3E=3E=3E You can disable SU+J after installing=2C though it would be nice= if the =3E=3E=3E installer gave you a choice=2E =3E=3E This assumes that you know about this flaw=2C which most people do n= ot=2E =3E=3E =3E=3E I didn=27t until I discovered it by panic-ing a perfectly fine runni= ng =3E=3E server=2E Getting burned by a known bug like this shouldn=27t be=20= =22SOP=22 =3E=3E for users of FreeBSD=2E =3E=3E =3E Currently when you try to take a snapshot=2C the kernel checks whether= SUJ =3E is enabled on specified mount-point=2C and if yes it returns EOPNOTSUPP= =2E =3E =3E See this commit =28MFCed as r230725=29=3A =3E http=3A//svnweb=2Efreebsd=2Eorg/base=3Fview=3Drevision=26amp=3Brevision= =3D230250 =3E =3E So it=27s not that bad=2E How about more installs on SSD and the hint about this in the=20 bsdinstaller source=3F This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 18:41:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF00E79 for ; Fri, 2 Nov 2012 18:41:42 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 623CA8FC15 for ; Fri, 2 Nov 2012 18:41:41 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x43so2153749wey.13 for ; Fri, 02 Nov 2012 11:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=lR8wVCbt2ALBZrqxt9A+BWAzcqYAjAq5F7JP6mIAtlk=; b=QcMJpWjD3Hm3aPeCwJwsbbmlkYRbCXyXbrBkGfFDR+1lIkLu1EV7ncFY5zFqMPHTEj A1nFM/nSRZRqwqgfCtW3tEXHjVQctYQ//skvUBqVH2oLBynR/xxbskhIMsXLtmgX/+La 8QebkoxWhyHJwYmq3eqgYUVWyro1WxiHpbrr60DMPrX19234NxGa8MmRFKFs/Z7UnnOI 8YjZfCLWm0HUQCplxmqnoEJY3Eop271m2I/B6w4cUnsBp2qOQyd2QKW/c9mxJb/ucEAa lVCUhj990eM+E+rKdekt5wBRtd2eoxsd7eH15QwTFkLr+SVFElpdeY5t+EOJDDtdw4k3 6bpw== Received: by 10.180.97.35 with SMTP id dx3mr3833578wib.14.1351881700859; Fri, 02 Nov 2012 11:41:40 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id dt9sm3380796wib.1.2012.11.02.11.41.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 11:41:40 -0700 (PDT) Date: Fri, 2 Nov 2012 19:41:31 +0100 From: Mateusz Guzik To: Bas Smeelen Subject: Re: [patch] Re: SU+J on 9.1-RC2 ISO Message-ID: <20121102184131.GB22755@dft-labs.eu> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <50940C20.3090409@ose.nl> <50940E40.3090709@ose.nl> <5094112C.2070102@ose.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5094112C.2070102@ose.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:41:43 -0000 On Fri, Nov 02, 2012 at 07:30:04PM +0100, Bas Smeelen wrote: > On 11/02/2012 07:17 PM, Bas Smeelen wrote: > > On 11/02/2012 07:08 PM, Bas Smeelen wrote: > >> On 11/02/2012 06:27 PM, Adam Strohl wrote: > >>> On 11/3/2012 0:13, Mike Jakubik wrote: > >>>> You can disable SU+J after installing, though it would be nice if the > >>>> installer gave you a choice. > >>> This assumes that you know about this flaw, which most people do not. > >>> > >>> I didn't until I discovered it by panic-ing a perfectly fine running > >>> server. Getting burned by a known bug like this shouldn't be "SOP" > >>> for users of FreeBSD. > >>> > >>> If anything it should be turned off by default, and people can turn it > >>> on if they want given the landmine it plants. If they know how to > >>> turn it on they're much more likely to be aware of the issue. > >>> > >>> > >>> > To sum it up > SU+J should be turned off by default because of > 1. It does not work with dumping a live system e.g. snapshot > 2. it is not recommended for SSD installs > 3. "Smart" admins can turn it on if they want > > root@sys:/usr/src/usr.sbin/bsdinstall/partedit # diff -u gpart_ops.c > gpart_ops.cnew > --- gpart_ops.c 2012-08-06 01:54:33.000000000 +0200 > +++ gpart_ops.cnew 2012-11-02 19:07:45.000000000 +0100 > @@ -90,8 +90,8 @@ > {"SU", "Softupdates", > "Enable softupdates (default)", 1 }, > {"SUJ", "Softupdates journaling", > - "Enable file system journaling (default - " > - "turn off for SSDs)", 1 }, > + "Disable file system journaling (default - " > + "turn on for adventurish admins)", 0 }, > {"TRIM", "Enable SSD TRIM support", > "Enable TRIM support, useful on solid-state drives", > 0 }, > > Please comment, then I can file a PR or not As was noted in my another mail, the kernel will no longer crash when an attempt to take a snapshot is made. Also AFAIR SUJ can be disabled later. Given that I prefer the following: diff --git a/usr.sbin/bsdinstall/partedit/gpart_ops.c b/usr.sbin/bsdinstall/partedit/gpart_ops.c index 479365a..80296c2 100644 --- a/usr.sbin/bsdinstall/partedit/gpart_ops.c +++ b/usr.sbin/bsdinstall/partedit/gpart_ops.c @@ -91,7 +91,7 @@ newfs_command(const char *fstype, char *command, int use_default) "Enable softupdates (default)", 1 }, {"SUJ", "Softupdates journaling", "Enable file system journaling (default - " - "turn off for SSDs)", 1 }, + "turn off for SSDs or if you use snapshots)", 1 }, {"TRIM", "Enable SSD TRIM support", "Enable TRIM support, useful on solid-state drives", 0 }, http://people.freebsd.org/~mjg/patches/suj-snapshot-comment.diff -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 18:59:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1ECBE806 for ; Fri, 2 Nov 2012 18:59:32 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id DB4DF8FC0A for ; Fri, 2 Nov 2012 18:59:31 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TUMSn-000DYN-Ba; Fri, 02 Nov 2012 14:59:29 -0400 Date: Fri, 2 Nov 2012 14:59:29 -0400 From: Gary Palmer To: Mateusz Guzik Subject: Re: [patch] Re: SU+J on 9.1-RC2 ISO Message-ID: <20121102185929.GA24320@in-addr.com> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <50940C20.3090409@ose.nl> <50940E40.3090709@ose.nl> <5094112C.2070102@ose.nl> <20121102184131.GB22755@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121102184131.GB22755@dft-labs.eu> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Bas Smeelen , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:59:32 -0000 On Fri, Nov 02, 2012 at 07:41:31PM +0100, Mateusz Guzik wrote: > On Fri, Nov 02, 2012 at 07:30:04PM +0100, Bas Smeelen wrote: > > On 11/02/2012 07:17 PM, Bas Smeelen wrote: > > > On 11/02/2012 07:08 PM, Bas Smeelen wrote: > > >> On 11/02/2012 06:27 PM, Adam Strohl wrote: > > >>> On 11/3/2012 0:13, Mike Jakubik wrote: > > >>>> You can disable SU+J after installing, though it would be nice if the > > >>>> installer gave you a choice. > > >>> This assumes that you know about this flaw, which most people do not. > > >>> > > >>> I didn't until I discovered it by panic-ing a perfectly fine running > > >>> server. Getting burned by a known bug like this shouldn't be "SOP" > > >>> for users of FreeBSD. > > >>> > > >>> If anything it should be turned off by default, and people can turn it > > >>> on if they want given the landmine it plants. If they know how to > > >>> turn it on they're much more likely to be aware of the issue. > > >>> > > >>> > > >>> > > To sum it up > > SU+J should be turned off by default because of > > 1. It does not work with dumping a live system e.g. snapshot > > 2. it is not recommended for SSD installs > > 3. "Smart" admins can turn it on if they want > > > > root@sys:/usr/src/usr.sbin/bsdinstall/partedit # diff -u gpart_ops.c > > gpart_ops.cnew > > --- gpart_ops.c 2012-08-06 01:54:33.000000000 +0200 > > +++ gpart_ops.cnew 2012-11-02 19:07:45.000000000 +0100 > > @@ -90,8 +90,8 @@ > > {"SU", "Softupdates", > > "Enable softupdates (default)", 1 }, > > {"SUJ", "Softupdates journaling", > > - "Enable file system journaling (default - " > > - "turn off for SSDs)", 1 }, > > + "Disable file system journaling (default - " > > + "turn on for adventurish admins)", 0 }, > > {"TRIM", "Enable SSD TRIM support", > > "Enable TRIM support, useful on solid-state drives", > > 0 }, > > > > Please comment, then I can file a PR or not > > As was noted in my another mail, the kernel will no longer crash when an > attempt to take a snapshot is made. Also AFAIR SUJ can be disabled > later. > > Given that I prefer the following: > > diff --git a/usr.sbin/bsdinstall/partedit/gpart_ops.c b/usr.sbin/bsdinstall/partedit/gpart_ops.c > index 479365a..80296c2 100644 > --- a/usr.sbin/bsdinstall/partedit/gpart_ops.c > +++ b/usr.sbin/bsdinstall/partedit/gpart_ops.c > @@ -91,7 +91,7 @@ newfs_command(const char *fstype, char *command, int use_default) > "Enable softupdates (default)", 1 }, > {"SUJ", "Softupdates journaling", > "Enable file system journaling (default - " > - "turn off for SSDs)", 1 }, > + "turn off for SSDs or if you use snapshots)", 1 }, > {"TRIM", "Enable SSD TRIM support", > "Enable TRIM support, useful on solid-state drives", > 0 }, > > http://people.freebsd.org/~mjg/patches/suj-snapshot-comment.diff How many people realise that snapshots are needed for dump based backups (and other related features)? Gary From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 19:00:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03EBD91B for ; Fri, 2 Nov 2012 19:00:31 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 55CD98FC0C for ; Fri, 2 Nov 2012 19:00:29 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Fri, 2 Nov 2012 20:00:28 +0100 Message-ID: <5094184B.6070100@ose.nl> Date: Fri, 02 Nov 2012 20:00:27 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: [patch] Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <50940C20.3090409@ose.nl> <50940E40.3090709@ose.nl> <5094112C.2070102@ose.nl> <20121102184131.GB22755@dft-labs.eu> In-Reply-To: <20121102184131.GB22755@dft-labs.eu> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:00:31 -0000 On 11/02/2012 07=3A41 PM=2C Mateusz Guzik wrote=3A =3E On Fri=2C Nov 02=2C 2012 at 07=3A30=3A04PM +0100=2C Bas Smeelen wrote= =3A =3E=3E On 11/02/2012 07=3A17 PM=2C Bas Smeelen wrote=3A =3E=3E=3E On 11/02/2012 07=3A08 PM=2C Bas Smeelen wrote=3A =3E=3E=3E=3E On 11/02/2012 06=3A27 PM=2C Adam Strohl wrote=3A =3E=3E=3E=3E=3E On 11/3/2012 0=3A13=2C Mike Jakubik wrote=3A =3E=3E=3E=3E=3E=3E You can disable SU+J after installing=2C though it would= be nice if the =3E=3E=3E=3E=3E=3E installer gave you a choice=2E =3E=3E=3E=3E=3E This assumes that you know about this flaw=2C which most pe= ople do not=2E =3E=3E=3E=3E=3E =3E=3E=3E=3E=3E I didn=27t until I discovered it by panic-ing a perfectly f= ine running =3E=3E=3E=3E=3E server=2E Getting burned by a known bug like this shouldn= =27t be =22SOP=22 =3E=3E=3E=3E=3E for users of FreeBSD=2E =3E=3E=3E=3E=3E =3E=3E=3E=3E=3E If anything it should be turned off by default=2C and peopl= e can turn it =3E=3E=3E=3E=3E on if they want given the landmine it plants=2E If they kn= ow how to =3E=3E=3E=3E=3E turn it on they=27re much more likely to be aware of the is= sue=2E =3E=3E=3E=3E=3E =3E=3E=3E=3E=3E =3E=3E=3E=3E=3E =3E=3E To sum it up =3E=3E SU+J should be turned off by default because of =3E=3E 1=2E It does not work with dumping a live system e=2Eg=2E snapshot= =3E=3E 2=2E it is not recommended for SSD installs =3E=3E 3=2E =22Smart=22 admins can turn it on if they want =3E=3E =3E=3E root=40sys=3A/usr/src/usr=2Esbin/bsdinstall/partedit =23 diff -u gpa= rt=5Fops=2Ec =3E=3E gpart=5Fops=2Ecnew =3E=3E --- gpart=5Fops=2Ec 2012-08-06 01=3A54=3A33=2E000000000 +0200 =3E=3E +++ gpart=5Fops=2Ecnew 2012-11-02 19=3A07=3A45=2E000000000 +0100= =3E=3E =40=40 -90=2C8 +90=2C8 =40=40 =3E=3E =7B=22SU=22=2C =22Softupdates=22=2C =3E=3E =22Enable softupdates =28default=29=22=2C 1 =7D= =2C =3E=3E =7B=22SUJ=22=2C =22Softupdates journaling=22=2C =3E=3E - =22Enable file system journaling =28default - =22= =3E=3E - =22turn off for SSDs=29=22=2C 1 =7D=2C =3E=3E + =22Disable file system journaling =28default - =22= =3E=3E + =22turn on for adventurish admins=29=22=2C 0 =7D=2C= =3E=3E =7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =3E=3E =22Enable TRIM support=2C useful on solid-state d= rives=22=2C =3E=3E 0 =7D=2C =3E=3E =3E=3E Please comment=2C then I can file a PR or not =3E As was noted in my another mail=2C the kernel will no longer crash when= an =3E attempt to take a snapshot is made=2E Also AFAIR SUJ can be disabled =3E later=2E =3E =3E Given that I prefer the following=3A =3E =3E diff --git a/usr=2Esbin/bsdinstall/partedit/gpart=5Fops=2Ec b/usr=2Esbi= n/bsdinstall/partedit/gpart=5Fops=2Ec =3E index 479365a=2E=2E80296c2 100644 =3E --- a/usr=2Esbin/bsdinstall/partedit/gpart=5Fops=2Ec =3E +++ b/usr=2Esbin/bsdinstall/partedit/gpart=5Fops=2Ec =3E =40=40 -91=2C7 +91=2C7 =40=40 newfs=5Fcommand=28const char *fstype=2C c= har *command=2C int use=5Fdefault=29 =3E =09=09=09 =22Enable softupdates =28default=29=22=2C 1 =7D=2C =3E =09=09=09=7B=22SUJ=22=2C =22Softupdates journaling=22=2C =3E =09=09=09 =22Enable file system journaling =28default - =22 =3E -=09=09=09 =22turn off for SSDs=29=22=2C 1 =7D=2C =3E +=09=09=09 =22turn off for SSDs or if you use snapshots=29=22=2C 1= =7D=2C =3E =09=09=09=7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =3E =09=09=09 =22Enable TRIM support=2C useful on solid-state drives= =22=2C =3E =09=09=09 0 =7D=2C =3E =3E http=3A//people=2Efreebsd=2Eorg/=7Emjg/patches/suj-snapshot-comment=2Ed= iff =3E Hi Mateusz I can see some benefits of having journaled soft updates and I=20 understand your preference=2E Though the last 10 years I have not had the inconvenience of having to=20= deal with long fsck=27 s or bgfsck=27 s on servers or workstation installs= =2C=20 so I think this should not be default on new installs=2E Since there are more SSD installs nowadays=2C it might be a good option to= =20 turn soft updates journaling off by default=2E Can you explain the benefits of having journaled soft updates turned on=3F= There are also a lot of back-up service providers who use the snapshot=20= functionality to be able to host a lot of back-ups=2C though they might be= =20 using zfs for this now I would guess=2E Kind regards Bas This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 19:04:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 310C7BBB; Fri, 2 Nov 2012 19:04:59 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 711348FC12; Fri, 2 Nov 2012 19:04:57 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Fri, 2 Nov 2012 20:04:57 +0100 Message-ID: <50941958.7030108@ose.nl> Date: Fri, 02 Nov 2012 20:04:56 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Gary Palmer Subject: Re: [patch] Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <50940C20.3090409@ose.nl> <50940E40.3090709@ose.nl> <5094112C.2070102@ose.nl> <20121102184131.GB22755@dft-labs.eu> <20121102185929.GA24320@in-addr.com> In-Reply-To: <20121102185929.GA24320@in-addr.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:04:59 -0000 On 11/02/2012 07=3A59 PM=2C Gary Palmer wrote=3A =3E On Fri=2C Nov 02=2C 2012 at 07=3A41=3A31PM +0100=2C Mateusz Guzik wrote= =3A =3E=3E On Fri=2C Nov 02=2C 2012 at 07=3A30=3A04PM +0100=2C Bas Smeelen wrot= e=3A =3E=3E=3E On 11/02/2012 07=3A17 PM=2C Bas Smeelen wrote=3A =3E=3E=3E=3E On 11/02/2012 07=3A08 PM=2C Bas Smeelen wrote=3A =3E=3E=3E=3E=3E On 11/02/2012 06=3A27 PM=2C Adam Strohl wrote=3A =3E=3E=3E=3E=3E=3E On 11/3/2012 0=3A13=2C Mike Jakubik wrote=3A =3E=3E=3E=3E=3E=3E=3E You can disable SU+J after installing=2C though it wo= uld be nice if the =3E=3E=3E=3E=3E=3E=3E installer gave you a choice=2E =3E=3E=3E=3E=3E=3E This assumes that you know about this flaw=2C which most= people do not=2E =3E=3E=3E=3E=3E=3E =3E=3E=3E=3E=3E=3E I didn=27t until I discovered it by panic-ing a perfectl= y fine running =3E=3E=3E=3E=3E=3E server=2E Getting burned by a known bug like this shoul= dn=27t be =22SOP=22 =3E=3E=3E=3E=3E=3E for users of FreeBSD=2E =3E=3E=3E=3E=3E=3E =3E=3E=3E=3E=3E=3E If anything it should be turned off by default=2C and pe= ople can turn it =3E=3E=3E=3E=3E=3E on if they want given the landmine it plants=2E If they= know how to =3E=3E=3E=3E=3E=3E turn it on they=27re much more likely to be aware of the= issue=2E =3E=3E=3E=3E=3E=3E =3E=3E=3E=3E=3E=3E =3E=3E=3E=3E=3E=3E =3E=3E=3E To sum it up =3E=3E=3E SU+J should be turned off by default because of =3E=3E=3E 1=2E It does not work with dumping a live system e=2Eg=2E snapsho= t =3E=3E=3E 2=2E it is not recommended for SSD installs =3E=3E=3E 3=2E =22Smart=22 admins can turn it on if they want =3E=3E=3E =3E=3E=3E root=40sys=3A/usr/src/usr=2Esbin/bsdinstall/partedit =23 diff -u= gpart=5Fops=2Ec =3E=3E=3E gpart=5Fops=2Ecnew =3E=3E=3E --- gpart=5Fops=2Ec 2012-08-06 01=3A54=3A33=2E000000000 +0200= =3E=3E=3E +++ gpart=5Fops=2Ecnew 2012-11-02 19=3A07=3A45=2E000000000 +01= 00 =3E=3E=3E =40=40 -90=2C8 +90=2C8 =40=40 =3E=3E=3E =7B=22SU=22=2C =22Softupdates=22=2C =3E=3E=3E =22Enable softupdates =28default=29=22=2C 1=20= =7D=2C =3E=3E=3E =7B=22SUJ=22=2C =22Softupdates journaling=22=2C =3E=3E=3E - =22Enable file system journaling =28default -=20= =22 =3E=3E=3E - =22turn off for SSDs=29=22=2C 1 =7D=2C =3E=3E=3E + =22Disable file system journaling =28default -= =22 =3E=3E=3E + =22turn on for adventurish admins=29=22=2C 0=20= =7D=2C =3E=3E=3E =7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C= =3E=3E=3E =22Enable TRIM support=2C useful on solid-stat= e drives=22=2C =3E=3E=3E 0 =7D=2C =3E=3E=3E =3E=3E=3E Please comment=2C then I can file a PR or not =3E=3E As was noted in my another mail=2C the kernel will no longer crash w= hen an =3E=3E attempt to take a snapshot is made=2E Also AFAIR SUJ can be disabled= =3E=3E later=2E =3E=3E =3E=3E Given that I prefer the following=3A =3E=3E =3E=3E diff --git a/usr=2Esbin/bsdinstall/partedit/gpart=5Fops=2Ec b/usr=2E= sbin/bsdinstall/partedit/gpart=5Fops=2Ec =3E=3E index 479365a=2E=2E80296c2 100644 =3E=3E --- a/usr=2Esbin/bsdinstall/partedit/gpart=5Fops=2Ec =3E=3E +++ b/usr=2Esbin/bsdinstall/partedit/gpart=5Fops=2Ec =3E=3E =40=40 -91=2C7 +91=2C7 =40=40 newfs=5Fcommand=28const char *fstype= =2C char *command=2C int use=5Fdefault=29 =3E=3E =09=09=09 =22Enable softupdates =28default=29=22=2C 1 =7D=2C =3E=3E =09=09=09=7B=22SUJ=22=2C =22Softupdates journaling=22=2C =3E=3E =09=09=09 =22Enable file system journaling =28default - =22 =3E=3E -=09=09=09 =22turn off for SSDs=29=22=2C 1 =7D=2C =3E=3E +=09=09=09 =22turn off for SSDs or if you use snapshots=29=22=2C= 1 =7D=2C =3E=3E =09=09=09=7B=22TRIM=22=2C =22Enable SSD TRIM support=22=2C =3E=3E =09=09=09 =22Enable TRIM support=2C useful on solid-state drive= s=22=2C =3E=3E =09=09=09 0 =7D=2C =3E=3E =3E=3E http=3A//people=2Efreebsd=2Eorg/=7Emjg/patches/suj-snapshot-comment= =2Ediff =3E How many people realise that snapshots are needed for dump based backup= s =3E =28and other related features=29=3F =3E =3E Gary My guess=3F A lot=2E But most who realize would turn SU+J off on new installs=2E I just ran across this when doing a new install from 9=2E1-RC2 and not=20= paying attention e=2Eg=2E realizing that SU+J is turned on by default now= =2E I have seen coming this across the mail lists before though=2E This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 19:06:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91B9AD82 for ; Fri, 2 Nov 2012 19:06:45 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from smh05.opentransfer.com (smh05.opentransfer.com [98.130.1.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4C28C8FC0C for ; Fri, 2 Nov 2012 19:06:45 +0000 (UTC) Received: by smh05.opentransfer.com (Postfix, from userid 8) id EABB98EA84; Fri, 2 Nov 2012 14:22:58 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on smh05.opentransfer.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=RDNS_NONE autolearn=disabled version=3.2.5 Received: from webmail7.opentransfer.com (unknown [69.49.230.6]) by smh05.opentransfer.com (Postfix) with ESMTP id C466F8E9F7 for ; Fri, 2 Nov 2012 14:22:58 -0400 (EDT) Received: from webmail7.opentransfer.com (webmail7.opentransfer.com [127.0.0.1]) by webmail7.opentransfer.com (8.13.8/8.13.8) with ESMTP id qA2IMwQ5011957 for ; Fri, 2 Nov 2012 14:22:58 -0400 Received: (from nobody@localhost) by webmail7.opentransfer.com (8.13.8/8.13.8/Submit) id qA2IMwn0011956 for freebsd-stable@freebsd.org; Fri, 2 Nov 2012 20:22:58 +0200 X-Authentication-Warning: webmail7.opentransfer.com: nobody set sender to oleg@opentransfer.com using -f Received: from 92-49-196-2.dynamic.peoplenet.ua (92-49-196-2.dynamic.peoplenet.ua [92.49.196.2]) by webmail.opentransfer.com (Horde Framework) with HTTP; for ; Fri, 02 Nov 2012 20:22:58 +0200 X-Opentransfer-Authenticated: oleg@opentransfer.com Message-ID: <20121102202258.12004cox9k4zrq0w@webmail7.opentransfer.com> Date: Fri, 02 Nov 2012 20:22:58 +0200 From: "Oleg V. Nauman" To: freebsd-stable@freebsd.org Subject: WITH_LIBCPLUSPLUS buildworld broken on STABLE-9 MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Originating-IP: 92.49.196.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:06:45 -0000 ===> lib/libc++ (all) clang++ -O -pipe -march=i686 -mtune=i686 -I/usr/src/lib/libc++/../../contrib/libc++/include -I/usr/src/lib/libc++/../../contrib/libcxxrt -nostdlib -DLIBCXXRT -Qunused-arguments -fstack-protector -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp -o algorithm.o In file included from /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: In file included from /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:596: /usr/src/lib/libc++/../../contrib/libc++/include/cstdlib:134:9: error: no member named 'at_quick_exit' in the global namespace using ::at_quick_exit; ~~^ /usr/src/lib/libc++/../../contrib/libc++/include/cstdlib:135:9: error: no member named 'quick_exit' in the global namespace using ::quick_exit; ~~^ /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:14:1: warning: inline namespaces are a C++11 feature [-Wc++11-extensions] _LIBCPP_BEGIN_NAMESPACE_STD ^ /usr/src/lib/libc++/../../contrib/libc++/include/__config:264:52: note: expanded from macro '_LIBCPP_BEGIN_NAMESPACE_STD' #define _LIBCPP_BEGIN_NAMESPACE_STD namespace std {inline namespace _LIBCPP_NAMESPACE... ^ 1 warning and 2 errors generated. *** [algorithm.o] Error code 1 Stop in /usr/src/lib/libc++. *** [all] Error code 1 Stop in /usr/src/lib. *** [lib__L] Error code 1 Stop in /usr/src. *** [libraries] Error code 1 Stop in /usr/src. *** [_libraries] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 19:16:09 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F923415 for ; Fri, 2 Nov 2012 19:16:09 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1898FC15 for ; Fri, 2 Nov 2012 19:16:08 +0000 (UTC) Received: (qmail 86804 invoked by uid 89); 2 Nov 2012 19:16:06 -0000 Received: by simscan 1.4.0 ppid: 86799, pid: 86801, t: 0.1054s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15533 Received: from unknown (HELO linux-wb36.example.org) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 2 Nov 2012 19:16:06 -0000 Date: Fri, 2 Nov 2012 20:15:54 +0100 From: Rainer Duffner To: Mark Saad Subject: Re: FreeBSD 9.1 stability/robustness? Message-ID: <20121102201554.6048f2e0@linux-wb36.example.org> In-Reply-To: References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.7; i586-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:16:09 -0000 Am Fri, 2 Nov 2012 13:34:20 -0400 schrieb Mark Saad : > > > > On Nov 2, 2012, at 4:10 AM, Rainer Duffner > wrote: > > > Am Thu, 1 Nov 2012 20:14:51 -0600 (MDT) > > schrieb Brett Glass : > > > >> I need to build up a few servers and routers, and am wondering how > >> FreeBSD 9.1 is shaping up. Will it be likely to be more stable and > >> robust than 9.0-RELEASE? Are there issues that will have to wait > >> until 9.2-RELEASE to be fixed? Opinions welcome. > > > > > > If I'm not mistaken, the bge-stuff that makes the default NICs ins > > HP G8 servers (360+380) actually run will not make it back into 9.1. > > Intel cards work much better anyway... > > > Did you swap out the bge nic daughter card in the g8 servers for an > intel one or , do you mean in general the intel nic support is > better ? Both, actually. At least, Intel has drivers for FreeBSD on their website and IIRC, it's a Tier 1 OS for them. I don't want to dis the efforts of the people working on the bXe stuff, but from what I have read, they have much less support from the vendor. We have used HP servers even back when they were still Compaq-servers (and came with Intel NICs...) and this is really the first time we had to install Intel NICs with them (with FreeBSD - there was an earlier issue with Solaris, but that does not count...). Are there Intel daughter cards for this server? I thought, all the daugher-cards came with some sort of Broadcom chipset. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 19:57:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DF2126C; Fri, 2 Nov 2012 19:57:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AEC8E8FC0A; Fri, 2 Nov 2012 19:57:17 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id 16so2658099wgi.31 for ; Fri, 02 Nov 2012 12:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=rXn6HI7M772o12lyAGsWHXH0VdVb9DSsz4yNL7F4VtQ=; b=siUuvCo2KYHbP72/kztTPFtEHxVeEYogzxVEkrt0whQrxFDkjxATV11izb1gFbint6 GYvW9v4yzXxjyrAj91YVbH5hymSMLKLB2fwL+7AKopIlxxWtdMfghGMApJVFxBC3tjr8 njeGEISX0yPkCAoxKzotb/y+c9Si+f4CSg68AjGbTpGXjCr3//NbS20eAqBTxFF2hiPn AhYLwxC3vnfpKqZhXUfo/rdRK5EFExEb/FriLft7ovXZI7suX7fCJToZFR8WauNOM//e W67Fbrxd3/DniQJbkV/iEIvzKFb98FvMKWTxNfDgxip3IYcn8RIRzRBn2WinU1AFqEg2 CLMg== Received: by 10.216.211.19 with SMTP id v19mr1022500weo.91.1351886231501; Fri, 02 Nov 2012 12:57:11 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id en20sm3259532wid.4.2012.11.02.12.57.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 12:57:10 -0700 (PDT) Date: Fri, 2 Nov 2012 20:57:01 +0100 From: Mateusz Guzik To: Gary Palmer Subject: Re: [patch] Re: SU+J on 9.1-RC2 ISO Message-ID: <20121102195701.GA496@dft-labs.eu> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <50940C20.3090409@ose.nl> <50940E40.3090709@ose.nl> <5094112C.2070102@ose.nl> <20121102184131.GB22755@dft-labs.eu> <20121102185929.GA24320@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20121102185929.GA24320@in-addr.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Bas Smeelen , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:57:18 -0000 On Fri, Nov 02, 2012 at 02:59:29PM -0400, Gary Palmer wrote: > On Fri, Nov 02, 2012 at 07:41:31PM +0100, Mateusz Guzik wrote: > > On Fri, Nov 02, 2012 at 07:30:04PM +0100, Bas Smeelen wrote: > > > On 11/02/2012 07:17 PM, Bas Smeelen wrote: > > > > On 11/02/2012 07:08 PM, Bas Smeelen wrote: > > > >> On 11/02/2012 06:27 PM, Adam Strohl wrote: > > > >>> On 11/3/2012 0:13, Mike Jakubik wrote: > > > >>>> You can disable SU+J after installing, though it would be nice if the > > > >>>> installer gave you a choice. > > > >>> This assumes that you know about this flaw, which most people do not. > > > >>> > > > >>> I didn't until I discovered it by panic-ing a perfectly fine running > > > >>> server. Getting burned by a known bug like this shouldn't be "SOP" > > > >>> for users of FreeBSD. > > > >>> > > > >>> If anything it should be turned off by default, and people can turn it > > > >>> on if they want given the landmine it plants. If they know how to > > > >>> turn it on they're much more likely to be aware of the issue. > > > >>> > > > >>> > > > >>> > > > To sum it up > > > SU+J should be turned off by default because of > > > 1. It does not work with dumping a live system e.g. snapshot > > > 2. it is not recommended for SSD installs > > > 3. "Smart" admins can turn it on if they want > > > > > > root@sys:/usr/src/usr.sbin/bsdinstall/partedit # diff -u gpart_ops.c > > > gpart_ops.cnew > > > --- gpart_ops.c 2012-08-06 01:54:33.000000000 +0200 > > > +++ gpart_ops.cnew 2012-11-02 19:07:45.000000000 +0100 > > > @@ -90,8 +90,8 @@ > > > {"SU", "Softupdates", > > > "Enable softupdates (default)", 1 }, > > > {"SUJ", "Softupdates journaling", > > > - "Enable file system journaling (default - " > > > - "turn off for SSDs)", 1 }, > > > + "Disable file system journaling (default - " > > > + "turn on for adventurish admins)", 0 }, > > > {"TRIM", "Enable SSD TRIM support", > > > "Enable TRIM support, useful on solid-state drives", > > > 0 }, > > > > > > Please comment, then I can file a PR or not > > > > As was noted in my another mail, the kernel will no longer crash when an > > attempt to take a snapshot is made. Also AFAIR SUJ can be disabled > > later. > > > > Given that I prefer the following: > > > > diff --git a/usr.sbin/bsdinstall/partedit/gpart_ops.c b/usr.sbin/bsdinstall/partedit/gpart_ops.c > > index 479365a..80296c2 100644 > > --- a/usr.sbin/bsdinstall/partedit/gpart_ops.c > > +++ b/usr.sbin/bsdinstall/partedit/gpart_ops.c > > @@ -91,7 +91,7 @@ newfs_command(const char *fstype, char *command, int use_default) > > "Enable softupdates (default)", 1 }, > > {"SUJ", "Softupdates journaling", > > "Enable file system journaling (default - " > > - "turn off for SSDs)", 1 }, > > + "turn off for SSDs or if you use snapshots)", 1 }, > > {"TRIM", "Enable SSD TRIM support", > > "Enable TRIM support, useful on solid-state drives", > > 0 }, > > > > http://people.freebsd.org/~mjg/patches/suj-snapshot-comment.diff > > How many people realise that snapshots are needed for dump based backups > (and other related features)? > I thought this is a common knowledge. When you run dump without -L on a live filesystem, it advises you to re-run with -L option. And -L description in the man page clearly states that it uses snapshots. The comment can be updated to mention that snapshots are used by dump with -L. I don't have a strong opinion on this subject, just wanted to correct Adam on his claims regarding panics with snapshots and while here I provided a patch that is more likely to get accepted since it does not change any defaults (and I hoped it would address concerns about admins installing new systems with SUJ unaware that it does not work with snapshots). -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 20:23:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A7379F1; Fri, 2 Nov 2012 20:23:37 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id 0C4C18FC08; Fri, 2 Nov 2012 20:23:36 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id qA2KDIj2024804; Fri, 2 Nov 2012 20:13:18 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id qA2KDIn8024803; Fri, 2 Nov 2012 20:13:18 GMT (envelope-from wkoszek) Date: Fri, 2 Nov 2012 20:13:18 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: FreeBSD in Google Code-In 2012? You can help too! Message-ID: <20121102201318.GI59689@FreeBSD.org> References: <20121016101957.GB53800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20121016101957.GB53800@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Fri, 02 Nov 2012 20:13:18 +0000 (UTC) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 20:23:37 -0000 On Tue, Oct 16, 2012 at 10:19:57AM +0000, Wojciech A. Koszek wrote: > (cross-posted message; please keep discussion on freebsd-hackers@) > > Hello, > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > youngest open-source hackers in 13-17yr age range: > > http://www.google-melange.com/gci/homepage/google/gci2012 > > It was successful. We gained one more FreeBSD developer thanks to that > (Isabell Long) We're pondering participating in the contest this year as > well. > > For now we only have 25 ideas. We need at least 100. > > I felt all members of the FreeBSD community should help, so please submit > your own Google Code-In 2012 ideas here: > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > Examples of previously completed tasks: > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > Those of you who have Wiki access, please spent 2 more minutes and submit > straight to Wiki: > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > I plan to send out next e-mail if there's any progress on this project. > > Help will be appreciated. Hello, This is last call for action. As for now, we won't qualify. I suggest doc@ and ports@ and www@ and src@ teams to try to come up with some ideas and add them to Wiki. Most of the ideas which we have so far are more GSOC-alike. Unless we have at least 80 tasks of the "easy"/"medium" type, we'll have to postpone participating in Code-In for next year. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 21:52:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D86CA7F7 for ; Fri, 2 Nov 2012 21:52:13 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8CCCD8FC08 for ; Fri, 2 Nov 2012 21:52:13 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id qA2LgvsS051551; Fri, 2 Nov 2012 17:42:57 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Fri, 02 Nov 2012 17:42:57 -0400 (EDT) Date: Fri, 2 Nov 2012 17:42:57 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Adam Strohl Subject: Re: SU+J on 9.1-RC2 ISO In-Reply-To: <5093FD3D.3080201@ateamsystems.com> Message-ID: References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Bas Smeelen , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 21:52:13 -0000 On Sat, 3 Nov 2012, Adam Strohl wrote: > On 11/2/2012 23:47, Bas Smeelen wrote: >> Hi >> >> Why are journaled soft updates the default when installing a new system >> from a 9.1-RC2 ISO? >> >> I admit I did not pay too much attention when installing a new system >> from an 9.1-RC2 ISO and found out when taking a snapshot with dump (dump >> -0Lauf) to clone the system. Other systems (9-STABLE, 9.1-RC2 and >> 9.1-RC3) have been upgraded from 8.X-RELEASE and earlier, so there are >> no journaled soft updates enabled, just soft updates, and well there >> dump with snapshot works just fine. >> >> Can SU+J be disabled for the 9.1-RELEASE or do you think this is not >> going to be a problem for users of FreeBSD? I will have to boot these >> two systems single user now to disable the soft updates journal, because >> I use dump + restore on live systems, not a problem for me, it is just >> an inconvenience. > > > I have to second this sentiment. Unless the dump/snapshot issue has been > resolved they journal should be turned off by default. +1 -- DE From owner-freebsd-stable@FreeBSD.ORG Fri Nov 2 22:13:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1E51F9A; Fri, 2 Nov 2012 22:13:49 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD058FC14; Fri, 2 Nov 2012 22:13:48 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Fri, 2 Nov 2012 23:13:44 +0100 Message-ID: <50944597.9090709@ose.nl> Date: Fri, 02 Nov 2012 23:13:43 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: SU+J on 9.1-RC2 ISO References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Adam Strohl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 22:13:49 -0000 On 11/02/2012 10=3A42 PM=2C Daniel Eischen wrote=3A =3E On Sat=2C 3 Nov 2012=2C Adam Strohl wrote=3A =3E =3E=3E On 11/2/2012 23=3A47=2C Bas Smeelen wrote=3A =3E=3E=3E Hi =3E=3E=3E =3E=3E=3E Why are journaled soft updates the default when installing a new= system =3E=3E=3E from a 9=2E1-RC2 ISO=3F =3E=3E=3E =3E=3E=3E I admit I did not pay too much attention when installing a new sy= stem =3E=3E=3E from an 9=2E1-RC2 ISO and found out when taking a snapshot with d= ump=20 =3E=3E=3E =28dump =3E=3E=3E -0Lauf=29 to clone the system=2E Other systems =289-STABLE=2C 9= =2E1-RC2 and =3E=3E=3E 9=2E1-RC3=29 have been upgraded from 8=2EX-RELEASE and earlier=2C= so there are =3E=3E=3E no journaled soft updates enabled=2C just soft updates=2C and wel= l there =3E=3E=3E dump with snapshot works just fine=2E =3E=3E=3E =3E=3E=3E Can SU+J be disabled for the 9=2E1-RELEASE or do you think this i= s not =3E=3E=3E going to be a problem for users of FreeBSD=3F I will have to boot= these =3E=3E=3E two systems single user now to disable the soft updates journal= =2C=20 =3E=3E=3E because =3E=3E=3E I use dump + restore on live systems=2C not a problem for me=2C i= t is just =3E=3E=3E an inconvenience=2E =3E=3E =3E=3E =3E=3E I have to second this sentiment=2E Unless the dump/snapshot issue h= as=20 =3E=3E been resolved they journal should be turned off by default=2E =3E =3E +1 =3E I have submitted a PR with patch=2C see how it goes Cheers This e-mail message=2C including any attachment=28s=29=2C is intended solel= y for the addressee or addressees=2E Any views or opinions presented herein= are solely those of the author and do not necessarily represent those of O= SE=2E If you are not the intended recipient of this communication please return t= his e-mail message and the attachment=28s=29 to the sender and delete and d= estroy all copies=2E From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 05:49:03 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 479C77AA for ; Sat, 3 Nov 2012 05:49:03 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC1A8FC08 for ; Sat, 3 Nov 2012 05:49:02 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEJAF2ulFDLevdH/2dsb2JhbABEv2SCQgOCD4IeAQEFOEEQCw4KCRMDDwkDAgECAUUGDQEHAQGIBbwKjAEbDEmFTAOmP4MCgUoe Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail05.adl6.internode.on.net with ESMTP; 03 Nov 2012 16:19:00 +1030 Message-ID: <5094AE70.1030403@ShaneWare.Biz> Date: Sat, 03 Nov 2012 16:11:04 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Doug Hardie Subject: Re: FreeBSD 9.1 stability/robustness? References: <201211020214.UAA29489@lariat.net> <040B042A-EDD1-4639-BD21-CCB97A410C21@lafn.org> In-Reply-To: <040B042A-EDD1-4639-BD21-CCB97A410C21@lafn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 05:49:03 -0000 On 02/11/2012 15:57, Doug Hardie wrote: > > On 1 November 2012, at 19:14, Brett Glass wrote: > >> I need to build up a few servers and routers, and am wondering how >> FreeBSD 9.1 is shaping up. Will it be likely to be more stable and >> robust than 9.0-RELEASE? > > It appears to be for me. I had problems with 9.0 not reading CDs and > rebooting with no error messages frequently. I have upgraded to > 9.1-RC2 and it now reads CDs just fine, and has not rebooted. > However, the uptimes with 9.0 ranged from about 2 hours to 30 days. > I have only had 9.1-RC2 running for a couple weeks so have not > declared victory yet. I has been running for more than most of the > uptimes already. > Personally I have had little issue with 9.0. I started with installing PC-BSD-9.0RC3 then moved to FreeBSD 9.0-RELEASE Shortly after I installed a world built with clang which found an issue with libthr that is fixed in 9.1 Until yesterday my only restarts have been power failure or updating kernel and/or kmods - I seem to have trouble manually unloading the nvidia kmod so end up restarting. I am fairly certain the restart I had yesterday is related to cuse4bsd-kmod which I have disabled for now to try and prove that. While I can load and use the current version the previous one is the only one I have been able to have activated during startup. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 12:51:14 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28ECCA5A; Sat, 3 Nov 2012 12:51:14 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7C2578FC0A; Sat, 3 Nov 2012 12:51:12 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id qA3CqY4n029869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Nov 2012 13:52:37 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5095132D.8000007@omnilan.de> Date: Sat, 03 Nov 2012 13:50:53 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: lock violation in unionfs (9.0-STABLE r230270) References: <5022840B.3060708@omnilan.de> <5048C6D1.8020007@omnilan.de> <508EDB2F.3010608@omnilan.de> <50910751.9030303@omnilan.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB4935B67372D64C0CC73A8A4" Cc: stable@FreeBSD.org, daichi@FreeBSD.org, Pavel Polyakov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 12:51:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB4935B67372D64C0CC73A8A4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb Attilio Rao am 02.11.2012 15:21 (localtime): > On Wed, Oct 31, 2012 at 11:11 AM, Harald Schmalzbauer > wrote: >> schrieb Attilio Rao am 29.10.2012 23:02 (localtime): >>> On Mon, Oct 29, 2012 at 7:37 PM, Harald Schmalzbauer >>> wrote: >>>> schrieb Attilio Rao am 27.10.2012 23:07 (localtime): >>>>> On Sat, Oct 27, 2012 at 9:46 PM, Attilio Rao = wrote: >>>>>> On Sat, Sep 8, 2012 at 12:48 AM, Attilio Rao = wrote: >>>>>>> On Thu, Sep 6, 2012 at 4:52 PM, Harald Schmalzbauer >>>>>>> wrote: >>>>>>>> schrieb Attilio Rao am 09.08.2012 20:26 (localtime): >>>>>>>>> On 8/8/12, Harald Schmalzbauer wrot= e: >>>>>>>>>> schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime): >>>>>>>>>>>>> mount -t unionfs -o noatime /usr /mnt >>>>>>>>>>>>> >>>>>>>>>>>>> insmntque: mp-safe fs and non-locked vp: 0xfffffe01d96704f0= is not >>>>>>>>>>>>> exclusive locked but should be >>>>>>>>>>>>> KDB: enter: lock violation >>>>>>>>>>>> Pavel, >>>>>>>>>>>> can you give a spin to this patch?: >>>>>>>>>>>> http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lo= ck.patch >>>>>>>>>>>> >>>>>>>>>>>> I think that the unlocking is due at that point as the vnode= lock can >>>>>>>>>>>> be switch later on. >>>>>>>>>>>> >>>>>>>>>>>> Let me know what you think about it and what the test does. >>>>>>>>>>> Thanks! >>>>>>>>>>> This patch fixes the problem with lock violation. Sorry I've = tested it so >>>>>>>>>>> late. >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> this patch still applies cleanly to RELENG_9_1. Was there anot= her fix >>>>>>>>>> for the issue or has it just not been PR-sent and thus forgott= en? >>>>>>>>> Can you and Pavel try the attached patch? Unfortunately I had n= o time >>>>>>>>> to test it, I just made in 5 free mins from a non-FreeBSD works= tation, >>>>>>>> Sorry, couldn't test earlier, but now I did: >>>>>>>> With this patch applied the machine hangs without debug kernel a= nd the >>>>>>>> latter gives the following panic: >>>>>>>> System call nmount returning with the following locks held: >>>>>>>> exclusive lockmgr ufs (ufs) r =3D 0 (0xc5438278) locked @ >>>>>>>> src/sys/fs/unionfs/union_vnops.c:1938 >>>>>>>> panic: witness_warn >>>>>>>> cpuid =3D 0 >>>>>>>> KDB: stack backtrace: >>>>>>>> db_trace_self_wrapper(c0a04f7f,c0c112c4,d1de3bb4,c097aa8c,fc,...= ) at >>>>>>>> db_trace_self_wrapper+0x26 >>>>>>>> kdb_backtrace(c0a4965f,0,c09c2ede3c1c,0,...) at kdb_backtrace+0x= 2a >>>>>>>> witness_warn(2,0,c0a4ac34,c0a0990a,286,...) at witness_warn+0x1e= 4 >>>>>>>> syscall(d1de3d08) ar syscall+0x415 >>>>>>>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>>>>>>> --- syscall (0, FreeBSD ELF32, nosys), eip =3D 0x280b883f,esp =3D= >>>>>>>> 0xbfbfe46c, ebp =3D 0xbfbfede8 --- >>>>>>>> KDB: enter: panic >>>>>>>> [ thread pid 86 tid 100054 ] >>>>>>>> Stopped ad kdb_enter+0x3a: movl $0,kdb_why >>>>>>>> db> bt >>>>>>>> Tracing pid 86 tid 100054 td 0xc541b000 >>>>>>>> kdb_enter(c0a00d16,c0a09130,0,0,0,...) at panix+0x190 >>>>>>>> witness_warn(2,0,x0a4ac34,c0a0990a,286,...) at witness_warn+0x1e= 4 >>>>>>>> syscall(d1de3d08) at syscall+0x415 >>>>>>>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>>>>>>> >>>>>>>> Hmm, I guess I forgot to install kernel debug symbols... >>>>>>>> Coming back if I have more >>>>>>> Unfortunately unionfs does very wrong things with the insmntque()= locking. >>>>>>> It basically expects the vnode to return locked in the same way >>>>>>> requested by the precedent namei() (when that happens) but when y= ou do >>>>>>> insmntque() you can only have an LK_EXCLUSIVE lock on the vnode. >>>>>> Hello, >>>>>> the following patch should workout the issues around unionfs_nodeg= et() a bit: >>>>>> http://www.freebsd.org/~attilio/unionfs_nodeget2.patch >>>>>> >>>>>> Unfortunately unionfs code is rather messy in the lookup path abou= t >>>>>> locking requirements so follow what it needs to be done there is a= bit >>>>>> difficult. >>>>>> I have no way to test this patch, so it is just test-compiled at t= he >>>>>> moment, but I would need that you also test lookup path (so direct= ory >>>>>> "ls", find(1) on the whole unionfs volume, etc.) to validate it >>>>>> someway. >>>>> On a second thought, I think that locking in lookup (and also other= >>>>> operations) is so fragile and difficult to follow that it makes all= >>>>> vnops real locking landmines. >>>>> I think that the following patch fixes the insmntque insertion and >>>>> follows the old approach well enough to be committed separately: >>>>> http://www.freebsd.org/~attilio/unionfs_nodeget3.patch >>>>> >>>> Unfortunately I have no idea about all those locking strategies and >>>> implementations. >>>> Applying unionfs_nodeget3.patch results in: >>>> sys/fs/unionfs/union_subr.c: In function 'unionfs_nodeget': >>>> sys/fs/unionfs/union_subr.c:332: error: expected statement >>>> before ')' token >>>> *** [union_subr.o] Error code 1 >>>> >>>> I guess there is a typo in this chunk: >>>> @@ -317,11 +328,11 @@ unionfs_nodeget(struct mount *mp, struct vnode= *up >>>> >>>> vref(vp); >>>> } else >>>> *vpp =3D vp; >>>> - >>>> -unionfs_nodeget_out: >>>> - if (lkflags & LK_TYPE_MASK) >>>> - vn_lock(vp, lkflags | LK_RETRY); >>>> - >>>> + if (lkflags & LK_TYPE_MASK) { >>>> + if (lkflags =3D=3D LK_SHARED)) >>>> ---------------------------------------- ^ >>>> + vn_lock(vp, LK_DOWNGRADE | LK_RETRY); >>>> + } else >>>> + VOP_UNLOCK(vp, LK_RELEASE); >>>> return (0); >>>> } >>>> >>>> After removing the second right parenthesis kernel compiles. >>>> But it still crashes: >>>> panic: Lock (lockmgr) ufs not locked @ sys/kern/vfs_default.c:512 >>>> cpuid =3D 1 >>>> KDB: stack backtrace: >>>> ... >>>> If you can use the bt info I'll transcribe - no serial console avail= able :-( >>>> >>>> Am I right that I should only apply _one_ unionfs-patchX.patch >>>> (unionfs_nodeget3.patch in that case)? >>> Yes, only that one. >>> Can you please do "bt" from DDB and take a picture of you screen with= a camera? >> Ok, now I had a reason to take some time finding out how ESXi handles >> serial ports ;-) It's quiet easy and very flexible, so no problem >> setting up a debug console. >> Please find attached the backtrace. >> Do I have to load any symbols? It's not very informative what I see, r= ight? > Hi Harry, > well done. > > Can you please backout the prior patch and try this one instead?: > http://www.freebsd.org/~attilio/unionfs_nodeget4.patch Unfortunately still panic, but only with debug kernel. Accidentally I first built a non-debug kernel and did some tests -> no crash with regular usage. I also took a completely unrelated PR to run the example "killer-app" on an upper_union mounted directory and ran the test for some minutes - no crash: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D159971 Since I also saw no LOR I checkd if I really have a debug-kernel... Now with debug kernel I get this panic at boot (where /.safe/etc gets mounted over /etc): panic: Lock (lockmgr) ufs not locked @ /usr/local/share/deploy-tools/RELENG_9_1/src/sys/kern/vfs_default.c:512. cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1cd witness_assert() at witness_assert+0x225 __lockmgr_args() at __lockmgr_args+0xb65 vop_stdunlock() at vop_stdunlock+0x43 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x9b unionfs_unlock() at unionfs_unlock+0xe1 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x9b unionfs_nodeget() at unionfs_nodeget+0x615 unionfs_domount() at unionfs_domount+0x4ab vfs_donmount() at vfs_donmount+0x960 sys_nmount() at sys_nmount+0x66 amd64_syscall() at amd64_syscall+0x2fa Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x80087798c, rsp =3D= 0x7fffffffd328, rbp =3D 0x7fffffffd750 --- KDB: enter: panic [ thread pid 72 tid 100083 ] Stopped at kdb_enter+0x3b: movq $0,0x64cd42(%rip) db> bt Tracing pid 72 tid 100083 td 0xfffffe00074c78e0 kdb_enter() at kdb_enter+0x3b panic() at panic+0x1c6 witness_assert() at witness_assert+0x225 __lockmgr_args() at __lockmgr_args+0xb65 vop_stdunlock() at vop_stdunlock+0x43 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x9b unionfs_unlock() at unionfs_unlock+0xe1 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x9b unionfs_nodeget() at unionfs_nodeget+0x615 unionfs_domount() at unionfs_domount+0x4ab vfs_donmount() at vfs_donmount+0x960 sys_nmount() at sys_nmount+0x66 amd64_syscall() at amd64_syscall+0x2fa Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x80087798c, rsp =3D= 0x7fffffffd328, rbp =3D 0x7fffffffd750 --- Thanks for your help, -Harry --------------enigB4935B67372D64C0CC73A8A4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCVEzYACgkQLDqVQ9VXb8hXWACgmXVSDxPkm771yitjPs5ZdhtV pjMAoLKo3kQ/U9Dc7oAYYXAFkdcDB9UF =B2dc -----END PGP SIGNATURE----- --------------enigB4935B67372D64C0CC73A8A4-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 13:54:35 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EA61B83 for ; Sat, 3 Nov 2012 13:54:35 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id E25428FC0A for ; Sat, 3 Nov 2012 13:54:33 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id qA3DsT64012403 for ; Sat, 3 Nov 2012 20:54:30 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <50952210.7060000@grosbein.net> Date: Sat, 03 Nov 2012 20:54:24 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: FreeBSD Stable Subject: freebsd-update and surces of 9.1-RC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 13:54:35 -0000 Hi! I'm trying to use freebsd-update for first time. I have 9.0-RELEASE installed without sources and I have read Handbook chapter and manual page for freebsd-update. "freebsd-update -r 9.1-RC3 upgrade" downloaded updates, its "install" command installed kernel and after reboot second "install" invocation installed binaries but not source tree that is needed to add IPSEC support to the kernel. Now it says: # freebsd-update -r 9.1-RC3 upgrade freebsd-update: Cannot upgrade from 9.1-RC3 to itself How do I make freebsd-update to download and install sources for 9.1-RC3 so I could rebuild custom kernel? Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 14:08:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5689DDA for ; Sat, 3 Nov 2012 14:08:05 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (feld.me [66.170.3.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9DD8FC12 for ; Sat, 3 Nov 2012 14:08:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-Id:Subject:Cc:To:From:Date; bh=CSvm3ywj2SLuObWtCn12jUyrIART5Gl0++rH6zNPowI=; b=BSO1oWOz6QhMRZv0DWqv1QA0uweLRe+TemskZwbrGsNDEQpTt2ve96FVaV32bJJ6VbICIxCfndpIqzgvXF46JSEUdS9U1NANPxmzm7nfawWibaGwnBaBq+9lfX75QaJw; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TUeOA-000Gps-5m; Sat, 03 Nov 2012 09:07:55 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1351951668-65253-65252/5/14; Sat, 3 Nov 2012 14:07:48 +0000 Date: Sat, 3 Nov 2012 09:08:30 -0500 From: Mark Felder To: Bas Smeelen Subject: Re: [patch] Re: SU+J on 9.1-RC2 ISO Message-Id: <20121103090830.0000009d@unknown> In-Reply-To: <5094184B.6070100@ose.nl> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <50940C20.3090409@ose.nl> <50940E40.3090709@ose.nl> <5094112C.2070102@ose.nl> <20121102184131.GB22755@dft-labs.eu> <5094184B.6070100@ose.nl> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-SA-Report: ALL_TRUSTED=-1, KHOP_THREADED=-0.5 X-SA-Score: -1.5 Cc: Mateusz Guzik , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 14:08:05 -0000 On Fri, 2 Nov 2012 20:00:27 +0100 Bas Smeelen wrote: > Though the last 10 years I have not had the inconvenience of having to=20 > deal with long fsck' s or bgfsck' s on servers or workstation installs,= =20 > so I think this should not be default on new installs. This is one man's opinion. On the other hand, SUJ by default is a = godsend for me because of the number of crashes/fscks I've been dealing = with. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 14:10:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B83CEF9; Sat, 3 Nov 2012 14:10:16 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (feld.me [66.170.3.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4690C8FC14; Sat, 3 Nov 2012 14:10:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-Id:Subject:Cc:To:From:Date; bh=AhM2tBOHoMnq6deyQdBUrbusqa1St1q+5+I9WzCweLw=; b=q41k35VcziY9O3qMazkIKnGGXOqCjuOMzlnnuAaTJkLl5NUDPFEfvWtcwZ/McJZ1k6JQtaA/Zf3u6zeGtBO04Gyw1JPMWuNnFJgkmLs147MKq614d8APnCrKNDhys4JV; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TUeQQ-000Gps-2B; Sat, 03 Nov 2012 09:10:14 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1351951813-65253-65252/5/15; Sat, 3 Nov 2012 14:10:13 +0000 Date: Sat, 3 Nov 2012 09:10:56 -0500 From: Mark Felder To: Bas Smeelen Subject: Re: SU+J on 9.1-RC2 ISO Message-Id: <20121103091056.00004eb9@unknown> In-Reply-To: <50944597.9090709@ose.nl> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <50944597.9090709@ose.nl> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-SA-Report: ALL_TRUSTED=-1, KHOP_THREADED=-0.5 X-SA-Score: -1.5 Cc: Daniel Eischen , freebsd-stable@freebsd.org, Adam Strohl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 14:10:16 -0000 On Fri, 2 Nov 2012 23:13:43 +0100 Bas Smeelen wrote: > I have submitted a PR with patch, see how it goes > Cheers Why aren't we patching the dump utility to error/exit saying it's not = compatible with SUJ at this time? Update the descriptions in the = installer, but leave SUJ as default and patch dump. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 14:19:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 453B22B9 for ; Sat, 3 Nov 2012 14:19:27 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C0B3B8FC08 for ; Sat, 3 Nov 2012 14:19:26 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x43so2477017wey.13 for ; Sat, 03 Nov 2012 07:19:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=sNamz2aKFiCJeK7AWhA54R3kO3DTN4ZN/0WXtdKks40=; b=E9DXzE0Xi4Mdnf3+XqdJXyRescsspItBTbVWwJ7uMQfllZa2S0Dic03mlEMHMwNFGd 2BgQpFf3O7CfsBZSBSBeCdWOZ+QfU4InYqMAYL4XK3kmvUA4Wfmbo5XkwG1SgQaw0Ljb O9874bmGjPa1eVZeLVjRxVosO54EJbotJEGvhRUwdDd+6ota4bjUouc4kL76QPIUcOWz oteShw5AcV5sm5s35GOxBJ8Kir+6Ykmi/j2iasvfpS7kAmR90ZQdeKk0CwU/PrgSBA0p l4vHsiCZ5oqr4gEmG1iWp3H93dwx3KvQYg9EWreILdGy4kIPmB9lGOK1bNvl+/aA3woW hdrQ== Received: by 10.180.19.197 with SMTP id h5mr6480518wie.22.1351952365582; Sat, 03 Nov 2012 07:19:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.164.43 with HTTP; Sat, 3 Nov 2012 07:18:55 -0700 (PDT) In-Reply-To: <20121103091056.00004eb9@unknown> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <50944597.9090709@ose.nl> <20121103091056.00004eb9@unknown> From: Maxim Khitrov Date: Sat, 3 Nov 2012 10:18:55 -0400 Message-ID: Subject: Re: SU+J on 9.1-RC2 ISO To: Mark Felder Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkXV28g+bpoeeme+MRyJxrdxAGGNhr0opX9IiB3xOwCysCCiusuvEC3cW4luL5QY+mP+uin Cc: Bas Smeelen , Daniel Eischen , freebsd-stable@freebsd.org, Adam Strohl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 14:19:27 -0000 On Sat, Nov 3, 2012 at 10:10 AM, Mark Felder wrote: > On Fri, 2 Nov 2012 23:13:43 +0100 > Bas Smeelen wrote: > >> I have submitted a PR with patch, see how it goes >> Cheers > > Why aren't we patching the dump utility to error/exit saying it's not compatible with SUJ at this time? Update the descriptions in the installer, but leave SUJ as default and patch dump. If I understood Mateusz correctly, r230725 already took care of the panic, so there is no need to modify dump. That, however, still doesn't solve all problems: http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html - Max From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 14:25:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B1844D4 for ; Sat, 3 Nov 2012 14:25:06 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 128D68FC12 for ; Sat, 3 Nov 2012 14:24:46 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qA3EOeiT030232 for ; Sat, 3 Nov 2012 08:24:40 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qA3EOa7W009937; Sat, 3 Nov 2012 08:24:37 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [patch] Re: SU+J on 9.1-RC2 ISO From: Ian Lepore To: Mark Felder In-Reply-To: <20121103090830.0000009d@unknown> References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <1351876381.2657.1.camel@mjakubik.localdomain> <50940276.5030306@ateamsystems.com> <50940C20.3090409@ose.nl> <50940E40.3090709@ose.nl> <5094112C.2070102@ose.nl> <20121102184131.GB22755@dft-labs.eu> <5094184B.6070100@ose.nl> <20121103090830.0000009d@unknown> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Nov 2012 08:24:36 -0600 Message-ID: <1351952676.1120.33.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Bas Smeelen , Mateusz Guzik , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 14:25:06 -0000 On Sat, 2012-11-03 at 09:08 -0500, Mark Felder wrote: > On Fri, 2 Nov 2012 20:00:27 +0100 > Bas Smeelen wrote: > > > Though the last 10 years I have not had the inconvenience of having to > > deal with long fsck' s or bgfsck' s on servers or workstation installs, > > so I think this should not be default on new installs. > > This is one man's opinion. On the other hand, SUJ by default is a godsend for me because of the number of crashes/fscks I've been dealing with. So SUJ has been a godsend for you. I don't see anything in your statement that supports it being the default. Given how much trouble it has been for people in the past, I don't plan to embrace journaling any faster than I embraced softupdates originally. That is to say, it will be years before I use it. I suspect my attitude on this isn't all that uncommon, and is likely the explanation for why things increasingly become the default before their time these days. Developers are motivated to push new features into wide use quickly, because that gets the new features lots of testing. Prudent users aren't interested in being guinea pigs, and will push back. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 14:32:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69239720; Sat, 3 Nov 2012 14:32:05 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (feld.me [66.170.3.2]) by mx1.freebsd.org (Postfix) with ESMTP id 313528FC12; Sat, 3 Nov 2012 14:32:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-Id:Subject:Cc:To:From:Date; bh=ldltuWoiLg1l2xrGki7MANVv2On3D/OEJ7RiV3t6oSw=; b=ra/iBwF1GonS6dvbFS2UWDp0uGrjnIhi0zRj7GDtW0AAzz37J+4/sLsGamkDDY+ErMUiqzsOnvaiXIBKmur4PhqdU2HTTVG4a7UhvV2EXZaxihbkVvtYzk7GLz47uqkS; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TUelW-000Hbp-0S; Sat, 03 Nov 2012 09:32:03 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1351953116-65253-65252/5/17; Sat, 3 Nov 2012 14:31:56 +0000 Date: Sat, 3 Nov 2012 09:32:39 -0500 From: Mark Felder To: Maxim Khitrov Subject: Re: SU+J on 9.1-RC2 ISO Message-Id: <20121103093239.00005c0c@unknown> In-Reply-To: References: <5093F934.7050306@ose.nl> <5093FD3D.3080201@ateamsystems.com> <50944597.9090709@ose.nl> <20121103091056.00004eb9@unknown> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-SA-Report: ALL_TRUSTED=-1, KHOP_THREADED=-0.5 X-SA-Score: -1.5 Cc: Bas Smeelen , Daniel Eischen , freebsd-stable@freebsd.org, Adam Strohl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 14:32:05 -0000 On Sat, 3 Nov 2012 10:18:55 -0400 Maxim Khitrov wrote: > If I understood Mateusz correctly, r230725 already took care of the > panic, so there is no need to modify dump. That, however, still > doesn't solve all problems: >=20 > http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/2460= 69.html Interesting... well, a big warning in the installer should be sufficient = I'd hope From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 15:06:32 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3954EF03 for ; Sat, 3 Nov 2012 15:06:32 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C0EA98FC0A for ; Sat, 3 Nov 2012 15:06:31 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so6126395vcb.13 for ; Sat, 03 Nov 2012 08:06:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version :x-gm-message-state; bh=3rTqInNd18ENGDPuJFEfok7w2YtE3NmwBnMNG0uw+jk=; b=mb2gH0GGn9ZNJg685jqHFOY1bZviXKz27JNIOndJIZpSjcy0p5Wvb1QfDV3s6kOUhX H6+EirwEMsD7Gth2LbmdEKbCP1R3T4WuNo8+Q2UecHwJ+UjiBNnKmZoVzgZ26WVxJrSh WcrM1+38VcNp6CXNAV0rW1de5AR49mKHszwrCZQIxVjIv3YyLk/0iMMe1KawfO8DLnty 7A/lRSUs9OgPnUoRcikKfw9DfI+EcD1qCPyTZY6EyFy89nIXKysRVeh80zPWsKFaI6U7 Q/ZTNYqYGyw6NAFlLnka3ZBavpu6bw0tWRqjfMFO7lvpJR/eJVNRo9XxUPH8aHEwsjxV oNRA== Received: by 10.52.100.229 with SMTP id fb5mr4076737vdb.103.1351955189691; Sat, 03 Nov 2012 08:06:29 -0700 (PDT) Received: from [192.168.11.202] (ool-182c8567.dyn.optonline.net. [24.44.133.103]) by mx.google.com with ESMTPS id xf2sm6313615vec.12.2012.11.03.08.06.28 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 08:06:29 -0700 (PDT) Subject: Re: FreeBSD 9.1 stability/robustness? References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> <20121102201554.6048f2e0@linux-wb36.example.org> From: Mark Saad Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) In-Reply-To: <20121102201554.6048f2e0@linux-wb36.example.org> Message-Id: <97EBC854-07A3-40E2-A397-FB71A7FCA64E@longcount.org> Date: Sat, 3 Nov 2012 11:06:26 -0400 To: "stable@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQkp2WtExsAY1TnpkvpsFZx4ii8s7tCfR/PmLZp8g1Uh+rmTtEhBfFa5hSKXuSSf7EH0GMQg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:06:32 -0000 On Nov 2, 2012, at 3:15 PM, Rainer Duffner wrote: > Am Fri, 2 Nov 2012 13:34:20 -0400 > schrieb Mark Saad : >=20 >>=20 >>=20 >>=20 >> On Nov 2, 2012, at 4:10 AM, Rainer Duffner >> wrote: >>=20 >>> Am Thu, 1 Nov 2012 20:14:51 -0600 (MDT) >>> schrieb Brett Glass : >>>=20 >>>> I need to build up a few servers and routers, and am wondering how >>>> FreeBSD 9.1 is shaping up. Will it be likely to be more stable and >>>> robust than 9.0-RELEASE? Are there issues that will have to wait >>>> until 9.2-RELEASE to be fixed? Opinions welcome. >>>=20 >>>=20 >>> If I'm not mistaken, the bge-stuff that makes the default NICs ins >>> HP G8 servers (360+380) actually run will not make it back into 9.1. >>> Intel cards work much better anyway... >>>=20 >> Did you swap out the bge nic daughter card in the g8 servers for an >> intel one or , do you mean in general the intel nic support is >> better ?=20 >=20 > Both, actually. > At least, Intel has drivers for FreeBSD on their website and IIRC, it's > a Tier 1 OS for them. > I don't want to dis the efforts of the people working on the bXe stuff, > but from what I have read, they have much less support from the vendor. > We have used HP servers even back when they were still Compaq-servers > (and came with Intel NICs...) and this is really the first time we had > to install Intel NICs with them (with FreeBSD - there was an earlier > issue with Solaris, but that does not count...). >=20 > Are there Intel daughter cards for this server? > I thought, all the daugher-cards came with some sort of Broadcom > chipset. Hp did a presentation at work 2 weeks ago about the g8 . Hp said you can swa= p out a daughter card in the 360/380/580 for nic options like broadcom 4 por= t gigabit nic , melenox infinbabd, intel pro1000 4 port nic , qlogic 8Gb fc-= al and others . They said its an FRU but I have not seen the parts yet .=20= --- Mark saad | mark.saad@longcount.org From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 15:40:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8F83664 for ; Sat, 3 Nov 2012 15:40:07 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp9.sbb.rs (smtp9.sbb.rs [89.216.2.41]) by mx1.freebsd.org (Postfix) with ESMTP id 271E78FC0C for ; Sat, 3 Nov 2012 15:40:06 +0000 (UTC) Received: from mycenae (cable-178-148-110-37.dynamic.sbb.rs [178.148.110.37]) by smtp9.sbb.rs (8.14.0/8.14.0) with ESMTP id qA3FXVId012644 for ; Sat, 3 Nov 2012 16:33:37 +0100 Received: by mycenae (Postfix, from userid 1001) id 005965C2F; Sat, 3 Nov 2012 16:33:27 +0100 (CET) Date: Sat, 3 Nov 2012 16:33:27 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: Re: SU+J on 9.1-RC2 ISO Message-ID: <20121103153327.GA1155@mycenae.sbb.rs> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -1.8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:40:07 -0000 I still use 8 and plan to install branch 9 on new laptop with ssd. If journaling comes as default on 9.1, I plan to accept defaults on partitioning and use tunefs to remove it with -h disable. Any idea what steps should I take for that? As far as I read, journaling uses it's own partitions. Do I have to remove them, resize them? Branch 8 had option to choose su and j during install. I tried to find proper tutorials/manuals, but lacked to re- solve it in my head. Best regards all Zoran From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 15:44:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CC63787 for ; Sat, 3 Nov 2012 15:44:41 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 04DE08FC17 for ; Sat, 3 Nov 2012 15:44:40 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TUftq-00035x-L3 for freebsd-stable@freebsd.org; Sat, 03 Nov 2012 16:44:46 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Nov 2012 16:44:42 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Nov 2012 16:44:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: freebsd-update and surces of 9.1-RC3 Date: Sat, 3 Nov 2012 15:44:19 +0000 (UTC) Lines: 30 Message-ID: References: <50952210.7060000@grosbein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:44:41 -0000 Eugene Grosbein grosbein.net> writes: > > Hi! > > I'm trying to use freebsd-update for first time. > I have 9.0-RELEASE installed without sources and I have read Handbook chapter > and manual page for freebsd-update. > ... > How do I make freebsd-update to download and install sources > for 9.1-RC3 so I could rebuild custom kernel? > ... You did not get src updated because you did not have it before. Because there was no official announcement, I can give you a link (similar to one for -RC2), from which you can get the sources src.txz: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.1-RC3/ Be sure to check download's signature in MANIFEST file. After that: - make backup of anything you got in /usr/src, and remove that dir # rm -rf /usr/src - unpack downloaded file locally into /usr/src dir (that destination dir is a default) jb From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 15:48:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C8538AF for ; Sat, 3 Nov 2012 15:48:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id A51678FC08 for ; Sat, 3 Nov 2012 15:48:45 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id qA3Fmg7D012979; Sat, 3 Nov 2012 22:48:42 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <50953CD5.7010902@grosbein.net> Date: Sat, 03 Nov 2012 22:48:37 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: jb Subject: Re: freebsd-update and sources of 9.1-RC3 References: <50952210.7060000@grosbein.net> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:48:47 -0000 03.11.2012 22:44, jb ÐÉÛÅÔ: > Eugene Grosbein grosbein.net> writes: > >> >> Hi! >> >> I'm trying to use freebsd-update for first time. >> I have 9.0-RELEASE installed without sources and I have read Handbook chapter >> and manual page for freebsd-update. >> ... >> How do I make freebsd-update to download and install sources >> for 9.1-RC3 so I could rebuild custom kernel? >> ... > > You did not get src updated because you did not have it before. > Because there was no official announcement, I can give you a link (similar to > one for -RC2), from which you can get the sources src.txz: > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.1-RC3/ > Be sure to check download's signature in MANIFEST file. > After that: > - make backup of anything you got in /usr/src, and remove that dir > # rm -rf /usr/src > - unpack downloaded file locally into /usr/src dir (that destination dir is > a default) > > jb Thanks, I've already done that :-) My real question is how make freebsd-update download sources they are not installed? From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 16:03:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A69FAE2A for ; Sat, 3 Nov 2012 16:03:57 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 544538FC0A for ; Sat, 3 Nov 2012 16:03:57 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TUgCZ-0003r3-AC for freebsd-stable@freebsd.org; Sat, 03 Nov 2012 17:04:03 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Nov 2012 17:04:03 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Nov 2012 17:04:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: freebsd-update and sources of 9.1-RC3 Date: Sat, 3 Nov 2012 16:03:43 +0000 (UTC) Lines: 14 Message-ID: References: <50952210.7060000@grosbein.net> <50953CD5.7010902@grosbein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:03:57 -0000 Eugene Grosbein grosbein.net> writes: > ... > My real question is how make freebsd-update download sources they are not > installed? I am not 110% sure, but you can not. When freebsd-update runs, it checks its config file /etc/freebsd-update.conf and then takes inventory of your system (that's why it is called "update", and that's why you do not get new src set). FREEBSD-UPDATE(8) does not give any "override" option. So, here you are. But next time (assuming you keep your src) you will be fine. jb From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 16:39:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0B617C1 for ; Sat, 3 Nov 2012 16:39:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8CEED8FC12 for ; Sat, 3 Nov 2012 16:39:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TUgkc-0002DY-6Y for freebsd-stable@freebsd.org; Sat, 03 Nov 2012 17:39:14 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Nov 2012 17:39:14 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Nov 2012 17:39:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: SU+J on 9.1-RC2 ISO Date: Sat, 3 Nov 2012 16:38:50 +0000 (UTC) Lines: 26 Message-ID: References: <20121103153327.GA1155@mycenae.sbb.rs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:39:09 -0000 Zoran Kolic sbb.rs> writes: > > I still use 8 and plan to install branch 9 on new laptop > with ssd. If journaling comes as default on 9.1, I plan to > accept defaults on partitioning and use tunefs to remove it > with -h disable. Any idea what steps should I take for that? > As far as I read, journaling uses it's own partitions. Do > I have to remove them, resize them? Branch 8 had option to > choose su and j during install. > I tried to find proper tutorials/manuals, but lacked to re- > solve it in my head. > Best regards all If you manage to disable it during install configuration (shell access) but before actual system installation, there is nothing else to do. If you install a partition with su+j, then as tunefs(8) says, you have to have your partition unmounted or ro to disable "J". But before doing that, you should run 'fsck' on that partition to have (select) journal played itself empty. Btw, any "J" partition has .sujournal file, e.g. # ls -al /.sujournal You can get rid of it then. jb From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 17:59:04 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F415292 for ; Sat, 3 Nov 2012 17:59:04 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id B37898FC08 for ; Sat, 3 Nov 2012 17:59:03 +0000 (UTC) Received: (qmail 16113 invoked by uid 89); 3 Nov 2012 17:58:56 -0000 Received: by simscan 1.4.0 ppid: 16108, pid: 16110, t: 0.0826s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15535 Received: from unknown (HELO linux-wb36.example.org) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 3 Nov 2012 17:58:56 -0000 Date: Sat, 3 Nov 2012 18:58:50 +0100 From: Rainer Duffner To: Mark Saad Subject: Re: FreeBSD 9.1 stability/robustness? Message-ID: <20121103185850.487188a3@linux-wb36.example.org> In-Reply-To: <97EBC854-07A3-40E2-A397-FB71A7FCA64E@longcount.org> References: <201211020214.UAA29489@lariat.net> <20121102091021.23cf9af0@suse3> <20121102201554.6048f2e0@linux-wb36.example.org> <97EBC854-07A3-40E2-A397-FB71A7FCA64E@longcount.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.7; i586-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 17:59:04 -0000 Am Sat, 3 Nov 2012 11:06:26 -0400 schrieb Mark Saad : > Hp did a presentation at work 2 weeks ago about the g8 . Hp said you > can swap out a daughter card in the 360/380/580 for nic options like > broadcom 4 port gigabit nic , melenox infinbabd, intel pro1000 4 port > nic , qlogic 8Gb fc-al and others . I've heard that, too (was on holiday when the sales-guy was here) > They said its an FRU but I have > not seen the parts yet . The quickspecs make no mention of it: http://h18000.www1.hp.com/products/quickspecs/14212_na/14212_na.html Only that 331FLR adapter, with contains that beloved BCM-chip. http://h18000.www1.hp.com/products/quickspecs/14214_div/14214_div.HTML Or one of the 10G adapters. But 10G is probably worse - and we don't have any 10G switch-ports anyway.... With the infiniband-stuff, they are probably waiting for the first customer to order a couple of thousand so they can do a profitable one-off production run... From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 19:09:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF2C7489 for ; Sat, 3 Nov 2012 19:09:34 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6408FC14 for ; Sat, 3 Nov 2012 19:09:34 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta03.emeryville.ca.mail.comcast.net with comcast id K3px1k0030x6nqcA379ahH; Sat, 03 Nov 2012 19:09:34 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id K79W1k00R1t3BNj8Y79WWo; Sat, 03 Nov 2012 19:09:33 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6A1EE73A31; Sat, 3 Nov 2012 12:09:30 -0700 (PDT) Date: Sat, 3 Nov 2012 12:09:30 -0700 From: Jeremy Chadwick To: b.smeelen@ose.nl Subject: Re: SU+J on 9.1-RC2 ISO Message-ID: <20121103190930.GA23145@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, nwhitehorn@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 19:09:34 -0000 (Please keep me CC'd, as I'm not subscribed to -stable) I've CC'd Nathan Whitehorn, who according to bsdinstall(8) is the author (not sure if maintainer) of the code. This default has already begun to bite users/SAs in the ass: http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html SU+J (the journalling part specifically) needs to be disabled by default in the installer. This default was a very bad choice and should not have been done. It either indicates someone was out of touch with the rest of the issues surrounding the feature, or that someone intentionally decided "it's the best way to get people using it for testing" (I have seen this justification presented in the past, and it is the wrong approach). However, since some people DO want it (and those folks don't use dump), the installer should be modified to make SU+J support toggleable via a a checkbox. The default, obviously, should be unchecked. If the user checks the checkbox, an ominous warning message should be displayed informing the user of the repercussions. The only option at that point should be "OK", after which the checkbox is checked. Do not tell me "send patches". This issue/problem has gone on long enough, and the community bitched hard/long enough, that the person who committed this default should be responsible for fixing it. We should operate under the assumption that this bug/problem will never be fixed. It probably will be, but again, we must operate with the assumption that Kirk et al will require years to fix it. (It has already been something like 9 months. Or is it a year?) While I'm here -- does anyone remember the exact commit which was done sometime in the past 6-9 months which "made the installer work properly with SSDs" (re: partition alignment)? I have questions about that; if I remember right, someone set the alignment size to 4KBytes, and that is completely 100% wrong -- it needs to be 1MByte or 2MBytes if you want to be extra cautious, which correlates with NAND erase block size, otherwise we're not really solving jack squat. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 19:20:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5208C70B for ; Sat, 3 Nov 2012 19:20:13 +0000 (UTC) (envelope-from bane.ivosev@pmf.uns.ac.rs) Received: from mail.pmf.uns.ac.rs (mail.pmf.uns.ac.rs [147.91.177.13]) by mx1.freebsd.org (Postfix) with ESMTP id DD4598FC08 for ; Sat, 3 Nov 2012 19:20:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.pmf.uns.ac.rs (Postfix) with ESMTP id 3E33521281 for ; Sat, 3 Nov 2012 20:12:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.pmf.uns.ac.rs Received: from mail.pmf.uns.ac.rs ([127.0.0.1]) by localhost (mail.pmf.uns.ac.rs [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7gS+yxSXOLme for ; Sat, 3 Nov 2012 20:12:26 +0100 (CET) Received: from [10.10.13.5] (unknown [10.10.11.14]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bane.ivosev@pmf.uns.ac.rs) by mail.pmf.uns.ac.rs (Postfix) with ESMTPSA id 659AE20FE7 for ; Sat, 3 Nov 2012 20:12:26 +0100 (CET) Message-ID: <50956C99.9060708@pmf.uns.ac.rs> Date: Sat, 03 Nov 2012 20:12:25 +0100 From: Bane Ivosev Organization: PMF Novi Sad User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.10) Gecko/20121028 Icedove/10.0.10 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Subject: kvm vlan virtio problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: bane.ivosev@pmf.uns.ac.rs List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 19:20:13 -0000 hi, i have several kvm ubuntu 12.04 and centos 6 hosts with standard bridged network setup. same problem on each server with freebsd 9 amd64 guest and virtio nic: soon after guest start host syslog is filling with this message at very high rate. guest is working without any problem. with e1000 guest driver eveything is ok. does enyone have/had same problem? thanks. kernel: [2337728.094141] ------------[ cut here ]------------ kernel: [2337728.094144] WARNING: at /build/buildd/linux-3.2.0/net/core/dev.c:1955 skb_gso_segment+0x341/0x3b0() kernel: [2337728.094146] Hardware name: System x3550 M3 -[7944K3G]- kernel: [2337728.094148] 802.1Q VLAN Support: caps=(0x30195833, 0x0) len=3196 data_len=0 ip_summed=0 kernel: [2337728.094149] Modules linked in: dm_snapshot ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables kvm_intel kvm dm_crypt nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat fat 8021q garp bridge stp serio_raw cdc_ether usbnet vhost_net macvtap i7core_edac macvlan shpchp ioatdma edac_core dca tpm_tis lp parport mac_hid btrfs zlib_deflate libcrc32c usbhid hid megaraid_sas bnx2 kernel: [2337728.094177] Pid: 8685, comm: vhost-8683 Tainted: G W 3.2.0-31-generic #50-Ubuntu kernel: [2337728.094179] Call Trace: kernel: [2337728.094180] [] warn_slowpath_common+0x7f/0xc0 kernel: [2337728.094185] [] warn_slowpath_fmt+0x46/0x50 kernel: [2337728.094188] [] skb_gso_segment+0x341/0x3b0 kernel: [2337728.094191] [] dev_hard_start_xmit+0xc1/0x540 kernel: [2337728.094196] [] ? br_flood+0xc0/0xc0 [bridge] kernel: [2337728.094199] [] dev_queue_xmit+0x2aa/0x420 kernel: [2337728.094203] [] br_dev_queue_push_xmit+0x92/0xd0 [bridge] kernel: [2337728.094208] [] br_forward_finish+0x58/0x60 [bridge] kernel: [2337728.094212] [] __br_forward+0xab/0xd0 [bridge] kernel: [2337728.094217] [] br_forward+0x5d/0x70 [bridge] kernel: [2337728.094221] [] br_handle_frame_finish+0x182/0x2a0 [bridge] kernel: [2337728.094226] [] br_handle_frame+0x1c8/0x270 [bridge] kernel: [2337728.094231] [] ? br_handle_frame_finish+0x2a0/0x2a0 [bridge] kernel: [2337728.094234] [] __netif_receive_skb+0x1e2/0x520 kernel: [2337728.094237] [] process_backlog+0xb1/0x190 kernel: [2337728.094240] [] net_rx_action+0x134/0x290 kernel: [2337728.094242] [] ? _raw_spin_lock+0xe/0x20 kernel: [2337728.094245] [] __do_softirq+0xa8/0x210 kernel: [2337728.094248] [] call_softirq+0x1c/0x30 kernel: [2337728.094249] [] do_softirq+0x65/0xa0 kernel: [2337728.094254] [] netif_rx_ni+0x28/0x30 kernel: [2337728.094258] [] tun_get_user+0x306/0x4a0 kernel: [2337728.094261] [] tun_sendmsg+0x25/0x30 kernel: [2337728.094265] [] handle_tx+0x296/0x530 [vhost_net] kernel: [2337728.094269] [] handle_tx_kick+0x15/0x20 [vhost_net] kernel: [2337728.094273] [] vhost_worker+0xdd/0x170 [vhost_net] kernel: [2337728.094276] [] ? vhost_set_memory+0x130/0x130 [vhost_net] kernel: [2337728.094279] [] kthread+0x8c/0xa0 kernel: [2337728.094282] [] kernel_thread_helper+0x4/0x10 kernel: [2337728.094285] [] ? flush_kthread_worker+0xa0/0xa0 kernel: [2337728.094287] [] ? gs_change+0x13/0x13 kernel: [2337728.094289] ---[ end trace a38cf088269411b3 ]--- kernel: [2337728.094731] ------------[ cut here ]------------ From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 20:19:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0988247F; Sat, 3 Nov 2012 20:19:37 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmaila.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id C50C68FC08; Sat, 3 Nov 2012 20:19:36 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 930FEC894; Sat, 3 Nov 2012 16:19:27 -0400 (EDT) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 5B27FD717; Sat, 3 Nov 2012 16:19:26 -0400 (EDT) Received: from smtp3.acsu.buffalo.edu (smtp3.acsu.buffalo.edu [128.205.5.226]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 42261C14E; Sat, 3 Nov 2012 16:19:26 -0400 (EDT) Received: from [192.168.1.101] (cpe-72-231-248-9.buffalo.res.rr.com [72.231.248.9]) (Authenticated sender: kensmith@buffalo.edu) by smtp3.acsu.buffalo.edu (Postfix) with ESMTPSA id D5EDD4F432; Sat, 3 Nov 2012 16:19:25 -0400 (EDT) Subject: FreeBSD 9.1-RC3 Available... From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-W5y/ioGOPKEOQGBI9RMf" Organization: U. Buffalo Date: Sat, 03 Nov 2012 16:19:25 -0400 Message-ID: <1351973965.39027.14.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 28% Cc: re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 20:19:37 -0000 --=-W5y/ioGOPKEOQGBI9RMf Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The third release candidate of the 9.1-RELEASE release cycle is now available on the FTP servers for amd64, i386, powerpc64, and sparc64. The MD5/SHA256 checksums are at the bottom of this message. The ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/ (or any of the FreeBSD mirror sites). This is expected to be the last Release Candidate. Unless a major show-stopper is discovered within the next few days the final Release Builds will be started. If you notice any problems you can report them through the normal Gnats PR system or here on the -stable mailing list. If you want to do a source-based update to an existing system using SVN the branch to use is releng/9.1. If you would like to use CVS instead use RELENG_9_1. The freebsd-update(8) utility supports binary upgrades of i386 and amd64= =20 systems running earlier FreeBSD releases. Systems running 9.0-RELEASE, 9.1-BETA1, 9.1-RC1, or 9.1-RC2 can upgrade as follows: # freebsd-update upgrade -r 9.1-RC3 During this process, FreeBSD Update may ask the user to help by merging=20 some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before=20 continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new= =20 userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 7.X, 8.X) can also use freebsd-update to upgrade to FreeBSD 9.1-RC3, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 7.X or FreeBSD 8.X and FreeBSD 9.X. Checksums: SHA256 (FreeBSD-9.1-RC3-amd64-bootonly.iso) =3D 86d57e699ae0e298a420ff168e6= abe7b715e6dee8350149ed2f230885b1973ec SHA256 (FreeBSD-9.1-RC3-amd64-disc1.iso) =3D 11c7e4ab16294794bf950073901f9a= 4dc8f735de08b02a321b63c4702af60f98 SHA256 (FreeBSD-9.1-RC3-amd64-memstick.img) =3D ccd983a7e1f37c0bb4b87c6cacc= 3945d38be8add66ea0689c0b8e0a72c75ad58 MD5 (FreeBSD-9.1-RC3-amd64-bootonly.iso) =3D 278a0ee9e00dba88068f1ad1c50942= 9c MD5 (FreeBSD-9.1-RC3-amd64-disc1.iso) =3D 78ea831eaf495e2f713d5cd5ffc5f083 MD5 (FreeBSD-9.1-RC3-amd64-memstick.img) =3D f37c7ff68025bc065465d3d647b6e7= e0 SHA256 (FreeBSD-9.1-RC3-i386-bootonly.iso) =3D 8b944a3b263de04db2e0cb38b068= a4ceca6e2fe4f8af5344567696e09b7df66a SHA256 (FreeBSD-9.1-RC3-i386-disc1.iso) =3D e7c19e2aadb0c6ce072265511d84fd0= d39c6e60628231d8dc31023d410e285d6 SHA256 (FreeBSD-9.1-RC3-i386-memstick.img) =3D 1ebb2ebf6b20376df7c3719f5b1b= bbdd47ae2054e3a23019d8fdc93734f78fe5 MD5 (FreeBSD-9.1-RC3-i386-bootonly.iso) =3D f14703b350e7f2357d23250c6eeee4e= f MD5 (FreeBSD-9.1-RC3-i386-disc1.iso) =3D 13405032579c52182bedfcd84a294871 MD5 (FreeBSD-9.1-RC3-i386-memstick.img) =3D 515d0866470d2edd1d99867e83387c3= 5 SHA256 (FreeBSD-9.1-RC3-powerpc64-bootonly.iso) =3D b46212dc2fa3308fc58465b= b999b4ec857245826fd1cb122af758e8b340afaf4 SHA256 (FreeBSD-9.1-RC3-powerpc64-memstick) =3D bfda2bf019eb4c540d280608a81= ba9d67402ab0248c38c33badb4548e725f657 SHA256 (FreeBSD-9.1-RC3-powerpc64-release.iso) =3D b5e0948df8d7f62a7e620647= d90c3c47f89ad71cf310277d86ef139c8ba25961 MD5 (FreeBSD-9.1-RC3-powerpc64-bootonly.iso) =3D d474edb9aac9aa5e9ad226a1e3= 45cbd9 MD5 (FreeBSD-9.1-RC3-powerpc64-memstick) =3D aa443c1ae88773cc6c0a070ca2c678= 4f MD5 (FreeBSD-9.1-RC3-powerpc64-release.iso) =3D 237aaf75f2f6b2192cf0e1f51c1= 90dc8 SHA256 (FreeBSD-9.1-RC3-sparc64-bootonly.iso) =3D e1d61b01ba8d03c324f0a8285= 27741542fd0b337d3281b1f943658f5f482ae9e SHA256 (FreeBSD-9.1-RC3-sparc64-disc1.iso) =3D 9b59c368f0572198ef9562c7f52a= 45ca33aa832d607c6331bd4ca796c5ca4d8f MD5 (FreeBSD-9.1-RC3-sparc64-bootonly.iso) =3D e3e10bc7ce2a0377053cb2d7eff2= 2538 MD5 (FreeBSD-9.1-RC3-sparc64-disc1.iso) =3D ab754ee5361a4c9b8d451b0eee08073= 2 --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-W5y/ioGOPKEOQGBI9RMf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlCVfEEACgkQ/G14VSmup/YQKwCfbm0WDGnTCMRPlziycrsZkS+R BPsAoIfsVIV7BmsaFPtSOXf+v1xC9VoX =2zrf -----END PGP SIGNATURE----- --=-W5y/ioGOPKEOQGBI9RMf-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 20:41:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43493C87 for ; Sat, 3 Nov 2012 20:41:20 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id CE8D28FC12 for ; Sat, 3 Nov 2012 20:41:19 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.196.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id E0FB942C088A; Sat, 3 Nov 2012 21:42:40 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from sage.daemoninthecloset.org (sage.daemoninthecloset.org [127.0.1.1]) by sage.daemoninthecloset.org (Postfix) with ESMTP id 153C26F384; Sat, 3 Nov 2012 15:40:17 -0500 (CDT) Date: Sat, 3 Nov 2012 15:40:16 -0500 (CDT) From: Bryan Venteicher To: bane ivosev Message-ID: <1542441515.1609.1351975216870.JavaMail.root@daemoninthecloset.org> In-Reply-To: <50956C99.9060708@pmf.uns.ac.rs> Subject: Re: kvm vlan virtio problem MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.14] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC22 (Mac)/7.2.0_GA_2669) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 20:41:20 -0000 Hi, ----- Original Message ----- > From: "Bane Ivosev" > To: freebsd-stable@freebsd.org > Sent: Saturday, November 3, 2012 2:12:25 PM > Subject: kvm vlan virtio problem > > hi, i have several kvm ubuntu 12.04 and centos 6 hosts with standard > bridged network setup. same problem on each server with freebsd 9 > amd64 > guest and virtio nic: soon after guest start host syslog is filling > with > this message at very high rate. guest is working without any problem. > with e1000 guest driver eveything is ok. > > does enyone have/had same problem? > > thanks. > I have a vague recollection of looking at something similar last year... Do you have VLAN configured in the guest as well? What is the ifconfig output? Does disabling TSO on the vtnetX device make these messages go away? Bryan > > kernel: [2337728.094141] ------------[ cut here ]------------ > kernel: [2337728.094144] WARNING: at > /build/buildd/linux-3.2.0/net/core/dev.c:1955 > skb_gso_segment+0x341/0x3b0() > kernel: [2337728.094146] Hardware name: System x3550 M3 -[7944K3G]- > kernel: [2337728.094148] 802.1Q VLAN Support: caps=(0x30195833, > 0x0) > len=3196 data_len=0 ip_summed=0 > kernel: [2337728.094149] Modules linked in: dm_snapshot > ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE > iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state > nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp > iptable_filter ip_tables x_tables kvm_intel kvm dm_crypt nfsd nfs > lockd > fscache auth_rpcgss nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat fat > 8021q garp bridge stp serio_raw cdc_ether usbnet vhost_net macvtap > i7core_edac macvlan shpchp ioatdma edac_core dca tpm_tis lp parport > mac_hid btrfs zlib_deflate libcrc32c usbhid hid megaraid_sas bnx2 > kernel: [2337728.094177] Pid: 8685, comm: vhost-8683 Tainted: G > W 3.2.0-31-generic #50-Ubuntu > kernel: [2337728.094179] Call Trace: > kernel: [2337728.094180] [] > warn_slowpath_common+0x7f/0xc0 > kernel: [2337728.094185] [] > warn_slowpath_fmt+0x46/0x50 > kernel: [2337728.094188] [] > skb_gso_segment+0x341/0x3b0 > kernel: [2337728.094191] [] > dev_hard_start_xmit+0xc1/0x540 > kernel: [2337728.094196] [] ? br_flood+0xc0/0xc0 > [bridge] > kernel: [2337728.094199] [] > dev_queue_xmit+0x2aa/0x420 > kernel: [2337728.094203] [] > br_dev_queue_push_xmit+0x92/0xd0 [bridge] > kernel: [2337728.094208] [] > br_forward_finish+0x58/0x60 [bridge] > kernel: [2337728.094212] [] > __br_forward+0xab/0xd0 > [bridge] > kernel: [2337728.094217] [] br_forward+0x5d/0x70 > [bridge] > kernel: [2337728.094221] [] > br_handle_frame_finish+0x182/0x2a0 [bridge] > kernel: [2337728.094226] [] > br_handle_frame+0x1c8/0x270 [bridge] > kernel: [2337728.094231] [] ? > br_handle_frame_finish+0x2a0/0x2a0 [bridge] > kernel: [2337728.094234] [] > __netif_receive_skb+0x1e2/0x520 > kernel: [2337728.094237] [] > process_backlog+0xb1/0x190 > kernel: [2337728.094240] [] > net_rx_action+0x134/0x290 > kernel: [2337728.094242] [] ? > _raw_spin_lock+0xe/0x20 > kernel: [2337728.094245] [] > __do_softirq+0xa8/0x210 > kernel: [2337728.094248] [] > call_softirq+0x1c/0x30 > kernel: [2337728.094249] [] > do_softirq+0x65/0xa0 > kernel: [2337728.094254] [] > netif_rx_ni+0x28/0x30 > kernel: [2337728.094258] [] > tun_get_user+0x306/0x4a0 > kernel: [2337728.094261] [] > tun_sendmsg+0x25/0x30 > kernel: [2337728.094265] [] > handle_tx+0x296/0x530 > [vhost_net] > kernel: [2337728.094269] [] > handle_tx_kick+0x15/0x20 [vhost_net] > kernel: [2337728.094273] [] > vhost_worker+0xdd/0x170 > [vhost_net] > kernel: [2337728.094276] [] ? > vhost_set_memory+0x130/0x130 [vhost_net] > kernel: [2337728.094279] [] kthread+0x8c/0xa0 > kernel: [2337728.094282] [] > kernel_thread_helper+0x4/0x10 > kernel: [2337728.094285] [] ? > flush_kthread_worker+0xa0/0xa0 > kernel: [2337728.094287] [] ? > gs_change+0x13/0x13 > kernel: [2337728.094289] ---[ end trace a38cf088269411b3 ]--- > kernel: [2337728.094731] ------------[ cut here ]------------ > _______________________________________________ > 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-stable@FreeBSD.ORG Sat Nov 3 21:30:34 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B42653ED for ; Sat, 3 Nov 2012 21:30:34 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 55B6E8FC08 for ; Sat, 3 Nov 2012 21:30:34 +0000 (UTC) Received: (from brett@localhost) by lariat.net (8.9.3/8.9.3) id PAA04484 for stable@freebsd.org; Sat, 3 Nov 2012 15:30:24 -0600 (MDT) Date: Sat, 3 Nov 2012 15:30:24 -0600 (MDT) From: Brett Glass Message-Id: <201211032130.PAA04484@lariat.net> To: stable@freebsd.org Subject: Why is SU+J undesirable on SSDs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 21:30:34 -0000 Have been following the thread related to SU+J, and am wondering: why is it considered to be undesirable on SSDs (assuming that they have good wear leveling)? I have been enabling it on systems with SSDs, hoping that between the lack of rotating media and the journaling I would have very robust systems. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 22:06:51 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E3A3E76 for ; Sat, 3 Nov 2012 22:06:51 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F16338FC15 for ; Sat, 3 Nov 2012 22:06:50 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so5815201obb.13 for ; Sat, 03 Nov 2012 15:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VSu79yUK2Jh2URCRpgNlJgheUeX6CuOEYkwdvB2EgDQ=; b=garWyqjg2FcbRqk6MRVE44Nx+jNGV/hr7Vh4VPAmyiFQ4gUh+b13AYfuKd9Y7oXlq2 s2JQp2C44KxCNvX4u3zZHcIvcXYWLVjhxBk0jy+KdsbopeK6BCoejMQh+mbNg5e4PgQ4 YYE2I0i+MeKJP6++Vnqf4JrUriz7UjyY3DZBgA9JC730i+Yj8oAk3vdANU/okTdgHuAY NEu3+YFMz5hC4SLgzPvUJ1hwN+WoOI1dVE9UfDu++q8r+WTTaYUe2fnQ/uWyMqyqziaf Q4EO3bNtqoOAk71TEDoTgcR1G4aKDnm8o0SJNpCoNkuYRvVO+RoycGJNPOgavGSkD418 pDig== MIME-Version: 1.0 Received: by 10.182.4.174 with SMTP id l14mr4472628obl.88.1351980410305; Sat, 03 Nov 2012 15:06:50 -0700 (PDT) Received: by 10.76.80.104 with HTTP; Sat, 3 Nov 2012 15:06:50 -0700 (PDT) In-Reply-To: <201211032130.PAA04484@lariat.net> References: <201211032130.PAA04484@lariat.net> Date: Sat, 3 Nov 2012 17:06:50 -0500 Message-ID: Subject: Re: Why is SU+J undesirable on SSDs? From: Adam Vande More To: Brett Glass Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 22:06:51 -0000 On Sat, Nov 3, 2012 at 4:30 PM, Brett Glass wrote: > Have been following the thread related to SU+J, and am wondering: why is it > considered to be undesirable on SSDs (assuming that they have good wear > leveling)? Superstition -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 22:26:55 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52A55E8C for ; Sat, 3 Nov 2012 22:26:55 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC038FC08 for ; Sat, 3 Nov 2012 22:26:54 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3339809pad.13 for ; Sat, 03 Nov 2012 15:26:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=Tp6q9uK8CJekok5LHtS2zKbp3SEdCdANZPKTCLgNCyA=; b=nAeznwddnsGtdQx7LmgE9KLreTr1LL0fFXbJfXkn6dtCDIK17Mrl9xavALTVZfowtM TXiyXCrKJnk0JrUsDSNUUq5QBz5ueEKkYQEwiU0al2+iJpe74EH56M77UDLEixbLs8on UtF7nY/rhX0/EnZoIV76LKwyt10ghFectEGUFizHSdy/Ote2wx5QQ/ozbcqdAhTAdpD/ jJa9PTwUXL3TLGdBMllMJFuWD2irtdEe4Grh2JdJbg1+/5BHL4KPDDpVrtTC2iGOziXJ pZ8vmgUUCoXJ6g3T1p3B+thYoyCMeJ5lCiPkzmVihcfL4QbhIciNhBK+4s5AMJOKkm22 SB7g== Received: by 10.68.232.163 with SMTP id tp3mr18340173pbc.44.1351981614502; Sat, 03 Nov 2012 15:26:54 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id ix9sm7956601pbc.7.2012.11.03.15.26.53 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 15:26:53 -0700 (PDT) Date: Sat, 3 Nov 2012 12:25:30 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Brett Glass Subject: Re: Why is SU+J undesirable on SSDs? In-Reply-To: <201211032130.PAA04484@lariat.net> Message-ID: References: <201211032130.PAA04484@lariat.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQlXezvyYhRJaHXZkw9M0EiPkrWAcT2zU7uCO9Wy41rfUnzJpYRVHo0Tzd05vP/WGIlBXsDq Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 22:26:55 -0000 On Sat, 3 Nov 2012, Brett Glass wrote: > Have been following the thread related to SU+J, and am wondering: why is it > considered to be undesirable on SSDs (assuming that they have good wear > leveling)? I have been enabling it on systems with SSDs, hoping that between > the lack of rotating media and the journaling I would have very robust > systems. I know of no reason to support this notion. Although SSDs are so fast you might be happy to wait for the fsck time in exchange for snapshots. Jeff > > --Brett Glass > _______________________________________________ > 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-stable@FreeBSD.ORG Sat Nov 3 22:41:41 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D72870E for ; Sat, 3 Nov 2012 22:41:41 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id E807F8FC08 for ; Sat, 3 Nov 2012 22:41:40 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3342727pad.13 for ; Sat, 03 Nov 2012 15:41:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=/aoaYnatAV1Amhlt/ro9fkE7nusT1NO1ieYMzakVoZY=; b=YQycFSRW42yE9DPEwAtQa7qEI/be+nUO9UV6GHblZzDVQm6YDstK4kfHPZNwVKxipm MpMHXLzFCDJeKvYQmhdQyfV/97GvFPVh/4j7I5jCWda2NlgzL4byc0ULKrnU6UXKFXG3 EmYC2N3J8HE6RTbbPTw/N+9N2UdaQWCyYfTB2r5cggW2NhI+To/+9Bui6yH9iemdnNp+ Le8wFSvH+yn/gzVwBv5Zs5hx+VVTEMmIPpnfTys7PSnAncsrCAGrw/ZGkw3QQE6D29du R3xZ35Nz/4SYo/eeuverU1evDyKMDFVpGgC3h5smK+O7c/zpxauWBWS44zt9CWG9I6jg pA5A== Received: by 10.68.226.67 with SMTP id rq3mr18089901pbc.121.1351982500581; Sat, 03 Nov 2012 15:41:40 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id ph7sm6525171pbb.9.2012.11.03.15.41.39 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 15:41:40 -0700 (PDT) Date: Sat, 3 Nov 2012 12:40:16 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Karl Denninger Subject: Re: Why is SU+J undesirable on SSDs? In-Reply-To: <50959B63.9070709@denninger.net> Message-ID: References: <201211032130.PAA04484@lariat.net> <50959B63.9070709@denninger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-1174873047-1351982418=:1947" X-Gm-Message-State: ALoCoQmyuoMhDh1caL0O9ncbN3g4yHShyur6YprK40s4XoqM8NAYsWoLO78a46EIiAiI+PHox2lY Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 22:41:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2547152148-1174873047-1351982418=:1947 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 3 Nov 2012, Karl Denninger wrote: > > On 11/3/2012 5:25 PM, Jeff Roberson wrote: > On Sat, 3 Nov 2012, Brett Glass wrote: > > Have been following the thread related to SU+J, and > am wondering: why is it > considered to be undesirable on SSDs (assuming that > they have good wear > leveling)? I have been enabling it on systems with > SSDs, hoping that between > the lack of rotating media and the journaling I > would have very robust > systems. > > > I know of no reason to support this notion.  Although SSDs are > so fast you might be happy to wait for the fsck time in exchange > for snapshots. > > Jeff > > > It is utter insanity to enable, by default, filesystem options that break > the canonical backup solution in the handbook ("dump", when used with "-L", > which it must be to dump a live filesystem SAFELY.) I did not enable it by default but it makes sense for desktop users who are probably not often using dump/restore. I agree that the option should be covered in more detail. > > IMHO either snapshots with journaling needs to be fixed, some other > canonical and reasonably-implemented means of backups that actually works > and is as robust as dump must be made available, tested and documented at > the level that dump has been (good luck with that!) or +J has to be removed > as the default. We are hopefully fixing snapshots in current and I would expect it to be ready for backport in the 9.2 timeframe. It is next on the list after we fix the drive write cache problem for mobile users who may lose power frequently. > > I love "progress" as much as the next guy but my first requirement for an > operating system is that it not irretrievably lose my data. I hear your frustrations but please try to express it more productively in the future. Thanks, Jeff > > -- > -- Karl Denninger > The Market Ticker (R) > Cuda Systems LLC > > --2547152148-1174873047-1351982418=:1947-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 22:55:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1300ACE1 for ; Sat, 3 Nov 2012 22:55:06 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 878448FC15 for ; Sat, 3 Nov 2012 22:54:53 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qA3MsqvO044529 for ; Sat, 3 Nov 2012 16:54:52 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qA3MsTKU010353; Sat, 3 Nov 2012 16:54:30 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Why is SU+J undesirable on SSDs? From: Ian Lepore To: Adam Vande More In-Reply-To: References: <201211032130.PAA04484@lariat.net> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Nov 2012 16:54:29 -0600 Message-ID: <1351983269.1120.137.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 22:55:06 -0000 On Sat, 2012-11-03 at 17:06 -0500, Adam Vande More wrote: > On Sat, Nov 3, 2012 at 4:30 PM, Brett Glass wrote: > > > Have been following the thread related to SU+J, and am wondering: why is it > > considered to be undesirable on SSDs (assuming that they have good wear > > leveling)? > > > Superstition > > Yeah, that's what it must be. Or... it could be well-informed choice. Journaling increases the number of writes. That puts wear on any disk, mechanical or SSD, and it takes time. What it buys you is better performance if you get into a crash recovery situation. It's perfectly reasonable for someone to make the decision that their SSD can finish an fsck so fast that there's no point in paying any penalty for the extra writes for journaling. I have a 256G SSD here with about 200G of data on it, and fsck without journaling takes about 3 minutes. I can live with that. With more data or a slower drive I might make a different choice. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 23:03:20 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DD5C392 for ; Sat, 3 Nov 2012 23:03:20 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 453808FC0A for ; Sat, 3 Nov 2012 23:03:19 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.4/8.13.1) with ESMTP id qA3MW8Am075801 for ; Sat, 3 Nov 2012 16:32:09 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Sat Nov 3 16:32:09 2012 Message-ID: <50959B63.9070709@denninger.net> Date: Sat, 03 Nov 2012 17:32:03 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jeff Roberson Subject: Re: Why is SU+J undesirable on SSDs? References: <201211032130.PAA04484@lariat.net> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Antivirus: avast! (VPS 121103-1, 11/03/2012), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 23:03:20 -0000 On 11/3/2012 5:25 PM, Jeff Roberson wrote: > On Sat, 3 Nov 2012, Brett Glass wrote: > >> Have been following the thread related to SU+J, and am wondering: why >> is it >> considered to be undesirable on SSDs (assuming that they have good wear >> leveling)? I have been enabling it on systems with SSDs, hoping that >> between >> the lack of rotating media and the journaling I would have very robust >> systems. > > I know of no reason to support this notion. Although SSDs are so fast > you might be happy to wait for the fsck time in exchange for snapshots. > > Jeff It is utter insanity to enable, by default, filesystem options that break _*the canonical backup solution*_ in the handbook ("dump", when used with "-L", which it must be to dump a live filesystem SAFELY.) IMHO either snapshots with journaling needs to be fixed, some other canonical and reasonably-implemented means of backups that actually works and is as robust as dump must be made available, tested and documented at the level that dump has been (good luck with that!) _*or*_ +J has to be removed as the default. I love "progress" as much as the next guy but my first requirement for an operating system is that it not irretrievably lose my data. -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 23:05:45 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2195B615 for ; Sat, 3 Nov 2012 23:05:45 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id C74E38FC12 for ; Sat, 3 Nov 2012 23:05:44 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id RAA05316; Sat, 3 Nov 2012 17:05:35 -0600 (MDT) Message-Id: <201211032305.RAA05316@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 03 Nov 2012 17:04:01 -0600 To: Karl Denninger , Jeff Roberson From: Brett Glass Subject: Re: Why is SU+J undesirable on SSDs? In-Reply-To: <50959B63.9070709@denninger.net> References: <201211032130.PAA04484@lariat.net> <50959B63.9070709@denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 23:05:45 -0000 At 04:32 PM 11/3/2012, Karl Denninger wrote: >It is utter insanity to enable, by default, filesystem options >that break the canonical backup solution in the handbook ("dump", >when used with "-L", which it must be to dump a live filesystem SAFELY.) I have not used "dump" in many, many years. So, I hope the installer will not make it difficult for me to turn on SU+J despite the problem you mention above. That being said, "dump" should obviously be fixed to work with SU+J. Perhaps there could be a workaround (e.g. synchronizing the file system and temporarily turning off journaling during a backup) that would eliminate the need to turn SU+J off all the time while a more graceful fix is being readied. --Brett From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 23:16:03 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCDCC7B0 for ; Sat, 3 Nov 2012 23:16:03 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 835158FC0A for ; Sat, 3 Nov 2012 23:16:03 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3349845pad.13 for ; Sat, 03 Nov 2012 16:16:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=84euiro70ju3Z6WtfDCQOWgK2nyyflkeDZ06pg+DuXc=; b=koLUJKxdhKtpvvHIwR/TE8CI5heq7FjmD3S1lZgoDXgglawaWpttvslRrFU49gIjiv RZzOtnN+WklvsyLPa8AWQyjEVhIZV5NNS8mKhejbveUudYjGXiEvqDOSVbhHdmIucM9/ Qqp3Wt6owV6aAhUBvQtEFEZzOLFbebat5hXq+/h1ft4j2HNMM1kxTWcenXGh5y3aYJbl Pq+lGv1GhPW2sCOeDmbZjvYiT0o8KAQEYkpSMYHRzhiMlOST/RgoZw/t9t84S9Xl2pvu eDOzL2jdxZyHYsMueZNwnB20848/v+xgp7R3N91+aHWgsUVDqLO0QU7rF5jd++Cpy2Q8 C74A== Received: by 10.68.248.33 with SMTP id yj1mr18502733pbc.141.1351984562927; Sat, 03 Nov 2012 16:16:02 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id n11sm7990699pby.67.2012.11.03.16.16.01 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 16:16:02 -0700 (PDT) Date: Sat, 3 Nov 2012 13:14:38 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ian Lepore Subject: Re: Why is SU+J undesirable on SSDs? In-Reply-To: <1351983269.1120.137.camel@revolution.hippie.lan> Message-ID: References: <201211032130.PAA04484@lariat.net> <1351983269.1120.137.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQlSPGoz6qhflhEOqzBoWMykmM49/6y1C5heXAjtIlqSz6uyx9Kv0N39CmJVek1Q+gbQbqVs Cc: Adam Vande More , stable@freebsd.org, Brett Glass X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 23:16:04 -0000 On Sat, 3 Nov 2012, Ian Lepore wrote: > On Sat, 2012-11-03 at 17:06 -0500, Adam Vande More wrote: >> On Sat, Nov 3, 2012 at 4:30 PM, Brett Glass wrote: >> >>> Have been following the thread related to SU+J, and am wondering: why is it >>> considered to be undesirable on SSDs (assuming that they have good wear >>> leveling)? >> >> >> Superstition >> >> > > Yeah, that's what it must be. Or... it could be well-informed choice. > > Journaling increases the number of writes. That puts wear on any disk, > mechanical or SSD, and it takes time. What it buys you is better > performance if you get into a crash recovery situation. It's perfectly > reasonable for someone to make the decision that their SSD can finish an > fsck so fast that there's no point in paying any penalty for the extra > writes for journaling. The journal entries are 32 bytes per in SUJ. So the number of extra writes is down in the noise. The journaling also gets you asynchronous partial truncation and a few other asynchronous operations that are sync in SU. It does cost slightly more cpu time and more memory. I'm not saying you're making the wrong choice. I'm just saying that it's not clear that you should or should not use it with SSDs. > > I have a 256G SSD here with about 200G of data on it, and fsck without > journaling takes about 3 minutes. I can live with that. With more data > or a slower drive I might make a different choice. If you are happy with 3 minutes this is very reasonable and I assume you turn off bg fsck. Jeff > > -- Ian > > > _______________________________________________ > 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-stable@FreeBSD.ORG Sat Nov 3 23:38:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24F37DE2 for ; Sat, 3 Nov 2012 23:38:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id CC0848FC08 for ; Sat, 3 Nov 2012 23:38:13 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 835AB5C59; Sun, 4 Nov 2012 00:38:07 +0100 (CET) Message-ID: <5095AAE1.5070901@FreeBSD.org> Date: Sun, 04 Nov 2012 00:38:09 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Oleg V. Nauman" Subject: Re: WITH_LIBCPLUSPLUS buildworld broken on STABLE-9 References: <20121102202258.12004cox9k4zrq0w@webmail7.opentransfer.com> In-Reply-To: <20121102202258.12004cox9k4zrq0w@webmail7.opentransfer.com> Content-Type: multipart/mixed; boundary="------------000802080608050502020505" Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 23:38:14 -0000 This is a multi-part message in MIME format. --------------000802080608050502020505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-11-02 19:22, Oleg V. Nauman wrote: ... > /usr/src/lib/libc++/../../contrib/libc++/include/cstdlib:134:9: error: > no member named > 'at_quick_exit' in the global namespace > using ::at_quick_exit; > ~~^ This was fixed in head by r242472, I will merge it as soon as the MFC timer expires (Nov 5). Sorry about the breakage, this was my fault. In the meantime, you can use the attached diff. --------------000802080608050502020505 Content-Type: text/x-diff; name="mfc-r242472.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mfc-r242472.diff" Index: lib/libc++/Makefile =================================================================== --- lib/libc++/Makefile (revision 242535) +++ lib/libc++/Makefile (working copy) @@ -53,7 +53,7 @@ cxxrt_${_S}: WARNS= 0 CFLAGS+= -I${HDRDIR} -I${LIBCXXRTDIR} -nostdlib -DLIBCXXRT -.if !defined(CXXFLAGS) || ${CXXFLAGS:M-std=*}" == "" +.if empty(CXXFLAGS:M-std=*) CXXFLAGS+= -std=c++0x .endif --------------000802080608050502020505-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 23:52:53 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F99C2F5 for ; Sat, 3 Nov 2012 23:52:53 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id F13728FC12 for ; Sat, 3 Nov 2012 23:52:52 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id RAA05658; Sat, 3 Nov 2012 17:52:44 -0600 (MDT) Message-Id: <201211032352.RAA05658@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 03 Nov 2012 17:52:42 -0600 To: Jeff Roberson , Ian Lepore From: Brett Glass Subject: Re: Why is SU+J undesirable on SSDs? In-Reply-To: References: <201211032130.PAA04484@lariat.net> <1351983269.1120.137.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Adam Vande More , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 23:52:53 -0000 At 05:14 PM 11/3/2012, Jeff Roberson wrote: >The journal entries are 32 bytes per in SUJ. So the number of >extra writes is down in the noise. The journaling also gets you >asynchronous partial truncation and a few other asynchronous >operations that are sync in SU. It does cost slightly more cpu >time and more memory. I'm not saying you're making the wrong >choice. I'm just saying that it's not clear that you should or >should not use it with SSDs. This is what I would expect, and with wear leveling it is unlikely that the wear on the SSD would be significant anyway. In my case, the most important thing is not to lose logs in a crash (which could happen with just fsck), so journaling is worth it for me. The only reason I could see not to use SU+J with SSDs (or any disk, for that matter) is if there are bugs which harm stability. A look at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&severity=&priority=&class=&state=open&sort=none&text=&responsible=&multitext=&originator=&release= shows several open PRs mentioning panics, corruption, and reboots. Are they still open because problems exist? Or have the committers simply neglected to close them? --Brett Glass